На конференции аналитиков Analyst days #10 было выступление архитектора с докладом как раскопать legacy систему без документации или при наличии противоречивой документации («4 правила археолога: как «раскопать» систему» Евгений Асламов). Отличный доклад.

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



Мне приходилось это делать. Где-то интуитивно было понимание кого, о чем спросить. Иногда подсказывал кто-то из проектной команды. Было даже так, что о каком-то триггере в твоей функциональности узнаешь после прилетевшего инцидента из отдела поддержки. Что-то прояснилось в рамках модернизации функциональности. Ну и самое топовое — самостоятельное тестирование и использование продукта.

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

Только это будет не 4 правила как в докладе архитектора, а 4 шага:

Шаг номер один. Собери всю документацию по реализованному решению.

1. Идеально, если она будет содержать по каждому функциональному блоку:

• описание потребности в этой функциональности в любом инструменте (просто текстом, таблички, какие-то схемы в любой нотации);
• описание фронта: поведение элементов, wf пользователя;
• описание бэка: внутренние сервисы, описание бд и компонентов;
• описание интеграционных сервисов, включая примеры запросов и ответов, статусы ответов.

2. Всю нормативную и регламентирующую документацию, которая задаёт границы продукты: ФЗ, регламенты, приказы, проекты.

3. ТЗ/ТП/спецификации (подчеркни нужное) — документ, в котором были описаны требования к функциональности.

4. Запротоколированные договоренности, в которых можно проследить какие-то не сделанные пожелания.

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

Шаг номер два. Тестирование

Вне зависимости есть вышеперечисленные документы или нет, следующим шагом должно стать тестирование продукта.

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

Шаг номер три. Вопросы

Выясняешь у начальника (линейного, руководителя проекта, лида и прочее — нужное подчеркнуть) кто может проконсультировать по вопросам. Готовишь фактуру вопросов. Задаёшь, конспектируешь ответ. Идёшь пропускать все это через себя.

Шаг номер четыре. Оформи то, что получил

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

По-хорошему следующие шаги должны звучать так: иди работай

Но что хочется сказать на самом деле в завершении статьи: задача аналитика — оставить после себя структурированную информацию.

Оставить — это значит оформить и выложить в общедоступное место. А не разобраться, как школьник с новыми знаниями, и оставить их при себе.

Структурированная информация — это значит разложить по полочкам все то, что до тебя плохо лежало.

Ничего не бойтесь и дерзайте!