#005 управление digital-проектами
Правила письменной контрацепции.
Как ставить задачи и не поубивать друг друга
Как ставить задачи и не поубивать друг друга
Продолжаем потихоньку публиковать избранные параграфы из книжки Управление digital-проектами
Владимир Завертайлов
Руководитель scrum-студии Сибирикс
Программисты — как джинны. Осторожнее в своих желаниях, они могут исполниться.
Как письменно формулировать свои требования к программистам? С одной стороны, навык несложный, но именно на этих деталях чаще всего можно получить на проекте долгоиграющий гемморой, а потом ходить и удивляться, почему всё складывается наперекосяк.
Как письменно формулировать свои требования к программистам? С одной стороны, навык несложный, но именно на этих деталях чаще всего можно получить на проекте долгоиграющий гемморой, а потом ходить и удивляться, почему всё складывается наперекосяк.
Итак, солнечное утро. Вы сидите за чашкой кофе. Лениво просматриваете свой проект. И находите в нём какой-нибудь баг. Рука тянется открыть отдельное окно браузера, открыть таск-менеджер, например JIRA. Авторизоваться там, найти нужный проект, поставить задачу с описанием бага в грамотных формулировках, приложить скриншоты, описать, как этот баг воспроизвести, назначить ответственных, запланировать себе контроль и так далее. Вот если так — то вы святой человек. Ведь интуитивно в этот момент хочется сказать: «Опять эти упыри накосячили, я что им — бета-тестер что ли?!». Ну, и устроить этим уродам веселую жизнь. И, не дай бог, они начнут сопротивляться.
Почему так? Почему даже мелкий баг на проекте может приводить в бешенство и заказчиков или менеджеров проектов? Причина тому – транзакционные издержки.
Мы интуитивно чувствуем, что на решение мелкой проблемы придется затратить довольно много энергии. На мелкие огрехи часто проще махнуть рукой, чем доделывать те последние 10% работы, которые занимают оставшиеся 50% времени. Возможность быстро поставить задачу, прилагая минимум усилий мозга и телодвижений, напрямую влияет на качество проекта и добрые отношения внутри рабочей группы. Хотя и двояким образом.
Минимум транзакционных издержек — это когда программист сидит рядом, под боком, и вы силой голоса призываете его, тычете пальцем в монитор и говорите: «Опять нихрена не работает, пойди разберись!». Нормально ли это? Отчасти.
Почему так? Почему даже мелкий баг на проекте может приводить в бешенство и заказчиков или менеджеров проектов? Причина тому – транзакционные издержки.
Мы интуитивно чувствуем, что на решение мелкой проблемы придется затратить довольно много энергии. На мелкие огрехи часто проще махнуть рукой, чем доделывать те последние 10% работы, которые занимают оставшиеся 50% времени. Возможность быстро поставить задачу, прилагая минимум усилий мозга и телодвижений, напрямую влияет на качество проекта и добрые отношения внутри рабочей группы. Хотя и двояким образом.
Минимум транзакционных издержек — это когда программист сидит рядом, под боком, и вы силой голоса призываете его, тычете пальцем в монитор и говорите: «Опять нихрена не работает, пойди разберись!». Нормально ли это? Отчасти.
Бета-тестер — почти настоящий пользователь, который интенсивно использует почти готовую версию продукта/сайта/приложения, чтобы выявить максимальное число ошибок для их последующего устранения перед окончательным выходом (релизом).
Совет
Большая часть крупных релизов перед дедлайном и перед выпуском проходят через фазу стресса. И здесь возможно всё — вплоть до трехэтажных матов и жёстких конфликтов. В целом, это даже полезно. Главное, чтобы такое не вошло в традицию. День-два в таком ритме можно пережить, дальше — нет. Все должно войти в русло, задачи должны поступать из одного источника, а не сыпаться на бедного-несчастного разработчика с приоритетами «СРОЧНО», «КОГДА УЖЕ БУДЕТ» и «НЕМЕДЛЕННО».
Рекомендую посмотреть старое интервью со Стивом Джобсом про драки внутри команды и как они влияют на качество продукта — я его периодически показываю своим ребятам, когда начинаются конфликты.
Большая часть крупных релизов перед дедлайном и перед выпуском проходят через фазу стресса. И здесь возможно всё — вплоть до трехэтажных матов и жёстких конфликтов. В целом, это даже полезно. Главное, чтобы такое не вошло в традицию. День-два в таком ритме можно пережить, дальше — нет. Все должно войти в русло, задачи должны поступать из одного источника, а не сыпаться на бедного-несчастного разработчика с приоритетами «СРОЧНО», «КОГДА УЖЕ БУДЕТ» и «НЕМЕДЛЕННО».
Рекомендую посмотреть старое интервью со Стивом Джобсом про драки внутри команды и как они влияют на качество продукта — я его периодически показываю своим ребятам, когда начинаются конфликты.
Вернёмся к разработчику, который услышал резко-высказанное замечание «баг на проекте» или «ничего не работает». У него всего два варианта действий: либо уйти в оборону, либо — в нападение. Но что адекватного можно ответить на формулировку «Ничего не работает»?! У тебя компьютер что ли не включается?!
Часто из-за нехватки времени на постановку, из-за транзакционных издержек и из-за нежелания думать менеджеры и клиенты склонны ставить неконкретные задачи. На что программисты абсолютно резонно попросят больше конкретики — мол, пиши техзадание. А могут и психануть.
Когда атмосфера накаляется, диалог может складываться как-то так:
Часто из-за нехватки времени на постановку, из-за транзакционных издержек и из-за нежелания думать менеджеры и клиенты склонны ставить неконкретные задачи. На что программисты абсолютно резонно попросят больше конкретики — мол, пиши техзадание. А могут и психануть.
Когда атмосфера накаляется, диалог может складываться как-то так:
заказчик:
У вас баг на проекте!
кодер:
А где именно?!
заказчик:
ВОТ ТУТ, ЕПТ! (скриншот)
КОДЕР:
<неразборчиво отвечает и, кажется, пишет заявление>
Когда пишешь разработчику матом, либо просто «баг» или даже «косяк» — это воспринимается как личное оскорбление (чуть позже мы посмотрим на когнитивные искажения). Это серьезный плевок в душу разработчика.
Пишите простыми, понятными формулировками. Не машите кулаками там, где не должно быть драки. А с надписями КАПСОМ будьте совсем осторожны — это воспринимается так, будто вы на человека ОРЁТЕ.
Конечно, только если это не ваш управленческий ход, чтобы загнать кого-то под тумбочку. Только ведь он потом оттуда вылезет! В общем, давайте не капсить. В мире и так слишком много этого дерьмеца.
Пишите простыми, понятными формулировками. Не машите кулаками там, где не должно быть драки. А с надписями КАПСОМ будьте совсем осторожны — это воспринимается так, будто вы на человека ОРЁТЕ.
Конечно, только если это не ваш управленческий ход, чтобы загнать кого-то под тумбочку. Только ведь он потом оттуда вылезет! В общем, давайте не капсить. В мире и так слишком много этого дерьмеца.
Меньше насилия, детка!
Вообще, речь на письме выглядит значительно жёстче, чем-то же самое, произнесенное устно. В подтверждение — известный анекдот про фразы «Папа! Вышли денег!» и «Папа, вышли денег». Если вы имели опыт переписки с клиентами из Европы или США, то наверняка заметили, что те очень часто используют вежливые слова — «пожалуйста», «спасибо», — и часто благодарят. Слова не влияют на суть, но могут сгладить стиль общения. В русских реалиях такое встречается редко. Причина — якобы вежливая речь может быть воспринята как слабость. На мой взгляд, эта идея глупая, и письменную речь нужно обязательно смягчать.
Смайлик — это визуальный дезодорант.
В. Пелевин.
В. Пелевин.
На тон сообщения влияет буквально всё — особенно смайлики и знаки препинания в конце предложений. У Пелевина есть интересная фраза: «Смайлик — это визуальный дезодорант». Поэтому стоит приучить себя к крайне вежливому стилю, не лениться писать «пожалуйста» и «спасибо», ставить смайлики на письме, чтобы сгладить жёсткость и сформировать позитивное отношение к себе в коллективе. В баг-листах или задачах это может быть не везде уместно, но в переписке, в постановке задач, в комментариях — точно не навредит. Посмотрите, как по-разному будут читаться, вроде бы, хвалебные слова, в зависимости от знака в конце предложения:
Молодец…
Молодец.
Молодец!!!
Молодец :(
Молодец :)
ХОРОШ!
Молодец.
Молодец!!!
Молодец :(
Молодец :)
ХОРОШ!
Оформляя баг-листы или письма, всегда задумывайтесь хоть на полсекунды, как это прочитают и с какой интонацией. У нас в студии терпимо относятся, если разработчик использует ненормативную лексику в баг-листах и в комментариях. Для менеджеров и тестировщиков это — табу, для разработчика — иногда можно, если он этим не злоупотребляет и если эти комментарии не увидят клиенты. А вот за неуважительные высказывания, устные или письменные, по отношению к клиенту уже надо наказывать или, как минимум, — разбираться, разговаривать про добро и зло. Для меня это индикатор «всё ли нормально на проекте?!». Потому что если появляется ругань в сторону клиента или проекта, дальше по инерции ситуация становится все менее и менее управляемой.
Совет
Не допускайте КАПСА, мата и ругани на письме и старайтесь отучать от этого коллег. И не стесняйтесь использовать смайлы, чтобы смягчить жёсткость, присущую письменной речи.
Не допускайте КАПСА, мата и ругани на письме и старайтесь отучать от этого коллег. И не стесняйтесь использовать смайлы, чтобы смягчить жёсткость, присущую письменной речи.
Окей, вы такой молодец, написали разработчику вежливое обращение со смайликом и скинули ссылку. Насколько это конкретно? Приложили скриншот? Уже лучше. Можно стрелок к нему ещё нарисовать. Уже почти хорошо. Только всё равно не спасает. Многие грешат надписями на скриншотах. Но часто конкретики с ними всё равно нет.
Я не преувеличиваю ни на грамм. Ставится задача с формулировкой «Косяк на сайте». КАПСОМ. Ставится ссылка на скриншот, где тоже что-то невменяемо написано капсом. Не удивляйтесь, если в комментариях к такой задаче вам также начнут отвечать капсом, нервно и грубо. Тикет-система тут будет не виновата — так накуролесить можно и в JIRA, и Trello, и в чем угодно ещё.
Я не преувеличиваю ни на грамм. Ставится задача с формулировкой «Косяк на сайте». КАПСОМ. Ставится ссылка на скриншот, где тоже что-то невменяемо написано капсом. Не удивляйтесь, если в комментариях к такой задаче вам также начнут отвечать капсом, нервно и грубо. Тикет-система тут будет не виновата — так накуролесить можно и в JIRA, и Trello, и в чем угодно ещё.
Надписи на скриншотах не возбраняются, но они должны быть конкретными.
Вместо «Вот тут проблема» можно написать «В тексте ссылки на отзыв — абракадабра». Гордый собой менеджер или заказчик считает, что на этом его миссия по формулированию проблемы — заметьте, чёткому формулированию — закончена. Мол, вот баг, вот скрин, описание — смотри на скрине. Но так не пойдёт: если таких багов двадцать (или двести), баг-лист превращается в мешанину, и как что искать в таком случае, неясно.
Сейчас за кадром оставим вопрос, почему у вас заказчик нашел баги и их так много, не на этом акцент. Это могут быть и формулировки заданий — разницы нет.
Сейчас за кадром оставим вопрос, почему у вас заказчик нашел баги и их так много, не на этом акцент. Это могут быть и формулировки заданий — разницы нет.
Найди меня потом, попробуй!
Если в таком виде с вами работает ваш клиент, и у вас не получается договориться о нормальных формулировках (ему тоже не до формулирования и чёткости и проще вам заплатить побольше денег, чтобы вы сами все фиксировали с его слов) — тогда проблем нет. Фиксируйте всё сами, сами переводите с клиентского на программистский. Берите за это денег. Это воспринимается абсолютно нормально в 80% случаев и ценится (если вы сильно не косячите). Вы экономите клиенту время — и это тоже часть менеджерской работы. К исполнителям формулировки должны попадать такие, чтобы задачу можно было найти поиском. Очевидная вещь, но приходится и про такое рассказывать.
Формулировки стоит писать так, чтобы по ним было легко найти, где случился и как проявился баг. Подробно описывайте, что заставило баг вылезти. И поменьше оценочных формулировок: что это за «абракадабра в тексте ссылки»? В том же Битриксе, например, по умолчанию не генерируются ссылки с человеко-понятными названиями, любой программист вам скажет про это. И даже не попытается понять вашу проблему. Мол, в коробочной версии это работает именно так, чего вы от меня хотите?! Это нормальное поведение программистов — и нельзя их за него осуждать.
Формулировки стоит писать так, чтобы по ним было легко найти, где случился и как проявился баг. Подробно описывайте, что заставило баг вылезти. И поменьше оценочных формулировок: что это за «абракадабра в тексте ссылки»? В том же Битриксе, например, по умолчанию не генерируются ссылки с человеко-понятными названиями, любой программист вам скажет про это. И даже не попытается понять вашу проблему. Мол, в коробочной версии это работает именно так, чего вы от меня хотите?! Это нормальное поведение программистов — и нельзя их за него осуждать.
Проблема или требование?
Бывают формулировки, из которых непонятно: это проблема или требование? Пример — «ссылка фиолетовая». И что? Она должна такой быть или ошибка в том, что она фиолетовая, а должна быть серой? Дело в том, что непонятно, что именно вы хотите, чтобы с этим фактом сделали и как именно его поправили.
Project manager:
Ссылка фиолетовая
coder:
И чо?
Мне кажется...
Другая частая ошибка менеджеров — формулировки задач в виде пожеланий. С оговорками «мне кажется», «я думаю», «а как на ваш вкус» и так далее. Опять же, если такие формулировки приходят от клиента — нормально, если менеджер их уточняет и конкретизирует. Слово «кажется» — это из словаря терминов-паразитов. В баг-листах, в формулировках задач, прилагательные и местоимения — это слова, которые можно трактовать двояко. «Каждый», «любой», «все», «больше», «меньше» и так далее. Это признак нечёткой постановки. Как минимум — перепроверьте, можно ли такие слова перевести в чёткие цифры или конкретизировать (не всегда, но можно).
Поплачь о нем... В другом месте!
Еще одна дичь — эмоциональность (или даже скрытая пассивная агрессия) в постановках, чатах или рабочих артефактах. Пара примеров из практики, правильно-неправильно и пара примеров подумать, как могло бы быть правильно, а главное — поставить себя на место того человека, который получил задачу или обратную связь к своей работе в таком виде:
Представьте, что программист переживает расставание с подружкой, пришел с плохим настроением. Открывает текстовый редактор. Создает файл
VsePloho.php.
В нем — класс PolniyPipec. А в нем метод
KakViVseDostali (vi, vse);
На другое день настроение наладилось, помирились, новый файл уже SuperPuperMegaKorzina.php и все в таком роде.
И это все идет на ревью службе безопасности.
Думаю, там разговор короткий будет.
VsePloho.php.
В нем — класс PolniyPipec. А в нем метод
KakViVseDostali (vi, vse);
На другое день настроение наладилось, помирились, новый файл уже SuperPuperMegaKorzina.php и все в таком роде.
И это все идет на ревью службе безопасности.
Думаю, там разговор короткий будет.
Принцип пирамиды
Организуйте постановки по принципу «пирамиды». Заголовок задачи должен быть такой, чтобы была понятна суть, и не приходилось много читать. Детали помещайте в описание.
Приоритеты
В баг-листах, помимо описания проблемы, её места на сайте и способов воспроизвести баг, также указывается приоритет. В разных компаниях системы приоритетов обычно складываются исторически. У нас она — вот такая:
Мы намеренно пропускаем 5, 6, 7 — если такие приоритеты понадобятся на конкретном проекте, мы их просто придумаем, не ломая основную систему.
Соответственно, если поставить нашей задаче приоритет, четко показать программисту, что это — «хотелка», он, скорее всего, это сделает, не задавая лишних вопросов. Кстати, приоритеты — очень полезная вещь, поскольку мы можем управлять качеством продукта. Например, закрываем всё по 4-й приоритет включительно и запускаемся. Почему бы и нет, если вдруг скорость запуска нам приоритетнее полировки проекта.
- 0 — критические баги (падает сервер или не работает оплата), нулевой приоритет ставим в случае, если тестировщик из-за этого бага не может дальше продолжать проверку проекта.
- 1 — либо что-то забыли реализовать, либо что-то критичное по юзабилити.
- 2, 3 — менее критичные вещи.
- 4 — ошибки в текстах или текстовые правки.
- 8 — это «хотелки», некритичные баги.
Мы намеренно пропускаем 5, 6, 7 — если такие приоритеты понадобятся на конкретном проекте, мы их просто придумаем, не ломая основную систему.
Соответственно, если поставить нашей задаче приоритет, четко показать программисту, что это — «хотелка», он, скорее всего, это сделает, не задавая лишних вопросов. Кстати, приоритеты — очень полезная вещь, поскольку мы можем управлять качеством продукта. Например, закрываем всё по 4-й приоритет включительно и запускаемся. Почему бы и нет, если вдруг скорость запуска нам приоритетнее полировки проекта.
Перфекционисты
(должны гореть в аду, но это не точно)
(должны гореть в аду, но это не точно)
Большая часть обновлений приложений в описании содержит две строчки «Увеличена стабильность, улучшена производительность».
На русский язык переводится как «мы поправили пару косяков».
На русский язык переводится как «мы поправили пару косяков».
Есть клиенты-перфекционисты, которые считают, что нельзя выпускать проект с незакрытыми багами. Увы, в наше время это утопия. Любой софт выпускается с какой-то долей некритичных ошибок. С какой именно — это вопрос дискуссионный. Бывает, что пользователи используются как бета-тестеры. Скорость на запуске (или Time To Market, TTM — время от начала разработки идеи до ее конечной реализации) важнее. Понять это можно, посмотрев на обновления приложений, которые прилетают к вам в телефон. Большая часть обновлений в описании содержит две строчки «Увеличена стабильность, улучшена производительность». На русский язык переводится как «мы поправили пару багов». Даже у Эппл ошибки, которые известны годами, — это норма.
Исключения — софт, отвечающий за критические элементы инфраструктуры: ядерные реакторы, системы управления двигателями и так далее. Но и там не все гладко, можете почитать про компанию Тойота, у которой 11 тысяч глобальных переменных и 82 тысячи нарушений в коде. В общем, ошибки в коде будут всегда, как только проект перерастает уровень песочницы.
Горшочек, не вари
Было ли у вас такое, что вы моете посуду, а вам всё время подкидывают новую? Опа, а тут еще и сковородка! Это откровенно бесит. Я считаю, что программисты должны видеть конечный набор багов и задач. Поэтому если тикетов много, стоит организовать работу мелкими итерациями (спринтами). И даже если параллельно с исправлением багов идет процесс тестирования, то новая пачка багов должна попасть к программистам, только когда они отработают и закроют уже выданный им объём. Это не всегда возможно и не везде применимо, но стоит к этому стремиться, потому что так в итоге спокойнее.
Подведем итоги
Правила грамотной постановки задач разработчикам
1
Маты и КАПС
Вам нельзя. Разработчикам иногда можно.
2
Место
Указывайте конкретное место, где возникла ошибка
3
Поископригодность
Пишите так, чтобы запись легко искалась по ключевых словам.
4
Пирамида
Используйте принцип пирамиды. Важное — в начала. Детали — в кончало.
5
Скриншот — важное дополнение
Дополните текстовое описание скриншотом.
6
Решение, а не мнение
Формулируйте не только проблему, но и ожидаемое решение — четко и однозначно, а не в виде абстрактных пожеланий и мнений.
7
Не впадайте в истерику
Пишите по делу, без эмоций.
8
Приоритизируй
Расставляйте приоритеты и организуйте по большим баг-листам работу микро-спринтами.
9
Закончи уже писать!
Не подкидывайте посуду!
Вот тогда вы, как менеджер, будете сильно нравиться программистам, и в мире будет больше добра, радости и взаимопонимания. Но это не точно :)
♥
Статья — глава из книги Владимира Завертайлова «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий». Книга доступна на сайте издательской группы ЭКСМО.