My background, a bit
ผมเป็น Software Engineer คนหนึ่ง ที่เคยทำงานกับ Product Owners, Product Managers (แม้กระทั่ง Project Managers) มาหลากหลายรูปแบบ (อ่านข้อแตกต่างได้ ที่นี่) ทั้งในงานประจำ และงานนอกเวลา ตั้งแต่สมัยที่ผมยังเป็น Junior จนตอนนี้ได้มีโอกาสมาดูแล Development team เต็ม ๆ แล้ว
ผมคิดว่าตัวเองค่อนข้างแตกต่างจาก Software Engineer คนอื่น ๆ ส่วนใหญ่ ตรงที่ผมไม่ได้มองว่าตัวเองเป็นคนที่ Very Tech Savvy หรือ Very Technical แต่ผมจะค่อนข้างชอบ Elements ของ User Experience และการทำ Product โดยรวมมากกว่า แม้จะยังไม่ได้เคยลงมือทำจริง ๆ จัง ๆ แต่ค่อนข้างมั่นใจว่า ผมเข้าใจ challenges ที่คนใน Role ของ Product ต้องเจอเป็นส่วนใหญ่
บริษัทที่ผมทำงานอยู่ ตอนนี้เป็น Ride-Sharing Platform แห่งหนึ่ง ซึ่งผ่านการปรับ Process และ Re-organization มาหลายรอบ ผมได้รู้จักและทำงานร่วมกับคนที่อยู่ใน Role ของ Product (หลัก ๆ คือ Product Owners) มาหลายคน แต่ละคนก็มีแนวทางการทำงานแตกต่างกันไป และแน่นอนว่า มี Impact กับ Output ของทีมโดยตรงทั้งนั้น
วันนี้ผมจะมาแชร์ให้ฟังว่า ในฐานะของ Engineer ที่ดูแลทีม เราชอบ Product Manager หรือ Product Owner ที่มีลักษณะแบบไหน ด้วยเหตุผลอะไรบ้าง (ซึ่งแน่นอนว่าพวกนี้เป็นความเห็นส่วนตัวครับ อาจจะ bias เข้าหาความที่อยากให้ตัวเองทำงานง่ายก็ได้นะ)
#1 – Be the same team with us
Product Manager หลาย ๆ คน มักบอกว่า ตัวเอง “Work Closely” กับ Development team อยู่แล้ว แต่สำหรับผม ความรู้สึกของการเป็นทีมเดียวกัน มันมี elements เล็ก ๆ เยอะมาก ที่ไม่ใช่แค่ว่ามี check list 1 2 3 4 ที่ check ทุกข้อ แล้ว จะแปลว่าเราเป็นทีมเดียวกันแล้ว
มันเหมือนจะเป็นความรู้สึกภายในมากกว่า ว่าเรามารวมตัวกันทำอะไรด้วยกัน ถ้ามีจังหวะเวลาที่ยากลำบาก เราไม่ได้แบ่งว่าเป็นฉันเป็นเธอ บางสิ่งที่ผมสังเกตได้จาก PM ที่ผมรู้สึกว่าเป็นทีมเดียวกับเขา ยกตัวอย่างได้ดังต่อไปนี้
- ตอนที่ทีม Standup Meeting PM คนนั้น ไม่ได้แค่มาเข้าร่วมในฐานะ Observer แต่เป็นหนึ่งในคนที่พูด update ด้วย ใน format เดียวกัน – เราก็อยากรู้นะว่าตอนนี้มีอะไรสำคัญอยู่ มีอะไรที่เราช่วยคิดได้มั้ย
- เวลาที่เกิดปัญหาเร่งด่วน แล้วเรา ทีม Engineer เรียกรวมตัวกัน PM จะ Join เข้ามาด้วยเสมอ และแบ่งเบาบางหน้าที่ที่เขาทำได้ในตอนนั้นไปจากพวกเรา เช่น ช่วย communicate กับทีมอื่น ๆ แบบ real-time เพื่อให้พวกเราได้โฟกัสในการแก้ปัญหา (เพราะนั่นเป็นสิ่งที่เราควรจะทำได้ดี และทุกวินาทีมีค่า)
- เมื่อมีอะไรที่ต้องตัดสินใจ ถ้ามีเวลา PM จะมาปรึกษากับทีมก่อนเสมอ แม้ว่าอาจจะมีคำตอบในใจอยู่แล้ว หรือว่า “ตัดสินใจไปก่อนแล้ว เพราะข้อจำกัดด้านเวลา หรือสถานการณ์” PM ก็จะมาอธิบายกับทีม ว่าสาเหตุที่ตัดสินใจแบบนี้ ๆ เพราะว่าอะไร
#2 – We trust each other
ผมคิดว่าความเชื่อใจมันเป็นสิ่งที่ต้อง Build up ขึ้นมา
ถ้าเราไม่รู้จักคนนั้นเลย เราอาจเชื่อเขาจาก Experience & Knowledge & Skills ที่เราเชื่อว่าเขามี
และสิ่งเหล่านี้ก็จะเพิ่มขึ้นหรือลดลงตาม Actions และ Consequences ที่คนคนนั้นแสดงออกมา
แม้ว่าเราจะผ่านข้อ 1 มาแล้ว ว่าเราเป็นทีมเดียวกัน บางครั้งเราอาจจะไม่ Trust กันก็ได้ เช่น PM อาจจะรู้อยู่แล้วว่า Dev บางคนในทีมชอบ Over-commit ก็อาจจะรู้สึกไม่เชื่อใจ ถ้าคนคนนั้นได้รับงานที่สำคัญไปทำ
ผมคิดว่า ถ้าเรายอมรับกันว่าแต่ละคนก็มี Traits ของตัวเอง เราควรจะยอมรับใน Traits ที่เราไม่ชอบในอีกฝ่าย และหาวิธี Manage มัน ให้ทำงานร่วมกันได้
ซึ่งวิธีนึงที่หลาย ๆ คนอาจจะเลี่ยงที่จะทำ แต่สำหรับผม มัน Always work คือ Be Honest / Be Transparent
ถ้า Dev ชอบ Over-commit ก็ต้อง Feedback กับเขาโดยตรง โดยอธิบายไปด้วยว่าผลที่เกิดขึ้นกับทีม ถ้าเขา Over-commit คืออะไรบ้าง
และการจะ Gain Trust ได้ เราก็ต้อง Trust อีกฝ่ายด้วย (อย่างน้อยก็แสดงออกมาแบบนั้น แม้ในใจจะหวั่น ๆ ก็ตาม) ดังนั้นในกรณีนี้ผมว่า เราควรส่งงานสำคัญให้เขาต่อไป แต่ Monitor closely และนึก ๆ แผนสำรองไว้ พร้อมกับเข้าไปจัดการให้ถูกจังหวะ เช่น ส่งไปให้อีกคนทำ ในจังหวะเวลาที่อีกคนยังทำทัน และตัวเขา Aware แล้ว ว่า เขา Over commit แล้วจริง ๆ
#3 – Great representation of Users / Stakeholders
แน่นอนว่า โดย Nature ของทีม Development ก็อาจจะไม่ได้ใช้เวลากับ Users / Stakeholders มากเท่ากับ Product Manager หรอก ดังนั้นการที่ PM เป็นส่วนหนึ่งของทีมเรา ก็คือเราอยากให้ PM ออกความเห็น หรือแชร์ข้อมูลในมุมมองของ Users / Stakeholders ที่พวกเราอาจจะมองข้ามไปก็ได้
PM ที่ผมเคยทำงานด้วย มีคนที่ Represent users ได้ดี ระหว่างที่เรา Discuss solutions กัน หากมีส่วนที่จะเพิ่มปัญหาให้ Users เขาก็สามารถ Voice ขึ้นมาได้ทันที
แน่นอนว่า ถ้าเราผ่านข้อ 1 คือความเป็นทีมเดียวกัน และข้อ 2 คือเราเชื่อใจกันแล้ว เราก็จะ Accept input ที่ Voice ขึ้นมาได้ทันที และเราก็จะพยายามปรับ solutions ที่คิดกันโดยคำนึงถึงเรื่องนั้นอยู่ด้วย
แล้วโดยส่วนใหญ่ ถ้า Engineer เข้าใจว่า สิ่งที่เขาต้องใช้พลังงานทำเพิ่ม มันจะช่วยให้ Users ใช้ชีวิตดีขึ้นยังไง เขาก็จะรู้สึกว่ามีแรงบันดาลใจที่จะทำมากขึ้นด้วย
#4 – Be sharp while prioritizing
ผมคิดว่าเป็นเรื่องปกติของเกือบทุก ๆ บริษัท ที่เรามี Workload > Workforce
ดังนั้นสิ่งที่พวกเราต้องเจอเสมอคือ การ “เลือกสิ่งที่จะต้องทำ”
บ่อยครั้งที่ความเห็นของเราแต่ละคนไม่ตรงกัน
Engineer อาจจะอยาก Clear technical debts
Marketing ก็อยากจะรีบปั้นยอด
Operations ก็อยากให้ลด Manual process
ทุกคนก็อาจจะหันหน้ามาหา Product Manager ที่อยู่ตรงกลาง ให้เป็นคนตัดสินใจ
ต่อเนื่องจากข้อที่แล้ว นอกจาก Development team จะไม่ได้ใช้เวลากับ Users / Stakeholders มากเท่า PM แล้ว เราอาจจะยังไม่ได้เห็นภาพรวม (Overview) ของ Product มากเท่า PM ด้วย และการตัดสินใจเลือก “สิ่งที่จะต้องทำ” ของ PM ก็อาจจะขัดกับความเห็นของพวกเรา
ถ้าเราผ่าน 3 ข้อแรก ทั้งการเป็นทีมเดียวกัน การเชื่อใจกัน และ PM ได้แสดงให้เห็นแล้วว่าเป็นตัวแทนที่ดีของ Users / Stakeholders ได้ เวลาที่ PM ตัดสินใจ Prioritize บางอย่างที่ขัดกับความเห็นของเรา แบบไม่มีเหตุผลที่ดีพอ เราอาจจะไปดึง Trust Level มาใช้ ทำให้ลดลง
แต่ถ้า PM สามารถอธิบายเหตุผลที่ Convince ทีมได้ แน่นอนว่าทีมเองก็จะพร้อมทำด้วยเช่นกัน
#5 – Can balance the mood and tone
เป็นเรื่องปกติของชีวิตการทำงาน ที่มันจะมีช่วงเร่ง ช่วงผ่อน ช่วงตกใจ เข้ามาบ้าง
และก็เป็นเรื่องปกติเช่นกันที่ Users / Stakeholders บางคน อาจจะส่งปัญหาเข้ามาหา PM แบบ Full of Emotion บางอย่าง (ส่วนใหญ่จะเป็นในเชิงลบมาก ๆ)
PM ที่ผมชอบ เขาเป็นเหมือน Barrier ที่จะคอยคัดกรองอารมณ์พวกนี้ออกไป จนเหลือแต่ Fact และส่งต่อให้กับ Development team ให้หาสาเหตุแก้ไขต่อไป
และแน่นอน บางอย่างเป็นเรื่องเร่งด่วนจริง ๆ เช่น Users ไม่สามารถใช้ Core features ได้ “80%” ในตอนนี้
ถ้า PM ส่งต่อเรื่องนี้เข้ามาที่ทีมแล้ว ทีมยังคงไม่ได้ Respond แบบเร่งด่วนอย่างที่ควรเป็น ก็ Fair นะที่จะกระทุ้งหน่อย เพื่อให้แน่ใจว่าความ Urgency มันได้ส่งต่อไปถึงแล้วจริง ๆ
#6 – Be on every phases, not just only beginning & end
ผมเข้าใจดีว่า PM เองก็มีงานส่วนอื่นที่ต้องทำ นอกเหนือจากการมาโฟกัสกับส่วน Delivery และงานเหล่านั้นก็สำคัญมาก ๆ ด้วย เพราะเป็นการมองไปในอนาคต และกำหนดทิศทางของ Product
แต่ว่า Development team ก็ล้วนประกอบด้วยคนหลาย ๆ คน และแต่ละคนก็มีเจตจำนงค์อิสระทั้งนั้น แม้ว่าทีมจะเป็นระบบระเบียบแค่ไหน ยังไงมันก็จะมีหลุดอะไรบางอย่าง ถ้าไม่มีใครคอยมาเคาะ ๆ ให้เข้าที่เข้าทาง
บางคนอาจจะรู้สึกว่าข้อนี้ขัด ๆ กับคำว่า Trust ในข้อ 2 เพราะมันจะดูเหมือน Micromanage มั้ย ถ้ามัวแต่มาอยู่ “คุม” ตลอด ทุก stage
ผมคิดว่า การ Manage คน หรือทีม มันมี Sweet spot ของการ Give guidance, Observe, Step in อยู่ และแต่ละทีม ก็แตกต่างกันไปหมด ซึ่งถ้าเราใช้เวลาร่วมกันมาก ๆ จนรู้สึกเป็นทีมเดียวกัน (กลับไปข้อ 1) เราจะเริ่มเห็น Sweet spot นั้นขึ้นมาได้เอง
และการ Step in บางครั้งก็ไม่ได้หมายถึงว่าลงไปจัดการ ลงไปแก้ บางทีก็เป็นการให้ Feedback หรือ Approval ในจังหวะที่เหมาะสมด้วย
ยกตัวอย่างเช่น เรากำลังทำฟีเจอร์ที่จะ Display ข้อความบางอย่างให้ Users ดู แล้วในระหว่างที่กำลังทำอยู่ Engineer อาจจะสงสัยว่า แล้วถ้าเงื่อนไขปัจจุบันเปลี่ยนไปแล้ว ไม่ตรงกับข้อความนั้นแล้ว เราควรแสดงค้างไว้ หรือควรปิดไป
พวกนี้ ถ้าทำงานละเอียด ๆ ก็อาจจะเคลียร์กันเสร็จตั้งแต่ก่อนเริ่มทำแล้ว แต่ยังไงเราก็จะเจอเรื่องจุกจิก ๆ พวกนี้เสมอแหละ
ถ้า Product Manager อยู่ในระหว่าง Development ด้วย ก็จะสามารถให้ Input ในฐานะ Users ได้เลย ซึ่งก็จะทำให้ทุกคนเข้าใจไปในภาพเดียวกัน และลดโอกาสที่จะต้องมาแก้ใหม่ด้วย
ส่งท้ายจากผู้เขียน
ขอบคุณทุกคนที่เข้ามาอ่านบทความนี้ครับ หวังว่าความเห็นของผมจะเป็นประโยชน์กับ PM / PO ที่อาจจะกำลังต้องการ Insights ในการทำงานร่วมกัน จากคนที่อยู่ในฐานะ Software Engineer แต่ทั้งนี้ทั้งนั้นแล้ว ทีมของผู้อ่าน ก็อาจจะมี Preferences ที่แตกต่างจากที่ผมแชร์ก็ได้
สุดท้ายแล้ว Key Takeaways ที่สำคัญที่สุดก็คงจะเป็น Be the same team ซึ่งก็คือข้อแรกนั่นเองครับ
และหากคุณชอบคอนเทนต์นี้ และอยากฟังเรื่องราวจาก Product People คนอื่น ๆ เพิ่มเติม อย่าลืมกดติดตาม PM Corner ผ่านช่องทางดังต่อไปนี้ได้เลย
- Facebook Page: PM Corner Thailand
- Website: PM Corner
- Youtube: https://www.youtube.com/@pmcornerthailand (สำหรับรับชม live ย้อนหลัง)
