Digital Product Development Process : กระบวนการสร้างดิจิทัลโปรดัก

        ในปัจจุบันองค์กรต่างๆมีความต้องการที่จะทำ digital transformation หรือทำ software ต่างๆขึ้นมาไม่ว่าจะเป็น software ที่ใช้ในองค์กรหรือใช้กับลูกค้าขององค์กร จุดประสงค์เพื่อพัฒนาศักยภาพในองค์กรให้ก้าวหน้าหรือเท่าเทียมกับคู่แข่ง แต่หลายๆครั้งในการทำ digital product หรือ software ในองค์กรนั้นยังไม่ประสบความสำเร็จเท่าที่ควร ซึ่งในประเทศไทยปัจจุบันสาเหตุอาจเกิดจากการขาดบุคลากรที่มีความสามารถเพียงพอหรือขาดความเข้าใจที่ถูกต้องในการทำ digital product 

        จริงๆแล้วการทำ digital product ไม่ได้มีวิธีการที่ตายตัวสามารถเลือกวิธีการที่เหมาะสมกับองค์กรของตัวเองมาปรับใช้ได้ ส่วนสำคัญในการทำ digital product หรือ software ในองค์กรนั้นจะแบ่งได้เป็น 3 ส่วนด้วยกันคือ

1. Discovery (การสำรวจความต้องการ)
2. Implementation (การพัฒนาซอฟแวร์)  
3. Launch (การนำซอฟแวร์ออกไปใช้งานจริง) 

