บทบาทของการเป็น “ผู้ช่วยทีม” ทำอะไรไปบ้างหลังเริ่มงานได้ 3 เดือน

คือผมไม่ค่อยชอบให้ใครเรียกว่า “Head” มากนัก อาจจะเพราะยังไม่ได้อยากเคลมบทบาทนี้มากนักด้วย และการเป็น Head มันก็เป็นผู้ช่วยทีมจริงๆ ช่วยให้ทีมสามารถทำงานในแบบที่พวกเค้าเชื่อได้ เค้าเติบโตได้ เค้ามีความสุขและสนุกกับการทำงาน (ผมตั้งชื่อเล่นให้กับสมาชิกทีมทุกคนด้วย อย่าง Chief of Design System, Chief of Google Sheet, Daddy Dog, Cheif of Writing, Cheif of Figma Plugin) ซึ่งบทความนี้ถ่ายทอดหลังจากทำงานเป็น Head ของทีมได้ 3 เดือน เลยอยากจะบันทึกเก็บเอาไว้ว่าทำไรไปบ้าง บางทีอาจจะได้ย้อนกลับมาอ่านและคงได้ตกผลึกอีกครั้งว่าควรทำอะไรเพิ่ม ควรทำอะไรใหม่ หรือบางทีอาจจะมานั่งนึกได้ว่า “ทำไมไม่ทำนะ”

รูปนี้ถ่ายฟิล์มตอนไป San Fran เมื่อปี 2019 เดี๋ยวบอกเหตุผลตอนท้ายทำไมต้องภาพนี้

สำหรับใครที่ไม่รู้จักผมมาก่อน หรือเราอาจจะไม่ได้สนิทกันมาก การอ่านบทความใครก็แล้วแต่ ผมคิดว่าเราน่าจะทำความรู้จักกันก่อนเล็กน้อย เพื่อให้เข้าใจมากขึ้นว่าผมมีประสบการณ์ใช้ชีวิตหรือคิดอ่าน พลาด ทำถูก ทำผิดยังไงมาบ้างในการทำงานที่ผ่านมา คุณสามารถอ่านบทความก่อนหน้าได้ที่นี่ น่าจะทำให้เรารู้จักกันได้มากขึ้น :)

Disclaimer — เนื้อหาต่อไปนี้เป็นเพียงการแบ่งปันประสบการณ์ เล่ามุมมองการทำงาน ที่เกิดขึ้นในทีม UX เป็นหลัก ไม่ได้อ้างอิงถึงทีมอื่นว่าวิธีการทำงานจะเป็นแบบเดียวกัน อาจจะมีเล่าตอนทำงานร่วมกันบ้างเท่านั้น (ในบริษัท เราใช้ชื่อทีมว่า Experience Design แต่ในบทความขอใช้คำว่า UX เพื่อง่ายต่อการเข้าใจ) ผมเชื่อว่ายังมี UX Leader อีกมากมายที่เก่งกว่าผมแน่นอน ผมรออ่านบทความท่านอื่นด้วยนะ :)

จุดประสงค์ของบทความ ส่วนตัวเพื่ออยากจะบันทึกการทำงานช่วงแรก และไว้ย้อนกลับมาอ่านเพื่อทบทวนตัวเอง และอีกนัยยะนึง ผมเชื่อว่าน่าจะมีคนที่อยากจะพัฒนาตัวเองเพื่อเป็น Senior หรือ Lead ในอนาคต ผมหวังว่าบทความนี้จะช่วยให้ข้อมูลเพื่อเตรียมตัว และลดข้อผิดพลาดที่อาจจจะเกิดขึ้นได้ในอนาคต ส่วนผู้มากประสบการณ์แล้วทักทายมาให้คำแนะนำได้นะครับ :)

จุดเริ่มต้น

ช่วงที่เราตัดสินใจออกจาก Thoughtworks ก็เริ่มทบทวนกับตัวเองว่ากำลังอยากจะพัฒนาตัวเองด้านไหนต่อไหม อะไรที่ทำแล้วเราสนุก พร้อมจะแก้ปัญหามัน หรืออยากเอาอะไรบางอย่างที่เราเชื่อว่ามันดีไปทดลองกับที่ใหม่ และไม่ว่าจะทำงานที่ไหนก็แล้วแต่ เราเชื่ออยู่อย่างนึงเสมอว่า เราจะเอาประสบการณ์ที่เรามี บวกกับความเชื่อที่คิดว่ามันดี อยากทำ เราเคยเจอแล้วอยากลอง เอามาบวกเข้าด้วยกันได้ยังไง ที่ไหนบ้างนะจะตอบรับสิ่งนี้ และเราอยากสร้าง Culture ที่ดี สังเคราะห์จากที่เคยทำที่ผ่านมา

