Технический директор, день 2: сокращение команды
Очень важный проект, который был решен и который обеспечит будущее организации на следующие пять лет, не состоялся.
Отсутствие победы в этом проекте означало, что организация была вынуждена «фокус» и сократить расходы.
Мне никогда не приходило в голову, что одной из первых вещей, которые меня попросят сделать как неопытного технического директора, будет увольнение части команды.
Сокращения и командные принципы
Фрагмент команды разработчиков «фокус» означает снижение себестоимости на 10-15%. В человеческом исчислении стреляют от двух до четырех человек (из 17).
После нескольких неудачных попыток приблизиться к этой задаче это сработало для меня.
Я начал с перечисления некоторых принципов:
- Для каждого продукта нам необходимо охватить следующие дисциплины: внешний интерфейс, серверная часть, архитектура, эксплуатация, мобильные устройства, UX, дизайн, контроль качества, лидерство и управление продуктом.
- Обычно существует 3 уровня опыта:
- Старший: создает план.
- Средний уровень: следует плану.
- Джуниор: нужно научить следовать плану.
- Никакое количество младших сотрудников не может выполнять работу, которую может выполнять старший.
- Отсутствие старшего специалиста по дисциплине будет означать, что качество продукта пострадает:
- Если сеньор создает план, команда из среднего и младшего звена может какое-то время (2-3 года?) следовать этому плану, прежде чем продукт превратится в большой беспорядок.
- Чтобы выбраться из большого беспорядка, нам нужны старшие люди.
- Мы уже в большой неразберихе с продуктом А и продуктом Б.
- С нынешней командой кажется, что Продукт А выбирается из беспорядка.
- Независимые (кросс-функциональные) команды более эффективны:
- Больше внимания.
- Никаких передач, более быстрая обратная связь.
- Отсутствие конкуренции за общие «ресурсы».
- Люди, работающие над несколькими продуктами/командами, менее эффективны.
- Многопрофильные (универсальные) люди:
- Может покрыть потребность в нескольких дисциплинах.
- Они могут быть младшими в одной дисциплине и старшими в другой.
- Разрешить сосредоточиться на каком-либо приоритете, не создавая искусственно важной работы для однодисциплинарных участников.
- Максимальный размер команды: 2 пиццерии по 6-8 человек.
Идеальная команда — это та, в которой все дисциплины охвачены на высшем уровне, а междисциплинарные люди работают только в одной команде, и при этом достаточно дублируется, чтобы избежать автобусный фактор одного. Дополнительные люди принесут дополнительную мощность.
Обратный маневр Конвея
Мы работали над объединением трех продуктов в течение некоторого времени. У них уже был один и тот же менеджер по продукту, но они все еще были тремя командами, работающими над своими собственными приоритетами. Объединение их в одну команду, в классическом обратный маневр Конвея мы надеемся ускорить интеграцию между продуктами.
Один из других продуктов был настолько мал, что для этой задачи я решил временно его игнорировать.
Следуя изложенным выше принципам и соображениям относительно продукта, планировалось перенести предыдущую настройку команды из:
Что-то вроде (коробки обозначают навыки, а не людей):
Итак, два продукта, две кросс-функциональные команды. Платформы и команды дизайнеров будут перетасованы внутри этих двух команд.
Кого из родителей вы любите больше всего? Компьютер расскажет
Имея четкий план для команды, следующим шагом было «просто» подобрать, кто будет работать в каждой команде, а кого нам нужно будет отпустить. Самое болезненное решение в моей карьере.
Люди с сильным техническим образованием могут превратить любую задачу в техническую, избегая тем самым работы, которую они не хотят делать. Джерри Вайнберг, Стать техническим руководителем
А выполнять задачу мне не хотелось, поэтому, сознательно игнорируя г-на Вайнберга, я превратил это испытание в задачу оптимизации, для решения которой написал приложение, которое мне поможет.
Приложение
Приложение приняло в качестве входных данных сумму $$$ для сокращения, список людей, их зарплату и уровень квалификации по каждой дисциплине, упомянутой выше, и вывело две возможные команды, которые будут в рамках бюджета и соответствуют минимальным требованиям, отсортированные по балльной системе.
Минимальные требования и конфигурация системы подсчета очков выглядели так:
{
"FE" [at-least-senior sum-skills]
"PM" [senior-plus-somebody-else (fix-points 5)]
"Design" [two-mid-or-senior (senior-better 6 2)]
...
}
Первая функция отфильтровывает недействительные команды, а вторая оценивает действительные.
В примере мы говорим, что команда должна иметь:
- По крайней мере, один старший разработчик FE. Чем больше разработчиков FE, тем выше результат команды.
- Как минимум один старший продакт-менеджер и один средний или младший менеджер. Одного старшего мало. Независимо от того, сколько PM в команде, оценка по этой дисциплине равна 5. Команда с большим количеством FE-разработчиков наберет больше баллов, чем команда с кучей PM.
- Минимум старший дизайнер или два дизайнера среднего уровня, но мы предпочитаем одного старшего дизайнера (6 баллов) вместо двух дизайнеров среднего уровня (2 балла).
Результат
Каким бы бессердечным это ни казалось:
- Это убрало некоторую предвзятость. По-прежнему существует предвзятость в оценке уровня квалификации и в системе командного подсчета очков.
- Я был среди тех, кто был в этом списке. Честно говоря, здесь мало утешения. Большая предвзятость.
- Это заставило меня быть очень и очень точным в том, что имелось в виду под «действующей командой».
- Это позволило мне увидеть, что выдают различные системы подсчета очков.
- Я заметил, что некоторые люди никогда не будут отображаться в выводе, и мне пришлось разобраться, почему. Это было поучительно.
- Это позволило мне проанализировать десятки тысяч различных комбинаций команд с разными системами подсчета очков.
- Программирование дало мне передышку от задачи. Это было впервые, но теперь я более регулярно провожу дни программирования «сохраняю рассудок».
Самое главное, приложение дало мне несколько отправных точек. Из них мне все еще приходилось учитывать динамику команды, существующие команды, личности, старшинство, потенциал, личную ситуацию, будущие потребности…
Сообщение плохих новостей
Как только решение было принято, пришло время проглотить последнюю горькую пилюлю.
Некоторые советы:
- Убедитесь, что пострадавшие люди узнают об этом первыми.
- Предупредите заранее:
- Не используйте свое обычное место для личных встреч.
- В своем сообщении дайте сильную подсказку: «HR-менеджер будет на встрече», «Очень плохие новости».
- Дайте им время подготовиться к встрече.
- Вам не нужно делать это в одиночку. Наш менеджер по персоналу присутствовал и оказал огромную поддержку нам обоим.
- Относитесь к людям как к взрослым.
- На встрече следуйте за Надей ван дер Влис. совет:
- Нанести удар:
- Сразу к плохим новостям.
- Назовите одну-две причины.
- Управляйте реакцией:
- Будьте понимающими. Не оправдывайтесь.
- Дайте пространство. Не заполняйте тишины.
- Решение, объяснение, последующая встреча:
- Дождитесь готовности сотрудника. Когда она начинает спрашивать «почему» или «что теперь».
- Повторите причины.
- Нанести удар:
- Через пару дней состоится еще одна более неформальная встреча. Новость бы провалилась, а разговор был бы более дальновидным и продуктивным.
Пощечина, чтобы пробудить меня от мечты о том, что роль технического директора в основном связана с технологиями.