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

Первое, что нужно сделать, заменить свою клавиатурную раскладку на раскладку Бирмана.

Эта раскладка есть для винды и мака. Я буду писать о маке. На сайте написано, как их установить. Если вы пишете, в основном, на русском, русской раскладки будет достаточно. С английской всё несколько сложнее, потому что из макоси выпилить дефолтную английскую по-моему, невозможно. Если возможно, напишите в комментах, как.

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

Ладно, ближе к делу. При помощи раскладки Бирмана вам нужно освоить, как набирать следующие символы и научиться делать это на автомате:

Всё. Остальные спецсимволы встречаются сильно реже.

Теперь поговорим о типографских приёмах для оформления текста.

Использования спецсимволов в сочетании с этими приёмами достаточно, чтобы тексты выглядели профессионально и круто. Пользуйтесь.

Документ будет полезен начавшим изучать английский для более комфортного входа в айти.

Есть только два гендера. Один спокойно живёт с тысячью непрочитанных сообщений, второй же волнуется, если на баджике приложения горит единица и тут же стремится её убрать. Я скорее принадлежу ко второму и стараюсь держать инбоксы всех своих почтовых ящиков и мессенджеров пустыми. Несколько слов о том, как я это делаю. 

Давным-давно для работы с почтой я использовал The Bat, потом перешёл на веб-версию gmail, но потом гугловцы что-то с ней сделали и она стала грузиться по полминуты, из-за чего я снова поставил почтовый клиент — Airmail. Но потом всё же перешёл на дефолтный маковский почтовик Mail, он мне пришёлся по духу больше.

У меня три основных почтовых ящика:

• proftwist@gmail.com – для рассылок, регистраций на сомнительных сайтах, автоинформаторов, календаря (прочитайте мою заметку, как сделать, чтобы в календарь не приходил спам) и адресной книги.
• vladimir@bychko.ru – для адресной переписки.
• v.polovcev@yandex.ru — для автоинформаторов Яндекс.Метрики и музыки с Яндекс.Музыки, для переписки же его не использую и к почтовому клиенту не подключаю.

Мой бывший работодатель, Денис Никаноров из Benovate, написал на vc статью о почти полном отключении уведомлений от всего. Я такого себе позволить не могу, так как 80 % моей работы — ответы на сообщения.

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

Таким образом я отписался практически от всего мусора, на который в изобилии подписался в конце десятых. Остались vc и dtf, да ещё несколько полезных рассылок. 

Всё автоматическое, от чего не отписался, автосортирую. Прочитайте мою заметку с инструкцией по автосортировке писем в gmail. Под каждую рассылку, под каждый автоинформатор (например, Почту России или доставку еды) отдельную папку и пусть почта валится в неё, минуя инбокс и не вызывая пиликанья. Автосортировку всегда делаю средствами веб-версии почты, в почтовом клиенте ничего не настраиваю, так как клиентские фильтры работают, только когда комп онлайн. Устраиваясь на новую работу, первым делом создаю папку для Джиры или иного используемого таск-трекера, потому что писем оттуда будет множество. 

Письма по проектам в рабочей почте автосортировать несколько сложнее, их сортирую руками. Ответил, положил цепочку в папку проекта. 

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

Некоторые коллеги советуют отмечать требующие ответа сообщения непрочитанными:

Из-за принадлежности ко второму гендеру, я так не могу, поэтому в почте помечаю их флажками, а в Телеграме отправляю в Избранное. Пробовал отправлять такие письма на служебный адрес Todoist для автоматического создания задачи, но мне не понравилось, как тело письма причепляется к описанию задачи. 

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

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

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

Давайте разберём разницу между лидерами и боссами более подробно. Картинки взяты из pdf-ки officevibe, если у вас хорошо с английским, оригинал тут.

Лидеры эмпатичны

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

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

Лидеры чаще говорят «мы», а не «я»

