เมื่อเดือนที่แล้วเราได้มีโอกาสทำหนึ่งใน bucket list ของงาน software development คือการออกแบบ survey และ interview จากคนใช้งานจริง เลยขอเขียนไว้หน่อยว่า ณ ตอนนั้นคิดอะไรอยู่

Motivation

แรงจูงใจที่ตัดสินใจลงมือทำคือเราค้นพบตัวเองว่าเราเป็นคน value งานด้าน impact คือเราจะภูมิใจถ้าเรารู้ว่างานของเรามันมีผลกระทบกับคนอื่นด้าน business และหรือด้าน engineering ในทางที่ดีขึ้น มาจากงาน social impact ต่าง ๆ ที่เคยทำ รวมไปถึงการให้ความสำคัญกับการเก็บ feedback และ moment ต่าง ๆ จากเพื่อนร่วมงานในตลอดอาชีพการทำงานที่ผ่านมา ดังนั้นการได้ทำ survey และ interview มันก็มาตอบโจทย์ทางใจของเราส่วนตัวตรงด้าน impact นั่นเอง แต่เราทำงานกันเป็นทีมมันก็จะเอาแต่ตัวเราอย่างเดียวไม่ได้ ต้องมองถึงผลประโยชน์ด้านอื่นด้วย เช่น

Validating platform objectives

ในทางอุดมคติแล้ว platform team มักจะเกิดขึ้นมาจากจุดประสงค์อะไรบางอย่างที่คนในองค์กรคาดหวังไว้ เช่น ปรับปรุง developer productivity หรือลด lead time ให้สั้นลง หรือถ้าอยู่ในรูปแบบแย่ที่สุดคือเกิดจากการหากลุ่มคนที่ให้ทีมพัฒนาอื่น ๆ โยนงานที่ตัวเองไม่อยากทำมาให้ แต่ใด ๆ ก็ตามการเกิดขึ้นมาของทีมมันจะต้องมีค่าใช้จ่ายและการลงทุนจากองค์กร ดังนั้นการตอบคำถามกับองค์กร ว่าเรารู้ได้ยังไงว่า platform มันตอบจุดประสงค์เหล่านั้นได้เป็นสิ่งสำคัญที่จะยังคงให้องค์กร invest กับ platform ต่อไป

คุณอาจจะบอกว่า Four key metrics ที่เป็น leading indicator ของ speed และ quality ของการส่งมอบก็ตอบคำถามได้ ก็ไม่เถียงครับ แต่มันไม่ได้บอกว่าสาเหตุที่เกิดขึ้นมันคืออะไรบ้าง ดังนั้นการกำหนด lagging indicator ผ่านคำถามอย่างเช่น developer รู้สึกติดขัดตรงไหน documentation ใช้งานง่ายไหม หรือ platform ใช้งานแล้วช่วยประหยัดเวลาจริงหรือเปล่า มันเป็นอีกมุมหนึ่งที่ช่วย check ว่า platform ที่สร้างและลงทุนไว้กำลังเดินมาถูกทางหรือเปล่า

Data-driven prioritisation

เมื่อ platform กำลังจะ scale หลาย ๆ ทีมจะต้องคำนึงถึง feature ที่ platform กำลังจะเพิ่มเข้าไปอย่างเดียวไม่ได้ แต่ยังรวมถึงการ maintain feature เดิมที่ developer เข้าใช้งานอยู่ทุก ๆ วันด้วย ทำให้หลาย ๆ ทีมจะต้องพิจารณาว่า feature ใหม่ ๆ อันไหนที่เหมาะที่จะลงทุนเพิ่มมากที่สุด ซึ่งปัจจัยในการพิจารณาก็มาจากหลายแหล่ง ไม่ว่าจะเป็นจาก business หรือจาก developer ที่เข้ามาใช้ feature การมีข้อมูลจาก survey และ interview ที่บอกว่า feature ไหนที่จะช่วยทำให้องค์กรส่งมอบ software ได้เร็วขึ้น หรือ feature ไหนที่ developer คาดหวังให้มีมากที่สุด จะช่วยให้การจัดลำดับงานที่จะต้องส่งมอบสอดคล้องกับ time-to-market มากขึ้น ซึ่งดีกว่าการมานั่งเดาว่า

“คิดว่า…น่าจะชอบ feature นี้ที่สุด งั้นเอาอันนี้แหล่ะ”

Make users happy

