Dəyişməyə açıqlıq

Çevik olmaq üçün necə - bir agentlik bələdçisi

Çevik müştəri layihələri üçün ideal şərait yaradın

Bu məqalə Alman dilində də mövcuddur.

Son illərdə "Çevik" agentlik səhnəsində getdikcə populyar bir ibarəyə çevrildi. Çevik bir şəkildə işləmək öhdəliyi götürməyən bir şirkət çətin ki var. Bəs əslində bu nə deməkdir? Bir şirkətin həqiqətən necə çevik olduğunu necə deyə bilərsən? Bir qaçışda işləyirsinizsə, onsuz da çeviksiniz? (Cavab: yox.)

Aperto Move-da son iki il yarımda iş yerlərimizdəki çeviklik vizyonumuzu inkişaf etdirmək üçün iş metodlarımızı daima təhlil və təkmilləşdirdik. Ən təkzibolunmaz reallaşdırmalardan biri çevikliyə keçməyin həm vaxt, həm də təcrübə alması idi. Yalnız çevikliyə keçə bilməzsən. Hələ istədiyimiz yerdə deyilik, amma inkişaflar açıq şəkildə nəzərə çarpır.

Bir agentlikdə çevik metodların tətbiqi ümumiyyətlə, məsələn, məhsul istehsalından daha çətindir; çünki şərtlər layihələr arasında kəskin şəkildə dəyişə biləcəyi fərqli müştərilər üçün məhsullar yaradırsınız. Buna görə hər agentliyin birdən çevik göründüyünə inanmaq çətindir. Xoşbəxtlikdən, bir şirkətin çeviklik yolunda nə qədər olduğunu müəyyənləşdirməyi asanlaşdıran amillər var.

Bu yazıda təqdim olunan tövsiyələr gündəlik işimizdə ortaya çıxan və onları problem kimi təyin edən kimi həll edilən əksər qurumlar üçün ümumi ssenarilərə əsaslanır. Bunlar dərman deyil, bizim üçün ən uyğun olan kəşflər toplusudur.

1. Terminologiyanı dəqiqləşdirin

Agile-ni qəbul edərkən şirkətdəki hər kəsin bu termini eyni şəkildə başa düşməsi vacibdir. Əks təqdirdə təhlükəli yanlış əlaqə riski var. Çevik yanaşmanı bütün konsepsiya mərhələləri olmadan, planlaşdırma və müntəzəm görüşlər olmadan həyata keçirmək kimi bir layihəyə dərhal atılmaq və nə baş verdiyini görmək üçün səhv başa düşmüş insanlara rast gəldim. Belə bir layihənin asan bir şey olduğunu təsəvvür etmək çətin deyil.

Digərləri sadəcə "Scrum" haqqında eşitmişlər və istifadə etməkdən bir qədər çəkinirlər. Bunu yaradıcılıq prosesinə mane olan "inkişaf etdiricilər üçün bir şey" kimi qiymətləndirdilər. Bu ifadələrin əksəriyyəti Scrum və ya çevik metodlarla tanış olan insanlardan gəlir. Bundan əlavə, onunla tanış olmayanlar tez-tez Agile ilə Scrum arasındakı fərqi deyə bilmirlər və eyni və eyni kimi təsnif edirlər.

Scrum və Çevik eyni deyil

Scrum, proqramın inkişafı üçün müəyyən qaydaları, rolları və iş proseslərini təyin edən bir çərçivədir. Bir nümunə, bir iş məhsulunun çatdırıldığı zaman aralıklarının tərifidir (sözdə sprint). Scrum-un tətbiqi çevik proqram inkişafına kömək edir, bu səbəbdən terminlər çox vaxt eyni mənada qəbul edilir, lakin alınmır.

Digər tərəfdən “çevik”, Scrum'un etdiklərindən daha çoxunu özündə cəmləşdirən bir düşüncə və ya mədəniyyət tərzidir. Çevik mədəniyyətini müəyyənləşdirən prinsiplər Çevik Manifestində verilmişdir və aşağıdakı videoda göstərilir:

Scrum, çevik prinsiplərə riayət etmək üçün mümkün olan bir yanaşmadır. Scrum olmadan da çevik ola bilərsiniz. Scrum qaydalarına sadiq qalmağınız əslində çevik işlədiyiniz anlamına gəlmir.

2. Layihə meneceri rolu ilə sağollaşın (çevik rollara salam deyin)

Scrum-da aşağıdakı rollar müəyyən edilmişdir:

  • Məhsul sahibi
  • Scrum Master
  • İnkişaf qrupu
  • Kimi digər maraqlı tərəflər B. son istifadəçi və ya müştəri tərəfində olanlar

Başqa rollar yoxdur və lazım deyil. Klassik layihə meneceri artıq bu quraşdırma üçün tələb olunmur. Layihə meneceri tərəfindən əvvəllər həyata keçirilmiş bütün tapşırıqlar indi yuxarıda sadalanan vəzifələrlə əhatə olunduğundan yalnız prosesə mane olacaqdır. Layihənin uğurlu olmasına görə məsuliyyət artıq bir nəfərin deyil, bütün komandanın üzərinə düşür.

Layihədə mövcud olan və Scrum komandası ilə müştəri arasında mövcud olan hər hansı əlavə rol, komanda ilə müştəri arasında birbaşa və effektiv ünsiyyət üçün bir maneədir.

Rollara və məsuliyyətlərə ciddi yanaşın

Bir layihə menecerinə ehtiyacınız yoxdursa, əvvəlki layihə menecerlərini Scrum Master və Product sahibi kimi birləşmiş rolda işə salmağın mənası yoxdur.

Yox. Bir tərəfdən, həm Scrum Master və həm də Məhsul Sahibi rolları hər iki vəzifəni yerinə yetirmək üçün kifayət qədər tapşırıq ehtiva edir, beləliklə rollardan biri laqeyd qalır. Nəticədə, iki rolun ziddiyyətli maraqları var. Məhsul Sahibi bütün maraqlı tərəflərlə daim əlaqə saxlayır və doğru məhsulun ən keyfiyyətli şəkildə çatdırılmasını təmin edir. Digər şeylər arasında, Scrum Master, komandanın həddindən artıq yüklənməməsinə və ya kəsilməməsinə əmin olmalıdır. Scrum Master-ın məhsulun özü ilə heç bir əlaqəsi yoxdur.

Scrum Master-ı tamamilə tərk etmək daha pis olardı. Vəzifədə olan Scrum Master olmadan komandanın məhsuldar işləməsini, son tarixlərə riayət etməsini və ya sonradan öyrənməsini və daha səmərəli olmasını təmin edən heç bir rol yoxdur. Bir sözlə, layihənin çevik şəkildə həyata keçirilməsini təmin edən onlardır. Təcrübəmizə görə, bu, dəyişən müştəriləri, maraqlı tərəfləri və şərtləri olan bir agentlik mühitində xüsusilə vacib bir rol oynayır, çünki Scrum Master müştəri üçün məşqçi rolunu da alır.

Bu məqalə, asanlıqla başa düşülən bir trafik bənzərliyindən istifadə edərək Scrum Master və klassik layihə menecerinin müxtəlif funksiyalarını izah edir:

3. Artıq resurs planlaşdırması yoxdur (bunun əvəzinə çəkmə prinsipini müəyyənləşdirin)

Agentliklər tez-tez eyni vaxtda müxtəlif müştərilər üçün bir neçə layihə üzərində işləyirlər ki, bu da bütün işçilər arasında səmərəli iş paylanmasını çətinləşdirir.

