สิ่งที่ได้เรียนรู้จากการทำงานแนว consulting มา 1 ปี

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

1. การจัดการ technical debt ต้องมีขั้นมีตอน

สืบเนื่องจากบทความปีที่แล้ว เราได้รับ feedback ว่าให้จำกัดกรอบเวลาการทำ tech analysis และ improvement ซึ่งการมีกรอบเวลาทำให้เราใช้เวลาที่มีให้คุ้มค่าที่สุด โดยไม่รบกวนการส่งมอบ business value จนเกินไป สมมติว่าเรามี 10 งานที่ต้องส่งมอบ การที่ทีมหมกมุ่นกับการปรับปรุงเพียงแค่ 2 งาน หมายความว่าเราละทิ้งโอกาสในการทำงาน 8 งานให้เสร็จตามกำหนด ซึ่งอาจส่งผลเสียต่อด้านธุรกิจและ productivity ของทีมโดยตรง

ถ้าเราใช้เวลาในกรอบจนหมดแล้วแต่ยังไม่ได้อะไรคืบหน้า เราก็ทำให้เรียบง่ายที่สุดโดยที่ยังสามารถปรับแก้ทีหลังในลักษณะที่เรียกว่า technical debt ได้ โดยคำว่า “ทีหลัง” ก็คือการจัดลำดับความสำคัญของ technical debt นั่นเอง โดยให้เราเลือกงานที่ใช้แรงน้อยแต่ได้ประโยชน์มากก่อน แต่จะดีกว่าถ้าอันไหนแก้ได้ก่อนก็ทำเลย โดยที่ไม่ต้องมาจัดลำดับให้เปลืองแรง

TechnicalDebtQuadrant by Martin Fowler

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

• User experience: user สามารถค้นหาเพลงที่ตัวเองชอบได้เร็วขึ้นผ่านระบบ recommendation
• Performance: user สามารถเข้า website ได้โดยไม่ต้องรอนานเกิน x วินาที
• Scalability: รองรับจำนวนการใช้งานในช่วง peak hour ได้มากขึ้น
• Security: ป้องกันเหตุการณ์ที่อาจจะเกิดขึ้นได้โดยไม่คาดคิด ซึ่งมีผลต่อทรัพย์สินและชื่อเสียงของบริษัท

2. ตัดสินใจด้าน technical จากข้อมูลมากกว่าความรู้สึก

หลายครั้งที่ทีมพัฒนาจะต้องมีการตัดสินใจด้าน technical (technical decision making) จะมีเหตุการณ์เกิดขึ้นอยู่ 2 อย่าง

1. การพูดคุยวนอยู่ในอ่างไม่ได้ไปไหน ต่างคนต่างก็มีประเด็นของตัวเอง
2. ทีมขาดความมั่นใจว่า ตั้งสมมติฐาน (assumption) เพื่อประกอบการตัดสินใจนั้น ถูกต้องหรือไม่

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

อ่านต่อได้ที่ สรุปสิ่งที่ได้เรียนรู้จาก Software Architecture workshop ปี 2019

3. ทำตัวให้่ชินกับความไม่แน่นอนเข้าไว้

ในการพัฒนา software มีความไม่แน่นอนเกิดขึ้นอยู่ตลอด ไม่ว่าจะเป็น

• requirement เปลี่ยน
• โครงสร้าง team เปลี่ยน
• องค์กร เปลี่ยน
• budget เปลี่ยน (?)

ถ้าเป้าหมายของเราคือ ต้องส่งมอบ business value ให้ได้ดีอย่างต่อเนื่อง เราอาจจะสงสัยว่าเราจะต้องสร้างอะไรบ้างถึงจะทำให้ user ชอบ คำตอบก็คือไม่มีใครรู้ครับ แม้กระทั่งตัวของ user เอง ถ้า user รู้ตัวเองว่าอยากได้ smartphone เราก็คงไม่ได้เห็นหนึ่งใน presentation ที่มี impact ที่สุดของโลกอย่างการเปิดตัว iPhone โดย Steve Jobs

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

