โดยทั่วไป การทำงานไม่ว่าจะเป็นสายอาชีพใด ก็คงเน้นในเรื่อง Efficiency กันอยู่แล้ว แต่อีกเรื่องที่เลี่ยงไม่ได้เช่นกัน คือเรื่องของ Productivity ซึ่งสำหรับคนไอทีแล้วถือเป็นเรื่องสำคัญมากเช่นกัน สำหรับบทความนี้ คุณ John Lafleur จะมาบอกว่า 12 เรื่อง ที่ทำให้ Productivity ของ Developer ลดลงมีอะไรบ้าง เรามาติดตามกันเลย
1. Interruptions & Meetings
Interruptions (การขัดจังหวะ) ดูจะเป็นประเด็นอันดับต้นๆ ที่ทำลาย Productivity ของ Developer เพราะ การทำงานโดยทั่วไปของ Developer จะมีจังหวะลื่นไหล หากมีอะไรมารบกวนหรือขัดจังหวะ กว่าพวกเขาจะกลับไปมีความคิดลื่นไหลได้อีกครั้งอาจต้องใช้เวลาพอสมควร ส่วนเรื่องการ Meeting ต่างจาก Interruptions นิดหน่อยตรงที่ มันเป็น Interruptions ที่วางแผนไว้ล่วงหน้า ซึ่งจะว่าไปเราก็คงหลีกเลี่ยงไม่ได้
ทางแก้ไข ก็คือ คุณจะต้องมีการจัดการที่ดีและวางแผนล่วงหน้า ถ้าคิดอะไรออก ก็รีบจดบันทึกสิ่งที่คุณคิดไว้ก่อน จะได้ไม่ลืม หรือหากมีอะไรมาขัดจังหวะ ก็รีบบันทึกไว้ว่าเราทำงานค้างไว้ที่จุดไหน แล้วจะทำอะไรต่อ จะได้ช่วยลดการเสียเวลามานั่งคิดถึงสิ่งที่ทำค้างไว้
2. Micro-management
หากหัวหน้าของคุณ ทำงานแบบ Micro-management ก็ส่งผลให้ Productivity ของ Developer ต่ำลงได้เช่นกัน ลักษณะหัวหน้าแบบนี้ เช่น ประชุมบ่อยโดยมักไม่ค่อยบอกล่วงหน้า ไม่ไว้ใจลูกน้องให้ทำงานเอง ซึ่งถือเป็นการไม่ส่งเสริมทักษะและความสามารถของคุณเลย และด้วยเหตุนี้ มันจึงเหตุผลอันดับต้นๆ ที่ทำให้ Developer ลาออกจากงานได้ หรืออย่างน้อยก็อยากย้ายไปอยู่ทีมอื่น
3. Vagueness
คงไม่มีใครชอบความคลุมเครือ หรอกจริงไหม อย่างเช่น มีคนเขียนใน Bug report ว่า “มันใช้การไม่ได้ แก้ไขซะ” แบบนี้ไม่ได้ให้ข้อมูลที่เป็นประโยชน์ต่อ Developer เลย สำหรับวิธีแก้ไขในกรณีนี้ หากมีการสร้าง Template น่าจะช่วยลดปัญหาลงได้
สำหรับการกำหนด Spec ที่ไม่เคลียร์ของ Feature อาจทำให้ Developer ใช้ความรู้สึกของตนเองคิดเอาว่ามันจะเป็นแบบใด แต่ถ้า Manager ช่วยลงรายละเอียดให้จะช่วยให้ Developer ทำงานได้ตรงขึ้น รวมทั้งเรื่องการมี Priority ที่ไม่ชัดเจนก็อยู่ในหัวข้อนี้ด้วย พวกเขาอาจเสียเวลาในการต้องมาคิดว่า ควรเริ่มทำงานไหนก่อนดี แล้วถ้าวันหนึ่ง Manager มาถามว่า ทำไมถึงทำงานนี้ก่อนทั้งที่ไม่ใช่งานด่วน แบบนี้ก็สร้างความยุ่งยากในการทำงานได้
4. Seagull Management
บางครั้งคุณอาจเจอกับ Manager ที่ใช้อำนาจสั่งการหรือทำสิ่งใดสิ่งหนึ่งโดยไม่ได้ฟังความเห็นของคนทำงาน อาจเข้ามาเพื่อติว่า “อย่างโน้นไม่ดี อย่างนี้ไม่ได้” โดยสุดท้ายนอกจากไม่ช่วยแก้ปัญหาแล้ว กลับทำให้ทุกอย่างแย่ลงอีก ซึ่งพฤติกรรมแบบนี้ สร้างความหงุดหงิดให้กับ Developer แน่นอน เพราะทำให้ทำงานลำบากขึ้น
5. Credit Greediness
ไม่แน่ใจว่าคุณเคยเจอ Manager หรือ Developer คนอื่นที่คอยขโมยเครดิต หรือแย่งผลงานที่คุณเป็นคนทำกับมือ บ้างไหม Developer ให้ความสำคัญกับความสามารถเหนือสิ่งอื่นใด การที่มีคนอื่นมาฉวยโอกาสแย่งชิงผลงานไป แบบนี้มันสร้างความตึงเครียดอย่างมากและความรู้สึกที่ไม่ดีต่อกัน จนกระทบกับ Productivity ของ Developer ได้มากพอสมควร
6. Environment — Noises, Motion, Workspace Design…
สำหรับ Developer/Programmer แล้ว สภาพแวดล้อมที่พวกเขาทำงานอยู่ สามารถส่งผลกระทบสำคัญต่อการทำงานได้ค่อนข้างมาก เช่น เสียง White noise อย่างเสียงของธรรมชาติ เสียงฝนตก สายลม น้ำไหล ก็ช่วยทำให้พวกเขาผ่อนคลายและมีสมาธิในการทำงานมากขึ้น เราจึงมักเห็นเหล่า Programmer ชอบใส่ Headset นั่นเอง อยากให้คุณลองฟัง RainyMood ดู แต่หากในที่ทำงานของคุณ มีการเคลื่อนไหวผ่านไปผ่านมาตลอดเวลา ก็ทำให้พวกเขา Focus สิ่งที่ทำได้ยากขึ้น
7. Scope Creepiness
Scope creep (หรือ focus creep, requirement creep, feature creep และบางครั้งก็เรียก kitchen sink syndrome) ในการจัดการ Project คือ การเปลี่ยนแปลง Scope ของ Project จนยากที่จะควบคุม สิ่งนี้จะเกิดขึ้นเมื่อ Scope ของ Project ไม่ได้ถูกจัดทำเป็น Document หรือมีการควบคุมอย่างเหมาะสม นั่นคือมีการเปลี่ยนแปลง Requirement ที่ยากและซับซ้อนมากขึ้นเรื่อยๆ เช่น
Version 1 (ก่อน Implementation): feature คือ “โชว์แผนที่ของ Location”
Version 2 (เมื่อ version 1 เกือบเสร็จ): feature ถูกเปลี่ยนเป็น “โชว์แผนที่แบบ 3D ของ Location”
Version 3 (เมื่อ version 2 เกือบเสร็จ): feature ถูกเปลี่ยนอีกครั้งเป็น “โชว์แผนที่แบบ 3D ของ Location ซึ่ง User สามารถเข้าไปดูรายละเอียดได้”
8. Product Definition Process
หากทีม Product กำหนด Priority ของทีม โดยไม่ได้วิเคราะห์ตรวจสอบ (จาก Feedback ของลูกค้าหรืออื่นใดก็ตาม) ถึงความสนใจของ Feature ที่เกี่ยวข้อง และ Developer เห็นว่า Feature ส่วนใหญ่อาจไม่ได้ใช้งาน ในที่สุดพวกเขาจะรู้สึกว่า สิ่งที่ทำนั้นช่างไร้ประโยชน์ และขาดแรงจูงใจในการทำ เราทุกคนต้องการที่จะรู้สึกว่า สิ่งที่ทำนั้นสร้าง Impact ต่อคนจำนวนมาก และนั่นอาจเป็นสิ่งสำคัญยิ่งสำหรับ Developer
9. Lack of Consideration to Technical Debt
Technical debt หรือ “หนี้ทางเทคนิค” เป็นการตัดสินใจโดยตั้งใจที่จะใช้วิธีแก้ปัญหาที่ไม่ดีที่สุด หรือเขียน Code ที่ไม่ดีที่สุดเพื่อจะได้ Release Software ได้เร็วขึ้น ซึ่ง ณ วันนี้มันอาจจะดีอยู่ แต่ในระยะยาวมันอาจก่อให้เกิดความซับซ้อนของ System ซึ่งทำให้การ Develop ช้าลงด้วย คนที่ไม่ใช่ Programmer มักประเมินความสูญเสีย Productivity ต่ำเกินไป และอยากที่จะก้าวไปข้างหน้าอยู่เสมอ ซึ่งสิ่งนี้ จะกลายเป็นปัญหา ถ้าให้ความสำคัญในเรื่องของการ Refactor เสียตั้งแต่ต้น มันจะไม่เพียงส่งผลกระทบต่อ Productivity เท่านั้น แต่ยังรวมถึง คุณภาพของ Product อีกด้วย
10. Tool Multiplicity & Hardware
Developer ใช้ Tools มากมายในการเขียน Program มีการ Push และ Merge code ของพวกเขาทุกวัน มีการใช้ Automation มากขึ้น เรามักได้ยินคนกล่าวว่า ถ้าคุณใช้ Tools ที่ “เก่าและโบราณ” จะส่งผลกระทบต่อ Productivity ของคุณ ในทำนองเดียวกัน การมี Screen ขนาดใหญ่ กับ มีเพียง laptop เล็กๆ ก็มีผลเช่นกัน เมื่อพิจารณาจากต้นทุนของ Hardware และเงินเดือนของ Developer แล้ว การได้ Productivity กลับมาเพียง 5% ก็คุ้มค่ากับการลงทุนแล้ว เพียงแค่มอบ Tools และ Hardware ที่ทีม Developer ของคุณถนัดตามความเหมาะสม
11. “How” Documentation
ตอนที่เรียนรู้วิธีการเขียน Code เราได้รับคำแนะนำให้ Comment เสียตั้งแต่เนิ่นๆ และบ่อยๆ แนวคิดก็คือ การมี Comment มาก ดีกว่ามี Comment น้อย แต่น่าเสียดายที่ Programmer หลายคนตีความผิดเป็นว่า พวกเขาจะต้อง Comment ทุกบรรทัดของ Code ซึ่งเรามักเห็น Code ลักษณะนี้ (จากโพสต์ของ Jeff Atwood ในหัวข้อ “Coding Without Comments“):
r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}
คุณคิดเห็นอย่างไร ปัญหาคือคุณจะเห็นว่ามี Comment มากมายใน Code นี้ แต่กลับไม่บอกเลยว่า ทำไมถึงทำแบบนี้และเพื่ออะไร หากมี Bug ใน Program คุณจะไม่รู้เลยว่า ควรจะเริ่มต้นอย่างไรตรงไหน
12. Impossibly Tight Deadlines
มีแนวโน้มที่ Manager จะขอให้ Developer ช่วยประเมินระยะเวลาการ Develop จากนั้นก็บีบระยะเวลาลงให้สั้นที่สุดเท่าที่จะทำได้ จากนั้นก็กำหนดเป็น Deadline โดย Manager จะพิจารณาว่า สิ่งที่ Developer ประมาณการมานั้น พวกเขาจะสามารถทำได้ตามกำหนดด้วย ดังนั้น Deadline ควรถูกพิจารณาให้ชัดเจนและเหมาะสมเพียงพอที่จะบอกกับผู้บริหารด้วย และไม่น่าแปลกใจที่ Developer รู้สึกว่า Deadline เหล่านั้น ไม่สมเหตุสมผลและกระชั้นมากเกินไป ซึ่งสิ่งนี้สร้างความตึงเครียด และ Focus การทำงานได้ยาก
นี่เป็นเพียงปัญหาส่วนหนึ่งที่มักเจอกัน หากคุณอยู่ในระดับหัวหน้า ควรหาสาเหตุของปัญหาและแก้ไขมัน แต่หากคุณเป็น Developer ที่ได้รับผลกระทบจากปัญหาเหล่านี้ ก็ลองหาทางแจ้งกับหัวหน้าของคุณ หรือช่วยนำเสนอแนวทางแก้ไขที่เหมาะสมดู เพื่อ Productivity ที่ดีทั้งของตัวคุณเอง ของทีม และของบริษัท
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://hackernoon.com/