รับ requirement จากลูกค้าที่ยังไม่ครบ: เดินงานต่อได้โดยไม่ต้องเดา และไม่ต้องรอ

ข้อความที่ผมได้รับบ่อยที่สุดจากลูกค้าไม่ใช่ requirement ครับ แต่คือสิ่งที่หน้าตาคล้าย requirement

"อยากได้ระบบสะสมแต้มให้ลูกค้าประจำ แบบร้านกาแฟน่ะครับ ลูกค้าซื้อแล้วได้แต้ม เอาแต้มมาแลกของได้ เดือนหน้าจะเปิดสาขาใหม่ อยากให้ทันพอดี ส่งได้ประมาณไหนครับ"

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

ผมเป็นทั้ง developer, PM และ PO ที่ Mulberrysoft ดูแลทีม junior และดูแลลูกค้าหลายเจ้าพร้อมกัน ถ้าให้เลือกคอขวดเดียวของงานผม มันไม่ใช่การเขียนโค้ด ไม่ใช่การรีวิว PR และไม่ใช่ agent ที่ทำงานไม่ตรงใจ แต่คือช่วงเวลาระหว่างที่ requirement เข้ามาไม่ครบ จนถึงวันที่มันครบพอให้ทีมเดินต่อได้อย่างมั่นใจ

ซีรีส์ Critical Thinking นี้เริ่มจากการให้ agent ทำงานแทนโดยไม่ให้มันคิดแทน ต่อด้วยวันที่คำตอบของ agent กลายเป็นความเห็นของเรา หนี้ความเข้าใจที่ไม่ขึ้นบน dashboard เจตนาที่ agent จ่ายแทนไม่ได้ สีเขียวที่ไม่ได้แปลว่าถูก การล็อกสเปกก่อนโค้ดด้วย OpenSpec การให้ agent grill เราจน requirement ชัด PRD ที่ AI เขียนให้แต่ไม่มีใครอ่าน ยุค agent ที่ทุกคนต้องเขียน AC เหมือน PO และล่าสุดคนอ่าน story เดียวกันแต่เข้าใจคนละอย่าง

หลายโพสต์ก่อนหน้าพูดถึงสิ่งที่เกิดหลังจากเรามี requirement แล้ว ทั้งการเขียน AC การล็อกสเปก และการตรวจว่าคนอ่านเข้าใจตรงกัน โพสต์นี้ขอถอยกลับไปก้าวหนึ่งครับ ไปที่จุดก่อนหน้านั้นทั้งหมด คือวันที่ข้อความสามบรรทัดจากลูกค้าเพิ่งเด้งขึ้นมา และเรายังไม่มีอะไรครบสักอย่าง

จุดยืนของโพสต์นี้คือ requirement ที่ไม่ครบไม่ใช่ข้อยกเว้นที่ต้องรอให้หายไป แต่เป็นสภาพปกติของงานที่ต้องจัดการให้เป็น งานของเราไม่ใช่การทำให้ทุกอย่างครบก่อนเริ่ม แต่คือการทำให้ส่วนที่ไม่ครบมองเห็นได้ มีเจ้าของ มีวันที่ต้องได้คำตอบ และไม่ไปขวางส่วนที่ครบแล้ว

สองทางที่ผมเคยเลือก และพังทั้งคู่

ช่วงแรกที่ผมเริ่มรับงานลูกค้าเอง ผมแกว่งอยู่ระหว่างสองขั้วครับ

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

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

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

ไม่ครบ มีหลายแบบ

หลังจากเจอมาหลายโปรเจกต์ ผมพบว่าคำว่า "requirement ยังไม่ครบ" ซ่อนสถานการณ์ที่ต่างกันมาก และแต่ละแบบต้องจัดการคนละวิธี

ลูกค้ายังไม่รู้ว่าตัวเองต้องการอะไร เขารู้ปัญหา แต่ยังไม่มีภาพของทางแก้ "อยากให้ลูกค้ากลับมาซื้อซ้ำ" คือปัญหา "ระบบสะสมแต้ม" คือทางแก้ที่เขาเห็นจากที่อื่น แบบนี้ถามรายละเอียดไปก็ไม่ได้คำตอบ เพราะคำตอบยังไม่มีอยู่ สิ่งที่ช่วยได้คือให้เขาเห็นของบางอย่าง เช่น mockup หรือตัวอย่างสองสามแบบให้เลือก

