İçeriğe geç
SEM ROI
Vaka çalışması · Müşteri tarafında ürün yönetimi

İki geliştirme ortağı, tek ürün sahibi

Bir tatil köyü grubu, web sitesini ve misafir uygulamasını iki ortakla yeniden geliştirdi. Ürün sahipliğini grubun tarafında biz yürütüyoruz; brif, kararlar ve kapsam tek bir yerde kalıyor.

Müşteri
Çok markalı tatil köyü grubu (adı paylaşılmıyor)
Sektör
Konaklama · çok markalı portföy
Pazar
Akdeniz · uluslararası misafirler
Süre
2026 – devam ediyor
Rolümüz
Grubun markaları genelinde web, uygulama ve dijital varlıklar için müşteri tarafında ürün yönetimi ve ürün sahipliği
  • Ürün yönetimi
  • Ürün sahipliği
  • Çoklu tedarikçi
  • Keşif
  • Platform mimarisi
  • YZ destekli süreçler
marka; web, uygulama ve dijital varlıklarda tek sorumlu
4
iş kolu: web sitesi, misafir uygulaması, operasyon sistemi
3
teslimat ortağı, tek bir ürün katmanından brif alıyor
2
karar kaydı; her açık sorunun bir sahibi var
1

Ekim 2026 itibarıyla iş kapsamı. Teslimat metrikleri yayına çıkıştan sonra eklenecek.

Zorluk

Tek bir yeniden yapım, çok sayıda ortak ve departman

Web sitesi, misafir uygulaması ve arka uç sistemleri; her birinin kendi öncelikleri olan departmanlar için iki ortak tarafından geliştiriliyordu. Müşteri tarafında birinin bunları tek bir ürüne dönüştürmesi gerekiyordu.

Yapmamız gerekenler
  • Her departmanın girdisini tek bir öncelik listesine dönüştürmekTamamlandı
  • Geliştirme fiyatlanmadan önce platform yönünü netleştirmekTamamlandı
  • İki ortağın da kapsamın tek bir sürümüyle çalışmasını sağlamakDevam ediyor
  • Grubun lansmandan sonra içeriğini kendisi yönetebilmesini sağlamakYapım aşamasında
  • Tasarım ve geliştirme ayrı şirketlerde

    Uygulamayı bir ortak tasarlıyor, diğeri geliştiriyor. Her devir teslim, bir özelliğin iki sözleşme arasında kaybolup fiyatlanmadan kalabileceği bir nokta.

  • Kısıtlar bilinmeden yazılmış bir brif

    Gereksinimler platform sınırları netleşmeden yazılmıştı; bazı maddelerin bir ortak tarafından fiyatlanabilmesi için yeniden yazılması gerekti.

  • Her departmanın ilk önceliği farklıydı

    Her departmanın kendi güçlü gerekçesi vardı ve hepsi aynı yönü göstermiyordu.

  • Sınırları platformlar belirliyor

    Rezervasyon motoru ve diğer üçüncü taraf sistemler, yeni ön yüzün misafirlere neler vaat edebileceğini sınırlıyor.

Neler yaptık

Tek bir ürün pratiği olarak yürütülen altı iş kolu

Ortaklar fiyatlamadan önce brifi gözden geçirdik, tek bir kanıt tabanı oluşturduk ve her kısıtı karar verebilecek kişilere taşıdık.

Program akışı2026 – sürüyor

