Bir BT ekibine liderlik etmek ve kod geliştirmek, birkaç temel ilkeyi paylaşır. Bu yazımızda yer alan üç yapısal ilkeye uyarak ekibinizin esnek, verimli ve her duruma hazırlıklı olmasını sağlayabilirsiniz.

Çapraz işlevli ekipler oluşturma ve bunu başarabilmek için geliştiricileri eğitme sürecinde geçerli olan üç yapısal ilke vardır. Bu ilkelerin işe alınan her geliştiriciye öğretilmesi, ekip liderlerinin işini oldukça kolaylaştırır.

1. İlke: Basitliği temel alın

Her geliştirme adımını olabildiğince basit tutmak kulağa klişe bir şeymiş gibi gelse de uyulması gereken en temel ilkedir. Örneğin, küçük bir performans artışı için zekice bir algoritma kullanarak hazırlanmış bir kod parçasını mevcut yazılımınıza eklediniz diyelim. Bu iyileştirme doğal olarak kod karmaşıklığını artıracaktır. Dolayısıyla ileride sistemde beklenmedik bir hata ortaya çıktığında sorunun nereden kaynaklandığını bulmaya çalışan ekibin işi de oldukça zorlaşacaktır. Basit ve anlaşılabilir kodlar kullanmak bu gibi ideal olmayan durumlarla karşılaştığınızda sizi çıkmazdan kurtarmaya yardımcı olur. Ayrıca üzerine geliştirme yapmayı ve ekibe yeni katılan geliştiricilerin adapte olmasını kolaylaştırır.

Basitliğin bir parçası da çalışanlarınızla dijital ortamda bulundukları yerde buluşmaktır. Şirketlerin ölçeği büyüdükçe değişime olan ihtiyaç da artar. BT ekiplerindeki genişlemenin iş süreçlerini yavaşlatmaması için biletleme sisteminde otomasyondan faydalanmak gibi çözümleri düşünebilirsiniz. Örneğin, ekipleriniz kendi aralarında Slack üzerinden iletişim kuruyorsa ve dokümantasyon için de Coda kullanılıyorsa, bu iki sistemi birbirine entegre ederek bilet oluşturma taleplerinin sadece Slack’te bir emoji gönderilmesiyle alınmasını sağlayabilirsiniz. Bu sayede ekip üyeleri ihtiyaç duydukları yardımı alabilmek için bir form doldurmaya ya da farklı bir yazılıma giriş yapmaya gerek duymadan zaten kullanmakta oldukları mesajlaşma aracının içinden basitçe sorunlarını çözecektir.

2. İlke: Başarısızlığa hazır olun

Bütün yazılımlar zaman zaman başarısız olur. Eğer önlemleri planlamayı başaramazsanız, başarısız olmayı planlıyorsunuz demektir. Gerektiğinde yedekleme planına kademeli olarak geçiş yapmak için sistemlerinizi tasarlayıp test ettiğinizde, birçok sorun kolayca önlenebilir veya hafifletilebilir.

Klasik bir örnek, nöbetçi mühendislerin üretim veri tabanlarına erişmesini sağlayan sistemdir. İyi tasarlanmış bir sistem, erişim ile birlikte temel denetim ve uyumluluk mekanizmalarını da içerir fakat bu mekanizma bozulursa, güvenlik politikalarınızla uyumlu olan ikincil bir sisteme ihtiyaç duyarsınız. Daha da önemlisi, bu ikincil erişim sistemi sık kullanılmadığından, sağlam bir dokümantasyon gerektirir ve ideali üç ayda bir olmak üzere periyodik olarak test edilmesi gerekir.

BT sistemleri, içe dönüktür ve aynı şekilde tasarlanmalıdır. Onay süreçlerinin her zaman bir yedeği olmalı, gerekli dokümantasyon hazırlanmalı ve değişiklik yapmak için hiç kimse gerekli anahtarları elinde tutmamalıdır.

Çalışan geçişlerini planlamak da aynı derecede kritiktir. BT departmanı her zaman en iyi uygulamaları dokümantasyon ve yedekleme planlarıyla birleştirmelidir. Bu, ekip üyeleri tatildeyken bir nöbetçi mühendise sahip olmak kadar basit olabilir. Şirketiniz ölçeklendikçe ve departmanlar genişledikçe bu uygulamalar da ölçeklenmelidir. Bu şekilde, kritik bir ekip üyesi şirketten ayrıldığında, sağlam bir dokümantasyon arşivi ve iş aktarım planı hazır olur.

3. İlke: BT altyapısını kod yazarken gösterdiğiniz titizlikle tasarlayın

Kod yazarken gösterdiğiniz özeni dahili sistemlerinizi tasarlarken de göstermelisiniz. Dikkatli bir planlama yapmadan ve ortaya çıkabilecek en kötü hataları ele almadan bir uygulamayı asla kullanıma açmazsınız. Aynı şey BT altyapısı için de geçerli olmalıdır.

Hiçbir deneyimli mühendis acil durumlar dışında bir sunucuya girip çalışan bir kod üzerinde değişiklik yapmayı kabul etmez. BT altyapınızı kurarken de böyle düşünmeli, yazılım kadar değerli bir şeymiş gibi tasarlamalı, acil durumlar dışında anlık değişiklikler yapmamalısınız.