Составление плана работ

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

При составлении плана работ почти все участники проекта стремят- ся, чтобы их участие было как можно меньше. Исключением могут яв- ляться некоторые сотрудники отдела автоматизации, которые хотят, чтобы работа была как можно более интересной, желательно с реше- нием «сложных» задач, объемной разработкой новых программ и по- купкой оборудования. Как правило, эти люди контролируемы, но о них не стоит забывать. С другой стороны, и пользователи, заказчики зачас- тую пытаются автоматизировать операции, автоматизация которых не имеет никакого смысла, например операцию, которая возникает раз в полгода.

Реалистичность объема проектных задач и сроков — это первый экзамен, который должен успешно сдать менеджер проекта при начале работ и закрепить его в плане проекта. Самое легкое — отвечать на все предложения: «Мы это сделаем и очень скоро», ведь проект только на- чинается. Но ответственный руководитель проекта должен быть песси- мистом, учитывать опыт других проектов и очень реалистично оцени- вать имеющиеся силы и ресурсы и уметь говорить «нет», аргументируя свою позицию. Менеджер проекта, видя перед собой постоянно основ- ную цель проекта, должен уметь находить компромисс и убеждать все стороны.

Как же может быть сокращен и адекватно оценен объем требова- ний? Основным приемом снижения объемов работ является поиск ра- ботающих прототипов. Если требуются новые отчеты при расчете нало- гов, надо выяснить, нет ли аналогичных отчетов в других областях. Если требуется организация новой услуги, надо посмотреть, как она реали- зована в других банках. А если ее там нет, то еще раз проанализиро- вать ее необходимость.

Общий алгоритм поиска прототипа заключается в следующем. Сна- чала идет поиск аналогов решения всей задачи. Если их нет, то форму- лируется более общая задача и ищутся подобные решения. И так до тех пор, пока не будет найдено ближайшее по смыслу работающее реше- ние. Затем определяются доработки к нему. Например, если нужна сис- тема межфилиальных расчетов, за основу можно взять систему расче- тов в РКЦ или SWIFT, или систему «банк — клиент». Всегда есть анало- гичные системы, доработка которых существенно дешевле и надежнее, чем разработка системы с нуля. Кроме того, если в приведенном при- мере система расчетов будет создаваться на базе системы «банк — кли- ент», то побочным эффектом будет расширение предлагаемого клиен- там сервиса.

Другой универсальный механизм оценки адекватности требований и оправданности их автоматизации — это финансовая оценка. По каж- дой потенциальной задаче руководителем проекта может быть сделана оценка требуемого времени специалистов, учтены все необходимые другие ресурсы и в конечном счете получена оценка стоимости выпол- нения этой отдельной задачи. Она должна быть сравнима со стоимос- тью поддержки данной операции в «ручном» или полуавтоматическом режиме. Не очень умно автоматизировать получение отчета, затраты на ручное выполнение которого в десятки раз ниже стоимости доработки системы. Окончательное суждение в подобных вопросах должно при- надлежать представителям бизнеса.

Рассмотрим теперь технические вопросы составления самого плана проекта. Самая лучшая формула, которой можно при этом руководство- ваться, — это «Плохой план проекта сегодня лучше, чем хороший завт- ра». Многие руководители проектов пишут планы месяцами, они состав- ляют десятки страниц. Но, к сожалению, их никак не могут дописать и согласовать. План может быть объемным, но 2-3-страничный план, осо- бенно на начальных стадиях, не только является допустимым, но и бо- лее предпочтительным.

Из того, что обязательно должно быть в плане, — это ключевые точ- ки (обучение, согласование детальных требований, презентация и кор- ректировка прототипа, завершение разработки, начало и конец тести- рования, исправление замечаний, начало и окончание пользователь- ского тестирования, дополнительное обучение, начало опытной эксплуатации, переход на промышленную эксплуатацию) с точным ука- занием времени их наступления. Также в плане должны найти свое от- ражение перечень основных задач и их взаимозависимость, распреде- ление задач по этапам, ресурсное обеспечение и ответственные лица. Если все это есть и согласовано со всеми сторонами, то план достигает своей цели.