สรุป software development journey ปี 2024

ครั้งแรกกับการ(เกือบ)เป็น partner กับลูกค้า

เมื่อต้นปีมีโอกาสได้เข้าไปกับทีมเพื่อประเมินระบบ Software-as-a-Service (SaaS) ให้กับลูกค้าเจ้านึงในไทย กินระยะเวลาแค่เดือนกว่า ๆ แต่เวลามันผ่านไปช้าเหลือเกินเพราะแต่ละวันคือเข้มข้นมาก ๆ นอกจากจะได้เรียนรู้สิ่งใหม่ ๆ (โดยส่วนมากก็จะเป็น domain knowledge เพราะทีมมีประสบการณ์ความรู้น้อยกว่าลูกค้า)ต้องเตรียมทำการบ้านสำหรับวันถัดไปโดยอิงจากข้อมูลใหม่ที่ได้มาในวันนี้ด้วย นำไปสู่ความท้าทายของ project นี้ซึ่งก็คือ

ทำยังไงที่จะแนะนำลูกค้าว่าต้องพัฒนาตรงไหนบ้างในเพียงช่วงเวลาสั้น ๆ

วิธีที่ทีมช่วยกันผ่านอุปสรรคไปได้คือ

“ทำให้ลูกค้าไว้เนื้อเชื่อใจเราอย่างสม่ำเสมออย่างถ่อมตัว”

ซึ่ง “ถ่อมตัว” ในที่นี้หมายความว่า

• เนื่องจากเราต้องประเมินและแนะนำลูกค้าในเวลาสั้น ๆ เราจึง “เปิดใจรับฟังทำความเข้าใจ priority ลูกค้า” มากกว่า “ประเมินและแนะนำให้ครบตามที่ตกลงกันไว้”
• เนื่องจากทีมมีประสบการณ์ความรู้ด้าน domain น้อยกว่าลูกค้า เราจึง “เป็น expert ในเรื่อง tech” มากกว่า “ฝืนเป็น domain expert”
• เนื่องจากเราต้องการให้ลูกค้านำคำแนะนำของเราไปปรับใช้ได้จริง ๆ เราจึง “ให้คำแนะนำที่เป็นร่าง ๆ กับลูกค้าตั้งแต่เนิ่น ๆ แล้วเก็บ feedback” มากกว่า “ให้คำแนะนำที่สมบูรณ์ตอนจบเพราะเราเป็น expert แล้ว”

หลังจาก “ถ่อมตัว” ตามที่ว่ามานี้แล้ว มันเกิดความคิดว่าเรากำลังกลายเป็นอะไรที่มากกว่าแค่ “มือคู่หนึ่งที่กด keyboard แทนลูกค้า” แต่เป็น “partner กับลูกค้า” จริง ๆ

• “เปิดใจรับฟังทำความเข้าใจ priority ลูกค้า” -> ใช้เวลาส่วนใหญ่ให้คำแนะนำที่สำคัญต่อลูกค้า นอกนั้นรายละเอียดก็พอประมาณแต่ก็ต้องไม่ขาดจนน่าเกลียด
• “เป็น expert ในเรื่อง tech” -> ทุกฝ่ายได้เรียนรู้ซึ่งกันและกัน ลูกค้าได้เรียนรู้เรื่อง tech ส่วนเราได้เรียนรู้ domain knowledge
• “ให้คำแนะนำที่เป็นร่าง ๆ กับลูกค้าตั้งแต่เนิ่น ๆ แล้วเก็บ feedback” -> ลูกค้านำคำแนะนำไปปรับใช้ได้

ท้ายสุดเราได้รับคำชมมากมายกับลูกค้า และเปิดโอกาสที่ดีหลาย ๆ อย่างเข้ามาในบริษัท แม้จะเป็นช่วงเวลาสั้น ๆ แต่ก็ได้เรียนรู้รสชาติของการเป็น “consultant” อย่างเข้มข้น ต้องขอขอบคุณเพื่อนร่วมทีมและลูกค้าที่น่ารักทุกคน แต่ละคนเก่งมากกกก

