Analiz Dokümanlarının Berbat Olmasının 6 Sebebi

Analistler, gereksinim yazmayı bilmiyor mu?

Tabi ki de biliyorlar. İş hayatına yeni başlayan bir analist, kimse ona yol göstermese bile, ilk ayının sonunda bir gereksinimin nasıl yazılması gerektiğini teorik olarak çok iyi bilir. Ama pratikte, o gereksinimler, işe yeni başlasa da yılların analisti olsa da hakkını vererek yazılmaz. Tahmin edeceğiniz üzere, bu yazımda gereksinimlerin nasıl yazılması gerektiği ile ilgili teorik bilgiler vermeyeceğim. Bunları zaten biliyorsunuz. Bilmiyorsanız da internette minik bir arama yaparak bu bilgilere ulaşabilirsiniz. Bunun yerine, gereksinimlerin özelliklerinin çok iyi bilinmesine rağmen neden berbat gereksinimler yazdığımızın bazı sebeplerinden bahsedeceğim.

  1. Gereksinimi, tanımına uygun yazmak zor gelir: Analist, aklındakini olduğu gibi yazmaya meyillidir. Bazen tuttuğu toplantı notlarını gereksinim diye yazar, bazen de talep sahibinin liste olarak gönderdiği maddeleri kullanır. Uzun uğraşlarla talep sahiplerinden topladığı bilgileri, bir de atomik, herkes tarafından aynı anlama gelen, açık, net ve test edilebilir şekilde yazmak analistler için bir angarya olarak kabul edilir.
  2. Business Domain’in, yapılan işin merkezinde olması: Analistler, özellikle sürekli aynı sektör ile ilgili projelerde çalıştıklarında, belli bir süre sonra, farkında olmadan, yaptıkları işin merkezine Business Domain’i koyarlar. Analiz aktiviteleri ikinci plana atılır. Evet, Business Domain, analistler için çok önemlidir. Projesini yaptığınız iş alanını çok iyi (hatta iş birimlerinden daha çok) bilmek zorundasınız. Ama analistin özelliği hem iş alanını hem analiz aktivitelerini birlikte yürütmesidir. Analiz aktivitelerinin ortasında da gereksinim vardır.
  3. Analistlerin, işin sonundaki başarıya odaklanması: Proje canlıya alınmış, iş birimleri şimdlik memnun. E-Mail’ler atılıyor. Talep sahibi ve yazılım geliştirme ekibine tebrikler yağıyor. Yöneticilerin, sponsorların CC’de olduğu E-Mail’lerde analistin de adı geçiyor. Ne kadar güzel değil mi? Bu zaten istemediğimiz bir şey değil. Ama odağımız sadece bu olmamalıdır. Analiz aktivitelerinin doğru yapılması zaten başarıyı beraberinde getirecektir. Ortaya çıkan üründe bir problem olduğunda fatura önce geliştirme ekiplerine kesilecektir. Böyle durumlarda detaya bakıldığında gereksinimlere yeteri kadar önem verilmediği görülebilir.
  4. Analistlerin, test yapmaya kendi gereksinimlerinden başlamaması:  Gereksinimlerin, gereksinimin tanımına uygun yazmaya çalışıldığını düşünelim. Yani yukarıdaki ilk 3 maddedeki hataların yapılmadığını varsayalım. Buna rağmen, eğer analist kendi yazdığı gereksinimleri tekrar tekrar okuyup, eksiklerini bulup düzeltmediği sürece yine başarısız analiz dokümanları ortaya çıkacaktır.
  5. Gereksinimlerin, süreci ilerletmek için gereken birkaç cümle olarak görülmesi: Çalıştığınız kurumun proje süreçlerinde mutlaka “Analiz Dokümanının Oluşturulması” gibi bir süreç vardır. Analist, bu “angarya” olan süreci hızlı ilerletmek için, gereksinimlerin kalitesine dikkat etmeden, yazıp geçer. Oysa, gereksinimler projenin geliştirme ortamındaki kodları kadar önemlidir.
  6. Analiz dokümanına ayıracak yeterli vaktin olmaması: Analistler her zaman acele ederler. Projeyi, planlanan tarihe yetiştirmeye çalışırlar. Bunu da, aslında en önemli adım olan gereksinimlerden vakit çalarak yürütmeye çalışırlar.

Fail olan projelerde, bazen “neden böyle oldu anlamadım” deriz değil mi? Eğer öyle diyorsanız bu yazıyı baştan bir daha okuyun derim.

Reklamlar