## Giriş
Layihələrdə maraqlı tərəflərin müxtəlif maraqlarını uzlaşdırmaq çox vaxt çətin olur. Bəzən elə görünür ki, layihə irəliləmir, əksinə, hər kəs öz tərəfinə çəkməyə çalışır. Bunun əsas səbəblərindən biri — maraqlı tərəflərin həqiqi motivasiyalarının və gözləntilərinin tam başa düşülməməsidir. 

Bu məqamda **Stakeholder xəritəsi** (maraqlı tərəflər xəritəsi) ən güclü alətlərdən birinə çevrilir. O, sadəcə vizual diaqram deyil, layihəyə təsir edən bütün şəxslərin və ya qrupların nə istədiyini anlamaq vasitəsidir. 

 

## Stakeholder xəritəsinin mahiyyəti
Stakeholder xəritəsi sizə vəzifə adlarının arxasına baxmaq və insanların real motivasiyalarını görmək imkanı verir. Bu, suallar vasitəsilə gizli hədəfləri və ya narahatlıqları üzə çıxarır: 

- Kimin əlində real güc var? 
- Kim layihədən ən çox təsirlənəcək? 
- Onların açıq demədikləri gizli gündəmləri varmı? 
- Onların prioritetləri sizin hədəflərinizlə necə kəsişir? 

Belə xəritə layihənin uğuru üçün görünməyən əlaqələri və təsir güclərini aşkara çıxarır. 

 

## Əsas suallar
Stakeholder xəritəsini hazırlayarkən özünüzə bu sualları vermək faydalıdır: 
- Bu layihə ilə bağlı ən böyük narahatlıqları nədir? 
- Onlar bu layihədən nə qazanacaq və ya nə itirə bilərlər? 
- Kimə təsir edirlər və kimdən təsirlənirlər? 
- Onların maraqları bizimlə harada üst-üstə düşür? 

Bu sadə, amma güclü suallar sizi daha dəqiq analizə aparır. 

 

## Nümunələr praktikadan
- **Bank sektoru:** Yeni mobil tətbiq hazırlanarkən texniki komanda performansa fokuslanmışdı, amma marketinq komandası yalnız interfeysin rənglərinə diqqət edirdi. Stakeholder xəritəsi vasitəsilə onların hər birinin gözləntiləri aydın oldu və prioritetlər balanslaşdırıldı. 
- **Dövlət layihəsi:** İctimai xidmət platformasında müxtəlif dövlət qurumlarının tələbləri ziddiyyətli idi. Xəritə hazırlanaraq hər qurumun gücü və təsir sahəsi göstərildi. Nəticədə dialoq daha konstruktiv oldu. 

 

## Stakeholder xəritəsinin faydaları
- **Kommunikasiya strategiyası:** Hər bir tərəflə fərdi yanaşma qurmaq mümkündür. 
- **Etirazların idarə olunması:** Potensial konfliktləri əvvəlcədən proqnozlaşdırmaq olur. 
- **Müttəfiqlərin müəyyənləşdirilməsi:** Layihəni dəstəkləyəcək güclü tərəfləri tapmaq asanlaşır. 
- **Ortaq məqsəd:** Hər kəsin maraqlarını ortaq bir hədəf ətrafında birləşdirmək olur. 

 

## Çek-list: Stakeholder xəritəsi üçün
- Maraqlı tərəfləri siyahıya alın. 
- Onların güc və təsir dərəcəsini qiymətləndirin. 
- Əsas narahatlıq və hədəflərini müəyyənləşdirin. 
- Əlaqələr və təsir rıçaqlarını vizuallaşdırın. 
- Kommunikasiya planınızı fərdiləşdirin. 

 

## Nəticə
Stakeholder xəritəsi sadəcə konfliktləri idarə etmək deyil, layihənin bütün iştirakçılarını ortaq məqsəd ətrafında birləşdirmək sənətidir. 

Siz layihələrinizdə stakeholder xəritəsindən necə istifadə etmisiniz? Təcrübənizi şərhlərdə paylaşın və məqaləni «Bəyəndim» və ya «Bəyənmədim» düymələri ilə qiymətləndirin.

<h2 id="giri">Giriş</h2>
Layihələrdə maraqlı tərəflərin müxtəlif maraqlarını uzlaşdırmaq çox vaxt çətin olur. Bəzən elə görünür ki, layihə irəliləmir, əksinə, hər kəs öz tərəfinə çəkməyə çalışır. Bunun əsas səbəblərindən biri — maraqlı tərəflərin həqiqi motivasiyalarının və gözləntilərinin tam başa düşülməməsidir. 
Bu məqamda Stakeholder xəritəsi (maraqlı tərəflər xəritəsi) ən güclü alətlərdən birinə çevrilir. O, sadəcə vizual diaqram deyil, layihəyə təsir edən bütün şəxslərin və ya qrupların nə istədiyini anlamaq vasitəsidir. 
 
<h2 id="stakeholderxritsininmahiyyti">Stakeholder xəritəsinin mahiyyəti</h2>
Stakeholder xəritəsi sizə vəzifə adlarının arxasına baxmaq və insanların real motivasiyalarını görmək imkanı verir. Bu, suallar vasitəsilə gizli hədəfləri və ya narahatlıqları üzə çıxarır: 
<ul>
<li>Kimin əlində real güc var? </li>
<li>Kim layihədən ən çox təsirlənəcək? </li>
<li>Onların açıq demədikləri gizli gündəmləri varmı? </li>
<li>Onların prioritetləri sizin hədəflərinizlə necə kəsişir? </li>
</ul>
Belə xəritə layihənin uğuru üçün görünməyən əlaqələri və təsir güclərini aşkara çıxarır. 
 
<h2 id="sassuallar">Əsas suallar</h2>
Stakeholder xəritəsini hazırlayarkən özünüzə bu sualları vermək faydalıdır: 
<ul>
<li>Bu layihə ilə bağlı ən böyük narahatlıqları nədir? </li>
<li>Onlar bu layihədən nə qazanacaq və ya nə itirə bilərlər? </li>
<li>Kimə təsir edirlər və kimdən təsirlənirlər? </li>
<li>Onların maraqları bizimlə harada üst-üstə düşür? </li>
</ul>
Bu sadə, amma güclü suallar sizi daha dəqiq analizə aparır. 
 
<h2 id="nmunlrpraktikadan">Nümunələr praktikadan</h2>
<ul>
<li>Bank sektoru: Yeni mobil tətbiq hazırlanarkən texniki komanda performansa fokuslanmışdı, amma marketinq komandası yalnız interfeysin rənglərinə diqqət edirdi. Stakeholder xəritəsi vasitəsilə onların hər birinin gözləntiləri aydın oldu və prioritetlər balanslaşdırıldı. </li>
<li>Dövlət layihəsi: İctimai xidmət platformasında müxtəlif dövlət qurumlarının tələbləri ziddiyyətli idi. Xəritə hazırlanaraq hər qurumun gücü və təsir sahəsi göstərildi. Nəticədə dialoq daha konstruktiv oldu. </li>
</ul>
 
<h2 id="stakeholderxritsininfaydalar">Stakeholder xəritəsinin faydaları</h2>
<ul>
<li>Kommunikasiya strategiyası: Hər bir tərəflə fərdi yanaşma qurmaq mümkündür. </li>
<li>Etirazların idarə olunması: Potensial konfliktləri əvvəlcədən proqnozlaşdırmaq olur. </li>
<li>Müttəfiqlərin müəyyənləşdirilməsi: Layihəni dəstəkləyəcək güclü tərəfləri tapmaq asanlaşır. </li>
<li>Ortaq məqsəd: Hər kəsin maraqlarını ortaq bir hədəf ətrafında birləşdirmək olur. </li>
</ul>
 
<h2 id="ekliststakeholderxritsin">Çek-list: Stakeholder xəritəsi üçün</h2>
<ul>
<li>Maraqlı tərəfləri siyahıya alın. </li>
<li>Onların güc və təsir dərəcəsini qiymətləndirin. </li>
<li>Əsas narahatlıq və hədəflərini müəyyənləşdirin. </li>
<li>Əlaqələr və təsir rıçaqlarını vizuallaşdırın. </li>
<li>Kommunikasiya planınızı fərdiləşdirin. </li>
</ul>
 
<h2 id="ntic">Nəticə</h2>
Stakeholder xəritəsi sadəcə konfliktləri idarə etmək deyil, layihənin bütün iştirakçılarını ortaq məqsəd ətrafında birləşdirmək sənətidir. 
Siz layihələrinizdə stakeholder xəritəsindən necə istifadə etmisiniz? Təcrübənizi şərhlərdə paylaşın və məqaləni «Bəyəndim» və ya «Bəyənmədim» düymələri ilə qiymətləndirin.

Stakeholder xəritəsi: müxtəlif maraqları necə uzlaşdırmalı?

## Giriş


Karyerama başlayanda İT-biznes analitik daha çox “sənəd insanı” idi. Tələbləri toplayırdıq, onlarla səhifəlik texniki tapşırıqlar yazırdıq, həftələrlə təsdiqlədirdik, sonra isə hər şey dəyişəndə yenidən yazmalı olurduq. 

O vaxtdan çox keçməyib, amma bu gün analitikin rolu tamamilə dəyişib. Süni intellekt artıq rutin işləri görür, biznes bizdən daha çox şey gözləyir, bazar isə hər zamankından daha sürətlə dəyişir. 

