Search Results for: olaylar

Çeviklik, Scrum ve Biz

Yazılım Mühendisliği

Çok komik. 🙂 Zaman zaman duyuyorum, IT yöneticilerinin “biz çevik sürece geçtik” ya da “artık çevik süreçler kullanıyoruz” gibisinden cümlelerini. Hemen şunu soruyorum ya da içimden geçiriyorum: “Daha önce neyi kullanıyordunuz ki???” 🙂 Öyle ya bildiğime göre taa Orta Asya’dan bu yana bizde kervan yolda düzülüyor. Yüzyıllardır zaten çevik hatta aşırı çevikiz. O kadar çok heyecanlıyız ve aklımız heyecanımıza o kadar çok yenik düşüyor ki birisinden bize bir iş yapmasını istediyip de bir süre sonra “düşünüyorum” cevabını alırsak çoğunlukla “düşünme yap” ya da “aptal mısın neyini düşünüyorsun?”  şeklinde laflar ediyoruz. İşin tuhafı, yazılım geliştirme gibi son derece soyut ve aşırı değişken çıktıları olan bir disiplinde de benzer şekilde kervanın yolda düzüldüğünü düşünmemiz. Tabi tüm bunlar birer kültür meselesi. Yazılım geliştiren ya da yöneten kişi, örneğin milli takımmızın Hollanda maçında bir mucize bekliyor. Zaten Çeklere karşı 3-2’lik mucizeyi de biz gerçekleştirmiştik. Olaylara bakışımız, toplumun hangi katmanından gelirsek gelelim aynı açıdan yani, sistematiklik yerine gelişi güzellik, takım yerine tek tek kişilerin kurtarma becerilerine odaklı, uzun vadede bir şeyleri yerleştirip başarmak yerine tamamen random, rastgele, ne zaman olacağı belli olmayan çıkışları beklemek. Yazılımı da bu şekilde ele alıyoruz genelde. Dolayısıyla diyorum ki bize sadece “çeviklik” değil “disiplin” de lazım. Bize “agility” değil “process-orientedness” lazım daha çok, yani kimin ne yapacağının belli olduğu, iyi tanımlandığı yazılım geliştirme süreçleri gerekli diye düşünüyorum.

Ne demek istediğimi bir örnekle anlatmaya çalışayım. 15 yılı aşkın süredir iş yazılımları geliştiren bir şirkete danışmanlık veriyorum. Zamanında bu şirketin yazılım müdürlüğünü de yaptığımdan 15 yılda nereden nereye geldiklerini çok iyi biliyorum. Ben şirketten ayrılırken 45-50 kişilerdi, şimdi ise 150’ye dayandılar sanırım. Sirketi zamanında kurup tırnaklarıyla kazıyarak bu noktaya getiren kişiler uzun süre haklı olarak programcılarının, müşterilerinin sorunlarını çözmekte sıklıkla yetersiz kaldıklarından şikayet eder ve problemi “proaktif olmamak” ya da en azından “inisiyatif almamak, alamamak” çekirdek davranışına indirgerlerdi. Tamamen haklılardı. Çünkü son derece çekirdekteki iş uygulamalarını geliştiren bu kurumun çalışanlarının müşterilerinin problemlerini çözmede “iki eli kanda olsa bile” şeklinde bir davranışa sahip olması, müşteri memnuniyeti açısından son derece önemliydi onlar için. Dolayısıyla “agile” davranarak işe başladılar. Simdi ise büyüdüler, “analist-programcı-proje yöneticisi-tester” düzeninden PMP sertifikasına sahip proje yöneticilerinden oluşan proje yönetim ofisine, yazılım mimari gibi rollere sahip bir development grubuna, 30 civarında analistin olduğu bir analiz grubuna, yeni oluşturulmakta olan ap-ayrı bir tester yapısına ve İK, Finans vb destek birimlerine sahip, ülkemiz standartlarında kocaman bir yazılım evi haline geldiler. Ve geldikleri noktada artık sistematik olmak zorundalar, kaliteye daha fazla önem veriyorlar, çünkü sektörlerinde bu ülkede lider oldukları gibi yurt dışına da açılmaya çalışıyorlar. Ve artık yöneticileri örneğin developerlarının müşteriden gelen bir hata bildirimine balıklama atlamalarını istemiyor. O hatanın kayıtlara geçmesini, gerçek sebebinin bulunmasını, gerekiyorsa analizinin yapılıp, etki ve maliyet gibi bilgilerin ortaya çıkmasını, o anı kurtarmak yerine daha sağlıklı bir çözüm üretilip, bu çözümün gerekiyorsa tüm müşterilerde yaygınlaştırılmasını hatta bir sonraki sürümün parçası olmasını ve en önemlisi de bu bilgilerin ilgili herkes tarafından bilinmesini istiyorlar. Bu yüzden developerin bu döngüye girmeden hatayı kendi başına halletmeye kalkmasının, nihayetinde, hata halledilse bile doğru bir davranış olmadığını, belki müşterisini memnun edeceğini ama şirketi açısından sürdürülemez bir davranış olacağını, yine müşteri odaklı ama daha sistematik bir çözüm döngüsü içinde olmak gerektiğini çalışanlarına anlatmaya çalışıyorlar. Çalışanlarının kariyer planları ve mutlu olmaları üzerine daha fazla kafa patlatıyorlar. Eskiden eğitim harcamaları ancak zorunluluk durumunda ve pek çok kısıtla yapılabilirken şimdi her sene San Francisco’ya JavaOne’a 4-5 çalışanını gönderiyorlar, çalışanlarını elde tutmak ve daha mutlu ve üretken kılmak için “yetenek yönetimi” çalişmaları yapıyorlar.  Çünkü artık çok daha zor bir yönetim problemiyle karşı karşıyalar. Sadece çevik olmak yerine sistematik çeviklik istiyorlar. Bu amaçla analiz olsun tasarım olsun ya da development olsun, nasıl bir sürece sahip olmaları gerektiği üzerine birlikte kafa yoruyoruz. Risk analizi, bütçe çalışmaları, yıllık eğitim planı vb. çalışmalar çok daha önemli hale geldi artık. Hala çevikler ama artık daha çok disiplinli bir çeviklik var.

