İş ve Hata Takip Yazılımı: Kendi Aracımızı Geliştirirken Öğrendiklerimiz

İş takip yazılımı, bir ekibin yapacağı işleri, çıkan hataları ve verdiği sözleri kalıcı kayıtlara bağlayan sistemdir. Çözdüğü asıl problem görev listesi tutmak değil, bilginin nerede durduğudur: bir işin neden başladığı, kimin elinde beklediği, hangi kararla ertelendiği ve sonunda ne olduğu tek bir yerde birikmezse, o bilgi sohbet pencerelerinde, e-postalarda ve insanların hafızasında dağılır. Ekip küçükken bu dağınıklık idare edilebilir; üç kişiden fazla olduğunuz anda maliyeti günlük olarak ödenmeye başlar.

İkinci çözdüğü şey görünürlüktür. Yöneticinin 'bu hafta ne çıkıyor', geliştiricinin 'bugün neye bakayım', destek ekibinin 'müşterinin bildirdiği hata ne durumda' sorusu aynı veriye farklı açılardan bakmaktır. İyi bir sistem bu üç kişiye üç ayrı ekran verir ama tek bir gerçeği gösterir. Kötü bir sistemde ise herkes kendi tablosunu tutar ve haftalık toplantı, tabloları birbirine uydurmakla geçer.

Bu yazıyı bir gözlemci olarak değil, problemin içinden geçen bir ekip olarak yazıyoruz. Stride'ı — ekiplerin iş, hata ve talep takibini tek akışta yürüttüğü platformu — kendi ihtiyacımızdan geliştirdik ve geliştirmeye devam ediyoruz. Aşağıda hem iş takip yazılımının bileşenlerini bir çerçeveye oturtacağız hem de bu çerçevenin her parçasını kendi ürünümüzde nasıl gerçeklediğimizi, nerede zorlandığımızı ve neyi bilinçli olarak sonraya bıraktığımızı adım adım anlatacağız.

Kendi aracımızı yazmamızın sebebi hazır araçların kötü olması değil, bizim çalışma biçimimizin alışılmadık olmasıydı. Aynı anda onlarca ürün geliştiriyoruz: bir tarafta sahada çalışan bir işletme platformu, öbür tarafta mobil bir uygulama, bir başka tarafta masaüstü araçlar. Bunların hepsi ayrı proje, ayrı ekip ritmi, ayrı sürüm takvimi demek. İhtiyacımız 'bir proje için mükemmel' bir araç değil, kırk projeyi aynı çatı altında tutup her birine kendi akışını verebilen bir araçtı.

İkinci sebep, verinin kendimizde kalmasıydı. Müşteri projelerinde bize gelen hata kayıtları çoğu zaman ekran görüntüsü, iş süreci detayı ve bazen kişisel veri içeriyor. Bunların nerede durduğu, kimin eriştiği ve gerektiğinde tamamen silinip silinemeyeceği bizim sorumluluğumuz. Ürünü kendimiz yazdığımızda bu sorunun cevabı 'sağlayıcının politikası ne diyorsa o' olmaktan çıktı, bizim mimari kararımız oldu.

Üçüncü sebep ise en dürüst olanı: kendi kullandığımız ürünü satmak istiyoruz. Bir ekip, her gün kendi kullandığı bir aracın eksiğini birkaç saat içinde fark eder; kullanmadığı bir aracın eksiğini ise ancak müşteri şikâyet edince öğrenir. Stride'ın yol haritası bu yüzden toplantı odasında değil, kendi işimizin akışında belirleniyor — bir şey bizi rahatsız ettiğinde o hafta düzeliyor.

Bir iş kaydının çekirdeği altı alandır: tip, başlık, durum, öncelik, sahip ve tarih. Geri kalan her alan, ancak bir soruyu düzenli olarak cevaplıyorsa hak ederek eklenir. Stride'da bir kayıt hata, görev, kullanıcı hikâyesi, epik ya da alt görev olabilir; bu beş tip yeterli çıktı, çünkü tip listesi uzadıkça insanlar hangisini seçeceklerini düşünmeye başlıyor ve kayıt açmak yavaşlıyor. Kayıt açmanın yavaşlaması, sistemin en sinsi ölüm biçimidir: insanlar yazmayı bırakır.

