Kitap İncelemesi: Sprint — How To Solve Big Problems And Test New Ideas In Just Five Days
Özet: Design Sprint için kullanıcı odaklı tasarım sürecinin 5 günlük bir versiyonu diyebiliriz. Jake Knapp ve arkadaşları, Sprint’in 5 gün içerisinde tamamlanabilmesi için farklı roller ve devamlılık için sıkı kurallar oluşturmuş. Ekip çalışmasının ve zaman yönetiminin işin merkezinde olduğu bu rehberi, ürün ekipleri, tasarım ofisleri ve start-up’lar rahatlıkla kullanabilir.
Sprint ile ilgili görüşlerimi 3 kısımda aktarmak istiyorum. Niyetim, sizin de rahatlıkla erişebileceğiniz bu rehberi birebir özetlemek değil.
1- İlk olarak ben bu kitabı neden okudum ile başlayacağım.
2- İkinci kısımda Design Sprint tekniğinin ne olduğuna, neden ve nasıl yapıldığına açıklık getireceğim. İkinci bölümün devamında ise kitabın içeriğine değineceğim.
3- Son kısımda ise Sprint tekniğini uygulamak isteyen ürün ekipleri, tasarım ofisleri ve start-up’lar için problem olabilecek varsayımlarımı ve tavsiyelerimi paylaşacağım.
Kısım 1: Sprint’i Neden Okudum?
Sprint piyasaya 8 ay önce çıkan bir kitap ancak tam zamanını hatırlamasam da, Sprint rehberi Google Ventures bünyesinde daha önce tasarım dünyasıyla paylaşılmıştı. O zamanlar şöyle bir bakmıştım ama detaylı olarak incelememiştim.
Kitabı alıp okuma ihtiyacı ise, Hürriyet mobil uygulaması için yapacağımız işleri belli bir yapı ve düzene oturtabilmek adına ekip olarak araştırma yaparken ortaya çıktı. Tüm paydaşları, fikir ve karar alma sürecine dahil edebilecek bir şeyler bulmaya çalışırken aklıma geldi. Takımla bu öneriyi paylaştığımda, herkes denemek için hem fikir oldu. Kitabı okuyup inceleme işi de bana kaldı.
Bu rehberi kullanarak şu an kadar bir sprint koştuk. Bizim tecrübelerimizi birkaç sprint tamamladıktan sonra paylaşmak daha doğru ve faydalı olur. Dolayısıyla başka bir yazıda bunları ayrıca paylaşacağım.
Kısım 2: Kitabın Özeti ve İçeriği Hakkında Fikirlerim
Jake Knapp bu kitabı, Google Ventures’da beraber çalıştığı John Zeratsky ve Braden Kowitz ile birlikte yazmış. Tasarımcı Jake Knapp önce Google bünyesindeki ürünlerde bu tekniği denerken, daha sonra Google Ventures çatısı altında Kowitz ve Zeratsky ikilisine katılmış.
Birlikte mobil, e-ticaret, sağlık ve finans gibi farklı alanlarda 100'ün üzerinde sprint tamamlamışlar. Bu aslında şu anlama geliyor, kitapta okuduğunuz birçok kural ve tavsiye ekibin bu tecrübesi doğrultusunda zamanla oluşmuş.
Design Sprint, kullanıcı odaklı ve iteratif tasarım sürecinin 5 günlük bir versiyonu. 5 günlük bu çalışmanın ana öğeleri ise; katılanlara verilen roller, takım çalışması ve etkili bir zaman yönetimi diyebiliriz.
Roller
Decider
Decider için karar alıcı kişi diyebiliriz, özellikle ekibinin yoğunlaşacağı problemi, hangi çözümü hayata geçirecekleri gibi kritik noktalarda karar almaları gerekiyor. Bu kişi farklı ölçeklerde farklı kişiler olabilir. Yani kurumsal bir şirkette Ürün Yöneticisi olabilirken, 10 kişiden oluşan bir girişimde CEO olabilir.
Decider rolü en fazla 2 kişiye verilebilir..
Faciliator
Bu rol için, Sprint’in sürekliliğini ve verimli olmasını sağlayan kişi diyebiliriz. Görevleri arasında Sprint’le alakalı kuralları hatırlatmak, süreyi takip etmek gibi işler var. Çalıştay yönetenlerin fazlasıyla aşina olduğu bir işi, topluluğu yönetme ve yönlendirme işini yapar.
Sprint’in amacına ters düşen uzun tartışmalarda, Decider rolündeki kişiye ‘’Haydi arkadaşım bir karar ver devam edelim.’’ diyen kişidir.
5 Günlük Takvim
1.Gün — Hedef Belirleme
İlk gün hedef belirleme ile ilgili. Önce çalışmayla alakalı ne elde etmek istediğiniz belirliyorsunuz. Bu kısım oldukça kritik, çünkü aynı hedefe odaklanmayan bir ekip, faydayı farklı şekillerde tanımlayabiliyor. Daha sonra çalışmayla alakalı doğru soruları sormaya çalışıyorsunuz. Ele aldığınız problemle alakalı aktörlerin yolculuğunu haritalaştırdıktan sonra da sırayla uzmanları dinliyorsunuz. Günün sonunda ise en önemli kullanıcı ve anı belirleyerek ilk günü tamamlıyorsunuz.
2.Gün — Çözüm Geliştirme
İkinci gün sprint’e katılan herkesin önceden belirlediği örnekleri inceledikten sonra, skeç aşamasına geçiyorsunuz. Crazy 8 tekniğini kullanarak herkes bireysel olarak skeç yapıyor. Grupça değil, herkes tek başına ama aynı anda çalışıyor.
Salı günü aynı zamanda Cuma günü yapacağınız test için kullanıcı ayarlamaya başlıyorsunuz.
3.Gün — Karar Verme
Salı günü geliştirdiğiniz çözümleri oylayarak karar vermeniz gerekiyor. Tüm fikirler asılıyor, birlikte kritik ediliyor, oylanıyor. Oylama işleminin finalini, Supervote adı verilen 3 oy ile Decider rolündeki kişiler veriyor. Böylece hangi çözüm ya da çözümler üzerine çalışılacağı belirleniyor.
Kazanan çözümleri bir araya getirip, tek bir prototip üzerinden gidip gidemeyeceğinize karar veriyorsunuz. Daha sonra prototipinizin bir storyboard’unu çalışıp, planınızı yapıyorsunuz.
4.Gün — Tasarım Yapma
Sprint grubundaki kişileri Maker, Stitcher, Writer, Asset Collector ve Interviewer gibi farklı rollere atayarak tasarım sürecini hızlandırıyorsunuz. Tasarımları da tamamladıktan sonra prototip kısmına girişiyorsunuz. Prototipi tamamladıktan sonra bir deneme testi gerçekleştiriyorsunuz ve eksikleri tamamlayarak ertesi güne hazırlanıyorsunuz. Bu süre zarfında Interviewer kişisi Cuma günü yapacağı testin senaryolarını hazırlıyor ve kullanıcıları kontrol ediyor.
5.Gün — Test Günü
Test çalışması için 2 odaya ihtiyacınız var. Interviewer testleri gerçekleştirirken, ekibin geri kalanı başka bir odada not alıyor. Böylece analiz, video kesme ve sunum hazırlama işi aradan çıkmış oluyor. Oda teknik olarak teste hazır hale getiriliyor ve 5 kullanıcı ile test gerçekleştiriliyor.
Her görüşme sonrası ekip bir araya gelip, notlarını bir tahta üzerinde birleştirip, kısaca üzerinde konuşuyor. Testlerin sonunda ise tüm notlar incelenip, tekrar eden noktalar belirleniyor. Sonrasında ise bir sonraki sprint için neler yapılacağı konuşulup, çalışma tamamlanıyor 🎉
Kitabın içeriğine ve okunabilirliğine gelirsek, sürekli olarak İngilizce kitap okumayan biri olarak hiç zorlanmadan bitirdiğimi söyleyebilirim. Yazarlar sizinle 5 gün boyunca, adım adım hangi gün ne yapacağınızı ve nasıl yapmanız gerektiğini paylaşırken, uymanız gereken kuralları da paylaşıyor.
Kitapla alakalı güzel noktalarından biri, “Bunu neden böyle yapmışlar ki?” diyebileceğiniz kararları neden aldıklarını gerçek örnekler açıklıyor olmaları. Örneğin Decider rolünün neden çok kritik olduğunu, acı bir tecrübelerini paylaşarak açıklamışlar. Direkt olarak alıntılıyorum;
‘’We’d carefully invited everyone from SquidCo’s team who worked on the project. Everyone, that is, except for one person: Sam, SquidCo’s chief product officer. Sam was going to be traveling, but the week worked for everybody else. So we helped SquidCo run a sprint. They made a prototype and tested it. The prototype did well with their customers, and the team was ready to start building.
But when Sam returned, the project ended. What happened? The solution had tested well — but Sam didn’t think we had picked the right problem to solve in the first place. There were other, more important priorities for the team.
The SquickCo sprint failure was our fault. We’d tried to guess what Sam would say, and we’d failed. The Decider should have been in the room.’’
Kitap içerisinde yukarıdakine benzer, kimi zaman anonim kimi zaman gerçek hikayelerle ‘‘Neden?’’ sorularınıza cevap verebilecek çok güzel örnekler var.
Aynı örnekler, bir şey yaratacağınız adımlar için de geçerli. Daha önce tecrübe etmişsinizdir, tasarımla alakalı bazı konular görsel örneklerle desteklenme ihtiyacı duyarlar. Örneğin harita ya da storyboard oluşturma süreciyle alakalı görsel örnekleri kitapta bulabilirsiniz.
Son olarak kitapta bir checklist var. Unuttuğunuz kısımları hatırlayabilmek için oldukça kullanışlı.
Kısım 3: Ürün Ekipleri, Tasarım Ofisleri ve Start-Up’lar için Olası Problemler
Problem 1
Decider Kim Olacak?
Design Sprint’i kurumsal bir şirket içerisinde hayal ettiğimde, ortaya çıkabileceğini düşündüğüm ilk problem, Decider rolünün belirlenmesi.
Bu problemi tüm ürün ekiplerine yakıştırmak tabii ki doğru olmaz. Ama yönetici, müdür ve C seviyesindeki kişilerin bolluğundan ortaya çıkma ihtimali de artıyor. Bu olası probleme çözüm bulmanın 2 tane şekli var.
Çözümler:
A- Sprint’te 2 tane Decider olabilir.
Bu durumun bir problem olacağını düşünüyorsanız, eşit oy ve söz hakkına sahip 2 tane Decider seçebilirsiniz. Tabii ki bu tercih kendi içinde bazı problemleri de beraberinde getiriyor. Diyelim ki Decider rolündeki kişiler farklı çözümler üzerine gitmeye karar verdiler. Bu karar, ekibin 5 gün içerisinde 2 tane tasarım, 2 tane prototip geliştirmesi ve test etmesi anlamına geliyor.
Bu durumda da size baya bir kahve ve Redbull gerekiyor. Benim tavsiyem kahveleri sütsüz içmeniz. ☕️
B- Sprint ‘’O’’ kişiden gizli yapılabilir.
Bu sene içerisinde okuduğum ‘’Google Nasıl Yönetiliyor?’’ kitabında Google’ın HİPPO adını verdiği bir kavramı öğrendim.
HİPPO Google dünyasında, “highest paid person’s opinion” ya da “highest paid person in the office.” demek oluyor.
Diyelim ki ekibinizde, Decider olmak isteyen ama ekibin geri kalanının kendisiyle fikir ayrılığı içerisinde olduğu bir HİPPO var.
En güzel yolu, kendisine hiç ses etmeden Sprint’i gerçekleştirmek ve test bulgularıyla karşısına çıkıp, gerçekleştireceğiniz çözümlerle alakalı kendisine bir sunum yapmak.
Size şimdiden bol şans, o toplantının gergin geçeceğine hiç şüphem yok.
Problem 2
Sprint’e Katılanların ‘’Çok Yoğun’’ Olma İhtimali
Kurumsal şirketlerle alakalı başka bir problem de çok yoğun oldukları gerçekliği ya da yanısılması. Genelde işlerinin çok çabuk halledilmesini isteyen kurumsal şirketler, hep çok yoğundurlar.
Diyelim ki tasarım ofisi olarak kurumsal şirkete Desing Sprint gerçekleştirmesinde yardım ediyorsunuz. İşte bu ekibin bitmeyen ‘’Çok yoğunuz.’’ şikayetleri işleri 5 gün içerisinde bitirmeniz önünde kocaman bir engel. Bu durumda sizin x günlük planınızı ve öbür haftanızı, hatta öbür haftanızı da patlatabilme ihtimaline sahipler.
Çözümler:
A-Sprint ekibini sınırlayın
Kitapta da bulabileceğiniz gibi yazarların önerdiği kişi sayısı 7. Bu sayıya da 100'ün üzerinde Sprint koştuktan sonra karar vermişler. Bu kuralı tabii ki hiç değiştirilemez olarak adlandırmıyorlar ama neden bu kuralı aldıklarını anlamanızı istiyorlar.
Çünkü sayı arttıkça, ekibi yönetebilmek ve Sprint’i idare edebilmek zorlaşıyor. Siz de ekibi, gerçekten belirlediğiniz gün süresince katılabilecekler ile belirli sayıda tutmaya özen gösterin.
B- Sprint’i ne olursa olsun devam ettirin
Diğer bir seçenek de, Sprint’i her tür şart ve koşulda devam ettirmektir. Yani 6 kişi başladığınız Sprint’in 2. gününde 4 kişi kaldıysanız, çalışmaya devam edin. Eğer gelemeyenler arasında Decider’da varsa, ya bir kişiyi elçisi olarak atamasını isteyin ya da karar aldığınız önemli anlarda o kişiyi davet etmeye çalışın.
Problem 3
Ekipte Daha Önce Tasarım Ya Da Prototip Yapmış Birinin Olmaması
Desing Sprint kitabı çoğu yerinde benim bu varsayımımı yalanlıyor. Gerçekten verdikleri örnekler uzman olmasanız bile bu tekniği kullanabilmenizi kolaylaştırıyor. Ama bu tamamen ekipteki kişilerin motivasyonlarına ve yeni şeyler öğrenme isteklerine bağlı.
En başta da dediğim gibi Design Sprint bir takım işi. Tasarımları birlikte oluşturuyorsunuz, birlikte prototipe hazırlayıp test ediyorsunuz. Ekipte bir tane ‘’Ben skeç yapmakla uğraşmam kardeşim 😒’’ kafasında birinin olması durumunda sizin Sprint patlıyor.
Yeri gelmişken kendisinin bir şey yapmaması yetmiyormuş gibi, söylenerek başkalarını da etkileyen bu kişilerle uğraşan tüm arkadaşlara selamlar!
İşte bu yüzden de ekipte bu uzmanlıklarda birilerinin olmaması ya da isteksiz kişilerin varlığı, Sprint’te bir problem olabilir. Bu durum için 2 tane önerim var.
Çözümler:
A- Tasarım ofisi ya da Freelancer desteği alın.
Benim tavsiyem iş alanınıza ve çözüm bulmaya çalıştığınız platforma hakim bir etkileşim tasarımcısı ve testleri gerçekleştirebilecek bir kullanılabilirlik testi uzmanı bulmanız.
İster bir tasarım ofisine gidin, ister freelancer ile anlaşın. Sizinle birlikte skeç yapıp tasarımları hazırlayacak, üstüne storyboard çalışıp prototipi oluşturup bir de test senaryoları yazıp, test yapacak bir Unicorn bulursanız ne ala.
Hatta o kişiyi bulursanız, bence iş teklif edin. Çünkü süper birine benziyor 👌
B- Ücretsiz kaynakların nimetlerinden faydalanın
Diyelim ki ekipte Invision ya da Marvel gibi sayfa temelli prototip araçlarını kullanabilen biri var. Ya da öğrenmek isteyen birileri var ki, bu araçlar öğrenme eşikleri de düşük araçlardır.
Yani bir Origami ya da Framer değillerdir.
Skeçleri yaptığınız ve üzerine çalışacağınız çözümü netleştirdiğiniz noktada internetteki milyonlarca ücretsiz kaynaktan faydalanabilirsiniz. Tasarımlarınızı bu ücretsiz paylaşımlarla özelleştirdikten sonra da prototip çalışmasını tamamlarsınız.
Problem 4
Yeterince ‘’Bossy’’ Olamayan Faciliator
Diyelim ki tasarım ofisi olarak kurumsal şirketlere ya da start-up’lara Design Sprint hizmeti veriyorsunuz. Dolayısıyla o sprint’in faciliator rolündeki kişisi sizden biri olacak, Decider ise hizmet verdiğiniz şirketten.
Daha önce büyük şirketlerle toplantıya girenler tecrübe etmiştir, toplantılara C seviyesindeki kişiler de katılabilir. Diyelim ki sizin de Sprint’inize Yemeksepeti’nden Nevzat Aydın Decider olarak misafir oldu.
Şimdiden avuçlarınız terledi mi? Sesinizde bir incelme de olmuş olabilir. Çünkü olur da Nevzat Aydın telefonuna bakarsa, ‘’Nevzat Bey bildiğiniz gibi sprint süresince elektronik cihaz kullanımı yasak. Telefonunuzu sessize almanızı rica edebilir miyim?’’ diyebilecek misiniz?
Diyebilirseniz helal olsun 👏
Çözümler:
A- Doğru kişiyi seçin
Problemi tanımladıktan sonra, çözümü tahmin etmekte zorlanacağınızı düşünmüyorum. Faciliator rolündeki kişinin daha önce geniş katılımlı çalışmaları yönetmiş biri olması çok büyük avantaj sağlayabilir. Sprint’e katılan kişilerle doğru iletişimi sağlayabilecek, gerektiği zaman araya girebilen ve olaya müdahele edebilen biri olması gerekiyor.
Ayrıca herhangi bir atölye çalışmasını yönetmiş ya da eğitim vermiş kişiler bilirler ki, çalışmanın akışını yönetip takip ederken bir yandan bir sürü ‘’Neden?’’ sorusuyla muhatap olursunuz.
Eğer bu sorulara cevap veremeyecek biri Faciliator olursa, karşıdaki ekibin güvenini kaybedersiniz ve Sprint patlar.
B- Sprint’te 2 tane Faciliator kullanın
Bu tavsiye kitapta hiç yer almayan bir konu. Yazarlara göre Faciliator’dan iki tane olması gibi bir durum yok ancak işe yeni başlamış bir Faciliator zaman takvimine uymayı ve yapılacak işler gibi yönlendirmeleri yapabilir. Tecrübeli diğer kişi de az önce değindiğim ‘’Neden?’’ sorularına cevap vermekle ve katılımcılara yardım etmekle meşgul olur.
Benim kitabı okuduktan sonra, ‘’Nasıl kullanılabilir?’’ diye düşünüp, aklıma gelen problemler ve çözüm önerilerim böyleydi.
Kitabı okumuş ya da bu tekniği deneyimlemiş olanların da yaşadığı problemleri ve önerilerini merak ediyorum açıkçası.
Kitap hakkında soru sormak, fikir ve görüş paylaşabilmek için bana moguzarikan@gmail.com adresinden ulaşabilirsiniz.
Kendinize iyi bakın 🤓
Benim vaktim var , biraz daha okumak istiyorum derseniz Hürriyet Ürün Ekibi’nin Apple ve Google Play Store tasarım sürecini ya da yenilenen mobil web site sürecinde neler yaptığımızı okuyabilirsiniz 👇
