Украинские IT-компании теряют клиентов из-за неправильно выстроенной стратегии управления внутри компании
Деятельность практически любой украинской IT-компании неразрывно связана с реализацией различных проектов. В независимости от их величины или направленности, будь то разработка программного обеспечения, системная интеграция, внедрение программных комплексов или автоматизация производства. Несмотря на то, что каждый из этих проектов уникален (в самом термине «проект» заложена уникальность), проблемы при их реализации возникают одни и те же. Владельцы и топ-менеджеры украинских IT-компаний, которые обращаются к нам за консультанциями по управлению проектами, говорят о постоянных срывах сроков проектов и перерасходе бюджетов. Иными словами, даже если проект завершен - его нельзя считать успешным. Руководители компаний прекрасно понимают, что и срыв сроков, и перерасход средств отнюдь не причины, а симптомы «болезни». Что же является настоящими причинами и как с ними бороться? Попробуем обобщить наш опыт и разобраться в этом вопросе при помощи такой науки, как проектный менеджмент.
Приведем простой пример – представьте себе среднестатистическую украинскую IT-компанию в динамике ее развития (предположим, что направление ее деятельности – разработка программного обеспечения на заказ). История компании до боли знакома – когда-то группа единомышленников-программистов решила перестать работать «на дядю» и начать работать на себя. О том, чем заниматься, вопроса не возникало – разрабатывать ПО. При помощи личных контактов был найден первый заказчик, снят офис в помещении бывшего НИИ и работа закипела. Прошли годы, появились постоянные заказчики и деловая репутация, а значит и новые клиенты, разросся штат, было построено свое офисное здание – бизнес обещал быть стабильным и безоблачным. Но, как это всегда бывает, проблемы возникли там, где их совсем никто не ждал.
Для одновременной реализации десятков крупных и мелких проектов были набраны новые программисты (частично студенты), ключевые посты заняли отцы-основатели и толковые программисты. Во главу угла было поставлено качество разрабатываемого ПО и самый жесткий контроль – это был топ-менеджмент компании (напомним, бывшие программисты). Причем речь шла непросто о качестве, а о том, чтобы при создании каждого продукта максимально приблизиться к идеалу, поэтому проекты постоянно дорабатывались, что автоматически обозначало опоздание по срокам. Все решения по проектам принимались следующим образом – менеджер проекта (старший программист), приходил к топам и выкладывал свои проблемы (передавал информацию) и видение путей их решения. Дальше происходило коллегиальное обсуждение и принятие решения, причем длиться это могло с перерывами несколько дней и недель. Топы считали такую схему работы очень оправданной, и гордились своеобразной «близостью к народу».
Со временем что-то пошло не так в датском королевстве. По истечению финансового года, вдруг выяснилось, что затраты на зарплату превысили поступления от сданных проектов. Руководство очень удивилось такому факту, ведь работа кипела, и они вместе со всеми засиживались в офисе допоздна. Так куда же делись деньги? Выяснилось, что работа действительно кипела, а вот сданных проектов за год было не так уж много – всего 7 (в разработке находилось около 30). Возник вопрос: почему так происходит? Руководство стало разбираться с каждым проектом отдельно, пытаясь понять, в чем задержка, что опять таки вылилось в целую кучу совещаний, заседаний и вызовов «на ковер». В результате прошло уже целых два месяца от нового финансового года, а воз был «и ныне там», более того ситуация ухудшалась – сразу два крупных заказчика отказались от услуг компании.
Для того чтобы разобраться с происходящим попробуем ответить на извечный вопрос «Что делать?» с точки зрения проектного менеджмента. Первопричина сложившейся в компании ситуации заключается в отсутствии системного проектного подхода к деятельности компании. Что это значит? Разложим по полочкам.
Проект (разработка программного обеспечения) подразумевает под собой комплекс действий, направленных на получение уникального результата (качества), в рамках ограниченных сроков и бюджетов. Операционная деятельность же (например, производство пластиковых труб) не предполагает уникального результата и, по сути, не имеет ограничений по времени и бюджету. Поэтому для достижения успеха подходы к управлению этими двумя видами деятельности должны быть разными. Что же мы видим в нашей компании – руководство жертвует сроками и бюджетом (ведь программистам каждый месяц нужно платить зарплату) в угоду качеству, не понимая при этом, что в цепочке время-деньги-качество все компоненты взаимосвязаны и напрямую влияют друг на друга. И если при небольшом количестве одновременно ведущихся проектов операционное (читай, ручное) управление еще может справиться, то с их увеличением обязательно наступит крах управленческой оргструктуры. Именно поэтому и выяснилось в конце года, что затраты на зарплату превысили поступления от сданных проектов. Гонясь за качеством, топ-менеджмент упустил из виду два остальных фактора успеха любого проекта. Это если говорить глобально, теперь же сформулируем проблемы компании по отдельности.
В первую очередь в компании не был налажен эффективный обмен информацией. Как мы знаем, о происходящем в проекте топ-менеджеры узнавали из уст менеджера проекта (старшего программиста). При этом понятно, что он мог представить дела как угодно, руководствуясь своими личными целями. Не имея независимого от менеджера проекта постоянного потока информации и не видя общей картины происходящего в портфеле проектов, топ-менеджмент не мог принимать адекватные управленческие решения, не говоря уж о сроках их принятия. Результат – еще большая задержка и порой не решение проблем, а их усугубление. Выход из этой ситуации – организация корпоративной системы управления проектами в лице отдельной службы, которая будет собирать информацию, анализировать ее и предоставлять руководству. Основа работы такой системы – корпоративные стандарты системы принятия решений, как по отдельно взятому проекту, так и всему портфелю проектов компании, а также такие необходимые составляющие, как организация документооборота по проекту и портфелю проектов.
Во-вторых, в этой компании существует проблема с делегированием полномочий. Практически все решения по любому проекту (менеджер проекта, по сути, является передаточным звеном) принимаются руководством компании. Это работало, когда проектов было три, а когда их стало тридцать, у топов физически не стало хватать времени. Результат – задержки по проектам и убытки. Решение проблемы – это делегирование полномочий различным уровням менеджмента. Добавим, что из нашей практики мы знаем, что на самом деле при грамотном разграничении ответственности и делегирования полномочий около 5% решений по проекту требуют вмешательства высшего руководства. Эти 5 % решений касаются по существу в рамках портфельного управления, а именно перераспределения ресурсов между проектами в рамках портфеля, причем перераспределение в связи с изменением приоритетов проектов. Остальные решения делегируются менеджеру проектов и функциональным руководителям. Конечно же каждый менеджер должен четко понимать (и это тоже прописано в должностной инструкции) как он отвечает за свои решения – все должны знать правила игры.
Позаботиться об этом, следует при помощи создания эффективной системы мотивации «на результат». В нашем примере получается, что сам менеджер проекта в первую очередь не заинтересован в своевременной сдаче проекта – ведь он получает зарплату помесячно, и, соответственно, чем больше будет длиться проект, тем больше он получит. То же самое касается и рядовых программистов – получается, что платят им не за результат (готовую в срок программу), а за время, проведенное на рабочем месте. Решением является определение, что же является результатом и разработка системы премирования/штрафования за достижение/недостижение результата.
Все о чем говорилось выше – это лишь то, что лежит на поверхности, ведь существует еще множество нюансов. Здесь и создание единой базы данных для всех проектов (своеобразной памяти компании), и разработка компьютерных моделей для расчета ресурсов, бюджета и времени, и обучение менеджеров навыкам управления проектами, и описание бизнес-процессов компании, и многое-многое другое. Внедрение проектного подхода, безусловно, займет время и потребует вложения средств, но с его использованием большинство проблем компании будут решены в зародыше. Тем более, когда бизнес развивается и может не устоять на ногах, если не будет разумного равновесия между качеством, бюджетом и сроками.
