Q-CHANG PD Series — — EP1 ระบบการทำงานที่ต้องถูกสะท้อน ตกผลึก และเปลี่ยนแปลงร่วมกัน — Workshop Product Development Way of Work

บางอย่างที่ดีอยู่แล้วในมุมมองเรา จะมาเปลี่ยนทำไม?

ทำไมต้องมีการเปลี่ยนแปลง? และถ้าเปลี่ยนแล้วจะรู้ได้ยังไงว่ามันจะดีขึ้นนะ?

— — — — — —

ฉันคือใคร พวกเราคือใคร

สวัสดีค่ะ ชื่อโอปอล์ ทำงานที่คิวช่างมาสักพักใน role ที่ทำหน้าที่ขุนและบุ๋น product cross functional team ให้ทำงาน deliver product ให้มีประสิทธิภาพและมีคุณภาพสูงสุด และนั่นคือตำแหน่ง ”Senior Delivery Manager” นั่นเอง และก็เป็นหนึ่งใน product development leads ด้วยค่ะ

ว่าแต่ทีมที่ชื่อว่า Product Development นี่คิวช่างพวกเขาทำอะไรกันนะ? พวกเราทำหน้าที่ สร้าง products and services ที่ serve business needs มีทั้งทีมสร้าง B2B products, B2C products, Internal ERP system เป็นทีมที่รวมชาว Tech and digital product builders อยู่ในนี้ บางบริษัทคงเรียกว่า ทีม Tech หรือ ทีม Product ก็ได้

ทีม Product Development (PD) ของพวกเราที่คิวช่างประกอบไปด้วยใครบ้าง?

• Product Owners
• Delivery Managers
• Business Analysts
• UX/UI Designers, UX Writers
• Developers (Backend, Frontend, Full-stack, Infrastructure, and DevOps)
• QAs
• PD Leads

จุดเริ่มต้นของการเปลี่ยนแปลง มักเริ่มจากการ Observe

ช่วงแรกๆ เราเข้ามาช่วย observe the current way of work ของทีมที่นี่ ทำมาเกือบๆเดือนก็เห็นการทำงานบางส่วนนั้น potentially เสี่ยงต่อความสุขในการทำงานของพนักงาน เลยเกิดไอเดียและคุยกับเหล่า leads ด้วยกันเอง

“เรามาทำ workshop กันเถอะ เพราะเราไม่อยากเปลี่ยนการทำงานของทั้งทีมคนเดียว แต่อยากให้ทีมทุกคนมีส่วนร่วมในการสร้างการเปลี่ยนแปลงนี้ไปด้วยกัน พวกเขาจะได้รู้สึกว่าเสียงของพวกเขามีความหมายในการสร้างสิ่งที่ดีขึ้นให้กับการทำงานของพวกเขาเอง“

ทำไมถึงอยากเขียนสิ่งนี้? เราว่าพนักงาน PD ทุกคนเป็นฟันเฟืองขนาดเล็กและใหญ่ที่สำคัญพอๆกัน ในการขับเคลื่อนธุรกิจให้เดินไปข้างหน้าตามทิศทางที่อยากไป และเราอยากให้ทุกคนเห็น facts ว่า งานที่ทำให้คนทำงานได้แสดงศักยภาพได้เต็มประสิทธิภาพและเกิด productivity สูงสุด คืองานที่ดี คืองานที่สนุก

ซึ่งสิ่งนี้ประกอบไปด้วยหลายอย่างมาก แต่ที่สำคัญอันดับต้นๆเลยคือ process แปลเป็นไทยคือ ”กระบวนการ” บางคนเรียกระบบการทำงาน นั่นเอง หากการเขียนครั้งนี้จะเป็นประโยชน์ต่อคนอ่านทั้งภายในและภายนอกองค์กร เราก็จะดีใจและยินดีมากๆไปด้วย

ออกแบบกระบวนการ และทำให้คนเข้าใจเป้าหมายของกระบวนการอย่างไร

