Translate

Kasım Şen - (Mütehayyil)

25 Eylül 2013

Etkili Analistlerin Davranışları - 1


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

Etkili Analistlerin Davranışları - 1

Yazılım projelerinin belli başlı süreçlerinden birisi de gereksinimleri elde etmek ve bunları belli kategoriler ışığında organize edip tasarıma girdi olarak hazırlamaktır. İş geliştirme aşamasından ve proje planının  belli olmasından sonra yazılımın ve sistemin gereksinimleri ortaya çıkarılmaya başlanır. Bu görevde sorumluluk gereksinim analistlerine düşer. Böyle olunca da müşteri ortamında sürekli bulunup geri beslemeler yapan ve bu gereksinimleri organize eden analistlere ihtiyaç doğar. Yazılım yöneticileri zaman zaman, bu konuda hiç bir eğitim almamış ama  müşterilerle iyi ilişki kuran  bir programcının, müşteri gereksinimlerini belirleyip bunları yazabileceği kanısına kapılırlar. 

Proje yönetimi, ön kestirim   yapabilme gibi özel yetenek gerektiren işlemlerin nasıl kendine özgü eğitimleri ve yetenekleri olması gerekliyse, gereksinim belirleme işlemi de özel yeteneklere ihtiyaç duyar. Kendi kendine çalışarak veya iş tecrübesiyle gereksinim mühendisliği tek başına başarılamaz. Bir çok yazılım mühendisliği eğitimi veren bölümlerin vurgulamasına rağmen,  programcılık alanında yeterlilik, projelerin tüm aşamalarının üstesinden gelmeyi sağlamaz.  
 
Gereksinim analistlerinin projedeki rolü, proje yöneticileri veya uygulama geliştiriciler tarafından yerine getirilemeyecek kadar önemli ve can alıcı bir niteliğe sahiptir, sahip olmalıdır. Kullanıcı1ık geçmişi olan bir analist teknik konularda yetersiz kalabildiği gibi, programcılıktan analistliğe geçen bir kişi ise iş süreçleri konusunda yetersiz kalabilmektedir. İşte bu aşama her yazılım geliştirme organizasyonu, yazılım geliştirme süreçlerinin diğerlerinde tüm zamanını harcamayacak olsa bile, mutlaka konusunda bilgili gereksinim analistlerini, uygun formasyon ve eğitim ile yetiştirmek zorundadır. Başarılı bir analist olmak için gereken bazı önemli özellikler şu şekilde sıralanabilir.

 İletişim Köprüsü kurmak

Analistler, müşterinin belirsiz ve karmakarışık düşünce ve gereksinimleri ile geliştiricilerin istediği açık ve iyi tanımlanmış belirtimler arasında yer alan boşluğu ortadan kaldıran bir köprü görevini üstlenirler. Her iki tarafa eşit mesafede ama her iki tarafın isteklerini karşılayan bir orta-adam rolünü oynamalıdırlar. Bir analist önce kullanıcı ihtiyaçlarını belirleyip, bunlardan fonksiyonel gereksinimleri ve kalite hedeflerini tanımlamalıdır. Fonksiyonel yaklaşımlar da kalite için her zaman bir anahtardır.

İyi bir analist olmak için, okuma, yazma ve dinleme olmak üzere iletişimin tüm yöntemlerine hakim olmak gerekir. Örneğin pazarlama veya sunum yapan bir proje yetkilisi ile olan iletişim halinde olan bir analist, o kişilerin iş süreçlerine ve uygulamalarına odaklanabilmelidir.  Özellikle bir analistin, müşterinin işine özgü kelime ve terimlere hakim olması, gereksinimleri elde etmek amacıyla kurduğu iletişimdeki anlaşmazlıkları ve hataları ortadan kaldıracaktır. Hatta bunun yanı sıra  gereksinim dokümanına ek olarak bu terimleri içeren bir sözlük de eklenmelidir ve gereksinim dokümanları mümkün derece müşterinin kullandığı terimleri içermelidir. Analistin bu terimlere katacağı farklı anlamlar, müşterinin anlamayabileceği bir doküman üretilmesine yol açacaktır. Uç kullanıcılarla yapılan toplantılarda analist, kullanıcının sistem içindeki görev ve rollerine odaklanmalıdır. Görevleri hakkında kullanıcıdan örnekler istemeli ve anlaşılmayan tüm noktalarda soru sormaktan çekinmemelidir. Kullanıcılar karşılarında sistemi çok iyi bilen bir kişi olmasını beklememektedirler. Hatta bu iş konusunda fazla bilgisinin olmadığını açık biçimde söyleyebilmelidir. Belki böylece kullanıcılar da daha yardımsever davranabilirler. Sonuçta  analist kendini “doğru” soru sormak zorunluluğunda hissetmeden davranmalıdır.

