«Если связываешься с разработкой — будь готов, что все сроки будут просраны». Именно так сказал один наш, на тот момент, будущий заказчик. И действительно: у него тогда дизайнер-фрилансер затянула выполнение проекта уже на два месяца.
К слову, работая с нами, по итогу, данный заказчик остался доволен. Мы сделали проект превосходного качества и сдали все вовремя. Но почему так получается, что, мягко говоря, очень часто, сроки в it не соблюдаются? Почему вместо получения результата в оговоренный срок, вы, как заказчик, слышите всяческие объяснения и новые обещания доделать уже к новому сроку, в лучшем случае? В этой статье постараюсь разобраться объективно с самыми распространёнными причинами просрочек в сфере IT-разработки.
Мы в своей деятельности с самого начала столкнулись с тем, что — как ни старайся — совершенно магическим способом проекты всё равно сдаются с некоторой просрочкой от изначальной оценки. Не помогает даже намеренное завышение сроков и создание значительного временного буфера. Но сейчас мы уже научились правильно и адекватно оценивать свои силы и сдавать проекты вовремя. Этим опытом и делимся.
Неправильная оценка реально необходимых сроков проекта
Вы, как заказчик, отправляете свою задачу на оценку в студии разработки и получаете самые разнообразные цифры сроков и стоимости (от самых маленьких до самых заоблачно больших). Естественно, у Вас желание сделать всё как можно быстрее и дешевле — и поэтому Вас привлекают низкие цены и минимальные сроки.
Нет никаких гарантий того, что исполнитель указал объективные сроки, а не взял цифру «от балды», лишь бы выиграть Ваш «тендер». Поэтому выбирать самого «быстрого» и дешевого исполнителя - практически всегда ошибка.
Если есть только общее описание задачи, то оценку на этом этапе можно ожидать от исполнителя только примерную. Опытная команда разработки, которая понимает весь цикл изготовления продукта, даст Вам точную оценку только на основании детального технического задания, которое содержит описание каждого экрана и каждой части функционала будущего продукта.
Такая оценка будет выглядеть как смета, которая содержит детальный список частей функционала будущего продукта c расчетным количеством требуемых часов на его реализацию. Отсюда и будет получаться объективная стоимость и сроки на будущую разработку.
Обязательно заложите для себя дополнительное время на разработку, как минимум +20% от времени, которое вы пропишите с исполнителем в договоре, но не говорите ему об этом. Лишь единицы студий разработки способны выдержать сроки договора и у них не пойдет «что-то не так» в процессе.
Предварительно подготовьте точное техническое задание, которое будет гарантировать Вам нужный результат. Получите оценки сроков и стоимости от потенциальных исполнителей. Выбирайте только из тех исполнителей, которые подошли к вопросу оценки ответственно и составили детальную смету. Не ведитесь на одну общую цифру сроков и стоимости.
Неправильная оценка сроков на тестирование проекта
Самый ключевой и затратный по времени этап проекта — это «тестирование и отладка». Многие неопытные заказчики вообще даже не в курсе, что при разработке существует данный этап, и воспринимают его неправильно, как будто исполнитель пытается сдать «багованный» проект. Это ведет ко взаимному непониманию между заказчиком и исполнителем и лишним нервам всех.
Очень часто ни исполнитель ни заказчик, при заключении договора, даже не поднимают вопрос о том, кто и какими методами будет тестировать проект и какой будет критерий готовности и приемки проекта? Именно поэтому этап тестирования нередко уходит столько же времени, сколько ушло на саму первичную реализацию проекта, и даже больше. Идеальный вариант, когда время на тестирование и отладку проекта заложено изначально в смете при заключении договора, и его выполняет тестировщик согласно подготовленным тест-кейсам, а также было предусмотрено время для внедрения в проект автотестов.
- Кто тестирует? Сам разработчик, QA-специалист или заказчик? Каждый вариант требует разного времени.
- Что тестируется? Только основной сценарий или все возможные пути пользователя?
- Как фиксируются баги? В трекере, в мессенджере, голосом по телефону? От этого напрямую зависит скорость правок.
- Сколько итераций? Один раунд тестирования или несколько циклов баг-фикса?
До старта проекта обсудите этап «тестирование и отладка» отдельно. Уточните у исполнителя: сколько времени заложено на этот этап, кто отвечает за QA и как будет организован процесс фиксации и правки ошибок.
Команда разработки тянет до последнего и поставила Ваш проект не в приоритет
Это классика. Разработчик берёт проект, уверен, что успеет, и откладывает реальную работу на потом. Сначала «завтра начну», потом «на следующей неделе разберусь», потом паника и ночные смены за три дня до дедлайна. Всё это сопровождается оптимистичными отчётами заказчику в духе «всё идёт по плану».
Проблема усугубляется тем, что разработчик редко ведёт один проект. Параллельно горят ещё два-три задания, и ваш — не самый приоритетный. В итоге реальная работа начинается тогда, когда дедлайн уже дышит в затылок, а качество страдает от спешки.
«Когда разработчик говорит "я в процессе" — это может означать что угодно. Требуйте измеримых промежуточных результатов, а не словесных отчётов.»
Установите систему промежуточных сдач — раз в неделю или раз в две недели исполнитель показывает реальный результат, а не рассказывает о нём. Это создаёт ответственность и позволяет вовремя увидеть отставание.
Заказчик засыпает разработчика правками при сдаче проекта
Парадоксально, но иногда в срывах сроков виноват сам заказчик. Типичная история: проект готов, начинается приёмка — и тут открывается ящик Пандоры. «А давайте перекрасим кнопки», «а можно добавить ещё вот эту фичу», «мне кажется, тут шрифт не тот». Правки множатся, каждая тянет за собой следующую.
Хуже того, часть правок касается вещей, которые не были прописаны в ТЗ изначально — заказчик «додумал» их в процессе просмотра. Для разработчика это означает переработку уже готовых частей, нарушение логики и дополнительное время. Которого в рамках проекта уже нет.
- Согласуйте критерии приёмки до начала работ — что значит «проект готов»?
- Зафиксируйте количество раундов правок в договоре.
- Разделяйте «ошибки», которые обязан исправить исполнитель, и «хотелки», которые идут отдельным договором.
- Собирайте все правки в один список, а не присылайте их по одной в течение двух недель.
Перед приёмкой потратьте час на то, чтобы собрать все замечания в единый документ. Это экономит дни для обеих сторон и делает процесс управляемым.
Качество выполненного проекта отвратительное
Иногда проект «готов» в срок — только вот принять его невозможно. Кривая вёрстка, падающие страницы, нелогичный интерфейс, скорость загрузки как в 2005-м. Исполнитель закрыл задачи формально: написал код, всё «работает» на его компьютере. На практике — продукт нежизнеспособен.
Это результат двух вещей: отсутствия стандартов качества в договоре и нежелания исполнителя вникать в суть задачи. Когда нет чётких критериев, «готово» означает «я закончил», а не «это работает так, как нужно заказчику».
«Быстро, дёшево, качественно — выберите два. Если исполнитель обещает все три сразу, значит, вы ещё не видели результат.»
- Прописывайте технические требования к качеству в ТЗ: скорость загрузки, кроссбраузерность, адаптивность.
- Требуйте демо на промежуточных этапах — не скриншоты, а живую версию.
- Включайте в договор пункт об ответственности за критические баги после сдачи.
Попросите исполнителя показать примеры предыдущих работ и поговорите с его прошлыми клиентами. Репутация в IT — это главный индикатор качества.
Срыв сроков в IT — это почти всегда системная проблема, а не злой умысел. Устранить её можно, если обе стороны подойдут к проекту осознанно. Вот минимальный чеклист:
- Требуйте детальную декомпозицию сроков, а не одну итоговую цифру
- Обсудите этап тестирования до старта — кто, как и сколько времени
- Установите промежуточные точки сдачи с измеримым результатом
- Зафиксируйте критерии приёмки и количество раундов правок в договоре
- Проверяйте репутацию исполнителя, а не только его цену и обещанные сроки
Мы прошли через все эти грабли сами — именно поэтому сейчас работаем иначе. Если у вас есть проект и вы хотите, чтобы он был сдан вовремя и без сюрпризов — обращайтесь.