Menyu

Arxitektor vs özünütəşkil qrupları (Self-Organizing Teams)

Əksər hallarda, proqramçılar gələcək planlarını qurarkən müəyyən zaman müddətindən sonra kod yazmayacaqlarını düşünürlər.  Karyeralararını ya komanda başçısı (team lead), ya İT menecer, ya arxitektor, ya da ümumyətlə biznesmen kimi davam edəcəklərini xəyal edirlər. Doğrudur, məşhur “keçmiş XXO(Xüsusi Xidmət Orqanı) işçisi olmur” deyimini məncə proqramçılara da aid etmək olar. Proqramçı hansı vəzifədə çalışmağından asılı olmayaraq həmişə proqramçı qalır, özü kod yazmasa belə işlətdiyi proqramın işləmə prinsipini araşdırır, sanki həmin proqramı özü yaza bilərmi sualını verir və yaza biləcəyini anladıqda sanki rahatlaşır.smiley  Lakin, bu toxunacağım mövzudan bir az uzaqdır . Yuxarıda sadalanan (xəyal edilən) vəzifələrdən ən cəlbedicisi arxiteoktor sayıla bilər. Vəzifə borcunun nə olduğunu tam bilmədən belə etiraf edək ki, cəlbedicidir. İlk baxışdan düşünmək olar ki, bütün proqramlaşdırma dillərində yaza bilən, bütün əməliyyat sistemlərini, şəbəkə, platforma və bulud (cloud) texnologiyalarını da gözüyumulu idarə etməyi bacaran universal insandır. Gəlin indi arxitektorun həqiqətdə kim olduğunu dəqiqləşdirək. Öncə, kim arxitektor deyil sualına cavab verək?


•    Arxitektor yanğınsöndürən deyil. Yəni, hər hansı layihədə, əməliyyatlarda problem yaranarsa arxitektor özünü hadisə yerinə dərhal çatdıran yanğınsöndürən deyil (Əslində olmalı deyil. İstisnalar hər zaman ola bilir)
•    Arxitektor kod yazmamalıdır. Yəni, proqramçı vəzifəsini daşımamalıdır
•    Arxitektor proqramçıların mentor-u deyil.


Bəs onda arxitektor kimdir? Arxitektor hansı biliklərə və özəlliklərə malikdir?


•    Kompüter Elmləri (Computer scince) 
•    Şəbəkə və platforma bilikləri
•    Kommunikasiya bacarığı
•    Sənədləşdirmə bacarığı 
•    Menecment


Təbii ki, siyahı bununla bitmir. Arxitektorun əsas vəzifəsi, maraqlı tərəflərlə (stakeholder) görüşüb onlardan istədiklərini toplamaq, prioritetləşdirmək və yazılacaq(və ya dəyişiklik olunacaq) sistemin planını hazırlayıb sənədləşdirməkdir (Maraqlı tərəf deyərkən investorlar, işçilər, müştərilər və təchizatçılar nəzərdə tutulur). Bəlkə də sadə görünə bilər, amma maraqlı tərəflərin istəkləri bir biri ilə  konflikt təşkil edə bilər. Demək arxitektor bütün maraqlı tərəfləri razı sala biləcək həll tapmalıdır. Kiçik bir misalla nəzər yetirək. Bank sistemi üçün “İnternet Banking” alt-sistemi yaradılmalıdır. Burada maraqlı tərəflər aşağıdakılardır:


•    Biznes – ən əsas oyunçu qrupudur. Yazılacaq proqram üçün konkret şərtlər qoyur və istənilən funksuinallıq bu plandan qırağa çıxa bilməz.(Misal üçün : abonentlərin sayı 10 mini keçməli, Sistemə daxil olanlar bütün bank əməliyyatlarını bir proqram daxilində yerinə yetirməli və s)
•    İnfoSec – Bankın təhlükəsizliyinə cavabdeh qrupdur, sözsüz ki, onların da istəkləri yuxarı prioritetlidir. Məsələn: Proqrama giriş 2-faktorlu identifikasiya (two-factor authentification) ilə olmalıdır
•    Müştəri xidmətləri - Problem yaşanacağı təqdirdə daha çox müracət gələcəyinə görə, onlar da maraqlı tərəf sayılır
•    Kredit, deposit, reklam və s. departamentlər də sözsüz maraqlı tərəflərdi
•    Texniki heyət (proqramçılar, testerlər, keyfiyyətə nəzarət(QA) və s.) – arxitekturanın hazırlanması prosesində iştirakçıdırlar.  


Arxitektorun işi bütün maraqlı tərəflərin istəklərini biznesin qoyduğu hədəflərə uyğun planlamaqdır.  Yaranan konfliktlərdə isə, uyğun güzəştlərə (trade off) getmək, və bu güzəştləri hamı ilə razılaşdırmaqdır. Misal üçün, əgər İnfoSec təhlükəsizlik səbəbindən 2-faktorlu identifikasiya və eyni zamanda müştəri xidmətləri sistemə sürətli giriş istəyirsə, arxitektor onların hər ikisinin eyni zamanda yerinə yetirilməsinin mümkünsüz olduğunu izah etməli və tərəfləri ortaq məxrəcə gətirməlidir.