Analistler, müşteri ile iletişimde kendi bilgi ve tecrübelerinin sınırlarından çıkarak müşterinin neler istediğini ve hangi noktalara önem verdiğini anlamaya çalışmalıdır. Kendi düşüncelerini empoze etmeye çalışmak veya kendince filtrelemeler yapmak, bazı önemli noktaların kaçırılmasına neden olabilir. Şunu unutmamak gerekir ki; müşteri her zaman haklı olmayabilir ama müşterinin belli başlı önem verdiği yerler ve noktalar vardır ve analist özellikle sistem içinde bu noktaları doğru adresleyebilmelidir. Müşterinin fonksiyonel ihtiyaçlarını elde etmek ürünün tam olarak gerçekleştirildiği anlamına gelmeyebilir. Analist, sistemin fonksiyonel olmayan, performans, kullanılabilirlik, verimlilik ve güvenilirlik gibi gereksinimlerini de elde etmeye çalışmalıdır.  Böylece ürün gerçek anlamda tamamlanmış sayılabilir. Fonksi-yonel olmayan gereksinimleri elde ederken subjektif  olmamalı, gereksinimlerin  ölçümlenebilir veya açıklıkla tanımlanabilir olmasına dikkat etmelidir. “Sistemin ekranları kullanıcı-dostu (user-friendly) olsun” şeklindeki bir gereksinim ortam, kişi ve koşullara göre değişebilen bir gereksinimdir. Analist bu tip gereksinimleri belli sınırlama ve sınıflamaya sokmak zorundadır.

Gereksinimleri elde ederken proje kapsamında birçok paydaşla, elde edilen müşteri ihtiyaçlarını paylaşmak gerekebilir. Analist, elde edilen tüm gereksinimleri iyi bir şekilde yazmalı, hazırlamalı ve organize etmelidir. Bunu yaparken müşteri temsilcisinin anlayabileceği açıklıkta, muğlak ifadeler bulundurmayan, fonksiyonel ve fonksiyonel olmayan gereksinimleri içeren bir doküman hazırlamaya çalışmalıdır. Hatta bu bazen bir doküman ile de sağlanamayabilir. Kullanıcı senaryoları tanımları, kullanıcının sisteme olan bakış açısını ve sistemden anladıklarını göstermesi sebebiyle kullanıcı ile analist arasında güzel bir iletişim ortamı sunar.  Fakat bu tanımlar, uygulama geliştiriciler için yüzeysel kalabilmektedir. Analistler kullanıcı senaryolarından, daha ayrıntıya girerek sistem gereksinim belirtimlerini içeren bir dokümanı hazırlayıp, uygulama geliştiricilere sunmalıdır.

Sonuçta analistler, uygulama geliştiriciler ve kullanıcılar olmak üzere her iki tarafa bakan, bunların arasında verimli bir iletişimi kuran kişilerdir. Bu sebepten dolayı analistlerin hazırladığı gereksinim dokümanının anlaşılırlığını anlamak için müşteri temsilcisi, uygulama geliştirici ve test sorumlularının bu dokümanı gözden geçirip onaylaması gerekir.

Devam edecek.

03 Eylül 2013

Gizli Denetim

Hayatımızın birçok noktasında olduğu üzere, projelerimizde de denetimler yapılır. "Denetleme", "Tetkik" ve "Teftiş" gibi farklı kelimelerle ifade edilse de temelinde yapılan işin doğruluğunu kontrol etmeye yönelik faaliyetlerdir. Kimisi proje ekibi içinden, kimisi proje ekibinden bağımsız kişiler tarafından ve kimisi de şirket dışından bağımsız denetçiler tarafından yapılabilir. Amaç aynı olsa da etkisi ve maliyeti hepsinin farklı ölçeklerdedir. Fakat, ortada yapılan bir iş olduğu sürece mutlaka farklı bir göz tarafından kontrol edilmesi zorunluluktur. Doğal bir ihtiyaçtır.

