Yazıya başlamadan önce şunu belirtmek istiyorum. Kamu ve özel sektörde yıllardır çalışan, özellikle özel sektörde birçok firma ile çalışma şansı elde etmiş biri olarak, yazının tümünde anlatılanların %90'ının özel sektörde şirket patronları tarafından, %10'unun özel sektördeki birim yöneticileri tarafından uygulanan olumsuz yöntemler olduğunu belirtmek isterim. Gerek şirket gerek birim yöneticilerinin bir çoğu hem teknik bilgi hem de insan ilişkilerinde başarılı olsalar da özellikle küçük - orta çaplı şirketlerin sayıca çok olmasa da azımsanmayacak bir kısmının para kazanma uğruna çalışanlarına bilinçli ya da bilinçsiz şekilde MOBBING uyguladığı tartışmasız bir gerçektir. Yazıda anlattığım tüm olumsuz örnekler, özel şirketlerde benim ve çevremdeki arkadaşlarımın karşılaştığı sorunları belirtmektedir. Kamu kurumlarında bu durum biraz daha farklıdır. Yönetici bazında değişiklik gösterse de gerek insan ilişkilerinde gerek proje yönetiminde kamuda uzun yıllar görev yapmış kişiler ve yöneticiler, uzun yıllardır o kurumda çalıştıkları ya da çalışacaklarını bildikleri için işi özel sektöre göre çok daha fazla sahiplenirler. Tüm ekipte oluşan bu sahiplenme neticesinde hem insan ilişkileri hem yönetici - personel ilişkileri özel sektördeki iyi ve kötü bir çok şirkete göre çok daha gelişmiştir.
Başlangıçta şirket yöneticileri tarafından yanlış anlaşılması muhtemel konularla ilgili düşüncelerimi paylaştıktan sonra yazımıza başlayabiliriz. Tüm yazıya bu çerçevede bakabilirsiniz :)
Yazılımcı denince ilk akla gelen sürekli bilgisayar başında oturup birşeyler yapan kişidir. Oturduğu yerden para kazanır ve kazandığı para hakettiğinden fazla diye düşünülür, çünkü sadece oturuyordur. Tüm işleri aslında bilgisayarın yapıyordur, kendi yapıyor gibi aksettirdiği söylenir.
Yukarıda bir yazılımcının, yazılım geliştirmeyle uğraşmamış hatta programlarla işi olmayan kişilerin yazılımcılara bakış açısıdır. Bir çok şirket ve kurumda maalesef bu kişiler yönetici / patron pozisyonlarında karşımıza çıkmaktadır. Sektörde uzun süre yazılımcı olarak çalışmışsanız, bahsettiğim türden bir yöneticiyle çalışmama ihtimaliniz %0 :) Bu düşünceler, bir süre sonra düşüncelikten çıkıp ve MOBBINGe doğru hızla ilerler. Bu kadar ileri noktaya gelmesinin sebeplerinin en başında, Y kuşağının çalışma şekillerinin X kuşağından çok farklı olması ve X kuşağının bir kısmının ısrarla (kimi bilinçli kimi bilinçsiz olarak) bu farkı anlamamasından kaynaklanıyor.
Y kuşağını sadece kendi özellikleriyle ele almamamız gerekiyor. Y kuşağı bir yazılımcı, herhangi bir Y kuşağından daha farklı özelliklere sahip. İyi bir yazılımcının kod yazarken belli periyodlarda dinlenmeye ihtiyacı var. Çalışma süreleri kiminde 30 dakika olabildiği gibi kiminde 2 saate kadar çıkıyor (2 saatten fazla aralıksız çalışan bir yazılımcıdan günün sonuna kadar verim beklememekte fayda var). Saat başı dinlenme arası veren ya da ofiste turlayan bir kişiyi gören yukarıda belirttiğim özelliklerdeki bir yöneticinin ruh hali ve uzun vadede yapabileceklerinin sınırı maalesef yoktur.
Yazılımcının, diğer meslekler gibi işe başlarken yönetici ve ekip arkadaşı seçme gibi bir seçeneği yoktur. Büyük şirketlerde mülakatı yapan yöneticiler iyi bilinse de içeride sorunlu yöneticiler de bulunabilir. Kimi zaman, belki de uzun bir süre bu yöneticilerde çalışılmak zorunda kalınabilir. Bu sebeple bir yazılımcının uzun vadede hedefi (ilk işe başladığı zaman şirket ayırmamasından yanayım. Bir süre tecrübe kazandıktan sonraki süreçte) büyük şirketten ziyade, kurumsal ve Y kuşağına önem veren bir şirket tercih edilmelidir. Bulunduğunuz yerde bu tür bir şirket yoksa, o zaman yöneticilere “NABZA GÖRE ŞERBET”in nasıl verildiği tecrübeyle öğrenilir.
Şu ana kadar çalıştığım ve danışmanlık verdiğim şirketlerde gerek müşteri gerek yönetici olarak farklı tarz ve kalitede yöneticilerle çalışma imkanı buldum ve şunu öğrendim: “yazılımcı sağlıklı ve planlı çalışma ortamını kendi oluşturur”. Peki nasıl? Gelin size sağlıklı ve planlı çalışmanın önemini ve aldığınız paranın yaptığınız işe göre az olduğunu yönetici ve müşterilinize nasıl anlatabileceğinizle ilgili bir kaç tüyo vereyim :)
Plan olmasa da sen planını yap!
Yöneticiniz proje planı yapmayı bilmeyebilir, projenin son günleri gelmesine rağmen yapacak çok iş olabilir, yöneticinizin yaptığı planların çalışma zamanları olması gerektiğinden az olabilir, danışmanlığını yaptığınız ya da freelance geliştirdiğiniz projede firma sizden işi hemen istiyor olabilir. Bunların hepsinin tek sebebi vardır: “Yazılımcıyı gece – gündüz çalıştırıp işi erken/zamanında bitirtmek ve yeni işlere başlamak”. Yönetici / müşteri bunu düşünürken yazılımcının da kendininki gibi bir hayatının olduğunu maalesef düşünmez, çünkü para veriyordur ve karşılığında hemen işi almak istiyordur.
Bu durumlarda yapmanız gereken, kendi planınızı hazırlayıp ortaya koymak. Yöneticinizin yaptığı planda iş 10 günde bitiyor gibi görünse de siz (abartmadan) planınızı yaptığınızda işin bitiş zamanı 15 gün olabilir. Bunu yöneticinizle sakince ve e-posta üzerinden paylaşın, “10 günde bitirmeye çalışabilirim, ama bitmez. 15 gün ideal” cümlesini mutlaka kurun ve işinizi yapmaya başlayın. Büyük ihtimalle sizi dinlemeyecek ve 10 günde işi bitirtmeye çalışacak, sizi her gün mesaiye bırakacaktır. Burada yapmanız gereken şey, mesaiye de kalsanız işi 15 günde bitirmektir. Bu şekilde bir kaç planda söylediğiniz zaman dilimlerinde projeyi sorunsuz şekilde tamamlarsanız, yöneticiniz sizin planlarınızı dikkate almaya başlayacak, mesai sonrası çalışmaya gerek olmadığını zamanla kendisi de görecektir. Eğer yine aynı davranışlara devam ediyorsa, alternatifleri değerlendirme zamanınız gelmiştir :)
10 – 15 gün tartışmalarının sonunda 15 günü kabul ettirmeyi başardım ve projeyi sonradan çıkan süpriz durumlarla beraber bir miktar fazla mesai ile 15 günde tamamladım :)
Proje planında süreyi %20 fazla ver!
Amerika'da yapılan bir araştırmaya göre, yazılım projelerinde tahmin edilen gerçekleşme süresinin %15 ile %30 arasında aşıldığı görülmüştür.
Projeyi geliştirirken öngöremediğiniz bir sorunla (müşterinin eksik aktardığı ya da analizcinin yanlış anladığı bölümler olabilir, yazılım geliştirme teknolojisiyle ilgili sorunlar yaşanabilir) karşılaşabilirsiniz, yapılması gereken farklı bir iş ortaya çıkabilir, yöneticiniz projenin süresini kısıtlamak isteyebilir ya da özel bir durum oluşup izin almanız gerekebilir. Bu durumlar oluşsa bile proje planına sadık kalmanız yöneticiniz ve müşteriniz tarafından beklenecektir. Müşteri nezdinde "ailevi sorunlarım vardı, yetişmedi" cümlesinin bir anlamı yoktur, çünkü müşteri firmayla bir anlaşma yapmıştır ve bu anlaşma gereğince projenin sizin belirttiğiniz tarihte bitmesi gerekmektedir. Dolayısıyla sadece müşteri tarafında değil, yöneticiniz tarafında da sorunlarla karşılaşabilirsiniz. Bu durumları göz önünde bulundurarak her zaman proje planınızı oluştururken projenin süresini hesapladıktan sonra %15 ile %30 arasında (%20 benim için yeterli oluyor, bunu kendinize göre planlamanız gerekir) tolerans süresi ekleyiniz. Tolerans süresinin çok olacağını düşünerek eklemekten çekinmeyin çünkü zamanı kısıtlı vermek başlangıçta birilerinin (yönetici ve müşterinin) gözüne iyi görünebilir ve kabul ederler fakat projeyi verdiğiniz zamanda bitiremezseniz büyük sorunlarla (yönetim baskısı, kavgalar, müşteri tarafından durumun yargıya taşınması ve buna bağlı olarak işinize son verilmesi vb) karşılaşabilirsiniz. Projeyi zamanında bitirdiğiniz taktirde tolerans zamanını beklemeden teslimini gerçekleştirin. Şunu da unutmayın, kimse zamanından önce bitirdiği bir proje için ödüllendirilmez ama zamanından geç bitirdiği için her zaman eleştirilir.
Örneğin 50 günlük bir projenin taslak planını 60 gün olarak oluşturun. Olası bir sorunla karşılaşıldığında bu süreyi kullanırsınız. Sorunla karşılaşmazsanız da testler ve refactoring işlemleri için size zaman kalacaktır. Test ve refactoring işlemlerini de tamamladıktan sonra da zamanınız kalabilir, bu durum sizin için büyük bir avantaj olacaktır, çünkü projeyi verdiğiniz zaman diliminde tamamlamış (verdiğiniz sözü tutmuş) olacaksınız. Projeyi verdiğiniz zamandan önce bitirdiğiniz taktirde farklı arayışlar içine girmeden bir an önce projeyi teslim edin ve yeni projelere yelken açın.
Analiz için zaman iste ve al!
Yeni bir projeye başlarken, yapılacak işin analizinin mutlaka yapılması gerekiyor. Analiz olmadan başlanan projelerde yapılan tasarım, plan ve kodlar bir süre sonra silinmeye mahkum olacaktır!
Başımdan geçen bir olayı paylaşayım. Yeni bir proje başlayacak ve o dönemki yöneticime toplantı talep etmemiz gerektiğini söyledm. Kendisi daha önce müşteriyle görüşmelerini yapmış. Müşterinin, yayında olan rakip firmanın yaptığı bir web projesinin (kendisinin anladığı dille web sitesinin) aynısını istediğini söyledi. Analiz ve toplantı taleplerimi sürekli geri çevirdi ve sürekli olarak “bu sitenin aynısı olacak” dedi. Yapacak bir şey yoktu ve o siteye benzer bir şeyler ortaya çıkartacaktım. Siteyi kullanmak için hesap satın alınması gerekiyordu, çünkü demo hesabıyla sadece kısıtlı işlem yapılabiliyordu. Hesap alınmasını da kabul etmedi ve “bu kadarı yeter, demo hesabına baka baka yapalım” dedi. Bir yandan o kodluyor, bir yandan ben. Ama dilimde hep şu şarkı: “Ne analiz var ne plan. Bu proje patlar”, tabi bir kulağından girip diğerinden çıkıyor. Sonuç: Projede benden istenen bölümleri yöneticimin istediği gibi (hatta fazlasıyla) tamamlayıp farklı bir ekibe geçtim. Proje patladı ve olay mahkemede sonuçlandı.
Benzer sorunları siz de yaşamış olabilirsiniz ya da yaşayacaksınız. Bu durumlarda analiz için zaman isteyin, vermezlerse karşılaşılacak sorunları sakince anlatın. Eğer zaman verilmiyorsa tam istedikleri şekilde yapın ve müşteriyle yöneticinizin isteklerini e-posta üzerinden alıp e-postaların yedeklerini bir kenara kaydedin. Eğer proje bittiğinde patlama (müşterinin beğenmemesi ya da olması gerekenden alakasız bir şeyin ortaya çıkması) riski yüksekse, “sizin istekleriniz bunlar, e-postalar da burada. Analizi siz yapmışsınız, ben de sizin isteklerinizi yaptım” deyip sorumluluğu üzerinizden atın ve sinirlenmeyin. Ne kadar sakin tavır takınırsanız, haklılığınızın anlaşılması o kadar kolaylaşır. Eğer projeleri uzun vadeli geliştirmeyi düşünen bir yöneticiyse, sonraki projelerde analiz çalışmaları için zaman verecektir.
Göze girmek için ilk zamanlarda çok çalış ama mesaiden uzak dur!
Yeni bir işe başladığınızda ilk zamanlarda yönteicilerinizin gözüne girmek için çok çalışırız. Hatta bazen iş yerinde sabahladığımız ve 2 gün sonra yetişmesi gereken işi büyük bir istekle ertesi sabaha yetiştiririz. Çalışmanızın ilk zamanlarında bu çok doğru bir yöntemdir. Fakat mesai olayına dikkat etmeniz gerekiyor. Çünkü ücretsiz fazla mesaiye kalma, bir süre sonra yöneticilerde alışkanlık yapabilir.
2 günlük işi 2 günde mesai saatleri içinde tamamlayın. 2 günlük iş için 1 gün veriliyor ve siz de o gece sabahlayıp işi bitiriyorsanız yöneticiniz şunu düşünecektir: “Az sürede çok iş yaptırırım ben buna. Bekar zaten, evde bekleyeni de yok, çalışsın!”. İlk zamanlarda biraz tolerans gösterilebilir fakat uzun vadede yöneticilerde alışkanlık yaptığında içinden çıkılmayacak ve alternatiflerin araştırılmasına kadar giden bir süreçtir bu. Bu sürecin yönetimini sizin mi yöneticinizin mi yapacağı sizin elinizdedir. Maalesef bu durumun özel sektörde çok fazla örneği vardır.
Ne kadar çok iş çıkartırsanız bir adım ötesi beklenir.
Yukarıdaki maddenin bir benzeridir aslında bu. Bugün 3 birimlik iş çıkardınız diyelim. Yöneticiniz şunu düşünebilir: “Bugün 3 birimi sorunsuz çıkardı. Yarın 4 birimi deneyeyim, bakayım çıkartabilecek mi”. Bu düşünceyle beraber ertesi gün 4 birimlik iş verir ve siz kendinizde onu bitirme zorunluluğu hissedersiniz ve bitirirsiniz. İşi bitirdikten sonra yöneticinizin düşüncesi değişecektir: “Bugün 4 birimi sorunsuz çıkardı, demek 5 birim versem onu da çıkartabilir. Birkaç gün sonra 5 birimi deneyeyim”. Bu düşünceyle beraber birkaç gün 4 birimlik iş verir ve siz işleri çıkardıktan sonra farkında olmadan 5 birime çıkartır. Yaptığınız iş neredeyse 2 katına çıktığı için bugünden sonra mesai sonrası çalışmalar artacaktır. O işi bitirme zorunluluğunu hissettiğiniz için o gün içinde tüm işleri bitireceksiniz ve birim sayısı gün geçtikçe artacaktır, ta ki istifa dilekçesini yöneticinin masasına koyana kadar.
Uzun vadeli planlarda bitmesi gereken işler için elbette mesai sonrası çalışmalar kaçınılmaz olacaktır. Fakat bunun tüm projeler için alışkanlığa dökülmemesi için durumu yöneticinizle paylaşın ve verimli çalışmanın önemini kendilerine anlatın. Yöneticiniz durumun ciddiyetini anlıyorsa şanslısınız. Nadir de olsa özel sektörde 7/24 sürekli çalıştırmayı doğru bir yöntem olarak algılayan yöneticiler için farklı alternatif çözümler üretilebilir.
Bu durumda şunu prensip haline getirin: “Ne iş ne yöneticilerin egoları sizin hayatınızdan önemli değil. Yöneticiniz hayatını yaşamaya devam ederken siz 7/24 çalışıyorsanız alternatifleri en kısa sürede değerlendirin!”
Yazılımcının ilk görevi, yöneticisi / müşterisi eğitime ihtiyacı varsa ve çalışanı köle gibi kullanmak istiyorsa, onunla anlaşmaya çalışmaldır. Baktınız ki anlaşılamıyor, bir üst yönetime (en üste kadar adım adım) durumu iletin. Sonuç alınmıyorsa şirket size muhtaç olmadığı için, alternatiflere yönelebilirsiniz.
Bu yazıdaki yapılmasını belirttiğim durumlar, şimdiye kadar özel sektör çalışmalarımda yaşadığım ve gördüğüm olaylardan edindiğim tecrübeler sonucunda yaşadıklarım ve olmasını gerektiğini düşündüklerim. Herkesin kendi değerlendirme kriteri farklı olacağı için bunları sadece tavsiye niteliğinde düşünmenizi rica ediyorum.
Yazıyı zaman içinde geliştireceğim. Her güncellemede sosyal medya hesaplarım üzerinden paylaşım yapacağım.
Ellerinize sağlık, vakit ayırıp uzun uzun yazdığınız için de teşekkürler hocam. Değerlendireceğiz :)