Önceki yazıda biraz daha şema ve devre tasarımından bahsetmiş, işin daha çok mekanik kısmını içeren led yapının oluşturulmasını ise bu yazıya bırakmıştım. 4^3 küp için öncelikle ölçüleri düşündüm. Her katta 16 adet led olacak, karenin her kenarında da dörder adet led olacak. Her kenarı 9cm’lik bir kare işimi görecek gibiydi. Her kenarda 0.cm, 3.cm., 6.cm. ve 9.cm.’lik yerlere birer led koyarsam, 9cm^3’lük bir küp elde edebiliyor ve tahminlerime göre çok da küçük olmadığı için rahatlıkla çalışabiliyordum. Öncelikle bunun şemasını çizdim. Bu şemayı kullanarak da çalışmama yardımcı olacak ahşap üzerine 5mm.’lik çapta delikler açtım. Her katın bağlantılarını yapacağım zeminim hazırdı. Burada ufak bir dikkat. Her delik eşit derinlikte olsun isteyeceksinizdir. En kolay yolu da fotoğraftaki gibi matkabın ucuna belli bir yere bant çekmek bu gibi durumlarda. Böylece her deliği eşit derinlikte tutabilirsiniz. Bunu yaklaşık olarak ledlerin şeffaf kısımlarının uzunlukları kadar yapmanızı tavsiye ederim.

Kimi videolarda led bacakları birbirleri ile direkt olarak bağlanmış. Bu çok da güven vermedi bana. Daha sağlam bir yapı oluşturmak için bir temel ve kolon düzeni getirmek istedim. Bunun için de bakır kablo aradım ancak bulamadım evde. Elimde iki kalınlıkta alüminyum tel vardı. Kalın olanı oldukça sağlam olacaktı. Bunlardan 15’er cm.’lik çubuklar yaptım. Her katta zemin için 6 adet tel, katlar arası led bağlantıları için de toplam 16 tele ihtiyacım vardı. Toplamda 40 adet el kesmem gerekiyordu.

Öncelikle daha kalın olan 1.2mm çapındakini denedim. Yanlış seçim yaptığım tabi ki lehimlemeye başlayınca ortaya çıktı. Alüminyum teller bakır teller aksine çok zor lehim tutuyor ve bu kalınlık çok fazla geliyordu. Yaklaşık 40 teli kesmeden önce iki üç tanesi ile deneme yapmış olsaydım boşa bu kadar iş çıkmayacaktı. Başka bir yerde kullanmak için o sevdadan vaz geçtim ve 0.6mm. çapındaki teli kullanmaya karar verdim. Aşağıdaki ilk video o daha kalın tellerin kesilişi. İkinci video ise akıllanıp kısa tellere geçiş sonrası her kısa teli nasıl tam düzleştirdiğim ve daha sağlam hale getirdiğimin tekniğini gösteren video. Bu ikinci adımı mutlaka yapın derim.

Tüm teller kesildikten ve düzleştirildiğinden sonraki adım artık ilk katın lehimi idi. Dizaynınızı unutmayınız. Tüm anotlar (+ uçlar / ledlerin uzun bacakları) dikeyde birleşecek ve kolonları oluşturacak, her katot ise (- uçlar / ledlerin kısa bacakları) yatay düzlemde birleşip satırları oluşturacak. Toplamda 16 adet kolon ve 4 adet de kat çıkışı olmak üzere 20 adet çıkış kablomuz olacak led küpten. Bunun için zemine yerleştireceğimiz ledlerin anotlarını (uzun bacaklar) o kalın telden kestiğim küçük bir tele dolayıp her birisinde birer halka oluşturdum. Bu halkaları her katta üst üste getirince ve o deliklerden de dikey teli geçirince katlar arası kolon bağlantısını da kolaylıkla yapabilecektim. Aşağıdaki fotoğraflarda bunu görebilirsiniz:

Ledleri lehimlerken alüminyum gerçekten sıkıntılı. Bu yüzden ek olarak lehim pastası da kullanmak zorunda kaldım. Bu aşağıdaki videoda göreceğiniz gibi işi oldukça kolaylaştırdı. Dikkat etmeniz gereken şey elbette ledlerin fazla ısıdan dolayı yanmaması. Bu yüzden de her kat bitiminde mutlaka ledleri test ettim. Yanmış olan varsa ona hızlıca müdahale edebilmenin en iyi yolu tam bu aşama. Katları çıktıktan sonra uğraşmak zorunda olacağınız cisim artık 3 boyutlu olacağından bu test işini asla atlamayın.

Her kat yapımı bittikten sonra artık işin ciddi tarafına geldim. Dizaynıma göre mantıken tümünü üst üste koyduğumda her şey yerli yerine oturacak ve anotlar arası 16 adet bağlantıyı da yapabilirdim artık. Neyse ki milimlik kaymalar dışında bir sorunla karşılaşmadım. Çok daha iyi yapılabilirdi ancak ilk deneme için bence yeterli.

Bu aşamada da artık son bir led testi gerekiyor. Bunu da hallettim Büyük mutluluk, hiçbir ledde sorun yok.

Bundan sonraki iş de Arduino devre ile bu küpü bir araya getirmek ve ara bağlantıları da halletmek. Önceki yazıda bahsettiğim devreleri ve kabloları bir kutuya yerleştirmeye karar verdim. Evde eski bir parfüm şişesi kutusu buldum. Üstünü siyah sprey boyayla boyadım ve hazır olan delik şemam ile yaklaşık 1mm.’lik delikler deldim. Küpün tüm bacaklarını bu delikli kapaktan geçirip kutunun kendisini de Arduino devresi ve kabloları için ayırdım. Tüm bağlantıları ilgili bacaklara yaptım. Buraya kadarki tek başıma çalıştığıma küfrettiğim tek aşama sanırım bu kutudaki deliklere küpün 16 telini de aynı anda geçirebilme aşamasıydı. İki kişi olursanız daha rahat olacaktır. Devre ile küp bir araya geldiğine göre artık kod ile testlere başlayabilirdim.

Buraya kadar sabredip okuduysanız şu sonuç videosunu da izleyip isterseniz işe el atabilirsiniz. Ben yıllar sonra böyle bir şeye bulaştığım için çok mutlu oldum ve tüm yapım aşamasından zevk aldım. Özlemişim bu tür “challenge”ları. Özellikle “old school” elektronik konusunda bilgilenmek için sevgili arkadaşım Fırat Tarman’ın Teknomani – YouTube kanalına abone olmayı ve takip etmeyi unutmayın. Sevgiler.

The post Arduino ile Led Küp 4X4X4 – Bölüm 2 appeared first on mirmirik.net.

Arduino ile farklı bir cihazı kontrol edecek kod yazmak oldukça basit ve çok fazla kaynak var elinizin altında. Biraz da merakınız varsa hemen her şey hakkında bilgi sahibi olabiliyorsunuz. Ben genelde YouTube kanallarından ve kullandığım komponentlerin üretici sayfalarından öğrendim gerekli gördüğüm bilgileri. Led küpler ile ilgili de çok fazla değişik metot ve uygulama var. 4^3 küpler için genelde de 20 adet dijital çıkış pinlerinin tamamının kullanıldığı Arduino Uno kullanılmış. Bunu aslında “shift registerlar” kullanarak (74HS595 gibi) Wemos, Nano vb. daha az çıkış pinine sahip Arduino mikroişlemciler ile de yapabilirsiniz. Gördüğüm çoğu tasarımda klasik led kontrollerinde olduğu gibi digital I/O pinine 220Ω – 330Ω’luk direnç takılmış ve direkt küpteki ilgili led için beslemeler yapılmış. Bir tanesi ise (ki hiçbir işe yarar dokümanı ya da anlatımı da yoktu) katları beslemek için 4 adet 2n2222 NPN transistör kullanıyordu. Akımı da güçlendirdiği ve daha sabit bir kontrol sağladığı için bunu tercih ettim. Benim yaptığım tasarımda dikkat edilecek tek şey diğer onlarca örnekteki gibi ledlerde katotların (negatif uç) değil, anotların (artı uç) birbirlerine bağlanması ve katotların ise satırları (katları) besleyecek şekilde bir araya gelmesi. Yani sonuçta elinizde 16 sütun için “+” sinyal ve 4 katlı tasarım için de 4 farklı “-” sinyal göndereceğiniz 20 uçlu bir led tahtanız olacak. Şema ve tasarımı anlattıkça ne demek istediğimi daha iyi anlayacaksınız.

