Translate

Kasım Şen - (Mütehayyil)

prioritize etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
prioritize etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

03 Nisan 2022

Kestirmeden Gidelim

 




Kestirmeden Gidelim

Birkaç kişi bir araya gelip, bir yolculuğa çıktıkları zaman genellikle içlerinden birisi hemen  “abi kestirmeden gidelim, ben kısa bir yol biliyorum daha kısa sürer” diye önerir. Bazen bu önerilen yol işe yararsa da, çoğu zaman işi daha da uzatır. Ekip içindekiler huzursuzlanmaya başlar ve süre ve yakıt maliyeti artar.

Proje yönetimi yolculuğu da böyle başlar. Özellikle projenin iş geliştirme ve planlama aşamalarında sıklıkla işçilik ve maliyet tahminleri yapılması gerekir. İngilizce “estimation” kelimesi için “tahminleme” kullanılabileceği gibi bazen “kestirim” de kullanılır. İşgücünü ve malzeme, hizmet maliyetini kestirmeye çalışmak anlamında düşünülebilir.

İyi, güzel ama kestirim yapmak kolay mıdır? Projelerimizde kestirimleri nasıl yapmalıyız?

Proje yönetimi açısından en zor konulardan birisi işgücünün ve maliyetlerin kestirimlerini yapmaktır. Çok risk içermektedir. Özellikle proje kapsamında teklif verilmesi veya sözleşme yapılması gerekiyorsa, yapılacak hatalı kestirimin telafisi kolay olmayacaktır. Hem işi alabilmek için kabul edilebilir bir teklif sunulmalıdır hem de maliyetler olabildiğince gerçeğe yakın öngörülmelidir. Gerçekten çok zor bir iştir, ayrı bir yetenek ve uzmanlaşma gerektirmektedir.

Projede kestirim yaparken aşağıdaki 4 yöntemden birkaçı uygulanır:

  • Uzman görüşü almak
  • Önceki projelerdeki verileri kullanarak benzetim yapmak
  • Global verilere dayalı hesaplamalar yapmak, modeller geliştirmek
  • Proje ekiplerinin tahminlerini bir arada değerlendirmek

Bu yöntemlerin hepsinin avantajları ve dezavantajları var. Şimdi bunları ele alalım.

Uzman görüşü almak: Projeyle veya çalışılan alanla ilgili daha önceden deneyimi olan uzmanlardan kestirim yapması istenebilir. Kulağa hoş gelen bir yöntem olsa da, hepimizin bildiği üzere ülkemizde herkesin “usta” olduğunu düşünürsek, şirketlerimizdeki “uzmanların(?!)” da sayısı epey fazladır. Çoğu da, yolculuk örneğimizde bahsettiğimiz o kısa yolu öneren kişiler olurlar. Üstelik bir de “abi ben ZATEN daha önce bu işi yapmıştım” diyorsa, vah ki vah!..

Önceki projelerdeki verileri kullanarak benzetim yapmak:  Şirketlerin veri havuzlarında geçmiş projelerdeki veriler kullanılarak yeni proje için benzetimler yapılmaya çalışılabilir. Sıklıkla benzer projeleri yapan firmalar için bu yöntem çok uygun ve kullanımı kolaydır. Ancak daha önce hiç tecrübe edilmemiş bir konuda çalışılması durumunda bu veriler tutarsız olacaktır. Bir diğer konu ise veri havuzundaki verilerin doğruluk değeridir. Verilerin toplanmasında, girişinde ve işlenmesinde hatalar yapılıyorsa, her defasında hatalı kestirimler yapılacaktır. Yazımızın başındaki yolculuk örneğindeki “kısa yol” ifadesi gibi hatalı verilere dayalı kestirimler, “çıkmaz yol” olabilir..

