Фёдор Борщёв

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

Третий поток «Стать Тимлидом»

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

Что толку, если ты джедай кубернетиса и тераформа, но не можешь договориться с менеджером о 30-минутном перерыве для миграции на новые технологии? Нафига знать KISS, DRY, SOLID и паттерны проектирования, если ты не умеешь соблюдать дедлайны и защищать свои решения на код-ревью?

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

Самое главное в работе программиста — это решать задачи бизнеса в адекватные сроки. Все остальные навыки присоединятся быстро — было бы желание и умение направлять силы в нужную сторону. А пишу я это всё потому, что в Школе открывается набор на третий поток Стать Тимлидом — курса про софт-скиллы, нужные всем программистам. За два предыдущих потока мы с Марьяной обучили больше 250 учеников, получили классные отзывы и доработали контент по итогам неклассных.

В курсе будет 5 лонгридов, 5 живых q&a-сессий со мной и Марьяной, 8 записей ланчтаймов с интересными спикерами, а так же куча практики и рефлексии. Говорим о переговорах, управлении командой, найме, продуктах и техдолге: все материалы направлены на инженеров, но не привязаны к конкретным технологиям.


До вечера понедельника действует скидка 10% по промокоду RED10

Инициировать, а не реагировать

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

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

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

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

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

Люди любят слабые решения

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

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

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

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

Бирюзовое доверие

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

Бирюзовое доверие

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

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

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

Нерешаемая задача

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

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

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

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

Нерешаемая задача

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

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

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