Немного депрессивное название на самом деле вызвано тем что статья написана как пересказ двух студенческих докладов предмета "Управление проектами" в ТТУ (Karin Rava, IDU3390 - Infos?steemi projekti juhtimine). Коммандная разработка требует от человека много качеств и Patrick Lencioni на этой основе вывел некоторые проблемы, которые я выделил болёё чётко. Также я привожу список причин по мнению исследования Coverdale Organization (Cushing, 2002)

Провал комманды

1. Безразличие к результату.
   Эта проблема часто встречается при исправлении очередной мелкой коммерческой CMS-ки или огромного хаотического кода, который никогда не увидит белого света. Идя от обратного - комманду можно мотивировать славой за популярный стартап, посещаемость и тд.
2. Избежание обязанностей и работы.
   Из личного опыта могу сказать, что когда человека мотивирует только время за которое ему платят, то "лишняя работа" за других работяг может раздражать. Например если дизайнер пришёл с полиграфии и в CSS ни бум бум. Избержание обязанностей из чисто бюрократического контекста может вылится например в то, что проект в итоге никто реально не тестирует.
3. Малая осведомлённость.
   Попав в огромную контору с кучей продуктов, технологий, людей очень легко потеряться и не получать нужную информацию. Даже если всё налажено с точки зрения руководителя, работники часто не имеют представления что делают коллеги.
4. Страх конфликта и избежание переговоров.
   Желание спрятаться в свою коморку что-бы никто не беспокоил - типично для работников побывавших в огромных залах, где все шумят и мешают работать. А если к этому ещё прибавить и личные качества, то человек может банально расстраиваться за просроченные deadline-ы.
5. Отсутсвие доверия.
   Надо сказать что это не столько доверие в плане того что человек не украдёт ничего из конторы или не напьётся после получки. Это может быть перепроверка кода из-за сомнения в его качестве, прослушка IM-болтовни со стороны начальства. Так и наоборот - работник видит что начальника волнуют только деньги, поэтому он перестаёт заботится о качестве своей работы, имидже в комманде. Типично для маленьких фирм

Провалы руководства

1. Плохое планирование.
   Как только управлением проектами начинают заниматься кодеры, то они как правило считают что планирование и анализ - пустая трата времени на рисование ненужных CASE-схем, оформление бумажной волокиты с требованиями к проекту и тестами, подписанием договоров и тд... Всё это выливается либо в "Agile dev", либо в следующие за этим этапом проблемы.
2. Неясные требования и цели.
   Очень типично когда управляющий проектом плевать хотел на программера и не достаточно разобрался чего хочет клиент. "Сделать модуль статистики" без чётких рамок того что в нём должно быть представляет собой угрозу - программист может нафантазировать то, чего клиенту не надо было вовсе.
3. Цель меняется во время проекта.
   Несомненно в процессе разработки что-то может измениться, но когда этих деталей уйма, а разработчик уже занят другими проектами, то это может серъёзно отрывать его и действовать на нервы. Также часто бывает, что проект делается годами, а когда заканчивается то уже никому не нужен и устарел.
4. Неправильно оцененное время или ресурс.
   Копать от утра и до обеда. Это страх разработчиков - инновация. Например создание проекта с неизвестными библиотеками или не понятными доселе теоретическим материалом всегда рискованно. Как правило прибавляется львиная доля время про-запас, который всё равно тратится под чистую.
5. Прерывание общения
   Прерывания в разработке на доработку старых проектов, увольнения работников, отсутсвие докладов, согласований и совещаний.