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

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

กติกาเดโมของเรา: ของจริงเท่านั้น และโชว์ของที่ยังไม่สวย

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

จังหวะสองสัปดาห์ไม่ใช่ของฟรีฝั่งลูกค้า มันเรียกร้องสามอย่าง หนึ่ง: คนที่ใช่ต้องอยู่ในห้องเดโม — ไม่ใช่แค่ผู้ประสานงาน แต่คือคนหน้างานที่จะใช้ส่วนที่กำลังโชว์ เพราะคำท้วงของแคชเชียร์ตัวจริงในนาทีที่สิบของเดโม มีค่ากว่ารายงานสรุปยี่สิบหน้า สอง: feedback ต้องกลับมาเร็ว — ภายในสองสามวัน ไม่ใช่สองสัปดาห์ถัดไป เพราะรอบถัดไปสร้างต่อบนของรอบนี้ ความเงียบคือการอนุมัติโดยปริยายที่แพงที่สุดในโปรเจกต์ และสาม: ยอมรับการเห็นของที่ยังไม่เสร็จโดยไม่ตกใจ — ระบบที่กำลังสร้างหน้าตาเหมือนบ้านที่กำลังสร้าง การเห็นโครงก่อนฉาบคือฟีเจอร์ของกระบวนการ ไม่ใช่สัญญาณอันตราย สิ่งที่ลูกค้าได้กลับมาคุ้มกว่าที่จ่ายมาก: ความเสี่ยงที่ถูกหั่นเป็นชิ้นสองสัปดาห์ (เข้าใจผิดกันได้มากสุดสิบวันทำการ ไม่ใช่หนึ่งไตรมาส) อำนาจปรับทิศจริง ๆ ระหว่างทางเมื่อเห็นของจริงแล้วความต้องการคมขึ้น (ซึ่งเกิดเสมอ และเราเขียนวิธีคัดคำขอไว้แล้ว) และระบบที่ทีมของลูกค้ารู้สึกเป็นเจ้าของตั้งแต่ก่อน go-live เพราะเห็นมันโตมากับมือ — เมล็ดพันธุ์เดียวกับที่ทำให้ adoption ง่ายขึ้นตามที่เราเล่าในหลายบทความ

เมื่อไหร่จังหวะนี้ไม่เหมาะ และคำถามที่ควรถามทุกทีม

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