สรุป Clubhouse "Bangkok Softskill for tech #2 Softskill in action"

จัดโดย SCB TechX x BigBears.IO ซึ่งงานรอบแรกจัดที่ SCB ก่อนโควิดเมื่อนานมาแล้วแหละ รอบนี้จะมาในหัวข้อ Softskill in action เนอะ

เราเลยเข้าแอพ clubhouse แล้วกดปุ่มกระดิ่งกริ้งๆ เพื่อเตือนเรา ว่าวันที่ 3 กันยายน ตอนสองทุ่ม อย่าลืมเข้ามาฟังน้าาา

และพี่ๆเขาก็มาก่อนถึงเวลานิดนึงด้วยเนอะ

มาเริ่มกันที่ Part 1 Share experience with กับพี่ๆแต่ละคนกันเลยจ้า

ไท ปังสกุลยานนท์ (ไท), Front-End Architect, Taskworld, "การสื่อสารด้วยภาพให้เกิด Clarity มากขึ้น"

ก่อนหน้านี้ soft skill จะหมายถึงความกระตือรือร้นในการพัฒนาตัวเอง และทำอะไรสักอย่างให้กีขึ้น ซึ่งจะต้องมี technical skill ที่แข็งแรงด้วย โดยมีเครื่องมือคู่ใจในการทำงาน เช่น Vim, VS Code, Firebase

เมื่อพัฒนาตัวเองไปได้สักพักนึง จะพบว่า ทำงานคนเดียวก็ดี และทำงานได้เร็วกว่าการทำงานเป็นทีม เพราะไม่มี overhead ในการสื่อสาร ไม่ต้องรอเขาทำงานเสร็จ

การร่วมงาน hackathon และ project ต่างๆที่มีระยะเวลาจำกัด เราพบว่า เราสามารถทำงานได้ทีละอย่าง เกิด bottleneck เรากลายเป็นคอขวด

ดังนั้น จะต้องหาวิธีการทำงานเป็นทีมให้เสร็จ ก็คือ โหลดภาพในหัวของเรา ใส่ในหัวของคนอื่น ดังนั้นเราจะมี soft skill ในการสื่อสารกับทีม (ซึ่ง soft skill เป็น area สำคัญในการทำงาน)

เวลาที่เราทำงานร่วมกัน เวลา sync งาน หรือประชุมกัน เราจะสื่อสารด้วยการพูดเพียงอย่างเดียว

ถ้าเป็นงานที่ async ในช่วง WFH จะใช้ chat คุยกัน ดังนั้นเลย pick-up tool ตัวนึง ที่ชื่อว่า Figma ก็ตัวเดียวกับที่ UI Designer บางคนใช้แหละ อันเดียวกัน

เหตุการณ์ตัวอย่างการสื่อสารด้วยภาพ

• ทีมมี meeting feature กัน คุยกันเรื่อง age case บางงานมี dependency หรือมีความเกี่ยวโยงกัน ทำให้อาจจะรองานกัน เช่น feature A กับ feature B เชื่อมต่อกัน ถ้าเลื่อนการส่งงาน feature B เข้ามาแล้ว ส่งผลกระทบอะไรใน feature A บ้าง และแต่ละคนจะเห็นภาพต่างกัน  เลยวาด UI mock-up ใน whiteboard และถามแต่ละคนใน meeting เพื่อดึงภาพในหัวของเขาออกมาบนกระดาน ถ้ามีเคสประหลาดๆ จะทำให้ทีมเข้าใจตรงกัน
• คุยกันผ่าน chat กับ customer support ถามว่า feature นี้ทำงานยังไง อันนี้เป็น bug หรือเปล่า ลูกค้าถามมา ซึ่งมี logic ที่ complex พอสมควร มีประมาณ 5-6 แบบ จึงใช้ Mermaid ในการวาด flow chart และเขียน logic เข้าไป ค่อนข้าง expective ในการสื่อสารกับคนอื่น

• ทำเกมส์อันนึง แล้วเขียน document อธิบาย แต่พยายามอ่านแล้วก็ยังไม่รู้สึกชัดเจน เลยใช้ Figma แคปรูปเกมส์ไปแปะ แล้วเชื่อมกันด้วยลูกศร ทำให้เราเขียนข้อความได้น้อยลงมาก

• เล่นดนตรีด้วยแป้นพิมพ์ ใช้ Figma เช่นกันในการวาดรูป keyboard computer และเขียนแต่ละ key ว่าทำงานยังไง เป็น sheet

สรุป : เราจะเสียเวลาเขียนทำไม ในเมื่อเราทำเป็นภาพได้

