Speed, Errors, Satisfaction ตัวชี้วัดความสำเร็จของซอฟต์แวร์
สองตัวชี้วัดที่เป็นที่รู้จักกันทั่วไปในแวดวง HCI คือ user performance (speed & errors) และ user satisfaction
user performance นั่นเป็นการวัดในเชิงปริมาณ ส่วน user satisfaction เป็นการวัดเชิงคุณภาพค่ะ
ดิฉันเคยตั้งคำถามกับตัวเองไว้นานแล้วว่า สำหรับระบบที่มีความซับซ้อนอย่างมาก ถ้ามีระบบหนึ่งที่ดูแล้วท่าทางจะใช้ยากมากแต่ความเร็วเป็นเยี่ยม กับอีกระบบหนึ่งที่ช้ามากแต่ดูน่าใช้และดูเข้าใจได้ง่าย ระบบใดจะประสบความสำเร็จก่อนกัน
อย่างที่ทุกท่านได้ทราบมาโดยตลอดว่า KnowledgeVolution ระบบ KM ที่เราพัฒนาขึ้นและได้ติดตั้งในหลายเว็บไซต์ ได้แก่ GotoKnow.org, Learners.in.th, Researchers.in.th พัฒนาขึ้นโดยพื้นฐานที่เน้นผู้ใช้เป็นศูนย์กลาง ซึ่งหมายความว่า features ต่างๆ เป็นที่ต้องการของผู้ใช้ ผู้ใช้เห็นประโยชน์ และผู้ใช้รู้สึกว่าใช้งานได้ง่าย และด้วยสิ่งต่างๆ เหล่านี้เป็นส่วนหนึ่งที่ทำให้จำนวนผู้ใช้ GotoKnow.org เพิ่มขึ้นอย่างรวดเร็วในหนึ่งปีที่ผ่านมา
จนกระทั่ง GotoKnow มาถึงปัญหาคอขวด คือ ศักยภาพของเครื่องแม่ข่ายที่ไม่สามารถรองรับจำนวนผู้ใช้ได้พร้อมกันจำนวนมากๆ จึงทำให้ระบบช้าอย่างมาก แต่ด้วยการติดบล็อก ก็จะมีผู้ใช้จำนวนหนึ่งพยายามใช้อย่างทรมานหัวใจ รวมทั้งตัวดิฉันเองด้วย และด้วยความช้าของระบบทำให้เกิด errors ขึ้นหลายครั้งเมื่อทำการบันทึกลงบล็อก หรือบางครั้งก็เกิดขึ้นกับส่วนอื่นๆ ด้วยเช่นกัน
สิ่งที่ทีมงานเราต้องทำช่วงนั้น คือ ต้องพยายามเค้นพยายาม optimize ระบบในเชิงเทคนิคอย่างถึงที่สุด และเมื่อระบบกลับมาเร็วได้ระยะหนึ่ง จำนวนผู้ใช้ก็เพิ่มทวีคูณขึ้นอีก จนทำให้ปัญหาความช้ากลับอีกครั้ง
ดิฉันมานั่งคิดว่า ถ้าระบบเป็นระบบที่ใช้งานได้ยากตั้งแต่แรกเริ่ม ซึ่งหมายถึง ออกแบบมาโดยไม่สนใจผู้ใช้เลย แม้จะไม่มีปัญหาความช้าใดๆ เลยก็ตาม ดิฉันก็คิดว่า ระบบจะไม่สามารถประสบความสำเร็จได้ เพราะ developer model กับ user model จะขัดแย้งกันอย่างสุดขั้ว พาลทำให้เกิด errors ในการใช้งานบ่อยครั้ง ยกเว้นระบบเล็กๆ และระบบที่ผู้ใช้ถูกบังคับให้ใช้ตามสายงานนะค่ะ
สรุปแล้ว lessons learned ที่ดิฉันได้รับจากการพัฒนาระบบ KnowledgeVolution คือ ต้อง balance goals ทั้งสองอย่างให้ดีค่ะ ทั้ง user performance และ user satisfaction
ความเห็น (8)
เห็นด้วยค่ะว่าระบบที่ดีจะต้องทั้งเร็วและใ้ช้ง่าย และเห็นด้วยที่ว่าการใช้ง่ายอาจจะสำคัญมากกว่าเร็วโดยเฉพาะในระยะแรกที่เริ่มต้นที่เปิดบริการใช้ระบบ
นอกจากนี้สิ่งที่ควรคำนึงถึงคือการทำระบบให้ตรงกับความต้องการจริง ๆ ของผู้ใช้ ดังจะเห็นตัวอย่างเกี่ยวกับระบบค้นหาเว็บที่ประสบความสำเร็จที่สุดซึ่งก็คือ google จริง ๆ มี search engine ก่อนหน้านี้ แต่ส่วนใหญ่มักจะเป็น web portal ด้วย มีข้อมูลและโฆษณาเยอะมาก ใช้ก็ยาก โหลดก็ช้า คนจึงติดใจ google เมื่อ google web page มีแต่ช่องให้ใส่ข้อมูลที่ต้องการค้นหาและปุ่มที่คลิกเพื่อให้ระบบเริ่มการค้นหา
ขอบคุณ อาจารย์กานดา ที่เข้ามาเสริมค่ะ เห็นด้วยอย่างยิ่ง
อย่าง Google นี้แหละค่ะ เรียกได้ว่า สำเร็จได้ด้วย simplicity หรือ less is more นั่นเองค่ะ
ขอบคุณครับ ;)
แล้วดิฉันจะเขียนเกี่ยวกับความเป็น simplicity ให้อ่านค่ะ
ปล. ว่าแต่คุณป้อมหายหน้าหายตาไปไหนค่ะ ไม่เข้ามา GotoKnow บ้างเลยนะค่ะ :)
อาจารย์เชื่อว่า คุณ มะปรางเปรี้ยว มีประสบการณ์สั่งสมไว้เยอะจากทำงานด้านการ system testing
อยากให้อ่านแล้วช่วยต่อยอดความรู้ให้อาจารย์ด้วยนะค่ะ
ประเทศไทยเราจะได้มีนักพัฒนาระบบที่เข้าใจเรื่อง user-centered system development มากขึ้นค่ะ
Thanks :)
จะรออ่าน simplicity ครับ...
เป็น topic ที่น่าสนใจครับ. มี article ที่น่าสนใจไม่นานมานี้ครับ จาก Don Norman เกี่ยวกับ Simplicity. http://www.jnd.org/dn.mss/simplicity_is_highly.html
แต่ในความเห็นของผม Simplicity มันมาในหลายรูปแบบ. Is more about a harmony of characteristics than a low number of charactersitics. มีจำนวน features น้อยลงไม่ได้หมายได้ถึง Simplicity เสมอไป. Put the right control & content at the right time น่าจะอธิบายได้ดีกว่า
Narin J.
Human Factor Engineering Specialist, Sprint Nextel Corp.