สวัสดีครับวันนี้ผมก็จะมาแชร์ประสบการณ์การทำงานตำแหน่ง Business Analyst, UX/UI โปรเจคแรกครับ ซึ่งเป็นตอนต่อจากซีรีย์งาน BA ตอนที่แล้วจากลิงค์ด้านล่างนี้ครับ
บางคนอาจสงสัยว่าทำไมหัวข้อ BA มีคำว่า UX/UI พ่วงมาด้วย ไม่ใช่อะไรครับ พอดีโปรเจคนี้ผมได้ถูก Assign งานมาทำ 2 ตำแหน่งซ้อน ซึ่งบทความนี้ก็เหมาะกับคนที่กำลังสนใจทำตำแหน่ง BA รวมถึงคนที่กำลังทำตำแหน่ง BA ในปัจจุบัน และคนที่อยู่ทีม IT ส่วนอื่นๆก็เหมาะครับ ใครสนใจอยากรู้ว่าตำแหน่ง BA ในโปรเจคทำอะไร ลองอ่านจากประสบการณ์จริงของผมนี้ได้เลยครับผม
“สิ่งที่เรียนรู้จาก BA มีมากมาย เพราะ เราจะเจออุปสรรคใหม่ตลอดเส้นทางแน่นอน”
ข้อท้าวความก่อนนะครับ โปรเจคที่ผมจะเล่านี้เป็นโปรเจคแบบงานด่วนว่าจ้างทำทั้งระบบ ดังนั้น Process การทำงาน จึงอาจพึลึกกึกกือแต่งต่างจาก Process การทำโปรเจคทั่วไป โดย Process การทำ IT Project ของตำแหน่ง BA แบบเต็มสตรีมในองค์กรของผมก็จะประมาณภาพนี้ครับ (ถ้าแบบปกติไม่เต็มสตรีมก็ถึงแค่ทำ User Story เป็นอันจบ)
โดยการเล่าครั้งนี้ผมก็จะเล่าเป็นกระบวนการแบ่งเป็นข้อๆนะครับ เพื่อนๆก็มาดูกันนะครับโปรเจค BA แรกของผม มันผิดเพี้ยนไปจากปกติมากเท่าไร 55+
1) เก็บ Requirement หา As Is กระบวนการทางธุรกิจ
“เขาว่ากันว่าเริ่มต้นดีก็มีชัยไปกว่าครึ่ง “
การเก็บ Requirement เป็นขั้นตอนแรกในการทำงานของ Business Analyst ที่เข้าไปทำการศึกษากระบวนการทางธุรกิจของผู้ว่าจ้างพัฒนาระบบ ซึ่งโจทย์ของ Business Analyst คือทำยังไงก็ได้ในเวลาอันจำกัดให้สามารถเข้าใจระบบ และเก็บ Requirement กลับมาให้ได้มากที่สุด เพราะ การทำงานจริงทั้งผู้ว่าจ้างที่เป็น User และทีมผู้เก็บ Requirement เอง ก็ไม่ได้มีเวลามากกันทั้งสองฝ่าย ซึ่งในขั้นตอนแรกนี้แหละที่จะเป็นขั้นตอนที่วัดความสามารถของ BA ถ้าดีก็จะสบายไปทั้งโปรเจค แต่ถ้าแย่คนที่ตามหลังมาก็จะซวย ไม่ว่าจะเป็น UX/UI, Dev รวมถึงตัว BA เอง ก็ตัวใครตัวมันครับ
หลังจากที่เก็บ Requirement แล้ว สิ่งที่ BA ต้องทำต่อไปก็คือการทำสรุป As Is (กระบวนการทางธุรกิจในปัจจุบัน) และนำเสนอ To Be (ระบบที่จะทำ) เพื่อนำไปใช้ไปร่างหน้าจอระบบ Wireframe คร่าวๆต่อไป ซึ่งแน่นอนว่าต้องใช้ความเชี่ยวชาญ
สำหรับโปรเจคแรกของผมนี้เริ่มต้นมาถึงก็มีอุปสรรคละครับ เพราะ ดันเป็นช่วงโควิด ทำให้การ Meeting และการเก็บ Requirement ทั้งหมดเป็นแบบออนไลน์ และแน่นอนด้วยการที่เป็นออนไลน์ทำให้การเก็บ Requirement ไม่ดีเท่าที่ควร ซึ่งทางที่ดีถ้าให้ผมแนะนำเราควรไปเก็บ Requirement แบบ Onsite ของที่อยู่ผู้ว่าจ้าง เจอแบบ Face on Face เลย คุยทั้งฝั่งบริหาร และลงลึกไปดูการทำงานของฝั่ง Operation ด้วยตัวเอง จะดีกว่ามากครับ เพราะ นอกจากเราจะได้ข้อมูล Insight การทำงานมากกว่าแล้ว เรายังจะได้เห็น Pain จากการทำงานจริงๆของเขา ที่บางครั้งอาจไม่ได้เป็นสิ่งที่ User พูดเอง แต่เป็นสิ่งที่เราสังเกตุเห็นจากการทำงานของเขาครับ
แน่นอนครับ งานงอก เพราะ โปรเจคที่ผมทำ ให้เวลาสั้นกระชับแค่ 3 เดือน พร้อมให้พัฒนาระบบใหม่ที่ยังไม่มีในประเทศไทย อารมณ์แบบ Digital Transformation แน่นอนว่าทีม BA ที่ไปเก็บไม่มี Know How แถมดันเกรงใจถาม + เป็นแบบออนไลน์ ทำให้ข้อมูลที่เก็บไปมาไม่ได้มากเท่าที่ควร และด้วยเหตุนั้น ทำให้ BA ตี Scope ออกมาผิดไปใกล ซึ่งโปรเจคที่ผมทำนี้มีทั้ง “ระบบหน้าบ้าน” (ใช้ขายของให้ลูกค้า) กับ “ระบบหลังบ้าน” (เป็นระบบเบื้องหลังใช้ Config ระบบหน้าบ้าน) โดยแน่นอนว่า เพราะ เป็นโปรเจค Digital Transformation ปกติ User ก็ให้ข้อมูลเยอะแต่ส่วนหน้าบ้านนี่แหละ เพราะ เขารู้แค่นั้น ซึ่งระบบหลังบ้านที่เป็นสิ่งใหม่ BA ควรทำการบ้านมาก่อน และดีไม่ดีควรให้ความสำคัญและให้เวลาคุยหาลือกับ User มากกว่าระบบหน้าบ้านอีกด้วย แต่ครั้งนี้ BA ในโปรเจคผมดันทำผิดพลาดครับ เพราะ เห็น User พูดเกี่ยวกับระบบหลังบ้านน้อย เลยไม่ให้ความสำคัญ และตี Scope ว่าระบบหลังบ้านเล็กนิดเดียว ซึ่งนั่นเป็นสิ่งผิดพลาดใหญ่หลวงครับ บทเรียนนี้จึงสอนให้รู้ว่า ก่อนไปเก็บ Requirement อะไร ควรทำการบ้านมาให้ดีก่อนครับ การเกรงใจไม่มีใน BA ถ้า User ไม่พูด เราต้องเป็นฝ่ายจี้ถาม ซึ่งแน่นอนว่าถ้าเราไม่ทำการบ้านมาก่อน เราก็ไม่รู้ว่าจะถามอะไร และสุดท้ายก็ไปเออออห่อหมกไปกลับ User จนไม่ได้อะไรกลับมา เหมือนกับที่ Steve Jobs เคยกล่าวไว้ว่า “ผู้คนไม่รู้หรอกว่าต้องการอะไร จนกระทัังคุณเอาของให้พวกเขาดู”
อีกเรื่องนึงครับ “การเกรงใจ” บางครั้งก็อาจมาจากโครงสร้างและวัฒนธรรมขององค์กร ซึ่งองค์กรของผมดันเป็นองค์กรที่ใหญ่ และดันมีทีมหลายทีมที่ไม่ใช่ทีมมำงานหลักมาเกี่ยวข้อง อย่างเช่น ทีม Business ที่ไม่ได้อยู่ฝั่ง IT มาช่วยเก็บ Requirement ซึ่งประเด็นคือทีม Business ดันเป็นคนนำทีม IT ที่ทำตำแหน่ง Business Analyst เวลาจะคุยกับ User ทีต้องผ่านทีม Business ที่ไม่ใช่ทีมทำงานหลักก่อน และด้วยสิ่งนี้ทำให้ความเกรงใจของทีม BA เกิดขึ้น โดยวิธีแก้ง่ายๆคือฝ่ายที่ทำงาน หรือ BA ควรเป็น Lead ตั้งแต่เริ่มต้น คุยตรงกับ User แล้วการทำงานจะมีประสิทธิภาพมาก ส่วนทีมไม่ได้ทำงานควรให้เป็นทีม Support เพราะอย่าลืมว่า BA ก็คือเป็นตัวกลางคุยกับ Dev อีกที ยิ่งตัวกลางมากเท่าไร ข้อมูลที่ได้จาก User ก็จะเบาบางมากขึ้นเท่านั้น แต่ถ้าเลี่ยงไม่ได้จริงๆ ทาง BA ก็ควร Communicate กับทีม Business หรือ PM ที่คุยตรงกับ User ให้ได้มากที่สุดครับ
2) ทำ Wireframe เบื้องต้น
อีกหน้าที่ของ BA ที่หลังจากการเก็บ Requirement แล้ว BA ต้องมาร่างหน้าจอระบบ Wireframe เบื้องต้นคร่าวๆให้ทุกฝ่ายทั้งฝั่ง User, Dev, Design เพราะ แน่นอนว่าการเห็นภาพย่อมดีกว่าตัวหนังสือ ซึ่งสิ่งนี้แหละจะเป็นสิ่งที่ทำให้ทุกฝ่ายเริ่มเห็นภาพระบบเป็นภาพเดียวกัน
สำหรับโปรเจคนี้ ผมไม่ได้เป็นคนวาด Wireframe แต่เป็น BA พี่ผมอีกท่านที่เป็นคนใช้ Google Slide วาด ซึ่งประเด็นคืองานที่พี่ BA ทีมผมรับ ดันเป็นระบบหลังบ้าน ที่ไม่ได้ค่อยได้ Requirement อะไรจาก User กลับมา มีแต่ Business Flow คร่าวๆ ซึ่งแน่นอนว่าพี่ BA ที่ผมรับงานที่ไม่รู้ Business อะไร ก็ทำตาม Business Flow แบบผิดถูกผิดตามไปละ ส่วนทีม BA อีกทีมที่ไปรับ Requirement ก็แยกไปทำระบบหน้าบ้านแบบตัวใครตัวมัน ซึ่งประเด็นคือจากการที่คนที่ไปเก็บ Requirement ไม่มืออาชีพและไปตี Scope หลังบ้านว่าเล็ก ตอนทำงานเลยดันดึง Resource คนทำงานไปทำระบบฝั่งหน้าบ้านหมดเลย รวมถึงคนเก็บ Requirement ก็ดันไปทำหน้าบ้านหมดด้วย แล้วดันให้ทีม BA อีกทีมที่ไม่รู้อิโหน่อิเหน่มารับผิดชอบระบบหลังบ้านที่พูดได้ว่ามีความซับซ้อนที่มากกว่าและสำคัญไม่แพ้กัน แทนที่จะส่งคนที่ไปคุย Requirement กับ User ตรงมาช่วยรับผิดชอบระบบหลังบ้านสักคน
ด้วยที่ไม่ค่อย Communicate ระหว่างกัน มองภาพกว้างทั้งระบบไม่ครบ และ Requirement จากต้นเรื่องก็ครึ่งๆกลางๆ สุดท้ายก็ออกมาเป็น Wireframe คร่าวๆบางหน้าจนได้ ซึ่งแน่นอนว่าฝั่งผมที่รับงานมาทำ UX/UI ต่อคงไม่ค่อยปลื้มแน่นอน บทเรียนนี้จึงสอนให้รู้ว่า “Garbage In Garbage Out” อย่าเริ่มโยนขี้ตั้งแต่ต้นทาง เพราะสุดท้าย ขี้ก็เป็นขี้วันยังค่ำ ควรแก้ไขปัญหาตั้งแต่เริ่มต้น ถ้าต้นทางไม่แก้ สุดท้ายก็ต้องมีใครสักคนระหว่างกระบวนการยอมเหนื่อยสร้างตั้งแต่ 0 ใหม่ และ 0 ที่ว่านั้นก็ไม่ใช่มาจาก User ด้วยนะ คิดใหม่กันเองทั้งนั้น
3) ทำ Prototype UX/UI
เป็นสเตปที่ UX/UI Designer รับ Wireframe จากฝั่ง BA มาวาดภาพหน้าจอระบบที่ Dev จะพัฒนาจริงๆละ ซึ่งบางบริษัทอาจจะมีแยกตำแหน่งทำ UX และ UI ไว้คนละคน โดย UX จะเป็นฝั่งที่ควรจะไปเจอ User ตอนไปรับ Requirement กับ BA ด้วย เพื่อทำ User Research ศึกษาวิธีทำงานและ Pain ของ User ส่วนฝ่าย UI เป็นฝั่งที่ต้องประสานงานกับทีม UX และ Dev อย่างมหาศาล เพราะ ฝั่ง UI จะเป็นฝั่งที่รับ Design มาจาก UX และยังต้องรู้พวกข้อจำกัดการใช้ Framework ที่ใช้พัฒนาฝั่ง Front-end ของ Dev แล้วนำมาพัฒนาหน้าจอระบบ Prototype จริงๆให้ Dev อีกที ซึ่งคนทำ UI เก่งๆควรเป็นคนที่ Dev ฝั่ง Front-end เป็นด้วยครับ
แล้วมาเคสโปรเจคของผม ผมได้รับตำแหน่งเป็นอะไรละ ผมได้รับตำแหน่งเป็น UX/UI ควบ ที่รับ Wirefram และ Requirement จากฝั่งพี่ BA ผมอีกที แต่ด้วยอย่างที่บอก “Garbage In Garbage Out” สิ่งที่ผมได้รับมาเป็นสิ่งใช้งานไม่ได้ ทำให้ผมต้องเริ่มใหม่จาก 0 และควบงานอีกตำแหน่งรวมเป็น 3 นั่นคือ BA ซึ่งรายละเอียดการทำงานทุกท่านสามารถติดตามได้ที่บทความด้านล่างที่ผมเคยเขียนเอาไว้ๆในช่วงที่ผมกำลังเริ่มโปรเจคสดๆร้อนๆ
และด้วยเหตุนั้นแทนที่ผมจะได้ไปโฟกัสและใช้เวลากับการทำ UX/UI ผมก็ต้องมานั่งปวดหัวกับการคิด Business ใหม่ให้จบกระบวนการแทน ซึ่งบางคนอาจอาจถามว่าผมทำไมแค่ผมทำตามๆ Wireframe ไปก็จบละ ประเด็น คือ ถ้าทำไปสุดท้ายก็ต้องทำใหม่ครับ เพราะ ปกติการดีไซน์ทั้งระบบทุกอย่างมันต้องเชื่อมกัน แต่สิ่งที่ผมได้มา มันมีหลุมเต็มไปหมด ซึ่งถ้าไม่แก้ไขที่ผม สุดท้ายก็ต้องไปแก้ไขที่ Dev และกลับมาให้ผมดีไซน์ใหม่อยู่ดีครับ
แล้วอย่างงี้ผมไปโฟกัสกับ Business แทนที่จะเป็น UX/UI แบบเต็มที่ แล้วเกิดอะไรขึ้น แน่นอนกฎของการแทนที่ เวลาเท่าเดิม แต่คนต้องเพิ่มงานเป็น 2 ตำแหน่ง คุณภาพของงาน UX/UI ก็ Drop สิครับผม!! แล้วพอ UX/UI Drop ลงไปกระทบใคร ก็ไปกระทบ Dev ต่อไปเป็นลูกโซ่สิ เพราะ แทนที่ Dev จะได้พวก Design System หรือรายละเอียด Pixel ยิบๆจากผมก็ต้องหายหมด ซึ่งในใจตอนนั้นของผม คือ แค่ดีไซน์ระบบให้เดินทางแบบ Happy Path จนจบกระบวนการได้ก็ดีใจท้วมท้นแล้ว
4) ทำ User Story
ขั้นตอนทำ User Story เป็นขั้นตอนที่บอกได้ว่าเป็น Main หลักของงาน BA ที่สุดละครับ ซึ่งมันเป็นขั้นตอนที่ทางทีม BA จะนำพวก Wireframe และพวก Requirement มาจัดสรรเขียนเรื่องราวไว้ในเล่มทั้งหมด เพื่อส่งต่อให้ทาง UX/UI Design, Dev และ Tester ไปทำต่อทั้ง ซึ่งศาสตร์การเขียน User Story นี้ก็เป็นทักษะสำคัญของ BA เช่นกัน โดยโจทย์ของ BA คือ ทำให้ยังไงก็ให้เขียนออกมาแล้วทุกฝ่ายเข้าใจให้ได้มากที่สุด โดยก็จะมีหัวหน้างานเป็นคน Review ซึ่งสิ่งนี้แหละบางครั้งอาจเป็นอุปสรรคที่ยากที่สุดของการทำ User Story เพราะหัวหน้าแต่ละคนที่ Review ก็จะมีพื้นฐาน Background ไม่เหมือนกัน และอาจมีพื้นฐานในการเข้าใจการทำงาน Dev น้อยก็ได้ ซึ่งถ้าน้อย แล้วเป็นคนเคี่ยวๆ จะเป็นปัญหามากครับ เพราะ เราจะต้องลงเวลาไปแก้งานกับสิ่งที่ไม่ควรลงเวลาไปกับการแก้ และสุดท้ายสิ่งที่ส่งมอบให้ Dev ก็จะเป็นสิ่ง Dev อ่านไม่รู้เรื่องและไม่ตรงความต้องการ เพราะ เราลงไปลงเวลากับสิ่งที่ไม่ควรหมดแล้วครับ สิ่งที่ได้ออกมาก็จะเหมือน Meme คลาสสิคตามรูปครับ
มาดูโปรเจคแรกที่ผมทำ User Story ดีกว่า ถ้าเพื่อนๆอ่านย่อหน้าเมื่อกี้ไปนะครับ เพื่อนๆอาจจะสะกิตใจว่า เอ๊ะ เราต้องทำ User Story ก่อนทำ UX/UI Design นี่ แต่นี่เรา Design ไปแล้วนี่หว่า ใช่แล้วครับ โปรเจคนี้ของผมมันผิดเพี้ยน มันให้ UX/UI Design นำไปให้ Dev เลย แล้ว User Story ค่อยตามมา
ผลเป็นอย่างไร User Story แก้กระหน่ำสิครับ แถมพวก Business Rule ก็ตกหล่นเยอะพอสมควร ซึ่งเป็นที่น่าแปลกใจ ผมที่ทำ UX/UI ก็ต้องมาทำ User Story ช่วยพี่ BA เพิ่มให้อีกด้วย แต่ก็ดีครับถือว่าเป็นประสบการณ์ ซึ่งแน่นอนหลังจากที่มีการทำ User Story ก็มีการแก้หน้าจอ UX/UI ระบบเพิ่มครับ พร้อมกับ Requirement ใหม่เพิ่มมาเยอะแยะ โดยสิ่งนี้ก็เป็นการใช้สกิล BA อีกละ ถ้าเริ่มต้นไม่ดีก็แก้เยอะครับ แถมพอเริ่มไม่ดีแล้ว ความไว้ในเชื่อใจของ Dev ก็จะลดลง เป็นอุปสรรคทำงานต่อไปครับ (พอ Dev ไม่เชื่อ ระบบที่พัฒนาออกมาก็จะกลายเป็น Dev นำ ไม่ใช่ Business นำ อันนี้ไม่โอเครแน่นอนครับ)
บทเรียนครั้งนี้คือการทำงานมันไม่ได้เป็นไปตามขั้นตอนทางทฤษฏีเสมอไป ตอนทำงานจริงเราอาจจจะต้องมีข้ามขั้นตอนไปมา ซึ่งเราต้องยืดหยุ่นปรับตัวให้ได้ครับ
5) ทำ SIT (System Integration Test)
SIT เป็นขั้นตอนการ Test ระบบภายในหลังจากที่ Dev พัฒนาเสร็จเรียบร้อย ซึ่งขั้นตอนนี้จะเป็นหน้าที่ของหลักของ Tester และ Dev ครับ โดยทาง Tester ก็จะอ่านรายละเอียดระบบที่พัฒนาจาก User Story ของ BA และ Test ตามนี่แหละ ซึ่งถ้าไม่ได้ตาม Story ทาง Dev ก็ต้องทำการแก้เพิ่มครับ
เพื่อนๆจะเห็นได้ว่าโปรเจคครั้งนี้ของผมมีเวลาสั้นมาก และก็เจอปัญหาตั้งแต่ต้นทาง กว่าจะถึงมือ Dev ก็เหลือเวลาแค่ 1 เดือนก่อน SIT ซึ่งจะทันได้อย่างไร โดยของจริงนี่ผมก็แปลกใจ เพราะว่า Dev ก็ทำทันครับ แล้วทำได้อย่างไร ง่ายๆครับ Back to Basic จ้าง Outsource ระดมคนเพิ่มสิครับผม บทเรียนนี้สอนให้รู้ว่าเราสามารถแก้ไขปัญหาด้วยเงินได้ครับ 55+ (แต่ฝั่ง Dev ก็ต้องมี Lead ที่ดีด้วยนะครับ ถ้างั้นจะมีแต่ Quantity ไม่มี Quality)
หลังจากที่ทีม Dev พัฒนาระบบไปค่อนข้างไปได้ใกลแล้ว ถึงจะยังไม่เสร็จ 100% แต่ก็ต้องเริ่มทำ SIT ละ เพราะใกล้ถึงเวลา Go Live (โปรเจคอื่นผมก็เชื่อว่า Nature เป็นอย่างนี้เช่นกัน มีส่วนน้อยที่สมบูรณ์ 100% แล้วค่อย SIT) ซึ่งแน่นอนครับ ด้วยเวลาเร่งรีบและก็ไม่ได้เริ่มต้นดีตั้งแต่เริ่มต้น Bug ก็กระจายสิครับ
แล้วด้วยที่ Head ของ Tester เป็นคนที่กำลังจะเกษียณ และมีลูกมือที่เป็น Outsource แค่ 2 คน แน่นอนครับว่า BA ต้องเข้ามาช่วย Test อีก รวมถึงผมด้วย
โดยขั้นตอนนี้แหละจะเป็นสิ่งที่วัดเลยว่า BA เขียน User Story และ Communicate กับทางทีม Dev เพียงพอหรือเปล่า โดยเราต้องเข้าใจว่าคนแต่ละคนมีความคิดไม่เหมือนกัน แค่ BA ยังมองไม่เหมือนกันเลย แน่นอนว่า Dev ก็คงตรัสรู้เองเพียงจากการอ่าน 100% ไม่ได้แน่นอน ซึ่งในเคสของผมก็ไม่ตรงค่อนข้างเยอะครับ โดยอันที่ Dev ทำไม่ตรง และ Dev ไม่ยอมปรับตาม ก็ต้องมาปรับ Design Pattern ให้ตรงกันใหม่หมด เพราะบางครั้งการปรับจุดนิดเดียว มันกระทบเป็นลูกโซ่ทั้งกระบวนการครับ ซึ่งสาเหตุหลักก็คือการ Communicate กันไม่เพียงพอนี่แหละ พอจบใครงานใครก็งานมัน พอเจอปัญหาทีหลังค่อยมาโวยวาย โทษกันไปกันมากัน ดังนั้นบทเรียนนี้ คือ ทุกฝั่งควร Communicate กันให้เยอะที่สุดครับ อย่าแยกเป็นทีม Dev ทีม Test ทีม BA เราควรมองว่าทุกทีมอยู่ใน Project เดียวกันครับ
6) ทำ UAT (User Acceptance Test)+ User Manual
ขั้นตอนสุดท้ายก่อน Go Live คือการ Test ให้ผู้ว่าจ้างลองใช้ระบบที่พัฒนา รวมถึงมีการ Training การใช้ระบบ โดยถ้ามีระบบส่วนไหนพอใช้แล้วไม่ตอบโจทย์ธุรกิจ หรือมีเงื่อนไขไม่ตรงกับตอนว่าจ้าง ก็ต้องมีการกลับไปแก้ไขก่อนไป Go Live รวมถึงมีการเพิ่ม CR กรณี User มี Requirement เพิ่มเติมครับ
สเต็ปนี้ผมไม่ได้ไปลง UAT กับ User ครับ แต่สิ่งที่ผมได้ทำเพิ่มเติมคือการทำ User Manual ระบบ ซึ่งนับได้ว่าเกือบทำทั้ง Project จริงๆ โดยการทำ UAT ครั้งนี้ก็ไม่ได้สวยงามครับ แต่ก็ไม่ได้ย่ำแย่ เพราะ ผมโชคดี Design การใช้งานระบบไปแบบกว้างๆ เพื่อให้ลองรับการใช้งานแปลกๆได้ทุกเคสครับ ซึ่งบทเรียนนี้สอนให้รู้ว่า ถ้า Requirement ไม่กระจ่าง อย่าดีไซน์ระบบที่มัดมือชก User ครับ
ส่วนฟี้ตแบ๊คอีกอย่างหนึ่งได้จาก User คือสเต็ปการใช้งานครับ เพราะ การทำงานของผมในโปรเจคนี้เป็นแบบ Waterfall ทำเสร็จทีเดียวไปให้ User ดู ซึ่งแน่นอนการที่ทีมเราคุยกับ User น้อย ผนวกกับการที่ผมฝั่ง Design ไม่ได้เข้าไปคุยกับ User เลย นั่นทำให้เราเข้าใจการทำงานของ User ไม่เพียงพอและสุดท้ายก็ต้องมานั่งปรับแก้ไขสเต็ปการทำงานกันไปให้ตรงกับกับทำงานของ User ภายหลังอีกที นั่นก็เป็นอีกบทเรียน คือ นอกจากฝั่งภายในที่เราต้อง Communicate กันให้ดีแล้ว ฝั่ง User เราก็ต้องพยายาม Communicate กับเขาให้ได้มากที่สุดด้วยครับ ไม่ใช่สุดท้ายพอเจอปัญหา ก็มานั่งบ่นและนั่งนินทาโยนความผิดกันไปกันมาเหมือนตามที่เคยกล่าวมาครับ
7) Go Live
ขั้นตอนสุดท้าย แต่ไม่รู้ท้ายสุดหรือเปล่า ถ้าเป็นโปรเจคที่ Perfect กระบวนการก็จะจบเพียงเท่านี้ครับ แต่ถ้าเป็นโปรเจคใหญ่ๆ ก็มีอาจต่อ Phase 2 และถัดๆไป ส่วน Project ที่ไม่เรียบร้อยนั้น BA ก็ต้องมานั่งเก็บ Defect และ CR จากระบบเพิ่มเติม จนกว่าจะเป็นระบบที่ใช้งานได้ครบสมบูรณ์จริง (ส่วนนี้ก็ขึ้นอยู่กับเขียน MOU ต้นโปรเจค และการเจรจาด้วยนะครับ ซึ่งถ้าฝั่งผู้พัฒนาทำไม่ตรง requirement 100% ซึ่งส่วนใหญ่ก็ไม่ตรงหมดอยู่แล้วแหละ แล้วถ้าเจรจาไม่ดี ก็ต้องมานั่งแก้ระบบต่อไปยาวๆครับ)
ส่วนระบบโปรเจคแรกของผมนี้แม้จะ Go Live ไปแล้ว สุดท้ายก็ยังไม่จบครับ เพราะ ยังมีต่อ Phase 2 ซึ่งก็ต้องมาลุ้นกันครับว่าจะเป็นอย่างไรต่อไป
สรุปส่งท้าย
เป็นอย่างไรบ้างครับกับบทเรียน Business Analyst, UX/UI งานแรกของผม เอาจริงนะครับผมอยากจะแชร์มากกว่านี้อีก แต่พอดีว่าเขียนแค่นี้ก็ปาไปเกือบ 1,000 words แล้วครับ เกรงว่าจะยาวไปสำหรับเพื่อนๆเกิน จึงขอหยุดไว้เพียงเท่านี้ และขอสรุปเป็น Bullet ต่อท้ายเพิ่มเติมนี้แทนละกันครับ โดยสิ่งที่ผมว่าสำคัญที่สุดเลยสำหรับ BA เลยรวมถึงคนอื่นๆในโปรเจคด้วย คือ การ Communicate กันครับ เป็นสิ่งง่ายๆที่ทุกคนทำได้ แต่ค่อยไม่ยอมทำกัน จนบางครั้งเขาว่ากันเป็นยาขมของฝ่าย IT เลย ยิ่งเป็น BA ที่ทำต้นทางนี้ยิ่งต้องพยายาม Communicate กันให้เยอะเลยครับ แม้ฝ่ายอื่นไม่เข้าหา เราก็ต้องเป็นฝ่ายเข้าหาเอง ซึ่งสิ่งนี้จะทำให้ทุกคนทำงานกันเป็นทีม เจออุปสรรคในโปรเจคอะไรเราก็จะสามารถผ่านไปด้วยกันได้ทุกคนครับผม
- ทุกฝั่งควร Communicate กันให้เยอะที่สุดครับ อย่าแยกเป็นทีม BA, Design, Dev, Test เราควรมองว่าทุกทีมอยู่ใน Project เดียวกัน รวมถึงฝั่ง User ด้วย
- ฝ่ายที่ทำงานอย่าง BA ควรเป็น Lead และให้ฝ่ายอื่น Support
- BA ควรลง Onsite ไปเก็บ Requirement เจอ User เอง และพาฝ่าย Design ไปด้วย
- ก่อนไปเก็บ Requirement เจอ User ควรทำการบ้านมาให้ดีก่อน ยิ่งเป็นเรื่องใหม่ที่ User ไม่รู้ และเราต้องไป Consult ให้
- Garbage In Garbage Out ถ้า BA เริ่มดีไซน์ไม่ดีตั้งแต่ต้นทาง ฝ่ายอื่นที่รับงานต่อก็จะโดนผลกระทบเป็นลูกโซ่ และต้องมีคนมาเสียสละรับชะตากรรมแทนเสมอ
- ควรกระจาย Resource คนทำงานให้ Balance กัน โดยระบบหลังบ้าน มีความสำคัญไม่แพ้หน้าบ้าน แค่ระบบหน้าบ้านมันใช้ขายของกับ User ได้ดีกว่าเท่านั้นเอง
- การทำงานมันไม่ได้เป็นไปตามขั้นตอนทางทฤษฏีเสมอไป เราต้องการยืดหยุ่นได้เสมอ
- ถ้า Requirement ไม่กระจ่าง อย่าดีไซน์ระบบที่มัดมือชก User
- พยายามทำทีมให้มี Power และมีความน่าเชื่อถือ อย่าทำเป็นทีม BA ลูกเมียน้อยที่ยอมทีมอื่นไปทุกอย่าง ซึ่งวิธีแก้ง่ายๆคือการเป็นมิตรจากการ Communicate กับทุกฝ่ายให้ดีตั้งแต่ต้น
- อย่าโยนความผิด ตีหน้าซื่อ นินทาลับหลังกันไปกันมา ทุกคนคือทีมเดียวกัน
P.S. บทความนี้ที่เขียนเป็นงานของ BA แบบ Project นะฮะ ถ้าเป็นงานแบบ Enhance จากระบบเดิม เรื่องพวก Process, Design จะสบายๆ ไม่ต้องใช้ความคิดไรมาก เหมือนตัวสไตล์งาน Project ที่อธิบายในบทความนี้ฮะ ก็ลองดูครับถ้าเรามีสิทธิ์เลือกได้ ถ้าอยากสบายหน่อยก็เลือกงาน BA ที่ทำงาน Enhance ฮะ แต่ถ้าอยากได้ประสบการณ์ไวๆก็ให้เลือกทำงาน Project เลย ส่วนผมนะหรอ ทำคู่ครับ งาน Project เป็นงานหลัก พร้อมควบงาน Enhance ทำพร้อมกันประมาณ 3–4 งาน ฮะ 😂😂
