İnsan Kaynakları etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
İnsan Kaynakları etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

11 Ağustos 2015

Yazılım Geliştirme Ekibinin Bütünselliği

Bir yazılım geliştirme ekibi nasıl olmalıdır sorusuna yazılım projesinin bağlamına, müşterisine, karakterine vs. göre farklı farklı cevaplar verilebilir ancak çoğu zaman gözlemlediğim ve beni rahatsız eden bir yapılanma şekli çok yaygın; rollere göre kurulan ayrı ayrı ekipler. Mimari ekip, altyapı ekibi, tasarım ekibi, geliştirme ekibi, test ekibi, analiz ekibi, kalite ekibi vs. Bu ekiplerin hepsinin başında bir lider ve bu liderler de hiyerarşide bir üstte birine(proje yöneticisi, proğram yöneticisi, çözüm yöneticisi, direktör vs.) bağlılar. Burada beni rahatsız eden temel konu bu ekiplerin bir birlerinden ayrı olarak kendi işlerini yapabilecekleri varsayımı.

Bu yapılanma kültürü sanırım biraz da waterfall yazılım geliştirme mantalitesi kaynaklı. Projenin her aşaması(analiz, tasarım, geliştirme, test) ayrı ve büyük tek aktiviteler olarak yapılır ve bu aktiviteleri de konusunda uzman ayrı ekipler yapar. Etkileşim vardır ancak bürokrasi de vardır, liderler farklıdır, ayrı grup mantığı vardır, çatışma çıkma olasılığı yüksektir.

Bana yazılım geliştirme sürecinin iterativ, üst üste konularak ilerleme şeklinde olması daha anlamlı geldiği için ekibin de bir bütün olması, gerekli olan farklı yeteneklere(analiz, test, dba, programcı, mimar vs.) sahip bir bütün olması daha mantıklı geliyor. Çünkü o kadar da ayrı gayrı işler yapmıyoruz tasarım, geliştirme, test, analiz bunlar aralarında ciddi ve sürekli bir etkileşim olması gereken, bir birlerinin farklı bakış açılarına muhtaç aktiviteler. Hepimiz aynı gemideyiz hepimizin amacı aynı; çalışan, doğru yazılımı doğru şekilde üretmek. Bu amacın ayrı ayrı ekipler ile çok etkin bir şekilde gerçekleştirildiğini veya gerçekleştirilebileceğini çok sanmıyorum.

Bence hangi ekipdesin sorusuna bir çalışan test, analist, geliştirme vs. diye cevap veriyorsa orada bir sorun vardır, ancak x projesi, y projesi diye cevap veriyorsa doğru bir bakış açısı vardır. Burada uzmanlık sağlanması, aynı role sahip insanların bir arada olmasının teknik bilgi beceri acısından faydaları gibi konuları yazılım geliştirmenin dışında tutuyorum. Bunları sağlamak icin illaki yazılım geliştirme ekiplerini bölmek gerekmiyor.

"Tek Takım", "Tek Lider" gibi konular biraz daha açılabilir, üzerinde düşünülebilir konular. Örnek yapılanmalardan benim hoşuma gidenler Toyotanın şef mühendis mantığı ve spotify yazılım geliştirme ekiplerinin yapılanmaları var.

08 Temmuz 2015

Yazılım Üreten Organizasyonlarda Merkezileşme

Organizasyonel anlamda merkezileşme'den kastım daha çok karar mekanizmaları bağlamında; onlarca, yüzlerce insanın her gün yaptığı işi etkileyen kararların 2-3 kişi tarafından alınması. Konu(Organizasyon, yönetim vs.) hakkında derinlemesine bilgi sahibi birisi değilim, bahsedeceğim bazı yönetimsel kavramları tam anlamıyla açıklayamayabilirim, ancak yazılım üreten şirketlerdeki bu çeşit politikalar, yazılım üreten insanlara ve yazılım projelerine bakış açıma çok uymuyor, dolayısı ile ben konuya merkeze insanı koyarak neden merkezileşmemeliyiz bakış açısıyla bakmaya çalışacağım, biraz beyin fırtınası tarzında olacak.

Belkide yönetimin teorisi hakkında biraz daha gerilere gitmek gerekiyor, bugün çoğumuzun maruz kaldığı bakış açısını anlayabilmek için. 20.yy başları, sanayi devriminin iyice oturması, kapitalizm'in alt kademe insanlar için acımasız şartları, sosyalizm'i doğuran şartlar...

