İNSAN YÖNETİMİ

Yazılım kurumunda çalışan insanlar onun en büyük servetidir. Onlar, yazılım yöneticilerine, kurum için, olabilecek en iyi getiriyi sağlayan yatırımın insan olduğunun ispat edecek bir akıl olgusunu temsil ederler. Başarılı firma ve ekonomilerde bu, kurumun insanlara saygı göstermesiyle başarılır. Onların görevleriyle orantılı bir seviyede sorumluluk ve ödüllendirilmeleri gerekir.
Sonuç olarak bir kurumda etkin yönetim insan yönetimidir. Proje yöneticileri kendi takımındaki insanları mümkün olan en etkin biçimde kullanarak teknik veya teknik olmayan problemleri çözmek zorundadır. Proje yöneticileri insanları özendirmek, işlerini düzenlemek ve işlerin düzgün bir şekilde işlemesini sağlamak zorundadır. İnsanların kısır yönetilmesi projelerin çökmesine en büyük katkıyı sağlar.
Tartışmamı son zamanlarda moda olan yönetim teorisinden çok kavrayış ve sosyal etmenlere dayandırıyorum. Yazılım mühendisliği kavramsal ve sosyal bir etkinlik olduğundan, insanların nasıl yazılım oluşturduklarına ilişkin etmenler önemlidir. Eğer yöneticiler bu esaslardan bir şeyler anlarlar ise onlar için çalışan insanlardan en iyisini alma işini daha iyi yaparlar.

DÜŞÜNCE SINIRLARI

Zeka, eğitim ve deneyimi yansıtan bireysel yetenekler arasında büyük farklılıklar vardır. Fakat öyle görünüyor ki bir çoğumuz düşüncelerimizde bazı temel sınırlamaların etkisinde kalıyoruz. Bunlar, bilginin beynimizde modellenme ve depolanma şeklinin sonucudur. Düşünce sınırlama bilincinin önemli olmasına rağmen, bilgi kavrama sürecinin ayrıntılarını bilmeye ihtiyacınız yoktur. Bu neden bazı yazılım mühendisliği tekniklerinin etkin olduğunu açıklamaya yardım eder ve size bir yazılım geliştirme takımındaki insanların aralarındaki etkileşim kavramını gösterir.

Bellek Düzeneği

Yazılım sistemleri soyut varlıklardır ve mühendisler geliştirme süreci boyunca özelliklerini hatırlamak zorundadırlar. Örnek olarak, programcılar kaynak kod listesi ile programın dinamik davranışı arasındaki ilişkiyi bilmek ve anlamak zorundadırlar. Onlar bu depolanmış bilgiyi ileriki program geliştirmelerinde kullanırlar.
İnsan belleği oluşumu üç ayrı, fakat birbirine bağlı, saha ile birlikte sıradüzeni bir yapı şeklinde gözükür.




1. Sınırlı kapasite, hızlı erişim, kısa ömürlü bellek : Duyulardan gelen veriler ilk olarak burası tarafından alınır ve işlenir. Bu bellek bilgisayarlardaki kayıtçı(register)’lar ile karşılaştırılabilir, bu kısım bilgi depolama değil, işleme için kullanılır.
2. Daha geniş kapasite, çalışan bellek alanı : Bu bellek alanı, kısa ömürlü belleğinkine oranla, daha uzun erişim zamanına sahiptir. Bilgi işleme için kullanılır ancak bilgiyi kısa ömürlü bellekten daha fazla zaman tutar. Uzun zaman bilgi tutmak için kullanılmaz. Bilgisayar ile örneklendiğinde, hesap zamanı boyunca bilginin tutulduğu rastgele erişimli bellek (RAM)gibidir.
3. Uzun Süreli Bellek : Büyük kapasiteli, diğer kısımlara oranla yavaş erişimli ve güvensiz geri besleme özelliğine sahiptir(İnsanlar bazı şeyleri unuturlar). Uzun süreli bellek bilginin kalıcı depolanması için kullanılır. Eğer örneklemeye devam edersek, uzun süreli bellek bilgisayardaki disk belleği gibidir.

Okunan belgelerden ve insan konuşmalarından elde edilen problem bilgileri kısa süreli belleğin girdileridir. Bu bilgiler ile uzun süreli bellekteki bilgiler çalışan bellekte bütünleştirilir. Bütünleşmenin sonucu, problem çözümünün temelini oluşturur. Bu çözümler daha sonraki problem çözümlerinde kullanılmak üzere uzun süreli bellekte saklanır. Tabii ki elde edilen çözümler yanlış olabilir. Daha çok bilgi elde edildikçe uzun süreli belleğin yenilenmesi gerekmektedir. Yenilenme sonrasında yanlış olan çözümler tamamıyla atılmayarak ayrı bir yapıda tutulur. Bunu hatalarımızdan öğrenerek biliyoruz.
Kısa süreli belleğin kısıtlı boyutu bizim kavrama sürecimizi kısıtlar. Klasik bir deneyim olarak Miller(1957) kısa süreli belleğin yedi parça bilgi saklayabildiğini bulmuştur. Bir parça bilgi sabit bir büyüklük olmamakla beraber birbiriyle ilgili bir bilgi çokluğunu göstermektedir. Bu bir telefon numarası, nesne amacı veya cadde ismi olabilir. Miller bilgilerin büyük parçalar (chunks) olarak birlikte tutulduğu kümelenme(chunking) sürecini de açıklamıştır.
Eğer bir problem kısa süreli belleğin taşıyabileceğinden daha fazla bilgi içeriyorsa, bilgilerin girdi süresi boyunca bilgi işleme ve bilgi aktarım işlemlerinin de yapılması gereklidir. Bu bilgi kayıplarına yol açabilir. Bilgi işleme sürecinin bilgi girdisiyle aynı zamanda olamayacağından dolayı hatalar meydana gelecektir.
Shneiderman(1980) bilgi kümeleme(chunking) işleminin programları anlamada kullanıldığını önermiştir. Program okuyucuları program bilgisini içsel anlamsal yapıların içine yapılandırılan büyük bilgi parçaları halinde ayırırlar. Eğer bir deyiş büyük mantıksal bir bilgi parçasını temsil etmiyorsa, programlar tek tek deyiş bazında anlaşılmaz. Aşağıdaki programı anlamaya çalışan biri tarafından olası kümelenmiş basit bir sıralama programını göstermektedir.


