Planlama ve öncelik belirleme

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çebilirsiniz.

Hedefleri ve önemli senaryoları belirleme

Bir platform mühendisliği liderinin bir keresinde "Bundan elde etmek istediğim bir şey olana kadar platform mühendisliği için bir şey yapmam". - Peter, platform mühendisliği Lideri, Çok Uluslu Teknoloji Şirketi

Özelliklerin veya özelliklerin kullanımdan kaldırma denetim listesine bakmak yerine, platform mühendisliği çalışmalarınızın hedeflerini belirleyerek başlayın. Zaman içinde hedefleri sürekli olarak planlayabilir ve güncelleştirebilirsiniz. Ancak, platform mühendisliği yolculuğunuza yatırım yapmaktan elde etmek istediklerinizi net bir şekilde ifade etmek, kurumsal destek oluşturmaya yardımcı olmak için çok uzun bir yol kat edebilir.

Hedeflerinizi düşünürken, bunları belirli bir geliştirme ekibinin özellikleri yerine platform mühendisliği çalışmanızla ilgili iş hedefleriyle kapsam olarak belirleyin. Örneğin, aşağıda bazı yaygın üst düzey platform mühendisliği hedefleri verilmiştir:

• Uygulama kalitesini artırın, yayın sırasında hataları ve sorunları azaltın.
• Güvenliği geliştirin, güvenlik olayı sayısını azaltın veya üretimde bir kez algılanan CVE'ler .
• Lisanslama, erişilebilirlik, gizlilik veya resmi düzenlemeler 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.

Bu hedeflerin tümü uzun vadeli hedefler olsa da, öncelik belirleme konusundaki düşüncelerinizi yönlendirdiğinden en önemli hedefinizi seçmek kritik önem taşır.

Daha da iyisi, hedefleri ve önemli sonuçları (OKR) liderliğiniz ve iç iş ortaklarınız ile kabul etmek, yatırımlarınızın geçerli aşaması için ölçülebilir hedefler oluşturmanıza yardımcı olabilir. (Kuruluşunuz başka bir şey kullanıyorsa diğer planlama yaklaşımları benzer kavramlara sahiptir.) En iyi OKR'ler, özniteliği ortadan kaldırdığı için somut bir ölçüye göre ayarlayabileceğinizlerdir.

Senaryolar ve yapılacak işler

Hedeflerinizi belirledikten sonra kapsam ve yol haritanızı çıkarmak için kullanacağınız temel senaryoları belirleyin. Örneğin, bu senaryolara ve yapılacak 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
• Sağlama araçları
• Ortak altyapı sağlama
• Ekip üyelerine erişim verme
• CI/CD işlem hatları oluşturma
• Geliştirme altyapısı sağlama
• "Kanalları" test etmek için ilk dağıtım

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

• Araçlara, hizmetlere erişimi güncelleştirme
• Geliştirici makinesini ayarlama
• Uygulamalarda ekip üyesini artırma
• Uygulama korumalı alanı ortamı oluşturma
• İlk çekme isteğini oluşturma ve gözden geçirme

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

• Kurumsal en iyi yöntemleri ve kullanılabilir seçenekleri anlama
• Kod yapıtları olarak altyapıyı güncelleştirme/ekleme
• Uygulama korumalı alanı ortamı oluşturma
• Güncelleştirmeleri doğrulama
• Değişiklikleri diğer ortamlarda kullanıma sunma

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

• Kurumsal en iyi yöntemleri ve kullanılabilir seçenekleri anlama
• Yeni aracın kullanılmasını isteme
• Araçlara ekip üyesi erişimini güncelleştirme
• (Varsa) Aracı istemcilerle veya CI/CD işlem hatlarıyla tümleştirme

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

• Kullanılabilir API'leri, SDK'yı, hizmetleri keşfedin
• Gereksinimleri karşılayıp karşılamadığını değerlendirme
• Sorularınız için sahip olan ekiple bağlantı kurun
• Uygulama için benimseme

Senaryo: Bir operasyon olayına yanıt verme

• Sorun bildirimi
• Uygulama kodunun veya altyapıyla ilgili olup olmadığını (veya her ikisini birden) değerlendirme
• 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 / Ortak Güvenlik Açıkları ve Etkilenmeler (CVE) bildirimi

• 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 bildirimi
• (İsteğe bağlı) Koordinasyon Kullanıcıların yeni ara aracına geçişi

Senaryo: Yeni uygulama modelini / mimarisini tanımlama / kullanıma sunma

• Pilot önerilen mimari
• Pilot sonuçlara göre ayarlama
• En iyi yöntemleri güncelleştirme belgeleri
• Şablon oluşturma, otomasyon güncelleştirme, ilkeler, idare

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

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

Birçok senaryo birden fazla rol için geçerlidir, bu nedenle senaryolarınızın ne kadar geliştireceğini nasıl anlayacağınıza ilişkin ölçümleri de düşünmek istersiniz.

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ı anlamaya çalışmanızı öneririz. 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ı gidermezse, benimsenme veya takdir edilme olasılıkları düşüktür.

Bu tür bir araştırma yapmanıza yardımcı olabilecek çeşitli yaklaşımlar vardır. Bunlardan biri Hipotez İlerleme Çerçevesidir. 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üşme ve sonra işlerini gerçekleştirmedeki en büyük sorunlarını belirleme konusunda çok şey kazanabilirsiniz. Bu sorunların ne olduğunu iyice anladıktan sonra, bunları çözmeye yönelik kavramlar ortaya çıkmaya başlayabilirsiniz. Bu, geliştiricilerin kullanmak istediği özellikleri derlemenize yardımcı olur.

