Доклад был представлен Николаем Мациевским, web-директором компании Acronis, на конференции по управлению проектами и предпринимательству WhaleRider 2013. Являясь настоящим профессионалом в области высоких технологий, Николай в течение 10 лет работает в этой сфере деятельности, в том числе сотрудничая с такими компаниями как «Acronis» и «Parallels». На конференции он поделился своим опытом и рассказал о том, как нужно действовать в проблемной ситуации, когда собрана команда, и выпускается продукт, но качество того или другого является неудовлетворительным.

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

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

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

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

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

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

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

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

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

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

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

Инфраструктурных сотрудников (например, программистов, тестировщиков, локализаторов, менеджеров по рекламе, по маркетингу), то есть людей, которые занимаются конкретными задачами, необходимо максимально освободить от необходимости принимать управленческие решения. Во-первых, эти люди некомпетентны, во-вторых, по сведениям Николая, они тратят на это 30-50% своего рабочего времени, хотя на процесс создания продукта принятые ими решения влияют мало. У инфраструктурных сотрудников есть конкретные задачи, на выполнение которых им стоит уделить максимум своего внимания. Если же такие сотрудники действительно могут изменить процесс организации выполнения этих задач в лучшую сторону, их необходимо выделить как перспективных сотрудников и переместить в категорию менеджеров.

Существуют проекты, которые текущая команда сделать не в состоянии, так называемые «невозможные проекты». Не стоит опускать руки: любая задача имеет решение. Нужно лишь понять, хотите ли вы действительно добиться выполнения этой задачи, а затем решить, как это сделать чисто технически. В первую очередь, необходимо заранее обрисовать крайние сроки реализации проекта (Николай считает, что 30% проектов не запускается просто потому, что не определена четкая дата запуска). Далее нужно определить минимальный набор требований к готовому продукту. Если при этом не совсем понятно, как успеть создать продукт с этим набором требований до заранее оговоренного крайнего срока запуска, то необходимо собрать совещание текущих команд и определить, какие возможны технические пути решения этой проблемы.

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

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

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

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