×
Фото Анти-паттерн «Разработка комитетом»

Анти-паттерн «Разработка комитетом»

Сегодня мы рассмотрим один из лучших инструментов уничтожения проектов — разработку комитетом. Прелесть этого подхода в том, что вам ничего и делать не придётся для того, чтобы развалить проект.

Сегодня мы рассмотрим один из лучших инструментов уничтожения проектов — разработку комитетом. Прелесть этого подхода в том, что вам ничего и делать не придётся для того, чтобы развалить проект.

“Как же так?” — спросите вы. Ведь в предыдущие разы, чтобы отправить работу под откос, вам приходилось нагнетать истерию вымышленными дедлайнами и приписками “Срочно!”, отчитывать случайных людей за случайные действия… А тут прямо всё само?

Почти. Вам достаточно лишь позвать своих коллег, и они закопают проект за вас!

Что же это за анти-паттерн

Разработка комитетом (design by committee) — уничижительная характеристика стиля проектирования и полученного результата, когда группа участников объединяется для создания чего-либо (обычно технического устройства или стандарта) при плохом или некомпетентном руководстве. Отличительными чертами «разработанного комитетом» проекта являются излишняя сложность, неполнота, логические противоречия, банальность и отсутствие целостной структуры.

Как использовать этот анти-паттерн

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

Первое (и последнее, на самом деле), что нужно сделать “ответственному” — это составить техническое задание или спецификацию и утвердить со всеми “заинтересованными людьми”.

Вот тут то и кроется скрытое коварство.

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

Поэтому придётся брать каждого “за пуговицу” и выдавливать технические требования.

Второй круг ада — согласовать набор неясных и противоречивых требований. Задача воистину сравнимая с чисткой авгиевых конюшен. Так как каждый видит проект со своей стороны, каждый хочет своё. В результате попыток удовлетворить всех, ТЗ превращается в огнедышащую химеру с over 9000 уровней абстракции и случаев использования. Будет весело заставить “ответственного” сделать схему полученного процесса, чтобы полюбоваться на старый логотип хабрахабра.

Казалось бы всё...

Но тут подстерегает третий круг ада — собрания для согласования полученного технического задания. Начнём с того, что получившуюся кипу бумаги никто не осилит, поэтому первое “заседание” будет потрачено на объяснение общей концепции. Ко второму — исполнитель догадается сделать реферат сего документа. Но и тут нежданчик — найдутся эксперты по всему и заявят, что всё сделано неправильно, а надо вот так.

Ух, вроде получили ТЗ. Осталось лишь реализовать ЭТО… Получив подобное противоречивое и запутанное ТЗ, разработчик если и не уйдёт в запой, то неприменно погрустнеет надолго. После того, как он даст документу проникнуть в свой мозг, появляется четвёртый круг ада — полученный документ мало того, что несовместим, так ещё и нереализуем. По крайней мере, в ближайшие 5 лет… Нужно выкинуть 90% хотелок. Возвращаемся к первому кругу, с той только оговоркой, что “заинтересованные лица” будут ещё менее готовы к диалогу — они уже “всё сказали”.

Возможные опасности

“Ответственный” может начать рассказывать окружающим о таких странных вещах как “Минимально ценный продукт” (MVP), о первой версии, об итеративной разработке. Негодяй! — Хочет таки выкрутиться.

Но не тут то было! Собираем совещание по обсуждению “важных” возможностей. А ведь для каждого члена комитета свои фичи важнее… И начинается “перетягивание одеяла”.

Ну и требуем план по разработки всего продукта перед началом первой итерации — нам же надо представлять, что происходит!

Также при использовании этого анти-паттерна будет уместно применить “управление грибами”. Но об этом — в другой статье.

Будь первым – оставь комментарий!

Фото Компьютерщики / IT Crowd. О выживании IT-шников в бетонных джунглях
Предыдущая запись:
Компьютерщики / IT Crowd. О выживании IT-шников в бетонных джунглях
Фото В поисках практики. История одной девушки
Следующая запись:
В поисках практики. История одной девушки