Sporda Dijital Dönüşüm Projesi

Spor Genel Müdürlüğünün artan ihtiyaçları ve teknolojik gelişmelerin iş süreçlerine uygulanarak kamu hizmetlerinin sorunsuz, hızlı, güvenilir ve sağlıklı işletilmesine imkân sağlaması sebebiyle Spor Genel Müdürlüğünün tüm faaliyetlerini kapsayacak şekilde “Sporda Dijital Dönüşüm Projesi” Kasım 2014 tarihinde başlatılmıştır.

Bu proje kapsamında Gençlik ve Spor Bakanlığı Bilgi İşlem Dairesi ve Spor Genel Müdürlüğü Strateji Geliştirme Dairesi Bilgi İşlem Şubesi personellerinden oluşan 8 kişilik proje ekibi tarafından Spor Genel Müdürlüğünün 25 biriminde yüz yüze yazılım analizi çalışmalarına başlanmıştır.

Tüm bu birimlerde yapılacak detaylı iş analizi çalışmaları sonucunda birimlerin ve faaliyetlerinin ihtiyacı olan teknik gereksinimler ve yazılım gereksinimleri ortaya konup fazlar halinde işlerin önceliğine bakılarak gerekli dijital sistemler devreye alınacaktır.

Bu proje kapsamında yapılan ön analiz çalışmaları 255 sayfalık Analiz Rehberi Raporu olarak konsolide edilmiştir. Bu rapor içeriği Spor Genel Müdürlüğü birimlerinden katılacak 100 kadar personelle “4-5 Nisan 2015 tarihinde Antalya’da yapılacak Rehber Çalıştayı” ‘nda kurum personelinin görüşüne açılacaktır. Görüşler sonucu ortaya çıkacak ihtiyaç önceliği sırasına göre detaylı iş süreç analizleri planlanacaktır. Yapılan planlama sonrası gerçekleştirilecek detaylı analiz çalışmaları sonrasında da süreç iyileştirme çalışmaları için Mayıs ayı sonunda Dönüşüm Çalıştayının daha geniş katılımla gerçekleşmesi beklenmektedir.

Spor Genel Müdürlüğü yazılım ihtiyaçlarının fazlar halinde analiz edilerek geliştirileceği bu projede ilk faz çalışmalarının 2015 yılı 3.çeyreğinde, ikinci faz çalışmalarının 2015 yılı sonunda ve ağırlıklı olarak sunulan hizmetlerin e-devlet hizmetine dönüştürülmesinin hedeflendiği üçüncü faz çalışmalarının da 2016 yılı ilk yarısında bitirilmesi hedeflenmektedir.

Bu proje kapsamında yapılacak çalıştay için biz BABOK’ın ilgili bölümünü rehber edindik.

Yine çalıştay sonuçlarını sizinle buradan paylaşacağım.

Reklam

KYK Değişim ve Dönüşüm Çalıştayı ve Tekniğimiz

PMBOK ve BABOK’dan yararlanarak yönettiğimiz ve yönlendirdiğimiz projemizde; Gereksinimlerin netleştirilmesi için Süreç İyileştirme aşamasında Çalıştay ile çalışmalarımıza devam ediyoruz.

Çalıştayımızda uygulayacağımız tekniğin detaylarını aşağıdaki gibi belirledik.

1.ADIM GENEL BİLGİ VERME

Süresi: 10 dk.

Süreçlerden sorumlu Proje Analisti sürecin kapsamı, işleyişi ve paydaşları hakkında bilgi verir.

Salon Koordinatörü uygulanacak tekniği katılımcılara anlatır.

2.ADIM SORUNLARI TESPİT ETME

Süresi:20 dk.

İlk 10 dakika; Masalardaki Proje Analistleri ve raportörler daha önceden tespit ettikleri sorunları masadakilerle paylaşır. Raportörlerin koordinasyonunda, masa katılımcıları kendilerine dağıtılan süreçlerin aşamaları bazında sarı renkte post-it’lere süreçte gördükleri sorunları her soruna bir kağıt olacak şekilde keçeli kalemle büyük harfle kısa özet şeklinde yazar. Proje analistleri, raportörler ve salon koordinatörleri katılımcılara yardımcı olur.

