Monthly Archives: Şubat 2012

Bilgi Teknolojilerinde Yetenek Yönetimi – I

Yetenek Yönetimi , ,

Giriş

Yetenek Yönetimi (Talent Management), önce farklı yeteneklere sahip bireyleri kuruma katmak, daha sonra ise, kurumun çalışanı haline gelmiş olan bu yetenekli bireyleri, yeteneklerine uygun bir şekilde, kurumda, kurumun stratejilerine uygun bir şekilde, ihtiyaç duyulan noktalarda değerlendirip, geliştirerek, hem çalışanların hem de kurumun performansını her yönde arttırmak amacıyla, çalışanlar ve yeteneklerini yönetmek demektir. Dolayısıyla Yetenek Yönetimi bir süreçtir ve kendi içinde farklı alt süreçleri ve farklı çalışmaları barındırır.

Yetenekli çalışanlardan oluşan bir takımın, daha az yetenekli çalışanlardan oluşan takımdan daha iyi bir performansa sahip olması, dolayısıyla birim zamanda daha çok ve yüksek kalitede çıktı üretmesi beklenir. Örneğin yetenekli futbolculardan oluşan bir futbol takımının, yetenekleri daha az olan oyunculardan kurulu olan bir başka takıma karşı her zaman galip gelmesi beklenir. Biraz düşününce bu beklentinin gerçekleşebilmesi için, yetenekli çalışanları bir araya getirmekten daha başka şeylerin de olması gerektiği açık bir şekilde ortaya çıkar. Çünkü yetenekli oyunculardan oluşan takımlar, daha az yetenekli oyunculardan oluşan takımlara her zaman üstünlük kuramazlar. Yetenekli bireylerden oluşan bir topluluğun bahsedilen beklentiyi karşılayabilmesi için gerekli olan en önemli şey ise “takım” olabilmektir. Takım, “bir araya geliş”den farklı bir şeydir. Takım olmada önemli olan, bir hedef için gerekli olan performansı elde etmek için, takım üyelerinin “birbirini tamamlayan” şekilde konumlandırılmalarıdır. Peki hedef nedir? Hedef bazen bir projedir bazen de bir spor karşılaşmasıdır. Ama hedef, ister bir projeyi tamamlayıp müşterinize teslim etmek ya da bir ürünü piyasaya çıkarmak olsun isterse bir spor karşılaşmasında galibiyet olsun, genelde kurallarını sizin koymadığınız ya da en azından tamamen sizin belirlemediğiniz bir sürecin sonunda elde edilecek olan şeydir. Dolayısıyla takım olmanın unsurları arasında hedef de doğrudan belirleyici olarak bulunmaktadır. Yani nasıl bir takım olması gerektiğini, takımdaki durumları ve bu durumlardaki gereklilikleri belirleyen de hep hedeftir.

Yukarıda anlattıklarımızı biraz daha bir kurum ya da daha doğru bir ifade ile rekabete sahip bir pazarda konumlanan bir endüstriyel organizasyon açısından tekrar ele alırsak, bu organizasyonun rekabet içinde var olabilmesinin en temel şartı, içinde bulunduğu pazarın şartlarını bilmesi ve kendini buna uygun bir şekilde konumlandırabilmesidir. Aslında buna daha kısa bir ifade ile organizasyonun pazarını ve kendini bilmesi diyebiliriz. Bu durum, Stratejik Yönetim’de kurumun iç ve dış şartlarını sürekli bir şekilde analiz etmesi ve buna göre bir yol haritası yani stratejiler ve taktikler geliştirmesi anlamına gelmektedir.