Yalnızca sıralama. Bu vaka çalışmasında tarihlere yer verilmiyor.

  1. Brif incelemesiSözleşme öncesi

    Gereksinimler, kimse fiyatlamadan önce kontrol edildi

    • Uygulama ve web gereksinimlerinin satır satır incelemesi: boşluklar, belirsizlikler ve önce karar gerektiren maddeler.
    • Native bir uygulamanın ihtiyaç duyduğu başlıklar kontrol edildi: gizlilik ve onay, yerelleştirme, bildirimler, veri taşıma.
    • Hiçbir ortağın yazıldığı haliyle fiyatlayamayacağı maddeler, sözleşmeye girmeden önce yeniden yazıldı ya da bölündü.

    SonuçKapsam soruları değişiklik taleplerinde değil, imzadan önce yanıtlandı.

  2. KeşifDevam ediyor

    İki ortak için tek bir kanıt tabanı

    • Her departmanla görüşmeler ve markalar genelinde otel yönetim ekiplerine yönelik yapılandırılmış bir anket.
    • Mevcut arayüze dair şikâyetler değil, misafirlerin nasıl karar verip rezervasyon yaptığı etrafında kurulan bir kullanıcı araştırması planı.
    • Bulgular güven düzeyine göre etiketlendi; erken bir sinyal hiçbir zaman kesinleşmiş sonuç gibi sunulmuyor.

    Sonuçİki ortak da aynı bulgulardan yola çıkarak tasarlıyor.

  3. Tasarım yönetişimi

    Pek çok kaynaktan geri bildirim, tek bir kayıt

    • Departmanlardan, otel ekiplerinden ve üst yönetimden gelen tasarım geri bildirimleri tek bir kayıtta toplandı.
    • Çatışmalar ve bağımlılıklar ortalamaya vurulmadı, görünür kılındı.
    • Her madde Tasarım, Ek iş ya da Karar bekliyor olarak sınıflandırıldı; kritik maddeler paydaşın ilk ifadesine bağlandı.

    SonuçHer değişiklik talebi kaynağına kadar izlenebiliyor.

  4. Mimari kararlar

    Kısıtlar, onları değiştirebilecek kişilere taşındı

    • Üçüncü taraf platform sınırları, birer tasarım sorununa dönüşmeden önce belgelendi.
    • Grubun BT ekibi ve iki ortakla ortak bir oturum: platform yönü üzerinde uzlaşıldı, gerekçesi kayda geçirildi.
    • Açık sorular, her biri bir sorumlu ve karar mercii ile birlikte kayda alındı.

    SonuçPlatform yönü, geliştirme kapsamı çıkarılmadan önce kararlaştırıldı.

  5. Ortak uyumuDevam ediyor

    İki ortak, kapsamın tek bir sürümü

    • Her karar sorumlusu ve gerekçesiyle bir kez kaydedildi, ortaklarla üzerinde uzlaşılmış kapsam olarak paylaşıldı.
    • İki ortağın birlikte sahiplendiği, web ile uygulama arasında nelerin taşınacağını kapsayan bir tasarımdan geliştirmeye devir teslim şartnamesi.
    • Kabul edilen kapsamın dışındaki talepler sessizce üstlenilmedi; kaydedilip sonraki bir faza bırakıldı.

    SonuçOrtaklar aynı ve netleşmiş kapsamla çalışıyor.

  6. İşletim modeliYapım aşamasında

    Altyapı grubun; ortaklar onun içinde çalışıyor

    • Barındırma, ortamlar ve kod depoları grubun kendi hesaplarında kuruldu; ortaklara erişim verildi.
    • Platform ve CMS yaşam döngüsü yol haritasına dahil edildi, şansa bırakılmadı.
    • Lansman sonrası içerik ve rutin güncellemelerin, CMS içindeki yapay zekâ desteğiyle şirket içinde yürütülmesi planlandı.

    SonuçLansmandan sonra herhangi bir ortağa daha az bağımlılık.

Program akışı2026 – sürüyor
01Brif incelemesiSözleşme öncesi

Gereksinimler, kimse fiyatlamadan önce kontrol edildi

  • Uygulama ve web gereksinimlerinin satır satır incelemesi: boşluklar, belirsizlikler ve önce karar gerektiren maddeler.
  • Native bir uygulamanın ihtiyaç duyduğu başlıklar kontrol edildi: gizlilik ve onay, yerelleştirme, bildirimler, veri taşıma.
  • Hiçbir ortağın yazıldığı haliyle fiyatlayamayacağı maddeler, sözleşmeye girmeden önce yeniden yazıldı ya da bölündü.

SonuçKapsam soruları değişiklik taleplerinde değil, imzadan önce yanıtlandı.

02KeşifDevam ediyor

