Больше нянек

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

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

Подобное случилось и со мной в совершенно абсурдном виде. Мы разрабатывали новый, с нуля созданный дизайн главной страницы Yahoo одной маленькой командой. Это был идеальный проект, мы небольшой группой проектировали базовую архитектуру страницы, и никто нам не мешал. Мы закончили проектирование, и готовы были приступить к разработке прототипа, как нам выделили восемь новых разработчиков. Более того, нам дали указания, чтобы эти разработчики тут же приступили к программированию новой страницы. Что было той еще задачей, ведь архитектуры в конечном виде еще не существовало! Но разработчиков нельзя оставлять без дела, их назначили на проект, значит им нужно дать задачу. Классическая проблема о курице и яйце.

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

Слишком большое количество разработчиков в команде может сильно усложнить проект. Конечно, они могут работать над независимыми друг от друга задачами, но, как правило, количество таких задач в любом проекте не так велико. Чем больше в проекте занято разработчиков, тем больше времени тратится не на разработку, а на планирование и организацию командной работы. Если вернуться к метафоре строительства дома, то нельзя строить второй этаж до того, как построишь первый. Большинство задач по разработке ПО выполняются строго по очереди, поэтому выделение дополнительного числа разработчиков никак не ускорит процесс разработки. Как говорил один из моих бывших коллег, сколько бы женщин у вас не было, ребенка родить раньше девяти месяцев не получится (на самом деле известная цитата из книги Фреда Брукса «Мифический человеко-месяц»).