3 roles, 2 bots ใน 1 คน

Mizusora
EMIT Stories
Published in
2 min readApr 16, 2021

แชร์การทำงานต้นน้ำยันปลายน้ำ พร้อมมุมมองของทั้ง Analyst, Dev, ยัน QA

ตำแหน่งงานปัจจุบันของเราคือ Analyst

เนื้องานหลักๆก็คือการประสานงานไปมาระหว่าง business และ developer รวมไปถึงวิเคราะห์ requirement หรือหา root cause

ส่วนนึงของงานเราก็คือการทำ QA (Quality Assurance) ไปในตัว เพราะเราต้องทำ internal test เอง บวกกับดูแลเรื่อง deployment ต่างๆตามระบบที่บริษัทได้วางไว้

ส่วนงาน developer เป็นของแถมที่ได้มา เนื่องจาก bot ตัวที่ 2 ในแพลนนั้นมีความไม่สมดุลระหว่าง resource และ timeline เราที่เคยโค้ดมาก่อนก็เลยเข้าไปรับหน้าแทน

เป็นการทำงานที่เหมือนเราเดินวนๆที่เดิม 3 รอบด้วยมุมมองที่ต่างกันออกไปตามเลนส์ “หน้าที่” ที่สวมใส่ วันนี้ก็เลยอยากมาแชร์แต่ละมุมมองในแต่ละขั้นตอนให้ฟังกัน

⚠️ เตือนไว้ก่อน นี่เป็นแค่ประสบการณ์ส่วนตัว ในโปรเจ็คที่มีลักษณะเฉพาะเท่านั้น ถ้าโปรเจ็คอื่นที่สเกลแตกต่างจากนี้ก็จะมีรายละเอียดอื่นๆที่ไม่ตรงกันนะ

Project’s scope

โปรเจ็คนี้เป็นการสร้าง RPA (Robotic Process Automation) เพื่อให้ bot ทำงานแทนมนุษย์ในส่วนที่มีเนื้องานที่ซ้ำๆและปริมาณมาก bot จะรับข้อมูล input จาก user, ทำการตรวจสอบข้อมูลผ่าน validation criteria ต่างๆ แล้วจึงเข้า SAP ไป process transaction ตามที่ได้โปรแกรมไว้ ซึ่งทีมเราจะใช้ UiPath Orchestrator ในการพัฒนาและสั่งงาน bot

เราไม่ได้ทำ bot ที่ฉลาดและซับซ้อนอะไรแบบนี้หรอก lol (photo from pexels)

Requirement Analysis

ตอนเริ่มโปรเจ็ค เราก็ทำงานตามประสา Analyst ทั่วไป พอเรารู้ process ที่เค้าอยากจะ automate แล้ว ก็เริ่มประชุม พูดคุย เจาะลึก detailed process กับ user จริงๆ เพื่อให้เข้าใจ manual process ที่เค้าทำ ก่อนจะเริ่มตีโครงออกมาว่าจะปรับเปลี่ยนรายละเอียดต่างๆยังไงให้มันสามารถกลายเป็น automation process ได้

👶 Analyst: ควรระวังเรื่อง scope งอกเหนือ timeline ควรให้ business เตรียมข้อมูลเก่าที่เคยทำงานไว้เยอะๆเพื่อเป็นหลักฐานในการต่อรอง ถ้าเริ่มคุยลงดีเทลไปที่เคสหนึ่งเคสใดให้รีบชิงเปรียบเทียบ % ที่จะเกิดขึ้นจริงแล้วประเมินความคุ้มค่าที่จะทำร่วมกัน

👩 Dev: พยายาม involve กับขั้นแรกๆให้ได้มากที่สุด ถ้าเข้าประชุมไม่ได้ให้ catchup ข้อสรุปหรือการเปลี่ยนแปลงที่เกิดขึ้น เพราะบางอย่างที่คนอื่นรู้สึกว่ามันเป็น common logic อาจจะเป็น tool limitation ที่ทำได้ยากมากๆก็เป็นได้

