Текст книги "Управляю проектом как Бог. Все, что нужно знать о проджект-менеджменте"

Резюме главы

Мы разобрались в том, как готовиться к переговорам. Подробный алгоритм подготовки вы можете найти в Приложении 1.

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

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

Глава 2
Работа с командой

Тот, кто воображает, что может обойтись без других людей, очень ошибается; а тот, кто воображает, что другие не могут обойтись без него, ошибается ещё больше.

Франсуа де Ларошфуко

Почему команда важна

Должен ли менеджер быть командным игроком? Вопрос неоднозначный, на мой взгляд. Это зависит от корпоративной культуры компании. Если она использует scrum[4]4
  Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.


[Закрыть], agile[5]5
  Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта. Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану». – Прим. ред.


[Закрыть] –подходы и вообще является бирюзовой[6]6
  Бирюзовые организации часто называют организациями будущего или живыми. В них отсутствуют KPI, контроль со стороны руководства, да и самого руководства тоже нет. Термин «бирюзовое управление» совсем молодой, его ввел консультант и бывший партнер McKinsey & Company Фредерик Лалу в 2014 году. Хотя организации, придерживающиеся этого принципа менеджмента, существуют еще с середины XX века. Лалу разделил компании по цветам согласно их управленческой модели, где красный соответствует самой импульсивной и неорганизованной, а зеленый – наиболее близкой к современному человеку осознанной организации с социальной ответственностью. Но Лалу понял, что это не последняя ступень, и выделил бирюзовую – эволюционную модель. – Прим. ред.


[Закрыть], то, скорее всего, да. Хотя опытный читатель может возмутиться – какой менеджер в аджайле? Однако бывает и такое.

А что, если в компании четкая структура и иерархия? Тогда, скорее всего, менеджер – уже не командный игрок, а управленец.

Все это не умаляет того факта, что с командой нужно работать. Большие дела не делаются в одиночку. Я часто вспоминаю, например, про Федора Конюхова[7]7
  Федор Конюхов – советский и российский путешественник, писатель, художник, священник Украинской православной церкви (Московского патриархата). В одиночку совершил пять кругосветных плаваний, 17 раз пересёк Атлантику, причём один раз на вёсельной лодке. – Прим. авт.


[Закрыть] или Ника Вуйчича[8]8
  Ник Вуйчич – австралийский мотивационный оратор, меценат, писатель и певец, рождённый с синдромом тетраамелии – редким наследственным заболеванием, приводящим к отсутствию всех четырёх конечностей. – Прим. авт.


[Закрыть]. На первый взгляд, это люди, которые делают свое дело сами. Но давайте подумаем, смог бы Ник Вуйчич добиться известности без поддержки родителей и друзей? Смог бы Федор Конюхов переплыть Атлантику без предварительной подготовки, с которой ему помогали единомышленники? Вряд ли. За их достижениями стоят люди, команда.

Как запустить команду

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

1. Составьте мнение о себе через маленькие победы: поручите установить в офисе кофемашину, договоритесь с руководством и закупите новые мобильные устройства для сотрудников, определите, что мешает людям работать, возможно это чрезмерная отчетность. Действительно ли нужны дневные или еженедельные отчеты? Что, если их отменить? Если все-таки нужны, попробуйте упростить этот процесс или возьмите часть работы на себя. Изменения могут быть маленькими, но обязательно видимыми.

Кейс из практики: на одном из проектов понадобилось тестировать мобильное приложение на последней версии iPad. Помимо запроса от клиента, я собрал статистику использования в разрезе типов мобильных устройств. Последняя версия iPad была на втором месте из восьми самых популярных. Это был весомый аргумент в пользу их закупки. В дальнейшем все запросы на покупку новых устройств проходили через меня. Логику коллег можно понять – «У него это получается лучше».

2. Организуйте объединяющие события. Решение общих проблем, например прохождение внутреннего аудита или получение новых компьютеров, серверов поможет в этом. Об этом я подробнее расскажу чуть позже, в разделе «Как мы починили QA-процессы».

3. Попробуйте договориться со своим руководителем и сыграйте в игру «Хороший полицейский, плохой полицейский». Например, прикрыв команду от выполнения дополнительных задач.

