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

Как сделать так, чтобы разработчики не завышали оценку задач?

⬅️ Совершите shift left
Прямо сейчас у нас в Циане я активнее сдвигаю разработку "влево" — то есть поближе в discovery. Это и есть shift left.

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

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

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

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

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

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

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

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

‼️ Выводы
- Совершите shift left — погрузитесь в продукт и фичи
- Создайте буфер — единый для всего проекта, а не несколько маленьких для каждой задачи
- Челленджите оценки — не стесняйтесь, но и борщить тут нельзя

Есть еще способы, но эти три — самые действенные для меня. А какие вы используете в своей работе?

Почему мы ВСЕГДА ошибаемся в сроках?
Ты когда-нибудь сталкивался с ситуацией, когда проект сорвал дедлайн, даже несмотря на все подстраховки? Это случается постоянно.

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

И вот тут начинается самое интересное.

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

Допустим, моя дорога до работы занимает 60 минут. Это если пробки средние и ничего не случилось.

Но если меня попросят дать оценку, я не скажу «60 минут». Почему? Потому что:
- Сильные пробки — +10 минут
- Перекрытие дорог — +10 минут

А если мне нужно назвать время, в которое я гарантированно уложусь? Тогда:
- Пробитое колесо — +20 минут
- Первый снег в Москве — +20 минут

В итоге выходит уже 120 минут — в два раза больше!

👨‍💻 Почему в IT-проектах происходит то же самое?
Когда мы оцениваем задачу в IT, мы тоже учитываем непредвиденные обстоятельства. Задача могла бы занять 4 дня? Добавляем подстраховку → получается 6 или 8 дней.

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

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

Но проблема не только в этом.

🤦 Как мы сами разбазариваем время?
Подстраховка почти никогда не используется по назначению. Как она расходуется?

- Задача занимает ВСЕ время, что на нее выделено — если дали 3 дня, но справились за 2, оставшийся день потратим на «полировку».
- Синдром студента — раз у нас много времени, мы не торопимся. Мы знаем, что успеем, так что откладываем до последнего (как с курсовыми).

Получается парадокс: подстраховка должна помогать нам укладываться в сроки, но она же и создает задержки!

🧨 Почему проект ВСЕ РАВНО опаздывает?
Мы завышаем оценки → проект становится длиннее, чем нужно.
Подстраховка почти всегда используется (но не по назначению).
И когда рано или поздно одна из задач начинается опаздывать, подстраховка из других задач ей не поможет. Опоздание ОДНОЙ задачи тянет за собой ВСЕ следующие.

Как итог, что бы мы ни делали, сроки все равно срываются. Знакомая ситуация, да?

Я специально не буду давать решение в этом посте.

Мне интересно:
❓ Согласны ли вы с тем, что мы всегда завышаем оценки?
❓ Как у вас принято бороться с этой проблемой?
❓ Оцениваете ли вы задачи без подстраховки?

А в следующем посте расскажу, как предлагает решать этот вопрос Элияху Голдратт.

// Если пост был полезен, поделитесь им — так вы помогаете развитию канала. Спасибо!

Чему нас могут научить автобусы
Бизнес всегда хочет, чтобы разработка поставляла фичи быстрее. И мы у себя в ИТ придумали процессы, скрам, CI/CD — кучу всего придумали, если честно.

Но сегодня я дам вам самый простой рецепт, как повысить ощущение скорости разработки для бизнеса. И помогут нам в этом... Автобусы!

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

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

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

Результаты удивили: пассажиры на остановках с дисплеем заявляли, что ждут автобуса примерно на 30% времени меньше, чем пассажиры на остановках без дисплея!

Еще раз: автобусов осталось ровно столько же. Ученые только добавили дисплей, на котором было видно, сколько еще осталось ждать. И это улучшило показатель на 30 процентов! Представьте, сколько автобусов нужно было бы вывести, чтобы достигнуть такого же результата? Сколько денег потратить — кошмар просто.

🚌 Автобусы помогают в ИТ
Думаю, вы уже догадались, куда я веду: контролируйте ожидания сроков своего заказчика. Не обещайте просто сделать задачу, озвучьте сроки и придерживайтесь их. А еще лучше: приведите в порядок вашу Джиру, чтобы бизнес сам мог видеть движение задач и знал, сколько ему еще ждать автобуса. В смысле, сколько еще ждать его фичи.

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

Инструменты, которые могут вам помочь:
- Дорожная карта, на которой отмечены важные даты проекта или его релизы
- Текстовые апдейты раз в неделю (или чаще), как двигается проект и как мы попадаем в сроки
- Заполненная Джира, в которой виден статус проекта и его задач