👵 QA: จับตามองรายละเอียดต่างๆที่คุยกันระหว่างประชุมให้ดี ทางที่ดีคือขอตัวอย่างข้อมูลมาสำรองไว้จะทำให้เทสได้ง่ายขึ้นเยอะ

Process Planning

พอเก็บ requirement คร่าวๆมาได้แล้ว เราจะสามารถวางแผนได้ดีขึ้นว่าแต่ละส่วนจะใช้เวลาประมาณเท่าไหร่ ถึงจริงๆส่วนใหญ่ที่เจอคือ user มาพร้อมกับ timeline ในใจแล้วก็ตาม…

👶 Analyst: ทำหน้าที่เป็นคนกลางระหว่างทั้งสองฝั่ง พยายาม balance ให้ดีระหว่าง business impact และ technical constraint การวาง timeline คร่าวๆ วาง checkpoint ให้สองฝ่ายได้มาคุยกันจะทำให้ติดตามงานได้ง่าย

👩 Dev: ขั้นตอนนี้จะสามารถต่อรอง-โยกย้ายแผนการทำงานได้ง่ายที่สุดแล้ว ถ้าทำการบ้านกับ analyst มาดีพอ เราสามารถชี้แจง limitation ต่างๆแล้วตัดทอนส่วนที่ไม่สำคัญออกเพื่อให้ plan ดูสมจริงยิ่งขึ้น

👵 QA: ในการต่อรองขั้นตอนนี้ จะสามารถแยกแยะส่วนสำคัญ-ไม่สำคัญได้ การจดบันทึกจะช่วยให้เราเอาไปใช้กับการลิสต์ known issue ในภายหลัง

Process Design

เมื่อสรุป process โดยรวมแล้ว ขั้นตอนต่อไปคือการ document ออกมาเป็น step-by-step ชี้แจงขั้นตอนการทำงานของ bot โดยละเอียด ครอบคลุมทั้งสิ่งที่ bot ทำได้และทำไม่ได้ หลังจากนั้นก็ให้ Business approve เป็นหลักฐาน ขั้นตอนนี้จะทำให้เสร็จก่อนค่อย dev หรือจะทำไปพร้อมๆกันก็ได้ เพราะมันยังเป็นแค่ initial draft ในการเขียนบอทจริงๆอาจจะมีการแก้ไขปรับปรุง ซึ่งพอจบ deliver ถึงจะอัพเดท final documentation อีกที

👶 Analyst: ไม่จำเป็นต้องทำเหมือน manual process เป๊ะๆ พยายามหาทางลัดหรือการดึงข้อมูลจากหลังบ้านแทนเพื่อเพิ่มความเสถียรและลดเวลาให้กับ bot

👩 Dev: การมีความรู้ใน system ใดๆที่ bot ต้องทำงานบนนั้นจะช่วยให้ทำงานง่ายขึ้น พยายามลองหา API หรือ library ใดๆมาช่วยลดความซับซ้อนของแต่ละขั้นตอน

👵 QA: คอยสังเกตความเปลี่ยนแปลงต่างๆในการเขียนบอท การดึง API, Library ต่างๆมาใช้ย่อมมีข้อจำกัด ศึกษาและเตรียม test script รอเอาไว้ได้เลย

Implementation & Test

ต้องเขียนอะไรเยอะแยะล่ะ ทำงานค่ะทำงานนน

👶 Analyst: เตรียม test data ของแต่ละเคส รวมถึงประสานงานกับฝั่ง business เพื่อเตรียมข้อมูลจริงในการทำ UAT รวมถึงการเจาะหาเคสที่เป็น business scenario ซึ่งฝั่ง IT อาจจะไม่ได้รู้มาก่อน

👩 Dev: เขียนโค้ด จบ 5555555+
หลอกๆ ทักษาเฉพาะตัวเราว่าไม่ต้องพูด แต่จะเพิ่มเรื่องการอัพเดท analyst เวลามีการเปลี่ยนแปลงใดๆเพื่อวิเคราะห์ผลกระทบร่วมกัน แล้วถ้าเจอเคสหรือ limitation อะไรพิเศษก็ให้ QA ลิสต์เก็บไว้เทสภายหลังเพื่อความแน่นอน