Son 10 dakika; Proje Analisti balık kılçığı tekniğini kısaca tarif ettikten sonra masa katılımcılarının bulduğu sorunları post-it’lerden sesli okuyarak, balık kılçığı diyagramını yeterince büyük şekilde duvarda ayrı bir alana yapar. Raportör Balık kılçığındaki sorunları ve kırılımları Süreç Aşamalarına göre detaylı numaralandırarak not alır. Bu notları ayrı bir yerde herkesin göreceği şekilde yazılır. Salon koordinatörleri masalar arasında varsa farklı sorunlar diğer masalarında kılçığına bu farklılıkları yazmasını sağlar.

3.ADIM ÇÖZÜM BULMA

Süresi: 30 dk.

İlk 15 dakika; Masa katılımcıları tespit edilen her soruna karşılık sorun numarasıyla beraber çözüm önerisi özetini her post-it kağıdına bir çözüm önerisi gelecek şekilde yazar. Proje analistleri, raportörler ve salon koordinatörleri katılımcılara yardımcı olur.

Son 15 dakika; Proje Analisti yazılan çözümleri aşama bazında sorun numarasına göre sırayla okuyarak masa katılımcılarına oylamaya sunar, raportör sorunlara karşılık gelen önerileri oylarıyla beraber not alarak sıralar. Çözüm önerilerinin fazla olması durumunda raportör en fazla oy alan 5 öneriyi (eşitlikle sayı artabilir) masa kararı olarak 4.Adımda dile getirebilir.

4.ADIM ÇÖZÜMLERİ KONSOLİDE ETME

Süresi: 30 dk.

Salon koordinatörleri süreç aşamalarına göre sırayla masa raportörlerine söz vererek çözüm önerilerini salon raportörüne not aldırır. Alınan notlar salon katılımcılarına sesli ifade edilerek varsa görüş ve itirazları çok uzun tutulmadan değerlendirilerek not alınır.

Gerekli Malzemeler:

1. Katılımcı sayısının 2 katı kadar sarı ve beyaz (iki farklı renkte ), ortalama avuç içi büyüklüğünde (76X127) POST-IT Not Kağıdı
2. Katılımcı sayısından 50 fazla Siyah Keçeli Kalem
3. Masa Sayısı kadar Duvar Alanı, Flip Chart, 2 katı kadar iki farklı renkte Tahta Kalemi
4. Masa Sayısı kadar Proje Analisti, Masa Raportörü, Laptop (Raportör Kullanımı için)
5. Salon Sayısı kadar Salon Koordinatörü, Salon Raportörü

 

BALIK KILÇIĞI TEKNİĞİ

Balık kılçığı diyagramı, bir örgütün süreçlerinde ve sistemlerinde ortaya çıkan problemleri ve bu problemlerin doğmasına neden olan temel sebepleri belirlemeye yardımcı olur. Bu yapıda, temel problemleri doğuran nedenlerin yanı sıra bu nedenlerin nedenleri de analize tabi tutulur. Analizin sonucunda problemler kökenlerinden itibaren çözülmeye başlanır.

Örnek Çıktı Şablonu

SÜREÇ İSMİ
Aşama1			Aşama…			AşamaN
Sorun1	Çözüm1	Oy Sayısı	SorunN	Çözüm1	Oy Sayısı	SorunN	Çözüm1	Oy Sayısı
	…	Oy Sayısı		…	Oy Sayısı		…	Oy Sayısı
	ÇözümN	Oy Sayısı		ÇözümN	Oy Sayısı		ÇözümN	Oy Sayısı
SorunN	Çözüm1	Oy Sayısı	SorunN	Çözüm1	Oy Sayısı	SorunN	Çözüm1	Oy Sayısı
	…	Oy Sayısı		…	Oy Sayısı		…	Oy Sayısı
	Çözüm1	Oy Sayısı		Çözüm1	Oy Sayısı		Çözüm1	Oy Sayısı