เพิ่มเติมจากพี่ๆแต่ละท่าน

• คุณสุนัยเคยเจอเหตุการณ์การสื่อสารคนละภาษา เลยเขียน flow chart ทำให้การสื่อสารง่ายขึ้น ไม่ต้องเข้าใจในภาษาพูดของเขา การวาดช่วยทำลายกำแพงภาษาไปได้ แล้วก็วาด topic ที่เราจะคุย คุยเสร็จแล้วกาทิ้ง เพื่อไม่ให้วนไปคุยใน topic เดิม และถ้าคุยเกิน 10 นาที ให้ไปที่กระดาน เพื่อลดอาการหัวร้อนลงได้
• เป็นเรื่องที่น่าทำในทุก situation ควรมี whiteboard ในทุกๆ meeting
• บางคนอาจจะไม่ยอมสื่อสารด้วยภาพ เหมือนเราไม่ยอมเขียนเทส เพราะเขียนเทสกันไม่ค่อยเป็น ถ้าเริ่มคุ้นชินจะ save เวลาเรา และลองหาโปรแกรมที่ดึงภาพในหัวของเราส่งต่อให้คนอื่น และดึงภาพของคนอื่นออกมาให้เราเห็น

ชาคริต ลิขิตขจร (คริส), Senior Consultant, ThoughtWorks, "ถามยังไงให้คนอยากตอบ"

ด้วยความที่ทำบริษัท consult ทำให้มี contract กับลูกค้า และไม่ค่อยสอบถามกัน เพราะกลัวคนรำคาญ วิธีการถามก็สำคัญเช่นกัน

สิ่งสำคัญในการตั้งประโยคคำถามให้คนอยากตอบ

• ไม่ใช้คำถามในการด่า หรือ attack คนอื่น เช่น การ review code ถามน้องในทีมว่า ทำไมเขียนโค้ดแบบนี้? ก็ถือว่าเป็นการด่าน้องเขา ทำให้เกิดความเจ้าใจผิด ดังนั้นจะต้องมี self awareness เข้าไปด้วย เช่น บอกน้องเขาดีๆว่า โค้ดตรงนี้ตกอันนี้ไปนะ
• ถ้าสงสัยจริงๆสามารถพูดได้ และฟังคำตอบเขาด้วย ก่อนที่จะไป judge เขา ไม่งั้นจะทำให้เราเสียคำถามไปเลย เพราะคนไม่อยากตอบ
• และถ้าต้องการ feedback เขาจริงๆ ให้บอกตรงๆ
• ถามแล้วเราต้องการคำตอบเสมอ และรอฟังคำตอบจนจบ เป็นมารยาทที่ดีอย่างนึง

ตอนเริ่มถาม

เช่นถามว่า พี่พ่น log ทำไม? เราก็เกิดคำถามกับคำถามนี้ว่ามันแปลกๆ ถามทำไม ก็เราพ่น log ไว้ดูไง

• ควรแสดง intent ว่าถามคำถามไป เพื่อถามอะไร เช่น พอดีเกิดปัญหานี้ขึ้น ว่าทำไมถึงมี log นี้พ่นมา
• แสดงว่าเราทำการบ้านอะไรมาแล้ว จากนั้นนำมาใส่ detail ในคำถามของเรา เช่น เห็น log นี้ทุกครั้งเมื่อ user ทำสิ่งนั้นอยู่
• ในการถามลูกค้าใหม่ เขาจะมี intent อะไรในการถามครั้งนี้ และเราจะ support อะไรเขากลับไป
• หลังจบให้ follow-up : ใช้คำตอบแก้ปัญหา และให้ feedback กลับไปที่เจ้าของคำตอบ เช่น แก้ปัญหานั้นได้แล้ว ขอบคุณมากๆครับ จะทำให้คนอยากตอบคำถามของเราในอนาคตมากขึ้น

สรุป : คำถามที่ดี คือ มี intent ทำการบ้านมา – ในฐานะคนตอบ ให้ทำกลับกัน ตอบเท่าที่ตอบได้ และถามเพราะอะไร เพื่อจะได้ช่วยได้มากกว่านี้ และ observe ก่อน ไม่ควรไป judge หรือ attach และแชร์ความเห็นของเราล้วนๆ

จากพี่ๆแต่ละท่านที่เพิ่มเติมมา

ขอรวมไว้ตรงนี้ที่เดียวกันไปเลย

