Слова паразиты, часть 2

– Ну неужели самому трудно догадаться?

Второй триггер некачественных коммункаций в команде, после слова «нормально».

Объяснение ему – ошибка атрибуции, когда поведение других людей объясняется их личностными особенностями, а своё – внешними обстоятельствами. Если вдруг мне что-то непонятно, значит плохо задача поставлена, документация отстой, интерфейс не продумали и вообще, сложно догадаться, что мне сразу нужно больше информации? А если непонятно тому, с кем мы общаемся – то он просто не тянет, раз сам не догадался, что я имел ввиду. А работает эта ошибка в обе стороны в любых коммуникациях – члены команды, руководитель ↔ подчинённый, бизнес ↔ пользователь.

Как её избежать?

– Понять, что если закрадывается мысль «неужели ему самому трудно догадаться?» то так и есть – да, ему было трудно догадаться! Ведь он не обладает той информацией, которая есть в твоей голове! И это не его фейл, а твой
– Научиться ставить себя на чужое место. Это не так легко, как кажется – сложно убрать из головы ту информацию, которая в ней есть и представить свою реакцию без неё. Развивается только на практике
– Разговаривать. Это вообще главный инструмент для решения любых проблем в команде. Хочешь разобраться, понял ли тебя человек? Спроси, что именно он понял. Не понимаешь, что говорят тебе? Скажи об этом!

Правило бойскаута

В книге «Чистый код» Роберт Мартин призывает разработчиков пользоваться правилом бойскаута: оставляй место стоянки чище, чем оно было до твоего прихода. Интересный факт – если погуглить «правило бойскаута», то вы найдёте в основном ссылки на эту книгу.

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

Представь, что каждый в команде будет выполнять каждую свою задачу на 110%? Кроме того, что его просят – он будет ещё смотреть вокруг, искать несовершенства и предлагать улучшения (а иногда не предлагать, а сразу их реализовывать)? В процессах, документации, постановке целей, формате проведения собеседования, регламенте работы с клиентами, в коде, формате код-ревью, дизайне и используемых инструментах?

Может, именно из таких людей должны состоять продуктовые команды?

А как бы ты отнёсся к такой культуре?

💂 – это же хаос! Пусть все делают, что от них просят
🧘 – это уровень просвещения! Все рано или поздно к этому должны прийти!

Про внедрение процессов

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

Любой процесс – это продукт, который нужно внедрить, а внедрение продуктов, в том числе внутренних – это не просто. Что нужно для внедрения?

– Продать идею людям. Какую их (а не вашу) проблему решает новый процесс?
– Сделать быстрый онбординг. Что прямо сейчас можно сделать, чтобы попробовать новый процесс и ощутить его пользу?
– Найти early-adopters. Соберите фидбек, доработайте
– Найти лидеров, которые введут новый процесс в свою работу. Кроме внедрения процесса у одного человека, он будет внедрён у целой команды.
– Проиллюстрировать процесс всеми возможными способами: про него нужно написать, рассказать, его нужно показать. Есть люди визуалы, есть аудиалы и т.д. – достучитесь до всех, до каждого своим способом.

А после этого – начните регулярно напоминать про новый процесс. И только когда вы устанете повторять – люди наконец-то вас услышат (с) CEO Linkedin Джефф Вейнер

Простой способ начать

Когда вы собираетесь сделать что-то новое, часто самое сложное – это начать. Это как белый лист для писателя – непонятно, что писать? Зато процесс разгоняется после первых строк.

Есть простая техника, которая упрощает первый шаг: не знаете, что вы хотите сделать? Подумайте, что вы точно не хотите – так вы сузите зону для старта.

– Не знаете, кого хотите нанять? Подумайте, кого вы не хотите видеть в команде
– Не знаете, как должно выглядеть новое приложение? Подумайте, как оно точно не должно выглядеть
– Не знаете, в чём ваши цели на следующий год? Подумайте, чем вы точно не хотите заниматься

Про планы и планирование

