29 Ağu 2025·8 dk
İç Duyurular ve Anketler İçin Web Uygulaması Nasıl Oluşturulur
İç duyurular ve anketler için bir web uygulamasını planlama, inşa etme ve dağıtma rehberi: roller, iş akışları, veri modeli, güvenlik ve devreye alma ipuçları.
İç duyurular ve anketler için bir web uygulamasını planlama, inşa etme ve dağıtma rehberi: roller, iş akışları, veri modeli, güvenlik ve devreye alma ipuçları.
Özellikleri veya araçları seçmeden önce, iç duyurular ve anketler web uygulamanız için “iyi”nin ne olduğunu netleştirin. Dar bir kapsam ilk sürümü basit tutar—ve değeri hızlıca kanıtlamayı kolaylaştırır.
Çoğu ekip çalışan anket aracı ve duyuru merkeziyi birkaç pratik nedenle kurar:
Çözmek istediğiniz ilk 3 problemi sade bir dille yazın. Bir cümlede açıklayamıyorsanız, kapsam muhtemelen çok geniştir.
Sistemi günlük olarak kullanacak kişileri belirleyin:
Burada açık olmak, daha sonra rol tabanlı erişim kontrolünü karmaşıklaştıracak “herkes her şeye ihtiyaç duyar” kararlarını önler.
İlk 60–90 günde beklediğiniz gerçek senaryoları listeleyin:
Bir kullanım senaryosu ölçülebilir bir sonuca bağlanmıyorsa, daha sonraki bir sürüme erteleyin.
Aylık inceleyeceğiniz küçük bir metrik seti seçin:
Bu metrikler “yayınladık”tan “işe yarıyor”a götürür ve daha sonra kullanıcılara spam atmadan bildirim/hatırlatma kararlarını yönlendirir.
Teknik yığını seçmeden önce, uygulamayı ilk günde kullanışlı kılan özellikleri kristalize edin. İç iletişim genellikle gönderiler zor bulunur, kötü hedeflenir veya anketler güvenilmez hissi verirse başarısız olur.
Mesajların okunmaz metin duvarlarına dönüşmemesi için zengin metin (başlıklar, linkler, madde listeleri) destekleyen temiz bir düzenleyiciyle başlayın.
Eklentiler (PDF, resim, politika belgeleri) için makul limitler ve virüs taraması ekleyin. Depolamayı öngörülebilir tutmak için alternatif olarak “dosyaya bağlantı” seçeneği sunun.
İçeriği yönetmeyi kolaylaştırın:
Anketler cevaplaması hızlı ve sonraki adımın ne olduğunu net göstermeli.
Tek tercihli ve çok tercihli soruları destekleyin ve anketlerin sonsuza kadar sürmemesi için kapanış tarihlerini zorunlu kılın.
İki kimlik modunu sunun:
Ayrıca anket başına sonuç görünürlüğünü belirleyin: oy sonrası anında, kapanış sonrası veya yalnızca yöneticiler için.
İyi bir iç duyurular uygulaması insanların önemli olanı görmesini sağlar:
Son olarak bilgilerin geri getirilebilir olmasını sağlayın: arama artı kategori, yazar, tarih ve etiket filtreleri. Çalışanlar geçen ayki politika güncellemesini 10 saniye içinde bulamazsa intranet akışına güvenmeyi bırakır.
Açık roller ve yönetişim, bir iç duyurular uygulamasını kullanışlı ve güvenilir kılar. Bunlar yoksa insanlar ya ihtiyaç duyduklarını yayımlayamaz ya da her şey gürültüye dönüşür.
Üç basit rol ile başlayın ve gerçek bir ihtiyaç olduğunda genişletin:
Varsayılan olarak rol tabanlı erişim kontrolü (RBAC) kullanın: izinler rollere atanır, roller kullanıcılara atanır. İzin listesi küçük ve eylem tabanlı olsun (ör. announcement.publish, poll.create, comment.moderate, category.manage).
Sonra istisnaları dikkatli ekleyin:
Şirketinizin iletişim tarzına uyan hafif kurallar belgeleyin:
Bu kararları basit ve görünür tutarsanız uygulama güvenilir ve yönetilmesi kolay kalır.
Açık bir iş akışı duyuruları zamanında ve güvenilir kılar, anketlerin “bunu kim paylaştı?” karışıklığına dönüşmesini önler. Hedef, yazarlar için yayımlamayı kolaylaştırmak, iletişim veya İK’ya ise kaliteyi koruyacak kadar kontrol vermektir.
Basit bir durum akışıyla başlayın:
Teslimi sürtüşmesiz hale getirin: inceleme ekranına bir kontrol listesi ekleyin (doğru kategori, kitle ayarlı, ekler kontrol edildi, kapsayıcı dil).
Her gönderi bir bekçi gerektirmez. Kategori ve kitle büyüklüğüne göre basit kurallar oluşturun:
Onayların takılıp kalmaması için zaman sınırlamaları ve eskalasyon ekleyin. Örnek: 24 saatte karar verilmezse yedek inceleyiciye yeniden ata; 48 saatte hâlâ bekliyorsa kategori sahibine bildir.
Her duyuru için bir sürüm geçmişi saklayın:
Bu, tarihler veya konumlar gibi bilgiler yayınlandıktan sonra değiştiğinde karışıklığı önler.
Anketler sıkı bir yaşam döngüsünden faydalanır:
İç uygulamalar bile koruma gerektirir. Bayraklanan içerikler için bir moderasyon kuyruğu, ayrıca gizle/göster, yorumları kilitleme (destekleniyorsa) ve kim neyi, ne zaman değiştirdiğinin aranabilir denetim izi gibi temel kontroller sağlayın.
Basit bir veri modeli uygulamanızı inşa etmeyi ve daha sonra değiştirmeyi kolay tutar. Duyuruları yayımlamak, anketleri yürütmek ve etkileşimi anlamak için gereken minimum varlıklarla başlayın—sonra gerçek bir kullanım durumu gerektirdiğinde karmaşıklık ekleyin.
Announcement
En azından duyuruları şu alanlarla modelleyin: title, body, author, audience, tags, status (draft/scheduled/published/archived), publish_at ve expires_at.
“Audience”ı esnek tutun. Bölümleri sert kodlamak yerine grupları hedefleyebilen bir kural yapısı düşünün (ör. All, Location: Berlin, Team: Support). Bu, gelecekteki veri göçlerini azaltır.
Poll
Bir anketin ihtiyacı: question, options, audience, bir anonymity flag, ayrıca open/close dates.
Anketin bir duyuruya ait olup olmayacağına erken karar verin (yaygın bir desen). Eğer “duyuru + anket” gönderileri bekliyorsanız, Poll üzerinde basit bir announcement_id yeterlidir.
Okundu bilgileri genellikle isteğe bağlıdır. Uygularsanız, kullanıcı başına bir viewed_at zaman damgası saklayın (isteğe bağlı olarak “first_viewed_at” ve “last_viewed_at”). Gizlilik konusunda açık olun: okuma takibi gözetim hissi yaratabilir, bu yüzden erişimi sınırlayın (ör. yöneticiler yalnızca toplu verileri görsün; belirli roller ise per-user verileri göremesin) ve saklama politikası ekleyin.
Votes için veritabanı seviyesinde “her kullanıcı için anket başına bir oy” kuralını zorlayın (benzersiz kısıtlama poll_id + user_id). Çoklu seçim destekliyorsanız kuralı “her seçenek için bir oy” olarak değiştirin (benzersiz poll_id + user_id + option_id) ve izin verilen davranışı tanımlayan bir bayrağı Poll üzerinde saklayın.
Basit bir denetim günlüğü bile (kim yayımladı/düzenledi/kapattı bir anketi) güven ve moderasyon konusunda yardımcı olur, modeli karmaşıklaştırmadan.
İyi UX, iç duyurular uygulaması için çoğunlukla sürtüşmeyi azaltmaktır: çalışanlar önemli olanı saniyeler içinde bulmalı, iletişimciler ise düzen hakkında endişe etmeden yayımlayabilmelidir.
Birincil gezinimi öngörülebilir ve yüzeysel tutun:
Yapışkan bir üst çubukta arama ve “Yeni” göstergesi, geri dönen kullanıcıların hemen neyin değiştiğini görmesine yardımcı olur.
Her duyuruyu okunması kolay bir kart olarak ele alın:
Kısa bir önizleme ve akışta uzun metinlerden kaçınmak için “Devamını oku” genişletmesi ekleyin.
Anketler hızlı ve kesin hissettirmeli:
Güveni sağlamak için temelleri doğru yapın: yeterli renk kontrastı, tam klavye desteği (tab sırası, odak durumları) ve okunabilir tipografi (mantıklı satır uzunluğu, net hiyerarşi). Bu küçük seçimler uygulamayı herkes için, mobilde ve gürültülü çalışma ortamlarında bile kullanılabilir kılar.
Takımınızın yayınlayıp sürdürebileceği bir yığın seçin—en moda kombinasyon değil. İç duyurular ve anketler CRUD tarzı bir uygulamadır, bazı ekstralar (roller, moderasyon, bildirimler) dışında, mimariyi basit ve öngörülebilir tutmak en iyi sonucu verir.
Çoğu ekip için React veya Vue güvenli seçimdir, eğer zaten kullanıyorsanız. Maksimum sadelik isterseniz sunucu tarafı render (Rails/Django/.NET MVC) hareketli parçaları azaltır ve izinli ekranları anlamayı kolaylaştırır.
Kural: anket oy kullanma ve temel filtreleme dışındaki çok dinamik etkileşimlere ihtiyacınız yoksa, sunucu tarafı render genellikle yeterlidir.
Arka uç yetkilendirme, doğrulama ve denetlenebilirliği basit yapmalı. İyi seçenekler:
Burada bir “modüler monolit” (Announcements, Polls, Admin gibi net modüllerle tek dağıtım) genellikle mikroservislerden daha iyidir.
Eğer tüm boru hattınızı yeniden kurmadan hızlı bir dahili araç göndermek istiyorsanız, Koder.ai gibi bir kod-jenerasyon platformu pratik bir ara yol olabilir: duyurular akışını, anketleri, RBAC’ı ve yönetici panosunu sohbette tarif edersiniz, ardından üretilen React ön yüzü ve Go + PostgreSQL arka ucu üzerinde yineleme yaparsınız. Bu, İK/iletşim ekiplerine hızlı bir pilot sunmak için özellikle faydalıdır ve kodu daha sonra dışa aktarma seçeneği bırakır.
Kullanıcılar, roller, duyurular, anket soruları, seçenekler ve oylar gibi ilişkilisel veriler için PostgreSQL kullanın. Sadece önbellekleme, hız sınırlama veya arka plan iş koordinasyonu gerektiğinde Redis ekleyin.
API için REST öngörülebilir, okunabilir uç noktalarla iyi gider; birçok farklı istemci ve karmaşık ekran verileri beklentiniz varsa GraphQL yardımcı olabilir. Her iki durumda da dokümante edin ve adlandırmayı tutarlı tutun ki ön yüz ve yönetici araçları uyumsuz olmasın.
Güvenlik kararları sonra değiştirmesi zor olduğu için, bazı net kuralları başta belirlemek faydalıdır.
Şirketiniz zaten bir kimlik sağlayıcı (Okta, Azure AD, Google Workspace) kullanıyorsa OIDC (en yaygın) veya SAML ile SSO tercih edin. Bu parola riskini azaltır, çalışan çıkışlarını otomatikleştirir ve insanların zaten kullandıkları hesapla giriş yapmasını sağlar.
SSO yoksa e-posta/şifre kullanın ve standart korumalar ekleyin: güçlü hashing, hız sınırlama, hesap kilitleme ve opsiyonel MFA. “Şifre unutma” akışını basit ve güvenli tutun.
Erken roller tanımlayın (örneğin: Employee, Editor, Comms Admin, IT Admin). Ardından rol tabanlı erişim kontrolünü (RBAC) her yerde uygulayın—sadece UI’da değil. Her API uç noktası ve yönetici işlemi izinleri kontrol etsin (announcement oluştur, yayımla, sabitle, anket oluştur, sonuçları görüntüle, veriyi dışa aktar, kullanıcıları yönet vb.).
Pratik bir kural: bir kullanıcı API’yi doğrudan çağırarak bir şeyi yapamıyorsa, uygulamadan da yapamaz.
Anketler sıklıkla hassas konulara dokunur. Anonim anketler destekleyin; yanıtlar kullanıcı tanımlayıcı olmadan saklansın ve “anonim”in ne anlama geldiğini açıkça belirtin (ör. yöneticiler kimin oy kullandığını göremez).
Kişisel veriyi en aza indirin: genellikle ad, e-posta, bölüm ve rol yeterlidir (mümkünse SSO’dan çekin). Saklama kuralları belirleyin (ör. ham anket yanıtlarını 12 ay sonra silmek, yalnızca toplu sayıları tutmak).
Önemli olaylar için denetim izi tutun: kim bir duyuruyu yayımladı/düzenledi/sildi, kim bir anketi erken kapattı, kim izinleri değiştirdi ve ne zaman. Günlükleri yönetici alanında aranabilir yapın ve düzenlemelere karşı koruyun.
Bildirimler ilgili ve saygılı olduğunda ancak işe yarar. İç duyurular ve anketler için “yüksek sinyal, düşük gürültü” hedefleyin: insanların abone olduğu şeyler hakkında bilgilendirin, geri kalanını özetleyin ve bir kere işlem yapınca durun.
Uygulama içi bildirimler birisi zaten araçtayken farkındalık için en iyi sonucu verir. Kullanıcının abone olduğu bir kategoride yeni bir duyuru olduğunda küçük, kapatılabilir bir bildirim gönderin (ör. “BT Güncellemeleri”). Öğeyi doğrudan açan link gösterin ve kategoriyi belirtin ki alaka kolayca değerlendirilebilsin.
E-posta özetleri gelen kutusunu doldurmamak için idealdir. Yeni duyuruları ve açık anketleri birleştiren günlük/haftalık özetler sunun; tek gönderi yerine küme halinde gönderin. Hızlı işlemler (“Görüntüle”, “Oy Ver”) ekleyin.
Anket hatırlatmaları zorunlu olmamalı:
İnsanların ilgiyi ayarlayabilmesi benimsemeyi artırır:
Basit bir /settings/notifications sayfası, herhangi bir karmaşık algoritmadan daha fazla benimsemeyi sağlar.
Raporlama, iç duyurular uygulamanızı bir paylaşım panosundan karar destek aracına çevirir. Analitiği, insanların ne gördüğünü, neyle etkileşime girdiğini ve hangi mesajların hedefe ulaşmadığını gösteren karar odaklı tutun.
İletişim yöneticileri için yönetici panosunda her gönderi için basit bir “duyuru skor kartı”yla başlayın:
Bu metrikleri yayın tarihi, hedef kitle ve kanal bağlamında gösterin (ana sayfa, e-posta, Slack/Teams köprüsü varsa). Benzer gönderileri karşılaştırmayı kolaylaştırır.
Çalışan anket aracı için katılım ve açıklık odaklı olun:
Anonim anketlerde sonuçlar toplu tutulmalı ve küçük grup analizleri kimlikleri ortaya çıkarabileceğinden kaçınılmalıdır.
Bölümlenmiş raporlar (bölüm veya konum bazında) hedeflemeyi iyileştirebilir, ancak korumalar ekleyin:
CSV dışa aktarma yöneticiler için kullanışlıdır. Dışa aktarmayı rol tabanlı erişimle sınırlandırın ve dışa aktarma eylemlerini denetim günlüklerine kaydedin ki yönetişim açık olsun.
İç duyurular uygulamasını göndermek sadece “çalışıyor mu?” değil; doğru kişiler için, doğru görünürlükle, her seferinde çalışıyor mu? sorusudur. Kısa, tekrarlanabilir bir kontrol listesi yanlış hedeflenmiş gönderilerden veya anketlerden sizi kurtarır.
Gerçek kullanım senaryolarına odaklanın, sadece mutlu yollar değil:
İçeriği bir ürün parçası olarak ele alın:
Gerçekçi veri ve test hesaplarıyla bir staging ortamı kullanın. Prodüksiyon yayını için plan yapın:
Koder.ai gibi yönetilen üretim araçları kullanıyorsanız aynı dağıtım disiplinini önceliklendirin: önce staging, net değişiklik takibi ve geri alma yolu (hızla yineleme yaparken anlık yedek/rollback çok yardımcı olur).
İlk günden itibaren hafif izleme kurun:
Seçmeniz gereken kural: sunucuları değil, kullanıcı yolculuğunu izleyin.
İyi inşa edilmiş bir duyurular ve anketler uygulaması bile insanlar ona güvenmez, hatırlamaz veya açmaya değer görmezse başarısız olur. Benimseme “lansman günü”nden çok düzenli alışkanlıklar yaratmakla ilgilidir: öngörülebilir gönderiler, açık sahiplik ve hafif eğitim.
Farklı rolleri temsil eden bir pilot grup ile başlayın (İK/iletişim, yöneticiler, saha çalışanları). 2–3 hafta çalışın ve net bir kontrol listesiyle: duyuruları hızlıca bulabiliyorlar mı, bir dakikadan kısa sürede anketlere oy verebiliyorlar mı ve beklentileri anlıyorlar mı?
Geri bildirimi iki şekilde toplayın: ana eylemler sonrası kısa bir uygulama içi anket ve pilot şampiyonlarla haftalık 15 dakikalık kontrol. Sonra aşama aşama yayın (ör. bir departman bir seferde) ve öğrendiklerinizi kategori, varsayılanlar ve bildirim ayarlarını güncellemek için kullanın.
Eğitim materyallerini kısa ve pratik tutun:
İçerik tutarlı olduğunda benimseme artar. Gönderi yönergeleri (ton, uzunluk, ne zaman anket kullanılacağı vs.) tanımlayın, kategori sahipleri atayın (İK, BT, Tesis) ve bir yayın ritmi belirleyin (ör. haftalık derleme + acil gönderiler gerektiği zaman). Yönetici alanınız varsa kategori sahiplerinin isimlerini gösterin ki insanlar kime başvuracaklarını bilsin.
Uygulamayı bir ürün gibi yönetin: bir backlog tutun, veriye (görüntülemeler, anket tamamlama oranları, okuma süresi) ve nitel geri bildirime dayalı önceliklendirin, ve küçük iyileştirmeleri düzenli olarak yayınlayın. “Tüm şirket” gönderileri görmezden geliniyorsa daha sıkı hedefleme deneyin; anketler düşük tamamlama alıyorsa daha kısa yapın veya amacını ve kapanış tarihini netleştirin.
Önce çözmek istediğiniz en önemli 3 problemi yazın (ör. kritik güncellemelerin kaçırılması, dağılan kanallar, yavaş geri bildirim). Ardından bu problemlere uçtan uca destek veren dar bir ilk sürüm tanımlayın: yayımla → hedefle → bildir → ölç.
Pratik bir kapsam: “duyurular akışı + basit anketler + temel yönetici kontrolleri” ve açık başarı ölçütleri.
Tipik ana kullanıcılar şunlardır:
Her rolün haftalık olarak yapması gerekenleri yazın; geri kalan özellikler “sonra” olarak kalmalı.
Duyurular için önceliklendirin:
Çalışanlar bilgiyi hızlıca bulup güvenmezse benimseme durur.
Anketleri hızlı, açık ve zaman sınırlı tutun:
Ayrıca veritabanında “kullanıcı başına bir oy” (çoklu seçimde gerekirse seçenek başına bir oy) kuralını uygulayın.
RBAC (rol tabanlı erişim kontrolü) kullanın; küçük, eylem-tabanlı izinler tutun (ör. announcement.publish, poll.create, comment.moderate). Aşağıdaki kısıtlamaları ekleyin:
Kaliteyi yüksek tutup süreci yavaşlatmamak için basit bir iş akışı kullanın:
İnceleme ekranında kontrol listesi (hedef kitle ayarlı mı, kategori doğru mu, ekler doğrulandı mı, kapsayıcı dil) ve onay gecikirse eskalasyon ekleyin.
Minimum düzeyde varlıklarla başlayın:
Mümkünse SSO kullanın (OIDC/SAML: Okta, Azure AD, Google Workspace). Kullanılamıyorsa e-posta/şifre ile:
Gizlilik için minimum profil alanı toplayın, gerçekten anonim anket desteği sağlayın (kullanıcı tanımlayıcı olmadan) ve saklama süresi tanımlayın (ör. ham yanıtları 12 ay sonra silmek, yalnızca toplu sonuçları saklamak).
“Yüksek sinyal, düşük gürültü” hedefleyin:
Kullanıcılara /settings/notifications içinde kategori takipleri, sıklık, sessize alma ve sessiz saatler seçenekleri verin.
Karar almaya yardımcı olacak metriklere odaklanın:
Bölümlenmiş raporlama için gizlilik korumaları (ör. en az 10+ yanıt eşiği) ekleyin. Dışa aktarma eylemlerini denetim günlüklerinde kaydedin ve analizleri hedefleme ve içerik kalitesini iyileştirmek için kullanın.
İzinleri sadece UI’da değil, her API uç noktasında uygulayın.
announcement_id ile ilişkilendirilebilir)poll_id + user_id), çoklu seçim için gerekirse poll_id + user_id + option_id“Audience” esnek tutun (kurallar/gruplar) böylece sık şema göçleri olmaz.