Domain storytelling, bir konunun anlaşılmasını sağlamak için hikaye anlatma tekniklerini kullanmayı içeren bir yaklaşımdır. Birçok işletme, bu teknikleri kullanarak müşterileri, hissedarları veya çalışanları ile iletişim kurar. Yani, bir şirketin bir ürününün, hizmetinin veya stratejisinin ne olduğunu anlatmak için bir hikaye oluşturmasını ve bu hikayeyi paylaşmasını içerir.
Domain Storytelling • Stefan Hofer, Henning Schwentner & Avraham Poupko • GOTO 2022
Domain storytelling, iş analizinde, özellikle de yazılım geliştirmede, bir iş sürecini veya işlevselliği anlamak ve iletmek için kullanılır. Çeşitli kullanıcıları, sistemleri ve bunlar arasındaki etkileşimleri görsel bir formatta gösteren hikayeler oluşturulur. Bu, bir iş sürecinin veya sistemler arası etkileşimin anlaşılmasını ve analiz edilmesini kolaylaştırır.
Domain storytelling, genellikle yazılım mühendislerinin ve iş analistlerinin ihtiyaçları daha iyi anlamalarını ve daha etkili çözümler üretmelerini sağlamak için kullanılır. Ayrıca, teknik olmayan kullanıcıların karmaşık iş süreçlerini veya sistemler arası etkileşimleri anlamalarını da kolaylaştırabilir.
Domain storytelling'nin birçok avantajı vardır:
Anlaşılması kolay: Domain storytelling, teknik olmayan kullanıcılara bile karmaşık iş süreçlerini anlatmak için kullanılabilir.
İş süreçlerinin daha iyi anlaşılması: Domain storytelling, bir iş sürecinin veya sistemler arası etkileşimin daha derinlemesine anlaşılmasını sağlar.
Yazılım geliştirme: Domain storytelling, yazılım mühendislerinin iş ihtiyaçlarını daha iyi anlamalarını ve bu ihtiyaçları karşılayan yazılımlar geliştirmelerini sağlar.
Domain storytelling'nin bazı dezavantajları ise şunlar olabilir:
Zaman alıcı: Domain hikayeleri oluşturmak zaman alabilir.
Yorumlama farklılıkları: Farklı insanlar aynı hikayeyi farklı şekillerde yorumlayabilirler.
Teknik kısıtlamalar: Hikayenin oluşturulması ve anlatılması, teknik beceri gerektirebilir.
Domain storytelling, genellikle iş analizinde ve yazılım geliştirmede kullanılır. Ancak, diğer sektörlerde de kullanılabilir. Örneğin, bir finans şirketi, müşterilerine bir hizmetin nasıl çalıştığını anlatmak için domain storytelling kullanabilir. Aynı şekilde, bir sağlık hizmetleri şirketi, hastalarına bir tedavi sürecini anlatmak için domain storytelling kullanabilir.
Domain storytelling'nin uygulanması genellikle aşağıdaki adımları içerir:
Konunun belirlenmesi: Hangi iş sürecinin veya işlevselliğin anlatılacağına karar verilir.
Hikayenin oluşturulması: İş süreci veya işlevsellik hakkında bir hikaye oluşturulur.
Hikayenin görselleştirilmesi: Hikaye, çeşitli kullanıcıları, sistemleri ve bunlar arasındaki etkileşimleri gösteren bir şekil veya diagram ile görselleştirilir.
Hikayenin paylaşılması: Hikaye, ilgili kişilere veya gruplara sunulur.
Domain storytelling, genellikle karmaşık iş süreçlerini veya işlevselliği anlatmak için kullanılan bir tekniktir. Ayrıca, hikayeyi oluşturmak ve paylaşmak için çeşitli teknikler ve araçlar kullanılabilir. Her ne kadar bazı dezavantajları olsa da, domain storytelling'nin birçok avantajı vardır ve birçok işletme tarafından başarıyla kullanılmaktadır.
Domain Storytelling, ayrıca karmaşık iş süreçlerinin veya hizmetlerin kritik yönlerini vurgulamak ve bunları belirginleştirmek için de kullanılabilir. Çünkü çoğu zaman bir şirketin sunmakta olduğu değeri belirleyen şey, sundukları hizmetlerin veya ürünlerin kendileri değil, bunların müşterilere veya kullanıcılara nasıl sunulduğudur. Bu nedenle, bir hizmetin veya ürünün başarısında belirleyici olan adımların ve süreçlerin hikaye şeklinde anlatılması, bu değeri daha net bir şekilde ortaya koyabilir.
Aynı zamanda, domain storytelling, iş süreçlerinin veya sistemlerin iyileştirilmesi için de bir araç olarak kullanılabilir. Hikaye anlatarak, analistler ve mühendisler süreçlerdeki veya sistemlerdeki hataları, eksiklikleri veya verimsizlikleri daha kolay fark edebilir. Bu, süreç veya sistem iyileştirmelerine yol açabilir.
Yine de, unutmamak gerekir ki domain storytelling, bir iş sürecinin veya sistemler arası etkileşimin her yönünü kapsayamayabilir. Özellikle çok büyük ve karmaşık sistemler söz konusu olduğunda, domain storytelling'nin her detayı aktarması zor olabilir. Bu durumda, daha detaylı ve teknik analizlerin yapılması gerekebilir.
Birçok büyük teknoloji şirketi domain storytelling tekniklerini kullanır. Örneğin, Amazon'un ünlü 6-sayfalık memo yaklaşımı, bir tür domain storytelling örneği olabilir. Bu yaklaşımda, bir fikir veya proje hakkında bir hikaye oluşturulur ve bu hikaye, bir projenin veya ürünün her yönünü kapsayan bir "basın bülteni" formatında yazılır. Bu, Amazon'un yeni ürünler veya hizmetler geliştirirken kullanıcılarına ve müşterilerine odaklanmasına yardımcı olur.
Bir başka örnek ise, Spotify'ın Agile modelidir. Bu modelde, ürün geliştirme süreci hikaye anlatma ve görselleştirme teknikleri kullanılarak anlatılır. Bu, takımların ürün geliştirme sürecini daha iyi anlamalarını ve daha etkili bir şekilde katılım sağlamalarını mümkün kılar.
Sonuç olarak, domain storytelling, bir iş sürecini veya işlevselliği anlatmak için güçlü bir araçtır. Hem iş analistlerinin hem de teknik olmayan kullanıcıların karmaşık iş süreçlerini veya sistemler arası etkileşimleri anlamalarını kolaylaştırabilir. Ancak, her hikaye anlatma tekniği gibi, domain storytelling'nin de sınırlamaları vardır ve her durumda kullanılabilir olmayabilir. Bu nedenle, en etkili sonuçları elde etmek için, domain storytelling'nin hangi durumlarda ve nasıl kullanılacağını dikkatlice değerlendirmek önemlidir.
Domain storytelling ayrıca özellikle büyük ölçekli projelerde veya geniş bir işleyiş ve işlevsellik yelpazesi olan organizasyonlarda yararlı olabilir. Her birimin, departmanın veya ekibin görevlerini ve işlevlerini kendi perspektifinden anlaması ve anlatması, tüm organizasyonun daha iyi bir anlayışına ve daha geniş bir bakış açısına sahip olmasını sağlar. Bu, organizasyon içindeki iletişimi ve işbirliğini güçlendirebilir, ve böylece genel verimliliği ve etkinliği artırabilir.
Öte yandan, domain storytelling, yanlış uygulandığında veya hatalı bir şekilde anlatıldığında, yanıltıcı veya karışık olabilir. Örneğin, bir hikayenin çok genel veya çok belirli olması, hikayenin etkinliğini azaltabilir. Ayrıca, hikayenin karmaşık bir konuyu basitleştirmesi gerekirken, bazen çok fazla basitleştirme, konunun gerçek karmaşıklığını ve önemini gizleyebilir. Bu nedenle, domain storytelling'nin etkili olabilmesi için, hikayenin hem anlamlı hem de doğru olması gerekir.
Bunun dışında, domain storytelling, bir organizasyonun içinde veya dışında belirli bir hedef kitleye hitap etmek için stratejik bir araç olarak kullanılabilir. Örneğin, bir organizasyon, domain storytelling kullanarak müşterilere, hissedarlara veya genel halka belirli bir mesaj vermek veya belirli bir imaj oluşturmak isteyebilir. Bu durumda, hikayenin hangi mesajı verdiği ve nasıl anlatıldığı, hedef kitle üzerinde büyük bir etkiye sahip olabilir.
Son olarak, domain storytelling, bazen bir organizasyonun veya ekibin düşüncelerini ve fikirlerini organize etmeye de yardımcı olabilir. Bir hikayenin oluşturulması ve anlatılması süreci, genellikle bir takımın bir konuyu tartışmasını, farklı bakış açılarını değerlendirmesini ve en iyi çözümü belirlemesini gerektirir. Bu süreç, bir takımın daha iyi bir anlayışa ve daha güçlü bir konsensüse ulaşmasına yardımcı olabilir.
Sonuç olarak, domain storytelling, iş süreçlerini, sistemler arası etkileşimleri ve hatta bir organizasyonun değerlerini ve hedeflerini anlatmak için güçlü ve esnek bir araç olabilir. Ancak, bu teknik, etkili olabilmesi için dikkatlice uygulanmalı ve hikayenin hem anlamlı hem de doğru olması gerektiği unutulmamalıdır.
Domain storytelling'de renklendirme ne için kullanılır?
Domain storytelling'de renklendirme, görsel çizimlerin ve diagramların daha etkili iletişim sağlamak için kullanılan bir yöntemdir. İşte renklendirme kullanımının bazı önemli nedenleri:
Görsel Ayrım: Renklendirme, görsel çizimlerde farklı bileşenlerin veya elemanların ayrı ayrı tanımlanmasını sağlar. Örneğin, bir hikaye anlatma çiziminde, kullanıcılar, iş süreçleri, sistem bileşenleri vb. farklı renklerle vurgulanabilir. Bu, okuyucuların çizimdeki farklı unsurları daha kolay ayırt etmelerine yardımcı olur.
İlişkilerin Gösterimi: Renklendirme, çizimlerdeki ilişkileri vurgulamak için kullanılabilir. İlişkili bileşenler veya süreçler aynı renkte gösterilebilir veya belirli bir renk temasıyla vurgulanabilir. Bu, okuyucuların çizimdeki ilişkileri daha hızlı ve daha net bir şekilde anlamalarını sağlar.
Öncelik ve Önem Belirtimi: Renklendirme, çizimdeki bileşenlerin veya süreçlerin öncelik ve önem sırasını belirtmek için kullanılabilir. Önemli veya öncelikli unsurlar belirli bir renkle vurgulanabilirken, daha az önemli olanlar başka bir renkte gösterilebilir. Bu, okuyucuların görsel olarak odaklanması gereken noktaları daha iyi anlamalarını sağlar.
Anlaşılabilirlik ve İletişim: Renklendirme, çizimlerin ve diagramların daha anlaşılır ve etkili bir şekilde iletilmesine yardımcı olur. Farklı renkler, görsel çizimlerdeki karmaşıklığı azaltır ve okuyucuların hızlı ve kolay bir şekilde bilgiyi anlamalarını sağlar. Renklendirme, bilginin daha çekici ve ilgi çekici bir şekilde sunulmasına da katkıda bulunur.
Renklendirme, domain storytelling sürecinde çizimlerin ve diagramların daha etkili bir şekilde iletişim sağlamasına yardımcı olur. Farklı renkler, ayrım yapmayı, ilişkileri göstermeyi, öncelikleri belirtmeyi ve anlaşılabilirliği artırmayı sağlar. Bu da hikayelerin ve görsellerin daha çekici ve anlaşılır olmasını sağlar.
Amazon'un ünlü 6-sayfalık memo yaklaşımı nedir?
Amazon'un 6-sayfalık memo yaklaşımı, şirketin içindeki toplantılar ve karar verme sürecinde kullandığı bir yöntemdir. Bu yaklaşım, şirketin kurucusu Jeff Bezos tarafından uygulanmaya başlanmıştır ve Amazon'un tüm düzeylerindeki çalışanlar tarafından benimsenmiştir.
Bu yöntemde, bir toplantı öncesinde, toplantıya katılacak kişilerden biri, toplantının gündemini belirleyen ve tartışılacak konuları detaylı bir şekilde açıklayan bir memo hazırlar. Bu memo genellikle 6 sayfa uzunluğunda olmalıdır ve genellikle bir basın bülteni formatında yazılır.
Toplantı başladığında, tüm katılımcılar önce memo'yu sessizce okur. Bu sessiz okuma süresi genellikle 30 dakika kadar sürer. Bu, tüm katılımcıların toplantının konusu ve amaçları hakkında tam bir anlayışa sahip olmalarını sağlar. Sessiz okuma süresinin ardından, katılımcılar memo hakkında tartışmaya ve kararlar almaya başlarlar.
Bu yaklaşımın amacı, toplantıların daha odaklı ve verimli hale getirilmesidir. Çünkü, herkesin toplantı öncesi konuyu detaylı bir şekilde anladığından emin olunur. Ayrıca, toplantı sırasında gereksiz veya tekrar eden tartışmaları önlemeye yardımcı olur.
Bu 6-sayfalık memo yaklaşımı, Amazon'un etkili karar verme ve işbirliği yapma kültürünün bir parçasıdır. Aynı zamanda, Amazon'un müşteri odaklı düşünme yaklaşımını da yansıtır, çünkü memo genellikle bir basın bülteni formatında yazılır ve bu da çalışanların müşteri bakış açısını benimsemelerini teşvik eder.
Spotify'ın Agile modeli nedir?
Spotify, Agile prensipleri ve uygulamalarını benimseyen bir teknoloji şirketi olarak bilinir. Agile yaklaşımlar genellikle iş ihtiyaçlarına hızlı ve etkili bir şekilde yanıt verebilmek, işlevselliği hızlı bir şekilde piyasaya sürmek ve sürekli öğrenme ve geliştirme döngülerini teşvik etmek için kullanılır. Spotify, bu yaklaşımları biraz farklı bir şekilde uygulamış ve bu da "Spotify Agile Modeli" olarak bilinir.
Bu model, Spotify'ın iş süreçlerini ve organizasyonel yapısını tanımlar. Spotify'da, ekipler "squads" olarak adlandırılır. Her squad, belirli bir hedefe odaklanır ve bu hedefe ulaşmak için gereken tüm becerilere sahip bir "kendi kendini yöneten" ekiptir. Bu ekipler, kendi kararlarını alabilir ve özerk bir şekilde çalışabilirler.
Squads, daha büyük birimler olan "tribes" içinde gruplanır. Bir tribe, genellikle birkaç squad'ı içerir ve aynı alana odaklanır. Tribes'lerin liderleri genellikle "agile coaches" olarak adlandırılır ve onların görevi, squads'ları desteklemek ve Agile prensiplerini ve uygulamalarını teşvik etmektir.
Spotify Agile Modeli ayrıca "chapters" ve "guilds" adı verilen diğer iki yapıyı daha içerir. Bir chapter, aynı uzmanlık alanına (örneğin, veri bilimi veya kullanıcı deneyimi tasarımı) sahip farklı squads'ların üyelerinden oluşur ve genellikle bir "chapter lead" tarafından yönetilir. Bir guild ise, aynı ilgi alanına sahip farklı tribes ve squads'ların üyelerinden oluşan daha geniş ve daha resmi olmayan bir ağdır.
Bu yapı, Spotify'ın hızlı ve etkili bir şekilde değişen iş ihtiyaçlarına yanıt vermesine ve sürekli öğrenme ve geliştirme döngülerini teşvik etmesine olanak sağlar. Bu yaklaşım ayrıca, ekipler arasındaki iletişimi ve işbirliğini kolaylaştırır ve her ekibin kendi hedeflerine odaklanmasını ve kendi kararlarını almasını sağlar. Ancak, Spotify Agile Modeli'nin her organizasyon için uygun olmayabileceğini ve her organizasyonun kendi ihtiyaçlarına ve koşullarına göre bu modeli uyarlaması gerekebileceğini unutmamak önemlidir.
Amazon'dan ve Spotify'dan çalışma şekilleri olarak domain storytelling'den örnekler verdik. Örnek bir senaryo ile bir yazılım uygulaması için domain storytelling'e örnek verebilir misin?
Elbette. Öncelikle, domain storytelling'nin bir iş sürecini, kullanıcıları ve sistemleri bir hikaye anlatma formatında tanımladığını hatırlayalım. Şimdi, örneğin, bir online sipariş ve teslimat uygulamasını ele alalım.
Hikayemiz şöyle başlayabilir: Sarah, yoğun bir günün ardından eve geldiğinde, akşam yemeği için alışveriş yapmak için süresi olmadığını fark eder. Yorgun olduğu için, hemen telefonunu çıkarır ve online sipariş ve teslimat uygulamasını açar. Sarah, uygulamayı açtığında, ona en son siparişlerini ve en çok sipariş verdiği restoranları hatırlatan önerilerle karşılanır. Sarah, favori restoranlarından birindeki yeni menü seçeneklerine bakar ve bu sefer farklı bir yemek denemeye karar verir.
Sarah, siparişini tamamlar ve ödeme bilgilerini girer. Uygulama, siparişin restorana iletildiğini ve yemeğin ne zaman teslim edileceğini bildirir. Sarah, teslimat sürecini uygulama üzerinden takip eder. Yemek, tahmini teslimat süresi içinde kapısına gelir ve Sarah, yorgun bir günün ardından sıcak bir yemekle rahatlar.
Bu hikaye, online sipariş ve teslimat uygulamasının nasıl çalıştığını ve Sarah gibi bir kullanıcının bu süreçte nasıl etkileşimde bulunduğunu açıkça gösterir. Bu hikaye, uygulamanın kullanıcılarına sunduğu değeri ve onların bu hizmeti nasıl kullandıklarını da vurgular.
Bu hikaye, bir yazılım geliştirme ekibine, uygulamanın kullanıcılarına hangi özellikleri ve işlevleri sunması gerektiğini anlamalarına yardımcı olabilir. Örneğin, hikaye, uygulamanın Sarah'ya önceki siparişlerini ve favori restoranlarını hatırlatan öneriler sunması gerektiğini belirtir. Ayrıca, hikaye, kullanıcının siparişini tamamlama ve teslimat sürecini takip etme yeteneğine sahip olması gerektiğini vurgular.
Sonuç olarak, bu tür bir domain storytelling, bir yazılım geliştirme ekibine, bir uygulamanın hangi özelliklerin ve işlevlerin geliştirilmesi gerektiği konusunda net bir yol haritası sağlar. Bu, ekip üyelerinin uygulamanın neyi başarması gerektiği konusunda ortak bir anlayışa sahip olmasına yardımcı olur ve bu da daha etkili bir yazılım geliştirme süreci sağlar.
Domain storytelling çizimleri nasıl olmaıldır? Çizimlerde hangi elementler kullanılır? Bu elementler arası ilişki nasıl ifade edilir? Çizimlerde sub processler çıkarılabilir mi? Fain grained ve corse grained çizmler nelerdir? To be çizimler nelerdir?
Domain storytelling, genellikle öyküleri resimlerle ifade etmek için çeşitli çizimler ve simgeler kullanır. Bu çizimler, bir hikayenin karmaşık ayrıntılarını basit ve anlaşılır bir biçimde sunar. Hikaye çizimlerinde genellikle aşağıdaki temel öğeler bulunur:
Aktörler: Aktörler genellikle hikayenin ana karakterleridir. Bir yazılım uygulamasının kontekstinde, bu, belirli işlevlere veya rollerine göre tanımlanan kullanıcılar veya sistemler olabilir.
Olaylar: Olaylar genellikle bir aktörün belirli bir eylemi gerçekleştirdiği veya bir durumu deneyimlediği zamanları temsil eder.
İlişkiler: İlişkiler, aktörler ve olaylar arasındaki bağlantıları ve etkileşimleri gösterir. İlişkiler genellikle oklar veya çizgiler ile temsil edilir ve genellikle bir eylemin yönünü veya akışını gösterir.
Süreçler: Süreçler genellikle bir dizi olayı veya eylemi temsil eder. Bir süreç, genellikle bir başlangıç ve bir bitiş noktası arasındaki olayların bir dizi olarak düşünülebilir. Bir domain hikayesinde, süreçler genellikle bir iş akışı veya iş süreci olarak görülür.
Bir hikaye çiziminde sub-processlerin çıkarılması mümkündür. Bir sub-process, genellikle daha büyük bir sürecin bir parçasını oluşturan daha küçük bir süreçtir. Bir sub-process genellikle daha detaylı veya ince taneli bir bakış açısı sağlar ve genellikle bir sürecin belirli bir bölümünü veya aşamasını gösterir. Bu, bir hikayenin daha karmaşık veya detaylı bir bölümünü daha kolay anlaşılır hale getirebilir.
Coarse-grained ve fine-grained çizimler, hikayenin detay seviyesini temsil eder. Coarse-grained çizimler genellikle bir hikayenin yüksek seviyeli veya genel bir bakışını sunar, daha az detay içerir ve genellikle geniş kavramları veya süreçleri temsil eder. Fine-grained çizimler ise daha fazla detay içerir ve genellikle belirli bir sürecin veya kavramın daha detaylı veya derinlemesine bir anlayışını sunar.
"To be" çizimler, genellikle bir sürecin veya sistemlerin gelecekte nasıl olması gerektiğini gösterir. Bu çizimler, genellikle bir sürecin veya sistemin mevcut durumunu ("as is") temsil eden çizimlere kıyasla, önerilen veya planlanan değişiklikleri veya iyileştirmeleri gösterir.
Bu çizimler, genellikle bir sürecin veya sistemlerin mevcut durumunu anlamak, planlanan değişiklikleri görselleştirmek ve bu değişikliklerin etkisini değerlendirmek için kullanılır. "To be" çizimler, genellikle bir proje veya girişimin başında oluşturulur ve genellikle proje veya girişimin hedeflerini ve sonuçlarını tanımlar.
Domain storytelling de as -is ile to-be storylerin farkı nedir?
Genel olarak, domain storytelling'de "as is" ve "to be" hikayeleri arasındaki farkı açıklamaya çalışabilirim.
Domain storytelling, bir iş alanını (domain) anlamak ve modellemek için kullanılan bir tekniktir. Bu teknikte, gerçek dünya örnekleri ve hikayeleri kullanılır.
"As is" hikayeleri, mevcut durumu, yani iş süreçlerinin, sistemlerin veya uygulamaların şu anki durumunu anlatır. Bu hikayeler, mevcut iş süreçlerini, problemleri ve zorlukları belgelemek için kullanılır.
"To be" hikayeleri ise gelecekteki durumu, yani iş süreçlerinin, sistemlerin veya uygulamaların nasıl olması gerektiğini anlatır. Bu hikayeler, ideal iş süreçlerini, hedefleri ve çözümleri belgelemek için kullanılır.
Bu iki tür hikaye, bir iş alanını anlamak ve iyileştirmek için birlikte kullanılır. "As is" hikayeleri, mevcut durumu anlamak ve problemleri belirlemek için kullanılırken, "to be" hikayeleri, bu problemleri çözmek ve iş süreçlerini iyileştirmek için kullanılır.
Detaylı örnek bir senaryo ile devam eder misin?
Bir e-ticaret şirketini düşünelim. Bu şirketin müşteri hizmetleri departmanı, müşterilerden gelen şikayetleri ve soruları çözmekle görevlidir. Ancak son zamanlarda, müşteri hizmetleri departmanı, müşterilerden gelen talepleri hızlı ve etkili bir şekilde çözme konusunda zorluk çekmeye başlamıştır.
Bu durumu çözmek için, şirket bir domain storytelling oturumu düzenler. Bu oturumda, "as is" ve "to be" hikayeleri oluşturulur.
"As is" hikayesi: Müşteri hizmetleri departmanı, müşterilerden gelen talepleri manuel olarak işlemektedir. Bu süreç, hem zaman alıcı hem de hata yapma olasılığı yüksektir. Ayrıca, departmanın talepleri takip etmek için kullanabileceği bir sistem yoktur. Bu durum, taleplerin kaybolmasına veya yanlış işlenmesine neden olabilir.
"To be" hikayesi: Şirket, müşteri hizmetleri departmanının iş yükünü azaltmak ve hizmet kalitesini artırmak için bir müşteri hizmetleri yönetim sistemi (CRM) kurmayı planlamaktadır. Bu sistem, müşteri taleplerini otomatik olarak işleyecek, takip edecek ve raporlayacaktır. Bu sayede, departmanın işlem süreleri kısalacak ve hata oranı düşecektir.
Bu iki hikaye, şirketin mevcut durumunu anlamasına ve gelecekteki hedeflerini belirlemesine yardımcı olur. Ayrıca, bu hikayeler, şirketin bu hedeflere ulaşmak için hangi adımları atması gerektiğini belirlemesine de yardımcı olur.
Bu hikayeleri oluşturduktan sonra, şirketin bir sonraki adımı bu hedeflere ulaşmak için bir plan oluşturmak olacaktır. Bu plan, "to be" hikayesinde belirlenen hedeflere ulaşmak için gereken adımları içerecektir.
Örneğin, bu plan aşağıdaki adımları içerebilir:
CRM Sistemi Seçimi: Şirket, ihtiyaçlarına en uygun CRM sistemini seçmek için bir araştırma yapar. Bu araştırma, sistemlerin özelliklerini, maliyetlerini ve kullanıcı yorumlarını içerebilir.
Sistem Kurulumu ve Özelleştirme: Seçilen CRM sistemi, şirketin ihtiyaçlarına göre kurulur ve özelleştirilir. Bu aşama, sistem ayarlarının yapılması, gerekli modüllerin eklenmesi ve şirketin iş süreçlerine uygun hale getirilmesi gibi adımları içerir.
Eğitim: Müşteri hizmetleri departmanı, yeni CRM sistemini nasıl kullanacakları konusunda eğitilir. Bu eğitim, sistem özelliklerini, işlevlerini ve en iyi uygulamalarını içerir.
Sistem Testi ve Lansmanı: CRM sistemi, canlıya alınmadan önce kapsamlı bir şekilde test edilir. Bu testler, sistem hatalarını, eksikliklerini ve iyileştirme alanlarını belirlemek için yapılır. Testlerden sonra, sistem canlıya alınır ve müşteri hizmetleri departmanı tarafından kullanılmaya başlanır.
İzleme ve İyileştirme: CRM sisteminin performansı, belirlenen hedeflere ulaşıp ulaşmadığını belirlemek için düzenli olarak izlenir. Gerekli durumlarda, sistemde iyileştirmeler yapılır.
Bu plan, "as is" hikayesinde belirlenen problemleri çözmek ve "to be" hikayesinde belirlenen hedeflere ulaşmak için kullanılır. Bu süreç, domain storytelling'in bir iş alanını anlamak ve iyileştirmek için nasıl kullanıldığının bir örneğidir.
Domain stories with software systems as actors are called DIGITALIZED cümlesinden ne anlamalıyım?
"Domain stories with software systems as actors are called DIGITALIZED" cümlesi, yazılım sistemlerinin aktör olarak yer aldığı hikayelere "digitalized" adı verildiğini ifade eder.
Bu cümle, domain storytelling sürecinde bazen yazılım sistemlerinin de birer aktör olarak gösterilebileceğini ve bu tür hikayelere "digitalized" adı verildiğini belirtmektedir. Yani, bu tür hikayelerde yazılım sistemleri, iş süreçlerinde etkin rol oynayan ve kullanıcı ihtiyaçlarını karşılayan birer aktör olarak tasvir edilir.
Bu ifade, yazılım sistemlerinin iş süreçlerindeki etkisini ve önemini vurgularken, aynı zamanda domain storytelling yönteminin geniş bir uygulama alanına sahip olduğunu gösterir. Yazılım sistemleri, iş süreçlerini otomatize etme, veri işleme veya kullanıcı etkileşimi gibi görevlerde aktif bir rol oynadığından, bu tür hikayelerin dijitalleştirilmiş süreçlerle ilgili olduğu söylenebilir.
Özetle, "Domain stories with software systems as actors are called DIGITALIZED" cümlesi, yazılım sistemlerinin aktör olarak yer aldığı hikayelere "digitalized" adının verildiğini ifade eder ve bu tür hikayelerde yazılım sistemlerinin iş süreçlerindeki etkisini yansıtır.
Domain stroytelling toplantıları nasıl gerçekleştirmelidir?
Domain storytelling toplantılarının düzenlenmesi ve yürütülmesi, hikayeyi oluşturacak ve ondan öğrenmek için birlikte çalışacak bir grup insanın etkili bir şekilde iletişim kurabilmesini gerektirir. Bu tür bir toplantı aşağıdaki adımları içerebilir:
Toplantının Amacını Belirleyin: Toplantının başında, toplantının amacını ve hedeflerini belirlemek önemlidir. Bu, genellikle hangi iş sürecinin veya özelliğin hikayesinin anlatılacağını ve bu hikayenin hangi problemi veya ihtiyacı çözmesi gerektiğini içerir.
Katılımcıları Hazırlayın: Katılımcılar, genellikle hikayenin anlatılacağı süreç veya özellik hakkında bilgi sahibi olan ve bu konuda fikir sahibi olan kişilerdir. Bu, genellikle iş analistleri, kullanıcılar, ürün sahipleri, geliştiriciler ve diğer ilgili tarafları içerir. Bu kişilerin, toplantıya hazırlanmaları ve konu hakkında düşünmeleri için yeterli zamanları olmalıdır.
Stonehenge kurulumu
Hikayeyi Anlatın: Toplantının ana bölümünde, katılımcılar hikayeyi anlatmaya başlarlar. Bu genellikle, süreci veya özelliği tanımlayan bir dizi olayı ve bu olayların birbirine nasıl bağlandığını içerir. Bu aşama genellikle, çeşitli çizimler veya diagramlar kullanılarak gerçekleştirilir.
Hikayeyi Tartışın ve İyileştirin: Hikaye anlatıldıktan sonra, katılımcılar hikayeyi tartışabilir ve iyileştirebilirler. Bu, genellikle hikayenin eksik noktalarını veya belirsizliklerini belirlemeyi ve hikayeyi daha kesin ve anlaşılır hale getirmeyi içerir.
Sonuçları Dokümantasyonla Kaydedin: Toplantının sonunda, hikayenin ve tartışmaların sonuçlarını belgelemek önemlidir. Bu, genellikle hikayenin çizimlerini ve ana noktalarını içerir ve ayrıca tartışılan herhangi bir iyileştirme veya değişikliği de içerir.
Domain storytelling toplantıları genellikle yüz yüze yapılır, ancak çevrimiçi araçlarla da yapılabilir. Önemli olan, katılımcıların hikayeyi anlama ve üzerinde etkili bir şekilde tartışma yeteneğidir. Bu tür bir toplantı, genellikle bir süreci veya özelliği anlamak ve geliştirmek için etkili bir yol olabilir.
Domain stroytelling toplantılarında nelere dikkat edilmelidir? Neler yapılmalı, nelerden kaçınılmalıdır?
Alan (domain) hikâye anlatımı toplantıları, bir ürün, hizmet veya işletme ile ilgili bilgileri çeşitli yönleriyle anlatmak ve ayrıntılı bir bakış açısı sağlamak için gerçekleştirilen oturumlardır. Bu tür toplantılar genellikle UX tasarımcıları, yazılım geliştiricileri, proje yöneticileri ve diğer ilgili paydaşlar arasında düzenlenir. Aşağıda bu tür toplantılarda dikkat edilmesi gereken noktaları bulabilirsiniz:
Katılımcıların Bilgi Seviyesini Anlama: Her katılımcının seviyesini ve konuya ne kadar hakim olduğunu anlamak önemlidir. Bu sayede herkesin konuyu anlaması ve katkıda bulunabilmesi için gerekli bilgi seviyesini ayarlayabilirsiniz.
Hikâyenin Yapısını Belirleme: Alan hikâyesini anlatırken, hikâyenin yapısını belirlemek önemlidir. İyi bir hikâye, genellikle bir giriş, orta kısım ve sonuçtan oluşur. Ayrıca, bir problemi tanımlayabilir, bu probleme nasıl bir çözüm getirileceğini anlatabilir ve çözümün sonuçlarını tartışabilirsiniz.
Bilgileri Basit ve Anlaşılır Tutmak: Hikâyenizi anlatırken, karmaşık terminoloji ve jargonu olabildiğince az kullanmak önemlidir. Anlaşılmaz terimler kullanmak yerine, konuyu herkesin anlayabileceği bir dilde anlatmaya çalışın.
Etkileşimi Teşvik Etmek: Alan hikâye anlatımı toplantıları, genellikle bilgi paylaşımı ve fikir alışverişi için harika fırsatlardır. Katılımcıları soru sormaya, yorum yapmaya ve kendi fikirlerini paylaşmaya teşvik edin.
Geri Bildirim Almak: Toplantının sonunda geri bildirim almak, hikâye anlatımınızın etkili olup olmadığını ölçmenin iyi bir yoludur. Bu, gelecekteki toplantılarınızı iyileştirmenize yardımcı olabilir.
Kaçınılması gereken şeyler:
Tek Taraflı Konuşmalar: Toplantınızın bir monologa dönüşmesine izin vermeyin. Katılımcıları dahil etmek ve onların görüşlerini almak önemlidir.
Fazla Detaya Kaçmak: Tüm detayları paylaşmak yerine, hikâyenin ana hatlarını ve en önemli noktalarını vurgulayın. Ayrıntılara boğulmak, hikâyenin akışını keser ve katılımcıların ilgisini dağıtabilir.
Hedeflerin Belirsiz Kalması: Toplantının sonunda, herkesin hikâyeden ne öğrenmesi gerektiğini ve bundan sonra ne yapılması gerektiğini anlaması gerekir. Hedeflerin belirsiz olması, toplantının verimliliğini düşürebilir.
Gerekli Hazırlıkların Yapılmaması: Hikâye anlatımı, belirli bir planlama ve hazırlık gerektirir. Toplantıya gelmeden önce, anlatacaklarınızı düşünün ve gerektiği kadar not alın. Bu, hikâyenizi daha etkili bir şekilde anlatmanıza yardımcı olur.
Toplantıları kim yönetir? Çizimleri kim yapar? Domain expertler ne iş yapar? Yöneticiler toplantılara davet edilmeli midir?
Toplantıları genellikle proje yöneticileri veya ekip liderleri yönetir. Bu kişiler toplantının amacını belirler, gündemi oluşturur, katılımcıları organize eder ve toplantının ilerleyişini yönetir. Yönetici veya lider, toplantının verimli bir şekilde ilerlemesini sağlamak ve hedeflere ulaşmak için sorumluluk alır.
Çizimler genellikle tasarımcılar veya hikâye anlatımı uzmanları tarafından yapılır. Bu kişiler, konuyu görsel olarak anlatmak ve katılımcıların daha iyi anlamalarını sağlamak için grafikler, diyagramlar veya akış şemaları gibi görsel araçları kullanır. Çizimler, toplantıda paylaşılabilir ve katılımcıların daha iyi bir görsel anlayışa sahip olmalarını sağlar.
Domain expertler (uzmanlar), bir konuda derin bilgiye ve deneyime sahip olan kişilerdir. Toplantılarda, uzmanlar kendi alanlarındaki bilgileri paylaşır, sorulara cevap verir, stratejik yönlendirmelerde bulunur ve proje veya ürün hakkında kritik görüşler sunarlar. Domain expertler, ekip üyelerine ve yöneticilere projenin teknik veya konuyla ilgili yönlerini açıklar ve yardımcı olurlar.
Yöneticiler, proje veya işletme için karar verici pozisyonda olan kişilerdir ve toplantılara davet edilmeleri önemlidir. Yöneticiler, projenin veya ürünün stratejik hedeflerini anlamak ve yönlendirmek için toplantılara katılmalıdır. Ayrıca, yöneticilerin toplantılarda bilgi paylaşması, kararlar alması ve ekibin ilerlemesini izlemesi gerekebilir. Yöneticiler, projenin genel vizyonunu ve hedeflerini temsil ederler ve bu nedenle toplantılarda yer almaları, proje başarısı için önemlidir.
Ama yöneticilerin katılımı ekip üyeleri üzerinde baskı da yaratabilir. Bu konu hakkında ne düşünüyorsun? Bazı durumlarda davet etmemek daha iyi olabilir mi?
Evet, bazı durumlarda yöneticilerin katılımı, ekip üyeleri üzerinde baskı yaratabilir. Ekip üyeleri, yöneticilerin varlığında kendilerini rahatsız veya çekingen hissedebilirler ve bu da açık iletişim ve katılımı olumsuz etkileyebilir. Ayrıca, yöneticilerin bulunduğu toplantılarda, ekip üyeleri kendi fikirlerini veya endişelerini ifade etmekte tereddüt edebilirler.
Bu nedenle, yöneticilerin toplantılara davet edilip edilmemesi konusu dikkatlice değerlendirilmelidir. İşbirliği, katılım ve açık iletişimi teşvik etmek için bazı durumlarda yöneticilerin toplantılardan uzak tutulması tercih edilebilir olabilir. Özellikle yaratıcı fikirlerin ortaya çıktığı veya sorunların çözüldüğü beyin fırtınası veya işbirliği odaklı oturumlar gibi durumlarda, ekip üyelerinin daha rahat hissetmesi ve düşüncelerini özgürce ifade edebilmesi önemlidir.
Ancak, yöneticilerin toplantılara katılımı bazı durumlarda da gereklidir. Özellikle stratejik kararların alındığı, ilerleme raporlarının sunulduğu veya projenin genel hedeflerinin tartışıldığı toplantılarda, yöneticilerin katılımı önemlidir. Yöneticiler, projenin veya işletmenin yönlendirilmesi ve başarıya ulaşması konusunda sorumluluk taşıdıkları için bu tür toplantılarda bilgi sahibi olmalı ve karar alma süreçlerine katılmalıdırlar.
Sonuç olarak, yöneticilerin toplantılara davet edilip edilmemesi durumu, toplantının amacına, konuya ve katılımcıların ihtiyaçlarına bağlı olarak değerlendirilmelidir. İhtiyaçlar ve dinamikler göz önüne alınarak, bazı durumlarda yöneticilerin katılımının azaltılması veya çeşitli toplantı formatlarının kullanılması daha uygun olabilir.
Domain storytelling DDD ilişkisi nedir ve Event Storming'den fark nedir?
Domain storytelling ve Domain-Driven Design (DDD) arasında yakın bir ilişki vardır. DDD, bir yazılım projesinin tasarımını ve uygulamasını, iş domainine odaklanarak gerçekleştiren bir yaklaşımdır. Domain storytelling ise, DDD'nin bir parçası olarak kullanılan bir teknik veya araçtır. Domain storytelling, DDD'nin temel prensiplerini ve fikirlerini iletişim ve paylaşım yoluyla uygulamak için kullanılır.
Domain storytelling, bir iş sürecini, bir sistemi veya bir özelliği anlamak ve tanımlamak için hikaye anlatma tekniklerini kullanır. Bu hikaye, bir yazılım projesinin iş domainini ve kullanıcıları, sistemleri ve etkileşimleri arasındaki ilişkileri açıklamak için kullanılır. Bu da DDD'nin temel fikirlerini ve prensiplerini uygulamak için bir yol sunar.
Öte yandan, Event Storming, bir iş sürecini veya bir yazılım projesini analiz etmek ve anlamak için kullanılan bir atölye çalışması veya işbirliği yöntemidir. Event Storming, bir grup insanın bir araya gelerek, iş domainini ve etkileşimlerini hızlı bir şekilde keşfetmesini ve anlamasını sağlar. Katılımcılar, domaindeki önemli olayları ve bu olaylar arasındaki ilişkileri keşfetmek ve görselleştirmek için post-it notlar ve duvarlar üzerinde çalışır.
Event Storming, DDD'nin bir parçası olarak kullanılan bir yöntemdir ve genellikle DDD projelerinde hikaye anlatmanın bir parçası olarak uygulanır. Event Storming, bir yazılım projesinin hikayesini, iş domainini ve etkileşimleri hızlı ve görsel bir şekilde keşfetmek için kullanılır.
İki yöntem arasındaki fark, odaklandıkları noktalarda yatar. Domain storytelling, bir hikaye anlatma tekniği olarak daha genel bir şekilde kullanılabilirken, Event Storming daha spesifik bir atölye çalışmasıdır ve genellikle bir yazılım projesinin analiz ve keşfi için kullanılır. Domain storytelling, hikaye anlatarak bir iş sürecini veya özelliği anlamak için daha bireysel bir yaklaşım sunarken, Event Storming daha çok bir grup işbirliği ve keşif yöntemidir.
Birlikte kullanıldığında, Domain storytelling ve Event Storming, bir yazılım projesinin iş domainini anlamak, gereksinimleri belirlemek ve etkili bir şekilde iletişim kurmak için güçlü araçlar sağlar.
Domain storytelling user story çıkarmak için kullanılır mı?
Evet, domain storytelling, user story çıkarmak için kullanılan bir yöntem olabilir. Domain storytelling, kullanıcıların ihtiyaçlarını ve iş süreçlerini anlamak için hikaye anlatımını kullanırken, user storyler ise kullanıcıların ihtiyaçlarını ifade etmek için kullanılan kısa açıklamalardır. Domain storytelling sürecinde oluşturulan hikayeler, daha sonra user storyler olarak dönüştürülebilir.
Domain storytelling, kullanıcıların hedefleri, beklentileri ve etkileşimleri hakkında daha derin bir anlayış sağlar. Bu hikayeler, daha sonra user storyler haline getirilerek, geliştirme ekibi tarafından kullanılabilir. User storyler, projenin gereksinimlerini, kullanıcı ihtiyaçlarını ve beklenen sonuçları ifade eder. Bu şekilde, domain storytelling, user storylerin temelini oluşturabilir ve daha iyi bir gereksinim analizi ve planlama sürecine yardımcı olabilir.
Domain storytelling'in user story çıkarma sürecinde kullanılması, kullanıcıların perspektifinden gereksinimleri daha net bir şekilde anlama ve iletişim kurma avantajı sağlar. Ayrıca, hikaye anlatma tekniği, ekip üyeleri arasında işbirliği ve anlayışı artırabilir. Bu, daha iyi bir proje yönetimi ve geliştirme süreci için önemli bir katkı sağlayabilir.
Ancak, domain storytelling'in kullanıcı hikayelerini doğrudan user storylere dönüştürmek için tek başına yeterli olmadığını unutmamak önemlidir. User storyler, daha spesifik ve ölçülebilir olmalıdır. Bu nedenle, domain storytelling sürecinden çıkan hikayeler, gereksinimleri daha iyi ifade etmek için daha fazla detaylandırılmalı ve gerektiğinde user story formatına dönüştürülmelidir.
Domain expertler domain storytelling için ne öneme sahiptir?
Domain expertler, domain storytelling için büyük bir öneme sahiptir. Onlar, belirli bir iş domaininde derinlemesine bilgi ve deneyime sahip olan kişilerdir. Domain expertlerin katılımı, domain storytelling sürecinin başarılı bir şekilde gerçekleştirilmesi için kritik öneme sahiptir ve aşağıdaki nedenlerle önemlidir:
İçgörü ve Doğruluk: Domain expertler, iş domainindeki süreçleri, etkileşimleri ve kullanıcıların ihtiyaçlarını en iyi şekilde anlarlar. Bu bilgi ve deneyimleri, hikaye anlatma sürecinde doğru ve gerçekçi hikayeler oluşturmak için kullanılabilir. Domain expertlerin katkıları, hikayelerin daha içgörülü, doğru ve uygun olmasını sağlar.
Doğru Gereksinimlerin Tanımlanması: Domain expertler, iş domainindeki gereksinimleri belirlemede ve ifade etmede önemli bir rol oynarlar. Onların katkıları, kullanıcıların ihtiyaçlarını daha iyi anlamak, doğru gereksinimleri tanımlamak ve user storylerin oluşturulmasına yardımcı olmak için değerlidir. Domain expertler, gereksinimleri daha spesifik ve ölçülebilir bir şekilde ifade etmede önemli bir rol oynayabilir.
İş Süreçlerinin ve Etkileşimlerin Açıklanması: Domain expertler, iş domainindeki süreçleri, etkileşimleri ve işbirliklerini en iyi şekilde anlayan kişilerdir. Hikaye anlatma sürecinde, domain expertlerin katılımı, bu süreçleri ve etkileşimleri daha iyi açıklamak ve görselleştirmek için önemlidir. Onlar, hikayelerin daha kapsamlı ve anlaşılır olmasını sağlar ve ekip üyeleri arasında bir ortak anlayış oluşturur.
Hata ve Yanlış Anlamaların Azaltılması: Domain expertlerin doğrudan katılımı, hataları ve yanlış anlamaları azaltmaya yardımcı olur. Onlar, yanlış anlaşılan veya eksik bilgileri tespit etmek ve düzeltmek için değerli bir kaynaktır. Bu, gereksinimlerin daha doğru bir şekilde anlaşılmasını ve projenin başarıyla ilerlemesini sağlar.
Domain expertlerin katılımı, domain storytelling sürecinde doğru ve geçerli hikayelerin oluşturulmasını sağlar. Onlar, doğru gereksinimlerin belirlenmesine, iş süreçlerinin açıklanmasına ve yanlış anlamaların azaltılmasına yardımcı olurlar. Bu nedenle, domain expertlerin perspektifi ve bilgisi, domain storytelling sürecinin başarılı bir şekilde gerçekleştirilmesinde önemli bir faktördür.
Domain Stroytelling interview soruları ve cevapları
İşe alım sürecinde Domain Storytelling becerilerini değerlendirmek için aşağıda bazı sorular ve olası cevaplar bulunmaktadır:
Soru: Bir iş sürecini veya sistemi anlamanızı sağlayan bir hikaye anlatın.
Olası Cevap: "Bir online alışveriş sitesi düşünelim. Kullanıcının ürünü seçip sepete eklemesi, ödeme yapması ve teslimatı takip etmesi gibi adımlardan oluşan bir hikaye oluşturabilirim. Kullanıcı, ürün arayışına başlar, seçimini yapar ve sepete ekler. Ardından, ödeme bilgilerini girer ve siparişi tamamlar. Son olarak, teslimat sürecini takip eder ve ürünü alır."
Soru: Bir hizmetin veya ürünün müşteriye nasıl değer kattığını açıklayan bir hikaye anlatın.
Olası Cevap: "Bir müşteri destek yazılımı düşünelim. Bir müşteri, bir sorun veya soruyla karşılaştığında, destek talebini oluşturur ve gönderir. Destek ekibi, talebi alır, sorunu anlar ve çözüm için çalışır. Müşteri, süreci takip eder ve sonunda sorunu çözülür. Bu hikaye, müşterinin sorunlarına çözüm sunarak onlara değer katan bir hizmeti tanımlar."
Soru: Bir sürecin veya sistemin zorluklarını veya eksikliklerini belirten bir hikaye anlatın.
Olası Cevap: "Bir proje yönetim yazılımını ele alalım. Bir proje yöneticisi, projeleri takip etmek, görevleri atamak ve ilerlemeyi izlemek için bu yazılımı kullanır. Ancak, kullanıcı arayüzü karmaşık ve kullanımı zordur. Ayrıca, bazı raporlama ve analitik özellikler eksik olabilir. Bu hikaye, yazılımda karşılaşılan zorlukları ve iyileştirme fırsatlarını açıklayarak sürecin eksikliklerini ortaya koyar."
Soru: Bir süreç veya sistemdeki iyileştirme veya geliştirme önerilerini açıklayan bir hikaye anlatın.
Olası Cevap: "Bir iş sürecini ele alalım. Manuel veri girişi gerektiren bir süreç var. Bu süreç, zaman alıcı ve hatalara neden olabilir. Önerim, otomatik veri entegrasyonu veya bir veri giriş arayüzü eklemek olurdu. Bu şekilde, manuel işlem süresini azaltabilir, veri doğruluğunu artırabilir ve genel verimliliği geliştirebiliriz."
Bu sorular, bir adayın Domain Storytelling becerilerini değerlendirmek için kullanılabilir. Cevaplar, adayın hikaye anlatma yeteneği, iş süreçlerini ve sistemleri anlama yeteneği ve iletişim becerileri hakkında bilgi sağlayabilir. Ancak, gerçek bir mülakatta, adayın tecrübeleri ve kendi örnekleriyle daha ayrıntılı olarak değerlendirilmesi gerekebilir.
Soru: Bir yazılım projesinde domain storytelling'i nasıl kullanırdınız?
Olası Cevap: "Bir yazılım projesinde, domain storytelling'i kullanarak iş süreçlerini ve kullanıcıların ihtiyaçlarını anlamak için hikayeler oluştururdum. Önce, paydaşlarla görüşür ve onların beklentilerini, hedeflerini ve zorluklarını anlamaya çalışırdım. Sonra, bu bilgileri kullanarak, hikaye anlatma tekniklerini kullanarak süreçleri ve etkileşimleri anlatan görsel çizimler oluştururdum. Bu, yazılımın kullanıcıların ihtiyaçlarını nasıl karşılayacağını ve iş süreçlerini nasıl iyileştireceğini daha net bir şekilde göstermeme yardımcı olur."
Soru: Domain storytelling'in bir yazılım projesinde hangi avantajları olduğunu düşünüyorsunuz?
Olası Cevap: "Domain storytelling, bir yazılım projesinde birkaç avantaj sunar. İlk olarak, hikaye anlatma teknikleri, karmaşık süreçleri veya sistemler arası etkileşimleri daha anlaşılır hale getirir ve tüm paydaşların aynı sayfada olmasını sağlar. İkinci olarak, hikayeler, kullanıcıların ihtiyaçlarını ve hedeflerini vurgulayarak kullanıcı odaklı bir yaklaşım sağlar. Ayrıca, hikayeler, fikirleri ve beklentileri paylaşmayı teşvik eder ve ekip üyeleri arasında daha iyi bir işbirliği ve anlayış oluşturur."
Soru: Domain storytelling sürecinde karşılaştığınız zorluklar nelerdir ve bunları nasıl çözersiniz?
Olası Cevap: "Domain storytelling sürecinde bazı zorluklarla karşılaşılabilir. Örneğin, bazı karmaşık iş süreçlerinin veya sistemlerin tüm detaylarını hikaye anlatma formatında sunmak zor olabilir. Bu durumda, daha özetleyici ve odaklanmış bir yaklaşım benimseyerek ana noktaları vurgulamaya çalışırım. Ayrıca, paydaşların farklı beklentileri veya anlayışları olabilir. Bu durumda, açık iletişim ve işbirliği yoluyla ortak bir anlayış oluşturmak için ekstra çaba sarf ederim."
Bu sorular ve cevaplar, bir adayın Domain Storytelling becerilerini ve deneyimlerini değerlendirmeye yardımcı olabilir. Ancak, gerçek bir mülakatta, adayın daha fazla örnek sunması, düşüncelerini derinleştirmesi ve proje veya senaryolar üzerinde daha fazla ayrıntı paylaşması gerekebilir.
Soru: Domain storytelling'i kullanarak bir iş sürecini veya sistemi anlattığınızda, hangi yöntemleri veya araçları tercih edersiniz?
Olası Cevap: "Domain storytelling sürecinde, görsel çizimler ve diagramlar oluşturmak için genellikle beyaz tahta veya poster kağıtları kullanırım. Bu, hikayenin görsel bir şekilde anlaşılmasını ve katılımcıların daha iyi bir şekilde ilişki kurmasını sağlar. Ayrıca, post-it notlarını ve farklı renklerle yazmayı tercih ederim, böylece farklı bileşenleri ve ilişkileri daha iyi görselleştirebilirim. Buna ek olarak, diğer katılımcıların da hikayeye katkıda bulunmasını sağlamak için açık tartışma ve beyin fırtınası tekniklerini kullanırım."
Soru: Domain storytelling'i kullanarak bir yazılım projesinde paydaşları nasıl etkileşime geçirirdiniz?
Olası Cevap: "Domain storytelling sürecinde, paydaşları etkileşime geçirmek ve katılımlarını sağlamak için düzenli toplantılar ve atölye çalışmaları düzenlerim. Onları hikayenin oluşturulmasına ve geliştirilmesine dahil etmek için aktif olarak sorular sorarım ve fikirlerini paylaşmalarını teşvik ederim. Ayrıca, katılımcılara hikayenin her aşamasında geri bildirim verme fırsatı sunarım ve onların düşüncelerini ve önerilerini dikkate alırım. Bu şekilde, paydaşların sürece dahil olmalarını ve projenin başarısını desteklemelerini sağlarım."
Soru: Domain storytelling'i kullanmanın bir yazılım projesindeki avantajları nelerdir?
Olası Cevap: "Domain storytelling, bir yazılım projesinde birçok avantaj sunar. İlk olarak, tüm paydaşların ortak bir anlayışa sahip olmasını sağlar ve proje gereksinimlerini daha net bir şekilde iletebilir. İkinci olarak, hikayeler, kullanıcı odaklı bir yaklaşımı destekleyerek müşteri ihtiyaçlarını daha iyi anlamayı sağlar. Ayrıca, hikaye anlatma, karmaşık iş süreçlerini veya sistemleri daha anlaşılır ve görsel bir şekilde sunarak iletişimi geliştirir. Bu da daha iyi bir işbirliği ve verimli bir proje geliştirme süreci sağlar."
Bu sorular ve cevaplar, bir adayın Domain Storytelling becerilerini ve deneyimlerini değerlendirmeye yardımcı olabilir. Ancak, gerçek bir mülakatta, adayın daha fazla örnek sunması, düşüncelerini derinleştirmesi ve proje veya senaryolar üzerinde daha fazla ayrıntı paylaşması gerekebilir.
Soru: Domain storytelling'i kullanarak bir yazılım projesinde işbirliğini nasıl teşvik edersiniz?
Olası Cevap: "Domain storytelling, işbirliği için etkili bir araçtır. Bir yazılım projesinde, paydaşlar arasında işbirliğini teşvik etmek için düzenli paydaş toplantıları ve atölye çalışmaları düzenlerim. Bu toplantılarda, hikaye anlatma tekniğini kullanarak paydaşların görüşlerini ve fikirlerini paylaşmasını teşvik ederim. Ayrıca, farklı perspektiflerden gelen insanları bir araya getirerek daha kapsamlı bir anlayış oluşturmayı hedeflerim. İşbirliğini desteklemek için açık iletişim, aktif dinleme ve geri bildirim alma ve verme süreçlerini kullanırım."
Soru: Domain storytelling sürecinde kullanıcı ihtiyaçlarını nasıl anlarsınız?
Olası Cevap: "Domain storytelling sürecinde, kullanıcı ihtiyaçlarını anlamak için kullanıcıları aktif olarak dahil ederim. Kullanıcıları anlamak için kullanıcı araştırmaları, kullanıcı mülakatları veya kullanıcı testleri gibi kullanıcı merkezli yöntemleri kullanırım. Kullanıcıların günlük rutinlerini, hedeflerini, sorunlarını ve beklentilerini anlamaya çalışırım. Bu bilgileri kullanarak, hikaye anlatma sürecinde kullanıcıların ihtiyaçlarını vurgulayan senaryolar oluşturur ve süreci daha kullanıcı odaklı hale getiririm."
Soru: Domain storytelling'i kullanarak karmaşık bir iş sürecini nasıl basitleştirirsiniz?
Olası Cevap: "Karmaşık bir iş sürecini basitleştirmek için, domain storytelling sürecinde odaklanılacak anahtar noktaları belirlerim. Karmaşık süreci basit bir şekilde anlamak için, sürecin başlangıcını, çıktılarını ve önemli adımlarını belirlerim. Bu adımları ve ilişkileri basitleştirmek için görsel çizimler ve basit simgeler kullanırım. Ayrıca, karmaşık süreci daha anlaşılır hale getirmek için açıklayıcı metinler veya açıklamalar eklerim. Bu şekilde, hikaye anlatma sürecinde karmaşık süreci daha anlaşılır ve erişilebilir bir şekilde sunabilirim."
Bu sorular ve cevaplar, bir adayın Domain Storytelling becerilerini ve deneyimlerini değerlendirmeye yardımcı olabilir. Gerçek bir mülakatta, adayın daha fazla örnek sunması, düşüncelerini derinleştirmesi ve projeler veya senaryolar üzerinde daha fazla ayrıntı paylaşması beklenir. Ayrıca, mülakatta adayın problem çözme becerileri, iletişim yetenekleri ve işbirliği yetkinlikleri de değerlendirilebilir.
Soru: Domain storytelling'in proje paydaşlarıyla iletişimi nasıl geliştirdiğini açıklayabilir misiniz?
Olası Cevap: "Domain storytelling, proje paydaşlarıyla iletişimi geliştirmek için etkili bir araçtır. Hikaye anlatma sürecinde, paydaşlar projenin iş domainini ve gereksinimlerini daha iyi anlamak için bir araya gelirler. Bu, paydaşların aynı sayfada olmasını ve projenin hedeflerine ortak bir vizyonla yaklaşmalarını sağlar. Hikaye anlatma, görsel çizimler ve senaryolar kullanarak karmaşık kavramları ve etkileşimleri basitleştirir. Bu da paydaşların projenin işleyişini daha iyi anlamalarına yardımcı olur ve gereksinimlerin daha net bir şekilde iletilmesini sağlar. Bu süreç, paydaşlar arasında daha iyi bir iletişim ve işbirliği sağlar."
Soru: Domain storytelling sürecinde kullanılan görsel çizimlerin paydaşlarla nasıl paylaşılacağını açıklayabilir misiniz?
Olası Cevap: "Domain storytelling sürecinde kullanılan görsel çizimler, paydaşlarla paylaşmak için farklı yöntemler kullanılabilir. Öncelikle, çizimleri dijital veya fiziksel ortamlarda paydaşlarla paylaşılabilir. Fiziksel ortamlarda, beyaz tahta, poster kağıdı veya büyük bir kağıt kullanılabilir ve paydaşlarla yüz yüze toplantılarda gösterilebilir. Dijital ortamlarda ise, çizimler sunum veya dokümantasyon aracılığıyla paydaşlarla paylaşılabilir. Ayrıca, paydaşlarla interaktif bir şekilde etkileşime girebilmek için dijital araçlar ve işbirliği platformları da kullanılabilir. Önemli olan, çizimlerin anlaşılır ve erişilebilir bir şekilde sunulması ve paydaşların görüşlerini ve geri bildirimlerini paylaşmaları için ortamın yaratılmasıdır."
Soru: Domain storytelling sürecinde çıkan hikayelerin nasıl dokümante edileceğini açıklayabilir misiniz?
Olası Cevap: "Domain storytelling sürecinde çıkan hikayelerin dokümante edilmesi önemlidir. Bu, hikayelerin gelecekte referans olarak kullanılmasını sağlar. Dokümantasyon için farklı yöntemler kullanılabilir. Örneğin, çizimler ve diagramlar, fotoğraflanabilir veya taranabilir ve bir dokümantasyon sistemine kaydedilebilir. Ayrıca, hikayeler metin formatına dökülebilir ve bir doküman veya sunum dosyası olarak saklanabilir. Bu dokümantasyon, proje sürecinde paydaşlarla ve ekip üyeleriyle paylaşılabilir ve gereksinimlerin, tasarımların ve geliştirmelerin takibi için kullanılabilir."
Bu sorular ve cevaplar, bir adayın Domain Storytelling becerilerini ve deneyimlerini değerlendirmeye yardımcı olabilir. Gerçek bir mülakatta, adayın daha fazla örnek sunması, düşüncelerini derinleştirmesi ve projeler veya senaryolar üzerinde daha fazla ayrıntı paylaşması beklenir. Ayrıca, adayın iletişim becerileri, paydaş yönetimi ve dokümantasyon yetenekleri de değerlendirilebilir.
Domain storytelling de oluşturulan hikayelerden scrum'daki user storyler arasındaki ilişki nedir?
Domain storytelling ve Scrum'daki user storyler arasında bir ilişki vardır. Her ikisi de yazılım geliştirme sürecinde gereksinimleri anlamak ve iletmek için kullanılan yöntemlerdir. İşte bu iki kavram arasındaki ilişkiyi açıklamak için bazı noktalar:
Kullanıcı Odaklılık: Her ikisi de kullanıcıların ihtiyaçlarını anlamak ve bunları geliştirme sürecine yansıtmak için odaklanır. Domain storytelling'de, hikaye anlatma yöntemiyle kullanıcıların hedefleri, beklentileri ve etkileşimleri anlatılır. Scrum'da ise user storyler, kullanıcıların ihtiyaçlarını ifade eden kısa ve net açıklamalardır.
Hikaye Anlatımı: Hem domain storytelling hem de Scrum'daki user storyler, bir hikaye anlatımı biçiminde ifade edilir. Domain storytelling'de, bir hikaye veya senaryo şeklinde iş süreçleri veya sistemler anlatılır. Scrum'da ise user storyler, bir kullanıcı veya paydaşın perspektifinden gereksinimleri ifade eden kısa cümlelerdir.
İletişim ve Paylaşım: Hem domain storytelling hem de Scrum'daki user storyler, ekip üyeleri arasında etkili iletişim ve paylaşımı teşvik eder. Domain storytelling, paydaşlar arasında bir ortak anlayış oluşturmayı hedeflerken, Scrum'da user storyler, ürün sahibi, geliştiriciler ve diğer ekip üyeleri arasında gereksinimleri paylaşmak ve anlamak için kullanılır.
Planlama ve Geliştirme: User storyler, Scrum'daki sprint planlaması ve geliştirme sürecinin temel bir parçasıdır. Scrum ekibi, user storyleri kullanarak sprint hedeflerini belirler ve işi parçalar. Domain storytelling ise, geliştirme öncesinde veya gereksinim analizi aşamasında kullanılır ve projenin genel vizyonunu ve hedeflerini anlamak için bir yol sağlar.
Özet olarak, domain storytelling, kullanıcıların ihtiyaçlarını ve iş süreçlerini anlamak için hikaye anlatımını kullanırken, Scrum'daki user storyler, kullanıcı ihtiyaçlarını ifade eden kısa açıklamalar olarak kullanılır ve sprint planlaması ve geliştirme sürecinin bir parçasıdır. Her ikisi de kullanıcı odaklılığı, hikaye anlatımını ve iletişimi teşvik eder.
Domain storytelling resmi sitesi :
https://domainstorytelling.org/
Araçlar :
Egon.io : Domain storytelling'ler oluşturmak için basit bir araç.
Kitaplar :
Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software : https://learning.oreilly.com/library/view/domain-storytelling-a/9780137458974/