ลูกค้ารู้ แต่ไม่ได้พูด แบบนี้เจอบ่อยที่สุดครับ เรื่องที่อยู่ในหัวเขาชัดมากจนไม่คิดว่าต้องบอก เช่น "แต้มหมดอายุสิ้นปี" ในหัวฝ่ายบัญชีเป็นเรื่องที่ทุกคนรู้ แต่ในหัวทีม dev ไม่มีอยู่เลย ความรู้แบบนี้ไม่ได้มาจากการถามว่า "มีอะไรเพิ่มเติมไหมครับ" แต่มาจากการถามเจาะจง หรือขอดูของจริงที่เขาใช้อยู่

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

ขึ้นกับคนนอก เช่น ระบบ POS ของสาขาเป็นของอีกบริษัท จะส่งข้อมูลยอดซื้อมาให้แบบไหน ยังไม่รู้จนกว่าจะได้คุยกับเขา หรือเงื่อนไขทางกฎหมายเรื่องข้อมูลส่วนบุคคลที่ต้องรอฝ่ายกฎหมายของลูกค้า เรื่องพวกนี้เร่งไม่ได้ แต่ออกแบบให้ไม่ติดได้

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

พอผมเริ่มแยกแบบนี้ คำถามที่ผมถามตัวเองเปลี่ยนไปครับ จากเดิมที่ถามว่า "ครบหรือยัง" กลายเป็น "ส่วนที่ไม่ครบนี้ ไม่ครบเพราะอะไร" เพราะคำตอบของข้อนั้นบอกว่าผมควรถาม ควรทำ mockup ควรไปหาคนตัดสิน หรือควรออกแบบให้รองรับการเปลี่ยน

เรื่องจากระบบสะสมแต้ม

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

แทนที่จะส่งคำถามยี่สิบข้อ วันแรกผมทำสามอย่าง

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

อย่างที่สอง ผมถามคำถามแค่สามข้อ คือข้อที่ถ้าเดาผิดแล้วแพงที่สุด และแต่ละข้อแนบคำตอบที่ผมแนะนำมาด้วย

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

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

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

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

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

สัปดาห์ถัดมาฝ่ายบัญชีตอบมาว่าแต้มหมดอายุสิ้นปีถัดไปนับจากวันที่ได้รับ ทีมใช้เวลาไม่นานในการเพิ่มส่วนนี้ เพราะเราเตรียมที่ไว้ให้มันตั้งแต่แรก

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

แยกงานเป็นสามกอง

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

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

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

ตัวอย่างจากระบบสะสมแต้ม

• รู้แล้ว สมัครด้วยเบอร์โทร ได้แต้มตามยอดซื้อ แลกเป็นของรางวัลหรือส่วนลดได้ สินค้าลดราคาไม่ได้แต้ม
• สมมติไว้ก่อน อัตราแต้มต่อยอดซื้อ ตั้งเป็นค่าที่แก้ได้จากหลังบ้าน หน้าตาข้อความแจ้งเตือนเมื่อได้แต้ม ภาพของรางวัลในหน้ารายการ
• ห้ามแตะจนกว่าจะรู้ กติกาการหมดอายุ การแยกแต้มระหว่างสาขาบริษัทกับแฟรนไชส์ รูปแบบข้อมูลจาก POS

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

สมมติฐานที่มีเจ้าของ และวันหมดอายุ

กองกลางคือกองที่อันตรายที่สุดครับ ไม่ใช่เพราะมันเสี่ยง แต่เพราะมันเงียบ

สมมติฐานที่ไม่ถูกจด จะค่อย ๆ กลายเป็นข้อเท็จจริงโดยไม่มีใครตั้งใจ วันจันทร์ developer ตั้งอัตราแต้มเป็นค่าที่คิดเอาเองเพื่อให้เทสได้ วันพุธ QA เขียน test case ตามค่านั้น วันศุกร์ค่านั้นไปโผล่ในเอกสารคู่มือ สองสัปดาห์ต่อมามันอยู่บนหน้าจอที่ลูกค้าเห็นตอน demo แล้วลูกค้าก็ถามว่า "ตัวเลขนี้มาจากไหนครับ" และไม่มีใครในทีมตอบได้