Ушли времена, когда продукты делали гении-одиночки. Современные продукты выпускаются слаженными командами, в которых есть командный дух. Кто-нибудь может сказать без гугла, кто сейчас CEO Кока-Колы? А этот продукт потребляют все. Лидер хорошо понимает этот момент и поддерживает даже на уровне лексики, чаще говоря «мы сделали», а не «я сделал».

Лидеры не занимаются микроменеджментом

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

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

Лидеры доброжелательны и уважительны

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

Да, третирующий подчинённых Джобс, достигал определённых успехов и выпускал революционные продукты, но его Apple был неустойчив, а порой и убыточен. Apple Тима Кука, излучающего доброжелательность, рвёт по капитализации все компании мира.

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

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

Лидеры развивают людей

— А вы не боитесь, что они выучатся и уволятся?
— Я боюсь, что они не выучатся и останутся.

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

Лидер не жалеет времени на то, чтобы вглядываться в подчинённых, находить их сильные стороны и предлагать варианты развития этих сильных сторон. Он периодически проводит встречи один на один и не только сообщает сотруднику, где и как он накосячил, но и как ему развиться в более крутого специалиста.

Лидеры говорят: «Давайте сделаем это!», а не: «Сделайте это!»

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

Даже на удалёнке, если вы потребовали от программиста не ложиться спать, пока не исправит важный дефект, сами оставайтесь на связи, пока он не отпишется о готовности, чтобы при необходимости ответить на его вопросы, а в конце перепроверить, всё ли он правильно поправил.

Лидеры берут на себя вину и делят успех на всех.

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

Успех же лидер напротив, делит на всю команду и подчёркивает, что это общее достижение, даже если сам сделал большую часть работы.

Лидеры сосредоточены на дальних перспективах

Боссов было много в девяностые. Взять у первого клиента предоплату за крупную партию товара, потом у второго другую предоплату, у третьего третью, купить джип «Гранд Чероки» и десять ящиков водки, джип разбить, офис заблевать, быть застреленным. Сейчас времена стали поцивилизованней, но боссы, всё равно, сосредоточены на целях, максимум, ближайшего квартала. Очень мало кто думает на год вперёд, а план на десять лет есть, вообще, у единиц.

Да, реалии нашей страны диктуют краткосрочное планирование, но лидера без стратегии, всё равно, не бывает.

Лидер — в первую очередь, ваш коллега

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

Будьте лидерами, а не боссами.

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

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

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

Хороший менеджер должен одинаково хорошо владеть как директивным, так и вопрошающим стилем и уметь их применять.

Если у вас большой и разлапистый комплекс софта, можно избежать многих дискоммуникаций между командами, если сделать и поддерживать актуальным словарь терминов.

Задача этого словаря — сделать так, чтобы одни и те же вещи назывались в разных командах одними и теми же словами и наоборот, чтобы одни и те же слова означали одни и те же объекты и процессы.

Только не делайте из словаря карго-культ, не надо записывать туда git, dns и https, только специфичные для вашей предметной области термины.

Столкнулся с проблемой. Punto Switcher версии 2.1.2 после выхода из ждущего режима macOS Catalina выгружается из памяти. Приходится запускать его заново или страдать от необходимости постоянно стирать и перенабирать текст, набранный не в той раскладке. Проблема лечится.

Открываем системные настройки → Пользователи и группы → Объекты входа

Убираем из объектов входа Punto Switcher.

Открываем текстовый редактор и создаём файл со следующим содержимым:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>user.launchkeep.puntoswitcher</string>
  <key>KeepAlive</key>
  <true/>
  <key>Program</key>
  <string>/Applications/PuntoSwitcher.app/Contents/MacOS/PuntoSwitcher</string>
</dict>
</plist>

Сохраняем файл с именем user.launchkeep.puntoswitcher.plist

Кладём файл в Библиотеки → LaunchAgents (Понадобится ввод админского пароля)

Завершаем сеанс на маке и авторизуемся заново. Проблема решена.

Если вам понадобится зачем-то выгрузить Punto Switcher, воспользуйтесь консольной командой:

launchctl remove user.launchkeep.puntoswitcher

