TL;DR
ใช้ Communication tools ที่เหมาะสมกับการทำงาน (แนะนำให้ใช้ Workplace messaging แทน Social Messaging)
ควรมี Task Management ที่ทุกคนสามารถใช้งานได้ทั่วถึง
และ ทำ Peer Review ทั้งเชิง Technical และ Business ก่อน Deliver
เนื่องจากสถานะการแพร่ระบาดของเชื้อไวรัส COVID-19 ภายใต้บริษัทที่ผมทำงานอยู่จึงออกมาตราการให้ทุกคนทำงานจากที่บ้านถ้าหากเป็นไปได้
ตัดภาพมาที่ทีมที่ผมดูแลอยู่มี Developer จำนวน 6 คนและ Application ที่อยู่ในช่วง Development 1 โปรเจค ประกอบด้วย ชาวต่างชาติ 4 คนและคนไทย 2 คนและ
ทุกคนไม่เคยมีประสบการณ์ Remotely Working มาก่อน 😱
ความท้าทายของการทำงานแบบ Remotely Working คือการควบคุมขั้นตอนการทำงาน และการสื่อสาร
เนื่องจากโดยส่วนตัวแล้ว ผมเองไม่คิดว่าการทำงานแบบ Remotely หรือ Work From Home จะมีประสิทธิภาพดีกว่าการทำงานแบบ Face To Face ได้ในแง่ของการสื่อสาร
แต่ด้วยสถานะการบังคับ เราเลยต้องมีการวางแผนและออกแบบวิธีการทำงาน เพื่อให้ได้ประสิทธิภาพการทำงานเท่าเดิม (หรือดีกว่า) ให้ได้
ผมแบ่งหัวข้อในการออกแบบวิธีการทำงานของทีมเป็น
- การสื่อสาร - Communication
- การติดตามความคืบหน้า - Tracking
- การตรวจสอบคุณภาพงาน และส่งงาน - Peer Review and Deliver
🌏 1. การสื่อสาร - Communication
เราคงจะเถียงไม่ได้ว่า การเดินไปจิกงาน หรืออธิบายรายละเอียดของงานนั้น ทำได้ง่ายกว่าในกรณี Face To Face แต่เมื่อเราต้อง Remotely Working สิ่งสำคัญอันดับแรกก็คือ
Communication Tools
Party ที่สำคัญหลักๆในการพัฒนาซอฟแวร์ไม่ได้มีเพียงแค่ Developer อย่างเดียว
เพราะยังรวมถึง Business Analysis team, Business Unit team, Management team, Test team ซึ่งทั้งหมดควรมี Protocol ในการสื่อสารเหมือนกัน
ภายใต้กลุ่มบริษัทของผม เราใช้ Microsoft 365 เป็นหลักในการทำงาน ดังนั้น Policy ของบริษัทจึงแนะนำให้ใช้ Microsoft Teams
(สามารถเป็น อะไรก็ได้เช่น Slack, Hipchat, Facebook Workplace)
ก่อนหน้านี้ ทุกคนสามารถใช้ Line ในการสื่อสารได้เพราะว่า การสื่อสารเป็นแค่การ สื่อความเล็กๆน้อยๆไม่ซับซ้อน
แต่หลังจากที่ต้องทำงานแบบ 100% Remotely เราพบว่า Line ไม่สามารถตอบสนองความซับซ้อนของการสนทนาในหลายแง่เช่น
- การแยกบทสนทนาเป็นรายหัวข้อ ( การทำ Thread และ Post )
- การจัดการ Channel, Chatroom เครื่องมืออย่าง Slack และ MSTeam ทำได้ดีกว่า Social Messaging ทั่วไป
- การ Integrate เข้ากับ Cloud หรือ Storage ภายใต้ Microsft Office นั้น MS Team สามารถทำได้ดีกว่า Line มาก ในการแชร์เอกสารร่วมกัน
- การประชุมสาย MS Team สามารถทำได้ดีกว่า Line และสามารถ Record การสนทนาได้ และสามารถนัดประชุมล่วงหน้าได้ (ใช้ร่วมกันกับ Outlook Calendar)
Protocol ของการสื่อสาร
ภายใต้หัวข้อนี้จะพูดถึงการใช้งาน Microsoft Team เป็นหลัก
การใช้ Channel
ภายใต้ feature ของ Microsoft Team เราสามารถจัดการหัวข้อการสนทนาได้อย่างละเอียดกว่า Social Messaging ทั่วไปโดยภายใต้ทีมของผม เราใช้ Channel ในการสนทนาเชิงวิเคราะห์ต่างๆเช่น วิเคราะห์ Requirement, รายงานปัญหาที่เกิดจาก Release ต่างๆ
ภายใต้ Channel มีการทำ Annoncement และการ Posts
การใช้ Chat และ Group Chat
เนื่องจาก MS Team นั้นมี Feature การสนทนาค่อนข้างแตกต่างจาก Line และ Social Messaging ทั่วไป ชนิดของบทสนทนานั้นแบ่งออกเป็น
- Channel
- Post, Annoucement
- Meeting Chat
- Chat and Group Chat
ทั้งสามอย่างมีวิธีการใช้แตกต่างกันตามแต่ละทีมจะนำไปประยุกต์ใช้และเราใช้ Chat และ Group Chat กับการสนทนาประจำวัน
มีการรายงานสถานะประจำวันของแต่ละคน Daily Meeting
ทางทีมยังคงใช้รูปแบบการทำงานที่ชื่อว่า Agile อยู่ เรายังมีการทำ Remotely Daily Meeting ทุกวันในช่วงเวลาที่ทุกคนสะดวก ( 11:00am ) เพื่อให้ทุกคนสามารถรายงานความคืบหน้าและสถานะการของตัวเอง (เฉลี่ย ไม่ควรเกิน 20 นาทีต่อครั้ง)
หัวข้อของ Daily Meeting ประกอบด้วย
- เมื่อวานนี้ทำอะไร
- วันนี้ทำอะไร
- ต้องการให้ใครช่วย
ทำเอกสารให้มันใช้งานได้จริงๆ
หลังจาก Work From Home เราเน้นเรื่องเอกสารมากขึ้น ในการทำงานแต่ละ Issues
ยกตัวอย่างเช่น การทำ Merge Request จะต้องมี Template ของการทำ MR ชัดเจนเพื่อให้การทำ Peer Review ทำได้สะดวก
อื่นๆ
- เราใช้ Gitlab และการทำ Merge Request เพื่อทำ Peer review
- เราออกแบบ Git branching strategy ร่วมกันเพื่อให้การทำงานทุกคนไปในทิศทางเดียวกัน
ปัญหาที่เจอในการสื่อสาร
- สมาชิกทีมบางส่วนยังคุ้นเคยกับการใช้งาน Line มากกว่า เนื่องจาก Microsft Team ไม่ใช่ Social Messaging จึงมีขั้นตอนการใช้งานยุ่งยากมากกว่า Line ที่ออกแบบมาเพื่อการใช้งานอย่างเรียบง่าย การ Adopt ใช้ Microsoft Team ต้องมีการเรียนรู้เพิ่มเติมจาก เอกสารต่างๆหรือ Training Session เพื่อให้ใช้งานได้อย่างมีประสิทธิภาพ ทำให้บางส่วนของ Team ยังมีการใช้ Line ในการสื่อสารอยู่
- ปัญหา Internet Connection และ คุณภาพของ Microphone เนื่องจากทุกคนไม่คิดว่าการทำงานแบบ Remotely จะยืดยาวจึงไม่ได้มีการเตรียมพร้อมหา Internet Connection ที่พร้อมสำหรับการใช้งาน รวมถึงอุปกรณ์การสื่อสารต่างๆเช่น คุณภาพของ Microphone
- กำแพงด้านภาษา เนื่องจากภายในทีมมีชาวต่างชาติ การสื่อสารบางอย่างค่อนข้างติดขัดบ้าง เพราะว่าภายในทีมบางส่วนไม่คุ้นเคยกับการใช้ภาษาอังกฤษในการทำงาน
- ความขี้เกียจเขียนเอกสารของ Developer
🧑🏼💻 2. การติดตามความคืบหน้า - Tracking
อย่างที่กล่าวไปเบื้องต้นแล้วว่าเราใช้ Agile ในการทำงาน การสื่อสาร Tools ที่ทางบริษัทมีให้ใช้คือ Atlassian JIRA
เนื่องจาก Position ผมเองเป็น Technical Lead และ Scrum Master ไปในตัว เราจึงเป็นคนที่ควบคุมกระบวนการ การทำงานของทีมไปด้วย
โชคดีของเราคือ Test team มีการใช้งาน JIRA ร่วมกัน ทำให้การทำ Bug tracking นั้นสะดวกมากยิ่งขึ้น (ปกติทาง Test team ใช้ HPQC แต่ช่วยมาทำใน JIRA ให้ด้วย)
ทำให้เราสามารถ tracking งานต่างๆ และเห็นภาพรวมของโปรเจคได้ชัดเจน
เนื่องจากการใช้ JIRA และทำ Issue Tracking เรามีการปฏิบัติอยู่แล้วตั้งแต่ก่อน Work From Home จึงไม่มีอะไรกระทบมากนัก
Draft Release note ให้ชัดเจน
Release Note เป็นส่วนหนึ่งที่มีประโยชน์มากในการวางแผนการพัฒนาซอฟแวร์
การทำ Release Note ที่ดี จะทำให้เราสามารถกำหนดและสื่อสารสิ่งที่จะ Deliver มาได้ชัดเจน ให้กับลูกค้าหรือ ทีมอื่นๆที่จะต้องเข้ามามีส่วนร่วมในการพัฒนาซอฟแวร์
ปัญหาที่เจอ
- ในฐานะคนดูแล Sprint และ Technical ไปพร้อมกัน ทำให้บางครั้ง ข้อมูลต่างๆภายใน JIRA ไม่ได้ถูกอัพเดทตามต่อวัน
- Notification ใน JIRA เมื่อเกิด Activity ต่างๆ (เวอร์ชั่นเก่า) ยังไม่ดีเท่าที่พอใจ บางครั้งทำให้การ Response Issue ต่างๆใน JIRA ค่อนข้างช้า
- Integration ระหว่าง Gitlab กับ JIRA ทำได้ยาก เนื่องจากข้ามผลิตภัณฑ์กัน จึงไม่ Seemless เท่าที่ควร (ถ้าเป็น BitBucket จะสามารถ Integrate JIRA task เข้ากับ Merge Request ได้ง่ายกว่า)
🤖 📦 การตรวจสอบคุณภาพงาน และส่งงาน - Peer Review and Deliver
เนื่องจากซอฟแวร์ที่ดูแล มีขั้นตอนการทำงานในเชิงธุรกิจ ( Business logic and Functionality ) ที่ค่อนข้างซับซ้อนและครอบคลุมหลายผลิตภัณฑ์ในด้านการเงิน
ทำให้การส่งงาน ( Merge code ) จำเป็นต้องมีการ Review จากหลายส่วน เพื่อให้รองรับการดูแลรักษาในอนาคต (Maintainability)
จึงต้องมีการทำ Policy ต่างๆขึ้นมาเพื่อรองรับการทำงาน เช่น
- การส่งงานใน Merge Request ต้องครอบคลุมถึงการเขียน Test ที่สำคัญใน Merge Request Change นั้นๆ
- Convention ของการเขียนโค้ด (Code Style and Convention Guideline)
- Template ของการเปิด Merge Request
- Branching Strategy และการ Merge Request เข้า release branch ให้ถูกต้อง
- ทำ Technical Peer Review
- CI/CD เพื่อรัน Unit-test, Integration-test และ E2E-test
เรายังมีการจัด Business Functionality Review Session เพื่อให้ Business Team ได้เข้ามามีส่วนร่วมในการ Review ชิ้นงานแต่ละ Feature ก่อน Merge เข้า Stable Branch
สรุป
เขียนมาถึงตรงนี้ก็หมดแรงแล้ว ถึงอย่างไรบทความข้างต้นเป็นการออกแบบการทำงานเพื่อรองรับกับทีมที่ผมเป็นคนดูแลอยู่
สุดท้ายแล้วการทำงานจะเป็นแบบไหนขึ้นอยู่กับลักษณะเฉพาะของงาน และทีมที่เราทำงานอยู่ด้วย
การทำให้ทีมทำงานได้อย่างมีประสิทธิภาพ ต้องอาศัยการทำความเข้าใจคนภายในทีม รูปแบบการทำงาน นิสัย ทัศนคติ เพื่อนำมาออกแบบวิธีการทำงานให้เกิดประสิทธิภาพสูงสุด
Top comments (0)