Bu yazıda hansı bacarıqların dəyərini itirdiyini, hansılarının əsas olduğunu və bu keçidi necə yaşadığımı danışacam. 

 

## 2025-də İT-biznes analitikin rolu necə dəyişdi 

Xatırlayıram, 30–50 səhifəlik texniki tapşırıqlar yazırdım. O vaxt elə bilirdilər ki, sənəd qalındırsa, iş də ciddi görünür. Saatlarla diaqramlar çəkirdik, uzun proses təsvirlərini oxuyur, hamısını yadda saxlamağa çalışırdıq. 

İndi isə vəziyyət tamam başqadır. User story və acceptance criteria artıq bir neçə dəqiqəyə ChatGPT ilə hazırlanır. FigJam və ya Miro AI diaqramları avtomatik qurur. Jira isə özü tapşırığın necə daha yaxşı tərtib olunacağını təklif edir. 

Amma maraqlısı alətlər deyil. Əsas fərq odur ki, bizdən gözləntilər dəyişib. Əvvəl analitikdən əsasən dəqiq sənədləşmə gözlənilirdi. Bu gün isə komandalar daha çox şey istəyir: **məhsulu bütöv görmək, strateji qərarlara təsir göstərmək, düzgün suallar vermək**. 

İT-biznes analitik artıq sadəcə **“sənəd yazarı”** deyil, o **“dəyər memarı”na** çevrilib. 

 

## Dəyərini itirən bacarıqlar 

Yaxşı xatırlayıram ki, bir vaxtlar analitikin dəyəri yazdığı sənədlərin həcmi ilə ölçülürdü. Nə qədər çox səhifə yazırdınsa, o qədər “peşəkar” sayılırdın. Amma o dövr artıq bitib. 

&ensp;* **Uzun-uzadı texniki tapşırıqlar.** Heç kim 50 səhifəlik sənəd oxumur. Komandalar canlı və çevik artefaktlara ehtiyac duyur. 
&ensp;* **Əl ilə diaqram çəkmək.** Əvvəllər həftələrlə çəkdiyimiz işləri indi İİ dəqiqələrə həll edir. 
&ensp;* **Toplantılarda passiv iştirak.** Analitik sadəcə qeydlər aparan biri olmamalıdır. Bu gün ondan aktivlik, fasilitasiya və iştirak gözlənilir. 

Dünən bizi “əvəzolunmaz” edən bacarıqlar bu gün avtomatlaşdırılır. Və bu, pis deyil — çünki daha dəyərli bacarıqlara yol açır. 

 

## Yeni əsas bacarıqlar 

Düzünü desəm, əvvəl süni intellektə skeptik yanaşırdım. Düşünürdüm ki, bu, sadəcə texnologiya həvəsidir və mənim işimlə heç bir əlaqəsi yoxdur. 

Amma bir gün anladım ki, qarşıda iki yolum var: 
Ya köhnə üsullarla işləyirəm və yavaş-yavaş geridə qalıram, ya da yeni texnologiyaları öyrənib güclənirəm. 

Mən ikinci yolu seçdim. Və bu, karyeramda verdiyim ən yaxşı qərarlardan biri oldu. 

Bu gün bir saata gördüyüm işi əvvəllər bir günə ancaq bitirirdim. İİ mənim üçün artıq təhlükə deyil — güclü bir köməkçidir. 

2025-ci ildə analitik üçün əsas bacarıqlar bunlardır: 

&ensp;* **Sİ ilə işləmə bacarığı.** Düzgün sorğu qurmaq və nəticəni işdə real tətbiq etmək. 

&ensp;* **Sistemli düşüncə.** Məhsulu bütöv görmək, yalnız bir user story ilə kifayətlənməmək. 

&ensp;* **Fasilitasiya.** Workshop-ları idarə etmək, çətin suallar vermək, komandanı düşünməyə sövq etmək. 

&ensp;* **Məhsul yanaşması.** Özünü sadəcə sənəd toplayanı kimi deyil, məhsul sahibinin yerində görmək. 


 

## Bu bacarıqları bu gündən necə inkişaf etdirmək olar 

Köhnə üsulların dəyərini itirdiyini başa düşəndə kiçikdən başladım — **eksperimentlərdən**. Gündəlik tapşırıqlarımı götürüb onları İİ ilə həll etməyə çalışırdım. Bəzən alınırdı, bəzən yox, amma o vaxt anladım: məsələ alətdə deyil, **ondan necə istifadə etdiyindədir**. 

Növbəti addımım fasilitasiya oldu. Əvvəllər sadəcə qeydlər aparırdım, indi isə toplantılarda təşəbbüs göstərməyə başladım: suallar verdim, müzakirəni yönləndirdim, komandaya cavabları tapmağa kömək etdim. Əvvəl çətin idi, amma sonradan məhz bu, mənə hörmət qazandırdı. 

Və ən əsası — artıq yalnız analitik kimi düşünmürdüm. Özümə sual verdim: *“Əgər bu məhsul mənim olsaydı, nə edərdim?”* Bu andan etibarən məndə məhsul yanaşması formalaşdı. Bu bacarıq olmadan 2025-də analitik sadəcə aktual qala bilməz. 

 

## Nəticə 

İT-biznes analitikin rolu dəyişir. Biz artıq uzun sənədlərin müəllifi deyilik — biz dəyər memarıyıq. Kim öyrənməyə və uyğunlaşmağa hazırdırsa, növbəti mərhələyə qalxacaq. 

2026-nı gözləməyin. Bu gündən başlayın. 
Və bu yolda praktik alətlərə ehtiyacınız varsa, saytımın "Resurslar" bölməsinə baxın — orada mən hər gün özüm istifadə etdiyim vasitələri toplamışam.

<h2 id="giri">Giriş</h2>
Karyerama başlayanda İT-biznes analitik daha çox “sənəd insanı” idi. Tələbləri toplayırdıq, onlarla səhifəlik texniki tapşırıqlar yazırdıq, həftələrlə təsdiqlədirdik, sonra isə hər şey dəyişəndə yenidən yazmalı olurduq. 
O vaxtdan çox keçməyib, amma bu gün analitikin rolu tamamilə dəyişib. Süni intellekt artıq rutin işləri görür, biznes bizdən daha çox şey gözləyir, bazar isə hər zamankından daha sürətlə dəyişir. 
Bu yazıda hansı bacarıqların dəyərini itirdiyini, hansılarının əsas olduğunu və bu keçidi necə yaşadığımı danışacam. 
 
<h2 id="2025dtbiznesanalitikinrolunecdyidi">2025-də İT-biznes analitikin rolu necə dəyişdi</h2>
Xatırlayıram, 30–50 səhifəlik texniki tapşırıqlar yazırdım. O vaxt elə bilirdilər ki, sənəd qalındırsa, iş də ciddi görünür. Saatlarla diaqramlar çəkirdik, uzun proses təsvirlərini oxuyur, hamısını yadda saxlamağa çalışırdıq. 
İndi isə vəziyyət tamam başqadır. User story və acceptance criteria artıq bir neçə dəqiqəyə ChatGPT ilə hazırlanır. FigJam və ya Miro AI diaqramları avtomatik qurur. Jira isə özü tapşırığın necə daha yaxşı tərtib olunacağını təklif edir. 
Amma maraqlısı alətlər deyil. Əsas fərq odur ki, bizdən gözləntilər dəyişib. Əvvəl analitikdən əsasən dəqiq sənədləşmə gözlənilirdi. Bu gün isə komandalar daha çox şey istəyir: məhsulu bütöv görmək, strateji qərarlara təsir göstərmək, düzgün suallar vermək. 
İT-biznes analitik artıq sadəcə “sənəd yazarı” deyil, o “dəyər memarı”na çevrilib. 
 
<h2 id="dyriniitirnbacarqlar">Dəyərini itirən bacarıqlar</h2>
Yaxşı xatırlayıram ki, bir vaxtlar analitikin dəyəri yazdığı sənədlərin həcmi ilə ölçülürdü. Nə qədər çox səhifə yazırdınsa, o qədər “peşəkar” sayılırdın. Amma o dövr artıq bitib. 
 * Uzun-uzadı texniki tapşırıqlar. Heç kim 50 səhifəlik sənəd oxumur. Komandalar canlı və çevik artefaktlara ehtiyac duyur. 
 * Əl ilə diaqram çəkmək. Əvvəllər həftələrlə çəkdiyimiz işləri indi İİ dəqiqələrə həll edir. 
 * Toplantılarda passiv iştirak. Analitik sadəcə qeydlər aparan biri olmamalıdır. Bu gün ondan aktivlik, fasilitasiya və iştirak gözlənilir. 
Dünən bizi “əvəzolunmaz” edən bacarıqlar bu gün avtomatlaşdırılır. Və bu, pis deyil — çünki daha dəyərli bacarıqlara yol açır. 
 
