ปัญหาขององค์กรแบบใหม่ ที่พยายามบริหารแบบเดิม

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

แล้วปัญหาอยู่ตรงไหน

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

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

ผู้บริหารไม่ใช่คนงี่เง่า เค้ามองเห็นปัญหา

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

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

ทำงานแบบ Hierarchy Work

ถ้าจัดทีม Agile แล้วทำงานลักษณะนี้ บริษัทจะไม่ต้องปรับตัวมากนัก คือทีมก็ใช้นักพัฒนากลุ่มเดิม อาจจะมีการจัดทีมให้ชัดเจน และพยายามไม่แยกคนกลุ่มนี้ออกจากกัน จากนั้นก็ให้ PM (Project Manager) รับหน้าที่ดูแลทีมในชื่อใหม่ว่า PO คนที่ทำหน้าที่เป็น PO ก็จะไปสอบถามว่าทีม Business ว่าอยากได้อะไร (หลายบริษัทจะเรียก Business ว่า User แล้วเรียกผู้ใช้จริง ๆ ว่า “เจ้าหน้าที่”)

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

ถ้าโชคดี PO ก็จะมาปรึกษากับทีมก่อน แต่ถ้าโชคร้ายทาง PO สัญญากับ Business ไปก่อนแล้วค่อยมาบอกทีม แบบนั้นทีมก็จะโชคร้ายหน่อย

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

จุดนี้เป็นส่วนแรกที่น่าขัดใจ เพราะซอร์ฟแวร์เป็นงานฝีมือไม่ใช่งานแรงงาน ดังนั้นคนที่รู้ดีคือคนที่ลงมือสร้างมันขึ้นมา (ไม่ใช่คนออกแบบ) ดังนั้นคนสร้างน่าจะเป็นคนที่คิด Solution ได้ดีที่สุด

ทีนี้เนื่องจากทีมอยู่ไกลจากผู้ใช้ การตรวจสอบว่าโปรแกรมดีหรือยัง (Inspect) จึงตกเป็นภาระของ PO ทีมงานจะส่งงานให้ PO เป็นคนตรวจสอบบ่อย ๆ (เช่น ทุก ๆ สองสัปดาห์) ถ้าได้รับอนุมัติว่าผ่านก็แสดงว่างานดีแล้ว ทีมจะไม่โดนดุว่าทำงานไม่ดี ถ้าระบบไม่ดีก็ไปโทษ PO หรือ BA ละกัน

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

การทำงานแบบนี้ถึงจะมีพิธีกรรมครบตามที่ Agile สาย Scrum, XP หรือ Kanban บอกเอาไว้ แต่มันก็ยากที่จะทำให้ซอร์ฟแวร์มีความยืดหยุ่นพร้อมสำหรับการเปลี่ยนแปลง

ทำงานแบบ Team Work

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

แต่คนที่เคยทำงานแบบเดิมจะกังวลมากแน่นอน เพราะเมื่อก่อนความต้องการต่าง ๆ จะได้รับการกรองโดย PO, BA หรือแม้แต่หัวหน้างานเสมอ ทำให้มั่นใจว่าจะได้แนวทางการแก้ปัญหาที่ถูกต้องก่อนที่จะนำไปพัฒนา

ดังนั้นถ้าทีมต้องการปรับตัวได้เร็ว แก้ปัญหาให้ผู้ใช้ได้อย่างถูกต้อง ทีมงานจะต้องทำให้ PO, BA และ Business ไว้ใจว่าจะมองไปที่ปัญหาของผู้ใช้แล้วพยายามหาทางออก ไม่ใช่ทำทุกอย่างตามที่ผู้ใช้ขอ

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

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

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

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

เมื่อทีมคิดได้เองแบบนี้การทำงานแบบ Team Work จึงจะเกิดขึ้น

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

🤔 ถ้าทีมคิดเองได้ แล้วอย่างนี้ผู้บริหารยังต้องทำอะไรอยู่หรือเปล่า?

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

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

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

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

Hierarchy Work vs Team Work

ไม่ใช่ว่าการทำงานแบบ Team Work จะสามารถทำได้ทันที หลาย ๆ องค์กรยังต้องการระยะเวลาในการปรับตัว การเริ่มต้นจาก Hierarchy Work หรือแนวทางอื่น ๆ ก็เป็นสิ่งสามารถทำได้ และอาจจะเป็นสิ่งที่เหมาะสมกับองค์กร ณ ตอนนั้น

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

ขอบคุณพี่โอที่ทำให้ผมเห็นภาพนี้ชัดขึ้นโดยเฉพาะตอนที่ไปร่วมงานกับพี่ที่ Sansiri ครับ ขอบคุณพี่อูที่สอนทำ Visual Note ตอนไป ODDS Gathering ขอบคุณ ODDS ที่ช่วยย้ำว่า “ทำซอร์ฟแวร์ต้องสนุก” และ ขอบคุณทุกคนที่ช่วยให้รู้ว่าการเข้าใจผู้ใช้ไม่ใช่สิ่งที่ UX จะเก็บเอาไว้ทำคนเดียว 🙇‍♂️