Uçakta pilot var mı?: teknik inceleme

Önemli : Bu makale makine çevisidir. Bkz. yasal uyarı. Bu makalenin İngilizce sürümüne buradan ulaşabilirsiniz.

“Uçakta pilot varsa lütfen çağrı düğmesine bassın” sözlerini hiçbir yolcu duymak istemez. Aralık 2013'te tam olarak bu şekilde gelişen gerçek bir olayla ilgili dikkat çekici haberi yeniden okudum. Des Moines/Iowa’dan kalkan bir uçağın pilotu ani bir sağlık sorunu yaşayınca yardımcı pilot, uçakta pilot varsa kokpite gelmesini istiyor. ABD Hava Kuvvetleri’nde B1 bombardıman uçağı pilotluğu yapan Yzb. Mark Gongol, görevi üstleniyor. Uçak, yolcuları ve mürettebatıyla birlikte sağ salim iniyor.

Bu harika bir hikaye, ancak tekrar okumak istememin sebebi çok farklı. Kısa bir süre önce potansiyel bir müşterimiz bizi arayarak kurumsal proje zaman çizelgesi yazılımımızı “pilot” olarak kullanıp kullanamayacağını sordu. Bu tür çağrılar aldığımda bir an için durup düşünürüm. Uçakta birisi “pilot” dediği zaman bunun ne anlama geldiğini hepimiz anlarız, ancak yazılım seçeneklerini değerlendiren biri “pilot” dediğinde o kadar emin olamıyorum.

Yazılım dünyasında “pilot” terimi, genellikle “kavram kanıtı” gibi diğer zorlu değerlendirme yöntemleriyle birlikte kullanılır. Bu terimlerin ne anlama geldiğine ve kendi kurumsal değerlendirme sürecinizde bunları nasıl kullanabileceğinize bir göz atalım.

Kavram Kanıtı

Geçmişi yıllar öncesine dayanan bu terim, elektrik mühendisliğinde yaygın olarak kullanılıyor. Bir devrenin "bread board"unu (deneysel devre) oluşturmak, devreyi üretime hazırlamak için değil, devrenin mümkün olup olmadığını görmek için yapılırdı. Kavram kanıtında, laboratuvar tezgahında geçirdiğiniz vakit, üretilecek devreyi oluşturduğunuz süreden daha fazla olabiliyordu. Ancak, verebileceğiniz zararlardan yalnızca önünüzdeki devre kartı etkilenebilirdi. Bu, bir elektrik devresinin istenen sonucu verebileceğini kanıtlamak için kullanılan ucuz ve düşük riskli bir yöntemdi.

Yazılım açısından bakıldığında, bir kavram kanıtının bir şeyi kanıtlamak için tasarlanması gerekir. Potansiyel müşteriler, kurumsal proje yönetimi veya kurumsal zaman çizelgesi yazılımları için bir kavram kanıtı sağlamalarına yardımcı olmamı istediğinde hep aynı yanıtı veririm: "Hangi kavramları kanıtlamak istiyorsunuz?"

Bunun karşılığı da genellikle sessizlik ve kafa karışıklığı olur.

Bir kavram kanıtı gerçekleştirecekseniz ve neyi kanıtlamaya çalıştığınız hakkında hiçbir fikriniz yoksa, deneyin başarılı olup olmadığını nasıl bilebilirsiniz? Tabii ki bilemezsiniz.

Haklı olarak sorarsınız: O zaman kavram kanıtı gerçekleştirmeye çalışmanın anlamı nedir? İlgili kişiler bu soruya cevap olarak genellikle, istekte bulunan kişinin, araştırmakta olduğu yazılımın uygulanması konusunda yönetimden gerekli desteği almadığını ve yönetim birimindeki kişilerin yazılımın çalıştığını gözleriyle görmesi durumunda bu fikri benimseyerek yazılımın kullanılması gerektiğine onay vereceğini umduklarını belirtiyor. Bu durumda "kanıt" yönetime, "kavram" ise kurumsal yazılım fikrinin kendisine işaret ediyor.

