ประสบการณ์หลงป่า

(หากต้องการอ่านเฉพาะข้อคิดที่ผมได้ ข้ามบทนี้ได้เลยครับ)

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

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

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

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

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

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

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

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

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

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

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

ข้อคิดที่ได้

จัดสรรแผนและทรัพยากรให้ดี มีของสำรองไว้เสมอ แม้ว่าเส้นทางนั้นจะมีประสบการณ์มาแล้ว

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

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

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

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

เมื่อรู้ว่าไปทางที่ผิด การถอยหลังกลับ อาจเป็นสิ่งที่ควรทำ

เพราะเราไม่รู้หรอกว่าข้างหน้าจะเจออะไร มีสองปัจจัยคือ หนึ่ง ปัจจัยภายนอกที่จำกัดที่เราควบคุมไม่ได้ และ สอง ปัจจัยภายในหรือทรัพยากรที่จำกัดที่เรามี ซึ่งเรารู้ดี

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

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

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

ถ้าเลือกไปต่อข้างหน้า เครื่องมือชี้วัดและการตัดสินใจ ต้องแม่นยำ

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

สิ่งหนึ่งที่จะช่วยให้การตัดสินใจให้แม่นยำขึ้น นอกจากความเก๋าและประสบการณ์ของเราแล้ว นั่นคือเครื่องมือชี้วัด (Indicator) ที่เที่ยงตรง เป็นประโยชน์ เหมาะสม และเราใช้เป็น

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

และสุดท้าย เครื่องมือชี้วัด ต้องเหมาะสมและเราใช้เป็น ไม่ใช่เลือกจากการ Compare ฟีเจอร์ต่อฟีเจอร์แล้วว่าดีที่สุดในอุตสาหกรรม แต่ต้องดูจากการที่เราจะใช้งานมันว่าใช้เพื่ออะไร เช่น แผนที่ที่ดีที่สุดที่ทุกคนรู้ อาจเป็น Google Map, แต่ Google Map ไม่สามารถบอกเส้นทางเดินเท้าได้ละเอียดนะครับ ไม่สามารถสู้ OpenStreetMap ได้เลย ดังนั้น แอพหนึ่งที่สามารถใช้เข้าป่า วิ่งเทรล ได้ คือ Map.Me ที่ใช้แผนที่ของ OpenStreetMap และสามารถโหลดแผนที่มาก่อน เผื่อไม่มีสัญญาณ Internet ได้ด้วย (Google Map ทำ Offline mode ได้เช่นกัน)

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

เมื่อจนหนทาง ให้ถามหาผู้มีประสบการณ์

แน่นอน การถามผู้มีประสบการณ์เป็นวิธีการที่ดีที่สุด แต่เราต้องหาเขาเจอก่อนนะ

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

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

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

ฉลองให้กับความสำเร็จ

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

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

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

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

สรุป

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

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

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

ยุทธจักรของ Coach

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

ซึ่งการโค้ชไปให้ถึงเป้าหมาย ก็แบ่งได้ 2 แบบ

• โค้ช เพื่อ พาคนที่ต้องการไปเป้าหมาย, ไปให้ถึงเป้าหมายของเขา
• โค้ช เพื่อ พาคนไปให้ถึงเป้าหมายของเรา

ดังนั้น ผู้ที่รับการโค้ช (Coachee) จะต้องมีความอยาก มีความต้องการไปให้ถึงเป้าหมายก่อน หรือเห็นประโยชน์ก่อน ถึงจะเริ่มต้นโค้ชได้

คำว่า Agile Coach จะเรียกได้ว่า โค้ชเพื่อทำให้คนๆ หนึ่ง ที่ต้องการ เก่งในการทำงานในแบบ Agile ก็ว่าได้

ดังนั้นการโค้ชแต่ละครั้ง Coach จะมีสิ่งที่เรียกว่า Gap to Goal

• Competency (สมรรถนะ)
  • Knowledge (ความรู้) – ในสิ่งที่จะทำ
  • Skill (ทักษะ) ที่ก่อให้เกิดผลสำเร็จ
  • Attribute (คุณลักษณะ) ที่เป็นแรงขับดันให้แสดงออกเป็นพฤติกรรมไปสู่ผลสำเร็จ
• Mindset (วิธีคิด)
• Solution Tools (เครื่องมือ)

อาจารย์ปกรณ์โยงไปถึงเรื่องของก้อนน้ำแข็งใต้น้ำ (Iceberg) ว่าถ้า Coach ไม่เก่งหรือประสบการณ์ไม่ถึง จะเห็นแค่ Feeling (ความรู้สึก), Thinking (ความคิด) ของ Coachee

แต่ถ้า Coach เก่งๆ หรือมีประสบการณ์สูง จะดำดิ่งลงไปเห็น Belief (ความเชื่อ), Value (คุณค่า) ของ Coachee

ซึ่ง Coach ที่จะรู้ลงไปส่วนก้นบึ้งของ Coachee ได้, Coach จะต้องเป็นผู้ฟังที่เก่ง และ Coach จะทำให้ Coachee ที่รู้สึกแย่มีพลัง ได้จากการฟัง

Coach จะพยายามทำให้ Coachee ทำในสิ่งที่เขาคิด ดังนั้น Coach เองจะต้องไปตัดสินว่าสิ่งที่เขาคิดนั้นผิดหรือถูก

แต่นอกจากเป็นนักฟังที่ดีแล้ว Coach จะต้องเป็นนักเล่าที่ดีด้วย โดย จะเล่า 2 แบบ

• Story Telling : โดยเล่าเรื่องราวของตนเองหรือที่รู้มา โดยเป้าหมายเพื่อให้ผู้ฟังหยิบไปเทียบกับเหตุการณ์ของเขา และเอาไปทำได้ โดยวิธีการนี้ผู้ฟังมักเกิดความประทับใจ แต่อาจจะเอาไปคิดต่อไม่ได้ และนำไปทำต่อไม่ได้
• Story Coaching : โดยเล่าเหตุการณ์ โดยมีเป้าหมายเพื่อให้ผู้ฟังสามารถหยิบไป mapping ไปกับเรื่องของเขา และเอาไปทำได้

ซึ่งในขั้นแรก Coach จะต้องทำให้เขารู้ว่าเขาอยากจะเก่งขึ้น ดีขึ้น ผ่าน Story Telling หรือ Story Coaching เล่าให้ Coachee เกิดแรงบันดาลใจ (Metaphor)

และ Coach จะเป็นกระจกเงาเพื่อสะท้อน (Reflect) ให้กับ Coachee โดยผ่านการตั้งคำถาม ทั้งนี้ การถาม จะ ถามเพื่อให้เขาเห็น มิใช่ ถามเพื่อให้เราเห็น

ดังนั้น Coach ที่ดีจะ Reflect เพื่อให้เขาเห็นประเด็นได้เอง แต่ถ้า Reflect แบบชี้ประเด็นให้เขาเห็น จะเป็นในรูปแบบของพี่เลี้ยง (Mentor)

ระหว่างการถาม อาจจะเกิดได้ 2 เหตุการณ์ ซึ่ง Coach จะต้องพยายามรู้ตัวเสมอ ว่าคำถามนั้นเป็นไปในแบบโค้ชหรือพี่เลี้ยง (Mentor) กล่าวคือ

ถ้าถามแบบโค้ช จะถามเพื่อค้นหา (Exploration) เพื่อให้ Coachee เขาหาวิธีการแก้ปัญหานั้นๆได้ด้วยตนเอง แต่ถ้าถามแบบพี่เลี้ยง จะถามเพื่อวิเคราะห์ (Analysis) ร่วมกัน และหาวิธีการแก้ปัญหานั้นๆ ร่วมกับ Coachee

มาถึงตรงนี้ อาจารย์ปกรณ์ ได้วาดตารางเปรียบเทียบระหว่าง Coach, Mentor, Facilitator ให้เห็นความแตกต่าง ซึ่งค่อนข้างชัดเจนมากๆ ครับ

อาจารย์ปกรณ์ ได้อธิบายเพิ่มเติมว่า

• Coach จะมี Empathy คือ เราเข้าใจปัญหาเขา
• Mentor จะมี Sympathy คือ เราเข้าใจปัญหาเขา และเราเข้าไปช่วยแก้ รับมาเป็นปัญหาเรา

ซึ่งด้วยตารางเปรียบเทียบด้านบน จึงทำให้เราพอจะเห็นภาพชัดเจนขึ้นและแนวปฏิบัติว่าการเป็นโค้ชควรทำแบบใด

ยุทธจักรของ Agile

มาถึงช่วงที่พี่หนุ่มอธิบายเรื่องของ Agile ซึ่งได้เปิดด้วยการอธิบายความหมายของคำว่า Agile และประวัติความเป็นมาของแต่ละ Process ที่ถูกคิดขึ้นมา จนมาถึงจุดที่บุคคล 17 ท่าน ได้คุยหาจุดเหมือนในแต่ละ Process ที่ตนเองได้คิด ทดลอง และปฏิบัติซ้ำๆ จนประกาศเป็น Agile Manifesto โดยมี 4 Values และ 12 Principles (ซึ่งในรายละเอียด ผมเคยไว้ใน ScrumMaster in Action (Day 1) แล้ว เนื้อหาประวัติก็จะคล้ายกัน)

แต่มี Slide หนึ่งที่พี่หนุ่มได้สรุปให้เห็นภาพชัดเจนมากขึ้น ว่า

• Agile คือ วัฒนธรรมสำหรับการทำงาน ไม่ใช่ตำแหน่ง
• Agile ใช้การทำงานแบบเป็นรอบ (Iterative and Incremental)
• Agile ขับเคลื่อนจากคุณค่าของงานชิ้นนั้น (Value)
• Agile ทำให้ทีมสามารถส่งมอบคุณค่าของงานชิ้นนั้นได้บ่อยๆ เพื่อได้รับการ feedback ได้บ่อยๆ
• Agile คือการทำงานร่วมกันของทุกฝ่าย
• Agile ให้ความเคารพต่อผู้คน
• Agile ต้องเปิดเผยในสิ่งที่ทำ และเข้าใจ และเห็นในคำว่า “งานเสร็จ” ร่วมกัน
• Agile ต้องมุ่งมั่นที่จะปรับปรุงตัวเอง ทีม กระบวนการ ต่อเนื่องไปเรื่อยๆ
• Agile จะต้องใช้ Automation เช่น Automated Testing, CI/CD เพื่อลดงานและให้เกิดความเร็ว