Bitkub เป็นหนึ่งในบริษัทที่เราได้คุยด้วย และมีโอกาสได้เห็นจุดที่ท้าทายและปัญหา แต่นั่นก็คือความตั้งใจที่ว่า “เราอยากลองมาแก้ปัญหา” ถ้าย้อนกลับไปช่วงก่อนต้นปีที่ยังไม่มีการ Lock down เพราะ COVID-19 เคสที่ทองหล่อ ตอนนั้นผมมีโอกาสได้ไปกินข่าวกับ Community คน Data หลายคนมากๆ และเราก็ได้เจอพี่เฮี้ยง ก็มีการพูดคุยเรื่องเนื้องานที่ Bitkub เล็กน้อย หลังจากนั้นก็เจอประกาศหา UX เข้าบริษัท ก็เลยทักไปถามกับทีมด้านใน และได้คุยกับ Co-CTO ก็คือพี่นิคในช่วงเวลานั้น ได้พูดคุยกับพี่นิคในเรื่องของ Direction กว้างๆ และความคาดหวังที่มองหาคน Lead ทีม UX (ซึ่งจริงๆ แล้วยังไม่มีทีมนี้ ภารกิจหลักคือการสร้างทีมนี้ รวมถึง Process ที่ดี ที่ควรมี ที่ควรเป็น และทีมอื่นควรจะเข้าใจ) จนมาถึงการที่เราขอให้พี่นิคช่วยนัดแนะกับน้องที่เป็น UX ในบริษัท ซึ่งตอนนั้นที่ได้คุยด้วยก็มีน้องที่ชื่ออีฟและซัน ทำให้เราเข้าใจวิธีการทำงานปัจจุบัน ทั้งภายในการทำงานของ UX เอง, การทำงานระหว่างทีม UX และทีมอื่นๆ รวมถึงปัญหาที่เกิดขึ้นในปัจจุบัน เมื่อทุกอย่างลงตัว ก็ตัดสินด้วยกันว่าจะร่วมงานกัน ซึ่งผมใช้เวลาล่วงหน้า 2 เดือนก่อนจะเริ่มงาน

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

อยากบอกว่า สำหรับใครที่กำลังหางาน สัมภาษณ์งาน หรือแม้แต่คนที่รับบทเป็นคนสัมภาษณ์งาน คุณควรจะคุยเรื่องความท้าทายหรือปัญหากันให้มากที่สุด แน่นอนว่ามุมมองแต่ละคนเรามองคำว่า “ปัญหา” หรือ “ความท้าทาย” แตกต่างกัน แต่เพราะคนทำงานทุกคน ควรรู้ว่าตัวเองพร้อมจะเจอกับความท้าทายปัญหาแบบไหนที่เค้ายินดีที่จะเจอและรับมือกับมันทุกวัน ทั้งวัน อย่าทำให้เค้ามาเจอภายหลัง อาจจะเสียความรู้สึกได้ทั้งสองฝ่าย แต่ก็ยังอยากย้ำเหมือนเดิมว่า ไม่ได้หมายความว่าทุกอย่างมันจะเป็นปัญหานะ :)

2 เดือนก่อนจะเข้าทำงานวันแรก

เราอยากใช้เวลาเตรียมตัวในช่วงสองเดือนอย่างเต็มที่ สิ่งที่เราทำหลักๆ มีทั้งหมด 3 เรื่องด้วยกันในการคำตอบมาให้ได้

เข้าใจเกี่ยวกับ Crypto และ Blockchain

แม้ว่าทุกวันนี้ทำงานที่ Bitkub ไปแล้ว 3 เดือนนิดๆ ก็ตาม แต่ก็ยังมีเรื่องให้เรียนรู้ตลอดเวลา ถ้าย้อนกลับไปช่วงระยะเวลาสองเดือนก่อนเข้ามาทำงาน สิ่งที่เราอยากหาคำตอบเกี่ยวกับ Industry นี้ ว่าทำไมถึงควรมี UX ไปส่งเสริมหรือสร้าง Value ยังไงบ้าง ซึ่งเราก็ไม่อยากคิดไปเองคนเดียว การได้พูดคุยหลายคน ก็ได้หลายมุมมอง มันเลยเป็นที่มาของ Live Podcast ใน EP นึงครับที่ผมสัมภาษณ์สองคน ก็คือ จอย และ โอ (สามารถกดไปดู Live ที่คุยเรื่องนี้ได้ที่นี่ครับ) การค้นหาข้อมูลเพื่อพูดคุยไม่ได้มีแค่สองคนนี้ แต่รวมถึงคนที่สนใจและเทรดรอบตัวหลายคนเลย

เข้าใจเกี่ยวกับ Bitkub

จากที่เกริ่นไปตอนต้นบ้างแล้ว ผมก็ได้ request กับพี่นิคหนักๆ เรียกว่าตื้อเลย เพื่อที่จะขอคุยกับ UX ที่ตอนนี้ทำงานอยู่ว่า ทำงานยังไงบ้าง, ใช้เครื่องมืออะไรบ้าง, ได้ข้อมูลจากทีมไหนเพื่อทำงานได้บ้าง, ทำงานกับทีมไหนบ้าง และความท้าทายกับปัญหาในปัจจุบันคืออะไร สิ่งที่ผมตั้งใจกับการให้เกิด session นี้ มันไม่ใช่แค่ผมจะมาหาคำตอบอย่างเดียวหรอก (เพราะแน่นอนว่าเรายังไม่ได้เริ่มงาน บางเรื่องมันก็ควรจะ confidential ไม่บอกอะไรมาก) แต่สิ่งที่ผมตั้งใจมากๆ คือผมไม่อยากให้น้องมี question ว่า “ไอ้คนนี้มาเป็น Head พวกเราได้ยังไงนะ” นั่นคือการ Bonding team แบบอ้อมๆ เพื่อให้คนที่เราจะร่วมงานกัน รู้จักเราให้ได้มากที่สุด พูดตามตรงว่าผมไม่คิดนะว่าการใช้คำว่า “Head” มันจะไปอยู่เหนืออะไรกว่าใคร แม้คำมันสื่อแบบนั้น และเราก็ไม่อยากใช้คำนี้ในแบบนั้นด้วย ผมบอกน้องเสมอประมาณว่า “มันเป็นแค่คำเรียกเอาไว้ทำงานต่างวาระกัน แต่สุดท้ายเราก็คนทำงานเหมือนกัน” รายละเอียดเรื่องทีมผมจะเล่าอีกทีด้านล่างนะ

เข้าใจเกี่ยวกับ Head/Lead

ผมตั้งคำถามกับตัวเองว่า “ไอ้คำว่า Head ที่ดีนี่มันหน้าตาเป็นยังไงนะ” และมันเป็นเรื่องนึงที่ผมก็อยากให้มันเกิดขึ้นมากๆ คือการที่มีการแบ่งปันความรู้หรือบอกเล่าสู่กันฟัง ว่าคนที่ทำหน้าที่นี่เค้าทำอะไรกันบ้างนะ บทความต่างประเทศมีเยอะมากๆ แต่ในไทยกลับน้อยหรืออาจจะไม่มีเลย จริงๆ ช่วงก่อน COVID-19 ก็มีการรวมกลุ่มกันพวกแก๊ง Head/Lead UX อยู่นะ แลกเปลี่ยนกันในหัวข้อหลักๆ คือ DesignOps แต่เสียดายมากว่าไม่ได้เจอกันต่อ แต่นั่นก็ไม่ใช่ปัญหาของผมแหละ ผมก็ต้องเตรียมตัวและหาคำแนะนำจากคนที่มากประสบการณ์ มีทั้งรุ่นพี่และรุ่นน้องด้วย ผมอาจจะจำได้ไม่หมด ถ้าเข้ามาอ่านถึงตรงนี้ก็อยากบอกว่าขอบคุณมากๆ ครับ ไม่รู้จะให้เครดิตใครดี กลัวให้คนนึงแล้วลืมอีกคน แต่ก็อยากย้ำว่า ขอบคุณมากๆ ครับ

เมื่อทำการบ้านครบสามด้านแล้ว ก็มาถึงวันแรก สัปดาห์แรก และเดือนแรกของการทำงาน

วัน-สัปดาห์-เดือน | ที่ 1

เล่าเป็นเนื้อความเดียวอาจจะเข้าใจแยกแยะยากแน่นอน เอาเป็นขอเล่าแบบเป็นข้อๆ แล้วกันนะครับ คิดว่าอาจจะมีมากกว่านี้ แต่ขอเล่าข้อที่สำคัญแล้วกัน

