Заметки с тегом «Софтскиллы»

Гениальный совет, который когда-то подсмотрел у Николая Товеровского — чтобы не опаздывать на офлайновые встречи (люди, бывает, разговаривают лично), можно приезжать сильно заранее — не на 15 минут, а на час или даже два. Время ожидания не пропадает — всегда найдутся дела, которые можно поделать из любого места: пописать код, поотвечать на письма, навести порядок в проекте.

Для меня этот совет — про спокойствие. В ежедневной рутине запаренному мозгу сложно переходить от одного дела без дедлайна (пишу код, пока не напишу) к делу с дедлайном (в 15:00 встреча). Боишься не успеть: оставить репозиторий с падающими тестами, а список дел — с непоставленной галочкой. Чем ближе ко времени выхода, тем важнее незавершённость: кажется, что я если прямо сейчас не допишу этот код или не удалю эти два письма из инбокса, то небо упадёт на землю. У вас, уверен, получше, но но неприятный выбор, — доделать дело или опоздать — есть у всех.

Если на встречу, запланированную в 15:00 приехать в 13:00, острота выбора снимается — даже если вы чуть-чуть задержитесь и приедете в 13:15, никто не заметит разницы. Время с 13:15 до 15:00 тоже не пропадёт — поделаете рутинные дела. Если вы интроверт, как я, то ещё и настроитесь спокойно на встречу, сделав обстановку комфортной — удобно поставите ноутбук. привыкните к креслу, выпьете кофе.

Пользуюсь этим советом уже несколько лет, иногда даже встречаю коллег по лайфхаку — это когда договорился встретиться в кофейне в 20:00, приходишь туда в 18:30, а тебя уже ждут.

Меня пугают большие амбициозные цели. Я могу согласиться пару раз в неделю ходить в спортзал, но вряд ли смогу когда-нибудь «подтянуть мышечный каркас» или «стать здоровым/накачанным». Со второй целью, всякий раз, когда я пропущу спортзал (а такое рано или поздно случится даже если я — биоробот), я начну думать: «а накачаю ли я теперь мышцы? А не потерял ли я в результате?». Это тяжело.

Имея простую нестрашную цель «ходить в зал несколько раз в неделю», я пропускаю спортзал гораздо спокойнее — никто же не умрёт, если я на этой неделе схожу не три раза, а два или даже один раз?

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

Может и вам поможет? Если часто не достигаете больших целей, попробуйте ставить маленькие цели на процесс, а не большие цели на результат, мне помогает.

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

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

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

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

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

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

Обычно источник таких решений (не важно, принятых явно или нет) — достаточно банальный: у ответственного дома собака с ипотекой и вообще сегодня пятница. А зачем делать острые и конфликтные вещи, когда можно делать тихие и посредственные? Авось всё само потом рассосётся. И, бывает, рассасывается же.

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

За это умение руководители и берут деньги.

Возьмём типичную проблему — допустим есть бизнес, у которого разработка периодически ломает прод. Если решать эту проблему классическим способом, как решали раньше на заводах, то вы просто построите ОТК: отдельный этап тестирования, жёсткие правила для код-ревью, чтобы без одобрения двух коллег нельзя было выкатывать. Как настоящий кризисный менеджер, вы придумаете какой-нибудь солидно звучащий KPI для программистов, вроде количества автотестов. Только вот прод реже ломаться не начнёт.

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

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

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