บางองค์กรมี platform ก็จริง แต่การใช้งาน feature แต่ละอย่างมันช่างติดขัดไปซะทุกอย่าง เช่น รอ approval จากคนบนฟ้าเมื่ออยากจะใช้ feature ใน platform หรือรอทีมนึงปรับแก้ตามที่ต้องการแทนที่ทีมตัวเองสามารถทำเองได้ กลายเป็นว่าองค์กรลงทุนกับ platform เพื่อให้องค์กรส่งมอบ software ได้เร็วขึ้น แต่ดันกลับทำให้ช้าลงซะงั้น แถมทำให้ developers หรือ users ไม่อยากใช้ platform เข้าไปอีก ผลที่เกิดขึ้นสามารถไปถึงในระดับองค์กรได้อย่าง lead time ที่สูงขึ้นจาก friction ที่ users ไปเจอ ไปจนถึงคนในองค์กรลาออก

เรื่องเหล่านี้จะไม่เกิดขึ้นหากมีการปรับปรุงและพัฒนา platform ตาม feedback ของ user บ้าง ซึ่งการทำ survey และ interview คือวิธีการนึงที่เสียงจาก user จะไปถึง platform team ได้

Thought process ที่ใช้ในการออกแบบ

เชื่อม platform feature เข้ากับ business/engineering outcome

คำถามที่เราจะไปถาม user ควรจะต้องตอบคำถามจากองค์กรให้ได้ว่า

Platform มันช่วยให้ business หรือคุณภาพชีวิต user ดีขึ้นได้อย่างไร

แต่ว่า user ไม่สามารถตอบคำถามนี้ได้โดยตรงเพราะเขาไม่ได้สัมผัส platform feature ตอนะรหว่างที่มันกำลังพัฒนา แต่เขาสัมผัสกับตอนที่มันออกมาให้เขาได้ใช้งานแล้ว คำถามจึงต้องเกี่ยวกับประสบการณ์ในการใช้งาน feature หรือผลประโยชน์ทาง technical หรือทางใจที่เขารู้สึกว่าเขาได้รับจาก feature เหล่านั้นแทน

นั่นหมายความว่าเราจะโยงว่า feature ที่ user ใช้นั้นมันมีผลทางบวกอย่างไรที่จะสามารถ influence ให้องค์กรตัดสินใจ invest กับ platform ต่อได้ หนึ่งในวิธีที่เราใช้คือการมองจากมุมที่ว่าองค์กรต้องการอะไรจากการลงทุนใน platform ผ่านเครื่องมือ Lean Value Tree

Lean Value Tree

Lean value tree

https://www.thoughtworks.com/en-au/insights/articles/bootstrapping-innovation-in-financial-service-firms

Lean Value Tree เป็นเครื่องสำหรับแปลง vision ขององค์กร ให้แตกออกมาเป็นงานที่ทีมสามารถลงมือทำได้จริง พร้อมทั้งทำให้ทุกคนเห็นว่าตัวเองกำลังสร้างคุณค่าอะไรให้องค์กรผ่านโครงสร้างของ Lean Value Tree มีทั้งหมด 4 ชั้น

  1. Vision – ภาพใหญ่ที่สุดขององค์กรเป็นทิศทางที่องค์กรลงทุนทั้งหมด ซึ่ง platform team เป็นส่วนหนึ่งที่ช่วยให้ vision นี้เกิดขึ้นจริง
  2. Goals – เป้าหมายที่สนับสนุน Vision ต้องผูกกับ Outcome ไม่ใช่ Solution หรือ technology ที่จะใช้สร้าง
  3. Bets – สมมติฐานว่าอะไรน่าจะทำให้ Goal นั้น ๆ สำเร็จ โดยที่ทีมจะทำการพิสูจน์ทีหลังว่าแบบไหนให้ผลดีที่สุด
  4. Initiatives – สิ่งที่ทีมจะลงมือทำจริง

เพื่อความเข้าใจแบบสั้น ๆ ขอยกตัวอย่าง Tree สายนึงจากบนลงล่าง

Vision – Ship software faster with higher quality Goals – Reduce deployment lead time Bets – Standardise CI/CD Pipeline Initiatives – Build reusable deployment pipeline

เมื่อทุก Initiative เชื่อมกลับไปยัง Goal และ Vision เดียวกัน การตัดสินใจว่าอะไรควรทำก่อนหรือหลังจะอิงกับผลลัพธ์ที่คาดหวัง มากกว่าความรู้สึกหรือเดาเอาว่า “ถ้าลงทุนกับ X แล้วหวังว่าจะดี”

หา friction ที่ user กำลังเจอ

