Ностальгический пост о прошлом и мысли о будущем.

10 лет назад я, будучи обычным разработчиком, пришел в "Островок" делать backend для B2B-направления. Тогда еще особо никто не умел в скрам, а все просто писали код, роль тимлида только зарождалась, а в продукте шли споры о том, как правильно называть владельца продукта: Product Owner или Product Manager. Это были дикие времена, и мы выживали как могли.

Но было классно! Можно было просто подойти к кому угодно в офисе и что-то у него спросить. Можно было после работы пойти с командой в бар, а все встречи проходили в переговорках или рядом с чьим-то рабочим столом, и не нужно было беспокоиться о камере, качестве микрофона, шаринге экрана и актуализации своего календаря. Сейчас, после ковида и геополитических изменений, это звучит как какой-то "каменный век", но это был чертовски приятный "век". Никто не заботился о метриках эффективности, так как их никто не умел считать. Никто не думал об импортозамещении, так как не было повода и смысла об этом думать. Никто не спорил, какой корпоративный мессенджер лучше, потому что ни Slack, ни MS Teams еще не вышли в свет. Никто не ломал голову о выборе облачного провайдера, так как из нормальных был только AWS.

Что будет еще через 10 лет? Все перейдут с Jira на какой-нибудь TeamStorm? gitverse заменит GitHub? А backend будем писать на Rust? Или же профессия разработчика вообще умрет и останутся операторы AI? Поглядим!

Кстати, частично эту тему затронули на последнем TechLeadConf в рамках доклада Как техлиду выжать максимум из ChatGPT.

Пост размышления о лидерстве.

Лидерство — это когда где-то внутри есть большое НАДО и яркое ХОЧУ.

НАДО — это тактика. НАДО говорит тебе, что ещё нужно сделать вот это, это и это, чтобы тактически решить проблему, исправить ситуацию, получить краткосрочную победу.
ХОЧУ — это стратегия. ХОЧУ смотрит гораздо дальше и шире, чем НАДО. ХОЧУ знает, когда что-то нужно захотеть, чтобы либо быстро сконвертировать ХОЧУ в НАДО, либо наоборот, погасить одно из текущих НАДО ради какого-то другого НАДО.

Пример.
Я знаю, что мне сейчас НАДО инвестировать своё время в подготовку к высокому сезону. Моё НАДО говорит мне: «Антон, иди разберись, как обстоят дела в командах по подготовке к сезону, проверь, что все всё сделали. Проконтролируй! Проверь! Помикроменеджь!»
При этом есть ХОЧУ. ХОЧУ хочет, чтобы я выстраивал культуру, процессы и роли в командах, чтобы достичь такого уровня зрелости и осознанности, при котором о подготовке к сезону не нужно было бы говорить, чтобы это было базовой гигиеной.

Лидер умеет отличать ХОЧУ от НАДО и НАДО от ХОЧУ. Лидер умеет приоритизировать два и более НАДО между собой. Лидер умеет прогнозировать, когда каким ХОЧУ пора начинать заниматься. Лидер готов инвестировать своё личное время в реализацию своих ХОЧУ.

P.S.: данный пост написан под влиянием яркого ХОЧУ =)

Возвращаюсь к истокам данного канала.

вот же пи....

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

Не потому что мне было лень это изучать, я просто искренне не понимал, зачем нужны все эти rebase, revoke и прочие непонятные команды, когда фактически все, что мне нужно, это:
- git checkout -b
- git push
- git pull
- влить изменения (merge в интерфейсе gitlab)

Крайне-крайне редко я мог воспользоваться cherry-pick и diff/apply.

Всё. Я никогда не понимал, зачем нужны dev-ветки, если всё, что мне нужно, — это отвести ветку от master, а потом вмержить её в master.

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

На последнем TLConf был, на мой взгляд, эталонный доклад про TBD. Ничего аналогичного на просторах Рунета в видеоформате нет. Автору респект. Максимально рекомендую всем!