จากนั้นพี่หนุ่มได้อธิบายการทำงานเป็นรอบๆ โดยเทียบกับกระบวนการพี่อาจารย์ปกรณ์และทุกคนน่าจะทราบดี นั่นคือ PDCA Cycle โดย 1 รอบกระบวนการ เท่ากับ 1 Sprint

และจะมีเพิ่มเติมนิดหนึ่งว่า ขั้นตอนที่ทำ (Do) ก็จะมีกระบวนการ PDCA ย่อยๆ อยู่ในนั้นด้วย ซึ่งจะเกิดขึ้นในระดับวัน (Daily Scrum)

ซึ่งถ้าไม่ใช้คำว่า Agile แต่พูดถึงในการทำงานจริงๆ พี่หนุ่มได้เขียนไว้ประโยคหนึ่งที่พอจะเข้าใจได้ง่ายกว่า คือ

Business Value is Deliver Incrementally
in Timeboxed Cross-Discipline Iterations

อันนี้ผมลอง map กับ PDCA เองว่า ถ้าพูดแบบจับต้องได้ คือ เรา Plan เพื่อตอบโจทย์ Business Value โดยใช้ Cross Functional Team เป็นผู้ Do และมีการ Deliver งานบ่อยๆ เพื่อให้เกิดการ Check และมี Feedback ที่เร็ว และ Adjust ปรับปรุงได้ ภายใน Timeboxed ที่กำหนด จากนั้นค่อยไปเริ่มชิ้นงานใหม่

ซึ่งสามารถใช้ได้ทั้งในระดับ Project, Feature และ Task เลยครับ

สรุปความเป็น Agile Coach

ดังนั้น ถ้าว่ากันแล้ว Agile Coach คือ โค้ชเพื่อทำให้คนๆ หนึ่ง ที่ต้องการเก่ง Agile ได้ เก่งในการทำงานในแบบ Agile

โดยสิ่งที่ Agile Coach จะต้องทำ แบ่งหน้าที่เป็น 40% Agile Expert และ 60% Behaviour Scientist

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

ปล. ผมคิดว่าเว็บที่ผมอ่านมา เขียนได้เข้าใจดีอยู่แล้ว รวมถึงผมไม่ได้ชำนาญด้วย ก็ขอตัดแปะ ยกมารวมไว้เลยแล้วกันฮะ

CRM คือ?

Ref: https://vgenz.com/

CRM ย่อมาจาก Customer Relationship Management หรือเรียกว่า การบริหารลูกค้าสัมพันธ์ ซึ่งก็คือการสร้างความสัมพันธ์กับลูกค้า โดยการใช้เทคโนโลยีและการใช้บุคลากรอย่างมีหลักการ เพื่อสรรหาวิธีที่จะสร้างความพอใจให้แก่ลูกค้าอันจะนำไปสู่ความจงรักภักดีในที่สุด

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

กระบวนการทำงานของระบบ CRM มี 4 ขั้นตอน

Ref: mindphp.com

1. Identify – เก็บข้อมูลว่าลูกค้าของบริษัทเป็นใคร เช่น ชื่อลูกค้า ข้อมูลสำหรับติดต่อกับลูกค้า
2. Differentiate – วิเคราะห์พฤติกรรมของลูกค้าแต่ละคน และจัดแบ่งลูกค้าออกเป็นกลุ่มตามคุณค่าที่ลูกค้ามีต่อบริษัท
3. Interact – มีปฏิสัมพันธ์กับลูกค้าเพื่อเรียนรู้ความต้องการของลูกค้า และเพื่อสร้างความพึงพอใจให้กับลูกค้าในระยะยาว
4. Customize – นำเสนอสินค้าหรือบริการที่มีความเหมาะสมเฉพาะตัวกับลูกค้าแต่ละคน

CRM Software คืออะไร

Ref: https://kobkrit.com/

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

CRM Software มักแบ่งออกเป็น 3 ส่วน

Ref: mindphp.com

1. Operational CRM – เป็นซอฟท์แวร์ front office ที่ใช้ช่วยจัดการกระบวนการทางธุรกิจที่เกี่ยวข้องกับลูกค้า ไม่ว่าจะเป็น sales, marketing หรือ service เช่น การจัดการข้อมูลติดต่อลูกค้า การเสนอราคา การบริหารฝ่ายขาย การเก็บข้อมูลพฤติกรรมลูกค้า ระบบบริการลูกค้า เป็นต้น
2. Analytical CRM – ระบบวิเคราะห์ข้อมูลลูกค้าที่รวบรวมได้จากส่วน Operational CRM หรือจากแหล่งอื่นๆ เพื่อแบ่งลูกค้าออกเป็นกลุ่มและค้นหากลุ่มลูกค้าเป้าหมายที่บริษัทสามารถนำเสนอสินค้า หรือบริการเพิ่มเติมได้
3. Collaborative CRM – ระบบช่วยสนับสนุนในการติดต่อปฏิสัมพันธ์กับลูกค้าผ่านทางช่องทางต่างๆ เช่น ติดต่อส่วนตัว จดหมาย แฟกซ์ โทรศัพท์ เว็บไซต์ E-Mail เป็นต้น รวมถึงช่วยจัดการทรัพยากรที่บริษัทมีคือพนักงาน กระบวนการทำงาน และฐานข้อมูล หรือ Database (ดาต้าเบส) ลูกค้า เพื่อนำไปให้บริการแก่ลูกค้าและช่วยรักษาฐานลูกค้าของบริษัทได้ดีขึ้น

CRM Software ที่มีดังๆ ในตลาด

Ref: https://kobkrit.com/ , wiki

• Salesforce
• Zoho
• Pipedrive
• Insightly
• Microsoft Dynamic CRM
• Sugar CRM
• Zendesk
• vTigerCRM
• AquaCRM
• Zanroo
• SignifyCRM

ทำไมต้องใช้ CRM System

Ref: https://kobkrit.com/

• ประสานงานระหว่างพนักงานขายของบริษัท ทำให้การทำงานรวดเร็วมากยิ่งขึ้น โอกาสที่จะทำงานผิดพลาดลดลง
• ช่วยเก็บสถิติทางความสามารถทางการขายและการช่วยเหลือลูกค้าของบริษัท รู้ว่าอัตราที่จะขายสำเร็จ (Activation Rate) มีเท่าไร่ เดือนนี้เราจะได้ขายได้ประมาณกี่บาท 3–4 เดือนที่แล้วเป็นอย่างไร เทียบกับปีที่แล้ว ปีนี้เราดีขึ้นหรือแย่ลง ลูกค้ากลับมาซื้อซ้ำหรือไม่ (Retention Rate) มากแค่ไหน Campaing Promotion ตัวไหนได้ผลบ้าง หากทำแล้ว ROI จะออกมาดีหรือไม่ เป็นต้น
• บางระบบ CRM มีระบบ AI ช่วยประเมินให้ด้วยว่า สิ้นปีนี้น่าจะมียอดขายเท่าไร่ จากการเก็บข้อมูลเพียงไม่กี่เดือนแรก ทำให้เจ้าของธุรกิจสามารถวัดผลและมีข้อมูลในการตัดสินใจทำการใดๆได้ หากมันกำลังจะแย่ ก็สามารถแก้เกมได้อย่างรวดเร็ว
• วัดผลการทำงานของพนักงานขาย ว่าวันวันหนึ่ง Sale แต่ละคนทำงานอะไรบ้าง คนไหนทำยอดได้สูงที่สุด เป็นข้อมูลหลักในการพิจารณาการเลื่อนขั้นหรือโบนัสได้อย่างโปร่งใสและชัดเจน

หลักการของ CRM (อ้างอิงจาก Saleforce)

Ref: https://kobkrit.com/

• Lead – คลังรายชื่อของคนหรือบริษัทที่ “สนใจจะมีปฏิสัมพันธ์” กับเรา หรือ“ไม่เคยได้ติดต่อ” ตัวอย่าง Leads เช่น รายชื่อคนกรอกแบบฟอร์มอะไรซักอย่างในเว็บไซด์ของเรา หรือคนที่เราเจอในงานแสดงสินค้า
• Accounts และ Contacts – คือกลุ่มคนที่ “เคยมีปฏิสัมพันธ์ร่วมกันมาก่อน” โดยที่ Accounts นั้นสำหรับเก็บรายชื่อบริษัทหรือหน่วยงาน ส่วน Contacts นั้นเก็บรายชื่อบุคคลที่ทำงานอยู่ภายใต้บริษัทนั้นๆ ความสัมพันธ์ระหว่าง Contacts และ Accounts ก็คือ Contacts นั้นจะทำงานอยู่ภายใต้ Accounts หนึ่งๆ หรืออยู่ภายใต้หลาย Accounts ก็ได้ (หากหนึ่งคนทำงานภายใต้หลายบริษัท) จึงต้องมีการดีไซน์ให้แยกส่วนกัน
• Opportunities – เมื่อคุยกับคู่ค้าที่เรารู้จักกันแล้ว และปรากฎว่ามีโอกาสที่จะได้ขายของให้แก่คู่ค้าคนนี้ เราก็ต้องทำการบันทึก Opportunities ซึ่งคือโอกาสที่เราจะได้ขายของให้ลูกค้า เข้าสู่ระบบ  CRM
  
  การบันทึกข้อมูลดิลที่เกิดขึ้นเข้าสู่ระบบ CRM เช่น วันที่แล้วพนักงานคนนึงรับออเดอร์ลูกค้าไว้ ปรากฎว่าวันนี้ป่วย แล้วลูกค้าโทรเข้ามา พนักงานอีกคนนึงเข้ามารับงานต่อ ก็สามารถอ่านดิลที่บันทึกไว้ในระบบได้และสานต่องานได้ทันที
  
  และการที่เราเอาดิลเข้าระบบ ต้องระบุว่าดิลนี้อยู่ในช่วงชีวิตใดของการขาย จากช่วงชีวิตการขายทั้งหมด (Sale Pipeline) ซึ่งจากข้อมูลนี้ทำให้เราสามารถประเมิน (คาดเดา) ยอดขายรวมที่จะถึงในสิ้นเดือนได้แม่นยำมากขึ้น