Таким образом вы можете запретить выгрузку любого другого приложения, поменяв имя файла и параметры внутри xml-ки.

Если загуглить слово «микрокоманда», поисковик возвращает множество статей про устройство микропроцессоров. Я хотел бы рассказать о немного другой микрокоманде — практике группового подхода к разработке. 

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

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

Микрокоманда периодически собирается и обсуждает написанные аналитиком требования. Как известно, цена ошибки на этапе проектирования минимальна, в отличие от ошибок на более поздних стадиях. И как раз, для вылавливания таких ошибок нужна микрокоманда. Тестировщик и разработчик имеют мышление, отличное от мышления аналитика и видят доработку под другими углами, поэтому их мнение на этапе написания требований чрезвычайно важно. 

Микрокоманда может и должна собираться и во время разработки, чтобы разработчик мог задать вопросы, которые возникли у него по мере технологического проектирования и написания кода. Большинство джунов и многие мидлы формулируют самые интересные вопросы не когда знакомятся с требованиями, а когда непосредственно приступают к продумыванию структуры классов и модулей и других технических штук. 

Микрокоманда полезна и на этапе тестирования/приёмки. Аналитик может произвести приёмочное тестирование, чтобы понять, что разработчик сделал именно то, что хотел бизнес, а также, что основной поток работает. Тестировщик протестирует уже более глубоко и может выявить баги в кейсах, не описанных в требованиях, сообщив об этом аналитику, чтобы тот в режиме пожара дособрал требования и кейс был запрограммирован уже корректно. 

Микрокоманда должна периодически собираться и обсуждать обстановку по доработке, специфика каждой встречи зависит от этапа, на котором разработка находится. Подход с микрокомандами позволяет сделать разработку достаточно комфортной, осознанной и минимизировать баги.

Если специфика разработки такова, что доработки пилятся всей командой одновременно или мы имеем дело с классическим проектом, будет более эффективна практика overview of requirements. Микрокоманда в этом случае не собирается, а аналитик, написав требования, засылает их тестировщикам и разработчикам, они эти требования ревьюят, формируют список вопросов, собирается встреча, на ней решается судьба каждого вопроса. Эта практика тоже вполне жизнеспособна.

В целом, я не люблю созваниваться. Во время групповых созвонов в моём сознании тикает таймер суммарных трудозатрат на этот созвон, который компании придётся оплатить. Один час на шестерых = шесть человекочасов. По самым скромным оценкам, двенадцать тысяч рублей за поговорить, а если там программисты, то и больше. 

Но некоторые встречи пиэм всё же должен проводить. Поговорим о них. Говорить будем о неком усреднённом скраме, который чаще всего применяется в современной разработке. Я знаю, что в классическом скраме пиэма нет, но на практике всегда нужен человек, которому больше всех надо и без работы вы не останетесь. 

Оценка задач

Существует священное правило. Оценивает тот, кто будет делать. Как минимум, та же команда, которая будет делать, так как не всегда понятно, какой именно разработчик. Вполне нормальная практика — устраивать сессии покера планирования. Я считаю, что лучше провести две часовые встречи в неделю, чем одну двухчасовую, потому что внимание рассеивается. 

А в остальном, покер как покер. Программисты рассматривают задачи с детализированными требованиями, задают вопросы аналитикам, голосуют, вытащившие карточки с экстремумами объясняют свою точку зрения, ну не мне вас учить. 

Статус

Я имею в виду статусную встречу с заказчиком. Заказчик может быть из компании-клиента в случае заказной или бизнес-подразделения, если мы говорим о продуктовой разработке. Крайне желательно, чтобы вы знали оперативную обстановку так, чтобы могли проводить эту встречу без привлечения разрабов и тимлида. Рассказываете заказчику, как обстоят дела с задачами, какие консёрны, какие блоки с его стороны или со стороны других продуктов, не двигаются ли сроки. 

Планирование спринта

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

А пока взаимопонимание не достигнуто, частота таких встреч зависит от длины ваших спринтов и проводится перед каждым спринтом. Подбиваете хвосты, которые переходят в следующий спринт, оставшееся время забиваете новыми задачами в соответствии с приоритетами заказчика. 

