See the original English version of this article here
เชื่อว่าในการทำงาน ย่อมมีเรื่องที่เราอาจไม่เคยรู้ ไม่เคยทำ และเกิดความไม่เข้าใจบ้าง ไม่เว้นแม้แต่ในสายงาน Programming แต่เมื่อต้องเจอปัญหา คุณจะทำอย่างไร วันนี้ทีมงานมีบทความที่จะช่วยลดปัญหาเรื่องความไม่เข้าใจในงานสาย Programming ซึ่งจะช่วยให้คุณเข้าใจ เพิ่มทักษะ/ความรู้มากยิ่งขึ้น รวมทั้งลดช่วงว่างระหว่าง Requirements ที่คุณต้องจัดการกับความรู้ที่ต้องใช้เพื่อทำให้งาน(Task)สำเร็จ โดยบทความนี้เขียนขึ้นโดย Justin Fuller
เกี่ยวกับ ‘Requirements’
ในที่นี้ขอใช้คำว่า Requirements ซึ่งความหมายของมันก็ขึ้นอยู่กับสถานที่ที่คุณทำงานอยู่ จากประสบการณ์ของ Justin พบว่า หากเป็นบริษัทใหญ่ๆ มักชอบการใช้ Requirement แต่บริษัทเล็กๆ จะไม่มีการทำ Requirements แต่ในฐานะของ Software Engineer ถึงอย่างไรก็มีหน้าที่ “แก้ไขปัญหา” อยู่ดี และเมื่อคุณได้รับงานมาแล้ว คุณต้องแน่ใจว่าคุณเข้าใจปัญหานั้นจริงๆ เพื่อจะได้แก้ไขปัญหาได้อย่างถูกต้อง
เกี่ยวกับขั้นตอนต่างๆ
อันที่จริงคุณอาจไม่จำเป็นต้องทำตามในทุกขั้นตอนที่กำลังจะบอกนี้ก็ได้ อาจใช้เฉพาะกับปัญหาที่ยากในการทำความเข้าใจ ซึ่งต้องใช้ความละเอียดและระมัดระวังสูงเท่านั้นพอ มีหลายๆ คำถามที่ได้จาก Requirements ที่คุณเองอาจไม่สามารถตอบได้ คุณอาจต้องถาม Developer คนอื่น, Team Lead, Product Owner, Business Analyst หรือใครก็ตามที่น่าจะเกี่ยวข้อง นั่นหมายถึงคุณจะได้รับความรู้มากมายเข้ามาในตัวคุณเอง ซึ่งตอนนี้คุณจะสามารถหาทำตอบที่เป็นไปได้มากที่สุดแล้ว และอย่าลืมว่า ไม่ต้องทำตามขั้นตอนนี้เป๊ะๆ ก็ได้ เป้าหมายของบทความแค่อยากช่วยให้คุณแก้ไขปัญหาให้รวดเร็วขึ้นเท่านั้น อย่าทำให้มันกลายเป็นอุปสรรคโดยไม่จำเป็น คุณควรวางแผนอย่างเนระบบเพื่อจะได้แก้ไขปัญหาที่เจอได้ดีและเร็วขึ้น
ขั้นตอนที่ 1 : วิเคราะห์งานที่ได้รับมา
คุณต้องทำความเข้าใจก่อนว่า คุณถูกร้องขอให้ทำอะไร หากคุณข้ามขั้นตอนนี้ อาจลงเอยด้วยผลลัพธ์ที่ผิดพลาดได้
1.1 จัดกลุ่มของงาน
การจัดกลุ่มของงาน หมายถึง การกำหนดประเภทงานที่คุณจะต้องแก้ไขปัญหานี้ ซึ่งตัวอย่างของประเภทงานที่ว่า ก็เช่น
-
- แก้ไข Bug
- Feature ใหม่
- Application ใหม่
- วิจัย Assignment
- การปรับปรุง Performance
- และอื่นๆ อีกมากมาย
เป้าหมายสำคัญของขั้นตอนนี้คือ การกำหนดประเภทของงานที่คุณคาดว่าจะต้องทำ ซึ่งสิ่งสำคัญเนื่องจากมีผลโดยตรงกับงานอะไรก็ตามที่คุณต้องทำ
1.2 สรุปงานที่ต้องทำเป็น 1-2 หัวข้อใหญ่ๆ
ขั้นตอนนี้เป็นการสรุป Requirements ที่อาจมีความซับซ้อนคลุมเครือให้ออกมาเป็น สิ่งที่คุณสามารถเข้าใจได้ง่ายขึ้นว่ามันคืออะไร และต้องทำอะไรกับมัน แต่หากคุณไม่สามารถสรุปออกมาได้ นั้นหมายถึง คุณอาจต้องแบ่งมันออกเป็นงานย่อยๆ ที่มีขนาดเล็กลง ซึ่งทำให้คุณต้องแกปัญหามากขึ้น (โดยไม่จำเป็น)
1.3 วางโครงร่างในงานหลักๆ
คุณสามารถใช้รูปแบบใดก็ได้ที่คุณเข้าใจมากที่สุด ในการสร้าง List ของ ส่วนที่สำคัญๆ ที่คุณต้องทำ ซึ่งสิ่งเหล่านี้ควรเป็นบทสรุปที่เรียบง่ายของเรื่องนั้นๆ ยังไม่ต้องลงลึกถึงรายละเอียดว่าจะแก้ไขมันอย่างไร จากตัวอย่างเรื่อง New Feature :“User แต่ละรายจะได้เห็นโฆษณาเกี่ยวกับ Product ของบริษัท และโฆษณานี้ควรได้รับการออกแบบมาเพื่อตอบสนองความต้องการของแต่ละบุคคลโดยพิจารณาจากข้อมูลที่เราเคยเก็บรวบรวมไว้” จาก Requirements ข้างต้น เราสามารถวางโครงร่างในงานหลักๆ ที่ต้องทำดังนี้
-
- โฆษณาปัจจุบันของเรา จะต้องถูกแบ่งย่อยเพื่อให้สอดคล้องกับ User
- จะต้องมีวิธีเพื่อให้ทีม Marketing สามารถจับคู่ระหว่างโฆษณาใหม่ กับกลุ่มของ User (โดยไม่ต้องเขียนโค้ด!)
- ระบบจะต้องรวบรวมข้อมูล User ที่สัมพันธ์กับโฆษณาของเรา
- สุดท้ายควรต้องสร้างระบบอะไรสักอย่างที่ไว้รับ User ID และแสดงผลโฆษณา
หลังจากสร้าง List งานที่ต้องทำแล้วอาจจะคุยกับทีมหรือหัวหน้าของคุณอีกครั้ง และจาก List ในตัวอย่าง เราอาจต้องมีงานเพิ่มอีกอย่าง คือ
-
- User ควรสามารถบอกเราได้ หากไม่ต้องการเห็นโฆษณาใดๆ อีกแล้ว
1.4 ระบุปัญหาที่คุณต้องแก้ไขให้ชัดเจน
ลองตอบคำถามเหล่านี้ เช่น “ทำไมผู้คนถึงควรใช้สิ่งนี้?” หรือ “ปัญหาอะไรที่เรากำลังแก้ไขอยู่?” เป็นต้น คำตอบของคุณควรจะชัดเจน แต่หากไม่ชัดเจน ก็อาจถึงเวลาที่ต้องถามใครสักคนว่า “ทำไมคุณถึงงานชิ้นนี้?” การถามคำถามแบบนี้จะนำไปสู่ความเข้าใจที่ชัดเจนของงานที่คุณกำลังทำอยู่หรือนำไปสู่การคิดใหม่ว่า “อะไรที่คุณถูกขอให้ทำ” ความเข้าใจที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับปัญหาและจุดประสงค์ จะช่วยให้คุณสามารถตัดสินใจในการ Implement ของคุณเพื่อให้บรรลุเป้าหมายทางธุรกิจได้จริง
ขั้นตอนที่ 2 : ตีความและประเมินผล
ขั้นตอนถัดไป คือการทำความเข้าใจรายละเอียดของสิ่งที่คุณกำลังทำ สิ่งที่คุณคาดหวังว่าจะทำ และเหตุผลที่คุณทำเช่นนั้น
2.1 ระบุคำเฉพาะที่เกี่ยวข้องกับงานที่ทำให้ชัดเจน
หากคุณเป็นมือใหม่ คุณอาจไม่คุ้นเคยกับ คำเฉพาะ บางอย่างที่บริษัทใช้กัน เช่น ชื่อของ Product/ Customer/ Process เป็นต้น นอกจากนี้ยังมี ชื่อของ Tools/ Applications/ Models/ Services หรือ Libraries อีกด้วย คุณต้องแน่ใจว่าได้เข้าใจคำเฉพาะที่สำคัญทั้งหมดโดยไม่มีความคลุมเครือใด ๆ เพื่อให้มั่นใจได้ว่า คุณกำลัง Implement งานอย่างถูกต้อง มิเช่นนั้น คุณอาจ Implement งานผิดพลาดและส่งผลกระทบต่องานโดยรวมได้
2.2 ระบุว่าควรทำงานนั้นอย่างไร
ในขั้นตอนนี้ มันก็แตกต่างกันไปตามหน้าที่ความรับผิดชอบของแต่ละคน หากทีมของคุณไม่ได้ให้คำแนะนำแก่คุณ คุณอาจไม่สามารถทำอะไรได้มากในขั้นตอนนี้ แต่หากคุณได้รับคำแนะนำแล้วเมื่อถึงจุดนี้คุณจะต้องเริ่มทำความคุ้นเคยกับขั้นตอนที่คุณต้องใช้ ซึ่งขั้นตอนนี้ค่อนข้างชัดเจน และคุณควรใส่ใจคำสิ่งที่ต้องทำเป็นพิเศษ เมื่อคุณใช้เวลาในการทำความเข้าใจกับงานของคุณแล้ว ตอนนี้คุณจะมีเป้าหมายที่ชัดเจนขึ้นในการประเมินขั้นตอนที่คุณต้องทำ
2.3 ตรวจสอบว่าปัญหาได้รับการแก้ไขแล้วหรือไม่
ในขั้นนี้เราจะรวม การวิเคราะห์และการตีความเข้าด้วยกัน ในขั้นตอนการวิเคราะห์ คุณมุ่งเน้นไปที่เป้าหมายในภาพรวมและผลลัพธ์ (What & Why) ส่วนในขั้นตอนการตีความ คุณเน้นไปที่รายละเอียดของวิธีการ (How) สาเหตุที่เรียกขั้นตอนนี้ว่าการตีความและประเมินผลก็เพราะคุณสามารถเปรียบเทียบวิธีการว่าสัมพันธืกับเป้าหมายและผลลัพธ์หรือไม่ คุณตีความรายละเอียดโดยการพิจารณาในภาพรวม และประเมินรายละเอียดแล้วดูว่าปัญหาที่เกิดในตอนต้น ได้รับการแก้ไขแล้วหรือไม่ ถ้าคุณรู้สึกมั่นใจว่า ปัญหาทั้งหมดจะได้รับการแก้ไขและรายละเอียดทั้งหมดมันสมเหตุสมผล ตอนนี้คุณก็พร้อมที่จะเริ่มต้นทำงานของคุณแล้ว มิเช่นนั้นคุณต้องไปสู่ขั้นตอนที่ 3 เพื่อแก้ไข Conflicts ที่เกิดขึ้น
ขั้นตอนที่ 3 : การคิดวิเคราะห์
ในขั้นตอนนี้คุณควรจะมั่นใจได้ว่าคุณเข้าใจปัญหาและแนวทางแก้ไขปัญหาแล้ว ในขั้นตอนสุดท้ายนี้ เป็นการทำให้แน่ใจว่าคุณมีทางออกที่เหมาะสม เพื่อที่จะสร้าง Product ที่ดีที่สุด เราทุกคนควรมีหน้าที่รับผิดชอบในการพูดเมื่อเห็นว่ามีบางสิ่งที่ไม่เหมาะสม และอย่าพูดแค่เพราะรู้สึก ควรมีเหตุผลประกอบด้วย และหากคุณจะบอกใครว่า “ไม่เห็นด้วย” มันก็มีหลักการอยู่ 2 ข้อดังนี้
3.1 รู้ว่าเมื่อไรที่จะบอกว่า “ไม่เห็นด้วย”
-
- อย่าเพิ่งบอกว่า ไม่เห็นด้วย หากคุณยังไม่เข้าใจปัญหาอย่างแท้จริง
- อย่าบอกว่า ไม่เห็นด้วย เพราะความคิดเห็นส่วนตัว ควรโฟกัสปัญหาที่เกิดขึ้นจริงเป็นหลัก
- มีเหตุผลที่ดีเพื่อสนับสนุนว่า ทำไมคุณถึง ไม่เห็นด้วย และพร้อมที่จะอธิบาย
3.2 รู้วิธีการที่จะบอกว่า “ไม่เห็นด้วย”
เพื่อให้แน่ใจว่า สิ่งที่เราไม่เห็นด้วยนั้น เป็นสิ่งที่ถูกต้อง คุณสามารถใช้วิธีการเหล่านี้ ในการแสดงออกไปว่า ไม่เห็นด้วย:
-
- แสดงให้เห็นว่า Solution นั้น ไม่มีข้อมูลมากเพียงพอ
- แสดงให้เห็นว่า Solution นั้น มีข้อมูลที่ผิดพลาด
- แสดงให้เห็นว่า ปัญหา หรือ Solution นั้น ไม่สมเหตุสมผล
- แสดงให้เห็นว่า Solution นั้น ยังไม่สมบูรณ์
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.freecodecamp.org/