บทความ IT เจ๋งๆ

โดยทั่วไปเวลาเกิด Software Project ขึ้นมาใหม่ ล้วนมีการคาดหวังผลลัพธ์เสมอว่าน่าจะออกมาเป็นแบบใด แต่ในความเป็นจริงแล้ว มันไม่ได้ง่ายอย่างที่คิด ยิ่ง Project ใหญ่แค่ไหน โอกาสที่ Project นั้นจะเกิดปัญหายิ่งมากขึ้นตามไปด้วย วันนี้เรามาดูกันว่า 14 สาเหตุที่ทำให้ Software Project ล้มเหลว นั้นมีเรื่องใดบ้าง

1. สมาชิกในทีมน้อยเกินไป

คงไม่น่าแปลกใจสำหรับสาเหตุนี้ เพราะถ้าคนน้อยกว่าปริมาณงานที่ต้องทำ แน่นอนว่าเกิดโอกาสที่ Project จะไม่เสร็จนั้นมีสูง มันค่อนข้างยากที่จะคาดเดาว่าควรมี Programmers กี่คนถึงจะเพียงพอ แม้จะวางแผนและประมาณคนทำงานแล้ว แต่อาจมีปัญหาก็อาจเกิดขึ้นได้เสมอ ซึ่งมันอาจไม่ใช่ความผิดของ Manager ที่งานงอกเพิ่มอีกเท่าตัว

2. สมาชิกในทีมมากเกินไป

บางคนอาจแปลกใจว่า ทำไมมีคนในทีมมากไปจะทำให้ Project ล่มได้ เพราะคนมากขึ้น หมายถึงต้องเน้นการประสานงานรวมทั้งการประชุมที่มากขึ้นซึ่งกินเวลาที่ควรจะเขียน Code ไป การยกเลิกประชุมช่วยให้ Programmer มีเวลาเขียน Code แต่ถ้าคุณประชุมไม่เพียงพอ ก็อาจพบว่า API ของทีม A ไม่ได้เชื่อมโยงกับ Microservices ของ Team B เลย

3. มีการเปลี่ยน Features พื้นฐานไป

นี่ก็เป็นอีกเรื่องที่อาจส่งผลกระทบกับ Project ได้ ถ้าการเปลี่ยนแปลงนั้นเป็นแค่ เช่น ย้ายตำแหน่งของปุ่มหรือเปลี่ยนสีมัน แต่ถ้าการเปลี่ยนแปลงนั้น ต้องมาปรับ Database Schema ใหม่ หรือทำให้ยุ่งยากขึ้นแล้วละก็ แบบนี้ก็อาจทำให้เกิดปัญหาขึ้นได้

4. เลือกเทคโนโลยีที่ไม่ถูกต้องสำหรับงาน

แม้จะวางแผนหรือ List ตัว Features ไว้เรียบร้อยแล้ว แต่ก็อาจเกิดความล้มเหลวได้ถ้าคุณเลือกใช้เทคโนโลยีที่ไม่เหมาะกับ Project ของคุณ อย่างเช่น แม้คุณออกแบบ Database ให้มีความยืดหยุ่นมากที่สุดแล้ว แต่มันดันมีข้อจำกัดทางด้านสถาปัตยกรรม พอใช้จริงก็อาจทำให้ Database ช้าหรืออาจไม่ทำงานโดยเฉพาะเมื่อมันมีขนาดใหญ่ขึ้น เป็นต้น

5. จัดลำดับความสำคัญไม่ดี

คนที่วางแผนงานดี จะมีการเขียน List ของ Features รวมทั้งจัดลำดับความสำคัญไว้ล่วงหน้าแล้ว แต่บางครั้งมันก็ไม่สอดคล้องกับความเป็นจริงเมื่อจะนำไปใช้งาน เป็นไปได้ว่า Feature ที่สำคัญที่สุดอาจเป็นสิ่งที่สร้างยากที่สุด แล้ว Developers ควรทำอย่างไรดีล่ะ ถ้าเริ่มงานที่ Feature สำคัญที่สุดก่อน ก็อาจทำให้ส่งต่องานให้คนอื่นไม่ทัน แต่ถ้าเริ่มงานที่ง่ายก่อนก็อาจได้ผลงานที่ไม่ได้มาตรฐาน การวางแผนที่ดีไม่ใช่แค่ทำ Checklist ซึ่ง Architectural Vision จะต้องคำนึงถึงความต้องการและต้นทุนด้วย

6. ตลาดไม่เปิดกว้างอีกต่อไป

บางครั้งก็ไม่ใช่ความผิดของ Programmer เพราะในระหว่างที่คุณกำลังสร้าง Project มันอาจะเป็นช่วงที่คิดว่าน่าจะไปได้สวย แต่หลังจาก Project เสร็จสิ้น บางทีความต้องการของลูกค้า/ผู้บริโภคอาจเปลี่ยนไปแล้วก็ได้ โดยเฉพาะในยุคนี้ที่อะไรๆ ก็เปลี่ยนแปลงไว

7. การตัดสินใจทางสถาปัตยกรรมที่ไม่ดี

การตัดสินใจทางสถาปัตยกรรม มีอายุการใช้งานตลอดชีพ โดยเฉพาะถ้าคุณมี Ego สูงจัดและคุณไม่สามารถเปลี่ยนมันได้ Project Managers ต้องพร้อมที่จะแจ้งให้คนอื่นทราบ เมื่อ Architectural Plan มันไม่ Work ซึ่งเมื่อนั้นจะต้องมีการตัดสินใจครั้งใหญ่ ถ้าผู้นำไม่สามารถแจ้งหึ้นอื่นทราบได้เมื่อแผนของพวกเขาผิดเพี้ยนไป เหล่า Coder ก็จะไม่มีความพยายามในการสร้างความคืบหน้าให้กับงานที่ดูแล้วเป็นไปไม่ได้ ซึ่งเกิดมาจากการมีรูปแบบสถาปัตยกรรมที่ไม่ดี