P.S.: этот доклад получил самую высокую оценку среди докладов ветки TechLead

Пост про использование консоли.

Я четко помню тот момент, когда я, еще будучи в вузе, перешел с Windows на Ubuntu. Момент я помню, но что послужило причиной этому - уже нет. То ли потому, что мне надо было что-то запускать из-под Unix, то ли просто потому, что все окружение вокруг работало под Unix-системами. Не суть. Суть в том, что я четко помню тот восторг, который я ощутил, когда смог пользоваться нормальной консолью. А tiling window manager типа awesome, ммм, сказка. Конечно, уже потом я перешел на Mac, так как консоль - это, конечно, хорошо, но вот собирать драйвера и разбираться с прочими приколами дистрибутивов Linux желания не было.

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

Раньше, при собеседовании разработчиков, я приятно удивлялся, что оставались еще те, кто умеет работать с vim. Видимо, через какое-то время можно будет удивляться тем, кто все еще умеет в grep / awk / cat в командной строке.

Кстати. Как выйти из vim? =)

Про визуализацию графиков отпусков.

За все время работы в разных компаниях я нигде не видел удобного и наглядного инструмента для визуализации отпусков и dayoff'ов сотрудников команды/отдела/департамента. Никакие внутренние самописные интранеты, ни СБИС, ни VKDoc не могут предоставить мне простейшую возможность увидеть график отпусков разных сотрудников в виде календаря с разбивкой по дням, неделям и месяцам, чтобы найти какие-либо пересечения.

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

Вроде бы простейшая задача, но никакой инструмент на рынке сейчас такую проблему не решает. Или я такого пока не видел.

Пост про важность проведения демо.

Когда я был тимлидом B2B-направления в Ostrovok, я с нетерпением ждал каждого демо. Почему? Потому что в какой-то момент я понял, что это абсолютно законный и честный способ похвалить самого себя и свою команду за проделанную работу, а также показать другим тимлидам, что твоя команда самая классная. Как? Почему? Зачем? Да просто потому, что если ты зрелый тимлид, то ты можешь вывести свою команду в топ-перформеры и на фоне остальных команд в большой компании выглядеть гораздо успешнее, показывая реальные результаты на цифрах и запусках каждые две недели.

Демо рождает здоровую и честную конкуренцию между командами за похвалу и общее признание как со стороны бизнеса/продукта, так и среди инженеров IT. Потому что если ты, как тимлид, выступаешь на демо раз в квартал, а в соседней команде условный Петя выступает каждый раз и показывает реальные результаты, то если ты нормальный, то должен задаться вопросом: почему у Пети все так классно, а у меня нет? Может, я что-то делаю не так? Или у меня в команде что-то не так? Хочу, чтобы у меня было как у Пети в команде. Все аргументы в духе «все команды разные и у всех есть свои особенности» идут лесом, потому что "признание специфичности смерти подобно". Все мы особенные, а когда все особенные, то никто не особенный.

Понятно, что само демо надо уметь проводить, чтобы оно было в радость, а не в тягость, но это тема отдельного поста.

P.S.: Еще я обожал в каждое демо прятать "пасхалку", нахождение которой всегда было интересным и веселым челленджем для слушателей.

Трудности перевода.

Есть достаточно старый, но не менее смешной стикер-пак CTO in Rage. Я никогда себе не позволял использовать оттуда стикеры, хотя очень хотелось. В какой-то момент я поймал себя на мысли, что фразы оттуда можно заменить вполне грамотной русской речью. Привожу свою интерпретацию перевода. Мат есть в оригинале, простите.

