Проблема соблюдения сроков при веб-разработке

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

Как-то слышал статистику, что порядка 65% веб-проектов в мире срывают сроки при разработке, а что уже говорить о нашем диком рынке!? Поэтому постараюсь помочь решить эту проблему в статье.

Оценка сроков

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

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

• Опыт менеджера, который будет вести проект.
• Примечание: менеджер проекта имеет опыт создания проектов и знает много подводных камней, поэтому именно он основной ответственный за временные оценки и соблюдение сроков реализации проекта.
• Опыт людей, которые будут участвовать в проекте (дизайнер, верстальщик, программист и т.д.).
• Примечание: конкретные специалисты являются более компетентными в своей области, чем менеджер проекта и могут указать на видимые сложности, которые тянут за собой увеличение сроков. Кроме того, есть люди с разным опытом и одно и то же задание, например, 2 разных программиста, будут делать по-разному и с разными временными затратами, поэтому очень важно чтобы оценивали не просто специалисты, а именно те люди, которые будут работать над этим проектом.
• Задание дробится на этапы, которые зависят от самого сайта и его сложности. Каждый этап оценивается отдельно с временным запасом не меньше 20%. Оценивает ответственный за этап и передает информацию менеджеру проекта, который собирает информацию и дает общие сроки.
• Примечание: это по методологиям управления проектами весьма полезная штука, которая позволяет более точно учесть каждую мелочь. Буфер берется для соблюдения гарантий, т.к. многие люди имеют свойство недооценивать задачи, либо относятся невнимательно к оценкам, особенно при большом потоке запросов.
• До клиента доносится несколько важных вещей: а) Сроки являются предварительной оценкой и могут быть уточнены после составления подробного ТЗ. б) Время на принятие этапов не учитывается в сроках реализации проекта. в) Сроки на разработку (доработку) технического задания также не учитываются.
• Примечание: то, что сроки предварительные – без вариантов, и клиенты это тоже понимают. Важно донести до клиента то, что прием и переделка результатов не учитывается в сроках, т.к. не может быть известна заранее. Самый тонкий момент при принятии – это дизайн: у каждого человека свои предпочтения и ощущения красоты, поэтому надеяться даже на лучшего дизайнера в мире нельзя, все равно у клиента наверняка будут предложения что-то изменить и иногда это может затянуться не на один месяц. То же касается и разработки технического задания, которое во многом зависит от клиента. Были случаи, когда клиент говорил, что хочет «сайт-визитку», а потом это все выливалось в портал, так сказать: «Аппетит приходит во время еды».
• Оценка сроков дается на каждый этап в формате рабочих дней «от» и «до».
• Примечание: клиент всегда что-то планирует и должен понимать, когда будет закончены работы. Кроме того, даже опытный разработчик не скажет точные сроки выполнения работы до дня. Если проект (этап) будет закончен раньше – это только плюс разработчику, а если позже – можно и клиента потерять.
• К оценке менеджера проекта обязательно плюсуется буфер времени от 50% до 100%.
• Примечание: буфер прибавляется для возможности выполнения гарантий, которые фиксируются в договоре. Обычно мы делаем проект полностью, силами своих специалистов, и не превышаем 20-30% сверх реальной оценки, иногда срыв достигает 40-50%, если возникает ряд подводных камней, поэтому минимум мы закладываем 50% буфера в сроках. При большой загрузке (обычно осень) или для специфических задач приходится привлекать фрилансеров: конечно, у нас есть ряд проверенных фрилансеров, с которыми мы работали, либо по рекомендации знакомых, но этот ресурс достаточно сложно управляемый и в 90% случаев срывает сроки, поэтому по нашим процедурам при срыве сроков мы отказываемся от услуг недобросовестного фрилансера и отдаем работу другому, такой большой буфер нужен для того, чтобы успеть провернуть данную схему. Фрилансеров используем только на отдельные задачи (этапы), поэтому на 100% не весь проект увеличивается, а только работа фрилансеров. Фриланс использовать крайне нежелательно.

Соблюдение сроков

После, когда клиент соглашается на наши условия, начинается сам процесс разработки. Есть два варианта: 1. Заключить отдельный договор на разработку ТЗ. 2. Заключить договор на сайт, к которому подписать приложение №1. Бриф, на основе которого будет разрабатываться ТЗ и после приложение №2. ТЗ. Первый вариант более правильный с точки зрения разработчика, но кроет риск потерять клиента после составления ТЗ – он просто может уйти к конкуренту с точным ТЗ. Второй вариант более рискованный – в договоре фиксируется список функционала, но каким он будет разработчик узнает только после составления ТЗ и можно получить себестоимость выше, чем рассчитывалась в начале, когда клиенту делалось предварительное коммерческое предложение, что приведет к снижению прибыльности проекта.

