İş Analizinde Yapılan Hatalar

İş Analizi:

BABOK’ta yer alan tanıma göre iş analizi,

“kurumların iş yapısını, iş kurallarını, iş süreçlerini çözümlemek, sorunlar ve fırsatlar için çözümler üretmek, çözümleri oluştururken çeşitli fonksiyonel birimler ile çalışarak gerçekleştirilen, gerektiğinde bütünleştirici bir görev ve teknikler bütünüdür.”

 

Yazılım gereksinimlerinin çözümlenmesi, iş süreçlerinin yeniden ya da ilk defa yapılandırılması gibi çalışmalarda gerçekleştirilen iş analizi çalışmaları birbirini izleyen 3 aşamadan oluşur:

1. Hazırlık Aşaması
2. İş Analizi Bilgilerinin Toplanması
3. İş Analizi Bilgilerinin Uygulanması

 

Tanımı ve adımlarına bakıldığında bu kadar kolaymış gibi görünen iş analizi, özellikle de yazılım projeleri ele alındığında, çok zor bir iş haline gelmektedir. Yazılım projelerindeki başarı oranını doğrudan etkileyen iş analizini daha etkin ve doğru şekilde yapmak için, genelde yapılan hataları bilmekte ve bunlara göre hareket etmekte fayda vardır.

 

Peki, Bu Analiz Sürecinde Yapılan Hatalar Nelerdir?

 

 

Bir yazılım projesinin en kritik safhalarından biri “analiz”dir. Bir projenin en zor sorusu “neye ihtiyacımız var?” yani “projemizin çıktısı olacak yazılım sisteminden ne bekliyoruz”dur. Bu sorunun cevabı kritiktir, çünkü kendinden sonra gelecek her türlü yazılım geliştirme faaliyetinin içeriğini belirler. Buradaki bir eksiklik veya hata, büyüyerek, ortaya çıkacak yazılım sisteminde büyük bir probleme dönüşecektir.

 

• İhtiyacın doğru belirlenmemesi:
  • Bir yazılım projesinin başlaması için ortada bir “ihtiyaç” olması gerekmektedir. Eğer projemiz başlıyorsa muhtemelen bir ihtiyacı görmüşüzdür ve bunu karşılamaya çalışıyoruzdur. Bu ihtiyacın doğru belirlenmesi her şeyin başlangıcıdır.

 

• Gereksinimler yeterince etkin bir şekilde toplanamayıp analiz edilememesi
  • Bu durumda projenin kapsamı net ve eksiksiz belirlenemez; dolayısıyla zaman, maliyet ve kaynak planı yapmak pek de mümkün olamaz.

 

• Analiz toplantılarına hazırlıksız katılmak
  • Karşımızdaki kişililer hayatlarında ilk defa bir yazılım projesi analizinde bulunuyor olabilirler. Dolayısıyla analiz sürecine ve müşteriye yön verecek kişi analist olmalıdır. Bunun için analize başlamadan önce kendimize bir yol planı çizip analiz süresince buna uymaya çalışmalıyız.

 

• İşi tam olarak anlamadan çözüm üretmek
  • Analiz süresince çözüm önermeden önce, işi doğru ve tam olarak anlamak gerekmektedir.

 

• Büyük ve karmaşık süreçleri parçalara ayırmadan çözümlemeye çalışmak
  • Eğer anlatılan iş, bütün olarak ele alınamayacak kadar büyük ve karmaşık süreçleri içeriyorsa, parçalara ayırarak çözümlenmelidir. Ama daha sonra sistemsel bakışı sağlamak, entegrasyon noktalarını ve bağımlılıkları da belirlemek şarttır.

 

• İşin uzman kişilerden dinlenmemesi
  • İşi anlatan kişilerin uzmanlık seviyeleri önemlidir; eğer işin ehli kişiler dinlenmezse, soracağımız sorulara net cevaplar alamayız. İşi eksik ya da yanlış öğrenme riskimiz ortaya çıkar. Bu ise en tehlikeli iki noktadır. Çünkü eksik kalan ya da yanlış olan bilgi belki de bizim bütün yazılım geliştirme sürecimizi etkileyecek ölçüde önemli bir bilgi olabilir.

 

• İletişim eksikliğinden dolayı bilgiyi tam ve doğru alamamak
  • Burada vurgulanmak istenen bizim iletişim kurma yeteneğimizdir. Eğer işi anlatan kişilerle aramızda iyi bir iletişim zemini kuramazsak bilgiyi doğru ve tam olarak alamayabiliriz. Profesyonelliği elden bırakmadan, işi bize anlatan kişi veya kişilerle kuracağımız ilişki en önemli noktalardan birisidir.

 

• Toplan­tılarda not almamak
  • Çok basit ama nedense dikkat edilmeyen bir noktadır; paydaşı din­lerken gerekli notlar alınmalıdır.

 

• Toplan­tılarda belirsizlik
  • Aklımıza takılan her noktada müşteriye “Burası kesinlikle böyle mi?”, “Böyle olmadığı durumlar var mı?” gibi soruları yönelterek analizi netleştirmeliyiz. Çünkü en büyük sorunumuz belirsizliktir.

 