Organizasyonların pazarlarını, pazardaki rekabet şartlarını bilmeleri, kendilerini pazarda konumlandırma stratejisi açısından hayati öneme sahiptir. Pazar şartları, pazardaki alıcıların ve satıcıların durumları yanı sıra, enflasyon, alım gücü, risk beklentisi gibi pek çok sosyo-ekonomik faktör tarafından belirlenir. Bu durum, organizasyonun açısından, “Pazarını Bil” ya da “Müşterini Bil” gibi sloganlarla dile getirilmektedir. Benzer şekilde hayati öneme sahip bir başka şey ise organizasyonun kendisi hakkındaki bilgisidir. Bu durumda, “bir organizasyon kendini nasıl bilir?” ya da organizasyon açısından bakıldığında “kendi”nden ne kastedildiği gibi sorular gündeme gelmektedir. Organizasyonun kendini nasıl bileceği konusunda farklı zamanlarda farklı algılar olmuş, dolayısıyla da farklı yaklaşımlar ve modeller ortaya konmuştur. Genel olarak organizasyonların kendisini bilmesinden, yaptığı işi detaylarıyla tarif edebilmesi ya da yaptığı işe dışarıdan giren girdileri bilmesi ve kontrol edebilmesi gibi noktalardan yaklaşımlar üretilmiş olmakla birlikte, endüstrilerin dolayısıyla da organizasyonların daha bilgi merkezli hale gelmesiyle birlikte bu soruya verilen cevap daha fazla insan odaklı hale gelmiştir. Bu durumda bir organizasyonun kendisini bilmesi, daha çok sahip olduğu yetenekleri bilip onları ayırt etmesi, elde tutup daha da geliştirmesi gibi açılardan ele alınmaktadır.

Yetenek Yönetimi, esas itibariyle en temel İnsan Kaynakları (İK) fonksiyonlarındandır ve daha çok son 30 yıllık süreçte gündeme gelmiş ve gelişmiştir. Yetenek Yönetimi kavramı ve süreci, İnsan Kaynakları’nın, bir kurumun süreçleri içinde sahip olduğu  yerinin ve öneminin zaman içinde nasıl değiştiğini ortaya çıkarması açısından da önemlidir. Bu anlamda konunun uzmanları, İnsan Kaynakları’nın geleneksel fonksiyonları yerine getiren idari bir birim olmaktan çıkıp, iş, pazarlama, teknoloji gibi birimlerle daha yakın çalışan ve bu birimlerin süreçlerinde idari olmaktan çok, katma değer sağlayan bir birim olmaya başlaması, yani daha modern bir deyişle Stratejik İnsan Kaynakları olmasında, Yetenek Yönetimi’nin ayrı bir rolü olduğunu belirtmektedirler.

Bilgi Teknolojileri (Information Technologies) açısından bakıldığında, Yetenek Yönetimi daha da öne çıkmaktadır. Haddi zatında Bilgi Teknolojileri (bundan sonra BT), çok yoğun bir zihin kullanımının söz konusu olduğu ve iş alanının yaygın olarak soyut kavramlardan oluştuğu bir iş alanıdır. Klasik anlamdaki kaynak kavramının, BTde  büyük oranda zihin kaynağına karşılık gelmesi, bu sektördeki kurumların kendilerini tanımasını, elindeki yetenekleri bilmesi, geliştirmesi ve elinde tutmaya devam etmesi anlamına gelmektedir. BT, bilginin miktarının ve derinliğinin en hızlı arttığı alanlardan birisidir. Bu durum, ister bu alanda rekabet etsin, isterse süreçlerinde bu alanı çok yoğun bir şekilde kullansın, BTni bünyesinde barındıran kurumların, bu alandaki yetenekli çalışanlara sahip olması ve onları geliştirmesi, bu kurumların ve özellikle de İnsan Kaynakları birimlerinin, kaynak anlamında en temel sorumluluğu haline gelmiştir.

Öte taraftan, İnsan Kaynakları açısından BT çalışanları, genel olarak “zor çalışan” kategorisinide bulunmaktadırlar. Çünkü BT çalışanları açısından teknoloji, bir meslekten ziyade bir tutkudur ve bu sektörün üyeleri, teknolojik açıdan kendilerini daima en iyi noktada tutmaya özen gösterirler. Bu sektörde çalışanlar, zaten ortalama olarak bir ülkenin en iyi eğitim almış kişilerini içinde barındırlar. Bu yüzden BT çalışanları sürekli bilgilenir, devamlı araştırır, bulur ve ortaya çıkarır. Bu durum, BT çalışanlarının, “durmak bilmeyen” ya da “çok enerjik” gibi sıfatlarla tanımlanmasına sebep olur. Bu durumun temel olarak BT çalışanlarının, diğer sektör çalışanlarıyla iletişimlerine negatif etkide bulunduğu iddia edilebilir. Çünkü, yukarıda bahsedilen özellikler BT çalışanların dilini esoterik, yani sadece ehlinin bileceği, karmaşık kelime ve tamlamalardan oluşan bir hale sokar. Öte taraftan, benzer şekilde yine aynı hasletler, BT çalışanlarını daha talepkar kılar. Bu talepkarlık sadece ücret konusunda değil, bilgilenme, eğitim alma, ek faydalar gibi pek çok farklı konuda gerçekleşir.  Tüm bunlar da birer iletişim bariyeri olarak profesyonel ortamlarda ortaya çıkar. Ama olan biten aslında BT çalışanlarının, kendi yeteneklerinin, çalıştıkları kurum tarafından daha iyi değerlendirilmesini istemelerinden başka birşey değildir. Bu anlamda BT çalışanlarının, temel ihtiyaçların üzerinde, daha çok kendilerini gerçekleştirme seviyesindeki ihtiyaçlarını karşılamada, çalıştıkları kurumun ciddi rol oynamasını bekledikleri ifade edilebilir. Tüm bunlar, birer yetenek olarak BT çalışanlarının, yetenekleri açısından da daha iyi bir yönetime ihtiyaçları olduğu gerçeğini ifade eder.