• Campaigns – นอกจากนี้เรายังสามารถ Link Opportunities เข้ากับ Campaigns (แคมเปญกระตุ้นยอดขายได้) ทำให้เรารู้ว่า Campaigns ไหนได้ผลหรือไม่ได้ผลบ้าง
• Quotation – CRM สามารถให้เราสร้างใบเสนอราคา (Quotation) จากข้อมูล Opportunities ได้ทันที ซึ่งประกอบไปด้วยข้อมูลสินค้า (Products) ที่เราป้อนเข้าไปในระบบ

Saleforce Software Structure

Ref: https://kobkrit.com/

• Chatter –  Social Network ที่รวมร่างกันระหว่าง Facebook (เพราะหน้าตาเหมือน) + Twitter (ต้องกด Follow) ใช้ในบริษัทนี่แหละ ใช้อัพเดทสถานะการขาย และติดตามข่าวสารความเคลื่อนไหวของการขายในบริษัท
• Opportunities – หน้าบริหารโอกาสที่จะขาย ใช้ดู, เพิ่ม, แก้ เวลาได้ Order หรือจะสร้าง Quotation มาเข้าที่หน้านี้นะจ๊ะ
• Leads – หน้าบริหารเพื่อนใหม่ ใช้ดู, เพิ่ม, แก้ เมื่อได้ Contact มาใหม่ๆ
• Accounts – บริหารรายชื่อบริษัทที่เป็นคู่ค้า
• Contacts – บริหารรายชื่อบุคคลที่เคยมีปฏิสัมพันธ์กับเรา เป็นสมาชิกภายใต้ Accounts
• Campaigns – เอาไว้สร้างและบริหารจัดการแคมเปญกระตุ้นยอดขายต่างๆ
• Dashboard – เอาไว้สร้างหรือบริหาร Dashboard เป็นหน้ารวมการแสดงผลสถิติความสามารถตาม KPI ต่างๆของบริษัทแบบเรียลไทม์ อาทิเช่น หน้า Dashboard ที่ประกอบไปด้วย กราฟแสดงผลยอดขายประจำเดือน และตัวเลขยอดขายรวม อันนี้ผู้บริหารจะชอบมาก เพราะจะถูกใช้เป็นข้อมูลประกอบการตัดสินใจต่างๆในบริษัท
• Tasks – เอาไว้บริหารจัดการ การมอบหมายงานให้เซลล์ของบริษัทต้องทำ เช่น “เตรียมใบเสนอราคา” ให้ลูกค้า หรือ “เขียน TOR” ให้ลูกค้า ซึ่งมักจะถูกผูกกับ Opportunity โดยเป้าหมายของมันคือ เพื่อผลักดันให้ Opportunity นั้นๆ สำเร็จ (ปิดการขาย)
• Notes – เอาไว้บันทึกข้อมูลต่างๆ เหมือนโปรแกรม Words มักจะถูกผูกกับ Opportunity เป็นโน๊ตข้อมูลประกอบให้กับ Opportunity
• Calendars – เอาไว้บริหารจัดการและแสดงผล Events ต่างๆ ที่เราต้องเข้าร่วมเพื่อจะได้ปฏิสัมพันธ์กับลูกค้า มีกำหนดเวลาเริ่มต้นและสิ้นสุด อาทิเช่น เข้าร่วมประชุมกับลูกค้าที่ตึก FYI เวลา 09.00–12.00 วันที่ 7 มกราคม (โดย Event จะหมายถึงงานที่เซลล์อย่างเราต้องเข้าไปร่วม โดยที่ไม่ต้องเตรียมตัวอะไรไป หากต้องเตรียมตัวอะไรไปต้องแยกงานการเตรียมตัวนั้นใส่ใน Tasks)
• Groups – ใช้จัดกลุ่มระหว่าง Sales ด้วยกันเอง มีหน้าตาเหมือน Groups ใน Facebook เลย อาทิเช่นตั้ง Sales Group นี้เป็น “ทีมกระเบื้อง” เวลามีข่าวสารอะไรที่เกี่ยวกับลูกค้ากระเบื้อง และอยากให้ทั้งกลุ่มรู้เรื่อง แต่ Post แปะที่กลุ่มได้เลย
• Reports – ใช้ออก Report สถิติต่างๆเป็นรูปแบบตาราง
• Files – บริหารจัดการ ดู และบันทึกไฟล์ ถูกผูกกับ Opportunity เป็นไฟล์ข้อมูลประกอบให้กับ Opportunity
• People – ดูรายชื่อสมาชิกผู้ใช้ CRM ทั้งหมดในองค์กรของเราได้ อยากจะส่ง Message หาใครก็ได้ที่นี่
• Cases – เมื่อลูกค้าเจอปัญหาหรือ Complaint อะไรมาที่บริษัท เซลล์ที่รับเรื่องต้องมาบันทึกที่ Cases ส่วนมากจะมีอีกคนนึงที่ดูแลเรื่อง Cases โดยเฉพาะ คอยแก้ปัญหาให้ลูกค้าเป็นกรณีพิเศษ
• Products – คือหน้าที่บริหารจัดการ ข้อมูลสินค้าและบริการของบริษัท ซึ่งจะเก็บแต่ข้อมูลผลิตภัณฑ์อย่างเดียว และต้องเชื่อมกับชุดราคา (Price Books) ที่ใช้เก็บข้อมูลราคาของแต่ละ Products ซึ่งทางบริษัทมีได้หลายชุดราคา อาทิเช่น ชุดราคาสำหรับผู้ค้าปลีก และชุดราคาสำหรับผู้ค้าส่งที่ราคาถูกกว่า สำหรับลูกค้าส่ง

Lead Status “สถานะของความสัมพันธ์”

Ref: https://kobkrit.com/

• Unqualified: หมายความว่า ไม่ได้ขายหรอก เค้าไม่สนใจ
• New: Lead ใหม่ ยังไม่เคยคุยกัน เราเลือกอันนี้เป็นค่ามาตรฐาน
• Working (ทำความรู้จัก): Lead นี้ได้ลองเริ่มคุยมาบ้างแหละ พอเริ่มรู้จักกันและว่าต้องการแบบไหน
• Nurturing (กำลังจีบ): เมื่อคุณได้คุยซักพัก มีโอกาสที่จะซื้อกับเรา แต่ตอนนี้ยังไม่สนใจ ด้วยเหตุผลร้อยแปด พยายามส่งข้อมูลให้มันเรื่อยๆ ส่ง E-mail ไปบ่อยๆ ส่ง Catalog ไปเรื่อยๆ โทรไปจีบเรื่อยๆเดี๋ยวก็คงสนใจมาซื้อกับเราซักวัน
• Qualified (จีบสำเร็จ): จะซื้อกับเราแล้ว

Opportunity Stage (งานขายนี้อยู่สถานะไหนแล้ว)

Ref: https://kobkrit.com/

• Qualification เป็นกรองขั้นต้นว่าลูกค้าคนนี้ เค้าสนใจสินค้าและบริการของเราหรือเปล่า ทำธุรกิจอะไร ปัญหาอะไรที่ลูกค้าต้องการจะแก้ไข เค้าต้องการตอนนี้ไหม? มี Budget หรือยัง?
• Needs Analysis เป็นการเซ็คว่า เค้าต้องการสินค้าและบริการของเราจริงๆ? สินค้าและบริการของเราสามารถแก้ไขปัญหาของเค้าได้จริงและดีกว่าเจ้าอื่นๆที่เค้าคิดอยู่หรือไม่​?
• Proposal เรามาถึงขั้นตอนการทำใบเสนอราคาแล้ว เราต้องมันหาคำตอบของคำถามอาทิเช่น? ตอนนี้อยู่ในช่วงเวลาสั่งซื้อของบริษัทลูกค้าหรือไม่? ทำอย่างไรถึงได้ PO? ใครคือคนที่มีอำนาจตัดสินใจ? ลูกค้าได้พิจารณาแล้วว่าคุ้มค่าต่อการลงทุน (ซื้อจากเรา) หรือยัง?
• Negotiation ถึงขั้นตอนการต่อรองแล้ว คุณได้ส่งข้อมูลให้กับผู้ที่มีอำนาจตัดสินใจครบถ้วนแล้วหรือยัง? คุณได้ลองหาทางลดราคาให้ได้ราคาที่ดีที่สุดหรือใส่อะไรเพิ่มเติมทำให้การขายนี้น่าสนใจมากยิ่งแล้วหรือยัง
• Closed การขายเสร็จสิ้นแล้ว ไม่ว่าจะสำเร็จ Closed Won หรือล้มเหลว Closed Lost ก็อยู่ในสถานะ Closed เช่นกัน

ข้อมูลอื่นๆ

• ลองดู Feature ของระบบ CRM ในไทย มีความคล้ายกับ Saleforce รวมถึงการใช้คำศัพท์ในระบบ เช่น
  • https://www.getmycrm.com/Mobile
  • https://www.mdsoft.co.th/%E0%B8%AA%E0%B8%B4%E0%B8%99%E0%B8%84%E0%B9%89%E0%B8%B2/crm.html
  • http://www.aquacrmsoftware.com/crm-software/
  • http://www.ismartsales.com/

ก่อนจะไปสรุปเนื้อหา คลาสนี้ผมเรียนกับผู้สอน 3 ท่าน คือ โค้ชพี่บี (อ.ขนิษฐา หล่อลักษณ์), โค้ชพี่โจ้ (อ.สุวัชชัย แก้วทรัพย์ศักดิ์) และ โค้ชพี่หมี (กัปตันจีรพัฒน์ เอี่ยมสรรพางค์) เผื่อถ้าใครสนใจ ลองติดต่อได้ที่ bemanagementcoach.com ดูนะครับ

(ในที่นี้ผมแทนพี่ๆโค้ชทั้งสามด้วย ผู้สอน นะครับ เพื่อไม่ให้สับสนระหว่าง โค้ช, โค้ชชี่, การโค้ช, Coaching และระหว่างที่สอน ก็เป็นการสอนคู่ของโค้ชพี่บี โค้ชพี่โจ้ ด้วย ซึ่งใครเป็นคนพูดท่อนไหนอันนี้ผมจำไม่ได้ด้วยครับ แหะๆ)

คุณลักษณะของผู้นำเชิงบวก

