Search Results for: nitelik

Nitelikli Eleman Açığı mı Niteliksiz Yönetici Fazlası mı?

BT, Yazılım Mühendisliği ,

Sosyal mekanlarda gezinirken “Yazılım Sektörünün En Önemli Sorunu Nitelikli Eleman Açığı” başlıklı bir yazı gördüm. Aslında sık sık gördüğümüz, ezberlenmiş türden başlıklardan birisi. Nedense bu sefer farklı geldi bana ve bu yazıyı yazmaktan kendimi alıkoyamadım. Bu tür açıklamalarda sık sık BT sektöründeki sivil toplum kuruluşları öne çıkıyor. Bu haberde de Yazılım Sanayicileri Derneği‘nin (Yasad) adı geçiyordu. Bu haberi Yasad’ın sayfasında da görmek mümkün.

Bu ülkedeki yazılım sektöründeki patronların ve yöneticilerin bir araya gelip dernekler oluşturmaları ve sektörü geliştirme amaçlı faaliyetlerde bulunmaları, devleti bu konuda yönlendirmeleri güzel bir şey. Her devlet gibi bizim devletimizin de bu tür danışmanlıklara ihtiyacı var. Ama ya bu yönlendirmeyi yapanların kendilerinin yönlendirme ihtiyaçları varsa? Ya bu tür kuruluşlar, “sektörün yetişmiş nitelikli elemana ihtiyacı var” derken gerçek ihtiyacın nerede olduğunu ciddi bir şekilde atlayıp, yazılımda daha iyi durumda olan yabancıların sektör gazete ve dergilerinde gördükleri haberlerde ifade edilen problemlerinin aynısının bizde de olduğu vehmine kapılıyorlarsa? İşin açıkçası bunları yazarken “yazlılım sanayicisi”nin ne anlama geldiğine ve “eleman” kelimesine takılmamaya çalışıyorum, çünkü bu yazıyı kara mizah yapmak istemiyorum.

Yazılımın içinden birisi olarak ülkemizin en ciddi sorununun nitelikli eleman eksiği olduğuna katılmıyorum. Bu tür haberlerde, konuşmalarda geçen “eleman” kelimesiyle kastedilenin (“eleman” nitelendirmesiyle her ne kadar kelle sayısı hesabı yapan dolayısıyla da itici bir anlayışı yansıtsa da), üniversitelerden sektörümüze sunulan mezunlar olduğu açıktır. Denilen, üniversitelerden yeterince mezun gelmediği ve gelenlerin de ihtiyacı karşılamadığı iddiasıdır. Evet bu bir problem, üniversitelerden hem sayı hem de kalite olarak yeterli mezun çıkmıyor. Ama kendimizi kandırmayalım, problemin büyüğü bu değil, yani bence durum bundan daha vahim. Bakın “eleman açığı”ndan şikayet şu anlama geliyor: “Ülkemizdeki yazılım sektörünün başka problemleri olsa da en büyüğü eleman açığıdır. Yani sektör var olan elemanları düzgün bir şekilde değerlendiriyor, imkanlar elverdiğince iyi işler çıkarıyor ve daha çok yeni elemana ihtiyaç duyuyor. Dolayısıyla en büyük engelimiz eleman açığı, eleman sayımız yetse, siz görün bizi.” Tırnak içinde yazdığım bu düşünceyi ifade eden yine Yasad’ın sayfasındaki şu habere bakılabilir. Haberde sektörün eleman açığının giderilmesiyle uçuşa geçeceğimiz ifade ediliyor.

Bence yine kendimize kendimizin propagandasını yapıyoruz. Çok açık bir şey var, ülkemizdeki yazılım sektörü dişe dokunur bir şey geliştirmekten malesef uzak. Geliştirdiklerimiz kalite olarak son derece düşük, o yüzden dünya yazılım piyasasına sunulabilecek cinsten değil. Çünkü hala kahramanca savaşan yazılımcılara bağlı olarak iş yapıyoruz, süreç tabanlı yazılım geliştirmeden çok uzağız. Daha program ile yazılım arasındaki farkı kavrayabilmiş değiliz. Nasıl futbol oynuyorsak öyle yazılım geliştiriyoruz; ikisinin de en temel dinamiği kaos.

Yazılım sektörünün esas sorununun “eleman açığı” olduğunu söyleyerek, kayıp yüzüğünü, kaybettiği samanlıkta aramayıp, kapının önünde arayan ve neden böyle yaptığı sorulduğunda da “samanlık karanlık ama” diyen Nasrettin hocamızın tiye aldıklarından oluyoruz. Bence bu ülkenin yazılım sektöründeki en temel problem nitelikli eleman açığı değil, niteliksiz yönetici fazlasıdır! Var olan iş gücü potansiyelimizi bile değerlendirmekten uzağız, kaotik bir şekilde iş yapıyoruz, başarımız çoğunlukla şansa bağlı, enerjimizi ve zekamızı yanlış yerlere harcıyoruz. Ve bence bu durumun en başlıca sebebi, yazılım “elemanları” değil, yazılım yöneticileridir, karar vericileridir.

Kifayetsiz yazılım yöneticilerine sahip olmamızın bence iki sebebi vardır. İlki yazılım yöneticilerimizin bizatihi kendileri ile bir şekilde yazılım geliştirme süreçlerini yöneten ya da yön verenler (örneğin daha üst düzey “C” seviyesindeki yöneticiler), daha yazılımın ne olduğundan, tabiatından, süreçlerinden, rollerinden ve yetkinliklerinden vs. habersizler. Bu konuda en temel ayrımları bile bilmediklerine ben defalarca şahit olmuşumdur. Çünkü bu yöneticiler muhtemelen kariyerlerinin başında teknik pozisyonlarda bulunmuşlardır ama daha işlerinde ustalaşmadan yönetici oluvermişlerdir ya da daha doğru ifadeyle yapılıverilmişlerdir. Dolayısıyla henüz öğrenmedikleri bir işi yönetmeye çalışıyorlardır. Yani, tabii olarak gördüklerini uyguluyorlar. Örneğin, projelerdeki en temel problem çözme yöntemleri, fazla mesaidir. Çünkü onlar da fazla mesai ile projeleri kurtarmaya çalıştılar.

Mesleğinde yeterince olgunlaşmadan yönetici olmanın bir başka handikapı da, kendilerini yönetici yapanlara karşı çıkamama şeklinde kendini göstermektedir. Zaten kafasında henüz bir sistem oluşturacak, süreci baştan sona kavrayacak şekilde olgunlaşmamış durumda olduklarından, teknik kaliteyi öne çıkarmaları, iş yapış şekilleriyle ilgili bir yenilik yapmaları ve nihayetinde var olan düzeni değiştirmeleri, üstlerinin kararlarına karşı çıkabilmeleri mümkün değildir. Bundan dolayı bizim sektörümüzde orta düzey yönetici olmak, tokmağı başkasının elinde olan davulu sırtında taşımaktır.