Я в Циан использую все три, кстати.

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

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

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

1️⃣ Уберите лишнее
Чтобы встречи были вам полезны, ходите только на полезные встречи. Отклоняйте ненужные или бесполезные для вас встречи.

Если сомневаетесь, спросите себя: на что конкретно вы меняете 30-60 минут своей жизни? Чтобы просто посидеть кустиком, потому что позвали, или вы внесете значимый вклад во встречу?

2️⃣ Слушайте и говорите
Если вы просидели молча всю встречу или постоянно смотрели мемы в соседней вкладке, поздравляю: вы только что растранжирили свое время одним из самых странных способов.

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

3️⃣ Записывайте
Я пользуюсь программой LogSeq, чего и вам советую. После каждой встречи у меня остается 5-10 поинтов исключительно для меня. Иногда я к ним обращаюсь, иногда — нет. Но пишу всегда.

Записи помогают мне сосредоточится, так что меня меньше тянет отвлекаться от того, что говорят люди на встрече.

4️⃣ Пишите агенду
Если я собираю новую встречу, я либо прикреплю агенду ко встрече, либо отправлю людям документ в мессенджер. Агенда помогает мне четче сформулировать мою цель для встречи и экономит время на введение.

5️⃣ Пишите план действий
В конце встречи определите, что каждый из участников сделает (или не сделает) по итогу встречи. Например, мы договорились, что Вася напишет архитектурное решение до среды. Обязательно должны быть конкретные действия. Если после встречи их нет, боюсь, встреча могла пройти впустую.

‼️ Итоги
Для меня каждая встреча — важное событие, по итогу которого я ожидаю каких-то изменений и действий. Неважно: это регулярный 1-1 или встреча по Event Storming'у, каждая встреча важна и нужна, а без нее будет хуже, чем с ней.

А как вы делаете ваши встречи эффективнее?

Как найти тему для выступления

Я часто пушу людей выступать на конференциях. Это полезно и для самого человека, и для карьеры.

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

Не. Выступайте. Для. Себя.

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

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

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

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

Если хотите копнуть тему подробнее, вот статья на Хабре. А еще, сегодня стартовал TeamLead Conf — вот каналы спикеров. Посмотрите и подпишитесь, если найдете для себя полезное 🙂

Доброго утра!

Я работаю по 60-80 часов в неделю и привык думать, что это еще норм. А работать сорок часов в неделю — вообще роскошь. Ведь раньше-то люди работали вообще без отдыха и выходных! Но так ли это? Мы с вами работаем где-то 2000 часов в год при рабочей неделе в 40 часов.

Давайте отмотаем время назад.

🛠 Индустриальная эпоха
В эпоху индустриализации люди на заводах работали по 12-16 часов каждый день, с редкими выходными. Тогдашние фабрики были филиалом ада на земле. В 19-ом веке в Британии человек мог работать 3000-3500 часов в год.

🧑‍🌾 Средневековье
А вот средневековый крестьянин работал значительно меньше нашего. В статье указаны вот такие цифры:
- 13-ый век — 1620 часов в год
- 14-ый век — 1440 часов в год

Это примерно на 500 часов меньше, чем работаем мы с вами. Это 12 недель или 3 месяца. Откуда такая разница?

- Праздники: если сложить все праздники того времени в Испании, получается пять месяцев в году. Неплохо!
- Перерывы в работе. Исследователи отмечают, что люди могли работать от рассвета до заката, но с перерывами: завтрак, послеобеденный сон (круто же?), ужин и различные перекусы.
- Сезонность: зимой ни сеять, ни жать нечего. Работать полный день или полную неделю не было смысла.

И я не спорю, что жить тогда было хуже: не было нормальной медицины, люди лечились то ртутью, то мышьяком (я не шучу). Болезни, чума — ужас.

Но работали при этом на 3 месяца меньше, чем мы с вами.

🦁 Первобытные племена
Думаете, это все? Нет, давайте-ка отмотаем время еще дальше, к нашим первобытным предкам и охотникам-собирателям. Они могли работать по 3 часа в неделю! Мужчина охотился неделю, а потом отдыхал еще две. Разные исследователи приводят разные цифры, но в среднем в те времена работали по 20 часов в неделю. В два раза меньше!

Роберт Сапольски жил рядом с таким племенем в Кении, и писал, что большую часть времени племя просто отдыхало и общалось. "Старики" вообще не работали ни одного часа в неделю. Стариком, кстати, считаются люди старше 25-30 лет. По меркам кенийцев, я уже старик.