4. ใช้ภาษาเดียวกันกับ business

หนุ่งในปัญหาที่ยิ่งใหญ่ที่สุดในการพัฒนา software คือ การทำงานร่วมกัน หรือ collaboration หนึ่งในนั้นคือ

Poor communication among customers, developers, users and project managers

ซึ่งทำให้เกิด overhead ไม่ว่าจะเป็น

• ตอน requirement analysis
• ตอนทำการทดสอบ
• ตอนเขียน code ตั้งชื่อ class ชื่อ method!

เพื่อลดการเกิดปัญหาดังกล่าว ทีมพัฒนาควรจะใช้ภาษาเดียวกันกับ business (ubiquitous language) ส่งผลให้ความรู้ความเข้าใจในระบบเป็นไปตามสิ่งที่ผู้เชี่ยวชาญ (domain expert หรือ subject-matter expert) ได้บอกกล่าว จากประสบการณ์การใช้แนวคิดนี้ที่เป็น core concept ของ Domain-driven design (DDD) พบว่าลดอาการปวดหัวลงไปได้เยอะ เราเคยจดบันทึก technique การใช้งาน DDD ไว้

5. สิ่งที่ชอบทำอาจจะไม่ใช่สิ่งที่ทำให้เติบโต

แน่นอนว่าเราอาจจะเคยได้ยินคำพูดที่ว่า

เราไม่เถียงครับว่ามันไม่จริง เพราะเราในฐานะ developer สิ่งที่ชอบเท่าที่นึกได้ก็คือ การเขียน code วิเคราะห์ระบบ ตัดสินใจด้าน technical และเขียนเอกสาร เพื่อสั่งสมประสบการณ์ในการเติบโตเป็น developer ที่เก่งขึ้น

แต่ในชีวิตจริงสิ่งที่เกิดขึ้นในการสั่งสมประสบการณ์คือ

ทักษะที่ทำให้เราเติบโตในตำแหน่งต่อไป ≠ ทักษะที่ทำให้เราเป็นมหาเทพในตำแหน่งปัจจุบัน

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

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

• ปั้น developer คนอื่น ๆ ด้วยการเพิ่มพูนทักษะให้พวกเค้า
• สร้างระบบงานอัตโนมัติ เช่น CICD เพื่อให้ทีมได้ feedback ที่เร็วขึ้น ปรับแก้งานได้เร็วขึ้น

จะเห็นว่านอกจากจะไม่เสียสุขภาพจากการทำงานเกินเวลา เรายังสร้าง impact ให้กับทีมและ career ของ developer คนอื่น ๆ ได้ด้วย

6. It’s okay to say NO

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

ลูกค้า: ตอนนี้มีงานเข้ามา 4 feature ใหญ่ที่จะต้องส่งมอบทั้งหมดในอีก 6 เดือนข้างหน้า ทีมเราทำกันเองไม่ไหวหรอก ไปเอาอีกทีมนึงมาช่วยดีกว่า จะได้ส่งมอบสัก 2 feature ทันในอีก 3 เดือนข้างหน้า

เรา: การนำคนเข้ามาในทีมจะทำให้ทีมส่งมอบงานได้ช้าลงในช่วงแรก เนื่องจากจะต้องมีการ onboarding ทำความเข้าใจ business และ technical context การตกลงเรื่องการเขียน code รวมไปถึง path to production ซึ่งมีความเสี่ยงว่าเราอาจจะส่งมอบไม่ทันภายใน 3 เดือน เพื่อลดความเสี่ยงเหล่านี้ เราอาจจะแบ่งงานให้ทีมนั้นไปทำ โดยงานนั้น ๆ จะต้องไม่เกี่ยวข้องกับ context ปัจจุบันของเราดีไหมครับ