<h2 id="yenisasbacarqlar">Yeni əsas bacarıqlar</h2>
Düzünü desəm, əvvəl süni intellektə skeptik yanaşırdım. Düşünürdüm ki, bu, sadəcə texnologiya həvəsidir və mənim işimlə heç bir əlaqəsi yoxdur. 
Amma bir gün anladım ki, qarşıda iki yolum var: 
Ya köhnə üsullarla işləyirəm və yavaş-yavaş geridə qalıram, ya da yeni texnologiyaları öyrənib güclənirəm. 
Mən ikinci yolu seçdim. Və bu, karyeramda verdiyim ən yaxşı qərarlardan biri oldu. 
Bu gün bir saata gördüyüm işi əvvəllər bir günə ancaq bitirirdim. İİ mənim üçün artıq təhlükə deyil — güclü bir köməkçidir. 
2025-ci ildə analitik üçün əsas bacarıqlar bunlardır: 
 * Sİ ilə işləmə bacarığı. Düzgün sorğu qurmaq və nəticəni işdə real tətbiq etmək. 
 * Sistemli düşüncə. Məhsulu bütöv görmək, yalnız bir user story ilə kifayətlənməmək. 
 * Fasilitasiya. Workshop-ları idarə etmək, çətin suallar vermək, komandanı düşünməyə sövq etmək. 
 * Məhsul yanaşması. Özünü sadəcə sənəd toplayanı kimi deyil, məhsul sahibinin yerində görmək. 
 
<h2 id="bubacarqlarbugndnnecinkiafetdirmkolar">Bu bacarıqları bu gündən necə inkişaf etdirmək olar</h2>
Köhnə üsulların dəyərini itirdiyini başa düşəndə kiçikdən başladım — eksperimentlərdən. Gündəlik tapşırıqlarımı götürüb onları İİ ilə həll etməyə çalışırdım. Bəzən alınırdı, bəzən yox, amma o vaxt anladım: məsələ alətdə deyil, ondan necə istifadə etdiyindədir. 
Növbəti addımım fasilitasiya oldu. Əvvəllər sadəcə qeydlər aparırdım, indi isə toplantılarda təşəbbüs göstərməyə başladım: suallar verdim, müzakirəni yönləndirdim, komandaya cavabları tapmağa kömək etdim. Əvvəl çətin idi, amma sonradan məhz bu, mənə hörmət qazandırdı. 
Və ən əsası — artıq yalnız analitik kimi düşünmürdüm. Özümə sual verdim: “Əgər bu məhsul mənim olsaydı, nə edərdim?” Bu andan etibarən məndə məhsul yanaşması formalaşdı. Bu bacarıq olmadan 2025-də analitik sadəcə aktual qala bilməz. 
 
<h2 id="ntic">Nəticə</h2>
İT-biznes analitikin rolu dəyişir. Biz artıq uzun sənədlərin müəllifi deyilik — biz dəyər memarıyıq. Kim öyrənməyə və uyğunlaşmağa hazırdırsa, növbəti mərhələyə qalxacaq. 
2026-nı gözləməyin. Bu gündən başlayın. 
Və bu yolda praktik alətlərə ehtiyacınız varsa, saytımın "Resurslar" bölməsinə baxın — orada mən hər gün özüm istifadə etdiyim vasitələri toplamışam.

İT-biznes analitik 2025: Süni İntellekt dövründə yeni bacarıqlar

## Fəsil 1. “Zəif bənd” 
> _“Niyə vasitəçi lazımdır? Mən özüm developerlərlə danışaram!”_ 
> _“Yenə Texniki Tapşırıq (TT)? Sadəcə dediyim kimi edin!”_ 

İlk böyük layihəmi yaxşı xatırlayıram. Bir tərəfdə əsəbi biznes müştərisi beşinci dəfə “sadəcə o düyməni əlavə edin!” deyə təkid edir, digər tərəfdə isə developer komandası səssizcə masaya zillənmişdi. Həmin an mən körpü yox, iki dünya arasında “süni baryer” idim. 

10–12 il əvvəl biznes analitiki (BA) belə görünürdü: biznes üçün — “xarab telefon”, developer üçün — “sənəd yazan adam”. Sistemdə xəta tapılanda isə günahkar da BA sayılırdı. 

Amma bu illər ərzində bu rol kvant sıçrayışı etdi: sadə sənədçidən məhsulun gələcəyinə təsir edən strateji tərəfdaşa çevrildi. 

 

## Fəsil 2. Junior. Dinləmə sənəti 

**Bu mərhələ nədir?** 
Şagirdlik səviyyəsi. Sənə konkret tapşırıqlar verilir: ekran formalarının təsvirini yazmaq, cədvəl tərtib etmək, Postman ilə “endpoint”ləri yoxlamaq. Heç kim səndən möhtəşəm ideyalar gözləmir, amma dəqiqlik və düzgün sual vermə bacarığı tələb olunur. 

**Necə hiss olunur?** 
Sən “istəklər dilindən” “kod dilinə” tərcümə edirsən, ancaq söz ehtiyatın bir stikerə sığacaq qədər azdır. Hələ də yadımdadır, yarım saat developera “overdraft”ın nə olduğunu izah etməyə çalışırdım. Sonda o dedi: “Aha, bu sadəcə limit daxilində mənfi balansdır”. 

Ən böyük qorxun — “lazımsız sual” verməkdir. Ən böyük kəşfin isə belə sualların əslində olmamasıdır. 

&ensp;- **Tipik tələlər:** tələbləri dəqiqləşdirmək əvəzinə fərz etmək; texniki terminləri bilməməkdən çəkinmək; prosesləri anlamaq əvəzinə alətlərə köklənmək. 
&ensp;- **İnkişaf etdirməli bacarıqlar:** aktiv dinləmə, Confluence/Jira/Figma ilə sərbəst işləmək, fundamental texniki biliklər (verilənlər bazası, API, veb-tətbiqlərin iş prinsipi). 
&ensp;- **Böyümə əlaməti:** artıq müsahibələri sərbəst apara, aydın tələblər formalaşdıra bilirsən və developerlər sənədlərini təkrar yoxlamağa ehtiyac duymur. 

> **Əsas dərs:** diqqətlilik sənin super gücündür. 

 

## Fəsil 3. Middle. Körpü quran 

**Bu mərhələ nədir?** 
Artıq BA sadəcə “yazan” deyil, sistemi bütöv şəkildə görməyə başlayır. Kiçik dəyişikliklərin böyük nəticələrə səbəb ola biləcəyini anlayır. 

**Necə hiss olunur?** 
İlk dəfə biznesə “yox” deyirsən, amma bu, əsaslandırılmış cavab olur: *“yox, çünki…”*. 
Məsələn, marketinq departamenti loyallıq proqramını kart məhsuluna inteqrasiya etmək istəyəndə bunu “sadəcə bir əlavə” adlandırmışdı. Mən isə böyük bir diaqram çəkib bu “sadə” funksionallığın prosessinq mərkəzinə, CRM-ə və hesabat sisteminə necə təsir etdiyini göstərdim. 

&ensp;- **Tipik tələlər:** “mən hər şeyi daha yaxşı bilirəm” sindromu; sənədləri həddən artıq detallı yazmaq; son istifadəçini nəzərdən qaçırmaq. 
&ensp;- **İnkişaf etdirməli bacarıqlar:** sistemli təfəkkür (korporativ arxitektura, inteqrasiyalar), kommunikasiya (moderasiya, münaqişələrin həlli, təqdimat), analitik metodlar (BPMN, Story Mapping). 
&ensp;- **Böyümə əlaməti:** başqa komandaların əməkdaşları məsləhət üçün sənə müraciət edir, sənin risk qiymətləndirmələrin reallıqda təsdiqlənir. 

> **Əsas dərs:** “yazmaqdan” “izah etməyə və təsir göstərməyə” keçid. 

 

## Fəsil 4. Senior. Sistemin keşikçisi 

**Bu mərhələ nədir?** 
Artıq analitik bütün məhsul və ya domenə görə məsuliyyət daşıyır. Həm biznes hədəfləri, həm də sistemin texniki məhdudiyyətləri onun zehnindədir. 

**Necə hiss olunur?** 
Heç vaxt unutmaram: köhnə “Core Banking” sistemindən yenisinə məlumatların miqrasiyası öncəsi gecə. Səhər saat 4-ə qədər balansları yoxlayırdıq. Spesifikasiyadakı bircə səhv sahə minlərlə müştərinin səhv balans görməsi demək idi. 

O an anlayırsan: işin sadəcə Jira tapşırığı deyil, böyük bir məsuliyyətdir. Artıq “funksionallıq” yox, “etibarlılıq, risk və miqyaslanma” ilə düşünürsən. 

&ensp; - **Tipik tələlər:** əvəzolunmazlıq sindromu; mikromenecment; texniki detallarda itib biznes baxışını itirmək. 
&ensp; - **İnkişaf etdirməli bacarıqlar:** strateji planlaşdırma (roadmap, texniki borc, refaktorinq), risklərin idarə olunması, mentorluq. 
&ensp; - **Böyümə əlaməti:** sənin arxitektura qərarların digər komandalar üçün standart olur, C-level rəhbərlik strateji dəyişikliklərdə səninlə məsləhətləşir. 

> **Əsas dərs:** sən artıq sadəcə ötürücü deyilsən — sistemin ortaq sahibisən. 

 

## Fəsil 5. Beyond Senior. Dəyişikliklər agenti 

**Bu mərhələ nədir?** 
BA komanda hüdudlarını aşaraq mədəniyyət və metodologiya daşıyıcısına çevrilir. O, yalnız məhsulu deyil, bütün təşkilatın işləmə tərzini təkmilləşdirir. 

**Necə hiss olunur?** 
Bankda Agile metodologiyasını tətbiq edəndə anladım: əsas işim mükəmməl “User Story” yazmaq yox, 80 komandanın istifadə edə biləcəyi vahid bir şablon yaratmaq idi. 

