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

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

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

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

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

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

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

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

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

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

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

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

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

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

В общении с плохими программистами (а ещё строителями, водителями и сантехниками) часто проскакивает тон «нерешаемая задача»:

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

— Давай передавать данные о телефонных заказах в Гугль-аналитику? Это невозможно — мы для таких заказов не знаем ID аналитики :(

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

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

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

Будьте решателями проблем, а не создавателями.

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

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

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

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

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