ความเร็วที่เพิ่มขึ้นอย่างมากเป็นจริงในสภาพแวดล้อมการต่อสู้หรือไม่?

เมื่อเร็ว ๆ นี้ผู้จัดการของฉันผลักดันให้ใช้ความเร็วเป็นเป้าหมายและวัดผลการผลิต ขณะนี้เรากำลังทำงานที่ความเร็วเฉลี่ย 50 คะแนน ผู้จัดการของฉันต้องการให้เราเพิ่มขึ้น 40% เป็น 70 คะแนน (โดยไม่เพิ่มสมาชิกในทีม) หากเราไม่บรรลุเป้าหมายที่เพิ่มขึ้นเขาต้องการให้เราอธิบายเหตุผลว่าทำไม

แนวคิดทั้งหมดในการวัดประสิทธิภาพของทีมด้วยความเร็วและการใช้งานเป็นเป้าหมายดูเหมือนว่าผิดสำหรับฉัน แต่ฉันพบว่ายากที่จะอธิบายว่าทำไม ความช่วยเหลือใด ๆ ทำไมจึงไม่ใช่วิธีที่ถูกต้องในการวัดและสร้างแรงจูงใจให้ผลิตภาพ?

ง่ายมากที่จะเพิ่มความเร็ว 40% เพียงเพิ่มคะแนน 40% ให้กับการประมาณทั้งหมดของคุณและทำงานในปริมาณที่เท่ากัน

ระบุว่าสิ่งนี้เป็นเช่นนั้นควรเห็นได้ชัดว่าทำไมการใช้ความเร็วเป็นเป้าหมายจึงไม่ถูกต้อง

คำตอบที่กะล่อนน้อยกว่าคือการประมาณของคุณแล้วว่าคุณจะไปเร็วเท่าที่จะทำได้ในขณะที่ทำทุกอย่างถูกต้อง วิธีเดียวที่จะเพิ่มผลผลิตได้ถึง 40% คือการทำงานล่วงเวลาหรือทำทุกอย่างไม่ถูกต้อง ความเร็วทั้งสองนี้เพิ่มขึ้นในระยะสั้น แต่ช้าลงในระยะยาว และในระยะยาวในกรณีนี้จะไม่ยาวมากเดือนข้างนอก กลยุทธ์ระยะยาวที่เหมาะสมคือไม่เคยก้าวไปเร็วกว่าก้าวที่ยั่งยืนของคุณ

Peoplewareพูดถึงปัญหาเกี่ยวกับการพยายามบังคับโปรแกรมเมอร์ให้ทำงานในระดับที่สูงขึ้นและเป็นรูปแบบที่อ้างถึงบ่อยครั้ง แต่โดยทั่วไปแล้วมันจะไม่ง่ายเลยที่จะเปลี่ยนใจผู้จัดการที่กำลังเดินไปตามเส้นทางที่คุณเป็น โครงการของคุณอาจมีปัญหา - นี่เป็นธงสีแดงแน่นอน

ดังที่ความเห็นชี้ให้เห็นว่าคำขอนั้นผิดอย่างเห็นได้ชัด แต่เขาก็ไม่ผิดที่ต้องการปรับปรุงการผลิตอย่างต่อเนื่อง ตามกฎแล้วนั่นคือสิ่งที่ผู้จัดการพยายาม (และได้รับการประเมิน) สำหรับ

ที่กล่าวว่าผู้จัดการมักจะมองหาเพื่อปรับปรุงประสิทธิภาพการทำงานและ Scrum และ Agile เป็นเรื่องเกี่ยวกับการปรับตัว ในขณะที่ความเร็วเป็นตัวชี้วัดของการก้าวเดินอย่างยั่งยืนในปัจจุบันของคุณคุณไม่ควรกลับไปนั่งดูเกียรติยศอีกต่อไป การแย่งชิงกันมีสถานที่สำหรับการประเมินผลและการเปลี่ยนแปลงสิ่งที่ใช้งานได้และไม่ได้อยู่ในกระบวนการของคุณ: ย้อนหลัง หากคุณใช้ประโยชน์จากสิ่งนั้นและปรับกระบวนการผลิตของคุณ (และความเร็วที่อาจเกิดขึ้น) ควรเพิ่มขึ้น

