Làm thế nào để thay đổi các chính sách hiện có trong một tổ chức?

Tôi giả định rằng một tổ chức muốn thực hiện chuyển đổi DevOps có một số vấn đề và chính sách mà họ quan tâm để thay đổi. Sự quan tâm này có thể đến từ các nhà quản lý hàng đầu, quản lý cấp trung hoặc thậm chí từ dưới lên. Một trong những yếu tố lớn nhất cản trở sự thay đổi này là khiến người khác mua để thực hiện thay đổi.

Ví dụ, trong nhiều trường hợp thúc đẩy các ý tưởng "mới" như Agile, thường thất bại. Mọi người chống lại sự thay đổi, và dường như một bức tường ngăn chặn những điều tốt đẹp xảy ra. Tuy nhiên, có một nhiệm vụ cho những điều tốt đẹp sẽ xảy ra.

Những phương pháp nào có thể được sử dụng để tác động đến nhân viên trong một tổ chức bắt đầu chuyển đổi DevOps? Đặc biệt là các kỹ thuật cụ thể và cách thức được tìm thấy để làm việc. Cụ thể như trong Kỹ thuật nhiều hơn, vẫy tay ít hơn.

Bạn phải hiểu rằng các quy trình thay đổi những người theo dõi họ. Khi mọi người học hỏi, nội tâm hóa và trở nên tốt hơn trong một quy trình, nó sẽ thay đổi cách họ học cách giải quyết một vấn đề cụ thể. Một tập hợp các quy trình tương tự củng cố lẫn nhau thành một tư duy mà người đó sử dụng để giải quyết một loại vấn đề và cuối cùng hình thành một tập hợp các giá trị hướng dẫn các quyết định và giải pháp mới cho các vấn đề mới.

Ngay cả khi bạn thay đổi quy trình, không thay đổi tư duy và thậm chí quan trọng hơn đối với các giá trị, người đó sẽ chỉ cần điều chỉnh quy trình mới để tuân thủ cùng các giá trị, cùng suy nghĩ hoặc thậm chí cùng một giải pháp như trong quy trình ban đầu. Tại một thời điểm nhất định, không thể ly dị người này ở vị trí này khỏi suy nghĩ có được hoặc thay đổi các giá trị cơ bản.

Để tạo ra một sự thay đổi, bạn có hai tùy chọn sau:

1. Mang lại một người sẽ có các giá trị và suy nghĩ đúng đắn và trong trường hợp tốt nhất, hãy hiểu quá trình cần phải tuân theo mà không cần sự giúp đỡ của bạn.
2. Mang lại và trao quyền cho nhân viên mới, được thuê gần đây, thuê mới hoặc chuyển từ một nhóm khác trong tổ chức và đào tạo anh ta trong quy trình mới, hy vọng khơi dậy tư duy mới, hy vọng bộ giá trị mới sẽ xuất hiện.

Nếu thay đổi là cục bộ, bạn có thể thích chuyển khoản nội bộ vì người đó đã chia sẻ các giá trị rộng của công ty toàn cầu mà bạn muốn giữ lại. Trong trường hợp có sự thay đổi lớn hơn, bạn cần đưa ai đó từ bên ngoài để có một viễn cảnh mới mẻ và không chia sẻ các giá trị rộng lớn của công ty mà bạn có thể đang cố gắng thay đổi.

Phần quan trọng là trao quyền cho người, nhóm hoặc đơn vị kinh doanh tuân theo các quy trình và cách ly họ khỏi nhóm cũ, các nhóm khác hoặc phần còn lại của công ty, tương ứng, vẫn có thể tuân theo các quy trình cũ. Vì rất khó để cách ly tác nhân thay đổi như vậy khỏi quản lý ở trên, nếu thay đổi lớn hơn, nó thường cần phải theo tất cả các cách lên chuỗi quản lý hoặc đi từ đầu của nó.

Lưu ý : Thật khó để mang lại sự thay đổi cho nhiều nhóm hơn là không có sự hỗ trợ của ban quản lý. Ngay cả trong nhóm của bạn cũng khó khăn nếu những người khác đã được thiết lập theo cách của họ. Đối với một nhóm mới trong một công ty mới, một nhà truyền giáo thành công thường có thể ảnh hưởng đến các chính sách hình thành ngay cả khi không có sự hỗ trợ của quản lý chỉ bằng cách trở thành một nhà lãnh đạo hoặc tạo ra con đường ít kháng cự nhất cho những người khác đi theo. Nhưng trong công ty thành lập, xem ở trên.

Hack đội của bạn

Mang lại sự thay đổi trong tổ chức của bạn là khó khăn. Mọi người có thói quen, họ chống lại sự thay đổi, và họ thường thoải mái với hiện trạng. Để mang lại sự thay đổi, không theo thứ tự cụ thể, đây là một vài công cụ bạn có thể sử dụng.

1. Nguyên nhân khiến người khác gặp phải vấn đề mà DevOps giải quyết. Nhiều lần lợi ích của DevOps chỉ được hiểu ở cấp độ lý thuyết bởi nhóm của bạn. Hầu hết các vấn đề xảy ra trong quá trình triển khai là hy vọng và hiếm khi gặp phải bởi phần còn lại của nhóm phát triển hoặc quản lý. Để khắc phục điều này, hãy đảm bảo rằng bạn phát biểu về các vấn đề khi chúng phát sinh và đề cập đến vấn đề này sẽ không xảy ra nếu nhóm sử dụng giải pháp tích hợp liên tục. Một khả năng khác là đảm bảo bạn yêu cầu các nhà phát triển khắc phục các sự cố mà mã của họ gây ra trong quá trình triển khai thay vì tự sửa nó.

2. Tìm các nhà lãnh đạo . Mọi người thường theo dõi các nhà lãnh đạo, có thể là quản lý hoặc chỉ là người phổ biến nhất / chỉ huy trong nhóm. Đưa những nhà lãnh đạo này lên tàu với mong muốn của bạn chuyển sang văn hóa DevOps và nghĩ ra những cách thức công khai mà họ có thể được nhìn thấy bằng cách sử dụng hoặc ủng hộ các thực tiễn tốt nhất.

3. Xây dựng niềm tin . Chúng tôi có nhiều khả năng đồng ý với những điều từ mọi người sau khi chúng tôi đã đồng ý với họ một hoặc hai lần trước đó. Lý tưởng nhất, bạn có thể tìm thấy những cải tiến nhỏ có thể được thực hiện mà không cần thay đổi văn hóa và xây dựng dựa trên thành công đó. Tuy nhiên, nếu đó không phải là một lựa chọn, hãy hỏi họ những câu hỏi đơn giản và đưa ra những gợi ý đơn giản để họ có thói quen nói đồng ý hoặc đồng ý với bạn.

4. Đừng xấu hổ khi lặp lại chính mình. Sự lặp lại hoạt động và cuối cùng chìm vào. Bất cứ khi nào có thể đề cập đến những điều tuyệt vời sẽ như thế nào nếu nhóm sử dụng DevOps. Tuy nhiên, điều này chỉ hoạt động nếu bạn có niềm tin đầu tiên được xây dựng trong nhóm của mình.

5. Làm cho nó dễ chịu . Nếu bạn được phép xây dựng một bằng chứng về khái niệm cho tình huống DevOps của mình, hãy sử dụng các biểu tượng cảm xúc dễ thương và màu sắc vui vẻ trong các báo cáo và thông báo. Đăng gifs vui khi xây dựng thất bại. Hãy chắc chắn rằng bạn không gây phiền nhiễu với các cập nhật của bạn.