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