[รู้อะไรไม่สู้รู้งี้ ตอนที่ 4] Lesson learned ของ Software Engineer ที่มีอำนาจในการตัดสินใจ
สวัสดีครับทุกคน กลับมาอีกครั้งกลับซีรีย์ รู้อะไรไม่สู้รู้งี้ ในหมวดของ Software Engineer Career Path นะครับ สำหรับบทความนี้ก็จะเกี่ยวข้องกับในเรื่องของที่ว่า เมื่อคุณทำงานมาได้ซักระยะนึง ไม่ว่าจะเป็นบริษัทเดิมมาประมาณนึง หรือเมื่อคุณได้เลื่อน Level ขึ้นไปเป็นอีกระดับ หลาย ๆ คนก็จะเริ่มมีอิทธิพลในด้านการตัดสินใจในเรื่องของ Architect, System discussions หรือ Technology options ต่าง ๆ นะครับ
เมื่อเราทำอะไรคนเดียว แน่นอนครับ เรามีทางเลือกมากมายที่เราสามารถใช้ได้ เราอยากจะทำอะไรก็ทำ เราอยากจะลองอะไรก็ลอง แต่เมื่อใดก็ตามที่เราทำงานเป็นทีม หรือเราทำอะไรซักอย่างเพื่อแก้ปัญหาให้กับ Business, Enterprise หรือ Humanity problems การตัดสินใจก็มักจะต้องทำความเข้าใจร่วมกัน เพราะถ้าหากเราเกิดเชื่อข่าวลือต่าง ๆ ทาง Technology ตามกระแสนิยม ไม่ว่าจะเป็น Frameworks หรือ Techniques ต่าง ๆ และพยายามนำไปปรับใช้กับงาน โดยที่ไม่ได้ไตร่ตรองหรือทำข้อตกลงร่วมกัน หรือแม้กระทั่งทีมเนี่ยทำความเข้าใจ และตกลงร่วมใจไปด้วยกันแล้ว มันก็อาจจะมีทั้งผลลัพธ์ที่ดี ที่คาดไม่ถึง หรือแม้กระทั่งผลลัพธ์ไม่เป็นไปตามที่คาดหวัง ซึ่งถ้าหากมันไม่เป็นไปตามที่คาดหวังก็อาจจะสร้างผลเสียมากกว่าผลดีให้กับ Team, Organization หรือ Company ได้
ทั้งนี้ทั้งนั้น ก็ไม่ได้บอกว่าการ Apply ของใหม่ ๆ ไม่ดีนะ เพราะว่าบางทีมันก็ถูกสร้างขึ้นมาเพื่อแก้ปัญหาแหละ แต่มันใช่สิ่งที่เหมาะสมกับงานนี้รึเปล่านะ 🤔 ถ้ายังไงก็มาลองเรียนรู้จากสิ่งที่ผมเขียนได้นะครับ ไม่ต้องเชื่อผมก็ได้เช่นกัน เพราะบางทีประสบการณ์ของผมอาจจะแตกต่างจากทุกคน โดยส่วนใหญ่ผมเป็น Backend Engineer ที่ทำ Enterprise level ซะส่วนมาก แต่อยากจะให้ทุกคนลองสะท้อนดูว่า มันเป็นสิ่งที่เกิดขึ้นจริง และเป็น Case study หรือ Roadmap ให้กับผู้อ่านทุกคนได้ หวังว่าไม่มากก็น้อยครับ 🙇♂️
ถ้าพร้อมแล้ว ก็มาเริ่มกันเลยครับผม
1. Know the problems enough
หลังจากที่เราทำการประชุม Meeting หรือ whatever กับพนักงานคนอื่น ๆ เพื่อนร่วมทีมเกี่ยวกับปัญหา หรือสิ่งต่าง ๆ ที่เราต้องการจะทำขึ้นมาเพื่อแก้ปัญหา ในเชิงของ Software Engineering แน่นอนครับว่าเราต้องทำความเข้าใจกับปัญหา ว่ามัน Make sense แค่ไหนที่จะทำ คือเนื้อหาของปัญหาที่เข้าใจไม่ใช่ในระดับแบบผิวเผิน อาจจะต้องเข้าใจว่า Root cause ของปัญหามันคืออะไร (เหมือนตอนไปหาหมอแล้วเขาซักนู่นนี่แหละ 😂)
เพราะไม่แน่ว่าบางทีเราอาจจะไม่ต้องทำ มันอาจจะไม่ Make sense ที่จะแก้ หรืออาจจะมาผิดทีมที่รับผิดชอบ แต่ทั้งนี้ทั้งนั้นมันก็คือกระบวนการเข้าใจปัญหาว่ามันคืออะไร เป็นแบบไหน เข้าใจให้ลึกและถี่ถ้วน แล้วเราจะได้ตอบรับได้อย่างมีประสิทธิภาพได้มากที่สุด ในฝั่งของ development โดยส่วนใหญ่ก็อาจจะมองในเรื่องของการผลิต เขียนโค้ดและพัฒนา แต่ก็ต้องเข้าใจ Atomic problems และค่อย ๆ แก้จากจุดเล็ก ๆ นั้นขึ้นไป เพื่อ user experience
ยกตัวอย่างเช่น Target users ของคุณเป็น Non-Tech team ที่ทำ Day-to-Day task แบบ Manual แล้ว เสนอแนวทางใช้กับ Platform ภายใน ก็ต้องมารุมพิจารณากันก่อน ว่า Organization ของเราจะมีแนวทางตรงนี้ยังไง เพราะมันจะต้องคิดถึง Human effort ที่ต้องใช้ด้วย บางทีเมื่อเข้าใจปัญหามากขึ้น แม้อาจจะไม่ Perfectly to solved แต่อย่างน้อยก็ยังดีกว่า Blindly solving นะครับ 😅
2. Think Beyond Today
Project ที่ Successful ส่วนใหญ่มักจะมีแนวทางในอนาคตรออยู่แล้ว บางครั้งมันก็อาจจะมี Ad-hoc fix issues หรือเพิ่ม requirements นู่นนี่ ก็อาจจะไม่ได้เปลี่ยนแปลงไปจากของดั้งเดิมมากนัก ข้อสำคัญของแต่ละ Project คือ Single responsibility, Loose coupling และ High cohesion แหม ถ้าภาษาไทยก็จะเป็น อย่าให้งานที่แตกต่างกันมีความสัมพันธ์กันมากเกินไป และพยายาม Grouping เรื่องที่ใกล้เคียงกันมาก ๆ อยู่ด้วยกันนั่นเอง
นอกจากนี้ นอกจากการ Development แล้ว ถ้าหากว่าอยู่ใน Team หรือ Organization ที่เป็น Mindset “You build it, You maintain it” ไม่หรอก จริง ๆ ideally หรือ อุดมคติ มันควรจะเป็นแบบนี้แหละ เวลาเราสร้างอะไร ให้คิดถึงเรื่องของการบำรุงรักษาระบบด้วย ไม่ว่าจะเป็นเรื่องของ scalability, maintainability, sustainability, และ cost optimization มีเรื่องต้องคิดเต็มไปหมดเลยครับ เราอาจจะ Over-Engineering กันไปก็ได้ ถ้าหากตัดสินใจไปแล้ว
3. Hold your breadth before picking technologies
โลกนี้มีเรื่อง Technology เข้ามาให้ตื่นตาตื่นใจได้ทุกวันจริง ๆ ครับ ไม่ว่าจะเป็น Programming languages ใหม่ ๆ Frameworks ใหม่ ๆ หรือ Tools ใหม่ ๆ ที่เราไปดูหรือไปอ่านมาแล้วรู้สึกว่า เอ้ย มันเจ๋งดีว่ะ อยากเอามาลองใช้ใน Project จริง ๆ เล้ยยยยยยยยย
แต่ทว่าก่อนเราจะเลือก ต้องพักหายใจซักหน่อย พยายามดูก่อนว่า Tools ที่ออกมาใหม่นั้น
- Is it really solved our issues?
- Is it enough documentation?
- Is the community support enough?
- Prerequisite for running the tools/frameworks?
- Do our team or organization need to learn this from scratch?
มันอาจจะมีคำถามอื่น ๆ จากนี้อีกเยอะแยะ แตกต่างกันไปตาม Market หรือ Domain knowledge ของแต่ละ Organization ไม่ใช่แค่อยากจะใช้ก็ใช้ มันอาจจะต้อง align ไปหลาย ๆ ส่วน ไม่ใช่แค่ทีมที่เราดู ทีมที่ใช้ Service ของเรา ทีมที่ดูเรื่องค่าใช้จ่าย ทีม Tech Lead และ Architect ก็ด้วย ดังนั้นต้องคิดให้ถี่ถ้วนพอสมควร เราสามารถ Research หลาย ๆ ทางเลือกได้ แล้วนำมาเสนอให้กับพวกเขาทีหลังก็ยังไม่สาย
4. Rebuild system or Reuse existing
ในบางครั้งระบบของเราก็มีบ้างแหละ ที่เป็น Legacy system และเมื่อเราได้รับปัญหาเข้ามา เราก็ต้องมาค่อย ๆ พิจารณาก่อนว่า สิ่งที่กำลังเข้ามา เราจำเป็นหรอที่จะต้องสร้างของใหม่ขึ้นมา เราอาจจะกำลังสร้างของใหม่ แต่ Logic เดิม ท่าเดิม หรือเราจะเป็นการ Improve system ที่เรามีอยู่แล้ว เอามันมา Enhancement และปรับเปลี่ยนตาม Logic ใหม่ ๆ ที่กำลังเข้ามา
การจะเริ่มตัดสินใจให้มีความ ideally right decision มากที่สุด ต้องเริ่มจากความเข้าใจ existing system ไม่ว่าจะข้อดี ข้อเสีย คอขวด จุดที่อาจจะทำให้ระเบิดถ้าเกิด triple peak time และจะต้องคำนึงถึงสิ่งที่เป็นอยู่จริง ๆ เช่น Resources CPU และ Memory ที่ใช้ เวลาต่าง ๆ ที่เกี่ยวข้องเช่น Build หรือ Deployment process ต่าง ๆ
ในหลาย ๆ ครั้งมักจะจบที่ตรงกลาง บางอันเรา Reuse API ได้ Reuse Message Queue system ได้ ดีกว่าการสร้างมันใหม่ทั้งหมด แต่ก่อนที่จะไปถึงการตัดสินใจใน Step นี้ได้ ต้องมีการ Investigation & Feasiblity ของระบบซะก่อนนะ 😁
5. How this newly system going to be?
เอาล่ะ มันต้องสร้างใหม่จริง ๆ ว่ะ คราวนี้ใน context ที่ว่ามันใหม่นะ เราจะทำยังไงกับมัน ปัญหาคืออะไร? เอาสิ่งต่าง ๆ ที่รวบรวมมาได้ มาลองดูว่า ไอ existing system ที่เรามีเนี้ย มันเป็น Workload แบบไหน เราต้องแยกมันออกรึเปล่านะ หมายถึงว่า ต้องแยก Service แยก Cluster หรือขั้นหนักก็แยก Cloud provider เลย แต่ใจความสำคัญคือ What is the shape of the end product will look like? ถ้าภาพในหัว Clear และไม่ได้แบบมีอะไรลอย ๆ งานหลังจากนี้จะง่ายขึ้นมาก ๆ ไม่ว่าจะเป็น Functional หรือ Non-Functional หรือการ Integrate ระหว่างระบบ
ยกตัวอย่างเช่น ถ้าเกิดเป็น E-Commerce Platform ก็ต้องมีอะไรที่เป็น Core ของมัน User management, Inventory, Payment, Order เอาประมาณนี้ก่อนละกัน
ถ้าสมมุติเราวางแผนว่า Target Users per day ของเราคือ 100K DAU (Daily Active Users) และเราบอกว่าเดี๋ยวขอ Support ที่ 500K Register users ก่อนละกัน
- 100K คนต่อวัน
- ใน 1 วันมี 1440 * 60 = 86400 วินาที (จำเลขนี้ให้ดีครับ ใช้บ่อย)
- แปลว่า Concurrent users ต่อวินาทีที่เป็นไปได้คือ 100K / 86.4K ประมาณ 1.1
- แล้ว Peak Time Multiply ที่เราจะ Support คือระดับไหน? ในที่นี้ผมขอใช้ 3
- แปลว่า concurrent users ของเราคือ 3 users per second
- แล้วมันใช้ 3 ได้เลยรึเปล่านะ ก็อาจจะได้นะ แต่อย่าลืมว่า เราอยู่ใน domain แบบไหน ในที่นี้คือ E-Commerce Platform แปลว่าอัตราส่วนก็จะเป็นคนดูอย่างเดียว แต่ไม่ซื้อ กับคนที่ซื้อสินค้าจากระบบ แบ่งเป็นอัตราส่วน 2:1 Read/Write
- แล้วสมมุติว่าครั้งนึงมันต้องใช้ Data ประมาณ 60KB จังหวะที่ request เพื่อทำการ Order และใช้ 20KB จังหวะ response category of data (สมมุติล้วน ๆ เลขลอย ๆ)
- Read operations: 2 operations/sec * 60 KB = 120 KB/sec
- Write operations: 1 operation/sec * 20 KB = 20 KB/sec
- Bandwidth ของทั้งสองอันรวมกันคือ 140KB/sec
- 140 (Prefix number) * 8 (Byte to bit) = 1120 Kbps
- แต่ส่วนใหญ่เราคุยตั้งแต่ Megabit/Megabyte ขึ้นไปกันเนาะ ก็เลื่อนจุดกันเล็กน้อยหน่อย 1.120 Mbps (จริง ๆ มัน 1.09 Mbps แต่เอาไว ก็ปัดขึ้นเลยละกัน 😅)
- ส่วน Storage ถ้าเกิดว่า focus ไปที่เรื่องของ User management อย่างเดียว
- 1 user ของเราจะมี metadata ประมาณ 100KB
- Support ที่ 500K * 100KB
- 500 * 100 * K * K => 500_00 * 2¹⁰ * 2¹⁰ => 500_00 * 2²⁰ => 50000 MB
- อ่ะ เลื่อนจุดเหมือนเดิม 50_000 MB => 50GB for storage ครับ
นอกจากนั้นก็จะเป็นเรื่องของการแลกเปลี่ยนข้อมูลระหว่าง Service และ Architect แล้วล่ะครับ
- เราจะเป็นการสื่อสารแบบไหนของ Use-case A ระหว่าง Service A กับ Service B
- เราจะจัด Resource Database หรือ Workload ของเราแบบไหน
- เราต้องทำ Microservices รึเปล่า
- ต้องมี Cache มั้ย
- เราต้องใส่ Circuit Breaker เพื่อความคงทนของระบบรึเปล่า
- Retry กี่ที Timeout กี่วินาที
- Service ไหนจะรับ Load หนักที่สุด จำนวน Instances ของ Service A อาจจะไม่เท่ากับ Service B
การ Clear ภาพพวกนี้ในหัวได้ก่อน จะทำให้การตัดสินใจหลังจากนั้น ไม่ใช่ที่ Why we need it? แต่จะเป็น How we able to acheived it?
6. How the technologies options going to be in the 3–5 years?
นั่นแหละ Technology มาไว เปลี่ยนแปลงสิ่งต่าง ๆ ไปรอบ ๆ ตัวตามกาลเวลาโดยตลอด ซึ่ง มันก็ไม่ใช่เรื่องที่เราจะเปลี่ยน หรือสร้างใหม่ไปตลอดใช่มะ อาจจะเสียเวลา เสียเงิน บางทีทำไว้ แล้วเราผู้เป็นคนตัดสินใจ วางแผน เกิดลาออกงี้ อ้าว ยังไงต่อล่ะ จะให้คนเข้ามาใหม่สร้างใหม่หรอ ไอตัวเก่าที่ทำไว้มันไม่ดีในอนาคตหรอ นั่นแหละครับคือสิ่งที่เกี่ยวข้องกับหัวข้อนี้
Rebuild thing is the last option I want to do — Thanaphoom Babparn พูดกับเพื่อนร่วมทีมเมื่อประมาณ April 2023
หลังจาก Consider Technology รวมถึงการทำ POC แล้ว ก็มาดูกันว่า ในอนาคต Community มันจะ Support ดีแค่ไหน มี Company ใหญ่ ๆ ช่วย Promote และ constribute มากน้อยแค่ไหน เรากำลังส่งหนี้ให้คนในอนาคตมากน้อยแค่ไหน เขาจะตามมาด่าคุณย้อนหลังรึเปล่านะ ใน 3–5 ปีข้างหน้ามักจะเป็นตัวเลขที่พยายามนำมาคิดล่วงหน้า ว่ามันเป็นขาขึ้น Stable ขาลง ก็ต้องนำมาประกอบการพิจารณาเช่นกัน
7. Once commitment, Take ownership & responsibility
หลังจากเราทำทุกอย่างแล้วไม่ว่าจะเป็นการวิเคราะห์ปัญหา การ POC การคุยกับทีม การ Knowledge sharing คราวนี้ก็ถึง Phase ช่วง Pre-Execution
หลังจากที่ทุกคนทำความเข้าใจร่วมกัน ตกลงปลงใจ กับการตัดสินใจของเรา ก็หายใจเข้าลึก ๆ แล้ว Let’s go ครับ เมื่อคุณตัดสินใจแล้ว อย่าลังเลในภายหลัง ไปให้สุดกับสิ่งที่เราตัดสินใจ Make commitment ให้กับตัวเอง รับผิดชอบในตัวเลือกแห่งการเติบโตของเรา ไม่ว่าจะเป็นผลร้ายดียังไง บันทึกการเดินทางของตัวเองไว้ สามารถเป็นบทเรียนให้เราในอนาคต และคนอื่น ๆ มันไม่ใช่แต่เรื่องของความมั่นใจ แต่เป็นเรื่องของความรับผิดชอบในการตัดสินใจ of your buttefly effects
แต่ทั้งนี้ทั้งนั้นคุณจะต้องเจอกับสิ่งนั้นไปเรื่อย ๆ ตราบเท่าที่ Software Developement Life Cycle (SDLC) เริ่มทำงาน ในระหว่างนี้ Feedbacks จะเป็นตัวที่ดีมาก ๆ สำหรับเพื่อนร่วมทีม หรือ stakeholders ที่เกี่ยวข้อง เพื่อทำให้เราเรียนรู้ว่า สิ่งที่เราตัดสินใจนั้นดีมากน้อยแค่ไหน 🙇♂️
เรียนรู้จากสิ่งร้ายดี และยืนต่อไปอย่างมั่นคง จำไว้ว่าอาจจะไม่มี Perfect decision การกระทำใด ๆ มีความเสี่ยงทั้งนั้นครับ ช่องทางการเติบโต ลงลึก และขยายฐานความรู้ของเราไปตลอดระยะเวลาของ career path ครับ
8. Know your team and stakeholders
ผู้คนทุกคนที่เกี่ยวข้องกับ Software Project หรือ stakeholders เราต้องเข้าใจ Subject expertise, domain expertise หรือ role background ของเขา และเราเลือกที่จะส่งมอบเนื้อหาที่เขาสามารถเข้าใจได้ แทนที่จะพ่นสิ่งที่เราคิดว่า เขาควรจะรู้อยู่แล้ว (Curse of knowledge ชัด ๆ) นอกจากการเลือกคนที่เหมาะสมกับการทำงาน การ Inquiry จะทำ Flow state ของเราทำงานได้คล่องตัวมากยิ่งขึ้น
เช่นสมมุติว่าเรากำลังทำงานเกี่ยวกับ Java/Kotlin based และรวมถึง Organization ก็เป็น Based แบบนั้น การเลือกใช้สิ่งใหม่ ๆ ก็อาจจะทำให้ slow down development และใส่ Learning curve ที่ไม่จำเป็น ให้กับคนอื่น ๆ รวมถึงการบำรุงรักษา ซึ่งไม่ใช่ว่าทางเลือกใหม่มันไม่ดี แต่หลังจาก compare tradeoffs และ timeline แล้ว การตัดสินใจของเราต้องไปต่อมั้ย เพียงพอมากน้อยแค่ไหน
9. Communications and knowledge sharing is key
การสื่อสาร สำคัญมาก ๆ ครับ สำหรับ software projects ไม่ว่าจะเป็น development team, stakeholders, end users, หรือ party ที่เกี่ยวข้องอื่น ๆ เพราะเป็นทางที่เราจะได้ทำความเข้าใจปัญหาซึ่งกันและกัน และใช้ภาษาที่เป็นกลางกับทุกฝ่าย
ในการสื่อสาร พยายามลดสิ่งที่เป็น Mindset ที่ว่า ถ้าเราพูดหรือไม่พูดออกไป เราจะไม่ Professional หรือ เราไม่รู้ก็กลัวจะไม่ Professional
- ถ้าไม่รู้ให้ถาม
- มองเรื่องความหมายของการสื่อสารเป็นสำคัญ
- หายใจเข้าลึก ๆ รู้ว่าเรากำลังคุยอยู่กับใคร เขามี background แบบไหน
- แม้คลังคำศัพท์มีไม่มาก แต่ Link ไปที่ข้อ มองเรื่องความหมายของการสื่อสาร ใช้ไปเลยครับ
- ถ้าเขาจะมองว่าไม่ Professional. It’s totally ok. You will grow bit by bit over time
นอกจากนั้นก็ต้องมีการ exchange knowledge ระหว่างภายในทีมด้วย ว่าทำไมเราถึงต้องทำอย่างนั้น ถ้าเฉพาะคนในทีมปัจจุบันก็อาจจะเรียนรู้ซึ่งกันและกันผ่าน PRD, Pull Request หรืออื่น ๆ แล้วแต่ช่องทาง แต่ถ้าคนเข้ามาใหม่ละ การมีระบบที่คิดว่า ideal ที่สุดในตอนนี้แล้วล่ะ หรือการทำ Video recorded for explanation ก็เป็นทางเลือกที่ดีเช่นกันครับ
10. Documentation is really important
Working software over comprehensive documentation
แหม วลีเด็ดจาก Agile manifesto ที่แปลว่าการส่งมอบ Software ที่ถูกต้องควรมาก่อน Documentation แต่บางคนก็ใส่ซะสุด Max เลย เอ้ย ก็บอกอยู่ว่าส่งมอบสำคัญ แล้วจะทำ Document ทำไม (กำหมัดเลย ✊)
จะว่ายังไงดี Most of the time เราชอบมองข้ามไป แต่ Document เป็นช่องทางการสื่อสารแบบ Asynchronous communication ที่ทำให้ Team หรือ Organization สามารถ scale และรับรู้ Context ของปัญหา หรือสิ่งที่เราสร้างได้ครับ การทำให้มัน up-to-date ก็จะทำ whole organization มีประสิทธิภาพมากขึ้นเช่นกัน
ยกตัวอย่างเช่น FAQ หรือ Architecture decisions พวกนี้จะช่วยทุ่นแรง และประหยัดเวลาให้กับทีมตัวเอง และทีมอื่น ๆ ลงไปได้เยอะมาก ๆ เลย
นอกจากนั้น ถ้าเป็น Document ที่เกี่ยวข้องกับทีมโดยตรง นี่แหละ จะเป็นตัวเด็ดในการ Onboarding new members ได้ดีเลย บางครั้งพวกเขาอาจจะมองข้าม document ก็ไม่เป็นไร แต่เรามีไว้เพื่อให้ตัวเองกลับมาดู หรือทีมอื่นกลับมาดูก็ได้ โดย Tool ที่ใช้ยอดนิยมก็คงเป็น Confluence Wiki ครับ
Tools ที่ใช้งานได้ดีสำหรับ ที่แบบสามารถสร้างภาพได้เร็ว ๆ ก็คงจะเป็น excalidraw.io ครับ
11. Never Stop Learning
ข้อสุดท้าย เป็นเรื่องแน่นอนครับ เรียนรู้มากขึ้น หัดทำมากขึ้น Learning over time พยายามหาช่องทางใช้ techniques หรือ best practices ที่ใช้ รวมถึง Exchange knowledge ไปมา ระหว่างคนในทีมหรือคนที่เกี่ยวข้อง แล้วเราจะปรับเปลี่ยนสิ่งที่เป็นความรู้กลายเป็นสัญชาตญาณที่แม่นยำมากข้ึน รวมถึงแทรกซึมเข้าไปยัง engineering culture ไปเรื่อย ๆ ไปตลอดกาลเวลา อ่อ เจ็บแล้วจำจนชินไปเองนี่เอง 😆 การเรียนรู้แบบจดจำ คือการมี Experiences กับมันครับ
สาย Java Developer อย่างผม ก็ส่วนใหญ่นี่แหละ หาดูตาม Conference หรือ Youtube ครับ เผื่อผมอยากไปทำงานแถวโซนยุโรปในอนาคต
นอกจากนั้นก็ผมยังแอบไปดูพวก Rust, LangChain หรือ How we can do with LLM นอกเรื่องละครับ อันนี้ส่วนตัว ๆ 5555555
Summary
เป็นยังไงกันบ้างครับสำหรับแต่ละข้อที่ผมเขียนเอาไว้ คือในบางครั้ง Engineering problems หรือ Business problems อาจจะไม่ใช่สถานที่ที่เราสามารถตอบสนองความ Need ของ Tech guys ที่อยากจะลองของใหม่ ๆ บางทีสิ่งที่พวกเขาพยายามสร้างขึ้นมา ก็อาจจะสนอง Need ของตัวเองล้วน ๆ และไม่ได้แก้ปัญหาให้กับผู้ใช้งานเลย
และก็ผมจะย้ำอีกครั้ง ไม่ใช่ว่าการใช้ของใหม่ ๆ หรือของแปลก ๆ จะเป็นผลเสียเสมอไป หลาย ๆ ครั้งมันก็สร้างผลประโยชน์ หรือ Benefits ให้กับ Organization ได้อย่างดีเยี่ยม พร้อมทั้งเปิดโอกาสทางเลือกใหม่ ๆ ที่ดีมากยิ่งขึ้นได้ และแน่นอน มันก็ไม่เป็นผลดีเสมอไปเช่นกัน ในหลาย ๆ ครั้งมันก็เป็นการสร้าง Technical debt หรือหนี้ทางเทคนิคให้กับ Organization จนเกิดเป็น Cost ด้าน budget และ time ไปกับการ maintainining มากกว่าการ develop ของใหม่ ๆ ออกมาแก้ปัญหาเช่นกัน
ไม่รุ่ง ก็ร่วง แต่ทั้งคู่ได้บทเรียน
สุดท้ายนี้ก็ถ้าหากใครอยากสอบถามเพิ่มเติม หรือจะ Make connection กันไว้ก็สามารถมาที่ช่องทางนี้ได้เลยนะครับ ขอบคุณที่อ่านจนจบนะครับ ไว้เจอกันใหม่บทความหน้าครับ ขอให้ทุกคนมีความสุข 🙇♂️
Facebook: Thanaphoom Babparn
FB Page: TP Coder
LinkedIn: Thanaphoom Babparn
Linktree: https://linktr.ee/tpbabparn