ตอนนี้ทุกสมมติฐานในโปรเจกต์ผม ต้องมีห้าอย่าง

## สมมติฐาน: อัตราแต้มต่อยอดซื้อ

- สิ่งที่สมมติ: ยอดซื้อทุก 25 บาท ได้ 1 แต้ม ปัดเศษลง
- ทำไมถึงสมมติแบบนี้: ใกล้เคียงกับบัตรสะสมแสตมป์เดิมของลูกค้า
- ถ้าผิด กระทบอะไร: แก้ค่าในหลังบ้าน ไม่ต้องแก้โค้ด
  แต่ถ้ามีลูกค้าจริงสะสมไปแล้ว ต้องตัดสินว่าจะคำนวณย้อนหลังไหม
- ใครยืนยันได้: ผู้จัดการฝ่ายการตลาดของลูกค้า
- ต้องได้คำตอบก่อน: วันที่เปิดให้ทดสอบกับพนักงานสาขา
- เจ้าของเรื่อง: Earth
- สถานะ: รอยืนยัน

สองบรรทัดที่สำคัญที่สุดคือ "ต้องได้คำตอบก่อน" กับ "เจ้าของเรื่อง" ครับ อย่างที่ผมเขียนไว้ในโพสต์ Grill Me ว่าสมมติฐานที่มีชื่อคนกำกับจะถูกตามต่อ ส่วนสมมติฐานที่ไม่มีจะกลายเป็นข้อเท็จจริงในสามวัน โพสต์นี้ผมขอเพิ่มอีกข้อ คือ สมมติฐานที่ไม่มีวันหมดอายุ จะไม่มีวันถูกยืนยัน เพราะไม่มีจังหวะไหนที่บังคับให้ใครต้องถาม

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

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

ถามลูกค้ายังไงให้ได้คำตอบ

ผมเคยคิดว่าปัญหาของการได้ requirement ไม่ครบคือลูกค้าไม่ให้ความร่วมมือ ตอนนี้ผมคิดว่าครึ่งหนึ่งของปัญหาคือวิธีถามของผมเองครับ คำถามหลายข้อที่ผมเคยส่งไป ถ้าผมเป็นลูกค้าก็คงไม่ตอบเหมือนกัน

สิ่งที่ผมเปลี่ยน

ถามน้อยข้อ เรียงตามราคาของการเดาผิด ลิสต์คำถามยี่สิบข้อส่งสัญญาณว่า "เรายังไม่ได้คิดอะไรเลย ช่วยคิดให้หน่อย" และลูกค้าจะตอบแค่ข้อที่ง่าย ผมเลยส่งครั้งละไม่เกินสามถึงห้าข้อ เป็นข้อที่อยู่ในกอง "ห้ามแตะจนกว่าจะรู้" ก่อนเสมอ ส่วนข้อในกองกลาง ผมใส่เป็นสมมติฐานให้ลูกค้าดูทีหลัง

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

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

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

ให้ดูก่อนถาม เมื่อลูกค้ายังไม่มีภาพ สำหรับเรื่องที่ลูกค้ายังไม่รู้ว่าต้องการอะไร ผมเลิกถามแล้วครับ แต่ทำ mockup หยาบ ๆ สองแบบให้เลือก หรือเปิดตัวอย่างจากแอปอื่นให้ดูแล้วถามว่า "ใกล้กับแบบไหนมากกว่ากัน" คนตอบคำถาม "แบบ A หรือแบบ B" ได้เร็วกว่าคำถาม "อยากได้แบบไหน" เสมอ

ระบุว่าต้องการคำตอบจากใคร และภายในเมื่อไหร่ "ข้อนี้น่าจะต้องให้ฝ่ายบัญชีตัดสินนะครับ ถ้าได้คำตอบภายในวันศุกร์ ทีมจะทำส่วนนี้ทันรอบ demo" ประโยคแบบนี้ช่วยคนที่คุยกับเรามากครับ เพราะเขาเอาไปส่งต่อในองค์กรได้ทันที และมีเหตุผลไปเร่งคนอื่นให้

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

