Codezone
Tüm MakalelerÖzel Yazılım Yaptırmadan Önce Proje Kapsamı Nasıl Netleşir?
Dijital Ürünler

Özel Yazılım Yaptırmadan Önce Proje Kapsamı Nasıl Netleşir?

30 Eyl 20269 dk okuma
Ömer Faruk ÇOBANOĞLU
Ömer Faruk ÇOBANOĞLU

Özel yazılım projesinde kapsam; kullanıcıların ne yapacağı, ekiplerin neyi yöneteceği, hangi verilerin işleneceği ve sistemin hangi süreçleri taşıyacağı üzerinden netleşir.

Özel Yazılım Yaptırmadan Önce Proje Kapsamı Nasıl Netleşir?

Özel Yazılım Projesinde Kapsam Neden En Başta Netleşmeli?

Özel yazılım projesi genellikle net bir ihtiyaçla başlar: şirket içinde tekrar eden bir işi kolaylaştırmak, müşteri süreçlerini dijitale taşımak, ekiplerin kullandığı dağınık araçları tek yapıda toplamak veya mevcut operasyonu daha ölçülebilir hale getirmek.

Fakat ilk ihtiyaç net görünse bile proje kapsamı çoğu zaman başlangıçta tam oturmuş olmaz. “Bir panel yapalım”, “müşteriler giriş yapsın”, “siparişler takip edilsin”, “ekipler buradan yönetsin” gibi cümleler iyi bir başlangıçtır; ama yazılım geliştirme için yeterli kapsam tanımı değildir.

Özel yazılımda kapsam; ekran sayısından önce iş akışı, kullanıcı rolleri, veri yapısı, yetkiler, entegrasyonlar ve yayın sonrası kullanım üzerinden netleşir.

İyi tanımlanmış kapsam, projenin küçülmesi anlamına gelmez. Hangi parçanın ne zaman, hangi sırayla ve hangi amaçla geliştirileceğinin netleşmesi anlamına gelir.

Bu netlik sağlandığında proje daha sağlıklı planlanır. Bütçe, süre, teknik mimari, ilk sürüm ve sonraki fazlar daha gerçekçi şekilde ortaya çıkar.

Projenin Çözeceği Ana İş Akışı Tanımlanmalı

Özel yazılım kapsamı, önce “hangi özellikler olacak?” sorusuyla değil, “hangi iş akışı yazılıma taşınacak?” sorusuyla başlamalıdır.

Bir şirket için özel yazılım şu alanlardan birini taşıyor olabilir:

  • Sipariş yönetimi

  • Bayi operasyonu

  • Müşteri talepleri

  • Randevu süreçleri

  • Stok ve depo takibi

  • Servis kayıtları

  • Teklif hazırlama

  • Saha ekipleri

  • Eğitim süreçleri

  • Başvuru ve onay akışları

  • İç ekip görevleri

  • Raporlama ve yönetim takibi

Bu aşamada önemli olan, mevcut süreci olduğu gibi dijitale kopyalamak değildir. Önce sürecin nasıl işlediği anlaşılır; ardından yazılım içinde daha düzenli, izlenebilir ve geliştirilebilir hale getirilir.

Ana akış nasıl çıkarılır?

Proje başlangıcında şu sorulara cevap aranır:

  • Süreç nerede başlıyor?

  • İlk kaydı kim oluşturuyor?

  • Hangi bilgiler giriliyor?

  • Hangi ekip bu kaydı görüyor?

  • Onay adımı var mı?

  • Süreç hangi durumlara ayrılıyor?

  • Kullanıcıya hangi bildirimler gidiyor?

  • Hangi veri raporlanıyor?

  • Süreç nerede tamamlanıyor?

Örneğin servis talebi yönetilecekse ana akış şöyle olabilir:

Müşteri talep oluşturur → Merkez ekip talebi inceler → Uygun ekibe atama yapılır → Saha ekibi işlem durumunu günceller → Müşteri bilgilendirilir → Talep tamamlanır → Rapor oluşur

Bu akış netleşmeden ekran listesi çıkarmak sağlıklı sonuç vermez. Çünkü her ekranın arkasında bir işlem, her işlemin arkasında bir veri ve her verinin arkasında bir yetki yapısı vardır.

ga.webp

Kullanıcı Rolleri Baştan Ayrıştırılmalı