‼️ Итоги
Прогресс принес нам много плюшек, это глупо отрицать. Но отрицать регресс тоже неправильно:
- Мы стали работать больше.
- Мы меньше общаемся с другими людьми вне работы, поддерживаем ограниченное количество социальных контактов.
- Мы сильно потеряли во взаимопомощи. В первобытном племени сплоченность была на совершенно ином уровне, чем в нашем развитом обществе.

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

А что вы думаете? Раньше действительно было лучше? :)

3 признака плохого лидера

Джоко Виллинк — бывший морской котик, Navy SEAL называется. Это очень элитное подзразделение, на их обучение и тренировки США тратит невероятное количество бабла. Особенное внимание уделяется лидерству.

Виллинк — как раз лидер, который командовал несколькими отрядами. После отставки он написал книгу "Extreme Ownership", где описал концепт экстремальной ответственности, который теперь применяют менеджеры во многих ИТ компаниях.

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

Согласитесь: дружественный огонь — это совсем не по-дружески!

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

Вот какие признаки плохого лидера определяет Виллинк.

1️⃣ Рычит на своих людей
Виллинк употребляет термин "bark orders" — когда вместо спокойного тона, вы бувально рычите на своих людей.

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

В мире ИТ я знаю руководителей, которые так себя ведут. Их не любят.

2️⃣ Не доносит конечную цель
Рычать на людей приходится из-за того, что плохой лидер не донес до них конечную цель. Если бойцы не знают, как должен выглядеть итоговый результат, они теряются и лидеру приходится рычать.

В ИТ это частая история. Приходит руководитель, очень смутно описывает что надо сделать и уходит. Приходит через пару недель и понимает, что результат вообще не соответствует его ожиданиям. Что он начинает делать? Он начинает гавкать на сотрудников!

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

3️⃣ Не создает правильных прецедентов
Допустим, ваш сотрудник на общей встрече предложил решение проблемы. Плохое решение. Очевидно плохое, потому что вы готовы по полочкам разложить, почему он не прав.

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

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

Хороший лидер создает хорошие прецеденты. Плохой — плохие.

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

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

Что скажете? Согласны с Виллинком, или его армейские принципы в ИТ неприменимы? Расскажите в комментариях :)

Шестой порок команды
Патрик Ленсиони в книге "Пять Пороков Команды" описывает эти самые пороки:
- Недоверие
- Боязнь конфликта
- Безответственность
- Нетребовательность
- Безразличие к результатам

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

Я обнаружил шестой порок: необоснованная эскалация.

❓Что это такое?
Необоснованная эскалация — это когда вместо того, чтобы разобраться в ситуации и решить проблему самостоятельно, проблема эскалируется руководителю, руководитель обращается к другому руководителю, вместе они спускаются к проблеме и пытаются ее решить.

Звучит сложно, поэтому давайте на примерах.

📁 Пример
Разработчик Вася считает, что все API должно быть исключительно RESTful. По шагам:
- Вася пришел в сервис соседней команды и запилил новую ручку.
- Соседняя команда в ходе ревью кода сказала Васе, что у них так не принято и API надо писать по-другому.
- Вася ответил, что RESTful — это лучшая практика, и он не понимает, почему это плохо и надо переписать.
- Соседняя команда вместо разговора с Васей обращается к своему тимлиду с просьбой разобраться.
- Тимлид идет к своему юнит-лиду.
- Их юнит-лид идет к юнит-лиду Васи.
- Юнит-лид Васи идет к тимлиду Васи.
- Тимлид Васи идет к Васе и говорит, что не надо так делать, лучше переписать по правилам команды.

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

❌ Почему необоснованная эскалация — это порок
- Убивает инициативность в людях. Человек видит, что его действия приводят к эскалации, в ходе которой проблему решает не он. Это ведет к выученной беспомощности: зачем вообще проявлять инициативу, если она ни к чему не ведет?
- Мешает росту лидеров. Если необоснованная эскалация стала стандартом, вырастить настоящего лидера в подобных условиях не получится.
- Крадет время. Для решения одной проблемы задействуются сразу несколько руководителей. Если необоснованная эскалация – регулярная практика, то руководители постоянно заняты решением этих эскалация вместо улучшения работы команд.

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

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

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

Кто такие Навигаторы и почему они вам нужны
Кому читать: руководителям и инженерам, которые хотят вырасти дальше сеньора.

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

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

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

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

Читайте и пробуйте внедрить Навигаторов у себя — или подумайте, как вам самим стать Навигатором. Роль интересная, очень востребованная на рынке. А еще название прикольное.

