ทำไมต้องให้และขอ
สำหรับบทความนี้จะเขียนในมุมมองของ Dev ถึง Requirement ว่ามันควรบอกอะไรเราบ้างและบทความนี้ก็อยากจะให้ความรู้เกี่ยวกับผู้ที่จะจ้างงาน Dev หรือบริษัทเกี่ยวกับ IT ว่าเวลาที่จะให้ Requirement เนี่ยควรจะให้ไปแบบไหนเพื่อให้มันชัดและเข้าใจจะได้ไม่ต้องเสียเวลาบอกไปแล้วกลับมาบอกใหม่ หรือทำไปแล้วมาดูแล้วไม่ใช่ต้องแก้กันไปแก้กันมาจนหัวเสียทั้งสองฝ่าย บางกรณีฟ้องร้องกันยิ่งใหญ่
โปรดใช้วิจารณญาณในการอ่าน
ออกตัวก่อนเลยว่าผมเป็นแค่โปรแกรมเมอร์ธรรมดาทำงานในบริษัทธรรมดาเล็กๆไม่ใหญ่มากเหมือนพวก REUTERS, IBM, Agoda, Microsoft, ThoughtWorks หรือบริษัทข้ามชาติใหญ่ๆมากมายในโลก ดังนั้นสิ่งที่ผมเขียนเป็นประสบการณ์กระโหลกกะลาในการทำงานในช่วง 4 ปีที่ผ่านมาว่าเจอ Requirement แบบไหนมาบ้างดีกว่า
งาน Service หรือ งาน Project
อย่างแรกเราต้องแยกกันก่อนว่างาน Service กับ งาน Project นั้นแตกต่างกัน ต้องเข้าใจมันก่อน เพราะมันมีผลกับการจัดการ Requirement ไม่ว่าจะเอามาทำไหม หรือวิธีการได้มาซึ่ง Requirement
งาน Service
คืองานที่สร้างขึ้นมาเพื่อให้คนอื่นเข้ามาใช้ ลูกค้าอาจจะใช้หรือไม่ใช้ก็ได้ งานพวกนี้ทำขึ้นมาเพื่อให้คนจำนวนมากใช้ ส่วนใหญ่ Requirement จะมาจากบริษัทที่สร้าง Service หรือว่าง่ายๆคิดเองแหละว่าอะไรดี หรือไม่ดี ทำออกไปแล้วดู Feedback ของลูกค้าแล้วมาเป็น Requirement ใหม่เพื่อมาปรับแก้ไขตามความสมควรของเจ้าของ Service ว่าง่ายๆว่าเจ้าของ Service มีสิทธิ์ตัดสินใจว่าจะเอาแบบไหน ลูกค้าทำได้มากสุดคือส่ง Feedback มาบอก ถ้าคุณเป็นลูกค้ารายใหญ่ก็อาจจะมีปากมีเสียงเยอะหน่อย แต่ก็อย่าหวังว่ามันจะไปตามที่คุณต้องการ 100 เปอร์เซ็นต์เพราะ Service ต้องออกแบบรองรับคนที่มาใช้ที่มากมายหลากหลายดังนั้นมันต้องรักษาความกลางๆยืดหยุ่นไว้ ไม่สามารถ Customize ให้คนใดคนหนึ่งได้ เจ้าของ Service จะต้องคิดคำนวณว่าควรทำอะไร เปลี่ยนอะไร เพื่อให้ Service ของตัวเองมีคนใช้เยอะที่สุด ตัวอย่าง Service ที่มีให้เห็นในปัจจุบัน Google drive, Gmail, Youtube, Facebook, IG
งาน Project
คืองานที่มีคนจ้างให้ทำเขามี Requirement บ้างแล้วว่าอยากได้อะไรทำอะไรได้บ้าง แต่เป็น Requriment แบบลมๆกล่าวคือมันไม่เฉพาะเจาะจงอะไรเลย เช่น มีระบบ Tracking พอฟังแบบคนทั่วไปก็จะแบบลมๆตรงไหน แต่ถ้าเป็นคนที่เขียนโปรแกรมนี่จะบอกว่า Tracking นี่ยังไง Tracking ผ่านหน้าเว็บ ผ่านมือถือ หรือ โทรมาถาม หรือ ส่งจดหมาย ข้อมูลต้อง Realtime ระดับไหน จะ Tracking ด้วยอะไร เลข Tracking หรือชื่อคนทำงาน หรืออะไร งาน Project พวกนี้จะเป็นการต้องคุยเพื่อทำให้ Requriement ลมๆพวกนี้ดูชัดเจนขึ้น ดูเป็นของจริงมากขึ้น เอาไปสร้างจริงได้ งานพวกนี้จะ customize ขนาดไหนก็แล้วแต่กำลังทรัพย์และกำลังคนของฝั่งจ้างและฝั่งถูกจ้าง แต่ขอให้คิดเสมอว่า Requirement หรือ Change ต่างๆมี Cost เสมอ ไม่ว่าจะเป็นเงินหรือเวลา ตัวอย่างเช่น Project ภาครัฐต่างๆที่มี TOR มาเล่มใหญ่ๆแต่ไม่บอกอะไรที่เจาะจงเป็นภาพ (UI คร่าวๆยังไม่มีเลย) ตัวอย่าง งานสร้างระบบ TCAS ของภาครัฐที่เป็นประเด็นมาล่าสุด
แตกต่างแล้วยังไง
ถ้าเรากำลังทำ Service ขอให้คิดเสมอว่า Requriement ต่างๆมีผลกระทบกับคนที่มาใช้เกือบทุกคน ดังนั้นการจะทำอะไรต้องคิดให้ถี่ถ้วน การทำอย่างนึงอาจเพิ่มยอดขายให้คนกลุ่มหนึ่ง แต่มันอาจทำลายผู้ใช้งานกลุ่มอื่นๆ
ถ้าเรากำลังทำ Project เราควรเข้าไป Clear Requriement ต่างๆที่ลมๆให้เป็นของที่จับต้องได้ พยายามให้ Clear ที่สุดเพราะการที่ Requriement ไม่ชัดเจนส่งผลในการพัฒนาและต้องแก้ไปแก้มาดังที่กล่าวไปข้างบน
Requirement ที่ดีคืออะไร
Requirement ที่ดีมันพูดยากนะว่าคืออะไรมันเหมือนเรื่องความดีคืออะไรแต่ละที่มันไม่เหมือนกัน แต่ละที่ แต่ละโซนเวลา แต่ละจักรวาลไม่เหมือนกัน เอาเป็นว่า Requirement ที่ Dev อยากได้มีอะไรบ้าง โดยส่วนใหญ่จะยกเป็นตัวอย่างที่เคยเจอ
วาด Flow status
ปกติลูกค้าที่มาจ้างคือเขาจะมาจ้างให้เราเปลี่ยนงานที่ทำแบบกระดาษสมัยก่อนเลยมาทำเป็นแบบดิจิตอลเพื่อลดการกรอกข้อมูลลงกระดาษแล้วก็ต้องมากรอกลง Digital บางทีต้องกรอกอะไรซ้ำๆ เขารำคาญเลยมาจ้างให้ทำเป็นแบบ Digital กัน คราวนี้เวลาเราไปขอ Requirement หรือ คุณเป็นบริษัทแล้วจะไปให้ Requirement อยากให้ลองวาดรูป Flow status ขึ้นมาครับ
คือจริงๆหลักการมันไม่มากมายอะไรให้ลองวาด status ของงานหนึ่งงานที่เราทำ อย่างตัวอย่างของผมมันคืองานรับส่งเอกสารจากระบบหนึ่งเข้ามาตรวจสอบและกรอกข้อมูลเพิ่มเติมก่อนส่งไปให้ระบบอื่นครับบ งานหนึ่งงานของผมก็เริ่มจากมันมีสถานะ New คือมันเข้ามาในระบบ จากนั้นจะมีคนมารับงานไปทำแล้วเปลี่ยนสถานะเป็น Received และเปลี่ยนสถานะไปต่างๆนาๆตามเหตุการณ์และการกระทำของผู้เกี่ยวข้องในระบบ ที่อยากให้วาดมันขึ้นมาเพราะ ทั้งฝั่งคนให้ Requriement และคนรับงานจะได้เริ่มเห็นว่าระบบที่เรากำลังจะทำเนี่ยมันกำลังทำอะไร การเปลี่ยนสถานะต่างๆมันเกิดขึ้นจากอะไรได้บ้าง ถ้าตามหลักเคยเรียนใน Software engineering เขาจะให้วาด Usecase diagram
แต่ส่วนใหญ่งานที่ผมเคยเจอ use case เกือบ 80 เปอร์เซ็นต์มันไปอยู่กับการกระทำการตัวงานที่ทำให้มันเปลี่ยนสถานะไปมาแล้ว (เนื่องจากเป็นงานในระบบเล็กๆที่อยากแปลงกระดาษให้เป็น Digital)
จากการวาด Flow status ไปแล้วนั้นจะทำให้เราเห็นการกระทำต่างๆที่กระทำต่องานหนึ่งงาน Status ของงานว่ามี Status อะไรบ้าง จุดไหนเป็นจุดสิ้นสุด วาดไปวาดมาบางทีไปเจอ Status หลุมดำซึ่งก็คือ Status ที่เข้าไปแล้วออกมาไม่ได้ทั้งที่งานนั้นยังไม่เสร็จสิ้นกระบวนการ หรือบางทีเราจะเห็นกระบวนการที่ในทางกระดาษจำเป็น แต่ทาง Digital ไม่จำเป็น หรือ บางทีเราอาจได้ขั้นตอนการทำงานแบบใหม่ที่ตอบโจทย์มากกว่าที่เป็นก็ได้ อีกทั้งสิ่งนี้มันยังทำให้เกิดคำถามระหว่างคนขอและคนให้ เช่น บาง Status มันไปแล้วกลับไม่ได้เลยแบบนี้มันคือความจริงเหรอ แล้วถ้ามันต้องกลับจะต้องทำยังไง เชื่อเถอะครับ มันมี Exception พวกนี้อยู่เสมอ ดังนั้นเราควรถามแต่เนิ่นๆว่าถ้ามันเกิดขึ้นจะต้องทำยังไง หรือ ขั้นตอนนี้มันจะมีคนมาดูจริงๆเหรอ เช่น ระบบหนึ่งเป็นระบบนำเข้าส่งออกข้อมูลเป็นล้านชิ้นแต่ต้องมี step approve ซึ่งก็คือต้องใช้คนระดับผู้ตัดสินใจได้มาตัดสินใจงานนับล้านชิ้นผมว่ามันโคตรไม่ Make sence เลยว่าไหม มาทำระบบ IT เพื่อลดงานแต่ใช้คน Approve เอกสารเป็นล้านอันตลกไหมล่ะ
นี่คือหนึ่งใน Requirment ที่ Dev อยากได้เพราะมันทำให้ Dev เห็นว่าระบบงานมี Status อะไรในระบบบ้าง ใครเข้ามายุ่งกับระบบบ้าง ซึ่งเวลา Dev มีคำถามเขาก็สามารถถามตรงจุดที่ Status ต่างๆหรือการกระทำใดๆเป็นจุดๆได้เลย เขาไม่ต้องมานั่งมโนว่ามันจะมีใครมายุ่งบ้าง Flow มันเป็นยังไง เพราะคุณเอาสิ่งที่เขาต้องมโนกลับมาจากปากลูกค้าแล้ว (ผมขอให้คนที่เอา Requirement ลองถามและ Confirm กับลูกค้าจริงๆ ไม่ได้เอาเองมโนนะครับ) แค่นี้ก็ช่วยลดเวลาในการศึกษา Business ของลูกค้าไปได้เยอะเลยทีเดียว
ตัดจบก่อนละกัน
สำหรับตอนนี้เหมือนจะพูดยาวเกินไปแล้วเดี๋ยวจะพาเบื่อกันซะเปล่าๆ สำหรับตอนหน้าอาจเป็นเรื่อง Report หน้า Search หรืออื่นๆ ตามแต่ที่อยากเขียน
วิดีโอประกอบการเขียน Blog
ดูแล้วอิจฉาน้อง NICO ที่ไปเที่ยวกรุงโซลจริงๆ