Продолжая взаимодействие с настоящим сайтом, вы выражаете свое согласие с тем, что ваши пользовательские данные (сведения о местоположении; тип и версия ОС; тип и версия Браузера; тип устройства и разрешение его экрана; источник откуда пришел на сайт пользователь; с какого сайта или по какой рекламе; язык ОС и Браузера; какие страницы открывает и на какие кнопки нажимает пользователь) будут обрабатываться ООО «Тадос» в целях сбора статистических данных о посетителях сайта и функционировании сайта в течение 3 месяцев. В случае, если вы не хотите, чтобы ваши данные обрабатывались, покиньте сайт.

Четыре года мы работали с проектами «с нуля» по распространенной схеме:

  1. Приходит заказчик, описывает проблему и желаемое решение.
  2. Мы изучаем бизнес-процессы и составляем детальное техническое задание.
  3. Подписываем договор, получаем предоплату и приступаем к разработке.
  4. Сдаем работу с проверкой ТЗ и получаем оставшуюся часть оплаты.

Почему такой формат работы оказался не эффективен

Долгое составление ТЗ

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

Ошибки в ТЗ

Учесть все требования и нюансы нереально. Продукт на этом этапе воспринимается как следующий Новый Год. Будут мандарины, елка, подарки и бой курантов. Конкретные детали — в следующем декабре после двадцатого числа.

Отсутствие оперативной обратной связи

Заказчик ждет итоговый вариант, чтобы сразу внедрять. Смотреть на промежуточные результаты не горит желанием — на это уходит время: «Как примем, так и скажем, что и как».

Долгий процесс разработки

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

В итоге у заказчика возникают сложности:

«Так просто и дорого»

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

«Кто вообще писал ТЗ?»

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

«Это так не работает»

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

Переход на новый формат работы

Мы скорректировали подход, чтобы заказчик получал нужный бизнесу продукт быстрее. Как стали работать:

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

Результаты

Быстрая разработка минимального продукта (3−4 недели) и дальнейшее развитие небольшими итерациями.

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

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

Разработка в порядке приоритета — реализуем сначала то, что нужно в первую очередь.