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


Предисловие


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


Продолжим наши музыкальные аналогии. Как и в предыдущей статье(К+П №2 2005), которая была посвящена управлению требованиями в проекте, мы будем вести две взаимно переплетающиеся темы: описание инструмента визуализации и описание модели предметной области, построенной с помощью этого инструмента визуализации.


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


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


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


Первые участники


С чего начинается благополучный проект? Конечно же с денежного Заказчика! Ну, а раз он Заказчик — значит, что-то ему нужно, он что-то заказывает и даже готов платить за это Что-то!


Итак, наша отправная точка — это Заказчик с его насущной потребностью и готовностью оплачивать удовлетворение этой потребности.


Но для того, чтобы потребность выросла в Заказ, необходим Исполнитель (реальный или воображаемый). Как Заказчику, так и Исполнителю для спокойствия душевного нужен юридический договор, а для этого каждому из них неплохо было бы иметь юридическое лицо. Попробуем воспользоваться юридическим буквариком: Заказчик и Исполнитель — субъекты, Заказ — объект их совместной деятельности, Договор — Юридический Документ, регулирующий эту совместную деятельность.


Обратимся к диаграмме сущностей (рис. 1), визуализирующей описанные выше понятия. И Заказчик, и Исполнитель являются Юридическими Лицами. Этот факт отображается связями абстрагирования, соединяющими сущности "Исполнитель" и "Заказчик" с сущностью "Юридическое Лицо".

 


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


Далее существует понятие Юридического Документа, по отношению к которому соответствующее Юридическое Лицо играет роль Субъекта (см. соответствующую ассоциацию на предыдущем рисунке). Таким образом из диаграммы следует, что Договор является частным случаем Юридического Документа, субъектами которого являются Исполнитель и Заказчик как частные случаи Юридического Лица.


Теперь — сущность "Заказ". Как для Заказчика, так и для Исполнителя, Заказ выступает в роли субъекта совместной деятельности. По отношению же к Договору Заказ является предметом этого самого Договора.


Рис. 1 является простым примером диаграммы сущностей UML в общепринятом стиле расположения ее элементов на рисунке. Приведем несколько "правил хорошего тона" для такого стиля.


Общие требования:

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

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

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

Все организации-участники

 

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

 


Расположим элементы в виде привычного для пользователя Windows многоуровневого списка, где каждый узел соответствует уровню обобщения (детализации) сущности. Текстовая интерпретация диаграммы на рис. 2 может быть такой: все организации-участники делятся на Ключевых и Факультативных. Ключевыми являются Исполнитель и Заказчик, все остальные участники — Факультативные. К числу последних относятся:

  • Поставщики (сырья, материалов, решений, технологий, услуг и т.д.);
  • Потребители Продукта — результата выполнения Заказа (например, жильцы дома, постройка которого заказывается);
  • Подрядчики — то есть исполнители, которым доверяется часть работ, но которые не взаимодействуют напрямую с Заказчиком, а несут ответственность перед ключевым Исполнителем;
  • Владельцы Продукта (например, реальные хозяева будущего построенного дома);
  • Инвесторы, вложившие свои средства в проект в надежде на ожидаемую прибыль, однако, в общем случае, не имеющие каких-либо возможностей повлиять на ход исполнения Заказа, и т.д. По-хорошему, их тоже надо бы помянуть в Договоре…

Ищем первую личность


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


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


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


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


Руководство Исполнителя назначает РПИ и представляет его Руководству Заказчика. Идеальным будет вариант, когда РПИ выбран и назначен еще до начала переговоров, а представляется Заказчику (и утверждается в своем статусе!) после первых же договоренностей. Однако в жизни нередки печальные ситуации, когда РПИ остановлен охранником на проходной Заказчика и пытается связаться со своим Руководством по мобилке. Никому не нужный и никому не известный… Не лишены любопытства также случаи, когда к моменту 89-процентной готовности проекта РПИ узнает о том, что он не только НЕ руководитель проекта с самого его начала и до текущего момента, но даже не сотрудник фирмы, а всего лишь лицо на испытательном сроке.


Как гарантированно завалить Руководителя Проекта, а вместе с ним — и сам Проект


Одной из ключевых особенностей проектной работы является принцип двойного подчинения сотрудников — членов проектной группы. Что имеется в виду: каждый участник, включая и самого РПИ, помимо своих прав и обязанностей в рамках проекта, продолжает выполнять определенных круг работ в качестве сотрудника своей организации — и, следовательно, за ним и должны сохраняться соответствующие права. Спрашивается, зачем понадобилось упоминание, а тем более акцентирование внимания читателя, на таком, казалось бы, очевидном, да еще и необязательном моменте? Оказывается, это одно из самых опасных "узких мест". Здесь кроется источник скрытого ущемления интересов РПИ, что не только катастрофически повышает степени всех имеющихся рисков, но еще и добавляет ворох новых.