ออกแบบให้เปลี่ยนใจได้ในราคาถูก

ส่วนนี้คือฝั่ง developer ครับ เพราะการจัดการ requirement ที่ไม่ครบไม่ได้อยู่แค่ในเอกสารกับการคุยกับลูกค้า มันอยู่ในโค้ดด้วย

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

ในทางปฏิบัติมันหน้าตาประมาณนี้

• ค่าที่ยังไม่ยืนยัน เช่น อัตราแต้ม ยอดซื้อขั้นต่ำ ให้อยู่ในการตั้งค่า ไม่ใช่ตัวเลขฝังในโค้ด
• เรื่องที่รู้ว่าจะมีกติกาแต่ยังไม่รู้กติกา เช่น การหมดอายุ ให้เก็บข้อมูลที่ละเอียดพอจะรองรับหลายกติกาไว้ก่อน อย่างการเก็บแต้มเป็นรายการพร้อมวันที่ได้รับ แทนการเก็บยอดรวม
• การเชื่อมกับระบบภายนอกที่ยังไม่รู้รูปแบบ ให้ซ่อนไว้หลังจุดเชื่อมจุดเดียว แล้วทำทางชั่วคราวไว้ก่อน เช่น ให้พนักงานกรอกเอง เมื่อรู้รูปแบบจริงก็เปลี่ยนแค่ตรงนั้น
• ฟีเจอร์ที่ยังไม่แน่ใจว่าลูกค้าจะเอาไหม ซ่อนไว้หลัง feature flag เพื่อให้ demo ได้โดยไม่ต้องเปิดใช้จริง

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

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

เอกสารหน้าเดียวที่ผมเก็บไว้ทุกโปรเจกต์

ผมไม่ได้เขียน PRD ยาว ๆ ให้ทุกโปรเจกต์ครับ ด้วยเหตุผลเดียวกับที่เขียนไว้ในโพสต์ PRD ที่ไม่มีใครอ่าน แต่มีเอกสารหนึ่งหน้าที่ผมเก็บไว้ทุกโปรเจกต์ที่ requirement มาไม่ครบ และอัปเดตทุกครั้งที่มีอะไรเปลี่ยน

# ระบบสะสมแต้ม: สถานะ requirement

อัปเดตล่าสุด: (วันที่)

## เป้าหมาย
ให้ลูกค้าประจำกลับมาซื้อซ้ำ ใช้ได้ทันวันเปิดสาขาใหม่

## รู้แล้ว (ยืนยันโดย / ที่มา)
- สมัครด้วยเบอร์โทร (คุยกับลูกค้า, สรุปส่งทางอีเมลแล้ว)
- สินค้าลดราคาไม่ได้แต้ม (เงื่อนไขหลังบัตรสะสมเดิม)
- แลกเป็นของรางวัลหรือส่วนลดได้ (ลูกค้าเพิ่มเติมหลังอ่านสรุป)

## สมมติไว้ก่อน (ดูรายละเอียดในรายการสมมติฐาน)
- อัตราแต้มต่อยอดซื้อ: รอยืนยันก่อนเปิดทดสอบกับพนักงาน
- ข้อความแจ้งเตือนเมื่อได้แต้ม: รอยืนยันตอน demo

## ห้ามแตะจนกว่าจะรู้
- กติกาหมดอายุ: รอฝ่ายบัญชี ต้องได้ก่อน (วันที่) ไม่งั้นเลื่อนส่วนนี้ไปเฟสสอง
- แยกแต้มแฟรนไชส์: รอผู้บริหารลูกค้าตัดสิน
- ข้อมูลจาก POS: รอคุยกับผู้ให้บริการ POS
  แผนสำรอง: พนักงานกรอกยอดเองสำหรับสาขาแรก

## นอกขอบเขตรอบนี้
- แอปมือถือแยก (ใช้ผ่านเว็บก่อน)
- แต้มจากการซื้อออนไลน์