Кейс из практики: когда я еще был разработчиком, мы выполняли проект для компании, где действовали строгие правила в отношении всего и IT в частности. То есть для того, чтобы развернуть бэкап базы данных на тестовом сервере, необходимо было писать заявку в техподдержку и получать одобрение от нескольких менеджеров. Бюрократичненько. Некоторая часть работ выполнялась непосредственно из офиса заказчика. Мы работали набегами, то есть по 3-4 часа один раз в пару недель, поэтому закрепленных за нами мест не было, каждый раз нам давали новые компьютеры в разных кабинетах. В очередной заезд мы – я и мой коллега-разработчик – усаживаемся за компьютеры. Наш менеджер уходит в другой офис делать свои менеджерские дела. Через некоторое время входит один из сотрудников заказчика, который никоим образом не имел к нам отношения и заявляет, что, исходя из политики компании, мы не должны сидеть за этими компьютерами. Я прикинул, что поиск новых мест может занять время, а это значит, что до обеда мы не управимся. Все попытки договориться с ним ни к чему не привели. Тут заходит наш менеджер и говорит, что сам все решит, берет сотрудника за локоть и уводит его в коридор. Я не знаю, что именно он сказал, но после этого к нам больше никто с претензиями не подходил.

Почему это работает? Люди запоминают события последовательно. То есть если после вашего прихода стало чуточку лучше, появились какие-то интересные вещи, то сотрудники это запомнят. Со временем такие воспоминания конвертируются в авторитет.

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

Как я потерял двух сотрудников и обрел счастливую команду

Какие мотивационные инструменты помогают настроить команду на продуктивный лад и предотвратить внезапные увольнения.

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

История эта началась пару лет назад в IT-компании, где я и сейчас тружусь менеджером проектов. У меня небольшая команда, количество сотрудников варьируется от проекта к проекту, но основной костяк – пять человек. Мы занимаемся обеспечением качества, в том числе тестированием, а также конфигурацией нашего софта под нужды клиентов.

В какой-то момент я заметил, что люди приуныли, работа была в тягость, за редким исключением – когда появлялись интересные задачи. Что, если провести нагрузочное тестирование, написать автотест, настроить нетривиальный рабочий процесс? Это интересно и драйвово. В голове всплывали отрывки из книги «Как пасти котов», что-то из Адизеса и Демарко про работу с командой.

Личные встречи с сотрудниками

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

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

И вот дело закрутилось – я назначал встречи раз в 3-4 недели. Одна беседа длилась примерно полчаса. В среднем у меня уходило на это 2-2,5 часа в неделю. Не такая уж и большая цена? Команда немного оживилась, это было видно по действиям и результатам. До поры до времени все шло неплохо. Мы нащупали общие темы и стали более сплоченными. Показалось, что драйвовых моментов стало больше, люди вовлекались в процесс.

Первым звоночком стал уход одного из тестировщиков. Для меня это был шок. Как так? Мы ведь разговаривали всего полтора месяца назад, и тогда было все хорошо! Как потом выяснилось, за прошедшее время многое произошло. Близился конец года – соответственно, дедлайны, перегруз и апатия. За этот период я не провел ни одной встречи – дедлайны же.

Второй звонок был через несколько месяцев – ушел второй тестировщик. На прощальном разговоре выяснилось, что ему надоела рутинная работа. Но как так-то? Он же сам говорил, что ему нравятся тихие, спокойные задачи, которые можно медленно, но верно «пилить». Да, нравились, но потом как-то надоели.

Тогда я крепко призадумался. Люди увольняются, на поиск новых специалистов уходит несколько месяцев, потом – период адаптации, а работу в это время надо выполнять. Прописная истина, однако. Слишком дорого и долго. Я понял, что в проведении встреч такого формата есть ряд подводных камней. Вот, что я выделил для себя:

1. Есть соблазн пропустить встречу

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

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

2. Может возникнуть ощущение «обязаловки»

После нескольких месяцев личных встреч может оказаться, что сотрудникам нечего сказать. Может возникнуть ощущение – «надо, значит, надо».

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

Какие могут возникнуть проблемы?

Неправильная продажа идеи. При внедрении любой практики нужно показать людям, что ваше предложение ПОЛЕЗНО и БЕЗОПАСНО. В конце я дам ссылку на шаблон письма, которое рассылал сотрудникам, когда приглашал на встречу.

Игнорирование чужих проблем. Важно слушать и слышать человека, узнавать, что его беспокоит или мешает ему.

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

Фиксируем договорённости и с этого начинаем следующую встречу.

Недостаточное внимание человеку на встрече. Одна из целей – дать возможность сотруднику рассказать о своих делах. Если говорит только руководитель – это не встреча, а просто оценка.

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

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

Под одну гребенку. С некоторыми сотрудниками встречи могут быть короткими, но эффективными (легкими), с некоторыми длинными и тягучими (тяжелыми) – это зависит от темперамента сотрудников. Частота встреч для разных специалистов может быть разная.