В любой компании, с разными подходами, размерами и людьми происходит примерно одно и тоже: руководство с менеджерами ставят планы, в которых они о чём-то забывают. В процессе работы возникают новые требования или происходят форс-мажоры и планы становятся не актуальными. Разработчики дают неверные оценки своей работы и планы менеджеров рушатся. Дизайнеры негодуют, что в правках их просят сделать то, что изначально вообще не обсуждалось – «Эу, мы же запланировали работы по дизайну и там этого не было!». В конце квартала менеджеры думают, как же так презентовать результаты, чтобы их планы считались выполнеными... Постоянный стресс и хаос! А казалось бы, планы созданы для душевного спокойствия и уменьшения энтропии...

Даже личные планы никогда не работают – когда ты последний раз запланировал свой день и занимался только тем, что написано в нём? И сделал всё, не больше и не меньше?

Так нужно ли что-то планировать или это лишнее усложнение, как в работе так и в жизни?

– Планирование – инструмент рефлексии. Обсуждая план (иногда – сам с собой) ты понимаешь, что именно собираешься делать. Поэтому план, опущенный сверху вниз без какого-либо обсуждения никогда не сработает. Слишком часто люди не понимают друг друга с первого раза
– План – вектор, а не конечная точка. И со временем этот вектор может меняться – не нужно подниматься на гору, если понял, что гора не та
– План с одной итерацией – плохой план. Парадокс: казалось бы, план должен составляться один раз в квартал/месяц/неделю/день и быть ориентиром. Но на самом деле, он должен в течение этого квартала/месяца/недели/дня постоянно обновляться
– Планирование – непрерывно совершенствующийся процесс. Просто начав планировать ты не начнёшь делать это хорошо. Например, в книге «Измеряйте самое важное» автор говорит, что для внедрения, казалось бы понятного способа планирования компаний Objectives & Key results (OKR) может понадобится 4–5 квартальных циклов.

В общем, «план – ничто, планирование – всё» Д. Эйзенхауэр

Лайфхак про планирование

Прочитал про него в «Джедайских техниках». Если задача постоянно переходит на следующий день/спринт/квартал – поменяй её формулировку. Из-за эффекта семантического насыщения ты со временем уделяешь ей меньше внимания (а иногда и хуже понимаешь, что же там нужно сделать)

Получается итеративная работа над формулировкой задачи, а чем понятнее формулировка – тем больше шанс выполнения.

Слова-паразиты, часть 3

– А давайте сделаем...!

Сколько раз в неделю вы слышите эту фразу в своей команде? А как часто говорите её? А какая конверсия из произнесения фразы в конечный результат? Подозреваю, что не очень высокая.

Эта фраза вызывает искажение: мы обсудили и произнесли вслух какое-то решение или идею, теперь она точно будет сделана! Но кто именно будет этим заниматься? И когда? А она важнее сотни других вещей или нет?

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

Как повысить конверсию?

– Придумайте простой первый шаг. По каким бы критериям вы не приоритезировали задачи и идеи в команде, всё равно первыми будут сделаны понятные
– Решите, кто именно это сделает. Или проявите инициативу и явно выдвините свою кандидатуру. Это ещё и может послужить примером в будущем.
– Зафиксируйте идею/задачу в мессенджер/таск-менеджер. Даже если задача не будет сделана сразу – она не потеряется
– Иначе – не ожидайте результата. Ведь завышенные ожидания ведут к разочарованиям и выгораниям.

Процесс разработки – это продукт

Часто разработчики думают, что продукт, получаемый в результате их работы совпадает с тем продуктом, который создаёт их компания. Всё так, но кроме этого они производят ещё и что-то внутреннее. Продукт, которым пользуется сама команда – весь процесс и код. А как нужно работать над продуктом?