Kurumsal proje ve zaman çizelgesi yazılımının kendileri için çok uygun olacağı konusunda yönetimi ikna etmek o kadar kolay olsaydı, çok daha fazla yazılım dağıtırdık.

Bu yöntemdeki sorun, kurumsal bir sistemin üretim dağıtımını yaptığınızda alacağınız desteği, bu kavram kanıtı örneğini dağıtmak üzere yapacağınız çalışmalar için de alma olasılığınızın son derece düşük olmasıdır. Bir kurum tarafından zaman çizelgesi veya proje yönetim sistemi gibi bir kurumsal sistem dağıtıldığında, bunun başarıya dönüşmesi için yapılması gereken birçok şey vardır. İlk olarak, dağıtımda kurumun herhangi bir boyutunu ilgilendiren konularda yönetimin ve üretim hattında çalışanların fikri alınmalıdır. Daha sonra ise yapılandırma için zamana, diğer kurumsal sistemlerin bağlanması için teknik hizmetlerin yardımına, yönetimin desteğine, eğitim için zamana ve tabii ki paraya ihtiyacınız olur.

Bunların hiçbiri yoksa kavram kanıtınızda hangi sistemi tamamlayabilirsiniz? En iyi ihtimalle, istediğiniz şeyin yalnızca gölgesini elde edersiniz. Günümüz bulut çağında tamamen barındırılabilen bir sisteme erişebileceğinizden, en azından sunucu ve yazılım satın alma konusunda endişelenmeniz gerekmez. Ancak yalnızca yüklü bir sisteme sahip olmak, kavram kanıtı sisteminizin en basit dağıtımını yapmak için gereken işin bile çok küçük bir kısmını oluşturur.

Kuruluşun tamamını etkileme olasılığı bulunan bir şeyin uygulanması için yüklü miktarda para ve kaynak ayırma konusunda neden tereddüt edildiğini anlamak zor değil. Bu, yüksek riskli bir iştir. Kurumsal proje yönetimi yazılımının yalnızca avantajlarından bahsediyoruz, ancak aynı projede hata olması durumunda eşit derecede olumsuz bir etkiyle karşılaşılacağını tahmin etmek hiç zor değil. Dolayısıyla, riskin azaltılması son derece önemli. Ancak, asıl zorluk sistemin avantajları konusunda yönetimi ikna etmek ise bunu yapmanın kesinlikle daha iyi yolları var. HMS Software olarak, aşağıdaki tekniklerden birkaçına odaklanıyoruz:

  1. Gerçek ve mevcut bir müşteriyle görüşün.

    Genel anlamda bizden memnun olan bazı harika müşterilerimiz var. Potansiyel bir müşterimiz kendilerini neyin beklediği konusunda endişelendiği zaman, söz konusu kuruluşu mevcut bir müşterimizle buluşturuyoruz. Çoğu durumda, mevcut müşteri yüz yüze toplantı düzenlemeyi teklif edecek kadar cömert oluyor. Bazı durumlardaysa birbirleriyle telefon görüşmesi yapıyorlar ve biz bu görüşmelere katılmamayı tercih ediyoruz. Mevcut müşteriyi, hem iyi haberleri hem de zorlukları paylaşmaya teşvik ediyoruz.

  2. Biz kanıtlayalım.

    Gerçekten kanıtlanması gereken bir kavramınız varsa, bunun size kanıtlanmasına yardımcı olmamıza izin verin. Öncelikle bazı uygulamaların belirli özelliklerinin kanıtlanmasını gerektiren haklı gerekçeler vardır. Belki de dağıtımda, hacmi çok büyük olan belirli türde veriler olacaktır. Örneğin bir keresinde, çözümümüzün sıra dışı büyüklükte bir proje yüküyle çalışabildiğini göstermemiz istendi. Yazılımın belirli tarayıcılarla veya belirli veritabanlarıyla çalıştığını ya da bazı dış sistemlerin belirli sürümlerine bağlandığını göstermemiz istendi. Değerlendirmeyi engelleyen kavram bu türde bir kavramsa bu zorluğun üstesinden en iyi şekilde gelebilecek kişiler, konunun uzmanlarıdır.

  3. Eğitim olanaklarımızı da değerlendirebilirsiniz.

    Potansiyel müşterinin, sistemin personel tarafından kullanılan verilerle çalıştığını kesinlikle göstermesi gerekiyorsa verilerin barındırılan bir sisteme yüklenmesine yardımcı oluruz, ardından sistemi müşterinin istediği biçimde yapılandırmak ve ilgili kişileri eğitmek için en düşük gereksinimleri yerine getiririz. Sunuma yardımcı olmak üzere şirkete gitmeyi tercih etsek de bunun mümkün olmadığı durumlarda, ilgili kişilerin kullanacağı senaryo veya sunumu görmeyi ve bunu değiştirme ya da sunumu yapan kişileri eğitme konusunda yardımcı olmayı teklif ederiz.