Kaydın ikinci katmanı ilişkilerdir. Bir iş başka bir işi engelliyor olabilir; bir epik altında onlarca iş toplanır; bir hata bir sürüme, bir bileşene ya da bir sprinte bağlıdır. Bu bağları alan olarak değil, ayrı ilişki kayıtları olarak tutmayı seçtik — böylece 'bu sürümde ne var' ile 'bu iş neyi engelliyor' aynı veriden iki farklı soru olarak sorulabiliyor. Hiyerarşiyi ise iki seviyeyle sınırladık: epik altında iş, işin altında alt görev. Üç seviyeden sonra kimse ağacın neresinde olduğunu bilemiyor.

Üçüncü katman ise ölçüm alanlarıdır: tahmin, hikâye puanı ve harcanan zaman. Bunların hepsi isteğe bağlıdır ve olmadan da sistem çalışır — ama sprint ölçümü yapmak istiyorsanız puan, fatura ya da maliyet takibi yapıyorsanız zaman kaydı gerekir. Burada verdiğimiz karar şuydu: zorunlu alan sayısını minimumda tutup, ölçümü isteyen ekibin kendi disiplinini kurmasına izin vermek. Sistem kimseyi puan girmeye zorlamaz; ama puan girildiğinde grafikler anlamlanır.

Durum akışını ekip tasarlamalı, ürün yalnızca sınırları koymalıdır. Bunu erken öğrendik: bir yazılım ekibinin akışı ile destek ekibinin akışı aynı değildir. Yazılımcı için 'kod incelemede' anlamlı bir duraktır, destek için anlamsızdır; destek için 'müşteriden bilgi bekliyor' hayati bir duraktır, yazılımcı listesinde yeri yoktur. Tek bir sabit akış dayattığınızda ekipler durumları kendi anlamlarına göre eğip bükmeye başlar ve bir süre sonra 'Beklemede' beş farklı şey demeye gelir.

Stride'da durumların adı, sırası ve rengi proje bazında tanımlanır. Ürünün koyduğu tek kural şudur: bir durum 'başlangıç' işaretli olmalı, en az bir durum da 'bitti' sayılmalıdır. Bu iki işaret olmadan hiçbir grafik çalışmaz — yanma eğrisi neyin bittiğini bilemez, hız grafiği neyi sayacağını bilemez. Yani ürün akışın içeriğine karışmaz, yalnızca ölçülebilir kalmasını şart koşar.

Bu esnekliğin bedeli, geçmişe dönük tutarlılıktır. Bir proje akışını değiştirdiğinde, eski kayıtların o anki durumu ne olacak? Biz durumları sabit bir kod listesi yerine projeye ait satırlar olarak tuttuğumuz için eski kayıtlar bağlı kaldıkları satırla birlikte yaşamaya devam ediyor; akış değişse de tarih bozulmuyor. Kulağa küçük gelen bu karar, altı ay sonra 'geçen çeyrekte kaç iş bitirmişiz' sorusunun cevap verilebilir kalmasını sağlıyor.

Panonun asıl işi işi göstermek değil, tıkanmayı göstermektir. Kartları kolonlar arasında sürüklemek yalnızca güzel bir etkileşimdir; panoyu değerli kılan şey, bir kolonun altında kartların birikmeye başladığını herkesin aynı anda görmesidir. Bu yüzden panoya erken eklediğimiz özellik sürükle-bırak değil, kolon başına iş limiti oldu: bir kolon sınırını aştığında kart taşımak serbesttir ama görsel uyarı düşer. Ekip 'daha fazla iş başlatmayı' değil, 'başlanmışı bitirmeyi' konuşmaya başlar.

