สอน Presentation โครงการ SSME Fast Track

วันที่ 24/3 ที่ผ่านมา ผมไปสอนเรื่อง Presentation Techniques ให้กับโครงการ SSME (Service Science & Management Engineering) ที่ SIPA แล้วก็สัญญากับคนที่ไปอบรม ว่าจะเขียน blog เกี่ยวกับเรื่องนี้เอาไว้สักหน่อย แต่พอเอาเข้าจริงก็มานั่งคิด แล้วจะเขียนอะไรดีล่ะเนี่ย ก็ขอเขียนถึงเนื้อหานิดๆ หน่อยๆ และเขียนถึงประสบการณ์และความรู้สึกดีๆ ที่ได้ไปสอนก็แล้วกัน

ผมแบ่งเนื้อหาออกเป็น 4 ส่วนใหญ่ๆ ดังนี้

  1. How *NOT* to Present ซึ่งพูดถึง Presentation Mistakes ที่นับเป็น common มากๆ ทั้งหลายทั้งแหล่ จริงๆ มันก็มีไม่กี่ตัวหรอกที่พบกันบ่อยๆ มากๆ


    SSME_Present1.png

    และใช่ครับ อย่างที่เห็นน่ะแหละ slide ของทั้ง 9 mistakes นี้ “แดกดัน” แรงๆ เลย เอาสิ่งที่พบบ่อยจนเกินงาม มาทำให้มันสุดโต่ง แล้วก็พยายามนำเสนอในแบบที่ยึดติดกับ slide (เช่นยืนอ่านตาม slide เป็นต้น) ใครที่เคยฟังผมพูดสาธารณะบ้าง คงจะจำได้ว่าปกติ slide ผมนี่ไม่ต้องพยายามอ่านมัน หรือว่าเอาไปอ่านโดยปราศจาก “ผม” เพราะว่ามันมีแต่รูปเป็นหลัก มี text บ้างไว้ประกอบรูป เอาไปนั่งเพ่งอย่างเดียวคงไม่รู้เรื่องเด็ดขาด

  2. วิธีการ Present ซึ่งตรงนี้รูปใน slide และเนื้อหานั้น ผมได้ส่วนหนึ่งมาจาก Presentation Zen (http://www.presentationzen.com/) และเล่าประสบการณ์ตัวเองและวิธีปฏิบัติบางอย่างในฐานะผู้นำเสนอ


    SSME_Present2.png

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

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

    สิ่งมีชีวิต ไม่ว่าจะเป็นอะไรก็ตาม บทบาทง่ายๆ ตามธรรมชาติของห่วงโซ่อาหารมันจะมีแค่ “ผู้ล่า” กับ “เหยื่อ” เท่านั้น หากเราแสดงความเป็นเหยื่อ (โดยการกลัวผู้ล่า) อีกฝ่ายหนึ่งก็จะคิดว่าตัวเองเป็นผู้ล่าของเราโดยธรรมชาติ และในฐานะผู้นำเสนอ บางทีเราโชคดีที่ได้เลือกบทบาทก่อน หากเราเลือกบทบาทของเหยื่อ เราจะมีปัญหาทันทีกับการนำเสนอให้มี Convincing performance และก็ให้ทำใจได้เลยว่า ผู้ฟังการนำเสนอ อาจมีคนรู้สึกว่าตัวเองเป็นผู้ล่าโดยปริยาย ดังนั้น มันเป็นทริคง่ายๆ ในการเลือกบทบาทก่อน

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

    นี่แหละ ผมเลยเสนอ “How NOT to Present” ก่อน เพราะแน่ใจได้เลยว่า หลายคนเคยเจอพวกนี้มา และเห็นว่ามันเป็นปัญหาแน่นอน พอเบรคแรก ก็พบว่ามีหลายคนเริ่มอิน ว่าเจอบ่อย เป็นปัญหา น่าเบื่อ ฯลฯ

  3. สอนแต่ทฤษฎี ยืนพูดมันไปก็เท่านั้นแหละ มันไม่เห็นของจริงใช่มั้ย เหมือนกับ Quote ใน slide นี้ ที่ว่าไม่ต้องโชว์มากนัก ไอ้ตัวโน๊ตน่ะ เปิดเพลงให้ฟังเลยดีกว่า หรือว่าเล่นเพลงให้ฟังและดูจะๆ เลยดีกว่า ในช่วงที่ 3 ก็เลยเป็นการ “แก้” Presentation ที่ห่วยให้มันดีขึ้น และทำด้วยกันทั้งห้อง


    SSME_Present3.png

  4. ช่วงสุดท้ายเป็น Workshop ทำจริง ซึ่งประเด็นหลักๆ อยู่ที่ว่า “อย่าเริ่มทำ presentation ด้วยการเปิดโปรแกรม ไม่ค่อยดีเท่าไหร่นักหรอก ให้เริ่มทำด้วยการเลือก Story และเปิด Mind Map มา storm idea ลงไปให้มันเคลียร์ๆ ซะก่อน (แต่ว่าวันนั้นยังไม่ได้ Mind Map นะ เพราะว่าเนื้อหาของหลักสูตรยังไปไม่ถึง) แล้วค่อยออกแบบการนำเสนอ” จากนั้นก็ใช้ลูกไม้ก้นหีบให้อย่างหนึ่งในการออกแบบ Presentation นั่นคือวิธีการที่ผมเรียกว่า Back-of-Business Card method (หรือ Business Card method)


    card_method.085.png

    design_to_implement.003.png

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


    mindmap_present.png

นั่นคือ ส่วนหนึ่งของเนื้อหา ทีนี้ขอพูดถึงประสบการณ์และบรรยากาศของวันนั้นหน่อย ขอสั้นๆ ชัดๆ โง่ๆ ง่ายๆ เลยละกันนะ

คลาสนี้เป็นคลาสที่ผมสอนได้อย่างมีความสุขและสนุกที่สุดในรอบ 3-4 ปีเลย ต้องขอบคุณผู้เรียนทุกคนมาก ที่หัวเราะ เฮฮา ด้วยกันตั้งแต่นาทีแรก จนถึงนาทีสุดท้าย มีกัดกันบ้างมีอะไรบ้าง แต่ละคนไม่อายในการถาม ในการเสนอความคิดต่างๆ

ภาพข้างล่างนี้เป็น Slide ที่ผมใช้ orientation วิชาบางวิชาที่ผมสอนที่ศิลปากร


hci_orientation2.png

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

สนุกมากครับ และขอบคุณทุกคนมากครับ

My Dad’s further comment:

Same as previous post, here’s my dad’s further comment on education, via e-mail. Note: Highlights are my own, on what I think are important messages.

Dear Son,
I saw my comments in your bloc.
I would like to add that our education system or our culture lead to surface knowledge. We do not go down deep to learn the basic behind.
I will give you an example.
If you read the research on life science these days you will see so many cluster analysis of similarity. This could be similarity among several varieties in any species. It is so easy to make these dendrograms using so many statistical packages available free on the web.
But, do we know the basic behind those calculations?.
It is fine for the users or technician. But, how about those with prestigious doctorate degree.
So, where are we going in education?
Love,
Dad

My Dad’s comment on “Generation Click”

ส่ง e-mail link บทความ “Generation Click” ให้พ่ออ่าน พ่อ e-mail กลับมาว่า

I just returned from KKU few minutes ago. Tomorrow, I will go to Chiang Mai and will return on Saturday. How about that?

The ‘Generation Click’ is good.

May be the academia has to work harder to bring the thinking process back to life. Or, the young generation will have to depend on some tools all the time. They cannot thinking about making the tools themselves.

Love,
Dad

Thank you Dad! Your comment really worths its own entry. It’s really that good! Let me repeat what I think is very important:

May be the academia has to work harder to bring the thinking process back to life. Or, the young generation will have to depend on some tools all the time. They cannot thinking about making the tools themselves

“Generation Click”

กลับบ้านคราวที่แล้ว นั่งคุยกับพ่อเรื่องน่าสนใจหลายเรื่อง เรื่องหนึ่งก็คือ เรื่องผู้ใช้คอมพิวเตอร์ ทั้งเป็นผู้ใช้แบบ user จริงๆ และนักคอมพิวเตอร์ นักเทคโนโลยีสารสนเทศและการสื่อสาร และโปรแกรมเมอร์ generation ใหม่ ที่พ่อผมเรียกว่า Generation Click

คุณพ่อบอกว่า “พวก Generation Click เนี่ย ไม่เจอ icon ไม่เจอเมนู ให้ click ได้ แล้วทำอะไรไม่เป็นเลย” แล้วอีกไม่นาน ก็ต่อด้วย “แบบนี้เขียนโปรแกรมใช้งานเองลำบากแย่เลย เพราะเขียนโปรแกรมจริงๆ ก็แค่เอาคำสั่งพวกนั้นมาต่อๆ กัน ไม่ใช่เหรอ?”

อืมมมมมม เห็นด้วยแฮะ

ก่อนจะพูดต่อไป ขอพูดถึงตัวเองหน่อย ….. ผมอาจจะโชคดีพอ ที่เกิดมาทันสมัย DOS (เครื่องแรกในชีวิต ที่ตั้งที่บ้าน ใช้งาน DOS 5.0 — ไม่มีเมาส์ด้วยซ้ำไป) ทำให้การทำงานกับ command line เป็นอะไรที่เป็นเรื่องปกติ รู้สึก at home กับมันมาก อยากจะให้มันทำอะไร ก็สั่งมันตรงๆ เป็นคำสั่งๆ ไป และแต่ละคำสั่งก็จะมี option อะไรก็ว่าไป ไม่พอ กว่าจะเล่นเกมได้แต่ละเกมๆ ก็ต้องแก้ config.sys, autoexec.bat กันวุ่นวาย ถึงขนาดต้องเขียน batch file เอาไว้เปลี่ยนสองไฟล์นี้เอง ด้วยความรำคาญ

พอชีวิตเริ่มเจอ GUI มากขึ้น ไม่ว่าจะเป็น Windows 3.x, Windows 95 ก็ได้ทุนไปเรียนญี่ปุ่น ก็พอเดินเข้าห้องคอมพิวเตอร์วันแรก ก็เจอ SGI IRIX เจอ GUI แบบไม่เคยเจอมาก่อน และต้องทำงานกับ Shell บน terminal emulator (ถ้าจำไม่ผิด รู้สึกว่าจะเป็น tcsh) ทำทุกอย่างบนนั้นหมด เหมือนกับเปลี่ยนโลกไปเยอะ จากนั้นเพื่อนๆ สนิทๆ กัน (Peter Suranyi, Janos Gyerik) ก็ยุให้เล่น Linux ก็เลยหามาลง ซึ่งก็กว่าจะหาทางทำให้ X-Windows มันทำงานได้ กว่าจะฯลฯ ได้ ก็แทบแย่

ประเด็นคือ การอยู่กับ terminal หรือ command prompt ทุกชนิดของผม ทำให้ผมมองการใช้งานคอมพิวเตอร์ เป็น “บทสนทนา” ระหว่างผมเอง กับคอมพิวเตอร์ ไม่ว่าผมจะใช้โปรแกรมอะไรก็ตามที่สามารถใช้งานในลักษณะ terminal ได้ จะเป็น MySQL, Octave, R หรือว่าโปรแกรมที่เป็น command line-based เช่น imagemagick ที่เอามาประกอบกับ shell scripting ได้ หรือว่า interactive programming environment ต่างๆ เช่น IRB, Python, Scheme, Haskell

กลับมาถึงบทสนทนาระหว่างผมกับคุณพ่อ

คุณพ่อผม เป็นนักปรับปรุงพันธ์พืช ที่ใช้ dBase 3 Plus ในการเก็บข้อมูล มานานมาก และเขียนโปรแกรมใช้งานเอง เริ่มจากใช้งานฐานข้อมูลนั้นๆ ทีละคำสั่งๆ แล้วก็เอาคำสั่งพวกนั้นมาต่อๆ กันเป็น routine/sub-routine และก็เริ่มซับซ้อนขึ้นเรื่อยๆ จนปัจจุบัน เป็นโปรแกรมที่มีความซับซ้อนมาก และทำงานได้ดี ช่วยงานได้เยอะมาก

สิ่งที่ท่านพบก็คือ นักปรับปรุงพันธ์รุ่นใหม่ ซึ่งใช้คอมพิวเตอร์ในการทำงานมากขึ้น ไม่ว่าจะในการวิเคราะห์ทางสถิติ หรือว่าการวิเคราะห์อื่นๆ กลับไม่ค่อยจะสามารถพัฒนากระบวนการคิดนั้นๆ ได้ และไม่สามารถที่จะมองความเชื่อมโยงระหว่าง process ระหว่างโปรแกรมได้เท่าไหร่ ไม่ต้องพูดถึงเรื่องเขียนโปรแกรมเลย ยิ่งกว่านั้น ในการทำงานทุกอย่าง จะมองหาแต่ icon ของคำสั่ง กระบวนการทำงานโดยทั่วไปคือ select & click และมองไม่ออกว่า จริงๆ สิ่งที่ทำๆ อยู่เนี่ยแหละ คือ “การสนทนา” ที่หากว่าบันทึกไว้ มันก็คือการเขียนโปรแกรมน่ะแหละ แต่พวกนี้กลับรักที่จะทำทุกอย่างแบบ manual แทน (เพราะว่าตัวเองได้เป็นคน click icon คำสั่งกระมัง)

มันเลยกลับมาถึงเรื่องที่ผมบ่นๆ ไว้บ่อยๆ เรื่องนักศึกษาในสาขาวิชาที่ต้องเรียนเขียนโปรแกรม ซึ่งพบว่า มีปัญหากับกระบวนการคิดค่อนข้างเยอะ และไม่สามารถคิดอะไรในลักษณะ “เอาคำสั่ง มาต่อกัน” หรือ chain ของ Input-Process-Output ได้เลย

ผมลองตั้งโจทย์คร่าวๆ ว่า “มีไฟล์อยู่หนึี่งไฟล์ ข้างในไฟล์มีคำอยู่เยอะ ซ้ำๆ กัน ผมอยากรู้ว่ามีคำไม่ซ้ำกันทั้งหมดกี่คำ?” (ทั้งนี้ คำทุกคำ เป็นตัวเล็กหมด และไม่มีอักขระแปลกๆ ตัวอย่างเนื้อความในไฟล์คือ this is a cat this is a bat this is a map this is a phone)

เชื่อหรือไม่ว่า ไม่มีนักศึกษาสามารถคิด logic ของโจทย์นี้ได้แบบเป็นขั้นเป็นตอน ชัดเจน ได้แม้แต่คนเดียว ใน class ที่ผมสอน! ทั้งๆ ที่ logic มันง่ายแสนจะง่าย ก็แค่

  • เปิดไฟล์ เอาเนื้อความ
  • เอาเนื้อความในไฟล์มา แยกเป็นคำๆ
  • เอาคำที่ได้ มากรองเอาคำซ้ำออก
  • นับคำที่เหลือ

จะเห็นว่า มันก็เป็น chain ของ I-P-O อยู่ชัดเจนนะ คือ สมมติว่ามันเป็นฟังคชัน f, g, h, i ตามลำดับ ก็จะได้ว่าคำตอบของมันก็คือ i(h(g(f(x)))) … เขียนให้มันง่ายๆ กว่านี้หน่อย สมมติว่าเป็นฟังคชันชื่อ readfile, splitwords, unique_element, count ตามลำดับ ก็เป็น count(unique_element(splitwords(readfile(“filename”)))) ใช่มั้่ย จากนั้นก็แค่เอาไปดูว่า แต่ละภาษาหรือ environment เนี่ย เอามาทำแบบนี้ยังไงดี มีฟังค์ชันมั้ย ต้องเขียนเองมั้ย ถ้าจะเขียนเองจะต้องเขียนยังไง ก็แค่คิด I-P-O แบบเดิม ลงไปให้ลึกขึ้น เท่านั้น

ถ้าเขียนใน bash shell ก็คงเป็น

cat filename.txt | tr " " "\n" | sort -u | wc -w

ถ้าเป็น ruby ก็เป็น

File.read("filename.txt").split(" ").uniq.count

ถ้าเป็น haskell ก็เป็น

content <- readFile "filename.txt"
length (List.nub (words content))

ซึ่งจะซับซ้อนกว่าตัวอื่นๆ นิดหน่อย เพราะว่ามีเรื่อง IO String กับ String มาเกี่ยวข้อง (purely functional ก็แบบนี้แหละ)

แถม ... เป็น C++ ก็ยาวหน่อย (ไม่รวมพวกการ include library มาใช้นะ)

int main()
{
  ifstream fin("filename.txt");
  set<string> words;
  copy(istream_iterator<string>(fin), istream_iterator<string>(),
       inserter(words, words.begin()));
  cout << words.size() << endl;
  return 0;
}

จะเห็นว่า logic มันไม่ได้เปลี่ยนเลยสักกะนิด เพียงแต่ว่าอาจจะ verbose บ้าง รูปแบบต่างกันบ้าง คำสั่งต่างกันบ้าง

วันนั้นข้อสรุปของบทสนทนาระหว่างผมกับพ่อก็คือ Generation Click พบความลำบากมากกว่า ในการคิดสื่อสารกับคอมพิวเตอร์เป็นขั้นตอน ด้วย text ด้วยคำสั่งต่างๆ ดังนั้นอาจจะช่วยได้ หากทุกคำสั่งมันมี icon หมด และลากมาวางต่อๆ กันได้ เหมือนกับ automator.app ใน Mac OS X หรือบรรดา visual programming ทั้งหลาย

สมัยผมสอน OOP ผมเคยให้ นักศึกษาเล่นกับ Alice ซึ่งก็เป็น visual programming พอสมควร ก็พบว่าได้ผลในระดับหนึ่ง แต่ว่าพอถึงเวลาต้องไปเขียน code ซึ่งเป็น text ก็ยังพบปัญหาเดิมๆ อยู่ เทอมนี้ก็เลยขอหักดิบ ให้ใช้งาน shell มันซะเลย เผื่ออะไรๆ จะดีขึ้นมาบ้าง

ลงท้ายด้วยการเผา advisee หน่อยละกัน ... เจอพวกที่แทนที่จะคิด logic ของระบบงาน กลับคิดแต่ว่าจะต้องใช้โปรแกรมอะไร ต้องเริ่ม click ที่ปุ่มไหน แล้วจะ click ปุ่มไหนต่อ งานถึงจะเสร็จ ....​ ฮา (ไม่ออก)

ลอกกุญแจ ได้คะแนนเต็ม

จำได้ว่าตัวเองพูดประโยคนี้ครั้งแล้วครั้งเล่า ไม่ว่าจะเป็นการพูดกับเพื่อน พูดกับลูกศิษย์ พูดกับพ่อแม่ พูดกับตัวเอง ทั้งพูดในที่สาธารณะ ทั้งพูดในที่ส่วนตัว ฯลฯ ซ้ำแล้วซ้ำเล่า ซ้ำแล้วซ้ำเล่า ตั้งแต่ยังเป็นนักเรียน จนถึงวันนี้

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

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

ไม่ขอพูดอะไรมากกว่านี้หรอกครับ ว่าเจออะไรมาบ้างเร็วๆ นี้ แต่มันมีหลายเรื่องมากกว่าเรื่องการส่งการบ้าน หรือว่าวิธีการทำการบ้านของนักศึกษา

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

“เกรด” “งาน” “ประสบการณ์”

ไม่ได้เขียน blog นานมาก …​ พักหลังๆ ไปอยู่ใน twitter ซะมากกว่า

วันนี้ก็บ่นใน twitter อีกน่ะแหละ แต่ว่าบ่นต่อกันเป็นเรื่องเป็นราวหน่อย ขอ copy & paste มาแปะไว้ที่นี่ด้วยก็แล้วกัน .. แต่ว่ามันอาจจะอ่านไม่ค่อยต่อเนื่องนะ เพราะว่าต้อง post ครั้งละไม่เกิน 140 ตัวอักษร (bullet ละ tweet)

  • เจอเรื่องเซ็งๆ กับ comment/remark เซ็งๆ อีกล่ะ
  • วันนึงน้องๆ นักศึกษาที่รักจะเข้าใจครับ ว่า “เกรด” มันไม่มีความหมายอะไรหรอก “ประสบการณ์” ที่ได้จากการทำงานต่างหากที่มันมีความหมาย
  • ดังนั้นถ้าน้องๆ ได้ A มาง่ายๆ และไม่ได้ประสบการณ์ แนวคิด และทัศนคติอะไรมาเท่าไหร่ มันไม่มีค่าเท่ากับ C ที่ได้มาพร้อมกับความคิด ประสบการณ์
  • เรื่องพวกนี้ “บริษัท” “ลูกค้า” “งานจริง” “ภาคเอกชน” “ภาคอุตสาหกรรม” ทราบดีมานานแล้ว
  • คิดว่า “สัมภาษณ์งาน” และ “การทำงานจริง” นี่ เค้าใช้เกรดทำงานกันเยอะแค่ไหนกันเชียว
  • คิดบ้างมั้ย ต้องวิเคราะห์งานให้ลูกค้า ทำระบบให้ลูกค้า ดีไซน์ usability ให้ระบบลูกค้า …. ทำได้ห่วย จะอ้างอะไร? “หนูได้ A มานะคะ” เหรอ?
  • ไม่พอๆ มีอีก ยิ่งเกรดดี งานห่วย ยิ่งทำให้เกรด จากคณะวิชา หรือมหาวิทยาลัยนั้นๆ “ไร้ค่า” ในสายตาลูกค้าคนนั้น และ/หรือ บ. ที่รับไปทำงาน
  • เหมือนกับที่ อ. มหาลัยทุกวันนี้ ไม่ดูเกรด ม.ปลาย ของเด็กจาก “หลายโรงเรียน” เพราะว่ามัน “ไร้สาระ” บอกอะไรไม่ได้
  • อีกอย่าง ที่ผมเคยบอกไปน่ะแหละ “เกรด” น่ะ มีกี่วิชากัน กี่แห่งกัน ที่จะใช้ metric ตัวเดียวกับภาคเอกชน ภาคอุตสาหกรรม บริษัท ลูกค้า?
  • ก็วิธีวัดผลมันต่างกัน จะไปบอกอะไรได้ดีแค่ไหนเชียว? เผลอๆ ยิ่งจะให้ผลตรงข้ามด้วยซ้ำ
  • เช่น ถ้าผมจะวัดประสิทธิภาพ DB … เอา Compiler ที่ดีที่สุดมาวัดผลในฐานะ DB รับรองได้คะแนนห่วยที่สุด
  • เพราะว่า DB ที่ดี ใส่อะไรเข้าไป ต้องออกมาแบบนั้น แต่ Compiler จะแปลงหมดเลย … ว่างั้นเถอะ

ไม่ได้บอกว่าวิธีการวัดผลมันไม่ดี หรือว่าต้องทำลายระบบเกรดทิ้งหรอกนะ เพียงแต่อยากจะบอกกับน้องๆ นักศึกษาแค่นั้น ว่าอย่าไปยึดติดกับเกรดมันมากเกินไป

ไม่ต้องมาอ้างมากมายหรอก ว่า “กลุ่มอื่นเค้าแจก A กันเยอะเลย” หรือว่า “ม.อื่นเค้าแจก A กันเยอะเลย” ฯลฯ มันไม่มีบรรทัดฐาน มาตรฐานกลางอะไรอยู่แล้ว

แต่อย่างน้อยๆ ผมไม่เคยทำงานสองมาตรฐาน ผมสอบทุกกลุ่มด้วยมาตรฐานเดียวกันหมด ก็แล้วกัน

ปัญหา ความเคยชิน “ก๊อปโค๊ดมาแก้” #2

สืบเนื่องจาก entry ที่แล้ว

ทำไมรู้สึกว่านับวันยิ่งเจอกรณีที่ confirm ความรู้สึกแย่ๆ กับเรื่องนี้ก็ไม่รู้ … แล้วคนที่ทำให้เราต้องมาหงุดหงิดกับเรื่องแบบนี้ก็นะ ทำไมถึงไม่พัฒนาอะไรเลยก็ไม่รู้

แต่วันนี้หายหงุดหงิดแล้วล่ะ ปลงแทนดีกว่า ….. ว่าแล้วก็ไปถ่ายรูปเล่นดีกว่า ผ่อนคลาย คลายเครียดกันดีกว่า

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

แต่ว่าถ้าทำกลับกัน คือ ไปทำตามเทคนิคเฉพาะเรื่องก่อน แล้วค่อยพยายามแก้ไขพื้นฐานให้รองรับสิ่งที่ตัวเองต้องการทีหลัง มันจะยากกว่ากันมาก … แต่ว่ามันจะเหมือนกับว่า “ได้ผลเร็ว” เพราะว่าสิ่งที่ทำให้ได้ผลเฉพาะอย่าง และเห็นผลเฉพาะอย่างเนี่ย มันคือเรื่องเทคนิค

แต่นั่นก็เลยทำให้ทุกอย่างยากขึ้น และคุณต้องแก้ไข Model พื้่นฐานของระบบ ในลักษณะ Hack หรือ Workaround มากขึ้น และถึงจุดหนึ่งมันจะยิ่งทำให้ทุกอย่างมันซับซ้อนมากขึ้น และการนำเอาเทคนิคอื่นๆ เข้ามาเพื่อบรรลุวัตถุประสงค์อื่นๆ ในงาน มันจะยากขึ้น และพบปัญหามากขึ้น และจุดนี้เองที่น้องๆ มักจะเริ่มเจอปัญหาชัดๆ และมักบอกว่า

เอาไอ้นี่มาใช้แล้วมีปัญหาครับ/ค่ะ

ซึ่งจริงๆ ปัญหาที่แท้จริงคือ พวกน้องไม่ได้เริ่มจากพื้นฐานตั้งแต่แรกน่ะครับ คือ ไม่ได้วางหรือคิดระบบตั้งแต่พื้นฐาน พอจะทำอะไรก็เลยยากไปหมด และมีปัญหาโผล่มาได้ทุกที่ เพราะว่ามันเป็นการทำโปรเจคจาก “นอกเข้าใน” ไม่ใช่การพัฒนาจาก “แก่น” ของระบบเลย

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

ปัญหา ความเคยชิน “ก๊อปโค๊ดมาแก้”

ว่าจะไม่เขียนเรื่องนี้แล้ว แต่ว่าเขียนหน่อยก็ดี จากเด็ก ICT ที่ทำโปรเจคกับผมเอง ขอยก conversation มาทั้งหมดกันแล้ว

rp: ./configure: งานเป็นไงมั่งน้อง
IKE::: ก้อกำลังปั่นค่ะ
rp: ./configure: เหอๆ
IKE::: ได้ พี่คนหนึ่งช่วยสอน
rp: ./configure: ปั้นเหน่งป่ะ?
rp: ./configure: ใช่ @punneng ใน twitter หรือเปล่า
IKE::: ได้ข่าวว่ารู้จักกะอาจารย์ด้วย
IKE::: ช่ายคร๊าา
rp: ./configure: อ่อ
IKE::: พี่เค้าสอน แบบว่ายาวนานมาก
IKE::: วัน ละ 5hr ได้
IKE::: เอากาน แบบว่า รื้องานทำใหม่กานเลย
rp: ./configure: แล้วดีขึ้นมั้ย
IKE::: ไม่แงะcode เก่าแบบไม่เข้าใจ เร่ิมทำใหม่เลยน้อง ประมาณนั้น
IKE::: ดีขี้น มากมายอะคร่ะ
IKE::: เข้าใจ ตั้งแต่แรกเลย
rp: ./configure: ได้หมอนี่สอน ค่อยยังชั่วหน่อย
IKE::: รู้งี้ รู้จักพี่เค้า แต่แรกดีกว่า
rp: ./configure: เฮ้อ ก็พวกคุณมันเล่นไม่ทำความเข้าใจอะไรเลยนี่หว่า
IKE::: งานคงออกมาหรูกว่านี้เยอะ
rp: ./configure: ก็พวกคุณเล่นไม่พยายามทำความเข้าใจอะไรจริงๆ จังๆ นี่หว่า …. เล่นลอกโค้ดๆ แล้วก็มาพยายามแก้ๆ กันอย่างเดียว
IKE::: ช่ายๆๆ
IKE::: เปลี่ยนแนวคิดใหม่ด้วย
IKE::: พี่เค้า สอน ดีมากเลย สอน ให้คิดแบบที่ควรจะเป็น
rp: ./configure: ก็ดีแล้ว
rp: ./configure: ปัญหาของพวกคุณ (และเด็กทุกคนที่รู้จัก) คือ ไม่ทำความเข้าใจ ไม่พยายามทำความเข้าใจ และปฏิเสธที่จะทำความเข้าใจ ใน “แนวคิด” ใน “วิธีคิด” และใน “คอนเซปท์” ทุกคนพยายามลัดไปที่โค้ดหมด
rp: ./configure: ลอกโค้ด เอาโค้ด รันได้ แก้โน่นนี่ ปะๆๆ มันเข้าไป
rp: ./configure: อะไรแบบนั้น
rp: ./configure: ก็ดี ได้เริ่มคิดใหม่
IKE::: ค่ะ ยอมรับผิดแต่โดยดี
rp: ./configure: ดีกว่าไม่ได้เลย
IKE::: แต่พี่เค้าสอน ทุ่มเท มากอะค่ะ
IKE::: เดี๋ยววัน อาทิต นี้ ก้อ ไปให้เค้าสอน อีก
IKE::: พี่เค้าแบบว่า ไม่เน้น งานเสร็จ แต่ว่าเน้น เข้าใจในสิ่งที่ทำมากกว่า

อยากจะกราบขอบคุณ @punneng มากๆ เลย แต่คงไม่ได้เจอตัวจริงๆ กันซะที ก็เลยทำมันซะที่นี่น่ะแหละ แล้วก็อยากจะฝากสิ่งที่ผมคุยกับน้อง IKE ให้เป็นอุทาหรณ์กับน้องคนอื่นๆ ด้วยนะครับ

ว่า “อย่าลัดไปที่ coding” นะครับ มันไม่ค่อยจะช่วยอะไรคุณหรอก ถ้า paradigm ของความคิดมันเหมือนๆ เดิมที่คุณคุ้ยเคยมา ก็ดีไป แต่ว่าถ้ามันไม่ใช่แบบนั้น มันจะแย่เอาง่ายๆ และถ้ามันเป็นการแก้ไขง่ายๆ เล็กๆ น้อยๆ ก็อาจจะโอเค แต่ว่าถ้ามันเป็นเรื่องของการพัฒนาโปรแกรมขนาดใหญ่กว่านั้นขึ้นมาเมื่อไหร่เนี่ย ถ้าไม่กลับไปที่พื้นฐาน (back to basic) จะแย่เอาง่ายๆ เพราะว่ามันอาจจะทำให้อะไรหลายๆ อย่างแย่ในระยะยาวได้ง่ายๆ เลยทีเดียว

rp: ./configure: ปัญหาของพวกคุณ (และเด็กทุกคนที่รู้จัก) คือ ไม่ทำความเข้าใจ ไม่พยายามทำความเข้าใจ และปฏิเสธที่จะทำความเข้าใจ ใน “แนวคิด” ใน “วิธีคิด” และใน “คอนเซปท์” ทุกคนพยายามลัดไปที่โค้ดหมด
rp: ./configure: ลอกโค้ด เอาโค้ด รันได้ แก้โน่นนี่ ปะๆๆ มันเข้าไป

จริงอยู่นะครับ การเริ่มต้นแบบนั้นมันทำให้เรา “เหมือนจะ” สร้าง application ที่เป็นรูปเป็นร่างขึ้นมาได้รวดเร็วกว่า แต่ว่ามันจะทำร้ายเราในระยะยาวนะครับ เมื่อเวลาที่เราต้องเพิ่มโน่นเพิ่มนี่ แก้โน่นแก้นี่ ฯลฯ ซึ่งจะต้องทำมันอยู่แล้ว …

จริงๆ แล้วด้วยความสะดวกของเครื่องมือสมัยนี้ (ยกตัวอย่างเช่น bootstrapping method ต่างๆ ใน framework สมัยใหม่ ที่สร้างโครงของโปรแกรมพร้อมใช้งานให้เราเลย หรือว่าพวก migration tools และ version control ต่างๆ) มันช่วยให้เราทำงานขึ้น application ได้เร็วมากๆ อยู่แล้ว ดังนั้นเราควรใช้เวลากับการออกแบบดีไซน์ และคอนเซปท์มากขึ้นกว่าเดิม ไม่ว่าจะเป็นเรื่องของ entity relation ต่างๆ เรื่อง use cases ต่างๆ และเรื่องของ usability เป็นต้น และถึงเวลาที่จะต้องไปขึ้น application มันจะทำได้ง่ายและรวดเร็วมาก

สืบเนื่องเรื่องนี้นะครับ วิชา Object-Oriented Programming ที่ผมสอนเทอมนี้ ดู coding แล้ว “ห่วยบรม” ส่วนหนึ่งก็เพราะว่าผมยังไม่ได้สอนลง coding เลย ผมถือว่าผมจัดสอบส่วนของ Lab (ที่เป็น coding) เพื่อเก็บข้อมูลเบื้องต้นเท่านั้น ว่าพื้นๆ ฐานๆ ของน้องๆ ในเรื่องของการเขียน code (ที่ผมย้ำนักหนา .. ว่าเรียนคอนเซปท์ไปอย่างหนึ่งเนี่ย มันมากพอที่จะไปหัด coding เอง ซึ่งก็ดูเหมือนจะไม่ทำกันเลย) นั้นเป็นอย่างไรบ้าง

แต่ว่าเท่าที่ดูจากความเข้าใจ concept ก็ดูค่อนข้างจะดีพอสมควรแล้วล่ะครับ

ล่องลอย …. เคว้างคว้าง … กลางทะเล

“ปล่อยไปตามลมเลย” เพลงเก่าๆ ของวงเก่าๆ ดังก้องอยู่ในหู ตั้งแต่ต้นเพลง

ล่องลอยไปไกลความจริง ทิ้งมันเสียความทรงจำ ปล่อยมันไปตามเวรกรรม เรื่อยไป

และท่อนสร้อย

ปล่อยไปตามลม จะพัดพาเราไป จะไปไหนก็แล้วแต่สายลม

วันนี้ประชุมสภามหาวิทยาลัยเป็นครั้งแรก ได้ฟังทัศนคติจากกรรมการผู้ทรงคุณวุฒิหลายท่าน ได้แนวคิดที่สำคัญต่างๆ มากมาย ที่จริงๆ น่าจะถือว่าเป็นการ “เรียกสติ” ภาคการศึกษา และ “เรียกสติ” มหาวิทยาลัย ไม่เพียงแต่ศิลปากรเท่านั้น แต่ว่าหลายๆ ที่อีกด้วย

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

การขับเคลื่อนภาคการศึกษา โดยเฉพาะมหาวิทยาลัย ในความรู้สึกของผม มันคือ “แพ” ใหญ่ๆ ที่กำลังลอยไปตามกระแสน้ำเรื่อยๆ น้ำแรง ก็ไปเร็ว น้ำเอื่อย ก็ไปช้า แพนี้มีพื้นที่ใหญ่มากพอให้ทุกคนอยู่กันอย่างสบายตามอัตภาพ ติดเกาะติดแก่งติดสันดอน ก็ช่วยๆ กันแก้ๆ ไปเป็นคราวๆ โดยคนที่อยู่ใกล้ๆ ขอบแพตรงที่ติด คนทั่วไปที่อยู่กลางแพ ไม่ได้รู้สึกรู้สารู้อะไรด้วยเลย

“แพ” ไม่เหมือนเรือ มันไม่มี “หัวแพ” เหมือนที่มี “หัวเรือ” ที่อยางน้อยให้เราได้รู้ว่ามันกำลังมุ่งหน้าไปทางไหน แพนี้อาจจะกำลังหมุนคว้างๆ อยู่กลางแม่น้ำ ที่เหมือนจะไหลไปข้างหน้าก็ได้ใช่หรือไม่ เราไม่สนใจ

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

com_cc_1.001-001.jpg

(ภาพจาก presentation หนึ่งของผม ให้กับศูนย์คอมพิวเตอร์ ม.ศิลปากร ในวันรับตำแหน่งผู้อำนวยการ)

เราจึงไม่เคยมองถึง Road Map เราจึงไม่เคยมองเห็น The Road Ahead … เราไม่เคยสนใจ

ที่สำคัญกว่านั้น ถ้าเป็นที่ๆ เราแทบไม่เคยไป หรือไม่มีใครเคยไปมาก่อน ไม่มีเส้นทางน้ำ ไม่มีถนน ไม่มีอะไรทั้งนั้น เรามักจะปิดกั้นตัวเอง ด้วยคำว่า “ไม่มีทางเดิน” แล้วก็ปฏิเสธต่างๆ นานา หาเหตุหาผลต่างๆ นานา เพื่อบอกว่า ไม่สามารถไปทางนั้นได้

เราแทบไม่คิดถึง “การบุกเบิกเส้นทาง” และ “การตัดถนน” เอาเสียเลย

com_cc_2.024-001.jpg

(ภาพจากอีก presentation ของผมเอง ในวันเดียวกัน)

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

ในภาวะเศรษฐกิจเช่นนี้ ผมไม่แน่ใจว่าเราได้เตรียมตัวเตรียมใจให้นักศึกษารุ่นปัจจุบัน รับรู้กับความเป็นจริงขนาดไหน ว่าพวกเขาต้องเผชิญกับภาวะ “การตกงาน”​และ “การไม่จ้างงาน”​แค่ไหนเมื่อจบไป

เราคงไม่สนใจอะไรเท่าไหร่ เพราะว่าลักษณะหน่วยงานของเรา เป็นหน่วยงานที่เมื่อไหร่ก็ตามที่สังคมเกิดเหตุการณ์แบบนี้ขึ้น เรายิ่งสบาย ส่วนหนึ่งก็เพราะว่า “ภาวะตกงานแฝง” …​ หางานทำไม่ได้ ก็เรียนมันต่อไปก่อน และแล้วเราก็ขยายกำลังรับ เปิดปริญญาโท กันต่อไปอย่างสนุกสนาน

ปัญหาแบบนี้ ทั้งหมดนี้ และมากกว่านี้ ผมเคยได้ยินอาจารย์ผู้ใหญ่หลายท่าน ผู้ทรงคุณวุฒิหลายท่าน และท่านที่ผมรักและเคารพ ทั้งในความคิดและตัวตนของท่าน หลายต่อหลายท่าน บ่นให้ฟังซ้ำแล้วซ้ำเล่า ซ้ำแล้วซ้ำอีก … ตัวเองบ่นเองก็เยอะ (ถ้าใครเคยฟังที่ผมพูดในงาน Blognone Tech Day 3.0 ล่ะก็ นั่นเป็นเพียงแค่ส่วนเดียวเท่านั้น)

แต่ว่าท่านเหล่านั้นสรุปให้ผมฟังอย่างน่าเศร้าใจว่า “ก็บ่นกันมาแบบนี้ ปีที่แล้วก็บ่นกันมาแบบนี้ ปีก่อนหน้านั้นก็บ่นกันมาแบบนี้ …​ ” และก็คงจะ so on and so on … และแล้วเราก็ผ่านมันไปปีต่อปี ปีหนึ่งผ่านไป ปีหนึ่งก็จะผ่านไปอีก

so on, so on, so on.

ล่องลอยไปไกลความจริง ทิ้งมันเสียความทรงจำ ปล่อยมันไปตามเวรกรรม เรื่อยไป

และท่อนสร้อย

ปล่อยไปตามลม จะพัดพาเราไป จะไปไหนก็แล้วแต่สายลม

เพลงๆ หนึ่งจากวงที่ไม่ค่อยจะดังเท่าเมื่อกี้ (วงนี้ไม่ดังเลย เพลงดังก็ไม่มี … แต่ว่าผมชอบเพลงนี้มาก ถึงขนาดจำเนื้อได้เกือบแม่น ได้ยินสมัยเด็กๆ — ดังนั้นถ้าผิดพลาดบ้างขออภัย) ดังขึ้นในหูผม

เวิ้งว้าง แสนไกล สุดสายตา สุดขอบฟ้า มองหาใครไม่มี
คลื่นลูกน้อย ล่องลอย ตามสายลมที่มี
เป็นอย่างนี้ สิ้นหวัง มาช้านาน
ล่องลอยไป ไร้จุดหมาย ในท้องทะเล
สิ่งที่หวัง คือไป ให้ถึงฝั่ง
หากวันนั้น ถ้ามี ดังที่หวัง
คลื่นน้อยคง มีหวัง เจอหาดทราย
แต่บางครั้ง คลื่นแรง ดังใจเร่าร้อน
แต่บางครั้ง คลื่นอ่อน น่าใจหาย
และบางครั้ง หมดแรง เช่นความตาย
ผลสุดท้าย เกยหาด จางหายไป
ตัวฉัน เคว้างคว้าง ใจกลางทะเล
จะหันเห ทางไหน ไม่เห็นฝั่ง
หากวันนั้น ถ้ามี ดังที่หวัง
แนบกายลง บนฝั่ง บนหาดทราย

กราบขอบพระคุณกรรมการสภามหาวิทยาลัยผู้ทรงคุณวุฒิ ท่านรองผู้อำนวยการสำนักงบประมาณ ท่านดวงสมร วรฤทธิ์ และท่านบุญชัย เบญจรงคกุล ที่ให้ข้อคิดดีๆ แก่มหาวิทยาลัยศิลปากรไว้ ณ ที่นี่ด้วยครับ

สูตร

สิ่งที่พบบ่อยเวลาที่มีการนำเสนองานหรือว่าพูดถึงอะไรก็ตามที่มีแบบจำลองทางคณิตศาสตร์ (Mathematical Model) คนนำเสนอมักจะพูดกันว่า

“สูตร” (เช่น “เป็นไปดังสูตร” เป็นต้น)

ผมไม่ได้เรื่องมากหรือว่าจ้องจับผิดคนหรือว่า Picky มากกว่าไปกับเรื่องพวกนี้หรอกนะ แต่ว่าผมเชื่อว่ามันให้ความรู้สึกต่างกัน ระหว่าง

  • แบบจำลองทางคณิตศาสตร์
  • ความสัมพันธ์ระหว่างสิ่งต่างๆ ในเชิงคณิตศาสตร์
  • การมองคณิตศาสตร์เป็นภาษาๆ หนึ่ง

กับการใช้คำว่า “สูตร” ซึ่งมักจะให้ความรู้สึกในเชิงคำนวณ ซึ่งแน่นอนว่าไม่ผิดทั้งหมด เพราะว่าในท้ายที่สุดแล้วความสัมพันธ์เชิงคณิตศาสตร์ (Mathematical Relation) นั้นท้ายที่สุดมักถูกนำไปใช้ในการคำนวณหา Output จาก Input หรือว่าในทำนอง R(Input) = Output อยู่แล้ว

แต่ว่าจุดมุ่งหมายในการพูดถึงความสัมพันธ์นั้นๆ น่ะ มันไม่ใช่ความรู้สึกที่อยากได้ผลลัพธ์แต่ถ่ายเดียว แต่ว่าหมายถึงความต้องการที่จะบอกว่าอะไรสัมพันธ์กับอะไรอย่างไร อะไรส่งผลถึงอะไรอย่างไร มากกว่า

มันเป็นเรื่องของ ภาษาของเหตุและผล ซึ่งเป็นแบบจำลองในลักษณะ abstraction จากความเป็นจริง ซึ่งเป็นความรู้สึกที่ implied มาจาก “ความสัมพันธ์ทางคณิตศาสตร์” และ “แบบจำลองทางคณิตศาสตร์”

ไม่ใช่การมุ่งจะเอาผลโดยไม่คิดถึงเหตุ ซึ่งเป็นความรู้สึกที่ผมมีกับคำว่า “สูตร”

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