• model ในการถามของพี่หนึ่งจะใช้ STAR Model คือเป็นวิธีถามให้ได้คำตอบ มีการ structure คำถาม observe บน fact ที่เราเห็น
• Nonviolent Communication (NVC) เป็นสิ่งที่คนทำงานประสานงานกับคนอื่นเยอะควรไปเรียน ทำให้เราอย่าเผลอฟังเสียงจองตัวเอง ทำให้เราอยากบวก และไม่ตรงกับเจตนาของเรา ดังนั้นเราต้องรู้ตัวทัน ว่าเราคิดอะไรอยู่ และมีสติ
• ถ้าเจอคำถาม เช่น บริษัทจะเจ๊งไหม? ให้เราลองถามกลับไปถึงจุดประสงค์ของคำถามคืออะไร และเข้าใจจุดประสงค์ของคำถาม มี assumption ให้คำถามดูอ่อนน้อมลง ดังนั้นอย่าไปกังวลมาก ไม่ต้องคิดเยอะ ตอบให้สุภาพ จริงๆเขาอาจจะ concern เกี่ยวกับว่าถ้าบริษัทปิดไปจะดูแลเขายังไงต่องี้
• Thank you board : เมื่อเราได้รับคำตอบหรือความช่วยเหลือนั้นๆ บอกขอบคุณคนคนนั้นให้เขาและเพื่อนร่วมงานเขาทราบ ซึ่งสามารถอยู่ใน Agile Retrospective เราขอบคุณใคร อย่างไร เมื่อเขาช่วยเหลือเรา
• feedback สำคัญ ให้ไปแล้วต้อง improve ได้

สุนัย สุขเอนก (นุ๊ก), Project Manager, BelD, "ส่งไม้ต่อ"

เล่าจากประสบการณ์การทำงานที่ที่สอง จากคน 20 คนขยายเป็น 150 คน เป็นบริษัทกึ่ง start-up กึ่ง software house เกี่ยวกับประกันภัย พอคนเริ่มเยอะขึ้นเวลาคุยงานกันจะต้องมีตัวแทน และทำให้ทำงานช้าลง เช่น deliver product ให้ user ใช้ หรือคุยงาน ซึ่งแต่ละคนทำงานร่วมกัน

และมีพี่คนนึงได้บอกเขาว่า

เรารับไม้มาจากใคร และส่งไม้ต่อให้กับใคร

การประชุมรวมของบริษัทนั้น มีจุดประสงค์ในการจูงใจให้พนักงานทำงานได้ดีขึ้น ก็เลยหยิบประโยคนี้มาเล่า จึงวาด diagram แบ่งเป็นดังนี้

• Tier 1 : คนที่สื่อสารในทีมบ่อยๆ มีใครบ้าง?
• Tier 2 : คนที่ทำงานต่อจากคนที่เราส่งต่อ เป็นใคร?

จากนั้นหาความสัมพันธ์ และแก่นของสิ่งที่เราทำคืออะไร? คือมี Value Proposition มีเป้าประสงค์ต่อสิ่งนั้น เช่น biker ที่มี performance ดีจะได้เงินพิเศษ ทำให้เขามีเงินจ่ายค่าเทอมลูก หรือได้ของ เป็นการส่ง inpact ต่อชีวิตเขา

บาง feature ที่ทำบางอย่าง nice to have ส่งผลกับชีวิตเราได้อย่างไร และปลายทางเขาใช้ของเราแล้วรู้สึกเป็นอย่างไร?

การทำงานให้เสร็จทันเวลา หรือเสร็จก่อนเวลา ทำให้คนรับไม้ต่อมีเวลาไปทำอย่างอื่นมากขึ้น

และทำอะไรให้พอดี คนได้รับไม้ต่อจากเราก็จะได้พอดีเช่นกัน

สรุป : วาด diagram Tier 1 และ Tier 2 ทำให้เราเห็นความสำคัญและเห็น impact กับงานที่เกิด ทั้งคนและระบบ และไม้ต่อของเราคือใคร

ภวิศ นพรุจ (อิศร์), UX Design Manager, SCB TechX, "รับงานมาทำต่อ"

เมื่อเราได้รับ assignment มา และรับงานจากทีมก่อนหน้า ซึ่งเป็นเรื่องปกติที่เราพบเจอกัน เราจะทำอย่างไรต่อ? ใน session นี้รวบรวมเทคนิคมาแชร์ให้ฟัง ทางเราบอกเลยว่าเนื้อหาแน่นมาก จดกันแทบไม่ทันเลยหล่ะ

1) การเข้าใจเป้าหมาย และจุดเริ่มต้นของมัน

• เข้าใจ problem statement — ถามอย่างมีศิลปะ เราอยากจะรู้เพื่ออะไร เช่น อยากรู้จักเริ่มต้น เพื่อแก้ไขปัญหา หรือ business problem เช่น ธุรกิจอยากเพิ่มยอดขาย แบะพยายาม relate back เช่น การสร้างกำไร ขึ้นกับโจทย์ว่าเราอยากได้อะไร มุ่งที่ short desk ของปัญหานั้นไปเลย หรือแก้ปัญหาใหม่ๆ ใน area ใหม่ๆ ที่อาจจะเป็นสิ่งที่จะให้ solve ได้ในอนาคต หรือมีตัวอย่างจุดเริ่มต้นของปัญหาในหลายๆรูปแบบ
• link ไปภาพปลายทาง ว่าเราวาดภาพความสำเร็จเหมือนกันไหม เช่น มีการวัดผล

2) เข้าใจรายละเอียดของงาน ว่าต้องทำอะไรบ้าง?

• เริ่มลงรายละเอียดว่า scope งานของคืออะไร? อะไรที่ควรทำ? อะไรที่ไม่ควรทำ? ใช้เทคนิคในการ make sure เช่น วาดรูปเป็นภาพ ทำให้เรา clear scope ให้เข้าใจตรงกันและ sure understanding
• จัด priority ว่าเราควรทำอะไรกันก่อน และได้ value อะไรกลับมา ตรงกับจุดเริ่มต้นไหม ช่วยตอบโจทย์ หรือ problem ที่มีไหม และ frame ว่าทำอะไรก่อนดี
• คุยว่างานนี้ปิดจบยังไง ปิดจบที่ใคร เพื่อให้เรา imagnie ภาพล่างหน้าง่าเราจะเล่าให้เขาฟังยังไงบ้าง
• เราไม่จำเป็นต้องเริ่มจากศูนย์ก็ได้ เช่น มีทีมอื่นทำคล้ายกัน เราสามารถ reuse หรือหยิบไปใช้ต่อได้ไหม และมีปัญหาอะไรที่เจอบ้าง ดังนั้นจะต้อง define ว่าอะไรคือ known list และ unknows list ในการ priority งาน
• target date ให้เสร็จเมื่อไหร่, มี milestone checkpoint ระหว่างทาง และมี dependency ว่ามีใครจะเอาไปใช้ต่อระหว่างทางไหม เพื่อลง detail ได้

3) เข้าใจวิธีการจัดการในงานนั้นๆ

• อย่าลืมถามว่าถ้าติดต่อคนหลักไม่ได้ ติดต่อคนรองที่ใคร? เพื่อให้ make sure ว่าเราทำงานต่อได้ ทำให้เราไม่เคว้ง
• มี guideline ที่ชัดเจนว่าจะให้ประสบการณ์กับเรื่องอะไร โดยมี criteria ที่นำมาตัดสินใจ 3 อย่าง คือ speed, performance และ money ถ้าเราต้องการความเร็วและ performance ดี จะต้องลงเงินเยอะ แต่บางสถานการณ์อาจจะต้องลด scope ลงมา
• แต่ละ situation ไม่สามารถคุยได้ทุกเรื่อง เราจะเจอตอนทำงานระหว่างทาง

สรุป : context ในการทำงานนี้เพื่ออะไร และมี definition of done คืออะไร สามารถวัดผลได้อย่างไร และเข้าใจ value ความเป็นมนุษย์ เราทำสิ่งนั้นไปเพื่ออะไร

ตอนมาที่ Part 2 everyone's experience จะเป็นช่วงให้คนฟังขึ้นมาแชร์ประสบการณ์ หรือสอบถาม speaker ซึ่งเงียบเหงามาก ก็เลยเป็นช่วงชวนคุยของพี่ๆ ซึ่งหลังๆก็ไม่ได้จด เพราะเริ่มดึกแย้ววว

ทำไมต้องเป็นเราทำงานชิ้นนี้?

อาจจะมี 2 ประเด็น คือ

• งานนี้เป็นของทีมเราหรือทีมอื่น
• เขาหา value อะไรในตัวเรา

Visualize อะไรที่ไม่ work