Klassik agentlik yanaşması resurs planlaşdırmasıdır: Layihə meneceri bir neçə gün və ya həftə əvvəlcədən planlar hazırlayır və işçiləri layihələrə və ya tapşırıqlara tapşırır. Bu, planlaşdırma və koordinasiya üçün çox vaxt aparır və bütün proqnozların və planların ayrılan vaxtda yerinə yetirildiyini düşündüyü üçün əyilməzliyə səbəb olur.

Təcrübə bizə bu cür planların əslində heç vaxt reallaşmadığını öyrədir: vacib bir çatdırılma təxirə salınır, işçilər xəstələnir və ya digər gözlənilməz hallar meydana gəlir ki, bu da fərdi tapşırıqların gözləniləndən daha uzun çəkməsi deməkdir. Nəticələr həmkarlar arasında qeyri-bərabər iş bölgüsü, daha çox stres və iş vaxtından çoxdur.

Bu deyilən “təkan prinsipi” (fərdi tapşırıqlar işçilər üçün “təxirə salındığı üçün”) bu səbəbdən ideal deyil. Çevik bürcdə bir layihə rəhbəri olmadan iş necə paylanır? Bu problem fərqli bir yanaşma tələb edir:

Dartma prinsipi

Çevik işləmə “çəkmə” zehniyyətinə əsaslanır. Bu, işçilərin hansı tapşırıqları üzərinə götürəcəklərini proaktiv şəkildə qərar verdikləri deməkdir. Bunun işləməsi üçün qarşıda duran vəzifələr və onların tərəqqisi şəffaf şəkildə çatdırılmalıdır.

İdeal olaraq, bu yalnız layihə səviyyəsində deyil, şirkətdəki bütün qarşıda duran vəzifələr üçün də baş verir. Bura əhatə dairəsini qiymətləndirmək, təqdimatlar etmək, seminarlar hazırlamaq, müsahibələrə getmək və ya hətta bu məqaləni yazmaq daxildir. Buna Kanban kartı ilə nail olmaq olar, məsələn:

Dartma prinsipi, hər kəsin vəzifələri üzərində işləyə bildikdə müstəqil qərar vermək azadlığına sahib olduğu işçilər arasında bərabər bir iş bölgüsünü təmin etməyə kömək edir. Bu, müəyyən işçiləri həddindən artıq yükləmə ehtimalını aradan qaldırmağa kömək edir.

Çekmə prinsipinin işləməsi üçün aşağıdakı şərtlər yerinə yetirilməlidir:

  • Daimi ünsiyyət çox vacibdir. Aperto Move-da layihənin vəziyyəti həftədə üç dəfə lövhədə müzakirə olunur
  • Başqalarının nə edəcəyini söyləməsini gözləmək əvəzinə təşəbbüs göstərmə qabiliyyəti olan insanlardan tələb olunur
  • Düz hiyerarşilere üstünlük verir və bunları həyata keçirmək istəyi tələb edir
  • Daha çox məsuliyyət götürə bilmək üçün şirkət rəhbərliyi işçilərinə güvənməlidir
  • Fərdi tapşırıqlar və layihələr arasında dəqiq bir fərq qoyulmalıdır. Layihələri tək bir şəxs deyil, bir komanda çəkir. Bu, aşağıdakı hissədə daha ətraflı izah olunur.

4. Sabit komandalar qurun

Agentliklərdə fərqli müştərilər üçün eyni zamanda işləmək tipikdir və təcili tapşırıqlar (sahə yoxlamaları, sahələr və ya səhv düzəlişləri kimi) tez-tez qısa müddətdə ortaya çıxır. Buna görə layihə qrupları tez-tez mövcud mövcudluğa görə bir araya gəlir. Bu növ resurs planlaşdırması çevik layihələrin qarşısını səmərəli şəkildə alır.

Çevik komandalar sabit olmalı və ideal şəkildə özlərini tapmalıdırlar. Yalnız yaxın komandalar bir-birindən öyrənərək, proseslərini və ünsiyyətlərini əlaqələndirərək, geriyə dönük təhlil yolu ilə problemləri müəyyənləşdirərək həll edərək optimal şəkildə inkişaf edə və sürətlərini qoruya, hətta sürətlənə bilər.