– Двигайтесь итерациями. Не старайтесь сразу написать идеальный код и внедрить идеальные процессы, решить все проблемы
– Продумайте jobs to be done. Какие JTBD у вашей команды? Быстро выкатывать изменения на продакшен? Легко и просто тестировать изменения? Мониторить изменения на продакшене? А помогает ли это делать ваш продукт?
– UX должен решать проблемы. Для UX в коде/тулинге даже есть отдельный термин – Developer Experience / DX. Насколько легко и удобно пользоваться вашим процессом? Всё ли легко найти? А кодом? Проста ли навигация? Нет ли запутанных формулировок?
– Что по онбордингу? Intercom говорит, что онбординг должен вести пользователя до тех пор, пока он не получит value вашего продукта. Легко ли новичку запустить ваш проект и зарелизить своё первое изменение на прод в первый рабочий день?
– Следите за ключевыми метриками. Чтобы понять, улучшается или ухудшается ваш продукт нужно выделить ключевые метрики. Какие они для вас? Количество релизов в день? Строчки кода? Размер бандла на фронтенде? Скорость прогона тестов в CI?

Если взглянуть шире, то не только код или процесс, всё – продукт. Про это я немного поразмышлял на нашей внутренней конференции

Проще = лучше

Наверняка, у каждого в школе или универе были преподаватели-антиподы. Первый был аспирант, объяснял «ковыряние в носу» с помощью сложных терминов, потом самоутверждался на экзаменах, унижая студентов, требуя заученных формулировок, вместо понимания. А в соседней аудитории кто-то весело и легко рассказывал про квантовую неопределённость, приводя в пример свою бабулю, которая смотрит Санта-Барбару. Или не смотрит. Какой предмет лучше усваивался? Уверен, что тот, который подавался простым и понятным языком.

В разработке есть принцип KISS – Keep it simple, stupid. Код нужно писать максимально просто и не усложнять без надобности. Чем проще код – тем проще его поддерживать, понимать, дописывать, изменять, переносить. А значит разработчики тратят меньше сил и нервов, а бизнес решает задачи быстрее и дешевле.

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

Делать просто должен не разработчик, это командная работа. Старайтесь держать в уме этот принцип каждый раз, когда что-то создаёте – пишете код, документацию, задачу, пост, проектируете систему или рисуете дизайн. Чем проще – тем лучше. Не усложняйте. Не пытайтесь сразу сделать идеально. Сначала сделайте, а потом сделайте лучше. А когда сделаете несколько итераций – задумайтесь, а не усложнили ли вы всё? Парадоксально, но делать просто – сложно.

Решайте одну проблему в одну единицу времени. Вряд ли бы мы с вами сейчас попивали томатный сок на высоте 10км и пытались утрамбовать свой рюкзак гидравлическим прессом до размеров ручной клади в «Победе», если бы Да Винчи или братья Райт думали, как будут влиять самолёты на экологию и где в их летательных аппаратах будет располагаться клетка для перевозки домашних животных.

И помните, если у вас получается что-то очень сложное – вы делаете что-то не так.

Почитать по теме:

– Лонгрид про Overthinking от автора канал @uxlive. ⚠️ подача зайдёт не всем ⚠️
– Принцип Keep it simple, stupid
– Принцип Бритва Оккама
– Чем хуже, тем лучше
– Колхозная доктрина - KISS для разработчиков простым языком

P.S. Будет круто, если вы мне посоветуете книги/посты/видео по теме – пишите в комментарии

P.P.S. Давно не было цитат из пабликов в вк, исправляюсь: «Делай просто, насколько возможно, но не проще этого» А. Эйнштейн

Слова-паразиты, часть 4

– Наверное, я скажу очевидную вещь...

Как давно вы хотели кому-то что-то сказать, но передумали, потому что это очевидно? Сколько фраз, сообщений, твитов, постов, докладов, анонсов в командах или компании вы не сделали из-за их очевидности?

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

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

Каждый раз, когда вы говорите очевидную вещь, кто-то узнает что-то новое.

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

Но есть много кейсов, что это работает и можно делать крутые вещи в короткие сроки, фокусируясь на главном. Вот мои любимые примеры:

– Линус Торвальдс начал работу над git 3 апреля 2005 и уже 4 дня спустя он использовал git для работы над git чтобы коммитить в git, пока он создаёт git. А 20 апреля вышел первый релиз linux на git
– Кен Томпсон написал первую версию unix за 3 недели
– От решения полететь на луну до полёта Аполлон 8 прошло чуть больше 4 месяцев
– Брендан Эйх сделал первую версию JavaScript за N̶a̶N̶ 10 дней

