ปกติเราเรียนรู้กันมาว่า คำว่า ‘ไม่’ ถือเป็นคำในเชิงลบ (Negative) แต่การเรียนรู้ที่จะพูดมันเพื่อ Focus ว่าสิ่งใดที่สำคัญ มันกลับส่งผลดีต่อชีวิตของเรา โดยเฉพาะอย่างยิ่งถ้าคุณเป็น Programmer ที่อาจต้องสื่อสารพูดคุยกับลูกค้า หรือกับ Team Leader ที่ขอให้คุณ Develop Feature ใหม่ๆ เรามาดูกันว่า ทำไมการเป็น Developer ที่ดี ถึงควรรู้จัก “ปฏิเสธ”
การเป็น Software Developer คุณไม่เพียงต้องเผชิญกับความท้าทายในเรื่องของ Syntax และ Logic เท่านั้น แต่ในหลายโอกาส คุณอาจต้องสื่อสารพูดคุยกับลูกค้าด้วย นี่เป็นสิ่งสำคัญมาก เพราะบางครั้งลูกค้าของคุณจะถามคุณเกี่ยวกับ Feature ซึ่งต้องใช้เวลาพูดคุยกันเป็นเวลานาน แต่มันกลับไม่ได้เพิ่ม Value ให้กับ Product หรือไม่ได้เป็นจุดมุ่งหมายของการทำ Application นั้นเลยด้วยซ้ำ
หากคุณกำลังเผชิญกับสถานการณ์ที่คล้ายคลึงดังที่กล่าวมาข้างต้น คุณมี 2 ทางเลือก
- Develop Feature นั้น
- say “No”
คุณอาจกำลังคิดในใจว่า ทำไมถึงควร say “No” หรือ “ปฏิเสธ” มัน? นั่นมันไม่ใช่สิ่งที่ลูกค้าต้องการเหรอ? นั่นไม่ใช่ Software ของเขาหรอกเหรอ?
คำตอบคือ ใช่ พวกเขาคือลูกค้าของคุณ และนั่นก็เป็น Software ของพวกเขา แต่ประเด็นคือ เรื่องเหล่านั้นมันเกี่ยวข้องกับ “เวลา” และ “งบประมาณ” ด้วยยังไงล่ะ
ลูกค้าของคุณเป็นผู้ที่ลงทุนกับทรัพยากรที่คุณเป็นผู้ตัดสินอย่างแน่นอนแล้ว ว่ามันไม่ได้เพิ่ม Value ให้กับ Product เลย และเมื่อรู้อย่างนั้นแล้ว คุณก็ยังคงทำแบบนั้นต่อไป แล้ว คุณควรจัดการกับสถานการณ์เช่นนี้อย่างไรดี? เรากำลังจะ “ปฏิเสธ” แต่อาจมีการโต้แย้งมาว่า “แล้วทำไมถึงต้องปฏิเสธล่ะ?”
Diego เล่าประสบการณ์ของตนเองว่า จากที่เขาได้เป็น Software Apprentice ที่ Pernix จะมีการ Develop Applications กันราวๆ 6 สัปดาห์ ซึ่ง Applications เหล่านี้จะถูกเรียกว่า MVP (Minimum Viable Products) ซึ่งหากดูจากชื่อที่เรียกกันแล้ว Applications เหล่านี้ ดูจะถูกตั้งใจทำให้เป็น Product ที่เล็กที่สุด แต่มี Feature พิเศษบางอย่างที่ช่วยสร้าง Value ให้กับ Final Product
เวลา 6 สัปดาห์ ถือเป็นช่วงเวลาที่สั้น ทีมงานต้องทำงานอย่างคล่องตัวและ Focus ในสิ่งที่มีความสำคัญมาก บางครั้งลูกค้าต้องการ Feature ที่ต้องใช้เวลานานในการพัฒนา และมันก็ไม่ได้เพิ่ม Value ที่แท้จริงให้กับ Product เลย นี่คือเหตุผลที่ว่า ทำไมเราถึงต้องระบุว่า จุดมุ่งหมายของ Application นั้นคืออะไร และคน Develop ต้องใช้ความพยายามกับ Feature เหล่านั้น
Diego เล่าอีกว่า มีหนึ่งใน Project ที่เขาเคยทำ ลูกค้าถามเรื่องการ Implement ตัว Chatbot ซึ่งน่าจะใช้เวลา 6 สัปดาห์เต็มถ้าบริษัทตกลงที่จะ Develop งานนี้ แต่ Feature หลักของ Project นั้นคือ การพัฒนา CRM ด้วย Social Network Implementation ดังนั้น ทีมงานจึงเสนอ 2 ทางเลือก คือ ลูกค้าจะ Develop Chatbot หรือ CRM แต่ถือเป็นความโชคดีที่ลูกค้าเข้าใจ และตัดสินใจที่จะใช้ Chatbot ในอนาคตแทน และให้ทีมงานของเขาทุ่มเท Develop ใน CRM เป็นหลัก แต่หากบริษัทยอมรับในการ Develop Chatbot ด้วย ทีมงานเองคงไม่สามารถ Develop Chatbot และ CRM พร้อมกันได้ ในที่สุดทีมงานก็ได้ Develop CRM และลูกค้าเองก็รู้สึก Happy กับผลลัพธ์ที่ออกมา แต่จากเหตุการณ์นี้ก็ทำให้บริษัทเองเริ่มที่จะเรียนรู้ในการ Focus ที่ 2 Function หลักและ Develop มันให้มีประสิทธิภาพและรวดเร็วที่สุดเท่าที่จะทำได้
จากวิธีการดังกล่าวข้างต้น ดูเหมือนจะเป็นสิ่งที่คุ้นเคยหากคุณใช้ Scrum ในการ Develop ใน Scrum คุณจะต้องรับหน้าที่ในงานและทำมันให้สำเร็จใน Sprint Period หากคุณพบว่างานของคุณอาจจะใช้เวลานานกว่าที่คุณคิด หรือคุณคิดว่า กำลัง Develop Feature ที่ต่างไปจากเดิมอย่างสิ้นเชิง โปรดระลึกไว้เสมอว่า อะไรคืองาน/หน้าที่ของคุณ จุดมุ่งหมายคืออะไร
สุดท้ายนี้ อยากให้คุณระบุว่า สิ่งใดที่สำคัญสำหรับ Project ของคุณ และจงเรียนรู้ที่จะ “ปฏิเสธ” ใน Feature ที่อาจต้องใช้เวลานานๆ ในการ Develop และไม่เพิ่ม Value ให้กับ Final Product
หวังว่า คนไอทีจะได้ประโยชน์ รวมทั้งนำเทคนิคเหล่านี้ ไปประยุกต์ใช้ในการทำงานและในสถานการณ์จริงได้อย่างเหมาะสมนะครับ
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://medium.com/