Devre tasarımlarımı EasyEDA Standard Edition kullanarak yapıyorum. Benim için oldukça kolay kullanıma sahip ve erişilebilir bir uygulama olduğu için tercih ediyorum. CircuitMaker ve KiCAD de denedim ancak nedense onlara ısınamadım şimdilik. Neyse. Her şeyden önce devre tasarımını bir ortaya koyayım. Buraya tıklayarak da PDF halini indirebilirsiniz.

Bu şemada en solda elimdeki Arduino Uno’da kullanılan Arduino Mega 32P çipi var. Bunun çıkışlarını evde atıl durumdaki eski IDE disk bağlantı kablosuna bağlayıp bir şekilde 20 dijital çıkışı iletmek istedim. Gereği yok bunun. Lehimleme işini biraz daha uzatıyor sadece. Şöyle bir board üzerine gerekli lehimlemeyi ve kablolamayı yapıp, Arduino’yu erkek header’lara çıkış verecek şekilde devreyi tamamlayabildim sonuçta. Bu fotoğraftaki kısım şemanın sol tarafındaki mikroçipi, transistörleri, dirençleri ve 20’li pini gösteriyor. Kartımız hazır:

Bu kısım ve IDE kablosuna bağlantı kısmı tamamen işi zora sokmak için diyebiliriz. Sürücü birim ile(Arduino) alıcı birimi(ledler) birbirinden bağımsız tasarlayabilme özgürlüğü gibi düşünebilirsiniz. İleride farklı bir şey için bu 20 pinli çıkışı kullanmak istersem tek yapmam gereken sürücü devreyi kablodan çekmek olacak. İşe yarayabileceğini düşünüyorum. Devre yerleşim yerini bir PCB yerine delikli pertinaksa yapacağım için kendime bir rehber oluşturmaya gereksinim duydum. Belki onlarca daha basit yolu ve uygulaması vardır ancak üşengeçliğimden dolayı eski dost Excel’de şöyle bir şey yaptım tüm kablo bağlantılarını net görebilmek için. Oldukça da işime yaradı bazı kararlarımda. Bunun uygulamasını bilen varsa ve yazarsa sevinirim.

Sonuçta IDE kablosu bağlantısını da alıcı bir erkek header’ın olduğu board’a götürmem gerekiyordu, bunu da şu şekilde yaptım:

Bu iki modül IDE kablo ile birleşince de şöyle bir görüntü ortaya çıktı:

Buraya kadar tüm çıkış / giriş testlerimi ve özellikle çok küçük bir alanda lehimleme yaptığım için kısa devre testlerimi de gerçekleştirdim. Tümünden geçti iki board da. Artık led küpün asıl ağır işçilik kısmına geçebilirdim. Led küpün tasarlanması ve birleştirilmesi konusunu diğer yazıya bırakacağım. Becerebilirsem yapım videolarını da ekleyeceğim. Umarım herkese faydalı olur. Sorusu olan olursa bkz: @mirmirik… Twitter’da konuşalım.

Yazının devamı için bkz: Arduino ile Led Küp 4X4X4 – Bölüm 2

The post Arduino ile 4x4x4 Led Küp… appeared first on mirmirik.net.

“Ü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.

Neredeydim, ne oldu?

2018 Mayıs ayında, uzun yıllardır arkadaşım olan ve her yıl gösterime giren yeni nesil Star Wars filmlerinin geceleri yapılan ilk gösterimini beraber izlediğim sevgili Barış Sarıalioğlu ile birlikte bir hayali gerçekleştirmek için adım attık. Bu oldu. Emekliliğimi alacağımı düşündüğüm ve bu yola da baş koyduğum TesterYou isimli firmanın bir neferiyim ben artık. Tüm gecem ve gündüzüm sadece burada. Genelde tüm yazılım yaşam döngüsündeki süreçlere, özelde ise yazılım test süreçlerine danışmanlık ve eğitmenlik yaptığımız bir oluşum kurduk. Çok güzel oldu. Daha da güzel olacak.

Hem bu işin getirdiği yeni öğrenmeler, hem de alışkanlığımdan dolayı yaptığım okumalar ve araştırmalarda, karşılaştığım şey tekrar şu oldu. Yazılım dünyasının kalite anlamında çok fazla eksiği var ve bu eksikliklerin ana unsuru da, bu geliştirmeyi yapan bizler ve bizlerin sahip olduğu rasyonel olmayan tutum ve tavırlarımız. Evrimimiz bizleri bu güne kadar getirdi ve en azından dünyaya hükmeden “en zeki” canlı türü olarak sağ kalabildik. Gelişen teknolojiyi yarattık, kullanır hale geldik ve geliştirmeye de devam ediyoruz. Bakılan açılara göre “çok şanslı bir çağda” ya da “tamamen şanssız bir çağda” yaşıyoruz. Yazılım yaşam döngüsündeki kişiler olarak (analistinden son kullanıcısına, geliştiricisinden proje yöneticisine, ‘creative ajans görevlisinden’ CTO’suna kadar herkes bu döngüde diye düşünelim), bu geliştirmelere ayak uydurmaya çalışıyor, işimizi ‘en iyi şekilde’ yapmaya çalışıyoruz. Ama hala bir şeyler tam da olması gerektiği gibi olmuyor. Bunun sebebi sadece süreçte kurallar olmaması, kurallara uymamak, araç eksikliği olamaz diye düşünüyorum. Yazılım geliştirme işinde her ne kadar “sayısal” iş yapılsa da,  insan dediğimiz canlı türü, savanada canlı kalmak için 200.000 yıldır geliştirdiği beyinsel becerilerin etkisi altında hala. Bu etkilerin izlerinin yazılım dünyasında ne kadar etkili olduğunu merak ettiğimden, altta yatan “insan faktörü” konusunda daha fazla araştırma yapmaya karar verdim. Bazı bulgularımı İngilizce olarak şirketimizin sitesinde bir blog post olarak yayınladım. Bu yazı da, hem onun Türkçeleştirilmiş hem de daha kişiselleştirilmiş hali olacak. Başlayalım bakalım…

Yazılım Kalitesi

Yıllar içinde, yazılımın kalitesinin ve doğru çalışmasının onaylanması sayılan testler, sadece son dakikada “bug” bulup bunları raporlamaktan, “hata meydana gelmeden önce önleme”ye doğru evrilmiş durumda. Bunda, yoğunlukla kullanılan “Waterfall” proje yönetim metodolojisinden “Agile” yönetim süreçlerine geçişin de etkisi çok büyük. Hala tersini yapan bir çok yazılım evi/birimi de var ama, gelişme gözle görülür bir şekilde iyi yönde.  Yazılım geliştirme yaşam döngüsünün (SDLC¹) analiz gibi ilk safhalarında başlayan testler, hem kalitenin artmasını sağlamakta, hem de ürünün piyasa başarısızlığını engelleyecek adımları atmaya yardımcı olmakta. Yazılım yaşam döngüsü içindeki hemen herkes (analistler, geliştiriciler, proje yöneticilerileri, test uzmanları ve üst düzey yöneticiler), testlerin, henüz geliştirme bile başlamadan önceki zamanlarda başlaması konusunda hemfikir.

İlk zamanlarda daha çok manuel olarak yapılan testler, gelişen teknoloji ile birlikte onlarca araç tarafından desteklenir hale gelmiş, otomasyon araçları ile iş yükünden tasarruf edilmiş, süreç iyileştirmeleri ile daha güvenilir düzeye getirilmeye çalışılmıştır. Artık geliştiriciler, “test” konusunda daha eğitimli ve bilinçli, ürün yöneticileri (ve proje yöneticileri) test etmenin önemini önceye göre daha iyi kavramış durumda. Tüm bu gelişmeler karşısında ise hala bir gerçek var: Ürün, kullanıcı kabul testine(UAT²) geldiğinde ya da daha da kötüsü piyasa çıktıktan sonra onlarca bug barındırmakta ve ürün ve üretici şirket imajı da bu durumdan çok kötü etkilenmekte. İki soru hala aktif olarak şirketin koridorlarında dolaşmakta: Neden böyle oldu ve bu kimin suçu?

Akıllı olan ekipler, böyle bir durumda kendi test süreçlerini kontrol eder, hangi noktada ne tür eksiklikleri olduğunu anlamaya çalışır, performans ya da otomasyona yönelik test araçlarını kullanılıyorlarsa da, o araçları kalibre eder, tüm bunlara bağlı olarak da belki ekip üyelerine daha fazla eğitim verme yönünde seçim yapar. Daha da akıllı hareket eden ekip üyeleri ise bunların tümünün üstüne bir de kendi içlerine, o bizi onbinlerce yıl hayatta tutmuş olan beyinsel işleyişlerimize bakar: Bilişsel önyargılarımız!

