ก้าวแรกของการเป็น Team Lead ที่ Ecosoft

วันแรกที่ผมถูกเรียกว่า “Team Lead” งานที่ผมทำไม่ได้เปลี่ยนทันที

IDE ยังเปิดอยู่ Support ยังมี task และโค้ดก็ยังต้องเขียนเหมือนเดิม

แต่มีบางอย่างเปลี่ยนไปแบบเงียบ ๆ เป็นความรู้สึกที่ถามตัวเองอยู่ในใจว่า มันถึงเวลาแล้วจริง ๆ หรอ

”เราพร้อมแล้วหรือยัง”

บทความนี้ไม่ใช่คู่มือการเป็น Team Lead และไม่ใช่ success story แต่มันคือบันทึกของคนที่กำลังก้าวเข้าบทบาทนี้เป็นครั้งแรก พร้อมกับความสับสน ความผิดพลาด และบทเรียนที่ได้จากโปรเจกต์ที่ยังเดินอยู่แค่ครึ่งทาง

ตอนเป็น developer ปัญหาส่วนใหญ่มักมีคำตอบ

• error แก้ได้
• performance วัดได้
• bug มี root cause

เพราะคอมพิวเตอร์ไม่เคยหลอกใคร

แต่เมื่อรับบทเป็น Team Lead ปัญหาหลายอย่างกลับไม่มีคำตอบที่ชัดเจน

มันไม่ใช่เรื่องของโค้ดอีกต่อไป แต่เป็นเรื่องของคน เรื่องของการตัดสินใจ และเรื่องของการบริหารในสิ่งที่ไม่มีสูตรตายตัว

ความท้าทายของการทำโปรเจค

1. จำนวนคนที่มีจำกัด

โปรเจกต์นี้มีทีมหลักอยู่ 3 คน คือ Team Lead, Business Analysis และ Developer โดยมี Project Manager คอยดูภาพรวมเป็นระยะ

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

2. การสื่อสารภายในทีม และกับลูกค้า

การเปลี่ยนจาก Developer มาเป็น Team Lead ทำให้ผมเจออุปสรรคที่ไม่คุ้นเคยมาก่อน นั่นคือ “การสื่อสาร”

ในโลกของโค้ด คำตอบมักชัดเจน ไม่ Yes ก็ No ไม่ผ่านก็ Error

แต่การสื่อสารกับคน ทั้งภายในทีมและกับลูกค้า คำตอบกลับไม่แน่นอน ต้องตัดสินใจว่าจะ ทำ หรือ ไม่ทำ และต้องอธิบายเหตุผลให้ทุกฝ่ายเข้าใจไปในทิศทางเดียวกัน

การเลือกใช้คำก็สำคัญ ศัพท์เทคนิคมากเกินไป ลูกค้าก็ไม่เข้าใจ ศัพท์เฉพาะของลูกค้า เราก็ต้องเรียนรู้

เพื่อให้การสื่อสารไม่หลุดโฟกัส และไม่สร้างความเข้าใจผิดในระยะยาว

3. ความเข้าใจใน Core Framework (Odoo 18)

โปรเจกต์นี้เป็นโปรเจกต์แรกที่ใช้ Odoo Version 18 ซึ่งแต่ละเวอร์ชันจะมีการปรับโครงสร้างและการทำงานบางอย่างที่แตกต่างกัน

การเข้าใจหลักการทำงานและข้อจำกัดของ Core Framework ช่วยลดการ Customize Module ที่ไม่จำเป็น

ไม่ใช่ว่าการ customize เป็นสิ่งที่ไม่ดี แต่ยิ่ง customize น้อยเท่าไร ระบบก็ยิ่งเสถียร และปัญหาในการดูแล Support ในอนาคตก็ยิ่งลดลงเท่านั้น

4. การรับงานใน Industry ที่ยังไม่คุ้นเคย

แม้จะเคยทำโปรเจกต์ใกล้เคียงกันมาก่อน แต่ไม่ได้เป็นคนเริ่มตั้งแต่ต้น รวมถึงเป็นคนละเวอร์ชันของระบบ

ทำให้ต้องใช้เวลาเรียนรู้ทั้ง domain และ technical เพิ่มขึ้นกว่าที่คาดไว้

5. เอกสารการส่งมอบลูกค้า

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

หากเอกสารล่าช้า การส่งมอบก็ล่าช้า และอาจมีค่าปรับตามมา

ทีมจึงต้องแบ่งเวลาให้กับงานเอกสารอย่างจริงจังไม่แพ้การพัฒนา

6. การเชื่อมต่อกับระบบภายนอกหลายระบบ

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

7. ระบบเดียว ใช้ร่วมกันหลายหน่วยงาน

ระบบที่ผมรับผิดชอบนี้ถูกใช้งานร่วมกันโดย 3 หน่วยงาน การเก็บ requirement และการทดสอบ จึงต้องได้รับความเห็นร่วมกันจากทุกฝ่าย

