Абстрактная компания Z2Z – это один из признанных мировых лидеров по производству товаров народного потребления.

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

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

Рассматривая этот пункт, следует выделить ряд вопросов, ответив на которые принципы могут быть сформулированы.

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

• "снизу" - в тех случаях, когда пользователи какой-то системы сами испытывают некоторые неудобства при работе с ней, или, например, когда что-то меняется в бизнес-процессах Z2Z, и какая-то часть работы может быть полностью автоматизирована. В большинстве таких случаев команда, поддерживающая и владеющая системой, получает отзывы и предложения от этих пользователей, анализирует их, и, в случае целесообразности внедрения предлагаемых изменений, формирует уже свою, более конкретизированную "инициативу", которая дальше идет вверх по административной иерархии до нужного уровня (этот процесс несколько детальнее будет раскрыт в описании следующего типа "инициатив").
• от владельца системы либо команды ее поддержки – в тех случаях, когда специалистами ИТ выявляются какие-то дополнительные возможности по улучшению работающей системы, либо обнаруживаются перспективы создания новой. В обоих случаях этот уровень генерации идей не может игнорировать уровень будущих пользователей системы: увидев какое-то направление по улучшению производительности систем, специалист должен, помимо видимых, возможно, только ему "технических" преимуществ, представить и тщательно смоделировать влияние этих предлагаемых им изменений на пользователей системы. Нелишним тут будет наличие некой "обратной связи" от некоторой фокус-группы пользователей (возможно, наиболее продвинутых пользователей, или, к примеру, представителей абсолютно разных уровней подготовленности и опыта работы). Суть такого детального представления возможных изменений в системе такова, что в случае их отсутствия проект может пойти несколькими нежелательными для инициатора путями, а именно: в первом случае, начальство, рассматривая любую инициативу, посмотрит на проблему несколько шире, чем это сделал ИТ-специалист, и либо может сказать, что им (специалистом) не продуманы (а если и продуманы, то не изложены в предложении) какие-то конкретные моменты, и инициатива не может быть поддержана вообще. Либо, в более "мягком" варианте, начальство может предложить ИТ-специалисту доработать это же предложение, учтя не только свои интересы и свое видение, но и влияние изменений на весь процесс – и в таком случае те самые более широкие исследования надо будет все равно проводить, однако будет абсолютно зря потрачено время руководства (мало кто это будет приветствовать), время самого специалиста (не только потому, что цикл "инициатива-рассмотрение-утверждение" увеличится во времени, а и потому, что после возврата предложения на доработку специалистом будет потрачено значительно больше времени на все исследования, потому как возвращено на доработку предложение было именно для таких исследований, и не сделать эти исследования должным образом значит не дать своей инициативе повторного шанса – в третий раз на доработку предложение могут и не вернуть, просто не дав ему ходу дальше), ну и, в конце концов, репутация специалиста как хорошего менеджера J

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

После получения задания от руководства к разработке выбранного направления настает черед более фундаментальных и детализированных исследований проблемной области. В результате этого этапа на выходе менеджер проекта должен предоставить так называемый Project Initiation Document (PID) (или Project Initiation Form) - (см. Приложение). Этот документ должен регламентировать все аспекты, имеющие какое-либо отношение к ведению проекта, и, по сути, является как руководством к действию команды, работающей над проектом, так и четко сформулированными грядущими изменениями в бизнес-процессах. Этот документ чаще всего является доступным если не абсолютно любому работнику Z2Z, то, как минимум, соответствующим отделам, вовлеченным в проект. Кроме того, такой документ может быть запрошен со стороны начальства любого уровня, а также любыми другими сотрудниками в случае мотивации необходимости ознакомления с сутью проекта (очень часто такие эти документы используют для приобретения опыта при работе над похожим проектом, для поиска "нужного" человека в решении каких-то возникших проблем). Стандартные разделы этого документа следующие:

Background – описываются проблемная область, имеющиеся проблемы, предпосылки для инициации проекта.

Objective: To: - формулируется цель проекта (ЧТО мы делаем).

