- แก่นสำคัญของ “Seeing Like A State(มองแบบรัฐ)” ของ James C. Scott คือ องค์กรพยายามยกระดับ “ความอ่านออกได้ (legibility)” ของระบบ เพื่อเปลี่ยนทุกอย่างให้วัดผลและรายงานได้
- แต่ในความเป็นจริง งานแบบ “อ่านออกไม่ได้” ที่ติดตามหรือคาดการณ์ไม่ได้กลับเป็นสิ่งจำเป็น และหากให้ความสำคัญกับความอ่านออกได้เพียงอย่างเดียว ก็อาจทำให้ประสิทธิภาพลดลงแทน
- โดยเฉพาะในองค์กรขนาดใหญ่ที่ ทำให้งาน “อ่านออกได้” ผ่านกระบวนการอย่างแผนรายไตรมาส, OKR, Jira ฯลฯ แต่สิ่งนี้กลับย้อนแย้งด้วยการลดทอนประสิทธิภาพ และทำให้บริษัทขนาดเล็กอาจมีประสิทธิภาพสูงกว่าถึง 20 เท่า
- องค์กรยังเปิดพื้นที่แบบอ่านออกไม่ได้ชั่วคราวอย่าง "ไทเกอร์ทีม" เพื่อรับมือสถานการณ์เร่งด่วน และการร่วมมือแบบไม่เป็นทางการผ่านแบ็กแชนเนลระหว่างวิศวกรก็มีบทบาทสำคัญพอ ๆ กับกระบวนการทางการ
- ความสำเร็จของบริษัทเทคโนโลยีขึ้นอยู่กับ การรักษาสมดุลระหว่างกระบวนการที่อ่านออกได้กับงานภาคปฏิบัติที่อ่านออกไม่ได้ เพราะหากมีเพียงอย่างใดอย่างหนึ่ง องค์กรก็จะทำงานได้ไม่เต็มที่
บทนำ: แนวคิดหลักของ “Seeing Like A State”
- ใจความสำคัญของหนังสือ “Seeing Like A State(มองแบบรัฐ)” ของ James C. Scott สรุปได้เป็น 3 ข้อดังนี้
- องค์กรสมัยใหม่เปลี่ยนระบบให้เป็นรูปแบบที่เพิ่ม “ความอ่านออกได้ (legibility)” สูงสุด เพื่อควบคุมให้ทุกส่วนวัดผลและรายงานได้
- แต่อีกด้านหนึ่ง องค์กรเหล่านี้พึ่งพางานขนาดมหาศาลที่ “อ่านออกไม่ได้ (illegible)” กล่าวคือ มีงานจำนวนมากที่ติดตามหรือวางแผนไม่ได้ แต่จำเป็นอย่างยิ่ง
- การเพิ่มความอ่านออกได้มักบั่นทอนประสิทธิภาพ แต่ผลประโยชน์ด้านอื่น ๆ ของมัน เช่น การควบคุม การวางแผน และความโปร่งใส กลับถูกมองว่าคุ้มค่าอย่างมาก
- ความอ่านออกได้หมายถึงงานที่คาดการณ์ได้ ติดตามผลลัพธ์ได้ และไม่ขึ้นกับบุคลากรเฉพาะคน ตัวอย่างเช่น การจัดการตารางเวลา, OKR, Jira เป็นต้น
- ความอ่านออกไม่ได้คืองานที่ต้องอาศัยการด้นสดหรือความรู้ฝังลึก เป็นความร่วมมือหรือการเปลี่ยนแปลงกะทันหันที่ไม่อาจเขียนหรือทำให้เป็นทางการได้ รวมถึงงานที่พึ่งพาความสัมพันธ์ระหว่างคน
กรณีศึกษา “มองแบบรัฐ (Seeing like a state)”
- Scott ใช้กรณี “ป่าที่เป็นระเบียบ” ในเยอรมนีศตวรรษที่ 19 เพื่ออธิบายความพยายามขององค์กรในการควบคุมและทำให้เป็นมาตรฐานเพื่อประสิทธิภาพ
- มีความคาดหวังว่า หากจัดการป่าให้เห็นต้นไม้ทุกต้นได้ในภาพเดียว ก็จะช่วยให้การวางแผน การซื้อขาย และการจัดสรรทรัพยากรมีประสิทธิภาพมากขึ้น
- แต่ในความจริง ความหลากหลายของป่าและบทบาทของพืชชั้นล่างกลับถูกมองข้าม ทำให้ผลผลิตลดลง และป่าเปราะบางต่อโรคกับปรสิตมากขึ้น
- กล่าวคือ แม้จะต้องการทั้งประสิทธิภาพและความโปร่งใส แต่การไล่ตาม ความอ่านออกได้ มากเกินไปกลับให้ผลตรงกันข้ามและบั่นทอนประสิทธิภาพ
ความอ่านออกได้และความอ่านออกไม่ได้ในบริษัทซอฟต์แวร์
- บริษัทซอฟต์แวร์ก็ไม่ต่างกัน เพราะทีมเล็กหรือแม้แต่คนคนเดียวอาจทำงานได้มีประสิทธิภาพมากกว่า
- ในหมู่วิศวกรซอฟต์แวร์แทบเป็นเรื่องสามัญสำนึกว่า วิศวกรคนเดียวที่ทำงานลำพังอาจมีประสิทธิภาพมากกว่าตอนทำงานเป็นส่วนหนึ่งของทีม
- งานที่วิศวกรขับเคลื่อนเองมัก เดินหน้าได้เร็วกว่างานที่ถูกสั่งมาจากเบื้องบนมาก เพราะไม่จำเป็นต้อง แปลให้อยู่ในรูปแบบที่มีความหมายสำหรับทุกฝ่าย หรือ สื่อสารเชิงรุกไปทุกทิศทาง
- เหตุผลที่บริษัทซอฟต์แวร์ขนาดเล็กมักส่งมอบซอฟต์แวร์ได้ดีกว่าบริษัทใหญ่ ก็เพราะถึงแม้องค์กรใหญ่จะทุ่มวิศวกรมากกว่า 10 เท่า แต่ถ้าบริษัทเล็กมีประสิทธิภาพมากกว่า 20 เท่า ก็ยังเหนือกว่าอยู่ดี
- ใน บริษัทใหญ่ มักนำขั้นตอนและเครื่องมือต่าง ๆ มาใช้เพื่อทำให้งานของวิศวกร “อ่านออกได้”
- แม้จะเอื้อต่อการวางแผน การวัดผล และการรายงาน แต่ก็อาจทำให้ผลิตภาพการพัฒนาซอฟต์แวร์จริงลดลง
- บริษัทเล็กสามารถตอบสนองต่อปัญหาได้ทันทีหรือรับการเปลี่ยนแปลงได้รวดเร็วกว่า ซึ่งเป็นความสามารถแบบอ่านออกไม่ได้
- เหตุผลที่บริษัทใหญ่ยังคงรักษาขั้นตอนอันซับซ้อนเหล่านี้ไว้ แทนที่จะเลือกประสิทธิภาพแบบนั้น เป็นเพราะเกี่ยวข้องกับ สัญญาองค์กรขนาดใหญ่ ลูกค้ารายใหญ่ต้องการความคาดการณ์ได้และความน่าเชื่อถือจากผู้ขาย
- การทำงานร่วมกับลูกค้าแบบนี้จึงจำเป็นต้องมีความอ่านออกได้ เช่น แผนระยะยาว คำมั่นสัญญาเรื่องฟีเจอร์ และการทำเอกสารความคืบหน้า
- กระบวนการจึงยังคงอยู่ เพราะมูลค่าที่ความอ่านออกได้สร้างขึ้นในเชิงรายได้ สูงกว่าความสามารถในการผลิตซอฟต์แวร์ให้มีประสิทธิภาพกว่าเดิม
มูลค่าที่แท้จริงของความอ่านออกได้สำหรับบริษัทใหญ่
- ในบริษัทซอฟต์แวร์ขนาดใหญ่ ความอ่านออกได้หมายถึง
- สามารถ มองเห็นทุกโปรเจ็กต์ที่กำลังดำเนินอยู่ ได้แม้ในระดับวิศวกรรายบุคคล
- สามารถดึง รายการโปรเจ็กต์ที่เสร็จสิ้นในไตรมาสก่อน ออกมาได้ทันที
- สามารถ วางแผนงานล่วงหน้าอย่างน้อยหนึ่งไตรมาส (หรือมากกว่านั้น)
- เมื่อเกิดเหตุฉุกเฉิน สามารถ ระดมทรัพยากรทั้งแผนก มาทุ่มให้กับงานเร่งด่วนได้ทันที
- บริษัทซอฟต์แวร์ขนาดเล็กแทบไม่สามารถตอบโจทย์เหล่านี้ได้ ยกเว้นเพียง ความสามารถในการตอบสนองอย่างยืดหยุ่นทันที
- บริษัทใหญ่เก่งเรื่องการบันทึก การจัดหมวดหมู่ และการวางแผนระยะยาว แต่ในด้านความสามารถในการตอบสนองอย่างรวดเร็วกลับอาจอ่อนลง
- การทำให้เกิดความอ่านออกได้นี้มีบทบาทสำคัญอย่างยิ่งต่อ ความเชื่อมั่น สัญญา และความร่วมมือระยะยาวกับลูกค้าองค์กร
สมมติฐานเพื่อสร้างความอ่านออกได้ และข้อจำกัดของมัน
- ระหว่างผลักดันความอ่านออกได้ บริษัทใหญ่มักตั้งสมมติฐานง่าย ๆ ดังนี้
- สมมติว่า วิศวกรทุกคนในระดับเดียวกันทำงานได้ใกล้เคียงกัน
- สมมติว่า การย้ายหรือจัดโครงสร้างวิศวกรใหม่ไม่ทำให้ผลิตภาพสูญเสีย
- สมมติว่า หากจำนวนวิศวกรในทีมเท่าเดิม ระดับผลิตภาพก็จะคงเดิมเมื่อเวลาผ่านไป
- สมมติว่า โปรเจ็กต์สามารถประเมินล่วงหน้าได้ และมีช่วงความคลาดเคลื่อนที่พอรับได้
- แต่ในความเป็นจริง
- แม้อยู่ระดับเดียวกัน ความสามารถก็แตกต่างกันมาก และ ความเชี่ยวชาญกับความสนใจ ส่งผลอย่างมากต่อผลิตภาพของโปรเจ็กต์
- ขนาดทีมกับผลิตภาพมีความสัมพันธ์กันเพียงเล็กน้อย
- การประเมินโปรเจ็กต์แทบเป็นเรื่องลวงตา และในทางปฏิบัติ วิธีทำงานก็มักถูกเปลี่ยนเพื่อให้ตรงกับกำหนดการที่ประเมินไว้
- ถึงอย่างนั้น สมมติฐานเหล่านี้ก็ยังมีประโยชน์ต่อการสื่อสารภายในบริษัท การทำข้อตกลงกับองค์กรใหญ่ภายนอก และการวางแผนธุรกิจ
พื้นที่อ่านออกไม่ได้ที่ได้รับอนุญาตชั่วคราว
- ในบริษัทใหญ่ กระบวนการที่สร้างความอ่านออกได้มักทำให้เกิดความล่าช้าอย่างรุนแรง
- ไอเดียผลิตภัณฑ์ → ขั้นวางแผนขององค์กรผลิตภัณฑ์ → การทบทวนทางเทคนิคโดยองค์กรวิศวกรรม → การเจรจาจัดสรรทีมระหว่าง VP และผู้จัดการอาวุโส → เข้าแผนงานค้างของทีม → เข้าคิวตั๋วงานของทีม → เข้า sprint → เริ่มลงมือทำจริง
- โครงสร้างแบบนี้ ไม่สอดคล้องเลยกับงานที่ต้องทำทันที
- เพื่อแก้ปัญหานี้ องค์กรจึงยอมให้มี พื้นที่อ่านออกไม่ได้ชั่วคราว อย่าง "ทีมเสมือน", "ทีมจู่โจม", "ไทเกอร์ทีม"
- ประกอบด้วยวิศวกรที่องค์กรคัดเลือกและไว้วางใจ
- หลายครั้งไม่มีผู้จัดการประจำทีมเลย และให้วิศวกรอาวุโสมากเป็นผู้ขับเคลื่อนโปรเจ็กต์
- ได้รับมอบหมายภารกิจแบบกว้าง ๆ และได้รับอิสระให้ทำแทบทุกอย่างเพื่อบรรลุเป้าหมาย
- นี่คือ การประนีประนอมอย่างชาญฉลาดระหว่างความอ่านออกไม่ได้โดยสมบูรณ์กับความอ่านออกได้โดยสมบูรณ์
- แม้จะเลี่ยงกระบวนการทางการ แต่ก็ไม่ได้ถูกใช้เป็นระบบถาวร และคงอยู่เพียงชั่วคราวเท่านั้น
- แม้แต่ความอ่านออกไม่ได้ที่ได้รับอนุญาตก็ยัง อยู่ร่วมกับองค์กรส่วนอื่นอย่างกระอักกระอ่วน วิศวกรคนอื่นอาจรู้สึกอิจฉาหรือมองว่าเสี่ยง เมื่อเห็นคนกลุ่มนี้ทำงานได้โดยไม่ต้องแบกรับภาระจากกระบวนการ
พื้นที่อ่านออกไม่ได้ถาวรและไม่ได้รับอนุญาต
- วิธีทางการที่วิศวกรทีม A จะขอให้ทีม B ทำงานให้ คือ สร้าง issue ใน backlog ของ “การวางแผน” แล้วผ่านกระบวนการ 12 ขั้นตอนเพื่อรอให้เข้าสู่ sprint ซึ่งใช้เวลาตั้งแต่หลายสัปดาห์ถึงหลายเดือน
- แนวทางแก้แบบทางการคือ ทีม A ต้องคาดการณ์งานของทีม B ไว้ตั้งแต่ในกระบวนการวางแผน แต่การคาดการณ์การเปลี่ยนแปลงทั้งหมดล่วงหน้าหลายเดือนก่อนเริ่มเขียนโค้ดนั้นแทบเป็นไปไม่ได้
- วิธีแก้จริงที่เกิดขึ้นคือ แบ็กแชนเนลแบบอ่านออกไม่ได้
- วิศวกรทีม A ขอวิศวกรทีม B ว่า "ช่วยแก้หนึ่งบรรทัดนี้ให้หน่อยได้ไหม?"
- วิศวกรทีม B ลงมือทำให้ทันที และการจะสร้างตั๋วงานหรือไม่ก็เป็นเรื่องเลือกได้
- สิ่งนี้ อ่านออกไม่ได้ เพราะอาศัยความสัมพันธ์ระหว่างบุคคลของวิศวกร
- แบ็กแชนเนลมีอยู่ตลอดในทุกระดับของบริษัท
- ทั้งแบ็กแชนเนลข้ามทีมระหว่างวิศวกร, ภายในทีม, ระหว่างผู้จัดการ, และระหว่างผู้จัดการผลิตภัณฑ์
- เมื่อมีการตั้งคำถามในพื้นที่ทางการ บ่อยครั้งคำตอบนั้นได้ถูกซ้อมและทบทวนกันเป็นการส่วนตัวมาก่อนแล้ว
- แบ็กแชนเนล ก็อาจผิดพลาดได้ และบางครั้งถูกใช้เพื่อแสวงหาประโยชน์ให้ตัวเองโดยทำให้วิศวกรที่ไร้เดียงสาเป็นฝ่ายเสียเปรียบ
โซซิโอพาธ คนไม่รู้เกม และผู้แพ้
- “Gervais Principle” ของ Venkatesh Rao แบ่งองค์กรออกเป็น 3 กลุ่ม
- “โซซิโอพาธ” ที่อยู่ชั้นบนสุด ใช้กฎขององค์กรอย่างเย็นชาเพื่อผลประโยชน์ของตนเอง
- “คนไม่รู้เกม (clueless)” ในสายผู้จัดการระดับกลาง เชื่อในกฎทางการขององค์กร และไม่ตระหนักว่ามีเกมที่ลึกกว่านั้นกำลังเล่นอยู่
- ด้านล่างลงมาคือ “ผู้แพ้ (losers)” ที่รู้ว่าเกมกำลังเกิดขึ้น แต่ไม่ต้องการมีส่วนร่วม
- หมวดหมู่เหล่านี้สามารถอ่านผ่านมุมมองของ ความอ่านออกได้ ได้เช่นกัน
- ทั้งโซซิโอพาธและผู้แพ้ต่างก็มีส่วนเกี่ยวข้องกับโลกที่อ่านออกไม่ได้ขององค์กร
- ส่วน “คนไม่รู้เกม” เกี่ยวข้องเฉพาะกับกระบวนการที่อ่านออกได้เท่านั้น และเมื่ออยากเลื่อนตำแหน่ง ก็จะไปดู career ladder อย่างเป็นทางการ แล้ววางแผนว่าจะทำคุณค่าของระดับถัดไปแต่ละข้อให้ได้อย่างไร
- อย่างไรก็ตาม การเรียกคนกลุ่มนี้ว่า “คนไม่รู้เกม” ก็อาจประชดประชันเกินไป
- กระบวนการที่อ่านออกได้ยังคงสำคัญมาก และเป็นส่วนใหญ่ของสิ่งที่องค์กรทำอยู่
- การปรับปรุงกระบวนการทางการก็ยังเป็นงานที่มี leverage สูงมาก
- การมองผู้คนผ่านหมวดหมู่เหล่านี้ช่วยให้ เข้าใจได้ว่าพื้นที่ความขัดแย้งที่เกิดขึ้นบ่อยในบริษัทซอฟต์แวร์ มักมีต้นตอมาจากแรงเสียดทานระหว่างกลุ่มเหล่านี้
ความคิดส่งท้าย
- การตระหนักและใช้ประโยชน์จากโลกที่อ่านออกไม่ได้ภายในองค์กรเป็นเรื่องสำคัญ
- ผู้เขียนเคยเขียนไว้มากเกี่ยวกับการมองเห็นและใช้ความอ่านออกไม่ได้ในบริษัทเทคโนโลยี
- คำแนะนำเกี่ยวกับกระบวนการที่อ่านออกไม่ได้ถือเป็น “คำแนะนำอันตราย”
- หากประกาศต่อสาธารณะว่าคุณทำงานให้เสร็จผ่านแบ็กแชนเนลแทนที่จะใช้กระบวนการทางการ คุณจะถูกองค์กรลงโทษ
- แม้สายการบังคับบัญชาจะเป็นฝ่ายอยากให้ทำแบบนั้นก็ตาม
- แม้ผู้เขียนจะได้รับเสียงสะท้อนเชิงลบมากมายว่าไม่ควรเลี่ยงกระบวนการทางการไม่ว่าในกรณีใด แต่เขา มองว่าความเห็นนี้ไร้เดียงสา
- ทุกองค์กรต่างมีทั้งด้านที่อ่านออกได้และด้านที่อ่านออกไม่ได้
- ด้านที่อ่านออกได้สำคัญเมื่อองค์กรเติบโตเกินระดับหนึ่ง เพราะทำให้วางแผนระยะยาวและประสานงานกับองค์กรขนาดใหญ่อื่นได้
- ด้านที่อ่านออกไม่ได้ก็สำคัญไม่แพ้กัน เพราะ เปิดทางให้งานประสิทธิภาพสูงเกิดขึ้น เป็นวาล์วนิรภัยให้กับกระบวนการที่ไม่สอดคล้องกับสถานการณ์ปัจจุบัน และตอบสนองความต้องการตามธรรมชาติของมนุษย์ต่อการซุบซิบและฉันทามติแบบนุ่มนวล
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมเห็นด้วยกับหลายส่วน แต่ขอคัดค้านตรงที่ภาวะผู้นำมักสมมติไปเองว่า "legibility" มีค่ามากพอจะคุ้มกับต้นทุนทุกอย่าง หาก CEO ต้องใส่ใจรายละเอียดงานทุกอย่างทั้งหมดจริง ๆ (เช่น การทำ unit test แบบขนาน) มันก็เหมือนสมองต้องรับรู้ทุกครั้งที่ขยับนิ้วหนึ่งนิ้ว จนสุดท้ายทำอะไรไม่ได้เลย ในความเป็นจริง CEO หรือหัวหน้าของบริษัทหนึ่งควบคุมภาพรวมได้แค่ราว 7% เท่านั้น ที่เหลือให้พนักงานแต่ละคนเติมเต็ม ตัวเองเป็นเพียงสมอง ไม่ใช่ทั้งร่างกายทั้งหมด แต่ผู้นำมักหลงคิดว่าตัวเองสำคัญที่สุด และเรื่องที่ไม่มีเวลาหรือไม่มีความเชี่ยวชาญพอ (เช่น ความต่างระหว่างวิศวกรเก่งมากจาก MIT กับวิศวกรระดับกลางจากบูตแคมป์) ก็มักถูกมองข้ามแบบลวก ๆ แม้แต่เวลาเล่าว่า Google ประสบความสำเร็จ ก็ยังมีแนวโน้มจะยกความดีความชอบให้ผู้ก่อตั้งสองคนหรือ CEO มากกว่าคนทำงานเก่ง ๆ อีกหลายสิบคน
บางส่วนของเนื้อหานี้ถูกต้อง แต่ก็ดูไม่ได้สุดโต่งเกินไปนัก ผมทำงานในบริษัทขนาดประมาณ 5,000 คน (ไม่เล็ก แต่ก็ไม่ถึงระดับ Amazon) กฎส่วนใหญ่มีเหตุผลที่ดีพอสมควร ตัวอย่างเช่น การต้องมี code reviewer 2 คนก็เพื่อกันความผิดพลาด ไม่ค่อยมีคนรีวิวไม่ผ่านหรอก แต่ถ้าปล่อยขึ้นระบบโดยไม่รีวิว ปัญหาขัดข้องก็น่าจะเกิดบ่อยขึ้น กฎแบบนี้ช่วยบังคับให้คนเช็กสิ่งต่าง ๆ อย่างน้อยก็พอประมาณ แน่นอนว่าสักวันหนึ่งอาจมีสถานการณ์ที่ต้องแหกกฎ (เช่น สมาชิกทีมส่วนใหญ่ต้องรีบไปจัดการ incident) ตอนนั้นการอนุญาตข้อยกเว้นตามเจตนารมณ์ของกฎก็ถือว่าสมเหตุสมผล แต่ถ้าเป็นที่ที่เต็มไปด้วยกฎราชการไร้ความหมายล้วน ๆ (เช่น มีใครบางคนยึดติดกับกระบวนการของตัวเองแล้วคอยพูดแต่ "วิธีของคุณผิด") คนก็ย่อมลาออก สภาพแวดล้อมที่ให้ความสำคัญกับกระบวนการหรืออีโก้ส่วนตัวมากกว่าความคืบหน้าและผลงานจริง แบบนั้นก็ถึงเวลาย้ายงาน
หลังจาก TDD ความคิดว่า "ถ้าทดสอบไม่ได้ ก็ยังถือว่ายังไม่ได้ implement" แรงขึ้นมาก คำว่า 'legibility' เหมาะกับการอธิบายเรื่องนี้จริง ๆ ใน Tritium เรามี unit test หลายร้อยตัว แต่พอถึงตอนสร้างบล็อกจริง ๆ ถึงได้พบ bug เชิงคุณภาพที่ unit test จับไม่ได้ (และยากจะตรวจด้วยการทดสอบ) ดู https://tritium.legal/blog/eat ผมคิดว่านี่อาจเป็นเหตุผลที่การพัฒนาเกมอินดี้ทนต่อแรงกดดันจากตรรกะตลาดได้ดี นักพัฒนาเกมได้ใช้ผลิตภัณฑ์ของตัวเองโดยตรง (Food-dogging) และพัฒนาเชิงคุณภาพได้ โดยไม่ต้องมีผิวหน้าของ legibility มากเกินไปแบบซอฟต์แวร์องค์กรขนาดใหญ่ ประเด็นสำคัญคือเราต้องมีทั้งตัวชี้วัดเชิงคุณภาพและเชิงปริมาณ
การทดสอบ โดยเฉพาะ unit test เสี่ยงต่อ "streetlight effect" มาก ส่วนที่เล็กน้อยหรือสำคัญน้อยมักทดสอบง่ายกว่า เลยจบลงที่ทดสอบแต่ของง่าย ๆ ถ้าองค์กรหมกมุ่นอยู่กับตัวชี้วัดที่วัดง่ายอย่าง line coverage สิ่งที่ตรวจยากแต่สำคัญจริง ๆ ก็เสี่ยงจะหลุดหายไป การประเมินเชิงคุณภาพอย่างการรีวิวโดยวิศวกรที่มีประสบการณ์ก็สำคัญเช่นกัน
การพัฒนาเกมมี feedback loop สั้นกว่าซอฟต์แวร์ด้านอื่นมาก ตัวอย่างเช่น ถ้าเกิด memory leak ปัญหาจะโผล่มาให้เห็นแทบจะทันทีเป็นร้อยครั้งต่อวินาที โค้ดที่ช้าก็สัมผัสได้ทันทีจากภาพกระตุก ทำให้ต้องใส่ใจเรื่องประสิทธิภาพอย่าง cache coherence หรือจะใช้ GC หรือไม่ด้วย
ผมชอบ TDD แต่สุดท้ายก็ยังต้องมีการทดสอบแบบ manual อยู่ดี ถ้าไม่ลองใช้เอง มักจะเจอปัญหาที่ไม่คาดคิดบ่อยมาก โดยเฉพาะเรื่องความเป็นมิตรต่อผู้ใช้ มันจะเห็นชัดเมื่อได้ใช้งานจริง
ผมชอบอ่านงานของ Sean และบทความนี้ก็โดนใจผมในหลายส่วนของงานด้านผลิตภัณฑ์ ตัวอย่างเช่น เมื่อประมาณหนึ่งปีก่อน คนดูแลผลิตภัณฑ์หลายคนกับวิศวกรหลายคนพยายามสร้างบางอย่างที่น่าจะช่วยทีมอื่นได้ด้วย การจะขออนุมัติผ่านช่องทางทางการ (legible channel) ตอนนั้นไม่ค่อยเป็นไปได้ตามโครงสร้างที่มีอยู่ เลยเดินหน้าผ่านช่องทางไม่เป็นทางการ (illeigible channel) บนพื้นฐานของความเชื่อใจและความเคารพ เป็นการขับเคลื่อนแบบ grassroots และกลับแพร่กระจายในบริษัทอย่างรวดเร็วจนได้ traction สุดท้ายตอนนี้ผู้บริหารเอากรณีนี้ไปใช้เป็นเหมือนเรื่องราวความสำเร็จของตัวเอง แต่พอเริ่มย้อนกลับมาทำขั้นตอนทางการทั้งหมด (legible channel) และหาหลักฐานรองรับย้อนหลัง กระบวนการก็เจ็บปวดพอสมควร อย่างไรก็ดี มันก็ง่ายขึ้นมากเพราะความเสี่ยงของความล้มเหลวลดลงไปมากแล้ว นี่เป็นหนึ่งในโปรเจกต์ที่คุ้มค่าและสนุกที่สุดที่ผมทำงานด้วยในช่วงหลายปีที่ผ่านมา
ยิ่งใช้ชีวิตในบริษัทนานขึ้น ยิ่งเจอการเมืองในออฟฟิศมากขึ้น ก็ยิ่งรู้สึกว่ามันคล้ายกับภูมิรัฐศาสตร์และการทูต พอไปไกลกว่านั้นก็เห็นความขนานกับความสัมพันธ์ทางสังคมและความสัมพันธ์เชิงรักใคร่ด้วย น่าจะเพราะผมมีนิสัยแบบนักคณิตศาสตร์ที่ชอบสร้างโมเดลนามธรรม
หัวข้อที่ผมชอบที่สุดก็คือการเมือง ผมอ่านหนังสือ นิตยสาร และข้อมูลสารพัดอย่างสนุก และพูดตรง ๆ ว่าการเมืองในออฟฟิศก็ไม่ได้ทำให้ผมลำบากใจมากนัก แก่นสำคัญคือมนุษย์ก็แค่ทำตัวแบบมนุษย์ ทุกคน (รวมถึงทุกองค์กร) มีสิ่งที่ต้องการและสิ่งที่กลัว และการหาสมดุลระหว่างสองอย่างนี้ก็เป็นความสนุกอย่างหนึ่ง มันเหมือนการแก้ปัญหาวิศวกรรม เพียงแต่ requirement คือ "คน" กระบวนการแก้ปัญหาแบบนี้น่าสนใจในตัวมันเอง
ผมเพิ่งมาคิดออกเรื่องนี้ไม่นาน เดิมทีผมมองการทูตว่าเป็นผลลัพธ์ของระบบซับซ้อนที่สร้างโดยนักการทูตหลายร้อยคน แต่จริง ๆ แล้วมันก็เป็นเพียงความสัมพันธ์ระหว่างมนุษย์ของผู้มีอำนาจไม่กี่คนที่พันกันอยู่เท่านั้น สามารถมองคล้ายกับสิ่งที่เกิดขึ้นในศูนย์เด็กเล็กได้เลย
นี่เป็นปรากฏการณ์ที่เป็นธรรมชาติตามสัญชาตญาณ จุดที่คล้ายกันระหว่างบริษัทยักษ์ใหญ่กับรัฐบาลชัดกว่าความสัมพันธ์ทางสังคม (รวมถึงความรัก) เสียอีก บริษัทมักใกล้เคียงกับความเป็นเผด็จการ (autocratic) หรือศักดินา (feudal) มากกว่า แม้จะมีความต่างอีกมาก แต่ยิ่งขนาดใหญ่ขึ้นก็ยิ่งมีแนวโน้มคล้ายรัฐบาลมากขึ้น หนึ่งในนั้นก็คือความเป็นระบบราชการขั้นสูง
วิกิเกมทฤษฎี
เมื่อเห็นว่านักการเมืองสมัยใหม่จำนวนไม่น้อยเริ่มต้นจากงานออฟฟิศทั่วไป ปรากฏการณ์นี้ก็ดูไม่น่าแปลกอะไร
ผมทำงานด้านความปลอดภัยไอที และที่นี่สถานการณ์แบบนี้ชัดยิ่งกว่าเดิม เวลาเราต้องรับคำขอที่ "ไม่ช่วยตัวชี้วัดโดยตรงของทีมเรา" ผมสงสัยว่ามีทางเลือกอื่นนอกจากวิธีไม่เป็นทางการแบบ back channel ไหม ใครมีประสบการณ์บ้าง
เป็นบทความที่ดี แต่ผมอยากพูดถึงอีกเรื่องที่มักไม่ค่อยถูกแตะต้อง ตัวบทความวาดภาพ software engineer (SWE) เหมือนเป็นเพียงใบไม้บนต้นไม้ หรือแรงงานในสายการประกอบเท่านั้น ซึ่งน่าเสียดาย แต่ดังที่ส่วน "Legible assumptions" บอกไว้ จริง ๆ แล้ววิศวกรยังทำหน้าที่แบบ "ผู้จัดการ" ที่ขยายการเชื่อมต่อในโครงสร้างองค์กรผ่าน "โค้ด" ด้วย ปัญหาที่เจอก็คล้ายกันมาก ต่างกันแค่สิ่งที่เอาไปใช้เท่านั้น
มีใครเห็นด้วยกับข้อความในบทความที่ว่า "ทำไมบริษัทเล็กถึงอยู่ได้โดยไม่มีความสามารถแบบนี้ แต่บริษัทซอฟต์แวร์ใหญ่กลับต้องมี? นี่ไม่ใช่ความเชี่ยวชาญของผม แต่เดาว่าอาจเป็นเพราะโปรเจกต์สำหรับองค์กรใหญ่" ไหม อยากฟังความเห็น
ผมคิดว่าไม่ใช่เพราะดีลกับองค์กรใหญ่เท่าไร แต่เป็นเพราะ "การสื่อสารเมื่อขยายขนาด (communication at scale)" ภายในมากกว่า เราอาจมององค์กรที่มีพนักงาน m คนเป็นเมทริกซ์การสื่อสาร m*m ได้ ตอนมีคนไม่มาก ช่องเกือบทุกช่องจะเป็น 1 (สื่อสารใกล้ชิด) แต่พอองค์กรใหญ่ขึ้น ส่วนใหญ่จะกลายเป็น 0 (ขาดการเชื่อมต่อ) หรือ 0.5 (สื่อสารแบบไม่เป็นทางการ) แทน แต่ข้อมูลก็คือตัวบริษัทเองในท้ายที่สุด ดังนั้นจึงต้องมีโครงสร้างที่ให้ผู้จัดการและกระบวนการทางการรับผิดชอบ "การไหล" ของข้อมูล การวางแผน การโปรโมต การทบทวน ทั้งหมดนี้ก็เพื่อให้เกิด legibility แบบนั้น
ผมทำโปรเจกต์ให้องค์กรใหญ่จากบริษัทเล็กอยู่บ่อย แต่ไม่จำเป็นต้องบังคับ legibility ภายในอย่างเข้มงวดถึงจะปิดดีลได้ ต่อหน้าลูกค้า เราต้องมี legibility ของการบริหารโปรเจกต์ แต่ไม่ได้หมายความว่าจะต้องเข้าไปกำกับวิธีพัฒนาภายในอย่างละเอียด สรุปคือที่บริษัทใหญ่หมกมุ่นกับ legibility เพราะพวกเขาเป็นองค์กรใหญ่ไปแล้ว หรือกำลังพยายามจะเป็นแบบนั้น
ผมอยู่ในวงการ medical imaging มานาน และเจ้าของธุรกิจส่วนใหญ่ไม่ได้เข้าใจจริง ๆ ว่าตัวเองอยู่ในอุตสาหกรรม IT service/solution ปัจจัยความสำเร็จที่แท้จริงคือความสามารถด้าน IT service มากกว่า ไม่ใช่ตัวงานวินิจฉัยเอง ส่วนที่ยิ่งใหญ่กว่ามากคือความพยายามของบุคลากรที่ไม่ใช่ผู้เชี่ยวชาญรังสีวิทยาในการทำให้แพลตฟอร์มใช้งานง่ายและมีประสิทธิภาพสูงขึ้น
ไม่ว่าองค์กรจะใหญ่แค่ไหน ก็ต้องเตรียมพร้อมรับการตรวจสอบทั้งภายในและภายนอก (audit) อยู่เสมอ ผู้ตรวจสอบมักอยากเห็นเอกสารกระบวนการให้มากที่สุด ตัวอย่างเช่นใน กรณีนี้ ในกรณีเลวร้ายที่สุด ผู้ตรวจสอบถึงขั้น "ไล่ลูกค้าออก" ได้เลย
ส่วนนั้น (ที่ว่าเพราะดีลกับองค์กรใหญ่) ก็ยังรู้สึกเฉพาะทางไปหน่อย สำหรับคนที่มาจากสตาร์ทอัพและตอนนี้เป็นผู้จัดการระดับกลางในบริษัทขนาดกลาง ผมมองว่ายิ่งองค์กรใหญ่ขึ้น ก็ยิ่งต้องมีโครงสร้างขั้นต่ำที่ช่วยบอกวิธีทำงานให้คน ต่อให้เกลียด process แค่ไหน พอเกิน Dunbar’s Number ไปแล้ว ก็มีขีดจำกัดของความเข้าอกเข้าใจและการสื่อสารไม่เป็นทางการอยู่ดี กรณียกเว้นสุดโต่งคงเป็น Steam แต่ที่นั่นก็รับเฉพาะคนบางประเภทและมีการเมืองภายในหนักมาก
แค่การเลือกใช้คำว่า legibility ก็น่าสนใจแล้ว มันให้ความรู้สึกเหมือนการแบ่งขั้วระหว่างกระบวนการทางการกับไม่เป็นทางการ ตอนบริษัทเล็ก วิธีไม่เป็นทางการใช้ได้ดี แต่พอเกินจุดวิกฤตหนึ่งไป ก็หลีกเลี่ยงไม่ได้ที่จะต้องมีกฎและกระบวนการทางการ ในระยะยาว กฎก็มักแข็งตัวและตามการเปลี่ยนแปลงไม่ทัน คนจะค่อย ๆ หมกมุ่นกับกระบวนการมากกว่าเป้าหมาย การหลุดออกจากกิจวัตรแบบนี้เพื่อรักษาความใหม่จึงไม่ง่าย ในบริษัทเรามักพูดว่าเงินเหมือนเลือด แต่จริง ๆ แล้วเงินไม่ค่อยใช่รากฐานของแรงจูงใจนัก มันเป็นเงื่อนไขจำเป็นก็จริง แต่ไม่ใช่เหตุผลของการมีอยู่ในตัวมันเอง
สุดท้ายแล้วมันเป็นเรื่องของสมดุลเสมอ ผมเป็น engineering manager มา 25 ปี และทำงานในบริษัทที่ขับเคลื่อนด้วย process อย่างเข้มข้น มันน่าอึดอัด แต่ก็มีข้อดีตรงที่ช่วยให้สร้างฮาร์ดแวร์ระดับโลกได้อย่างสม่ำเสมอ (ไม่ใช่ซอฟต์แวร์) การทำเอกสารและเรื่องทำนองนี้จำเป็นแน่ แต่ถ้าเข้มงวดเกินไปก็เสี่ยงทำให้โปรเจกต์แข็งทื่อ ปัญหาที่ร้ายแรงที่สุดคือ communication overhead นั่นแหละ เพราะอย่างนี้เอง ทีมเล็กที่เก่งและทำงานร่วมกันมานานจึงสร้างผลิตภาพมหาศาลได้ และ "tribal knowledge" ก็เป็นตัวเร่งสำคัญมากจริง ๆ ที่ผมเขียนบทความ Concrete Galoshes ก็เพราะอยากพูดถึงองค์ประกอบเชิงโครงสร้างและความแข็งตัวแบบนี้ บทเรียนสำคัญที่สุดคือ "อย่าเอาชุดแบบเดียวไปใส่ให้ทุกโปรเจกต์" แต่ละโปรเจกต์ต้องการโครงสร้างและ overhead ที่ต่างกัน