Все идет по скраму

- Так ревью может повысить этот уровень культуры! Вася читает чужой код и учится. Шаринг знаний! Да ничему Вася не учится, если не хочет этого делать. У него задачи горят, ему некогда внимательно изучать что ты там накодил. А когда ты в его МР-е пишешь свои глубокомысленные замечания он пребывает в лимбе: задача готова, но закрыть ее он не может пока не ответит тебе. Думаешь это хороший процесс обучения? Вместо условного Васи есть условный Петя. Его прет писать код и он уже давно излазил ваш репозиторий, украдкой подглядывая МР-ы, даже если его туда не звали. Наверняка ещё и девопсов успел доебать вопросами о том как релизы раскатываются и где продовые метрики смотреть. Того, кто хочет учиться, не нужно заставлять, а тот, кого нужно заставлять, не хочет учится. В итоге своей обязаловкой ты делаешь хуже не только Васе но и Пете. Слышал про обучение с положительным подкреплением в поведенческой психологии? Там простая мысль: если бить палкой за каждую ошибку, то учеба идет хуже, чем если поощрять правильное поведение. А теперь посмотри на ваше ревью. Если ты ошибся - тебе обязательно скажут и заставят переделать. Если ты все сделал хорошо, то никакой реакции не будет. Как скоро ты начнёшь избегать этого процесса? А вот если у тебя нет энтузиаста Пети, то все сложнее. Ты можешь попробовать своим примером воспитать его в команде. Покажи что учиться интересно и полезно. Притаскивай статьи, обсуждай новые знания с командой и рассказывай истории как тебе эти знания помогли. Глядишь и Петя появится и инженерная культура команды повысится. Это тяжёлый путь без гарантированного результата. Но мы же тут не ищем легких путей, только интересные?)

- Мишань, ты не шаришь. - говорят мне - Ревью нужно, что бы баги искать. Друг, скажи честно, ты запускаешь код МР-а, который смотришь? Хитрые тест кейсы гоняешь? Нет? Может у тебя в голове компилятор, которым ты валидируешь код с первого взгляда? Тоже нет? А как ты баги ищешь? Судя по тому, что я видел за 10 лет работы в ИТ, на ревью мы тратим минут 15. В лучшем случае смотрим на дизайн решения, а обычно просто линтим код. Т.е. условному Васе приходится бросать свою задачу и срочно грузить в голову контекст МР-а. Много он в таком режиме багов найдёт? Найдёт ли что-то сложное? Или опять навтыкает комментариев про "стайлгайд" и с чувством выполненного долга вернётся к своей задаче? И вообще... Если ты реально хочешь уменьшить количество багов, то можешь прислушаться к классике. Например, в Мифическом человекомесяце пишут, что для повышения качества продукта нужно повышать уровень инженерной культуры. А не вводить ещё один этап контроля качества.

А давай про обязаловку в команде поговорим? Я уже писал про то что дейли стали карго культом и средством успокоения тревожных менеджеров, но наивно было бы думать что эта болезнь не затронула другие ритуалы. Вот, например, кодревью очень популярно в опенсурсе. Там любой дурачок с улицы может наконтрибьютить в твой репозиторий и очень важно иметь фильтр совсем уж плохих решений. Но почему то такой подход стал стандартом в продуктовой разработке. Подумай как смешно звучит. При найме ты прокатился на карусели из этапов, в которой доказал ЧТО ТОЧНО НЕ ДУРАК. Затем прошёл испыталку, на которой все ещё раз убедились что ты СОВЕРШЕННО ТОЧНО ЗНАЕШЬ ЧТО ДЕЛАЕШЬ. Подписал договор, в котором ты несёшь ответственность за свои действия. И теперь, каждый раз на твой код смотрят так, как будто ты дурачок с улицы. Получается все эти этапы по приколу были?

А вот и гайд

Знали, что задачи можно оценивать не в SP, а в размерах футболок и даже собаках? Предлагаю новую систему оценки. Задача на девятку может быть только одна в спринте. Нулевка это чисто кнопку перекрасить.

Что, простите

2002 - CHIP №11

Хех, смотри что нашел в архивах! График капасити команды за год. В начале года сжигали около 40SP, в конце года +/- так же. Но есть нюанс - за год команда стала в два раза больше. Я допускаю, что "размер" SP мог измениться, но, как непосредственный наблюдатель, могу сказать что делать мы больше не стали. А вот время на ревью, общение и фикс багов стали тратить больше. Еще один повод задуматься перед тем как открывать найм.

Раз уж про амазон: свежий пост инженера, который только что уволился из оттуда. Прямо канонический крик души о работе в корпорации, да ещё и на русском.