ความท้าทายคือ ตารางเวลาของแต่ละหน่วยงานไม่ตรงกัน การประชุมจึงต้องวางแผนล่วงหน้าอย่างรอบคอบ เพื่อให้ทุกฝ่ายมีส่วนร่วมในทิศทางเดียวกัน

เครื่องมือที่ช่วยให้ทีม “ยังไปต่อได้”

หลังจากรับบท Team Lead ได้สักระยะ ผมเริ่มเห็นว่า สิ่งที่เคยเป็นเพียง “เทคนิคเสริม” กำลังกลายเป็น “เครื่องมือหลัก” ที่ช่วยพาทีมรอด และลดภาระของทุกคน

1. Test Script ที่เชื่อถือได้

นักพัฒนาส่วนใหญ่น่าจะคุ้นเคยกับการเขียน Test Script บางที่มี Tester โดยเฉพาะ บางที่ไม่มี

ลองนึกภาพว่า เมื่อเพิ่มหรือแก้ไข feature หนึ่งเข้าไป เราจะมั่นใจได้อย่างไรว่า มันจะไม่กระทบกับสิ่งที่เคยทดสอบกับลูกค้าไปแล้ว

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

การยอมใช้เวลาประมาณ 1/3 ของเวลาพัฒนา เพื่อเขียน Test Script ช่วยให้การเพิ่ม feature ในอนาคตทำได้มั่นใจขึ้น

deploy production ได้ถี่ขึ้น และลดความเสี่ยงของ bug ที่ย้อนกลับมา

2. เข้าใจ Core Framework มากพอที่จะ “กล้าปฏิเสธ”

ไม่ใช่การปฏิเสธทุกอย่างที่ลูกค้าขอ แต่คือการปฏิเสธในสิ่งที่

ระบบทำไม่ได้ ไม่อยู่ใน Scope หรือตาม TOR หรือทำไปแล้วไม่มีใครใช้งานจริง

การปฏิเสธอย่างมีเหตุผล ช่วยปกป้องทั้งทีม และคุณภาพของระบบในระยะยาว

3. การลงทุนกับ DevOps เพื่อคืนเวลาให้ทีม

การทำให้โปรเจกต์สำเร็จนั้นยาก แต่การทำให้ระบบใช้งานได้ยาว ๆ นั้นยากกว่า

DevOps ที่ดี ช่วยให้ทีมไม่ต้องกังวลว่า deploy แล้วจะพังไหม คำสั่งถูกต้องหรือเปล่า และเปิดทางให้ระบบสามารถพัฒนาต่อยอดได้ในอนาคต

4. การเขียนโค้ดให้รองรับการ Config ในระบบ

บทเรียนนี้ได้มาจากการพัฒนา API เพื่อเชื่อมต่อระบบภายนอก ช่วงแรกการเขียนค่าไว้ในโค้ดดูสะดวก แต่เมื่อคิดถึงอนาคต หากมีการเปลี่ยน path หรือ field ต้องกลับมานั่งไล่โค้ด และต้องพึ่ง Developer ทุกครั้ง

สุดท้ายจึงออกแบบให้สามารถ Config ได้จากหน้าระบบ เปิดโอกาสให้ Admin หรือ Support สามารถปรับแก้ได้เอง โดยไม่ต้องแก้โค้ดหรือ deploy ใหม่

5. Project Plan คือเข็มทิศของโปรเจกต์

เมื่อทำงานไปสักระยะ เรามักจะติดอยู่กับปัญหาตรงหน้า จนลืมภาพรวม

Project Plan เลยไม่ใช่แค่เอกสาร แต่มันคือเข็มทิศที่คอยเตือนว่า ตอนนี้เราควรอยู่ตรงไหน อะไรคือสิ่งที่ยังทำให้ไปไม่ถึงขั้นถัดไป และอะไรคือปัญหาที่ “ยังไม่ควรแก้” ในตอนนี้

6. คู่มือ และ Test Case

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

ในมุมของทีมพัฒนา มันยังช่วยลดการเข้าใจผิดตั้งแต่ช่วงทดสอบ ลดการแก้ไขวนซ้ำ และทำให้การคุยกับผู้ใช้งานมี “จุดอ้างอิงเดียวกัน”

สิ่งหนึ่งที่มาพร้อมกับบทบาท Team Lead คือความเครียด

ไม่ใช่ความเครียดจากโค้ด แต่เป็นความเครียดจากความรับผิดชอบ การตัดสินใจ และความรู้สึกว่า “ถ้าตรงนี้พัง คนแรกที่ต้องอธิบายคือเรา”

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

บางช่วงถึงขนาดมองไม่เห็นภาพข้างหน้า ไม่มั่นใจว่าจะพาโปรเจกต์ไปถึงจุดนั้นได้หรือเปล่า ไม่รู้จะถามใคร และไม่รู้ว่าควรจัดการกับมันอย่างไร

ผมยังไม่รู้วิธีจัดการกับมันได้ดี แต่เริ่มเรียนรู้ว่า การยอมรับว่ามันมีอยู่ “คือก้าวแรกของการเป็น Team Lead เหมือนกัน”

By Saran L.