👵 QA: ลิสต์ความเป็นไปได้ต่างๆ ทั้งการทำ data validation, การใช้ API/Library, business scenario ที่เกิดขึ้นได้ ทำงานควบคู่กับ Analyst เพื่อที่จะลดทอนเคสที่ไม่เกิดขึ้นจริงลงไป ทำงานร่วมกับ dev ในการทำ test ไปจนถึงการ list known issues หากการแก้ไขเป็นไปได้ยากหรือดูไม่คุ้ม effort เพื่อนำไปคุยในขั้นตอนถัดไป

UAT & Deploy

เมื่อผ่านการตรวจสอบคุณภาพจากฝั่ง IT แล้ว ก็จะต้องกลับไปหา user และทำ UAT (User Acceptance Test) เพื่อเป็นการ confirm final product รวมไปถึง final document ที่จะสรุปรวบยอดทุกอย่างและทำการ business approve เป็นหลักฐาน เมื่อทุกอย่างลงตัวสมบูรณ์แล้ว ก็ deploy ขึ้นระบบจริงแล้วเตรียมใช้งานกันได้เลย

👶 Analyst: คล้ายๆขั้นตอน planning ถ้าเราขลุกอยู่กับ Dev และ QA มากพอ เราก็จะเข้าใจ limitation ต่างๆ และสามารถนำมา balance กับ business impact เพื่อพิจารณาการแก้ไขและผลกระทบกับ timeline ต่อไปได้

👩 Dev: ช่วงเวลาการส่องประกายของผลงาน อาจจะมีช่วยประเมินเวลาที่จะต้องใช้ในการแก้ไขสิ่งใดๆตามที่ business ขอมาบ้าง เมื่อทุกอย่างผ่านแล้วก็ทำการ deploy ได้เลย เนื่องจากเราใช้ orchestrator ในการทำงาน การ deploy ก็เลยใช้ตาม service ที่เค้ามีให้ได้เลย

👵 QA: Known issues ที่ลิสต์เอาไว้จะมีประโยชน์มากๆ ทีมจะเห็นแล้วว่าในเวลาที่เหลืออยู่ มีอะไรบ้างที่อยากแก้หรืออะไรที่ยังไม่ต้องแก้ตอนนี้ก็ได้ ลิสต์จะเก็บไว้เป็นทั้งยันต์ป้องกันภัยในอนาคต แล้วก็อาจจะเป็น to-do list ในการ planning ครั้งต่อไปด้วยเช่นกัน

และนั่นก็คือการทำงานคร่าวๆของ RPA Project ที่เราทำมาตลอดครึ่งปีที่ผ่านมา จะเห็นว่าตัวฝั่ง technical เองจะไม่ซับซ้อนอะไรมาก ที่ยุ่งยากจะเป็นการ simplify process ให้เป็นมาตรฐานสำหรับ bot กับการติดต่อประสานงานไปมาซะมากกว่า ส่วนตัวรู้สึกว่าถ้าแบ่งงานกันดีๆ ทำงานไปด้วยกันเป็นทีมก็น่าจะแข็งแกร่งอยู่พอตัว

แต่พอรวมทุก roles มาอยู่ในคนเดียว ความอ่อนล้าที่ต้องทั้งประสานงานไปมา ทั้งคิดหา solution ดีๆเพื่อความเสถียร ไม่รวมถึง learning curve ที่เจอ ก็ทำให้หนักหนาสาหัสอยู่เอาเรื่อง แต่ส่วนที่หนักมากๆสำหรับเราจริงๆก็คือการที่ต้องคิดเองทำเองเทสเองนั่นแหละ เราไม่มี second opinion หรือ outside viewpoint มาช่วยจี้จุด ช่วง UAT เลยค่อนข้างยือเยื้อเพราะต้องให้ฝั่ง user แจงเคสแปลกๆที่ไม่เคยเจอมาให้แทน Analyst หรือ QA

ก็ถือว่าเป็นอีก challenge ที่ดีที่ทำให้เรามองเห็นภาพรวมมากขึ้นนะ

แต่ถ้าให้แนะนำ…ก็ไม่จำเป็นต้องลองหรอก 😂

--

--