Минимум транзакционных издержек это когда программист сидит рядом, под боком, и вы силой голоса призываете его, тычете пальцем в монитор и говорите: «Опять ничерта не работает, пойди разберись!» Нормально ли это? Отчасти.
Совет
Большая часть крупных релизов перед дедлайном и перед выпуском проходят через фазу стресса. И здесь возможно все вплоть до трехэтажных матов и жестких конфликтов. В целом, это даже полезно. Главное, чтобы такое не вошло в традицию. День-два в таком ритме можно пережить, дальше нет. Все должно войти в русло, задачи должны поступать из одного источника, а не сыпаться на бедного-несчастного разработчика с пометкой «СРОЧНО», «КОГДА УЖЕ БУДЕТ» и «НЕМЕДЛЕННО».
Рекомендую посмотреть старое интервью со Стивом Джобсом про драки внутри команды и как они влияют на качество продукта я его периодически показываю своим ребятам, когда начинаются конфликты.
Вернемся к разработчику, который услышал резко высказанное замечание «баг на проекте» или «ничего не работает». У него всего два варианта действий: либо уйти в оборону, либо в нападение. Но что адекватного можно ответить на формулировку «Ничего не работает»?! У тебя компьютер что ли не включается?!
Часто из-за нехватки времени на постановку, из-за транзакционных издержек и из-за нежелания думать менеджеры и клиенты склонны ставить неконкретные задачи. На что программисты абсолютно резонно попросят больше конкретики мол, пиши техзадание. А могут и психануть.
Когда атмосфера накаляется, диалог может складываться как-то так:
У вас баг на проекте!
А где именно?!
ВОТ ТУТ, ЕПТ!!!
Плюс скриншот.
Когда пишешь разработчику матом, либо просто «баг» или даже «косяк» это воспринимается как личное оскорбление (чуть позже мы посмотрим на когнитивные искажения). Это серьезный плевок в душу разработчика. Пишите простыми, понятными формулировками. Не машите кулаками там, где не должно быть драки. А с надписями КАПСОМ будьте совсем осторожны это воспринимается так, будто вы на человека ОРЕТЕ. Конечно, только если это не ваш управленческий ход, чтобы загнать кого-то под тумбочку. Только ведь он потом оттуда вылезет! В общем, давайте не капсить. В мире и так слишком много этого дерьмеца.
1.8.1. Меньше насилия, детка!
Вообще, речь на письме выглядит значительно жестче, чем то же самое, произнесенное устно. В подтверждение известный анекдот про фразы «Папа! Вышли денег!» и «Папа, вышли денег». Если вы имели опыт переписки с клиентами из Европы или США, то наверняка заметили, что те очень часто используют вежливые слова «пожалуйста», «спасибо» и часто благодарят. Слова не влияют на суть, но могут сгладить стиль общения. В русских реалиях такое встречается редко. Причина якобы, вежливая речь может быть воспринята как слабость. На мой взгляд, эта идея глупая, и письменную речь нужно обязательно смягчать.
На тон сообщения влияет буквально все особенно смайлики и знаки препинания в конце предложений. У Пелевина есть интересная фраза: «Смайлик это визуальный дезодорант». Поэтому стоит приучить себя к крайне вежливому стилю, не лениться писать «пожалуйста» и «спасибо», ставить смайлики на письме, чтобы сгладить жесткость и сформировать позитивное отношение к себе в коллективе. В баг-листах или задачах это может быть не всегда уместно, но в переписке, в постановке задач, в комментариях точно не навредит. Посмотрите, как по-разному будут читаться, вроде бы, хвалебные слова, в зависимости от знака в конце предложения:
Молодец
Молодец.
Молодец!!!
Молодец:(
Молодец:)
ХОРОШ!
Оформляя баг-листы или письма, всегда задумывайтесь хоть на полсекунды, как это прочитают и с какой интонацией. У нас в студии терпимо относятся, если разработчик использует ненормативную лексику в баг-листах и в комментариях. Для менеджеров и тестировщиков это табу, для разработчика иногда можно, если он этим не злоупотребляет, и если эти комментарии не увидят клиенты. А вот за неуважительные высказывания, устные или письменные, по отношению к клиенту уже надо наказывать или, как минимум, разбираться, разговаривать про добро и зло. Для меня это индикатор «все ли нормально на проекте?!». Потому что, если появляется ругань в сторону клиента или проекта, дальше по инерции ситуация становится все менее и менее управляемой.