Ролевая модель Scrum: как возникла и почему важна

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

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

ТРИ ЭПОХИ

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

ПРОБЛЕМЫ 1980-90-Х

Кроме распада СССР, 1990-е прославились компьютерным бумом. Это были славные времена для Стива Джобса, Билла Гейтса и других новаторов, которые жили и работали в стране, создавшей немало благоприятных условий и возможностей для реализации самых смелых идей.

Кибернетика приобрела большую популярность еще в 80-х. К тому времени она обслуживала преимущественно задачи космической отрасли, электроники, приборостроения.

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

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

ИТ-отрасль тех времен напоминала ребенка, учившегося ходить, преодолевая такие препятствия:

1. Потеря времени через старые подходы. С точки зрения подхода к разработке продукта использовали старый добрый вотерфол (waterfall) – “водопадную” или каскадную модель управления проектами, которая предусматривала подробно прописанные технические задачи, разбитие на этапы или “фазы”, в то время как возможность увидеть результат возникала только в конце проекта – после выполнения всех требований. Если плоды продолжительной работы программистов не удовлетворяли заказчика, начинали новый “водопад”.
2. Давление со стороны бизнеса. Требуя быстрого результата, представители бизнеса не занимались целым рядом дополнительных и зачастую не регламентированных функций, должны были выполнять программисты. Разработчики должны самостоятельно выяснять всевозможные подробности, коммуницировать с различными должностными лицами на разных уровнях, даже заниматься вопросами бюджетирования, прогнозирования и другой рутиной, кроме главной задачи – писать код.
3. Завышенная стоимость труда. Слабое понимание специфики интеллектуального труда сыграло с бизнесменами злую шутку. Нанизывание, как шашлык на шампур, дополнительных функций плечи программиста на самом деле увеличивало количество времени, которое он тратил на разработку. Только и говорить об эффективности в таких условиях.

Это привело к высоким расходам на оплату труда разработчиков.

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

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

ПРОБЛЕМЫ 1990 – 2000-Х

Итак, решением проблемы 1990-х стало появление целого ряда дополнительных ролей, которые должны были:

1. Сократить время на разработку программного обеспечения.
2. Помочь программисту сосредоточиться на главной работе и не отвлекаться.
3. Удешевить конечный продукт разработки.
4. Создать ряд вспомогательных функций для реализации 1, 2 и 3.

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

Долгое время этот тренд удовлетворял потребности той эпохи, однако “недолго музыка звучала” – из-за новых проблем, возникших в начале миллениума.

Новые вызовы

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

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

Главная проблема

Новая “прослойка” специалистов в сочетании со старыми подходами к менеджменту (вотерфол никуда не исчез) постепенно вызвал серьезную проблему – непонимание голоса конечного потребителя.

Специалистов интересовало одно: выполнить задание “по техническим спецификациям”, “с соблюдением условий”, “в соответствии с инструкциями”. Программист не думал о пользователе, потому что этим должны заниматься другие. Они также не думали, потому что каждый должен заниматься своим. Кто же в конце концов отвечал за конечный продукт? Вразумительного ответа на этот вопрос не было. У многих не существует до сих пор.

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

ТРЕТЬЯ ЭПОХА

С началом нового тысячелетия ситуация начала радикально меняться.

На мировом рынке цифровых продуктов (Windows / Apple, Microsoft / Photoshop / CorelDraw и др.) появились глобальные игроки, которые начали конкурировать друг с другом.

Возникли новые факторы, определявшие победу в конкурентной борьбе:

1. Быстрее.
2. Удобнее.
3. За меньшую цену.

Это поняли Швабер и Джефф Сазерленд. Объединив усилия, они решили разработать инновационный подход.

Об истоках гибкого подхода к разработке, возникшего еще в 70-х (даже в средневековье!) См. нашу статью “Самоуправляемые и самоорганизующиеся команды: Начало”.

Они поставили вопрос ребром: кто же все-таки будет отвечать за конечный продукт? Возникла необходимость четко определить роль такого участника разработки – владельца продукта.

Опираясь на эмпирические данные, анализ и опыт разработки, авторы Scrum пришли к выводу, что самые эффективные команды должны быть кросфункциональнымы, насчитывать от 3 до 9 человек и состоять из таких ролей:

1. Скрам-мастера (Scrum Master).
2. Владельца продукта (Product Owner).
3. Команда разработчиков (программисты, тестировщики и другие участники разработки).

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

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

Подробнее о специфике ролевой модели в Scrum см. в следующей статье.

ПРИСОЕДИНЯЙТЕСЬ К AGILE.LIVE

Ближайшие сертификационные тренинги Agile.Live: Professional Agile Leadership Essentials (PAL-E), Professional Scrum Product Owner (PSPO)
Подписаться на страницу в LinkedIn
Подписаться на Telegram-канал Agile.Live
Подписаться на YouTube-канал Agile.Live