Программисты срывают сроки. Что делать, чтобы оценка была более точной?

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

За 25 лет в заказной разработке мы в SVK.Digital сталкивались с разными кейсами и понимаем, насколько сложно менять команду в середине проекта. Поэтому в статье расскажем, какие инструменты помогут спасти проект, если команда уже не вписывается в сроки, а выпускаться все же нужно. Но сначала разберемся, в чем вообще трудность с расчетами в IT. 

Почему так сложно точно оценить сроки в IT-проекте?

К сожалению, срыв сроков для IT — норма. Почему так? Дело в том, что разработка, которая кажется набором технических задач, — на самом деле творческая деятельность. Задачи программистов больше похожи на изобретательство и науку, чем на работу за токарным станком. 

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

От чего зависит точность оценки IT проекта?

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

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

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

Объем работы. Если проект простой, оценка будет точнее. Например, дать сроки реализации одностраничного сайта проще, чем срок разработки ERP-системы с множеством интеграций в IT-инфраструктуру компании. 

Как работать с этими факторами? Если в наличии один из них, то сроки, названные разработчиками, стоит умножать на два. Если сошлись все три фактора, задача займет в три раза больше времени, чем назвали разработчики.

Но все-таки, как сделать оценку проекта более точной, несмотря на «отягчающие обстоятельства»? У нас есть несколько приемов, которые помогут в этом и которые мы сами используем при оценке проектов.

Что делать, чтобы оценка была более точной: 7 инструментов

1. Синхронизация ожиданий

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

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

Какова цена ошибки? Например, если планировался проект на 8 недель, то из-за двух таких недопониманий вы потеряете 2 недели на выполнение не того и еще 2 недели на переделывание. 

Итого: сроки увеличатся в 1,5 раза. Проект займет 12 недель вместо 8-ми. Выглядит неприятно. 

Как определить, что вы с командой поняли друг друга? Иметь четкое и согласованное ТЗ. Например, мы составляем документ «Спецификация требований», где описаны цели, задачи, результаты и критерии достижения целей. А также основной набор требований и два состояния системы: «как есть сейчас» и «как будет».

Пример документа «Спецификация требований» для одного из наших проектов

2. Дополнительное время на изучение незнакомых задач

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

Например, на одном из наших проектов — разработка личного кабинета болельщика для баскетбольной команды «Локомотив-Кубань» — нужно было интегрировать личный кабинет с билетной системой «Qtickets». 

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

Как определить, что команда использует такой прием? Спросите, как они оценивали срок и проводили ли ресерч, перед тем, как дать вам оценку по времени и стоимости.

3. Привлечение для оценки сроков сотрудников разных направлений

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

Лучший вариант, когда в команду на этапе оценки включены все, кто будет принимать участие в проекте: тимлид, аналитик, проектный менеджер, дизайнер, бэкенд- и фронтенд-лиды и другие сотрудники. 

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

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

4. Добавление времени на непредвиденные обстоятельства и риски

Даже если есть уверенность в сроках, заложите на непредвиденные проблемы минимум 25% от времени, которое планируете потратить на задачу. То есть, если рассчитываете, что задача будет сделана за месяц — заложите еще неделю, чтобы точно успеть в срок. 

Почему это важно? Бывают самые разные обстоятельства, которые влияют на длительность выполнения задачи. Например, команды часто забывают про тестирование задач. А ведь после него обычно приходится что-то переделывать. Также имеют значения отпуска, больничные и командировки.

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

Иногда не все менеджеры могут справиться с ведением сложных IT-проектов. Такой риск случился как-то и у нас. 

Проект заключался в аналитике перед внедрением PIM-системы (используется в ecommerce для управления данными о продуктах. Подробнее в статье). И менеджер выгорел, не справился с нагрузкой и уволился. Риск критичный, дедлайн горел. Чтобы выйти из ситуации, подключили более опытного менеджера — руководителя проектного отдела. Благодаря тому, что мы детально вели документацию, удалось подхватить проект и успешно его зарелизить. 

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

Пример документа со списком рисков для одного из наших проектов

5. Подготовка дорожной карты 

Чтобы спланировать, как будет идти проект, стоит разработать дорожную карту. Это стратегический документ, который описывает основные этапы, а также временные рамки их выполнения. Дорожная карта — ориентир для команды. Она помогает координировать действия участников и обеспечивает прозрачность процесса.

Да, скорее всего, дорожная карта не сразу станет детальной. Ближайшие пункты в ней будут описаны точно, а последние этапы — абстрактно. Это нормально, ведь в начале команда может не обладать всей полнотой информации.

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

По ходу проекта дорожная карта должна актуализироваться. Если у вас 12-месячный проект то дорожная карта не может актуализироваться реже чем 1 раз в месяц. 

6. Фокус на ближайшей задаче и декомпозиция

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

А также разбивайте сложные задачи на небольшие подзадачи (декомпозиция). Важно, чтобы большая часть подзадач были знакомыми для команды и небольшие по объему. Так они будут выглядеть посильными, а оценить время на их выполнение будет проще.

7. Контроль

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

Почему это необходимо? Ритмичность снижает риски, что что-то пойдет не так. Минимальный срок, когда нужно провести ревизию задач — середина проекта. То есть, если проект длится месяц, то минимальная точка контроля будет через 2 недели. Если примерно 50% работы выполнено — значит все хорошо. Если нет — это повод пересмотреть сроки или обсудить с командой эффективность работы. 

Как не свалиться в гиперконтроль? Тут работает только путь проб и ошибок. Команда системно выполняет обещания и соблюдает сроки? Тогда имеет смысл давать ей больше свободы. Если же есть ошибки, то контроль стоит усилить. 

По нашему опыту, в разработке контроль может быть ежедневным, еженедельным или раз в две недели, но не реже. Ведь если проект занимает 6-12 месяцев, то при контроле раз в месяц, вы ничего не будете знать об ⅙ проекта. За такой срок может многое произойти. Редкий контроль (реже раза в две недели) допустим только на проектах, длительность которых превышает год. 

Выводы

Итак, во-первых, расслабьтесь: сроки в проектах по разработке срываются почти всегда. По нашему опыту, это почти неизбежность. Тем не менее, можно минимизировать отставание, используя приемы, что мы перечисли. 

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

И не принимайте сроки, которые вам назвали программисты, как окончательные. Всегда закладывайте буфер или хотя бы умножайте время на проект в 1,5 раза. То есть, если вам обещают, что проект будет готов через 10 месяцев, рассчитывайте на срок от года до 18 месяцев. 

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