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

Рекомендации из “Справочника руководителя проекта” Владимира Завертайлова

IT-инструменты, которые использует Владимир Завертайлов

  • SingularityApp
  • ReactJs
  • NodeJs
  • Jira

Сотрудники каждой компании время от времени получают письменное задание от своих руководителей или коллег. От того, как сформулировано задание, зависит, насколько хорошо оно будет понято и, в конечном счете, результат. Письменные задания особенно распространены в цифровых и ИТ-компаниях. Владимир Завертайлов, основатель одной из самых успешных российских ИТ-компаний, в своей “Приборной панели руководителя проекта” рассказывает, почему не стоит использовать капслок и вульгаризмы в своих высказываниях и как просто и понятно объяснить ИТ-специалистам, что от них требуется.

Досье

Владимир Звертайлов, 41 год, является основателем и руководителем scrum-студии Sibirix. Окончил Алтайский государственный технический университет по специальности “инженерная педагогика и информатика”. Он основал студию Sibirix в 2003 году, и в последние годы компания неизменно входит в десятку лучших веб-студий страны, по версии Tagline. Он является автором книги “Справочник руководителя проекта”. Владимир Завертайлов имеет лицензию на управление самолетами и вертолетами. Он женат и имеет двух детей в семье.

Как сформулировать свои требования к программистам в письменном виде

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

Итак, солнечное утро. Вы сидите за чашкой кофе. Вы бездельничаете над своим проектом. И вы находите в нем ошибку. Ваша рука тянется, чтобы открыть менеджер задач, например Jira. Вы заходите туда, находите нужный проект, ставите задачу с четким описанием ошибки, включаете скриншоты, описываете, как воспроизвести ошибку, назначаете ответственных, контролируете график и так далее. Если вы делаете это, то вы святой человек. Интуитивно вы хотите сказать в этот момент: “Эти упыри опять допустили ошибку, я что, бета-тестер или как!

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

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

Минимальные транзакционные издержки – это когда программист сидит рядом с вами, под боком, и вы насильно призываете его или ее, тыкая пальцем в монитор и говоря: “Это не работает, пойди разберись еще раз!”. Это нормально? Вроде того.

  • Подсказка. Большинство крупных релизов проходят через стрессовую фазу перед дедлайном и перед релизом. Здесь возможно все, вплоть до трехэтажной ругани и жестоких конфликтов. В целом, это даже полезно. Главное, чтобы это не стало традицией. В таком ритме можно прожить день или два, но не потом. Все должно стать нормальным, задачи должны поступать из одного источника, а не от бедного разработчика, помеченные как “срочно”, “КОГДА” и “НЕЗАМЕДЛИТЕЛЬНО”.
Читайте также:  Международная Академия развития интеллекта "BOOM KIDS"

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

Принципы письменной контрацепции: как ставить цели для ИТ-специалистов и не покончить с собой

Когда вы пишете разработчику бранное слово или простое “баг” или даже “ошибка”, это воспринимается как личное оскорбление. Это серьезное оскорбление для разработчика. Пишите простыми, понятными словами. Не размахивайте кулаками там, где не должно быть драки. И будьте очень осторожны с CAPS, потому что это звучит так, как будто вы кричите на кого-то. Если, конечно, это не ход руководства, чтобы затащить кого-то под прикроватную тумбочку. Только он ведь потом выйдет из нее, верно? В любом случае, давайте не будем забивать себе голову. Пока что в мире слишком много этого дерьма.

Меньше насилия, детка!

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

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

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

Читайте также:  Держать ухо востро: каким компаниям стоит создавать подкаст и какие задачи он решает

Молодец…
Молодец.
Браво!!!
Молодец :(
Молодец :)
ХОРОШО!

При подготовке карточек с ошибками или списков всегда думайте на полсекунды, как это будет прочитано и с какой интонацией. Наша студия терпима, если разработчик использует ругательства в списках ошибок или комментариях. Это табу для менеджеров и тестировщиков, но для разработчика это иногда приемлемо, если он или она не злоупотребляет этим и если клиенты не видят комментариев. Но неуважительные комментарии, письменные или устные, в адрес клиентов должны быть наказаны или, по крайней мере, – рассмотрены и обсуждены на предмет правильности и неправильности. Для меня это показатель того, что “все ли в порядке в проекте?”. Потому что если есть какие-то проклятия в адрес клиента или проекта, ситуация становится все менее захватывающей в результате инерции.

  • Советы. Не допускайте CAPS, ругательств в письменной речи и постарайтесь отучить от них своих коллег. И не стесняйтесь использовать смайлики, чтобы смягчить резкость, присущую вашему письму.

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

Я ничуть не преувеличиваю. Была поставлена задача: “Пруд на строительной площадке”. КАПС. Приводится ссылка на скриншот, где также что-то написано неуместно в CAPS. Не удивляйтесь, если в комментариях к такому заданию вы также будете отвечать в CAPS, нервно и хамски. Подписи к скриншотам не запрещены, но они должны быть конкретными.

Принципы письменной контрацепции: как бросить вызов ИТ-специалистам, не убивая друг друга

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

Найди меня позже, попробуй!

Вместо “Здесь есть проблема” вы можете написать: “В тексте ссылки на рецензию есть абракадабра”. Гордый менеджер или клиент думает, что на этом его миссия по формулированию проблемы (заметьте, что он сформулировал ее точно) закончена. Например, вот ошибка, вот скриншот, описание – посмотрите на скриншот.

Читайте также:  Прокат веломобилей

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

Мне кажется.

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

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

Плачьте об этом… в другом месте!

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

Принципы письменной контрацепции: как бросить вызов ИТ-специалистам, не убивая друг друга

Принцип пирамиды

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

Хорошие правила для правильного обозначения задач для программистов

  1. Маты и КАПСы. Вы не должны. Для разработчиков иногда можно поступить так.

  2. Местонахождение. Определите конкретное место, где произошла ошибка.

  3. Возможность поиска. Напишите его так, чтобы можно было легко найти запись по ключевым словам.

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

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

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

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

  8. Расставьте приоритеты. Расставлять приоритеты и организовывать работу над большими списками ошибок с помощью микроотпечатков.

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

Более подробно о нюансах управления проектами в российских реалиях читайте в книге Владимира Завертайлова “Справочник руководителя проекта”, опубликованной издательством “Бомбора”.

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

Компания biz360

Рейтинг
( Пока оценок нет )
pitovaxi/ автор статьи
Понравилась статья? Поделиться с друзьями:
Идеи малого бизнеса
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: