Сейчас все больше компаний внедряет Agile и Scrum, переосмысливая такие популярные понятия, как команда, управление компанией, разработка продукта. Из-за нехватки новой базы знаний и достаточного количества специалистов, способных проконсультировать и помочь бизнесу осуществить переход на современные гибкие подходы, у руководителей возникает больше вопросов, чем ответов.
Кроме непосредственного консалтинга, мы делимся ценными инсайтами на страницах Agile.Live, чтобы поддержать энтузиастов на пути трансформаций. В этой и нескольких следующих статьях затронем тему команды с точки зрения Scrum.
ТРИ ЭПОХИ
За последние несколько декад состоялся феноменальный всплеск развития технологий. Хотя этот период достаточно короткий по сравнению с длительными историческими периодами, однако он показывает, как еще вчера популярные понятия сегодня могут считаться каменным веком или эпохой динозавров. Это касается не только поколения станков или приборов, но и подходов к управлению и разработки продукта.
ПРОБЛЕМЫ 1980-90-Х


Кроме распада СССР, 1990-е прославились компьютерным бумом. Это были славные времена для Стива Джобса, Билла Гейтса и других новаторов, которые жили и работали в стране, создавшей немало благоприятных условий и возможностей для реализации самых смелых идей.
Кибернетика приобрела большую популярность еще в 80-х. К тому времени она обслуживала преимущественно задачи космической отрасли, электроники, приборостроения.
ИТ мало чем отличалась тогда от других индустрий, связанных с разработкой любого продукта вообще (фотоаппаратов, электротехники и др.). Инженеры приборостроительной отрасли хорошо понимали что нужно потребителям, а потому их продукция была User Friendly – разработана с заботой о пользователе (поколение родителей и дедушек до сих пор помнит японские магнитофоны с удобными кнопками, которые выполняли различные функции, акустические системы, радовали широким диапазоном звучания, удобные переносные электронные приборы).
Однако в 90-х производить кубовидный телевизоры было недостаточно, возникала потребность в разработке программного обеспечения. Спрос на программистов оказался настолько внезапным, что количество специалистов, способных удовлетворить эту потребность рынка, не существовало.
ИТ-отрасль тех времен напоминала ребенка, учившегося ходить, преодолевая такие препятствия:
- Потеря времени через старые подходы. С точки зрения подхода к разработке продукта использовали старый добрый вотерфол (waterfall) – “водопадную” или каскадную модель управления проектами, которая предусматривала подробно прописанные технические задачи, разбитие на этапы или “фазы”, в то время как возможность увидеть результат возникала только в конце проекта – после выполнения всех требований. Если плоды продолжительной работы программистов не удовлетворяли заказчика, начинали новый “водопад”.
- Давление со стороны бизнеса. Требуя быстрого результата, представители бизнеса не занимались целым рядом дополнительных и зачастую не регламентированных функций, должны были выполнять программисты. Разработчики должны самостоятельно выяснять всевозможные подробности, коммуницировать с различными должностными лицами на разных уровнях, даже заниматься вопросами бюджетирования, прогнозирования и другой рутиной, кроме главной задачи – писать код.
- Завышенная стоимость труда. Слабое понимание специфики интеллектуального труда сыграло с бизнесменами злую шутку. Нанизывание, как шашлык на шампур, дополнительных функций плечи программиста на самом деле увеличивало количество времени, которое он тратил на разработку. Только и говорить об эффективности в таких условиях.
Это привело к высоким расходам на оплату труда разработчиков.
Таким образом, кроме стремительного роста спроса на программистов, возникла такая же острая необходимость уменьшить расходы на оплату их труда.
Так началась следующая эпоха в жизни разработчиков – возникновение вспомогательных промежуточных ролей в ИТ.
ПРОБЛЕМЫ 1990 – 2000-Х