Frederick Winslow Taylor fabrikalarda farklı seviyelerde(işci, başmühendis) çalıştıktan sonra ekonomik verimlilik konusuna kafa yoruyor. Ve Bilimsel Yönetim adı altında bazı pratikler geliştiriyor ve bunları 1911 yılında bir kitap ile yayınlıyor. Taylor'ın bakış açısı tamamen ekonomik verimlilik üzerine, bunu sağlamak için her yol mübah gibi bir bakış açısı var, yani insan ikinci planda. Ve insana/işcilere bakış açısı genellemeci; işçiler sorumsuzdur, onları sürekli kontrol etmezsen işi savsaklarlar, onlar işlerini nasıl daha etkin yapabileceklerini bilmezler, hepsinin ödül/ceza motivasyonu aynıdır vs. şeklinde. Bunları aşabilmek için önerdiği yöntem; işleri planlayan, işçileri sürekli kontrol eden, onlara ne yapacaklarını, nasıl yapacaklarını sürekli anlatan, işcilerin performansını ölçen birileri olmalı, bir üst akıl, daha dogrusu bir üst akıllılar grubu olmalı. Ancak bu birileri işçilerin yaptıkları işin en iyi, en verimli nasıl yapılabileceğini bilebilir, uygulatabilir.

Taylor'un yöntemleri kullanılıyor elbet, ancak 1930'lar ile birlikte insana olan bu bakış açısı yavaş yavaş terk ediliyor. Taylor bu çalışmalarıyla, endüstri mühendisliğinin babası olarak biliniyor.

Douglas McGregor 1960'larda bir iş yerinde yöneticinin çalışanlarına bakış açısını gösteren, bir birine zıt 2 teori geliştiriyor; Theory X ve Theory Y.

Theory X'e göre insanlar tembel ve yaptıkları işten mutsuzdurlar, sorumluluktan kaçarlar. Dolayısı ile bu insanların verilen işi yapabilmeleri için otoriter bir yönetim stili gereklidir. Bu insanları yakın mesafeden kontrol etmek ve gerekiyorsa ceza vermek gereklidir.

Theory Y'e göre insanlar çalışarak bir şeyler başarmayı isterler ve bundan bir haz alırlar. Gerekli şartlar sağlandığında her insan sorumluluk almayı ister, motive olup, kendi kendini kontrol edebilir.

Her iki teoriden birisine uyan insanlarla beraber çalışıyor olabilirsiniz, tüm insanlar X'dir veya tüm insanlar Y'dir diye bir ön kabullenme yok. Aslında önemli olan bu iki yaklaşımın da bu iki insan tipinin de farkında olmak ve ona göre davranmak. X olan bir insanı Y bakış açınızla yönetemezsiniz, Y olanı da X bakış açısıyla.

Aynı bağlamda Peter Drucker'ın 1959'larda ortaya attığı knowledge worker diye bir kavram var. Türkçeye bilgi çalışanı olarak çevrilebiliyor. Bu insanlar hayatlarını düşünerek kazanan insanlar, en azından ağırlıklı olarak, doktorlar, mühendisler, bilim adamları, mimarlar gibi. Bu insanlar sürekli belli bir rutinde iş yapmazlar, problem çözerler, farklı bakış açılarını, yaklaşımları düşünmek işlerinin bir parçasıdır.

Drucker bu tip insanlarla çalışıyorsanız, bunların kendi işlerinin eğitimini aldıklarını ve yaptıkları işi en iyi kendilerinin bildiğini kabul etmek zorundasınız diyor. Bilgi çalışanlarının yöneticilerinin de bilgi çalışanı olması veya geçmişte bilgi çalışanı olmuş olması gerekir. Bu insanların motivasyon faktörlerini genelleyemezsiniz, bireysel olarak bu insanlarla ilgilenmek zorundasınız, bireysel farkındalık ile bu insanları motive edebilirsiniz.

Drucker 21.yy'da kurumların en değerli varlıkları bilgi çalışanları ve onların verimlilikleri olacak şeklinde bir öngörüde de bulunmuş.

Benim bakış açıma göre biz yazılım/bilgisayar mühendisleri kesinlikle bir bilgi çalışanıyız dolayısı ile bilgimize, tecrübemize, iş yapış şeklimize saygı duyarak, değer vererek yönetilmeliyiz diye düşünüyorum. Ancak çoğu zaman Taylor'un çalışanlara bakış mantalitesi ile yönetildiğimizi düşünüyorum.

Yönetilme şeklimizin odağında insan olmalı. Eğer yönetilme şeklimizin odağında ekonomik verimlilik, süreçler, ürün, proje vs. olursa bunları sağlamak çok zor ancak yönetilme şeklimizin odağında insan olursa ekonomik verimlilik, düzgün süreçler, düzgün ürünler hepsi bunun bir çıktısı olacaktır.