Ote taraftan çevikliği yukarıda olduğu gibi kelime manasıyla almak yerine bir yönetim felsefesi ya da yazılım geliştirme paradigması olarak ele aldığımızda, yani “agile processes” ya da “çevik süreçleri” düşündüğümüzde, pek tabi olarak yukarıda kastettiğimiz çeviklikten farklı bir noktada durduğumuz aşikardır. Bunu da şöyle açıklayabiliriz: Çevik süreç kavramı bizim ülkemizde çıkmadığı gibi bu paradigma çerçevesinde oluşturulan metodolojilere bir katkımız da henüz olmadı. Çevik süreçlerin temeli, ozellikle ABD’de aşırı yapısal ve bürokratik, bundan dolayı hantal ve müşteriden uzak yazılım organizasyonları ve onların yazılım geliştirmeye yaklaşımlarına bir tepki olarak yayınlanmış Agile Manifesto‘ya dayanır. Tabi olarak bu manifesto bir günde yayınlanmadı. Eskiden bu yana yazılımın başarısızlık ve başarısının neye bağlı olduğu üzerine kafa yoran pek çok akademisyen ve uygulayıcı vardı. Bunların en iyi bilinenleri Barry Boehm ve onun spiral modeli ile Kent Beck’in Extreme Programming’idir. Benzer şekilde Jim Highsmith’in yazılarını, bu konudaki itirazları ve çözüm önerilerini okuduğumu hatırlıyorum. Bu anlamda 90lı yıllarda Unified Process gibi, yazılım projesini bir seferde bir big bang gibi kurmak yerine daha daha müşteri odaklı, mimariyi merkeze koyan ve riski önceleyen metodolojiler konuşulmaktaydı. Agile Manifesto da bu dünyanın babaları tarafından, ağır süreçler yerine insanları ve iletişimi, hantal ve okunmayan dokümanlar yerine yinelemeli ve artımlı (iterative, incremental) olarak geliştirilen, her an çalışır halde tutulan ve müşteri tarafından test edilebilen kod yapısını, müşteride analiz yapıp, “2 sene sonra kullanıcı kabul testinde görüşelim” diyen anlayış yerine, müşteriyle yakın ilişki içinde olan, onu da elini taşın altına koymanın en temel risk yönetimi olduğunu düşünen bir paradigmayı, proje planını kutsamak yerine değişimi nasıl yöneteceğini düşünen bir felsefeyi dünyaya duyurdu. Çok da iyi oldu, özellikle de bizim için. Neden? Çünkü bizim zaten genlerimizden, kültürümüzden, alışkanlıklarımızdan ve aşırı faydacı ve anlık yapımızdan dolayı çok daha uzunca bir müddet o hantal ve aşırı bürokratik yazılım geliştirme metodolojilerini uygulamamız mümkün değildi. Bu yüzden çevik süreçler, bu hantal süreçlere sahip yazılım evlerine dinamizm getiriken bize sistematiklik getirdi. Ne kadar sistematiklik? Tam olması gerektiği kadar bence? Fazlası değil, çünkü fazla sistematiklik bize göre değil. Bu anlamda çevik süreçler, bizim gibi bir kaç bin senedir çevik yaşayanlara disiplin sağlayor, ben de bu yüzden yukarıda “disiplinli çeviklik”i kullandım.

