Статья "Гибкий подход разработки ПО – Scrum" и белый шум

Алексей Кривицкий

Вот уже год, я отвечаю на комментарии к статье, которую опубликовал на developers.org.ua. По своей сути, комментарии часто такие:

Пробовали мы ваш Скрам. Не понравилось. Классика лучше.

Об отличиях классического и гибкого подхода мы с Натальей Трениной говорили 14 июля на SCRUM:open. В более сжатой форме будем говорить 25 июля на PM-labs. И будем говорить везде, где нас будут слушать, поскольку, считаем понимание этих отличий важным.

Классика решает много проблем, но и создает немало. Ниже привожу ответ на очередной комментарий к статье.

Классика руководства проектом конечно работает, если руководитель обладает умениями, навыками и талантами. Дело лишь в том, что такой подход может вести к следующим проблемам управления:

1. узкоспециализированных специалистов (это происходит постепенно, когда PM оптимизирует раздачу задач, так чтоб росла локальная продуктивность: люди делают схожие задачи тем, которые они делали раньше);
   
   
2. это в свою очередь приводит к мышлению в рабочей группе типа “я свое сделал…”, это не команда, со всеми вытекающими;
   
   
3. у PM-a растет число задач по микроменедженту своей группы, так как он является единственным человеком, который видит “всю картину”;
   
   
4. подключение новых людей становится задачей PM-a, текущие работники не заинтересованы в обучении новеньких – что им с того?
   
   
5. когда в итоге новых людей подключают, у PM-а работы только прибавляется;
   
   
6. в итоге PM (а это особенные люди) занимается задачами ниже своего уровня компетенции

Вместо этого PM мог бы заниматься:

• развитием продутка;
• формированием команды и устранением пряпятствий на её пути;
• высокоуправленческой функцией на уровне предприятия.
  и т.д.

Теперь о проблемах по задачам и прогрессу проекта:

1. поскольку члены рабочей группы работают над своими задача (частями функционала), размеры задач и темпы работы людей разняться, то какая-то часть фич оказывается сделана частично;
   
   
2. что такое частично сделанная работа (фича) – это вливания инвестиций, которые не вернулись;
   
   
3. эти фичи нельзя потестировать и, если их много, то проект оказывается в состоянии “мы на половине проекта” или “50% фич сделаны наполовину”;
   
   
4. это непрозрачно и рискованно для инвесторов, заказчиков, подрядчиков – всех заинтересованных сторон.

Это неуправляемый проект - Титаник.

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

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

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

Сама статья на ДОУ.