Şirketin ürün ekipleri forumu: Product Day programı

Ürün ekipleri forumu portföyü, ekipler arası bağımlılıkları ve yönetim kararlarını birbirine bağlar. Product Day programını, rolleri, materyal hazırlığını ve etkinlik sonrası çalışmayı ele alıyoruz.

Şirketin ürün ekipleri forumu ya da iç Product Day, artık tek bir ekibin toplantılarına sığmayan konular için gereklidir. Burada katılımcılar portföyün genel resmini oluşturur, ekipler arası bağımlılıkları bulur, kısıtlamaları tartışır ve kararları kayda geçirir. Böyle bir etkinliğin değeri çalışma çıktılarıyla belirlenir: portföy haritası, bağımlılık sicili, karar günlüğü ve net bir devam planı.

Biz Aventura olarak forumun etkinlik kurgusundan sorumluyuz: program, senaryo, katılımcı rotaları, mekân, teknik altyapı ve sonuçların kayda geçirilmesi. Ürün verileri, öncelikler ve karar alma yetkisi müşteride kalır. Bu ayrım, konuşmacılar ve salonlar seçilmeden önce belirlenmelidir.

Bir şirket ne zaman ürün ekipleri forumuna ihtiyaç duyar?

Kısaca: Forum, birkaç ekibin ortak platformlara, verilere, kanallara, uzmanlara veya yönetim kararlarına bağlı olduğu durumlarda gereklidir. Olağan bir senkronizasyon yetersiz kalır: her ekip kendi bölümünü görür, öncelik ve kaynak çatışmaları ise birimler arasında kalır.

İlk belirti: bir ekibin kararları diğerleri için sonuçlar doğurur. Yeni bir sürüm, platformda iyileştirme, verilere erişim, hukuki onay, satış desteği veya ortak müşteri yolculuğunda değişiklik gerektirir. Bu bağlantılar farklı takvimlerde tartışılırsa, genel tablo dağılır.

İkinci belirti: yönetim, bir dizi ayrı raporun ardından girişimleri karşılaştırmak zorunda kalır. Ekipler kendi yol haritalarını ve metriklerini gösterir, ancak farklı formatlar kullanır. Sonuç olarak zaman, verilerin çevrilmesi ve netleştirilmesiyle geçer. Portföy seçimi, mantığını katılımcıların daha sonra öğreneceği kapalı bir toplantıya ertelenir.

Üçüncü belirti: anlaşmazlık, ekipler üstü düzeyde yetki gerektirir. Ekip, bir hipotezi veya görev sırasını kendi başına netleştirebilir. Ortak bir kaynağın yeniden dağıtılması, bir girişimin durdurulması veya taahhütlerin değiştirilmesi konusunu ilgili yönetici çözmelidir. GOV.UK'ın çevik teslimat ilkeleri, kararların zamanında, uygun düzeyde ve doğru kişilerin katılımıyla alınmasını önerir. Forum için bu faydalı bir sınırdır: programa, olağan bir ekip toplantısıyla kapatılamayacak konular girer.

Müşterinin ortak bir hedefi, seçim kriterleri ve karar verme yetkisine sahip kişileri yoksa forum erkendir. Büyük bir salon, hazırlanmamış verileri düzeltmez. Önce çelişkileri toplamak ve hangilerinin ortak çalışma gerektirdiğini belirlemek gerekir.

Demo Day, hackathon ve stratejik oturumla sınır

Öz: Etkinliğin adı formatı belirlemez. Demo Day hazırlanmış sonuçları gösterir, hackathon bir çözüm oluşturmak için zaman verir, stratejik oturum yön seçer, forum ise mevcut portföyü, ekipleri, kısıtları ve sonraki adımları birbirine bağlar.