Agile Manifesto’ya imza atanlardan birisi de Jeff Sutherland aynı zamanda Scrum’ın da yaratıcısı. Yukarıda bahsettiğim o hantal yapıdan tamamen haberdar ve ona karşın daha çevik ama gerektiği kadar sistemli bir yazılım geliştirme yönetim metodoloji ortaya koymuş birisi. Scrum ülkemizde de yaygınlaşıyor ve ben buna çok seviniyorum. Bize disiplin getirirken damarlarımızda olan çevikliği ise övüyor ama onu sistematik olarak kullanmamıza imkan sağlıyor.

Bu blogun takipçilerinden olan bir dost ise bana gönderdiği bir emaille, Jeff Sutherland’in 16-17 Ocak 2014 tarihlerinde ülkemizde yapılacak Scrum Master eğitimi için İstanbul’da oalcağını hatırlattı. Scrum Turkey tarafından düzenlenen bu çalışmayla ilgili ayrıntılı bilgiye buradan ulaşabilirsiniz.

İçimizdeki çevikliğe zapt-u rapt vurmanın zamanı geldi de geçiyor bile 🙂

 

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

Genç Yazılımlılar İçin – II: Master yapmak ya da yapmamak.

Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği , , ,

Çok komik… Aslında traji komik… Bakın anlatayım:

Üniversiteli gençlerle hemen her buluşmamda bana sorulan sorulardan birisi de “hocam master yapalım mı?” oluyor. Çocuklarının kafasını daha lisedeyken “doktora yapma” fikriyle yıkamış bir adama sorulacak soru mu bu? Ya da yaşı 40’nı geçmesine rağmen, bir de Felsefe masterı yapsam diye düşünen bir adamın bu soruya cevabı ne olabilir ki? Dolayısıyla bu soruya, “tabi ki yapın” ya da “sadece master değil doktora da yapmalıyız” şeklinde cevaplar veriyorum. Toplumumuzun eğitim seviyesinin yükselmesi, sektörde bilgi birikiminin olması, herşeyden önce bilgi ve bilgi sevgisi kültürünün yaygınlaşması vb. tonla sebepten dolayı master ve doktora yapmanın önemli olduğuna inanıyorum. Tabi ki bu işin bir vechesi. Diğer vechesi ise o kadar da zevkli değil malesef.