Programı temsil eden iç anlamsal yapı oluşturulduktan sonra uzun süreli belleğe aktarılır. Eğer bilgi düzenli olarak kullanılıyorsa genelde unutulmaz. Fazla zorluk olmadan bu bilgiden farklı sistemler de üretilebilir. Bu yüzden, alt seviye ayrıntıları değil de üst seviye soyutlamaları öğrenmiş gözükürüz.
Yazılım geliştirme sürecinde kazanılan ve uzun süreli bellekte depolanan bilgi iki sınıfa ayrılır:
1. Mantıksal Bilgi : Atama deyişi işlemi süreci, nesne sınıfının gösterim kavramı, arama tekniği işlemleri ve kurum yapılandırılması kavramları gibi bilgilerdir. Bu bilgi öğrenme ve deneyim sonucunda elde edilir ve bağımsız bir tanımlama olarak saklanır.
2. Sözdizimsel Bilgi : Bu UML’de nasıl nesne tanımlaması yapılacağı, bir programlama dilinde hangi standart fonksiyonlara ulaşılabileceği, bir atama işleminin ‘=’ veya ‘:=’ işareti ile yapılması vb.. ayrıntılı bilgi temsilidir. Bu bilgi işlenmemiş formda saklandığı gözükür.
Bilgi oluşumu Shneiderman’ın kullanıcı ara yüz tasarımı ile ilgili kitabından alınan şekil



Bu şekil, anlam ve iş bilgisinin düzenli ve yapısal olduğunu önermektedir. Değişik bilgi parçacıkları arasındaki ilişkiler kurulmuştur. Bunun aksine, sözdizimsel bilgi rastgele ve düzenlenmemiştir. Bu yüzden bu tip bilgi kullanılırken yanlış yapmak ve unutmak daha kolaydır.

Anlamsal bilgi, deneyim ve aktif öğrenimle kazanılır. Yeni anlamsal bilgi bilinçli bir şekilde varolan anlamsal yapı ile birleşir. Sözdizimsel bilgi ise ezberleme ile kazanılır. Yeni sözdizimsel bilgi varolan bilgi ile hemen birleşmez fakat karışabilir. Bu bilgi kendisinden daha geniş anlamsal bilgiden daha kolay unutulabilir.
Sözdizimsel ve anlamsal bilginin biçimleri deneyimli programcıların yeni bir programlama dilini nasıl anladıklarının açıklanmasına yardım eder. Onlar atama, döngü ve koşul deyişlerini anlamakta zorluk çekmemelerine rağmen programlama dili komutları, kendine benzer diğer bir dilin komutları ile, karışma eğilimi gösterirler. Bu yüzden Java öğrenen bir Ada programcısı atama operatörü olarak “=” yerine “: =” yazabilir.
Kavram gelişimini anlamak belleğe anlamsal bilgi olarak depolanır. Anlamsal bilgi soyut bir kavramsal formda depolandığı gözükür. Kavram ayrıntıları değişik somut gösterimler şeklinde tekrar türetilebilir.
Örnek olarak sıralı ikilik düzende herhangi bir sayının arandığı sayı arama algoritmasını ele alalım. Bu, sıranın orta noktasını bulup sıralama ilişkisi bilgisini kullanarak anahtar sayının alt veya üst yarıda olup olmadığının bulunmasını içerir. Bu algoritmayı anlayan bir programcı Java, Ada veya diğer bir programlama dilinde ki uygulamasını üretebilir.
Bu model program öğrenmek isteyen birçok insan için program öğrenmenin belli bir zaman aralığındaki zorlukları atlattıktan sonra tüm programların bir arada öğrenilebildiğini açıklar. Programlama becerisi anlamsal kavramlar ile, anlamasal ile sözdizimsel kavramların farklarını anlamayı gerektirir. Öğretmenler çoğu zaman öğrencilerin problemlerini anlamakta güçlük çekerler. Onlar geliştirilmiş anlamsal bilgiyi başarılı bir şekilde anlamışlardır ve sadece sözdizimsel bilgiyi anlamak zorundadırlar. Bu yüzdendir ki acemi programcılara anlamsal kavramları açıklamakta zorlanırlar.

Problem Çözümü

Bir program tasarlamak ve yazmak problem çözme sürecidir. Bir yazılım sistemi geliştirmek için problemi anlamalı, çözüm yolları üzerinde çalışmalı ve bunları programa aktarmalısınız. İlk adım problemin kısa süreli bellekten çalışan belleğe geçişini kapsar. Burada uzun süreli bellekteki varolan bilgilerle bütünleşir ve genel bir çözüm için analiz edilir. Sonuç olarak genel çözüm çalışan bir programa aktarılır



Problem çözümü genellikle görev ve bilgisayar kavramlarının birleşimini gerektirir. Çözümü bütçe içinde tamamlamak gibi kurumsal etmenler önemlidir. Bu yüzden bir kullanıcı görev kavramında, bir yazılımcı bilgisayar kavramlarında ve bir yönetici de kurum etmenlerinde uzman olabilirler. Yazılım mühendisliği sürecinde tüm bu uzmanlıklar bir arada kullanılmalıdır.
Çözümün geliştirilmesi(program), problemin iç anlamsal modelinin oluşturulması ile buna karşılık gelen çözüm modelidir. Bu model oluşturulduğunda herhangi bir sözdizimsel gösterimle gösterilebilir. Bu yüzden program tasarım süreci aşağıdaki kendinden türetilen adımları kapsar:
1. Yeni bir bilgi oluşturmak için bilgisayar bilgisi ile görev bilgisini birleştirip problemi anla. Curtis(1988), Uygulama deneyiminin bu adımda önemli olduğunu önermektedir.
2. Çözümün anlamsal bir modelini oluştur ve doyurucu bir sonuç elde edinceye kadar problemlere karşı sına.
3. Modeli herhangi bir programlama diline veya tasarım gösterimine aktar.

