По-моему мнению в статье “Боссы-кровососы в контексте …” не была раскрыта причина распада самоуправляемых команд, а причина именно в низкой скорости распространения требований к продукту, и непонимании того, что руководитель всегда является частью команды.
Изменив подход к планированию работ проектно-конструкторского отдела при разработке нового продукта можно повысить скорость с которой информация распространяется, что для проекта намного важнее чем просто обладание информацией.
Классическая схема
В классической схеме процесс планирования работ и процесс разработки имеют четкие временные границы. Обычно процесс планирования ведется до разработки. По окончании планирования на каждый месяц появляется “сетевой график работ” по которому начинается процесс разработки изделия проектно-конструкторским отделом. Видов сетевых графиков существует не так много — это в основном PERT и GANTT. Сроки в сетевом графике как правило декларативные и ничем не подкреплены, что создает некоторый мнимый простор при выполнении работ в процессе разработки проектно-конструкторским отделом. На самом деле сроки в сетевом графике согласованы с заказчиком и исполнитель вынужден соблюдать их, иначе срыв ключевых сроков разработки может грозить закрытием проекта в целом. Разработчиков в классической схеме никто не спрашивает и руководитель проекта просто спускает сроки выполнения по каждой работе до разработчиков.
Со стороны выглядит это так будто руководитель проекта раздает всем по своеобразной удочке (инструмент) и говорит: “Ловите пока карася. В конце месяца прийду проверю сколько наловили. Нужно наловить 2 тонны”. В течении месяца руководитель проекта проводит совещания, на которых ему отчитываются кто, сколько тонн и какого вида рыбы выловил. В конце месяца руководителю проекта спускают новый “уточненный” сетевой график работы, по которому заказчик хочет ловить не карася, а к примеру ”кабачок”. У “мудрого руководителя проекта” появляется шанс получить себе премию для покупки новой плазмы или нового современного внедорожника. Если ему повезет и будет хоть один, кто поймает “рыбу-кабачок”, тогда он заплатит премию себе и удачливому рыболову, а другим назначит штраф.
Такой режим работы вынуждает руководителя проекта брать часть задач по разработке на себя, а разработчики такого проекта постоянно задерживаются на работе, а иногда им приходится выходить в выходные дни, чтобы успеть в срок разработать новые интерфейсы взаимодействия пользователей с продуктом. Все это, как уже упоминалось мною выше, усугубляется еще и тем, что требования к конечному продукту могут поменяться, и тогда сетевой график корректируется, причём корректировка производится таким образом, чтобы не задеть ключевые сроки в проекте.
В такой схеме вся работа зависит от человеческого фактора, который играет ключевую роль. Человеческий фактор можно свести к минимуму путем введения автоматизированных систем планирования и разработки, что в сущности и делают многие внедряя у себя на предприятия системы CAD, CAM, CAE, PDM, ERP, CRM, PLM и т.п.
Однако базис в виде классической схемы, когда планирование и разработка имеют четкие временные границы остается неизменным. В результате разработчикам приходится поддерживать в актуальном состоянии многочисленные редакции программного продукта и документацию в каждой автоматизированной системе, а также постоянно поддерживать интеграцию систем, что в современных конкурентных условиях IT-рынка весьма проблематично. Заказчику в конечном итоге нужно лишь одно — это готовый продукт или налаженное производство. В классической схеме перечень документации разрабатываемый исполнителем всегда будет избыточен, так как ни у заказчика, ни у исполнителя нет полной уверенности в том что цель будет достигнута, а значит нужно по максимуму документировать процесс, чтобы выявить на кого “свалить ответственность” за срыв сроков. Даже если конечная цель изначально будет сформулирована, как конкретная (Specific), измеримая (Measurable), достижимая (Attainable), реалистичная (Realistic) и ограниченная во времени (Time-based), в итоге после первого дополнительного требования у исполнителя может пропасть уверенность в достижимости конечной цели, а следовательно будет срыв сроков и закрытие проекта.
Как же тогда сделать так чтобы заказчик не менял требования слишком часто, а исполнитель выполнил все требования заказчика в срок?
В классической схеме процессом планирования занимается опытный эксперт в области планирования проектов, который на основе своего опыта определяет перечень задач и их сроки. Я считаю, что всё это можно было бы и не делать опытному эксперту, потому как сроки выполнения задач, а также перечень задач необходимых для выполнения может определить и сама команда. Для этого эксперту со стороны заказчика нужно максимально подробно описать продукт в своем ТЗ и конечный срок к которому нужен продукт, и всё! Команда же под руководством руководителя проекта может сама провести планирование работ, выявить подводные камни, произвести декомпозицию задач, короче всю ту работу, что выполняет опытнейший эксперт.
“Проблема” состоит в том, что в этом случае каждый член команды знает конечную цель, она прозрачна и в каждый момент времени известно на сколько команда далека от неё. “Мудрый руководитель проекта” не сможет включить в эту цель еще и свою мегацель: “покупка современного внедорожника”. Для того, чтобы ему 100% успешно достичь своей мегацели ему нужно разделить процессы планирования и разработки, а списки задач выдавать порционно по мере возникновения “проблем”. В этом случае задача руководителя проекта максимально отвести внимание команды от конечной цели проекта, и сфокусировать их внимание на решении точно в срок конкретных работ сетевого графика. Другими словами: “завалить команду рутинной работой”.
Принципиально иная схема работы — это схема работы с использованием гибких методологий разработки, где главным принципом является:
частые непрерывные поставки продукта ценного для заказчика.
Достичь этого позволяет в первую очередь прозрачность процесса планирования, когда каждый член команды знает конечную цель и участвует в формировании пула задач на следующие 1-4 недели, по окончании которых заказчик увидит первую версию реализации продукта с новой функциональностью. Обязанность руководителя проекта получить одобрение у заказчика или просто поставить его в известность по версии продукта с новой функциональностью, которая будет готова после завершения итерации. Все дополнительные требования поступающие от заказчика должны быть учтены при планировании командой пула задач в следующих итерациях.
Для того, чтобы не сбиться с пути достижения конечной цели команда каждый день собирается для проведения 15-минутных митингов, на которых каждый член команды отвечает на три вопроса:
- Что было сделано с предыдущего митинга?
- Что будет сделано к следующему митингу?
- Какие есть проблемы?
В случае, когда планирование ведется отдельно от разработки ответ на второй вопрос дает руководитель проекта, впрочем как и ответ на третий.
В конце каждой итерации (спринта) команда проводит демонстрацию продукта с новой функциональностью заказчику. После каждой демонстрации команда собирается отдельно от заказчика для проведения ретроспективы. Методик проведения ретроспектив масса, хочется отметить ретроспективу в стиле “PLUS/DELTA”, в которой каждый член команды высказывает 10 положительных моментов (PLUS) и десять моментов, которые заставили команду отклониться (DELTA) от достижения намеченной цели.
В схеме работы с использованием гибких методик разработки автоматизированные системы играют ключевую роль, позволяя получать по окончании итерации продукт с максимально проработанным новым функционалом. После каждой итерации продукт можно отправлять на технологическую проработку в ERP- или CRM- системах с целью дальнейшего запуска производства прототипа продукта для испытаний в условиях максимально приближенных к реальным. Таким образом, после каждой итерации происходит уточнение программного продукта и наращивание новых функциональных требований. Сами клиенты уже на этапе технологической проработки или пилотного проекта через обратную связь в CRM- системе выскажут требования, о которых вы даже и не подумали бы. Главное вовремя донести эти требования до разработчиков, а не скрывать их у себя в чертогах разума, как это иногда делают “Мудрые руководители проекта”.
Сделаем выводы
Попытки построить процесс разработки по классической схеме с использованием гибких методологий обычно терпят фиаско, и видя это многие руководители проектов в угоду своих “мегацелей” или просто автоматически следуя основополагающему принципу “разделяй и властвуй” отказываются от применения современных знаний управления проектами на практике.
