[Book] Google + Happiness

Tags

book, google, happiness, review

คิดอย่างผู้นำ ทำอย่าง Google
by Eric Schmidt & Jonathan Rosenberg
ความหนา 364 หน้า

ตอนแรกที่หยิบหนังสือเล่มนี้ขึ้นมานึกว่าจะเป็นชีวประวัติของ Google แบบที่หนังสือของบริษัท tech startups อื่นๆชอบทำ แต่เปล่าเลย หนังสือเล่มนี้ไม่ได้เน้นประวัติ แต่กลับสรุปแนวคิดการทำงานที่ Google มองว่าเวิร์คและมีประโยชน์จากมุมมองของ CEO และหัวหน้าฝ่าย Products และหยิบออกมาเล่าเป็นหัวข้อสั้นๆ ตัวอย่างง่ายๆแต่น่าสนใจ

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

ในรายละเอียดเล็กๆน้อยๆของเนื้อหา ผู้แต่งได้สอดแทรกพฤติกรรมในองค์กรบางอย่างที่ทำลายประสิทธิภาพของการองค์กรที่ขับเคลื่อนนวัตกรรมใหม่ (ตัวอย่าง เช่นหัวข้อ อย่าไปฟังพวกฮิปโป, กฏเลขเจ็ด, ไล่เนฟออกไป รักษาดีวาไว้)

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

ปัญหาเกี่ยวกับการจ้างคนและวิธีการแก้ปัญหาที่ Google ทำได้ดีมากๆ (เช่น การทดสอบแบบ LAX, สัมภาษณ์แค่ 30 นาที, และเงื่อนไขที่จะไม่ยอมคุณภาพของการจ้างลง, ปล่อย M&M ไปและเก็บลูกเกดไว้)

วิธีการแก้ปัญหาของเวลาที่คนสายวิทยาศาสตร์ชนกันเอง (ในหัวข้อ “คุณถูกทั้งคู่”)
วิธีการบริหารการประชุมให้มีประสิทธิภาพ (ในหัวข้อ “การประชุมต้องมีเจ้าภาพ”)
วิธีการบริหารเวลาและทรัพยากร (ในหัวข้อ “ใช้เวลา 80% กับสิ่งที่สร้างรายได้ 80% ให้บริษัท”, “70/20/10”, “เวลา 20%” – สองหัวข้อนี้เล่าถึงวิธีการทำงาน prototype แบบต้นทุนต่ำของ Google ทั้งที่ตอนมีเงินมหาศาลแล้วด้วย)

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

สรุปโดยรวม: 91%
เป็นหนังสือที่น่าอ่าน และเปิดมุมมองเกี่ยวกับการทำงานในวงการ IT & Tech ได้ดีทีเดียว

ความสุข
ประเสริฐ เอี่ยมรุ่งโรจน์ (แกะดำทำธุรกิจ)
ความหนา 243 หน้า

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

วิธีการเลือกคนที่จะทำธุรกิจด้วย

แนวคิดเกี่ยวกับการตัดสินใจ (ทั้งด้านความเร็วและการเลือกเรื่องที่ต้องตัดสินใจ)

วิธีการบริหารแบบ forward planning & scenario planning

รากฐานของความคิดสร้างสรรค์

สาเหตุของการเป็นคน “มีของ” และ “คุณภาพ”

ผลลัพธ์ลูกโซ่ของการคอรัปชั่นที่คนทั่วไปมองไม่เห็น (ที่มีต่อครอบครัวผู้ทำ)

2-pizza rule ของ Jeff Bezos (Amazon founder)

Pitch

การตัดสินใจจากความรู้สึกที่มีประสิทธิภาพกว่าตรรกะ

ผลลัพธ์ของการทำสิ่งที่ชอบด้วยความสนุก

การพุ่งเป้าที่ความเป็นเลิศ + วินัย + ความคิดสร้างสรรค์

ทำเพื่อทุกคน = ขาดจุดเด่น และมีแต่จุดด้อย เพราะขีดจำกัดในชีวิตจริงมีมากกว่าข้อดี

