Çok Rollü Bir Platform İçin Keşif Aşaması Ne Sağlamalı?

Çok rollü bir platformun keşfi şunları teslim etmelidir: her rolün ne görebildiğini ve ne yapabildiğini gösteren bir rol haritası, rollerin işi birbirine devrettiği yolculuklar, yetki modeli, roller arasındaki çatışmalar ve en az iki role uçtan uca hizmet eden bir ilk sürüm. Bundan azı, entegrasyon sorunlarının geliştirme sırasında ortaya çıkması demektir.

Çok rollü platformlar zordur; çünkü karmaşıklık rollerin sayısıyla değil aralarındaki etkileşimlerle büyür. Dört rol, dört katından çok daha fazla tasarım işi üretir.

Önemli noktalar

• Zor kısım devirlerdir: Her biri, tek rollü tasarımın gizlediği durum, bildirim ve yetki sorularını doğurur.
• Diğerlerinin önünü açan rolle yayına girin: En kalabalık rolle başlamak genellikle boş ekranlar üretir.
• Yetkileri erken modelleyin: Rol tabanlı erişimi sonradan eklemek mevcut en pahalı değişikliklerdendir.
• Çatışmaları adıyla söyleyin: İki rolün bağdaşmaz şeyler istediği yer bir tasarım detayı değil bir iş kararıdır.

Her rolün ne görebildiğini ve ne yapabildiğini haritalayın

Bir tabloyla başlayın: her rol için neyi başarması gerektiği, hangi bilgiyi görebileceği, hangi eylemleri yapabileceği ve asla neyi görmemesi gerektiği. En sık boş bırakılan ve en sık soruna yol açan son sütundur.

Sınırlar konusunda kesin olun. Kendi ekibini gören bir amir ile tüm ekipleri gören farklıdır. Kendi siparişlerini gören bir müşteri ile kendi kurumundaki herkesin siparişlerini gören bir satın alma yöneticisi farklıdır. Bu ayrımlar veri modelini belirler ve sonradan değiştirmek pahalıdır.

İlk anda kimsenin aklına gelmeyen rolleri de ekleyin: bir kullanıcı adına işlem yapması gereken destek personeli, sistemi yapılandıran yöneticiler ve her şeye salt okunur erişime ihtiyaç duyan denetçiler.

Devirleri açıkça tasarlayın

İşin roller arasında geçtiği her nokta aynı soruları doğurur ve keşif her birini yazılı olarak yanıtlamalıdır: Kayıt hangi durumda? Kime, nasıl ve ne kadar hızlı bildirim gidiyor? Gönderen rol sonrasında hâlâ neyi değiştirebilir? Alan rol reddederse veya hiçbir şey yapmazsa ne olur? Beklerken kim görebilir?

Uygulamaya bırakıldığında kusura dönüşen sorular bunlardır. Rol başına ekranları haritalayan ama aralarındaki geçişleri haritalamayan bir keşif, kolay yarısını belgelemiştir.

Her ortak kaydın sahibini belirleyin

Birkaç rol aynı kayıtla etkileşiyorsa her aşamada sahibinin kim olduğuna ve bir hatayı kimin düzeltebileceğine karar verin.

Bilgilendirici olanlar zor durumlardır. Müşteri bilgi gönderiyor ve personel bir hata fark ediyorsa personel düzeltebilir mi yoksa müşteri mi düzeltmelidir? İki rol aynı alanı güncellerse hangisi kazanır? Bir kayıt onay için kilitliyse meşru ve acil bir değişikliğe ne olur?

Bunların her biri operasyonel sonuçları olan bir iş kuralıdır ve hiçbirine bir geliştirici karar veremez. Bunları yüzeye çıkaran keşif işini yapıyordur; bunları geliştirmeye bırakan keşif maliyeti erteliyordur.

Roller arasındaki çatışmaları adıyla söyleyin

Roller bağdaşan şeyler istemez. Operasyon hız ister; uyum kontrol ister. Satış esnek fiyat ister; finans tutarlılık ister. Saha personeli daha az zorunlu alan ister; yönetim eksiksiz veri ister.

Uyumlu bir tablo sunan bir keşif yeterince kişiyle konuşmamıştır. Yararlı çıktı her gerilimi adıyla söyler, platformun onu nasıl çözdüğünü belirtir ve kimin karar verdiğini kaydeder. Çözülmemiş çatışmalar kaybolmaz — yayından sonra kendini göz ardı edilmiş hisseden grubun değişiklik talepleri olarak geri döner.

Bu kısıtların düzenlemeye tabi ortamlarda nasıl sıkılaştığı için düzenlemeye tabi bir iş akışı için geliştirme iş ortağı nasıl seçilir yazısına bakın.

İlk rolü bilinçli seçin

İçgüdü en büyük gruba yayına girmektir. Bu genellikle içinde hiçbir şey olmayan bir sistem üretir; çünkü o kullanıcıların ihtiyaç duyduğu kayıtları başkası oluşturur.

Bunun yerine işi diğer herkesin önünü açan rolle yayına girin — diğerlerinin bağlı olduğu kayıtları oluşturan rolle. İlk günden kullanılabilir veri üretir ve ikinci rol geldiğinde ona çalışacak gerçek bir şey verir.

İlk sürüm yine de en az iki role uçtan uca hizmet etmelidir; çünkü tek rollü bir sürüm devirleri test etmez ki risk asıl orada durur.

Yetkileri ilk ekrandan önce modelleyin

Yetki yapısı veri modelini şekillendirir. Her kullanıcının her şeyi görebildiğini varsayan bir sisteme rol tabanlı erişimi sonradan eklemek her ekranda ve her sorguda yeniden çalışmayı zorunlu kılar.

Yetkilerin rol tabanlı mı, nitelik tabanlı mı yoksa kuruma göre hiyerarşik mi olduğuna ve kullanıcıların birden fazla rol taşıyıp taşıyamayacağına erken karar verin. Modeli en zor gerçek durumunuza karşı — aynı zamanda onaycı olan yönetici, geçici erişimi olan yüklenici — uygulandıktan sonra değil önce test edin.

İlgili rehberler

• Çok Rollü Bir Platform İçin Keşif Aşaması Ne Sağlamalı? rehberinin yanında İş Gücü Yönetimi Uygulaması: Mobil, Web ve Yönetim Kapsamı.
• Çok Rollü Bir Platform İçin Keşif Aşaması Ne Sağlamalı? rehberinin yanında İş Gücü Görünürlüğü: Faydalar, Riskler ve Sorumlu Metrikler.

Çok Rollü Bir Platform İçin Keşif Aşaması Ne Sağlamalı? rehberinden doğan çalışma; ürün stratejisi, tasarım, geliştirme veya entegrasyon desteği gerektiren somut bir girişime dönüşürse Sektörel Platformunuzu Konuşalım.