То, чего нет в стандартах, но полезно в проектах преобразований

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

В технической реальности привыкли называть проекты «жесткими цифровыми идентификаторами» (изделие№3527). Или здоровенным названием, включающим и цель, и описание, и заказчика, и пользователя, и адрес прописки проекта («Проект постройки современного луна-парка на 3 Га между улицей Казачьей и промзоной», «Проектирование эффективной системы закачки рабочего агента в пласт для нужд цеха добычи сырья» или «Проект разработки ИТ-системы внутреннего CRM для улучшения взаимодействия и повышения клиенториентированности между департаментами Банка»).

Но в социально-экономической реальности название проекта имеет весомое значение.

Во-первых, люди любят красивые названия.

Персонально я, в том числе как бывший военный, поработавший в свое время с «секретками», стараюсь использовать:

· или ключевое слово из проекта (например, «Грейдинг», «OpMod» и т.д.)

· или запоминающуюся звучную аббревиатуру (например, TLDP или IRMT, iCRM). К примеру, знаете ли Вы, что у нас в СССР предлагалось еще Китовым внедрить единую госсеть вычислительных центров, а его последователем Глушковым – общегосударственную автоматизированную систему от госплана до цеха? Запомнили эти оба проекта с первого раза? А проектное название первого было ЕГСВЦ, а второго ОГАС… Думаю как минимум название ОГАС большинство слушателей не забудет.

· или какое-то интересно-заманчивое название (например «Скрепка», «Реактор», «Энштейн»). Кстати, проект ЕГСВЦ имел название «Красная книга».

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

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

Например, я когда-то реализовал для одной транснациональной компании проект TLDP – и когда его результаты перешли в процесс Performance Management, люди еще года три его TLDP называли. Но важно не то что его долго еще так называли – важно то, что при управлении проектом название уменьшает необходимость лишней коммуникации и объяснений «а о каком именно проекте идет речь?» – все все сразу схватывают.

Вот такая-вот нестандартная штука (имя / название проекта), но очень полезная для проектов преобразования социально-экономических систем.

Методологии управления проектами

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

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

И одна из главных задач менеджера проекта – правильно выбрать методологию реализации проекта или комбинацию методологий. О комбинации методологий мы будем говорить еще отдельно.

И еще замечу, что упомянутый в предыдущей главе РМВоК (как и любой стандарт, справочник или каталог) это не методология – это свод знаний об управлении проектами.

А методологий в практике на сегодня выделяют две (если привязаться к РМВоК, то в их основе лежат уже упоминаемые ранее предиктивный и адаптивный жизненные циклы):

· Waterfall (каскад, водопад)

· Agile (гибкий, проворный, адаптивный)

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

WATERFALL – это последовательно-каскадная методология. Она предполагает, что все этапы проекта осуществляются последовательно, четко следуя плану.

Описание – Планирование – Разработка -Внедрение – и т.д….. – как изображено на рис. 1.17.

Закончив один этап – переходите ко второму, т.е. планомерно, от этапа к этапу двигаясь к результату проекта.

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

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

В частности, важно для длинных проектов, в которых среда нестабильна и требования могут меняться с течением времени – когда Вы 3 месяца анализировали, 2 месяца проектировали, зашли в годовую разработку… а среда и цели настолько сменились, что результат проекта уже и не нужен.

Особенно это критично для социально-экономических систем, когда и заказчик может за период реализации «вырасти» и понять, что ему не это нужно; и социальная часть изменится; или экономически станет нерентабельным…

Приведу простенький изменения среды. После M&A (слияние и поглощение) в одной из стран СНГ 5 юрлиц стали единой компанией. Но поскольку антимонопольный комитет не дал разрешение на слияние – они де-юре остались 5 юрлицами, но де-факто уже стали единой компанией с единым менеджментом.

Сотрудники, доходы и бюджеты оставались числиться во всех 5 юрлицах в своих учетных системах: причем в конкретно взятом отделе руководитель отдела с 3 подчиненными мог быть в одном юрлице, еще 2 подчиненных в другом, еще один в третьем и т. д. И сводить людей, бюджеты, доходы по такой структуре в детализированном виде естественно было невозможно.

И вот пока 4 месяца ИТ, кадры, управленческий учет и бухгалтерия совместно писали бизнес-требования как выгружать информацию из всех ИТ-систем для единой интегрированной компании, пока ИТ с подрядчиком еще 8 месяцев разрабатывали, пока 2 месяца тестировали и устраняли ошибки – антимонопольный комитет «дал добро» на слияние и программа в принципе стала не нужна.

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

Поэтому когда продукт и требования к нему четко определены, технологически все определено и низковариативная среда – смело используем Waterfall.

AGILE – это итерационная методология, когда Вы двигаетесь к результату короткими итерациями. Причем важным является перечень основных характеристик продукта/результата проекта – а реализация идет по итеративным циклам.

Итерации могут касаться этапов – тогда имеем дело с итеративным жизненным циклом (рис.1.18).

Или они могут касаться продукта\результата проекта, который делается «по-кусочку» (инкремент за инкрементом) – тогда имеем дело с инкрементным жизненным циклом (рис.1.19).

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

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

На практике обычно эти оба цикла используются вместе (я уже об этом писал ранее в главе о жизненном цикле проекта), поэтому в среде практиков можно просто говорить об адаптивном жизненном цикле (Agile-методологии) как таковом.

Очевидное преимущество Agile – это учет изменений как требований клиента, так и среды. Т.е., Agile наиболее подходит для проектов с нечеткими, вариативными, высоконеопределенными требованиями и\или средой.

С моей т.з. лучше всего эту Agile-методологию (адаптивный цикл) в ее практическом виде олицетворяет SCRUM (СКРАМ) – визуализация на рис.1.19.1.

В Скраме:

– Готовится описание результата, который разбивается на перечень всего того, что мы хотим получить (на кусочки) – Продукт-бэклог;

– Проект разбивается на маленькие отрезки (так называемые «спринты» или «забеги» если аутентичнее к русскому языку) длиной от недели до максимум месяц, каждая со своим набором задачек из Продукт-бэклога (т.е. имеет бэклонг для спринта);

Конец ознакомительного фрагмента.