9 ошибок менеджера или почему задерживаются проекты 

Тема не новая. Почему-то все равно актуальная. Ведь причины, которые я перечислю, казалось бы, понятны опытным разработчикам и менеджерам как Ruby, так и PHP проектов. Отчего тогда часто (особенно в отрасли IT outsourcing) не удается избежать задержек в проекте на практике? Не бывает плохих исполнителей, бывают лишь сложные проекты и интересный, классический project management.

Если условно поделить проект на этапы (задания, таски), то причины задержки такой части проекта:

1. Task not prepared correctly. Задание описано таким образом, что позволяет разное понимание того, что нужно сделать. Ошибка менеджера.
2. Not enough data to prepare task. Задание просто не могло быть описано полностью, так как не хватало данных по проекту. И вместо того, чтобы разработать быстрый прототип, на основе которого потом нарастить функциональность (имея в запасе время), менеджер описал в задании полностью не то, что нужно заказчику, а свое видение, которое вовсе не shared vision с видением заказчика (ввиду чего у заказчика еще есть циклы feedbacks, а времени уже для этого не остается). Ошибка менеджера.
3. Urgent tasks. Задание не было сделано по причине того, что другие срочные задания не позволили этого. То есть, имело место неправильное планирование, неправильная расстановка приоритетов, недостаточно резервных ресурсов на случай срочных задний и форс-мажора, недостаточно воли, для того, чтобы придерживать другие задания срочные новые и не отвлекать команду. Если срочные задания имели достаточное основание, чтобы отложить задание, действия менеджера, конечно, оправданы, но тем не менее, задание задержено. Ошибка менеджера.
4. Feature requests. Задание не было сделано, потому что слишком поздно было добавлено. По причине того, что не было единого понимания результатов проекта (no shared vision) из-за плохого общения с заказчиком например. Или просто задание было добавлено, потому что заказчику приглянулась какая-то новая functionality. Такие случаи не должны считаться задержкой проекта теоритечески, но они задержививают проект в общем смысле. Ведь потом никто не вспомнит, что в середине года вы что-то для заказчика разрабатывали, через год все равно будут говорить, что делали проект 1.2 года, а не год. А если и удастся объяснить это заказчику (а именно это и должен напомнить, делать менеджер - общение), проект задержан по времени. Ошибка менеджера.
5. Curve hands or new to job. Задание было разработано с большим количеством брака (ошибок, багов) ввиду плохого качества исполнения, маленького запаса для доделок по времени. Т.е. не был правильно подобран исполнитель для задания, либо задание не было разбито на несколько для лучшего контроля качества, не был подключен технический директор для содействия в задании с таким риском. Ошибка менеджера.
6. Research type of work. Задание не может быть четко сформулировано по причине его исследовательского характера. т.е. нет оп ыта в такого рода заданиях, соответственно оценка затрат для выполнения задания затруднена, и зачастую меньше необходимого времени, и задание задерживается. Ошибка менеджера.
7. Наследование чужих результатов работы. Задание не сделано в срок, или возникающие доделки, циклы feedbackов задерживают выполнение задания по причине того, что работа ведется на основе наработок других исполнителей. Как правило из-за нехватки документации, низкого качества работы предыдущих исполнителей (которых обычно как раз меняют на вас поэтому), но задание задерживается уже под вашим руководством, поэтому это снова уже ваша ошибка как менеджера.
8. Не была применена декомпозиция в проекте. Задание задерживается потому, что оно очень большое. Хотя времени достаточно, как кажется сначала, и поэтому с исполнением задания никто не торопится, позже оказывается, что много “подводных камней”, и задание задерживается. Ошибка менеджера.
9. Conservative thinking, no brainstorming. Задание задерживается потому, что не были учтены советы технического директора или коллег менеджеров. Менеджер для исполения задачи решил пойти в разработке по простому пути, руководствуясь собственным опытом, не учитывая новых идей, новых рисков, мнения команды. Задание задерживается, потому что в конечном счете либо задание выходит из-под контроля менеджера (исполнители просто не могут смириться с вашим явно неправильным решением), или же риски и советы коллег по заданию были актуальны, но не восприняты вами. ошибка менеджера.

P.S. Информация подготовлена без использования каких-то статей, и публикация без ссылок на Татсофт не допускается. Интересно услышать мнения опытных разработчиков по данному списку из 9 пунктов , и быть может, дополнить список.