Sənin dəyərin artıq tapşırığı icra etmək deyil, başqalarının işini asanlaşdıran sistem qurmaqdır. 

&ensp; - **Tipik tələlər:** hər şeyi birdən dəyişmək istəyi; əməliyyat işlərindən tamamilə qopmaq; müqavimət səbəbindən tükənmək. 
&ensp; - **İnkişaf etdirməli bacarıqlar:** dəyişikliklərin idarə edilməsi (change management), təşkilati dizayn, ictimai çıxış bacarıqları. 
&ensp; - **Böyümə əlaməti:** sənin tətbiq etdiyin yanaşmalar layihələrdən daha uzunömürlü olur və bütün şirkətə yayılır. 

> **Əsas dərs:** bu mərhələdə sən fikir liderinə və dəyişikliklərin təşəbbüskarına çevrilirsən. 

 

## Fəsil 6. Memar / Strateq. Gələcəyə baxış 

**Bu mərhələ nədir?** 
Ən yüksək səviyyə. BA artıq ekosistem miqyasında düşünür: biznes strategiyası, korporativ arxitektura, texnoloji trendlər. 

**Necə hiss olunur?** 
Artıq “kredit modulu necə işləyəcək?” sualını deyil, “3 ildən sonra bu modulun API-si dövlət fintex platforması ilə necə inteqrasiya olunacaq və bu, müştəri təcrübəsini necə dəyişəcək?” sualını düşünürsən. 

Sən evlər yox, şəhərlər qurursan. Süni intellekt rutin işləri avtomatlaşdırır, amma yalnız sən konteksti anlaya və etik qərarlar verə bilərsən. 

&ensp;- **Əsas kompetensiyalar:** gələcək vizionu, ekosistem təfəkkürü, səlahiyyətsiz təsir bacarığı. 

> **Əsas dərs:** bu səviyyədə BA artıq tələbləri analiz etmir — o, gələcəyi formalaşdırır. 

 

## Fəsil 7. Karyera platoları: necə ilişib qalmamaq? 

&ensp; - **Junior → Middle:** məsuliyyətdən qorxmaq, alətlərə həddən artıq köklənmək, münaqişələrdən yayınmaq. 
&ensp; - **Middle → Senior:** komfort zonası, texniki mükəmməlliyə aludə olmaq, zəif mentorluq. 
&ensp; - **Senior → Beyond:** əvəzolunmazlıq sindromu, strateji vizyonun olmaması. 

**Necə öhdəsindən gəlmək:** dürüst özünüqiymətləndirmə, mentor tapmaq, iş kontekstini dəyişmək, əlavə bacarıqlar öyrənmək (UX, məhsul idarəçiliyi, arxitektura). 

 

## Nəticə: Daim təkamül edən bir rol 

BA-nın təkamül yolu İT-nin özünü əks etdirir: 
**“Sənədçi” → Məhsul tərəfdaşı → Dəyər memarı.** 

&ensp; - Junior dinləməyi öyrədir. 
&ensp; - Middle — sistemi görməyi. 
&ensp; - Senior — məsuliyyəti daşımağı. 
&ensp; - Beyond — mədəniyyəti dəyişməyi. 
&ensp; - Memar — gələcəyi formalaşdırmağı. 

IIBA (International Institute of Business Analysis) da bu trayektoriyanı təsdiqləyir: BA çox vaxt Biznes Memarı, Məhsul Sahibi (Product Owner) və ya Korporativ Memar (Enterprise Architect) roluna keçir. 

Süni intellekt (AI) BA-nı əvəz etməyəcək, sadəcə sürətləndirəcək. 
Amma yalnız insan stakeholder-lərin motivlərini anlaya, etik qərarlar verə və ideyalarla kod arasında körpü qura bilər — gələcəyin üzərindən keçəcəyi körpünü. 

**Müəllif:** Sərxan Hacıyev — 10+ illik enterprise təcrübəsi olan Senior Business Analyst.

<h2 id="fsil1zifbnd">Fəsil 1. “Zəif bənd”</h2>
<blockquote>
 “Niyə vasitəçi lazımdır? Mən özüm developerlərlə danışaram!” 
 “Yenə Texniki Tapşırıq (TT)? Sadəcə dediyim kimi edin!” 
</blockquote>
İlk böyük layihəmi yaxşı xatırlayıram. Bir tərəfdə əsəbi biznes müştərisi beşinci dəfə “sadəcə o düyməni əlavə edin!” deyə təkid edir, digər tərəfdə isə developer komandası səssizcə masaya zillənmişdi. Həmin an mən körpü yox, iki dünya arasında “süni baryer” idim. 
10–12 il əvvəl biznes analitiki (BA) belə görünürdü: biznes üçün — “xarab telefon”, developer üçün — “sənəd yazan adam”. Sistemdə xəta tapılanda isə günahkar da BA sayılırdı. 
Amma bu illər ərzində bu rol kvant sıçrayışı etdi: sadə sənədçidən məhsulun gələcəyinə təsir edən strateji tərəfdaşa çevrildi. 
 
<h2 id="fsil2juniordinlmsnti">Fəsil 2. Junior. Dinləmə sənəti</h2>
Bu mərhələ nədir? 
Şagirdlik səviyyəsi. Sənə konkret tapşırıqlar verilir: ekran formalarının təsvirini yazmaq, cədvəl tərtib etmək, Postman ilə “endpoint”ləri yoxlamaq. Heç kim səndən möhtəşəm ideyalar gözləmir, amma dəqiqlik və düzgün sual vermə bacarığı tələb olunur. 
Necə hiss olunur? 
Sən “istəklər dilindən” “kod dilinə” tərcümə edirsən, ancaq söz ehtiyatın bir stikerə sığacaq qədər azdır. Hələ də yadımdadır, yarım saat developera “overdraft”ın nə olduğunu izah etməyə çalışırdım. Sonda o dedi: “Aha, bu sadəcə limit daxilində mənfi balansdır”. 
Ən böyük qorxun — “lazımsız sual” verməkdir. Ən böyük kəşfin isə belə sualların əslində olmamasıdır. 
 - Tipik tələlər: tələbləri dəqiqləşdirmək əvəzinə fərz etmək; texniki terminləri bilməməkdən çəkinmək; prosesləri anlamaq əvəzinə alətlərə köklənmək. 
 - İnkişaf etdirməli bacarıqlar: aktiv dinləmə, Confluence/Jira/Figma ilə sərbəst işləmək, fundamental texniki biliklər (verilənlər bazası, API, veb-tətbiqlərin iş prinsipi). 
 - Böyümə əlaməti: artıq müsahibələri sərbəst apara, aydın tələblər formalaşdıra bilirsən və developerlər sənədlərini təkrar yoxlamağa ehtiyac duymur. 
<blockquote>
 Əsas dərs: diqqətlilik sənin super gücündür. 
</blockquote>
 
<h2 id="fsil3middlekrpquran">Fəsil 3. Middle. Körpü quran</h2>
Bu mərhələ nədir? 
Artıq BA sadəcə “yazan” deyil, sistemi bütöv şəkildə görməyə başlayır. Kiçik dəyişikliklərin böyük nəticələrə səbəb ola biləcəyini anlayır. 
Necə hiss olunur? 
İlk dəfə biznesə “yox” deyirsən, amma bu, əsaslandırılmış cavab olur: “yox, çünki…”. 
Məsələn, marketinq departamenti loyallıq proqramını kart məhsuluna inteqrasiya etmək istəyəndə bunu “sadəcə bir əlavə” adlandırmışdı. Mən isə böyük bir diaqram çəkib bu “sadə” funksionallığın prosessinq mərkəzinə, CRM-ə və hesabat sisteminə necə təsir etdiyini göstərdim. 
 - Tipik tələlər: “mən hər şeyi daha yaxşı bilirəm” sindromu; sənədləri həddən artıq detallı yazmaq; son istifadəçini nəzərdən qaçırmaq. 
 - İnkişaf etdirməli bacarıqlar: sistemli təfəkkür (korporativ arxitektura, inteqrasiyalar), kommunikasiya (moderasiya, münaqişələrin həlli, təqdimat), analitik metodlar (BPMN, Story Mapping). 
 - Böyümə əlaməti: başqa komandaların əməkdaşları məsləhət üçün sənə müraciət edir, sənin risk qiymətləndirmələrin reallıqda təsdiqlənir. 
<blockquote>
 Əsas dərs: “yazmaqdan” “izah etməyə və təsir göstərməyə” keçid. 
</blockquote>
 
<h2 id="fsil4seniorsisteminkeikisi">Fəsil 4. Senior. Sistemin keşikçisi</h2>
Bu mərhələ nədir? 
Artıq analitik bütün məhsul və ya domenə görə məsuliyyət daşıyır. Həm biznes hədəfləri, həm də sistemin texniki məhdudiyyətləri onun zehnindədir. 
Necə hiss olunur? 
Heç vaxt unutmaram: köhnə “Core Banking” sistemindən yenisinə məlumatların miqrasiyası öncəsi gecə. Səhər saat 4-ə qədər balansları yoxlayırdıq. Spesifikasiyadakı bircə səhv sahə minlərlə müştərinin səhv balans görməsi demək idi. 
O an anlayırsan: işin sadəcə Jira tapşırığı deyil, böyük bir məsuliyyətdir. Artıq “funksionallıq” yox, “etibarlılıq, risk və miqyaslanma” ilə düşünürsən. 
  - Tipik tələlər: əvəzolunmazlıq sindromu; mikromenecment; texniki detallarda itib biznes baxışını itirmək. 
  - İnkişaf etdirməli bacarıqlar: strateji planlaşdırma (roadmap, texniki borc, refaktorinq), risklərin idarə olunması, mentorluq. 
  - Böyümə əlaməti: sənin arxitektura qərarların digər komandalar üçün standart olur, C-level rəhbərlik strateji dəyişikliklərdə səninlə məsləhətləşir. 
