Сергей Нужненко darkboatman, ведущий системный аналитик SuperJob, делится опытом запуска IT-проектов с точки зрения аналитика.
По итогам выступления на прошедшем митапе у меня получается серия заметок, в которых я постараюсь, освободившись от ограничения форматом выступления, обсудить с вами принципы выполнения предпроектных задач и покажу несколько примеров из жизни.
Это пригодится представителям заказчика, системным, бизнес-аналитикам, менеджерам проектов, другим участвующим в запуске ИТ-проектов, итераций или спринтов.
Под предпроектом мы понимаем все задачи, которые надо выполнить до момента получения согласия всех сторон, утверждения бюджета, а главное — понимания, что мы делаем и зачем, а также каким способом, то есть кого надо привлечь и кому позже надо будет ставить задачу. Эти задачи одинаковы как для большого проекта, так и для короткой двухнедельной итерации.
Мы знаем, что, во-первых, хорошая постановка задачи — это половина решения, а, во-вторых, не столь важно, насколько продуктивно ты что-то делаешь, если при этом делаешь не то, что нужно. Системной предпроектной работе уделяется удручающе мало внимания. Подавляющее число обсуждений, книг и статей посвящено тому, что делать внутри проекта, или поиску продукта во взаимодействии с рынком. В серой зоне оказывается переход от понимания, что надо продавать, к самой работе.
Что нужно сделать для того, чтобы построить ИТ-систему или сервис?
Вот список больших задач, которые так или иначе решаются для любой системы:
Подчеркнутые пункты мы будем называть «предпроект».
Предпроект (хоть он и не всегда так называется) может выполняться в разных условиях: на систему в целом, на подсистемы или на каждую фичу продукта.
Все указанные задачи могут выполняться годы, месяцы или пролетать за неделю в рамках подготовки сессии планирования спринта, могут сопровождаться различным количеством бумаги и разными схемами взаимодействия участников.
Однако перед тем, как мы начнем фиксировать цели, пресловутые 4 параметра проектного треугольника — формулировать обязанности участников проекта, назначать внешние статус-митинги с участием спонсора и расчехлять другие общеупотребимые инструменты проектного управления — необходимо полностью выполнить задачи предпроекта:
1) Понять сроки и стоимость
2) Допродать систему:
3) Создать основание для приемки (контракт на объем и качество результата, называемое так же «техническое задание»)
4) Определиться с ресурсами: видами, этапами, сроками, объемами работ и источниками ресурсов
Без этого ничего (хорошего) не выйдет.
Все проблемы, о которых пойдет речь ниже, развиваются на заведомо неблагоприятном фоне, общем для всех предпроектов.
Надо быстро определиться со стоимостью системы на фоне высокой неопределенности.
Идет торг за бюджет и сроки — это конфликт, изначально заложенный в любой предпроект.
Заказчик хочет Сhrysler Escalade, денег есть на ГАЗ 69, но нужен ему Renault Logan. Бывает, что при этом поставщик решений хочет продавать яхты и самолеты, но реально может сделать только надувную лодку, а сейчас пойдет искать, у кого купить Logan.
Проект еще не «продан» и идет борьба за его запуск.
Мы расположили частые проблемы предпроекта по мере роста зрелости заказчика и других участников ИТ-проекта:
1) «Письмо Дяди Фёдора»
2) Не учтены полный ЖЦ и структура как системы, так и финансового актива
3) Не учтены задачи предпроектной фазы
4) Выбран неверный режим коммуникации требований
Обзор предлагаемых решений, о которых мы более детально поговорим в следующих разделах:
Кроме этого необходимо помнить о базовых принципах, которые мстят за невнимание к себе. Среди них:
Краткий обзор закончен, к деталям перейдем в следующих заметках серии.
По итогам выступления на прошедшем митапе у меня получается серия заметок, в которых я постараюсь, освободившись от ограничения форматом выступления, обсудить с вами принципы выполнения предпроектных задач и покажу несколько примеров из жизни.
Это пригодится представителям заказчика, системным, бизнес-аналитикам, менеджерам проектов, другим участвующим в запуске ИТ-проектов, итераций или спринтов.
Под предпроектом мы понимаем все задачи, которые надо выполнить до момента получения согласия всех сторон, утверждения бюджета, а главное — понимания, что мы делаем и зачем, а также каким способом, то есть кого надо привлечь и кому позже надо будет ставить задачу. Эти задачи одинаковы как для большого проекта, так и для короткой двухнедельной итерации.
Мы знаем, что, во-первых, хорошая постановка задачи — это половина решения, а, во-вторых, не столь важно, насколько продуктивно ты что-то делаешь, если при этом делаешь не то, что нужно. Системной предпроектной работе уделяется удручающе мало внимания. Подавляющее число обсуждений, книг и статей посвящено тому, что делать внутри проекта, или поиску продукта во взаимодействии с рынком. В серой зоне оказывается переход от понимания, что надо продавать, к самой работе.
Задачи предпроекта
Что нужно сделать для того, чтобы построить ИТ-систему или сервис?
Вот список больших задач, которые так или иначе решаются для любой системы:
- Понять наличие проблемы или возможности
- Выявить ожидаемую пользу (эффект) качественно или количественно
- Понять «образ решения» (концепцию или vision) и его стоимость
- Выделить бюджет в деньгах или натуральных ресурсах
- Определить виды ресурсов, объемы работ и начать их заказ
- Определить основание для приемки (как мы узнаем, что работа сделана)
- …
- (Здесь унылый список работ по проектированию, планированию, разработке, развертыванию, внедрению и т.п., который сегодня останется за рамками нашего обсуждения)
- …
- Приемо-сдать результат
- Измерить эффект
- Подтвердить возврат финансовых вложений
Подчеркнутые пункты мы будем называть «предпроект».
Предпроект (хоть он и не всегда так называется) может выполняться в разных условиях: на систему в целом, на подсистемы или на каждую фичу продукта.
Все указанные задачи могут выполняться годы, месяцы или пролетать за неделю в рамках подготовки сессии планирования спринта, могут сопровождаться различным количеством бумаги и разными схемами взаимодействия участников.
Однако перед тем, как мы начнем фиксировать цели, пресловутые 4 параметра проектного треугольника — формулировать обязанности участников проекта, назначать внешние статус-митинги с участием спонсора и расчехлять другие общеупотребимые инструменты проектного управления — необходимо полностью выполнить задачи предпроекта:
1) Понять сроки и стоимость
2) Допродать систему:
- Показать заказчику понимание его целей
- Показать пользователям решение их проблем
- Успешно завершить торг за бюджет
3) Создать основание для приемки (контракт на объем и качество результата, называемое так же «техническое задание»)
4) Определиться с ресурсами: видами, этапами, сроками, объемами работ и источниками ресурсов
Без этого ничего (хорошего) не выйдет.
Трудности
Все проблемы, о которых пойдет речь ниже, развиваются на заведомо неблагоприятном фоне, общем для всех предпроектов.
Надо быстро определиться со стоимостью системы на фоне высокой неопределенности.
Идет торг за бюджет и сроки — это конфликт, изначально заложенный в любой предпроект.
Заказчик хочет Сhrysler Escalade, денег есть на ГАЗ 69, но нужен ему Renault Logan. Бывает, что при этом поставщик решений хочет продавать яхты и самолеты, но реально может сделать только надувную лодку, а сейчас пойдет искать, у кого купить Logan.
Проект еще не «продан» и идет борьба за его запуск.
Обзор проблем и решений
Мы расположили частые проблемы предпроекта по мере роста зрелости заказчика и других участников ИТ-проекта:
1) «Письмо Дяди Фёдора»
2) Не учтены полный ЖЦ и структура как системы, так и финансового актива
3) Не учтены задачи предпроектной фазы
- Избыточная детализация требований
- Не представлены объем и достаточное деление системы
- Не проявлено понимание целей заказчика
- Нет основания приемки результата
4) Выбран неверный режим коммуникации требований
Обзор предлагаемых решений, о которых мы более детально поговорим в следующих разделах:
Кроме этого необходимо помнить о базовых принципах, которые мстят за невнимание к себе. Среди них:
- Понимание сути ИТ-системы и ее жизненного цикла
- Понимание взгляда на систему как на финансовый актив
- Понимание, что такое конус неопределенности и как его использовать
- Понимание основ оценки
- Понимание полного состава задач предпроектной фазы, невыполнение которых обрекает нас в лучшем случае на отказ от запуска проекта, в худшем — на мучения в заведомо провальном проекте, а в еще худшем — на кармические долги за мертворожденные ИТ-системы
Краткий обзор закончен, к деталям перейдем в следующих заметках серии.
