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

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

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

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

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

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

● АНО «Госорган» — организация клиента.

Проектирование… есть множество сложных терминов, но смысл у всех примерно один: на этом этапе мы придумываем и описываем, как все будет, когда мы это сделаем. Во вводной статье, где разбирался полный цикл проекта на примере задачи «съесть слона» (ссылка) , этот этап предполагал «приготовление всего, чтобы съесть слона»: от меню до технологии прожарки.

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

Замечательно. И что же с этим дальше делать? Искать улики! То есть, выявлять
требования*: группировать их, сопоставлять, нащупывать нить и логику. Так до тех пор, пока не получится ясная, четкая картина, лишенная противоречий и дающая ответы на все поставленные вопросы. Ну вы поняли, этот этап — настоящий детектив. Где LEAD — самый главный Шерлок Холмс, SENIOR — верный Ватсон, а MIDDLE и JUNIOR — бравые представители Скотленд-ярда, которые приносят много улик, но что с ними делать, пока не понимают.

Самое главное, чему Конан Дойль может научить аналитика — это тому, что мелочей небывает. И маленький грязный окурок способен стать краеугольным камнем всего дела. Ох, сколько у меня таких окурочков было — до сих пор некоторые снятся. Как и в романах, настоящую значимость мелочей понимает только самый матерый сыщик в команде — LEAD. И поскольку среднестатистический Холмс вплоть до самой развязки сюжета выглядит немного придурковато, то в период проектирования команда, зачастую не
совсем понимает логику действий босса. Ватсон, то есть SENIOR, единственный из всех подозревает у LEADа не шизофрению, а гениальную идею. Поэтому послушно «носится по городу», становясь глазами и ушами главного сыщика. Скотланд-ярд же, в лице MIDDLE и JUNIOR, строит, конечно, свои гипотезы, но улики носит Холмсу.

А наш сегодняшний клиент — АНО «Госорган». Те, кто с ними сталкивался, в пояснениях не нуждаются. Для остальных — короткая вводная: любое действие чиновника начинается и заканчивается оформленным по всем правилам документом; нет документа — считай, не было работы.

Итак, ООО «Наша команда» была привлечена для разработки информационной системыавтоматизации работы сотрудников АНО «Госорган». Тендерное техническое заданиепредлагало реализовать несколько слабо-связанных модулей для нескольких слабосвязанных подразделений. По старой государственной традиции, этапа Исследования унас не было, его полностью заменило тендерное техзадание. Внимание, тендерное, а не рабочее. То есть, по сути, концепция и границы. Шоу интуиция начинается!

Собирается внутреннее совещание и распределяются задачи: модули посложнее
отдаются на выявление требований SENIORу, попроще — MIDDLE, самый хардкорный берет себе LEAD. JUNIORы помогают всем. Далее кипит работа, данные накапливаются, и по мере увеличения количества информации, у LEADа становится все более задумчивый вид: все гипотезы предлагаемых командой решений не исчерпывающие, то есть, все время возникают противоречия. И гипотезы, по сути, становятся костылями для логических дыр. Количество этих костылей растет, а дыры не заканчиваются. Это видит не только команда, но и заказчик — АНО «Госорган», который отвергает один за другим все варианты.

И так продолжается, пока в один прекрасный день, LEAD не говорит о том, что нам-таки нужна «информационная архитектура». Тогда его текущие задачи перераспределяются между остальными участниками команды, а сам он начинает серию допросов. Причем, допрашивает своих же аналитиков, которые накопили достаточно знаний по отдельным модулям. Собранные воедино показания открывают следующую картину: все модули системы являются последовательными этапами одного процесса. То есть, они не просто
взаимосвязаны, они еще и имеют свой строгий порядок. А это значит, что:

1. Проектировать систему нужно комплексно;

2. Разработка этого комплекса не может вестись параллельно по «модулям», а толькопоследовательно;

3. Необходимо поменять модель коммуникации с заказчиком, то есть, встречаться с ними не по отдельным подразделениям, а на больших общих совещаниях.