Bu amaçla, tüm kalite modellerinde işin sürece ve standartlara uygun yapıldığını kontrol edecek süreç adımları ve/veya yöntemleri belirtilmiştir. CMMI, PMBOK kitaplarında bununla ilgili ana başlıklar bulunur. Bu kalite denetimlerinde genellikle bir kontrol listesi üzerinden geçilerek eksiklikler tespit edilir ve düzeltilmesi için planlama yapılması istenilir.

Bu denetimlerde şunlar özellikle dikkate alınır:
  • Denetimlerde kişisel yetkinlikler veya hatalar yerine ürün ve sürece yönelik eksiklikler bulunmaya çalışılır. Uygunsuzluklar bir kişinin üstüne yıkılmaya çalışılmaz ve ekip olarak eksikliklerin giderilmesi beklenir.
  • Denetimlerde ne bazı şeyler gözardı edilmeye çalışılır ne de çok detayda inceleme yapılarak mutlaka bir uygunsuzluk bulunmaya çalışılır. Denetimin maksadı dışına çıkılmadan genel hatları ile süreç veya ürün sorgulanır.
CMMI süreçlerinde denetimlerin gizli yapılmasına yönelik bir yaklaşım bulunmaz. Zaten denetim gizli de yapılsa, haber verilerek de yapılsa eğer bir uygunsuzluk varsa tespit edilebilir. Uygunsuzlukları tespit etmek denetçinin yeteneğine kalmıştır. Haber verilerek yapılan denetimlerde de denetçi uygun sorular sorarak gizlenebilecek uygunsuzlukları ortaya çıkarabilir.

Gizli denetim şöyle düşünülebilir: Akşam ailece evinizde otururken baskın yapar gibi bir arkadaşınızın size misafirliğe gelmesi durumunu düşünelim. Belki evde bazı eşyalar dağınık olabilir, biraz ortalığı toparlamak gerekebilir. Fakat, aniden veya gizlice yapılan bu baskın ziyaret sonrası misafirliğe gelen arkadaşınızın sizin hakkınızda söyleyeceği şeyler ne kadar gerçekçidir? Her zaman ve her evde olabilecek bu dağınıklığı kusur olarak ele almak doğru değildir.

Aynı durum iş yeri veya proje denetimlerinde de ortaya çıkabilir. Hazırlıksız yapılan denetimlerde mutlaka uygunsuzlukla karşılaşılır.Ama haber verilse, belki daha hazırlıklı olarak denetim yapılarak daha anlamlı uygunsuzluklar belirlenebilir.

Özetle, haber vererek denetim yapmak medeni bir davranıştır. "Gammazlık", "muhbirlik", "ajanlık" ve tebdil-i kiyafet gibi yöntemlerin kullanım yeri ve amacı ancak güvenlik tehlikesi varsa geçerlidir.


04 Şubat 2013

"Hello World" Projesi

Bir firmanın süreçlerinin maliyeti ve verimliliği; sadece  "Hello World" programı yazılacak bir proje için harcanan / harcanması gerekecek iş gücünün maliyetidir.

Gerçekten de öyle değil midir? Proje başlatıldıktan sonra en azından şunları tamamlamak gerekir:
  • SOW (State of Work)
  • Başlangıç toplantısı (Kick-off Meeting)
  • Proje Planı
  • Gereksinim listesi
  • Tasarım dokümanı (platform, iş akışı vb içerecek)
  • Test senaryoları
  • Kurulum ve entegrasyon dokümanları
  • vs.
  • vs..
Belki de 1 saatte yazılacak bir program için bu kadar belge gerekecek...



06 Ocak 2013

Ekiplerde motivasyon-2

Ekip Motivasyonu

