วิธีเก็บ requirement ภายในองค์กรก่อนทำ internal software

ในการเริ่มต้นทำ Software หรือ Digital Product สิ่งแรกที่ต้องเริ่มทำคือการเก็บ Requirement หรือเก็บรายละเอียดของคุณสมบัติที่ต้องการให้ Software นั้น ๆ มีการเก็บ Requirement จะต้องทำเสมอไม่ว่าจะเป็นการทำ Software หรือ Digital Product เองภายในองค์กร หรือเป็นการจ้างบริษัทภายนอกมาทำก็ตาม เพื่อให้ทราบว่า เราต้องการทำอะไรบ้างโดยมีรายละเอียดที่เพียงพอสำหรับการนำไปประเมินต้นทุนก่อนลงมือทำ อีกทั้งขั้นตอนนี้สามารถช่วยให้เราทำความเข้าใจในอีกหลาย ๆ เรื่องด้วยเช่น วัตถุประสงค์ในการทำ ผลลัพธ์ที่เราต้องการ Dependency ต่าง ๆ ที่จะเกิดขึ้น เป็นต้น 

ขั้นตอนการเก็บ Requirement ที่สามารถทำเองได้ก่อนที่จะส่งไปให้ทีม IT หรือ นักพัฒนาซอฟต์แวร์ทำมี 6 ขั้นตอนดังต่อไปนี้ 

1. ระบุให้ชัดเจนว่า การทำ Software หรือ Digital Product นี้ขึ้นมามีวัตถุประสงค์อะไรหรือเพื่อแก้ปัญหาอะไร 

2. ระบุให้ชัดเจนว่า ใน Software หรือ Digital Product นี้มีผู้ใช้งานหรือ User กี่ประเภท 

3. ดำเนินการเก็บ Requirement หรือสำรวจความต้องจากผู้ใช้งานหรือ User

4. นำ Requirement ที่ได้มาจากผู้ใช้งานหรือ User มาเรียบเรียงให้เป็นลายลักษณ์อักษร 

5. ทำการ Confirm Requirement ที่ได้เรียบเรียงแล้วกับผู้ใช้งานหรือ User อีกครั้ง
6. เรียงลำดับความสำคัญของ Feature หรือ Function การทำงานต่าง ๆ ของ Software หรือ Digital Product

1. ระบุให้ชัดเจนว่า การทำ Software หรือ Digital Product นี้ขึ้นมามีวัตถุประสงค์อะไรหรือเพื่อแก้ปัญหาอะไร 

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

ตัวอย่างเช่น บริษัทของเราเป็นโรงงานผลิตยางรถยนต์ต้องการทำ Software หรือ Digital Product ขึ้นมามีวัตถุประสงค์เพื่อให้ทีมงานทราบว่า ปัจจุบันมีวัตถุดิบเพียงพอสำหรับผลิตยางรถยนต์ตาม Order ที่มีหรือไม่ หากมีไม่เพียงพอจะต้องทำการ Notify ไปยังทีมวัตถุดิบให้นำวัตถุดิบมาเติม

จากตัวอย่างจะเห็นว่ามีเพียง 1 ข้อเท่านั้นที่เป็น Feature หรือ Function ที่ทำให้บรรลุวัตถุประสงค์ในการทำ Software หรือ Digital Product โดยตรง จะเห็นได้ว่าการระบุวัตถุประสงค์ในการทำ Software หรือ Digital Product ที่ชัดเจนมีประโยชน์มาก

2. ระบุให้ชัดเจนว่า ใน Software หรือ Digital Product นี้มีผู้ใช้งานหรือ User กี่ประเภท 

