Большой стандарт для маленькой компании

Применение MSF в качестве стандарта уровня предприятия в управлении проектами развития информационной инфраструктуры

Борис Александрович Летучий - главный технолог компании «СетьПроект», ему можно написать по адресу letuchiy@netproject.ru

В этой статье описываются опыт и результаты внедрения дисциплины управления проектами MSF в качестве стандарта уровня предприятия в компании «СетьПроект». Для правильной оценки нашего опыта необходимо хотя бы кратко охарактеризовать нашу компанию.

«Сетьпроект» — небольшая молодая компания, она существует с 1998 года, хотя специалисты, составляющие ее костяк, работают вместе с 1996 года. Специализация компании — проекты развития информационной инфраструктуры.

Мы называем информационной инфраструктурой предприятия совокупность всех его информационных технологий и средств, на которых эти технологии основаны. Информационная технология, в соответствии с ГОСТ 34.003-90, — это «приемы, способы и методы применения средств вычислительной техники при выполнении функций сбора, хранения, обработки, передачи и использования данных», а средства — это не только компьютерное оборудование и каналы передачи данных, но и архитектура локальных и глобальных сетей, протоколы и транспорты, сетевые операционные системы, программное обеспечение компьютеров, доменные и другие структурные модели.

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

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

К искреннему огорчению автора, преобладающим является взгляд на информационные технологии как на всего лишь «средства предоставления и поддержки доступа к данным и услугам обработки данных». Этот взгляд неизбежно принижает и роль информационных технологий, и статус руководителя подразделения информационных технологий. Если главный технолог машиностроительного завода вхож в кабинет директора, то «главного технолога по процессам обработки информации» этого же завода примет разве что заместитель директора, а то и руководитель третьего уровня. Снижается и статус инициатив по развитию этих технологий, что в итоге негативно влияет на развитие предприятия. Впрочем, обсуждение различных последствий такого взгляда заслуживает отдельной статьи.

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

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

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

Понимая, что не только повышение эффективности работы, но и само существование компании возможно только при профессиональном управлении проектами, мы решили найти, адаптировать и внедрить методику, сочетающую методы проектного управления, стандарты разработки проектной документации, детализированные процедуры работы и шаблоны документов. Стандарт PMBOK (Project Management Body of Knowledge), которым мы руководствуемся, затрагивает все темы, имеющие отношение к управлению проектами, однако деталей в нем не хватает; в то же время на полную разработку детальной методики своими силами у нас не хватало ресурсов.

Фирменный стандарт управления проектами мы решили построить на основе дисциплины Microsoft Solutions Framework (MSF). Ниже будут описаны ее особенности и опыт применения в сочетании с другими стандартами и документами. Мы назовем факторы, способствующие (а также мешающие) уверенному и качественному выполнению многодисциплинарных проектов силами распределенных команд в срок и в рамках смет.

Состав MSF

MSF — это набор принципов и правил деятельности, в некоторой степени ориентированный на проекты разработки программного обеспечения и развития информационной инфраструктуры. Ядром MSF являются шесть основных групп принципов, называемых моделями:

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

Ранее в документах фирмы Microsoft описывалась и седьмая модель — модель совокупной стоимости владения (TCO), однако в более свежих материалах эта модель как часть MSF не упоминается. Возможно, она перемещена в другие дисциплины (одна из них — Microsoft Readiness Framework), о которых Microsoft заговорила сравнительно недавно.

Модель производственной архитектуры

Рис. 1. Модель производственной архитектуры

Модель производственной архитектуры объединяет взаимодействующий персонал, процессы и технологии. Персонал участвует в процессах, применяя технологии (рис. 1).

Эта модель состоит из четырех так называемых «перспектив»: бизнеса, приложений, информации и технологий.

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

Модель производственной архитектуры отражается в документах, разрабатываемых уже в самом начале проекта — в фазе анализа требований к создаваемым системам. В этой фазе разрабатывается документ «Образ и границы проекта» (его называют еще концепцией проекта, а мы, прикладывая такой документ к договору, называем его обоснованием проекта); значительная часть «образа и границ» посвящена выявлению и формализации именно деловых потребностей организации, ее целей, ролей пользователей системы и сценариев их работы. Ориентация на деловые требования подчеркивается и в документах, разрабатываемых в последующих фазах.

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

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

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