Bu ülkenin, daha mesleğini öğrenmeden o mesleği yönetmeye çalışan yöneticileri var. Bu ülkenin daha 30’una gelmediği halde, hızını almış giderken, teknik olarak ilerlerken, yaptığından zevk alırken, programcılıktan tam işin mimari ve mühendislik kısımlarına atlamaya hazırlanan ya da ekran analistliğinden çıkıp sistem analistliğine doğru ilerleyen civa gibi gençlerini bulunduğu ortamdan aniden koparıp, “sen yöneticisin artık” diyen ve muhteşem mühendis adaylarını berbat yöneticilere dönüştüren bir kültürü var. O kadar çok arkadaşım var ki bu durumda olan. Hepsi çok iyi eğitim almışlar, mesleklerinin ilk 5-6-7, bilemediniz 10 yılında bu eğitimin üzerinde deli gibi bilgi ve tecrübe inşa etmişler. Bu arkadaşlarım ya da tanıdıklarım, tam mesleklerinde çıraklığı atıp, olgunluk çağlarına gelmişler, bundan dolayı da belki daha stratejik konulara ele atacaklar, iş yapış şekillerini düzeltecekler, kaliteyi arttırmaya odaklanacaklar ya da meşreplerine ve ilgilerine göre değişik konularda uzmanlaşacaklar, belki kimileri kitap yazacak, belki çok odaklı, niche, bir konuda bir gelişme sağlayacaklar ve hem ülke hem de insanlık adına bir katkıda bulunacaklar. Ama sektörün böyle insanlar yetiştirmek gibi bir derdi yok ki!  Hemen tüm bu şekilde gelişmeye çalışan arkadaşlarımın önü, daha yüksek maaşla yönetici yapılarak kesilmekte. Daha geçen gün bu şekildeki bir arkadaşım “ben bu ülke için bir kayıpım” dedi bana. Çünkü iyi bir mühendisken, sırf maddi ve sosyal şartlardan dolayı yönetici oluvermişti.

Kifayetsiz yöneticilere sahip olmamızın ikinci sebebi ise, bu yöneticilerin bu makama gelirken hatta geldikten sonra herhangi bir yöneticilik formasyonundan geçmemiş olmalarıdır. Genelde işini iyi yapan, iyi eğitim almış, zeki ve başarılı yazılımcılar, programcı olsun, analist olsun, 3-5 sene içinde bir şekilde yöneticiliğe tabii olarak geçerler. İyi mühendis, iyi programcı, iyi sistemci, iyi bir yönetici olmak için gerek sebep olabilir ama yeter sebep değildir. Yüksek empati yeteneğine sahip olmadan iyi bir sistemci olabilirsiniz, iyi bir organizatör olmadan iyi bir programcı olabilirsiniz, iyi bir arabulucu olmadan iyi bir tasarımcı olabilirsiniz ama bunlar olmadan iyi bir yönetici olamazsınız. Bu durumun benim sıklıkla gözlemlediğim, en açık göstergesi ise yazılım yöneticilerimizin ezici bir kısmının, senelerdir yöneticilik yapığı halde hala doğru detay seviyesinde bulunmayı beceremeleridir. Ya hala çok teknik davranırlar ve bu yüzden altında çalışan teknik insanlara güvenip iş teslim edemezler, bu yüzden de detayda boğulurlar, ya da işin sadece tarihleri ve maliyetiyle ilgilenirler ve üst yönetimin kararlarını altlarına uygulatmak dışında bir insiyatifleri yoktur. Her iki halde de başarılı olamazlar.

Yöneticilik, öğrenilebilir. Ama bir eğitim ve öğrenim sürecinden geçmeden bir şekilde yönetici olanlar ki buna ben de dahilim ve ne olduğunu çok iyi biliyorum, ancak hasbel kader yöneticilik yapabilirler. Yani sektörümüzdeki yöneticiler genel olarak, ne yazılımı ne de yönetimi bilmeyen insanlardır. Yöneticilik algısı ve yeteneği olanlar, uzun vadede başarılı yönetici olabilirler, örneğin hangi detayda kalacaklarını öğrenirler, teknik insanlarla nasıl konusacaklarını belirlemiş olurlar belki ama bu sırada kaç çalışan ve proje telef olur, bilinmez.

Bu ülkenin yazılım sektörünün tek sıkıntısı hakikatten üniversiteden sektöre akan mezunların sayısı olsaydı, örneğin onlara karşı da bu sektör “deneyimin yok ama” sendromunu yaşatmazdı ve bu ülkede çok daha farklı şeyler olurdu.

Ben de yöneticilik yaptım, sıkıntılarını iyi biliyorum. Bu ülkede orta düzey yazılım yöneticisi olmak çoğu zaman yukarıda da söylediğim gibi, tokmağı başkalarının elinde olan davulu taşımaktır. Sektörümüzde yönetici olmak çoğu zaman tetikçiliktir, üstte verilen kararların aşağıya uygulatılmasından sorumlu olmaktır, örneğin bitiş tarihini üstlerinin belirlediği projeyi, alttakilerin ensesinde boza pişirme pahasına bitirmektir. Dolayısıyla bence sektörümüzün sıkıntıları ne teknolojiktir, ne kişi sayısıyla ilgilidir ne de doğrudan maddidir; yoğun olarak kültüreldir. Teknik kaliteye önem vermeyen ve her şeyi insan manipulasyonu ile yapmaya çalışan zihniyetimizi değiştirmedikçe her ilçeye bir üniversite kursak bile, yazılım gibi yüksek soyutlama gerektiren disiplinlerde durum değişmeyecektir.

Toplam görüntülenme sayısı: 4134

Programlama Nedir: Programlamanın Tabiatı ve Programcılık Üzerine – II Bilim mi, Mühendislik mi, Sanat mı Yoksa Zanaat mı?

Bilgisayar Bilimleri, Programlama, Yazılım Mühendisliği ,

Farklı vesilelerle “programlamanın neliği” hakkında konuşuyoruz, okuyup yazıyoruz. Ben de burada daha önce “Programlamanın Tabiatı ve Programcılık Üzerine – I” başlıklı bir yazı yazmıştım. Bu konu üzerine düşünen ve bizzat çalışan farklı kişiler de yazıp çiziyorlar. Örneğin arkadaşım Özcan Acar burada programcılığın sanat mı yoksa zanaat mı olduğunu tartışırken burada da bu konuda bir başka programcının yazdıklarını eleştirmiş.

Sıklıkla programlama ve programcılık, mühendis olup olmamak, okullu-alaylı vb. bağlamlarda tartışılıyor. Ben “üniversiteli mi alaylı mı” konusunu burada ele almıştım. Orada da açık bir şekilde ifade ettiğim gibi aslolan, “bilerek yapmak”tır. Yapmayı sürdürülebilir halde tutan şey bilmektir. Yapamadıkça zaten o şeyi bilmiyoruz demektir. Dolayısıyla her şart altında yapabilen ve başkalarına aktarabilen kişi, yapabilmeyi sürekli bir davranışa dönüştürmüş ve onu herkesin anlayabileceği yapıda ifade etmiş kişi, gerçekten bilendir.

