Epiqraf:
Bir vaxtlar Kirpi və Kiçik Ayı meşədə qarşılaşdılar.
- Salam, Kirpi!
- Salam, Balaca Ayı!
Beləliklə, söz-söz, zarafat-zarafat, Kirpi Balaca Ayı üzünə vurdu...
Aşağıda komanda rəhbərimiz, eləcə də RAS Məhsul İnkişafı Direktoru İqor Marnatın iş münaqişələrinin xüsusiyyətləri və onların idarə edilməsinin mümkün üsulları haqqında müzakirəsi var.
İşdə rastlaşdığımız münaqişələrin əksəriyyəti yuxarıdakı epiqrafda təsvir olunan ssenariyə uyğun olaraq inkişaf edir. Bir neçə iştirakçı var ki, ilkin olaraq bir-birinə qarşı kifayət qədər rəğbət bəsləyirlər, onlar hansısa məsələni həll etməyə çalışırlar, lakin sonda problem həll olunmamış qalır və nədənsə müzakirə iştirakçıları arasında münasibətlər korlanır.
Həyat müxtəlifdir və yuxarıda təsvir edilən ssenaridə variasiyalar baş verir. Bəzən iştirakçılar arasında ilkin münasibət o qədər də yaxşı olmur, bəzən birbaşa həllini tələb edən məsələ belə olmur (məsələn, epiqrafda olduğu kimi), bəzən müzakirədən sonra münasibət əvvəllər olduğu kimi qalır, lakin məsələ sonda həll olunmur.
İş münaqişəsi vəziyyəti kimi müəyyən edilə bilən bütün vəziyyətlərdə ümumi olan nədir?
Birincisi, iki və ya daha çox tərəf var. Bu tərəflər təşkilatda müxtəlif yerləri tuta bilər, bərabərlik münasibətində ola bilər (komandada həmkarlar) və ya iyerarxiyanın müxtəlif səviyyələrində (rəis - tabeçiliyində), fərdi (işçi) və ya qrup ola bilər (bir qrup şəxs arasında münaqişə olduqda). işçi və bir komanda və ya iki komanda) və s. Münaqişə ehtimalı və onun həllinin asanlığı iştirakçılar arasında etimad səviyyəsindən çox təsirlənir. Tərəflər bir-birini nə qədər yaxşı tanıyırsa, etimad səviyyəsi nə qədər yüksək olarsa, razılığa gəlmək şansları da bir o qədər yüksəkdir. Məsələn, heç vaxt üz-üzə ünsiyyətdə olmayan paylanmış komanda üzvləri, ən azı bir neçə üz-üzə ünsiyyətdə olan insanlarla müqayisədə, sadə iş məsələsi ilə bağlı münaqişə ilə daha çox qarşılaşırlar. Buna görə də, paylanmış komandalarda işləyərkən, bütün komanda üzvlərinin vaxtaşırı bir-biri ilə şəxsən görüşməsini təmin etmək çox vacibdir.
İkincisi, işdə münaqişə vəziyyətində tərəflər tərəflərdən biri, hər ikisi və ya bütövlükdə təşkilat üçün vacib olan hansısa məsələni həll etmək vəziyyətində olurlar. Eyni zamanda, vəziyyətin xüsusiyyətlərinə görə, tərəflərin adətən kifayət qədər vaxtı və onu həll etmək üçün müxtəlif yolları (rəsmi, qeyri-rəsmi, görüşlər, məktublar, idarəetmə qərarları, komandanın məqsəd və planlarının olması, iyerarxiya faktı və s.). Bu, təşkilatda iş (və ya qeyri-iş) məsələsinin həlli vəziyyətindən, məsələn, vacib bir sualın həllindən fərqlidir: “Eh, bala, sən hansı bölgədənsən?!” küçədə və ya epiqrafdan münaqişə. İş məsələsinin həlli zamanı iş prosesinin keyfiyyəti və komandada məsələlərin həlli mədəniyyəti önəmlidir.
Üçüncüsü, münaqişənin müəyyənedici amili (müzakirə etdiyimiz nöqteyi-nəzərdən) proses tərəflərinin müstəqil olaraq bütün tərəflərə uyğun olan məsələnin həllinə gələ bilməməsidir. Vəziyyət üçüncü tərəfin, kənar hakimin müdaxiləsini tələb edir. Bu məqam mübahisəli görünə bilər, amma mahiyyət etibarilə, əgər münaqişə vəziyyəti kənar hakimin müdaxiləsi olmadan uğurla həll olunubsa, məsələ uğurla həll olunubsa və tərəflərin münasibətləri pisləşməyibsə, biz buna çalışmalıyıq. . Çox güman ki, belə bir münaqişədən xəbərimiz belə olmayacaq, ya da həll olunandan sonra təsadüfən öyrənəcəyik. Komanda nə qədər çox məsələni təkbaşına həll edə bilsə, bir o qədər effektiv olar.
Münaqişənin toxunmağa dəyər olan başqa bir xarakterik xüsusiyyəti qərar zamanı emosional intensivliyin dərəcəsidir. Münaqişə mütləq yüksək emosional səviyyə ilə əlaqəli deyil. İştirakçılar vəziyyətin mahiyyət etibarilə münaqişə olması üçün qışqırıb əllərini yelləmək məcburiyyətində deyillər. Məsələ həllini tapmayıb, müəyyən emosional gərginlik var (bəlkə də zahirdə aydın ifadə olunmur), bu o deməkdir ki, qarşıdurma vəziyyəti ilə üzləşmişik.
Münaqişə vəziyyətlərinə ümumiyyətlə müdaxilə etmək lazımdır, yoxsa onların həllini öz kursuna buraxıb problemin öz-özünə həllini gözləmək daha yaxşıdır? Lazımdır. Münaqişəni tamamilə həll etmək həmişə sizin səlahiyyətinizdə və ya səriştənizdə deyil, lakin istənilən vəziyyətdə, istənilən miqyaslı münaqişədə siz böyüklər mövqeyi tuta və bununla da ətrafınızdakı daha bir neçə insanı ona cəlb edə, münaqişənin mənfi nəticələrini azalda bilərsiniz. münaqişənin həllinə töhfə verir.
Münaqişə vəziyyətlərinin bir neçə nümunəsinə baxmazdan əvvəl, bütün münaqişələr üçün ümumi olan bir neçə vacib məqama nəzər salaq.
Münaqişəni həll edərkən onun daxilində deyil (buna “meta-mövqe tutmaq” da deyilir), yəni həll prosesində tərəflərdən birinin tərkibində olmamaq, mübarizədən yuxarıda olmaq vacibdir. Əks halda, qərarın qəbul edilməsində kənar arbitrin köməkliyi yalnız digər tərəfin zərərinə tərəflərdən birinin mövqeyini gücləndirəcək. Qərar qəbul edərkən onun mənəvi cəhətdən bütün tərəflər tərəfindən, necə deyərlər, “alıb” qəbul edilməsi vacibdir. Belə ki, tərəflər qəbul edilən qərardan məmnun olmasalar da, heç olmasa, onun həyata keçirilməsinə səmimi razılıq verdilər. Necə deyərlər, razılaşmayıb öhdəçilik götürə bilmək. Əks təqdirdə, münaqişə sadəcə görünüşünü dəyişəcək, alovlanan alov torf bataqlığının altında qalacaq və bir anda yenidən alovlanacaq.
Qismən birincisi ilə əlaqəli olan ikinci məqam ondan ibarətdir ki, əgər siz artıq münaqişənin həllində iştirak etmək qərarına gəlmisinizsə, ona ünsiyyət və konteksti öyrənmək baxımından mümkün qədər ciddi yanaşın. Tərəflərin hər biri ilə şəxsən danışın. Hər biri ilə ayrıca, yeni başlayanlar üçün. Poçtla kifayətlənməyin. Paylanmış komanda vəziyyətində, heç olmasa video bağlantı vasitəsilə danışın. Eşitmə və şahid ifadələri ilə kifayətlənməyin. Hekayəni anlayın, hər bir tərəf nə istəyir, niyə bunu istəyir, nə gözləyir, bu problemi daha əvvəl həll etməyə çalışıblarmı, həll olunmasa nə olacaq, hansı həll yollarını görürlər, tərəflərin mövqeyini necə təsəvvür edirlər? qarşı tərəf, nə düşünürlər, doğru və ya yanlış və s. Hər kəsin haqlı olduğunu fərz edərək, açıq düşüncə ilə bütün mümkün konteksti başınıza yükləyin. Siz konfliktin içində deyilsiniz, onun xaricində, metapozisiyadasınız. Kontekst yalnız bir yazı mövzusunda mövcuddursa, heç olmasa onu bütövlükdə və onunla əlaqəli mövzuları və sənədləri oxuyun. Oxuduqdan sonra yenə də səsinizlə danışın. Sizə demək olar ki, poçtda olmayan vacib bir şeyi eşitmək üçün zəmanət verilir.
Üçüncü vacib məqam ünsiyyətə ümumi yanaşmadır. Bunlar adi şeylərdir, kosmik bir şey deyil, lakin çox vacibdir. Biz vaxta qənaət etməyə çalışmırıq, bütün iştirakçılarla danışırıq, insanı tənqid etmirik, amma onun hərəkətlərinin nəticələrini nəzərə alırıq (“sən kobudsan” yox, “bəlkə də uşaqlar ondan inciyə bilər” bu şey”) üzünü xilas etmək imkanı veririk, müzakirələri cərgə qarşısında deyil, şəxsən aparırıq.
Münaqişələr adətən iki səbəbdən biri ilə yaranır. Birincisi, münaqişə zamanı bir insanın böyüklər və ya uşaq mövqeyində olması ilə bağlıdır (aşağıda daha ətraflı). Bu, onun emosional yetkinliyi, duyğularını idarə etmək bacarığı ilə bağlıdır (yeri gəlmişkən, bu, həmişə yaşı ilə əlaqəli deyil). İkinci ümumi səbəb, iş prosesinin qeyri-kamilliyidir ki, bu da iştirakçılar arasında məsuliyyətin yayıldığı, tərəflərin gözləntilərinin bir-birinə şəffaf olmadığı və prosesdəki rolların bulanıq olduğu boz sahələr vəziyyətləri yaradır.
Müvafiq olaraq, konfliktin həlli zamanı (hər hansı digər məsələ kimi) menecer üç perspektivi yadda saxlamalıdır: qısamüddətli – problemi/münaqişənin burada və indi həlli, orta müddətli – başqa bir münaqişənin yaranma ehtimalını minimuma endirmək. eyni səbəbdən, və uzunmüddətli - komanda şəxs böyüklər mədəniyyəti yetişdirmək.
Hər birimizin təxminən üç-dörd yaşında daxili övladı var. O, işdə çox vaxt yatır, lakin bəzən oyanır və nəzarəti ələ alır. Uşağın öz prioritetləri var. Onun üçün bunun onun qum qutusu olduğunu, anası onu daha çox sevdiyini, maşınının ən yaxşı olduğunu israr etməsi vacibdir (dizayn ən yaxşısıdır, ən yaxşısını proqramlaşdırır, ...). Münaqişə vəziyyətində uşaq oyuncaqları basa bilər, ayaqlarını döyə bilər və spatulanı çatlaya bilər, lakin o, böyüklər problemlərini həll edə bilmir (həll arxitekturası, avtomatlaşdırılmış sınaqlara yanaşmalar, buraxılış tarixləri və s.), faydaları baxımından düşünmür. komanda üçün. Münaqişədə olan uşağı ondan böyüklərinə zəng etməsini xahiş etməklə həvəsləndirmək, təsəlli vermək və yatağa göndərmək olar. Münaqişə vəziyyətində müzakirəyə başlamazdan əvvəl, uşaqla deyil, böyüklərlə danışdığınızdan və özünüz də böyüklər mövqeyində olduğunuzdan əmin olun. Hal-hazırda dürüst məqsədiniz ciddi bir problemi həll etməkdirsə, siz böyüklər mövqeyindəsiniz. Məqsədiniz ayaqlarınızı döymək və çiyin bıçağınızı sındırmaqdırsa, bu uşaq mövqeyidir. Daxili uşağınızı yatağa göndərin və böyükləri çağırın və ya müzakirəni yenidən planlaşdırın. İnsan emosional qərar qəbul edir, sonra bunun üçün rasional əsas axtarır. Uşaqların prioritetlərinə əsaslanaraq uşağın verdiyi qərar optimal olmayacaq.
Münaqişə zamanı davranışdan əlavə, uşağın və ya böyüklərin mövqeyi də insanın öz üzərinə götürməyə hazır olduğu məsuliyyət səviyyəsi ilə xarakterizə olunur. Həddindən artıq təzahürlərində bir dəfədən çox qarşılaşdığım bir proqramçının uşaq mövqeyi belə görünür: kodu yazdım, nəzərdən keçirməyə göndərdim - işim bitdi. Rəyçilər bunu nəzərdən keçirib təsdiq etməli, QA yoxlamalıdır, problem olarsa, mənə xəbər verəcəklər. Qəribədir ki, hətta kifayət qədər yetkin və təcrübəli insanlar da bəzən belə davranırlar. Şkalanın digər ucu ondan ibarətdir ki, bir şəxs kodunun işləməsini, testlərlə əhatə olunmasını, şəxsən onun tərəfindən yoxlanılmasını, baxışdan uğurla keçməsini təmin etmək üçün özünü məsuliyyətli hesab edir (zəruri olduqda, rəyçiləri pingləməkdə, məsələləri müzakirə etməkdə problem yoxdur) səslə və s.) və yatırılıbsa, QA lazım gəldikdə yardım göstərəcək, sınaq ssenariləri təsvir olunacaq və s. Normal hallarda, proqramçı ya miqyasın yetkin sonuna yaxın başlayır, ya da təcrübə qazandıqca oraya köçür (komanda daxilində düzgün mədəniyyət yetişdirildiyi təqdirdə). Həddindən artıq hallarda, o, ümumiyyətlə uşaq mövqeyi tutaraq işləməyə davam edir, sonra o və komandada vaxtaşırı problemlər və münaqişələr olur.
Komandada düzgün, yetkin mədəniyyətin aşılanması hər bir menecer üçün mühüm vəzifədir. Bu, uzun müddət və gündəlik səy tələb edir, amma nəticə buna dəyər. Komanda mədəniyyətinə təsir etməyin iki yolu var - nümunə göstərmək (buna mütləq əməl olunacaq; komanda həmişə liderə baxır) və düzgün davranışı müzakirə etmək və mükafatlandırmaq. Burada da absurd və ya çox formal bir şey yoxdur, sadəcə problemləri müzakirə edərkən, burada nəyinsə edilə biləcəyinə diqqət yetirin, düzgün qərar verildiyi zaman fərq etdiyinizi vurğulayın, tərifləyin, buraxılışa baxış zamanı qeyd edin və s.
Sadədən mürəkkəbə doğru bir neçə tipik münaqişə vəziyyətlərini nəzərdən keçirək:
İşlə bağlı olmayan münaqişələr
Çox vaxt işdə iş ilə bağlı olmayan münaqişələr olur. Onların baş verməsi və həlli asanlığı adətən iştirakçıların emosional intellekt səviyyəsi, yetkinlik səviyyəsi ilə birbaşa bağlıdır və iş prosesinin mükəmməlliyi və ya qeyri-kamilliyi ilə bağlı deyildir.
Tipik misallar: kimsə paltaryuyan maşından və ya duşdan kifayət qədər tez-tez istifadə etmir, başqalarının xoşuna gəlmir, kimsə havasızdır, digərləri pəncərəni açanda külək alır, kimsə çox səs-küylüdür, digərləri işləmək üçün sükuta ehtiyac duyur və s. Bu cür münaqişələrin həllini gecikdirməmək və onların öz kursuna getməsinə imkan verməmək daha yaxşıdır. Onlar özbaşına həll etməyəcək və sizi hər gün işdən yayındıracaq və komandadakı atmosferi zəhərləyəcəklər. Xoşbəxtlikdən, onları həll etmək adətən böyük problem deyil - sadəcə olaraq gigiyenaya məhəl qoymayan həmkarınızla sakit danışın (təbii ki, təkbətək), səssizliyə/sərinliyə üstünlük verən insanlar üçün rahat oturacaq təmin edin, səs uducu qulaqlıqlar alın və ya arakəsmələr quraşdırın. və s.
İşlədiyim müddətdə bir neçə dəfə qarşılaşdığım başqa bir misal komanda üzvlərinin psixoloji uyğunsuzluğudur. Nədənsə insanlar birlikdə işləyə bilmirlər, hər qarşılıqlı əlaqə qalmaqalla bitir. Bəzən bu, insanların hansısa aktual məsələyə (adətən siyasi) qütb baxışları olması və onları işdən kənarda necə tərk edəcəklərini bilməmələri ilə bağlıdır. Onları bir-birlərinə dözməyə və ya davranışlarını dəyişməyə inandırmaq olduqca boş bir işdir. Qarşılaşdığım yeganə istisna açıq qavrayışlı gənc həmkarlarımdır; onların davranışı hələ də dövri söhbətlər vasitəsilə tədricən dəyişdirilə bilər. Adətən məsələ onları müxtəlif komandalara ayırmaqla və ya ən azından işdə çox nadir hallarda üst-üstə düşmək imkanı verməklə uğurla həll olunur.
Yuxarıda göstərilən bütün hallarda, bütün iştirakçılarla şəxsən danışmağa, vəziyyəti müzakirə etməyə, bu vəziyyətdə ümumiyyətlə problem görüb-görməmələrini soruşmağa, onların fikrincə, həll yollarının nə olduğunu soruşmağa və bunun həyata keçirilməsində iştirakını təmin etməyə dəyər. qərar.
İş prosesinin optimallaşdırılması nöqteyi-nəzərindən (qeyd etdiyim ortamüddətli perspektiv) burada çox şey etmək olmaz, optimallaşdırmanın yeganə məqamı komanda formalaşdırarkən uyğunluq amilini nəzərə almaq və adamları yerə qoymamaqdır. kimin qarşıduracağını əvvəlcədən birlikdə.
Komanda mədəniyyəti nöqteyi-nəzərindən, insanların komandaya və həmkarlarına hörmət etdiyi və problemləri müstəqil şəkildə həll etməyi bilən yetkin mədəniyyətə malik komandalarda belə hallar daha az baş verir. Bundan əlavə, yüksək etimad səviyyəsinin olduğu, insanların uzun müddət birlikdə işlədiyi və/və ya işdən kənar tez-tez ünsiyyət qurduğu komandalarda bu cür münaqişələr daha asan (çox vaxt avtomatik) həll olunur.
İşlə bağlı münaqişələr:
Belə konfliktlər adətən hər iki səbəbdən birdən yaranır, həm emosional (iştirakçılardan birinin böyüklər mövqeyində olmaması), həm də iş prosesinin özünün qüsursuzluğu. Ola bilsin ki, rastlaşdığım münaqişələrin ən çox yayılmış növü kod təhlili və ya tərtibatçılar arasında memarlıq müzakirələri zamanı münaqişələrdir.
Burada iki tipik halı qeyd edərdim:
1) Birinci halda, tərtibatçı həmkarından kod nəzərdən keçirə bilmir. Yamaq nəzərdən keçirilməyə göndərilir və heç nə baş vermir. İlk baxışdan iki tərəf arasında açıq-aşkar münaqişə yoxdur, amma fikirləşsəniz, bu, kifayət qədər münaqişədir. İş məsələsi həll olunmayıb, tərəflərdən biri (nəzərdən keçirilməsini gözləyən) açıq-aşkar diskomfort yaşayır. Bu işin ekstremal alt növü icmada və ya müxtəlif komandalarda inkişafdır, halbuki rəyçi yüklənmə və ya digər hallar səbəbindən bu xüsusi kodla maraqlanmaya bilər, baxış sorğusuna ümumiyyətlə diqqət yetirməyə bilər və kənar arbitr. (hər iki tərəf üçün ümumi olan menecer) ) ümumiyyətlə olmaya bilər.
Belə bir vəziyyətdə kömək edən həll yanaşması, böyüklərin uzunmüddətli perspektivi, mədəniyyəti ilə bağlıdır. Birincisi, ağıllı fəaliyyət işləyir. Rəydə asılan kodun rəyçinin özünün diqqətini cəlb edəcəyini gözləməməlisiniz. Biz rəyçilərə onu görməyə kömək etməliyik. Pingani bir neçə adam, syncape haqqında sual verin, müzakirələrdə iştirak edin. Aydındır ki, ehtiyatsızlıq köməkdən daha çox zərər verə bilər, sağlam düşüncədən istifadə etməlisiniz. İkincisi, əvvəlcədən hazırlıq yaxşı işləyir. Əgər komanda nə baş verdiyini və nə üçün, ümumiyyətlə, bu kodun nə üçün lazım olduğunu başa düşürsə, dizayn əvvəlcədən hamı ilə müzakirə edilib və razılaşdırılıbsa, insanlar daha çox belə koda diqqət yetirir və onu işə qəbul edirlər. Üçüncüsü, hakimiyyət işləyir. Nəzərdən keçirilməsini istəyirsinizsə, özünüz çoxlu rəylər edin. Həqiqi yoxlamalar, real testlər və faydalı şərhlərlə yüksək keyfiyyətli rəylər edin. Əgər ləqəbiniz komandada yaxşı tanınırsa, kodunuzun fərqinə varma şansınız daha yüksəkdir.
İş axını nöqteyi-nəzərindən, burada mümkün təkmilləşdirmələr tərtibatçıya özünün və komandanın məqsədlərinə çatmasına kömək etməyə yönəlmiş düzgün prioritetləşdirmədir (başqalarını nəzərdən keçirin, cəmiyyətə məktublar yazın, kodu arxitektura təsviri, sənədlər, testlər ilə müşayiət edin, müzakirələrdə iştirak edin. icma və s.), yamaqların növbədə çox uzun müddət asılmasının qarşısını almaq və s.
2) Kod və ya dizaynın nəzərdən keçirilməsi zamanı baş verən münaqişələrin ikinci ümumi halı texniki məsələlər, kodlaşdırma üslubu və alətlərin seçimi ilə bağlı fərqli baxışlardır. Bu işdə iştirakçılar arasında inam səviyyəsi, eyni komandaya mənsub olması və birgə iş təcrübəsi böyük əhəmiyyət kəsb edir. İştirakçılardan biri uşaq mövqeyi tutduqda və həmsöhbətin ona çatdırmaq istədiyini eşitməyə çalışmadıqda çıxılmaz vəziyyət yaranır. Çox vaxt həm qarşı tərəfin təklif etdiyi yanaşma, həm də ilkin olaraq təklif olunan yanaşma uğurla nəticələnə bilər və hansını seçmək prinsipcə əhəmiyyət kəsb etmir.
Bir gün komandamdan bir proqramçı (ona Paşa deyək) paket yerləşdirmə sistemində dəyişikliklərlə yamaq hazırladı, bu patch qonşu şöbədən olan həmkarlar tərəfindən hazırlanmış və dəstəklənmişdir. Onlardan biri (İqor) paketləri yerləşdirərkən Linux xidmətlərinin necə konfiqurasiya edilməli olduğuna dair öz güclü fikri var idi. Bu fikir yamaqda təklif olunan yanaşmadan fərqli idi və onlar razılaşa bilmədilər. Həmişə olduğu kimi, son tarixlər tükənir və bir növ qərara gəlmək lazım idi, onlardan birinin yetkin mövqeyini tutması lazım idi. Paşa hər iki yanaşmanın yaşamaq hüququna malik olduğunu qəbul etdi, lakin o, seçiminin keçməsini istədi, çünki Nə birinin, nə də ikinci variantın heç bir aşkar texniki üstünlükləri yox idi.
Müzakirəmiz belə göründü (çox sxematik olaraq, əlbəttə ki, söhbət yarım saat davam etdi):
- Paşa, bir neçə günə donma xüsusiyyətimiz var. Hər şeyi bir araya gətirməyimiz və mümkün qədər tez sınaqdan keçirməyimiz vacibdir. İqoru necə keçə bilərik?
— Xidmətləri başqa cür qurmaq istəyir, mənim üçün orada şərhlər yapışdırıb...
- Bəs nə var, böyük dəyişikliklər, çox hay-küy?
- Yox, bir-iki saat iş var, amma axırda fərq yoxdur, hər iki yolla da işləyəcək, bu niyə lazımdır? İşləyən bir şey etdim, qəbul edək.
- Qulaq as, bütün bunları nə vaxtdan müzakirə edirsən?
- Bəli, artıq bir həftə yarımdır ki, vaxtı qeyd edirik.
- Um... onsuz da həftə yarım çəkmiş bir məsələni bir neçə saata həll edib, bunu etməyək?
- Yaxşı, bəli, amma İqorun mənim başıma gəldiyimi düşünməsini istəmirəm ...
- Qulaq asın, sizin üçün daha vacib olan nədir, içərinizdəki qərarınızla birlikdə azadlığa çıxmaq, yoxsa İqoru öldürmək? Biz onu bloklaya bilərik, lakin buraxılışla uçmaq üçün yaxşı şans var.
- Yaxşı ... İqorun burnunu silmək, əlbəttə ki, gözəl olardı, amma yaxşı, sərbəst buraxılması daha vacibdir, razıyam.
- Doğrudanmı İqorun nə düşündüyü sizin üçün bu qədər vacibdir? Düzünü desəm, o, heç vecinə də deyil, sadəcə olaraq məsuliyyət daşıdığı işin müxtəlif yerlərində vahid yanaşma istəyir.
- Yaxşı, yaxşı, icazə verin, şərhlərdə xahiş etdiyi kimi edim və test etməyə başlayaq.
- Sağ ol, Paşa! Əmin idim ki, siz ikinizdən daha yetkin olacaqsınız, baxmayaraq ki, İqorek sizdən böyükdür :)
Məsələ həll olundu, buraxılış vaxtında çıxdı, Paşa çox da narazılıq hiss etmədi, çünki özü həll yolunu təklif etdi və həyata keçirdi. İqor ümumiyyətlə məmnun idi, çünki... Onun fikri nəzərə alındı və təklif etdiyi kimi etdilər.
Əsasən eyni münaqişənin başqa bir növü layihədə, xüsusən də paylanmış komandada texniki həllər/kitabxanalar/yanlaşmalar arasında seçimdir. C/C++ proqramından istifadə edən layihələrdən birində məlum oldu ki, layihənin texniki idarə edilməsi qəti şəkildə STL (Standart Şablon Kitabxanası) istifadəsinə qarşıdır. Bu inkişafı asanlaşdıran standart dil kitabxanasıdır və komandamız buna çox öyrəşib. Məlum oldu ki, layihə C++ ilə müqayisədə C dilinə daha yaxındır, bu da komandanı o qədər də ruhlandırmayıb, çünki rəhbərlik əllərindən gələni sınadı və həqiqətən də gözəl oyunçuları işə götürdü. Eyni zamanda, komandanın Amerika hissəsi, həm mühəndislər, həm də menecerlər uzun müddət şirkətdə çalışmış, mövcud vəziyyətə öyrəşmiş və hər şeydən razı idilər. Komandanın Rusiya hissəsi bu yaxınlarda, bir neçə həftə ərzində (mən də daxil olmaqla) bir araya gəldi. Komandanın Rusiya hissəsi inkişafa adi yanaşmadan qəti şəkildə imtina etmək istəmədi.
İki qitə arasında sonsuz yazılı müzakirələr başladı, üç-dörd ekranda məktublar proqramçılardan proqramçılara və menecerlərə qədər qrup poçtları və şəxsi məktublar şəklində irəli-geri uçurdu. Adətən olduğu kimi, bu uzunluqdakı məktubları müəlliflərdən və onların qızğın tərəfdarlarından başqa heç kim oxumurdu. STL-nin texniki üstünlükləri, nə qədər yaxşı sınaqdan keçirildiyi, nə qədər təhlükəsiz olduğu və ümumiyyətlə, onunla həyatın nə qədər gözəl olduğu və onsuz nə qədər dəhşətli olduğu ilə bağlı müxtəlif istiqamətlərdə çox ekranlı fikirlər ötürən söhbətlər gərginliklə cırıldı. .
Bütün bunlar kifayət qədər uzun müddət davam etdi, nəhayət başa düşdüm ki, biz məsələnin texniki aspektlərini müzakirə edirik, amma əslində problem texniki deyildi. Problem STL-nin üstünlükləri və ya mənfi cəhətləri və ya onsuz işləməyin çətinliyi deyil. Problem daha çox təşkilati xarakter daşıyır. Sadəcə, çalışdığımız şirkətin necə işlədiyini başa düşmək lazım idi. Heç birimizin əvvəllər belə bir şirkətdə işləmək təcrübəsi yox idi. Məsələ onda idi ki, kod hazırlanıb istehsala buraxıldıqdan sonra dəstək digər komandalardan, başqa ölkələrdən tamamilə fərqli insanlar tərəfindən idarə olunurdu. Bir neçə on minlərlə mühəndisdən ibarət bu nəhəng mühəndis komandası (ümumilikdə) yalnız tamamilə əsas minimum texniki vasitələri, belə demək mümkünsə, minimum minimumu ödəyə bilərdi. Şirkətdə fiziki olaraq müəyyən edilmiş mühəndislik standartından kənara çıxan hər hansı bir şey gələcəkdə dəstəklənə bilməz. Komandanın səviyyəsi onun ən zəif üzvlərinin səviyyəsi ilə müəyyən edilir. Anladıqdan sonra əsl motivasiya Komandanın Amerika hissəsinin hərəkətləri ilə bu məsələ gündəmdən çıxarıldı və biz birlikdə şirkətin qəbul etdiyi standartlardan istifadə edərək məhsulu uğurla inkişaf etdirdik və buraxdıq. Bu vəziyyətdə məktublar və söhbətlər yaxşı nəticə vermədi, ortaq məxrəcə gəlmək üçün bir neçə səfər və çoxlu şəxsi ünsiyyət lazım idi.
İş prosesi nöqteyi-nəzərindən bu konkret halda istifadə olunan vasitələrin təsviri, onlara olan tələblər, yenilərinin əlavə edilməsinə məhdudiyyətlər və bu cür məhdudiyyətlərin əsaslandırılması kömək edərdi. Bu cür sənədlər təqribən XNUMX-ci ildə hazırlanmış “Proqram təminatının inkişafı üzrə menecerin əl kitabı”nın Təkrar İstifadə Strategiyası və İnkişaf Mühiti paraqraflarında təsvir edilənlərə uyğun gəlir. . Yaşına baxmayaraq, bu cür proqram təminatının inkişafının bütün əsas fəaliyyətlərini və planlaşdırma mərhələlərini mükəmməl şəkildə təsvir edir. Bu kimi sənədlərin olması məhsulda hansı komponentlərin və yanaşmaların istifadə oluna biləcəyini və niyə istifadə oluna biləcəyini müzakirə etməyi çox asanlaşdırır.
Mədəni nöqteyi-nəzərdən, açıq-aydın, daha yetkin bir mövqe ilə, tərəflər həmkarlarının hərəkətlərinin əsl motivasiyasını eşitməyə və anlamağa çalışaraq, şəxsi eqoyu deyil, layihənin və komandanın prioritetləri əsasında hərəkət edirlər. , münaqişə daha asan və daha tez həll olunardı.
Texniki həll yolunun seçilməsi ilə bağlı başqa bir münaqişədə tərəflərdən birinin motivasiyasını başa düşmək mənə də nəzərəçarpacaq vaxt tələb etdi (bu, çox qeyri-adi bir hal idi), lakin motivasiya aydın olduqdan sonra həll yolu göz qabağında idi.
Vəziyyət belədir: təxminən 20 nəfərlik komandada yeni bir tərtibatçı peyda olur, gəlin onu Stas adlandıraq. O zaman komanda olaraq ünsiyyət üçün standart alətimiz Skype idi. Sonradan məlum oldu ki, Stas açıq standartların və açıq mənbə proqram təminatının böyük pərəstişkarı idi və yalnız mənbələri ictimaiyyətə açıq olan və açıq şəkildə təsvir edilmiş protokollardan istifadə edən alətlər və əməliyyat sistemlərindən istifadə edirdi. Skype bu vasitələrdən biri deyil. Biz bu yanaşmanın üstünlükləri və mənfi cəhətləri, Skype-ın analoqlarını müxtəlif əməliyyat sistemlərində işə salmaq cəhdləri, Stasın komandanı başqa standartlara keçməyə inandırmaq cəhdləri, ona şəxsən poçt vasitəsilə yazmaq, ona şəxsən zəng etmək barədə çox vaxt sərf etdik. telefon, ona Skype üçün xüsusi olaraq ikinci kompüter al və s. Nəhayət, başa düşdüm ki, bu problem mahiyyət etibarı ilə texniki və ya təşkilati deyil, daha çox ideoloji, hətta deyə bilərik ki, dinidir (Stas üçün). Nəhayət Stas və Skype-ı bağlasaq belə (bu, bir neçə ay çəkdi), problem hər hansı bir sonrakı alətdə yenidən yaranacaq. Stasın dünyagörüşünü dəyişdirmək üçün mənim ixtiyarımda heç bir real vasitə yox idi və bu mühitdə mükəmməl işləyən komandanın dünyagörüşünü dəyişməyə cəhd etmək üçün heç bir əsas yox idi. İnsan və şirkət dünyagörüşündə sadəcə olaraq ortoqonal idi. Belə vəziyyətlərdə yaxşı bir həll təşkilatçılıqdır. Stası daha üzvi olduğu başqa komandaya transfer etdik.
Bu konfliktin səbəbi, məncə, konkret şəxsin (onun güzəştə getməyə imkan verməyən güclü fikri olan) şəxsi mədəniyyəti ilə şirkətin mədəniyyəti arasındakı uyğunsuzluqdur. Bu halda, təbii ki, menecerin səhvidir. Onu belə bir layihəyə götürmək əvvəlcə yanlış idi. Stas nəhayət açıq mənbəli proqram təminatının inkişafı layihəsinə keçdi və orada mükəmməl oldu.
Həm tərtibatçının uşaq münasibəti, həm də iş prosesinin çatışmazlıqları nəticəsində yaranan münaqişənin yaxşı nümunəsi, görülən işin tərifi olmadıqda, tərtibatçı və QA komandasının hazır olması ilə bağlı fərqli gözləntilərə malik olduğu bir vəziyyətdir. xüsusiyyət QA-ya köçürüldü. Tərtibatçı hesab edirdi ki, kodu yazmaq və funksiyanı hasarın üstündən QA-ya atmaq kifayətdir - onlar onu orada çeşidləyəcəklər. Yeri gəlmişkən, kifayət qədər yetkin və təcrübəli proqramçı, lakin bu, keyfiyyət üçün onun daxili həddi idi. QA bununla razılaşmadı və özünün yoxladığını onlara göstərməyi və təsvir etməyi tələb etdi və onlar üçün sınaq skripti tələb etdi. Onlar keçmişdə bu tərtibatçının funksionallığı ilə bağlı problemlər yaşamışdılar və yenidən vaxtlarını itirmək istəmədilər. Yeri gəlmişkən, onlar haqlı idilər - xüsusiyyət həqiqətən işləmədi, kodu QA-ya göndərməzdən əvvəl yoxlamadı.
Vəziyyəti həll etmək üçün ondan hər şeyin həqiqətən işlədiyini göstərməsini xahiş etdim (işləmədi və o, bunu düzəltməli oldu), komanda ilə və görülən QA tərifi ilə danışdıq (onlar bunu bacarmadılar) yazaraq, prosesi çox bürokratik etmək istəmədiyimiz üçün ), yaxşı, tezliklə bu mütəxəssislə yollarımızı ayırdıq (ümumi rahatlama üçün).
İş axını nöqteyi-nəzərindən, bu vəziyyətdə mümkün təkmilləşdirmələr, görülən işlərin tərifinin, hər bir vahid xüsusiyyətinin və inteqrasiya testlərinin dəstəklənməsi tələblərinin və tərtibatçı tərəfindən həyata keçirilən sınaqların təsvirinin olmasıdır. Layihələrdən birində biz kod əhatə səviyyəsini CI zamanı testlərlə ölçdük və yamaq əlavə etdikdən sonra əhatə səviyyəsi aşağı düşdükdə, testlər uğursuz olaraq qeyd edildi, yəni. hər hansı yeni kod yalnız onun üçün yeni testlər olduqda əlavə edilə bilər.
İş prosesinin təşkili ilə sıx bağlı olan münaqişənin başqa bir tipik nümunəsi. Bizim məhsulumuz, məhsul inkişaf komandamız, dəstək komandamız və müştərimiz var. Müştərinin məhsul və əlaqə dəstəyi ilə bağlı problemləri var. Dəstək problemi təhlil edir və problemin məhsulda olduğunu anlayır və problemi məhsul komandasına ötürür. Məhsul komandası məşğul vaxtdadır, buraxılış yaxınlaşır, buna görə təyin olunduğu tərtibatçının digər biletləri arasında itirilən müştərinin problemi olan bir bilet bir neçə həftə diqqətdən kənarda qalır. Dəstək, tərtibatçının müştərinin problemi üzərində işlədiyini düşünür. Müştəri gözləyir və probleminin üzərində işləndiyinə ümid edir. Reallıqda isə hələ heç nə baş vermir. Bir neçə həftədən sonra müştəri nəhayət tərəqqi ilə maraqlanmağa qərar verir və işlərin necə getdiyini dəstəkdən soruşur. Dəstək inkişaf tələb edir. Tərtibatçı titrəyir, biletlərin siyahısına baxır və orada müştəridən bilet tapır. Müştəridən bir bilet oxuyarkən, problemi həll etmək üçün kifayət qədər məlumat olmadığını başa düşür və ona daha çox log və zibillik lazımdır. Dəstək müştəridən əlavə məlumat tələb edir. Və sonra müştəri başa düşür ki, bütün bu müddət ərzində heç kim onun problemi üzərində işləməyib. Və ildırım çaxacaq...
Bu vəziyyətdə, münaqişənin həlli özü olduqca aydın və xəttidir (məhsulu düzəldin, sənədləri və testləri yeniləyin, müştərini sakitləşdirin, düzəliş buraxın və s.). İş prosesini təhlil etmək və iki komanda arasında qarşılıqlı əlaqənin təşkilinə kimin cavabdeh olduğunu və bu vəziyyətin ilk növbədə nə üçün mümkün olduğunu başa düşmək vacibdir. Prosesdə nəyi düzəltmək lazım olduğu aydındır - kimsə müştərilərin xatırlatmaları olmadan, fəal şəkildə ümumi mənzərəni izləməlidir. Müştərinin biletləri tərtibatçıların digər biletləri arasında fərqlənməlidir. Dəstək, inkişaf komandasının hazırda öz biletləri üzərində işlədiyini və yoxsa, nə vaxt işə başlaya biləcəyini və nəticələrin nə vaxt gözlənildiyini görməlidir. Dəstək və inkişaf vaxtaşırı əlaqə saxlamalı və biletlərin vəziyyətini müzakirə etməli, sazlama üçün lazım olan məlumatların toplanması mümkün qədər avtomatlaşdırılmalıdır və s.
Müharibədə düşmən iki bölmənin qovşağına zərbə vurmağa çalışdığı kimi, işdə də ən incə və həssas nöqtə adətən komandalar arasında qarşılıqlı əlaqədir. Əgər dəstək və inkişaf menecerləri kifayət qədər yaşlıdırlarsa, onlar prosesi özləri düzəldə biləcəklər, əgər yoxsa, vəziyyəti düzəldə bilən menecer müdaxilə edənə qədər proses münaqişələr və problemlər yaratmağa davam edəcək.
Müxtəlif şirkətlərdə dəfələrlə gördüyüm başqa bir tipik nümunə, bir məhsulun bir komanda tərəfindən yazıldığı, onun üçün avtomatik inteqrasiya testlərinin ikinci bir komanda tərəfindən yazıldığı və hamısının işlədiyi infrastrukturun üçüncü bir komanda tərəfindən müşayiət olunduğu bir vəziyyətdir. komanda. Testlər həyata keçirərkən problemlər hər zaman yaranır və onlarda problemlərin səbəbi həm məhsul, həm də testlər və infrastruktur ola bilər. Problemlərin ilkin təhlilini, fayl səhvlərini, məhsulun təhlil jurnallarını, testləri və infrastrukturu və s. kimin yerinə yetirməli olduğunu razılaşdırmaq adətən problemlidir. Burada münaqişələr çox tez-tez olur və eyni zamanda, vahid xarakter daşıyır. Yüksək emosional intensivlik halında, iştirakçılar tez-tez uşaq mövqeyinə düşürlər və serialda müzakirələr başlayır: "Mən niyə bununla məşğul olmalıyam", "onlar daha tez-tez pozulur" və s.
İş axını nöqteyi-nəzərindən problemi həll etmək üçün konkret addımlar komandaların tərkibindən, testlərin və məhsulun növündən və s. Layihələrdən birində komandaların hər həftə testlərə nəzarət etdiyi dövri növbətçiliyi tətbiq etdik. Digərində, ilkin təhlil həmişə test tərtibatçıları tərəfindən aparılırdı, lakin təhlil çox əsas idi və məhsul kifayət qədər sabit idi, buna görə də yaxşı işləyirdi. Əsas odur ki, prosesin şəffaf olması, gözləntilərin bütün tərəflər üçün aydın olması və vəziyyətin hamı üçün ədalətli olmasıdır.
Bir təşkilatda münaqişə hətta problemdirmi?Komandanızda konfliktlərin tez-tez (və ya sadəcə vaxtaşırı) baş verməsi pis əlamətdirmi? Ümumiyyətlə, yox, çünki artım, inkişaf varsa, hansısa dinamika varsa, o zaman indiyədək həllini tapmayan məsələlər yaranır və onları həll edəndə münaqişələr yarana bilər. Bu, bəzi sahələrin diqqətə ehtiyacı olduğunun, təkmilləşdirilməli sahələrin olduğunun göstəricisidir. Münaqişələr çox tez-tez yaranırsa, həll etmək çətindirsə və ya uzun müddət çəkirsə, pisdir. Bu, çox güman ki, kifayət qədər sadələşdirilməmiş iş proseslərinin və komandanın kifayət qədər yetkin olmamasının əlamətidir.
Mənbə: www.habr.com