6 Şubat 2014 Perşembe

İş Modeli ve yazılım geliştirme ilişkisi

 Yazılım geliştirme süreçlerinde proje yönetimi standartlarının etkin bir şekilde kullanılmaması sonucu iş modelinin ve yazılım geliştirme süreçlerinin çatışması kuvvetle muhtemeldir..

 Genelde pek fazla zamanınız yoktur, ve yapılacak geliştirmenin son hali, yaratacağı etki net olarak tahmin edilememektedir. Toplantılar yapılır, iş modeli için ne tür bir geliştirme olması gerektiği belirtilir. Daha sonra geliştirme süreci başlar. Ancak bir süre sonra geliştirmesine başlanmış yada tamamlanmış bir işlemin iptal edilmesine yada değiştirilmesine karar verilir.

 Geliştirme için yapılan toplantılardaki kararlara sadık kalınmamıştır, ama müşteri yada yönetici haklıdır. Çünkü toplantıda  sadece teorik analizlere göre kararlar alınmıştır. İş pratiğe geldiğinde yapılan aksiyonun istenilen sonucu vermediği yada vermeyeceği düşünülmüş ve bir takım aksiyonların güncellenmesi gerekmektedir.

 IT ekibinde bu karar pek hoş karşılanmamıştır. Çünkü bu işlem projenin bir çok bölgesini etkileyebileceğinden tekrar mantık haritası çıkarılması gerekmektedir. (Yazılan kodların değiştirilmesi, veritabanının yeniden tasarlanması vb. gibi.)

 Eğer yapılacak proje yada geliştirme orta yada büyük ölçekli bir işlem ise bir süre sonra geliştirme süreci tıkanır ve sinirler gerilir. Her iki taraftan da birbirini suçlayıcı ifadeler gelmeye başlar, iş geliştirme istedikleri bir değişikliğin bu kadar uzun sürmemesi gerektiğini düşünür, yazılım geliştirme departmanı ise istenilen taleplerin değiştirilmemesi gerektiğini düşünür. Aslında her iki taraf da haklıdır.

 Çözüm?
  İş geliştirme ve yazılım geliştirme süreçlerinin bir standart a bağlanması ve tarafların da bu standartlara katı bir disiplin ile uyması gerekmektedir.

Nedir bu standartlar? 

 Proje yönetiminde yukarıda bahsettiğim gibi sorunları ortadan kaldırmak için geliştirilen modeller vardır. Detaylı bilgiye buradan ulaşabilirsiniz.
 Ben kısaca en sevdiğim ve Türkiye şartlarına en uygun model olarak gördüğüm Spiral model den bahsetmek istiyorum. Bu modelde projenin bir başlangıcı vardır, ancak bitiş zamanı yoktur.

  Her bir geliştirme bir iterasyondur. Talepler gelir, geliştirme yapılır,yayınlanır, sonrasında iş modeline uygunluğu test edilir. Bu işlemlerin sonucunda bir rapor çıkartılır. Yapılan geliştirmenin ne derecede faydalı olduğu uygulamalı olarak analiz edilir. Bu analizlere göre tekrar bir iterasyon planı yapılır. Süreç bu şekilde proje istenilen seviyeye gelinceye kadar devam eder.

 Bu model yukarıda bahsettiğim sorunları ortadan kaldırdığı gibi yazılım geliştirme ve iş geliştirme ekibinin performansının da ölçeklenebilmesini sağlar. Çünkü model sizi her iterasyonun kayıtlarını tutmaya zorlayacak ve bu kayıtlar üzerinde de kimlerin etkinliğinin ne şekilde olduğu açık bir şekilde görüntülenebilecektir.

 Spiral model hangi tür durumlarda kullanılmalıdır?
 Eğer projeniz yada yapılacak geliştirme daha önce kullanmadığınız özellikler içeriyorsa, ve yapacağınız aksiyonları yapmış birilerinden iş modeli hakkında danışmanlık almamışsanız, yaptığınız projenin kullanılabilirliğini hiç bir zaman net olarak bilemezsiniz. Çünkü uygulamalı tecrübeden gelen net datalarınız yok. Teorik, bu olursa böyle olur gibi tahminleriniz var. Örnek olarak start-up projelerini gösterebiliriz.

Spiral model hangi tür durumlarda kullanılmamalıdır? 
 Eğer yaptığınız projeyi daha önce birkaç kez tekrar yapmışsanız, ve elinizde yapılmış projenin kabul edilen sonuçları varsa bu modeli uygulamaya gerek yok, burada waterfall model kullanabilirsiniz. Bunun sonucu size + zaman olarak yansıyacaktır. Örnek olarak paket program satılan bir firmayı düşünebiliriz.