Intercom'un Veri Altyapısı ekibi artan talebi sağlam ilkelerle nasıl karşıladı?

Bir şirketi ölçeklendirmek asla doğrusal bir süreç değildir. Girişiminiz bir ölçek büyütüldükçe, ekipler yeni taleplere hızla uyum sağlamalarını gerektiren engellerle karşılaşacaktır.

2020'nin sonunda Veri Altyapısı ekibimizi burada bulduk - Intercom'daki ekiplere içgörü elde etmeleri ve önemli süreçleri yürütmeleri için veri ve araçlar sağlıyoruz ve her zamankinden daha fazla talep görüyorduk. Intercom, son birkaç yılda büyük bir büyüme yaşadı ve yolculuğumuzda bize yardımcı olması için çok sayıda inanılmaz yetenekli insanı işe aldık. Sonuç olarak, şirketimizin gidişatı hızla değişti - geçen yılın sonunda ekibimiz her zamankinden daha fazla talep görüyordu. Kullanmakta olduğumuz altyapıların, uygulamaların ve süreçlerin yeni ölçeğimizde verimli bir şekilde çalışmakta zorlandığını fark ettik.

Veri Altyapısı ekibi bir devrilme noktasına ulaştı

Ekip, günlerinin çoğunu sistemimizde ortaya çıkan küçük sorunlarla ilgilenerek, altta yatan sorunlara bakmak yerine sürekli reaktif olarak çalışarak ve proaktif olarak altyapıyı güçlendirerek geçirdi - sadece zamanımız yoktu. Yönetici olarak bu, takımın yönüne, stratejisine ve profesyonel gelişimine odaklanmak yerine sık sık araya girip günlük görevlere yardım etmem gerektiği anlamına geliyordu. Bir devrilme noktasına ulaşmıştık ve bir şeylerin değişmesi gerektiği açıktı.

“Ekibi hedeflerimize yönlendirmek ve işimize odaklanmak için bir takım ilkeler belirledik”

Grup Mühendisliği Müdürümüz Cormac McGuire ekibe katıldığında, bir adım geri çekildik ve tekrar rayına oturmak için yapılması gerekenlere baktık. Bilginin silolanması, sürekli bağlam değiştirme ve önemli sistem sağlığı sorunlarının önceliklerinin düşürülmesi gibi geçmişte blok ekiplerinin karşılaştığı birkaç sorunu fark ettik. Bu sorunları çözmek için ekibi hedeflerimize uyumlu hale getirmek ve işimize odaklanmak için bir dizi ilke belirledik.

Prensipler neden Intercom'da çalışma şeklimizin ayrılmaz bir parçasıdır?

Yıllar içinde, en yüksek performans gösteren, en mutlu ekiplerimizin, nasıl çalıştıkları konusunda dikkatli ve bilinçli olduklarında taleplerle daha iyi ilgilendiğini öğrendik. Bir ekibi ölçeklendirmenin ve onlar için doğru olanı yapma konusunda onlara güvenirken onları uyumlu tutmanın en iyi yolunun ilkelerin olduğunu düşünüyoruz. İlkelerimiz, neyin işe yarayıp neyin yaramadığına dair öğrendiklerimizle gelişir.

İşte çözmemiz gereken en acil sorunlar ve her birine uyguladığımız ilkeler.

Problem 1: Problem çözme yerine hıza öncelik vermek

Projeleri hızlı bir şekilde teslim ederek müşterilerimizi, diğer bir deyişle Intercom'daki meslektaşlarımızı memnun ettik, ancak çözülmesi gereken temel sorunu anlamak için kendimize yeterli zaman ayıramadık. Önceden yapılan bir varsayımın yanlış olduğu ortaya çıktığında veya bir senaryonun gözden kaçırıldığını fark ettiğimizde, genellikle tamamlanmış projeleri tekrar ziyaret etmek zorunda kaldık.

İlke 1: Daha azını, daha iyisini yapın

Daha az görev üzerinde çalışmak, daha az bağlam değiştirme anlamına gelir ve sorunu tamamen anlamak için daha derin bir odaklanma sağlar. Ekibin, ulaşmak için belirlediğimiz hedefleri karşılayana kadar çözüm üzerinde yinelemek için daha fazla alanı var.

"Daha az, daha iyi yap" ilkesini benimsemek, uzun vadede takıma fayda sağlamak için zorlu takaslar yapmak anlamına geliyordu. İlk olarak, diğer ekiplerin bize giriş yapmak yerine verilerinin ilerlemesini kontrol edebilmeleri için bir durum hizmeti kurduk. Bu, sorguları yanıtlamak için harcayacağımız zamanı boşa çıkardı, böylece onu sistemlerimizde çalışmak ve sonuçta veri dağıtımını hızlandırmak için kullanabilirdik.

“Çözülene kadar tek bir şeye odaklanmamız gerekiyordu ve onu tekrar ziyaret etmemiz gerekmeyeceğinden emindik. Ancak o zaman bir sonraki şeye geçebiliriz”

İkinci olarak, yalnızca günlük ELT'mizin (çıkarma, yükleme, dönüştürme) güvenilirliğine, her gece en son verilerin alındığı ve mevcut tüm verilerin yenilendiği sürece odaklanmayı seçtik. Çözülene kadar bir şeye odaklanmamız gerekiyordu ve onu tekrar gözden geçirmek zorunda olmayacağımızdan emindik. Ancak o zaman bir sonraki şeye geçebiliriz.

Problem 2: Bilgi siloları

Veri Altyapısı ekibimiz küçüktür, bu nedenle mühendisler genellikle projeler üzerinde bireysel olarak çalışırlar. Ekipteki diğer mühendislerin gerekli bağlam olmadan kodu gözden geçirmesi zordu ve mevcut hizmetlerle ilgili sorunlar ortaya çıkarsa, yalnızca sistem üzerinde çalışan mühendis sorunu hızlı bir şekilde çözme bilgisine sahipti.

“Paralel olarak akıllı işler yapan akıllı insanlar vardı”

O mühendis izindeyken, tüm işler dururdu. Takım arkadaşlarımız kısa sürede bir alandan sorumlu tek kişi olmaktan dolayı hüsrana uğradılar. Kısacası, paralel olarak akıllı şeyler yapan akıllı insanlar vardı - mühendislerimizi daha iyi destekleyen uyumlu süreçler yaratmamız gerekiyordu.

Prensip 2: Sorunları eşleştirin

Her çözüm üzerinde çalışan en az iki mühendis olurdu. İki yerine bir mühendis atamak, sonucun verimliliğini veya kalitesini mutlaka iki katına çıkarmaz, sadece başarısızlık noktaları riskini artırır. Süreçte birden fazla bakış açısı olduğunda projeler her zaman daha iyi sonuçlar verir.

Belirli bir alandaki soruları yanıtlayacak veya sorunları çözecek birinin her zaman olduğunu bilmek, bireysel mühendisler üzerindeki baskıyı azalttı, bu da onların izin almalarını veya yeni projelere geçmelerini kolaylaştırdı.

Sorun 3: Sistem sağlığına yetersiz öncelik verilmesi

Sistem sağlığı sorunları, herhangi bir hizmeti çalıştırmanın bir parçasıdır. Bununla birlikte, yeni sorunları öncelik sırasına koymak ve önceliklendirmek için etkili bir sistem olmadan, nöbetçi mühendis önce hangi sorunların ele alınacağına öznel olarak karar verecektir.

Bu sistem sağlığı sorunları ortaya çıktığında, analitik verilerimiz kesinlikle müşteriye yönelik olmadığından bunları birinci öncelik (P1) olarak işaretleme konusunda isteksizdik ve bu nedenle daha az kritik olduğunu düşündük. Ancak bu sorunların genel sistem sağlığını etkileme ve ekibimizin çalışmasını olumsuz etkileme potansiyeli vardı. Onlara yeterince öncelik vermediğimizi fark ettik ve zamanla daha büyük sorunlara neden olmak için birleştiler.

İlke 3: Sistem sağlığı her zaman P1'dir

Birincil SLA'larımızı (hizmet öğrenme anlaşmaları) etkileyen herhangi bir sistem sorunu birinci öncelik olacaktır (P1). Bir sorunu P1 olarak işaretleme yaklaşımımızı yeniden düşünmemiz gerekiyordu; P1'leri yalnızca acil, müşteriyi engelleyen acil durumlar olarak ve bunun yerine önemli bir sürecin başlatıcıları olarak düşünmekten vazgeçmek.

Bu ilkeyi uyguladığımızdan beri, sorunları çok daha etkili bir şekilde ele aldık. Sistem sağlığı sorunları P1 olarak işaretlenir ve çağrı üzerine çalışan mühendis yeni bir P1 sorununu bağımsız olarak çözmek için yeterli içeriğe sahip değilse, ekip proaktif çalışmayı durdurur ve sorun tamamen kökten kaynaklanana ve çözülene kadar çabalarını yeniden yönlendirir. Olay, Mühendislik ekibimiz Slack kanalına otomatik olarak kaydedilir; bu, kuruluş genelinde konuyla ilgili ekstra bağlam veya anlayışa sahip herkesin sorunu olabildiğince çabuk çözmek için giriş yapabileceği anlamına gelir.

Ekibinizin neler yapabileceği konusunda gerçekçi olun

Küçük ekiplerin çok fazla işi üstlenmesi, odaklarını çok ince dağıtması ve uzun vadede daha fazla iş yaratacak önemli ayrıntıları kaçırması kolaydır.

Daha azını, daha iyisini yapmak ve sistem sağlığını en büyük önceliğimiz yapmak, sürecimizin diğer temel unsurlarını geliştirmek için daha sağlam yapılar inşa etmemiz ve reaktif değil proaktif olarak çalışmamız anlamına geliyordu. Her projeye iki mühendis atamak, çalışma şeklimizi değiştirdi. Intercom'un değerlerinden biri “birlikte daha ileriye gidiyoruz”dur ve bu yaklaşımı benimsediğimizden beri bunun doğru olduğu defalarca kanıtlanmıştır.

Çalışma şeklimiz ve sorunlara yaklaşımımızla ilgileniyor musunuz? Sizinle konuşmayı çok isteriz – açık rollerimize göz atın.