Действующие лица:

● JUNIOR — решивший стать аналитиком начинающий боец;

● MIDDLE — системный аналитик, который «понюхал пороху», получил опыт на
нескольких проектах и начал осознавать всю глубину профессии;

● SENIOR — аналитик с богатым опытом разнообразных проектов, большим
количеством навыков и теоретической подготовкой;

● LEAD — эксперт и профессионал в области системного анализа, обладающий,
помимо прочего, хорошими управленческими навыками и лидерскими
качествами;

● ООО «Наша команда» — компания-исполнитель, отвечающей за проектирование и аналитику;

● ООО «Заказчика» — организация клиента.

Если описать общую задачу этапа одним предложением, то здесь мы, в идеале, должны увидеть всю картину целиком.

Слон здесь — это информационная система, на которую у нас есть запрос. Запросы варьируются от конкретных и проработанных («автоматизируйте нам процесс заявок на. командировки — вот схема») до самых абстрактных и объемных («поставьте нам HR-систему»). У любого «сделайте» есть свои границы. И первая задача команды — договориться обо всех «сделайте», то есть, о границах проектируемой системы*.

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

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

Но у LEADа, как и у терапевта, в реальных условиях, есть еще один вопрос для проработки — скрытый, а потому очень коварный. Мало того, что пациент, зачастую, приходит с готовым «диагнозом» из гугла и «решением» от бабы Кати. Так он, в этом случае, хочет получить от терапевта только назначением, ну скажем, к хирургу. А ему не надо к хирургу! Чтобы восстановить зрение ему нужен кардиолог. Вот лично ему. И плевать, что бабе Кате помогла операция. Сколько организмов, столько случаев. И терапевту предстоит не только выяснить (иногда через сопротивление пациента), что поможет удовлетворить запрос, но и доказать свою правоту в неравном бою с авторитетом бабы Кати и гугла.

Как несложно догадаться, SENIOR, MIDDLE и JUNIOR, как врач, ординатор и интерн в сериале «Доктор Хаус», без лишних вопросов разбегаются выполнять задания главного.

Ну, по общим принципам прошлись. Держим веселый кабинет терапевта в голове и разбираем функционал и навыки команды на боевом примере.
Довелось мне несколько лет назад создавать феерическую систему для ООО «Наш заказчик». Они заказали автоматизацию договорных процессов и интеграцию с ERP-системой. Прислали шикарное техническое задание — просто конфетка. В нем содержалось:

● 2 схемы, подозрительно напоминавшие типовые решения из интернета;

● такой же набор требований, описывающий схемы абстрактных процессов в
вакууме;

● информация о том, что у них порядка 300 типовых шаблонов договоров и дс
(типовых шаблонов Карл!) и одно из главных требований к системе —
возможность менять их налету, но с условием, что все предыдущие версии по
прежнему будут работать (300 шаблонов умножить на количество итераций);

● и вишенка на торте: в ERP автоматом должны создаваться записи о контрактах на основе всех этих шаблонов.

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

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

Следовательно: сформированный запрос вообще не может быть реализован ни по одному пункту. А контракт уже заключен и подписан.

Как было сказано ранее, на этом этапе первую скрипку играет LEAD. С него и начнем.

LEAD: Поскольку изначальный запрос был на типовое решение по типовым требованиям, то LEAD выбирает схему, которая позволяет быстро определить все отклонения от них. Схема состоит из 3-х частей:
— сбор демонстрации типового решения по описанию в тз;
— запрос у клиента шаблонов документов на проработку;
— вопросы по интеграции.

Далее, он приходит к «ООО Наш заказчик» и проводит демонстрацию, где по каждому пункту слышит: «Нет, у нас все не так». К концу встречи становится ясно, что запрос не соответствует ни ожиданиям, ни потребностям клиента.
Еще раз: запрос клиента не соответствует его хотелкам. Но понимает это пока только 1 человек.

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

Следовательно, дальнейшее исследование на текущем этапе — это сопоставление:
— заказанных типовых процессов;
— документации внутренних правил;
— протокола демонстрации типового решения.

В идеальном мире такое заключение готовится быстро и приводит к безболезненному перезаключению контракта.
В реальном — LEAD сталкивается с диким сопротивлением как со стороны «ООО Наш клиент», так и со стороны руководства «ООО Наша команда».

В нашем кейсе, ему таки удалось добиться пересмотра и перезаключения контракта на необходимую заказчику систему.

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

Этот пример наглядно демонстрирует самые главные навыки LEADа:

— видеть несоответствия и уметь их фиксировать;
— видеть риски таких несоответствий;
— формировать стратегическое решение задачи;
— отстаивать найденное решение (даже непопулярное).

На этапе исследования именно эти навыки, на принципиальном уровне, отличают LEADа.

Все остальное умеет SENIOR.

