Хочу поділитися з вами правдивою історією про початок становлення мене, як аналітика. Сподіваюся, інформація і висновки будуть корисні системним аналітикам-початківцям, бізнес-аналітикам.
1. Передісторія
Йшов 2006 рік. Мій шлях системного аналітика почався в дуже великій компанії з добре налагодженим життєвим циклом розробки.
Аналітики, менеджери проектів, програмісти, тестувальники, архітектори працювали в компанії вже не один рік. Задовго до моєї появи в команді, в компанії був затверджений формат специфікації вимог, для всіх зручний, звичний і зрозумілий.
Мені сказали: роби так, і буде всім щастя. І стало так... до релізу першого серйозного проекту. Там і з'ясувалося, що просто грамотно слідувати шаблону, а потім узгодити документ з необхідним списком осіб - недостатньо.
А з'ясувала я це вже через півроку роботи аналітиком.
Що ж я робила цілі півроку, запитаєте ви?
Мені доручали опис невеликих змін, про які так чи інакше всі були в курсі ще до мого приходу в компанію. Фахівці знали, що треба буде зробити; прийдешні проекти неодноразово обговорювалися раніше. А специфікація вимог була скоріше «папірцем» для збору підписів. Підписаний документ служив відмашкою: «можна починати, людей виділили, бюджет затвердили і проект розпочато» (це я зараз це розумію, але не тоді!).
Ще в мої обов'язки входив опис стандартних завдань (конфігурація або дрібні, прості зміни в системі). Такі вимоги теж були всім зрозумілі з півслова. Загалом, документ був нагадуванням, що треба зробити, але ніхто не вчитувався особливо.
І ось через півроку мені доручили непросте завдання. На початку проекту я, як зазвичай, зустрілася кілька разів з представником замовника, ми обговорили необхідні зміни, я їх описала, погодила з усіма. Отримавши на титульній сторінці необхідний набір підписів я, дуже задоволена виконаною роботою, віддала документ менеджеру і благополучно пішла у відпустку. «Моя робота в даному проекті завершена» - думала наївна я, спираючись на досвід попередніх дрібних завдань.
Ось тут-то і почалося найцікавіше. На глибині описаного мною рівня деталізації всім все було зрозуміло. Всі поставили свої підписи на документі. І віддали в роботу програмістам і тестувальникам. Коли справа дійшла до тестування, я вже давно повернулася з відпустки і займалася наступним завданням, на яке була виділена на 100%. А до мене почали приходити з питаннями тестувальники (перший раз у житті!). Вони знайшли відмінності між вимогами і реалізацією (ось так сюрприз!).
Загалом, один і той же текст трактувався по-різному: мною, програмістами і тестувальниками. Спасибі, хоч із замовниками у мене бачення збіглося. Потім ми разом відстоювали потрібний варіант. Описано було так, що, копнувши трохи глибше, кожен погано знайомий з процесами компанії фахівець міг знайти те, що йому було зручніше/зрозуміліше. Я була в шоці. Але швидко оговталася, «намотала цю ситуацію на ус» і провела роботу над помилками.
2. Які я тоді виділила проблемні місця
2.1. Якість специфікацій: вимоги були недостатньо конкретні. Була описана загальна ідея, при цьому шляхів реалізації можна було придумати кілька. А замовнику був важливий конкретний варіант. Відповідно, потрібно було або дуже докладно описати необхідне рішення, або щодня на етапі проектування і реалізації зустрічатися з командою, розповідати, що потрібно, дивитися, що виходить. Враховуючи бізнес процеси тієї компанії, та ще й майбутню відпустку, мені підійшов би перший варіант.
2.2. Участь аналітика в житті проекту: я брала участь тільки на початкових фазах життєвого циклу продукту. А аналітик потрібен на всіх етапах:
а) на фазі обговорення бізнес ідеї аналітик може підказати:
- чи можлива реалізація,
- способи і вартість реалізації.
б) фаза аналізу та проектування: ну, і так зрозуміло;
в) фаза розробки та тестування: відповідати на запитання програмістів і тестувальників, активно брати участь в обговореннях. Тестувати, перевіряти реалізацію основної функціональності. Переглянути тест-кейси або підказати тестувальникам «хитрі» моменти, що потрібно перевірити. Завжди є такі нюанси, що тільки аналітик тримає в голові, а перевірити їх нікому не спадає на думку:)
г) здача в експлуатацію та використання продукту: аналітик часто знає продукт краще за всіх і може взяти участь у підготовці презентацій продукту.
Якщо виникають питання або зауваження під час експлуатації, аналітик погоджує і пише вимоги до змін, при необхідності.
2.3. Узгодження документа: практика показала, що підпис на документі (узгодження документа) не завжди означає розуміння вимог підписуваним. Краще зайвий раз зустрітися (хоч у скайпі) з тими, від кого щось залежить і кому важливі результати проекту, провести презентацію і обговорити ключові вимоги, якщо є така можливість. Переконатися, що ви «на одній хвилі».
І ще момент, який я хочу відзначити зараз, але тоді не замислювалася про нього.
2.4. Облік рівня команди та специфіки проекту: цим злощасним проектом займалися новенькі в компанії
розробники і тестувальники. Якби не цей нюанс, то, можливо, все пройшло б добре і для розглянутого проекту, навіть без попередніх пунктів.
Мораль: спосіб збору та опису вимог, а так само модель реалізації проекту, залежить від конкретного проекту. Що необхідно враховувати:
- рівень команди;
- зануреність команди в проект;
- спрацьованість команди;
- тип завдань (щось стандартне для цієї команди, конфігурація, або складний, унікальний проект);
- бюджет і терміни проекту;
- багато іншого.
Але ця думка відвідала мене не відразу, і ще якийсь час я шукала свою ідеальну специфікацію.
3. Що я робила в ситуації, що склалася:
3.1. Багато читала: в хід пішли Вігерс, Леффінгуелл, Коберн, і т. д. Я розглядала приклади специфікацій, намагалася почерпнути максимум корисного і підходящого, і негайно це використовувала в роботі.
3.2. Організувала своєчасний зворотний зв'язок тестувальників і програмістів на ранніх стадіях проекту:
менеджер проекту дивувався, коли я просила виділити тестувальника для перегляду специфікації, але йшов назустріч. Адже є такі питання, що спадають на думку тільки тестувальникам! І добре, коли вони розглянуті вчасно.
3.3. Збирала разом когось із представників замовника, програмістів, тестувальника, менеджера проекту перед запуском проекту: на такій зустрічі ми переконувалися, що правильно розуміємо один одного, нагадували важливі деталі тощо.
Через короткий період часу програмісти стали відзначати прогрес і дякувати за специфікації.
І тут я зрозуміла, що застопорилася на якомусь рівні і хочу рухатися далі. У мене з'явилася нав'язлива ідея: дізнатися, як в інших компаніях пишуть специфікації, і почерпнути щось нове для себе. Знайшлися форуми, спільнота аналітиків. Я читала «а як в інших», розглядала приклади, ініціювала зустрічі і ставила запитання.
Окремо хочу зазначити, що світ не без добрих людей, і малознайомі, але досвідчені аналітики жодного разу мені не відмовили у зустрічі і відповідях на питання. Спасибі вам, дорогі колеги. Тому, «шукайте і знайдете, стукайте, і вам відворять».
Продовження слід...