ถ้าใครเคยอ่านใน Internet จะพบว่ามีหลายข้อแตกต่างกันไป แต่ถ้าดูดีๆแล้ว จะมีคุณสมบัติสองอย่างที่ผสมอยู่ในทุกแบบคือ “ผู้นำที่มีความเป็นโค้ช (Coach)” และ “ผู้นำที่มีความเป็นพี่เลี้ยง (Mentor)”

“We have done lots of research over the past three years, and we have found that leaders who have the best coaching skills have better business results.”
Tanya Clemens, V.P. of Global Executive & Organizational Development at IBM

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

แล้วโค้ช (Coach) กับพี่เลี้ยง (Mentor) ต่างกันอย่างไรล่ะ ?

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

ภาพจาก Presentation ในการเรียน BE Positive Leader with Coaching and Mentoring

โดยสรุปออกมาเป็นภาพง่ายๆ ระหว่างความต่างของ Coaching, Mentoring ด้วย TAPS Model

ภาพจาก Presentation ในการเรียน BE Positive Leader with Coaching and Mentoring

ว่าด้วยเรื่องของการโค้ช (Coaching)

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

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

ผู้สอนได้ให้สูตรหนึ่งมา คือ

P = P – I ถ้าอธิบายเต็มๆ ก็คือ Performance = Potential – Interference

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

ICF หรือ International Coach Federation ได้บอกว่า “การโค้ช คือ การเป็นหุ้นส่วนกับผู้รับการโค้ช (โค้ชชี่) ในกระบวนการกระตุ้นความคิดสร้างสรรค์ เพื่อสร้างแรงบันดาลใจให้พวกเขานำเอาศักยภาพทั้งส่วนตัวและวิชาชีพมาใช้อย่างสูงสุด”

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

ผู้สอนได้เปิดคลิปนี้ให้ดู ค่อนข้างเคลียร์กับสิ่งที่อธิบายข้างต้นเลยทีเดียวครับ

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

เราควรต้องมีทัศนคติสำหรับการโค้ชอยู่ 6 ข้อ

1. คนมีทรัพยากรเพียงพอ ในการบรรลุเป้าหมายของตัวเอง
2. คนตัดสินใจเลือกสิ่งที่ดีที่สุดสำหรับตนเอง ตามทรัพยากรที่มีในขณะนั้น
3. คนมีความรับผิดชอบต่อหนทางที่เขาคิดเอง
4. การ Coaching เป็นเรื่องของโค้ชชี่ล้วนๆ ไม่ใช่เรื่องของโค้ช
5. โค้ชรับผิดชอบแค่กระบวนการ Coach
6. คนเรามีมุมมอง ความคิดและแผนที่ชีวิตที่ต่างกัน ไม่อาจบอกได้ว่าใครถูกต้องกว่าใคร (และสิ่งที่โค้ชพูด คิด ก็ไม่ใช่วิ่งที่ผิดหรือถูกเช่นกัน)

โดยระหว่างที่เราโค้ช จะต้องพยายามควบคุมความพอดี ไม่ให้โค้ชชี่เกิดความกดดัน เป็นกังวล หรือเป็นทุกข์ มากเกินไป (Anxiety) หรือกลับกัน ไม่ใส่ความท้าทาย หรือทำอะไรเลย จนโค้ชชี่เกิดความเบื่อหน่าย (Bored) ซึ่งสถานการณ์นี้ มีภาพเปรียบเทียบไว้ เรียกว่า The Flow State คือพยายามทำให้โค้ชชี่ให้อยู่ในสภาวะกลางๆ ให้เร็วที่สุด ไม่เบื่อจนเกินไป ไม่มีแรงจูงใจทำงาน หรือท้าทายจนเครียดและกดดัน

ภาพจาก https://harveyhypnosis.com/2017/02/21/the-flow-state-getting-in-the-zone/

ทั้งนี้ ก่อนที่เราจะทำให้โค้ชชี่อยู่ใน Flow State ตัวของโค้ชเอง ควรจะต้อง Flow State ก่อนด้วยนะ

ปัจจัยที่ผู้นำควรตระหนักในการทำงานกับลูกน้อง

ผู้สอนได้ชี้ให้เห็นถึงสิ่งที่ผู้นำควรทำและไม่ควรทำ โดยให้คำนึงถึง 5 หัวข้อ เรียกว่า SCARF Model

• S = Statue (สถานะ) คือ สร้างความสัมพันธ์ต่อกัน ให้รู้สึกเหมือนเป็นพี่น้อง ญาติ ที่สามารถพูดคุยได้
  • ที่ไม่ควรทำ เช่น ทำตัวสูงส่ง
• C = Certainty (ความแน่นอน มั่นคง) คือ ต้องมีสื่อสารที่ดี ให้เข้าใจความต้องการของเรา และไม่โลเลเปลี่ยนแปลงบ่อย
  • ที่ไม่ควรทำ เช่น อารมณ์ไม่คงที่, เช้าสั่งอย่างหนึ่ง เย็นสั่งอีกอย่างหนึ่ง
• A = Autonomy (มีอิสระทางความคิด และตัดสินใจ) คือ ให้โอกาสลูกน้องเพื่อคิดและทำสิ่งต่างๆ
  • ที่ไม่ควรทำ เช่น ชอบบี้ ชอบจิก ชอบสั่ง ลูกน้อง
• R = Relatedness (มีความสัมพันธภาพที่ดี) รวมถึงเรื่องไหนควรเข้าไปโค้ช หรือเป็นพี่เลี้ยง
  • ที่ไม่ควรทำ เช่น ทำตัวห่างเหินกับลูกน้อง
• F = Fairness (ได้รับการดูแลอย่างยุติธรรม)
  • ที่ไม่ควรทำ เช่น มีอคติ หรือเมินเฉยในบางคน

ภาพจาก http://www.edbatista.com/2010/03/scarf.html

รูปแบบการสื่อสารอย่างโค้ช

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

ภาพจาก http://www.coaching.net.nz/how-not-to-act-insanely/

Beliefs (ความเชื่อ) > Values (ค่านิยม) > Thinking (ความคิด) > Emotions (ความรู้สึก) > Behaviours (พฤติกรรม) > Result (ผลลัพธ์)

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

“วงจรแห่งปัญญา” (“Insight Loop: PQC”)

ผมลองไปหาข้อมูลเพิ่มเติม มีความคล้ายกับ “Dance Toward Insight” กล่าวคือ ก่อนเข้าไปโค้ชต้องแจ้งกับโค้ชชี่เพื่อขออนุญาตทำการโค้ช (Permission) จากนั้นจึงเริ่มเข้าสู่การ ตั้งประเด็น (Placement), ถาม (Questioning) และ ทำให้เกิดความกระจ่าง (Clarifying)

ภาพจาก https://www.slideshare.net/KaushikSahaSrBusines/coaching-model-coach-for-performance

1. การขออนุญาต (Permission) : ทำเพื่อสร้างความไว้วางใจให้กับโค้ชชี่ ให้ทางเลือก แสดงความเคารพต่อกัน ขอเปิดโอกาสเข้าสู่ความคิด ซึ่งจะทำครั้งแรกครั้งเดียวก่อนจะโค้ช
2. ตั้งประเด็น (Placement) : เป็นการเปิดประเด็นสนทนาเพื่อสร้างความสัมพันธ์ ระบุผลลัพธ์ของการโค้ชที่จะเกิด หรือแจ้งวัตถุประสงค์ที่จะทำการโค้ช เวลาที่จะใช้โค้ช จะเกิดอะไรขึ้นบ้างระหว่างที่โค้ช
3. ถาม (Questioning) : เป็นส่วนที่ผมคิดว่ายากมาก เพราะเป็นทักษะที่โค้ชต้องฝึก ซึ่งผมจะมีเขียนไว้หลังจากนี้ แต่สิ่งที่ต้องพึงระวังคือ มารยาทในการถาม ความเหมาะสมของคำถามที่เราจะใช้กับโค้ชชี่ ความเหมาะสมของกาลเทศะ ความมีสาระ และความกระชับชัดเจนทางภาษา
4. ความกระจ่าง (Clarifying) : เป็นอีกส่วนที่ยากเช่นกัน เพราะโค้ชจะต้องทำความเข้าใจว่าสิ่งที่โค้ชชี่พูดมา มีอะไรอยู่เบื้องหลังคำพูดเหล่านั้น สามารถสรุปแก่นของสิ่งที่โค้ชชี่พูดได้ หรือสามารถสะท้อนกลับได้ (Reflect) ว่าความคิด ความรู้สึกของโค้ชชี่ ณ ตอนนั้น คืออะไร

โค้ชต้องฟังด้วยใจ (Empathy Listening)

ทักษะแรกที่(ดูเหมือนจะ)ง่ายที่สุด ที่โค้ชพอจะเริ่มฝึกได้คือเรื่องของการฟัง นอกจากฟังด้วย 2 หู แล้ว ยังต้องมี 1 ใจ ที่เราต้องคอยฟังจากโค้ชชี่ตลอดเวลา ผ่านการสังเกต เช่น สายตาของเขา สีหน้า กิริยาท่าทาง ว่าสื่อถึงอะไร

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

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

ผู้สอนจึงได้แนะนำ เทคนิคการฟังให้เข้าใจ 5 ข้อ คือ

1. ฟังด้วยหู – ต้องมีความสนใจ ตั้งใจ ใส่ใจฟัง เพื่อจับใจความประเด็นหลัก
2. ฟังด้วยตัว – สังเกตภาษากาย แสดงให้คู่สนทนาเห็นว่าเราฟัง เช่น พยักหน้าตอบรับ ออกเสียงตอบรับ
3. ฟังด้วยตา – คอยสบตากับผู้พูดอยู่เสมอ
4. ฟังด้วยปาก – คอยถามเพื่อทบทวนความเข้าใจ หรือสรุปเพื่อให้ผู้พูดรู้ว่าเราเข้าใจถูกหรือไม่
5. ฟังด้วยใจ – ฟังแบบไม่มีอคติ หรือความลำเอียงเข้ามาแทรก

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

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

คำถามที่โค้ชควรถาม (Powerful Questioning)

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

• เป็นคำถามที่สะท้อนมาจากการฟัง หยิบคำ ประโยค ของเขามาใช้ถาม
  • เช่น เท่าที่ฟังคุณให้ข้อมูลมา อยากให้ช่วยอธิบายความหมายของคำว่า ความยุติธรรม ในมุมมองของคุณ