ОПРОСНИК ПО МОТИВАЦИОННЫМ ФАКТОРАМ

Хочу предложить вам еще один инструмент – опросник по мотивационным факторам[9]9
  Ссылку на опросник см. в Приложении 3.


[Закрыть]. Он позволяет определить главные мотиваторы для сотрудника, что в конечном итоге позволяет сформулировать глобальную цель, движение к которой будет мотивировать. Таким образом, если рабочие задачи будут приближать сотрудника к цели, то можно будет говорить о мотивации на текущем месте работы.

На заполнение такого опросника в среднем требуется 10-15 минут.

Как заполнять опросник

Выделяем 7 главных мотивационных факторов и ранжируем их деньгами, проставляя соответствующую сумму в столбце $$$:

• $3000 – главный мотивационный фактор.

• 2×$2000 – два мотивационных фактора поменьше, но тоже важных.

• 2×$1000 – еще два мотивационных фактора, ценность которых ниже, чем у предыдущих.

• 2×$500 – еще два мотивационных фактора, ценность которых, по вашему мнению, ниже, чем у предыдущих.

• Далее напротив каждого из 7 уже отмеченных деньгами фактора в столбце «Д» (достижимость) проставляем значение от 0 до 2, где:

• 2 – текущая работа дает мне то, что меня заводит (мотивационный фактор).

• 1 – возможно дает.

• 0 – не дает.

Количество 2, 1 и 0 не лимитировано.

После этого перемножаем значения в столбцах $$$ и «Д» и записываем в третий столбец.

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

GROW-подход

Я попросил членов своей команды заполнить опросник. Результаты оказались разными, но главное – мне было с чем работать. В этом мне помог подход GROW, который часто используют в коучинге. Вкратце: он позволяет выработать сценарии «прокачки» тех мотивационных факторов, которые важны для человека.

Например, для сотрудника важен фактор «Быть креативным». Согласно подходу GROW, делим обсуждение на четыре этапа:

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

2. Reality – Реалии. Далее я прошу рассказать, что в текущей ситуации он предпринимает, чтобы реализовать возможности. Сотрудник отмечает, что он использует в работе JMeter (в организации есть порядок проведения экспертизы и кейсы для этого инструмента), но хотел бы расширить кругозор.

3. Options – Варианты. Следующий вопрос: а что можно сделать, чтобы прокачать навыки, какие вообще сценарии возможны? Важно сгенерировать как можно больше вариантов – чем креативнее, тем лучше. Но в итоге нужно определиться и выбрать те, которые можно реализовать. Сотрудник что-то слышал про Gatling и Яндекс. Танк.

4. Wrap-up – Итоги. На финальном этапе определяем конкретные действия, возможные препятствия и временные рамки.

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

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

На что стоит обратить внимание при обсуждении:

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

• При выборе вариантов следует использовать не только системный, но и творческий подход. Порой самые необычные варианты могут принести значимый результат.

• Необходимо активно слушать и подмечать важные для сотрудника нюансы.

Что получилось

Улучшился общий настрой, выросла производительность, причем не только за счет драйва, но и за счет оптимизации процесса выполнения тест-кейсов, сокращения времени обучения новым фичам[10]10
  Фича (англ. feature) – в жаргоне программистов, геймеров и других пользователей компьютеров, какая-нибудь недокументированная дополнительная возможность, фишка. – Прим. ред.


[Закрыть]. А значит, ускорилась скорость поставки результатов клиентам.

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

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

Упражнение

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

Как мы починили QA-процессы и выстроили системную работу

Как уйти от хаоса в тестировании и выстроить системную работу QA-команды.

Одним из направлений моей деятельности является курирование QA-команды (Quality assurance – Обеспечение Качества). К нам приходят разноплановые задачи – от банальных проверок исправленных багов до создания некой фичи путем конфигурации софта. Здесь же и регрессионное тестирование, и end-to-end – сквозное тестирование.

Сейчас я оговорюсь – может показаться, что это скрам, или канбан[11]11
  Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач. Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др. – Прим. ред.


[Закрыть], или что-то из той же серии. Все верно, вам не кажется. Это некая смесь гибких техник, к которой мы внутри своей небольшой QA-команды пришли опытным путем. Главное – это всех устраивает и дает результат.

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

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

Как мы проводим ежедневные брифинги

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

Этот подход позволяет:

• повысить индивидуальную ответственность за результат в команде;

• повысить результативность и ясность;

• выстроить процесс с минимальным вмешательством в непосредственную работу.