Özel yazılım projelerinde en önemli kapsam kararlarından biri kullanıcı rolleridir. Sistemi kimler kullanacak? Her kullanıcı aynı ekranları mı görecek? Hangi kullanıcı hangi işlemi yapabilecek?

Kullanıcı rolleri netleşmeden yazılımın ekran yapısı, yetkilendirme sistemi ve yönetim paneli doğru tasarlanamaz.

Sık görülen kullanıcı rolleri

  • Sistem yöneticisi

  • Operasyon ekibi

  • Satış ekibi

  • Finans kullanıcısı

  • Müşteri

  • Bayi

  • Saha ekibi

  • İç ekip üyesi

  • Onay yetkilisi

  • Rapor görüntüleyen kullanıcı

Her rolün ihtiyacı farklıdır. Yönetici tüm sistemi görmek ister. Operasyon ekibi günlük kayıtları yönetir. Finans kullanıcısı ödeme ve fatura alanlarına erişir. Müşteri yalnızca kendi kayıtlarını görür. Bayi özel fiyat ve sipariş bilgilerine ulaşır. Saha ekibi ise kendisine atanan işleri takip eder.

Rol ve yetki farkı

Rol, kullanıcının sistem içindeki genel konumudur. Yetki ise o kullanıcının hangi işlemleri yapabileceğini belirler.

Örneğin “operasyon ekibi” bir roldür. Bu role bağlı yetkiler şu şekilde olabilir:

  • Talep görüntüleme

  • Talep durumunu değiştirme

  • Kullanıcıya not ekleme

  • Dosya yükleme

  • Sipariş güncelleme

  • Rapor görüntüleme

Bu ayrım doğru yapılırsa sistem daha güvenli ve yönetilebilir olur.

Modüller İş Akışına Göre Gruplanmalı

Özel yazılım projelerinde modül listesi çoğu zaman projenin kapsamını belirleyen ana başlık gibi görülür. Ancak modüller, ana iş akışı ve kullanıcı rollerinden sonra netleştirilmelidir.

Bir özel yazılımda şu modüller bulunabilir:

  • Kullanıcı yönetimi

  • Müşteri yönetimi

  • Talep yönetimi

  • Sipariş yönetimi

  • Ürün veya hizmet yönetimi

  • Stok yönetimi

  • Randevu yönetimi

  • Belge yönetimi

  • Bildirimler

  • Raporlama

  • Ayarlar

  • Entegrasyon yönetimi

  • Yönetim paneli

Burada amaç, her ihtimali modül haline getirmek değildir. Amaç, sistemin gerçekten taşıyacağı işleri anlamlı parçalara ayırmaktır.

Modül listesi, yazılımın menüsü gibi düşünülmemelidir. Her modül, şirket içinde yönetilen somut bir iş alanını temsil etmelidir.

İlk sürüm modülleri nasıl seçilir?

İlk sürüm için modüller şu sorularla önceliklendirilebilir:

  • Bu modül ana iş akışı için gerekli mi?

  • Kullanıcı ilk günden bu modülü kullanacak mı?

  • Ekip bu alan olmadan operasyonu yürütebilir mi?

  • Bu modül başka bir modülün çalışması için zorunlu mu?

  • Yayın sonrası eklenirse büyük teknik değişiklik gerektirir mi?

Örneğin müşteri taleplerini yöneten bir sistemde ilk sürüm için kullanıcı yönetimi, talep yönetimi, durum takibi, bildirimler ve temel raporlama yeterli olabilir. Gelişmiş segmentasyon, detaylı dashboard, yapay zekâ destekli öneriler veya otomatik görev atama sonraki fazlara bırakılabilir.

Veri Yapısı Projenin Omurgasını Oluşturur

Özel yazılım projelerinde ekranlar görünür taraftır; veri yapısı ise sistemin omurgasıdır. Hangi bilginin tutulacağı, hangi bilginin kim tarafından güncelleneceği ve hangi verinin hangi modülle bağlantılı olacağı baştan düşünülmelidir.

Veri yapısında netleşmesi gereken alanlar

  • Kullanıcı bilgileri

  • Müşteri bilgileri

  • Ürün veya hizmet kayıtları

  • Sipariş veya talep kayıtları

  • Durum bilgileri

  • Tarih ve işlem geçmişi

  • Dosyalar

  • Ödeme veya fatura bilgileri

  • Bildirim kayıtları

  • Loglar

  • Raporlama verileri

