Лавки у Миколаєві прогинаються під дорослими. Хто винен? Бізнес-аналітик?

💡 Усі статті, обговорення, новини для аналітиків — в одному місці. Приєднуйтесь до Analysts спільноти!

Натрапила на новину. Скандал — новесенькі лавочки на дитячому майданчику у Миколаєві прогинаються і скриплять під вагою 82 кг. Обурена жінка залишила скаргу. Як пишуть новини, виявилося, що лавки виготовлені згідно з ТУ 2024 року і призначені виключно для дітей віком від 3 до 12 років, а їхня гранична вантажопідйомність — 80 кг. (посилання на оригінал новини)

Але цікавіше інше — як ця ситуація взагалі стала можливою, якщо подивитись на неї як бізнес-аналітик.

*зображення згенероване ШІ

Product Discovery і User Persona

Хто буде користуватись лавкою? Для кого ми її робимо? Міська рада замовляє лавки для дитячого майданчику, значить логічно → лавка для дітей. User — дитина. Але давайте подивимось глибше і проаналізуємо, що робить дитина на майданчику (її jobs to be done) — вочевидь, дитина більшість часу бігає і грається. А хто ж тоді користується лавкою? Батьки!

Тобто з самого початку неправильно визначений користувач і взагалі — для кого і для чого ми робимо цей продукт. Якщо подивитись на бізнес-аналіз в ІТ, то це одна з перших речей, які має з’ясувати бізнес-аналітик, коли починає працювати над новим продуктом. Для кого ми його робимо, навіщо, яку проблему ми вирішуємо. Так часто буває і в ІТ-проєктах, коли створений продукт не вирішує проблему або взагалі не потрібен тому юзеру.

Нефункціональні вимоги

Коли ми працюємо з нефункціональними вимогами на ІТ-проєктах, то часто зустрічаються Capacity/Load або, наприклад, Performance/Reliability. Наприклад, скільки навантаження система може витримати, якщо одночасно зайде 10 000 юзерів. Тут те саме — лавка не витримує більше 80 кг. А ще потрібно врахувати погодні умови, постійний вандалізм і так далі. Вочевидь, ці нефункціональні вимоги були не враховані або неправильно визначені. На ІТ-проєктах це часто виливається в те, що система падає в найвідповідальніший момент, бо не витримує навантаження. (Наприклад, часто буває на Black Friday — всі заходять купити щось на знижках, і сайт падає.)

Use Cases і Acceptance Testing

Всі ці проблеми випливають з першої, бо якщо б правильно визначили юзера, то, можливо, й з рештою проблем не було б.

Але все ж. Уявімо, що дійсно лавка для дітей. Зазвичай, коли ми аналізуємо use cases продукту чи системи, ми починаємо з успішного флоу. Дитина вагою приблизно 30 кг сідає на лавку. Лавка витримує, нічого не зігнулось, сидіти комфортно, дитина поміщається. Чи реально, що на лавку сядуть 3 дитини по 30 кг? Цілком реально, і це навіть досить частий кейс на майданчику, бо діти граються разом. І що тоді? А якщо вони ще й поставлять свої шкільні рюкзаки з книгами, а якщо почнуть стрибати на лавці чи з лавки?

Ми як бізнес-аналітики маємо аналізувати різні юз-кейси, а також альтернативні флоу і винятки. Сюди ж і acceptance testing додала, бо мають бути якісь критерії приймання — хтось мусив перевірити, чи ті лавки відповідають вимогам. Можливо, на цьому етапі можна було б зрозуміти, що щось не так, і виправити ще до введення в експлуатацію. Бізнес-аналітики роблять acceptance testing, щоб переконатись, що функціонал відповідає вимогам — є чіткі пункти (acceptance criteria), і ми їх перевіряємо, і на цьому етапі, якщо щось не так, є ще можливість виправити це перед релізом. (у мене теж бувало так, що щось з’ясувалось вже на acceptance testing, а до того якось пропустила вимогу чи не передбачила кейс)

Але все це не має сенсу, якщо з самого початку ми не визначили правильно проблему і користувача, не врахували контекст — тоді і наше рішення, як та лавка, ніби є, але реальну проблему не вирішує. Саме в цьому цінність бізнес-аналітиків — вони визначають проблему, потребу, користувачів і цінність на самому початку, і зменшують ризик невдачі та втрати грошей.

Чи були у вас подібні кейси? Як ви з ними справлялись?