ขีดจำกัดและความสามารถในการเปลี่ยนแผน + ความคิดสร้างสรรค์ = new solution

Only the paranoid survives

กฏกติกา มารยาทในการประชุมของ Google

ประวัติของ Tesla บริษัทที่กำลังเปลี่ยนโลก(ไปในทางที่ดี)

สรุปโดยรวม: 93%
เป็นหนังสือที่อ่านง่าย เปิด และกระตุ้นให้เกิดความคิดในการพัฒนาตัวเอง

Agile Thailand 2015 (ภาค 2)

Tags

docker, haskell, sketchnote

เก็บตก Agile Thailand 2015 (ต่อ) จาก Blog ที่แล้ว
คำเตือน Blog นี้ค่อนข้าง geek ถ้าสนใจเฉพาะแนว management ให้อ่านข้ามไป session ที่สามครับ

3. Joomla Continuous Delivery with Docker

Session speaker: Jirayut Nimsaeng (Dear)

Session นี้ว่ากันด้วยเรื่องของเทคโนโลยี Docker ที่กำลังมาแรงในตลาด server

ก่อนจะอธิบาย Docker ขอปูพื้นความเข้าใจของคำว่า “Virtual machine” (ที่จะเรียกกันย่อๆว่า VM) กันก่อนซักเล็กน้อยครับ

Virtual Machine คือ แนวคิดการจำลองระบบคอมพิวเตอร์ด้วย software ลงบนเครื่องคอมพิวเตอร์เพื่อทำงาน เช่น ถ้าคุณต้องการจะใช้งาน software ที่ต้องรันบน OS ซักตัวหนึ่ง วิธีทำแบบตรงไปตรงมาก็คือ ล้างเครื่องเพื่อติดตั้ง OS ที่จะใช้แล้วลงโปรแกรม ซึ่งยุ่งยากมาก

วิธีที่ดีกว่าก็คือการสร้างพื้นที่จำลอง(VM) ขึ้นมาแล้วติดตั้ง OS และโปรแกรมที่ต้องการลงไป VM พอใช้เสร็จก็ลบทิ้งไปได้เลยไม่กระเทือนระบบที่ใช้อยู่ หรือจะเซฟเก็บไว้เป็น image เอาไว้ใช้ในคราวต่อไปก็ได้

ปัญหาหลักๆของ VM ก็คือ มันเป็นการจำลองระบบทั้งระบบลงบนคอม (พูดง่ายๆก็คือลง OS ซ้อนลงบน OS อีกที) ประสิทธิภาพของมันก็เลยไม่ดีเท่าลง OS จริงๆ แต่ก็แน่ละถ้าต้องเลือกระหว่างนั่งลบระบบแล้วลงใหม่ทุกครั้ง VM ก็ยังเป็นทางเลือกที่ดีกว่าอยู่ดี

Docker คืออะไร ?

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

สำหรับในมุมของ software Docker ก็คือการรวมเอาโปรแกรมและสภาพแวดล้อมที่ใช้ทำงาน (เอาเฉพาะ program, library และ binary แต่ไม่รวมส่วน kernel) ไว้เป็นก้อนเดียวกันใส่ไว้ใน container เพื่อให้การติดตั้งและย้ายระบบไปเครื่องอื่นง่ายมากขึ้น

เมื่อไม่ต้องติดตั้งทั้งระบบลงไปเหมือนวิธีของ virtual machine การทำงานแบบ Docker จึงเป็นการใช้ physical จริง ไม่ต้องผ่านการจำลอง ส่งผลให้ประสิทธิภาพของระบบสูงกว่า VM มาก

และด้วยความเบาก็เลยช่วยให้สามารถสร้าง instance สำหรับทำงานได้จำนวนมากกว่าเมื่อเทียบกับ VM บน hardware เดียวกัน ดังนั้นเลยทำให้เกิดการต่อยอด เช่น การสร้างระบบที่ environment เหมือนกับ production ได้ง่าย, ทำซ้ำได้ตลอดเวลา และเร็ว!