Global verilere dayalı hesaplamalar yapmak: Kestirimler konusunda dünya çapında toplanan verilere dayalı hesaplama yöntemleri önerilebiliyor. En bilinen örneği yazılım geliştirme faaliyetlerinde kullanılan “Function Point” ve COCOMO (Constructive Costing Model) yöntemleridir. Detaylarına girmeye gerek yok. Bazen kurumsal verileri kullanarak modeller de geliştirilebilir. Örneğin bir mekanik parçanın belli özelliklerini girerek bir formülle yaklaşık işyükü ve maliyet kestirimi yapılan modeller oluşturulabilir. En ideal kestirim yöntemi olarak görünse de modelin hatalı kurgulanması sonucu hatalı kestirimler yapılabilir. Ayrıca bu tür modellerin sürekli iyileştirilmesi ve geliştirilmesi gerekmektedir. Bu da ayrı bir uzmanlık gerektirir. Modeller geliştirilirken “bir elbise dikelim, herkese uysun ve güzel görünsün” temennisi olduğu için her model her projeye uygun olamayabilir, ne yazık ki..

Proje ekiplerinin tahminlerini bir arada değerlendirmek: Bu yöntemde  projedeki ilgili kişilerden iyimser, kötümser ve en olası tahminleri alınır. PERT yönteminden esinlenerek geliştirilen Üç Nokta yöntemi böyledir. Bazen bu üç verinin ortalaması alınır, bazen de başka bir  şekilde formül kullanılır. Detayları araştırılıp, öğrenilebilir. Yöntemin en önemli riski, tahmin yapanların birbirlerini etkilemesidir. Birbirleriyle konuşup, “galiba ben fazla iyimser ya da kötümser söylemişim, biraz değişiklik yapayım” diyerek sonuçlar etkilenebilir (manipulasyon). 

Geriye bir yöntem daha kaldı:”Hissikablelvuku” Yani kalbinden geldiği gibi, altıncı hissine ve sezgilerine dayanarak bir kestirim yapmaktır. 

Tutar mı? Ya tutarsa!

Proje yolculuğunda kestirmeden gitmeyi önerenlere fazla şans vermeyip, uygun yöntemler kullanılması gerekmektedir.

Kazasız, belasız iyi yolculuklar..


25 Eylül 2013

Etkili Analistlerin Davranışları -2



Not: 2002 yılında yazdığım ve yayımlanan bir makalemi paylaşmak istedim

Etkili Analistlerin Davranışları -2

Başarılı bir analist olmak için gereken bazı önemli özellikleri sıralamaya devam ediyoruz.

Çizgileri Belirlemek

Birçok projenin sınırları yazılı olarak belirlenmediği için neyin kapsam içinde, neyin dışında olduğu bilinemez ve bunun sıkıntıları zamanla ortaya çıkar. Yeni sistemin gereksinimlerini tanımlamaya öncelikle sistemin veya ürünün vizyonunu ve ne olup neler yapması gerektiğini ortaya koymakla başlanmalıdır. Sistemin iş gereksinimlerini tanımlamak ve vizyonu ortaya çıkarmak  için projenin pazarlama sorumlusu ve/veya finansal destekçisiyle iletişim içinde olmak, gerekirse hazırlanmış uygun bir doküman sunmak gereklidir. Son ürünün vizyonu tanımlamak zor olduğundan başlangıçtan son ürüne kadar her bir sürüm ve aşamanın vizyonlarını tanımlamak gerekecektir.

Gereksinimleri ortaya çıkarma görüşmelerinde önemli olan kullanıcıların sistemle neleri başarmak istedikleridir. Görüşmeler daha çok fonksiyonellik, kalite kriterleri ve çözüm önerileri odağında geçer. Bu kriterlerdeki ufacık bir bilgi bile kullanıcıların kafasından geçenleri anlamak için gerekli ve önemlidir. Bununla birlikte kullanıcıların bu sistemi kullanma hedefleri, bu sürecin verimli olmasında ve fonksiyonel gereksinimlerden tasarım arayüzlerinin çıkarılmasında oldukça etkilidir.

Açığa Çıkaran Sorular Sormak

