Yazının en sonunda söylemem gerekini en başta söylüyorum çünkü bu yazı ön yargılı ya da sadece ana fikirle ilgilenip nedenleri sorgulamayan okuyuculara göre değil ve gerisini okumak istemiyorlarsa gönül rahatlığıyla sayfayı kapatabilsinler. Ön yargınız varsa bu yazı (belki de tüm diğer yazılar) size hitap etmiyor ve ben ön yargıların sadece bir yazıyla (belki de pek çok farklı yöntemle çok uzun zaman) kıramayacağının bilincindeyim. Neyse fazla da uzatmadan ana fikri söyleyeyim : “Çok fazla çalışmak daha az tamamlanan işe neden olur!”
Bu cümle Jeff Sutherland’in “İki katı işi yarı zamanda yapma sanatı” isimli kitabından alıntıdır. Okumayanlar varsa şiddetle tavsiye ederim. Özellikle organizasyonların yapılarını doğrudan etkileyecek kararları alma yetkisi bulunan kişilerin mutlaka okuması gereken bir kitaptır. Jeff Sutherland kitabının bir bölümünde aşırı çalışmanın verdiği hasarları ve verimliliğe olumsuz etkisini anlatır. Ben bu yazıda konuyu biraz daha detaylandırmaya çalışacağım.
Halen pek çok organizasyonda fazla mesai olumlu bir perfermans kriteri olarak görülür. Pek çoğumuz yöneticilerimizden mesaiye kalmamız konusunda telkinler almışızdır. Çalışanların performansını bir iş üzerinde harcadığı zamanla ölçen firmaların sayısı azımsanamayacak kadar fazla. Hatta Agile dönüşümler yapmış kişilerden bile bu dönüşümlerde çalışanların bir iş üzerinde harcadığı zamanı tutacak uygulamalar ile kontrol koymaya çalıştıklarını ballandırarak anlatmalarına şahit oluyorum. Bir kişiyi övmek için “gece geç saatlerde bile mail atıyor”, “ne zaman gelsem ofiste” gibi cümleler fazla mesainin nasıl da olumlu bir şey olarak içselleştirildiğinin göstergesi. Fakat aşırı çalışmak pek çok araştırmaya göre verimliliği düşüren bir etken.
Peki neden daha az çalışarak daha kaliteli ve daha fazla tamamlanmış iş çıkarırız?
- Belki de en önemli etkenlerden bir tanesi, insanları sürekli ve aşırı çalışma temposuna zorlamanın insani olmamasıdır. İnsani olmayan her şey motivasyonu ve ürekenliği düşürür. İnsan yerine konulmayan kaç kişi severek işini yapabilir ki
- En önemli etkenlerden bir tanesi de daha fazla çalışarak harcadığımız eforun ciddi bir dikkat kaybına neden olmasıdır. İşte yapılan hatalar artar ve bu hataları düzeltmek için harcanan efor israfa neden olur. Yine bu hatalar organizasyondaki stres düzeyini yükseltebilir, ki stres hata ihtimalini daha da arttırır.
Bir futbol takımını yönetiyor olsanız, iyi bir futbol direktörü olmak için bilimsel çalışma yöntemlerini mi takip edersiniz yoksa sadece “çok çalışma” stratejisini mi benimsersiniz. Çok fazla kondisyon çalışması yapan takımlardaki sonuç güçsüzlük olduğuna göre etkileri pek hoş olmayacaktır. Ya da soruyu şöyle soralım: “takımınızı maça yorgun mu çıkarmak istersiniz yoksa dinlenmiş bir şekilde mi?”
- Daha fazla çalışma sonucu ortaya çıkan hataların düzeltilmesi daha çok işe ve bu işleri yetiştirmek için de kaliteden ödün vermeye neden olur. Bu nedenle yoğun çalışma baskısı kirli koda neden olur.
- Daha fazla çalışarak harcanan enerji karar alma kalitesini de doğrudan düşürecek bir etkiye sahiptir. Tüm 4 maddede birbirlerini olumsuz yönde beslerler. Bir organizasyondaki tüm yapısal ve kültürel özellikler birbirleriyle etkileşim halindedir. Hiçbir şey bir diğerinden bağımsız ya da tekbaşına düşünülemez. Aynı zamanda da organisyondaki tüm özellikler tek başlarına birer olgudur. Yani tüm gelişim noktaları onlar ile ilgili aksiyonlar alındığı zaman iyileşmeye neden olur ve hepsi de bir diğeriyle etkileşim içerisindedir. Dolayısıyla fazla çalışmanın verdiği hasarlar katlanarak ilerler.
Yöneticiler halen bir iş üzerinde çalışılan saatine bakarak takım üyelerinin “çalışıp çalışmadığını” ölçüyorlar ve performanslarını buna göre değerlendiriyorlar. Oysa bir iş üzerinde harcanan zaman maliyettir. Bir kurumun hedefi maliyetleri düşürerek, çıktıyı arttırmaktır. Bir iş üzerinde harcanan zaman arttığında çıktı artmıyorsa ortada bir gelişim noktası var demektir. Tek tek tüm takım üyelerinin harcadığı zamanı tutmak ya da harcadıkları zamanı bir sisteme girerek bunları raporlamatmak yerine takımların çıktılarına bakmak gerekir. Takımı yoğun fazla mesailer ile yoruyor ve çıktısını düşürüyorsanız, kağıt üzerinde takım çok çalışmış gibi görünse de ortaya hem verimsiz hem de kalitesiz bir sonuç çıkacaktır.
Karşılaştığım enteresan örneklerden bir tanesi de takımlardan 3-4 haftalık planlar alıp, bu planlardaki işlere takım üyelerinin ne kadar çalıştığını tutmaya çalışmak ve plansız gelen işlere zaman harcanmışsa ya da planlı işler planlandığından daha erken bitmişse negatif olarak değerlendirmek, takımı kötü plan yapmakla ve/ya da kişileri çalışmamakla ya da plansızlıkla suçlamak. Bu örnek gerçekten enteresan çünkü aynı örnekte çıktılara da bakılıyor, yani bir takım çıktı üretememişse olumsuz değerlendiriliyor buraya kadar sorun yok, ama aynı takım çıktı üretmişse fakat takım üyeleri işlerin bitmesi için harcadığı süreleri bir sisteme girmemişse de olumsuz değerlendiriliyor, dahası çıktı üretmiş süre de girmiş bir takım 4 hafta önce planladığı çıktılar yerine başka çıktılar ürettiyse yani bir değişiklik olduysa ve takım ona karşılık verdiyse de yine olumsuz değerlendiriliyor. Takıma başarısızlıktan başka bir yol kalmıyor. Bu başarısızlığın “suçlusu” bulunuyor.
Doğru kriterleriniz yoksa doğru davranışlar da sergileyemezsiniz. Yanlış kriterler yöneticileri “suçlama” kültürüne iter. Bu kültür bütün organizasyona derinlemesine işler. Tüm kötü şeyler hızlı bulaşır. İyiler yavaş. Takım çıktıları yerine bireylerin harcadıkları süreyi, ölçme kriteri olarak alan yöneticiler, takımın çıktıları düştüğü zaman bireyleri suçlarlar, bireyler de birbirlerini. Suçlama davranışı bu şekilde yayılmaya ve tekrar edilmeye başlar, bir zaman sonra katı bir kültür halini alır. Bir yönetici organizasyonu “suçalama kültürüyle çalışmakla” suçluyordu. İronik, evet suçluyordu. Kişileri ya da sistemi değiştirmekten önce kendimizi değiştirmemiz gerektiğine güzel bir örnek.
Yöneticilerden şu soruyu duyar gibi oluyorum, “peki bireyleri nasıl ölçeceğiz?”. Ben de neden buna ihtiyaçları olduğunu sormak isterim. Bir takımın üretkenliğini arttırmak için bireylerin yetkinliklerine, takıma uyumuna ve gayretine/motivasyonuna ihtiyacınız var, ölçmeniz gereken kriterler bunlar, bir işe çok zaman harcamaları tek ya da en önemli olumlu kriter olmamalıdır, onlara güvenmeniz ve onları desteklemeniz gerekir. Takım üyelerinin işlere harcadıkları zamanları kontrol etmeye çalışarak, onları aşırı çalışmaya zorlayarak motivasyonlarını öldürdükten sonra onları “yeterince gayretli olmamakla” ya da “isteksizlikle” suçlamanız ne size ne takım üyelerine ne de organizasyona bir fayda sağlamaz.Tam tersine büyük zararı olur.
Bu sefer bir basketbol takımının koçu olduğumuzu varsayalım, onlara maçtan önce ne kadar gayretsiz olduklarını ne kadar yetersiz olduklarını herkesin sorumluluğu birbirine attığını mı söylerseniz iyi bir maç çıkarırlar yoksa desteklerseniz, inancınızı, güveninizi söylerseniz ve maç içerisinde onların göremediği gelişim noktalarını hatırlatıp dikkat etmeleri halinde kazanacaklarını mı söylerseniz?
Çevik bir takımın planlaması zaman üzerine değil işlerin büyüklüğü üzerine olmalıdır. (Neden süre tahmini yerine işleri büyüklük cinsinden tahminlediğimize buradaki yazıda anlatmaya çalışmıştım.)
Özetle yazılım geliştirme karmaşık bir iştir. Bir geliştirme çalışmasının tam olarak ne kadar süreceğini önceden bilmek neredeyse imkansızdır. Ek olarak takım üyelerinin kod yazma hızları da değişkenlik gösterir bu nedenlerle bir ürünün ya da projenin geliştirme çalışmalarının tam olarak ne kadar süreceğini tahmin etmek yerine işleri test edilebilir en küçük parçalara ayırarak bu işlerin büyüklüklerini birbirleriyle kıyaslayarak tahmin etmek gerekir.
Eğer işlerimizin büyüklüklerini tahminlemişsek ve sprintler (iterasyonlar) ilerledikçe takımın ne kadar büyüklükteki işleri tamamladığını ölçüyorsak, yani takımın hızını biliyorsak, tüm işlerin bitmesi için ne kadar sprint geçmesi gerektiğine dair geçekçi bir fikrimiz olabilir.
Tam da bu noktada takımın her bir iş üzerinde harcadığı zamanı bilememizin bize söyle bir faydası vardır. Birbirine yakın büyüklüklerdeki işler için harcadığımız zamanlara bakabilir ve bunlardan birisine çok daha fazla zaman ya da daha az zaman ayırmışsak, nedeni sorgulayabilir ve buradan takıma gelişim noktaları çıkarabiliriz. Bir örnek vermek gerekirse, X ve Y story’leri 3SP ya da “small” büyüklükte işler olsun. Aynı sprint içerisinde, X için takımın harcadığı süre 20 saat iken Y için harcanan süre 40 saat ise, bunun nedenini takımın retrospektif toplantısında sorgulaması gerekir. Takım hatalı büyüklük tahmini yapmış olabilir gözden kaçırdığı noktaları konuşabilir ya da tahmin doğrudur ancak takımı engelleyen teknik bir kısıta takılmış olabilir bu durumun tekrar etmemesi için kalıcı çözüm üzerinde konuşabilir. Bir iş üzerinde harcanan sürenin çok olmasını olumlu bir “performans” kriteri yerine “maliyet” olarak düşündüğünüz ve raporladığınız zaman israfı azaltan, takımın önündeki engelleri kaldırmasını teşvik eden bir yaklaşımı benimsemiş olursunuz. Agile’ın bir yaklaşım biçimi olmasına dair güzel bir örnek.
