Bir yazılım şirketiyle ilk görüşmeye hazırlanırken teknik dokümanınızın, ekran tasarımlarınızın veya tamamlanmış bir özellik listenizin olması şart değildir. Hatta birçok projede bunları geliştirme ekibiyle birlikte şekillendirmek daha sağlıklıdır.
Ancak bazı temel konuların önceden düşünülmesi, görüşmenin kalitesini ciddi biçimde artırır. Ekip ihtiyacınızı daha doğru anlar, belirsizlikler daha hızlı görünür hale gelir ve tekliflerin birbirinden neden farklı olduğunu değerlendirmek kolaylaşır.
Aşağıdaki sekiz başlık, ilk görüşme öncesinde hazırlanabilecek en değerli çerçeveyi oluşturur.
1. Çözmek istediğiniz problem
Görüşmeye “bir mobil uygulama yaptırmak istiyoruz” veya “AI tabanlı bir platform düşünüyoruz” diyerek başlamak mümkündür. Ancak çözüm biçiminden önce problemi anlatmak daha faydalıdır.
Şu sorulara kısa cevaplar hazırlayın:
- Bugün ne yanlış veya verimsiz ilerliyor?
- Bu problem kimleri etkiliyor?
- Ne sıklıkta yaşanıyor?
- İşletmeye zaman, para veya müşteri kaybı olarak etkisi nedir?
- Şu anda nasıl çözülüyor?
Örneğin “öğretmenler için bir panel istiyoruz” yerine “öğretmenler farklı kaynaklardan gelen öğrenci sonuçlarını birleştirmek için haftada birkaç saat harcıyor” demek çok daha yönlendiricidir.
2. Hedef kullanıcılar ve karar vericiler
Ürünü kim kullanacak, kim satın alacak ve kim yönetecek?
Bu roller aynı kişi olmayabilir. EdTech ürününde öğrenci, öğretmen, okul yöneticisi, veli ve yayıncı farklı ihtiyaçlara sahiptir. Bir hastane yazılımında doktor, hemşire, operasyon ekibi, IT departmanı ve yönetim farklı beklentiler taşıyabilir.
Her kullanıcı grubu için şu üç bilgiyi not edin:
- Ürünle yapmak istediği ana iş,
- Bugünkü en büyük zorluğu,
- Başarılı bir deneyimden beklediği sonuç.
Bu çalışma, tek bir ürün içinde gereksiz rol karmaşasını azaltır.
3. Mevcut iş akışı
Yeni yazılımın sıfırdan tamamen yeni bir süreç oluşturacağını düşünseniz bile, kullanıcılar bugün bir şeyler yapıyor.
Süreci mümkün olduğunca basit biçimde adım adım yazın:
- Talep nereden geliyor?
- Kim işlem yapıyor?
- Hangi bilgiler toplanıyor?
- Kim onaylıyor?
- Sonuç nereye aktarılıyor?
- Hangi rapor hazırlanıyor?
Excel dosyaları, formlar, e-postalar, WhatsApp mesajları ve kullanılan mevcut yazılımlar da bu akışın parçasıdır.
Geliştirme ekibi yalnızca ideal süreci değil, kullanıcıların gerçek alışkanlıklarını da bilmelidir.
4. Beklediğiniz iş sonucu
Projenin amacı “yazılımın tamamlanması” olmamalıdır. Başarıyı iş sonucuyla tanımlayın.
Örneğin:
- Manuel veri girişini azaltmak,
- Yeni bir abonelik geliri oluşturmak,
- Müşteri taleplerine daha hızlı dönmek,
- Öğretmenlerin aktif kullanımını artırmak,
- Rezervasyon hatalarını azaltmak,
- Yeni pazarlara açılmak,
- Operasyon ekibinin aynı sayıda çalışanla daha fazla müşteriyi yönetebilmesini sağlamak.
Mümkünse bir veya iki ölçülebilir hedef belirleyin. Bu hedefler, proje kapsamının ve önceliklerin tartışılmasını kolaylaştırır.
5. Olmazsa olmazlar ve ertelenebilecekler
İlk görüşmeye yüz maddelik kesin bir özellik listesiyle gitmek zorunda değilsiniz. Ancak ihtiyaçları üç gruba ayırmak yararlıdır:
- İlk sürümde mutlaka olması gerekenler,
- Olması değerli fakat sonraya bırakılabilecekler,
- Şimdilik fikir seviyesinde olanlar.
Burada “mutlaka gerekli” ifadesini dikkatli kullanın. Bir özellik yapılmadığında ürünün temel değeri kaybolmuyor, yasal bir sorun oluşmuyor veya müşteri ürünü kullanamaz hale gelmiyorsa ilk faza ait olmayabilir.
Önceliklendirme, bütçeyi azaltmak için yapılan rastgele bir kesinti değil; ürünü daha erken öğrenmek için alınan stratejik karardır.
6. Beğendiğiniz ve beğenmediğiniz örnekler
Referans ürünler, beklentiyi anlatmayı kolaylaştırır. Ancak “bunun aynısını istiyoruz” demek yerine neyi neden beğendiğinizi belirtin.
- Kayıt akışı mı kolay?
- Dashboard bilgiyi iyi mi özetliyor?
- Arama ve filtreleme mi güçlü?
- Görsel dil mi güven veriyor?
- Mobil deneyim mi hızlı?
Aynı şekilde beğenmediğiniz örnekleri ve nedenlerini de paylaşın. Böylece ekip yalnızca görsel zevki değil, deneyim beklentisini anlayabilir.
Örneklerin sektörünüzden olması şart değildir. Bir turizm ürünündeki rezervasyon akışı, sağlık uygulamasındaki adım adım yönlendirmeden ilham alabilir. Önemli olan hangi davranışın örnek alındığını açıklamaktır.
7. Entegrasyon, veri ve teknik kısıtlar
Projenin mevcut sistemlerle nasıl ilişki kuracağını baştan düşünmek gerekir.
Aşağıdaki bilgileri mümkün olduğunca hazırlayın:
- Kullanılan mevcut yazılımlar,
- Entegre olunması gereken sistemler,
- Var olan API veya teknik dokümanlar,
- Taşınacak veri miktarı,
- Veri formatları,
- Kullanıcı sayısı ve beklenen büyüme,
- Güvenlik veya mevzuat gereksinimleri,
- Web, mobil veya çevrimdışı kullanım ihtiyacı.
Bu bilgilerin tamamı elinizde olmayabilir. Önemli olan bilinmeyenleri de görünür kılmaktır. “Mevcut sistemimizin API sunup sunmadığını bilmiyoruz” demek, entegrasyonu yok saymaktan daha değerlidir.
8. Bütçe, zamanlama ve karar süreci
Bütçe paylaşmak birçok şirket için zor olabilir. Ancak hiçbir aralık vermemek, geliştirme ekibinin gerçekçi bir yaklaşım önermesini güçleştirir.
Aynı problem çok farklı kapsamlarla çözülebilir. Bir pilot ürün, üretime hazır kurumsal platform ve çok ülkeli ölçeklenebilir sistem aynı bütçe ve sürede geliştirilemez.
Şu bilgileri netleştirmeye çalışın:
- Hedeflenen bütçe veya yatırım aralığı,
- Kritik bir lansman ya da etkinlik tarihi olup olmadığı,
- Kararı kimin vereceği,
- Hukuk, satın alma veya IT onayı gerekip gerekmediği,
- İçerik, tasarım veya veri gibi sorumlulukların kimde olacağı.
Süre ve bütçe net değilse bile öncelik sırası paylaşılabilir: “Hız bizim için kapsamdan daha önemli” veya “İlk sürüm küçük olabilir ama altyapının belirli güvenlik şartlarını karşılaması gerekiyor” gibi.
İlk görüşmede ne beklemelisiniz?
İyi bir yazılım ekibi ilk toplantıda yalnızca özellikleri not almaz. Problemi, kullanıcıyı, iş modelini ve riskleri anlamaya çalışır.
Size şu tür sorular sorması beklenir:
- Bu özelliğe neden ihtiyaç var?
- Bugünkü süreç nasıl ilerliyor?
- İlk kullanıcı grubu kim olacak?
- Başarıyı nasıl ölçeceğiz?
- En riskli varsayım nedir?
- Entegrasyon için teknik erişim var mı?
- Bu kapsam fazlara ayrılabilir mi?
Bu sorular süreci zorlaştırmak için değil, yanlış ürünü doğru biçimde geliştirmemek için sorulur.
ONX Software olarak yaklaşık 20 yıldır farklı sektörlerde yazılım projeleri geliştiriyoruz. Özellikle son 12 yıldaki EdTech çalışmalarımızda gördüğümüz en önemli farklardan biri şu oldu: İyi başlayan projelerde müşterinin tüm cevaplara sahip olması gerekmiyordu; fakat hangi soruların cevaplanmadığını biliyordu.
İlk görüşmenin amacı kusursuz bir proje dosyası sunmak değildir. İhtiyacı birlikte netleştirecek kadar doğru bağlamı oluşturmaktır.