นอกจากนี้ Docker ยังรองรับการ deploy แบบอัตโนมัติอีกด้วย (ผ่านทาง script ของ Docker เอง) และถ้านำไปทำงานร่วมกับ Automate testing เช่น robot framework ก็จะสามารถทำให้กลายเป็นระบบแบบ automate systems ได้ง่ายขึ้นมากเลย

ข้อมูลอ้างอิง: Slide เก่าของคุณ Dear
http://www.slideshare.net/winggundamth/joomla-continuous-delivery-with-docker

ข้อมูลเพิ่มเติมอื่นๆ
http://www.docker.com/whatisdocker/
https://www.blognone.com/node/56627
https://www.blognone.com/node/59681
http://en.wikipedia.org/wiki/Docker_(software)

Action items ส่วนตัว: ลองเล่น Docker, ฝึกทำ automated deploy, robot framework

4. Functional programming (Haskell)

Session speaker: Weerasak (ป้อ)

Haskell เป็นภาษา programming ชนิด functional programming!

พูดแค่นี้ คนส่วนใหญ่จะงง ว่ามันคืออะไร แล้วยังไง?

ถ้าอธิบายแบบหยาบๆ ก็จะได้ประมาณว่า
– วิธีการเขียนโปรแกรมไม่เหมือนภาษาที่ programmer ทั่วไปในตลาด
– วิธีการคิดและรูปแบบคำสั่งการเขียนก็ต่าง (ยกตัวอย่าง เช่น ไม่มีตัวแปร !)

ส่วนคำนิยามแบบละเอียดกว่า(หน่อย) ก็คือ
– มันเป็น programming language แบบ strong static typing
– เป็นภาษาที่มีความสามารถเด่นในการทำ lazy evaluation, pattern matching

วิธีการคิดและเขียนโปรแกรมจะต่างจาก procedural, object-oriented ในแง่ของการออกแบบโค้ด (วิธีที่ทางคุณป้อนำเสนอ คือ การเขียนเคส, มอง patterns ให้ออกแล้วยุบ!)

ซึ่ง code ของ Haskell ในการแก้ปัญหา เช่น quicksort, factorial, Fizzbuzz problems จะสั้นและตรงไปตรงมามากกว่าโปรแกรมด้วยภาษาอื่น เช่น java, C

และด้วยลักษณะการทำงานแบบ lazy evaluation ก็ทำให้ทำหลายอย่างแบบที่ programming แบบอื่นทำไม่ได้ เช่น ประกาศตัวแปรเป็นอนันต์แล้วทำงาน (โดยที่ไม่ต้องจองหน่วยความจำจนล้น) หรือการคำนวณ factorial โดยไม่ต้องทำการสร้าง stack จำนวนมากเหมือน java (ประหยัด meomory กว่ามากมาย)

http://yannesposito.com/Scratch/en/blog/Yesod-tutorial-for-newbies/

ในแง่การทำงานแบบ concurrency
เนื่องจาก haskell ไม่มีตัวแปร (Immutable) เวลาทำงานแบบ concurrent จึงไม่ต้องใช้วิธีการแชร์ตัวแปร ไม่ต้องใช้การ block/wait แบบการทำ multi threads ในภาษาอื่นๆ เลยทำให้ optimize ได้มีประสิทธิภาพสูงมาก (เรียกกันว่า Haskell’s green threads)

ส่วนการนำไปใช้งาน
ภาษา Haskell (หรือ functional programming) มักจะนำไปใช้งานประเภท prototyping (เพราะทำงานได้เร็ว), งานที่ state ซับซ้อนมาก (ซึ่งไม่ค่อยเหมาะกับ OOP), Safe multithreading

ข้อมูลเพิ่มเติม:
http://learnyouahaskell.com/chapters
http://stackoverflow.com/questions/1604790/what-is-haskell-actually-useful-for
https://wiki.haskell.org/Why_Haskell_matters

Action items: ทดลองใช้ Haskell แก้ปัญหา marketing