Ülkemizin BT sektörü açısından bakıldığında da Yetenek Yönetimi daha farklı bir yere sahiptir. Öncelikle BT sektörümüz son derece genç, dünya ile henüz rekabet edebilecek olgunluğa erişememiş ve çok ciddi bir şekilde ithalata dayalı bir sektördür. Sektörün büyük çoğunluğunu, telekom ve finans şirketlerinin büyük BT departmanları oluşturmaktadır. Genç ve enerjik bir nüfusa sahip olan ülkemiz BT sektörünün, yine genç ve son derece enerjik yeni mezunları, başarılı bir şekilde yetiştirip, dünya ile rekabet edebilecek şekilde bilgi ve beceri ile donattığı şüphelidir. Bu durum, aşırı değişken ortamlarda çalışmaktan yorulmuş, uzmanlaşma eksiği olan dolayısıyla da önünde sürdürülebilir bir kariyer patikası göremeyen bir BT çalışan kitlesi oluşturmaktadır. Bu durum, hem bu sektörün büyük oyuncularını, hem de özellikle yazılım geliştiren ve nispeten küçük oyuncularını negatif yönde etkilemektedir. Motivasyon eksikliği, taktir edilmemişlik, güvensiz bir gelecek gibi problemlere sahip BT çalışanları açısından Yetenek Yönetimi, kesinlikle bir ihtiyaçtır.

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

Yazılım Projelerinde İhtiyaç Analizi – I

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

Bir yazılım projesinin en kritik safhası hangisi diye sorsalar, bu yaşta hasta bir Javacı 🙂 olarak her zaman ve kesinlikle “analiz” derim. Çünkü, Brooks babanın da çok isabetli bir şekilde belirttiği gibi bir projenin en zor sorusu “neye ihtiyacımız var?”dır Yani “projemizin çıktısı olacak yazılım sisteminden ne bekliyoruz?”a cevap vermek en kritik ve en zor olandır. En kritik olandır çünkü bu sorunun cevabı, kendinden sonra gelecek her türlü yazılım geliştirme faaliyetinin içeriğini belirler. Dolayısıyla, bu soruya cevap verirken yapılacak bir hatanın, eskiklik ya da yanlışlığın örneğin, büyüyerek, ortaya çıkan yazılım sisteminde nasıl bir fonksiyonel probleme dönüşeceğini tahmin edebilirsiniz. Yazılım Mühendisliği kitapları, analiz safhasında yapılan hatanın aynı safhada düzeltilmesinin maliyetini bir birim alarak yaptıkları kıyaslamalarda, ortaya çıkan hatayı son sistemde düzletmenin maliyetinin yüzlerce kat olabileceğini vurgularlar. Bu soru aynı zamanda en zor olandır çünkü, geliştirilecek yazılım sisteminin bütün iş süreçlerini, iş kurallarını, entegre olacağı diğer sistemlerle olan iletişim detaylarını, bütün kullanıcı arayüzlerini ve diğer tüm standart, kısıntı vb. cinsten ihtiyaçlarını belirlemek çok zordur. Hatta en zordur çünkü, bir yazılım projesindeki bütün diğer faaliyetler, genel olarak üzerine bina edildiği ve önce gelen diğer çalışmalardan faydalanırlar ama işin analizinin ise çoğu zaman böyle bir lüksü yoktur. Eğer projeniniz, zaten var olan ama farklı sebeplerle yeniden yazmayı planladığınız, dolayısıyla da kullanımda olan bir yazılımın yeni versiyonu olacaksa ancak, durum çok daha farklı ve kolay olabilir. Çünkü sadece ve sadece zihinde olan bir ihtiyacı, yukarıda bahsettiğim farklı tipte ihtiyaçlar toplamı olarak ifade etmek aşırı zordur. Hatta Brooks, bunu ilk seferde yapmanın teorik olarak imkansız olduğunu söyler. Ona göre bu detayda bir betimleme, geliştirilen sistemin ancak ilkel de olsa bir versiyonunun çalışır halde görülmesinden sonra yapılabilir.

