Güncel, Proje Yönetimi

Hatasız Geçiş Olmaz ! Yoksa Olabilir Mi?

Proje 3 Ayak Kümesi_v1Klişe olmuş bir sözle başlamak istiyorum yazıma: “Hatasız Kul Olmaz” dan uyarladığım “Hatasız Geçiş Olmaz” 🙂

Belki bir çok kişinin kabullendiği bir olgu haline gelmiş maalesef hatasız geçiş olamayacağı. Gerçekten mümkün değil mi hatasız “0” bug ile geçmek? Biraz derinlemesine irdelemek ve sorunların nereden kaynaklandığını hatta çözüm önerilerimi paylaşmak isterim.

Uzun zamanlar harcadığımız projelerde en can alıcı kısım hiç kuşkusuz “Canlıya Geçiş” aşamasıdır. Hem artık gecelerini verdiğimiz hem de o kadar emek harcadığınız projenin müşterinize/müşterinizin müşterisine açıldığı en önemli aşamasıdır. Artık bu aşamaya bir milestone (MS) demeyip “Ürün” demeye başladığımız noktadayızdır.

Geçiş zamanı (-ki yazılım projelerinde genelde çalışan sistemleri etkilememesi için gece yapılır) o kadar önemlidir ki proje için geride harcadığınız aylar-yılların bir anda silinip gitmesine bile neden olabilir. Çünkü ortaya çıkan üründen müşterinin memnun olmaması harcanan onca emeğin unutulması ve sadece ortaya çıkan üründeki hatalara odaklanılması anlamına gelmektedir. Ürün döngüsü içerisinde hataların yönetimi, müşteri yönetimi de ayrı bir yönetim anlayışı ve uzmanlık gerektiriyor oraya da değineceğim ama önce hatasız geçiş için yeter şartlar nelermiş bakalım.

product

Hatasız Geçiş olması için gerekli ve yeter şartlar şunlar olacaktır:

  • Hatasız geçişi sadece PROD a çıktığınız gün olarak düşünmeyin yerine proje yönetim süreci olarak düşünün,
  • Hatasız Geçiş” proje boyunca harcadığınız tüm eforların ve çalışmaların bir sonucudur,
  • Sağlam, mantıklı ve doğru bir proje planı çıkarabilmek gerekir,
  • Proje planı sadece sizin değil müşteri tarafından da mantıklı olarak hazırlanmalı,
  • Proje süresince yaşayacağınız teknik/idari sorunların çözümüne yaklaşımınız önemli,
  • Sorunları halı altına süpürmek yerine ortaya çıkarıp çözüm bulmak en önemli düsturlardan biri olmalı,
  • Belki de en önemli nokta olan “Kalite” yi sağlayabilmek üstte yazdıklarıma bağlı olmakla beraber;
    • Kaliteli ürün için tek tek adımları belirlemeli,
    • Taleplerin toplanmaya başladığı müşteriyle temas noktası çok önemli. GAP analiz toplantılarında analistin ve müşterinin birbirini anlaması kritik,
    • Test senaryolarınızın olmaması gibi bir durum olmaması düşünülemez,
    • Hatta test senaryolarının mümkün olduğunca zenginleştirilmesi sizin de yararınıza olacaktır,
    • Development süresince yazılımcının kendi testlerini net ve eksiksiz bir şekilde yapması gerekli,
    • Hazırlanan kodun müşteriye teste verilmeden önce analist tarafından da tekrar gözden geçirilmesi hataları daha da minimuma çekecektir,
    • Test süresince müşteriye verilecek destek (yerinde veya uzakta) hem müşteri memnuniyeti hem de ürün kalitesi açısından olmazsa olmaz bir noktadır.
    • Kaliteyi sağlayabilmek sadece developer, analist tarafından değil tüm paydaşlarla sağlanabilecektir,
    • Gene şirketlerdeki tüm süreçlerin yalın ve ürüne özgü olması “Kalite” yi sağlayacak en önemli unsur olacaktır.
    • Dolayısı ile “Kalite” nin sağlanması için öncelikle uygun ortam ve süreçlerin yöneticilerce sağlanması gerek.

Yazdıklarımı biraz daha açmak daha açıklayıcı olacaktır.

quality

Kaliteyi Sağlayan Kriterler:

  1. Ürününüzün müşteri gözünde durumu. Yani müşteri üründen memnun mu değil mi?
  2. Ürün müşteri ihtiyaçlarını karşılıyor mu?
  3. Ürününüzün kendisinde bir eksiklik olabilir mi?
  4. Yazılım ve test süreçleriniz tam ve eksiksiz mi?
  5. Destek ve proje yönetim süreçleriniz tam ve eksiksiz mi?
  6. Müşteri destek ve şikayet yönetimi ekipleriniz doğru ve eksiksiz olarak müşteriden geri bildirim alıp ilgili ekiplerle paylaşıyor mu?
  7. Şirket içi dinamikleriniz ve süreçleriniz “Kaliteli Ürün” anlayışını destekliyor mu?
  8. En önemlisi de yukarıdaki 6 maddeye “Herkes ama Herkes” inanıyor mu? Üst düzey yöneticiden işe yeni başlayan yazılımcı/analiste kadar…