## การตัดสินใจที่เปลี่ยนไปแล้ว
- (วันที่) เพิ่มการแลกเป็นส่วนลด เดิมมีแค่ของรางวัล

หัวข้อที่คนมักข้ามแต่ผมคิดว่าสำคัญมากคือ "นอกขอบเขตรอบนี้" กับ "การตัดสินใจที่เปลี่ยนไปแล้ว" ครับ ข้อแรกกันไม่ให้ requirement งอกโดยไม่มีใครสังเกต ข้อหลังช่วยในวันที่ลูกค้าถามว่า "ทำไมตอนนี้เป็นแบบนี้" แล้วเราเปิดให้ดูได้ว่าเปลี่ยนเมื่อไหร่ เพราะอะไร ใครเป็นคนบอก

เอกสารนี้ผมส่งให้ลูกค้าดูได้ ทีมอ่านได้ และ agent ก็อ่านได้ ซึ่งข้อสุดท้ายสำคัญขึ้นเรื่อย ๆ ครับ

agent ช่วยตรงไหน และไม่ควรให้ช่วยตรงไหน

ผมใช้ agent กับงานช่วงนี้ทุกวัน แต่ใช้แบบระวังกว่าช่วงอื่นของงานมาก เพราะช่วง requirement ไม่ครบคือช่วงที่ agent อันตรายที่สุด

agent เก่งมากในการทำให้ของที่ไม่ครบดูครบครับ ถ้าผมวางข้อความสามบรรทัดของลูกค้าแล้วสั่งว่า "เขียน spec ระบบสะสมแต้มให้หน่อย" ผมจะได้เอกสารที่สวยงาม มีกติกาหมดอายุ มีระดับสมาชิก มีอัตราแต้ม ครบทุกหัวข้อ และทุกข้อในนั้นคือการเดาที่ถูกเขียนด้วยน้ำเสียงมั่นใจ อย่างที่ผมเขียนในโพสต์ Intent Debt ว่าช่องว่างจะถูกเติมเสมอ คำถามคือใครเติม และถ้าผมส่งเอกสารนั้นต่อให้ทีมหรือให้ลูกค้าดู การเดาของ agent ก็จะกลายเป็น "requirement" ทันที

ดังนั้นสิ่งที่ผมให้ agent ทำในช่วงนี้ คือหาช่องว่าง ไม่ใช่เติมช่องว่าง

อ่านข้อความจากลูกค้าและบันทึกการคุยด้านล่าง ยังไม่ต้องเขียน spec

1. แยกเป็นสามกลุ่ม
   - สิ่งที่ลูกค้าบอกชัดแล้ว (อ้างประโยคต้นทาง)
   - สิ่งที่ต้องมีคำตอบก่อนทำงานได้ แต่ยังไม่มีใครพูดถึง
   - สิ่งที่ลูกค้าพูดแต่ตีความได้มากกว่าหนึ่งแบบ
2. สำหรับกลุ่มที่สองและสาม ประเมินว่าถ้าเดาผิดต้องแก้มากแค่ไหน
   และเรียงจากแพงไปถูก
3. ร่างคำถามถึงลูกค้าไม่เกิน 5 ข้อ จากรายการที่แพงที่สุด
   แต่ละข้อมีคำตอบที่แนะนำพร้อมเหตุผลหนึ่งประโยค
   เขียนเป็นภาษาที่คนไม่ใช่สายเทคนิคอ่านเข้าใจ
4. ห้ามเติมคำตอบแทนลูกค้า ถ้าข้อไหนต้องสมมติ ให้ระบุว่าเป็นสมมติฐาน

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

สิ่งที่ agent ช่วยได้ดีอีกอย่างคือการไล่ดูว่าบันทึกการคุยรอบใหม่ขัดกับเอกสารสถานะ requirement ตรงไหนบ้าง ลูกค้าที่คุยกันหลายรอบมักพูดสิ่งที่ขัดกับที่เคยพูดไว้โดยไม่รู้ตัว และงานไล่เทียบแบบนี้คนทำแล้วพลาดง่าย แต่ agent ทำได้ละเอียดและไม่เบื่อ

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

Checklist ที่ผมใช้ทุกครั้งที่ requirement มาไม่ครบ