ดูสิ่งที่ได้เรียนรู้อื่น ๆ เพิ่มเติมได้จากการทำงานแนว consulting มา 3 ปี

ครั้งแรกกับงาน coach สอนพัฒนา software

ชีวิตการทำงานควรประกอบไปด้วยแผนที่เราวางไว้อย่างรอบคอบ (Deliberate) และการปรับตัวตามโอกาสที่เข้ามา (Emergent) ซึ่งอย่างหลังมันเกิดขึ้นว่าเพื่อนชวนไปช่วยสอนในงาน KBTG Java Intensive Workshop และ KBTG Go Intensive Workshop ซึ่งเป็น workshop 2 วัน เพื่อให้เห็นภาพของขั้นตอนการส่งมอบ software ว่าเป็นอย่างไรบ้าง จากนั้นทำการออกแบบระบบตาม requirement ทำความรู้จักเครื่องมือต่าง ๆ จากนั้นก็ลง workshop ต่อไป

พอมันเป็นโอกาสที่เข้ามาโดยไม่ได้วางแผนไว้ จึงไม่มีการเตรียมทักษะมาก่อน อย่าง workshop นี้มีการกำหนดว่าระบบงานจะต้องพัฒนาด้วยภาษา Go แต่ประสบการณ์การพัฒนาระบบงานด้วยภาษา Go ไม่มีถึงน้อยมาก ล่าสุดคือเรียนพื้นฐานเมื่อ 2 ปีที่แล้ว

ความท้าทายที่เกิดขึ้นคือ “ทำยังไงให้เราสามารถเรียนรู้สิ่งใหม่ที่ยากได้อย่างรวดเร็ว”

วิธีแก้ปัญหานี้ที่เราใช้แล้วมัน work คือทำความเข้าใจหลักการและภาพรวมของเนื้อหาที่เราจะศึกษาก่อน (อ่านเรื่อง Ultralearning เพิ่มเติม) ด้วยการแบ่งเนื้อหาออกเป็น 3 ส่วน คือ

• Concepts: สิ่งที่ต้องทำความเข้าใจ เช่น pointer, concurrency, error handling, interface
• Facts: สิ่งที่ต้องจดจำ เช่น keyword, dependency management, default value, testing
• Procedures: สิ่งที่ต้องลงมือทำ เช่นฝึก coding, build, test และ deploy application

จากนั้นดูว่าเราต้องเน้นอันไหนเป็นพิเศษแล้วหาวิธีหรือตัวช่วยให้เรียนง่ายขึ้น เช่น ใช้ Generative AI เพื่อตอบคำถามในเชิง concept พร้อมกับแสดง code ตัวอย่างประกอบในการลงมือทำ หรือจะเป็นการเรียนจากการแก้ test ให้มันผ่านโดยเอาโจทย์มาจาก Learn Go with Tests อีกที

พอถึงวันสอนจริงก็สามารถทำได้ดีเกินคาด สำคัญที่สุดคือการได้เรียนรู้อะไรที่คาดไม่ถึง เช่น

• Makefile เพื่อย่อคำสั่งต่าง ๆ ใน terminal
• Stakeholder management เช่น การอธิบายพูดคุยกับคนเรียน การออกแบบและปรับ session ให้ตรงกับความคาดหวังของทั้งคนเรียนและคนจัด(!) เป็นต้น
• การทำความเข้าใจกับ test-driven development (TDD) ในมุมมองใหม่ นำไปใช้กับงานลูกค้าจริง ๆ (อ่านเพิ่มเติมว่านำ TDD ไปใช้ได้อย่างไร)
• การเรียนภาษา Go จาก engineering practices ที่สอดแทรกเข้ามาใน ecosystem ให้ตั้งแต่แรกโดยไม่ต้องติดตั้งอย่างอื่นเพิ่มเติมเลย ไม่ว่าจะเป็น versioning & backward compatibility, testing, formatting, package system, dependency management

