Ürünümüz daha karmaşık hale geldikçe, her şeyin birlikte nasıl çalıştığına dair tam bir resme sahip olmak giderek zorlaştı. Ve büyüme hızımızı korumak için, tüm işlevsel belirtimlerimiz için güncel bir doğruluk kaynağı sağlamanın bir yolunu bulmamız gerekiyordu. Bu makale, daha önce spesifikasyonları nasıl ele aldığımızı, bu yaklaşımla bulduğumuz sorunları ve tamamen yenisini nasıl bulduğumuzu açıklıyor.

"Özelliğe göre teknik özellikler" ile ilgili yanlış olan ne?

Spesifikasyonlara yönelik geleneksel yaklaşımımız, her yeni spesifikasyon için Ürün Yöneticilerinin yeni ve mevcut ekranlar için beklenen davranışların bir listesini derleyeceği özel bir sayfaya sahip olmaktı. Bu yaklaşım, özellikle yeni özellikler mevcut ekranların bazı kısımlarını geçersiz kıldığında, ürün daha karmaşık hale gelene kadar işe yaradı.

Sonuç olarak, bir ekranın tam olarak nasıl çalıştığını ve belirli bir öğeyi güncellerken uygulamanın başka bir yerinde olası sonuçların neler olabileceğini tam olarak anlamak zordu. Kod tabanı, gerçeğin tek güvenilir kaynağı haline geldi ve Ürün Yöneticileri, ekranların nasıl davrandığını tekrar tekrar açıklamak için Mühendislere güvenmek zorunda kaldı. Bu, Mühendislerin odaklanmasını kesintiye uğrattı ve yeniden çalışmaya, israfa, artan teslim süresine ve hayal kırıklığına yol açan hızlı, yaklaşık yanıtlar vermelerine neden oldu.

Prototipi oluşturmak

Bu sorunu çözmek için, özellikler ve tasarımlar için bir doğruluk kaynağı prototipi geliştirmemiz gerekiyordu. Her ekranın benzersiz bir gerçek kaynağı olmalıdır. Bu nedenle, bir ekranda yapılan herhangi bir güncelleme, başka herhangi bir özel sayfa yerine, o tek gerçek kaynağına yansıtılmalıdır. Tasarımlarımız Figma üzerindeydi, biz de onları orada tuttuk. Notion'da ekran görüntülerinin yanına özellikler yazmak, aslında doğrudan Figma'da özellik yazmaktan daha fazla işti. Geliştiriciler, aynı Figma dosyasındaki yüksek kaliteli tasarımları, önerilen değişikliğin hemen yanında mevcut özelliklerle birlikte hemen görebilirler.

Spesifikasyonlarımızın kapsamlı olmasını sağlamak için, önceki yaklaşımlarımızın yeni prototipimize dahil etmeyi kaçırdığı dört temel alan belirledik. İlk olarak, koşullar ne olursa olsun ekranın tüm öğeleri üzerinde görünürlüğe ihtiyacımız vardı. İkinci olarak, mühendislerden kod tabanını geriye dönük mühendislikle tasarlamalarını istemeye başvurmak zorunda kalmadan herhangi bir öğenin nasıl davrandığını bilmemiz gerekiyordu. Üçüncüsü, bir ekranda bir değişikliğin diğer ekranlarda istenmeyen güncellemeler yapmasını önlemek için bir öğenin birkaç ekranda paylaşılıp paylaşılmadığını bilmemiz gerekiyordu. Ve son olarak, bir ekrandan diğerine geçmek için tüm koşullarla birlikte ekran akışlarının net bir resmine ihtiyacımız vardı.

Prototipi iyileştirme ve ölçeklendirme

Tüm Tasarımcılarımızı işe almak için, tanıdıkları ve düzenli olarak kullandıkları bir platformda özel ihtiyaçlarına yanıt veren net bir standart bulmamız gerekiyordu. Artık Figma'da klasörlerin takıma göre değil temaya göre sıralandığı bir "Görsel Özellikler" çalışma alanımız var. Her ekran herkese aittir, sadece bir takıma değil. Belirli bir kapsamdan sorumlu bir ekip, uygulamanın başka bir bölümünü etkileyecek bir değişiklik yaparsa, doğru ekranları doğru yerde güncelleyebilir ve değişikliği herkes otomatik olarak görebilir. Bu şekilde, spesifikasyonlara yönelik mevcut yaklaşımımız öncekinden daha kapsamlıdır. Her tema klasörü, her kullanıcı hikayesi için bir sayfaya sahiptir.

Bir kullanıcı hikayesinin içeriği, kullanıcı yolculuğunun yatay ilerleyişini gösterir. Dikey olarak, her bir anahtar ekranın olası tüm varyantlarına sahibiz (hata durumu, yükleme durumu, boş durum…). Özellik kartları, her bir öğe için, öğenin olası her davranışının açıklandığı, tamamen kapsamlı kabul kriterleridir. Ana ekranlar, teknik özelliklerin çoğunu içerecek ve varyantlar yalnızca kendi spesifik özelliklerini gösterecektir.

