เขียน TOR จ้างพัฒนาซอฟต์แวร์อย่างไร ให้ได้ระบบที่ต้องการโดยงบไม่บานและไม่ถูกผูกขาด

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

เขียนจากกระบวนการจริงและผลลัพธ์ ไม่ใช่รายการฟีเจอร์

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

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

ใช้ TOR อ่านผู้เสนอราคา ไม่ใช่แค่ให้ผู้เสนอราคาอ่าน TOR

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

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

Whale Task อยู่ฝั่งผู้รับพัฒนามากว่า 10 ปี และเคยตอบ TOR มาแล้วทุกแบบ เรารู้ว่าเอกสารแบบไหนนำไปสู่โปรเจกต์ที่จบสวย จึงยินดีช่วยตั้งแต่ก่อนคุณเปิดหาผู้รับงาน ทั้งการรีวิวร่าง TOR ให้ฟรี และการทำ Workflow Audit เพื่อเปลี่ยนกระบวนการจริงหน้างานให้กลายเป็นขอบเขตงานที่เกณฑ์ชัด เสนอราคาเทียบกันได้ และไม่มีคำว่าบานปลายซ่อนอยู่ระหว่างบรรทัด