Bir Product Day demo, çalışma oturumu ve yönetici konuşmasını içerebilir. Ağırlık merkezi yine de tek olmalıdır. Aksi halde katılımcılar farklı vaatler içeren uzun bir programla karşılaşır: birilerinden işlerini göstermeleri istenir, diğerlerinden yeni bir şey düşünmeleri, üçüncülerden ise kaynakları onaylamaları.

Scrum'da Sprint Review, sonucu doğrulamak ve sonraki uyarlamayı tartışmak için bir çalışma oturumu olarak tanımlanır. Bunun bir sunumla sınırlandırılması önerilmez. Bu ilke forum için de faydalıdır: demo, bir soru veya karar için malzeme sağlamalıdır, aksi halde ekranlar geçidine dönüşür.

Ana görev, hazırlanan projelerin gösterilmesi ve her biri hakkında karar verilmesiyle bitiyorsa, ayrı bir kurumsal proje demo günü kullanmak daha iyidir. Uygulamaları ve belgeleri karşılaştıran profesyonel topluluk için işletme teknologları forumunun nasıl yapılandırıldığına bakmak faydalıdır. Ürün forumu çalışma konusuyla ayrılır: kalıcı çapraz fonksiyonel ekipleri, ürün sinyallerini, yol haritalarını ve ortak kısıtları birbirine bağlar.

Gün sonuna kadar alınması gereken kararlar

Çıktı: Programı birleştirmeden önce, ekiplerin bir araya gelmesine neden olan kararların kaydedilmesi gerekir. Her soru için beklenen sonuç düzeyi tanımlanır: nihai seçim, öneri, eksik veri listesi, atanmış eylem veya eskalasyon.

«Ekipleri senkronize etmek» ifadesi, senaryo yazarına işe yarar bir görev vermez. Bunu somut sorulara bölmek gerekir. Hangi girişimler ortak kaynak gerektirir? İki ekip nerede birbiriyle uyumsuz teslim tarihleri verdi? Hangi bağımlılıklar kritik risk oluşturur? Yönetimin hangi konularda seçimi onaylaması gerekiyor?

Karar haritasıyla başlıyoruz. İçinde tartışma konusu, hazırlık sahibi, katılımcılar, onay yetkisi olan kişi ve forumun kabul edilebilir sonucu bulunur. Eğer karar salonda alınamıyorsa, forumun bir sonraki adım için neyi hazırlayacağını dürüstçe belirlemek gerekir.

Soruları dört gruba ayırmak uygundur:

1. Ekip kendi başına karar verir ve sonucu diğerlerine bildirir.
2. Birkaç ekip ortak eylem üzerinde anlaşır.
3. Yönetici önceliği onaylar veya çatışmayı giderir.
4. Soru ek veri gerektirir ve devamı için bir sahip atanır.

Her tartışma aynı gün içinde bir yanıtla sonuçlanmak zorunda değildir. Bazen nitelikli sonuç, hangi verilerin eksik olduğunu, bunları kimin topladığını ve katılımcıların seçime ne zaman döneceğini kaydetmektir. Bu, maliyet, riskler ve yükümlülükler hakkında bilgi olmadan yapılan resmi oylamadan daha faydalıdır.

Atlassian'ın karar alma konusundaki materyalinde, rollerin belirsiz kaldığı durumlarda tekrarlanan tartışmalar sorunu anlatılır. Forum için çıkarım açıktır: katılımcılar nerede katkı sağladıklarını, nerede öneri oluşturduklarını ve sonucu kimin onayladığını bilmelidir. Oylama mekaniği hedef kitle sinyalini toplar, ancak karar alma hakkının yerini almaz.

Katılımcı yapısı ve roller

Kısaca: Katılımcılar, çözüme katkılarına göre seçilir. Forumda ürün bağlamı, teknik kısıtlar, kullanıcı verileri, ticari yükümlülükler ve ortak kaynakların sahiplerine ve bir sonraki adımı onaylayabilecek yöneticilere ihtiyaç vardır.