ตอนที่เราออกแบบกระบวนการว่าเราจะทำ workshop way of work transformation ยังไงบ้างนะ เราคิดแค่ว่า เวลาเราอยากจะเปลี่ยนอะไรบางอย่าง เรามักมีขั้นตอนยังไงบ้าง และก็ได้คำตอบประมาณนี้

1. เราต้องรู้ก่อนว่า ระบบการทำงานของเรามีอะไรอยู่ตอนนี้ เราทำอะไรแบบไหนอยู่ และมันมี pain points ตรงไหนบ้างนะ เรียกขั้นตอนนี้ว่า “Understand what we have and what we currently do” ขั้นตอนนี้สำคัญมากที่สุด มันคือการสะท้อนและตกผลึกสิ่งที่เป็นอยู่ในปัจจุบันร่วมกัน เพราะถ้าเราไม่รู้ว่าเรามีปัญหาอะไร เราจะไม่รู้เลยว่าเราจะเปลี่ยนแปลงอะไร เพื่ออะไร เราจะไม่มีแรงขับเคลื่อนนั่นเอง
2. เราอยากยึดแบบแผนไหนมาทดลองทำตามดู เพื่อให้ตอบโจทย์และเป้าหมายของเรามากที่สุด เอามากางให้ดูกันว่าระบบการทำงานแบบนี้ เอื้อให้การทำงานของเราดีขึ้นและปิด switch pain points ที่เรามีไปได้บ้างไหมนะ และอย่างไร เรียกขั้นตอนนี้ว่า “Introduce the new way“ เวลานี้เราต้องโฟกัสให้ถูกจุดมากๆ ว่าแบบแผนการทำงานแบบใหม่ที่เราอยากเอามาใช้นั้น จะแก้ไขปัญหาอะไร เช่น เอา scrum ceremonies guideline มาช่วยเรื่องปัญหาประชุมซ้ำซ้อนและไม่ตอบ objective เป็นต้น
3. หลังจากนั้นเราจะต้องสร้างแผนและตกลงกันแล้วว่า ตัวเราเองนั้นในฐานะ Individual contributors เราจะต้องปรับเปลี่ยน หรือรักษาอะไรไว้เพื่อให้ way of work แบบใหม่ ถูก implement ได้สำเร็จ และบรรลุเป้าหมายของทีม (นั่นคือการมีระบบการทำงานที่มีประสิทธิภาพ และทำให้เราทำงานได้อยากมีความสุข) เรียกขั้นตอนนี้ว่า “Call to action“ บอกได้เลยว่า ขั้นตอนนี้คือขั้นตอนแห่งความหวังที่แท้จริง ถ้าทีมสามารถเคาะความคิดของตัวเองได้ว่า เราจะทำอะไรต่างจากเดิมได้บ้าง เพื่อให้ชีวิตการทำงานของเขาดีขึ้น สิ่งที่ทำมาทั้งหมดก็คือสำเร็จไปแล้วครึ่งทาง

ซึ่งสามข้อด้านบนเป็นแค่เกือบๆครึ่งทางของภาพด้านล่างนี้เองนะ นี่คือวงจรของการพัฒนาปรับปรุงกระบวนการทำงานอย่างต่อเนื่อง เราเจอจุดที่อยากปรับ เราวางแผนว่าจะปรับยังไง เราลงมือทำตามแผน และเรารีวิวว่าสิ่งนี้นั้น work ตรงไหน ไม่ work ตรงไหน และเราก็ปรับเรื่อยๆ เพื่อให้ระบบการทำงานดีขึ้นเพื่อพนักงานทุกคน หนทางอีกยาวไกล เราต้องสู้กันยาวๆ

ภาพจาก https://www.beaconbc.co.uk/consultancy-services/improvement-planning/

มาถึงการรวมพลังหว่านล้อมให้คนมาร่วมกิจกรรม (ที่แปลว่าทุกคนในทีม Product Development) เราต้องยอมรับอย่างหนึ่งว่า ไม่ใช่ทุกคนที่พร้อม และยอมรับการเปลี่ยนแปลง สิ่งนี้เป็นทุกที่ รวมถึงที่นี่ด้วย