- Бля, реши вопрос - Слушай, я сейчас занят, разберись, пожалуйста, сам.
- Хули вы тут мусолите в этом чате - Диалог идет не в том направлении, вернитесь пожалуйста к сути.
- Прием блять - Привет, получилось что-то выяснить?
- Блять, как же вы меня заебали - Ох, я что-то подустал.
- У меня сейчас 0 доверия к тех команде - Я сомневаюсь, что мы сможем решить эту проблему самостоятельно.
- Штрафуйте - Кто-то может остаться без бонусов.
- Кто проебал? - Кто упустил?
- Вы реально не отбиваете - Я вижу, что у вас нет понимания.
- Вся разработка и куа у нас хуйня - Я считаю, что нам нужно больше инвестировать в зрелость наших инженеров.
- Какого хуя не откатили релиз? - Можно же было просто откатить, забыли?
- Ты со мной поспорить решил? - Давай обсудим, я готов привести свои аргументы.
- Меня это ебланство заебало - Ой, кажется, у нас есть общая проблема с ответственностью за свою работу.
- Я щас нахуй опять вас всех оштрафую - Видимо мы снова останемся без бонусов.
- Не ебите мне мозги - Разберитесь, пожалуйста. сами с проблемой.
- Та мне похуй - Я не в контексте.
- Нахуй ты мне это пишешь? - Ты хочешь чтобы я тебе чем-то помог?
- Нихуя не игрушки - Внимательнее, пожалуйста.
- В пизду такой мониторинг вообще - У меня есть вопросы к качеству нашего мониторинга.
- Позор - Я вижу тут точки роста.

Про выбор между двумя плохими вариантами.

Всегда когда передо мной стоит выбор между двумя плохими вариантами я вспоминаю эту уже классическую серию Южного парка.

«Клизма и дерьмо» (англ. Douche and Turd) — эпизод 808 (№ 119) сериала «Южный Парк», его премьера состоялась 27 октября 2004 года. Эпизод вышел накануне выборов Президента США и является их сатирическим отображением — выборы президента сравниваются с «выбором талисмана школы, между гигантской клизмой (Джон Керри) и сэндвичем с дерьмом (Джордж Буш-младший)»

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

Серию можно посмотреть здесь.

Команда разработки как болид ралли.

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

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

Пост про размер команды.

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

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

Я и раньше считал, что большие команды — это скорее плохо, чем хорошо, но я отталкивался скорее от Кошелька Миллера. А теперь вот узнал, что, оказывается, этому есть вполне себе научное объяснение за плечами которое стоят различные социальные эксперименты.

Размер команды зависит от числа инженеров, выполняющих конкретную часть работы. Если речь идет о кросс-функциональной команде, то минимальный состав включает: TeamLead, Backend, iOS, Android, web и QA — всего 6 человек, что оптимально для управления. При этом если мы хотим сократить риски (автобусное число >= 2), то команда уже может состоять из 11 человек, что превышает "Число Миллера". Можно попробовать использовать общий стек технологий, тогда команда наверное станет меньше, а "автобусное число" может достигнуть 3. Например, всё на JS (React/Node.js/React Native), или Kotlin Multiplatform на мобилках, или вообще весь фронтенд на Flutter. Однако, кажется, что так никто не делает, и, видимо, на это есть свои причины.

Мы, ITшники, привыкли к высокому уровню удобства продуктов и сервисов, которые мы сами и наши коллеги разрабатывают.
- Хочешь заказать еду? Скачай приложение и нажми кнопку!
- Нужно записаться к врачу? Скачай приложение и нажми кнопку!
- Надо купить или забронировать отель или билет? Скачай приложение и нажми кнопку!
- Надо продать авто? Скачай приложение и нажми кнопку! Да, сейчас так можно!
Авторизация в один клик! Оформи заказ сейчас, плати потом! Мы делаем всё, чтобы наши клиенты были довольны и ничто не мешало им быстро пройти всю воронку — от захода на сайт/приложение до финального действия.

