บันทึกการเขียน “สมุดโน้ต WTF” ของผม (2021)
(simplermachines.com)- หากเพิ่งเข้าร่วมทีมใหม่แล้วไม่รีบชี้ประเด็นแปลก ๆ ที่เห็นทันที แต่รวบรวมไว้ใน สมุดโน้ต WTF ก่อน จะได้บริบทสำหรับสร้างความไว้วางใจในฐานะคนที่ช่วยทีม ไม่ใช่คนที่เอาแต่บ่น
- สิ่งที่ควรบันทึกคือสัญญาณติดขัดใน การดำเนินงานของทีมและโฟลว์ทางเทคนิค เช่น การ retrospective ที่จบลงโดยไม่มี action, การทดสอบบนเครื่อง local ไม่ได้, กระดาน build เป็นสีแดง, หรือการพึ่งพาคนคนเดียวในงานบางอย่าง
- เมื่อเวลาผ่านไป รายการจะถูกคัดกรองออกเป็นรายการที่มีเหตุผลสมควร, มีการแก้ไขอยู่แล้ว, ทีมให้ความสำคัญต่ำ, หรือเป็นรายการที่ แก้ได้ง่าย
- ปัญหาที่ยังเหลืออยู่หลังผ่านไปหลายสัปดาห์ ควรถูกนำไปคุยกับสมาชิกทีม, team lead และ manager เพื่อยืนยันสาเหตุและประวัติ แล้วเริ่มแก้ร่วมกันจากปัญหาที่กวนใจมานานแต่ค่อนข้างเรียบง่าย
- แทนที่จะระเบิดประเด็นทันที การสะสมบริบทและลำดับความสำคัญไว้ก่อนช่วยให้สมาชิกทีมใหม่สร้าง ชื่อเสียงในฐานะนักแก้ปัญหา ได้โดยไม่เสียความไว้วางใจ
วิธีใช้สมุดโน้ต WTF
- ชื่อเสียงที่อยากได้ในทีมคือ “คนที่ช่วยแก้ปัญหาของฉัน” และ “คนที่ทำงานที่ฉันให้ความสำคัญให้สำเร็จ”
- ทุกครั้งที่เข้าร่วมทีมใหม่ ให้เปิดหน้าใหม่ใน bullet journal แล้วเขียนว่า
WTF - [Team Name]จากนั้นบันทึกทุกครั้งที่เจอเรื่องที่รู้สึกแปลก - หากมีสิ่งที่อยากเปลี่ยนแปลง ก็จดไว้เป็นงานแยกต่างหากด้วย
- ในช่วง 2 สัปดาห์แรกให้ โฟกัสแค่การบันทึก
- ไม่พูดทุกอย่างที่คิดว่าทีมทำผิดทันที
- ไม่เทรายการสิ่งที่ควรเปลี่ยนลงใน retrospective
- ดู ฟัง และจดสิ่งที่รู้สึกแปลกอย่างลึก ๆ
- วิธีนี้เป็นเทคนิคที่ช่วยสร้างความเปลี่ยนแปลงในทีมไปพร้อมกับบริหารตัวเอง และไม่ทำให้ดูเหมือนคนที่เอาแต่บ่น
สัญญาณผิดปกติที่พบในทีมใหม่
- ในทีมใหม่มักมีเรื่องที่ทำให้รู้สึกว่า “wtf” เสมอ
- ตัวอย่างที่พบบ่อยมีดังนี้
- ทีมคุยปัญหาร้ายแรงใน retrospective เป็นชั่วโมง แต่จบลงโดยไม่มี action item
- การทดสอบรันบนเครื่อง local ไม่ได้ แต่ดูเหมือนไม่มีใครสนใจ
- ส่วนใหญ่ของกระดาน build อยู่ในสถานะสีแดงตลอดเวลา
- งานสำคัญและเร่งด่วนมีแค่คนเดียวที่จัดการได้
- ทีมใช้เวลากับฟีเจอร์หนึ่งมาก แต่ไม่มีใครรู้ชัดว่าทำไมมันสำคัญ หรือช่วยลูกค้าอย่างไร
รายการที่ถูกลบออกจากลิสต์
- เมื่อมีรายการมากพอแล้ว ให้เริ่มลบออกทีละข้อ
- เหตุผลที่ถูกลบมักมีอยู่สี่แบบ
- จริง ๆ แล้วมี เหตุผลที่ดี
- ทีมกำลังแก้ไขอยู่แล้ว
- ทีมไม่ได้มองว่าปัญหานั้นสำคัญ
- แก้ได้ง่ายมาก
- ปัญหาที่รันการทดสอบบนเครื่อง local ไม่ได้ อาจไม่ใช่ปัญหาใหญ่ ขึ้นอยู่กับบริบท
- อาจเป็น issue ที่รู้กันอยู่แล้วและกำลังพยายามแก้ไข
- ทีมอาจทำงานทั้งหมดบน virtual machine และสามารถ provision เครื่องนั้นได้ง่ายด้วยคำสั่งในแชต
- อาจมีระบบ continuous integration ที่ดี และมีนิสัย deploy การเปลี่ยนแปลงเล็ก ๆ บ่อย ๆ จนการทดสอบบนเครื่อง local ไม่ได้ไม่ขัดขวางการ deploy หลายครั้งต่อวัน
- บางรายการมองเห็นวิธีแก้ที่ง่าย
- ถ้ารู้ตำแหน่ง ก็เขียนเอกสารได้
- ถ้าหา script ที่ถูกต้องเจอ ก็อาจเป็นการเปลี่ยนแปลงที่ง่าย
- ถ้าเห็นวิธีแก้ง่าย ๆ ก็แก้ทันที
จัดการปัญหาที่เหลือร่วมกับทีม
- หากผ่านไปหลายสัปดาห์แล้วยังมีปัญหาที่แปลกและยังไม่ถูกแก้ ให้เริ่มคุยกับสมาชิกทีม, team lead และ manager
- จุดเน้นของคำถามคือ ทำไมรายการเหล่านี้จึงอยู่ในสภาพนั้น และมันกลายมาเป็นแบบนั้นได้อย่างไร
- เป้าหมายคือการสร้างความไว้วางใจในฐานะ คนที่สงสัยอย่างจริงใจและเห็นอกเห็นใจ มีความอดทน และเคารพความเชี่ยวชาญของเพื่อนร่วมงาน
- เหตุผลที่ปัญหายังคงอยู่มักแบ่งได้เป็นไม่กี่แบบ
- ทีมไม่ทันสังเกต
- ทีมชินไปแล้ว
- ปัญหานี้ค่อนข้างใหม่ และปัญหาก่อนหน้านั้นแย่กว่านี้มาก
- ไม่รู้วิธีแก้
- เคยพยายามแก้แล้วล้มเหลว
- ปัญหาประเภทแรก ๆ อาจแก้ได้ทันทีเพียงแค่ถาม
- อีกฝ่ายแก้ทันที หรือช่วยกันหาวิธีแก้
- ถ้าเป็นปัญหาทางเทคนิค ก็เขียน story หรือ ticket ร่วมกันแล้วลงมือทำ
- ถ้าเป็นปัญหาด้าน process หรือด้านสังคม ก็นำไปคุยกับทั้งทีมใน retrospective
- ณ จุดนี้ ควรมองหาปัญหา 1-2 เรื่องที่กวนใจเพื่อนร่วมงานใหม่คนหนึ่งมาระยะหนึ่ง และมีวิธีแก้ค่อนข้างเรียบง่าย
- เลือกปัญหาที่เมื่อเอาขึ้น retrospective board แล้วไม่ใช่มีแค่ตัวเองที่รู้สึกไม่สบายใจ
- จับข้อเสนอของสมาชิกทีมคนนั้นระหว่างการคุยในทีม ให้กลายเป็น action item ที่ทดลองได้ทันที
- ทีมจะเริ่มรู้สึกว่าสมาชิกใหม่กำลังช่วยแก้ปัญหาของพวกเขา
ปัญหาที่ยากขึ้นและการคุยกับ manager
- เมื่อเวลาผ่านไป จะเข้าสู่ ปัญหาเหนียวหนึบ ที่ทีมรู้ดีแต่กลัวจะจัดการ
- ปัญหาเหล่านี้อาจถูกมองว่า “ไม่ได้แย่ขนาดนั้น” แต่ไม่มีใครอยากพูดถึง
- อาจขาดความสามารถทางเทคนิคที่จำเป็น
- อาจมีปัญหาคนที่ซับซ้อนเป็นแกนกลาง
- ในขั้นนี้ ให้นำรายการที่ทำมาจนถึงตอนนี้ไปคุยกับ manager
- สิ่งที่เห็นมาตลอดหลายสัปดาห์
- บางอย่างมีความคืบหน้า แต่บางอย่างดูเหมือนต้องใช้เวลานานกว่า
- มีอะไรที่ตกหล่นไปหรือไม่
- อยากให้โฟกัสด้านใด
- manager อาจกังวลเรื่องเดียวกันอยู่แล้ว แต่ไม่สามารถผลักดันแรง ๆ ได้ เพราะดูเหมือนทีมไม่ได้รู้สึกไม่สบายใจมากนัก
- หลังจากนั้นสามารถสรุปความกังวลและปัญหาร่วมกับ manager และพูดคุยกรณีในอดีตที่เคยได้ผลหรือไม่ได้ผล
- manager จะเริ่มมองว่าคุณเป็นคนที่มีวิจารณญาณดี และช่วยแก้ปัญหาที่ยากขึ้นได้
เหตุผลที่ไม่ชี้ทันที
- ชื่อเสียงที่ต้องการคือ “Nat ช่วยแก้ปัญหาของฉัน” และ “Nat ทำงานที่ฉันให้ความสำคัญให้เสร็จ”
- ชื่อเสียงแบบนี้ช่วยให้ได้ผลลัพธ์ที่ต้องการในการประเมินผลงานปีถัดไป และอาจนำไปสู่การแนะนำตัวในอีกหลายปีต่อมา
- ในอดีต เคยพูดทันทีที่พบปัญหา
- ผลคือได้ชื่อเสียงว่า “บ่นตลอด” และ “คิดว่าเราไม่เคยทำอะไรถูกเลย”
- ผู้คนเริ่มไม่ฟัง ทำให้หงุดหงิดเป็นการส่วนตัว และไม่มีประสิทธิภาพในเชิงอาชีพด้วย
- หากสมาชิกใหม่โวยวายใหญ่โตกับเรื่องที่จริง ๆ แล้วไม่ใช่ปัญหา, ทีมไม่ได้มองว่าเป็นปัญหา, กำลังแก้อยู่แล้ว, หรือมีวิธีแก้ง่าย ๆ ที่ตอนแรกยังมองไม่เห็น ความไว้วางใจจะพังลงอย่างรวดเร็ว
- ในทีมมักมีปัญหาที่ปรับปรุงได้มากมายเสมอ แต่สิ่งที่แก้ได้จริงมีเพียงบางส่วน
- ลำดับที่ค้นพบปัญหาแทบไม่เคยเป็นลำดับการแก้ที่มีประสิทธิภาพที่สุด
- สมุดโน้ต WTF ช่วยเก็บแรงกระตุ้นที่ว่า “อยากแก้เดี๋ยวนี้” ไว้ชั่วคราว และรอจนกว่าจะมีบริบทพอสำหรับตัดสินใจว่าควรจัดการอะไรก่อน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมคิดว่าบทความนี้ยังไม่ได้เน้นประเด็นหนึ่งให้พอ: มุมมองของคนใหม่ มีได้เพียงครั้งเดียวเท่านั้น
เหตุผลที่เราตัดสินความใช้งานง่ายของผลิตภัณฑ์ได้ไม่ดี เป็นเพราะเรารู้วิธีใช้มันอยู่แล้ว และเริ่มชินชาต่อข้อผิดพลาดกับจุดบกพร่องต่าง ๆ
สมาชิกทีมคนใหม่ยังไม่อยู่ในสภาพแบบนั้น ดังนั้นการดูว่าเขาถามอะไร ติดตรงไหน และต้องการความช่วยเหลือจริง ๆ ตรงไหน จะทำให้ทีมได้ข้อมูลเชิงลึกมากมาย
นั่งพร้อมสมุดจด คอยบันทึก และพูดคุยกับผู้ใช้ระหว่างที่เขาใช้ผลิตภัณฑ์
ต่อให้รวบรวม ข้อมูล telemetry ได้หลายเทราไบต์แค่ไหน ก็ไม่อาจเข้าใจวิธีที่ผู้ใช้ใช้ผลิตภัณฑ์ได้เท่ากับการพูดคุยกับผู้ใช้จริง
วงการเทคโนโลยีควรเลิกกลัวมนุษย์คนอื่นเสียที
คล้ายกับอาจารย์ผู้เชี่ยวชาญที่ลืมไปว่าสิ่งที่ต้องอธิบายให้ผู้เรียนมือใหม่นั้นยากเพียงใด
แต่ไม่ใช่ว่าทุกคนจะทำได้แย่เท่ากันหมด เรื่องนี้ขึ้นอยู่มากกับว่ามี ความสามารถในการเห็นอกเห็นใจ และความใส่ใจพอจะยืนในมุมของผู้เริ่มต้นหรือไม่
คนสองคนที่เคยใช้ Bash shell มา countless ครั้ง ก็อาจมีความเข้าใจต่างกันโดยสิ้นเชิงว่าอะไรที่แปลกและไม่เป็นธรรมชาติสำหรับมือใหม่
การมองด้วยสายตาสดใหม่ก็เป็นทักษะอย่างหนึ่ง และพัฒนาได้ด้วยการฝึกฝน เหมือนการเรียนรู้ที่จะวาดจากแสงและวัตถุจริง
ถ้าจดไว้แทนที่จะพูดออกมาทันที ก็จะได้เวลาทำความเข้าใจว่าทำไมสิ่งต่าง ๆ ถึงเป็นแบบนั้น และได้เรียนรู้ภูมิประเทศขององค์กร
เมื่อเรื่องอย่างบัญชี สิทธิ์ และการอนุมัติต่าง ๆ ถูกจัดการเรียบร้อยแล้ว ก็สามารถขยับต่อจากรายการนั้นได้
แบบนั้นทีมก็มีแนวโน้มจะรับรู้ว่าเป็นคนที่พยายามช่วย มากกว่าจะเป็น “คนที่โผล่มาตะโกน WTF อยู่ตลอด”
สำหรับทีมขนาด 12–15 คน มันเวิร์กดีมาก แต่ไม่แน่ใจว่าจะขยายผลได้ดีแค่ไหนในองค์กรที่ใหญ่กว่านั้น
การจดไว้แล้วรอนั้นทำได้ทันที ภาระต่ำ และยังมีรางวัลเล็ก ๆ อย่าง “รายการยาวขึ้นแล้ว” จึงน่าจะฝึกอย่างเป็นระบบและเรียนรู้กลับมาได้ไม่ยาก
ผมชอบที่แยกขั้นตอนของการรับรู้และบันทึก ออกจากขั้นตอนภายหลังในการทำแผนที่ มองย้อนกลับ เรียนรู้ และรวบรวมคนนำทีมที่มีความรู้สึกต่อปัญหาเดียวกัน
การเขียนบันทึกการทำงานเป็นความคิดที่ดีเสมอ แต่ น้ำเสียง ของบทความนี้มีบางอย่างที่สะดุดใจ
ผมไม่อยากทำงานกับคนที่ทำตัวเหมือน Borg หรือทำตามบทที่เหมือนยกมาจาก 『How to Win Friends and Influence People』
ถ้าใครดูเหมือนพยายามชักใยผม อย่างน้อยตั้งแต่วินาทีที่ผมสังเกตเห็น ก็จะไว้ใจได้ยาก
ถึงอย่างนั้นก็ไม่ควรถูกแรงปฏิเสธในทันทีนั้นลากไปทั้งหมด
ผมเองก็ตั้งเป้าว่าอยากให้ผู้มีส่วนได้ส่วนเสียรู้สึกกับผมอย่างไร และมันค่อนข้างมีประโยชน์ในฐานะเกณฑ์กำกับพฤติกรรม
ต่อให้ทำงานเชิงเทคนิคได้ดี แต่ถ้าเพิกเฉยต่อ มิติของความสัมพันธ์ระหว่างมนุษย์ ก็เกิดปัญหาได้ และสิ่งที่ผู้คนพูดกันลับหลัง วิธีที่ผมถูกรับรู้ และวิธีที่งานของผมถูกนำเสนอ ล้วนสำคัญจริง ๆ
แค่บอกว่า “ทำงานให้ดีก็พอ” ไม่ได้ทำให้ข้อเท็จจริงที่ว่างานของผมและตัวผมสร้างความรู้สึกอย่างไรให้คนอื่นนั้นหายไป
ผมไม่เคยอ่าน 『How to Win Friends and Influence People』 แต่รู้สึกว่าตัวบทความเขียนได้ค่อนข้างดี
ไม่ว่าจะเป็น individual contributor ที่มีประสบการณ์ ผู้จัดการใหม่ หรือนายทหาร ช่วง 30–90 วันแรกก็คล้ายกัน คือไม่ควรเปลี่ยนอะไร แต่ควรพยายามทำความเข้าใจว่างานเดินอย่างไร และที่สำคัญกว่านั้นคือทำไมถึงเป็นแบบนั้น
องค์กรได้ประโยชน์หลายอย่าง และพูดสั้น ๆ นี่คือวิธีที่ควรทำจริง ๆ
วิศวกรหลายคนเคยทำงานใต้ผู้จัดการแย่ ๆ และแม้จะอธิบายไม่ได้ชัดว่าแย่ตรงไหน แต่ก็มักจะสัมผัสได้
ความรู้สึกเรื่อง “ผู้จัดการแย่” นั้นมักมาจากการไม่มีภาวะผู้นำที่ดีในเชิงยุทธวิธี และเช่นเดียวกับวิศวกรรม ภาวะผู้นำก็เป็นทักษะที่เรียนรู้ได้
ปัญหาคือมีไม่กี่แห่งที่สอนเรื่องนี้อย่างตั้งใจ เช่น ในกองทัพหรือการอบรมผู้บริหารระดับสูง
ถ้าอยากทำงานใต้ผู้จัดการที่ดี จริง ๆ แล้วคุณอยากทำงานใต้ผู้นำที่ดี และภาวะผู้นำก็เป็นทักษะเชิงยุทธวิธีเหมือนการเขียนโค้ด C++ ให้มีประสิทธิภาพ
มันคือการประสานและนำผู้คนให้บรรลุเป้าหมายที่ใหญ่กว่าผลรวมที่แต่ละคนทำแยกกันได้ ดังนั้นเมื่อมองจากบางมุมจึงอาจรู้สึกเหมือนการชักใย
ถึงอย่างนั้น คนที่ปกป้องทีมจากเรื่องโง่ ๆ ภายนอก จัดหาทรัพยากรที่จำเป็น ชมต่อหน้าสาธารณะและวิจารณ์เป็นการส่วนตัว ให้ทิศทางโดยไม่ micromanage มากเกินไป ยอมรับและให้รางวัลผลงาน และไม่ปล่อยผ่านมาตรฐานที่ต่ำกว่าที่ควร มักเป็นผู้นำแบบที่วิศวกรชอบ
ในทางกลับกัน ถ้าเป็นนักการเมืองสายคาริสมาที่จบ MBA แต่ไม่รู้เทคโนโลยี แล้วใช้เทคนิคเหล่านี้ด้วยเหตุผลไม่ดี ก็จะกลายเป็นคนที่ไม่น่าทำงานด้วย
คนที่ไต่ขึ้นจากสายเทคนิคไปเป็นผู้จัดการ แต่ไม่ยอมรับว่าการบริหารจัดการต่างจากทักษะทางเทคนิค ก็มักถูกไม่ชอบอยู่บ่อย ๆ
สุดท้ายถ้าอยากให้ทั้งวงการมีผู้นำที่มีความสามารถมากขึ้น ก็ต้องปฏิบัติต่อภาวะผู้นำเหมือนในบทความแบบนี้ คือไม่ใช่สัญชาตญาณคลุมเครือที่ติดตัวมาแต่กำเนิด แต่เป็นยุทธวิธีที่อธิบายได้ว่าต้องทำอย่างไร
การได้ชื่อว่า “Nat ช่วยแก้ปัญหาให้ฉันได้” อาจดีต่อการถูกแนะนำต่อ แต่เสี่ยงต่ออาชีพได้
ผมเคยทำแบบนั้นมาตลอด 20 ปีในหลายแผนก และทุกครั้งพวกเขาพยายามรั้งผมไว้ในฐานะคนแก้ปัญหา แต่ไม่เคยเสนอชื่อเป็น ผู้สมัครเลื่อนตำแหน่ง
เพื่อนร่วมงานที่ทำงานมา 40 ปีแล้วเกษียณก็เป็นคนที่แก้ปัญหาอะไรก็ได้ และมีความสามารถมากกว่าผู้จัดการหลายคนมาก แต่ก็ไม่ได้เลื่อนตำแหน่ง
เขาเป็นไพ่ตายของทุกคน แต่แทบไม่ได้รับการยอมรับ การแก้ปัญหาถูกมองว่าเป็น “เรื่องที่ต้องทำอยู่แล้ว” และไม่มีผลตอบแทน
คนอื่นในระดับเดียวกันถูกใช้มาตรฐานที่ต่ำกว่ามาก และในการประเมินผลงานครั้งสุดท้าย ผู้จัดการยังบอกว่า “ไม่ได้ประเมินเทียบกับเพื่อนร่วมงาน แต่ประเมินเทียบกับเป้าหมาย”
ผมก็เคยได้ยินคำเดียวกันจากผู้จัดการอีกคน จึงไม่ใช่เรื่องบังเอิญ
ที่สำคัญที่สุดคือ ผู้จัดการของผมอยู่ข้างผมเสมอเวลาช่วยกันคำขอที่ไม่ได้มาจากเขา
ถ้าคนที่ไม่รู้จักมาขอให้ทำงานที่ไม่ใช่เรื่องเล็ก แต่ผมไม่มีเวลาหรือไม่สนใจ ผมแค่พูดว่า “ตอนนี้ผมไม่มีเวลาดูครับ ถ้าต้องการให้จัดลำดับความสำคัญ โปรดคุยกับผู้จัดการของผม” และ 99 ครั้งจาก 100 ครั้ง เรื่องก็ไปไม่ถึงผู้จัดการ
ข้อดีใหญ่ที่สุดของการเป็น คนที่ใคร ๆ ก็ไปหา ในระดับแผนกหรือทั้งบริษัท คือได้สะสมคนรู้จักและเครือข่าย
เวลาต้องการข้อมูลจากนอกทีม หรือต้องฝ่าขั้นตอนราชการเพื่อเรื่องสำคัญ มันทำงานเหมือนพลังพิเศษเล็ก ๆ
และยังมีเครือข่ายไว้ติดต่อเมื่อมองหาโอกาสใหม่ ๆ ด้วย งานทั้งหมดที่ผมได้ตลอด 15 ปีในภาคเอกชนก็เชื่อมโยงมาด้วยวิธีนี้
แต่คงพูดได้ว่า ในสองแนวทางนี้ แนวทางหนึ่งผ่าน กระบวนการเลื่อนตำแหน่ง ได้ดี ส่วนอีกแนวทางไม่เป็นเช่นนั้น
ไม่ใช่เรื่องง่าย แต่การตั้งขอบเขตเป็นทักษะสำคัญ
ส่วนที่ว่า “พอเห็นปัญหาก็หยิบขึ้นมาพูดทันที จน Nat ได้ชื่อว่าเป็นคนบ่นตลอด และคิดว่าเราทำอะไรก็ผิดไปหมด” ควรอยู่ใกล้ ๆ ต้นบทความ
การรู้เท่าทันตัวเอง ในระดับนี้เป็นทักษะจริงที่ควรฝึก
Chris Hadfield อดีตนักบินอวกาศก็เคยบอกในหนังสือว่า เขาใช้วิธีคล้ายกันเมื่อต้องเข้าร่วมภารกิจและทีมใหม่
คือเข้าสู่โหมดสังเกตก่อน เพื่อเรียนรู้ว่าช่วงเวลา WTF เหล่านั้นสมเหตุสมผลจริงหรือไม่ และเป็นวิธีที่ไม่ทำให้สมาชิกทีมใหม่กลายเป็นคนน่ารำคาญ
น่าอ่าน
พอทำงานอยู่ที่เดิมนาน ๆ ก็พบว่าการสร้างที่ไว้กรองเสียงรบกวน อย่างน้อยก็ช่วยไม่ให้มันค้างอยู่ในหัวตรง ๆ
ไม่ใช่แค่การตัดสินว่าปัญหานั้นสมเหตุสมผลหรือไม่ แต่ยังใกล้เคียงกับการเรียนรู้ว่าเรื่องบางอย่างควร ปล่อยวาง อย่างไรด้วย
ถ้าบอกได้ว่าเล่มไหนก็คงดี
เวลาต้องเข้าไปอยู่ในสถานการณ์ที่มีอยู่แล้ว โดยทั่วไปผมก็ใช้วิธีประมาณนี้
สัปดาห์แรกจะตรวจดูทุกอย่าง พร้อมจดคำถามและสิ่งที่สังเกตได้
ไม่ได้จดแค่ช่วงเวลา “WTF” แต่จดสิ่งที่ทำงานได้ดี และสิ่งที่รู้สึกว่าเป็นไอเดียที่ดีจริง ๆ ด้วย
หลังจากนั้นค่อยทบทวน จัดลำดับความสำคัญ แล้วจึงเข้าไปพูดคุย
สิ่งนี้ดูเป็นหลักการที่เข้ากันได้ดีกับ รั้วของเชสเตอร์ตัน
เป็นเรื่องที่บอกกับคนที่อยากรื้อรั้วว่า “ถ้าคุณไม่รู้ว่ามันมีไว้ทำอะไร ผมจะปล่อยให้คุณรื้อไม่ได้ ไปคิดดูก่อน และเมื่อคุณบอกได้ว่าเข้าใจหน้าที่ของมันแล้ว จึงค่อยรื้อได้”
พูดให้ชัดขึ้นคือ แม้อะไรบางอย่างจะดูแปลก ก็ควรสมมติก่อนว่าคนที่มาก่อนฉลาด และมีเหตุผลอยู่เบื้องหลัง
เหตุผลนั้นอาจล้าสมัยไปแล้วก็ได้ แต่ถ้าไม่พิจารณา ก็จะทำผิดซ้ำเดิม
ไม่ใช่แค่เก็บรายการสิ่งที่อยากแก้ แต่การปล่อยไว้สักระยะจะทำให้เข้าใจได้ว่าอะไรเป็นอย่างนั้นเพราะอะไร จึงเป็นไอเดียที่ดี
หลายครั้งอาจเป็นสิ่งที่ทำอย่างรีบเร่งหรือเกิดจากความผิดพลาด แต่บางครั้งก็มี ความซับซ้อนที่ซ่อนอยู่ จริง ๆ ซึ่งดูจากโค้ดเพียงบรรทัดเดียวแล้วเข้าใจทันทีได้ยาก
แบบแรกคือความล้มเหลวชัดเจน ส่วนแบบหลังมักคลี่คลายเมื่อได้จมอยู่กับสภาพแวดล้อมนั้นนานพอ
ถึงอย่างนั้น การจดทั้งสองแบบไว้ก็ยังมีประโยชน์
สัปดาห์นี้ผมเพิ่งบอกเพื่อนร่วมงานสองคนว่าในคอมพิวเตอร์ของผมมีไฟล์ “How the F” อยู่
มันไม่เหมือนกับที่ผู้เขียนพูดทั้งหมด แต่คล้ายกันมาก และเวลาเข้าทีมใหม่ ผมจะจดทุกอย่างที่เกิดปัญหาแล้วทำให้คิดว่า “นี่ต้องทำยังไงอีกแล้วนะ?” ไว้ทั้งหมด
ผมไม่ได้เอาไปให้ผู้จัดการเหมือนในต้นฉบับ แต่มันให้มุมมองในการทำความเข้าใจว่า อุปสรรค ของทีมและบริษัทคืออะไร แล้วค่อย ๆ ใช้เวลาแก้ไขไป
ผมใช้ชีวิตด้วยวิธีจดไอเดียทั้งหมดที่นึกขึ้นได้ลงในรายการ
ไม่มีลำดับพิเศษ แค่เติมต่อไปเรื่อย ๆ บนกระดาษหรือไฟล์ข้อความ
ไอเดียมักไม่โผล่มาเวลาที่ต้องการ แต่จะมาเรื่อย ๆ ทั้งวันระหว่างทำอย่างอื่น และถ้าไม่จดไว้ อย่างน้อยสำหรับผมก็จำไม่ได้
พอถึงเวลาต้องทำอะไร ก็แค่ขีดทิ้งทีละรายการ จึงไม่ต้องคิดว่าจะทำอะไรต่อ และเพราะไอเดียไม่หมด จึงเกิด การระเบิดของผลิตภาพ ได้ค่อนข้างมาก
ฟังดูเหมือนเป็นเรื่องการจัดการรายการงานส่วนตัว แต่ต้นฉบับเป็นบทความเกี่ยวกับวิธีปรับตัวและสื่อสารภายในทีม
ชีวิตสั้นเกินกว่าจะมานั่งจัดระเบียบบันทึก ผมคิดว่าเขียนทุกอย่างลงไป แล้วพึ่งการเรียงลำดับย้อนกลับกับการค้นหาจะดีกว่า
น่าขันที่ผมรู้ว่ามีขุมทรัพย์ของไอเดียน่าทึ่งอยู่ แต่พอมาถึงวัยนี้ ก็ไม่ได้ใส่ใจมากพอจะลงมือทำเหมือนตอนอายุ 20 กว่า ๆ แล้ว