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

В первую очередь, если говорить о моем подходе к работе над проектами, очень важно научиться ставить и отвечать на два вопроса:

1. Какую задачу бизнес решает?
2. Какой результат мы ожидаем на выходе?

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

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

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

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

По мере того как наш проект обрастает сущностями, я добавляю новые листя в mindmap, стараюсь их структурировать по домену, специфике работы, исполнителю, приоритету и так далее, зависит от конкретного проекта.

Тут, стоит сказать, что для mindmaps я использую кроссплатформеный opensource продукт FreeMind, с функциональностью более-менее идентичной коммерческим аналогам. Из полезных возможностей freemind что стоит отметить:

• Возможность добавлять маркеры-иконки к узлам карты
• Freemind сохраняет карту в XML (а не экспортирует), что позволяет свободно оперировать с информацией карты и генерировать необходимые вам артефакты
• Возможность добавлять текстовые, а точнее HTML описания для узлов карты. Я это использую как метаинформацию, которую использую в зависимости от маркера при генерации артефактов
• Возможность помимо текстовых описаний добавлять аттрибуты, которые, я например использую для оценки для отдельных узлов, и на выходе получаю суммарную оценку по проекту

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

Сам скрипт, для тех кто заинтересовался.

Важно, в процессе выяснения деталей, разбивать функциональность на задачи максимум, по 4-8 часов, уменьшая, таким образом, риски и еще раз проясняя для себя, суть того что должно быть сделано. Если возникают сложности с оценкой, вполне возможно, задача недостаточно мелко разбита, либо недовыяснена. В таком случае, её стоит отложить до следующей итерации, либо продолжать выяснять детали. После этого, я еще раз могу проговорить это с клиентом, чтобы убедиться, что мы говорим об одном и том же и одинаково понимаем процесс и финальный результат.

Посколько компания у нас аутсорсинговая, то через нас проходят сотни самых разных проектов, связанных с торговлей, маркетингом, банками, медициной и страхованием. Отдельная тонкость, это выяснение деталей проектов доменная отрасль которых неизвестна, иногда этот процесс может быть усложнен тем, что приходится работать через посредника, не обладающего всей информацией. Подход, который я обычно стараюсь применить, это создание лаконичного языка в рамках домена, который мы с клиентом обсуждаем. Иногда выручает математическая нотация, иногда что-то похожее на python. Вот пример логики описанной при помощи подобного DSL:

ADD A(100) (transfer_id: 10)
DEC A(50) (SOLD by sale_order_id: X) ADD A(50), order_id: X
DEC A(10) (SOLD by sale_order_id: Y) ADD A(10), order_id: Y

Такая лаконичность, при условии что все “разговаривают” на одном и тоже языке, позволяет “втискивать” в несколько строк примера страницы документации, ну и как следствие упрощает работу с описанием-изменением такого рода правил.

Благодаря тому что freemind сохраняет карты в форматированный XML их можно ложить в репозиторий и отслеживать изменения, практически также удобно как и код. Вообще, надо сказать я большой фанат форматов которые читаются любым редактором, не требуя специального софта, версионируются в репозитории. Так я проникся нежной любовью к markdown, asciidoc и гораздо меньше LaTeX.

Если вы работаете в высокотехнологичном окружении, где все способны читать код, возможно вам больше подойдет Jupyther, opensource платформа, позволяющая писать и тут же запускать код на python/ruby, описывать его в markdown, визуализировать графики и многое другое. Например так это может выглядеть, и является стандартом де-факто в среде data scientists.