Инцидент коммандер: как стать человеком, у которого есть план (даже если его нет)
Кому читать: всем, кто спасти мир — в смысле, компанию

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

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

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

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

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

Хотите узнать, как примерить на себя геройский плащ? Читайте! Этому городу нужен новый герой.

Вы понимаете роль Product Owner'а неправильно
Кому читать: всем, кто работает с продакт овнерами

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

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

Статья предлагает по-новому построить ваши отношения с продуктом: узнайте своих клиентов, поймите данные, которые стоят за гипотезами продакта.

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

Семь типов руководителей, которыми вы не хотите стать

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

🎯 Борис-хрен-попадешь
Любой свой косяк скидывает на команду. Упал прод? Это тестировщики виноваты, плохо протестировали. Сроки поехали? Это разработка долго кодит. Фича не принесла денег? Очевидно, аналитики плохо посчитали. Если же что-то получается, забирает все лавры себе. Действует по проверенной веками схеме: успех мой, провалы — командные.

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

🪄 Алиса в стране чудес
Не очень понимает реалии системы, которой он управляет. С удивлением может обнаружить, что ключевой сотрудник ушел в отпуск неделю назад. Может не знать точный состав команд. Совершенно точно не знает архитектуру своего участка системы. Теряется, если его спрашивают о текущем положении дел или про нюансы работы его сервисов. В случае, если его непонимание реалий приводит к проблемам, может превратиться в Чайку или Бориса-хрен-попадешь.

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

🥒 Садовод
Ни за что не пустит вас в свою зону ответственности, потому что это — только его сад. Решения внутри сада принимаются только и только самим Садоводом. Вся коммуникация только через него. Его отдел — это компания в компании, часто со своими практиками и решениями. После ухода садовника, выясняется много интересных деталей, которые часто ведут к рефакторингу архитектуры и реорганизации всего садика.

🖨 Ксерокс
Обожает подсматривать процессы и практики из успешных компаний и приносить их к себе. Как правило, после очередной прочитанной статьи или книги, Ксерокс решает: так дальше жить нельзя! Поэтому в понедельник он приходит и объявляет, что теперь все будут жить по-новому. Например, нужно создать гильдии, потому что на выходных он прочитал про Спотифай и теперь уверен, что гильдии это маст хэв. Зачем — неясно, как внедрять — непонятно, но решение принято! Ядерная смесь получается при совмещении с Алисой в стране чудес: человек не совсем понимает, что вообще вокруг происходит, но тащит из книг все новые и новые практики.

🦄 One trick pony
Не могу перевести на русский, но это человек, который из раза в раз повторяет один и тот же прием. Как цирковой пони, который умеет выполнять только один трюк, такой руководитель продолжает использовать для решения новых проблем одни и те же подходы. Главный аргумент — я так уже делал в прошлых компаниях, и это работало. Разница в контекстах не учитывается, а оппоненты давятся опытом. Хорошо совмещается вместе с Борисом-хрен-попадешь: когда старые решения перестают работать, виноваты будут все, кроме менеджера!

Вот такой список получится. Узнали кого-то? Напишите в комментариях, доводилось ли вам видеть таких руководителей :)

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

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

А если соберетесь и напишите Цепочку Ценности или Матрицу БКГ, обязательно поделитесь этой новостью в комментариях :)

Что происходит, когда ИТ и бизнес не поняли друг друга

1️⃣ Элитные инженеры
Представьте: вы — сотрудник самого секретного ИТ-отдела в стране. Само ваше существование это тайна, а от ваших действий зависят судьбы сотен тысяч людей. Каждый из вас прошел самый тщательный отбор. Вы лучшие инженеры, математики и технари своей страны. Элита из элит, creme de la creme.

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

Итак, именно такими ИТшниками были сотрудники Комнаты №40 — секретного отдела Британии. Комната №40 занималась дешифровкой немецких радио-сообщений во время Первой Мировой. Они перехватывали сообщения, ломали шифр и передавали информацию флотским адмиралам.

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

Система несложная: если адмирал в бухте, DK — его кодовое имя. Если не в бухте, то DK становился кодовым именем маяка.

2️⃣ История одной ошибки
30-го Мая Комната №40 начинает перехватывать тревожные сигналы: 3-ая немецкая эскадра покинула бухту. Это 5 линкоров, бронированных монстров с пушками больше 300мм. Даже один линкор — огромная угроза, а тут пять!

31-го Мая бухту покидает 1-ая и 2-ая эскадры. То есть, все линкоры немецкого флота вышли в море. Очевидно, не просто так погулять вышли. Судя по радиоперехвату, адмирал Шеер тоже вышел в море, потому что кодовое имя DK было переназначено на маяк.

