Фёдор Борщёв

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

«Самому не проще»: новый почтовый курс про делегирование

На курсе «Стать Тимлидом» больше всего тёплых отзывов получил урок о процессах в управлении командой. Странно, но мы с Марьяной были довольны им меньше других — хотелось переделать фабулу, добавить ещё больше текста и вообще всё нафиг переписать. Один из вопросов, которые хотелось осветить лучше — как правильно делегировать задачи коллегам.

Делегирование и постановка задач — больная тема. Ещё 10 лет назад всех уже тошнило от S.M.A.R.T. и условных «семи правил успешного делегирования». Мне, к примеру, хотелось, чтобы кто-нибудь рассказал, почему я так стесняюсь ставить коллегам задачи, и как сделать, чтобы команда делала порученную работу быстрее, чем я своими руками. Но везде были советы от копирайтеров, из серии «делегируйте полномочия вместе с ответственностью».

Даже банальная фраза «дай им обосраться», когда-то брошенная одним из наставников, помогла мне больше, чем все книги по управлению людьми.

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

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

3 письма, 1 q&a-сессия, старт 12 января. Стоит 6500 рублей. До конца этого года скидка 15% по промо-коду FBLOG1.

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

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

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

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

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

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

Курс «стать тимлидом»

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

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

В соавторстве с Марьяной Онысько, руководителем новых проектов в МИФе, я собрал целый курс о навыках тимлида который так и называется «Стать тимлидом». Марьяна классно разбирается в продуктах и имеет огромный опыт в МИФе, и вместе мы покажем ситуацию с обоих сторон баррикад — я буду говорить со стороны разработки, а Марьяна — со стороны бизнеса.

Наш курс будет полезен тем, кто только собирается стать тимлидом, и тем, кто уже работает тимлидом и хочет прокачать навыки. Занятия стартуют 26 октября и продлятся 5 недель. На каждой неделе вы будете получать лонгрид, домашнее задание, публичную q&a сессию, и одного (а иногда и двух) признанных в индустрии спикеров, помимо нас с Марьяной.

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

Всем читателям моего блога — скидка 15% по промокоду FEDORBLOG.

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

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

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

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

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

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

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

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

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

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

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