Никакое расписание, Никакой UML, нет и т.д., но все еще проект быть успешным? [закрытый]

К сожалению, большого шока нет, назовите меня Айн Рэнд, но я давно придерживаюсь мнения, что 1% мира движет вперед остальные 99%.

Как это так? Что ж, все, что я вижу, когда читаю статью, это то, что люди ужасно умеют управлять чем угодно, но в конце концов все работает, потому что должно. На самом деле это просто задокументированное свидетельство того, что люди очень плохо умеют оценивать риски, и лучшее управление проектами - это то, что допускает неудачи и готовится к ним. Любая другая точка зрения является бредовой.

Если кто-то решит определить успех как вывод проекта за дверь (и это даже не худшее определение, которое я слышал), то для руководства очень легко заявить (или поверить), что все хорошо в мире. В конце концов, экономическое давление заключается в том, чтобы просто положить деньги в банк, только очень маленькие и очень крупные компании заинтересованы в том, чтобы заставить вещи работать [лучше].

Зачем вам нужны графики и т. д.? Итак, вы можете бороться с рисками и создать эффективную компанию. Вы можете обойтись и без всего этого (в мире нет справедливости), но вы увеличиваете риск крупной неудачи, и в конечном итоге это убьет вас.

33% проектов заявили, что у них нет риски, но 62% провалились

Говорит все реально. Люди, а?

Что ж ... Что касается проектов без расписания - они должны быть успешными, поскольку если вы дается столько времени, сколько вам нужно, большинство программных проектов становятся довольно тривиальными. Устранение давления дедлайнов, вероятно, приведет к более интеллектуальному и менее сложному кодированию.

Я также видел некоторые исследования, в которых говорилось, что выбор методологии не имеет значения, а просто помогли методология.

Я думаю, что мы ожидаем, что UML, расписания и подробное планирование помогут в наших проектах по программированию, потому что это то, что нам говорят менеджеры проектов. Вероятно, это вызвано вдохновленной модернизмом потребностью все контролировать.

Итак, они описывают определение успешного проекта в конце статьи:

Вернер также спросил разработчиков, что их критерии были для проекта успех. Они сказали:

 * У них было ощущение, что они поставили качественный продукт
* У них было чувство достижения
* У них было достаточно самостоятельности, чтобы работать творчески
* Требования были соблюдены, и система работала должным образом

Ничего о своевременной доставке или удовлетворении запросов клиента. Попался.

Как это?

Все зависит от того, как вы определяете успех. Я определяю успех как «Заинтересованные стороны довольны результатами».

Обычно ваши заинтересованные стороны оценивают результаты следующим образом:

1. Получили ли они требуемый результат (программу / систему) (это может быть не тем, что они изначально указывали)? Это также включает аспекты функциональности и качества (ошибки, скорость и общий вид).
2. Получили ли они результат вовремя? Он появился до того, как ДЕЙСТВИТЕЛЬНО понадобился в срок?
3. Они заплатили столько, сколько ожидали, за результат? Время могло быть вовлечено в это? Также помните, что важна и точность сметы; слишком мало может быть так же плохо, как и слишком много. «Слишком много» очевидно. "Слишком мало" также означает, что вы неправильно оценили проект, и тот, кто финансировал вас, теперь имеет профицит бюджета, с которым они должны справиться (а в крупных организациях, если вы оставляете деньги на столе, это часто означает, что вы потеряете их в следующем году)

Re: Вывод №1) Отсутствие расписания выбивает №2 и, вероятно, также №3 (потому что время ресурсов тоже имеет свои затраты). Нет расписания = неограниченный бюджет (пока кто-то, контролирующий кошелек, не выяснит, что происходит). Если ваш проект подошел к концу, а пользователи получили то, что им нужно, то это успех. Но по тем же критериям измерения Duke Nukem Forever был успешным вплоть до 8 мая 2009 г.

. Кроме того, ответственные лица часто боятся признать, что проект был неудачным или даже частичным успехом, потому что он мог плохо отражаются на них и их будущей карьере. следовательно, даже если это на 500% больше бюджета и с опозданием на 3 года. Они всегда определяют это как успех.