Uzun zamanlı projelerde karar vermek zorunda olan yöneticiler programlama dil becerileri yerine problemin genel çözüm yeteneğini ve alan uzmanlıklarını göz önüne alırlar. Bir kere problem anlaşıldığında deneyimli programcılar her programlama dilinde aynı zorluğu yaşarlar. Dil becerisi gereklidir ve geliştirmesi zaman alır(özellikle C++ gibi karışık diller)fakat benim kişisel düşüncem özel olarak bir programlama dilini öğrenmek problem çözme becerilerini geliştirmekten daha kolaydır.
Eğer programlama dili programcının anladığı en düşük seviye anlamsal yapılar ile eşleşen yapıları içeriyorsa, anlamsal modelden programa aktarım daha çok hata kontrolsüz olarak görünür. Bunlar kişiden kişiye değişmesine rağmen genellikle atama, döngü, koşul deyişleri, bilgi gizleme, nesneler, kalıtım gibi kavramlarla uyuşmaktadır. Programlama diliyle bu kavramlar arasındaki daha yakın uyuşma daha kolay program yazmayı sağlar.
Fonksiyonel ve nesneye dayalı kavramlar birbirine karıştırılmadığı sürece, alt seviye anlamsal kavramların dil deyişleri ile doğrudan kodlanabilmesinden dolayı üst seviye dillerde (java) yazılan programlar makine dilinde yazılanlardan daha az hataya sahip olmalıdır. Eğer bir şirket analiz için tek bir metot kullanıp nesneye dayalı tasarım ve programlama süreci kullanıyorsa bunlar problem olabilir.
Model aynı zamanda yapısal programlamanın neden program kontrolünün sağlanması için en iyi yöntem olduğunu da açıklar. Yapısal programlama döngü ve koşul deyişleri gibi anlamsal kavramlar üzerine oturtulmuştur. Programcının kısa süreli belleği aşırı yüklenmez aksi tekdirde hata yapmaya başlar. Yukarıdan aşağıya doğru okunabildiği için yapısal programların anlaşılması daha kolaydır. Bilgi parçalarının (chunks) oluşturulmasında değinilen soyutlamalar programın diğer kısımlarına bakmadan sırayla yapılabilir. Kısa süreli bellek kodun tek bir kısmına ayrılabilir. O kısımla karışan, programın diğer bölümleriyle ilgili çalışan bellekteki, bilgilerin tekrar çağırılmak zorunluluğu ortadan kalkar.

Özendirme

Proje yöneticilerinin rollerinden bir tanesi de onlar için çalışan insanları özendirmektir. Maslow(1954) şekildeki gibi insanların seviyelendirilmiş gereksinimlerinin karşılanması ile özendirilebileceğini önermektedir.



Bu sıra düzeninin alt seviyeleri yemek, uyku, bulunulan ortamdaki güvenlik gibi ana gereksinimleri temsil etmektedir. Sosyal gereksinimler sosyal gruplaşmanın bir parçası olma isteği ihtiyacıdır. Övülme ihtiyacı diğer insanlar tarafından kabul görme, öz gerçekleme ihtiyacı ise kişisel gelişme ile ilgilidir. İnsan öncelikleri doymak gibi alt seviye gereksinimlerden daha soyut olan üst seviye gereksinimlere doğrudur.
Yazılım geliştirme kurumlarında çalışan insanlar genellikle aç veya susamış değillerdir ve çevreleri tarafından fiziksel olarak tehdit edilmezler. Bu yüzden sosyal, övülme ve öz gerçekleme gereksinimlerinin sağlanması bir yönetici açısından daha önemli hale gelir :
1. Sosyal gereksinimleri karşılamak insanların iş arkadaşlarıyla görüşmelerini sağlamak için ortam sağlamak anlamına gelmektedir. Kabaca, elektronik posta gibi iletişim yollarının kullanımının kolay hale getirilmesi oldukça önemlidir.
2. Övülme/saygı ihtiyacını karşılamak için, insanlara kurum tarafından değer verildiğini göstermelisiniz. Başarıların genel olarak tanınması bunu açıkça yapmak için basit bir yoldur. İnsanlar işlerine yansıttıkları deneyim ve yetenekleri doğrultusunda kazandıklarını bilmelidirler.
3. Son olarak öz gerçekleme ihtiyacının karşılanması için, insanlara kendi işleri için sorumluluk verin, onlara çözümü gayret isteyen (imkansız olmayan) işler verin ve yeteneklerini geliştirmeleri için çalışma ortamları sağlayın.
Bass ve Dunteman (1963)’ın Özendirme ile ilgili bir çalışmasında uzmanlıkları üç sınıfa ayılmışlardır:
1. Görev-yönlendirmeli, yaptıkları işlerle özendirilenler. Yazılım mühendisliğinde teknikerler yazılım gelişiminin akıl meydan okumaları ile özendirilirler.
2. Öz-yönlendirmeli başlıca kişisel başarı ve tanınma ile özenenler. Onlar yazılım geliştirme ile kişisel amaçlarına ulaşmak amacıyla ilgilenirler.
3. İletişim-yönlendirmeli, çalışma arkadaşların varlık ve yaptıklarıyla özenenler. Yazılım geliştirme kullanıcı-merkezli oldukça, yazılım mühendisliği iletişim-yönlendirmeli kişilikleri daha çok içermeye başlamıştır.

İletişim-yönlendirmeli insanlar, öz ve görev-yönlendirmeli insanlar yalnız çalışmayı seçerken, bir grubun parçası olarak çalışmayı seçerler. Kadınlar erkeklerden daha çok iletişim-yönlendirmeli gözükmektedir. Onlar genellikle daha aktif iletişimcilerdir.
Karakterler ve kişilikler değişken olduğu halde bütün kişisel özendirmeler yukarıdaki her sınıfın elemanlarından oluşurken bunlardan biri her zaman baskın olarak gözükür. Örnek olarak, kendisinin yeterince ödüllendirilmediğini düşünen teknik çalışanlar öz-yönlendirilmeli olup kişisel ilgilerine teknik işlerden daha fazla öncelik verebilir.
Maslow’un modelindeki problem sadece insanın özendirme üzerindeki bakış açısını almasıdır. İnsanların kendilerini bir kurumun, profesyonel bir grubun ve genellikle bir kültürün parçası olarak hissetmeleri gerçeğini içermemiştir. İnsanlar sadece kişisel gereksinimleri ile değil bu geniş grupların amaçları ile de özenirler. Sıkı bir grubun üyesi olmak birçok insanı özendirir. İşlerini yapan insanlar sık sık iş yerlerine yaptıkları iş ve çalışma arkadaşları tarafından özendirilmek için giderler.