การระบุว่า Software หรือ Digital Product มีผู้ใช้งานหรือ User กี่ประเภททำได้ด้วยการร่าง Flow การทำงานขึ้นมาแล้วดูว่า มีผู้ที่เกี่ยวข้องเป็นใครบ้าง การร่าง Flow ทำได้โดยการ List Step การทำงาน หรือ ทำเป็น Flowchart แล้วใส่รายละเอียดต่าง ๆ ที่เกี่ยวข้องลงไปก็ได้ แต่การร่างเป็น Flowchart จะเป็นวิธีที่ละเอียดแล้วทำให้ง่ายต่อการเก็บ Requirement กับ User มากกว่า เพราะว่า ทำให้เราและ User เห็นภาพของขั้นตอนการทำงานทั้งหมด การทำ Flowchart เพื่อระบุประเภทผู้ใช้งานหรือ User สามารถทำได้ด้วยการคิดถึงขั้นตอนการทำงาน และระบุประเภทผู้ใช้งานหรือ User หรือผู้ที่มีหน้าที่เกี่ยวข้องใน Process นั้น ๆ กับ Action ที่ผู้มีหน้าที่เกี่ยวข้องต้องทำลงไป เราสามารถทำ Flowchart แบบง่าย ๆ โดยเริ่มจากการใช้ Shape Process เพียง Shape เดียวก็ได้แล้วค่อย ๆ ใส่ Shape อื่น ๆ ตอนเราเก็บ Requirement หรือสำรวจความต้องจากผู้ใช้งาน หรือ User อีกที เพราะขั้นตอนนี้เราเพียงต้องการระบุว่า มีผู้ใช้งานหรือ User กี่ประเภท แต่หากเรามีความสามารถในการเขียน Flowchart ที่ดีอยู่แล้วก็สามารถใช้ Shape อื่น ๆ ด้วยได้เลย

ตัวอย่าง
   

3. ดำเนินการเก็บ Requirement หรือสำรวจความต้องจากผู้ใช้งานหรือ User

ในขั้นตอนการเก็บ Requirement หรือสำรวจความต้องจากผู้ใช้งาน หรือ User เราจะต้องวางแผนว่า จะเริ่มเก็บ Requirement ในขั้นตอนไหนก่อนจากนั้นจึงจัดกลุ่ม และเรียงลำดับผู้ใช้งานหรือ User ตามที่เราวางแผนไว้ จากนั้นจึงนัดหมายผู้ใช้งานหรือ User มาเก็บ Requirement โดยที่เราจะต้องเตรียมคำถามไว้สอบถาม ผู้ใช้งานหรือ User ไว้ก่อน ตัวอย่างคำถามเช่น 1. ใน 1 วันหรือใน 1 รอบการทำงานจะต้องทำอะไรบ้าง โดยให้อธิบายจากจุดเริ่มต้นงานไปยังจุดจบงาน 2. วัตถุประสงค์ในการทำงานหรือเป้าหมาย หรือสิ่งที่เขาต้องทำให้สำเร็จคืออะไร 3. จุดไหนเป็นจุดที่ยากในการทำงานเพราะว่าอะไร 4. ข้อดีและข้อเสียของ process การทำงานในปัจจุบัน คำถามที่ถามผู้ใช้งานหรือ User ควรเป็นคำถามปลายเปิดเพื่อให้เขาเล่าเรื่องราวออกมาได้อย่างเต็มที่ บรรยากาศในการพูดคุยควรเป็นไปอย่างสบาย ๆ

ในขั้นตอนการเก็บ Requirement กับผู้ใช้งานหรือ User เราควรที่จะทำการ Observe การทำงานของผู้ใช้งานหรือ User แต่ละประเภทตั้งแต่ต้นจนจบ หรือเท่าที่จะสามารถทำได้เพื่อให้ทราบกระบวนการอย่างแน่ชัดเพราะเพียงแค่ฟังผู้ใช้งานหรือ User เล่า Process การทำงานของเขาให้ฟังนั้นอาจจะยังไม่ครบถ้วน อีกทั้งถ้าเราทำการ Observe การทำงานของผู้ใช้งานหรือ User แต่ละประเภทตั้งแต่ต้นจนจบ เราจะได้เห็นว่าในแต่ละขั้นตอนนั้นผู้ใช้งานหรือ User จะต้องอยู่ในสถานที่ใด มีข้อจำกัดใดหรือไม่ หรือมี Dependancy ใดเข้ามาเกี่ยวข้องหรือไม่ จะทำให้เราเข้าใจผู้ใช้งานหรือ User อย่างแท้จริง

4. นำ Requirement ที่ได้มาจากผู้ใช้งานหรือ User มาเรียบเรียงให้เป็นลายลักษณ์อักษร 

