ก่อนอื่นต้องขอเกริ่นว่าทีมงานผู้เขียนอยู่ในบริษัทที่รับจ้างพัฒนาระบบ และทีมงานก็พยายามยึดหลัก Agile ในการทำงาน โดยมี SCRUM Framework เป็น backbone ในการดำเนินโครงการต่างๆ บทความนี้จึงเขียนขึ้นจากประสบการณ์ของทีมงานที่ได้ร่วมทำงานกับลูกค้ามาเป็นจำนวนหนึ่ง และสังเกตเห็นรูปแบบของความเข้าใจที่ไม่ตรงกันระหว่างลูกค้าและพวกเรา

ลองมาเข้าใจเรื่องราวกันก่อน

จริงอยู่ที่ SCRUM ถูกคิดค้นขึ้นมาตั้งแต่ปี 1990 หลังจากนั้น 20 ปี Scrum Guide ได้ถูกตีพิมพ์ออกมา Revision แรกเมื่อปี 2010 และถูกปรับปรุงมาอย่างต่อเนื่อง 6 reviesions ซึ่ง Revision ล่าสุดออกมาเมื่อปี 2020 (ที่มา https://scrumguides.org/revisions.html) ที่ต้องหยิบเรื่องนี้ขึ้นมาพูดเพราะผู้เขียนอยากเปรียบเทียบ Timeline กับ Waterfall methodology ที่ได้มีการคิดค้นขึ้นมาโดย Winston w. Royce ในปี 1970 (ที่มา https://www.forbes.com/advisor/business/what-is-waterfall-methodology/ ) พูดง่ายๆคือ SCRUM เกิดมา 20 ปีหลังจาก Waterfall และถูกนำมาใช้อย่างแพร่หลาย ช่วง 40 ปี หลังจาก Waterfall

แล้วมันมีผลกระทบกับพวกเราอย่างไร ลองจินตนาการว่าเราทำงานกับรูปแบบการทำงานแบบหนึ่งมามากกว่า 10 ปี ถึงวันหนึ่งก็พบว่ารูปแบบการทำงานนี้ไม่ใช่วิธีเดียวที่นำไปสู่ความสำเร็จได้ แม้ว่าบริษัทต่างๆพยายามจะเปลี่ยนแปลงตาม แต่ทุกๆอย่างไม่ใช่จะเปลี่ยนในชั่วข้ามคืน เพราะไม่ว่ารูปแบบสัญญา Mindset ในการทำงาน วิธีการจัดซื้อจัดจ้าง วิธีการส่งมอบงาน Incentiveในการทำงานต่างๆ ยังคงฝังรากกับ 40 ปีที่ Waterfall สร้างสมมา บริษัทในกลุ่ม SI, Software House, Digital Agency เป็นเพียงกลุ่มแรกๆที่เริ่มต้นใช้ Agile ในฐานะ Early Adopter แล้วบริษัทที่เหลือที่อยู่ในกลุ่มอุตสาหกรรมอื่นๆละ บริษัทเหล่านี้บางบริษัทอาจจะสามารถนำ Framework มาใช้ได้อย่างมีประสิทธิภาพ บางบริษัทกำลัง Transform บางบริษัทอาจจะเพิ่งเริ่ม และ บางบริษัทอาจจะไม่ทราบด้วยซ้ำว่า Agile คืออะไร

ในบทความนี้จึงอยู่บน Context ว่าเมื่อบริษัทเหล่านี้ได้มาร่วมทำงานกับลูกค้า ที่อยู่ในกลุ่มอุตสาหกรรมอื่นๆ จะเกิด Marathon Effect (they are not at our position yet) เราเลยมาเล่าให้ฟังว่าความคาดหวังส่วนใหญ่ที่ลูกค้าต้องการคืออะไร และ 3 สิ่งที่ลูกค้าสามารถคาดหวังจากโครงการ Agile ได้แต่ต้องด้วยความเข้าใจ(จริงๆนะ) คืออะไร

_{Source: Capstone Events}

What makes a project agile?

ก่อนที่เราจะเข้าเรื่อง (เอ๊ะ ทำไมไม่เข้าเรื่องสักที) มาทำความเข้าใจหลักการของ Agile ก่อน

Agile ความหมายตรงตัวภาษาไทยคือ รวดเร็ว คล่องตัว

_{ag·ile
/ˈajəl/
adjective
able to move quickly and easily.“Ruth was as agile as a monkey”}

รวดเร็วยังไง คล่องตัวยังไง รวดเร็วและคล่องตัวในการตอบสนองต่อการเปลี่ยนแปลงที่อาจจะเกิดจากความที่ Business มันเปลี่ยนแปลงค่อนข้างไว หรือผู้ใช้งาน ผู้ว่าจ้าง มี Input/Feedback ใหม่ๆที่สำคัญต่อ Product ที่กำลังพัฒนาอยู่

แล้วมันทำอย่างไรละ? คำตอบแบบอ้อมๆจากทีมงานผู้เขียนคือ Agile เป็นเพียง Mindset ที่ยึดหลัก 4 ข้อต่อไปนี้ และ 4 ข้อนี่ละที่ทำให้รวดเร็ว คล่องตัว

_{Source: Agile Manifesto}

คำแปล Manifesto ภาษาไทยด้านล่าง ทีมงานแปลเอง ขออภัยหากสื่อความหมายไม่ชัดเจน

1. Individuals and interactions over processes and tools = การสื่อสารและทำงานร่วมกันระหว่างทีมงาน มีความสำคัญกว่า กระบวนการและเครื่องมือ
2. Working software over comprehensive documentation = ระบบหรือผลิตภัณฑ์ที่ผู้ใช้งานสามารถใช้งานได้จริง มีความสำคัญกว่า เอกสารต่างๆที่ใช้ในการพัฒนา
3. Customer collaboration over contract negotiation = ความร่วมมือระหว่างทีมพัฒนากับลูกค้าหรือผู้ใช้บริการ มีความสำคัญกว่า การต่อรองในสัญญา
4. Responding to change over following a plan = ตอบสนองต่อการเปลี่ยนแปลง มีความสำคัญกว่า ดำเนินการตามแผน

มีเป็นพันๆบทความที่อธิบายเกี่ยวกับทั้ง 4 ข้อนี้ เพราะฉะนั้นทางทีมงานผู้เขียนจะขออนุญาตไม่บรรยายในรายละเอียดในบทความนี้ (ถ้าสนใจก็ comment ทิ้งไว้ได้ครับทีมงานจะได้สร้างบทความแยกของเรื่องนี้ขึ้นมา) แต่แนะนำให้ลองไปอ่านดูที่ SCRUM Guide เลยระกัน https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf ที่อยากจะเน้นคือ “…there is value in the items on the right, …”

3 ความคาดหวังจากลูกค้าหรือผู้ใช้บริการ

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

1. Fixed Timeline

_{Source: Djim Loic}

คำถามสำคัญสำหรับลูกค้าเวลาจะจ้างพัฒนาอะไรสักอย่างคือ เวลา เพราะบางสิ่งบางอย่างถ้าช้ากว่าคู่แข่งก้าวเดียวก็มีผลต่อการบริโภค หรือ ต้นทุนการปฏิบัติการ ทำให้ข้อมูลด้านเวลานี้มีผลต่อการตัดสินใจ แล้วในโครงการ Agile จะตอบคำถามลูกค้าเรื่องเวลาได้อย่างไร ในเมื่ออะไรก็ไม่แน่นอน (welcome change) คำตอบคือ “ได้ (แต่ต้องเข้าใจมันด้วยนะ)” อิหยังวะ ได้ยังไง เข้าใจอะไร

Agile Methodology โดยเฉพาะ SCRUM กับ XP ทำงานเป็น Timebox คือมีระยะเวลาแต่ละรอบ (Cycle) ที่แน่นอน

• SCRUM ใช้เวลาแต่ละรอบ(ซึ่งเราเรียกกันว่า Sprint) 2 สัปดาห์เป็นอย่างต่ำ และ XP เป็นรอบละสัปดาห์
• แต่ละรอบทีมงานจะส่งมอบ Feature บางอย่างที่ช่วยแก้ปัญหาผู้ใช้บางอย่างได้ (เป็นประโยชน์)
• ส่วนใหญ่แล้วทีมก็จะพัฒนา Feature ตามลำดับความสำคัญในมุมมองของผู้ใช้งาน

ลูกค้าอาจจะถามว่าจะรู้ได้อย่างไรว่า Feature ที่เชื่อว่าเป็น highlight นั้นจะเสร็จเมื่อไหร่ กี่รอบ กี่ Sprint คำตอบก็คือ เราไม่รู้หรอก (Everyone sucks at planning) เนื่องจากเราไม่ได้มีรายละเอียดทั้งหมดในการประเมิน (แต่ถ้ามีก็จะกลายเป็น Waterfall แล้ว) แต่ที่เราทำได้ในฐานะผู้รับจ้างคือ

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

สิ่งที่ลูกค้าต้องเข้าใจคือ การแบ่ง Feature เป็น Sub Feature นั้น ทุกๆ Sub Feature ที่พัฒนาต้องมีประโยชน์ต่อผู้ใช้ในตัวมันเอง ยิ่งถ้าเวลามีความสำคัญต่อการบริโภค การที่เรานำ Sub Feature บางส่วนมาให้ลูกค้าใช้ก่อนจะมีผลดีมากกว่าผลเสีย เนื่องจากลูกค้าบางส่วนเริ่มได้รับประโยชน์ทันที ไม่ต้องรอ Sub Features อื่นๆที่ไม่รู้ว่าจะได้ใช้หรือไม่ และผลดีอีกอย่างคือ เราสามารถรับ Feedback จากการใช้งานจริงมาปรับปรุงผลิตภัณฑ์ในอนาคตได้อีกด้วย ทั้งหมดที่กล่าวไป อิงอยู่บน Pareto Principle 80/20 กล่าวคือ 80% ของผู้ใช้ ใช้ Sub Features เพียง 20% ของที่ผลิตภัณฑ์นั้นมีเท่านั้น

เพราะฉะนั้นลูกค้าจะต้องเปลี่ยนความเข้าใจใน Timeline ของโครงการ Agile ว่าเป็นวันที่ที่จะ Release บางอย่างออกไปถึงผู้ใช้ มีให้ใช้แค่ไหนก็นำออกไปเท่านั้นก่อน ซึ่งในรอบถัดๆไปก็จะมี Feature ใหม่ตามมา เราประเมินกันให้ดีที่สุด และถึงแม้ทำจริงจะไม่ได้ทุก Feature ตามที่วางแผนไว้ แต่ทุกๆรอบจะมี Value ส่งถึงผู้ใช้ได้เสมอ ยิ่งบางทีมมี practice แบบ CI/CD แล้วการนำขึ้นแต่ละรอบจะไม่น่ากลัวเหมือนโครงการ Waterfall อีกต่อไป

2. Ability to change whatever whenever

_{Source: Daria Nepriakhina}

ลูกค้ามักคาดหวังว่าโครงการ Agile สามารถแก้ไข Requirement ได้เรื่อยๆ ซึ่งเป็นความเข้าใจที่ อืมมมมมม….ถูกต้องละ เราเลือก Agile เพื่อให้ Feedback Loop นั้นเร็วขึ้น เพื่อพัฒนาต่อยอดหรือแก้ไขปัญหาได้ทันท่วงที แต่เราต้องไม่ลืมว่าทุกๆการเปลี่ยนแปลงนั้นมีผลที่ตามมาหรือสิ่งที่ต้องแลกเปลี่ยน (Trade-off) เสมอ ในโครงการ Agile ก็เช่นกัน แม้ว่าจะถูกออกแบบมาเพื่อรองรับการเปลี่ยนแปลง (Welcome change) แต่ความถี่และขนาดของการเปลี่ยนแปลงก็ส่งผลกระทบต่อความก้าวหน้าของโครงการไม่มากก็น้อย เพราะฉะนั้น หากทีมงานทั้งสองฝั่งเจอปัญหา เช่น

• ลูกค้าขอเปลี่ยน User Story กลาง Sprint
• ผู้บริหารขอเปลี่ยนจุดประสงค์การใช้งานของระบบ
• ต้องการให้ทุก Story รองรับการทำงานมากกว่า 100 concurrent transactions เป็นต้น

แล้วเกิดคำถามว่า ได้ด้วยเหรอ คำตอบจากผู้เขียนคือ “ได้ (แต่ต้องเข้าใจมันด้วยนะ)” ลองมาดูรายละเอียดกันว่าต้องเข้าใจอะไร

• เข้าใจว่ามี Cost/Effort ที่ต้องใช้สำหรับการเปลี่ยนแปลงเหล่านั้นเสมอ
  Cost หรือ Effort ที่ว่านี้มักเป็นตัวแปรสำคัญที่ทำให้โครงการ delay ออกไปเพราะการมองแค่ Cost ที่ใช้ในการ Implement สิ่งที่ต้องการปรับเปลี่ยน แต่ไม่ได้คิดถึง Cost ประเภทอื่นๆ ที่ส่งผลกระทบถึงการส่งมอบงานอื่นๆ อาจทำให้มีค่าใช้จ่ายแฝงอื่นๆ ที่ไม่คุ้มค่าต่อการเปลี่ยนแปลงได้ โดย Cost สามารถแบ่งออกเป็น 3 ชนิดใหญ่ๆได้ดังนี้
  • Implementation Cost เป็นค่าใช้จ่ายที่เกิดจากจำนวนวันที่ใช้ในการ Implement การเปลี่ยนแปลงนั้นของ Development Team ซึ่งจะค่อนข้างตรงไปตรงมา เช่น จำเป็นต้องใช้ Dev 2 คน จำนวน 4 วัน ก็จะมี Cost คิดเป็นค่าแรงจำนวน 8 Man-days
  • Overhead Cost เป็น effort ของเหล่า PO, PM, BA/SA, DevOpsหรือแม้แต่ Development Team บางส่วน ที่ต้องลงแรงไปกับการคิดแผนงานหรือ POC เพื่อให้มั่นใจว่าสิ่งที่เราต้องการเปลี่ยนนั้นเป็นสิ่งที่ถูกต้อง ซึ่งสิ่งนี้มักไม่ถูกนับเป็นหนึ่งใน deliverable ของโครงการในกรณีที่เรา POC (proof of concept) แล้วว่ามันไม่สามารถไปต่อได้ effort ส่วนนี้มักจะถูกปัดหายไป และกลายเป็นว่าโปรเจค delay แถมยังไม่มีงานมา deliver เป็นชิ้นเป็นอัน
  • Hidden Cost มักพบได้บ่อยในโครงการที่ค่อนข้างใหญ่หรือมีความซับซ้อนสูง ซึ่ง cost ตรงนี้จะยิ่งมากขึ้นไปอีกจนทำให้ Timeline ของโครงการอื่นๆที่มีความเกี่ยวข้องกัน ต้อง delay ตามกันไปด้วย เช่น พบว่าระบบไม่สามารถต่อกับ ERP ได้แบบ real-time จนกลายเป็นว่าไม่สามารถ Check Stock Online ได้ ซึ่งกระทบถึง Marketing Plan ต่างๆที่เกี่ยวข้องกัน แล้วแต่กรณี
• เข้าใจว่าระบบถูกออกแบบมาเพื่อรองรับ Objectives หนึ่ง
  หรือพูดอีกแบบหนึ่งคือ ระบบไม่ได้ถูกออกแบบมาเพื่อรองรับจุดประสงค์ที่ครอบคลุมจักรวาลได้ หมายความว่า วันหนึ่งเราจะผลิตระบบ e-Commerce แต่การจะเปลี่ยนระบบให้กลายเป็น LMS (Learning Management System) มันก็คงทำได้ละ แต่มันต้องปรับตั้งแต่โครงสร้างจนถึง Workflow การทำงานทั้หมด หลายครั้งที่เราพบว่าลูกค้าหรือเจ้าของโครงการต้องการเปลี่ยน Business Model ใหม่ ไม่ว่าจะทั้งเพื่อนำไปเป็นหัวข้อทำการตลาดหรือการ Raise Fund จากนักลงทุนก็ตาม โดยที่ไม่ได้คำนึงถึงจุดประสงค์หลักของโครงการว่ามีความสัมพันธ์ต่อกันแค่ไหน ซึ่งสุดท้ายแล้วผลลัพธ์ส่วนมากคือ Core Features ไม่สามารถส่งมอบได้ทันเวลา เนื่องจากปัญหาเหล่านี้
  • ไม่สามารถนำมาต่อยอดกับ Core Function อื่นๆได้
  • ระบบที่พัฒนาอยู่ไม่ได้ออกแบบมาสำหรับ Function ดังกล่าว
  • มีการ Rework สูงเนื่องจากปรับรายละเอียดของ Requirement ตลอดเวลา
• เข้าใจว่า Impact Analysis คือสิ่งแรกที่ต้องทำ
  ส่วนมากเวลาที่เราต้องตัดสินใจปรับ Requirement เรามักจะเน้นไปที่เรื่องของ Ideas หรือแนวทางในการพัฒนา แต่เรามักไม่มีการหยิบประเด็นเรื่อง Impacts ที่จะเกิดขึ้นต่อส่วนอื่นๆมาถกเถียงหรือวิเคราะห์อย่างจริงจัง ซึ่งสิ่งนี้มักเป็นสาเหตุหลักที่ทำให้เกิด Hidden Issues ขึ้นและส่งผลให้ Project Timeline ที่ Estimate ไว้นั้นมีโอกาสสูงที่จะไม่สามารถทำได้จริง
  เรื่องนี้สำคัญมากจริงๆ การลงแรง ลงเวลาในการวิเคราะห์ก่อนที่จะทำการเปลี่ยนแปลงใดๆ เพื่อให้ได้มาซึ่งข้อมูลผลกระทบในหลายๆมุมก่อนการตัดสินใจ อาจจะเหมาะสมกว่า การลุยไปข้างหน้า ไม่มีการวางแผนใดๆ มีปัญหาแล้วค่อยแก้ไข มันต้องมีสมดุลย์ เพราะสิ่งที่แย่กว่าการเปลี่ยนแปลง คือ การขอเปลี่ยนกลับไปเป็นเหมือนเดิม เมื่อพบว่าทางที่เราเลือกจะเปลี่ยนนั้นอาจจะไปเจอทางตัน หรือ ใช้เวลามากกว่าหลายเท่าเทียบกับแนวทางในตอนแรก

3. Low involvement

_{Source: Dylan Gillis}

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

ในโครงการแบบ Waterfall ที่มีลักษณะ Big Requirement Up Front (BRUF) ลูกค้ากับทีมงานอาจจะมาเจอกันตอนเริ่มต้นโครงการเพื่อพูดคุย detailed กันให้เรียบร้อยและ Sign off requirement แล้วมาเจอกันอีกทีตอนตรวจรับ ระหว่างที่ผู้รับจ้างพัฒนา Develop Software ลูกค้าก็สามารถใช้เวลาสะสางงานที่สะสมไว้

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

และอีกครั้งที่ทีมงานผู้เขียนอยากจะบอกว่า “ได้ (แต่ต้องเข้าใจมันด้วยนะ)”

จริงอยู่ว่าการที่ลูกค้ามีเวลาให้กับทีมผู้รับจ้างอย่างเพียงพอจะก่อให้เกิดผลลัพธ์ที่ดีที่สุดทั้งในแง่ของผลิตภัณฑ์ และ ความสัมพันธ์ แต่หากลูกค้าไม่สามารถสละเวลาได้มากขนาดนั้น อย่างน้อยก็ขอให้มีเวลาทำสิ่งต่อไปนี้

• มีเวลาแจง Wish list ว่าต้องการสิ่งใดบ้าง
• มีเวลาเล่าให้ทีมฟังว่าสิ่งเหล่านั้นมีประโยชน์อย่างไร ช่วยผู้ใช้งานอย่างไร
• มีเวลาในการบอกทีมว่าสิ่งไหนสำคัญกว่าสิ่งไหน
• มีเวลาในการตรวจสอบผลลัพธ์ของทีมแต่ละรอบว่ามาถูกทางไหม

ลูกค้าบางคนอาจจะสงสัยว่าแต่นี่มันคือเกือบทั้งหมดแล้วนี่? ก็ไม่เชิง มีอีกหลายอย่างที่ไม่ได้กล่าวถึงด้านบน เช่น

• รูปลักษณ์ หน้าตา (UX/UI)
• กระบวนการทำงานอย่างละเอียด (Detailed Steps)
• กรณียกเว้นต่างๆ (Edge cases)
• คุณสมบัติอื่นๆ เช่น รองรับผู้ใช้งานได้ XXX คนพร้อมกัน
• และ อื่นๆๆๆๆๆๆ

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

แต่ก็ต้องเข้าใจว่ามันมาพร้อมความเสี่ยง

• เสี่ยงที่จะไม่ได้เป็นไปตามที่ลูกค้าอยากให้เป็น และต้องมีการ rework/repurpose กันบ้าง เนื่องด้วยผู้รับจ้างมี background และ ความรู้ต่างกัน อาจไม่สามารถคิดหรือทำได้ตรงใจกับลูกค้า (ขนาดตัวเราเองยังไม่พอใจบางอย่างที่เราทำเองเลย) หรือบางครั้งก็อาจจะไม่มีใครตัดสินใจเลยก็ได้ และค่อยนำมาคิดกันในวันหลัง
• เสี่ยงที่ทีมพัฒนาจะส่งมอบ Feature หรือ Value ได้น้อยลง เมื่อทีมต้องใช้เวลาและพลังในการไปคิดเรื่องดังกล่าว

ผู้เขียนอยากจะย้ำว่าในความเป็นจริงแล้ว SCRUM Framework ก็ไม่ได้ขอเวลามากมายจากคนทางฝั่งผู้ใช้งานหรือลูกค้ามากนัก โดยขออนุญาตแจงระยะเวลาโดยประมาณที่ Framework ระบุไว้สำหรับ 2-week Sprint

• สูงสุด 4 ชั่วโมง สำหรับ Sprint Planning
• สูงสุด 2 ชั่วโมง สำหรับ Sprint Review
• ประมาณ 8 ชั่วโมง สำหรับ Product Backlog Refinement

รวมแล้ว 14 ชั่วโมง สำหรับการทำงาน 80 ชั่วโมง (2 สัปดาห์ หรือ 10 วัน) หรือ 17.5% เท่านั้นเอง และผู้พัฒนาส่วนใหญ่ก็ชอบที่จะทำงานกับ Code มากกว่าที่จะคุยกับลูกค้าเช่นกัน เพราะฉะนั้นเชื่อได้เลยว่า ทีมงานจะใช้เวลาอย่างมีประสิทธิภาพกับลูกค้าแน่นอน เพื่อประโยชน์กับลูกค้าและตัวทีมงานเอง

พูดเหมือนจะง่าย แต่ถ้าลูกค้ายังไม่เข้าใจละ (Marathon Effect)

ก็จริงอีกขนาดทีมงานผู้รับจ้างอยู่กับ Agile มานาน เราก็มีการ Discuss ถึง Value ที่แท้จริงของ Agile และ Practice ที่ควรจะเป็น เพราะเราก็อยู่ในระหว่างการ Transform เช่นกัน ต่อไปนี้จึงเป็น Tips เล็กๆจากทีงานผู้เขียนที่อาจจะช่วย Speed up กระบวนการ ถ้าคิดว่ามีประโยชน์ผู้อ่านลองนำไปใช้กันได้ (หรือถ้าอยากได้รายละเอียดเพิ่มเติมก็ระบุมาใน Comment ได้)

• เริ่มอธิบาย Agile Mindset หรือวิธีการทำงานของบริษัทคุณ ไม่ว่าจะเป็น SCRUM, XP, Kanban ให้ได้เร็วที่สุดที่มีโอกาส เช่น ตอนขาย, ตอน Present Proposal, ตอนวางแผน, หรือ ตอน Kick-off เชื่อสิว่า มีลูกค้าจำนวนไม่น้อยอยากจะฟังวิธีการทำงานของเรา
• รายละเอียดสัญญาในโครงการก็ต้องสนับสนุนวิธีการทำงานแบบนี้ และต้องมี Incentive ที่จะช่วยให้ทุกฝ่ายเดินไปในทิศทางเดียวกัน เพราะสุดท้ายแล้วถ้าวิธีการทำงานแบบนี้คือ Main Factor สำหรับความสำเร็จในโครงการ มันก็ควรต้องระบุไปในสัญญาเพื่อเป็นข้อตกลงร่วมกันสิ เช่น R&R ของลูกค้าและของทีมงานผู้รับจ้าง วิธีการจัดการกับการเปลี่ยนแปลง วิธีการจัดการ Requirement วิธีการวัดความก้าวหน้า จำนวนทีมงาน Ceremonies ที่อยากให้ลูกค้ามีส่วนร่วม เป็นต้น
• Keep informing/educating at the right moment การอธิบายในตอนแรกอาจจะพอเห็นภาพ พอจะเข้าใจ concept บ้าง (abstract) แต่คงยากที่จะคาดหวังให้ลูกค้าเข้าใจอย่างลึกซึ้งภายในการอธิบายครั้งเดียว อาจจะต้องหาเวลาและโอกาสในการอธิบาย ว่า Practice บางอย่างที่เรานำมาใช้ในโครงการเพราะอะไรเพื่ออะไร เมื่อลูกค้าเห็นโจทย์จริง (concrete) ถึงวิธีการนำ Agile ไปใช้ และ Value/Principle ของมัน ความเข้าใจของลูกค้าจะดีขึ้น
• ให้ลูกค้าเข้ามามีส่วนร่วมกับทีมพัฒนาของผู้รับจ้าง Manifesto#3 (Customer collaboration over contract negotiation) เช่น เป็น Product Owner สำหรับ SCRUM team เพราะ Collaboration จะสร้างความเป็นหนึ่งเดียวกัน สร้างความเข้าใจ และเพิ่ม Engagement ให้กับทีมงาน

Key Takeaways

• Mindset และ วิธีการทำงานของ Waterfall และ Agile มีความแตกต่าง ในขณะที่ Waterfall จะฝังรากลึกกับอุตสาหกรรม Software มา 40 ปี แต่ Agile เพิ่งเริ่มเข้ามามีบทบาท ในรอบ 20 ปีที่ผ่านมา
• Agile Manifesto ทั้ง 4 ข้อ เป็นเหมือน North Star ที่ช่วยในกระบวนการปรับตัวของแต่ละองค์กร
• การเปลี่ยนแปลงของบริษัทที่เป็น Service Provider นอกจากเรียนรู้ที่จะปรับตัวแล้ว จำเป็นต้องเข้าใจลูกค้าที่จะทำงานกับเราด้วย
• มองให้รอบด้านอยู่เสมอในทุกๆครั้งที่มีการเพิ่มเติมหรือปรับเปลี่ยน Requirement เพื่อให้แน่ใจว่าทีมงานไม่ได้ตกหล่นประเด็นไหน หรือมองข้ามปัญหาบางอย่างไป เพราะการกลับมาแก้ไขมักยากกว่าเสมอ
• อย่าให้ค่าแค่กับ Deliverable ที่สามารถจับต้องได้ เพราะทุก Activities ล้วนมีราคา (หรือเวลา) ที่ต้องจ่ายเสมอ ทั้งในรูปแบบของ Knowledge หรือ Experience ต่างๆต่อทั้งทีมงานและเจ้าของโครงการเอง
• ช่วยลูกค้าในการสร้างความเข้าใจเรื่อง Agile เปรียบเสมือนตัวเองเป็นอุปกรณ์ที่ให้บริการรูปแบบใหม่ ที่ลูกค้าต้องเรียนรู้ที่จะทำงานร่วมกันกับเราเพื่อดึงความสามารถเราออกมาได้ดีที่สุด หาโอกาสที่จะอธิบายหลักการต่างๆ อย่างเหมาะสม

Technology supplier หลายๆบริษัทเริ่ม Adopt Agile มาสักพักแล้ว คุณละพร้อมสำหรับการเปลี่ยนแปลงนี้หรือยัง

About Authors

1. _{Jesada Maythangkul (Ohm) is the Business Development/Consultant at MAQE. He has a solid background as Software Engineer and recently turned to Business Development to provide suitable solutions for various projects.}
2. _{Werachart Ratanatharathorn (Yim) has more than 15 years in project management. Currently holding a position of Head of Projects at MAQE. He has a strong passion for organizational project delivery and team psychology.}