การจัดการกับโปรแกรมเมอร์ที่ไม่ยืดหยุ่น

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

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

ฉันแนะนำว่าเรากำจัดค่าใช้จ่ายในการพัฒนาบางส่วน (เช่นการกรอกสเปรดชีตไม่กี่รายการ) เพียงแค่รวมการจัดการข้อบกพร่องและเครื่องมือควบคุมเวอร์ชัน (ทั้งคู่เป็นเครื่องมือของ IBM-Rational เพื่อให้การรวมกันเป็นเรื่องง่าย นอกจากนี้หากเราใช้เครื่องมือเช่น Maven & Ant (โปรเจ็กต์เกี่ยวข้องกับ Java และผลิตภัณฑ์ COTS บางรายการ) การสร้างและวางจำหน่ายสามารถทำให้ง่ายขึ้นซึ่งควรลดข้อผิดพลาดและการแทรกแซงด้วยตนเอง

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

เราจะรับมือกับสถานการณ์นี้ได้อย่างไรโดยไม่สร้างแรงเสียดทานในทีม?

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

ตกลงคำแนะนำการปฏิบัติบางอย่าง:

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

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

ทำความรู้จักกับสิ่งกีดขวางบนถนนของคุณ ค้นหาสาเหตุของการต่อต้านและทำงานกับสิ่งเหล่านั้น

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

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

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

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

ในฐานะกลยุทธ์การสร้างทีมฉันแนะนำเจ็ดภาษาในเจ็ดสัปดาห์ให้กับคนที่คุณมีปัญหา

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

(1) สร้างแบบจำลองโดเมน (แบบง่าย) (2) ใช้งานโดยใช้สองภาษาที่แตกต่างกัน (เช่น Java และ Lisp)

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

หวังว่านี่จะช่วยได้

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

ในฐานะนักพัฒนาชาวรัสเซีย (และเห็นการปฏิบัตินิยมแบบตะวันตกที่มีเหตุผลน้อยกว่า) ฉันเห็นเหตุผลเชิงปฏิบัติที่น่าเชื่อถือน้อยกว่าการพยายามเดินเล่นในรองเท้าของคนอื่น

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

ฉันเชื่อว่าการมีความยืดหยุ่นภายนอกข้อดีที่ชัดเจนของความคิดของคุณอาจเป็นคาถาเวทมนต์ของคุณที่นี่

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

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

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

• บางทีเขาคิดว่าคุณพูดเกินจริงปัญหา (พวกเขาไม่สามารถเป็นคนเลวได้ ... )

• บางทีเขาคิดว่าคุณไม่เข้าใจความเสี่ยงด้านเทคนิคอย่างเต็มที่

• บางทีเขาคิดว่ามีความสำคัญมากกว่าที่จะทำตอนนี้

• บางทีคุณอาจจะถูเขาผิดทาง

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

หากคุณต้องการติดตาม "การปรับปรุงกระบวนการ" ในตอนนี้คำแนะนำของฉันจะทำให้ช้าลงในขั้นตอนเล็ก ๆ

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

เป็นสถาบันเกี่ยวกับอะไรเป็นพิเศษ เทคโนโลยีรูปแบบการปฏิบัติ?

หากพวกเขาได้รับในองค์กร / โครงการเป็นเวลานานโอกาสที่พวกเขานักพัฒนาอาวุโสกำลังและมีความรับผิดชอบ / ประสบการณ์ในการโทรเหล่านั้นและมีประสบการณ์ในโครงการมากกว่าแค่จะปรับอากาศเช่นการทดลอง 5 ลิง

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

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

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

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

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

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

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