Вывод лишь один: немцы готовятся дать генеральное сражение.

Адмиралтейство посылает запрос в Комнату №40: «Где находится DK?». Конечно, адмиралам было интересно текущее расположение немецкого флота.

Однако, в Комнате №40 сидели люди со строго инженерным мышлением. Кодовое имя DK на момент запроса было прикреплено к маяку, а маяк не отличается особой мобильностью. Строго говоря, маяк вообще не двигается за неимением двигателей.

Поэтому Комната №40 ответила, что DK находится в бухте. Адмиралов ответ устроил и они продолжили действовать исходя из вводной, что немецкий флот никуда не вышел.

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

И все из-за того, что разработка неправильно поняла бизнес… В смысле, инженеры не поняли адмиралтейство.

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

В следующей серии постов я расскажу, как наладить взаимодействие ИТ и продукта.

Кстати, а в вашей истории было что-то похожее?

Как по-настоящему решать проблемы
Есть четыре пути решения проблемы: absolve, resolve, solve, dissolve. Давайте представим себе голодного человека и постараемся решить его проблему с помощью всех четырех инструментов:
- Absolve — сделать вид, что проблемы нет. Самое простое решение: мы взаимодействуем с проблемой путем бездействия! Красиво?
- Resolve — частичное решение: вернуть систему назад к рабочему состоянию. Мы даем человеку рыбу и возвращаем систему к "рабочему" состоянию, человек сыт. Но это не решает проблему целиком!
- Solve — оптимальное решение: не просто вернуть систему в рабочее состояние, но обеспечить стабильность решения: мы выдаем человеку рыбу каждый день. Проблема решена навсегда, ведь человек будет сыт каждый день, верно? Не совсем: это не системное решение, это костыль. Ключевое здесь вот что: мы не поменяли систему, мы просто решили проблему.
- Dissolve — ликвидация проблемы и перестройка системы таким образом, что в будущем она не сможет возникнуть ни при каких условиях: мы даем человеку удочку и учим рыбачить. Проблема решена навсегда.

Абстрактно и непонятно, понимаю. Позвольте мне развернуть идею.

Перенесем пример на ИТ. Представьте: в результате инцидента сервис деградировал на час и компания понесла убыток в десяток миллионов рублей. Инцидент устранили и теперь все работает нормально. Поехали!

I — Absolve
Инцидент устранен, бизнес работает, деньги капают. Ну упали и упали, надо дальше двигаться.

Итог: никаких действий не предприняли. Вопрос времени, когда инцидент повторится.

II — Resolve
Фиксим баг в коде, который привел к падению.

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

III — Solve
Фиксим баг и пишем тесты. Кажется, что решение системное. Но нет: вы не застрахованы, что ваш код сломается в другом месте, где тестов нет. Покрыть весь код тестами? Даже если у вас получится, вы потратите тонну времени.

Итог: мы вернули систему в стабильное состояние плюс обеспечили продолжительность нашего решения, больше в этом месте ничего не сломается. А в других — может сломаться.

IV — Dissolve
Проводим post mortem, на котором разбираем причину возникновения бага. Допустим, разработчик не успел дописать тесты, потому что у него слишком много горящих задач.

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

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

Что дальше
Это хорошая система для измерения себя как руководителя. Я думаю, хороший менеджер стремится решать проблемы с помощью dissolve: таким образом, проблем будет возникать все меньше и меньше.

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

Проблему редко можно решить там, где она проявилась — ищите, где она появилась.

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

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

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

Сравнить команды
Разные команды могут оценить одну и ту же задачу по-разному. Это не означает, что одна команда слабее другой. Стори поинты родились из концепции "идеального дня" — без созвонов и прерываний.

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

Для сравнения команд стори поинты не подходят.

Сравнить сроки
Если вы оценили задачу в стори поинтах, нужно в итоге сравнить реальные сроки выполнения и изначальную оценку, ведь так? Если оценка и реальность разошлись, нужно провести ретроспективу, понять причины и начать оценивать лучше?

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

Так что стори поинты и тут бесполезны.

Давить на команду
В красной книге SCRUM сказано, что количество стори поинтов, которые команда берет в спринт, должно постоянно расти от спринта к спринту. Такой подход приведет к майндсету "количество важнее, чем качество" — разработка начнет срезать углы и копить технический долг, а QA начнут пропускать баги.

Это как постоянно сжимать пружину в погоне за количеством. Рано или поздно, пружина разожмется и, может быть, попадет кому-то в лоб.

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

