6.2.Готовим отчет
Проведение анализа и составление итогового отчета по концепции проекта – задача весьма интересная, но для специалистов, которые не имеют большого опыта таких работ, изначально сложная. Поручать такую работу консультанту без должного проектного опыта – неблагодарное дело, так можно подвести все стороны проекта и породить ненужные проектные риски.
Этой задачей должен заниматься опытный специалист, прошедший несколько аналогичных фаз в других проектах. Всегда бывает «первый раз» – и как тогда его пройти? Нужно привлекать новичков в помощь такому «проектному ветерану». Задач хватит на всех, но контроль за логикой, подачей информации в отчете, проектными решениями и оформлением должен осуществлять понимающий и опытный специалист. То есть итоговый отчет по фазе анализа готовят несколько консультантов под чутким руководством системного архитектора либо самого руководителя проекта (если он в прошлом имеет большой проектный опыт и «собаку съел» на всем этом).
Хороший шаблон из проектной методологии тоже является секретом успеха: он содержит структуру и описание разделов, и даже «пустой» шаблон может быть на 10 страницах только из-за детализации структуры, по сути, являясь опросником для консультанта, – остается узнать то-то и то-то и сформулировать выявленное в виде формального описания.
Вроде все просто, но процесс «пропускания через себя» большого потока информации, четкое формулирование текста и выработка проектных решений требуют определенного склада ума и понимания предметной области.
Можно вспомнить известную фразу древнекитайского философа Лао-цзы: «Даже путь в тысячу ли начинается с первого шага». Вот и подготовку отчета нужно с чего-то начать, перебороть страх перед пустой первой страницей.
Наличие хорошего шаблона и подсказок в нем – это хорошо, но как понять, какие подразделы нужны и что в них будет? Для этого занимаемся максимально возможной декомпозицией «непонятного» на части, чем меньше эти части будут, тем проще их сделать «понятными», а поняв, формально описать.
У нас на входе довольно много информации, полученной от заказчика, ее нужно переработать, используя конспект проведенных интервью и опросные листы. Начинаем описывать бизнес-процессы и роли пользователей «как есть» – это понятно, т. к. вся информация есть, всегда можно уточнить у ключевых сотрудников заказчика какой-то непонятный момент, проверить и согласовать схемы.
Далее это «как есть» критически рассматриваем применительно к системе и входящим требованиям, попутно проверяя какие-то гипотезы в прототипе системы (настраиваем цепочки документов). Проводим мозговые штурмы внутри команды по необходимости. Проводим fit-gap анализ, рисуем схемы ИТ-ландшафта – текущего и целевого (подробнее про это было в главе 2).
Обычно системный архитектор знает систему, что называется, наизусть, и ему достаточно прочесть требование и посмотреть схему бизнес-процесса, чтобы понять, как это настроить в системе и может ли она такое вообще, а если не может, то что можно доделать, чтобы смогла.
Попутно из «как есть» приходим к схемам «как будет», это продиктовано возможностями системы и здравым смыслом свежего пересмотра бизнес-процессов в ходе анализа – реинжиниринг бизнес-процессов на этой фазе очень к месту.
Крайне нежелательно слепо перекладывать в систему все как есть без попыток пересмотра, мотивируя тем, что специалистам заказчика виднее, это их фирма, их бизнес. Сыграем в простую игру: представьте, что вас наняли в эту фирму на эти самые ключевые должности. Вы бы все так и оставили или, может, что-то поменяли, исходя из свежего взгляда со стороны на компанию (и опыта других компаний по другим проектам)? Вот что вы бы сами себе меняли, то и нужно предлагать менять сотрудникам заказчика.
Стоит давать рекомендации (консультации), рассматривать разные варианты на выбор, будучи консультантом со стороны исполнителя, руководителям (и ключевым специалистам) подразделений со стороны заказчика. Они на своих местах нормально это воспринимают: потому и зовут специалистов со стороны, что сами изнутри не могут что-то заметить (а своих подчиненных, даже если те скажут то же самое, что и вы, скорее всего, не услышат). Если предложение имеет минусы – вам прямо на это укажут (новая информация к анализу), а вот если предложение пройдет: «А действительно, что это мы так раньше не сделали?» – то это победа.
Ситуация со стороны заказчика – нужно чаще спрашивать консультантов исполнителя: «А как можно еще это сделать?», «Какую альтернативу вы можете предложить?» На данной фазе коммуникация особенно важна. Специалисты исполнителя и сотрудники заказчика еще не сработались до понимания друг друга с полуслова. Исполнитель может принять (под давлением или по иным причинам) тактику «любой каприз за ваши деньги» («что скажете, то и будем делать»). Нужно со стороны заказчика не подавлять («нам виднее, это наша фирма!») инициативу рассмотрения разных вариантов, а, наоборот, поощрять креатив специалистов исполнителя. Помним график из главы 5 про возможность влияния на проект в начале, при проектировании? Вот на этой фазе, где все пока еще слова, даже документа описания может не быть, бумага с рисунками, схемы на флипчарте и маркерных досках (не забываем, кстати, все с них фотографировать, потом может пригодиться для перерисовки в документ) – это все быстрая коммуникация и рассмотрение вариантов.
Нужно понимать, что в реальности между мыслями одного человека, их формулировкой (речью и текстом) и пониманием другого человека этого всего лежат фильтры «искажений», меняющие и урезающие поток информации. Наглядно это можно представить на схеме.
Рис. 6.1. Схема искажения понимания при коммуникации «исполнитель – заказчик»
Схема работает в обе стороны: консультанты исполнителя также фрагментарно понимают рассказ или описание регламентов от специалистов заказчика. Мало того, это и внутри группы работает – между, например, консультантом и разработчиком. Собственно, это один из факторов того, что в какой-то момент наращивание проектной команды сотрудниками останавливает ускорение в решении задач, т. к. накладные расходы на коммуникациях съедают этот прирост от дополнительных «человеко-часов». Какие методики есть для налаживания коммуникаций, рассматривалось в главе 4 « ». Показ прототипа и презентация тезисов и выводов готового отчета – тоже важный инструмент выстраивания коммуникации. Со стороны не видно, что думает человек при прочтении документа, зато реакция на озвучивание тезисов и показ схем на очной презентации очень заметна, можно быстро задать уточняющие вопросы в обе стороны, проверить, что все теперь имеют одинаковое представление о проектных задачах и границах. После таких встреч отчет можно уточнять итерационно и после рассылать текстовую версию на согласование.
Рассмотрим типовую структуру документа «Концептуальный проект» (он же «Отчет об обследовании»):
- История изменений – версии, даты, кто и что менял (документ может уточняться итерационно по мере согласования и обсуждения презентаций).
- Принятые сокращения, понятия и определения – словарь сокращений и принятых в проекте и используемых далее по тексту терминов.
- Введение – назначение документа, когда и как проходил анализ и концептуальное проектирование, кто участвовал.
- Общие сведения о заказчике и области автоматизации – описание контекста для последующих пунктов: о компании, бизнес-направления, оргструктура, используемое программное обеспечение, текущая схема ИТ-ландшафта.
- Бизнес-требования – кратко со ссылкой на таблицу-приложение (в таблице работать с требованиями удобнее), входящие требования для автоматизации (по мере концептуального проектирования уточняемые).
- Основные бизнес-процессы – описания бизнес-процессов в виде схем (или иерархических списков) и пояснений к ним «как есть» (может не быть) и «как будет» (как целевая модель).
- Концепция решения – долгосрочное видение системы (включая перспективный ИТ-ландшафт), которая должна быть создана и внедрена и которая будет удовлетворять всем бизнес-требованиям, разделение требований по этапам проекта и целевые схемы системы и ИТ-ландшафта на каждый этап.
- Факторы успеха проекта – критерии, по которым можно будет измерить и определить, что проект завершился успешно.
- Секция утверждения – подписи согласующих (может быть на самом титульном листе, так нагляднее).
- Приложения – необходимые приложения, вынесенные из основного текста: схемы, таблицы, графики, ссылки на другие файлы.
Как же подготовить отчет? Простые шаги, с чего начать:
- Взять шаблон документа и заполнить шапку шаблона и историю изменений.
- Составить свое оглавление (последовательность подпунктов). Оглавление делать заголовками с пустым содержимым.
- Расположить полученные от заказчика и нарисованные на флипчартах схемы и диаграммы в целевых разделах документации.
- Декомпозировать подзаголовки дальше – получаем иерархическую структуру документа, что будет соответствовать ИСР (иерархической структуре работ) проекта.
- Начинаем наполнять все подразделы, уточняем непонятные моменты у заказчика и коллег, проводим мозговые штурмы, настраиваем прототип, проектируем.
- Включаем в приложения описание используемой нотации для схем бизнес-процессов.
При завершении документа:
- Прочитать полученный документ самому так, как будто это совершенно новый документ, который писал кто-то другой (очень хороший трюк для взгляда со стороны).
- При этом нужно задавать себе вопросы: «А это что?», «Откуда это?», «А что будет, если?..»
- Если ответов на эти вопросы по тексту нет, дописать пояснения по месту возникновения.
- После итерации вычитки отдать на проверку коллегам и далее по процедуре специалистам заказчика.
- Полученные в ходе анализа и проектирования уточненные требования к автоматизации критически рассматриваем и приоритизируем с учетом всех изученных и проанализированных документов и процессов заказчика.