สุดท้ายขอขอบคุณเพื่อน(ใหม่)และทีมงานสอนที่ชักชวนและช่วยเรียนรู้ไปด้วยกันระหว่าง workshop ถึงจะเหนื่อยแต่ก็ภูมิใจมาก ❤️

ครั้งแรกกับการเข้าไปช่วยทีม pitch งานให้ลูกค้า

ในปีนี้เราได้มีโอกาสไปทำอีกงานนึงคือช่วยทีม pitch งานให้ลูกค้าเจ้าต่าง ๆ ในการลงทุนกับ developer experience หรือ engineering effectiveness ประโยชน์ของที่ลูกค้าจะได้รับโดยมากจะอยู่ที่ ease (ช่วย developer ส่งมอบ business ได้ง่าย ออกแรงน้อย), quick (ช่วย developer ส่งมอบ business value เร็ว ทันกับความต้องการของลูกค้า), quality (developer ส่งมอบงานที่คุณภาพดีขึ้น)

ทำอย่างไรที่จะโน้มน้าวองค์กรลงทุนหรือแม้แต่จะให้ความสำคัญกับเรื่องเหล่านี้

ซึ่งจากการไปเรากับทำการบ้าน research ในเรื่องของวิธีการ pitch กับลูกค้าในเรื่องของ developer experience เราก็พบว่ามันสามารถทำได้หลากหลายวิธี อาทิเช่น

• นำหลักการ user experience เข้ามาใช้เพื่อทำความเข้าใจว่าเขาติดหล่มอะไร สิ่งไหนที่ทำให้เขาไม่สามารถทำงานได้เต็มประสิทธิภาพ เช่น ทำ interview, survey เป็นต้น
• ประมาณคร่าว ๆ ว่า financial return of investment (ROI) มีขนาดเท่าไรหากลูกค้าตัดสินใจลงทุนในด้านนี้
• นำ value stream mapping มากางแล้วเจาะไปทีละ step เลยว่ามันมี friction ตรงไหน ใครมีส่วนร่วมบ้าง

จากนั้นนำผลจากวิธีการเหล่านี้มาเชื่อมกับ business outcomes โดยมี metrics เป็นตัววัดทั้งในแง่ของ quantity (เวลาและเงินที่ประหยัดไป) และความรู้สึก (retention rate, NPS score) ปิดท้ายด้วยคำแนะนำที่ลูกค้าสามารถนำไปปรับใช้ได้

สิ่งที่เราได้การ research ในช่วงนี้ไม่ใช่แค่ช่วยทีม pitch งานลูกค้าได้สำเร็จ (ถึงแม้ว่า scope จะ creep แบบมากมายก็ตาม) ยังช่วยให้คำแนะนำเพื่อน ๆ ในบริษัทที่เข้ามาปรึกษาว่าจะพัฒนาแนวทางการทำงานของทีมได้อย่างไรอีกด้วย

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

ครั้งแรก(ในรอบ 3 ปี)กับการปรับตัวกับองค์กรในสภาพใหม่กลางปี

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

พอปรับความเข้าใจด้วยการรับฟังและเข้าใจเจตนาของทุกฝ่ายที่เกี่ยวข้องแล้ว ก็ต้องเดินตามแนวทางบริษัทไปเพราะเรายังอยากอยู่กับบริษัทนี้อ่ะนะ

https://www.truemanchange.co.uk/our-resources/the-change-curve-and-the-mistakes-managers-make-when-using-it

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

อย่าให้เหตุการณ์ที่เกิดขึ้นในชีวิตหรือสิ่งภายนอกตัวเรามากำหนดคุณค่าของเรา

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