คุณกำลังมองหาหนทางที่จะมีประสิทธิผลมากขึ้นในฐานะทีมหรือไม่? มีอะไรในการวิ่งแข่งของคุณที่ใช้ความพยายามอย่างไม่เหมาะสมสัดส่วนเป็นประจำหรือไม่? สามารถแก้ไขได้ไหม มันอาจจะไม่ทำให้คุณเพิ่มขึ้น 40% แต่ 5-10% เป็นการเริ่มต้นใช่มั้ย การวิ่งทุกครั้งคุณควรมองหาคอขวดและจัดการกับมัน ในที่สุดคุณอาจเข้าใกล้เป้าหมายที่เขาตั้งไว้ให้คุณ

TL; DR

Velocity มีประโยชน์อย่างมากสำหรับการประเมินกำหนดการหรือสร้างค่าการวางแผนและยังสามารถควบคุมนักสืบที่มีความหมายสำหรับการประเมินคอขวดของกระบวนการหรือการเปลี่ยนแปลงความสามารถของทีม มันไม่ได้เป็นตัวชี้วัดที่ถูกต้องของการผลิต

เมื่อความเร็วถูกทำให้สับสนกับเป้าหมายการจัดการ

"Velocity" เป็นช่วงที่แสดงความสามารถเฉลี่ยของทีมในช่วงเวลาที่ผ่านมา เป็นการวิเคราะห์ทางสถิติของประสิทธิภาพที่ผ่านมาซึ่งสามารถใช้ในการประมาณการความน่าจะเป็นของความจุเวิร์กโหลดในอนาคตหรือรอบเวลา สิ่งนี้ตรงกันข้ามกับ "เป้าหมายการตั้งเวลา" ซึ่งเป็นวัตถุประสงค์ของการจัดการที่กำหนดลำดับเวลาหรือเป้าหมายสำหรับการวางแผน

ผู้จัดการโครงการเปรียวที่มีประสบการณ์รู้ว่าการใช้ความเร็วที่เหมาะสมคือการพิจารณาว่าทีมมีความสามารถที่ยั่งยืนในการบรรลุเป้าหมายการจัดการที่กำหนดโดยฝ่ายบริหารหรือไม่ บางครั้งคำตอบคือใช่และทุกคนมีความสุข บางครั้งคำตอบคือไม่จุดสามเหลี่ยมเหล็กบังคับให้การตัดสินใจทางธุรกิจเกี่ยวกับขอบเขตราคาเวลาและคุณภาพ

ประเมินทางเลือกทางการเมืองของคุณ

เรามีความเร็วเฉลี่ย 50 เรื่องราว ... ฉันถูกขอให้เพิ่ม 40% เป็น 70 คะแนน (โดยไม่เพิ่มสมาชิกในทีม)

สมมติว่าวิธีการประมาณค่าของคุณนั้นดีและความเร็วของคุณมีความเสถียรพอสมควรผู้จัดการของคุณจะไม่ได้รับความสุขจากการปรับขนาดโดยประมาณหรือตั้งค่าเป้าหมายการจัดการที่ไม่ได้ขึ้นอยู่กับประสิทธิภาพในอดีต ในขณะที่คุณชี้ให้เห็นอย่างถูกต้องนี่เป็นปัญหาด้านความสามารถพื้นฐาน

ขีดจำกัดความจุอาจเกี่ยวข้องกับจำนวนคนในทีมของคุณหรืออาจเป็นข้อ จำกัด ของกระบวนการในองค์กรของคุณ แน่นอนว่าการเพิ่มผู้คนเพิ่มไม่ได้เพิ่มความสามารถของโครงการจริงเช่นกัน ดูกฎหมายของ Brooksสำหรับข้อมูลเพิ่มเติมเกี่ยวกับความเข้าใจผิดที่พบบ่อยนี้

ปัญหาที่คุณเผชิญคือเรื่องการเมือง จากน้ำเสียงของโพสต์ของคุณดูเหมือนว่าผู้จัดการของคุณต้องการที่จะเห็นการเพิ่มประสิทธิภาพในการทำงานโดยไม่ต้องทำการเปลี่ยนแปลงใด ๆ กับความสามารถพื้นฐานของทีม การแก้ปัญหาจึงเป็นเรื่องการเมืองและการศึกษาส่วนใหญ่อยู่ในธรรมชาติ

หากคุณเป็นร้าน Scrum ขอให้ Scrum Master ของคุณแก้ไขปัญหานี้ผ่านช่องทางที่เหมาะสม Backlog Grooming และ Sprint Retrospectives มักเป็นโอกาสในการตรวจสอบและปรับตัวในอุดมคติสำหรับปัญหานี้โดยเฉพาะ

หากคุณไม่ใช่ร้าน Scrum คุณต้องตัดสินใจเลือกวิธีที่เหมาะสมในการจัดการข้อกังวลของคุณภายในองค์กรของคุณ หากคุณมีข้อตกลงที่ดีกับผู้จัดการของคุณคุณอาจยืมสำเนาของการประมาณและวางแผนสำหรับเขาสองคนเพื่อหารือเกี่ยวกับอาหารกลางวัน

หากทุกคนล้มเหลวเตรียมความพร้อมสำหรับการเดินขบวนโดยการแปรงเรซูเม่ของคุณและทำอย่างมืออาชีพให้ดีที่สุดจนกว่าโครงการจะระเบิด 68% ของโครงการด้านไอทีล้มเหลว ; เว้นแต่เป้าหมายการจัดการจะได้รับการพิจารณาอย่างมั่นคงในความสามารถขององค์กรคุณอาจเป็นหนึ่งในนั้น

ฉันไม่เข้าใจว่าผู้จัดการของคุณมีบทบาทอย่างไรในทีมการต่อสู้? เขาเป็นโค้ชหรือไม่ เขาเป็นเจ้าของผลิตภัณฑ์หรือไม่

ถ้าเขาอยู่ในทีมเหมือนโค้ชหรือเขาทำงานให้กับการพัฒนาคุณอาจถามเขาว่าทำไมเขาถึงประเมินผลงานของตัวเองต่ำเกินไปเพราะดูเหมือนว่าไม่ใช่กรณีสำหรับสมาชิกในทีมคนอื่น หากเขาเชื่อว่าเขาสามารถรับ 30 คะแนนได้ทุก ๆ การย้ำให้เขาแสดงให้เขาเห็น

น่าจะเป็นมากกว่านี้: เขาอยู่นอกทีมอาจเป็นเจ้าของผลิตภัณฑ์หรือไม่ ถ้าเป็นเช่นนั้นเขาควรเข้าใจการทำสิ่งที่โง่เง่าเช่นนี้เขาหยุดความว่องไว

กฎพื้นฐานคือเจ้าของผลิตภัณฑ์กำหนดเป้าหมายในขณะที่ทีมกำหนดสิ่งที่สามารถทำได้ในการทำซ้ำ การไม่ทำเช่นนั้นนำไปสู่วงกลมเหล็กคลาสสิกและเป็นที่รู้จักกันดี: ทรัพยากร, ความเร็ว, คุณสมบัติ เลือกสอง! คุณไม่สามารถเลือกได้สามแบบพร้อมกัน (และอย่าลืม: คุณภาพไม่ใช่ตัวแปรการปรับการพยายามตัดมุมด้วยคุณภาพต่ำจะทำให้สิ่งเลวร้ายลง)

หากเขาไม่ต้องการเปลี่ยนเป้าหมายปัจจุบันอาจจะสามารถเพิ่มผลิตภาพได้ถึง 40% โดยการสรรหาคนเข้าร่วมทีมมากขึ้น? บางทีการลงทุนในการฝึกอบรมขั้นสูงสำหรับสมาชิกในทีมบางคน? ทีมอาจได้รับความเร็วในช่วงเวลาที่ผ่านการปรับปรุงอย่างต่อเนื่อง แต่ไม่แน่นอนโดยการตัดสินใจโดยพลการ

การพยายามเปลี่ยนความเร็วของทีมก็เหมือนกับการพยายามเปลี่ยนขนาดของห้อง สามารถทำได้ แต่โดยทั่วไปคุณต้องเปลี่ยนห้อง

คุณไม่มี Scrum Master หรือคนอื่น ๆ ที่มีความเข้าใจพื้นฐานของ Scrum ที่สามารถอธิบายสิ่งนั้นกับเขาได้