แต่สุดท้ายสิ่งที่ทำให้คนอยากร่วมกิจกรรมใดใดคือ การสื่อสารที่ดีว่า ทำไมเราต้องทำ แล้วเราจะได้อะไรจากการทำสิ่งนี้นั้นเอง

3 Phases of Progress

Phase 1 — Understand what we have and what we currently do

Objective and outcome: Understand what we have and issues that are caused by the current practice or process

เรามาทำอะไรใน phase นี้:

1. คล้ายๆ warm-up and check up ทุกคนในทีมก่อน ว่าตอนนี้เรารู้สึกว่า เรามี value ในทีมมากน้อยแค่ไหน เราเข้าใจเป้าหมายของทีมหรือไม่ว่าเรากำลังเดินไปทิศทางไหนกันอยู่ และมีความสุขในการทำงานของเรา และชอบทีมตัวเองหรือไม่
2. Sticky notes session and our “AS-IS” end to end way of work กิจกรรมหลักคืออันนี้เลย เราทำแนวลูกทุ่งๆเลยส่วนประกอบของการแปะ sticky notes มีทั้งหมด 5 lanes

When — ทีมสามารถระบุได้ว่า อยากตั้ง time frame แบบไหน ซึ่งสังเกตได้ชัดว่าทีมแบ่งได้สะดวกขึ้นตอนที่เริ่มเตรียมเอาของเข้า sprint หนึ่งๆ

What activity we do — พวกเราทำอะไรกันบ้างในช่วงเวลานั้นๆ สามารถทำเป็น sequence of actions ได้เลย ตามที่สะดวก เช่น discuss tasks > Q&A > confirm detailed tasks เป็นต้น

What ceremony it is — ถ้าจากตัวอย่างด้านบน ก็จะรวบและเรียกชุดกิจกรรมเหล่านี้ว่า Grooming เป็นต้น

What the output is — แน่นอนว่าทุกๆขั้นตอนการทำงานจะต้องมี output ของมันเสมอ ทีมจะต้องนึกออกมาว่า “เอ้ะ…เราทำสิ่งนี้ไปแล้วเราได้อะไรจากมันนะ”

Who is involved — ใครมีส่วนร่วมใน ceremony เหล่านี้บ้าง ตรงนี้ก็ทำให้หลายคนเอ้ะ อ๋อ กันเยอะเหมือนกันว่า เออ ทำไมเราต้องอยู่ทุกจุดเกินจำเป็น หรือ ทำไมเราไม่ได้อยู่ในจุดนั้นของการทำงานกับทีมนะ เราเจอประเด็นอันน่าสนใจตรงนี้เยอะเลย

As-is way of work template from discovery to delivery

Phase 2 — Introduce the new way

Objective and outcome: To Introduce of new practice of product management and development for Q Chang PD Team and the team acknowledge and believe the better solution is coming

เรามาทำอะไรใน phase นี้:

1. Introduction to squad team ceremonies and how to build the sense of team and team autonomy ownership สิ่งนี้ทำเพื่อ encourage ให้ทีม ทำงานเป็นทีมจริงๆ ช่วงไหนควรมีใคร involve ก็ควรทำ และทำอย่างไรให้ทีมมีอำนาจในการออกแบบวิธีการทำงานของตัวเอง แต่ยังสามารถตอบ objective ของกิจกรรมนั้นๆได้อยู่ เช่น วิธีการทำ sprint planning ของแต่ละทีมอาจจะไม่เหมือนกัน แต่ถ้ายังตอบโจทย์ที่ว่า เรารู้ว่าแต่ละ tasks ใช้ effort เท่าไหร่ และพร้อมเริ่ม sprint จริง ก็ถือว่าโอเคมากๆ แล้วเป็นต้น
2. Introduction to product delivery and release procedures อันนี้ทำขึ้นมาเพื่อขอความร่วมมือในชาว developers ให้เข้าใจและลอง implement สิ่งใหม่นี้ไปในทางเดียวกัน เพื่อให้การทำ deployment and release product ดีกว่าเดิม effective มากขึ้น และเป็นที่ไว้วางใจมากขึ้น

Phase 3 — Call to Action

Objective and outcome: Call to Action workshop — reflect what you would need to change from now

