Фёдор Борщёв

QA не должны искать ошибки

Многие программисты почему-то рассчитывают на QA как на «тестировщиков» — чуваков, которым можно отдать задачу, а они проверят, сделал ты её или нет. Делать так нельзя.

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

Во-вторых, это трата времени людей. Я говорю не об автоматических e2e-тестах на регресс, а о банальных интеграционных тестах. Какой смысл ждать по 4 часа ответа от кожаного мешка, когда можно за час написать робота, который проверит этот кусок работы? Причём робот сделает это не только сейчас, но и потом — в CI, при регрессионном тестировании, всегда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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