Сегодня мы рассмотрим один из лучших инструментов уничтожения проектов — разработку комитетом. Прелесть этого подхода в том, что вам ничего и делать не придётся для того, чтобы развалить проект.
“Как же так?” — спросите вы. Ведь в предыдущие разы, чтобы отправить работу под откос, вам приходилось нагнетать истерию вымышленными дедлайнами и приписками “Срочно!”, отчитывать случайных людей за случайные действия… А тут прямо всё само?
Почти. Вам достаточно лишь позвать своих коллег, и они закопают проект за вас!
Что же это за анти-паттерн
Разработка комитетом (design by committee) — уничижительная характеристика стиля проектирования и полученного результата, когда группа участников объединяется для создания чего-либо (обычно технического устройства или стандарта) при плохом или некомпетентном руководстве. Отличительными чертами «разработанного комитетом» проекта являются излишняя сложность, неполнота, логические противоречия, банальность и отсутствие целостной структуры.
Как использовать этот анти-паттерн
Разработку комитетом лучше всего начать с назначения безынициативного, безыдейного или просто неопытного сотрудника “ответственным”. Обычно это инициатор идеи, которую вы хотите закопать. Так вы сможете заодно устроить “Охоту на ведьм”, а впоследствии и подтвердить свой статус “Рыцаря в сияющих доспехах”.
Первое (и последнее, на самом деле), что нужно сделать “ответственному” — это составить техническое задание или спецификацию и утвердить со всеми “заинтересованными людьми”.
Вот тут то и кроется скрытое коварство.
Первый круг ада — собрать со всех список хотелок. Казалось бы — разослал по почте, получил результат. Но нет, ответа в большинстве случаев не последует: свободные сотрудники на то и свободные, что ничего не делают, а занятым — как всегда, некогда.
Поэтому придётся брать каждого “за пуговицу” и выдавливать технические требования.
Второй круг ада — согласовать набор неясных и противоречивых требований. Задача воистину сравнимая с чисткой авгиевых конюшен. Так как каждый видит проект со своей стороны, каждый хочет своё. В результате попыток удовлетворить всех, ТЗ превращается в огнедышащую химеру с over 9000 уровней абстракции и случаев использования. Будет весело заставить “ответственного” сделать схему полученного процесса, чтобы полюбоваться на старый логотип хабрахабра.
Казалось бы всё...
Но тут подстерегает третий круг ада — собрания для согласования полученного технического задания. Начнём с того, что получившуюся кипу бумаги никто не осилит, поэтому первое “заседание” будет потрачено на объяснение общей концепции. Ко второму — исполнитель догадается сделать реферат сего документа. Но и тут нежданчик — найдутся эксперты по всему и заявят, что всё сделано неправильно, а надо вот так.
Ух, вроде получили ТЗ. Осталось лишь реализовать ЭТО… Получив подобное противоречивое и запутанное ТЗ, разработчик если и не уйдёт в запой, то неприменно погрустнеет надолго. После того, как он даст документу проникнуть в свой мозг, появляется четвёртый круг ада — полученный документ мало того, что несовместим, так ещё и нереализуем. По крайней мере, в ближайшие 5 лет… Нужно выкинуть 90% хотелок. Возвращаемся к первому кругу, с той только оговоркой, что “заинтересованные лица” будут ещё менее готовы к диалогу — они уже “всё сказали”.
Возможные опасности
“Ответственный” может начать рассказывать окружающим о таких странных вещах как “Минимально ценный продукт” (MVP), о первой версии, об итеративной разработке. Негодяй! — Хочет таки выкрутиться.
Но не тут то было! Собираем совещание по обсуждению “важных” возможностей. А ведь для каждого члена комитета свои фичи важнее… И начинается “перетягивание одеяла”.
Ну и требуем план по разработки всего продукта перед началом первой итерации — нам же надо представлять, что происходит!
Также при использовании этого анти-паттерна будет уместно применить “управление грибами”. Но об этом — в другой статье.