“Ürün geliştirmek demek, ürünler için tarif vermek demektir. Ürünlerin kendisini oluşturmak değil.”

Donald G. Reinertsen¹

1993 yılında, x86 Assembly ile yazdığım TSR² tipi program, belirli tuş kombinasyonuna basıldığında ekranın o anki görüntüsü alıp, bunu 4.000 byte’lık fiziksel bir dosyaya³ yazıyordu. 1992’den, profesyonel olarak çalışmaya başladığım 1998 yılına kadar zaman zaman yazdığım Pascal uygulamaları (Muhtar 1.0?) bu fiziksel dosyaların içeriğini okuyup, belleğin belirlenmiş adreslerine bu bilgiyi yazıp, uygulama çalışırken bellekten o bilgileri alıp, ekran çizimleri için kullanıyordu. O, en fazla 80 – 100 satırlık x86 Assembly kodundan oluşan minik bir “.com” dosyası, işimi oldukça hızlandıran, benim için vazgeçilemez ve çok değerli bir yazılım olmuştu.

Yazılımın değeri

Herhangi bir hizmet ya da malın değeri denildiğinde, akla ilk olarak “ekonomik değer” gelmekte. “Bu iş bize kaça patlar?” ya da “bunu kaça yaparız?” soruları, büyük ve kurumsal olsun ya da küçük ve aile şirketi olsun, birçok firmadaki ilk sorulardan. Yazılımın değeri denilince de konuya, -özellikle bilgi teknolojilerine uzak kişiler tarafından- sadece parasal yönden yaklaşılmakta. Okuyuculardan, yazılım satış işine de bulaşmış çoğunun müşterideki “satın alma departmanları” ile benzer hikayeler yaşadıklarını düşünüyorum. Her ne kadar analiz yeteneği daha iyi olan ve geleceğe dair değişkenleri de hesaba katan ekipleri tenzih etsem de birçok satın alma departmanının iki benzer ürün ya da hizmetten daha ucuz olanını seçmesi çok rastlanılan bir senaryo olmakta ne yazık ki.

Oysa yazılım ya da yazılım hizmeti dediğimiz şey (yazının bundan sonrasında yazılım hizmeti yerine de ‘yazılım’ kelimesini kullanacağım), birçok ürün aksine elle tutulamayan, dokunulamayan, fiziksel varlığı olmayan bir metadır. Yazılımı buğday, tuğla, hazır kahve, litrelik saf oksijen ya da ne bileyim, metrelik kumaş birimine çevirip de karşılaştırma yapmanız oldukça zor. Sn. Ali Akurgal’ın 1992 yılındaki, “yazılımı ‘metre’ olarak ihraç etmeyi başarabilme” konusu⁴ aslında hala da devam eden ve kafa karıştıran bir konu. Yıllardır yazılımın ne olduğu bile tartışılmakta, bir ürün mü, bir yapıt mı yoksa bir sanat eseri mi olduğu bazı arkadaş gruplarının iç tartışmalarında bile yer almaktadır.

Bu yazıda, bir zamandır kafamı kurcalayan ve araştırmaya giriştiğim ‘yazılımın değeri’ konusunda aklıma gelenleri paylaşmaya çalışacağım. Sizlerin de akıllarında soru işareti oluşturmayı amaçladığım sorular ve kendimce cevap bulmaya çalıştığım bazı konular var. Bunu yaparken de geçmiş proje yönetimi ve IT yöneticisi deneyimlerimde kullandığım bazı yöntemleri anlatmaya çalışacağım.

Sokaktaki Vatandaşa Sorduk!

2020 yılı, Ekim ayı ortası gibi, bu yazılımın değeri konusunu, yazılımcının kendi üretimini değerlemesi açısından ele almak istedim ve Twitter üzerinde erişebildiğim yazılımcılara yönelik olarak şu şekilde sordum:

Burada koyduğum seçenekleri de şu şekilde açmaya çalıştım:

1. Satır sayısı: Yazılımın içinde benim yazdığım kod satır sayısı daha fazlaysa, o yazılım benim için daha değerlidir.  (O projeye neredeyse 18.000 satır kod yazdım)
2. Müşteriye satılan fiyat: Bütçesi yüksek bir rakam olan projede yazdığım kod, benim için daha değerlidir. ($2.000.000 fiyata satılan projede ben de görev aldım)
3. Bilinirlik / memnuniyet: Çok bilindik bir proje ya da yazılım ise, benim için oraya katkım çok daha değerlidir. (Twitter’ın FAQ sayfasındaki ‘search’ fonksiyonunun bug-fix’ini ben yaptım)
4. Harcadığım zaman: Uygulamayı gerçekleştirmek için gece gündüz çalışmak ve üzerinde çok uzun zaman geçirmek benim için daha değerlidir. (6 yıldır bu projenin içini dışını inceledim, emek verdim, gece gündüz ve hatta hafta sonu/tatillerde bile çalıştım)

2,229 kişiden gelen cevaplara göre, yazılımcılar için en önemli değer verisi, o katkıda bulundukları işin bilinirliği ve kullanıcılarının memnuniyeti olarak görülüyor. Soruyu soruş biçimine, karşı tarafın algılamasına ve tabi ki Twitter ortamındaki anonim olmaya bağlı olarak çok doğru ve net bir sonuçtur diyemem ama bizlere bir mesaj verdiğini kabulleniyorum. Bu bilgi elimizde bir dursun, konunun sonrasında ilginç bir yere bağlayacağız.

Şirketler Nasıl Hesaplıyor?

Pazarlama ya da satış stratejilerine göre “freemium”, “free”, “open-source”, kiralama, SaaS ya da “Pay as You Go” modeller oldukça yaygınlaşsa da fiyatlama modellerinden “Cost-Based Pricing” diye adlandırılan maliyet bazlı fiyatlama, özellikle, “terzi usülü yazılım yapan” firmalar için hala en popüler yöntemlerden.

Yine yazılım dünyasında özellikle daha yeni dönemlerde daha gerçekçi olarak kullanılan fiyatlama yöntemlerinden birisi de değer bazlı fiyatlandırma. Burada da tüketicinin bu tür bir yazılım için ne kadar değer biçebileceğine bakılıyor, tüketici değer algısı belirleniyor, oluşacak maliyetler hesaplanıp, tüketicinin ödeyebileceği fiyata uygun ürünler geliştiriliyor.

Bir de “rakip bazlı fiyatlandırma” konusu var ki, benim genelde içinde bulunduğum ve uğraştığım “terzi usulü yazılımlar” konusuna pek uymuyor. Bu yüzden bu konudaki bilgim neredeyse yok denecek kadar az, üzerinde aktif olarak çalışmadım, bu yüzden de bilmiyorum deyip geçeyim. Ekonomi çalışan arkadaşlar ilgili anlatımlara iyi referanslar verebilir sanırım.

Biraz kafa karıştırıcı olsa da -hatta akademik açıdan çok doğru olmasa bile-, benim en azından deneyimlediğim iki model arasındaki farkı daha iyi anlamamız için şu soruları sorduğumuzu düşünebiliriz kendimize;

1. Maliyet bazlı fiyat: Müşterinin istediği 10 fonksiyonu kaça mal edebilirim?
2. Değer bazlı fiyat: Müşterinin ödeyeceği ₺100.000’e kaç fonksiyon geliştiririm?

Maliyet Bazlı Fiyatlama Örneği

Bu yöntemde şirketler için bir yazılım projesinin satış tutarının hesaplanması, genelde, kullanılan kaynakların giderleri (proje çalışanları), yapılan özel ek masraflar (ek donanım ya da yazılım ücretleri), direkt faturalandırılamayan gider kalemlerinin (İK, stajyer, muhasebe, elektrik / internet / su / kira giderleri gibi şirketin işlemesi için şart olan ancak şirkete direkt nakit girişi sağlamayan tüm giderler) belirli oranlarda proje bedellerine eklenmesi ve tüm bu toplama yine belirli oranda şirket kârı da eklenmesi gibi yöntemler ile yapılmakta. Ya da en azından bu şekilde hesaplanması şirketin gelir / gider dengesi açısından çok daha yerinde olacaktır. Bir cesaret ile tek müşteriye satılabilecek özel bir yazılım için fiyatlandırma konusunda şunu diyebiliriz sanırım;

YB = ((PEG) + (PÖM) + (FAGİ)) * KO

YB: Yazılımın bedeli

PEG: Proje ekibi giderleri

PÖM: Projeye özel masraflar

FAGİ: Proje bağımsız, faturalandırılmayan giderler

KO: Kâr oranı

Yazının bundan sonrasındaki satış tutarı hesaplama kısmını kendi “freelance” projeleriniz için de kullanabilirsiniz belki. İyi bir fikir vereceğini düşünüyorum. Çok basit bir örnek üzerinden gideyim. A şirketi, B şirketinden bir yazılım talebinde bulunuyor ve teklif istiyor. B şirketi talebi değerlendiriyor ve şöyle bir kaynak ve kaynak kullanım planı çıkarıyor:

Proje planlayıcısı olarak bu şekilde bir saat / kaynak tahminlemesi yapabiliyorsanız, şirket içindeki kaynak saat bedelleri de belli ise, çok basit ilkokul matematiği ile bir fiyat çıkarabilirsiniz. Tek kaynak için yaklaşık saat hesabını ben aşağıdaki şekilde yapıyordum:

