เดือนที่แล้ว ขึ้นรถเมล์ปรับอากาศแถวบ้าน
ด้วยความที่ขึ้นทีไร ก็ไม่เกิน 14 บาท
อยู่ๆรถเมล์คันนี้ก็เก็บ 16 บาท ทางเดิม ป้ายลงป้ายเดิม
เลยเกิดอาการ”เอ๊ะ” กับคุณกระเป๋า
คุณกระเป๋าทำหน้าให้โหดยิ่งขึ้น
แล้วพูดมาสามพยางค์เหมือนเดิม

“สิบหกบาท”

โถ่ ลูกหมาอย่างเราจะทำอะไรได้
นอกจากจ่ายๆไปซะ
แล้วก็นั่งขดๆเงียบๆอยู่ห่างๆพี่กระเป๋าหน้าหูด (โหด + บูด)

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

วันต่อมา ก็ค้นพบเองว่า
รถเมล์ยูโร 2 จะแพงกว่ารถเมล์อื่น
ทั้งที่เป็นรถเมล์ปรับอากาศเหมือนกัน
ขึ้นป้ายเดียวกัน ลงป้ายเดียวกัน เส้นทางเดียวกัน
ขนาดขึ้นรถเมล์หลายครั้งหลายหนยังไม่รู้เลยว่ารถปรับอากาศแต่ละแบบก็เก็บต่างกันด้วย
ทั้งชีวิตจำได้แค่ว่า รถปรับอากาศ กับไม่ปรับอากาศ มีค่าโดยสารที่ต่างกัน
และจนป่านนี้ ก็ยังแยกไม่ออกว่า รถคันไหนคือยูโร 2
จนกระทั่งเขาเก็บค่าโดยสาร ถึงจะร้องอ๋อ

 

หลังๆแทนที่จะให้เงินพอดีค่าโดยสาร
ก็เลยต้องให้เป็นธนบัตรยี่สิบบาทแทน
จะเอาเท่าไหร่ก็เอาไป จะทอนเท่าไหร่ก็ทอนมา

 

หนึ่งเดือนกว่าๆผ่านไป
คำตอบคงจะหายไปกับสายไฟตรงไหนสักที่แล้วกระมัง
(ไม่ต้องพูดถึงโทรศัพท์เลย
เคยโทรไปถามทางแล้ว โดนดุอีกต่างหาก)

 

แม้ว่าจะเป็นสถานการณ์ปรกติเมื่อเราติดต่อกับทางราชการผ่านทางเว็บไซต์
แต่มันก็ยังไม่แก้ข้อสงสัยว่า “ไม่มีใครดูแล้วมันจะทำไปทำไม(ฟะ)”

 

ถ้าให้ลองนึก scenario ในการทำเว็บไซต์ขสมก.ดู
ก็อาจจะเป็นประมาณว่า…
คนทำ: พอดีเรามีส่วนสร้าง contact us form อยู่แล้ว
ถ้ามีคนอยากติดต่อเราจะได้ผ่านทางหน้าเว็บได้เลย ดีไหมครับ
คนจ่าย: อืมๆ องค์กรเราจะได้ดูไฮเทคด้วยเนอะ เอาๆๆ

พอทำเสร็จแล้ว
คนทำ: ตรงหน้า contact จะให้ส่งไปที่ใครดีครับ
คนจ่าย: หือ ส่งอะไร
คนทำ: ก็ส่งอีเมล์ไงครับ
คนจ่าย: อีเมล์คืออะไร?
คนทำ: …

 
(ล้อกันเล่นนะ ล้อกันเล่น แฮ่ม…)

 

 

เวลาที่จะมีอะไรสักอย่างบนเว็บไซต์
ถ้าเป็นเรื่องที่ไม่จบบนเว็บไซต์ อย่างเช่น การตอบคำถามกลับ หรือการส่งของที่สั่งซื้อ
การจัดส่ง quotation ตามที่ขอมา อะไรก็ตามที่ลามมาถึงการดำเนินงานนอกอินเทอร์เน็ต
Business Logic เป็นเรื่องที่ต้องคำนึง ทั้งก่อนและหลังการออกแบบพัฒนา
และเป็นเหตุผลว่า ทำไมเราถึงต้องเข้าใจในธุรกิจนั้นๆ หรือเรื่องนั้นๆ
ที่เรากำลังจะออกแบบเพื่อรองรับมันอย่างเหมาะสม

อย่างเรื่อง Contact Form ในเว็บไซต์ของเรา
ถ้ามองในมุมเว็บอย่างเดียว ทำไมจะไม่ดี
มันควรจะเป็น Default feature ที่มีด้วยซ้ำในการทำธรุกิจหรือการทำองค์กรใดๆ
แต่ถ้าไม่หันกลับไปมองว่า มีคนรองรับอยู่หรือไม่
feature นั้นก็เป็นเพียงส้วมในโชว์รูมโฮมโปร ที่ไม่สามารถใช้งานได้จริง
(แต่ส้วมเขายังบอกนะ ว่ามันใช้งานไม่ได้ อะแฮ่ม…)
ไม่มีใครรู้ว่า พอกดปุ่ม submit หรือ send ที่หน้านั้นแล้ว
มันจะไปที่ไหน มันไปที่อีเมล์ หรือว่า Back Office
หรือว่ามันเป็นแค่ปุ่มกดเฉยๆ จริงๆแล้วมันไม่ได้ส่งไปไหนเลย ก็เป็นไปได้
นัยว่า ให้ผู้ติดต่อ ระบายอารมณ์เล่นๆ แค่นั้น

