Инженер и Менеджер

DORA — это DevOps Report, группа людей, которые опрашивают сотрудников крупных компаний на тему "как у вас устроено ИТ в целом и DevOps в частности". Потом ответы собирают, анализируют и делают выводы.

Оригинальный отчет занимает 60 страниц, поэтому вот вам краткие lessons learned из отчета за 2023 год.

1️⃣ Самый легкий способ ускорить вашу разработку — ускорить ваше code review.

Я лично видел, как у команды было нормой ревьюить коммит 2-3 дня. То есть: человек пишет код 3-4 часа, тестирует его минут 30, а потом ждет трое суток (72 часа, кстати), пока кто-то сделает ревью.

Итого: вместо 5 часов заказчик ждет задачу 77 часов.

2️⃣ Найдите баланс между скоростью и стабильностью.

Подчеркну — баланс. Инциденты в проде — ок, не старайтесь свести их в нулю. Чем больше сил вы вкладываете в стабильность, тем меньше результата вы получите.

Тот же Netflix вообще открыто заявляет, что готов принести в жертву стабильность ради скорости. Netflix понимает, что на их рынке скорость поставки новых фич — лучший способ удержать клиента и рынок. Если Netflix будет мега-стабильным, но не таким прорывным, он потеряет рынок.

3️⃣ Распределяйте работу равномерно.

Не допускайте, чтобы все интересные задачи скидывали на какого-то крутого бойца, а всю рутину разгребал замученный и демотивированный мидл.

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

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

Если есть время — почитайте отчет целиком

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

Что влияет на продуктивность работы программиста? Исследователи взяли 600 человек из 92 компаний, разбили их на пары, выдали им одинаковое задание на день и попросили отмечать время.

❌Что не влияет на продуктивность
- Язык разработки: COBOL и Fortran не особо отличались от С. Единственное исключение — языки Ассемблера.
- Опыт: разработчики с опытом в десять лет справились не лучше коллег, которые работали пару лет.
- Итоговое качество: около 30% программистов не допустили ни единого бага, при этом они потратили столько же времени.
- Зарплата: разброс результатов внутри одной вилки не особо отличался от общего разброса.

Замечу: мы говорим о задании "на день", так что кодовая база проекта будет маленькой и разница между языками действительно не очень заметна. Чем больше проект, тем больше решает язык — мое мнение.

✔️Что влияет на продуктивность
Главным фактором эффективности программиста стала... Его компания. В каких-то компаниях программисты показывали стабильно хороший результат, в других — стабильно плохой. Если 9 программистов компании хорошо себя показали, можно с уверенностью заявить, что и 10-ый будет хорош — и наоборот!

В лучших компаниях разработчики показывали результат в 11 раз лучше, чем в плохой. В одиннадцать раз!

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

Исследователи пришли к выводу, что разница крылась в рабочем месте. Вот основные критерии "успеха" по их мнению:
- Физический размер рабочего пространства
- Тишина на рабочем месте
- Приватность рабочего места: ну знаете, когда никто не ходит мимо и не смотрит в твой экран
- Возможность отказаться от созвона
- Количество прерываний в работе: от вопроса в личку до предложения сгонять за кофе

Мое мнение
Рабочее место важно, но я уверен, что не оно определяет продуктивность. Мне нравится мысль про то, что успех определяет компания, но я говорю о процессах и культуре.

А вы что скажете, от чего зависит эффективность разработки?

Пять неочевидных способов усложнить себе интервью

Был период, когда я проводил по 3-4 собеседования в день. Каждый день. Со временем, глаз начал цепляться за неочевидные детали. Я называю их "оранжевый флаг" — не критичный, но неприятный момент в ходе интервью. Наличие оранжевого флага не означает провал интервью, но лучше их свести в ноль.

1️⃣ Не спросить ничего самому. В конце интервью я выделяю время на вопросы соискателя. Мне важно, что интересно человеку и о чем он меня спросит: про атмосферу в команде, переработки или отношение к срокам. Если у человека в конце нет вопросов, я вижу этот как толику безразличия к будущему месту работы.

