1-ая часть статьи - доступна вот здесь.
Всех, кому интересно обсудить тему будущего проектного управления ждем на вебинаре в четверг 30 января. Подключайтесь!
В прошлой статье я начала разбирать, как соотносятся группы процессов и области знаний из прошлых версий PMBoK и принципы из новой.
Давайте продолжим разговор. Про ответственное управление, команду, заинтересованные стороны и ценность мы уже поговорили, разберем остальные 8 принципов:
5. Целостное мышление (Holistic thinking). Это взгляд на все то же Управление интеграцией немного под другим углом. Опять же, не то, чтобы необходимость для руководителя видеть картину целиком (big picture) - это принципиально новая идея.
Те, кто учились на моих курсах помнят фото-загадку - Как вы считаете, где в этом проекте (по переноске бревна через пропасть) место руководителя проекта? Жду ваших версий в комментариях - чур, выпускники - не подсказывать!
Англоамериканский сатирик начала 20-ого века Стивен Ликок в одном из своих произведений так описал своего персонажа “Думать для великого сыщика означало действовать, а действовать - означало думать. Иногда ему удавалось делать и то и другое одновременно”... Характеристика, конечно, ироничная, но, как известно, в каждой шутке есть доля шутки, а всё остальное - правда. Правда в данном случае в том, что одновременно анализировать ситуацию в целом и действовать невозможно. И беда многих проектов внедрения в том, что их исполнители за деревьями не видят леса. В том смысле, что концентрируются на выполнении конкретных задач и реализации определенных функций и не задумываются над тем, а поможет ли этот функционал пользователю на самом деле решать его задачи? Когда спрашиваешь исполнителя напрямую, очень часто слышишь ответ: “ничего не знаю, Заказчик так просил/бизнес так сказал, я просто делаю по ТЗ”. Но такой подход, как вы понимаете, противоречит первому принципу про “ответственное планирование и управление”. Подход, когда исполнители проекта задумываются о целях и помогают добиться именно целей Заказчика более перспективен, чем исполнение не задумываясь. Хотя, честно скажем, и более трудоемкий. В условиях высокой конкуренции и демпинга на рынке внедрения 1С, многие франчайзи жалуются, что если “копать глубже”, проект станет для них просто нерентабельным. Что можно на это ответить? Все то же - что если удастся показать заказчику (неважно, внешнему или внутреннему), что он заинтересован в более тщательном и вдумчивом исполнении проекта, чем простое выполнение не всегда согласованных требований бизнеса - то заказчик явно окажется в плюсе, даже если проект в итоге окажется дороже. Ну, то есть я не призываю делать проекты по реорганизации бизнес-процессов по цене развертывания стандартной коробки. Но это то направление, в котором стоит двигаться.
6. Лидерство. В предыдущих версиях PMBoK про лидерство много говорится в разделе про “Роль руководителя проекта”. А в 7-ой версии, кстати, подробно объясняется, что лидерство стоит проявлять отнюдь не только РП, а всем членам команды!.. В том плане, что все могут проявлять инициативу, выступать в роли наставников, мотивировать и поддерживать своих коллег и т. п. И, опять же, не забываем, что лидерство не надо путать с полномочиями. Многие аспекты лидерства разбираются в предыдущих версиях PMBoK в разделах Управление человеческими ресурсами (про необходимость в большей степени мотивировать, чем приказывать) и Управление коммуникацией (про выбор подходящих каналов коммуникации - в том числе виртуальных, про разрешение конфликтов при помощи консенсуса или сотрудничества, а не директивных указаний “все делаем так-то, потому что я сказал!”). На тему грамотного лидерства рекомендую почитать книгу “Как пасти котов” (пособие для программистов, как руководить другими программистами). Общий подход автора к руководству можно понять уже из метафоры в названии - вы можете представить себе стадо котов, которым пастух управляет при помощи кнута? Да они же моментально разбегутся, в процессе пастуха еще и оцарапав!.. Нееет, с котами нужен другой подход: кому-то молочка в блюдечко налить [премию пообещать за хорошую работу], кому-то за ушком почесать [похвалить за заслуги], с кем-то в мячик поиграть [интересную задачку подкинуть].
7. Адаптация. Это еще один аспект Управления интеграцией. Каждый проект уникален, и пытаться загнать все проекты в жесткие рамки конкретной методологии может оказаться вредным.
Мне вспоминается на эту тему анекдот про автомат для бритья:
А вот машинка для автоматического бритья. Вставляете сюда свое лицо, и она вас гладко бреет
- Но ведь у каждого человека - своя форма лица?!
- О, это только в первый раз!
PMI рассказывал про разные подходы к проектам в “Путеводителе по Agile”, прилагающемся к 6-ой версии PMBoK. Я рассказывала про них, в частности в статье:
Можно ли объять необъятное или чем Agile отличается от водопада?
8. Встраивание качества. Этот принцип, собственно, продолжает область знания про Управление качеством из предыдущих версий PMBoK. Напомню, качество понимается здесь как соответствие требованиям (как явным, так и не явным). И основная идея, что качество должно быть встроено в процессы и результаты, а не просто обеспечиваться за счет героических усилий отдельных исполнителей (это, конечно, работающий метод, но, во-первых, герои слишком быстро выгорают на работе, а во-вторых, результаты героических усилий не очень предсказуемы и мало повторяемы от проекта к проекту).
Кстати, разнообразные мероприятия из подхода Agile - такие как частые демонстрации заказчику, поставки по частям, встречи по обсуждению того, как работать лучше (ретроспективы) - как раз призваны в том числе способствовать повышению качества.
9. Управление сложностью (или запутанностью? не знаю как лучше перевести complexity). Это еще один аспект всё того же Управления интеграцией с одной стороны, и Управления содержанием с другой. К сложности проектов приводит масса разных факторов - в том числе человеческое поведение (далеко не всегда рациональное - вспомните сколько раз вас удивляло поведение пользователей!), сложности систем (в том числе бюрократических - внутри которых вам предстоит внедрять те или иные программные решения), неоднозначность (например, я регулярно сталкиваюсь с тем, что при сборе требований с разных подразделений получаю явно противоречащие требования), неопределенность (ответы на многие вопросы можно получить только попробовав - то есть уже реализовав какой-то функционал и выдав его на пользовательское тестирование, чтобы получить реакцию в формате “ой!..”)
10. Возможности и угрозы. Здесь мы говорим, фактически об Управлении рисками. Тема обширная и непростая, я про риски как минимум две статьи публиковала на Инфостарте: Риск - благородное дело!.. Часть первая и Часть вторая
Подробно вдаваться здесь в эту тему не буду, напомню только, что управление рисками - это подход, предполагающий составление стратегии действий заранее, и противоположный привычному многим “стресс-менеджменту”, когда все бюджеты и расписание составляются “впритык”, и дыры судорожно залатываются по ходу дела уже по факту возникновения внештатных ситуаций.
Хотя вот Иван Селиховкин в своем курсе в теме про риски Алгоритм управления рисками утверждает, что управление рисками - в смысле, предположения, чего плохого может случиться, - для русского человека дело естественное. Мой опыт утверждает обратное, поделитесь как обстоят дела в вашей компании? Принято ли предполагать заранее, какие угрозы есть у проекта и придумывать стратегии реагирования? Или скорее действовать по факту?
11. Адаптивность и жизнестойкость (adaptability and resilience). Этот пункт, пожалуй, более привычно было обсуждать в контексте Agile проектов (в предыдущих версиях PMBoK о нем говорилось вскользь). Но контекст любых проектов меняется в последние годы всё быстрее, поэтому этот принцип признан важным для проектного управления в целом. Что имеется в виду? Готовность адекватно реагировать на меняющиеся внешние условия. Могу привести пример крупного банка, который сначала заказал проект разработки программного обеспечения “по уму”, то есть с согласованным заранее ТЗ, четко определенными сроками и бюджетом. Получил через полтора года ровно то, что заказывал, только к этому моменту контекст изменился настолько, что продукт оказался неактуальным. Следующий проект с тем же подрядчиком реализовывали уже основываясь на принципах “адаптивности и жизнестойкости” - маленькими итерациями, корректируя ТЗ по мере изменения обстоятельств.
12. Управление изменениями. Еще один аспект Управления интеграцией (не путать с контролем изменений), тесно связанный с предыдущим пунктом (адаптивность и жизнестойкость). И здесь, кстати, главный фокус внимания упирается во всё то же вовлечение заинтересованных сторон, которое я упоминала в начале. Потому что люди, как известно, консервативны. Японский подход к управлению проектами (P2M) вообще говорит, что основные три кита проектного управления - это управление сложностью, ценностью и сопротивлением изменениями. Так вот, когда мы планируем любое изменение, нужно быть готовым, что не все заказчики/ пользователи/менеджеры будут к нему готовы, и в любом случае кто-нибудь да будет вставлять палки в колеса. Кстати сказать, согласна с формулировкой моего коллеги, который сформулировал следующее условие успешности проекта внедрения нового программного продукта взамен старого. За внедрение нового продукта и развитие старого должен быть ответственным один и тот же человек, и он должен быть заинтересованным во внедрении. Иначе пользователи так и будут использовать “привычный” продукт, дополняя его новыми “костылями” по мере необходимости - лишь бы не переходить на новый (работать с которым в любом случае окажется сложнее, чем в уже привычной среде - как минимум, в ходе переходного периода). Поэтому нужно, чтобы кто-то в какой-то момент сказал: “Стоп. Этот функционал добавлять в старый продукт мы не будем. Если он понадобится - нужно использовать новый…”
Ну что, мы поговорили про принципы, который проектный институт советует ставить в основу проектного управления. За кадром осталась система поставки ценностей (Value Delivery System), Области деятельности (Performance Domains).
Приглашаю к продолжению разговора на эту тему на бесплатном вебинаре 30 января.
До новых встреч на Инфостарте!
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах