Как развиваются процессы. Часть 3. Классовая борьба

Продолжение

Первая часть. Хаотическая разработка
Вторая часть. Проектная разработка

Классовая борьба
Итак, в компании появились две противоборствующие силы. Эти силы стараются отстоять свои интересы и, в соответствии с теорией классовой борьбы, начинают противоборство.

Этот конфликт постоянный и открытый. Например, любые попытки стабилизировать ситуацию со стороны разработки (например, наладить процесс управления изменениями) рассматриваются бизнесом как покушение на их интересы, поскольку оттягивают реализацию и затрудняют изменение требований.
Спор бизнеса и разработки

Дальше ситуация развивается в разных компаниях по разному.Все зависит от того, кто станет «правящим» классом. Может показаться странным, но не так уж часто бизнес выигрывает эту войну.

Определить победителя легко - нужно узнать что происходит при изменении требований или приоритетов.

Давайте немного пофантазируем.

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

Или даже так. Заказчик приходит к менеджеру проекта и взахлеб рассказывает ему, что вчера звонили аж из Майкрософта и теперь мы будем делать с ними партнерскую программу. Когда начинаем? Сейчас. Когда должно быть готово? Вчера. Что с уже начатым проектом? Тоже нужен. Что делать со сроками по другим проектам? Не меняются. Как жить? Изыскивать резервы!

Диктатура разработки

Что произойдет дальше? Ведь это сильно влияет на рамки проекта - а значит и на сроки и бюджет. Менеджер, разумеется, открывает регламент по управлению изменениями. Впрочем нет, он помнит его наизусть.После ряда процедур выпускает Запрос на Изменение, в котором подробно описывает изменение и оценку по трудозатрам, а также насколько изменится срок окончания проекта. В оценку трудозатрат включаются работы по изменению плана, требований, доработку документов архитектуры и дизайна, тестовых планов и сценариев. Это помимо само собой разумеющихся трудозатрат на разработку и тестирование. На круг выходит немаленькая сумма в часах. Специально назначенный комитет собирается и утверждает Запрос на Изменение. Менеджер проекта уведомляет заказчика о изменении сроков окончания проекта.

Для вас это звучит как фантастика?

Это мир Победившей Разработки, альтернативной реальности для большинства наших менеджеров проекта. Это мир классического водопада, о котором вы могли читать в веселых фельетонах евангелистов итеративной разработки и комиксах про Дилберта.

Как идет проектная работа в такой компании?

Начало проекта. Аналитик приносит на согласование техническое задание. Это толстый документ, полный унылых описаний. Заставить себя прочитать, а тем более вникнуть и покритиковать, практически никто из заказчиков не в состоянии. Самое ужасное, что после подписания документа способов повлиять на рамки проекта нет. Документ уйдет в разработку и результаты будут очень нескоро. Единственный способ уменьшить риск (заодно избавится от такой большой ответственности) - вовлечь в принятие решений как можно больше людей. Все они будут проводить комитеты и совещания, организовывать рабочие группы и проводить ревью документации. Старт проекта еще более затягивается.

Архитектор счастлив. Его никто не подгоняет. Он может придумать действительно гениальную архитектуру и потрясающе элегантный дизайн. Это на самом деле очень интересная задача, ведь просто делать очередную бизнес-систему скучно. Решение получается сложным, реализация требует времени, но ведь именно для таких моментов мы учились архитектурным паттернам, не так ли? Архитектор убежден, что ESB все равно понадобится, а к сервисно-ориентированной архитектуре надо готовится уже сейчас!

Сдача проекта - единственный шанс бизнеса дать бой разработке на своей территории. Систему они видят в первый раз и в таком виде принимать ее не хотят — она им категорически не нравится. В рамках приемки результата переписывается огромное количество кода, и даже в этом случае вталкивать систему в прод иногда приходится силой. Опытная эксплуатация — весьма болезненное время для разработчиков, поскольку в этот момент они сильнее всего соприкасаются с пользователями.

Впрочем, возможен и такой вариант:


Последний раунд. Победа разработки нокаутом

Никаких возможностей у бизнеса внести изменения просто нет. Только в следующий релиз.

Привелегии бизнеса

Мы познакомились с организацией, где разработка доминирует. А как выглядит компания, где правит бизнес?

Итак, произошли изменения. Менеджер проекта после встречи с заказчиком возвращается на место и дает новую вводную программистам. Он не очень верит в планы вообще и в MS Project в частности: они никогда для него не работали. Впрочем, план-график есть, но через месяц после начала проекта заглядывать в него перестают: он уже никак не соответствует реальности, а каждый раз переделывать нет времени. Сделать хороший прогноз окончания срока проекта не получается: для этого нужно точно знать не только рамки проекта, но и иметь какой-то дизайн системы. Он может быть и был когда-то, но постоянные изменения ничего от него не оставили.

Если уж начистоту, затюканный бизнесом менеджер проекта не всегда различает понятия дедлайна и прогноза срока окончания проекта!

Начинается проект также, как и в случае диктатуры разработки: фаза сбора требований, создание плана проекта. Затем лафа заканчивается и начинается Хаотическая разработка, со всеми присущими ей проблемами.

Типичный конфликт

Собственно, это и есть мир победившего Бизнеса.

Проблемы
Привелегии бизнеса
Диктатура разработки
Обещанные сроки
Очень оптимистичные, так как часто определяются бизнесом, а не возможностями разработки.
Во время проекта сроки не прогнозируются. Провал сроков происходит неожиданно.
Реальные, так как разработка закладывает время на риски. Сроки большие и не устраивают бизнес.
Реальные сроки
Задерживаются из-за постоянных изменений скоупа и приоритетов
Задерживаются при изменении требований - то есть практически всегда
Качество
Низкое внутренне качество, так как времени тестировать и исправлять дефекты нет
Низкое качество с точки зрения заказчика, продукт неудобен
Приемка у заказчика
Болезненная из-за отсутствия критериев приемки
Болезненная из-за плохой обратной связи по ходу проекта

От чего зависит исход битвы бизнеса и разработки?

Факторы, мне кажется, такие:

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

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

Роль личности. Харизматичный руководитель IT с большим авторитетом вполне способен склонить на свою сторону чашу весов. И наоборот, слабое руководство разработкой, неспособное постоять за свои права сдает позиции без боя.

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

Tags: