Planlama ve öncelik belirleme

Platform Mühendisliği Yetenek Modeli'ni temel alarak platform mühendisliği çalışmalarınızın hedeflerini belirlemeyi, yaygın senaryoları incelemeyi ve başarıyı ölçmenin yollarını aramayı öğrenin. Hedeflerinizin kapsamını iş hedeflerine göre ölçerek başarıyı ölçün.

Hedefleri ve önemli senaryoları belirleme

Başlamak için önce Platform Mühendisliği Yetenek Modeli'ni kullanarak kuruluşunuzun bugün nerede olduğunu değerlendirin. Yatırım, benimseme, idare, sağlama ve yönetim, arabirimler ve ölçüm ve geri bildirim olmak üzere altı temel platform mühendisliği özelliğinde kuruluşunuzun nerede olduğunu grafik olarak görüntülemek için modeli kullanın. Tüm kuruluşlar bazı özelliklerde diğerlerine göre daha gelişmiştir. Kuruluşunuzun bugün nerede durduğunu öğrendiğinizde, hangi özellikleri büyütmek istediğinizi seçebilirsiniz. Daha fazla bilgi edinmek için bkz . Geçerli uygulamalarınızı değerlendirme ve gelecekteki hedefleri belirleme.

Platform mühendisliği hedeflerinizi zaman içinde sürekli olarak planlayabilir ve güncelleştirebilirsiniz. Platform mühendisliği yolculuğunuza yatırım yapmaktan elde etmek istediğiniz kazançlar konusunda net olmak, kurumsal destek oluşturmaya yardımcı olmak için uzun bir yol kat edebilir.

Bir platform mühendisliği lideri bir keresinde şöyle demişti: "Platform mühendisliği için ancak ondan kazanabileceğim bir şey olduğunda harekete geçerim." - Peter, platform mühendisliği lideri, çok uluslu teknoloji şirketi

Hedefleriniz hakkında düşünürken, bunları belirli bir geliştirme ekibinin özellikleri yerine platform mühendisliği çalışmanızla ilgili iş hedefleri olarak belirleyin. Yaygın üst düzey platform mühendisliği hedefleri şunlardır:

