Portföyünüz için eğitim amaçlı CRM nasıl geliştirilir?

Eğitim amaçlı bir CRM, gerçek iş süreçleriyle çalışmayı gösterdiği için en iyi portföy projelerinden biridir. Kullanıcılar ve roller, ilişkili varlıklar, satış hunisi, görevler, değişiklik geçmişi, analitik ve erişim kısıtlamaları içerir. Böyle bir proje yalnızca arayüzü değil, eksiksiz bir sistem mimarisinin anlaşıldığını da gösterir.

Belirli bir senaryoyla başlamak gerekir. Örneğin CRM, web sitesinden talepler alan, bunları yöneticiler arasında dağıtan ve müşteriyi ödemeye kadar takip eden küçük bir şirket için geliştirilebilir. Açık bağlam, gerekli işlevleri belirlemeye ve eğitim projesini büyük bir kurumsal sistemin sonsuz kopyasına dönüştürmemeye yardımcı olur.

İlk sürüm için iki rol yeterlidir: yönetici ve satış sorumlusu. Yönetici çalışanları, satış hunisini ve genel ayarları yönetir. Satış sorumlusu kendisine atanan müşterileri ve fırsatları görür, görev oluşturur, yorum ekler ve satış aşamasını değiştirir. Rol kontrolü yalnızca arayüzde düğmeleri gizlemekle kalmamalı, sunucuda yapılmalıdır.

Projenin temel varlıkları kullanıcı, müşteri, iletişim kişisi, fırsat, huni aşaması, görev, yorum ve geçmiş olayıdır. Bir müşterinin birden fazla iletişim kişisi ve fırsatı olabilir; fırsatın sorumlu yöneticisi, mevcut aşaması, tutarı, beklenen kapanış tarihi ve etkinlikleri bulunur. İlişkiler yabancı anahtarlar ve veri tabanı kısıtlamalarıyla güvence altına alınmalıdır.

Temel iş süreci şöyledir: yeni talep bir müşteri ve fırsat oluşturur; yönetici veya sistem bir satış sorumlusu atar; sorumlu bir sonraki iletişimi planlar, fırsatı aşamalar arasında ilerletir ve sonucu kaydeder. Zorunlu veriler olmadan fırsatın kapatılmasına izin verilmemeli, gecikmiş görev ise dikkat gerektiren öğe olarak gösterilmelidir.

Arayüz; genel bakış paneli, müşteri listesi, fırsat Kanban panosu, görevler, müşteri kartı ve yönetim bölümü olarak ayrılabilir. Müşteri kartı iletişim kişilerini, fırsatları, yorumları ve işlem zaman çizelgesini bir araya getirmelidir. Kullanıcı mevcut çalışma durumunu anlamak için çok sayıda ekran arasında geçiş yapmamalıdır.

Eğitim mimarisi için modüler monolit uygundur. İstemci uygulaması arayüzden, sunucu iş mantığı ve erişim kontrolünden, PostgreSQL kalıcı verilerden, dosya depolama ise belgelerden sorumludur. Ayrı mikroservisler bu aşamada projeyi yalnızca karmaşıklaştırır ve portföye ek fayda sağlamaz.

API, ekranlar toplu şekilde yazılmadan önce tasarlanmalıdır. Her işlem için adres, yöntem, giriş verileri, olası hatalar ve erişim yetkileri belirlenmelidir. OpenAPI dokümantasyonu sözleşmeyi anlaşılır kılar, isteklerin arayüzden bağımsız test edilmesini sağlar ve işverene düzenli bir mühendislik yaklaşımı gösterir.

İşlem geçmişine özel önem verilmelidir. CRM; fırsat oluşturmayı, aşama değişikliğini, yönetici atamasını, tutar değişikliğini ve görev tamamlanmasını kaydetmelidir. Bu günlük hataları incelemeye yardımcı olur ve geliştiricinin iş sistemlerinde denetimin önemini anladığını gösterir.

Genel bakış paneli için birkaç yararlı gösterge yeterlidir: yeni fırsat sayısı, aktif huninin toplam değeri, aşamalar arasındaki dönüşüm, gecikmiş görevler ve satış sorumlularının sonuçları. Veriler gerçek kayıtlardan hesaplanmalı; filtreler dönem ve sorumlu çalışana göre çalışmalıdır.

Güvenlik; korumalı kimlik doğrulama, parolaların yalnızca güçlü özetler olarak saklanması, her sunucu işleminde yetki kontrolü, giriş doğrulaması, istek hızının sınırlandırılması ve dosyalarla güvenli çalışmayı kapsar. Günlüğe parolalar, token’lar veya başka gizli bilgiler yazılmamalıdır.

Proje testlerle kapsanmalıdır. Birim testleri hesaplamaları ve geçiş kurallarını, entegrasyon testleri API ile veri tabanını kontrol eder; uçtan uca test ise talep oluşturmadan fırsatın başarıyla kapatılmasına kadar ana yolu izler. Satış sorumlusunun başkasına ait verileri açma veya yönetici işlemi yapma girişimleri ayrıca test edilmelidir.

Son sürüm Docker üzerinden çalışmalı; otomatik kod kontrollerine, veri tabanı geçişlerine, demo verilerine ve herkese açık test ortamına sahip olmalıdır. Depoda açık bir problem tanımı, mimari şeması, çalıştırma talimatı, API dokümantasyonu, test hesapları ve temel senaryoların görselleri bulunmalıdır.

Portföyde ekran sayısını değil, alınan kararları göstermek önemlidir. İyi bir açıklama CRM’in hangi sorunu çözdüğünü, veri modelinin neden böyle seçildiğini, rollerin nasıl uygulandığını, hangi senaryoların test edildiğini ve sistemin daha sonra nasıl geliştirilebileceğini anlatır. Bu, tüm kod ayrıntılı incelenmeden de geliştiricinin düşünme biçimini değerlendirmeyi sağlar.