Geliştiriciler sorumsuz oyun çocuklarıdır!
Geliştiricilere dikkat etmezseniz, bütün gün ortalığı karıştırırlar. Nasıl başa çıkılır bununla?
Oldukça sık bana şu soru soruluyor: “Ekipte teknoloji seçimini nasıl kontrol ediyorsunuz?” Görüş, geliştiricilerin aslında teknoloji kararları vermemesi gerektiği tartışmasında ortaya çıkıyor. Aksi takdirde proje, akla gelebilecek tüm teknolojiler kullanıldığı için kaosa ve anarşiye sürüklenir. Ne de olsa, geliştiriciler sorumsuz oyuncaklar! Ancak projeler kaosa ve anarşiye dönüştüğünde zarar gören geliştiricilerdir. Bu nedenle, teknolojiyi makul bir şekilde kullanmak onların çıkarınadır. Ancak, bu nadiren tartışmada rol oynar.
Bir sonraki yükseltme seviyesi, “14 yaşındaki kızım da programlar ve bu geliştiricilerden daha hızlı yapabilir” veya “Modern fikirleri burada geliştiricilerle zaten uygulayamazsınız” gibi ifadelerdir. Geliştiriciler yüksek eğitimli uzmanlardır. Yazılım, insanların üretebileceği en karmaşık şeylerden biridir. Bu tür açıklamaların sadece saygısızlık olduğunu düşünüyorum.
kontrol
Ancak geliştiricilerin aslında sorumsuz playboylar olduğunu varsayalım. Yani görünüşe göre sadece kontrole güvenebilirsin. Bu, örneğin hangi teknolojilerin kullanılacağına veya ideal olarak otomatik kontrollerle standartların kodlanmasına ilişkin net yönergelere yol açar.
Bu tür önlemler kesinlikle yararlı olabilir. Ancak kontroller genellikle yetersiz çalışıyor: İlk büyük projelerimden birinde, birlikte bazı kodlama yönergeleri tanımladık ve bunları araçlarla otomatik olarak kontrol ettik. Bir süre sonra herhangi bir ihlal olmadı, ancak yalnızca görünüşte: aslında, bazı geliştiriciler araçları belirli kod noktalarında devre dışı bıraktı. Kontrol etmek ve kontrolü alt üst etmek için beyhude bir yarış başlayabilir.
Yani tabii ki daha ileri gidemezsin. Denetim de ölçeklenebilir değildir: Tek bir kişi olarak tüm ekibin ürettiği her şeyi anlayamaz, denetleyemez ve düzeltemezsiniz. Kendi üzerinde hak iddia eden başarısız olmalıdır. Uygun bir şekilde, bu blogda daha önce bahsedilen “DevOps Durumu” çalışmasında yer alan ampirik çalışma, ağır bir değişiklik sürecinin yazılım geliştirme organizasyonunun performansını olumsuz yönde etkilediğini gösteriyor. Yani daha fazla kontrol ve aşırı yükleme kesinlikle çözüm değil.
çözümler
Kulağımda Fred George’dan bir cümle var: “Geliştiriciler bir şeylerle uğraşmak istiyor. Bu yüzden onlara kurcalayacakları şeyler verin!” Bu, modelinde geliştiriciler için büyük miktarda özgürlük sağlar. Ayrıca, yalnızca kod üzerinde değil, doğrudan artan satışlar veya müşteri memnuniyeti gibi iş hedefleri üzerinde de çalışırlar. Modelin adı “Geliştirici Anarşisi”dir. Bu nasıl çalışır? Ne de olsa, geliştiriciler sorumsuz oyuncaklar!
Belki de sonuçta sorumlu insanlardır? Ne de olsa, özel hayatlarında, örneğin bir ev inşa ederken, riski kendilerine ait olmak üzere önemli bütçeleri yöneten epeyce müteahhit tanıyorum. Becerileri de onlar için önemlidir. Örneğin, boş zamanlarında da kod yazıyorlar veya akşam toplantılarına ya da hafta sonu kod inzivalarına katılıyorlar. Bu, boş zamanlarında bile becerilerini sürekli olarak geliştirmek için yüksek düzeyde bir motivasyon gösterir.
saygı
Bence bu durumdan çıkmanın tek yolu öncelikle geliştiricilere ve onların niteliklerine saygı duymaktır. Onları kod uzmanları olarak görüyorum ve öyleler.
Güven ve yetki verme davranışı değiştirebilir ve sorumlu eylem için bir ön koşul olabilir. Geliştiriciler anlamsız buldukları kararları uygulamak zorunda kalırsa, bu kararları baltalamaya çalışacaklardır. Tüm proje anlamsız görünüyorsa, oynamak için köşeler arayacaklar. Ancak geliştiriciler kararları kendileri verirse, farklı davranmak zorunda kalacaklar. Sadece eleştiremezsin, kendin yapıcı olmalısın. Ayrıca sonuçlarla yaşamak zorundalar, bu yüzden kararlar hakkında dikkatlice düşünecekler.
Bence “İnanç Sıçraması” daha fazla güvene doğru atılan bir adım için iyi bir terim: geliştiricilere inanıyor ve bilinmeyene atlıyorsunuz, bu da elbette cesaret istiyor.
Prosedürünüz optimize edilebilirse, kontrolün bir faydası olmaz çünkü atlatılabilir. Bunun yerine, odak noktası bilgi alışverişi ve transferi olmalıdır. Geliştiriciler hem hedefleri hem de teknik uygulamalarını anlamışlarsa, teknik uygulama kavramlarını da takip etme olasılıkları nispeten yüksektir. Ve değilse, belki de sonuçta iyi bir fikir değildi? Belki daha iyi bir taneleri vardır? Bu, açık ve üretken tartışmalara ve iyileştirmelere izin verir.
Bu şekilde kontrol, ilgili tarafların farklı bakış açılarının değiş tokuş edildiği ve hatta tek başına kontrollerle mümkün olandan daha iyi çözümlerin üretildiği işbirliğinin yerini alır. Geliştiriciler aynı zamanda kendi alanlarında uzman kişilerdir.
yönetmek
Şimdi, elbette, yönetimin ve mimarların nihayet geliştiricilere gerekli saygıyı ve güveni göstermesi gerektiği söylenebilir – ve sorun nihayet çözüldü!
Ancak saygı tek yönlü bir sokak değildir. Geliştiriciler ayrıca yönetime ve mimarlara saygı duymalı ve güvenmelidir. Aksi takdirde, göz seviyesinde tartışmalar pek mümkün değildir. Onlar da uzmanlar, sadece farklı alanlarda. Örneğin, mimarlar daha büyük sistemler yapılandırabilir ve yönetim organizasyonla ilgilenebilir.
tl; doktor
Karşılıklı saygı ve güven, başarılı bir işbirliğinin temelidir.
Makalenin önceki bir versiyonuna yaptıkları yorumlar için meslektaşlarım Christoph Iserlohn, Robert Glaser, Anja Kammer, Michel Krämer, Martin Kühl, Stefan Tilkov, Hermann Schmidt ve Benjamin Wolf’a çok teşekkürler.
()
ana sayfaya