ผู้ ใช้ twitter จำนวนมากบ่นถึงสถาณการณ์ที่ช่วงนี้ระบบล่มบ่อยเหลือเกิน และถึงแม้จะกู้ระบบคืนมาแล้ว แต่ก็ยังมีการจำกัดฟีเจอร์บางอย่างอยู่ เพื่อลดโหลด เช่นปิดการใช้งานร่วมกับ IM หรือไม่สามารถดู timeline ย้อนหลังไปกว่าหน้าปัจจุบันได้

สิ่งที่น่าหงุดหงิดไปกว่านั้นก็คือ การที่ทาง Twitter ไม่ได้ออกมาสื่อสารกับผู้ใช้มากเพียงพอว่า เกิดอะไรขึ้น และกำลังทำอะไรอยู่ คาดว่าจะเสร็จเมื่อไหร่ คืออยู่ๆ ก็ใช้งานไม่ได้เสียเฉยๆ หรือความสามารถเดิมที่เคยใช้อยู่ อ้าววันนี้ปุ่มนี้มันหายไปไหนเสียละ

ความจริงก็คงบ่นอะไรมากไม่ได้นักหรอกครับ ก็ใช้ของเขาฟรีนี่นา แต่ผมมองย้อนกลับมาถึงการให้บริการ IT ภายในองค์กร ไม่ว่าคุณจะให้บริการแบบ in house หรือจะ outsource ก็ตาม สิ่งที่ควรจะมีเป็นอย่างยิ่งคือ Service Outage Communication เรียกง่ายๆ ว่าเตรียมไว้เลย ถ้าระบบมีปัญหา เราเตรียมการที่จะสื่อสารกับผู้ใช้อย่างไร

Service Outage Communication ควรมีลักษณะดังนี้

  1. ครอบคลุมช่องทางที่สามารถติดต่อกับผู้ใช้ได้ แน่นอนครับ คงไม่มีใครพยายามส่งอีเมล์เพื่อที่จะบอกว่าอีเมล์ใช้งานไม่ได้หรอก เพราะผู้ใช้ก็คงไม่ได้รับอีเมล์แจ้งอยู่ดี แต่ในบริการบางอย่าง ที่มีช่องทางเข้าถึงได้หลายช่องทาง การสื่อสารให้ครบทุกช่องทางจะช่วยได้มาก ตัวอย่างเช่น ผู้ใช้ m.twitter.com จะไม่มีทางรู้ได้เลยว่า Pagination service ใช้งานไม่ได้ ถ้าไม่ได้เข้าไปดูในเว็บ สิ่งที่เขาเห็นก็เพียงแค่ ปุ่มลิงค์ Next หายไปเท่านั้นเอง ถ้า Daily Sales Report มีปัญหาไม่สามารถ publish ได้ เราอาจจะจำเป็นต้องผู้ใช้ ทั้งทาง Intranet homepage และทางอีเมล์ หรือถ้าระบบเน็ตเวิร์คมีปัญหา วิธีที่ควรใช้คือการประกาศทาง PA (Public Announcement) แทนที่จะรอให้ผู้ใช้ทุกๆ คนรุมกันโทรเข้ามาถามที่ Helpdesk
  2. เนื้อหาของการสื่อสาร ต้องใช้สั้น กระชับ แค่รู้ว่าระบบใช้งานไม่ได้ก็แย่พอแล้ว ยังต้องมาให้นั่งอ่านอีเมล์ยาวเป็นหน้าๆ ที่อ่านแล้วก็ยังไม่รู้ว่าเกิดอะไรขึ้น และที่สำคัญกว่านั้นคือ ไม่ได้ตอบคำถามสำคัญที่ว่า “แล้วเมื่อไหร่ถึงจะใช้ได้ละเนี่ย?” เนื้อหาควรจะแบ่งเป็นส่วนๆ เรียงลำดับตามความสำคัญดังนี้
  • หัวเรื่อง ถ้าเป็นอีเมล์ ใส่ไว้เป็น subject เลยว่า อะไรใช้งานไม่ได้ ผู้ใช้ส่วนมากแค่ต้องการรู้ว่า ปัญหาที่เกิดขึ้น ไม่ได้แค่เกิดกับฉันคนเดียวเท่านั้นนะ
  • What: คล้ายกับหัวเรื่อง แต่อาจมีรายละเอียดเพิ่มเติมให้ชัดเจนและเจาะจงกว่าที่อยู่ในหัวเรื่อง
  • When: เมื่อไหร่จะใช้ได้ บอกเวลาคร่าวๆ ก็ได้ครับ อีก 15 นาที หรือ อีก 2 ชม. ถ้าไม่รู้จริงๆ ว่าปัญหาที่เกิดขึ้นจะใช้เวลาแก้ไขนานเท่าไหร่ ให้บอกเวลาที่จะแจ้งความคืบหน้าในการแก้ไขปัญหาแทน ซึ่งความถี่ของการสื่อสาร จะขึ้นอยู่กับลักษณะของบริการโดยตรง ถ้าเป็นระบบ OLTP อาจจะต้องแจ้งกันทุก 1-2 ชั่วโมง แต่ถ้าเป็นระบบ Reporting ที่มีข้อมูลอัพเดทวันละครั้ง แค่ 1-2 ครั้งต่อวันก็น่าจะเพียงพอ
  • Why: จากจุดนี้ไป ผู้ใช้หลายคนอาจจะหยุดอ่านแล้วก็ได้ แต่บางคนก็จะสงสัยว่า เกิดอะไรขึ้น คำอธิบายสั้นๆ เป็นภาษาง่า่ยๆ จะช่วยได้มาก
  • Contact for more info: ตรงนี้อาจจะให้ชื่อเจ้าหน้าที่ ที่ดูแล หรือหมายเลขติดต่อภายใน เผื่อใครซักคนอยากระบายอารมณ์ อยากให้คำแนะนำ หรืออาจจะแค่อยากหาคนรับฟังปัญหา จะได้รู้ว่าจะโทรหาใครได้

ผมพบว่าการสื่อสารในเชิงรุกเกี่ยวกับ service outage ให้ผลดีในระยะยาว แทนที่จะงุบงิบเก็บปัญหาไว้ แล้วหวังว่าคงไม่มีใครทันสังเกตว่าระบบมันมีปัญหา ถึงแม้ว่าในตอนแรกมันจะดูไม่ดีนักก็ตาม ถ้าทุกครั้งที่มีปัญหา เราปล่อยให้ผู้ใช้เป็นคนพบปัญหาเหล่านั้นเอง เขาอาจจะแจ้งมาที่ helpdesk แต่คงมีีอีกหลายคนที่ไม่แจ้ง ไม่บ่น แล้วก็เลิกใช้ระบบของเราไปเลย (ถ้าเขาีมีทางเลือกอื่นนะครับ)