Objective: In a way that: - формулируются способы достижения цели (КАК мы делаем).

Objective: So that: - формулируются ожидаемые последствия реализации вышеизложенных способов.

Scope – перечисляются аспекты и области, которые планируются как часть проекта.

Out of Scope – перечисляются, возможно, нужные и относящиеся к проблематике сферы, на которые, однако, проект не будет распространен (они могут быть включены в другой проект, оставлены на будущее, оставлены "как есть", и т.д.).

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

Success Criteria – перечисляются те параметры, которые по окончании проекта будут замерены и сравнены с ожидаемыми значениями, и которые определят успешность проекта. Общее требование к таким критериям – они должны быть объективно измеримы, и реальны. Достаточно уместным, по моему мнению, является совет одного из боссов, данный мне в период подготовки моего PID: "You get what you measure" – "получишь то, что померяешь".

Benefits – перечисляются все преимущества и достоинства проекта.

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

Costs – перечисляются все статьи расходов на проект – в денежном и временном эквиваленте (например, $1000 для оплаты тренинга по какой-то технологии, и 500 человекочасов ИТ-специалистов).

Risks / Counter Measures – описываются предусмотренные риски, которые могут повлиять на проект, а также указываются возможные стратегии борьбы с ними. Следует отделять риски от Assumptions – первые очень реальны, вторые – уровня "если случится что-то из ряда вон выходящее". Соответственно, для Assumptions средства борьбы не указываются ввиду очень низкой вероятности их возникновения.

Project organization – перечисляются люди, вовлеченные в проект.

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

Project Manager – человек, управляющий проектом, и несущий личную ответственность за его выполнение.

Project Team – коллектив, который будет очень тесно вовлечен в работу над проектом, и у которых этот проект будет забирать большую часть их рабочего времени.

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

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

Синхронно с подписанием PID менеджером проекта назначается деловая встреча, – так называемый Project Kick-off Meeting – на которую, в большинстве случаев, приглашаются спонсор проекта, его команда и стейкхолдеры. Целью такого собрания является объяснение "скользких" моментов (хотя, вообще-то говоря, такие моменты должны быть разъяснены в PID), акцентирование внимания на важности проекта, приоритетности направлений и потенциальных угроз проекту. Также могут быть еще раз проговорены глобальные обязанности основных участников, "узкие" места проекта, где в сжатые сроки потребуется максимальная отдача вовлеченных в проект сотрудников. Успешным считается такой Kick-off meeting, когда по его завершении проект из стадии подготовки переходит в стадию реализации. Формально это собрание во многом дублирует саму суть PID, однако я абсолютно уверен в необходимости совмещения формального документа с вербальным общением, даже если они кажутся идентичными. Во-первых, такое собрание является в некоторой степени "вводным", "тренировочным" – многие вовлеченные в проект люди могут быть лично не знакомыми друг с другом, и так как личное общение обязательно понадобится в ходе проекта, то чем раньше эти люди будут хотя бы иметь понятие о своих коллегах по проекту, тем эффективнее будет идти проект в плоскости сотрудничества и работы в команде. Во-вторых, стиль ведения проектов вообще, и стиль проведения собраний у каждого руководителя проекта уникален, и формат этого первого собрания во многом определяет формат будущих собраний, без которых не обходится ни один проект. И, наконец, в ходе публичного обсуждения, казалось бы, понятных вещей существует высокая вероятность "озарения" каждого участника относительно всего проекта или его деталей, и, что вполне возможно, внесенные мгновенно изменения в PID смогут повысить эффект от проекта, сэкономить время в будущем на дополнительные исследования, и т.п.