Projelerde Paydaş Yönetimi Süreci

Projelerde Sorumluluk Atama Matrisi (Responsibility Assignment Matrix (RAM)) İş Analizi ve Proje Yönetimi süreçlerinin olmazsa olmaz unsurlarından bir tanesidir. Sorumluluk Atama Matrisi Projede görev alacak Ekibi Üyelerini belirlemekte ve Proje kapsamındaki görevlerini tanımlamaktadır. Gereksinim Toplama, Gereksinim Yönetimi ve İletişimi süreçlerinde İş Analistleri Paydaşlar ile birlikte çalışmakta ve bu kapsamda Paydaş Yönetiminde en önemli görevler İş Analistlerine düşmektedir. Bu yazımızda başarılı bir Paydaş Yönetimi gerçekleştirmek için tavsiyelerimizi sizlerle paylaşacağız.

1. Paydaşlarımız kimlerdir?
Paydaş belirleme süreci kolay bir görev olarak gözükmekle birlikte her zaman atlanan paydaşlar olabilmektedir. Özellikle Projeden doğrudan etkilenmeyen organizasyon üniteleri veya kişiler Paydaş belirleme sürecinde unutulmaktadır. Proje çıktısı ürün veya hizmet ile doğrudan bağlantısı olmayan ama dolaylı olarak ürün veya hizmet ile ilgili bilgilerden etkilenen paydaşları gerek Paydaş Belirleme sürecinde gerekse Gereksinim Toplama sürecinde mutlaka Projeye dahil etmek için dikkatli analiz yapmamız gerekmektedir.
2. Paydaş Beklentilerini nasıl yöneteceğiz?
Proje Yönetmek sadece kaynakları, kapsamı, zamanı ve riski yönetmek demek değildir. Proje Yönetmek aynı zamanda beklentileri yönetmek demektir. Paydaşların beklentileri Proje çıktısı olan ürün veya hizmet ile ilgili olup, beklentileri tespit etmek “çözümden ne bekliyorsunuz” sorusu ile mümkün olsaydı biz İş Analistlerinin işi çok daha kolay olurdu. Beklentilerin toplanması çoğu zaman atlatmaktadır ve genellikle kendi tecrübelerimiz doğrultusunda tamamen göreceli olarak beklentiler ile ilgili varsayımlar oluşturmaktayız. Paydaşların Proje ile ilgili beklentilerini sahiplik, ilgi, etik ve yasal olmak üzere dört temel kavram altında toplayabiliriz ve bu beklentiler göz ardı edilemeyecek niteliktedir.
3. Paydaş Grupları ile İletişimimizi nasıl yönetmeliyiz?
Paydaşların projeye ilgi düzeyi ve Proje üzerine olası etkisi Paydaş Yönetimi sırasında odaklanacağımız kitleyi ve yönetim tarzımızı belirlemekte kullanılmakta olup, bu model Paydaş Yönetimi sırasında dikkate almamız gereken temel unsurlardan bir tanesi olan aciliyetin etkisini göz ardı etmektedir. Aciliyet boyutunu Paydaş Etkisi ve İlgisi Izgara Şemasına (Stakeholder Influence and Interest Grid) eklediğimiz takdirde Güç Meşrutiyeti ve Aciliyeti Modelini (Power Legitimacy and Urgency Model) elde etmiş oluruz. Bu model önceliklerin doğru anlaşılması ve odak noktalarının doğru belirlenmesinde daha gerçekçi bir analiz fırsatı sunmaktadır.
4. Verimli Paydaş İletişimini nasıl oluşturabiliriz?
Paydaş İletişiminin Paydaş ihtiyaçlarına uygun olarak planlanması gerekmektedir. İletişimi doğru yönetebilmek için Proje Planlama sürecinde Paydaş gruplarının hangi bilgiyi, hangi detayda, hangi sıklıkta istediğinin analiz edilmesi gerekmektedir. Gereksinim Yönetimi sürecinden sorumlu İş Analistlerinin bu planlamayı Paydaşlar ile birlikte gerçekleştirmesi gerekmektedir.
5. Paydaşlarımızın zaman ayırmasını nasıl sağlayabiliriz?