Şimdi, ne zaman yeni bir özellik geliştirsek, Figma'da yeni bir dal oluşturuyoruz ve yeni özellik kartlarını yeni öğelerin yanına belirgin bir renkte ekliyoruz. Özellik bittiğinde, bu özellik kartları "canlı" durumlarına dönüştürülecek ve dal ana kartla birleştirilecek. Bu, her şeyi temiz, güncel ve mümkün olan en iyi koşullarda yeni bir özelliği başlatmaya hazır tutar.

Tam geçişin gerçekleştirilmesi

Bir Teknoloji ve Ürün departmanında çalışma yöntemlerini güncellemek zor olabilir. Qonto Way burada devreye girdi — sürekli iyileştirme, kültürümüzün merkezinde yer alır. Ekibin bir alt kümesiyle yeni yöntemler deniyoruz ve eğer yararlı olurlarsa tüm ekipte uyguluyoruz. Değilse, onları atarız. Spesifikasyonlar yaklaşımımızı yenilemeye geldiğimizde, ekibim düzeyinde başladık ve kullanımında doğrudan yer alan Ürün/Tasarım/Teknoloji ekip üyelerinin desteğiyle inisiyatifin tüm sahipliğini üstlendim. İdeal olarak, sonunda üzerinde çalışacağınız bir sonraki özelliği kapsayacak kadar yeterli sayıda ekran ve spesifikasyon üzerinde tersine mühendislik yapmak istersiniz (Ekibimin tüm kapsamını tersine mühendislikle yaptım, böylece önümüze çıkan her yeni özelliğe hazırız).

Bu yeni özellikle ilgili (olumlu!) deneyiminizi gösterdiğinizden emin olun ve Teknoloji ve Ürün yöneticilerinden destek almak için avantajlarını başkalarına yoğun bir şekilde tanıtmaktan çekinmeyin.

Topu yuvarladıktan sonra, geniş ölçekte çalışma şeklimizi güncellememiz gerekiyordu. Her biri farklı bir ekibe yönelik, gözden geçirilmiş bir dizi standart yazdık: Her yığın için sahiplik açıkça belirtilmiş olan Teknoloji, Ürün ve Tasarım.

Bu adıma ulaştığınızda, yeni özelliklerinizi görsel özelliklerde oluşturabilir, bilgiyi her özellikte pekiştirebilirsiniz. Ancak, bu şekilde çalışmanın tüm avantajlarından ancak her bir davranışın haritasını çıkardıktan sonra yararlanabilirsiniz. Durumunuza bağlı olarak, tam ölçekli haritalamaya başlamanın iki yolu vardır (her ekip bir yaklaşımı veya diğerini benimsemeye karar verebilir):

• Her işlevsel ekipte üretimi birkaç gün dondurun ve Teknik ekibinizden ve Tasarımcılarınızdan mevcut kapsamın tamamını retro-mühendisleştirmelerini isteyin. Bu yöntemin çeşitli faydaları vardır: ilgili ekip, yeni katılanlar da dahil olmak üzere tam alan bilgisine sahip olur ve siz de her şeyin nasıl çalıştığı konusunda %100 netlik elde edersiniz; artık kör nokta kalmaz.
• Yeni bir özellik oluşturmadan hemen önce yalnızca güncellemeyi planladığınız parçalarda retro-mühendislik yapın. Bu, hiçbir şeyi kaçırmamanızı sağlar ve bu yeni hakikat kaynağının üzerine yeni unsurları inşa etmeye başlayabilirsiniz. Bu yaklaşımın dezavantajı, hiçbir zaman tüm resmin haritasını çıkaramayacak olmanızdır.

Yeni spesifikasyon sürecimiz, çalışma şeklimizde devrim yaratarak "mağara dalışı" kod tabanına veda etti. Spesifikasyonlar ve tasarımlar için tek bir doğruluk kaynağı oluşturarak, kullanımı kolay, tüm ekip üyelerinin erişebileceği ve tüm ekranlarımızda ve kullanıcı hikayelerimizde doğru ve güncel bilgiler sağlayan bir çalışma alanı oluşturduk. Zamandan tasarruf ettik, yeniden çalışmaları azalttık, yeni katılanların katılımını hızlandırdık ve her şeyin birlikte nasıl çalıştığına dair daha kapsamlı bir resim sağladık.

Qonto , 2016 yılında Steve Anavi ve Alexandre Prot tarafından kurulan KOBİ'ler ve serbest çalışanlar için tasarlanmış bir finans çözümüdür. Temmuz 2017'deki lansmanımızdan bu yana Qonto, 350.000'den fazla şirket için işletme finansmanını kolaylaştırdı.

İşletme sahipleri, Qonto'nun aerodinamik hesap kurulumu, sınırsız işlem geçmişi, muhasebe dışa aktarımı ve pratik bir gider yönetimi özelliği ile sezgisel bir günlük kullanıcı deneyimi sayesinde zamandan tasarruf sağlar.

Gerçek zamanlı bildirimler ve bir kullanıcı hakları yönetim sistemi aracılığıyla ekiplerine daha fazla özerklik verirken kontrolü ellerinde tutuyorlar.

Akıllı panolar, işlem otomatik etiketleme ve nakit akışı izleme araçları aracılığıyla gelişmiş nakit akışı görünürlüğünden yararlanırlar.

Ayrıca adil ve şeffaf bir fiyata mükemmel müşteri desteğinden yararlanırlar.

Zorlu ve oyunun kurallarını değiştiren bir şirkete katılmak ister misiniz? İş tekliflerimize danışın !