ในกรณีนี้ผู้จัดการได้เปลี่ยนทิศทางผิดหลังจากได้รับการประเมินที่ซื่อสัตย์และซื่อสัตย์จากทีม ผู้จัดการควรหันไปหาผู้มีส่วนได้เสียและแจ้งให้พวกเขาทราบว่าข้อกำหนดของพวกเขาไม่สามารถดำเนินการให้เสร็จภายในเวลาที่ร้องขอ ผู้จัดการ / นักวิเคราะห์ควรจัดลำดับความสำคัญของคุณลักษณะที่ต้องรวมและคุณสมบัติอื่น ๆ ที่สามารถรอได้ (แม้จะใช้เวลาเพียงสองสามสัปดาห์) หากผู้มีส่วนได้เสียไม่มีเหตุผลก็อาจต้องมีผู้จัดการที่สูงขึ้นในการมีส่วนร่วมซึ่งโดยทั่วไปอาจเป็นเรื่องที่ท้าทายและต้องมีการอภิปรายอื่น ๆ

ถ้าผมอยู่ในรองเท้าของคุณฉันจะเกิดขึ้นกับกรณีที่มีรายละเอียดว่าทำไมโครงการISจะใช้เวลานานเท่าอยู่ที่ประมาณ ลองระบุรายการที่มีผลตอบแทนต่ำ ค้นหารายการที่ไม่ได้เพิ่มคุณค่ามากนักและต้องใช้ความพยายามในการเขียนโปรแกรมอย่างมากและสร้างเคสสำหรับการลบสิ่งเหล่านั้นออกจากการวิ่ง นอกจากนี้ยังมีวิธีการวนซ้ำซึ่งให้ "X" ในวันที่ "Y" และตรวจสอบให้แน่ใจว่ามันเป็นไปได้จากนั้นทำซ้ำการติดตามที่จะได้รับรายการที่เหลือ

โดยทั่วไปแล้วบางคนต้องบอกผู้มีส่วนได้เสียว่าพวกเขาสามารถคาดหวังว่าจะได้รับอะไรภายในวันที่กำหนดและรวมถึงข้อกำหนดส่วนใหญ่ด้วย และโดยการปล่อยต่อไปนี้พวกเขาจะมีรายการที่เหลืออยู่ หากลูกค้ามีเหตุผลที่ไม่สมเหตุสมผลผู้บริหารระดับสูงจำเป็นต้องมีส่วนร่วมผู้จัดการควรจะสามารถทำให้เรื่องนี้เกิดขึ้นได้

อย่างไรก็ตามหากลูกค้าถูกสัญญามากกว่าและไม่มีใครพูดถึงตอนนี้มันจะเป็นการต่อสู้ที่ยากเย็นแสนเข็ญ นี่ไม่ใช่สถานการณ์ที่ผิดปกติอย่างน่าเสียดาย

ดูเหมือนว่าคุณต้องเผชิญกับสองประเด็น

ส่วนที่เกี่ยวกับการวัดความเร็วที่รบกวนจิตใจคุณอาจเป็นว่าวัดเป็นค่าใช้จ่าย สิ่งที่คุณต้องการที่จะปรับปรุงเป็นมูลค่า น่าเสียดายที่การวัดคุณค่าของซอฟต์แวร์นั้นเป็นเรื่องที่ยากและเป็นไปไม่ได้ แต่ถึงกระนั้นการวัดที่ไม่สมบูรณ์และเป็นอัตนัยก็ยังมีประโยชน์ อาจเป็นได้ว่าปัญหาแท้จริงไม่ใช่ว่าทีมของคุณต้องเขียนโค้ดเพิ่มเติม แต่เรื่องราวนั้นจำเป็นต้องมีค่ามากกว่า

ปัญหาอื่น ๆ นั้นขึ้นอยู่กับบัญชีของคุณผู้จัดการของคุณคาดว่าผลผลิตเพิ่มขึ้น 40% มันไม่ได้ระบุไว้ในคำถามของคุณเกี่ยวกับบริบทของคำขอนี้ มันอาจเป็นนิสัยที่ดีถ้าต้องการปรารถนาให้ทีมของคุณปรับปรุง หรืออาจเป็นสัญญาณบ่งชี้ที่ไม่ละเอียดนักว่าผู้จัดการของคุณเชื่อว่าทีมของคุณทำงานได้ไม่ดี

แก้ไข: ตามความคิดเห็นของคุณสถานการณ์ดูไม่ดี ดูเหมือนว่า บริษัท ของคุณกำลังวางรากฐานเพื่อไล่คุณและทีมของคุณ (อาจเป็นผู้จัดการของคุณด้วย) ฉันขอแนะนำให้คุณมองหางานอื่น