İkinci mesele, panonun kim için olduğudur. Aynı panoya bakan iki kişi farklı şeyler arar: biri kendi işlerini, öbürü ekibin toplam yükünü. Kulvarlar (swimlane) bu yüzden var — kartları kişiye, epike ya da önceliğe göre yatay şeritlere bölerek aynı panoyu iki farklı soruya cevap verir hâle getiriyor. Ayrı bir 'kişisel pano' ekranı açmak yerine mevcut panoyu gruplayabilmek, öğrenilecek ekran sayısını azalttı.

Üçüncüsü gerçek zamanlılık. Panonun iki kişide farklı görünmesi, panonun olmamasından daha kötüdür: birinin taşıdığı kartı öbürü hâlâ eski kolonda görüyorsa, ikisi de aynı işi ayrı ayrı yapmaya başlar. Bunu canlı bir bağlantıyla çözdük; bir kart taşındığında ya da bir durum değiştiğinde açık olan panolar kendiliğinden tazeleniyor. 'Yenile' tuşuna basmak zorunda kalan bir ekip, bir süre sonra panoya güvenmeyi bırakır.

Planlamanın ölçülebilir olması için üç şey gerekir: sınırlı bir zaman kutusu, o kutuya konan işin bir büyüklüğü ve kutunun sonunda gerçekte ne bittiğinin kaydı. Sprint bu kutudur. Stride'da backlog sıradaki işlerin havuzudur; sprint başlatıldığında içine alınan işler o kutuya kilitlenir, sprint kapatıldığında bitmeyen işler otomatik olarak havuza döner. Bu 'geri dönüş' kısmı önemlidir: bitmeyen işi sessizce sonraki sprinte taşımak, ekibin gerçek hızını olduğundan yüksek gösterir.

Büyüklük konusunda saatler yerine hikâye puanını tercih ettik, ama ikisini de destekliyoruz. Sebep basit: saat tahmini kişiye bağlıdır, puan işe bağlıdır. Aynı işi kıdemli biri üç saatte, yeni biri iki günde yapar; ikisi de aynı puandır. Puanla ölçtüğünüzde ölçtüğünüz şey kişinin hızı değil, işin büyüklüğü olur — ve ekip değiştiğinde geçmiş veriniz anlamını korur.

Puan girmenin zorunlu olmadığını da söyleyelim. Bazı ekipler puanlamayı sevmez ve bu bir tercih meselesidir; sistem onlarsız da tam çalışır, yalnızca iki grafik boş kalır. Bizim kendi kullanımımızda puanlama, ürün ekibinin sprint dolgusunu yaparken 'bu sprint fazla dolu' diyebilmesi için var — geriye dönüp performans ölçmek için değil. Ölçüm aracının insan değerlendirme aracına dönüşmesi, verinin bozulmasının en hızlı yoludur; insanlar ölçüldüklerini bildikleri anda puanları şişirmeye başlar.

Yanma eğrisi bir sprint içinde kalan işin nasıl eridiğini, hız grafiği ise ekibin sprint başına gerçekte ne kadar iş bitirdiğini gösterir. İkisinin de söylediği şey tahmin değil, geçmiştir. Bir ekibin son beş sprintte ortalama kırk puan bitirdiğini biliyorsanız, altmış puanlık bir sprint planı bir hedef değil bir temennidir. Bu iki grafiğin bütün değeri, planlama toplantısındaki 'yetişir mi' tartışmasını sezgiden veriye taşımasıdır.

Yanma eğrisinin biçimi, sayısından daha çok şey söyler. Sprintin son iki gününde dikey düşen bir eğri, işlerin gerçekten son iki günde bitmediğini, sadece o gün 'bitti' işaretlendiğini gösterir — yani durumlar akış boyunca değil, sprint sonunda toplu güncelleniyordur. Düz giden bir eğri işlerin çok büyük parçalandığını, testere dişli bir eğri sprint ortasında kapsam eklendiğini anlatır. Biz bu grafiği ekip içinde 'nerede yanlış yapıyoruz' sorusunun aracı olarak kullanıyoruz.

