BEN HİÇ DEĞİŞMEM! NEDEN? HAYAT SANA BİR ŞEY ÖĞRETMEDİ Mİ?

BEN HİÇ DEĞİŞMEM! NEDEN? HAYAT SANA BİR ŞEY ÖĞRETMEDİ Mİ?

Yıllarca özel sektörde farklı alanlarda faaliyet gösteren “kurumsal” pek çok şirkette farklı pozisyonları işgal ettim. İçerisinde benim de bulunduğum proje ekipleri sınırlı bir zaman diliminde benzersiz bir ürün/özellik üretmek için gecelerini gündüzlerine kattılar. Ulaşılan çıktı (ürün/özellik) proje yemekleri ile kutlandı, yönetim tarafından ekip üyelerine hediye çekleri verildi. Filmin sonu hep aynı!

Filmin başına geri dönecek olursak, müşteri ile günlerce yapılan analiz toplantılarının ardından tüm gereksinimleri belirledikleri düşünen proje ekipleri kendilerini ofise kapatıp “kapalı kapılar ardında” proje takviminde kullanıcı kabul testi için belirlenen tarihe kadar çılgınlar gibi geliştirme yapıyorlar. Bu süreçte (son kullanıcı için hiç bir anlam ifade etmeyen) yeni teknolojilerden faydalanıyorlar, kullanılabilirliği oldukça yüksek (ancak çoğunlukla hiç kullanılmayacak) önyüzler geliştiriyorlar, (aslında yüksek performans ihtiyacı olmamasına rağmen) performans iyileştirmeleri için veri tabanı yönetimi ekibi ile birlikte çalışıyorlar. Bu süreçte ekip açısından işler oldukça yolunda görünüyor. Ancak kabul testi denen “sona” yaklaşıldıkça birim testler veya alfa testleri özensiz bir şekilde yapılıyor ve kalite hızlı bir şekilde yok edilmeye başlıyor. Hatta kabul testi kapsamının geniş ve süresinin uzun olduğu bazı projelerde “Bu fonksiyonun çalışmadığını biliyoruz; ancak kullanıcı bunu test edene kadar biz bunu hallederiz.” söylemiyle, bu sürenin de geliştirme için kullanıldığına şahit oluyoruz. Kabul testinde üretilen çıktıya ilk kez dokunan kullanıcının çıktı hakkındaki yorumları ve talepleri “Bunlar için vaktimiz yok, 2. fazda yaparız.” sihirli cümlesi ile geçiştiriliyor. Tabi bu arada kullanıcının belki hiç bir işine yaramayacak bir özellik için günlerce vakit harcanmış olduğunu da proje ekibi bu sırada fark ediyor.

Sonuç? Bir tarafta istediğim gibi olmamış diyen bir kullanıcı, diğer tarafta “Biz bunun için günlerce geliştirme yaptık, bu özelliği ne olursa olsun canlıya alacağız. Diğer talepleriniz için vakit kalmadı, pazartesi canlıya çıkıyoruz, 2. fazda yaparız” diyen bir proje ekibi. Tabi bir de kutlama(!) yemeği. Kişisel tecrübelerime göre geliştirilen 10 projenin 8’inde bu filmi izliyoruz.

İnsanlar izledikleri bir filmi nadiren 2. kez izlerler. Bazı istisnai durumlarda bir film 3. kez izlenebilir; ancak bu sayının 4 olma olasılığı çok düşüktür. Peki konu proje geliştirme olduğunda neden her gün aynı filmi izliyoruz? Aşağıdaki söylemler sizlere tanıdık geliyor mu?

• “Böyle gelmiş, böyle gider abi. Bu şirkette işler düzelmez.”
• “Yöneticim düşünmüyor, ben neden düşüneyim ?”
• “Bu müşteriye ağzınla kuş tutsan yaranamazsın.”
• “Bu analistlerle kaliteli iş çıkmaz.”

Bu cümleleri hemen her proje ekibinden duymak mümkün.

Peki çözüm ne?

Değişimin ve iyileşmenin önündeki en büyük engel çoğunlukla bu önyargılar. Bu önyargıları ortadan kaldırmak ve değişmek için bir kaç adım atabilecek cesareti göstermek gerekiyor. “Bu projeyi de öyle böyle atlattık, önümüzdeki release’e daha 3 ay var.” yaklaşımını sürdürerek aslında görünen tozu halının altına süpürmüş oluyoruz. Diğer yandan da 3 ay sonra halıyı kaldırdığımızda tozun orada olmayacağına kendimizi inandırıyoruz.

Unutmamak gerekir ki; problemler şarap değildirler, bekledikçe güzelleşmezler. Görünen tozu bugün süpürmek ve dahası toza neden olan faktörleri tespit edip bunları ortadan kaldıracak çözümleri aramak zorundayız.
Proje geliştirmeyi bir fonksiyon olarak düşünürsek, aynı girdiler her zaman aynı çıktıyı verecektir. Çıktıdan memnun değilsek, girdileri ve/veya girdiler üzerinde uyguladığımız işlemleri değiştirmek zorundayız.
Kutlama yemeğine ayırdığımız vaktin en azından yarısını geliştirme sürecinde karşılaşılan problemlerin neler olduğu ve nasıl çözülebileceği konusuna ayırmak zorundayız.

Yazıya başlık olarak seçtiğim Oscar Wilde’ın ünlü sözünde belirttiği gibi, ilerleyebilmek için hatalarımızdan ve başkalarının hatalarından öğrenerek değişmemiz gerekiyor.

Onur Özcan, Agile Team Coach, ACM