Bu işlemi hızlı bir şekilde tekrarlayabilmek için doğrudan dahili geliştirici platformu ekibinizde müşterinin sesini temsil edebilecek birini tanımlamak istersiniz. Bu role genellikle ürün yöneticisi adı verilir (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 edebilecek ve ne zaman daha fazla görüşme yapmanız gerektiğini saptayabilecektir. Bu, çevikliğinizi artırırken iç müşterilerinize değer sunmaya odaklanmanızı sağlar.

İlk yatırımlarınız için durumunuzu belirleme

Doğrulanmış bir dizi sorun ve kavram elde ettikten sonra, yatırım yapmak için bir bağımsız değişken oluşturmak için iyi bir konumda olursunuz. Ancak, ön yatırım düzeyini ve gerekli uzun vadeli bakımı göz önünde bulundurun. Sorunu çözebilecek en düşük efor çö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 bir MVP) belirledikten sonra, geri bildirim sağlamaya istekli bir dizi geliştirme ekibiyle pilot uygulaması yapabilirsiniz. Pilot çözümünüz bu ekiplerin karşılaştığı sorunları çözüyorsa, etkileşim kurmak isteyen birini bulmakta sorun yaşamamalısınız.

Yeni bir yetenek 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 kanıtlama

İlk yatırımınızı yapıp yapmadığınızdan bağımsız olarak, ne kadar başarılı olduğunuzu ölçmek ürün zihniyetinin önemli bir parçasıdır. Hedeflerinize ulaşıp ulaşmadığınızdan emin olmanıza yardımcı olmakla kalmaz, aynı zamanda mütevazı yatırımlarla küçük başarılar bile daha büyük yatırımların üzerine inşa etmek 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 olduğundan ve paydaşların iş hedeflerine uygun olduğundan emin olmaya çalışıyorsunuz. Ölçümler, iş değeri sağladığınızı kanıtlamak için olguları kullanmanıza olanak sağlar. OKR'leri ayarlamak, ö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 temel ayarlamak üzere ayarlayabilirsiniz.

Aşağıda, üzerinde çalıştığınız ekiplerin oluşturduğunuzdan değer alıp almadığını belirlemek için ölçebileceğiniz iyi bilinen ölçümlere örnekler verilmiştir. Sizin ve geliştirme ekibi müşterilerinizin hedeflerinize ulaşıp ulaşmadığını ölçmenize yardımcı olanlardan sıfır. Ö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 süresi: İlk çekme isteğinin tamamlanması için ortanca gün sayısı (ekleme), derleme ve test işlemleri için ortanca dakikalar (örnek: CI), çekme isteğini birleştirmeye yönelik ortanca süre.
• Yazılım kalitesi: Geliştirme başına aylık oluşturulan olaylar (sorunlar(geliştirme sayısı için normalleştirilmiş sayı), düzeltme 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: "Elimden gelenin en iyisini yapma gücüm var", "çoğu gün yaptığım iş tarafından enerjileniyorum", "yaptığım iş benim için anlamlı."

Ardından 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 watch.

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

Alan	Örnek ölçümler
Yazılım teslim performansı	DevOps Araştırma ve Değerlendirme (DORA): Sağlama süresini, dağıtım sıklığını, değişiklik başarısızlığını, hizmeti geri yükleme süresini (MTTR) değiştirme
Işlem	DORA (MTTR), hata arasındaki ortalama süre (MTBF), ortalama kabul 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, özellikle de OKR'lerinizi destekleyenler olmak üzere tanımladığınız temel hedefler için kritik ölçümlere odaklanmanız önemlidir. Application Insights gibi OpenTelemetry tabanlı ürünler yardımcı olabilir. Ne olursa olsun, 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şılamayacağı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 de haberdar olmanıza yardımcı olur.

Diğer ipuçları

Nasıl başladığınıza bakılmaksızın aşağıdaki yönergeleri göz önünde bulundurun.

Değişiklik planı

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

Yeni uygulamalarla fikirleri doğrulama

Genel olarak, yeni platform veya platform özelliklerinizi pilot olarak kullanırken makul boyutta yeni uygulamalarla başlamak en iyisidir. Bu, platformunuzu bir ürün olarak yönetme deneyimi de sunar. Devam ettikçe öğreneceğiniz için yeniden platform oluşturma projelerinden çekinin ve mevcut büyük uygulamaların genellikle yalnızca yeniden platform oluşturma çalışması sırasında ortaya çıkarılan benzersiz ihtiyaçları vardır. Bu nedenle, başarınızı bu tür çabalarla eşleştirmek, beklenti uyuşmazlıklarına veya geç hataya neden olabilir. Daha yeni bir şeyle başlamak, sağladığı değerin yönüne güvenmenizi sağlayabilir. Bu, bu daha büyük çabalarla uğraşma riskini azaltır. Başka bir şekilde ifade edin, insanların doğru şekilde başlayıp doğru şekilde kalabileceğine güveniyorsanız deneyimden öğrendiklerinizle doğru bir kampanya oluşturmak daha kolay hale gelir. Bu yaklaşım mümkün değilse, her şeyi aynı anda değiştirmeye çalışmak yerine dikkatli analizler yapmak, beklentileri ayarlamak ve artımlı olarak adımlamak istersiniz.

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 düşük ayrıcalık ilkesini varsayın

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

Kontrollü 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 el ile iş akışı, fikirleri pilot olarak kullanmak için harika bir yol olabilir.

Uygulama Platformu özelleştirmesini simge durumuna küçültme

Yazılım satıcılarının zaman içinde yayınladığı özellikler tarafından tutulabilecek özel derleme uygulama platformu özelliklerinden kaçınmaya çalışın. Örneğin, çalışma zamanı barındırma, hizmet 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 olacaktır.

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