เกือบ 4 ปีที่แล้ว Stephen McLean ได้เรียนจบปริญญาตรีด้าน Computer Science และเริ่มต้นอาชีพด้วยการเป็น Software Developer ซึ่งในบทความนี้เขาจะมาแบ่งปัน 5 บทเรียน ที่ได้จากการเป็น Software Developer มา 4 ปี มาให้ทุกคนได้อ่านกัน
1. อย่าทึกทักเอาเอง
หลังจาก Stephen เริ่มงานแรก ก็ได้รับ Assignment งานที่ทำในระยะสั้น ๆ ใน Project ระยะยาวซึ่งมี Developer ทำงานหลายคน แถมมี Codebase ขนาดใหญ่ ซับซ้อน พร้อมทั้ง External Services ต่าง ๆ อีกมากมาย
งานที่ได้รับมอบหมายงานแรกก็ คือ แก้ไข unit tests ที่ล้มเหลวเป็นระยะ ๆ Code ที่ถูก Test นั้นค่อนข้างเก่าและเขียนโดย Senior Developer เนื่องจาก Function การใช้งาน ทำงานได้ดีจาก UI และได้รับการ Test อย่างละเอียดจาก QA เขาจึงตั้งสมมติฐานว่า ปัญหาน่าจะต้องเกิดจากการ Test ของพวกเขา
Stephen ใช้เวลาเกือบ 3 วันในการพยายามแก้ไข Test ที่ไม่เสียหาย เมื่อเขาอธิบายให้ทีมทราบว่า เพราะเหตุใดการแก้ไขจึงใช้เวลานาน คนในทีมจึงสอนบทเรียนสำคัญเรื่องแรกให้ Stephen โดยบอว่า เขาไม่ควรทึกทักเอาเองว่า Code ของคนอื่นจะถูกต้องทั้งหมดเพียง เพราะมันดูเหมือนจะดีไม่มีปัญหา
อาจเป็นบทเรียนที่สำคัญที่สุดที่เขาได้เรียนรู้ และสามารถนำไปใช้กับหลาย ๆ สถานการณ์ได้ ไม่ใช่แค่เฉพาะกับ Code เท่านั้น นอกจากนี้ยัง:
-
- อย่าทึกทักเอาเองว่า จะมีคนทำอะไรบางอย่างเพียงเพราะคุณขอร้องให้พวกเขาทำ ควรมีข้อตกลงที่ชัดเจนเสมอ หากคุณไม่ได้รับคำตอบจากคนที่คุณสอบถามให้พวกเขาเช็คบางอย่างให้ คุณก็ควรส่ง Email เพื่อ Follow-up หากเรื่องนั้นสำคัญ มันก็สำคัญมากพอที่คุณจะต้อง Follow-up มัน
- อย่าทึกทักเอาเองว่า จะมีคนเข้าใจในสิ่งที่คุณบอกกับพวกเขา แม้ว่าพวกเขาจะพูดว่าเข้าใจก็ตาม นี่คือสิ่งที่ Stephen ได้เรียนรู้หลังจากทำงานจนถึงจุดที่เขาได้ช่วยให้คำปรึกษาแก่ Junior Developer มากขึ้น ซึ่งเขาพบว่าเขาจะใช้ตรวจสอบผ่านการสั่งงานและติดตามผลในวันถัดไป เพื่อค้นหาว่ามี Developer คนไหนบ้าง ที่งานไม่คืบหน้าทั้งที่บอกว่าพวกเขาเข้าใจในสิ่งที่ Stephen ต้องการเป็นอย่างดี ในทางกลับกันคุณควรให้พวกเขาอธิบายถึงสิ่งที่ได้คุยกันเพื่อให้แน่ใจว่าพวกเขาเข้าใจมันชัดเจน ซึ่งสิ่งนี้สามารถประยุกต์ใช้ได้กับสถานการณ์อื่นด้วย เช่น เมื่อคุณต้องอธิยานบางสิ่งให้กับ BA หรือ QA ฟัง เป็นต้น
- อย่าทึกทักเอาเองว่า คนในฝ่ายอื่นผิด Stephen คิดว่า Developer มีแนวโน้มที่จะโทษคนอื่นเมื่อ Code ของพวกเขาไม่ทำงาน คุณปกป้อง Code ที่คุณเขียนจนถึงจุดที่คุณมั่นใจว่ามันไม่มีอะไรผิด หาก QA บอกคุณว่า พวกเขาพบปัญหา และพวกเขามีเหตุผลที่จะทำเช่นนั้น มันไม่ทำให้คุณเสียหายมากนักเพื่อให้พวกเขาได้รับประโยชน์จากข้อสงสัย และพวกเขาก็จะขอบคุณคุณด้วยซ้ำ
2. ปัญหาที่ไม่ใช่ทางด้าน Technical นั้นยากที่สุด
ในมหาวิทยาลัย ปัญหาทั้งหมดเป็นเรื่องทาง Technical การหาวิธีทำให้ ส่วนของ Code ทำงานได้ เกือบจะเป็นปัญหาอยู่เสมอ อย่างไรก็ตาม ในชีวิตการทำงานของ Stephen พบว่า มันไม่ค่อยจะเกิดขึ้นนัก
ควรทำให้มั่นใจว่าการสื่อสารมีความชัดเจนภายในทีมขนาดใหญ่ที่ทำงานกันหลายที่ มั่นใจว่ากระบวนการทำงานและมีการบันทึกไว้อย่างชัดเจน
หาวิธีช่วยเหลือหรือให้คำปรึกษาสมาชิกใหม่ในทีม พยายามแนะนำสิ่งใหม่ ๆ ให้กับ Process Development โน้มน้าวให้ Project Management มุ่งเน้นไปที่ให้ Code ใช้งานได้ในระยะยาว
เหล่านี้เป็นเพียงตัวอย่างเล็กน้อยที่แสดงชนิดของสิ่งที่คุณสามารถพบเจอใน Project ในความคิดของ Stephen พวกมันยากกว่าการ Track ตัว Null-Pointer เสียอีก
3. คิดก่อน แล้ว Code ทีหลัง
คุณสังเกตเห็น Process ที่สามารถปรับปรุงได้ คุณตัดสินใจที่จะทำให้เป็น Automate ทันที คุณใช้เวลาว่างในการ Develop สิ่งที่จะเปลี่ยนวิธีการทำงานของทีม
มันฟังดูคุ้นใช่ไหม? Developer (รวมทั้ง Stephen) ชอบ Automated Solutions
Stephen ได้เรียนรู้อะไรบ้าง? อย่าเพิ่งรีบ Code ทันที หยุดและคิดถึงปัญหา ไม่ใช่วิธีการแก้ปัญหา พูดคุยกับผู้คนที่หลากหลายไม่ใช่แค่เฉพาะ Developer คิดดูว่าปัญหานั้นเป็น ปัญหาทางด้าน Technical หรือปัญหาด้าน Process เสียก่อน แล้วค่อยคิดเกี่ยวกับ Solutions
แน่นอนว่าการหาวิธีแก้ปัญหาที่ซับซ้อนโดยใช้ Docker และ Script ที่ถูกเขียนขึ้นมาอย่างดีนั้นเป็นสิ่งที่ยอดเยี่ยม และคุณอาจจะได้เรียนรู้แนวทางบางอย่างที่ดี แต่การเสนอวิธีแก้ไขปัญหาด้าน Technical สำหรับปัญหาที่ไม่ใช่ด้าน Technical อาจไม่ช่วยทีมในระยะยาว มันอาจปกปิดปัญหาที่ใหญ่กว่า
4. สิ่งที่คุณสร้างมีความสำคัญมากกว่าเครื่องมือที่ใช้ในการสร้าง
เมื่อ Stephen เรียนจบ เขาชอบเขียน Code เรียนรู้ภาษา Programming และ Framework ใหม่ ๆ และอะไรก็ตามที่เกี่ยวข้องกับองค์ประกอบทางด้าน Technical
อย่าเพิ่งเข้าใจ Stephen ผิด ตอนนี้เขาก็ยังทำอยู่ แต่เขาก็ได้ตระหนักว่า ตราบใดที่เครื่องมือที่เราใช้ในการ Develop ทำให้เราสามารถทำงานให้สำเร็จได้ ไม่สำคัญว่าเครื่องมือเหล่านั้นจะเป็นอะไรก็ตาม ใน Front-End Development มี Framework ใหม่ ๆ เกิดขึ้นทุกวัน ในขณะที่มันเป็นสิ่งสำคัญในฐานะของ Developer ที่ต้องติดตาม, End user (คนสำคัญ) ไม่สนใจว่ามันทำงานอย่างไร แต่สนใจแค่ว่ามันทำงานได้
5. ทุกบทบาทล้วนมีความสำคัญเท่าเทียมกัน
Stephen ได้พูดถึงความสำคัญของการไม่ทึกทักเอาเองโดยอัตโนมัติว่าทุกคนที่ไม่ใช่ Developer นั้นผิด นอกจากนี้เขายังได้เรียนรู้อีกว่า สมาชิกแต่ละคนที่ร่วมทำงานอยู่ในทีมเดียวกับคุณ (BA, QA, Project Manager, ผู้เกี่ยวข้องคนอื่น ๆ) ล้วนมีความสำคัญเทียบเท่ากับ Developer
Project คงไม่เดินหน้าหากไม่มีตัวแทนที่ทำหน้าที่แต่ละบทบาท และในทำนองเดียวกัน Project จะไม่เดินหน้าหากการจัดหาResource ใหม่ ๆ ไม่ได้รับการแบ่งปันอย่างเท่าเทียมกันระหว่างประเภทของ Resource ที่แตกต่างกัน
เขาได้เรียนรู้อีกว่า แม้ว่าจะเป็น Developer ที่เขียน Code เองจริง ๆ แต่มันไม่จำเป็นต้องมี Code เลยหากไม่มีผู้มีส่วนได้เสีย และจะไม่มีผู้มีส่วนได้ส่วนเสียโดยปราศจากการประกันคุณภาพของสิ่งที่พวกเขาทำ
สรุป
หวังว่า บทเรียน 5 ข้อนี้ น่าจะเป็นประโยช์กับ Developer ที่กำลังทำงานร่วมกับคนอื่น ๆ ที่มาจากหลากหลายส่วน และได้เข้าใจบทบาทของการทำงานมากขึ้น
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการกว่า 28 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่
Source: https://medium.com/