2️⃣ Слишком много говорить. Некоторых соискателей я постоянно перебивал и прерывал, потому что они уходил в дебри вопроса. Не поймите меня неправильно: подробный ответ — это хорошо, но важно придерживаться сути вопроса и не уходить за горизонт. Например, на вопрос "Зачем вы использовали Кафку?" я не очень хочу услышать лекцию про Raft или распределенные системы.

3️⃣ Слишком мало говорить. Если мне приходится вытягивать из соискателя ответы, это тоже плохой признак: возможно, ему не очень интересна вакансия. На тот же вопрос "Зачем вы использовали Кафку" лучше отвечать подробнее, чем просто "Понравилось". Иногда за неинформативными ответами прячется тот факт, что соискатель ничего сам руками и не делал, просто рядом стоял, но пытается выдать чужие достижения за свои.

4️⃣ Говорить на бегу, в машине или в где-то в подъезде. Все три случая я взял из практики. Я понимаю, что обстоятельства бывают разные, но лучше все-таки перенести собеседование.

5️⃣ Выдумывать, гадать и привирать. Нет ничего плохого сказать "Я не знаю ответа на твой вопрос". Я в таких случаях предлагаю подумать вместе и даже подскажу. Однако, если это превращается в угадайку или "Не помню Кафку, давно ее не использовал, но вообще — очень хорошо знаю!", для меня это оранжевый флаг. Нельзя знать все, но плохо думать, что знаешь все.

Какие неочевидные оранжевые флаги вы подмечаете у соискателей?

Как расти в карьере

Представьте Васю, он мидл-разработчик. Вася справляется со своими обязанностями и хочет расти до сеньора.

Вася думает: если я буду работать еще лучше, меня повысят. И Вася начинает сворачивать горы и показывает:
- Скиллы: берет самую тяжелую работу и вывозит
- Старательность: перерабатывает
- Результат: влезает в абсолютно все сроки

Но ни через месяц, ни через полгода, Васю не повышают.

Лучше всех в колхозе работала лошадь, но председателем она так и не стала, — думает Вася и теряет мотивацию.

Что случилось?
Руководитель не заметил, что Вася хочет вырасти. Руководитель заметил, что Вася отлично делает свою работу и точно находится на своем месте.

Почему руководитель не повысил Васю?
Много вариантов:
- Неопытный руководитель
- Слишком занятой руководитель, у которого нет времени анализировать реальность
- Руководитель-пофигист, который просто отбывает номер на проекте

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

А что делать?
Поговорить с руководителем на сессии один-на-один. Если ваш руководитель не проводит их регулярно, сами попросите поставить один-на-один.

На встрече голосом озвучьте ваши хотелки: до какой позиции хотите расти и за какое время. Например, Вася хотел вырасти от мидла до сеньора за полгода. Это невозможно, поэтому руководитель должен скорректировать ожидания Васи, после чего:
- Запланировать задачи "на рост" на работе.
- Подсветить точки роста Васи: посоветовать почитать Фаулера или кабанчика, например.

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

Чтобы стать идеальным сотрудником, нужно всего лишь...

Самая важная часть работы менеджера — принимать решения. Чем больше у вас людей, тем больше решений вам надо принимать. Решения бывают разные: от того, в какую дату провести оффсайт команды, до выбора БД для real time аналитики на всю компанию.

С решениями есть проблема: в сутках 24 часа, из них рабочих в лучшем случае 10-12. Что же делать?

Рождение идеи
Американская военщина — источник не только многих бед, но и некоторых лучших ИТ практик. Например:
- SCRUM основан на цикле НОРД, который изобрели в армии США
- Extremal Ownership описан Джоко Вилинком, который служил в армии США
- Опрос 360 тоже появился в армии США!

