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

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

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

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

กล่องส่งมอบหกชิ้นของเรา

  • หนึ่ง — โค้ดพร้อมสิทธิ์เจ้าของเต็ม: repository ที่บัญชีของลูกค้าเป็น owner ไม่ใช่แค่ได้สิทธิ์อ่าน พร้อมประวัติการแก้ทั้งหมด สัญญาของเราเขียนชัดว่าโค้ดที่จ้างทำเป็นของผู้จ้าง — ประโยคเดียวที่เราแนะนำให้ทุกคนหาให้เจอในทุกสัญญาก่อนเซ็น
  • สอง — เอกสารที่เขียนให้ทีมถัดไป ไม่ใช่ให้ตัวเอง: แผนผังภาพรวมหนึ่งหน้า ระบบต่อกับอะไรบ้าง ข้อมูลสำคัญอยู่ตรงไหน การตัดสินใจใหญ่ ๆ ทำไมถึงเลือกทางนี้ และวิธี setup เครื่องใหม่จากศูนย์ — เกณฑ์วัดของเราคือ นักพัฒนาที่ไม่เคยเห็นงานนี้ ต้องอ่านแล้วเริ่มงานได้ในหนึ่งวัน
  • สาม — รหัสและบัญชีที่เป็นของลูกค้าตั้งแต่วันแรก: โดเมน โฮสติ้ง ฐานข้อมูล บัญชีอีเมลระบบ และบริการเสริมทุกตัว จดทะเบียนใต้บัญชีของลูกค้าตั้งแต่ต้น เราเป็นแค่ผู้ได้รับเชิญที่ถอดออกได้ — ไม่ใช่ส่งมอบวันสุดท้าย เพราะของที่เริ่มผิดชื่อ ย้ายทีหลังเจ็บเสมอ
  • สี่ — คู่มือใช้งานเป็นภาษาคนทำงาน พร้อมวิดีโอสั้น: งานประจำแต่ละอย่างทำยังไง มีคลิปหน้าจอสั้น ๆ ประกบ เพราะพนักงานใหม่ในอีกสองปีจะเรียนจากสิ่งนี้ ไม่ใช่จากคนที่ลาออกไปแล้ว
  • ห้า — super user ที่เราตั้งใจปั้นระหว่างทาง: คนของลูกค้าอย่างน้อยสองคน (บทเรียนจากเคสแชมป์เปี้ยนลาออกที่เราเคยเล่า) ที่ตอบคำถามในบ้านได้เองแปดสิบเปอร์เซ็นต์
  • หก — บันทึกสุขภาพระบบ: อะไรต้องต่ออายุเมื่อไหร่ (โดเมน ใบรับรอง บริการรายปี) อะไรควรอัปเดตทุกไตรมาส และสัญญาณอะไรที่แปลว่าควรโทรหาช่าง — หน้าเดียวที่กันเหตุการณ์เว็บล่มเพราะลืมต่อโดเมนได้ตลอดชีวิตของระบบ

ทำไมการไม่ล็อกถึงเป็นธุรกิจที่ดีกว่า

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

ส่งมอบโปรเจกต์Ownershipจากทีมพัฒนาจ้างทำระบบ

บริการที่เกี่ยวข้อง

รับพัฒนาระบบและซอฟต์แวร์เฉพาะทาง

ออกแบบและวางระบบตามความต้องการเฉพาะของธุรกิจคุณ ตั้งแต่ต้นจนใช้งานจริง

WhaleScope

ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope

รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล

อ่านต่อ

เราอยากสอบตกตอน UAT: วิธีที่เราจัดการทดสอบรับมอบกับลูกค้า ให้เจอปัญหาตอนที่มันยังถูก

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

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

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

เราตีราคาโปรเจกต์ซอฟต์แวร์ยังไงจริง ๆ: เปิดหลังบ้านวิธีประเมิน ที่จะทำให้คุณอ่านทุกใบเสนอราคาเก่งขึ้น

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

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

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