Sprint failed เพราะงานแทรก(ad hoc) ทำยังไงดี
สปรินท์ที่ถูกงานแทรกเรื่อยๆ จนงานในสปรินท์ไม่เสร็จ จะแก้ไขอย่างไร
จากการนำสกรัม(Scrum) มาปฏิบัติจริงในช่วงแรกสามารถดำเนินไปได้อย่างราบรื่น แต่ต่อมาเมื่อมีการพัฒนาโปรเจ็คใหม่เพิ่มและต้องดูแลโปรเจ็คปัจจุบันไปด้วย ทำให้ทีมที่กำลังพัฒนาโปรเจ็คใหม่ถูกงานของโปรเจ็คปัจจุบันแทรกเข้ามาระหว่างสปรินท์ การขึ้นโปรเจ็คใหม่จึงเกิดความล่าช้าและโปรเจ็คปัจจุบันก็ดูแลได้ไม่ดี บทความนี้จะเล่าถึงสถานการณ์ที่ทีมพบและอธิบายแนวทางที่ทีมใช้จัดการปัญหานี้
ก่อนเข้าสู่เนื้อหา หากยังไม่เข้าใจว่าสกรัมคืออะไร สามารถเข้าไปอ่านเพิ่มเติมได้ที่
Requirement flow
ปกติแล้วการทำงานของทีมพัฒนา(Developer) จะได้รับความต้องการ(requirement) จาก PM(project manager) และนำมาเข้าสปรินท์ โดยที่ PM จะเป็นคนรับความต้องการของฝ่ายต่างๆ และนำมาประเมินว่าควรพัฒนาหรือไม่พัฒนาอะไรบ้าง จากนั้นจึงนำเข้าสู่การวางแผนงานในสปรินท์ และทีมพัฒนาจะพัฒนาผลิตภัณฑ์ตามงานที่ถูกวางแผนไว้ในสปรินท์นั้น
จากรูปจะเห็นได่ว่า PM ต้องรับความต้องการของฝ่ายธุรกิจทีมต่างๆ และทีมช่วยเหลือผู้ใช้งานหรือ CS(Customer Support) โดยทีม CS จะต่างจากทีมอื่นคือบางครั้งต้องติดต่อกับทีมพัฒนาโดยตรงเพื่อแก้ให้ปัญหาเฉพาะบางอย่างให้กับผู้ใช้งานในทันที
สถานการณ์ที่เกิดขึ้นคือเมื่อบริษัทคาดการณ์ว่ามีแนวโน้มจะทำยอดไม่ได้ตามเป้าหมายที่วางไว้ ทีมธุรกิจแต่ละทีมก็จะระดมความคิดกันและหาทางแก้ไขสถานการณ์เพื่อให้บริษัทกลับมาบรรลุเป้าหมาย จึงมีการแทรกงานที่คิดได้เข้ามาในระหว่างสปรินท์ ทำให้งานที่ทีมพัฒนาวางแผนไว้ตอนเริ่มสปรินท์ถูกงานใหม่แทรก(ad hoc) เข้ามามาก งานในสปรินท์ที่ถูกใส่ไว้ในตอนแรกจึงมีบางส่วนที่เสร็จไม่ทันตอนจบสปรินท์
หลังจากทีมพัฒนาทำ Sprint Retrospective จึงมีการ Feedback กลับไปเพื่อให้ PM ทราบว่าโปรเจ็คใหม่อาจไม่สามารถขึ้นได้ทันกำหนดการเดิม หากยังโดนงานแทรกเข้ามาแบบนี้อยู่เรื่อยๆ
ทีมพัฒนาจึงเสนอแนวทางว่าควรแจ้งให้ทีมอื่นทราบว่าความตจ้องการที่คิดขึ้นมาอาจไม่สามารถพัฒนาในทันทีได้ ไม่ควรมีงานชนิดที่แจ้งความต้องการวันนี้แล้วเอาวันพรุ่งนี้ งานทั้งหมดควรจะถูก PM จัดลำดับความสำคัญ(Prioritize) และนำเข้าคิวเพื่อเอาเข้าสู่สปรินท์ตามปกติ โดย
- PM จะทำการประเมิน Business Impact Point ของงานชิ้นนั้น และกำหนดว่าผลิตภัณฑ์ของเราควรตอบสนองความต้องการนั้นได้หรือไม่ หากผลิตภัณฑ์ของเราควรทำได้ก็จะมีการนำมาจัดเรียงความสำคัญแล้วใส่ใน Product Backlog เพื่อเตรียมนำเข้าสู่สปรินท์ในลำดับต่อไป
- หากไม่ควรมีในผลิตภัณฑ์ก็จะลบความต้องการนั้นทิ้ง ไม่นำมาใส่ใน Product Backlog และแจ้งให้เจ้าของความต้องการนั้นทราบว่า “เราจะไม่พัฒนา” เพราะอะไร ซึ่งหากความต้องการนั้นจำเป็นจริงๆ ทีมต้นคิดก็สามารถเสนอความต้องการมาที่ PM ได้อีกครั้ง
- ทีมต่างๆต้องเข้าใจว่าความต้องการที่ร้องขอมาอาจไม่ถูกพัฒนาทันที แต่ต้องรอ 1–2 สปรินท์ ตามความสำคัญที่ PM จัดลำดับไว้ ดังนั้นแต่ละทีมจำเป็นต้องวางแผนล่วงหน้าว่าต้องการอะไรเพื่อจะทำอะไรต่อไป
- สำหรับทีม CS จะต้องมีการกำหนดขอบเขตการดำเนินการแก่ผู้ใช้งาน(Customer Support Policy)ให้ชัดเจนมากขึ้น ว่าอะไรที่สามารถทำได้หรือทำไม่ได้ เพราะบางเรื่องที่ลูกค้าร้องขอเข้ามาก็ไม่จำเป็นต้องทำ เช่น การเปลี่ยนคะแนนรีวิว
การวางแผนล่วงหน้า (Forward Planning)
การวางแผนต้องดูเป้าหมายล่วงหน้าเพื่อวางแผนออกมาว่าควรทำอะไรบ้าง รวมถึงการคิดแผนสำรองเผื่อในกรณีที่ไม่ถึงเป้าหมายว่าจะดำเนินการอะไรเพิ่มเติมบ้าง เพื่อเป็นการเตรียมรับมือล่วงหน้า และเพื่อให้ทีมพัฒนารู้ล่วงหน้าว่าควรเผื่ออะไรไว้เท่าไร
อย่างพวกแคมเปญหรือโปรโมชันบางอย่างสามารถพัฒนาเตรียมพร้อมและทดสอบไว้ล่วงหน้าได้ เพื่อให้สามารถพร้อมใช้งานได้ทันที ไม่จำเป็นต้องแทรกงานเข้ามาระหว่างสปรินท์เมื่อเกิดเหตุการณ์ท่ียอดจะไม่ถึงเป้าหมาย หรือในกรณีที่ทำยอดได้ตามเป้าหมายอยู่แล้ว เราก็สามารถเลือกได้ว่าจะใช้เพื่อเพิ่มยอดให้มากขึ้นไปอีกหรือเก็บเอาไว้ใช้ในอนาคตก็ได้
ซึ่งในระยะยาวควรพัฒนาระบบสำหรับจัดการแคมเปญและโปรโมชันขึ้นมา เพื่อให้ทีมฝ่ายธุรกิจสามารถบริหารจัดการเองได้ แต่ด้วยปริมาณงานในปัจจุบันทีมพัฒนาไม่สามารถแบ่งไปทรัพยากรไปพัฒนาระบบเหล่านั้นในตอนนี้ได้
การจัดลำดับความสำคัญของงาน (Prioritize)
การจัดลำดับความสำคัญของงานเราจะแบ่งครึ่งบนเป็นงานที่สำคัญคือมี Business Impact สูง และงานทางซ้ายคืองานที่รอไม่ได้ (โดยทั่วไปคนจะใช้คำว่างานที่เร่งด่วน ทำให้เกิดปัญหาเวลาปฎิบัติจริง คือทุกอย่างก็ด่วนไปหมด ทำให้มันไม่ช่วยอะไร เราจึงนิยามเป็นคำว่างานที่รอไม่ได้แทน)
- ช่องสีแดงคืองานแทรก(Ad Hoc) งานที่รอไม่ได้ต้องทำทันทีและมีความสำคัญสูง เช่น ระบบมีการทำงานผิดพลาด การแก้ไขปัญหาบางอย่างให้ผู้ใช้งาน
- ช่องสีเขียวคืองานในสปรินท์ปกติ เป็นงานที่มีความสำคัญและด่วนแต่สามารถรอได้ ไม่จำเป็นต้องเอาทันทีในตอนนั้น
- ช่องสีเหลืองคืองานใน Product Backlog ที่มีความสำคัญรองลงมา รอนำเข้าสู่สปรินท์เพื่อพัฒนาต่อไป
- ช่องสีม่วงคืองานเก่าๆ ที่มีความสำคัญน้อยและยังไม่จำเป็นต้องหยิบมาทำเพิ่ม เช่น Internal tools ที่สามารถใช้งานได้อยู่แล้ว แม้จะไม่มีการพัฒนาอะไรเข้าไปเพิ่ม
ปกติทีมพัฒนาควรได้โฟกัสเฉพาะงานในช่องสีเขียวคืองานในสปรินท์ และงานสีแดงบางส่วนซึ่งก็ไม่ได้เกิดขึ้นบ่อยนัก
สถานการณ์ที่บริษัทอาจทำยอดไม่ถึงเป้าหมาย ทีมพัฒนาจะต้องแบ่งคนไปช่วยพัฒนาโปรโมชันและแคมเปญระหว่างสปรินท์ ทำให้งานของโปรเจ็คใหม่ที่อยู่ในสปรินท์ตั้งแต่แรกเกิดความล่าช้าออกไป หากเป็นแบบนี้ต่อไปเรื่อยๆทุกสปรินท์อาจทำให้โปรเจ็คใหม่ไม่สามารถขึ้นได้ทันกำหนด
ดังนั้นจึงแก้ไขปัญหาด้วยการให้แต่ละทีมวางแผนไว้ล่วงหน้าทั้งแผนหลักและแผนสำรอง และกำหนด Customer Support Policy เพื่อลดงานในช่องสีแดงลงให้มากที่สุด โดยนำงานเหล่านั้นเข้าสู่ช่องสีเขียวและสีเหลืองแทน ทำให้ทีมพัฒนาสามารถวางแผนการทำงานในสปรินท์ได้แม่นยำขึ้น สามารถขึ้นโปรเจ็คใหม่ได้ทันกำหนด และบริษัทก็ยังสามารถบรรลุเป้าหมายได้
สิ่งที่เกิดขึ้นเมื่อสปรินท์ถูกงานอื่นแทรก
- กราฟแท่งสีฟ้าคือเวลาการทำงานของหนึ่งสปรินท์
- กราฟส่วน Ideal คือการแบ่งเวลาที่ควรจะเป็นคือจะเริ่มสปรินท์ด้วยการประชุมต่างๆ(สีส้ม) จากนั้นทีมพัฒนาจะแบ่งเวลาให้โปรเจ็คปัจจุบันบางส่วน(สีแดง) เช่น การปรับปรุงฟีเจอร์เดิมหรือการเพิ่มฟีเจอร์ใหม่เล็กๆ โดยเร่งพัฒนาให้เสร็จตั้งแต่ต้นสปรินท์ จากนั้นจะทุ่มเวลาพัฒนางานของโปรเจ็คใหม่(สีเขียว) ต่อไปจนจบสปรินท์ แล้วปิดสปรินท์ด้วยการประชุม
- กราฟส่วน Ad hoc คือสิ่งที่เกิดขึ้นเมื่อมีงานและประชุมแทรกเข้ามาระหว่างสปรินท์ ทำให้ทีมมีเวลาพัฒนางานส่วนโปรเจ็คใหม่น้อยลง รวมถึงเสียเวลาบางส่วนเมื่อทำการสลับกลับมาทำงานโปรเจ็คใหม่ เพราะงานเขียนโปรแกรมคล้ายกับการแก้สมการคณิตศาสตร์ยากๆ ที่หากเราหยุดคิดไปกลางคัน เมื่อกลับมาทำต่อเราจะต้องทบทวนว่าทำถึงจุดไหนแล้ว มีอะไรที่ทำไปแล้ว มีอะไรที่ยังไม่ทำ และต้องทำอะไรเพิ่มอีกเพื่อให้ชิ้นงานสำเร็จ
- กราฟส่วน Should be คือสิ่งที่เรากำหนดขึ้นใหม่เพื่อแก้ไขปัญหาคือทีมพัฒนาจะกำหนดวันสำหรับประชุมขึ้นมา วันอื่นที่ไม่ใช่วันประชุมจะได้โฟกัสกับงานไปเลยไม่ต้องเสียเวลาเพื่อสลับการทำงาน
Sprint Backlog
งานที่จะนำเข้าสู่สปรินท์ต้องมีรายละเอียดให้ครบก่อนนำเข้ามา บางครั้งทีมพัฒนาจะเริ่มพัฒนาแต่ไม่สามารถทำได้เพราะต้องรอรายละเอียดจากฝ่ายอื่นก่อน ทำให้งานอัดแน่นกันในวันท้ายๆของสปรินท์ รายละเอียดที่ต้องมีให้ครบ เช่น Copywriting, UI, รูปภาพ และต้องประเมิน Business Impact Point มาให้เรียบร้อย
Business Impact Point
การประเมินผลกระทบ(Impact) จะประเมินจากผลกระทบกับคน 2 กลุ่ม คือ ผู้ใช้งานและทีมงาน
- ผลกระทบต่อผู้ใช้งาน เช่น ทำให้ผู้ใช้ใช้งานได้ง่ายขึ้น ตอบโจทย์ความต้องการมากขึ้น ทำให้เข้าถึงผู้ใช้ได้มากขึ้น
- ผลกระทบต่อทีมงาน เช่น Internal tool จะช่วยให้ทำงานได้ง่ายขึ้น หรือการพัฒนาฟีเจอร์บางอย่างเพื่อเก็บข้อมูลมาเพิ่มความรู้แก่ทีมเพื่อช่วยในการตัดสินใจต่างๆ
นอกจากนี้เราจะทำการแบ่งระดับของผลกระทบออกมา เช่น
- Supreme คืองานที่ส่งผลกระทบต่อบริษัท เช่น ภาพลักษณ์ หรือ การสร้างความได้เปรียบให้คู่แข่งรายใหม่ไม่สามารถเข้ามาในตลาดนี้ได้
- High คืองานที่ส่งผลกระทบต่อเป้าหมายของผลิตภัณฑ์ เช่น จำนวนผู้ใช้ จำนวนรายได้ หรือข้อมูลที่หากขาดไปแล้วส่งผลให้ทีมตัดสินใจไม่ได้ หรือโอกาสตัดสินใจพลาดสูงหากขาดข้อมูลส่วนนี้
- Soso คืองานที่ส่งกระทบต่อผู้ใช้เพียงบางกลุ่ม หรือเป็นข้อมูลแวดล้อมที่ช่วยประกอบการตัดสินใจเท่านั้น หากขาดข้อมูลส่วนนี้ไปก็ยังสามารถตัดสินใจได้
- None คืองานที่แทบไม่ส่งผลกระทบอะไร ความต้องการนั้นก็จะถูกลบออกจาก Product Backlog
การเลือกพัฒนาฟีเจอร์เพื่อตอบสนองความต้องการ
เมื่อต้องพัฒนาโปรเจ็คใหม่และดูแลโปรเจ็คปัจจุบันไปด้วย การจะเลือกพัฒนาฟีเจอร์ของโปรเจ็คปัจจุบันโดยที่กระทบกับทรัพยากรที่ต้องใช้พัฒนาโปรเจ็คใหม่ให้น้อยที่สุดได้อย่างไร สามารถไปอ่านต่อได้ที่
ข้อดีของการทำงานเป็นสปรินท์
ทีมจะรู้ทันทีเมื่อมีสถานการณ์ผิดปกติเกิดขึ้น และหาวิธีปรับปรุงประสิทธิภาพการทำงานได้ในทันที
- การทำ Daily Scrum ทำให้ทุกคนในทีมรู้หากมีงานอะไรแทรกเข้ามาในสปรินท์
- การทำ Sprint Review ทำให้รู้ว่ามีงานใดเสร็จหรือไม่เสร็จ อาจมีงานใหม่ที่แทรกเข้ามาเสร็จ แต่งานเก่าที่วางแผนไว้ตอนแรกอาจไม่เสร็จ
- การทำ Sprint Retrospective เพื่อหาแนวทางปรับปรุงการทำงาน
- เมื่อมีงานแทรกเข้ามาระหว่างสปรินท์ อาจมีการทำประชุมเพื่อสลับงานบางอย่างในสปรินท์ออกและนำงานใหม่เข้ามาแทน
- นอกจากนี้ยังสามารถคาดการณ์ได้ว่าเป้าหมายของงานในระยะยาวจะเสร็จได้ทันหรือไม่ทันเพราะสาเหตุอะไร
สิ่งที่เกิดขึ้นกับโปรเจ็คใหม่หากมีงานแทรกเรื่อยๆ
จากกราฟสามเหลี่ยมด้านซ้ายจะเห็นได้ว่าเราต้องการให้โปรเจ็คใหม่มีความสามารถสูง และเปิดให้ใช้งานในเวลาที่เร็วเพื่อตอบสนองให้ทันต่อธุรกิจ ดังนั้นคุณภาพของโปรเจ็คใหม่จะถูกลดลงไปส่วนหนึ่ง
สิ่งที่เกิดขึ้นเมื่อมีงานของโปรเจ็คปัจจุบันแทรกเข้ามาในสปรินท์ทำให้เวลาในการพัฒนาโปรเจ็คใหม่น้อยลงไปอีก เมื่อถึงกำหนดการขึ้นโปรเจ็คใหม่ อาจทำให้โปรเจ็คใหม่มีฟีเจอร์ไม่ครบตามที่ต้องการ รวมถึงมีคุณภาพต่ำลง(ตามกราฟด้านขวาบน)
สิ่งที่ควรเป็นคือเราต้องลดงานแทรกของโปรเจ็คปัจจุบันลง ทำให้เมื่อถึงเวลาขึ้นโปรเจ็คใหม่ โปรเจ็คใหม่จะได้มีฟีเจอร์ครบตามที่ต้องการและมีคุณภาพสูง(ตามกราฟขวาล่าง)
หากโปรเจ็คมีคุณภาพไม่ดี สิ่งที่จะเกิดขึ้นตามมาคือโปรเจ็คนั้นอาจมีช่วงอายุสั้น คือเมื่อมีการพัฒนาอะไรเพิ่มเติมไปเรื่อยๆ จะถึงขีดจำกัดของโปรเจ็คนั้นได้อย่างรวดเร็วเนื่องจากโครงสร้างของโปรเจ็คนั้นไม่ได้ถูกพัฒนาให้สามารถรองรับการขยายต่อยอดได้มาก เนื่องด้วยเวลาที่จำกัดทำให้โปรเจ็คถูกพัฒนาแค่เฉพาะความสามารถที่กำหนดไว้ตั้งแต่แรกเท่านั้น และถูกตัดการพัฒนาส่วนสำหรับรองรับการขยายต่อยอดออก เพื่อให้สามารถเปิดใช้งานได้ทันตามกำหนดเวลา รวมถึงคุณภาพที่อาจไม่ดี เช่น Unit Test ไม่ครบ เมื่อมีการใช้งานจริงอาจเกิดปัญหากับผู้ใช้งานได้ การเข้าไปพัฒนาเพิ่มเติมหรือแก้ไขก็อาจทำให้ของเดิมพังโดยไม่รู้ตัว ทำให้อาจต้องมีโปรเจ็คใหม่อีกตัวในเวลาอันสั้นเพื่อนำมาแทนที่โปรเจ็คนี้ที่ไม่สามารถขยายต่อไปได้
จากการระดมความคิดของทีม เราเลือกที่จะลดสโคปของโปรเจ็คใหม่ลงชั่วคราว โดยการแบ่งเป็น 2 เวอร์ชัน เพื่อให้มีบางส่วนสามารถปล่อยออกไปให้ผู้ใช้งานสามารถใช้งานได้ก่อน แล้วค่อยอัพเดทตัวเต็มออกไปในภายหลัง
วิธีการลดสโคปงานดีกว่าการขยายเวลาเพราะว่า หากเราทำการขยายเวลาแล้ว ถ้ายังทำไม่เสร็จอีกจะต้องมาลดสโคปทีหลังอีกรอบ ต้องมีการวางแผนใหม่ว่าส่วนที่ทำไปแล้ว ส่วนใดสามารถนำมาใช้ต่อได้ และขาดส่วนใดที่ต้องทำเพิ่มอีก ซึ่งอาจมีส่วนที่ต้องทำเพิ่มอีกมากหากว่าวางแผนลำดับการทำงานมาไม่ดีตั้งแต่ในตอนแรก ส่วนวิธีการลดสโคปงานก่อน หากว่าเรายังทำไม่ทันจริงๆ เราก็ยังมีแผนสำรองในการขยายเวลาเพิ่มขึ้นได้อีกรอบ
ภาพรวมของผลิตภัณฑ์
สิ่งที่เกิดขึ้นเมื่อเน้นการตลาด(Marketing) เพื่อให้บริษัททำยอดบรรลุตามเป้าหมายจะเป็นแบบด้านซ้ายคือต้องใช้การตลาดช่วยเรื่อยๆ โดยส่วนหลักยังคงมีความสามารถเท่าเดิมซึ่งจะเกิดปัญหาในระยะยาวเมื่อถึงขีดจำกัดของผลิตภัณฑ์และการตลาด ต่อให้เพิ่มการตลาดมากขึ้นเท่าไรก็ไม่สามารถเติบโตต่อได้ หรือเมื่อหยุดการตลาดอาจทำให้ยอดหายไปเลย
เช่น
- ตลาดชาเขียวที่เน้นแคมเปญชิงโชค เมื่อไม่มีแคมเปญยอดซื้อก็หายไปเลย ไม่สามารถไปต่อด้วยตัวผลิตภัณฑ์เองได้
- ค่ายมือถือต่อให้มีส่วนลดร้านอาหารมากขนาดไหน ถ้าสัญญาณไม่ดี ไม่สามารถใช้งานได้ คนก็ย้ายค่ายหนี
ดังนั้นเราควรเน้นพัฒนาผลิตภัณฑ์ให้ตอบโจทย์ความต้องการหลักของผู้ใช้งานมากกว่า และใช้การตลาดเป็นส่วนเสริม เช่น ช่วง low season หรือ ช่วงที่ต้องการเพิ่มยอดเป็นพิเศษ
เป้าหมายของผลิตภัณฑ์
สุดท้ายแล้วทุกฝ่ายของบริษัทล้วนมีเป้าหมายเดียวกัน ทุกคนล้วนต้องการช่วยพัฒนาบริษัทไปสู่เป้าหมาย ดังนั้นจึงควรยึดเป้าหมายหลักของบริษัทในระยะยาว จากนั้นแตกออกมาเป็นเป้าหมายย่อยระดับล่างลงไป โดยเป้าหมายย่อยในระดับล่างจะต้องช่วยสนับสนุนให้เป้าหมายระดับบนสำเร็จ เพื่อไม่ให้บริษัทของเราออกนอกทิศทาง และไปถึงเป้าหมายในเวลาที่กำหนด