• เป็นคำถามที่กระตุ้นให้คิด เพื่อค้นพบ เพื่อให้เกิดความเข้าใจอย่างลึกซึ้ง
  • เช่น สมมติว่าถ้ามีคนถามคุณว่า… คุณจะตอบคำถามนี้อย่างไร
• เป็นคำถามปลายเปิด
  • เช่น คุณมีความรู้สึกอย่างไรกับการทำงานชิ้นนี้
• ใช้คำถามที่จะพาโค้ชชี่ไปข้างหน้า เข้าหาเป้าหมาย
  • เช่น คุณคิดว่าปัจจัยของความสำเร็จในโครงการนี้คืออะไร

และที่ควรระวังในการใช้ตั้งคำถาม เช่น

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

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

ส่วนที่จะพยายามเลี่ยงเลยคือ การถามเจาะถึงปัญหา และอารมณ์

ภาพจาก Presentation ในการเรียน BE Positive Leader with Coaching and Mentoring

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

หรือถ้าโค้ชชี่ยังหาเป้าหมายไม่เจอ ผู้สอนแนะนำให้ลองใช้หลัก SMART เพื่อให้โค้ชชี่ได้ตั้งเป้าหมายกับตัวเองดูก่อน

ภาพจาก https://www.1213.or.th/th/moneymgt/finplan/Pages/planningsteps.aspx

จากนั้นโค้ชจะเริ่มตั้งคำถาม โดยใช้หลัก 6 GOAL Setting Questions ซึ่งจะเป็นชุดคำถาม 6 ข้อ คือ

1. วันนี้คุณอยากพูดคุยเรื่องอะไรเป็นพิเศษ
2. เรื่องนั้นเป็นปัญหาอะไรสำหรับคุณในตอนนี้
3. ถ้าทุกอย่างเป็นไปได้ตามที่คุณต้องการ ภาพฝันจะเป็นแบบไหน (Visualize) แล้วคุณเห็นอะไร ได้ยินอะไร รู้สึกอย่างไรในภาพฝัน จะบอกกับตัวเองว่าอย่างไร และหากบอกกับคนอื่น จะบอกว่าอะไร แล้วเขาจะตอบกลับมาอย่างไร (Visualize ไปในอนาคตให้เห็นผลลัพธ์)
4. การได้สิ่งนั้นมาจะให้อะไรกับตัวคุณ / เรื่องนั้นสำคัญอย่างไรกับตัวคุณ
5. ในสิ่งที่คุณอยากให้เป็น มีอะไรขาดหายไปจากที่คุณเป็นอยู่ในตอนนี้ (Gap ระหว่างปัจจุบันกับเป้าหมายของเขา)
6. ผลลัพธ์ที่ดีที่สุดที่คุณอยากเห็นจากการโค้ชครั้งนี้ (ผลลัพธ์จากการคุยกับโค้ช)

ขั้นตอนการโค้ช และ G.R.O.W+ Model

ผู้สอนได้ให้รู้จักกับ G.R.O.W+ Model เพื่อใช้ในกระบวนการโค้ช ซึ่งจะคล้ายกับ G.R.O.W Model ที่เคยเห็นกันใน Internet แต่ได้เพิ่มเติมรายละเอียดไว้ได้เข้าใจเลยหละครับ โดยในทุกขั้นตอนจะใช้วงจรแห่งปัญญา หรือ Dance Toward Insight – PQC ในการกระทำแต่ละขั้นตอนเสมอ ใช้เทคนิคการ ฟัง ถาม และสะท้อนกลับ เพื่อให้บรรลุในแต่ละขั้น โดยในที่นี้ผู้สอนเองบอกว่า อาจจะกลับไปมาในแต่ละขั้นตอนได้ด้วย โดยไม่ต้องเรียงกัน

และสิ่งที่สำคัญ คือ จะต้องทำ Rapport คือสร้างความสัมพันธ์ ความไว้วางใจในการพูดคุย ความเข้าใจให้ตรงกัน ตลอดระยะเวลาที่ทำการโค้ชด้วย .. ฟังดูค่อนข้างยาก ต้องฝึกฝนมากพอสมควรเลยทีเดียว

โดยมี 3 ขั้นตอน คือ

1. ทำการ Pre Coaching Session
   1. โค้ชจะอธิบายทำความเข้าใจกฎ กติกา ของการโค้ช หรือเทคนิคที่จะใช้ จะทำอะไร
   2. Builing Rapport เพื่อสร้างสายสัมพันธ์ ทำความคุ้นเคย
2. โค้ชจะขออนุญาต เริ่มการโค้ช
   1. แจ้งเวลาที่จะโค้ช
3. เริ่มกระบวนการตาม G.R.O.W+ Model
   1. G – Goal ค้นหาเป้าหมาย
      1. เช่น เป้าหมายที่คุณต้องการคือเรื่องอะไร
      2. เช่น ผลลัพธ์ที่ต้องการให้เกิด มีลักษณะอย่างไร
      3. เช่น เป้าหมายนี้มีความสำคัญกับคุณในเรื่องอะไร
   2. R – Reality ค้นหาความเป็นจริงในปัจจุบัน
      1. เช่น ปัจจุบันเมื่อเทียบกับเป้าหมายแล้วเป็นอย่างไร
      2. เช่น ถ้าเป้าหมายคือ 10 ปัจจุบันอยู่ที่คะแนนเท่าไร
      3. เช่น ปัจจัยอะไรที่มีความสำคัญที่จะทำให้คุณบรรลุเป้าหมาย
   3. O – Option ค้นหาทางเลือกที่มี
      1. เช่น คุณมีทางเลือกที่เหมาะสมในการประสบความสำเร็จอะไรบ้าง
      2. เช่น คุณมีแผนงาน หรือวิธีการในการบรรลุเป้าหมายอย่างไร
   4. W – Will / Way Forward คนหาการตัดสินใจ ความมุ่งมั่นที่จะทำ
      1. เช่น เพื่อบรรลุเป้าหมาย คุณตัดสินใจที่จะปฏิบัติในเรื่องอะไร
      2. เช่น คุณช่วยสรุปสิ่งที่คุณจะไปลงมือปฏิบัติ
      3. เช่น คุณมั่นใจในแนวทางนี้มากแค่ไหน
      4. เช่น คุณรู้สึกอย่างไรกับการตัดสินใจในครั้งนี้
   5. + Plus ให้การสนับสนุน ให้กำลังใจ

ภาพจาก Presentation ในการเรียน BE Positive Leader with Coaching and Mentoring

ผู้สอนได้ให้เทคนิคเพิ่มเติมคือ ถ้าตอนที่เราถาม Will/Way Foreard ยังพบว่าพลังงานเขายังมีไม่มาก ความมุ่งมั่นไม่มากพอ เราควรต้องวนกลับไป Goal, Reality, Option ต่อไป ไม่ควรปล่อยเขาผ่านไป เพราะสิ่งนั้นอาจจะไม่สำเร็จ

และถ้าคำถามที่เราถาม เขาเกิดการฉุกคิดขึ้นมา เป็นไปได้ว่าเป็นคำถามที่ทรงพลัง (Powerful Question) แต่ถ้าเราถามปุ๊บ และเขาตอบปั๊บ แปลว่าเขาอาจจะคิดไว้อยู่แล้ว เขาจะเอาสมองส่วนความจำเข้ามาใช้ตอบเรา ซึ่งเขาจะไม่เกิดการพัฒนา

5 สิ่งสูงสุดที่ไม่ควรทำในระหว่างการโค้ช เพราะจะลดความไว้วางใจ

• Closed Question – ใช้คำถามปลายปิด
• Offer Solution Question – ถามเพื่อนำเสนอทางออกตามความคิดของโค้ช
• Rambling Question – ยิงทีละหลายประโยค หลายคำถาม
• Leading Question – ถามโดยใช้ความรู้สึกของโค้ชเข้าตัดสินในเรื่องราวที่ได้ฟัง
• Neglecting to Interrupt  – ไม่กล้าตัดบท หากโค้ชชี่พูดออกนอกประเด็น หรือลงรายละเอียดมากเกินไป

ว่าด้วยเรื่องของการเป็นพี่เลี้ยง (Mentoring)

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

การโค้ช คือการตั้งคำถาม การเป็นพี่เลี้ยง คือการสอน การบอก

โดยการจะเป็น Mentoring จะต้องมี 3E คือ

1. มีประสบการณ์ (Experience) – จะไปสอนเขาได้ ตัวเองต้องมีประสบการณ์เคยทำมาก่อน
2. แลกเปลี่ยนได้ (Exchange) – สามารถแลกเปลี่ยนประสบการณ์กันได้ เพื่อเพิ่มพูนความรู้
3. อธิบายได้ (Explain) – ต้องอธิบายเป็น เพื่อให้คนเรียนเข้าใจ

และมีขั้นตอนการ Mentoring อยู่ 4 ขั้นตอน คือ

1. Explain – อธิบายได้ว่า จะทำอะไร เพื่ออะไร สำคัญอย่างไร
2. I Do – ทำให้ดูเป็นตัวอย่าง
3. We Do – ทำไปพร้อมกัน, ช่วยเหลือให้ทำได้, มีคำชม
4. You Do – ให้ผู้เรียนทำเอง โดยเขาจะต้องทำให้เราเห็นก่อน เราถึงจะปล่อยให้ทำเอง และเราต้องติดตามผลด้วย

กุญแจสำคัญที่จะทำให้การ Mentoring สำเร็จมี 5 ข้อ คือ

1. Together – ไปด้วยกัน
2. Real Situation – ให้ลองทำจริง พาไปเห็นของจริง
3. Understand – เราต้องเข้าใจ และอธิบายให้เขาเข้าใจ
4. Show – ทำให้เขาดู
5. Time – ให้เวลาเขาในการเรียนรู้

สรุป

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

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

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

—

Reference

• ข้อมูลและภาพไสลด์จาก Presentation ในการเรียน BE Positive Leader with Coaching and Mentoring
• รูปปก – https://celestialsdc.com/courses/events/coaching-and-mentoring/

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

1. เคลื่อนไหวอยู่เสมอ (They get moving)

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

2. หาเวลางีบหลับสั้นๆ (They take naps)

