จะเปลี่ยนนโยบายที่มีอยู่ในองค์กรได้อย่างไร

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

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

วิธีใดบ้างที่สามารถใช้เพื่อส่งผลกระทบต่อพนักงานในองค์กรที่เริ่มต้นการเปลี่ยนแปลง DevOps โดยเฉพาะเทคนิคและวิธีการเฉพาะที่พบในการทำงาน เฉพาะในด้านวิศวกรรมมากขึ้นโบกมือน้อย

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

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

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

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

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

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

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

แฮ็คทีมของคุณ

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

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

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

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

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

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