Самая "пикантная" ситуация — когда РПИ назначается не просто из новичков, но вообще из стажеров на фирме. При этом для руководства главное — "выдержать линию", не "проявить слабость" и т.д. Соблюдая эти принципы, Руководство старается строго выверять давление на РПИ, чередуя кратковременное постановление последнего то в статус маститого сотрудника фирмы, то в статус не менее маститого "контрактника". Для определения того, какой именно статус предоставить РПИ в текущий момент и при текущих обстоятельствах, начальство руководствуется простым и надежным критерием: минимум прав и максимум обязанностей.


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

  • весь предыдущий опыт и наработки РПИ автоматически становятся достоянием фирмы (очевидно, что здесь нужно поставить РПИ в позу полноправного сотрудника фирмы);
  • все его прежние (и будущие) промахи и изъяны однозначно закрываются на положении контрактника, то есть исправляются за свой счет;
  • опыт и наработки фирмы, предоставляемые РПИ в качестве стартовой базы,— бесценное сокровище, не нуждающееся в каких-либо затратах на его освоение (все сотрудники фирмы это уже давно знают и умеют применять!);
  • во всех случаях, где существует альтернативный выбор, чьи именно (РПИ или фирмы) наработки и технологии применять, преимущество однозначно отдается старым наработкам и технологиям фирмы. Ведь РПИ — всего лишь сторонний контрактник, а посему должен подстраиваться;
  • все промахи и изъяны фирменных наработок и технологий (а главное — все прежние посулы и обещания фирмы Заказчику) автоматически становятся "достоянием" РПИ — как полноправного и полномочного представителя фирмы (имеешь право отвечать за все);
  • и, наконец, главное: оклад РПИ назначить, как положено контрактнику, то есть нулевым. Зато премиальные за успех — как сотрудникам фирмы, то есть % от оклада, да и то по окончанию проекта.

Закладываем основание настоящего успеха


Нам уже слышатся возмущенные возгласы со стороны "ответственного руководства": мы в этих россказнях ничего не поняли, а времени потратили изрядно (читай — "устали!")! Давайте-ка коротко и ясно предложения по существу ("конкретно!") — и идем дальше.


Для стабильной и эффективной работы РПИ необходимо предоставить ему достойное место в среде участников проекта — и, в первую очередь, отдать ему решающие права по формированию Проектной Группы. Реальность этих прав немедленно проверяется, проявляясь уже на самом первом шаге.


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


Главное назначение РПЗ — разделять (вместе с РПИ) ответственность за судьбу проекта. Это лицо, официально отвечающее "да"/"нет" ("готово"/"не готово", "подходит"/"не подходит") на ключевые вопросы руководства по поводу результатов проекта. Попросту говоря: лицо, подписывающее документы со стороны Заказчика.


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


Однозначно, что формирование команды проекта — компетенция и обязанность РПИ. И в процессе работы над созданием проектной группы наиболее ответственной и болезненной для него оказывается вакансия РПЗ. Как правило, серьезно повлиять на выбор кандидата не получается — в лучшем случае удастся "наложить вето" на решение руководства Заказчика. Но остается право (и обязанность!): разработать должностную инструкцию и добиваться ее утверждения, а затем — исполнения.


Набираем сотрудников Заказчика


После утверждения РПЗ оба РП формируют отделение группы Заказчика. В него должны входить Инспектора, Администраторы, Эксперты и Консультанты.


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


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


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


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


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


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


Диаграмма классификации


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

 


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


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


На самом верху этой классификации оказывается РПЗ — как Инспектор, наделенный в рамках проекта неограниченными (опять же, в рамках Проекта) административными правами.


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


Визуализация принципа двойного сотрудничества


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


Данная диаграмма, хотя и достаточно объемна, читается легко. Упрощение восприятия достигается за счет многократно примененного расположения элементов диаграммы в виде многоуровневого списка:

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

Рассмотрим еще раз список классификации сотрудников из подгруппы РПЗ, но уже на рис. 4. Каждый участник в этой подгруппе является одновременно составной частью как организации-Заказчика, так и Проектной Группы. К тому же классы еще и связаны между собой свойством наследования (абстрагирования). Отображение всех связей портит внешний вид общей диаграммы. Поэтому, следуя принципу приоритета визуализации, скроем часть ассоциаций включения, идущих от классов сотрудника Заказчика к сущности Проектная Группа, чтобы диаграмма красиво смотрелась. А дотошных читателей отнесем к рисунку с фрагментом диаграммы, полностью отображающим все связи (рис. 3). Здесь НЕэстетичность пересекающихся изображений связей побеждается более разреженным расположением элементов фрагмента общей схемы.

 


Для визуализации понятия "Внутренние Участники Проекта" воспользуемся еще одним простым приемом: просто проведем границу, выделяющую область, которой будут принадлежать все внутренние участники. Сюда попадают сущности "Исполнитель" и "Заказчик" вместе с их классом-обобщением — "Ключевой Участник", сущность "Проектная Группа" и все ее члены, в том числе сотрудники организаций, являющихся для проекта внешними (Поставщики, Потребители, Подрядчики, Владельцы, Инвесторы и т.д.).


Подведем итоги


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


Отдельно следует отметить трудности, с которыми мы столкнулись, подбирая русский эквивалент англоязычному термину Project Team. Традиционный примитивный перевод — Команда Проекта — нас принципиально не устраивал.

 


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


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


За кадром осталась классификация сотрудников подгруппы РПИ, но это лишь первая часть материала, посвященного участникам проекта. Классификация сотрудников-исполнителей требует более глубокой и обширной проработки и будет положена в основу второй части. Замечательно распределение материала: описание подгруппы исполнителя и описание всех остальных участников проекта приблизительно равны по объему. Это наталкивает на мысль, что и в реальной работе нагрузка и ресурсы РПИ должны распределяться точно так же: половина — на свою подгруппу, половина — на всех прочих.

2005.06.24
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".