TanThai.Com

Story#7 ทีมคุณทำงานแบบ Tetris รึป่าว?

Visit: https://codingugly.com/?p=40

Product manager จำนวนมากมองทีม development เหมือนกับบล็อก Tretis โดยไม่รู้ตัว เป็นอย่างไร มาลองดูกันครับ

การพัฒนา product อย่างที่ทราบกันดี คือต้องเป็นไปอย่างต่อเนื่องเป็น iterations ทำให้การบริหาร resource ต้องต่อเนื่องด้วยเช่นกัน การใส่ product backlogs เข้าไป ทำให้การันตีว่ามีงานเข้ามาอย่างต่อเนื่อง และ เมื่อจัดเป็น sprint backlog แล้วยิ่งต้อง flow อย่างต่อเนืองยิ่งกว่า

คำถามประมาณว่า “ตอนนี้ทำไรอยู่?” “ให้คนนั้นมาช่วยทำดีไม๊?” “ถ้า dev คนนั้นทำ ticket นี้เสร็จ ผมจะให้เค้ามาทำอีก ticket นะ” หรือ “quarter นี้ถ้าพอมีเวลาเรา deliver feature xxx เข้าไปด้วยใน sprint นี้เลยจะทันไม๊ บางทีเราอาจต่อรองเอา epic นี้ออกไปก่อน”

จริงๆ product manager ก็ไม่ได้ทำอะไรผิด เพราะมันเป็นหน้าที่ของเขาที่ต้อง ทำให้ได้ output ให้ได้มากที่สุด ไม่เฉพาะ product manager บางทีลงไปถึงระดับ technical lead หรือแม้แต่ตัวเราเองเลย ที่คิดแบบนั้น เรากำลังเล่นเกมส์ Tetris กับเวลาของเรา ตลอดเวลา ลองนึกภาพดู ตอนเราติดบางอย่าง เราจะพยายามใช้เวลาทั้งหมดไปกับมันแทนที่จะเอาตัวเราเองออกมาหาเวลาใคร่ครวญหาวิธีแก้ปัญหา หรือแม้กระทั่งเวลาพักสมอง ซึ่งบางครั้งเป็นสิ่งที่ควรทำ

ผลข้างเคียงของการเล่น Tetris กับงานคือเราจะไม่มีเวลามาทดลองอะไรใหม่ หรือทำการสำรวจบางอย่าง เราจะพยายามทำให้ทุกคน busy และรีบจ่ายงานให้เมื่อเวลาของงานถัดไปมาบรรจบ หากทำงานร่วมกันหลายๆทีม ยิ่งซับซ้อนมากขึ้น ถ้าทีมนั้นรออะไรบางอย่างจากเรา เราจะเห็นว่าทุกอย่างได้ถูกวางไว้แล้วเหมือนบล็อก Tetris อันถัดๆไป เพราะทุกอย่างได้ถูกวางไว้แล้ว เราอาจไม่มีเวลาที่จะ rework (bug!) เราจะถูกล็อกไว้ด้วยสิ่งที่ต้องทำเพราะเราได้ commit ไว้ใน backlogs และมันเป็นสิ่งที่ผมเห็นบ่อยมาก ในการทำงานสาย software development เราคงเคยได้ยินคำว่า day 1 bug ที่ไม่เคยถูกแก้ไขเลย ดังนั้น พยายามอย่าเป็นเหมือนเกมส์ Tetris

แต่ก็เป็นเรื่องที่ยากเพราะ engineering team จะต้อง make things happen และมี pressure จากหลายส่วนภายในองค์กร ที่พยายามให้เราเล่นเกมส์ Tetris แต่ถึงกระนั้น เราควรยิ่งต้องพยายามให้มาก ในการสร้าง awareness ให้ทุกคนได้รู้ถึง bad habit นี้ และเริ่มจัด backlogs ทีเป็น experimental มากขึ้นเรื่อยๆในแต่ละ sprint โดยคำนึงถึง impact driven approach และอย่าไปกังวลว่าเวลาจะบานปลาย เพราะดีกว่าที่จะทำให้ทุกคน busy จนไม่มีเวลา optimize อะไรเลย นอกจาก optimize ให้ทุกคน busy