Не понимая приоритетов информационных технологий, распорядители кредитов в таких условиях склонны обращать внимание на произвольный элемент информационной инфраструктуры, вызывающий у них наибольшее доверие (например, на кабельную систему), причем они добиваются обоснования выгодности этого элемента; к сожалению, обосновать выгодность одного элемента без учета его взаимосвязи с другими элементами информационной инфраструктуры иногда просто невозможно: та же кабельная система сама по себе выгоды не приносит.

Несмотря на это, применение данной модели дало нам определенные выгоды. Мы всегда стараемся узнать у клиента планы развития его бизнеса и предлагаем двух-трехлетнюю программу совершенствования информационной инфраструктуры. Это позволяет выработать планы действий, которые включают и рутинную деятельность, и проекты, связывающие текущие и перспективные задачи.

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

Модель проектной группы

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

Данная модель определяет шесть основных ролей участников проектной группы:

• менеджера продукта, отвечающего за удовлетворение требований заказчика;
• менеджера программы, ответственного за своевременное выполнение проекта в рамках бюджета;
• разработчика, реализующего систему (а также, например, разрабатывающего комплект проектной документации на сеть);
• тестера, испытывающего не только продукт, но и его спецификации и документацию к нему;
• логистика, отвечающего за разворачивание продукта и легкость его поддержки;
• инструктора, деятельность которого направлена на повышение эффективности труда пользователей (не производительности системы!). Кстати, инструктор организует и обучение разработчиков, если в проекте предстоит применить новую технологию.

Участники проектной группы взаимодействуют не только между собой, но и с участниками проекта, не входящими в проектную группу. Обязанность взаимодействия с каждым внешним контрагентом возложена на определенного участника проектной группы (рис. 2).

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

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

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

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

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

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

В наших проектах важны вспомогательные роли администратора, сопровождающего, реализатора и связиста, описанные в материалах по MSF очень уж кратко. К сожалению, MSF не описывает детально важнейшие роли заказчика и пользователя (как это сделано в отношении участников проектной группы), хотя именно участие заказчика в проектах и взаимодействие с ним порождают множество проблем.

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

Мы определили недостающие роли, их деятельность в ходе реализации проекта и результаты этой деятельности по аналогии с имеющимися описаниями, хотя, будь эти описания исчерпывающими, мы сэкономили бы свои усилия. Определение этих ролей позволяет нам точнее оценивать потребности в персонале заказчика (например, участниках пилотного внедрения) и его трудозатратах; без этого практически неизбежно катастрофическое отставание от графика при подключении персонала заказчика, когда начинаются предварительные испытания, пилотное внедрение и окончательное развертывание системы.

При сравнении с детально проработанной моделью проектной группы MSF перечень организаций, участвующих в разработке автоматизированных систем (справочное приложение 2 к ГОСТ 34.601-90), вызывает только горькую усмешку.

Модель процесса описывает фазы проекта, контрольные точки каждой фазы, ее результаты и деятельность участников проектной группы в каждой фазе (рис. 3).

Рис. 3. Фазы и контрольные точки

В учебном курсе, включающем главы по MSF, утверждается, что модель процесса реализует не итерационный подход к созданию решения, а некий универсальный подход, в связи с которым упоминается UML. Так или иначе, в соответствии с этим подходом создается несколько версий продукта, а создание каждой версии проходит фазы анализа, планирования, разработки и стабилизации (в проектах развития информационной инфраструктуры чаще называемой развертыванием).

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

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

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

Сопоставив описания результатов проектных работ с ГОСТами 34-й серии, мы разработали самодокументированные шаблоны документов; их применение свело к минимуму потребность в обучении исполнителей, привлекаемых на один проект, так что разработка шаблонов, которую мы продолжаем, быстро окупается.

Модель управления рисками

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

В 1999 году описание модели управления рисками MSF представлялось гораздо более конкретным, чем, например, описание управления рисками в издании PMBOK 1996. Даже сейчас оно, пожалуй, не уступает описанию управления рисками в недавно вышедшем PMBOK 2000.

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

Рис. 4. Упреждающее управление рисками

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

Хотя методика управления рисками полезна и сама по себе, по-настоящему ценной она становится только тогда, когда накоплен хотя бы минимальный перечень рисков, которые на деле опасны для реального проекта в данной предметной области. К нашему удовлетворению, доступным оказался даже не перечень, а программа (Microsoft IT Advisor for Risk Management), позволяющая нескольким экспертам оценить значимость множества факторов риска и объединить их оценки в общую оценку рисков проекта.

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