การที่ user ใช้งาน platform นอกจาก productivity ของ user จะเพิ่มขึ้นแบบอ้อม ๆ แล้ว มันยังช่วยลดสิ่งที่ทำให้ productivity ลดลงอีกด้วย ซึ่งการถามคำถามที่เน้นถึงจุดนี้ก็ทำให้ value ของ platform มันถูกขับเน้นออกมามากขึ้น โดยคำถามของคำถามทั้งหมดที่เราจะไปถาม user คือ

สิ่งใดที่ขวางทีมพัฒนาให้ส่งมอบงานไปไม่ได้เร็วไปกว่านี้หรือคุณภาพสูงขึ้นไปไม่ได้มากกว่านี้บ้าง

แนวคิดหลักที่เราจะใช้จับ “สิ่งใด” เหล่านั้นคือ Lean Manufacturing

Lean Manufacturing

Lean Manufacturing กำเนิดมาจาก Toyota Production System ที่บริษัท Toyota ใช้ในการ optimise ค่าใช้จ่ายด้านเงินแรงและเวลาในสายงานระบบของการผลิตรถ โดยเน้นไปที่การลดสิ่งที่ไม่สร้างคุณค่าออกไป 3 อย่าง

  1. Muri – งานหนักเกินกำลังคนงานที่จะรับไหว
  2. Mura – ความไม่สม่ำเสมอของงานที่เข้ามา
  3. Muda – ความสิ้นเปลือง (waste) ที่เกิดขึ้นในสายงานระบบ

ในส่วนของ survey และ interview นี้เราจะเน้นไปที่ Muda เพื่อค้นหา waste ที่เกิดขึ้น โดยมีทั้งหมด 7+1 อัน ต่อมาคือตั้งสมมติฐานเพื่อโยง waste เหล่านั้นไปหา business/engineering outcomes ว่า waste เหล่านั้นส่งผลลบอย่างไรต่อองค์กร

แนวคิดนี้สอดคล้องกับงานวิจัยของ DX ซึ่งเป็นองค์กรที่ทำ research เกี่ยวกับเรื่องนี้โดยเฉพาะ เก็บข้อมูลจาก Developer กว่า 40000 คนในกว่า 800 องค์กรทั่วโลก โดยข้อสรุปหลัก ๆ ของงานวิจัยคือ

“ถ้า friction ที่ทีมต้องเจอน้อยลง จะทำให้องค์กรส่งมอบงานชิ้นเล็ก ๆ ได้เร็วขึ้น ทำให้ความเสี่ยงหรือการเกิดข้อผิดพลาด(จากการส่งมอบงานชิ้นใหญ่ ๆ ที่เดียว)น้อยลง”

ในส่วนของข้อมูลจากงานวิจัยยังพบว่า Developer Experience มีความสัมพันธ์กับทั้งความเร็วและคุณภาพของงาน software ที่ส่งมอบ ไปจนถึง financial revenue ขององค์กรด้วย โดยมีปัจจัยมาจากเรื่องต่าง ๆ อาทิเช่น documentation, change confidence, ease of release, clear direction, local development speed, production incident & debugging เป็นต้น

Developer Experience Index https://getdx.com/blog/guide-to-developer-experience-index/

เมื่อกลับมาที่การออกแบบ การพิสูจน์สมมติฐานที่เราตั้ง(ว่า waste อันไหนส่งผลลบอย่างไรต่อองค์กร)นั้นมันต้องใช้แรงและข้อมูลจากระยะเวลาที่ยาวประมาณนึง ส่วนตัวจึงมองว่าถ้าคุณเพิ่งเริ่มต้นกับ survey และ interview แทนที่จะ focus กับการตั้งสมมติฐาน ให้ไป focus กับการตั้งคำถามที่สะท้อนให้เห็นถึง waste ที่เกิดขึ้นจากปัจจัยต่าง ๆ ที่มีใน DX เพราะเขาพิสูจน์มาในระดับนึงแล้วว่า somehow waste เหล่านั้นส่งผลลบต่อองค์กร เช่น แทนที่จะถามแค่ว่า “ใช้ platform แล้วชอบไหม เป็นยังไง” ให้ถามว่า “อะไรทำให้เสียเวลาที่สุด(ในการส่งมอบ software)” “ขั้นตอนไหน(ในการส่งมอบ software)น่าหงุดหงิดที่สุด” เพราะคำตอบก็คือ waste ที่ platform ที่ดีควรเอาออกนั่นเอง