В 1942-ом, в самый разгар Второй Мировой, полковник Арчер раз и навсегда ответил на вопрос: как должно выглядеть решение, которое нижестоящий офицер передаст вышестоящему. Арчер собрал свои мысли в статью и выпустил в свет "COMPLETED STAFF WORK" — шесть правил того, как выглядит завершенная работа.

Как должна выглядеть завершенная работа
1. Изучите проблему и представьте решение в таком виде, чтобы вышестоящий офицер мог только согласиться или отвергнуть ваше решение. Не добавляйте деталей и не перегружайте руководителя — разберитесь с нюансами сами или при помощи коллег.
2. Не спрашивайте вашего руководителя. Делайте свою работу сами и сами давайте ему советы.
3. Не беспокойте руководителя долгими объяснениями ситуации. Проанализируйте ситуацию, сделайте выводы, найдите выходы, выберите лучший и предложите решение, на которое можно ответить лишь "да" или "нет".
4. Никаких драфтов решений. Драфт отличается от финала лишь наличие помарок и опечаток.
5. Резонно потратить больше времени сотрудника, чтобы сэкономить время руководителя.
6. Спросите себя: если бы вы были руководителем, согласовали ли бы вы свое решение? Если нет — переделывайте.

Так чего же хочет руководитель
Он хочет дать вам задачу и вспомнить о ней только тогда, когда вы придете к нему с решением. Делайте так и быстро станете идеальным сотрудником.

Когда найм — это решение
Прямо сейчас в одной из моих команд происходит running to stay still. Это когда вы бежите изо всех сил, люди работают на совесть, делаете тонну задач — вы красавцы! Но заказчик все равно не очень доволен результатом и объемом сделанной работы.

Это плохая, но обычная ситуация. Почему она происходит?

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

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

Другое дело, что бизнес не видит результата выплаты теходлга. Окей, вы потратили две недели, а сколько мы заработали?

Классификация
Вилл Ларсон в "Элегантном Пазле" предлагает категоризировать команды на 4 типа, исходя из отношения команды к техническому долгу:
- Falling behind — когда вы берете больше долга, чем отдаете, техдолг растет
- Running to stay still — новый долг по объему равен выплачиваемому, техдолг стагнирует
- Repaying Debt — платите больше, чем берете, техдолг снижается
- Innovating — для нашей темы неинтересно.

Что делать?
Нужно переходить из "running to stay still" в "repaying debt". Для этого перехода есть только два варианта, третьего нет.
- Нанять больше людей. Найм позволит вам расширить пул задач и начать платить больше. Для меня сейчас это не вариант, к сожалению.
- Делать меньше "нужной" работы и освободившееся время отдавать на выплату техдолга. Это мой вариант, но договориться с заказчиком будет не очень просто :)

Я, кстати, выступал на конфе по этому поводу

Закон Брукса
Нельзя тушить пожар бензином. С этим любой согласен. Однако, если проект начинает гореть, менеджер начинает заливать его людьми.

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

Почему закон Брукса работает
- Новые люди должны влиться в команду. Вил Ларсон в "Элегантном Пазле" называет это геллингом. Чтобы выйти на уровень эффективности, новый разработчик должен со всеми перезнакомиться, запомнить, как запускать всякие магические скрипты, к какому девопсу ходить, а к какому не надо, к кому идти за советом касаемо то или иной части кода — ну короче, геллинг. Что еще хуже: существующая команда тоже потратит время, чтобы влить к себе новичка.
- Новые люди повышают налог на коммуникацию. Я приложил к посту картинку, насколько быстро растет число горизонтальных (и только горизонтальных!) коммуникаций с ростом команды.
- Некоторые задачи нельзя распараллелить. Как девять женщин не родят ребенка за месяц, так и некоторую задачу просто нельзя ускорить людьми. Как правило, это какой-нибудь ресерч или технически сложная задача.

Что же теперь делать
Если ваш проект горит, я знаю три надежных варианта действий, чтобы успеть:
- Перенести сроки на подальше.
- Порезать скоуп задач, чтобы бэклог стал поменьше.
- Использовать принцип "бах-бах и в продакшн", то есть набрать кучу техдолга.