ไล่เขาออกไป นั่นคือการพูดไปให้พ้นหัวและอธิบายว่าเขาหมดความไว้วางใจในทีมของเขาและอธิบายว่าเขาไม่มีคุณค่าต่อธุรกิจ อธิบายว่าผู้จัดการที่มีระดับความสามารถในการไร้ความสามารถนี้จะเปลี่ยนได้ง่ายกว่าทีมด้านล่าง

ไม่มีเหตุผลที่ดีที่จะทนกับผู้จัดการดังกล่าว แต่นั่นไม่ควรหมายความว่าผู้พัฒนาควรลาออกโดยอัตโนมัติ ไม่จำเป็นต้องมีอะไรผิดปกติกับธุรกิจเพียงแค่กับบุคคลนี้ แก้ไขปัญหานั้น

และเพื่อที่จะยึดเอาการจัดการจากผู้บริหารระดับสูงให้ชัดเจนว่านี่ไม่ใช่ความผิดพลาดที่ลืมเลือน มันบ่งบอกว่าผู้จัดการที่รับผิดชอบไม่มีความเข้าใจในทีมที่เขาจัดการอยู่ ที่ไม่ได้ให้ยืมตัวเองเพื่อแก้ไขและไม่จำเป็นต้องมีในตลาดแรงงานในปัจจุบัน ผู้จัดการสามารถเปลี่ยนได้อย่างชัดเจนเหมือนกับโค้ชกีฬา เจ้าของอย่ายิงทีม

ตอนนี้อาจดูเหมือนกลยุทธ์ที่สามารถย้อนกลับมาได้ แต่ให้พิจารณา: หากผู้บริหารระดับสูงร่วมกับผู้จัดการของคุณไม่ว่าคุณจะอยู่ในสถานะขาดทุนอยู่แล้ว ดังนั้นหากคุณพิจารณาเฉพาะสถานการณ์ที่คุณไม่ได้อยู่ในสถานะสูญเสียผลลัพธ์จะเป็นไปในเชิงบวกมากขึ้น ความเสี่ยงที่แท้จริงคือการที่ผู้บริหารระดับสูงยิงทีมทั้งหมดรวมถึงผู้จัดการ มีเพียงคุณเท่านั้นที่สามารถประเมินความเสี่ยงนั้น เห็นได้ชัดว่าเป็นที่ต้องการของคุณไม่เช่นนั้นพวกเขาจะไม่ขออะไรเพิ่มเติม แต่ราคาเท่าไหร่?

ประสบการณ์ของฉันคือมันยากมากที่จะเพิ่มความเร็วที่แท้จริงของทีมเนื่องจากไม่ว่าทีมปัญหาโดเมนหรือเทคโนโลยีจะเปลี่ยนไป

ที่ฉันสามารถทำให้เพิ่มขึ้นได้ก็เป็นเรื่องของ:

• การชำระหนี้ทางเทคนิค ตรวจสอบให้แน่ใจว่าทุกอย่างทำงานถูกต้อง (ไม่จำเป็นต้องเป็นรุ่นล่าสุด!), รหัสนั้นดีพอสมควรและไม่มีความซ้ำซ้อนในระบบ (รหัสซ้ำรหัสที่ไม่ได้ใช้ ฯลฯ )

• ปรับปรุงการปฏิบัติ; การจับคู่ที่เป็นไปได้ (ใช่ฉันพบว่าเพิ่มความเร็ว) ใช้เวลาในการปรับโครงสร้างอย่างจริงจัง (เหมือนกัน!) และไร้ความปรานีเกี่ยวกับขอบเขตและโฟกัส

• การค้นหาและ / หรือการซื้อเครื่องมือที่ดีที่สุดสำหรับงาน (เช่น ReSharper สำหรับ. NET นั้นมีมูลค่าเท่ากับทองคำการพัฒนา Airbrake และ Splunk for Ruby เป็นต้น)

ฉันเห็นด้วยกับคนอื่น ๆ ที่นี่ที่บอกว่าผู้จัดการของคุณขอเพิ่มความเร็วโดยพลการเป็นธงสีแดง ฉันจะมองหางานอื่นที่มีความสำคัญสูง

ผู้จัดการของคุณกำลังขอ (หรือบอก) ทีมของคุณให้ทำงานเพิ่มชั่วโมง ในขณะที่การเอาคอขวดออกและการเพิ่มประสิทธิภาพอาจช่วยเพิ่มความเร็วของคุณได้บ้างวิธีเดียวที่จะได้รับการเพิ่มขึ้น (40%) คือการทำงานเป็นเวลานานขึ้นเพราะคุณจำเป็นต้องทำงานในหน่วยงานมากขึ้นในช่วงเวลานั้น