<blockquote>
 Əsas dərs: sən artıq sadəcə ötürücü deyilsən — sistemin ortaq sahibisən. 
</blockquote>
 
<h2 id="fsil5beyondseniordyiikliklragenti">Fəsil 5. Beyond Senior. Dəyişikliklər agenti</h2>
Bu mərhələ nədir? 
BA komanda hüdudlarını aşaraq mədəniyyət və metodologiya daşıyıcısına çevrilir. O, yalnız məhsulu deyil, bütün təşkilatın işləmə tərzini təkmilləşdirir. 
Necə hiss olunur? 
Bankda Agile metodologiyasını tətbiq edəndə anladım: əsas işim mükəmməl “User Story” yazmaq yox, 80 komandanın istifadə edə biləcəyi vahid bir şablon yaratmaq idi. 
Sənin dəyərin artıq tapşırığı icra etmək deyil, başqalarının işini asanlaşdıran sistem qurmaqdır. 
  - Tipik tələlər: hər şeyi birdən dəyişmək istəyi; əməliyyat işlərindən tamamilə qopmaq; müqavimət səbəbindən tükənmək. 
  - İnkişaf etdirməli bacarıqlar: dəyişikliklərin idarə edilməsi (change management), təşkilati dizayn, ictimai çıxış bacarıqları. 
  - Böyümə əlaməti: sənin tətbiq etdiyin yanaşmalar layihələrdən daha uzunömürlü olur və bütün şirkətə yayılır. 
<blockquote>
 Əsas dərs: bu mərhələdə sən fikir liderinə və dəyişikliklərin təşəbbüskarına çevrilirsən. 
</blockquote>
 
<h2 id="fsil6memarstrateqglcybax">Fəsil 6. Memar / Strateq. Gələcəyə baxış</h2>
Bu mərhələ nədir? 
Ən yüksək səviyyə. BA artıq ekosistem miqyasında düşünür: biznes strategiyası, korporativ arxitektura, texnoloji trendlər. 
Necə hiss olunur? 
Artıq “kredit modulu necə işləyəcək?” sualını deyil, “3 ildən sonra bu modulun API-si dövlət fintex platforması ilə necə inteqrasiya olunacaq və bu, müştəri təcrübəsini necə dəyişəcək?” sualını düşünürsən. 
Sən evlər yox, şəhərlər qurursan. Süni intellekt rutin işləri avtomatlaşdırır, amma yalnız sən konteksti anlaya və etik qərarlar verə bilərsən. 
 - Əsas kompetensiyalar: gələcək vizionu, ekosistem təfəkkürü, səlahiyyətsiz təsir bacarığı. 
<blockquote>
 Əsas dərs: bu səviyyədə BA artıq tələbləri analiz etmir — o, gələcəyi formalaşdırır. 
</blockquote>
 
<h2 id="fsil7karyeraplatolarneciliibqalmamaq">Fəsil 7. Karyera platoları: necə ilişib qalmamaq?</h2>
  - Junior → Middle: məsuliyyətdən qorxmaq, alətlərə həddən artıq köklənmək, münaqişələrdən yayınmaq. 
  - Middle → Senior: komfort zonası, texniki mükəmməlliyə aludə olmaq, zəif mentorluq. 
  - Senior → Beyond: əvəzolunmazlıq sindromu, strateji vizyonun olmaması. 
Necə öhdəsindən gəlmək: dürüst özünüqiymətləndirmə, mentor tapmaq, iş kontekstini dəyişmək, əlavə bacarıqlar öyrənmək (UX, məhsul idarəçiliyi, arxitektura). 
 
<h2 id="nticdaimtkamlednbirrol">Nəticə: Daim təkamül edən bir rol</h2>
BA-nın təkamül yolu İT-nin özünü əks etdirir: 
“Sənədçi” → Məhsul tərəfdaşı → Dəyər memarı. 
  - Junior dinləməyi öyrədir. 
  - Middle — sistemi görməyi. 
  - Senior — məsuliyyəti daşımağı. 
  - Beyond — mədəniyyəti dəyişməyi. 
  - Memar — gələcəyi formalaşdırmağı. 
IIBA (International Institute of Business Analysis) da bu trayektoriyanı təsdiqləyir: BA çox vaxt Biznes Memarı, Məhsul Sahibi (Product Owner) və ya Korporativ Memar (Enterprise Architect) roluna keçir. 
Süni intellekt (AI) BA-nı əvəz etməyəcək, sadəcə sürətləndirəcək. 
Amma yalnız insan stakeholder-lərin motivlərini anlaya, etik qərarlar verə və ideyalarla kod arasında körpü qura bilər — gələcəyin üzərindən keçəcəyi körpünü. 
Müəllif: Sərxan Hacıyev — 10+ illik enterprise təcrübəsi olan Senior Business Analyst.

İT-analitikin yolu: “ən zəif bənd”dən dəyər memarına qədər

## Giriş
Discovery (kəşf) fazası hər bir rəqəmsal məhsulun uğur yolunda ilk və ən vacib addımdır. Bu mərhələ sadəcə ideyanın müzakirəsi deyil, həm də onun real bazarda necə işləyəcəyini, hansı problemi həll edəcəyini və hansı dəyəri yaradacağını anlamaq prosesidir. Təcrübə göstərir ki, Discovery-ni buraxan komandalar sonradan bahalı səhvlərlə, davamlı dəyişikliklərlə və itirilmiş resurslarla üzləşirlər.
 

## Niyə Discovery vacibdir?
Layihələr çox vaxt tələsik şəkildə başlanır: “Müştəri bunu istəyir, gəlin hazırlayaq!” Amma əsas suallar cavabsız qalanda nəticə ya bazarla uyğunlaşmayan məhsul, ya da bitib-tükənməyən dəyişikliklər silsiləsi olur. Discovery-nin məqsədi – gələcək məhsulun əsasını möhkəmləndirmək, riskləri azaltmaq və komandanı vahid vizion ətrafında toplamaqdır.
 

## 1. Biz hansı problemi həll edirik?
Hər şey problemdən başlayır. Bu sual sadə görünə bilər, amma əksər uğursuz layihələrdə cavab ya yoxdur, ya da qeyri-dəqiqdir. Məsələn, bank mobil tətbiqinə yeni funksiya əlavə etmək istəyir. Problem müştərinin ehtiyacıdır, yoxsa sadəcə rəqiblərdə var deyə biz də edirik? Əgər problemin kökü aydın deyilsə, bütün həll səhv istiqamətdə ola bilər.
 

## 2. Hədəf istifadəçi kimdir?
Məhsul hər kəs üçün deyil. Ona görə də, hədəf istifadəçini dəqiq müəyyənləşdirmək kritikdir. İstifadəçi personası yaratmaq – onların kim olduqlarını, gündəlik problemlərini, gözləntilərini təsvir etmək – komandanın qərarlarını yönləndirir. Məsələn, e-ticarət platformasında tələbə ilə orta yaşlı biznesmenin ehtiyacları tamamilə fərqlidir.
 

## 3. İstifadəçilərin ən böyük ağrısı nədir?
Sadəcə istifadəçini tanımaq kifayət deyil, onların real ağrı nöqtələrini başa düşmək lazımdır. İnsanlar məhsulları xüsusiyyətlərə görə deyil, problemlərini həll etdiyinə görə seçirlər. Məsələn, bir müştəri bank tətbiqindən yalnız pul köçürməsi etmək üçün istifadə edir, amma proses çox uzun çəkirsə — bu onun “ağrısıdır” və prioritet həll olunmalıdır.
 

## 4. Uğuru necə ölçəcəyik?
Hər məhsulun uğuru KPI-larla ölçülməlidir. Əks halda, nəticələri yalnız hisslərə əsasən qiymətləndirmək olar. KPI-lar aydın olduqda, komanda məqsədləri dəqiq görür. Məsələn:
- Satışların 20% artması
- Müştəri məmnuniyyətinin 15% yaxşılaşması
- Mobil tətbiqin yüklənmə sayının 2 dəfə artması
Bu metriklər olmadan, layihə uğurlu olub-olmadığını anlamaq mümkün deyil.
 

## 5. Əsas maraqlı tərəflər kimdir?
Məhsulun uğuru təkcə istifadəçidən asılı deyil. Menecerlər, sponsorlar, texniki komanda – hamısı maraqlı tərəflərdir və hərəsinin öz prioriteti var. Discovery-də bu gözləntiləri toplamaq və balanslaşdırmaq lazımdır. Əks halda, məhsul bir tərəfin istəklərinə uyğun hazırlanır, amma digər tərəflər narazı qalır.
 

## 6. Onların gözləntiləri nələrdir?
Maraqlı tərəflərin yalnız kim olduqlarını bilmək kifayət deyil, həm də onların gözləntilərini dəqiq öyrənmək vacibdir. Bir sponsor qısamüddətli ROI istəyirsə, amma istifadəçi uzunmüddətli sabitlik gözləyirsə, bu ziddiyyət erkən aşkar olunmalıdır. Discovery-də bu balansı qurmaq vacibdir.
 

