Topic 52: Delight Your Users

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

Guy Kawasaki

เป้าหมายของเราในฐานะ Developers คือการทำให้ Users ประทับใจ นั่นคือเหตุผลที่เรามาอยู่ตรงนี้ ไม่ใช่เพื่อขุดข้อมูล หรือนับยอดชม หรือทำให้กระเป๋าตังค์เขาว่างเปล่า ตัดเป้าหมายที่ชั่วร้ายออกไป แม้กระทั่งการส่งมอบ software ที่ทำงานได้ตรงเวลาเพียงอย่างเดียวก็ยังไม่พอ แค่นั้นยังไม่ทำให้เขาประทับใจหรอก

Users ของคุณไม่ได้ตื่นเต้นกับ code สักเท่าไรหรอก แต่พวกเขามี business problem ที่ต้องแก้ไขภายใต้เป้าหมายและงบประมาณของเขา เขาเชื่อว่าการทำงานร่วมกับทีมของคุณจะช่วยให้เขาทำสิ่งนั้นได้

ความคาดหวังของเขาไม่เกี่ยวข้องกับ software หรอก และมันไม่ได้ซ่อนอยู่ใน specification ที่เขาให้มาด้วยซ้ำ (เพราะ specification นั้นจะยังไม่สมบูรณ์จนกว่าทีมของคุณจะได้ทำ iteration ร่วมกับเขาหลายๆ รอบ)

งั้นคุณจะรู้ความคาดหวังของเขาได้ยังไงล่ะ? ก็แค่ถามคำถามง่ายๆ:

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

คุณอาจจะแปลกใจกับคำตอบที่ได้รับ โปรเจกต์ที่ทำเพื่อปรับปรุงระบบ product recommendations อาจถูกประเมินในเชิงของ customer retention ส่วนโปรเจกต์ที่รวมฐานข้อมูลสองแห่งเข้าด้วยกัน อาจถูกประเมินในเชิง data quality หรืออาจจะเป็นการประหยัดงบก็ได้ แต่ความคาดหวังใน business value ต่างหากที่สำคัญจริงๆ ไม่ใช่แค่ตัว software project อย่างเดียว เพราะ software เป็นเพียงเครื่องมือที่ช่วยให้บรรลุเป้าหมายเหล่านั้น

และตอนนี้เมื่อคุณเริ่มเห็นความคาดหวังแฝงในเชิงมูลค่าของโปรเจกต์แล้ว คุณก็เริ่มคิดหาวิธีที่จะส่งมอบสิ่งเหล่านั้นได้:

• ตรวจสอบให้แน่ใจว่าทุกคนในทีมเข้าใจความคาดหวังเหล่านี้อย่างชัดเจน

• เมื่อต้องตัดสินใจ ให้พิจารณาว่าทิศทางไหนจะทำให้บรรลุความคาดหวังเหล่านั้นได้มากที่สุด

• วิเคราะห์ user requirements ให้ถี่ถ้วนตามความคาดหวัง ในหลายๆ โปรเจกต์ เราค้นพบว่า "requirement" ที่ระบุไว้นั้นจริงๆ แล้วเป็นเพียงการเดาจากเทคโนโลยีที่มี หรือเป็นเพียงแผนการ implementation ที่ไม่ได้เป็นมืออาชีพนักที่เอามาใช้เป็นเอกสาร requirements อย่ากลัวที่จะเสนอแนะเพื่อเปลี่ยน requirement ถ้าคุณพิสูจน์ได้ว่ามันจะช่วยให้โปรเจกต์บรรลุเป้าหมายได้ดีกว่า

• คิดถึงความคาดหวังเหล่านี้อย่างต่อเนื่องในขณะที่โปรเจกต์ดำเนินไป

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

ถ้าคุณต้องการให้ลูกค้าประทับใจ ให้สร้างความสัมพันธ์ที่คุณสามารถช่วยเหลือเขาในการแก้ปัญหาได้อย่างกระตือรือร้น แม้ว่าชื่อตำแหน่งของคุณอาจจะเป็น "Software Developer" หรือ "Software Engineer" แต่ความจริงแล้วมันควรจะเป็น "Problem Solver" นั่นคือสิ่งที่เราทำ และนั่นคือหัวใจของ Pragmatic Programmer

เราแก้ปัญหา

หัวข้อที่เกี่ยวข้องรวมถึง

• Topic 12, ​_Tracer Bullets_​
• Topic 13, ​_Prototypes and Post-it Notes_​
• Topic 45, ​_The Requirements Pit_​