Управление проектами Scrum

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

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

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

Однако такая реальность существует только здесь и сейчас, но через, скажем, год, уже начинаются проблемы. Ясное дело, что некая бабушка, проработав 30 лет в учреждении, весьма активно составляет отчёты, которые сдаются в министерство. Она собирает в архиве все данные, что-то считает на калькуляторе, вносит в графы, а если вдруг ошибка – замазывает корректором. Естественно, ей ни к чему использовать специальную программу (а главное, учиться работать с ней), которая весь год собирает нужные данные, а во время отчёта требует лишь нажать одну кнопку – «Сформировать отчёт по форме Т-2М», и всё.

Бог бы с ними, с бабушкой и отчётами, но так как эта программа существует, так как время подготовки отчёта сокращается с 5 дней до 10 минут, значит у сотрудников появляется лишнее время (в теории). Министерство, не будь дураками, придумывает новые отчёты, расширяет сферы деятельности, то есть занимается, собственно, самодурством повышением эффективности. Вот она и проблема. Нововведение, позволяющее сократить и систематизировать работу, мы оттолкнули от себя, продолжили выполнять работу, как и раньше, по 5 дней, однако в довесок получили ещё 5 отчётов по 5 дней, а кредит дополнительными днями жизни пока ещё не дают...

Если говорить языком бизнеса, то из-за отталкивания от себя нововведений мы теряем дополнительные деньги в прогрессе. Сокращая любое действие в разы, мы увеличиваем производительность, что приводит к увеличению прибыли – привет, Kanban! Однако занимаясь постоянной самомодернизацией, мы уже получаем прибыль в разы больше начальной линии, оставаясь при этом одинаково загруженными, а это важно. В управлении проектами мы же не говорим о том, как навалить побольше работы на бедного сотрудника, чтобы получить больше денег. Мы говорим о том, как сделать так, чтобы каждому сотруднику было: а) очень легко и комфортно работать, б) у него были для этого самые продуманные инструменты, в) он не перетруждался и не уставал.

О чём мы сейчас говорим? Да конечно же о Scrum!

Способны ли мы принять Scrum в качестве метода управления проектами

Естественно, продвинутые пользователи сети Интернет могут найти множество статей по опыту внедрения Scrum в те или иные группы. Однако такие примеры чаще исключения, и пусть они очень желанны, но при этом очень утопичны. Во-первых, это какое-то непонятно слово, и многих, кто не в теме, оно пугает уже при первом знакомстве. Во-вторых, чуждая и непонятная структура, какие-то роли, митинги. «Нет, не хотим, не понятно ничего, у нас нет времени разбираться! » Так говорят многие, даже не пытаясь ознакомиться хотя бы малость.

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

Дальше от меня следует предложение: «Раз это не самый главный процесс, то над ним ведь можно сделать эксперимент – постараться улучшить. Говорю сразу, вам ничего изучать и понимать не нужно, просто всё систематизируем». Слово «систематизируем», благо, особо никого не пугает, оно знакомо с института многим. Для начала в нашей системе управления проектами Scrum Time я создаю, собственно, проект (людям вообще не важно, что мы занимаемся управлением проектами). Дальше предлагаю в свободной форме написать мне то, что вообще хочется получить в итоге. Никому никакого дела нет, что сейчас я буду исполнять роль Product Owner, и говорить про это необязательно. Перерабатываю всё в задачи, создаю список этих задач и спрашиваю, какие из этих задач нам бы хотелось сделать за месяц (мерка месяцами более привычна для большинства, когда сразу предлагаешь какой-то спринт на 2 недели – рыбка сорвалась и пора сматывать удочки). Естественно, незнающий ничего про оценку задач в SP, от балды накидает всё что думает, основываясь на личном мнении. Но ОК, хотя бы первый шаг сделан. Показываю доску и говорю: «На доске ведь всё понятно?»

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

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