• Bonding team — เรื่องนี้สำหรับผมแล้วสำคัญมากๆ เพราะเราจะต้องทำงานร่วมกัน คุยกัน ปรึกษากัน และกล้าที่บอกเล่าปัญหาที่พบเจอด้วยกัน ผมให้ความสำคัญกับเรื่องนี้มากๆ รวมถึงเข้าใจด้วยว่าแต่ละคนมีสไตล์ยังไงบ้าง ทั้งเรื่องงานที่รับผิดชอบอยู่ การสื่อสาร การตัดสินใจ ความถนัด และการอ่านสถานการณ์ด้วย และแน่นอนว่าบางครั้ง ถ้าเราอยากจะรู้ปัญหาที่เกิดขึ้นมีอะไรบ้าง บางครั้งมันอาจจะไม่ได้ออกมาตรงๆ ยิ่งกับคนใหม่อย่างเรา ผมเลยเลือกที่จะพูดปัญหาก่อนคนแรก
• Assessment — ผมว่าเรื่องนี้ และคำนี้ เป็นคำที่อาจจะตีความได้หลายความหมายมากๆ บางคนอาจจะมองว่าเป็นเรื่องที่ไกลเกิน บางคนอาจจะมองว่ากำลังจับผิดความสามารถหรือเปล่า และเพื่อที่จะลดความสุ่มเสี่ยงแต่ละอย่างที่คิดได้นั่น ก็เลยเลือกที่จะชวนคุยตั้งแต่สัปดาห์แรกเลยว่า “อยากชวนคุยว่าแต่ละคนถนัดเรื่องไหนใน 5 เรื่องของ Design Thinking บ้าง” เพราะผมคิดว่า Design Thinking น่าจะเป็นจุดเริ่มชวนคุยได้ดี ใกล้ตัว และพอจะเป็นตัวแทนของ UX Process อย่างคร่าวๆ ได้ แม้ว่ามันจะไม่ได้ละเอียดทุก Ceremony ของ UX ก็ตาม แต่เราควรจะเลือกชวนคุยหรือเปิดประเด็นด้วยเรื่องง่ายๆ (ปัจจุบันนี้สมาชิกทีมทำ UX Assessment แบบลงรายละเอียดแล้ว ไว้มีโอกาสจะมาเล่าอีกครั้ง)
• Communication — ในการทำงาน UX มันไม่ได้ทำงานตัวคนเดียวหรอก และอย่างแน่นอนด้วย เพราะฉะนั้นมันเลยถึงมีคำถามแรกๆ ตั้งแต่ก่อนเข้ามาทำงานแล้วว่า เราทำงานกับใครบ้าง มันเลยทำให้ในช่วงสัปดาห์แรกผมได้สร้างห้อง Slack เพิ่มขึ้นหลายห้องเพื่อให้สามารถต่อตรงการทำงานบางอย่างด้วยกันได้ทันที ไม่ว่าจะเป็นขนาดบริษัทที่มีพนักงานหลายคน และรวมถึงการทำงาน Remote ด้วย เพราะฉะนั้นช่องทางการสื่อสารสำคัญมากๆ (Tips ส่วนตัว คือผมจะ Grouping กลุ่มคนออกเป็น 2 กลุ่มหลักๆ คือ ทีม UX และทีมที่เราคุยด้วยบ่อยๆ เช่น Lead PO, Product, หรือรวมถึง People team เพราะจะมีสิ่งที่เราขอความช่วยเหลือบ่อยๆ เช่น เรื่องการ Hiring, Request Budget, etc.)
• Way of Working/Direction/Roadmap — สิ่งที่ต้องสื่อสารหลักๆ กับทีม และต่างทีมเสมอ คือ วิธีที่ทีม UX ทำงาน, ทิศทางของทีม เช่นเรื่องการเติบโตของทีม หรือการ Prioritize งาน และรวมไปถึงภาพไกลๆ ของทีมจะเป็นยังไง Milestone หลักของทีมเป็นยังไงบ้าง อย่างเช่น ผมก็จะย้ำกับทุกคนทั้งในทีมตัวเองและทีมที่ทำงานด้วยกันว่าเรา Design with Data ไม่ใช่แค่เอา opinion หรือความคิดเห็นส่วนตัวคุยกันอย่างเดียว ไม่มาพูดว่า “ผมคิดว่า...” “ผมเชื่อว่า...” “จากประสบการณ์ผมนั้น…” แน่นอนละว่ายังคงมีได้ยินอยู่บ้าง แต่ก็เชื่อว่าจะลดน้อยลง หรือจะมี Data มาประกอบการสนทนาเสมอ ส่วนเรื่องของ Roadmap ถ้าตีเป็นภาพย่อยก็น่าจะเป็นการดึงเอา Task งานที่จะเกิดขึ้นทั้งภาพใหญ่จนภาพเล็กมา Estimation หรือมาประเมินค่าเสียหายว่าจะใช้เวลามากน้อยยังไงบ้าง แต่ละส่วนงานภาพย่อยทำอะไรบ้าง
• Setup Ceremony — ถ้าจำไม่ผิด สัปดาห์แรกก็ Setup เลยว่า เราจะ Retro ทุกวันอะไร, ทำ Knowledge Sharing ทุกวันอะไร, หรือจะไปเข้าร่วมอะไรกันยังไงบ้าง อันนี้เล่ารวมๆ ทั้งที่เกิดขึ้นกับตัวเอง ในทีม และต่างทีม และก็ปักใน Calendar ให้เป็น Recurring หรือตั้งให้มีเป็นประจำไปเลย ตัวอย่างเช่น Knowledge Sharing มันถูกต่อยอดมาจากการทำ Assessment เจ้า Design Thinking ครับ พอผมรู้ว่าใครถนัดอะไรแล้ว ก็ให้คนที่ถนัดแต่ละด้าน ทำ Session หัวข้อของตัวเองขึ้นมา โดยเรามีเป้าหมายว่า จะทำให้คนคนนึงในทีมเราเข้าใจ UX และ Design Thinking มากขึ้น (ซึ่งคนนั้นคือคนที่ถนัดเรื่อง Visual Design มากๆ และอยากจะพัฒนาด้าน UX) พอจบทุกหัวข้อแล้ว เราก็ให้คนนี้มาเล่าครับว่าได้เรียนรู้อะไรบ้าง สรุปคือทั้งหมดทั้งมวลผมให้ทุกคนได้ลองดึงทักษะ Storytelling และ Facilitate ไปด้วยในตัว เพราะผมคิด(เอาเอง)ว่า ถ้าได้พัฒนาด้านนี้ ต่อไปทีม UX จะต้องไปเล่างานบ่อยอยู่แล้ว รวมถึงอนาคตแต่ละคนจะได้ออกไป Public Speaking หรือแบ่งปันเรื่องราวตัวเองกับคนอื่น เป็นการฝึก Coaching ไปในตัว ที่ต่อไป Senior/Lead ก็ต้องควรที่จะสามารถทำได้ — โดยผมก็หวังว่าการทำ Knowledge Sharing จะสามารถเพิ่ม UX Maturity ในองค์กรด้วยในภาพไกล
• Recruit — ในช่วง 2 เดือนก่อนเข้ามา จนถึงสัปดาห์แรก สิ่งที่ถูกพูดคุยบ่อยมาก คือผมถามหาว่า อะไรที่จะเติมเต็มทีมได้บ้าง ทั้งเรื่องของคนและทักษะที่หายไป สำหรับผมแล้วก็ต้องมา Balance กันระหว่าง เราต้องการคนนั้นจริงๆ หรือต้องการทักษะนั้นจริงๆ ไม่ใช่เพียงแค่นั้น และต้องตอนนี้จริงๆ ใช่ไหม มันไม่ได้คิดว่าอยากให้มีคนมาเติมเท่านั้น และสิ่งที่ต้องคิดต่อคือ คนปัจจุบันที่มีอยู่เดินหน้ายังไง และคนใหม่เข้ามาเติมเรื่องไหนในแบบระยะยาวหรือ Long term shot เราจะมองแต่เพียงระยะสั้นอย่างเดียวไม่ได้ ส่วนเรื่อง Hiring Process ขอเล่าแยกข้อต่อไปแล้วกัน
• Hiring Process — ผมให้ความสำคัญมากๆ เพราะอย่างที่บอกไปตอนแรกคือ เราอยากได้คนที่เข้ามาแล้วไม่ควรมี Question ว่าเข้ามาทำงานได้ไง ก็ต้องผ่านการพิสูจน์ตัวเองประมาณนึง และยิ่งกับคนที่ผมรู้จักก่อนหน้าก็ต้องระวังมากๆ เรื่องของ Bias ถ้าใครที่ผมรู้จักอยู่แล้วก็จะให้น้องๆ ตัดสินใจเสียส่วนใหญ่เลย ถ้าเล่ากระบวนการคร่าวๆ คือผมจะประกาศหาด้วยตัวเอง จากนั้นผมก็ชวนพูดคุยกันก่อน เพราะผมคิดว่า ผมกำลังจะเป็นผู้ช่วยเค้า เค้าน่าจะอยากรู้ว่าผมจะช่วยเค้าทำงานได้จริงไหม ซึ่ง Criteria เวลาผมเลือกคนจะมอง 3 ข้อ คือ ทำงานได้ไหม, พัฒนาตัวเองได้ไหม และเข้ากับทีมได้ไหม(ซึ่ง 3 ข้อนี้ผมใช้มาตั้งแต่ Wisesight, SCB10X) มันเลยเป็นที่มาว่า พอผ่านจากผมไปแล้ว ก็จะไปคุยกับน้องๆ ในทีมกันต่อ ซึ่งจริงๆ ก่อนจะได้ไปคุยกับทีม ผมให้สมาชิกทีมทุกคนให้คะแนนด้วย แล้วก็ Ranking คะแนน จากนั้นก็ลำดับมาสัมภาษณ์อีกที (บางคนก็มาคุยกับผมแล้วขอไว้โอกาสหน้า ทั้งน้องบอกเอง และผมบอกไปเลยตรงๆ ก็มี ขอบคุณที่เราได้คุยกันนะครับ) พอมาถึงวันที่ได้เจอกับทีม ก็มีการให้คะแนนอีกทีด้วย ส่วนคิดจากอะไรบ้าง ไว้มีโอกาสเรามาคุยกันครับ :)
• Authorize — หรือจะเรียกอีกคำว่า Ownership เป็นสิ่งที่เราเชื่อมาตลอด และเราก็ทำมาตลอด คือการให้ทีมมีส่วนการตัดสินใจ จากที่ผมเล่าไปเรื่อง Hiring คนใหม่เข้าทีม ในเรื่องการทำงานก็เช่นกัน ยกตัวอย่างเช่น มีภารกิจถูกมอบหมายให้ทีม UX ทำงาน สิ่งที่ผมทำคือ ถามความคิดเห็นกับสมาชิกคนนั้น เช่น คิดว่าจะต้องทำยังไงเพื่อให้งานนี้มันเกิดขึ้น, ต้องเกิดอะไรขึ้นบ้าง, ต้องได้ข้อมูลอะไรบ้างก่อนทำงาน และจากใครด้วย จากนั้นผมจะดูว่าเค้าตัดสินใจยังไง แม้ว่าในใจจะรู้สึกว่าเรามีคำตอบที่เคยทำ แต่เราก็จะไม่ห้ามใดๆ (ถ้ามันไม่ได้ร้ายแรงถึงขึ้นกฏหมาย) เราเชื่อว่าทุกคนควรได้รับการเรียนรู้จากประสบการณ์ตัวเอง ยกตัวอย่างเคสนึง มีน้องในทีมทำ Survey ที่เราเห็นแล้วว่ามันน่าจะปรับนะ และผมก็บอกว่าผมคิดเห็นยังไง แต่ผมจะไม่บังคับให้เค้าเปลี่ยน ซึ่งผมยอมรับการตัดสินใจน้อง (การยอมรับหมายความว่า ต่อให้ผมรับออกมาไม่ดี ห้ามพูดกับน้องว่า “เห็นไหม พี่บอกแล้ว” ถ้าใครคิดจะปล่อยน้อง ห้ามพูดคำนี้เด็ดขาด) และเมื่อถึงตอนที่เราปล่อย Survey ให้คนต่างทีมทำ ก็มีคนมาคอมเมนท์ว่าต้องปรับ พร้อมทั้ง tag ชื่อผมด้วย! แต่สิ่งที่ผมรับมือกับเหตุการณ์นี้คือ ผมไม่เข้าไปตอบ แต่ผมยินดีให้น้องมาปรึกษาได้นะ ไม่ได้ทิ้งน้อง ผมให้เหตุผลกับน้องไปว่า “ถ้าพี่เข้าไปตอบ ครั้งต่อไปเค้าจะ tag พี่อีกพร้อมกับคาดหวังว่าพี่จะต้องเข้าไปตอบ เพราะฉะนั้นเราเป็นเจ้าภาพงานนี้ อยากให้ลองรับมือดู”
• Continuous Discovery — ต้องขออนุญาตให้คำนี้อ้างอิงถึง Lean UX เลย เพราะต้องบอกว่าโดยนิสัย UX แล้ว พวกเค้าคือกลุ่มคนที่ต้องการหาความจริง เข้าใจเหตุผลและเบื้องหลักของสิ่งที่จะทำ จนนำไปสู่การติดตามว่า สิ่งที่เราสันนิษฐานเนี่ย มันจริง มันเป็นไปได้ไหม มันใช่หรือไม่ใช่นะ แต่แน่นอนละว่า “การทำ Research มันไม่ได้บอกว่าถ้าทำแล้วจะถูกต้อง 100%” เพราะสุดท้าย มันคือการเข้าใจสถานการณ์ รวมถึงหาความแนวโน้มและคาดการณ์ถึงความผิดพลาดล่วงหน้า (ณ ช่วงเวลานั้น บริบทนั้นด้วยนะ ถ้าคิดว่าทำทีเดียวแล้วใช้ได้ตลอด Lean UX คงไม่ใช่คำว่า “Continuous” หรอก) และถ้าวันนี้มีคนเชื่อว่าการทำ Research มันจะต้องลดการผิดพลาดได้ 100% ในนัดเดียว อันนี้น่าจะต้องทำความเข้าใจกันใหม่แล้ว หรือผมเข้าใจผิดนะ? นอกจากนั้นอย่างที่บอกไปว่าผมกำหนดเรื่อง Process ในการทำงานไว้ด้วย ก็จะลง Detail ว่า การทำงานทั้งองค์กรกว่าจะมาถึงเราเป็นยังไง, ตั้งแต่ไอเดียจนมาถึง Product Backlog และถึง Sprint Backlog เป็นยังไง และเราควรอยู่ตั้งแต่ตรงไหน (แน่นอนละว่าควรอยู่ตั้งแต่แรกสิ!), รวมไปถึงการ Research และ Testing เป็นยังไง เอาจริงๆ น้องทั้งทีมรูภาพนี้อยู่แล้ว แต่หลักๆ ไว้ใช้สื่อสารรวมถึงย้ำพูดในทุก Meeting ด้วย (ที่ผมเล่ามาผมจะจัดใส่ไว้ Onboarding slide ครับ เพื่อที่เวลามีคนอยากเข้าใจ ไม่เข้าใจ หรือแนวโน้มว่าต้องอธิบาย ก็จะพามา Slide นี้)

