Geliştirici üretkenliğini ölçmek: Google, Notion ve diğerlerinden gerçek örnekler

xguru · 2024-01-22T11:06:01+09:00

Google, LinkedIn, Peloton, Amplitude, Intercom, Notion, Postman ve diğerleri dahil 17 teknoloji şirketinin geliştirici üretkenliğini nasıl ölçtüğüne dair derinlemesine analiz 1. 17 teknoloji şirketinin geliştirici üretkenliği metrikleri Geliştirici üretkenliğini ölçmek karmaşık bir problemdir; çünkü bilgi temelli bir iş olan yazılım mühendisliğinde "üretken" olmanın ne anlama geldiği başlı başına belirsizdir Geliştirici üretkenliği (DevProd) veya geliştirici deneyimi (DevEx) ekipleri olarak adlandırılan ekipler, geliştiricilerin yüksek kaliteli yazılımı kolayca dağıtabilmesini destekler Bu ekipler, mühendislik ekiplerinin üretkenliğini ve engellerini ölçmek, ayrıca yaptıkları işin gerçekten etki yaratıp yaratmadığını izlemek için geliştirici üretkenliği metriklerine ihtiyaç duyar Bu şirketlerde kullanılan geliştirici üretkenliği metrikleri Teslimat kolaylığı (Amplitude, GoodRx, Intercom, Postman, Lattice) Deney hızı (Etsy) Servis/uygulama kararlılığı (DoorDash) SPACE metrikleri (Microsoft) Mühendis başına haftalık odaklanma süresi (Uber) Şirket büyüklüğüne göre 4 örnek seçildi Google: 100.000'den fazla çalışan LinkedIn: 10.000'den fazla Peloton: 1.000'den fazla, 10.000'den az Scale-up'lar (100 ile 1.000 arasında mühendis): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice 2. Google'ın yaklaşımı Google, geliştirici üretkenliğini ölçmede sıkça en iyi uygulama örneği olarak anılsa da, Google düzeyindeki yatırımı taklit etmenin çoğu şirket için imkansız olduğu da söylenir Google'ın Developer Intelligence ekibi, geliştirici üretkenliğini ölçen ve liderlere içgörü sağlayan uzman bir birimdir Google, tek bir metriğin üretkenliği yakalayamayacağına inanır ve üretkenliğe hız, kolaylık ve kalite olmak üzere üç boyut üzerinden bakar Speed hız: Kod incelemesinin tamamlanması ne kadar sürüyor? Ease kolaylık: Geliştiricinin kod inceleme sürecinden geçmesi ne kadar kolay veya zor? Quality kalite: Kod incelemesi sırasında alınan geri bildirimin kalitesi ne düzeyde? Google, metrikleri hesaplamak için nitel ve nicel ölçümleri bir arada kullanır 3. LinkedIn LinkedIn, Microsoft bünyesinde bağımsız şekilde faaliyet gösterir ve 10.000'den fazla çalışan istihdam eder LinkedIn'de, geliştirici üretkenliğini ve memnuniyetini ölçen ve organizasyonun geri kalanına içgörü aktaran bir Developer Insights ekibi vardır LinkedIn, metrikleri yakalamak için üç aylık anketler, gerçek zamanlı geri bildirim sistemi ve sistem tabanlı metrikler kullanır Üç aylık anketler: Developer Insights ekibi, üç aylık anketlerle çeşitli araçlar, süreçler ve faaliyetler genelinde geliştirici deneyimini değerlendirir Anket yaklaşık 30 sorudan oluşur ve geliştiriciler yaklaşık 10 dakika içinde yanıtlayabilir Anket, Developer Insights ekibinin geliştirdiği ve yönettiği özel bir platform üzerinden sunulur; ayrıca gerçek zamanlı geri bildirim ve metrik sisteminden toplanan verilere dayanarak anket soruları ileri düzeyde özelleştirilebilir ve kişiselleştirilebilir Gerçek zamanlı geri bildirim sistemi: LinkedIn, üç aylık anketler arasında geri bildirim toplamak için geliştiricilerin geliştirme araçları içindeki olay ve işlemlerini izleyen ve belirli tetikleyicilere göre hedefli anketler gönderen bir gerçek zamanlı geri bildirim sistemi geliştirdi Bu sistem, geliştiricilere aşırı sayıda geri bildirim isteği gitmesini önlemek için akıllı bir throttling mekanizması kullanır Sistem tabanlı metrikler: LinkedIn ayrıca sistem verilerini kullanarak metrikler hesaplar ve build süresi ile deployment sıklığı gibi konularda yüksek hassasiyetli ölçümler sunar Developer Insights ekibi, bu verileri toplamak ve analiz etmek için küresel bir sistemi sürdürür; buna geliştirici içgörü merkezi ya da iHub der Bu sistem sayesinde LinkedIn'deki tüm ekipler, kendi ihtiyaçlarına uygun özel dashboard'lar ve metrikler oluşturabilir LinkedIn hem nitel hem nicel metrikleri dikkate alır Developer Net User Satisfaction (NSAT): Geliştiricilerin LinkedIn'in geliştirme sistemlerinden genel olarak ne kadar memnun olduğunu ölçer. Üç aylık olarak ölçülür Developer Build Time (P50 ve P90): Geliştiricinin geliştirme sırasında build'in yerelde tamamlanmasını beklemek için harcadığı süreyi saniye cinsinden ölçer Code Reviewer Response Time (P50 ve P90): Kod inceleyenin, yazarın her kod inceleme güncellemesine yanıt vermesinin ne kadar sürdüğünü ölçer (çalışma saatleri bazında) Post-Commit CI Speed (P50 ve P90): Her commit'in continuous integration (CI) hattından geçmesinin kaç dakika sürdüğünü ölçer CI Determinism: Test flaky'liğinin tersi bir kavramdır. Test paketinden çıkan sonucun hata yerine geçerli bir sonuç olma olasılığını ifade eder Deployment Success Rate: Production ortamına yapılan deployment'ların ne sıklıkla başarılı olduğunu ölçer Winsorized Means: Aykırı değer içeren metriklerde iyileşmeyi tanıma yöntemi. En yüksek ve en düşük değerleri ortaya daha yakın sayılarla değiştirerek hesaplanır Developer Experience Index: LinkedIn'in ekiplere sunduğu özel bir metriktir. Bu endeks, yukarıda listelenenler gibi çeşitli metriklere dayanan bileşik bir puandır 4. Peloton Peloton, yaklaşık 3.000-4.000 çalışanı olan büyük bir şirkettir, ancak LinkedIn'den çok daha küçüktür Peloton'un ölçüm yaklaşımı, önce geliştirici deneyimi anketleriyle nitel içgörüler elde etmekle başladı; daha sonra bunlar nicel metriklerle birlikte kullanılmaya başlandı Peloton, üretkenliği ölçerken katılım, hız, kalite ve kararlılık olmak üzere dört ana alana odaklanır Katılım (Engagement): geliştirici memnuniyet puanı Hız (Velocity): tüm yeni çalışanlar için ilk ve 10. PR'ye kadar geçen süre, lead time, deployment sıklığı Kalite (Quality): 250 satırdan küçük PR oranı, line coverage, değişiklik başarısızlık oranı Kararlılık (Stability): servis kurtarma süresi Bu metriklerin önemli bir kısmını ölçen geliştirici deneyimi anketleri, ürün operasyonları organizasyonunun parçası olan Peloton'un teknik destek ve geliştirici deneyimi ekibi tarafından yürütülür Teknik destek ve geliştirici deneyimi ekibi ayrıca anket sonuçlarını analiz etmekten ve bunları organizasyon genelindeki liderlerle paylaşmaktan sorumludur 5. Scale-up'lar ve küçük şirketler Notion, Postman, Amplitude, GoodRx, Intercom ve Lattice gibi çeşitli scale-up şirketleri 100 ile 1.000 arasında mühendis istihdam eder Bu şirketler "hareket ettirilebilir metriklere (Moveable Metrics)" odaklanır Hareket ettirilebilir metrikler, geliştirici üretkenliği ekiplerinin işleri üzerinde olumlu ya da olumsuz etki yaratarak "oynatabildiği" metriklerdir. Geliştirici üretkenliği ekiplerinin kendi etkisini göstermesi açısından faydalıdır Yaygın metrikler Teslimat kolaylığı (Ease of Delivery, moveable): Çoğu şirket, geliştiricilerin işlerini yapmanın ne kadar kolay veya zor hissettirdiğini gösteren nitel bir ölçü olan teslimat kolaylığını ölçer Birçok DevProd lideri, ekiplerinin amacının geliştiricilerin hayatını kolaylaştırmak olduğunu ve bu nedenle bu metriği çalışmalarının 'kuzey yıldızı' olarak gördüklerini söyler Bu metrik oldukça oynatılabilir olduğu için etkiyi göstermede de faydalıdır Teorik açıdan bu metrik, bilişsel yük ve geri bildirim döngüleri gibi geliştirici deneyiminin temel yönlerini de yakalar Katılım (Engagement) Geliştiricilerin işlerine ne kadar ilgi duyduğunu ve ne kadar motive olduğunu ölçen katılım da izlenir Katılım genellikle HR katılım anketlerinde ölçülür, ancak DevProd ekipleri de bu nedenle katılıma odaklandıklarını belirtir Geliştirici katılımı ile üretkenlik yakın ilişkilidir; yani "mutlu geliştirici üretken geliştiricidir" sözünde olduğu gibi, geliştirici katılımı üretkenliğin bir göstergesi olarak görülebilir Katılımı ölçmenin asıl faydası, hızı vurgulayan diğer metriklerle denge kurabilmesidir. Yazılımı daha hızlı teslim etmek iyi olsa da, bunun bedeli geliştirici mutluluğunun azalması olmamalıdır Zaman kaybı (Time Loss, moveable) GoodRx ve Postman, ortalama zaman kaybı miktarına dikkat eder Bu, çalışma ortamındaki engeller nedeniyle kaybedilen geliştirici zamanının oranı olarak ölçülür Bu metrik, geliştirme ekibinin işinin doğrudan etki edebileceği hareket ettirilebilir bir ölçü sunması bakımından teslimat kolaylığına benzer Maliyete dönüştürülebilmesi büyük bir avantajdır; bu sayede iş liderleri zaman kaybını kolayca anlayabilir Örneğin mühendislik personel maliyeti 10 milyon dolar olan bir organizasyonda, bir inisiyatif sayesinde zaman kaybı %20'den %10'a düşerse bu 1 milyon dolarlık maliyet tasarrufuna karşılık gelir Değişiklik başarısızlık oranı (Change Failure Rate) Bu, DORA (DevOps Research and Assessment) araştırma programının dört temel metriğinden biridir Amplitude ve Lattice dahil birçok şirket tarafından takip edilen üst düzey bir metriktir DORA ekibi değişiklik başarısızlık oranını şöyle tanımlar: "Production veya kullanıcıya yapılan bir release değişikliğinin hizmette bozulmaya (ör. servis arızası veya kesinti) yol açması ve ardından düzeltme gerektirmesi (ör. hotfix, rollback, fix forward veya patch gerekliliği) durumlarının oranı" 6. İlginç bulgular DORA ve SPACE metrikleri isteğe bağlı olarak kullanılıyor ve tüm şirketler hem nitel hem nicel ölçümleri birlikte kullanıyor DORA: DevOps Research and Assessment SPACE: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow "Odaklanma süresi" üzerine güçlü bir vurgu var; Stripe ve Uber, "yeterli odaklanma süresine sahip olunan gün sayısı" ve "mühendis başına haftalık odaklanma süresi" gibi somut metrikler paylaşıyor Özgün metrikler Adoption Rate (DoorDash, GoodRx, Spotify) Design Docs Generated per Engineer (Uber) Experiment Velocity (Etsy) Developer CSAT/NSAT (Chime, LinkedIn) 7. Kendi metriklerinizi nasıl seçersiniz Metrik seçimine rehberlik etmek için Google'ın Goals, Signals, Metrics (GSM) framework'ünü kullanmak faydalıdır Önce çözmek istediğiniz hedefi tanımlayın, sonra bu hedefe ulaşıldığını gösterecek sinyalleri bulun ve ardından uygun metrikleri seçin Hedef tanımlama Google: "Geliştiricilerin hızlı ve kolay şekilde harika ürünler sunmasını destekliyoruz." Slack: "Her mühendise sorunsuz bir geliştirme ortamı sunuyoruz." Stripe: "Yazılım mühendisliğini daha kolay hale getiriyoruz." Hedeften geriye doğru çalışarak üst düzey metrikleri tanımlamak Geliştiriciler için yazılım teslim etmek ne kadar kolay? (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate Geliştiriciler yazılımı ne kadar hızlı teslim ediyor? (Speed): Perceived Delivery Speed, Perceived Productivity Sunulan yazılımın kalitesi (Quality): Incident frequency, Perceived Software Quality Eğer CTO, VPE veya mühendislik lideriyseniz En iyi tavsiye "problemi yeniden çerçevelemek (reframe the problem)" olacaktır Üç kovadan metrik seçin İş etkisi Bunu neden şimdi inşa etmeliyiz? Bu proje iş açısından nasıl gelir yaratıyor veya hedefleri destekliyor? Bu proje yolunda mı gidiyor, yoksa gecikiyor mu? Sistem performansı Mühendislik sistemleri hızlı ve kararlı mı? Altyapı güvenli ve iyi bakılıyor mu? Kullanıcılar kullandıkları hizmetlerden memnun mu? Mühendislik verimliliği Nitel ve nicel metrikleri birlikte ölçmek, tüm şirketlerde ortak görülen bir durumdur Her şirketin kullandığı farklı ölçümlerden ilham alın Her şirketin önceliklerine ve mühendislik kültürüne göre özellikle odaklandığı ölçümlerde büyük farklılıklar vardır

(newsletter.pragmaticengineer.com)

53 puan yazan xguru 2024-01-22 | 1 yorum | WhatsApp'ta paylaş

Google, LinkedIn, Peloton, Amplitude, Intercom, Notion, Postman ve diğerleri dahil 17 teknoloji şirketinin geliştirici üretkenliğini nasıl ölçtüğüne dair derinlemesine analiz

1. 17 teknoloji şirketinin geliştirici üretkenliği metrikleri

Geliştirici üretkenliğini ölçmek karmaşık bir problemdir; çünkü bilgi temelli bir iş olan yazılım mühendisliğinde "üretken" olmanın ne anlama geldiği başlı başına belirsizdir
Geliştirici üretkenliği (DevProd) veya geliştirici deneyimi (DevEx) ekipleri olarak adlandırılan ekipler, geliştiricilerin yüksek kaliteli yazılımı kolayca dağıtabilmesini destekler
Bu ekipler, mühendislik ekiplerinin üretkenliğini ve engellerini ölçmek, ayrıca yaptıkları işin gerçekten etki yaratıp yaratmadığını izlemek için geliştirici üretkenliği metriklerine ihtiyaç duyar
Bu şirketlerde kullanılan geliştirici üretkenliği metrikleri
- Teslimat kolaylığı (Amplitude, GoodRx, Intercom, Postman, Lattice)
- Deney hızı (Etsy)
- Servis/uygulama kararlılığı (DoorDash)
- SPACE metrikleri (Microsoft)
- Mühendis başına haftalık odaklanma süresi (Uber)
Şirket büyüklüğüne göre 4 örnek seçildi
- Google: 100.000'den fazla çalışan
- LinkedIn: 10.000'den fazla
- Peloton: 1.000'den fazla, 10.000'den az
- Scale-up'lar (100 ile 1.000 arasında mühendis): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice

2. Google'ın yaklaşımı

Google, geliştirici üretkenliğini ölçmede sıkça en iyi uygulama örneği olarak anılsa da, Google düzeyindeki yatırımı taklit etmenin çoğu şirket için imkansız olduğu da söylenir
Google'ın Developer Intelligence ekibi, geliştirici üretkenliğini ölçen ve liderlere içgörü sağlayan uzman bir birimdir
Google, tek bir metriğin üretkenliği yakalayamayacağına inanır ve üretkenliğe hız, kolaylık ve kalite olmak üzere üç boyut üzerinden bakar
- Speed hız: Kod incelemesinin tamamlanması ne kadar sürüyor?
- Ease kolaylık: Geliştiricinin kod inceleme sürecinden geçmesi ne kadar kolay veya zor?
- Quality kalite: Kod incelemesi sırasında alınan geri bildirimin kalitesi ne düzeyde?
Google, metrikleri hesaplamak için nitel ve nicel ölçümleri bir arada kullanır

3. LinkedIn

LinkedIn, Microsoft bünyesinde bağımsız şekilde faaliyet gösterir ve 10.000'den fazla çalışan istihdam eder
LinkedIn'de, geliştirici üretkenliğini ve memnuniyetini ölçen ve organizasyonun geri kalanına içgörü aktaran bir Developer Insights ekibi vardır
LinkedIn, metrikleri yakalamak için üç aylık anketler, gerçek zamanlı geri bildirim sistemi ve sistem tabanlı metrikler kullanır
- Üç aylık anketler:
  - Developer Insights ekibi, üç aylık anketlerle çeşitli araçlar, süreçler ve faaliyetler genelinde geliştirici deneyimini değerlendirir
  - Anket yaklaşık 30 sorudan oluşur ve geliştiriciler yaklaşık 10 dakika içinde yanıtlayabilir
  - Anket, Developer Insights ekibinin geliştirdiği ve yönettiği özel bir platform üzerinden sunulur; ayrıca gerçek zamanlı geri bildirim ve metrik sisteminden toplanan verilere dayanarak anket soruları ileri düzeyde özelleştirilebilir ve kişiselleştirilebilir
- Gerçek zamanlı geri bildirim sistemi:
  - LinkedIn, üç aylık anketler arasında geri bildirim toplamak için geliştiricilerin geliştirme araçları içindeki olay ve işlemlerini izleyen ve belirli tetikleyicilere göre hedefli anketler gönderen bir gerçek zamanlı geri bildirim sistemi geliştirdi
  - Bu sistem, geliştiricilere aşırı sayıda geri bildirim isteği gitmesini önlemek için akıllı bir throttling mekanizması kullanır
- Sistem tabanlı metrikler:
  - LinkedIn ayrıca sistem verilerini kullanarak metrikler hesaplar ve build süresi ile deployment sıklığı gibi konularda yüksek hassasiyetli ölçümler sunar
  - Developer Insights ekibi, bu verileri toplamak ve analiz etmek için küresel bir sistemi sürdürür; buna geliştirici içgörü merkezi ya da iHub der
  - Bu sistem sayesinde LinkedIn'deki tüm ekipler, kendi ihtiyaçlarına uygun özel dashboard'lar ve metrikler oluşturabilir
LinkedIn hem nitel hem nicel metrikleri dikkate alır
- Developer Net User Satisfaction (NSAT): Geliştiricilerin LinkedIn'in geliştirme sistemlerinden genel olarak ne kadar memnun olduğunu ölçer. Üç aylık olarak ölçülür
- Developer Build Time (P50 ve P90): Geliştiricinin geliştirme sırasında build'in yerelde tamamlanmasını beklemek için harcadığı süreyi saniye cinsinden ölçer
- Code Reviewer Response Time (P50 ve P90): Kod inceleyenin, yazarın her kod inceleme güncellemesine yanıt vermesinin ne kadar sürdüğünü ölçer (çalışma saatleri bazında)
- Post-Commit CI Speed (P50 ve P90): Her commit'in continuous integration (CI) hattından geçmesinin kaç dakika sürdüğünü ölçer
- CI Determinism: Test flaky'liğinin tersi bir kavramdır. Test paketinden çıkan sonucun hata yerine geçerli bir sonuç olma olasılığını ifade eder
- Deployment Success Rate: Production ortamına yapılan deployment'ların ne sıklıkla başarılı olduğunu ölçer
- Winsorized Means: Aykırı değer içeren metriklerde iyileşmeyi tanıma yöntemi. En yüksek ve en düşük değerleri ortaya daha yakın sayılarla değiştirerek hesaplanır
- Developer Experience Index: LinkedIn'in ekiplere sunduğu özel bir metriktir. Bu endeks, yukarıda listelenenler gibi çeşitli metriklere dayanan bileşik bir puandır

4. Peloton

Peloton, yaklaşık 3.000-4.000 çalışanı olan büyük bir şirkettir, ancak LinkedIn'den çok daha küçüktür
Peloton'un ölçüm yaklaşımı, önce geliştirici deneyimi anketleriyle nitel içgörüler elde etmekle başladı; daha sonra bunlar nicel metriklerle birlikte kullanılmaya başlandı
Peloton, üretkenliği ölçerken katılım, hız, kalite ve kararlılık olmak üzere dört ana alana odaklanır
- Katılım (Engagement): geliştirici memnuniyet puanı
- Hız (Velocity): tüm yeni çalışanlar için ilk ve 10. PR'ye kadar geçen süre, lead time, deployment sıklığı
- Kalite (Quality): 250 satırdan küçük PR oranı, line coverage, değişiklik başarısızlık oranı
- Kararlılık (Stability): servis kurtarma süresi
Bu metriklerin önemli bir kısmını ölçen geliştirici deneyimi anketleri, ürün operasyonları organizasyonunun parçası olan Peloton'un teknik destek ve geliştirici deneyimi ekibi tarafından yürütülür
Teknik destek ve geliştirici deneyimi ekibi ayrıca anket sonuçlarını analiz etmekten ve bunları organizasyon genelindeki liderlerle paylaşmaktan sorumludur

5. Scale-up'lar ve küçük şirketler

Notion, Postman, Amplitude, GoodRx, Intercom ve Lattice gibi çeşitli scale-up şirketleri 100 ile 1.000 arasında mühendis istihdam eder
Bu şirketler "hareket ettirilebilir metriklere (Moveable Metrics)" odaklanır
- Hareket ettirilebilir metrikler, geliştirici üretkenliği ekiplerinin işleri üzerinde olumlu ya da olumsuz etki yaratarak "oynatabildiği" metriklerdir. Geliştirici üretkenliği ekiplerinin kendi etkisini göstermesi açısından faydalıdır
Yaygın metrikler
- Teslimat kolaylığı (Ease of Delivery, moveable):
  - Çoğu şirket, geliştiricilerin işlerini yapmanın ne kadar kolay veya zor hissettirdiğini gösteren nitel bir ölçü olan teslimat kolaylığını ölçer
  - Birçok DevProd lideri, ekiplerinin amacının geliştiricilerin hayatını kolaylaştırmak olduğunu ve bu nedenle bu metriği çalışmalarının 'kuzey yıldızı' olarak gördüklerini söyler
  - Bu metrik oldukça oynatılabilir olduğu için etkiyi göstermede de faydalıdır
  - Teorik açıdan bu metrik, bilişsel yük ve geri bildirim döngüleri gibi geliştirici deneyiminin temel yönlerini de yakalar
- Katılım (Engagement)
  - Geliştiricilerin işlerine ne kadar ilgi duyduğunu ve ne kadar motive olduğunu ölçen katılım da izlenir
  - Katılım genellikle HR katılım anketlerinde ölçülür, ancak DevProd ekipleri de bu nedenle katılıma odaklandıklarını belirtir
  - Geliştirici katılımı ile üretkenlik yakın ilişkilidir; yani "mutlu geliştirici üretken geliştiricidir" sözünde olduğu gibi, geliştirici katılımı üretkenliğin bir göstergesi olarak görülebilir
  - Katılımı ölçmenin asıl faydası, hızı vurgulayan diğer metriklerle denge kurabilmesidir. Yazılımı daha hızlı teslim etmek iyi olsa da, bunun bedeli geliştirici mutluluğunun azalması olmamalıdır
- Zaman kaybı (Time Loss, moveable)
  - GoodRx ve Postman, ortalama zaman kaybı miktarına dikkat eder
  - Bu, çalışma ortamındaki engeller nedeniyle kaybedilen geliştirici zamanının oranı olarak ölçülür
  - Bu metrik, geliştirme ekibinin işinin doğrudan etki edebileceği hareket ettirilebilir bir ölçü sunması bakımından teslimat kolaylığına benzer
  - Maliyete dönüştürülebilmesi büyük bir avantajdır; bu sayede iş liderleri zaman kaybını kolayca anlayabilir
  - Örneğin mühendislik personel maliyeti 10 milyon dolar olan bir organizasyonda, bir inisiyatif sayesinde zaman kaybı %20'den %10'a düşerse bu 1 milyon dolarlık maliyet tasarrufuna karşılık gelir
- Değişiklik başarısızlık oranı (Change Failure Rate)
  - Bu, DORA (DevOps Research and Assessment) araştırma programının dört temel metriğinden biridir
  - Amplitude ve Lattice dahil birçok şirket tarafından takip edilen üst düzey bir metriktir
  - DORA ekibi değişiklik başarısızlık oranını şöyle tanımlar:
  "Production veya kullanıcıya yapılan bir release değişikliğinin hizmette bozulmaya (ör. servis arızası veya kesinti) yol açması ve ardından düzeltme gerektirmesi (ör. hotfix, rollback, fix forward veya patch gerekliliği) durumlarının oranı"

6. İlginç bulgular

DORA ve SPACE metrikleri isteğe bağlı olarak kullanılıyor ve tüm şirketler hem nitel hem nicel ölçümleri birlikte kullanıyor
- DORA: DevOps Research and Assessment
- SPACE: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
"Odaklanma süresi" üzerine güçlü bir vurgu var; Stripe ve Uber, "yeterli odaklanma süresine sahip olunan gün sayısı" ve "mühendis başına haftalık odaklanma süresi" gibi somut metrikler paylaşıyor
Özgün metrikler
- Adoption Rate (DoorDash, GoodRx, Spotify)
- Design Docs Generated per Engineer (Uber)
- Experiment Velocity (Etsy)
- Developer CSAT/NSAT (Chime, LinkedIn)

7. Kendi metriklerinizi nasıl seçersiniz

Metrik seçimine rehberlik etmek için Google'ın Goals, Signals, Metrics (GSM) framework'ünü kullanmak faydalıdır
Önce çözmek istediğiniz hedefi tanımlayın, sonra bu hedefe ulaşıldığını gösterecek sinyalleri bulun ve ardından uygun metrikleri seçin
- Hedef tanımlama
  - Google: "Geliştiricilerin hızlı ve kolay şekilde harika ürünler sunmasını destekliyoruz."
  - Slack: "Her mühendise sorunsuz bir geliştirme ortamı sunuyoruz."
  - Stripe: "Yazılım mühendisliğini daha kolay hale getiriyoruz."
- Hedeften geriye doğru çalışarak üst düzey metrikleri tanımlamak
  - Geliştiriciler için yazılım teslim etmek ne kadar kolay? (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate
  - Geliştiriciler yazılımı ne kadar hızlı teslim ediyor? (Speed): Perceived Delivery Speed, Perceived Productivity
  - Sunulan yazılımın kalitesi (Quality): Incident frequency, Perceived Software Quality
Eğer CTO, VPE veya mühendislik lideriyseniz
- En iyi tavsiye "problemi yeniden çerçevelemek (reframe the problem)" olacaktır
- Üç kovadan metrik seçin
  - İş etkisi
    - Bunu neden şimdi inşa etmeliyiz?
    - Bu proje iş açısından nasıl gelir yaratıyor veya hedefleri destekliyor?
    - Bu proje yolunda mı gidiyor, yoksa gecikiyor mu?
  - Sistem performansı
    - Mühendislik sistemleri hızlı ve kararlı mı?
    - Altyapı güvenli ve iyi bakılıyor mu?
    - Kullanıcılar kullandıkları hizmetlerden memnun mu?
  - Mühendislik verimliliği
Nitel ve nicel metrikleri birlikte ölçmek, tüm şirketlerde ortak görülen bir durumdur
- Her şirketin kullandığı farklı ölçümlerden ilham alın
- Her şirketin önceliklerine ve mühendislik kültürüne göre özellikle odaklandığı ölçümlerde büyük farklılıklar vardır

1 yorum

demorier 2024-01-24

Önceki McKinsey ile ilgili yazıdan beri ilgimi çekiyordu; özetlenip hatırlatılması güzel olmuş.