- เมื่อนักพัฒนาพูดว่า No การรับมือกับเรื่องนี้จะช่วยให้คุณในฐานะผู้จัดการผลิตภัณฑ์สามารถยืนยันบทบาทของตัวเองและบรรลุเป้าหมายได้
- เมื่อมีการบอกว่าไม่สามารถพัฒนาฟีเจอร์ให้เสร็จภายในเวลาที่กำหนดได้เพราะเหตุผลทางเทคนิค การตั้งคำถามที่ถูกต้องอาจช่วยคลี่คลายสถานการณ์ได้
1. มีแนวทางแก้ปัญหาทางเทคนิคอื่นในการสร้างฟีเจอร์นี้ไหม?
- วิธีสร้างฟีเจอร์หนึ่ง ๆ มีได้หลายแบบ และวิธีแรกที่ลองไม่ใช่วิธีที่ดีที่สุดเสมอไป
- นักพัฒนามักอยากใช้เทคโนโลยีใหม่ล่าสุดเพื่อสร้างฟีเจอร์เจ๋ง ๆ แต่สิ่งนี้อาจนำไปสู่การทำวิศวกรรมเกินความจำเป็น มากกว่าการปรับให้เรียบง่าย
- นักพัฒนาที่มีชุดทักษะเฉพาะทางบางอย่างอาจมองไม่เห็นทางออกที่ง่ายกว่าซึ่งอยู่นอกขอบเขตความรู้ของตน
- ดังนั้นจึงเป็นเรื่องดีที่จะกระตุ้นให้วิศวกรคิดอย่างสร้างสรรค์มากขึ้นเกี่ยวกับโซลูชันทางเทคนิค
- ผู้จัดการผลิตภัณฑ์ที่เก่งที่สุดบางคนที่ฉันเคยร่วมงานด้วย มีทั้งมุมมองเชิงเทคนิคและความรู้เกี่ยวกับสภาพแวดล้อมทางเทคโนโลยีมากพอที่จะตั้งคำถามได้อย่างเฉียบคม ช่วยให้วิศวกรคิดนอกกรอบได้
2. ถ้าต้องเสนอวิธีแก้ภายใต้ข้อจำกัดเหล่านี้ คุณจะทำอย่างไร?
- หากนักพัฒนาตั้งข้อกังขากับวิธีแก้ที่คุณเสนอ ลองขอให้พวกเขาเสนอทางออกของตัวเอง
- นักพัฒนาเป็นแหล่งรวมของความคิดสร้างสรรค์และนวัตกรรม และการถามว่ามีฟีเจอร์เวอร์ชันที่ง่ายกว่านี้ไหม ก็เป็นการเปิดโอกาสให้พวกเขาได้คิดอย่างสร้างสรรค์
- เมื่อเข้าใจแก่นของปัญหาแล้ว นักพัฒนาจะสามารถคิดอย่างสร้างสรรค์และหาทางออกที่ใช้ได้ภายใต้ข้อจำกัดของโปรเจกต์
3. เราสามารถพิจารณาแนวทางแบบค่อยเป็นค่อยไปสำหรับฟีเจอร์นี้ได้ไหม?
- เมื่อมีการบอกว่าไม่สามารถพัฒนาฟีเจอร์ได้เพราะความซับซ้อนทางเทคนิค ให้ถามว่าสามารถแบ่งโปรเจกต์ออกเป็นหลายเฟสและจัดวางตามวันปล่อยแต่ละรอบได้หรือไม่
- แม้จะน่าดึงดูดใจที่จะส่งมอบวิสัยทัศน์ใหญ่ทั้งหมดในครั้งเดียว แต่วิธีแบบค่อยเป็นค่อยไปจะมีความเป็น iterative มากกว่า และส่งมอบผลลัพธ์ที่จับต้องได้เร็วกว่า
- ลำดับความสำคัญอาจเปลี่ยนแปลงได้ และแนวทางแบบค่อยเป็นค่อยไปช่วยให้คุณปรับร่วมกับนักพัฒนาได้ว่าควรเพิ่มฟีเจอร์อะไรต่อไป
4. เราสามารถขจัดหรือแก้ไขอุปสรรคอะไรได้บ้างเพื่อให้งานนี้เป็นไปได้?
- นี่เป็นคำถามสำหรับกรณีที่มีการคัดค้านเรื่องทรัพยากร โดยเมื่อนักพัฒนาอ้างถึงทรัพยากรที่จำกัด (เช่น เวลา หรือจำนวนนักพัฒนาที่พร้อมทำงาน) คุณก็ควรช่วยตัดงานบางอย่างออกอย่างจริงจังเพื่อคืนเวลาให้พวกเขา
- วิธีที่เป็นไปได้ ได้แก่ ตัดงานนั้นออกไปเลย, รับงานที่ไม่จำเป็นต้องใช้นักพัฒนาไปทำเอง, รับหน้าที่สื่อสารกับทีมอื่นและ/หรือบุคคลภายนอก, หรือทำให้งานง่ายขึ้นด้วยการเป็นเจ้าของกระบวนการและยุติฟีเจอร์ legacy
บทสรุป
- การ "ผลักดัน" เมื่อนักพัฒนาบอกว่า "ทำไม่ได้" อาจทำให้รู้สึกอึดอัด แต่สิ่งนี้อาจทำให้คุณได้รับความเคารพมากขึ้น
- คุณควรเจาะลึกลงไปอีกเล็กน้อยเพื่อทำความเข้าใจว่าทำไมวิศวกรจึงคัดค้าน แล้วค่อย ๆ ขจัดเหตุผลคัดค้านเหล่านั้นออกไปทีละข้อ
- คำถามเหล่านี้ล้วนเป็นคำถามที่ดี เพราะเป็นการยอมรับถึงความยากและข้อจำกัดเฉพาะที่วิศวกรอาจเผชิญเมื่อพัฒนาฟีเจอร์หนึ่ง ๆ
- อีกทั้งยังเป็นการแสดงให้เห็นอย่างชัดเจนว่าคุณพร้อมจะลงมือช่วยทีมและโปรเจกต์ด้วยตัวเอง ไม่ว่าจะเป็นการลุยงานยาก ๆ หรือการปรับให้เข้ากับข้อกำหนดและกำหนดการ
8 ความคิดเห็น
สุดท้ายก็ขึ้นอยู่กับว่าจะประสานกันอย่างไร
ขอบคุณสำหรับเนื้อหาดี ๆ
ถ้าถามด้วยประเด็นด้านบน ก็น่าจะคัดออกได้เร็วเลยว่าแท้จริงแล้วแค่ไม่อยากทำก็เลยตอบว่า "No"
ในฐานะ PM/PO ผมมีอยู่ 2 วิธีที่ช่วยได้ตอนทำหน้าที่ประสานงานระหว่างฝ่ายธุรกิจกับฝ่าย IT ในโปรเจกต์
แน่นอนว่ามีเงื่อนไขก่อนว่า ไม่ว่าจะเป็นฝ่ายธุรกิจหรือฝ่าย IT ต้อง "คุยกันรู้เรื่อง" ก่อน
อย่างแรกคือ ทำแบบเป็นขั้นตอน
อย่างที่สองคือ ลดขนาดงานลง
มีอยู่สองข้อนี้ครับ
อุปสรรคใหญ่ที่สุดในการเดินโปรเจกต์ของทั้งฝ่ายธุรกิจและฝ่าย IT คือเรื่อง "ระยะเวลา"
กำหนดเวลานั้นตายตัว แต่บ่อยครั้งปริมาณงานดูเหมือนจะทำไม่ทันภายในเวลานั้น
แบบนี้ต้องทำ "เป็นเฟส" เช่น phase 1, 2, 3.. ตามลำดับเวลา โดยเอาฟังก์ชันที่สำคัญที่สุดไว้ใน phase 1 และของที่สำคัญน้อยกว่าไว้ใน phase 2.. ประมาณนี้
แต่ถ้าเป็นโปรเจกต์ที่ทำแบบแบ่งเป็นขั้นตอนไม่ได้ คือจำเป็นต้องเปิดใช้ทีเดียวทั้งหมด
ก็ต้องลด "ขนาด" ให้พอดีกับ "ระยะเวลา" ครับ ต้องตัดทุกอย่างที่อยู่ใน phase 1, 2, 3 ทิ้งไปให้หมด ยกเว้น "ฟังก์ชันที่จำเป็นจริง ๆ"
ด้วยสองวิธีนี้ ถ้าเป็นฝ่ายธุรกิจ/ฝ่าย IT ที่ "คุยกันรู้เรื่อง" ส่วนใหญ่ก็จะเห็นด้วยครับ
เพราะยังไงก็ดีกว่าโปรเจกต์พังแล้วแต่ละคนต้องไปโดนหัวหน้าตัวเองตำหนิ..
เฮ้อ
ทุกคนสู้ ๆ นะครับ^^
PS:
มีเคล็ดลับปิดท้ายอีกอย่างครับ
ถึงจะใช้สองวิธีข้างต้นแล้ว นักพัฒนาหลายครั้งก็ยังแสดงท่าทีลำบากใจ
ตอนนั้นถ้าพูดว่า
"เดี๋ยวเรามาเช็กกันอีกครั้งช่วงกลางระยะเวลาโปรเจกต์นะครับ ถ้าดูแล้วน่าจะต้องใช้เวลาเพิ่ม ผมจะรับผิดชอบขอขยายเวลาให้เอง"
บ่อยครั้งสีหน้าของนักพัฒนาจะผ่อนคลายลง
แล้วพอเช็กกันช่วงกลางทาง ก็มีถึง 95% ที่สุดท้ายไม่จำเป็นต้องเพิ่มเวลา
อีกอย่าง พอนักพัฒนาเริ่มลงมือเขียนโค้ดแล้ว หลายครั้งก็มักทำได้เร็วครับ
ในฐานะคนที่ต้องทำงานประสานกับนักพัฒนา ก็อยากร่วมงานกับนักพัฒนาที่คุยกันแบบนี้ได้เหมือนกันนะครับ จนถึงตอนนี้เจอแต่นักพัฒนาที่บอกว่าไม่ได้เลยก็เลยรู้สึกเสียใจ พอลองค่อย ๆ เกลี้ยกล่อมและถามไปถามมา ส่วนใหญ่ก็มักจะเป็นกรณีที่เจ้าตัวไม่รู้วิธีที่ทำได้เองนั่นแหละ..
55555555 เจ็บจี๊ดที่อกเลย..
คำถามที่วิศวกรควรถามตัวเองก่อนจะพูดว่า "NO"
ดูเป็นคำถามที่ดีมาก ๆ ที่แม้แต่ผมเองก็ควรถามตัวเองเหมือนกัน
เพราะก่อนจะเป็นวิศวกร พวกเขาก็เป็นคนเหมือนกัน ผมเห็นด้วยว่าการติดนิสัยพูดว่า No ในฐานะวิศวกรเป็นปัญหา แต่ถ้าฝั่ง PM/PO มีคำถามแบบนั้นติดตัวไว้ ก็น่าจะช่วยได้มากครับ