Empowering developer

ในวงการ Developer เรามักจะมีคำพูดที่ว่า “ถ้าเห็นว่ามันไม่ดี บ่นทำไม ทำไมไม่แก้ไขให้มันดีขึ้นล่ะ”

คำพูดนี้ฟังดูเผินๆ ก็อาจจะเหมือนเป็นคำพูดที่มีเหตุผล Make sense แล้วเป็นเรื่องที่คนทำงานที่มีทัศนคติดีควรจะมีไว้

แต่ลองนึกถึงสถานการณ์ที่คุณเจอ Bug หรือเจอจุดที่ไม่ดีหนึ่งจุดแล้วการแก้ไขต้องผ่านขั้นตอนเหล่านี้

  1. ต้องสร้าง Ticket ทิ้งไว้ในระบบ
  2. ต้องเดินมาขอ Approve กับหัวหน้าทีม
  3. หัวหน้าทีมต้องเดินไปขอ Approve กับ Stakeholder
  4. พอผ่านการยืนยันว่าสิ่งไม่ดีเหล่านี้แก้ได้ ต้องประสานงานกับอีก 2 ทีมให้แก้ไข Interface ที่เกี่ยวข้อง
  5. ทีมสองทีมนั้นบอกผมงานยุ่งอยู่ รออีกซัก 2–3 Sprint แล้วนะ
  6. หัวหน้าเดินมาตามว่า อ้าวตอนแรกเห็นมีไฟบอกว่าอยากแก้อยากแก้ เนี่ยก็อุตส่าห์ไปขอ Approve ให้แล้ว ทำไมผ่านไปหลายวันแล้วแก้ไม่เสร็จ
  7. เริ่มต้องพูดจาที่ฟังเผินๆ เหมือนแก้ตัว แต่ก็เป็นเรื่องจริง ว่า “ผมรอทีมนั้น รอทีมนี้อยู่”
  8. ผ่านขั้นตอนทั้งหมดมาแล้วโค้ด 15 นาที
  9. Release ขึ้น Production
  10. Regret decision ครั้งหน้าเงียบๆ ไว้ดีกว่า นี่มันยุ่งยากเกินไปแล้วที่จะทำให้อะไรๆ ดีขึ้น แถมโดนด่าอีกว่ามีไฟแล้วทำไมแก้ช้า

ผมคิดว่าไม่แปลกเลยที่องค์กรที่ลักษณะการบริหารแบบนี้ Developer นอกจากหมดไฟไม่พอ ยังต้อง Micromangement แล้วทุกคนก็อยู่ในสภาวะรอคำสั่งเป็นหลัก อยู่ในสภาวะ Passive เป็นหลัก

ในสภาพโครงสร้างแบบนี้ ผมเชื่อว่าต่อให้เอา Developer ที่มีไฟที่สุดในโลกมาอยู่ เขาก็ไม่สามารถแสดงศักยภาพได้เต็มที่นัก


เรื่อง Motivation มันไม่ใช่เรื่องของ “ปัจเจก” อย่างเดียว แต่เป็นเรื่องของที่ว่าคนต้องรู้สึกว่าฉันมีอำนาจที่จะเปลี่ยนแปลงอะไรได้

ลองนึกถึงอีกองค์กรนึงที่มีลักษณะแบบนี้

  1. ผมรู้สึกว่าตรงนี้ของแอพเรามันไม่ดีนะ
  2. หัวหน้าบอกทำเลย แก้เลย
  3. โค้ด 15 นาที ไม่ต้องรอทีมที่เกี่ยวข้อง
  4. ขึ้น Production เรียบร้อย
  5. ได้รับคำขอบคุณจากทั้งหัวหน้าและลูกค้า “น้องครับ ขอบคุณมากเลยที่ช่วยดูให้” “ทีมนี้เจ๋งอ่ะขออะไรแป๊ปเดียวได้เลย”

นี่แหละคือสิ่งที่เรา Taskworld อยากให้เป็น


คำถามคือเราจะไปถึงจุดนั้นได้อย่างไร

ถ้าเทียบระหว่างสถานการณ์แรกกับสถานการณ์ที่สอง เราจะมีข้อแตกต่างใหญ่ๆ ดังนี้

สถานการณ์แรกนั้น Approval process นั้นนานมาก

