8 (861) 292-73-72

Почему все веб-студии срывают сроки и что с этим делать?

Денис Раневский

Абсолютно все веб-студии срывают сроки работ. Кто-то чаще, кто-то реже, но 70% проектов проваливаются с треском под громкое улюлюканье конкурентов и крики заказчика. Если вам посчастливилось получить работающий продукт вовремя, то вы попали в оставшиеся 30% и вероятно являетесь единственный заказчиком агентства. Недавний скандал банка “Тинькофф Кредитные системы” с одним из самых дорогих агентств России “Студия Артемия Лебедева” показал, что даже высокая стоимость проекта вкупе с квалификацией подрядчика не спасает от срыва сроков.

Сегодня разберём почему на рынке веб-разработки всё плохо с планированием, и что делать Заказчику для предотвращения просрочек.


Кто на самом деле виноват в срыве сроков?


Ненавижу, когда в Adverbs проваливаются сроки проектов. Мне стыдно перед клиентами, обидно за менеджеров проектов, неловко за всю индустрию веб-разработки. Хочется в конце концов сесть и написать волшебный свод правил, который гарантирует 100% сдачу проекта вовремя. И хочется верить, что мы придём к этому. С вами поделюсь самими распространёнными и критичными для планирования факторами, которые подметил в наших проектах и проектах коллег по цеху.


1. “Хотелки” клиента.


“Хотелка” — это доработка, которая изначально не согласована в техническом задании. Даже самая невинная мелочь может потребовать 5-8 часов на работу и ещё столько же на устранение ошибок. Самые печальные “хотелки” появляются на этапе тестирования. Всё готово, программист переключается на новый проект, но тут, как из рога изобилия, сыпятся маленькие правочки, которые не сможет сделать тестировщик. Страдает план работ по новому проекту, специалист нервничает из-за постоянного переключения внимания, а клиент всё равно остаётся недоволен, так как сроки неизбежно растягиваются.


2. Нестандартные работы.


Конечно, не все сайты делаются по индивидуальному заказу. Однако даже в самых простых решениях есть 1-2 уникальных доработки, которые до этого веб-студией не реализовались. То есть нет точных цифр норма-часа, которые могут потребоваться на подобную работу. Как оценить сроки выполнения? Да никак. На глазок и пальцем в небо. Хорошо, если такие работы укладываются в планирование по рискам, но и в этом везёт не всегда.


3. Неясные требования.


Большинство клиентских технических заданий (ТЗ) описывают функционал в самых общих чертах. Исполнитель видит что-то вроде: “На сайте должна быть реализована синхронизация с сервисами оплат”, и уже сам додумывает какими сервисами, как они должны работать и как синхронизироваться с системой учёта клиента. Не факт, что программист всё “додумает” верно. В агентствах функцию человека, который дописывает ТЗ выполняет менеджер проекта, но это не бесплатная услуга и зачастую клиент не готов ждать - ему нужна цена здесь и сейчас.

А бывает и так


4. Эффект неведомой фигни


Это ошибки программного кода, которые можно увидеть только в процессе работы. Например, у заказчика последняя версия «magento», а там взяли и сменили шаблонизатор для тем на новый, эксприментальный. Заказчик не понимает, почему предыдущие темы делались за 5 дней, а на этой срыв сроков. И про шаблонизатор ему не объяснить, потому что даже то, что я сейчас написал вам не понятно
На такие неизвестные всегда закладываются дополнительные часы, но как точно оценить время?


5. Переключение на другие проекты


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

ЕСЛИ ПАУЗА В ПРОЕКТЕ БОЛЬШЕ, ЧЕМ ПОЛОЖЕНО - СПЕЦИАЛИСТЫ ПЕРЕКЛЮЧАЮТСЯ НА ДРУГУЮ РАБОТУ. И ПОКА НЕ ЗАКОНЧАТ, НЕ ВЕРНУТСЯ К ВАШЕМУ ПРОЕКТУ.

К примеру, на согласование дизайн-макета главной страницы сайта клиенту даётся 2-4 дня, но по факту всё затягивается на недели. Что происходит в этот момент в агентстве? Дизайнер берёт в работу новый проект минимум на 40 рабочих часов и вернётся к вам не раньше, чем через 5 рабочих дней. То есть к дате окончания проекта прибавляем просрочку от клиента и задержку от дизайнера.


6. Замена сотрудника на проекте.