Örneğin bir bayi portalında bayi hesabı, bayi kullanıcıları, fiyat listeleri, ürünler, siparişler ve ödeme bilgileri birbirine bağlı çalışır. Bu ilişkiler doğru kurulmazsa sistem büyüdükçe yönetim zorlaşır.

Bayi portalı gibi B2B yapılarda kapsamın nasıl şekillendiğini Bayi Portalı Kurmak İsteyen Şirketler Nereden Başlamalı? yazısında daha detaylı ele alıyoruz.

Veri sadece saklanmaz, süreçleri çalıştırır

Özel yazılımda veri yapısı yalnızca kayıt tutmak için kullanılmaz. Sistem davranışlarını da belirler.

Örneğin:

  • Sipariş durumu değişirse müşteriye bildirim gider.

  • Kullanıcının rolü değişirse erişim alanları güncellenir.

  • Stok azalırsa uyarı oluşur.

  • Ödeme tamamlanırsa hizmet aktifleşir.

  • Talep kapanırsa rapora yansır.

Bu nedenle veri modeli, projenin teknik tarafında en erken netleşmesi gereken alanlardan biridir.

gb.webp

Yönetim Paneli Kapsamı Operasyona Göre Belirlenmeli

Özel yazılım projelerinde yönetim paneli çoğu zaman sistemin en önemli alanlarından biridir. Çünkü şirket ekibi yazılımı bu panel üzerinden yönetir.

Yönetim paneli yalnızca kayıt listeleyen bir ekran olmamalıdır. Ekibin günlük operasyonunu taşıyan, karar almasını kolaylaştıran ve süreçleri düzenli takip etmesini sağlayan bir çalışma alanı olarak düşünülmelidir.

Yönetim panelinde yer alabilecek alanlar

  • Dashboard

  • Kullanıcılar

  • Müşteriler

  • Talepler

  • Siparişler

  • Randevular

  • Ürünler

  • Belgeler

  • Bildirimler

  • Raporlar

  • Ayarlar

  • Entegrasyon kontrolleri

  • Yetki yönetimi

Ancak her projede bu alanların tamamı gerekmez. Panel kapsamı, şirketin günlük iş akışına göre belirlenmelidir.

Yönetim paneli modüllerini daha geniş anlattığımız Yönetim Paneli Yaptırırken Hangi Modüller Planlanmalı? yazısı bu konu için iyi bir tamamlayıcıdır.

Panelde ilk bakışta ne görünmeli?

İyi bir yönetim panelinde kullanıcı ilk bakışta neye odaklanacağını anlamalıdır. Bu nedenle dashboard alanı rastgele kartlarla doldurulmamalıdır.

Örneğin servis yönetimi yapan bir sistemde dashboard şunları gösterebilir:

  • Yeni talepler

  • Açık işler

  • Atama bekleyen kayıtlar

  • Bugünkü saha görevleri

  • Geciken işlemler

  • Tamamlanan talepler

  • Son aktiviteler

Bu yapı, paneli yalnızca izleme alanı olmaktan çıkarır; ekibin günlük kararlarını yönlendiren operasyon ekranına dönüştürür.

Entegrasyonlar Kapsamın Gizli Büyüme Noktasıdır

Özel yazılım projelerinde entegrasyonlar çoğu zaman kapsamı ciddi şekilde etkiler. Proje başında küçük görünen bir bağlantı, teknik tarafta veri uyumu, güvenlik, hata yönetimi, senkronizasyon ve test süreçleri gerektirebilir.

Bu yüzden entegrasyon ihtiyacı erken netleşmelidir.

Sık kullanılan entegrasyonlar

  • ERP

  • CRM

  • Muhasebe yazılımı

  • E-fatura

  • Ödeme altyapısı

  • SMS servisi

  • E-posta servisi

  • Kargo sistemi

  • Harita servisi

  • Takvim

  • Dosya depolama

  • Analytics araçları

Her entegrasyon için şu sorular cevaplanmalıdır:

  • Veri hangi sistemden gelecek?

  • Hangi sistem ana kaynak olacak?

  • Veri tek yönlü mü çift yönlü mü akacak?

  • Güncelleme gerçek zamanlı mı yapılacak?

  • Hata olduğunda ne olacak?

  • Kullanıcıya hangi bilgi gösterilecek?

  • Yönetim panelinde entegrasyon durumu görülecek mi?

