Закоулки мозга

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

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

Почему тимлид я всего лишь формально? Потому что:

  1. группа бэкенд-разработки разнородна по технологиям (40% java; 40% js/ts; 20% devops)
  2. группа занята на двух изолированных друг от друга проектах
  3. контекста и требований к результату работы группы в явном виде нет
  4. описания ролевых практик тимлида в явном виде нет
  5. ожидания от работы тимлида слабо связаны с результатами работы группы бэкенд-разработки

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

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

Плюс к этому все сильнее ощущается необходимость отстаивать границы фича-команды, а именно:

  • подвергать сомнению навязываемые “извне” фича-команды решения, как технические, так и организационные;
  • подбирать и публиковать аргументацию для принятых “внутри” фича-команды решений;
  • повышать прозрачность собственной работы для того, чтобы остальные могли ориентироваться на ее результаты при принятии своих решений.

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

Итак, имеем три направления работы. А что с целями? Их по большому счету две: выпустить в срок текущий продукт (это краткосрочная и “внешняя” по отношению ко мне цель) и сформировать автономную команду, способную выпускать любые продукты (это среднесрочная и “моя” цель).

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

Что ж, дальше буду думать именно в эту сторону.