Ретроспектива

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

Демо

Худшее, что вы можете сделать с законченной доработкой — это скинуть заказчику ссылку на неё и предложить самостоятельно ознакомиться. Нужно проводить полноценные демо, на которых показывать заказчику, что у вас получилось и как это работает. Вам решать, кто это должен делать, вы лично или аналитик с разрабом. 

Я против массовых демо на три часа, на которых показывается целый релиз за один раз. Очень тяжело присутствовать на таких встречах, внимание рассеивается, легко упустить важное. Лучше проводить демо по мере готовности доработок, после того, как данная доработка пройдёт приёмочное тестирование. Но заказчик может оказаться занятым и не пойти навстречу. Тогда придётся идти по плохому варианту и договариваться о гигантских трёхчасовых демо. В любом случае, демо нужны. 

Дейлики

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

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

Воспользуемся для типизации заказчиков теорией темпераментов Гиппократа-Галена — холерики, сангвиники, меланхолики, флегматики. Разберём, как работать с заказчиком каждого темперамента. 

Дальше будет пересказ нескольких глав из книги Бориса Шпирта «Отчаянные аккаунт-менеджеры».

Холерики

Холерики — вспыльчивые, эмоциональные люди с сильной волей. Они нечувствительны к эмоциям других и прут напролом. Предпочитают принимать решения и действовать быстро, не вникая в детали. Холерики часто бывают визионерами, среди них множество владельцев бизнеса, политиков (Тиньков, Трамп, Жириновский). Получить холерика в качестве заказчика весьма вероятно. 

В деловых отношениях холерик будет стремиться занять позицию «сверху вниз» и доминировать над вами, однако выстроить с ним партнёрские отношения возможно, дав определённый отпор. 

В процессе переговоров с холериком, не растекайтесь мысью по древу, будьте ёмки и кратки. Долгие ответы и подробные объяснения людей с этим типом темперамента раздражают. На срочные вопросы от такого клиента реагируйте максимально оперативно, иначе он воспримет это как тормознутость и некомпетентность. 

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

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

Сангвиники

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

В работе с сангвиником лучше пойти у него на поводу, разрешить называть себя на «ты». Если будете пытаться держать дистанцию — он огорчится и продуктивных отношений не получится. 

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

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

Меланхолики

Меланхолики часто не уверены в себе, любят советоваться с коллегами. Клиенты такого типа обожают привлечь к рассмотрению вариантов дизайна всех сослуживцев и соседей по подъезду, затянув переговоры до чрезвычайности. Меланхолики тонки и ироничны, способны переживать как трагедию то, что сангвиник принял бы за просто интересный кейс. Меланхоликам трудно карабкаться вверх и делать карьеру, поэтому вероятность встретить такого клиента невелика. Они чаще актёры (например, Робин Уильямс), писатели, художники. В бизнесе их можно встретить на креативных должностях. 

В отношениях с меланхоликом вы можете сами стать той самой опорой и внешним подтверждением их идей, в котором они так сильно нуждаются. Как только он убедится, что вы такого доверия достойны, он с радостью доверит вам эту роль. Эмпатически выслушав жалобы меланхолика на жизнь, судьбу и руководство, вы можете расположить его к себе, хоть это и трудно, а также энергозатратно. Ответные откровения в этих беседах не нужны, имейте в виду. 

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

Меланхолики мнительны, поэтому им нужны подробные периодические отчёты о ходе проекта. Зато, если вы заслужите доверие такого клиента, он будет работать с вами годами. 

Флегматики

Флегматики общаются чётко и по делу, держатся ровно. У них не бывает вспышек ярости, как у холериков или потоков шуток, как у сангвиников. Флегматики обожают копаться в деталях, поэтому так часто встречаются среди айтишников, где такая черта характера необходима для выживания, либо в бухгалтерии или аудите. Если вы — мой коллега-айтишник, вероятность встречи с таким заказчиком для вас средняя. 

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

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