Tabi bu tek başına yeterli bir bakış açısı olmayabiliyor, doğru insan diye bir kavram işin içine giriyor. Siz doğru insanlarla çalışmıyorsanız, bu insanları Theory X'e göre yöneterek zar zor bir çıktı alabiliyor olabilirsiniz, aynı insanları knowledge worker mantığı ile yönetirseniz kaos üretiyor olabilirsiniz.

Peki doğru insanı nasıl bulacağız, işin içine insan girince, kesin ifadeler tanımlar çok gercekci olmayabiliyor ancak öncelikle Theory Y'deki tanıma uygun insanları seçmeye çalışmanız gerekiyor. İki anahtar kelime öne çıkıyor, iletişim ve merak. Yazılım mühendisleri için birinci yetenek çoğu zaman zor ama belli bir kriterin üzerinde olmasını beklemeliyiz, mükemmel teknik yetenekleri olan ama iletişim anlamında özürlü olan birisi ile bir noktaya kadar çalışabiliyorsunuz, gerçek başarıların bir takım çalışmasından çıktığına inanıyorsanız bu insanlarla uzun vadeli çalışamıyorsunuz.

Eğer yazılım üretirken bilgi çalışanı insanlarla çalışıyorsanız onları standartlaştırmaya çalışmanız, onlardan bağımsız süreçler tasarlamaya çalışmanız size çok bir fayda vermeyecektir. Yıllarca yazılım üreten bir bilgi çalışanına, hayatında iki satır kod yazmamış birilerinin, sırf teorik bilgiye dayanarak, nasıl çalışacağını tarif etmeye çalışması ne organizasyona ne de çalışana faydası olan bir yöntem. Bilgi çalışanlarının iş yapma şekilleri üzerine olan fikirlerinin üzeri, sırf bilgi çalışanı olmayan yöneticilerinin kafasına uymuyor diye çiziliyorsa, işi yapan yani gerçek yazılımı üreten kendisi olmadığı halde ortalıkta sürekli en iyi ben bilirim kafası ile dolaşanlar varsa, o organizasyondan sağlıklı çıktılar beklemek de çok gerçekçi değil.

Bilgi çalışanlarının olduğu bir organizasyonda sürekli merkezi kararlar alıp bunu dayatmak, yeni bilgi çalışanlarının gelişmesini engellediği gibi, insanların bu kararlara taahhüt vermelerini(commitment, buy-in) de engelliyor. Sonuç olarak asıl amacı yazılım üretmek olan firmada, yazılım üretmesi gereken bilgi çalışanları yazılım üretmek dışındaki her şeye odaklanmak zorunda kalıyorlar. Dolayısı ile yazılım üretilmiyor, yönetimin teşhisi çok farklı noktalara oluyor, daha fazla mikro yönetim, daha fazla kontrol devreye giriyor, ve daha kaotik bir sona doğru gidiliyor.

Bahsettiğim bakış açısı değişikliği ve insanların buna doğru tepki vermesi tabiki bir anda olabilecek bir şey değil. Yıllar boyunca insanlarda oturmuş bir yönetme ve yönetilme kültürü var, sadece şuna dikkat çekmek istiyorum; yöneticilerin ciddi bir beyin gücüyle çalıştıklarının farkında olmaları ve bu beyin gücünü kullanabilmek için ne gerekiyorsa ona yapmaları gerekiyor. Nihayetinde bu bir vizyon meselesi yani yöneticinin bakış açısında, hedefinde bu olmalı ve attığı her adımda bu hedefi gözetmeli. Çalışanlarına, bu işi siz yapıyorsunuz, bu işin sorumlusu da yetkilisi de sizsiniz bakış açısını vermeli, yöneticinin bu bakış açısının farkında olan ve bu profile uymayan çalışanlar zaten uzun vadede orada tutunamayacaklardır.

Burada denetimsiz bir şekilde her şeyin çalışanlara delegasyonu anlaşılmasın, süreclerinizde elbette farklı seviyelerde raporlamalarınız, ölçümleriniz olacak. Bunlara göre şartlar değişmiş ise sürekli planlama yapmanız gerekecek. Denetim konusunda yapıcı mıyız yoksa yıkıcı/cezalandırıcı mıyız sorusunun sorulması gerekiyor.