Analiz safhasının kritikliğini ve zorluğunu hallettikten sonra bir başka soruya geçelim. Yazılım projelerinde en fazla ihmal edilen, en fazla yok sayılan safha hangisidir sizce? Nereye gelmeye çalıştığımı farkettiniz değil mi? Bu sorunun cevabı ile yukarıdaki sorunun cevabı aynı malesef 🙁 Bu durum dünyada da böyle ama ülkemizde bence sanki biraz daha böyle. “Analizin ihmal” edilmesi üzerine biraz daha düşündüğümüzde, aslında bu ihmal kavramının açılması gerektiği aşikar hale gelir. Problem aslında şudur: Bir kurumun işleriyle ilgili olarak bir yazılım sistemine ihtiyacı vardır. Bu sistem ile işinin tamamını ya da bir kısmını daha hızlı ve etkin olarak yapabilecektir, en azından o kurum böyle düşünmektedir. Bu amaçla bir yazılım geliştirecek/geliştirtecek/satın alacaktır. Hangi çözümden yana giderse gitsin, ihtiyacının ne olduğunu çok ciddi bir detay ve kesinlikte belirlemek ve betimlemek zorundadır. Aksi taktirde hayal kırıklığı yaşaması çok büyük bir ihtimaldir. Yani o kurumun o an itibariyle yaptığı işler açısından, var olan iş süreçlerini, bu süreçlerdeki iş kurallarını, varsa form ve doküman gibi girdi ve çıktıları, kullanılan malzemeleri, iş sürecine dahil olan çalışan/insan rollerini ve özelliklerini, süreçlerin birbirleriyle ve diğer sistemlerle olan ilişkilerini vb. daha pek çok detayı, bir yazılım sistemi kullanmıyor olsa bile, iyi biliyor ve bu bilgiyi de formal bir şekilde örneğin bir dokümanda betimlemiş olmalıdır. Yani bir kurum, bütün işlerini tamamen klasik olarak elle, ya da en fazla Word ve Excell gibi yazılım araçlarını kullanarak işletiyor ve bir otomasyon sistemi kullanmıyor olsa bile durum budur. Bunu gerçekleştirdiğinde o kurum, “işini” biliyor ve bunu insandan bağımsız olarak detaylarıyla tarif edebiliyor demektir. Bu durumda o kurum kesinlikle daha etkin çalışır, çünkü en önemlisi kurumsal bir hafızayı çok daha sağlıklı olarak oluşturmuş olur. Bu şekilde, çalışanlarını uzmanlaştırarak, onları daha yanlışsız ve verimli bir çalışmaya sevkeder ki bu durum, çalışan motivasyonunu olumlu yönde etkiler. Böylece aynı pozisyona gelen farklı kişilerin farklı çalışma şekillerinin yarattığı iç ve dış, uyumsuzluk ve memnuniyetsizliklerin sebep olduğu verimsizlikleri ve kayıpları ortadan kaldırır. Bu şekilde oturmuş olan süreçlerin sürekli gözden geçirilmesi ve değişen şartlara uyarlanmasıyla, müthiş bir enerji ortaya çıkar. Dolayısıyla, sisteme yeni girenlerin de üretken hale gelmeleri çok hızlı olur, hatalar kemikleşmez, herkes tekerleği baştan keşfetmez.

Yukarıda bahsettiğim şekilde çalışan şirketler uzmanlaşırlar ve piyasada avantajlı duruma gelirler çünkü, öğrenmenin maliyeti en aza iner ve nihayetinde şirketlerin varlık sebebi olan, sahiplerine kar sağlamak çok daha yüksek oranlarda gerçekleşir. Çalışan seviyesinde yani micro seviyede böyle bir uzmanlaşmanın ve nihayetinde işleri, uzmanların elbirliği ile yaptığı bir akış, bir süreç olarak ele almanın, makro seviyede daha üretken, daha karlı ve verimli bir ortam oluşturduğu da açıktır. Bir şirketin çalışan başına düşen toplam üretim değerinin ya da karlılığının tamamen aynı şartlarda ve aynı sektördeki diğer bir şirketten yukarıda olmasının sebebi, karlı olan şirketin uzmanlaşmış olmasıdır. İster beğenelim ister beğenmeyelim, daha çok üretime ve dolayısıyla da tüketime odaklanmış bir dünyada, daha çok üretmenin en temel yolu, işini iyi bilmektir (ve Adam Smith tarafından kitabı “Wealth of Nations”da çok güzel bir şekilde açıklanmıştır). “İş”in, gittikçe fiziksel olmaktan çıkıp, daha zihni bir hale gelmesi ise “insan sermayesi” (human capital) kavramını daha da öne çıkarıyor tabi olarak.