Если знаете еще варианты, пишите в комментарии :)

Здравствуйте, это ваша сила воли

Да, прямо на картинке. Эта часть мозга называется Anterior cingulate cortex, или Передняя поясная кора (ППК), и ее можно накачать, почти как мышцы.

С чего это я взял
В ходе исследований (пример) ученые установили прямую связь между размером ППК и "силой воли" человека — способностью делать то, что не хочется и не делать то, что хочется. Если все так, что формула простая: чем больше ППК, тем "больше" у вас силы воли.

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

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

Чтобы увеличиться ППК, надо ее использовать: чем больше мы используем ППК, тем больше в размере она становится. Например, ППК больше у людей, которые:
- Занимаются спортом
- Медитируют

С другой стороны, ППК будет меньше у людей:
- С избыточным весом
- С низкой активностью
- И так далее

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

Если вы поддаетесь желанию съесть лишний кексик, в следующий раз сопротивляться будет сложнее. Если кексик вы все-таки не съели, в следующий раз отказаться станет еще проще.

Но помните: наука может ошибаться, и все это опровергнут через сто лет. Или нет :)

Le Saboteur
В 1944 ЦРУ выпустила книгу "Простой саботаж", чтобы помочь европейскому сопротивлению в их борьбе: вредить, но при этом не слишком вызывающе, тайно. И вы сейчас очень сильно удивитесь, потому что кажется, что некоторые нынешние руководители взяли ее за мануал :) Смотрите сами:

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

Далее попробуем переложить их на наши реалии
СТО
- Первым делом потребуйте полгода-год, чтобы переписать все легаси.
- Сделайте так, чтобы для локальной разработки надо было поднять 10-12 сервисов разом.
- Убедитесь, что для каждой буковки в коде создана задача, история или даже эпик.
- Настаивайте, что любое техническое решение должно выдержать нагрузку минимум в х10 от текущей.
- Наймите как можно больше архитекторов, устройте архитектурный комитет и проводите сквозь него любую мало-мальски большую фичу.

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

Проджект менеджеры
- Пытайтесь включить в проект как можно больше разных команд. Бонус-поинт, если они будут из разных часовых поясов :)
- Требуйте точной оценки в часах всех задач. Всех!

Готово! Вы великолепный саботер, Франция может вами гордиться :) Если интересно подробнее и больше, вот оригинал.

Наткнулся на правила общения в компании 37signals

Понравились, перевел для вас самые интересные:
2. Предпочитайте асинхронное общение — чатики или почту, но иногда можно и синхронное — звонки или встречи.
5. Встречи или созвоны — решение на крайний случай, а не выбор по умолчанию.
8. Если ваши слова могут понять неоднозначно, большинство людей поймет их максимально вредным и оскорбительным образом.
9. Никогда не ожидайте немедленного ответа ни от кого. Если только у вас не случился пожар, конечно. Требования немедленного ответа — это токсичное поведение.
11. Плохая коммуникация создает больше работы.
13. Пять людей на часовой встрече — это не один, а пять потраченных часов.
15. Коммуникация не должна требовать синхронизации. Календари тоже не связаны с коммуникацией. Письменную речь можно отвязать и от синхронизации, и от календаря.
16. "Сейчас" редко является лучшим временем для высказывания мысли, которая только что родилась у вас в голове. Дайте ей настояться. То, что останется через время — и есть та часть, которую стоить говорить.
19. Чтобы узнать ответ, надо задать вопрос. Чтобы получить правильный ответ, надо задать правильный вопрос. У людей вообще есть что вам рассказать, но редко есть желание подходить без спросу.
21. Срочность переоценена, ASAP — яд.
22. Если вы пытаетесь донести сложную новость, пригласите людей задавать вопросы в конце вашего письма или речи. Сложная весть без возможности ее обсудить — лучшая почва для слухов и сплетен.
25. Не перемешивайте плохие и хорошие новости, подавайте их отдельно.
26. Время на твоей стороне, а вот спешка лишь усложнит коммуникацию.
27. Общайтесь напрямую с теми, с кем вам нужно общаться. Избегайте передачи мыслей через кого-то.
29. Если нужная и важная коммуникация случится в неподходящее время, считайте, что никакой коммуникации и не было.

