Проектное управление из первых рук. Как это на самом деле работает в крупном российском бизнесе

На одном языке

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

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

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

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

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

⠀

На одном языке

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

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

К нашему удивлению, получить ответы на эти простые вопросы оказалось чрезвычайно сложно. Например, выяснилось, что главный бухгалтер владела программой, что называется, со словарем – точнее со шпаргалкой, на которой была записана простая последовательность нажатия кнопок на клавиатуре. Требования одних сотрудников оказывались заоблачными, других – противоречивыми. Большинство же стейкхолдеров, хоть и жаловались на прежнее ПО, высказывались в том смысле, что если уж оно работает, то и делать ничего не надо – а то, не дай бог, станет еще хуже.

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

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

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

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

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

⠀

Изнутри

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

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

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

Кто-то из читателей уже наверняка подумал: легко сказать – убедите стейкхолдеров в том, что проект выгоден! А как это сделать? Искусству убеждения посвящена масса книг, но почему-то далеко не каждый, прочитав их, становится переговорщиком. Что делать, если не чувствуешь в себе сил воздействовать на мнение людей? Где их взять?

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

1. Проблемное интервью

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

2. «А почему Баба-яга против?»

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

3. Демонстрация выгоды

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

4. Мнение эксперта

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

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

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

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

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

Выводы:

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

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

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

Круги по воде:

как планировать и внедрять изменения

Автор Станислав Кречетов

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

⠀

Изнутри

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

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

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

Возможности рынка тут почти безграничны. Системы MRP управляют хозяйственными операциями и материальными потоками, CRM-системы упорядочивают взаимоотношения с клиентами, а ERP-системы приводят в порядок процессы управления в целом. Казалось бы, нанимай специалистов по специализированному ПО, внедряй – и получай дивиденды от роста эффективности бизнеса.

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

Лишь ответив себе на эти вопросы, вы сможете выбрать нужную вам систему, грамотно настроить ее и максимально безболезненно внедрить в бизнес-практику компании. По сути, это будет уже не IT-проект, а диверсифицированный системный проект, центром которого станет изменение бизнес-процессов в нужном направлении. А IT-система станет лишь подспорьем в этом процессе.

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

⠀

На одном языке

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

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

⠀

Изнутри

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

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

Основные ошибки в планировании изменений:

1. «Проблема лоскутного одеяла»

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

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

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

2. «Синдром Бога»

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

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

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

Мы и сами не избежали вышеперечисленных ошибок. Так, нам оказалась знакома проблема «лоскутного одеяла», когда выяснилось, что внедряемая ERP-система конфликтует с действующей на предприятии PDM-системой, отвечающей за управление продуктами, и создает много препятствий в работе. Грешили мы и «синдромом Бога», когда попытались сделать нашу систему как можно более глобальной – и тем самым тормозили ход давно и успешно налаженных кастомизированных проектов. Ликвидировать ошибки на ранней стадии и наладить работу тогда помогло именно тщательное наблюдение за всеми сопутствующими процессами и последовательный фокус на потребностях каждого из подразделений.

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

Затем пришло время вернуться к решению главной задачи – как организовать работу завода максимально эффективным способом? Найти ответ на этот вопрос нам помогла методика «Пять почему».

⠀ ⠀

На одном языке

«Пять почему» – методика анализа проблем, созданная японским предпринимателем Сакити Тоеда, основателем компании Toyota. Она позволяет с помощью последовательных ответов на вопрос «Почему?» добраться до первопричины любой проблемы. Изначально методика использовалась для устранения неисправностей производственного оборудования и ликвидации их первопричин. Впоследствии ее взяли на вооружение предприниматели, работающие в самых разных сферах, сделав ее качественным инструментом для решения не только производственных, но и организационных проблем, повышения качества и эффективности работы.

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

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

Выводы:

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

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

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

Часть 2.

Руководитель проектов

и его команда

Типы проектов

и их лидеры:

каждому свое

Автор Сергей Малоземов

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

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