การทำงานร่วมกันนั้นไร้ประโยชน์
(newsletter.posthog.com)- คำกล่าวที่ว่า “ไปคนเดียวจะเร็ว ไปด้วยกันจะไปได้ไกล” อาจทำให้สตาร์ตอัพพังได้
- การทำงานร่วมกันที่มีประสิทธิภาพควรมีบทบาทแค่ระดับตัวช่วยนำทางระหว่างขับรถ แต่บริษัทส่วนใหญ่กลับเจอความเร็วที่ลดลงจาก ฟีดแบ็กที่มากเกินไปและการกระจายบทบาท
- ภายใต้ค่านิยม “You're the Driver” ของ PostHog บริษัทเน้น ความเป็นอิสระและความเป็นเจ้าของที่สูง พร้อม ลดการทำงานร่วมกันที่ไม่จำเป็นให้เหลือน้อยที่สุด
- สาเหตุของการทำงานร่วมกันมากเกินไปถูกวิเคราะห์ว่าเกิดจาก ความอยากช่วยเหลือ วัฒนธรรมที่ครอบคลุมเกินไป การขอฟีดแบ็กที่ไม่ชัดเจน การใช้คำว่า “let’s discuss” พร่ำเพรื่อ และการหลีกเลี่ยงความรับผิดชอบ
- ทางแก้คือแนวทางเชิงปฏิบัติ ได้แก่ ให้ความสำคัญกับการปล่อยใช้งานทันที, กำหนดผู้รับผิดชอบให้ชัดเจน, ขอฟีดแบ็กเฉพาะจากคนที่จำเป็น, รับฟีดแบ็กหลังเปิดตัว, และ ตัดการทำงานร่วมกันที่ไม่จำเป็นทิ้งทันที
กับดักของการทำงานร่วมกัน
- คำพูดอย่าง “ถ้าอยากไปเร็วก็ไปคนเดียว ถ้าอยากไปไกลก็ไปด้วยกัน” กำลังค่อยๆ ฆ่าบริษัท
- มันคือ กับดักที่ใช้สร้างความชอบธรรมให้กับการทำงานร่วมกันมากเกินไป
- การทำงานร่วมกันที่มีประโยชน์ควรอยู่แค่ระดับ ช่วยบอกทิศทางหรือข้อมูลรอบตัวระหว่างขับรถ
- แต่คนส่วนใหญ่ในองค์กรกลับติดอยู่กับ การทำงานร่วมกันแบบไร้ประสิทธิภาพราวกับผลัดกันจับพวงมาลัย
- ฟีดแบ็กที่เหมาะสมช่วยให้ไปถึงจุดหมายได้เร็วขึ้น แต่ฟีดแบ็กที่มากเกินไปจะทำให้ช้าลงและเสี่ยงที่จะไปไม่ถึงที่ที่ต้องการ
ความย้อนแย้งของฟีดแบ็ก: การให้ฟีดแบ็กเก่งคือการรู้ว่าเมื่อไรไม่ควรให้
- เมื่อ PostHog เติบโตขึ้น ก็มี การทำงานร่วมกันที่ไม่ได้เพิ่มคุณค่า หรือให้คุณค่าน้อยเกินไปเมื่อเทียบกับเวลาที่ใช้ เพิ่มขึ้น
- ในการประชุมทั้งบริษัทครั้งล่าสุด มีการหยิบหัวข้อ “การทำงานร่วมกันเป็นเรื่องไม่ดี” ขึ้นมาพูด
- “You're the driver” คือค่านิยมหลักของ PostHog: “จ้างคนเก่งมากแล้วอย่าไปขวางพวกเขา”
- ไม่มีเดดไลน์ การประสานงานให้น้อยที่สุด และผู้จัดการไม่คอยสั่งงาน
- สิ่งที่แลกมาคือการต้องมี ความเป็นเจ้าของในระดับสูงมากและความสามารถในการทำงานจำนวนมากได้ด้วยตัวคนเดียว
- นักการตลาด deploy โค้ด, พนักงานขายตอบคำถามทางเทคนิคโดยไม่มีตัวช่วย, วิศวกรผลิตภัณฑ์ทำงานได้ทั้งสแตก
- แทบจะมีคนที่เก่งกว่าคุณอยู่เสมอ จนเกิดแรงดึงดูดให้อยากร่วมงานกับคนนั้น แต่ การทำงานร่วมกันบังคับให้คนขับต้องชะลอความเร็วและคอยอธิบายภูมิหลัง บริบท และความคิด
- แนวโน้มนี้มักปรากฏผ่านวลีสำคัญไม่กี่แบบ
- “สงสัยว่า X คิดยังไง”
- “อยากฟังความเห็นของ Y”
- “ต้องทำงานร่วมกับ Z”
- สิ่งเหล่านี้ บางครั้งนำไปสู่มุมมองที่มีคุณค่า แต่ก็ทำให้คนขับช้าลงเสมอ
- มันกัดกร่อนแรงจูงใจ ความมั่นใจ และประสิทธิภาพของคนขับ และสุดท้ายทำให้ปริมาณการปล่อยงานลดลง
ถ้าการทำงานร่วมกันไม่ดี แล้วทำไมผู้คนยังทำมันอยู่
- ทุกคนมีส่วนก่อให้เกิดปัญหา
- คนเราต่างอยากช่วย: เมื่อมีใครโพสต์งานที่กำลังทำใน Slack คนอื่นก็มักรู้สึกว่าต้องให้ฟีดแบ็ก เพราะวัฒนธรรมฟีดแบ็กผลักดันเช่นนั้น
- ในทางกลับกัน หลายคนก็ รู้สึกว่าการขอฟีดแบ็กจากคนเฉพาะเจาะจงนั้นไม่ inclusive จึงไม่ขอ ทั้งที่จริงแล้วมันน่าจะมีประโยชน์
- ไม่ได้ระบุให้ชัดว่าต้องการฟีดแบ็กแบบไหน: จึงเปิดช่องให้การทำงานร่วมกันแทรกเข้ามา การคุยเรื่องการสร้างฟีเจอร์หนึ่งอาจบานปลายไปเป็นการประเมิน product roadmap ทั้งหมดใหม่
- เมื่อมีใครเสนอไอเดียดีๆ ปฏิกิริยาพื้นฐานมักไม่ใช่ “ไปทำเลย” แต่เป็น “มาคุยกัน”
- หลักฐานคือใน Slack มีคำว่า “let's discuss” โผล่เต็มไปหมด
- มันเปลี่ยนจากการลงมือทำไปเป็นการถกเถียงแทน
- หลายคนยุ่งเกินไปที่จะลงมือทำ หรือขี้เกียจทำ เลย แค่อยากคุย
- PR → issue/RFC → Slack (ตอนนี้ส่วนใหญ่มาจบที่นี่) → “มาคุยกัน”
- ไม่ชัดว่าใครเป็นเจ้าของ (หรือไม่มีใครอยากเป็นเจ้าของสิ่งที่กำลังคุยกันอยู่)
- แม้มันจะน่าหงุดหงิด แต่บางครั้งก็มีกรณีที่ คนคนเดียวไม่สามารถ Shipping งานคุณภาพสูงได้ตั้งแต่ต้นจนจบ และไม่สามารถแค่ Shipping ไปก่อนแล้วค่อยวนปรับปรุงได้
- โค้ดที่พังยังแก้ได้ แต่ จดหมายข่าวส่งซ้ำใหม่ไม่ได้
วิธีทลายการทำงานร่วมกัน (และไปได้เร็วขึ้น ไกลขึ้น)
- ถ้ามองการทำงานร่วมกันเป็นศัตรู จะเอาชนะมันอย่างไร
- ตั้งต้นด้วยการลงมือทำก่อน: Pull request > Issue > ข้อความใน Slack
- เมื่อการทำงานร่วมกันเริ่มมากเกินไป ให้ขีดเส้นชัดๆ ว่า “คุณเป็นคนขับ คุณตัดสินใจเอง”
- เวลาขอฟีดแบ็ก ให้ แท็กคนที่ต้องการอย่างเจาะจง พร้อมบอกให้ชัดว่าอยากได้อะไร อย่าโยนลอยๆ
- แทนที่จะรีวิวก่อนเปิดตัว ควร ให้ฟีดแบ็กหลังเปิดตัว (ก่อนรอบถัดไป) มากกว่า เพราะฟีดแบ็กล่วงหน้าอาจกลายเป็นกระบวนการอนุมัติกลายๆ
- ผู้นำควรยับยั้งการให้ฟีดแบ็ก และรักษาท่าทีแบบ “you can just do stuff”
- แต่ละคนควรเป็น “กัปตันที่มีข้อมูลครบ (informed captain)”
- รับฟีดแบ็กได้ แต่ คนตัดสินใจคือตัวเอง
บทสรุป
- เราไม่อาจถอนรากถอนโคนการทำงานร่วมกันทั้งหมดได้ และบางรูปแบบก็มีประโยชน์ (จดหมายข่าวฉบับนี้ Ian และ Andy เป็นคนช่วยแก้ไข)
- แต่ก็จำเป็นต้อง พยายามลดการทำงานร่วมกันให้เป็นค่าเริ่มต้น
- ถ้าไม่ได้พยายามลดการทำงานร่วมกันอย่างจริงจัง ก็มีโอกาสสูงว่าคุณกำลังร่วมงานกันมากเกินไปอยู่แล้ว
- เพราะการทำงานร่วมกันทำให้ช้าลงโดยธรรมชาติ
ยิ่งร่วมงานกันน้อย ก็ยิ่งไปได้ไกลและเร็วขึ้น
- เขียนโดย Charles Cook ผู้เกลียดน้ำอัดลมเพราะ (ฟองมันร่วมมือกันมากเกินไป)
12 ความคิดเห็น
การทำงานร่วมกันเป็นสิ่งที่ถูกต้องครับ
ถ้าคนนั้นไม่อยู่ (เสียชีวิต, ป่วย, ลาพักร้อน) ก็จะไม่ตอบสนองลูกค้าเลยหรือ?
ฉันทำงานอยู่ที่บริษัทเล็กมากจนมีพนักงานแค่ฉันคนเดียว เลยทั้งดูแลระบบเองและพัฒนาเองคนเดียว.... แต่พออยู่ในสภาพนี้มานานเกินไป ก็เริ่มรู้สึกว่าอยากทำงานร่วมกับคนอื่นบ้าง การทำงานคนเดียวมันเหงาเกินไป...
เป็นบทความที่เรียกร้องความสนใจแรงเกินไปนะครับ
หรือว่าเพราะความเป็นตัวของผู้เขียนโดดเด่นเกินไป เลยเข้ากับคนอื่นได้ไม่ค่อยดี?
ในการสร้างฟีเจอร์หนึ่งขึ้นมา
โดยปกติก็ต้องมีบทบาทอย่างดีไซเนอร์ ฝ่ายวางแผน ผู้จัดการโครงการ ฝั่งฟรอนต์เอนด์ แบ็กเอนด์ QA ฯลฯ อย่างขาดไม่ได้
ดูเหมือนว่าเขากำลังใช้คำกล่าวที่ค่อนข้างสุดโต่งเพื่อเปิดเผยปัญหาที่ตัวเองรับรู้
แต่ความร่วมมือกันคงไม่ได้หมายถึงการดำเนินไปในรูปแบบคล้ายอะโกราเสียทีเดียวนี่ครับ
อย่างไรก็ตาม การใช้คำว่า ‘let’s discuss’ พร่ำเพรื่อ และการเลี่ยงความรับผิดชอบ สองอย่างนี้เป็นปัญหาที่ชัดเจนแน่นอน
แต่ส่วนใหญ่มักเกิดจากการไม่มีผู้นำหรือผู้รับผิดชอบที่มีอินไซต์อยู่จริง
เดิมทีก็ต้องมีการวิจัย พัฒนาคน จ้างคน หรือซื้อโซลูชันมาเพื่อจัดการเรื่องแบบนี้อยู่แล้ว
ถ้าสร้างทีมขึ้นมาจากสมาชิกที่คอยเชื่อฟังอย่างเดียว ก็ยิ่งเป็นตัวกระตุ้นให้ปัญหานี้รุนแรงขึ้นได้
ผมไม่คิดว่านี่จะเป็นปัญหาที่เกิดจากการทำงานร่วมกันหรือการทำงานคนเดียวโดยตัวมันเองครับ
โปรดอ่านโดยคำนึงว่า Posthog มักเขียนบทความด้วยถ้อยคำที่รุนแรงแบบนี้อยู่เสมอ
เพราะน้ำเสียงแรงเกินไป จึงมักเห็นบทความที่เหมือนจะเลยประเด็นหลักและออกนอกทางอยู่บ่อย ๆ
(แต่น้ำโซดาดีจะตายไป!!!)
น้ำอัดลมนั่นไม่ใช่แท่นยิงไฮบอลหรอกเหรอ คึห์ม
ความเห็นจาก Hacker News
มีคำแนะนำว่าเมื่อใดก็ตามที่เกิดการทำงานร่วมกัน ให้พูดว่า “คนเยอะเกินไป, X เป็น driver ดังนั้นคุณตัดสินใจเลย”
แต่ถ้าผู้จัดการบอกว่า “คุณตัดสินใจเลย” แล้วไม่เข้าประชุม จากนั้นค่อยกลับมาทีหลังแล้วบอกว่า “ถ้าเป็นฉันจะทำอีกแบบ” พร้อมสั่งให้แก้ พนักงานก็จะลาออก
ผู้จัดการของผู้จัดการฉันพูดแบบนี้ตลอด แต่พอฉันเปิด PR เขากลับเรียกร้อง รีดีไซน์ ใหม่ทั้งหมด
สุดท้ายฉันก็กลัวงานไปเลย เพราะรู้ว่าไม่ว่าโปรเจกต์ไหนก็คงต้องเขียนใหม่ตั้งแต่ต้น
ถ้าหัวหน้ากลับคำตัดสินบ่อยเกินไป คนในทีมก็จะจงใจโยนทุกการตัดสินใจกลับไปให้หัวหน้า
สุดท้ายหัวหน้าก็จะหายใจไม่ออกเพราะ ความต้องการควบคุม ของตัวเอง
แต่ในบริบทของ “ผู้จัดการไม่ควรสั่งทุกอย่าง” มันก็ยังสอดคล้องกัน
เพราะหลังจากนั้นจะตามมาด้วยการจูนพิกเซลไม่รู้จบ การแก้เลย์เอาต์ และข้อเสนอให้รื้อสแตกใหม่ทั้งหมด
คิดว่าแก่นของปัญหาไม่ใช่การทำงานร่วมกัน แต่คือ โครงสร้างการตัดสินใจ
ฟีดแบ็กเป็นโอกาสในการเรียนรู้ แต่ถ้าไม่ชัดว่าใครเป็นคนตัดสินใจสุดท้าย ความเร็วก็จะช้าลง
ถ้าอยากตัดสินใจได้เร็ว ต้องระบุ ผู้มีอำนาจตัดสินใจ ให้ชัด และตระหนักว่าการตัดสินใจส่วนใหญ่ย้อนกลับได้
เมื่อการทำงานร่วมกันลดลง โอกาสในการเรียนรู้ก็ลดลงด้วย
ต้องกำหนดผู้ตัดสินใจให้ชัดเจน แต่ก็ต้องรับฟังฟีดแบ็ก
อีกทั้ง การตัดสินใจที่ย้อนกลับได้ ก็ควรตัดสินใจให้เร็ว
หลายคนบอกว่าการทำงานร่วมกันทำให้ช้าลง แต่จริง ๆ แล้วกระบวนการนั้นช่วยยกระดับคุณภาพ
บางคนคัดค้านเพียงเพื่อจะคัดค้าน สุดท้ายก็พยายามแย่ง ความเป็นเจ้าของ ของไอเดียไป
ถึงจะมีผู้ตัดสินใจสุดท้ายชัดเจน แต่ถ้าจุดยืนไม่แข็งพอ สุดท้ายก็จะไหลไปตามฉันทามติของคนหมู่มาก
พอเขากด “request changes” ทุกคนก็ต้องทำตาม สุดท้ายคุณภาพโค้ดกลับแย่ลง
ฉันคิดว่าการคัดคนดี ๆ มาแล้ว มอบอำนาจการตัดสินใจ ให้ จะดีกว่ามาก
ต้องกำหนดทิศทาง ลำดับความสำคัญ และ framework เพื่อให้ทีมตัดสินใจเองได้
ฉันไม่เห็นด้วยกับ ความเกลียดชังน้ำอัดลมโซดา ของผู้เขียน แต่ก็ดีใจที่มีการพูดถึงปัญหาการทำงานร่วมกันอย่างเปิดเผย
หลายบริษัทที่เคยอยู่ ฉันเสียเวลาใน code review ไปกับ การทักเรื่องสไตล์เล็กน้อย มากกว่าการลงมือทำจริงถึง 3 เท่า
จุดยืนของฉันคือ “ถ้าไม่ชอบก็แก้เองแล้วค่อยบอก”
และยังแชร์วิดีโอที่เกี่ยวข้องด้วย
มาจัดการตอน code review นั้นช้าเกินไป
ปัญหาคือคนที่ไม่ยอมทำให้เข้ากับสไตล์ของโค้ดรอบข้าง
ควรแก้ด้วย linter หรือวัฒนธรรมทีม
ฟีเจอร์ที่ทำคนเดียวโดยไม่มีการทำงานร่วมกันจะกลายเป็นความเสี่ยงใหญ่ตอนบำรุงรักษา
ถ้าระบบพังตอนฉันไม่อยู่ การขาดการทำงานร่วมกันก็จะเผยตัวว่าเป็นปัญหา
ผู้เขียนเน้นเรื่องอคติที่เอนเอียงไปทางการลงมือทำ แต่ถ้าตัดการทำงานร่วมกันออกไป ก็จะเกิด ไซโลและความมั่นใจเกินเหตุ
วัฒนธรรมใน Slack แบบ “ฉันกำลังจะทำ X มีใครคัดค้านแรง ๆ ไหม?” เคยได้ผลดี
เพราะแบบนั้นงานถึงเดินหน้าจริง
เมื่อก่อนฉันเคยสัมภาษณ์ตอนเขียนหนังสือเกี่ยวกับ GitHub แล้วพบว่าบางทีมจะเปิด PR เปล่า ก่อนเขียนโค้ดเพื่อขออนุมัติการออกแบบ
นี่ไม่ใช่การทำงานร่วมกันระหว่างลงมือทำ แต่เป็น การทำงานร่วมกันในขั้นวางแผน
ถ้ามีการเขียนและการสื่อสารที่ดี การทำงานร่วมกันก็จะรวดเร็วและมีประสิทธิภาพ
ในยุค AI ความสามารถแบบนี้จะยิ่งสำคัญขึ้น
ถ้าไม่มีการประชุมและการแชร์ ผลงานก็จะไม่เป็นที่เห็น
ถ้าป้องกันปัญหาไว้ได้ก็ไม่มีใครรู้ เลยเกิดวัฒนธรรมที่ “ปล่อยให้เกิดปัญหา” กันโดยเจตนา
แค่การวางแผนอย่างเดียวจินตนาการการ implement ได้ยาก
อย่างที่ประโยคสุดท้ายของบทความบอกว่า “การทำงานร่วมกันที่ดีมีอยู่จริง”
ชื่อเรื่องเป็นคลิกเบต แต่ PostHog ก็ขึ้นชื่อเรื่องสไตล์แบบนี้อยู่แล้ว
มันทำให้คนกลับมามองมีมเรื่อง “การทำงานร่วมกัน” อย่างวิพากษ์มากขึ้น
บทความนี้เป็นการทดลองทางความคิดที่ผิดตั้งแต่ต้น
ปัญหาไม่ใช่การทำงานร่วมกัน แต่คือ การขาดผู้มีอำนาจตัดสินใจ
ต้องมีคนหนึ่งที่ตัดสินใจอย่างชัดเจน และยิ่งกระจายอำนาจนั้นลงล่างมากเท่าไร ความเร็วยิ่งเพิ่มขึ้น
บทความแบบนี้บิดเบือนภาษาและมี พิษที่ทำให้แนวคิดที่จำเป็นกลายเป็นไร้ค่า
วัฒนธรรมที่พอมีใครติดขัดก็พูดทันทีว่า “ไปถาม Bob สิ” ก็เป็นปัญหาเหมือนกัน
ระยะสั้นอาจเร็ว แต่ระยะยาวจะทำให้ สูญเสียโอกาสในการเรียนรู้ และเกิด ภาระงานล้นมือ
ฉันชอบที่เพื่อนร่วมงานสนใจงานของฉัน
คำว่า “คุณจัดการเองเลย” จริง ๆ แล้วแทบจะแปลว่า “ฉันไม่สนใจ”
ปัญหาไม่ใช่การทำงานร่วมกัน แต่คือ การทำงานร่วมกันที่ไม่มีประสิทธิภาพ
ส่วน PR มีผลลัพธ์ที่เป็นรูปธรรมอยู่แล้ว ทำให้การคุยกันชัดเจนกว่า
รู้สึกว่าการทำงานร่วมกันทำงานได้ดีที่สุดตอนมีสองคน
คนสองคนสามารถเข้าใจ codebase ร่วมกันและรีวิว PR ของกันและกันได้
แต่พอมีสามคนขึ้นไป ความซับซ้อนเชิงการจัด组合 จะระเบิดขึ้นทันที
เพราะงั้นฉันเลยอยากออกแบบโปรเจกต์เป็น โครงสร้างทีมละ 2 คน
ลิงก์อ้างอิง
ตามอุปมาในบทความ การแข่งขัน F1 เป็นกีฬาที่ต้องทำงานร่วมกันอย่างสุดขั้ว
นักขับสื่อสารกับโค้ชตลอดทั้งการแข่งขัน
เลยสงสัยว่าในซอฟต์แวร์มีตัวอย่างแบบนี้ไหม
คอมเมนต์ต่าง ๆ ดูแปลกนะครับ ดูจากสรุปบทความแล้ว เหมือนประเด็นไม่ได้บอกให้ทำงานคนเดียวหรือไม่ต้องมีเพื่อนร่วมทีม แต่เป็นการเสนอให้ลดการทำงานร่วมกันระหว่างสมาชิกในทีมที่มากเกินไปมากกว่า
เห็นด้วยครับ
ดูเหมือนว่าจะเป็นผลลัพธ์จากการจับคู่กันของพาดหัวเรียกกระแสกับผู้อ่านที่ไม่ได้อ่านอย่างละเอียด
ไม่ใช่แค่บทความแบบนี้เท่านั้น แม้แต่ใน YouTube ก็มีคนจำนวนมากที่ดูแค่ชื่อเรื่องแล้วก็มาแสดงความคิดเห็นกัน
เมื่อเริ่มงานใหม่ ๆ บางครั้งเราอาจพยายามเล่นให้ปลอดภัยเกินไป จนขอให้คนรอบตัวช่วยรีวิวมากเกินความจำเป็น แต่จริง ๆ แล้วคนรอบตัวหรือแม้แต่ทีมเองอาจไม่ได้เข้าใจเรื่องนั้นดีพอ จึงให้ฟีดแบ็กที่ดีได้ยาก สุดท้ายแล้วการลงมือทำอะไรบางอย่างออกมาก่อน แม้จะเป็นทิศทางที่ผิดก็ตาม แล้วค่อยรับฟีดแบ็กที่เป็นรูปธรรมและนำกลับไปปรับแก้อีกครั้ง อาจช่วยประหยัดเวลาโดยรวมได้มากกว่า