Стори поинты хороши для давления на команду, но само давление — плохая идея.

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

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

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

Менеджеры не нужны!
Именно так подумал Ларри Пейдж, СЕО Google в 2001-ом году и кикнул всех менеджеров их компании. Пейджа не устраивала скорость разработки. Мотивация у Пейджа была такая:
- Гугл нанимает лучших инженеров, у которых все ок с мотивацией
- Лучшие инженеры сами могут решать, что им делать и как держать дедлайны
- Менеджеры гораздо слабее в технике, чем инженеры, и поэтому не могут руководить инженерами
- Менеджеры отвлекают инженеров от задач своими глупыми активностями

Сказано — сделано, и в компании Google не остается ни одного менеджера. Все 130 инженеров компании теперь репортят одному вице-президенту, Вейну Розингу. Менеджеры, кстати, офигели — никто их заранее не предупредил. Их просто собрали вместе и сообщили новость, что они больше не нужны.

Прекрасная жизнь без менеджмента
Когда инженеров оставили без менеджеров, произошло вот что:

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

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

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

- Задачи не делались. Инженеры любят интересную работу, а неинтересную работы мы не любим и предпочитаем делать ее когда-нибудь потом. Без участия менеджмента, инженеры брались только за те задачи, которые хотели. Скучные, но нужные задачи, просто пылились в самом низу бэклога.

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

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

Менеджеров пришлось нанимать обратно спустя некоторое время. Эксперимент признали неудачным и вернули все как было.

Мыши предсказывают вероятности лучше людей
Разум — наш самый главный инструмент, но порой он становится нашей главной слабостью. Например, самые обычные мыши могут справиться с задачей на вероятность лучше людей. Не верите? Читайте дальше :)

Эксперимент
Для исследования ученые взяли мышей и дали им на выбор две кнопки: зеленую и красную. После нажатия на одну из кнопок, следовала пауза, после которой одна из кнопок подсвечивалась. Зеленая светилась в 80% случаев, красная — в 20%. Если мышь угадывала, какая кнопка загорится, и нажимала на нее, ей давали кусочек сыра. Если не угадывала, ее били током.

Мыши достаточно быстро принимали правила игры и просто постоянно нажимали на зеленую кнопку. Таким образом, процент угадывания мышей стремился к 80%.

После мышей, такой же эксперимент провели на людях. Людям озвучили, что зеленая кнопка загорается в 80% случаев. Но испытуемые человеки постоянно пытались угадать, какая кнопка загорится следующей, и это дало средний процент успеха в 68%.

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

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

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

Что делать?
Я описывал в своем посте "игру победителя" и что не всегда стоит пытаться переиграть события. Порой лучше поверить в вероятность и выбрать стратегию, которая по-настоящему минимизирует риски.

Секреты small talk'а
Как познакомиться и завести разговор с незнакомым человеком, например, на конференции или корпоративе? Такие непринужденные разговоры называются small talk, у них нет конкретной задачи, просто знакомство с человеком.

И ведь small talk на самом деле — нифига не small. Это большая, важная часть постройки вашей карьеры, потому что полезные контакты забустят вас как ни что другое.

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

Мэтт Абрамс ответил на все эти вопросы в видосе, а вам я принес краткую выжимку.

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

На этом все! Поделитесь вашими лайфхаками для small talk'ов? Нам всем интересно :)

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

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

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

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

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

❓ Как увидеть на интервью
Задать вопросы вида:
- "Расскажи про свой самый большой провал. Что привело тебя к нему?" — максимально лобовой вопрос. Если виноваты вообще все, кроме самого человека это повод копнуть глубже, но не делайте выводы лишь на основании одного ответа!
- Спросите про случаи, когда не удалось выстроить отношения с другой командой или человеком. Если соискатель обвиняет лишь другую сторону, это не здорово. Часто в проваленной коммуникации виноваты обе стороны, здорово, если соискатель подсветит эти моменты.

⬇️ Обратная сторона
Люди с внутренним локусом любят загоняться там, где не надо. Иногда ситуация действительно диктует условия, с которыми можно только смириться. Но внутренний локус — это не отключаемая фича и за провалы такие люди съедают себя очень сурово.

Как считаете, какой локус превалирует у вас?

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

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