Sprint dışı raporlarda ise soru değişir: 'bu proje sağlıklı mı' yerine 'hangi proje dikkat istiyor'. Portföy düzeyindeki karşılaştırma, açık iş sayısı, geciken iş oranı ve haftalık kapanış eğilimi gibi az sayıda göstergeyi yan yana koyar. Burada bilinçli olarak az gösterge tuttuk: on beş grafikli bir pano kimsenin bakmadığı bir panodur, dört göstergeli bir pano her sabah bakılır.

Bir ekibin işi genellikle ekibin dışından gelir ve çoğu sistem tam burada kopar. Müşteri bir hata bulur, e-posta atar ya da telefonla arar; birisi bunu duyar ve iş kaydına elle geçirir. Bu elle geçirme adımı hem gecikme hem de kayıp üretir: yoğun bir gün, ekran görüntüsü olmayan bir açıklama, sonra 'sen bunu açmış mıydın'. Stride'da bu adımı ortadan kaldırmak için işi tersten kurduk: dışarıya bir form yayınlarsınız, o formdan gelen her gönderim doğrudan iş kaydına dönüşür.

Form projeye bağlıdır, alanlarını siz tasarlarsınız — metin, e-posta, telefon, sayı, seçim listesi, onay kutusu — ve gelen kaydın hangi tipte açılacağını, kime düşeceğini önceden belirlersiniz. Formu dolduran kişinin hesabı olmasına gerek yoktur; bağlantıyı paylaşırsınız, o kadar. Bu, destek talebi toplamak için ayrı bir sistem kurmadan, müşteriyle ekip arasındaki en kısa yolu açar.

Açık form aynı zamanda bir kötüye kullanım kapısıdır, o yüzden baştan iki koruma koyduk: robotları yakalayan gizli alan ve aynı kaynaktan gelen gönderim sayısını sınırlayan hız kısıtı. Bunlar kullanıcıya görünmez ama olmadıklarında, formu yayınladıktan bir hafta sonra projenizin ilk yüz kaydı reklam spam'i olur. Dış dünyaya açılan her uç, açıldığı gün korunmalıdır — sonra eklenen koruma, temizlenecek veri de bırakır.

Bildirim sisteminin başarısı kaç bildirim gönderdiğiyle değil, kaç bildirimin okunduğuyla ölçülür. Herkese her şeyi gönderen bir sistem, iki hafta içinde herkesin sustuğu bir sisteme dönüşür: insanlar bildirimleri toplu olarak okundu işaretlemeye başlar ve gerçekten önemli olan da o yığının içinde kaybolur. Bu yüzden Stride'da bildirim ilgi temellidir: bir işe atandıysanız, işi siz açtıysanız, yorumda etiketlendiyseniz ya da o işi açıkça takibe aldıysanız haber alırsınız.

İkinci ayrım, bildirimin nerede yaşadığıdır. Uygulama içi bildirim merkezi kalıcıdır ve okunmamışları biriktirir; canlı bağlantı ise siz ekrana bakarken anlık olarak ilerler. Üçüncü kanal olan e-posta bilinçli olarak opsiyoneldir: sunucu ayarı boşsa sistem sessizce e-posta göndermez, hata da vermez. Bunu, ürünü kendi sunucusuna kuran bir ekibin e-posta altyapısı hazır olmadan da tam çalışabilmesi için böyle tasarladık.

Bir de zamanla ilgili bildirim var: teslim tarihi yaklaşan işler. Bunu kullanıcı eylemine değil, sunucuda düzenli çalışan bir arka plan görevine bağladık. Basit gibi görünse de burada öğrendiğimiz ders şu oldu: hatırlatma gönderen her sistemin, aynı hatırlatmayı iki kez göndermeyeceğine dair bir kaydı olmalı. Yoksa sunucu yeniden başladığında herkes aynı uyarıyı ikinci kez alır ve sisteme duyulan güven tam da böyle ufak şeylerle aşınır.

