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

Продолжаем потихоньку публиковать избранные параграфы из книжки Управление digital-проектами

Программисты — как джинны. Осторожнее в своих желаниях, они могут исполниться.

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

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

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

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

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

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

Вернёмся к разработчику, который услышал резко-высказанное замечание «баг на проекте» или «ничего не работает». У него всего два варианта действий: либо уйти в оборону, либо — в нападение. Но что адекватного можно ответить на формулировку «Ничего не работает»?! У тебя компьютер что ли не включается?!

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

Когда атмосфера накаляется, диалог может складываться как-то так:

Когда пишешь разработчику матом, либо просто «баг» или даже «косяк» — это воспринимается как личное оскорбление (чуть позже мы посмотрим на когнитивные искажения). Это серьезный плевок в душу разработчика.

Пишите простыми, понятными формулировками. Не машите кулаками там, где не должно быть драки. А с надписями КАПСОМ будьте совсем осторожны — это воспринимается так, будто вы на человека ОРЁТЕ.

Конечно, только если это не ваш управленческий ход, чтобы загнать кого-то под тумбочку. Только ведь он потом оттуда вылезет! В общем, давайте не капсить. В мире и так слишком много этого дерьмеца.

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

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

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

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

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

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

Сейчас за кадром оставим вопрос, почему у вас заказчик нашел баги и их так много, не на этом акцент. Это могут быть и формулировки заданий — разницы нет.

Если в таком виде с вами работает ваш клиент, и у вас не получается договориться о нормальных формулировках (ему тоже не до формулирования и чёткости и проще вам заплатить побольше денег, чтобы вы сами все фиксировали с его слов) — тогда проблем нет. Фиксируйте всё сами, сами переводите с клиентского на программистский. Берите за это денег. Это воспринимается абсолютно нормально в 80% случаев и ценится (если вы сильно не косячите). Вы экономите клиенту время — и это тоже часть менеджерской работы. К исполнителям формулировки должны попадать такие, чтобы задачу можно было найти поиском. Очевидная вещь, но приходится и про такое рассказывать.

Формулировки стоит писать так, чтобы по ним было легко найти, где случился и как проявился баг. Подробно описывайте, что заставило баг вылезти. И поменьше оценочных формулировок: что это за «абракадабра в тексте ссылки»? В том же Битриксе, например, по умолчанию не генерируются ссылки с человеко-понятными названиями, любой программист вам скажет про это. И даже не попытается понять вашу проблему. Мол, в коробочной версии это работает именно так, чего вы от меня хотите?! Это нормальное поведение программистов — и нельзя их за него осуждать.

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

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

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

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

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

Замечу, что это именно наши приоритеты по разработке. Например, у рейтингового агентства «Тэглайн» приоритеты другие: для них ошибка в продающем тексте может быть более приоритетна, чем криво работающая форма подачи какой-нибудь анкеты. Ну ради бога.

Мы намеренно пропускаем 5, 6, 7 — если такие приоритеты понадобятся на конкретном проекте, мы их просто придумаем, не ломая основную систему.

Соответственно, если поставить нашей задаче приоритет, четко показать программисту, что это — «хотелка», он, скорее всего, это сделает, не задавая лишних вопросов. Кстати, приоритеты — очень полезная вещь, поскольку мы можем управлять качеством продукта. Например, закрываем всё по 4-й приоритет включительно и запускаемся. Почему бы и нет, если вдруг скорость запуска нам приоритетнее полировки проекта.

(должны гореть в аду, но это не точно)

Есть клиенты-перфекционисты, которые считают, что нельзя выпускать проект с незакрытыми багами. Увы, в наше время это утопия. Любой софт выпускается с какой-то долей некритичных ошибок. С какой именно — это вопрос дискуссионный. Бывает, что пользователи используются как бета-тестеры. Скорость на запуске (или Time To Market, TTM — время от начала разработки идеи до ее конечной реализации) важнее. Понять это можно, посмотрев на обновления приложений, которые прилетают к вам в телефон. Большая часть обновлений в описании содержит две строчки «Увеличена стабильность, улучшена производительность». На русский язык переводится как «мы поправили пару багов». Даже у Эппл ошибки, которые известны годами, — это норма.

Исключения — софт, отвечающий за критические элементы инфраструктуры: ядерные реакторы, системы управления двигателями и так далее. Но и там не все гладко, можете почитать про компанию Тойота, у которой 11 тысяч глобальных переменных и 82 тысячи нарушений в коде. В общем, ошибки в коде будут всегда, как только проект перерастает уровень песочницы.

Было ли у вас такое, что вы моете посуду, а вам всё время подкидывают новую? Опа, а тут еще и сковородка! Это откровенно бесит. Я считаю, что программисты должны видеть конечный набор багов и задач. Поэтому если тикетов много, стоит организовать работу мелкими итерациями (спринтами). И даже если параллельно с исправлением багов идет процесс тестирования, то новая пачка багов должна попасть к программистам, только когда они отработают и закроют уже выданный им объём. Это не всегда возможно и не везде применимо, но стоит к этому стремиться, потому что так в итоге спокойнее.

Правила грамотной постановки задач разработчикам

1. Маты и КАПС

Вам нельзя. Разработчикам иногда можно.

2. Место

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

3. Поископригодность

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

4. Пирамида

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

5. Скриншот — важное дополнение

Дополните текстовое описание скриншотом.

6. Решение, а не мнение

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

7. Не впадайте в истерику

Пишите по делу, без эмоций.

8. Приоритизируй

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

9. Закончи уже писать!

Не подкидывайте посуду!

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

Этот материал — черновик книги по управлению digital-проектами. Автор заранее приносит извинения за возможные неточности. Любая конструктивная обратная связь приветствуется.

Предыдущие главы: #001, #002, #003, #004

Продолжение следует.