Özellikleri İki Kat Daha Hızlı Yayınlamaya Nasıl Başladık (Örnek Olay)

İşletmeler günlük işleri için uygulamanıza güvendiğinde, onların ihtiyaçlarını hızla karşılamak için yeterince çevik olmanız gerekir. Sen yapmazsan, diğerleri kesinlikle yapacak. SaaS'ın affetmeyen dünyasında, kritik bir özelliği geciktirmek (veya hata yüklü bir kod parçasını aceleye getirmek) müşteri kaybetmek anlamına gelir. Sağlam bir çevik iş akışı tüm farkı yaratabilir.

Sürekli büyüyen özelliklere ve büyük bir kullanıcı tabanına sahip bir proje yönetimi uygulaması olan Active Collab'ın arkasındaki ekibiz. Bu, işlevsellikteki en küçük değişikliğin bile çok sayıda insanı etkileyeceği anlamına gelir.

SmashingMag'de Daha Fazla Okuma :

• Sadık Kullanıcılara Zarar Vermeden Yeni Özellikler Nasıl Sunulur?
• Web Sitesi Başlatma Kontrol Listesi – Canlı Yayına Başlamadan Önce 15 Temel Kontrol
• Mobil Cihazlar İçin Web Tasarımına Kullanıcı Merkezli Bir Yaklaşım
• Herhangi Bir Şey Nasıl Başlatılır
  

Bu nedenle, geliştirme sürecinin sorunsuz ve bir standarda kadar, gecikmelerin en aza indirilmiş olması gerekir. Herhangi bir değişiklik son kullanıcıya ulaşmadan önce beş önemli aşamadan geçer: geri bildirim, tasarım, geliştirme, kalite güvencesi ve dağıtım . Bu makalede, sekiz yılı aşkın bir süredir sektördeki aşamaların her biri hakkında öğrendiklerimizi (zor yoldan) paylaşacağım.

Uyandırma Çağrısı

Ayrıntılara girmeden önce, tüm bunların nasıl gerçekleştiğine bir bakalım. Yeterince inceleme olmadan yıllarca özellik ekledikten sonra, uygulamamız özellik şişmesinden muzdaripti. Yıllar içinde o kadar çok işlevsellik ekledik ki, yeni kullanıcılar kullanıcı arayüzünün (bir daha asla geri dönmeyecekleri) katıksız karmaşıklığından korktular. Bu, her bir özelliği sıfırdan yeniden yazmak anlamına gelse bile, sıfırdan yeniden oluşturmamız gerektiğini biliyorduk.

Sonra gecikmeler geldi. Yeni sürümlerin özellikleri sürekli olarak programın gerisinde kalıyordu. Örneğin, küçük bir geliştiricinin QuickBooks ile bir entegrasyon geliştirmesi gerekiyordu. Gereken karmaşıklığı, becerileri veya bilgiyi doğru bir şekilde tahmin edemedik. Ayrıca, bu göreve atanan tek kişi oydu ve kimse ona yardım etmek için hemen atlayamazdı. Sonuç olarak, iki haftalık olması gereken bir iş, beş gün sürdü. Bunlar birkaç kırmızı bayraktı.

Açıkça daha çevik bir yaklaşıma geçmenin zamanı gelmişti. Çeşitli çevik (ve çok çevik olmayan) yöntemlerden beğendiklerimizi aldık, deneyimle birleştirdik ve o zamandan beri harika sonuçlar veren kendi versiyonumuzu ortaya çıkardık.

Bir özelliğin son kullanıcıya sunulmadan önce kat etmesi gereken yola daha yakından bakalım.

Öneriden Özelliğe

İş akışımızda, geliştirme ekibine ulaşmadan çok önce yeni bir özellik şekillenmeye başlar ve genellikle kullanıcı geri bildirimlerinden doğar. Bu bir tesadüf değil — eskiden kimsenin ihtiyaç duymadığı özellikleri yayınlardık, çünkü genellikle bir kullanıcı çok gürültülüydü ya da bir şeye sahip olmanın harika olacağını düşündük. Kullanıcılarımızın hangi özelliklere ihtiyaç duyabileceğini hayal etmek yerine, artık gerçek talebe göre kararlar alıyoruz.

Yalın üretimle ilgileniyorsanız, müşterilerimizin belirli özellikleri diğerlerinden daha sık talep ederek "çektiğini" söyleyebilirsiniz. Destek ve satış ekiplerimiz, ihtiyaç ve fikirlerini paylaşan kullanıcılarla sürekli iletişim halinde oldukları için sürecin büyük bir parçasıdır.