สำหรับ Taskworld เราต้องการ Minimize สิ่งเหล่านี้ให้มากที่สุด เราพยายามสร้างความชัดเจนว่าอะไรที่สามารถทำได้เองทันที อะไรบ้างที่มันใหญ่จริงๆ แล้วเรายังไม่พร้อมที่จะให้ Developer ตัดสินใจโดยไม่บอก Stakeholder

เราพยายามมอบ Autonomy พยายามมอบอิสระให้กับ Developer

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

และแน่นอนนอกจากเรื่องของ Culture ในเชิงเทคนิคแล้วเราก็ต้องมีระบบ Automated testing ที่ดีพอที่ถ้าเขาใช้อิสระในทางที่จะทำให้ Application พัง ระบบก็จะป้องกันเขาให้

เมื่อเรามีสองอย่างนี้ประกอบกัน Autonomy ก็จะเกิดขึ้นกับ Developer

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

ก็ไม่แปลกที่เขาก็จะอยู่เฉยๆ รอคำสั่ง

ดังนั้น Boundaries ในเชิงการบริหารว่าทำอะไรในขอบเขตไหนจะไม่โดนต่อว่า และ Automated test ว่าทำอะไรถึงจะไม่ทำ Production พังจึงเป็นสิ่งสำคัญมากที่จะทำให้เกิด Autonomy ที่สุขภาพดีได้

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

สำหรับผม ถ้าตรงกับที่เราคิด 80% ผมถือว่าสำเร็จแล้ว อย่าไปคาดหวัง 100% มันไม่มีทางเป็นจริงได้

เพราะถ้ามันตรงกับที่เราคิด 80% แล้วผมไม่ต้องมาเสียเวลาคอยจ้ำจี้จำไชว่าต้องทำอะไร ผมยอมเสีย Slack 20% นั้นได้

ผมว่าถ้าผมต้องมานั่งจัดประชุมทุกวี่ทุกวันทำ Status update ทุกวี่ทุกวัน เพื่อให้เวลานอกงานประชุมเขาทำตรงกับที่เราต้องการ 100% เนี่ย

สุดท้ายจะกลายเป็นว่าตัวงานประชุมเอง มันเสียเวลามากกว่า 20% เยอะเลย

อีกข้อคือ สถานการณ์แรก มี Code dependency มากเกินไป

นั่นทำให้การอยากจะทำอะไรซักอย่างต้อง Depends ต้องพึ่งพาทีมอื่นที่อยู่ไกลและมีภารกิจของเขาเอง ที่จะช่วยแก้โค้ดที่เกี่ยวข้องให้

ในสถานการณ์แบบนี้เขาก็รู้สึกว่าเขาไม่สามารถทำอะไรได้ ต้องรอไปรอมา กว่าจะถึงเวลาที่เขาจะเริ่มแก้ไขได้ ไฟของเขาก็หมดไปแล้ว

เรื่องนี้แก้ได้ด้วย Software architecture ที่ดี ที่ Clean ที่ Decoupling ที่ทำให้แต่ละคนสามารถแก้ไขได้ด้วยตัวเอง ไม่มี Dependency ระหว่างกันมากมาย แต่ละคนติดต่อกันด้วย Interface ที่เสถียรและเพียงพอที่จะให้คนที่เกี่ยวข้องเคลื่อนไหวได้


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

แน่นอนผมอยากเห็นภาพที่ทุกคนบอกว่า “เห็นว่าไม่ดีก็ทำให้มันดีขึ้นสิ”

แต่การเดินไปบอกเฉยๆ ว่า “ไม่ชอบก็แก้สิ” แล้วก็เดินจากไป โดยไม่ดูทั้งข้อจำกัดเชิง Process การทำงาน และข้อจำกัดเชิง Technical มันก็เป็นอะไรที่ผลักภาระให้ Developer มากเกินไป

มันไม่แฟร์เลยที่ Developer ที่ไม่ได้รับพลังมากเพียงพอที่จะแก้ไขสิ่งที่ไม่ดีได้ จะต้อง Take accountability ในสิ่งที่ไม่ดีที่เกิดขึ้น จะโดนตัดสินว่าไม่มีไฟ Attitude ไม่ดี ไม่ใส่ใจ รู้แล้วทำไมไม่ทำให้มันดีขึ้น

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

นั่นแหละคือสิ่งที่เราต้องการจะสร้างขึ้นใน Taskworld ครับ


ถ้าใครสนใจองค์กรที่ต้องการสร้าง Development team บนพื้นฐานแนวคิดแบบนี้ ตอนนี้ Taskworld is hiring กำลังหาคนร่วมทีมอยู่นะครับ

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.