สิ่งหนึ่งที่ผมสัมผัสได้ทั้งจากในองค์กรใหญ่สมัยนู้นที่เป็นพนักงานประจำ และองค์กรใหญ่สมัยนี้ที่ออกมาทำธุรกิจเอง สิ่งนั้นคือ “ความกลัวต่อความล้มเหลว” … ยังไง?
ต้องการแผนที่สมบูรณ์แบบ — มันจึงเป็นที่มาของการประชุมแล้วประชุมเล่า จากสองคนเป็นสองทีม เป็นสามแผนก และจบที่ยี่สิบหกสาขา … วางแผน แก้แผน เปลี่ยนแผน หาข้อมูล หาคำตอบของทุกคำถาม ออกแบบระบบ เขียนสเปค คิดเวิร์คโฟล ออกแบบยูไอ ทุกกระเบียดนิ้ว จากไอเดียธุรกิจเจ๋งๆแต่หยาบๆ กลายเป็นแผนธุรกิจเล่มหนา จากไวร์เฟรมที่วาดด้วยมือ ขยายขนาดไปเป็นรายละเอียดของหน้าจอ ปุ่ม ฟ้อนท์ แม้กระทั่งโค๊ดสี … ทั้งหมดนี้เพียงเพื่อต้องการสร้าง “หลักประกันว่าสิ่งที่กำลังคิดจะทำมันจะเวิร์ค”
ต้องการการตัดสินใจจากคนที่อยู่เหนือขึ้นไป “เสมอ” — เพราะหัวหน้าอันดับหนึ่งกลัวจะล้มเหลว มองความผิดพลาดเป็นเรื่องคอขาดบาดตาย หัวหน้าอันดับสองจึงกลัวความล้มเหลวไปด้วย ก่อนจะทำอะไรก็ต้องขอคำอนุมัติจากหัวหน้าอันดับหนึ่ง หัวหน้าอันดับสามก็รออันดับสอง หัวหน้าอันดับสี่ก็ต้องถามอันดับสาม เรื่อยไปเป็นลูกโซ่ จนกระทั่งถึงลูกน้องอันดับโหล่ก็นั่งเฉยๆรอคำสั่ง … ทั้งหมดนี้เพียงเพราะต้องการ “คนรับผิดชอบเมื่ออะไรๆมันไม่เป็นไปตามแผน”
ถ้าเราไขว่คว้าหาปัจจัยสองข้อนี้ สิ่งเดียวที่จะเป็นหลักประกันให้เราได้คือ
- เราจะไม่มีทางสร้างสิ่งใหม่ที่แตกต่างที่ดีกว่าที่เป็นนวัตกรรมได้ เพราะเมื่อมีแผนเราต้องเล่นตามแผน เราจะถูกจำกัดด้วยข้อมูลที่ล้าสมัยและด้วยกฎเกณฑ์ที่ไม่ยืดหยุ่น เรากำลังจะสร้างอะไรที่เคยมีมาอยู่แล้วและเราก็กำลังปิดหูปิดตารับรู้โอกาสที่ดีกว่าจากโลกภายนอก 🙈
- ต่อให้แผนดีเยี่ยม ละเอียดรอบคอบมีหลักการ … แต่น่าเสียดายว่ากว่าจะเห็นผลลัพธ์ก็เมื่อสายไปแล้ว เราใช้พลังงานไปมากมายในการวางแผนเผื่อหาหลักประกันความสำเร็จ (ซึ่งไม่มีอยู่จริง) เราใช้เวลาครึ่งปีในการขอคำอนุมัติจากหัวหน้าของหัวหน้าของหัวหน้าของหัวหน้า … ซึ่งหลายครั้งคำตอบคือ “NO” … ไอเดียดีๆก็ถูกฝังกลบตรงนี้ ⚰️
ลูกค้ารายแรก — ผมอยากรู้ทุกเรื่อง
เล่าประสบการณ์จริงของผมเองครับ ลูกค้ารายแรกอยากได้ระบบที่ค่อนข้างใหม่ ใหม่ในที่นี้คือยังไม่เคยมีใครในเมืองไทยทำมาก่อน เป็นระบบที่ผสมผสานกันทั้งเรื่องไอทีและหลักการคันบัน (Kanban) น่าตื่นเต้นดีครับ … มันแย่หน่อยตรงที่ผมและทีมงานของลูกค้าใช้เวลาเป็นเดือนๆเพื่อเขียนสเปคเล่มใหญ่ เพราะผู้ใหญ่อยากเห็นทุกหน้าจอ อยากรู้ทุกฟังก์ชั่น อยากเข้าใจทุกปุ่มและเมนู และอยากรู้จักรายงานทุกประเภท
ผมรู้สึกว่ามันมากเกินไป มันบีบบังคับแนวคิดที่แตกแขนงของผมและทีมงานของผมมากเกินไป … ผมตัดสินใจถอนตัวจากงานนี้ ตัวงานน่าสนใจ กระบวนการเข้มงวดและล้าสมัยเกินไป และเท่าที่ตามข่าว โปรเจกต์นี้ยังไม่ได้เริ่มทำ ยังไม่ได้ก้าวหน้าไปไหน นี่คือสิ่งที่ผมเรียกว่าความกลัวที่จะล้มเหลว
ลูกค้ารายที่สอง — ผมพอจะเห็นภาพแล้ว
ลูกค้ารายที่สอง เริ่มต้นคล้ายๆกัน อยากได้ระบบใหม่ที่ไม่เคยมีใครทำมาก่อนในบ้านเรา งานนี้เน้นเทคโนโลยีเยอะหน่อยทั้งฮาร์ดแวร์และซอฟต์แวร์ รวมถึงการออกแบบเวิร์คโฟลใหม่หมด ผมคุยกับทีมงานลูกค้าเพื่อเก็บรีไควเม้นต์รอบแรก ผมกลับมาทำการบ้านเป็นการออกแบบซอฟต์แวร์ในส่วนต่างๆไปพรีเซ็นต์ … น่าสนใจมากว่าหัวหน้าทีมของลูกค้าพูดมาแบบนี้ครับ
“โอเคครับ ผมพอจะเห็นภาพการทำงานของซอฟต์แวร์และการเชื่อมโยงกับฮาร์ดแวร์แล้ว ผมไม่มีปัญหาครับ เริ่มได้เลย”
คีย์เวิร์ดคือ “พอจะเห็นภาพ” มันคือการเก็ตไอเดียหลัก มันคือการเข้าใจในแก่นของงานที่เรากำลังจะทำ ปัญหาที่เราพยายามจะแก้ และที่สำคัญคือมันไม่จำเป็นต้องมีคำตอบให้กับทุกคำถามตั้งแต่วันแรก นี่คือสิ่งที่ผมเรียกว่าความกลัวที่จะไม่ได้ลอง
ตอนนี้ผมและทีมงานกำลังช่วยกันทำงานนี้อยู่ครับ สนุกดี เพราะทั้งโจทย์ที่ไม่เคยมีใครแก้และทั้งแนวทางการทำงานที่ยืดหยุ่นและมีช่องว่างมากมายให้คิดต่างเพื่อสร้างอะไรใหม่ๆ
ถ้าถามว่าอะไรทำให้เราล้มเหลว … ผมก็คงตอบได้ว่ามันคือความกลัวที่จะล้มเหลวนั่นแหละที่ทำให้เราล้มเหลว
ในเวลาหนึ่งเดือน องค์กรที่พยายามหาหลักประกันที่ไม่มีอยู่จริงและคนรับผิดชอบ — ยืนอยู่ที่เดิม
ในเวลาหนึ่งเดือนเท่ากัน องค์กรที่กล้าเสี่ยงและไม่กลัวความล้มเหลว — ก้าวไปแล้วหลายขั้น 🚶🏽🚶🏽♀️🚶🏾♂️