Projeleriniz NASA Projesi Karmaşıklığında Olmasın !

Bir NASA Projesi mi Yönetiyoruz ? Yaptığımız NASA Projesi Değil Kardeşim Sonuçta !

nasa

Tabii ki NASA’da çalışan ufak azınlığı hariç tutarak bu tabiri kullanıyorum ki hiç birimiz bu denli karmaşık, geniş kapsamlı ve çok paydaşlı bir proje yürütmüyoruz…

Evet malum NASA projeleri dünyada en detaylı, içinden çıkılması en zor ve karmaşık, sınırlı zamanda ve kritik önem ve hassasiyete sahip projeleri. Ayrıca bir çok tedarikçiniz ve paydaşınız var. Tüm hepsini çok kısıtlı zaman dilimi içinde tabiri caizse saniyelerle yarışarak yönetmeniz gerekiyor. Sürekli dikkatli ve uyanık olmanız da şart. Projenin ve işin hayati ve ülke ve dünya için önemini de eklemek lazım…

Peki gelelim yönettiğimiz projelere. Tabii ki biraz düşününce yukarıda saydığım karmaşıklık ve detay seviyesine kıyasladığımızda farklar ortaya çıkacaktır. Her projenin ayrı bir zorluk seviyesi, ayrı karmaşıklığı ve paydaşları, apayrı bir yapısı olacaktır. Bu da normaldir ki zaten projeleri “Proje” yapan da budur. Tamamen orijinal/özgün yani daha önce hiç yapılmamış olmasıdır. Bir diğer özellik de belirli bir hedefi ve zaman aralığı olmasıdır.

Yönettiğimiz projelerin evet kendine özgü karmaşıklığı olsa da niye acaba bazen NASA projesi seviyesine getiriyoruz? Projelerde karmaşıklıklar anlaşmazlıklar neden oluyor? Projeyi basite indirgeyeceğimize NASA seviyesine çıkarıp içinden çıkılmaz hale sokuyoruz? Müşteri mi tedarikçi mi yoksa çalışan veya yönetici mi karmaşıklık seviyesini arttıran? Peki bu işin çözümü kimde?

from-space-cloud-nasa-embraces-cloud-computing

Aklımıza gelebilecek soruların sayısını artırmak mümkün ancak hızlıca konuyu dağıtmadan sorunlara ve çözüm önerilerimize bakalım…

  • Projeler neden bu kadar kapsamlı?” ya da “Proje bu kadar kapsamlı olmak zorunda mı?

Bu soru ile genelde karşılaştığımız durumlar oluyor. Özellikle de ekibinizdeki “yeni mezun” analist ve/veya yazılımcılardan duyabileceğiniz klişe bir sorudur. Zira deneyimli kişiler yönettiği veya dahil olduğu projenin kapsamını bilir. İdealde o işi ne kadar zamanda yapabileceğini de tahminler. Ancak yeni mezun bir çalışan kapsama hakim olamadığı için bu soruyu sormuş olabilir.

Ya da başka bir alternatif olarak, proje normalde yapılan kapsamın dışına çıkılmıştır ve iş büyümüştür. Bunun bir çok nedeni olabilir. Bunlardan en sık karşılaşılan olanı müşteriden gelen bitmek tükenmek bilmeyen istekler sonucu proje kapsamı büyüyebilir. Ayrıca her gelen isteğin ve değişiklik talebinin kabul edilmesinin de sakıncalarını ve yan etkilerini çekecek olan işi yapan ekip olacaktır. İşte bu durumlarda proje kapsamı ideal ve hedefin dışına çıkabilir.

  • Bir proje bu kadar mı karmaşık yapıya sahip olur?

Bu soruyu da herhalde projenin karmaşıklık seviyesini kavrayamamış olmamız gerek ki soruyoruz. Teknik olarak proje istediği kadar karmaşık olursa olsun onu başarı ile yönetebilmenin de bazı ipuçları var. Bu ayrı bir yazı konusu olabilir ancak genel hatlarıyla bu yazımda da değiniyorum.