Stakeholder Management — ขอเป็นข้อสุดท้ายแล้วกันครับ ผมคิดว่าน่าจะมีอีกหลายเรื่องเลย จริงๆ เรื่องนี้น่าจะเป็น Core หรือตัวหลักอยู่แล้วที่ต้องทำ เพราะ Head เองก็เป็นเหมือนสะพานความเชื่อมโยงระหว่างตัวองค์กรสู่ทีม แปลงสารและความเชื่อ รวมถึงคัดกรองด้วย มันไม่ใช่แค่ผมจะเออ-ออไปตามสิ่งที่ผู้บริหารวางไว้อย่างเดียว แต่ก็ต้องอธิบาย, Educate, Convince หลายต่อหลายครั้ง เพื่อรักษาการทำงานที่ดีร่วมกัน รวมถึงกระบวนการทำงานที่ดีที่ควรจะเป็น เพื่อให้ทีมยังมีการทำงานที่สร้าง Value หรือคุณค่าให้กับทั้งองค์กรและผู้ใช้งานด้วย ซึ่งจริงๆ คำว่า Stakeholder สำหรับผมแล้วก็ไม่ได้มีแค่ผู้บริหารนะ แต่ผมมองเป็น Stakeholder Mapping คือคนที่มีส่วนเกี่ยวข้องที่ทีม UX ต้องร่วมงานด้วย (ผมแยกตามวิจารณญาณของผมเองนะไม่ได้อิงตำราไหน ขออภัยล่วงหน้าถ้ามันผิดหลักใครด้วยนะครับ) ผมมองเป็น 5 ระดับด้วยกัน