GRUP ÇALIŞMASI

Herkes için büyük bir takım içinde verimli olarak tek bir problem üzerinde çalışmanın imkansız olmasına rağmen profesyonel yazılımlar eleman sayıları iki ile birkaç yüz arasında değişen gruplar tarafından geliştirilir. Bu büyük gruplar genellikle birkaç alt gruba bölünür. Her alt grup bir alt sistemi çalıştıran alt projeden sorumludur. Genel bir kural olarak yazılım mühendisliği grupları sekiz üyeden daha fazla üyeye sahip olmamalıdır. Alt gruplar kullanıldığında iletişim problemi azaltılır. Bütün grup bir masanın etrafında ve diğerlerinin ofisinde toplanabilir. Karmaşık iletişim yapılarına gerek kalmaz.
Bu yüzden etkin çalışan bir grubu bir yere toplamak duyarlı bir yönetim işidir. Başarılı grupların, basitçe toplanmış, birbirine yakın yeteneklere sahip insanlardan oluşmasından daha fazla artıları olmasına rağmen grup üyelerinin birbirlerine yakın oranlarda teknik beceri, deneyim ve kişiliklerinin olmasının önemi ortadadır. İyi bir grup takım ruhuna sahiptir, kendi amaçları olarak gördükleri grubun başarıları ile özenirler. Bu yüzden gerekli olan grup dayanışmasının kurulması için yöneticiler takım etkinliklerine destek verirler.
Grup çalışmasını etkili kılan birkaç neden vardır :

1. Grup Oluşumu; Takımda doğru oranda beceri, deneyim ve kişilikler var mı?
2. Grup Dayanışması ; grup kendini beraber çalışan kişilikler topluluğu yerine bir takım olarak görüyor mu?
3. Grup İletişimi ; Grup üyeleri birbirleriyle etkin bir şekilde iletişim kurabiliyor mu?
4. Grup Düzenlemesi ; Grup, herkesin grup içinde değer verildiğini hissedecek ve grup içindeki görevi ile mutlu olacak şekilde düzenlenmiş mi?

Grup Oluşumu :

Birçok yazılım mühendisi ilk olarak kendi işleri ile özenirler. Bu yüzden yazılım geliştirme grupları teknik problemlerin nasıl çözüldüğüne ilişkin fikirleri olan insanlardan oluşmuştur. Bu göz ardı edilen ara yüz standartlarının, kodlanarak yeniden tasarlanan sistemlerin, gereksiz sistem ayrıntılarının düzenli olarak rapor edilmesi ile meydana çıkmaktadır. Bu tip problemler engellenmek isteniyorsa bir proje grubuna doğru insan seçmek zorunludur.
Birbirini tamamlayan insanlardan oluşan gruplar yalnızca teknik yeteneklerine göre seçilmiş gruplardan daha iyi çalışabilirler. İşi tarafından özendirilen insanlar teknik olarak da en iyi duruma gelirler. İşleri ile özendirilen insanlar teknik açıdan en iyiymiş gibidir. Öz yönlendirmeli insanlar işi başkasına devredip işten kurtulmakta en iyileridir. İletişim yönlendirmeli insanlar grup içinde iletişim kurarak yardımlaşırlar. Bir grup içinde iletişim yönlendirmeli insanlara sahip olmak kısmen önemlidir. Onlar insanlarla konuşmaktan hoşlanırlar ve böylece gerilim ve rahatsızlıkları erken safhalarda anlayabilirler. Grup üzerinde ciddi olarak etkileri olmadan onlar, kişisel problem ve farklılıkları çözümüne yardımcı olurlar.
Bazen grubu birbirini tamamlayan insanlardan seçmek imkansızdır. Bu durumda yöneticiler grup üyelerini kişisel hedeflerin grup hedefleri üzerine çıkmamamsı için kontrol etmelidir. Bu kontrol, tüm grup elemanlarının projenin her safhasına katılımının sağlanmasıyla kolayca sağlanır. Kişisel yetki, grup elemanlarının projenin genelinde ki rollerine bakmadan kullanılmaktadır.
Örnek olarak bir mühendise kodlaması için bir program tasarımının verildiğini düşünelim. Eğer bu mühendis tüm projenin mantığını anlamadan programda amacı aşan iyi yönde gelişmeler kaydederse, bu gelişmeler programın diğer kısımları için ters etkiler yaratabilir. Eğer tüm grup başından itibaren proje ile ilgilenirse tasarım kararlarının neden verildiğini anlarlar ve bu sayede bu kararlara karşı çıkmak yerine desteklerler.
Bir grupta lider önemli bir role sahiptir. O teknik yönetmenlik ve proje uzmanlık desteği sağlamak zorundadır. Grup liderleri grubunun çalışmalarını gün be gün izlemeli ve insanların etkin ve proje planlamasında proje yöneticilerine yakın çalışmalarını sağlamalıdırlar.
Liderler normalde proje yöneticilerine karşı sorumlu olmaları ve proje yöneticileri tarafından atanmalarına rağmen gerçekte teknik konular göz önüne alındığında gerçek lider olamayabilirler. Grup üyeleri diğer bir grup üyesine lider gözüyle bakabilirler. O, atanmış grup liderinden daha iyi bir mühendis ve insanları daha iyi özendiriyor olabilir.
Bazen teknik lider ile proje uzmanını ayırmak daha etkilidir. Teknik olarak yetenekli insanlar her zaman en iyi uzman olamazlar. Onlara uzman rolü verildiğinde bu onların gruptaki değerini düşürür. En iyisi onları günlük uzmanlık görevlerini hafifletecek yardımcı bir uzmanla desteklemektir.
Eğer istenmeyen bir lider gruba dayatılırsa bu gerilimler oluşturacaktır. Üyeler lidere saygı göstermeyip grup bağlılığını kişisel amaçlar için ret edebilirler. Bu problem, yazılım mühendisliğinde elemanların grup liderlerinden daha modern ve daha iyi eğitimli olması probleminin bir kısmıdır. Bazı deneyimli insanlar daha yeni fikirlere sahip genç liderlerin dayatılmasından hoşlanmazlar.




