От провала проекта гибкие методологии не спасут

– У нас не получится уложиться в сроки!
– Примените Agile!
– Без достаточного количества людей он нам не поможет!
– Тогда придумайте другое умное слово!

Многие люди связывают провал проекта с выбором методологии разработки, вот выбрали бы Scrum/Agile/DevOps то все было бы хорошо. Скажу честно – такие люди ничего не понимают в разработке программного обеспечения.

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

На сегодняшний день существует более десятка методологий, но ни одна из них не дает гарантии успеха. Выбор методологии, должен быть первым что вы будете делать при начале нового проекта. В основном выбор зависит от разрабатываемого продукта и людей которые будут участвовать в разработке. Главный принцип обеспечения производительности гласит:

Модель процесса должна подстраиваться под команду, а не команда под модель процесса.

Продукт

Предположим что мы разрабатываем программное обеспечение для управления космическим кораблем или систему управления водоснабжения. Все требования заранее известны, есть обширная техническая документация продукта, существуют жесткие требования которые должны быть соблюдены и т.д. Неудивительно, что в таких проектах применяются методологии каскадной разработки или проверенный временем “водопад”.

Совершенно другого подхода требует разработка современного веб-сервиса, когда в самом начале у нас есть только нечеткие требования и они могут постоянно меняться. Тут широко разрекламированные Scrum/Agile и прочие “гибкие” методологии отлично приходят на помощь. Их применение в данном случае оправдано тем, что можно быстро получить обратную связь в условиях быстроменяющегося внешнего мира.

Сказанное выше можно спроецировать и на размер разрабатываемого продукта. Ведь совершенно разные процессы должны применяться в проектах, в которых участвует 10 человек и 1000 человек.

Люди

Команда студентов и команда высококлассных специалистов требуют разного подхода в организации рабочего процессса.

Я продолжаю считать, что Scrum и прочие Agile-подобные методологии были созданы для тех, кто просто не в состоянии самостоятельно работать (но хочет получить ощущение самостоятельности). Я выделил несколько типов команд для себя в зависимости от которых можно выстраивать процесс работы внутри:

• Профессионалы – каждый знает свое дело и как нужно работать. Могут смело взять ответственность за результат на себя. Таким не важно какая методология будет использоваться, она в принципе не нужна, тем более навязанная сверху. Зачастую не требуется и менеджер как таковой, посколько они умеют работать самостоятельно без постоянного контроля и с выдающимся результатом. Менеджер выступать может только щитом от клиентов и бизнеса.
• Бородатые программисты – достаточно опытные специалистов, но которые требуют периодического контроля и поддержки, четко прописанные формулировки в задачах зачастую не требуются.
• Зеленые новички – требуют постоянного контроля, поддержки в поиске решения.

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

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

Многие молодые менеджеры проектов с которыми я общался записывают себе в достижения, что они являются главным фактором успеха продукта, а без них все бы пошло ко дну. Управленцы, остановитесь! Успех проекта – не в действиях руководителя, не в процессе с помощью которого он создавался. Успех – это команда которая работала над проектом.

Как писал Том Де Марко в “Deadline. Роман об управлении проектами”, управление проектами – это управление людьми, иначе – это административная ерундистика.