Yalnızca ürün yöneticileri için bir forum eksik bir tablo sunar. Ürün kararı mimariye, araştırmaya, analitiğe, desteğe, satışa, pazarlamaya, operasyonlara, finansa veya yasal kısıtlara bağlı olabilir. GOV.UK Service Manual, dijital hizmetin çalışmasını disiplinler arası bir ekibe ve kararları gerçekten alan kişilerin katılımına bağlar.

Katılımcı yapısı gündeme bağlıdır. Evrensel bir pozisyon listesi yoktur. Programın her bloğunu ele alıp üç soruya yanıt vermenizi öneriyoruz: girdi verilerini kim doğrular, kararın sonuçlarını kim görür ve bir sonraki adım için kimin yetkisi vardır.

İK ve iç iletişim, hedef kitleyi toplamaya, amacı açıklamaya ve sonuçları katılımcılara geri döndürmeye yardımcı olur. Ürün kararlarının sahiplerinin yerini almamalıdırlar. Etkinlik ekibi de CPO veya portföy sahibi adına öncelikleri belirlemez.

Her kararın sahibini ve forumun kendi sahibini ayrı ayrı atarız. İlki sorunun içeriğinden sorumludur. İkincisi programı, materyal sürümlerini, erişimleri ve değişiklikleri bir araya getirir. Bu ayrım, organizasyonel görevlerin ve ürün çıkarımlarının aşırı yüklenmiş tek bir rolde birleşmesi riskini azaltır.

Program, moderasyon ve üretim kararlarına dair analizleri Aventura'nın Telegram kanalında paylaşıyoruz.

Forumdan önce ekiplerden ne toplanmalı?

Çalışma prensibi: Her ekip keyfi bir sunum değil, karşılaştırılabilir bir pre-read hazırlar. İçinde sorun veya fırsat, hedef kitle, veriler, beklenen sonuç, kısıtlar, bağımlılıklar ve diğer ekiplere ya da yönetime yönelik tek ve somut bir talep yer almalıdır.

Materyaller sahne provasından önce toplanmalıdır. Bir ekip metrikler ve seçenekler getirirken, ikincisi sürüm geçmişini, üçüncüsü ise reklam filmini getirirse, bunları karşılaştırmak imkânsızdır. Son haftadaki düzeltmeler, ortak bir sorunun yokluğunu telafi edemez.

Ekip pasaportunu bir veya birkaç kısa sayfa halinde alıyoruz:

• ürün hedefi veya sorunu;
• kullanıcı veya iç müşteri;
• sinyal: metrik, araştırma, geri bildirim veya taahhüt;
• daha önce alınan karar ve değerlendirilen alternatifler;
• beklenen sonuç;
• risk veya belirsizlik;
• ekiplere, platformlara ve ortak işlevlere bağımlılıklar;
• foruma yönelik somut bir talep;
• materyallerin izin verilen açıklama düzeyi.

Böyle bir pakette Roadmap, hedefleri, girişimleri ve beklenen sonuçları birbirine bağlayan bir araç olarak gereklidir. Product School ve Aha!, yol haritasını genel resmi aktarmanın ve stratejiyi işle ilişkilendirmenin bir yolu olarak tanımlar. Forum için sürüm takvimi yeterli değildir. Katılımcıların bahsin gerekçesini, beklenen değişimi, kısıtı ve seçim noktasını anlaması gerekir.

Önceden okunabilecek verileri pre-read'e taşıyoruz. GitLab'ın kamuya açık handbook'u, live-doc meetings'i ve senkron konuşmanın ortak dokümantasyonla bağlantısını açıklar. Bir şirketin sürecini kopyalamayı önermiyoruz. Pratik ilke faydalıdır: salondaki zamanı sorulara, çatışmalara ve kararın düzenlenmesine ayırmak daha iyidir.

