4-недельный курс по Developer Experience, после которого команде больше не придётся переделывать задачи по 100 раз и тратить бесконечные часы на настройку проекта или выяснение, кто за что отвечает Кому поможет В первую очередь — тимлидам и СТО. На курсе много говорим про менеджмент: настройку и изменение процессов в сторону продуктивности, выбор и внедрение в работу полезных инструментов и отказ от бесполезных. Модуль 1 «Ищем корневую проблему и завоёвываем доверие программистов» Проблема: Команда, ответственная за запуск медиа, явно буксует. Даже простые баги чинятся по 2 недели, а сложные задачи не делаются вообще. Найм новых людей не помогает, а только ухудшает ситуацию. Вместо того, чтобы ускоряться, команда замедляется. Решение: Чтобы понять, что у команды не так, Сергей собирает все проблемы на доску и обнаруживает, что корень проблем — Developer Experience. Чтобы завоевать доверие бизнеса и команды, Сергей решает снять пару низко висящих фруктов — для начала чинит процесс фикса багов, которые сыпятся, но не резолвятся. В поисках затыка Сергей раскладывает сценарий по фреймворку JTBD и находит несколько неочевидных моментов. Решив эти моменты, команда начинает чинить половину зависших багов вовремя. «Инженерные процессы — CI\CD и онбординг» Проблема: Людей всё ещё не хватает, а новые онбордятся бесконечно долго. Инженерные процессы хромают. Пытались решить это базой знаний, но она быстро протухает. Решение: Сергей обнаруживает, что в команде плохо передаются знания: непонятно, куда и как писать код, как разворачивать проект и даже запускать тесты. CI\CD, который мог бы быть образцом разворачивания проекта, тоже не справляется. Варианта два. Первый: чинить базу знаний. Второй: сделать так, чтобы база знаний была не нужна, — то есть специфические для компании инструменты заменить на общепринятые, которые люди знают ещё до прихода в компанию. Сергей выбирает второй вариант, и время до первого коммита в main падает с бесконечности до двух недель, а специалисты освобождаются. Модуль 2 «Куда утекает внимание» Проблема: Простые задачи делаются быстро, но как только надо спокойно подумать — всё зависает. Разработчики заняты по горло и жутко устают. Нормально едут только задачи с менеджером, который стоит над душой у разработчика, пока код не окажется на проде. Решение: Гипотеза Сергея — команда тратит силы на муду (от японского — потери, не несущие ценности). Сергей чинит встречи, чтобы люди от них не уставали. Дейлики превращает из скучного ритуала в короткие полезные встречи на 15 минут. Учит команду справляться с конфликтами — чтобы не сраться по поводу архитектуры и линтеров. «Выстраиваем работу с заказчиком» Проблема: Бизнес не знает, чего хочет, зато знает, что разработка это уже просрала. Программисты могут делать только задачи, где не надо общаться с бизнесом. Если по задаче нужно посоветоваться — она будет делаться вечно. Решение: Сергей чинит взаимодействие с заказчиками — работу над задачами и планирование фичей. Точную оценку задач, которая никогда не попадает в реальность, заменяет на примерную оценку и Flex Scope. Перепридумывает синки с заказчиком, учит команду работать с рисками, чтобы лучше попадать в сроки и не подводить бизнес.