Motivasyon için terim karşılığı olarak Türk Dil Kurumu tarafından belirtildiği üzere "isteklendirme" ve "güdülendirme" kullanılabilir. Bir hedefe ulaşabilmek amacıyla hem bireysel hem de ekip halinde güdülenmek ve birbirini güdülemek gerekir. Aksi halde zincirde kopmalar olacaktır. Bireysel motivasyon ile ekip motivasyonu arasında güçlü bir bağ bulunduğu açıktır. Bu bağlantıyı 3 ana ilişki üzerinden göstermemiz doğru olacaktır:
  1. Bireysel motivasyon sağlanmadıkça ekip motivasyonunu sağlamak güçtür: Kendi kendini belli amaçlar için güdülememiş olan bireylerden oluşan ekiplerin bir hedefe güdülenmesi beklenemez. Mutsuz insanlardan oluşan bir ekipte motivasyon sağlamak güçtür.
  2. Ekip motivasyonu olmayan bir ortamda bireysel motivasyonlar ya düşer, ya da farklı amaca hizmet eder: Hedefe güdülenmemiş bir ekibin içindeki kısmen sağlanan bireysel motivasyonlar zaman içerisinde azalır. Bazen, ekip içindeki bireysel motivasyonların amacı farklılaşır. Ekibin başarıya hedeflenmesi beklenildiği halde bireysel motivasyonlar anlık gelir kazançlarına veya kariyer yükselmesine odaklanabilir. Bu durumda bireysel motivasyonun ekibe bir faydası olmayacaktır.
  3. Birbirini güdüleme yöntemi ile ekip motivasyonu sağlanabilir: Ekip içerisindeki herkesin aynı zamanda aynı seviyede motivasyona sahip olması çoğu zaman güçtür. Bazı ekip üyelerindeki yüksek motivasyon, diğer ekip üyelerine hem pozitif hem de negatif etki yapabilir. Pozitif etki yapması durumunda ekip üyeleri birbirlerini güdüleyerek ekip motivasyonunu belli bir seviyeye yükseltebilirler. Bu durum istenilen bir hedeftir. Kimi zaman da yüksek motivasyon sahibi ekip üyeleri, diğer ekip üyelerindeki motivasyon eksikliğini gerekçe göstererek o kişilerin ekip dışında kalmasını ve yola ancak yüksek motivasyona sahip kişiler ile devam edilmesini isteyebilirler. Bu durum bir ekibin küçülmesine ve dağılmasına neden olacaktır. Ekip liderinin pozitif sinerjiyi sağlaması gerekmektedir.

Ekip liderinin motivasyonu

Ekip liderinin, ekip motivasyonunu yüksek tutmak için bireylere özel yöntemleri uygulaması gerekir. Bu onun en önemli görevidir.  Burada öncelikle bireysel motivasyonu sağlamalıdır. Bireysel motivasyonun ekip hedefleriyle uyumlu olmasına özen gösterilmelidir. Ekibin ulaşması gereken bir hedefin kapsamı dışında sağlanacak bir motivasyonun ekibe faydası olmayacaktır. Ekip lideri, önce ekibinin hedeflerini ortaya koymalı ve sonra bu hedeflere göre ekip üyelerinin her birinin motivasyonu sağlamalıdır.

Ekip liderlerinin bazılarının hedef kartlarında "ekip motivasyonunu yüksek tutmak" şeklinde bir hedef görülebilmektedir. Kulağa hoş gelse de böyle bir hedef koymak tıpkı "yumurta mı tavuktan, tavuk mu yumurtadan" şeklinde ikilem oluşturur. Hedeflere ulaşmak için motivasyonu yükseltmek için bir hedef tanımlanmamalıdır. Böyle bir hedef zaten ölçülemeyeceği için hakkıyla da değerlendirilemez. Motivasyonun ölçülebilir değeri yoktur.

Ekip liderinin veya dar kapsamda proje yöneticisinin, ekibin motivasyonunu sağlamak için öncelikle hedeflere ve başarıya kendisinin inanması gerekir. Belki doğru bir benzetme olmayabilir ama "projesine inanmayan proje yöneticisinin projeyi yönetmesi, ateist birisinin cami imamlığı yapması" gibi bir şey olacaktır. Motivasyonun birinci gereği ekibin hedeflere olan inancını sağlayabilmektir.

Bireysel hedefleri dolaylı olarak da olsa sağlamayan ekip hedeflerine, ekip üyelerinin inanması oldukça zorlaşacaktır. Ekip üyelerinin bireysel fayda ve tatmin açısından mutlu edilmesi gerekir. Bu faydalar kimi zaman maddi ödüller olabilir, kimi zaman manevi olarak ödüllendirme olabilir. Bazen ilgili hedefe ulaşıldığı anda elde edilecek kazanç, kar payı veya sosyal statü olabilir. Bazen de geleceğe yönelik olarak kariyer yatırımı olabilir. Kimi zaman da cezadan kurtulma ve elindekileri koruma olabilir. Her ne olursa olsun, ekibin hedefleri de bireysel hedeflerle uyumlu olmalıdır ve desteklemelidir.

Yazımızın bundan sonraki bölümünde ekiplerde motivasyonu etkileyen faktörler ve ekip motivasyonunu sağlamaya yönelik yöntemlere yer verilecektir. Konunun geniş kapsamlı olması nedeniyle, bir kaç yazı dizisi içerisinde dağılım olabilecektir.