- เหมือนกับงานวิจัยที่ระบุว่าในช่วงสงครามโลกครั้งที่ 2 มีทหารที่ยิงปืนจริงเพียง 15~20% เท่านั้น ผลลัพธ์ที่เป็นชิ้นเป็นอันส่วนใหญ่ในองค์กรก็มักถูกสร้างโดยคนเพียงส่วนน้อย
- วงการเทคเสนอ "การทำงานร่วมกัน" เป็นคำตอบของปัญหานี้ แต่ในความเป็นจริงกลับมีเพียงเครื่องมือประสานงานงานเพิ่มขึ้น ขณะที่โครงสร้างที่แทบไม่สร้างผลงานก็ฝังแน่นมากขึ้น
- ยิ่งกลุ่มใหญ่ขึ้น ต้นทุนการสื่อสารและต้นทุนการประสานงาน ก็ยิ่งพุ่งสูง และเกิดปรากฏการณ์ ความรับผิดชอบที่กระจายตัว จนการประชุมก่อให้เกิดการประชุมอีกต่อหนึ่ง
- เมื่อความโปร่งใสถูกสับสนกับความคืบหน้า และการมองเห็นถูกสับสนกับความรับผิดชอบ วัฒนธรรมการทำงานร่วมกันจึงกลายเป็นกลไกที่ทำให้ความรับผิดชอบส่วนบุคคลเจือจางลง
- งานที่ซับซ้อนและมีคุณภาพสูงจริง ๆ ส่วนใหญ่มักดำเนินการโดย บุคคลหรือกลุ่มขนาดเล็กที่มีอำนาจและความรับผิดชอบชัดเจน และ การทำงานร่วมกันก็ทำหน้าที่เป็นเพียงภาษาที่ใช้ห่อหุ้มสิ่งนั้น
- สิ่งที่จำเป็นจริง ๆ ไม่ใช่โครงสร้างพื้นฐานเพื่อการทำงานร่วมกัน แต่คือ การตัดสินใจอย่างเป็นเจ้าของและความรับผิดชอบของปัจเจก (ownership) และองค์กรจำเป็นต้องเปลี่ยนไปในทิศทางที่ไว้วางใจสิ่งนี้
ภาพลวงของการทำงานร่วมกัน
- การทำงานร่วมกัน (collaboration) ถูกมองราวกับเป็นสัญลักษณ์ของผลิตภาพในองค์กรสมัยใหม่ แต่ในความเป็นจริงมันกลับทำงานเป็น โครงสร้างของการหลีกเลี่ยงความรับผิดชอบและความไร้ประสิทธิภาพ
- ตามงานวิจัยของ S.L.A. Marshall ในช่วงสงครามโลกครั้งที่ 2 มีทหารเพียง 15~20% เท่านั้นที่ยิงปืนจริงระหว่างการรบ
- เช่นเดียวกับรูปแบบที่ IBM ค้นพบในทศวรรษ 1960 ว่า “80% ของการใช้งานมาจาก 20% ของฟังก์ชัน” คนเพียงส่วนน้อยเป็นผู้สร้างผลลัพธ์ส่วนใหญ่
- ที่เหลือให้เพียง “การสนับสนุนเชิงโครงสร้าง (structural support)” และเกิด ความไม่สมดุลของความพยายาม ซ้ำแล้วซ้ำเล่าในองค์กร
- อุตสาหกรรมเทคโนโลยีกลับหันไป ศรัทธาแนวคิดเรื่อง ‘การทำงานร่วมกัน’ ราวกับเป็นความเชื่อ เพื่อแก้ปัญหานี้
- มีเครื่องมือสำหรับการทำงานร่วมกันมากมาย เช่น Notion, ClickUp, Slack, Jira, Monday, Teams แต่สิ่งที่เพิ่มขึ้นคือ กิจกรรม (activity) มากกว่า ผลผลิต (output)
- ความโปร่งใสและการมองเห็นถูกเข้าใจผิดว่าเท่ากับความคืบหน้าหรือความรับผิดชอบ และ “การถูกใส่ไว้ในเธรด” ถูกมองว่าเท่ากับ “การเป็นเจ้าของผลลัพธ์”
- ด้วยเหตุนี้ การทำงานร่วมกันจึงเสื่อมสภาพกลายเป็น การจำลองการมีส่วนร่วม มากกว่าจะเป็นผลลัพธ์จริง
- การกระจายตัวของความรับผิดชอบ (diffusion of responsibility) เป็นปรากฏการณ์ที่ถูกสังเกตมานานแล้ว
- ในปี 1913 ผลของ Ringelmann แสดงให้เห็นว่าเมื่อขนาดของกลุ่มใหญ่ขึ้น สัดส่วนความพยายามของแต่ละบุคคลจะลดลง
- Frederick Brooks เสนอกฎผ่านกรณีของ IBM System/360 ในปี 1975 ว่า ถ้าเพิ่มคนเข้าไปในโครงการที่ล่าช้า มันจะยิ่งล่าช้ากว่าเดิม
- เมื่อจำนวนคนเพิ่มขึ้น ต้นทุนการสื่อสารและการประสานงานจะเพิ่มขึ้นแบบทวีคูณ และเกิดวงจรอุบาทว์ที่การประชุมก่อให้เกิดการประชุมอีกชั้นหนึ่ง
- อุตสาหกรรมการทำงานร่วมกันทุ่มทรัพยากรมหาศาลเพื่อปกปิดปัญหาเชิงโครงสร้างนี้ แต่ งานคุณภาพสูงจริง ๆ กลับถูกทำโดยคนไม่กี่คนหรือทีมขนาดเล็ก
- Dostoevsky เขียน 『พี่น้องคารามาซอฟ』 คนเดียว และ Apollo Guidance Computer ก็ถูกพัฒนาโดยทีมขนาดเล็กของ MIT ภายใต้ระบบความรับผิดชอบที่ชัดเจน
- ความสำเร็จที่แท้จริงเกิดจาก อำนาจที่ชัดเจนและความรับผิดชอบส่วนบุคคล ขณะที่การทำงานร่วมกันทำหน้าที่เพียงเป็นภาษาที่ใช้ห่อหุ้มผลลัพธ์นั้น
- ตรงกันข้าม องค์กรสมัยใหม่กลับเพียงสร้างโครงสร้างพื้นฐานการทำงานร่วมกันที่ซับซ้อนเพื่อ การจัดการทางสังคม (social management) โดยที่งานจริงถูกผลักไปอยู่เบื้องหลัง
- ความเป็นเจ้าของที่แท้จริง (ownership) มีอยู่ในรูปแบบที่แต่ละคนตัดสินใจด้วยตนเองและรับผลของมัน
- แต่ในสภาพแวดล้อมที่การทำงานร่วมกันกลายเป็นบรรทัดฐานทางวัฒนธรรม การตัดสินใจเพียงลำพังกลับถูกมองว่าเป็นพฤติกรรมไม่ให้ความร่วมมือ
- อุดมการณ์การทำงานร่วมกัน ทำให้ความรับผิดชอบและความริเริ่มดูคล้ายเป็นพฤติกรรมต่อต้านสังคม และสิ่งนี้บั่นทอนกลไกหลักของการผลิต
- การประชุม เอกสาร การทบทวนย้อนหลัง คิกออฟ ฯลฯ ถูกทำซ้ำอย่างไม่รู้จบ แต่สุดท้ายกลับเหลือเพียง ‘การประสานงานที่มากเกินไป’ ซึ่งไม่เชื่อมโยงกับการลงมือทำจริง
ความจำเป็นของการหวนกลับสู่ความรับผิดชอบส่วนบุคคล
- โครงการส่วนใหญ่กลายเป็นโครงสร้างแบบ เวลาในการประสานงาน > เวลาในการลงมือทำ และเมื่อเกิดความล้มเหลว คำตอบก็มักจบลงที่ “ต้องทำงานร่วมกันให้มากขึ้น”
- แต่คำถามที่แท้จริงคือ “เรากำลังสร้างอะไรอยู่จริง ๆ และใครเป็นผู้รับผิดชอบสิ่งนั้น”
- ไม่ว่าเรื่องใด ต้องมีผู้รับผิดชอบสูงสุดเพียงคนเดียว แม้ว่าโครงสร้างการทำงานร่วมกันจะบดบังการมีอยู่ของเขาหรือเธอก็ตาม
- จำเป็นต้อง ฟื้นฟูความไว้วางใจต่อปัจเจก
- ไม่จำเป็นที่ทั้งองค์กรต้องคอยเฝ้าดูทุกความรับผิดชอบ
- แทนที่จะเป็น การจัดการที่มากเกินไปและวัฒนธรรมที่ยึดเมตริกเป็นศูนย์กลาง แต่ละคนควรบริหารงานของตนเองและถูกประเมินจากผลลัพธ์
- และเมื่อเกิดความล้มเหลว ก็จำเป็นต้องมีโครงสร้างที่ระบุความรับผิดนั้นกลับไปยังบุคคลอย่างชัดเจน
- เราควรละทิ้ง ภาพลวงของความพยายามแบบหมู่คณะ และกลับไปสู่ สภาพแวดล้อมที่สามารถระบุได้ว่าใครคือคนที่ลงมือทำจริง
- กลับสู่โครงสร้างเรียบง่ายที่แต่ละคนจัดการงานของตนเอง และถูกประเมินจากผลลัพธ์นั้น
- เมื่อเราวางลงซึ่งเรื่องแต่งแสนอบอุ่นแต่มีราคาแพงที่เรียกว่า “การทำงานร่วมกัน” เราก็จะมองเห็นได้ชัดเจนว่า ใครกันแน่ที่เป็นคนเหนี่ยวไกจริง ๆ
20 ความคิดเห็น
ดูเหมือนเป็นแค่การเขียนยืดยาวเพื่อประกาศว่า 'ฉันทำงานร่วมกับคนอื่นไม่ได้' มากกว่านะ แม้ในองค์กรขนาดใหญ่จะไม่ใช่ว่าไม่มีกรณีที่แนวคิดเรื่องการทำงานร่วมกันกลายเป็นตัวถ่วง แต่แม้แต่สิ่งนั้นก็เป็นปรากฏการณ์ที่เกิดจากการทำงานร่วมกันได้ไม่ดี ไม่ใช่ปัญหาของการทำงานร่วมกันเอง
ดูเหมือนว่าผู้เขียนจะมีนิสัยไม่ค่อยดีเท่าไหร่นะครับ
555555555555555555 โอ๊ย ผมขำจนหลุดเลย 555555
"ในช่วงสงครามโลกครั้งที่ 2 มีทหารเพียง 15~20% เท่านั้นที่ยิงปืนจริง"
งานวิจัยและบทความติดตามที่โต้แย้งและวิเคราะห์ข้ออ้างเรื่อง "อัตราการยิง 15~20%" ของ Marshall โดยตรง ถูกพูดถึงอย่างมีน้ำหนักพอสมควรในแวดวงประวัติศาสตร์การทหาร ตั้งแต่ทศวรรษ 1980 เป็นต้นมา เมื่อบรรดานักประวัติศาสตร์และผู้เชี่ยวชาญด้านการทหารหลายคนติดตามบันทึกการวิจัยของ Marshall ก็ได้ข้อสรุปว่าตัวเลขดังกล่าวแทบเป็นข้อมูลที่ถูกแต่งขึ้น หรือไม่ก็ถูกพูดเกินจริงอย่างร้ายแรง
Robert Engen (2010) ได้วิเคราะห์แบบสอบถามและบันทึกการรบของนายทหารราบแคนาดาในช่วงสงครามโลกครั้งที่ 2 ซึ่งสู้รบในสภาพแวดล้อมที่คล้ายกับกองทัพสหรัฐฯ เขาพิสูจน์ว่าอัตราการยิงจริงของกองทัพแคนาดาสูงกว่าที่ Marshall อ้างไว้ที่ 15~20% อย่างท่วมท้น และโต้แย้งว่าข้ออ้างของ Marshall เป็นความผิดพลาดร้ายแรงจากการเหมารวม ซึ่งไม่อาจนำไปใช้กับฝ่ายสัมพันธมิตรตะวันตกทั้งหมดได้
ผมรู้สึกตั้งแต่ย่อหน้าแรกแล้วว่ามีอะไรแปลก ๆ เลยลองค้นดู ปรากฏว่าน่าจะเป็นข้อมูลที่เข้าใจผิดกันมา เหมือนกับที่คอมเมนต์ใน Hacker News ด้านล่างพูดไว้ด้วย
ความคิดเห็นจาก Hacker News
ตลอดเวลากว่า 30 ปีที่ฉันทำงานนี้ สิ่งที่เห็นคือ "เดดไลน์(date)" ถูกให้ความสำคัญมากกว่าผลลัพธ์จริงเสมอ
ทั้งที่ในความเป็นจริง แทบเป็นไปไม่ได้เลยที่จะทำให้ทันวันนั้น แต่องค์กรก็ยังใช้มันเป็นตัวชี้วัดเดียว
แทบไม่มีใครคำนึงถึงความจริงที่ว่าการพัฒนาซอฟต์แวร์เป็นกิจกรรมที่ คาดเดาไม่ได้โดยเนื้อแท้
ตอนที่ Agile Manifesto ออกมาใหม่ ๆ ยังพอมีความหวังอยู่บ้าง แต่ไม่นานมันก็เพี้ยนไปเป็นการบริหารแบบ “บอกมาให้แม่นว่าแต่ละขั้นจะใช้เวลานานแค่ไหน”
ช้ากว่านิดหน่อยมักพอให้อภัยได้ แต่ถ้าขอเงินเพิ่มจะถูกเกลียดไปอีกนาน
Agile จะเวิร์กก็ต่อเมื่อมี Product Owner ที่ดี ซึ่งมีงบประมาณและอำนาจตัดสินใจที่เหมาะสมเท่านั้น
ทีมจะส่งมอบได้เท่าที่ทำทันภายในช่วงเวลา และยิ่งใกล้เดดไลน์ก็ยิ่งตัดฟีเจอร์ออก
เป็นวิธีที่รับประกันการส่งมอบ มากกว่ารับประกันเนื้อหาของสิ่งที่ส่ง
ถ้าวันที่มันสำคัญขนาดนั้น การลองแนวทางแบบนี้ก็น่าจะไม่เลวใช่ไหม?
องค์กรเล็กมักยังมีผู้มีส่วนได้ส่วนเสียตัวจริงอยู่ แต่ในองค์กรใหญ่ ผลงานกับเส้นทางอาชีพถูกแยกออกจากกัน
ฉันทำงานด้านฮาร์ดแวร์ และกำหนดเป้าหมายปลายปีของตัวเองว่า “ต้องอยู่ในสภาพที่เดโมได้ด้วยโค้ดที่ฉันเขียนเองโดยตรง”
บอกว่า “ต้องใช้เวลาหลายสัปดาห์” แต่จริง ๆ ทำเสร็จใน 30 วินาที
ฉันว่าผู้เขียนพูดแรงเกินไปหน่อย
บางทีเขาอาจมีบาดแผลจากการทำงานใน ทีมที่ทำงานร่วมกันได้ห่วยมาก
แต่ทีมที่บริหารจัดการดีมีอยู่จริง และ กลุ่มคนก็สร้างผลงานได้มากกว่าปัจเจก
ทั้งพีระมิด, Linux kernel และ AWS ก็ไม่ได้ถูกสร้างโดยคนคนเดียว
ยิ่งทีมใหญ่ communication overhead ก็ยิ่งมาก และส่วนหนึ่งของมันก็มาจากความต้องการมองเห็นงานของฝ่ายบริหาร
ทีมที่ดีจะสื่อสารกันภายในได้ดี แต่ฝ่ายบริหารก็ยังต้องการ visibility ในระดับหนึ่ง
สุดท้ายแล้วต้องมีทั้ง ทีมที่ดี + ผู้จัดการที่ดี
องค์กรส่วนใหญ่ทำ collaboration ได้ไม่ดี แต่กลับใช้คำว่าการทำงานร่วมกันมาปิดทับความล้มเหลวนั้น
แต่อย่างไรก็ตาม ข้ออ้างว่า “มีแต่ทีมเล็กเท่านั้นที่ทำงานได้” ก็เกินจริงไปหน่อย
ตัวอย่างอย่างการสร้างพีระมิด ในความหมายสมัยใหม่มันไม่ใช่ collaboration เท่าไร แต่ใกล้กับ ระบบสั่งการที่เข้มงวด มากกว่า
โปรแกรมคอมพิวเตอร์ของ Apollo ถูกทำโดยทีมเล็กก็จริง แต่การจะไปถึงดวงจันทร์ต้องอาศัยความร่วมมือมากกว่านั้นมาก
หลักฐานที่ว่าการทำงานร่วมกันได้ผลจริงมีอยู่มากเกินกว่าจะมองข้าม
คนเดียวสร้างเกมฟอร์มยักษ์แบบ Assassin’s Creed ไม่ได้ และคณะกรรมการก็สร้างเกมแบบ Stardew Valley ไม่ได้เช่นกัน
มันเป็นความสามารถคนละประเภท
ฉันก็อินกับประสบการณ์ของผู้เขียนเหมือนกัน
หลังถูกเลย์ออฟจากสตาร์ทอัพ ฉันย้ายไปบริษัทใหญ่ ตอนแรกทีมเวิร์กเข้าขากันดีและผลงานก็ดีมาก
แต่แล้ว Agile coach ก็โผล่มาและเริ่มยัดเยียดวาระของตัวเองโดยอ้าง “การทำงานร่วมกัน”
ตลอด 8 เดือนมีแต่เวิร์กช็อปไร้ประโยชน์กับการแย่งชิงอำนาจ สุดท้ายทีมเก่ง ๆ กลับต้องถูกทีมที่ไร้เรี่ยวแรงลากไป
ปัญหาคือ วัฒนธรรมที่ไม่ไล่คนไร้ความสามารถออก
การทำงานร่วมกันจริง ๆ จะเกิดขึ้นได้ก็ต่อเมื่อทุกคน ลดอีโก้ลง รับฟังกัน และลงมือทำงาน
ถ้าทำงานคนเดียว คุณอาจทำงานได้มากกว่า แต่ก็มีความเสี่ยงสูงที่จะ นิยามปัญหาผิด
การทำงานร่วมกันช่วยป้องกันเรื่องนั้นด้วยมุมมองที่หลากหลาย
คนที่ไม่ทำงานกลับรบกวนคนที่กำลังทำงานอยู่
ไม่นานมานี้ฉันอ่านบทความของ McEntire ชื่อ “The Organizational Physics of Multi-Agent AI” แล้วน่าสนใจมาก
แม้แต่ AI agent ก็ยังจำลอง ความไร้ประสิทธิภาพทางการเมือง ขององค์กรมนุษย์ออกมาเหมือนเดิม
สุดท้ายถ้าองค์กรแย่ ทุกคนก็จะเอาแต่ทำ “งานเกี่ยวกับงาน(work about work)”
ทีมเล็กที่มีความรับผิดชอบชัดเจน น่าสนุกกว่ามาก แต่ก็ทำซ้ำได้ยาก
ฉันก็พูดเรื่องนี้ไว้ในบล็อก Where to Cut ของตัวเองด้วย
ยิ่งรู้สึกว่าการ orchestration จะทำงานได้ ก็ต่อเมื่อบทบาทและโครงสร้างชัดเจนเท่านั้น
พอเปลี่ยนคนหรือย้ายทีมก็จะมี ต้นทุนของการสลับบริบท ทำให้ความเหนียวแน่นของทีมพังลง
ต้นฉบับอ่านแล้วแทบไม่รู้ว่าต้องการจะสื่ออะไร
วัฒนธรรมที่ไม่ให้การยอมรับคนที่ทำผลงานได้จริง กัดกินองค์กรจากข้างใน
20% ที่แบกรับน้ำหนักมากกว่าคนอื่น แค่อยาก ได้รับการยอมรับ เท่านั้น
ถ้าไม่ให้สิ่งนั้น บริษัทก็จะว่างเปล่าอย่างรวดเร็ว
ฉันไม่สนใจคำชมจากคนที่ไม่รู้ด้วยซ้ำว่าฉันทำอะไร
บทความนี้สามารถขยายไปไกลกว่าเรื่ององค์กร สู่ ความหมายทางสังคมของ ‘ลิขสิทธิ์และความเป็นเจ้าของผลงาน’ ได้ด้วย
งานที่ซับซ้อนและคุณภาพสูงท้ายที่สุดมักออกมาจาก ความรับผิดชอบที่ชัดเจนของทีมเล็กหรือคนคนเดียว
อย่างเช่น Dostoevsky หรือทีมคอมพิวเตอร์ Apollo
ในทางกลับกัน ยูโทเปียของการทำงานร่วมกันแบบ “ทุกคนมีส่วนร่วมแต่ไม่มีใครได้รางวัล” นั้นห่างไกลจากความจริง
มนุษย์มีแรงจูงใจมากกว่ากับ ผลงานสร้างสรรค์ที่มีชื่อตัวเองกำกับอยู่
ห่วงโซ่อุปทานที่ซับซ้อนเองก็เป็น collaboration อีกรูปแบบหนึ่ง
ฉันสงสัยกับคำกล่าวที่ว่า “80% ของทหารไม่ได้ยิงปืน” เลยไปค้นดู แล้วพบว่ามันเป็นข้อมูลที่ ถูกโต้แย้งมานานแล้ว
ในบทความปี 2011 ก็ระบุว่าหลักฐานของเรื่องนี้อ่อนมาก
ถ้าดู สัดส่วน tooth-to-tail ของกองทัพสหรัฐ กำลังพลที่อยู่แนวรบจริงมีเพียงราว 4~10% เท่านั้น
ดังนั้นสาเหตุอาจเป็นการสับสนของตัวเลข
แต่ในขณะเดียวกัน อัตรา PTSD ก็เพิ่มขึ้น ด้วย
โดยรวมแล้วบทความนี้ให้ความรู้สึกเหมือน ความพยายามที่ไม่ปะติดปะต่อในการดึงกรณีของทหารมาใช้เป็นโมเดลสำหรับงานออฟฟิศ
แต่ก็ยังมีข่าวดีสำหรับผู้เขียน — คุณเองก็เป็น ผู้สร้างงานเดี่ยว ได้
เหมือน Notch หรือผู้พัฒนา Stardew Valley
แทนที่จะบ่น ก็ลงมือสร้างอะไรสักอย่างด้วยตัวเองได้เลย
การที่ 80% ไม่ยิงปืนเลยยังเป็นข้อเท็จจริงที่ชวนคิด
ผู้เขียนไม่ได้พิจารณาเรื่อง การออกแบบแรงจูงใจต่อผลงาน เลย
อย่างที่ Munger พูดไว้ว่า “ดูแรงจูงใจ แล้วคุณจะรู้ผลลัพธ์”
สิ่งที่สำคัญยิ่งกว่าความยากของการทำงานร่วมกัน คือการสร้าง โครงสร้างที่ให้รางวัลคนทำผลงานและลงโทษคนเกาะฟรี
และก็ไม่ได้มากนัก
ถ้าทำได้ เราคงอยู่ในยูโทเปียกันไปแล้ว
นอกจากข้อเท็จจริงที่ว่าแม้แต่เหตุผลตั้งต้นในบรรทัดแรกก็ไม่ตรงกับความเป็นจริงแล้ว การเอาประเด็นเรื่องการยิงปืนในสงคราม (สามารถฆ่าคนได้, ระดับการฝึกของทหารในช่วงสงคราม... ฯลฯ ซึ่งมีหลายปัญหาปะปนกันอยู่) มาเชื่อมโยงกับปัญหาการทำงานร่วมกันในการพัฒนา ก็ดูแปลกตั้งแต่แรกแล้ว นี่เป็นบทความที่พิสูจน์ว่าการเปิดเรื่องนั้นสำคัญใช่ไหม...
ดูจากปฏิกิริยาต่าง ๆ แล้ว เหมือนจะมีคนจำนวนมากที่ใช้ชีวิตอยู่ในความเข้าใจผิดตามที่บทความนี้พูดไว้จริง ๆ
ต่อให้เป็นเพียงแค่
1 + 1 = 1.1ก็ตาม ไม่ว่าแต่ละคนจะมีผลิตภาพสูงแค่ไหน ก็ไม่อาจสร้างผลงานที่มากไปกว่าคน 1,000 คนที่ทำงานอย่างไม่มีประสิทธิภาพได้เพราะการพัฒนาซอฟต์แวร์มีทั้งมิติของงานช่างฝีมือแบบทำด้วยมือ และมิติของสินค้าที่ผลิตจากโรงงานด้วย
คนฉลาดแค่ไม่กี่คนจัดระบบไว้ดี ทำให้แม้แต่พวกโง่ก็เข้าใจได้และทำงานต่อได้ดี พวกโง่พวกนั้นก็เลยหลงคิดไปเองว่าตัวเองกำลังทำงานร่วมกันอยู่ 555
แม้เป็นความจริงที่การทำงานร่วมกันส่วนใหญ่มักล้มเหลว แต่ทุกสิ่งยิ่งใหญ่รวมถึงการกำเนิดของชีวิตล้วนเกิดจากการทำงานร่วมกัน
ถ้าไม่ใช่อัจฉริยะระดับสุดยอดจริง ๆ ต่อให้เก่งแค่ไหนก็ทำงานคนเดียวไม่ได้หรอก ถึงอีก 80% ที่เหลือจะทำได้แค่คอยเชียร์อยู่ข้าง ๆ แต่แค่คอยหนุนใจก็ยังนับเป็นแรงงานได้ครึ่งคน และพวกตัวท็อปที่ทำงานได้เท่า 2~3 คนก็ทำให้บริษัทเดินต่อไปได้ ถ้าทำงานคนเดียวก็จะไม่รู้สึกว่าได้รับการยอมรับ แถมยังเหงาจนทนไม่ไหวด้วย
เห็นด้วยมากครับ
โดยเฉพาะเวลาที่เอาแต่เพิ่มงานสารพัดในเครื่องมือ collaboration เพื่อให้ดูมี visibility และ transparency มากกว่ามุ่งไปที่ผลลัพธ์จริง...
เวลาเห็นพวก PM จดโน้ตทิ้งไว้ทุกอย่างเพื่อจะได้ลดความรับผิดชอบของตัวเอง ในฐานะนักพัฒนาแล้วได้แต่รู้สึกหมดไฟครับ
ดูเหมือนนักเรียนมัธยมปลายที่เพิ่งค้นพบพิธีรีตองจอมปลอมของพวกผู้ใหญ่เป็นครั้งแรกแล้วเริ่มโกรธขึ้นมา ยังไงไม่รู้ ผู้เขียนก็น่าจะชอบโฮลเดน คอลฟิลด์จาก The Catcher in the Rye ล่ะมั้ง...
ขึ้นอยู่กับขนาดของโปรเจกต์ บางครั้งการที่คนคนหนึ่งเป็นผู้นำอย่างเด็ดขาดอาจสำคัญกว่าการมีส่วนร่วมของทั้งทีมก็ได้... แต่ถ้าขนาดต่างกันก็อาจไม่ใช่แบบนั้น
น่าจะเป็นแบบนี้ไหม..
กฎพิซซ่า 2 ถาดนั่นแหละ
การร่วมมือกันไม่มีประโยชน์
เหมือนเคยเห็นชื่อแบบนี้มาก่อนนะ...
ดูเหมือนว่าแม้แต่ข้อมูลที่ยกมาในบรรทัดแรกก็ยังไม่ได้รับการตรวจสอบเลยนะครับ
ยิ่งเป็นองค์กรขนาดใหญ่ก็ยิ่งรู้สึกว่าสิ่งที่ผู้พูดคนนี้พูดนั้นถูกต้อง
ส่วนยิ่งเป็นองค์กรขนาดเล็กก็ยิ่งรู้สึกว่าทิศทางที่ผู้พูดคนนี้พูดถึงนั้นกลายเป็นจริงไปแล้วเหมือนกันครับ 555
ในช่วงเวลานี้ที่ AI TOOLs กลายเป็นความจริงแล้ว ผมคิดว่านี่เป็นบทความที่ค่อนข้างสมจริงและมีมุมมองที่น่าเชื่อถือเกี่ยวกับการยกระดับ man power ของแต่ละบุคคลให้สูงสุด
ต่อจากนี้ทุกอย่างจะยิ่งต้องการความเบาและความเร็วมากขึ้นเรื่อย ๆ ดังนั้นแนวคิดการทำงานร่วมกันแบบเก่าที่ทำกันมาจนถึงตอนนี้ก็คงถูกรีเซ็ตไป อย่างไรก็ตาม สำหรับการพัฒนาโซลูชันระดับเอ็นเตอร์ไพรส์ การทำงานร่วมกันยังคงเป็นสิ่งจำเป็น