Zaman yönetimi özellikle projelerde görevlendirilmiş paydaşların operasyonel sorumlulukları devam ediyorsa problem oluşturan konulardan bir tanesidir. Müzakere ve biraz zorlama ile paydaş katılımını güvence altına almak genellikle gereklidir.
6. Değişim sürecinde Paydaşlarımıza nasıl yardımcı olabiliriz?
Tüm Projeler değişimi tetikler. Değişim yönetimi kapsamında kullanılabilecek etkili yollardan bir tanesi ADKAR Yaklaşımıdır. ADKAR yaklaşımı Farkındalık (Awareness), İstek (Desire), Bilgi (Knowledge), Yetenek (Ability), ve Destek (Reinforcement) unsurlarının oluşturulmasına dayanmakta olup, değişim yönetiminde basit, güçlü ve amaç odaklı bir yöntemdir. Proje başarısı için biz İş Analistlerinin Paydaşlarımızı ve Organizasyonumuzu değişime hazırlamamız gerekmektedir.
7. Paydaş Yönetimi başarısına birey olarak nasıl katkı sağlarız?
Yapılan çalışmalar yapıcı, destekleyici ortamın sağlandığı ve takım ruhunun oluşturulduğu ortamlarda iş sonuçlarına daha hızlı ulaşıldığını ve iş kalitesinin artığını göstermektedir. Projelerde de paydaşlar arasında kurulacak yakınlık, sosyal ilişkiler, güven ortamı ve takım bilinci Paydaş Yönetimi Başarısı ve dolayısıyla Proje Başarısı üzerinde doğrudan etki etmektedir.
8. Paydaşlarımızın birey olarak ihtiyaçları nedir?

Projeler üzerinde kaynak, zaman ve maliyet açısından ciddi baskılar söz konusudur. Çoğu zaman bu kısıtları göz önünde bulundurarak kendimizi ve Projeyi koruma altına almak adına daha yanlı bir tutum sergileyebiliyoruz. Ancak, Paydaş gereksinimlerini ve beklentilerini doğru tespit edebilmek ve yönetebilmek için Paydaş bakış açısı ile Projeye bakabilmeyi becermemiz gerekmektedir. Bunu yapabildiğimiz takdirde, Paydaşların güven duygusu, katılımları ve destekleri artacak sonuç, Proje Başarısı üzerine pozitif etki yaratacak.

 

Kaynak:http://www.thebasolutions.com/blog-projelerde-paydas-yonetimi-sureci-basarisi-72

İş Analizi Ekip Yönetimi Nasıl Olmalı

İş Analizi Ekip Yöneticileri uygulama odaklı bakış açısına sahip olmalıdır. Kendilerine bağlı çalışanlara katkı sağlamaları için ekip üyelerinin yetkinliklerini çok iyi bilmeleri, güçlü ve zayıf yönleri için eğitim planları hazırlamaları gerekmektedir. Bunun için yöneticilerin de iş analizi uygulama yetkinliklerinin gelişmiş, kullanıyor ve güçlendirmeye devam ediyor olmaları gerekir. İyi bir yönetici olabilmek için koçluk, mentorluk ve eğitim becerilerinin de bulunması gerekir. Ayrıca ekip üyelerine açık ve samimi iletişim ortamı sağlanması çalışma ortamı iyileştirecek ve ekip bilincine sağlayacaktır.

İş Analizi Ekip Yöneticisinin Temel Görevlerini özetlemek gerekirse;