Size pilot mu lazım?

Pilot projeye ne dersiniz? Daha iyi olmaz mı? Olabilir. Kurumsal bir zaman çizelgesi veya kuruluş proje yönetim sistemi için pilot dağıtım kurmanız istendiyse, çalışmaya hedefleri belirleyerek başlamalısınız. Hedefler yalnızca kavram kanıtıyla ilgiliyse, yaptığınız şey kesinlikle pilot program değildir.

Pilot proje, üretimde kullanılan, gerçek, canlı bir dağıtımdır. Genellikle değerlendirilen sistemi kullanması beklenen toplam kullanıcı tabanının alt kümesini ilgilendirdiğinden, pilot programlar biraz zaman alır. Hedef kullanıcı tabanının tamamının ihtiyaçları en baştan itibaren göz önünde tutulsa da pilot program, pilot kullanıcılar için gerçek bir uygulamanın gerçekleştirilmesine odaklanır. Bu kullanıcılar, gerçekten de projelerini yönetmek veya zaman çizelgelerini doldurmak için yeni sistemi kullanır.

Tam bir üretim dağıtımının karşılaşacağı zorluklar pilot uygulamada da karşımıza çıkar. Aradaki tek fark, verilerin hacmi ya da karmaşıklığıdır. Pilot projelerde en sık karşılaştığım sorunlar arasında destek eksikliği; bütçe, zaman ve kaynakların yetersiz olması ve belki de en kötüsü, pilot projenin başarılı olup olmadığını belirlemek için gerekli açık hedeflerin olmaması.

Bu, pilot projenin kötü olduğu anlamına gelmez. Pilot uygulamalar, çok kullanışlı olmanın yanı sıra eksik ya da kötü yapılandırılmış bir dağıtımla birlikte, kurumun tamamını etkileme riskini azaltmaya yardımcı olabilir. Ancak, bir pilot projenin başarılı olabilmesi için biraz düşünmek de gerekir.

Kısa bir süre önce, kamu sektöründeki bir kuruluş için büyük boyutlu bir dağıtım üzerinde çalışmaya başladık. Bu uygulamanın sevindirici tarafı, kurumun değerlendirmesini tamamlamak için harcaması gereken zamanın tamamını zaten harcamış olmasıydı. Kurumsal sistem konusunda tercihlerini yaptılar. Ne mutlu ki bizim sistemimizi seçtiler. Geçtiğimiz yıl boyunca kurumun değerlendirme ekibiyle birlikte çalışarak teknik sorularının yanıtlanmasını sağladık, ancak şimdi odak noktamız, sistemin bu kurumdaki insanların gündelik çalışmaları üzerindeki etkisi.