สิ่งที่ได้เรียนรู้จากการลงมือทำ

หลังจากที่ออกแบบแล้วก็ได้ส่ง survey + interview developers และ QA ของหลาย ๆ ทีมในหลาย ๆ domain ไป step ต่อมาที่สำคัญคือการวิเคราะห์ข้อมูลโดยจะเน้นไปที่การทำ data cleansing เช่น ตัด outliers ตัด weekend/holiday ออก (ถ้าข้อมูลดิบเกี่ยวข้องกับเวลาที่ใช้ไปกับเรื่องใด ๆ) ไม่อย่างนั้นสรุปผลอาจผิดไปเยอะ ลดโอกาสการแก้ปัญหาไม่ตรงจุด

อีกเรื่องที่สำคัญคือ เราจะต้องให้ psychological safety กับคนตอบก่อน เพราะถ้าคนตอบกลัวว่าจะถูกตามตัวได้เขาจะไม่ตอบความจริง เกิดจากความรู้สึกกลัวว่าคำตอบอาจจะไปกระทบจิตใจใคร ๆ ที่มีผลต่อหน้าที่การงานได้ เพราะฉะนั้นก่อนที่เราจะเริ่มถามหรือก่อนที่จะกรอก survey ให้เน้นย้ำในจุดนี้ และตอนที่ share ผล ให้ทำแบบ anonymous ด้วย

ในระหว่าง interview ให้เน้นเหมือนกันการพูดคุยกับเพื่อนร่วมงานหรือไป date พวก script ที่เตรียมไว้ก็ดูเป็นแค่ checklist หรือ guideline ก็พอ เน้นไปที่ flow คำถามแบบปลายเปิดและชวนให้เขาเล่าเพิ่มถ้ายังไม่ clear เช่น “เล่าเพิ่มได้ไหม” หรือ “ทำไมถึงรู้สึกแบบนั้น” เราพบว่าหลาย ๆ ครั้ง insights ที่ดีที่สุดมันมาจากการถามต่อ บางคำถามอาจไม่เกี่ยวกับบริบทของเขา ก็ไม่จำเป็นต้องฝืนถามให้ครบทุกข้อ

ในด้านของจิตใจเป็นสิ่งสำคัญมากที่สุดเพราะใด ๆ คือเราก็เป็นมนุษย์ที่มีความรู้สึก เวลาเรารับและอ่าน feedback ที่เน้นไปทางติ (จะเพื่อก่อหรือเพื่อด่าก็แล้วแต่จะตีความ) ขอบอกเลยว่าเป็นปกติที่จะรู้สึกเสียใจเหมือนมาด่าที่เราแม้ว่าจริง ๆ แล้วเขาอาจจะติที่ platform ก็ได้ และจะรู้สึกแย่ไปกว่านั้นถ้ามันเกี่ยวข้องกับสิ่งที่เราทำหรืออีกด้านคือเกินสิ่งที่เรานั้นควบคุมได้ แน่นอนว่าเป็นไปไม่ได้ที่ทุกคนจะให้ feedback ที่ถูกจริตเราทุกตรง แต่เราสามารถควบคุม reaction ที่สะท้อนจากการรับ feedback เหล่านั้นได้ reaction ที่ไม่ควรเกิดขึ้นมีได้ 2 ด้านอย่างสุดขั้วคือ

  1. ปล่อยผ่านไม่สนใจ feedback ทั้งหมด หรือหลอกตัวเองว่าเราฉลาดกว่า user โง่ ๆ ที่ดันใช้ platform ไม่เป็นเอง
  2. เอาใจเขามาใส่ใจเรามากเกินไป และเริ่มตื้อคนในทีมหรือ leadership ให้ prioritise หรือทำในสิ่งที่ user ต้องการ แม้ว่ามันจะยังเป็นไปไม่ได้ทั้งในด้าน technical หรือ politics ก็ตาม

การ react แบบทั้ง 2 ขั้วนี้ล้วนไม่ work เสมอ สิ่งสำคัญคือการรับ feedback แล้ววิเคราะห์ว่าแนวทางการปรับปรุงแก้ไขนั้นมันมีอะไรบ้าง จากนั้น balance ว่า วิธีแก้เหล่านั้นมันเป็นไปได้จริงไหม มันสิ่งที่องค์กรต้องการจาก platform ไหม และมันเป็นสิ่งที่ user ต้องการจริง ๆ หรือเปล่า เราแนะนำให้สนใจ feedback ที่วิธีแก้ balance ที่สุดก่อนเสมอ