Re: Вывод № 2) Самое главное, что у вас есть план. Методология - это просто общий язык в вашей организации. UML (Unified Modeling Language) - это просто набор инструментов для выражения вашего плана. Неважно, используете ли вы SCRUM, XP или просто POW (Обычный старый водопад), вам все равно нужно заниматься планированием, оно просто меняется, когда и как часто вы выполняете планирование. Если у вас нет расписания, о котором нужно беспокоиться, планирование (или не планирование) может происходить на лету; и переделка из-за отсутствия планов не имеет значения.

Re: Вывод № 3) Я считаю это утверждение ложным; потому что я знаю, что это неправда. Я' Мы видели разработчиков, участвующих в оценках со всевозможными требованиями (как в США, так и за их пределами). Вы, вероятно, видите здесь сегментацию ролей. «Мы не можем послать этого выродка Чарли пойти и встретиться с клиентом, послать Билла бакалавра, чтобы он собрал требования. Он не может делать Fizz-Buzz, но у него есть костюм-тройка».

В то же время, некоторые менеджеры придерживаются философии установления невыполнимых сроков для повышения производительности; и страх, что, если мы позволим рабочим говорить им, сколько времени на самом деле потребуется, они автоматически необоснованно завышают оценки. Они считают, что закон Паркинсона применим везде. Это неверно, поскольку оно предназначалось только для применения к бюрократии (например, правительству, и администрация в крупной корпорации) и никогда не подвергалась научным испытаниям. Это продолжается, потому что это забавно, а не потому, что это доказано.

Зачем вам нужны расписания, UML и т. Д.

Если только вы не участвуете в чудо-проекте, где у вас нет времени и бюджета ограничения, тогда да: вам нужен график, вам нужны требования, вам нужен план и т. д.

И даже если вы участвуете в одном из этих чудо-проектов, вы все равно рискуете, что кто-то наверху поумнет и отключит вас .

Однажды я работал с парнем, который определил успех как «Получу ли я деньги?» Ему платили за 100% его проектов, неудачных или нет, поэтому он считал это 100% -ным показателем успеха.

Как говорили другие, успех субъективен.

Такие вещи, как UML и управление проектами, работают только тогда, когда экосистема проекта поддерживает их. Если вы попытаетесь запихнуть концепции PM в глотку небольшой команде, вы можете, например, привести их к провалу.

Вероятно, существует ряд факторов, но меня не удивляет, что неструктурированные проекты могут быть успешными (и под этим я подразумеваю завершение и предоставление желаемой выгоды для бизнеса, а не только отправили что-то или дошли до того, что клиенту выставили счет).

Факторы, которые, как я полагаю, вы найдете общими для этих успешных проектов, следующие (один или несколько):

1) относительно небольшой размер (команды максимум из 10 человек в течение не более 12 месяцев)
2) сложившаяся и / или связанная команда
3) участники проекта с большим опытом работы в рассматриваемых областях бизнеса / технологий
4) задействованы умные, целеустремленные люди
5) реалистичные ожидания от руководства и клиентов

Все это может существовать без твердого планирования, использования UML или твердой методологии, и ИМХО будет иметь гораздо большее значение. Я полагаю, что любой разработчик, который работал в хаотичной, но благоприятной среде, вероятно, сможет придумать больше положительных историй, чем те, кто работал на структурированных, но политических рабочих местах.

И, конечно, если вы посмотрите на Стива МакКоннелла. список 12 основных ошибок проекта, по которым ИТ-проекты терпят неудачу ( http://www.stevemcconnell.com/ieeesoftware/bp05.htm - не научные, но, безусловно, вещи, которые будут правдой для большинства разработчиков) , только один или два из них действительно относятся к процессу. UML и лучшее расписание не улучшат рабочую среду, не решат проблемы сотрудников, заниматься политикой и нереальными требованиями и так далее.

Так почему же проекты могут быть успешными без этих вещей - потому что они важны, но не являются наиболее важными факторами.

если это правда, кто-то должен сказать ребятам из PRINCE2 упаковать его в

PRINCE2 был создан в результате исследования, показывающего, что большинство проектов терпят неудачу (неудача основана на: 1) не на время, 2) не в бюджет, 3) не в спецификацию

на стороне примечания, я не использую UML и обойдусь. главным образом потому, что UML не может быть передан клиентам, и не все программисты это знают. В пользовательских историях такой проблемы нет

- LM