10 правил для бізнес-аналітика

Вступ

Я відпрацював 1,5 року в великий великій компанії, яка займається оптовими і роздрібними поставками нафто-газового обладнання (оборот близько 30ккк рублів). Усередині впроваджена система управління (розроблена на 1С), що включає кілька конфігурацій для декількох бухгалтерій, складів і т.д. Близько 2к користувачів, що працюють в системі щодня.
 
Підтримує і розвиває всю систему команда аналітиків. За цей час у нас виробилися правила, які, на мою думку, допоможуть усім аналітикам (бізнес, вимог) і менеджерам, співробітникам підтримки і навіть трохи розробникам в крупному enterprise сегменті.
 
 

1. Аналітика ноги годують

Це правило придумав мій колега. Якщо ви знаходитесь в одному будівлю з користувачами і ключовими замовниками, то їх треба відвідувати і розмовляти з ними. Так як не всі вміють чітко і ясно висловлювати свої думки письмово, іноді один 15 хвилинну розмову може замінити триденну переписку.
 
 Ігнорування цього правила приведе до довгих поштовим листуванням і нескінченної формалізації задач.
 
 

2. Малюйте

Малювання схем бізнес-процесів і начерків інтерфейсу дозволить зрозуміти задачу вам і легко пояснити своє бачення користувачеві. Красиві схеми бізнес процесів справляють величезне враження на керівництво замовника. Особисто я використовував нотацію EPC з вільними добавками (досить просто для розуміння і досить наочно).
 
 Ігнорування цього правила зробить вашу роботу нудною призведе до того, що ви будете витрачати набагато більше часу на розуміння задачі та її пояснення.
 
 

3. Спрощуйте (або не ускладнюйте)

Аналітики і бізнес-аналітики схильні до ускладнення задач частіше, ніж би цього хотілося. Регулярно це негативно позначається на результаті. Я вважаю, що вирішувати завдання треба якомога простіше.
 
Десь через рік роботи я зрозумів, що думати треба за таким алгоритмом:
 
а) придумаємо просте рішення;
б) намагаємося з'ясувати чому не підходить;
в) трохи ускладнюємо;
г) намагаємося з'ясувати чому не підходить;
д) трохи ускладнюємо;
і т.д. поки рішення не стане оптимальним.
 
 Ігнорування цього правила призведе до створення велосипедів і невиправдано складних рішень, якими ніхто не користуватиметься.
 
 

4. Опитуйте всіх майбутніх користувачів і всіх учасників процесу

Бачення суб'єктивно, тому намагайтеся з'ясувати думку всіх, кого стосується майбутнє доробка, навіть тих, хто буде порушене суміжно. На практиці завжди є активний користувач, який гне свою лінію, але вона може виявитися неправильною, так як він не знає всіх підводних каменів і діяльності інших відділів так само добре, як і свого.
 
 Ігнорування цього правила призведе до того, що рішення не буде влаштовувати всіх, а задовольнятиме тільки одного користувача з яким ви працюйте.
 
 

5. докопуватися до суті проблеми

Користувачі постійно просять якісь кнопки на формах, якісь фільтри на списках і не люблять пояснювати навіщо. Але з'ясувавши відповідь на запитання «Навіщо?" Ви можете придумати зовсім інше рішення, яке можливе працюватиме краще і ефективніше.
 
 Ігнорування цього правила призведе до того, що рішення буде незавершене або не відповідатиме всім вимогам задачі.
 
 

6. Вирішуйте глобальні завдання

Наприклад, вас просять зробити документ, щоб включити відділ в процес роботи у вашій ERP системі. На підставі цієї вимоги ви повинні ставити глобальну задачу «Автоматизація відділу плано-економічного відділу» і з'ясовувати суміжні вимоги, але і докопуватися до суті, згідно з правилом 5. Це допоможе відразу розробити рішення, яке в майбутньому викличе менше доопрацювань.
 
 Ігнорування цього правила призведе до того, що завдання не будуть вирішуватися.
 
 

7. Користувач націлений на успіх (результат)

Дуже поширена помилка, що користувач або замовник не розуміють, що їм треба і слабо зацікавлені в результаті. Міф з'явився з того, що вони регулярно смакують дрібниці і там самим затягують розробку. Насправді, всі користувачі і замовники хочуть результат. Не забувайте про це!
 
 Ігнорування цього правила призведе до розвитку конфліктів.
 
 

8. Приймайте універсальні рішення (НЕ автоматизуйте автоматизоване)

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

9. Виконавець повинен розуміти, що він робить

Аналітики регулярно лінуються пояснювати розробникам суть проблеми, а ті лінуються слухати і вникати. Необхідно, щоб розробник розумів, що він робить і навіщо, а не просто «додай кнопку, яка ...». Це дозволить розробнику прийняти зважене рішення, а іноді і дати мудру пораду аналітику.
 
 Ігнорування цього правила призведе до поганих рішень з точки зору розробки.
 
 

10. Уникайте неоднозначності

Розбивайте задачу до таких деталей, щоб бачення результату було однозначно для вас, для ключових користувачів і для розробників. Це не завжди можливо, але прагне до цього необхідно.
 
 Ігнорування цього правила призведе до рішення не відповідає завданням.
 
 Рекомендована література:
1. & quot; Розробка вимог до програмного забезпечення & quot ;, 2004. Карл Вігерс
2. & quot; Принципи роботи з вимогами до програмного забезпечення. Уніфікований підхід & quot ;, Дін Леффінгуелл, Дон Уідріг

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.