И еще бонус. Почему они не включили это как правило — не знаю, по-моему, лучшая идея:
> We don’t use email internally

Очень захотелось затащить к нам такое.

Будущее непредсказуемо
В 80-ых годах компания AT&T крепко задумалась: заходить ли им в рынок изготовления мобильных телефонов. AT&T занимались телекомом, так что смежное направление мобильных телефонов выглядело перспективным, но рискованным. Компания переживала, что сотовые телефоны — это просто игрушка для богатых людей, а не стабильный рынок.

Чтобы помочь самим себе сделать выбор, AT&T пригласили компанию McKinsey составить прогноз: сколько сотовых телефонов будет на руках у жителей США в 2000-м году?

Для справки: McKinsey это очень-очень крутая консалтинговая компания, топ оф зе топ, сrème de la сrème. Клиенты McKinsey это Google и Microsoft, так что парни там сидят очень серьезные.

И эти серьезные парни должны быть дать серьезный прогноз. В конце-концов, это их работа, а они — профессионалы. Ведь так?

Не совсем
McKinsey посчитали, что к 2000-му году у жителей США будет на руках около 900 тыс. мобильных телефонов. AT&T решила не заходить на рынок мобильных телефонов (позже они изменят решение, но время будет потеряно).

Как думаете, насколько ошиблись McKinsey? Ваши ставки? В три раза? В десять раз?

Более, чем в сто раз. В 2000-м году по разным оценкам у жителей США на руках находилось более 100 млн. мобильных телефонов. А AT&T упустила миллиарды (триллионы?) долларов.

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

Нельзя предсказать будущее. Можно предположить и сделать ставку на определенный исход, но предсказать — нельзя.

Неймдроппинг
Давайте сыграем в игру. Допустим, вы хотите убедить разработчика сделать задачу, которая не в его бэклоге. Практика плохая, но иногда приходится. Я могу привести плюс-минус три категории аргументов, чтобы это сделать:
- A — Задача поможет заработать нам денег
- B — Задача интересная и поможет тебе прокачаться
- C — Задачу поставил сам Иван Иванович, понимать надо!

Какой бы выбрали вы? Для меня лучший аргумент — заработок компании, но для подавляющего большинства людей интерес к задаче важнее. Поэтому я бы выбрал В и давил на него. Однако, выбрать А не будет ошибкой.

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

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

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

Альтернативы неймдроппингу
Помимо мотивации пользой (приоритетами) и ростом, есть еще варианты:
- Замена — если вам так надо впихнуть в бэклог новую задачу, сделайте это, но уберите одну старую примерно того же объема работы.
- Бартер — предложите команде, в которую вы хотите пропихнуть работу, свою помощь. Выделите им своего QA, помогите ревьюить MR'ы, включитесь вместо них в дежурства.
- Примером — попросите у команды список текущих и предстоящих крупных задач. Потом сравните каждую из них со своей задаче и коротко опишите, почему ваша важнее.

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

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

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

Давайте разберемся, как именно Вася можете зафакапить стратегию.

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

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

Неправильно понять вызов
"Увеличить продажи молодой аудитории с помощью нового дизайна дверных ручек" пишет Вася. И Вася молодец — такая формулировка очень похожа на стратегию, но верно ли Вася понял вызов? Действительно ли для компании важно продавать двери именно молодому поколению?

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

Вася ставит диагноз: "Мы должны производить дверные ручки, которые стали бы конкурентным преимуществом".

Вася пишет правила:
- Каждая ручка должны выдерживать миллион открытий
- Модельный ряд ручек не должен сократиться

