Làm thế nào để truyền giáo DevOps và các công cụ trong một môi trường chấp nhận thấp?

Một cách học gợi mở về công nghệ đột phá sáng tạo là bạn có thể phát hiện ra rằng không phải ai cũng sẽ hào hứng với các công cụ có thể mang lại cho bạn năng suất cao hơn.

Để làm cho câu hỏi này ít chung chung hơn, những gì nên và không làm - như họ cũng nói, những bài học kinh nghiệm - về việc truyền giáo Docker trong tổ chức của bạn dựa trên kinh nghiệm thực tế với các vai trò khác nhau?

Đây không phải là đặc thù của docker, nhưng quy tắc chung này cho việc truyền giáo được áp dụng: các đối tượng khác nhau đòi hỏi bằng chứng khác nhau. Nói chung, các nhà phát triển phần mềm (và các nhà quản lý từ nền tảng phát triển) muốn thấy nó hoạt động, vì vậy các kết quả có thể đo lường được của POC được ưu tiên. Các chuyên ngành khác và các bên liên quan điều hành có thể ổn với các nghiên cứu trường hợp và thuyết trình trước khi bật đèn xanh; Mục tiêu của bạn là xác định đối tượng bạn đang nói chuyện và bắt đầu xây dựng một cuộc tranh luận toàn diện.

Khởi đầu nhỏ; tìm một bên liên quan chính và trình bày trường hợp của bạn bằng các bằng chứng phù hợp nhất với họ. Kiên nhẫn; thay đổi trong các tổ chức trưởng thành thường chậm, vì vậy, có được một dự án nhỏ và vận hành là một thành tựu lớn.

Một vài tháng trước tôi đã trình bày về những ưu và nhược điểm về docker. Kỳ vọng của tôi là các nhà phát triển sẽ bắt đầu sử dụng công cụ ngay sau khi thuyết trình, nhưng phải mất một vài tháng. Hóa ra là một vấn đề (rất lớn) là bắt buộc để được các thành viên trong nhóm chấp nhận:

Có sáu dịch vụ tại thời điểm này tất cả chạy trong mơ hồ. Hệ thống của tôi không thể xử lý được nữa. Chúng ta sẽ sử dụng docker? Bạn đã nói trong bài thuyết trình của mình rằng nó bỏ qua một hệ điều hành, rằng nó nhẹ hơn so với VM nên máy sẽ tiêu tốn ít tài nguyên hơn và tôi sẽ có thể chạy các dịch vụ cục bộ phải không?

Khi hóa ra các dịch vụ hiện đã có thể chạy, ngày càng nhiều nhà phát triển bắt đầu sử dụng docker.

Bạn có thể đặt tên của các đồng nghiệp trong một tờ và quyết định mỗi cá nhân nếu một người dễ hay khó thay đổi, có nhiều ảnh hưởng và sẵn sàng chia sẻ kiến ​​thức. Bắt đầu chia sẻ thông tin với người có số điểm cao nhất và cố gắng thuyết phục anh ấy hoặc cô ấy thuyết phục người tiếp theo có khả năng thay đổi nhất.

Người giới thiệu

https://hbr.org/2015/03/convincing-skeptical-empologists-to-adopt-new-t Technology

Bạn muốn những người có khả năng làm việc theo chiều ngang trong tổ chức và những người có kỹ năng giao tiếp và kết nối tốt.

https://hbr.org/2014/09/convincing-emp NHÂN-to-use-new-t Technology

Xác định sớm các nhà vô địch kỹ thuật số đã cam kết của bạn - những cá nhân có mạng lưới tốt và có thể tạo ảnh hưởng theo chiều ngang để giúp thực hiện thay đổi hành vi trên các silo.

https://gethppy.com/talent-manloyment/convince-empologists-adopt-new-t Technology

Đảm bảo rằng các giám sát viên hoặc nhân viên khác mà các nhân viên còn lại tìm kiếm lời khuyên và lãnh đạo sẽ thể hiện sự nhiệt tình.