Основные проблемы в управлении проектами в реалиях

Работа идет, мы делаем вроде всё добросовестно, но, однако, стоп. Мы просто не успеваем ничего сделать. Показываю график:

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

По итогам получаем следующее: сделали по проекту значительно больше, так как была дисциплина и порядок в задачах. Все вовремя получали оповещения, видели свои задачи, которые не теряются в почте/скайпе/иных средствах связи. Конечно, в управлении проектами Scrum это не всё. Моё логичное следующее предложение: «А давайте мы перед тем, как начать работу, хорошенько подумаем над сложностью задач и прикинем, сколько на ту или иную задачу нужно времени».

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

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

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

Основные проблемы в типичной системе управления проектами.

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

Задачи и новые проекты сваливаются на руководителя отдела разработки (не путать с руководителем проекта) от разных подразделений. Задачи разных проектов начинают конкурировать между собой т.к. команда одна. Как быть в такой ситуации?

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

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

Коллеги дают новые задачи со сроками и отстраняются, ожидая что далее за задачу несёт ответственность только руководитель разработки. Owner (если даже он существует) не участвует в работе.

В компаниях, где нет Scrum, нужно договориться о терминах. Кто в таком случае выступает в роли Product Owner? Тут проще понять, как обстоят дела при управлении проектами через Scrum. Давайте абстрагируемся от конкретных регалий и опишем просто общими словами, кто и за что отвечает.

Есть тот, кому чего-то хочется (это может быть руководитель, может быть заказчик, может быть коллега (если ему позволительно давать задачи другому коллеге)). Ему на самом деле мало интересно, как обстоят дела, ему не надо подходить к каждому сотруднику и говорить, что тому делать. Всё, что ему нужно, – найти «человека-прослойку», который его «хочу» трансформирует в реальный продукт. В Scrum такой человек и будет называться Product Owner.

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

Стоит сразу оговориться, что всё может быть и не так. В роли Product Owner может выступать и тот, кто общается с руководителем отдела, здесь вопрос в тех правилах, которые установлены в компании. То есть руководитель проекта (компании) говорит сотруднику: «Займись этим вопросом, мне нужно сделать это и то, сходи в отдел разработки». Тогда именно этот человек и будет выступать в роли Product Owner, а руководитель отдела спокойно займет место Scrum Master – то есть будет заниматься только своей командной и не влезать в желания других коллег.

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

Ну именно из-за этого и был изобретен Scrum)). Помните, как в замечательной книге «Scrum. Революционный метод управления проектами» Джеффа Сазерленда он описывает, как ФБР долгое время не может разработать программу, так как постоянно заканчивается время и деньги?

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

Договорились работать по правилам, но при первом обращении клиента к топ-менеджменту всё бросаем и бежим исполнять «хотелки», дабы не схватить по голове.

В Scrum полное изменение вектора работы является частью философии. Здесь никак без жёсткой позиции. Необходимо как-то объяснить, что наш отдел работает на результат! Чтобы этот результат был, у нас есть правила. Когда начался спринт, все «хотелки» Product Owner записывает в бэклог и вносит в следующий спринт. Если они буквально «горят», он не кидает их кучами в работу прямо сейчас, это просто неэффективно. Понятно, что культуры эффективности у нас пока нет, её надо завоёвывать.

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

Также есть возможность резко остановить спринт, что, конечно, бьёт по эффективности.

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

Что тут сказать, только осудить и погрозить. Scrum – это команда, которая одержима успехом и победой, а не личными проблемами типа «тренер по голове стукнет».

Как начать правильно управлять проектами со Scrum Time?

Давайте сделаем два шага.

Шаг №1 (левая нога): базовый подход

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

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

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

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

Проблемы со временем

