แชร์เรื่องนี้
การวางแผนโปรเจกต์พัฒนาซอฟต์แวร์สำหรับปี 2023
โดย Seven Peaks เมื่อ 22 เม.ย. 2022, 10:52:00
10 ขั้นตอนง่ายๆ ที่จะช่วยให้คุณดำเนินการพัฒนาโปรเจกต์ได้จนสำเร็จลุล่วง
เราถามคุณมาร์ค ผู้ซึ่งเป็น Lead Scrum Master ของ Seven Peaks Software ว่า จากประสบการณ์ที่ผ่านมาของเขา สิ่งสำคัญในการทำโปรเจกต์พัฒนาซอฟต์แวร์ให้ประสบความสำเร็จมีอะไรบ้าง แต่ก่อนอื่นขอทำความเข้าใจกับผู้อ่านว่าข้อมูลในบทความนี้อาจไม่เป็นกลางนัก เนื่องจากเป็นการรวบรวมจากประสบการณ์ส่วนตัว เพราะหลักการทำงานแบบ Agile นั้นเน้นที่การส่งมอบคุณค่าที่ดีที่สุดให้กับผู้ใช้เสมอ (ไม่ใช่ลูกค้า) สำหรับชาว Agile แล้ว เราแนะนำให้คุณทำตาม 10 วิธีต่อไปนี้ |
1) ความโปร่งใส
ทุกคน (รวมถึงลูกค้า) จะต้องรู้ว่าแต่ละคนกำลังทำอะไรอยู่ตลอดเวลา ซึ่งปกติแล้วข้อมูลเหล่านี้จะไม่เปิดเผยในการทำงานกับลูกค้าแบบ Waterfall
2) การตรวจสอบ
เมื่อจบแต่ละ sprint แล้ว เราจะตรวจสอบว่าทำ task ไหนเสร็จไปแล้วบ้าง และมองหาวิธีที่จะปรับปรุงกระบวนการทำงาน จากนั้นเราจึงกำหนดตัวชี้วัดเพื่อประเมินประสิทธิผลในการทำงาน
3) การปรับตัว
จากการตรวจสอบแต่ละครั้ง เราจะนำกระบวนการใหม่ๆ (ในทุกรูปแบบการใช้งาน) มาจัดกลุ่ม ถ้าอันไหนใช้งานได้ดี เราก็เก็บไว้ อันไหนใช้ไม่ได้ เราก็ทิ้งมันไป และลองอย่างอื่นแทนใน sprint ต่อไป
4) ลูกค้าโปรเจกต์ Agile
แน่นอนว่าลูกค้าต้องทำความเข้าใจว่าต้องมีการปรับเปลี่ยนบางอย่างเพื่อเข้าสู่การทำงานแบบ Agile หรือถ้าจะให้ดีที่สุดคือ ลูกค้าทำงานแบบ Agile เองด้วย ไม่อย่างนั้นโปรเจกต์ก็จะรันไปได้ไม่นานและล้มเหลวในที่สุด หรืออาจจะเริ่มโปรเจกต์ในแบบ Waterfall แต่สุดท้ายก็แทบจะสู้คู่แข่งไม่ได้เลย
ในการทำงานแบบ Agile นั้น เราไม่ได้ตั้งเป้าให้งานออกมาสมบูรณ์แบบ (แม้ว่าความสมบูรณ์แบบของแต่ละคนจะไม่เหมือนกันก็ตาม) แต่เน้นให้งานออกมาดีพอในเวลาที่รวดเร็วที่สุดเท่าที่จะเป็นไปได้
5) บริษัทที่ทำงานแบบ Agile
นอกจากนั้น บริษัทผู้พัฒนาซอฟต์แวร์เองก็ต้องเข้าใจและสนับสนุนการทำงานแบบ Agile ด้วย
ในตอนแรก บริษัทอาจจะมีขนาดเล็กเกินไปที่จะเลือกลูกค้าและมุ่งเน้นไปที่การทำงานแบบ Waterfall หลังจากนั้น พวกเขาก็ปรับตัวให้มีความ Agile มากขึ้น จึงสามารถหาทางขายโปรเจกต์ Agile มากขึ้นได้ โดยที่เก็บระบบ Waterfall ไว้ใช้กับโปรเจกต์ที่เน้นความสำคัญในการทำภารกิจจริงๆ เท่านั้น
6) ความไว้ใจ
เราเชื่อว่าทุกคนมีความเป็นมืออาชีพและจะทำงานตาม task ที่ได้รับการฝึกฝนมาอย่างมีประสิทธิภาพ เมื่อใดที่ผมต้องการให้ developer ประเมินงาน ทั้งผมและลูกค้าจะเชื่อใจในข้อมูลที่พวกเขามอบให้
ในขณะที่ภายใต้การทำงานแบบ Waterfall นั้น ถ้า developer ระบุว่างานไหนต้องใช้เวลาสองเดือน คนที่เป็น PM มักจะเพิ่มหรือลดเวลาที่ประเมินมา ขึ้นอยู่กับสภาพคล่องทางการเงินของบริษัท
7) คุณภาพ
เราจะไม่มีวันยอมลดคุณภาพงานเมื่อต้องเพิ่มฟีเจอร์เด็ดขาด เพราะว่าซอฟต์แวร์นั้นมีโอกาสที่จะเกิดบั๊กได้ และเราไม่ต้องการใช้วิธีลัด
8) Product owner ที่มีความสามารถ
Product owner คือคนที่เป็นศูนย์กลางของโปรเจกต์แบบ Scrum ซึ่งตำแหน่งนี้เป็นสิ่งที่ค่อนข้างใหม่ เพราะมีอายุประมาณ 20 ปี เท่านั้น และ product owner เก่งๆ นั้นเป็นบุคคลที่ขาดแคลนและทุกองค์กรต่างต้องการตัวเป็นอย่างมาก
หลายๆ บริษัทกำหนดความรับผิดชอบของ product owner เหมือนกับ PM ซึ่งเป็นสิ่งที่ไม่ถูกต้อง เพราะว่า PM เป็น product owner ที่แย่ที่สุดเนื่องจากผ่านการฝึกฝนเบื้องต้นมาด้วยการเป็นผู้จัดการในระบบ Waterfall พวกเขาไม่สามารถทิ้งความเคยชินเดิมๆ ได้ PO ที่ดีจึงเปรียบเสมือนยูนิคอร์น และเป็นเรื่องธรรมดาที่ PO เก่งๆ จะได้เงินเดือนมากกว่าหมอ
9) Scrum developer
Developer ที่มีประสบการณ์ในการทำงานแบบ Scrum นั้นหายาก และเมื่อหาเจอแล้ว ก็ไม่ค่อยอยู่ที่ไหนนานๆ เนื่องจากเป็นที่ต้องการสูงมาก
10) การมีส่วนร่วมและพัฒนาอย่างต่อเนื่อง
ในการทำงานแบบ Scrum เราจะไม่โยนงานให้กันและสนับสนุนให้ทุกคนทำงานไปพร้อมๆ กัน
องค์กรต้องทำงานให้เร็วขึ้นและส่งมอบคุณค่าให้ลูกค้ามากขึ้นในปี 2023 นี้ การพัฒนาผลิตภัณฑ์ในแบบ Agile นั้นจะช่วยให้การส่งมอบงานรวดเร็วขึ้นและเพิ่มความพึงพอใจของลูกค้าได้อย่างต่อเนื่อง
แนะนำวิธีการสร้างแผนพัฒนาซอฟต์แวร์ที่มีประสิทธิภาพและนำมาปรับใช้
รวบรวม requirement ที่มีความเฉพาะเจาะจง
การรวบรวม requirement คือหลักสำคัญของทุกโปรเจกต์พัฒนาซอฟต์แวร์ ซึ่ง requirement เหล่านี้เป็นรายการพร้อมคำอธิบายที่เต็มไปด้วยรายละเอียดว่าโปรแกรมจะทำอะไรได้บ้าง
Requirement ที่ระบุมาอย่างชัดเจนอาจถือได้ว่าเป็นหนึ่งในสิ่งสำคัญที่สุดในการเขียนแผนโปรเจกต์พัฒนาซอฟต์แวร์เลยก็ว่าได้ ซอฟต์แวร์ที่ไม่สามารถทำให้ลูกค้าพอใจได้หรือไม่เหมาะกับกระบวนการทำงานของพวกเขา คือผลพวงจากการบริหารจัดการ requirement ที่ขาดความเข้าใจ
Requirement แบ่งออกเป็น 2 ประเภท ได้แก่ พวกที่เกี่ยวกับฟังก์ชัน และพวกที่ไม่เกี่ยวกับฟังก์ชัน
-
พวกที่เกี่ยวกับฟังก์ชัน ได้แก่ การรายงานผล, การโต้ตอบกับผู้ใช้, การลงชื่อเข้าใช้ เป็นต้น
-
พวกที่ไม่เกี่ยวกับฟังก์ชัน ได้แก่ ความปลอดภัย, โครงสร้างฐานข้อมูล และ requirement เกี่ยวกับพื้นที่เก็บข้อมูล เป็นต้น
สิ่งเหล่านี้ควรจะทำโดยการปรึกษากับลูกค้าอย่างเต็มที่ นั่นคือสาเหตุว่าทำไมโปรแกรมถึงเกี่ยวข้องกับโฟลว์ในการดำเนินธุรกิจ ทุกขั้นตอนการทำงานต้องมีการระบุให้ชัดเจนและบันทึกเอาไว้เป็นลายลักษณ์อักษร
การวางแผน
โปรเจกต์แบบ Agile นั้นเริ่มขึ้นด้วยการวางแผนก่อนเริ่มงาน โดยจะเริ่มด้วยวิสัยทัศน์และโรดแม็ปที่วางโครงสร้างของฟีเจอร์ไว้กว้างๆ ยกตัวอย่างเช่น ผู้ใช้สามารถลงชื่อเข้าใช้ด้วย social login ได้, สามารถชำระเงินด้วย Visa ได้, ถ่ายรูปได้, สแกนคิวอาร์โค้ดได้ เป็นต้น โดยไม่ต้องระบุรายละเอียดใดๆ รวมถึงบอกเหตุผลทางธุรกิจว่ามีอะไรบ้าง
วางแผนสำหรับการ release และ iteration บริษัทสามารถตัดสินใจได้ว่าจะ release แต่ละ iteration ให้ลูกค้าทีละอันหรือว่าจัดรวมเป็นกลุ่ม การวางแผนสำหรับ release สามารถทำได้ทันทีหลังจากสร้าง product backlog แล้ว หรือหลังจาก iteration แรกเสร็จแล้วก็ได้
- การทำแบบนี้ทำให้เรามั่นใจได้ว่าแต่ละ iteration สามารถเสร็จได้ทันเวลาตามที่ระบุไว้ใน product backlog จากนั้นก็สามารถมอบหมายงานในการทำ iteration หรือ release ต่างๆ ตาม backlog
- ทุกๆ release จะต้องส่งมอบผลิตภัณฑ์ที่ใช้งานได้
- วันที่สำหรับการ release แต่ละครั้งรวมถึง release ของผลิตภัณฑ์เวอร์ชันเสร็จสมบูรณ์นั้นสามารถกำหนดได้ด้วย release plan (ตามเวลาที่มี)
- ค่าใช้จ่ายทั้งหมดของโปรเจกต์จะกำหนดโดยจำนวนของ iteration และค่าแรงของทีมงาน Agile เป็นหลัก ส่วนค่าดำเนินการและอุปกรณ์ที่ต้องใช้ก็ต้องนำไปคำนวณด้วยเช่นกัน
การวางแผนโปรเจกต์ Agile นั้นจะให้ความสำคัญกับ iteration ครั้งต่อไปเป็นหลัก
หลังจากเสร็จแต่ละ iteration แล้ว ทีมงานของโปรเจกต์ก็จะวางแผนสำหรับเนื้อหาของ iteration ครั้งต่อไปใน iteration backlog จากนั้นทีมงานจะยืนยัน product backlog และลำดับความสำคัญของรายการฟีเจอร์ที่เตรียมไว้ในตอนเริ่มประชุม
การจัดลำดับความสำคัญใหม่อาจเกิดขึ้นเมื่อทีมงานรู้สึกไม่แน่ใจว่าลำดับของฟีเจอร์ใน product backlog นั้นเหมาะสมหรือไม่ โดยทีมพัฒนาจะเลือกฟีเจอร์จาก product backlog ที่พวกเขาเชื่อว่าจะสามารถทำเสร็จได้ทันก่อน iteration ครั้งต่อไป
จากนั้นทีมงานจะตัดสินใจเลือกเรียงลำดับ task ว่าอันไหนทำก่อนหลัง, กำหนดว่าใครต้องทำ task ไหน, และประเมินว่าแต่ละ task ใช้เวลานานแค่ไหน ทีมงานอาจจะพบว่าต้องใช้เวลาในการทำแต่ละฟีเจอร์นานเกินกำหนดสำหรับ iteration นั้นๆ ดังนั้น ฟีเจอร์ดังกล่าวก็อาจจะถูกเอาออกหรือเพิ่มเติมเข้าไปก็ได้ การนำฟังก์ชันใดๆ กลับเข้ามาใน product backlog อาจทำให้ต้องมีการจัดเรียงลำดับความสำคัญใหม่
การสื่อสารภายในทีม
แผนของโปรเจกต์พัฒนาซอฟต์แวร์นั้นต้องใช้การสื่อสารที่มีประสิทธิภาพ ซึ่งมีความจำเป็นอย่างยิ่งในช่วงเริ่มต้นโปรเจกต์
ลูกค้าควรจะสื่อสารให้ชัดเจนว่า requirement ของผลิตภัณฑ์มีอะไรบ้าง และมีวิสัยทัศน์อย่างไร ข้อมูลที่ได้รับมาจะทำให้มั่นใจได้ว่าทีมพัฒนาสามารถสร้างสิ่งที่ลูกค้าต้องการจริงๆ การกำหนดอย่างชัดเจนว่าขอบเขตการทำงานเป็นอย่างไรจะช่วยให้ทุกคนเข้าใจตรงกัน การสื่อสารที่ชัดเจนจะช่วยเพิ่มโอกาสสำเร็จให้กับโปรเจกต์พัฒนาซอฟต์แวร์ได้
การเห็นพ้องต้องกันอย่างชัดเจนและต่อเนื่องจะช่วยหลีกเลี่ยงความสับสน ความล่าช้า และข้อผิดพลาดในโปรเจกต์พัฒนาซอฟต์แวร์ได้
การสื่อสารมีความสำคัญมากในทุกขั้นตอนของโปรเจกต์ ควรมีช่องทางสื่อสารโดยเฉพาะสำหรับการทำความเข้าใจปัญหา, ความสำเร็จ, และความคืบหน้าของโปรเจกต์ ตัวอย่างช่องทางที่ควรนำมาใช้กับทีม ได้แก่ Slack, Skype, และอีเมล เป็นต้น
ทีมงาน
ขนาดของทีม
ถือว่าเป็นปัจจัยสำคัญในการสร้างสรรค์ผลงานของทีม ดังนั้นจึงเป็นสิ่งที่ต้องพิจารณาตั้งแต่เนิ่นๆ เพราะว่าขนาดของทีมจะถูกกำหนดโดยความซับซ้อนของโปรเจกต์ งบประมาณ ทรัพยากร และเดดไลน์
บทบาทและหน้าที่
การกำหนดบทบาทและหน้าที่ของแต่ละคนหรือกลุ่มต่างๆ อย่างชัดเจนจะช่วยให้สร้างผลงานได้ดีและเพิ่มความโปร่งใสภายในทีมได้ ก่อนที่จะลงมือทำอะไร ควรรู้ก่อนว่าในแต่ละสถานการณ์ต้องเรียกใช้ใคร หากลูกค้ามีคนให้ติดต่อหลายคน ก็ควรรู้ว่าใครรับผิดชอบเรื่องอะไรบ้าง อย่างไรก็ตาม การสร้างทีมขึ้นมาก็ขึ้นอยู่กับเป้าหมายของกระบวนการพัฒนาซอฟต์แวร์ของคุณ
จ้างคนที่เหมาะสม
ในท้ายที่สุดแล้ว คุณภาพของทีมพัฒนาซอฟต์แวร์ที่คุณสร้างขึ้นมาคือสิ่งที่จะกำหนดความสำเร็จของโปรเจกต์ การเลือกคนที่เหมาะสมมาเข้าร่วมทีมจะเพิ่มโอกาสในการหาพาร์ตเนอร์ในฝันของคุณเจอ และช่วยให้วิสัยทัศน์ของคุณเป็นจริงได้
การสร้างทีม developer ที่มีความสามารถและให้ความร่วมมือต่อกันนั้นจำเป็นต้องมีกลยุทธ์ในการจ้างงานที่วางไว้อย่างดี เมื่อต้องสัมภาษณ์ผู้สมัคร ให้พิจารณาบุคลิกของพวกเขาอย่างละเอียด รวมถึงความเหมาะสมกับวัฒนธรรมขององค์กรคุณด้วย ซึ่งควรมีคุณสมบัติต่อไปนี้
มีทัศนคติที่ดี – ไม่มีอะไรจะดีไปกว่าการทำงานร่วมกับคนที่ตื่นเต้นกับการร่วมงานกับคนอื่นๆ และสร้างผลงานอันยอดเยี่ยมอยู่เสมอ พร้อมมีความคิดสร้างสรรค์และความคิดริเริ่มเป็นเลิศอีกแล้ว ทัศนคติที่ดีในการทำงานจะช่วยเพิ่มผลลัพธ์ที่ดี รวมถึงความสำคัญระหว่างเพื่อนร่วมงานก็ดีไปด้วย ช่วยลดความขัดแย้งภายในทีมได้
ทีมเวิร์กเยี่ยม – ประสิทธิภาพของการพัฒนาซอฟต์แวร์นั้นขึ้นอยู่กับความยอดเยี่ยมในการสื่อสารและความสามัคคีในการทำงานระหว่างสมาชิกในทีม การแบ่งปันประสบการณ์และรับฟังความคิดเห็นจากเพื่อนร่วมงานนั้นจำเป็นต้องมีทักษะการสื่อสารที่ดี รวมถึงทักษะทางด้านเทคโนโลยีที่ยอดเยี่ยม
กระตือรือร้นที่จะเรียนรู้และปรับตัว – developer ที่มีความสามารถรอบด้านนั้นมักจะมองหาเทคโนโลยีหรือโอกาสใหม่ๆ เพื่อเพิ่มพูนทักษะของตัวเองอยู่เสมอ พวกเขาจำเป็นอย่างยิ่งที่จะต้องปรับตัวให้เข้ากับวัฒนธรรมองค์กรและสภาพแวดล้อมในการทำงานได้อย่างรวดเร็ว
การออกแบบและวาง prototype
Product requirement ที่ทีมงานได้รับมาตั้งแต่ตอนเริ่มขั้นตอนการออกแบบอาจเปลี่ยนแปลงได้ในระหว่างการพัฒนา ควรใช้แนวทางที่ประหยัดต้นทุนด้วยการหาไอเดียในการออกแบบจากลูกค้าตั้งแต่เนิ่นๆ ทำการออกแบบและทดสอบดีไซน์ซ้ำๆ เพื่อหาว่าสิ่งที่ผู้ใช้ต้องการคืออะไร จัดลำดับความสำคัญของผู้ใช้ และให้ผู้ใช้ได้ทดสอบไอเดียใหม่ๆ ของคุณด้วย การมีกรอบเวลาที่สั้นลงก่อน release จะช่วยให้ทีมงานโฟกัสกับงานได้ดีในระหว่างที่ทำงานแบบ Agile
นี่คือ 7 หลักการพื้นฐานสำหรับการนำกระบวนการออกแบบผลิตภัณฑ์แบบ Agile มาปรับใช้
ผู้บริหารพร้อมช่วยเหลือ UX designer
มีบางอย่างที่ผู้บริหารที่ให้ความสำคัญกับ UX design สามารถทำได้
-
ให้ UX designer มาร่วมวางแผนงานของโปรเจกต์ตั้งแต่เนิ่นๆ และรับฟังความคิดเห็นของพวกเขา
-
อาจมี request ที่ไม่คาดคิดน้อยลง เพราะการขาดการวางแผน backlog อาจส่งผลต่อการวางแผน sprint และประสิทธิภาพของทีมได้ในที่สุด การบริหารจัดการแบบ Agile นั้นจะพยายามไม่ไปยุ่งเกี่ยวกับแผนงานที่วางเอาไว้อย่างดีแล้ว
-
ช่วยให้มีเวลาในการทำ user research และทดสอบ
เพราะผู้บริหารเหล่านี้เชื่อว่าการทำ user research ที่ดีจะนำไปสู่ผลิตภัณฑ์ที่ดีกว่าภายใต้เวลาและทรัพยากรที่มี
ทีมงานต้องมีหลายฝ่ายทำงานร่วมกัน
Designer จะทำงานร่วมกับสมาชิกคนอื่นๆ ในทีม เช่น developer และ นักการตลาด เป็นต้น ซึ่งจะช่วยทำให้เกิดทีมเวิร์กและความรู้สึกเป็นเจ้าของงาน
Product backlog และการวางแผนที่ดีคือสิ่งที่ขาดไม่ได้
Product backlog จะมีรายการฟีเจอร์ที่ทีมงานหวังว่าจะนำไปใส่ในผลิตภัณฑ์เวอร์ชันที่เสร็จสมบูรณ์ได้ designer ที่ออกแบบผลิตภัณฑ์ในแบบ Agile จะลำดับความสำคัญของงานใน backlog อย่างระมัดระวัง ซึ่ง task ทั้งหมดจะต้องสร้างคุณค่าให้กับผู้ใช้ โดยแต่ละ task สามารถใช้เครื่องมืออย่าง user persona และ empathy map ให้เป็นประโยชน์ได้ เมื่อ designer กำหนดได้อย่างชัดเจนว่าความต้องการของกลุ่มเป้าหมายคืออะไร ก็ไม่ใช่เรื่องยากที่จะรู้ว่าฟีเจอร์ไหนมีคุณค่าต่อพวกเขา
มีสิ่งที่ประเมินได้อย่างแม่นยำว่า release ครั้งต่อไปควรจะเกิดขึ้นเมื่อไร
การประเมินทั้งเวลาที่ต้องใช้ในการออกแบบฟีเจอร์ (ของทีมนักออกแบบ) และเวลาที่ต้องใช้ในการเขียนโค้ดสำหรับฟีเจอร์เหล่านั้น (ของทีมนักพัฒนา) เป็นสิ่งที่สำคัญอย่างยิ่ง
กระบวนการออกแบบจะได้รับข้อมูลสนับสนุนจากการค้นคว้าและทดสอบ
หมายความว่าทีมงานควรใช้เวลาในการทำ user research และทดสอบให้น้อยที่สุดเท่าที่จะทำได้ แต่ยังคงได้ข้อมูลมากพอ ซึ่งการทำ user interview และ field research จะมีประโยชน์มากในเรื่องนี้
การออกแบบและพัฒนาคือกระบวนการที่สิ่งที่ต้องทำซ้ำๆ
และเป็นสิ่งที่ต้องทำเพิ่มขึ้นเรื่อยๆ อีกด้วย กล่าวอีกนัยหนึ่งก็คือ release ของผลิตภัณฑ์ขนาดใหญ่ (ที่กำหนดไว้เป็น milestone) ควรถูกแบ่งออกเป็นก้อนเล็กๆ ที่สามารถบริหารจัดการได้ง่ายขึ้น ด้วยเหตุนี้ผลิตภัณฑ์ที่มีการตรวจสอบซ้ำๆ หลายครั้งจึงออกแบบมาเพื่อตอบโจทย์ทั้งผู้ใช้และธุรกิจ
การสื่อสารอย่างต่อเนื่องคือหัวใจสำคัญ
การพัฒนาและเขียนโค้ด
ดีไซน์ที่มาจากขั้นตอนก่อนหน้านี้ทำหน้าที่เสมือนเป็นพิมพ์เขียวของระบบ ทำให้ developer มีข้อมูลที่จำเป็นมากมายสำหรับการทำงาน ซึ่ง software engineer จะทำหน้าที่แปลงดีไซน์ให้กลายเป็นโค้ดต่อไป
การ debug คือขั้นตอนของการหาบั๊กในโค้ดเหล่านี้แล้วทำการแก้ไขมัน ภาษาที่ใช้ในการเขียนโปรแกรมส่วนใหญ่ในสมัยนี้รองรับการคอมไพล์เวอร์ชัน “debug” ซึ่งสำหรับ software engineer แล้ว เวอร์ชัน debug นี้ช่วยให้พวกเขาสามารถตรวจสอบโค้ด, สร้าง breakpoint, ตรวจสอบค่าของตัวแปร, และรับข้อมูลสำหรับ debug โค้ดได้
แม้ว่า software engineer จะเป็นคนออกแบบระบบ แต่ก็จำเป็นที่จะต้องมีดีไซน์ที่แม่นยำเนื่องจากความผิดพลาดเล็กๆ น้อยๆ อาจนำไปสู่ error ร้ายแรงได้ ในระหว่างที่เขียนโค้ดอยู่นั้นอย่ากลัวที่จะต้องเจอกับลูกค้าถ้าหากจำเป็นต้องให้พวกเขาช่วยอธิบายหรือปรับ requirement หลังจากที่โค้ดทำงานได้เสถียรแล้วก็จะถูกคอมไพล์และนำไปใช้งานในการทดสอบระบบต่อไป
วัดความสำเร็จและติดตามความคืบหน้า
ตามหลักแล้ว ควรมองว่าตัวชี้วัดต่างๆ เป็นเครื่องมือในการตั้งสมมติฐานเพื่อการทดสอบที่มีหน้าที่ในการสนับสนุนเป้าหมายและให้คำตอบเพื่อช่วยในการปรับปรุงซอฟต์แวร์ และควรจำไว้ว่าการวัดผลจะไม่มีประโยชน์อะไรหากคุณไม่สามารถทำอะไรกับข้อมูลเหล่านั้นได้
Project analytics หรือเรียกอีกอย่างว่า development analytics นั้นเป็นเครื่องมือสำคัญในการหาว่ามีอุปสรรคหรือมีโอกาสที่เกิดอุปสรรคอะไรในวงจรของการพัฒนาซอฟต์แวร์บ้างแล้วหาทางกำจัดมัน คุณไม่สามารถบริหารจัดการโปรเจกต์ได้อย่างมีประสิทธิภาพหากไม่มีเครื่องมือวัดผลเหล่านี้ในการเก็บและแสดงข้อมูลอันมีค่าออกมา
คุณต้องกำหนดหน่วยสำหรับชี้วัดของซอฟต์แวร์เพื่อหาทางวัดผลและติดตามประสิทธิภาพ ซึ่งตัวชี้วัดเหล่านี้ควรจะกำหนดไว้ตั้งแต่ตอนเริ่มโปรเจกต์เพื่อให้แน่ใจว่าเวิร์กโฟลว์นั้นราบรื่นและมีความสม่ำเสมอ
ความสำเร็จควรจะวัดผลได้ในหลากหลายทาง เช่น ความสอดคล้องกับวัตถุประสงค์ของโปรเจกต์, developer ทำงานสอดคล้องกับ requirement แรกเริ่ม, และคุณค่าที่ผลิตภัณฑ์มีต่อบริษัทและลูกค้าของคุณ เป็นต้น
ความท้าทายคือ “คุณค่า” หรือ “คุณภาพ” นั้นสามารถวัดผลได้หลายแบบ เช่น ความง่ายในการใช้งาน, ความน่าเชื่อถือ, ความแข็งแรงของโครงสร้าง เป็นต้น
การวัดผลความคืบหน้าในโปรเจกต์ IT นั้นมีความสำคัญมากทั้งต่อลูกค้าและทีมพัฒนาซอฟต์แวร์ ด้วยเหตุผลที่ชัดเจนอยู่แล้วว่าลูกค้าต้องการรู้ว่าโปรเจกต์มีความคืบหน้าอย่างไร แต่ก็ช่วยให้ developer โฟกัสกับงานและจัดลำดับความสำคัญงานได้ดีขึ้นด้วย ซึ่งช่วยทำให้สมาชิกในทีมมีส่วนร่วมและมีส่วนรับผิดชอบต่อผลลัพธ์มากขึ้น
การทดสอบและควบคุมคุณภาพ
การประกันคุณภาพคือหลักการในการติดตามผลของกระบวนการทางวิศวกรรมซอฟต์แวร์ในระหว่างการพัฒนา ซึ่งสามารถทำได้หลากหลายวิธี เช่น ISO 9000 หรือใช้โมเดล Capability Maturity Model Integration (CMMI) ในบางกรณี อาจมีการใช้ซอฟต์แวร์มาช่วยแก้ไขข้อผิดพลาดด้วย
การ deploy บน production
แผนการ delpoy มักคาดหวังว่าจะมีการทำหน้าที่บางอย่างหลังจากที่ส่งมอบงานเสร็จแล้ว
ซึ่งแผนการ delpoy นี้ช่วยให้เราเข้าใจได้ดีขึ้นว่าเส้นทางในการทำงานจะเป็นอย่างไรได้แบบเรียลไทม์และควรคาดหวังหรือจัดการความขัดแย้งที่อาจเกิดขึ้นอย่างไร คุณควรพิจารณาบางอย่างก่อนเริ่มแผนการ delpoy ซึ่งสิ่งต่อไปนี้จะช่วยให้คุณวางแผนและบริหารโปรเจกต์ได้อย่างมีประสิทธิภาพมากยิ่งขึ้น
เริ่มจากผู้ใช้ – เมื่อต้อง deploy ซอฟต์แวร์ คุณต้องคำนึงถึงความง่ายในการใช้งานด้วย ซึ่งเป็นสิ่งที่ควรทำก่อนที่จะปล่อยให้คนทั่วไปได้ใช้กัน การรับฟีดแบ็กจากคนที่ไม่ได้มีส่วนเกี่ยวข้องกับกระบวนการพัฒนาซอฟต์แวร์จะช่วยให้คุณหาบั๊กเจอก่อนที่จะทำให้ลูกค้าของคุณไม่พอใจหากจะสื่อสารกับผู้ใช้ก็ควรสื่อสารกับพวกเขาตั้งแต่ก่อนเปิดตัวผลิตภัณฑ์ ย้ำกับพวกเขาว่านี่คือผลิตภัณฑ์ใหม่ที่ยังจำเป็นต้องมีการแก้ไขอยู่ เมื่อเปิดตัวผลิตภัณฑ์ก็ควรบอกให้พวกเขาอดทนและเชิญชวนให้พวกเขาให้ฟีดแบ็กที่มีค่ากับคุณด้วย
บันทึกเวอร์ชันที่ผ่านมา – คุณอาจต้องพัฒนาผลิตภัณฑ์ขึ้นมาหลายเวอร์ชันเมื่อเตรียมพร้อมสำหรับการเปิดตัว การทำ version control ในการบริหารจัดการวงจรชีวิตของโปรเจกต์จึงเข้ามารับผิดชอบในส่วนนี้ ซึ่งจะมีการใช้ทั้งเอกสารที่ใช้ภายนอก (เช่น คู่มือการอัปเดตซอฟต์แวร์ของคุณ) และเอกสารที่ใช้ภายใน (เช่น log ที่บันทึกการแก้ไขโค้ดสำหรับ release ครั้งต่อไปของซอฟต์แวร์คุณ)
คุ้มไหมที่ต้องทำการแก้ไข – “ถ้าไม่พัง ก็ไม่ต้องซ่อม” เพราะการสร้างผลิตภัณฑ์ใหม่ขึ้นมาหรือแก้ไขสิ่งที่มีอยู่แล้วอาจกลายเป็นงานใหญ่ที่ส่งผลลัพธ์ที่ไม่พึงประสงค์ เช่น บั๊กใหม่ที่ผู้ใช้ต้องเจอ การวางแผน deploy ซอฟต์แวร์จึงควรต้องพิจารณาให้ดีว่าหากอัปเดตแล้วจะคุ้มกับการที่ต้องเหนื่อยแก้ปัญหาหรือไม่
การให้บริการช่วยเหลือผู้ใช้และบำรุงรักษาซอฟต์แวร์
อย่าลืมว่าต้องจดเรื่องสุดท้ายที่แสนสำคัญนี้ไว้ในแผนงานพัฒนาซอฟต์แวร์ของคุณ เพราะเมื่อคุณเปิดตัวผลิตภัณฑ์แล้ว ตารางการบำรุงรักษาก็จะเริ่มขึ้น
การแก้ไขบั๊ก การให้ความช่วยเหลือผู้ใช้ และตอบสนองต่อความต้องการฟีเจอร์ใหม่ๆ คือตัวอย่างของการให้บริการช่วยเหลือ ส่วนแพทช์และอัปเดตก็คือตัวอย่างของการบำรุงรักษา คุณต้องตัดสินใจว่าลูกค้าต้องการความช่วยเหลือด้านใดบ้าง การบำรุงรักษาและให้ความช่วยเหลือสามารถมีได้หลากหลายประเภทขึ้นอยู่กับผลิตภัณฑ์และความต้องการของลูกค้า
การหาทางป้องกันปัญหาในการบำรุงรักษาและให้ความช่วยเหลือคือสิ่งสำคัญในการทำให้ลูกค้าพึงพอใจและกลับมาใช้บริการคุณอีกครั้งในอนาคต
สรุปทิ้งท้าย
ความแตกต่างหลักๆ ก็คือ โปรเจกต์แบบ Waterfall นั้นทุกสิ่งถูกกำหนดไว้ตายตัว และเป็นเส้นตรง ทุกสิ่งมีการวางแผนไว้ล่วงหน้าหมดแล้ว และลูกค้าจะมามีส่วนร่วมเฉพาะตอนเริ่มและสิ้นสุดโปรเจกต์เท่านั้น
แต่สำหรับหลักการทำงานแบบ Agile นั้น จะต่างกันตรงที่มีลำดับความสำคัญของงานและ requirement ใหม่ๆ เพิ่มเข้ามาในโปรเจกต์หลังจากเสร็จแต่ละ sprint และเมื่อได้รับฟีดแบ็กจากลูกค้า
เราพร้อมช่วยเหลือคุณตั้งแต่การวางแผนโปรเจกต์พัฒนาซอฟต์แวร์จนกระทั่งโปรเจกต์เสร็จสิ้น ไม่ว่าคุณเพิ่งเรียนรู้เกี่ยวกับ Agile หรือว่าเคยมีประสบการณ์เกี่ยวกับ Agile และ Scrum มาก่อนก็ตาม ที่ Seven Peaks Software เราออกแบบ สร้าง และบริหารจัดการโปรเจกต์ Agile ด้วยหลักการแบบ design thinking เพื่อสร้างผลิตภัณฑ์ที่ลูกค้าชอบ
อ่านข้อมูลเพิ่มเติมเกี่ยวกับบริการพัฒนาซอฟต์แวร์แบบครบวงจรของเราได้ที่นี่
แชร์เรื่องนี้
- FinTech (11)
- การพัฒนาซอฟต์แวร์ (10)
- Expert Spotlight (8)
- อาชีพการงาน (8)
- Cloud (5)
- InsurTech (5)
- Mixpanel (5)
- Agile (4)
- Digital Transformation (4)
- JavaScript (4)
- QA (4)
- Trend (4)
- การพัฒนาแอปพลิเคชัน iOS (4)
- Android Developer (3)
- Azure (3)
- Banking (3)
- CSR (3)
- Hybrid App (3)
- IoT (3)
- Product-Centric Mindset (3)
- Seven Peaks Insights (3)
- Thought Leadership (3)
- การพัฒนาแอปฯ Android (3)
- การออกแบบ UX (3)
- บริษัท (3)
- เทคโนโลยีการเงินและการธนาคาร (3)
- .NET (2)
- AI (2)
- Cross-Platform Application (2)
- Data (2)
- Kotlin (2)
- Native App (2)
- ReactJS (2)
- digital marketing (2)
- การพัฒนาแอปฯ (2)
- งาน Product Owner (2)
- 5g (1)
- Android (1)
- AndroidX Biometric (1)
- Azure OpenAI Service (1)
- Biometrics (1)
- CI/CD (1)
- Customer Data Platform (1)
- Data and Analytics (1)
- Design Thinking (1)
- DevOps (1)
- Digital Healthcare (1)
- Digital ID (1)
- Digital Landscape (1)
- Digital Product (1)
- Digital Product Development (1)
- E-payment (1)
- E-wallet (1)
- Financial Inclusion (1)
- GraphQL (1)
- IT Outsourcing (1)
- MVP (1)
- MVVM (1)
- Metaverse (1)
- Morphosis (1)
- Node.js (1)
- Partner (1)
- Platform Engineering (1)
- Recruitment (1)
- SCB (1)
- SEO (1)
- Scrum Master (1)
- Software Engineer (1)
- Software Tester (1)
- Stripe (1)
- Swift (1)
- SwiftUI (1)
- Tech Meetup (1)
- Turnkey (1)
- UI (1)
- UX (1)
- UX Design (1)
- UX writing (1)
- Web-Debugging Tool (1)
- customer centric (1)
- iOS17 (1)
- waterfall (1)
- การจ้างงาน (1)
- การพัฒนาด้วย RabbitMQ (1)
- การพัฒนาระบบคลาวด์ (1)
- การออกแบบ Decorator Pattern (1)
- การใช้งาน C# (1)
- งาน Product Manager (1)
- งาน platform enginerring (1)
- ทำ Context API (1)
- ฟินเทค (1)
- ระบบการชำระเงิน (1)
- สร้าง brand loyalty (1)
- อีคอมเมิร์ซ (1)
- เขียนโค้ด React (1)
- เทคโนโลยี React (1)
- เพิ่ม conversion (1)
- เฟรมเวิร์ก (1)
- แดชบอร์ด (1)
- สิงหาคม 2024 (1)
- กรกฎาคม 2024 (2)
- มีนาคม 2024 (5)
- กุมภาพันธ์ 2024 (5)
- มกราคม 2024 (14)
- ธันวาคม 2023 (4)
- พฤศจิกายน 2023 (9)
- ตุลาคม 2023 (12)
- กันยายน 2023 (7)
- กรกฎาคม 2023 (4)
- มิถุนายน 2023 (3)
- พฤษภาคม 2023 (3)
- เมษายน 2023 (1)
- มีนาคม 2023 (1)
- พฤศจิกายน 2022 (1)
- สิงหาคม 2022 (4)
- กรกฎาคม 2022 (1)
- มิถุนายน 2022 (4)
- เมษายน 2022 (6)
- มีนาคม 2022 (3)
- กุมภาพันธ์ 2022 (6)
- มกราคม 2022 (3)
- ธันวาคม 2021 (2)
- ตุลาคม 2021 (1)
- กันยายน 2021 (1)
- สิงหาคม 2021 (3)
- กรกฎาคม 2021 (1)
- มิถุนายน 2021 (2)
- พฤษภาคม 2021 (1)
- มีนาคม 2021 (4)
- กุมภาพันธ์ 2021 (4)
- ธันวาคม 2020 (4)
- พฤศจิกายน 2020 (1)
- มิถุนายน 2020 (1)
- เมษายน 2020 (1)