Neyse, çok fazla dağıtmadan konuya dönersek, eğer bir kurum, yukarıda anlattığım şekilde kendi işini iyi bilmiyorsa, bu işi otomatize etmek amacıyla bir yazılıma sahip olması ne anlama gelir? Tabi ki bu yanlışı betonlaştırmak ya da yanlışı daha “pahalı” bir yanlış haline getirmek demektir. Zaten hantal, bürokratik, verimsiz, insana bağlı olan bir sistemin, daha da kemikleşmesi, pahalı ve değişemez hale gelmesinden başka birşey değildir bu durum. Benim gerek kamu gerek ise özel sektör kurumlarında gördüğüm pek çok “otomasyon” sistemi bu duruma örnektir. Bir devlet dairesinde bulunduğum üç-beş dakikada bile o kadar farkedilebilir bir durum ki bu, inananılmaz…

Peki şimdi bu durumu “yazılım ihtiyaçları” açısından ele alalım. Yani yukarıdaki gibi, işlerini düzgün bir süreç olarak ifade etmemiş bir kurumda yazılım geliştirmek amaçlı olarak yazılım ihtiyaçlarının analizini yapmak ne anlama gelir? Kısaca “yapamamak” anlamına gelir 🙂 Ne yaptığını bilmeyen, neye ihtiyacı olduğunu da bilemez, bu kadar basit. İşte bu yüzden bir yazılım projesinde en kritik ve en zor soru “neye ihtiyacınızın olduğu”dur.

Buraya kadar bahsettiğimiz aslında işin analizidir yani İngilizce’de “business analysis” terimiyle ifade edilen çalışmadır. Yazılım ihtiyaçlarının analizi ise, yani İngilizce’de “software requirements analysis” ile ifade edilen ise, iş analizi yapılmış bir işin otomasyonunun yazılım ile sağlanması amacıyla, geliştirilecek yazılım sisteminin ihtiyaçlarının belirlenmesidir. Bu durumda iş analizinin üzerine, bir yazılıma konu olabilecek seviyede detay girmesi gerekiyor ki “iş” bir yazılımla yerine getirilebilsin. Burada yazılım ihtiyaçları analizinin ya da daha kısaca ihtiyaç analizinin, iş analizinde olmayan bir takım yeni detaylar isteyeceği çok açıktır. Böyle bir ihtiyaç analizi çalışmasının, grafik kullanıcı arayüzü (GUI) gibi, yazılımın yarattığı yeni yapıların belirlenmesi ya da “otomasyon” kavramının getirdiği ve önceki, elle çalışan yapılarda hiçbir şekilde söz konusu olmayan performans, ölçeklenirlik, güvenlik gibi yeni ihtiyaçların ortaya çıkarılması ve detaylandırılması gibi farklı boyutları olacaktır.

Buraya kadar, ister iş amaçlı ister yazılım yazılım amaçlı olsun, ihtiyaçların tarif edilmesinden bahsettik ve burada ikili bir ayrımı kurguladık. Biz yazılımcılar, eğer sağlıklı bir yazılım geliştirmek istiyorsak, bunun için sağlıklı bir yazılım ihtiyaç analizi yapmalıyız. Sağlıklı bir yazılım ihtiyaç analizi ise sağlıklı bir iş analizi üzerine bina edilebilir. İşinin analizini yapmamış ama bir şekilde işini otomatize etmek isteyen kurumun önünde iki seçenek vardır: Ya iş analizini de, geliştirilecek olan yazılım vesilesiyle yazılım projesinde, projenin başında yapmak, ya da hiç yapmayıp, doğrudan yazılıma girişmek. Ülkemizde ikisi de çok sık olarak uygulanan yöntemler ama sanki ikincisi daha fazla oranda yapılıyor gibi geliyor bana. Dolayısıyla bir analiz yapılacaksa bile tamamen yazılım geliştirme amaçlı olarak düşünülüyor çünkü zihnimizde iş analizi ile yazılım ihtiyaç analizi ayırımı yok malesef. Bu durumda da ortaya çıkan yazılım da ezici çoğunlukla, var olan hantal ve verimsiz süreçleri kemikleştirmekten öteye hizmet etmiyor. Hatta daha da temelde, işini bilmeyen ama bir şekilde halleden 🙂 kişilerle, işini ve ihtiyacını tarif etmek amacıyla ihtiyaç analizi çalışması yapmak çok sorunlu hatta şunu da diyeyim, hastalıklı bir hal alıyor. Bu şekilde ortaya çıkan yazılım da tatmin edici olmuyor, aşırı miktarda değişiyor ve bu yazılımı ayakta tutmanın maliyeti aşırı artıyor.