Так как наша команда распределенная, такие брифинги мы проводим через GoToMeeting. Это платформа для проведения совещаний, где можно показывать свой экран, рисовать на нем и, что наиболее полезно, записывать собрания.

Важно проводить брифинги в одно и то же время. Почему? Брифинг нужен в первую очередь для того, чтобы гарантированно сфокусировать себя и команду в начале рабочего дня. К тому же у сотрудников вырабатывается чувство ритма.

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

Цикл Деминга (или Цикл PDCA – Plan-Do-Check-Act) – инструмент, который позволяет наладить процесс изменений, сделать его системным и последовательным. Это цикл улучшений, цикл повышения качества продукта и его ценности. Он включает в себя 4 этапа: планирование – осуществление – проверка – претворение в жизнь.

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

Так вот, если мы с утра не собрались и не скоординировали общие действия, то мы будем делать это целый день – звонить, отвлекать друг друга. PDCA цикл будет разрываться.

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

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

Постановка задач команде

С точки зрения делегирования, задачи можно разделить на два вида:

• Типовые – регламентированные, они повторяются из раза в раз. Например, прохождение чек-листов.

• Нетиповые – такие задачи раньше не выполнялись, они обладают высокой степенью неопределенности.

Если с типовыми все более-менее понятно, то к нетиповым задачам мы применяем специальный подход, который включает в себя четыре этапа.

ПЕРВЫЙ ЭТАП – определяем, зачем нужна задача

Стоит задать себе вопрос: зачем конкретно эта задача нужна мне, команде или нашей компании? Ключевой момент – задавая этот вопрос, мы отметаем те задачи, которые нам не нужны.

Конечно же, есть минус – приходится постоянно находиться в осознанном состоянии и думать: что я хочу получить? Это нагрузка на сознание.

Существует еще один тонкий момент: если я себе не ответил на этот вопрос, то и сотруднику будет трудно объяснить, зачем эта задача нужна. Значит, при исполнении задачи могут возникнуть проблемы. Если сотрудник не понимает, что и почему он делает, то сам себе дорисовывает картину на основании своего уровня экспертизы.

ВТОРОЙ ЭТАП – представляем результат

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


[Закрыть] для демки». Какой здесь риск?

Я-то понимал, что пойду на встречу с клиентом, за 15 минут должен буду донести ключевую ценность своего продукта и показать дашборд буквально с 2-3 чартами из будущего проекта. Осознавал, что это пятнадцатиминутная демка, и что детали пока не важны. Но сотрудник всего этого не знал.

К чему это привело? Он «дорисовал картинку» сам, сделал дашборд с 25 чартами и анимацией, которая показывала всю мощь нашей системы по работе с аналитикой. Но все жутко тормозило. Из-за того, что ожидаемый результат не был согласован, мы потратили лишние силы команды и не добились нужного от клиента.

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

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

ТРЕТИЙ ЭТАП – записываем задачу

Мы используем следующую формулировку: название проекта + задача, которая начинается с глагола в совершенном виде – «сделать», «выполнить», «сконфигурировать».

Глагол должен описывать получение конкретного результата, так что отметаем все лишнее. В заголовке лучше писать 5-7 слов, не более.

Фиксируем задачку в Trello[13]13
  Trello – облачная программа для управления проектами небольших групп, разработанная Fog Creek Software. Trello использует парадигму для управления проектами, известную как канбан. – Прим. ред.


[Закрыть], где она доступна всей команде, и каждый может дать обратную связь. Об этом еще поговорим немного позже.

Ставим дату исполнения, но только если задачу или ее часть нужно выполнить до окончания спринта[14]14
  Спринт – это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы. Спринты лежат в основе методологий scrum и agile.


[Закрыть].

ЧЕТВЕРТЫЙ ЭТАП – определяем исполнителя

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

– Скажи мне, что от тебя требуется?

– Нужно сделать то-то и то-то.

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

Как вы думаете, в чем здесь минус?

Мне нравится фраза Майкла Хардинга Роберта, автора «Project Management Book»: «Из нескольких возможных интерпретаций коммуникации наименее удобная является самой правильной».

Осознания не произошло!

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

Планируем задачи команды

Я говорил про брифинги. Они должны опираться на осознанную расстановку приоритетов задач. К тому же все в IT любят отслеживать свои задачки. Мы используем для этого Trello, с таким набором списков:

• В «Проектах и идеях» держим карточки крупноуровневых задач и проектов, которые внутри разделены на более мелкие. Затем мелкие перетаскиваем в список «Все задачи».