Люди болеют, увольняются, уходят в незапланированный отпуск и это нормально. Однако для сферы IT смена специалистов — крайне болезненный процесс. Передать менеджеру по продажам клиентов в CRM — это одно, а вот отдать недописанный программный код - совсем другая история. Смена специалиста в ходе проекта сказывается на сроках самым негативным образом.


7. Цена и сроки оцениваются на скорую руку


Мы часто участвуем в тендерах, где проект отправляется десяткам агентств. Нужно выдержать конкуренцию по цене и срокам, при этом от заказчика поступает очень приблизительное техническое задание. Клиент не расположен говорить о подробностях проекта, ведь нужна быстрая оценка. В итоге называются цифры на 60%, а то и на 100% меньше реальных. Умножаем условность на условность и получаем очень большую условность. Условность фиксируется в договоре, а потом выходит боком заказчику и исполнителю.

В тендерах все могут всё, но это только кажущиеся возможности.


8. Устранение ошибок


В крупных агентствах на тестирование отводится 30% времени проекта. В штате работает сотрудник, который проверяет сайт на все возможные ошибки. Наличие такого человека экономит нервы заказчика, но значительно увеличивает стоимость проекта. В краснодарских агентствах таких людей нет, даже если вам скажут, что они есть — не верьте (и да, я проверял). Клиенты просто не готовы за это платить. После официальной сдачи проекта, вы ещё долго будете вносить микроправки, что оттянет не на один месяц запуск проекта.


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


Куда бежать и что делать?


Как клиент вы не можете повлиять на пункты № 2, 4, 6, 8, однако в остальном всё зависит именно от вас. Вы не представляете насколько ваша работа важна для успеха всего проекта. Придерживайтесь этих простых правил и вам гораздо проще будет работать с подрядчиком:


1. Не торопите с оценками


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

БЫСТРО ЦЕНУ ГОВОРЯТ ТОЛЬКО ГОЛОДНЫЕ СТУДЕНТЫ И НАЧИНАЮЩИЕ ВЕБ-СТУДИИ. ГРАМОТНЫЙ ПОДРЯДЧИК ЛИБО ИЗМОТАЕТ ВАС ДОПОЛНИТЕЛЬНЫМИ ВОПРОСАМИ, ЛИБО ДАСТ ЦИФРЫ В ОЧЕНЬ ШИРОКОМ ДИАПАЗОНЕ.

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


2. Вникайте в техническое задание


В идеале обсуждение технического задания должно занимать 50% работы по проекту. Это не просто бумажка, которую нужно подписать, а единственное, что подтверждает ваши договорённости с подрядчиком. Проговорите все непонятные моменты в ТЗ, остановитесь на каждом пункте. Представьте как этот функционал будет выглядеть и работать. Попросите отрисовать прототипы будущего сайта и снова пофантазируйте как всё это будет работать на сайте. Чем больше времени тратите на этапе планирования, тем быстрее и качественнее делается проект.


3. Контролируйте промежуточные этапы


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


4. Выполняйте свою часть работы вовремя


Заказчик участвует в проекте не меньше исполнителя: согласовывает правки, макеты, предоставляет контент, тестирует ошибки, проводит оплаты и тд. Если на каком-то из этапов вы затягиваете сроки, то будьте готовы к тому, что общий тайминг проекта тоже растянется. Особо проблемные участки - это согласование дизайн-макетов и подготовка контента.


5. Грамотно работайте с “хотелками”


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

Мы используем Гугл докс для планирования мелких правок


6. С мелкими задачам работайте по постоплате


Мелкие технические правки лучшее делать в формате поддержки. То есть оплачиваете подрядчику ежемесячно, к примеру, 10 часов работы технического отдела, и он в рамках этих часов вносит любые правки по проекту. Так вы экономите время на оценке проекта. Мелочь проще сделать сразу, чем тратить время на оценку, согласование цены, оформление счетов и актов.


7. Имейте эксперта на вашей стороне


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

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


8. Не меняйте контактных лиц без необходимости


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

Это похоже на письмо дяди Фёдора родителям, когда каждый писал о своём


9. Отправляйте правки оптом


Увидели ошибки на сайте? Не спешите их сразу отправлять разработчику. Просмотрите внимательно все страницы, покажите сотрудникам, возьмите 1-2 дня на вдумчивую проверку. Все правки соберите в один файл и только после этого отправляйте подрядчику. Если сразу начнёте сыпать правками в почте, сообщениями в скайпе или телефонных переговорах, то половина информации потеряется, сроки исправления растянуться, а выполнение сложно будет проконтролировать.

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

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