Рольова модель 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
• Підписатися на You-канал Agile.Live