Grup Dayanışması

Dayanışma içindeki bir grupta üyeler grubun, içindeki kişilerden daha önemli olduğunu düşünürler. Dayanışma içinde, iyi düzenlenmiş bir grubun üyeleri gruplarına bağlıdırlar. Onlar grup amaçlarını grup üyelerinden ayırmazlar. Gruplarını bir varlık olarak dış etkilerden korumaya çalışırlar. Bu grubun dayanıklı, problemlerle ve beklenmedik durumlarla başa çıkabilir hale getirir. Grup ortak destek ve yardımlar sayesinde değişimlerle başa çıkabilir.

Grup dayanışmasının avantajları :

1. Grup kalite standardı geliştirilebilir. Çünkü bu standartlar ortak kararlarla oluşturulduğu için dışarıdan dayatılanlardan daha fazla saygı görür.
2. Grup üyeleri birbirlerine yakın çalışırlar. Grup içindeki insanlar birbirlerinden öğrenirler. Önem verilmemekten doğan çekingenlikler en aza indirilebilir ve karşılıklı öğrenme desteklenir.
3. Grup elemanları birbirlerinin işlerini öğrenebilirler. Bir grup üyesinin ayrılmasında devamlılık sağlanmalıdır.
4. Egosuz programlama sağlanabilir. Programlar kişisel ürünler yerine grup ürünü olarak görülür.
Egosuz programlama (Weinberg,1971) tasarım, program ve diğer belgelerin onları geliştiren kişilerin ürünü olarak değil, ortak ürün olarak görüldüğü bir grup çalışması şeklidir.Mühendisler işlerini bu şekilde düşündüğü durumda diğer grup elemanları tarafından daha fazla işi sahiplenme, kritik etme ve programın gelişimine ilişkin katkı görürler. Grup dayanışması geliştirilir çünkü tüm üyeler yazılımın sorumluluğunu paylaştığını hissederler.
Tasarım, program ve belgelerin kalitesi geliştikçe egosuz programlama grup içindeki iletişimi de geliştirir. Girişken tartışmaları statü ve cinsiyete bakmadan destekler. Üyeler diğer grup üyeleriyle proje doğrultusunda işbirliği yaparlar. Bu grup üyelerini bir arada çaçışmasını sağlayarak onların grubun birer parçası olduklarını hissetmelerini sağlar.
Grup dayanışması oganizasyonel kültür ve üyelerin kişiliklerini de içeren birçok etmene bağlıdır. Yöneticiler dayanışmayı birkaç şekilde özendirebilirler. Grup üyeleri ve aileleri için sosyal etkinlikler düzenleyebilirler, grup oluşumunu gruba bir isim vererek sağlayabilirler. Spor ve oyunlar gibi grup yapılandırma faaliyetleriyle doğrudan ilgilenebilirler.
Deneyimlerime göre dayanışmayı dayatmanın en önemli yollarından biri üyelere sorumlu ve güvenilir bir şekilde davranarak bilgilere erişim yetkisi verilmesidir. Sık olarak yöneticiler grubun tüm üyelerine açık bir bilgi vermezler. Bu durum güvensizlik ortamı yaratır. Basit bilgi aktarımı insanların grubun parçası gibi hissetmelerinin etkili ve ucuz bir yoludur.
Güçlü birbirine bağlı gruplar bazen iki problemle karşı karşıyadır:
1. Lider değişimine mantıksız direnç. Eğer dayanışma içindeki bir grubun lideri grup dışından başka bir lider ile değiştirilirse grup elemanları yeni lidere karşı birlikte cephe alabilirler. Grup üyeleri yeni lider tarafından dayatılan değişikliklere karşı direnç göstermek için zaman harcayarak üretkenliğin yitirilmesine sebep olabilirler. Bu yüzden yeni lider olarak grup içinden en iyi olan atanmalıdır.
2. Grup düşüncesi. Grup düşüncesi grup üyelerinin kritik yeteneklerinin grup bağlılığı yüzünden yıpratılması durumuna verilen isimdir. Alternatiflerin göz önüne alınması grup bağlılığının normları ve kararları doğrultusunda olur. Grubun çoğunluğu tarafından sunulan bir öneri daha doğru alternatifler göz önüne alınmadan kabul edilebilir.
Grup düşüncesini engellemek maksadıyla kritik kararlar için resmi oturumlar düzenlenebilir. Grup harici uzmanlar grup kararlarını gözden geçirmek için katılabilir. Tartışmacı, çok soru soran ve kaba insanlar grup üyesi olarak atanabilirler. Bunlar şeytanın avukatı gibi hareket edip devamlı grup kararlarını sorgulayarak diğer grup üyelerinin etkinliklerini sorgulamasına zorlayabilirler.

Grup İletişimi

Yazılım geliştirme grubunun üyeleri arasında iyi bir iletişimin olması gereklidir. Grup üyeleri kendi işlerinin statülerinde bilgi paylaşımı yapmak, kararlar almak ve daha önce alınmış kararlara değişiklikler yapmak zorundadır. İyi bir iletişim, grup üyelerinin gruptaki diğer insanların özendirme, güç ve zayıflıklarını anlamasıyla grup dayanışmasını da arttırır.


İletişimin etkinliğine etki eden bazı anahtar etmenler aşağıda olduğu gibidir :

