Мне надоело писать сюда теорию из книг. Канал у меня "Инженер и Менеджер" называется, а не "Пересказываем лучшие практики из разных книг". Поэтому теория менеджмента останется, по как отдельный тэг: #теория_менеджмента (логично). Плюс три новых тега: про технику, прочитанные книги и фан факты. Давайте начнем с последнего.

#fun_fact
Люди любят сбиваться в группы. Групповое поведение заложено у нас в генах: чтобы выжить, нашим предкам нужно было вместе охотиться, обмениваться корешками, торговать каменными топорами и вместе бить по шапке соседние племена. Если человека отторгала его группа, он помирал и проваливал естественный отбор, так что его гены дальше не шли.

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

Дано: группа людей разного цвета кожи, религиозных предпочтений, пола и вообще. Людей разделили на две группы, красные и синие. Потом всех людей развели по комнатам и предложили начислить условные баллы каждому участнику эксперимента. Баллы вообще ничего не значили, просто цифры.

Результаты поразили Генри: участники предпочитали ставить более высокие баллы членам своей группы! Не потребовалось ни идеологии группы, ни общих целей, вообще ничего. Чтобы люди ощутили себя группой и начали предпочитать своих (и дискриминировать чужих) надо было просто поделить их на две группы. Все.

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

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

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

Оригинальное исследование
Любимая цитата: It was found that, as soon as the notion of ‚group' was introduced into the situation, the subjects still discriminated against those assigned to another random category.

#articles
Про Постгрес
На собеседованиях люблю задавать вот такой вопрос:
> Представь, что в вашем Постгресе есть важная таблица с платежами. Как-то раз, к тебе приходит команда и говорит: дяденька, мы только что удалили половину платежей. Удаляли с помощью DELETE, прямо из консоли. Вопрос: что будешь делать?

Кто-то говорил "накачу дамп". Чуть более прошаренные спрашивают, есть ли реплика с отставанием. Но это все не то :) Совсем прошаренные люди по-другому. Как именно -- не скажу, мне ж еще этот вопрос на собеседовании задавать :) Но подскажу.

Чтобы так ответить правильно, неплохо было бы знать про MVCC, как Постгрес хранит данные и зачем вообще VACUUM нужен и какой он бывает. Изначально я хотел с вами поделиться списком статей на тему, но нашел на Хабре прекрасный цикл статей на русском. Вот он: https://habr.com/ru/company/postgrespro/blog/442804/.

Читать абсолютно точно стоит всем, кто использует ПГ. Тем более все на русском. Если осилите целиком, то я даже не знаю, как потом вас можно завалить по теории Постгреса на собеседовании. Никак, наверное. Автору серии низкий поклон, очень подробно получилось.

Про Кафку
Судя по реакциям, посты вида "вопросы с собеседований" вам зашли. Не вижу повода не продолжить :)

На прошлом месте работы мы втаскивали Кафку рядом с кроликом (RabbitMQ). Мне понравились гарантии доставки Кафки, возможность перечитать топик и философия pull'а сообщений. То есть Кролик буквально ЗАПИХИВАЕТ сообщения в потребителя, даже если в него -- потребителя -- уже откровенно ничего не лезет. Это все равно что в вас после хорошего обеда попытаются запихнуть еще один обед. Неприятно ведь. Кафка более обходительная и позволяет потребителю читать сообщения по мере доступности.

// А еще один коллега придумал шутку, которая меня до сих пор веселит. Когда кто-то говорил "Кафка", он быстро добавлял "грефневая". Не знаю как вам, мне было (и до сих пор) смешно :)

У нас в Сбермаркете мы Кафку тоже используем, и на собеседованиях любим про нее поговорить. Один из первых моих вопросов: "Расскажи плиз про гарантии доставки Кафки".

Вы подумали, что это простой вопрос?

Нет.

Многие люди, которые работали с Кафкой в продакшне, на него не отвечают. Оставим этот факт на их совести. Правильный ответ: at-least-once. То есть: Кафка гарантирует доставку МИНИМУМ один раз, но так же гарантирует, что может доставить сообщение повторно. Если вы не учли этот момент в проектировании системы, на высоких нагрузках у вас появится очень интересный способ проводить вечера в попытках найти баг в распределенной системе.

А еще я для вас нашел статью, в которой есть картиночки и есть заход в идемпотентность. И объясняет автор хорошо. Делюсь: https://medium.com/@andy.bryant/processing-guarantees-in-kafka-12dd2e30be0e

(Кстати, если вас вдруг недавно на собесе завалили или удивили каким-нибудь вопросом, можете написать в комменты или мне в телегу. Разберу вопрос и напишу пост в канал.)

