Translate

Kasım Şen - (Mütehayyil)

rol etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
rol etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

30 Mart 2024

EVCİLİK

 

EVCİLİK

Ünlü film yönetmeni Andrey Tarkovski bir sözünde şöyle der: "Bir ağacın üzerindeki bir böcek gibi, sanatçı da asalak gibi çocukluğundan beslenir. Sonra biriktirdiklerini harcar, yetişkin olur ve olgunluğu da son noktadır". Ben de yazılarımda çocukluğumun hazinelerinden beslenmeye devam ediyorum. Bu kimi zaman bir anı, kimi zaman ise bir film, bir oyun, bir trajik olay olabiliyor. Her çocuk gibi bizler de oyunlar oynardık. Körebe, birdirbir, uzuneşek, saklambaç vs bunlardan bazılarıydı.  Ama galiba en çok oynadığımız oyun ise evcilikti.

“Abdal düğünden, çocuk oyundan usanmaz!”

Özellikle mahallemizin çocukları ile bir araya gelince hemen bir oyun kurulurdu. O oyunlarda hiç sıkılmazdık, oynamaktan usanmazdık. Türlü senaryolar ve hikayeler oluşturulurdu. Bazen yaşanmış bir anı, bazen ise hayal ürünü kahramanlar yaratılırdı. İlerleyen yıllarda bu oyunların çok faydasını gördük. Şimdilerde sosyalleşme olarak adlandırılan kavramı bizler içeriğini bilmeden doyasıya yaşamıştık. Evcilik oyununda her defasında farklı roller oynuyorduk. Bazen evin babası, bazen evin hasta çocuğu, bazen doktor, bazen polis oluyorduk. Rolümüzün hakkını vermek için olabildiğince sahici oynamaya çalışıyorduk.

“Mahsusçuktan, hasta oluver!”

Evcilik oynarken bazıları kendine verilen rolü beğenmezlerdi. Hasta rolü verilen çocuk, “yaa ben doktor olucam, ben hasta olmak istemiyomm, doktor olmak istiyommm” diye mızmızlanırdı. Bu durumda oyundaki yaşça büyük olan ablalar veya abiler devreye girer ve “canım n’olcak sanki mahsusçuktan hasta olacaksın, sonraki oyunlarda da sen doktor olursun” diye ikna etmeye çalışırlardı. Hayatımızın birçok zamanında da birileri bize zaman zaman mahsusçuktan oynamamız gereken roller verdi. Şimdi o evcilik oyunlarını çok iyi anlıyorum.

“Bir projede, iki cambaz oynamaz!”

Benzer rol dağıtımı proje ekipleri oluşturulurken de gerçekleştirilir. Herkesin yetkinliklerine ve yeteneklerine göre rolleri belirlenir. Kimisi iyi polis olur, kimisi ise eli sopalı kötü polis oluverir. Bazılarımız bize düşen rolleri beğenmeyiz. “Ama ben proje yöneticisi olmak istiyorum yaa!” diye serzenişte bulunanlar olur. Ancak bilinmesi gerekir ki, bir ipte iki cambaz oynamaz. Birisinin ak dediğine, diğeri kara diyemez. Bunu yapmaya kalkarlarsa, ya ip kopar ya da cambazların ikisi de yere düşer..

Kimisi arkadaşına biçilen rolü kıskanır ve “Ama o kişi şu rolü almış, o zaman ben de şu rolde olmalıydım, benim neyim eksik!” diye şikayet eder. O sırada bir yönetici çıkar ve “aman canım mahsusçuktan o rolü üstleneceksin, bu projede böyle olsun, başka projede sana başka roller veririz” der. O kişi de ya ikna olur, ya da küskün bir şekilde işi yavaşlatır, aksatır.

“Eşeğe cilve yap demişler, çifte atmış!”

Kimisi ise rolünü fazla sahiplenir ve kraldan daha fazla kralcı oluverir. Kendisine verilen yetkinin dışına çıkıp, sorumluluğuna girmeyen işlere de burnunu sokmaya başlar. Mahsusçuktan oynadığı rolü, sahici bir şekilde yerine getirir. Faydasından çok zararı olur.  