Естественно, у нас всегда проблемы со временем, мы постоянно что-то не успеваем, а если проект уже горит, начинается паника и всё идёт ещё хуже. Здесь уже не обойтись без планирования, но для многих даже страшно представить, как спланировать целый проект на длительное время вперёд. Это же надо сесть и всё обдумывать, всё просчитывать. Кто этим будет заниматься? Не произойдёт ли ещё большая путаница? Наш ответ: скорее всего произойдёт! Всё по той же причине – невозможно просчитать практически никакой проект на всё время работы над ним, это самообман. Очень уж много в нашей жизни форс-мажоров, и всегда будут всплывать подводные камни и тормозить нас весьма болезненно (привет любителям рафтинга). Чтобы решить эту проблему, нужно сделать всего один небольшой шаг, а именно разделить своё время работы на отрезки.

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

Более того, так у нас появляется возможность для маневрирования. Как часто у вас случается, что проект срочно нужно менять? Ну может не кардинально, а, так скажем, задавать другой вектор? Это случается и по желанию заказчика, руководителя, и благодаря собственным мыслям, которые почему-то приходят всегда позже, чем надо. Так вот, спринты для этого и созданы. Работа начинается с каких-то базовых основ, которые в любом случае будут фундаментом для всего проекта. Что касается веб-проектов – это, например, запуск виртуальной машины, инсталляция системы управления базы данных, установка CMS и так далее. Редко бывает так, что во время старта вместо Debian решили использовать CentOS, вместо MySQL накатить Oracle Database 12c. Ну а испечь пирог? Посреди работы решить использовать другое тесто для коржей? Это тогда уже совершенно другой проект пирог получается, а вот вариант украшения, пропитки и так далее уже можно поменять во время следующего спринта.

Шаг №2 (правая нога): Углубление

В целом, выше описано фундаментально всё, что нужно для простого управления без лишних терминов и заморочек. Для тех, кто хочет сделать следующий шаг углубления, мы опишем еще несколько рекомендаций. Хочется именно поговорить о базовых вещах, на которых строится производительность команды. Во-первых, это, конечно, умение подбирать задачи на спринт. Задач не должно быть много и не должно быть мало. Сколько должно быть? В самый раз! Все профессиональные Scrum-команды приходят к этому – некому дзэну или нирване, если хотите. Первым делом нужно найти человека, который точно знает, что нужно делать. Человек этот должен уметь из абстрактных вещей сделать конкретные задачи. Такой человек называется Product Owner. Его изначальная цель – создать общий список задач, описывающий весь проект. Вы скажете: «Весь проект?! Выше же написано, что так нельзя!». Да, действительно, есть негласные правила составления. Чем менее близкая задача, тем меньше она детализирована.

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

Детализировать лучше минимум на 2 спринта вперёд, нам это пригодится.

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

Распределять лучше по эффективности исполнения задачи. Как видно на карте, Алёша находится недалеко от дома Добрыни. Следовательно, самое эффективное – начать с задачи «Взять булаву у Добрыни», а затем уже идти в свой дом и выполнить «Набрать воды из колодца» и «Поймать курицу на дворе и приготовить». Дальше «Взять свой меч», «Взять меч у Ильи» и «Отнести к оружейнику на заточку». Это называется «бережливое производство», которое так активно применяется в «Тойота». Сотрудник на производстве «Тойота» работает точно по такой же схеме.

Как это может выглядеть при веб-разработке.

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

Как только работа над карточкой подходит к концу, всем нужно хватать новые задачи. Вопрос, какие? Вспомним Алёшу. Что ближе к карточке? Ну, наверное, корзина будет ближе всего. Ведь если сделать корзину, то получится готовый функционал продукта (карточки + корзина). Это один из принципов Scrum – не должно храниться недоделанного хлама! Не стоит делать пару задач из оформления блога, пару из системы лояльности, немного заняться SEO и в итоге получить вообще неготовый продукт к концу спринта. Куда более приятней на конечной демонстрации показать, как полностью работает система покупки со всем оформлением и текстом.

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