การเดินทางสู่เป้าหมายชีวิต ด้วยแนวคิด Agile — EP 1: What do you require?
จัดกระเป๋า เราจะไปกันแล้ว
Recap
สำหรับอีพีที่แล้ว ผมได้แชร์เรื่องการตั้ง Roadmap ของตัวเองโดยมี Tips สั้นๆ 3 ข้อให้เราได้สำรวจและวางแผนเส้นทางไปสู่เป้าหมายชีวิตเรา อีพีนี้จะมาว่ากันด้วยเรื่อง “การเตรียมตัว” ให้พร้อมก่อนออกเดินทางกันครับ
Requirement แปลตรงตัวก็คงเป็น “ความต้องการ” แต่ถ้าพูดแบบนี้ก็อาจจะไม่เห็นภาพกัน เพื่อให้เข้าใจง่ายผมขอใช้คำว่า “การเตรียมตัว” แล้วกันครับ ธีมใหญ่ของซีรีส์นี้ผมอยากนำเสนอการบรรลุเป้าหมายในชีวิตผ่านการเดินทาง ดังนั้น “Requirement” เปรียบได้กับการเตรียมตัว เตรียมความพร้อม เตรียมสิ่งที่ต้องการก่อนออกเดินทางนั่นเอง
ในวงการ Software Development “Key Person” สำหรับเฟสนี้คงเป็นใครไปไม่ได้นอกจาก BA (Business Analyst) กับผู้ให้ Requirement หรือที่เรามักเรียกพวกเขาเหล่านั้นว่า “User”
แปลกมั้ย? ทำไมการวิเคราะห์หรือเก็บ Requirement ในงานที่ทำ ดูเป็นไปได้มากกว่าการนั่งวิเคราะห์ความต้องการของตัวเองซะอีก!
ซึ่งคำตอบมีจะด้วยกัน 2 แบบครับ
- เราไม่เคยใช้เวลานั่งวิเคราะห์มันจริงๆ จังๆ ซักที
- เราคิดว่าเรารู้ว่าต้องการอะไร แต่จริงๆ เราไม่รู้หรอก
ผมมีเคล็ดลับ Practice เล็กๆ 7 ข้อที่จะช่วยให้คุณวิเคราะห์ Requirement เพื่อไปสู่เป้าหมายของคุณให้มีประสิทธิภาพมากขึ้น พร้อมกับการยกตัวอย่างจากแผนที่ผมลองทำจริงๆ มาแชร์ให้ดูกันครับ
1. Supplement User Stories
คือการเล่าความต้องการของเรานั่นเอง! การทำแบบนี้จะช่วยให้เข้าใจภาพรวมและสาเหตุที่ต้องการจะเปลี่ยน ลงมือทำ หรือเพื่อผลลัพธ์อะไรซักอย่าง ยิ่งการเล่าเรื่องละเอียดมากเท่าไหร่จะยิ่งทำให้เราวิเคาระห์ความต้องการที่แท้จริงออกมาได้มากเท่านั้น รวมถึงบางครั้งจะช่วยเติมสิ่งที่เราอาจนึกไม่ถึงอีกด้วย
ยกตัวอย่าง หนึ่งใน Roadmap ของผมคือด้านสุขภาพ
เมื่อแก่ตัวผมอยากมีสุขภาพที่ดี แข็งแรง สามารถทำกิจกรรม เล่นกีฬากับลูกๆได้ และต้องไม่เป็นภาระพึ่งพาอาศัยใครในการใช้ชีวิตประจำวัน
ประโยคยาวๆ ข้างต้นเทียบเท่ากับ User Story แหละ ทีนี้ลองมา Supplement (เพิ่มเติม) ดูว่ามีอะไรตกหล่นไปมั้ย?
จะเห็นได้ว่า Story สั้นๆ นี้จริงๆ มีหลายสิ่งหลายอย่างซ่อนอยู่ เราต้องหาให้เจอ!
2. Involve Stakeholder Regularly
ช่วงระหว่างการทำ Requirement การสื่อสารคือสิ่งสำคัญ อาจฟังดูบ้าไปหน่อย แต่ “คุณนั่นแหละที่ต้องสื่อสารกับตัวคุณเอง” เพราะทั้ง Requirement วิธีการที่เหมาะสม ผลลัพธ์ที่คาดหวัง เชื่อเถอะ! ไม่มีใครรู้ดีไปกว่าตัวคุณเองหรอก
จากข้อแรก “Supplement” ความแข็งแรงและการเล่นกีฬาได้ ปัจจัยอย่าง “การลดน้ำหนักส่วนเกิน” อาจจะส่งผลหรือไม่อย่างไร? ผมต้องสวมหมวกทั้ง 3 ใบ 3 Role ในการไตร่ตรอง Recheck และสื่อสารกับตัวเองเพื่อหาคำตอบนั้น
3. Prioritize Requirements
ส่วนนี้ผมให้ความสำคัญมากเนื่องจากในหนึ่ง Story สามารถแตกแยกย่อยได้หลาย Requirement มาก และ “ให้ตายเถอะ! มันไม่มีทางทำได้หมดในทีเดียวแน่ๆ” ผมมี Criteria ในการจัดลำดับความสำคัญที่ผมลองเอามาใช้เอง หรือที่ผมเรียกว่า “3Q Filter” กับ 3 คำถามง่ายๆ
- Does it give you the most benefit? มันจะให้ผลประโยชน์ที่ดีที่สุดมั้ย
- Are you 100% sure you’ll be able to do it? มั่นใจ 100% เลยว่าทำได้แน่ๆ ใช่มั้ย
- Can you start tomorrow? เริ่มพรุ่งนี้เลยได้มั้ย
ถ้า Requirement ที่ว่าผ่าน Criteria ทั้ง 3 ข้อนี้ แล้วคำตอบคือ “ใช่” ทุกข้อ ไม่ต้องลังเลเลย นั่นคือสิ่งที่ต้องทำก่อนเลย ผมลองนำ Requirement ย่อยๆ มาผ่าน 3Q Filter Criteria ได้ออกมาเป็น 3 ข้อตามนี้ครับ
เพราะฉะนั้นวันพรุ่งนี้ผมสามารถเริ่มกินสลัด 1/3 มื่อต่อวัน นั่งสมาธิ และออกกำลังกายได้เลยทันที
4. Focus on Executable Requirements
การให้ความสำคัญ Requirement ที่ดี ให้ประโยชน์มากสุด แต่ไม่สามารถลงมือทำได้นั้นไม่มีประโยชน์และถือเป็นการเสียเวลาเปล่าครับ ไม่ต่างอะไรเลยกับการนั่งคิดว่าต้องเตรียมเงิน มีคนดูแลสุขภาพตอนแก่ ทั้งที่จริงๆ เราดูแลสุขภาพเราได้ตอนนี้เลย เพราะฉะนั้นหลังจากที่จัดลำดับความสำคัญแล้ว อย่าจมอยู่กับ Requirement ที่ยังไม่ได้เลือก หรือ Requirement อื่นๆ ถ้ามันผ่าน 3Q Filter Criteria มาและคือสิ่งที่เหมาะกับสถานการณ์ในปัจุบันแล้ว ให้โฟกัสกับมันและไม่ต้องห่วง Requirement อื่นๆ เพราะเรายังเก็บ Requirement เหล่านั้นเป็น Backlog ให้มา Prioritize อีกรอบได้ และเมื่อถึงตอนนั้น Criteria ทั้งหมดอาจเป็น “Yes” ให้หยิบมาทำก็เป็นได้
หลังจากได้ Priority มา 3 อย่างแล้ว ผมก็เริ่มมาเช็คตารางชีวิตว่าผมจะเอาอันไหนลงในช่วงวันเวลาไหนได้บ้าง โดยที่โฟกัสแค่ 3 อย่างนี้ก่อน
5. Use “INVEST” Principle
Independent Requirement ที่ดีควรเป็น “อิสระ” ไม่เกี่ยวพันกับข้ออื่นๆ (หาก Story ของคุณยังไม่สามารถยืนด้วยตัวเองได้ ให้ย่อยมันลงอีก! อย่างกรณีของผม จะเห็นได้ว่า “สุขภาพดี” ที่ผมเลือกมาทำ คือ การทานสลัด 1/3 มื้อต่อวัน กับ การทำสมาธิ ซึ่งไม่เกี่ยวพันกันใดๆ ดังนั้นลองสำรวจ Requirement ดู หากยังพบว่ามันพัวพันกันอยู่ บางทีอาจจะต้องแยกหัวข้อ แยกเรื่อง หรือทำให้มันเล็กลงไปอีก
Negotiable Requirement สามารถยืดหยุ่น ต่อรอง เปลี่ยนแปลงได้ เพื่อให้สามารถทำได้จริงภายใต้สถานการณ์ที่มีแนวโน้มเปลี่ยนแปลง และปัจจัยต่างๆ ที่ไม่แน่นอนอยู่เสมอ อะไรแข็งไปก็ไม่ดี อ่อนไปก็ไม่ได้ เพราะฉะนั้นต้องมีจุดพอดี เปิดโอกาสให้ต่อรองหาสิ่งที่เหมาะสมที่สุด
การนั่งสมาธิคือหนึ่งใน 3 สิ่งที่ผมเลือกทำ ผมจัดตารางโดยจับเวลา 20 นาทีตอน 3 ทุ่มทุกวัน ผลปรากฏว่าทำได้อยู่ 3 วัน เนื่องด้วยบางวันเลิกงานดึกบ้าง บางวันยังอยู่ข้างนอกบ้าง ขับรถบ้าง สถานการณ์ที่ไม่แน่นอนในแต่ละวัน ผมเลยต่อรองว่า “เห้ยแบบนี้ไม่ได้ละ งั้นขอเป็นเวลาไหนก็ได้ นั่ง 10 นาทีพอ แต่จะทำทุกวันไม่ให้ขาดเลย” ผลลัพธ์ที่ได้คือผมทำติดต่อกันมาทุกวันเข้าเดือนที่ 3 แล้ว
Valuable จะคล้ายกับหนึ่งใน 3Q Filter คือ “Does it give you the most benefit?” ถ้าไม่เป็นการเพิ่มมูลค่าหรือให้เราขยับเข้าใกล้เป้าหมายเราอีก 1 ก้าว “Don’t waste your time” ไม่มีประโยชน์ อย่าไปทำ
Estimate Requirement ที่นำมาทำต้องผ่านการประเมินมาด้วย เช่น จะทำต้องใช้อะไรบ้าง ประเมินคร่าวๆ ว่าเรามี Resource เพียงพอทำได้มั้ย ทำได้ทันตามกรอบเวลามั้ย
ประเด็นเรื่อง “การไม่เป็นภาระผู้อื่นตอนแก่” ยังเป็นปลายเปิดสำหรับผม อาจจะเนื่องด้วยอายุที่ยังอีกนานกว่าผมจะถึงจุดนั้น จึงยังไม่สามารถประเมินรอบด้านหรือหาตัวชี้วัดได้ว่าจะต้องมีการจัดการอย่างไร และ Requirement ที่ไม่สามารถประเมินได้จึงนำเก็บเป็น Backlog ยังไม่โฟกัสตอนนี้
Small แนวเดียวกันกับข้อ “I” “Independent” ถ้า Requirement ยังพัวพัน ยุ่งเหยิง ซับซ้อนกันไปหมด เราต้องทำให้เข้าใจง่ายและเบสิคที่สุด
ข้อออกกำลังกาย ผมได้แบ่งย่อยมันลงไปอีก คือ “Weight Training” กับ “Cardio” และย่อยมากกว่านั้น แบ่ง Weight Training เป็นแต่ล่ะส่วนเล่นในแต่ล่ะวัน เช่น Mon day แขน, Tuesday ไหล่ และ Cardio 1 ชั่วโมง แบ่ง 30 นาทีแรกปั่นจักรยาน 30 นาทีหลังวิ่ง ย่อยจนไม่ต้องคิดเลยว่าวันนี้ต้องทำอะไร แค่ลุกออกไปทำเลย มีตารางไว้อยู่แล้ว
Testable ทั้งหมดที่กล่าวมาข้างต้นจะไม่มีประโยชน์เลยถ้าไม่มี Output ดังนั้น Requirement ที่เลือกทำจะต้องทำได้และให้ Output ที่จับต้องได้ เป็นรูปธรรม ทดสอบและวัดผลได้ ไม่มีเหตุผลที่จะลงมือทำในสิ่งที่เราไม่รู้ว่าจะนิยามผลลัพธ์มันยังไง
ตัวอย่างที่ผมอยากพูดถึงมากๆ คือการนั่งสมาธิ คิดว่ามันวัดผลเป็นรูปธรรมหรือจับต้องได้มั้ย? คำตอบคือ “ได้” หลายคนอาจจะคิดไม่ถึง เช่น คุณนอนหลับง่ายขึ้น คนรอบข้างบอกคุณดูเป็นคนใจเย็นหรือนิ่งขึ้น เวลาเจอปัญหาคุณตื่นเต้นหรือวิตกกังวลน้อยลงเพราะรู้ว่ามันมีทางออก คุณเริ่มรู้สึกว่าคุณอยากทำมันทุกวัน สัญญาณเหล่านี้เป็นตัวบ่งชี้ถึง Progress ของการนั่งสมาธิทั้งสิ้น (ไว้ผมจะแชร์เรื่องการนั่งสมาธิในบทความอื่นเพื่อไม่ให้นอกเรื่องของบทความนี้ครับ)
6. Think Layers, Not Slices
หลายครั้งที่เรามักเข้าใจผิดว่า Agile คือแบ่งงานเป็นชิ้น แต่จริงๆ แล้วมันแบ่งเป็นชั้น หลายคงอาจจะคุ้นเคยกับ Agile Car Example ที่ว่าด้วยการทำ MVP (Minimum Variable Product)
การ Think Layers, Not Slices คือการวิเคราะห์ Requirement แบ่งเป็น MVP ที่ใช้งานได้เลย และค่อยๆ ต่อเติมขึ้นไปเรื่อยๆ ไม่ใช่การทำทีละชิ้น ที่ไม่สามารถใช้งานได้จนกว่าทั้งหมดจะเสร็จและประกอบเข้าด้วยกัน
“การมีสุขภาพดี” เป็นคำสั้นๆ ที่มีทั้งชั้นและชิ้นรวมๆ กันอยู่ข้างใน “ผมจะไม่สามารถมีสุขภาพดีได้เลย ถ้าผมเอาแต่นั่งสมาธิแต่นอนดึกหักโหมงานทุกคืน”
“ผมจะแข็งแรงได้อย่างไรถ้าเอาแต่ออกกำลังกายแต่ไม่ใส่ใจเรื่องการกิน”
อย่างที่บอก “ออกกำลังกาย Cardio + Weight Training” คิดเป็น 1 ชิ้น “ใส่ใจการกิน+คุมอาหาร” คิดเป็น 1 ชิ้น ย้อนกลับไปข้างต้น 2 อย่างนี้ยังคงเป็น Independent ต่อกันและสามารถทำได้โดยไม่มี Conflict ตาม INVEST Principle ถ้าทำแยกกัน ผลลัพธ์มีมั้ย? มี! แต่ประสิทธิภาพของผลลัพธ์คนละเรื่องกับการทำไปพร้อมกัน (Layer) เลย เพราะฉะนั้นคิดให้เป็น “ชั้น” ไม่ใช่ “ชิ้น” ครับ
7. Prototype and Update
สุดท้ายแล้ว Requirement ที่คิดไว้จะตอบโจทย์ (Pain Point) ได้ตามที่คาดหวัง 100% มั้ย? ไม่หรอกครับ เพราะต้องผ่านการจูน (Tune) ปรับแต่งจนเข้าที่เข้าทาง จึงเป็นที่มาว่าทำไมเราจึงควรนำ Requirement ไปทำต้นแบบก่อน จากนั้นนำมาเปรียบเทียบกับความคาดหวัง (Expectation) ว่าใช่หรือไม่ เหมาะหรือไม่เหมาะ นำมาปรับและอัพเดตส่วนที่ต้องแก้ไขเพิ่มเติมกลับเข้าไป จนได้เกือบๆ ใกล้เคียงกับที่คาดหวังมากที่สุด
สำหรับการออกกำลังกายนั้น ตอนแรกผมทำ Prototype มาว่าจะ Cardio ด้วยการปั่นจักรยานอย่างเดียว 60 นาทีเต็ม เบิร์นได้ประมาน 600 Kcal อัตราการเต้นของหัวใจเฉลี่ยอยู่ที่ 130 ครั้งต่อนาที และมีอาการปวดหลังล่างเนื่องจากการนั่งปั่นต้องงอหลังเป็นเวลานาน ถามว่าได้ตามที่คาดหวังมั้ย ก็ได้นะถึงเป้า Kcal กับอัตราการเต้นของหัวใจ แต่ผมได้อาการปวดหลังล่างมาด้วยนี่สิ ไม่ดีแน่ในระยะยาว ผมจึงมาลองใหม่ โดยแบ่งวิ่ง 30 นาที ปั่นจักรยาน 30 นาที เบิร์น Kcal ประมาน 900 อัตราการเต้นของหัวใจเฉลี่ยที่ 145 ครั้งต่อนาที และไม่มีอาการบาดเจ็บหรือปวดอะไรเลย ผมจึงได้ข้อสรุปว่า Prototype อันนี้แหละเหมาะสมและตรงกับความคาดหวังที่สุด
แก่นสำคัญต่างๆ ก็ได้อธิบายจบไปแล้ว กับอีพีนี้ที่ว่าด้วยเรื่องการค้นหา วิเคราะห์ Requirement หรือการเตรียมความพร้อมก่อนออกเดินทางไปสู่เป้าหมายชีวิตของเรา ลองนำไปใช้หาความต้องการของตัวเองกันนะครับ
อีพีถัดไป รถจะสตาร์ท ล้อจะหมุนกันแล้วนะครับ
“Sprint and Iteration — ค่อยๆ ไป อยากแวะไหนรึเปล่า?”
สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech
