แทบไม่มีโครงการใดล้มเหลวเพราะการเปลี่ยนแปลงครั้งใหญ่เพียงครั้งเดียว แต่ล้มเหลวเพราะการเปลี่ยนแปลงเล็ก ๆ สามสิบครั้ง ซึ่งแต่ละครั้งดูสมเหตุสมผลเมื่อพิจารณาแยกกัน แต่ไม่มีครั้งใดถูกประเมินราคาไว้
การชี้แจงหรือการเปลี่ยนแปลง
ความแตกต่างนี้มีความสำคัญ และโดยปกติสามารถตัดสินได้
การชี้แจง คือการคลี่คลายความกำกวมในสิ่งที่ตกลงกันไว้แล้ว สเปกระบุว่าผู้ใช้สามารถรีเซ็ตรหัสผ่านได้ ลูกค้ายืนยันว่าลิงก์รีเซ็ตควรหมดอายุหลังจากหนึ่งชั่วโมง สิ่งนี้เป็นสิ่งที่จะต้องพัฒนาอยู่แล้ว เพียงแต่มีการตัดสินรายละเอียดให้ชัดเจน
การเปลี่ยนแปลง คือการเพิ่ม ลบ หรือแก้ไขขอบเขตงานที่ตกลงกันไว้ สเปกระบุว่าผู้ใช้รีเซ็ตรหัสผ่านผ่านอีเมล แต่ตอนนี้ลูกค้าต้องการให้รองรับ SMS ด้วย นี่คืองานใหม่
พื้นที่สีเทาเกิดขึ้นเมื่อสเปกไม่ได้ระบุไว้ หากสเปกไม่ได้บอกว่าลิงก์ใช้ได้นานเท่าใด ก็ต้องมีผู้ตัดสินใจ และการตัดสินใจนั้นคือการชี้แจง หากสเปกไม่ได้กล่าวถึง SMS เลย การเพิ่ม SMS คือการเปลี่ยนแปลง กฎที่มีประโยชน์คือ หากนักพัฒนาที่มีเหตุผลอ่านสเปกแล้วจะพัฒนาสิ่งนั้นอยู่ดี นั่นคือการชี้แจง
เหตุใดการเปลี่ยนแปลงเล็ก ๆ จึงมีต้นทุนสูงกว่าขนาดของมัน
การเปลี่ยนแปลงที่ใช้เวลาเขียนโค้ดสองชั่วโมงแทบไม่เคยมีต้นทุนเพียงสองชั่วโมง เพราะยังมีสิ่งต่อไปนี้รวมอยู่ด้วย:
- การหารือและการจัดทำรายละเอียดของการเปลี่ยนแปลงนั้น
- ผลกระทบต่อสิ่งที่พัฒนาไปแล้ว — ฟิลด์ใหม่ปรากฏในฟอร์ม การตรวจสอบความถูกต้อง ฐานข้อมูล รายงาน และการส่งออกข้อมูล
- การทดสอบซ้ำทุกส่วนที่ได้รับผลกระทบจากการเปลี่ยนแปลง
- การปรับปรุงเอกสารและงานออกแบบที่ได้รับอนุมัติแล้ว
- ต้นทุนจากการหยุดชะงัก ซึ่งมีอยู่จริงและมักไม่ได้ถูกประเมินราคา
นี่คือเหตุผลที่การเปลี่ยนแปลงซึ่งร้องขอระหว่างการออกแบบมีต้นทุนเพียงเศษส่วนของการเปลี่ยนแปลงเดียวกันที่ร้องขอหลังการทดสอบการยอมรับ ตัวคูณระหว่างสองจุดนี้มีค่าสูง — โดยทั่วไปมักอ้างกันว่าอยู่ในระดับหนึ่งลำดับขั้นของขนาด และไม่มีข้อโต้แย้งเกี่ยวกับทิศทางดังกล่าว แม้ตัวเลขที่แน่นอนจะแตกต่างกัน
การอธิบายเรื่องนี้ให้ลูกค้าเข้าใจตั้งแต่เนิ่น ๆ ทำให้การพูดคุยในภายหลังง่ายขึ้นมาก เพราะลูกค้าเข้าใจว่าการถูกขอให้คิดอย่างรอบคอบในขั้นตอนการออกแบบมีเหตุผลรองรับ
กระบวนการจัดการการเปลี่ยนแปลงที่เรียบง่ายพอให้ใช้งานได้จริง
สำหรับโครงการขนาดเล็ก มีสี่ขั้นตอน:
- บันทึกคำขอไว้เป็นลายลักษณ์อักษร หนึ่งย่อหน้าในสถานที่เดียวที่ทั้งสองฝ่ายมองเห็น การเปลี่ยนแปลงด้วยวาจาเป็นต้นเหตุของข้อพิพาทส่วนใหญ่
- นักพัฒนาประเมินคำขอ — ทั้งแรงงาน ต้นทุน และผลกระทบต่อวันส่งมอบ ผลกระทบต่อวันส่งมอบมีความสำคัญพอ ๆ กับต้นทุน และมักถูกลืม
- ลูกค้าอนุมัติหรือปฏิเสธเป็นลายลักษณ์อักษร การปฏิเสธเป็นผลลัพธ์ที่ชอบด้วยเหตุผลและควรทำได้โดยไม่ยุ่งยาก
- เพิ่มการเปลี่ยนแปลงที่อนุมัติแล้วลงในกำหนดการและใบแจ้งหนี้ และเลื่อนวันส่งมอบอย่างเป็นทางการหากมีการเลื่อน
ขั้นตอนที่มักถูกข้ามมากที่สุดคือขั้นตอนที่สาม และการข้ามขั้นตอนนี้เองที่ทำให้เกิดข้อโต้แย้งในตอนท้าย นั่นคือมีการทำงานที่ไม่มีใครตกลงอย่างเป็นทางการว่าจะชำระเงิน
การจัดการการเปลี่ยนแปลงเล็ก ๆ
การดำเนินการตามคำขอเปลี่ยนแปลงอย่างเป็นทางการสำหรับการปรับแก้ที่ใช้เวลาสิบห้านาทีมีต้นทุนด้านกระบวนการสูงกว่างานจริง และทำให้โครงการมีบรรยากาศเหมือนเป็นฝ่ายตรงข้าม แนวทางที่ใช้งานได้จริงมีสองแบบ:
โควตาการเปลี่ยนแปลง รวมจำนวนชั่วโมงที่ระบุไว้ในสัญญาสำหรับการปรับแก้เล็ก ๆ โดยติดตามและรายงานการใช้ เมื่อใช้ครบแล้ว การเปลี่ยนแปลงเพิ่มเติมจะต้องจัดทำใบเสนอราคา แนวทางนี้โปร่งใสและลดความติดขัดจากคำขอที่เล็กน้อยอย่างแท้จริง
การรวบรวมคำขอ รวบรวมการเปลี่ยนแปลงเล็ก ๆ แล้วจัดทำใบเสนอราคารวมกันในจุดเวลาที่กำหนด การหยุดชะงักลดลง และลูกค้าจะเห็นต้นทุนสะสม ซึ่งมักเป็นสิ่งที่ทำให้ลูกค้าจัดลำดับความสำคัญ
การเปลี่ยนแปลงที่ลูกค้าควรทักท้วง
ไม่ใช่ทุกคำขอเปลี่ยนแปลงจะมาจากลูกค้า หากนักพัฒนาเสนอการเปลี่ยนแปลงเพราะบางสิ่งในสเปกที่ตกลงกันไว้กลับทำได้ยากกว่าที่คาดการณ์ไว้ โดยทั่วไปนั่นไม่ใช่การเปลี่ยนแปลง แต่เป็นข้อผิดพลาดในการประเมิน และโดยปกติความเสี่ยงด้านการประเมินจะตกอยู่กับผู้จัดทำการประเมิน
ข้อยกเว้นคือกรณีที่สเปกกำกวมอย่างแท้จริง และการตีความของลูกค้ามีต้นทุนสูงกว่า นั่นคือการเปลี่ยนแปลงที่แท้จริง และเป็นเหตุผลที่ความพยายามในการจัดทำสเปกตั้งแต่ต้นช่วยชดเชยต้นทุนของตัวเอง
การเก็บบันทึก
มีรายการเดียวที่ทั้งสองฝ่ายมองเห็น โดยบันทึกการเปลี่ยนแปลงทุกครั้งพร้อมสถานะ ต้นทุน และผลกระทบต่อวันส่งมอบ เมื่อโครงการสิ้นสุด รายการดังกล่าวจะอธิบายได้อย่างชัดเจนว่าเหตุใดใบแจ้งหนี้สุดท้ายจึงแตกต่างจากใบเสนอราคาเดิม และโครงการที่อธิบายความแตกต่างได้อย่างชัดเจนมักไม่จบลงด้วยข้อพิพาท
บริการ Manboo ที่เกี่ยวข้อง
- การพัฒนาแอป Flutter สำหรับ MVP บน iOS และ Android
- การพัฒนาซอฟต์แวร์ธุรกิจ สำหรับระบบ CRM การจอง สินค้าคงคลัง และเวิร์กโฟลว์
- การพัฒนาแผงผู้ดูแลระบบ สำหรับแดชบอร์ดการปฏิบัติงานและการจัดการแบ็กเอนด์
- การผสานรวม AI API เมื่อผลิตภัณฑ์ของคุณพร้อมสำหรับการค้นหาอัจฉริยะ แชต หรือระบบอัตโนมัติ
- ขอให้ตรวจสอบขอบเขตงานและประเมินราคาโครงการ เมื่อคุณพร้อมวางแผนเวอร์ชันแรก