Итак, решением проблемы 1990-х стало появление целого ряда дополнительных ролей, которые должны были:
- Сократить время на разработку программного обеспечения.
- Помочь программисту сосредоточиться на главной работе и не отвлекаться.
- Удешевить конечный продукт разработки.
- Создать ряд вспомогательных функций для реализации 1, 2 и 3.
Именно при таких условиях и возникли популярные ныне профессии в ИТ-индустрии – бизнес-аналитик, проектный менеджер, технический писатель и многие другие.
Долгое время этот тренд удовлетворял потребности той эпохи, однако “недолго музыка звучала” – из-за новых проблем, возникших в начале миллениума.
Новые вызовы
- Количество технологий продолжает расти.
- Языков программирования становится больше.
- Количество специалистов по программированию не так критично, как в предыдущий период.
Декада 1990-2000-х наплодила целую прослойку дополнительных профессий, которые должны были бы помогать программистам и бизнесу.
Главная проблема


Новая “прослойка” специалистов в сочетании со старыми подходами к менеджменту (вотерфол никуда не исчез) постепенно вызвал серьезную проблему – непонимание голоса конечного потребителя.
Специалистов интересовало одно: выполнить задание “по техническим спецификациям”, “с соблюдением условий”, “в соответствии с инструкциями”. Программист не думал о пользователе, потому что этим должны заниматься другие. Они также не думали, потому что каждый должен заниматься своим. Кто же в конце концов отвечал за конечный продукт? Вразумительного ответа на этот вопрос не было. У многих не существует до сих пор.
Поэтому первые программы были чрезвычайно сложными (интерфейсы слишком сложные и непонятные для обычных пользователей), хотя при других обстоятельствах можно было бы сразу сделать его удобным и легким в использовании.
ТРЕТЬЯ ЭПОХА
С началом нового тысячелетия ситуация начала радикально меняться.
На мировом рынке цифровых продуктов (Windows / Apple, Microsoft / Photoshop / CorelDraw и др.) появились глобальные игроки, которые начали конкурировать друг с другом.
Возникли новые факторы, определявшие победу в конкурентной борьбе:
- Быстрее.
- Удобнее.
- За меньшую цену.
Это поняли Швабер и Джефф Сазерленд. Объединив усилия, они решили разработать инновационный подход.


Об истоках гибкого подхода к разработке, возникшего еще в 70-х (даже в средневековье!) См. нашу статью “Самоуправляемые и самоорганизующиеся команды: Начало”.
Они поставили вопрос ребром: кто же все-таки будет отвечать за конечный продукт? Возникла необходимость четко определить роль такого участника разработки – владельца продукта.
Опираясь на эмпирические данные, анализ и опыт разработки, авторы Scrum пришли к выводу, что самые эффективные команды должны быть кросфункциональнымы, насчитывать от 3 до 9 человек и состоять из таких ролей:
- Скрам-мастера (Scrum Master).
- Владельца продукта (Product Owner).
- Команда разработчиков (программисты, тестировщики и другие участники разработки).
Сейчас эта модель помогла заработать миллиарды долларов, решить большие задачи бизнеса и улучшить жизнь миллионам людей.
Почему именно эта модель важна и приобрела большую популярность в новую эпоху? Простота, гибкость и эффективность! Теперь у разработчиков есть своя полноценная продуктовая команда, дистанция до голоса конечных потребителей минимальная – владелец продукта! А для решения организационных вопросов не нужно думать, к кому из десяти менеджеров обращаться, потому что теперь скрам-мастер, который решит любой вопрос.
Подробнее о специфике ролевой модели в Scrum см. в следующей статье.
ПРИСОЕДИНЯЙТЕСЬ К AGILE.LIVE
Ближайшие сертификационные тренинги Agile.Live: Professional Agile Leadership Essentials (PAL-E), Professional Scrum Product Owner (PSPO)
Подписаться на страницу в LinkedIn
Подписаться на Telegram-канал Agile.Live
Подписаться на YouTube-канал Agile.Live