Atlassian şirketi Do Agile Right adında bir webinar serisine başladı. Atlassian Jira ve Confluence gibi ürünleri geliştiren şirket olduğundan ilgimi çekti ve 28 Ocak 2014 tarihli ilk webinar'ı offline olarak youtube üzerinden izledim. Software Development üzerine bolca bilgi beklerken farkı ama ilgi çekici bir içerik ile karşılaştım ve paylaşmak istedim.
Eklenecek özellik ile ilgili olarak karar verildikten sonra akış üzerinden geçiliyor. Bunu da gene görselliği ön planda tutarak yapıyorlar. Bir odayı tamamen akış ile kaplıyorlar ve yürüyerek adım adım üzerinden gidiyorlar. Sonrasında ekip ile bu odada akışların yanında dikilerek sesli olarak tartışıyorlar.
Her tasarım bir fikir ile başlıyor ve bu fikrin gelişimi için önerdikleri bir şablon var, bu şablon sadece yeni eklentiler için değil sorunların düzeltilmesi için de kullanılıyor. Kullanıcı ile etkileşimi olan güncellemeleri diğerlerinden ayırıyorlar. Bir güncelleme için birden çok yol bulunmasını ve mutlaka hepsinin değerlendirilerek kayıt altına alınmasını öneriyorlar. Oldukça radikal tartışmalar yapılmasından yanalar, bu kısım hatalı kalsa ne olur gibi konularında değerlendirilmesi gerektiğini söylüyorlar.
Müşteri fikirleri ve katkıları için müşteriler ile birebir görüşmeler ayarlanıyor. Bunlar anladığım kadarıyla çok resmi havada geçmiyor. Her pozisyondan insanın mutlaka yapacağı işi kullanacak olan müşteri ile tanıştırmaya çalışıyorlar. Anladığım kadarıyla sadece mevcut müşteriler ile değil, potansiyel müşteriler ile de bu tür iletişim halindeler.
Bu görüşmelerin içerik ve sonuçlarını merkezi bir ortama mutlaka kaydediyorlar. Başlık, Label kullanımı ve ilgili/benzer konular ile ilişkilendiriyorlar. Bunun için confluence ürününü kullanıyorlar, detaylarını bir alt konuda paylaşacağım.
Public bir jira'ları var, ürünler ile ilgili istekleri buradan topluyorlar, bu jira sadece müşterilere değil herkese açık. Bu ortam'da teknik ekip ile isteği yapan son kullanıcılar birebir iletişime de geçme fırsatı buluyor.
Confluence veya Jira üzerinde tutulan tüm veriler, planlar, ihtiyaçlar, vs, şirketin tüm çalışanlarına açık. Burada amaç sadece bu verileri kayıt altına almak değil, her görevdeki kişinin kolay ve basitçe erişebileceği şekilde sunmak. Bunlar uygun yapıldığında herkesden yorum ve katkı alınabiliyor. Benzer veya belki de aynı işin hali hazırda yapılmış olduğunu ve nasıl yapıldığını ilgili kişiler yorum/öneri olarak görebiliyorlar. Tüm bunlar şirketin gelişen ürününe her ekip üyesinin aynı şekilde bakmasına da imkan sağlıyor.
24:30 - 35:00 arası (John Masson);
Bu kısım tasarım aşamasında prototip kullanımı üzerine ayrılmış.
Sonrasında soru cevap kısımları yer alıyor. Alttaki kısımlar benim aklımda kalan sorular...
Lessons learned from an Atlassian product manager (28.01.2014)
Webinar youtube adresinden izlenebilir. Yaklaşık 53 dakika, ilk 5 dakikası ne nedir bilgileri ile geçiyor, 35. dakikadan sonra da soru-cevap kısmı var. 5 ile 35 arası ise 2 konuşmacıyı dinliyoruz.
05:40-24:00 arası (Sherif Mansour);
Poll : What tool do you primarily use to define requirements?
Bu kısmın amacını şu başlıklarla özetleyebilirim;
- Müşteri beklentilerinin en uygun şekilde alınması, bu beklentilerin herkese sürekli hatırlatılması
- Ürün geleceğinin planlanması,
- Tüm geri bildirimlerin, ihtiyaç ve taleplerin merkezi ortamda toplanması,
- Merkezi ortama herkesin dahil olmasının, katkı yapmasının sağlanması
- İlişkili veya kesişen planların görüntülenmesi ve hızlı, basit şekilde herkesin erişiminin sağlanması
Burada şu cümle çok hoşuma gitti, "a big company works like a small team."
Detaylara girersek beni en çok şaşırtan müşteri beklentilerinin alınması oldu. Müşteri beklentileri her yapılan işte çok önemlidir ama Atlassian ekiplerinin bunu yapış şekilleri ilginç, açıkçası bu kadarını beklemiyordum.
Personas dedikleri kartları var, ürünlerini kullanan müşterileri için bunlardan oluşturuyorlar, daha doğrusu müşterileri temsil eden hayali karakterler oluşturuyorlar. Bu karakterler için 1-2 yılda 400 civarı müşteri ile röportaj yapmışlar ve bunları uygun karakterler ile ilişkilendirerek güncellemişler. Bu şekilde müşterileri tanıyorlar, alttaki örneklere bakarsanız bu kartlar oldukça detaylı hazırlanıyor, içerikleri sadece ürün ile ilgili değil. Kartlar sayesinde bu sistemleri kimin için tasarlıyoruz sorusuna net yanıtlar bulabiliyorlar. Diğer ilginç nokta ise bu kartların dijital ortamda herkese açık olması, duvarlarda, herkesin sürekli görebileceği diğer yerlerde (Ör: Pisuvar önü :)) bulunuyor. Herkes dediğimin altını çizmek isterim, sadece ürünün geleceğini planlayan yöneticiler değil, tüm çalışanlar bu kartları sürekli görüyor. Bu sayede şu özelliği eklersek Emma bunu kesin çok sever gibi önerileri her pozisyondaki çalışanlardan alabiliyorlar...
Eklenecek özellik ile ilgili olarak karar verildikten sonra akış üzerinden geçiliyor. Bunu da gene görselliği ön planda tutarak yapıyorlar. Bir odayı tamamen akış ile kaplıyorlar ve yürüyerek adım adım üzerinden gidiyorlar. Sonrasında ekip ile bu odada akışların yanında dikilerek sesli olarak tartışıyorlar.
Her tasarım bir fikir ile başlıyor ve bu fikrin gelişimi için önerdikleri bir şablon var, bu şablon sadece yeni eklentiler için değil sorunların düzeltilmesi için de kullanılıyor. Kullanıcı ile etkileşimi olan güncellemeleri diğerlerinden ayırıyorlar. Bir güncelleme için birden çok yol bulunmasını ve mutlaka hepsinin değerlendirilerek kayıt altına alınmasını öneriyorlar. Oldukça radikal tartışmalar yapılmasından yanalar, bu kısım hatalı kalsa ne olur gibi konularında değerlendirilmesi gerektiğini söylüyorlar.
Müşteri fikirleri ve katkıları için müşteriler ile birebir görüşmeler ayarlanıyor. Bunlar anladığım kadarıyla çok resmi havada geçmiyor. Her pozisyondan insanın mutlaka yapacağı işi kullanacak olan müşteri ile tanıştırmaya çalışıyorlar. Anladığım kadarıyla sadece mevcut müşteriler ile değil, potansiyel müşteriler ile de bu tür iletişim halindeler.
Bu görüşmelerin içerik ve sonuçlarını merkezi bir ortama mutlaka kaydediyorlar. Başlık, Label kullanımı ve ilgili/benzer konular ile ilişkilendiriyorlar. Bunun için confluence ürününü kullanıyorlar, detaylarını bir alt konuda paylaşacağım.
Public bir jira'ları var, ürünler ile ilgili istekleri buradan topluyorlar, bu jira sadece müşterilere değil herkese açık. Bu ortam'da teknik ekip ile isteği yapan son kullanıcılar birebir iletişime de geçme fırsatı buluyor.
Confluence veya Jira üzerinde tutulan tüm veriler, planlar, ihtiyaçlar, vs, şirketin tüm çalışanlarına açık. Burada amaç sadece bu verileri kayıt altına almak değil, her görevdeki kişinin kolay ve basitçe erişebileceği şekilde sunmak. Bunlar uygun yapıldığında herkesden yorum ve katkı alınabiliyor. Benzer veya belki de aynı işin hali hazırda yapılmış olduğunu ve nasıl yapıldığını ilgili kişiler yorum/öneri olarak görebiliyorlar. Tüm bunlar şirketin gelişen ürününe her ekip üyesinin aynı şekilde bakmasına da imkan sağlıyor.
24:30 - 35:00 arası (John Masson);
Bu kısım tasarım aşamasında prototip kullanımı üzerine ayrılmış.
- Prototipler interactif olmalıdır. Mockup, wireframe, photoshop prototip değildir.
- Kullanıcı ilişkisi olmayan yerler için prototip yapılmasına gerek yoktur.
- Yapılamayacak kadar zor, her seferinde yapılması çok uzun zaman alacak prototiplerden kaçınmak gereklidir.
- Prototipler geliştirme öncesinde, akışlarda yaşanabilecek sorunları tamamen engellemez ancak kağıt veya sözde kalan tasarımlara göre çok daha etkili olarak sıkıntıların önceden belirlenmesine imkan sağlar.
- Etkileşimli prototiplere her pozisyondan çalışan, hatta müşteri bile dahil edilmelidir, bazı denemeler grup halinde yapılmalıdır. Bu sayede geliştirme yapacak teknik çalışanların hem müşteri beklentilerine hem de potansiyel sorunlara önceden önlem alması sağlanır.
- İlk zamanlarda geliştirme maliyeti olsa da, uzun vadede uygun kullanılan prototipler aslında zaman kazandıracaktır.
Sonrasında soru cevap kısımları yer alıyor. Alttaki kısımlar benim aklımda kalan sorular...
- Az dokümantasyon ile QA işleyisinde nasıl sıkıntılar yaşanabiliyor ve önlemleri neler?
- Çok sayıda PM agile bir projede neden var?
- Persona nasıl hazırlanıyor ve biraz daha detay.