นักคิดชอบงีบ ซึ่งผลการศึกษาบอกว่า ช่วงบ่ายๆ ถ้างีบ 10-20 นาที จะมีประโยชน์ต่อร่างกาย แต่ถ้านอนเกินมากกว่านั้น เช่น 30 นาที อาจทำให้ปวดหัวได้ เพราะร่างกายกำลังเข้าสู่ช่วงหลับลึก แต่ถ้าเรานอนมากกว่า 1 ชั่วโมง ความจำจะถูกฟื้นฟู (ข้อมูลเพิ่มเติมจากบทความ การงีบหลับในตอนบ่ายวันละ 10-20 นาที สามารถพัฒนาความจำและความคิดสร้างสรรค์ได้อย่างดีเยี่ยม)

3. ออกนอกเรื่องบ้าง (They daydream)

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

4. พยายามทำงานร่วมกับผู้อื่น (They collaborate)

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

5. เผชิญหน้ากับความเสี่ยง (They take risks)

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

6. ตั้งกิจวัตรประจำวันที่แน่นอน (They make [and stick to] a routine)

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

7. ผจญภัยและออกค้นหา (They explore)

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

8. สังเกตและจดจำ (They pay attention)

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

9. ไม่รังเกียจงานที่แย่ (They forgive “bad” work)

นักคิดที่ดี จะมีทัศนคติที่ดี จะไม่รังเกียจอะไรที่แย่ๆ สามารถขัดเกลาความคิดที่แย่ที่สุด เป็นความคิดที่ดีที่สุดได้ และไอเดียดีๆหลายอย่าง อาจเกิดได้จากความคิดที่แย่ๆ มาก่อน

10. มีเวลาอยู่กับตัวเอง (They take time to be alone)

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

…

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

…

ฟังป๋าเต็ดเล่า

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

วันหนึ่ง จิวยี่ได้เชิญขงเบ้งมาดื่มสุราเพื่อขอความคิดเห็นเกี่ยวกับการสู้กองทัพเรือโจโฉ

จิวยี่กล่าวขึ้นมาก่อนว่า “กองทัพเรือโจโฉครั้งนี้ใหญ่หลวงนัก เราคิดกลอุบายไว้อย่างหนึ่งไม่ทราบว่าท่านจะเห็นด้วยหรือไม่”

ขงเบ้งตอบทันทีว่า “อย่าเพิ่งพูดอะไร ให้ท่านกับข้าเขียนอุบายไว้บนฝ่ามือ แล้วเราจะเปิดดูพร้อมกัน”

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

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

ลองไปหาที่เป็นหนังดูได้ครับ โครตสนุก ตอนนี้เองได้ถูกหยิบทำเป็นหนังหลายเรื่องมาก

ผู้เขียนนิยายสามก๊กหลอก้วนจงเขียนได้มีสีสันประหนึ่งต่างคนต่างเดาใจกันออก เป็นอัจฉริยะทั้งขงเบ้ง และจิวยี่
ส่วนในความเป็นจริงทางประวัติศาสตร์ว่าอย่างไรก็ตามไปหาอ่านกันอีกที

…

กลับมายุคปัจจุบัน

วันนี้ที่บริษัทลูกค้ามีการหยิบ Requirement ของงานมาคุยกัน เพื่ออธิบายว่าทำอะไรบ้าง
และให้ทีมเป็นผู้ประเมินเบื้องต้นว่า ขนาดของงานมีความใหญ่หรือยากแค่ไหน
ใช้เทคนิคง่ายๆ โดยเทียบไซต์ XS, S, M, L, XL

ปรากฎว่ามีงานหนึ่ง ทีมทำ 4 คน ต่างพูดถึงความยาก ความใหญ่ ไปคนละเรื่อง ตามที่ตัวเองมองเห็น
คุยกันอยู่พักใหญ่ ก็ยังไม่ลงตัวสักที

ดังนั้นเพื่อลดความวุ่นวาย จึงได้แจก Post-it ให้ไปคนละแผ่น แล้วเขียนไซต์ที่ตนเองคิดว่าใช่

ผลออกมาคือ มี 2 คน ระบุเป็น L และอีก 2 คน ระบุเป็น XL ..
เลยให้แต่ละคนได้อธิบายว่าทำไมคิดเห็นเช่นนั้น
สุดท้าย ก็ตกลงกันที่เป็น XL เพราะความเยอะของ Task ที่ต้องทำ ได้ถูกแจงให้ทุกคนได้รับรู้

ตกลงกันจบได้ภายในไม่กี่นาที

…

สองเรื่องที่เล่าข้างต้น เป็นวิธีที่เรียกว่า “Silent Brainstorm”
ถ้าเอาแค่หลักฐานที่ขงเบ้งใช้ ก็ประมาณ ค.ศ. 208
มันคงมีคนคิดวิธีเจรจาแบบนี้กันมานานมากแล้ว และก็ยังใช้ได้ผลอยู่
เพราะมนุษย์เป็นพวกเจ้าความคิด โดยเฉพาะทีมที่มีคนเก่งอยู่มากๆ

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

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

แต่คงไม่ต้องขั้นเขียนพู่กันลงฝ่ามือ แบบขงเบ้งจิวยี่ ก็ได้นะ เปื้อนเปล่าๆ

ไม่รู้คนอื่นๆจะเป็นเหมือนผมไหม ทุกวันนี้ที่นอนเยอะเพราะความกลัว .. กลัวตาย กลัวง่วงตอนทำงาน กลัวได้นอนน้อย หรือแม้แต่จะตื่นเช้าไปซ้อมวิ่ง ยังคุยกับตัวเองบ่อยๆว่า “เหยย เมื่อคืนแม่งนอนน้อยไป(5ชม) ถ้าออกไปวิ่ง เดี๋ยวเป็นลมนะเว้ย!” ก็ว่าไปนั่น..

สรุปคือแม่งขี้เกียจนั่นหละ

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

แล้วมันทำอย่างไรล่ะ?

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

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

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

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

จะให้หลับอย่างมีประสิทธิภาพ (How To Sleep Well) ผมสรุปได้ประมาณ 5 ข้อ

กำหนดเวลาการนอนและตื่นให้สม่ำเสมอ (Sleep/Wake Schedule)

โจทย์นี้ผมเน้นที่นอนตื่นเช้าสำคัญกว่า แต่คิดกลับกัน โดยจะฝึกเวลานอนก่อน คือจะลองกำหนดว่า ถ้าต้องการตื่นตี 5  ด้วยเวลานอนเท่าเดิมก่อน จะต้องนอนกี่โมง เช่น 5 ทุ่มครึ่ง ก็จะลองนอนแบบนี้ดูสักระยะ แต่ยังตื่นเวลา 7:30 เหมือนเดิมก่อนนะ

ซึ่งช่วงนี้ก็คงจะได้นอนมากขึ้น พร้อมกับทำข้ออื่นๆ เพื่อให้ร่างกายแข็งแรงขึ้น แล้วค่อยลองหดเวลาลงด้วยการตื่นเป็น ตี 5:00 แทน

จากที่สังเกตหลายครั้ง และตามแนวคิดนาฬิกาชีวิต พบว่า แม้นอนด้วยจำนวนชั่วโมงเท่าเดิม แต่นอนก่อนเที่ยงคืน และนอนก่อนที่ตัวเองจะง่วง แม้ต้องตื่นเช้าไปวิ่ง ไปทำงาน มันก็สดชื่น ไม่เพลีย, ดีกว่านอนดึกแล้วตื่นสายครับ

ควบคุมสภาพแวดล้อม (Control Environment)

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

อ่ะ แต่ก็จะลองทำความสะอาดจากเดือนละครั้งเป็นสัก 2 อาทิตย์/ครั้ง ก็แล้วกัน (เดือนละครั้ง แลดูสกปรกนะ 555)

ใส่ใจการกิน การดื่ม (Focus Eat/Drink)

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

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

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

ออกกำลังกาย (Workout & Excercise)

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

ข้อนี้ทำได้เลย ถ้าใครอยากทำ ส่วนผมคงจะพยายามทำ Power Walk (เดินเร็ว) ให้บ่อยและนานขึ้น จะได้ฝึกกำลังขาไปในตัวด้วย และคงต้องเอาเป้าหมายเดินวันละ 10,000ก้าว กลับมาใช้

ฝึกไม่คิด (Clear My Head)

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

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

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

Reference

• http://www.webmd.com/a-to-z-guides/discomfort-15/better-sleep/slideshow-sleep-tips
• https://www.helpguide.org/articles/sleep/getting-better-sleep.htm
• http://www.wikihow.com/Sleep-Better

หนังสือเล่มนี้ใช้ภาษาอ่านไม่ยาก คนทั่วไปอ่านได้ เหมือนกำลังฟังลุง Ron บ่นๆ ไปเรื่อยๆ เพื่อปูพื้นฐานและปรับทัศนคติ ใครอ่านที่ผมสรุปไว้และสนใจอยากลองหาฉบับเต็มมาอ่าน ลองดูได้จากลิงค์นี้ครับ The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece

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

แล้วคำถามต่อไปคือ เมื่อซอฟต์แวร์ มันใช้เวลาผลิตนาน จะให้มันเสร็จไวๆ มอบของ(คุณค่า)ให้ลูกค้าได้เห็นบ่อยๆ จะทำอย่างไรล่ะ? 

ค้นหาคุณค่าซอฟต์แวร์ของคุณให้เจอ

เจ้ายอดพีระมิดในรูปนั่นหละ คือสิ่งที่เราต้องค้นหามันให้เจอ ว่าคุณค่าของซอฟต์แวร์เราคืออะไร ซึ่งคุณค่า (Value) ที่ว่า คือ สิ่งที่เราต้องการในงานชิ้นนี้ (What you want) ซึ่งเป็นได้หลายกรณี ตั้งแต่แบบจับต้องได้คือ เงิน ไปจนถึงจับต้องไม่ได้ อย่าง เสียงหัวเราะ ความสุข ความสะดวกสบาย

การทำให้เกิดคุณค่า จะเริ่มจากส่วนล่างสุดของพีระมิด ไล่เรียงขึ้นมา โดยเริ่มจาก…

