บทความนี้เขียนโดย Mitchell Irvin ซึ่งเขาจะมาถ่ายทอดถึง สิ่งที่ได้เรียนรู้จากการเป็น Software Engineer มา 2 ปี เรามาดูกันว่า เขาได้เรียนรู้เรื่องอะไรมาบ้าง เชื่อว่าน่าจะเป็นประโยชน์กับคนไอทีและคุณยังสามารถนำไปประยุกต์ใช้ในการทำงานได้จริงอีกด้วย
มหาวิทยาลัย กับ ที่ทำงาน
ในช่วงปี 2015 ที่ Mitchell กำลังศึกษาอยู่ที่ University of Florida เขาได้เรียนวิชาที่ยากที่สุดวิชาหนึ่ง ซึ่งมีการแบ่งทีมเพื่อทำ Project ตลอดเทอม ทุกครั้งที่เริ่ม Project ใหม่ อาจารย์จะแบ่งกลุ่มให้นักศึกษาที่เก่งอยู่ด้วยกัน กลุ่มที่ไม่เก่งก็อยู่ด้วยกัน ทีมที่มีความพยายามก็จะประสบความสำเร็จ ส่วนทีมที่อ่อนกว่าก็ล้มเหลวไป เขาคิดว่ามันดีมากที่คนเก่งๆ ไม่ต้องถูกบังคับให้มาโอบอุ้มคนที่เก่งน้อยกว่า ซึ่งเขาชอบแนวทางแบบนี้มาก จนปีต่อมาหลังจากจบการศึกษา เขาก็ได้ทำงานเป็น Software Engineer ที่บริษัทมีชื่อเสียงขนาดใหญ่แห่งหนึ่ง
Mitchell เริ่มต้นทำงานใน Project หนึ่ง ซึ่งต้องการกำลังสร้าง Web Application ทั่วไป โดยทำงานร่วมกับ Engineer 3 คน เมื่อทำงานไปไม่กี่เดือนก็พบว่า เขากลายเป็นกำลังสำคัญของทีมที่สามารถจัดการได้กับทุกอย่างใน Project และด้วยอายุเพียง 22 ปี เขาก็ได้รับบทบาทเป็น Lead Engineer ในบริษัทที่ติดอยู่ใน Fortune 25
ทุกอย่างดูเหมือนจะดีแต่มันกลับไม่ใช่ เพราะ เขาต้องช่วยแบกรับคนในทีมซึ่งมีประสบการณ์ทำงานแล้ว ผลงานเขาไม่ได้เกรด A แต่คนอื่นกลับไม่ได้ F เขาไม่มีหุ้นใบริษัท มีเวลาพักร้อนน้อยลง เขาต้องอดทนและช่วยเหลือเพื่อนร่วมทีม ต่อมาเขาเริ่มไม่ค่อยแยแสกับอะไร และ Productivity ก็เริ่มลดลง
Mitchell เป็นแบบนี้อยู่ 3 เดือน จนช่วงท้ายของ Project ขวัญกำลังใจของทีมย่ำแย่ ไม่มีใครเฉลิมฉลองกับความพยายามใน 14 เดือนที่ผ่านมา ที่สำคัญกว่านั้นเขารู้ว่าเพื่อนร่วมทีมของเขาส่วนหนึ่ง ไม่ได้รู้สึกตื่นเต้นที่จะได้ร่วมงานกับเขาอีกในอนาคต เขาเริ่มตระหนักว่า ทัศนคติของเขาที่มีต่อสภาพแวดล้อมในการทำงาน กำลังส่งผลกระทบต่อตัวเขาเองและคนรอบข้าง
หลังจากนั้นไม่กี่สัปดาห์ เขาก็ส่ง Survey ไปให้เพื่อนร่วมงานเพื่ออยากทราบ Feedback จากเพื่อนร่วมทีม แต่ผลที่ออกมาทำให้ทราบว่า “Performance” ไม่ใช่คำตอบของทุกสิ่ง ตอนเริ่มทำงานเขาเคยคิดว่า วิธีที่เคยใช้ตอนเรียนจะใช้ได้แบบเดียวกันกับที่ทำงาน ซึ่งการคิดแบบนี้กลับกลาย “เป็นพิษ” ต่อความสามารถของเขาในการที่จะทำงานร่วมกับคนอื่น ต่อความซาบซึ้งในความช่วยเหลือของผู้อื่น, ความใฝ่รู้ และอดทนเมื่อต้องสอนผู้อื่น ตอนนี้คนอื่นกำลังมองว่า “เขาโฟกัสไปที่ Performance มากเกินไป”
*** บทเรียนที่ 1: ความสัมพันธ์ของคุณกับเพื่อนร่วมงาน (interpersonal/leadership skills) และความสามารถทางด้านเทคนิคของคุณ (hard skills) มีความสำคัญเท่าเทียมกัน
ในการเป็น Software Engineer ที่ยอดเยี่ยม คุณอาจต้องฝึกฝนฝีมือเป็นเวลาหลายปี คุณอาจต้องผ่านช่วงเวลาที่แย่แต่หากผ่านไปได้คุณก็จะสำเร็จ คุณอาจทำผิดพลาดบ้าง แต่จงเรียนรู้จากผู้อื่น และแบ่งปันความรู้ให้ผู้อื่น หากเป้าหมายของคุณ คือการเป็น Software Engineer ที่ดีที่สุดเท่าที่จะทำได้ เส้นทางนั้นจะต้องมีเพื่อนร่วมทีมที่ดีด้วย (ซึ่งอาจเป็นหัวหน้า) เริ่มต้นด้วยการให้ความสำคัญกับผู้คนรอบข้างให้เหมือนกับที่ให้ความสำคัญกับตนเอง
Engineer ที่ดีที่สุด ที่เคยร่วมงานด้วย
ครั้งหนึ่ง Mitchell เคยทำงานกับพนักงาน Contract ที่เข้ามาร่วมทีม 2 คน สำหรับวิธีทำงานของทีม จะใช้วิธีการจับคู่กันทำงาน (Pair Programming) โดยเขาเองก็ได้จับคู่กับ Contractor คนหนึ่งที่ชื่อ Bob ซึ่งการทำงานกับ Bob นั้น เขาต้องเจอกับคำถามอยู่เสมอ เมื่อจะทำ Feature ใหม่ๆ Bob จะถามว่าใช้ Language และ Framework ใด, ตอนที่มีการปรับแก้รายละเอียดใน Business Rules, Bob จะถามเกี่ยวกับ Product และปัญหาที่ทีมกำลังแก้ไขอยู่ ซึ่งในแต่ละวัน Bob ไม่ค่อยได้เขียน Code มากนัก ทำให้ Mitchell รู้สึกผิดหวัง เพราะ Mitchell เองก็คาดหวังไว้สูงในทักษะด้าน Engineer ของ Bob และหวังว่าจะได้เรียนรู้อะไรจาก Bob บ้าง
วันถัดมา ขณะที่ Mitchell กำลังเขียน Test Case สำหรับ Feature หนึ่งและ Run มัน เขายิ้มเมื่อมีเครื่องหมายถูกสีเขียวปรากฏขึ้นบนหน้าจอ แต่ Bob ทำท่าครุ่นคิด หลังจาก Test ผ่าน Bob ก็เข้าไปยัง Method ที่ Test และแก้ไข Code 1-2 บรรทัด แต่ Mitchell กลับห้ามว่าอย่าทำ ซึ่ง Bob ก็พยักหน้า แล้วทำการ Run Test อีกครั้ง ซึ่งผลก็คือ ผ่าน
หลังจากทำงานคู่กัน 1 สัปดาห์ Bob ยังคงมีคำถามเสมอ Bob เริ่มสามารถตอบคำถามในเรื่อง Language และ Framework ที่บริษัทใช้งานอยู่ โดยเขาแนะนำ OO Design Pattern ที่ Mitchell ไม่คุ้นเคย คำถามของ Bob เกี่ยวกับปัญหาทางธุกิจกำลังเปิดช่องโหว่ของ Software แถมยังเจอ Bug และข้อบกพร่องใน Code ที่ Mitchell ไม่เคยรู้ว่ามันมีอยู่ เมื่อเวลาผ่านไป Bob และ Mitchell แก้ Bug ที่ค้นพบ, ออกแบบ Software ที่ไร้ช่องโหว่ และปรับปรุงความเชื่อมโยงระหว่างปัญหาทางธุรกิจและ Code ของพวกเขา
เมื่อมีการสนทนากันในทีม Bob ไม่เคยซ้ำเติมในความผิดพลาดของผู้อื่น เขาแค่ตั้งคำถาม แทบทุกการตัดสินใจเกี่ยวกับ Software นั้น มักจะพบคำถามของ Bob เสมอ Bob ไม่เคยอ้างสิทธิ์ในการมีส่วนร่วมของเขาต่อทีม ไม่เคยพูดถึงความสามารถในฐานะ Engineer เลย และดูเหมือนเขาจะไม่สนใจเลยว่าจะใช้เวลาในการ Coding มากน้อยแค่ไหน สรุปแล้ว Bob เป็น Engineer ที่ดีที่สุดที่ Mitchell เคยร่วมงานด้วย
*** บทเรียนที่ 2: ความสามารถของคุณที่มีอิทธิพลต่อผู้อื่นนั้น เป็นสิ่งสำคัญที่สุด โดยความสามารถของคุณจะช่วยให้ผู้อื่นได้ข้อสรุปเดียวกันกับสิ่งที่คุณทำด้วยตนเอง
Bob มักถามเกี่ยวกับ Idea อื่นๆ เวลามีการสนทนากันในทีม และบ่อยครั้งที่เขาจะได้รับคำตอบจากหนึ่งในคำถามของเขาซึ่งนำไปสู่คำพูดที่ว่า “มันใช่เลย เดินหน้ากันต่อได้เลย” Bob มีอิทธิพลด้านบวกอย่างมากต่อคุณภาพของ Software ที่กำลังพัฒนาอยู่ เพราะเขามีความสามารถที่จะจูงใจคนในทีมในการอ้างอิงเหตุผล
*** บทเรียนที่ 3: มันเป็นลักษณะของนักแก้ปัญหาที่ยอดเยี่ยม ที่จะถามคำถามหลายข้อ ก่อนที่จะเริ่มคิดวิธีแก้ปัญหา
Software Engineer ที่ยอดเยี่ยม จะเป็นนักแก้ปัญหาที่ยอดเยี่ยมด้วย และการแก้ปัญหาที่ดี เริ่มต้นด้วยการทำความเข้าใจปัญหาด้วยการถามคำถาม เพราะการถามแสดงให้เห็นถึงความเคารพต่อความคิดของผู้อื่น การถามคำถามช่วยให้คุณเข้าใจในสิ่งที่คุณไม่เคยรู้ คนที่มีวิธีการแก้ปัญหาที่ดี มักจะเป็นคนที่ใช้เวลาในการทำความเข้าใจกับปัญหาได้เป็นอย่างดี
Bob มีความสามารถทางด้านเทคนิคมากเพียงพอที่จะเป็น Leader ของทีมได้ เขาชอบเขียน Code ชอบวิเคราะห์, ออกแบบ Business object และเขียน Test ที่มีประสิทธิภาพและส่งมอบ Software ที่มีคุณภาพ
เมื่อมองย้อนกลับไป
ช่วง 2 ปีแรกของ Mitchell ถือเป็นปีแห่งการผจญภัยในสายอาชีพก็ว่าได้ เขาทั้งสร้าง Software, ทำ Software เสียหาย รวมทั้งแก้ไข Software เขาทั้งทุ่มเทกับงานด้วยความสุขและความเจ็บปวดปะปนกันไป และเมื่อมองย้อนกลับไป สิ่งที่เขารู้สึกเสียดายก็คือ
- เวลาที่ใช้ไปกับการให้ความสำคัญกับ “งาน” มากกว่า “ตัวบุคคล” งาน (Product) จะเรียงลำดับตัวเองเสมอ อย่างไรก็ตามเรื่องของความสัมพันธ์ อาจเป็นเรื่องที่ยากในการรักษาไว้และทำให้กลับมาเหมือนเดิมหากมันเสียไปแล้ว
- เวลาที่ใช้ไปกับการค้นหา ปรับปรุงให้ดีขึ้นและมองลงไปให้ลึก คุณคงไม่สามารถเป็นเพื่อนร่วมทีมที่ดีได้จากการ Focus ไปที่การปรับปรุงตัวของผู้อื่น แต่คุณจะเป็นคนที่ดีขึ้นได้จากการตระหนักถึงจุดอ่อนและจุดแข็งของตัวเอง
- เวลาที่ใช้ไปกับการพูด ทั้งที่เขาก็สามารถเป็นผู้ฟังได้ ไม่มีใครที่ฉลาดขึ้นหรือได้รับความเอาใจใส่มากขึ้น เมื่อพวกเขาพูดอย่างเดียวหรอก
- เวลาที่ใช้ไปกับความหงุดหงิดในบางสิ่งและไม่ได้สื่อสารอย่างเปิดใจกับหัวหน้างาน พวกเขาคงไม่สามารถช่วยเหลืออะไรได้ หากพวกเขาไม่รู้ว่าปัญหาคืออะไร
หากคุณพยายามอย่างหนักและใส่ใจกับงานที่ทำมากไป คุณอาจทำให้ใครบางคนขุ่นเคืองใจ คุณจะล้มเหลวอย่างต่อเนื่อง หากคุณทำแบบนี้กับใครไป ก็ขอให้เข้าขอโทษพวกเขาด้วยความจริงใจ และก้าวต่อไปข้างหน้า การกระทำเช่นนี้จะชี้วัดความแตกต่างระหว่าง “Software Engineer” ที่ไม่ก้าวหน้า และคนที่ได้เป็นแนวหน้าใน Industry
เมื่อ Mitchell กำลังเดินต่อไปข้างหน้า นี่คือสิ่งที่สำคัญที่สุด:
- เป้าหมาย: เป็น Software Engineer ที่ดีที่สุดเท่าที่จะเป็นไปได้ อาจต้องใช้เวลาและมันจะพัฒนาขึ้นไปทีละ Step
- เป้าหมาย: เป็นเพื่อนร่วมงานที่ดี การเป็น Engineer ที่ดีที่สุด คงจะไม่มีความหมายเลยหากเราไม่มีความสัมพันธ์ที่ดีกับผู้อื่น การทำงานร่วมกันเป็นทีม สามารถชนะ ความสามารถส่วนบุคคลได้
- เป้าหมาย: ให้ความสำคัญกับการจัด Priority ในชีวิต เพราะ Software คงไม่สำคัญกว่าความสัมพันธ์ที่ดีของเรากับ คู่รัก เพื่อน หรือสุขภาพ ให้คิดดูว่าอะไรที่สำคัญที่สุดสำหรับคุณ และเขาเองก็ไม่ได้วางแผนที่จะเสียสละสิ่งเหล่านั้นเพื่อแลกกับ Software
หวังว่าประสบการณ์ของ Mitchell คงจะช่วยเป็นอุทาหรณ์ให้กับคนไอทีได้เป็นอย่างดีในเรื่องการทำงานร่วมกับผู้อื่น
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการกว่า 25 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่
Source: https://www.medium.com/