เมื่อต้องขยับไปเป็นเทคลีด (From an engineer to a technical lead)
พอถึงจุดนึงในชีวิต หัวหน้าจะเลื่อนขั้นคุณ แต่อย่าด่วนดีใจไป เพราะการเลื่อนขั้นมักจะมาพร้อมกับภาระหน้าที่ที่เพิ่มขึ้น (ส่วนจะขึ้นเงินเดือนให้รึเปล่านี่อีกเรื่องนึง)
สำหรับคนที่ไม่ได้อยากทำสาย People Management (เช่น ไปเป็น Engineering manager) ส่วนใหญ่ก็มักจะได้รับการเลื่อนตำแหน่งให้เป็น Technical lead (หรือบางที่ก็เรียกว่า Project lead) ที่คอยดูแลภาพรวมของโปรเจ็คหรือโปรดักต์ และคอยกระจายงานให้กับคนในทีม
จากประสบการณ์ส่วนตัว การขยับไปเทคลีดมักจะไม่ได้มีการเตรียมพร้อมกันให้ดี ส่วนใหญ่มักจะเกิดขึ้นเพราะมีเทคลีดคนเก่าออก หรือไม่ก็ค้นพบว่าทิศทางมันมั่วมาก ควรจะมีใครสักคนคอยดูแลเรื่องนี้
ถ้าเทียบกับตอนเริ่มทำงานใหม่ๆ อย่างน้อยคุณก็จะมีเมนเตอร์หรือพี่เลี้ยงในทีมคอยช่วย แต่พอเลื่อนทำแหน่งเป็นเทคลีด หัวหน้ามักจะคิดว่าคุณทำได้ทันทีโดยไม่ต้องมีพี่เลี้ยงหรือชั่วโมงทดลองบิน ซึ่งก็มักจะนำมาซึ่งความฉิบหายในโปรเจ็คแรกๆ ก่อนที่จะเข้าที่เข้าทาง (อันนี้ผมเองเลย)
บทความนี้เสนอข้อแนะนำ 3 ข้อ สำหรับเทคลีดมือใหม่ครับ
- เลือก Scope, Time, และ Quality ใหม่เหมาะสม
ไม่ว่าคุณจะมี Project manager ประกบหรือไม่ หน้าที่ของเทคลีดคือเป็นกันชนให้กับคนในทีม ไม่ให้ทีมต้องรับงานที่ต้องปั่นกันจนไม่ได้หลับไม่ได้นอน
โปรเจ็คส่วนใหญ่ เกือบ 80% มันไม่ทันตั้งแต่ตอนเริ่มแล้ว เพราะ Scope ไม่ชัดเจน หรือใหญ่เกินไป เวลาก็จำกัด แถมบางทีจะเอาโค้ดที่คุณภาพดีๆอีก หน้าที่สำคัญของเทคลีดคือการเจรจากับลูกค้า (หรือ PM) ว่า อันนี้ไม่ทันหรอก ต้องตัดบางฟีเจอร์ออกไป ไม่ก็ต้องรอนานกว่านี้
อย่าหวังว่า PM หรือ System analyst จะคิดเรื่องนี้ให้คุณ อย่ารับงานมาดื้อๆโดยไม่เจรจา เพราะคนพวกนั้นไม่ได้เขียนโค้ดเอง เค้าไม่มีทางกะแม่นได้เท่ากับทีมคุณ และเค้าไม่ต้องมาอดนอนปั่นงานกับคุณ . 2. จัดการกับ Stakeholder ให้เหมาะสม
หนึ่งในปัญหาของคนที่เป็นทีมลีดใหม่ๆ คือไม่เข้าใจ(อย่างถ่องแท้)ว่านี่เป็นหน้าที่และบทบาทใหม่ จะทำแบบเดิมไม่ได้
ทำแบบเดิมคือโฟกัสแค่เรื่องเทคนิคัลอย่างเดียว ในตำแหน่งนี้ คุณต้องจัดการกคนที่คุณต้องทำงานด้วยในอีกรูปแบบ ยกตัวอย่างสองตำแหน่ง
2.1 หัวหน้า - สมัยก่อน หัวหน้าอาจจะคุยกับคุณแค่รายละเอียดงานส่วนที่คุณทำอยู่ หรือเรื่อง Career path
แต่พอเป็นเทคลีด คุณต้องคุยถึงภาพรวมของโปรเจ็คทั้งหมดด้วย อาจจะต้องคุยเรื่องคนหรือโปรเซสภายในทีม ว่าต้องมีการพัฒนาทักษะตรงจุดไหน เพื่อให้มีประสิทธิภาพมากขึ้น
ตัวอย่างเช่น พอเป็นเทคลีด ผมเริ่มต้องเสนอว่ามีโค้ดส่วนไหนที่เราใช้ซ้ำบ่อยๆในหลายๆโปรเจ็ค เอามาทำเป็นไลบรารี่เพื่อประหยัดเวลาได้, เสนอมาตรฐานในการทำ Continuous Delivery Pipeline อย่างไร ส่วนไหนบ้างที่ใช้ซ้ำกันได้ทุกโปรเจ็คหรือทุกทีม, เสนอว่ามีปัญหาไหนที่เกิดขึ้นเป็นประจำแทบทุกโปรเจ็ค พร้อมเสนอวิธีแก้ไข
2.2 ลูกค้า - หลักๆของลูกค้าคือตกลงเรื่องเวลาส่งมอบ คุณภาพ และสโคปให้ชัดเจน หลายๆครั้งลูกค้าไม่มีความรู้ด้านเทคนิคัล อาจจะขออะไรที่ทำยากมาก แต่ไม่ได้ต้องการจริงๆ เทคลีดที่ดีจึงต้องทำความเข้าใจความต้องการของลูกค้าให้ชัดเจน และช่วยให้ข้อมูลกับลูกค้าในการตัดสินใจ
ตัวอย่างเช่น โปรเจ็คนึงบรีฟตอนแรกคืออยากทำดาต้าเลคเพื่อเอาข้อมูลมาประมวลผล ต้องทำ Integration กับระบบที่มีเพื่อดูดข้อมูล, ต้องคลีนดาต้าแล้วก็เอาเข้าดาต้าเลคอัตโนมัติ, แล้วก็มี API ให้ดึงข้อมูลด้วย พร้อมโมไบล์แอพ (iOS, Android) เพื่อดูสรุปข้อมูลบนนั้น มีเวลาให้หนึ่งเดือน เลื่อนไม่ได้
คุยไปคุยมา ปรากฏว่าลูกค้าแค่อยากทำ Proof of concept ไปเสนอให้CTOอนุมัติในอีกหนึ่งเดือนข้างหน้า หลักๆคืออยากให้เห็นว่าข้อมูลส่วนนี้มีมูลค่ามาก สามารถเอาไปทำอะไรได้หลายอย่าง ส่วนที่สำคัญที่สุดคือโมไบล์แอพ ซึ่งเป็นของ iOS หรือ Android ก็ได้ จะได้เอาไปเดโม่ให้ CTO
ส่วนที่อยากได้ดาต้าเลคคือได้ยินแผนกข้างๆเค้าทำอยู่ เลยอยากลองทำบ้าง . อันนี้เป็นตัวอย่างที่ค่อนข้าง Extreme (อ้างอิงจากโปรเจ็คชีวิตจริงผมเอง) เรื่องของเรื่องคือ กว่าที่ Requirement จะมาถึงเรา พวกบริบทมันหายไปในการสื่อสารระหว่างทางเยอะมาก อย่างเคสนี้ ถ้าไม่ได้ไปนั่งคุยกับลูกค้า มองแค่ Requirement อย่างเดียว โปรเจ็คมันเป็นไปไม่ได้เลยใน 1 เดือน แต่พอไปคุยรายละเอียด เราจะพบว่าไอ้ Technical requirement หลายๆอย่าง จริงๆแล้วมันไม่ได้จำเป็นเลย ลูกค้าสามารถตัดออกได้ หรืออาจจะมีวิธีอื่นที่ดีกว่าด้วยซ้ำ 3. มี Definition of Done กับ Acceptance criteria ที่ชัดเจนให้กับคนในทีม
สำหรับคนในทีม เราต้องสื่อสารให้ชัดเจน ว่าเราต้องการอะไรจากเขา
ปกติเทคลีดจะเป็นคนวางดีไซน์ภาพรวมของระบบจาก Requirement แล้วก็แตกงาน (Task) ย่อยๆออกมา หลังจากนั้นก็กระจายงานให้กับคนในทีม
แต่ละคนก็มีเทคนิคต่างกันไป วิธีที่ผมชอบทำ คือดึง Engineer เข้ามาช่วยประเมิน Scope ให้มากที่สุด และให้ทุกคนช่วยกันเขียน Acceptance criteria ในแต่ละ Task ด้วย วิธีนี้จะทำให้ทุกคนมีความรู้สึกว่าเป็นเจ้าของงาน และเข้าใจขอบเขตของงานแต่ละชิ้นตรงกัน
Acceptance criteria คือเส้นชัยของาน ต้องกำหนดให้ชัดเจนว่าอะไรอยู่ในขอบเขตของงานนี้ อะไรที่ไม่อยู่ พวกนี้ต้องเขียนให้เคลียร์มากๆ ไม่งั้นจะเข้าใจไม่ตรงกันแล้วออกทะเล หรือทำมาเสร็จแบบลวกๆ (เช่น ไม่เช็ค Edge case, ไม่ Catch error, ไม่มี metrics ไว้เช็คบนโปรดักชั่นว่าพังรึเปล่า)
อีกอันคือ Definition of Done เป็นข้อกำหนดที่ใช้กับทุกงานโดยอัตโนมัติ เช่น ต้องมี Unit test ที่ Coverage เกิน 90%, ต้องรันผ่าน Linting tool, ต้องรันผ่าน Integration tests ใน Dev Environment ก่อนปิด Task พวกนี้ผมจะให้มีเช็คลิสต์ตอบทำพวก Pull request/Code review เพราะคนมักจะลืมกัน
สำหรับคนที่ Junior มากๆ บางทีผมจะลงไปนั่งช่วย Design พวกคลาสให้ก่อนเลย ว่า Interface ต้องเป็นประมาณไหน ต้องมี Test cases อะไรบ้าง ส่วน Engineer ที่ผมเชื่อมือแล้ว ผมจะพยายามไปยุ่งกับเค้าให้น้อยที่สุด แต่จะมีกำหนดคุยกันเป็นระยะๆเพื่อให้ชัวร์ว่าเข้าใจตรงกัน
สรุป คนที่เป็นเทคลีดใหม่ๆ ต้องเข้าใจว่านี่คืองานใหม่ที่ Job description คล้ายงานเก่า (เพราะยังต้องดีไซน์และเขียนโค้ดด้วย) แต่เนื้องานจริงๆต่างจากงานเดิมเยอะมาก โปรเจ็คแรกๆเลยมักจะสะดุดหกล้ม เจ็บกันเยอะ
ผู้อ่านท่านใดมีประสบการณ์ด้านนี้ และมีข้อแนะนำอื่น เพิ่มเติมกันในคอมเม้นต์ได้นะครับ
---
ติดตามบทความสำหรับโปรแกรมเมอร์ทั้งด้านได้ที่ Facebook page Not about code หรือ Twitter @notaboutcode บทความของเพจจะเน้นเนื้อหาที่นำไปใช้ได้กับชีวิตจริง แต่ไม่ยึดติดกับเทคโนโลยีหรือภาษา เช่น System Design, Continuous Delivery, Testing, Career, etc.
สำหรับท่านที่อยากสนับสนุนผู้เขียน รบกวนช่วยแชร์โพสต์ในเฟสบุ้คให้กับเพื่อนๆที่น่าจะสนใจหัวข้อพวกนี้ด้วยครับ