Dolayısıyla hepimiz projelerde bir anlamda evcilik oynuyoruz. Her projede farklı roller üstleniyoruz. Rolümüzün gereği mahsusçuktan da olsa sert olabiliyoruz. Kimsenin bu rolleri fazla ciddiye almasına gerek yok. Bilinmesi gereken şey:

Dostun attığı taş, baş yarmaz..

 

 



29 Ocak 2023

ÜZÜMÜ YİYİP, BAĞCIYI DÖVMEK

 



ÜZÜMÜ YİYİP, BAĞCIYI DÖVMEK

Pek çoğumuz duymuştur: “Maksat üzüm yemek mi, bağcıyı dövmek mi?” diye bir atasözümüz vardır. Üzüm güzelse, gerekirse bağcıyı aşıp, korkutup ve hatta dövüp ulaşmak isteriz. Ancak atasözüne farklı bir açıdan yaklaşalım. Yenilebilecek üzümün olması için sadece bağcı mı gerekir?  Pek çok şey gereklidir. Öncelikle iyi bir toprak lazım. Üzüm öyle her toprakta yetişmez. Her toprağın kendine özgü tadı ve lezzeti olur. Güzel bir asma fidanı gereklidir. Her asma fidanından üzüm alınmaz. Yeterli su verilmelidir. Fazla su çürütür, az su kurutur. Toprağı besleyecek ilaçlar, vitaminler gerekir. Aksi halde böcek sarar, verim düşer. Gün ışığı olmazsa, olmazdır.

Neticede bağcı, iyi bir üzüm için gereklidir ama tek başına yeterli değildir. Maksat üzüm yemek ise, bağcıyı dövmeden önce üzümün kalitesini arttırmak için gerekenler sağlanmalıdır. Aksi halde, bağcıyı dövseniz bile kaliteli üzüm yiyemezsiniz, ancak koruk gibi ekşi bir şeyler yersiniz.

Proje yönetiminde de önemli şey “EKİP”.  Ekip, yani projede çalışan insanlar iyi ve ortam kaliteli olmadıkça proje yöneticisinin kim olduğu çok da etkili değildir. İyi bir proje için de pek çok şey gereklidir. Tıpkı üzüm gibi pek çok şeyi bir arada ister. Öncelikle iyi bir şirket ortamı (toprak)  gerekiyor. Her şirketten iyi projeler çıkmaz, üretilmez. Toksik bir şirket ortamında kimse çalışmak istemez. Şirket kültürüne göre ortaya çıkacak projeler de değişik seviyelerde olur. 

“Filden uçmasını bekleyemezsiniz!”

Projelerde çalışacak iyi personelleri istihdam etmek gerekir. İyi yetişmemiş, konusunun uzmanı olmayan kişilerden oluşan bir ekip baştan başarısız olacaktır. Torpille, adam kayırmayla, diplomasına bakmadan, sırf birilerinin tavsiyesi(!) ile alınan personellerin, projeye katkısı olmayacağı gibi zarar bile vereceklerdir. Projede her role ihtiyaç vardır. Herkes her işi yapabilir diye düşünmek hata olur. 

Proje ekibinin motivasyona ihtiyacı olur. Üzüme verilen su gibi, az motivasyon işten soğutur, işten ayrılmaya sebep olur. Fazla motivasyon ise şımarıklık yaratır, iş çıkmaz, eğlenceye varır işin sonu. Dolayısıyla motivasyon için gereken tüm argümanlar uygulanmalıdır. Bazen prim, bazen takdir, bazen ödül, bazen de terfi verilmelidir. Ancak aşırı motivasyon verilmesi durumunda, bu argümanların etkili olmayacağını, alışkanlık yaratacağını da bilmek gerekir.

Ekibin iyi işler çıkarması için gereken teknolojik altyapı ve araçların tedarik edilmesi de önemlidir. Bunlarda kesintiler yapmak, işlerin ağır aksak ilerlemesine neden olur. Bir süre sonra ekip işlerini yapamaz olur. Uygun araçların tedarik edilmesinde tasarruf yapılmaz. 

“İlk düğme yanlış iliklenmiş ise, gömlek sonuna kadar hatalı iliklenir”