Öte taraftan, gerek akademide gerek ise pratisyenleri arasında, yazılım mühendisliği olsun, onun çok temel ve belirleyici bileşeni olarak programlama olsun, tüm bunların gerçekte ne oldukları üzerine eskiden bu yana tartışmalar yapılmakta. Yani yaptığımız iş, bir bilim midir, yoksa mühendislik midir yoksa sanat mıdır yoksa zanaat mıdır? Ya da hepsi bir arada mıdır?

ABD’de yazılım sektörüne nitelikli insan yetiştiren bölümler ağırlıklı olarak “Computer Science” olarak adlandırılmalarına rağmen, bu bölümlerin yaptığı seyin ne kadar “bilim” olduğuyla ilgili şüpheler çoktur. Belki de bu isimlendirme bir öykünmedir ya da bu bölümlerin tarihi olarak Matematik’ten çıkmış oldukları düşünülerek isimlerine “science” eklenmiştir. Aslında iki kelimeden oluşan bu ismin problemi sadece “science” kelimesinden kaynaklanmıyor, esas problem”computer” kelimesinde. Dijsktra bir zamanlar “astronomy ne kadar teleskoplarla ilgiliyse, computer science da ancak o kadar bilgisayarlarla ilgilidir” (“computer science is no more about computers than astronomy is about telescopes.”) demişti.

“Computer Science” isimlendirmesi ilk defa 1959’da kullanılmasına rağmen yerine zaman zaman farklı kelimeler teklif edildi. “Datalogy” ya da “computics” bu alternatif isimlerden bir kaçı. Bu anlamda sanırım Avrupalılar daha düzgün bir isimlendirme yapmışlar. Bu alan için Avrupa’da genel olarak “automatic information” anlamlarına gelen “informatics”in türevleri kullanılıyor. Aslen yapılan iş de zaten verinin ve bilginin otomatik olarak işlenmesidir. “Computer” ya da “bilgiayar” sadece bir araç. Biz ise bu durumu dilimizde “bilgi” ve “saymak” kelimeleri ile ifade etmişiz. Başlarda, 70li yıllarda yani, bilgisayar yerine “elektronik beyin” dendiğini de hatırlıyorum ben. (Ülkemizde bu alanın “Bilgisayar Mühendisliği” olarak ifade edilmesi, hele benim üniversitemin, İTÜ, “Kontrol ve Bilgisayar Mühendisliği” gibi dahiyane bir isim 🙂 bulması ise başka bir tartışma konusu.) (Bu konudaki isimler için hızlıca Wikipedia‘ya bakabilrisiniz.)

Tanınmış ve tecrübeli bir bilim adamı olan Peter J. Denning, savunma amacıyla yazdığı “Is Computer Science Science?” başlıklı makalesinde, “Computer Science”ın (CS) ne kadar bilim olduğunu tartışıyor. Yazar makalesine alt başlık olarak şunu koymuş: “CS bilim olmanın tüm şartlarını taşıyor fakat kendinden kaynaklanan bir güvenirlik problemi var.” Yazara göre CS’i oluşturan 3 farklı disiplin vardır: Matematik, bilim ve mühendislik. Denning, CS’in, Fizik ve Kimya gibi bir “exact science” (bu terimi dilimizde nasıl ifade ediyoruz bilmiyorum, “kesin bilim” mi, bir kaç yere çevirisine baktım, “pozitif bilim” olarak karşılık verilmiş ki bu durum doğru bir çeviri değil bence) olduğunu savunuyor. Çünkü CS, adında “computer” kelimesini barındırsa da aslen bilgiyi işlemenin bilimidir. Algoritmalar ve hesaplamalı bilim (computational science) CS’i bilim yapan alanlardandır ve sayısal kesinliğe sahip çalışmalardır. Yazılımı tasarlama ve geliştirme ise temelde mühendislik çalışmasıdır. Yazar CS’in ne kadar bilim olduğu konusundaki itirazlara cevap vermeye çalışırken, “Computer Science”daki “science” yani “bilim” kısmının, diğer iki disiplin olan mühendislik ve matematikten daha geride kaldığını kabul ediyor ve ekliyor: Bu durum yakında düzelecektir.

Ben yaptığımız işin bir bilimsel tarafının olduğunu bir gerçek olarak kabul ediyorum. Programlama ve yazılım geliştirmenin son derece matematiksel dolayısıyla da bilimsel bir “hesaplama” alt yapısı var. Zaten bizim “bilgi” ve “saymak” kelimelerini yanyana getirerek ifade ettiğimiz şey İngilizce’de “computer” yani “”hesaplayıcı”dır. Veriyi ve bilgiyi işlemenin yöntemi olan her türlü algoritmik yapı, doğrudan matematiğin de konusudur. Algoritmaların karmaşıklığı, zaman ve bellek açısından ihtiyaçları, daha etkin şekilde ifade edilmeleri, tipik bir uygulamalı matematik ve sayılar teorisi konusudur. Sonuçta yazılan her program bir şekilde bir algoritmadır dolayısıyla da matematiğin ve bilimin konusudur.

Donald Knuth, programlama dünyasının muhtemelen yaşayan en ünlüsü olup, uzun yıllar Stanford’da hocalık yaptı. 1962 yılında tek cilt olarak yazmayı düşündüğü temel programlama kitabı, şu anda 4 cilt olarak yayınlanmış durumda. Hala yayınlamayı planladığı 3 cilt daha var. Knuth, programlamanın en temel kitabı olarak bilinen bu diziye, “The Art of Computer Programming” ismini vermiştir.  Çünkü Knuth’a göre programlama, bir sanattır.

Knuth gibi programlamanın bir sanat olduğunu iddia edenler, ondaki yaratıcılığa (creativity) ve bu yaratıcılığı ortaya çıkaran ilham (inspiration) kavramına vurgu yaparlar. Evet, yazılım geliştirmek de programlamak da zihinsel dolayısıyla da kavramsal, soyut ve son derece karmaşık uğraşlardır. Yazılım geliştirmenin bir sanat olduğunu iddia edenler, onun deterministic olmayan, yani başından, sonunun öngörülemeyeceği gerçeğini öne çıkarırlar. Bence de programlama, bilim ile sanatın iç içe geçtiği alanlardandır.

Mahiyeti itibariyle program yazmak ile bir film senaryosu yazmak ya da ne bileyim beste yapmak çok farklı şeyler değil. Yola çıkarken tüm detayını kestirmiş olamazsınız çünkü, ancak nereye gitmek istediğinizi bilirsiniz, hedefiniz vardır ama arasını ancak yolda anlarsınız çünkü kavramsal bir sentezlemeden bahsediyoruz. Programlama bir sanattır, çünkü doğru yoktur, aynı şeyi herkes tamamen farklı şekillerde yapabilir.