1. Grup büyüklüğü : Grup büyüdükçe grup içinde etkin bir iletişim kurmak daha da zorlaşır. Tek yönlü iletişim bağlantı sayısının n*(n-1) ve “n” in grup büyüklüğü olduğu düşünülürse, 7 veya 8 üyeli bir grupta bir üyenin hemen hemen hiç iletişim kuramayacağını söylemek mümkündür. Grup elemanlarının statü farkları iletişimin çoğunlukla tek yönlü olacağını gösterir. Daha yüksek konumdaki üyeler iletişim kurmakta isteksiz olan daha düşük konumdaki üyelerle iletişim kurma eğilimindedir.
2. Grup yapısı :Resmi olmayan yapıda bir gruptaki insanlar aralarında resmi olanlardan daha etkin iletişim kurarlar. Sıra düzeni gruplarında iletişim sıra düzeninin altından yukarıya veya tersi şeklinde işleme eğilimindedir. Aynı seviyedeki insanlar birbirleriyle konuşmayabilirler. Bu birkaç geliştirme grubu olan büyük projelerde bir problemdir. Değişik alt sistemlerde çalışan insanlar eğer sadece yöneticileri ile iletişim kuruyorlarsa bu yanlış anlamalara ve gecikmelere yol açabilir.
3. Grup oluşumu : Eğer bir grupta birbiriyle aynı kişiliklere sahip çok insan varsa bunlar çatışabilir ve iletişim çekingen bir hale gelebilir. Genellikle her iki cinsiyetinde bulunduğu gruplardaki iletişim , sadece hem cinslerin olduklarında yapılandan daha iyidir(Marshall ve Heslin 1975). Kadınlar erkeklerden daha fazla iletişim yönlendirmelidir ve kadın grup üyeleri iletişim kontrolörü ve yardımcısı olarak görev yapabilirler.
4. Grubun fiziksel çalışma ortamı : çalışma ortamının düzeni iletişime yardımcı veya engel olmada ana etmenlerdendir.

Grup Düzenlemesi



Küçük programlama grupları genelde yansız olarak resmi olamayan şekilde kurumsallaşırlar olular. Grup lideri diğer grup elemanları içine karışır. Bir teknik lider yazılım ürününü etkin bir şekilde kontrol etmesi ile ortaya çıkabilir. Resmi olmayan bir grupta işler, grubun bütün olarak tartışması ve görevlerin deneyim ve yeteneklere göre dağıtımı ile yapılır. Üst seviye sistem tasarımı kıdemli grup elemanları tarafından yapılır fakat alt seviye tasarım kendine belirli görevler verilmiş üyeler tarafından yapılmaktadır.
Resmi olmayan gruplar, üyelerinin büyük kısmının becerikli ve deneyimli olduğunda, belirli görevlerde başarılı olabilirler. Demokratik bir ünite olarak grup fonksiyonları kararları oy birliği ile verir. Psikolojik olarak bu bütünlük ve performanstaki artışın sonucu olarak grup ruhunu geliştirir. Eğer bir grup yeteneksiz ve deneyimsiz üyelerden oluşuyorsa, resmi olmaması engel olabilir. İşle doğrudan ilgili olarak belirlenmiş bir yetkilinin olmaması grup üyeleri arasında anlaşma eksikliğine ve sonuç olarak projenin başarısızlığına yol açabilir.
Demokratik grupların ilginç kurumsal değişiklikleri Beck tarafından ‘uç programlama’ kitabında açıklanmıştır. İş programındaki kararlar gibi, genellikle yönetim tarafından verilen kararlarmış gibi gözüken, kararlar grup üyelerine devredilmiştir. Programcılar kod geliştirmek için çift olarak çalışırlar ve geliştirilen programın ortak sorumluluğunu alırlar.

Baker ve diğerleri (Aron,1974;Brooks,1975) çok yetenekli programcıların etkin kullanımının sağlanması takımların çok yetenekli tek bir şef programcı etrafında oluşturulması ile mümkün olduğunu önermektedir. Şef programcı takımının altında yatan prensip yetenekli ve deneyimli bir programcının tüm yazılım gelişiminden sorumlu olmasıdır.Onlar günlük işlerle uğraşmayıp işlerine iyi bir teknik ve uzman desteği vermelidir.Grup dışındaki insanlarla iletişimleri sınırlı olmalıdır.

Şef programcı takımının elemanları:

1. Sistemin kurulması, test edilmesi, programlanması ve tasarımı ile ilgili tüm sorumluluğu alan şef programcı
2. Şef programcıyı destekleyen ve yazılım geçerliliğinin sorumluluğunu alan deneyimli yardımcı programcı.
3. Konfigürasyon yönetimi, sonuç belgeleme gibi proje içindeki bürokratik işlerle ilgili olan kütüphaneci

Uygulamanın büyüklüğüne ve çeşidine göre diğer uzmanlar da takımla geçici veya sürekli olarak çalışabilir. Bunlar sistem yetkilileri, işletim sistemi veya dil bilim uzmanları olabilir.
Bu yaklaşımın mantığı yazılım mühendisleri arasında programlama yeteneği olarak farlılıkların olmasındandır. Bu yüzden en iyi insanları en etkin yolla kullanmak ve onlara sağlanabildiği kadar destek sağlanmasını gerektirir. Şef programlama grubu için önerilenlerin 25 yaş üzeri olmasına rağmen küçük geliştirme takımlarını etkin olarak düzenlemek için etkin bir yoldur.
Bazı problemler olmasına rağmen eğer doğru insanlara ulaşılabilirse bu iyi yapılanmış grubu kullanmak çok etkin olabilir.
1. Yetenekli tasarımcılar ve programcılar kolay bulunmazlar. Yaklaşım, mükemmel bir şef programcı ile vekil bir şef programcı üzerine dayandırılmaktadır. Eğer onlar hata yaparsa onların kararlarını sorgulayacak kimse yoktur. Demokratik bir grupta herhangi biri kararları sorgulayabilir ve onlarla birlikte problemleri araştırabilir.
2. Şef programcı tüm sorumluluğu alır ve başarının tüm kredisini talep edebilir. Proje içindeki rolleri fark edilmediyse grup üyeleri alıngan olabilir. Eğer tüm başarı şef programcıya mal edilirse üyelerin saygı görme gereksinimleri giderilmeyebilir.
3. Eğer şef programcı ve onun vekili hastalanır veya işi bırakırlarsa proje risk altına alınabilir. Yöneticiler böyle bir riski kabul etmeyebilir.
4. Kurumsal yapılar böyle grupların oluşumuna izin vermeyebilirler. Büyük işletmeler üst seviyede iyi gelişmiş yapıya sahip olabilirler. Şef programcıyı bu yapı dışında tutmak çok zordur. Küçük işletmelerde onlardan birini tamamen bir göreve atamak basitçe olanaksızdır.