7. เราเท่านั้นที่เป็นคนกำหนด career ตัวเอง

แต่ก่อนเราเคยคิดว่า

ก้มหน้าก้มตาทำงานในตำแหน่งของเราให้ได้ดี ทำงานในตำแหน่งถัดไปให้ได้ สักวันต้องมีคนเห็นค่าเรา

สมมติว่าค่าตอบแทนไม่เป็นดั่งใจเรา ถ้าเป็นเราก็ย่อมโทษตัวเองว่า เราขาดอะไร เรายังต้องทำอะไรอีกหรอถึงจะได้เลื่อนตำแหน่ง ส่งผลให้เสียกำลังใจเพราะเราคิดว่าเราไม่สมควรได้รับในสิ่งที่ควรได้ แท้จริงแล้วคนเค้าเห็นค่าเราก็จริง แต่เค้าจะไม่ผลักดัน career ของเราหรอกเพราะเค้าจะ focus อยู่แค่ career ของเค้าเหมือนกัน ซึ่งก็ fair นะ เพราะ career เราไม่ได้มีส่วนได้ส่วนเสียอะไรกับ career ของเค้านิ การที่เค้าไม่ผลักดันเราไม่ได้ทำให้เค้าโดนไล่ออกซะหน่อย

Why You’re Not Getting Promoted (as an Engineer)

ดังนั้นเราเท่านั้นที่เป็นคนกำหนด career ตัวเอง เราจะต้องศึกษาว่า

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

จงอย่าได้รอให้ใครมาผลักดันเรา ไม่มีใครอยากให้เราได้เลื่อนตำแหน่งมากกว่าเราหรอกนะ

สรุป

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

ปิดท้ายด้วย impact ที่เรามีต่อตนเอง ทีม และองค์กรไปในรอบ 1 ปีซะหน่อย

• ใช้ presentation และ diagram ในการนำเสนองานให้ลูกค้าแทนที่จะกระโดดไปที่ code ทำให้ลูกค้าเข้าใจระบบงาน และเสนอความคิดเห็นเพื่อปรับปรุงได้ตรงจุดได้มากขึ้น
• แบ่งปันความรู้เกี่ยวกับการพัฒนา application ด้วยภาษา Java + Spring Boot framework เพื่อสร้างทักษะให้ developer คนอื่น ๆ ในทีม
• เสนอตัวเป็นคนนำพา ceremonies ต่าง ๆ ในทีม อย่าง retrospective และ tech huddle เพื่อให้ทีมได้ตระหนักและปรับปรุงการทำงานให้ดีขึ้น
• Onboard เพื่อนร่วมทีมใหม่ ให้สามารถส่งมอบ business value ได้รวดเร็วที่สุด
• เป็นที่ปรึกษาด้าน technical ให้กับคนในทีม เพื่อตัดสินใจแก้ปัญหาด้าน technical
• แจกจ่ายงาน production support แล้ว documentation บางส่วนให้สมาชิกคนอื่นในทีม เพื่อสร้างประสบการณ์ที่ดีต่อลูกค้าและเพิ่มความรู้ความเข้าใจในระบบ โดยให้สมาชิกได้ลองผิดลองถูกในบางส่วน และให้คำแนะนำแก่คนอื่น
• ถามคำถามและตั้งประเด็นที่มีผลต่อ user experience ทำให้เกิดการพูดคุยและเปลี่ยนแปลง requirement ให้ตอบโจทย์ลูกค้ามากขึ้น
• มีโอกาสไปแบ่งปันประสบการณ์และความรู้ในการใช้เครื่องมือ Testcontainers เป็นภาษาอังกฤษให้คนใน Southeast Asia ผ่าน video conference
• มีโอกาสไปแบ่งปันประสบการณ์และความรู้เกี่ยวกับแนวทางปฏิบัติ Mutation testing เป็นภาษาไทยให้คนไทยฟังผ่าน Facebook Live