หรือแม้จะเป็นการอยากเข้าไปทำงานใน project นึงมาก แต่กลับไม่ได้รับเลือก เราอาจรู้สึกเสียใจหรือสงสัยในความสามารถของตัวเอง รู้สึกได้แต่อย่ารู้สึกนาน ควรกลับมามองว่าเป็นเพียงบทเรียนหนึ่งในชีวิต และเรายังคงมีคุณค่าในตัวเองจากความพยายามและศักยภาพที่เรามี เรียนรู้แล้วก้าวต่อไป ไม่แน่ว่า project อื่น ๆ อาจจะดีกว่าก็ได้ (ซึ่งก็จะเข้าสู่หัวข้อถัดไปนั่นเอง ฮ่า ๆๆ)

ครั้งแรกกับการเป็น technical lead

หนึ่งในสาเหตุที่ไม่อยากเข้า project นี้คือ “สภาพปัจจุบันของทีม” ยกตัวอย่างเช่น

• เพื่อนร่วมทีมบางคนมีความสัมพันธ์ที่ไม่ดีกับลูกค้าและไม่ถูกกันเอง คนทะเลาะก็ทะเลาะกันไป คนดูก็ดูอย่างเดียวไม่พูดไรเลย จนงานไม่เดิน productivity, morale เป็นไปในแง่ลบ
• ทีมมีการเปลี่ยนแปลงสมาชิก ทำให้แต่ละคนมีความรู้ทักษะที่เข้ากับบริบทของ project ไม่เท่ากัน นั่นรวมถึงการเปลี่ยน technical lead มาเป็นเราแทน (ซึ่งไม่เคยเป็น technical lead มาก่อน) ซึ่งเกิดขึ้นพร้อม ๆ กับการมี new joiner เข้ามาใหม่ 2 คน
• ทีมขาดการช่วยเหลือจาก leadership เพราะไม่มี visibility ว่าเกิดอะไรขึ้น

จะเห็นว่าโดยมากมันเป็นเรื่องของ “คน” ดังนั้นเราต้องแก้ปัญหาที่ “คน” ไปทีละเรื่อง

• มีความสัมพันธ์ที่ไม่ดี ทะเลาะกันบ่อยมาก
  • นำปัญหาขึ้นมากางบนโต๊ะ มีคนกลางคอยรับฟังและอธิบายอีกครั้งให้อีกฝั่งเข้าใจโดยเน้นไปที่เหตุและผล
  • เจ้าของไอเดียลงมือทำ “prototype” ให้ดูด้วยว่าไอเดียมันเป็นไปได้จริงไหม
  • สร้าง awareness เมื่อการสนทนาไม่เดินหน้าไปไหน แล้วให้ไปคุยแยกกันให้จบแล้วค่อยกลับมาหาทีม
• แต่ละคนมีความรู้ทักษะที่เข้ากับบริบทของ project ที่ห่างกันมาก
  • สร้าง skill matrix เพื่อประเมินตนเองว่าความรู้และทักษะอยู่ในระดับไหน ใครจะต้องเน้นเรื่องอะไร ใครจะต้องเป็น anchor เรื่องอะไร
  • ปรับ culture ของการ share ข้อมูลให้กันและกันผ่านการปรับการสื่อสาร ริเริ่มการทำ sharing session เปิดโอกาสให้ทีมได้ลองลงมือทำและเรียนรู้จากความผิดพลาด
  • ลงรายละเอียดในการทำ pair/mob programming ด้วยการให้สมาชิก lead ชิ้นงานด้วยตนเองแล้วเราคอยช่วยเหลืออยู่ห่าง ๆ เกิดความรู้สึกมี autonomy มากขึ้น เป็นเจ้าข้าวเจ้าของกับ product ที่พัฒนามากขึ้น
• ไม่เคยเป็น technical lead มาก่อน
  • ไปศึกษาว่าคนอื่นที่เป็น technical lead เขามีแนวคิดอย่างไร แล้วค่อย ๆ เอามาปรับใช้ให้เข้ากับแนวทางการทำงานของเราและทีม