А потом Вася начинает думать. Ему надо увеличить качество ручек, но сокращать модельный ряд нельзя — тогда откуда взять людей и денег? После размышлений на тему, Вася вычеркивает последний пункт и пишет правило: "Мы можем исключить неудачную модель без попытки исправить ее".

Вася пишет список действий:
- Заменить поставщиков комплектующих
- Внедрить систему 5S на рабочих местах
- Усилить технический контроль на производстве
- ...

Готово! То, что сделал Вася — очень похоже на настоящую стратегию и билет до тойоты камри и водителя.

План — это не стратегия
Чем больше вы менеджер, тем чаще вы будете ходить на встречи по типу "стратегическое планирование", "стратегия Q5 2077" и всякое такое. Набор тем для обсуждений может быть разный, типа:
- Как мы запилим фичу Х
- Какие новые продукты мы запустим
- Какие новые направления откроем

Так вот, это не стратегия. Это — планы. Отличие стратегии от плана хорошо писано в этом видео.

Что такое стратегия
Стратегия — это набор установок и связанных между собой действий, которые направлены на решение конкретной проблемы. Стратегия состоит из трех частей:
- Диагноз — подробное, но лаконичное описание проблемы и контекста. "Мы хотим качественнее пилить фичи" это не диагноз. "Мы хотим перестать терять деньги из-за простоев, которые происходят из-за багов в коде" — больше похоже на правду. Хорошо сформулированный диагноз это половина успеха.
- Установки — набор правил, по которым мы играем. Для примера выше правила могут быть такими: мы можем снизить кол-во фич в месяц, но мы не можем замедлить разработку. Правила помогут вам формулировать действия.
- Действия — набор задач, которые помогут достигнуть цели. Задачи должны быть связаны между собой! Если задачи получились вразнобой, возможно, диагноз неправильный.

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

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

Я сфокусировал три из трех команд одного из юнитов платформы на доставке инструментов и процессов для НТ.

Мой диагноз оказался верным. Сейчас инструменты НТ используются в 80%-90% команд Сбермаркета, а это значит, что платформа вновь помогла бизнесу сэкономить деньги, потому что предоставила единое решение для всей компании.

Сила воли — безграничный ресурс
Несмотря на то, что нам очень долго вещали обратное: из книг ("Джедайские техники", например), подкастов и прочего. Везде говорили, что сила воли — это как будто бы ресурс и его вроде как надо беречь, чтобы пустить на важные дела.

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

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

Корень мифа
В 1996 году Рой Баумайстер провел эксперимент: 67 человек поместили в комнату, в которой лежало свежее печенье с восхитительным ароматом. Рядом с печеньем лежала самая обычная редиска.

Испытуемых поделили на две группы. Первой группе разрешили съесть печенье, а второй — нет, их заставили есть редиску. После перекуса обе группы объединили в одну и дали следующее задание, которое должно было проверить их настойчивость и усидчивость при решении. Пример такого задания — найти в тексте все буквы "и", перед которыми есть буква "н". Задача простая, но очень, очень скучная, так что придется привлекать силу воли, чтобы не забить.

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

Ответ: да, приведет. Та группа, которая съела печенье, справилась с заданием гораздо лучше. Поедали редиски и справились хуже, и попыток сделали меньше. А еще редискоеды даже сдались раньше, не потратив в среднем и половины от доступного времени. Вывод: поедатели редиски действительно растратили силу воли.

Суть мифа
Силв воли — это типа мышца. Если вы используете ее, она устанет и будет работать хуже, а потом и вовсе откажет. Удобная теория, правда? Очень понятно все описывает, а главное — дает нам с вами миллион отмазок для самих себя.

Баумайстер, кстати, резких выводов не делал, а вот ученое сообщество и около-наука вроде научпопа (со всем уважением к) оказались более быстрыми на выводы из его опытов.

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

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

Ответ: нет. Дело даже не в глюкозе.

Разрушение мифа
Исследование от 2013 провело 3 эксперимента, в которых испытуемых и заставляли решать муторные задачи (например, вычеркивать из текста все буквы Е), и проходить тест Струпа, и делать еще всякое. На разных этапах эксперимента разным группам выдавали либо воду с подсластителем, либо воду с глюкозой.

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

