ทั้งเรื่องมีแบรนด์เดียวคือมิตซูบิชิที่เป็นไปตามเนื้อเรื่อง

ไม่มีโฆษณาแฝงบ้าบอครบ 90 นาทีเหมือนหนัง GTH

10/10

บ้านเราช่วงสิบปีที่ผ่านมา เริ่มอ้างอิงงานวิจัยกันมากขึ้นเรื่อยๆ ถึงกับมีการวิจัยออกทีวีมาแล้วตอน GT200

แต่การอ้างหลายครั้งก็น่ารำคาญ เวอร์ และมั่วกันบ่อย เลยขอเขียนถึงสักที

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

CRM เป็นซอฟต์แวร์ระดับองค์กรที่มูลค่าสูง หลายองค์กรที่เราด่าๆ ว่ากระบวนการแก้ปัญหาลูกค้ากากๆ ทุกวันนี้ส่วนใหญ่ลงซอฟต์แวร์ CRM มูลค่าหลายสิบหลายร้อยล้านมาแล้วทั้งนั้น

ราคาแพงที่ลงไปไม่ใช่ราคาที่ไม่สมเหตุสมผลซะทีเดียว (ไปดูสเป็คแล้วจะหนาว) แต่เอาเข้าจริงแล้วของพวกนี้ที่ลูกค้าต้องการจริงๆ ก็มีไม่กี่อย่าง

• ติดตามเคส ลูกค้าโทรหรือติดตามเข้ามา ต้องไม่ถามซ้ำ เรื่องยังไม่คืบไม่เป็นไร แต่ call center ทักได้ “อ้าว คุณ XXXX ที่ทำเรื่องขอคืนเงินใช่มั๊ยคะ” แค่นี้ก็น้ำตาไหลแล้ว ถ้าจะเทพมากๆ ก็ให้ case id ลูกค้าไปเลย
• ค้นหาลูกค้า ลูกค้าอาจจะติดต่อมาหลายทาง ส่งเอกสารทางอีเมล โทรมา complain ฯลฯ CRM จัดรวมให้อยู่ในคนๆ เดียวกันซะ อีกคนมารับงานจะได้เห็นว่าลูกค้าเดินเรื่องถึงตรงไหนแล้ว
• ติดตามสัญญากับลูกค้า จะโทรกลับในกี่วัน จะแก้ปัญหาในกี่วัน ฯลฯ ทำได้ไม่ได้ ติดตามลูกค้าซะ โทรไปขอโทษขอโพยว่ากำลังทำอยู่อะไรว่าไป

ของพวกนี้เอาเข้าจริงใช้ bug tracker ดีๆ สักตัวก็พอ ที่เหลือจะมีหน้าจอวิเคราะห์สารพัดไว้ทีหลัง ถ้า call center ยังต้องถามเรื่องลูกค้าทุกรอบก็เรียกว่า fail แล้ว

เห็นพูดกันบ่อยตามเว็บ

• โปรแกรมเมอร์ไม่ได้หายไปจากสังคม ไม่ได้ลดลงหรือเพิ่มขึ้นอย่างรวดเร็ว
• ตรงกันข้าม ในยุคหนึ่งแล้วงานโปรแกรมเมอร์กลายเป็นงานระดับล่างสุด (เงินน้อย งานหนัก สายก้าวหน้าคิดไม่ออก) ด้วยซ้ำ จะมีดีบ้างคือรับงานนอกได้ง่าย
• งานมากขึ้นเรื่อยๆ ปริมาณโปรแกรมเมอร์ที่ “ทำงานได้เลย” ก็ยังคงมีจำกัดอยู่ เพิ่มไม่ทัน ค่าแรงก็เพิ่มไปเรื่อยๆ คนที่มีอยู่เริ่มได้ offer ที่ดี หรืองานมีเยอะบางทีเบื่อๆ อยากจะเปลี่ยนงานซะก็ทำได้
• ทั้งหมดนี้ “ไม่ใช่” วิกฤติ โปรแกรมเมอร์ไม่ได้หายไปนับหมื่นคนในวันเดียวแบบนั้น
• ปัญหามีสองอย่าง คือ ค่าแรงที่นายจ้างคาดหวัง กับคุณภาพที่นายจ้างคาด
• โอกาสที่จะเจอเด็กคุณภาพดีๆ ในค่าแรงที่นายจ้างจำนวนมากคาด น้อยลงเรื่อยๆ มีบ้างหากมีเหตุผลพิเศษบางอย่าง เป็นกรณีไป ไม่ว่าจะเป็นบ้านใกล้ คุยกันถูกคอ สวัสดิการดี ให้หุ้นบริษัท ฯลฯ แต่โอกาสรวมๆ ก็ดูจะน้อยลงเรื่อยๆ
• ทางแก้ตรงไปตรงมา คือ ค่าแรงตลาดมันเพิ่ม ก็เพิ่มค่าตอบแทนให้เท่าตลาดเพื่อให้แข่งขันได้
• แนวทางแบบอยู่ยาว ต้องทำงานกันตลอดชีวิต มีน้อยลงเรื่อยๆ คงคาดหวังกันได้น้อยลงแล้วในยุคนี้ ในแง่หนึ่งไทยเราก็ไม่เคยมีวัฒนธรรมรับประกันงานตลอดชีวิตเหมือนกัน ก็แฟร์ๆ กันทั้งสองฝ่าย
• จับเด็กมาเทรน ถ้าเด็กเทรนแล้วขึ้น ก็ให้ตามสัดส่วนที่แข่งขันได้ ไม่งั้นเด็กก็ไม่อยู่กับเราอยู่ดี
• ถ้าเป็นบริษัทไอทีก็คงตรงไปตรงมา ต้องรับงานในราคาต้นทุนตามตลาด
• สำหรับบริษัท non-IT แล้วเจอปัญหา ทางแก้คือลดความต้องการใช้โปรแกรมเมอร์ซะ
• อันนี้เป็นปัญหาของบ้านเราคือแต่ละบริษัทมักมี process เฉพาะตัวมาก จะซอฟต์แวร์เทพแค่ไหนก็ต้อง customize กันแทบทุกฟีเจอร์ ทุก process ที่สะสมมานับสิบปี ไม่สามารถปรับ ยกเลิก หรือยุบรวมได้
• ก็ต้องเรียนรู้ที่จะตระหนักกันเสียทีว่าการเข้าไปแก้อะไร ต้นทุนที่เกิด ไม่ใช่ตอนใช้โปรแกรมเมอร์ให้แก้อย่างที่เราต้องการ แต่ต้นทุนคือโปรแกรมเมอร์ที่จะมานั่งดูแลส่วนที่เราแก้ไปตลอดอายุการใช้งาน
• ถ้าบริษัททำเงินสูง จ้าง “ทีม” โปรแกรมเมอร์มาดูแลได้ก็คงไม่มีปัญหา (ไม่ควรให้คนเดียวดูระบบเดี่ยวอยู่แล้ว เพราะเหตุผลลาออกอาจจะมีได้ล้านแปด ตั้งแต่เงินไม่พอ ไปจนถึงอกหักอยากหนีรัก)
• แต่ถ้าไม่มีงบขนาดนั้นก็ต้องอยู่กับซอฟต์แวร์สำเร็จรูปให้มาก แก้ไขซอฟต์แวร์ให้น้อย อยู่กับเส้นทางที่มีการซัพพอร์ตชัดเจน ต้นทุนต่ำ ยอมเปลี่ยนกระบวนการทำงานหากจำเป็น