ТЗ пишет менеджер проекта как самый опытный член команды, ему помогают все другие участники проекта. Должен быть стандартный набор требований, которые обязательно учесть. Само ТЗ должно быть максимально точным и однозначным. Впрочем, есть гибкие методологии разработки, по которым рекомендуется не делать ТЗ очень четкими, а достаточно сделать примерное описание, которое потом будет детализироваться – тактика имеет место особенно для больших проектов, где все сразу не опишешь, но она очень скользкая в плане соблюдения сроков и точности оценки. В любом случае написание ТЗ – это непрерывный процесс коммуникации с клиентом. После ТЗ дается на утверждение клиенту (он его, скорее всего, не будет читать, либо прочтет поверхностно) и подписывается как приложение к договору вместе с календарным планом.

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

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

При работе над проектом клиент почти всегда вставляет свои пять копеек и на ходу начинает пытаться внести коррективы, дополнения, переделки. Это палка о двух концах: с одной стороны нужно идти клиенту на встречу и делать его жизнь сказкой, а с другой стороны любая, даже самая маленькая переделка – это время и деньги, а значит переделки (доработки) автоматически уменьшают прибыль и ведут к срыву сроков. Полное решение этой проблемы мы до сих пор не можем найти, самый эффективный вариант – все мелкие доработки делать походу и параллельно доносить мысль клиенту, что это может привести к срыву сроков, а все крупные доработки выносить во второй этап, который будет иметь отдельную стоимость и сроки. Очень важный момент, у многих разработчиков вызывает проблемы, поэтому еще перед началом работы нужно предупредить клиента о том, как будет происходить взаимодействие по доработкам, а все детали четко закрепить в ТЗ. Желательно обговорить рамки изменений, которые допустимы по ходу работы.

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

Немного статистики

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

Примерно год назад в рамках повышения конкурентоспособности мы решили узнать, чем живут конкуренты. Мелочиться не стали, все-таки мы стремимся быть лучшими! Мы взяли топ 20 студий рунета по версии рейтинга Теглайн и постучались к ним, как клиенты. Секретной информации мы, безусловно, не получили, но общую статистику собрали по ценам и срокам. Ответили не все, ровно половина компаний прислали предложения. Всем на оценку отправлялось примерное ТЗ на несложный корпоративный сайт. Некоторые оценивали по месяцам, некоторые по рабочим дням, мы все перевели в единый формат, вот что получилось в итоге (названия компаний опускаем, по понятным причинам):

• 57+ раб. дней.
• 46 раб. дней.
• 45 раб. дней.
• 69 раб. дней.
• 57-69 раб. дней.
• 51 раб. дней.
• 40 раб. дней.
• 57-80 раб. дней.
• 52 раб. дней.
• 55 раб. дней.

В среднем в топовых компаниях на корпоративный сайт отводится почти 53 рабочих дня или 2,3 календарных месяца! Сразу понятно, что сумма затраченного времени специалистов будет меньше, но есть определенные проектные процедуры, а сами компании понимают, что еще нужно работать с клиентом и вероятно придется что-то переделывать.

Несколько советов:

• Очень нежелательно брать проекты, которые должны быть готовы «еще вчера». Клиенты, которые сильно торопятся, обычно приносят много проблем.
• Нельзя начинать проект без четких требований и договоренностей.
• Если проект делается не с нуля, а дорабатывается (переделывается) после других разработчиков – это смело еще +50% к срокам: разбирать чужие идеи, код и т.д. – очень сложно.
• Никогда не обещайте клиентам то, что не можете сделать или не знаете как именно. Сделать такое может и получиться, но срыв сроков будет на 90%.
• Автоматизируйте все рутинные и однотипные операции – это позволить выполнять задачи быстрее. При этом автоматизация должна еще повышать качество, а не наоборот.
• Собирайте и используйте собственные наработки: часто задачи повторяются в разных проектах.
• Организуйте хорошую командную работу, даже если команда распределенная и находится в разных городах.
• Используйте известные практики менеджмента для разных задач: PMBOK, CMM, Agile/Scrum, TQM и т.д. Менеджмент – это не модное слово, а основа эффективной работы компании!
• Используйте специальное ПО для помощи в разработке: системы управления проектами, системы управления версиями, софт для автоматического тестирования и т.д.
• Следите за сроками всегда, больше половины клиентов после срыва сроков уйдут к конкурентам!

P.S. Чтобы получать наши новые статьи раньше других или просто не пропустить новые публикации — подписывайтесь на нас в Facebook, VK, Twitter, LiveJournal и LinkedIn