Proje yöneticilerinin ellerinde sihirli değnek yoktur. İşler baştan yanlış yapılmış ise, sonradan düzeltmek zor ve maliyetli olur. Proje yöneticisini yücelten birlikte çalıştığı ekiptir. En iyi araçları alsanız da, en güzel binalarda çalışsanız da, en yüksek maaşları verseniz de her şey ekibinizin kabiliyetlerinde yatmaktadır. Liyakat sahibi olmayan kişileri ne yaparsanız yapın, size faydası olmayacaktır.

“Tekeden süt çıkarmaya çalışmayın”

Ekip iyi değilse, yapacağınız her şey boşuna olacaktır. Her rolün kendine özgü yetkinlikleri vardır. Duvar ustasını, elektrik tesisatçısı olarak çalıştırmaya çalışmayın, başaramazsınız. Ekibinizde herkesin sorumlulukları olmalıdır ve herkesten sadece uzmanlık alanıyla ilgili çalışmasını beklemelidir.

Projelerde tek amacınız üzüm yemek olsun. Proje yöneticisini dövmek olmasın. Güzel, tatlı ve lezzetli üzümleri yemek istiyorsanız önce gerekenleri sağlamalısınız. İyi bir ekip kurmalısınız. Her şeyi eksiksiz yaptığınıza inandığınız halde hala iş çıkmıyorsa, işte o zaman bağcıyı dövebilirsiniz. Proje yöneticileri böyle durumlara karşı alışık olmalıdır, dayanıklı olmalıdır. Ve son bir atasözü:

“Üzüm yiyen köpeği, pekmez s.çana kadar kovalarlar..”


29 Temmuz 2018

Size Baba Diyebilir Miyim?


SİZE BABA DİYEBİLİR MİYİM?

"Size baba diyebilir miyim" sözü eski Türk filmlerinde sıkça duyduğumuz klişe bir replikti. Filmin atmosferi içerisinde duygusal bir bağ oluşturur ve izleyiciyi hüzünlendirip, gözyaşlarıyla izlemesini sağlayabilmiştir. Temeli ise "baba" figürüne dayanmaktadır.

Toplumumuzda egemen olan ataerkil yapı gereği baba figürü tüm yapılara sirayet etmiştir. Gelenek, örf ve adetlerimizde, bu erkek egemen davranış şekli aileden başlayarak, ekiplere, topluluklara ve hatta devlete bile uyarlanmıştır. Siyasilerin çokça kullandığı "devlet baba" imgesinin temelinde de, bu geleneksel ataerkil yapı bulunmaktadır. Ailenin reisi olan baba, devlet seviyesinde ise tüm vatandaşlarının babası olarak görülür. Tıpkı her şey ailedeki babadan istenildiği gibi, devletten istenilmeli, baba olan devlet de bunu sağlamalıdır. Bu "baba" figürünün sağladığı yüceltme mekanizması, arka planda sorumluluklar da getirir. Baba, para kazanmalı, ailesini korumalı, ihtiyaçları gidermeli, toplumla iletişime geçmeli, gerekirse kavga etmeli, yedirmeli, içirmeli vs.. Bu sorumluluk listesi uzayıp gider.

Benzer ataerkil yapı, ülkemizdeki yönetim yapısına da yansımıştır. Baba rolünü, çoğu zaman patron veya organizasyonda üst düzeydeki CEO, genel müdür, başkan, lider, direktör gibi kişiler üstlenmektedir. Hatta birçok takım/ekip lideri de ekibin babası gibi davranabilmektedir. Organizasyonda baba rolünü üstlenenler, tıpkı ailedeki babalar gibi, çalışanlarına iş sağlamalıdır, amiyane tabirle ekmek vermelidir. Baba rolü gereği çalışanların tüm sorunları, onların sorunu olur ve çözmeleri beklenir. Ekip içi çatışmaları, tıpkı ailedeki babanın yaptığı gibi sona erdirmeli, gerekirse masaya yumruğunu vurup çatışmayı önlemelidir.

