Гибкое управление

~ 2 ~
Скрам требует новой корпоративной культуры

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

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

Компания впервые применила скрам при разработке продукта Vosod и начала регулярно представлять высококачественные инкременты. Джорис ввел стабильный рабочий ритм (одно из правил скрама). Все стали работать по восемь часов в день. Кто-то скажет: «Да при таком режиме разработчики просто перестают напряженно трудиться!» Однако все наоборот: стабильный ритм способствует росту производительности и качества продукции.

Adventure Works принадлежала японцам. Они сочли 8-часовой рабочий день неприемлемым и потребовали работать по 12 часов в сутки, как до введения скрама. Однако в первых же спринтах количество недоработок выросло на 60 %, что было неприемлемым, несмотря на расширение функциональности продукта. Тогда Джорис вернул 8-часовой рабочий день. Но для японских менеджеров в Сан-Диего вид пустых парковок и темных окон в офисе компании по вечерам был невыносим. Они донесли в головной офис, что сотрудники Adventure Works ленивы и равнодушны, и предложили продать компанию. В глазах начальников это кажущееся разгильдяйство затмевало даже регулярный выпуск высококачественных инкрементов. Вот вам наглядный пример столкновения разных корпоративных культур.

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

Убедитесь в необходимости трансформации

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

Прежде чем пытаться внедрить скрам в масштабах всей компании, необходимо убедиться, что у нее действительно есть серьезные проблемы и что скрам – именно то средство, которое поможет их решить. Первый шаг к этому – применение скрама в нескольких проектах. Скрам не так уж сложен, и понять его принципы позволяют книги (некоторые из них приведены в приложении Б), но на старте не будут лишними организация тренинга и привлечение скрам-мастера (скрам-терминология подробно объясняется в приложении Б). Обучение можно пройти, в частности, на платформе www.scrumalliance.org. Для начала выберите какую-либо задачу, которая может принести высокую ценность либо связана с высокими рисками. Проведите встречу по планированию итераций (встреча по планированию спринта) и установочное обучающее занятие. После этого переходите к спринтам. Проведите минимум три спринта. Они позволят вам прочувствовать ценность метода, ясно понимать, как продвигается проект, и легко вносить в него изменения. Кроме того, вы заметите, как повышается производительность.

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

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

И пусть сотрудники, задействованные в этих проектах, официально пройдут курс обучения скраму. Курсы, предлагаемые компанией Scrum Alliance (www.scrumalliance.org), помогут приобрести необходимые навыки. Немного тренировки – и новичок быстро овладеет навыками и техникой, совсем как в бейсболе.

Перемены, которые вас ждут

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

Текучесть кадров. Обновление персонала на 20 % – это обычное дело. Некоторые говорят: «Мне это не по душе. Я просто хочу приходить на работу, делать там, что скажут, а вечером уходить домой, выбросив все это из головы». Скрам меняет основные правила игры. Он предлагает решать задачи сообща, в команде. Не всем это нравится.

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

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

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

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

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

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