Если человек считает свою силу воли неисчерпаемым ресурсом, то ни глюкоза, ни длительность экспериментов не будут иметь никакого эффекта.

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

Ссылки
- То самое исследование от 2013 года
- Выпуск Хубермана
- Подробная статья

Почему маленькие команды — это плохо
И какие команды считать маленькими

Когда на собеседовании я спрашивал, "какого размера должна быть команда" у тим-/юнит-лида, я всегда получал ответ "4-7 человек" или "two-pizza team" — команда, которая целиком способна пообедать двумя пиццами.

Ответ правильный.

Потом я спрашивал, почему нельзя сделать команду больше? Мне отвечали, что менеджеру тяжело управлять бОльшим числом людей. Тоже правильно.

А потом я спрашивал, почему нельзя меньше? Почему бы нам не сделать команду из 2-3 человек? Это ведь даже должно быть удобно: гибкий коллектив, все друг друга знают, дейлики быстрее проходить будут. Так почему команда из 2-3 человек — это плохо?

Потому что у команды из 2-3 человек на самом деле меньше человеко-часов, чем должно быть. У команды всегда есть часы, которые она тратит на процессы и поддержку старых проектов. Например:
- 2 часа в неделю на планирование,
- 1 час на ретроспективу
- 2 часа на груминг/PBR
- и еще 10 часов на поддержку старых проектов — вы никуда не избавитесь от этих трат.

Пример из жизни. У команды из 2-х разработчиков (менеджера не считаем) должно было быть 40*2 = 80 человеко-часов в неделю. Поначалу все шло неплохо. Команда пилила эпик за эпиком, проектов на поддержке постепенно становилось все больше. Поддержка не была критичной: тут кнопочку подкрасить, там формочку добавить.

Но спустя пол-года мы обнаружили, что из 80 часов в неделю, до 40 часов занимает обслуживание других проектов и SCRUM-артефакты. То есть: реальное капасити команды было не 80, а 40 часов в неделю.

А дальше начинается магия. В теории, если к команду из 2-х разрабов донанять еще одного, это увеличит их производительность в полтора раза, с 80 до 120 часов в неделю. Но в новых реалиях, если мы докинем +1 разработчика (+40 часов), то он увеличит реальное капасити команды в два раза.

Так что за two-pizza team'ами стоит еще и суровая математика.

Работали ли вы в команде, менее чем из 3-х человек? Управляли ли вы такой? Как вам?

Как быть, если на встрече ваш собеседник (или собеседники) настроены к вам агрессивнее, чем вы бы хотели?

Вчера у Хубермана в подкасте услышал тейк, с которым хочу с вами поделиться.

Сам Хуберман — ученый нейробиолог, а его гость — бывший специалист по переговорам из ФБР. В подкасте оба рассуждали о ведении переговоров и описывали всякие хитрые приемы, чтобы с большей вероятностью достичь успеха. Один из примеров мне прямо запал в сердце.

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

Переговорщик из ФБР рекомендовал использовать голос вечернего радиоведущего, если ваш собеседник агрессивно настроен к вам. Такой тон успокоит вашего собеседника и поможет стабилизировать его эмоции.

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

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

К сожалению, в подкасте он не привел ссылки на исследования, поэтому их привожу вам я :) Они действительно подтверждают следующие мысли:
- Понижение голоса помогает ощутить контроль над происходящим
- Более низкий голос (для мужчин) больше располагает к себе собеседника
- Имитация более низкого голоса тоже может работать

tl; dr если вы или ваш собеседник перевозбужден или настроен агрессивно, понижайте голос и делайте ваше интонацию плавнее. Опыт переговорщика ФБР и наука утверждают, что это работает :)

- Исследование-1
- Исследование-2
- Исследование-3