Bu işi tarihsel bir süreçte halletmiş ve nihayetinde çok iyi noktalara gelmiş örnekler var; TPS(Toyota Production System) gibi, tabi biz japon değiliz, araba da üretmiyoruz. Ancak Japonlar bu mantalitelerini farklı ülkelerde kurdukları fabrikalarda da uygulayabiliyorlar, önemli olan nasıl bir değer ve prensipler kümenizin olduğu, pratikler sektörden sektöre, ülkeden ülkeye değişebilir.

Önemli olan insana ve yaptığımız işe bakış açımızın bize ne kattığını ne katmadığını ciddi anlamda sorgulamak, odağı doğru yere yani insana yani yazılım geliştirme döngüsündeki en önemli varlığa ve onların beraber çalışabilmesine(ekip ruhuna) çevirmek. Yazılım geliştirme işini yapan çalışanlara, sanat ve fikir eseri geliştiren bir çalışanmış bir ustaymış gibi bakmak gerekiyor. Bu kültürü oturtmak ve insanları da bu kültür içinde yetiştirmek gerekiyor. İnsanlara zaten karşılığında parasını alıyorlar eş...k gibi yapacaklar sığ düşüncesinden ziyade sanki onları oraya gönüllü toplamışsınız da bir şeyler yaptırmaya çalışıyormussunuz gibi yaklaşmak gerekiyor. Ama bunu bizim insanımız suistimal eder, hic bir şey üretemeyiz karşı çıkışlarını yapanlar acaba hayatlarında hiç bunu denediler mi merak ediyorum. Suistimal edenler çıkabilir ancak bunu genelleyemezsiniz, suistimal edenlerden kurtulursunuz yolunuza doğru insanlarla devam edersiniz.

Gerçekten mükemmel ürünler/projeler üretmek istiyorsak mükemmel insanlara ihtiyacımız var, mükemmel insanları çekmek ve onların bizimle kalmasını sağlamak için de mükemmel organizasyonlara ihtiyacımız var.

İnsanlara şunu söylettirebilmektir bence bir organizasyon için gerçek başarı; "Her sabah uyanıp işe giderken şunu biliyorum ki mükemmel insanlarla mükemmel bir ortamda çalışacağım ve anlamlı bir şeyler yapacağım/başaracağım..."

Büyüdükçe merkezileşen, merkezileşme gereği duyan bir organizasyon bence düzgün büyünmediğinin önemli bir göstergesidir.

Kendisini "management exorcist" olarak tanımlayan Niels Pflaeging'i Agile Turkey Submit 2014 konferansında dinlemiştim, bakış açısı hoşuma gitmişti. Organize for Complexity isimli bir kitabı var, kitap biraz sunum tadında, içinde epey görsel var ama vermeye çalıştığı mesajı gayet iyi veriyor.

18 Temmuz 2013

Uyumayan Tavşan ve Bildiğiniz Kaplumbağa

Organizasyonel anlamda çalışanlarınız arasında faydalı bir rekabet oluşturulması hem organizasyonun hem de çalışanların faydasınadır. Hem organizasyonel olarak hem de bireysel olarak sürekli bir iyileşmenin ateşleyici etkenlerinden biridir. Bunu yapmayıp iyiyi vasatı aynı şekilde değerlendirip aynı geri bildirimleri onlara verirseniz bunun hem organizasyon için hem iyi hem de vasat bireyler için olumsuz sonuçları olur.

Kaplumbağa ve tavşanı yarıştırıyorsunuz, tavşan uyumuyor ancak sürekli kaplumbağa ile yarışı beraber bitiriyorlar ne olduğunu hiç anlamıyor. Tavşan ne kadar çabalasa da bir şey değişmiyor, kaplumbağa aynı kaplumbağa ama her yarışın sonunda kamlumbağayı birisi alıp tavşanın yanına koyup, “Aferin aynı zamanda bitirdiniz!” diyor. Neden? Önemli olan yarışmak mı, ama yarışmıyor da, o zaman önemli olan kaplumbağanın orda olması, ne yarışmasının önemi var ne de yarışmayı kazanmak icin çaba sarfetmesinin. Neden çaba sarfetsin ki zaten yarışı her zaman beraber bitiriyorlar. Birileri kaplumbağanın kaplumbağa olduğunu ısrarla anlamak istemiyor ve ondan tavşandan ne beklerse onu bekliyor, ama farketmiyor ki, kaplumbağa istenileni veremese farketmiyor...