А теперь я расскажу вам о моей (суровой и современной реальности) покупки автомобиля.
- Февраль–март: исследование, как можно купить автомобиль, не переплачивая в 1.5 или 2 раза.
- Апрель–май: осознание необходимости поиска автомобиля на аукционах Южной Кореи и выбор модели и марки, которые мне подходят.
- Июнь–июль: поиск провайдера, который сможет купить автомобиль в Южной Корее и доставить его в РФ.
- Июль: поиск конкретного автомобиля, уточнение его состояния, переписка с подборщиком, оформление договора и передача денег.
- Август: ожидание ... и наблюдение за перемещением автомобиля в контейнере из Владивостока в Москву.
- Сентябрь: ожидание прибытия автомобиля в Москву, перегон в Беларусь на растаможку и обратно в Москву, после чего — детейлинг и окончательные процедуры оформления и получения номеров.

Для меня это всё кажется полной дикостью, тк даже чисто ITшный опыт поиска авто на южнокорейском сайте был крайне ужасным. С нашим auto.ru не сравнится (не реклама). Я сам бы это все не осилил, мне помогал отец, тк, видимо, его поколение к такому привыкло, а наше (мое) ещё (уже) нет.

К чему я это всё? К сожалению, не везде можно просто скачать приложение и нажать кнопку!

Про проклятие знания.

Проклятие знания (англ. curse of knowledge) — одно из когнитивных искажений в мышлении человека (см. их список); термин, предложенный психологом Робином Хогартом для обозначения психологического феномена, заключающегося в том, что более информированным людям чрезвычайно сложно рассматривать какую-либо проблему с точки зрения менее информированных людей[1].

Где-то последний месяц я жутко расстраивался из-за того, что приходится объяснять людям простейшие и, по моему мнению, понятные вещи. С одной стороны, это, наверное, часть моей работы, с другой стороны, возникает ряд вопросов: как всё это работало и существовало раньше. Покаравшись в инете открыл для себя бложик Тимлид Очевидность.

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

Мысль ясна, но как сделать так, чтобы и они также обладали этим "проклятием", чтобы мы все "страдали" вместе? Ответ прост — обучать и повторять. Подход называется "Правило трех повторений". Согласно ему, чтобы запомнить информацию, её нужно повторить трижды в разных контекстах или формах. Повторение необходимо, потому что забывать — это нормально. Помню, еще в вузе или школе мне говорили, что чтобы что-то запомнить, это нужно услышать, написать и прочитать. Видимо, это оно и есть.

Учить — лечить — мочить

Татуировка «УЧИТЬ — ЛЕЧИТЬ — МОЧИТЬ» должна занимать достойное место на вашем туловище. Действуйте всегда исключительно в таком порядке, и все у вас в вашей менеджерской жизни будет прекрасно!

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

Внимательный читатель поймёт, что последовательность моих действий с данным сотрудником отличается от заголовка. Учить всегда-всегда-всегда проще, чем лечить. Если "лечение" не помогает, то можно пробовать "мочить". Начать можно с низкой оценки на ревью, которая будет сигналом для изменений.

Про запас прочности.

Хорошо известна история, когда Генри Форд внезапно отправил руководителей всех отделов своих заводов в двухнедельный круиз по Карибам. По возвращении половину он уволил, а другую половину повысил, те руководители, чьи отделы в их отсутствии не потеряли эффективности, заслужили награду, ведь они, по мысли Форда, сумели грамотно организовать работу своих сотрудников. Те, чьи отделы начали «проседать», закономерно показали себя плохими управленцами.

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