Arama zorlaşır, çünkü ilk yılın sonunda aradığınız şey artık bir kelime değil, bir kesişimdir: 'bu projede, bana atanmış, açık ve önceliği yüksek olanlar'. Tek bir arama kutusu bu soruyu cevaplayamaz. Stride'da bu yüzden iki ayrı yol var: anahtarla doğrudan gitmek ve filtreyle daraltmak. Bir kaydın anahtarını (ör. WEB-142) yazdığınızda arama sonucu listesi değil, doğrudan o kayıt açılır — gün içinde en sık yapılan iş bu olduğu için en kısa yol ona verilmiştir.

Filtreleme tarafında verdiğimiz teknik karar, listeyi tarayıcıda değil sunucuda süzmekti. Kayıt sayısı birkaç bini geçtiğinde 'hepsini indir, tarayıcıda filtrele' yaklaşımı hem yavaşlar hem de belleği şişirir. Sunucu taraflı sayfalama ve sıralama, listeyi ilk günkü hızında tutar; onun karşılığında her filtre kombinasyonunun veritabanında karşılığı olacak şekilde sorgu yazmak gerekir — bu, geliştirme tarafında ucuz değildir ama kullanıcı tarafında pazarlık edilecek bir konu da değildir.

Filtrelerin ikinci hayatı, kaydedilip paylaşılmalarıdır. Bir ekipte aynı sorular tekrar tekrar sorulur: 'test bekleyenler', 'bu sürüme kalanlar', 'iki haftadır dokunulmayanlar'. Bunları her seferinde yeniden kurmak yerine kaydedip ekiple paylaşmak, filtreleri ortak bir dile dönüştürüyor. Ayrıca aynı liste CSV olarak dışarı alınabiliyor — veri sizde kaldığı sürece hiçbir aracın esiri olmazsınız, biz de kendi ürünümüz için bu kapıyı açık tutmayı ilke edindik.

Yetkilendirme, kimin ne yapabileceğinden önce kimin ne görebileceği sorusudur. Bir kurumda bütün projelerin herkese açık olması çoğu zaman sorun değildir; ama müşteri projeleri aynı kurulumda yaşıyorsa, bir müşterinin kaydının başka bir müşterinin ekibine görünmemesi gerekir. Stride'da bu ayrım proje düzeyinde çözülür: her projenin kendi üyeleri vardır ve üyelik üç rolden birine bağlanır — yöneten, çalışan, izleyen. İzleyen okur ama değiştiremez; bu rol, işin gidişatını görmesi gereken ama akışa dokunmaması gereken paydaşlar için vardır.

Takımlar ise proje sınırını aşan ikinci bir katmandır. Aynı beş kişi altı projede birlikte çalışıyorsa, her projeye tek tek üye eklemek yerine takım olarak tanımlanır; bir kişi birden fazla takımda olabilir. Bu ayrımı yapmamızın sebebi organizasyon şeması çizmek değil, iş yükü sorusuna cevap verebilmekti: 'bu ekip şu an ne kadar dolu' sorusu, ancak ekip diye bir kavram varsa cevaplanabilir.

Üçüncü ayak denetim izidir ve bizce en çok hafife alınan özelliktir. Stride'da bir kaydın hangi alanı, kim tarafından, ne zaman ve neyden neye değiştirildi — hepsi ayrı bir geçmiş kaydına düşer. Bunun günlük faydası tartışmayı bitirmesidir: 'bu iş neden kapatılmış' sorusunun cevabı hafızada değil kayıttadır. Kurumsal faydası ise denetimdir; bir sürümde neyin ne zaman değiştiğini gösteremiyorsanız, süreç belgeniz ne yazarsa yazsın elinizde kanıt yoktur.