ลองทำสถานการณ์

สำหรับการผสมผสานสองสัปดาห์ให้บอกว่า 10 วัน ยูโทเปียจะเป็น 8 ชั่วโมงต่อวันโดยมีจุดเรื่องราวที่เป็นนามธรรมเพื่อวันทำงาน ดังนั้นจากด้านบน velcoity ของคุณจะเป็น 8 แต่ผู้คนที่สัมพันธ์กันอาจจะได้รับใน 6 ชั่วโมงที่ดีต่อวันด้วยอีเมลการประชุมการพักห้องน้ำ ฯลฯ ดังนั้นตอนนี้คุณอยู่ที่ 6 ต่อนักพัฒนา ดังนั้นพื้นฐานของคุณคือ 6 สมมุติว่าคุณต้องการให้คนทำงานล่วงเวลาตอนนี้ที่นั่น 10 ชั่วโมงต่อวัน ดังนั้นจะเป็น 10 คะแนนความเร็วต่อนักพัฒนา

ความเร็วของคุณจะผันผวนอยู่เสมอบางทีมันอาจจะต่ำเพราะคุณต้องจัดการกับข้อผิดพลาดมากมายในระหว่างการทำซ้ำนั้นอาจจะมีความต้องการที่ขาดหายไปหรืออาจมีบางคนที่ป่วยมาสองสามวัน อาจจะสูงเพราะมีการประเมินค่าสูงเกินไปหรือทีมของคุณใช้เวลาเพิ่มอีกชั่วโมง

แต่ถ้าคุณอยู่ที่ระดับ 50 แน่นอนการได้รับ 70 จะต้องใช้เวลาเพิ่ม

ปัญหาเกี่ยวกับความเร็วคือมันเป็นตัวแปรขึ้นอยู่กับผลลัพธ์ที่วัดได้ของกระบวนการพัฒนาของคุณ ความต้องการในการเพิ่มความเร็ว 40% นั้นก็เหมือนกับการพยายามทำงานให้เร็วขึ้นโดยการตะโกนใส่รถให้เร็วขึ้น ความเร็วเพิ่มขึ้นโดยป้อนเชื้อเพลิงและอากาศเข้าสู่เครื่องยนต์หรือรับรถเร็วขึ้นรวมถึงค้นหาเส้นทางที่มีการจราจรน้อยลง

การทำงานหลายชั่วโมงไม่ได้เพิ่มความเร็วหากคุณวัดอย่างถูกต้องพูดในจุดคุณลักษณะต่อนักพัฒนาชั่วโมง ใช้งานได้เฉพาะถ้าคุณวัดคะแนนต่อวันจากนั้นกำหนดใหม่ว่า "วัน" อยู่ในระดับใด นี่เป็นเพียงภาพลวงตาของความเร็ว

การเพิ่มความเร็วต้องมีการปรับปรุงตัวแปรอิสระในกระบวนการพัฒนา คอมพิวเตอร์และคอมไพเลอร์ที่เร็วขึ้นระบบการสร้างที่มีประสิทธิภาพมากขึ้นกระบวนการออกแบบที่ดีขึ้นนักพัฒนาที่มีความสามารถมากขึ้นพื้นที่ทำงานที่ดีขึ้นแรงจูงใจที่เหนือกว่า การปรับปรุง 40% จะต้องมีการเปลี่ยนแปลงที่สำคัญมาก

ถามว่าผู้จัดการของคุณจะพิจารณาร่วมทีมของคุณในสำนักงานที่ปิดล้อมรอบห้องทำงานทั่วไปซื้อฮาร์ดแวร์ dev ใหม่ทั้งหมดของทีมหรือจ้างผู้พัฒนาอาวุโสจำนวนมากเพื่อให้คำปรึกษากับทีมถ้านั่นจะทำให้เขาได้ 40% หากไม่มีทรัพยากรที่สามารถปรับปรุงปัจจัยการผลิตให้กับกระบวนการพัฒนาของคุณได้นั่นเป็นสิ่งที่ทำให้คุณสนใจอย่างจริงใจในการปรับปรุง สิ่งนี้ทำให้ผู้จัดการวิศวกรรมของคุณต้องย้อนกลับไปหาสิ่งที่เป็นแรงบันดาลใจให้เขาจริงๆ