การนำ Requirement ที่ได้มาจากผู้ใช้งานหรือ User มาเรียบเรียงให้เป็นลายลักษณ์อักษร หรือการทำ Requirement Document นั้นในเอกสารจะต้องมีรายละเอียด 3 อย่าง ประกอบไปด้วย

1. รายละเอียดของวัตถุประสงค์ในการทำ Software หรือ Digital Product

2. รายละเอียดของ Users ระบุให้ชัดเจนว่าใน Software หรือ Digital Product นี้มี Users ทั้งหมดกี่ประเภทและแต่ละประเภทสามารถทำอะไรได้บ้าง

3. รายละเอียดของ Features และ Function การทำงานต่าง ๆ

5. ทำการ Confirm Requirement ที่ได้เรียบเรียงแล้วกับผู้ใช้งานหรือ User อีกครั้ง

ในการ Confirm Requirement แนะนำให้ทำสองรอบด้วยกัน รอบแรกเป็นการ Confirm Requirement กับผู้ใช้งานหรือ User โดยแบ่งแยกประเภทเพื่อให้ผู้ใช้งานหรือ User ประเภทต่าง ๆ เห็นตรงกันก่อน จากนั้นควรทำการ Confirm Requirement แบบรวมเพื่อให้ผู้ใช้งานหรือ User ทุกประเภทได้มีโอกาสถามคำถามเพื่อทำความเข้าใจ หรือแลกเปลี่ยนความคิดเห็นกัน หากมีจุดใดที่ต้องทำความเข้าใจกันเพิ่มหรือปรับเปลี่ยน Requirement เมื่อมีการปรับเปลี่ยนแล้วจะต้องกลับมาทำการ Confirm Requirement อีกครั้ง จนกว่าทุกฝ่ายจะเห็นตรงกัน หรือมีความเข้าใจที่ต้องตรงกันจึงจะถือว่าเสร็จขั้นตอนการ Confirm Requirement ขั้นตอนนี้สำคัญมากเพราะหากว่า ไม่มีการทำการ Confirm Requirement เสียก่อนเมื่อเริ่มดำเนินการทำ Software หรือ Digital Product จะพบว่ามีหลายจุดที่จะต้องมาทำความเข้าใจกันในระหว่างทางทำให้ระยะเวลาในการพัฒนาทำ Software หรือ Digital Product ต้องล่าช้าออกไปกว่าเป้าหมายที่กำหนด

6. เรียงลำดับความสำคัญของ Feature หรือ Function การทำงานต่าง ๆ ของ Software หรือ Digital Product

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

การเรียงลำดับความสำคัญจะทำให้การทำ Software หรือ Digital Product พัฒนาออกมาให้ Users จริงได้ใช้ได้เร็ว เพราะว่าเราควรให้ User ได้ใช้งานจริงทันทีที่ Software หรือ Digital Product ถึงจุดที่สามารถใช้งานได้ (User สามารถใช้ Software หรือ Digital Product ทำงานของตัวเองให้บรรลุวัตถุประสงค์ได้) เนื่องจากการคิด Feature หรือ Function ต่าง ๆ ของเราล้วนแต่เป็นสมมติฐานทั้งสิ้นหาก User ได้ใช้จริงเร็วขึ้นเท่าไรจะทำให้เราทราบว่า สมมุติฐานของเราถูกต้องหรือไม่เร็วขึ้นเท่านั้น และเมื่อ User ได้ใช้จริงจะทำให้เราทราบว่า Feature หรือ Function ที่ขาดไปนั้นคืออะไรได้อย่างถูกต้องชัดเจน 

ยกตัวอย่างเดิมจากข้อ 1 บริษัทของเราเป็นโรงงานผลิตยางรถยนต์ต้องการทำ Software หรือ Digital Product ขึ้นมามีวัตถุประสงค์เพื่อให้ทีมงานทราบว่า ปัจจุบันมีวัตถุดิบเพียงพอสำหรับผลิตยางรถยนต์ตาม Order ที่มีหรือไม่ หากมีไม่เพียงพอจะต้องทำการ Notify ไปยังทีมวัตถุดิบให้นำวัตถุดิบมาเติม