Sanatta da programlamada da çoğu kez ortaya koyduğunuz şey hiç bir zaman bir seferde mükemmel olmaz, muhtemelen pek çok yazarın, bestecinin eserlerine son halini vermeden, üzerinde senelerce çalıştıkları gibi yazdığımız programların da üzerinden tekrar tekrar geçmemiz gerekir. (Biz buna refactoring diyoruz.) Ve her bir üzerinden tekrar geçiş eserimizi daha mükemmel kılar ve bize muthiş bir haz verir. Hangimiz şöyle bir şey yaşamamıştır: Daha önce defalarca baktığınız, gördüğünüz kodunuzun öyle bir yönünü farkedersiniz ki, çok ufak bir değişiklikle örneğin müthiş bir kısaltma, hızlandırma yaparsınız ya da o ana kadar gözünüze çarpmamış bir hatasını giderirsiniz. İşte bu yaratıcılıktır, öngörülemezliktir ve böyle bir tecrübe sizin egonuzu tavan yaptırır. Belki de bu sanat ruhudur programcıları, diğer insanlar gözünde “farklı” kılan. Belki de bizi bilim adamlarından ayıran, “benimkisi daha güzel” düşüncesinin çok yaygın olmasıdır. Belki de başkalarının “ne anlıyorsun bundan” diye sorduğu durumda, o garip ifadelere bakarak sanki bir Mevlevi ayinindeymişcesine haz almaktır programlama.

Ben bu satırları yazarken Knuth’ın The Art of Computer Programming serisinin ilk cildini indirdim Internet’ten ve önsözünü okumaya başladım. Bakın ne diyor üstad:

“The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music.”

Yani

“Dijital bir bilgisayar için program hazırlama süreci çok çekicidir, (bu durum) bunun sadece ekonomik ve bilimsel olarak mükafatlandırıcı/faydalı olmasından dolayı değil, aynı zamanda bir şiir yazmak ya da müzik bestelemek gibi estetik bir tecrübe olmasından dolayıdır.”

(Bu arada bu kitabı okuyanların CVlerini Bill Gates’e gönderebilirler, çünkü kendisi bu kitabı okuyabilenlerin nasıl bir tip olabileceğini biliyor 🙂 Kaynak, Wikipedia.)

Yazılım projesi de programlama da bir sanat eseri gibi yolda nelerin gündeme geleceğini ve nihayetinde detayda neyin ortaya çıkacağını çok da bilmeden girişilen bir çalışmadır. Bilimin prensipleri vardır, halbuki sanat daha çok çalışmayla ortaya çıkar, defalarca denersiniz. Bilim sizi sınırlar, sanat ise ancak serbest kılar. Bilim var olanı açıklar, sanat ise sentezler, yeni şeyler ortaya koyar, bu anlamda bilim bulur ama sanat yaratır.

Yaptığımız işin sanatsal tarafı olduğu kesin, tamamen sanat olmadığının kesin olduğu gibi. Bilimsel tarafı olduğu da kesin, tamamen bilim olmadığı gibi. Ama aslolan, nasıl olması gerektiği. Code Complete’in yazarı Steve McConnell da bu konuyu düşünenlerden. Buradan ulaşabileceğiniz yazısında “Yazılım Mühendisliği ne olmalıdır?” sorusunun daha doğru olduğunu ifade eder ve bu soruya “mühendislik” olarak cevap verir. YMnin örneğin iş analizi son derece subjektif dolayısıyla yaratıcılığa el veren, sanatsal öğeler içerebilir, programlama kısmı gibi. Ama belli ki bu tür pek çok farklı çalışmayı bir süreç halinde ve tekrar edilebilir olarak formüle edebilmek, onu mühendislik disiplini haline getirebilmekle mümkün olabilir. Gittikçe daha hızlandırmak, daha verimli hale getirmek örneğin ve çıktı kalitesini arttırmak, böyle bir mühendislik disiplinin amacı olabilir. Böylelikle bilimsel YM süreçleri ve metotları oluşur ve bunları uygulayanlar iyi yazılım ürünleri üretirler.

Aslında McConnell’in Code Complete isimli kitabının 2. bölümünde de belirttiği gibi, yazılımda da diğer pek çok şeyde olduğu gibi metaforlar kullanırız. Bu metaforlar konuyu anlamamızı kolaylaştıran benzetmelerdir. Ve bu metaforların hiç birisi kendi başına doğru değildir. Örneğin, projelerin sonunda, canlıya geçiş sırasında çalışanların kendilerini “itfaiyeci” gibi hissetmeleri, yaptığımız işin tamamını resmetmez.

Söyle diyor McConnell:

“A confusing abundance of metaphors has grown up around software development. David Gries says writing software is a science (1981). Donald Knuth says it’s an art (1998). Watts Humphrey says it’s a process (1989). P. J. Plauger and Kent Beck say it’s like driving a car, although they draw nearly opposite conclusions (Plauger 1993, Beck 2000). Alistair Cockburn says it’s a game (2002). Eric Raymond says it’s like a bazaar (2000). Andy Hunt and Dave Thomas say it’s like gardening. Paul Heckel says it’s like filming Snow White and the Seven Dwarfs (1994). Fred Brooks says that it’s like farming, hunting werewolves, or drowning with dinosaurs in a tar pit (1995). Which are the best metaphors?”

Yani

“Yazılım geliştirme etrafında şaşırtıcı sayıda metafor türemiştir. David Gries’e göre yazılım yazmak bir bilimdir (1981). Donald Knuth ise o bir sanattır der (1998). Watts Humphrey, o bir süreçtir der (1989). P. J. Plauger ve Kent Beck ise onun bir araba sürmek gibi olduğunu söylerler, ama buna rağmen tamamen zıt sonuçlara ulaşırlar (Plauger 1993, Beck 2000). Alistair Cockburn ise o bir oyundur der (2002). Eric Raymond ise onun bir pazar yeri olduğunu söyler (2000). Andy Hunt ve Dave Thomas ise o bir bahçıvanlıktır der. Paul Heckel ise o bir “Pamuk Prenses ve Yedi Cüceler” (Snow White and the Seven Dwarfs) (1994) filmini çekmek gibidir der. Fred Brooks ise o, kurtları avlayan ya da dinazorları bir tuzakta boğan çiftçilik gibidir der (1995). Sizin en iyi metaforunuz hangisi? ”

İşte size bir kaç tartışma daha: SD Times, Jason Gorman, CodeSqueeze, Research Gate’de iki tane, 1 ve 2 ve Jonah Kagan.

Eskiler “barika-i hakikat müsademe-i efkardan çıkar” demişler, neticede kimsenin aksi fikir belirtmediği yerde hiç kimse zaten düşünmüyor demektir. Neticede düşünmek, yazarak paylaşmak ve eleştirilmek hem cesurca hem de güzel bir şey. 