• มี new joiner เข้ามาใหม่ 2 คน
  • จัดระเบียบ documentation และเนื้อหา onboarding โดยให้สมาชิกที่อยู่ในทีมมานานกว่าเป็นคนนำ onboarding
• Leadership ไม่มี visibility ว่าเกิดอะไรขึ้น
  • พาทีมไปพูดคุยสื่อสารกับ Leadership บ่อย ๆ และขอ feedback เพื่อปรับแนวทางของทีมและการเข้าหาลูกค้าต่อไป

ปัญหาอีกกลุ่มนึงก็คือเรื่องของ “process”

• ทีมรู้สึกเซ็งเพราะมันมีงานแทรกขึ้นมาตลอด ไม่ว่าจะเป็นงานกรรมเก่า งานฟ้าประทาน งานที่ plan ไว้แต่ลืมหยิบมา prioritise ทำ รู้ตัวอีกทีกลายเป็นงานแทรกไปซะงั้น นอกจากนั้นก็มีงาน support ทีมอื่น ๆ ที่เข้ามาใช้ระบบอีก
• การทำงานกับทีมอื่นไม่รอนานไปเลยก็มาเร่งเอาสุด สั่งวันนี้จะเอาเมื่อวาน เพราะต่างทีมต่างทำงานที่ทีมตัวเองคิดว่า “สำคัญ” เสมอ
• ประชุมเยอะ แต่ไม่ได้สาระอะไรเลย เหมือนมานั่งบ่นให้ฟังแล้วก็ไป

จาก list ข้างบน มันเป็นผลพวงมาจาก “คน” อีกทีเพราะมันคือวิธีที่ “คน” ทำงานร่วมกันนั่นเอง ดังนั้นต้องแก้ปัญหาที่ “คน”

• มีงานแทรกขึ้นมาตลอด
  • กำหนด vision และเป้าหมายหลักของทีม
  • นำงานทั้งหมดขึ้นมากางให้ทุกคนเห็น แล้ว prioritise ใหม่โดย balance สัดส่วนงานที่เข้ามาให้ตรงกับเป้าหมายหลักเป็นส่วนใหญ่
  • เผื่อ “buffer” ไว้นิดหน่อยเผื่อรับงานฟ้าประทาน / งาน support ไม่งั้นถ้ามีงานแทรกมา เราจะต้องปรับงานที่ plan ไว้ทั้งหมด
  • ทำความเข้าใจเกี่ยวกับ technology ของระบบรวมถึง dependencies ให้มากที่สุดเท่าที่จะมากได้เพื่อคาดเดาเหตุการณ์ที่อาจจะเกิดขึ้นได้ เช่น ต้อง upgrade version เมื่อไร, ถึงเวลาต้อง migrate tech ที่ out-of-support แล้วหรือยัง เป็นต้น
• ต่างทีมต่างทำงานที่ทีมตัวเองคิดว่า “สำคัญ”
  • กำหนดทิศทางและ measure of success ร่วมกันเพื่อช่วยให้ทุกทีมที่เกี่ยวข้องกันช่วยเหลือกัน
  • กำหนดขอบเขตความรับผิดชอบของแต่ละทีม ย้ายของให้ไปอยู่กับเจ้าของที่ถูกต้องเพื่อลด dependencies ที่ไม่จำเป็นและลดการเหยียบเท้ากัน
• ประชุมเยอะ
  • ปรับความเข้าใจว่าการประชุมคือการสร้างความเข้าใจว่าปัญหาอยู่ตรงไหน ทำไมเราต้องทำงานชิ้นนั้น ๆ เหตุการณ์อะไรที่อาจเกิดขึ้นแล้วมีผลต่อการส่งมอบของทีม และอธิบายให้คนที่สามารถช่วยเหลือเรารู้ว่าเขาจะสามารถช่วยเหลือเราได้อย่างไร