Birincisi arayüzün tazelenme disiplini oldu. Arayüzü, değişiklikleri otomatik yakalayan klasik yöntem yerine, her değişimin açıkça bildirildiği bir kipte yazdık; bu, uygulamayı belirgin biçimde hızlandırıyor ama karşılığında disiplin istiyor. Sunucudan dönen her cevapta ekranın tazelenmesi gerektiğini açıkça söylemeyi unutursanız, veri gelir ama ekran eski hâlinde kalır — üstelik hata da vermez. Bu tip sessiz kusurları yakalamanın tek yolu, kuralı istisnasız uygulamak oldu.

İkincisi panonun sıra ve durum tutarlılığıydı. Kart taşımak görünüşte 'durumu değiştir' demektir; gerçekte ise hem kolonu hem de kolon içindeki sırayı değiştirmek, aynı anda başkasının yaptığı taşımayla çakışmamak ve bunu tek bir işlemde kaydetmek demektir. İki kişi aynı kartı aynı saniyede taşıdığında hangisinin kazanacağına karar veren bir kural yazmadan pano güvenilir olmuyor.

Üçüncüsü, kütüphane kullanmadan yazmayı seçtiğimiz iki parçaydı: zengin metin editörü ve grafikler. Hazır bileşen almak günü kurtarır, ama uzun vadede sürüm bağımlılığı, tema uyumsuzluğu ve lisans meselesi getirir. İkisini de kendimiz yazdık; editör tarayıcının kendi düzenlenebilir alanı üzerine, grafikler doğrudan vektör çizimle. Bedeli birkaç haftalık ek emek oldu, kazancı ise tam kontrol ve sıfır dış bağımlılık.

Dördüncüsü ise en can sıkıcısıydı: her yazma işleminde denetim kaydının da yazılması. Bir alanı güncelleyen her uç, aynı işlem içinde 'ne değişti' kaydını da bırakmak zorunda. Bunu tek bir yerde çözmezseniz, altı ay sonra bazı alanların geçmişi tutulur bazılarının tutulmaz ve denetim izi güvenilirliğini kaybeder — yarım denetim izi, olmayandan daha tehlikelidir, çünkü ona güvenirsiniz.

Stride bugün on üç ayrı proje ekranıyla çalışıyor: özet, pano, backlog, liste, takvim, zaman çizelgesi, raporlar, yol haritası, bileşenler, sürümler, formlar, şablonlar ve proje ayarları. Bunların üstünde kişisel panolar, tüm projelerde arama, bildirim merkezi, takımlar ve yönetim ekranları var. Veri tarafında yirmi altı tablo, uygulama tarafında ise projeden sprinte, yorumdan zaman kaydına kadar on dokuz ayrı işlev ailesi yaşıyor.

Yapılmayanları da aynı netlikle söyleyelim, çünkü ürün sayfasında 'yakında' yazan her şeyin bir gerekçesi var. Dosya eki henüz iş kaydına bağlı değil: nesne depolama altyapısı kurulu ve çalışıyor, ama ekin kayda iliştirilmesi, boyut sınırı ve erişim yetkisi tasarımı bitmeden açmak istemedik. Dış sistemlerle entegrasyon uçları da yol haritasında — bugün var gibi anlatmaktansa yokluğunu söylemeyi tercih ediyoruz.

Ürünün geliştirme hızıyla ilgili bir not: Stride, çekirdeğini birkaç günde alan bir uygulama değil, uzun süredir olgunlaştırdığımız bir altyapının üstünde yükselen bir üründür. Kimlik doğrulama, yetki, tablo bileşeni, form denetimleri ve dağıtım hattı gibi parçalar aile içindeki diğer ürünlerle ortaktır; biz de bu sayede enerjimizi iş takibinin kendine özgü problemlerine — akış, pano, sprint, denetim izi — ayırabildik.

Kurulum modelini teknik tercih değil, verinin sorumluluğu belirler. Bulut aboneliği, kurulumu, yedeği, güncellemeyi ve izlemeyi sağlayıcıya bırakır; ekibiniz ilk gün çalışmaya başlar, sistem yöneticisi ayırmanız gerekmez. Küçük ve orta ekiplerin büyük çoğunluğu için doğru cevap budur — çünkü kendi sunucusunda yazılım işletmenin görünmeyen maliyeti, lisans farkından çok daha yüksektir.