P.S. Если совсем докопаться, правильный ответ "а какие настройки у брокера, потребителя и продьюсера?". Кафка может работать в нескольких режимах доставки, нужно смотреть настройки. Из коробки у нее почти at-least-once. Почему "почти" я расскажу, но в следующих постах, все в один не залезет.

Если вдруг не знали, какую БД выбрать для вашего нового сервиса или монолита, то я принес: https://www.amazingcto.com/postgres-for-everything/

#management
Хвалите публично, но помните о капуцинах

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

Проще всего мне будет объяснить на примере обезьян-капуцинов. Мордочку одной из них вы видите на фотографии выше. Так вот, ученые взяли двух обезьян и посадили в разные клетки. Клетки стояли недалеко друг от друга, так, чтобы обезьяны могли друг друга видеть. Внутри каждой клетки ученые поместили по кнопке.

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

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

Так что если вдруг надумаете хвалить кого-то публично, посмотрите по сторонам: возможно, кто-то с огурцом в руке смотрит на то, как вы кидаетесь виноградом в других за ту же работу.

Всем хорошего понедельника :)

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

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

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

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

Результат номер один: мозги двух крыс физически работали по-разному, на разной частоте. Мозг крысы, которая бежала самостоятельно, работал активнее, с бОльшей частотой, а значит — активнее. А ведь обе крысы совершали одно и то же действие, разница была только одна — первая крыса бежала сама, вторая вынуждена была бежать.

Результат номер два: эндокринная система двух крыс тоже работала по-разному. У второй крысы уровень гормонов стресса в крови был заметно выше. И это странно: так как колесо двигалось само, вторя крыса прилагала меньше усилий, но гормоны стресса у нее все равно были выше.

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

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

Все. Остальное выводы предлагаю сделать вам :) Хороших выходных!

Исследование

К прошлому посту в комментах насыпали вопросов. Вы спрашиваете — я отвечаю :)

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

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

Мотивация — это когда у человека есть причины делать задачу. Например, задача прокачает его скиллы, принесет пользу миру, ускорит работу проекта или просто принесет ценность компании. Так или иначе, задача находит отклик у человека и он делает ее.

Принуждение — это когда у человека есть только одна причина делать задачу: потому что ему так сказал руководитель.

Теперь к ответу. Иногда — очень редко! — принуждать допустимо, но лучше поискать варианты.

Например, вам нужно пройти ИБ аудит, и 10 ваших сервисов аудит завалят.

Вариант один
Вы можете прийти и сказать: "Через 5 дней я ожидаю, что вы пофиксите все уязвимости". Они даже не понимают, что это за уязвимости, но начинают их фиксить. Это — неоправданное принуждение.

Вариант два
Вы приходите, объясняете командам, что если они не исправят уязвимости, компания завалит аудит и всем сотрудникам будет грустно. Это — хорошая мотивация.

Вариант три
Вы приходите, объясняете последствия, но командам все равно. Для них ваши аргументы — не аргументы. Очевидно, проблема все еще в нас с вами: мы должны уметь мотивировать. В таком случае, вы говорите "Через 5 дней я ожидаю, что вы все пофиксите". Это — оправданное принуждение.

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

Негативная мотивация
Если спросить человека, что лучше: позитивная мотивация или негативная, большинство ответят однозначно — позитивная! Не согласен. Более того, сама постановка вопроса в корне неправильна.

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

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

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

Нейробиология о мотивации
Яак Панксепп, нейробилог, провел ряд экспериментов на тему мотивации и написал целую книгу -- Affective Neuroscience. Главным открытием стало разделение мотивации на две системы: вознаграждающую и наказывающую. За каждую из них отвечал свой участок мозга.

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

В теории, голодающая крыса будет рваться к сыру на пределе своих сил, но это не так!

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

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

Дайте знать, если вам интересна эта тематика.

Ссылочка на интервью

Подъехало видео с моего выступления на #TeamLeadConf2023 — https://www.youtube.com/watch?v=7HKJf7HGnTY

Если вам интересно узнать:
- Сколько компаний из Fortune-500 в 1955 году оттуда вылетели
- Как не надо внедрять ОКР в свою компанию
- Как связан шаблон для Golang в Сбермаркете и японский истребитель Zero
- И главное: что такое Теория Диффузии Инноваций

То кликайте по ссылке :) Говорят, получилось интересно и полезно.

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

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

Со временем я стал задавать такой вопрос все реже и реже, но важность получения информации меньше не стала.

Поэтому сегодня я хочу порекомендовать канал, который читаю сам — https://t.me/odgers_berndtson_russia. Пишут про менеджмент, последний пост про громких тружеников лично я переслал в несколько чатов :) Никаких лонгридов на час, все сжато, но информативно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда на собеседовании я спрашивал, "какого размера должна быть команда" у тим-/юнит-лида, я всегда получал ответ "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-х человек? Управляли ли вы такой? Как вам?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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