Когда заказчикам была показана полная картина того, как у них, на самом деле, все устроено с точки зрения информационной архитектуры, они просто обалдели. Оказалось, что в АНО «Госорган» никто до конца понимал, насколько там все железобетонно взаимосвязано. Общей картины не было ни у кого, потому что руководителю не хватало деталей — того самого допроса. А у исполнителя не было видения — способности соединить показания в систему. Ну то есть, не хватало им аналитика.

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

Итак, аналитики пришли. Процесс запустился. Новая концепция была слету утверждена. Идальнейшее проектирование шло гораздо проще, а все логические дыры, которые ООО «Наша команда» насобирала ранее, исчезали одна за одной.

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

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

● До обнаружения глобальных проблем, он выполнял роль SENIORа на самом
сложном модуле.

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

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

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

● Параллельно, он координирует работу MIDDLE и JUNIOR во всем многообразии и вариативности этого понятия.

● После того, как LEAD ушел в туман писать архитектуру, SENIOR подхватывает задачи по его модулю и рулит самостоятельно. И это нормальная ситуация для
критических моментов в проекте.

● После получения новой концепции, быстро переработал все свои решения под
нее.

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

● При перераспределении модуля LEADа тоже попадает под раздачу и отхватываетпару новых задач, которые не успел закончить SENIOR.

● После явления миру новой концепции: в лучшем случае, вносит правки в свои
решения, в худшем — все переписывает.

● Параллельно, помогает JUNIORу, внося в его жизнь новые интересные задания.

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

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

Помимо навыков компетенций, мой пример ярко иллюстрирует одну очень важную мысль. На этапе Проектирования у вас до последнего есть шанс сделать так, чтобысистема была нормальной. Потом его не будет. Это 100%. Если вернуться к аналогии с поиском улик, то ищите этот «маленький грязный окурок» — вашу главную зацепку вделе, до последнего! Проверяйте и перепроверяйте себя, заказчика, концепцию. Будьте честны с собой: если видите алогизм, не притворяйтесь, что не видите. Раз он есть, то никуда не денется.

Этап проектирования — лучшее время посмотреть правде в глаза и все переделать. Он, вы не поверите, именно для того и придуман. Есть в Испании одно неприличное крылатоевыражение, которое звучит примерно так: «Затолкайте это в обратно в мать и перелюбите на что-нибудь нормальное». Так вот, Проектирование — это время свою концепцию по-быстренькому перелюбить, если намечается очередной Франкенштейн.

В общем, нормально делай — нормально будет. И пусть это станет слоганом статьи.

10е место: Рассчитывать на то, что на этом этапе вы обойдетесь без технического архитектора и запроектируете реализуемую систему.
О да, вы можете!

9е место: Рассчитывать на то, что все ваши «маленькие» нестыковки порешает на следующем этапе команда разработки. Она за такие подарки только разве что вас порешает.

8е место: Пойти на поводу у заказчика, которому что-то очень надо, вопреки всем вашим логическим выкладкам и объективной реальности. Скайнет еще не изобрели.

7е место: Игнорировать существование валидации требований.
А что это?

6е место: Игнорировать концепцию и границы проекта.

Аналитик, бди! Аппетиты у заказчиков растут во время еды, и детали запросто могут превратиться в отдельную систему.

5е место: Гнаться за сроками этапа Проектирование.
Помните: сдать техзадание гораааздо проще, чем разработать по нему систему — неспешите, подумайте еще.

4е место: Проводить проектирование силами MIDDLE и JUNIOR.
Вот вы смеетесь, а такие проекты бывают.

3е место: Не проверять себя, заказчика и концепцию.
Вообще, не «проверять» можно сделать закрепом в ТОП-10 косяков аналитики.

2е место: Закрывать глаза на алогизмы.
Как кот: я не вижу хозяина, значит хозяин не видит меня.

1е место: И лидер нашего чарта: сбор требований вместо выявлений. Это когда вы приходите с блокнотиком к клиенту и ждете, что он надиктует грамотные требования.

* Выявление требований — процесс составления требований к системе на основании собранных данных. Процесс включает в себя:
— раскладывание запроса на систему на отдельные сегменты и фрагменты рабочих
процессов;
— изучение каждого процесса через заказчика, пользователя, документацию и другие источники (ссылка на курс, как писать ТЗ);
— детализация процессов до функции;
— формулирование однозначных требований к функциям для решения задач
запрошенной системы.

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