Многие проекты по разработке программного обеспечения выходят за сроки. В этом винят и за это ругают разработчиков, но так происходит не только в разработке. Многие строительные проекты выходят за сроки, и самые заметные из них — оперные театры и концертные залы. Вот несколько примеров:
- От оперного театра в Сиднее (срок превышен на 10 лет, бюджет — в 15 раз) до концертного зала имени Уолта Диснея (16 лет строительства) и концертного зала Копенгагена (самое дорогое строительство концертного зала в истории) — строительство современных концертных залов стало архитектурным кошмаром. — The problem with building concert halls
- Строительство Евротоннеля затребовало на 80% больше бюджета, Большого Бостонского тоннеля — на 220% больше. — Megaprojects: Over Budget, Over Time, Over and Over
- То же самое можно сказать про Эльбскую филармонию в Гамбурге, Парижскую филармонию и стадион Уэмбли. После 15 лет планирования в 2006 году началось строительство нового аэропорта в Берлине, и в 2016 ему ещё не было видно конца. Как сказал представитель по связям с прессой: “Никто не даст вам точных гарантий насчет этого аэропорта, только если этот человек не принимает наркотики”. Вот это оценка.
Зачем нам нужна оценка времени?
Это разумный вопрос. Клиенту нужно знать, сколько времени займет проект, потому что ему нужно планировать свою работу.
Многие продукты создаются для нужд бизнеса, и компании планируют использовать эти программы вскоре после их завершения. Например, если они хотят нанять людей для работы с этой программой, эти две операции нужно совместить по времени. Люди не могут работать без программы.
Если менеджеры команды разработки требуют этой оценки, им нужно успеть вовремя для целей бизнеса и планировать будущие проекты команды. Как они могут найти новый проект, если старый ещё не закончен?
Если это стартап, то они выступают в качестве собственных клиентов. Им нужно планировать дальнейшие действия с продуктом: продажу, развитие, маркетинг. Всё это должно быть спланировано по расписанию.
Наконец, может существовать дедлайн, приуроченный к определенной дате, например, ко дню рождения человека, который получит открытку в виде сайта, или все эмодзи будут связаны с Хеллоуином, или новый проект должен быть озвучен на публичной конференции. Представьте, если открытка опоздает на неделю, а стикеры к Хеллоуину выйдут 1 ноября? Какой тогда в этом будет смысл?
В некоторых случаях дедлайн может быть строгим, а в некоторых — гибким, но он в любом случае есть. Иногда клиент просит разработчиков оценить время на проект, а иногда клиент назначает дедлайн, но в любом случае он ожидает, что сроки будут соблюдены.
В этой статье я рассмотрю некоторые общие причины, по которым проекты разработки выходят за временные рамки, объясню, почему это происходит и как снизить риск этого.
Причина 1: уникальность или сложные требования
Разработку часто сравнивают со строительством домов. Но я рассею миф о том, что это одно и то же.
Многие дома строятся по одному шаблону, изменяется при этом лишь цвет стен. Очень просто построить точно такой же десятый дом и не ошибиться. Строительство уникальных зданий, с другой стороны, часто превышает планируемые сроки. Оперные театры, мосты, памятники, арены, все смелые и сложные проекты склонны к этому.
Многие проекты по созданию ПО отличаются друг от друга. У каждого есть свой уникальный набор требований. Если вы создаете десятый одинаковый сайт, то проект очень просто оценить и сдать в срок. Но если требования сложны и не совсем понятны даже для клиента, разработчики не смогут сделать точную оценку необходимого времени. При работе над проектом они, скорее всего, поймут, что им нужно больше времени. Требования к некоторым проектам настолько велики, что никто не может держать их все в уме. Некоторая неточность во времени здесь неминуема.
Если вы разработчик
Если вы чувствуете, что проект слишком сложен, и вы не уверены, что произойдет дальше, вы можете договориться о гибкости дедлайна. Пусть бизнес-аналитик запишет все требования максимально подробно, вам нужно много информации, чтобы сделать точную оценку времени.
Убедитесь, что вы поняли требования клиента так, как он понимает их. Нет ничего хуже, чем создать что-то не то.
Помогите клиенту приоритизировать требования в порядке важности. Начните с самых главных, они вряд ли изменятся в процессе. Договоритесь с клиентом, что не самые важные требования вы добавите в конце, если у вас будет хватать времени. Возможно, вы позаботитесь о них после первоначального дедлайна, если критическая часть будет закончена вовремя.
Если вы клиент
Помогите разработчикам лучше понять требования. Отвечайте на их вопросы, дайте им детали, примеры и картинки.
Сначала вам нужно определить требования для себя. Если на ранней стадии они вам не совсем ясны, это нормально: профессиональная команда поможет вам понять, чего вы хотите. Но к началу работы вы должны это сформулировать.
Если ваш дедлайн имеет строгую дату, будьте готовы убрать несколько требований из списка. Приоритизируйте их и разделите на “абсолютно необходимые” и “было бы отлично, но можно обойтись без них”. Вторая группа будет содержать возможных кандидатов на удаление. Эти функции можно будет внедрить уже после старта вашего проекта. Если вы не можете расстаться ни с одним из требований, остается один выход: рассмотреть сдвиг дедлайна.
Причина 2: нереалистичные требования
Оригинальный дизайн был очень смелым и оказался структурно невозможным. После четырех лет исследований Утзон изменил свой дизайн. — Об оперном театре Сиднея.
Если у вас слишком смелая задумка, может случиться так, что её нельзя будет воплотить. Сюда же относится и дедлайн — если вы хотите результат на следующий день, это будет столь же нереалистично.
Если вы разработчик
Убедитесь, что ваш клиент понимает, что сделать это невозможно. Может быть, они не знают, что подходящей технологии пока не существует. Может быть, они хотят вещь, невозможную даже теоретически. Может быть, они просто не знают, чего хотят.
Постарайтесь максимально просветить своего клиента. Если это ошибка, они будут рады уделить свое время и выслушать вас, а затем изменить свои требования вместе.
Если вы клиент
Спросите у разработчиков, возможно ли создать то, что вы хотите. Вы хотите масштабируемую распределенную систему, в которой обновления данных появляются моментально? Это невозможно даже теоретически. Вы хотите серверы со 100% времени безотказной работы? Маловероятно. Динамический 3D-шутер с 200 FPS на устаревших ноутбуках? Социальную сеть, размещенную на одной машине? Этого не произойдет.
Разработчики могут принять вашу работу, если она им нужна. Они убьют кучу времени на то, чтобы провести исследования, выполнить ваши требования, но всё будет не то. В этом случае вы должны будете разобраться, почему так происходит, и пойти на компромиссы.
Если ваши разработчики говорят вам, что это невозможно, но у вас есть хорошие причины, чтобы с ними не соглашаться, поищите другое мнение. Они могут и ошибиться.
Причина 3: изменение требований
…государство изменило требования после начала строительства. Оригинальный дизайн был рассчитан на два театра. Государство изменило свое мнение и запросило строительство четырех театров. — об оперном театре Сиднея
У вас может возникнуть срочная необходимость добавить одну маленькую функцию в проект, а потом ещё одну, а потом изменить первую, но потом оказывается, что третья конфликтует со второй, поэтому уберите вторую…Нет, оставьте и уберите первую…
Если вы разработчик
Если ваш клиент настаивает на строгом дедлайне, требования должны быть установлены в начале проекта. Убедитесь, что они задокументированы, а критические требования находятся на первом месте. Каждая функция, которую клиент хочет добавить или изменить, должна приводить к официальному изменению требований и дедлайна.
Если вы клиент
Если вы изменяете требования, вы должны понимать, что это означает больше работы для разработчиков, только если вы не удаляете функцию. Удаление функций может быть к лучшему, но только если никто ещё не начал над ней работать.
Дедлайн — это тоже требование, причем критическое. Поэтому сдвиг его на более ранний срок — это тоже изменение требований. Конечно, отмена дедлайна устранила бы проблему, но без сроков ваш бизнес пострадает.
Причина 4: изменение команды
Разработчики приходят и уходят. Через месяц половина команды полностью изменилась. Лидер команды ушел, а новый только начал работать после другой компании с другим опытом.
Если команда меняется слишком часто, у них нет времени узнавать сильные и слабые стороны друг друга, и они не знают, как работать вместе эффективно. Новым разработчикам нужно время, чтобы погрузиться в проект. Иногда это может занять до полугода.
Если вы разработчик
Убедите своего менеджера, что добавление новых людей в проект не ускорит его окончание. Если в вашей команде появились новые люди, помогите им всем, чем можете. Инвестируя в них свое время, вы облегчите работу им и себе в ближайшем будущем.
Planning poker может помочь с оценками. То, что у вас займет час, у новичка может занять неделю. Новый человек может не сказать это, но planning poker заставит их высказаться.
Обсуждение возможного развертывания с командой также поможет новым участникам ознакомиться со всеми аспектами, о которых они могли и не подумать. Парное программирование и обзоры кода помогут в повышении качества кода и распространении знаний.
Если вы новый разработчик, общайтесь с другими и учитесь у них всему, чему можете. Разговаривайте с клиентами. Вам может понадобиться больше времени, и иногда ваши коллеги могут об этом забыть, не бойтесь напомнить им.
Если вы клиент
Попытайтесь узнать, сколько времени команда работает вместе. Если это небольшой срок, позвольте им сначала ознакомиться с проектом и не ожидайте, что новый разработчик быстро войдет в работу.
Причина 5: слишком неопытная команда
Все разработчики работают первый или второй год. Старший разработчик только что закончил колледж. Менеджер работал здесь три года и только что получил повышение. Они стараются, но пока не имеют достаточно опыта для большого и сложного проекта.
Если вы разработчик
Не переоценивайте себя. Если вы и ваша команда только начинаете, обсудите этот вопрос до того, как взять на себя обязательства. Вы сможете сделать это? А закончить? У вас достаточно навыков? Вы знаете, что нужно сделать сначала, как собирать требования и чему уделить внимание? Не так плохо отклонить проект, чем начать его и не закончить.
Если вы клиент
Уделите внимание опыту команды. Они могут выглядеть очень уверенными, но знать не так много. Спросите о рекомендациях, завершенных проектах, пообщайтесь с их прошлыми клиентами.
Посмотрите на их работу. Они делают тесты и документацию? Они следуют процессу?
Причина 6: это не только код
Забыли отдел тестирования? Тестирование и устранение багов занимает время.
Вы учли время на написание юнит-тестов? Интеграционных тестов? Регрессионных тестов? А вам нужно ещё настроить сервер…. Время на настройку git, slack и wiki. Время на подготовку серверов. Время развертывания. Кстати, вы включили время для написания правильного сценария развертывания? А ещё брейнстормы, презентации, отпуска, болезни, конференции и все мелкие неприятности, которые случаются одновременно.
Если вы разработчик
Помните, что дело не только в кодинге. Должно произойти много всего, пока часть кода начнет работать. Непредвиденные вещи также случаются. Оставьте время для них.
Если вы клиент
Напомните, что разработчикам нужно будет провести тестирование и развертывание. Если разработчик говорит вам “Я закончу сегодня”, это не значит, что функция у вас будет уже сегодня. Спросите их, когда функция будет развернута, выпущена и видима для пользователя. Ответ может сильно отличаться.
Причина 7: оптимизм
Разработчики привыкли оптимистично оценивать свое время. Это так просто! Я сделаю это до завтра, нет, за час. Ой нет, мне нужно установить IDE и настроить git. Но потом ровно час!
Если вы разработчик
Вспомните свои предыдущие оценки. Когда вы завершали задачу на самом деле?
Чтобы сделать это, ведите журнал. Перед каждой задачей запишите, сколько она должна у вас занять времени, а потом сравните, сколько времени она заняла на самом деле. Команда может вести совместный дневник. Синхронизация команды может происходить, например, при обзоре спринта.
Совет: если у вас нет журнала, умножьте свою оценку на число пи.
Если вы клиент
Умножьте все оценки времени на число пи. Серьезно. Это эмпирическое число магическим образом работает во многих случаях. Думаете, это слишком много? Что же, если все закончится раньше, вы будете приятно удивлены. Если нет — вы этого и ожидали. Будьте пессимистом! Вы можете также попросить диапазон оценок и выбрать для использования самый долгий срок.
Причина 8: постоянное давление
Уже второй день, а мы ещё ничего не сделали. Почему так медленно? Не нужно думать об архитектуре, начинайте кодить! Нет времени на тесты, давайте-давайте!
Некоторые люди под давлением становятся продуктивнее. Некоторые начинают сомневаться и задавать себе вопросы. Многие при стрессе совершают ошибки. Исправить ошибку будет сложнее потом. Разработчиков часто толкают на компромисс. Они должны выбрать между долгосрочным качеством и краткосрочной скоростью, и их могут заставить сделать быструю и неаккуратную функцию вместо медленной и точной работы.
После некоторого времени код начинает загрязняться. Новые функции становится сложнее вводить, а сделать ошибку гораздо проще. Это состояние кода называется “техническим долгом”. Чем дольше вы откладываете платеж (чистку кода), тем больше становится долг.
Когда приходит время погашать технический долг: опыт LinkedIn
Если вы разработчик
Главный вопрос: что является причиной давления? Ваш клиент может захотеть “почувствовать власть”. В таком случае объясните им, что это вредит проекту.
Если приближается дедлайн, или вы замедлили работу, или происходит что-то ещё, у клиента есть моральное право применить давление — вам нужно найти способ не повредить качеству проекта. Если можете, делегируйте менеджеру переговоры и общение с клиентом.
Если вы клиент
Доверяйте разработчикам. Не давите на них без надобности. Вам нужно, чтобы они мыслили ясно.
Причина 9: нерешительность
Эти две библиотеки очень хорошие, какую бы выбрать? Может, нам написать свою собственную? Какой фреймворк выбрать? А базу данных? Ruby или Python?
Иногда разработчики не могут решить, как именно внедрить функцию, и застревают в дискуссиях, прототипах и сравнениях.
Если вы разработчик
Сделайте глубокий вдох и подумайте о клиенте. Это действительно нужно в проекте? Случится ли что-то плохое, если вы выберете не самую лучшую технологию?
Ограничьте время на сравнения. Например, решите, что потратите только два дня на исследования и изучение вариантов. Не позволяйте себе прокрастинировать, потому что не можете принять решение. Это трата времени.
Часто лучший подход — выбрать технологию, с которой знаком кто-то в команде. Это сэкономит вам время, и у вас будет человек, который научит всех остальных.
Если вы клиент
Не позволяйте разработчикам тратить слишком много времени на некритические вопросы. Помогите им понять, что не так критично. Если они решат сделать собственное решение, библиотеку или фреймворк, у них должны быть очень веские причины так поступить.
Причина 10: некомпетентность
Это самая грустная причина. Люди неверно внедряют функции, ломают работающие части новым кодом, не делают юнит-тесты и регрессионные тесты. Не делают тесты совсем. Некоторые люди не думают об архитектуре до начала кодинга. Многие думают, что код важнее продукта, и создают монстра, которого не могут использовать люди. Многие пишут слишком хрупкий код, который нельзя прочитать или расширить.
Иногда разработчики не чувствуют мотивацию. Они ходят по офису с кофе, разговаривают у кулера, долго ходят на ланч, смотрят видео и играют в игры. Иногда команда прокрастинирует до самого дедлайна, а затем делает всю работу.
Иногда разработчики могут обмануть клиента. Они могут взять деньги и не сделать ничего или сделать работу некачественно. Они могут перепоручить работу кому-то, чьи услуги стоят дешевле, не беспокоясь о клиенте, проекте и репутации.
Если вы разработчик
Извините, но вам нужно научиться многому перед тем, как вы сможете по-настоящему работать над важными проектами. Поищите курсы и тренинги. Поработайте над более простыми проектами. Найдите ментора, почитайте статьи и книги. Будьте более ответственны за свою работу.
Если вы заметили, что кто-то из команды работает не лучшим образом, поговорите с ними или скажите менеджеру. Если это вы управляете командой разработчиков, вы должны уметь замечать эти проблемы в самом начале и решать их. Может быть, вам нужно быть строже, изменить процесс или поощрять разработчиков за хорошую работу. Что вы можете сделать, чтобы помочь им стать лучше? Или остается только нанять других людей?
Если вы клиент
Вам, вероятно, нужно сменить команду. Или тщательнее смотреть за этой. По сути, вам нужно стать их менеджером. У вас может не быть нужных навыков, а им может это не понравиться, но если вы уже на полпути, вам необязательно отменять контракт.
Я была в этой ситуации сама и не могу сказать, что была рада этому опыту.
Заключение
Вероятнее всего, проект будет включать в себя несколько причин выхода за рамки дедлайна и бюджета. Я часто видела, как “Изменение требований”, “Изменения в команде” и “Оптимизм” происходили в одно время.
Надеюсь, что заказчики поняли, насколько разработка является сложным процессом, как и оценка времени. Надеюсь, что разработчики немного лучше поняли, что от них ожидает заказчик, и узнали, как замечать проблемы на раннем этапе и как исправлять самые распространенные из них.