Gerçekten mükemmel bir ürüne sahip olabilirsiniz. Ancak işte tüm bu süreçler doğru yönetilmez ise ortaya çıkan üründen hiç de iç açıcı sonuçlar alamayabilirsiniz.

seyyar-tayyar

Gelin son dönemde ortaya çıkan bir örnek vakaya (Study Case) bakalım. Apple karşısında Samsung’un düştüğü durum…

  • Samsung’un Ağustos 2016 da müşteriye sunduğu Note 7… Seyyar Tayyar in da dedigi gibi “Patladi gitti”… Note7 nin üretimi piyasaya çıktıktan 2 ay sonra 11 Ekim 2016 tarihi itibariyle durduruldu!
  • Peki;- Samsung gibi bir şirket kalite testlerinde bunu nasıl atladı?
    – Lansman sanki biraz acele oldu -ki normalde Eylül aylarında olan lansmanı Ağustos da yapmak kimin fikri?
    – Apple ile yarış yapıp ondan önce lansman yapmak mantıklı bir hareket gibi görünse de sonuç hüsran oldu.
    – Sanki is aceleye mi geldi? UAT veya preprod testlerinin sürelerini mi kıstılar 
    – Yoksa test caseleri mi yeterli değildi ?
    Teknik anlamda da incelemek lazim tabii ki… (Ah o son diyodu takmayacaktın hocam  )

    Sonuç ne oldu: Ürünü geri veren müşterilerin de %35 i Apple e gecmiş. İnanilmaz rakamlar dönüyor. Ancak Samsung un bundan sonra yapacağı, amiral gemisi olan note 7 de bu sorunu yasaması şimdilik ölçülebilir değer olarak tam 26 milyar $ kayba neden olan bu önemli hatadan ders çıkarıp önlem almak olmalı.

    Düşünün patlama vakası satılan 1 milyona yakın üründen sadece 75 adedinde yaşanmış !

    Oransal olarak milyonda 75 adeti projelerinizdeki hata sayısı ile ile kıyaslayın lütfen. Evet can güvenliği söz konusu olması bu iptalde etken belki ama bu kadar az örnekte bile yaşanmasına rağmen tamamen ürünü durdurmak dünyada her şirketin alabileceği bir karar olmasa gerek.

    Tabii ki benim burada anlatmak istediğim “Kalite” nin sadece analiz sırasında bir noktanın atlanması, yazılımdaki bir hata veya test sırasında yeterli desteğin verilmemesi olarak indirgenmek yerine bu işin bir “süreç ve kültür” olduğudur. Nasıl ki bir çok şirkette maalesef halen proje yönetim ve test yönetim kültürü oturmadığı gibi kaliteli iş yapma veya en azından en az hata ile ürün çıkma kültürü oluşmamış durumda. Ancak bu anlayışı yerleştirmek ve değiştirmek sadece yöneticiler değil tüm çalışanların ortak emeği olabilecektir. Yöneticilerin kaliteli ürüne giden süreçleri oluşturmak ve çalışanların işini kolaylaştırmak iken çalışanların da elindeki işi “Sıfır” hata ile çıkmak ana hedefi olmalıdır.

    Kalite nin diğer bir etmeni de hiç kuşkusuz “Hız”. Elinizdeki iş için 10 birim zaman öngörüyorsanız ve elinizdeki diğer işlerden dolayı bunu 5 birim zamanda bitirmeniz gerekiyorsa o zaman orada bir problem var demektir. Ucuz etin yahnisi yavan olur misali, kısa zamanda ortaya çıkan üründe de illaki eksiklikler olacaktır.

    İşte Kaliteyi oluşturan ve benim “Kalitenin 3 Sac Ayağı” olarak nitelendirdiğim Kapsam, Zaman ve Maliyetin etkin yönetimi de bizi Kaliteye ulaştıracaktır.

    Tabii ki aşağıdaki tasviri esprili bir dilde hazırlamış olsam da 3 kümenin kesişimine ulaşmak için belirtmiş olduğum noktalara dikkat etmek gerekecektir. Bunların eksiği yok ancak fazlası olabilir. Zira yapılacak iş her zaman vardır. Sonucunda kaliteli işler ve ürünlerinizin olacağı projeler dilerim 🙂

    Proje 3 Ayak Kümesi_v1

 

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Connecting to %s