Перевод первой части статьи «What’s Common Between Opera Houses And Software Projects, or 10 Reasons Software Developers Go Overtime».
Что общего между зданиями оперы и программами? Создание и тех, и других часто проходит с нарушением графиков. Почему так происходит и что с этим делать, если вы разработчик или клиент? Мы попробовали с этим разобраться.
Многие проекты по созданию ПО требуют больше времени, чем было запланировано. Винят за это разработчиков. Над ними же и посмеиваются.
Любопытно, что такая проблема есть не только в сфере разработки.
Многие архитектурные проекты также выбиваются из графиков, и самые примечательные примеры подобного – оперные театры и концерт-холлы.
Вот несколько интересных случаев:
- Koncerthuset в Копенгагене был построен на 2 года позже, чем планировалось, а бюджет был превышен в 3 раза.
- Концерт-холл Elbphilharmonie в Гамбурге построили на 7 лет позже и в 10 раз дороже по сравнению с начальным планом.
- Парижская филармония – 2 года опоздания и превышение бюджета в 3 раза.
Строительство туннеля под Ла-Маншем, соединившего Великобританию и Францию, обошлось на 80% дороже, чем планировалось. В случае с Сиднейским оперным театром это были уже 1400%.
Зачем нужны приблизительные оценки?
Это хороший вопрос.
Клиент должен знать, сколько времени уйдет на реализацию проекта, потому что ему нужно спланировать свою работу в соответствии с этим.
Многие программы создаются для целей бизнеса, и бизнес чаще всего планирует начать использовать продукт как можно скорее после выпуска. Например, если для будущей работы с программой, находящейся в разработке, нужно нанять людей, эти процессы должны быть подогнаны по времени. Люди не смогут работать с ПО, если его еще нет.
Менеджер, требующий от команды приблизительные прикидки, заботится не только об интересах бизнеса. Эта информация нужна и для планирования будущих проектов этой команды. Ведь не закончив этот проект, они не смогут взяться за следующий.
Если речь идет о стартапе, где люди фактически работают сами на себя, то они являются по факту собственными клиентами. Им нужно спланировать, что в дальнейшем делать с продуктом – продавать, продвигать, развивать. И все это тоже нужно включать в расписание заранее.
Наконец, дедлайны могут привязываться к определенным датам. Например, ко дню рождения человека, которому в качестве открытки дарят маленький сайт. Или смайлики нужно заменить на тыковки к Хеллоуину (31 октярбя). Или релиз нового проекта планируется анонсировать на публичной пресс-конференции. Представьте, что графики разработки нарушаются и поздравительная открытка запаздывает на неделю, а стикеры для Хеллоуина выходят 1 ноября. И зачем они теперь нужны?
В некоторых случаях дедлайны могут быть очень жесткими, в других – более гибкими. Но в сфере профессиональной разработки дедлайны есть всегда. Не существует таких понятий как неограниченный бюджет и неограниченное время.
Порой клиенты могут попросить разработчиков сделать приблизительные расчеты. В подобных случаях клиенты имеют полное право надеяться, что разработчики уложатся в назначенные ими самими сроки.
В других случаях дедлайны устанавливают сами клиенты, но от разработчиков все равно ждут, что они успеют к назначенной дате.
В этой статье я перечислю несколько самых распространенных причин, почему разработка ПО может запаздывать. Также рассмотрим вопрос, как с этим бороться и снизить риски подобных ситуаций. Надеюсь, статья будет полезна как разработчикам, так и заказчикам.
1. Уникальность проекта или сложные требования
Практически любое ПО сложное. Каждый проект уникален, делается по индивидуальному заказу и подгоняется под нужды и желания клиента.
Разработку программ часто сравнивают со строительством зданий, но полностью отождествлять эти процессы не стоит. Архитекторы оттачивали свое ремесло десятки тысяч лет. Разработка ПО существует лет 70. Ну ладно, можно считать, что 180 лет.
Многие дома строятся по типовому проекту, без каких-либо изменений (за исключением цвета стен). Построить десяток совершенно одинаковых домов легко, тут не так много места для ошибок.
А вот строительство уникальных зданий часто выбивается из графиков. Оперные театры, мосты, памятники, стадионы – все крупные и сложные проекты «склонны» занимать больше времени, чем планировалось.
Большая часть проектов разработки программ отличаются друг от друга. В каждом из них реализовываются уникальные наборы требований.
Если вы создаете 10-й по счету клон сайта, то вам будет легко сделать предварительную оценку реализации такого проекта.
Но если требования сложные, замысловатые и не очень ясные даже для самого клиента, разработчики не сумеют сделать хороший предварительный подсчет. Уже работая над проектом, они неизбежно поймут: времени нужно больше, чем планировалось.
Многие проекты, к тому же, имеют такие объемные и сложные наборы требований, что они могли бы составить несколько томов книг. Никто не способен удержать все это в голове.
Если полученные вами инструкции именно такого рода, некоторая неаккуратность в прикидках нужного времени неизбежна.
Что делать разработчику
Если вы чувствуете, что проект слишком сложный и нет никакой уверенности, что еще может «всплыть», вы можете оговорить некоторую гибкость дедлайна.
Пускай бизнес-аналитик запишет все требования, чтобы у вас было как можно больше деталей. Чтобы сделать хороший расчет времени, вам нужно быть хорошо информированным.
Убедитесь, что вы понимаете требования так же, как понимает их заказчик! Ничто не может быть более ужасным, чем создание не того, что заказывали.
Помогите заказчику расставить требования в порядке приоритетности. Начните с критически важных – самое важное вряд ли будет меняться.
Договоритесь с заказчиком, что требования из «некритичной» группы будут реализовываться в конце, если будет время. Возможно, будет лучше позаботиться о них даже после установленного дедлайна. А вот критически важная часть должна быть реализована вовремя.
Что делать клиенту
Помогите вашим разработчикам лучше понять требования. Чем понятнее вы объясните, тем лучше они смогут сделать прикидки. Если вам задают вопросы – отвечайте. Добавляйте детали. Приводите примеры. Рисуйте картинки.
Для начала вам нужно самому понять требования к своему заказу. Если на ранних стадиях они немного расплывчаты, ничего страшного: опытная команда разработчиков поможет вам понять, чего вы хотите. Но ко времени начала работ над проектом вы должны уже четко осознавать свои желания.
Если у вас жесткий дедлайн, будьте готовы отказаться от некоторых своих требований. Расставьте их в порядке приоритетности с точки зрения ваших нужд. Разделите их на категории «абсолютно необходимые» и «хорошо бы иметь, но и без этого можно жить». В последней будут вероятные кандидаты на удаление из бэклога. Их всегда можно реализовать позже, возможно, в рамках отдельных маленьких проектов, когда ваш главный проект будет уже готов.
Если вы совершенно не можете пожертвовать никакими из требований, стоит подумать о смещении дедлайна.
2. Нереалистичные требования
«Начальный дизайн был настолько смело задуман, что его конструктивно невозможно было реализовать. После четырех лет исследований архитектор изменил его», – о строительстве Сиднейского оперного театра, 10 лет спустя.
Если задумка проекта «слишком смелая», есть вероятность, что реализовать ее не получится.
Дедлайн это тоже одно из требований, поэтому, если вы хотите, чтобы что-то было сделано прямо завтра, это тоже можно считать нереалистичным требованием.
Что делать разработчику
Убедите вашего клиента, что воплотить его желания нереально. Возможно, он не знает, что технологии еще не достигли такого уровня. Может, он хочет то, что даже теоретически невозможно создать. Может, он просто не знает, чего хочет.
Постарайтесь по мере возможности просветить своего клиента. Вполне вероятно, что он будет этому только рад, и после этого вы сможете совместно изменить требования так, чтобы они стали более реалистичными.
Если клиент настаивает, вы вправе отказаться работать над таким проектом.
Что делать клиенту
Уточните у своих разработчиков, возможно ли создать то, что вы придумали.
Вы хотите масштабируемую распределенную систему, где обновление данных немедленно появляется везде? Это невозможно даже теоретически.
Вам нужен 100% uptime у ваших серверов? Это вряд ли.
Задумали создать социальную сеть вроде фейсбука, но чтобы она хостилась на одной машине? Такого не будет.
Мессенджер с шифрованием, в котором некоторые сообщения все же могут быть тайком прочитаны третьими лицами? Неа.
Искусственный интеллект для захвата мира? Туда же.
Правда, ваши разработчики могут так жаждать получить работу, что согласятся на это. Они могут потратить столетия на попытку удовлетворить ваши требования, провести множество исследований, испытать множество вещей, – но так ничего и не сделают. В этом случае вы должны понимать, почему это происходит, и пойти на какие-то компромиссы.
Если ваши разработчики говорят вам, что это невозможно, но вы все равно имеете причины для сомнений, поищите других разработчиков. Все же могут ошибаться, в конце концов.
3. Изменение требований
«Кроме начала строительства еще до завершения разработки проекта была и другая проблема. Правительство изменило требования к зданию уже после начала стройки. Начальный проект предполагал наличие двух залов. Теперь их должно было быть четыре», – о Сиднейском оперном театре, 10 лет спустя.
Если вы сначала хотели построить два зала, а потом передумали и решили, что их будет четыре, угадайте: изменятся ли сроки строительства?
Может возникнуть срочная потребность добавить всего одну маленькую фичу в проект. И еще одну. И еще. А затем поменять первую. И третья определенно конфликтует со второй, так что, пожалуйста, удалите вторую. А впрочем, оставьте. Если подумать, лучше удалить первую. И еще одну добавить…
Что делать разработчику
Расставьте требования в порядке приоритетности, чтобы понять, о каких следует позаботиться сразу. Начните с самых критичных.
Если ваш клиент хочет иметь жесткий дедлайн, требования должны быть зафиксированы с самого начала работы над проектом. Задокументируйте их. Все должно быть изложено на бумаге и подписано кровью, а потом запечатано двумя алыми восковыми печатями с гербами (вашим и клиента). Первыми должны фиксироваться критически важные требования.
Изменение или добавление любого функционала, каким бы маленьким оно ни было, должно приводить к официальному изменению требований и, следовательно, изменению сроков.
В противном случае это приведет к катастрофе. Клиент будет считать, что все изменения уже учтены в сроках и смете. Он будет на вас давить, вы будете работать по выходным – и все равно не успеете вовремя. Все будут несчастны.
О некритичных требованиях можно позаботиться позже, возможно, в рамках отдельного небольшого проекта уже после основного дедлайна.
Что делать клиенту
Расставляйте свои требования в порядке их приоритета. Убедитесь, что вы вполне понимаете, какие из них самые важные. Смотрите на этот счет пункт о сложных требованиях.
Если вы вносите изменения в свои требования, вы должны понимать, что это увеличивает объем работ для разработчиков. Больше работы – больше времени. Конечно, кроме тех случаев, когда вы хотите что-то удалить. Удаление функционала воспринимается совершенно нормально (если только никто еще не начал над ним работать).
Дедлайн это тоже требование, и чаще всего – из группы важных. Поэтому сдвиг дедлайна означает изменение требований.
Конечно, отмена дедлайна вообще никаких проблем у разработчиков не вызовет, однако так ваш бизнес может пострадать.
4. Изменения в команде
Разработчики приходят и уходят. В следующем месяце половина команды может состоять из новых людей. Тимлид ушел. Техлид только приступил к своим обязанностям, перейдя из другой компании и не обладая бэкграундом в вашей сфере. Оба джуниора, начавшие работать только два месяца назад, стараются, как могут, чтобы помочь новому QA войти в курс дела. Документацию никто еще не читал.
Если команда меняется слишком часто, у людей нет времени узнать сильные и слабые стороны друг друга и научиться эффективно сотрудничать.
Больше того, люди приходят на новый для себя проект. Потребуется время, чтобы они освоились в нем и познакомились с заказчиком и его требованиями. Чем сложнее проект, тем больше времени на все это потребуется.
Кроме того, если работа над проектом уже перевалила за половину, или если вы расширяете существующий проект, людям будет нужно время для ознакомления с кодовой базой.
В некоторых случаях может понадобиться полгода на то чтобы разработчик достаточно освоился и начал приносить пользу проекту.
Чем дольше члены команды знакомы и работают вместе, тем точнее будут их предварительные расчеты.
Что делать разработчику
Убедите своего менеджера, что добавление новых людей в проект не ускорит его окончание.
Если у вас в команде есть новички, старайтесь помочь им, чем только можете. Если вы вложите в это свое время и силы, это облегчит работу не только новичкам, но и вам самому в ближайшем будущем.
Покер планирования может помочь сделать предварительную оценку. Если вы знаете какую-то сферу деятельности, вы можете прикинуть, что выполнение задачи займет один час. Но новичку на то же самое потребуется неделя. Новый человек может постесняться сказать об этом прямо, но покер планирования заставит его сделать это.
Обсуждение возможных реализаций внутри команды также помогает новым членам ознакомиться со всеми аспектами, о которых они не подумали, да и вообще не знали.
Парное программирование и ревью кода помогает не только поддерживать качество кода, но и делиться знаниями.
Если вы новичок в команде, общайтесь со «старожилами» и учитесь у них. Узнавайте у них все о команде и проекте. Читайте документацию. Говорите с клиентами. Впитывайте в себя информацию. Вероятно, вам потребуется больше времени на выполнение заданий, чем более «старым» коллегам. Это совершенно нормально и ничего постыдного в этом нет. Но иногда ваши коллеги могут забывать о том, что вы не провели вместе с ними всю вашу предыдущую жизнь, так что напоминайте им об этом.
Что делать клиенту
Постарайтесь определить, давно ли члены этой команды работают друг с другом, или же их только вчера собрали.
Во втором случае сделайте мысленную пометку: времени потребуется больше. Дайте им возможность познакомиться с проектом в их собственном темпе. Не начинайте сразу подгонять новых разработчиков. Помните, что даже 9 женщин не выносят ребенка за 1 месяц.
5. Слишком много джуниоров
Все в команде только второй год работают. Сеньор только из университета выпустился. Менеджер проработал три года, а на эту должность его недавно перевели.
Все они очень стараются, но у них просто нет достаточного опыта, чтобы начать (и закончить) большой и сложный проект.
Что делать разработчику
Не переоценивайте свои силы (и не недооценивайте тоже! Но это отдельная тема).
Если вы только начинаете карьеру, а все вокруг такие же, поднимите этот вопрос прежде чем приступать к проекту. Действительно ли вы можете это сделать? Сумеете ли вы завершить этот проект? Есть ли у вас достаточно навыков? Способны ли вы реализовать то, что просят? Знаете ли вы, что нужно делать перед разработкой, как собирать требования, на что обращать внимание?
Не так плохо отказаться от проекта, как взяться и не суметь завершить.
Что делать клиенту
Обращайте внимание на опыт вашей команды. Они могут выглядеть очень уверенно, однако быть слишком «зелеными».
Спрашивайте рекомендации. Спрашивайте о завершенных проектах. Поинтересуйтесь о них у их прошлых клиентов.
Понаблюдайте за тем, как они работают. Проводят ли они тестирование? Ведут ли документацию?
Все очень индивидуально, конечно. Более простые проекты можно достаточно смело доверять джуниорским командам. Более критичные и важные, возможно, стоит поручить более опытным разработчикам.
Продолжение статьи читайте здесь.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]