Geri bildirimlere dayanarak ekiplerimiz şuna benzeyen bir formu günceller:

İhtiyacımız olan tüm bilgilere sahip olmadığımızda, doğrudan müşterilere ulaşacağız. Bu genellikle dikkatle seçilmiş bir örnek üzerinde hedeflenen anketlerle yapılır. Mesele şu ki, dinliyoruz. Bizimle ilgili hiçbir geri bildirim kaybolmaz. Her zaman kabul edilir ve belgelenir.

Bir sonraki adım analizdir. Hangi özelliğin en çok oyu aldığını görmek için her ay puanları topluyoruz. Ayrıca, uygun kategorizasyonla, yazılımımızın hangi bölümlerinin çalışması gerektiğine dair daha geniş bir bakış açısı elde ederiz. Örneğin, takvim çok sayıda şikayet alıyorsa, en çok oyu alan özelliği (takvim dışa aktarma gibi) sunmak yerine tüm bölümü yenilemeyi düşünürüz.

Ancak, sonuçlar ortadayken bile, bir özelliği tanıtma kararı nihai değildir. Yapılacaklar listemize girmeden önce, her zaman kapsamlı bir akıl sağlığı kontrolü yaparız:

• Bu özellik kullanıcılara ne gibi faydalar sağlayacak?
• Ürün felsefemize uyuyor mu?
• Gereksiz karmaşıklık katacak mı?
• Mevcut arayüz ve işlevsellik ile güzel bir şekilde uyum sağlıyor mu?
• Makul bir zaman diliminde teslim edecek kaynaklara sahip miyiz?

Bir özellik kontrol listesinden geçtiğinde ve ürün sahipleri tarafından onaylandığında, çizim tahtasına gitme zamanıdır.

Kullanıcı İçin Tasarlama

Deneyim bize, yeni bir özellik eklemenin sadece onu kullanıcı arayüzünün üstüne yapıştırmak anlamına gelmediğini öğretti - onu mevcut tasarımla, kullanıcıyı göz önünde bulundurarak harmanlamanız gerekiyor. Bunu yapmazsanız, kısa süre sonra, denemenin ilk beş dakikasını yalnızca birkaç cesur kişinin atlatabileceği kadar karmaşık bir uygulamayla karşılaşacaksınız (evet, oradaydık). Estetik de iyi bir ilk izlenim için önemlidir, ancak asıl endişemiz kullanım kolaylığıdır . Kullanıcıya doğal hissettirecek bir özellik eklenmelidir.

Kullanıcı bu seçeneğin nerede olmasını bekler?

Mevcut kullanıcılar için yeni tasarımın aşina oldukları kalıpları takip etmesi ve iş akışlarını bozmaması önemlidir. Ayrıca, hepimizin (bilinçsizce) alıştığı endüstri standartları ve gelenekleri vardır. Kullanıcılarınızın alışkanlıklarını tamamen değiştirmesini asla beklemeyin. Arayüz sezgisel değilse, muhtemelen başka bir yere bakacaklardır.