• В списке «Все задачи» перечислены задачи, которые нам предстоит реализовать примерно в течение 1-1,5 месяцев, т. е. в обозримом будущем.

• В начале недели, обычно это понедельник, мы накидываем задачи из списка «Все задачи» в «Спринт», тем самым планируя загрузку. При этом стараемся оставить небольшой запас времени на работу над внезапными задачами, которые могут появиться.

• В «Спринт» мы перетаскиваем те задачи, которые, по общему мнению, мы реально выполним в течение недели.

• «Сегодня в работе» – название говорит само за себя – задачи, над которыми работаем сегодня. Мы используем лейблы для придания контекста статусу задачи, но есть общее правило – приоритетные задачи находятся сверху.

• «Девелопмент» – здесь мы отмечаем те задачи, которые будут или были назначены разработчикам, и мы ждем, пока они вернутся к нам.

• «Сделано» – сюда помещаются те задачи, которые были выполнены, протестированы и задокументированы. Мы выделяем каждую неделю. Например – неделя заканчивается 12 числа. Я завожу карточку и пишу название «12 февраля – закончить end-to-end тестирование мобильного приложения». Это значит, что приоритет на неделю – тестирование мобильного приложения. Плюс, мы видим сколько задач было сделано за рабочую неделю – это имеет мотивационный эффект. Мы сделали за неделю 25 задач. Ура, ура, мы – молодцы!

Помните, я говорил про 3 вопроса? Так вот, я прошу команду записать вечером заранее 3 текстовых ответа к завтрашнему брифингу, опираясь именно на карточки задач с нашей доски:

• в блок «Сделано» – все задачи, выполненные за завершенный рабочий день (сегодня), лежащие в колонке «Готово»;

• в блок «Планирую» – все задачи, находящиеся в колонке «Сегодня в работе»;

• в блок «Мешает» – трудности и сложности, которые могут помешать выполнить план на завтра.

Это позволяет осознать, что надо будет сделать завтра, и на брифинге не нужно будет мучительно долго вспоминать – что же я вчера сделал, и что мне осталось доделать сегодня.

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

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

Разберитесь, в чем причина. Почему человек делает работу некачественно? Достаточно ли ему ваших встреч тет-а-тет? Очень тонкий момент: если у него есть проблема, не пытайтесь ее ликвидировать. Вспомните про GROW-подход и подтолкните сотрудника к поиску решения и его реализации. Если вы разберетесь с его проблемой, то с большой долей вероятности это войдет в привычку.

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

Упражнение

Подумайте, какие задачи чаще всего встречаются в вашей работе? Типовые или нетиповые? Понимаете ли вы, зачем их нужно выполнять? Понимает ли команда? Можете представить конечный результат? Опишите любую задачу, используя всего 5-7 слов и глагол, связанный с результатом. Попробуйте поработать так в течение недели.

Как наладить коммуникации между командами

Что делать, если большой проект делается несколькими командами, и все общение сводится к фразочкам: «Да опять эти наворотили…»? Работа вроде идет, но часто случаются «пробуксовки». Налицо проблема – напряженность во взаимоотношениях между командами. Есть разделение на «наших» и «чужих».

В основе взаимоотношений между командами лежит принцип взаимного обмена – об этом много писал Роберт Чалдини в своей книге «Психология влияния[15]15
  Чалдини Р. Психология влияния. Убеждай, воздействуй, защищайся. – СПб.: Питер, 2010. – 336 с.


[Закрыть]». Важно не требовать или выпрашивать что-то у сотрудников, а сначала самому это дать.

Приведу в пример две истории.

История про помощь

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

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

Когда нас пропустили, мы продолжили разговор. Через некоторое время я вспомнил, что это один из координаторов. Мы работали с ним полгода назад. Он запомнил меня, потому что во время выполнения проекта я был одним из немногих, кто отвечал и помогал пользователям в свое нерабочее время. Для заказчика это было важно – производство работало круглосуточно.

История про «непочтальона»

Одно время я работал вахтовым методом в нефтегазовой компании. Организация предоставляла жилье. Это была трехкомнатная квартира, где проживали вахтовики. Основной костяк был из соседних городов. В какой-то момент у нас случилось пополнение, пришел новый сотрудник. Он был один из немногих, кто приезжал на вахту на своей машине. И вот под конец первой смены один из «старичков» попросил новичка передать посылку домой, так как они были из одного города. На что он заявил, что не нанимался работать почтальоном.

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

Это плохо или хорошо? Мне кажется, это зависит от культуры общения внутри группы, как в данном примере, или же от организации в целом.

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