Множество проектов разработки программного обеспечения проваливаются исключительно благодаря плохому управлению. Следующий список, по моему мнению, содержит 5 самых распространенных и опасных ошибок, совершаемых менеджерами в области разработки программного обеспечения.
1. Вера в то, что производительность, в основном, определяется количеством человек и часами рабочего времени
Производительность — современный аналог философского камня. Каждый менеджер проектов пытается найти его, применяя весьма простую алхимию: чем больше разработчиков и чем больше рабочих часов — тем лучше.
К несчастью, этот подход бредовый, он абсолютно не научен. Существует множество исследований, которые доказывают, что производительность может быть даже отрицательной при использовании этого незатейливого принципа.
Самый серьезный источник, который я могу привести в качестве ссылки — «Мифический человеко-месяц». Пожалуй, самая важная книга о разработке программного обеспечения за последние 20 лет (которую, к несчастью, чаще читают разработчики, а не менеджеры проектов). Что же касается статей в Интернет, я бы рекомендовал «Законы продуктивности — 8 экспериментов, которые вам не стоило бы повторять». Я настоятельно рекомендую вам отправить её каждому менеджеру проектов, которому, как вы считаете, эта статья могла бы пригодиться.
Очевидно, вопрос стоит так: что же улучшает производительность? Ну, пока я не могу ответить абсолютно точно (а если бы мог, то был бы уже чертовски богат!). На мой взгляд, производительность сильно зависит от двух факторов: мотивации сотрудников и лидерских способностей руководителя. То есть, желания двигаться вперед и наличия человека, способного показать лучшую дорогу.
Менеджеры проектов должны быть уверены, что клиенты понимают, что и когда будет готово.
Одна из самых часто повторяющихся ситуаций: становится понятно, что сроки не будут соблюдены, и нужно бы поговорить с клиентом. Что же происходит чаще всего? Клиент узнаёт об этом, когда сроки уже сорваны, потому что менеджер думал, что эти отклонения могут быть скомпенсированы, или просто боится расстроить клиента. Клиент узнает о проблеме тогда, когда уже нет никаких вариантов её решения. То, что могло бы быть пустяковой или не такой уж и важной проблемой на ранней стадии и что можно было бы решить изменением целей или сроков проекта, становится серьезной проблемой, зачастую ставя под угрозу судьбу всего проекта.
Менеджер Проектов должен мыслить шире разработчиков, но это не значит, что он не должен их слушать.
В разработке программного обеспечения, программисты, обычно, — единственный источник производительности, и поэтому нет ничего важнее того, чтобы обеспечить их всем необходимым для выполнения их работы.
К несчастью, многие менеджеры проектов слишком сфокусированы на датах, собраниях и сроках, что, конечно, иногда хорошо, поскольку заставляет проект двигаться вперед, но очень часто за всем этим теряется связь с разработчиками, что вызывает проблемы производительности команды, технического долга, низкого качества продукта и т.п.
Разработка программного обеспечения требует творческого подхода и проактивности. И это именно те два качества, которые убивают поборники повсеместного контроля (control freaks).
Контроль особо любим теми менеджерами проектов, которые до сих пор считают, что все требования к продукту вместе с техническими спецификациями и графиком работ могут быть определены и зафиксированы еще в самом начале проекта.
Делегирование решений, в свою очередь, делает разработчиков лучше и, обычно, является краеугольным камнем отличного продукта.
Одна из причин, почему менеджеры проектов получают больше денег, чем разработчики, это то, что забота менеджера проектов — гарантировать, что всё идет как должно. Часто это требует принятия весьма непростых решений, например, уволить кого-нибудь, нанять нового человека или объявить выговор.
Менеджеры проектов, которые c трудом принимают важные решения, предают свою команду. Задержки с тяжелыми, но важными решениями обернутся суровыми последствиями в будущем.
1. Вера в то, что производительность, в основном, определяется количеством человек и часами рабочего времени
Производительность — современный аналог философского камня. Каждый менеджер проектов пытается найти его, применяя весьма простую алхимию: чем больше разработчиков и чем больше рабочих часов — тем лучше.
К несчастью, этот подход бредовый, он абсолютно не научен. Существует множество исследований, которые доказывают, что производительность может быть даже отрицательной при использовании этого незатейливого принципа.
Самый серьезный источник, который я могу привести в качестве ссылки — «Мифический человеко-месяц». Пожалуй, самая важная книга о разработке программного обеспечения за последние 20 лет (которую, к несчастью, чаще читают разработчики, а не менеджеры проектов). Что же касается статей в Интернет, я бы рекомендовал «Законы продуктивности — 8 экспериментов, которые вам не стоило бы повторять». Я настоятельно рекомендую вам отправить её каждому менеджеру проектов, которому, как вы считаете, эта статья могла бы пригодиться.
Очевидно, вопрос стоит так: что же улучшает производительность? Ну, пока я не могу ответить абсолютно точно (а если бы мог, то был бы уже чертовски богат!). На мой взгляд, производительность сильно зависит от двух факторов: мотивации сотрудников и лидерских способностей руководителя. То есть, желания двигаться вперед и наличия человека, способного показать лучшую дорогу.
2. Отсутствие управления ожиданиями
Менеджеры проектов должны быть уверены, что клиенты понимают, что и когда будет готово.
Одна из самых часто повторяющихся ситуаций: становится понятно, что сроки не будут соблюдены, и нужно бы поговорить с клиентом. Что же происходит чаще всего? Клиент узнаёт об этом, когда сроки уже сорваны, потому что менеджер думал, что эти отклонения могут быть скомпенсированы, или просто боится расстроить клиента. Клиент узнает о проблеме тогда, когда уже нет никаких вариантов её решения. То, что могло бы быть пустяковой или не такой уж и важной проблемой на ранней стадии и что можно было бы решить изменением целей или сроков проекта, становится серьезной проблемой, зачастую ставя под угрозу судьбу всего проекта.
3. Игнорирование информации от разработчиков
Менеджер Проектов должен мыслить шире разработчиков, но это не значит, что он не должен их слушать.
В разработке программного обеспечения, программисты, обычно, — единственный источник производительности, и поэтому нет ничего важнее того, чтобы обеспечить их всем необходимым для выполнения их работы.
К несчастью, многие менеджеры проектов слишком сфокусированы на датах, собраниях и сроках, что, конечно, иногда хорошо, поскольку заставляет проект двигаться вперед, но очень часто за всем этим теряется связь с разработчиками, что вызывает проблемы производительности команды, технического долга, низкого качества продукта и т.п.
4. Контроль вместо делегирования
Разработка программного обеспечения требует творческого подхода и проактивности. И это именно те два качества, которые убивают поборники повсеместного контроля (control freaks).
Контроль особо любим теми менеджерами проектов, которые до сих пор считают, что все требования к продукту вместе с техническими спецификациями и графиком работ могут быть определены и зафиксированы еще в самом начале проекта.
Делегирование решений, в свою очередь, делает разработчиков лучше и, обычно, является краеугольным камнем отличного продукта.
5. Боязнь принимать решения
Одна из причин, почему менеджеры проектов получают больше денег, чем разработчики, это то, что забота менеджера проектов — гарантировать, что всё идет как должно. Часто это требует принятия весьма непростых решений, например, уволить кого-нибудь, нанять нового человека или объявить выговор.
Менеджеры проектов, которые c трудом принимают важные решения, предают свою команду. Задержки с тяжелыми, но важными решениями обернутся суровыми последствиями в будущем.