5. เพิ่มประสิทธิภาพและประสิทธิผลการสื่อสารแบบ face-to-face ด้วยเทคนิค Sketchnote

Session speaker: หนุ่ม SPRINT3R

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

Sketch note คืออะไร?

http://sketchnotearmy.com/blog/2015/4/7/the-sketchnote-workbook-featured-sketchnoter-jeff-bennett.html

Sketch note คือวิธีการเขียนเรียบเรียงข้อมูลเพื่อสื่อสารความเข้าใจของตัวเองออกมาเป็นภาพ

สาระสำคัญในการเขียน Sketch note ประกอบไปด้วย

Title
การมีหัวข้อที่เด่นชัด จะช่วยให้คนดูเข้าใจประเด็นหลักที่จะสื่อได้ง่าย ส่วนการใส่รายละเอียดเพิ่มเติม เช่น ใครเป็นคนพูด ที่ไหน เมื่อไหร่ เป็น option เพื่อเสริมข้อมูลกันลืมได้ดี

Layout
การวางโครงสร้างหลักที่ดี จะช่วยให้พื้นที่เพียงพอที่จะใส่เนื้อหาที่จะนำเสนอ โดยปกติมักจะเริ่มจากบนซ้ายกระจายออก (basic) แต่มักทำให้เกิดการเอียงของน้ำหนักภาพได้ง่าย บางคนจะใช้วิธีกระจายออกจากตรงกลาง (เช่น mindmap) เรียงเป็นแถวแนวดิ่งลงไปเรื่อย วนออกเป็นก้นหอย ซึ่งส่วนใหญ่มักจะมีเส้นนำสายตาช่วยที่ชัดเจน เพื่อไม่ให้ผู้ชมสับสนลำดับของข้อมูล(ในกรณีที่ลำดับสำคัญ)

http://nuggethead.net/2013/09/preparing-sketchnote-format-visual-flow-and-materials/

Content
วิธีการเปลี่ยนข้อมูลให้น่าสนใจหลักๆ มีหลายวิธี เช่น ย่อให้เหลือแค่ Keyword สำคัญแล้วเน้น หรือ เปลี่ยน keyword ให้กลายเป็นรูปภาพ/สัญลักษณ์ วิธีนี้ทำให้ผู้ชมย่อยง่าย และจำประเด็นได้ดีกว่าการใช้ข้อความล้วน
เพราะสมองคนเราจับภาพได้เร็วกว่าตัวอักษร และเรายังเลือกใช้ขนาดของ text และสี เพื่อแบ่งแยกน้ำหนักของเนื้อหาให้แตกต่างกันได้อีกด้วย

http://graphitemind.com/post/19803717908/keeping-with-the-good-internet-theme-here-did

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

http://sachachua.com/blog/series/sketchnote-lessons-2/

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

ข้อมูลเพิ่มเติม:
http://nuggethead.net/tag/sketchnote/
http://graphitemind.com/
http://sachachua.com/blog/series/sketchnote-lessons-2/

Action items: ฝึกเอาไป map กับการเรียบเรียงไอเดียเวลา present งาน

Agile Thailand 2015 (ภาค 1)

Tags

2015, agile, baby, coaching, listening

สรุปประเด็นน่าสนใจจากงาน Agile Thailand 2015 (ภาคแรกครับ)

1. Agile Dialogue

by Kulawat (Pom) Wongsaroj + Bee

https://www.flickr.com/photos/dkuropatwa/4612194068/

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

การฝึกตัวเองในคลาสนี้ เพื่อช่วยให้รู้ตัวเองตลอดการประชุม รู้จักคุมจังหวะ
ไม่รีบผลีพลามยิงสวนขณะที่คนอื่นกำลังพูด วิธีการที่ง่ายและตรงไปตรงมาคือ
การกำหนด Rules ขึ้นมาร่วมกัน 3 ข้อ ที่จะช่วยกำกับ “สติ” ของทุกคน

ข้อแรก: พูดทีละคน 
เพื่อให้มีโอกาสได้ฟัง และ(จง)ตั้งใจฟัง

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

