ปกติแล้วผมจะเขียนเกี่ยวกับ product development ที่เว็บไซต์ของ JindaTheme เสียเป็นส่วนใหญ่ แต่หลังจากนี้คิดว่าจะเอาทั้งหมดกลับมาเขียนที่บล็อกส่วนตัวแทนจะได้จัดการโพสต์ต่างๆได้ง่ายขึ้น วันนี้อยากแชร์ประสบการณ์ในฐานะที่ตัวเองเคยเป็นทั้งลูกค้า เป็นทั้งผู้รับผิดชอบโครงการ และเป็นทั้งผู้ให้บริการ เกี่ยวกับการทำแพลตฟอร์มหรือการทำผลิตภัณฑ์ดิจิตอลครับ
Requirement ไม่ชัดเจน
ยิ่งกับบริษัทสตาร์ทอัพ หรือโปรเจคใหม่ที่เพิ่งก่อตั้งไม่นานปัญหานี้จะชัดเจนมากๆ อาจจะเป็นเพราะไอเดียที่ได้ยังไม่ตกผลึกหรือยังไม่รู้ตลาดที่ชัดเจน ทำให้ requirement ที่ได้รับมามักจะเปลี่ยนไปเปลี่ยนมาตลอดเวลา อาทิตย์นึงอยากได้แบบนึง พอผู้ให้บริการทำไปสักพักก็นึกอยากจะเปลี่ยน requirement แบบนี้มีให้พบเจออยู่ตลอด ซึ่งแน่นอนว่าเมื่อมีการเปลี่ยนแปลง ก็ต้องใช้เวลาในการพัฒนามากขึ้น และบางครั้งก็ต้องเสียค่าใช้จ่ายในการปรับเปลี่ยนสิ่งต่างๆที่อยู่นอกเหนือข้อตกลงด้วย
การเปลี่ยน requirement นั้นเสียสองอย่างคือ ระยะเวลาที่ใช้พัฒนาต้องเพิ่มขึ้น และค่าใช้จ่ายที่อาจเกิดขึ้น
หากโครงการไหนที่มี deadline กำหนดวันส่งงานชัดเจน การเปลี่ยน requirement ถือเป็นเรื่องอันตรายและถือเป็นความผิดพลาดด้านการจัดการและการวางแผน โดยเฉพาะการเปลี่ยนสาระสำคัญของโครงการ หรือส่วนที่เป็นหัวใจหลัก(core)ของผลิตภัณฑ์ก็อาจทำให้เกิดข้อผิดพลาดอย่างมากมายตามมาได้
ยกตัวอย่าง ลูกค้าต้องการทำระบบ e-commerce ซึ่งได้บรีฟมาว่าต้องการระบบขนส่งที่คิดราคาตามระยะทาง หรือคิดราคาจากรหัสไปรษณีย์ ก็ตกลงกับผู้ให้บริการกันเรียบร้อยตั้งแต่ก่อนลงนามสัญญาทั้งเรื่องของระยะเวลาที่ใช้และค่าใช้จ่ายที่จะเกิดขึ้น หลังจากทำสัญญากันแล้วผู้ให้บริการก็จะไปทำการพัฒนาระบบ ออกแบบโครงสร้างวางแผนงานตามที่ได้ทำสัญญาเอาไว้
วันดีคืนดี ลูกค้าไปเห็นระบบอื่นหรือคู่แข่งมีฟังก์ชันการใช้งานใหม่
ก็นึกอยากจะเปลี่ยนแปลง เปลี่ยนจากคิดราคาตามรหัสไปรษณีย์มาเป็นคิดราคาตั้งต้นจากจุดกระจายสินค้าแล้วบวกเพิ่มตาม hop หรือระยะทางที่เพิ่มขึ้นเป็นหน่วยๆ อาจฟังดูเหมือนเป็นเรื่องดีสำหรับธุรกิจที่มีการเปลี่ยนแปลงอยู่ตลอดเวลาและยืดหยุ่นตามสถานการณ์ แต่สำหรับผู้พัฒนาระบบแล้ว การเปลี่ยนแปลงฟังก์ชันการทำงานเหล่านี้ล้วนเป็นเรื่องที่ต้องระวังและต้องชี้แจ้งให้ลูกค้าอย่างรวดเร็วตรงไปตรงมา
เสียเวลา
การเปลี่ยนแปลงการทำงานของระบบ ยิ่งถ้าการเปลี่ยนแปลงนั้นเป็นเรื่องที่สำคัญและกระทบกับหัวใจหลักของระบบโดยตรง (อย่างกรณีคิดค่าส่งตามที่ยกตัวอย่างไปข้างต้น) จะทำให้ผู้พัฒนาต้องเปลี่ยนแปลงวิธีออกแบบระบบใหม่ อะไรก็ตามที่เคยวางแผนไปแล้วตั้งแต่วันแรกอาจจะถูกรื้อ หรืออาจจะถูกเอาออกไปเลยก็ได้ หรือบางอย่างไม่เคยคิดถึงมาก่อนว่าต้องมีแบบนี้ก็อาจจะทำให้ระบบไม่เสถียรเหมือนสิ่งที่วางแผนคิดทำตั้งแต่วันแรก
แน่นอนว่าการวางแผนออกแบบระบบให้รองรับกับ requirement ใหม่ หมายถึงการที่ต้องคำนึงถึงกรณีการใช้งาน(use case)ต่างๆเพิ่มขึ้นด้วย และการคิดถึง use case ต่างๆไม่ครอบคลุมนี้เองเป็นต้นเหตุของปัญหาที่เกิดขึ้นกับตัวระบบ สิ่งที่วางแผนเอาไว้ว่าระบบจะสามารถใช้งานได้ภายใน 2 เดือน อาจจะถูกปรับเปลี่ยนให้กลายเป็น 3 หรือ 4 เดือน การให้เวลาที่มากขึ้นสำหรับrequirement ที่มีการเปลี่ยนแปลงถือเป็นเรื่องที่เหมาะสมและควรทำ แต่บางองค์กรกลับมองข้ามปัญหานี้และให้เวลาเท่าเดิมกับทีมพัฒนาในการทำตาม requirement ใหม่ ซึ่งเป็นต้นเหตุของปัญหาที่เกิดขึ้นเมื่อนำระบบไปใช้งานจริง
เสียค่าใช้จ่าย
สำหรับองค์กรหรือหน่วยงานที่ไม่มีนักพัฒนาเองก็อาจจะต้องทบทวนเรื่องต้นทุนของโครงการใหม่ เพราะการเปลี่ยนแปลงขอบเขตการทำงาน(scope) นั้นมักจะมาพร้อมกับค่าใช้จ่ายที่เพิ่มขึ้น หลายคนอาจจะบอกว่า ทำสัญญาไปแล้ว สิ่งที่ว่าจะทำแต่ไม่ได้ทำ แต่เปลี่ยนมาทำอีกอย่างนึงแทนน่าจะทดแทนกันได้สำหรับค่าใช้จ่ายที่เกิดขึ้น ต้องบอกเลยว่าไม่เสมอไปครับ
การทำสัญญาจ้างกันโดยมีเอกสารแนบท้ายไม่ว่าจะเป็น TOR หรือว่าเป็น scope of work อะไรก็ตามแต่ การเปลี่ยน requirement ในเอกสารเหล่านั้นย่อมหมายถึงขอบเขตการทำงานของระบบที่เพิ่มขึ้นหรือลดลงต่างไปด้วย ถ้า requirement ใหม่ที่เข้ามาทำให้นักพัฒนาต้องทำงานน้อยลง ยกตัวอย่างเช่นการตัดฟังก์ชันใดฟังก์ชันหนึ่งออกไป หรือลดทอนความสามารถของตัวงาน ไม่ได้หมายความว่าจะผู้ว่าจ้างจะจ่ายน้อยลงจากที่ทำสัญญากันได้
การลดทอนหรือตัดฟังก์ชันการทำงานของระบบช่วยให้นักพัฒนาสามารถทำงานได้เร็วขึ้น หมายถึงงานสามารถส่งมอบได้ตามกำหนด หรือมีโอกาสที่จะส่งมอบได้ก่อนวันกำหนด ส่วนถ้าจะเอาฟังก์ชันอื่นมาแทนที่ส่วนที่ตัดออกไปแล้วจะมีค่าใช้จ่ายหรือไม่นั้นขึ้นอยู่กับการตกลงของผู้ว่าจ้างและผู้รับจ้างมากกว่า หากประเมินแล้วว่ามีค่าใช้จ่ายมากขึ้นกว่าที่ทำสัญญาเอาไว้ก็ต้องตกลงเป็นเรื่องเป็นราวกันใหม่ว่าจะทำเอกสัญญาเสริมหรืออะไรก็ว่ากันไป
แต่โดยส่วนมากแล้ว การเปลี่ยนแปลงขอบเขตการทำงานที่เกิดขึ้นมักจะเป็นการเพิ่มจากสิ่งที่ตกลงกันไว้มากกว่า ทำให้บางครั้งเกิดความกระอักกระอวนใจระหว่างผู้รับจ้างและผู้ว่าจ้างว่าจะคิดค่าใช้จ่ายกันอย่างไรและจะเพิ่มเวลาที่ใช้มากน้อยแค่ไหน ซึ่งเราคงไม่กล่าวถึงในบทความนี้
แต่ถ้าหากองค์กรที่มีนักพัฒนาภายในของตัวเอง ก็อาจจะต้องคำนึงถึงเรื่องระยะเวลาที่แปรผันกับ requirement ใหม่ที่เข้ามาด้วย บางองค์กรไม่เข้าใจว่าทำไมการเปลี่ยนแปลงฟังก์ชันจึงต้องขยายระยะเวลาการทำงานออกไปทั้งๆที่ “ดูเหมือน” จะแก้ไขเปลี่ยนแปลงไม่มาก และก็ดูไม่ยากจนเกินไปในสายตาคนนอก
จริงอยู่การเปลี่ยนแปลงและความยืดหยุ่นถือเป็นหัวใจสำคัญขององค์กรที่จะสามารถอยู่รอดในปัจจุบันนี้ได้ แต่ก็ต้องย้อนกลับมาถามตัวผู้รับผิดชอบโครงการเองว่า ความท้าทายและความเป็นไปได้นั้นคุ้มค่าพอสำหรับการเปลี่ยนแปลงหรือเปล่า เพราะบางทีอาจจะทำให้สภาพจิตใจหรือพลังใจในการทำงานของพนักงานผู้พัฒนาระบบน้อยลงหรือหมดลงหลังจากที่ได้ทำโครงการนี้แล้ว
และปัญหาเรื่อง turnover ของพนักงานในองค์กรที่บอกว่ากำลังคิดค้นพัฒนานวัตกรรมนั้นก็เป็นปัญหาใหญ่ ถ้าผู้พัฒนาทีมเดิมออกไปแล้วก็อาจจะต้องมานั่งปวดหัวกับการจ้างทีมใหม่เข้ามาสานต่องานเดิม เปรียบได้เหมือนเราจ้างคนมาเขียนหนังสือเล่มหนึ่ง แล้วเกิดวันดีคืนดีคนเขียนลาออกไป ต้องจ้างคนใหม่เข้ามาเขียนหนังสือเล่มเดิม ใครเล่าจะสามารถรู้ลึกถึงเจตนาและอารมณ์ในการเขียนเหมือนกับนักเขียนคนแรก ก่อให้เกิดปัญหาที่ใหญ่ขึ้นตามมาและรอวันอุบัติ เหมือนกับการซ่อนปัญหาเอาไว้มากๆ พอถูกพบเจอหรือเปิดโปงขึ้นมาก็สายไปเสียแล้วที่จะแก้ไข
แล้วต้องทำยังไงหากต้องการเปลี่ยน requirement กลางคัน
แน่นอนว่าโลกปัจจุบันมีการเปลี่ยนแปลงอยู่ตลอด โครงการที่บรีฟข้อมูลกันไปเมื่อ 2 เดือนที่แล้วอาจจะล้าสมัยและต้องเปลี่ยนใหม่ให้ทันคู่แข่งและความต้องการของลูกค้า การเปลี่ยน requirement หรือขอบเขตการพัฒนาระบบนั้นสามารถทำได้ เพียงแต่ต้องอาศัยความเข้าใจในแต่ละขั้นตอนอย่างรอบคอบ ผู้ที่ต้องคอยประสานตรวจสอบดูความเข้ากันได้ของสิ่งที่มีและ requirement ใหม่นั่นก็คงจะเป็นคนที่รับหน้าที่ product owner หรือผู้รับผิดชอบดูแลผลิตภัณฑ์
PO ที่ดี จะช่วยลดงานทั้งฝั่งพัฒนาผลิตภัณฑ์ และการตัดสินใจจากฝั่งลูกค้า
การรับ requirement ต้องให้ความเห็นที่เป็นประโยชน์สำหรับลูกค้า และต้องเป็นประโยชน์สำหรับทีมพัฒนาเองด้วย บ่อยครั้งที่ลูกค้ามักจะถามว่า “แบบนี้ทำได้ไหม หรือเปลี่ยนเป็นแบบนี้แทนได้ไหม” การให้ความเห็นของ PO นั้นจะสามารถไกด์ลูกค้าไปสู่ทางเลือกอันประณีประนอมที่ลูกค้าเองก็พอใจและทำให้ทีมงานไม่จำเป็นต้องลงแรงทำงานหนักเกินความจำเป็นจากขอบเขตงานใหม่ที่เป็นไปไม่ได้ ถ้า PO เข้าใจผลิตภัณฑ์ที่ตัวเองรับผิดชอบดีพอ และเข้าใจในเรื่องของนวัตกรรมหรือเทคโนโลยีได้ดีพอก็จะช่วยป้องกันปัญหาที่อาจจะเกิดขึ้นกับตัวโครงการและตัวองค์กรได้
สรุปเรื่องการเปลี่ยน requirement
ถ้าระหว่างการประชุมนำเสนอไอเดียมีคนจากหลายฝ่ายเข้ามาให้ความเห็นในหลายมุมมอง ไม่ว่าจะเป็นฝ่ายออกแบบ ฝ่ายพัฒนา ฝ่ายการตลาด และฝ่ายบริหาร พร้อมทั้งรับฟังปัญหาที่อาจจะเกิดขึ้นอย่างตรงไปตรงมา และช่วยกันวิจารณ์แก้ไขว่าอะไรดีหรือไม่ดี อะไรที่สามารถทำได้และจะใช้เวลาเท่าไหร่ ความเสี่ยงของโครงการกับเวลาที่เลยผ่านไปเป็นอย่างไร ก็จะช่วยให้การเปลี่ยน requirement กลางคันน้อยลง เพราะสามารถทำให้ทุกคนเห็นภาพเห็นเป้าหมายเดียวกันว่าเรากำลังจะทำโครงการอะไรเพื่ออะไร
แต่ก็ต้องอย่าลืมนะครับ.. ว่าวัฒนธรรมองค์กรก็เป็นเรื่องสำคัญ พนักงานสามารถเสนอความคิดเห็นอย่างตรงไปตรงมาได้หรือเปล่าโดยที่ไม่โดนบทลงโทษ หรือโดนลดทอนสิทธิ์ในการถกเถียง การตอบคำถามนี้ได้ไม่ควรเป็นคำตอบที่มาจากตัวผู้บริหาร แต่ควรเป็นคำตอบจากคนที่ทำงานหรือตัวพนักงานเองมากกว่า ว่าตัวเองมีสิทธิ์มีเสียงในการนำเสนออย่างตรงไปตรงมาแค่ไหน