Как мы придумали LEGO-подход к разработке и успешно внедряем его

Привет!

Я — Михаил, мы в Ошке создаём веб-сервисы, а также консультируем по вопросам продуктовой разработки. Мы постоянно сталкиваемся с очень интересным феноменом: заказчики просят оценить проект в сроках и стоимости, не имея оформленной идеи проекта. Очень часто все, что есть — пара голосовых сообщений. При этом оценку просят очень быстро.

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

Вполне логично, что недостаток требований часто решают написанием технического задания. Техническое задание было актуально, когда команды разработки использовали waterfall — негибкую модель разработки: договорились в начале на объем работ, описали все подводные камни, сделали продукт, сдали. Шаг в сторону — допсоглашение. При таком формате взаимодействия техзадание воспринимается как единственный источник правды — в нем стороны согласились о видении продукта, по любым вопросам нужно обращаться к техзаданию.

Сейчас практически каждая команда разработки придерживается Agile-подходов к разработке. Эти «гибкие» методологии на то и гибкие, что детальная проработка задач ведется по мере программа проекта. Конечно, в рамках Agile тоже требуется видение продукта, но оно необязательно должно быть максимально детальным и проработанным. Agile позволяет быстрее приступить к разработке и двигаться "от простого к сложному" — сначала сделать минимально жизнеспособный продукт, максимально быстро добраться до релиза, потом — увеличивать функционал продукта.

Получается, что Agile и техзадание — несовместимые понятия. Одно говорит «давай определим примерный продукт, детали проработаем в процессе», другое — про глубочайшую проработку контекста и неспособность адаптации к изменениям в продукте. Идеальным решением было бы такое же "гибкое" техническое задание, которое формализует требования к продукту, но оставляет проработку деталей на более поздние стадии аналитики.

Мы в Ошке разработали формат «LEGO-инструкция к стартапу». Мы подготавливаем нефункциональные требования, формируем пользовательские сценарии (User Stories), документируем их в виде диаграмм с логикой продукта и архитектурой базы данных. После определения сценариев мы создаём вайрфреймы – прототипы интерфейса, которые показывают пользовательские сценарии в картинках. Наш формат максимально похож на Product Discovery — фазу в развитии продукта, когда команда изучает рынок и формирует требования к продукту.

Наша задача в рамках исследования — максимально глубоко описать продукт "на бумаге", увидеть сложные моменты логики и проработать их, не приступая к разработке. Однако, сделать это не в виде текста 12 кегля Times New Roman, а более понятно и гибко. Мы также описываем план развития продукта: какие функции должны быть в первой версии, какие — во второй и так далее.

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

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

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

Я также веду Телеграм-канал, где рассказываю про то, как строится наша компания по разработке и консалтингу. Буду рад видеть!