Risk Yönetimi Paradoksu: Kontrolü Bırakarak Ekiplerinizi Etkinleştirin

Brett Luckabaugh, Hesap Müdürü, Contino

Herkes, “bir şeyi seviyorsanız, bırakın gitsin.” ifadesine aşinadır. u ‘ya geri dönerse, sonsuza kadar senin. Eğer değilse, asla olması gerekmiyordu. ” BT Riski bunun gibi bir çok şey olabilir, kulağa çılgınca gelebilir ama beni bir saniyeliğine dinleyin. Günümüzde kuruluşlar, Agile, DevOps’u benimseyerek, Big Data ve ML / AI kullanarak BT mağazalarında daha iyi bir yere ulaşmak için çaresiz durumda. Bu şirketlerin çoğu, bu kavramların her birinin derinliklerine zar zor daldırırken, liderlik “modern BT uygulamalarını” dinleyen herkese duyurur. İyi haber şu ki, çoğu profesyonel bir organizasyonun genel yönünü anlıyor, ancak neredeyse hiç kimse nasıl yapılacağının ayrıntılarını bilmiyor. Bu blog, bunun nasıl yapılacağının bir yönünü ele alacak: riski yönetmek ve ekipleri etkinleştirmek.

Modern BT sektörünün en iyi uygulamalarını benimsemek, ekipleri etkinleştirmeye yönelik bir uygulamadır. Bunu yapmak için, o ekibin görüşüne giren şeylerin sahipliğini ve kontrolünü en üst düzeye çıkarmanız gerekir. Günümüzde pek çok takım, günlük işleri üzerinde çok az sahiplik ve kontrole sahip.

Burada, birçok geliştirme ekibinin tamamen sahip olduğu ve kontrol ettiği şeylerin kapsamlı bir listesi bulunmaktadır:

Nesne geliştirme ekiplerinin sahip olmadığı ve kontrol etmediği şeyler:

Bu duruma nasıl geldiğimizin anlatısını tanımlamak oldukça basit görünüyor. Şirketler, BT yeteneklerini artırmak için çok sayıda kişiyi işe almak zorunda kaldı. Bu insanlardan bazıları doğal olarak olması gerektiği kadar yetkin olmayacak ve sonuç olarak kötü şeyler olacak. Bütçeden tasarruf etme çabası içinde, habersiz yöneticiler, geleneksel olarak geliştirme görevlerini, çalıştırmaya yetecek kalitede kod üreten dış kaynaklı üçüncü taraflara atıyor – şimdilik. Aylar veya yıllar sonra, kritik bir güvenlik açığı, aşırı derecede modası geçmiş ortamlar (dışarıda tam olarak kaç tane Java 1.4 ortamı var?), Kimsenin bilmediği bir teknoloji yığınında yeni özellikler isteği gibi bir şey kaçınılmaz olarak acil bir duruma neden olur nasıl başa çıkılacağı ve daha fazlası! Şimdi, bu sorunun bir kısmını, BT alanındaki her şeyi bir ürün olarak değil bir proje olarak ele alan (Mik Kersten’in Project to Product kitabını öneriyorum) ve bu nedenle ana hedef, çalışan bir çıktı üretmek ve bu şeyin bakımı veya operasyonları hakkında endişelenmeme gerek yok çünkü bozulduğunda, hepimiz çoktan farklı bir projeye gideceğiz, aynı hataları tekrar tekrar yapacağız. tekrar. Daha sonra, doğal olarak, optikler, kaptan köşklerindeki her şeyin kalitesiz olduğunu ve her zaman bozulduğunu gösterdiği için BT kötü bir şöhrete sahip oluyor. Açıkçası, bu acil durumların durmasını sağlamak için kontroller koymalıyız!

Kaliteyi Politikayla Çözme

