Процесс разработки веб-проекта

В этой статье расскажу как мы делаем проекты. 

На входе - компания или человек, желающий создать сайт. 

Концепт

Он описывает проект в виде концепта, указывая основные значащие детали проекта в письменном виде. 

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

КП

На базе этого мы делаем КП - это оценка сроков и бюджета проекта. Мы разбиваем на модули проект и грубо оцениваем затраты в часах, умноженных на почасовую ставку. 

КП - это Excel файл со сметой, примерным сроком работ и условиями работы. 

Важно дать понять заказчику, что это примерная смета. Она не является окончательной, а скорее служит ориентиром. Почему не конечная? Да потому что у заказчика на этапе основного ТЗ или в ходе проекта будет еще 100500 хотелок, которые вы сейчас никак не можете учесть. 

Договор

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

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

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

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

1 этап - создание технического задания

ТЗ создается на основную часть программы, которая планируется к 1 версии. Не нужно здесь прорабатывать далеко идущие планы - нужно прописать то, что мы внедрим в 1 релизе. 

Чем меньше ТЗ - тем быстрее будет 1 полноценный релиз, тем меньше будет бюджет 1 версии.

Прописываем детально что и как должно работать:

  • личные кабинеты
  • страницы
  • таблицы
  • формы
  • процессы
  • структуру БД
  • формат и объем интеграций

Чем детальнее все прописано, тем проще оценить, тем меньше повода для будущих споров с клиентом. 

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

После завершения работы над ТЗ делается оценка проекта по страницам. 

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

Именно эта оценка служит дальнейшим основанием для сметы дальнейших этапов. 

Этап 2 - реализация 

Любой этап - это доп. соглашение к основному договору. Оно содержит 3 ключевых элемента: 

  • что нужно сделать - ТЗ на этап
  • сколько стоит - смета этапа
  • календарный план - сроки этапа

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

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

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

Этап 3 Шлифовка и внедрение

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

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

Главная болезнь многих владельцев продукта - бесконечное наращивание возможностей продукта. Им хочется по максимуму впихнуть в свой продукт, перед релизом, в надежде попасть в потребности клиента. И это может затянуть внедрение на 1-2 года! А иногда проект вообще не запускается в эксплуатацию. 

Шлифовка продукта - это хорошо. Существующие возможности должны хорошо и удобно работать. Но менять объем до релиза - это плохая практика. Должны быть очень веские причины для этого. 

Последующие этапы 

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

Все эти доработки также имеет смысл оформлять в этап проекта. В некоторых случаях мы по факту выставляем счет и оформляем акт по работам. 

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

Предоплата или постоплата? 

Мы работаем в большинстве ситуаций по 100% предоплате за этап. 

В некоторых случаях, если доверие к заказчику велико, то идем на предоплату 50%.

Не рекомендую делать на 1 этапе постоплату в 50 или 100%. Вы как бизнес никуда не денетесь, а вот заказчик вполне может передумать и не доплачивать в итоге остаток или за весь этап. 

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

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

В моей практике было примерно 3-4 раза когда, нам не выплатили в итоге по этапам. Обещали-обещали, и не выплатили. Ошибка была в том, что не нужно доверять на словах (особенно когда это постоянно оттягивается). Нужно построить такой процесс, который исключит эти проблемы на корню. 

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

Заключение

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

Смотрите также:

SQL-инструмент для создания личных кабинетов на сайте

Суть подхода и история создания Falcon Space
Веб-платформа для создания личных кабинетов

Платформа Falcon Space

Это снижение стоимости владения

за счет меньшего количества людей для поддержки

Это быстрое внесение изменений

по ходу эксплуатации программы

Это современный интерфейс

полная адаптация под мобильные устройства

Веб-приложения на MS SQL. Партнерская программа для разработчиков и веб-студий

Вы можете разрабатывать самостоятельно или сотрудничать с нами в плане веб-разработки на платформе Falcon Space, используя только SQL и HTML.
Смотреть примеры с кодом SQL
Документация по платформе
Работа на MS SQL Server
Демо-стенд компонентов
На стенде можно посмотреть различные компоненты в действии: таблицы, формы, модальные окна, диаграммы, карта и т.д.
Демо-сайт решений
Базисные решения, которые можно гибко адаптировать под себя: менять внешний вид, бизнес-логику и даже структуру базы данных.
Получить оценку проекта
Создайте концепцию проекта на основе нашего шаблона и получите оценку проекта в виде КП.