👀 Как увидеть на интервью
- Спросите про задачи с самыми туманными требованиями и послушайте ответ. Не пугайтесь, если туманные требования соискателю не понравились — это не красный флаг, это нормально. Важно то, как он обработал эти туманные требования.
- Узнайте, как часто ему приходилось общаться к людьми не из своего отдела. В идеале, если это были люди даже не из ИТ, как можно ближе к бизнесу. Самонаводимые люди неизбежно контактируют с бизнесом.
- Задайте вопрос "расскажи мне про самую долгую задачу". Здесь важно узнать, насколько человек контролировал расплывшуюся по времени задачу и не забил ли он на нее.

⬇️ Обратная сторона
Чем выше самонаводимость, тем выше соблазн забить на формулировку задачи и просто говорить человеку "сделай хорошо, чо ты". Во-первых, это может демотивировать человека. Во-вторых, результат может в корне отличаться от того, что вы изначально ожидали.

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

Как понять на собеседовании, что чувак крутой и его надо брать?

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

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

Но помните: идеального метода собеседования не существуют, ошибки найма будут всегда. Учитесь на них.

А первый признак крутого чувака это...

🧑🏼‍💻 Ему не пофигу на работу
Самое ценное качество в специалисте.

Это те люди, которые не закроют ноутбук, пока не пофиксят этот плавающий баг. Они будут повышать coverage тестов в чужом коде и следуют правилу "оставляй код чище, чем он был до тебя". Скорее всего, вам придется уговаривать их прекратить овертаймить, потому что оно того не стоит. Если нашли такого — удерживайте всеми силами и следите, чтобы не выгорел.

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

👀 Как увидеть на интервью
- Спросите, какие проблемы у него были на прошлом месте и как они решились. Именно решились — если кандидат рассказывает как его проблемы решали другие люди, это не тот случай. Если вы спросите "как решал", это зафреймит вопрос не в ту сторону. Наш кандидат решал свои проблемы самостоятельно и проактивно.
- Узнайте, влиял ли кандидат на бэклог команды. Проактивные чуваки сами наполняют бэклог найденным техдолгом.

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

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

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

Двухфакторная теория мотивации Герцберга

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

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

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

Вопрос: какая компания сделала правильный выбор?
Ответ: обе ошибаются.

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

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

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

Философское.

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

Если да, у меня для вас есть ответ. Точнее, не у меня, а у Фридриха Ницше.

Сила нападающего имеет в противнике, который ему нужен, своего рода меру, всякое возрастание проявляется в искании более сильного противника — или проблемы: ибо философ, который воинствен, вызывает и проблемы на поединок. Задача не в том, чтобы победить вообще сопротивление, но преодолеть такое сопротивление, на которое нужно затратить всю свою силу, ловкость и умение владеть оружием, — равного противника…

Давайте расшифруем мысль философа по пунктам:
- Сложные вызовы — мерило вас как специалиста. Чем сложнее вызов, чем больше он вас пугает, тем лучше.
- Лишь самый сложный, самый страшный вызов заставит вас выложиться полностью и узнать свои возможности.
- Если вы избегаете сложных вызовов, вы никогда не узнаете, где же ваш предел.
- Единственный способ роста — постоянный поиск противника, который пугает вас, который заставляет вас усомниться в своих силах.

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

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

Так что же делать, если перед вами стоит задача или направление, с которым вы боитесь не справиться?

Нужно пробовать. Это единственно верный ответ. Либо вы справитесь и станете лучшей версией себя, либо узнаете пределы своих возможностей. Ведь если вы завершите карьеру, так и не узнав своей максимум — разве это не будет разочарованием?

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

1️⃣ Первое, оно же главное — руководитель гораздо чаще хочет "стать друзьями" с подчиненными, чтобы насыпать им в панамку побольше работы. В ИТ реже, вне ИТ чаще бывает такое, что руководитель "лезет под кожу" подчиненным, пытается сойти за своего парня, чтобы получить больше возможности для манипуляций. Я пока еще ни одного руководителя не видел, которым подчиненные манипулировали.

2️⃣ Второе: если вы наняли людей, которые пользуются чужой добротой, вам надо учиться нанимать людей. Причем без разницы, эксплуатируют вашу доброту или чужую, таких нанимать не нужно, таких нужно увольнять. Вообще, нужно постараться, чтобы таких нанять.

3️⃣ Третье: реципрокность. Это очень, очень мощный механизм внутри каждого из нас, который на любую оказанную нам услугу требует у нас оказать услугу в ответ. Если механизм сломан, это сигнализирует об отклонениях, например — социопатии. Если руководитель оказывает услугу сотруднику, сотрудник окажет ее в ответ в 9 случаях из 10.

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