Şöyle bir soru sorsam size: Ülkemizdeki BT sektörünün ihtiyacı açısından, ortalama bir BT çalışanının ne kadar eğitime ihtiyacı vardır? Zor soru tabi. Ama cevap kesinlikle “üniversite lisans eğitimi” değil bence.  Ülkemiz BT sektöründe var olan yerleşik yazılım geliştirme kültürü ve pratiği açısından ele alındığında, benim iddiam şudur: Akıllı bir lise mezunu, var olan işlerin ezici çoğunluğunu, makul miktarda iş başı eğitim ve yol gösterme ile başarabilir. Efendim BT sektöründe çalışanlar zaten liselerden gelen en zeki çocuklardanmış, ÖSS’de ilk bilmem kaça girenler bu sektörde çalışıyorlarmış, yok lisedeyken fizik olimpiyatlarına katılmışlarmış ya da yazılım sektörü çok analitik bir zeka istiyormuş, falan filan… Bence hepsi hikaye. Bunun, heyecanlı Bilgisayar Mühendisliği öğrencilerinin canını sıkacak bir iddia olduğunun farkındayım ama bence durum bu kadar vahim. Bence sadece bizim sektörde değil, pek çok mühendislikte durum bu kadar vahim: İnşaat Mühendisliği ve “bina inşa etme” kültürümüzde de durum pek farklı değil. Ya da bakın, ortalık Endüstri Mühendisliği mezunu dolu ama görüyor musunuz süreç tabanlı bir çalışma? Ben görmüyorum…  Kadın, “Endüsti Mühendisliği mezunuyum ve 10 senedir falan bankada iş analisti olarak çalışıyorum” diye tanıtıyor kendini. Soruyorum, “nasıl iş analizi yapıyorsunuz?” diye. Cevap veriyor “işte, müşterimiz iç müşteri oluyor her zaman. Onlardan istek geliyor. Gidip görüşüyorum onlarla, sonra görüşmeden çıkardıklarımdan bir Word dokümanı oluşturuyorum. Ayrıca PowerPoint’de ekran tasarımı yapıyorum.” “Peki” diyorum içimden ve soruyorum kendi kendime: Burada “analiz” nerede?: PowerPoint ile yapılan şeyin analiz olmadığı kesin çünkü zaten adında “tasarım” var. Geriye kalıyor “Word dokümanı”. Oradan birşeyler çıkarmaya çalışıyorum, çünkü kadının anlatımından “Word dokümanına yazılan şey, iş analizidir” ya da “cümleleri, analitik yapan şey, onların bir Word dokümanına yazılmış olmasıdır” (!) şeklinde birşey çıkıyor. Soruyorum,” o Word dokümanındaki temel kısımlar, başlıklar nelerdir?” Ya da “herhangi bir diyagram çiziyor musunuz” diye, ama nafile. Tek derdim, “iş analisti” olarak çalışan Endüstri Mühendisi arkadaşımızın zihninde “iş” ve “analiz” ile ilgili bir kırıntı var mı onu anlamak. Belli ki iş analisti olarak çalışan herkes kendine göre bir “analitik” 🙂 süreç izliyor.Ve Word dokümanına yazılan şeyler bir şekilde “analiz” oluyor ama dokümanda herhangi bir yapısallık bile yok. Peki söyler misiniz bana böyle bir işi akıllı bir lise mezunu niye yapamasın? Bu işin neresinde analitik bir işlem var? Bu işin postacılıktan ya da sekreterlikten ne farkı var? Postacılıktan farkı yok, çünkü analitik bir katma değer olmadan sadece bilgiyi taşıma söz konusu, herhangi bir çözümleme ve dönüştürme yok. Sekreterlikten farkı yok çünkü Word dokümanına geçiriliyor anlatılanlar. Halbuki, işi soyut olarak bir süreç olarak ifade etme, gerçek olaylardan oluşan senaryolarla, bu soyut süreci kurgulama ve doğrulama, iş kurallarını farklı kriterlerle yakalayıp ifade etme, nesne-merkezli bir yaklaşım söz konusuysa bir kavramsal nesne modeli çıkarma vb. yaklaşım ve tekniklerden bahsetmesi gerekirdi. Literatürde ve pratik uygulamada tonla “iş ve ihtiyaç analizi” (business and requirements analysis) yaklaşımı, tekniği, şablonu (patterns), diyagramları (örneğin UML), en iyi uygulamaları (best practices) vs. var. Var mı uygulayan? Olsa, bir Endüstri Mühendisliği disiplininin sağladığı alt yapıya ihtiyaç olurdu. Ve siz de derdiniz ki “bu işi ancak bir Endüsti Mühendisi” yapabilir.

Tonla iş analistine eğitim verdim, bir tanesinin de zihninde “ihtiyaç tipleri” gibi bir ayırım görmedim. Hatta analiz ile tasarım arasındaki farkı bilene bile pek rastlamadım. Her eğitimde ya da danışmanlıkta Karl Wiegers’ın nefis Software Requirements kitaplarını ebook olarak dağıttım, nefis örneklerinden verdim… Çünkü ihtiyacınızı ya da işinizi analitik olarak ele alıp, çözümlemezseniz, ne istediğinizi ya da nasıl iş yaptığınızı tarif edemiyorsunuz demektir. Bunu yapamadığınızda, hangi yazılımı, hangi en ileri teknoloji ile geliştirdiğinizin hiç bir önemi yoktur. Yazılım projelerinde, ne yapacağınızı bilmediğinizde, ne kadar adam-gün, ne zaman, ne kadar maliyet vb. hiçbir soruya yanılma payıyla bile olsa cevap veremezsiniz. Ne proje planı yapabilirseniz ne de test. Yaparsanız, sadece “yaptım oldu” olur. “Dostlar sizi PMP’lerinizle proje planı yaparken görsün”den öteye gidemezsiniz. İşimizi ve ihtiyacımızı tarif etmeyi bu şekilde algıladığımzıda ne master yapmış bir Endüstri Mühendisi’nin katma değer sağlaması mümkündür ne de bu duruma master sahibi olmak tercih sebebidir.

