Нет ТЗ? Не страшно, мы все поймем

Довольно часто клиент приходит к нам с общим пониманием задачи, без каких-либо детализаций и формализаций. Бывает даже, что все ТЗ выглядит так: «Я хочу, чтобы на телефоне мой клиент мог делать вот так, и это принесет моему бизнесу успех».

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

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

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

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

• Определим суть бизнеса клиента - желательно понимать ее, чтобы не добавить клиенту новую боль своими решениями. Мы работаем иначе: если мы начали общаться с клиентом, значит, мы заранее изучили специфику бизнеса. Да, на 100% мы не знаем деталей, но некоторые особенности нам известны.
  
• Определим место включения - если мы не знаем, где и как должен быть интегрирован наш модуль в общую экосистему заказчика, значит, этап валидации не пройден. А если пройден - фиксируем, какое ПО куда подключается и как это влияет на текущие процессы.
  
• Опишем процесс - настало время схемы ведения бизнес-процесса. Используем BPMN-нотацию: она хорошо читаема без глубокого знания ИТ. К тому же, если что-то будет работать неверно, клиент всегда сможет указать пальцем на нужное место на схеме.
  
• Напишем ТЗ - интересная часть работы, поскольку зачастую до конца ТЗ дочитывает только тот, кто его пишет. Но есть и обратная сторона: в случае претензий, обоснование строится именно на уровне ТЗ. Поэтому желательно его все же прочесть. А если нет сил и времени на написание, вычитку и согласование, остается один путь.
  
• Напишем функциональное задание - упрощенное, но тоже очень конкретное для исполнения. Минус состоит в том, что полностью определить состав работ несколько сложнее, особенно если работа выполняется впервые. Огромный плюс такого задания - двустороннее понимание того, что будет сделано и как это будет работать. Да, здесь команде исполнителей придётся больше поработать над формализацией, ведь простора для творчества тоже много.

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