Bu çeşit grubun deneyimlerinden öğrenebileceklerimiz olduğu halde Şef programcı takımları kurumların kabul edemeyeceği riskli bir strateji olabilir. Bu yüzden onların yetenekleri en iyi şekilde kullanılmalıdır. Uzmanların kısa süreli ulaşılabilir olması genel deneyimleri olan programcıların uzun süreli kullanılmasından daha üretken bir yol olabilir.

İNSANLARIN SEÇİLİP ELDE TUTULMASI

Proje yöneticilerinin bir rolü de projede çalışacakları seçmeleridir. Beklenmedik durumlarda, proje yöneticileri bütçe imkanları ve diğer sorumluluklarına bakmaksızın işe en uygun olan insanları seçerler. Daha normal olan proje yöneticilerinin sonsuz seçme olanağı olmamasına rağmen kurumdaki ulaşılabilir herhangi birini kullanma, insanları çok çabuk bulma ve bütçe olanakları gibi kısıtlamaları olabilir. Bütçe olanakları projede çalışacak deneyimli (pahalı) mühendis sayısını kısıtlayabilir.
Eğer bir yöneticinin proje için çalışacakları seçme olanağı varsa vereceği kararı etmenler etkileyebilir. Uygulama sahasına, proje türüne ve takımdaki diğer üyelerin yeteneklerine göre değişen bu etmenlerin önemliliklerine göre seviyelendirilmesine olanak yoktur.
Projeye çalışanların seçilmesi kararını verecek kimse bunu genellikle üç çeşit bilgi kullanarak yapar:
1. Adaylar tarafından sağlanan öz geçmişleri ve deneyimleri bilgisi(CV)
2. Adaylar ile yapılan görüşmelerle kazanılan bilgiler
3. Adaylar ile çalışmış diğer insanların önerileri.

Etmen Açıklama
Uygulama Alanı
Deneyimi Başarılı bir sistem geliştirme projesi için geliştiricilerin uygulama alanını anlaması gereklidir.
Platform Deneyimi Eğer alt-seviye programlama gerekli ise önemlidir. Diğer durumlarda önemli bir nitelik değildir.
Programlama Dili Deneyimi Bu, yeni bir dil öğrenmek için yeterli zamanın olmadığı kısa süreli projeler için önemlidir.
Eğitim Geçmişi Sadece adayın bilmesi gerekenler ve öğrenme yeteneği gibi ana esaslar için bir göstergedir. Mühendis, projelerde tecrübe kazandıkça bu faktörde önemsiz hale gelir.
İletişim Yeteneği Mühendisler, yöneticiler ve müşterilerle konuşması ve yazışması amacıyla ihtiyaç olan çalışan için önemlidir.
Uyum sağlayabilirlik Uyum sağlayabilirlik hakkında adayın daha önce kaç çeşit yerde çalıştığına bakılarak yargıya varılabilir. Bu, içine öğrenme yeteneğini de alan önemli bir özelliktir.
Davranış Çalışanın işine olumlu bir yaklaşımı olmalı ve yeni yetenekler kazanmak için istekli olmalıdır. Bu niteliğin değerlendirilmesi çoğu zaman zordur.
Kişilik Bu önemli fakat değerlendirilmesi zor bir niteliktir. Adaylar diğer üyelerle yeterli oranda uyuşabilmelidir. Yazılım mühendisliği için uyumlu veya uyumsuz olarak tanımlanabilen bir kişilik yoktur.





Bazı firmalar adayları değerlendirmek için değişik türlerde teste tabii tutarlar. Bunlar doğal programlama yetenekleri ile psikometrik testlerdir. Psikometrik testler adayın çeşitli görevler için uygunluğunu ve davranışını kapsayan psikolojik profilini oluşturmak için uygulanan testlerdir. Bazı yöneticiler bu testlerin kullanışsız olduğunu düşünürken diğerleri de çalışanları seçmek için faydalı bilgiler edinildiğini düşünmektedir. Daha önce de değinildiği gibi problem çözme yeteneğinin uzun süreli bir süreç olan anlamsal modellerin yapılandırılmasıyla ilgili olduğu görülmektedir. Doğal yetenek ve psikometrik testler genellikle sorulara çabuk karşılık verme esasına dayanmaktadır. Problem çözme yeteneği ile doğal yetenek testleri arasında bir bağlantı olduğu ikna edici bir şekilde gösterilememiştir.
Proje yöneticileri bazen uygun yetenek ve deneyimde insanlar bulmakta zorlanırlar. Takımlar birbiriyle bağlantılı deneyimlere sahip insanlarla yapılandırılmalıdır. Bu uygulama alanının veya kullanılan teknolojinin anlaşılamaması gibi problemleri ortadan kaldırabilir.
Bunun bir sebebi bazı firmalarda yetenekli insanların kısa yoldan kariyer sahibi olmalarıdır. Bu daha da geliştiğinde bu insanlar yönetici sorumlulukları almak zorundadır. Bu insanların yönetici kadrosuna yükselmeleri kullandıkları teknik yeteneklerinin yok olması demektir. Bunu engellemek için bazı firmalar teknik ve yönetici kariyerlerini eş değerde geliştirmişlerdir. Deneyimli teknik elemanlar yöneticilerle aynı şekilde ödüllendirilirler.Bir mühendisin kariyerinin gelişmesi açısından teknik veya yönetici etkinliklerde uzman olabilir veya ücrette bir kayıpla karşılaşmadan her ikisini de ayrı ayrı yapabilir.

Çalışma Ortamı