• Guiding – ทีมทำงานต้องเข้าใจว่าอะไรคือสิ่งที่พวกเขาจะต้องทำ เราต้องการอะไร คุณค่าของงานคืออะไร เรามีทรัพยากร เช่น เครื่องมือ เวลา ฯลฯ อย่างไร
• Organizing – ใช้ความสามารถของทีมให้มีประสิทธิภาพ และสร้าง Team มีการพัฒนาความชำนาญขึ้นไปเรื่อยๆ
• Planning – วางแผน ตัดงานเป็นชิ้นตามคุณสมบัติ (Feature) ลำดับความสำคัญตามสิ่งที่ต้องการ เพื่อให้ได้สาระสำคัญของงานนั้นออกมาก่อน
• Building – สร้างงานเป็นชิ้นๆ ตามคุณสมบัติ (Feature) เพื่อส่งมอบงานให้ได้บ่อยๆ สามารถเห็นความคืบหน้าได้เรื่อยๆ
• Slicing – ตัดคุณสมบัติออกเป็นงานให้เล็กที่สุด ที่จะทำให้ส่องมอบงานได้ไว และส่งงานได้ตลอดเวลา
• Quality – นำวิธีการต่างๆมาประยุกต์ใช้เพื่อสร้างงานให้มีคุณภาพอยู่ตลอดเวลา

คุณค่าที่คุณคู่ควร (Value)

คุณค่า (Value)  คือ สิ่งที่เราทุกคนต้องการ (What you want) และในมุมมองของซอฟต์แวร์นั้น เราจะไดรับคุณค่าของมันก็ต่อเมื่อมีการส่งมอบคุณสมบัติ (Features) ของซอฟต์แวร์นั้นออกมา ไม่ว่าจะแบบจับต้องได้ อย่างการทำให้ประหยัดเงิน ประหยัดเวลา หรือจับต้องไม่ได้อย่างการช่วยสร้างความสะดวกสบายในชีวิต หรือทำให้ผู้ใช้ยิ้มได้ ดังนั้น ผู้เขียนจึงให้คำนิยามคำว่า Value คือ “What we want” 

ตามที่กล่าวไปข้างต้น คุณค่าของซอฟต์แวร์เริ่มมีหลังจากที่เราส่งมอบซอฟต์แวร์ไปแล้ว ดังนั้น การส่งมอบได้บ่อยๆ ก็เหมือนการส่งมอบคุณค่าให้ลูกค้าได้รับได้เห็นบ่อยๆ และสามารถพิจารณากันได้ทันทีว่า คุณค่าที่ส่งออกมา มันมีคุณค่าจริงๆไหม และที่กำลังจะทำต่อไป มันมาถูกทางแล้วหรือไม่ ซึ่งในภาษา Startup ใช้คำว่าทำ MVP (Minimum Viable Product) ขึ้นมาก่อน โดยจะมีหัวใจของซอฟต์แวร์ หรือฟีเจอร์ที่ที่เอาไปขายได้ ออกมาทดลองในตลาดก่อน

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

ดังนั้น การแยกชิ้นงานเป็นชิ้นเล็กๆ คือ การแยกตามคุณสมบัติ (Features) เช่น คุณสมบัติต้องกันฝนกันลมได้ สิ่งที่ส่องมอบคือ โครงสร้างภายนอกของรถ, หรือคุณสมบัติรถสามารถเคลื่อนที่ได้ สิ่งส่งมอบคือ โครงสร้างภายนอกที่ปรอกับใส่ล้อและสามารถเคลื่อนที่ได้ เป็นต้น

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

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

มุ่งสู่สิ่งที่ดีกว่า ด้วยแนวคิดการทำทีละฟีเจอร์ (Guiding)

แบบที่เรารู้ๆกัน โครงการ (Project) ทุกชิ้นจะต้องมีกำหนดเวลาเสร็จชัดเจนเสมอ (Deadline) และต้องการได้ของครบทุกอย่างตามที่สั่งด้วย แต่พอนำไปปฎิบัติจริง ก็มักไม่ได้ตามนั้น, เพราะอะไร?

เพราะ การวางแผนที่ใช้ในโครงการส่วนใหญ่มัก จะทำเป็นก้อนใหญ่ และตัดเฟสโดยแบ่งตามประเภทกิจกรรม (Activity-based phase) เช่น เริ่มจากการวิเคราะห์ (Analysis) เสร็จแล้วนำไปออกแบบต่อ (Design) และก็ไปเขียนโค้ด (Coding) บลาๆๆ ซึ่งถ้าทำแบบนี้กว่าจะไปถึงเฟสหลังๆ จะรู้ได้อย่างไรว่า จะไม่เกิดบั๊กในภายหลัง หรือมีการเปลี่ยนแปลงความต้องการช่วงกลางทาง  ซึ่งถ้าเกิดเรื่องเหล่านี้ขึ้นมา ก็แปลว่าเราจะไม่สามารถส่งมอบงานที่สมบูรณ์ทั้งหมดได้ใช่หรือไม่? … คำตอบคือ ก็ใช่..

และถ้าเปลี่ยนเป็นทีมส่งมอบงานออกไปได้บ่อยๆ เริ่มตั้งแต่การวางแผนเป็นชิ้นงานเล็กๆ แบบทีละฟีเจอร์ (Feature by Feature) จากนั้นค่อยนำเข้ากระบวนการ ออกแบบ เขียนโค้ด ทดสอบ เสร็จงานก็ปล่อยฟีเจอร์นั้นออกไปขาย และค่อยเริ่มทำฟีเจอร์ชิ้นต่อไป แบบนี้จะดีกว่าไหมครับ?

การทำทีละฟีเจอร์ นอกจากส่งมอบงานได้บ่อยๆ ทำให้ลูกค้าเห็นความเคลื่อนไหวของงานแบบที่จับต้องได้อยู่ตลอดเวลา ลูกค้าเอาไปใช้งานได้ทันที ส่วนตัวทีมพัฒนาเองก็ดูแลโครงการทั้งหมดง่ายขึ้นด้วย เพราะดูแลเป็นฟีเจอร์เล็กๆ ให้เสร็จไปทีละส่วน ก็จะ Win-Win กว่าไหม?

อ่านถึงตรงนี้ลองนึกย้อนกลับไปเทียบกับสิ่งที่ตัวเองกำลังทำ หรือกำลังสั่งให้ทีมพัฒนาทำอยู่ ว่ามันดีกว่าหรือแย่กว่ากัน?..

วิธีจัดการงานทีละฟีเจอร์ให้มีประสิทธิภาพ (Organizing)

บางครั้งงานชิ้นหนึ่งจำเป็นต้องใช้ความสามารถหลากหลายเพื่อมาทำ เช่น Dev/UX/UI ซึ่งการจัดทีมแบบ Skill-set หรือจับคนที่มีความสามารถแบบเดียวกันไปอยู่ด้วยกัน แม้จะง่ายกับการบริหาร  แต่ก็อาจไม่เหมาะสมกับงาน และทำให้งานเดินได้ช้าลง เพราะพวกเขาต้องสลับหมุนเวียน ละจากงานหนึ่งไปงานหนึ่ง ออกไปขอคำปรึกษาจากผู้รู้ภายนอกทีม เช่น ฝ่ายกราฟฟิก ต้องไปถามฝ่ายทำ UX และไปถามฝ่ายพัฒนาถึงความเป็นไปได้ จากนั้นค่อยกลับมาทำงานของตนเอง นั่นจะหมายถึงเวลาที่สูญเสียแบบเปล่าประโยชน์ (แม้จะดูเล็กน้อยก็ตาม)

ดังนั้น วิธีการแก้ปัญหาคือ สร้างทีมทีมีผู้รู้ในแต่ละเรื่องที่จำเป็นสำหรับฟีเจอร์นั้นๆ มารวมกัน หรือเรียกว่า Feature Team

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

ในกรณีที่เรามีผู้เชี่ยวชาญในแต่ละด้านไม่เพียงพอเพื่อจับไปลงทีม เราควรหาผู้ที่มีความรู้ (อาจไม่จำเป็นต้องถึงขั้นผู้เชี่ยวชาญก็ได้) และสร้างกลุ่ม Community of Practice ขึ้นมา โดยให้ผู้รู้คนนั้นสอนคนอื่นๆ ในส่วนที่มีความจำเป็นต้องใช้ทำงาน เช่น Database Community of Practice หรือ UX Community of Practice

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

ลุง Ron ทิ้งท้ายไว้อย่างสะกิดต่อมเซเลบลัมในสมองว่า “ผู้เชี่ยวชาญที่เราจ้างมาด้วยราคาสูง ไม่ใช่จ้างมาเพราะเขาเป็นผู้เชี่ยวชาญเท่านั้น แต่ควรจ้างเขาเพื่อสร้างให้คนอื่นเป็นผู้เชี่ยวชาญได้เช่นกัน” (A highly paid expert shouldn’t be highly paid just because she’s an expert. She should be highly paid because she is helping other people become experts.)

การวางแผนทำทีละฟีเจอร์ (Planning)

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

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

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

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

(อ่านมาถึงตรงนี้ จู่ๆผมก็นึกถึงบริษัทที่ผมเคยทำงานด้วย, สมัยก่อนผมขึ้นต้นด้วยการอธิบายวิธีการเลย ผู้ใหญ่ไม่ต้องรู้หรอกว่ามันดีอย่างไร แต่มันดีนะ ให้ผมทำไปเถอะ เชื่อผม…. และแล้ว เขาก็ไม่ได้เห็นด้วยกับวิธี และไม่อนุมัติให้ทำ.. เพราะเราไม่ได้ตัดแบ่ง ทำ Pilot Team, Pilot Project ทดลองให้เขาดูก่อน)

การส่งมอบงานออกมาเรื่อยๆ แบบนี้ จะเรียกรอบส่งงานนี้ว่า Iterations หรือ Sprints, โดยฟีเจอร์ (Feature) ที่ส่งมอบ จะเรียกว่า Story ซึ่งการทำงานแบบนี้ จะต้องวางแผนอยู่ตลอดเวลา เพราะมีการปรับเปลี่ยนเรื่อยๆ ไม่สามารถวางแผนในครั้งแรกครั้งเดียวแล้วใช้ได้เลย (ย้อนกลับไปย่อหน้าบนๆ อีกเช่นกัน ว่าทำไมไม่ต้องลงรายละเอียดกับมัรเยอะ และทำไมเรามักมีปัญหาเมื่อแผนเปลี่ยน)