İşe Alım: İş Analizi Ekip Yöneticileri ihtiyaç durumunda ekibi güçlendirmek için işe alım süreçlerinde aktif rol alır. Bu süreçte Yöneticilerin sadece iş analizi yetkinliklerine sahip adaylara değil, aynı zamanda stratejik ihtiyaçlara uygun ve kurum kültürüne adapte olabilecek adayları değerlendirmesi gerekmektedir.

Oryantasyonu ve Eğitim. İşe alım süreci sadece başlangıçtır. Ekibe yeni katılan üyelerin başarı gösterebilmesi için çaba gösterilmesi gerekiyor. Yeni katılımların oryantasyon süreçlerinin alan bilgisi eğitimi, devam eden projelerde süreç gözlemi ve projelerde bağımız görev verilerek adapte edilmesi ile desteklenmesi gerekmektedir.

Koçluk, Ekip ve Kişisel Gelişimin Desteklenmesi. Yöneticilerin ekip üyeleri ile birebir görüşmeler yapması gerek yöneticiler gerekse ekip üyeleri için ciddi katkı sağlamaktadır. Bu katkıyı sağlamak için önerebileceğimiz bir yaklaşım ekip üyelerine gündeme getirmek istedikleri konular ile ilgili toplantı ajandasını belirleme görevinin verilmesidir. Birebir görüşmeler sırasında ekip üyelerinin gündeme getirmek istedikleri konular dışında yöneticiler ekip üyelerinin çalışma yöntemleri, proje paydaşları ile ilişkileri ve proje görevleri ile efor tahminlerini ve sürelerini gözden geçirmek isteyebilir. Bu görüşmeler aynı zamanda bazı projelerin statüsü, ekip üyelerinin zamanlarını nasıl yönettikleri ve başka görevler için uygunluk durumlarını değerlendirmek için fırsat da oluşturabilir. Ekip bilincinin geliştirilmesi için ekip üyelerinin birlikte çalışabileceği fırsatlar yakalanmaya çalışılmalıdır.

İş Analizi Süreçlerinin Tanımlanması. Her organizasyonun iş analizi süreçleri o kurumun ihtiyaçları doğrultusunda özelleşmiştir. Proje ve hizmet verilen alan bazında kurum süreçlerinin özelleştirilmesi durumları da söz konusu olabilmektedir. Yöneticilerin önemli görevlerinden bir tanesi de uygulanacak süreçlerin, kullanılacak araç ve şablonların ekip üyeleri tarafından kullanılmasını sağlamaktadır.

Kaynak Ataması ve Planlaması. Ekip yöneticileri projelere gerekli yetkinliklere sahip kaynak atamaları gerçekleştirmek ve gelecek projeler için gerekli kaynak ihtiyaçlarını planlama görevlerini de yerine getirmektedir.

Kurumsal Hedeflerin Gözetilmesi. İş Analizi yöneticilerinin en önemli görevlerinden bir tanesi kurumsal hedeflere ulaşma konusunda yapabilecekleri katkıların farkında olmalarıdır. Bu farkındalığı ekipte oluşturmak ve ekibin kurumsal hedeflere ulaşma konusunda katkı oluşturmalarını sağlamak da gerekmektedir. Kurumsal hedefler veya öncelikleri zaman içerisinde değişebilmektedir. Bu değişimler konusunda ekip üyelerinin zamanında bilgilendirilmesi önemlidir.

Bazı organizasyonlarda veya projelerde yukarı da belirtmiş olduğumuz görevlere ek olarak iş analizi yöneticilerinin projelerde iş analizi süreçlerinin yerine getirilmesinde aktif olarak yer alması söz konusu olabilmektedir.

İş Analizi ekip yöneticilerinin görevleri yer aldıkları organizasyonun büyüklüğüne göre değişebilmektedir. Sizinle paylaşmış olduğumuz görevler daha çok orta veya büyük ölçekli organizasyonlar için geçerli olmakla birlikte, daha küçük organizasyonlarda bu görevlerin farklı roller tarafından üstlenilmesi söz konusu olabilmektedir.

 

Kaynak: theBASolutions

http://projeegitimmerkezi.com/bdetail-d-222-is-analizi-ekip-yonetimi-nasil-olmali

