Ekiplerde Güven – 3

Ekiplerde Güven – 3

Ekiplerdeki güven sorunu ile ilgili bulgulara ve çözüm önerilerine kaldığımız noktadan devam etmek istiyorum. Önceki yazımızda ekip üyelerinin birbirine yardımcı olmamasının ve önyargılarının etkisinden bahsetmiştik. Ekiplerdeki diğer bir problem ise ekip üyelerinin birbirlerinin deneyimlerinden yararlanmamasıdır.

Ekip üyeleri birbirlerinin deneyimlerinden yararlanmazlar

Proje ekiplerindeki kişilerin geçmişte yapmış oldukları işlerden dolayı yüklü bir deneyimleri bulunur. Deneyimin derecesi göreceli bir kavramdır. Bazılarının yaş ile ölçmeye çalıştığını görmekteyiz. Kısmen doğru olsa da işin içine teknoloji girdiği zaman yaş, deneyime negatif etki yapabilir. Deneyim için, benzer iş alanında geçmişte karşılaşılmış sorunlar ve bunların çözüm yöntemleri hakkında bilgi sahibi olmak diyebiliriz. Proje ekibinde bulunan herkesin farklı konularda farklı deneyimleri olabilir. Bazı deneyimler doğru çözümü bulmaya yardımcı olurken, bazı deneyimler de yanlış yöntemlere yönelmeyi engellemeye yönelik olabilir. Bir projede ne yapacağınızı bilemediğiniz durumlarda ne yapmayacağınızı bilmek de önemli bir kazanımdır.

Projelerde elde edilen deneyimleri veya öğrenilmiş dersleri bir veritabanında kayıt altına alarak ilerideki projelerde faydalanmak için saklamak en iyi yöntemdir. Fakat, bunu tam olarak gerçekleştirmenin zorlukları vardır. Teknolojik altyapı gereksinimi, güncel tutabilme, paylaşabilme ve doğru deneyimleri eksiksiz elde edebilme şeklinde zorluklardan bahsedebiliriz. Herşey sağlanmış olsa bile deneyim sahiplerinin böylesine açık bir ortamda deneyimlerini paylaşmak istememesi veya çekincesi durumu da oluşabilir. Bu nedenle proje ekibinin deneyim düzeyi konusunda belirli bir ölçü tanımlamak zordur.

 

Birbirine güvenmeyen proje ekiplerinde birbirlerinin deneyimlerinden faydalanma konusunda da sıkıntılar yaşanır. İlk başta deneyimli kişinin deneyimleri konusunda şüpheler oluşur. Öyle ki, ekip üyeleri belli bir konuda diğer ekip üyelerini tamamen deneyimsizlikle suçlayabilirler. Bazen de deneyimin farkında olunmasına rağmen deneyim sahibi kişiden yardım istemek yerine deneme yanılma yöntemi tercih edilir. Bunun nedeni ise , önceki yazılarımda belirttiğim üzere önyargıdır. Deneyimli kişinin deneyimi konusunda önyargı oluşmuştur. Başka bir neden ise deneyim sahibi kişinin sürekli olarak her durumda geçmiş deneyimlerini ortaya koyarak etki alanı oluşturmaya çalışmasıdır. Bu durumda ister istemez deneyim sahibine karşı bir muhalefet oluşacaktır. Çünkü, deneyimlerini paylaşmak adına bir anlamda gösteri sergilenmektedir, beklenti amacından uzaklaşmaktadır.

Birbirine güvenen ekiplerde ekip üyeleri deneyimlerini paylaşmak konusunda istekli olurlar. Deneyim sahibi kişiden olabildiğince yararlanılmaya çalışılır ve ilgili kişi takdir edilir. Deneyim sahibi kişiler de deneyimlerine dayalı bir nüfuz oluşturma gayreti içinde olmazlar. Deneyimlerini ekibin çıkarlarına uygun olarak paylaşırlar. Aynı zamanda bilgili olmadıkları alanlarda da diğer kişilerin deneyimlerine başvururlar. Her ekip üyesi diğer üyelerin deneyimlerine saygılıdırlar. Gelişmiş proje ekiplerinde, ortaya çıkan deneyimlerden herkesin faydalanabilmesi için paylaşım ortamları yaratılır. Bu kimi zaman sosyal paylaşım sitesi olabilir, kimi zaman da şirket için portal yapılarıdır. Böylece kişilerin öğrendikleri dersleri veya faydalı kazanımları paylaşma imkanı yaratılır. Bilgiye erişim için kişilere soru sorma veya bilen kişileri aramak gibi zaman kaybına yol açacak darboğazlar ortadan kaldırılmıştır. Böylece deneyim sahibi de deneyimlerinden başkaları da faydalandığı için gurur duyacağı bir çalışmanın ortak paydası olur.

Ekip üyeleri birbirlerine kin beslerler