•  Analizde anladıklarımızı belirli aralıklarla onaylatmadan ilerlemek
  • Analiz sırasında müşteri işi aktarırken, konuyu anladığımız şekilde özetleyerek belirli aralıklarla onaylatmalıyız.

 

• Süreçteki istisnai durumların önceden tahmin edilememesi
  • Gerçek hayatta çok az gerçekleşen bir koşulun analiz sırasında aktarılamaması söz konusu olabilir. Analizi yapan kişinin bu istisnai durumu öngörmesi genellikle çok zordur. Bu durum uygulama kullanılırken ortaya çıktığında, bir geliştirme süreci sonunda uygulamaya bu özelliğin katılması gerekmektedir.

 

• Toplantı tutanağını onaylatmamak
  • İşi anlatanın bize anlattıklarını mutlaka bir toplantı tutanağı ile dokümante etmeliyiz. Daha sonra, bu toplantı tutanağında aldığımız notları bu sefer kendi cümlelerimizle yeniden yazarak paydaşımıza gönderip, yazdıklarımızı teyit etmesini istemeliyiz.

Bizim kendi cümlelerinizle ifade ettiklerimizi paydaşımızın onaylaması, artık aynı şeylerden aynı şekilde bahsettiğimiz anlamına geleceği için önemlidir. Acaba doğru mu anlamışız? Eğer paydaş, “Hayır şu noktayı yanlış anlamışsınız” derse o noktaya yeniden dönmeli, gerekirse tekrar görüşüp gerekli değişiklikleri yaparak paydaşa yeniden göndermeliyiz.  Artık bu noktadan sonra paydaş bize “Ben onu size böyle anlatmamıştım” diyemez. Böyle bir durumda elimizde, paydaşa karşı ileri sürebileceğimiz ve dokümante edilmiş bir belgemiz vardır, bu dokümanı gösterebiliriz. Hem de bu bizim için bir yapılacaklar listesi olur. Onaylaması durumunda, bir sonraki aşamaya geçebiliriz.

 

• Paydaşı doğru yönlendirememek
  • Buna en can alıcı madde diyebiliriz. Paydaş bizden yazılıma bir özel­lik eklem­emizi iste­diğinde bunun nasıl olması gerek­tiğini sorgu­la­yarak onu doğru yönlendirmeliyiz.

• Paydaşı düzenli olarak bilgilendirmemek
  • Paydaşı düzenli ve yazılı olarak (e-posta ile) bil­gilendirmeliyiz. Biz bir nok­tada takıldıysak bunun hakkında soru sor­mak için bir son­raki toplan­tıyı bek­le­meyip, eğer paydaşımız e-postalarımızı hızlı ve ayrın­tılı bir şek­ilde cevap­lıyorsa e-posta ile sorumuzun cevabını almalıyız. Eğer sorumuzun cevabını telefon veya yüz yüze görüşerek aldıysak daha sonra konuşu­lanın bir özetini e-posta ile yeniden göndermeliyiz.

• Mock-up kullanmamak
  • Mock-up kul­la­narak yazılım ekib­ine daha net bir şek­ilde ne yapıla­cağını anlat­makla kalmaz, aynı zamanda paydaşın da ortaya çıka­cak nihai ürünün neye ben­zeye­ceğini bilmesini sağlarız. Oluşturulmuş formları ve sayfaları içlerinde kontroller ile gören müşteri, analizde yanlış aktardığı iş kurallarını farkedebilecek, kullanım kolaylığı bakımından nasıl bir dizayn kullanılması gerektiğini analiz aşamasında söyleyecek, uygulama geliştirme aşaması bittiğinde kullanımının nasıl olacağını tahmin edebilecektir. Bu sebe­ple, ortaya çıkardığımız mock-up’ı paydaşımızın teyit etmesini sağlamalıyız ki ne onlar ne de biz bir sürpriz ile karşılaşmayalım.

 

• Analizden sonra gelecek istekleri versiyonlamamak
  • Analiz aşamasının sonunda hazırladığımız analiz dokümanının müşteriye onaylatılması sırasında bu noktadan sonra gelecek yeni isteklerin projenin sağlıklı yürümesi ve teslim zamanına yetişmesi için mutlaka ikinci versiyona bırakılması gerektiğini bildirmeliyiz.

 

Sonuç olarak:

İş analizi, yazılım çözümü geliştirmede en önemli adımlardan biridir. İşle ilgili sorunlara uygun çözümleri belirlemek için, müşterilerin ihtiyaçlarını doğru belirlemek çok önemlidir. İhtiyaçların belirlendiği iş analizi süreci, yazılım geliştirme akışının en başında yer aldığı için, bu sürecin yanlış ilerlemesi ondan sonraki adımları da etkileyecektir.

Gizem Cönger

Kaynak: http://www.projeyonetimiofisi.com/bilgi-birikimi-makale-detay?makaleId=25

Reklam