ฉันแปลกใจนิดหน่อยที่คำตอบอื่น ๆ ตอบคำขอของเจ้านายอย่างจริงจัง คนที่ต้องการเพิ่มผลผลิต 40% ไม่รู้สิ่งแรกเกี่ยวกับการพัฒนาซอฟต์แวร์

ฉันยังคงสนุกกับการอ่านPhil Factorในหัวข้อนี้:

การจัดการไอทีมีสองเส้นทางพื้นฐาน คุณสามารถเรียนรู้การค้าขายของคุณผ่านทางเลือดเหงื่อและน้ำตาและค่อยๆไต่ระดับขึ้นอยู่กับความน่าเชื่อถือที่คุณได้รับจากความรู้ทางเทคนิคและโครงการที่ประสบความสำเร็จ คุณสามารถสวมสูทและเน็คไทที่คมชัดเรียนรู้ศัพท์แสงและพูดคุยอย่างราบรื่นไปยังจุดสูงสุด

เส้นทางทั้งสองดูเหมือนจะมีประสิทธิภาพเท่ากัน การจัดการกับสายพันธุ์หลังนั้นอาจทำให้เกิดความกลัวและความสิ้นหวังอย่างไม่คาดฝัน ... แม้กระทั่ง ... และบางส่วนก็บันทึกไว้ในเรื่องราวเหล่านี้

อย่างไรก็ตามมันเป็นเรื่องง่ายที่จะเศร้าและขมขื่นเมื่อพบกับความสามารถทางเทคนิคในตำแหน่งที่มีอำนาจและทำให้ผู้จัดการทั้งหมดด้วยแปรงเดียวกันนั้นหมดไป ฟิลให้คำแนะนำกับมัน ผู้จัดการส่วนใหญ่ทำงานหนักและมีส่วนร่วมกับ บริษัท และแม้แต่ผู้จัดการที่ไม่ดีก็สามารถฝึกฝนตามมาตรฐานที่กำหนดได้หากคุณเพียงทำตามแนวทางง่ายๆ เป็นส่วนหนึ่งของความรับผิดชอบของทีมของคุณเพื่อช่วยให้ผู้จัดการของคุณทำงานในลักษณะที่จะเป็นประโยชน์ต่อทุกคน

ในที่สุดหากคุณไม่สามารถฝึกอบรมพวกเขาได้รับการเลื่อนตำแหน่งหรือหลีกเลี่ยงพวกเขาบางทีคุณสามารถเรียนรู้ที่จะรักพวกเขาเพียงเพื่อสนับสนุนพวกเขาโดยไม่ได้ตั้งใจให้กับนักแสดงตลกในที่ทำงาน

คำแนะนำที่จะไม่กลายเป็น "เศร้าและขมขื่น" เป็นสิ่งที่ดีที่สุดที่คุณจะได้รับ อย่าต่อสู้กับหัวหน้าที่ไร้ความสามารถทางเทคนิคเกี่ยวกับเรื่องทางเทคนิค เขาจะเห็นว่าเป็นการโจมตีส่วนตัว

ผู้จัดการของคุณเข้าใจผิดเกี่ยวกับการใช้ความเร็ว ไม่ใช่ตัวชี้วัดและไม่ใช่เป้าหมาย โดยมีวัตถุประสงค์คือการสอบเทียบปริมาณงานของทีมต่อการวิ่งหนึ่งครั้ง
หากคุณคิดเกี่ยวกับมันความเร็วของคุณจะปรากฏขึ้นจากการเดาที่ดีที่สุดซึ่งคุณจะได้รับหลังจากการวิ่งแต่ละครั้ง โดยปกติเมื่อเวลาผ่านไปควรมีเสถียรภาพบ้าง แต่นั่นไม่ได้เปลี่ยนความจริงที่ว่ามันเป็นผลพลอยได้จากสิ่งที่ทีมของคุณกำลังทำจริง ๆ : การสร้างคุณค่าให้กับลูกค้าของคุณ