8. เกิดความขัดแย้งกันภายในทีม

เมื่อใดที่ความคิดของคนในทีมแตกออกเป็น 2 ฝ่าย มันก็อาจทำให้เกิดปัญหาได้  เช่น ระหว่าง XML และ JSON ต่างฝ่ายก็ล้วนต่างสนับสนุนให้ใช้ในสิ่งที่ตนเองชอบหรือถนัด หากคนกรุ๊ป A ชอบ JSON ส่วนคนกรุ๊ป B ชอบ XML คนในทีมอาจจำเป็นต้อง implement ทั้งคู่ หรือกลุ่มใดกลุ่มหนึ่งอาจต้องเปลี่ยนไปใช้อีกอย่าง ซึ่งแน่นอนว่าต้องมีคนปวดหัวที่ต้องทำงานท่ามกลางทั้ง 2 ฝ่าย

9. ใช้เทคโนโลยีที่ยังไม่พร้อมสำหรับ Production

Programmers Tools Frameworks Programmer Production use Features Code File Database

10. ใช้เทคโนโลยีที่กำลังจะล้าสมัยไปแล้ว

หลายคนอาจมีความเชื่อว่า สิ่งเก่าๆ มีความน่าเชื่อถือและได้รับการทดสอบมาแล้ว ซึ่งมีค่ามากกว่าเทคโนโลโลยีใหม่ๆ แต่นั่นไม่ได้หมายความว่าเทคโนโลยีเก่าๆ จะสมบูรณ์แบบ พวก Features บางอย่างอาจหายไปซึ่งกระทบต่อ Software Project ของคุณ และที่แย่ยิ่งกว่านั้น อาจทำให้คุณพลาดโอกาสในอนาคต เช่น หากมี Idea, Protocols และ File format ใหม่ๆ เกิดขึ้นแล้วดันเกิด implement ไม่ได้ขึ้นมา เมื่อนั้น Project ของคุณจะมีปัญหาตามมาอีก

11. Deadline ที่ไม่สมเหตุสมผล

การกำหนด Deadline ไม่ได้เป็นสิ่งที่ทำได้ง่าย หลาย Projects ก็ต้องทำตาม Season หรือแล้วแต่สถานการณ์ เมื่อ Deadline ถูกกำหนดในครั้งแรก Developers อาจยังไม่รู้สึกว่าอะไรจะเป็นอุปสรรคของพวกเขา แต่เมื่อ Project เสร็จเกินกำหนด มันจะถูกมองว่า Project นั้นล้มเหลวแม้ว่า Code จะทำงานได้ราบรื่นก็ตาม Deadline ช่วยให้ทุกคนโฟกัสและทำให้ทุกคนร่วมกันทำงาน แต่ก็กลายเป็นสร้างความคาดหวังที่ไม่ตรงกับความเป็นจริง

12. เกิดการแข่งขันที่คาดไม่ถึง

Product Manager ที่ดีจะทำการสำรวจว่า มีการแข่งข้นสูงแค่ไหนก่อนจะสร้าง Project อย่างจริงจัง แต่มันก็ยากจะคาดเดาได้ ถ้าคู่แข่งออก Feature ใหม่ที่คุณต้องทำตามละก็ Project คุณก็ดูไม่ค่อยดีนัก

13. การเร่ง Process

หลายๆ Software Project เกิดขึ้นจากวิสัยทัศน์ของคน/ทีมหรือเพื่อแก้ปัญหาบางอย่าง คุณคงเคยได้ยินวลีอย่าง “Snapchat for Y” หรือ “Uber for Y” เป็นต้น ปัญหาคือ การหา Scope ของ Project การคิดมันไม่ยาก แต่เวลาทำจริง อาจไม่ใช่เรื่องง่าย ทั้ง wireframes, database schema และ user stories ไม่ได้ง่ายเหมือนการโบกมือ แต่มันกลับเป็น Part สำคัญของงาน แต่คนส่วนใหญ่มักเชื่อว่า Software Project เป็นเพียงการเขียน Code เพื่อ implement ความคิดเท่านั้น

14. ความเชื่อที่ผิดๆ เกี่ยวกับพลังของ Software

คนช่างฝันบางคนเชื่อว่าพลังของ Software จะช่วยเปลี่ยนแปลงโลกได้ หลายๆ Software Project เริ่มต้นด้วยความสวยงามโดยมั่งมั่นว่าจะเปลี่ยนแปลงบางสิ่งและปฏิวัติบางส่วนของโลกใบนี้ แต่หากไม่สามารถบันทึกข้อมูลลง Database ได้ ผู้คนก็จะโกรธ เบื่อ สับสนหรือรู้สึกแย่ จากนั้นพวกเขาก็บอกว่า Software นี้มีปัญหา มันไม่สำคัญว่า Database จะทำงานได้อย่างราบรื่นและ Application จัดเก็บข้อมูลไว้ในตำแหน่งที่ถูกต้องหรือไม่ แต่ประเด็นคือ Software ไม่สามารถแสดงให้เห็นถึงการเปลี่ยนแปลงที่น่าอัศจรรย์ตามที่ทุกคนคาดหวังไว้ต่างหาก

ที่มา:  https://www.cio.com/

รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert

อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ

บทความที่เกี่ยวข้อง

• Top 5 Python Distributions สำหรับ Machine Learning
• Functional Programming มี ข้อดี-ข้อเสีย อะไรบ้าง
• 10 API Testing Tools ที่ดีที่สุด