คุณเคยสร้างระบบโดยไม่มี workflow standard รึเปล่า ?
บางคนอาจจะคิดว่าเคย บางคนก็คิดว่าไม่เคย… แต่จริงๆแล้วทุกๆระบบย่อมมี workflow ของมันนะ ไม่ว่าระบบมันจะเล็กขนาดไหนก็ตาม อย่างน้อยที่สุดก็ต้องมี start — > process — > end และไม่ว่าองค์กรณ์ไหนๆก็คงมี standard อะไรบางอย่างเพื่อให้สื่อสารกันได้
แต่จากประสบการณ์หลายต่อหลายครั้งที่ได้ทำงานกับหลายๆ project มักจะเห็นคนมองข้ามเรื่องของ workflow แล้วไปสนใจกันที่กิจกรรม หรือ process ย่อยๆกัน แต่สุดท้ายก็ต้องแก้ปัญหาปะผุเอาตอนที่ร้อยเรียง flow การทำงานเข้าด้วยกัน
บาง project ตอนเก็บ requirement กับ user ก็มี workflow นะ แต่ไม่ทันเรียบเรียงให้ดี ก็รีบเอามาตีความเป็น flow ที่แยกกันคิดไปซะ เพราะห่วงว่าโครงการจะไม่คืบหน้า หรือไม่มีงานแจกให้ dev เพราะมัวแต่ design หรือบางทีก็เห็นไปแปล flow ของ business ให้เป็น flow diagram แบบของตัวเอง ซึ่งมันก็ไม่ผิด แต่สุดท้ายก็จะติดกับคำบ่นว่า business กับ dev คุยกันคนละภาษา
ยิ่งถ้ามันถูกจัดเป็น defect เพราะไม่ตอบโจทย์ตาม business flow นี่ก็พาให้เถียงกันยาวได้เลย เพราะอาจเกิดความสับสนว่าตรงไหนใน flow diagram ของ dev เทียบได้กับตรงไหนใน workflow ของ business และมันถูกแปลไปอย่างถูกต้องจริงๆรึเปล่า
เราลองมาดูตัวอย่างปัญหาที่ทำให้เกิดความสับสนอย่างที่เล่าไว้ข้างต้นดู ว่าเกิดขึ้นได้ยังไง…
Business Owner วาด flow ด้วย power point บอกว่าอยากได้ระบบที่แยกการทำงานเอกสารระหว่างทีม A, B , C, D, E โดยคนที่เริ่มสร้างเอกสาร ได้คือ A, B, C แล้วต้องส่งไปตรวจที่ D หากเป็นการตัดสินใจที่เกินอำนาจของ D จะต้องส่งไปให้ E ถ้า E ต้องการข้อมูลเพิ่มให้คนที่ส่งงานหามาส่งเพิ่ม แต่พนักงานทีม D และ E เค้าทำงานอยู่ที่ระบบอื่น
พอ developer พูดคุยซักถามกับฝ่าย business จบแล้ว ก็ไปคิด spec สำหรับระบบตัวเอง จนเกิดเป็น flow diagram แบบนี้ออกมา
ซึ่ง diagram ตัวอย่างที่ได้มา จริงๆมันก็มีกิจกรรมครบถ้วนสำหรับระบบสีฟ้าที่คิดตาม requirement ที่แกะออกมาจาก diagram ของ business user แล้วนะ เพราะเค้าพัฒนาระบบสำหรับส่วนสีฟ้าไม่ใช่ระบบสำหรับส่วนสีม่วง จึงสนใจเรื่องของระบบสีฟ้าเป็นหลัก และส่วนที่ติดต่อมาจากระบบสีม่วงเค้าก็คิดรวมมาให้แล้ว แต่… คุณคิดว่า นอกจาก dev ที่ทำระบบสีฟ้าแล้ว ใครบ้างที่ได้รับเอกสารชิ้นนี้แล้วจะเข้าใจว่าส่วนไหนคือตรงไหนของ flow ที่ business user พูดถึง หรือลองคิดอีกแบบว่าถ้าทีมกระจายงาน โดยส่งเอกสารนี้ให้ business analyst ไปคุยกับ user เค้าจะสามารถเอาไปอธิบายให้ business user เข้าใจได้ไหม ว่าทำถูกต้องตาม flow ที่ user ให้มายังไง และมันบอกตรงไหนว่าใครเป็นผู้ทำกิจกรรมตรงไหนได้บ้าง
จากตัวอย่างข้างต้นที่เล่ามา มันก็ชวนให้เกิดคำถามว่า มันจะดีกว่ามั๊ยล่ะถ้าเราจะสามารถเขียน flow เดียวที่ใช้คุยได้ทั้ง business และ dev ไม่ต้องเสียเวลาแปลงกลับไปกลับมาเพื่อคุยกันอีก ?
อันที่จริงก็มีความพยายามแก้ปัญหานี้มานานแล้ว และก็เคยมีการออกมาตรฐานเป็น open standard กันมากว่าสิบปีแล้ว แต่จากที่เคยทำงานมาก็หลายปีก็ไม่ค่อยได้พบ project ไหนที่นำมันมาใช้เป็นพิมพ์เขียวในการพัฒนา software เพื่อคุยกันระหว่าง dev และ business ให้เป็นภาพเดียวกัน
จากตัวอย่างข้างต้น คราวนี้เราลองมาดูว่าถ้าเปลี่ยนไปวาดด้วย standard workflow diagram ดูว่าจะเป็นยังไง
Workflow Diagram แบบนี้ก็สามารถระบุกิจกรรมได้ครอบคลุมเหมือนที่ user แจ้งมาให้ และก็ยังแสดงรายละเอียดได้ครบทุก state ของเอกสารเหมือนที่ diagram ก่อนหน้านี้ระบุ อีกทั้งยังคงแสดงให้เห็นถึงระบบทั้งสองที่ต้องติดต่อกัน และบอกได้ว่ากิจกรรมไหน ต้องให้สิทธิ์บทบาทไหน หรือผู้เกี่ยวข้องไหนบ้าง ที่ต้องเข้าไปทำงานในแต่ละกิจกรรม
จะเห็นได้ว่า Workflow Diagram นั้นสามารถรักษาข้อมูลไว้ได้จากทั้ง 2 มุม และยังเป็นการขยายรายละเอียด flow จาก user ให้เห็นถึงรายละเอียดปลีกย่อย กิจกรรมย่อยๆที่จะทำให้เกิดข้อมูลตามที่ user ต้องการ
ทีนี้ลองคิดเล่นๆดูว่าถ้าเกิดต้องอธิบายกระบวนการทำงานให้ user ฟังเพื่อให้แน่ใจว่าเราตีความการทำงานได้ตรงตามที่ได้รับฟังมา คิดว่า workflow diagram จะช่วยได้มากกว่า flow diagram อันแรกหรือไม่
จากที่ยกตัวอย่างมา เชื่อว่าน่าจะพอทำให้เข้าใจประโยชน์ของการใช้ workflow standard มากขึ้นแล้ว และเชื่อว่าหลายคนก็คงเห็นด้วยที่จะนำมันมาใช้เป็นพิมพ์เขียวเพื่อสื่อสารกับ business owner และ development team โดยไม่ต้องไปเหนื่อยวาด flow หลายๆแบบ ทำให้ให้ต้องสลับอ่าน สลับคิดไปๆมาๆอีกแล้ว เราจะได้เก็บแรงและเวลาไปทุ่มเทแก้ปัญหาที่แท้จริงใน code กันดีกว่า
และสำหรับตอนหน้าเราจะมาดูรายละเอียดตามมาตรฐานของ workflow diagram กัน เพื่อจะได้ลองนำไปใช้กันต่อไป