• нотификационные сообщения. Таковыми в большинстве случаев являются электронные письма, составленные менеджером проекта или ответственным за это лицом, в котором очень сжато излагаются текущее положение проекта (этап, стадия), локальные задачи, стратегии их решения, а также в котором адресаты предупреждаются о приближающихся задачах, в решении которых потребуется их непосредственное участие. Стоит отметить, что, во-первых, это рассылаемое сообщение является не очень официальным, и, как следствие, не является обязательным при ведении проекта. Кроме того, такое письмо, как я считаю, является абсолютно неинформативным для всех членов команды, непосредственно участвующих в разработке проекта. Однако значение такого сообщения резко возрастает при адресации его т.н. ресурсам проекта – то есть тем людям, участие которых в проекте предполагается, хоть и в небольшой степени или на протяжении лишь какого-то этапа проекта. В таком случае для этих людей такое сообщение станет чуть ли единственным источником информации о течении проекта. Кроме того, ввиду занятости ресурсов проекта в других проектах, где они уже не являются только ресурсами, а полноправными членами тех проектов, человек не всегда сможет и захочет удерживать у себя в голове все нужные ему детали по этому "второстепенному" для него проекту. Изложенные же кратко в понятных всем терминах положения будут явно полезны для успешного ведения проекта.
• рабочие собрания – это способ коммуникации между членами команды проекта, непосредственно участвующими в нем. Такие собрания могут быть как аналогом некой ежедневной "планерки", принятой в некоторых как коммерческих, так и некоммерческих организациях, так и специально запланированным мероприятием; на таких собраниях могут присутствовать как вся команда проекта, так и лишь малая ее часть, а также специально приглашенные для получения экспертной оценки в каком-либо вопросе специалисты. На таких собраниях желательно наличие понятной всей терминологии и языка общения (что в условиях компании масштаба Z2Z крайне необходимо) – эти аспекты необходимо также учитывать при обращении за экспертной оценкой к "третьим лицам". Такие собрания должны, как мне кажется, носить исключительно рабочий (возможно, даже неофициальный) характер – грубо говоря, есть проблема, и, отвлекая всех участников собрания от остальных своих дел, не стоит тратить время на официальную организацию самого собрания, на вступительные (не относящиеся к самой проблеме) речи, и т.п. Все приглашенные должны быть заранее оповещены о сути проблемы, о возможных ее решениях, чтобы опять-таки не тратить потом коллективное время на вникание в суть вопросов, а прийти и участвовать в обсуждении, имея собственную четко сформулированную и мотивированную точку зрения.
• Project Status update (Обновление состояния проекта) собрания – обязательное для проекта собрание руководства проекта с прилагающимся официальным документом определенного формата. Суть такого собрания – держать в курсе дел проекта всех заинтересованных "вышестоящих товарищей", при этом получая от них мгновенный отклик на все спорные моменты. То есть по сути status update является формальной формой нотификационного письма, но отличия в том, что, во-первых, формат этого сообщения строго определен. Во-вторых, status update предполагает созыв собрания с целью либо отчетности о проделанной работе (завершенном этапе, полученных результатах и т.п.), либо решения каких-то спорных моментов, когда требуются дополнительные ресурсы (финансы, время, люди, и т.п.) или решение уровня, более высокого, чем менеджер проекта может позволить себе сделать.

• в разделе The Project Progress (Текущее состояние проекта) тезисно описываются достигнутые за отчетный период (с прошлого status update) результаты, а также те стадии, которые на текущий момент находятся в стадии выполнения
• в разделе Project issues (Возникшие проблемы) описываются возникшие за отчетный период проблемы, возможные или примененные стратегии решения, статус самой проблемы (решенная, в процессе решения, разрешимая, неразрешимая, и т.п.) и ресурсы, затраченные или предполагаемые на ее решение
• в разделе Next steps (Следующие шаги) перечисляются запланированные следующие шаги проекта с предполагаемыми сроками начала-завершения. Стоит отметить, что эти сроки могут отличаться от указанных в Project Initiation Document – в этом, собственно, и суть Status Update – чтобы гибко и мгновенно подстраивать ведение проекта под текущую ситуацию. То есть вполне нормальным событием является пересмотр всех сроков, указанных в PID, лишь на основании проведенного Status Update собрания.
• в разделе Resources Needed (Необходимые ресурсы) перечисляются запрашиваемые на планируемый временной период ресурсы – денежные средства, время, конкретные люди с указанными человеко-часами.

