В 2021 году я из тимлида разработки вырос в руководителя кроссфункциональной команды в 30+ человек. Пришлось быстро учиться руководить менеджерами, разбираться с зонами ответственности, изучать финансовые аспекты работы с клиентами.
Ниже — мои выводы о том, как приобретаются новые умения.
Shu-ha-ri: Повторяй — Изменяй — Делай по-своему
Я осознал, что все последние практические навыки изучал по шагам описанным в Shu-ha-ri:
- Повторять за кем-то. Найти самый упрощенный и легкий для понимания алгоритм.
- Начать изменять заученные действия. И так понять что значит каждый шаг и правило.
- Выстраивать свой алгоритм работы/действий
Сознательное принятие первого шага с полным копированием помогает скорее влиться в какую-то область не занимаясь перфекционизмом.
Если немного отойти от работы, то по такому же алгоритму я погружался в новое хобби. Например, в написание музыки. Этапы развития были (и есть) такие:
- Нашёл туториалы на YouTube . Повторял их один в один: нажимал те же кнопки, использовал тот же софт. Запоминал для себя правила — что можно, а что нельзя
- Чуть позже начал экспериментировать: использовать другие синтезаторы, другие тональности, ударные.
Уже можно было писать треки — далеко не шедевры, очень типичные. Но уже что-то.- На этом же этапе полезно было смотреть, к чему приводит нарушение правил, слышать как каждая “крутилка” синтезатора ведет себя на экстремальных значениях.
- Сам создаю треки с нуля.
- Если услышал про какую-то новую технику, новые стили музыки, то возвращаюсь к шагу 1.
Shu-ha-ri контрастирует с обучением, когда сначала загружаешься теорией и только потом приступаешь к практике. С последним я обнаруживал себя в ситуации, когда я боялся приступить к чему-то новому и прокрастинировал, вычитывая теорию.
Главные выводы:
- Если только вливаешься в деятельность, то копируй поведение большинства или ближайших соратников. Главное — начать. Потом изменишь алгоритм работы под себя.
- Минимизируй стоимость экспериментов: скорее всего, первые шаги в новом направлении будут ошибочными. Поэтому выгоднее начать что-то делать с минимальными вложениями.
Фазы “бездоказательно принимаешь правило” — “пытаешься опровергнуть правило” — “следуешь правилам с пониманием нюансов” похоже на развитие по спирали.
Осознание контекста
Паттерн развития убеждений про X (подставь что угодно) обычно такой:
- “X — круто”
- “X — отстой”
- “X — круто в таких случаях …”
На первом этапе что-то принимается как есть, без подтверждений. Может быть, даже как “серебряная пуля” — решение многих проблем.
На втором — появляются сомнения и попытки понять что именно не так.
На последнем шаге — осознание, что предыдущее убеждение верно, но не во всех случаях. Приходит осознание того, как контекст/окружение влияет на уместность применения правил.
Например:
Когда я начинал работать программистом, то везде был модным скрам. И я был убежден, что “скрам — это круто”. Какое-то время мы работали по подобию скрама. Я принимал это как должное.
Набирая опыт, я начал видеть проблемы — планирование и спринты скорее мешали для бэклога, в котором были в основном срочные патчи и инциденты с продакшена. Планирование спринтов стало выглядеть как “карго культ” — мы просто это делали потому, что привыкли. Появилось ощущение, что “скрам отстой”. Хотелось спорить со спикерами, превозносившими скрам.
После перехода на канбан, уменьшения количества незапланированных патчей и инцидентов, пришло осознание, что “скрам — круто”, но для определенных типов бэклогов с жесткими дедлайнами и редко меняющимися приоритетами.
Этап осознания контекста в разных интерпретациях модели братьев Дрейфус часто указывается как одно из условий для роста от новичка до компетентного в чем-либо.
Главные выводы для меня больше связаны с командой:
- Культура команда должна принимать ситуации, когда люди меняют мнение о чем-то. Это стимулирует обучение.
- Иногда возврат к старым убеждениям — это не шаг назад, а естественный процесс развития.
Вообще, я уже смирился, что метания от одной крайности к другой — важная часть обучения. Особенно это я прочувствовал в менеджменте.
Определение границ — что такое “хорошо”, а что такое “плохо”
У Вастрика есть крутая статья про крайности — “Оставайся посередине”. Суть: крайности плохо — “Всеми силами держи дистанцию между крайностями”.
Я согласен, что постоянно находится в крайностях — плохо, но для набора опыта очень важно пробовать разные крайности.
Например:
- ошибиться и пару раз сделать работу плохо: как минимум, чтобы понять как исправлять последствия
- иногда делать работу очень хорошо — чтобы научиться эмоционально справляться со свалившимся успехом, понять критерии успеха и цену качественной работы (как в слогане студии Лебедева: “ох*енно” = долго + дорого).
Моё мастерство во многом, зависит от того, в какие крайности я заходил в данном виде деятельности.
Например, если говорить про найм новых членов команды, то опытный руководитель проходил через обе крайности:
- когда наняли “не того” и приходилось увольнять, исправлять последствия работы такого неподходящего специалиста
- когда получалось нанимать людей, превосходящих ожидания. В этом случае приходят новые испытания — научиться удерживать такого спеца в компании/команде, правильно оценивать работу людей, у которых результаты похуже.
Крайности не всегда видны сразу. Занимаясь чем-то новым я, как в компьютерных стратегиях, постепенно открываю всю доступную мне область. И каждый сдвиг по карте — новая ситуация в которой я еще не был.
В примере из предыдущей части про “скрам — отстой” сразу понятно, что есть другая крайность с безоговорочными поклонниками фреймворка.
Тяжелее осознать крайности в своих установках, с которыми уже привык жить.
Когда я работал над первым проектом в роли проектного менеджера, то в первый месяц работы сразу же напоролся на критический баг в продакшене. Куча данных клиента было испорчено.
Я видел последствия и было страшно: непонятно — ущерб большой или маленький,. Было непонятно как отреагирует клиент, что ожидается от меня. И должен ли я следовать ожиданиям.
Пока я решал эту проблему мои убеждения как маятник качались от одной крайности к другой:
- “я несу полную ответственность за все проблемы с проектом” —> фаза отрицания: “баг пропустили в прод до меня, моя совесть чиста” —> “я несу ответственность за проблемы с проектом. Но нести ответственность значит … <список того, что включает ответственность. там нет пункта “очень сильно переживать”>”
- “клиент всегда прав” —> “клиент много в чем неправ” —> “клиент прав. Но мы не должны делать всё что он скажет”
Спокойно преодолевать проблемы на проектах, работать с “трудными клиентами” моя команда и я научились благодаря тому, что мы прошлись по крайностям.
Осознать прелесть “крайностей” помогла книга “The Black Swan” Таллеба. Читая книгу, я осознал, что главный опыт, который получил я и моя команда — благодаря куче жоп, которые случались на проектах. Пережив проблему, мы учимся предотвращать еще большие проблемы.
Это справедливо не только для явно плохих ситуаций. Я был свидетелем и участником того, как внезапно хорошие ситуации катились в катастрофу:
- ПМ привыкает работать со сложными в общении клиентами.
Внезапно появляется клиент, с которым легко общаться, он без проблем отодвигает сроки доставок, дает время на стабилизацию.
В итоге: у проекта перерасход бюджета. - Проектная команда несколько лет работает в условиях недостатка людей — фокус только на супер—критичных задачах, часто приходится переключаться между задачами для тушения пожаров.
Реорганизация компании приводит к тому, что на каких-то проектах людей больше, чем нужно для “выживания”.
В итоге: менеджеры не знают что делать с этим “излишком” — стараются как можно скорее куда-то перевести людей, взять новые проекты чтобы вернуться в состояние “выживания”. Разработчикам морально тяжело работать с техдолгом и задачами, которые не нужно “прямщас” доставлять в прод.
Главные выводы:
- Крайности — необходимы для обучения. Они дают уникальный запоминающийся опыт.
- Менеджер должен давать команде проживать критичные проблемы в “тепличных” условиях. Лучше дать обосраться на маленьком проекте, чем не предусмотреть что-то и разгребать последствия на большом.