Baba olarak görülen yönetici, bir süre sonra ekibindekilere bağırabilme, kızabilme, kötü söz söyleyebilme hakkını da görmeye başlar. Öyle ya, evdeki baba da çocuklarına hem kızar hem de sever. "Baba yönetici", çalışanlarına kızma hakkını kendini görürken, aynı zamanda ekibine yönelik dışarıdan gelecek tepkiler karşısında da "koruyucu" rol üstlenir, üstlenmesi beklenir. Çalışan zaman içinde şöyle düşünür: Yöneticim bana kızar ama beni de başkalarına karşı savunur. Bu anlayışa sahip çalışanların çoğalması durumunda baba rolünü üstlenen yöneticinin kendinde "hak"?! olarak gördüğü davranış biçimleri de artar.

Bu tip yöneticiler, bir süre sonra çalışanların özel hayatına karışmaya başlar, kendi sorumluluğunda olmayan konularda kısıtlamalar/özgürlükler koymaya çalışırlar. Çalışanlar da bu durumdan bazen mutsuz bazen de mutlu olurlar. Ancak sırtını baba rolünü üstlenen yöneticiye dayayan çalışanlar, yöneticilerinden ayrıldıkları veya yöneticileri ayrıldığı zaman, tıpkı ailedeki baba ölünce ortada kalan çocuklar gibi savunmasız, iradesiz ve hatta sahipsiz kalırlar.

Profesyonel iş yaşamının gereklerine uygun olarak yapılanmayan şirketlerdeki organizasyon yapılarının kolayca ve hızlıca ürettiği "baba" yöneticiler, şirketlerin ileride çözmeleri gereken önemli sorunlardan birisi olmaktadır. Hem çalışanların kişisel gelişimi hem de yöneticilerin yetki ve sorumlulukları açısından "baba" figürünü üstlenen yöneticilerin öncelikle kendilerini değiştirmesi gereklidir. Yönetici ne çalışanlarının hem kızan hem seven babasıdır, ne de çalışanları, yöneticilerinin her şeyleri istedikleri/bekledikleri çocuklarıdır. Aralarında organik bir bağ bulunmadığı gibi varolan hiyerarşik bağ da ancak profesyonel iş hayatının gerektirdiği düzeyde olmalıdır.

Tıpkı eski Türk filmlerinde olduğu gibi, "size baba diyebilir miyim" diyen çalışanlara veya "seni oğlum gibi sevdim" diyen yöneticilere profesyonel iş yaşamında yer yoktur.


22 Ağustos 2015

CMMI Felsefesi





CMMI Felsefesi


Dünyadaki süreç iyileştirme modellerinden birisi de CMMI (Capability Maturity Model Integration). Burada CMMI tanımları, model yapısı ve süreç alanlarının detaylarına  girmeden doğrudan CMMI modelinin ortaya koyduğu ana felsefeyi ortaya koymaya çalışacağım. CMMI hakkında detaylı bilgiler CMMI resmi sitesi olan CMMI Institute  (www.cmmiinstitute.com) web sayfasından edinilebilir.

CMMI, belirtildiği üzere süreç iyileştirme için bir modeldir. Öncelikle, sürecin ne olduğunu açıklamaya çalışacağım. Süreç; işlerin veya görevlerin nasıl yapılacağını açıklayan yazılı veya yazılı olmayan (teknik veya teknik olmayan) YÖNTEMler ile bu işleri yapacak kişilerin yetkinliklerine, eğitim seviyelerine ve motivasyonlarına bağlı olarak işin gerektirdiği araçların kullanılmasının tanımlanmasıdır.

Bu uzun açıklamanın özetinde süreç; insan, yöntem ve araç ile ilişkili iş tanımlaması  bulunur. Bu temel açıklamadan sonra işin felsefik yönüne girmeye çalışacağım. CMMI bir model demiştik, dolayısıyla her modelde olduğu üzere CMMI, bir organizasyonun işlerini  nasıl yapmasını tanımlamaz, standartları ortaya koymaz ve hangi araçların kullanılması gerektiğini zorlamaz. Her model her organizasyona da uymayabilir. Mağazada  manken (model) üzerinde güzel görünen bir elbise (süreç tanımları) siz giydiğinizde uygun olmayabilir, dar (işinizi tanımlamayan süreçler) gelebilir, belli yerleri bol  gelebilir (işinizle ilgisi olmayan, fazladan yapılan süreç adımları).  