ลองคิดดูคร่าวๆเล่นๆว่า
จากเหตุการณ์นี้ เราน่าจะมี perception กับขสมก.อย่างไร
ก. ไม่มีความจริงใจในในรับรู้ปัญหาของผู้โดยสาร
ข. มีปัญหาเรื่องการทำงานภายใน
ค. แอ๊บไฮเทค แต่จริงๆแอบโลว์เทค
ง. ถูกทุกข้อ

 
การที่เรารู้จัก User มันทำให้เราเห็นว่า สิ่งที่เราออกแบบพัฒนาไปนั้น
User จะได้ใช้หรือไม่ น่าจะตอบสนองความต้องการของ User ได้หรือไม่
แต่ในอีกขาหนึ่ง เราก็ต้องรู้จัก Business เพื่อให้เห็นได้ว่า
สิ่งที่จะทำขึ้นมาสนองความต้องการของ User นั้น
ทาง Business สามารถดูแลได้หรือไม่ ทำตามนั้นได้หรือไม่

อย่างเคสหนึ่งที่เคยทำ
ลูกค้ามีคลัง content มหาศาล
พอเราออกแบบ Rich Internet Application ชิ้นหนึ่ง
ก็กะจะให้เขาดึง content ที่มีมาใช้ประโยชน์อย่างเต็มที่
แต่เหตุการณ์ที่ค้นพบก็คือ ด้วยความที่เป็นบริษัทใหญ่
การนำ content ออกมาใช้ ต้องทำขั้นตอนการขอใช้
ซึ่งกลายเป็นว่า ไม่สามารถดึงออกมาใช้ได้ตามใจนึก
เพราะ Business Logic ที่เป็นในบริษัท มันไม่อำนวย

หรืออีกเคสหนึ่ง
ลูกค้าต้องการเว็บไซต์ Community ที่มี content มากๆ
แต่ใน Business Logic ปัจจุบัน เขาไม่มีทีมทำ
แต่เมื่อมีคำถามกลับไปว่า จะมีการตั้งทีมสร้าง content มารองรับหรือไม่
ก็ได้เปลี่ยนเป็นการซื้อหรือเป็น Partner กับผู้สร้าง Content รายอื่นๆแทน
แต่ไปๆมาๆ ก็ได้พบว่า Business Logic กับความเป็นสมาชิกของบริษัทลูกค้านั้น
ยังไม่ได้ปรับให้มีส่วนสนับสนุนการมี Community เลยด้วยซ้ำ
อย่าว่าแต่ online เลย
กลายเป็นเรื่องใหญ่ที่นอกเหนือการมีเว็บไซต์หนึ่งไปเสียแล้ว

 
บางคนอาจจะอึดอัดที่ต้องไปเข้าใจธุรกิจ หรือเรื่องราวของลูกค้า
ซึ่งเป็นสิ่งที่ไม่สนใจ
เพราะต้องการที่จะทำของให้อย่างเดียว ต้องการทำซอฟต์แวร์ ไม่ต้องการอะไรมากกว่านั้น
ในหลายๆกรณี ลูกค้าก็ต้องการแค่นั้นจริงๆ คือต้องการให้เราทำของให้เหมือนคนอื่นๆ
แต่อย่างไรก็ตาม สำหรับลูกค้าที่มีความหวังที่จะได้สิ่งที่ดีจากเรา
การเข้าใจการทำงาน สถานการณ์ของลูกค้า
จะช่วยให้เรามีโอกาสทำของที่มีการใช้งานจริง
ไม่ใช่เพียงทำเสร็จแล้วก็แล้วกัน
ทำให้ของนั้นทำออกมาแล้วได้ประโยชน์สูงสุด ทั้งกับผู้ใช้และองค์กร
อีกทั้งยังส่งเสริมภาพลักษณ์ขององค์กรได้อีกทางหนึ่งด้วย
(คือ ตรงไหนไม่พร้อม ไม่ได้เรื่อง ก็อย่าโชว์
ไปโชว์ ไปทำงาน ในสิ่งที่ถนัด เหมาะกับองค์กร ดีกว่า)

แล้วยังดีกับเราเองด้วย
ลูกค้าจะมีความประทับใจกับเรา
นับตั้งแต่การที่เราพยายามเข้าใจองค์กรของเขา เข้าใจวิธีการทำงานของเขา
เข้าใจทรัพยากรที่เขามี และ potential ที่เขาจะทำได้
ตลอดจนการตั้งใจออกแบบพัฒนาเพื่อมอบสิ่งที่ดีที่เหมาะสมที่สุดให้กับเขา

อ๊ะ แต่ต้องส่งงานให้ตรงเวลาด้วยนะ แฮ่ม…