Сохраняйте себе ссылку и скидывайте вашей команде разработки в следующий раз, когда они оценят очередную фичу в месяц

​​Слова-паразиты, часть 5

– Есть 5 минут?..

Знакомо? Сколько раз вы реально уложились? Смысл этой фразы всегда отличается от содержания – все понимают, что это не 5 минут, но продолжают использовать именно такую формулировку. Ведь так в голове есть оправдание – мы выдернули человека всего на чуть-чуть (даже если по факту разговаривали час)! Многие не умеют планировать время, даже своё.

– Цените чужое время. Тема на полчаса? Так и говорите, но планируйте заранее
– Не знаете, сколько нужно запланировать? Поставьте дедлайн. Не успеваете? Разбейте общение – у вас будет больше информации для планирования следующей встречи
– Цените своё время. Кто-то планирует с вами разговор на 5 минут? Поставьте таймер – это поможет держать фокус на главном. Не успели? Возможно, в следующий раз кто-то будет лучше ценить ваше время
– Говорите нет. Делаете что-то в потоке и вас хотят выдернуть? Пусть подождут. Минут 5.
– Не доверяйте людям, у которых всегда есть 5 минут.

Первый шаг автоматизации – сделать это руками

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

Когда-то я подсмотрел у Леши идею создания специального отдела, в который кто угодно может делегировать простые задачи. Идея проста: вы нанимаете людей, которые занимаются только простыми/однообразными задачами, но делают это постоянно, тем самым разгружая остальные отделы. В итоге задачи делаются быстрее, стоят – дешевле. И часто экономят не только время менеджеров, но и разработчиков, т.к. отпадает нужда в автоматизации.

Какие задачи мы передаём в отдел?

– Сбор информации – ходить по сайтам, «парсить» тексты, копипасить в гугл-табличку или сохранять картинки на гугл-драйв
– Модерация (текстов, фотографий)
– Обработка данных, отчёты
– Простейшая работа с графикой
– Бонус 1: вы можете поставить задачу, которую сложно формализовать. Например «найди классные фотки», «выбери 20 самых интересных текстов»
– Бонус 2: этот человек обойдёт любую капчу!

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

В общем, всем рекомендую.

Парадокс покоя

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

– Никто не спорит и все согласны со всеми принимаемыми решениями
– Все уверены, что выстроены идеальные процессы и коммуникация
– Никто не сомневается в компетентности других членов команды, в качестве их работы
– Команда годами использует одни и те же инструменты и практики

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

Как отличить инженера от программиста?

– Программист скажет «так сделать нельзя», инженер возьмёт паузу и придёт либо с решением, либо с альтернативой
– Программист скажет «я там спросил, а мне не ответили...», «пул-реквест на код-ревью/QA-завис...», «у меня доступов не было...», а инженер доведёт всё до продакшена
– Программист скажет «у меня кончились задачки, чем заняться?», инженер – «задачки кончились, но у меня есть пара сотен предложений. Займусь ими?»
– Программист делает как попросили, инженер – лучше
– Программист начнёт делать, когда поймёт, что от него хотят. Инженер - когда поймёт, зачем

Нанимайте инженеров!

Как прокачать руководителя?

Фидбек между руководителем и подчинённым работает в обе стороны. Почему-то об этом часто забывают сами подчинённые и воспринимают общение с руководителем, только как получение фидбека. Но (сюрприз!) руководители – просто люди. У них может не хватать опыта, могут быть проблемы с тайм-менеджментом, они могут не знать, о чём вы хотите поговорить, у них у самих может быть не лучший руководитель. А ещё они сами могут всего этого не замечать. Так что если вы не получаете от руководителя того, что ожидаете – возьмите инициативу в свои руки, прежде чем искать новую работу. В английском для этого есть отличное выражение – manage your manager.

Примеры распространённых ситуаций:

– Получаете только негативный фидбек? Соберите факты и обсудите. Вроде «мне кажется, что за последние 3 месяца я хорошо сделал X и Y, но слышал только критику за Z. Почему?»
– Руководитель становится бутылочным горлышком и это замедляет вас? Намекните, что вы могли бы быстрее и лучше делать свою работу, если бы он делегировал полномочия
– Руководитель назначает встречи в стиле «окей, давай вернёмся к этому вопросу через месяц» и забывает о них? Добавляйте в календарь и приглашайте его. Либо просто напоминайте – «Привет! Месяц прошел – обсудим?»
– Не знаете, как зарабатывать больше? Спросите руководителя. Подумайте вместе, что вы можете делать и обсудите дату подведения промежуточных итогов
– Вам обычно не хочется с ним разговаривать? Скорее всего вам не повезло и вы работаете с руководителем, который не заряжает вас энергией, а забирает её. Попробуйте решать вопросы письменно – может так будет проще.

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

Слова паразиты, часть 6

– Ну я же говорил!

У всех хотя бы иногда проскакивает эта фраза, хоть и не все озвучивают её вслух. И именно когда она попадает в мозг – нужно себя поймать и разобраться, в чём же первопричина? В 80% случаев произошло что-то, что не идёт на пользу команде. Например:

– Вы закинули идею, возможно в формате «а давайте...», но не захотели её продвигать, чтобы умышленно избежать ответственности за возможные последствия. Возможно ожидая, что кто-то её услышит и «возьмёт в работу» вместо вас, но этого не произошло и всем от этого стало хуже.
– Недостаточно аргументов. Возможно, вы уверены что ваше предложение было очевидно остальным (несмотря на то, что их позиция для вас не очевидна) и из-за недостаточной аргументации, вашего неумения «продавать» свои идеи пострадала вся команда.
– Ваше эго для вас важнее общих успехов ¯\_(ツ)_/¯. Если из 10 принятых чужих решений лишь одно не сработает вы наверняка скажете заветную фразу, а про остальные 9 и не вспомните
– Вы просто любите покой и не хотите с кем-то спорить.
– Из нескольких альтернатив выбрали не ваше решение, хоть вы и аргументировали всё и были готовы взять ответственность. Можете даже не напоминать – в следующий раз все и так вспомнят этот случай и прислушаются к вам.

Узнали себя? Ну я же говорил!

​​Как давать фидбек?

Нет-нет, я тут не буду говорить про схемы бутерброда, ненасильственного общения или stop–start-continue. Тут о другом.

Часто замечаю 2 крайности при фидбеке о чужой работе:

1. Люди смотрят на чужую работу (код, картинки, тексты) и никак её не комментируют, если их явно об этом не спросить.

При такой схеме в команде отсутствует культура обмена знаниями и мнениями. «Ну работает и работает» и не важно, что это можно сделать проще/быстрее/лучше, часто даже не потратив больше времени.

2. Чаще всего бывает в схеме лид/подчинённый: одни комментируют всё подряд, выражая своё мнение о каждой мелочи, после чего другие исправляют всё и делают именно так, как сказали.

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

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

Итого, 5 простых правил для продуктивного фидбека (и не важно, кто ты – новичок в стартапе или CEO в большой компании):

1. Задавай вопросы. Так будешь лучше понимать, что происходит, почему именно так и вообще, как мыслят другие
2. Предлагай идеи, желательно как-то аргументируя (даже если ты не считаешь себя экспертом в вопросе). Не все знают, что знаешь ты и кто-то точно чему-то научится.
3. Пиши о возможных проблемах и альтернативных путях решения
4. Хвали коллег, когда они делают хорошо!
5. И главное – явно сообщи, что ты хочешь? Как относиться к твоему фидбеку – это просто комментарий, просьба переделать или твоё мнение, что всё ок и с этим можно продолжать?

Ну и примеры:

– «̶Д̶а̶в̶а̶й̶ ̶п̶о̶ ̶н̶о̶в̶о̶й̶,̶ ̶М̶и̶ш̶а̶,̶ ̶в̶с̶е̶ ̶х̶е̶р̶н̶я̶!̶»̶ ̶«Давай поправим пункты 3-5 и будет 👍, а 6-7 на твоё усмотрение, не хочется время терять»
– «👀 Накидал комментов, на случай если интересно моё мнение»
– «🔫 Пушка, можно релизить!»

