SharePoint Intranet Tasarımı: Projeyi Kurulumdan Sonra Batıran Kararlar
SharePoint bir intranet değildir; intranet yapmaya yarayan bir kutudur. Kutu kurulduğunda kurumun bilgi düzeni kendiliğinden oluşmaz, oluşmayınca da suç platforma atılır. Projeyi asıl batıran şey lisans ya da sürüm değil, kurulumdan sonra verilen üç karardır: bilgi mimarisi, yetki modeli ve özelleştirmenin bakım maliyeti.
Bilgi mimarisi metadata disiplinine yaslanamaz
Her rehber aynı tavsiyeyi verir: içeriği anahtar kelimelerle etiketleyin, arama düzelsin. Tavsiye eksiktir, çünkü etiketi kimin gireceğini söylemez. Alanı zorunlu yaparsanız kullanıcı listedeki ilk seçeneği işaretleyip geçer, zorunlu yapmazsanız alan boş kalır. Her iki durumda da arama, etikete güvendiği ölçüde bozulur.
İşe yarayan yaklaşım metadata'nın büyük kısmını kullanıcıdan hiç istememektir. Belge hangi kitaplığa ve hangi takım alanına yüklendiyse departman, proje ve gizlilik seviyesi zaten bellidir; bunları kitaplık düzeyinde varsayılan sütun değeri olarak tanımlayın. Kullanıcıya kalan alan bir ya da iki tane olduğunda gerçekten doldurulur. Kalan her alan için de şu testi uygulayın: bu değeri kim, hangi işi yaparken girecek? Cevap yoksa alanı silin.
Yetkilendirme sadeliği bir tasarım kararıdır
Yetkiyi ayrıntılandırma isteği kurumsal projelerde her zaman gelir ve her zaman ilk aylarda zararsız görünür. Görünmeyen tarafı, her istisnanın kalıtımı kırması ve kırılan her kapsamın hem yönetim ekranını hem de aramanın güvenlik kırpmasını ağırlaştırmasıdır. Bir süre sonra kimsenin bir belgeye neden erişemediğini açıklayamadığı bir yapı ortaya çıkar, ve destek yükü tasarımdan tasarruf edilen zamanı fazlasıyla geri alır.
Az sayıda geniş grup kurun, istisnayı belge düzeyinde değil kitaplık düzeyinde tanımlayın. Gerçekten gizli olan içerik ayrı bir alana taşınır; aynı kitaplıkta yetkiyle saklanmaz.
Yayına geçiş kademeli olmalı
Kademeli yayını tek seferlik kurumsal lansmandan daha güvenilir buluyorum, çünkü ilk departmanın ilk haftasında çıkan sorunlar hep aynı türden oluyor: kimsenin öngörmediği bir doküman akışı, yanlış kurgulanmış bir onay adımı, menüde bulunamayan bir form. Bunları yüz kişiyle görmek, beş bin kişiyle görmekten ucuzdur.
Eğitim videosu ve SSS sayfası bu sorunların hiçbirini çözmez, yalnızca üstünü örter. Kullanıcı bir işi bulamıyorsa eksik olan bilgi değil, yerleşimdir. İlk pilot grubun aramalarını ve tıklamalarını izleyin; hangi terimle arayıp sonuç bulamadıklarını gösteren liste, yapılacaklar listesinin kendisidir.
Özelleştirmenin faturası ilk gün kesilmez
Kurumsal kimliğe uygun bir arayüz meşru bir istektir. Sorun, bu isteğin bedelinin proje bütçesinde tek seferlik bir kalem gibi görünmesidir. Oysa varsayılan arayüzün üstüne yazılan her CSS geçersiz kılması ve her özel bileşen, platform güncellendiğinde yeniden test edilecek bir borçtur. Microsoft arayüzü değiştirir, sizin seçicileriniz kırılır, kimse fark etmez ve intranet bir sabah bozuk görünür.
Bu yüzden özelleştirmeyi iki kümeye ayırın: renk, logo ve tipografi gibi platformun kendi tema mekanizmasından geçen şeyler ucuzdur, güncellemeyi genelde sağ salim atlatır. Yapıyı ve davranışı değiştiren bileşenler ise pahalıdır ve yıllık bakım bütçesine yazılmadan onaylanmamalıdır. Marka uyumunun büyük kısmı ilk kümeyle sağlanır; ikinci kümeye geçmeden önce o özelleştirmenin hangi kullanıcı sorununu çözdüğünü yazılı olarak isteyin.