BABOK İş Analizi Süreçleri Bilgi Alanları

Uluslararası İş Analizi Enstitüsü (IIBA) tarafından yayınlanan ve sektör tarafından kabul edilmiş İş Analizi standartlarını içeren BABOK Guide V2 İş Analizi süreçlerinde 6 farklı bilgi alanına işaret etmektedir.

1. İş Analizi Planlama ve İzleme : Bu bilgi alanı bir Proje veya Programın İş Analiz süreçlerinin yerine getirilmesi için gereken görevlerin İş Analistleri tarafından nasıl belirleneceği ile ilgili görevleri ve teknikleri içermektedir. Bu bilgi alanındaki görevler Proje veya Programın İş Analizi süreçlerinin performansını yönetmektedir.

 

2. Gereksinim Toplama : İş Analistlerinin Paydaşların ihtiyaçlarını ve çekincelerini anlamak için ne tip çalışmalar gerçekleştireceğini, ve bulundukları çevre koşullarını nasıl değerlendireceklerini tanımlar. Gereksinim Toplama çalışmalarının temel amacı, Paydaşların ifade etmiş olduğu ihtiyaçların ardındaki gerçek nedenleri anlamaktır.

3. Gereksinim Yönetimi ve İletişimi : İş Analistlerinin çatışmaları, sorunları ve değişiklik taleplerini nasıl yöneteceğini tanımlar. Paydaşlar ve Proje Ekibinin çözüm mutabakatının nasıl sağlanacağını, Gereksinim İletişiminin Paydaşlar ile nasıl gerçekleştirileceğini ve kazanılan tecrübelerin ileri tarihli çalışmalarda nasıl kullanılmasının sağlanacağını içermektedir.

4. İşletme (Girişim) Analizi : İş Analistlerinin bir iş ihtiyacını nasıl tespit ettiğini ve tanımladığını, organizasyon tarafından kabul edilebilir bir çözümün nasıl belirlediğini tanımlar. Bilgi alanı problem tanımı ve analizini, iş vakası geliştirmeyi, fizibilite çalışmalarını ve çözüm kapsamı tanımlamayı içermektedir.

5. Gereksinim Analizi : İş Analistlerinin Sponsor konumundaki organizasyonun ve paydaşların ihtiyaçlarını karşılamak üzere Proje Ekibinin üreteceği çözüm için Paydaş ve Çözüm gereksinimlerini nasıl önceliklendirdiğini ve detaylandırdığını tanımlar. Paydaş ihtiyaçlarını karşılamak üzere bir çözüm tanımlamak amacıyla Paydaş ihtiyaçlarının analiz edilmesini, iş süreçlerinin mevcut durumunun analiz edilerek gelişim noktalarının belirlenmesini ve tespit edilen gereksinimlerin onaylanmasını ve gerçekleştirilmesini içermektedir.

6. Çözüm Değerlendirme ve Onay : İş analistlerinin iş ihtiyaçlarını karşılayabilecek çözümler arasından en iyi çözümü belirlemek için yapacağı değerlendirmeleri içermektedir. Bu amaçla olası çözümlerin nasıl değerlendirileceğini, çözümlerin ihtiyaçları karşılamadığı noktalarda iyileştirmelerin nasıl tespit edileceğini ve çözüm üzerinde yapılması gereken değişikliklerin nasıl tanımlanacağı ile ilgili görev ve tekniklerden oluşmaktadır. Bilgi alanı aynı zamanda uygulamaya alınmış bir çözümün Proje veya Program kapsamında belirlenmiş ihtiyaçları ne ölçüde karşıladığı ile ilgili değerlendirmenin İş Analistleri tarafından yapılacağını tanımlar.

Kaynak: http://www.thebasolutions.com/blog-babok-is-analizi-surecleri-bilgi-alanlari-73

TheBASolutions

İş 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

İş Analizi Nedir? İş Analisti Ne Yapar?