CMMI felsefesinde, tanımlanan süreç alanları (process area) özelindee anahtar hedeflere odaklanmıştır. Detaylarda verilen özel pratikler (specific practices) ise  modeli uygulayanlar için açıklama türünden ipuçları vermektedir. Süreç alanının ana hedeflerine ulaşıldığı sürece alt pratiklerin aynen uygulanması gibi bir zorunluluk  yoktur. Zaten CMMI modelinde, ana hedefin kurumun iş yapış şeklinin iyileştirilmesi olduğu belirtilmiştir. İş yapış şeklinin tamamen lağv edilerek yerine farklı  yöntemlerin sunulması söylenmez.

Peki, soru şu olabilir: Neden özellikle ülkemizde firmalar aynı model üzerinden aldıkları belgeleri, süreç alanlarını modelde olduğu gibi (as it is) tanımlayarak elde  etmeye çalışmaktadırlar? Aslında temelinde yanlış olan ve ülkemize gelen birçok denetçi tarafından zorunlu-öneri gibi sunulan bu yönteme göre kurumlar süreçlerini CMMI  model kitabında yazılan adımlara göre tanımlamaktadırlar. Yani, bir elbiseyi tüm firmalar giymeye çalışmaktadırlar. Belki bazılarına neredeyse tamamen uyabilir fakat  ortaya konulan bu yanlış zorlamalar birçok firmanın hem süreçlerini hatalı/eksik tanımlamasına neden oluyor hem de gereksiz maliyetlere yol açıyor.

CMMI süreç modelinin en önemli felsefesi, firmaların gereksiz görebileceği bazı rollerin aslında öne çıkarılması, farkındalık yaratılması gibi önemli yaklaşımları  içerir. Örneğin, konfigürasyon sorumlusu, kalite güvence sorumlusu, gereksinim analisti, ölçüm ve analiz sorumlusu gibi nispeten teknik olmayan ama destek anlamında  bir organizasyonda bulunması gereken rolleri ön plana çıkarır. CMMI bunu yaparken, asla modelde bu rolleri veya kişileri isim olarak zikretmez. Yani, modelde  "konfigürasyon yöneticisi şu şu işleri yapmalıdır" gibi ifade bulunmaz. Hatta modelde "proje yöneticisi" gibi bir ifade bile yer almaz. Sadece bazı yerlerde üst  yönetim (senior management) tanımı geçer.  

Bu yaklaşımın bir amacı vardır. CMMI felsefesinde, kurumda mutlaka bir konfigürasyon sorumlusu kişi olmak zorunda değildir, bu bir ROL'dür ve bu rolü herkes  üstlenebilir. Modelin gerektirdiği şekilde hedefe ulaştırabilecek herkes bu rollerin gereği işleri gerçekleştirebilir. Fakat, ne yazık ki, ülkemize gelen CMMI  denetçileri, sanki her rol için bir kişi gerekliymiş gibi kurumları zorlamaktadırlar. Ana felsefede böyle bir anlayış yokken bu zorlamalar nedeniyle denetimler  sırasında ilgili/ilgisiz herkes farklı rolleri üstlenebiliyor. Sonuçta denetimlerde amiyane tanımlama ile "doğan" görünümlü "şahin" gibi kişiler ortaya çıkıyor. Maksat  belge almak olunca da herkes kendi işinin dışındaki rollerin işleri yaptığını anlatmaya çalışıyor. Çok komik sahneler sergileniyor.

Özetle, CMMI felsefesinde yapılan işin dünyada kabul görmüş standartların seviyesine çıkarmak için gerekli olan iyileştirmeler bulunmaktadır. Süreç alanlarındaki özel pratiklerin adım adım yazılarak süreç tanımıymış gibi sunulması hem bir kolaycılık hem de ana felsefeyi bilmemektir.     

25 Eylül 2013

Etkili Analistlerin Davranışları -3

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

Etkili Analistlerin Davranışları -3

Başarılı bir analist olmak için gereken bazı önemli özellikleri sıralamaya devam ediyoruz.  

İşbirliği Ortamı Yaratma

