Team Ramp Up รับประกันความเร็วของฟีเจอร์ที่เพิ่มขึ้นหรือไม่?
เผยแพร่แล้ว: 2020-03-28สิ่งสำคัญอย่างหนึ่งในขณะที่เพิ่มทีมเพื่อเพิ่มความเร็วในการปล่อยคือการถ่ายโอนความชัดเจนจากทีมผลิตภัณฑ์ไปยังทีมวิ่ง
การดำเนินการ sprint ที่ราบรื่นเป็นผลจากผลงานเด่นที่มาจากทั้งผลิตภัณฑ์และทีม sprint
ปรัชญาของ 'สิทธิครั้งแรก (FTR)' ช่วยให้สมาชิกในทีมทุกคนบรรลุเป้าหมายร่วมกัน
เมื่อสตาร์ทอัพเปลี่ยนจากจุดเริ่มต้นไปสู่ระยะการเติบโต ลำดับความสำคัญจะเปลี่ยนไปตามระดับที่มีนัยสำคัญ เหนือสิ่งอื่นใด ความเร็วของคุณลักษณะโดดเด่นเป็นลำดับความสำคัญและมีบทบาทสำคัญในการแสวงหาการเติบโต
ผู้ก่อตั้งสตาร์ทอัพที่ได้รับทุนสนับสนุนจากเมล็ดพันธุ์ที่ฉันทำงานด้วย ซึ่งเพิ่งยกซีรีส์ A ขึ้นมา ขอให้ฉันเพิ่มทีมวิศวกรเป็นสองเท่าเพื่อเปิดตัวฟังก์ชันใหม่ๆ ในหกเดือน อย่างไรก็ตาม นั่นเป็นเพียงปัจจัยที่เกี่ยวข้องในการลดรอบเวลาใช่หรือไม่ ในการตอบ ฉันตัดสินใจที่จะพูดถึงแง่มุมที่ถูกละเลยซึ่งอยู่เบื้องหลัง 'ความเข้าใจผิด' ที่แพร่หลายนี้
แม้ว่าความจุของทรัพยากรจะเป็นปัจจัยสำคัญประการหนึ่งที่ผลักดันให้เกิดการออกผลิตภัณฑ์บ่อยครั้งในการผลิต แต่สิ่งนี้ไม่สามารถรับประกันรอบเวลาการทำงานที่ลดลงได้ ขณะสร้างผลิตภัณฑ์สำหรับสตาร์ทอัพมากกว่า 16 ราย ฉันได้เห็นการเปลี่ยนแปลงจากช่วงเริ่มต้นเป็นช่วงเติบโตหลายครั้ง จากประสบการณ์นี้ ต่อไปนี้คือปัจจัยสำคัญบางประการที่ฉันแบ่งปันให้ผู้ก่อตั้งสตาร์ทอัพต้องพิจารณา
ส่งต่อความชัดเจน: สิ่งสำคัญจากบนลงล่าง
สิ่งสำคัญอย่างหนึ่งในขณะที่เพิ่มทีมเพื่อเพิ่มความเร็วในการปล่อยคือการถ่ายโอนความชัดเจนจากทีมผลิตภัณฑ์ไปยังทีมวิ่ง เมื่อการวิ่งเริ่มต้นด้วยความคลุมเครือหรือมีเรื่องราวไม่เพียงพอที่จะเริ่มต้น อัตราส่วนการส่งของการวิ่งจะได้รับผลกระทบในทางลบ เรื่องราวที่กำหนดไว้อย่างคลุมเครือหรือการรวมงานระหว่างการวิ่งช้าลง ส่งผลให้ทีม sprint ล้มเหลวในการดำเนินการตามแผนที่วางไว้
การดำเนินการ sprint ที่ราบรื่นเป็นผลจากผลงานเด่นที่มาจากทั้งผลิตภัณฑ์และทีม sprint ทีมผลิตภัณฑ์สามารถมีส่วนร่วมโดยการเตรียมและแบ่งปันแผนงานกับทีมวิ่งอย่างน้อยในไตรมาสเพื่อให้ทีมสามารถวางแผนการส่งมอบได้อย่างเหมาะสม
ในทางกลับกัน ทีม sprint ควรผลักดันทีมผลิตภัณฑ์ต่อไปเพื่อให้ได้งานในมือและดูแลเป็นรายสัปดาห์/รายปักษ์เพื่อให้แน่ใจว่ามีการส่งมอบที่ตรงจุด
อัตโนมัติเพื่อปล่อย 'ปราศจากข้อบกพร่อง'
“ประสิทธิภาพคือการทำสิ่งที่ถูกต้อง ประสิทธิภาพคือการทำสิ่งที่ถูกต้อง” – ปีเตอร์ ดรักเกอร์
เมื่อคุณนึกถึงระบบอัตโนมัติ นี่คือตัวอย่างของหมวดหมู่หลัง ในขณะที่การพัฒนาคุณลักษณะเพิ่มขึ้นอย่างรวดเร็ว มีความเป็นไปได้สูงที่การผลิตจะหยุดชะงักลงเว้นแต่จะมีกระบวนการที่เหมาะสม หากผลิตภัณฑ์ไม่เสถียรพอที่จะรองรับการพัฒนาคุณสมบัติใหม่ ทีมของคุณจะใช้เวลาแก้ไขปัญหามากกว่าการสร้างคุณสมบัติใหม่ ดังนั้นความเร็วทางวิศวกรรมของคุณจึงลดลง
นี่คือที่มาของ CI/CD (การรวมอย่างต่อเนื่องและการปรับใช้อย่างต่อเนื่อง) ในที่นี้ ความครอบคลุมของการทดสอบหน่วย การรวมระบบ และระบบอัตโนมัติอย่างละเอียดถี่ถ้วนทำให้มั่นใจได้ว่าสิ่งที่จัดส่งจะไม่ทำให้ระบบเสียหาย
แนะนำสำหรับคุณ:
อย่าเพียงแค่สร้างเพิ่มเติม มิฉะนั้นคุณจะทำลายเพิ่มเติม
การทำใหม่เป็นตัวทำลายประสิทธิภาพการทำงานครั้งใหญ่ และอาจเป็นผลมาจากปัจจัยต่างๆ เช่น เรื่องราวที่ไม่ชัดเจน ขาดการทดสอบสำหรับนักพัฒนา การขาดความครอบคลุมในการทดสอบ และอื่นๆ การทำงานซ้ำอาจทำให้ประสิทธิภาพการทำงานลดลง เนื่องจากจะต้องใช้เวลาและความพยายามของวิศวกร QA ในการทดสอบและการถดถอย นักพัฒนาในการดีบัก และปล่อยผู้จัดการในการรีลีสใหม่
การช้าลงเล็กน้อยสามารถช่วยให้ทีมของคุณส่งมอบได้เร็วขึ้นและเพิ่มมูลค่า เนื่องจากความเร็วที่มีประสิทธิภาพมักจะให้รางวัลมากกว่าความเร็วเสมอ
ปรัชญาของ 'สิทธิในครั้งแรก (FTR)' ช่วยให้สมาชิกในทีมทุกคนสามารถปรับตัวให้เข้ากับเป้าหมายร่วมกัน ซึ่งก็คือการส่งมอบโค้ดที่มีประสิทธิภาพและเสถียรในครั้งแรก การใช้เวลาเพิ่มเติมเพื่อกำหนดคุณภาพของโค้ดนั้นเป็นเรื่องที่ดีต่อสุขภาพเสมอ แทนที่จะรีบร้อนแล้วไปยุ่งกับการทำงานใหม่
วิธีปรับปรุงอัตราส่วน FTR ที่ผ่านการทดลองและทดสอบแล้วบางส่วน ได้แก่ การดูแลงานในมือที่ค้างอยู่ การเล่าเรื่องราวซ้ำ การสาธิตตามปกติสำหรับผู้จัดการผลิตภัณฑ์ แทนที่จะรวบรวมข้อกำหนด ทีมวิ่งควรให้ความสำคัญกับการอธิบายให้ชัดเจนมากขึ้นเพื่อปรับปรุงอัตราส่วน FTR
จัดโครงสร้างทีมของคุณสำหรับการวิ่งแบบขนาน
เมื่อการเริ่มต้นของคุณมีทีมผลิตภัณฑ์ขนาดเล็ก ทุกคนส่วนใหญ่จะทำงานกับคุณลักษณะหนึ่งหรือสองคุณลักษณะพร้อมกัน (โดยทั่วไปใช้ได้กับทีมที่มีสมาชิก 4-6 คน) อย่างไรก็ตาม ในขณะที่ความคาดหวังเพิ่มขึ้นในการนำเสนอคุณลักษณะหลายอย่าง ขอแนะนำเป็นอย่างยิ่งให้คุณสร้างทีมย่อยหลายทีมโดยมีเป้าหมายที่แตกต่างกัน ในลักษณะนี้ ทุกทีมย่อยจะได้วิ่งและกำหนดแผนงานของตน
เมื่อเทียบกับทีมใหญ่ทีมใดทีมหนึ่ง ทีมขนาดเล็กที่เกิดจากเฟรมเวิร์ก 'การแยกทางตรรกะ' จะมีประสิทธิภาพมากกว่าและให้ผลลัพธ์ที่ดีกว่า แต่ละทีมสำหรับไมโครเซอร์วิส สายผลิตภัณฑ์ที่แตกต่างกัน และส่วนประกอบต่างๆ เป็นเพียงตัวอย่างเล็กๆ น้อยๆ ของแนวทาง 'การแยกทางตรรกะ'
ในระหว่างการปรับโครงสร้างใหม่ จำเป็นต้องรวมสมาชิกอย่างน้อยหนึ่งคนจากทีมหลักก่อนหน้าในแต่ละทีมย่อยเพื่อรักษา DNA แม้ว่าการประสานงานระหว่างทีมในการจัดส่งจะมีค่าใช้จ่ายเพิ่มเติม แต่ก็เป็นการแลกเปลี่ยนที่สมเหตุสมผล
ติดตามการใช้งานคุณสมบัติพร้อมกับ Velocity
ประสบการณ์ของผู้ใช้เป็นตัวชี้วัดที่สำคัญที่สุดในการวัดความสำเร็จของการเปิดตัวคุณลักษณะใหม่ เมื่อคุณเริ่มนำเสนอคุณสมบัติหลายอย่างอย่างรวดเร็ว ประสบการณ์ของผู้ใช้มักจะต้องเสียเปรียบ เมื่อผลิตภัณฑ์ของคุณมีคุณสมบัติที่จำกัด การโต้ตอบกับผู้ใช้จะยังคงเป็นเส้นโค้งที่ราบรื่นไม่ขาดตอน
อย่างไรก็ตาม เมื่อคุณเริ่มเผยแพร่คุณลักษณะใหม่ ๆ มีโอกาสสูงที่ผู้ใช้จะถูกครอบงำและประสบการณ์ของพวกเขาจะได้รับผลกระทบ
การติดตามการมีส่วนร่วมของผู้ใช้ควบคู่ไปกับความเร็วของฟีเจอร์ยังคงเป็นวิธีที่ดีที่สุดเพื่อให้ผู้ใช้นำไปใช้ได้ดียิ่งขึ้น ในขณะที่การวิจัยผู้ใช้อย่างละเอียดถี่ถ้วนเป็นวิธีหนึ่งที่ได้รับการพิสูจน์แล้ว แต่สิ่งสำคัญอื่นๆ กำลังเปิดตัวในขั้นต้นให้กับผู้ใช้ที่เลือกผ่านการตั้งค่าสถานะคุณลักษณะ การทดสอบ AB และการติดตามเส้นทางของผู้ใช้ (ผ่านแอมพลิจูดหรือเครื่องมือวิเคราะห์ที่คล้ายกัน) หลังจากเผยแพร่ใหม่ทุกครั้ง
อย่าสูญเสียสมาชิกหลักของคุณ
นี่อาจเป็นแง่มุมที่มักถูกละเลย แต่ก็ยืนหยัดอย่างมั่นคงว่าเป็นสิ่งสำคัญมาก ทีมขนาดเล็กไม่จำเป็นต้องมีกระบวนการและมีโครงสร้างที่ว่องไว และได้ยินเสียงของทุกคน เมื่อทีมเหล่านี้ย้ายไปอยู่ในสถานะที่มีการตั้งค่ากระบวนการและเพิ่มสมาชิกด้านวิศวกรรมและหน้าที่ใหม่ การจัดการที่ดีเป็นวิธีเดียวที่จะหลีกเลี่ยงความสับสนวุ่นวาย
เมื่อทีมวิศวกรของคุณประสบความสำเร็จในการขยายขนาด ทีมผลิตภัณฑ์ที่มีความสามารถเป็นสิ่งสำคัญในการเลี้ยงทีมวิศวกรอย่างต่อเนื่อง ความปั่นป่วนเป็นสิ่งที่หลีกเลี่ยงไม่ได้เมื่อสมาชิกในทีมไม่มีงานสำคัญ แต่ไม่มีสตาร์ทอัพคนไหนอยากจะสูญเสียสมาชิกหลักไป ในกรณีนี้ ผู้บริหารระดับสูงถือกุญแจสำคัญในการสร้างความสัมพันธ์ที่ดีกับผู้คนและเข้าใจพลวัตเป็นอย่างดี
การเรียนรู้ที่ฉันแบ่งปันที่นี่มาจากประสบการณ์กับบริษัทสตาร์ทอัพหลายแห่งในช่วงหลายปีที่ผ่านมา ฉันคาดหวังว่ามันจะเป็นประโยชน์สำหรับผู้ก่อตั้งสตาร์ทอัพที่มีจำนวนมากอยู่แล้วในจานของพวกเขา ในแบบที่พวกเขาไม่ได้ลงเอยด้วยการคิดค้นล้อใหม่