Çalışma ortamının insanların performanslarında ve işleri ile doyuma ulaşmalarında büyük etkileri vardır. Psikolojik deneyimler ispatlamıştır ki, davranışlar oda büyüklüğü, mobilya, araç-gereç, sıcaklık, nem, parlaklık /ışık miktarı, gürültü ve insanların özel hayatını yaşayabilmesi ile etkilenmekteyken grup davranışları kurum mimarisi ve telekomünikasyon etkinlikleri ile, grup içindeki iletişim ise bina mimarisi ve çalışma ortamı düzenlemesinden etkilenmektedir.
İyi çalışma koşulları sağmada gerçek ve önemli bir maliyet vardır. İnsanlar çalışma ortamlarında mutsuz olduklarında, çalışanların işleri artmaktadır. Bu yüzden işe alımlardan ve eğitimlerden daha fazla maliyetler oluşmaktadır. En sonunda ise yazılım projeleri kaliteli çalışan eksikliğinden gecikebilmektedir.
Yazılım geliştirme çalışanları genel olarak açık geniş ofis ortamlarında, bazen de odacıklarda çalışırlar. Sadece kıdemli yöneticiler kendilerine ait odalarda çalışırlar. McCue(1978) bir çalışmasında birçok firma tarafından benimsenen açık geniş ofis ortamlarının ne çok istenen ne de üretken yerler olduğunu önermiştir. Bu öneri içinde en önemli çevresel etmenler şöyle tanımlanmıştır:
1. Özel yaşam : Programcılar yoğunlaşabilecekleri ve rahatsız edilmeyecekleri bir ortama gereksinim duyarlar.
2. Dış Bilgi : İnsanlar doğal ışıkta ve dış manzara ile çalışmayı seçerler.
3. Kişiler değişik çalışma deneyimlerini ve dekora ilişkin değişik düşünceleri kabul ederler. Yeni çalışma deneyimi edinmek ve çevreyi kişiselleştirmek için iş yerini tekrar düzenleme olanağı önemlidir.

Kısaca insanlar kendi zevklerine göre düzenleyebilecekleri kişisel ofislerden hoşlanırlar. Buralarda açık geniş ofislerden daha az işleri bölünür ve daha az rahatsız edilirler. Açık geniş ofislerde insanlar özel hayatından yoksun olarak kendi çalışma yerlerini kişiselleştirmekte sınırlandırılmışlardır. Yoğunlaşma zor ve verim düşüktür.
Yazılım mühendislerine kişisel ofisler sağlamak üretkenlikte önemli bir fark yaratır. DeMarco(1985) iki çeşit çalışma yerindeki programcıların üretkenliklerini kıyaslamıştır. Özel bir çalışma mekanın ve rahatsız etmelerin kesilmesinin önemli bir etkisi olduğunu bulmuşlardır. İyi çalışma koşullarına sahip bir programcının kendi ile aynı yetenekte ama daha kötü çalışma ortamına sahip diğer bir programcıdan iki kat daha fazla üretken olduğu görülmüştür.
Geliştirici gruplar kendi üyelerinin hep birlikte grup olarak hissedebilecekleri ve projelerini resmi veya resmi olmayan şekilde tartışabilecekleri alanlara gereksinim duyarlar. Toplanma odaları tüm gruba özel alanlar sağlamalıdır. Kişisel özellik ve grup iletişimi gereksinimleri önemli nesnelerdir. McCue bu birbiriyle çelişen gereksinimlerin büyük toplanma alanlarının etrafında sıralanmış kişisel ofislerle sağlanmasını önermiştir



Benzer bir model Beck(2000) tarafından “uç programlama için çevre tanımlaması”nda önerilmiştir. Beck açık bir alanın, tüm programlama etkinliklerinin içinde yer aldığı bir ortam olarak ortak alanı önermiş, odaları ise grup üyelerinin yalnız çalışmak istediği ortamlar olarak düşünmüştür. Açık olarak anahtar gereksinim, grup elemanları için hem kişisel hem de grup olarak çalışabilecekleri ortamın sağlanmasıdır.
Bu tip iletişim, grup üyelerinin problemlerinin çözümü ve bilgi alış verişi için etkin ve resmi bir yoldur. Weinberg(1971) programcıların kahve makinesi başında birbirleriyle konuşarak harcadıkları zamanın kazanılması ile ilgili komik bir örnekten söz etmiştir. Kahve makinesinin kaldırıldığında dramatik olarak yardımcı programcı isteği ortaya çıkmıştır. Makine etrafındaki dedikodularla insanlar birbirlerinin problemlerine de yardımcı olmaktadır. Bu firmaların çalışanlarına resmi olan konferans salonlarının yanında resmi olmayan toplanma yerlerinin de sağlaması gerektiğini göstermektedir.



İnsanların Yetenek Olgunluk Modeli

A.B.D. deki Yazılım Mühendisliği Enstitüsü (SEI) “Uzun Süreli Yazılım Süreci” programı üzerinde çalışmaktadır. Bu programın bir kısmı Bölüm 25’te tartışılan yazılım süreci için yetenek olgunluk modelidir. Bu yazılım mühendisliğindeki en iyi çalışma ile ilgilidir. Bu modeli desteklemek için İnsan Yetenek Olgunluk Modeli’ni önermişlerdir(P-CMM). Bu, bir kurumun insan varlığını nasıl yönetmesi gerektiğinin geliştirilmesi için temel yapı oluşturabilir.
Aynı CMM gibi P-CMM’de şekil 22.9’da olduğu şekilde beş seviyeden oluşmaktadır. Bunlar :

1. Başlangıç ; resmi olmayan insan yönetim örnekleri kullanılır.
2. Tekrarlanabilir ; Çalışanların yeteneklerini geliştirme politikalarının ortaya konması
3. Tanımlanmış; En iyi insan yönetim örneklerinin kurumda standartlaştırılması
4. Yönetilmiş ; İnsan yönetimi ile ilgili nicel hedeflerin ortaya konması ve sunulması
5. Eniyileme ; devamlı olarak kişisel gelişme ve çalışma gücü özendirilmesi üzerine yoğunlaşma





Curtis(1995) P-CMM’in stratejik nesnelerini aşağıdaki şekilde sıralamıştır :

1. Yazılım kurumunun kapasitesini onların çalışma gücü kapasitesini arttırarak geliştirmek
2. Yazılım geliştirme kapasitesini birkaç kişinin değil kurumun bir etmeni haline getirmek
3. Kişilerin özendirilmesini, kurumun özendirilmesi haline dönüştürmek.
4. İnsan varlığının (kritik bilgi ve becerilere sahip olanların) kurumda tutulması.

P-CMM özendirme, tanımlama, standartlaştırma ve iyi uygulamaların geliştirilmesine bir temel oluşturduğundan dolayı bir kurumdaki insanların yönetiminin geliştirilmesi için iyi bir araçtır. Bu insanların ayrı birer kişilik olarak tanımlanması gereksiniminin önemini ve onların yeteneklerinin geliştirilmesini desteklemektedir. Tabii ki tüm uygulama bir çok kurum için çok pahalı ve gereksizdir