Как организовать эффективное управление в команде разработчиков?

Часть первая: осознать проблему. Почему мы решили отказаться от менеджеров проектов.


Предистория.

JetRockets - это компания, в которой на данный момент работают 25 человек, но всего семь лет назад, на старте нас было лишь пятеро.

workload

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

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

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

Спустя какое время, появились постоянные проекты, а также новые клиенты. Это потребовало расширения группы разработчиков до 15 человек. С таким быстрым ростом команды оказалось достаточно трудно справиться. Резко возросла административная часть работы, а также количество и сложность задач.

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

Мы решили нанять менеджера проекта.

Каким мы видели менеджера проекта?

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

pm

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

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

Что на самом деле произошло?

В идеале мы искали кандидата, который соответствовал одному из следующих профилей:

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

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

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

Где искать менеджера?

В какой то момент мы осознали, что соискатели со стороны являются плохой идеей, поэтому мы решили искать менеджера проекта в нашей команде разработчиков, как говорится “воспитаем Бабу-Ягу в собственном коллективе”.

lead

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

И мы снова столкнулись с проблемами.

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

Чувствуя личную ответственность за проект, они предпочитали не делегировать свои задачи по разработке другим сотрудникам, действовали по принципу “хочешь сделать это хорошо - сделай сам!”. Лидеры проектных команд самостоятельно решали сложные и неотложные задачи, позволяя остальным сотрудникам выполнять простые и рутинные задания. Это привело к дальнейшему выгоранию, нестабильной рабочей нагрузке и потере мотивации, что в конечном итоге, повлияло на качество работы. И что еще важно, об этом действительно стоит помнить - не каждый хочет быть менеджером - лидером команды (да, нам нужно было усвоить этот трудный путь!)

Урок был выучен!

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

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

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

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

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

tobecontinued


Ilya
Mikrukov

CIO at JetRockets

Explore more of JetRockets