Kurum içi kurulum ise verinin kurum dışına çıkmaması gerektiğinde anlam kazanır: kamu, savunma, finans, sağlık ve kendi veri merkezini işleten büyük kurumlar. Burada tartışma güvenlik değil, yetki alanıdır — verinin hangi hukukun, hangi ağın ve hangi yedekleme politikasının altında durduğu. Stride bu iki modelde de aynı çekirdekle çalışır; kurum içi sürüm 'kısıtlı sürüm' değildir, aynı üründür.

Kimlik doğrulamayı her iki modelde de merkezî bir oturum açma servisine bağladık ve parolayı uygulamada tutmuyoruz. Oturum jetonu sunucu tarafında yaşıyor; bu, bir kullanıcının erişimini gerçekten anında kesebilmek anlamına geliyor. İstemcide taşınan, süresi dolana kadar iptal edilemeyen bir jeton kullanmamayı bilinçli olarak seçtik — çünkü 'bu kişinin erişimini şimdi kapat' talebi, kurumsal bir üründe teorik değil, sık gelen bir taleptir.

Bir: durum akışını kendiniz tanımlayabiliyor musunuz, yoksa ürünün akışına uymak zorunda mısınız? İki: verinizi istediğiniz gün, eksiksiz ve makine okunur biçimde dışarı alabiliyor musunuz? Üç: ekip dışından gelen talep sisteme elle mi giriliyor, yoksa doğrudan kayda mı dönüşüyor? Bu üç sorunun cevabı, aracı bir yıl sonra sevip sevmeyeceğinizi büyük ölçüde belirler.

Dört: kim neyi görür sorusu proje düzeyinde çözülüyor mu — yoksa 'herkes her şeyi görür' mü? Beş: bir kaydın geçmişi tutuluyor mu, hangi alanın kim tarafından değiştirildiğini gösterebiliyor musunuz? Altı: ekip büyüdüğünde liste ekranları yavaşlıyor mu; on bin kayıtla denenmiş mi? Bu üçü, aracın küçük ekipte iyi görünüp orta ölçekte çatırdayıp çatırdamayacağını söyler.

Yedi: ürünün arkasındaki ekip ürünü kendisi kullanıyor mu? Bu soru duygusal görünür ama pratik karşılığı vardır: kendi kullandığı aracın eksiğini ekip birkaç saatte fark eder, kullanmadığı aracınkini ancak siz şikâyet edince öğrenir. Cevabı 'evet' olan ürünlerde yol haritası kullanıcının gündemine daha yakın seyreder.

İş takip yazılımının değeri, ekibe kaç alan sunduğunda değil, ekibin ona ne kadar az bakmak zorunda kaldığında saklıdır. İyi bir sistem, sabah açıldığında 'bugün ne yapacağım' sorusunu tek ekranda cevaplar, gün içinde yolunuza çıkmaz ve altı ay sonra 'bu neden böyle yapıldı' diye sorduğunuzda cevabı hâlâ elinde tutar. Bu üçünü aynı anda yapabilmek için gereken şey daha fazla özellik değil, doğru yerlere konmuş birkaç sağlam karardır: akışı ekibe bırakmak, ölçümü zorunlu kılmamak, dış dünyaya açılan kapıyı ilk günden korumak ve her değişikliği kayda geçirmek.

Stride'ı kendi ihtiyacımızdan geliştirdik ve her gün kendimiz kullanıyoruz; bu yazıdaki her tespit de o kullanımın içinden çıktı. Ürün bulutta abonelikle ya da kendi sunucunuzda kurulu çalışıyor, eksikleri açıkça işaretli ve yol haritası kendi işimizin ritmiyle ilerliyor. Ekibinizin çalışma biçimini anlatırsanız, akışı birlikte kurar ve hangi kurulum modelinin size uyduğuna beraber karar veririz.