## 7. Əsas risklər hansılardır?
Hər layihə qeyri-müəyyənliklərlə başlayır. Riskləri əvvəlcədən müəyyənləşdirmək – uğursuzluğun qarşısını almağın ən yaxşı yoludur. Məsələn:
- Texnologiya hələ sınaqdan keçməyib
- Rəqib eyni funksiyanı artıq elan edib
- Büdcə məhduddur
Risklərin xəritəsini yaratmaq və cavab planlarını hazırlamaq komandanı daha etibarlı edir.
 

## 8. İlkin ehtimallarımız nələrdir?
Discovery-də hipotezləri yazmaq mütləqdir. Məsələn, “İstifadəçilər bu funksiyanı ayda ən azı 1 dəfə istifadə edəcəklər”. Bu ehtimallar sonradan test edilərək ya təsdiqlənir, ya da inkar olunur. Beləliklə, komanda faktlara əsaslanır, fərziyyələrə yox.
 

## 9. Hansı alternativ həll yolları var?
Bir problemi həll etmək üçün həmişə bir neçə yol var. Discovery-də yalnız bir yanaşmaya fokuslanmaq risklidir. Məsələn, “mobil tətbiq hazırlamaq”la yanaşı, “mövcud veb-platformanı optimallaşdırmaq” da alternativ ola bilər. Alternativlərə baxmadan qərar vermək komandanı dar çərçivədə saxlayır.
 

## 10. Hansı resurs və məhdudiyyətlərlə işləyirik?
Layihənin uğuru yalnız ideyalardan asılı deyil. Büdcə, vaxt, texnologiya, komanda bacarıqları — bunların hamısı məhdudiyyətlərdir. Məsələn, startap yalnız 6 ay büdcəyə sahibdirsə, bu müddətdə MVP hazırlamaq prioritet olmalıdır. Resursları düzgün planlaşdırmaq – uğurlu icranın əsas şərtidir.
 

## Real praktikada necə olur?
Təcrübədə çox vaxt bu suallar ötürülür. Layihələr başlanır, amma komanda yalnız inkişaf mərhələsində problemləri kəşf edir. Nəticədə dəyişikliklər, əlavə xərclər və vaxt itkisi qaçılmaz olur. Məsələn, bir bank layihəsində Discovery olmadan sistem hazırlanmışdı, amma istifadəyə veriləndən sonra məlum oldu ki, müştərilərin 60%-i əsas funksiyanı başa düşmür. Bu, yenidən dizayn və böyük əlavə xərclərlə nəticələndi.
 

## Check-list: Discovery-də soruşulmalı 10 sual
- Biz hansı problemi həll edirik? 
- Hədəf istifadəçi kimdir? 
- İstifadəçilərin ən böyük ağrısı nədir? 
- Uğuru necə ölçəcəyik? 
- Əsas maraqlı tərəflər kimdir? 
- Onların gözləntiləri nələrdir? 
- Əsas risklər hansılardır? 
- İlkin ehtimallarımız nələrdir? 
- Hansı alternativ həll yolları var? 
- Hansı resurs və məhdudiyyətlərlə işləyirik? 
 

## Nəticə
Discovery mərhələsi layihənin taleyini müəyyənləşdirir. Bu mərhələdə düzgün sualları vermək – gələcəkdə minlərlə manat vəsaiti və aylarla vaxt itkisinin qarşısını almaq deməkdir.

Əgər siz də Discovery təcrübənizi paylaşmaq istəyirsinizsə, tətbiqdə şərh yazın. Hansı sualları daha vacib hesab edirsiniz? Bəyənmək və ya bəyənməmək düyməsini basaraq məqaləyə münasibətinizi bildirə bilərsiniz!

<h2 id="giri">Giriş</h2>
Discovery (kəşf) fazası hər bir rəqəmsal məhsulun uğur yolunda ilk və ən vacib addımdır. Bu mərhələ sadəcə ideyanın müzakirəsi deyil, həm də onun real bazarda necə işləyəcəyini, hansı problemi həll edəcəyini və hansı dəyəri yaradacağını anlamaq prosesidir. Təcrübə göstərir ki, Discovery-ni buraxan komandalar sonradan bahalı səhvlərlə, davamlı dəyişikliklərlə və itirilmiş resurslarla üzləşirlər.
 
<h2 id="niydiscoveryvacibdir">Niyə Discovery vacibdir?</h2>
Layihələr çox vaxt tələsik şəkildə başlanır: “Müştəri bunu istəyir, gəlin hazırlayaq!” Amma əsas suallar cavabsız qalanda nəticə ya bazarla uyğunlaşmayan məhsul, ya da bitib-tükənməyən dəyişikliklər silsiləsi olur. Discovery-nin məqsədi – gələcək məhsulun əsasını möhkəmləndirmək, riskləri azaltmaq və komandanı vahid vizion ətrafında toplamaqdır.
 
<h2 id="1bizhansproblemihlledirik">1. Biz hansı problemi həll edirik?</h2>
Hər şey problemdən başlayır. Bu sual sadə görünə bilər, amma əksər uğursuz layihələrdə cavab ya yoxdur, ya da qeyri-dəqiqdir. Məsələn, bank mobil tətbiqinə yeni funksiya əlavə etmək istəyir. Problem müştərinin ehtiyacıdır, yoxsa sadəcə rəqiblərdə var deyə biz də edirik? Əgər problemin kökü aydın deyilsə, bütün həll səhv istiqamətdə ola bilər.
 
<h2 id="2hdfistifadikimdir">2. Hədəf istifadəçi kimdir?</h2>
Məhsul hər kəs üçün deyil. Ona görə də, hədəf istifadəçini dəqiq müəyyənləşdirmək kritikdir. İstifadəçi personası yaratmaq – onların kim olduqlarını, gündəlik problemlərini, gözləntilərini təsvir etmək – komandanın qərarlarını yönləndirir. Məsələn, e-ticarət platformasında tələbə ilə orta yaşlı biznesmenin ehtiyacları tamamilə fərqlidir.
 
<h2 id="3stifadilrinnbykarsndir">3. İstifadəçilərin ən böyük ağrısı nədir?</h2>
Sadəcə istifadəçini tanımaq kifayət deyil, onların real ağrı nöqtələrini başa düşmək lazımdır. İnsanlar məhsulları xüsusiyyətlərə görə deyil, problemlərini həll etdiyinə görə seçirlər. Məsələn, bir müştəri bank tətbiqindən yalnız pul köçürməsi etmək üçün istifadə edir, amma proses çox uzun çəkirsə — bu onun “ağrısıdır” və prioritet həll olunmalıdır.
 
<h2 id="4uuruneclcyik">4. Uğuru necə ölçəcəyik?</h2>
Hər məhsulun uğuru KPI-larla ölçülməlidir. Əks halda, nəticələri yalnız hisslərə əsasən qiymətləndirmək olar. KPI-lar aydın olduqda, komanda məqsədləri dəqiq görür. Məsələn:
<ul>
<li>Satışların 20% artması</li>
<li>Müştəri məmnuniyyətinin 15% yaxşılaşması</li>
<li>Mobil tətbiqin yüklənmə sayının 2 dəfə artması
Bu metriklər olmadan, layihə uğurlu olub-olmadığını anlamaq mümkün deyil.
 </li>
</ul>
<h2 id="5sasmaraqltrflrkimdir">5. Əsas maraqlı tərəflər kimdir?</h2>
Məhsulun uğuru təkcə istifadəçidən asılı deyil. Menecerlər, sponsorlar, texniki komanda – hamısı maraqlı tərəflərdir və hərəsinin öz prioriteti var. Discovery-də bu gözləntiləri toplamaq və balanslaşdırmaq lazımdır. Əks halda, məhsul bir tərəfin istəklərinə uyğun hazırlanır, amma digər tərəflər narazı qalır.
 
<h2 id="6onlarngzlntilrinlrdir">6. Onların gözləntiləri nələrdir?</h2>
Maraqlı tərəflərin yalnız kim olduqlarını bilmək kifayət deyil, həm də onların gözləntilərini dəqiq öyrənmək vacibdir. Bir sponsor qısamüddətli ROI istəyirsə, amma istifadəçi uzunmüddətli sabitlik gözləyirsə, bu ziddiyyət erkən aşkar olunmalıdır. Discovery-də bu balansı qurmaq vacibdir.
 
<h2 id="7sasrisklrhanslardr">7. Əsas risklər hansılardır?</h2>
Hər layihə qeyri-müəyyənliklərlə başlayır. Riskləri əvvəlcədən müəyyənləşdirmək – uğursuzluğun qarşısını almağın ən yaxşı yoludur. Məsələn:
<ul>
<li>Texnologiya hələ sınaqdan keçməyib</li>
<li>Rəqib eyni funksiyanı artıq elan edib</li>
<li>Büdcə məhduddur
Risklərin xəritəsini yaratmaq və cavab planlarını hazırlamaq komandanı daha etibarlı edir.
 </li>
</ul>
<h2 id="8lkinehtimallarmznlrdir">8. İlkin ehtimallarımız nələrdir?</h2>
Discovery-də hipotezləri yazmaq mütləqdir. Məsələn, “İstifadəçilər bu funksiyanı ayda ən azı 1 dəfə istifadə edəcəklər”. Bu ehtimallar sonradan test edilərək ya təsdiqlənir, ya da inkar olunur. Beləliklə, komanda faktlara əsaslanır, fərziyyələrə yox.
 
