Before User Story-ภาค 5: สร้าง User Workflow, Happy Path และ Sad Path

จาก Story Map มาถึงขั้นตอนที่คุ้นเคย … การสร้าง Product Backlog … มันอาจจะมีเทคนิคหลากหลายแต่ที่ผมชอบคือการสร้าง Product Backlog โดยยึดกระบวนการทำงานของผู้ใช้เป็นหลัก เริ่มต้นที่เส้นทางแห่งความสุข ปิดท้ายด้วยเส้นทางแห่งความทุกข์แสนสาหัส

End-to-End User Workflow

สิ่งแรกที่ผมทำก่อนจะเริ่มเขียน User Story (พูดถึง Product Backlog ทุกคนมักจะคิดถึง User Story) คือผมจะจินตนาการก่อนว่า End-to-End User Workflow มีหน้าตาเป็นยังไง … ทำไมมันถึงสำคัญ?

End-to-End User Workflow

เพราะมันเป็นแผนภาพที่ช่วยให้เราเห็นระบบของเราจากมุมสูง (เปรียบเหมือน Bird’s Eye View) ช่วยให้เราเห็นโครงข่ายและขอบเขตของกระบวนการของผู้ใช้และงานที่เราต้องทำได้ชัดเจนเป็นภาษาคนมากกว่ารูปภาพใน Story Map

รูปด้านบนนอกจากจะช่วยให้เรามองหาเส้นทางแห่งความสุขและความทุกข์ได้ง่ายแล้ว มันยังใช้เป็นแผนภาพอ้างอิงในการวางแผนโปรดักส์ในระยะสั้น กลาง และยาวได้ด้วย (ไว้อธิบายในตอนต่อๆไป)

Primary Happy Path

เมื่อกำหนด End-to-End User Workflow ได้แล้วสิ่งที่ผมทำเป็นลำดับถัดมาคือมองหา Primary Happy Path ที่สั้นที่สุดของระบบที่เรากำลังจะพัฒนาขึ้นมา อะไรคือ Primary Happy Path? — ง่ายๆครับ

อะไรคือเป้าหมายสูงสุดที่ผู้ใช้ต้องการจากระบบของเรา? ตอบคำถามนี้ได้ เราจะมองเห็น Primary Happy Path ที่ชัดเจน

ที่ผมมองเห็นคือเส้นสีเขียว เส้นที่จะผู้ใช้จะเดินตามเพื่อ “Print Reports & Payment Sheet” ได้อย่างราบรื่น รวดเร็ว และถูกต้อง มันประกอบขึ้นจากอะไรบ้าง?

1. Login
2. Main Screen
3. Review Reports and Amounts
4. Print Preview
5. Review Detailed Reports
6. Print Reports and Payment Sheet

นี่คือขั้นตอนทั้งหมดที่เกี่ยวข้อง หลักการของผมคือเริ่มคิดถึง User Story สำหรับหกขั้นตอนนี้พอ ไม่ต้องฟุ้งไปไกล เอาแค่นี้ก่อน อีกเรื่องคือเราต้องหาเส้นทางที่สั้นที่สุดที่จะทำให้ขั้นตอนทั้งหกนี้เชื่อมต่อและทำงานได้ ทำไมถึงทำแบบนี้ล่ะ? — ง่ายๆครับ เพราะเรื่องอื่นๆมันไม่มีประโยชน์สำหรับผู้ใช้เลย … ในตอนนี้

ลองเอา Story Map มาเทียบดู เห็น User Story อะไรบ้างสำหรับ Login และ Main Screen?

Primary Happy Path

ถ้านั่งปล่อยใจคิดไปแบบไม่มีโฟกัส เราจะได้ User Story มามากมายมหาศาลเกินความจำเป็นครับ หนักแน่นในเป้าหมายนิดนึง ถามตัวเองหลายๆรอบว่า “ไอ้นี่มันจำเป็นต้องมีจริงๆหรอ? ถ้าคำตอบคือไม่ ตัดทิ้งทันที อย่าเก็บไว้ให้รกหูรกตา

Primary Sad Path

นอกจากความสุขที่ผู้ใช้จะได้รับแล้ว เราต้องทำให้พวกเค้ารับรู้ถึงรสชาติความเจ็บปวดด้วย ฮ่าๆๆ มันเป็นเรื่องจำเป็นอย่างมากครับที่เราต้องกำหนด Primary Sad Path ซึ่งเป็นเส้นทางที่จะทำให้ผู้ใช้เกิดความทุกข์ … ที่สุด ส่วนตัวผมมองว่า Primary Sad Path ของระบบหาไม่ยาก