Klavye kısayollarını alın. Kendi kısayol setinizi oluşturabilir ve kullanıcıların bunları öğrenmesini bekleyebilirsiniz (muhtemelen öğrenmeyecektir). Veya insanların zaten kullandıklarını ekleyebilirsiniz. Örneğin, birçok kullanıcımız zaten Slack kullanıyor, bu nedenle zaten aşina oldukları bir kısayol ekledik ( Hızlı atlamalar için Command + K Active Collab'da da çalışır).

Kullanıcı akışları yerinde olduğunda, UX tasarımcımız tasarımı Sketch'te taklit eder. Erken aşamalarda HTML'yi nadiren kullanırız. İyi düşünülmüş Sketch görselleştirmeleri, kodlamaya başladığımızda herhangi bir geri izleme yapmak zorunda kalmamamız için bize yeterince esneklik sağlar. İlk tasarım genellikle nihai ürünün yaklaşık %80'i ile eşleşir. Gerisi yol boyunca eklenir ve ayarlanır.

Tasarım sürecinin bir diğer önemli adımı da kopyalamadır. Metin yazarlarımız her bir kelimeye büyük önem veriyor. Hatta kulağa olabildiğince yaklaşılabilir ve mümkün olduğunca kolay anlaşılır olması için kendi stil rehberimiz bile var. Örneğin, “SSL sertifikası” yerine “güvenlik sertifikası” demek, sıradan bir kullanıcının terimleriyle ortalama bir kullanıcının aşina olmadığı bir şeyi ifade eder.

Tüm bunlar yapıldığında özellik bir geliştirme ekibine atanır. Ekip, iş yüküne bağlı olarak bir proje yöneticisi, bir lider geliştirici ve bir dizi arka ve ön uç geliştiriciden oluşur. Proje yöneticisi her şeyin sorunsuz ve programa uygun şekilde çalışmasını sağlarken, baş geliştirici ise işlerin teknik tarafıyla ilgilenir. Ayrıca genç geliştiricileri koordine eder ve onlara rehberlik ederler.

İşleri Başlatma Zamanı

Başlangıç ​​toplantılarımız sıkıcı, motive edici buluşmalar değil. Bunlar, bir geliştirme ekibinin (küçük ve kıdemli geliştiricilerden oluşan) proje yöneticisi ve ürün sahibi ile görüşmesi için fırsatlardır.

Boş monologlara izin vermek yerine, herkesin sözlerini eyleme geçirilebilir görevlere koymaya odaklanıyoruz. Gün boyunca üç önemli toplantı gerçekleşir:

• Ürün sahibi, verilen özelliği ekibe, arkasındaki fikirleri, ilk tasarımları ve beklenen sonuçları sunar.
• Ardından, ekibin eylem planını, olası sorunları ve test programını tartıştığı kendi toplantısı vardır.
• Nihai toplantıya katılan herkes katılır ve plan son şeklini alır. Bu toplantının sonunda ekip, demolar için tahminler ve son teslim tarihi verir.

Bir gün için üç toplantı çok fazla gibi gelebilir, ancak bu şekilde sorunların erken çözülmesini sağlıyoruz. Bu aşamada boşlukları doldurmak, geliştiricilerimize çok fazla zaman, yanlış başlangıçlar ve geri izleme kazandırır. Toplantılar ayrıca ekip çalışmasını teşvik eder ve herkesin katkılarının memnuniyetle karşılandığını hissettirir.

Toplantılardan sonra ekip gerekli tüm bilgilere sahip olacaktır:

1. Ne? Bu, özelliğin kapsamıdır ve yapılması gereken her şeyin yanı sıra olası engelleyicileri ve darboğazları içerir. Mümkün olduğunca çok senaryo ve uç vaka tahmin etmeye çalışıyoruz. Hepsini tahmin etmek kolay değil; genellikle biz giderken ortaya çıkarlar.
2. Niye ya? Ürün sahibi, bir özelliğin ticari değerini tahmin eder ve neden bu çabaya değdiğini açıklar. Bu şekilde ekip, müşterilere ve ürüne sağlanan faydaların net bir resmini elde eder. Buradaki ana motivasyon, herkesin çalışmalarının neden önemli olduğunu ve bir bütün olarak şirkete nasıl katkıda bulunduğunu anlaması gerektiğidir.
3. Nasıl? Bir özelliği tamamlamak için gereken adımları özetleyerek geliştiricilerimizin pusulalarını asla kaybetmemelerini sağlıyoruz. Ayrıca bir karmaşıklık etiketi ekleyerek gerçekçi beklentiler belirledik. T-shirt bedenleriyle gittik - S birkaç saat içinde çözülebilirken, XXL'in tamamlanması haftalar veya daha uzun sürüyor.
4. Kim? Ekip lideri, bir özelliği veya görevi zamanında bitirmekten ve ürün sahibini ilerleme konusunda güncellemekten sorumludur . Diğer ekip üyeleri kendi alt görevlerine atanır, böylece kimin neyden sorumlu olduğu tamamen açıktır. Bunu mümkün olduğunca şeffaf tutmak, birinin zorluk çekip çekmediğini veya gecikmelere neden olup olmadığını görmemize yardımcı olur.
5. Ne zaman? Her şey göz önüne alındığında, bir son tarih tahmin edilir . Bir görev ertelenirse, nedenlerini analiz eder ve bir dahaki sefere bu deneyimi kullanırız. Bu şekilde, kaçırılan bir teslim tarihi, bir stres kaynağı değil, bir öğrenme fırsatı haline gelir.

Başlangıç ​​günü telaşlı olabilir ama aynı zamanda çok verimlidir. Herkes fikir ve yorumlarla devreye giriyor. Bir görev, boş bir listeden yorumlar, düzenlemeler ve güncellemeler için bir merkeze dönüşür. Günün sonunda, geliştirme ekibinin önlerindeki işin net bir resmi ve üzerine inşa edilecek sağlam bir zemini var.

Çalışmaya başlamadan önce bu kontrol listesini gözden geçiriyoruz:

• özellik açıkladı,
• özetlenen tamamlama adımları,
• ürün sahibi tarafından atanan iş değeri,
• ekip tarafından atanan karmaşıklık,
• özellik ve hata bağımlılıkları belirlendi,
• belirlenen performans kriterleri (gerekirse),
• demolar planlanmış,
• takım lideri tarafından belirlenen başlangıç ​​ve bitiş tarihleri.

Bu, bir görevin "Devam Ediyor" sütununa taşındığı andır.

Kodlama zamanı!

Ekranda Ekip Çalışması

Geliştiricilerimiz asla yalnız çalışmaz — bu her zaman bir ekip çalışmasıdır ve yeni özellikleri yayınlamanın açık ara en verimli yoludur. Ekipler tanıtılmadan önce, (küçük) bir geliştirici bir soruna takılıp kalır ve günlerce (kimsenin farkına varmadan) daireler çizebilirdi. Ya da yalnız korucu tipi olmasaydı, sürekli olarak iş arkadaşlarının ve yöneticilerin dikkatini dağıtırlardı.

Öte yandan, ekiplerle, farklı beceri setlerine ve deneyim seviyelerine sahip insanları bir araya getiriyoruz. Bu, herkese seviyelerine uygun bir dizi görev atandığı anlamına gelir. Ayrıca, kıdemliler, genç takım arkadaşlarını nasıl yöneteceklerini ve onlara nasıl koçluk yapacaklarını öğrenme avantajına sahip olur ve gençler yardım isteyebilir. Bu bir ekip çalışması olduğundan ve herkes aynı amaç için çalıştığından, sorular dikkat dağıtıcı olarak kabul edilmez ve ekip herhangi bir sorunu çok daha verimli bir şekilde çözebilir. Ekip, işi aşamalara (veya sprintlere) bölerek ve çalışmalarını demolar sırasında sunarak kendi kendini organize eden bir varlık haline gelir.

Göster ve Anlat

Programa göre ekip, ürün sahibi için demo yapacak. Demoların amacı, bir özelliğin mevcut durumunda ne kadar iyi performans gösterdiğini ve nerede daha fazla cilaya ihtiyaç duyduğunu göstermektir. “Sadece birkaç son rötuş gerekiyor” (bir ay daha sürecek rötuşlar) gibi mazeretlere izin vermeyen bir gerçeklik kontrolü. Ayrıca, işler ters gitmeye başlarsa, ürün sahipleri hızlı tepki verir.

Haftalık Toplantılar

Tüm geliştiricilerin katıldığı düzenli kısa günlük toplantılarla başladık. Her geliştirici kısaca ne üzerinde çalıştıklarını, sorunlarını, engelleyicilerini ve yardıma ihtiyaç duyup duymadıklarını açıklayacaktır. Bu toplantıların daha fazla odaklanması ve somut sonuçlar vermesi gerektiği çok geçmeden anlaşıldı. Böylece, bireysel ekiplerle haftada bir kez toplantılar yapmaya geçtik. Ürün sahipleri ve proje yöneticisi bu şekilde döngüde tutulur ve tüm olası sorunlar anında giderilir.

Test Etme

Kod yazıldı, demolar başarılı oldu, her şey güzel bir şekilde tamamlanıyor gibi görünüyor... ta ki siz özelliği yayınlayıp uygulamanın çöktüğünü görene kadar. Bu nedenle yaptığımız her özellik kalite güvencesinden (Q/A) geçer . Hep. Test cihazımız, olası her senaryoyu titizlikle inceler, tüm seçenekleri kontrol eder ve testleri farklı ortamlarda çalıştırır. Bir özellik, ilk seferde nadiren Q/A'yı geçer.

Üretkenliği artırmak için, geliştiricilerin bu aşamada yeni özelliklere başlamasına izin verirdik, ancak bu sadece birçok gecikmiş, yarı bitmiş özellik ile sonuçlandı. Bu nedenle, geliştirme ekibi, özellikleri gözden geçirilirken küçük bakım görevleri üzerinde çalışarak meşgul olmaya devam ediyor. Soru/Cevap bir sorun bulursa, geliştiriciler sorunu hemen düzeltir ve yeniden gönderir. Özellik Q/A'yı geçene ve kod incelemesine geçene kadar süreç tekrarlanır.

Bu, kıdemli bir geliştiricinin kodun standartlarımıza göre yazıldığından emin olduğu zamandır. Yayınlanmadan önceki son bir adım, belgeleri yazmaktır - kimsenin nasıl kullanılacağını bilmediği bir özelliği yayınladıktan sonra destek e-postalarına boğulmak istemezsiniz. Metin yazarlarımız ayrıca sürüm notlarını günceller ve e-posta duyuruları ve blog gönderileri gibi pazarlama materyalleri yazar.

İşte "bitti" tanımımız:

• otomatik testler yazılı,
• Soru/Cevap tamamlandı ve ortaya çıkan tüm görevler tamamlandı,
• kod incelemesi yapıldı ve kod master ile birleştirildi,
• sürüm notları güncellendi,
• özellik ve hata bağımlılıkları belirlendi.

Görev, “Release Q” adı verilen son aşamaya ulaştı.

Yayın Günü

Yeni sürümler için bir gün seçerken, hemen Cuma ve Pazartesi olarak karar verdik. Cuma günü iyi değil çünkü olası sorunlar Pazartesi'ye kadar çözülmez; artı, destek ekibi o zaman zaten oldukça meşguldü. Pazartesi en iyi zaman değil çünkü herhangi bir büyük güncelleme, hafta sonu yapılması gereken hazırlık gerektiriyor. Son rötuşlar için bir gün bırakmak her zaman iyidir. Bu, seçenekleri üç güne indirir - ve Salı ile gittik. İşte nedeni:

• Sürümü gözden geçirmek ve dağıtmadan önce son rötuşları eklemek için Pazartesi gününe sahibiz.
• Çevrilmemiş ifadeler varsa (web uygulamamız yedi dilde mevcuttur), çeviriyi bitirmek için yeterli zamanımız var.
• Pazarlama ekibinin sosyal medya aracılığıyla haber bültenleri ve duyurular göndermek için bolca zamanı vardır.
• Haftanın geri kalanında hızlı ve verimli bir şekilde yükseltme desteği sağlamaya hazırız.
• Herhangi bir nedenle son teslim tarihi geçtiyse, işi tamamlamak için hala Çarşamba veya Perşembe günleri var.

Ücretsiz Aktivite Günü

Büyük bir sürümden sonraki gün, ekip için ücretsiz bir gündür. Bu, yeni beceriler öğrendikleri veya işle ilgili ilginç buldukları bir şey yaptıkları zamandır. Herkes ertesi gün hangi özelliği başlatacağımızı merak etse de ekip henüz bunu tartışmıyor. Bunun yerine, rahatlayacaklar ve belki Erlang'ın tarihi hakkında bir sunum izleyecekler veya PSR-7 ve ara yazılımın modern PHP geliştirmesi için neden önemli olduğu hakkındaki makaleyi okumayı bitirecekler veya kendi geçmişe dönük tartışmalarını yapacaklar. Pillerini şarj etmek ve iyi yapılmış bir işi kutlamak için hak edilmiş bir gün.

Böcek Avı Günü

Büyük yeni özellikler geliştirmenin yanı sıra, her zaman mevcut olanlar üzerinde yapılacak işler vardır. Bir hata düzeltmesi, bir tasarım güncellemesi veya işlevsellikte küçük bir değişiklik olsun, ekibin makul bir süre içinde bununla ilgilenmesi gerekir.

Bu nedenle ayda en az bir kez böcek avlama günlerimiz oluyor. Bu, tüm geliştiricilerin ana projeleri üzerinde çalışmayı bırakıp dikkatlerini bakıma verdiği zamandır. Bu odaklanmış çabanın büyük bir başarı olduğu kanıtlanmıştır. Herkes aynı gün yalnızca hatalar üzerinde çalıştığında ve birbirlerine yardım etmeye hazır olduğunda, ekip çok sayıda sorunu çözer.

Sonuç nedir?

Büyük bir özelliğin piyasaya sürülmesi, başlangıçtan geliştirme, test etme, kod inceleme, belgeleme ve son sürüme kadar ortalama olarak yaklaşık üç hafta sürüyor. Bize 45 gün süren eşdeğer karmaşıklıkta bir özellik. Bizim bakış açımıza göre, bu verimlilikte %100'lük bir artış . Bunu aynı kaynaklar ve insanlarla başardık, tek fark iyileştirilmiş bir iş akışıydı.

O halde, sizin için bir çıkarımımız varsa, o da şudur: Değişim korkusunu ortadan kaldıran bir şirket kültürünü beslemek, ekibinizi yaptığı işte daha iyi hale getirecektir. Şirketinizin büyümesine yardımcı olduğu sürece Scrum, Kanban veya Yalın olarak adlandırmanız önemli değil. Herhangi bir çevik yaklaşımın kalbinde deney ve yenilik yatar. Farklı çözümleri test etmekten, sonuçları ölçmekten ve sonuçlara göre mevcut uygulamaları değiştirmekten korkmayın. İyi sonuçlar takip edecek.