Мне очень нравится идея, что отдел разработки не приносит ценность сам по себе, но увеличивает ценность других отделов. Например. Разработка интернет магазина увеличит ценность отдела продаж. Интернет магазин без продажников не принесет денег, а они без него вполне, хоть и меньше. CRM – поможет аккаунтам вести клиентов. Можно работать и в чатиках, но шанс проебаться на много выше. Есть совсем сложные цепочки: разработка собственного облака в компании усиливает девопсов, которые усиливают разработчиков, которые помогают другим отделам. Вот это мы сложности навалили, да? - Клево! - cкажешь ты - А в жизни эта философия как поможет? Тут простая мысль — сам по себе твой код никому не нужен. Нужен инструмент, который ты создаешь. И этим инструментом должен кто-то пользоваться. Иначе ты потратил время зря. По этому, перед тем как читать ТЗ, разберись зачем бизнесу твой IT-продукт? Кто будет им пользоваться? Кого и как ты будешь усилять? Во первых, это будет хорошей точкой входа в проект. ТЗ это ответ на вопрос "как усилить?". Пытаться понять задачу через ТЗ все-равно что пытаться угадать вопрос по его ответу. Довольно сложно. Во вторых, есть шанс, что читать ТЗ вообще не придется. Если у бизнеса нет четкого понимания зачем им этот IT-продукт, то и ТЗ с описанием того что хотят получить – чистая фантазия. Вписавшись в такую разработку, можно сделать все точно по ТЗ, а потом узнать, что пользы не стало больше. Ни ты, ни бизнес довольны не будут: тебя с командой сократят оптимизируют, а бизнес будет латать дыру в бюджете. Вот и получается грустный выбор: ты, либо, делаешь что сказали, получаешь получку и уповаешь на то что "им виднее"; либо начинаешь задавать вопросы, которые могут оставить тебя без получки уже на старте. Тут уже сам решай🤷‍♂️

Видимо, начало любого проекта это чистый хаос, в котором необходимо найти структуру и выйти из операционки. А пока. у меня нет времени ни на книги, ни на заметки. Хочется рассказать про то как можно писать не душные спеки, а истории. И про то как наша команда идет в разрез корпоративным стандартам, что бы вместо долгостроя получить быстрый фидбек от пользователей. Но увы, не сегодня. В общем, пока меня не уволили, stay tuned

Начинается моя любимая рубрика - найм

Меня можно поздравить с новой должностью. Был лидом фронтов а стал ✨руководителем разработки✨. Не люблю лычки, по этому радуюсь не должности, а возможности обкатать всю теорию, которую получил за последние пару лет. Видимо теперь тут будет еще больше про управление и ещё меньше про фронтенд, ведь пишу я больше для себя, чем для вас. Так что, либо подождите пока меня уволят и я вернусь к коду, либо давайте и дальше разбираться в том как быть хорошим менеджером. Желательно, не превращаясь в корпората. Наверное пара подумать над новым названием канала? А то ввожу людей в заблуждение, получается🤔

Expert Generalists Статья в блоге Мартина Фаулера про T-shaped специалистов. Точнее, все текущие термины (T-shape, П-shape, и другие) плохо подходят, поэтому в статье вводится термин Expert-Generalist, который означает, что человек одновременно является и экспертом (в противовес generalist) и использует свою экспертизу во многих областях (в противовес эксперту в одной области). В данном случае имеется в виду, что человек является экспертом в фундаментальных понятиях, которые позволяют ему быть успешным в областях, которые построены на этих понятиях. Классический пример из IT, это когда человек имеет опыт написания ПО на 3-4 языка программирования и ему после этого уже не так важно, на каком именно другом языке писать код, пока этот язык следует общим парадигмам (основан на том же фундаменте). Условно, человек, который писал на JS, PHP, JAVA, C++ с легкостью может войти в Go, Rust, Kotlin. Но, вероятно, столкнется с некоторыми проблемами при входе в Haskell. Но, скорее всего, сможет это сделать в короткие сроки. В профессиональных кругах не любят генералистов, т.к. у них нет глубоких знаний ни в одной из зон. В этом кроется ключевая разница между генералистами и экспертами-генералистами. Чистые генералисты знают все поверхностно. Эксперты-генералисты - знают фундаментальные принципы, знание которых позволяет им погружаться в смежные области В чем сила таких специалистов: Как правило, такие люди быстро обучаются - они изучат новый инструментарий, если он решает текущую задачу. Как следствие, они создадут более лучшее решение за счет подходящих инструментариев. Эксперты-генералисты должны иметь хорошие навыки коммуникации и совместной работы. Т.к. они не являются экспертами в областях, они должны уметь запрашивать помощь у коллег. Понимание основных принципов помогает им быстро погружаться в контексты специалистов Эксперты-генералисты игнорируют барьеру между отделами, командами, функциями. Это те люди, которые могут ускорить выполнение проекта т.к. для них не существует барьеров и, как следствие, они ускоряют коммуникацию, которая необходима для решения задачи Ключевые качества экспертов-генералистов: - Любознательность - Умение сотрудничать - Фокус на клиенте (бизнесовая направленность) - Ставка на фундаментальные знания - Широта знаний - Способность понимать позицию смежных доменов (например, понимать проблемы SRE или DevOps) Многие эксперты-генералисты вырастают в технических лидеров Встает закономерны вопрос: "где брать таких специалистов?". Текущий найм устроен так, что мы скорее наймем ультра-эксперта в технологии, чем наймем человека, который любознателен и умеет погружаться в новые домены. В статье предлагается подход из двух решений: - Перестать смотреть только на узкие хард-скилы. Вместо этого следует проверять человека на обучаемость, любознательность, создание условий для совместной работы - Проводить внутренние тренинги и воркшопы, цель которых - погрузить специалистов в смежные области. В Thoughtworks есть 3 воркшопа, в которых специалисты делают решения из смежных областей. В рамках воркшопа они реализуют простые прототипы kafka, kubernetes, delta lake (штука для работы с данными). Создав прототип, люди начинают понимать базовые принципы, на которых основаны эти системы и начинают видеть рабочие ситуации с другой стороны Это не означает, что больше не нужны специалисты, которые глубоко погружены в какую-то область знаний. Они, конечно же, нужны. В идеале в команде нужны и генералисты и специалисты. Специалисты в этом сетапе: - Обучают генералистов, подсказывают им какие-то неочевидные нюансы, потеря которых сильно ухудшит решение - Используют свои знания для создания лучших решений Для каждой ключевой компетенции в команде нужен 1-2 специалиста. --- Мое личное мнение: статья топ. По моему личному опыту, люди, которые умеют быстро погружаться в любые домены и находят общие паттерны - одни из самых драйвящих и ценных кадров. По крайней мере в моем опыте продуктовой разработки. https://martinfowler.com/articles/expert-generalist.html #managment #tshape #martinFowler

