ФБР прогавив події 11 вересня 2001 року, тому що система обробки інформації у відомстві була не адекватна зовнішнім викликам. Багатоярусна, ієрархічна, громіздка система просто не була здатна відстежити, оцінити, інтерпретувати ту інформацію, якою мала. Урядова комісія, що проаналізувала підсумки катастрофи, охарактеризувала стан інформаційних систем ФБР як «плачевний». Цей кейс наводить у своїй книзі «Scrum. Революційний метод управління проектами » Джефф Сазерленд. Події 11 вересня в цій логіці представляли собою кризу класичного менеджменту, заснованого на ідеї ієрархії.

В кінці ХХ століття в таких областях, як проектний менеджмент, методологія розробки програмного забезпечення початку проростати нова ідея. Для її визначення використовуються такі терміни як Scrum (сутичка, тиснява) і Agile (живий, гнучкий, маневрений, моторний). Про те, що це таке, Executive.ru розмовляє з керівником команди ScrumTrek, фахівцем з гнучкими методологіями розробки Асхат Уразбаєва.

Executive.ru: Що таке Scrum?

Асхат Уразбаев: Ітеративна Інкрементальний робота самоорганізованих крос-функціональних команд. Є чотири пункти, які визначають Scrum і його відмінність від інших підходів.

• Ітеративна: значить, що ми працюємо короткими ітераціями, в Scrum вони називаються Sprints ( «спринти»). Ми не намагаємося створити ідеальний план «до горизонту», до кінця проекту: це не просто марно, але й шкідливо, тому що в цьому випадку замовник і виконавець думають не про те, що правильного і корисного вони зробили, а про те, наскільки точно вони рухаються за планом. У Scrum на верхньому рівні знаходиться не детальний план, а Road map (дорожня карта), де сформульовано загальне уявлення про те, куди ми рухаємося .
• Інкрементальний: ми намагаємося на кожному етапі роботи, в кінці кожного спринту, зробити щось корисне, цінне для клієнта. Ну, або хоча б провалідіровать, перевірити якийсь фрагмент проекту або продукту: то ми робимо, або не те.
• Кроссфункціональность: в Scrum намагаються працювати групами, в яких є всі необхідні фахівці і уникаємо «функціональних колодязів».
• Самоорганізація: в Scrum робиться дуже великий акцент на командній роботі. Команда сама визначає правила роботи.

Executive.ru: Який з цих принципів є Know How Scrum?

А.У .: В тому чи іншому вигляді вони зустрічаються в класичному проектному менеджменті, який часто називають «водоспадом». Коли я починаю розповідати про Scrum і задаю питання, чи бувало у вашому житті, що ви діяли так, як прийнято в Scrum - щодня збиралися і перепланували свою роботу, в аудиторії дуже часто знаходяться люди, які розповідають, що бували складні дні, наприклад, під час здачі проекту, коли треба було за короткий час видати якісний результат , І вони вдавалися до подібних принципам.

Executive.ru: Чому ваші співрозмовники в критичні періоди використовували саме ці методи?

А.У .: Тому що ці підходи дозволяють ефективно організувати роботу в умовах невизначеності, в мінливих умовах. Ці методи були винайдені не сьогодні. Scrum до якійсь мірі стандартизував їх.

Executive.ru: У чому ж новизна Scrum?

А.У .: В тому, що треба слідувати глузду, а не планом. План - це спосіб максимально ефективно виконувати мінливих умов. В одному з перших проектів, в якому я працював років 15 назад, був менеджер проекту Іван. Ми підходили до нього і говорили: «Ти не можеш поговорити з замовником про це і про те? Тут є реальні проблеми ». Він відповідав, що йому колись: у нього в плані 800 завдань, і йому не до наших проблем - все його час йшло на актуалізацію плану.

Executive.ru: У книзі «Scrum. Революційний метод управління проектами »Джефф Сазерленд пише:« Планувати корисно, сліпо слідувати плану - нерозумно ». Хто визначає слепость або НЕ слепость?

А.У .: Люди дійсно дуже люблять плани, і коли розповідаєш їм про Agile, вони чомусь думають, що Agile і Scrum - спосіб роботи без плану. Це не так. Є різні моделі життєвого циклу проекту , Наприклад, «водоспадна» і ітеративна. Scrum - приклад итеративной моделі. В IT також використовують модель, яку називають Code and fix (кодується і исправляй). Це те, що застосовується, коли вдається замовник і кричить: «Хлопці! Біжимо туди! ». Все знімаються і біжать. Потім замовник подає команду «Біжимо назад!». Всі біжать назад. При такому підході можна нескінченно бігати навколо кілочка і ніколи не досягти мети. Це - точно не Agile. Це - протилежність Agile.

У Agile ми завжди, в кожен момент часу, представляємо кінцеву мету, до якої ми приходимо, і рухаємося до неї, як я вже говорив, короткими ітераціями. В кінці кожної короткої ітерації, «спринту», ми оцінюємо, наблизилися ми до мети чи ні. Загальний план руху по проекту теж є, він називається Backlog, але він не є докладним. Слепость або НЕ слепость визначає Product owner - його завдання полягає в тому, щоб за допомогою Backlog оцінювати, чи правильно ми рухаємося до мети.

Executive.ru: Product owner знаходиться на стороні замовника?

А.У .: Може перебувати на стороні замовника або виконавця, це не принципово і визначається контекстом. Буває, що це - представник замовника. Буває, що це - хтось всередині команди підрядника. Іноді у проекту є два Product owner, один з яких, що представляє замовника, - «головніший». У кожному конкретному проекті ми оцінюємо, хто найкраще підійде на роль Product owner. При цьому підкреслю, що це - не посада, а роль .

Executive.ru: Що являє собою Backlog?

А.У .: Уявлення про те, як ми рухаємося до мети проекту. План руху. Він складається з того, що ми в Agile називаємо «призначеними для користувача історіями». У кожній з них розповідається про те, що ми хочемо зробити для кінцевого користувача, яку цінність ми хочемо йому принести. Якщо порівнювати Backlog зі стандартними документами проектного менеджменту, це ближче до плану проекту.

Executive.ru: А що знаходиться над Backlog?

А.У .: Концепція або Vision. Зазвичай це короткий - від півсторінки до двох - документ, в якому сказано, куди ми рухаємося, сформульована мета верхнього рівня.

Executive.ru: Що таке спринт, ким він ініціюється, скільки триває, ніж закінчується?

А.У .: Припустимо, замовник просить зробити систему, яка дозволить його підрозділу вирішувати якесь завдання, наприклад, робити розрахунок для отримання деяких відрахувань. У виконавця є уявлення про те, як це треба зробити. Виконавець хоче запропонувати, щоб в кінці кожного кварталу підрозділ замовника могло закривати квартальні звіти за допомогою нової системи. При цьому «на березі» виконавець не уявляє, як саме він досягне цієї мети, тому що не знає, як влаштоване життя в компанії замовника. А замовник не уявляє, що саме збирається зробити виконавець, слабо уявляючи можливості системи.

При класичному «водоспадних» підході, ми спочатку реалізуємо попередній проект, або аналіз. Готуємо солідний документ, який називаємо технічним завданням (ТЗ) , Після затвердження якого починаємо рухатися. Завдання менеджера проекту полягає в тому, щоб не відхилитися від ТЗ ні вліво, ні вправо.

Executive.ru: Що неправильно в цій схемі?

А.У .: Те, що в ТЗ могли потрапити помилки. Наприклад, виконавці могли не до кінця розібратися в тому, що потрібно замовнику. Втім, ТЗ могло перестати бути актуальним і по «вини» замовника: змінилися бізнес-процеси, оточення компанії, змінилося керівництво, а разом з ним - розуміння того, навіщо потрібен проект. В результаті отримали те, що запланували, але не те, що потрібно.

Щоб переписати ТЗ, потрібні великі зусилля, тому що зміни вносяться в план проекту, внутрішні документи, графіки і так далі, аж до програмного коду. У Scrum діють інакше. Тут вважають за краще рухатися короткими - зазвичай двотижневими - «Спринт», в кінці кожного відрізка виходить простий і зрозумілий результат, актуальний для замовника. Якщо вимоги до проекту змінюються, але не змінюється кінцева мета, це не тягне за собою переписування ТЗ, ми просто враховуємо ці зміни в наступних «спринтах».

Executive.ru: У Scrum використовується діаграма згоряння завдань. Наскільки вона близька діаграм Генрі Ганта?

А.У .: Аналогом діаграми Ганта в Scrum є Backlog. У свою чергу найближчим аналогом діаграми згоряння завдань в проектному менеджменті є, напевно, Earned Value - «Діаграма освоєного обсягу». Вони близькі за змістом.

Executive.ru: Які ролі є в команді Scrum?

А.У .: В класичному Scrum є Product owner, який відповідає за Backlog, взаємодіє з зацікавленими особами. Він відповідає за те, яку цінність потрібно привнести замовнику. Інша найважливіша роль - Scrum-майстер. Його головне завдання полягає в тому, щоб вибудувати максимально ефективну, максимально круту команду, здатну вирішити ті проблеми, які є у замовника. Різниця між менеджером проекту і Scrum- майстром полягає в тому, що перший орієнтований на здачу проекту. Проект закінчився - його робота теж закінчена. Роль Scrum-майстри більш довгострокова, вона не закінчується в момент здачі проекту, вона розрахована на нескінченне зростання зрілості і компетенцій команди.

Executive.ru: Як зберігається ця роль, якщо роботи виконані і фінансування закінчено?

А.У .: В Agile не рекомендується будувати команди «під проекти». Формування і переформування команд - це трудомісткий і дорогий процес. Уявіть, ви реалізували проект і попрощалися з розробниками. Через деякий час з'явився новий проект, і вам треба створювати команду заново. Ми знову збираємо іншу команду, знову вона проходить всі стадії розвитку зрілості через неминучий криза. У Agile замість того, щоб переформовувати команди під проект, ми збираємо стабільні команди, і стабільним командам віддаємо проекти. Розумієте різницю?

Є чимала кількість вендорів, які працюють по Agile, при цьому у них, як правило, стабільні команди всередині. Проекти приходять і йдуть, а команда залишається. Такі команди внаслідок своєї зрілості можуть робити дійсно круті проекти.

Executive.ru: В яких ролях представлений замовник і наскільки він інтегрований в проект, який реалізується за методологією Scrum?

А.У .: Ми намагаємося формувати команди так, що замовник є складовою частиною команди. У нас виходить команда, що складається з двох сильно перетинаються частин. Одну, ми зазвичай називаємо Product Delivery - поставка цінності, а друга Discovery - вона досліджує, що ж потрібно насправді робити, в якому напрямку рухатися. Представники замовника можуть бути і в Discovery, і в Delivery. Ми просто формуємо максимально ефективну команду, члени якої класно взаємодіють один з одним, і неважливо, хто з якого боку увійшов в команду.

Executive.ru: За рахунок чого в Scrum відбувається економія часу, якщо порівнювати Scrum з традиційним проектним менеджментом? Перший фактор, ви вже позначали: за рахунок відмови від бюрократичних процедур. Цей фактор не єдиний?

А.У .: Чи не єдиний. Важливий фактор - крос-функціональність. Замість того щоб виконувати операції послідовно (аналітик написав ТЗ, передав далі по ланцюжку), ми в Agile створюємо крос-функціональну команду (аналітик, розробники, тестувальник ...), члени якої добре розуміють один одного, тому можуть приступати до проекту спільно, орієнтуючись на Backlog. В один момент над проектом працює вся команда (класичне обмеження на її розмір 7 + 2 людини). За нашими спостереженнями, завдяки такому підходу, Scrum виграє у класичного «водоспаду», перевершуючи його по швидкості в 2,5-3 рази.

Executive.ru: В яких галузях застосовується Scrum?

А.У .: Scrum виник в середині 1990-х. По крайней мере, перший доповідь на конференції на цю тему був в 1996 році. У 2001 році з'явилося слово Agile, яке нині розташоване як парасольку над Scrum, і іншими аналогічними підходами. До Росії ці підходи прийшли в 2006 році, першими їх почали застосовувати web-розробники, які реалізували проекти для «Яндекса», «Рамблера», «Афіші». Потім до цієї методології почали проявляти інтерес компанії, що займаються інформаційною безпекою, великі IT-компанії. Зараз до Scrum відчувають неабиякий інтерес банки - «Альфабанк», «Сбербанк», «Райффайзен банк», «Хоум кредит», - всі вони так чи інакше переходять поступово на використання гнучких методологій.

Executive.ru: Якими програмними продуктами підтримується Scrum-процес?

Таких продуктів дуже багато. Із зарубіжних часто використовують Atlassian Jira, мабуть, він найпоширеніший. З російських можу порекомендувати Kaiten.io.

Executive.ru: Чи багато в Росії прихильників Scrum?

А.У .: Конференція Agile days в березні 2016 зібрала 1200 чоловік. Це була вже десята конференція. Спільнота в Facebook налічує близько 2500 чоловік, воно досить активно. Число прихильників, ймовірно, більше, тому що є люди, які використовують Scrum, але не беруть участі в тусовках. Число прихильників Scrum приростає за рахунок представників класичного проектного менеджменту. Починаючи з четвертої версії PMBok, ми бачимо свого роду розворот в бік Scrum, в тому числі з'явилася сертифікація PMI's Agile Certified Practitioner. До речі кажучи, з хороших Project managers виходять сильні Scrum-майстра. Я взагалі вважаю, що сучасний менеджер проекту повинен володіти компетенціями Scrum-майстри, просто тому, що ці знання додадуть йому цінності на ринку праці.