İş analizi (business analysis) kavramından bahsedildiğinde esas olarak insanların zihninde iki farklı konu canlanır.

1. Uzunca bir süredir var olan anlamıyla; bir firmada gerçekleştirilmek istenen bir proje veya çıkartılmak istenilen bir ürün ile ilgili piyasa araştırmalarının yapılması, ürün niteliklerinin belirlenmesi, fizibilite çalışmalarının yapılması gibi daha ziyade iş geliştirme tarafında hitap eden konular.

2. Yeni oluşturulan veya optimize edilmek istenilen bir sürecin oluşturulması, bu süreçlerin otomasyona geçirilmesi için ihtiyaç duyulan analizlerin yapılması.

İkinci konu daha ziyade bilgisayarların hayatımıza yoğun olarak girmesi ile birlikte ihtiyaç duyulan yazılımların, uygulamaların geliştirilmesi için yapılacak analizleri kapsar.

Birinci maddedeki sorumluluklar ise günümüz iş dünyasında ürün yöneticisi olarak ifade edilen rollere aktarılmıştır. Bu şekilde olmasını da doğal karşılamak gerekir. Zira konular birbirinden oldukça farklı ve farklı tecrübe ve birikimlere ihtiyaç duyar nitelikte karmaşıktır. Ancak her durumda birbirleri ile etkileşimi oldukça yoğundur.

Öncelikle bu hususlarda net olmak gerekir. İstihdam ettiğimiz iş analistlerimizden beklentimizi doğru olarak ifade edebiliyor olmalıyız. Danışmanlığını yaptığımız çeşitli firmalarda bu ayrımın net olmamasından kaynaklanan sorunlar yaşandığını çeşitli kereler gözlemlemişsizdir.

Meselenin bir diğer boyutu ise ikinci maddede ifade ettiğimiz iş analistinin uygulama geliştirme süreci içine ne kadar gireceği, sorumluluğunun teknik süreçlerin hangi aşamasına kadar işin içinde olacağı veya olması gerektiği yönünde sıkça yaşanılan tartışmalardır. Yazılım ekipleri sıkça iş analistinin rolünün ihtiyaç ve gereksinimlerin toplanması ve bunların yazılımcılara aktarılmasından ibaret olması gerektiğini söyler. Bu aşamadan sonra yapılması gereken yazılım analiz ve tasarım çalışmalarının “teknik” meseleler olduğu ve yazılım ekiplerinin işi olduğu yönünde kanaat belirtirler.

Bu tartışmalar aslında çok gerekli değildir. Zira yapılacak çalışmalar herşeyden önce projenin tüm aşamalarında birlikte yürütülmesi gereken çalışmalardır. Yazılım yaşam döngüsünde analiz ve tasarımın dört temel seviyesi vardır. İlk iki seviye kavramsal ve tanımlama seviyesidir, iş analizinin konusudur. Üç ve dördüncü aşamalar ise fiziksel ve uygulama seviyeleri olarak geçer ve teknik ekiplerin konusudur. Ancak her aşamada birlikte çalışılır. Sözkonusu olan bir yazılım üretmek olduğu için de yapılan tasarım buna uygun teknikler kullanılarak yapılırsa, her aşamada detay seviyesi biraz daha artırılarak sonuçta kaliteli bir yazılıma kavuşmak imkanı vardır.

Bunun için geliştirilen özel teknik ve yöntemlerin ve analiz methodolojilerinin eğitimlerinin tüm ekiplere aldırılması bu anlamda çok önemlidir. Zira ekiplerin birbirlerinin yaptığı işi tamamlayarak gitmeleri ve karşılıklı olarak birbirilerinin dilinden konuşmayı ve birbirlerini anlamayı kolaylaştırdığı gibi geri dönüp bakıldığında ciddi bir analiz ve tasarım envanterine de sahip olunur. Test senaryolarının çalışılması da bu anlamda çok rahat olacaktır.

 

Kaynak:http://www.fonksiyon-tr.com/blogpost-48/is-analizi-nedir-is-analisti-ne-yapar.html