<h2 id="9hansalternativhllyollarvar">9. Hansı alternativ həll yolları var?</h2>
Bir problemi həll etmək üçün həmişə bir neçə yol var. Discovery-də yalnız bir yanaşmaya fokuslanmaq risklidir. Məsələn, “mobil tətbiq hazırlamaq”la yanaşı, “mövcud veb-platformanı optimallaşdırmaq” da alternativ ola bilər. Alternativlərə baxmadan qərar vermək komandanı dar çərçivədə saxlayır.
 
<h2 id="10hansresursvmhdudiyytlrlilyirik">10. Hansı resurs və məhdudiyyətlərlə işləyirik?</h2>
Layihənin uğuru yalnız ideyalardan asılı deyil. Büdcə, vaxt, texnologiya, komanda bacarıqları — bunların hamısı məhdudiyyətlərdir. Məsələn, startap yalnız 6 ay büdcəyə sahibdirsə, bu müddətdə MVP hazırlamaq prioritet olmalıdır. Resursları düzgün planlaşdırmaq – uğurlu icranın əsas şərtidir.
 
<h2 id="realpraktikadanecolur">Real praktikada necə olur?</h2>
Təcrübədə çox vaxt bu suallar ötürülür. Layihələr başlanır, amma komanda yalnız inkişaf mərhələsində problemləri kəşf edir. Nəticədə dəyişikliklər, əlavə xərclər və vaxt itkisi qaçılmaz olur. Məsələn, bir bank layihəsində Discovery olmadan sistem hazırlanmışdı, amma istifadəyə veriləndən sonra məlum oldu ki, müştərilərin 60%-i əsas funksiyanı başa düşmür. Bu, yenidən dizayn və böyük əlavə xərclərlə nəticələndi.
 
<h2 id="checklistdiscoverydsoruulmal10sual">Check-list: Discovery-də soruşulmalı 10 sual</h2>
<ul>
<li>Biz hansı problemi həll edirik? </li>
<li>Hədəf istifadəçi kimdir? </li>
<li>İstifadəçilərin ən böyük ağrısı nədir? </li>
<li>Uğuru necə ölçəcəyik? </li>
<li>Əsas maraqlı tərəflər kimdir? </li>
<li>Onların gözləntiləri nələrdir? </li>
<li>Əsas risklər hansılardır? </li>
<li>İlkin ehtimallarımız nələrdir? </li>
<li>Hansı alternativ həll yolları var? </li>
<li>Hansı resurs və məhdudiyyətlərlə işləyirik? 
 </li>
</ul>
<h2 id="ntic">Nəticə</h2>
Discovery mərhələsi layihənin taleyini müəyyənləşdirir. Bu mərhələdə düzgün sualları vermək – gələcəkdə minlərlə manat vəsaiti və aylarla vaxt itkisinin qarşısını almaq deməkdir.
Əgər siz də Discovery təcrübənizi paylaşmaq istəyirsinizsə, tətbiqdə şərh yazın. Hansı sualları daha vacib hesab edirsiniz? Bəyənmək və ya bəyənməmək düyməsini basaraq məqaləyə münasibətinizi bildirə bilərsiniz!

"Discovery-faza: layihənizi xilas edəcək 10 əsas sual"

## Giriş: Mənim Agile-də “Evrika” anım
Bir vaxtlar *Agile* sözü bir növ sehr kimi səslənirdi. Hamı deyirdi: “Bu, sürətdir! Bu, çeviklikdir! Bu, gələcəkdir!” 

Bankdakı ilk demo layihələrdən birini xatırlayıram: hər şeyi “kitaba uyğun” etdik — lövhələr, mitinqlər, yeni rollar. Amma nəticədə biz mükəmməl qurulmuş proses yaratdıq… və heç kimə lazım olmayan məhsul. Biznes demonu nəzakətli təəccüblə izləyirdi, komanda isə mənasız ritualardan yorulmuşdu. 

Məhz o an başa düşdüm: Agile gözəl lövhələr və gündəlik görüşlər üçün deyil. Agile — bu, dəyərin fasiləsiz çatdırılmasıdır. 

 

## Rolun transformasiyası: “TT saxlayıcısı”ndan dəyər fasilitatoruna 
Agile biznes-analitikin işini kökündən dəyişdi. Klassik yanaşmada çatışmayan bir şeyi verdi — məhsula buradaca, indi təsir etmək imkanı. 

**Əvvəl (Waterfall):** 
- **Rol:** Biznes-analitik “biliklərin saxlayıcısı” idi. Tapşırığı — əhatəli Texniki Tapşırıq (TT) yazmaq, hamı ilə razılaşdırmaq və inkişafçılara ötürmək. 
- **Proses:** Aylarla analiz, qalın sənədlər və uzun-uzadı gözlənilən relizlər. 
- **Mənfi tərəf:** Tələblərdəki səhvlər çox gec aşkarlanırdı, düzəlişlər isə bahalı başa gəlirdi. Sənədlər tez-tez reallıqdan qopmuş arxivlərə çevrilirdi. 

**İndi (Agile yanaşması):** 
- **Rol:** Biznes-analitik strateji tərəfdaş olur. Vəzifəsi — sadəcə tələbləri sənədləşdirmək yox, komandanın diqqətini real istifadəçi problemlərinə və biznes dəyərinə yönəltməkdir. 
- **Proses:** Qısa iterasiyalar, sürətli hipoteza yoxlamaları və davamlı geribildirim. 
- **Üstünlük:** Sənədlər indi “canlıdır” (User Story, Acceptance Criteria, Story Map) və yalnız bir məqsədə xidmət edir — komandanın dəyəri tez çatdırmasına kömək etmək. 

 

## Mənim təcrübəm: Scrum və Kanban analitikin gözü ilə 
**Scrum komandasında İT-biznes analitik** kimi işləyəndə ilk dəfə hiss etdim ki, tələblər “bir dəfəlik” ötürülməməlidir. Onlar sprint-sprint müzakirə edilə, dəqiqləşdirilə və çevik şəkildə dəyişdirilə bilər. Bu, Waterfall-dan çox fərqli idi. 

Daha sonra, **Agile koçu kimi və indi Kanban komandasında işləyərkən**, başqa bir tərəfi gördüm: tapşırıqların axınını idarə etmək, tamamlanmamış işləri azaltmaq və dəyəri hərəkatda göstərmək, uzun dövrün sonunda yox. 

Mənim üçün Agile artıq sadəcə metod deyil. Bu, hər gün real dəyər yaratmaqdır. 

 

## Biznes-analitiklərin Agile-də düşdüyü tələlər 

İllər ərzində çoxlu komandaların “Agile etdiyini”, amma nəticə almadığını gördüm. Ən tipik tələlər bunlardır: 

### “Daily karqo-kultu” 
Daily — dünən nə etdiyini demək üçün deyil. Analitik üçün bu, komanda ilə sinxronlaşmaq, blokerləri aşkar etmək və detalları aydınlaşdırmaq fürsətidir. 
**Nə etməli:** “Dünən X etdim, bu gün Y edəcəyəm” əvəzinə belə suallar verin: “Sprintin məqsədinə doğru irəliləyirikmi? Mən kömək edə biləcəyim blokerlər varmı?” 

### “Mükəmməl lövhə, yararsız məhsul” 
Jira-nı ideal qurmaq olar, amma əgər backlog-da biznes məqsədi olmayan tapşırıqlar varsa, siz sürətlə… heç yerə gedəcəksiniz. 
**Nə etməli:** Hər böyük tapşırığı dörd sadə sualla yoxlayın: 
1. Nə yaradırıq? 
2. Kimin üçün yaradırıq? 
3. Hansı problemi həll edir? 
4. Uğuru necə ölçəcəyik? 

### “Proses naminə proses” 
“Biz Scrum-da işləyirik” və ya “Biz Kanban istifadə edirik” demək özü-özlüyündə heç nə ifadə etmir. Əsas odur ki, hər element həqiqətən dəyər yaratsın. 
**Nə etməli:** Retrospektiva real yaxşılaşmalara gətirməlidir. Planlaşdırma isə göstərməlidir ki, biz biznesə növbəti sprintdə nə verəcəyik. 

 

## Analitikin Agile alət dəsti: işləyən vasitələr 

Alətlər təkbaşına dəyər yaratmır. Dəyər yalnız komanda *niyə* və *necə* istifadə etdiyini anladıqda yaranır. 

Mənim sınanmış dəstim: 
- **User Story Mapping.** Məhsulu tam şəkildə göstərir, backlog detalları arasında itib-batmağa imkan vermir. 
- **Definition of Ready / Done.** Onlarla saat mübahisədən xilas edir. “Ready” — xam tapşırıqların işə düşməsinin qarşısını alır, “Done” — keyfiyyətli nəticəni təmin edir. 
- **Acceptance Criteria (məsələn, Gherkin formatında).** Abstrakt tələbləri hamıya — testçidən biznesə qədər — aydın ssenarilərə çevirir. 
- **Value Proposition Canvas.** İstifadəçini və onun problemlərini unutmamağa kömək edir. 