(Один из рисков, о котором спрашивает IT Advisor, — неспособность поставщика программного обеспечения предоставить адекватную техническую поддержку за приемлемую цену. Тут сразу вспоминается техническая поддержка моего легального Microsoft Word; впрочем, я отвлекся.)

Модели процесса проектирования и приложения

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

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

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

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

Другие стандарты...

Применение MSF не предполагает полного отказа от использования всех других стандартов. Модели MSF мы применяем не вместо стандартов, а вместе с ними.

Общую картину фаз проекта и процессов, составляющих управление проектом, дает стандарт PMBOK. Ему недостает конкретики (она в него и не закладывалась), зато он привлекает полнотой. Руководитель компании и один из ведущих специалистов были обучены основам управления проектами на базе этого стандарта, а еще один сотрудник эти основы даже преподавал.

Многим нашим заказчикам знакомы ГОСТы 34-й серии на автоматизированные системы. Эти ГОСТы не только полезны при переговорах, но и служат основой проектной документации, поскольку определяют структуру многих документов. Стадийность, принятая в ГОСТ 34, несколько более подробна, чем перечень фаз модели процесса MSF, однако заказчика, как и нас, устраивает стадийность MSF, и разногласий не возникает.

Как отмечалось выше, часть проектов мы выполняем с соисполнителями. Если проект включает разработку программного обеспечения, применяются стандарты 19-й серии (Единая система программной документации, ЕСПД).

Многие наши клиенты, особенно в промышленности, придерживаются стандартов предприятия, которые предписывают оформлять даже сугубо текстовую документацию в соответствии с ГОСТами 2-й серии (Единая система конструкторской документации, ЕСКД). При использовании компьютеров это несложно, однако ЕСКД предусматривает не только определенный порядок оформления документации, но и определенный порядок ее обращения, в частности выпуск изменений к отдельным листам. Когда речь идет о чертежах, это вполне естественно, однако длинный текстовый документ гораздо проще переиздать целиком, чем выпускать изменения к листам, поэтому мы уклоняемся от использования ЕСКД для текстовых документов. По счастью, многие заказчики соглашаются, что отступление от ГОСТов в этих случаях оправданно.

...и не только стандарты

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

Мы заказали дизайнеру не только «обычный» фирменный стиль (эмблема, визитная карточка, конверт, бланк), но и детально проработанный стиль большого сложного документа. Следование этому стилю сделало наши документы легкочитаемыми, облегчило их восприятие и, несомненно, способствует принятию их заказчиками. Забавно, что, переверстав в соответствии с этим стилем один из ГОСТов 34-й серии, мы обнаружили в нем гораздо больше смысла, чем замечали до этого. Фактически нашим документам обеспечено техническое и художественное редактирование.

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

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

Наконец, мы очень тщательно проработали договоры, которые заключаем с заказчиками и другими контрагентами. Мы не только сделали договоры читаемыми и исключили из них двусмысленности; включение в них неизбежных, хотя и незначительных санкций для обеих сторон позволяет обеспечить неуклонное продвижение проекта. Казалось бы, такие договоры должны вызвать резкое неприятие со стороны клиентов; на практике клиенты просят разрешения использовать эти договоры для оформления отношений с другими контрагентами.

(Случай из практики. Начальник отдела информационных технологий заказчика приводит нас в финансовый отдел обсуждать договор. Начальница отдела резко протестует против санкций, объясняя, что важно не то, есть санкции или нет, а то, из чьей зарплаты вычитать уплаченные пени. «Вот у него будем вычитать», — показывает она на начальника отдела информационных технологий. «Почему у меня? — удивляется тот. — Я всегда мгновенно перекидываю бумаги вам, а уж у вас в отделе они зависают. Это из вашей зарплаты пойдут пени». Документ немедленно получает согласующую визу.)

Заключение

Наша компания невелика, и свободных ресурсов у нас немного. Работа по стандартизации выполняется в свободное время и с невысоким приоритетом, например, когда почему-то затягивается рассмотрение документов клиентом. Поэтому в данной статье рассказывается не только о результатах, но и о подходах.

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

Найти материалы по MSF нетрудно. MSF обсуждается в недавно опубликованном учебном курсе по разработке программного обеспечения (Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD. М.: Русская редакция, 2000). Другие источники информации: энциклопедия технической поддержки TechNet (доступна по подписке и на узле http://www.microsoft.com/TechNet), энциклопедия разработчика MSDN (по подписке и на узле http://msdn.microsoft.com/), узел MSF в Internet (http://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise&AnnMenu=solutions).