После стадии разработки некой системы идет стадия ее тестирования. Особенностью этой стадии является то, что, наряду с работающей "старой" системой (или старым порядком проведения каких-то процессов) испытывается и "новая", то есть та, которая была разработана в ходе проекта. В общем, процесс тестирования стандартен, и после получения каких-то результатов тестирования и доработки системы наступает следующий этап: это проведение обучающих тренингов и подписание Business Acceptance Test (BAT). Тренинг – это некий учебный курс, предоставляемый командой проекта, по прохождению которого специалист Z2Z в своей области умеет пользоваться всеми предполагаемыми возможностями системы. Тренинг может проводиться в различных форматах:

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

Внедрение системы осуществляется в 2 этапа: это Trial cutover и Deployment. Первый – это пробный запуск. В это время система работает параллельно со старой, все данные должны реплицироваться, и пользователи по возможности (то есть если система не сбоит) используют новую систему. Этот период длится сравнительно недолго – как раз столько, сколько нужно для удостоверения, что система достаточно надежна и функциональна. После осознания этого факта менеджером проекта созывается Go-not-go Meeting – такое собрание, на котором руководством проекта принимается решение, запускать ли систему, соответствует ли она бизнес-потребностям, или ряд каких-то требований не выполнен, и для запуска системы эти требования критичны.

Это соответствие отображается в Project Closure Document (Документ закрытия проекта). На основании этого документа руководством проекта (менеджером, спонсором, одноуровневыми со спонсором участниками проекта) принимается решение о закрытии проекта (в случае выхода его в такую стадию, когда система уже рабочая, ею пользуются, "держать" всю команду проекта не имеет смысла – необходимы лишь усилия на текущую поддержку системы) либо о его продлении. Первое, конечно, является более желательным – держать в проекте все запрошенные ресурсы, тем самым сбивая график других проектов, является крайней мерой, и, как я считаю, должно проводиться только в случаях наиболее приоритетных проектов. Если же объем проекта на запланированный срок не полностью выполнен, то в случае проекта не самого высокого приоритета первый может быть отложен на некий срок, а в последствии заниматься "залежавшимся" проектом не всегда и может получиться. Другим вариантом является передача проекта другому менеджеру (Project Handover). Следует отметить, что передача проекта возможно и на стадии его активной разработки (например, в случае увольнения менеджера, перевода на другую должность, другой сайт, и т.п.) В таком случае вся проектная документация передается новому менеджеру проекта, он вводится в курс дел, ознакамливается со всеми принятыми решениями, используемыми подходами и т.п. Все делается таким образом, чтобы новый человек в день своего вступления на новую должность смог вести начатое коллегой дело без потери эффективности.

• организовать и провести туристическую поездку в Будапешт на майские праздники.

• оформлен заграничный паспорт;
• оформлена въездная виза в Венгрию;
• найдена приятная для поездки компания;
• найдены необходимые для поездки средства;
• найден и оплачен подходящий тур.

• все въездные документы оформлены;
• веселая компания проводит в Будапеште 3 дня;
• к 5 мая довольные туристы возвращаются в Киев и к 8:00 готовы приступить к работе и учебе.

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

• оформление въездной визы;
• поиск отеля для проживания;
• составление экскурсионных программ;
• выбор маршрута движения автобуса.

• организация поездки (5 hours)
• переезд и экскурсионная программа (5 суток)
• затраты на тур ($100)
• дополнительные расходы ($150)

Пример Business Acceptance Test

Business Acceptance Test

ДАТА Подпись ФИО

2. Заказ в типографию будет оформлен к 15 октября 2001 года

1. 20 часов рабочего времени Петрова Р.Л.
2. Консультация представителей SAP R/3 в Украине
3. Тренинг по работе с SAP R/3 для будущих пользователей системы

Пример Project Closure Document

• Все съездившие получили заряд энергии и набор неизгладимых впечатлений
• Восторженный рассказ вдохновил родителей на финансирование следующей поездки
• Новые знакомства оказались крайне интересными и перспективными