Ekip içerisinde zaman zaman tartışmalar olabilmektedir. Hatta, tartışmaların olması faydalıdır. Böylece ekip üyeleri sorunları derinlemesine tartışarak kalıcı çözümler üretme şansı bulurlar. Ancak bu fayda, tartışmaların amacından sapmadan, kişisel kavgalara veya küskünlüklere yol açmaması durumunda sağlanabilir. Eğer ekip üyelerinde güven sorunu yaşanıyorsa, tartışmalar kişisel hesaplaşmalara dönüşecektir. Sorunu çözmek yerine yeni sorunlar yaratmaya yol açacaktır. Bir süre sonra tartışma kişisel hesaplaşmaya gidecektir. Tartışmanın tarafları birbirini yanlış anlayacak, söylenilenleri kişiselleştirecek ve birbirlerinden hesap sormak için fırsat arayacaklardır.

Tartışmalar, toplantı zamanı içerisinde kalmalı ve sonuca bağlanmalıdır. Sonuçlanmayan, kırgınlık yaratan tartışmaların ardından ekip üyeleri birbirlerine kin beslemeye başlayacaklardır. Bazıları bir sonraki toplantıda -sözde- rakibini mağlup edecek gerekçeler ve iddialar ortaya koyma çabası içine girecektir. Bazıları da kendilerini tartışmanın galibi ilan edecek ve çevresinde övgüyle bu -sözde- başarılarından bahsedeceklerdir. Tartışmanın dışında bulunan ekip üyeleri ise kendi kriterlerine uygun olarak bir taraftan yana olacaklardır. Bir süre sonra galibi ve mağlubu asla belli olmayan bir kör dövüşünün içinde bulunacaklardır. Durumu toparlamaya çalışan bazı akl-ı selim kişiler ise bir süre sonra ekip üyeleri tarafından, çoğunlukla taraf tutma suçuyla suçlanmaya çalışılacaktır.

Kin beslemek için mutlaka sözel bir tartışmanın veya kavganın olması gerekmeyebilir. Birbirini yanlış anlayan ekip üyeleri kendi kendilerine sorun yaratıp, karşı taraf hakkında önyargılar oluşturacaktır. Bu önyargılara istinaden zamanla birbirlerine kin besleyeceklerdir. Eğer bu yanlış düşünceler düzeltilmezse ekip üyeleri, haklı oldukları noktalarda bile karşı tarafı haksız görecektir. Bu arada üzerinde fırtınalar kopartılan sorun ise hala çözüm beklemektedir. Üstüne üstlük yeni sorunlar ortaya çıktığı için öncelik yeni sorunlara verileceğinden dolayı asıl çözümlenmesi gereken eski sorunlar unutulabilir.

 

Birbirine güvenen ekiplerde ekip üyeleri gerektiğinde özür dileyebilmelidir. Tartışmanın, projenin geleceği için yapıldığını bilip kişisel noktalara kaymamaya çalışırlar. Yanlış anlaşılmaların olduğu durumlarda doğrudan ilgili kişiyle konuşarak yanlışlıkları gidermeye çalışırlar. Sorunlar kin besleme aşamasına gelmeden çözümlenir veya çözümlenmesi için diğer ekip üyeleri çaba gösterirler.

 

Bu yazı ile proje ekiplerindeki güven konusundaki bulgular ve çözüm önerilerini noktalamış durumdayım. Güven kelimesinin proje ekipleri kapsamında ne kadar geniş bir kavram olduğunun altını çizmeye çalıştım. Güvenin sadece doğru söz söyleme ve hep aynı çizgide kalmanın ötesinde olduğunu ortaya koymuş durumdayız. Bununla birlikte proje ekipleri için çok önemli olan güven konusuna dikkat edilmesi ve güvenin tahsis edilmesi için öncelikle proje yöneticisinin çaba göstermesi beklenilmektedir. Aksi takdirde projenin başarısı olumsuz etkilenecektir. Birbirine güvenmeyen proje ekiplerinin iyi bir iş çıkarmaları ise oldukça zordur. Özellikle uzun soluklu işlerde böyle bir güvenin oluşması projenin başarısı için olmazsa olmaz bir gerekliliktir.

Yazılım böyle sattırılır :)

Dominant-Resesif

Dominant-Resesif

Geçmiş yıllarda yazdığım bir yazıyı tekrar paylaşmak istedim. Projede gereksinimleri yönetmek konusunda esprili bir senaryo içermektedir.

                     

Gereksinimleri elde ederken hem müşterinin hem de projeyi geliştiren ekibin uzlaşması en önemli bir beklentidir. Her iki tarafın da kazançlı çıktığı (win-win) ve mutlu oldukları bir durum, hem istenilen hem de çoğu zaman ütopik olan bir durumdur. Her ne kadar herkes kendisinin ödün verdiğini savunsa da bir taraf çoğunlukla baskın çıkmaktadır. Bu baskın olma durumuna çeşitli faktörler neden olur.

Birinde müşterinin, diğerinde ise analistin baskın olduğu iki hikaye ile olayı senaryolaştırdım.

Senaryo 1:

Toplantı başlamıştır ve müşteri tarafındaki Bay Dominant ile analistimiz Bay Resesif bir modülün ekran prototipleri üzerinde tartışmaktadırlar.

