ถ้าอยากรู้จักใครจริง ๆ อย่าฟังแค่ที่เขาบอก แต่ให้สังเกตสิ่งที่เขาทำ
เรื่องนี้ไม่เว้นกระทั่งงานวางระบบในองค์กร การรวบรวมความต้องการ (requirement) โดยการสัมภาษณ์ หรือรับฟังความคิดเห็นจากผู้ใช้ เป็นเพียงเงื่อนงำบางส่วนของความต้องการที่แท้จริง บางครั้งการร้องขอสว่าน เพราะนั่นคือเครื่องมืออย่างเดียวที่เขารู้จัก เนื่องจากไม่รู้ว่ายังมีเครื่องมืออื่นที่ใช้เจาะรูได้
ระยะหลังเมื่อมีผู้ใช้โปรแกรมมากขึ้น ผมไม่สามารถพบหรือทำความรู้จักกับรายไหนเป็นพิเศษ อาศัยทำงานร่วมกับ "ทีมพัฒนา" ทำหน้าที่เป็นผู้พบปะดูแลผู้คนเหล่านั้น ทำความเข้าใจกับธรรมชาติธุรกิจและขั้นตอนงาน แล้วมาถ่ายทอดให้กับทีมที่ทำงานเบื้องหลัง
วิธีการทำงานของทีมพัฒนา เริ่มจากเก็บข้อมูลโดยอาศัยการสัมภาษณ์ สังเกตการณ์ และถ้าเป็นไปได้ขอเข้าไปลองทำงานหน้าที่ต่าง ๆ เพื่อให้มีประสบการณ์จริง เรียกว่าต้องมือเปื้อน หรือสวมรองเท้าของเขา (in someone's shoes) เพื่อทำความเข้าใจข้อจำกัดและปัญหาของผู้ปฏิบัติ
เมื่อมาประชุมร่วมกัน หัวหน้าทีมมีภาพของเป้าหมายใหญ่ที่รับนโยบายมาจากผู้บริหารและสังเกตการณ์จากภาพรวม โปรแกรมเมอร์ช่วยให้ข้อมูลทางเทคนิคว่าโปรแกรมสามารถทำเรื่องไหนได้ หรือไม่ได้อย่างไร และทีมพัฒนาที่มีข้อมูลในภาคสนามระดับรายละเอียด ข้อเท็จจริงทั้งหมดนี้ถูกนำเข้ามาพิจารณาจุดอ่อน จุดแข็ง ความพร้อม รวมถึงประเมินปฏิกิริยาตอบรับของผู้ใช้ว่าต่อต้านหรือร่วมมือ เพื่อหาแนวทางออกแบบระบบที่น่าจะเป็นไปได้มากที่สุด
กิจการแต่ละแห่งไม่ว่าจะทำธุรกิจคล้ายกันแค่ไหน แต่คนที่เป็นผู้ใช้โปรแกรมในนั้นไม่เหมือนกัน วัฒนธรรม การให้คุณค่า ทัศนะคติแตกต่างกัน จุดอ่อนจุดแข็งไม่เหมือนกัน กลยุทธการวางระบบจึงไม่มีสูตรสำเร็จตายตัว สำหรับทีมพัฒนาแล้ว การอ่านคน ทำความเข้าใจคน เป็นทักษะที่ยากกว่าการทำความเข้าใจโปรแกรมและออกแบบระบบงาน
ข้อจำกัดของทีมพัฒนา เมื่อวางระบบลงตัวและใช้งานได้แล้ว ก็จะต้องถอนตัวไปทำงานให้รายอื่น เปลี่ยนเป็นโหมดเฝ้าระวังห่างกว่าเดิม ไม่สามารถสังเกตได้ใกล้ชิดเหมือนกับตอนขึ้นระบบใหม่ บางครั้งเมื่อเกิดปัญหาหรือความไม่สะดวกที่เล็กน้อย แล้วไม่มีฟีดแบคจากผู้ใช้มาก็ไม่อาจทราบได้ เรื่องเหล่านั้นจึงมาไม่ถึงทีมโปรแกรม
เมื่อปีที่แล้ว ผมมีคำถามเกี่ยวกับผลงานที่ผ่านมา กับลูกค้าที่ใช้โปรแกรมมานานหลายปี เราได้ปรับปรุงเปลี่ยนแปลงไปหลายอย่างตามวันเวลา ทำอย่างไรจึงจะรู้ว่างานที่เคยทำไว้เดิมมีส่วนไหนที่ยังใช้อยู่ หรือส่วนไหนเลิกใช้ไปแล้ว
โดยเฉพาะคำถามว่ามีรายงานไหนที่ไม่ใช้แล้ว ไม่มีใครตอบได้อย่างมั่นใจ ถ้าจะให้ไล่ถามผู้ใช้แต่ละคนก็เป็นการออกแรงที่มากโดยไม่จำเป็น แล้วอาจจะได้คำตอบว่า ทุกวันนี้ทำงานส่วนไหน ใช้รายงานอะไรบ้าง นั่นคือเท่าที่เขานึกออก แต่อาจจะไม่ครบถ้วน การรวบรวมข้อมูลเพื่อให้ได้ข้อสรุปน่าจะยุ่งยาก แถมยังเชื่อถือไม่ค่อยได้
ก็เลยคิดทางออกด้วยวิธีทางโปรแกรม เพิ่มโค้ดเล็ก ๆ เข้าไปทำหน้าที่เป็นมิเตอร์นับจำนวนติดไว้ทุกรายงาน ทุกครั้งที่ผู้ใช้เรียกรายงานก็จะบันทึกบวกคะแนนนับเอาไว้ รายงานไหนได้คะแนนมากแสดงว่านิยมมาก และก็ได้รู้ว่าอาจจะมีบางรายงานที่ไม่มีคะแนนเลย แสดงเป็นรายงานที่ไม่มีใครใช้อีกแล้ว
ในที่สุดก็สรุปออกมาได้ หลังจากปล่อยให้โปรแกรมจดคะแนนอย่างเงียบ ๆ มาเกือบปี จะเห็นว่ามีงานเก่าหลายชิ้นไม่มีใครใช้แล้วจริง ๆ เรียกว่าจำนวนมากพอสมควร บางรายงานทำมาเพื่อใช้ทดสอบชั่วคราว บางรายงานเพียงทำมาเผื่อไว้แล้วก็ไม่มีโอกาสได้ใช้ งานหลายชิ้นสามารถเคลียร์ออกไปได้ ลดความเทอะทะโดยไม่ต้องเสียเวลาสอบถามผู้ใช้
ปัญหาต่อมา สมมติว่านับคะแนนสะสมไปเรื่อย ๆ มีรายงานที่เคยใช้มากเมื่อปีที่แล้ว แต่มาปีนี้เพิ่งเลิกใช้ จะรู้ได้อย่างไร เพราะรายงานที่ได้คะแนนสูงอาจเพราะมีแต้มบุญเก่าสะสมมาเยอะ บางรายงานที่คะแนนน้อยกว่าอาจมีการใช้งานต่อเนื่องก็ได้ ตัวเลขสูงต่ำยังใช้บอกอะไรไม่ได้ชัดเจน
แก้ไขโปรแกรมอีกครั้ง ปรับวิธีนับคะแนนใหม่ ให้ reset ตัดรอบเริ่มนับหนึ่งใหม่ทุกเดือน กลายเป็นคะแนนที่มีกรอบเวลาสะสมแค่หนึ่งเดือน เพราะเราต้องการรู้ว่ามีรายงานไหนบ้างที่ยังเรียกใช้อยู่ปัจจุบัน มิเตอร์ที่นับคะแนนของทุกรายงานจะมี session ปีเดือนกำกับว่า ครั้งสุดท้ายที่นับเข้ามาเป็นของเดือนไหน
ผลพลอยได้อีกด้านหนึ่ง ถ้าเปลี่ยนเป็นจัดลำดับตามคะแนนสูงสุด ก็จะได้รู้ว่ารายงานไหนมีความสำคัญ ทุกเดือนมีปริมาณเรียกใช้มาก อาจมีผู้ใช้หลายคน หากสามารถปรับปรุงให้ดียิ่งขึ้น เช่น เร็วขึ้น มีรายละเอียดครบถ้วนขึ้น ก็มีผลต่อความรู้สึกผู้ใช้มากกว่า รายงานที่เรียกใช้น้อย หรือมีผู้ใช้ไม่กี่คน
ข้อได้เปรียบของโปรแกรมบนคลาวด์ ทำให้ผู้ดูแลสามารถทำความเข้าใจผู้ใช้ และปรับปรุงคุณภาพให้ดีขึ้นเรื่อย ๆ ผ่านการวัดค่าโดยไม่ต้องรอให้ร้องขอ ผมเชื่อว่าโปรแกรมที่ดี ก็คือโปรแกรมที่ไม่ได้หยุดนิ่ง คอยปรับปรุงแก้ปัญหาความไม่สะดวกเล็ก ๆ น้อย ๆ เหมือนกับรู้ใจผู้ใช้ ซึ่งเบื้องหลังก็เริ่มต้นมาจากข้อมูลและสถิติการใช้งานของผู้ใช้เองนั่นแหละ ที่ทำให้รู้ว่าควรโฟกัสให้ปรับปรุงส่วนไหนก่อน
Comentarios