Bilişsel Önyargı

Vikipedi Türkçe sayfası (evet, 2019 yılında sadece VPN ile girilebiliyor hala), bilişsel önyargıyı, “diğer insanlar ve durumlar hakkında mantıksız olabilecek çıkarım sapmaları için kullanılan bir kalıptır. Bireyler ellerindeki mevcut girdiler neticesinde kendi nesnel sosyal gerçekliklerini yaratırlar. Öznel girdi yerine, bir bireyin kendi yarattığı sosyal gerçeklik inşası sosyal dünyadaki davranışlarını da dikte edebilir. Böylece, bilişsel eğilimler bazen algısal bozulma, yanlış yargı, mantıksız yorumlama ya da geniş anlamıyla mantıksızlığa (irrasyonalite) yol açabilir.” olarak tanımlamakta. Uzun lafın kısası: “kendi bilinciniz ile oluşturduğunuz önyargılar, sizlerin mantıklı davranışlarınızı kısıtlayabiliyor ve yanlış eğilimlerde bulunabiliyorsunuz“. Ya da bu süslü cümleleri “anneye anlatır gibi” anlatmak istersek; “her birimiz, insan beyninin işleyişi yüzünden, mantıksız ve farkında olmadığımız davranışlar içinde bulunabiliyoruz“.

Eğer bu son cümleye karşı çıkıyorsanız size bir sürprizim var. Buna karşı çıkıyor olmanızın sebebi, “yanılgı kör noktası” (bias blind spot) denilen bilişsel önyargınızdan kaynaklanıyor olabilir. Başkalarının önyargılı davranışlarını, kendi davranışlarımıza göre çok daha hızlı görebilme kusurudur belki de.

Yazılımın testi benim gözümde hem bir sanat hem de bilim olan bir meslektir; temel olarak yazılım özellikleriyle ilgili seçimleri yapma, seçimleri gözden geçirme, değerlendirme ve sonuç çıkarma üzerine oluşan bir meslek. Yazılım testi mesleği ayrıca testleri oluşturma, uygulama ve test sonuçlarının analizi aşamaları boyunca bilişsel önyargıya çok fazla maruz kalmaktadır.

Yazılım test süreçlerini, testleri ve kalite ekiplerini etkileyebilecek birçok bilişsel önyargı türü olduğunu düşünüyorum. Bu konuda yapılacak araştırmaların hem yazılım hem de yazılımcıların kalitesini olumlu ölçüde değiştireceğine inanıyorum. Ben küçük bir katkı olarak, yeni işimizdeki danışmanlık hizmetlerimiz sırasında karşılaştığımız ikisini yazının devamında özetlemeye çalıştım.

1. Doğrulama Yanlılığı (Confirmation Bias)

Tanım: Doğrulama yanlılığı ya da teyit yanlılığı, kişilerin kendi inançlarını, düşüncelerini ve varsayımlarını destekleyen ya da teyit eden bilgileri kayırma, dikkate alma ve öne çıkarma eğilimidir. Bu yanlılığa sahip kişiler inançlarına, düşüncelerine ve varsayımlarına ters düşen, karşı duran, onlarla çelişen bilgileri ihmal etme, yok sayma eğilimi gösterir.

Genelde oluşturulan test senaryolarının “Pozitif Testler” üzerinden gitmesine yol açtığını görüyoruz. Yazılan test senaryoları çoğunlukla, yazılmış olan “analiz” ya da “gereksinim” dokümanlarına bağlı olduğu ve analiz dokümanları da çoğunlukla pozitif ifadeler içerdiği için -doğal olarak- sistemin “ne yapması gerektiğine” daha çok odaklanıyoruz. Pozitif test bizim aklımızdaki senaryoyu da doğrular nitelikte olacağı için, test için kullandığımız verileri bile “doğru sonuç vermesi” için değiştirebiliyoruz.

Bir konuda geçmiş deneyimlerimiz doğrultusunda fikrimizin ve belirli bir örgüdeki “bakış açımızın” olmaması neredeyse imkansız. Bunu yazılım testleri sırasında kendi dünya görüşümüze ve bakış açımıza uygun arayışlar ile yapıyoruz. Hesap makinesi yazılımını düşünün. Gereksinim dokümanında, ekrandaki iki alana girilen rakamların toplanılarak bir “label”‘da sonucun gösterilmesi gerektiği yazıyor diyelim. İki tane textbox var ve biz doğal olarak gidip oraya “nümerik değer” yazıyoruz. Çünkü zihnimiz yıllarca, hesaplamanın rakamlar üzerinden yapıldığını öğrenmiş durumda. Rakamları girip de sonuca baktığımızda ve doğru toplama yapıldığını görünce de testten geçmiş olduğunu varsayıyoruz.

Benzer şekilde, gereksinim dokümanındaki “şifrenin en az 8 karakter olmalıdır” isteği için, test senaryosuna “şifrenin en az 8 karakterli olması gerektiğini” test edecek adımı koyuyoruz ve “olması gerekeni doğruluyoruz. Peki ya en fazla kaç karakter koyabiliyoruz? Veri tabanı oraya 1024 karakter eklesek de izin verecek mi?

2. Sürü Psikolojisi (Bandwagon Effect)

Tanım: Bir yığın kurallar ve koşullar dizisiyle temellenmiş belirli inançların, bir grup, topluluk, ülke vs.’nin (siz bunu IT ekibi ya da agile ekip olarak da düşünün) insanları arasında yayılmasına verilen addır.

Ortak tutuma başvurma safsatası ile de ilişkili olan bu kolaycılık görüşümüz, genelde ekiplerin içindeki otoriter ve yetkin kişilerin fikirlerinin ekip içinde kabul görmesi ve yaygınlaşması ile kendini ortaya çıkardığını gözlemledim. Sprint planlama toplantılarınızdaki “Story Point”‘lerin belirlenmesini düşünebilirsiniz. Ekip içinde yeniyseniz, ne kadar bilgili ve tecrübeli olduğumuza bakmaksızın baskın görüşe doğru yönleniyoruz. “Büyük çoğunluk bu şekilde düşünüyorsa, büyük ihtimalle ben yanılıyorumdur” gibi davranıyor beynimiz. Bu da yanlış bile olsa bazı kararlara katılımımızı sağlıyor.

Benzer şekilde, ekip içinde bir modülün / fonksiyonun hata çıkarmayacağına dair yaygın bir inanış varsa bu modül üzerinde yazılan ya da koşulan test sayısı da düşmekte. Bulunan hatalar bile, baskın inanış bunun aksini söylediği için, kimi zaman göz ardı edilebilmekte (yine, “büyük ihtimalle ben yanlış bir şey yaptım” görüşü baskın geliyor test eden kişiye).

Test uzmanı bir arkadaşta gördüğüm bir davranış biçimi de şu şekilde oldu. Bir ekipte yeni olan test uzmanı, grup içinde kabul edilebilirliliğini arttırmak için, kendisine “bunu bug olarak raporlama, ben hallederim” şeklindeki telkinlere uymaya başlayıp, aslında yazılımın kalitesinden ve ekip içindeki test olgunluğunun yükselmesinden taviz verdi. Ekibin performans ölçüm kriterlerinden birisini “bulunan bug sayısı” olarak koymak, bu türden yanlışlıklara da yol açabiliyor.

Özet

Bilim insanlarına, araştırmacılara ve psikologlara göre karar verme sürecini kendimiz için kolaylaştıran, bizlerin günlük yaşamını etkileyen düzinelerce önyargı var. Bu önyargıların çoğu inanç oluşumunu, ticari ve ekonomik kararları ve genel olarak insan davranışını etkilemekte. Test uzmanları ve kalite ekibi üyeleri olarak, bu önyargıların üstesinden gelmenin kolay bir yolu da yok. Ne de olsa hepimiz insanız, robot değil. Yapabileceğimiz şey, bu önyargıları bilmek ve kabul etmek, irrasyonel davranışların sonuçları hakkında açık fikirli olmak ve şartların gerektirdiği şekilde değişiklik yapmaya istekli olmaktır.

Kısaltmalar, tanımlar