1. สมาชิกทีม UX
2. ทีมที่ตัดสินใจด้วย — Product Owner, QA, Developer
3. ทีมที่มีข้อมูล — Marketing, Customer Support, Compliance
4. ทีมที่พร้อมสนับสนุน — เพื่อนร่วมงานในส่วนงานอื่นๆ
5. ผู้บริหาร

ซึ่งแต่ละระดับ ถ้าไป Search ค้นหาว่า Stakeholder Mapping ก็จะพบว่า มีความสำคัญของแต่ละกลุ่มแตกต่างกันไป ต้องขอยกประโยคนึงที่ได้ยินบ่อยจนติดหูมากๆ “ทีมพึ่งพาอะไรคุณได้” และผมคิดว่ามันเป็นประโยคที่ดีมากที่ไว้ Remind หรือเตือนใจตัวเอง แม้ว่ามันจะดูตรง แน่นอนละว่าผมก็คงไม่ได้พูดแบบนี้กับทุกคน แต่ความหมายของประโยคนี้ที่แท้จริงคือ เราจะสร้างคุณค่าอะไรให้กับทีมได้บ้าง เราช่วยทำให้ผลลัพธ์เกิดขึ้นด้วยความสามารถของเราอะไรบ้าง อย่างไรบ้าง

หลังจากนั้นช่วง 2 เดือนถัดมาก็

