คำถามที่เราถามในประชุมแรกของทุกโปรเจกต์: เปิดสมุดโน้ตของทีมพัฒนา ว่าทำไมเราไม่เคยเริ่มจากคำว่าอยากได้ฟีเจอร์อะไร

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

คำถามแรก: งานไหนเจ็บที่สุด และเจ็บเป็นเงินเท่าไหร่

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

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

คำถามที่สาม: ถ้าระบบนี้สำเร็จ อีกหกเดือนอะไรจะต่างไป

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

สัญญาณที่เราหัดฟังจนได้ยิน

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

และบางครั้ง คำตอบของเราคือยังไม่ต้องทำ

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