Yazılım geliştirme sürecinde, kullanıcılar, geliştiriciler, pazarlamacılar ve yöneticiler arasında zoraki de olsa bazı ilişkilerin doğması sağlanır. Bütün bu gruplar birbirlerinin yaptığı işin değerini anlamayabilir veya işe verdikleri öneme,  kısıtlarına ve ihtiyaçlarına inanmayabilir. Gerçekte ise birçok ortak amaç ve zorluklara sahiptirler. Bütün bu gruplar aynı iş ortamında çalışmaları nedeniyle sistemin getirilerinden baştan sona ortak bir şekilde faydalanacaklardır. Ürünün başarısı için tüm bu grupların birbirlerini tetiklemesi gerekecektir. Herşeyin kazanmak-kazanmak  felsefesi için yapılması gerekir. Kazanmak-kazanmak başarımı için ise öncelikle dürüst olmak gerekecektir. Proje ekibindeki tüm grupların, yöneticiden geliştiriciye kadar herkesin bilgi paylaşımında bulunması gerekecektir. Böyle bir ideal ortamı sağlamak elbette zordur ama mantıksız kişileri bir araya getirmek, işbirliği ortamını baştan yok etmek demektir.

Öncelikle iş gereksinimlerini tanımlamak, müşteri ve geliştiriciler için beklenilen kazançların daha fazla açığa vurulmasını sağlayacaktır. Tüm katılımcılar da projenin maliyeti ve kısıtları hakkında dürüst olup, bilgi paylaşımına fazlaca katkıda bulunacaklardır. Analistler, müşterinin zaman planı ve maliyetlerini gerçekçi bulmaz ise bunun sebepleriyle birlikte açıklamasını yapması gerekecektir. Anlamsız maliyetlendirme ve zaman planı, tüm paydaşların teknoloji, zaman ve kaynak açısından alacağı tüm kararlarını etkileyecek ve beklentilerini değiştirecektir. Bu noktada analistin proje yönetimi ile iletişimli olarak geri beslemelerde bulunması gerekecektir.

Analistin müşteri ile konuşmak için zamanının olmaması veya neler istenildiğini biliyor zannetmesi düşünülecek şey değildir. Analist müşteri ortamındaki anahtar konumdaki tüm kişilerle uygun işbirliği ortamını hazırlamak zorundadır. Müşteri temsilcileri, kendilerinden tam olarak ne istendiği belirtilmedikçe, katılımcı olmak konusunda tereddütlü davranabilirler. Bu durumda müşteri temsilcilerine katılım konusunda bir yazı yazıp, her seviyedeki işbirlikçilerle görüşmek ve onları ortamın içine çekmek istenmelidir. Vizyon dokümanı, doğru kişilerle konuşmayı seçmeyi sağlar ayrıca müşteriye ürün daha anlaşılır kılar.Yetersiz kullanıcı katılımı projeyi başarısızlığa götüren temel nedenlerden biridir. Bu noktada gereksinim görüşmeleri için zaman harcamak istemeyen dik kafalı kullanıcı ve yöneticilere dikkat etmek gerekir. Yetersiz kullanıcı katılımı nedeniyle problemler yaşanılan önceki projeleri hatırlamak ve müşterilere örnekler sunmak çözüm açısından yardımcı olacaktır. Hemen hemen her organizasyonda yeni sistemin istenilenleri karşılamayacağı, kullanılabilirliğinde sorunlar yaşanacağı, performans sorunları oluşacağı şeklinde kötümser hikayeler yaratılır. Kullanıcı ihtiyaçlarının yeterince anlaşılması ve paylaşılması, projenin başarımını da etkileyecektir.

Becerileri Yenileme ve Etkinleştirme

Gereksinim analistinin temel fonksiyonu, geliştirici ile müşteri arasıdaki projeye olan bakış açılarından kaynaklanan boşlukta bir köprü görevi görmektir. Yetenekli bir analist, iletişim kurabilme, basitleştirebilme, kişiler arası becerilere sahiplik ve teknik açıdan işin etki alanına hakim olabilme yeteneklerini kendisinde toplamalıdır. Çok iyi bir programcı ile sisteme hakim bir kullanıcının bir analist olabilmesi için uygun hazırlıktan geçmesi gerekir. Bütün bu üstün özellikler analist olmak açısından yeterli olamamaktadır. Kazanılması gereken bazı önemli yetenekler şunlardır:
•    Kolaylaştırıp, basitleştirebilme
•    Görüşme Teknikleri
•    Dinleme yeteneği
•    Yazma yeteneği
•    Organizasyonel yetenekler
•    Kişiler arası beceriler
•    Modelleme yeteneği

