วิธีทำให้แน่ใจว่า บริษัท ของคุณจะไม่ลงไปใต้น้ำถ้าโปรแกรมเมอร์ของคุณชนะลอตเตอรี [ปิด]

ฉันมีโปรแกรมเมอร์ไม่กี่คนที่อยู่ภายใต้ฉันพวกเขาทั้งหมดทำได้ดีมากและฉลาดมาก ขอบคุณมาก.

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

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

1. โปรแกรมเมอร์เก่าอาจต่อต้านแนวคิดของการถ่ายโอนความรู้โดยกลัวว่าการสำรองข้อมูลอาจลดค่าลง
2. ฉันไม่มีระบบที่จะอำนวยความสะดวกในการถ่ายโอนเทคโนโลยีระหว่างผู้พัฒนาที่แตกต่างกันดังนั้นแม้ว่าฉันจะขอให้พวกเขาทำก็ตามฉันก็ไม่รับประกันว่าพวกเขาจะทำอย่างถูกต้อง

คำถามของฉันคือ

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

วิธีนำมันไปใช้กับโปรแกรมเมอร์เก่า ๆ

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

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

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

ในทีมของเรานอกเหนือจากความคิดเห็นเกี่ยวกับรหัส / การออกแบบเราใช้

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

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

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

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

บางทีพวกเขาอาจทำงานเป็นคู่ในบางสิ่งถ้าพวกเขามีความอยากรู้อยากเห็นก็ไม่น่ามีปัญหา

การรับเอกสารภายในของซอฟต์แวร์ที่ทันสมัยควรเป็นขั้นตอนแรกก่อนที่คุณจะเริ่มจ้างคนใหม่ แน่นอนว่าโปรแกรมเมอร์ที่มีค่าของคุณจะใช้เวลากับเครื่องมือ Office และ UML แทน IDE แต่ฉันคิดว่ามันคุ้มค่าในทุกกรณี

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

จากนั้นคุณสามารถพิจารณาการจ้างคนใหม่ หรือไม่ขึ้นอยู่กับปริมาณงานใน บริษัท ของคุณ

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

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

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

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

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

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

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

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

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

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

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

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

นักศึกษาฝึกงานอาจเป็นความคิดที่ดีพวกเขาจะเป็นผู้ใต้บังคับบัญชาโดยตรงกับผู้พัฒนาปัจจุบันดังนั้นพวกเขาจะไม่รู้สึกว่าถูกคุกคาม

ในขณะที่ บริษัท เติบโตคุณจะต้องมีนักพัฒนาทั้งเก่าและผู้ที่ทำมันหลังจากการฝึกงาน

ฉันคิดว่ามันอาจใช้ได้

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

ทุกคนได้รับคำสั่งให้ทำเอกสารขั้นตอนและกระบวนการทั้งหมด

ระดับ 3 ของ "การเตือนภัยขององค์กร "

อีกทางเลือกหนึ่งเรียงความแสดงให้เห็นว่าเราจะส่งเสริมวัฒนธรรมของ " ขึ้นหรือออก " แม้ว่าการโต้เถียงคือว่า บริษัท น้อยมากมีบันไดอาชีพด้านเทคนิคที่ในทางใดทางหนึ่งคล้ายกับคลื่นความถี่ทางการเงินและพลังงานที่บันไดอาชีพอาชีพ มี

การสร้างแนวคิดของเอกสารเต็มรูปแบบที่ @ammoQ เริ่มต้นในคำตอบของเขา ...

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

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

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

ก่อนที่ฉันจะเริ่มนำโปรแกรมเมอร์คนใหม่มาฉันขอให้แต่ละคนช่วยสร้างเอกสารที่เป็นของตนเอง

ไม่ว่าจะเป็นวิกิหรือเอกสารเกี่ยวกับงานสามด้านเกี่ยวกับงานของพวกเขา

หรือถ้าคุณต้องการเอกสารที่ละเอียดและละเอียดมาก ๆ จ้างนักเขียนด้านเทคนิคสัมภาษณ์โปรแกรมเมอร์แต่ละคนแล้วสร้างเอกสารทุกอย่างทุกคนทำทุกวันทุกสัปดาห์รายเดือนรายเดือนรายปี

จากนั้นสร้างเวอร์ชันของวิกิเพื่อให้โปรแกรมเมอร์ของคุณสามารถอัปเดต / แก้ไข / เข้าร่วม / แสดงความคิดเห็นได้

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

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

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

ทุกครั้งที่โปรแกรมเมอร์คนใดคนหนึ่งของคุณป่วยให้โทรหาเขาด้วยคำถามและปัญหาซ้ำ ๆ

ทุกครั้งที่โปรแกรมเมอร์คนใดคนหนึ่งของคุณหยุดพักผ่อนให้โทรหาเขาด้วยคำถามและปัญหาซ้ำ ๆ

ในไม่ช้าพวกเขาจะรู้ว่าจะดีกว่าสำหรับพวกเขาเช่นเดียวกับ บริษัท ที่จะไม่มีคนเดียวที่รับผิดชอบในพื้นที่หลัก

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

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

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

ใคร ๆ ก็อยากไปเที่ยวพักผ่อนบ้างไหม?

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