Bu yazıda, iş analizi ile sonrasındaki yazılım ihtiyaçları analizinden ve aralarındaki ilişkiden bahsettik. Bir sonraki yazıda yazılım ihtiyaçlarının analizini daha detaylı olarak ele alacağız.

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

Düşünce Azığı: Java Performance

Java, Kitaplar , , , , ,

“Düşünce azığı” yazıları (bunun için “food for thought”tan esinlendim) bilgi ve fikir dünyamızı besleyen en temel kaynak olan kitaplarla ilgili olacak. İlk kitap ise geçen senenin sonunda çıkan “Java Performance” kitabı.

[openbook booknumber=”0137142528″]

Malum, Java projelerinde, aslında doğru düzgün yapılmış hemen her nesne-merkezli dil kullanılan projede, nesneler, çalışma zamanında umulmadık performans ve ölçeklenirlik (scalablity) sorunlarına yol açar. Bu durumun Java projelerinde daha da problem hale gelmesinin en temel sebebi, Java’nın bir sanal ortamda yani JVM’de çalışması. Kurumsal projelerde, kullanıcı sayısı ve dolayısıyla açılan oturum sayısı, veri tabanından getirilen nesneler, bunalrın hayat döngüleri ve temizlenmesi, JVM’in dış dünya ile ilişkisi vb. noktalar hep sıkıntı yaratır. Bu durumu çözmenin ya da baştan engellemenin en temel yolu JVM’i iyi bilmekten geçiyor. Benim gözlemlediğim, ülkemizdeki Java’cıların, bu konularda ya hiç ya da çok az farkındalık sahibi oldukları yönünde. Çok az Java’cı, örneğin HotSpot JVM’inin server ve client tipleri arasındaki farkı bilir. Çöp toplama (garbage collection) algoritmaları hakkında bilgi sahibi olan pek Javacı bulamazsınız mesela. Bu ve benzeri halleri ben “ama benim makinamda sorunsuz çalışıyor” şeklinde bir cümleyle ifade etmeyi tercih ediyorum. Bu problemli bir durum çünkü bence her Java EE projesinde bunlardan haberdar en az bir kişi olmalı ve bu haberdarlık durumu herkese yayılmalı. Performans ve ölçeklenirlik testlerinin yapılmadığı projelerde böyle bir farkındalığın olmamasına şaşmamalı ama bu durumda da problem hakikatten büyük demektir. Çünkü bu kitaptan da anlaşılacağı üzere, sistem çapında bir performans ve ölçeklenirlik farkındalığı yoksa ve gerekli çalışmalar da zamanında yapılmamışsa, yani mimari yapı, projenin en başından itibaren uygun olarak kurgulanmamışsa, sistemi süper bilgisayar üzerine kursanız da problemi çözemezsiniz.

Kitap kalın, 720 sayfa ve James Gossling tarafından bir önsöz ile başlıyor. Kitabı konu başlıkları şunlar:

  1. Strategies, Approaches, and Methodologies
  2. Operating System Performance Monitoring
  3. JVM Overview
  4. JVM Performance Monitoring
  5. Java Application Profiling
  6. Java Application Profiling Tips and Tricks
  7. Tuning the JVM Step by Step
  8. Benchmarking Java Applications
  9. Benchmarking Multitiered Applications
  10. Web Application Performance
  11. Web Services Performance
  12. Java Persistence and Enterprise Beans Performance

Ayrıca kitabın sonunda HotSpot JVM’inin parametreleri hakkında bilgi veriliyor.

Kitabın konularından da anlaşılacağı gibi kitapta hem metodoloji hem detay bir arada bulunuyor.

Bu açıdan bakıldığında “her Javacının okuması gereken kitap” diyesim geliyor ama Javacıların yılda ortalama okudukları kitap sayısı nedir diye düşününce pek de gerçekçi bulmuyorum kendimi. Ama en azından tecrübeli, bir grup programcıya liderlik eden, Java EE projelerinde mimar rolünde bulunan, tuning, performans ve ölçeklenirlik vb. çalışmaları yapan kişilerin okuması gereken kitaplardan olduğunu söyleyebilirim.

Bu arada kitap Internette PDF ve epub formatında bulunuyor.

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

İyi Bir Özgeçmiş (CV ya da Resume) Nasıl Olmalıdır?

Diğer , ,

Gerek ABD’deyken gerekse döndükten sonra ülkemizde çalışırken elimden sayısız özgeçmiş geçti. Pek çok yakınımın/arkadaşımın özgeçmişini düzelttim, daha iyi bir sunuma sahip olmasını sağladım. Dolayısıyla ülkemizde ve özellikle de gençlerin özgeçmişlerinde ortak bazı eksiklikler görüyorum, onları ifade etmek istedim.

Öncelikle özgeçmişinize, doğru olmayan, abartı taşıyan ifadeleri kesinlikle koymayın. Özellikle yeni mezun arkadaşların, yaşı kadar çalışmış olsa bile öğrenemeyeceği kadar teknolojiyi özgeçmişinize koyması kabul edilebilir birşey değil. Sadece ismini duyduğunuz, seminerini aldığınız, ya da üç-beş satır bir şey yaptığınız bir teknolojiyi biliyorum diye, hele hele 10 üzerinden 8-9 hatta 10 vererek 🙂 lütfen özgeçmişinize koymayın. Bu gibi durumlar, size olan güveni sarsar, sizi komik duruma düşürür. Gerçekçi olun ve karşı tarafa, çok şeyden az az bildiğinizi değil, bir işi halledecek şekilde, ilgili ama az sayıdaki teknolojiyi bildiğinizi ifade edin. Ve tabi bu durumun farkına özgeçmiş hazırlarken varmayın, hedefiniz en baştan itibaren bu olsun.

Özgeçmişlerde “Hedef” (Objective) alanı muhakkak olmalıdır. Bu alan ülkemizdeki özgeçmişlerde çok ender olarak gördüğüm kısım malesef. Ama özgeçmişinizi okuyan, niyetinizin ne olduğunu, neyi hedeflediğinizi anlamalı. Eğer özgeçmişinize hedef yazmada zorlanıyorsanız, daha büyük bir probleminiz var demektir, ne istediğinizi bilmiyorsunuzdur. Bu anlamda hedefler olabildiğince somut, elde edilebilir şeyler olmalı, başvurduğunuz pozisyonla ilişkili olmalı.”Giriş seviye Web programcısı” olarak başvurduğunuz bir pozisyon için “Proje Yöneticisi olmak” gibi bir hedef yazmayın. Bu sizin nihai olarak kariyer hedefiniz olabilir ama henüz ondan çok uzaktasınız ve bu pozisyon için uygun bir hedef yazmalısınız. Tabi burada, her pozisyon için ayrı hedefe sahip ayrı özgeçmişler mi oluşrturulmalı gibi bir soru akla gelecektir. Eğer odaklanmış, her işe atlamayan, hedefinizi belirlemiş kişilerseniz buna çok da ihtiyaç kalmayacaktır. Ama gerekirse bir iki farklı hedef için bir iki farklı özgeçmiş oluşturulabilir.

Eğitim ve tecrübe bilgilerinde, ayrıntılar atlanmamalıdır. Örneğin tarihler atlanmamalı, ay/yıl bazında şehir ile birlikte verilmeli. Özgeçmişinizi okuyan, eksik tarihler için “bu arada ne oldu” diye sormamalıdır.