Materyaller, hedef kitle, akışlar ve kısıtlar listesini kurumsal forum için teknik şartname içinde sabitlemek uygundur. Buna dayanarak programı, mekânı, ekipmanı, navigasyonu ve ekip kompozisyonunu hesaplıyoruz.

Product Day programının mimarisi

Kısaca: Program genel çerçeveden çalışma oturumlarına ve ortak tespitlere doğru ilerler. Katılımcı önce hedefleri ve seçim kurallarını anlar, ardından kendi track'i ile çalışır, sonrasında kararları, sahiplerini ve devamını görür.

Biz Aventura olarak forum ve seminer organizasyonunu katılımcıların eylemleri etrafında kurarız. Önce insanların genel bağlamı nerede dinlediğini, girişimleri karşılaştırdığını, bağımlılıkları ele aldığını, demolara baktığını ve kararlar aldığını belirleriz. Ardından salonları, sahneyi, ekranları, ağı ve geçiş programını seçeriz.

Çalışma rotası şöyle görünebilir:

1. Yönetimden genel çerçeve: hedefler, seçim kriterleri, kısıtlar ve günün soruları.
2. Kısa portföy özeti: girişimlerin ve bağlantıların genel haritası.
3. Tematik incelemeler: ürün bahisleri, kullanıcı sinyalleri, teknik kısıtlar.
4. Dependency clinic: kritik ekipler arası bağlantılarla çalışma.
5. Canlı gösterimin tezi doğruladığı konularda demolar.
6. Hassas kararlar için kapalı oturum, gerekliyse.
7. Ortak karar noktası: nelerin kabul edildiği, nelerin veri gerektirdiği, kimin çalışmaya devam ettiği.

Ortak sahne, herkesin aynı şekilde duyması gereken bağlam için gereklidir. Detaylı çalışma daha iyi küçük odalarda veya çalışma masalarında yürür. Final, katılımcıları yeniden bir araya getirir, ancak tüm sunumları tekrarlamak için değil. Moderatör genel resimdeki değişiklikleri gösterir ve sonraki adımları belirtir.

Paralel akışlar bir rota gerektirir. Her katılımcının anlaşılır bir seçim mantığı olmalı; organizatörlerin ise oda kapasitesi, geçiş süresi ve sonucu ortak günlüğe geri döndürme yöntemi olmalı. Bir grubun çalışması final tespitine girmezse, yerel bir konuşma olarak kalır.

Geniş kapsamlı bir iş etkinliği için içeriği, lojistiği ve teknik prodüksiyonu iş etkinlikleri organizasyonu içinde birleştiririz. Müşteri bu süreçte ürün gündeminin içerik sahipliğini korur ve tüm sonuçları onaylar.

Bir dizi rapor yerine çalışma formatları

Kısaca: Rapor, hızlı bir şekilde ortak bir bağlam oluşturduğunda haklıdır. Karşılaştırma, risk analizi ve eylemlerin koordinasyonu için çalışma formatlarına ihtiyaç vardır: yuvarlak masa, klinik, karar incelemesi, portföy haritası, başarısızlık incelemesi veya bir belge üzerinde ortak çalışma.

Bir dizi sunum, program için uygundur, ancak ekiplerin çalışmasını pek değiştirmez. Her konuşmacı kendi hikayesini gösterir, sorular azalır ve konuşmalar arasındaki bağlantılar dinleyicilerin notlarında kalır. Sonuç olarak forum yoğun görünür, ancak kararlar etkinlikten sonra ortaya çıkar.

Formatı, istenen eyleme göre seçiyoruz:

Hata analizi güvenli bir moderasyon gerektirir. Kararı ve koşulları tartışıyoruz, seçim anında bilinenleri ve sonradan netleşenleri ayrı ayrı ele alıyoruz. Hatanın kabulünü departman sıralamasına dönüştürmüyoruz.

