Teknoloji Yol Haritası Örneği: Bir Platform Ekibi için Now, Next, Later Planı

Teknoloji yol haritaları genellikle iki şekilde başarısız olur. Bazıları, kimsenin inanmadığı tarihlerle dolu ve her çeyrek yeniden çizilen Gantt şemalarıdır. Diğerleri, başına bir başlık eklenmiş bir iş listesi dökümüdür. İkisi de size bağımlı ekiplere şu anda neler olduğunu, sırada ne olduğunu ve henüz neye karar vermediğinizi söylemez.

Platform ekiplerinin işi çoğundan zordur. Son tarihlerini çoğu zaman başkaları belirler; örneğin bir Kubernetes ya da PostgreSQL sürümünün desteğinin sona ermesi. Müşterileri, her birinin bir talebi olan diğer mühendislik ekipleridir. İşleri de aylarca neredeyse bitmiş halde kalan uzun geçişlerle doludur.

Bu yazı, bir platform ekibi için Now, Next, Later (şimdi, sıradaki, daha sonra) biçiminde bir teknoloji yol haritası oluşturuyor; biçimin nereden geldiğini ve neden teknoloji işine uyduğunu açıklıyor ve yol haritasının dürüst kalması için nasıl yürütüleceğini anlatıyor.

Neden Now, Next, Later

Biçim ProdPad'den geliyor. Kurucu ortak Janna Bastow, The Birth of the Modern Roadmap yazısında, 2012'nin sonlarına doğru diğer kurucu ortağı Simon Cast'in bir peçeteye üç sütun çizdiğini anlatır: Current, Near term ve Future. Sütunlar zaman ufuklarıydı ve arkalarındaki fikir kesinlikti: ilk sütundaki iş net ve yakındır, son sütundaki işin kapsamı ise bulanıktır. Bunu ProdPad'e Now-Next-Later yol haritası olarak eklediler.

Sütunlar takvim çeyreklerini değil kesinliği gösterir. Bir madde, bir çeyrek bittiğinde değil, ona taahhüt verecek kadar bilgi edindiğinizde sola kayar.

Bir teknoloji yol haritasını farklı kılan nedir

Dış son tarihler. Çalıştırdığınız yazılımın bir destek penceresi vardır ve bu pencere işlerinizin sırasını belirler. Kubernetes projesi en son üç minor sürümü destekler ve her biri yaklaşık bir yıl yama desteği alır. Bu yüzden yükseltmeler tek seferlik bir proje değil, yol haritasında tekrar eden bir maddedir; kubeadm kümelerinde minor sürüm atlamak da desteklenmez, yani 1.35'ten 1.37'ye geçmek iki yükseltme demektir. PostgreSQL her major sürümü beş yıl destekler; ardından son bir minor sürüm yayımlanır ve sürümün ömrü sona erer.

İç müşteriler. Akış odaklı ekipler planlarını platformun teslim edeceklerine göre yapar. Neyin taahhüt edildiğini ve neyin edilmediğini bilmeleri gerekir; sütunlar da tam olarak bunu söyler.

Uzun kuyruklar. Yüzde 90'ı bitmiş bir geçişte hâlâ eski sürümde kalan bir veritabanı ya da servis vardır. İlerlemeyi bir tarih olarak değil, taşınması gereken kalan iş olarak gösterin.

Bağımlılıklar. Platform işi çoğu zaman başka platform işlerinin üzerine kurulur. Tracing içeren bir servis şablonu, tracing çalışmadan yayımlanamaz.

Proje değil, çıktı yazın

Her maddeyi istediğiniz sonuç olarak yazın; böylece herkes ne zaman bittiğini anlayabilir:

Ölçütü maddenin açıklamasına ekleyin: trace gönderen servisler, desteklenen sürümdeki kümeler, hâlâ 15 sürümünde olan veritabanları.

Örnek: bir platform ekibinin yol haritası

Örnek Ekim 2026 tarihli; bu yüzden son tarihler Kubernetes ve PostgreSQL sürüm sayfalarındaki gerçek tarihler.

• Now. OpenTelemetry geçişi olan Traces everywhere yaklaşık üçte bir oranında tamamlandı ve ekibin bir mühendise daha ihtiyacı olduğu için risk altında. Kubernetes 1.37 sürüyor: Kubernetes 1.35'in ömrü 28 Şubat 2027'de sona eriyor; bu tarih Next penceresine düştüğü için yükseltmenin şimdi yapılması gerekiyor.
• Next. CI/CD, tracing ve panoları hazır gelen bir servis şablonu olan Golden path, tracing'i bekliyor. Off PostgreSQL 15, 15 sürümünün 11 Kasım 2027'deki ömür sonundan önce pg_upgrade ile 18 sürümüne yapılacak bir major yükseltme.
• Later. Keşfedilecek iki sorun: bulut maliyetini ekip bazında görünür kılmak ve ödeme akışının bir bölge kesintisinde ayakta kalmasını sağlamak. İkisinin de henüz bir sahibi ya da çözümü yok.

Nasıl okunur:

