Предпроектный анализ

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

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

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


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




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

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


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

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

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

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

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

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

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

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

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

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

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

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

    Трудности


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

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

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

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

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

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


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

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

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

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

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

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

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



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

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

    Краткий обзор закончен, к деталям перейдем в следующих заметках серии.
    SuperJob.ru
    82,60
    Интернет-сервис для поиска работы
    Поделиться публикацией

    Комментарии 4

      0
      Есть еще серьезная проблема вида «А кто заплатит за предпроектные работы?»
        0
        Спасибо за очень правильный вопрос!

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

        Быстро и как можно дешевле. И не только со стоимостью, но и вообще с балансом вложений и отдачи, в чем бы она ни измерялась. Так как пока нет уверенности в том, что мы стартуем, никто не хочет платить за работы.

        Собственно, кто будет платить, вариантов не так много и из них легко выбирать. А вот как его заставить платить и как сделать цену приемлемой, дальше мы обсудим.
        0
        1. Предпроекты описаны только в стандарте PRINCE2.
        2. Эффективным считается такой предпроект, после которого будет осуществлен старт ПРОЕКТА с четко определенными сроками, ресурсами и целями. Это и является основным ключевым показателем эффективности предпроекта.
          0
          Такая точка зрения понятна. При этом она не защищает интересы заказчика и инвестора. Задача бизнес-аналитика со стороны заказчика во-первых закрыть 10 проектов с низкой или отрицательной отдачей и только во-вторых открыть 1, который даст высокую отдачу.

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

        Самое читаемое