Top.Mail.Ru
Колонки

«Пацаны не извиняются»: 6 главных ошибок IT-руководителя

Колонки
Маргарита Лебедева
Маргарита Лебедева

Бизнес-партнер ИТ-компании Proscom

Елизавета Шатохина

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

«Пацаны не извиняются»: 6 главных ошибок IT-руководителя
  1. Колонки

 

Как ошибки руководителей влияют на эффективность работы

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

Действительно, нематериальные факторы влияют на эффективность команды и прибыльность компании. Если руководитель оскорбляет и унижает подчиненных, то их мотивация и желание что-то делать падает. К примеру, 30% сотрудников работают медленнее или ошибаются (для сравнения, в обычных условиях — это 6%).



Кстати, особо эмоциональны работники творческой сферы (графические дизайнеры, инфограферы, копирайтеры, 2D- и 3D-художники и другие): в условиях агрессивного стиля управления их эффективность в три раза ниже. Они также отказываются от выполнения новых задач. В результате бизнесу не хватает инноваций, он стагнирует, а конкуренты идут вперед.

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

 

RB.RU рекомендует лучших поставщиков цифровых решений для вашего бизнеса — по ссылке

Неготовность рисковать и принимать самостоятельные решения

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

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

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


По теме: Дилемма рекрутинга в привлечении талантов: Build, Buy или Borrow


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

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

Мнения членов команды разделились: некоторые склонялись, что проект слишком рискован и разрушит репутацию при провале. Другие понимали, какие перспективы откроются, если мы успешно реализуем проект.

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

Итог — мы со всем справились и успешно выполнили условия контракта. Заказчик был доволен и назвал нас «лучшими исполнителями, с которым ему доводилось сотрудничать».

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


Полная авторитарность

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

Для авторитарного управленца характерны:

  1. зацикливание всех вопросов на себе — только он обладает властью для принятия решений;
  2. взращивание сотрудников, неспособных нести ответственность;
  3. ограждение команды от информации по проекту, которая их «не касается»;
  4. дистанцированность от команды;
  5. игнорирование внутренних сигналов от команды (снижение мотивации, конфликты, несогласие со стратегией).

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

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

Что же изменилось с момента передачи проекта под наше руководство?

Возросла инициатива тимлидов — они больше погрузились в процессы, начали участвовать в формировании ТЗ, декомпозиции задач и их оценке. Благодаря этому нам удалось провести новые архитектурные работы, которые повысили производительность сервиса в разы. Мы также наладили agile-ритуалы и наши встречи стали активными, результативными и быстрыми.

Кроме того, мы начали активно вовлекать всех членов команды в процессы и разделили ответственность — каждый отвечал за свою часть работы. Это увеличило производительность команды, мы стали покрывать больше запросов на доработки — например, актуализацию стоков, согласование прайс-листов, переход на ЮЗДО (юридически значимый документальный оборот), повысился бюджет продукта.

В результате мы стали выполнять 100% поставленных планов.

График прибыли (замена руководителя началась в Q2)
Так, после всех сложностей перехода, спустя три месяца команда встала на новые рельсы и начала выдавать значительно лучший результат.
План работ

 

Отсутствие доверия к сотрудникам

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

Сотрудники, не занимающие управляющие или лидирующие роли, ограничены в видении своим департаментом или проектной командой.

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

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

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

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


По теме: 5 стратегий для удержания сотрудников

Для понимания этапов построения команды менеджерам полезно изучить модель Брюса Такмана — «Forming, Storming, Norming, Performing» («Формирование, Конфронтация, Нормирование, Выполнение»).

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

Чтобы повысить прозрачность в уровнях ответственности сотрудников, полезно составлять на проектах матрицу RACI.

Методика RACI — средство проектирования и планирования изменений, участия различных ролей в процедурах и задачах процесса:

R — Responsible — исполняет.

A — Accountable — несет ответственность
C — Consult before doing —консультирует до исполнения.
I — Inform after doing — оповещается после исполнения.
Два этих инструмента устанавливают паттерн взаимодействия сотрудников, формируют реалистичные ожидания и положительно сказываются на доверии к членам команды.

 

Приверженность Fixed price формату

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

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

Fixed price формат выбирают руководители, которые привыкли работать по модели водопада.

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

Кроме того, предусмотреть абсолютно все и отразить это в техническом задании — невозможно. А Fixed priced-контракты с недостаточно детализированным ТЗ вынуждают сдерживать заказчика в его пожеланиях. И приводят к продуктам, которые по документации сделаны на 100%, а на деле — далеки от ожиданий пользователей.

Мы стараемся использовать продуктовый подход с расчетом в формате Time & Material. Это дает больше гибкости в формировании и приоритизации бэклога. 

В соглашении Time & Material (T&M) общая стоимость не определяется в начале сотрудничества — она зависит от количества часов, затраченных на проект, и материалов, использованных для его реализации. Таким образом, даже если проект займет гораздо больше или меньше времени, чем предполагалось, обе стороны могут быть уверены, что они получат оговоренный продукт.

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

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

У нас было несколько кейсов — сервис для повышения качества жизни, платформа для международного маркетплейса, сервис для сдачи недвижимости — когда после Fix price контракта удавалось приобщить заказчика к ценностям продуктового подхода — последующие контракты уже заключались на T&M.

 

Всегда говорить «да»

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

У нас был заказчик, который всегда очень торговался (буквально за каждый рубль) и постоянно менял требования. И мы шли навстречу, естественно, в ущерб марже. Это длилось около года, и к концу нашего сотрудничества все члены команды были настолько опустошены, что не могли выдавать тот же качественный продукт, что был раньше. И только благодаря тому, что мы собрались и поднажали, мы не ушли в минус. Больше мы с этим заказчиком не работаем.

На самом деле тут все просто. Руководствуйтесь этими критериями при выборе проекта:

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

 

Отсутствие выстроенных отношений с сотрудниками

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

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

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

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

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

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

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

Такие отношения — путь к доверительному и прозрачному сотрудничеству.

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

Чтобы этого не происходило, можно придерживаться следующих правил:

  1. Искренне приносить извинения с четким обозначением ошибки и ее последствий. 
  2. Обязательно подчеркивать, в чем был прав сотрудник — это стимул для налаживания взаимоотношений.
  3. Брать ответственность только за свою часть ошибки, а не глобальный провал, где оплошности допускались разными участниками.
  4. Обязательно предложить способы разрешения вопроса.

Чаще всего ошибки находятся в зоне классического треугольника проекта, который формируется из тройственного ограничения: объем работ, сроки, стоимость. Баланс этих аспектов определяет качество. Другими словами, если объем плановых работ равномерно встраивается по срокам и достаточно при этом покрывается бюджетом (косты плюс маржа), закрывается основная часть рисков.

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

Наша матрица рисков во время пандемии

Что следует сделать, чтобы этот документ принес максимум пользы:

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

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

Фото на обложке: Freepik

Подписывайтесь на наш Telegram-канал, чтобы быть в курсе последних новостей и событий!

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Топ-6 стратегий привлечения персонала в 2024 году
  2. 2 4 рабочих метода сплочения команды в онлайне
  3. 3 «Инструкция по эксплуатации» аутсорсинговой компании: 6 правил для бизнеса по выбору подрядчика
  4. 4 Снижаем уровень стресса в офисе: лопаем «пупырку» и чилим в гамаках
  5. 5 Самые высокооплачиваемые вакансии января в стартапах
Relocation Map
Интерактивный гид по сервисам и компаниям, связанным с релокацией
Перейти