Управление проектами в области ИТ. Детальная постановка задачи
Следующий этап - детальная постановка задачи. Корректная постановка задачи - уже повышение вероятности успеха и сокращение затрат на проект на 30-50%. Четкие ответы на вопрос "Что надо?" часто сразу дают ответ на вопрос "Как делать?". Особенностью российских правил учета является тот факт, что изменения в них часто носят весьма глобальный характер, в результате четкого понимания всех изменений на этапе начала проекта нет ни у кого в организации. Для решения этой проблемы используются приемы, которые рассмотрены ниже.
Описание глобальной цели проекта включает ответы на вопросы "Зачем?" как для внешней среды (Зачем ЦБ РФ издал такую инструкцию?), так и самой организации и ее подразделений (Зачем организации реализовывать этот проект?). Вариантов ответов на последний вопрос может быть несколько: "Чтобы организацию не оштрафовали" (самый неудачный ответ), "Данная инструкция позволит снизить операционные риски от совершения операций" и т.д. Анализ ответов позволит не только более точно понимать детали изменений, но и прогнозировать дальнейшие дополнения и исправления.
Создание единого информационного пространства проекта. В простейшем варианте оно представляет собой директорию, в которой все участники проекта записывают имеющуюся у них информацию и соображения по поводу решаемой задачи. Более сложным вариантом является организация интранет-конференции.
Использование ролевого моделирования процесса подразумевает обыгрывание несколько раз бизнес-процесса всеми его участниками с обязательной регистрацией всех выполняемых действий и пожеланий:
┌────────────────────────┐ ┌─────────────────────────────┐
│Сотрудник бухгалтерии: │ │Сотрудник отдел отчетности: │
│Я регистрирую документ│ │Я формирую отчет группировки│
│данного типа в АБС.│ │платежей по статьям расхода│
│Ввожу следующие поля: │ │за период. В качестве│
│СЧЕТ ПО ДЕБЕТУ, СЧЕТ ПО│ │параметра отчета я должен│
│КРЕДИТУ, СУММУ,│ │определять интервал дат.│
│НАЗНАЧЕНИЕ... │ │Отчет должен иметь следующую│
│ │ │форму: │
│ │ │ │
│Пометка: надо вводить│ │┌────┬─────┬────┬─────┬─────┐│
│еще и статьи расхода....│ ││ │ │ │ │ ││
│ │ │├────┼─────┼────┼─────┼─────┤│
│ │ ││ │ │ │ │ ││
│ │ │├────┼─────┼────┼─────┼─────┤│
│ │ ││ │ │ │ │ ││
│ │ │└────┴─────┴────┴─────┴─────┘│
└────────────────────────┘ └─────────────────────────────┘
Данный прием моделирования позволяет максимально использовать имеющийся человеческий капитал, поскольку каждый участник строит свой бизнес-процесс самостоятельно, а общий контроль осуществляет руководитель и представители других подразделений.
Описанные приемы помогут группе более точно понять и написать техническое и бизнес-задание проекта. В бизнес-задании описываются основные функциональные требования, техническое - отражает более детальную информацию, особенности, включая параметры и подходы к реализации. Иногда они подготавливаются разными людьми, но гораздо чаще представляют единый документ, который готовится одним человеком - аналитиком. Далее мы не будем делать различий между этими документами и понятиями.
Следует помнить, что, если точного задания не получится, придется давать системе, реализующей проект, дополнительную гибкость. Но реализация универсальной, гибкой бизнес-функции требует в несколько раз больше ресурсов на разработку и сопровождение, чем статичное решение.
Кроме того, рекомендуется вести разработку двух заданий, которые условно можно назвать: "Программа-минимум" и "Программа-максимум". В первом варианте нужно описать минимальные изменения в организации по сравнению с текущим положением дел, достаточные для реализации основной цели. Второй документ должен составляться с учетом всех пожеланий и перспектив. Как правило, в конце проекта будет реализован некоторый промежуточный вариант. Имея установленный проект бюджета, группа сначала реализует только самые необходимые требования (на это бюджета, как правило, хватает), а потом либо будет дополнять данное решение новыми возможностями, либо аргументирует прекращение работ и возьмет на себя ответственность за это.
В любом случае при постановке задачи, как и везде, вредны крайности. Многие проекты были загублены чересчур грамотными аналитиками, которые месяцами составляли задания, исчисляемые сотнями страниц. Потом сами же с трудом могли понять, что они имели в виду, настолько запутана и сложна была задача или ее описание. Поверхностность также вредна. Исходя из практического опыта, можно сказать, что ориентирами "золотой середины" могут являться параметры объема работ по подготовке техниче ского задания, представленные в таблице, представленной ниже.
Ресурсы и объем работ по подготовке технического задания
┌────────────┬────────────────────┬───────────────────┬─────────────────┐
│Размер банка│ Количество │Примерное время для│ Примерный │
│ │ выделенных для │завершения этапа с │ суммарный объем │
│ │ постановки задачи │учетом согласований│ задания в │
│ │ аналитиков │ │ страницах, с │
│ │ │ │ учетом │
│ │ │ │ комментариев │
├────────────┼────────────────────┼───────────────────┼─────────────────┤
│Небольшой │ 2-3 │ 1-2 месяца │ 100-150 │
├────────────┼────────────────────┼───────────────────┼─────────────────┤
│Средний │ 4-5 │ 3 месяца │ 200-300 │
├────────────┼────────────────────┼───────────────────┼─────────────────┤
│Крупный │ 6-8 │ 4-5 месяцев │ 350-500 │
└────────────┴────────────────────┴───────────────────┴─────────────────┘