История.
В декабре 2023 года один из моих тимлидов сообщил, что покидает компанию через две недели. Ничего необычного, подумал я, бывает. Моё беспокойство было связано не с его уходом, а с тем, что мне придётся искать нового тимлида, и какое-то время команда будет без руководителя. Через месяц, уже в январе 2024 года, я пришёл в команду узнать, как дела, и всё было хорошо: бэклог на квартал сформирован, команда понимала, что, когда и зачем ей нужно делать, осознавала свои обязательства перед всеми стейкхолдерами. Команда самостоятельно ставила себе цели на спринт и вела все скрам-процессы. Спустя ещё месяц ситуация радикально не изменилась, команда продолжала самостоятельно функционировать. Только спустя третий месяц начали проявляться первые проблемы, видимо, запас прочности, заложенный ушедшим руководителем, начал иссякать. В разговоре с членами команды стало ясно, что ушедший тимлид изначально закладывал принципы самостоятельности и ответственности. В команде не было такого: "я тут делаю только что-то одно, а что делает мой сосед, меня не волнует." В каждом сотруднике чувствовались проактивность, не было безразличия, а было общее желание показывать результаты.

Мудрость.
Если вы уходите в отпуск, а ваша команда успела потерять в эффективности за это короткий срок, то "хьюстон, у нас проблемы".

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

Субъективное мнение про ИПР.

Существует мнение, что составлением ИПР и развитием сотрудников должен заниматься руководитель. Я считаю иначе. Есть только один человек, который заинтересован в вашем развитии, — это вы сами. Да, наверное, лет 10-15 назад это было актуально. Сейчас, когда практически любая информация находится на расстоянии вытянутой руки от клавиатуры, когда количество курсов, конференций, вебинаров, подкастов и лекций больше, чем может вместить сознание любого инженера, составление ИПР звучит как расписка в собственной лени. Руководитель может скорректировать ваш план развития, упорядочить его, сказать, что важно сейчас, а что потом, но не составлять его за вас.

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

Мне никто никогда не составлял план развития, как и я никогда не делал этого для своих сотрудников. Хорошо поставленная цель и соответствующая ей задача — лучший ИПР.

Про самый лучший интранет.

Я работал в разных конфигурациях корпоративных инструментов: личный мессенджер, далее МР, и самописный интранет; личный МР и энтерпрайзный коробочный интранет; корпоративный МР и самописный интранет; корпоративный МР и энтерпрайзный коробочный интранет. Так вот, интранет не нужен, никакой не нужен. Неважно, самописный он и поддерживается инженерами самой компании или это какая-то платная коробка. Всё, что представляет интранет, должно быть в МР, в корпоративном МР. Оргструктура, постановка целей, новости компании, календарь встреч, организация процесса ревью, организация процесса найма, NPS опросы, звонки, календарь дней рождений, создание заявок на отпуска, инцидент менеджмент, работа с codereview — всё это и многое другое должно быть в корпоративном МР или должно быть интегрировано в него, чтобы он был единым интерфейсом, через который любой сотрудник компании мог реагировать на изменения в других инструментах или создавать их через корпоративный МР.

Я не могу сказать, что где-то у меня был 100% опыт, что я описал выше, но на деле нет никаких технических проблем, чтобы это реализовать. API-интеграции и боты — наше всё. Ближе всего к этому, конечно же, приблизился Slack и впоследствии Mattermost.

(на скрине пример slack бота Mortimer для работы с инцидентами)

Про самоиронию.

Если у человека есть самоирония, он неуязвим!

В какой-то момент я понял, что самоирония — это один из моих инструментов руководителя. Для меня самоирония — это способ защитить себя от потенциальной критики, ведь когда ты сам публично критикуешь себя, любая внешняя критика не будет нести никакой смысловой нагрузки и будет звучать смешно. Я часто самоиронизирую над своими инженерными навыками, так как по разумным причинам не удается поддерживать их на уровне senior-инженера, а это важно при общении с сильными инженерами, чтобы они чувствовали себя комфортно при общении с СТО. Ведь звания/лычки/тайтлы никто не любит, а фраза "я не настоящий сварщик, так как уже 3 года не трогал код" помогает разрядить обстановку. Или, когда ты зашел на встречу, и все с умным видом что-то обсуждают, а ты ничего не понимаешь, фраза "Ребят, видимо, я немного отстаю, не совсем понимаю, почему..." помогает создать более открытую и непринужденную атмосферу.

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