Toplam görüntülenme sayısı: 1891

İstek mi İhtiyaç mı Yoksa Problem mi? – II

İş ve İhtiyaç Analizi, Yazılım Mühendisliği

Aynı başlıklı ilk yazıda istek ile ihtiyaç arasındaki ayırımdan bahsetmiş ve yazılımların başarısı açısından istekler yerine ihtiyaçlara yönelmenin gerekliliğini vurgulamıştık. Bu yazıda ihtiyaç kavramına biraz daha odaklanacağız ve “kapsam”ı ele alacağız.

İşin açıkçası ihtiyaçlara odaklanmak da projelerin başarısını garanti etmez ya da kullanıcılarını memnun etmez. Çünkü ihtiyaç, üzerine biraz daha düşünülmesi gereken bir kavramdır. Örneğin ihtiyaç noktasında sorulması gereken bazı sorular vardır. Bu sorulardan ilki, ihtiyacın gerçek olsa bile projenin kapsamında (scope) olup olmadığıdır. İsteklerinin üzerine düşünmeden onları ihtiyaç diye proje ekibine kabul ettirmeğe çalışmakla, aslında kapsam dışı olması gereken ihtiyaçları kapsama sokmak için proje ekibini ikna etmek arasında, projeyi riske sokmak açısından hiç bir fark yoktur.

Proje tanımından, bir projenin kapsamının ve hedeflerinin belli olması gerektiğini biliyoruz. Kapsam yönetimi, proje yönetim metodolojilerinin üzerinde önemle durduğu konulardandır. Proje kapsamından kasıt ise ihtiyaçlar açısından neyin projede ele alınacağı neyin ise proje dışında bırakılacağıdır. Kapsam, projenin sınırlarını belirler. Kapsamın önce belirlenmesi ve sonrasında kontrol edilmesi, yeni isteklerin ve değişikliklerin kapsamın içine girip girmediğine karar verilmesi, giriyorsa önceliklendirilmesi ve maliyetlendirilmesi, bu bağlamda yapılması gereken en temel çalışmalardandır. Bu noktada ihtiyaçlarını belirlerken sistemin kullanıcılarına düşen en temel şey ise ihtiyaçları arasında önce kapsam açısından bir öngörüde bulunmaları sonra da kapsam içinde olduğunu düşünüyorlarsa ihtiyacı önceliklendirmeleridir.

Gerek dünyada yazılım projelerinin başarısızlık sebepleri üzerine yapılan araştırmalar gerek ise benim ülkemizdeki yazılım projelerinden edindiğim tecrübeler, kapsamı düzgün yönetilmeyen projelerin bir süre sonra batağa saplandığını gösteriyor. Kapsam problemi, eğer proje iç BT birimi tarafından yapılıyorsa, yapılan işi proje tanımından çıkaracak noktaya kadar gidebiliyor. Bu durumda zaten hiç bitmeyen projeler ortaya çıkıyor. Yok proje eğer bir dış kuruma yaptırılıyorsa, bu durumda kurumlar arası özellikle finansal menfaatler söz konusu olduğundan, işler daha da sarpa sarabiliyor. Bu ikinci tip durumlarda projelerin ezici çoğunluğunun sabit maliyetle anlaşıldığı gerçeği de göz önüne alınırsa, durumun ne kadar riskli olduğu anlaşılır. Buradaki tek risk proje ekibinin riski değildir aslında. Yani, maliyet sabit tutulurken kapsamın genişlemesi sadece proje için o sabit maliyetin altına imza atan ekip sıkıntıya girmeyecektir. Projenin sahibi olan kurum da, ayırdığı kaynakları boşa sarfetmiş olma ve sonuçta motivasyonel açıdan son derece sıkıntılı bir duruma düşme gibi tehlikelerle karşı karşıya kalacaktır.

Peki bir ihtiyacın kapsam dahilinde olup olmadığına nasıl karar verilir? Aslında bu çok daha teknik bir soru olup farklı teknikler ve yaklaşımlarla halledilebilecek niteliktedir. Tabi olarak projenin stratejisi, iş hedefleri, paydaşların projeden beklentileri, elde etmek istedikleri fonksiyonellik vb. girdiler, projenin kapsamını oluştururken kullanılacak en temel ihtiyaçlardır. Projenin kapsamını belirlerken zaman zaman nelerin içinde olmadığını belirtmek de kafa karışıklıklarını gidermek açısından önemlidir. Kapsam belirlemede en temel problemler, paydaşların gerçekçi olmayan kapsam istekleri, birbiriyle çelişen ihtiyaçlar ve kapsam dahilindeki ihtiyaçların önceliklendirilmesi konusudur.

Paydaşların gerçekçi olmayan isteklere sahip olmalarının en temel sebebi, yöneticilerin sık rastlandığı üzere “ne isterseniz isteyin, yaptırın” tavrı kadar her şeyi “acil” ya da “blocker” statüsünde gören dolayısıyla ihtiyaçlarıyla ilgili herhangi bir önceliklendirme alışkanlığı olmayan kullanıcılardır. Oyuncaklarını paylaşmayan çocuk psikolojisiyle yazılım projelerine girdi sağlanamaz. Ayrıca projelerin pek çok farklı tipte kullanıcıları olduğu gerçeği göz önüne alındığında, her kullanıcı tipinin bu şekilde davranması durumunda projenin çok ciddi riske gireceği aşikardır. Bu tipten önceliklendirme problemlerini çözmek için “Project Champion” rolü ya da Scrum’daki “Product Owner” aslında biçilmiş bir kaftandır. Büyük yazılım projelerinde yukarıdaki bahsettiğim rollerde birden fazla kişi bulunabilir ve belki bu durumda bu rollerin en tepesindeki örneğin “Chief Product Owner” rolü bu noktada karar verici olabilir. Bu iki rolün yer almadığı projelerde iki taraftan yönetsel sorumluluklara sahip kişilerin bir araya gelip, projeyle ilgili karşılıklı özveride bulunarak, projenin yapılabilirliğini ve yetişebilirliğini garanti altına almaları çok sık karşılaştığımız durumlardandır. Burada aslolan, böyle bir noktaya gelmeden projedeki tarafların makul ölçülerde önceliklendirme yaparak anlaşma yoluna gitmeleri ve kapsamı bir kriz durumuna getirmenin sebep olduğu zaman, iş ve motivasyon kaybını önlemeleridir.

Yazılım mühendisliği literatürüne kapsamın yavaş yavaş büyümesi ve bu şekilde kontrolden çıkmasına “scope creep” denir. Bu durumla ilgili son derece komik ve bir o kadar da gerçekçi karikatürler mevcuttur:


Konuyla ilgisi açısından belki şu yazıma da bakabilirsiniz.

