แก้ปัญหา Business Requirement ด้วย BiRD Canvas
BiRD ย่อมากจาก Business impact Requirement Description เป็น Frameworks ที่ทีม ODDS พัฒนาต่อยอดมากจากหลายๆ แนวคิด เพื่อนำมาแก้ปัญหา Requirement ไม่ชัดเจน (เอกสารความต้องการจากผู้ใช้งานที่จะส่งไปให้นักพัฒนาไม่ชัดเจน) เป็นต้นเหตุให้งานล่าช้า หรือหลายครั้งงานที่ได้ออกมาไม่สามารถนำไปแก้ปัญหาได้จริง แม้จะทำตามเอกสารทุกอย่างแล้วก็ตาม
ปัญหาอยู่ตรงไหน (Why)
ถ้าย้อนไปดูต้นเหตุของปัญหา Requirment ไม่ชัด มันเกิดจากเชื่อที่ว่า “เราสามารถระบุได้ว่าโปรแกรมควรเป็นอย่างไร ก่อนที่จะเริ่มพัฒนา” แต่ในความเป็นจริงที่เกิดขึ้นคือ “เราไม่สามารถคาดการปลายทางล่วงหน้าได้เลย” เพราะโปรแกรมที่เรากำลังจะทำนั้นมักไม่เคยถูกพัฒนาขึ้นมาก่อน ในโลกที่เปลี่ยนแปลงเร็วขนาดนี้ เรามักจะใช้เทคนิคใหม่ๆ ในการพัฒนาอยู่เสมอ และความต้องการของลูกค้าก็มักเป็นของใหม่อยู่ตลอด
ถ้ามองย้อนกลับไปที่ผู้เกี่ยวข้องหลัก 3 ฝ่าย
1. เริ่มจากผู้ใช้: ผู้ใช้มักไม่รู้ว่าตัวเองต้องการอะไร หรือบางครั้งไม่รู้ด้วยซ้ำว่าปัญหาที่ตัวเองเจออยู่คืออะไร ลองนึกดูว่า “ถ้าไม่ได้ใช้ iPhone เราก็คงคิดว่าการมี Keyboard อยู่บนเครื่องก็คงไม่ใช่ปัญหา” คนที่มองปัญหาได้จะเป็นทีมที่พยายามเข้าใจความต้องการจริงๆ ของผู้ใช้ และทำงานร่วมกับนักพัฒนาเพื่อหาทางแก้ปัญหาที่ดีกว่าเดิม
ดังนั้นการให้ผู้ใช้คิด Requirement มาให้ จึงมีความเสี่ยงสูง และหลายครั้งแม้จะได้ของที่ทำตามสิ่งที่ผู้ใช้ขอ ถ้าสุดท้ายมันไม่ได้แก้ปัญหาได้ดีอย่างที่คิด ผู้ใช้ก็จะไม่ใช่มัน
2. ทีมธุรกิจ: เป็นผู้สนับสนุนหลักในการพัฒนา ทีมนี้จะชัดเจนอยู่แล้วว่าต้องการโปรแกรมนี้ไปเพื่ออะไร มีต้นทุนในใจ และผลตอบแทนที่คาดว่าจะได้รับอย่างชัดเจน ดังนั้นทีมนี้จึงมีโอกาสสูงมากที่จะเขียนความต้องการออกมาได้ตรงกับที่ตนเองอยากได้
ความชัดเจนนี่เองที่สร้างปัญหา เพราะการพัฒนาโปรแกรมมันไม่ชัดเจน โอกาสที่เราคิดว่าเห็นชัดจะเริ่มไม่ชัดทันทีที่เราเห็นโปรแกรมออกมาส่วนหนึ่ง เราจะมองเห็นโอกาสใหม่ๆ ซึ่งทำให้ความต้องการเปลี่ยนไป ดังนั้นถ้าความต้องการระบุแค่ลักษณะของโปรแกรม การปรับเปลี่ยนก็จะเป็นเรื่องยากเพราะเราไม่แน่ใจว่าเปลี่ยนไปแล้วมันจะยังคงเป้าหมายเดิมอยู่หรือเปล่า
ดังนั้นการกำหนดเป้าหมายระยะสั้น และระยะยาว รวมถึงวิธีการวัดผลสำเร็จ จะต้องใส่เข้ามาใน Requirement ด้วย
3. ทีมพัฒนา: เป็นทีมที่รวม BA (Business Analysis), SA (System Architecture), UX (User Experience), UI (User Interface), SE (Software Engineer), QA (Quality Assurance), DevOps (Development Operations) รวมถึงทุกคนที่เป็นผู้ร่วมพัฒนาโปรแกรม
ทีมนี้ดูเป็นอีกความหวังเนื่องจากเค้าอยู่ใกล้กับตัวโปรแกรมมากที่สุด แถมทีมนี้ยังสามารถสร้างสรรค์แนวทางการแก้ปัญหาที่สองทีมแรกคิดไม่ถึงได้ด้วย เพราะเป็นทีมที่สร้างของชิ้นนี้ขึ้นมาเอง แต่สิ่งที่เกิดขึ้นคือทีมนี้มักถูกว่างให้อยู่ไกลจากปัญหามากที่สุด เรามักจะให้ทีมนี้คอยรับ Requirement จากผู้ใช้และจากทีมธุรกิจ ทำให้การหาท่าใหม่ๆ ในการแก้ปัญหาทำได้ยาก
แม้เราจะให้โอกาสทีมพัฒนาในการเสนอแนวทางแก้ปัญหา แต่เนื่องจากทีมขาดความเข้าใจปัญหาอย่างลึกซึ้งจึงไม่สามารถพลิกแพลงวิธีการได้เต็มที่ ทำให้ข้อเสนอต่างๆ จากทีมพัฒนาดูเป็นข้ออ้างให้ตัวเองไม่เหนื่อย (แม้ว่าทีมพัฒนาจะไม่ได้คิดแบบนั้นเลย)
ถ้าเราสามารถทำให้ทีมพัฒนามีส่วนร่วมในการการกำหนด Requirement เพื่อร่วมกันกำหนดเป้าหมายให้ชัดเจน มากพอที่จะสามารถปรับเปลี่ยนมันได้ตามหน้างาน โดยยังคงตอบโจทย์ของธุรกิจได้แถมแก้ปัญหาให้ผู้ใช้ได้ด้วย มันจะเป็น Requirement ในฝันที่ทุกคนเข้าใจและถือปัญหาไปด้วยกัน การแก้ภายหลังก็จะไม่ดูเป็นข้ออ้างของอีกฝ่ายอีกต่อไป
ถึงตอนนี้เราคงเริ่มเห็นลางๆ แล้วว่า ในตัว Requirement ควรประกอบด้วยอะไรบ้าง เพื่อดึงทุกคนเข้ามามีส่วนร่วม และทำให้เราสามารถปรับมันได้ตามหน้างาน ทีมของ ODDS ก็เห็นจุดนี้เหมือนกัน เราจึงพัฒนา BiRD ขึ้นมา
ภาพรวมของ BiRD Canvas (What)
ถ้าต้นทุนในการพัฒนาน้อยก็ไม่จำเป็นต้องคิดเยอะ ทำไปก่อนแล้วค่อยวัดก็เร็วดี แต่เมื่อไหรก็ตามที่เราคิดว่าต้นทุนเริ่มเยอะ ประมาณว่า “มากกว่าที่นักพัฒนา 1 คนจะทำเสร็จได้ใน 1 อาทิตย์” ผมคิดว่าเราควรจะย้อนกลับมาคิดให้ดีว่าสิ่งที่จะทำนั้นคุ้มค่าหรือไม่ พวกเราได้ลองผิดลองถูกกันมาพักใหญ่ ก็ลงตัวที่เจ้า BiRD Canvas นี่ล่ะ
BiRD Canvas แบ่งได้ 3 ส่วน
1. Objective & Measurement
การเริ่มเขียนเป้าหมายจะช่วยดึงให้ผู้เขียนออกห่างจากสิ่งที่ต้องการจะทำ แล้วเน้นไปที่ปัญหาหรือสิ่งที่ต้องการพัฒนาให้ดีขึ้นแทน ในส่วนของการวัดผลจะมาทำให้เป้าหมายไม่ฟุ้งมากเกินไป นอกจากนี้ยังช่วยให้ทีมพัฒนาเข้าใจที่มาที่ไปรวมไปถึงภาพความสำเร็จของงานชัดขึ้น ทำให้การแก้ปัญหาหน้างานทำได้เร็วโดยไม่เสียเป้าหมายที่ตั้งไว้
2. Solution & Alternative
การที่ให้เขียนทั้งวิธีแก้ปัญหาที่เลือก และวิธีแก้ปัญหาอื่นๆ ก็เพื่อให้ผู้เขียนแน่ใจว่า วิธีที่เลือกนั้นเป็นวิธีที่เหมาะสมที่สุดแล้ว รวมถึงทำให้คนที่อ่านได้รู้ด้วยว่าผู้เขียนได้คำนึงถึงความเป็นไปได้อะไรบ้างก่อนที่จะเสนอแนวทางนี้มา สิ่งนี้จะช่วยให้ทีมพัฒนาเข้าใจมุมมองของผู้เขียนต่อแนวทางต่างๆ ซึ่งช่วยให้การเสนอวิธีแก้ปัญหาที่ต่างออกไปในอนาคตทำได้ชัดเจนขึ้น
3. Press release & Dependency
ส่วนสุดท้ายเป็นการขมวดให้เห็นภาพรวมมากที่สุด ผู้เขียนจะคิดว่าตอนที่ทุกอย่างเสร็จแล้วจะประกาศบอกผู้ใช้ว่าอย่างไร สิ่งนี้จะแก้ปัญหาอะไรด้วยวิธีการไหน ช่วยให้ผู้อ่านเข้าใจผลกระทบของงานนี้อย่างชัดเจน รวมทั้งการเขียนความเกี่ยวข้องกับส่วนอื่นๆ ไม่ว่าจะเป็นโครงการที่ต้องเสร็จก่อนจึงจะแก้ปัญหานี้ได้ หรือสิ่งที่ต้องทำหลังจากที่ปัญหานี้เสร็จแล้ว
การทำ BiRD Canvas จะทำให้เห็นภาพรวมทั้งต้นทุนในการพัฒนา และประโยชน์ที่ได้จากตัวโครงการ ทำให้การลำดับความสำคัญของโครงการต่างๆ ทำได้ง่ายขึ้นมาก และที่สำคัญที่สุดคือ Canvas นี้จะพาให้คนที่เขียนโครงการสามารถค่อยๆ มองความต้องการของตนเองไปทีละขั้น พร้อมกับชวนให้มองย้อนกลับไปบ่อยๆ เพื่อให้เรายังเห็นภาพรวมอยู่ตลอดเวลา
ทั้งหมดนี้คือภาพรวมของ BiRD Canvas ครับ ในแต่ละส่วนของมันยังมีเทคนิคในการคิดและเทคนิคการเขียนที่ละเอียดลงไปอีก เพื่อเราจะได้สื่อสารไปถึงทีมได้จริง ไม่ใช่แค่ได้รู้ว่าเราอยากได้อะไร แต่ให้เข้าใจว่าเราทำกันไปทำไม (ไปต่อกันในส่วนที่สองครับ)
ถ้าสนใจเรื่อง ความสุขในการพัฒนา Software ผมอยากแนะนำให้อ่าน Blog ของ ODDS ครับ เพราะคนเขียนในนั้นคือคนที่เชื่อว่า “การทำ Software ต้องสนุก”
ส่วนใครสนใจเรื่อง UX สามารถเข้าไปร่วมกลุ่มกันได้ที่ Facebook group UX Thailand นะครับ
