สวัสดีค่ะ ครั้งนี้ พวกเราชาว PM Corner จะมาแชร์ประสบการณ์ในหัวข้อ Stakeholder Management จากงาน Panel Meetup Q3 ที่เพิ่งจัดไปเมื่อวันที่ 1 ตุลาคม 66 ที่ผ่านมา งานนี้ชาว PM Corner ตั้งใจจัดขึ้น เพื่อให้เหล่านักพัฒนา หรือ ชาว Community Product Management มาสนุกสนานกัน ในธีมแบบ Panel, Debate และ Focus Group Discussion
งานในวันนี้ เรายังได้ Speaker รุ่นพี่ตัวท๊อปวงการเทคไทย มาร่วมเสวนา และแชร์ประสบการ์ให้เหล่าน้อง ๆ รุ่นใหม่อีกด้วย นั่นคือ พี่รูฟ Software Stylist (roofimon) แถมยังเป็นตัวพ่อแห่งวงการ Agile coach จาก ODDs-E Thailand และพี่หนุ่ม Agile Software Development Experience Delivery (zyracuze) จากบริษัทสยามชำนาญกิจ
ซึ่งพี่ทั้งสองคนมีประสบการณ์พัฒนา software มายาวนานตั้งแต่ยุค 90’s โดยมีประสบการณ์ตั้งแต่การเตรียมตัว เก็บ requirement ก่อนที่จะทำซอฟแวร์ จน product ที่มาให้ทุกคนใช้งานกัน
สำหรับหัวข้อที่แชร์กันในวันนี้เริ่มต้นด้วยเรื่องของ “Expectation alignment” ศิลปะของการสื่อสารกับ stakeholder เราควรจะคุยยังไงให้เป็นภาพเดียวกัน และปฏิเสธเค้ายังไง เมื่อเค้าอยากได้ในสิ่งที่เรารู้สึกว่า อาจจะยังไม่จำเป็น หรือไม่ควรทำในตอนนี้
เทคนิคทำให้ stakeholder เห็นภาพเดียวกัน
- หาเครื่องมือมาช่วยในการ visualize ให้ stakeholder เห็นภาพอย่างชัดเจน
เพราะคำพูดลอยๆ อย่างเดียว ภาพในหัวคนฟังแต่ละคน อาจไม่เหมือนกัน การมี Model หลายๆ ตัวในเชิงของ Business เช่น Process Model, Data Model, Logic Model, Design Model, Operation Model และ Financial Model มารวมกันให้เค้าเห็นภาพในหลาย ๆ มุมมอง
เลือกใช้ให้ถูกอัน และถูกเวลา เพื่อการตัดสินใจในสิ่งที่สำคัญ จะช่วยให้ทีมเห็นภาพตรงกัน ดีกว่าปล่อยให้การสื่อสารที่ไม่ชัดเจน นำไปสู่การออกมาเป็นของลอย ๆ ที่ stakeholder ไม่ได้อยากได้ - ออกจากห้องประชุม
พา stakeholder ไปดูหน้างานจริง เพื่อให้เห็น context จริงๆ และรู้ว่าปัญหามีอยู่ตรงไหน เช่น ลงพื้นที่สำรวจ ทำ prototype แล้วทำสรุปให้เห็นภาพ ว่าใช่สิ่งที่ตอบโจทย์มั้ย ซึ่งบางคนอาจจะมองว่า ไม่จำเป็น จริงๆ แล้วถ้าเทียบกับ cost ในการ dev ของที่คนไม่ต้องการ ก็นับว่าคุ้มค่ามากๆ
ยกตัวอย่างให้เห็นภาพ
Product A : เอา presentation จากทีม business (screenshot หน้าแอปของคู่แข่ง) มาให้ dev ดู.
ปัญหาคือ (1) context ไม่เพียงพอ (2) ไม่ได้เช็คกับ user เลย
Product B : ต้องการมี digital solution สำหรับคนในตลาด team product B เอาทั้ง PO, QA, ผู้จัดการสาขา ลงไปดูว่าพ่อค้าแม่ค้าในตลาดทำงานกันอย่างไร, ทีม B ได้เห็นปัญหามากกว่า 50 อย่าง, ได้ prototype solution อาจดูเหมือนเป็นการลงทุนจำนวนมาก แต่จริงๆ แล้วเป็นแค่เศษเสี้ยวของ development cost ทั้งหมด
ปฏิเสธ Stakeholder อย่างไร ให้ยังรักษา Relationship ที่ดี
Product Manager ที่ดีไม่ควรพูดคำว่า “ไม่” ควรพูดคำว่า
จาก “Constraint” ที่มี ที่คุ้มที่สุดคืออะไร? ควรจะ…
หรือ ด้วยข้อจำกัดเหล่านี้ คุ้มที่สุด ที่พี่ควรจะได้ คือ อะไร ?
หรือ ด้วยข้อจำกัดที่เรามีในตอนนี้ เราสามารถไปได้เท่านี้นะ !!!
หลายคนอาจสงสัยว่า แล้วเราจะมองหา hidden agenda ของ stakeholder ยังไง ต้องเตรียมตัวอย่างไรให้รู้ทันเกม อ่านเกมในวงประชุมยังไงได้บ้าง พี่รูฟและพี่หนุ่มก็ได้แชร์เทคนิคมาหลายข้อเลย
- เลือกวิธีการสื่อสารให้เหมาะกับคนดู Personal Type ของคน โดยการสื่อสารบางแบบ อาจจะไม่ได้เหมาะกับทุกคน เพราะคนมีวิธีคิดที่แตกต่างกัน ดังนั้น จึงมี preference และความถนัดในการรับสารที่แตกต่างกันเช่นกัน เช่น บางคนชอบดีเทล, บางคนต้องการ data ประกอบ, บางคนเป็นคน result oriented ชอบให้เอา result ขึ้นมาก่อน ไม่ต้องอารัมภบทเยอะ อาจจะใช้ Data มาช่วยในการอธิบาย จะ win มากกว่า, บางคนเน้นเรื่องคน อารมณ์ ความรู้สึก
“เรื่องเดียวกัน ต่างคนฟัง มีวิธีการพูดที่เหมาะสม ไม่เหมือนกัน”
ทั้งนี้ ยังมี Framework ต่างๆ ที่สามารถช่วยวิเคราะห์ Personality เช่น DISC, Enneagram, 4 types of animals ลองไปศึกษาเพิ่มเติมกันได้
- ไม่ facilitate เฉยๆ แต่เสนอ option
นอกจากเข้าใจใน Personality ของแต่ละคนแล้ว ให้เราเลือก option ที่คิดว่าดีที่สุด ภายใต้ความเข้าใจที่มี อย่าพยายาม Facilitate เพียงอย่างเดียว เพื่อรอการตัดสินใจ แต่เราต้อง suggest หรือ มี option ให้เลือก
เช่น “เราคิดว่า จากความเข้าใจทั้งหมดที่แชร์กันมา เราแนะนำว่าแบบนี้” โดยมี 3 ตัวเลือก พร้อม Benefit ของแต่ละตัวเลือกที่อธิบายอย่างชัดเจนให้คนเลือก
“Product Manager ที่ดี ไม่ควรทำแค่ Facilitate แต่ควรให้ Suggestion ด้วย เพราะเราถือ Product Ownership
- หาว่าใครเป็น decision maker
ถ้ามี Stakeholder หลายคนต้องหาให้ได้ว่าใครคือ ผู้ตัดสินใจสูงสุด โดยการทำ relationship map (อาจจะต้องใช้เวลาหน่อย) หรือคุยกับคนที่อยู่มาก่อน
การคุยกับ decision maker ก่อนเข้า meeting เพื่อขอ buy-in ก่อน จะช่วยให้เราสามารถสรุปสิ่งที่จะทำได้ โดยไม่ล่องลอย และได้ลงมือทำงานเร็วที่สุดเท่าที่จะเป็นไปได้
แต่ถ้าเรายังอายุน้อย อาจจะลองวิธีการใช้ปากคนอื่น หรือยืมคนอื่นมาพูดแทน
- อย่าพยายามไป recommend ทันที ตั้งแต่ day 1 (เพราะเราอาจยังไม่เข้าใจ context มากพอ)
ถ้าเราเข้าไป join บริษัททีหลัง หรือเข้าไปเป็นพนักงานใหม่ แต่ให้เราเข้าไปอยู่ตรง center ตรงตาของพายุ หรือท่ามกลางพายุก่อน เพื่อซึมซับสถานการณ์ในบริษัทก่อน เกณฑ์ context ให้มากพอก่อน ค่อยไป solve
ดูว่าเรื่องอะไรสำคัญที่สุด ค่อยๆ prioritize หยิบเรื่องสำคัญมาทำก่อน เริ่มจาก low hanging ที่ effort น้อยๆ impact เยอะๆ
ถ้า stakeholder หัวดื้อ ไม่สามารถ convince ด้วยเหตุและผลได้ ควรจะจัดการอย่างไรดี
- ใช้ data คุย, อธิบายให้ชัดเจน, จำลองสถานการณ์ข้างหน้า 1-2 เดือน และอย่าลืม track ผลลัพธ์ หรือ KPI
- ทำทางเลือก options และความเสี่ยง risk ของแต่ละตัว ชั่งน้ำหนักข้อดีข้อเสีย ทำหน้าที่เร่งปฏิกิริยา ให้เห็นว่ามันล้มแล้วขยี้ด้วย data เพื่อให้เห็นภาพ
- ถ้าเจอ stakeholder ที่ดื้อด้วย hidden agenda และยืนยันจะไปทางนั้น ก็พูดตรงๆ กับเขา ประมาณว่า เราสามารถทำแบบนั้นให้ได้ แต่ถ้าเกิดอะไรขึ้นมาในอนาคต เขาจะต้องยินยอมที่จะรับในผลของมันนะ
- ถ้าเจอ stakeholder ที่ดื้อเพราะไม่ชอบเพราะตัวเรา ก็ต้องทำใจ แล้วหาเพื่อนที่ไปคุยกับเขาแล้วเค้าไม่หงุดหงิดแทน
- ถ้าเป็นเรื่อง Principle การแก้ไขปัญหา ประกอบไปด้วย 2 ส่วน คือ แก้อะไร (What) และ แก้อย่างไร (How)
ให้ make sure ก่อนว่าเรากำลังพยายามแก้สิ่งเดียวกัน (ไปที่ What ก่อน) ก่อนจะไปเถียงกันว่าจะทำอย่างไร
- ถ้า stakeholder เป็นคนในยุค baby boomer ต้องหาอะไรที่เป็น gap ระหว่างกันมาเสริมเพื่อสร้าง trust ที่มากขึ้น หรือบางทีเขาอาจจะเพียงแค่ ต้องการจะ challenge เราก็ได้
เราควรพูด หรือ ไม่ควรพูดกับคนดื้อ?
- ถ้าเป็นคนนอก พูดได้เลย เราไม่มีอะไรจะเสียอยู่แล้ว เขาอยากได้ความเห็นจากเราด้วย
- ถ้าคนใน อาจจะยาก หากไม่สามารถรับความเสี่ยงได้ แต่ในทางตรงกันข้าม การกล้าพูด กล้าแสดงความคิดเห็น ในฐานะคนใน ก็สามารถพาเราไปไกล เติบโตในหน้าที่การงานได้เลย เพราะฉะนั้น ความเห็นที่แตกต่าง มีคุณค่ามาก
ท้ายนี้ พี่รูฟยังมี key take away ว่า “คนที่ก้าวหน้า คือ คนที่ take risk เสมอ”
- วิธีการ handle ความแตกต่างระหว่าง multi generation ทำอย่างไร อะไรคือกลยุทธมัดใจ stakeholder
- ควรจะมีคนกลาง ที่ช่วงวัยใกล้ๆกันกับเรา ให้เค้าเป็นตัวกลางในการไปพูดคุยสื่อสารต่อ แทนที่เราจะไปคุยเองโดยตรง
- พยายามหาทุก Generation มาอยู่รอบตัวให้ได้ แล้วศึกษาว่าแต่ละ Gen เป็นยังไง มี Type ยังไง
- อาจจะหาที่ปรึกษาฝั่ง People Team มาช่วย เพราะเค้าจะมีวิธีรับมือกับคนหลายๆ Gen
- ควรเขียนเยอะๆ มีการเขียนถึงกัน แทนการพูด เช่น เขียนใน Wiki ของบริษัท/ ใช้ ChatGPT ช่วยในการปรับคำให้เหมาะสมกับคนรุ่นนั้นๆ แต่จะต้อง Set up ดีๆ ถ้าสงสัยอะไรให้ comment ไว้ และพยายามใช้ Emoticon เช่น แบบนี้ “🥺” เพื่อให้ดูซอฟท์ลง
- ถ้ามีการทำงานร่วมกับทีมอื่น ๆ และต้องการ gain trust หรือสร้าง desired behavior ปรับพฤติกรรมการทำงานกับคนต่างทีมให้เข้ากัน ควรทำอย่างไร เช่น Developer, QA, etc.
- ถ้าเป็นทีม Developer หรือ Programer ที่ไม่เคยทำงานด้วยกันมาก่อน ให้ชวนไปกินข้าวสังสรรค์ หรือดื่ม เพื่อละลายพฤติกรรม
*** ขอ disclaimer ว่า “ไม่ใช่ทุกคนนะจ๊ะ” 🙂***
- มีกิจกรรม Social programmer ตอนเช้าด้วยกัน เช่น การทำ coding dojo เขียน code ด้วยกันวันละ 1 ชม. หรือที่เรียกอีกอย่างว่า “pair programming”
- ทำข้อตกลง หรือข้อบังคับ (สำหรับสายโหด) แต่จะต้องมีคำอธิบายประกอบเพื่อ maintain relationship ในอนาคต โดยทำซ้ำบ่อย ๆ เพื่อให้ทีมมี mindset ที่ align กัน จนเกิดเป็น culture
- ทำ document ไว้ มี onboarding process ดี ๆ ซึ่งจะดีกว่า การทำ on the job training (ซึ่งมัน obsolete ไปแล้ว)
วิธีการ onboarding คนใหม่ ๆ เข้าทีม
- ให้เวลาศึกษาทำความเข้าใจบริษัทอ่าน document ก่อน 1 เดือน
- เข้าใจ culture / business
- On site ดูหน้างาน จะช่วยให้เข้าใจ flow
- พาเค้าไปลองเล่น product และหา issues
- รู้ความเสี่ยง Risk
เพราะ คนทำงานเอง ก็มีประสบการณ์ที่ผ่านมาแตกต่างกันเหมือนกัน แม้จะบอกว่าเป็น professionals เหมือนกัน แต่เมื่อเข้าทำงานที่ใหม่ ต้องมีเรื่องที่แตกต่างกันอยู่แล้ว
Process ที่ดี ควรจะมีเวลาให้พนักงานใหม่ ได้ศึกษาวิธีการทำงานกันภายในบริษัท เช่น ใน 1 เดือนแรก ให้พนักงานใหม่ อ่าน document ภายใน + ลองใช้ product ทำความเข้าใจระบบที่เขากำลังจะเข้ามาทำงานก่อน ยกตัวอย่างเช่น บริษัท e-commerce แต่พนักงานไม่เคยซื้อของออนไลน์เลย ที่ Rakuten ก็จะมีงบให้พนักงาน นำเงินไปทดลองซื้อของผ่าน platform เพื่อให้รู้จักและเข้าใจ product จริงๆ หรือธุรกิจบ่อกุ้ง ก็ให้พนักงานไปบ่อกุ้ง ไปเรียนรู้ ไปเห็นหน้างานที่บ่อกุ้งจริงๆ
— document document document: เนื่องจาก พนักงานคนหนึ่งอาจไม่ได้อยู่ที่เดียวไปตลอดชีวต ระบบ documentation ที่ดี ช่วยให้คนข้างหลังที่มา ทำงานต่อได้ง่าย รวมถึงทำให้การกระจายข้อมูลทำได้ง่ายอีกด้วย
- วิธีการสังเกตผู้บริหาร และองค์กร ที่เหมาะกับการทำงานกับเรา
พี่ ๆ ให้ความเห็นว่า องค์กร ที่เหมาะที่เราจะไปทำงานด้วย ให้ดูจาก reaction ของคนทำงานในองค์กรนั้น เค้ากล้าชวนเราไปทำงานด้วยกันมั้ย กับ ตัวเราเอง มีเป้าหมายอย่างไร ปลายทางอยากไปสุดที่จุดไหน เราอยากจะได้อะไรกับมาจากที่ที่เราจะไป เช่น คิดว่า เราอยากจะอยู่ที่นี่ สัก 5 ปี เพื่อสิ่งไหน และอยากไปยังไงต่อ ดูว่าที่ที่จะไปสามารถตอบโจทย์ Goal ของเราได้ด้วยหรือไม่
ทั้งนี้ พี่ ๆ ยังเสริมในมุมของความเป็น Product Manager ที่ดี
- คิดของใหม่ ไอเดียใหม่ ๆ
- กลับไปแก้ของเก่า ทำที่มีอยู่ให้มันดีขึ้น เอา features ที่ไม่ได้ใช้ออก (ทำให้ OPEX (operation term) ลดลง)
ให้มองในมุมที่ว่ามีคนเท่านี้ กำลังการผลิตมีเท่าไหร่ เพื่อให้ได้ของที่ดีขึ้น สามารถเพิ่ม retention เพื่อให้ลูกค้าอยู่กับเรา เร็วที่สุด เราควรทยอยเอาของออก (release features or publish) ในทุก ๆ week เพื่อให้คนที่อยู่ตรงนั้นเค้าเห็นสิ่งที่เกิดขึ้น เกิดความเปลี่ยนแปลง
PM ที่ดีควรมีตัวชี้วัดทางธุรกิจมาวัดผลเสมอ ๆ
1. วัดเพื่อเห็น progress ตัวเอง
2. วัดเพื่อให้ business user ดู
อาจจะใช้ DORA Metrics มาเป็นตัวช่วย อีกทางคือ มองในมุม business เพื่อหาตัวชี้วัด เช่น ถ้าเน้นไปทำหลังบ้าน แล้วสิ่งที่ทำคือ improve stalability ลองวัดว่าในมุม business การลดระยะเวลาใน flow จาก 1 นาที เหลือ 30 วินาที ทำให้มีเงินไหลเข้ามาเพิ่มเท่าไหร่
หลังจาก Session ที่ Speaker ของเราทั้ง 2 คนแชร์ความรู้และประสบการณ์ ก็ได้มีการ Debate ระหว่างกัน แต่จะมีคำถามอะไรบ้างนั้น สามารถติดตามได้ในบทความถัดไปนะคะ…
หากคุณชอบคอนเทนท์นี้ อย่าลืมกดไลก์ กดแบ่งปันให้เพื่อนๆ หรือคอมเมนต์กับพวกเราได้นะคะ และสามารถติดตาม content update ใหม่ๆ จาก pmcorner ได้จาก Facebook Page: PM Corner Thailand ได้เลยนะคะ 😀
Writer: Beaubaby
Note taker: Chakrik Thaviyonchai
Editor: Onaraya Chen
