Kiosk
Koçtaş Yapı Marketleri Tic. A.Ş.
Kiosk
Proje İçeriği
Koçtaş Mağaza Kiosk Uygulaması (Flutter) — mağaza içi self-servis terminallerde çalışan, müşterinin satış danışmanına ihtiyaç duymadan uçtan uca alışveriş yapabildiği dokunmatik uygulama.
Ne yapıyor:
- Ürün keşfi: Kategori ağacı, marka sayfaları, kampanya/landing sayfaları, Algolia tabanlı arama, ürün detay (varyant, stok, mağaza stoğu, montaj hizmeti seçimi)
- Sepet ve sipariş: Anonim sepet → üye girişinde sepet birleştirme, teslimat/fatura adresi, sipariş takibi ve sipariş detayı
- Ödeme (2 farklı akış): Nakit (kasada ödeme) ve mobil ödeme,
- Üyelik ve sadakat: OTP ile giriş/kayıt, Koçtaş Kart, sadakat kartları, kullanıcı profili
- Satış sonrası: İade talebi (basit + gelişmiş iade akışı), ürün talep/sipariş takibi (demands), destek talebi (ticket), SSS
- İçerik ve sosyal kanıt: Bazaarvoice ürün yorumları ve soru-cevap, ürün değerlendirme gönderimi, stok gelince haber ver
- Retail media: Gowit sponsorlu banner'ları (anasayfa, ürün listesi, sponsorlu marka vitrini) ve ekran koruyucu reklam döngüsü — kiosk boştayken reklam envanteri olarak çalışıyor
- Kişiselleştirme: Segmentify öneri motoru (ürün görüntüleme, checkout önerileri)
- Mağaza farkındalığı: Kiosk ID'sinden mağaza tipini (Koçtaş Fix / BigBox) tanıyıp özellikleri buna göre açıp kapatıyor; "Artı Deneyim" anket uygulamasını harici süreç olarak başlatabiliyor
Teknik profil (repodan ölçülen):
| Metrik | Değer |
|---|---|
| Dart dosyası (üretilen kod hariç) | 524 |
| Toplam kod satırı | ~127.000 |
| Feature modülü | 33 |
| Ekran (page) / BLoC dosyası | 42 / 46 |
| OCC endpoint tanımı | 194 |
| Test dosyası / test senaryosu | 94 / ~580 |
| Uçtan uca entegrasyon senaryosu | 8 |
Projenin Amacı
İkisi birden — ama ağırlık "var olan hizmetin yeniden inşası + operasyonel süreç iyileştirmesi" tarafında.
a) Var olan hizmetin modernizasyonu (asıl motivasyon):
Bu proje sıfırdan bir fikir değil; sahada çalışan C# WPF kiosk uygulamasının (Koctas.Kiosk.App) yerine geçmek üzere yazıldı. Legacy uygulama 810 C# dosyası / ~66.700 satır / 221 XAML ekranı. Windows'a ve WPF'e çivilenmiş, tek platformlu, test edilebilirliği düşük bir kod tabanıydı. Flutter'a taşıma ile:
- Tek kod tabanından Windows + macOS çalışabilir hale geldi (geliştirme ve demo artık Windows makinesi gerektirmiyor)
- Katmanlı mimari ve otomatik test kapısı geldi — legacy tarafta karşılığı yoktu
- Yeni ekran/akış ekleme maliyeti belirgin şekilde düştü (bkz. 4. soru)
b) Kurum içi süreç iyileştirmesi (en somut kazanç):
Asıl iyileştirme saha operasyonunda. Önceki dünyada bir kiosk sürümünü sahaya almak, MSIX/AppInstaller kısıtları ve mağaza başına manuel müdahale demekti. Şimdi:
- Pipeline sürümü otomatik hesaplıyor (Azure variable group'tan major/minor/patch), pubspec ile senkronluyor, ZIP üretiyor
- Paket monitoring dashboard'una yükleniyor, hedef cihazlara komut kuyruğuna düşüyor
- Cihazdaki SDK komutu alıyor, indiriyor, uygulamayı durduruyor, C:\Koctas üzerine açıyor, koctas.exe'yi tekrar başlatıyor — mağazada kimsenin bir şey yapmasına gerek yok
- Geri alma da aynı mekanizma: eski sürümün ZIP'i kuyruğa alınır, cihaz kendi kendini eski sürüme döndürür
Proje içindeki en büyük inovasyon nedir? (yeni bir teknoloji veya var olan teknolojinin farklı kullanımı gibi. IOT, M2M, AI vb.)
Kiosk'a özgü etkileşim çerçevesi. Terminallerde fiziksel klavye yok ve kullanıcı işini yarıda bırakıp gidiyor. Uygulama kabuğu bunu sistematik olarak çözüyor: tüm metin girişi KioskTextField + ekran klavyesi üzerinden; 60 sn hareketsizlikte ekran koruyucu (reklam döngüsü) devreye giriyor; 30 sn boşta + 20 sn geri sayım sonunda oturum kapanıp sepet temizleniyor ve karşılama ekranına dönülüyor — ama ödeme ekranlarında bu iki mekanizma da otomatik olarak askıya alınıyor. Böylece "müşteri gitti, sepeti bir sonrakine kaldı" ve "3D Secure ortasında ekran koruyucu açıldı" sınıfı hataların ikisi birden mimari düzeyde engelleniyor.
Çift token modeli ve sepet birleştirme. Tek bir terminalde anonim ve üye oturumlar iç içe geçiyor. API istemcisi anonim ve üye token'ını eş zamanlı tutuyor, yolu (/users/anonymous/) inceleyerek doğru olanı seçiyor; anonim token'ı stampede koruması ile yeniliyor. Üye girişinde anonim sepet GUID'i yakalanıp mergeCart ile üye sepetine katılıyor — müşteri gezerken doldurduğu sepeti giriş yapınca kaybetmiyor.
Yapay zekâ destekli geliştirme altyapısı. 131 bin satırlık bir kod tabanında AI asistanların verimli çalışabilmesi için depo içine yedi adet özel "skill" yazıldı (kiosk-nav kod bulma protokolü, kiosk-api OCC entegrasyonu, kiosk-feature yeni modül iskeleti, kiosk-ui tema token'ları, kiosk-verify doğrulama kapısı, dart-lsp, task-observer). Feature indeksi otomatik tazeleniyor, dosya haritası çıkaran scriptler var. Kritik olan: bu kurallar üç farklı AI aracından da (Claude, GitHub Copilot, Antigravity) aynı kaynak dosyaya işaret eden stub'larla okunuyor — kural tek yerde yaşıyor, sürüm kayması olmuyor. Ekibin hangi aracı kullandığından bağımsız olarak aynı mimari standarda uyulması sağlanıyor.
Proje kurum içindeki hangi bölüme fayda sağlamıştır?(satış, pazarlama, finans, İK, IT, Üretim, Planlama, Satın alma, Lojistik Müşteri İlişkileri gibi)
Arge ve Mağazalara
Projenin hayata geçirilmesi konusunda üst yönetimin desteğini tam olarak alabildiniz mi?
Evet
Proje sonunda ortaya çıkan sonuçları analiz edebildiniz mi? Rakamsal verilerle ifade eder misiniz?(ROI, maliyetlerde yüzdesel azalma, üretim süresinde azalma, hata payının düşmesi vs.)
Evet — ölçüm altyapısı bilinçli olarak projenin parçası olarak kuruldu. Sonuçları üç başlıkta ayırmak gerekiyor:
a) Ölçüm altyapısı (kurulu ve çalışıyor)
| Katman | Araç | Ne ölçülüyor |
|---|---|---|
| Kullanıcı davranışı | GA4 (Measurement Protocol) | Ekran görüntülenme, sepet, ödeme hunisi olayları |
| Hata / kararlılık | Sentry (debug sembolleri ile) | Crash, release health, sürüm bazlı hata oranı |
| Cihaz sağlığı | Monitor SDK + Device Telemetry Reporter | Filo durumu, sürüm dağılımı, donanım metrikleri |
| Ticari | Segmentify / Gowit | Öneri etkileşimi, sponsorlu içerik gösterim ve tıklama |
Bu, "proje bitti, sonuç bakalım" değil; sonucun sürekli ölçüldüğü bir işletim modeli.
b) Ölçülmüş ve doğrulanmış mühendislik sonuçları (repodan doğrulanabilir)
- Kod hacmi: Legacy C# WPF (810 dosya / ~66.700 satır / 221 XAML ekranı) → Flutter (524 dosya / 33 modüler feature). Aynı işlevsellik + üzerine yeni yetenekler, tek kod tabanında ve çok daha yüksek modülerlikle.
- Test kapsamı — projenin en net iyileşmesi: Şubat 2026 tarihli iç analiz raporunda (docs/PROJECT_ANALYSIS.md) test dosyası sayısı 1 (yalnızca varsayılan smoke test). Bugün 94 test dosyası, ~580 test senaryosu ve 8 uçtan uca kiosk yolculuğu var (nakit ödeme, kredi kartı, anonim oturum, üye oturum, sadakat kartı, hareketsizlik, iade talebi). Beş ayda sıfır test kültüründen, regresyonu otomatik yakalayan bir kapıya geçildi.
- Dağıtım süresi: Manuel/mağaza başına müdahale gerektiren MSIX akışından, dashboard'dan komut kuyruğuna eklenip cihazın kendini güncellediği akışa geçildi. Rollback aynı mekanizmadan, ek geliştirme olmadan çalışıyor.
- Mimari uyum: CI'da her koşuda otomatik denetleniyor; kural ihlali dokümantasyon değil, ölçülen bir metrik.
- Gözlemlenebilirlik: Öncesinde saha hatası ancak mağazadan gelen bildirimle öğreniliyordu; şimdi Sentry'ye crash, telemetriye cihaz durumu düşüyor.
Projenizde şirket içinden kaç kişi aktif olarak görev almıştır? Ekip birimleri hakkında kısaca bilgi verir misiniz?
3
Projenizde (varsa)işbirliği kurduğunuz veya destek aldığınız bilişim şirketlerini belirtiniz.
Herhangi bir iş birliği kurulmadı
Proje sırasında kullandığınız ve spesifik önemi olan markaları (varsa) belirtiniz. (Yazılım veya donanım markaları)
Yok
