On requirement change

เรื่องราวที่เรามักได้ยินจาก Developer เสมอ คือ ลูกค้าเปลี่ยนบ่อย

แล้วเรามองมันเป็นความสิ้นเปลือง (ซึ่งผมขอบอกว่าส่วนตัวผมเห็นด้วยแค่ครึ่งเดียวกับเรื่องนี้) ที่ต้องทำงานซ้ำซ้อน

แต่สิ่งที่ผมคิดว่าเราเข้าใจผิดกันคือ

“ถ้าเราไม่ยอมให้เปลี่ยนง่ายๆ แล้ว ลูกค้าจะคิดมาดี จะทำครั้งเดียวจบ แล้ว Productivity จะสูงกว่า จะสิ้นเปลืองน้อยกว่า”

ซึ่งผมว่าไม่จริง

ลองในทางกลับกัน ถ้าผมบอกแบบนี้ล่ะ

“ต่อไปนี้ เอาปุ่ม Backspace ออกไปจากคีย์บอร์ดเหอะ แล้วโปรแกรมเมอร์จะมี Productivity สูงขึ้นเพราะก่อนพิมพ์แต่ละตัวอักษรเขาจะคิดมาดีก่อนพิมพ์ ทำให้ไม่พิมพ์ซ้ำซ้อน”

โปรแกรมเมอร์ทุกคนคงบอกว่า Absurd และบ้ามากๆ

แต่ทำไมล่ะ?

ผมว่าเป็นคำถามที่น่า Explore และเจาะลึกลงไปนะว่า ทำไม แล้วจริงๆ เราอาจจะเข้าใจมุมของลูกค้ามากขึ้นนะ


ทำไมการเอา Backspace ออกไปถึงไม่ทำให้ Productivity สูงขึ้น?

  1. เพราะบางครั้ง เราก็ไม่รู้หรอกว่าเราจะเขียนโค้ดอะไร แล้ววิธีที่เร็วที่สุดในการเขียนคือ ลองดู รัน เวิร์คมั้ย ไม่เวิร์คก็เปลี่ยน หรือถ้า TDD ก็คือเขียนเทสก่อน เขียนโค้ด รันดู ไฟเขียวมั้ย ไม่เขียวก็เปลี่ยน นั่นเป็นวิธีการที่ โดยเฉลี่ยแล้ว ถึงแม้จะมี Waste จากการพิมพ์ตัวอักษรที่ลบทิ้งไปฟรีๆ Productivity สูงกว่าการพยายามวางแผนมาอย่างดีก่อนพิมพ์แต่ละตัวอักษร
  2. เพราะบางครั้ง ต่อให้วางแผนมาอย่างดีแล้ว ก็เจอเหตุไม่คาดฝันเกิดขึ้นได้ เราอาจจะวางดีไซน์มา ปรากฎว่าเอาเข้าจริงแล้วพิมพ์ไปซักพักเห้ย มันมีจุดที่เราลืมคิดได้ แล้วถ้าเราไม่สามารถลบทิ้งได้เลย
  3. เพราะบางครั้ง ดีไซน์ที่คิดมาตอนแรกก็ไม่สมบูรณ์ แล้วมันคุ้มค่ากว่าที่เราจะ Refactor แทนที่จะยืนกรานว่าจะทำตามดีไซน์แรกโดยไม่ลบโค้ดเลยแม้แต่ตัวอักษรเดียว
  4. เพราะบางครั้ง มันก็มี Bug บางอย่างที่ไม่คาดฝัน แล้วถ้าเราลบโค้ดเก่าไม่ได้เลยได้แต่เพิ่ม กลายเป็นว่าเพื่อแก้ Bug นั้นเราก็อาจจะต้องสร้าง Class หรือ Method ใหม่มารองรับเคสนั้น ซึ่งกลายเป็นว่าสิ้นเปลืองกว่าเดิม