• Sütunlar çeyrek değil, kesinlik gösterir. Soldan sağa iş, taahhüt edilmişten muhtemele ve henüz karar verilmemişe doğru ilerler.
• Her kart bir çıktıdır; bir sahibi, durumu ve ilerleme çubuğu vardır. Later maddelerinin henüz sahibi yok; bunlar plan değil, sorun.
• Bağımlılık rozeti tracing'in Golden path'i engellediğini gösterir, çünkü şablon tracing açık olarak gelir.
• Kilometre taşları dış son tarihlerdir ve düştükleri sütuna yerleştirilir. Kubernetes 1.35 desteği Next sırasında bittiği için yükseltmesi Now'da. PostgreSQL 15 desteği Later'da bittiği için yükseltmesi Next'te başlıyor ve uzun kuyruğa zaman bırakıyor.
• Durum rozeti riski açıklar: tracing için ek kişi gerekiyor.

Nasıl yürütülür

• Sabit bir ritimle, örneğin iki haftada bir, hizmet verdiğiniz ekiplerin liderleriyle gözden geçirin. Maddeleri yalnızca bu incelemede taşıyın; böylece yol haritası insanların ayağının altında değişmez.
• Now'u küçük tutun. İçine yalnızca ekibin üzerinde çalışacak kadrosu olan işleri koyun. Now'a yeni bir şey girerse başka bir şey çıkar.
• Later'dan Next'e yalnızca şekillendiğinde taşıyın: bir sorun tanımı, bir bitti ölçütü, bir sahip ve kaba bir büyüklük.
• Tarihleri yalnızca dış son tarihler için kullanın. İç tahminler, yol haritasında söz olarak değil, maddenin açıklamasında aralık olarak yer alır.
• Biten maddeleri bir kez gösterin, bir sonraki incelemede, sonra arşivleyin. Yol haritası önünüzdeki işle ilgilidir.
• Maddeleri ayrıntılara bağlayın: tasarım belgesi, geçiş takibi, mimari diyagram. CI/CD hattı diyagramı ve Kubernetes mimari diyagramı yazıları bu görsellerin nasıl görünebileceğini gösteriyor.

Sık yapılan hatalar

• Tarihli bir özellik listesi. Belirsizliği bir tarih kayana kadar gizler ve sonra herkes bunu aynı anda öğrenir.
• Her şey Now'da. On madde birden sürüyorsa hiçbiri sürmüyordur.
• Sahipsiz maddeler. Now ya da Next'te sahibi olmayan bir madde bir dilektir.
• Gizli bağımlılıklar. Bir madde diğerine ihtiyaç duyuyorsa bunu çizin. Yoksa ikinci madde başlar ve takılır.
• Yalnızca acil olduğunda görünen yükseltmeler. Bağımlı olduğunuz her destek penceresini, o sürümü benimsediğiniz gün yol haritasına kilometre taşı olarak ekleyin.
• Kimsenin bakmadığı bir yol haritası. Onu insanların zaten çalıştığı yerde tutun ve eskiyen bir ekran görüntüsü yapıştırmak yerine belgelerinize gömün.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun ya da Now / Next / Later yol haritası şablonundan başlayın.
2. Yol Haritası paketinden üç Çeyrek çerçevesi ekleyin ve bunlara Now, Next ve Later adlarını verin.
3. Her çıktı için bir Epik ekleyin; başlığını, sahibini, durumunu ve ilerlemesini ayarlayın.
4. Her dış son tarih için, tarihiyle birlikte, düştüğü sütuna bir Kilometre taşı ekleyin.
5. Birinin diğerini engellediği iki epik arasına bir Bağımlılık rozeti ekleyin ve onları kesikli kenarlarla bağlayın.
6. Bir risk için bir Durum rozeti, her sütunun kuralları için de Temel paketinden bir Not ekleyin.

Örnek 13 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Teknoloji yol haritası ile ürün yol haritası arasındaki fark nedir? Ürün yol haritası müşterilerin ne alacağıyla ilgilidir. Teknoloji yol haritası ise bunu mümkün kılan yetenekler, yükseltmeler ve geçişlerle ilgilidir ve müşterileri genellikle diğer mühendislik ekipleridir. Biçim aynı olabilir.

Bir teknoloji yol haritasında tarih olmalı mı? Yalnızca tarihin gerçek olduğu yerlerde: bir destek sonu, bir sözleşme ya da bir düzenleme. Geri kalan her şey kesinlik sütunlarına girer.

Later ne kadar ileriye uzanmalı? Sabit bir ufuk yok. Later sorunları tutar; bu yüzden onu her maddenin bir sonraki incelemede hâlâ konuşulmaya değer olacağı kadar kısa tutun.

Uzun bir geçişte ilerlemeyi nasıl gösteririm? Kümeler, servisler ya da veritabanları gibi taşınması gereken kalan şeyleri sayın ve sayıyı her incelemede güncelleyin. Sayısı olmayan bir yüzde uzun kuyruğu gizler.

Platform yol haritasını kimler görmeli? Platforma bağımlı olan herkes. Onu hizmet verdiğiniz ekiplerle paylaşın ve liderleriyle birlikte gözden geçirin; böylece taahhüt edilenlere göre plan yapabilirler.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.