Analitikin vəzifəsi sadəcə “alət tətbiq etmək” deyil, katalizator olmaqdır: müxtəlif fikirləri vahid məhsul vizyonuna və dəqiq fəaliyyət planına çevirmək. 

 

## Nəticə: ritual yox, dəyər 
Biznes-analitik üçün Agile — stikerlər və mitinqlər deyil. Bu, düşüncə tərzinin dəyişməsidir: “Mən tələbləri yazıram”dan “Mən komandaya dəyər yaratmağa kömək edirəm”ə. 

Mən özüm bu yolu keçdim: qalın TT-lərdən və uzun razılaşdırmalardan — Scrum iterasiyalarına və Kanban axınına, harada dəyəri sabah görmək olar. Bu, tamamilə başqa hissdir. Məhsulun canlandığını, istifadəçilərin fayda gördüyünü, biznesin nəticə aldığını görəndə başa düşürsən ki, işin doğrudan da mənalıdır. 

Bunu özünüz sınamaq istəyirsinizsə, saytımın [Resurslar](https://sarkhan.dev/#resources) bölməsinə baxın — mən orada hər gün istifadə etdiyim şablonları toplamışam.

large_45677.jpg

medium_45677.jpg

small_45677.jpg

thumbnail_45677.jpg

45677.jpg

<h2 id="girimnimagiledevrikaanm">Giriş: Mənim Agile-də “Evrika” anım</h2>
Bir vaxtlar Agile sözü bir növ sehr kimi səslənirdi. Hamı deyirdi: “Bu, sürətdir! Bu, çeviklikdir! Bu, gələcəkdir!” 
Bankdakı ilk demo layihələrdən birini xatırlayıram: hər şeyi “kitaba uyğun” etdik — lövhələr, mitinqlər, yeni rollar. Amma nəticədə biz mükəmməl qurulmuş proses yaratdıq… və heç kimə lazım olmayan məhsul. Biznes demonu nəzakətli təəccüblə izləyirdi, komanda isə mənasız ritualardan yorulmuşdu. 
Məhz o an başa düşdüm: Agile gözəl lövhələr və gündəlik görüşlər üçün deyil. Agile — bu, dəyərin fasiləsiz çatdırılmasıdır. 
 
<h2 id="roluntransformasiyasttsaxlaycsndandyrfasilitatoruna">Rolun transformasiyası: “TT saxlayıcısı”ndan dəyər fasilitatoruna</h2>
Agile biznes-analitikin işini kökündən dəyişdi. Klassik yanaşmada çatışmayan bir şeyi verdi — məhsula buradaca, indi təsir etmək imkanı. 
Əvvəl (Waterfall): 
<ul>
<li>Rol: Biznes-analitik “biliklərin saxlayıcısı” idi. Tapşırığı — əhatəli Texniki Tapşırıq (TT) yazmaq, hamı ilə razılaşdırmaq və inkişafçılara ötürmək. </li>
<li>Proses: Aylarla analiz, qalın sənədlər və uzun-uzadı gözlənilən relizlər. </li>
<li>Mənfi tərəf: Tələblərdəki səhvlər çox gec aşkarlanırdı, düzəlişlər isə bahalı başa gəlirdi. Sənədlər tez-tez reallıqdan qopmuş arxivlərə çevrilirdi. </li>
</ul>
İndi (Agile yanaşması): 
<ul>
<li>Rol: Biznes-analitik strateji tərəfdaş olur. Vəzifəsi — sadəcə tələbləri sənədləşdirmək yox, komandanın diqqətini real istifadəçi problemlərinə və biznes dəyərinə yönəltməkdir. </li>
<li>Proses: Qısa iterasiyalar, sürətli hipoteza yoxlamaları və davamlı geribildirim. </li>
<li>Üstünlük: Sənədlər indi “canlıdır” (User Story, Acceptance Criteria, Story Map) və yalnız bir məqsədə xidmət edir — komandanın dəyəri tez çatdırmasına kömək etmək. </li>
</ul>
 
<h2 id="mnimtcrbmscrumvkanbananalitikingzil">Mənim təcrübəm: Scrum və Kanban analitikin gözü ilə</h2>
Scrum komandasında İT-biznes analitik kimi işləyəndə ilk dəfə hiss etdim ki, tələblər “bir dəfəlik” ötürülməməlidir. Onlar sprint-sprint müzakirə edilə, dəqiqləşdirilə və çevik şəkildə dəyişdirilə bilər. Bu, Waterfall-dan çox fərqli idi. 
Daha sonra, Agile koçu kimi və indi Kanban komandasında işləyərkən, başqa bir tərəfi gördüm: tapşırıqların axınını idarə etmək, tamamlanmamış işləri azaltmaq və dəyəri hərəkatda göstərmək, uzun dövrün sonunda yox. 
Mənim üçün Agile artıq sadəcə metod deyil. Bu, hər gün real dəyər yaratmaqdır. 
 
<h2 id="biznesanalitiklrinagiledddytllr">Biznes-analitiklərin Agile-də düşdüyü tələlər</h2>
İllər ərzində çoxlu komandaların “Agile etdiyini”, amma nəticə almadığını gördüm. Ən tipik tələlər bunlardır: 
<h3 id="dailykarqokultu">“Daily karqo-kultu”</h3>
Daily — dünən nə etdiyini demək üçün deyil. Analitik üçün bu, komanda ilə sinxronlaşmaq, blokerləri aşkar etmək və detalları aydınlaşdırmaq fürsətidir. 
Nə etməli: “Dünən X etdim, bu gün Y edəcəyəm” əvəzinə belə suallar verin: “Sprintin məqsədinə doğru irəliləyirikmi? Mən kömək edə biləcəyim blokerlər varmı?” 
<h3 id="mkmmllvhyararszmhsul">“Mükəmməl lövhə, yararsız məhsul”</h3>
Jira-nı ideal qurmaq olar, amma əgər backlog-da biznes məqsədi olmayan tapşırıqlar varsa, siz sürətlə… heç yerə gedəcəksiniz. 
Nə etməli: Hər böyük tapşırığı dörd sadə sualla yoxlayın: 
<ol>
<li>Nə yaradırıq? </li>
<li>Kimin üçün yaradırıq? </li>
<li>Hansı problemi həll edir? </li>
<li>Uğuru necə ölçəcəyik? </li>
</ol>
<h3 id="prosesnaminproses">“Proses naminə proses”</h3>
“Biz Scrum-da işləyirik” və ya “Biz Kanban istifadə edirik” demək özü-özlüyündə heç nə ifadə etmir. Əsas odur ki, hər element həqiqətən dəyər yaratsın. 
Nə etməli: Retrospektiva real yaxşılaşmalara gətirməlidir. Planlaşdırma isə göstərməlidir ki, biz biznesə növbəti sprintdə nə verəcəyik. 
 
<h2 id="analitikinagilealtdstiilynvasitlr">Analitikin Agile alət dəsti: işləyən vasitələr</h2>
Alətlər təkbaşına dəyər yaratmır. Dəyər yalnız komanda niyə və necə istifadə etdiyini anladıqda yaranır. 
Mənim sınanmış dəstim: 
<ul>
<li>User Story Mapping. Məhsulu tam şəkildə göstərir, backlog detalları arasında itib-batmağa imkan vermir. </li>
<li>Definition of Ready / Done. Onlarla saat mübahisədən xilas edir. “Ready” — xam tapşırıqların işə düşməsinin qarşısını alır, “Done” — keyfiyyətli nəticəni təmin edir. </li>
<li>Acceptance Criteria (məsələn, Gherkin formatında). Abstrakt tələbləri hamıya — testçidən biznesə qədər — aydın ssenarilərə çevirir. </li>
<li>Value Proposition Canvas. İstifadəçini və onun problemlərini unutmamağa kömək edir. </li>
</ul>
Analitikin vəzifəsi sadəcə “alət tətbiq etmək” deyil, katalizator olmaqdır: müxtəlif fikirləri vahid məhsul vizyonuna və dəqiq fəaliyyət planına çevirmək. 
 
<h2 id="nticritualyoxdyr">Nəticə: ritual yox, dəyər</h2>
Biznes-analitik üçün Agile — stikerlər və mitinqlər deyil. Bu, düşüncə tərzinin dəyişməsidir: “Mən tələbləri yazıram”dan “Mən komandaya dəyər yaratmağa kömək edirəm”ə. 
Mən özüm bu yolu keçdim: qalın TT-lərdən və uzun razılaşdırmalardan — Scrum iterasiyalarına və Kanban axınına, harada dəyəri sabah görmək olar. Bu, tamamilə başqa hissdir. Məhsulun canlandığını, istifadəçilərin fayda gördüyünü, biznesin nəticə aldığını görəndə başa düşürsən ki, işin doğrudan da mənalıdır. 
Bunu özünüz sınamaq istəyirsinizsə, saytımın <a href="https://sarkhan.dev/#resources">Resurslar</a> bölməsinə baxın — mən orada hər gün istifadə etdiyim şablonları toplamışam.

Blog

Stakeholder xəritəsi: müxtəlif maraqları necə uzlaşdırmalı?

İT-biznes analitik 2025: Süni İntellekt dövründə yeni bacarıqlar

İT-analitikin yolu: “ən zəif bənd”dən dəyər memarına qədər

"Discovery-faza: layihənizi xilas edəcək 10 əsas sual"

Agile biznes-analitikin gözü ilə: Dəyər yaratmaq, sadəcə rituala əməl etmək yox

ITBAI Assistant