Analist olarak çalışırken, kullanıcılarla yapılan oturumları kolaylaştırmak ve basitleştirmek gerekir. Müşteri temsilcisinin  daha önce hiç bahsetmediği bir görev hakkında alternatif yolları deneyerek kullanıcılara sorular sormak ve diğer görevlerle olan ilişkileri ortaya çıkarmak gerekir. Kullanıcının sorulara verdiği cevaplar o senaryo için olmazsa olmaz ve yapılsa iyi olur gibi ifadeler içerir. Böylece kullanıcı senaryolarının da iş akışı ortaya konulmuş olur. Kullanıcılar, sistemin doğru ve beklenildiği gibi çalışmasına odaklanırlar. Analist bunun yanı sıra beklenilmeyen durumlar için de uygun senaryoları hazırlamalıdır.  Hata durumlarında uygulama geliştiricinin ele alması gereken kontrolleri, zaman zaman kullanıcılardan da yardım alarak tanımlamalı ve hata durumlarını yönetmelidir. Bu öncelikle sistemin güvenilirliği ve tutarlılığı açısından önemlidir.

Yaratıcı ve bilgili bir analist, kullanıcıların söylediklerini birebir kaydetmek yerine alternatif bakış açıları ve öneriler sunar. Kullanıcılar bazen uygulama geliştiricilerin yeteneklerinin farkında olmayabilirler. Önerilecek fikirler ile sistemin daha kullanışlı olması sağlanabilir. Zaman zaman da kullanıcıların iş yapışını izleyerek, otomatikleştirilebilecek olan süreçler hakkında bilgiler verilerek, kullanıcıların sistemin kullanılabilirliğine olan bakışı arttırılabilir. Önceki sistemlerde kullanılmış bir fonksiyonel yapının tekrar kullanımının sağlanması, kullanıcıların gereksinimlerini yeniden gözden geçirmesini ve düzenlemesini sağlayacak ve yeni yapılar üzerinden yeni gereksinimleri düşünecektir.

Etkili bir analist birçok düzeyde soyutlama yapabilmelidir. Kullanıcının bildirdiği belirgin özellikteki gereksinimlerin, diğer kullanıcıların gereksinimleri ile ilgili olup olmadığını ve aralarındaki ilişkileri sağlamalıdır.  Bir konudaki önemli noktaları ortaya çıkarmak, belirsizlikleri yok etmek, anlaşmazlıkları ortadan kaldırmak, öngörü ve varsayımları belirlemek, beklentileri karşılamak için soru sorma sanatına hakim ve yetenekli olmak gerekir ve bu da çoğunlukla tecrübeye dayanır.

Önceliklendirme

Gereksinim geliştirme süreci, bulanık, her bir aşama için belirsiz tanımlardan detaylı belirtimlere giden döngüsel-artımlı bir süreçtir. Her aşamada doğru soyutlama düzeyine odaklanmak gerekir. Birden tasarıma dalmak veya detaylara girmek, sistemin ve sürecin hataya düşmesine neden olabilecektir. Kullanıcı arayüz ekranlarından veya prototiplerden gereksinimleri ortaya çıkarmak ve her aşamada gerektiği kadar detaya girmek sistemi doğru anlamak açısından önemlidir. Temel yapılması gereken şeylerin yapılmamış ve daha az önemi olan özelliklerin yapılmış olması, yazılım takımının cesareti kırıp, müşteriye ümitsizliğe yöneltir. Bu sebepten analist elde ettiği gereksinimleri önceliklendirmelidir. Herkes kendi işini çok önemli ve öncelikli görür. Analist bu noktada tüm kullanıcı sınıfları ve geliştiriciler arasında gerekli iletişim ve işbirliğini sağlayarak hassas öncelikli kararları almalıdır.

Gereksinim geliştirmede öncelikle katkıda bulunabilecek kullanıcı sınıfları oluşturulmalıdır. Bunu yaparken beğenilen, gözde ve beğenilmeyen gruplarla gereksinim geliştirmeye katkıda bulunmayacak grupları ayırt etmek gerekecektir. Tabii olarak beğenilen ve gözde sınıfın gereksinimleri de varolan çatışmalardan arındırıldıktan sonra öncelikli olacaktır.

Devam edecek.