Разработка веб проектов. Описание и этапы

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

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

Концепт

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

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

КП

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

КП - это 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

В 2-3 раза экономнее и быстрее, чем заказная разработка
Более гибкая, чем коробочные решения и облачные сервисы
Используйте готовые решения и изменяйте под свои потребности

Ищем партнеров-разработчиков на T-SQL

Прямая работа с заказчиками как ИП или самозанятый. Нужно знать только SQL и HTML
Работа на MS SQL Server
Нужна бесплатная консультация?
Планируете делать веб-проект?
Сайт использует Cookie. Правила конфиденциальности OK