Мы разрабатываем ПО для малого и среднего бизнеса. У заказчиков сложные процессы, которые укладывать в рамки готовых продуктов неэффективно. Часто готовых решений нет.
Четыре года с момента основания работали по распространенной схеме:
- Приходит заказчик, описывает проблему и желаемое решение.
- Мы изучаем бизнес-процессы и составляем детальное техническое задание.
- Подписываем договор, получаем предоплату и приступаем к разработке.
- Сдаем работу с проверкой ТЗ и получаем оставшуюся часть оплаты.
Почему такой формат работы оказался не эффективен
Со стороны заказчика проектом руководит собственник бизнеса или руководитель одного из отделов. У них и до проекта по разработке времени не хватало, а стало ещё меньше. Выделить отдельного сотрудника малый и средний бизнес не готов. В результате уточнение небольшого вопроса по техническому заданию затягивалось на недели. В лучшем случае техническое задание согласовывали за полтора месяца.
Заказчик привлекает других сотрудников к обсуждению, но учесть все — нереально. Продукт на этом этапе воспринимается как будущий Новый Год. Будут мандарины, елка, подарки и бой курантов. Конкретные детали — в следующем декабре после двадцатого числа.
Заказчик ждет итоговый вариант, чтобы сразу внедрять. Смотреть на промежуточные результаты не горит желанием — на это уходит время: «Как примем, так и скажем, что и как».
Между составлением ТЗ и сдачей рабочей версии проходит несколько месяцев. У заказчика за это время может многое поменяться — а значит, снова оттянется время внедрения продукта.
В итоге при сдаче проектов возникали сложности:
«Так просто и дорого»
Проходит несколько недель, мы ищем обратной связи и встречаем негатив. Заказчик считает, что делали долго и дорого. Начинаем разбираться. Оказывается, часть функционала не используется в принципе. Зато поступает куча жалоб от менеджеров по продажам, для которых не реализовали систему напоминаний на email. В техническом задании про неё ни слова.
«Кто вообще писал ТЗ?»
Ситуация возникает, когда у заказчика меняется руководитель проекта. Хуже всего, когда собственник бизнеса активно участвует в разработке, а затем делегирует всё сотруднику. Последний не знает планов на будущее, которые закладывались при проектировании. Начинается долгий разбор, что и для чего нужно.
«Это так не работает»
Поменялись бизнес-процессы, появились новые отделы/исчезли старые — ТЗ стало неактуальным. Возможность масштабирования и гибкого изменения должна быть заложена в техническое задание. На практике этому редко уделяется внимание, а платить за составление корректного ТЗ компании не готовы.
Переход на новый формат работы
Мы скорректировали подход, чтобы заказчик получал продукт, закрывающий потребности компании, быстрее. Как стали работать:
- Приходит заказчик и описывает проблему. Составляем общее описание проекта и список функций, которые нужны в ближайшее время.
- Называем примерную стоимость всего проекта и первого этапа, на котором внедряем самые важные функции. Первый этап не должен занять больше 3−4 недель.
- Подписываем договор, получаем полную оплату первого этапа и приступаем к разработке.
- Сдаем результат. Упор на функции, на уровне интерфейса — минимализм.
- Ждем пожеланий по доработке или внедрению новых функций и начинаем новую итерацию.
С чего начинается правильная разработка, какие методологии мы используем и как создается продукт? Почитайте о минимальных функциях для внедрения ПО в работу компании, а также о комфортном расширении продукта.
Результаты
Быстрая разработка минимального продукта (3−4 недели) и дальнейшее его развитие небольшими итерациями.
После каждой итерации вы можете внедрить решение и проверить, удобно оно или нет.
Снижение затрат со стороны заказчика на доработки продукта — правки коснутся небольшой части, не придется вносить большие изменения.
Разработка в порядке приоритета — реализуем сначала то, что нужно вам в первую очередь.