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

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

Упражнение:

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

Работа с руководством

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

По приведенному мной алгоритму^[2] решается большинство проблем в коллективе.

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

Предыстория

Головной офис компании ООО «Ясность Inc.» находится в Москве, там живет один-единственный топ-менеджер, он же владелец фирмы, Тимофей Александрович. В Екатеринбурге расположен филиал – офис разработки. Им управляет директор Антон. У него в подчинении местные разработчики, тестировщики и руководители проектов. Львиная доля управления осуществляется из Москвы.

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

Руководство:

• Тимофей Александрович – CEO, красно-желтый по системе DISC, интегратор по Адизесу^[3].

• Антон – директор, сине-зеленый по DISC, администратор.

• Петр – руководитель проекта, по DISC сине-красный, по Адизесу – администратор.

Подготовка к разговору:

Проблема:

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

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

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

Не желая снова попасть впросак, Петр решил переговорить с Антоном и выяснить, что же все-таки происходит.

Цель разговора:

Антон выберет одно из решений Петра по завершению проекта и пообещает защищать его перед Тимофеем.

Анализ ситуации:

• Точка зрения Антона: что-то менять в системе сложно, долго, рискованно. Код уже отлажен и работает несколько лет. Очень не хочется что-то менять, так как это может повлечь за собой «поломку» всей архитектуры.

• Всегда ли он себя так вел? – Если не всегда, то часто. Не видно явного «триггера», после которого ситуация меняется.

• Когда именно это началось? – Возможно, давно, с момента открытия компании.

Четыре причины, почему человек ведет себя не так, как вы хотите:

• Перед ним стояла нечеткая цель или понял ее по-своему. – Второе вполне возможно, так как Тимофей Александрович не хочет разговаривать с Антоном на эту тему.

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

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

• Не хочет, так как это будет отнимать много времени и очень рискованно с технической точки зрения.

Цели и желания Антона:

• Меньше пристального внимания от топ-менеджмента.

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

• Достижение необходимых результатов.

Позитивное намерение:

Почему он так себя ведет? В чем может быть его позитивное намерение? Чего человек может добиваться своим поведением?

Он себя так ведет, потому что:

• Хочет делать работу правильно.

• Хочет выполнять приоритетные задачи.

Аргументы:

Как объяснить Антону, что его поведение противоречит его целям и позитивному намерению:

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

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

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

Сценарий разговора:

Петр: – Антон, спасибо, что уделил время, буду лаконичным. У меня какая-то каша в голове из-за этой ситуации с автотестами. Вы с Тимофеем Александровичем об этом вообще разговаривали? Просто у меня ощущение, что я чего-то не знаю.

Антон: – Нет, не разговаривали, но он упоминал, что поручил это тебе.

Петр: – Ок! Наверняка ты видел задачи, которые я создал и отправил в работу. На тот момент не было других важных задач, поэтому своим я поставил высокий приоритет, но они потом съехали вниз.

Антон: – Да, пришли новые клиенты.

Петр: – То есть это распоряжение Тимофея Александровича?

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

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

Антон: – Давай поручим это Ивану, но весьма вероятно, что ситуация повторится, и приоритеты все-таки поменяются. При случае можешь об этом сказать, мол, разработчики занимались подготовкой к презентации. Тем более в списке задач видно, кто и что делал.

Петр: – Ок, давай так и поступим.

Результат разговора:

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

Упражнение:

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

Резюме главы

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

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

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

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

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

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

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

Должен ли менеджер быть командным игроком? Вопрос неоднозначный, на мой взгляд. Это зависит от корпоративной культуры компании. Если она использует scrum^[4], agile^[5] –подходы и вообще является бирюзовой^[6], то, скорее всего, да. Хотя опытный читатель может возмутиться – какой менеджер в аджайле? Однако бывает и такое.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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