สัปดาห์แรกหลังระบบขึ้น: สิ่งที่เกิดขึ้นจริงในเจ็ดวันที่เรานั่งเฝ้า และทำไมมันคือสัปดาห์ที่ตัดสินทั้งโปรเจกต์

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

ของที่พังก่อนเสมอ ไม่เคยใช่โค้ด

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

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

ตัวเลขที่เราดูทุกเย็น

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

เส้นที่บอกว่าถึงเวลาถอย

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