API entegrasyonlarının şirketler için sağladığı değeri API Entegrasyonu Nedir? Şirketler İçin Ne Sağlar? yazısında ayrıca inceleyebilirsiniz.

Entegrasyon kararı yalnızca “bağlanırız” seviyesinde bırakıldığında proje içinde belirsizlik oluşturur. Hangi verinin, hangi yönde, hangi kuralla akacağı netleşmelidir.

İlk Sürüm ve Sonraki Fazlar Ayrı Planlanmalı

Özel yazılım projesinde tüm ihtiyaçları tek faza almak cazip görünebilir. Fakat sağlıklı başlangıç için ilk sürüm ve sonraki fazlar ayrılmalıdır.

İlk sürüm, sistemin temel iş akışını çalıştıran versiyonudur. Sonraki fazlar ise kullanıcı geri bildirimleri, operasyon deneyimi ve ölçümleme verileriyle şekillenir.

İlk sürümde yer alabilecek alanlar

  • Temel kullanıcı rolleri

  • Ana iş akışı

  • Kritik modüller

  • Yönetim panelinin ilk versiyonu

  • Temel bildirimler

  • Zorunlu entegrasyonlar

  • Basit raporlama

  • Güvenlik ve yetkilendirme

  • Yayın hazırlığı

Sonraki fazlara bırakılabilecek alanlar

  • Gelişmiş raporlama

  • Otomasyonlar

  • Kişiselleştirme

  • Gelişmiş entegrasyonlar

  • Mobil uygulama

  • Çoklu dil

  • Kampanya veya segmentasyon

  • Yapay zekâ destekli özellikler

  • Daha detaylı rol yönetimi

Bu ayrım proje bütçesini daha kontrollü kullanmayı sağlar. Aynı zamanda ürünün gerçek kullanıcı davranışlarına göre gelişmesine alan açar.

Mobil uygulama tarafında ilk sürüm kapsamını Mobil Uygulama İçin İlk Sürüm Kapsamı Nasıl Belirlenir? yazısında detaylı anlatıyoruz. Özel yazılım projelerinde de benzer yaklaşım geçerlidir: önce temel akış, sonra kontrollü gelişim.

Kapsam Dokümanı Projenin Ortak Dili Olmalı

Özel yazılım projesinde kapsam netleştikten sonra bu yapının yazılı hale gelmesi gerekir. Kapsam dokümanı, müşteri ve yazılım ekibi arasında ortak dil oluşturur.

Bu doküman fazla ağır bir teknik şartname gibi hazırlanmak zorunda değildir. Ancak projenin ana kararlarını anlaşılır şekilde içermelidir.

Kapsam dokümanında neler yer alabilir?

  • Projenin amacı

  • Hedef kullanıcılar

  • Kullanıcı rolleri

  • Ana iş akışları

  • Modül listesi

  • Ekran yapısı

  • Veri ihtiyaçları

  • Yönetim paneli kapsamı

  • Entegrasyonlar

  • Bildirim senaryoları

  • Raporlama ihtiyaçları

  • İlk sürüm kapsamı

  • Sonraki faz önerileri

  • Teknik varsayımlar

  • Açık kalan kararlar

Bu doküman, proje boyunca alınan kararların da referansı olur. Yeni bir özellik gündeme geldiğinde, bu özelliğin ilk sürüme mi yoksa sonraki faza mı ait olduğu daha kolay değerlendirilir.

Kapsam dokümanı, projenin yaratıcılığını sınırlayan bir dosya değildir. Ekibin aynı hedefe bakmasını sağlayan çalışma zemini oluşturur.

Proje Kapsamı Teklif Sürecini de Netleştirir

Özel yazılım tekliflerinde en büyük farkları oluşturan konu çoğu zaman kapsam belirsizliğidir. Aynı fikir, farklı kapsam seviyeleriyle çok farklı süre ve maliyetlere dönüşebilir.

Örneğin “müşteri portalı” ifadesi tek başına yeterli değildir. Bu portalda kullanıcı girişi olacak mı, belge paylaşımı yapılacak mı, ödeme bilgisi görünecek mi, destek talebi açılacak mı, ERP entegrasyonu olacak mı, yönetim paneli hangi modülleri içerecek?