ข้อที่สาม: ไม่ตัดสินความคิดคนอื่น
การฝึกคิดที่มุ่งตัดสินความคิดคนอื่นจะทำให้เรารีบคิดหาช่องว่างหรือแนวทางอื่นมาหักล้าง จนทำให้สติในการตั้งใจฟังสาระ “หลุด” จากผู้พูด (นี่คือหนึ่งสาเหตุใหญ่ที่ทำให้คนคุยกันคนละหัวข้อ เพราะไม่ตั้งใจฟังคนอื่นพูดให้จบก่อน แต่รีบแทรกพูด) กับคนที่มี ego สูงจะต้องหาทางลด ego เขาก่อน (อาจโดยลดตัวเองก่อนด้วย)

นอกจากเรื่องการฟังแล้ว ใน Session ยังขยายไอเดียออกไปครอบคลุมถึงเรื่องอื่นๆ
ของ Agile ด้วยอีกเล็กน้อย ขอสรุปเป็นประเด็นสำคัญตามความคิดเห็นของผมเองเป็นข้อๆ ดังนี้ครับ

• Lean คือ วิธีการทำงานแบบที่มุ่งเน้นการลด watse ในกระบวนการ
• Agile เป็นหลักการทำงานที่ช่วยให้เข้าใจธรรมชาติของ software development process ง่ายขึ้น (ซึ่งจะมีหายแนวทางย่อยและ practices ย่อย)
• การที่ทีม commit งานไว้มากเกินไป = การทำงานแบบ overload ตลอดเวลา
• เมื่อทำงานหนักมาก ไม่มีจุดพัก กำลังใจคนทำงานจะหมดเร็ว
• เมื่อไม่มีเวลาพัก = ขาดโอกาสในการพัฒนาตัวเองหรือเสริมศักยภาพใหม่ๆ
• ทำให้ทีมท้อและพังได้ง่าย
• การทำงานให้ได้ผลงานมากที่สุด ตอบโจทย์ใคร นายจ้าง? ทีม?
• เมื่อ burn ชีวิตมากไป แล้วจะรักษา balance ของครอบครัว/การทำงานได้หรือ?
• ถ้าคนทำงานไม่ Happy อะไรคือ goal ระยะยาวร่วมกัน
• ปัญหาต้นๆของการคุยกับลูกค้าคือ ใช้ estimation = commit (ซึ่งมันคนละเรื่องกัน!)
• ถ้าคุยกันภายในทีมรู้เรื่องดี จะทำให้ประมาณ velocity ของทีมได้ดีขึ้นเรื่อยๆ
• คนทำงานด้วยกันจะประมาณเวลาได้ใกล้เคียงมากขึ้น
• และในกรณีที่ estimate ผิด ต้องรีบ feedback ให้ลูกค้าเร็ว เพื่อให้ลูกค้าปรับแผน/ตัดสินใจ

Action items (สำหรับตัวเอง): ฝึกสติจับประเด็นตอนประชุมแก้ปัญหา conflict ให้ได้ตลอดเวลา

 

2. การ coach ก็เหมือนการเลี้ยงลูกนั่นแหละ

by Juacompe + Chawin

Session นี้ว่าด้วยการสังเกตถึงการดูแลเด็กตัวน้อยๆคนนึง (ในช่วงที่กำลังพัฒนาพฤติกรรมขวบปีแรก) และนำมาเปรียบเทียบกับการโค้ชให้ผู้อื่น

ในช่วง 3 ปีแรกของอายุ จะเป็นช่วงที่เด็กกำลังเรียนรู้สิ่งต่างๆรอบตัว และสมองกำลังเริ่มเตรียมความพร้อมในการสร้างเซลล์ประสาทในแต่ละด้าน เช่น การควบคุมอารมณ์, ทักษะการเข้าสังคม, ภาษา (เป็นสาเหตุให้การฝึกภาษาใหม่หลังสามขวบทำได้ไม่ดีเท่าฝึกช่วงต้นอายุ)

(*) ข้อมูลอ้างอิง http://www.unicef.org/dprk/ecd.pdf

