Правила письменной контрацепции: как ставить задачи айтишникам и не поубивать друг друга

Сотрудники каждой компании время от времени получают в письменном виде задачи, которые им поручают руководители или коллеги. От того, как будет сформулировано задание, зависит правильность его понимания и, в конечном счёте, результат. Письменная постановка задач особенно широко распространена в digital- и IT-компаниях. О том, почему в формулировках не стоит использовать капслок и мат, а также как просто и понятно объяснить айтишникам, что от них требуется, в своей «Настольной книге project-менеджера» рассказал Владимир Завертайлов, основатель одной из самых ярких российских IT-компаний.

С одной стороны, навык несложный, но именно из-за деталей чаще всего можно получить на проекте долгоиграющий геморрой, а потом ходить и удивляться, почему всё складывается наперекосяк. 

Итак, солнечное утро. Вы сидите за чашкой кофе. Лениво просматриваете свой проект. И находите в нём какой-нибудь баг (ошибку). Рука тянется открыть таск-менеджер, например Jira. Авторизоваться там, найти нужный проект, поставить задачу с описанием бага в грамотных формулировках, приложить скриншоты, описать, как этот баг воспроизвести, назначить ответственных, запланировать себе контроль и так далее. Вот если так – то вы святой человек. Ведь интуитивно в этот момент хочется сказать: «Опять эти упыри накосячили, я что им – бета-тестер что ли?!» 

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

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

Минимум транзакционных издержек – это когда программист сидит рядом, под боком, и вы силой голоса призываете его, тычете пальцем в монитор и говорите: «Опять ничерта не работает, пойди разберись!» Нормально ли это? Отчасти. 

• Совет. Большая часть крупных релизов перед дедлайном и перед выпуском проходят через фазу стресса. И здесь возможно всё – вплоть до трёхэтажных матов и жёстких конфликтов. В целом, это даже полезно. Главное, чтобы такое не вошло в традицию. День-два в таком ритме можно пережить, дальше – нет. Всё должно войти в русло, задачи должны поступать из одного источника, а не сыпаться на бедного-несчастного разработчика с пометкой «СРОЧНО», «КОГДА УЖЕ БУДЕТ» и «НЕМЕДЛЕННО». 

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

Когда пишешь разработчику матом, либо просто «баг» или даже «косяк» – это воспринимается как личное оскорбление. Это серьёзный плевок в душу разработчика. Пишите простыми, понятными формулировками. Не машите кулаками там, где не должно быть драки. А с надписями КАПСОМ будьте совсем осторожны – это воспринимается так, будто вы на человека ОРЁТЕ. Конечно, только если это не ваш управленческий ход, чтобы загнать кого-то под тумбочку. Только ведь он потом оттуда вылезет! В общем, давайте не капсить. В мире и так слишком много этого дерьмеца. 

Вообще, речь на письме выглядит значительно жёстче, чем то же самое, произнесённое устно. В подтверждение – известный анекдот про фразы «Папа! Вышли денег!» и «Папа, вышли денег». Если вы имели опыт переписки с клиентами из Европы или США, то наверняка заметили, что те очень часто используют вежливые слова – «пожалуйста», «спасибо» – и часто благодарят. Слова не влияют на суть, но могут сгладить стиль общения. В русских реалиях такое встречается редко. Причина – якобы вежливая речь может быть воспринята как слабость. На мой взгляд, эта идея глупая, и письменную речь нужно обязательно смягчать. 

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

В баг-листах или задачах это может быть не всегда уместно, но в переписке, постановке задач, комментариях – точно не навредит. Посмотрите, как по-разному будут читаться вроде бы хвалебные слова, в зависимости от знака в конце предложения: 

Молодец...
Молодец.
Молодец!!!
Молодец :(
Молодец :)
ХОРОШ! 

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

• Совет. Не допускайте КАПСА, мата и ругани в письме и старайтесь отучать от этого коллег. И не стесняйтесь использовать смайлы, чтобы смягчить жёсткость, присущую письменной речи. 

Окей, вы такой молодец, написали разработчику вежливое обращение со смайликом и скинули ссылку. Насколько это конкретно? Приложили скриншот? Уже лучше. Можно стрелок к нему ещё нарисовать. Уже почти хорошо. Только всё равно не спасает. Многие грешат надписями на скриншотах. Но часто конкретики с ними всё равно нет. 

Я не преувеличиваю ни на грамм. Ставится задача с формулировкой «Косяк на сайте». КАПСОМ. Ставится ссылка на скриншот, где тоже что-то невменяемо написано капсом. Не удивляйтесь, если в комментариях к такой задаче вам также начнут отвечать капсом, нервно и грубо. Надписи на скриншотах не возбраняются, но они должны быть конкретными. 

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

Вместо «Вот тут проблема» можно написать: «В тексте ссылки на отзыв – абракадабра». Гордый собой менеджер или заказчик считает, что на этом его миссия по формулированию проблемы – заметьте, чёткому формулированию – закончена. Мол, вот баг, вот скрин, описание – смотри на скрине. 

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

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

Слово «кажется» – это из словаря терминов-паразитов. В баг-листах, в формулировках задач прилагательные и местоимения – это слова, которые можно трактовать двояко. «Каждый», «любой», «все», «больше», «меньше» и так далее. Это признак нечёткой постановки. Как минимум – перепроверьте, можно ли такие слова перевести в чёткие цифры или конкретизировать (не всегда, но можно). 

Ещё одна дичь – эмоциональность (или даже скрытая пассивная агрессия) в постановках, чатах или рабочих артефактах. Ниже – пара примеров из практики: правильно-неправильно. 

Организуйте постановки по принципу «пирамиды». Заголовок задачи – такой, чтобы была понятна суть и не приходилось много читать. Детали помещайте в описание. Также указывается приоритет задачи. 

1. Маты и КАПС. Вам – нельзя. Разработчикам – иногда можно.

2. Место. Указывайте конкретное место, где возникла ошибка.

3. Поископригодность. Пишите так, чтобы запись легко искалась по ключевых словам.

4. Пирамида. Используйте принцип пирамиды. Важное – в начало. Детали – в кончало.

5. Скриншоты – важное дополнение. Подкрепите текстовое описание скриншотом.

6. Решение, а не мнение. Формулируйте не только проблему, но и ожидаемое решение – чётко и однозначно, а не в виде абстрактных пожеланий и мнений.

7. Не впадайте в истерику. Пишите по делу, без эмоций.

8. Приоритизируйте. Расставляйте приоритеты и организуйте по большим баг-листам работу микро-спринтами. 

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

Более подробно о нюансах управления проектами в условиях российских реалий можно прочитать в «Настольной книге project-менеджера» Владимира Завертайлова, которую выпустило издательство «Бомбора».

Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал, страницу в «ВКонтакте» и канал на «Яндекс.Дзен».
biz360