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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

launchctl remove user.launchkeep.puntoswitcher

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

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

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

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

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

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

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

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

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

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

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

Оценка задач

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

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

Статус

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

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

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

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

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

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

Демо

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

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

Дейлики

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

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

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

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

Холерики

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

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

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

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

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

Сангвиники

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

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

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

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

Меланхолики

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

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

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

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

Флегматики

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

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

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

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

Несколько слов о том, как поступать не следует.

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

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

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

Четвёртая ошибка— вместо руководителя обсуждать вопрос повышения с коллегами. Даже если вам не запретили разглашать зарплату через NDA (что, кстати, незаконно) и в вашей компании принято суммы не скрывать, вопрос этот достаточно интимный и обсуждаться должен только с руководителем. Коллеги не имеют полномочий повысить вам зарплату, а руководитель, если узнает об этих разговорах, может решить, что зреет бунт и нужно принимать меры.

Как действовать не надо, разобрали. Теперь как надо.

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

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

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

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

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

Пожалуйста, сначала произнесите его имя, а только потом просьбу, а не наоборот, как делает 99 % больших начальников. То есть:

⛔️ Неправильно: Нужно принести, пожалуйста, в жертву козла, а затем прыгнуть в портал. Сергей, сделаешь?!
✅ Правильно: Сергей! <пауза для пробуждения Сергея> Принеси, пожалуйста, в жертву козла и прыгни в портал. 

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

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

—  Нильс Хенрик Давид Бор

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

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

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

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

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

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

Теперь самое важное. Как нужно было вести себя, чтобы из этой ситуации вылезти. Ситуации, когда скоуп проекта не определён, допускать нельзя. Окажись я в таком положении сейчас, действовал бы так. В первые же дни собрал встречу с заказчицей и своим гендиром, как бы он ни был занят, и заставил проговорить, что обязательно должно быть в первой итерации, потом оценил эти работы с командой заново, потом составил документ и подписал вместе с договором.

И напоследок бонус. Чтобы определить базовые приоритеты заказчика, можете ему подсунуть на заполнение вот такую простенькую табличку:

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

Ранее я писал, какие вопросы задают на собеседовании на project manager-а. Вот вопросы и ответы для бизнес-аналитика.

Какой основной инструмент бизнес-аналитика?

Единственный правильный ответ — критический ум. Перечисление программных продуктов, при помощи которых вы пишете требования, будет ошибочным.

Какие знаете методологии разработки?

Классический проектный подход (PMI), скрам, канбан. В принципе, этого достаточно.

Какие бывают требования?

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

Также можно рассказать про уровни требований:

• бизнес-правила,
• бизнес-требования,
• пользовательские требования,
• требования к продукту.

Также можно рассказать про типы требований:

• ограничения,
• требования к графическим интерфейсам,
• требования к данным.

Какими свойствами обладают хорошие требования?

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

Какие существуют методы сбора требований?

• интервью,
• анкетирование-опрос,
• фокус-группа,
• семинар,
• мозговой штурм,
• совещание,
• ролевая игра,
• обсервация,
• моделирование процессов,
• прототипирование,
• анализ вариантов использования,
• анализ интерфейсов.

Как строится процесс работы с требованиями?

Требования нужно:

• собрать,
• задокументировать,
• проанализировать,
• управлять ими.