บริษัทใหญ่โครงสร้างมันทำให้เกิด win ที่มีขอบเขตชัด ระบุได้ว่าเป็นของใคร และมองเห็นเป็นชิ้นเป็นอันได้ยาก เงินเดือนส่วนหนึ่งคือค่าที่ต้องอยู่ให้ได้โดยไม่มีสิ่งนั้น
จากฝั่งproductที่ต้องคุมว่าอะไรปิดจบ กรอบนี้ใช้ได้จริงกว่าที่คิด แต่สามข้อที่ว่ามาไม่ได้พังเองตามธรรมชาติเสมอ มันพังเพราะการตัดสินใจ ขอบเขตชัด มักหายไปเพราะไม่มีใครกล้าตัดscopeให้เล็กพอจะจบในควอเตอร์เดียว ความเป็นเจ้าของถูกเฉลี่ย เพราะแปะชื่อคนสิบแปดคนปลอ
จากฝั่งproductที่ต้องคุมว่าอะไรปิดจบ กรอบนี้ใช้ได้จริงกว่าที่คิด แต่สามข้อที่ว่ามาไม่ได้พังเองตามธรรมชาติเสมอ มันพังเพราะการตัดสินใจ
ขอบเขตชัด มักหายไปเพราะไม่มีใครกล้าตัดscopeให้เล็กพอจะจบในควอเตอร์เดียว
ความเป็นเจ้าของถูกเฉลี่ย เพราะแปะชื่อคนสิบแปดคนปลอดภัยกว่าให้คนเดียวรับผิดชอบแล้วพลาด
feedback loopช้า เพราะdashboardมันโชว์ให้ผู้บริหารสบายใจ ไม่ได้ทำมาให้คนทำงานเห็นว่าตัวเองขยับอะไร
สเกลเป็นข้ออ้างได้ครึ่งเดียว อีกครึ่งคือปัญหาความกล้าในการตัดงาน
ผมเห็นเรื่องนี้เกิดซ้ำมาพอจนตอนนี้รูปแบบมันชัดแล้ว ทำงานมาได้สองสามปี เงินเดือนดี สวัสดิการดี impact ระดับ FAANG (maango อะไรก็ว่าไป) ทำงานได้ดี ได้ขึ้นเงินเดือนเรื่อยๆ แต่มันมีอะไรไม่เข้าที่ ยังไม่ถึงขั้น burn out หรอก แต่พอจะชี้ไปที่อะไรสักอย่างแล้วบอกว่า "อันนี้เกิดเพราะผม" กลับไม่มีอะไรให้ชี้ได้เลย เวลาเจอครอบครัวเจอเพื่อนแล้วเขาถามว่าทำงานอะไร ก็ตอบได้แบบคลุมเครือ อธิบายให้ชัดไม่ได้จริงๆ โปรเจกต์นึงมี stakeholder สิบแปดคน การตัดสินใจผ่าน approval สี่ชั้น วนไปวนมา แล้วใครกันแน่ที่เป็นคนชี้ขาดก็ไม่มีใครรู้ ผลลัพธ์ไปนั่งอยู่บน dashboard ที่อ่านได้แต่แทบไม่มีทางไปขยับมันจริงๆ สิ่งที่เราทำลงไปคงมีค่าจริง แต่มันสำคัญแค่ไหน หรือสำคัญจริงไหม ตอบไม่ได้เลยจริงๆ
ความรู้สึกแบบนี้ไม่ใช่ปัญหาที่นิสัยใครหรอก บริษัทใหญ่ทำให้ทุกคนรู้สึกเหมือนกันหมด ไม่ได้เป็นที่เราคนเดียว สิ่งที่ขาดไป อย่างน้อยผมขอเรียกมันแบบนี้ คือ win density การได้ความสำเร็จที่ระบุว่าเป็นของเราอย่างสม่ำเสมอ win คือ 1) มีขอบเขตชัด ระบุได้ว่าเป็นของใคร และมองเห็นเป็นชิ้นเป็นอัน 2) มันจบ และเราได้ทำอะไรสำเร็จไปจริงๆ 3) สาวกลับไปได้ว่ามาจากสิ่งที่เราทำ ชี้ไปที่ร่องรอยที่มันทิ้งไว้ได้ บริษัทใหญ่กดทั้งสามข้อนี้พร้อมกัน งานยืดข้ามไปหลายไตรมาส ความเป็นเจ้าของถูกเฉลี่ยให้คนมากพอจนไม่มีใครเห็นเค้าโครงตัวเองในนั้น feedback loop มาช้า ถูกกรองผ่าน dashboard ผ่านลำดับชั้น ผ่านรอบ review มันคือวิธีที่องค์กรใหญ่ประสานงานกันในสเกลใหญ่
ดีลของ startup มันกลับด้านกัน เงินเดือนน้อยลง win density สูงขึ้น ได้ทำอะไรเสร็จทุกวัน แล้วมันเสพติด ปัญหาคือ startup มักจะเจ๊ง สุดท้ายก็ burn out แล้วเงินเก็บก็แทบไม่มี
สิ่งที่ win density ต่ำๆทำกับคนไม่ได้ดราม่าอะไร มันไม่ได้ทำให้ลุกออกจากห้องไป ส่วนใหญ่ก็แค่ชินไปเอง แต่มันทำให้อยากทำอะไรให้เสร็จสักอย่าง อะไรใหม่ๆ engineer เริ่ม overengineer เพราะ milestone ที่ปั้นขึ้นมาเองยังดีกว่าไม่มี milestone เลย ถ้างานไม่ยอมให้เส้นชัยชัดๆ ก็ปั้นมันขึ้นมาเอง refactor อีกรอบ เขียน re-architecture doc อีกฉบับให้ service ที่มันก็ทำงานได้ดีอยู่แล้ว โปรเจกต์ cleanup ที่มีอยู่เพราะมันทำให้จบได้เป็นหลัก หาวิธีใหม่ๆมาทำ testing... บางคนก็แค่ซีดลงแล้วตายข้างใน ทำตามที่สั่งเป๊ะๆ ยังมาทำงาน ยังดูปกติดีในห้อง status meeting แต่เงินเดือนส่วนหนึ่งเริ่มรู้สึกเหมือนเป็นค่าที่ต้องยอมไม่ได้เห็นงานตัวเองลงจอด
อันนี้ส่วนใหญ่เป็นเรื่องบ่นของคนทำงานออฟฟิศ คนอีกเยอะที่ทั้งเงินน้อย และ win density ก็ต่ำ บทความนี้พูดถึงดีลในเวอร์ชันของคนทำงานออฟฟิศ ใช่ เงินเดือนเราดี คุณภาพชีวิตก็ดี แต่เราก็ใช้เวลาวันละ 8 ชั่วโมงกว่าๆไปกับงาน บ่อยครั้งมากกว่านั้นด้วยซ้ำ แล้วเราต้องทำให้มันเข้ากันได้กับวิธีที่แรงขับและสมองเราทำงาน ใช่ งานมันสบาย และบ่อยครั้งเราก็ได้เงินดี และใช่ จะทำให้งานออฟฟิศน่าอยู่และสนุกสุดๆก็ทำได้ ประเด็นที่ผมจะบอกคือ ต้องมี win density ถึงจะได้แบบนั้น ต้องมีความสำเร็จที่เป็นของเราเองอย่างสม่ำเสมอ ถึงจะรู้สึกเหมือนได้ชนะ
และนั่นก็คือเหตุผลที่ปัญหานี้สำคัญกับ manager ด้วย แม้จะแก้ปัญหาเรื่องสเกลที่เป็นต้นตอให้หมดจดไม่ได้ก็ตาม งานบางอย่างมันช้าโดยธรรมชาติ ไม่ใช่ทุกอย่างจะ ship ได้ในลูปหนึ่งสัปดาห์ แต่ทีมจะไปได้ดีกว่าเมื่องานมันปิดจบ การระบุว่าเป็นของใครเป็นเรื่องจริง และคนยังเห็นได้ว่าอะไรขยับเพราะตัวเอง ยังรู้สึกได้ว่าเป็นเจ้าของมันตั้งแต่ต้นจนจบ และทำมันสำเร็จ ความถี่ในการ ship ที่สูงขึ้นมักสัมพันธ์กับ performance ขององค์กรที่ดีขึ้นและ engagement ที่แข็งแรงขึ้น ประเด็นในทางปฏิบัติมันง่ายกว่าข้อถกเถียงเชิงวิจัย ถ้าไม่มีใครบอกได้ว่าอะไรเสร็จไปแล้ว ใครเป็นเจ้าของ หรืออะไรเปลี่ยนไป ความทะเยอทะยานก็เริ่มบูดกลายเป็นแค่งานประคองระบบ
ไม่ต้องจ่ายเงินคนเพิ่มเพื่อให้เขามีความสุขขึ้นก็ได้ (เฮ้ย กูเพิ่งพูดอะไรลงไป???) บ่อยครั้งแค่ต้อง "gamify" งานให้เขา ป้อน dopamine ให้ engineer บ่อยๆถี่ๆ บางคนจะรับดีลนี้แบบตั้งใจเองด้วยซ้ำ ผมเองก็เคยรับมันแบบตั้งใจมาแล้ว แต่ถ้าให้ดี จ่ายเงินเขาด้วยนะ
งานวิจัยชุด State of DevOps ของ DORA พบสม่ำเสมอว่าความถี่ในการ deploy ที่สูงขึ้นสัมพันธ์กับ performance ขององค์กรที่แข็งแรงขึ้น และมักสัมพันธ์กับ engagement ที่สูงขึ้น แม้ทิศทางของเหตุและผลจะยังเป็นที่ถกเถียงกันอยู่
เวอร์ชันที่แข็งที่สุดของโพสต์นี้คือประโยคที่ว่าเงินเดือนส่วนหนึ่งคือค่าที่ต้องอยู่ให้ได้โดยไม่เห็นงานตัวเองลงจอด อันนี้จริงและไม่ค่อยมีคนพูดตรงๆ แต่win densityมันกระจายไม่เท่ากันในทีม งานfrontendกับaccessibilityนี่คือจุดที่ความคลุมเครือของproductกลายเป็นสิ่งที่คนคลิกจริงๆ เราเห็นผลทันทีกว่าใคร ปัญหาคือพอถึงรอบreview สิ่งที่นับเป็นwin กลับเป็นfeatureที่ผู้บริหารชี้ได้บนสไลด์ ไม่ใช่edge caseที่เราอุดไปเงียบๆสามสิบเคส
มองจากมุมการเงินแล้วดีลนี้คุ้มกว่าที่โพสต์ทำให้รู้สึก เงินเดือนสูงที่ความสำเร็จต่ำ แปลงเป็นsavings rateสูงได้ ถ้าคุมรายจ่ายอยู่ งานที่win densityสูงแต่เงินน้อยอย่างstartup ส่วนใหญ่จบที่burn outแล้วเงินเก็บแทบไม่มี แบบที่โพสต์เขียนเอง ความรู้สึกว่าได้ชนะทุกวันมันไม่ได้จ่ายค่าอิสรภาพตอนห้าสิบ อัตราการออมต่างหากที่จ่าย ความเบื่อในงานที่มั่นคงคือต้นทุนที่ถูกที่สุดในบรรดาทางเลือกทั้งหมด
จากฝั่งproductที่ต้องคุมว่าอะไรปิดจบ กรอบนี้ใช้ได้จริงกว่าที่คิด แต่สามข้อที่ว่ามาไม่ได้พังเองตามธรรมชาติเสมอ มันพังเพราะการตัดสินใจ
ขอบเขตชัด มักหายไปเพราะไม่มีใครกล้าตัดscopeให้เล็กพอจะจบในควอเตอร์เดียว
ความเป็นเจ้าของถูกเฉลี่ย เพราะแปะชื่อคนสิบแปดคนปลอดภัยกว่าให้คนเดียวรับผิดชอบแล้วพลาด
feedback loopช้า เพราะdashboardมันโชว์ให้ผู้บริหารสบายใจ ไม่ได้ทำมาให้คนทำงานเห็นว่าตัวเองขยับอะไร
สเกลเป็นข้ออ้างได้ครึ่งเดียว อีกครึ่งคือปัญหาความกล้าในการตัดงาน
เห็นด้วยกับอาการนะ แต่คำว่าwin densityมันเอียงไปทางคนที่งานมองเห็นได้อยู่แล้ว งานสายreleaseกับinfraนี่win densityต่ำตลอดกาลโดยธรรมชาติ คุณกันความพังได้สำเร็จสิบครั้งก็ไม่มีใครเห็น แต่พังหนเดียวทั้งบริษัทรู้ สิ่งที่ขาดไม่ใช่ความสำเร็จที่ชี้ได้ มันคือเครดิตของงานที่ไม่มีร่องรอยให้ชี้ ปัญหาคนละชั้นกัน
ที่เขียนว่าtech debtครึ่งหนึ่งเป็นการปั้นมิลสโตนเองเพราะงานจริงมันไม่ยอมจบนี่ตรงเกินไปจนแสบ ทีมกูช่วงปีก่อนมีคนเสนอre-architecture docให้serviceที่ทำงานนิ่งมาสองปี เหตุผลที่ขายกันในห้องคือscalability แต่เหตุผลจริงคือมันเป็นงานชิ้นเดียวในควอเตอร์นั้นที่มีจุดเริ่มกับจุดจบชัดๆ ปัญหาคือwin ที่ปั้นเองพวกนี้มันมีต้นทุนจริงตอนตีสอง คนที่ไม่ได้เลือกให้rewrite ต้องมารับon-callดูแลblast radiusที่โตขึ้นเพราะใครคนนึงอยากรู้สึกว่างานเสร็จ
บริษัทจ่ายเงินคนเพื่อกันไม่ให้ออกไปทำอะไรสำเร็จที่อื่น คือประโยคที่อ่านแล้วอยากquote tweetพร้อมคำว่าโดนจับได้