Bay Resesif rica eder bir tavırla:"Efendim, bu gereksinimi sisteme ekleyemeyiz, kaldıralım, ne dersiniz"

Bay Dominant:"yok yok kalsın"

Bay Resesif: "Ama o zaman kapsam genişliyor"

Bay Dominant: "Fazladan bunu da yapsanız ne olur canim"

Bay Resesif: "Efendim, gecen gün de başka bir gereksinim için ayni şeyi demiştiniz ama"

Bay Dominant: "Hatırladım, ama bu bizim için çok önemli"

Bay Resesif: "Sayın Bay Dominant, bu bize en az bir aylık iş demektir"

Bay Dominant: "Yaparsınız canim yaparsınız, senin yöneticin kimdi, istersen telefonunu ver de ona da anlatayım" -Burada Bay Dominant gözdağı vermektedir, aba altından sopa gösteriyor-

Bay Resesif: "Yöneticim de bunu kabul etmeyecektir, efendim"

Bay Dominant: "Kardeşim siz nasıl firmasınız, bundan öncekiler bizim her dediğimizi yapardı, bunu da siz yapacaksınız" -Aslında bundan önceki firmaya da ayni yöntemi uygulamışlardı da, paçalarını zor kurtarmışlardı-

Bay Resesif: "Olmaz efendim, size söz veremeyiz, bu şartnamede yoktu"

Bay Dominant:"Bu olmazsa ben bu sistemi kullanmam"

Bay Resesif: ???

Bay Dominant:"Sizden de bir şey istenmiyor, her şeye hayır, hayır"

Bay Resesif: ???

Bay Dominant:"Alin sisteminizi, sökün götürün, bu ne ya!"

Bay Resesif: "Bay Dominant, şey efendim"

Bay Dominant bu sırada sekreteri arayarak "kızım bana XXXX firmasından Emirkulu Derhal Bey'i bağlasana" der...

Sonuç bellidir, Bay Dominant'in istediği olmuştur.

Senaryo 2:

Toplantı başlamıştır ve müşteri tarafındaki Bayan Sinik ile analistimiz Bayan Lafebesi bir raporun görüntüsü üzerinde tartışmaktadırlar.

Bayan Sinik: "Lafebesi Hanım, su sütunun altına toplamları da yazdıralım mı?"

Bayan Lafebesi:"Ama onlar ayni cinsten değil, onları toplamak için ayrı bir prosicir yazmak lazım, eskuel içinde hem kaunt etmek gerek hem de sam yazacağım,...."

Bayan Sinik araya girerek "Lafebesi Hanım, onların hepsi para cinsinden, altı üstü toplama yapılmayacak mı?"

Bayan Lafebesi:"olsun ama bir bilseniz ne kadar kod yazılıyor onun için, tamam tamam yapalım"

Bayan Sinik: "Bir de raporu çalıştırırken önceki girdiğim parametreler tekrar ekrana gelse iyi olur"

Bayan Lafebesi:"olmaz, bu sistemde bu yetenek yok, onun için global veraybil tutacağım, her ekranda onu post edeceğim, hidın ile saklayarak eplikeyşın seviyesinde tutmam gerek"

Bayan Sinik: "tamam Bayan Lafebesi, o zor görünüyor onu yapmayın ama her seferinde kağıda çıktı almasak, bu raporu excel'e aktarabilsem de istediğim bicimde üzerinde oynayabilsem, ne bileyim yani excelde iyiyimdir"

Bayan Lafebesi:"Bayan Sinik, bunları neden projenin başında söylemiyorsunuz, bunun için yazılımın arkitekçırında değişiklik yapmak gerek, teybıllar ve indeksler değişecek, bunu yapmak zaman alır, siz şimdilik yazıcıdan almaya devam ediniz"

Bayan Sinik: "Bir de raporun başlıkları kalın ve kırmızı olsun, tepeye de raporun alındığı tarihi basabilir misiniz"

Bayan Lafebesi:"Sizin için renkleri değiştiririm ama tarih için yazılmış kodu değiştirmek lazım"

Bayan Sinik: "Ama Bayan Lafebesi hanım, daha geçen gün gereksinimleri alma aşamasındayız, programı sonra yazacağız demiştiniz"

Bayan Lafebesi:"doğru ama raporlar genelde standart olur diye kodunu yazıverdi yazılımcı arkadaşlar"

Bayan Sinik: "eee o zaman niye bana neden programda ne istiyorsunuz diye soruyorsunuz"

Bayan Lafebesi:"Bayan Sinik hanim, bunların dışında daha önemli şeyler var mı, bunları boş verin, size başka hangi raporlar gerekli"

Bayan Sinik: "yok, yok  başka istediğim bir rapor yok" diyerek konuşmayı bitirir.

Bayan Lafebesi mutludur, içinden şunu düşünür "oh be bundan da yırttık, bir iki yazılımcı  terminolojisi ve İngilizce kelimeyle rapor hazırladığımız haliyle kaldı"

                   

CMMI ve M&A

"CMMI modelini TITANIC gemisi gibi düşünürsek; Ölçme ve Analiz (M&A) süreç alanı da onu batıran BUZDAĞI'dır."