Трансформация или чемодан без ручки (часть 2) Как избежать кризиса с ключевыми сотрудниками?

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

Итак, какая здесь возникает проблема?

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

По моему опыту, значительно чаще имеется другая ситуация: Особенно в случае с компаниями, которые образовались достаточно давно. Хотя понятие давно в ИТ сейчас сводиться к 3-5 годам существования коммерческого продукта. И в этом случае, когда нужно не немного подкрутить старое решение, а принципиально поменять продукт и признать, что имеющиеся технологические/архитектурные решения уже безвозвратно устарели. То, что было рождено в головах сотрудников, выстрадано их интеллектом, реализовано собственными руками, сегодня становится программным антиквариатом, место которому в музее и в архивах на СХД. Это значит, что позиция, которую они занимали в компании и которая позволяла им чувствовать себя неуязвимыми и незаменимыми, меняется на диаметрально противоположную. Ведь признать, что выстраданный тобой идеальный продукт, в который вложено так много, теперь откровенно устарел. Что он приносит больше проблем, чем денег, и что ты не «бог», который может реализовать любой запрос пользователя на кончиках пальцев. А признать что именно ты и разработанный тобой продукт есть причина раздражения всего бизнес-подразделения — это сложно.

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

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

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

Но время идет.

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

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

Подход заключается в следующем:

Ситуация выглядит следующим образом:

Что делать в этой ситуации? По моему опыту, нужно выполнить следующие пункты:

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

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

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

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

Реализация вышеописанных пунктов и всего подхода в целом позволяла мне проводить трансформации эффективно и с минимальным уровнем конфликтов внутри компании.