ผมรวบรวมทั้งหมดข้างบนเป็นรายการที่เปิดดูได้ทุกครั้งครับ ไม่จำเป็นต้องทำครบทุกข้อในงานเล็ก แต่ทุกข้อที่ข้าม ผมอยากให้เป็นการข้ามที่ตั้งใจ

วันแรกที่ได้รับ requirement

• เขียนสิ่งที่เข้าใจกลับไปหาลูกค้า เป็นภาษาของลูกค้า ไม่เกินครึ่งหน้า แล้วขอให้ยืนยัน
• ระบุเป้าหมายทางธุรกิจให้ได้หนึ่งประโยค ว่าระบบนี้มีไว้ "เพื่ออะไร"
• ถามว่าใครเป็นคนตัดสินเรื่องธุรกิจ และใครเป็นคนใช้งานจริง ถ้าไม่ใช่คนเดียวกับที่คุยอยู่
• ขอของจริงอย่างน้อยหนึ่งชิ้น เช่น ไฟล์ เอกสาร ภาพหน้าจอระบบเดิม หรือกระบวนการที่ทำด้วยมืออยู่
• ถามถึงระบบหรือคนนอกที่ต้องเกี่ยวข้อง เช่น POS ระบบบัญชี payment ฝ่ายกฎหมาย

ก่อนให้ทีมเริ่มงาน

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

ระหว่างทำงาน

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

ก่อนส่งงานหรือ demo

• แนบรายการสมมติฐานที่ยังเปิดอยู่ไปพร้อมงานทุกครั้ง
• ชี้ให้ลูกค้าเห็นบนหน้าจอจริงว่าส่วนไหนเป็นสมมติฐาน แล้วขอคำยืนยันตรงนั้น
• ตรวจว่าไม่มีสมมติฐานไหนหลุดไปเป็นข้อมูลจริงที่ย้อนคืนยาก โดยที่ยังไม่มีใครยืนยัน
• ถ้ามีเรื่องในกอง "ห้ามแตะ" ที่ยังไม่ได้คำตอบ บอกชัดว่าส่วนไหนจะเลื่อน และเลื่อนเพราะรออะไร

เมื่อใช้ agent ในช่วงนี้

• ให้ agent หาช่องว่างและร่างคำถาม ไม่ใช่เติมช่องว่างหรือเขียน spec จากข้อความดิบ
• อ่านคำถามที่ agent ร่างทุกข้อ ตัดข้อที่รู้คำตอบจากบริบทที่ agent ไม่มี และเรียบเรียงใหม่เป็นน้ำเสียงของเรา
• ให้ agent อ้างอิงเอกสารสถานะ requirement เสมอ และห้ามมันเปลี่ยนสมมติฐานเป็นข้อเท็จจริงเอง

ท้ายที่สุด

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

สิ่งที่เปลี่ยนไปในงานผมไม่ใช่ลูกค้าครับ ลูกค้ายังส่งข้อความสามบรรทัดมาเหมือนเดิม สิ่งที่เปลี่ยนคือผมเลิกมองข้อความนั้นเป็น requirement ที่ไม่ครบ แล้วเริ่มมองมันเป็นจุดเริ่มต้นของบทสนทนาที่ผมต้องเป็นคนพาเดิน

การรอให้ครบทำให้ทีมว่าง การเดาให้ครบทำให้ทีมต้องรื้อ ทางที่ผมเลือกตอนนี้คือทำสิ่งที่รู้ จดสิ่งที่สมมติ เว้นที่ให้สิ่งที่ยังไม่รู้ แล้วทำให้ทุกคน รวมทั้งลูกค้า เห็นว่าแต่ละกองมีอะไรอยู่บ้าง

ในยุคที่ agent เขียนโค้ดได้เร็วกว่าที่ลูกค้าตอบข้อความทัน เรื่องนี้ยิ่งสำคัญครับ เพราะความเร็วของการสร้างไม่ได้ช่วยอะไรเลย ถ้าสิ่งที่สร้างตั้งอยู่บนการเดาที่ไม่มีใครรู้ว่าเป็นการเดา

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

แล้วค่อยถามลูกค้าแค่ข้อสุดท้ายนั้นครับ