— И это после всего, что я вам рассказал? — я, конечно, уже слышал подобные заявления от потенциальных клиентов, но каждый раз удивлялся.
— Ну да. Зачем нам эти прототипы и функциональные спецификации? Я уже несколько проектов запустил со своей командой и точно могу сказать: никто документацию не читает.
— А как же вы ставите задачу на разработку?
— Пишу небольшую вводную — и всё. В основном, на словах объясняю. Я же каждый день с разрабами общаюсь. Да и сам немного программист. Мы же с вами оба понимаем, что этап проектирования — это просто способ для вас заработать дополнительных денег.

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

— Ну что ж, понимаю. Тогда давайте попробую вам рассказать одну небольшую историю…

Для начала немножко контекста. Меня зовут Егор Камелев, я проектирую интерфейсы с 2006 года. Работал в агентствах, внутри компаний, на аутсорсе. Основал Проекторат. Специализируюсь на сложных информационных системах. До сих пор в деле. Вроде, всё. Теперь поехали!

В 2018 году я решил отойти от деятельности проектировщика интерфейсов. Спроектировал стартап (конструктор одностраничных сайтов), нашёл инвестора, собрал команду — и мы приступили к разработке.

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

Сроки разрабы выдерживали железобетонно. К проектной документации не требовательны. Я поначалу предоставлял небольшое ТЗ, поверхностный интерактивный прототип в Axure и основные экраны в Фигме.

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

Часть таких самостоятельных решений мне нравились, а часть — нет. И я просил то там, то сям что-то переделать. Иногда что-то безобидное вроде сортировки в списках. А иногда посерьёзнее: например, сделали экспорт лендинга в виде архива, а формы с заявками продолжают работать через нашу API и превращаются в тыкву, если баланс не пополнен.

И выстроилась такая схема:

1. Я на коленке готовил проектную документацию (её себестоимость была условные 20к)

2. На её основе разрабы оценивали следующую итерацию (например, месяц работы, а это 250к)

3. Через месяц работа выполнялась, но в ней было несколько вещей, которые меня не устраивали. Я составлял перечень комментариев и вносил их в список задач (себестоимость этой работы составляла ещё условные 20к)

4. На внесение комментариев и доведение результата до идеала уходил ещё месяц ( ещё 250к)

Итого итерация обходилась мне в условные 540к и два месяца.

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

Такая подготовительная работа уже обошлась мне в 50к вместо 20. Но зато через месяц я получил почти то, что мне было нужно. На правки и комментарии ушла дополнительная неделя, но это уже было связано не с плохой проектной документацией, а с невнимательностью разработчиков. Которая, кстати, исчезла через две таких итерации (т.к. на этапе с правками мне уже не нужно было формулировать замечания, а достаточно было ссылаться на пронумерованные невыполненные тезисы, подготовленные до начала работ; а это привело к тому, что разработчики стали внимательнее относиться к этому перечню). Так что подробная документация не только сэкономила денег, но и поменяла поведение команды.

И теперь итерация обходилась мне в условные 300к и один месяц.

Проектная документация за 50к экономила мне 250к. И бесценное время.

Вот такая история.

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

В комментариях наверняка найдутся приверженцы разных подходов со своими примерами из практики.

Напоследок хотел бы привести одну аллегорию, которую мне подкинул один из клиентов.

— Для типовых и понятных задач предварительное проектирование не обязательно. Представьте себе, например, художника. Есть такие профессионалы, которые берут листок бумаги, ручку и без наброска, начисто, сразу рисуют шедевр!

Тогда я не знал, что на это возразить, а сейчас знаю. Не стоит сравнивать творческую работу, которую делаешь для себя с творческой работой, которую делаешь для кого-то. Результат, каким бы хорошим он ни оказался в глазах исполнителя, может не соответствовать ожиданиям клиента. Тогда придётся переделывать. Проектная документация — она как раз позволяет зафиксировать ожидания клиента в том виде, который он может понять и согласовать (речь идёт не о спецификациях — их никто не читает — а о перелинкованных прототипах) до начала работ.

Да, кстати, диалог в начале публикации — не выдуманный. И, как ни грустно мне это признавать, клиент ко мне в работу так и не пошёл.