1. Discovery (การสำรวจความต้องการ)

        การเริ่มทำ discovery ที่ดีที่สุดควรเริ่มจากปัญหาที่มีในองค์กร เช่น ปัญหาเรื่อง productivity ใน operation ปัญหาเรื่องยอดขาย ปัญหาเรื่อง costumer service เป็นต้น เนื่องจากการทำ software เป็นสมมติฐานว่าจะสามารถช่วยแก้ไขปัญหาได้อีกทั้งเราต้องคำนึงอยู่เสมอว่าการทำ software นั้นเป็นการลงทุนอย่างหนึ่งซึ่งต้องมีการวัดผลว่าคุ้มทุนที่จะต้องลงหรือไม่ดังนั้นควรมีวัถุประสงค์ที่ชัดเจนว่าต้องการทำ software ขึ้นมาเพื่อส่งเสริมองค์กรในเรื่องใด อีกวิธีหนึ่งที่เป็นวิธีที่ดีคือ การเริ่มทำ discovery จาก strategy ขององค์กร องค์กรมีเป้าหมายอะไร มี challenge ในเรื่องใดบ้าง เราก็สามารถที่จะตั้งสมมติฐานว่าการทำ software ที่มีฟังก์ชันแบบนี้จะช่วยให้องค์กรบรรลุเป้าหมายหรือก้าวข้าม challenge ที่มีได้

        เมื่อมีวัตถุประสงค์ชัดเจนแล้วเราก็ต้องมาดูต่อว่าจะมีใครเป็นผู้ใช้งานหรือเป็น users ใน software หรือ platform ที่เราจะทำขึ้นมาบ้าง เช่นมี ฝ่ายปฏิบัติการ ฝ่ายบัญชี และฝ่ายบริหาร เป็นต้น users แต่ละประเภทจะมีวัตถุประสงค์หรือเป้าหมายในการใช้งานที่แตกแต่งกันไป ดังนั้น ฟังก์ชันหรือ features ที่ควรมีใน software ควรเป็น features ที่จำเป็นต่อการทำให้วัตถุประสงค์หรือเป้าหมายในการทำงานของ users ทุกประเภทสำเร็จด้วยความราบรื่น  

        ยิ่งไปกว่านั้นเราต้องทำความเข้าใจประเภทของ users ต่างๆ ว่าพวกเขาเป็นใคร มี process การทำงานอย่างไร เช่น หากผู้ใช้งานเป็นผู้สูงอายุและไม่มีความเชี่ยวชาญด้านเทคโนโลยี ก็ควรออกแบบ software ให้ navigate ง่ายและควรใช้ตัวอักษรที่มีขนาดใหญ่ หรือหากผู้ใช้งานจะต้องใช้ software ระหว่างปฏิบัติการในโรงงานและในระหว่างทำงานต้องมีการเดินไปมาเยอะก็ควรออกแบบให้ user ประเภทนี้สามารถใช้งานผ่านโทรศัพท์มือถือได้เพื่อเป็นงานสะดวกในการทำงาน ภาษาที่ users ถนัด หรือ การแสดงผลหรือข้อความต่างๆบน software ก็ควรแสดงเฉพาะข้อมูลที่ users แต่ละประเภทต้องดูเพื่อใช้งานเท่านั้น ข้อมูลใดที่ไม่จำเป็นก็ไม่ควรแสดงผลเพื่อง่ายต่อการทำงานของ users ประเภทต่างๆ

        หลังจากเราได้ศึกษากระบวนการทำงานของ users แต่ละประเภทแล้วเราก็จะสามารถทำเป็น users flow diagrom ซึ่งจะอธิบาย process การทำงานของ users ได้อย่างชัดเจนและทำให้เราสามารถทำ features list ว่าใน platform หรือ software นี้ควรมี features อะไรบ้าง ในการทำ features list ควรเริ่มจาก feature ที่จำเป็นในการทำงานของ user แต่ละประเภทเท่านั้นยังไม่ควรใส่ feature ที่คิดว่าถ้ามีก็จะดีหรือ nice to have เพราะภายหลัง feature เหล่านั้นอาจจะกลายเป็น feature ที่จริงๆ user ไม่ได้ใช้งานก็จะเท่ากับว่าเป็นการลงทุนที่สูญเปล่า

        เมื่อเราได้ user flow diagram กับ features list แล้วเราก็จะมาต่อด้วยการทำ sitemap หรือแผนที่ของ website, platform หรือ software นั่นเอง ที่กล่าวมาตั้งแต่ขึ้นตอนแรกจนมาถึงการทำ sitemap นั้นทีมงานทีสามารถทำในส่วนนี้ได้ก็คือ Product Owner (PO) หรือ “เจ้าของดิจิทัลซอฟแวร์” Business Analyst (BA) หรือ “นักวิเคราะห์ธุรกิจ”และ ดีไซน์เนอร์ตั้งแต่ในส่วนของ user type ลงมา แต่จริงๆแล้วถ้า Product Owner สามารถทำได้ด้วยตัวเองหรือมีส่วนร่วมทั้งหมดก็จะดีที่สุด

        ในที่สุดเราก็จะสามารถทำ prototype ของ digital product ของเราเพื่อนำไปทดสอบกับ users เพื่อเก็บ feedback ได้แล้ว ซึ่ง prototype ของเราก็คือตัว wireframe นั้นเอง (แนบบทความ = ชนิดของ wireframe) เมื่อทำ wireframe หรือ prototype เสร็จแล้วเราก็ควรนำไปให้ user ที่จะต้องมาเป็นผู้ใช้งานจริงได้ลองใช้เพื่อไปเก็บ feedback แล้วนำมาปรับแก้ก่อนที่จะลงสีหรือทำเสร็จเป็น User Interface (UI) ซึ่งจะส่งไปให้ developer พัฒนาต่อไป ขั้นตอนนี้ถือเป็นขั้นตอนที่สำคัญเพราะเหตุผลสำคัญ 2 ประการด้วยกันคือ ประการแรก หากเราได้ให้ user ทดลองใช้งานและเก็บ feedback มาปรับจะทำให้เราสามารถ deliver software หรือ platform ที่เป็นที่ต้องการของ user ประการที่สองการปรับแก้ในขั้นตอนของ wireframe นั้นทำง่ายกว่า ราคาถูกกว่า และใช้เวลาน้อยกว่าที่จะต้องไปปรับแก้หลังจากได้พัฒนา software ออกมาแล้วหรือแม้แต่การปรับแก้ User Interface (UI)

        การทำ Discovery ที่สมบูรณ์แบบนั้นควรจบด้วย User Interface (UI), User stories ที่เขียนโดย Product Owner (PO), Requirement Document (functional and non-functional) และในบางกรณีก็ต้องมี Technical Requirement Document ด้วย

2. Implementation (การพัฒนาซอฟแวร์)  

        ในขั้นตอนการทำ Implementation หรือการพัฒนาซอฟแวร์จะต้องมี Project Manager เป็นผู้บริหารจัดการ Project โดย Project Manager (PM) ก็จะได้รับ User Interface (UI), User stories ที่เขียนโดย Product Owner (PO), Requirement Document (functional and non-functional) และ Technical Requirement Document ด้วยในบางกรณี แต่ในกรณีที่ Product Owner ไม่ได้เขียน User Stories Project Manager ก็จะต้องทำหน้าที่นี้ซึ่งเรียกว่าการ Create Backlog นั้นเองโดย Project Manager จะทำการ Create tickets หรือสร้างตั๋วงานขึ้นมาโดยเรียงลำดับความสำคัญของ Feature ที่ต้องการ develop หรือพัฒนาตามความต้องการของ Product Owner 

        หลังจากนั้นก็จะต้องทำการ setup Sprint Life cycle หรือ กระบวนการในรอบการทำงานนั้นเอง ใน 1 Sprint Life Cycle โดยส่วนใหญ่จะใช้เวลา 1-2 สัปดาห์ขึ้นอยู่กับขนาดของ Project ซึ่งจะประกอบไปด้วย 

