Living with Complexity : Donald A.Norman
เราไม่ได้ต้องเลือกระหว่างความซับซ้อนและความเรียบง่ายฃ
ความซับซ้อนคือสภาพความเป็นจริงของโลก
ความเรียบง่ายคือสิ่งที่เกิดขึ้นในจิตใจ
ช่วงสามเดือนก่อน
…ผมได้อ่านหนังสือเล่มนี้ครับ จากน้อง Programer ในทีม
Living with Complexity ที่เขียนโดยคุณ Donald A. Norman
เขาเป็นอาจารย์สอนที่ Harvard และเป็นผู้ที่เขียนถึงกฎนี้ครับ
“Tesler Law”
มีใครเคยได้ยินชื่อกฎนี้ไหมครับ
แห่ๆ…..ผมก็พึ่งเคยรู้จักครั้งแรกผ่านหนังสือเล่มนี้แหละครับ
โดยกฎนี้เกิดจากคุณ ลาร์รี เทสเลอร์ ผู้ซึ่งเคยเป็นรองประธานบริษัทแอปเปิ้ลได้กล่าวว่า
“ความซับซ้อนโดยรวมของระบบมีค่าคงที่”
หากเราทำให้ส่วนหนึ่งของระบบง่ายขึ้น ทุกส่วนที่เหลือของระบบซับซ้อนขึ้น
ถ้าการทำให้สิ่งต่างๆง่ายขึ้นสำหรับผู้ใช้ มันก็คือการเพิ่มความยากให้กับงานของนักออกแบบหรือวิศวกร
ดังนั้นโปรแกรมทุกโปรแกรม ต่างมีค่าความซับซ้อนที่ไม่อาจลดทอด
เราไม่อาจลดความซับซ้อนได้
ดังนั้นคำถามที่ว่า
“เราจะลดความซับซ้อนได้อย่างไร”
เป็นคำถามที่ผิด !
คำถามที่ถูกคือ
“ใครจะต้องเป็นผู้รับมือกับมัน”
ผู้ใช้ หรือ ผู้พัฒนา
ทีนี้เมื่อผมได้อ่านบทความนี้จบ ผมก็มานั่งคิดว่าเอ แล้วในชีวิตของเรานั้น เอาหลักการนี้ไปใช้ได้หรือไม่
ผมลองดูที่สิ่งใกล้ตัวก่อน
โรงพยาบาล
ถ้าในโรงพยาบาล อันนี้ก็จริงนะครับ
ในฐานะที่เราเป็นหมอเราก็ไม่ได้ทำอะไรซัซ้อนมาก เพราะหน้าที่ส่วนใหญ่ถูกผลักไปให้คนไข้ หรือผู้ใช้บริการเสียหมด
ไหนจะต้องมาแต่เช้าเพื่อทำบัตรคิว เดินวนในเขาวงกฎเพื่อไปเจาะเลือด นั่งรอคิวที่ไม่รู้ว่าจะมาเมื่อไหร่ซักที ตรวจเสร็จ รอยา จ่ายเงิน รอรับยา งงไปหมด
แท๊กซี่
ถ้าเป็นด้านความสะดวกสบายละ
ผมว่าที่ใกล้ตัวสุดน่าจะเป็น Uber/Grab นะครับ
ที่ระบบช่วยจัดการความซับซ้อนหลายอย่างให้เรา
กดแล้วจะมีคนรับหรือไม่
ตอนนี้รถอยู่ตรงไหน จะมาถึงหรือยัง
การจ่ายเงิน มีเศษไม่พอดี
review / Rating ช่วยควบคุมพฤติกรรมที่ดีของทั้งสองฝ่าย
เราเพียงกดบอกจุดหมาย มีคนมารับ ขึ้นรถ แล้วลงรถได้เลยโดยไม่ต้องพูดอะไรซักคำก็ยังได้ (กรณีหมุดแม่น)
จะเห็นว่างานที่ดูซับซ้อนต่างๆ ถูกระบบนำไปจัดการหมดแล้ว
ประยุกต์ใช้…..มองเรื่องใกล้ตัว
ทีนี้มาดูเรื่องที่ผมเจอมากับตัวบ้าง ตลอดช่วงสามปีที่ผ่านมาบ้างครับ
Health at home version แรกนั้น
ผมก็คิดเอาง่ายๆว่า ถ้าครอบครัว อยากหาผู้ดูแล ก็แค่นำเขามาเจอกันสิ มันจะไปยากอะไร ทำไมไม่มีใครทำน้า
เรานี่แหละ ยูนิคอร์นตัวถัดไป 555
2016
เราก็สร้าง website ให้ผู้ดูแลมาลงทะเบียน แล้วก็ให้ครอบครัวมาลงทะเบียน
พอกดแล้วก็ ส่ง profile คนที่ว่างงานให้ไปคุยกัน ให้เบอร์ไปคุยกันเอง
ตอนนั้นเราทำ website ให้ผู้ดูแลมาสมัคร แล้วก็ครอบครัวที่สนใจใช้มาสมัคร กรอกข้อมูลที่ต้องการ ถ้าข้อมูลตรงกัน เราก็ขึ้นโชว์ว่า มีใครที่ Match บ้าง จากนั้นก็ขึ้นเบอร์ให้ทั้งสองฝ่ายติดต่อกันเอง
ในเวลานั้นมีหลักความคิดคือ สร้างของขึ้นมาก่อน ให้ user มาใช้เยอะๆ แล้วถ้ามันมี value ค่อยคิด Business model อีกที ( ง่อววว Startup mindset)
สุดท้าย ทำได้อยู่ประมาณ 2 เดือนก็พบว่าไม่ work แฮะ
ผู้ดูแลก็งง ครอบครัวก็งง
เราเองก็ งง ……
เราพบว่าแท้จริง การที่สองฝ่ายจะสามารถตกลงงานกันได้ นั้นมันมีขั้นตอนซับซ้อนมากมายที่ต้องจัดการ พอเราโยนภาระงานทั้งหมดให้จัดการกันเอง มันเลยมีโอกาสสูงที่จะทำให้เกิดความผิดพลาด
ปีถัดมา 2017
เราก็เลยมานั่งคิดว่า งั้นมันอาจต้อง manaul ใช้พลัง Brute force เอามาเลยโยกกลับมาที่เราหมดเลย
คือเปิดมาเป็น Website แล้วก็มีเบอร์ HAH เลยโทรมา ก็เจอผมนี่แหละครับ นั่งรับโทรศัพท์ จากนั้นตัวเราก็ทำหน้าที่จัดการ Task ทั้งหมดให้
ไม่ว่าจะเป็น, การยืนยันวันทำงาน, การ Match สถานที่,ค่าตอบแทน,การจัดการเรื่องการชำระเงิน,การคืนเงิน, การทำเรื่องภาษี, การรับรองคุณภาพของผู้ดูแล, การขอเปลี่ยนผู้ดูแล, การหาคนแทนในวันที่ผู้ดูแลป่วย, การคุยกับญาติในวันที่ Scope งานไม่ตรงกัน, การเทรนนิ่ง ฯลฯ
พอได้มาทำเองเราก็เลยเข้าใจว่า เดิม Function เหล่านี้ เดิมมันถูกผลักไปให้ญาติ มันก็มาที่เรา
การแก้ปัญหาแบบนี้ ก็ช่วยให้ทั้งสองฝ่ายมีความสุขมากขึ้น เพราะเราเป็นคนแบกรับความซับซ้อนทั้งหมด แต่ก็นำมาซึ่งปัญหาใหม่คือเมื่อมีลูกค้าเยอะขึ้นเราก็พบว่า ไม่สามารถเติบโตได้อีกแล้ว อย่างน้อยผมก็รับโทรศัพท์ทุกวันไม่ไหวแล้ว
ในเวลานั้น ลูกค้าแฮปปี้ ผู้ดูแลแฮปปี้ แต่ ผมและทีมงานเองเริ่มแฮปปี้ไม่ค่อยไหวแล้ว
ปีถัดมา 2018 หรือปีนี้
เรารู้แล้วว่ามี Task มีความซับซ้อนอะไรบ้าง จากนั้นเราเริ่มออกแบบระบบ โดยโยนความซับซ้อนออกไปให้ Computer เป็นคนจัดการ
เราเริ่มทำ Automation Function ที่ง่ายๆก่อน เช่น การ Match skill / Location / Scheudule วันทำงาน / Price
แต่หน้าที่อื่นๆส่วนใหญ่เราก็ยังต้องจัดการอยู่
แต่เราก็พอเห็นภาพทั้งหมดในการ Develope product แล้วว่ามันต้องทำอะไรบ้าง
ในปีต่อๆไป
ผมคิดว่าเราคงอยากลดความซับซ้อนให้ได้มากที่สุด
โดยเราโยกความซับซ้อนให้เข้าระบบ Automation ให้ได้มากที่สุด โดยที่ประสบการณ์ของผู้ใช้บริการไม่หล่นหาย (นั่นคือความท้าทาย)
เพื่อเราจะทุ่มทรัพยากรไปทำงานบางอย่างที่มัน Automate ไม่ได้ เช่น เรื่องการการดูแลจิตใจ การสร้างสัมพันธ์ที่ดีกับผู้ใช้บริการ กับพี่ๆผู้ดูแล
ข้อคิดจากเรื่องนี้คือ
1.ความซับซ้อน มีค่าคงที่ในระบบ มันขึ้นอยู่กับเราว่า จะเอามันไว้ตรงไหน แล้วใครเป็นคนจัดการ ซึ่งเราสามารถประยุกต์ไปใช้มองเรื่องรอบตัวได้
2.การจัดการกับความซับซ้อน มันอาจไม่ได้เท่มากในวันแรกๆ แต่ถ้าเท่ได้ก็ดี แต่ทั้งนี้ทั้งนั้น มันคือการเข้าใจทั้งระบบ แล้วนำการออกแบบมาช่วย โดยการออกแบบควรเอา User centric เป็นที่ตั้ง (ในกรณีของ Health at home คือ ผู้ใช้บริการ และ ผู้ดูแล )
3.หัวใจสำคัญคือจะเติบโตอย่างไร (หรือ Automation อย่างไร ) โดยที่ไม่ทำให้ประสบการณ์ของผู้ใช้ไม่หล่นหายไป
หวังว่าบทความนี้จะมีประโยชน์ ให้ทุกๆคนลองไปอ่านเรื่องเกี่ยวกับ Tesler’s law กันเพิ่มเติมนะครับ แล้วก็คิดว่าหนังสือเล่มนี้เหมาะสำหรับคนที่ทำเรื่อง Service design ด้วยครับ
เกี่ยวกับผู้เขียน
นพ.คณพล ภูมิรัตนประพิณ (ตั้ม)
พนักงานรับโทรศัพท์คนแรกของ Health at home
