- จากผลสำรวจบริษัทบิ๊กเทคมากกว่า 100 แห่ง
- หากสรุปแนวทางการบริหารโปรเจ็กต์ของบิ๊กเทค ก็คือ ⇨ "ขึ้นอยู่กับสถานการณ์ (It Depends)"
- ส่วนใหญ่ไม่มีวิธีการหรือรูปแบบการทำงานที่ตายตัว และทีมจะเลือกสิ่งที่เหมาะกับตัวเอง
- บริษัทจดทะเบียนหรือบริษัทที่ได้รับเงินลงทุนมีความพึงพอใจต่ำต่อการมี PM ประจำ แต่กรณีที่ไม่ได้รับเงินลงทุนกลับมีความพึงพอใจสูง
- ความเป็นอิสระของทีมกับความพึงพอใจมีความสัมพันธ์กันสูง
- แม้แต่ทีมที่มีปัญหา สาเหตุก็มักไม่ใช่เรื่องวิธีการ แต่เป็นเพราะไม่สามารถสื่อวิสัยทัศน์ได้ชัดเจน หรือขาดความโปร่งใสและเครื่องมือที่เหมาะสม
- JIRA ได้รับคำตอบเชิงลบเป็นส่วนใหญ่
- วิธีบริหารโปรเจ็กต์ที่ไปได้ไม่ดี
- วิศวกรไม่ได้มีส่วนร่วมในการประเมินระยะเวลาโปรเจ็กต์
- แม้จะมี PM ประจำ แต่ข้อกำหนดก็ยังเปลี่ยนแปลง
- ทีมที่ไม่มีอิสระในการเปลี่ยนวิธีบริหารโปรเจ็กต์ที่ล้มเหลว มีคะแนนความพึงพอใจต่ำ
- วิธีที่บิ๊กเทคดำเนินโปรเจ็กต์
- วิศวกรเป็นผู้นำโปรเจ็กต์ส่วนใหญ่
- ไม่มีวิธีการตายตัว และทีมสามารถเลือกได้อย่างอิสระ
- โปรเจ็กต์ระดับทีมไม่มี Project Manager ประจำ ส่วนโปรเจ็กต์ขนาดใหญ่ที่มีหลายทีมหรือทั้งบริษัทเข้าร่วมจะมี Technical Program Manager โดยกรณีของ Uber มีสัดส่วนประมาณ 1:50
- มีเครื่องมือสำหรับนักพัฒนาระดับ first-class และสิ่งนี้ส่งผลอย่างมากต่อรอบการทำงานแบบ iteration ที่สั้น
โครงสร้างองค์กรของบิ๊กเทคที่ส่งผลต่อโปรเจ็กต์
- สภาพแวดล้อมพื้นฐาน
- วิศวกรและทีมมีความเป็นอิสระ
- ไม่ใช่ทรัพยากรที่ไร้สำนึก (แรงงานโรงงาน) แต่เป็นนักแก้ปัญหาที่มีความอยากรู้อยากเห็น
- ข้อมูล โค้ด และเอกสารภายในเปิดเผยอย่างโปร่งใส
- วิศวกรได้สัมผัสกับธุรกิจและตัวชี้วัดทางธุรกิจด้วย
- สื่อสารกันแบบวิศวกรถึงวิศวกรอย่างรวดเร็ว แทนการสื่อสารแบบลำดับชั้น
- ลงทุนกับประสบการณ์นักพัฒนาที่น่าหงุดหงิดน้อยลง
- ค่าตอบแทนที่สูงขึ้นซึ่งอธิบายได้ด้วย leverage ที่สูงกว่า
- สามารถจ้างบุคลากรที่เก่งกว่าได้
- ทีมที่ได้รับอำนาจและมีความเป็นอิสระ
- ทีมที่มี ownership ชัดเจน
Product Manager คือ Yes, Project Manager คือ No
- บทบาทของ Product Manager คือการทำความเข้าใจว่า "What game we're playing" และ "How we're going to play it"
- ในหลายกรณี Product Manager ของบริษัทบิ๊กเทคไม่ได้ทำ Project Management
- ทีมเป็นผู้รับผิดชอบการลงมือทำ และโดยมากผู้จัดการสายเทคนิค (หัวหน้าทีม) จะรับผิดชอบการบริหารโปรเจ็กต์
- ในทีมที่ได้รับอำนาจและมีความเป็นอิสระ การบริหารโปรเจ็กต์แบบสั่งการจากบนลงล่างเกิดขึ้นได้ยาก ⇨ ทุกคนทำร่วมกัน
- คำถามที่เกิดขึ้นเมื่อไม่มี Project Manager ประจำ
- โปรเจ็กต์ระดับทีม : ทำให้กระบวนการเรียบง่าย และเสริมความสัมพันธ์ระหว่างบุคคล
- โปรเจ็กต์ที่ซับซ้อน : บิ๊กเทคจะมี Technical Program Manager (TPM)
- มี Program Manager / Project Manager ประจำอยู่จริง โดยทั่วไปจะเชื่อมกับภายนอก ลูกค้า และแผนการดำเนินงานระยะยาว
- สภาพแวดล้อมที่ยึดผลิตภัณฑ์เป็นศูนย์กลางและเหตุผลที่ไม่ทำ Scrum
- Scrum ที่ทำงานเป็นรอบ sprint ไม่ค่อยเหมาะกับสถานการณ์ที่ต้อง deploy อย่างรวดเร็ว
- โครงสร้างพื้นฐานและเครื่องมือสำหรับนักพัฒนาช่วยทดแทนกิจกรรมหลายอย่างของ Scrum
- บริษัทบิ๊กเทครู้แล้วว่าการลงทุนในโครงสร้างพื้นฐานและเครื่องมือสำหรับนักพัฒนานำไปสู่การเพิ่มผลิตภาพ
- Facebook, Google, Netflix ฯลฯ ไม่ใช้ Scrum ทำไม?
- คนที่มีความสามารถและมีความเป็นอิสระต้องการโครงสร้างแบบนี้น้อยกว่า
- หากให้ทีมที่มีความสามารถมีอิสระในการเลือกวิธีดำเนินงาน ก็จะดึง leverage จากพวกเขาได้
- การขยายองค์กรวิศวกรรมเป็นเรื่องที่ไกลเกินกว่ากระบวนการระดับทีมมาก
- แต่การที่ทุกคนจะเลียนแบบบิ๊กเทคแล้วไม่ทำ Scrum ทั้งหมดก็เป็นความผิดพลาด
→ มีสถานการณ์ที่การใช้ Scrum เหมาะสม และอาจให้ผลิตภาพที่สูงกว่าได้
- ทีม kitchen sink : เมื่อทีมเดียวต้องแก้ทุกอย่างทั้งหมด (สตาร์ทอัพระยะเริ่มต้น)
- ในช่วงที่กำลังก่อตั้งทีมใหม่
- ในกรณีที่ deploy กันทุกๆ หลายสัปดาห์
- ในกรณีที่จำเป็นต้องมีรายงานความคืบหน้าโปรเจ็กต์ในรูปแบบที่เป็นมาตรฐานเดียวกัน
ควรบริหารทีมอย่างไร?
- การเปลี่ยนแปลงแบบค่อยเป็นค่อยไปดีกว่าการเปลี่ยนแบบ 'big bang' เสมอ
- การสอนวิธีจับปลา ยากกว่าการจับปลาให้
- การสั่งการ (Directing), การเป็นพี่เลี้ยง และการโค้ช ต่างก็มีบทบาทของตัวเอง
- การสั่งการคือการช่วยแบบ micro-managing ในเชิงเสริมเท่านั้น เมื่อพวกเขาทำเองได้แต่ยังทำไม่ได้
- ยิ่งมีคนที่ต้องใช้ในการตัดสินใจน้อย ก็ยิ่งตัดสินใจได้เร็ว
- การ optimize เพื่อการรายงาน คือการ optimize เพื่อสภาพแวดล้อมที่มีความไว้วางใจต่ำกว่า
- ที่ปรึกษามักเอนเอียงไปทางการส่งมอบผลลัพธ์ที่วัดได้ง่าย เพราะนั่นเป็นวิธีที่ง่ายที่สุดในการพิสูจน์คุณค่าของตนเอง
- การเรียนรู้จากคู่แข่งโดยตรงเป็นสิ่งที่ถูกประเมินค่าต่ำเกินไป
- วิศวกรระดับท็อปบางคนยอมลาออกดีกว่าถูก micro-manage
8 ความคิดเห็น
"JIRA ได้รับคำตอบในเชิงลบเป็นส่วนใหญ่"
ผมคิดว่าไม่ว่าจะใช้รูปแบบไหน การจัดการ issue ก็เป็นสิ่งจำเป็น และตัวผมเองก็เคยมอง JIRA ในแง่ลบเหมือนกัน เลยตั้งใจลองใช้เครื่องมืออื่นมาบ้าง (github issues, trello, asana เป็นต้น)
แต่สุดท้ายก็ต้องยอมรับว่าของเก่ายังดีที่สุด เลยกลับมาใช้ JIRA อีกครั้ง...
อย่างไรก็ตาม ผมก็ยังคิดอยู่เสมอว่าอาจจะมีวิธีที่ดีกว่านี้หรือไม่
คุณคิดว่าในแง่ไหนที่ว่า "ของเก่ายังดีกว่า" ครับ?
ฉันชอบ YouTrack มาก เป็นเครื่องมือ PM ที่ Jetbrains สร้างขึ้น และมันก็จัดการโปรเจกต์ได้เท่าที่ฉันต้องการเลย
ทีมของเราเปลี่ยนมาใช้ Linear แล้ว และโดยรวมความพึงพอใจก็เพิ่มขึ้นมากครับ/ค่ะ แนะนำให้ลองพิจารณาดูสักครั้งนะครับ/คะ
น่าจะเป็นผลิตภัณฑ์นี้นะครับ https://linear.app/. ดูน่าสนใจดี
ข้อดีที่ผมรู้สึกมีดังนี้
ประมาณนี้คือสิ่งที่ผมรู้สึกครับ
บริษัทเทคโนโลยีขนาดใหญ่ดำเนินโปรเจกต์กันอย่างไร
เครื่องมือสำหรับนักพัฒนาระดับเฟิร์สต์คลาสทำอะไรกันแน่?
เพื่อคงอารมณ์ของต้นฉบับไว้เลยจึงนำมาแบบนี้ครับ
ณ ตอนนี้ก็น่าจะถือได้ว่าเป็นเครื่องมือสำหรับนักพัฒนาที่ดีที่สุดเท่าที่องค์กรจะสามารถจัดหาให้ได้