Etkili bir analist, elindeki araçların hangisini nerede kullanıp kullanmayacağını iyi bilir.  Bu araçlar çok geniş bir yelpazeye dağılmıştır. Örneğin, içerik diyagramı, veri-akış diyagramı, UML gösterimleri bu araçlardandır ve bir analistin koleksiyonunda gerektiğinde kullanılmak üzere beklemelidirler. Etkili bir analist yolu üzerindeki engelleri tespit edip, uygun araçları seçerek bu engelleri ortadan kaldırmaya çalışır. Bunlara rağmen tecrübenin yerini hiçbir şey  tutamaz. Tecrübeli bir analist tarafından yazılacak bir gereksinim dokümanı, acemi biri tarafından yazılacaktan iki kat daha hızlı ve daha az hata içerecek şekilde yazılır. Geliştiricilerinin gereksinimleri yazabileceğini isteyen bir organizasyon ise, kalite ve organizasyon yapısından gitgide uzaklaşır.
Yazılım ürünleri için gereksinimler, analist şapkası giymiş birinin toplaması için ortada yayılmış durumda beklememektedir. En azından gereksinimler kullanıcıların, geliştiricilerin kafalarında çekip çıkarılmak ve uygun formlara dönüştürülmek için beklemektedirler. Gereksinimler, kullanıcıların ihtiyaçlarını belirlemek konusunda yardımcı olan, kullanıcıların ne istediklerini ortaya çıkarıp, geliştiricilerin de ihtiyaçlarına göre bunları düzenleyen bir analist tarafından keşfedilmeye ihtiyaç duyarlar. Gereksinim analistlerinin projede az ama önemli bir rolü vardır.



Kaynaklar: 
 Habits of Effective Analysts /Karl E. Wiegers - Process Impact www.processimpact.com 
To Be Reqirements Analyst /Karl E. Wiegers -Process Impact www.processimpact.com

Etkili Analistlerin Davranışları -2



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

Etkili Analistlerin Davranışları -2

Başarılı bir analist olmak için gereken bazı önemli özellikleri sıralamaya devam ediyoruz.

Çizgileri Belirlemek

Birçok projenin sınırları yazılı olarak belirlenmediği için neyin kapsam içinde, neyin dışında olduğu bilinemez ve bunun sıkıntıları zamanla ortaya çıkar. Yeni sistemin gereksinimlerini tanımlamaya öncelikle sistemin veya ürünün vizyonunu ve ne olup neler yapması gerektiğini ortaya koymakla başlanmalıdır. Sistemin iş gereksinimlerini tanımlamak ve vizyonu ortaya çıkarmak  için projenin pazarlama sorumlusu ve/veya finansal destekçisiyle iletişim içinde olmak, gerekirse hazırlanmış uygun bir doküman sunmak gereklidir. Son ürünün vizyonu tanımlamak zor olduğundan başlangıçtan son ürüne kadar her bir sürüm ve aşamanın vizyonlarını tanımlamak gerekecektir.

Gereksinimleri ortaya çıkarma görüşmelerinde önemli olan kullanıcıların sistemle neleri başarmak istedikleridir. Görüşmeler daha çok fonksiyonellik, kalite kriterleri ve çözüm önerileri odağında geçer. Bu kriterlerdeki ufacık bir bilgi bile kullanıcıların kafasından geçenleri anlamak için gerekli ve önemlidir. Bununla birlikte kullanıcıların bu sistemi kullanma hedefleri, bu sürecin verimli olmasında ve fonksiyonel gereksinimlerden tasarım arayüzlerinin çıkarılmasında oldukça etkilidir.

Açığa Çıkaran Sorular Sormak

