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

Tekst
5
Recenzje
Przeczytaj fragment
Oznacz jako przeczytane
Jak czytać książkę po zakupie
Nie masz czasu na czytanie?
Posłuchaj fragmentu
Управляю проектом как Бог. Все, что нужно знать о проджект-менеджменте
Управляю проектом как Бог. Все, что нужно знать о проджект-менеджменте
− 20%
Otrzymaj 20% rabat na e-booki i audiobooki
Kup zestaw za 27,99  22,39 
Управляю проектом как Бог. Все, что нужно знать о проджект-менеджменте
Audio
Управляю проектом как Бог. Все, что нужно знать о проджект-менеджменте
Audiobook
Czyta Вадим Пугачев
14,87 
Zsynchronizowane z tekstem
Szczegóły
Czcionka:Mniejsze АаWiększe Aa
Какие могут возникнуть проблемы?

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

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

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

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

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

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

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

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

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

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

На заполнение такого опросника в среднем требуется 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]. А значит, ускорилась скорость поставки результатов клиентам.

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

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

Упражнение

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

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

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

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

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


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

 

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

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

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

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

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

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

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


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

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

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



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

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

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

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

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

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

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

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

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


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


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

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

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

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


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

Нужно определить, какой результат хотим увидеть. Простой пример: я поручил специалисту задачу – «настроить дашборд[12] для демки». Какой здесь риск?

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

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

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

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


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

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

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

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

Ставим дату исполнения, но только если задачу или ее часть нужно выполнить до окончания спринта[14].


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

9Ссылку на опросник см. в Приложении 3.
10Фича (англ. feature) – в жаргоне программистов, геймеров и других пользователей компьютеров, какая-нибудь недокументированная дополнительная возможность, фишка. – Прим. ред.
11Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач. Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др. – Прим. ред.
12Дашборд (или инфопанель) – это умные отчеты в реальном времени, с помощью которых руководители и менеджеры понимают, что прямо сейчас происходит с определенными показателями и группами показателей. – Прим. ред.
13Trello – облачная программа для управления проектами небольших групп, разработанная Fog Creek Software. Trello использует парадигму для управления проектами, известную как канбан. – Прим. ред.
14Спринт – это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы. Спринты лежат в основе методологий scrum и agile.
To koniec darmowego fragmentu. Czy chcesz czytać dalej?