• จะเป็นท่าที่จะเริ่มปรับเอา Process ที่เราวางไว้มาใช้กับงานจริง และเกิดเหตุการณ์แบบเดือนแรกวนไปเรื่อยๆ และยากขึ้นเรื่อยๆ เข้มข้นขึ้นเรื่อยๆ
• ให้คำปรึกษาทีม รวมถึงซ้อมยิง Present ให้น้องๆ ด้วย เพราะช่วงแรกเรามี Setup ทำ Research ไว้หลายอย่าง ถึงตาน้องๆ ให้เล่างานกันโดยตรง โดยผมจะไม่เข้าไปยุ่งเกี่ยวมากนัก เพื่อให้รักษาความเป็น Ownership เอาไว้
• แก้ไขสถานการณ์ หรือรวมถึงบางครั้งก็ต้องปรับ Process ในบางครั้ง
• เข้าไปมีส่วนร่วมในการประชุมที่มีการตัดสินใจภาพรวมมากขึ้น ในฝั่งของทีม UX เองอาจจะไม่ได้ตัดสินใจทั้งหมดอยู่แล้ว แต่ก็ต้องสามารถให้ข้อมูลภาพ High Level ได้หรือภาพกว้างๆ ได้ เช่น ค่าเสียหาย หรือ Estimate cost (working hour) ในการทำงานได้ หรือรวมถึงการนำเสนอทางเลือกให้กับทีมต่างๆ หาก UX เข้ามา Involve หรือมามีส่วนร่วมด้วย
• มีประเมินน้องในทีมสำหรับคนที่ยังอยู่ในช่วง Probation และรวมถึงน้องที่เพิ่งเข้ามาใหม่ด้วย