ลุง Ron บอกว่า ไม่แนะนำให้ทำเป็น Story ใหญ่ๆ, ไม่แนะนำให้แตกงานย่อยๆ ออกมาเป็น Task ที่มีแต่ด้านเทคนิค (Technical) เพราะฝั่งที่ไม่มีความรู้ด้านเทคนิคจะอ่านไม่เข้าใจเลย และอีกประเด็นคือ การแปลง Story ออกมาเป็นฟีเจอร์เล็กๆ จะใช้เวลาทำและเข้าใจง่ายกว่าเป็น Technical Task

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

ลุง Ron เตือนไว้ว่า ในขณะที่วางแผน อย่าไปใส่ความท้าทายให้เป้าหมาย (stretch goals) เช่น “ลองใส่เพิ่มไปอีก 1 ฟีเจอร์ซิ๊” การทำแบบนี้มันจะทำให้ทีมพยายามทำมันให้เสร็จ โดยที่พวกเขาต้องเร่งทำงานอื่นให้เร็วขึ้น ทดสอบน้อยลง โค้ดลดคุณภาพลง เพียงเพราะต้องหาเวลาเพื่อรับความท้าทายขึ้นอีกแค่ 1 ฟีเจอร์ และท้ายที่สุดเราอาจจะได้งานช้าลงเพราะทีมต้องกลับมาปรับปรุงโค้ดหรือแก้ Defect ที่เกิดขึ้นในภายหลัง

“ความกดดันเป็นสิ่งที่อันตราย พยายามลีกเลี่ยงมัน”

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

สร้างมันขึ้นมาทีละฟีเจอร์ (Building)

ประโยชน์ของการย่อยงานทำทีละฟีเจอร์ (Feature by Feature) ทีมและองค์กรจะได้เรียนรู้ และเห็นผลของงานได้เร็ว สามารถเปลี่ยนแปลง ปรับปรุง การทำงานและตัวงานได้ตลอดเวลา (หรือเรียกกันว่า False Fast, Learn Fast)

ลักษณะการทำงานแบบนี้ มันเหมือนเราต้องทำซอฟต์แวร์ตัวเล็กๆหลายตัว เพื่อมาโปะกันไปเรื่อยๆจนได้สมบูรณ์ตามซอฟต์แวร์ภาพใหญ่ที่ต้องการ ดังนั้น การทำฟีเจอร์ตัวหนึ่ง จะยังคงต้องมีกระบวนการ Development Cycle ครบด้วย ตั้งแต่การวางแผน วิเคราะห์ ออกแบบ เขียนโค้ด ทดสอบ และเราจะเรียกกระบวนการที่ว่านี้เป็น 1 รอบการทำงาน (Iteration) ดังนั้นงานที่ได้ออกมาในแต่ละรอบจะเป็นงานที่ใช้ฟีเจอร์นั้นได้จริงๆ เอาไปโชว์ ไปขาย ไปใช้ได้ทันที

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

ในการทำงานแบบเดิม เราต้องรอจนถึงเฟส Test ถึงจะพบว่ามี Defect อะไรบ้าง ซึ่งมันอาจมีมากหรือน้อยจนทำให้ใช้เวลาเกินที่วางแผนไว้ แต่หากทำเป็นรอบและทุกรอบมีการ Test อยู่แล้ว เมื่องานทั้งหมดใกล้เสร็จ เราก็ไม่ต้องกังวลกับ Defect ก้อนโตในตอนท้าย (ผู้เขียนใช้คำว่า “nearly free of defects” คืองานเกือบจะไม่มีข้อผิดพลาดเกิดขึ้น)

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

แนวคิดแบบแนวตั้ง และสร้างเท่าที่จำเป็น  (Build Feature and Foundation in Parallel)

ฟีเจอร์ของซอฟต์แวร์ต้องมีโครงสร้าง (Foundation) ของซอฟต์แวร์ที่ดี, แต่สิ่งที่เราต้องคิดคือ จะทำอย่างไรให้ทั้งสองอย่างสมดุลและเสร็จไปพร้อมกันได้ ในเวลาที่จำกัด และเท่าที่จำเป็น

หากเรามัวแต่ไปทำโครงสร้างพื้นฐานของซอฟต์แวร์ เช่น ออกแบบ Framework สุดหรู, สร้าง Library ที่พร้อมใช้ทุกอย่าง แต่แล้วฟีเจอร์ต่างๆ ที่เป็นคุณค่าของซอฟต์แวร์ ไม่เสร็จ หรือเสร็จไม่ครบ แบบนี้ซอฟต์แวร์ของเราจะไปมีค่าอะไร เพราะมันใช้งานไม่ได้ตามที่ลูกค้าต้องการ

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

พัฒนาฟีเจอร์ออกมาเพื่อให้ใช้งานได้ก่อน โดยทำขึ้นมาอย่างง่ายๆ หรือที่เรียกว่า MVP – “Minimum Viable Product” จากนั้นค่อยกลับมาเก็บรายละเอียดให้ดีอีกครั้ง

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

การออกแบบที่ดี และไร้ข้อผิดพลาด (Bug-Free and Well Designed)

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

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

ดังนั้น สิ่งที่ควรทำในการทำซอฟต์แวร์ คือ ต้องป้องกัน (Prevent) ไม่ให้เกิดข้อผิดพลาด มากกว่าการมาตามแก้ไขข้อผิดพลาดในภายหลัง (Fix)

สิ่งที่เราจะเริ่มทำคือ ทดสอบระบบด้วยการทดสอบระดับ Business ว่าสามารถใช้งานได้ตามที่ต้องการไหม หรือที่เราเรียกว่า Acceptance Test-Driven Development (ATDD) และค่อยต่อด้วยทดสอบระดับ Technical ด้วยวิธีการต่างๆ

ซอฟต์แวร์ของเราจะใหญ่ขึ้นเรื่อยๆ ตามจำนวนฟีเจอร์ที่เพิ่มและโค้ดที่เขียน ดังนั้นจะใช้เวลาและยากมากที่ต้องทดสอบทั้งหมดทุกครั้งหลังจบรอบการทำงาน (System Test, Integration Test) ดังนั้น ทีมพัฒนาควรทำ Automate Tests ให้ครอบคลุมทั้งระบบงาน หรือออกแบบทำไว้ตั้งแต่ก่อนพัฒนาระบบ หรือที่เรียกกันว่า Test-Driven Development (TDD)

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

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

ดังนั้น ในทุกรอบการทำงาน เพื่อให้ระบบเราสอดคล้องกับฟีเจอร์ใหม่ในรอบนั้นๆ ควรให้ความสำคัญถึงการทำ Refactoring Code ด้วย เพื่อไม่ให้เกิดความยุ่งยากซับซ้อนในรอบทำงานต่อๆไป

Test และ Refactor ทั้งสองอย่างนี้เป็นเรื่องสำคัญของการพัฒนาระบบแบบ Feature-by-Feature เพราะจะทำให้งานเรามีคุณภาพได้ตลอดเวลา เพื่อพร้อมส่งมอบงานให้ลูกค้าได้เสมอ

ส่งท้าย

จากที่สรุปมาให้อ่านทั้งหมด ผมสังเกตได้ว่า ลุง Ron Jeffrie มีคำที่พยายามย้ำอยู่เรื่อยๆไม่กี่คำ คือ คุณค่า (Value), ทีม (Team), การพัฒนาทักษะ (Learn), การทำงานเป็นรอบ (Iteration) และ การทำทีละฟีเจอร์ (Feature-by-Feature), การส่งมอบ (Shipable)

ดังนั้น หัวใจหลักของการพัฒนาแบบ “The Nature Way” ที่ลุง Ron เอามาเสนอ เราต้องให้ความใส่ใจกับคำ 6 คำนี้แหละครับ ส่วนใครอ่านไปแล้วจะคิดต่อหรือหาความรู้เพิ่มเติม จากนั้นเอาไป Adapt & Implement กันอย่างไร ก็คงขึ้นอยู่กับแต่ละวัฒนธรรมองค์กร

ขอให้สนุกครับ

—

ที่มาของเนื้อหาและรูปภาพ จากหนังสือ The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece เขียนโดย Ron Jeffries

2-3 ปีก่อน คุณ  Peter Skillman เคยเล่าในงาน TED ถึงปัญหาด้านการออกแบบ ที่เขาเรียกมันว่า “ปัญหามาสเมลโล (Marshmallow Problem)” ซึ่งคลิปนี้ คุณ Tom Wujec จึงเล่าถึงการนำปัญหานั้นไปทำเป็นเกมส์ในคลาสสัมนาต่างๆ โดยที่เขาเรียกมันว่า “Marshmallow Challenge” หรือ การแข่งขันกันสร้างตึกสูงที่สุดด้วยเส้นสปาเก็ตตี้ 20 เส้น มาร์ชแมลโลว์ 1 ก้อน และเทปกาว เชือก กรรไกร

วิธีการคือ มีทีมจำนวน 4คน ถ้าทีมไหนต่อเส้นสปาเก็ตตี้ 20 เส้นได้สูงที่สุด และเอาก้อนมาร์ชแมลโลว์วางไว้บนนั้นได้ด้วย จะถือว่าเป็นผู้ชนะ

Tom ได้เดินทางไปสอนการเล่นนี้ในหลายๆที่ทั่วโลก และพบว่า กลุ่มที่ทำความสูงได้มากสุด และรูปแบบแปลกตาด้วย ก็คือ “เด็กอนุบาล” (Kindergarten) ส่วนกลุ่มที่ทำความสูงได้ไม่ดีนัก คือ “นักศึกษาบริหารธุรกิจ”

ฟังดูแปลกๆดีนะครับ แต่เขาก็ให้เหตุผลว่า เพราะนักศึกษาบริหารธุรกิจถูกสอนมาให้ทำแผนที่ดีที่สุด จากนั้นค่อยลงมือทำ ซึ่งสิ่งที่เกิดขึ้น นักศึกษาใช้เวลาส่วนมากในการวางแผน ทำโครงสร้าง และเมื่อจะวางมาร์ชแมลโลว์บนยอดสุดก็ตอนที่ใกล้จะหมดเวลาเสียแล้ว… หรือที่เราเรียกว่า “เมื่อถึงเวลาวิกฤต” (It’s in crisis)

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

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

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

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

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