Aynı durum, yazılım geliştiren programcılar için de geçerli. Tonla Bilgisayar, Endüstri, Matematik vb. mühendisin çalıştığı bir yazılım geliştirme ortamında en temel kavram “ekran” nasıl olur? “Ekran aşağı, ekran yukarı”. Her şey sadece ve sadece ekran ile anlatılıyor. O yukarıda bahsettiğim ünlü Word dokumanını, tamamen ekran tasarımı ve üzerindeki arayüz elemanlarının özelliklerini yazarak oluşturan ve buna “iş analizi” diyen iş analistleri de gördüm bu ülkede ben. Herşeyin ekran üzerinden anlatıldığı bir yerde “iş” ve “analiz” nerede Allah aşkına? En önemli soyutlamanın “ekran” olduğu bir iş ortamının anlamlı olması için orasının, CRT ya da LCD ekran geliştiren bir elektronik vb. bir AR-GE birimi olması gerekmez mi? 🙂 Yazılım gibi tamamen süreç odaklı bir işi, “ekran” kavramı etrafında kurgulamamız için ne kadar eğitim almamız gerekiyor? Bunun için ne kadar Matematik, ne kadar differantial equations, ne kadar operating systems, ne kadar algorithms, ne kadar artificial intelligence öğrenmemiz gerekiyor?

Bakın ilanlara, pek çok ilanda Bilgisayar Mühendisi ile başlanır, sonra Elektronik Mühendisliği vb. mühendislikler sıralanır. Yahu BM’in yapacağı iş için niye EM ya da “ilgili bölümler” gibi ortaya karışık bir şey söylenir? Sebebi şu: Aslında aranılan şey, biraz mürekkep yalamış adam. Ne okuduğu çok da önemli değil. Gerçek bu.

Dolayısıyla “master yapalım mı” sorusunun cevabı yine tamamen kendi içinizde yatıyor. Kimse sizden master yapmış olmanızı beklemez bu ülkede, ama siz kendinizden bekliyorsanız ona saygı duyarım. Dolayısıyla bilgi sizin için önemliyse, master da yapın doktora da. Yok “erken kalkan yol alır” derseniz, bir an önce işe girin, nasıl olsa masterlı olmak çok da fazla bir avantaj sağlamayacak.

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

Düşünce Azığı: Outliers (Çizginin Dışındakiler)

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

Outliers (Çizginin Dışındakiler) –Bazı İnsanlar Neden Daha Başarılı Olur? – Malcolm Gladwell

MediaCat  9. Baskı – 2009 İstanbul

Malcolm Gladwell, Kanadalı aslıllı ve New York’ta yaşayan, bir araştırmacı, gazeteci ve yazar.  Gladwell, dördü de dilimize çevrilen, Tipping Point (Kıvılcım Anı) (2000), Blink (Düşünmeden Düşünebilmenin Gücü) (2005),  Outliers (Çizginin Dışındakiler) (2008) ve What The Dog Saw (Köpeğin Gördüğü) (2009) isimli, ABD’de çok satan kitapların yazarı. Yazar, her kitabında, hayatın tamamen içinde olan, herkesin bir şekilde az ya da çok bilgi ya da çoğunlukla his sahibi olduğu ama dile getirmekte zorlandığı bir konuyu ele alıyor,  kuvvetli gözlem ve delillerle anlaşılır hale getirip, sebep sonuç ilişkileri üzerinden giderek çözümlemeci bir yaklaşım sunuyor. Outliers’da da yaptığı, başarının bileşenlerini ele almak. Öncelikle Gadwell’in yaklaşımının, popüler kişisel gelişim kitaplarındakinden çok farklı olduğunu belirtelim. Gladwell, nasıl başarılı olabileceğinizi size öğretmeye çalışmıyor. Sadece, çok başarılı kişilerin hayatlarını ve başarı hikayelerini, kurduğu bir çerçeve içerisinde değerlendiriyor ve tezini doğrulamaya çalışıyor.

