Liderlikten Kural Satırlarına: Bir Ekip Lideri Kılavuzu

Merhaba!

Ekip lideri rolüne geçen her geliştiricinin, başlangıçta ekiple birlikte kodlama ve çözme görevlerine geri dönmeye çabaladığını düşünüyorum. Daha sonra, işle ilgili zorluklara, departmanlar veya müşteriler arasındaki iletişime ve mimariye kadar daha fazla iş görevi ve sorununu kapsamaya başlıyoruz.

Bu noktadan sonra artık başka bir şey yapmaya ne zamanımız ne de isteğimiz kalıyor. Tipik bir takım liderinin takvimi şuna benzemeye başlar:

Geliştirmeye Nasıl Dönüp Kodlamaya Yeniden Nasıl Başlarım? Nereden Başlamalıyım?

Gerçekten ne kadar meşgul olduğunuzu ve tipik iş gününüzün nasıl geçtiğini değerlendirmek de önemlidir. İşten sonra kişisel gelişimle ilgileniyor musunuz, ilgilenmiyor musunuz? Bunların hepsi çok önemli faktörler.

Deneyimlerime dayanarak, “işten önce ya da sonra zaman yok, arzu ya da fırsat yok”tan, “Her zaman bilgisayar başındayım ve bu benim tutkum”a giden yolda adımlar atmanızı öneriyorum.

Zamanınızı Engelleyin!

Etkili bir başlangıç noktası, gelişime ayrılmış zamanı planlamaktır. Takviminizde 'kodlama süresini' bir saat veya daha uzun süre engelleyin. Mümkünse, özellikle teknik görevlerin üstesinden gelmek için her haftanın yarım gününü veya tam gününü ayırmayı düşünün.

Evet, toplantıların başka yerlere taşınması, gereksiz olanların ortadan kaldırılması veya bazı toplantılara katılmanın gerekliliğinin tartışılması gerekebilir. Ancak belirli bakım seanslarının hâlâ sizin için geçerli olup olmadığını yeniden değerlendirmeyi düşünün.

Ekibinizle Kod İncelemesi!

Çevrenizdeki belirli süreçleri optimize etmenin ikinci ve en önemli yönü, projenin değerlerini veya yaklaşımlarını meslektaşlarınıza iletmektir. Her geliştirici problem çözme konusunda aynı yaklaşımı görmez; bu nedenle kodlama stillerini, test kapsamını ve platform veya hizmetlerin temel yöntem ve mekanizmalarını ayrı ayrı önceden tanımlamak önemlidir.