Örneğin bir pozisyonun gerekliliği alan uzmanlığı ve teknik yeterlilik ise sadece alan uzmanı olan ancak teknik olarak yeterli olmayan insanları da bu pozisyonda tutmanız gerektiğinde benzer bir duruma düsüyorsunuz. Tam tersi bir durum genelde geçerli olmuyor yani alan uzmanı olmayan ancak teknik olarak yeterli olan insanları ekip lideri yapamıyorsunuz. Bu insanlar yıllardır aynı ezberde iş yaptıkları icin bu ezberin dışına çıkmaları çok mümkün olmuyor ki zaten o ezberin dışı hakkında da hic bir fikirleri yok. Daha önce yapılmayan bir işi yapmalarını istediğinizde bocalıyorlar. Yani bildiği iş alanı bilgisini çıkarın geriye pek bir şey kalmıyor.

Bu arkadaşları  başka çalışanların başına lider olarak koyarsanız, beraber çalıştığı kendi ekibindeki insanlar açısından iş alanı bilgisi almaktan başka bir işe yaramıyor. Teknik meselelere gelince ne bir yönlendirme var, ne de bir çözüm üretiyorlar ve çoğu iş hayatına yeni başlamış ekip arkadaşları bir bataklığın içinde debelendikçe daha da dibe batıyorlar.

Yeterli yetersiz herkesten aynı rolü oynaması isteniyor ancak bazıları rolün hakkını veremeyince onun altında kalıyorlar. Buna rağmen yine herkesin aynı olarak değerlendirilmeye devam edilmesi ise bireysel ve organizasyonel olarak ilerlemeyi durduruyor. Çünkü bu şekilde davranarak rolün hakkını verenlerin de motivasyonunu kırıyorsunuz. Bir rekabet ortamı yok, çünkü rekabet edilecek kimse yok, ki rekabet etseniz de bir anlam ifade etmiyor, sonuc olarak aynısınız. Bu hem iyiler hem de vasatlar icin aynı derecede önemli, iyiler yapmaya çalıştıklarının karşılığını alamıyorlar, vasatlar bir şey yapsada yapmasada farketmiyor, iyilerle arasında da zaten bir fark yok neden çaba sarfetsin ki? Veya çaba sarfetmesi gerektiğinin bile farkında değil dünyayı bildiğinden ibaret sanıyor. Sürekli iyileştirme, daha iyi daha düzgün iş yapma diye bir bakış açısı yok.

Bir organizasyonda roller ve sorumluluklar net olarak ayrıştırılmalıdır. Rolünün hakkını verenler ile vermeyenler de net olarak ayrıştırılmalıdır. “Ne şiş yansın ne kebab” mantığının bence organizasyonel anlamda uzun vadede bir faydası yok. Elinizdeki iyilerin gözü sürekli dışarda olur, bazıları gider, siz de vasatlarla beraber kalırsınız. Hedefleriniz vizyonunuz uzun vadeli ise bence bakış acısı bu olmalıdır, yok yarın ne olacağı belli degil biz günü kurtaralım yeter diyorsanız o zaman zaten bir şey yapmaya gerek yok. Ancak organizasyonunuza yeni elemanlar, birazcık da olsa iyi elemanlar almak icin göbeğiniz çatlıyorsa bu politikanızı ciddi anlamda gözden gecirmeniz gerekir.

Organizasyonel olarak bu şekildeki mevcut politikanızdan bugüne kadar bir zarar görmemiş olmanız politikanızın doğruluğundan değil biraz insanların kültürü ile alakalı. Yapılan haksızlığa sesini çıkarmaktan aciz, var olanı kabullenen, bana dokunmayan yılan bin yaşasın mantığıyla hareket eden çalışanlarınızdan dolayıdır. Ancak bir gün birileri uyanırsa ve en önemli kaynağınız insansa çok kötü çuvallarsınız.

İnsanlara verilen değer çalıştığı yıl ile değil ürettiği değer ile doğru orantılı olmalıdır. Bugüne kadar ne üretti, ortaya ne koydu, neleri iyileştirdi bize ne kattı şeklinde değerlendirmeler yapıldığında ortaya ne çıkıyorsa kişiye verilen değer de o kadar olmalıdır. O zaman tecrübelileri elimizde tutamayız, onları küstürürüz derseniz o zaman siz de değer üreten tecrübelileri elinizde tutun değer üretmeyenleri tutmanızın zaten anlamı yok, belki bazılarının gerçekten küsmesi gerekiyordur. Değer üretmeyen 3 tane elamanınız olacağına değer üreten 1 tane elemanınız olsun.


Kaplumbağalar tavşan değildir gözünüzü açın, alın kaplumbağaları kaplumbağaların içine koyun, kaplumbağalar da mutlu olsun tavşanlar da.