Видео про культуру в Spotify – это, наверное, лучшее куда вы можете потратить свободные 25 минут сегодня (и как это раньше прошло мимо меня?)

Основные тезисы:

- Команды должны быть loosely coupled, tighly aligned. Ставьте понятные цели для компании, чтобы команды шли в одном направлении, при этом делая команды максимально автономными
– No one will tell you what to do. Конкретные действия должны определяться внутри команд, но основываться на глобальных целях
– «If you need to know exactly who is making decisions you are in the wrong place». Избегайте систем, где решения принимаются единолично
– Чем реже релизы – тем сложнее релизить. И наоборот. Чаще делайте релизы, прячьте неготовый функционал за feature toggles, упрощайте процесс релиза.
– Каждая команда отвечает за свои системы и релизит их независимо от других команд
– Fail fast → learn fast → improve fast
– failure recovery важнее, чем failure avoidance
– «If everything is under control, you are going too slow»
- Innovation важнее predictability. 100% predictability = 0% innovation
– Big project = big risk. Делите большие проекты на мелкие шаги, выкатывайте MVP

Оно же текстом: часть 1, часть 2.

​​Про поведение

Нашел простую модель, объясняющую человеческое поведение. Fogg Behavior Model говорит, что поведение зависит от мотивации, сложности этого действия и побуждений:

Behavior = motivation × ability × prompt

Как это применять в командах? Так же как и в продуктах/дизайне: если хотите, чтобы люди что-то делали, то

– Упрощайте. Чем проще и понятнее взаимодействие, инструменты, процессы – тем проще их использовать. Плохо: деплой в особую фазу меркурия специально выбранным человеком с помощью сложных ритуалов. Хорошо: деплой одним нажатием на кнопку 🆗.
– Мотивируйте. Мало рассказать, как надо делать, важно показать пользу для конкретного человека. Плохо: «Ну показывай, что сделал». Хорошо: «Чем раньше ты поделишься наработками – тем быстрее получишь фидбек и в случае ошибок или неверного решения не обидно будет срезать часть работы 🔪»
– Подталкивайте. Даже если люди замотивированы что-то сделать и у них есть все возможности – им нужен call to action. Плохо: «Стыдно этого не знать...», хорошо: «Почитай <название книги> – там классно рассказывается про базовые принципы, тебе в будущем это поможет быстрее принимать решения 💪»

Почитать:

– https://suebehaviouraldesign.com/bj-fogg-model/
– https://behaviormodel.org

​​Про хлам

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

Я всегда больше всего любил изменения в коде, в которых что-то удалялось и ничего не добавлялось. При этом ничего не ломалось и всё работало как и прежде, а код становился проще, а значит лучше.

От чего, например, можно избавиться и упростить жизнь себе и окружающим?

– От фич. Зачем добавили новую фичу в продукт? Принесла ли она пользу? Если нет – то может она и не нужна? Или, возможно, с её помощью вы решили те же проблемы, что пытались решить другими фичами и теперь можно удалить именно их и оставить только новую? Это можно сделать ритуалом, например выделять несколько часов каждую пятницу на поиск чего-то ненужного.
– От процессов. Ведь наверняка у вас есть какое-то соглашение принятое несколько лет назад, которое все делают по привычке, не задаваясь вопросом «зачем мы это делаем?». Докапайтесь до первопричин, например используя 5 whys и избавьтесь от неактуальных процессов.
– От кода. В проекте остался код, который уже не используется? Удаляйте. Будет нужен – вернёте с помощью гита (подсказка: минимум 80% удалённого кода окажутся ненужными). У вас же не используют количество строк кода, как метрику продуктивности?
– От чатов. Можно бороться с fomo и выходить из чатов, где не нужно постоянное присутствие.
– От сервисов/систем/софта. Иногда, чтобы система работала стабильнее её нужно упростить, а не добавлять новые элементы.

Хорошая практика (которой сложно придерживаться) – при создании чего-то нового избавляться от чего-то старого. Заводите новый регулярный митинг? Отмените один из старых. Добавляете новый код? Удалите немного старого.

В общем, как говорит каждый второй мотиватор – «выкидывайте хлам, чтобы освободить место для чего-то нового».