• Visual Thinking วาดรูปง่ายๆ คนไม่กล้าในการวาด ถ้าวาดง่ายเกินไป อาจจะแอบดูยาก อ่จจะเขียนภาพประกอบรูปสั้นๆ เพื่อให้เราเข้าใจได้เร็ว
• ดู screenshot ไม่ออกว่าเขาจะสื่ออะไร? จะสื่ออะไรให้ชัดเจน ต้องลงแรงอีกนิดหน่อย อาจจะวงกลม แล้วใส่ annotation ต้องดูว่าสื่อสารแบบไหน ให้ balance คุณภาพและความเข้าใจ
• วาด diagram แล้วไม่คุ้นชินกับเครื่องมือ หรือไม่ค่อยได้วาด ทำให้กะระยะห่างไม่ถูก ให้ลองวาดด้วยมือด้วยพื้นที่จำกัด เพื่อฝึกการสื่อสารด้วยภาพได้ดีขึ้น
• รูปอาจจะแก้ยากกว่า text ซึ่ง text ลบได้ แต่รูป speed การแก้จะช้ากว่า text

อื่นๆ

มีคนขึ้นมาแชร์บ้าง แต่จบไม่ครบ เริ่มมึนๆง่วงๆ เพราะดึก

• audient แต่ละคนมีพื้นฐานต่างกัน เช่น มี Android Developer ถามว่า service ทำงานยังไง? ซึ่งเขาจะงงว่าถามทำไม จริงๆบางทีคือเขาไม่รู้ แต่ทำงานได้ และให้ความสำคัญไม่เท่ากันด้วย ดังนั้นให้เข้าใจก่อนที่จะสื่อสารยังไง
• ทุกงานมี intent ว่าเราต้อง aware อะไร และจะส่ง message อะไรให้คนฟัง ดังนั้นเราจะมี self aware เรามี intent อะไรกับคนนั้นๆ เช่น จะคุยเรื่องนี้กับใคร เช่น present งานให้หัวหน้าฟัง
• presentation แต่ละหน้าเราจะสื่อสาร เช่น ขอเงินในการทำ project สื่อสารให้ชัดเจนว่าเราจะเอาเงินไปทำอะไร
• soft skill ไม่ใช่เรื่องเบาๆ เป็นเรื่องหนัก ใช้ประสบการณ์ปรับไปเรื่อยๆ
• presentation เช่น อยากให้คนเล่นเกมส์เสร็จแล้วรู้สึกยังไง เช่น มั่นใจ ตื่นเต้น มีคำถามไปถามเราต่อ ทำให้เราเริ่มสร้างจาก emotion ก็ได้
• draw.io ใช้วาด diagram และสามารถสื่อสารภายในทีมแบบไม่มีกำแพงภาษา และสามารถ integration ใน VS Code ด้วยนะ โดยจะเป็นไฟล์ draw.io.svg สามารถเปิดด้วย draw.io แล้วแก้ไขได้
• มีคำถามนึง จด detail ได้ไม่ครบ คือ soft skill ช่วยคน burn-out ได้อย่างไร? ก่อนอื่นเราต้องหาคำตอบก่อนว่า burn-out เกิดจากอะไรได้บ้าง ในที่นี้จะให้ burn-out เกิดจากการทำงาน support ตลอดเวลาแบบ 24x7 ที่จดคร่าวๆ คือ manager ต้อง support ให้อย่างจริงจัง และลดจำนวนของปัญหาลงได้, มีเรื่อง people management, keep talent ให้คนเก่งในทีมยังทำงานอยู่กับเรา, check-in 1-on-1 มีอะไรที่ลูกน้องอยากคุยกับหัวหน้าไหม และมีการ catch up ช่วยเหลือให้เขาเติบโตในเส้นทางที่เขาต้องการ และ happy ไปด้วยกัน

และรอบหน้าจะเป็นหัวข้อ Self Management ตามหา speaker หน้าใหม่ ถ้าใครสนใจสามารถติดต่อคุณ Sakul หรือคุณ Mahasak ได้นะฮับ ทางเราจะรอฟัง เพราะฉันเองก็ self management ไม่ค่อยรอดเหมือนกัน แหะ

สามารถ support ค่ากาแฟเจ้าของบล็อกได้ที่ปุ่มแดงส้มสุดน่ารักที่มุมซ้ายล่าง หรือกดปุ่มตรงนี้ก็ได้จ้า

กด follow Twitter เพื่อได้รับข่าวสารก่อนใคร เช่น สปอย content ใหม่ หรือสรุป content เร็วๆในนี้จ้า

ติดตามข่าวสารและบทความใหม่ๆได้ที่

download แอพอ่านบล็อกใหม่ของเราได้ที่นี่

MikkiPastel - Apps on Google Play

First application from “MikkiPastel” on play store beta feature- read blog from https://www.mikkipastel.com by this application- read blog content by chrome custom tab- update or refresh new content by pull to refresh- share content to social network

Apps on Google PlayMikkiPastel Studio