FoodSoul sistemi üzerinde çalışma nasıl yürütülüyor: fikirden sonuca

Ortaklarımızın güvenini önemsiyoruz ve bu nedenle mümkün olduğunca şeffaf olmak istiyoruz. Bu yazıda, ekibimizin nasıl yapılandığını, fikirlerin nasıl fonksiyonlara dönüştüğünü, öncelikleri nasıl belirlediğimizi ve bir şeyler ters gittiğinde perde arkasında neler yaşandığını anlatacağız.

FoodSoul — yaşayan bir sistemdir

FoodSoul sadece bir uygulama değildir. Arkasında büyük bir altyapı vardır: CRM, veri depolama ve koruma, web sitesi ve mobil uygulama şablonları ve her biri kendi ihtiyaçları ve çalışma senaryoları olan binlerce restoran ortağı.

Sürekli dinliyoruz: Ortaklarımızdan teknik destek aracılığıyla, müşterilerle doğrudan iletişimden ve IT departmanımızın kendi analistlerinden fikirler topluyoruz. Tüm bunlar, ürünün gelişim yol haritasının oluşturulduğu, sürekli güncellenen bir görev listesi olan backlog’da birikiyor.

Ekip ve iş yapısı nasıl düzenleniyor

FoodSoul üzerinde birkaç uzman grubu çalışıyor ve her birinin kendi sorumluluk alanı ve diğerleriyle etkileşim mantığı var.

Teknik destek — ortaklarla ilk temas hattıdır. Başvuruları alır, sorunun özünü anlar ve ya yerinde çözer ya da sistemi iyi bilen uzmana iletir.

İkinci hat uzmanları — entegrasyonlar, mobil uygulamalar, CRM, ödemeler gibi belirli modüllerde derin bilgiye sahip mühendislerdir. Başvurunun fonksiyonun bir özelliği mi yoksa gerçek bir hata mı olduğunu onlar kontrol eder.

Analistler ortakların taleplerini toplar ve yapılandırır, değişikliğin ne kadar talep edildiğini ve diğer müşterileri nasıl etkileyeceğini değerlendirir, ardından görev geliştirmeye alınır.

Geliştiriciler ve test uzmanları görevleri uygular ve yayına almadan önce kontrol eder — küçük düzeltmelerden büyük fonksiyonel geliştirmelere kadar.

Proje yöneticileri önceliklere odaklanır: backlog’u takip eder, görevleri ekipler arasında dağıtır ve önemli olanın mevcut işler arasında kaybolmamasını sağlar.

Çalışma döngüseldir: Ekip düzenli olarak backlog’u gözden geçirir, yeni başvuruları ve talepleri değerlendirir, yakın vadeli görevleri planlar ve üzerinde çalışılanların durumunu takip eder. Bu ritim, acil sorunları ve ürünün uzun vadeli gelişimini gözden kaçırmamayı ve öngörülebilirliği korumayı sağlar: Ortak, başvurusunun hangi aşamada olduğunu teknik destekten her zaman öğrenebilir.

Öncelikleri nasıl belirliyoruz

Bir sorun ortaya çıktığında, aşağıdaki senaryolardan biriyle hareket ediyoruz.

Toplu arıza — birkaç müşteri aynı anda, gün veya saatler içinde aynı hatayla karşılaşıyorsa. Bu en yüksek önceliktir: test uzmanı ve geliştiriciler hemen müdahale eder.

Bir müşteride kritik hata — hata doğrudan ortağın gelirini veya itibarını etkiliyorsa, öncelik yine yüksektir. Temel kaynaklarımızı bu soruna yönlendirir ve kısa sürede çözeriz.

Standart hata — teknik destek tarafından alınan ve felaket gibi görünmeyen başvurudur. Sistemi iyi bilen ikinci hat uzmanı tarafından işleme alınır. İki olası sonuç vardır: Ya bu, fonksiyonun gözden kaçan bir özelliğidir ve müşteriye açıklama yapılır; ya da gerçekten bir sorun vardır, bu durumda proje yöneticisine iletilir, görev sistemine öncelik ve sorumlu atanarak kaydedilir ve sırayla uygulanır. Teknik destek uzmanı durumu takip eder ve görev tamamlandığında müşteriye bilgi verir.

Minör hata — sistemin çalışmasını etkilemeyen, ancak düzeltilmesi gereken hata: yazım hatası, kaymış arayüz öğesi, yanlış buton rengi. Bu tür görevler, yukarıdaki daha öncelikli başvurular olmadığında ele alınır.

Talepler — ortaklarımızın isteklerini dikkatle takip ediyoruz. Aynı talep birkaç müşteriden gelirse, önceliği artar ve analize alınır. Her değişiklik, sadece talepte bulunanı değil, tüm ortakları etkiler, bu nedenle uygulamadan önce farklı müşterilerden geri bildirim toplarız ki birine yapılan iyileştirme diğerine zorluk yaratmasın. Bu ek bir adım, ancak nihai çözümü daha dengeli kılar.

Neden hatalar oluşur

Herhangi bir karmaşık ürünün geliştirilmesinde hatalar sürecin düzenli bir parçasıdır, istisna değil. Bu karmaşıklık şunlardan oluşur:

Sistem büyüyor. Fonksiyon, entegrasyon ve kullanım senaryosu arttıkça, sistemin farklı bölümlerinin birbiriyle etkileşime geçtiği noktalar da artar. Ekip en tipik senaryoları test eder, ancak en deneyimli ekip için bile tüm kombinasyonları önceden kapsamak fiziksel olarak imkansızdır.

Her ortak sistemi kendine göre kullanır. Binlerce işletme — binlerce benzersiz iş süreci demektir. Gerçek koşullarda kullanıcı davranışı, test senaryolarında öngörülebilenden her zaman daha zengindir ve bazı sapmalar yalnızca canlı verilerde ortaya çıkar.

Bir değişiklik diğerini etkiler. Bir geliştirici bir modülü iyileştirdiğinde, bu komşu fonksiyonları etkileyebilir. Sistem büyüdükçe, bölümler arasındaki bağımlılık zincirleri uzar ve her değişikliği daha dikkatli kontrol etmek gerekir.

Çevre sürekli değişiyor. Tarayıcılar, işletim sistemleri, entegre olduğumuz üçüncü taraf servisler güncelleniyor. Dün çalışan bir şey, başka bir şirketin güncellemesinden sonra farklı davranabilir ve biz bu tür değişiklikleri hızlıca yanıtlamak için takip ediyoruz.

Gereksinimler süreçte netleşiyor. Bazen bir fonksiyon tam da planlandığı gibi uygulanır, ancak gerçek kullanımda fikrin geliştirilmesi gerektiği ortaya çıkar. Böylece ürün her iterasyonda daha hassas hale gelir.

Bunu, karmaşık bir sistemin büyümesinin normal bir parçası olarak görüyoruz ve onu her ortağa daha istikrarlı, hızlı ve kullanışlı hale getirmek için sürekli çalışıyoruz — daha derin testler, net ekip yapısı ve müşterilerle sürekli geri bildirim sayesinde.

Bir sorunla karşılaştıysanız veya bir fikir paylaşmak istiyorsanız, lütfen teknik destek ekibimize yazın FoodSoul. Her başvuru ilgili uzmana ulaşır ve kaybolmaz. Yanınızdayız!

Saygılarımızla,

FoodSoul Proje Yöneticisi