Оригінальна стаття – The Core Question to Ask about Building Better Software Faster, переклад – Олена Галушка, ревью – Олександра Серебрянська (Business Analysis Community Kyiv). Оригінальна графіка від Karl Wiegers.
Перш ніж квапитися застосовувати найсучасніші методи розробки у якості панацеї, спробуймо розібратися, чому вже зараз ви не отримуєте бажаного результату.
Я ще ніколи не зустрічав людину, яка б чесно визнала: «Я створюю програмне забезпечення найефективнішим способом, який тільки може існувати». Людина, команда та ціла компанія перебувають у постійному пошуку більш ефективних шляхів виконання своєї роботи.
Розчарування від невтішних результатів є потужною мотивацією спробувати інший підхід. Однак, ви маєте бути впевнені, що цей новий підхід дійсно допоможе вирішити саме ваші проблеми.
Компанії полюють на найновіші та наймодніші рішення у розробці програмного забезпечення з надією, що вони як магічне зілля, впораються з усіма існуючими проблемами.
Наприклад, керівник/керівниця десь прочитали про багатообіцяючий підхід до розробки, можливо занадто розрекламований, та наполягають, що саме їх команда має негайно його застосувати, щоб «вилікувати усі хвороби». Я чув, що таке явище називається «управління за популярними медіа (“management by Businessweek”).
Або ж, розробники/розробниці послухали презентацію про новий метод і, натхненні, одразу квапляться його застосувати. Прагнення до вдосконалення похвальне, але вам потрібно спрямувати цю енергію на нагальну проблему і оцінити, наскільки добре потенційне рішення відповідає вашій ситуації, перш ніж застосовувати його.
Багато років ми живемо у вирі незліченної кількості нових парадигм, методів та підходів створення програмного забезпечення і управління цим процесом. Всі вони мають переваги, всі вони мають недоліки та обмеження, і всі вони повинні застосовуватися у відповідному контексті. В якості прикладу для цієї дискусії я використаю гіпотетичний новий підхід до розробки програмного забезпечення, назвемо його Метод-9.
Спочатку проблема, потім рішення
У статтях та книгах про Метод-9 винахідники та перші послідовники вихваляють його переваги. Деякі компанії звертаються до Методу-9, бо хочуть, щоб їхні продукти максимально задовольняли потреби клієнтів. Можливо, ви хочете створювати затребуване програмне забезпечення швидше (а хто цього не хоче?). Метод-9 може допомогти вам у цьому. А може ви хочете зменшити кількість дефектів, які дратують клієнтів і потребують додаткового навантаження від команди на доопрацювання (знову ж таки, хто цього не хоче?). Метод-9 поспішає на допомогу! Адже в тому і суть покращення процесів: постановка цілей, визначення перешкод та вибір методів, які, на вашу думку, допоможуть їх подолати.
Однак, перш ніж зупинитися на якомусь новому підході до розробки, знайдіть час, щоб задати собі головне питання на шляху до створення кращого програмного забезпечення:
“Що заважає нам досягти кращих результатів вже сьогодні?”
Якщо ви хочете створювати програмне забезпечення швидше, що вам заважає вже зараз? Якщо ваша мета – менше недоліків і менше переробок, то чому сьогодні у ваших продуктах занадто багато тих самих недоліків чи дефектів? Якщо ви хочете швидше реагувати на мінливі потреби, що вам заважає саме зараз?
Іншими словами, якщо Метод-9 є відповіддю – принаймні, згідно з тією статтею, яку ви прочитали, – то в чому було питання?
Маю надію, що я помиляюся, але схиляюся до думки, що небагато компаній проводять подібний аналіз першопричин, перш ніж вхопитися за те, що здається їм перспективним рішенням. Взяти за мету покращення – це чудовий початок, але ви також повинні розуміти поточні перешкоди на шляху до досягнення цієї мети. Вам потрібно лікувати справжню причину, а не лише симптоми. Якщо ви не розумієте цих реальних перешкод, вибір будь-якого нового підходу – це лише постріл у темряву.
Приклад пошуку першопричини
Припустимо, ви хочете створювати програмні продукти, які задовольняють потреби клієнтів краще, ніж ви робили це раніше. Ви читали, що в командах, які використовують Метод-9 передбачається роль “Гуру бачення” (Vision Guru), задача якого слідкувати, щоб продукт задовольняв потреби. “Чудово!” – думаєте ви. “Гуру бачення подбає про те, щоб ми створили правильну річ. Замовники точно будуть щасливі”. Проблему вирішено, чи не так? Можливо, але я пропоную, щоб перед тим, як власне вносити будь-які зміни в процес, ваша команда зрозуміла, чому те, що ви розробляєте зараз не викликає захоплення у ваших замовників.
Аналіз першопричин – це процес мислення в зворотному напрямку, коли ви ставите питання “чому” доти, поки не дійдете до проблем, на рішення, яких можна спрямувати зусилля за допомогою ретельно підібраних заходів з удосконалення. Перша виявлена причина може не піддаватися безпосередньому впливу; вона також може бути некінцевою першопричиною. Тому усунення цієї першопричини не розв’яже проблему. Тоді вам потрібно запитати “чому” ще раз чи два, щоб переконатися, що ви дісталися самої суті
На рисунку 1 показано частину діаграми “риб’яча кістка”, яку також називають діаграмою Ішикави або причинно-наслідковою діаграмою, що є зручним способом для аналізу першопричини. Єдині інструменти, які вам знадобляться, – це кілька зацікавлених сторін, дошка та маркери. Розгляньмо цю діаграму.
Малюнок 1. Частковий аналіз першопричини у вигляді діаграми “риб’яча кістка”.
Ваша мета – краще задовольнити потреби клієнтів з першого випуску продукту. Напишіть цю мету на довгій горизонтальній лінії. Або ж ви можете сформулювати її як постановку проблеми: “Перший випуск продукту не відповідає потребам замовника”. У будь-якому випадку, ця довга горизонтальна лінія – хребет на діаграмі “риб’яча кістка” – представляє вашу ключову проблему.
Далі запитайте свою групу: “Чому ми не задовольняємо потреби наших клієнтів?” Тепер починається аналіз. Одна з можливих відповідей полягає в тому, що команда не отримує адекватної інформації про вимоги від кінцевих користувачів – це доволі поширена ситуація. Напишіть цю причину на діагональній лінії, що йде від лінії формулювання цілей. Це гарний початок, але вам потрібне глибше розуміння, щоб знати, як розв’язувати проблему. Ви запитуєте: “Чому ні?”.
Один з членів групи відповідає: “Ми намагалися поговорити з реальними користувачами, але їхні менеджери кажуть, що вони занадто зайняті, щоб працювати з командою розробників”. Хтось інший скаржиться, що представники замовника, які працюють з командою, не дуже добре висвітлюють реальні потреби кінцевих користувачів. Запишіть ці причини другого рівня на горизонтальних лініях, що відходять від діагональної лінії ключової проблеми.
Третій учасник вказує на те, що розробники, які намагаються з’ясувати вимоги, не вміють ставити правильні запитання представникам замовника. Далі йде звичайне уточнююче запитання: “Чому?” Причин може бути безліч, включаючи брак кваліфікації або інтересу до вимог з боку розробників. Можливо також, що бізнес-аналізу не відводиться окрема роль в команді. Кожна причина переходить на нову діагональну лінію, прикріплену до ключової проблеми.
Тепер ви дійшли до перешкод, які стоять між поточною ефективністю вашої команди і бажаною. Продовжуйте цей багаторівневий аналіз доти, доки учасники не дійдуть згоди, що вони розуміють, чому команда не досягає бажаних результатів. Діаграма може виглядати безладно; в такому випадку, можна записувати причини на клейких папірцях, щоб ви могли перетасувати їх під час подальшого дослідження. Я виявив, що ця техніка є надзвичайно ефективною і уможливлює учасників зосередитися та швидко досягти чіткого розуміння ситуації.
Спочатку діагноз, потім лікування
Під час наступних мозкових штурмів члени команди можуть шукати практичні рішення для усунення цих першопричин. І тоді ви вже на шляху до досягнення найкращих результатів. Ви можете дійти висновку, що залучення досвідчених бізнес-аналітиків до вашої команди може бути більш корисним, ніж застосування Методу-9 з його Гуру Бачення. Або ж, можливо, поєднання цих двох методів виявиться секретним інгредієнтом. Але без ретельного аналізу це неможливо з’ясувати.
Коли ви міркуєте над тим чи іншим новим підходом розробки, не звертайте уваги на хайп і модні тенденції. Проаналізуйте передумови та ризики, пов’язані з новим підходом та зважте чи дійсно ризик вартує потенційного результату. Ще декілька питань, на які варто відповісти:
– Чи знадобиться вашій команді навчання, інструменти або консультування, щоб розпочати і підтримувати прогрес?
– Чи окуплять себе докладені зусилля?
– Якими будуть можливі наслідки переходу на нову систему для вашої команди, ваших клієнтів, їхніх організацій та бізнесу?
– Наскільки потворною може бути крива навчання?
Висновки, зроблені в результаті аналізу першопричин, можуть стати поштовхом до пошуку кращих практик для вирішення кожної проблеми, яку ви виявите. Не визначивши перешкоди між тим, де ви перебуваєте сьогодні, і де прагнете бути, не дивуйтеся, якщо проблеми залишаться, навіть якщо ви застосуєте новий підхід. Спробуйте провести аналіз першопричин замість того, щоб гнатися за “найгарячішою новинкою”, про яку хтось прочитав у заголовку.
Аналіз першопричин займає менше часу, ніж ви очікуєте. Це надійна інвестиція в ефективне зосередження ваших зусиль з удосконалення. Будь-який лікар скаже вам, що необхідно правильно визначити хворобу, перш ніж призначати лікування.
Адаптація статті Карла Вігерса: «Розробка програмного забезпечення за Перлзом: уроки 50 річного досвіду у розробці».
Карл – головний консультант у Process Impact. Він є автором значної кількості книжок, що включає «Вимоги до програмного забезпечення», «Непродуманий дизайн звичних речей» та «Успішне консультування у бізнес аналізі».
До теми – 13 типових помилок у роботі початкуючих бізнес-аналітиків