การวางแผนโปรเจกต์พัฒนาซอฟต์แวร์สำหรับปี 2023

ทุกคน (รวมถึงลูกค้า) จะต้องรู้ว่าแต่ละคนกำลังทำอะไรอยู่ตลอดเวลา ซึ่งปกติแล้วข้อมูลเหล่านี้จะไม่เปิดเผยในการทำงานกับลูกค้าแบบ 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 นั้นจะช่วยให้การส่งมอบงานรวดเร็วขึ้นและเพิ่มความพึงพอใจของลูกค้าได้อย่างต่อเนื่อง

แนะนำวิธีการสร้างแผนพัฒนาซอฟต์แวร์ที่มีประสิทธิภาพและนำมาปรับใช้

การออกแบบและวาง 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 เพื่อสร้างผลิตภัณฑ์ที่ลูกค้าชอบ

อ่านข้อมูลเพิ่มเติมเกี่ยวกับบริการพัฒนาซอฟต์แวร์แบบครบวงจรของเราได้ที่นี่