Абсолютно все веб-студии срывают сроки работ. Кто-то чаще, кто-то реже, но большинство проектов проваливаются с треском под громкое улюлюканье конкурентов и крики заказчика. Громкий скандал банка «Тинькофф Кредитные системы» с одним из самых дорогих агентств России «Студия Артемия Лебедева» показал, что даже высокая стоимость проекта вкупе с квалификацией подрядчика не спасает от срыва сроков. Это больной вопрос клиентов и исполнителей. В статье разберу основные причины факапов и объясню, что делать Заказчику для предотвращения просрочки.

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

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

"Хотелки" заказчика

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

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

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

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

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

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

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

Переключение между проектами

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

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

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

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

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

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

Бесконечная правка багов

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

Если всё обобщить и подытожить, то в срыве сроков виноваты:

— зависимость от человеческого потенциала

— некомпетентность заказчика

— неправильная работа с ожиданиями клиента

— большое количество неизвестных на стадии планирования

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

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

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

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

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

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

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

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

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

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

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

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

Грамотно работайте с «хотелками»

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

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

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

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

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

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

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

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

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

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

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

Иллюстрация: http://vistanews.ru/uploads/posts/2016-01/1454057359_0_961a2_ea2718a8_xxxl.jpg

Степан Корнев
Руководитель коммерческого департамента в Intaro

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

В таких ситуациях, особенно когда в роли ТЗ приходится руководствоваться брифом или словами «а как у них», мы часто предлагаем работу по гибкому контракту и с помесячными отчетами о выполненных работах, двухнедельными спринтами и прочими прелестями agile-разработки.

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

Мурад Эфендиев
Менеджер проектов веб-студии в ITSOFT

К срывам сроков реализации проекта всегда причастны две стороны — заказчик и/или студия, но ответственность всегда несет студия.

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

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

Какого-то уникального нововведения — пилюли, которая решила бы проблемы, к сожалению (а может, и к счастью), нет. У нас в ITSOFT, для снижения вероятности срыва сроков выстроены понятные бизнес-процессы и принято правило, что на каждый проект выделяется ответственный менеджер, который следит за всеми сроками внутри проекта.