สุดท้าย หลังจากครบ 3 เดือน ผมก็ขอ Feedback การทำงานกับคนที่เราเคยร่วมงานด้วยทั้งหมด ไม่ว่าจะน้อยครั้งมากครั้งก็ตาม เราเชื่อว่า การทำประเมินเพียงแค่ 1 ครั้งต่อปีมันไม่เพียงพอแล้ว ตอนสมัยอยู่ Wisesight ก็ทำทุก 4–5 เดือน มาตอน Thoughtworks เราก็ขอ Feedback ทุกช่วงสำคัญ อาจจะช่วงจบโปรเจคหรือจบ Phase ก็คุยกัน (ซึ่งตามความเป็นถ้าคุณอยากจะคุย ก็คุยเลย อย่ารอให้ถึงรอบ)

คำถามหลักๆ คือ

• ถามถึงความถี่ในการทำงานร่วมกัน เชื่อไหมว่าแต่ละคนมองความถี่ในการทำงานร่วมงานแตกต่างกัน ผมก็เลยมีตั้งต้นไว้ให้ และก็ถามข้อต่อมาว่า คำว่า “บ่อย” แต่ละคนนิยามว่ายังไงระหว่าง “ไม่บ่อย” กับ “บ่อยมาก”
• ส่วนต่อมาก็จะ list ให้ดูว่างานที่เราทำไปที่ผ่านมามีอะไรบ้าง แล้วถามว่าได้ร่วมงานกันในโปรเจคไหน (เพราะ Survey นี่ตอบกันหลายคน เลยต้องง่ายต่อการตอบ)
• จากนั้นก็ถามว่าเราได้ช่วยอะไรเค้าไว้บ้าง (ดูเหมือนจะเป็นการทวงบุญคุณ อย่าคิดแบบนั้นนะ แต่เราจะได้รู้ว่าเค้ารู้สึกว่าการกระทำไหนเป็นการช่วยเค้าบ้าง) ซึ่งข้อต่อไปก็เลยให้ rating ว่าการทำงานร่วมกันพึงพอใจเท่าไร และที่หายไปเราจะต้องทำยังไงเพื่อเติมคะแนนให้ดีขึ้น

ซึ่งแน่นอนว่า ในหน้าแรกของ Survey นี้ผมเขียน Ground rules ไว้เล็กๆ ว่าเราต้องทำงานร่วมกันในระยะยาว เราอยากช่วยให้งานของพวกเค้าและของเราด้วยกันดีขึ้น ซึ่งผมก็อธิบายด้วยว่า มันไม่เพียงหรอกนะที่จะมาประเมินแค่ Line Manager เพียงมุมเดียว เราทำงานกับใครบ้าง พวกเค้าก็ควรจะมีส่วนร่วมในการให้คำแนะนำในการทำงานด้วย เพราะเราทำงานกับทุกคน ไม่ใช่แค่ Manager

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

หวังว่าบทความนี้จะมีคุณค่าต่อผู้อ่านนะครับ หากเป็นประโยชน์โปรดแชร์ต่อกับเพื่อนหรือคนรอบตัวที่เค้าทำงานด้านนี้ หรือเกี่ยวข้องกับทีมนี้ก็ได้ครับ และสุดท้าย ผมไม่ได้เคลมว่าสิ่งที่ผมทำมันถูก เพราะมันอาจจะไม่เหมาะกับบางบริบท บางคน บางวิธีกับสถานการณ์นั้นๆ ของแต่ละคนก็ได้

ถ้าอยากแลกเปลี่ยนมุมมองหรือแบ่งปันเรื่องราวส่วนตัวกับผม ทักมาได้ทั้งทางเพจหมีเรื่องมาเล่า หรือ FB ส่วนตัวผมก็ Inbox มาได้ครับ :) ขอบคุณที่อ่านมาถึงตรงนี้ครับ