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

Продолжение. Начало здесь: http://urazbaev.ru/kak-razvivaiutsia-protsessy-chast-1-khaoticheskaia-razrabotka

Проектная разработка

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

Руководитель разработки пытается как-то стабилизировать ситуацию. Надо понимать, что с его точки зрения ситуация выглядит следующим образом.

Заказчики приходят к нему, требуют рабочую силу и просят назвать дату. Руководитель отдела рассчитывает примерную дату исходя из смутно описанных запросов пользователей, выдает программиста или нескольких программистов. По ходу проекта выясняется, что от первоначально описанных требований ничего не осталось, программист занимается уже совсем другой системой, размеры которой намного больше. Очень часто ему приходится переделывать, иногда по несколько раз, потому что пользователь меняет свои решения. Сроки начинают плыть, а виновным оказывается отдел разработки и лично его руководитель, как нижнее звено в иерархии ответственности или, проще говоря, по принципу "я начальник, ты дурак".

Руководитель, разумеется, себя виновным не считает и начинает «крестовый поход» против заказчиков. От руководства IT одной крупной компании я как-то слышал следующее: "Дайте нам такую методологию, которая позволит отбиваться от запросов пользователей".

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

Документирование требований
Главный враг - изменение требований. Больше всего разработчиков раздражает легкомыслие бизнеса - они легко отказываются от своих слов, не помнят, что требования поменялись, утверждают, что они «именно это и имели ввиду, а вы сами напутали».

Требования в письменном виде позволяют зафиксировать обязательства заказчиков. Теперь они никуда не денутся - радуются разработчики.

Поскольку навыков программистов часто не хватает, создание требований либо перекладывается на бизнес-пользователей («не будем делать, пока не предоставите требований в письменном виде»), либо в отделе появляются специальные люди - аналитики. Они отвечают за сбор и документирование требований.

Проекты и проектные команды
Хаосом нужно управлять. Новому заказчику не просто выдают человека, а стартуют проект, рамки которого очерчиваются описанными требованиями. Сотрудники (теперь они называются ресурсами) выделяются из общего пула ресурсов и назначаются на проект. Так появляются проектные команды.

У проекта явным образом появляются фазы. Как минимум, фаза сбора требований и фаза приемки у заказчика.

Часто отдельно выделяется команда поддержки с одной или несколькими линиями. Это позволяет контролировать объем работ по поддержке и снизить постоянные отвлечения программистов.

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

Требования меняются, заказчики не знают чего хотят, разработчиков на имеющийся объем задач мало, кодовая база в ужасном состоянии. Все эти трудности подстерегают менеджера проекта.

Его главная задача - «сдать проект». Он должен быть закончен, и по возможности в срок и в рамках бюджета. Это практически единственное мерило результативности работы менеджера проекта.

Технологический стек
Технологический стек унифицируется. Отдел выбирает какой-то разумно очерченный набор технологий и старается его придерживаться. Например, .NET или Java.

Архитектура и дизайн
Часто отдельно выделяется фаза архитектуры и дизайна. Появляется должность архитектора или проектировщика. Это позволяет как-то контролировать качество итогового продукта.

Архитекторы больше всех заинтересованы в наличии качественных требований. Они могут провести анализ и выбрать правильную и продуманную архитектуру.

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

Тестирование
Если проблема качества принимает угрожающие масштабы, в отделе появляются выделенные тестировщики. Эти веселые ребята очень дружны между собой и довольно настороженно относятся к программистам. У них часто свой собственный менеджер, который их набирает и воспитывает.

Соблазн сделать ответственным за качество систем тест-менеджера очень большой. Если руководитель не сможет ему противостоять, тестирование становится независимой службой, со своей отчетностью и не подчиняется напрямую менеджеру проекта.

Итог
Большая часть проблем решается. Упор на создание и согласование требований заказчикам не нравится, но рано или поздно они привыкают писать и согласовывать документы. Разработка стабилизируется, уровень хаоса падает. Команда разработки изолируется от заказчика слоем из менеджера проекта и, отчасти, аналитиков.

Благодаря этому уровень демотивации сотрудников снижается. Наступает эра относительного благоденствия отдела разработки.

Кризис проектной разработки

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

Требования фиксируются заранее в документации. После этого команда возвращается к заказчику в лучшем случае с наполовину готовым решением. Обратной связи недостаточно и итоговый результат часто является шоком для заказчика. "Это то, что мы просили, но это не то, что нам нужно" - вот что часто можно услышать.

Дальше сценария развития ситуации на самом деле два. Мы рассмотрим полярные варианты, в реальности получается что-то промежуточное между ними.

К настоящему моменту формируется две силы: бизнес и разработка.

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

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

Об этом мы поговорим в следующий раз.

Tags: