Формулювання проблеми
У момент початку нового проекту в ролі бізнес-аналітика, я часто стикаюся з ситуацією, коли надано опис програмного рішення, але відсутня важлива інформація про те, які конкретні проблеми воно спрямоване на вирішення зараз. Відсутність роз'яснень про те, чому рішення виглядає саме так, а також відсутність планів щодо його подальшого розвитку, створює деяку невизначеність. Ця тенденція не є ізольованою нагодою, як показує мій досвід в організації професійних конференцій і в ролі тренера.
Багато керівників і тимліди висловлюють невдоволення тим, що їхні колеги часто обмежуються розробкою єдиного рішення, не розглядаючи альтернативних варіантів. Вони також висловлюють зауваження щодо того, що часто ставиться акцент виключно на внутрішній реалізації системи, з огляду на контекст роботи користувача та поточну ситуацію в бізнесі. Навіть найдосвідченіші аналітики, розпочинаючи роботу над системою, часто висловлюють невдоволення з приводу того, що попередні етапи не були належним чином висвітлені або задокументовані. Відсутність загального розуміння контексту та цілей стає критичною для провідних фахівців, відповідальних за команди, оскільки їм доводиться витрачати значний час на ретельний аналіз роботи аналітиків, що у свою чергу знижує ефективність виконання більш стратегічних обов'язків.
Далі в цій статті я розгляну обґрунтованість подібних скарг на мій погляд, запропоную можливі шляхи вирішення проблеми та обговоримо, чи варто звинувачувати виключно аналітиків чи можна покращити ситуацію іншими методами.
Чому пильний розгляд вирішуваної проблеми викликає занепокоєння колег? Це пов'язано з кількома ключовими аспектами, які можуть мати серйозні наслідки для бізнесу та команди розробників.
-
Неповне вирішення проблеми
Простий або поверховий розгляд проблеми може призвести до того, що обране рішення буде неповним або неоптимальним. Це може призвести до непотрібних трудовитрат на доопрацювання системи та переписування коду. -
Трансформація стилю роботи замовника
Рішення, які не враховують особливості поточного стилю роботи бізнес-замовника, можуть вимагати від нього значних змін. Це може викликати невдоволення та втрату ефективності роботи. -
Нескінченні зміни та дописування коду
Недосконалі рішення часто призводять до постійної необхідності дописувати та переписувати код, що у результаті стає важким тягарем для розробників. -
Втрата лояльності та репутаційні втрати
Невдалі проекти можуть призвести до втрати довіри клієнта та вплинути на репутацію компанії на ринку. Це може позначитися на майбутніх пропозиціях та виділенні фінансування. -
Невиконання вимог регулюючих документів
Відсутність всебічного аналізу може призвести до порушення вимог галузевих та державних стандартів. Це може призвести до адміністративних правопорушень та штрафів. -
Проблеми з безпекою та зберіганням даних
Неправильне рішення може призвести до порушення вимог безпеки та зберігання даних. Це особливо важливо у сфері піклування про персональну інформацію та медичні дані.
Всі ці фактори наголошують на важливості ретельного та всебічного розгляду завдання перед прийняттям рішення. Такий підхід допомагає уникнути негативних наслідків та забезпечує успішну реалізацію проекту.
Що потрібно для задоволення запиту
Серед усіх ролей у проекті роль бізнес-аналітика найближча до місії "бачити завдання загалом". Тому я хотів би обговорити діяльності, які можуть наблизити до широкого розгляду завдання, висвітленого з погляду цієї ролі. Хоча керівник проекту також може відчувати потребу в цьому, у нього, проте, фокус на пошуку балансу між часом, обсягом роботи та задоволеністю замовника, що унеможливлює розгляд усіх варіантів.
Отже, якщо ви вирішуєте серйозно зайнятися переосмисленням та аналізом поточного завдання, вам слід:
- Розглядати завдання з поглядів різних зацікавлених сторін.
- Охоплюватиме весь життєвий цикл системи.
- Аналізувати вхідну інформацію на повноту, якість та актуальність.
- Враховувати ризики та обмеження.
- Застосовувати широкий набір аналітичних інструментів.
- Розглядатиме кілька варіантів рішень.
- Спочатку розглядати тривіальне рішення.
Можливо, це не повний перелік, але його достатньо для розробки плану саморозвитку чи розвитку своєї команди на кілька років, тому на даному етапі обмежимося цим.
Аналіз ситуації з урахуванням інтересів різних сторін
Аналіз ситуації з урахуванням інтересів різних сторін є ключовим аспектом успішної роботи бізнес-аналітика. Розгляд перспектив бізнес-замовника та користувача, керівника проекту та архітектора, тимліда та техпідтримки є важливими точками фокусу. Важливо відзначити, що завдання аналітика — не передбачати все, а забезпечити наявність інформації про принципи архітектурного проектування поточної системи, управління проектом, плани підтримки та особливості фінансування з боку спонсора.
Якщо ця інформація відсутня у документації, необхідно забезпечити доступ до людей, здатних надати відповіді на ці запитання.
Не варто вагатися у пошуку та спілкуванні з відповідними фахівцями, щоб роз'яснити контекст розробки. В ідеалі, аналітику слід прагнути до розуміння всіх аспектів проекту, що, зрештою, сприяє кращому сприйняттю завдання в цілому.
Надання аналітику доступу до ключової інформації з усіх аспектів проекту забезпечує більш глибоке та всебічне розуміння контексту, що, у свою чергу, підтримує прийняття інформованих та обґрунтованих рішень у ході аналізу та задовольняє потреби всіх зацікавлених сторін.
Розглядати весь життєвий цикл системи
Врахувати повний життєвий цикл системи є ключовим моментом у роботі бізнес-аналітика. Не менш важливо також зберегти в думці тимчасову перспективу життя продуктів, що розробляються. Будувати систему, враховуючи як її поточний розвиток, а й майбутню підтримку, є обов'язком, що лежить на плечах розробників. Важливо, що відповідальність за товар не зникає після завершення розробки; підтримка та зміни, узгоджені з продуктом, будуть неминучими.
Також варто мати на увазі, що будь-яка система, хоч би скільки ретельно вона була спроектована, рано чи пізно буде замінена іншою. Це відбиває реальність сучасного світу, де технологічні зміни відбуваються настільки швидко, що довгострокова стійкість стає викликом. Однак головною цінністю для бізнесу залишається інформація, що зберігається в системі. Безпека та можливість безпечного збереження або експорту даних стають критичними моментами.
Таким чином, необхідно задуматися про те, наскільки продукт, який ви розробляєте, буде актуальним та корисним у майбутньому. Чи то прототип для моделювання розв'язання задачі, чи цінне джерело інформації на довгий термін — це важливий роздум, який допоможе створити продукт, здатний відповідати вимогам бізнесу не лише сьогодні, а й у перспективі.
Проведення аналізу вхідної інформації з урахуванням її повноти
Проведення аналізу вхідної інформації з урахуванням її повноти, якості та актуальності є важливим етапом для бізнес-аналітика. Оскільки інформація може надходити в різних форматах, від технічних завдань до неповних описів завдань, важливо вживати активних заходів для уточнення деталей і заповнення пробілів.
При роботі з технічним завданням, створеним недосвідченим замовником, буває недостатньо інформації про цілі та обмеження системи. У разі макетів інтерфейсів, іноді складно однозначно зрозуміти користувальницькі сценарії та життєві цикли об'єктів. Навіть за таких простих запитів, як "реалізувати можливість відображення списку замовлень в ЛК користувача", неясно, в яких умовах користувачі взаємодіятимуть із продуктом і які у них ролі.
Ефективна стратегія включає активну взаємодію з замовником або іншими відповідальними сторонами.
Запит додаткової інформації про обмеження та цілі системи, завдання додаткових питань при виявленні прогалин в інформації, а також перевірка актуальності та часу створення артефактів стають першими кроками при опрацюванні завдання. Це допомагає сформувати повніше і точніше уявлення про вимоги, що, своєю чергою, забезпечує успішне виконання проекту.
Виявляти ризики та обмеження
Повністю згоден з вашим підходом до виявлення та опису ризиків та обмежень. Робота з цими аспектами дійсно потребує уваги та проактивного підходу з боку бізнес-аналітика.
Ризики, пов'язані зі зміною зацікавлених сторін, зміною їх точок зору та побажань, а також обмеження, пов'язані з тимчасовими рамками, архітектурою, інструментами та регулюючою документацією, що використовуються, є невід'ємною частиною проектної діяльності.
Бізнес-аналітик, як ви правильно зазначаєте, має здатність працювати з різноманітною інформацією на різних рівнях абстракції та виявляти нестиковки та прогалини, які можуть залишитися непоміченими іншими учасниками процесу.
Важливо не лише порушувати питання про ці нестиковки, а й обговорювати їхні наслідки та потенційні ризики для проекту.
Прозорість у спілкуванні та відкрите вираження занепокоєння щодо ризиків та обмежень є ключовими елементами успіху. Взаємодія із замовником, керівником проекту, архітектором, UX/UI-фахівцем та іншими учасниками проекту для чіткого розуміння ситуації та прийняття спільних рішень дійсно допомагає знизити ймовірність непередбачених проблем та підвищує якість проектної роботи.