Karmaşık bir vaka için moderatör önceden soruyu, mevcut verileri ve tartışma sınırlarını alır. Görevi, konuşmayı talebin sınırları içinde tutmaktır. Katılımcılar sorunu netleştirmeden uygulama detaylarına girerse, moderatör onları başlangıçtaki seçime geri döndürür.

Portföy incelemesi nasıl yapılır?

Kısaca: Portföy incelemesi girişimleri tek bir şablon üzerinden karşılaştırır. Ekip hedefi, beklenen sonucu, gerekçeleri, kısıtları, bağımlılıkları ve karar talebini ortaya koyar. Slaytların güzelliği ve yayımlanan özelliklerin sayısı içeriğin yerini tutmamalıdır.

İnceleme genel bir haritayla başlar. Üzerinde ürün yönleri, girişimler, ortak platformlar ve büyük bağımlılıklar görünür. Ardından ekipler yalnızca diğer katılımcıların bakışına veya yönetsel bir tercihe ihtiyaç duyulan unsurları açıklar.

Her bahis için yedi alan yeterlidir:

1. Ekip hangi sorunu veya fırsatı ele alıyor.
2. Bu kimin için önemli.
3. Hangi veriler güncelliğini doğruluyor.
4. Hangi sonuç bekleniyor.
5. Hangi kısıtlar ve alternatifler zaten biliniyor.
6. Sonraki adım kime bağlı.
7. Forumda hangi karar gerekiyor.

Moderatör ekipten tüm roadmap'i savunmasını istemez. Tartışmalı kısım hakkında sorular sorar. Veriler yeterliyse, atanmış yönetici tercihi onaylar. Gerekçeler zayıfsa, ekip doğrulama görevi alır. Çatışma ortak bir kaynakla ilgiliyse, konu o kaynağın sahibiyle birlikte karar penceresine geçer.

Böyle bir bloğun anti-pattern'i yeşil statüler geçididir. Katılımcılar her şeyin plana göre gittiğini duyar, ancak durdurulan hipotezleri, gecikmenin maliyetini ve diğer ekiplere yönelik talepleri görmez. Her incelemeyi net statülerden biriyle bitirmeyi öneriyoruz: devam et, değiştir, durdur, verileri doğrula veya yükselt.

Karar sekreteri ifadeyi hemen ekranda veya ortak bir belgede yazar. Katılımcılar metni görür ve bir sonraki soruya geçmeden önce belirsizliği düzeltebilir. Nihai kayıt, odada bulunmayan bir kişi için anlaşılır olmalıdır.

Dependency clinic ve ekipler arası bağlantı haritası

Cevap: Bağımlılık, her iki taraf, sahibi, gerekli eylem, gecikmenin sonucu ve kontrol noktası belirtildiğinde iş için anlaşılır hale gelir. Bu alanlar olmadan iki kart arasındaki çizgi bağlantıyı gösterir, ancak sonraki işi tanımlamaz.

Atlassian, dependency mapping metodolojisinde bağımlılıkları ve riskleri önceden belirlemeyi, sahipleri atamayı, risk azaltmayı planlamayı ve geri bildirim ritmini belirlemeyi önerir. Forum için bu, ayrı bir çalışma oturumunun temelidir.

Etkinlikten önce ekipler bilinen bağlantıları ortak bir sicile kaydeder. Forumda katılımcılar kritik bağımlılıkları kontrol eder, tartışmada eksik olanları bulur ve eylemi netleştirir. Odadaki her engeli kaldırmayı vaat etmiyoruz. Yetki veya veri yoksa, sonuç bir eskalasyon yoludur.

Bağımlılık kartı şunları içerir:

Haritanın etkinlikten sonra bir sahibi olmalıdır. Duvarın fotoğrafı sicilin yerini tutmaz. Tüm kartlar, ekibin zaten ürün çalışmasını yürüttüğü dijital bir ortama aktarılır. Aracın formatını müşteri seçer.