Gladwell Outliers’da dahiler, zengin ve güçlü avukatlar, rock yıldızları ve başarılı programcılardan yola çıkarak, “bireysel başarı” şeklinde ifade edilebilecek olan genel başarı algısının yanlış olduğunu ispatlamaya koyuluyor. Outliers’da iddia ettiği tez şu: Başarı, bireysel değildir. Başarı, ancak doğru şartlarda oluşabilir. Bu şartların pek çoğu ise kişinin elinde değildir, olsa olsa kişi, o başarıyı hazırlayan şartların içine doğar. Bu şartlar ise temelde zaman, toplum ve bu çerçevede ele alınabilecek olan imkanlar ya da şanslardır. Gladwell Outliers’ı, insanların başarıyı, başarılı insanların üstün zekalarına ve yeteneklerine atfetmelerini çürütmek amacıyla  yazdığını ifade ediyor. İnsanlar genel olarak, başarıda zirveye çıkmanın ancak çok sıradışı zeka ve yeteneğe sahip olmakla mümkün olduğunu düşünürler. Fakat Gladwell, normal bir zekaya sahip olduktan sonra başarı için bir bireyin yapabileceği tek şeyin çok çalışmak olduğunu vurguluyor. Peki çok çalışanların hepsi çok başarılı olabilir mi? Hayır olamazlar, çünkü, kişilerin doğduklarında kendilerini içinde bulundukları aile başta olmak üzere her türlü ortam ve zaman ile bunların sunduğu fırsatlar, onların başarılarında, zeka ve çalışmalarından çok daha etkilidir.

Outliers’in Türkçe çevirisi 224 sayfa ve MediaCat yayınları arasından 2009 yılından itibaren okuyucuya ulaşmış durumda. Kitap 9 bölümden oluşuyor. Akıcı bir dile sahip olan kitap, birkaç günde bitirilebilecek şekilde sizi kendine bağlıyor.

Kitabın ilk beş bölümü “Fırsat” başlığı altında, geri kalan dört bölümü ise “Miras” başlığı altında toplanmış. Fırsat kısmındaki bölümlerde başarılı kişlerin, nasıl fırsatlar dünyasına doğdukları inceleniyor. Miras başlığındaki bölümlerde ise atalar ve aileden gelen kültürel yapıların, başarıda oynadığı rol ele alınıyor.

Kitabın birimci bölümü “Matta Etkisi” başlığını taşıyor ve sosyologların “kümülatif avantaj” dedikleri olguyu, Kanada hokey ligindeki oyuncuların doğum tarihleri üzerinden açıklıyor. Kanada hokey ligi oyuncuları, ilkokuldan başlayıp devam eden okul liglerinde başarı gösterip sivrilen, en yetenekli oyuncular arasından geliyorlar. Ve Kanada okullarında o yılki hokey takımına seçilmenin yaş bakımından şartı, 1 Ocak’tan sonra doğmuş olmak.  Dolayısıyla takımda olan 1 Ocak doğumlu bir çocuk, aynı takımdaki 30 Aralık doğumlı bir diğer çocuğa göre çok daha gelişmiş ve yapılı oluyor.  Bu durum, bireysel liyakat prensibi üzerine kurulu olan bu sporda, en başarıların ezici  çoğunluğunun, yılın ilk aylarında doğmuş olanlardan çıkmasını sağlıyor. Ve Gladwell diyor ki, Kanada’da hokeyde ne kadar iyi olduğunuz ve ne kadar çok çalıştığınızdan daha önemli olan, yılın hangi ayında doğduğunuzdur.

Kitabın ikinci bölümünün adı “On Bin Saat Kuralı”. Bu bölümde Gladwell, doğru zamanda doğup, fırsatları değerlendirerek 10.000 saat çalışmış olma avantajını yakalayanların, şartların elverdiğinde, bu bilgi ve tecrübe ile, dallarında dünyanın en iyisi olduklarını vurguluyor.

Kitabın üçüncü ve dördüncü bölümleri “Dehaların Sorunu, 1. Bölüm” ve “Dehaların Sorunu, 2. Bölüm” isimlerini taşıyor. Gladwell bu bölümlerde, zeka ile başarı arasında bir zorunluluk ilişkisi olmadığını, dehaların hayatları ve onlar üzerine yapılan araştırmalardan yola çıkarak savunuyor. Yani yeterli zekaya sahipseniz, çalışmanız ve elinizde olmayan diğer şartların elvermesiyle, sizden çok daha yüksek zekaya sahip birinden pekala daha başarılı olabilirsiniz.

Beşinci bölüm, “Joe Flom’dan Alınacak 3 Ders”  başlığını taşıyor ve Avrupa’dan göçen yahudilerin, New York’ta nasıl zor şartlarda kendilerine yer edindiklerini ve yeni nesillerin, ailelerinin bu zorlu tecrübelerinin üzerine, zamanla, şartların değişmesiyle, oluşan fırsatları değerlendirerek nasıl başarıyı bina ettiklerini anlatıyor.

Altıncı bölüm “Kentacky, Harlan” başlığını taşıyor ve kültürel mirasın başarıdaki rolünü ele alıyor.