İşte politika yürüyüşü. “Satıcı A’nın X gereksinimini karşılaması gerektiği” ve “geliştiricilerin hiçbir üretim ortamına erişemeyeceği” ve “teknoloji yığını her ekipte standart olacak, bu nedenle bakım ekibimiz için aylarca sağlam ve kusursuz belgeler oluşturacağız. uyumlu olabilir ve yalnızca bir tür sorunla başa çıkabilir. ” Siz farkına varmadan önce, tüm organizasyonda silolarınız var ve çalışanların tatmin ve mutluluğu zeminden ve bodrum katından geçiyor. En azından herkes, durumu nasıl kontrol ettiğimizi CIO’ya gösterebilir, değil mi? Haykırışlar dışında, birçok nedenden ötürü hiçbir zaman tam olarak bu şekilde yürümez:

Bu noktada, umarım okuyucularımın en azından birkaç başını sallamışımdır. Bunun çoğu, bu “sağlam, güvenli” kuruluşları istila eden standart bir kanserdir. O kadar sağlam, o kadar güvenli ki, çok az şey yapılır. Risk ekipleri genellikle riskten kaçmazlar, riskleri geçersiz kılarlar. Sık sık şaka yapıyorum ki, veri merkezi elektrik hatlarına bir balta götürmek için riskten o kadar kaçınmalıyız. En azından bu şekilde saldırıya uğramayız.

Nasıl Başlanır

Bu delikten çıkmak için bir şey vermeli ve gerçekçi olarak verebilecek tek olası şey risktir. Bu, merkezi BT tarafından bir miktar kontrolün bırakılması ve geliştiricilere geri verilmesi gerektiği anlamına gelir. Evet, bu, geliştiricilerin potansiyel olarak bir şeyleri bozabileceği anlamına gelir. Evet, bu, teknik olarak bir geliştiricinin şirketin lisansına sahip olmadığı bir şeyi kurarak yasal risk oluşturabileceği anlamına gelir. Bu , geliştiricilerinizi potansiyel olarak zarar verebilecek kadar güçlendirmeniz gerektiği anlamına gelir. Bu, sizi böyle bir gelecek hayal edemeyecek kadar korkutuyorsa, sözleşme yaptığınız veya istihdam ettiğiniz geliştiricilerin kalitesine iyice bir göz atmanız gerekebilir. Geliştiriciler bu yetkiye layık olmadığında güçlü geliştirici yetkilendirmesi gerçekleşemez ve en uzun süre geliştiricilere atılan ürünler olarak davranılırsa, maymunları gerçek zeki insanların (sizin mimarlar, güvenlik uzmanları vb.) ve ardından “uygulamayı çalıştıran şeyleri” ortaya çıkarın. Burada biraz ikilemle karşı karşıyayız, çünkü bu tür bir gerçekliğe sıkışmış bir BT kuruluşunun tüm kötü performans gösterenleri ortadan kaldırıp ardından mutlak en iyi yetenekleri işe alacak bütçeyi bularak kendisini çekmesinin uzaktan bile mümkün olduğunu sanmıyorum. , böylece geliştiricinin yetkilendirilmesi riskini azaltır. Bu sorunu pratik bir şekilde ele almak için önce “kontrolünü kaybetmek neyin mümkün olduğuna” bakmalıyız

Merkezi kontrolün tüm görüntüsünü bir gecede tamamen kaldırmak akıllıca değildir; geliştirme ekipleriniz – ve hatta üstlerindeki yönetim katmanı – bu kadar çok sorumluluğu aynı anda nasıl üstlenecekleri konusunda hiçbir fikre sahip olmazdı. Bu nedenle, nüanslı bir yaklaşım gereklidir. Ayrıca, etkinleştirmenin herhangi bir süreç ve kontrol görünümünden kaçmamasını sağlamak için gerekli denetim gereksinimlerini gerçekleştirmek, kuruluşunuzun yeteneklerine bağlı olacaktır. Bir takımı etkinleştirmenin iyi bir yolunun bir örneğini burada bulabilirsiniz:

Uğraştıkları geliştirme paketi üzerinde kontrolü olmayan, yetkin bir geliştirme ekibini ele alalım. Ekibin önemli bir kısmı IntelliJ’e daha aşina olsa da belki de organizasyon Eclipse’i zorunlu IDE olarak belirlemiştir. IntelliJ için lisanslar maliyete mal olurken, bir kuruluşun ulaşması ve geliştiricilerin gerçekten kullanmaktan keyif aldığı bir araç için ödeme yapmayı teklif etmesi büyük bir iyi niyet işaretidir. Bu onların üretkenliğini ve iş mutluluğunu ölçülebilir şekilde artıracaktır. Eclipse ve IntelliJ’in kod çıktısı bariz bir şekilde farklı olmadığı için buradaki risk son derece düşük.

Riski gerçekten artıran bir başka örnek de, bir geliştirme ekibinin kendi geliştirmelerine ve hatta ortamları test etmesine ve sahip olmasına izin vermektir. Ekiplerin artık kendi ortamlarının kontrolünde olduğu yeni yetkiyi basitçe bırakabilirsiniz, ancak bunu yapmak ve başka hiçbir şey risk faktörünüzü kabul edilebilir olandan daha fazla artırmaz. Örneğin, artık ekipler arasında çok önemli bir çevre sapması yaşamanın gerçek riskini üstleniyorsunuz ki uygulama savunulamaz hale geliyor. Bu riski azaltmak için, yalnızca yürürlükte bir politikaya sahip olmak (“22 numaralı bağlantı noktasını halka açık internete açan herkes kovulacaktır”) değil, aynı zamanda bir tür otomatik (veya en azından manuel) denetim prosedürlerine sahip olmak önemlidir. bu politikalara gerçekten uyulup uyulmadığını kontrol etme yeri. Çevre politikasını otomatikleştirmenin tonlarca yolu vardır. Geçiş hakkı sahiplerinin riskten bu kadar kaçınmasının nedeni, bir şeyin geçmesine izin vermemesi durumunda hattaki onların kıçları olmasıdır, bu nedenle varsayılan davranış her şeye “hayır” demektir. Bu yanlış davranışı teşvik ediyor. Politika yöneticilerinin tekliflere hayır demelerine izin verilmemeli, otomasyon ve araçlar aracılığıyla politikaya bağlılığı sağlamanın en iyi yolunu belirleme yetkisi verilmelidir.

Bazı Örnekler

Geliştiricilerin kontrol etmediği şeylerin listesini alalım ve bir kuruluşun her bir öğeyi potansiyel olarak nasıl ele alabileceğine dair bazı hızlı örneklerden geçelim:

Ne geliştirmeli

Zaman çizelgesi

Bütçe

Teknoloji yığını

Geliştirme araç seti

Altyapı ve mimari

Geliştirme / test / QA / üretim ortamları

Kod ardışık düzenleri / Sürekli Teslimat

Veri katmanı / günlük yönetimi / raporlama

Güvenlik kontrolleri

İşlemler / bakım

Sonuç

Bir ekibe bir şeyin sahipliğini her verdiğinizde, geleneksel merkezi kontrolü kaybedersiniz. Çoğu kuruluş kontrolü kaybetmeye o kadar kendini kaptırmıştır ki, kontrole bakışlarını değiştirirlerse, aslında daha az yerine daha fazla kontrole sahip olacaklarını fark edeceklerdir. Uyum ekiplerinizin çalışma şeklini değiştirerek geliştirme ekiplerinizi yinelemeli bir şekilde etkinleştirerek, tüm kuruluşunuza önemli ölçüde özerklik sağlayabilir ve ekiplerinizden kesinlikle akıl almaz miktarda artan üretkenlik elde edebilirsiniz.

İlk olarak www.contino.io 12 Şubat 2019’da yayınlanmıştır.