Oturumun kendisinde, bağlantının her iki tarafından insanları yan yana toplamak faydalıdır. Bir taraf yoksa, tartışma hızla başkalarının yetenekleri hakkında bir varsayıma dönüşür. Böyle bir konu açık olarak kaydedilir ve üzerinde anlaşılmış bir plan olarak sunulmaz.

Yönetimin rolü ve kapalı oturum

Kılavuz: Yöneticiler, yetkilerinin sonucu değiştirdiği bloklarda yer almalıdır. Karşılama konuşması, önceliklerin, kaynakların ve eskalasyon yolunun seçimine katılımın yerini tutmaz. Hassas konular kapalı bir odada ele alınabilir, ancak karar mantığı izin verilen ölçüde ekiplere dönmelidir.

Forumdan önce, karar vericilerin takvimini programla karşılaştırırız. Eğer CPO, CTO veya iş lideri sadece açılışta bulunursa, tartışmalı konular yine «onaya» gider. Bu nedenle karar pencereleri onaylanmış bir zamana yerleştirilir ve yöneticiye önceden pre-read iletilir.

Geniş kitle, kullanıcı sinyallerini, bağımlılıkları, uygulama seçeneklerini ve sonuçları tartışabilir. Personel, gizli veriler, yatırım limitleri veya henüz açıklanmamış strateji ile ilgili konular kapalı bir kadro gerektirebilir. Sınır, müşteri tarafından onaylanan erişim matrisi ile belirlenir.

Kapalı oturum, tüm forumu bir dekorasyona dönüştürmemelidir. Oturumdan sonra ekipler net bir statü alır: karar alındı, konu verilere kadar ertelendi, ayrı bir toplantı planlandı veya öncelik değişti. Ayrıntılar sınırlandırılabilir, ancak katılımcıların bundan sonra ne yapacaklarını bilmeleri gerekir.

Her karar için, gerekçeyi izin verilen ölçüde saklamak faydalıdır. «Yönetim karar verdi» ifadesi hızla bağlamını yitirir. «Öncelik, genel taahhüt nedeniyle onaylandı; A ekibi planı güncelliyor, B ekibi bağımlılığı kontrol ediyor» kaydı uygulamaya yardımcı olur ve tekrar eden tartışmaları azaltır.

Hibrit, demo ve teknik yedek nasıl tasarlanır?

Kısaca: Uzaktan katılımcılar soru sormalı, belgelerle çalışmalı ve kararları etkileyebilmelidir. Her live demo için kararlaştırılmış bir yedek gerekir; kayıt kuralları, yol haritalarının gösterimi ve materyallere erişim ise teknik prova öncesinde onaylanır.

Hibrit Product Day, pasif sohbetli bir sahne yayını olarak kurgulanamaz. W3C, katılımcı ihtiyaçlarının, ses kalitesinin, altyazı veya deşifrelerin, önemli görsel bilgilerin betimlenmesinin ve materyallerin erişilebilirliğinin önceden dikkate alınmasını önerir. Salondan gelen sorular mikrofonla tekrarlanmalıdır, aksi halde uzaktaki izleyici konuşmanın bir kısmını kaçırır.

Dağıtık ekipler için tek bir dijital doğruluk kaynağı oluşturuyoruz. Orada pre-read, çalışma şablonları, karar günlüğü ve izin verilen materyaller bulunur. Her odada uzaktan katılım hattını izleyen ve soruları tartışmaya geri getiren bir kişi olmalıdır.

Şirketin tam kapsamlı bir hibrit etkinlik organizasyonuna ihtiyacı varsa, stüdyo ve yüz yüze rotaları ayrı ayrı kurarız: bağlantı, ses, ekran gösterimi, oylamalar, grup çalışması ve sonuçların aktarımı. Tek bir platform bu görevi otomatik olarak çözmez.