Komandalar problemləri müntəzəm araşdırmalar yolu ilə müəyyənləşdirə və həll edə bilərlər (şəkil Andreas Plath)

Birlikdə yaxşı işləyən təsirli həmkarlar qruplarının narahat olmasının qarşısını almaq üçün bütün öyrənmə və gündəlik təsirlərin aradan qaldırılması üçün yaxın gələcək layihələr fərdlər üçün deyil, sabit qruplar üçün planlaşdırılmalıdır.

Bununla birlikdə, bütün fənlər ilə bütöv bir agentliyin sabit və balanslı komandalara çevrilməsinin bir gecədə baş verə biləcəyinə inanmaq real deyil. Hər kəsin hər zaman eyni komandada çalışmaq istəməməsi düşünülür. Beləliklə, hər kəs üçün yaxşı bir tarazlıq tapmaq vacibdir.

5. Çevik təkliflər yaradın

Müştəri ilə agentlik arasında klassik, sadələşdirilmiş təklif mərhələsi ümumiyyətlə aşağıdakı formada olur: Müştərinin məhsul üçün müəyyən bir fikri və nə vaxt başa çatmalı olduğu üçün bir cədvəli var.

Müştəri daha sonra agentliyi tələblər barədə məlumatlandırır (ehtimal ki, bir meydança ilə) və bu məhsulun inkişafı üçün sabit bir qiymət təyin olunduğu təklifi istər. Özlərini qorumaq üçün hər iki tərəf, mümkün anlaşılmazlıqların qarşısını almaq üçün təklifin hazırlanması üzərində xeyli dərəcədə çalışır.

Müştəri baxımından bu, ümumiyyətlə işlənən bir həll kimi görünür: nə əldə etdiklərini, nə vaxt və hansı qiymətə aldıqlarını bilirlər.

Tələblər dəyişir

Müştərilərin əksəriyyətinin bu nöqtədə bilmədikləri şey, tez-tez layihənin sonunda əvvəlindən daha fərqli bir şey istəmələridir.

Təklifdə hər şey xüsusi olaraq müəyyənləşdirildiyi üçün, yenidən danışıqlar aparmadan layihədəki bir şeyi sonradan dəyişdirmək demək olar ki, mümkün deyil.

  • bu vaxt digər funksiyalar daha da əhəmiyyətli oldu
  • İstədiyiniz layihə artıq texniki cəhətdən mümkün deyil
  • İstifadəçi testi məhsulun səhv başa düşüldüyünü və ya bir mənası olmadığını aşkar etdi
  • Rəqib strateji dayaq nöqtəsi tələb edən oxşar bir məhsul hazırlamışdır

Bu vəziyyətdə, təklifdə köhnə, yenidən işlənmiş əhatə dairəsi göstərildiyi təqdirdə yenidən prioritetləşdirmək asan deyil.

Çevikliyin digər vacib cəhətləri bu tip təkliflərlə zədələnir. Təklifi tamamlamaq üçün məhsul əvvəlində dəqiq bir şəkildə müəyyənləşdirilməli olduğundan məhsulun davamlı, birgə yaxşılaşdırılması daha çətindir. Bu tipik bir şəlalə iş axınına səbəb olur. Planlaşdırma poker də daxil olmaqla sprintlərin planlaşdırılması, son bir tarix qədər mənasızdır və nəticə artıq müəyyən edilmişdir.

Əgər əhatə dairəsi, tarix və qiymət əvvəldən təyin edilmişsə, artıq Scrum kimi çevik bir çərçivə tətbiq etməyin mənası yoxdur.

Bu vəziyyətdə, çevik təminatın əsas üstünlüklərindən artıq istifadə edə bilməzsiniz, lakin Scrum iclasları üçün hələ heç bir faydası olmayan əlavə işiniz var. Bu proses "yalançı skrum" olaraq da bilinir.