พัฒนาการในช่วงนี้จะเกิดขึ้นตลอดเวลา และนี่เป็นธรรมชาติของเด็ก

หันมามองกลับกัน เรามักจะได้ยินคำว่า “คนไม่ชอบการเปลี่ยนแปลง”
ซึ่งพอมาย้อนคิดดูอีกที มันอาจจะไม่จริงซะทีเดียวนัก เพราะที่จริงแล้ว คนเรามีความสามารถในการปรับตัว (adapt) เข้ากับสิ่งแวดล้อมสูงมากจนเราไม่ถือว่ามันคือการเปลี่ยนแปลง ยกตัวอย่างเช่น เราสามารถกินอาหารเช้าไม่ซ้ำกันแต่เราก็ไม่ได้มองว่ามันคือการเปลี่ยนแปลง ดังนั้นคำว่าเปลี่ยนแปลงจึงขึ้นกับขนาดของพฤติกรรมและความสำคัญที่ส่งผลต่อจิตใจผู้กระทำมากกว่าแค่ action เฉยๆ

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

แล้วกับเด็กทำอย่างไรล่ะ?

เรามักคิดว่าเด็กเล็กๆไม่เข้าใจการพูด แต่เราอาจมองข้ามไปว่าเด็กสามารถเข้าใจ body language (และฝึกฝนทักษะเพื่อเข้าใจได้เร็วมาก) การพูดคุย สัมผัส ปลอบ การชื่นชมเมื่อเขาทำถูกต้อง หรือให้กำลังใจเมื่อเขาทำผิดพลาด (ฝึกให้ positive ไม่ว่าจะ action จะ success หรือ failed) จะทำให้เขาค่อยๆมีความมั่นใจและเห็นคุณค่าในตัวเอง และทำให้เขากล้าลองทำในสิ่งใหม่ๆมากขึ้น โดยไม่มีแรงต่อต้านเท่าการบังคับให้ทำ

และก็คล้ายกันกับการโค้ชทีม

ที่ body language มีผลช่วยให้ทีมเชื่อมั่นในตัวเอง แม้จะลองแล้วผิดพลาด แล้วกล้าที่จะลองไปทำอะไรใหม่ๆเพื่อพัฒนาศักยภาพของตัวเองต่อ

หัวข้อย่อย1: ความแข็งแกร่งภายนอก vs. ความแข็งแกร่งจากภายใน

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

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

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

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

 

หัวข้อย่อย2: Emotional bank account

https://www.flickr.com/photos/ms308/16177956936/in/album-72157625647271859/

ในการแก้ปัญหา บางครั้งเราก็อาจจะ focus ผิดจุด
เช่นเราอาจจะทุบโต๊ะเพื่อเอาผลงานให้รวดเร็วจนมองข้ามความรู้สึกของผู้ร่วมงานไป

ซึ่งทำลาย Balance ระหว่าง เป้าหมายร่วมกัน กับ ความสัมพันธ์ระยะยาว

ถ้ามองว่าอารมณ์ตอบสนองของคนเหมือนบัญชีธนาคาร (Emotional bank) การทำดี ชื่นชม ให้กำลังใจ สนับสนุน ก็เหมือนการฝากเพิ่ม ส่วนการด่า ประชด ไม่เห็นคุณค่าต่อกัน ทำร้ายความรู้สึก เป็นการถอน

เมื่อวันนึงที่ emotional ใน bank ติดลบ คนก็เกิด bias
พูดอะไรเท่าไหร่เขาก็จะไม่ฟัง พูดธรรมดาก็กลายเป็นประชด พูดด่าลอยๆก็นึกว่าด่าตัวเอง แล้วบรรยากาศการทำงานร่วมกันทุกอย่างก็จะแย่ลง

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

เพื่อความยั่งยืนของความสัมพันธ์ระยะยาวที่จะนำไปสู่เป้าหมายร่วมกัน

Action items: ฝึกตัวเองให้ควบคุมอารมณ์ให้มั่นคง, long relationship is important than short goal

🙂