Yedinci bölüm “Uçak Kazalarına İlişkin Etnik Kuram” başlığını taşıyor ve pilotların içinde yetiştikleri kültürün, onlara empoze ettiği güç anlayışının, pilotların iletişim kurma biçimlerini nasıl belirlediğini ve bu durumun uçak kazalarının sebebi olarak nasıl ortaya çıktığını anlatıyor.

Sekizinci bölüm “Çeltik Tarlaları ve Matematik Testleri” başlığını taşıyor ve uzak doğuda, yüzyıllar boyunca, çok dar alanlarda ve çok dikkatli ve zahmetli çalışmalarla prinç yetiştiren insanların kültürü ile dillerinin, o topraklarda matematiksel zekanın gelişimini nasıl kolaylaştırdığı ele alınıyor.

Dokuzuncu bölüm “Marita’nın Pazarlığı” başlığını taşıyor ve ABD’de, sekizinci bölümde ele alınan kültürel yapıya benzer bir anlayışla kurulmuş özel yapıdaki bazı devlet okullarına kabul edilen ve bu fırsatın farkında olanların başarıya ulaşmalarını ele alıyor. Bu bölüm, başarının, ne sadece zeka ne de sadece çalışma ve yetenekle bina edildiğini, daha çok bir armağan olduğunu ve fırsatı değerlendirme güç ve soğukkanlılığını göstermeye bağlı olduğunu ifade ederek bitiyor.

Kitabın, “Bir Jamaika Hikayesi” isimli son sözünde ise yazar, kendi atalarını ve onlardan devraldığı mirası bize aktarıyor.

Gladwell’in kitaplarında sunduğu yaklaşım, bazı tekil olaylardan yaptığı çıkarımları genellemesinden dolayı eleştiriliyor. Bu anlamda kitabın bilimsel doğruluğu elde etmeye çalışmadığını söylemek gerekir. Dolayısıyla, kitap, doğruyu tam olarak ifade etmekten çok, doğrunun bir kısmını güzel bir şekilde ortaya koymuş olmakla övülebilir.

Kitap, bir cümlede özetlemek gerekirse, “başarılı insanlar yoktur, başarılı toplumlar vardır” fikrini güzel bir şekilde savunmaktadır.

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

Genç Yazılımlılar İçin – I

Diğer, Yazılım Mühendisliği

