[RE: สอบถามคนเป็นหัวหน้า ท่านเอาสิ่งนี้เป็นส่วนนึงในการประเมินลูกน้องไหมแม้อาจไม่มีหัวข้อตรงตัวให้ประเมิน (โหวต)]
_TOnZ- พิมพ์ว่า:
byrd.tt พิมพ์ว่า:
มีผลแน่นอนครับ
หลายครั้งที่เข้าทำงานที่ใหม่ เราไม่ได้เป็นคนตั้ง KPI น้องในทีมตั้งแต่ต้นปี แต่เรื่องพวกนี้มีผลแน่นอน ผมอยู่ในสายงาน IT เคยดูแลทีม support คือใช่ที่ระบบมันจ่าย ticket แบบวนให้คน แต่ต่อให้จำนวน ticket เท่ากัน แต่ความยากง่ายไม่เท่ากัน ถ้าคนนึงแม่มติดเคสยาก อีกคนชิลล์เพราะแก้ของตัวเองเสร็จแล้ว (ง่ายกว่า) แล้วจะไม่ไปช่วยเพื่อนที่งานล้นหรอครับ
ถ้าคิดแบบนั้น รบกวนออกไปทำงานของตัวเองเลยครับ
เรามีคำว่าทีม เพราะเราเอาไว้ช่วยกันครับ
บางทีช่วยแล้วเดือดร้อนก็มี (งานเพิ่ม เจอลูกค้าด่า งานยาก ฯลฯ)
แต่คุณทำงานให้องค์กร เพื่อนคุณก็ทำงานให้องค์กรเดียวกัน
มันก็ต้องช่วยกันครับ
หรือทีม BA ก็เหมือนกัน คนนึงดูแล workstream ที่โคตร complex แต่ของอีกคนง่ายกว่า ถ้าคุณมีเวลาเหลือ ก็สมควรไปช่วยเพื่อนคุณครับ หรืออย่างน้อยไปถามก็ได้ว่าให้ช่วยไรมั้ย
สำหรับผมเรื่อง teamwork สำหรับมากครับ
สำหรับผมคนที่จะมีหน้าที่ แจกงานคือ team lead หรือหัวหน้าน คือระบบมันอาจจะช่วยกระจายงานมาบ้างก็จริง แต่ตามตัวอย่างที่คุณบอก คือมันมีงานยาก ง่าย ฉะนั้น team lead น่าจะต้องม่ monitor ตรงนี้แล้วแจกงานตามความเหมาะสมอีกที
ผมมองว่าการที่คนที่ได้งานง่ายมาทำจบ และไม่ไปช่วยคนอื่นต่ออาจจะไม่ได้ผิดมากนัก กลับกันหัวหน้าที่ไม่ยอมแจกจ่ายงานตาม manpower จริงๆ ควรมีความผิดมากกว่า
เคส ba ก็เช่นเดียวกัน ทุกๆ task เรามี story point ฉะนั้น เวลาเราแจกงานเราไม่ควรแจกงานเป็น task แต่ควรกระจายงานตาม point ให้เท่าๆ กัน ที่นี่ถ้า point มันเท่ากันแล้วมีคนนึงทำเสร็จก่อน แล้วไม่ไปช่วยคนอื่น มันไม่น่าใช่ความผิดของเขาเลย เพราะทุกคนได้รับงานที่มี workload เท่ากันแล้ว กลับกันถ้าคนทำเสร็จเร็วไปช่วย หรือ team lead assign ให้ไปข่วน เราควรจะ reward เขา
ตอบเป็น 2 ส่วนเนอะครับ เพราะว่ามันไม่เหมือนกัน
1/ Ticket สำหรับ Team Support มันไม่ได้มาตาม complexity ครับ มันจ่ายงานตาม load ของงาน เราไม่ได้เป็นคน assign แต่ ticket มันถูก route แล้วก็ assign มาที่น้องในทีมเอง team lead เค้าก็ไปช่วยน้องดูแล้วก็ re-assign ใหม่กันเองนั่นแหล่ะครับ ผมแค่ ensure ว่างานไม่โหลดที่ใครคนได้คนนึง เพราะไม่งั้นนอกจากน้องงานหนักแล้ว SLA มันก็ช้าตามไปด้วย
2/ ก่อนที่จะออกมาเป็น story point ตอนเข้าไปเก็บ requirements คือปัญหาครับ อย่างทีมที่ดูเรื่อง AR กับ AP ตอนไปคุยกับ user เราก็พอมีไอเดียแล้วว่า อันไหนมันน่าจะ complex กว่ากัน แต่พอไปคุยกับ user จริงๆ use case มันงอกครับ แล้วก็ไม่เท่ากับที่ anticipate ไว้ตอนแรกด้วย จริงๆก็แก้แล้วก็ปรับกันไปครับ แต่สุดท้าย ผมเองเป็น consult เราต้องทำยังไงก็ได้ให้ deliver on-time สุดท้ายมันก็ต้องช่วยกันไถให้งานออกมาอยู่ดี มันจะต่างกับ corporate ที่ scope ความรับผิดชอบมันไม่ต้องมี deliverables ที่ไปเก็บเงินลูกค้าด้วย ฉะนั้น พวกน้องๆก็ต้องช่วยกันให้งานเสร็จครับ ต่อให้มันจะ bloat ขนาดไหนก็ตาม (หรืออาจจะไม่เรื่องของน้องเค้าโดยตรงก็ตาม) เพราะงานไม่เสร็จก็เก็บเงินลูกค้าไม่ได้ครับ