Создавать системы, которые работают без твоего участия Внезапно осознал, что это универсальный навык/образ мышления. 🌱 Когда ты разработчик Проще всего пояснить мысль про «систему, работающую без тебя» на примерах, когда это свойство нарушается. Пример 1: разработчик пишет ошибку в лог и возвращает код ответа 200 OK. - Хорошо, а как мы узнаем, что у нас что-то работает некорректно? - Посмотрим в логи! Такой ответ - «звоночек». Просмотр логов подразумевает, что это кто-то должен делать. Сразу возникают дополнительные вопросы: кто будет смотреть в логи, как часто, как убедиться, что он не забыл и т.д. То есть вокруг созданного кода возникает необходимость выстраивать какие-то процессы сопровождения. Да, они всё равно нужны. Но их объёмом и требуемой квалификацией сопровождающих можно управлять. Иначе получается, что бизнес, заказывая фичу, вместо экономии денег получает дополнительные расходы. Пример 2: разработчик делает фичу, которая зависит от конфигурационных данных в БД. Способ внесения этих данных не делает. Если на проекте всё в порядке с информационной безопасностью и регулированием доступа к средам, то такая фича просто не заработает в проде. Нужным данным-то взяться неоткуда. Но в маленьких компаниях могут быть незрелые политики ИБ, допускающие подобное. Как следствие, и без того ограниченный ресурс разработки тратится на какие-то ручные манипуляции с БД. И этот эффект копится с каждой подобной фичей. В обоих примерах созданные фичи не будут полноценно работать без отвлечения инженеров. Написать код один раз и «забыть» (переключить разработчиков на другие задачи) не получится. А если вы (в хорошем смысле) ленивый разработчик, то «забыть» должно быть вашей целью. 🪴 Когда ты тимлид На уровне тимлида к описанному добавляется команда. Когда встречаю в резюме пункты вроде «управляю командой из X человек: распределяю задачи...», то для меня это красный флаг. Хочется включить токсика (спалился, гы 😬) и спросить: разработчики в команде – это пятилетки, которые без вас не разберутся, как вместе сделать общее дело? Или вам нужно как-то оправдать свою необходимость перед бизнесом? Спасибо Стратоплану, в котором Слава Панкратов рассказывал нам про «мясных роутеров»! А если серьёзно, то для меня это просто показатель незрелости команды и её лидера. Конструкция, в которой, чтобы работа была сделана, нужно вручную всем управлять – неустойчивая. Как только руководитель пойдёт в отпуск, заболеет или его собьёт автобус, то работа встанет. Если вообще сможет вырваться 😁 Поэтому задача тимлида, на мой взгляд, это построить такую команду, которой тимлид не нужен в краткосрочной перспективе. Операционка должна быть так налажена, чтобы всё работало как часы – само по себе и чётко. И тогда появляется время на другие активности: стратегическое развитие команды и подходов, помощь тиммейтам в развитии, возможность самому поработать руками. Да и человеческую эмпатию и эмоциональный интеллект проще проявлять, когда от тебя не ждут 10 ответов сегодня, иначе фичу не сделают, релиз не выкатят и всех уволят. 🌳 Когда ты руководитель разработки На уровне выше индивидуальные исполнители превращаются в команды. Процессы взаимодействия и связи становятся сложнее, ответственность и сложность решений – выше. Появляется над-команда тимлидов. Становится больше взаимодействия с другими отделами. В общем, всего больше и всё сложнее… Но, как мне кажется, ключевая задача остаётся прежней: создать такую систему, чтобы команды выполняли цели бизнеса без твоего микроменеджмента. Другими словами, цель – создать самодостаточную систему, а не систему, которой нужно «управлять». Что это за система – техническая или социальная – уже деталь реализации… Хотя, возможно, я слишком упрощаю и неуместно притягиваю всё к одной простой абстракции 😁 А вы как думаете, есть в этом здравое зерно? #софты