ผลลัพธ์ที่ออกมาต้องบอกว่าดีเกินคาดไปเยอะมาก ๆ ทั้งสถานการณ์ใน project ดีขึ้น ความรู้และทักษะของทีมพัฒนาขึ้น ทุกคนกล้าแสดงความคิดเห็นรวมไปถึงกล้า “say no” กับลูกค้าในบางเรื่อง feedback จากเพื่อนร่วมงาน ลูกค้า leadership team ก็ดีมาก แม้ว่าทุกวันต้องเตรียมตัวและเจอความรู้สึกในการเป็น “tech lead” ครั้งแรก เช่น

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

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

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

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

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

สถิติ

ปีที่ผ่านมาเขียนไป 58 blog โดยเรื่องที่เขียนเยอะที่สุดคือ

• soft-skill (11)
• kubernetes (6)
• productivity (6)
• tools (6)
• aws (5)
• book (5)
• practice (5)
• testing (5)

มี 1 blog ที่เอาไปแชร์กับพี่ ๆ ผ่าน Medium

• วิธีการประมาณค่าใช้จ่าย cloud infrastructure แบบบ้าน ๆ

เวลาที่ใช้ในการเขียน code

จากการใช้เครื่องมือ WakaTime เป็นตัวเก็บสถิติ พบว่าปีทีี่แล้ว

• เขียน code ไปเกือบ 400 ชั่วโมง เฉลี่ยวันละ 1 ชม. 23 นาที
• ภาษาที่เขียนเยอะสุดคือ Markdown, YAML, C#

Feedback

ระหว่างปีที่ผ่านมา มาดู feedback ที่เราได้รับกันหน่อย โดยจะแบ่งเป็นครึ่งปีแรกกับครึ่งปีหลัง เพราะมันเยอะจริง ๆ ต้องขอขอบคุณทุกคนที่มอบ feedback เป็นของขวัญตลอดทั้งปีนะครับ 🎁

ครึ่งปีแรก

ข้อดี

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

ข้อควรปรับปรุง

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

ครึ่งปีหลัง

ข้อดี

• มีทักษะการสื่อสารที่ดีเยี่ยม ทั้งการพูด การเขียน และการอธิบาย
• ช่วยลดความตึงเครียดและสร้างความสัมพันธ์ที่ดีระหว่างทีมและลูกค้า
• มีทักษะด้านเทคนิคที่กว้างขวาง โดยเฉพาะในด้าน Kubernetes, CI/CD, Cloud Computing และ Infrastructure
• สนับสนุนทีมด้วยการแชร์ความรู้และจัด session เพื่อให้ทีมเตรียมพร้อมสำหรับงานสำคัญ
• มีทักษะการบริหารจัดการทีมและสร้าง high-performing team
• ใส่ใจในความต้องการของลูกค้าและสามารถปรับตัวเข้ากับความซับซ้อนของ project ได้ดี
• มีความตั้งใจจริงและเอาใจใส่ในรายละเอียดของงาน
• สร้างแรงบันดาลใจและช่วยให้เพื่อนร่วมทีมเติบโตในอาชีพ

ข้อควรปรับปรุง

• ควรแบ่งงานหรือมอบหมายงานบางส่วนให้ทีมเพื่อให้มีเวลามากขึ้นสำหรับภาพรวมของ project
• พัฒนาความสัมพันธ์กับลูกค้าต่อไปเพื่อสร้างความไว้วางใจในระยะยาว
• ลดความกังวลในสถานการณ์ที่ซับซ้อนและใช้วิธีมองภาพในระยะยาวในการตัดสินใจ
• หลีกเลี่ยงการทำงานเกินกำลังและรักษาสมดุลระหว่างงานกับชีวิตส่วนตัว

สิ่งที่อยากจะทำจาก blog ปีที่แล้ว