Her zaman kod incelemeleri yapın ve bir sorunun uzayıp gittiğine dair bir his varsa, çekme isteklerindeki (PR'ler) sorunları hızlı bir şekilde ele almak için ekibi toplayın. Uygulamada görüldüğü gibi, bu yaklaşım sorun çözme süresini hızlandırır ve sonuç olarak özelliklerin pazara sunulma süresini iyileştirir.

Zamanla ekibiniz daha az dikkat gerektiren geliştirme yaklaşımlarını tam olarak anlayacak ve uygulayacaktır. Yalnızca elinizdeki görevi ve onun mantığını çözmeye odaklanacaksınız; bu, başlangıçta birkaç dakika ve uzun vadede potansiyel olarak saatlerce süren geliştirme süresinden tasarruf etmenizi sağlayacaktır.

Nelerden sorumlusun?

Bu çok bariz bir görev gibi görünmeyebilir ama kendinize sorun, neyden sorumlusunuz? Ne yapman gerek? Tüm bu noktaları bir kağıda yazın ve gereksiz bir şey yapıp yapmadığınıza bakın.

Belki başkasının işini alışkanlık haline geldiği için yapıyorsunuzdur. Belki komşu bir ekibe süreçlerinde yardımcı oluyorsunuz ve hâlâ işin içindesiniz.

Pozisyonunuzu ve projeye veya şirkete ne gibi katkılarda bulunduğunuzu açıkça tanımlayın. Büyük bir ekibe liderlik ediyorsanız, görev ve sorunlardan oluşan bir sıra oluşturabileceğiniz notları kullanın. Her zaman incelemeler yapın ve örneğin bir DevOps lideriyseniz, mobil uygulama geliştiricilerine yönelik görevleri yanlışlıkla gerçekleştirmediğinizden emin olun.

Kendinizi görev ve bağımlılıklarla aşırı yüklenmiş halde bulursanız, üstlerinizle konuşup departmanınızda bunun neden olduğunu anlamak için durmanız faydalı olacaktır. Örneğin, Veri Mühendislerinden sorumlu bir DevOps ekibiyseniz ve onların kendi liderleri varsa, sorumlulukları bölümünüz yerine kendi liderlerine devretmeniz mantıklı olabilir.

Anlaşmaları veya kurulum veya bakımla ilgili gizli ayrıntıları resmileştirmek ve insanları ilgili ekiplerine geri göndermek için spesifikasyonları ve gerekli belgeleri oluşturun.

Önceliklendirme ve Yetkilendirme

Öncelikler değişmeye devam ettiği için işleri halledemiyor olabilirsiniz. Şirketin tamamı iki haftalık sprintlerle çalışıyor ancak bu düzen artık size uymuyor ve siz de bunun değerini görmüyorsunuz. Zayıf öncelikler nedeniyle özellikler bir sprint içinde tamamlanamıyor.

Bu, hizmet odaklı ekipler için geçerlidir.

Kanban'ı veya su akışı yaklaşımını keşfetmeyi düşünün. Ekiplerimiz, süreçleri daha iyiye doğru değiştirmeyi deneme hakkına sahip olduğumuz ayrı adalar gibidir. Bir ay boyunca yeni yaklaşıma geçişi test edin ve ölçümlerinizi gözlemleyin. Deneyimlerime göre Scrum'ın bizim için uygun olmadığını fark etmek için birkaç hafta yeterliydi ve Kanban'a geçtik.

Önceliklerin artık haftada iki kez değişebilmesi nedeniyle pazara sunma süremiz önemli ölçüde azaldı ve bu da sorunları daha hızlı çözmemize olanak sağladı.

Daha sonra ekibi alan bölgelerine ayırmayı deneyin, ancak bunu çok ayrıntılı bir şekilde yapmayın.

Her ekip üyesini 70/30 kuralını izleyerek suya daldırın:

• %70'i ana yığına, projeye veya ürüne adanmıştır
• Diğer her şey için %30

Ekibinizde 5'ten fazla kişi varsa, tüm hizmet ve işlevleri kapsayarak bireylerin konuya daha hızlı dalmalarına olanak tanıyacaksınız.

Bu neyi başarıyor?

Bir geliştiricinin zaten iyi bir anlayışa ve konuya hakim olduğunu görürseniz, her şeyi kendiniz yapmak yerine bazı görevleri ekibe devretmenize olanak tanır. Algoritmanın ve entegrasyonların tamamını açıklamanıza gerek yok! Zaten her şeyi biliyorlar!

Zaman Yönetimi ve Verimlilik

Ekip Çalışma Zamanını Nasıl Planlıyor?

Basit bir şeyle başlayalım: Ekip olarak nasıl çalışıyorsunuz? Tahminlerinize ve görevleri nasıl değerlendirdiğinize bir göz atın. Her şey yolunda mı? Belki iyileştirme veya iş yükü katsayısının eklenmesi için yer vardır?

İş yükü katsayısı, destek için olası dikkat dağıtıcı unsurları göz önünde bulundurarak her takım üyesinin bir sprint veya hafta boyunca nasıl yüklendiğinin anlaşılmasına yardımcı olur. Örneğin, kendi ürününüzün bakımını üstlenen bir hizmet ekibiyseniz, diğer ekipler sizden yardım isteyebilir veya iyileştirmeler talep edebilir, bu da sprint içinde iletişim için zaman harcanmasına neden olabilir.

Aynı şey hatalarla uğraşmak için de geçerli; Üretim ortamındaki acil sorunları çözmek için sık sık dikkatinizi dağıtabilirsiniz.

Şimdi katsayıya dönelim. Her birimizin en az 5 günün 1'inde bir sorunu çözmek için bir sohbete veya toplantıya çağrıldığını kabul edersek, bunu planlama sırasında dikkate alın. Bu şekilde, ekibe gerçekten fayda sağlayan görevleri gerçekçi bir şekilde gerçekleştirmeyi başaracak ve potansiyel olarak kod yazmaya zaman ayıracaksınız.

Pomodoro tekniğini deneyin.

Çığır açan hiçbir şey yok; Telefonunuzda, 45 dakika gibi belirli bir zaman aralığında bir göreve odaklanmanıza olanak tanıyan bir uygulama kullanmanız yeterlidir. Özel bir şey yok sanırım.

İzleyicileri kullanın.

8 çalışma saatinizi neye harcadığınıza ilişkin bir araştırma yapın; hafta veya ay boyunca faaliyetlerinizin her saatini ve dakikasını kaydedin. Dikkatinizi dağıtan faktörleri keşfedebilir veya öğle yemeğinden sonra 15 dakikalık bir yürüyüş yapmanın daha verimli çalışmanızı sağladığını fark edebilirsiniz; belki de başarının anahtarı budur? Veya art arda üç toplantınız varsa, kendinizi bir saat boyunca hiçbir şey yapmadan, sadece spesifikasyonları okurken mi buluyorsunuz? Belki senin için zorlayıcıdır?

Önemli olan ne yaptığınızı dikkatle incelemektir ve geliştirilecek alanları belirleyeceğinize inanıyorum.

Teknik Açıdan Zorlu Projelere Katılım

Sistem tasarımı veya mimari çözümlerle ilgili toplantılara katılamayacak durumdaysanız takipleri veya belgeleri okuyun. Sorunu nasıl ve neyin çözdüğünü anlamaya çalışın. Bu tür toplantıları kaçırmamak ve kendinizi mümkün olduğunca teknik konulara kaptırmaya çalışmak tercih edilir.

Kodun derinlemesine incelenmesini gerektiren projeleri veya proje yönlerini seçin. Bu, yeni teknolojiler ve geliştirme metodolojilerinden haberdar olmanıza yardımcı olacaktır.

Sizin için RnD

Projede sorunlu veya işlevselliğin geliştirilebileceği alanlar fark ederseniz prototip oluşturmaktan çekinmeyin. Bu yalnızca önerilen değişiklikleri görselleştirmenize olanak sağlamakla kalmayacak, aynı zamanda ekibe tartışma ve karar alma için somut materyal sağlayacaktır.

Ana amaç sadece fikirleri sergilemek değil, gerçekten önemli veya faydalı oldukları kanıtlanırsa bunları projeye uygulamaktır. Örneğin, her zaman eski hizmetleri Java 1.8'den sürüm 21'e geçirmeyi hayal ettiyseniz, neden bunu denemiyorsunuz? Bir prototip oluşturun, bunu ekibe gösterin, çözümünüzü geliştirin ve gelecekte başvurmak üzere tüm süreci kapsamlı bir şekilde belgeleyin.

Bu yaklaşım, yalnızca teknik iyileştirmelerin uygulanmasına değil, aynı zamanda ekip içinde olası değişikliklere ilişkin ortak bir anlayış yaratılmasına da yardımcı olur. Böylece projeye yapıcı bir katkıda bulunabilir, projenin etkili bir şekilde gelişmesini sağlayabilir ve yeniliği teşvik edebilirsiniz.

İnceleme Noktası!

Bu aşamada kod yazmak, çözüm önermek için birkaç saatiniz olacak ve ardından biraz nefes alabilirsiniz. Tabii ki, liderlik pozisyonu her ikisini de yapmanıza izin vermeyecektir ve eğer odak noktanız hâlâ gelişimse, geri dönüşü düşünmeye değer olabilir.

Bunda yanlış bir şey yok; bunda başarılı olsanız bile, yönetimin sizin için sıkıcı hale geldiğini fark etmek sorun değil. Sadece bu noktada sizin için çekiciliğini kaybetmiş durumda.

Hala Biraz Boş Zamanınız Varsa

Öğrenme ve Kişisel Gelişim

Teknik literatürü okuyarak, eğitim kurslarını keşfederek ve teknik konferanslara katılarak kendinizi sürekli eğitin. Bu, yazılım geliştirmedeki en son trendleri ve en iyi uygulamaları takip etmenize yardımcı olacaktır.

Teknik literatürü okumak, yeni teknolojilerin, metodolojilerin ve en iyi uygulamaların derinliklerine inmek için eşsiz bir fırsat sağlar. Bu, yazılım geliştirmenin çeşitli yönlerini kapsayan kitapları, makaleleri, blogları ve diğer materyalleri içerebilir.

Eğitim kursları almak, yeni konular ve teknolojiler hakkında bilgi edinmenin yapılandırılmış ve sistematik bir yoludur. Çevrimiçi kurs platformları farklı programlama dilleri, çerçeveleri ve kavramları üzerine geniş bir kurs yelpazesi sunar.

Teknik konferanslara katılmak, yalnızca en son trendler ve yenilikler hakkında bilgi edinme fırsatını değil, aynı zamanda sektör profesyonelleriyle etkileşimde bulunma fırsatını da sunar. Konferanslar deneyimlerin paylaşılması, zorlu konuların tartışılması ve teknik topluluk içinde bağlantılar kurulması için bir platform sağlar.

Özetle, okuyarak, ders alarak ve konferanslara katılarak sürekli öğrenme, yazılım geliştiricilerin yalnızca en son trendleri takip etmelerine değil, aynı zamanda yeni bilgi ve becerileri günlük işlerine aktif bir şekilde entegre etmelerine de olanak tanır.

Örnekler: leetcode, Udemy veya Youtube (bazen orada gerçekten iyi ÜCRETSİZ içerik bulabiliriz!).

Kişisel Projeler Üzerinde Çalışmak

Mümkünse boş zamanlarınızda kişisel projeler üzerinde çalışın. Bu yalnızca programlama becerilerinizi geliştirmekle kalmayacak, aynı zamanda asıl işiniz için yeni fikirler kaynağı olarak da hizmet edecektir.

Ayrıca bu aktiviteyi makaledeki Ar-Ge noktasıyla birleştirmek, yaratıcılık ve yenilikçilik için ekstra bir teşvik olabilir.

Kişisel projeler üzerinde çalışmak, becerilerinizi pratik senaryolarda uygulamanıza, yeni teknolojileri denemenize ve gerçek dünyadaki sorunları çözmenize olanak tanır. Bu projeler, kendi web uygulamalarınızı geliştirmeyi, açık kaynaklı projeler oluşturmayı veya ilgi çekici yan projelere katılmayı içerebilir.

Bu aktiviteyi daha önce bahsedilen araştırma ve geliştirme (RnD) çalışmasıyla entegre etmek, prototipler oluşturmanıza ve bunları iş yerinizde sergilemenize olanak tanır. Açık kaynak geliştirmeye katılmak gibi projenizi halka açmak yalnızca becerilerinizi geliştirmekle kalmaz, aynı zamanda değerli profesyonel bağlantılar kurmanıza ve yaratıcılığınızın tanınmasına da katkıda bulunur.

Çözüm

Ekip lideri olarak kodlamaya zaman bulmak, bilinçli çaba ve etkili öncelik yönetimi gerektirir. Rolünüzün sadece ekibe doğrudan liderlik etmek olmadığını, aynı zamanda teknik becerilerinizi tatmin edici bir seviyede tutmayı da içerdiğini unutmayın.

Zor olacak, size iyi şanslar diliyorum!