Итак, у нас есть запрос на типовое решение по договорным процессам, плюс 300
шаблонов, плюс интеграция. Пока LEAD еще не знает, что есть один нюанс…
И он дает SENIORу задания:

— подготовить демонстрацию нашего типового решения, которое максимально
отобразит требования из тз заказчика;
— и: «Бро, разберись там с интеграцией».

SENIOR быстро собирает сценарий демонстрации, самостоятельно разбираясь в
приоритетах, взаимосвязях и логике.

Дальше, он веселится с интеграцией: снимает информацию с заказчика, прорабатывает риски и возможности реализации. Но у нас ведь увлекательный кейс. Поэтому, веселье с интеграцией быстро показывает, что у заказчика нет работающей ERP системы, но есть лучше — описание работающей ERP системы. В момент, когда это вскрывается, с эпохальной встречи приходит LEAD со словами «Хьюстон, у нас проблемы». И напарники объединяют усилия, чтобы доказать полную невозможность реализации контракта в текущих условиях.

SENIOR берет на себя половину задач по сбору доказательной базы, и они с LEADом в 4 глаза проверяют и перепроверяют факты.

Этот пример показывает значимость технических навыков SENIORа на этапе
Исследования:
— грамотно составить сценарий демонстрации;
— расковырять интеграцию и выявить риски;
— ловить несоответствия по всей системе;

— и главное, все делать очень-очень быстро и точно.

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

Они получают задания сверху и радостно разбирают шаблоны: 300 договоров и
небольшие вопросы по интеграции. У них, на самом деле, очень важная функция — выполнять формальные условия контракта и те задачи, которые не зависят от
дальнейшего решения руководства. Тем самым, они развязывают руки LEADу и SENIORу для решения основных вопросов и подкладывают соломку для дальнейшей работы по проекту. Помимо этого, они учатся, как, непосредственно, профессии, так и специфике данного конкретного кейса.

Таким образом, главные навыки MIDDLE и JUNIOR на этапе Исследования:
— выполнять хорошо детализированные задания;
— анализировать и структурировать информацию;
— задавать заказчику грамотные уточняющие вопросы.

Итак, мы разобрали проектный этап «Исследование» с точки зрения компетенций команды.

Разумеется, в реальном мире ситуация, когда на одном проекте собраны LEAD, SENIOR, MIDDLE и JUNIOR встречается крайне редко. И вариантов иного распределения функционала очень много. К сожалению, в рамках одной статьи, это множество разобрать нереально. Тем более, невозможно поделиться рабочими инструментами, необходимыми для решений той или иной задачи этапа. Эта информация целого курса (ссылка на курс). Именно с этого я начинала свою первую статью цикла — нужно учиться.

Но не просто учиться, а как-то и чему-то.

На вопрос «как» я отвечала в предыдущей своей статье (ссылка):
Можно читать книги, можно читать статьи на английском (правда, лучше на английском). Можно проходить курсы, и приобретать компетенции через решение конкретных проектных задач под руководством наставника. Все три способа эффективны. Особенно вместе.

А теперь вопрос «чему учиться». Здесь могу ответить одно — конкретным
профессиональным практикам, потому в прикладных профессиях вся теория— это не что иное, как обслуживание практики.

10е место: Со всеми общаться только с глазу на глаз без какой-либо записи. Тепло так и по-семейному.

9е место: Запрашивать у заказчика регламентирующие документы и отчетные формы устно и не вести никаких реестров: ни полученных документов, ни проигнорированных просьб.

8е место: В вопросах заказчику использовать общие формулировки: «А как вы работаете вообще?», «А чего вообще надо?»

7е место: Забыть/ пропустить матрицу коммуникаций***. Всем рекомендую.

6е место: Проигнорировать решения конкурентов по вашему вопросу. Вы— творец, не оглядывайтесь ни на кого!

5е место: Лениться писать протоколы совещаний. Память-то вам на что!

4е место: Пойти к заказчику неподготовленным. Даже сайт компании не почитать. Даже первую страницу.

3е место: Верить на слово устным показаниям заказчиков. Это топчик.

2е место: Не изучить контракт. Не вызубрить его, не пропустить каждую буковку через себя.

1е место: Барабанная дробь… Отправить на исследование STANDARTа, а лучше JUNIORа!

Это верная победа.

PS: Если вы даже не улыбнулись, пока читали, то вам лучше заглянуть сюда (ссылка на статью) и разобраться в последствиях такого поведения, а также узнать, как избежать типичных ошибок в аналитике.

*Границы системы — это зафиксированные договоренности между заказчиком и исполнителем о том, что считать готовой системой.
** Обращаю внимание для тех, кто не читал вводную статью: навыки суммируются при повышении квалификации. Это значит, что LEAD имеет все навыки SENIOR, MIDDLE и JUNIOR. SENIOR — навыки STANDARD и JUNIOR и т.д.
*** Матрица коммуникаций — это список заинтересованных лиц и участников проекта, с распределением областей вопроса, за которые они отвечают.