บทความนี้เป็นการแชร์ประสบการณ์ของคุณ Jakub Górowski ซึ่งตอนยังเป็น Programmer เขามักจะคิดว่าตัวเองมีความสามารถในระดับของ Senior Developer แต่เมื่อวันหนึ่งเขาได้เป็น Chief Technology Officer (CTO) ใน Med-Tech startup แห่งหนึ่ง ทำให้เขาได้เรียนรู้ว่า สิ่งที่เขาคิดมันผิด เรามาดูกัน 4 ข้อผิดพลาด ที่ CTO ก็เคยทำ ตอนยังเป็น Programmer มีอะไรบ้าง
1. User ไม่รู้/ไม่ฉลาด
Users เป็นเพียงคนที่ใช้ App ในลักษณะที่ Developers ไม่คาดคิดและบางครั้งอาจด้วยวิธีการที่แตกต่างออกไป พวกเขาอาจถามคำถามที่ไม่น่าจะถาม หรือบางครั้งพวกเขาก็ต้องการ Feature ที่ดูเหมือนจะไม่มีประโยชน์
อย่าลืมว่า Users ไม่ใช่ Expert ขนาดแพทย์ของคุณ Jakub เอง ก็ไม่เคยต้องการให้เขาทราบถึงความแตกต่างระหว่าง Lipoproteins ชนิดที่มีความหนาแน่นต่ำและความหนาแน่นสูง แล้วทำไม Developers ถึงคิดว่า Users ควรต้องรู้ประเภทของ Browsers ที่พวกเขาใช้ล่ะ ขนาดแม่ของคุณ Jakub เองยังคิดว่า Google และ Internet คืออย่างเดียวกันเลย และเธอก็บอกว่าเธอไม่ได้ใช้ Browser นะ แต่เธอกำลังใช้ Google
ในบางครั้ง เพื่อความสุขและความสะดวกของ Users คุณ Jakub เคยต้อง Override ส่วนของ Framework เพื่อเปลี่ยน Default Behaviors ของมัน บางครั้งเขาก็จำเป็นต้องเพิ่มการรองรับสำหรับ Browsers ที่ไม่ได้เป็นกลุ่มเป้าหมายหลัก (อย่าง Safari Users) ในวันนี้อาจพูดได้ว่ามันเป็นเรื่องที่ออกจะงี่เง่าไปสักหน่อย แต่ ณ ตอนนั้นเขาคิดว่ามันเป็นความผิดพลาดของลูกค้า ที่ทำให้เขาต้องมาคอยนั่งแก้ปัญหาบางอย่างใน Code เพียงเพราะ Requirement ของลูกค้ามีการปรับเปลี่ยน
2. Code คือศิลปะ และมันจะต้องสมบูรณ์แบบ
ไม่ว่าจะเป็น Clean Code, Unit Test หรือ Documentation ที่ดี สิ่งเหล่านี้ล้วนเป็นสิ่งที่สำคัญอย่างไม่ต้องสงสัย ในฐานะของ Programmer คุณ Jakub ก็ย่อมอยากเขียน Code ที่ Clean โดยใช้ Patterns ที่ทันสมัยอยู่เสมอและเขาเองก็มักจะตรวจสอบว่า Dependencies ทั้งหมดใน Project ถูก Update ให้เป็นปัจจุบันหรือไม่ แน่นอนว่าทุกคนอยากเป็น Programmers ที่ดี
ตอนที่ Product Manager เคยขอให้คุณ Jakub ลดการทำ Unit Tests ลงเพื่อเพิ่มความเร็วในการ Develop ณ ตอนนั้นเขารู้สึกโกรธ และสงสัยว่า ทำไม Product Manager ถึงไม่รู้ว่า Unit Tests มีความสำคัญ ในทีมไม่มี Automatic Tests อื่น ๆ เลย ดังนั้น Unit Tests จึงเป็นความหวังเดียวของทีมที่จะทำให้ Product มีความ Stable และไม่แย่ลงไปเรื่อย ๆ เมื่อเวลาผ่านไป
การตัดสินใจครั้งนี้ดูเหมือนจะเป็นการตัดสินใจที่ไม่รอบคอบในความคิดของคุณ Jakub นอกจากนี้ Product Manager คนนั้นยังแนะนำว่า ทีมงานควรหยุดเขียน Documentation แล้ว Convert Code ให้ Architecture มีความซับซ้อนน้อยลง (ซึ่งที่จริงเราสามารถทำสิ่งนี้ได้ตั้งแต่ตอนเริ่มต้น Project)
อันที่จริงคุณ Jakub ก็ยอมรับว่า วิธีการเหล่านั้นจะทำให้การ Develop มีความรวดเร็วขึ้น แต่เราอาจจะมีปัญหามากมายในอนาคต เราจะเสียเวลามากมายกับการแก้ไข Bugs และ Architecture ใหม่ก็อาจจะเรียบง่ายเกินไปเมื่อ Project มีขนาดที่ใหญ่ขึ้น และที่สำคัญคือ เราจะแนะนำ Programmer ใหม่ ๆ ให้รู้จักและเข้าใจ Project โดยที่ไม่มี Readme ที่ดีได้อย่างไรกัน
ทีมงานและผู้เกี่ยวข้องใช้เวลาหลายชั่วโมงในการพูดคุยกันว่า การตัดสินใจครั้งนี้อาจส่งผลเสียมากแค่ไหน และอาจมี Cost เท่าใดที่ต้องจ่ายในอนาคต
สรุปแล้ว Project ล้มเหลวในไม่กี่เดือนต่อมา เนื่องจากมันเกิน Budget ไปอย่างมาก
หลายปีต่อมาคุณ Jakub ก็ต้องยอมรับความจริงที่ว่า ทีมงานทำผิดพลาดครั้งใหญ่ ที่คิดเกี่ยวกับอนาคตและลืมบางอย่างที่เกี่ยวกับปัจจุบัน ทีมงานเพิกเฉยต่อสถานการณ์หนึ่งโดยสิ้นเชิง ก็คือ การใช้ Budget ที่ไม่สูงและความจำเป็นในการสร้าง MVP ในเวลาอันสั้น
มันเป็นเรื่องดี ในการสร้าง Code ที่คุณสามารถแสดงให้คนอื่นได้เห็นและภูมิใจไปกับมัน แต่จะเป็นการดีกว่า ที่จะทำ Project ให้สำเร็จ ซึ่งท้ายที่สุดแล้ว Programming ไม่ใช่เรื่องของศิลปะเพียงอย่างเดียว
3. เราจะใช้ “Tech Stack นี้” ใน Project เพราะเรารู้จักมัน
ในบริษัทก่อนหน้าที่คุณ Jakub เคยทำงานด้วย มีการสร้างทุก Projects ด้วยเทคโนโลยีเดียวกันซึ่งก็คือ Symfony และ Angular คุณอาจเกิดคำถามว่าแล้ว Symfony เป็น Backend Framework ที่ดีที่สุดหรือไม่? คำตอบคือ “ไม่” บางที Angular อาจเป็นวิธีเดียวในการสร้าง Frontend ที่ทันสมัย ใช่หรือไม่? คำตอบคือ “ไม่” เช่นกัน ทีมงานมีการเลือก Set ของเทคโนโลยีเหล่านั้นมาโดยตลอด เพราะทีมงานไม่รู้จักเทคโนโลยีอื่นดีเท่ากับเทคโนโลยีเหล่านี้ นั่นคือ Comfort Zone ของทีมงาน แต่มันผิดไหม ที่จะเลือกเทคโนโลยีที่เป็นที่รู้จักสำหรับ Project ใหม่ ๆ คำตอบคือ แล้วแต่คุณ
ในหลาย ๆ กรณี Project ถัดไปของคุณอาจจะคล้ายกับ Project ก่อนหน้านี้ไม่มากก็น้อย มันไม่มีเหตุผลเลยที่จะใช้เวลามากมายไปกับการเรียนรู้เทคโนโลยีใหม่ ๆ ในเมื่อคุณมี Solutions ที่ได้รับการพิสูจน์ว่าดี มาแล้ว แต่บางครั้งมันก็อาจเป็น “การตัดสินใจที่ผิดพลาด”
คุณ Jakub จำได้ถึง Project ที่มี WebSocket เป็น Requirement ที่สำคัญที่สุด แล้วทีมเลือกอะไรในการสร้าง Backend? แน่นอนว่าเป็น Symfony บางทีวันนี้การสร้าง WebSocket ใน PHP อาจจะง่ายกว่า แต่ในช่วงนั้นมันเป็นฝันร้าย ทีมงานต้องใช้เวลานานมากในการทำให้มันทำงานได้ ทีมงานทราบดีว่ามันต้องใช้เวลา (และเงิน) มากเท่าใดในการสร้าง WebSocket โดยใช้ PHP แต่ทีมงานก็ทิ้งความคิดที่จะใช้ Node ไป เนื่องจาก แม้ทีมงานจะใช้ Node ซึ่งสามารถสร้าง API ได้เร็วขึ้นกว่าเดิม 10 เท่า แต่นั่นไม่ใช่ Tech Stack ที่ทีมงานคุ้นเคย
คุณ Jakub รู้สึกดีมากที่ Programmers ในทีมปัจจุบันมีความใจกว้างและเปิดรับสิ่งต่าง ๆ มากขึ้น เมื่อไม่นานมานี้ทีมงานตัดสินใจเปลี่ยนไปใช้เทคโนโลยีที่ใช้สร้างส่วนหนึ่งของ System ไปโดยสิ้นเชิง เขาแน่ใจว่าการตัดสินใจครั้งนี้ จะช่วยประหยัดเวลาได้มาก แม้ว่าอาจจะต้องเรียนรู้บางสิ่งตั้งแต่เริ่มต้นก็ตาม
4. Product Owner/Manager ทำผิด เราจะทำมันให้ดีกว่านี้
ตอนที่คุณ Jakub ทำงานเป็น Programmer ความสัมพันธ์ของเขากับ Product Manager ไม่ค่อยราบรื่นนัก เมื่อใดก็ตามที่ Product Manager มาบอกเขาเกี่ยวกับ การเปลี่ยนแปลงใน Scope งาน เขาก็มักรู้สึกว่า:
ทำไมคุณไม่ทำงานของคุณและกำหนดขอบเขตของงานให้ชัดเจน ก่อนที่จะเริ่มทำงาน? การตัดสินใจล่วงหน้าว่า Feature นั้นควรทำงานอย่างไร มันเป็นเรื่องยากนักเหรอ?
คุณ Jakub คิดว่ามันไม่ใช่เรื่องยากเลย แต่ตอนนี้เขาเข้าใจแล้วว่า การวางแผนในทุกรายละเอียดของ Project นั้นมีความท้าทายมากเพียงใด คุณต้องคำนึงถึงข้อจำกัดของเทคโนโลยีและ Budget คุณต้องนึกถึง Users ที่จะใช้ Product ของคุณด้วย คุณไม่สามารถมองข้าม Business และ Marketing Requirements ไปได้ บางครั้งคุณอาจไม่ทราบถึง Requirements บางประการในตอนต้น บางครั้งสถานการณ์ทาง Business ก็เปลี่ยนไป และบางครั้งคุณก็ต้องสร้างอะไรบางอย่างขึ้นมาก่อนที่คุณจะคิดออกว่า มันสามารถออกมาดีกว่านี้ได้
อีกอย่างหนึ่ง Product Manager ก็สามารถทำผิดพลาดได้, Programmer ก็สามารถสร้าง Bugs ได้, PMs ก็เช่นกัน มันชัดเจนมากเมื่อคุณ Jakub คิดเกี่ยวกับเรื่องนี้ในปัจจุบัน เขาคิดว่า เขาน่าจะสามารถเป็น Programmer ที่ดีกว่านี้ได้ ถ้าก่อนหน้านี้ แทนที่เขาจะพยายามแสดงให้เห็นว่าเหล่า Product Owner/ Product Manager ทำผิดพลาด เขาควรที่จะมุ่งเน้นไปที่การหา Solution มากกว่า
มันทั้งน่าขันและน่าเศร้าไปด้วยพร้อม ๆ กัน แต่เมื่อถึงจุดหนึ่งคุณ Jakub ลืมไปว่า เขาและ Manager มีเป้าหมายเดียวกัน ก็คือ การสร้าง Product ที่ยอดเยี่ยม อันที่จริงเหล่า Managers มีความรู้ความเข้าใจเกี่ยวกับ Budget, สถานการณ์เกี่ยวกับ Business, Requirements จากฝั่งลูกค้า, Deadlines และ Priorities ซึ่งแน่นอนว่ามันมากกว่าที่ตัวเขามี นั่นอาจเป็นสาเหตุที่เขาไม่เข้าใจการตัดสินใจบางอย่างของ Managers
“การเป็น Programmer ที่ดี” นั้นไม่ได้เกี่ยวกับทักษะด้าน Technical เพียงเท่านั้น แต่สิ่งสำคัญยิ่งกว่าคือ การที่คุณเข้าใจว่า อะไรคือ Value ที่คุณจะสามารถทำให้บริษัทได้และคุณจะทำมันอย่างไร จากที่คุณ Jakub เคยคิดเกี่ยวกับคุณสมบัติของ Senior Developer ตอนนี้มันเปลี่ยนไปเป็นดังนี้:
“Senior Developer ไม่ใช่คนที่รู้ทุกแง่มุมของเทคโนโลยี แต่เป็นบุคคลที่สามารถช่วยบริษัทในการสร้าง Products ที่ยอดเยี่ยม แม้ว่าสิ่งนั้นจะทำให้พวกเขาออกจาก Comfort Zone ก็ตาม แนวทางแก้ปัญหาสำคัญกว่าตัวปัญหา”
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการมา 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย
หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่
Source: https://betterprogramming.pub/