İki ortak için tek bir kanıt tabanı

  • Her departmanla görüşmeler ve markalar genelinde otel yönetim ekiplerine yönelik yapılandırılmış bir anket.
  • Mevcut arayüze dair şikâyetler değil, misafirlerin nasıl karar verip rezervasyon yaptığı etrafında kurulan bir kullanıcı araştırması planı.
  • Bulgular güven düzeyine göre etiketlendi; erken bir sinyal hiçbir zaman kesinleşmiş sonuç gibi sunulmuyor.

Sonuçİki ortak da aynı bulgulardan yola çıkarak tasarlıyor.

03Tasarım yönetişimi

Pek çok kaynaktan geri bildirim, tek bir kayıt

  • Departmanlardan, otel ekiplerinden ve üst yönetimden gelen tasarım geri bildirimleri tek bir kayıtta toplandı.
  • Çatışmalar ve bağımlılıklar ortalamaya vurulmadı, görünür kılındı.
  • Her madde Tasarım, Ek iş ya da Karar bekliyor olarak sınıflandırıldı; kritik maddeler paydaşın ilk ifadesine bağlandı.

SonuçHer değişiklik talebi kaynağına kadar izlenebiliyor.

04Mimari kararlar

Kısıtlar, onları değiştirebilecek kişilere taşındı

  • Üçüncü taraf platform sınırları, birer tasarım sorununa dönüşmeden önce belgelendi.
  • Grubun BT ekibi ve iki ortakla ortak bir oturum: platform yönü üzerinde uzlaşıldı, gerekçesi kayda geçirildi.
  • Açık sorular, her biri bir sorumlu ve karar mercii ile birlikte kayda alındı.

SonuçPlatform yönü, geliştirme kapsamı çıkarılmadan önce kararlaştırıldı.

05Ortak uyumuDevam ediyor

İki ortak, kapsamın tek bir sürümü

  • Her karar sorumlusu ve gerekçesiyle bir kez kaydedildi, ortaklarla üzerinde uzlaşılmış kapsam olarak paylaşıldı.
  • İki ortağın birlikte sahiplendiği, web ile uygulama arasında nelerin taşınacağını kapsayan bir tasarımdan geliştirmeye devir teslim şartnamesi.
  • Kabul edilen kapsamın dışındaki talepler sessizce üstlenilmedi; kaydedilip sonraki bir faza bırakıldı.

SonuçOrtaklar aynı ve netleşmiş kapsamla çalışıyor.

06İşletim modeliYapım aşamasında

Altyapı grubun; ortaklar onun içinde çalışıyor

  • Barındırma, ortamlar ve kod depoları grubun kendi hesaplarında kuruldu; ortaklara erişim verildi.
  • Platform ve CMS yaşam döngüsü yol haritasına dahil edildi, şansa bırakılmadı.
  • Lansman sonrası içerik ve rutin güncellemelerin, CMS içindeki yapay zekâ desteğiyle şirket içinde yürütülmesi planlandı.

SonuçLansmandan sonra herhangi bir ortağa daha az bağımlılık.

Nasıl çalışıyoruz

Her talep nereye gidiyor

Talepler departmanlardan, otel ekiplerinden, üst yönetimden ve iki ortaktan geliyor. Her biri bir ortağa ulaşmadan önce aynı ürün katmanından geçiyor.

Girdiler
  • Departmanlar
  • Otel ekipleri
  • Üst yönetim
  • Ortaklar
  • Misafir araştırması
Ürün katmanı · müşteri tarafı
  1. Birleştir
  2. Kaynağıyla karşılaştır
  3. Sınıflandır
Çıktılar
  • Tasarımtasarım ortağına
  • Ek işdeğişiklik olarak fiyatlanır ya da sonraki faza bırakılır
  • Karar bekliyordoğru karar merciine (BT, gelir, üst yönetim), bir sorumluyla
  • Platform kısıtımimari karar kaydına

Her talep için tek bir yol. Sınıflandırılmadan ve kaynağı belirtilmeden hiçbir şey bir ortağa ulaşmıyor.

Portföy genelinde

Dört marka, tek ürün sahibi

Dört marka, farklı misafirler, tek portföy. Markaların ortak olduğu yerde kararlar bir kez verilir; ayrıştıkları yerde ayrı tutulur.

  • Marka A
  • Marka B
  • Marka C
  • Marka D
Barındırma · güvenlik · analitik · CMS
  1. Bir kez karar verilir, tüm markalara uygulanır

    Barındırma, güvenlik, analitik ve CMS seçimleri grup düzeyinde yapılır; böylece her marka aynı değerlendirmeyi baştan yapmaz.

  2. Her marka kendi konumunu korur

    Ortak bileşenler ve standartlar altta durur; ton, içerik ve misafir deneyimi markanın kendisine ait kalır.

  3. Dersler bir sonrakine taşınır

    Bir markanın projesinin ortaklar, platformlar ve içerik hakkında öğrettikleri bir sonraki brife yansır.

  4. Gerçek geçmişe dayalı destek kapsamı

    Bakım ve destek ihtiyacı, kalıp bir aylık anlaşmaya göre değil, mevcut sitelerin gerçekte neye ihtiyaç duyduğuna göre öngörülür.

Öncesi ve sonrası

Program artık nasıl işliyor

AlanÖncesiŞimdi
Geri bildirimHer departman ortaklarla doğrudan konuşuyorduTek kayıt; sınıflandırılmış ve kaynağı belli
KısıtlarTasarım sırasında fark ediliyorduÖnce karar vericilere taşınıyor
KararlarToplantılarda alınıyor, farklı hatırlanıyorduSorumlusu ve gerekçesiyle kayıtlı
Kapsam değişiklikleriDuruma göre ele alınıyorduKaydediliyor, fiyatlanıyor ya da sonraya bırakılıyor
Lansman sonrası içerikOrtağa açılan bir talepŞirket içinde, yapay zekâ destekliplanlandı
  • Geri bildirim

    Şimdi: Tek kayıt; sınıflandırılmış ve kaynağı belli

    Öncesi: Her departman ortaklarla doğrudan konuşuyordu

  • Kısıtlar

    Şimdi: Önce karar vericilere taşınıyor

    Öncesi: Tasarım sırasında fark ediliyordu

  • Kararlar

    Şimdi: Sorumlusu ve gerekçesiyle kayıtlı

    Öncesi: Toplantılarda alınıyor, farklı hatırlanıyordu

  • Kapsam değişiklikleri

    Şimdi: Kaydediliyor, fiyatlanıyor ya da sonraya bırakılıyor

    Öncesi: Duruma göre ele alınıyordu

  • Lansman sonrası içerik

    Şimdi: Şirket içinde, yapay zekâ destekliplanlandı

    Öncesi: Ortağa açılan bir talep

Neler öğrendik

  1. Risk, ortakların arasında

    Sorun ortaklardan hiçbiri değildi; sorun, kimsenin sahiplenmediği özelliklerdi. Her devir teslimi erkenden haritalamak, kapsamın aksi halde fiyatlanmadan kalacağı yerleri gösterdi.

  2. Kısıtı, değiştirebilecek kişilere götürün

    Misafirlerin istediği bir özellik üçüncü taraf bir platformun izin verdiklerine bağlıysa, çözüm daha akıllıca bir tasarım değildir. Bu, o platformun ve ticari koşullarının sahiplerinin kararıdır; konuyu oraya taşırız.

  3. YZ birleştirmeyi hızlandırır, kaynaklar dürüst tutar

    Özetler kayar: bir şey söyleyen not, yeniden ifade edilirken daha güçlü bir iddiaya dönüşebilir. Yapay zekâyı ölçekli birleştirme için kullanıyor, her kritik maddeyi paydaşın kendi sözlerine bağlıyoruz.

Birden fazla ortakla bir program mı yürütüyorsunuz?

Ne geliştirdiğinizi ve kimin geliştirdiğini anlatın; boşlukların nerede çıkabileceğini ve ürün tarafını nasıl yöneteceğimizi gösterelim.

Shopify üzerindeki yeni Horeca Papatya ana sayfası
Sonraki vaka çalışması · Otel tedariki
Horeca Papatya: online gelirin yarısı Google'dan