Buraya kadar ilk yazı dahil geldiğimiz noktayı şöyle özetleyebiliriz. Yazılım ihtiyaç analizi, adı üzerinde ihtiyaçlar üzerinden ilerler, istekler üzerinden değil. İsteklerini ifade eden kullanıcıların ve diğer paydaşların, bu isteklerin sistemin stratejik hedefleri, müşteri memnuniyeti, paydaş olarak kendi ihtiyaçları vb. girdilerle projenin kapsamını, proje ekibinin de yardımıyla, makul ölçülerde tutmalı ve daima genişleme eğiliminde olan kapsamın projenin başarısızlığına sebep olmasının önüne geçmelidirler.

Bir sonraki yazımızda kapsam dahilindeki ihtiyaçların önceliklendirmesini ele alalım.

Toplam görüntülenme sayısı: 1584

Eğitim şart mı? BT’de Mesleki Eğitim Üzerine

BT, Kültür, Bilgi ve Düşünce ,

Mesleki eğitim (professional/vocational training), kurumların sadece İnsan Kaynakları bölümlerinin değil aynı zamanda eğitim alacak kişilerin çalıştığı bölümlerin de sorumluluk alanına giren ve verimli bir şekilde halli hiç de sanıldığı kadar kolay olmayan bir iştir. Bu yazıda verimli bir mesleki eğitimin sahip olması gereken niteliklerinden ve uzunca bir süredir içinde bulunduğum, ülkemizdeki kurumsal Bilişim Teknolojileri (BT) eğitim sektöründen bahsetmek istiyorum.

Her ne kadar İngilizce’deki “education” ve “training” kelimeleri dilimize aynı sözcükle, “eğitim” olarak çevrilse de, aslında ikisi az-çok farklı kavramlardır. Bu konudaki yayınlarda, bu iki kavrama bir de “farkındalık” (awareness) eklenir ve bu üç kavram ile aslında birbirlerini takip eden ama gittikçe daha geniş ve karmaşık hale gelen zihni süreçler ifade edilir. Bu şekilde bir yaklaşımla başladığımızda, farkındalık, kişinin dikkatini çekme, bir olayın, problemin varlığından haberdar etme gibi anlamlar taşır. “Training” ise daha çok, kişiye belli bir işi yapacak şekilde yetkinlik kazandırma ya da onu bir konuda daha verimli hale getirme, olarak tanımlanabilir. “Education” anlamında eğitim ile daha tabi ve zaman yayılmış ve daha karmaşık süreçler kastedilir. Bu anlamda eğitim, kişiye sadece teknik yetkinlik kazandırmaz, o konudaki yaygın bilgi birikimini (body of knowledge) sunar ve eğitimi alan bireyi, konunun sosyal, kişisel vs. boyutları hakkında düşünmeye sevkeder. Karışıklığın önüne geçmek için mesleki eğitim olarak çevrilebilecek olan “training” ya da “professional/vocational training”, çerçevesi çok daha dar olarak belirlenmiş bir konuda, kişilere hızlıca teknik problem çözme kabiliyeti kazandırmayı hedefler. Buna karşılık eğitim ise kişiyi düşünmeye sevkeder ve düşünme için malzemeler sunar. Bu anlamda eğitim, daha çok bir gelişme/geliştirme yani olgunlaşma/olgunlaştırma sürecidir ve bu yüzden de evrimseldir. Dolayısıyla mesleki eğitim daha çok pratik ve uygulamalı olurken, eğitim, hem teorik bilgiyi hem de pratik uygulama becerisini kazandırmayı hedefler. Bu iki kavram arasındaki farkı sanırım en iyi anlatan, Tony Bray’ın “The Training Design Manual” isimli kitabının 35. sayfasında verdiği örnektir. Yazar, kendimizi henüz orta öğretime devam eden bir çocuk sahibi ebeveyn olarak düşünmemizi istiyor ve şu soruyu soruyor: Çocuğunuzun okulda cinsel konularla alakalı “education” mı yoksa “training” mi almasını isterdiniz? Çocuğunuza cinsel “education” yerine cinsel “training” verilmesi durumunda çok farklı tepki vereceğinizi söylüyor yazar. Bu güzel örnek aradaki farkı tamamen açıklıyor.

Biz bu ayrımdan sonra mesleki eğitime odaklanalım ve yazının kalanında eğitim deyince “training”i kastettiğimizi ifade edelim.

Eğitim, kurumlar açısından çok merkezi bir kavram tabiki. İster organizasyon teorileri ve örneğin Öğrenen Organizasyon (Learning Organization) açısından bakın ister Toplam Kalite Yönetimi, TKY (Total Quality Management, TQM) gibi daha sistemli bir noktadan bakın, isterseniz çok daha pratik açıdan bakıp, daha verimli ve üretken çalışanlara sahip olmayı isteyin ya da yeni bir teknolojie geçişten dolayı tamamen zorunluluk olarak görün, eğitim çok önemli. Biz bu gibi durumlarda, genelde gülümseyerek “eğitim şart” deriz; çünkü bu cümle en önemli sloganlarımızdandır.

Uzunca bir süredir BT eğitimleri ile ilgilendiğim ve ciddi miktarda Java ve Yazılım Mühendisliği’nin değişik konularında eğitimler ve eğitim ile ilgili danışmanlıklar verdiğim için (ve dahi ilköğretimde, lisede ve üniversitede, yurt içinde ve dışında eğitim alan çocukların babası da olduğum için, yani eğitime tonla para harcadığım için 🙂 gerek “education” gerek ise) “training” anlamında eğitimin pek çok farklı açısıyla ilgileniyorum.

Kurumlar çalışanlarını eğitirler ya da dış eğitim kurumlarından eğitim aldırırlar. Bunu hangi amaçlarla yaparlar? En genelde, şu ya da bu çapta, ama bir şekilde bir “değişim” ihtiyacına cevap olarak eğitim gündeme gelir. En azından değişimle, çalışanın yetkinliklerinde bir değişim hedeflenir. Peki nedir yetkinlik (competence)? Yetkinliğin ne olduğu ile ilgili detay tartışmalara girmeden, konumuz açısından son derece faydalı olan bir tanımından yola çıkarak, teknik eğitimlerin, yetkinlik geliştirmedeki rolüne odaklanabiliriz.

