ถ้าเราเป็นน้องใหม่ในทีม เราต้องผ่านการเรียนรู้เรื่องงานสักระยะก่อนลุยงานจริงอย่างเต็มสปีด
ดีเวลลอปเปอร์, เทสเตอร์, และโปรดักท์ ซัพพอร์ต … สิ่งที่น้องใหม่ทุกคนในตำแหน่งเหล่านี้มีเหมือนกันคือการเรียนรู้ในโปรดักท์ของตัวเองอย่างเข้มข้นเพื่อรู้รายละเอียดของมันอย่างถ่องแท้ที่สุด
- พวกเขาอ่าน
- พวกเขาไล่โค๊ด
- พวกเขาดีบั๊ก
- พวกเขาลองแก้บั๊ก
- พวกเขาเทสระบบ
- พวกเขาเซ็ตอัพระบบ
หลายเรื่องที่ทำมันส่งผลให้ความรู้ในโปรดักท์เพิ่มขึ้น
เราก็เป็นน้องใหม่ในตำแหน่งโปรเจ็กต์ เมเนเจอร์ เราต้องผ่านการเรียนรู้งานเช่นกัน แต่กิจกรรมที่เราทำมักเป็นเช่นนี้
- พวกเราเขียนอีเมล
- พวกเราเข้าประชุม
- พวกเราจัดประชุม
- พวกเราเขียนแผน
- พวกเราแทรคงาน
- พวกเรายกหูโทรศัพท์
- พวกเราเขียนรายงาน
ดูเหมือน “ออน เดอะ จ๊อบ เทรนนิ่ง” ของเราไม่ค่อยมีส่วนไหนส่งเสริมให้เรามีความรู้ความเข้าใจในโปรดักท์มากขึ้นสักเท่าไร ทำไมเป็นอย่างนั้น ทำไมโปรเจ็กต์ เมเนเจอร์ถึงไม่ถูกผลักดัน (แกมบังคับ) ให้ต้องเข้าใจโปรดักท์อย่างถ่องแท้
บางคนกล่าวว่าเรารับผิดชอบภาพรวมเรื่องรายละเอียดทางเทคนิคนั้นไม่สำคัญขนาดนั้น นี่เป็นแนวคิดที่ไม่ถูกต้องหรือไม่? ไม่น่าจะใช่ … สาเหตุสำคัญก็เพราะโปรเจกต์ เมเนเจอร์ที่ดีต้องมองเห็นในสิ่งที่คนอื่นมองไม่เห็น การที่จะทำแบบนั้นได้เราต้องมีความรู้ทั้งแนวกว้างและลึก เราไม่สามารถพึ่งพาความคิดเห็นของคนอื่นได้ตลอดเวลา เราต้องสร้างความคิดและความเห็นของตัวเอง … เราจะทำแบบนั้นได้ก็ต่อเมื่อมีความรู้เท่านั้น
ดังนั้นสิ่งแรกที่โปรเจ็กต์ เมเนเจอร์น้องใหม่ (ถึงจะมีประสบการณ์แต่เปลี่ยนทีมก็เรียกว่าเป็นน้องใหม่เหมือนกัน) คือเข้าไปเรียนรู้และพยายามทำความเข้าใจตัวโปรดักท์ให้ได้มากที่สุดเท่าที่เวลาเอื้ออำนวย ถ้าเรามีเวลาส่งเมลเข้าประชุมเขียนรายงาน เราก็ต้องหาเวลาเพื่ออ่านเอกสารเกี่ยวกับระบบ ศึกษาแนวทางธุรกิจของโปรดักท์นี้ ลองเล่นลองใช้ลองทดสอบโปรดักท์นี้อย่างละเอียดด้วยเช่นกัน
นั่นคือจุดเริ่มต้นของการเป็นโปรเจกต์ เมเนเจอร์ที่ดี ถึงแม้จะมีคนกล่าวว่าโปรเจ็กต์ เมเนเจอร์มีหน้าที่ “บอกต่อ” คือใครพูดอะไรมาเราก็ไปพูดต่อให้คนใหญ่คนโตฟัง … ฟังดูแล้วไม่ค่อยน่าภูมิใจเท่าไร จริงมั้ย