สาเหตุที่ทำให้การใช้มันเป็นเป้าหมายและ / หรือตัวชี้วัดที่ไม่ถูกต้องนั้นเป็นเพราะมันจะทำให้มันเป็นตัวชี้วัดความหยิ่งยะโส มันจะดูดีบนกระดาษ แต่มันจะไม่ทำอะไรอย่างแน่นอนเพื่อสะท้อนให้เห็นถึงสภาพอากาศที่ดีหรือไม่ผลิตภัณฑ์ของคุณเต็มไปด้วยความต้องการของลูกค้า และนั่นคือสิ่งที่สำคัญที่สุด (ฉันหวังว่า)

เกี่ยวกับประสบการณ์ของฉันและตรงไปยังจุด

ขั้นแรกคุณสามารถขยายการประมาณค่าได้ แต่ไม่ได้หมายความว่าคุณจะทำมากขึ้น

ประการที่สอง (สถานที่ตั้ง: โดยไม่ต้องพองเพียงมุ่งเน้นไปที่ความเร็วของทีม)

พยายามค้นหาทักษะภายในทีมของคุณ พวกเขาทำงานในสิ่งที่ดีที่สุดหรือไม่? คุณต้องการสถาปนิกระบบเพื่อทำการตัดสินใจที่ยากลำบากเกี่ยวกับการสร้างแอปพลิเคชันและสิ่งที่ซับซ้อนหรือไม่? ทีมใช้ความพยายามของพวกเขาอย่างไร? พวกเขาใช้เวลาค้นคว้าหาวิธีแก้ปัญหาการปรับโครงสร้างการตัดสินใจทางธุรกิจหรืออะไร

พวกเขาสบายโฟกัสและประเมินไหม? จะเกิดอะไรขึ้นต่อไปสำหรับพวกเขา

นี่ไม่ใช่ "ฉันผลักดันขีด จำกัด " ... มันเป็นเหมือนคำถามสำหรับทั้งทีม "เราอยู่ในขีด จำกัด หรือไม่" และ "เราจะผลักดันขีด จำกัด ได้อย่างไร" ...

ฉันได้นำทีมที่มีประสิทธิภาพสูง (สำหรับการก่อสร้างครั้งแรกและ / หรือการย้ายถิ่นฐาน) ... แรงจูงใจของทีมคือกุญแจแห่งความสำเร็จ ... และการวางแผนว่าฐานของแอปพลิเคชันจะเป็นสิ่งสำคัญอย่างไร บางครั้งฉันหรือเพื่อนร่วมทีมได้รับบทบาทของ Systems Architect และตัดสินใจว่าควรจะทำอย่างไร "สิ่ง"

บางครั้งเมื่อฉันเห็นว่าเพื่อนร่วมทีมของฉันกำลังสูญเสียประสิทธิภาพฉันพยายามที่จะทำลายและเชิญพวกเขาออกไปดื่มเบียร์หรืออะไรที่พวกเขาชอบ วิธีนี้จะแก้ไขความขัดแย้งและในวันถัดไปพวกเขาจะมุ่งเน้นอีกครั้ง

ขาย ...

หากอธิบายเหตุผลที่คุณไม่สามารถเพิ่มความเร็วได้ยากให้ใช้ ROI

การต่อสู้มุ่งเน้นไปที่สิ่งที่สำคัญที่สุดสำหรับลูกค้า ในทางทฤษฎีงานที่ทำกำไรได้มากที่สุด

หากปัญหาของคุณเกี่ยวกับการขายความพยายามในการพัฒนาคุณคิดอย่างไรกับการขาย ROI ของความพยายามในการพัฒนาแทนที่จะแปลงคะแนนเรื่องราวเป็น "ราคา" โดยตรง หากคุณสามารถพิสูจน์ได้ว่าทีมของคุณทำงานกับ ROI สูงใครจะถามคุณ นอกจากนี้ทุกทีมมีข้อ จำกัด หากทีมพบว่า "ขนาดความสะดวกสบาย" ให้ลองเดือนต่อเดือนเพิ่มขึ้นเล็กน้อยหากพวกเขาไม่สามารถทำงานทั้งหมดให้เสร็จได้นี่คือข้อ จำกัด (อาจ)

แสดงประวัติของงานรายได้ผลกำไร (ถ้ามี) จุดเรื่องราวที่คุณใช้และแสดงให้เห็นว่าการผลิตไม่ได้เป็นความพยายามของทีมคือการคำนวณที่กำหนดโดยทีมเพื่อประเมินความซับซ้อนและอาจถึงเวลาที่จะได้รับบางสิ่ง เสร็จแล้ว