ว่าด้วยงานวิจัย

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

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

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

CRM

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

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

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

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

 

วิกฤติโปรแกรมเมอร์

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

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

คิดถึงวิทยา

  • หนังรวมๆ โอเค
  • ตามสไตล์ GTH คือต้อง “่ข่มขืน” หนังตัวเองด้วยโฆษณาอย่างไร้ศิลปะ พี่ใส่แบบนี้เรื่องหน้าพี่ตัดกลางเรื่องขอพักโฆษณาสิบห้าวินาทีก็ได้
  • ประกันชีวิตนี่ทรามพอๆ กับโฆษณารถในกวน มึน โฮ แถมซ้ำสองรอบ วันหลังพี่ตัดกลางเรื่องโฆษณาสิบห้าวินาทีให้สาแก่ใจไปเลยดีกว่าครับ
  • มอเตอร์ไซด์ฮอนด้านี่โอเค เนียน แล้วใส่มาแล้วเพิ่มเรื่องราวให้หนัง (รถนั่งกับแฟนเก่า ขับทิ้ง) ระดับนี้ใส่มาไม่มีปัญหา แบบเดียวกับเป๊บซี่ในกวน มึน โฮ
  • รถนี่เริ่มแย่ โอเค อย่างน้อยเรื่องราวมันก็เดินหน้า ไม่ได้หยุดหนังมานั่งถ่ายป้ายโฆษณา
  • อย่างสมุดในถ้าใช้สมุดแบรนด์ (ไม่ว่าจะไทยหรือจะนอก) ก็น่าจะเนียนดี (หรือจริงๆ มันแบรนด์อยู่แล้ว)
  • ยางหน้าสมุดมันทนไฟ ปกหลังก็ทนไฟ
  • นางเอกหน้าเป๊ะมาก แม้โดดลงส้วม (อย่างโหด)
  • ที่ไม่เข้าใจคือข้อมือร้าว เหมือนจะจงใจใส่มาเพื่ออะไรบางอย่างที่ไม่ได้พูดถึง จงใจทำให้คนเข้าใจว่าลายมือของสองแย่มาก?