Digər bir təklif növü tələb olunur

Təklifdəki dəqiq nəticələri müəyyənləşdirməkdənsə, görülən işlərin (vaxt və maddi müqavilələr deyilən) məbləğinin hesablanması daha məqsədəuyğundur. Yalnız bundan sonra bir layihəni çevik bir şəkildə idarə etmək mümkündür.

Müştəri pulu üçün nə qədər və nə alırsa, tələblər siyahısını müasirləşdirərək və komanda ilə birlikdə prioritet verərək layihənin gedişində özünə qərar verir.

Çevik təkliflərin yazılması təcrübə tələb edir (mənbə: https://unsplash.com/?photo=OQMZwNd3ThU)

Müştəriyə nə gözləməsi barədə bir fikir vermək üçün, müəyyən bir müddətdə nə qədər əldə edilə biləcəyini və ya müəyyən bir tələbin yerinə yetirilməsindən əvvəl nə qədər vaxt aparacağını təxminən təxmin edə bilərlər. Bir komanda nə qədər uzun müddət birlikdə çalışsa, komandanın ümumi tempini və ya “sürətini” ölçmək daha asan olduğundan bu təxmin bir o qədər dəqiq olur. Bu, stabil komandalarla işləməyin üstünlük verilməsinin başqa bir səbəbidir.

Bunu nəzərə alaraq təklif hazırlamaq hələ də çevik keçidin ən çətin elementlərindən biridir. Hələ çevik bir mühitdə təcrübə qazanmamış hər hansı bir müştəri açıq bir müqavilə bağlamaq istəmir. Onları öz ləyaqətlərinə inandırmaq üçün əvvəlcə səriştəni nümayiş etdirmək və müştəriyə inam yaratmaq vacibdir.

Təcrübəmizə görə, çevik bir layihəni birlikdə başa vurduqdan sonra bu problemi mənimsəmək asandır. Sonra layihə prosesi özü üçün danışır; Təkrarlanan iş, sıx əməkdaşlıq və müştərinin fikirlərinə tipik şəlalə layihələrindən daha çox yaxınlaşan qısa rəy dövrləri sayəsində sürətli və nəzərəçarpan nəticələr.

Bu kitab kimi çevik təkliflər haqqında bir çox faydalı ədəbiyyat var:

6. Layihə qrupunu mümkün qədər tez əldə etmə mərhələsinə cəlb edin

Agentliklərdə satınalma və təklif mərhələsi çox vaxt layihənin həyata keçirilməsindən təcrid olunur. Yeni bir iş qrupu yeni layihələrdən məsuldur və layihə qrupu yalnız tətbiqetmə mərhələsində təfərrüatlara məruz qalır və münaqişələrin yaranma ehtimalını artırır.

Tətbiqetmə mərhələsi artıq bir layihənin uğurlu olub-olmaması üçün həlledici ola bilər. Bu səbəbdən çevik komandanın mümkün qədər tez ünsiyyətdə olması vacibdir.

Nəticədə çevik bir tətbiqin mümkün olub olmadığı və bunun üçün nə qədər vaxt gözlənilə biləcəyi nisbətən erkən qiymətləndirilə bilər. Tələb olunan vaxt, məsələn, Scrum layihəsində tələb olunan qaçış sayı yalnız layihə haqqında mümkün qədər çox şey bildiyi təqdirdə komandanın özü tərəfindən qiymətləndirilə bilər.

Bəzən işlənə biləcəyindən daha çox layihə sorğusu olur. Dartma prinsipini həyata keçirmək və ən uyğun layihəni seçmək üçün komandanın qarşıdakı bütün layihələr barədə mümkün qədər çox məlumat sahibi olması lazımdır. Yalnız bundan sonra əsaslı qərarlar verə və yeni layihələri mövcud layihələrin qaçışlarına mənalı bir şəkildə daxil edə bilərsiniz.

Yeni layihə başlayanda komanda, mümkün olan ən yaxşı keyfiyyətə uyğun məhsulu çatdırmaq üçün iştirak edən hər kəsi və tələblərini mümkün qədər tez bilməlidir. Buna nail olmaq üçün təsirli bir tədbir müştəri tərəfindəki komanda və maraqlı tərəflərlə bir seminar.

Əlavə olaraq çevik dəyərləri müştəriyə çatdırmaq, birincil əlaqə quran şəxsi müəyyənləşdirmək və əməkdaşlığa yanaşmanı ətraflı izah etmək vacibdir.

7. Xidmət təminatçının rolunu unudun (və müştərinizlə bir komanda şəklində çalışın)

Müştəri-xidmət təminatçısı əlaqəsi əks nəticə verir, çünki həmişə müştərinin sifariş verdiyini və müəyyən bir nəticə gözlədiyini düşünür. İştirak edən hər kəsi məmnun edən uğurlu bir layihə nəticəsi ümumiyyətlə hər tərəfdən çalışmaq, xüsusən də bir-biri ilə müntəzəm ünsiyyət tələb edir.

Uğurlu çevik bir layihə üçün vacib bir şərt eyni səviyyədə ünsiyyətdir. Bu o deməkdir ki, müştəri və agentlik bir-birlərini bir komanda kimi görür, bir layihə üzərində birlikdə işləyir və güclü tərəflərini tanıyır və qiymətləndirirlər. Agentlik ümumiyyətlə strategiya, istifadəçi təcrübəsi, dizayn və texniki tətbiqetmə üzrə mütəxəssisdir. Müştəri isə hədəf qrupu ilə yanaşı öz daxili proseslərini və tələblərini də bilir. Yalnız bu məlumat paylaşıldıqda, bütün maraqlı tərəfləri razı salacaq həqiqətən istifadəçi mərkəzli bir məhsul yaradıla bilər.

Bu, müştəri tərəfində layihə ilə bağlı sualları cavablandıran və ya agentliyə çatışmayan material təqdim edə bilən daimi bir əlaqələndirici şəxsin mövcud olduğunu düşünür. Hər bir müştəri tək bir layihəyə bu qədər vaxt sərf edə bilməz və ya istəmir, çünki öz daxili iş prosesləri buna imkan vermir.

Təcrübəmizə görə, müştərilər çevik əməkdaşlıq yolu ilə yüksək keyfiyyətli nəticələr əldə edə biləcəklərini daha tez-tez hiss edirlər. Bu, gözləntilərinizi qarşılayır və vaxt ayırmağa hazırsınız.

8. Komanda işi üçün yer ayırın

Çevik olmaq fənlərarası bir şəkildə və davamlı ünsiyyətdə işləmək deməkdir. Çevik qrup oturanda bu, işin koordinasiyasını asanlaşdıran ən yaxşı nəticədir. İdeal olaraq, hər bir komandanın başqaları üçün narahatlıqlar olarkən narahat olmayaraq işləyə biləcəyi öz sahələri olmalıdır, məsələn. dizaynları və ya xüsusiyyətləri müzakirə edərkən.

Çevik komandalar fasiləsiz işləyə bilməlidirlər (Mənbə: https://unsplash.com/photos/5T6lSk2uI1A)

Agentliklər tez-tez fərqli bir mənzərə çəkirlər: işçilərin müvafiq fənlərinə görə qruplaşdırılması. Bu o deməkdir ki, bütün dizaynerlər ofisin bir küncündə, inkişaf etdiricilər başqa bir küncdə, tester və hesab menecerləri tez-tez fərqli otaqlarda otururlar. Bu mövzu ilə əlaqəli mübadilə baxımından faydalı ola bilər, ancaq bir layihə qrupu içərisində ünsiyyəti daha da çətinləşdirir. Bir-birinizə yazmaq bir seçimdir, ancaq birbaşa bir-birinizlə danışmaqdan daha uzun çəkir.

Bütün komanda üzvləri eyni yerdə olmadıqda daha da çətinləşir. Hər kəs telefon və ya video konfransların nə qədər pis olduğunu bilir və əvvəllər belə bir problem görməmisinizsə, aşağıdakı video tövsiyə olunur:

9. Hər bir intizamı və bütün layihə prosesini nəzərdən keçirin

Scrum proqram inkişafından yarandığından, layihənin texniki tərəfini yalnız yaradıcılıq mərhələsinə təsir göstərmədən çevik şəkildə həyata keçirmək uyğun görünə bilər. Ancaq bu, nisbətən az şey əldə edir, çünki şəlalə quruluşu yalnız bir layihənin sonunda həll olunur.

Klassik bir şəlalə prosesi müəyyən nəticələrin təsdiqinə əsaslanır

Çevik komandanın tamamilə inkişaf etdiricilərdən ibarət olduğunu düşünək. Müştəri veb saytının konsepsiyası və dizaynı artıq tamamlanıb. İnkişaf əsnasında, əhəmiyyətli dövlətlərin hələ müəyyənləşdirilmədiyi və dizayn edilmədiyi və yaradıcı qrupun artıq növbəti layihə ilə məşğul olduğu aydın olur. İndi nə? İnsanları başqa layihələrdən çəkindirmək lazımdır? Yarımçıq bir məhsul daha da inkişaf etdirirsiniz? Başdan bəri çevik iş axınına bütün müvafiq fənləri daxil etməkdən sadə bir cavab yoxdur.

Layihə qrupu daxilində müntəzəm mübadilə məhsulun keyfiyyətini artırır (mənbə: https://unsplash.com/photos/gN_nIUnjYJI)

Əlaqə, rəy, rəy

Çevik inkişaf etdirilmiş proqram təminatının keyfiyyətinin klassik layihə rəhbərliyindəki şəlalə layihələrindən daha yaxşı olmasının böyük bir gücü və vacib səbəbi, bütün iştirak edənlərin erkən və müntəzəm rəylərinə əsaslanan məhsulların fənlərarası əməkdaşlığı və təkrar təkmilləşdirilməsidir.

Sadəcə, bu o deməkdir: hər kəs layihənin hər mərhələsində hər şeyi nəzərdən keçirir.

  • Müştəri və bütün komanda məhsul sahibinə (PO) istifadəçi hekayələri barədə rəy verir
  • İstifadəçi interfeysi dizaynerləri tel çərçivə və mühəndislik barədə rəy verir
  • UX dizaynerləri istifadəçi interfeysi dizaynı və texniki icrası ilə bağlı rəy verir
  • Ön tərəfli inkişaf etdiricilər tel çərçivələr, istifadəçi interfeysi dizaynları, arxa uç interfeyslər və mümkünsə arxa tərəf tətbiqetmə barədə rəy verir
  • Back-end inkişaf etdiricilər tel çərçivələr, istifadəçi interfeysi dizaynları və ön tətbiqetmə barədə geribildirim təqdim edirlər
  • Keyfiyyət təminatı (QA) tel çərçivələr, istifadəçi interfeysi dizaynları və mühəndislik barədə geribildirim təqdim edir
  • İstifadəçilər layihə mərhələsi boyunca istifadə testləri (rəylər, dizayn prototipləri, kuklalar, ön tətbiqetmə) vasitəsilə geribildirim verirlər.
  • Müştəri, sprint iclaslarında məhsul artımları haqqında geribildirim təqdim edir
Çevik bir mühitdə komanda bir-birinin ardınca deyil, birlikdə işləyir

Müntəzəm rəy çevik inkişafda ən vacib sərvətdir və məhsulun iştirak edən hər kəsi razı salacaq səviyyədə inkişaf etdirilməsini təmin edir. Əlbətdə ki, bu yalnız layihənin hər mərhələsində hər kəsin iştirakı ilə işləyir.

10. Hər şeyin dərhal işləməyini gözləməyin (səhv edin və onlardan dərs alın)

İnşallah əvvəlki bölmələr illər ərzində inkişaf etdirilmiş və qurulmuş olanlardan başqa bir neçə səviyyədə yanaşmalara ehtiyac olduğunu açıq şəkildə göstərmişdir. Çevikliyə addımın mütləq asan olmayan və müəyyən bir sonu olmayan bir proses olduğunu başa düşmək daha vacibdir.

Yuxarıda müzakirə olunan tədbirlərin həyata keçirilməsi çevikliyə keçidin avtomatik təminatını vermir. Eynilə, Scrum'u qəbul etmək kimi yalnız "texniki" aspektləri tətbiq etmək kifayət deyil. Daha doğrusu, korporativ mədəniyyətin dəyişdirilməsi və bütün iyerarxik səviyyələrdə ortaq, çevik bir dəyər sisteminin yaradılması vacibdir.

Bu cür əsaslı dəyişikliklərin dərhal və hamar bir şəkildə ediləcəyini gözləmək sadəlövhlük olardı. Korporativ proseslərdəki dəyişikliklər çevik bir layihə kimi qəbul edilə bilər və təkrarlanan şəkildə yayımlanır.

Nəticədə bu o deməkdir ki, insan hər şeyi bir anda dəyişdirməyə çalışmamalı, əksinə hər dəfə bir hərəkət etməlidir. Nəyin işlədiyini, nəyin işləmədiyini və nəyin yaxşılaşdırılacağını bu şəkildə öyrənirsiniz. Bir kitabın və ya bloqun tövsiyə etdiyi üçün özünü düzgün hiss etməyən bir tədbirə riayət etmək səhv olardı.

Xarici məşqçilik doğru düşüncə proseslərini hərəkətə gətirməkdə eyni dərəcədə kömək edə bilər. Lakin, birdən-birə çevik edəcək sürətli bir vasitə tapacağına ümid etmək olmaz.

Daxili bilik və təcrübə mübadiləsini qurmaq və ortaq bir yanaşma barədə razılığa gəlmək eyni dərəcədə vacibdir. Buna nail olmaq üçün, Çevik Manifestin on iki prinsipinə müntəzəm olaraq nəzər yetirmək və şirkətin onları nə dərəcədə qəbul etdiyini yoxlamaq faydalıdır:

Komandamızda Scrum çərçivəsinin təlimatlarına ciddi riayət etmək ən yaxşı həll yolu olduğunu sübut etdi. Bu proseslərdən hər dəfə kənarlaşdıqda, fəsadlar və səylərin artması ilə nəticələndi. Ancaq bunun hamı üçün olması lazım deyil. Hər şirkət özü üçün nəyin daha yaxşı işlədiyini öyrənməlidir.

Nəticə

Bir müştəri layihəsi başlamazdan əvvəl də müəyyən agentlik şərtləri çevik layihələrin müvəffəqiyyətini təhlükə altına ala bilər və ya hətta mümkünsüz edə bilər. Bunun üçün bütün səviyyələrdə və bütün fənlərdə bir gecədə həyata keçirilə bilməyəcək dəyişikliklər gətirən yeni bir düşüncə tərzi lazımdır.

Bu məqalədəki məqamlar çevik layihələri başlamazdan əvvəl planlaşdırarkən vəziyyətləri və problemləri müəyyənləşdirmək və müzakirə etmək üçün bir rəhbər ola bilər.

Bu mövzuda təcrübələriniz necədir? Çevik prosesləri çətinləşdirən digər halları bilirsinizmi? Bu məqalənin şərh hissəsində bizə məlumat verin.

Daha çox oxu

Aperto Move - Bir IBM şirkəti, 30-a yaxın işçisi olan rəqəmsal və mobil xidmətlər üçün Berlin agentliyidir. Bəs sən?

Bizi izləyin: apertomove.com / Facebook / Twitter