1. SDLC: Software Development Life Cycle, Yazılım Geliştirme Yaşam Döngüsü. Yazılımın, istek oluşma anından başlayıp, analiz, geliştirme, test ve piyasaya sürülmesi süreçlerinin tamamını kapsayan döngü.
2. UAT: User Acceptance Test, Kullanıcı Kabul Testi. Özne olarak yazılımdaki gereksinimleri ve istekleri belirleyen kişilerin geliştirici ekip ile birlikte yaptığı testler.
3. Test senaryosu: Uygulama parçasının doğru çalışması ve istenilenleri doğru yaptığının görülmesi için yazılan adımların ve her adım için beklenen çıktıların tutulduğu şablon.

Yararlanılan Kaynaklar

1. Yalansavar Web Sitesi (http://www.yalansavar.org)
2. Şebnem Özdemir, Buster Benson’un “Cognitive Bias Cheat Sheet” çevirisi (https://medium.com/@behavioralist/buster-bensonun-cognitive-bias-cheat-sheet-t%C3%BCrk%C3%A7e-versiyonu-22baf8e0a5)
3. 18 Cognitive Biases You Can Use for Conversion Optimization. Shanelle Mullin, October 15, 2015. (https://conversionxl.com/blog/cognitive-biases-in-cro/)
4. Wikipedia, List of cognitive biases yazısı, (https://en.wikipedia.org/wiki/List_of_cognitive_biases)
5. Fuqun Huang (June 21st, 2017). Human Error Analysis in Software Engineering, Theory and Application on Cognitive Factors and Risk Management, Fabio De Felice and Antonella Petrillo, IntechOpen, DOI: 10.5772/intechopen.68392. (https://www.intechopen.com/books/theory-and-application-on-cognitive-factors-and-risk-management-new-trends-and-procedures/human-error-analysis-in-software-engineering)
6. Oswald, Margit E.; Grosjean, Stefan (2004). “Confirmation Bias”. In Pohl, Rüdiger F. Cognitive Illusions: A Handbook on Fallacies and Biases in Thinking, Judgement and Memory. Hove, UK: Psychology Press. pp. 79–96. ISBN 978-1-84169-351-4. OCLC 55124398.
7. Kullanılan fotoğraf: Leonard von Bibra on Unsplash

The post Yazılım testlerinde bilişsel önyargılar 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.

Kaldığımız yerden devam edelim. Bu yazıyı kısa tutup, “in your face March mirmirik” diyelim.

En son “Yazılımcı / Uzman yazılımcı” konusunda ahkam kesmiştim. Bu konuda ve öncesindeki “Stajyer” ve “Jr. Yazılımcı” konularında yazdıklarımda hala haklı olduğumu düşünüyorum. Bu konularda fikrimi değiştirecek bir gelişme göremedim geçtiğimiz dönemde. Bu yazının konusu da “Teknik lider” ya da “Ekip lideri” adı verilen titre ile ilgili olsun. İçimi bir dökeyim. Oradaydım, bu işi de yaptım.

4. Teknik Lider, Ekip Lideri

Gerçekler: Ekip lideri / teknik lider kavramlarına bir açıklık getirmekte fayda var. Benim fikrimce, ekip lideri kod yazmayan, teknik konulara mümkün olduğu kadar uzak duran, daha çok ekibinin İK problemleri ve projelerin yürütülmesi ile uğraşan birisiyken; teknik lider tam tersine yazılımın mimarisi hakkında da söz sahibi olup, ilgili “core” kodları yazan, yazılımın ana şeklini oluşturan ve bu konularda da haleflerine yol gösterici olan kişidir. Evet, sevgili ülkemizde bu iki titre de ramazan çadırlarında dağıtılan yemeklere dönmüş olsa da, bu benim kişisel görüşüm. Yine önceki konuda belirttiğim, herkesin “senior olması” gibi kendisinden 1 ya da 2 yıl tecrübesiz herhangi iki kişi ile birlikte çalışan çoğu arkadaşım ya “ekip lideri” ya da “teknik lider” ve hatta çoğu zaman her ikisi birden oluyor.  Liderlik başlı başına çalışılması, üzerinde akıl yürütülmesi, ciddi anlamda “pişilmesi” gereken ve sosyal tarafı da ağır basan bir kavram iken hem ekibin hem de teknik gelişmelerin lideri olan arkadaşlar ile karşılaştıkça gözlerim doluyor (Tamamen yalan. Profesyonel bir empati yoksunu olarak hiç bir şey hissetmiyorum tabi ki).

Gereken: Benim, ekip ve teknik liderlik kavramları ile ilgili görüşüm şu şekilde görselleştirilebilir sanırım:

‘Teknik Lider‘ dediğimiz kişi daha çok ekibin içinde olan ve geliştirmeye de yardımcı, ‘Ekip Lideri‘ ise geliştirme ekibinin görev tanımlarının biraz daha dışındaki bir kişi. Tabi ki teknik lider iş birimleri ile konuşuyor ve tabi ki ekip lideri de geliştirme ekibi ile dirsek temasında. Ancak her iki işi de yüklenmeye çalışınca -ya da işte, üst yönetim tarafından yükletilince- işler sarpa sarabiliyor. Atılması gereken adımların çoğunun yönetim kademesinden gelmesine inanıyorum yine. Tamam, uzman yazılımcı arkadaşlar yine liderlik için kendilerini zorlasın ama onlardaki yatkınlık seviyesini ölçemeyen ya da farkına varamayan yönetim kademesinin sırf “title dağıtmak ile” geleceğe yatırım yapmadığını bilmesinde fayda var.

Kişisel eklenti: Çoğu zaman gördüğüm şu oldu. Şirkette uzun yıllardır bir projede çalışan arkadaşın niyeti/isteği/yeteneği göz ardı edilip sırf bir “title” vermek için, ekip lideri ünvanı veriliyor. Kadın (ya da adam) aslında teknik olarak profesyonel iken, üzerine bir de uğraşması gereken ve hiç de zevk almadığı onlarca İK problemi de ekleniyor. Bu durumun da iki çetrefilli derdi var. Teknik anlamdaki birisinin ne yazık ki “sosyal becerileri” biraz düşük olabiliyor (bende öyleydi diye herkeste olmak zorunda değil ama dediğim gibi: ‘gördüğüm bu’). Ekip lideri dediğimiz arkadaş da, proje yönetim, İK konuları, yönetimsel konularda doyurucu olsa bile, teknik konulara #muffinbey‘in kırmızı ete duyduğu sevgi kadar uzakta durmayı seçebiliyor. Bu konu da hem onun geliştirme ekibi içindeki saygınlığını yerle bir ediyor hem de ekibi olması gerektiği gibi yönetemediği için verim kaybına sebep oluyor.

Bugün yaptığım işten mutsuz olsam, ben kurumsal bir yere döneyim, her ay maaşımı rahat rahat alayım, emeklim/sgk’m olsun baş göz olayım, evlenip çoluk çocuğa karışayım bari desem “teknik liderlik” yapabilme kapasitem bunca yıllık iş birikimime rağmen yok örneğin. Bugün teknik liderlik yapabilecek durumda hiç değilim, çünkü “bilmiyorum”. Günümüzün teknolojik gelişmelerine çoğu yazılımcı arkadaşım kadar yatkın değilim ne yazık ki. Uzun yıllardır yazılım projelerinde “hands-on” görev almadım ve bu bana teknik bilgi anlamında çok şey kaybettirdi. Öylesine bir seçim ile, R, React, NodeJS, Python, jQuery kütüphaneleri ve/veya geliştirme dillerini, Docker/AWS yapılarının veya bu dillerin avantaj ve dezavantajlarını, küçük performans ipuçlarını kişisel olarak deneyimlemediğim için “teknik anlamda” ekipteki arkadaşlara çok şey katamam. Ama “ekip lideri” olarak hala işe yarayabilirim. Çünkü bu konuya diğerinden daha çok eğildim ve bu konuda kendimi de eğittim. Ekipteki hangi arkadaş erkek ya da kız arkadaşından ayrılmış, kimin evinde ev arkadaşı (ya da ailesi) ile ilgili bir problem var, hangi “manager” pozisyonundaki ekipteki kime ne şekilde baskı yapıyor, kimin iş yerindeki çay yapım saatleri ile ilgili bir sıkıntısı var sorularının cevabı bende olmak zorunda (dedikodu ile ilgili değil bunlar) ve bu konuların hiçbirisinin benim NodeJS sunucusunun nasıl başlatılabileceği ya da yeni bir Conda ortamının nasıl kurulabileceği ile ilgisi yok (zevkli konular, o ayrı).

Biterken çalıyordu:

The post Yazılımcı maskesini çıkarıp yönetici olmak / III 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.

Hobi olarak gördüğüm 1990-1998 arası zamanlarımı saymazsak, 1998 yılında profesyonel olarak başlayıp, uzun yıllar sürdürdüğüm yazılım geliştiricilik maskesini çıkartıp, işin daha çok analiz kısmına ve proje yönetimine girmeye başlamam 2007 yılına dayanıyor. Restoranın mutfağından çıkıp içeride oturan müşteriler ile birebir ilgilenmeye başlayalı 10 yıl kadar olmuş(Restaurant, şef ve aşçı ve yazılım ekipleri arasındaki benzeşimlerin geçtiği yazı “Bir CTO işe alım yapıyor” adında 2014’te yazılmıştı). Neredeyse 20 yıldır, çatışmalarım, yanlışlarım, bilgisizlikle hareket ettiğim zamanlar olmasına rağmen çalıştığıma, iş ile ilgili konularda gerektiği gibi davrandığıma, özel hayatımdan da ödün verdiğime ve şu anki mutlu iş hayatıma kavuştuğuma inanıyorum. Bu yüzden “yazılımcıdan yönetime geçiş” konusunda biraz ahkam kesme hakkı görüyorum kendimde.

Yönetim süresi kapsamında, öncelikle uluslararası bir bankadaki yazılım grubunda teknik proje yöneticiliği (ki iş için aktif olarak kod yazdığım son dönemdi), sonrasında da zamanının en başarılı yazılım firmalarından birisinde sırasıyla proje yöneticiliği, IT takım yöneticiliği ve IT yöneticiliği yaptım. Devam eden yıllarda, öncelikle, ana işi yazılım üretim tarafının dışındaki bir e-ticaret firmasında ve sonrasında uluslararası bir ödeme ve para gönderim şirketinde IT direktörlüğü görevlerinde bulundum. Tamamını bırakıp kendi işime sarılmam ve Türkiye’deki girişim firmalarına destek vermeye başlamam da 2 yıl kadar olmuş. Bu geçen sürede deneyimlediğim Türkiye’de yazılımcıdan yöneticiliğe geçiş sürecinin neden sancılı olduğunu ilk elden görme fırsatım oldu. Bu iki yazı, benim “samimi olan”  özgeçmişim olacak (Neden özgeçmişime döndüğümü inanın ben de çok bilmiyorum. Devam edeyim bakalım, bağlayacağım bir şekilde)

Hayatı bir ve sıfırlar ile geçmiş kişiyi alıp, ona “hadi bakalım sen şimdi bu yazılım işlerinden yavaş yavaş elini eteğini çek, ekip bu, onlara liderlik et, al bak şu işi geliştir, ekip yarat, gençleri eğit ve onları yönet” denilince, hele bir de “ego” yüksekse ve bir de “title” verilmişse durum ilk başta şöyle olabiliyor:

Kendimizi kuzeydeki kral gibi hissederken, gözden kaçırılan bir çok şey oluyor. Bendeki sorun teknik anlamda doyuma ulaştığımı ve çok iyi kod yazdığımı sanmam, bunun ekip yönetimi için yeterli olacağını düşünmem ve sanırım yönetim kademesindeki bir kişide olması gerektiğinden çok daha fazla egoya sahip olmamdı. Her şeyi kendi yapmaya alışmış, en küçük detaya kadar ben bilirim fikrindeki, her teknik şeye burnunu sokan ve tam bir “mikro-management” yönetim sürdüren birisinin, yönetimsel problemlerin tümünün birden altından kalkamayacağı aşikar aslında. Zor yollardan öğrendim bunu. Bir kaç konuya dikkat edilmezse, aşağıdaki duruma gelmek inanın ki bir ay bile sürmüyor:

Sevdiğimiz ve saydığımız sevgili Jon Snow’un konuya özgü iki durumunun da tam olarak içinde bulundum ilk zamanlarımda. Tecrübe kazanmam, alışkanlıklarımı ve yöntemlerimi değiştirmem gereken onlarca durum vardı. Olaylara teknik gözle bakan bir insandım ve benden iş geliştirme, ekip yönetimi ya da aylık yönetim kurulu raporları gibi “boş işler(!)” bekleniliyordu. Ben bunlara gerektiği şekilde adapte olamamıştım. Bu konulardaki sosyal becerilerim çok iyi değildi. Onlarca sorun üzerime geliyor, teknik konulara benden daha yetkin arkadaşlar ekipte olmasına rağmen illa ki burnumu sokuyor, C-Level adı verilen üst yönetim ile (bana göre) mantıksız davranışları yüzünden tartışıyor, ekibi kendi başına bırakıp, o sorunlar ile birebir boğuşmaya çalışıyordum. Ekip de başlarında düzgün bir yönetici olmadığı için kendi bildiğini okuyup müşteri / kullanıcı isteklerine plansızca “dalıyordu”. Cahil olduğum bir alanda kendimi eğitmem gerekiyordu.

Bir yazılımcının bir şirkete girip de, ilk profesyonel kodunu yazmasından, CTO ünvanını almasına kadar geçen sürede (eğer ki tercih bu yönde ise), aşağıdaki adımların her birisinin çok önemli olduğuna inanıyorum. Her adımı/ünvanı belki ayrı yazı konusu yapmak gerekir, ancak anlatmak istediklerime zemin olması için, özeti bu iki yazıda vereyim. Aşağıdaki ünvanların aslında bizim ülkemizde dağıtıldığı kadar kolay harcanmaması gerektiğine inanıyorum. Bu yazı dizisinde de bu tezimi savunacağım. Arada onlarca ara katman / ünvan yer alabilse de, genelde bir yazılımcının iş hayatındaki basamakları şu şekilde oluyor Türkiye’de (Ülkeyi özellikle belirtiyorum çünkü yurtdışında farklılıklar olabiliyor):

1. Stajyer
2. Junior yazılımcı
3. Yazılımcı
4. Uzman / Senior yazılımcı
5. Teknik lider / mimar
6. Takım/ekip yöneticisi
7. IT yöneticisi
8. CTO / CIO (İkisi eş değer görülse de farklar büyük aslında)
9. CEO?

Bunların ilk ikisini, kendi kişisel deneyimlerim ile bu yazıda ele almaya çalışacağım. Diğer adımlar/ünvanlar da diğer yazı konusu olarak kalsın(“in your face September mirmirik”).

1. Stajyer

Gerçekler: Ülkemizde stajyer, fotokopi çeken, getir götür işleri yapan ya da sadece staj defteri imzalatmak için “fake” görev alan kişi gibi görülüyor çoğu zaman. Konunun işveren ve işçi olmak üzere iki tarafı var. Stajyer olan, staj dönemini sadece zorunlu bir görev olarak gördüğü için pek ciddiye almıyor ve baştan savma bir zaman geçirip, bitse de gitsek fikrinde oluyor. İşveren ise ucuz (ücretsiz/bedava) işçi bulduğunu düşünerek hiç bir yatırım yapmadan ne kadar sömürsem kardır mantığında kalıyor.

Gereken: Stajyer tarafında bu sürecin tam bir gerçek ortam deneyimi olduğu bilinci yükselmeli, işveren de staj yapmaya geleni iyi bir çekirdekten yetişen kadrolu elemanı olarak görmeli. Eğitim ve bilgi birikiminin arttırılmasına yönelik olarak stajyeri konumlandırmalı ve ona mentor desteği sağlayarak kadrosunu zenginleştirmeli. Stajyer arkadaş da, son sınıf değil daha 3. sınıftan başlayarak stajın onun hayatına yön verecek bir zaman dilimi olduğunu kabul etmesi ve işe sarılması gerekli. Dediklerimin kulağa hoş geldiğini ve “boş” gibi algılandığının farkındayım. Ülkemizdeki durum yüzünden bu dediklerim çok akıl karı değil gibi. Ama bunları yapmamaya, günü kurtarmaya devam ettikçe sürdürülebilir bir iş deneyimi yaşayamayacağımız gibi, on yıl sonrasında devam eden bir işimiz bile olmayabilir. Yani kısacası, sevgili üniversite ve lise öğrencileri… Lütfen stajınızı size kadrolu elemanmışsınız gibi davranan bir yerde, öğrenimlerinizi devam ettirebileceğiniz bir şirkette, iyi bir ekip ile ve de işe çok sarılarak yapın. Şirket sahiplerinin vergi yükü ile bu kadar ezildiği bir ülkede “lütfen stajyerlerinize iyi imkanlar sunun” demem abes olsa da, stajyerlere “biz eğittik gitti başka yerde sefasını sürecek” kişi gözü ile bakmayın ve kadrolu eleman yetiştirebilmek için seçim yapın.

Kişisel eklenti: Lisede sanayi stajımı Balıkesir’de çok sevdiğim bir “Commodore/Amiga/PC oyunları satışı” yapan(o yıllardakiler iyi bilir) ve aynı zamanda da samimi müşterilerinden oluşan küçük bir ekip ile “Pascal dilinde yazılım yapıp satan” bir şirkette (HCS) yapmıştım. Oradaki ekip ve dostluklar asla unutulmaz. Öğrendiklerim, gördüklerim ve bir bilgisayar yazılımının nasıl da bir “yaratım” işi olduğunu anlamam burası sayesinde oldu. Assembly’de kendimi geliştirdim, BBS ile ilk “modem” bağlantımı da burada yaptım. Elektronik devreler ve tasarımları konusunda tam bir saha çalışması yapma imkanı da buldum(Biraz fazla RS-232 kartı yakmış olabilirim). Sabah “dükkanı” açıp yer de sildim, vitrin de düzenledim. Bunlar şimdiki ev temizliğimi yaparken de çok işe yarıyor

Üniversitedeki ilk stajımı ise zamanının iyi bankalarından birisi olan Esbank’ta, AS/400 sistemleri yanında PC / internet yazılımları da üreten bir ekip ile yapmıştım. İkinci (son sınıf) stajımı ise zaten yarı-zamanlı olarak çalıştığım Coretech firmasında tamamladım. Bankaya girişim içerideki tanıdık olan sevgili Serkan abimin özgeçmişimi ilgili kişilere iletmesi sayesinde oldu. İki staj sürem de resmi olarak 20 iş günü olmasına rağmen, lisede 4 ay, üniversitede ise 3 ay kadar çalışmıştım (Coretech dönemini zaten bir çalışan olduğum için saymıyorum). Öğrenebildiğim kadar öğrenmeye çalışmış, yeni onlarca yöntem ve bilgi edinmiş, merak tatmini sağladığım için mutlu olmuştum.

2. Junior yazılımcı

Gerçekler: Herhangi bir üniversitenin herhangi bir bölümünden mezun olmuş ve herhangi bir yazılım kursundan herhangi bir konuyu bitirmiş herkes kendisini “yazılımcı” olarak adlandırıyor ne yazık ki. Bu gördüğüm, yaşadığım bir gerçek. Mütevazi davranan ve var olan bilgisini satmayı beceremeyen kişiler ise çoğunlukla elenip gidiyor arada (Ne lise mezunları vardı ki ben dahil bir çok “yazılımcıyı” cebinden çıkarıp, bir algoritmada size ters takla attırabiliyorlardı). Herhangi bir işe girmenin ilk yolunun parlak bir kariyer.net özgeçmişi olduğu devirler biraz geride kaldı. Bir önceki konuya bağlı olarak, staj döneminde katkı sağladığı projeler ile göz doldurmuş kişilerin bile bir yere girip de başarılı yazılımcı olmaları zorlaşıyor. Daha çok, tanıdık kişilerin referansları ile işler ilerletilmeye çalışılıyor. Bu noktada “tanıdıklık” kavramına açıklık getirmekte fayda var aslında. Tanışıklığın becerilerden ve “network” kaynaklı olması ile, “mahalledeki sevilen bir abimizin çocuğu” olması arasında çok fark var.

Gereken: Algoritmalar ve matematik konularına ilgi duyan, bir yazılımın sadece bir text dosyaya satırlar yazmaktan ibaret olmadığını bilen kişilerin çoğalması gerekiyor. Bu olgunluğu verecek olan da sadece üniversite değil (ki an itibari ile ülkemizdeki üniversiteleri düşününce iki elin parmaklarını geçmezler bu şekilde eğitim verenler). İçten gelen bir ilgi ve bilgi açlığı olması da kaçınılmaz. Bu ilginin uyandırılması ve gençlerin içindeki bilgisayar bilimleri sevgisinin açığa çıkarılması ne yazık ki yine ortaokul / lise eğitimlerine ve aileye kadar dayanıyor. İstenildiği kadar bilimsel eğitim peşinde koşmanın iyi olduğunu söyleyelim, herhangi bir hükümetin “ben evrim değil de, cihat öğreteceğim bundan sonra” demesi ile geleceğin kapkaranlık hale gelmesi hep olası. Atılması “gereken” adımların bireysel olarak değiştirilebilecek bir şey olmadığının anlaşılması da söz konusu olabilir. Kim bilir, belki de bireysel olarak da çok şey yapabiliriz!

Kişisel eklenti: Türkçe kelime olarak “junior” yerine ne koyacağımı çok bilemedim yıllardır. Hala da bilmiyorum. Staj dönemini başarı ile geçmiş, öğrenmeye devam etmiş, bilgi açlığına devam eden, üç-dört yazılım projesi geliştirilmesinde bir şekilde rol almış, süreçler ve yazılım yaşam döngüsü konusunda bilgi sahibi, algoritmaların ne kadar önemli olduğunu bilen ve önemseyen kişi gibi görüyorum ben. Ekip içinde olduğunu anlaması, kişisel hırslarını bir kenara koymaya başlaması gereken bir süre. Sosyal becerilerin geliştirilmesi için mükemmel zamanlama…Staj sonrasındaki ilk iş aslında. Kaynak kullanımı (bellek / disk / zaman) konusunda hassasiyeti olan, GitHub / Stackoverflow gibi oluşumları çoktan öğrenmiş olan, kendisine en az bir yıllık gelişme programı yapabilmiş olanlar benim gözümde ışık patlamalarına yol açıyor.

Ben Jr dönemimi üniversite 3. sınıfta yarı-zamanlı çalışmaya başladığım ve benim için hala bir okul olan Coretech’te geçirdim. Klasik hikaye… Internet Türkiye’ye yeni yayılmaya başlamış ve herkes her şeyi yapar halde. Müşterinin isteği öğrenilip, tahta başında DB tasarımı, Adobe Photoshop’ta tasarım. Sonrasında çıkan tasarımı kesip biçerek HTML hazırlama, JS ile sayfaya dinamiklik kazandırma, ASP ile sunucu kodlarının yazılımı, SP ve TRIGGER’lar ile DB desteği… Artık ne varsa işte! Bugünlerde “full-stack developer” diyorlar bu şekildeki çalışmaya galiba. Bu dönemin bendeki en büyük kazanımları, işlerin nasıl yürüdüğünü çok yakından görmüş olmam ve müşteri isteklerinin “asıl” olduğunu anlamaya başlamış olmam. Şansım, çalıştığım firmadaki “patronların” sabah 04:00’lere kadar bizler ile bir ufacık problem ile ilgili oturup bire bir çalışıyor olmaları ve hepsiyle “arkadaş” olmamız idi.

Yazının devamı, Eylül ayının Mırmırık’ına ait… Buradan çekileyim şimdilik!

Yazı biterken çalıyordu:

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

Öncelikle söylemem gerekir ki, Zagreb’e kadar gelmişseniz bu bölgeyi ziyaret etmeden ayrılmayın ülkeden. İmkanınız varsa, tavsiyem o bölgede bir otel ya da çokça bulunan “guesthouse” ayarlayın ve en az iki gününüzü burada geçirin. Parkın tamamını 1 günde gezmek zaten imkansız. Sırf göllerin olduğu yer tüm park alanının %1’ini kapsıyormuş ve burası bile bir günde bitemiyor. Toplam alan ise 295 km² imiş. Asıl gezilmesi gereken alanın ormanlık bölge olduğunu söylediler ama orası için haftalık program yapmak ya da işi bilen bir tur satın almak gerekiyordu. Bir arkadaş ile birlikte iki günde tüm göller bölgesinin ancak %40’ını bitirdiğimizi düşünürsek… Hesaplamaya matematiğim yetmedi şu anda! Ulusal park Hırvatistan’ın Zagreb’e daha yakın olan orta bölgesinde bulunuyor. Google Maps açıp da kaçırmak neredeyse imkansız:

Neyse… Zagreb’den göller bölgesine gelmek 2-2.5 saat kadar süren bir otobüs yolculuğu sadece. Otobüs biletinizi online olarak vollo.net üzerinden satın alabilirsiniz. Ya da Zagreb otobüs terminali sayfasından detaylı bilgi de edinebilirsiniz. Dilerseniz direkt otobüs durağına gidip, oradan da satın alma yapabilirsiniz.

Göller bölgesine tek yönlü bilet 99 Kuna tuttu Vollo.net üzerinden. Bu da, bu yazının yazıldığı tarih itibari ile yaklaşık €13.5 kadar (55TRY). Bileti aldığınızda, size gelen biletin yazıcı çıktısı gerekiyor. Yani “online bilet aldım telefonumda da e-postam var” çok işe yaramıyor. Otobüs içindeki muavin ya da şoförlerin İngilizce bilgileri oldukça kısıtlı. Anlaşmak zor olabiliyor. Sadece işaret dili ile anlaşmak zorunda kalacağınızı ya da Hırvatça ve İngilizce bilen bir arkadaş bulmak zorunda kalabileceğinizi göz önünde bulundurun. Bileti online alamazsanız da, yazdığım gibi otobüs firmalarından ya da yer varsa otobüse bindikten sonra içeriden alım yapabiliyorsunuz. Yine dediğim gibi yer sorunu olabiliyor bu durumda. Bileti aldığınızı varsayarsak, ikinci adım otobüse binişe geçebiliriz. Zagreb’teki ana otobüs durağını aşağıdaki haritada işaretlemeye çalıştım (https://goo.gl/maps/Mae2pY4noB12):

Otobüs terminaline ulaşınca panolardan otobüsünüzün hangi perondan kalktığını bulabilirsiniz. Oldukça başarılı bir sistemleri ve havayolları gibi yönlendirmeleri var. O yüzden otobüsü karıştırmanız oldukça zor (dedi İtalya’da yanlış trene binip bambaşka yerlere gitmiş olan adam). Eğer otobüs yolculuğunda bagaja vereceğiniz çantanız varsa o da 8 Kuna tutuyor(4.5TRY kadar). Biz alışkın olmadığımız için garip gelebilir bu uçak uygulaması ama, kurallar böyleymiş. Havayolları benzerliği sadece terminal ile sınırlı değil kısacası. Ben çantayı bagaja atıp direkt otobüse yöneldiğim için ufak bir anlaşmazlık yaşadım muavin ile. O para istiyor, ben de ona biletimi gösteriyordum. Anlaştık neyse ki.

Yol 2-2.5 saat kadar sürüyor. Bir süre otobandan gidip, Karlovac şehrinden sonra ara yola sapıyor otobüs. İnanılmaz yeşillikler arasından geçiyor ve bir iki kasaba sonrasında ulusal parkın 1 numaralı girişinde duruyor. Parkın 2 farklı giriş noktası var ve bu birazdan söyleyeceğim bir ipucu için önemli bir konu.

Otobüs yolculuğu sırasında yanımda oturan Danimarkalı bir arkadaş(sevgili Maja) ile tanışmıştım ve buradaki iki günümüzü de birlikte geçirmeye karar vermiştik. Şans eseri aynı yerde kalacaktık. Biz iki numaralı girişte indik ve gideceğimiz yere nasıl ulaşabiliriz endişesi baş gösterdi. Çünkü tam olarak çift şeritli küçük yol ağzında idik ve haritaya göre bu evimiz için yoldan 3km kadar yürümemiz gerekiyordu. Araçlar ile birlikte… Transfer sorunu büyüktü! Bölgede Adriana Guesthouse diye bir yerde kalacaktık ve oraya nasıl ulaşabileceğimizi hiç düşünmemiştim. Oldukça uzakmış aslında asıl park alanına. İndiğimiz duraktakiler ile konuştuk ve en mantıklı seçimin taksi olduğu ortaya çıktı. Yokluk bölgesinde bir araç yolundasınız ve yabancı bir ülkede taksi ile bir yere ulaşmak? Fikri bile cüzdanı yakacak gibi görünüyor ama, biraz çenebazlık ve iyi niyet göstergeleri ile sevgili şoförümüz Damir ile tanıştık. İngilizcesi bizim Mr. Brown ve Mrs. Brown’dan hallice idi ama gayet de iyi anlaşarak köy evine kadar 50 Kuna ücret almayı kabul etti (sonradan ispatladı ki, taksimetre açınca 70 – 75 kadar tutuyor). Telefonunu aldık. Sonraki tüm seyahatlerimizde de kendisini telefon ile aradık, O da gelip evin önünden alıp, istediğimiz yere kadar bıraktı.

Eve çantaları atıp yine Damir ile 2 numaralı kapıya gittik. Dönüş için ücret almadı 2 numaralı kapının içinden girip bizi bilet lokasyonuna kadar götürdü. Biraz ön bilgi olması amacı ile şu “kapı” / “giriş” olaylarını da bir göstereyim harita üzerinde:

Bizim kaldığımız yer bu haritada yok… O kadar uzak işte. İki kapı arası mesafe yaklaşık 2-2.5 km. kadar. Aradaki yol da -bilenler bilir- Altınoluk / Küçükkuyu yolu gibi. Dümdüz araç yolu! Konuya dönüyorum…

Fun fact 1: İlk gün 2. kapıdan giriş yaptık ve yaklaşık yarım saat kuyrukta sırf bilet almak için bekledik. Hem de Perşembe gibi hafta içi bir gün olmasına rağmen. İncelikli nokta şimdi geliyor. Eğer iki gün kalacaksanız MUTLAKA önce ikinci kapıyı ziyaret edin ve “2 days ticket” alın. 180Kuna bir günlük bilet parası, 280Kuna da 2 günlük geçiş hakkı veren bilet. Bunu yaptığımıza ikinci gün 1 numaralı kapıya gidince o kadar sevindik ki… Emin olun siz de sevineceksiniz.

Fun fact 2: Bilet noktasındaki restaurant benzeri yerden yemek / su / bira alınabiliyor ama özellikle yemek kalitesi pek de iç açıcı değil. Çok şey ummamakta fayda var. Su alırken de “PET” markalı olanları tercih etmek en azından %50 tasarruf sağlıyor (15 Kuna 50ml. bira idi, 12 Kuna 50ml. PET marka su ve 27 Kuna adını hatırlamadığım yine 50ml. su idi).

Bileti aldıktan sonra ister elektrikli tur otobüslerine binebilir, isterseniz yine sıraya girip tam karşınızdaki iskeleye geçen elektrikli tekneye atlayabilir ya da yürüyüş rotanıza göre tabanlarınıza güvenebilirsiniz. Biz tabanlarımıza güvenmedik. Karşı iskeleye geçen tekne için sıraya girdik ve yaklaşık 20 – 25 dakika sonra sıra bize gelip karşıya geçtik. Buradan sonrasında yürüyüşümüze başladık. Rotamız yaklaşık şöyle oldu (çizim becerilerimi sorguluyorum hala):

Oldukça yorucu ama bir o kadar da heyecan verici ve zevkli saatler geçirdik. 3-3.5 saate yakın bir sürede bitirdik bu parkuru. Zamanımızın çoğu ahşap iskele benzeri bir yolda geçti. Diğer zamanlarda ise kuru orman tabanında yürüdük. Sadece bir ya da iki defa suya dokunabildik. Manzara, şelaleler, korunmuş ve kollanmış doğa inanılmaz güzellikteydi. Tavsiyem yanınızda şapka, su ve atıştırmalık bulundurmanız. İlk günün ilk dikkat çekici fotoğrafı şurada hemen (devamını Instagram hesabıma ekleyeceğim sanırım):

Birinci günü bitirip, eve döndük. Ertesi sabah için programımızı yaptık. İkinci gün yine inanılmazdı. Damir bizi aldı ve 1. kapıya kadar getirdi (bu sefer 100 kuna tuttu ücret). Kapıdaki bilet sırası, hac dönemi Atatürk Havalimanı pasaport kuyruğunun 3 – 4 katı kadardı. Ön sıralardakilere sorduğumuzda 1.5 saattir kuyrukta olduklarını söylediler. Bir önceki gün 2. kapıdan iki günlük bilet almış olmamızın faydası ile herkesin kem gözleri altında sallana sallana içeriye girdik. Tekrar edeyim. İki gün kalacaksanız mutlaka ilk gün 2. kapıya gidip iki günlük bilet alın ve 2. gün birinci kapıya gelip içeriye girin. Sırada beklemek çok uzun sürecek diğer türlü. Boşa zaman kaybı olacaktır. Birinci kapının olduğu yer, tanıtımlarda kullanılan kataloglardaki büyük şelalenin olduğu yermiş. Fotoğraf çekimlerinin bir çoğu da burada oluyormuş meğer. Bilet gişesinden geçip, daha içeriye 100m kadar girmişken bizi karşılayan görüntü, tabiatın gücü karşısında boynumuzu eğmemize yol açtı. Tam bir “natureporn”. Varolan ve varolmuş olan tüm jeoloji tanrılarına ve tektonik plakalara şükranlarımız sunduk.

Fotoğrafın sağ tarafında görülen şelale, bölgedeki en büyük şelale imiş. Onun olduğu mekana yürümek yarım saat kadar vaktimizi aldı. Tüm yol inanılmaz bir bitki örtüsü ve görüntüler ile doluydu. Oraya ulaştıktan sonra “normal yol” yerine, hep yapmayı tercih ettiğim gibi “daha az gidilmiş yol” tercihi ile yukarıya tırmandık. Kısacası, şelalenin oradan büyük çoğunluğun yaptığı gibi geri dönmeyin. Arkada sol tarafta oldukça dik olan merdivenler var. 80 – 100 metre kadar yukarıya çıkarıyor. Çok yorucu olabilir ama buna değer. Buraya sapın! Yanınızda oram ağrıyor, buram ağrıyor, yoruldum geri dönelim, çantamı taşı / yardım et bana falan diyen birisi yoksa çok güzel bir yolculuk. Çıktığınızda şunun benzeri manzara var karşınızda. O şelalenin döküldüğü nokta ile yaklaşık aynı hizaya geldik ve karşıdan görüyorduk.

Bu noktadan sonrası size kalmış. Normal yolları izleyebilir ya da üstteki fotoğrafta şelalenin sağ tarafına çıkabilirsiniz. Üst tarafta bir araba yolu var. Oraya doğru gidip, sağa dönüp, polis noktasının oradaki pek kullanılır gibi görünmeyen patikadan aşağıya inebilirsiniz. Dönüş yaptığınız, saptığınız yerlere dikkat etmenizde fayda var. Şununla karşılaşırsanız, ne yapacağınızı biliyorsunuz. Sonuçta çoğumuz Blair Witch Project (IMDB) izlemiştir sanırım.

Eğer yolu bulup da, gözlem noktasına ulaşabilirseniz, şu manzaranın da keyfini çıkarabiliyorsunuz:

Buradan tekrar asfalt yola dönüp ormandaki patika yola geçiş yaptık. Bir süre sonra dinlenme noktasına ulaştık ve biralar ile yemeklerimizi hallettik. Bir saat kadar mola verdik. Gücümüzü topladıktan sonra tekrar “Entrance 1” tabelasını izleyerek yola koyulduk. Yine mükemmel manzaralar eşliğinde bir baca mağaraya geldik. Çok dik merdivenler ile 80 metre kadar yukarıya çıkıyorsunuz. İçeride yarasaların yuvası varmış ama karanlık koridorlara sapmadığımız için ne yarasa ne de Bruce Wayne göremedim. Şu tabela karşılıyor sizi girişte:

Sonrası oldukça uzun bir yol ile tekrar bir numaralı kapıya ulaştık ve ikişer bira molası verip, Damir’i aradık. İkinci gün bu şekilde kapanmış oldu ve yaklaşık olarak 6.5 saat kadar sürdü tüm yürüyüş. Yaklaşık yürüyüş rotamız da şu şekilde oldu:

Yaptığımız yolculuk ve yaşadığımız deneyim asla unutulmaz. Yeşile, turkuaza ve maviye doyduk. Mavi ve yeşil sever birisi olarak çok tatmin olduğumu söylemem gerekiyor. Umarım bu bölgeye yolunuz düşer ve bu deneyimi sizler de yaşarsınız.

Not ve güncelleme bilgisi: Bazı saçma cümle devrikliklerini düzeltmeye çalıştım, bir iki fotoğraf ile biraz detay daha ekledim. Dönüş ve Zagreb konularını da üşenmezsem bir yıl içinde yazarım.

(Konuyu kapatırken çalan parça: Lilac Wine / Jeff Buckley)

The post Plitvičke Jezera / Plitvice Lakes Gezisi appeared first on mirmirik.net.

Kovboy tarzı yazılımcı olmanın ve bu şekilde yazılım geliştirmenin kötü taraflarından üzerine sıklıkla bastırdıklarım özetle şunlar:

• Tek kişi kalmak, yalnız olmak
• Ekibe güvenmemek
• Test ya da dokümantasyona zaman ayırmamak
• Bilginin tek elde toplanması
• İşlerin gün geçtikçe yığılması
• Yığılmadan dolayı işlerde gecikmeler ve bug çıkması
• Bug-fix yapacak ya da işleri yetiştirecek kişinin aynı kişi olması
• [infinite loop]

Tüm bunları bir kovboy yazılımcı ile konuşursanız, size, kendisine zamansız ve eksik dokümante edilmiş istekler geldiğinden, isteklerin bilgisizce hazırlandığından, zaten sistemin ayakta kalmasının tek sorumlusunun kendisi olduğundan, ekipteki daha junior seviyedekilere işin nasıl yapılacağını anlatmaktansa kendisinin yapmasının çok daha hızlı olduğundan bahsedecektir. Kendisinin çevik metodolojiler için yanıp tutuştuğundan, yazılım geliştirme döngüsünde herhangi bir çevik yazılım geliştirme metodolojisi uygulanıyor olsa herşeyin güllük gülistanlık olacağından, ancak süregiden şirket politikası ve işlerin kritikliği sebebiyle bunun uygulanamayacağından da söz edecektir.

Bu durumda kendisine çevik metodolojilerin prensiplerini tekrar hatırlatmakta fayda var:

• En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.
• Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.
• Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.
• İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.
• Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.
• Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze iletişimdir.
• Çalışan yazılım ilerlemenin birincil öçüsüdür.
• Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.
• Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.
• Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.
• En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.
• Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.

Prensiplerde önemle tekrarlanan bir nokta var. Takım / ekip / birlikte çalışmak / takım oyuncusu olmak. Takım oyuncusu olmanın şartlarından birisi de aslında bilgi paylaşımının ve şeffaflığın arttırılması. Bilgi paylaşımında bulunmak ve şeffaflığı arttırmak için ise asıl yapılması gerekenin -kişisel deneyimlerden yola çıkarak- “profesyonel ego”dan kurtulmak olduğuna inanıyorum.

Egosunu yenebilmiş teknik bir kişinin, ekip ile birlikte daha çok büyüyeceğine ve hep hayalindeki rahat çalışma ortamına kavuşacağına dair inancım yüksek. Ego nasıl yok edilir konusu ise daha çok psikoloji ve sosyoloji alanlarının konusu. Hala kişisel hayatımda yüksek olduğuna inansam da, benim iş konusundaki egomu zayıflatmam şunları sağladı:

• Şirket içi bilgi paylaşımıma daha fazla zaman ayırdım,
• Ekibe yeni katılmış ya da daha önceden ekip içinde varolan arkadaşların teknik bilgilerini yükseltmek için çabalar oldum,
• Ekipteki arkadaşlarımın kendilerine güvenleri yükseldi,
• Üzerimdeki işleri dağıtabilmeyi başardım,
• Üretime aldığımız kodlarda çok daha az hata çıkmaya başladı,
• Müşterilerimizde şirketimize ve ekibimize karşı güven yükseldi ve zaman zaman yaptığımız hataların tolere edilmesi kolaylaştı
• Mesai sonrası boş zamanım oldu,
• Sosyal hayata daha çok zaman ayırabildim,
• Geceleri, aklımda o günkü ya da yarınki proje ile ilgili daha az endişe duydum ve daha rahat uyuyabildim.

Uzun lafın kısası, kovboy yazılımcı olmanın o iç daraltıcı dünyasından, ilk etapta egonuzu arkanızda bırakarak ve bu sayede takım oyuncusu olma yoluna adım atarak sıyrılabilirsiniz. Emin olun her şeyin en iyisini siz bilmiyorsunuz ve aslında vazgeçilmez değilsiniz.

Not: Yazıdaki fotoğraf, bir zamanlar kovboy filmlerinde oynayan ancak daha sonra ABD başkanlığına soyunan Ronald Reagan‘a ait.

The post Kovboyluktan vazgeçip takım oyuncusu olmak appeared first on mirmirik.net.