Блин блинский, яж ссылку на story map прикрепить забыл. А вы чего молчите? Вот краткое упоминание в wiki - Story Map А вот тут целая книга от автора методики. Если вам сказали сделать проект, а вы не знаете с чего начать - начните с книги: Пользовательские истории. Искусство гибкой разработки ПО Перевод кринжовый, да и автор подкидывает неловких шуток, но для понимания концепции подходит.

Почему дизайнеров пихают в дискавери а не в деливери? Меня удивляло, почему дизайнеров, рисующих интерфейсы, считают не частью разработки, а частью дескавери. Т.е. сначала бизнес придумывает фичу, прорабатывает требования к ней, рисует дизайн и только потом идет с этим в разработку. Что случается дальше? Правильно - правки. Разработка бессовестно режет макет и заставляет переделывать целые блоки логики. Задает каверзные вопросы о негативных сценариях и по 20 минут решает какие то технические нюансы, которые нужно было учесть на макетах. Короче говоря, разработчики видят проект под другим углом и, соответственно, другие ограничения. Казалось бы - ну сделай ты дизайнера частью разработки и приходи к ним с "концептом" и набросками UI. Не заставляй тратить время и силы на макеты, которые потом все равно будут переделываться. Пусть он, вместе с разрабами, обсуждает ограничения и только после этого рисует макеты. А теперь, присмотревшись к процессам дискавери и погрузившись в продуктовую часть работы, я понял почему так происходит. Все предельно логично и совершенно неправильно))) Когда продукт придумывает фичу, ему нужно понять как юзер будет с ней взаимодействовать. Проще прорабатывать нюансы, когда видишь фичу со стороны пользователя. А еще макеты упрощают шаринг контекста между людьми - ткнул в макет и всем стало понятно что ты хочешь получить. Короче, как не крути, макеты нужны на этапе проработки фичи. Или все же... Можно по другому? Можно. Есть такой подход - story map. Если очень сильно упрощать, то это построение сценария использования проекта. Фактически, попытка визуализировать то, как пользователь будет взаимодействовать с фичой. Можно использовать стикеры с User Story, референсы, рисунки - любые инструменты. Главное, что бы смотря на карту было понятно что из себя представляет фича и как ей будут пользоваться. Такая карта помогает сделать все то же самое, что макеты, но экономит время и силы. Да и сломанные процессы становятся на свои места. Бизнес прорабатывает пользовательские сценарии и описывает поведение пользователя. Рисует карту "в ширь". Команда наоборот, углубляет карту, уточняя детали. Причем детали будут уточнять сразу со всех контекстов разработки. В конце мы получаем не просто макет, а подробную карту на основе которой можно приступить к дизайну, разработке и тест кейсам. Она уже будет содержать в себе все исправления и нюансы, по этому не будет серьезно меняться. Вот теперь можно рисовать макеты. А еще тест кейсы. И ADR накидывать, если надо. Что делать то? TL;DR Короче. Что делать, если к вам постоянно приходят с макетами, которые надо переделывать после тех ревью: 1. Не стесняйтесь отправлять переделать. Это не вы заставляете дизайнера работать дважды, а система. 2. Подумайте, может надо подключаться к проработке фичи сильно раньше? Еще до дизайна? Сэкономите время дизайнера, бизнеса и свое.

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