✅ ทำให้ performance รอบนี้เกิน expectation ที่ได้ตั้งไว้กับบริษัท
❌ พูดในงาน public/private conference อย่างน้อย 3 งาน (เพราะเราไม่มีแรงจูงใจ + ไม่มี content ที่จะพูด)
❌ ออกต่างจังหวัดช่วยงานอาสาโดยไม่จำเป็นต้องไปกับบริษัทอย่างน้อย 1 งาน (เปลี่ยนจากงานอาสาเป็นงานสอนแทน)
❌ วิ่งโดยระยะรวมเท่าเดิมหรือมากขึ้นไปเรื่อย ๆ ในทุกอาทิตย์ half-marathon ให้ได้ทุกอาทิตย์ ไม่ว่าจะจากการซ้อมหรือการแข่ง (วิ่ง half-marathon ทุกอาทิตย์ไม่ไหว จิตใจยังไม่แข็งแรงพอ)
❌ ทำ Bring Sally Up - Push Up Challenge ให้จบ (ตอนนี้ได้มากที่สุด 2:35 นาที ฝึกต่อไป)
✅ ทำ Wide-Grip Pullups อย่างน้อย 1 ครั้งโดยไม่ใช้ตัวช่วย (ได้ 10 ครั้ง ถือว่าเกินคาดมาก ๆ)
✅ ออกทริปเที่ยวคนเดียวอย่างน้อย 2 ทริป ต่างประเทศหรือในประเทศได้หมด
✅ เป็น sponsor ให้กับคนที่ไม่อยากจะอยู่แค่ที่เดิม (ซึ่งไม่ผิด) อย่างน้อย 1 คน

สิ่งที่อยากจะทำในปีนี้

ปีนี้เป็นปีแรกในหลาย ๆ ปีที่ผ่านมาที่คิดไม่ออกว่าอยากจะทำอะไรต่อ อาจจะเป็นเพราะ

• ลองทำหลายอย่างในปีนี้ เช่น การเป็น consultant, coach, และ technical lead ซึ่งเป็นบทบาทที่แตกต่างกัน ซึ่งอาจทำให้รู้สึกว่าไม่มีสิ่งไหนเด่นชัดว่าเราอยากจะพัฒนาต่อในด้านไหนเป็นพิเศษ
• ความสำเร็จที่ได้รับในปีนี้มันเกิดคาด มันก็สร้างแรงกดดันให้เรารู้สึกว่าปีหน้าต้อง “สำเร็จ” หรือ “ก้าวหน้า” ในแบบที่เทียบเท่าหรือดีกว่าเดิม ซึ่งอาจทำให้เรากลัวที่จะตั้งเป้าหมาย

สรุป

ปีนี้เป็นปีแห่งการเรียนรู้และเปลี่ยนแปลงสำหรับเราเลย มีทั้งโอกาสใหม่ ๆ และความท้าทายเข้ามาแบบไม่ทันตั้งตัว ตั้งแต่การทำงานใกล้ชิดกับลูกค้าในฐานะ (เกือบ) partner ซึ่งช่วยให้เราเข้าใจการทำงานแบบ consulting ลึกซึ้งขึ้น ไปจนถึงการลองเป็น coach ใน workshop สอนพัฒนา software และการช่วยทีม pitch งานลูกค้า ซึ่งเปิดมุมมองใหม่ ๆ ให้เราในเรื่อง engineering practices และ developer experience นอกจากนี้ยังได้ก้าวขึ้นมาเป็น technical lead ครั้งแรก เผชิญหน้ากับทั้งปัญหาเรื่องคนและกระบวนการทำงานที่ท้าทายสุด ๆ แต่ทุกอย่างก็ทำให้เราเติบโตขึ้น และเข้าใจตัวเองมากขึ้นว่าคุณค่าในตัวเราขึ้นอยู่กับความพยายามและศักยภาพที่มี ไม่ว่าจะเจออุปสรรคหรือการเปลี่ยนแปลงแบบไหน เราก็ยังภูมิใจในสิ่งที่ทำสำเร็จในปีนี้ 🏅

จบปีแล้วดูสภาพตัวเองเหมือนเพิ่งวิ่ง full marathon จบ race ถัดไปมารอแล้วดังนั้นสู้ต่อไป!