อะไรคือความเจ็บปวด (Pain Point) สูงสุดที่ผู้ใช้กำลังเผชิญอยู่ และจุดไหนที่เราคิดว่ามีความเสี่ยงสูงที่สุด (ที่ผู้ใช้จะไม่ยอมรับ) … นั่นแหละ Primary Sad Path

ในกรณีของระบบนี้ ชัดเจนว่าความเจ็บปวดสูงสุดของผู้ใช้คือการปริ้นท์รายงานสองสามฉบับออกมานั่งตรวจดูตัวเลขยอดเงินด้วยตาและมือ เรากำลังจะแก้ปัญหานี้โดยให้ระบบเป็นตัวจัดการเรื่องนี้ให้แบบอัตโนมัติ … เราเอาแนวคิดไปเสนอและได้รับเสียงตอบรับที่ดีจากลูกค้าแล้วแต่หลายครั้งที่ผู้ใช้ (หรือแม้แต่ตัวเราเอง) ไม่รู้ว่าจริงๆแล้วต้องการอะไรจนได้เห็นของจริง … หน้าที่ของเราคือต้องให้พวกเค้าได้เห็นของจริงโดยเร็วที่สุดครับ ถ้าชอบก็มาถูกทาง ถ้าไม่ชอบก็ปรับเปลี่ยนซะตั้งแต่เนิ่นๆ

หลักการในการคิด User Story ของ Sad Path ก็ไม่ยาก ทำเหมือนเดิมนั่นแหละ อะไรที่ไม่จำเป็นก็ตัดทิ้งไปให้หมด อย่าเก็บไว้เป็นเรื่องหนักใจครับ

Lean Is To Eliminate Wastes

ที่ผมทำแบบที่เขียนมาข้างบนนั้นเป็นแนวคิดที่ได้มาจากการทำงานแบบ Lean (ลีน) ที่แปลแบบบ้านๆว่า ผอม ไม่มีไขมันส่วนเกิน … ถ้าเป้าหมายเราชัดเจน เราต้องมุ่งมั่นทำทุกอย่างให้ถึงเป้าหมายนั้นโดยเร็วที่สุดแบบเหนื่อยน้อยที่สุด เราจะไม่คิดทำอะไรเกินตัว ทำอะไรฟุ้งเฟ้อ และเสียเวลากับเรื่องไม่เป็นเรื่อง

การเขียน User Story ที่เกินความจำเป็นคือไขมันที่ต้องถูกกำจัด ทำไมเราถึงทำแค่ Login Success?

• ทำไมไม่ทำ Sign-Up Screen? — มันยังไม่จำเป็น
• ทำไมไม่ทำ Forget Password? — มันยังไม่จำเป็น
• ทำไมไม่คิดเรื่อง History ของ Reports? — มันยังไม่จำเป็น
• ทำไมไม่เตรียมฟอร์แมทของ Adjustment Sheet? — มันยังไม่จำเป็น
• อื่นๆอีกเป็นร้อยที่เราจะตอบว่า — มันยังไม่จำเป็น

เราจะตอบว่า “ไม่” กับทุกคนได้ง่ายขึ้นเพราะเป้าหมายเราชัดเจน

1. ทำให้ผู้ใช้เห็นว่าขั้นตอนจากต้นจนจบแบบมีความสุขนั้นหน้าตาเป็นอย่างไร
2. ทำให้ผู้ใช้เห็นว่าความทุกข์ของพวกเค้าจะถูกจัดการอย่างไร พวกเค้าจะแฮปปี้ขึ้นมั้ยถ้าต่อไปนี้ … มันจะเป็นแบบนี้แล้ว

ถ้าสิ่งที่คนอื่นหรือแม้แต่ตัวเราเองต้องการไม่ได้เป็นไปเพื่อสองเป้าหมายนี้ … ราตรีสวัสดิ์

ป.ล. ผมไม่เล่าถึงรายละเอียดและเทคนิคที่ใช้ในการแบ่ง User Story เพราะเข้าใจว่าเพื่อนๆส่วนใหญ่เก่งเรื่องนี้กันอยู่แล้ว … สำหรับใครที่อยากทบทวน ลองอ่านหนังสือสองเล่มนี้ดูครับ

1. User Story & ‘INVEST’ — การเขียน User Story ที่ดีด้วยหลัก INVEST … ดาวน์โหลดที่นี่
2. 9 Ways To Split User Stories — เก้าวิธีช่วยแบ่ง User Stories ให้เล็กลง … ดาวน์โหลดที่นี่

ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิต ซอฟท์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