Analist olarak çalışırken, kullanıcılarla yapılan oturumları kolaylaştırmak ve basitleştirmek gerekir. Müşteri temsilcisinin  daha önce hiç bahsetmediği bir görev hakkında alternatif yolları deneyerek kullanıcılara sorular sormak ve diğer görevlerle olan ilişkileri ortaya çıkarmak gerekir. Kullanıcının sorulara verdiği cevaplar o senaryo için olmazsa olmaz ve yapılsa iyi olur gibi ifadeler içerir. Böylece kullanıcı senaryolarının da iş akışı ortaya konulmuş olur. Kullanıcılar, sistemin doğru ve beklenildiği gibi çalışmasına odaklanırlar. Analist bunun yanı sıra beklenilmeyen durumlar için de uygun senaryoları hazırlamalıdır.  Hata durumlarında uygulama geliştiricinin ele alması gereken kontrolleri, zaman zaman kullanıcılardan da yardım alarak tanımlamalı ve hata durumlarını yönetmelidir. Bu öncelikle sistemin güvenilirliği ve tutarlılığı açısından önemlidir.

Yaratıcı ve bilgili bir analist, kullanıcıların söylediklerini birebir kaydetmek yerine alternatif bakış açıları ve öneriler sunar. Kullanıcılar bazen uygulama geliştiricilerin yeteneklerinin farkında olmayabilirler. Önerilecek fikirler ile sistemin daha kullanışlı olması sağlanabilir. Zaman zaman da kullanıcıların iş yapışını izleyerek, otomatikleştirilebilecek olan süreçler hakkında bilgiler verilerek, kullanıcıların sistemin kullanılabilirliğine olan bakışı arttırılabilir. Önceki sistemlerde kullanılmış bir fonksiyonel yapının tekrar kullanımının sağlanması, kullanıcıların gereksinimlerini yeniden gözden geçirmesini ve düzenlemesini sağlayacak ve yeni yapılar üzerinden yeni gereksinimleri düşünecektir.

Etkili bir analist birçok düzeyde soyutlama yapabilmelidir. Kullanıcının bildirdiği belirgin özellikteki gereksinimlerin, diğer kullanıcıların gereksinimleri ile ilgili olup olmadığını ve aralarındaki ilişkileri sağlamalıdır.  Bir konudaki önemli noktaları ortaya çıkarmak, belirsizlikleri yok etmek, anlaşmazlıkları ortadan kaldırmak, öngörü ve varsayımları belirlemek, beklentileri karşılamak için soru sorma sanatına hakim ve yetenekli olmak gerekir ve bu da çoğunlukla tecrübeye dayanır.

Önceliklendirme

Gereksinim geliştirme süreci, bulanık, her bir aşama için belirsiz tanımlardan detaylı belirtimlere giden döngüsel-artımlı bir süreçtir. Her aşamada doğru soyutlama düzeyine odaklanmak gerekir. Birden tasarıma dalmak veya detaylara girmek, sistemin ve sürecin hataya düşmesine neden olabilecektir. Kullanıcı arayüz ekranlarından veya prototiplerden gereksinimleri ortaya çıkarmak ve her aşamada gerektiği kadar detaya girmek sistemi doğru anlamak açısından önemlidir. Temel yapılması gereken şeylerin yapılmamış ve daha az önemi olan özelliklerin yapılmış olması, yazılım takımının cesareti kırıp, müşteriye ümitsizliğe yöneltir. Bu sebepten analist elde ettiği gereksinimleri önceliklendirmelidir. Herkes kendi işini çok önemli ve öncelikli görür. Analist bu noktada tüm kullanıcı sınıfları ve geliştiriciler arasında gerekli iletişim ve işbirliğini sağlayarak hassas öncelikli kararları almalıdır.

Gereksinim geliştirmede öncelikle katkıda bulunabilecek kullanıcı sınıfları oluşturulmalıdır. Bunu yaparken beğenilen, gözde ve beğenilmeyen gruplarla gereksinim geliştirmeye katkıda bulunmayacak grupları ayırt etmek gerekecektir. Tabii olarak beğenilen ve gözde sınıfın gereksinimleri de varolan çatışmalardan arındırıldıktan sonra öncelikli olacaktır.

Devam edecek.

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.