Live demo'yu bir üretim zinciri olarak test ederiz: ortama erişim, ürün sürümü, hesap, ağ, kablolar, kaynak geçişi, arayüz ölçeği ve verilerin gösterim izni. Yedek için kararlaştırılmış kayıt, ekran görüntüleri veya statik bir rota uygundur. Yedek çözüm, demonun programa dahil edilme amacındaki aynı tezi doğrulamalıdır.

Bağlantı noktalarını etkinliğin teknik provasında geçmek faydalıdır. Orada nihai dosyalar, akışlar arası geçişler, erişim hakları, yedek, gizli verilerin gösterimi ve kararın ortak günlüğe aktarımı kontrol edilir. Bu bağlantı noktaları olmadan yapılan bir konuşma provası, forumun hazır olduğunu göstermez.

Kayıt kuralları önceden belirlenir. Katılımcılar kayıt konusunda bilgilendirilir ve müşterinin kuralları ile geçerli hukuka göre gerekli onay alınır. Müşteri ayrıca erişimi, saklama süresini ve materyallerin kullanım iznini belirler. Kişi, hassas bir konu tartışılmadan önce kayıt modunu bilmelidir.

Çıktılar, metrikler ve sonraki adım

Kısaca: Forumdan sonra çalışma belgeleri ve devam takvimi kalır. Değerlendirmeye değer olan, kararların hareketidir: sahipler atandı mı, bağımlılıklar güncellendi mi, eksik veriler toplandı mı ve katılımcılar kontrol noktalarına geri döndü mü? Konukların izlenimi bu tabloyu tamamlar, ancak onun yerini almaz.

Product Day sonrası minimum paket; portföy haritası, bağımlılık kaydı, karar günlüğü, açık sorular listesi ve izin verilen materyalleri içerir. Günlükte her kayıt için ifade, gerekçe, sahip, devam katılımcıları, eksik veriler, erişim modu ve kontrol noktası belirtilir.

Sonucun dört durumu vardır:

1. Karar kaydedildi ve katılımcılar tarafından onaylandı.
2. Sahip bir sonraki eylemi kabul etti.
3. Eylem kontrol noktasına kadar tamamlandı veya güncellendi.
4. Ürün veya iş sonucu, şirketin çalışma döngüsü içinde sahibi tarafından doğrulandı.

Forum ilk iki adımı nitelikli şekilde gerçekleştirebilir. Geri kalanlar, etkinlik sonrası düzenli yönetime bağlıdır. Bu nedenle, müşteri verileri olmadan bir güne ürünün pazara çıkışının hızlanmasını, finansal göstergenin büyümesini veya katılımın artmasını atfetmek doğru olmaz.

Etkinlikten sonra organizasyonel göstergeleri kontrol etmek faydalıdır: çalışma grupları beyan edilen sonuca ulaştı mı, kararlar için yeterli zaman var mıydı, materyaller erişilebilir miydi, ses, geçişler veya erişimle ilgili sorunlar nerede ortaya çıktı. Bu gözlemler bir sonraki döngüyü iyileştirmeye yardımcı olur, ancak ürün etkisini kanıtlamaz.

Yeni forumun hazırlığına kısa bir brifingle başlıyoruz. Bunda iş hedefi, ekip kompozisyonu, tartışmalı konular haritası, karar yetkileri, erişim modu ve beklenen belge paketi gereklidir. Bundan sonra program mimarisini, mekanı, teknik planı, rolleri ve bütçeyi bir araya getiriyoruz.

Kaynaklar

• Scrum Guides: resmi Scrum kılavuzu
• Atlassian Team Playbook: bağımlılık haritalama
• Atlassian Team Playbook: karar alma ve roller
• GOV.UK Service Manual: disiplinler arası ekip
• GOV.UK Service Manual: agile delivery yönetimi ilkeleri
• Product School: ürün yol haritası
• Aha!: ürün yol haritası kılavuzu
• W3C Web Accessibility Initiative: erişilebilir etkinlikler ve sunumlar
• GitLab Handbook: tamamen uzaktan toplantılar