Geliştiriciler çocuk oynamaktan sorumsuz!
Geliştiricilerle ilgilenmezseniz, bütün gün saçmalayın. Nasıl yüzleşmelisin?
Soru nispeten sık sık soruluyor: “Ekipteki teknoloji seçimini nasıl kontrol ediyorsunuz?” Bu nedenle tartışma, geliştiricilerin aslında teknolojik kararlar almamaları gerektiğini göstermektedir. Proje aksi takdirde kaos ve anarşide ses çıkarır çünkü akla gelebilecek tüm teknolojiler kullanılır. Sonuçta, geliştiriciler çocuk oynamaktan sorumsuz! Mağdurlar, projeler kaos ve anarşiye battığında geliştiricilerdir. Bu nedenle, teknolojileri bir oran duygusu ile kullanmak sizin yararınıza. Bu nadiren tartışmada rol oynar.
Bir sonraki yükselme seviyesi, “ayrıca 14 yaşındaki kızım planladım ve onu bu geliştiricilerden daha hızlı alıyor” ya da “Buradaki geliştiricilerle modern fikirleri uygulayamazsınız” gibi beyanlar. Geliştiriciler yüksek nitelikli uzmanlardır. Yazılım, insanların üretebileceği en karmaşıktır. Sadece bu ifadelerin saygısız olduğunu düşünüyorum.
kontrol etmek
Ancak, geliştiricinin aslında oynamak için sorumsuz olduğunu varsayalım. Görünüşe göre sadece çek takabilirsiniz. Bu, örneğin ideal olarak otomatik bir inceleme ile kullanılan teknolojiler veya kodlama standartları ile ilgili net yönergelere yol açar.
Bu önlemler kesinlikle yararlı olabilir. Ancak kontroller genellikle sadece kötü çalışır: İlk önemli projelerimden birinde, bazı kodlama yönergelerini belirledik ve araçlarla otomatik olarak kontrol ettik. Bir süre sonra hiçbir ihlal yoktu, ama görünüşe göre: gerçekte bazı geliştiriciler araçları belirli bir koddaki devre dışı bıraktılar. Bu, anlamsız bir cinsin kontrollerin kontrolü ve kontrolü ile başlayabileceği anlamına gelir.
Açıkçası daha ileri gidemezsin. Ve kontrol bile azaltılmaz: tek bir kişi olarak tüm bir ekibin ürettiği her şeyi anlayamaz, kontrol edip düzeltemezsiniz. Kendiniz için isteğiniz varsa, başarısız olmalısınız. Buna uygun olarak, bu blogda daha önce bahsedilen “DevOps Eyaleti” çalışmasındaki ampirik inceleme, ağır bir değişim sürecinin yazılım geliştirme organizasyonunun performansı üzerinde olumsuz bir etkisi olduğunu göstermektedir. Bu nedenle daha fazla kontrol ve aşırı yük neredeyse çözüm değildir.
Çözümler
Fred George'dan kulağımda bir cümle var: “Geliştirici bir şeyleri folyolamak istiyor. Öyleyse size bir şeyler folyo ver!” Dolayısıyla modelindeki geliştiriciler için büyük bir özgürlük. Ayrıca, sadece kodla değil, aynı zamanda doğrudan satışlar veya müşteri memnuniyeti artışı gibi kurumsal hedeflerde de çalışırlar. Önemli bir şekilde, modele “geliştirici anarşisi” denir. Nasıl çalışabilir? Sonuçta, geliştiriciler çocuk oynamaktan sorumsuz!
Belki sorumlu insanlarsın? Sonuçta, özel hayattaki riskimdeki önemli bütçeleri yöneten bazı geliştiricileri, örneğin bir evin inşasında biliyorum. Becerileriniz de sizin için önemlidir. Ayrıca boş zamanlarını planlarlar veya akşam buluşmalarına veya hafta sonları kodun adımlarına katılırlar. Bu, boş zamanlarınızda becerilerinizi sürekli geliştirmek için yüksek bir motivasyon seviyesine tanıklık eder.
Saygı
Bence, bu durumun tek yolu geliştiricilere ve niteliklerine saygı duymaktır. Sizi kod için bir uzman olarak algılıyorum: nesiniz.
Güven ve delegasyon davranışı ve sorumlu eylemler için bir ön koşul değiştirebilir. Geliştiriciler gözlerinde anlamsız kararlar uygulamak zorundalarsa, bu kararları vermeye çalışacaklardır. Tüm proje anlamsız görünüyorsa, oynayabileceğiniz köşeleri bulacaksınız. Ancak, geliştiriciler tek başına karar verirse, farklı davranmaları gerekecektir. Basitçe eleştiremezsiniz, ama kendiniz yapıcı olmalısınız. Ayrıca sonuçlarla birlikte yaşamak zorundasınız, bu yüzden kararlar hakkında dikkatlice düşüneceksiniz.
Daha fazla güvene doğru bir adım için bir isim olarak, “inanç sıçraması” nın (inanç atlaması) iyi olduğunu düşünüyorum: geliştiricilere inanıyorsunuz ve bilinmeyene atlarsınız, bu da açıkça cesaret gerektirir.
Prosedür optimize edilebilirse, kontrol yardımcı olmaz, çünkü zayıflatılabilir. Bunun yerine, dikkat bilgi alışverişi ve transfer üzerinde olmalıdır. Geliştiriciler hem hedefleri hem de teknik uygulamalarını anladılarsa, teknik uygulama kavramlarını da takip edecek nispeten yüksek bir olasılık vardır. Ve eğer değilse: Belki bu iyi bir fikir değildi? Belki de daha iyi bir tane var? Dolayısıyla açık ve üretken tartışmalar ve iyileştirmeler olabilir.
Bu şekilde, bir işbirliği, dahil olanların farklı bakış açılarının değiştirildiği ve bu nedenle sadece kontrollerden mümkün olandan daha iyi çözümlerin ortaya çıktığı kontrol yerini alır. Geliştiriciler ayrıca kendi alanları için uzmandır.
yönetmek
Şimdi, elbette, yön ve mimarın nihayet geliştiriciye gerekli saygıyı ve gerekli güveni ödemesi gerektiği söylenebilir – ve sorun nihayet çözüldü!
Ancak, saygı tek yollu bir yol değildir. Geliştiriciler ayrıca yönetim ve mimarla yüzleşmeli ve onlara güvenmelidir. Aksi takdirde, daha fazla göz tartışması yoktur. Aynı zamanda bir uzmansınız, sadece başka alanlarda. Örneğin, mimar kuruluşla ilgilenen daha geniş sistemleri ve yönetimi yapılandırabilir.
TL; Dr.
Karşılıklı saygı ve güven başarılı işbirliğinin temelidir.
Meslektaşlarım Christoph Iserlohn, Robert Glaser, Anja Kammer, Michel Krämer, Martin Kühl, Stefan Tilkov, Hermann Schmidt ve Benjamin Wolf'a makalenin önceki bir versiyonuyla ilgili yorumlar için çok teşekkürler.
()