Göründüyü kimi arxitektor kifayət qədər təcrübəli, çevik qərarlar verə bilən, həm də hamı ilə dil tapa bilən biri olmalıdır. İri şirkətlər özlərində arxitektorlar qrupu saxlayır, bir arxitektorun hazırladığı sənədi digər arxitektorlar da nəzərdən keçirir və beyin fırtınası aparırlar. Sözsüz ki, bu yaxşı səslənir. Amma şirkətlərdə  arxitektor ştatlarının olması aşağıdakı çətinlikləri yarada bilər.


1.    Hər hansı bir layihəyə arxitektura sənəd hazırlanandan sonra arxitektorun boş qala bilmə ehtimalı yüksəkdir. Bu səbəbdən, bir neçə layihəyə bir arxitektor təyin etmək praktikası da var. Amma bu yanaşmanın da mənfi tərəfi odur ki, həm arxitektorun fokusu dağınıq olur, həm də eyni anda bir neçə məşğul olduğu layihədə dəyişiklik tələb olunarsa, hansısa biri digərini gözləyəsi olacaq.
2.    Bürokratik əngəllər yarada bilir. Hər hansı məsələdə çevik qərar verilməli halda, arxitektorun sənədə dəyişiklik edib, son versiyanı hazırlamasını gözləmək lazım gəlir.
3.    Çox bahalı resursdur. Bir arxitektora bağlanmaq risklidir, bir neçəsini saxlamaq isə çox məsrəfli ola bilir.
 

Yuxarıda sadalanan mənfi təsirlər böyük banklar üçün bəlkə də problem yaratmaz, amma İT kompaniyalar, startup-lar üçün başağrısı yarada bilər. Müasir dövrün tələblərində Agile metodologiyası (bax: www.kibrit.tech/blog/agile-methodology) ilə proseslərə yanaşmağa daha üstünlük verilir. Bu metodologiyanın tələbləri sırasında həm də özünütəşkil qrupları (Self-organizing teams) da vardır. 

 

self-organizing-teams-agile

 

•    Bu qruplarda rəhbər olmur, hər bir üzv bərabər haqqlara malikdir. 
•    Qərarlar qrup daxilidə müzakirələr, beyin fırtınaları nəticəsində verilir
•    Qrupun üzvləri çoxfunsional olur – proqram arxiterturası hazırlayır, proqramlaşdırır, prodakşna çıxarır, test və monitor edir.


Özünütəşkil qruplara keçid ağır olsa da, keçid baş tutandan sonra çox yaxşı nəticələr əldə etmək olur. Bürokratik əngəllər olmur, komandanın fokusu bir yerdə olur, proqramçılar özlərini icraçı yox, qərar verən kimi hiss edirlər və bu hiss onlara əlavə motivasiya verir. Keçid 3 addımda həyata keçirilə bilər.

•    Təlim (Training) – Özünütəşkil qrupuna çevrilmək üçün öncə hər bir üzv fərdi olaraq müvafiq təlimlərdən keçməlidir. Bu təlimlər həm layihənin icrası üçün lazım olan texniki, həm də davranış və ünsiyyət üzrə olmalıdır.
•    Məşqçilik (Coaching) – Fərdi təlimlərdən sonra birgə məşqə başlamaq lazımdır. Bu addımda artıq komanda formalaşacaqdır. Əsas məsələ bütün komandanın bir dalğada olmasıdır və komanda tam bir orqanizm kimi fəaliyyət göstərməsidir.
•    Mentorluq (Mentoring) – Qrup formalaşdıqdan sonra isə daima mentorluq edilməlidir. “Scrum master” bu işi yerinə yetirir. Bu, o anlama gəlmir ki komandaya daim nəzarət edilir. Komanda nə qədər də özünütəşkil olsa da, daimi mentorluq və məşqçiliyə ehtiyac var.

Qruplar adətən 5-9 nəfərdən ibarət olur (Amazon-un qurucusu Jeff Bezos demiş: şirkətiniz nə qədər genişlənsə də, komandalar iki pizzanın doyuzdura biləcəyindən böyük olmamalıdır). Qruplar böyüdükcə kiçik qruplara bölünür. Məsuliyyət və öhdəliklər də uyğun olaraq qruplar arasında paylanır.

P.S. Sual yarana bilər ki, bütün qruplar özünütəşkil olacaqsa, şirkətlərdə arxitektorlar olmalı deyil? “Yaxşı arxitektura olmur, sizin tələblərə uyğun arxitektura olur” – deyimi bu halda da keçərli sayıla bilər. Yəni, hər şirkət qruplardan kənarda arxitektor saxlamaq qərarını özü verir. Sözsüz ki, hibrid quruluşlar da istisna deyil.
 

İstinadlar : 

www.gaiku.io/blog/self-organizing-team
www.visual-paradigm.com/what-is-self-organizing-team-in-scrum/