Предпроектный анализ27.12.2017 19:33

Сергей Нужненко darkboatman, ведущий системный аналитик SuperJob, делится опытом запуска IT-проектов с точки зрения аналитика.

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

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

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

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

Задачи предпроекта

Что нужно сделать для того, чтобы построить ИТ-систему или сервис?
Вот список больших задач, которые так или иначе решаются для любой системы:

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

Подчеркнутые пункты мы будем называть «предпроект».

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

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

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

1) Понять сроки и стоимость

2) Допродать систему:

Показать заказчику понимание его целей
Показать пользователям решение их проблем
Успешно завершить торг за бюджет

3) Создать основание для приемки (контракт на объем и качество результата, называемое так же «техническое задание»)

4) Определиться с ресурсами: видами, этапами, сроками, объемами работ и источниками ресурсов

Без этого ничего (хорошего) не выйдет.

Трудности

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

Надо быстро определиться со стоимостью системы на фоне высокой неопределенности.

Идет торг за бюджет и сроки — это конфликт, изначально заложенный в любой предпроект.

Заказчик хочет Сhrysler Escalade, денег есть на ГАЗ 69, но нужен ему Renault Logan. Бывает, что при этом поставщик решений хочет продавать яхты и самолеты, но реально может сделать только надувную лодку, а сейчас пойдет искать, у кого купить Logan.

Проект еще не «продан» и идет борьба за его запуск.

Обзор проблем и решений

Мы расположили частые проблемы предпроекта по мере роста зрелости заказчика и других участников ИТ-проекта:

1) «Письмо Дяди Фёдора»

2) Не учтены полный ЖЦ и структура как системы, так и финансового актива

3) Не учтены задачи предпроектной фазы

Избыточная детализация требований
Не представлены объем и достаточное деление системы
Не проявлено понимание целей заказчика
Нет основания приемки результата

4) Выбран неверный режим коммуникации требований

Обзор предлагаемых решений, о которых мы более детально поговорим в следующих разделах:

Кроме этого необходимо помнить о базовых принципах, которые мстят за невнимание к себе. Среди них:

Понимание сути ИТ-системы и ее жизненного цикла
Понимание взгляда на систему как на финансовый актив
Понимание, что такое конус неопределенности и как его использовать
Понимание основ оценки
Понимание полного состава задач предпроектной фазы, невыполнение которых обрекает нас в лучшем случае на отказ от запуска проекта, в худшем — на мучения в заведомо провальном проекте, а в еще худшем — на кармические долги за мертворожденные ИТ-системы

Краткий обзор закончен, к деталям перейдем в следующих заметках серии.