Фёдор Борщёв

Инфостиль в заголовках задач

Я не сильно докапываюсь к чистоте текста в задачах и служебной переписке: конечно клёво, когда люди пишут понятно, но не всем нужно это учить: нафига какому-нибудь руководителю логистической службы писать тексты на 8 баллов главреда? Главное, чтобы он мог хоть как-то сформулировать сигнал, что болит — а дальше придут опытные продакты/проджекты и всё выяснят.

Но есть одно место, где я жёстко включаю Ильяхова — это заголовки задач в трекере. Насколько вы бы захотели работать в команде, которая целый день занимается какой-нибудь «необходимостью реализовать новый механизм построения отчётности» и, чтобы не произносить это дерьмо в слух, называет задачи по номерам (типа «Как там задача 1238?»). Я — не хотел бы.

Вот четыре правила для заголовков задач, которые помогут не превращать трекер в бухгалтерский отчёт:

  • Из заголовка чётко понятно, что нужно сделать. Не «доработать логику корзины», а «Сделать, чтобы при удалении последнего товара корзина очищалась».
  • Никакой воды: смело рубить всякие «необходимо реализовать» и «отсутствие возможности».
  • В заголовке есть понятные для всей команды ключевые слова. Если задача про вкладку Логистика, то так и писать «логистика», а не «интерфейс менеджера до доставке».
  • Если задача мало декомпозирована («привести в порядок учёт зарплаты») то заголовок должен описывать следующий понятный шаг, к примеру «Понять, почему заказ 100500 не пробросился в 1с» или «сделать кнопку «не согласен с расчётом».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какую я добавил ценность?

Хороший менеджер задаёт этот вопрос во время каждой своей активности.

  • Какую ценность я добавил, когда сходил на встречу? Был ли полезен, принёс что-то новое или тупил в фейсбук?
  • Какую ценность я добавил, когда ответил на письмо? Легче ли стало совершить следующий шаг по проекту?
  • Какую ценность я добавил, когда поговорил с программистом? Стало ли ему понятнее, что и как делать на проекте?
  • Какую ценность я добавил за неделю руководства отделом? А за месяц?

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