ในทางตรงกันข้าม ผมคิดว่า Metaphor พวกนี้ก็ใช้ได้กับ Stakeholder ด้วย

  1. บางครั้ง เขาก็ไม่รู้หรอกว่าเขาอยากจะได้อะไร แล้ววิธีที่เร็วที่สุดคือลองทำ Prototype เทส เวิร์คมั้ย ไม่เวิร์คก็เปลี่ยน หรือถ้าเป็น Lean ก็คือตั้งสมมติฐานก่อน เทสดู สมมติฐานผ่านมั้ย ไม่ผ่านก็เปลี่ยน นั่นเป็นวิธีการที่โดยเฉลี่ยแล้ว แม้จะมี Waste จากการทำ Prototype ที่ไม่เวิร์ค ก็ยังมี Productivity สูงกว่า
  2. บางครั้ง ต่อให้เราคิดในแง่ของ Marketing หรือดีไซน์มาอย่างดี ก็เจอเหตุไม่คาดฝันได้ เอาเข้าจริงแล้วทำไปซักพัก เห็น Product นิดหน่อย อ้าวมีจุดที่เราลืมคิดไปนี่หว่า
  3. บางครั้ง สิ่งที่คิดตอนแรกก็ไม่สมบูรณ์ แล้วมันจะคุ้มค่ากว่าที่จะขอเปลี่ยน Requirement แทนที่จะยืนกรานว่าจะทำตามแรกโดยไม่เปลี่ยนเลยแม้แต่นิดเดียว
  4. เพราะบางครั้ง มันก็มีปัญหาบางอย่างจากตลาดที่ไม่คาดฝัน แล้วถ้าเราเปลี่ยนอะไรไม่ได้เลย เราก็อาจจะต้องเปิดโปรเจ๊กต์ใหม่เพื่อนแก้ปัญหานั้นแทน ซึ่งสิ้นเปลืองกว่าเดิม

จริงๆ Stakeholder มันก็คือมนุษย์เดินดินกินข้าวแกงเหมือนโปรแกรมเมอร์แหละครับ ไม่ว่าเขาจะมีหัวโขนเป็น CEO, นายกของกระทรวงทบวงกรมใดๆ, หัวหน้าผู้บริหารระดับ C อะไรก็ตาม, ผู้จัดการ หรืออะไรก็ตาม มันก็ไม่ได้ต่างจากเรา

สุดท้ายไม่ว่าหัวโขนนั้นจะเป็นอะไรก็ตาม แต่เนื้อแท้เขาก็มนุษย์เหมือนๆ เรา

งานที่เขาทำมันก็เหมือนเรา

เขาก็ไม่ได้รู้ทุกอย่าง เหมือนกับเราที่ไม่ได้รู้ทุกอย่างก็เขียนโค้ดแต่ละตัวอักษร

เขาก็ต้องการปุ่ม Backspace เหมือนกับโปรแกรมเมอร์อย่างเราๆ นี่แหละ


ผมคิดว่าปัญหาจริงๆ ไม่ใช่การเปลี่ยน Requirement แต่ถ้าเปลี่ยนแล้ว Budget เท่าเดิมหรือ Deadline เท่าเดิมมากกว่า อันนั้นที่จะเป็นปัญหา

แต่ไอ้การคาดหวังว่าไม่ให้เปลี่ยน ให้คิดมาดีก่อน ผมมองว่ามันเป็นไปไม่ได้ ถ้ามองเขาเป็นมนุษย์เหมือนเรา มีข้อจำกัดเหมือนเราแล้ว ขนาดงานของเราเอง ให้เราเขียนโค้ดโดยไม่ Refactor เลย ไม่มีปุ่ม Backspace ให้ใช้ เรายังไม่มีปัญญาทำเลย

แล้วเราคิดว่างานประเภทอื่นที่ไม่ใช่เขียนโปรแกรมเนี่ย เขาไม่ต้องการปุ่ม Backspace มั่งเหรอ

ผมคิดว่ามันเป็นข้อเรียกร้องที่เกินข้อจำกัดมนุษย์

มันก็มนุษย์เหมือนๆ กันนั่นแหละ ไม่ได้วิเศษวิโสอะไรว่าแบบเป็นผู้บริหารระดับโลก CEO 100 ล้าน แล้วจะไม่เคยคิดอะไรผิดพลาด ไม่เคยต้องใช้ Backspace ไม่จำเป็น มีเป้าแล้วลุยตรงเลยตามแผนที่คิดไว้ทุกอย่างเป๊ะๆ ซักหน่อย