Bu detaylar netleşmeden verilen fiyatlar sağlıklı karşılaştırılamaz.

Daha doğru teklif için paylaşılması iyi olan bilgiler

  • Projenin amacı

  • Kullanıcı tipleri

  • Yönetilecek ana süreç

  • Gerekli modüller

  • Mevcut sistemler

  • Entegrasyon beklentileri

  • Örnek ekranlar veya referanslar

  • İlk sürümde olmazsa olmaz alanlar

  • Sonraki faz beklentileri

  • Yayın hedefi

Bu bilgiler yazılım ekibinin projeyi daha doğru anlamasını sağlar. Böylece teklif yalnızca tahmini bir fiyat gibi değil, gerçek kapsamla bağlantılı bir proje önerisi haline gelir.

Codezone Yaklaşımı

Özel yazılım projelerinde kapsamı ekran sayısından önce iş akışı üzerinden ele alıyoruz. Çünkü şirketin ihtiyacı çoğu zaman “birkaç ekran” değil; belirli bir operasyonun daha düzenli, takip edilebilir ve geliştirilebilir hale gelmesidir.

Codezone’da proje başlangıcında kullanıcı rollerini, ana süreçleri, veri ilişkilerini, yönetim paneli ihtiyaçlarını, entegrasyonları ve ilk sürüm kapsamını birlikte çıkarıyoruz. Bu yapı netleştiğinde yazılımın yalnızca görünen arayüzü değil, arka plandaki teknik omurgası da daha sağlıklı planlanıyor.

Bu yaklaşım sayesinde özel yazılım projesi; neyin geliştirileceği, hangi sırayla ilerleyeceği ve hangi teknik yapıya dayanacağı daha net görülen bir ürün sürecine dönüşür.

Sonuç

Özel yazılım yaptırmadan önce proje kapsamının netleşmesi, hem şirket hem de yazılım ekibi için daha sağlıklı bir başlangıç sağlar. Ana iş akışı, kullanıcı rolleri, modüller, veri yapısı, yönetim paneli, entegrasyonlar, ilk sürüm ve sonraki fazlar birlikte ele alındığında proje daha gerçekçi şekilde planlanır.

Kapsam netliği, projeyi yavaşlatan bir ön hazırlık gibi görülmemelidir. Aksine, geliştirme sürecinin daha kontrollü ilerlemesini sağlayan temel adımdır.

Özel yazılım projesi doğru kapsamla başladığında; kullanıcıların ihtiyaç duyduğu akışlar daha net kurulur, ekiplerin yönetim alanları daha düzenli çalışır ve sistem uzun vadede geliştirilebilir bir yapıya kavuşur.

Sıkça Sorulan Sorular

Özel yazılım projesinde kapsam ne demektir?

Kapsam; yazılımda yer alacak kullanıcı rolleri, iş akışları, modüller, ekranlar, veri yapısı, yönetim paneli, entegrasyonlar ve ilk sürüm özelliklerinin bütünüdür.

Özel yazılım yaptırmadan önce hangi bilgiler hazırlanmalı?

Projenin amacı, hedef kullanıcılar, yönetilecek süreçler, ihtiyaç duyulan modüller, mevcut sistemler, entegrasyon beklentileri ve ilk sürümde gerekli olan ana özellikler hazırlanmalıdır.

İlk sürüm kapsamı neden ayrı belirlenmeli?

İlk sürüm, projenin temel iş akışını çalıştıran başlangıç versiyonudur. Tüm özellikleri aynı anda geliştirmek yerine, önce ana değeri taşıyan yapı yayına alınır; sonraki geliştirmeler gerçek kullanıma göre planlanır.

Yönetim paneli her özel yazılım projesinde gerekli midir?

Bir ekip kullanıcıları, kayıtları, siparişleri, talepleri, içerikleri veya raporları yönetecekse yönetim paneli gerekir. Panel kapsamı projenin operasyon ihtiyacına göre belirlenmelidir.

Entegrasyonlar proje kapsamını etkiler mi?

Evet. ERP, CRM, ödeme, muhasebe, kargo, SMS, e-posta veya farklı sistemlerle kurulacak bağlantılar proje süresini, teknik mimariyi, test sürecini ve maliyeti doğrudan etkiler.