Özel bilgilerinizi özgeçmişinizde ifade etmekten kaçının. Medeni durum, çocuk sayısı, din, en son ilişkinizin ne kadar sürdüğü 🙂 gibi bilgilerin özgeçmişlerde olmaması gerekli. Sadece ve sadece profesyonel olarak anlamlı şeyleri özgeçmişinize dahil etmelisiniz. İş ortamları sosyal ortamlar olduğundan, ülkemizde henüz çok değer verilmemekle birlikte, örneğin ABD’de, “sen bu ortama nasıl renk katacaksın” anlamında sosyalliğinizi ve liderliğinizi gösteren ve vurgulayan maddelerin özgeçmişlerde olması beklenir. Bunları abartmamak kaydıyla özgeçmişinizde bulundurun. Abartmamak kaydıyla diyorum çünkü özgeçmişinizde ilgi alanı olarak “Edebiyat” varsa, sizinle iş görüşmesi yapan birisi olarak ben, mesela size Orhan Pamuk’un son kitabı “Saf ve Düşünceli Romancı”yı okuyup okumadığınızı sorabilirim. Okumuş olmak zorunda tabi ki değilsiniz ama bu tip sorulara muhatap olduğunuzda üzerinde birşeyler söyleyebilecek kadar bilginizin olmadığı konuları, sırf farklı görünmek adına özgeçmişinize koymayın lütfen.

Ülkemizdeki gençlerin özgeçmişlerinde gördüğüm en temel problemli noktalardan birisi de şu: Aday örneğin 2 ay önce mezun olmuş ama toplamda 3 senelik tecrübesi var görünüyor özgeçmişinde. Bu nasıl olur ki diye ben düşünüyorum tabi? Okuldayken yaptığınız çalışmalar, ister okulda olsun ister dışarıda olsun, bence profesyonel tecrübeden değildir. Yok “ben okula gitmedim ama dışarıda çalıştım” diyorsanız o zaman bu daha büyük bir problem bence. Yani şunu diyorsanız, “Ben Operating Systems dersine devam etmedim, oradan buradan soru vs. bularak geçtim dersi ama dışarıda iki Android projesinde çalıştım, Android’i çok iyi biliyorum”, kusura bakmayın ben bunu almam. Bunun tutulur tarafı yok. Sizin yazdığınız Android kodunun ne zaman nasıl bir probleme yol açacağını düşünmek istemem açıkçası. Ülkemizde çok sıkıntılı olan “bilgi” anlayışı açısından düşünüldüğünde bu duruma değer verenler olabilir ama bu tipik olarak “bilgi sahibi olmadan fikir sahibi olmak”tır ve sürdürülebilir birşey değildir. Operating Systems dersini veren hocayı veya yaklaşımını beğenmiyor olabilirsiniz ama bu sizin o konuda cahil olmanızın sebebi olmamalıdır.

Özgeçmişinizde referanslarınız olmalı ya da en azından istendiğinde sağlanacağı bilgisi görülmeli. Ülkemizde referans sistemi malesef pek de işletilmiyor ama bence çok önemli. Davranışşal açıdan güvenilir tek kaynak referanslardır; bu açıdan önemlidir.

Özgeçmişler önemlidir, dolayısıyla onların şekline de önem verin. Düzgün bir formata sahip, başlıklar, paragraflar belli ve aynı düzende olmalı, nerede kalın nerede italik kullanılacağına dikkat edin ve tüm bunlar tek düzende olsunlar, gelişi güzel olmuş izlenimi vermesin. Örneğin bu amaçla MS Word’ün çok güzel olan pek çok özgeçmiş şablonundan faydalanabilirsiniz.

Malum, sunumun çok önemli olduğu bir çağda yaşıyoruz. Özgeçmişinizi, tonla benzeri arasından ayırt edilen olarak hazırlamanız ama ondan önce de bu ayırt ediciliği, kişiliğinizle, bilgi ve tecrübenizle, yetkinliklerinizle oluşturmuş olmanız çok önemli.

Özgeçmişinizdeki ifadeleriniz, noktalama işaretleri ve grammer, doğru ve hoş olsun. Bunlara dikkat edin, o ana kadar etmemişseniz, belki özgeçmiş hazırlama vesilesiyle, biraz zaman harcayıp, bu konulara eğilirsiniz. Pek çok kişiden, bu blog vb. vesilelerle email alıyorum ve içlerinde bir selam cümlesi olmayanlar oluyor, inanamazsınız 🙁 Dili nasıl kullandığınız kadar sizi ele veren başka birşey olamaz, bunu unutmayın.

Son olarak da özgeçmişlerinizi isimlendirirken, “AkinKaldiroglu – Özgeçmiş” gibi bir format kullanırsanız, email vb. yollarla ulaştığınız kişileri “tekrar isimlendirme” işinden kurtarmış olursunuz 🙂

Öz ve has geçmişli günler dilerim 🙂

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

1 2