มันก็เกิดขึ้นได้ มันก็มนุษย์เหมือนๆ กัน


ผมคิดว่าข้อเรียกร้องที่สมเหตุสมผลกว่าคือ

  1. เวลาเรา Pair programming กัน อีกคนสามารถเตือนได้ว่าเห้ยทำแบบนี้ไม่เวิร์คฉันใด เราในฐานะ Developer ก็น่าจะเตือน Stakeholder ได้ว่าอย่าทำแบบนี้เลยนะผมว่ามันไปผิดทาง การขอให้สามารถพูดได้ตักเตือนได้ผมคิดว่ามันสมเหตุสมผล
  2. เราสามารถบอกให้เขาเข้าใจได้ว่า Deadline หรือ Budget มันต้องเปลี่ยนนะ เพราะมันเป็นไปไม่ได้ที่จะเปลี่ยนความต้องการ แล้วคงเดิมไว้ แล้วถ้า Negotiation หรือต่อรองกันให้ลงตัวไม่ได้ก็ไม่อยากเปลี่ยน อันนี้ก็เป็นธรรมดา เป็นข้อเรียกร้องที่สมเหตุสมผล
  3. เราสามารถเรียนรู้และเติบโตไปพร้อมกับเขาได้ เหมือนโปรแกรมเมอร์ที่เก่งแล้วไม่ทำโค้ดที่เละตั้งแต่แรกเพราะรู้ดีว่ามันไม่เวิร์คตั้งแต่เริ่มพิมพ์ฉันใด Stakeholder ที่เก่งขึ้นแล้วก็จะไม่พลาดท่าเรื่องง่ายๆ มากขึ้นฉันนั้น ซึ่งตรงนั้นเราเติบโตไปด้วยกันได้
  4. ในงานที่การกด Backspace มันมีค่าใช้จ่ายสูงมาก เราต้องระวังสูง ก็ช่วยๆ กันเตือนช่วยๆ กันคิด และบอกให้เขารู้ว่า การลบตรงนี้ แก้ตรงนี้ มันมี Cost สูงมากเลยนะ ผมต้องเปลี่ยนโครงสร้างภายในนะ ผมอยากให้มั่นใจเพราะต้นทุนตรงนี้ เราก็จ่ายร่วมกัน ผมจ่ายเป็นเวลางาน คุณจ่ายเป็น Budget เราก็ทีมเดียวกัน เจ็บก็เจ็บกันทั้งคู่นั่นแหละ

ซึ่งผมเข้าใจได้นะเวลาที่ไม่อยากเปลี่ยน Requirement เพราะ Budget หรือ Deadline ตายตัว แล้วอยากให้เปลี่ยน คืออันนั้นมันก็เข้าเนื้อเราแหละ

แต่ถ้าเป็นอะไรที่ไม่ตายตัว ผมว่าอยากให้เราเห็นใจเขาใจเรามากขึ้น

ถึงแม้ว่าเราอาจจะหงุดหงิดที่ว่าเราต้องมารื้อโค้ดที่ไม่ได้คาดคิดใหม่หมด มันเหนื่อย มันน่ารำคาญ

มันอาจจะมีเสียงออกมาจากตัวเราว่า ทำไมต้องเปลี่ยน ทำไมไม่คิดมาให้ดี

ผมอยากให้จำไว้ว่า เรารับได้มั้ย ถ้ามีคนมาเรียกร้องว่าโปรแกรมเมอร์มืออาชีพ ต้องไม่ใช้ Backspace ล่ะ

นั่นแหละ ถ้าเรายังทำไม่ได้ ผมว่าข้อเรียกร้องที่ว่า Stakeholder มืออาชีพต้องคิดมาดีแล้วห้ามเปลี่ยนแปลงอะไรเลย

ก็ไม่สมเหตุสมผลในระดับเดียวกันล่ะครับ

ก็มนุษย์เหมือนๆ กันนั่นแหละครับ

Show your support

Clapping shows how much you appreciated Chris’s story.