6 aylık bir dönem boyunca, nispeten büyük olsa da grubun tamamının yalnızca %10 kadarını oluşturan bir grupla çalışmamızı önerdiler. Yeterli bütçe var, pilot uygulama en üst düzey yönetimin desteğini aldı ve buna benzer bir dağıtımda normalde yardımcı olacağımız her konuda yardımcı olabilmemiz için yeterli süre verildi. Bu proje izleme ve zaman çizelgesi ortamına geçirilecek grup, bir aksilik çıkmadığı sürece üretimde bu sistemi kullanacak; yani sadece test etmeyecek. Bunu bir “deneyelim de ona göre karar veririz” uygulamasından ziyade, dağıtımın ilk aşaması gibi düşünebilirsiniz. Tüm bu etmenler bir araya gelince, bu yılın sonunda başarılı bir sonuç elde etmeyi beklemememiz için bir sebep yok.

Sonuç

Pilot projeler ve Kavram Kanıtı projeleri, kurumsal yazılımda hayatın bir gerçeği. Ancak yakınlarda böyle bir şey yapmanız gerekirse, projeye katılacak herkese bazı önemli başarı etmenlerini göstererek başarılı bir sonuç alınmasına katkı sağlayabilirsiniz:

  1. Öncelikle, hedeflerinizi mutlaka açıkça ortaya koyun.

  2. Daha sonra, yönetimin neye ihtiyacınız olduğunu anladığından ve bu hedeflerin gerçekleştirilmesi için sizi para, kaynak ve zaman açısından destekleyeceğinden emin olun.

  3. Son olarak, mutlaka bir proje planı oluşturun ve bu planı portföyünüzdeki diğer projeler gibi yönetin.

Yazar hakkında

Chris Vandersluis, merkezi Kanada’nın Montreal şehrinde bulunan ve bir Microsoft Sertifikalı İş Ortağı olan HMS Software şirketinin başkanı ve kurucusu. McGill Üniversitesi’nden ekonomi alanında lisans diplomasına ve proje kontrol sistemlerinin otomasyonu konusunda 30 yılı aşkın bir tecrübeye sahip. Uzun süredir Project Management Institute (PMI) üyesi olan Chris, Microsoft Project Users Group’un (MPUG) Montreal, Toronto ve Quebec şubelerinin kuruluşunda yer aldı. Chris’in yazı gönderdiği yayınlar arasında Fortune, Heavy Construction News, Computing Canada dergisi, PMI’s PMNetwork ve Project Times yer alıyor. Kendisi McGill Üniversitesi’nde İleri Seviye Proje Yönetimi dersi veriyor ve Kuzey Amerika’nın yanı sıra dünyanın diğer yerlerinde proje yönetimi dernek etkinliklerine sık sık konuşmacı olarak katılıyor. HMS Software, proje odaklı zaman tutma sistemi TimeControl yazılımının yayımcısı ve 1995’ten beri Microsoft Project Çözüm İş Ortağı.

Chris Vandersluis’e e-posta yoluyla ulaşabilirsiniz: chris.vandersluis@hms.ca

Chris Vandersluis tarafından kaleme alınan EPM ile ilgili diğer makaleleri okumak isterseniz kendisinin EPM Kılavuzu bloguna bakın (http://www.epmguidance.com/?page_id=39).

Not : Makine Çevirisi Yasal Uyarısı: Bu makale, insan müdahalesi olmadan bir bilgisayar sistemi tarafından çevrilmiştir. Microsoft bu makine çevirilerini İngilizce bilmeyen kullanıcıların Microsoft ürünleri, hizmetleri ve teknolojileriyle ilgili içeriklerden yararlanmasına yardımcı olmak için sunar. Bu makale makine çevirisi olduğundan sözcük, cümle dizilimi ve gramer hataları içerebilir.

Yeteneklerinizi geliştirin
Eğitimleri keşfedin
Yeni özellikleri ilk olarak siz edinin
Office Insider Programına Katılın

Bu bilgi yararlı oldu mu?

Görüşleriniz için teşekkür ederiz!

Geri bildiriminiz için teşekkürler! Office destek temsilcilerimizden biriyle görüşmeniz yararlı olabilir.

×