[PM] เมื่อไม่ได้คุยกันมาก่อนถึงได้มีปัญหา

ปีนี้น่าจะ 2020 เดือน 2 แล้วครับเอาหล่ะลองมาสรุปปัญหาในปีที่ผ่านๆมาดีกว่าครับว่าทำไมคนกลุ่มนึงถึงงานหนักอยู่เสมอ ทำไมโครงการ IT ถึงประเมินงานแล้วอะไรแล้วถึงต้องมาทำวันหยุด

ประสบการณ์ผู้ประเมินไม่เพียงพอ

• อาจจะไม่เชี่ยวชาญในงานที่ทำ หรือ เคยประเมินครั้งแรกครับ
• Skill ยังขาดไป เช่น เคยทำ Windows APP แล้วมาประเมิน Web APP
• ประเมินแล้ว แต่เพื่อให้ได้งาน อาจจะต้องลดเวลาประเมินไปให้พอดีกับงบของลูกค้า อันนี้ประสบการณ์คนประเมินคนแรกอาจจะพอ แต่คนถัดมาอาจจะของปัดลดลงไป
• ไม่เข้าใจใน Product หรือยังใช้งานไม่คล่อง

บริหารโครงการไม่เป็น(Project และ MA)

• ตามใจลูกค้าเกินไป เอ็นดูลูกค้า แต่ทีมตายเอา เลื่อนไป เลื่อนมาจน Delay
  • จนทีมเละจาก Project A delay มาชน Project B เพราะไม่มีการกำหนด scope ของการ research
  • พอมา Project B Dev เร่งงานจนตามแผนแล้ว ลูกค้าขอเลื่อน เพิ่ม Feature จนไปชนกับ Project C
  • Project C เนื่องจากเป็นองค์กรที่ล๊อคความสำเร็จกับ KPI ดังนั้น Deadline เท่าเดิม ส่วนที่กินๆมา Dev รับเละ
• การสื่อสาร
  • ขยับ milestone เข้า หรือ ออกแล้วไม่แจ้งทีม เช่น
    • ไม่แจ้งทีมเอกสารส่งมอบตกลงส่งเดือน 5 ปี 2020 ขยับกลายเป็น เดือน 11 ปี 2019
    • UAT อยู่ๆขยับเร็วกว่ากำหนด 2 สัปดาห์ แล้วทั้งทีมไม่รุ้
  • คิดเอง เออเอง ไม่เข้าใจ แต่ไม่ได้ถามผู้ที่เกี่ยวข้อง
  • ขาด Tracking และติดตามประชุม
    • ไม่ต้องเยอะ แต่ควรมีการแจ้ง ติดตาม และปรับปรุงสม่ำเสมอ ไม่ใช่แจ้งเอาตอนอีก 2 สัปดาห์จะเริ่ม ทั้งๆที่รู้มาก่อน 1 เดือนครึ่ง ++
  • มีการสื่อสารหลาย Hop
• ดูเฉพาะภาพรวมเฉพาะ 1 โครงการ ทั้งที่จริงๆแล้ว Resource มันกระจายไปอยู่ในหลายโครงการ
  • จริงๆควรดูภาพรวมของ Resource ด้วย ไม่ใช่มองเฉพาะแค่โครงการเดียวแยกกัน ต้องมองภาพรวมด้วยศัพท์ทาง PM จะเรียกว่า Portfolio 1 Portfolio มีหลายโครงการครับ

กระบวนการไม่ชัดเจน

• พอบริหารโครงการเละแล้ว งานทีม Project ล้น แต่ไม่สามารถส่งงานต้อให้ทีม MA เข้ามาช่วยได้ เพราะไม่ได้กำหนดกระบวนการชัดเจน
• เคส MA มี Incident ค้างแล้ว จริงๆต้องมีการติดตามจำนวนกี่วัน

ขาดการจัดเก็บ KM ที่ดี

• ปัญหาจุกจิต่างๆที่เกิดซ้ำๆขาดการจัดเก็บ KM หรือสรุปไปแล้วไม่ได้มีสาระที่ช่วยให้แก้เลย อาทิ เช่น
  • ส่งทีมไปแก้ปัญหาที่หน้างานแล้ว
  • แก้ไขโปรแกรมแล้ว (แต่จริงๆไม่มีการแก้ไขโปรแกรม)

ท้ายที่สุดแล้ว ถึงทุกอย่างจะ Perfect แต่มันพังทลายได้ด้วยคน

• คนไม่ทำตามกระบวนการ
  • กระบวนการจริงๆ คือ Support ควรทดสอบเคสเท่าที่ทำได้ก่อนส่งงานต่อทีมที่เกี่ยวข้อง แต่ในความเป็นจริงแค่ทำตัวเป็น forward mail ส่งงานต่อไป
  • DEV ไม่ทำ Unit Test เพราะเวลาไม่เพียงพอ
• หัวรัน ทีมเตือนแล้วไม่เชื่อ
• มืนงงขอความร่วมมือแล้วก็เฉยๆ
• หงุดหงิด อารมณ์ไม่ดี