ทำไม System Analyst ถึงไม่เชื่อ Design จากทีม
บ่อยครั้งที่ผมได้ยินน้อง ๆ ออดส์ทีม (ODT) เล่าว่า งานที่ทำอยู่ไม่ท้าทายเลย เพราะเพียงได้รับ Specification มาจาก System Analyst (SA) หรือ Tech Lead ที่เป็นพนักงาน แล้วน้องก็มีหน้าที่เขียนโค้ดตามนั้นไปอย่างเดียว บ่อยครั้งที่น้องเห็นวิธีการที่ดีกว่าในการแก้ปัญหานี้ แต่พอเสนอไอเดียไปก็ไม่ได้รับการรับฟัง ทุก ๆ ครั้งที่คำแนะนำถูกเพิกเฉย ความรู้สึกเป็นเจ้าของงาน (Ownership) ความคิดที่อยากทำให้มันดี ก็กร่อนลงไปเรื่อย ๆ สิ่งเดียวที่ยังเป็นแรงผลักดันให้ยังสู้และคอยเสนอไอเดียอยู่ คือไม่อยากกลายเป็นเหมือน Outsource บางคนที่หมดไฟแล้ว และทำงานตามสั่งภายใต้ขอบเขตที่รับผิดชอบเท่านั้น
ผมเลยอธิบายให้น้องเข้าอกเข้าใจ SA คนนั้นว่า กว่า Specification จะมาถึงมือของน้อง มันเกิดอะไรขึ้นมาก่อนบ้าง...
กว่าจะเป็นไอเดียที่ "สอบผ่าน"
บ่อยครั้ง ฝ่ายลูกค้าสัมพันธ์ (Customer Support) ได้รับแจ้งปัญหาจากลูกค้า เช่น ความยากในขั้นตอนการ Onboard พอเห็นปัญหาซ้ำ ๆ ก็ไปคิดกระบวนการ Onboard ใหม่ที่ง่ายขึ้นมา หลังจากมั่นใจแล้วว่าไอเดียนั้น Valuable (มีคุณค่า) ก็ไปให้ทีม UX ช่วยลงรายละเอียดดีไซน์เพื่อให้มั่นใจว่าไอเดียนี้ Usable (ใช้งานได้จริง) จากนั้นก็ต้องทำ Presentation เพื่อเตรียมไปของบประมาณกับผู้บริหาร แต่การจะรู้ค่าใช้จ่ายได้ ก็ต้องเริ่มตรวจสอบก่อนว่าไอเดียนี้มัน Feasible (เป็นไปได้ในทางเทคนิค) หรือไม่
วังวนของการประสานงาน
พอเริ่มติดต่อแผนกไอทีเพื่อดูความเป็นไปได้ เจ้าของไอเดียก็ต้องไปถาม Business Analyst (BA) เพื่อหาว่าต้องคุยกับ SA คนไหน กว่าจะนัดประชุมกันได้ เจ้าของไอเดียก็เล่าวิธีการที่ออกแบบมา แต่ปรากฏว่า SA ที่เชิญมาตอบไม่ได้ทั้งหมด เพราะเขาดูแลแค่ Component เดียว ไม่ได้ดูแล Dependency ที่ต้องไปดึงข้อมูลมา และไม่มีข้อมูลว่าระบบอื่นมี API ให้เรียกพร้อมหรือยัง สุดท้ายต้องเลื่อนการประชุมออกไปเพื่อนัด SA จากส่วนอื่นมาเพิ่ม
กว่าจะหาเวลาว่างตรงกันได้อีกครั้งก็ผ่านไปเกือบเดือน ถึงได้รู้ว่ายังไม่มี API เส้นนี้ ต้องไปเติมในเส้นเดิมที่มีอยู่ แต่การเติมเข้าไปก็จะกระทบกับ Product อื่นอีก จนต้องนัดประชุมกับฝ่าย Business Operation ของอีกฝั่งเพื่อตกลงกัน
กว่าจะครบองค์ประชุมและตกลงกันได้ว่าเอายังไงกันแน่ ต้องผ่านการประชุมไม่รู้กี่รอบ จน SA ได้ Final Requirement มาเขียน Specification ว่า Component ของฉันต้องแก้อะไร พอเอามาให้ทีมดู ทีมกลับเสนอวิธีที่ง่ายกว่าเพราะทีมรู้รายละเอียดโค้ดหน้างานมากกว่า
แต่คำถามคือ: ถ้าแก้ตอนนี้ จะกระทบกับใครบ้าง? ต้องกลับไปประชุมอีกกี่รอบ?
ข้อมูลเรื่อง Feasibility ถูกเอาไป Present ผู้บริหารเพื่อตัดสินใจเรื่องงบประมาณมาแล้ว แค่คิดว่าต้องวนกลับไปเริ่มต้นใหม่ ท่ามกลางแรงกดดันหลายเดือนที่ผ่านมา และปัญหาลูกค้าที่ยังบ่นเข้ามาทุกวัน ทำให้ Option ในการปรับ Design ให้ดียิ่งขึ้นนั้น "ไม่ดึงดูด" เอาเสียเลย
ช่องว่างของการสื่อสาร
ในเหตุการณ์แบบนี้ สมาชิกในทีมที่เสนอไอเดียมักจะตำหนิตัวเองว่า "ไม่มีเครดิตมากพอ" ที่จะทำให้ SA เชื่อ เพราะไม่รู้ว่าเบื้องหลัง Specification นี้มีที่มาที่ไปอย่างไร และการแก้ไขมันมีราคาที่ต้องจ่ายสูงแค่ไหน
บางองค์กรแก้ปัญหาด้วยการให้ตัวแทนทีมเข้าประชุมตั้งแต่ต้น แต่บ่อยครั้งทีมก็ไม่ได้สนใจปัญหาธุรกิจเพราะฟังไม่เข้าใจ เลยเลือกย้ายที่นั่งไปทำงานของตัวเองในห้องประชุมแทน พอถึงเวลาถามก็ต้องคอย Recap ใหม่ ทำให้บรรยากาศการประชุมที่ทุกคนต่างรีบเร่งนั้นน่าหงุดหงิด สุดท้ายก็วนกลับไปแบบเดิม คือให้ทีมอยู่ปลายน้ำ และเสียโอกาสที่จะได้รับฟังความเห็นจาก "คนลงมือทำจริง"
ก้าวข้ามเพื่อเป็น "นักแก้ปัญหา"
สำหรับทีมที่ก้าวข้ามความยากนี้ไปจนมีส่วนร่วมในการออกแบบได้ สมาชิกจะเห็นภาพรวมชัดขึ้น เข้าใจกระบวนการธุรกิจมากขึ้น ลดความผิดพลาดในการทำงาน และที่สำคัญคือ ทีมเหล่านั้นจะรู้ว่าสิ่งที่ตัวเองกำลังทุ่มเททำอยู่นั้น กำลังสร้างรอยยิ้มให้ใคร
แต่การจะเปลี่ยนมุมมองจาก "คนเขียนโค้ด" เป็น "คนที่ใช้ความรู้เทคนิคแก้ปัญหาธุรกิจ" เป็นก้าวที่ไม่เล็ก และต้องใช้เวลาในการปรับตัว
สรุป
ที่ผมเอาเรื่องนี้มาแบ่งปัน เพราะผมเห็นสมาชิกในทีมหลายคนตำหนิตัวเองเวลาที่ไม่สามารถจูงใจ SA หรือ Tech Lead ได้ ผมอยากให้มองภาพที่ใหญ่ขึ้นเพื่อให้เข้าใจว่า บ่อยครั้งไม่ว่าไอเดียใหม่จะดีกว่ากี่เท่า แต่ "ค่าใช้จ่ายในการเปลี่ยนรายละเอียด" มันอาจแพงกว่าสิ่งที่ไอเดียใหม่จะประหยัดได้
ถึงมันจะน่าเสียดาย แต่นั่นไม่ใช่เหตุผลที่จะต้องด้อยค่าตัวเอง ในฐานะมืออาชีพ เรามีหน้าที่แบ่งปันข้อมูลและความคิดเห็นอย่างโปร่งใส ส่วนเจ้าของระบบจะเป็นคนตัดสินใจเองว่าเขาจะเลือก "ซื้อ" ไอเดียนั้นหรือไม่ครับ
