Сроки разработки сайтов: ITConstruct

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

Дигибу узнал у ведущих российских веб-студий, как они работают со сроками разработки проектов.

ITConstruct
Роман Петров

Рассказывает Роман Петров

Директор компании ITConstruct, г. Новосибирск

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

Для начала хочу рассказать, почему важно соблюдение сроков и их уменьшение:

  • Более быстрая разработка даёт больше денег. Это связано с тем, что при заключении договора обычно фиксируется какая-то стоимость работ, и, если разработка затягивается, инфляция съедает часть прибыли.
  • Более быстрая разработка уменьшает загрузку сотрудников и экономит деньги компании. Причина — человеку не требуется дополнительное время на повторное вникание в проект.
  • Более быстрая разработка уменьшает претензии заказчика. При долгой разработке может смениться менеджер со стороны заказчика, могут измениться цели и задачи бизнеса или появиться новые, не требовавшиеся ранее блоки проекта. При быстрой разработке есть шанс уложиться в начальные требования.

Теперь немного о нас. По состоянию на 2012 год ITConstruct работает в сегменте средних проектов, каждый из которых по отдельности не способен обеспечить работой всю компанию. Поэтому нам необходимо постоянно вести несколько проектов одновременно. Например, в 2011 году мы разработали около 60 проектов. При средней длительности проекта 4-6 месяцев от отправки коммерческого предложения до запуска сайта это означает, что в работе на разных стадиях находится более 40 проектов, и ещё несколько десятков проектов находятся на технической поддержке.

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

Чтобы решить проблемы с задержками сроков разработки сайтов, необходимо определить их причины. Сейчас нам они видятся так.

С января 2012 года мы внедряем у себя работу по ТОС (Теория ограничений), одним из результатов внедрения стало дерево существующей действительности, по которому заказчик всегда будет недоволен разработанным сайтом.

Поэтому, работа со сроками проекта начинается с момента продажи.

Например, большинство наших конкурентов обещают разработку корпоративного сайта за 1-2 месяца, а интернет-магазина — за 2-3. Мы называем сроки в 3-4 месяца для корпоративного сайта и около 6 месяцев — для интернет-магазина. Естественно, чистой работы в корпоративном сайте — 1-1,5 месяца, а остальное — это как раз буфер и задержки на согласования. Как правило, такая методика позволяет уже на этапе продажи снять завышенные ожидания заказчика и предотвратить часть последующих проблем. Сразу оговорюсь, что не все заказчики готовы так работать. Однако, мы специально проводим ликбезы и работаем с заказчиками по данному вопросу.

Далее мы разбиваем проект на этапы, каждый из которых относительно независим и может быть закрыт актом приёмки-сдачи работ. Например, это:

  1. Разработка прототипов.
  2. Техническое задание.
  3. Дизайн главной страницы.
  4. Дизайн внутренних страниц.
  5. Вёрстка.
  6. Программирование.
  7. Гарантийное обслуживание.

В случае задержек на каком-то этапе мы официальным письмом сообщаем клиенту о задержке, причине задержке (чаще всего это затягивание ответа со стороны заказчика) и стараемся договориться о переносе сроков.

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

Для учёта этих особенностей при назывании сроков заказчику мы используем следующие приемы:

  • Запланированное в часах время переводится в рабочие дни из расчёта 4 часа/день. Оставшиеся 4 часа — это как раз буфер на согласования, задержки, связанные с болезнями, отпусками, работой над другими проектами.
  • В случае, если какой-то этап уже близок к «съеданию» буфера, мы уведомляем заказчика письмом о сдвиге сроков не только этого этапа, но и последующих.
  • В договор могут включаться штрафные санкции для заказчика — при задержке согласования какого-либо этапа мы можем перенести начало следующего этапа на более удобное для нас время.
  • При проблемах в коммуникациях мы готовы на возврат ранее перечисленных средств, и это оказывается более выгодным, чем «тянуть» проект, уходя на нём в минус.
  • Мы стараемся разгрузить узкое звено, менеджеров проектов, от работы, которую могли бы выполнить другие сотрудники. Например, первичное информирование клиента о сроках разработки проводит отдел продаж и именно на нем «отсеиваются» заранее проблемные клиенты.

Естественно, несмотря на предпринимаемые меры, часть проектов всё-таки идут с запозданием. Однако, меры, которые мы предпринимаем, показывают хорошую динамику, и мы часто готовы гарантировать соблюдение сроков (при одновременном соблюдении своих обязательств заказчиком). Чаще всего это финансовые гарантии.