Пять простых способов провалить проект

2013-12-24

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

Например, в 2004 г. я посетил одну из конференций, которые для разработчиков проводит Microsoft (NASDAQ:MSFT). На мероприятии рассказывали о грядущих изменениях в следующей Windows OS. Тогда говорилось о новой функциональности под названием WinFS. Предполагалось, что эта WinFS соединит в себе черты файловой системы и базы данных.

Это было достаточно амбициозным начинанием. WinS в техническом смысле можно было приравнять к налаживанию массового производства летающих автомобилей. Вот-вот, пара лет —и счастье здесь.

Прошло три года. Менеджер Microsoft по имени Квентин Кларк в своём блоге объявил, что WinFS невозможно выпустить вовремя, и что она задерживает запуск последней ОС Windows. Поэтому релиз WinFS был задержан. Более того, его выпуск теперь предполагался лишь в качестве одной из функций будущей базы данных: а значит, ни о каком крутом проекте совмещения базы данных и файловой системы не могло быть и речи.

Так как же понять, уготована ли вашему проекту печальная судьба WinFS? 

Вот моё пошаговое руководство по провалу проекта разработки ПО:

Шаг № 1: Наймите штат посредственных разработчиков

Разработка ПО — дело непростое (ваш Кэп). К сожалению, многие люди, называющие себя разработчиками и программистами, на самом деле таковыми не являются. Кстати, несмотря на то, что именно плохая команда является причиной номер 1 во всех провальных проектах, вы никогда об этом не прочтёте в официальной документации и отчётах. На всех этапах реализации проекта, начиная со стадии разработки, и заканчивая логистикой и клиентским сервисом, люди не могут переступить через профессиональную вежливость и такт и говорить о возможной некомпетентности своих коллег. Ну кто осмелится сказать о сотрудниках отдела что-то вроде «да просто им опыта и таланта не хватало, чтобы сдюжить этот проект»? А ведь это очевидный факт: если люди в команде недостаточно хорошо делают своё дело, этот продукт никогда не будет выпущен. И не полагайтесь на HR-ов, которые отфильтруют неподходящих людей. Полагайтесь только на себя.

Шаг № 2. Стройте планы на неделю вперёд

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

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

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

Шаг № 3: Обсуждайте дедлайн

Что может быть хуже расписания работы над проектом на неделю вперёд? Только надежда на то, что команда закончит работу раньше установленного срока. Зачастую разработчики склонны поддаваться на уговоры и в конце концов согласовывать с заказчиком сроки, в которые точно не уложатся.

В качестве лирического отступления: самка моржа вынашивает детёныша 15-16 месяцев. Вы просите мамашу постараться разобраться с родами за 15 месяцев, и, возможно, она согласится на такой исход. А вот попросить мамашу уложиться месяцев в 8 — это уже чистое сумасшествие. Вы можете предлагать что угодно, умолять на коленях и угрожать, но вам никуда не деться от 15 месяцев. Иногда даже 16.

Шаг № 4: Раздавайте задачи поровну

Идеальный способ провалить любой проект. Составьте список тех, кто работает над проектом, а потом распределите между ними задачи. Если у Маши слишком много работы, отдайте часть её задач Ване. Ну вроде бы разумно, да?

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

Шаг № 5: Работайте до полуночи

Допустим, проект длится шесть месяцев по 40 рабочих часов в неделю. Если все будут работать по 60 часов в неделю, проект можно завершить за четыре месяца. И все будут выглядеть настоящими героями.

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

Не нужно доводить команду до марша смерти.

В конце концов, написание кода — дело интеллектуальное, и мозг не способен продуктивно работать более 4 часов.

Заставить команду проводить за компьютером дни и ночи не приведёт к повышенным результатам. Только к плачевным: уставшая голова и руки начнут нести околесицу и писать непригодный код. Хотите избавиться от сотрудников? Запретите им выход в Интернет на любимые сайты MMORPG.

Итак, что делать, чтобы всё было хорошо?

Во-первых, подойдите к набору команды как можно серьёзней. В моей компании мы проводили 400 собеседований, чтобы найти одного разработчика.

Во-вторых, мыслите краткими сроками. Составляйте расписание на ближайшие день-два, не больше.

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

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

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

Перевод: Люся Ширшова. По мотивам статьи Joel Spolsky, сооснователя и CEO Fog Creek Software.