Planlama ve önceliklendirme
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
Özelliklerin veya özelliklerin rote denetim listesine bakmak yerine, platform mühendisliği çalışmalarınızın hedeflerini belirleyerek işe başlayın. Hedefleri zaman içinde sürekli olarak planlayabilir ve güncelleştirebilirsiniz. Ancak, 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 olarak bir kez şöyle ifade etti: "Bundan kazanacağım bir şey olana kadar platform mühendisliği için bir şey yapmam." – 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, yayın sırasında hataları ve sorunları azaltın.
- Üretimde bir kez güvenliği geliştirin, güvenlik olayı sayısını azaltın veya Ortak Güvenlik Açıkları ve Açığa Çıkarmalar (CVE) algılandı.
- 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 yol açar. (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 kapsam ve yol haritanızı çıkarmak için temel senaryoları seçin. Örneğin, bu 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
- Sağlama araçları
- Ortak altyapı sağlama
- Ekip üyelerine erişim verme
- CI/CD işlem hatlarını oluşturma
- Geliştirme altyapısı sağlama
- "Kanalları" test etmek için ilk dağıtım
Senaryo: Mevcut bir ekime yeni üye ekleme veya 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 veya güncelleştirme
- Kurumsal en iyi yöntemleri, 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 veya güncelleştirme
- Kurumsal en iyi yöntemleri, 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 veya 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: İşlem olayına yanıt verme
- Sorun bildirimi
- Uygulama kodunun veya infra related (veya her ikisinin) olup olmadığını 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
- 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 ara aracına koordinasyon geçişi
Senaryo: Mimarinin yeni uygulama modelinin piyasaya sürülması
- Pilot önerilen mimari
- Pilot sonuçlara göre ayarlama
- En iyi yöntemleri güncelleştirme belgeleri
- Şablon oluşturma, otomasyonu 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 oluşturma
- Değişiklik yapma, test, yayın
Birçok senaryo birden fazla rol için geçerlidir, bu nedenle senaryolarınızın ne kadar iyiye doğru ilerleteceğini anlamak için ölçümleri düşünmeniz gerekir.
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 bakı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 ç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üş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 saptayabiliyorlar. 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 edindikten sonra, nereye yatırım yapılacağına 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 bir MVP) belirledikten sonra geri bildirim sağlamak isteyen bir dizi geliştirme ekibiyle bu platformun pilot uygulamasını yapın. 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
Ne kadar başarılı olduğunuzu ölçmek, ü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 değerden değer alıp almadığını belirlemek için ölçebileceğiniz iyi bilinen ölçümlere örnek verilmiştir. Sizin ve geliştirme ekibi müşterilerinizin hedeflerinize ulaşıp ulaşmadığını ölçmenize yardımcı olanlarla ilgili 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: İlk çekme isteğinin tamamlanması için ortanca gün sayısı (ekleme), derleme ve test işlemleri için ortanca dakika (ö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ına göre normalleştirilmiş sayı), ortalama 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: "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 ilgilenebileceğ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 |
| 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, özellikle de OKR'lerinizi destekleyenler olmak üzere tanımladığınız temel hedefler için kritik ölçümlere odaklanmak ö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şı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 deneyimi de sunar. Devam ettikçe öğrendiğiniz için projeleri yeniden oluşturmaktan ç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ünüzde size 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ştirmek yerine dikkatli analiz yapmak, beklentileri ayarlamak ve artımlı olarak devreye girmek 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 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 el ile iş akışı, fikirleri pilot yapmak 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 kullanıma sunduğu özellikler tarafından gölgelenebilen özel uygulama platformu özellikleri oluşturmaktan kaçının. Örneğin, çalışma zamanı barındırma, hizmet kafesleri, 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.