Yetkinlik, kişinin bir konudaki, bilgi, beceri ve davranış ve tutumlarının tamamına verilen isimdir. Yani bir konuda yetkin olmak ya da yetkinlik sahibi olmak, o konuda gerekli teorik bilgiyi bilmek, o konun gerektirdiği yapabilime becerilerine sahip olmak ve bu beceriyi, ihtiyaç olan her noktada yapıcı bir şekilde kullanabilmektir. İngilizce’de knowledge, skill ve attitude/behavior olarak ifade edilir ve genelde KSA olarak kısaltılır. Bu tanım, sosyal ya da psikolojik açıdan çok yeterli olmayabilir, yani örneğin “aşk” konusuna uygulamada çok aydınlatıcı olmayabilir ama bizlerin de içinde bulunduğu teknik konularda güzel bir modeldir. Bilgi/beceri/davranış yani BBD’den oluşan yetkinlik kavramını bir örnekle açıklayalım: Diyelim ki çocuğunuza ya da yeğeninize diş firçalamayı öğretmek istiyorsunuz. Aslında derdiniz sadece “öğretmek” değil, derdiniz, ona bu konuda yetkinlik kazandırmak yani onu diş fırçalamada yetkin hale getirmektir. Nasıl yaparsınız bunu? Öncelikle onunla konuşarak, diş fırçalamanın gerekliliğini ve bu konudaki en temel bilgileri verirsiniz ki bu yetkinliğin “bilgi” kısmına karşılık gelir. Yeterli midir? Tabi ki hayır, çünkü eğittiğiniz kişiye bu konuda bir beceri de kazandırmanız lazımdır. Bunun için onunla birlikte banyoya gider ve ona diş fırçalamada, hem kendiniz yaparak hem de onun yapmasını sağlayarak, bir beceri sağlarsınız. Macunu nasıl sıkacağını, fırçayı dişleri üzerinde nasıl hareket ettireceğini ve sonunda ağzını nasıl çalkalayıp temizleyeceğini hem siz yaparsınız hem de onun bir kere yapmasını sağlarsınız. Dişini bir kere hatasız fırçalayabilen çocuk, bu konudaki gerekli beceriyi de kazanmış demektir. Yeter mi sizce? Yetmez tabi ki. Çünkü önemli olan şey, nihayetinde çocuğun bu beceriyi, hayatına yayması, onu bir alışkanlık haline getirmesi, mesela yatmadan önce ya da yemeklerden sonra dişlerini fırçalamasıdır. Yani, bu beceriyi sürekli bir davranış olarak hayatına yayması ve bunu yaparken de olumlu bir tutum takınmasını beklersiniz. Yani çocuk, dişlerini isteyerek fırçalamalı, bunu temiz bir insan olmanın bir parçası olarak algılamalı vs. Bu da yetkinliğin tutum, motivasyon vb. boyutunu oluşturur.

Şimdi de isterseniz BBD anlamındaki yetkinliği, örneğin bir programcının birim testi (unit test) yetkinliği açısından açıklayalım. Programcıya, daha kaliteli kod yazabilmesinin birim testi yapmaktan nasıl geçtiğinin açıklanması ve programcının bu konuda ikna edilmesi, kullanılan teknolojiye göre birim testinin bileşenlerinin varsa araçlarının, test kodunun yazımının, etiketlerinin (tag) ve örneğin konfigürasyonun, derleme ve çalışma zamanlarının, yani tüm sürecin bileşenleriyle sistematik olarak açıklanması, bilgilendirme sürecini oluşturur. Bu sırada eğer bu yetkinlik teknik bir eğitimle kazandırılıyorsa, eğitmen, muhtemelen “Selam” gibi basit bir kod parçasından başlayarak birkaç farklı karmaşıklıktaki kod için kendi örneklerini çalıştırır ve benzer şekilde sınıftaki katılımcıların da bunu yapmalarını ister. Bu örneklerle katılımcılar yetkinliğin bilgi kısmını halledip yavaş yavaş beceri kısmına doğru ilerlerler. Sonrasında eğitmen, örneklere benzer uygulamaları, katılımcıların kendilerinin yapmasını ister. Yetkinliğin karmaşıklık seviyesine göre bu, bazen sınıfça, eğitmenin önderliğinde yapılır ve katılımcılar önce taklit ederler ve sonrasında kendileri, eğitmeni takip etmeden kendi uygulamalarını gerçekleştirirler. Böylece her katılımcı birim testi için gerekli beceriyi en az bir defa sınfta göstermiş olur. Peki, bir programcının kaliteli kod yazabilmesi için yeterli midir bu yetkinlik? Kesinlike hayır. Programcı, her yazdığı kod için birim testini uygulamalı, bu konuda yapıcı bir tutum geliştirmeli, mesela etrafına da yaymalı vs. ki bu konuda bir davranış ve alışkanlık geliştirmiş olsun.

Şimdi soru şu: Yetkinlik kazandırmak amacıyla çalışanlarımıza aldırdığımız eğitimden ne bekliyoruz? Yani bir eğitimden, örneğin, başka bir programlama dilinde tecrübeli programcıları, Java ile nesne-merkezli programlama yetkinliklerini kazandırmak amacıyla göndereceğimiz bir eğitimden, yukarıda detaylandırdığımız BBD anlamında ne bekliyoruz? Benim acizane cevabım şu: Hiç bir fikrimiz yok 🙁 Bu güne kadar, BT eğitimlerinde ne İK bölümlerinin ne de teknik bölümlerin, böyle bir eğitimden ne beklediklerini analitik ve rasyonel bir çerçevede açıklayabildiklerine malesef şahit olamadım. Genelde IK birimlerinin de olduğu eğitim ihtiyaç analizi toplantılarında, yukarıdaki BBD cinsinden açıklamayı ben yapıyorum 🙂 Bırakın yatırımın geri dönüşü (ROI) gibi teknik ve çok daha karmaşık ölçümleri, eğitimden gelen kişiden, eğitim sonrasında ne isteyebileceğimizi, istediğimiz şeyi ne kadar sürede ve ne kalitede yapacağını bile tahmin etmekten çok uzakız. Komik ama gerçek bu 🙂 Bir kurum, çalışanlarını eğitime gönderir de, eğitimden döndüklerinde ne durumda olacaklarını bilmez mi? Örneğin 5 günlük bir “Java’ya Giriş” isimli eğitimden sonra BBD anlamında bir programcının ne durumda olacağını bilmez mi? Bilmiyorsa, en azından bilene, mesela bana sormaz mı? Ya da sormadan anlattığımda ona göre davranmaz mı? Cevap, hiçbirini yapmaz. Sonra da “Eğitim Şart”ı dilimize pelesenk yaparız. Gıcığım ben bu slogana zaten. Sadece slogan cünkü, içi boş, lafı güzaf malesef. Neden böyle diyorum? Çünkü, ister kelli felli o kurumsal (!) BT kurumlarının ya da devasa BT bölümlerinin olsun ister ufak yazılım evlerinin olsun, eğitim ihtiyaçlarında hep aynı sıkıntıyı çekiyorum. Bir örnekle açıklayayım ama sıkı durun: Cok sık bir şekilde örneğin Cobol ya da Oracle Forms gibi yapılarla senelerini harcamış, bazen benden daha yaşlı programcılara 3 ya da 4 günde Java ile nesne-merkezli programlama öğretmem bekleniyor 🙂 Yani, Java’nın nasıl tanım tabanlı (specification-based) ve açık yapıda bir dil olduğundan başlayarak (ki burası çok önemlidir çünkü Java kültürünün çok temel bir parçasıdır ve genelde farklı programlama kültüründen gelenlerin anlamakta zorlandıkları ve bu yüzden de “Hangi Java’yı öğreteceksiniz” şeklinde sorular sordukları bir alandır bu), söz dizimi ve anahtar kelimelerini, kontrol yapılarını ve sonra gelen, pek çok programlama kültürüne göre Java’nın en ayırt edici yönünün ele alındığı sınıf ve nesne yapıları, sonrasında kalıtım, çok şekillilik, soyut yapılar ve arayüzler ve sonrasında sıra dışı durumlar ile temel Java yapılarının halledilip, üzerine torbalar, giriş-çıkış, kanallar ve JDBC’nin ele alınması ve bu konularda bir yetkinlik oluşturmak için 3 olmadı 4 gün, nasıl? 🙂 Ve bu konuları gören katılımcıların, bir projede yer almaları, kendilerine verilen programlama görevlerini yerine getirmeleri yani “yetkin” olmaları bekleniyor. Sonra da herkes birbirine soruyor, proje neden gecikti? Ya da Java’nın adı çıkıyor, “Java çok zor” ya da “Java’da kod geliştirmek çok yavaş” 🙂 Şaka gibi…

