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

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

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

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

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

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

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

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

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

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

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

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

Приверженность 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