Распожаризация - нужно понять, чего можно не делать / не читать / не изучать без значительной потери в качестве. Но для начала, как обычно, нужно понять, каковы цели и в каком контексте оценивать это самое качество.
Ограничусь для начала своей профессиональной жизнью. Если кратко, то ситуация у меня сейчас такова: формально я тимлид/бэкенд-разработчик в продуктовой команде, перед которой стоит ну очень амбициозная и по моему мнению недостижимая с заданными параметрами задача.
Почему тимлид я всего лишь формально? Потому что:
- группа бэкенд-разработки разнородна по технологиям (40% java; 40% js/ts; 20% devops)
- группа занята на двух изолированных друг от друга проектах
- контекста и требований к результату работы группы в явном виде нет
- описания ролевых практик тимлида в явном виде нет
- ожидания от работы тимлида слабо связаны с результатами работы группы бэкенд-разработки
Мне сейчас совершенно непонятно, что тут “лидить” и где тут “тим”. Ну и в свете моих размышлений про “как” и “что”, если уж придется с этим разбираться, то начинать нужно будет с контекста и внешних требований / ролевых интересов стейкхолдеров.
Плюс к этому у меня есть некоторый пул рабочих задач, требующих чего-то спроектировать головой и закодить руками. Но с этим как раз все более-менее понятно - бери и делай, а если непонятно, что делать, то нужно собираться с заинтересованными людьми и обсуждать голосом. Это часть про собственно бэкенд-разработку.
Плюс к этому все сильнее ощущается необходимость отстаивать границы фича-команды, а именно:
- подвергать сомнению навязываемые “извне” фича-команды решения, как технические, так и организационные;
- подбирать и публиковать аргументацию для принятых “внутри” фича-команды решений;
- повышать прозрачность собственной работы для того, чтобы остальные могли ориентироваться на ее результаты при принятии своих решений.
Первые два пункта здесь - это реализация “джунглей идей”, в которых выжить должна самая сильная идея, это приложение научного подхода к менеджменту и инженерии. Результат этой деятельности по большому счету превращается в архитектуру разрабатываемого ПО и в архитектуру инженерной команды.
Итак, имеем три направления работы. А что с целями? Их по большому счету две: выпустить в срок текущий продукт (это краткосрочная и “внешняя” по отношению ко мне цель) и сформировать автономную команду, способную выпускать любые продукты (это среднесрочная и “моя” цель).
Сравнив все три направления по принципу “что случится, если я буду заниматься только этим, а на все остальное забью”, пришел к выводу, что важнее всего третья часть, архитектурная. Формальное “лидерство” пока никому не нужно, а в условиях разнородности команды и проектов еще и неэффективно. Ну, то есть, не нужно никому “снаружи”, для моей цели по формированию команды это деятельность все-таки нужная. Написание кода можно делегировать - у меня есть напарник, с которым мы очень сходимся во взглядах на “правильный код”, так что тут просадки в качестве не будет точно. К тому же код работает только на первую краткосрочную “чужую” цель. Остается архитектура и “выращивание” сильных идей, как технических, так и организационных - это направление работает на обе цели разом, поэтому выглядит важнее остальных в данный момент.
Что ж, дальше буду думать именно в эту сторону.