Що таке БІЗНЕС АНАЛІЗ, з чим його «їдять», а головне чи варто за нього платити?
Бізнес-аналіз сьогодні відіграє роль «першої скрипки» в успішній реалізації IT-проектів.
Насамперед бізнес-аналіз – це побудова нового бізнес-процесу, з урахуванням можливостей програми, що розробляється. Основними його складовими є аналіз вимог Замовника, вивчення деталей, виявлення можливих слабких місць Проекту. Іншими словами, бізнес-аналітик має вникнути в бізнес-процеси Замовника, з`ясувати його побажання, проаналізувати їх, доповнити та сформулювати нову модель бізнесу у вигляді технічного завдання. ТЗ є самодостатнім документом, з яким Замовник може звернутися до команди розробників для подальшої оцінки та розробки. Як правило, життєвий цикл Проекту, а особливо розробки програмного забезпечення, складається з наступних етапів:
Вилучення якогось із цих етапів різко підвищує ймовірність провалу і втрату витрачених грошей і часу.
Не розуміючи важливості етапу «Аналізу», розраховуючи заощадити час та гроші, Замовники часто нехтують саме послугами бізнес-аналітика.А даремно!
Уявіть, що ви вирішили побудувати будинок і найняли для цього бригаду заробітчан з недалеких сонячних країн. Яка ймовірність того, що, викладаючи їм ваші побажання, ви не витратите свої нерви, намагаючись донести до них думку, що те, що вони роблять, не є «красивим і зручним»? І це взагалі насправді не те, що Ви хочете! Безсумнівно, ви, зрештою, порозумієтесь з ними. А тепер уявіть, що в індустрії розробки програмного забезпечення спеціалізований сленг/поняття/принципи побудови систем в рази складніші і об`ємніші, а програмісти часто виявляють набагато більше небажання вас розуміти і спілкуватися з Вами звичайною людською мовою. В основному вони пропонують, що зручно їм, те що вони «вміють» і коли-небудь вже робили. Те, на що потрібні мінімально витрачені зусилля!
Ось тут і приходить на допомогу бізнес-аналіз, в особі бізнес-аналітика, який «розуміє проблеми та можливості бізнесу в контексті вимог і рекомендує рішення, що дозволяють Вам досягти своїх цілей.
Як підтверджує наш багаторічний досвід у сфері IT, від того наскільки досконало з`ясовано та розписано завдання, наскільки правильно це відображено у ТЗ і чи буде залежати, чи буде Ваш Проект успішно та вчасно завершено виконавцем.
Якщо Ви хочете бути впевненим у тому, що всі побажання до майбутньої системи, ПЗ враховані та грамотно структуровані, зверніться до нашої Компанії. Наші спеціалісти в найкоротший термін підготують для вас якісне ТЗ, з яким Ви зможете звернутися вже до виконавця без ризику залишитися незрозумілим!
Корисна інформація!
Міфи та помилки.
Огляд найпоширеніших помилок, які виникають під час створення програм:
Міф №1 «Замовник знає, що він хоче». Або: починаємо писати програму зі слів замовника, не розібравшись у його бізнесі.
Це дуже поширена ілюзія розробників. Відноситься вона практично до всіх фахівців-початківців і навіть до професіоналів своєї справи, які не мають особистого досвіду роботи з постановниками завдань. Реальність така, що лише малий відсоток замовників, добре розуміє, навіщо йому потрібна програма, з чого вона складатиметься, і як працюватиме. І це цілком нормальна ситуація, тому що далеко не всі стикалися і мають уявлення про те, як відбувається створення програм, з яких етапів воно складається, і хто все це робить.
Ця помилка (особливо якщо має місце наступний описаний міф) спричинила невдачі у великій кількості проектів. Вона веде до того, що розробники починають проектувати і створювати програми, до ладу не розібравшись ні в самому бізнесі, ні для чого ця програма потрібна, ні як вона використовуватиметься. Це призводить до нескінченних переробок, які можуть початися ще на ранніх етапах, і збільшують обсяги проекту в рази, а на виході замовник отримує зовсім не те, що йому потрібно для підвищення ефективності свого бізнесу, тобто. абсолютно непотрібний для нього продукт.
Висновок
Перед початком розробки програми необхідно виконувати бізнес-аналіз, щоб виявити всі реальні потреби бізнесу, які мають бути відображені в програмі. На основі даних цього аналізу можна виконувати проектування та написання постановок (тех. завдань), які згодом будуть передані розробникам.
Міф № 2 «Виконавець знає, що мені потрібно». Або: одних програмістів нам буде достатньо, щоб зробити наш проект.
Міф дзеркальний першому, але ставиться вже до помилки замовника, у тому, що виконавець знає, чи зможе швидко розібратися, яка програма йому потрібна. Шановні замовники, якщо при розробці проекту Ви контактуєте безпосередньо з розробниками (програмістами), Вам необхідно розуміти, що в переважній більшості випадків розробник: мислить інакше, оцінює інакше, робить зовсім не ті висновки, на які Ви розраховуєте, і часто розмовляє з Вами "на різних мовах". Розробник – людина з іншим типом мислення, він не мислить категоріями бізнесу, категоріями функціональності та аналізу, не оцінює весь взаємозв`язок процесів, що відбуваються у Вашому бізнесі чи роботі. Для того щоб програму проектувала і розробляла одна людина, вона повинна поєднувати в собі: бізнес-аналітика, системного-аналітика і програміста. Тому що наявність таких навичок вимагає одночасно і великого, різнобічного досвіду та здібностей людини, як до програмування, так і до аналізу, нескладно зробити висновок, що таких фахівців небагато і зустрічаються вони не набагато частіше, ніж замовники, які чітко знають, що їм потрібно (міф №1 ).
Чим більший і складніший проект, тим гостріша необхідність поділу робіт. Бізнес-аналітик виконує аналіз бізнес-процесів та формує їх моделі. Системний аналітик на основі бізнес-аналізу проектує структуру об`єктів та їх взаємозв`язки, пише ТЗ розробникам. Програмісти займаються розробкою, використовуючи ТЗ від аналітиків.
Спроби економії на етапах бізнес та системного аналізу призводять до того, що узгоджується постановка задачі, в якій замовник і виконавець бачать зовсім різний результат. Швидше за все, вона буде успішно реалізована, буде витрачено час і гроші, а користь від отриманої програми буде дуже сумнівною. Є безліч прикладів, коли після реалізації проектів, з подібним підходом, після їх впровадження, все лише ускладнювалося і через короткий проміжок часу від програми відмовлялися або відправляли її на переробку.
Висновок.
Аналогічний попередньому: щоб створена програма була справді корисним інструментом і помічником у вашому бізнесі, на початковому етапі повинен виконати аналіз бізнес-аналітик, тільки після цього виконується етап проектування та написання постановок для програмістів і починається її розробка.
Міф № 3 «Програма вирішить усі мої проблеми». Або: я хочу велику червону кнопку, щоб при її натисканні все працювало і саме робилося.
Оману, що досить часто зустрічається, про те, що програма – панацея від усіх бід. Без неї все погано, бардак та робота не йде. А от якщо програма з`явиться, то все відразу чарівним чином зміниться і настане щастя. Насправді, це не так. Програма це лише ваш помічник, інструмент, який дозволяє полегшити і прискорити виконання низки процесів обробки та аналізу даних. Зазвичай потреба у використанні автоматизації з'являється тоді, коли обсяги даних, якими оперують люди, стає досить великим і звичні інструменти, такі як ручка, журнал або таблички в Excel вже не рятують. Тому перед впровадженням будь-якої програми потрібно зрозуміти які саме функції будуть на неї покладені, хто зі співробітників буде в ній працювати, з якими даними та які операції виконувати. Тільки в цьому випадку вона стане гарним та надійним помічником.
Висновок.
Перед впровадженням, у бізнес, будь-якої програми, потрібно сформулювати яким чином вона братиме участь у бізнес процесах, якою інформацією оперувати, хто, коли і як з нею працюватиме. Можливо, перед впровадженням програми потрібно буде реорганізувати бізнес процеси, з урахуванням нових можливостей, які стануть доступними Вам і вашим співробітникам.
Міф № 4 «Завжди можна знайти дешевший варіант». Міф про те, що якісну програму можна замовити дешево. Ні, ні та ще раз ні! Чому? Відповідь проста. Справа в тому, що розробка програмного забезпечення займає досить багато часу, а як відомо, час — це гроші. Звичайно завжди можна знайти студентів, новачків, які роблять перші кроки на терені IT, охочих взятися за реалізацію, поекспериментувати, набути досвіду, ще й отримати за це гроші. Однак, швидше за все, тут спрацює приказка «скупий платить двічі» і є ймовірність, що через якийсь час необхідно буде шукати нового виконавця. Як результат, втрачені гроші та час. То чи є сенс у такому невиправданому ризику?
Висновок.
Не треба гнатися за дешевими пропозиціями. Необхідно знайти фахівців, які можуть пояснити за що вони беруть з вас гроші і чому саме така ціна. Головне, щоб якість розробки виправдала вкладені в нього кошти.