sloganı:
Bir zamanlar Kirpi ile Küçük Ayı ormanda buluşmuşlar.
- Merhaba Kirpi!
- Merhaba Küçük Ayı!
Yani kelime kelime, şaka şaka, Küçük Ayı Kirpi'nin suratına çarptı...
Aşağıda ekip liderimiz ve RAS Ürün Geliştirme Direktörü Igor Marnat'ın iş çatışmalarının ayrıntıları ve bunları yönetmenin olası yöntemleri hakkında yaptığı bir tartışma bulunmaktadır.
İşyerinde karşılaştığımız çatışmaların çoğu, yukarıdaki epigrafta anlatılana benzer bir senaryoya göre gelişir. Başlangıçta birbirlerine oldukça olumlu yaklaşan birkaç katılımcı var, bir sorunu çözmeye çalışıyorlar, ancak sonunda sorun çözülmeden kalıyor ve bazı nedenlerden dolayı tartışmanın katılımcıları arasındaki ilişkiler bozuluyor.
Hayat çeşitlidir ve yukarıda açıklanan senaryoda farklılıklar meydana gelir. Bazen katılımcılar arasındaki ilişki başlangıçta pek iyi değildir, bazen doğrudan çözüm gerektiren bir konu bile yoktur (mesela epigrafta olduğu gibi), bazen tartışma sonrasında ilişki başlamadan öncekiyle aynı kalır ancak sonuçta sorun çözülmedi.
İş çatışması durumu olarak tanımlanabilecek tüm durumlarda ortak olan nedir?
Öncelikle iki veya daha fazla taraf var. Bu taraflar kuruluşta farklı yerleri işgal edebilir, eşitlik ilişkisi içinde olabilir (bir ekipteki meslektaşlar) veya hiyerarşinin farklı düzeylerinde (patron - ast), bireysel (çalışan) veya grup (biri arasında çatışma durumunda) olabilir. çalışan ve bir ekip veya iki ekip) vb. Çatışma olasılığı ve çözümünün kolaylığı, katılımcılar arasındaki güven düzeyinden büyük ölçüde etkilenir. Taraflar birbirini ne kadar iyi tanırsa, güven düzeyi de o kadar yüksek olur ve anlaşmaya varma şansları da o kadar artar. Örneğin, dağınık bir ekibin hiç yüz yüze etkileşime girmemiş üyelerinin, basit bir iş meselesinde çatışma yaşama olasılığı, en az birkaç yüz yüze etkileşime sahip olan kişilere göre daha yüksektir. Bu nedenle dağınık ekiplerde çalışırken tüm ekip üyelerinin periyodik olarak birbirleriyle şahsen buluşmasını sağlamak çok önemlidir.
İkinci olarak, iş yerinde bir çatışma durumunda taraflar, taraflardan biri, her ikisi için veya bir bütün olarak organizasyon için önemli olan bazı sorunları çözme durumundadırlar. Aynı zamanda, durumun özelliklerine bağlı olarak, taraflar genellikle yeterli zamana ve sorunu çözmek için çeşitli yollara sahiptirler (resmi, gayri resmi, toplantılar, mektuplar, yönetim kararları, ekibin hedef ve planlarının varlığı, hiyerarşi gerçeği vb.). Bu, bir kuruluştaki iş (veya iş dışı) sorununu çözme durumundan, örneğin önemli bir soruyu çözmekten farklıdır: "Eh, evlat, sen hangi bölgedensin?" sokakta ya da epigraftaki çatışma. Bir iş sorununun çözülmesi durumunda, iş sürecinin kalitesi ve ekipteki sorunları çözme kültürü önemlidir.
Üçüncüsü, (tartışmamız açısından) çatışmanın belirleyici unsuru, sürecin taraflarının bağımsız olarak, tüm taraflara uygun bir çözüme ulaşamamasıdır. Bu durum üçüncü bir tarafın, yani dışarıdan bir hakemin müdahalesini gerektirmektedir. Bu nokta tartışmalı görünebilir, ancak özünde, eğer çatışma durumu dışarıdan bir hakemin müdahalesi olmadan başarıyla çözüldüyse, sorun başarıyla çözüldüyse ve tarafların ilişkileri bozulmadıysa, çabalamamız gereken durum budur. . Büyük olasılıkla böyle bir çatışmadan haberimiz bile olmayacak veya çözüldükten sonra tesadüfen öğreneceğiz. Bir ekip ne kadar çok sorunu kendi başına çözebilirse o kadar etkili olur.
Çatışmanın değinmeye değer bir diğer karakteristik özelliği de karar sırasındaki duygusal yoğunluğun derecesidir. Çatışmanın mutlaka yüksek duygusal düzeyle ilişkili olması gerekmez. Durumun özünde bir çatışma olması için katılımcıların bağırmasına ve kol sallamasına gerek yoktur. Sorun çözülmedi, belli bir duygusal gerilim var (belki de açıkça ifade edilmiyor), bu da bir çatışma durumuyla karşı karşıya olduğumuz anlamına geliyor.
Çatışma durumlarına müdahale etmek gerekli mi, yoksa çözümlerinin kendi yoluna gitmesine izin verip sorunun kendi kendine çözülmesini beklemek daha mı iyi? Gerekiyor. Çatışmayı tamamen çözmek her zaman sizin gücünüzde veya yetkinliğinizde olmayabilir, ancak her durumda, herhangi bir ölçekte bir çatışmada, yetişkin bir pozisyon alabilir, böylece etrafınızdaki birkaç insanı daha bu duruma getirebilir, çatışmanın olumsuz sonuçlarını hafifletebilirsiniz. Çatışmayı çözebilir ve çözümüne katkıda bulunabilir.
Birkaç çatışma durumu örneğine bakmadan önce, tüm çatışmalarda ortak olan birkaç önemli noktaya bakalım.
Bir çatışmayı çözerken, kavganın içinde değil üstünde olmak (buna “meta-pozisyon almak da denir”), yani çözüm sürecinde taraflardan birinin parçası olmamak önemlidir. Aksi takdirde, karara dışarıdan bir hakemin yardımcı olması, taraflardan birinin konumunu diğer tarafın aleyhine güçlendirecektir. Bir karar verirken, “satın alındı” dedikleri gibi, tüm taraflarca ahlaki olarak kabul edilmesi önemlidir. Öyle ki, taraflar alınan karardan memnun olmasalar bile en azından içtenlikle uygulamaya karar verdiler. Dedikleri gibi, aynı fikirde olmamak ve taahhütte bulunmak. Aksi takdirde, çatışma sadece görünüşünü değiştirecek, için için yanan ateş turba bataklığının altında kalacak ve bir noktada kaçınılmaz olarak yeniden alevlenecek.
Kısmen birinciyle bağlantılı olan ikinci nokta, çatışmanın çözümüne zaten katılmaya karar verdiyseniz, bunu iletişim açısından ve bağlamı incelemek açısından mümkün olduğunca ciddiye almanızdır. Tarafların her biriyle kişisel olarak konuşun. Yeni başlayanlar için her biriyle ayrı ayrı. Postayla yetinmeyin. Dağınık bir ekip söz konusu olduğunda en azından video bağlantısı aracılığıyla konuşun. Kulaktan dolma bilgilerle, görgü tanıklarının ifadeleriyle yetinmeyin. Hikâyeyi anlayın, her iki taraf da ne istiyor, neden istiyor, ne bekliyor, bu konuyu daha önce çözmeye çalıştılar mı, çözülmezse ne olacak, hangi çözümleri görüyorlar, Türkiye'nin konumunu nasıl hayal ediyorlar? diğer taraf ne düşünüyor, doğru mu yanlış mı vs. Açık fikirlilikle, herkesin haklı olduğunu varsayarak olası tüm bağlamları kafanıza yükleyin. Çatışmanın içinde değilsin, onun dışındasın, bir metapozisyon içindesin. İçerik yalnızca bir gönderi dizisinde mevcutsa, en azından içeriğin tamamını ve onunla ilgili konuları ve belgeleri okuyun. Okuduktan sonra yine de sesinizle konuşun. Postada olmayan önemli bir şeyi duymanız neredeyse garantidir.
Üçüncü önemli nokta ise iletişime genel yaklaşımdır. Bunlar sıradan şeylerdir, kozmik değiller ama çok önemlidirler. Zamandan tasarruf etmeye çalışmıyoruz, tüm katılımcılarla konuşuyoruz, kişiyi eleştirmiyoruz, ancak eylemlerinin sonuçlarını değerlendiriyoruz (“kabasın” değil, “belki de adamlar bundan rahatsız olabilir) bu şey”), itibarı kurtarma fırsatı veriyoruz, tartışmaları sıra önünde değil, bizzat yürütüyoruz.
Çatışmalar genellikle iki nedenden birinden kaynaklanır. Birincisi, çatışma anında kişinin yetişkin konumunda mı, yoksa çocuk konumunda mı olduğuyla ilgilidir (bununla ilgili daha fazla bilgi aşağıdadır). Bunun nedeni duygusal olgunluğu, duygularını yönetme yeteneğidir (bu arada, bu her zaman yaşıyla ilgili değildir). İkinci ortak neden ise sorumluluğun katılımcılar arasında dağıldığı, tarafların beklentilerinin birbirine karşı şeffaf olmadığı ve süreçteki rollerin bulanıklaştığı gri alanlar durumları yaratan iş sürecinin kusurlu olmasıdır.
Buna göre, bir çatışmayı (ve diğer herhangi bir konuyu) çözerken yöneticinin üç perspektifi aklında tutması gerekir: kısa vadeli - sorunu/çatışmayı burada ve şimdi çözmek, orta vadeli - başka bir çatışmanın ortaya çıkma olasılığını en aza indirmek aynı nedenden dolayı ve uzun vadede - ekip kişisinde yetişkin kültürünü geliştirmek.
Her birimizin içimizde yaklaşık üç ya da dört yaşında bir çocuğu vardır. İşyerinde çoğu zaman uyuyor ama bazen uyanıp kontrolü ele alıyor. Çocuğun kendi öncelikleri vardır. Buranın kendi sanal alanı olduğu, annesinin onu daha çok sevdiği, makinesinin en iyisi olduğu (tasarımın en iyisi olduğu, en iyi programladığı, ...) konusunda ısrar etmesi onun için önemlidir. Bir çatışma durumunda çocuk oyuncaklara basabilir, ayağını yere vurabilir ve spatulasını kırabilir ancak yetişkinlerin sorunlarını çözemez (çözüm mimarisi, otomatik test yaklaşımları, çıkış tarihleri vb.), faydalar açısından düşünmez takım için. Çatışma içindeki bir çocuk, yetişkinini aramasını isteyerek cesaretlendirilebilir, teselli edilebilir ve yatağa gönderilebilir. Bir çatışma durumunda tartışmaya başlamadan önce, bir çocukla değil bir yetişkinle konuştuğunuzdan ve kendinizin bir yetişkin konumunda olduğundan emin olun. Şu anda dürüst hedefiniz ciddi bir sorunu çözmekse, bir yetişkin konumundasınız demektir. Amacınız ayaklarınızı yere vurmak ve kürek kemiğinizi kırmaksa bu çocukça bir pozisyondur. İçinizdeki çocuğu yatağına gönderin ve bir yetişkini arayın ya da tartışmayı yeniden planlayın. Kişi duygusal bir karar verir ve ardından bunun için rasyonel bir gerekçe arar. Bir çocuğun önceliklerine göre vereceği bir karar optimal olmayacaktır.
Çatışma anındaki davranışına ek olarak, bir çocuğun veya yetişkinin konumu aynı zamanda kişinin üstlenmeye hazır olduğu sorumluluk düzeyiyle de karakterize edilir. Birden fazla kez tanıştığım programcının çocuksu konumu, aşırı tezahürlerinde şuna benziyor: Kodu yazdım, incelemeye gönderdim - işim bitti. Gözden geçirenler bunu incelemeli ve onaylamalı, QA kontrol etmeli, sorunlar varsa bana bildirecekler. İşin garibi, oldukça olgun ve deneyimli insanlar bile bazen bu şekilde davranırlar. Ölçeğin diğer ucu ise kişinin kodunun çalışmasını, testlere tabi tutulmasını, kendisi tarafından bizzat kontrol edilmesini, incelemeyi başarıyla geçmesini (gerekirse inceleyenlere ping atılmasında, konuların tartışılmasında) sağlanmasından kendisini sorumlu görmesidir. sesli vb.) ve bastırılmışsa, QA gerekirse yardım sağlayacaktır, test senaryoları açıklanacaktır, vb. Normal durumlarda, programcı ya ölçeğin yetişkin sınırına yakın bir yerden başlar ya da deneyim kazandıkça oraya doğru hareket eder (ekip içinde doğru kültürün geliştirilmesi şartıyla). Aşırı durumlarda, genellikle çocukça bir tavır alarak çalışmaya devam eder, ardından kendisi ve ekibi periyodik olarak sorunlar ve çatışmalar yaşar.
Bir takımda doğru ve olgun kültürü teşvik etmek her yönetici için önemli bir görevdir. Uzun zaman ve günlük çaba gerektirir, ancak sonuç buna değer. Ekip kültürünü etkilemenin iki yolu vardır: örnek olarak liderlik etmek (buna kesinlikle uyulacaktır; ekip her zaman lidere bakar) ve doğru davranışı tartışıp ödüllendirmek. Burada da anlaşılması güç ya da çok resmi bir şey yok, sadece sorunları tartışırken, burada bir şeyler yapılmış olabileceğine dikkat edin, doğru karar verildiğinde bunu fark ettiğinizi vurgulayın, övgü, sürüm incelemesi sırasında not alın vb.
Basitten karmaşığa doğru birkaç tipik çatışma durumunu ele alalım:
İş sorunlarıyla ilgili olmayan çatışmalar
İşyerinde sıklıkla işle ilgili konularla ilgili olmayan çatışmalar yaşanır. Bunların ortaya çıkması ve çözüm kolaylığı genellikle katılımcıların duygusal zeka düzeyiyle, olgunluk düzeyleriyle doğrudan ilişkilidir ve iş sürecinin mükemmelliği veya kusuruyla ilgili değildir.
Tipik örnekler: Birisi çamaşır makinesini veya duşu yeterince sık kullanmıyor, diğerleri bundan hoşlanmıyor, birisi havasız, diğerleri pencereyi açtığında rüzgara maruz kalıyor, biri çok gürültülü ve diğerleri çalışmak için sessizliğe ihtiyaç duyuyor ve yakında. Bu tür çatışmaların çözümünü geciktirmemek ve kendi yollarına gitmelerine izin vermemek daha iyidir. Kendi başlarına çözülmeyecekler ve sizi her gün işten uzaklaştıracak ve takımdaki atmosferi zehirleyecekler. Neyse ki, bunları çözmek genellikle büyük bir sorun değildir - hijyeni ihmal eden bir meslektaşınızla sakin bir şekilde (elbette bire bir) konuşun, sessizliği/serinliği tercih eden insanlar için rahat oturma yerleri sağlayın, ses emici kulaklıklar satın alın veya bölmeler takın. , vesaire.
Çalışmalarım sırasında defalarca karşılaştığım bir diğer örnek ise ekip üyelerinin psikolojik uyumsuzluğudur. Bazı nedenlerden dolayı insanlar birlikte çalışamıyor; her etkileşim bir skandalla sonuçlanıyor. Bazen bunun nedeni, insanların bazı acil konularda (genellikle politik) kutupsal görüşlere sahip olmaları ve onları iş dışında nasıl bırakacaklarını bilmemeleridir. Onları birbirlerine hoşgörü göstermeye veya davranışlarını değiştirmeye ikna etmek oldukça nafile bir iştir. Karşılaştığım tek istisna, algıları açık olan genç meslektaşlarım; onların davranışları hala periyodik konuşmalar yoluyla kademeli olarak değiştirilebiliyor. Genellikle sorun, onları farklı ekiplere ayırarak veya en azından çok nadiren iş yerinde çakışma fırsatı sağlayarak başarılı bir şekilde çözülür.
Yukarıdaki durumların hepsinde, tüm katılımcılarla kişisel olarak konuşmak, durumu tartışmak, bu durumda bir sorun görüp görmediklerini sormak, onlara göre çözümlerin neler olduğunu sormak ve bunun yapılmasına katılımlarını sağlamak faydalı olacaktır. karar.
İş sürecini optimize etme açısından (bahsettiğim orta vadeli perspektif) burada yapılabilecek pek bir şey yok; optimizasyon için tek nokta, ekip oluştururken uyumluluk faktörünü dikkate almak ve insanları bir kenara koymak değil. kimin çatışacağını önceden birlikte.
Ekip kültürü perspektifinden bakıldığında bu tür durumlar, insanların ekibe ve meslektaşlarına saygı duyduğu ve sorunları bağımsız olarak nasıl çözeceklerini bildikleri olgun bir kültüre sahip ekiplerde çok daha az sıklıkta ortaya çıkar. Ayrıca güvenin yüksek olduğu, insanların uzun süre birlikte çalıştığı ve/veya iş dışında sıklıkla iletişim kurduğu ekiplerde bu tür çatışmalar çok daha kolay (çoğunlukla otomatik olarak) çözümlenir.
İş sorunlarıyla ilgili çatışmalar:
Bu tür çatışmalar genellikle aynı anda hem duygusal (katılımcılardan birinin yetişkin konumunda olmaması) hem de çalışma sürecinin kusurlu olmasından kaynaklanır. Belki de karşılaştığım en yaygın çatışma türü, geliştiriciler arasındaki kod incelemeleri veya mimari tartışmaları sırasındaki çatışmalardır.
Burada iki tipik durumu vurgulayacağım:
1) İlk durumda geliştirici bir meslektaşından kod incelemesi alamaz. Yama incelenmek üzere gönderilir ve hiçbir şey olmaz. İlk bakışta iki taraf arasında bariz bir çatışma yok ama düşündüğünüzde bu oldukça büyük bir çatışma. İş sorunu çözülmedi, taraflardan biri (incelemeyi bekleyen) bariz bir rahatsızlık yaşıyor. Bu durumun aşırı bir alt türü, bir toplulukta veya farklı ekiplerdeki gelişmelerdir; incelemeyi yapan kişi yükleme veya diğer koşullar nedeniyle bu özel kodla ilgilenmeyebilir, inceleme talebine hiç dikkat etmeyebilir ve harici hakem (her iki tarafta ortak bir yönetici) hiç mevcut olmayabilir.
Böyle bir durumda yardımcı olacak çözüm yaklaşımı tam olarak uzun vadeli bakış açısıyla, yetişkinin kültürüyle ilgilidir. İlk olarak akıllı aktivite işe yarıyor. İncelemede asılı olan kodun, incelemeyi yapan kişinin dikkatini çekmesini beklememelisiniz. Eleştirmenlerin onu fark etmesine yardımcı olmalıyız. Pingani'de birkaç kişi senkopla ilgili soru soruyor, tartışmalara katılıyor. Açıkçası, önemsizliğin yardımdan çok zarar vermesi muhtemeldir, sağduyunuzu kullanmanız gerekir. İkincisi, ön hazırlık iyi sonuç verir. Ekip ne olduğunu ve neden bu kodun gerekli olduğunu anlarsa, tasarım herkesle önceden tartışılır ve üzerinde anlaşmaya varılırsa, insanların bu koda dikkat etme ve onu iş için kabul etme olasılığı daha yüksektir. Üçüncüsü, otorite çalışır. Eğer gözden geçirilmek istiyorsanız, kendiniz birçok inceleme yapın. Gerçek kontroller, gerçek testler ve faydalı yorumlarla yüksek kaliteli incelemeler yapın. Takma adınız ekipte iyi biliniyorsa kodunuzun fark edilme olasılığı daha yüksektir.
İş akışı açısından bakıldığında, buradaki olası iyileştirmeler, geliştiricinin kendisinin ve ekibinin hedeflerine ulaşmasına yardımcı olmayı amaçlayan doğru önceliklendirmedir (diğerlerini gözden geçirmek, topluluğa mektup yazmak, koda bir mimari açıklamayla eşlik etmek, dokümantasyon, testler, tartışmalara katılmak) topluluk vb.), yamaların kuyrukta çok uzun süre asılı kalmasını önleyin vb.
2) Kod veya tasarım incelemeleri sırasındaki ikinci yaygın çatışma durumu, teknik konular, kodlama stili ve araç seçimi konusundaki farklı görüşlerdir. Bu durumda büyük önem taşıyan, aynı ekibe ait olan katılımcılar arasındaki güven düzeyi ve birlikte çalışma deneyimidir. Katılımcılardan biri çocuksu bir pozisyon aldığında ve muhatabın kendisine iletmek istediğini duymaya çalışmadığında çıkmaz sokak ortaya çıkar. Çoğu zaman, hem diğer tarafın önerdiği yaklaşım hem de başlangıçta önerilen yaklaşım başarılı bir şekilde işe yarayabilir ve prensipte hangisini seçeceğiniz önemli değildir.
Bir gün ekibimden bir programcı (ona Pasha diyelim), komşu departmandaki meslektaşlarımız tarafından geliştirilen ve desteklenen paket dağıtım sistemindeki değişiklikleri içeren bir yama hazırladı. Bunlardan birinin (Igor), paketleri dağıtırken Linux hizmetlerinin tam olarak nasıl yapılandırılması gerektiği konusunda kendi güçlü fikri vardı. Bu görüş yamada önerilen yaklaşımdan farklıydı ve anlaşamadılar. Her zamanki gibi son teslim tarihleri bitiyordu ve bir tür karara varmak gerekiyordu; içlerinden birinin yetişkin pozisyonu alması gerekiyordu. Paşa, her iki yaklaşımın da yaşam hakkı olduğunu kabul etti ancak bu seçeneğin kabul edilmesini istedi çünkü Ne birinin ne de ikinci seçeneğin belirgin bir teknik avantajı yoktu.
Tartışmamız şuna benziyordu (çok şematik olarak elbette konuşma yarım saat sürdü):
-Paşa, birkaç gün içinde özellik dondurmamız var. Her şeyi bir araya toplayıp mümkün olan en kısa sürede teste başlamamız önemlidir. Igor'u nasıl aşabiliriz?
— Hizmetleri farklı ayarlamak istiyor, benim için yorumları oraya yapıştırdı...
- Peki ne var, büyük değişiklikler mi, bir sürü yaygara mı?
- Hayır birkaç saatlik çalışma var ama sonuçta hiçbir fark yok, her iki şekilde de işe yarayacak, bu neden gerekli? İşe yarayan bir şey yaptım, kabul edelim.
- Dinle, ne zamandır bunları tartışıyorsun?
- Evet, bir buçuk haftadır zamanı değerlendiriyoruz.
- Hımm... zaten bir buçuk hafta süren bir sorunu birkaç saat içinde çözebilir miyiz?
- Evet ama Igor'un pes ettiğimi düşünmesini istemiyorum...
- Dinle, senin için hangisi daha önemli, içerideki kararınla birlikte bir açıklama yapmak mı, yoksa Igor'u öldürmek mi? Bunu engelleyebiliriz, ancak serbest bırakıldığında uçup gitme şansımız yüksektir.
- Şey... elbette Igor'un burnunu silmek harika olurdu, ama tamam, serbest bırakılması daha önemli, katılıyorum.
- Igor'un ne düşündüğü senin için gerçekten bu kadar önemli mi? Dürüst olmak gerekirse, hiç umurunda değil, sadece sorumlu olduğu şeyin farklı yerlerinde birleşik bir yaklaşım istiyor.
- Peki, yorumlarda istediğini yapayım ve teste başlayalım.
- Teşekkür ederim Paşa! Igorek senden daha büyük olmasına rağmen ikinizden daha olgun olacağından emindim :)
Sorun çözüldü, yayın zamanında yayınlandı, Paşa pek memnuniyetsizlik hissetmedi çünkü kendisi bir çözüm önerdi ve uyguladı. Igor genel olarak memnundu çünkü... Onun fikri dikkate alındı ve onun önerdiği gibi yaptılar.
Esasen aynı çatışmanın bir başka türü de, özellikle dağıtılmış bir ekipte, bir projede teknik çözümler/kütüphaneler/yaklaşımlar arasındaki seçimdir. C/C++ kullanılacak şekilde konumlandırılan projelerden birinde, projenin teknik yönetiminin STL (Standart Şablon Kütüphanesi) kullanımına kategorik olarak karşı olduğu ortaya çıktı. Bu, geliştirmeyi kolaylaştıran standart bir dil kütüphanesidir ve ekibimiz buna çok alışkındır. Projenin C++'dan çok C'ye yakın olduğu ortaya çıktı, bu da ekibe pek ilham vermedi çünkü yönetim ellerinden geleni yaptı ve gerçekten harika artı oyuncuları işe aldı. Aynı zamanda ekibin hem mühendis hem de yönetici olan Amerikalı kısmı uzun süredir şirkette çalışıyordu, mevcut duruma alışmıştı ve her şeyden memnundu. Ekibin Rus kısmı yakın zamanda, birkaç hafta içinde (ben de dahil) bir araya getirildi. Ekibin Rus kısmı kategorik olarak olağan gelişim yaklaşımından vazgeçmek istemedi.
İki kıta arasında sonsuz yazılı tartışmalar başladı, programcılardan programcılara ve yöneticilere, üç veya dört ekrandaki mektuplar, grup postaları ve kişisel postalar halinde ileri geri uçtu. Genellikle olduğu gibi bu uzunluktaki mektuplar, yazarlar ve onların ateşli destekçileri dışında kimse tarafından okunmadı. Sohbetler gerginlikle gıcırdadı, STL'nin teknik avantajları, ne kadar iyi test edildiği, ne kadar güvenli olduğu ve genel olarak onunla hayatın ne kadar harika ve onsuz ne kadar korkunç olduğu konusunda çoklu ekran düşünceleri farklı yönlere aktarıldı .
Bütün bunlar oldukça uzun sürdü, ta ki sonunda konunun teknik yönlerini tartıştığımızı fark edene kadar, ancak sorunun gerçekte teknik olmadığını fark ettim. Sorun STL'nin avantajları veya dezavantajları ya da onsuz çalışmanın zorluğu değil. Sorun oldukça organizasyonel. Sadece çalıştığımız şirketin nasıl çalıştığını anlamamız gerekiyordu. Hiçbirimizin daha önce böyle bir şirkette çalışma tecrübesi yoktu. Mesele şu ki, kod geliştirilip üretime sunulduktan sonra destek, diğer ekiplerden ve diğer ülkelerden tamamen farklı kişiler tarafından gerçekleştirildi. Onbinlerce mühendisten oluşan bu devasa mühendislik ekibi (toplamda), yalnızca tamamen temel bir minimum teknik araç, tabiri caizse minimum bir minimum miktarı karşılayabiliyordu. Şirkette fiziksel olarak oluşturulan mühendislik standardının ötesine geçen hiçbir şeyin gelecekte desteklenmesi mümkün değildi. Bir takımın seviyesi, en zayıf üyelerinin seviyesine göre belirlenir. Biz anladıktan sonra gerçek motivasyon Ekibin Amerikalı kısmının da harekete geçmesiyle bu konu gündemden çıkarıldı ve ürünü şirketin benimsediği standartları kullanarak başarıyla geliştirip piyasaya sürdük. Bu durumda mektuplar ve sohbetler pek işe yaramadı; ortak bir paydaya varmak için birkaç gezi ve çok sayıda kişisel iletişim gerekti.
İş akışı açısından bakıldığında, bu özel durumda, kullanılan araçların bir açıklamasının, bunlara yönelik gereksinimlerin, yenilerinin eklenmesine ilişkin kısıtlamaların ve bu tür kısıtlamaların gerekçelerinin bulunması yardımcı olacaktır. Bu tür belgeler kabaca, XNUMX'da geliştirilen “Yazılım Geliştirme için Yönetici El Kitabı”nın Yeniden Kullanım Stratejisi ve Geliştirme Ortamı paragraflarında açıklananlara karşılık gelir. . Yaşına rağmen bu tür yazılım geliştirmenin tüm ana faaliyetlerini ve planlama aşamalarını mükemmel bir şekilde tanımlamaktadır. Bunun gibi belgelere sahip olmak, bir üründe hangi bileşenlerin ve yaklaşımların kullanılabileceğini ve nedenini tartışmayı çok kolaylaştırır.
Kültürel bir bakış açısıyla, tabii ki, tarafların meslektaşlarının eylemlerinin gerçek motivasyonunu duymaya ve anlamaya çalıştığı ve kişisel egoya değil, projenin ve ekibin önceliklerine göre hareket ettiği daha olgun bir konumla. , çatışma daha kolay ve daha hızlı çözülecektir.
Teknik bir çözümün seçimiyle ilgili başka bir anlaşmazlıkta, taraflardan birinin motivasyonunu anlamam da kayda değer bir zaman aldı (bu çok alışılmadık bir durumdu), ancak motivasyon netleştikten sonra çözüm de belli oldu.
Durum şu: Yaklaşık 20 kişilik bir ekipte yeni bir geliştirici ortaya çıkıyor, ona Stas diyelim. O zamanlar ekip olarak standart iletişim aracımız Skype'tı. Daha sonra ortaya çıktığı üzere Stas, açık standartların ve açık kaynaklı yazılımların büyük bir hayranıydı ve yalnızca kaynakları kamuya açık olan ve kamuya açıklanmış protokolleri kullanan araçları ve işletim sistemlerini kullanıyordu. Skype bu araçlardan biri değil. Bu yaklaşımın avantajlarını ve dezavantajlarını tartışmak için çok zaman harcadık, farklı işletim sistemlerinde Skype analoglarını başlatma girişimleri, Stas'ın ekibi diğer standartlara geçmeye ikna etme girişimleri, ona kişisel olarak posta yoluyla yazma, onu şahsen arama telefon edin, ona özellikle Skype için ikinci bir bilgisayar satın alın, vb. Sonunda, bu sorunun özünde teknik veya örgütsel olmadığını, daha ziyade ideolojik, hatta dini bile söylenebilir (Stas için). Sonunda Stas ve Skype'ı bağlasak bile (ki bu birkaç ay sürdü), sorun daha sonraki herhangi bir cihazda tekrar ortaya çıkacaktı. Stas'ın dünya görüşünü değiştirmek için elimde hiçbir gerçek araç yoktu ve bu ortamda mükemmel bir şekilde çalışan bir ekibin dünya görüşünü değiştirmeye çalışmak için hiçbir neden yoktu. Kişi ve şirket dünya görüşlerinde tamamen birbirine dikti. Bu gibi durumlarda iyi bir çözüm organizasyoneldir. Stas'ı daha organik olduğu başka bir takıma transfer ettik.
Bana göre bu çatışmanın nedeni, belirli bir kişinin (uzlaşmasına izin vermeyen güçlü bir görüşe sahip olan) kişisel kültürü ile şirket kültürü arasındaki tutarsızlıktır. Bu durumda elbette yöneticinin hatası var. Onu bu tür bir projeye almak başlangıçta yanlıştı. Stas sonunda açık kaynaklı bir yazılım geliştirme projesine geçti ve orada başarılı oldu.
Hem geliştiricinin çocuksu tutumundan hem de iş sürecindeki eksikliklerden kaynaklanan çatışmaya iyi bir örnek, yapılan tanımının yokluğunda geliştirici ve QA ekibinin hazır olma konusunda farklı beklentilere sahip olduğu bir durumdur. özellik QA'ya aktarıldı. Geliştirici, kodu yazmanın ve özelliği QA'ya atmanın yeterli olduğuna inanıyordu; sorunu orada çözeceklerdi. Bu arada oldukça olgun ve deneyimli bir programcıydı ama bu onun kaliteye yönelik içsel eşiğiydi. QA buna karşı çıktı ve kendisinin kontrol ettiği şeyleri onlara gösterip açıklamayı talep etti ve onlar için bir test senaryosu talep etti. Geçmişte bu geliştiricinin işlevselliğiyle ilgili sorunlar yaşamışlardı ve tekrar zamanlarını boşa harcamak istemiyorlardı. Bu arada haklıydılar; özellik gerçekten işe yaramadı; kodu QA'ya göndermeden önce kontrol etmedi.
Durumu çözmek için ondan bana her şeyin gerçekten işe yaradığını göstermesini istedim (işe yaramadı ve düzeltmesi gerekiyordu), ekiple konuştuk ve QA'nın tamam tanımıyla konuştuk (başaramadılar) Yazma, çünkü süreci fazla bürokratik hale getirmek istemedik), kısa süre sonra bu uzmanla yollarımızı ayırdık (genel rahatlama için).
İş akışı açısından bakıldığında, bu durumda olası iyileştirmeler, yapılan bir tanımın, her birim özelliğinin desteklenmesine yönelik gereksinimlerin ve entegrasyon testlerinin ve geliştirici tarafından gerçekleştirilen testlerin bir açıklamasının bulunmasıdır. Projelerden birinde kod kapsamı düzeyini CI sırasındaki testlerle ölçtük ve kapsam düzeyi bir yama ekledikten sonra düşerse testler başarısız olarak işaretlendi; herhangi bir yeni kod ancak bunun için yeni testler olması durumunda eklenebiliyordu.
İş sürecinin organizasyonuyla yakından ilgili bir çatışmanın başka bir tipik örneği. Bir ürünümüz, ürün geliştirme ekibimiz, destek ekibimiz ve bir müşterimiz var. Müşterinin ürünle ilgili sorunları var ve destek ekibiyle iletişime geçiyor. Destek, sorunu analiz ederek sorunun üründe olduğunu anlar ve sorunu ürün ekibine aktarır. Ürün ekibi yoğun bir dönemden geçiyor, bir sürüm yaklaşıyor, bu nedenle bir müşteriden kaynaklanan sorun içeren bir destek bildirimi, kendisine atanan geliştiricinin diğer bildirimleri arasında kayboluyor ve birkaç hafta boyunca dikkat edilmeden askıda kalıyor. Destek, geliştiricinin müşterinin sorunu üzerinde çalıştığını düşünüyor. Müşteri bekler ve sorununun çözüleceğini umar. Gerçekte henüz hiçbir şey olmuyor. Birkaç hafta sonra müşteri nihayet ilerlemeyle ilgilenmeye karar verir ve işlerin nasıl gittiği konusunda destek ister. Destek gelişme ister. Geliştirici ürperir, bilet listesine bakar ve orada müşteriden bir bilet bulur. Bir müşteriden gelen bileti okuduğunda, sorunu çözmek için yeterli bilgi olmadığını ve daha fazla kayıt ve dökümlere ihtiyacı olduğunu anlıyor. Destek müşteriden ek bilgi talep eder. Ve sonra müşteri, bunca zamandır kimsenin sorunu üzerinde çalışmadığını fark ediyor. Ve gök gürültüsü çarpacak...
Bu durumda, çatışmanın çözümü oldukça açık ve doğrusaldır (ürünü düzeltmek, belgeleri ve testleri güncellemek, müşteriyi memnun etmek, bir düzeltme yayınlamak vb.). İş sürecini analiz etmek ve iki ekip arasındaki etkileşimi organize etmekten kimin sorumlu olduğunu ve bu durumun ilk etapta neden mümkün olduğunu anlamak önemlidir. Süreçte neyin düzeltilmesi gerektiği açıktır; birisinin genel resmi müşterilerden gelen hatırlatmalar olmadan proaktif bir şekilde izlemesi gerekir. Müşteriden gelen biletler, geliştiricilerden gelen diğer biletler arasında öne çıkmalıdır. Destek, geliştirme ekibinin şu anda bildirimleri üzerinde çalışıp çalışmadığını, çalışmıyorsa ne zaman çalışmaya başlayabileceğini ve sonuçların ne zaman beklenebileceğini görmelidir. Destek ve geliştirme periyodik olarak iletişim kurmalı ve biletlerin durumunu tartışmalı, hata ayıklama için gerekli bilgilerin toplanması mümkün olduğunca otomatikleştirilmelidir, vb.
Tıpkı savaşta düşmanın iki birim arasındaki kavşağı vurmaya çalışması gibi, işte de en hassas ve savunmasız nokta genellikle ekipler arasındaki etkileşimdir. Destek ve geliştirme yöneticileri yeterince yaşlıysa, süreci kendileri düzeltebileceklerdir; değilse, durumu düzeltebilecek bir yönetici müdahale edene kadar süreç çatışmalar ve sorunlar üretmeye devam edecektir.
Farklı firmalarda defalarca karşılaştığım bir diğer tipik örnek ise bir ürünün bir ekip tarafından yazılması, otomatik entegrasyon testlerinin ikinci bir ekip tarafından yazılması ve üzerinde çalıştırıldığı altyapıya üçüncü bir ekip tarafından eşlik edilmesi durumudur. takım. Testleri çalıştırırken sorunlar her zaman ortaya çıkar ve sorunların nedeni hem ürün hem de testler ve altyapı olabilir. Sorunların ilk analizini, dosya hatalarını, ürünün ayrıştırma günlüklerini, testleri ve altyapıyı vb. kimin yapması gerektiği konusunda anlaşmaya varmak genellikle sorunludur. Burada çatışmalar çok sık yaşanıyor ve aynı zamanda tekdüze. Duygusal yoğunluğun yüksek olması durumunda, katılımcılar genellikle çocuksu bir pozisyona düşerler ve dizi halinde tartışmalar başlar: "neden bununla uğraşayım", "daha sık bozuluyorlar" vb.
İş akışı açısından bakıldığında, bir sorunu çözmeye yönelik belirli adımlar ekiplerin bileşimine, testlerin ve ürünün türüne vb. bağlıdır. Projelerden birinde ekiplerin testleri hafta hafta teker teker takip ettiği periyodik görevi uygulamaya koyduk. Diğerinde, ilk analiz her zaman test geliştiricileri tarafından yapıldı, ancak analiz çok basitti ve ürün oldukça stabildi, bu yüzden iyi çalıştı. Önemli olan sürecin şeffaf olmasını, beklentilerin tüm taraflar için net olmasını ve durumun herkese adil gelmesini sağlamaktır.
Çatışma bir organizasyonda bir sorun mu? Ekibinizde çatışmaların sık sık (veya sadece periyodik olarak) ortaya çıkması kötü bir işaret mi? Genel olarak hayır, çünkü büyüme, gelişme varsa, bir tür dinamik varsa, o zaman daha önce çözülmemiş sorunlar ortaya çıkar ve bunları çözerken çatışmalar ortaya çıkabilir. Bu bazı alanlara dikkat edilmesi gerektiğinin, geliştirilecek alanların olduğunun göstergesidir. Çatışmaların çok sık ortaya çıkması, çözülmesinin zor olması veya uzun sürmesi kötüdür. Bu büyük ihtimalle iş süreçlerinin yeterince düzenlenmediğinin ve ekibin yetersiz olgunluğunun bir işaretidir.
Kaynak: habr.com