Gerek yüzyüze görüştüğüm gerek ise email yoluyla bana ulaşan gençler, çok sıklıkla benden “yol gösterme” istiyorlar. Hepsine ayrı ayrı birşeyler yazmaya çalışıyorum ama bir müddet sonra bunları topluca ifade etmenin daha faydalı olduğunu düşünüp bu yazıyı kaleme aldım. “Yol gösterme” isteği ile ilgili öncelikle şu iki şeyi belirtmem lazım. Benden yol gösterme ve tavsiye isteyen gençler öncelikle hakkımda hüsn-ü zanda bulunup, bana büyük bir sorumluluk yüklüyorlar. Bu durum onların iyi niyetini gösterirken beni ise sıkıntıya sokuyor. Öte taraftan gençlerin bu isteği tamamen bir ihtiyaçtan kaynaklanıyor. Her toplumda, önden gidenler, bilgi ve tecrübelerini arkadan gelenlarle paylaşırlar; bundan daha tabi birşey olamaz. Bu konuda belki dikkat edilmesi gereken şeyin, herkesin kendi tecrübesinden elde ettiklerini paylaşıyor olmasıdır, dolayısıyla her paylaşım da tabi olarak pek çok şahsi kanıyı ve tecrübeyi içinde barındıracaktır. Ülkemizde yaygın olan düşünce yapısının taklitçi ve detaycı olduğunun çok iyi farkındayım. Yani düşüncemiz yapımızda özgünlük az ve soyut kavramlar yerine tek tek olaylarla ilgilenerek vaktimizi harcıyoruz. Tek tek olaylardan yola çıkarak, sistematik olarak, soyut bir düşünce dünyası kurgulamaktan çok uzağız. Dolayısıyla da büyük resmi görmekte zorlanıyoruz. Eğitim kurumlarımız, eğitim ve gelişimi, kuru malumat ile problem çözme olarak ele aldıklarından, soyut düşünce yapımızın gelişmesine katkıda bulunmuyor. Bu da tek tek ağaçları gören ve sayan ama ormanda olduğunu farkedemeyen bireyler ortaya çıkarıyor. Dolayısıyla önden gitmiş olanların bilgi ve tecrübeleri, ormanı farketmek için daha önemli hale geliyor. İşte acizane tavsiyelerim:

  1. Öncelikle kendinizi tanıyın. Yazılım dünyasıyla ilgili nelerden hoşlanıyorsunuz, neleri yapmak size zevk veriyor, merakınız ne yönde gibi sorularla başladığınız bu tanıma süreci, nelere yeteneğim var şeklinde daha zor soruların cevabını alacak şekilde daima aklınızın bir yerinde çalışır halde olsun. Kendinizi ne kadar erken tanırsanız o kadar isabetli karar verirsiniz. Bir kişinin kendini tanıması zor ve ömür boyu süren bir faaliyettir, bunun farkındayım. “Kendini bilmek”, dini olsun olmasın her hikmet kaynağı disiplinin en temel öğretilerindendir. Kendinizi tanıdıkça, toplumda kol gezen ideolojik söylemlere kanmaz, daha sağlıklı adımlar atarsınız. (Bu konuda “Her Zeki Öğrenci, Programcı mı Olmalı?” başlıklı yazıma gözatabilirsiniz.)
  2. Odaklanın.  Gençlerde gördüğüm en temel sıkıntı, bir odaktan yoksun olmaları. Kendine bir konu belirlemiş ve o konunun üstadı olmak için var gücüyle çalışan gençler yerine, her çiçekten bir damla almaya çalışan gençler görmek çok daha ihtimal dahilinde malesef. Bu da pek çok konudan birşeyler bilen ama hiç birini tam olarak kavramamış, dolayısıyla da bir şeyi baştan sona ele alıp çözme yeteneğini haiz olmayan kişiler demek. Çok sık sahit olduğum şeylerden birisi: Hem Oracle veri tabanı, hem Java hem de Cisco için sertifika almayı planlamak ya da ne bileyim sadece birkaç yıllık kariyerinde üç-beş tane Java ya da .Net gibi heyula bilgi birikimine sahip yapılarla uğraşmış olup, hiç birinde bir projenin farklı katmanlarını, farklı vechelerini tam olarak görmemiş ve hiçbirinde yetkin bir duruma gelmemiş olmak. Günümüzde dünyasında “genişlik” yerine “derinlik” daha önemli. “Genişlik” ancak farklı ama ilişkili konularda derinleşerek elde edildiğinde anlamlı olur. Yüzeysel, “turistik” seviyedeki malumatın, yetkinlik açısından önemi yoktur. Dolayısıyla hedef belirleyin, odaklanıp, gerektiği kadar üzerinde çalışın, belli bir yetkinlik seviyesine gelin, sonra ilgili bir başka yan alana geçin öyle ki ikisi bir araya geldiğinde anlamlı bir bütün oluştursunlar.
  3. Bilgi hiyerarşisine önem verin. Temelleri anlamadan ileri konulara dalmayın. Yani daha iyi bir ifade ile “bilgi sahibi olmadan fikir sahibi olma” hastalığına kapılmayın. Unutmayın bu bizim milli hastalığımız. Gerçekliği kavramak için önce onu ciddiye alın, en temelinden başlayarak anlamaya çalışın, sonra üzerinde yorum yapın. Dolayısıyla okulda “Operating Systems” derslerine girmeden Android ya da Linux gurusu olma hayaline kapılmayın. Kendisine hayranlık duyduğunuz o işletim sistemlerinin ya da programlama dillerinin yaratıcıları ya formal ya da informal yollarla, ama muhakkak en temelinden başlayarak kendilerini yetiştirmişlerdir. Pek çoğu Stanford ya da MIT gibi okullardan doktora sahibidir. Pek çoğu, okuldayken “gerçek hayatta ne işimize yarayacak bu” diye sorduğumuz Matematik derslerini ya da hocasını beğenmediğimiz için derslerini astığımız mesela Algorithms dersine gereken önemi vermiştir. Formal bir eğitim imkanı bulamayanların ise bir şekilde tırmalayarak gerekli altyapıyı kazandıklarını görürsünüz. Dolayısıyla şu ya da bu şekilde, en temel Matematik, İşletim Sistemleri, Algoritamlar, Veri Yapıları vb. konularda gerekli altyapıya önem vermeden, aklınıza gelecek süper bir fikirle yeni bir Steve Jobs olmayı düşünüyorsanız, büyük bir ihtimalle ne eğitim ne başarı ne de Jobs hakkında fazla birşey bilmiyorsunuz demektir. Bunun için “Outliers” kitabı iyi bir başlangıç olabilir.

Şimdilik bu kadar. Aklıma geldikçe yenilerini paylaşacağım. Fikirlerinizi ve eleştirilerinizi her zaman beklediğimi ifade etmeliyim.

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

1 2