กระบวนการของทีมของฉันอยู่เหนือการควบคุมหรือไม่?

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

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

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

อะไรคือวิธีที่ดีในการจัดการกับสิ่งนี้? ฉันมีทฤษฎีมากมาย แต่ฉันกำลังมองหาคำตอบจากคนที่มีประสบการณ์การทำงานจริงในสถานการณ์เช่นฉัน

นี่คือรายการเล็ก ๆ ของการทำงาน:

• นักพัฒนาซอฟต์แวร์แต่ละคนรับผิดชอบต่อแอปพลิเคชันและบริการเฉพาะที่โต้ตอบกับมัน
• โดยทั่วไปแล้วรีลีสจะถูกทดสอบโดยไคลเอนต์ในเซิร์ฟเวอร์ที่ใช้งานจริงจำลองจากนั้นปรับใช้กับเซิร์ฟเวอร์ที่ใช้งานจริง
• แต่ละแอปพลิเคชันใช้งานโดยเฉลี่ย 50-80 คนโดยมี 8 แอปพลิเคชั่นทั้งหมด

ขอบคุณ

ลูกค้าของเราจะไม่ยอมรับผลล่าช้าอย่างกะทันหัน

ถ้าอย่างนั้นพวกเขาก็ต้องยอมรับในคุณภาพที่แย่

สิ่งที่คุณต้องทำเพื่อเปลี่ยนสิ่งนี้คือให้ลูกค้าของคุณยอมรับความเป็นจริงของการพัฒนาซอฟต์แวร์ (หรือการผลิตอื่น ๆ !): สิ่งที่เร่งรีบส่งผลกระทบต่อคุณภาพ

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

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

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

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

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

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

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

ท้ายที่สุดคุณต้องให้ความรู้แก่ลูกค้าเกี่ยวกับการพัฒนาซอฟต์แวร์และให้ลูกค้ามีส่วนร่วมในกระบวนการให้มากที่สุด สิ่งที่พวกเขาเห็นในขณะนี้คือการส่งมอบคุณสมบัติใหม่อย่างรวดเร็ว แต่ยังมีข้อบกพร่องในซอฟต์แวร์ ในขณะที่พวกเขาจะมีความสุขกับอดีตพวกเขาจะไม่ (หรือไม่ควร) มีความสุขกับหลัง

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

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

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

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

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

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

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

หวังว่าจะช่วยในระดับหนึ่ง .. หวังว่าฉันไม่ได้พลาดจุด

สิ่งที่คุณอธิบายฟังดูธรรมดามากและไม่น่าตกใจเลย

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

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