Karmaşıklık seviyesini öğrenmek için;

  1. Öncelikle projenizin ve/veya organizasyonun karmaşıklık seviyesine bakın, büyük resmi görün,
  2. Her kişi ve/veya birimin temas ettiği noktalara bakın,
  3. Projelerde bir kişinin temas ettiği kişi sayısı = (n * n-1 ) /2 formülü ile hesaplanabilir. Bu sayı en yüksek çıkan kişi en karmaşık ilişki sayısı ve yapısına sahip kişidir. Örneğin; bir kişi 8 kişi ile temasta ise = (8*7)/2 = 28 olacaktır.
  4. En yüksek temas noktasına sahip olan kişi tahmin edersiniz ki “Proje Yöneticisi” olacaktır.
  5. Ayrıca iki projenin karmaşıklık seviyesini de bu yöntem ile proje yöneticileri üzerinden de karşılaştırmanız mümkün.
  6. Temas noktaları ile karmaşıklık seviyesini öğrendikten sonra kapsamı kıyaslamak da önemli,
  7. Kapsam dışında tedarik ve insan kaynaklarının durumuna da bakılabilir. Yani kapsam ve karmaşıklık seviyesiniz ideal olsa bile tedarikleriniz ve insan kaynaklarınızda halen eksikler ve belirsizlikler söz konusu ise bu durumda işiniz oldukça zordur.
  8. Son olarak da – belki de en önemlisi – süreçlerinizin net olmamasını sayabilirim. Siz istediğiniz kadar sonuç odaklı olun süreçlerinizde tıkandığınız an sonuca ulaşmanız imkansızdır. Sonuca ulaşsanız bile bu sadece günü kurtarmak olacaktır! Uzun vadede aynı sorunlar farklı caseler ve farklı müşterilerde karşınıza çıkacaktır.

Peki şimdi gelelim karmaşıklığın çözümüne;

  • Öncelikle yukarıda saydığım durum analizini yaptığınızı varsayıyorum,
  • İletişim karmaşıklığı projenizin yönetim zorluğunu gösterecektir. Ayrıca farklı coğrafya, kültür ve dil farkları da ekstra olarak projeyi zorlaştırabilen unsurlar olarak sayılabilir,
  • Bu bilgiler ışığında proje iletişim karmaşıklık seviyesine göre öncelikle süreçlerinizi gözden geçirmeniz önemli,
  • Proje Lideri, Yöneticisi, Fonksiyonel Yöneticiler, Analist, Yazılımcı, Müşteri, Test Uzmanı vb. projeye dahil olan tüm ekip üyelerini etkileyen başkaca zorluklar varsa onların da üzerine gitmelisiniz,
  • Bu zorluklar birim bazında olduğu gibi kişisel problemler de olabilir,
  • Eğer süreçlerinizi iyileştirir ve çözüme yönelik adımları attığınızda sorunların büyük yüzdesini çözdüğünüzü göreceğinize eminim, hem de kalıcı olarak,
  • İç ve/veya dış müşteri olsun farketmez, kendi iç süreçlerinizdeki iyileştirmeler doğrudan müşterinize de yansıyacaktır,
  • Müşteri sizde karmaşıklığın ortadan kalktığını kendisi ile kolaylıkla temas kurulduğunu hissettiğinde “Müşteri Memnuniyeti” doğrudan sağlanmış olacaktır. Müşteri memnuniyeti için ekstra çabaya girmenize gerek bile kalmayacaktır. Müşteri onunla yediğiniz yemeğe, hal hatırını sormanıza veya gönderdiğiniz eşantiyonlara bakmayacaktır.
  • Müşteri memnuniyeti için önemli olan yeter ve tek şart “Temas kurabileceği bir kişi olması ve sorunlarının makul sürelerde çözüme kavuşmasıdır“.

Evet projelerde çalışmaları zorlaştırmanın hiç ama hiç anlamı yok. Birbirimize yardım edebilmek, birbirimizi dinlemek ve çözüm bulmaya çalışmak ayrıca beşeri olarak yapabileceğimiz destekler olacaktır.

İşte örnek bir NASA Projesi: Challenger Projesi.

chellengers

Bir örnek ama kötü bir senaryo örneği. Bu tür örnekleri de görelim ki hatalardan ders alabilelim. Yoksa her şey güllük gülistanlık gittiğini sandığınız durum aslında hiç öyle olmayabilir de…

1986 da tam 10. denemesinde uzaya fırlatılan Challenger uydusu tam 73 saniye sonra infilak etti. İçindeki 5 astronot ve 2 yük uzmanı ile patlayan mekik NASA tarihindeki en kötü deneyimlerden biri olmuş ve NASA uzun yıllar uzay araştırmalarını askıya aldığını açıklamıştı. NASA uzun süren iç denetimler ve araştırmalar sonrasında teknik ve idari olarak sorunlarını çözüp tabiri caizse toparlanıp projelerine kaldığı yerden devam etti. Bu süreçte yaşadığı ekonomik kayıplar, sponsor eksiklikleri ve itibar kaybına rağmen oldukça iyi toparlanma dönemi geçirdiğini söyleyebilirim.

Challenger mekiği ile ilgili daha detaylı bilgiye şu adresten ulaşabilirsiniz:

https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disaster

Ayrıca Challenger ın fırlatma ve patlama anları aşağıdaki yayından izleyebilirsiniz…

Sonuç olarak zorlaştırmadığımız ve karmaşıklaştırmadığımız projeler dilerim 🙂 Tabii ki sonu da Challenger gibi kötü sonuçlarla sonuçlanmasın…

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