1. Sprint Grooming หรือการเตรียมตั๋วงาน
2. Sprint Planning การวางแผนและจ่ายงานใน sprint นั้นๆ 
3. Standup meeting คือการประชุมแบบสั้นๆโดยจะมีการถาม 3 คำถามคือเมื่อวานนี้ทำตั๋วงานอะไร วันนี้ทำตั๋วงานอะไร มี blocker หรืออุปสรรค์ในการทำงานหรือไม่
4. Demo หรือการส่งมอบงานให้ Product Owner 

        ในขั้นตอนนี้ทีมก็จะประกอบไปด้วย Project Manager (PM), Developer (ไม่ว่าจะเป็น Frontend, Backend, Mobile, Full Stack หรือ DevOps) และ Quality Assurance (QA)  

3. Launch (การนำซอฟแวร์ออกไปใช้งานจริง) 

        ในการ Launch software หรือ Digital Product จะต้องทำ Strategy ก่อน เบื้องต้นอาจจะพิจารณาได้สองรูปแบบคือ Software หรือ Digital Product ที่ทำขึ้นมานั้นจะนำมาใช้ภายในองค์กรหรือจะนำไปใช้ภายนอกองค์กร 

        หากเป็น Software หรือ Digital Product ที่ทำขึ้นเพื่อใช้ภายในองค์กร หนึ่งใน Strategy อาจเป็นการให้ users จริงที่จะต้องเป็นคนใช้งาน Software หรือ Digital Product เมื่อทำเสร็จมามีส่วนร่วมในการคิด Features หรือ Function การทำงานต่างๆตั้งแต่แรก เพราะว่าการสร้าง engagement ในลักษณะนี้จะทำให้ Users มีส่วนร่วมในการคิด Features ที่เขาจะต้องใช้ทำให้ Software ที่ออกแบบมาตรงกับความมต้องการของ users ทำให้เขามองว่าสิ่งนี้สร้างขึ้นเพื่อให้เขาทำงานได้ดียิ่งขึ้นสะดวกสบายยิ่งขึ้น ในทางกลับกันหาก users ที่ต้องใช้งานจริงไม่ได้มีส่วนร่วมในการคิด Features อาจจะทำให้ adoption rate ต่ำ เนื่องจาก users จะมีความรู้สึกว่าจะต้องเปลี่ยนแปลงวิธีการทำงานใหม่เพราะเป็นความต้องการขององค์กรไม่ใช่ความต้องการของตนการเปลี่ยนวิธีการทำงานมาใช้ Digital Product ที่องค์กรทำขึ้นมาอาจไม่ประสบความสำเร็จเพราะว่า users ไม่อยากใช้หรือเกิดการต่อต้านการเปลี่ยนแปลงนั่นเอง 

        หากเป็น Software หรือ Digital Product ที่ทำขึ้นเพื่อใช้ภายนอกองค์กร อาจพิจารณาได้ในหลายแง่มุมขึ้นอยู่กับธุรกิจขององค์กรและ users ที่องค์กรต้องการให้ใช้ หรือ เป็นการทำ Software หรือ Digital Product ขึ้นมาใหม่ทั้งหมด หรือเป็นการทำใหม่เพื่อแทน Software หรือ Digital Product ที่มีอยู่ก่อน หรือเป็นการทำใหม่บางส่วน แต่หลักการสำคัญยังคงคล้ายเดิมคือ Focus ที่ users หรือผู้ใช้งานนั่นเอง เช่น หากเราทำ Software ที่เป็น E-Commerce หรือ Market Place ก็อาจจะต้องคำนึงที่ budget หรืองบประมาณที่มีในการทำการตลาด องค์กรที่มี budget เยอะก็อาจทำ promotion ต่างๆออกมาเยอะ หรือ ขายในราคาที่ถูกกว่าท้องตลาดในตอนแรกเพื่อให้ได้ users บน Platform ในจำนวนมาก อย่างไรก็ตามในการทำ Strategy เพื่อ Launch software หรือ Digital Product จะต้องทำตั้งแต่เริ่มทำ Discovery เพื่อให้การออกแบบ software หรือ Digital Product รองรับ Features ต่างๆที่อาจต้องมีเพื่อทำการ Launch