Моя история успеха — это как раз хороший коллектив друзей (friend'ов, если быть точным). Я стараюсь делать максимум для команды, а команда отвечает тем же. Если я вдруг прошу человека выйти за пределы нормы и сделать задачу к сроку, он мне не откажет. Правда, и прошу я таком совсем-совсем редко :)

Если хотите крутую команду, вам придется с ней дружить — в той или иной степени. Не в нашем обыденном понимании, а скорее в американском, когда friend'ом называют человека после пары месяцев общения.

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

Про лидера

Помните, мы с вами говорили про Тоётоми Хидэеси? Давайте продолжим.

Тоётоми получил задачу: ускорить ремонт одного из замков на границе. Шла война, так что огромная дыра в стене замка была не очень кстати. Сроки по ремонту были неоднократно сорваны, так что Тоётоми должен был заменить начальника и починить стену за три дня.

Тоётоми прибыл на место и приуныл: ремонт стены шел отвратительно. Люди работали неохотно, и с таким темпом ремонт не удалось бы закончить ни за три дня, ни даже за неделю. Начальник постоянно кричал и бил рабочих, но ремонт быстрее не шел и начальник валил все провалы на подчиненных.

Классика! Ситуация знакома любому менеджеру: тебе достался проект с горящими сроками и команда, которая уже давно опустила руки и открыла резюме для поиска работы. Типичный начальник попробует:
❌ Кричать громче и "бить" людей сильнее. Такие "руководители" быстро теряют людей, ломают коллектив и дальше наперегонки: либо успеют уволиться ПСЖ, либо их выкинут за провал.
❌ Увольнять людей за низкий уровень продуктивности, а вышестоящему руководству говорить, что виновата команда. Рано или поздно такого "руководителя" и самого уволят, но вреда он наделает много.
❌ "Прошаренные" постараются залить проект людьми. Это не сработает, говорит нам закон Брукса.

Ничего из перечисленного настоящий лидер не сделает.

Для начала Тоётоми собрал всех и... Забухал. Я серьезно: он повелел выкатить почти рисовой водки, риса и прочей самурайской еды. Все это творческий коллектив употребил под хохот и веселье, после чего ушел спать.

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

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

Рабочие с под руководством лидера уложились в срок, получили награду, а Тоётоми — признание Оды Нобунаги.

Я вижу здесь три главных вывода:
✔️ Начальник просто ставит цель. Лидер обеспечивает результат.
✔️ Начальник требует невозможного. Лидер не требует ничего, чего не сделал бы сам.
✔️ Мораль коллектива прежде всего. Я не видел ни одного слаженного коллектива, которые завалил бы задачу. Я не видел блестящих результатов от разваленной команды.

Привет!

Мы тут вернулись с новым выпуском, теперь — в формате шоу! Обсуждаем собеседования, красные флаги кандидатов и компаний, играем в игры. Задаем вопросы нашей гостье, которая хантит СТО, где еще есть такой контент?)

В конце бонус от меня: история найма от Древнего Рима до наших дней.

https://youtu.be/jgRZ-wI50xs?si=i-G3qAhdFh6i698J

Буду рад обратной связи :)

Смешной мем, подумали вы? Реальность для тысяч IT-шников, отвечу я. Если для вас это тоже жиза, читайте дальше.

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

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

То есть: меня не хотели уволить. Меня хотели удерживать! Как так получилось?

❓ Почему мы думаем, что нас завтра уволят
Потому что не можем объективно оценить реальность из-за следующих причин:
- Высокие требования к себе. Я вижу каждую свою ошибку и вижу результаты своей работы. Они не идеальны.
- Синдром самозванца, когда нам кажется, что нас по ошибке взяли на нашу роль.
- Видимый (лишь видимый!) успешный успех коллег вокруг вас. Их провалы вы не видите, поэтому вам кажется, что вся их работа — это успех.

Плохие новости: у вас не получится снизить требования к себе (пробовал, знаю) и от синдрома самозванца избавиться не выйдет.

Еще хуже: подобные мысли вызывают хронический стресс и кучу адовых проблем со здоровьем. Так что же делать?

💡 Объективно оценить реальность
Самый верный способ избавиться от мысли про "я плохой, меня уволят" — поговорить с вашим руководителем. Опытный руководитель сам донесет до вас удовлетворенность вашей работой, но если вдруг не доносит, спросите сами!

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

Идеальное время для такого вопроса — ваш 1-1 с руководителем. У меня в командах принято ставить 1-1 регулярно, один раз в одну-две недели, в зависимости от ситуации. Если у вас нет 1-1 с руководителем, это — само по себе проблема. Попросите его поставить такую встречу.

P.S. Если вы решили проблему как-то по-другому, напишите. Мне правда интересно.