โปรเจกต์ซอฟต์แวร์มีคนรับผิดชอบแล้ว แต่ทำไมยังไม่มีใครตัดสินใจได้?

โปรเจกต์ซอฟต์แวร์มีคนรับผิดชอบแล้ว แต่ทำไมยังไม่มีใครตัดสินใจได้?

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

ปัญหาไม่ได้แปลว่ามีใครไม่ตั้งใจทำงาน

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

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

ผู้บริหารไม่ต้องรู้ทุกขั้นตอน แต่ทิศทางต้องลงมาถึงขั้นตอน

ผมไม่ได้คาดหวังให้ผู้บริหารระดับสูงจำรายละเอียดการทำงานทั้งหมด หน้าที่สำคัญของเขาคือกำหนดทิศทาง เช่น ต้องการควบคุมความเสี่ยง ลดรอบเวลางาน หรือรองรับการขยายธุรกิจ ส่วนคนปฏิบัติการควรช่วยบอกว่าหน้างานมีข้อจำกัดและข้อยกเว้นอะไร เมื่อสองส่วนนี้เชื่อมกัน เราจึงจะออกแบบ Workflow ที่ตอบทั้งธุรกิจและการทำงานจริงได้

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

ธุรกิจเหมือนกัน ไม่ได้แปลว่าหลังบ้านเหมือนกัน

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

เจ้าภาพฝั่งลูกค้าจึงควรเข้าใจทั้งบริบทภายในและธุรกิจที่องค์กรกำลังทำ และทำงานคู่กับ Project Manager ฝั่งผู้พัฒนา ไม่จำเป็นต้องใช้ตำแหน่งว่า Product Owner เสมอไป แต่ต้องมีขอบเขตอำนาจที่องค์กรยอมรับจริง แนวคิดนี้สอดคล้องกับ Scrum Guide ซึ่งย้ำว่าองค์กรต้องเคารพการตัดสินใจของ Product Owner ไม่ใช่แต่งตั้งชื่อไว้โดยไม่ให้อำนาจ

มอบอำนาจให้ชัด ไม่ใช่มอบอำนาจแบบไร้ขอบเขต

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

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

งานช้าและ Change Request อาจเป็นปลายเหตุ

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

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