Saha operasyonu
Teknik ekipHareket halinde, telefonla çalışır. Sıradaki iş, adres ve bağlantı kesildiğinde ne olacağı önemlidir.
YöneticiMasaüstünde ekip yükünü, gecikmeleri ve sorumlulukları birlikte görmek ister.
SOFT MARKETING / ÜRÜN GELİŞTİRME YAKLAŞIMIMIZDoğru teknoloji,
Doğru teknoloji,
doğru problemle başlar.
Ürün geliştirme yaklaşımımız doğru sorularla başlar. Bir projeye kod yazarak başlamıyoruz. Önce problemi, kullanıcıyı ve iş hedefini anlamaya çalışıyoruz. Teknoloji seçimini bundan sonra yapıyoruz.
- 01 / GİRDİProblem
Hangi işi kolaylaştırıyoruz?
- 02 / BAĞLAMKullanıcı + veri
Kim, nerede, nasıl kullanacak?
- 03 / YÖNİş hedefi
Hangi değişimi arıyoruz?
- 04 / KARARÜrün mantığı
Nasıl bir deneyim kuruyoruz?
- 05 / ARAÇTeknoloji
Bu kararı neyle hayata geçiriyoruz?
İstenen çözüm ile gerçek ihtiyaç
her zaman aynı şey değildir.
“Mobil uygulama istiyorum.”
Bu talebin arkasında saha operasyonu, self-service kullanım, satış ekibinin iş yükü, rezervasyon veya dağınık veri olabilir. Bu nedenle ilk sorumuz “Flutter mı, React Native mi?” olmaz.
Bu ürün neyi çözüyor?Ürün geliştirme yaklaşımımız, araç seçmeden önce problem, kullanıcı, iş modeli ve hedef arasındaki ilişkiyi kurar. Ancak bundan sonra mobil uygulama, web platformu veya başka bir çözüm anlam kazanır.
TEKNOLOJİ BİR BAŞLANGIÇ NOKTASI DEĞİL.
Doğru tanımlanan ihtiyacın sonucudur.
02 / PROBLEMİ ANLAÖnce problemi
Önce problemi
doğru tanımlarız.
Mevcut süreci ve sistemleri birlikte inceleriz. Ayrıca bütçe, zaman, teknik kısıtlar ve ölçek beklentisini aynı kararın içine alırız. Böylece çözümün operasyon içinde gerçekten çalışıp çalışamayacağını görebiliriz.
ÖRNEK DURUM / BİR KONAKLAMA İŞLETMESİ
- Mevcut durum
Misafir talepleri farklı mesajlaşma kanallarına geliyor.
- Problem
Talebin sahibi ve güncel durumu net görünmüyor.
- Etkilenen kullanıcı
Misafir, resepsiyon ve ilgili hizmet ekibi.
- İş etkisi
Ekipler aynı bilgiyi tekrar soruyor; takip zorlaşıyor.
- Beklenen sonuç
Tek talep kaydı, açık sorumluluk ve izlenebilir durum.
KARARIN SINIRLARI
Mevcut otel sistemi · Cihazlar · Ağ koşulları · Kullanıcı rolleri · Bütçe · Yayın hedefi
Yanlış tanımlanan probleme doğru teknoloji uygulamak, yine yanlış ürünü üretir.
03 / KULLANICIYI ANLAÜrünü kullanan insanı
Ürünü kullanan insanı
tasarımın merkezine koyarız.
Bir rolün ihtiyacı yalnızca yetkilerden oluşmaz. Kullanım ortamı, cihaz, zaman, teknik bilgi ve karar anı da deneyimi değiştirir. Bu nedenle aynı veriyi herkese aynı yoğunlukta göstermeyiz.
Konaklama
MisafirTalebini kolayca iletmek ve sonucunu anlamak ister.
Otel çalışanıÖnceliği, atanan işi ve tamamlanma durumunu takip eder.
CRM
Satış temsilcisiSıradaki görüşmeyi ve müşteri geçmişini hızlıca bulmalı.
Satış yöneticisiPipeline, tahmin ve ekip performansını topluca değerlendirmeli.
ERP
Depo personeliÜrün, miktar ve hareketi işlem anında doğrular.
Genel müdürOperasyonun bütününü ve karar gerektiren istisnaları izler.
Gerçek ürünlerden: Memorial’ın mobil sağlık deneyimi, kullanıcıya ihtiyaç duyduğu hizmeti anlaşılır bir akışla sunmanın önemini gösterir.
04 / ÜRÜN STRATEJİSİÖzellik listesi değil,
Özellik listesi değil,
ürün mantığı kurarız.
Bir öneriyi kullanıcı ve iş değeriyle değerlendiririz. Ardından geliştirme maliyetini, operasyonel etkisini, teknik riskini ve bakım yükünü konuşuruz. Her fikri aynı sürüme almamak da ürün geliştirme yaklaşımımızın bir parçasıdır.
ÖRNEK ÖNCELİKLENDİRME / TALEP YÖNETİMİ
01
Must Have
İlk sürümün omurgasıTalep oluşturma, sorumlu ekibe yönlendirme ve durum takibi. Önce temel işin uçtan uca tamamlanmasını sağlarız.
02
Should Have
Bir sonraki faydaTekrarlanan talepleri kolaylaştıran şablonlar. Ancak önceliği, kullanım ihtiyacı ve elde kalan kapasite belirler.
03
Later
Veriyle yeniden değerlendirGelişmiş tahminler ve kişiselleştirme. Önce bu kararları besleyecek yeterli kullanım verisi oluşmalı.
İlk sürüm, doğru problemi en temiz çözen sürüm olmalı.
05 / TEKNOLOJİ SEÇİMİTeknolojiye değil,
Teknolojiye değil,
probleme sadığız.
Ürün tipi, kullanıcı kitlesi ve performans ihtiyacı ilk çerçeveyi kurar. Ayrıca platformu, ekibi, bütçeyi, entegrasyonları ve uzun vadeli bakımı birlikte değerlendiririz. En yeni teknoloji her zaman en doğru teknoloji değildir.
KARAR MATRİSİHer karar bağlama göre değişir.
KARAR NOTU
Aynı ürün hedefi, farklı mobil kararlar.
Native iOS ihtiyacı belirginse Swift / SwiftUI; Android tarafında Kotlin / Jetpack Compose değerlendiririz. Ortak iOS ve Android deneyimi için Flutter veya React Native seçeneklerini ürünün cihaz ihtiyaçlarıyla birlikte inceleriz.
| Kriter | Neye bakarız? | Karara etkisi |
|---|---|---|
| Performans | Yoğun cihaz kullanımı veya kritik akış | Önce kritik ekranı ve cihaz özelliğini küçük bir teknik denemeyle doğrularız. |
| Geliştirme süresi | İki platformda benzer deneyim | Ortak kod geliştirmeyi kolaylaştırabilir; platforma özgü işi ayrıca planlarız. |
| Bütçe | İlk yatırım ve devam eden geliştirme | Bütçeyi yalnız ilk sürümle sınırlamayız; iki platformun bakımını birlikte hesaplarız. |
| Platform ve cihaz | Native özelliklere erişim | Mevcut destek, native köprü ihtiyacı ve platform kısıtları kararı etkiler. |
| Ölçek | Kullanıcı ve ekip büyümesi | Mobil mimariyi API, veri ve sürüm yönetimiyle birlikte düşünürüz. |
| Bakım | Mevcut ekibin yetkinliği | Swift, Kotlin, Dart veya React deneyiminin bakım üzerindeki etkisini değerlendiririz. |
| Entegrasyon | Ödeme, bildirim, kamera, konum | Üçüncü taraf SDK ve cihaz desteğini seçimden önce inceleriz. |
| Uzun vadeli esneklik | Platformlara göre farklılaşma | Deneyimler ayrışacaksa ortak kodun sınırlarını baştan tanımlarız. |
KARAR NOTU
Kurumsal içerik ile SaaS aynı ürün değildir.
İçerik ağırlıklı bir web sitesinde bulunabilirlik, içerik yönetimi ve açılış deneyimi öne çıkar. Gerçek zamanlı bir SaaS panelinde ise durum yönetimi, yetki, veri akışları ve yoğun etkileşim farklı kararlar gerektirir.
| Kriter | Neye bakarız? | Karara etkisi |
|---|---|---|
| Performans | İlk açılış ve etkileşim süresi | İçerik sunumunu ve tarayıcıda çalışacak işi ayrı değerlendiririz. |
| Geliştirme süresi | İçerik sitesi veya yoğun uygulama | İçerik yönetimi ile özel ürün arayüzünün gerektirdiği geliştirmeyi ayırırız. |
| Bütçe | Editör ve operasyon maliyeti | İçerik ekibinin günlük işini de toplam maliyete dahil ederiz. |
| Platform ve cihaz | Tarayıcı ve responsive deneyim | Hedef cihazlara göre gezinme, veri yoğunluğu ve giriş biçimleri değişir. |
| Ölçek | Trafik ve eşzamanlı işlemler | İçerik trafiğiyle kullanıcıya özel veri yükü için farklı çözümler değerlendirebiliriz. |
| Bakım | İçerik ve bileşen sahipliği | Editörün güncellediği alanlarla geliştiricinin yönettiği yapıyı netleştiririz. |
| Entegrasyon | Kimlik, CMS ve ürün API’leri | Verinin kaynağını, erişim kurallarını ve güncellenme sıklığını tanımlarız. |
| Uzun vadeli esneklik | Yeni ekranlar ve kanallar | Arayüz sistemini, içerik modelini ve API sınırlarını büyümeye uygun kurarız. |
KARAR NOTU
Mimari, gerçek yükün etrafında kurulur.
Basit bir API ile yüksek trafik alan gerçek zamanlı sistem aynı mimariyi gerektirmez. Önce veri akışını, tutarlılık ihtiyacını ve operasyon yükünü anlarız; ardından modülerlik, kuyruk veya servis ayrımı gibi kararları gerekçelendiririz.
| Kriter | Neye bakarız? | Karara etkisi |
|---|---|---|
| Performans | Yanıt süresi ve iş yükü | Ölçülen darboğaza göre sorgu, önbellek veya arka plan işi değerlendiririz. |
| Geliştirme süresi | İlk kapsamın sınırları | Gereksiz dağıtık yapı kurmadan, sorumlulukları anlaşılır modüllere ayırırız. |
| Bütçe | Geliştirme ve işletim maliyeti | Sunucu, veri, gözlemleme ve operasyon emeğini birlikte hesaba katarız. |
| Platform ve cihaz | Mobil, web ve dış istemciler | API sözleşmesini ve sürüm stratejisini istemci ihtiyaçlarıyla eşleştiririz. |
| Ölçek | Trafik ve veri büyümesi | Beklenen yükü test eder; ölçek kararını ölçüm ve kapasiteyle destekleriz. |
| Bakım | Arıza anında anlaşılabilirlik | Loglama, monitoring ve dokümantasyonu mimarinin parçası sayarız. |
| Entegrasyon | Dış sistemlerin sınırları | Zaman aşımı, tekrar deneme ve yinelenen kayıt riskini baştan ele alırız. |
| Uzun vadeli esneklik | Değişecek iş kuralları | Her değişiklik bütün sistemi etkilemesin diye veri ve iş sınırlarını açık tutarız. |
KARAR NOTU
Sıfırdan başlamak her zaman avantaj değildir.
Standart müşteri ve satış süreçlerinde hazır CRM güçlü bir başlangıç olabilir. Benzersiz iş kuralları varsa uyarlama veya özel yazılımı değerlendiririz. Ürün geliştirme yaklaşımımız, mevcut çözümle gerçek ihtiyaç arasındaki mesafeyi görünür kılar.
| Kriter | Neye bakarız? | Karara etkisi |
|---|---|---|
| Performans | Kritik operasyon yükü | Hazır ürünün sınırlarını örnek veri ve gerçek akışla kontrol ederiz. |
| Geliştirme süresi | İlk kullanım için gereken iş | Kurulum, veri aktarımı ve uyarlamayı özel geliştirme kapsamıyla karşılaştırırız. |
| Bütçe | Lisans veya geliştirme yatırımı | Aylık lisans, kurulum, entegrasyon ve bakım kalemlerini ayrı konuşuruz. |
| Platform ve cihaz | Çalışma şekli ve cihazlar | Mevcut ürünün kullanım biçiminize uyumunu doğrularız. |
| Ölçek | Kullanıcı, şube ve veri büyümesi | Büyümenin lisans, mimari ve operasyon üzerindeki etkisine bakarız. |
| Bakım | Standart sürüm ve özelleştirme | Özel değişikliklerin sonraki ürün güncellemelerine etkisini değerlendiririz. |
| Entegrasyon | ERP, muhasebe ve diğer sistemler | Mevcut API, veri sahipliği ve bağlantı kapsamını inceleriz. |
| Uzun vadeli esneklik | İşe özgü kararlar | Uyarlama sürdürülemez hale geliyorsa özel yazılım seçeneğini açıkça konuşuruz. |
Bu matris bir otomatik teknoloji önerisi değildir. Önce gereksinimleri doğrular, ardından seçimi ve vazgeçtiğimiz alternatifleri birlikte kayıt altına alırız.
06 / DENEYİMİ TASARLAArayüz çizmeden önce
Arayüz çizmeden önce
akışı tasarlarız.
Kullanıcı akışı (user flow) ve bilgi mimarisi, ekranların hangi sırayla anlam kazanacağını belirler. Önce wireframe ve içerik hiyerarşisini kurarız. Ardından etkileşimleri, responsive davranışı ve prototipi birlikte değerlendiririz.
- BulHangi hizmete ihtiyacım var?
Konum ve seçenekler anlaşılır olmalı.
- DoğrulaDoğru bilgiyi verdim mi?
İşlem öncesinde özet ve düzeltme yolu görünmeli.
- Gönderİşlem tamamlandı mı?
Başarı ve hata durumu açıkça ayrılmalı.
- Takip etSonra ne olacak?
Güncel durum ve bir sonraki adım bilinmeli.
Bu bakış, Pawbnb’nin keşif ve rezervasyon dünyası gibi birbirini takip eden ürün adımlarında da önem taşır.
TASARIM SİSTEMİTek ekran değil,
Tek ekran değil,
sistem tasarlarız.
Tipografi ölçeği ve boşluklardan buton, input ve formlara kadar ortak kurallar oluştururuz. Ayrıca kart, tablo, durum, modal, drawer ve gezinme davranışlarını ürünün ihtiyaçlarına göre tanımlarız.
Responsive kuralları, ürün geliştirme yaklaşımımızın bir parçası olarak tasarım sırasında belirleriz. Özellikle SaaS, CRM ve ERP’de tutarlı deneyim, ekran sayısı arttıkça daha da önem kazanır.
Bilgi hiyerarşisiÖnce önemli olan.
Başlık, açıklama ve yardımcı bilgi aynı düzeni izler.
Durum dili
BekliyorİşlemdeTamamlandı
Renk tek başına anlam taşımaz; durumun adı da görünür.
Davranış
Form hatası, klavye odağı ve işlem sonucu benzer akışlarda aynı şekilde çalışır.
Tutarlı ürün deneyimi, onlarca ekranın tek tek güzel görünmesinden daha değerlidir.
07 / MÜHENDİSLİKBugünü çözerken
Bugünü çözerken
yarını bozmamaya çalışırız.
Sürdürülebilir kod, okunabilir sorumluluklar ve anlaşılır veri ilişkileri üzerine çalışırız. Modüler mimariyi ürünün büyüklüğüne göre kurarız. Böylece sonraki değişikliklerin maliyetini daha baştan düşünürüz.
Veri modeli + API
İş kurallarını, veri sahipliğini ve API sözleşmesini açık tanımlarız. Ayrıca entegrasyon sınırlarını ve sürüm değişikliklerini birlikte ele alırız.
Güvenlik + performans + test
Riskli akışları geliştirme sırasında doğrularız. Hata durumunu ve tekrar denemeyi, başarılı işlem kadar ciddiye alırız.
Log + monitoring + deployment
Çalışan sistemi anlayabilmek için uygun kayıt ve izleme yapısı kurarız. Ardından işletim bilgisini kapsamına göre dokümante ederiz.
Hızlı geliştirmek ile
acele geliştirmek aynı şey değildir.
İLK SÜRÜM
MVP, eksik ürün demek değildir.
MVP; en kritik problemi çözen, kullanılabilir ve test edilebilir bir üründür. Ayrıca ölçüm üretir; bir sonraki karar için kanıt sağlar.
İlk sürümdeki ürün geliştirme yaklaşımımız, doğru şeyi yaptığımızı doğrulamaya odaklanır. Güvenlik veya temel kullanılabilirlik bu nedenle ertelenebilir ayrıntılar değildir.
08 / ENTEGRASYONÜrünler
Ürünler
tek başına yaşamaz.
ERP, CRM, ödeme, kargo, muhasebe, e-posta, SMS ve WhatsApp gibi bağlantıları mimarinin içinde değerlendiririz. Önce hangi sistemin hangi veriye sahip olduğunu netleştiririz. Ardından API erişimini, sağlayıcı koşullarını ve hata davranışını planlarız.
ÜRÜNİşlem isteği
Kullanıcı ve yetki bağlamı
ENTEGRASYON SINIRIKontrollü veri akışı
Doğrulama · Kayıt · Hata yönetimi
DIŞ SİSTEMSonuç ve durum
Sağlayıcının gerçek yanıtı
E-Taşıt; mobil uygulama, araç teşhisi ve operasyon panellerinin bir arada çalıştığı gerçek ürün dünyamızdan bir örnek.
09 / GÜVENLİKGüvenlik sona bırakılan
Güvenlik sona bırakılan
bir kontrol listesi değildir.
Ürün geliştirme yaklaşımımız, güvenlik kararlarını ilk veri ve rol tasarımına taşır. Kimlik doğrulama (authentication) ile yetkilendirmeyi (authorization) ayrı sorular olarak ele alırız. Böylece sisteme girişle bir veriye erişimi aynı karar sanmayız.
Kim, hangi veriye, neden erişiyor?
Rol yönetimi, API güvenliği ve veri erişim sınırlarını gerçek görevlerle eşleştiririz.
Hangi bilgi nerede tutuluyor?
Secrets yönetimi, erişim kayıtları ve bağımlılık güncellemelerini kontrol altında tutmayı hedefleriz.
Bir sorun olduğunda nasıl geri döneriz?
Güvenli yayın, yedekleme ve geri dönüş adımlarını ürünün riskine göre planlarız.
10 / PERFORMANS VE KALİTEPerformans, kullanıcı
Performans, kullanıcı
deneyiminin bir parçasıdır.
Açılış süresi, yanıt süresi, ağ koşulları, veritabanı ve frontend rendering aynı deneyimi etkiler. Ayrıca görsel ve diğer asset optimizasyonlarını, mobil cihaz kapasitesini ve gerçek kullanım koşullarını birlikte değerlendiririz.
Bir özellik çalışıyor olabilir.
Ama yavaşsa kullanıcı için çalışmıyor olabilir.
Yayın butonuna basmadan önce.
Her proje aynı test setine ihtiyaç duymaz. Kritik akışlarla eşleşen kontroller, ürün geliştirme yaklaşımımızın temelidir.
- Temel iş tamamlanıyor mu?
- Fonksiyonel testler, API testleri ve uçtan uca kullanıcı akışları.
- Hedef ortamda kullanılabiliyor mu?
- Cihaz, tarayıcı, responsive davranış ve farklı ekran kontrolleri.
- Beklenmeyen durumda ne oluyor?
- Edge case, hata senaryoları, bağlantı kesilmesi ve yinelenen işlem kontrolü.
- Yük altında deneyim korunuyor mu?
- Kapsama uygun performans, sorgu ve ağ kontrolleri.
11 / YAYINA ALMAProduction da
Production da
ürünün bir parçasıdır.
Yayın ortamını geliştirmeden kopuk düşünmeyiz. Environment ayrımı, domain, SSL, CDN, monitoring, analytics ve hata takibi gibi başlıkları ürünün ihtiyacına göre planlarız. Ardından geçişi ve geri dönüş yolunu netleştiririz.
Mağazaya ve gerçek cihaza.
App Store / Google Play hesapları, test sürümleri, mağaza bilgileri ve inceleme gereksinimleri yayın hazırlığının parçasıdır. Ayrıca mağaza onayını dış bir süreç olarak planlarız.
Mobil ürün geliştirmeÇalışan bir production ortamına.
Deployment, ortam değişkenleri, veri geçişi, izleme ve hata takibini birlikte ele alırız. Önce kritik akışların gerçek ortamda çalıştığını doğrularız.
Ekibin günlük kullanımına.
Roller, veri aktarımı, yapılandırma ve onboarding ihtiyacı ürüne göre değişir. Bu nedenle yayını yalnız sistemin açılmasıyla tamamlanmış saymayız.
12 / ÖLÇ VE İYİLEŞTİRYayın,
Yayın,
bitiş çizgisi değildir.
Kullanıcı davranışı, analytics, hata kayıtları, performans, müşteri geri bildirimi ve operasyon verisinden öğreniriz. Ancak her metriği başarı saymayız; ürünün çözmek istediği problemle ilişkisini ararız.
YayınVeriÖğrenmeİyileştirmeYeni sürüm
Örneğin talep yönetiminde yalnız açılan kayıt sayısını izlemek yeterli olmayabilir. Talebin doğru ekibe ulaşması ve kullanıcının sonucu anlaması da önemlidir.
Dönüşüm (conversion) ve operasyon ölçümü, ürün geliştirme yaklaşımımızda bir sonraki kararı besler. Böylece yalnız özellik eklemek yerine deneyimin nerede iyileşmesi gerektiğini konuşuruz.
13 / ÜRÜN GELİŞTİRME DÖNGÜSÜHer adım, sonraki karara
Her adım, sonraki karara
bir dayanak bırakır.
Ürün geliştirme yaklaşımımızın ortak döngüsü budur. Bir sonraki adıma geçerken önceki kararları kaybetmeyiz; yeni bilgi geldikçe onları yeniden değerlendiririz.
AnlaKararlar birbirine eklenir.
- Problem tanımı
- Öncelikli kapsam
- Kullanıcı akışı
- Çalışan sistem
- Doğrulama notları
- Yayın planı
- Kullanım verisi
- Yeni sürüm kararı
- 01
Anla
İşin mevcut halini, kullanıcıyı ve asıl problemi birlikte tarif ederiz.
Çıktı / Problem tanımı - 02
Planla
Önceliği, başarı ölçütünü ve ilk sürümün sınırını belirleriz.
Çıktı / Öncelikli kapsam - 03
Tasarla
Akışı, içerik hiyerarşisini ve arayüz davranışını görünür kılarız.
Çıktı / Kullanıcı akışı - 04
Geliştir
Teknoloji kararını çalışan, sürdürülebilir bir sisteme dönüştürürüz.
Çıktı / Çalışan sistem - 05
Test et
Kritik akışları, hata ihtimallerini ve hedef ortamları doğrularız.
Çıktı / Doğrulama notları - 06
Yayınla
Geçişi, erişimleri ve işletim sorumluluğunu birlikte planlarız.
Çıktı / Yayın planı - 07
Ölç
Gerçek kullanımın hedeflenen sonucu üretip üretmediğini inceleriz.
Çıktı / Kullanım verisi - 08
İyileştir
Öğrendiğimizi önceliğe çevirir, ardından yeni sürümü planlarız.
Çıktı / Yeni sürüm kararı
14 / BAĞLAMA GÖRE ÇALIŞMAKTek metodoloji.
Tek metodoloji.
Farklı uygulama.
Aynı soruları her projede aynı ağırlıkla sormayız. Ürün geliştirme yaklaşımımız sabit bir teslim şablonu değildir. Önce ürünün riskini ve olgunluğunu anlar, ardından sürecin yoğunluğunu buna göre kurarız.
- MVP
- Hızlı doğrulama, kritik işlevler ve kısa iterasyonlar. Önce temel varsayımı test ederiz.
- Kurumsal sistem
- Süreç analizi, entegrasyonlar, yetkilendirme ve migrasyon. Mevcut operasyonun sürekliliğini gözetiriz.
- Mobil ürün
- Platform kararı, cihaz deneyimi ve mağaza süreçleri. Kullanım bağlamını gerçek cihazla değerlendiririz.
- SaaS
- Tenant yapısı, billing, yetkiler ve ölçeklenebilirlik. Farklı müşterilerin sınırlarını ve ürünün işletimini birlikte ele alırız.
- Siber güvenlik
- Kapsam, risk, kontrol, test ve izleme. Güvenlik çalışmasını sistemin gerçek sınırlarına göre planlarız.
HAZIR ÜRÜN MÜ, ÖZEL YAZILIM MI?Her problemi sıfırdan kodlamak
Özel geliştirme yetkinliğimiz
Her problemi sıfırdan kodlamak
iyi mühendislik değildir.
Önce mevcut ürünün işi ne kadar karşıladığını değerlendiririz. Ardından uyarlama sınırını, entegrasyonu ve toplam sahip olma maliyetini konuşuruz. Hazır ürün ile özel geliştirme arasında bilinçli bir tercih yaparız.
15 / MÜŞTERİYLE ÇALIŞMA BİÇİMİKapalı kapılar ardında
Kapalı kapılar ardında
ürün geliştirmeyiz.
Projenin durumunu düzenli iletişim, demo, milestone ve karar kayıtlarıyla görünür tutarız. Ayrıca geri bildirimin hangi kararı değiştirdiğini açıklarız. Görüşme sıklığını ve kontrol noktalarını projenin çalışma biçimine göre birlikte belirleriz.
ORTAK GÖRÜNÜRLÜK
Ne üzerinde çalışıyoruz? Hangi karar gerekiyor? Sırada ne var?
Her yeni fikir aynı sürüme girmek zorunda değil.
Önce fikrin kullanıcı değerini ve mevcut hedefle ilişkisini konuşuruz. Ardından kapsam, süre ve maliyet etkisini görünür kılarız. Böylece yeni bir talep, sessizce teslim beklentisini değiştirmez.
- Mevcut kapsamÜzerinde uzlaştığımız sürümün hedefi.
- Sonraki sürümDeğeri net, zamanı birlikte planlanacak geliştirme.
- BacklogKanıt, öncelik veya daha açık tanım bekleyen fikir.
Kısa yolun maliyetini biliriz.
Bazen hızlı bir çözüm bilinçli tercih olabilir. Ancak nedenini, sınırını ve ne zaman ele alınacağını kaydederiz. Ürün geliştirme yaklaşımımız, bugünkü hızın yarınki bakım yükünü görünmez kılmasına izin vermemeyi hedefler.
Ürün yalnız kaynak koddan oluşmaz.
Teknik ve API dokümantasyonu, roller, deployment bilgisi ve tasarım dosyaları kapsamın parçası olabilir. Ayrıca erişimleri ve mağaza hesaplarını sahiplikleriyle birlikte düzenleriz. Teslim varlıklarını projenin kapsamına göre baştan netleştiririz.
Hedefe uygun iş birliği.
Belirli kapsam için proje bazlı çalışmayı, gelişen ürünler için uzun vadeli iterasyonu değerlendirebiliriz. Teknik danışmanlık ve mimari desteğin sınırlarını ise ihtiyaca göre tanımlarız. Mevcut ekibe katkı beklentisini ve kapasiteyi ilk görüşmede ayrıca netleştiririz.
Başarı,
teslim etmek değildir.
Kullanıcı ürünü kullanabiliyor mu? İş problemi çözülüyor mu? Sistem sürdürülebilir ve sonraki geliştirmelere hazır mı?
Ürün geliştirme yaklaşımımızın karşılığını bu sorularda ararız. Teknik sorunları görünür kılan, öğrenmeye açık ve sahiplenilebilir bir sistem hedefleriz.
İyi ürün,
doğru sorularla başlar.
Teknolojiyi konuşmadan önce problemi konuşalım.