Bullshit Chain
Обнаружил процесс, который адски замедляет работу, понижает мотивацию и ворует время. Не знаю, описывали ли его до меня (должны же были?) и как его называют. Если что, подскажите в комментах.

А суть вот в чем. Разработчику Васе дали Очень Важную Задачу, заметную даже на уровне компании. Он ее делает, но прозрачности выполнения не хватает.

Поэтому самый главный — пусть это будет СТО — пишет руководителю направления: что там, как прогресс по задаче?

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

Юнит-лид тоже не в курсе, потому что сфокусирован на другой задаче. Он отрывается от этой задачи и идет в тим-лида Васи.

Тим-лид Васи просит самого Васю раписать текущий статус. Вася вздыхает, откладывает задачу и пишет какой-то репорт.

От Васи цепочка поднимается вверх, пока не доходит до СТО. СТО читает статус, говорит "Огонь, но вообще-то я хотел узнать про сроки. Где сроки?", спрашивает СТО руководителя направления.

Руководитель направления вздыхает, и цепочка вновь отправляется вниз, сквозь все уровни, до Васи. А потом опять наверх.

В итоге, мы имеем несколько людей, которые потратили время, но ни на грамм не продвинулись в решении текущих задач. А уже пол-дня прошло. Если вам еще не страшно, представьте, что таких Bullshit Chain'ов по компании в моменте времени могут раскинуться сотни.

Методы борьбы с этим есть, что хорошо.

Вопрос к вам: называете ли вы такие цепочки коммуникации как-то или встречали ли вы их где-то в литературе? Или в реальной жизни? :)

О работе
Я часто слышу вокруг себя фразы "у меня нет времени на %вставьте сюда какой-то запрос%". Иногда даже произношу такую фразу сам. Ничего криминального я в этой фразе не вижу, говорить "нет" чему-то — куда важнее, чем говорить "да".

Но один эпизод из жизни римского императора заставил меня задуматься, а прав ли я.

Император Адриан (Рим, второй век) — третий из пяти "хороших" императоров — был вечно занят. Прошения, встречи, письма, снова прошения, переговоры, стратегии и реформы. Хорошо управлять — тяжелая работа, которая съедала все время Адриана.

Разумеется, Адриан отвечал "нет времени" на часть запросов. До одного события.

Однажды, Адриан посещал какую-то отдаленную провинцию. Когда император приезжал по улице, незнакомая бедная вдова попыталась передать ему прошение. Мы не знаем, о чем было прошение, но император ответил: "Нет. У меня нет времени."

И вдова выкрикнула вслед: "Тогда перестань быть императором!"

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

Менеджер, конечно, не император (хотя, не исключаю, есть люди и с таким самомнением). Но нам всем нужно помнить: мы согласились делать свою работу. И мы должны ее делать, какой бы сложной или нудной она не была.

Про "Проект Феникс"
Менеджерами не рождаются. А многие ими и не становятся, даже если по трудовой ими являются. Одна из причин — работу менеджера очень трудно описать словами.

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

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

Короче, начинающий менеджер не понимает, что от него хотят, и это — огромная проблема. Главное достоинство Проекта "Феникс" — он на примерах объясняет менеджеру, в чем его работа.

Книга построена как рассказ о менеджере в ИТ-компании, которая пытается запустить новый продукт, но сроки постоянно срываются. Знакомо? Герою предстоит решить проблемы сроков, нехватки ресурсов, планирования, инцидентов, узких горлышек и еще дофига всего.

Для примера, до сих пор со мной работает прекрасный тимлид, который на заре своей менеджерской карьеры на серьезном меня спрашивал "Олег, зачем мне вообще Джира? Приноси задачи я парням сам раздам". Я бы мог потратить недели встреч, чтобы объяснить человеку, зачем ему Джира, но вместо этого я порекомендовал ему прочитать Феникса и обсудить его через те же пару недель. Это стало нашей отправной точкой на пути правильного менеджмента.

Я до сих пор советую "Проект Феникс" всем менеджерам, от мала до велика. Это — фундамент, важность которого переоценить нельзя.