• Uygulama kalitesini artırın ve yayın sırasında hataları ve sorunları azaltın.
• Üretim ortamında güvenliği geliştirin, güvenlik olaylarının ve yaygın güvenlik açıkları ve zafiyetlerin (CVE'ler) algılanma sayısını azaltın.
• Lisanslama, erişilebilirlik, gizlilik veya kamu düzenlemesi gibi alanlarda daha iyi uyumluluk sayesinde riski azaltın.
• karmaşıklığı, ek yükü azaltarak ve iç kaynak uygulamaları aracılığıyla kod paylaşımını teşvik ederek iş zamanı değerini hızlandırın.
• Geliştirme veya operasyon maliyetlerini azaltın, yinelemeyi en aza indirin ve otomasyonu geliştirin.

Hedefiniz, öncelik belirlemeyi düşünme şeklinizi yönlendirdiğinden en önemli hedefinizi seçmek kritik önem taşır.

Daha da iyisi, liderlik ve iç iş ortaklarınız ile hedefler ve önemli sonuçlar (OKR) üzerinde anlaşmak, yatırımlarınızın geçerli aşaması için ölçülebilir hedefler oluşturmaya yardımcı olur. (Kuruluşunuz başka bir şey kullanıyorsa diğer planlama yaklaşımları benzer kavramlara sahiptir.) En iyi OKR'ler, öznerliği ortadan kaldırdığı için somut bir ölçüye göre ayarlayabileceğiniz değerlerdir.

Senaryolar ve yapılacak işler

Hedeflerinizi belirledikten sonra bekleyen işlerinizi ve yol haritanızı belirlemek için kilit senaryoları seçin. Örneğin, aşağıdaki senaryolara ve yapılacak ilişkili işlere bakın.

Senaryo: Yeni uygulama oluşturmaya başlama

• Kurumsal en iyi yöntemleri ve ilkeleri anlama ve uygulama
• Yeni depo oluşturma
• Kaynak sağlama araçları
• Ortak altyapı sağlama
• Ekip üyelerine erişim verme
• CI/CD işlem hatlarını kurun
• Geliştirme altyapısı sağlama
• "Kanalları" test etmek için ilk dağıtım

Senaryo: Mevcut bir takıma yeni bir üye ekleme veya kaldırma

• Araçlara ve hizmetlere erişimi güncelleştirme
• Geliştirici makinesi ayarlama
• Uygulamalarda ekip üyesini geliştirip eğitme
• Uygulama için bir korumalı alan ortamı oluşturma
• Önce çekme isteğini oluşturun ve ardından gözden geçirin.

Senaryo: Mevcut uygulama için altyapı ekleme veya güncelleştirme

• Kurumsal en iyi yöntemleri, kullanılabilir seçenekleri anlama
• Altyapıyı kod yapıtları olarak güncelleştirme veya ekleme
• Uygulama sandbox ortamı oluşturma
• Güncelleştirmeleri doğrulama
• Değişiklikleri diğer ortamlarda kullanıma sunma

Senaryo: Mevcut ekip için araç ekleme veya güncelleştirme

• Kurumsal en iyi yöntemleri, kullanılabilir seçenekleri anlama
• Yeni bir aracın kullanılmasını isteme
• Araçlara ekip üyesi erişimini güncelleştirme
• (Varsa) Aracı müşterilerin sistemleriyle veya CI/CD işlem hatlarıyla entegre etme

Senaryo: Mevcut API, SDK veya hizmeti bulma veya yeniden kullanma

• Kullanılabilir API'leri, SDK'yı veya hizmetleri bulma
• Gereksinimleri karşılayıp karşılamadığını değerlendirme
• Herhangi bir sorunuz varsa sorumlu ekiple bağlantı kurun
• Uygulama için kullanma

Senaryo: İşlem olayına yanıt verme

• Sorun bildirimi
• Uygulama kodunun veya altyapıyla ilgili (veya her ikisinin) olup olmadığını değerlendirin.
• Prod'u yansıtan korumalı alan ortamı oluşturma (farklıysa)
• Değişiklik yapma, test, bant dışı sürüm

Senaryo: Güvenlik olayını hızla düzeltme

• Sorun bildirimi
• Sorunların büyük kısmını değerlendirme (hangi sistemler)
• Müşterilerin doğrudan etkilenip etkilenmediğini anlama
• Prod'u yansıtan korumalı alan ortamı oluşturma (farklıysa)
• Değişiklik yapma, test, bant dışı sürüm
• Etkilenen herkesle iletişim kurma

Senaryo: Aracı kullanımdan kaldırma

• Araç kullanımını anlama
• Kullanıcıları kullanımdan kaldırma hakkında bilgilendirin
• (İsteğe bağlı) Kullanıcıların yeni bir ara aracına geçişini koordine etme

Senaryo: Mimarinin yeni uygulama modelinin piyasaya sürülması

• Önerilen pilot mimari
• Pilot sonuçlara göre ayarlama
• En İyi Uygulamalar Belgesini Güncelleme
• Şablon oluşturma, otomasyonu, ilkeleri ve idareyi güncelleştirme

Uygulama uyumluluğunu denetleme (GDPR, erişilebilirlik, altyapı standartları)

• Geçerli uyumluluk kurallarını anlama
• Uygulamanın kurallara uygun olduğunu doğrulama
• Sapmaların düzeltmeleri için son tarih belirleme
• Değişiklik yapma, test, yayın

Birçok senaryo birden fazla rol için geçerlidir. İyileştirmeyi nasıl ölçeceğiniz için ölçümleri düşünün.

Sorunlardan kavramlara

Ardından, geliştiricilerinizin ve diğer rollerinizin tanımladığınız senaryolar ve işlerle karşılaştığı en büyük sorunları anlayın. Algılanan boşlukları doldurmak için yeni ürünleri araştırmaya başlamak cazip olabilir, ancak bu ürünler büyük bir ağrı noktasını çözmezse, benimsenmeleri veya takdir edilmeleri pek mümkün değildir.

Bu tür bir araştırma yapmanıza yardımcı olabilecek Hipotez İlerleme Çerçevesi gibi çeşitli yaklaşımlar vardır. Hipotez İlerleme Çerçevesi gibi resmileştirilmiş bir süreç kullanmasanız bile, tartışmanın kapsamını belirlemek için yapılması gereken bir iş hakkında geliştiricilerle görüşmeli ve sonra çalışmalarını gerçekleştirirken en büyük sorunlarını tanımlamalısınız. Bu sorunların ne olduğunu iyice anladıktan sonra, bunları çözmek için plan yapmaya devam edin. Bu, geliştiricilerin kullanmak istediği özellikleri derlemenize yardımcı olur.

Bu işlemi hızla tekrarlayabilmek için doğrudan dahili geliştirici platformu ekibinizde müşterinin sesini temsil edebilecek birini belirleyin. Bu rol genellikle ürün yöneticisi olarak adlandırılır (farklı bir iş unvanına sahip olsalar bile) ve bilgileri arttıkça daha küçük kararlar için sonuçları doğru bir şekilde tahmin edebiliyor ve ne zaman daha fazla görüşme yapmanız gerektiğini saptayabiliyor. Bu, çevikliğinizi artırır ve şirket içi müşterilerinize değer sunmaya odaklandığınızdan emin olur.

İlk yatırımlarınızı gerekçelendirin

Doğrulanmış bir dizi sorun ve kavram edindikten sonra, nereye yatırım yapacağınıza karar vermek için iyi bir konumda olursunuz. Ancak, çözümleri değerlendirirken gereken ön yatırım ve uzun vadeli bakımı göz önünde bulundurun. Sorunu çözebilecek en düşük çaba çözümü, başlangıç için doğru çözüm olma eğilimindedir, ancak genellikle yatırımınızın başarılı olup olmadığına karar veren bakım çalışmasıdır.

Başka bir ifadeyle, gerçekten gerekmedikçe yolculuğunuzun sonraki aşamalarını hedefleyen çözümler oluşturmayın.

En ince uygulanabilir platformunuzu (TVP) (platformunuz için asgari uygulanabilir ürün gibi) tanımladıktan sonra, geri bildirim sağlamak isteyen bir dizi geliştirme ekibi ile pilot bir çalışma gerçekleştirin. Pilot çözümünüz bu ekiplerin karşılaştığı sorunları çözüyorsa, etkileşim kurmakla ilgilenen birini bulmakta sorun yaşamamalısınız.

Yeni bir özellik veya değişiklik pilotu yaparken bazı önemli ölçümleri yakalamanız gerekir. Böylece, kullanıma sunmadan önce kavramın başarılı olup olmadığını ölçebilirsiniz.

Başarıyı ölçme ve değeri onaylama

Başarınızın ölçülmesi, ürün zihniyetinin önemli bir parçasıdır. Mütevazı yatırımlarla küçük başarılar bile, daha büyük yatırımlar için temel oluşturabilir.

Örneğin, uyumluluk çalışmaları için fon veya satın alma güvenliğini sağlamak zor olabilir çünkü bunlar, iş değeri sunan geliştirme ekiplerine işletim vergisi olarak algılanabilir. Bir ürün anlayışı bu algıyı değiştirebilir. Bir ürün düşünce yapısıyla, iç geliştirici platformunuzun müşterilerinin mutlu olmasını ve paydaşların iş hedeflerine ulaşmasını sağlamaya çalışıyorsunuz. Ölçümler, iş değeri sağladığınızı kanıtlamak için olguları kullanmanıza olanak sağlar. OKR'lerin ayarlanması, özellikle öznel yanlılıkları ortadan kaldırmaya yardımcı olmak için kullanabileceğiniz ölçümleriniz varsa yardımcı olabilir. Bugün geçerli olan hiçbir şeyi ölçmeseniz bile, öğrenme OKR'sini bu temel bilindikten sonra iyileştirebileceğiniz bir taban çizgisi ayarlamak üzere ayarlayabilirsiniz.

Aşağıda, üzerinde çalıştığınız ekiplerin oluşturduğunuz işlerden değer alıp almadığını belirlemek için ölçebileceğiniz iyi bilinen ölçüm örnekleri verilmiştir. Kendinizin ve geliştirme ekibinizdeki müşterilerinizin hedeflerinize ulaşıp ulaşmadığını ölçmenize yardımcı olan unsurlara odaklanın. Örneğin, aşağıda platformunuzun etkili bir mühendislik kuruluşuna katkıda bulunup bulunmadığını değerlendirmenize yardımcı olan bir ölçüm kümesi verilmiştir:

• Hız / iş değeri: İlk çekme isteğinin tamamlanması için ortanca gün sayısı (uyum sağlama süreci), derleme ve test işlemleri için ortanca dakika (örnek: CI), çekme isteğinin birleştirilmesi için ortanca zaman.
• Yazılım kalitesi: Geliştirme başına aylık oluşturulan olaylar (sorunlar) (geliştirme sayısına göre normalleştirilmiş sayı), ortalama kurtarma süresi (MTTR), güvenlik sorununu araştırma ve düzeltme süresi.
• Platform kullanım kolaylığı: Net kullanıcı memnuniyeti (NSAT)
• Gelişen ekosistem: Ankete alınan şu soruların her biri için ortalama puan: "En iyi çalışmamı yapma gücüm var", "yaptığım iş tarafından enerjilendirildiğim çoğu gün", "yaptığım iş benim için anlamlı."

Daha sonra bu ölçümleri kuruluşa, takıma veya projeye göre ayırabilirsiniz. Başlamak için bazı temelleri ölçmeniz gerekir, ancak daha sonra platformunuzu geliştirirken bu ölçümlerin değişmesini izleyebilirsiniz.

Sizin veya sponsorlarınızın ölçmek isteyebileceği diğer ölçümler şunlardır:

Area	Örnek ölçümler
Yazılım teslim performansı	DevOps Araştırma ve Değerlendirme (DORA): Değişiklik bekleme süresi, dağıtım sıklığı, değişiklik başarısızlık oranı, Hizmetin Geri Yüklenme Süresi (MTTR)
Operations	DORA (MTTR), hata arasındaki ortalama süre (MTBF), ortalama onay süresi, son müşteri kullanılabilirliği, gecikme süresi, aktarım hızı ölçümleri, takım başına maliyet, dağıtım başına maliyet
Platform özelliği benimseme ölçümleri	Zaman içinde bir araç veya özellik kullanan ekip veya geliştirici sayısı, platformu kullanan depoların yüzdesi, en popüler şablonlar, işlem hatları vb.

Ölçümleri toplamak için zaman ve çaba gerekir, bu nedenle tanımladığınız temel hedefler için kritik ölçümlere, özellikle de OKR'lerinizi destekleyen ölçümlere odaklanmak önemlidir. Application Insights gibi OpenTelemetry tabanlı ürünler yardımcı olabilir.

Platform kullanım kolaylığını ölçmeyi ve düzenli olarak gelişen bir ekosisteme sahip olduğunuzu araştırmayı unutmayın. Bu ölçümler genellikle iç sistemler için kaçırılır ve katılım başarı için kritik öneme sahip olduğundan daha geniş iş hedeflerinizi karşılayıp karşılamadığınız konusunda önde gelen bir göstergedir. Ayrıca, bir sonraki adımda nereye gideceğiniz konusunda daha fazla müşteri geliştirmesi yapma zamanının geldiğinden emin olmanıza da yardımcı olur.

Diğer ipuçları

Nasıl başladığınıza bakılmaksızın, değişiklik planlamanız, pilotlar için yeni uygulamalarla başlamanız, mevcut kullanıcı deneyimlerini geliştirmeye odaklanmanız, en az ayrıcalık ilkesini benimsemeniz, denetimli denemeler planlamanız ve özelleştirmeyi en aza indirmeniz gerektiğini unutmayın.

Değişiklik planı

Hedef uygulama platformunuz zaman içinde gelişecek ve tüm mevcut yatırımlarınızı aynı anda geçiremeyebilirsiniz. Zaman içinde birden fazla çeşitlemeyi nasıl destekleyebileceğinizi düşünün ve değişikliği planlayın.

Yeni uygulamalarla fikirleri doğrulama

Yeni platform veya platform özelliklerinizi pilot olarak kullanırken makul boyutta yeni uygulamalarla başlayın. Bu, platformunuzu bir ürün olarak yönetme konusunda da deneyim sağlar. Devam ettikçe öğrendiğiniz için projeleri yeniden düzenlemekten çekinin ve mevcut büyük uygulamaların genellikle yalnızca yeniden platform oluşturma çabası sırasında ortaya çıkarılan benzersiz ihtiyaçları vardır. Bu nedenle, başarınızı bu tür çabalarla bağlamak, beklenti uyuşmazlıklarına veya son anda ortaya çıkan sorunlara neden olabilir. Daha yeni bir şeyle başlamak, size yönünüz ve sağladığı değer konusunda güven verebilir. Bu, bu daha büyük çabalarla mücadele riskini azaltır. Başka bir şekilde ifade etmek gerekirse, insanların doğru şekilde başlayıp doğru şekilde kalabileceğine güveniyorsanız deneyimden öğrendiklerinizle doğru seçim kampanyasını daha kolay hale getirebilirsiniz. Bu yaklaşım mümkün değilse, her şeyi aynı anda değiştirmeye çalışmak yerine dikkatli analiz yapmak, beklentileri ayarlamak ve artımlı olarak devreye girmek istiyorsunuz.

Yenilerini oluşturmadan önce kullanıcı deneyimleri için mevcut ağırlık merkezlerine odaklanın

Geliştiricilerin zaten beğendikleri ve kullandıkları bir şey ortaya çıktığında yeni özellikleri benimseme ve kullanmaya devam etme olasılığı daha yüksektir. Yeni özellikler sunmak için kavramları değerlendirirken mevcut ağırlık merkezlerini genişleten seçenekleri araştırdığınızdan emin olun. Örneğin düzenleyiciler/IDE'ler (Visual Studio, VS Code), DevOps paketleri (GitHub, Azure DevOps), mevcut CLI'ler veya mevcut bir iç portal, tamamen yeni bir portaldan veya diğer UX'lerden daha etkili olabilir. Daha fazla bilgi edinmek için bkz . Kullanıcı deneyimleri.

En az ayrıcalık ilkesini varsayın

Geliştiricilerin altyapı sağlama gibi işlemler için aşağı akış sistemlerine sınırlı erişimi olduğunu varsayalım. Self servis deneyimlerinde bu erişimi etkinleştirmek için denetimli bir yönteme ihtiyacınız olacaktır.

Denetimli denemeyi planlama

Büyük veya riskli değişiklikleri kullanıma sunulmadan önce denemeler yapın. Başlamak için her şeyin tamamen otomatik olması gerekli değildir. Otomatik olarak tetiklenen manuel iş akışı, fikirleri pilot yapmak için harika bir yol olabilir.

Uygulama platformu özelleştirmesini en aza indirme

Yazılım satıcılarının zaman içinde kullanıma sunduğu özelliklerle gölgelenebilen özel uygulama platformu özellikleri oluşturmaktan kaçının. Örneğin, çalışma süresi barındırma, servis ağları, kimlik sistemleri vb. Böyle olabileceğinden şüphelendiğiniz bir alanda acil bir gereksinim bulursanız, uzun süreli bakım nedeniyle birden çok uygulama seçeneği planlamak büyük olasılıkla zaman içinde geçiş yapmanıza neden olur.

İlgili içerik

• Yazılım mühendisliği sistemlerini uygulama