KSB = ((KBM * 1,2 + KYH) / (20 * 6)

KSB: Kaynak saat bedeli

KBM: Kaynak brüt maaş

KYH: Kaynak yan haklar bedeli

Formüldeki “20”, aydaki toplam iş gününü, “6” de bir gündeki iş saatini temsil ediyor. Günde 6 saat değil, 8 saat var itirazı gelebilir ancak yazılımda verimli çalışma süresi hesaplarken günlük çalışmanın en fazla %80’inin hesaba alınmasının çok daha yerinde olacağını tecrübe ettim geçtiğim zaman içinde. Burada günlük verimli çalışma saatini %75 üzerinden hesapladım. “1,2” ise işveren maliyetini (sigorta, vergi vs.) hesaplamada kullanılan özel katsayı (şirket giderlerine göre yaklaşık 1.2 ile çarpım doğru değeri veriyor).

Kaynağın aylık brüt maaşı 5.000₺ ise ve aylık özel sağlık sigortası, yemek + yol ücretleri vs. giderleri toplamı da 1.000₺ ise;

KSB = (5.000 * 1,2 + 1.000) / (20 * 6)

KSB = 7.000 / 120

KSB = 58,33

Kaynağın aylık toplam işveren maliyeti formüle göre 7.000 ve saatlik maliyeti ise ~58 TL ediyor.

Yukarıdaki tabloyu buna göre tekrar düzenlersek şöyle bir durum ortaya çıkıyor;

Burada ortaya çıkan ₺278.266, çalışanların projeyi tam planlandığı gibi zamanında bitirmeleri halinde ekibin şirkete “maliyetini” temsil etmekte. İçinde şirket kârı, ek masraflar, diğer giderler gibi farklı kalemler yok. İlk formüldeki “PEG” ile gösterdiğimiz yeri hesapladık daha. Eğer tüm “Yazılım Bedeli” formülünü uygularsak, proje teklif bedeli olarak şöyle bir şey elde edebiliriz (₺12.500 projeye özel gider, ₺10.000 faturalandırılmayan gider):

YB = ((278.266) + (12.500) + (10.000)) * 1.2

YB = 360.919,2

YB ~= ₺ 370.000

Son satırdaki ₺370.000’e yuvarlama kısmını, “pazarlık payı” olarak düşünebilirsiniz. Buradaki en önemli husus, genelde az çok girdi / çıktı hesabı yapmayı bilen, nakit akış dengesi gözeten aklı başında şirketlerin bunu böyle sayısal veriler ile yaptığı. Çoğu yerde hala “olsa olsa metodolojisi” kullanıldığını da -ne yazık ki- biliyoruz.

Epilog

Gerçek dünya örnekleri, duygusal yaklaşımlar ve çeşitli fiyatlama yöntemlerini kurcalamama ve üzerlerinde uzun süredir çalışmama rağmen hala sorularımın net bir cevabını bilemiyorum. Kişisel olarak, yazılımın standart bir ücretlendirmesinin yapılabileceğine ya da o yazılım için bir “net değer” belirtilebileceğine de pek inanmıyorum.

İlk başta özellikle koyduğum “yazılımcı için hangisi değerli” sorusuna verilen cevaplar, biz “yazılım fiyat belirleyicileri” için bir uyarı niteliğinde olur ümidindeyim. İçinde bulunduğumuz dönemde çok fazla “derdini seveyim” örneği gibi olabilir bu. İsteğim ve hayalim, üretimde büyük katkısı olan asıl kişilerin hissettiklerinin ve yorumlarının, yazılım değerlendirme ve fiyatlandırmada da benzer şekilde etkili olması. Bir yazılımı, onu üretenleri için de değerli kılabilmeyi, şirketin uzun vadeli geleceği için elzem görüyorum. Hadi danışmanlıklarda çok kullanılan havalı o terimlere de gireyim, “customer-centric approach” yanında ek olarak bir de “asıl üreticinin merkezde olduğu yaklaşım” daha iyi olacağına canı gönülden inanıyorum.

Peki ya sizce bir yazılımın gerçek değerini ne belirler? Kime göre değerlendirilmeli yazılım? Müşteri mi, üretici mi yoksa şirket sahibi mi?

Notlar, Ek Okumalar ve Yararlanılan Kaynaklar:

[1]: The Principles of Product Development Flow: Second Generation Lean Product Development. https://www.amazon.com/gp/product/B007TKU0O0/

[2]: TSR: Terminate and Stay Resident. https://en.wikipedia.org/wiki/Terminate_and_stay_resident_program

[3]: 4000 byte’ın sırrı şuradan geliyor. TSR programları, DOS türevi işletim sistemleri için yazılan küçük programlardı. DOS ekranları 80 kolonlu ve 25 satırlı bir matris üzerinde çalışır normalde. Yani matrisin her bir koordinatında bulunan karakteri kaydetmek isterseniz, 2000 byte kullanmanız gerekir (3. satırın 7. kolonunda ‘T’ harfi yazılı gibi). Her koordinattaki “renk” bilgisini de bir byte içinde tutabilirseniz (arka planı kırmızı, yazı karakter rengi de parlak beyaz gibi), toplamda 4000 byte alana ihtiyacınız olacaktır. Renk bilgisini bir byte içine yazmak için de 8 bit’in ilk dördünü ön renk ve son dördünü de arka plan rengi olarak kullanıyordum. DOS ekranlarındaki renkler (VGA ekranlarda, ‘ekran modu 0’ için) en fazla 16 adet (0…F) oluyordu. Yani şunun gibi bir yapıdaydı dosyaya yazılı olan her koordinattaki tek karakter bilgisi:

[4]: Güney, Melih; Siz, Yazılımın Birimi Nedir Bilir misiniz? https://www.melihguney.com/siz-yazilimin-birimi-nedir-bilir-misiniz.html

Ayrıca, Sn. Akurgal’a erişmek için: http://akurgal.com

[5]: Fiyatlandırma stratejileri için bkz: https://www.netrivals.com/resources/guides/3-major-pricing-strategies-a-short-guide/

The post Hepimiz Milyoner Olacağız: Bu yazılımın değeri ne, kaça satılır ki? appeared first on mirmirik.net.

Ben de kendisinin bu savına işveren taraflı olarak bakarak, bunun günümüz Türkiye şartları için hayal olabileceğini, işverenin bu maliyet altına girmek istemeyeceğini, ancak veren firma varsa da kaçırılmaması gerektiğini belirterek, şöyle bir şey yazdım:

Yeni mezun net 5.500 TL alacak bir mühendisin işveren maliyeti (sadece maaş üzerinden) ortalama olarak aylık 10.000 TL. Yemek + yol + özel sağlık sigortası giderleri yaklaşık 1.200 TL. Ofis, makine parkı giderleri ortalaması da 500 TL. Aylık maliyeti 12.000 TL oluyor bu net için. 

10 adet (yeni mezun) yazılımcı çalıştıran bir şirketin aylık minimum 120.000TL NET gelir elde etmesi gerekir sadece yazılımcı giderlerini karşılamak için. 120.000 NET gelir için ise aylık olarak (kabaca) 240.000 TL’lik ÖDENMİŞ işlerinin olması gerekir.

Her ay olarak bu kadarlık fatura kesilmesi, faturaların zamanında ödemesinin yapılmış olması ayrı şart. Bunları yapmak için de o jr. ve sıfır piyasa bilgisindeki kişilerin üretim güçlerinin “mükemmel” olması gerekmekte.

Kişi kriterlerine, yeni mezun mühendislerin “yeterliliklerine”, iş yapabilme becerilerine bile girmedim. Kısacası, -hele ki Türkiye’de- bu rakam hayal. Veren firma varsa da kaçırmayın.

Sonrasında ise engellendiğim için kendisinin değerli görüşlerinden yararlanamadım. Bu yazı, “yeni mezun bir yazılım mühendisinin minimum 5.500 TL net ücret ile Türkiye’de işe başlaması” konusundaki görüşlerim ile ilgili olacak. Başlayalım…

Önce TLDR; kısmı!

Yazının devamını okumayacaklar için benim konu hakkındaki “sonuç” görüşümü “keşkeler ile dolu olarak” yazmam daha doğru geliyor. Şöyle ki;

1. Keşke her diplomasını alan mühendis arkadaşlarımız aynı derecede “ilgili” ve “öğrenmeye aç” olabilse,
2. Keşke okullarımızdaki eğitimimiz öğrenci arkadaşları araştırmaya, sorgulamaya, ezber yerine öğrenebilmeye ve meraka yöneltse,
3. Keşke (konu özelinde bilgi teknolojilerindeki) yeni mezun işe alım teşvikleri firmalar tarafından sömürüye bu kadar açık olmasa,
4. Keşke vergi sistemimiz insaflı olabilse ve ücret dağılımı buna göre yapılabilse,
5. Keşke adaletli gelir dağılımı konusunda daha da iyi olabilsek,
6. Keşke her yeni mezun arkadaşımız teknik becerilerden önce “konuşabilmeyi”, “yazabilmeyi” bari bilebilse, “ekip çalışması gerekliliğini”, “sosyal bir canlı olduğumuz gerçeğini” kabul edebilse,
7. Keşke “diploma sahibi olmanın” aslında çok da bir şey olmadığı kabullenilse,
8. Keşke mezunlarımız, Türkiye’nin sosyo-ekonomisi bilen, gelir düzeyini kavrayabilmiş, ekonominin ne olduğunu az çok anlayabilse,
9. Tüm bunlar olduğunda sonuç olarak, değil 5.500TL, 10.000 TL ile işe başlayabilse.

Bunlar benim isteklerim. Sanırım konuyu açan kişi gibi çok bilgili olamadığım için, direkt olarak “hayır ya, ne 5.500’ü, 1.000 TL bile yeter” gibi saçma bir tavırda bulunamıyorum. Net ücret, brüt ücret ve işveren maliyeti konularını zor yollardan da olsa öğrendiğim için onlar ile ilgili bilgilerimi paylaşarak başlayayım. Bu sonuçlara nasıl ulaştığım daha net anlaşılabilir belki.

Net ücret, brüt ücret?

Hem yeni mezun arkadaşlarımız hem de ne yazık ki yıllardır işçi olarak çalışan arkadaşlarımız net ücret / brüt ücret / işveren maliyeti konularında bilgisiz olabiliyor. Öncelikle bu konulara biraz açıklık getireyim. Bunlar sınav sorularında cevap olabilecek nitelikte ansiklopedik ya da teknik tanımlar değil. Benim düşüncelerim. Aradaki hesaplamaları ise 2019 yılı vergi dilimleri ve vergi oranlarına göre ekledim. Onlar matematiksel olarak doğru.

Net ücret

Ay sonunda aldığınız, bankanıza yatan, cebinize giren ve devlete ödenen vergilerden arındırılmış kesin rakamdır. Hani o borçlarınızı ödeyip de, maaşınızı aldığınız haftadaki ilk Cuma ve Cumartesi günü çılgınca eğlendiğiniz, ancak sonraki haftalarda makarnaya talip olmanızı sağlayan o küçücük meblağa “net ücret” denilir. O aldığınız para ile alış veriş yapar, alışverişiniz karşılığında fiş alsanız da almasanız da yine devlete vergi öder, aylık geçiminizi sağlamaya çalışırsınız.

Brüt ücret

Sizin net maaşınız üzerine kesintiler ve vergilerin de dahil olduğu, işveren tarafından hem devlete vergi olarak hem de size maaş olarak ödenen toplam tutardır. Hani “bordro” denilen bir kağıt vardır ya arada imza attığınız. İşte oradaki rakamdır. İçinde devlete verilen vergi de vardır o kağıtta. O kağıttaki dip toplamda sizinle yapılan anlaşma rakamını görmüyorsanız, çok büyük ihtimal ile çalıştığınız şirket sizin üzerinizden devleti kandırmaya yönelik olarak vergi kaçakçılığı yapıyordur.

İşveren maliyeti

Brüt maaşınız üzerine, sizin için yapılan toplam aylık masraftır. Aylık yemek paranız, servis ya da özel sağlık sigorta ücretleriniz, ofisteki çayınızdan, kullandığınız bilgisayarın yaktığı elektriğe, sandalye masa gibi demirbaşların yıllık masraflarından ofis kirasına kadar masrafların aslında üreten kişi olarak sizin payınıza düşen kısmı ile hesaplanır. Bu hesaplara bir de “non-profit-employee” denilen giderler de eklenir. Muhasebe, avukat, temizlikçi, asistan hizmetleri bu kapsamdadır genelde.

Eee, 5.500 TL ne olacak yani?

Yukarıdaki tanımlamaların herhangi bir şirket için “gerçek dünyadaki” yansımaları ise şöyle hesaplanıyor.

Mühendis olanların çok sevdiği “matematik”, sırf diploması yüzünden yeni mezun birisine verilmesi şart koşulan net rakama karşılık, gerçek dünya için bunu ortaya koyuyor. Bunda da bir eksiklik yok. Brüt maaş hesaplarını yapmak için ben şu siteyi kullanıyorum, size de tavsiye ederim:

https://www.verginet.net/dtt/maashesaplama.aspx

Ekip olunca ne olacak?

Yukarıdaki hesaplar tek kişi için şirketin aylık olarak ayırması gereken kaynağı gösteriyor. Hadi hep beraber bir şirket kuralım. Sonra da oraya yeni mezun arkadaşları alalım ve hepsini “minimum 5.500 net maaş” ile işe başlatalım. 10 kişi olsunlar. Diplomalı mühendisler olarak hesap kitap işlerini çok iyi bildiğimiz için bu hesaplamalar hiç de zor değil (Kopya: yukarıdaki sayıları 10 ile çarpın). Buyrunuz:

Her şey güzel. Bu duruma göre, şirket olarak yapmamız gereken tek şey şu. Her ay “net olarak” çalışanlara verilmesi şart olan 120.000 (yüz yirmi bin) TL’lik iş yapmamız lazım. Bence yapabiliriz zaten. Sonuçta “milyon dolarlar” dönüyor zaten piyasada ve işte o “5.500 TL net şartı” savını ortaya atan kişinin dediği gibi, patronlar da zaten her yıl eşinin ve kendisinin Porsche’sini yenilemek için işçileri sömürüyor. Hadi sömürelim.

120.000 TL aylık net ödeme için şirketin kesmesi gereken fatura tutarı aylık olarak yaklaşık 240.000 TL. Neden? E çünkü gelir vergisi var, KDV var, stopaj var, belediye vergileri var, defter tasdik bedeli var, Bağkur ödemesi var, muhtasar damga vergisi var, geçici vergi damga vergisi ve eki var, kurumlar vergisi damga vergisi ve eki var. Kısacası, günlük olarak neredeyse 12.000 TL’lik iş yapma mecburiyeti var şirketin (20 iş günü zaten. Çünkü biliyorsunuz, fazla mesai vs. olunca yeni mezun arkadaşlarımız rahatsız olacaklar).

Aylık olarak “t₀” anında bir “sömürücü patronun” aylık 240.000 TL verebilmesi için ya milli piyangodan para çıkmış olması ya miras kalması ya da gerçekten geçmiş yıllarda kazandıkları ile çok iyi birikim yapması gerekmekte.

İşte o “sömürücü patron” bu parası ile arsa alıp konuttan da kazanabilir, inşaat işine de girebilir ya da parasını faize de yatırabilirdi. Mükemmel gelir kaynaklarına da kavuşabilirdi.

Kişisel serzeniş

Elini vicdanına koymadan, Türkiye şartlarını bilmeden işkembe-i kübradan sallayan, her önüne gelen karşı savı safsatalar ile geçiştirmeye çalışan mühendislere gerçekten ihtiyaç yok. Teknik bilgilerinin mükemmelliği ile istedikleri yerlerde çok iyi işler çıkarabilir ve çalışabilir hepsi. Birilerinin yaptığı işleri ve geldikleri noktaları, geçirdikleri zorlukları bilmeden çoğunluk ile aynı kefeye koyup da kaçmayın yeterli.

Hedefinizi “gerçek problemlere” yöneltin. Öne sürdüğünüz her iddianızı eleştiren kişilere “ad-hominem” ile saldırmayın. Skeptik olun!

The post İşverenler Mars’tan, yazılımcılar Venüs’ten… appeared first on mirmirik.net.

Bir önce yazdığım yazıda, Türkiye’deki bir yazılımcının kariyer adımlarından Stajyer ve Jr. Yazılımcı konularında ahkam kesmiş, samimi özgeçmişimi de yazı içine ekleyeceğimi belirtmiş, azıcık içinde bulunduğumuz yönetim/sosyal çevre durumlarına çemkirmiş ve devamının Eylül’de geleceğini yazmıştım. Hakkında onlarca şarkı olan Eylül ayı geldiğine göre sözümüzde duralım o zaman. Hazır sözümüzde dururken de, şu çalsın arka planda(Rakı opsiyonel ama tavsiye edilir):

https://www.youtube.com/watch?v=ZFobOUv942k

Bu yazıdaki planım, bir öncekinde belirttiğim adımlardan “Yazılımcı” ve “Uzman / Senior yazılımcı” kavramlarını bir arada almak. Bu konuda biraz doluyum açıkçası. Sonrasında da “Teknik lider / mimar” ve “Takım/ekip yöneticisi” titrelerini kendi görüş açıma göre yorumlamak var aklımda ama bu büyük ihtimalle Ekim Mırmırık’ına kalacak. “IT Yöneticisi” ve “CTO/CIO” kavramlarını da Kasım Mırmırık’ına “sallayarak” üstümden atma niyetim var açıkçası. Bu arada şunu özellikle tekrarlamak istiyorum. Burada yazdıklarım sadece ve sadece benim görüşlerim. Ne benim çalışma/işbirliği ya da ortaklığı yaptığım şirketleri ve çalışanlarını, ne önceden çalışmış olduğum şirketleri(ve çalışanlarını) ne de eş/sevgili/eski sevgili/tanıdık/dost/akraba/arkadaş/komşularımı bağlar. Tüm fikirler, kişisel deneyimlerim ve görüşlerimdir.

Neyse…
Başlayalım!

3. Yazılımcı / Uzman yazılımcı

Gerçekler: Bu iki ünvanı birleştirme sebebim aslında Türkiye’de (özellikle son iki yıldır) ‘yazılımcı’ bulamamam ile ilgili. Herkes ya çok işin başında(Jr.) ya da çoktan uzman seviyeye(Sr.) erişmiş durumda! Arada kalan bir arkadaş yok! Bir zamanlar ünvanım öyle gibi görünse de, geçmişime baktığımda kendimi bir konuda “uzmanlaşmış” göremiyorum nedense. Yönetim kademesine adım attığımda, kendimi geçmiş işlerim ile ilgili “uzman” sanmam büyük bir yanılgıydı. Şu anda gördüğüm de bir çok yazılım geliştirici arkadaşta aynı durum söz konusu. Aynı şirkette 1-1.5 yıl geçirmiş bir çok kişi maaş görüşmeleri ya da yeni iş görüşmelerinde mutlaka “uzman” olarak devam etmek istiyorlar. Bunun suçunu da ne yazık ki yine ikiye bölüyorum. Hep o şikayet konusu olan Y ve Z kuşağı ile şirketlerin yönetimsel beceriksizlikleri. Türkiye’de şirketlerin bir çoğu hala 1970 kuşağındaki babalarımızdan gördüğümüz şirket yönetim anlayışında işliyor. Üzgünüm ki, buna yazılım şirketleri de dahil. Y veya Z kuşağının anlayış / beklenti veya yaşanmışlık farklılıklarını hesaba katmadan, sadece daha fazla para ve “ünvan” ile şirket bağımlılığı yaratabileceğini (hala) düşünen yüzlerce şirket yöneticisi var. Aynı şekilde, Y/Z kuşağındaki arkadaşlar da bir önceki yazıda anlattığım gibi stajyerliğini “çakma” yaparak, Jr. döneminde sadece ezbere dayalı, iki Google araması ile çözülecek sorunları çözerek geçirmiş olmalarına rağmen kendilerini bulunmaz hint kumaşı sanıyorlar. Şu karikatür için -her ne kadar işvereni haksız görsem de- özür dileyemeyeceğim arkadaşlar…

Gereken: Yazılım süreçleri danışmanlığı yaptığım bir şirkette, “Dünyanın parasını döküyoruz, adam/kadın hala ‘o iş öyle olmaz’ diye itiraz ediyor” cümlesini duydum. “Improvements” konu başlığında yönetici aleyhine “kırmızı” madde olarak yerini aldı. Bir yönetici olarak bana gelen “o iş öyle olmaz” itirazı, en güzel ve en yerinde tartışma konusu aslında. Çünkü bu sorunun karşılığı olan “nasıl olur peki? İkna et beni” cümlesinin karşılığını verebilecek bir uzman yazılımcı varsa, o kişi aklı çalışan birisidir. 10 yıl boyunca C# yazmış olması bir kişiyi uzman yapmayabilir. “İkna edebilir misin beni?” sorusunun karşılığını ne kadar verebildiği ve ne kadar veriye dayalı ikna kabiliyeti olduğu belli eder uzmanlığını. Bir konuya veriler ile itiraz edebilmek, düşünebilmek ile ilgilidir ve yazılım uzmanlığı aslında herhangi bir programlama dilinde kaç yıldır kod yazabildiğiniz ile ilgili değildir. O yıllar sadece, o spesifik dildeki uzmanlığınızı/ezberinizi gösterir. MS Word kullanmak gibi düşünün(ben asla MS Word ya da MS Excel uzmanı olamadım örneğin [denedim!]. Hala içinde hem “portrait” hem de “landscape” sayfalar olan doküman yaratmakta ya da özel bir pivot oluşturmada Google araması yapıyorum).

Bir problem karşısındaki çözümü değerlendirebilip, o çözümün uygulamaya ne kadar uyabileceğini tartmak, araştırma yapmak, veriler üzerinde analiz yapmak, sonuca varmak, o sonucun işe yaramayacağını görebilmek ve işe yarar bir alternatif çözüm üretebilmek; her uzmanlıkta olduğu gibi, “yazılım uzmanlığı” ünvanında da değerlidir. Bu değeri bir de “itiraz edebilme cesareti” ile birleştirebilirseniz, uğraşınız sizi “Teknik Lider”liğe de hazırlar. İnce noktayı bir daha belirteyim ki “abi ben de mükemmel itiraz ediyorum da, kovdular yahu” tarzı mesajların önüne şimdiden geçeyim. İtiraz noktasının sonrasında gerçekten ispatlanabilir, bilimsel metodlar ile gerçekliği gösterilebilir veriler sunabiliyorsanız anlamlı ve mantıklı olursunuz. Diğer türlü her şeye itiraz eden huysuz şirinden farkınız kalmaz. İki ünvan öncesine dönersek, matematik ve algoritmalar konularına eğilmeniz gereken zaman ile ilgili hala bir şeyler yapabilirsiniz. Okuyun, araştırın, meraklı olun ve öğrenin. Yüzlerce ücretsiz internet kursu, binlerce ücretsiz kitap var internette. Aklınızın gözünü açın. Okuyun, araştırın ve öğrenin lütfen. Bu zamandaki üniversiteler tabi ki “öğrenme” ve “sorgulama” konularında basiretsiz kalacaklar üst otoriteye biat ettikleri yüzünden ama, geleceğinizi düşünüyorsanız tek düşünceye esir olmayın, soru sormayı, aklın ve bilimin yolunu bulmaya çalışın. Önümüzdeki yüz yıl geçmiş fantastik hikayelerinin değil, aklın ve bilimin yüz yılı olacak. Kendinizi buna göre hazırlayın.

Kişisel eklenti: Kendimi “yazılım uzmanı” olarak gördüğüm zamanlar sanırım proje yönetimine geçiş öncesi dönemlerime rastlıyor. 2005-2007 gibi işte. Her şeyi en iyi bilen, assembly ve pascal dillerinde kod yazarken, internetin TR’de doğuşuna şahitlik etmiş bir yazılımcıydım sonuçta. Backend – frontend – DB – tasarım ve mimari konularında sabaha kadar tartışabilecek bilgiye sahiptim. Byte değil bit hesabı yapıyordum kullandığım değişkenlerde. Onlarca proje başarmış, bir yarısı kadar da batırmıştım (proje batırma konusu ayrı yazı konusu olsun, çok değerlidir). Bu etrafta gezinen proje yöneticileri ve / veya ekip yöneticileri ne iş yapıyorlardı ki gelip benimle “iş” konusunda tartışma cesaretine sahip olabiliyorlardı…

Şu anda düşündüğümde, tabi ki bu fikirlerim komik geliyor. “İş” konusunda bilgim o kadar azdı ki… Teknik konulardaki bilgilerim ne kadar yüksek olursa olsun, iş konusunda kocaman bir sıfırdım ve “iş” için çok farklı disiplinlerden, çok farklı şeyler öğrenmem gerekiyordu. Bir değişkenin bellekte tutacağı yerin bir “word” ya da bir “bit” olmasını bilmek, 6 ay sonrasının getirilerindeki “forecast” değerleri için çok da önemli olmayabiliyordu bazı durumlarda. Ben ise “forecast” kelimesini duymuş olmama rağmen, yeni öğreniyordum… “İş” öğrenmem gerekiyordu, işi öğrenmem için ise kendimi biraz daha pişirmem ve “teknik ekip lideri” pozisyonuna koşmam gerekiyordu.

Geri kalan hikaye ve görüşler Ekim Mırmırık’ının olsun (“in your face October Mırmırık” diyeyim ben de Ağustos’taki gibi.)

Biterken çalıyordu:

The post Yazılımcı maskesini çıkarıp yönetici olmak / II appeared first on mirmirik.net.

Red Kit’i hepimiz biliriz. Lucky Luke diye geçer İngilizcede. Morris olarak tanınan Belçikalı çizer Maurice De Bevere tarafından 1940 sonlarında yaratılmış ve dünya çapında ün sağlamıştır. Zor durumda kalan insanları kurtarır, karşılaştığı olayları gölgesinden bile hızlı çektiği silahı ve en büyük yardımcısı ve dünyanın en zeki atı olan Düldül ve dünyanın en aptal köpeği olan Rin Tin Tin ile çözer; tam son anda uçurumdan yuvarlanmak üzere olan posta arabasının yolunu değiştirir, kasabanın başına çok uzun zamandır bela olan çeteyi tam da artık kasabayı yok edeceklerken dağıtır, varolabilecek tüm sorunlar onun başına gelir, her şeyi çözdükten sonra da yine yalnız başına, gün batımına ve yeni sorunlarına doğru yoluna devam eder, takım oyuncusu değil, tek tabancadır. (Düldül’ün asıl adı Jolly Jumper’dır çizgi romanlarda. Rin Tin Tin’in çizimlerdeki adı da Rantanplan’dır, Türkçe diline gerçekte ünlü bir sinema oyuncusu haline gelmiş olan, I. Dünya Savaşı sırasında kurtarılmış bir Alman kurt köpeğinin adı olan Rin Tin Tin ile geçmiştir [#donotshopadopt]).

Tanınan ve sevilen bir kovboy olan Red Kit anolojisini vermemin sebebi, uzun zamandır bir kaç farklı yazılım ekibinde karşılaştığım bir durumun, bir zamanlar “kovboy yazılımcı” olmanın ve sonrasında da bir yönetici olarak bu kovboylar ile neler yaşanabileceğinin tecrübelerini paylaşmak.

Kovboy yazılımcı derken ilginç şapkalar takmalarını, mahmuzlu çizmeler ile etrafta dolaşmalarını, mataralarını yalaktan doldurmalarını kastetmiyorum. Yalnız olmalarından, bir ekip ile çalışamamalarından, devamlı sorunlar ile uğraşmalarından, bunun tercihleri olmasından ve aslında nişan almadan silahlarını çekip kalçalarından ateş etmelerinden bahsediyorum.

Önce çuvaldız…

Üniversite dönemimde az deneyimli bir yazılımcı olarak başladığım ilk işimde “kovboy” haline gelmem 1.5 ya da 2 yılımı almıştı. Birlikte çalıştığım arkadaşlarım ya da o zamanki şirketin sahibi olan iş arkadaşlarım (hiç bir zaman patron diye görmediğim için bu tabiri kullanıyorum) hatırlayacaklardır. Belirli konulardaki tüm bilgiler sadece bendeydi, sadece benim istediklerimi yapmaya veya yaptırmaya çalışıyordum, önemli projelerdeki en “core” kodları ben yazmıştım, işin ilk aşamasından müşteri teslimine kadar olan süreçte dediğim dedik inatçı birisi olmuş ve tüm seslere kulağımı tıkamıştım. Tüm yazılım ekibindeki arkadaşların yazdıkları kodları mutlaka ben gözden geçirmeliydim ki, çocuğum olarak gördüğüm projeler “kirlenmemiş” olsundu. Ekip arkadaşlarımı yönlendirmek, onlara güvenmek ve işleri onlarla paylaşıp düzgün iş çıkarmak yerine, egomu tatmine yönlenmiştim.

20-22 yaşlarındayken bunlar çok güzel duygulardı. Kendini önemli görmek, vazgeçilmez hissetmek… Hepsi bir şekilde ego tatmini yaşatıyordu. Sonrasında olanlar ise kendi yarattığım kompleksin ve egoistliğin sonuçlarıydı sadece. Öncelikle varolan eski işlerin operasyonel yüklerini çekemez hale geldim. Bug-fix ya da CR’lar ile uğraşmaktan sabahlara kadar klavye başında kalıyor, ne kendimi teknik anlamda istediğim kadar geliştirebiliyor ne de istediğim gibi yazılım üretebiliyordum. Her yaptığım şey yeni bir bug ya da operasyonel yük üretiyor, ya da projeye zarar getirip müşteri memnuniyetsizliği yaratıyordu. Tüm bunlar tabi ki her şeyi etkiliyor, bir çığ yığını gibi büyüyen işler altında boğuluyor ve iş memnuniyetsizliğim üst noktaya çıkıyordu. İşten sıkılıyordum, bana kendi hayatımı yaşamam için gerekli zaman kalmıyordu, gelen isteklerin sonu yoktu, herkes her şeyi bana soruyordu, en ufak bir problem oluştuğunda bile ya sorumlu ya da o çıkan sorunu çok acil çözmesi gereken kişi olarak ben biliniyordum. Bir çok kod test edilmeden canlı ortama aktarılıyordu. Ekibe yeni giren tüm arkadaşların sorumluluğu da vardı. Onların eğitimi ile geçireceğim sürede tabi ki iki satır kod yazmak daha mantıklıydı o zamanlar… Zaten onlar bu çömezlikleri ile ne bilebilirdi ki?

Buraya kadarki senaryoda var olan kişi şu anda IT ekibinizde mi sizin de? Bir şekilde projenin her şeyini bilen ve vazgeçilmez gibi görünen o kovboy ile çalışmak zorunda mısınız? Üstü iseniz gitmek ile tehdit etmeye varan iyileşmeler göstermiyor ve şirketin şu anki durumu için bu durum kötü mü görünüyor? Ya da o kişinin astı iseniz sizi her durumda eziyor ve yaptıklarınızı bir türlü beğenmiyor, size güvenmiyor mu? Her iki durumun da çözümü tam olarak yazının devamında demek isterdim…

Gelelim iğneye…

Sevgili kovboylar: Eğer öğrenimlerinizi ve kazanımlarınızı aktarmaz, iş bölümü yapmaz, en doğrusunu ben bilirim tavrınızı değiştirmez, sizin güveninizi isteyen ekibinize sorumluluk vermez, takım oyuncusu olmak yerine tek tabanca ilerlemekte ısrar ederseniz; bir yazılım projesinin, ekibinin baş aktörü olmak ve projenin ya da şirketin kuruluşundan bu yana işin içinde ve hatta başında olmak hiç bir meziyet ya da övünülecek bir şey değil. Bundan 8-10 yıl sonrasında open source neden tüm dünyayı ele geçirmiş olacak sanıyorsunuz? Paylaşmak, bilgi aktarımı, yönlendirici rolü üstlenmek, takımdaki daha az teknik yeterlilikteki arkadaşlar ile güven ilişkisinin kuvvetlendirilmesi, ekip çalışması kavramları emin olun sadece üst düzey yöneticilerin “şirkete kurumsal kimlik kazandırmak” için uydurduğu şeyler değil.

Evet haklısınız, proje için şu anda çok değerlisiniz. Projenin detaylarındaki o küçük iş kurallarını sadece siz biliyorsunuz ve sipariş modülünde yapılması gereken o ufak bug-fix, depo ve sipariş toplama için bundan bir yıl önce eklenen kuralı öyle bir ihlal ediyor ki, bunun çok dikkatli uygulanması lazım. Bu konuda da tabi ki henüz sekiz aydır ekibinizde çalışan yazılımcının yazacağı koda güvenemezsiniz, sizin yapmanız lazım (hem de bu kadar çok iş arasında). Aslında neden güvenemeyeceğinizi de biliyorsunuz. Sisteme az da olsa hakim olacak kadar kendisine yol gösterilmedi şimdiye kadar. Yaptığı her yanlışta “sen çekil ben yapayım” dediniz. Her yanlışını onu ezerek yüzüne vurdunuz ve her yaptığı değişikliği size göstermesini, sizin onayınız olmadan asla bir işe girişmemesini söylediniz kendisine.

Sizi daha çok ekip yönetimine yönlendirmeye çalışan yöneticinize de üstünüzdeki işlerin yoğunluğunu, sabahlara kadar çalışmalarınızı, bu şirket/proje için yaptığınız fedakarlıkları, hastayken bile sırf iş yürüsün diye gelip çalıştığınızı ve hiç bir kötü yorumu haketmediğinizi anlattınız.

Önünüzde iki yol var. Biri zahmetli ve zaman alacak olan süreç olan “iş dağıtımını öğrenmek” ve ekip yöneticisi olarak kariyerinizde ilerlemeye devam etmek, diğeri de kolay olan şu anki durumun devamını sağlamak. Zaten çoktan ekip yöneticisi olarak adlandırılmış olabilirsiniz, ancak hala tüm operasyonun yükünü “hands-on” olarak siz çekiyor, üstlerinizden gelen işleri içten içe saçma ya da zaman darlığından dolayı yapılamaz kabul edip buna karşı sayısal veriler ile üstünüzü ikna edemiyorsanız ekip yöneticiliğiniz sadece kağıt üstündedir. Daha kendinizi yönetemezken ekibi yönetiyor olarak görülmeniz çok da mantıklı görülmez.

Daha somut adımlar ile kovboyluktan nasıl vazgeçebileceğiniz ile ilgili bir sonraki yazıda ahkam kesmeyi planlıyorum. Şimdi gidip Dalton kardeşler ile uğraşmam lazım… O yazı çıkana kadar, sevgili Morris’i anmak lazım:

https://www.youtube.com/watch?v=B_EXFt4BSiY&t=40

The post Yazılım ekibindeki kahraman kovboy… appeared first on mirmirik.net.

Oldukça büyük ve ünlü bir restoran mutfağındaki aşçılık ve büyük ihtimalle şef aşçılık kariyeriniz sizi, bir şekilde, müşteriler ile daha fazla beraber olabildiğiniz “şef garsonluk” tarafına sürükledi. Artık mutfakta dönen her şeyden siz “ayrıca” sorumlusunuz. Gelen siparişlerin içerideki şef aşçıya iletilmesi, siparişin ne kadar sürede hazırlanması gerektiği, içeriğinin müşterinin istediği şekilde nasıl hazırlanabileceği ve bunu en hızlı nasıl ve kimin tarafından sunulabileceği tamamen sizin kontrolünüzde. Tabi ki bunların hepsi kasada oturan arkadaşınızın uyarıları ile şekillenmek zorunda. İşin en kötüsü de, bu restoranda menü falan yok. Sadece sizin “kırmızı et” yemekleri konusunda iyi olduğunuz biliniyor çevrede. Kimin ne zaman ve neyi nasıl isteyeceği tamamen deneyimlerinizden kaynaklı öngörülerinize bağlı.

İş hayatınızdaki “yazılımcı” ve büyük bir ihtimalle “yazılım takım yöneticisi” kariyeriniz bir şekilde, müşteriler ve şirket yöneticileri ile çok daha fazla birebir ilişki kurduğunuz “manager” pozisyonuna sizi sürükledi. Artık IT ekibi içinde dönen her şeyden çok daha fazla sorumlu hale geldiniz (Bir nevi, 1.49V üzeri DC ya da AC ile çalışan herşeyin sorumluluğu sizde). IT’den belirli bir zaman planına uygun olarak istenilen her şeyin, bir süzgeçten geçirilip yazılım takım yöneticisine iletilmesi, isteğin çıktısının ne olması gerektiği gibi konularda kafanızı oldukça yormanız gerekmekte. Bunları yaparken de finansal girdi ve çıktıları hesaba katıp, en uygun fiyatlı çözümü sunmanızın şart olduğunu da unutmamak gerekiyor.

İşlerin yetişemediğini, bir nevi gelen talepleri artık elinizdeki aşçılar ile karşılayamadığınızı farkettiğinizi ve çözüm olarak bir ya da iki aşçıyı daha ekibinize katmak olduğunu gördüğünüzü varsayalım. Elinizde sağlam veriler de var. Verileri analiz ettiniz ve bir iki ay içinde her akşam size gelen müşterilerin isteklerini, istedikleri süre içinde tam olarak karşılayamayacağınızı biliyorsunuz ve bu isteklerin daha da artacağını zaten görüyorsunuz. Bu durumda atılacak adımlar belli aslında. Bu durumu yöneticinize (büyük ihtimalle genel müdürünüze) bildirmek ve iyi bir aşçı arama sürecine girmek ya da bu kadar masa fazla, bunların sayılarını azaltmamız lazım demek. İkinci seçeneği seçmeniz mantıksal açıdan kolay yol olsa da, işletme açısından istenilen bir davranış olmayacaktır büyük ihtimalle. İlk seçeneğe dönelim. Eleman alalım…

Restoranlardaki işe alımların hangi süreçlerden geçtiğini kesin olarak bilmediğim için tabi ki o konuda ahkam kesmeye devam etmeyeceğim. Kendi bildiğim kısma döneyim. Artık birlikte çalıştığımız IT ekibine yeni bir çalışan katma konusunda sorumlu hale geldiğimize göre, bu konudaki deneyimleri anlatıyor olmanın zararı olmaz.

• Öncelikle, “eleman” değil, çalışma arkadaşı arayışı içinde olduğunuzu kabullenin. “Eleman” arayışından vazgeçin. İş arkadaşı arayın.
• İşverenlerinizin hayalindeki gibi mükemmel kişiliğe sahip, sabahtan akşama kadar yerinden kalkmadan çalışan, işyerinin “iş hedeflerini” %100 içselleştirmiş ve çok iyi derecede teknik bilgiye sahip insan arayışından vazgeçin. Öyle birisi yok. Onlara Artificial Intelligence adı da veriliyor ve Stephen Hawking’in de uyardığı gibi insanlığın sonu onlardan gelecek.
• İş görüşmelerinde patron gibi değil, çalışma arkadaşı gibi konuşun. Zamanınızın büyük bir kısmını birlikte geçireceksiniz. Eşiniz, çocuğunuz ya da kedileriniz ile çok daha az görüşüyorsunuz. Hadi çocuk neyse de, eşinizi seçerken bile “birlikte geçireceğiniz zamanın huzurlu olması” şartını aradığınızı unutmayın.
• Sinirli olduğunuz ya da çok neşeli olduğunuz gibi yüksek duygu durumlarınızda görüşme yapmaktan ve karar vermekten mümkünse kaçının.
• Çok bilindik ve klasik olacak ama sizin aradığınız teknik yeterlilik ile ilgili herşeyi tam olarak ve çok iyi bildiğini iddia eden kişileri işe almayın. Yalan söylüyorlar. Piyasada Photoshop ve 3DS uzmanı olup da SAP’de modül desteği verebilen, ABAP’ta kendisini aşmış ve .NET ile SQL Server’a, Python ile mongoDB’ye “takla attırmasını” bildiğini iddia eden bir çok CV var. *nix sistemlerde her daim bir root, Windows’ta ise Sys.Admin olmaları da büyük artı belki. Swift’te 10 yıllık tecrübeleri olması kendilerini bir adım öne çıkarsa da, Android’de sadece 8 yıllık tecrübeli olmaları sizi şüphelendirebilir. (İş arayanlara not: Bu tip bir özelliklerde birisini arayan bir iş ilanı görürseniz de o firmayı bir şekilde bloklayın)
• Dürüst olun görüşmede. Dürüst olmaktan kastım acımasızca dürüst olmak. Pembe bir tablo çizmeyin kesinlikle. Beyaz yalanlar bile söylememeye çalışın. Gerçekleşmesi çok düşük ihtimalde olan vaatlerde asla bulunmayın. Gücünüzün sınırlarında olan konularda istekler gelirse bunları ne kadar gerçekleştirebileceğinize bakın. Eğer gerçekleştiremeyeceğinize dair bir şüpheniz varsa bunu paylaşın. Sırf “eleman alımını gerçekleştirmek” ile siz bir üst makamın gözünde iyi görüneceksiniz diye insanları boş vaatler ile oyalamayın.
• Bilmediğiniz bir teknik alanda iş arkadaşı arayışı içindeyseniz, mutlaka o konuyu iyi bilen birisinden destek alın.
• Zaman zaman, ekip içindeki konum olarak daha alt düzeyde bulunan bir ekip arkadaşınızı da görüşmelere alın. Bu hem başvuran kişinin gireceği ekibi biraz daha nesnel tanımasına, hem de ekip içindeki arkadaşınızın IK konularında kendisini eğitmesine destek olacaktır. Örneğin bir Jr. Developer arıyorsanız, o güne kadar iş görüşmelerinde hep masanın diğer tarafında oturan bir Mid.Level Developer arkadaşınızı yanınızda bulundurun. Onun da soru sormasına fırsat verin.

Bu tavsiyelerim ya da hayallerim tabi ki benim her zaman yapmayı başarabildiğim şeylerden öte, yapmak istediklerim. Birçoğunu şimdiye kadar uygulayabildiğimi düşünüyorum ama tam anlamı ile her maddeyi gerçekleştirdiğimi söylemek “beyaz bir yalan” olur. Acımasızca dürüst olmadığım zamanlar oldu.

Şef aşçı olmak zor. Benim becerebileceğim bir şey değil. Sanırım bu yüzden yazılımcı oldum…

The post Bir CTO işe alım yapıyor! appeared first on mirmirik.net.

Bizler (teknik proje yöneticileri, mimari tasarımcılar, IT direktörleri, yazılım geliştirme müdürleri, iş analistleri, yazılımcılar), bilişim çalışanları olarak genelde sadece yaptığımız işin bizlere verdiği tatmin duygusu ile işlerimizi yapıyoruz. Bu ego tatminlerimiz gerektiği gibi olduğu müddetçe de yapılan işi olması gerektiğinden çok daha iyi yapıyor ve başarılı sayılıyoruz. İşin sonucunun şirketi nereye getireceği, ne şekilde satışları arttıracağı ya da şirket olarak tanınırlığımızı nereye getireceği ile pek ilgilenmiyoruz. Açıkçası, pek de umurumuzda değil aslında bunlar. Satışın ya da pazarlamanın isteklerini karşılayabilmek için sizler gibi düşünmemizi, tam olarak sizler gibi P&L⁵ gözetmemizi, müşteri memnuniyetini %100 seviyesinde tutmamızı ya da satış grafiğinin her zaman bir önceki döneme göre pozitif olarak büyüme trendinde olmasını hedeflediğimizi görmek istiyorsunuz. Cidden mi? Bunlar maalesef önemsediğimiz konularda üst sıralarda değil.

Kişisel olarak görüşüm, bundan 3 – 5 yıl sonrasındaki iş hayatında, pazarlamadan anlamayan ya da satış aktivitelerinin önemini kavrayamayan bir IT çalışanının başarılı olamayacağı yönünde. Bunun tam tersi de geçerli. Yani bir CMO⁶ eğer IT’yi ve getirilerini anlayamıyorsa, günün piyasasında iz bırakacak bir iş yapamayacaktır. Tabi bu sadece global olarak düşününce geçerli. Yoksa ülkemizi düşününce her yolun mübah olduğu ayrı bir gerçek. Buradaki 3-5 yılı ülkemiz için 12-15 yıl olarak düşünebiliriz. Yeter ki patron şirketleri 1980’li yıllarda kalmış olan alışkanlıklarını değiştirebilsin o zamana kadar.

Deneyimlerimden gördüğüm kadarıyla, bir IT çalışanının, pazarlama ya da satış ekibi ile aynı düşünce yapısında olması ile ilgili grafiği aşağıya ekledim. Buradaki “Umursama durumu”, IT çalışanının, pazarlama ya da satış ekibinin hedeflediği amacı yüzdesel olarak ne kadar içselleştirdiğini veriyor:

Şimdi, bir kaç acı gerçeği yazılı hale getirmeli sanırım bu grafik yardımı ile. Aşağıdaki maddelerde hem biz bilişim çalışanları için hem de pazarlama ya da satış ekibindeki arkadaşlar için bir şeyler var.

1. Üzgünüm ki, biz IT çalışanları henüz yeteri kadar “iş bilgisi” ile donatılmamış durumdayız.
2. Pazarlama ve satışın hedefleri ile, IT hedefleri(ego tatmini ile de doğru orantılı olarak) pek örtüşemiyor.
3. Yapılan işin şirkete sağlayacağı yarardan daha çok, teknik anlamda bizi ne kadar zorlayacağı ve bizlere ne kadar bilgi katacağı bazen çok daha önemli.
4. O andaki görevimiz ve sorumluluğumuz ne kadar fazla teknik bilgi birikimine ihtiyaç duyuyorsa, o kadar empatiden uzaklaşıyoruz.
5. Dünya üzerinde şu ana kadar geliştirilmiş ya da geliştirilmekte olan yazılımların kaynak kodları yüzlerce farklı dil ile yazılmış durumda. Lütfen bize “x firması bu işi 3 günde tamamlamış; ne kadar zor olabilir ki?” diye gelmeyiniz (bkz: List of programming languages.)
6. Hedeflerinizi matematiksel ifadeler kullanarak bize aktarabilirseniz, sizleri o kadar sever ve işi sahiplenebiliriz. Yoksa “bunu tüm müşterilerimiz istiyor” ya da “bunu yaparsak çok güzel atılımda olacağız” ifadeleri emin olun ki aramızdaki konuşmalarda bazen eğlence konusu olabiliyor.
7. En sevdiğim öngörü: “Bir kadın 9 ayda doğum yapabilir ama 9 kadın bir ayda doğum yapamaz”. Çalışan adam sayısını arttırıp, projelerin de buna doğru orantılı olarak sürelerinin daha kısalacağını söylemeyin lütfen, kalp kırıcı oluruz.
8. Sizlerin KPI’larınız ile bizlerin KPI’ları arasında çoğu zaman ciddi fark var. Satış cironuzu %20 arttırmayı hedefleyen bir proje fikrinizdeki size çok basit gelen bir fonksiyon için düşündüğünüz geliştirme zamanı, bizim aylık çözülen bug sayımızı inanılmaz ölçüde arttırabilir.
9. Şirket bütçesinde “cost” olarak büyük bir kalem olarak yer alıyoruz. Eminiz ki kuzeninizin bir tanıdığı bizlerin yaptığı işi 1/3 zamanda çok daha iyi yapabilir. Uygulamak zorunda olduğumuz süreçler ve uymamız gerektiğini söylediğimiz kurallar emin olun işi zora sokmak için değil, bir sonraki proje talebinizi daha hızlı karşılayabilmek için.
10. Yazının genelindeki “siz” ve “biz” ayrımını uzun bir süre kıramayacağız. Bunun bilincine vardığımız sürece ortak bir hedef için çok daha hızlı ilerleyebiliriz.

Kişisel fikrim: bundan 5 yıl sonra bence bir IT departmanına gerek bile kalmayacak şirket içinde(TR için bu süre iki katı). Pazarlamaya bağlı ufak bir destek ekibi olması yeterli olacak. Giderek gelişen cloud ortamı sayesinde hem “in-house” geliştirme yavaş yavaş ölecek, hem de teknik destek anlamında uğraşılması gereken konular çok azalacak. Pazarlamaya bağlı olacak bir iş analisti ve proje yöneticisi ile işlerin oldukça iyi ilerleyebileceğini düşünüyorum. Ancak o zamana kadar aramızı düzeltmek için iki tarafın da bazı ödünler vermesi gerekecek. Bizlerin “iş” anlamında bir şeyler öğrenmemiz ve şirketin hedeflerini daha çok içselleştirmemiz gerekiyor. Pazarlama ya da satış departmanları da mümkün olduğunca IT’nin süreçlerine anlam vermesi ve yönetime karşı bizleri de savunabilmesi iki taraf için de yararlı olacak gibi.

Evet; “pazar” doymak bilmeyen bir canavar ve her haftayı geçtim, her gün değişen kurallara göre oyunu oynamak zorundayız. Ama matematik hiç yalan söylemiyor. Matematik konusunda bizlere güvenin.

Ek okumalar:

3 things your CIO should know about marketing
Inside the Minds (and Personalities) of CIOs and CMOs
Are CIOs Destined to Work for the CMO?
Hey CIOs! Show Your CMO the Love
Güncelleme (29.08.2014):
Getting the CMO and CIO to work as partners

Kısaltmalar:

¹: Chief Technology Officer
²: Chief Information Officer
³: Bilişim Teknolojileri
⁴: Information Technology
⁵: Profit and Loss
⁶: Chief Marketing Officer

The post Bir CMO, IT hakkında ne bilmeli? appeared first on mirmirik.net.

Aşağıdaki görüşlerim ve uygulamalarım büyük bir olasılıkla insan psikolojisi ve bunu anlamak ile de ilişkili. Salt olarak bu kuralları doğru kabul etmek ve uygulamaya çalışmak ya empati yoksunluğunu ya da insan ilişkilerindeki çözülmesi çok zor olan ilişki ağlarını anlamamak ile ilgili olabilir. Burada yazılanları ofisinizde denemenizden sorumlu olmayacağımı tekrar söylemek istedim.

Gücünüzü öğrenin!

Her yeni konuma gelen gibi, ilk yaptığım şey kendi çevremi ve o çevredeki konumumu anlamaya çalışmaktı(bunu sadece iş yeri için sınırlamamak da lazım. Sosyal herhangi bir ortam için bu durum geçerlidir bu içgüdüsel davranış). Yeni çalışma ortamımda ilk önce çalışma arkadaşlarımı oluşturan ekipte kim neyi yapıyor ve kim hangi konulardan sorumlu araştırmasına girdim. Kulaktan dolma ve tahmin yürütme yerine bunu herkes ile birebir görüşerek yapmayı tercih ettim ki bence hem çalışma arkadaşlarınıza saygı duymanız hem de saygı görmeniz açısından en doğrusu bu. Üst yönetimin ekibinizdeki kişiler ile ilgili varsayımlarına tamamen kendinizi kaptırmanız(x şundan sorumlu, y şunu iyi bilir gibi) sizi hem önyargılı yapar hem de oluşan önyargılarınız yüzünden yanlış kaynak seçerek gerekli verimi alamaz ve belki de ileride ihtiyaç duyacağınız değişikliği yapamaz duruma gelirsiniz. Ekibinizin içindeki dinamikleri anlamazsanız, potansiyel dinamiği, sorumlu olduğunuz uygulama yararına yönlendirme şansınız olmaz. Varolan gücünüz, şirkette yöneticiler tarafından size verilen “title” ile ilgili olmaktan çok, ekip olarak sizin neyi başarabileceğiniz ile ilgili olduğuna inananlardanım maalesef. Bu yüzden “varolan güç” kavramı, benim için “ekip olarak neyi daha iyi yapabiliriz” sorusu ile bağlantılı. Bu gücü öğrenmenin en iyi yolu da ekip ile iyi iletişimden geçiyor.

Test edin!

Gücünüzü test etmenin en iyi yolu, güvenilir bulduğunuz bir projede değişim için gerekli gördüğünüz adımlardan bazılarını atmanızdır. Hani hep yürümeden önce emeklemek derler ya, onun gibi bir şey. Daha önce çalışmakta olduğunuz yerde başarıyla uygulanan bir sistem cidden mükemmel olabilir ama bunu şu anki yere “hemen” uygulamanız çok da mümkün değil aslında. Bunu kabullenin ve ufak adımlar ile başlayın. Önceki şirketimde projelerdeki planlamalar için uygulanan güzel bir sistem vardı. Bunu öncelikle ekip arkadaşlarım ile paylaştım ve onlara bu sistemin bize olacak faydalarını anlattım. Üst yönetime giderek bir projede kendi iş yapış yöntemimi uygulamak istediğimi ve bunun şirkete faydalı olabileceğini söyledim. Sonrasında da bu sistemi savunabileceğim verileri elde edebilmek için bir dolu soru sordum ekip arkadaşlarıma(x işi için sence kaç saat harcarız? Peki sence bunu da eklersek buna sence bizi ne kadar etkiler? Şöyle bir istek var y departmanından, sence yapmalı mıyız?). Daha sonra elimdeki tüm verileri test edeceğim projeye uyguladım ve projenin takibini de bu veriler doğrultusunda yaptım. Şansıma ilk deneme oldukça başarılı geçti ve hem ekip arkadaşlarım hem de işi isteyen departman ve yönetim sonuçtan memnun kaldı. Acemi şansı belki de ama matematik yalan söylemez.

Daha iyi sonuçlar elde edin!

Yöntem farklılığının başarı ile sonuçlanması sayesinde bazı şeylerin ilk etapta zahmetli olsa da daha iyi olabileceği fikri kabul görmeye başlayınca, yönteminizi tüm projelere yayın. İlk denemeniz sonucunda zaten öngördüğünüz iyileşmeyi gördüyseniz bir sonraki aşamaya geçin ve kendinize daha zorlu bir proje seçin. Yöntem değişikliğinden emin olmak ve bu değişikliğin uygulamanıza/şirketinize getireceği yararların ölçülebilir olduğunu ancak daha fazla veri ile elde edebilirsiniz. Korkmayın! Bir çok kişi yaptığınızın saçma olduğunu, zaman kaybettirdiğini, dün bitmesi gereken bir çok işin biriktiğini söyleyecektir ama yılmayın. İlk test verilerinizi önlerine atın ve bunun gücünüze güç kattığını unutmayın(güvenen ekip=güç). Bırakın bir kaç proje geciksin. Bu gecikmeleri de asla bahaneler arkasına saklamayın. Sorumluluğu mutlaka üstlenin. Yeni yöntemden dolayı gecikmeler/hatalar ortaya çıktığını ama zaman içinde düzeltilebileceğini anlatın. Buradaki “düzelecek zaman” konusunda şunu yapmanız da yardımcı olacaktır. Diyelim ki artık baskılara dayanamaz duruma geldiniz. Kolay bir projeye geri dönün ve onu gerçekleştirin. Eliniz hem daha da güçlenecek, hem de “zaman” kazanmış olacaksınız.

Elde ettiğiniz sonuçları paylaşın!

Yeni çalışma alışkanlığının sonuçlarının -alışması zor olsa dahi- matematiksel olarak daha iyi olduğuna ikna edebiliyorsanız önünüzdeki bir çok engel ortadan kalkacaktır(ki matematik yalan söylemez). Burada en önemli tutum aslında yöneticilerinizin tutumu. Türk çalışma mantığına alışmış, daha klasik yöntemleri tercih eden, günümüz söylemleri ile statükocu bir yönetim anlayışınız varsa bu adımı aşmanız çok daha zor olacaktır. Bu durumda matematiksel veriler cidden elinizi güçlendirecek ve işinizi hızlandıracaktır. Yaptığınız işlerin “ölçülebilir” veriler doğuruyor olması bu sebeple çok önemli. Daha önceden x zamanda yapılan y işi, yeni yöntemle x+4t zamanında gerçekleşiyor ama, bunun bakım maliyetinde ve gelmesi öngörülen işlerin uygulanma sürelerindeki kısalma sayesinde toplam geliştirme maliyeti 2 adam/ay kazandırıyor dediğinizde emin olun bir şeyleri başarabileceğinizi gösterirsiniz.

‘Yandaş’ toplayın(kaynak isteyin)!

Gerçekleştirdiğiniz projelerde, yaptığınız değişiklik sayesinde olumlu dönüşler oldukça, yeni yöntemleriniz daha çok saygı görecek ve kabul edilir olacaktır. Adice gelebilir yazınca ama, kendi tarafınıza çektiğiniz her kişi ile aslında yöntemi uygulamak isteyen “ekip” güçlenecek ve değişime bir adım daha yaklaşacaksınız. Yeni yöntemin her projeye uygulanması için üstünlüğünüzü lehinize çevirin. Her isteğe bunu uygulayabilmek için üst yönetime talepte bulunun. Eğer ki bunu elde edebilirseniz, bu durumda #1 numaralı adıma geri dönmeniz ve yeni gücünüzü öğrenmeniz yerinde olacak.

Değişimi gerçekleştirmek yazıldığı ya da anlatıldığı kadar kolay değil hiç bir zaman. “Bu böyle olmaz”, “bunu şöyle yap”, “ben bunun şöyle olmasını istiyorum” ya da “ben ne dersem o” tavrı ile karşılaşmanız özellikle Türkiye şartlarında çok olası. Önemli olan değiştirmek istediğiniz alışkanlıkların ne kadar yerleşik olduğunun farkına varmanız ve hangi noktaya müdahalede bulunabileceğinizi bilmeniz. Bu da bence iki temele dayanıyor. Değişimi gerçekleştireceğiniz ekibe ve ne kadar inatçı olduğunuza…

The post Alışkanlıkları değiştirmek appeared first on mirmirik.net.

Geçen süre boyunca yazılım geliştirici olarak göremediğim –daha doğrusu görmek ve anlamak bile istemediğim- onlarca sorun ile boğuştum. Yazılımcının kafasında yer alan ve dünya görüşünü de oldukça etkileyen sıfır ve bir ikilisinin gerçek hayata aslında ne kadar da uzak durduğuna daha ikna oldum belki de; bilemiyorum(Kendimi yalanlamak gibi olacak ama bence dünya hala sıfır ve bir. Bunu IT sektörü çalışanları dışında kimse de anlamıyor ne yazık ki). Yazılımcıların / IT çalışanlarının asosyal görülmesinin ya da tuhaf yaratıklar gözü ile bakılmasının bir sebebi de bu: Dünya algılarının diğer insanlardan farklı olması.

IT’nin mutfağından çıktığımda yeni ortama alışmam ilk başta çok zor geldi. Doğru matematiksel verileri doğru yöntemler ile istenilen şekilde işlerseniz, her zaman doğru sonucu bulabilirsiniz. Yani düşünseniz ya, “2+2 her zaman 4 sonucunu doğuruyor, şu müşteri neden bu 4’ün illa ki “IV” şeklinde yazılmasını istiyor ki? İkisi de aynı değil mi sonuçta?”(Bana 2+2≠4 ile gelmeyin, kalbinizi kırarım) Ya da daha sosyal ve yazılımcı tarafından hak verilmesi daha da zor bir örnek vereyim; “neden illa ki işe giriş çıkışlarımın takip edilmesi gerekiyor ve bu konudan sorumlu tutuluyorum, sonuçta bana verilen işi bana tanımlanan süre içinde bana anlatıldığı şekli ile yerine getiriyorum!” İşte bu son 7 yılda anladım ki; maalesef kazın ayağı öyle değil ve yazılımcılar aslında pek bir şey de bilmiyorlar gerçek dünyanın ihtiyaçlarına dair(böyle dedim diye alınmayın sevgili yazılımcı dostlarım; kendimden ve gördüklerimden örnek vererek genelleme yapıyorum aslında).

Konu daha da fazla dağılmadan geleyim başlığın açıklamalarına. Mutfaktan çıkıp da içeride oturan müşterinin karşısına geçmiştik değil mi en son?  Tamam. O zaman hemen şu aşağıdaki cümleleri/düşüncelerinizi bir kenara bırakmaya çalışın eski yazılımcı yeni yönetici dostlar(ben çok uzun zaman ikinci ve altıncı maddeyi beceremedim):

1. “Herkes beni ben olarak kabul etsin ve söylediklerimi bir kerede anlasın. Anlamazlarsa onların aptallığıdır”. Yok artık! Karşınızda yazdıklarınızı makine diline çeviren ve yapamadığı zaman size hatanın nereden kaynaklandığını gösteren bir yazılım derleyici yok. Karşınızda insan var ve iletişim dediğiniz nane bilgisayardaki gibi işlenmiyor(Sevgili abim Erhan Eroğlu’na saygılarımla). Söylemek istediğiniz, söylediğiniz, alınan ve algılanan adlı dört farklı sistem düşünün ve bu her sistem arası geçişte veri kaybı olduğunu kabul edin, daha rahat edersiniz. Sevdiğim bir tabir var teknolojide bilgi aktarımı ile ilgili; her zaman “anneye anlatır gibi” anlatın derdinizi. Açık, basit ve çok net olun. Sonra bu anlatımı sabır ile on defa daha yapın. Sonra bir on defa daha!
2. Asla ama asla yazılımın teknik detaylarına girmeyin. Bu artık sizin işiniz değil. (Bence şu şekilde interface yazın oradan türetirsiniz her ihtiyaç olan class’ı. Bir de şu şekilde tablo oluşturup şu şekilde çalışan bir SP çağırın.) Bu asla burnunuzu sokmayın demek değil. Yapılan işi anlamaya çalışmakta ya da işleri teknik anlamda da takip etmenizde hiç sorun yok aslında. Bir işin teknik olarak dert yaratacağını görmüş olabilirsiniz. Ama bunun yolu asla neyi nasıl olması gerektiğini çok bilmişlik taslayıp da anlatmak değil. Tartışmak, sağlam veriler ile karşılıklı doğru yolu bulmak.
3. “Bana verilen işi eksiksiz yapıyorum, bu yeterli olmalı” demeyin. Size iş verilmeyecek duruma gelmelisiniz. Siz iş üretmelisiniz.
4. “Bana söylenen bu, demek ki iş böyle olmalı” da demeyin. Çoğu zaman doğru gibi görülse de, aslında tam olarak öyle değil. Artık sizin göreviniz zaten size söylenmeyeni araştırmak, sorgulamak, bulmak, irdelemek ve bunların gerçekleşmesini sağlamak için akıllıca bir yöntem izlemek.
5. “Tüm istekler benim önüme yazılı olarak gelsin ben de bu yazılı doküman üstünde anlaşmaya varınca işe başlayayım “. Unutun bunu! Her ne kadar çalışılan kuruma bağlı olsa da, çoğu projede size eksiksiz ve PMI ya da CMII öngörülerindeki gibi bir istek listesi ile gelmeyecekler arkadaşlar. Zaten artık sizin işiniz bu dokümanı mükemmel hale getirmek. Unuttunuz mu? Siz artık yazılımcı değilsiniz, yazılımcılara iş verecek kişisiniz. O istek listesinin arzu ettiğiniz gibi mükemmel olmasını sağlamak sizin asli göreviniz.
6. “Ben zamanında her şeyi tek başıma yapıyordum, şimdi neden her görev ayrı olsun isteniliyor ki, JS de yazsın, web service de yaratsın, veri tabanına da baksın”. Bu daha çok ‘90’lı yıllarda yazılım dünyasına adım atmış ve internetin ilk sancılarını yaşamış kişilerde oluşan “kendini bir şey sanma” dürtüsünden dolayı meydana gelmekte. Saçmalamayın! Dünya çok değişti. Ekibinize yeni bir arkadaş katmak için yaptığınız görüşmeniz sırasında size bunların hepsini yapabileceğini söyleyen kişiler ile karşılaşırsanız iki durum vardır. Ya artık soyu tükenmekte olan çok ender bir tür ile karşı karşıyasınızdır ya da karşınızdaki kişi bahsi geçen tüm becerileri çok yüzeysel şekilde biliyordur ve aslında sizi çok daha zora sokacaktır. %97,32 ikinci seçenek çıkacaktır(Dikkat; küsuratlı sayı verdim).

Şimdilik burada durayım ve devamını sonraki yazıya bırakayım.

The post IT Yönetiminde Bebek Adımları – Alışkanlıklar appeared first on mirmirik.net.