เรามาทำอะไรใน phase นี้:

1. Game quiz ง่ายๆ เพื่อ check ความเข้าใจสืบเนื่องมาจาก phase 2 สนุกสนานกันไป ครั้งนี้ PD leads หลายๆคนก็เข้ามาช่วยอธิบาย และเสริมใยเหล็กความเข้าใจระบบการทำงานกันอีกแรง
2. What we will keep and change as an individual contributor from now. อันนี้อย่างที่บอกตอนแรกเลยว่าคือ เวลาแห่งความหวัง เพราะอย่างที่บอกไปตอนต้นว่าแต่ละคนคือฟันเฟืองสำคัญ เสียงทุกเสียงมีความหมาย และสะท้อนอนาคตได้ดีเลย พวกเขาจะรู้ว่า อันไหนที่ทำไว้ดีอยู่แล้ว เขาจะรู้ว่าต้องทำต่อไป ส่วนสิ่งไหนที่ต้องปรับเขาจะรู้ว่าตัวเองต้องทำอะไร อย่างไร เช่น มีการ discussion มากขึ้นระหว่าง UI Designer และ Frontend Developer เพื่อ check in กันเสมอว่า เราทำงานในแผนเดียวกัน เป็นต้น

What you will keep and change as individual contributors workshop

เราได้อะไรจากการทำสิ่งนี้ และ Key Learnings ที่อยากฝาก

• ทุกคนล้วนมีความต้องการการเปลี่ยนแปลงที่ดีขึ้นเสมอ แต่ในบางองค์กรนั้นไม่ใช่ทุกคนที่จะกล้าเริ่มทำ หรือมองว่านี่ไม่ใช่หน้าที่ฉัน เราถึงต้องการ leadership มาช่วยรวมกำลังพล put everything into action and make it happen จริงๆ
• เราต้องเชื่อใน coaching over micro management การที่เรานำเสนอระบบการทำงานแบบใหม่ เราจะต้องทำใจอยู่อย่างหนึ่งคือ เราไม่สามารถ hand hold หรือ force ทุกคนให้ทำตามเราเป๊ะๆ 100% แต่เราต้องทำให้เขาเชื่อว่า เขาสามารถหันมาถามเราได้เสมอว่า สิ่งนี้ทำนี้มัน effective จริงไหม ในทางกลับกันเราจะต้องเข้าไปแวะเวียน validate the result of changes อยู่เป็นเนืองๆว่า ถ้าทีมลองทำท่าการทำงานแบบใหม่นี้แล้ว มันดีขึ้นหรือไม่ และอย่างไร แวะกลับขึ้นไปดู The continuous improvement cycle ด้านบนเลย
• การพัฒนาระบบการทำงาน มักจะเกิดขึ้นเรื่อยๆอยู่แล้ว เวลาเปลี่ยน คนเปลี่ยน สถานการณ์เปลี่ยน ระบบเปลี่ยน ความต้องการและความคาดหวังเปลี่ยน แปลว่าเราจะต้องพร้อมปรับ พร้อมเปลี่ยนอยู่เสมอ อยากให้มองว่าการเปลี่ยนแปลงคือเรื่องธรรมดาในที่ทำงาน แต่ให้เชื่อเสมอว่า มันมักจะมาพร้อมกับ objective ที่อยากทำให้สิ่งต่างๆดีขึ้นเสมอ

สุดท้ายนี้ ขอบคุณผู้อ่านทุกคน ทีม PD and Leads ทุกท่าน ที่เป็นส่วนหนึ่งของงานนี้ พูดเป็นล้านๆครั้งได้เลยว่า เราทำสิ่งนี้คนเดียวไม่ได้ และดีใจที่ทีมได้ยินความต้องการนี้ของเรา แถมร่วมมือเป็นอย่างดีเสมอมา ฝากติดตาม Q-CHANG PD Series ตอนถัดๆไปด้วย รับรองว่ามีประโยชน์ สนุกมือคนเขียนอีกแน่นอน ฮี่ๆๆๆ 💙

โอปอล์ — Senior Delivery Manager at Q-CHANG