Peki, yukarıdaki konuları kapsayan bir eğitim, ne kadar sürede nasıl bir yetkinlik kazandırabilir? Bu konularla ilgili gerekli bilgi için rahatlıkla 5 güne ihtiyaç vardır. Eğer eğitimde bilgiden beceriye de geçmek istiyorsak ki tabi olan budur, katılımcıların, eğitmenin bilgilendirirken verdiği örneklere benzer örnekleri yapmaları gereklidir ve bu durumda böyle bir eğitim rahatlıkla 10 güne çıkar. Burada dikkat çekilmesi gereken şey, böyle bir eğitimde beceriyi her konuda kazanmanın mümkün olmadığıdır. Sınıfta katılımcıların ne kadar kendi uygulamalarını yapabileceklerini belrileyen en temel şeylerden birisi, sınıfın mevcududur örneğin. Katılımcıların hangi konularda kendi uygulamalarını yapacakları, hangi konularda eğitmenin örnekleriyle yetinip, örneğin eğitim sonrası kendi gayretleriyle beceri kazanmaya yönelik olarak kendi uygulamalarını yapacaklarını belirlemek çok önemlidir.  Ama kesin olan şey şudur ki, 10 günlük böyle bir eğitimde bile katılımcılar, eğitmenin örneklerinin çok iyimser bir tahminle, yaklaşık 3’te birinde kendi uygulamalarını yapabilmektedirler. Burada şunu atlamamalıyız: İster bilgi tarafı ister beceri tarafı olsun, aslolan anlamadır, yani katılımcının anlamasıdır ve katılımcının örnek uygulamayı yapmış olması bile onun konunun her yönünü anladığını göstermez, çünkü burada “training” anlamında bir eğitimden bahsediyoruz. Yani örneğin neden “Java’da mesela kanal yapısı böyle kurgulanmış da .NET’deki gibi şöyle kurgulanmamış” sorusu nefis bir tartışma konusu olmakla birlikte, “training” anlamında bir eğitimin konusu olamaz. Bu olsa olsa, Programlama Dilleri isimli bir master dersinin konusu olabilir ki bu da zaten “education” anlamında bir eğitimle halledilir.

Davranışa gelirsek, sınıf içi eğitimle, yetkinliğin, davranış kısmını kazandırmanın mümkün olmadığını ifade etmek gerekir. Yani sınıf içi eğitim, davranış kazandırmaz, bu çok açık. Peki davranış, tutum nasıl kazandırılır? Tabi ki eğitimin bir parçası olarak ama sınıf eğitiminden sonra yapılacak bir workshop ile davranış kazandırmaya başlarsınız. Yani alınan eğitime uygun içerikte, örneğin 5 günlük bir sürede yapılacak küçük bir proje çalışması ile katılımcılar, bilgilerini kullanma imkanı bulurlar, becerilerini geliştirirler, eksik kalan becerileri tamamlarlar ve davranış olarak da, özellikle eğitmenin liderliğinde, gerek taklit gerek ise tartışma yoluyla davranış geliştirmeye başlarlar, becerilerini her durumda ve hızlıca nasıl yerine getireceklerini öğrenirler. Bu tipik usta-çıraklık ilişkisidir. Ve teknik yetkinlikler ancak ve ancak bu şekilde elde edilirler. Usta-çırak ilişkisine girebilmek için gerekli altyapı ise sınıf eğitimiyle verilir. Bu anlamda sınıf eğitimi bilgi-beceri yoğun, workshop ise beceri-davranış yoğun yapılardır.

Eğitim ile ilgili kitaplarda otoriteler, eğitim hayat döngüsünden bahsederken workshopı da muhakkak dahil ederler. Bunun sebebi de sınıf eğitimiyle, bilgi ve bir miktar beceriye elde edilen kişilerden, projelerin gerektirdiği davranışı göstermeyi beklemenin haksızlık ve yanlış olduğu gerçeğidir. Ülkemizde workshop alışkanlığı çok ama çok azdır. Ben çok az müşterime bunu kabul ettirebiliyorum. Çoğu zaman yukarıda bahsettiğim 10 günlük eğitimi bile 3-4 güne sığdırmam istendiğinden, tabi olarak ben de 10 gün eğitim ve üzerine 5 gün workshop, dolayısıyla 15 gün diyemiyorum. 200 bin TL’lik bir mala birisinin 10 bin veririm demesi gibi bir durum bu 🙂  Workshopı yapmamak için en sık söylenen sebep, “zaman yok”tur. Halbuki projenin gecikmesinin en temel sebeplerindendir yetkinlik eksiği. Bir diğer argüman da, “katılımcılar zaten eğitimden sonra projeye girecekler ve orada kod yazacaklar”dır. Bu da farkedileceği gibi, workshopın ne anlama geldiğini anlamamaktan kaynaklanan bir argümandır. Workshopta yazılan kod, gerçek kod değildir ama projede yazılan kod gerçek koddur. Yani söylenen şey, tatbikat yapmadan askerlerin doğrudan savaşa girip gerçek mermileri kullanmaları ya da Tıp öğrencilerinin, ameliyat yapan hocalarını izlemeden doğrudan ameliyata girmesidir. Sonra neden hasta öldü demenin bir anlamı yok bence 🙂

Teknik eğitimin, ülkemizdeki yapıldığı haliyle, ciddi problemleri var. Örneğin eğitmen kirliliği, içerik kirliliği, bir ihtiyaç analizi yapmadan eğitim satan ya da alan kurumlar, eğitimi mala indirgeyen dershane mantığındaki eğitim kurumları vs. Bunlara daha sonra değiniriz.

Ama şu bir gerçek: Eğitim şart 🙂

 

Toplam görüntülenme sayısı: 1121

1 2