Хорошим примером самоиронии Илона Маска является вот этот кусок из эпизода сериала "Теория большого взрыва". Вообще Маск — мастер самоиронии, иронии и сарказма. Ролики о том, как он увольнял из Twitter это отдельная категория интересного контента.

Пост о мелочи, которая может всё разрушить.

Вот бывает же такое: ты очень долго выбираешь ресторан, куда можно сходить с супругой вдвоём. Изучаешь карты, чтобы найти удобное по местоположению место, смотришь заведения с высокой оценкой и с меткой "хорошее место" от Яндекса, просматриваешь отзывы и фотографии внутри и снаружи. Думаешь о логистике: как лучше добраться до заведения, минуя потенциальные пробки, и как вернуться обратно.

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

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

И вот так же в IT. Можно потратить уйму времени на исследование рынка, уникальный дизайн, общий перфоманс приложения/сайта, вложить кучу денег в маркетинг и продвижение, а в итоге всё запороть, забыв при релизе сменить адрес с тестового на продовый в финальной сборке.

Прошёл примерно год, как я воскресил этот канал и стараюсь регулярно сюда что-то писать.

Расскажу, почему вообще я его завёл. Помню, что было два триггера. Первый — это ТГ-канал Бывшая и смешная история вокруг этого канала. Рекомендую посмотреть, хороший стендап получился. Второй — это моя команда в ostrovok.ru. Когда я там работал, меня местами сильно бомбило по разным рабочим вопросам, и ребята порекомендовали завести канал, чтобы я писал туда, а не в рабочий мессенджер (Slack). Да, это были времена, когда Slack, JetBrains, Miro, MS и прочие ещё не знали о "культуре" отмен, а Линус Торвальдс вызывал уважение.

Сейчас этот канал — это саморефлексия над собой, над проделанной работой, над какими-то рабочими ситуациями и проблемами, которыми хочется поделиться. Судя по статистике и аналитике, которую предоставляет ТГ из коробки, большинство подписчиков — это мои бывшие или текущие коллеги. Спасибо, что читаете, ставите реакции и оставляете комментарии. Не всегда есть возможность встретиться с вами, с кем раньше вместе работал и засиживался допоздна в офисе, но знаю, что большинство из вас здесь есть ❤️❤️❤️

(продолжение)

Лично для себя я делю структуры на два типа: по центрам компетенций (далее ЦК) и по командам. По ЦК это значит, что, например, существует один руководитель всего backend, и весь найм backend-инженеров идет под его руководство, либо непосредственно, либо через какой-либо дополнительный слой, если речь идет о десятках или сотнях backend-инженеров. Командная структура подразумевает, что есть руководитель команды (тимлид — TL), и инженеры, которые входят в команду, подчиняются административно TL команды. TL команды в этом случае становится своего рода мини-СТО.

Понятно, что это холивар, в обоих подходах есть свои плюсы и минусы, и то и другое можно научиться как-то готовить, но я всей душой и сердцем за командную структуру. По одной причине: у любого сотрудника должен быть один и только один руководитель, и в командной структуре это именно так. В структуре ЦК у рядового сотрудника оказывается как минимум два руководителя: административный — в лице руководителя ЦК или какого-то руководителя внутри ЦК, и функциональный — в лице TL команды, в которой данный сотрудник сейчас работает. Двойственность всегда приведет к лишним конфликтам, дополнительной коммуникации, дополнительным проблемам и согласованиям, которых не должно быть, плюс если у сотрудника два руководителя, то это значит, что функциональный может поменяться, а это значит, что мне как сотруднику нет особого смысла вкладываться на 100% сейчас в работу той команды, где я нахожусь, так как сегодня я тут, а завтра я в другой команде. Это ведет к отсутствию овнершипа и привязанности к целям команды.