Người ta có thể làm gì khi người dẫn đầu bằng ví dụ, người không làm việc? [đóng cửa]

Tôi đã làm việc cho một công ty lớn (hơn 8000 nhân viên) gần 2 năm nay và được tuyển dụng ngay sau khi tôi hoàn thành khóa học.

Mọi người ở đây phải đối phó hàng ngày với mã kế thừa thường được thiết kế rất tệ và đầy rẫy. Lúc đầu, tôi giữ một hồ sơ thấp, cố gắng không chỉ trích mọi thứ quá nhiều. Nhưng tình hình, như hiện tại, đã trở nên rất khó sống và dường như không ai sẵn sàng cải thiện / thay thế các công cụ chúng ta sử dụng.

Để rõ ràng hơn, chúng tôi có:

• Một công cụ kiểm soát nguồn lỗi thời (Visual SourceSafe)
• Makefiles cũ đơn giản chỉ hỗ trợ xây dựng lại đầy đủ
• .def các tệp phải được duy trì thủ công và riêng cho tất cả các kiến ​​trúc hiện có
• Các tệp và dự án tiêu đề nguyên khối có rất ít tệp khác nhau (nhưng mỗi tệp có khoảng 3000 dòng mã, đôi khi đảm nhiệm các nhiệm vụ rất khác nhau)
• không sử dụng các phương tiện ngôn ngữ "mới" (cũng std::stringkhông phải là mới nhưng không ai ngoại trừ tôi sử dụng nó)

Tôi đã quyết định, một vài tháng trước để làm một cái gì đó về nó, bằng cách thiết kế một môi trường biên dịch mới. Tôi có thể có các bản dựng tăng dần để hoạt động đáng tin cậy, thời gian biên dịch nhanh hơn, các dự án có cấu trúc tốt hơn, .deftạo tệp tự động . Tôi thậm chí đã tạo một cầu nối từ / đến Git đến / từ Visual SourceSafe.

Tôi đã cho thấy thành tích của mình cho một số đồng nghiệp và ông chủ của chúng tôi nhưng nó giống như không ai quan tâm. Tất cả họ đều như "Chà ... mọi người đã quen làm theo cách đó bây giờ. Tại sao chúng ta sẽ thay đổi mọi thứ?"

Những thay đổi tôi đề xuất được thiết kế để chúng tôi có thể có sự chuyển đổi mềm mại từ hệ thống cũ sang hệ thống mới. Mỗi cải tiến có thể được áp dụng riêng biệt và an toàn.

Tôi thậm chí đã cố gắng để một số đồng nghiệp của tôi tham gia vào các thay đổi. Nhưng cho đến nay, không có thành công.

Bạn đã phải đối mặt với một tình huống tương tự? Người ta có thể làm gì khi "dẫn dắt bằng ví dụ" không hoạt động?

Mục tiêu cho người đứng đầu : "Dẫn dắt bằng ví dụ" cần có sự cải thiện trong tâm trí, nhưng nó nên được nhắm mục tiêu vào những người không dựa trên công nghệ. Có thể bạn đã đầu tư quá nhiều thời gian vào việc cải tiến công nghệ, nhưng không đủ thời gian cho những gì đang diễn ra trong đầu họ. Hãy suy nghĩ về các yếu tố lái xe tại sao có sự phản đối cho những điều mới. Trong nhiều trường hợp họ chỉ sợ một số rủi ro. Xác định những rủi ro đó và tìm phản biện cho chúng.

Lấy thịt tươi : Sẽ dễ dàng hơn để chiến thắng những nhân viên muốn thay đổi mọi thứ. Bạn nhận thấy chúng ngay lập tức khi bạn nhìn thấy chúng.

Tránh thịt thối : Một số người sẽ không bao giờ đồng cảm với ý tưởng của bạn. Để chúng sang một bên.

Phát triển đến một khối quan trọng : Tìm những người đồng cảm với ý tưởng của bạn. Giành chiến thắng từng cái một. Tại một số điểm nếu đạt được một khối lượng quan trọng, ngày càng nhiều người sẽ theo gương của bạn một cách tự nguyện.

Từ vựng quản lý: Các nhà quản lý không quan tâm đến các thiết kế tốt hơn. Ngôn ngữ của họ là tiền bạc và thời gian. Làm rõ bao nhiêu giờ người đàn ông bị lãng phí cho lỗi. Hãy làm rõ rằng những khách hàng không hài lòng gặp phải lỗi không có lợi nhuận. Chứng minh bạn có thể thực hiện một tính năng mới nhanh hơn bao nhiêu. Bạn cần chọn một từ vựng khác cho các nhà quản lý.

Đó là tất cả về các quy trình : Các công nghệ tốt hơn không làm cho các lập trình viên và chương trình tốt hơn. Nếu bạn có các quy trình chạy tốt, ngay cả các công nghệ lỗi thời cũng dẫn đến kết quả tốt. Hãy suy nghĩ về những nỗ lực và thời gian bị lãng phí. Có thể nó không phải là công nghệ, nhưng một cái gì đó trong các quy trình đang hết sức sai lầm. Trong hầu hết các trường hợp đó là một sự thiếu giao tiếp.

Tìm một công ty mới : Bạn đã đã làm rất nhiều. Bạn vẫn có thể cố gắng cải thiện mọi thứ, nhưng cũng tùy thuộc vào bạn quyết định thời gian bạn muốn thử nó và bao nhiêu năng lượng bạn muốn đầu tư. Hãy ghi nhớ: Ngay cả khi bạn không thể đạt được nhiều cải tiến, bạn sẽ học được rất nhiều từ những nỗ lực của mình. Tại một số điểm bạn cần phải di chuyển trên.

Bạn đã bao giờ dừng lại để xem xét rằng bạn có thể sai?

Vì vậy, bạn đọc một số thiết kế và mẫu sách trong trường và bạn bị tước quyền với những gì có vẻ giống như các thực hành cổ xưa tương đối nơi bạn làm việc. Không nghi ngờ gì có lẽ chúng là những ý tưởng tốt hơn và các dự án mới nên bắt đầu với những điều này trong đầu, nhưng có vẻ như bạn đang ở một cấp độ hoàn toàn khác.

Các nhà phát triển chăn gia súc cũng giống như cố gắng chăn dắt mèo, chúng vốn có một suy nghĩ của riêng chúng, và một cách làm việc ưa thích, cho dù đúng hay không. Tôi có một thời gian đủ khó để thực thi các thực tiễn tốt nhất và quản lý một nhóm gồm 2 nhà phát triển, nhưng bạn làm việc cho một công ty có 8000.

Đó là một con số khổng lồ đáng kinh ngạc. Ngay cả một thay đổi quy trình đơn giản mà tất cả các nhà phát triển phải lên lịch các cuộc họp và ngoài giờ làm việc trên lịch công cộng trở thành một chính sách cực kỳ phức tạp và khó thực hiện trên toàn ban. Nó cũng sẽ đòi hỏi một sự thúc đẩy đáng kể từ ban quản lý để đảm bảo chính sách được chấp nhận và áp dụng trên toàn hội đồng quản trị.

Bạn có thể không nghĩ vậy, nhưng một cái gì đó đơn giản như chuyển từ nguyên khối sang nhiều tệp tiêu đề hoặc chuyển điều khiển phiên bản từ SourceSafe sang Git đòi hỏi một nỗ lực và đầu tư rất lớn từ phía mọi người tham gia. Nó sẽ yêu cầu:

• Hỗ trợ quản lý quan trọng

• Công ty chấp nhận rộng rãi

• Đầu tư giờ họp cho tất cả các nhà phát triển để thông báo cho họ về các sáng kiến ​​mới (Cuộc họp tốn thời gian cho con người, giờ làm việc tốn kém)

• Đào tạo cần được lên kế hoạch và thành lập để đảm bảo ngay cả những nhà phát triển ngu ngốc nhất cũng biết họ đang làm gì

• Ngay cả khi giả định một giờ đào tạo, trên 8000 nhà phát triển x € 50 / giờ = € 400000 chi phí đào tạo. Đây là số tiền nhiều hơn một nhóm phát triển phần mềm của tôi được ngân sách trong cả năm cho tiền lương, phần mềm và phần cứng. Đó là một khoản đầu tư đặc biệt mà bạn đang đề xuất.

Nhưng bạn đang nói, "Hãy nghĩ về tất cả thời gian có thể được lưu thông qua việc tăng năng suất." Đúng như vậy, nhưng đầu tư đáng kể là rủi ro đáng kể, vì vậy tôi tốt hơn là chắc chắn rằng bạn đúng về điều này trước khi tôi đăng nhập vào nó. Nếu không ai trong số các đàn anh đang ủng hộ bạn thì tôi không thể biện minh cho chi phí. Cuối cùng, chúng tôi có thể không hiệu quả, nhưng chúng tôi nhất quán và với 8000 nhà phát triển trên toàn công ty, tính nhất quán là quan trọng nhất.

Để làm điều này, bạn cần đăng xuất từ ​​nhiều người cấp cao và bạn cần tìm một cách chính xác và khách quan để tìm cách đo thời gian của nhà phát triển bị mất hiệu quả. Thời gian đó tương đương với đô la và chỉ có đô la và chính trị sẽ giúp bạn chiến thắng trong trận chiến này.

Những gì bạn mô tả không giống như "dẫn dắt bằng ví dụ" với tôi, có vẻ như bạn đã đưa ra một đề xuất và đã bị từ chối. Để dẫn dắt bằng ví dụ, bạn cần cho mọi người thấy rằng cách của bạn tốt hơn. Trong số các vấn đề bạn liệt kê tôi thấy có ba vấn đề bạn có thể bắt đầu sử dụng thay đổi của chính mình.

Makefiles cũ đơn giản mà chỉ hỗ trợ xây dựng lại đầy đủ.

Tạo tệp tạo tệp riêng của bạn cục bộ và cho biết bạn có thể làm việc với chúng hiệu quả hơn như thế nào.

Các tệp và dự án tiêu đề nguyên khối có rất ít tệp khác nhau (nhưng mỗi tệp có khoảng 3000 dòng mã, đôi khi đảm nhiệm các nhiệm vụ rất khác nhau)

Hoặc phá vỡ các tệp hiện có khi bạn chạm vào chúng (mà không phá vỡ bản dựng) hoặc giới thiệu các tệp tiêu đề nhỏ hơn khi bạn viết mã mới. Khi mọi người bắt đầu làm việc với họ, họ sẽ nhận ra rằng họ không cần sự trùng lặp.

không sử dụng các tiện ích ngôn ngữ "mới" (well std :: string không phải là mới nhưng không ai ngoại trừ tôi sử dụng nó)

Tiếp tục giới thiệu các cơ sở ngôn ngữ mới bất cứ khi nào bạn chạm vào mã cũ hoặc giới thiệu mã mới. Hãy chắc chắn rằng bạn đang đơn giản hóa mọi thứ. Đừng nản lòng từ điều này. Hầu hết chúng ta đều lười biếng. Nếu chúng tôi thấy rằng một tính năng ngôn ngữ mới làm cho mọi thứ dễ dàng hơn, chúng tôi sẽ áp dụng nó.

Sau một vài tháng, nếu các nhà phát triển khác bắt đầu áp dụng các cải tiến của bạn, thì bạn có thể tiếp cận ông chủ của mình một lần nữa về những thay đổi triệt để hơn như nâng cấp hệ thống kiểm soát nguồn của bạn. Bạn cần chắc chắn rằng các nhà phát triển khác nhìn thấy lợi ích mặc dù, hoặc nó sẽ không bao giờ đi qua. Một cách để tiếp cận nó có thể là đề xuất dùng thử Git trong một dự án nhỏ mà chỉ có một vài nhà phát triển đang hoạt động. Bằng cách đó, bạn có thể quảng bá nó như một đánh giá, không phải là sự chuyển đổi toàn diện sang một hệ thống xa lạ.

Cuối cùng, nếu sau vài tháng cố gắng, không ai có vẻ quan tâm đến việc cải thiện cách mọi thứ được thực hiện tại công ty của bạn, bạn cần thực sự xem xét liệu nó có phù hợp với bạn không.

Ngoài việc nghiện Lionel Barret (mà tôi hầu hết đồng ý), cũng xem xét động lực có thể để kháng chiến.

• Đánh giá chi phí của quá trình thực tế
• Đánh giá chi phí của quá trình vì nó sẽ giống như của bạn

Nhưng cũng:

• Đánh giá chi phí của sự thay đổi trong nhiệm kỳ của
  • Tiền để chi tiêu để thiết lập môi trường mới cho bất cứ ai
  • Dành thời gian để đào tạo mọi người làm quen với chế độ mới (có thể dễ dàng với bạn, nhưng không dễ cho những người không biết về những gì bạn đang làm)
  • Thời gian đã qua cần thiết để quản lý thay đổi theo cách không phá vỡ.

Tôi có một nghi ngờ: Có bao nhiêu người trong công ty của bạn, những người như bạn về tuổi tác và văn hóa (tôi là đàn ông "trường học" và "loại trường học")? Có bao nhiêu người như bạn dự kiến ​​sẽ được tuyển dụng trong 2/3 năm tới và bao nhiêu người sẽ nghỉ hưu hoặc thay đổi vai trò của họ trong tổ chức?

Tôi nghi ngờ rằng bạn đang ở một vị trí không đủ sức mạnh để thay đổi công ty. Trong tình huống đó, công ty sẽ thay đổi bạn hoặc sẽ "trục xuất" bạn (Theo nghĩa đó, nó sẽ trở thành mong muốn của bạn để biến mất), nếu bạn không thể chờ thêm thời gian.

Nhưng có thể công ty đang đánh giá rằng các chi phí bổ sung mà tôi đã nói với bạn có thể được tiết kiệm cho phép quá trình thay đổi xảy ra một cách tự nhiên bằng cách chờ đợi sự thay thế tự nhiên của mọi người xảy ra. Bạn chỉ mới bắt đầu một quá trình mà bạn không thể thấy bởi vì không có gì (chưa) đằng sau bạn.

Tại thời điểm này, tôi chỉ có thể thêm một tham chiếu đến Điều Joel Hoàn thành mọi việc khi bạn chỉ là một người lẩm cẩm . Các phần bao gồm:

Chiến lược 1 Chỉ cần làm

Chiến lược 2 Khai thác sức mạnh của Viral Marketing

Chiến lược 3 Tạo một túi xuất sắc

Chiến lược 4 Trung hòa các Bozos

Chiến lược 5 Tránh xa sự gián đoạn

Chiến lược 6 Trở nên vô giá

Tôi muốn tóm tắt bài viết là "Thay đổi phải bắt đầu với bạn."

Đáng buồn thay, mọi người bị mắc kẹt trong một lối mòn và phát triển tâm lý rằng 'nó hoạt động, mọi người sử dụng nó ổn, tại sao thay đổi nó' Và nó đang gây phẫn nộ.

Bạn đã đi đúng hướng bằng cách không chỉ phàn nàn mà bằng cách phát triển một giải pháp khả thi như một sự thay thế, bây giờ bạn chỉ cần mua vào.

Hiển thị quản lý trực tiếp của bạn (hoặc lãnh đạo kỹ thuật). Nếu họ không quan tâm, bạn có ai chịu trách nhiệm kiểm soát thay đổi hoặc đổi mới không?

Có khả năng mặc dù, ý tưởng và công việc của bạn có thể bị bỏ qua và tình hình sẽ vẫn như vậy.

Bạn cần nói rõ trường hợp của bạn theo cách khiến sếp đứng về phía bạn. BTW, loại thay đổi này được đề xuất bởi giám đốc kỹ thuật hoặc người quản lý dự án, do đó sẽ cần phải cam kết với dự án. (Là một lộ trình thay thế, bạn có thể đề xuất kiểm toán kỹ thuật, người ngoài có thể nói những điều tương tự như bạn nhưng sẽ có trọng lượng hơn.)

Cho đến nay, anh ta không thấy sự cần thiết phải thay đổi, có vẻ như mỹ phẩm thay đổi với anh ta: Tốn kém mà không có lợi ích rõ ràng ngoại trừ để thỏa mãn sự ưa thích của một nhà phát triển. Chỉ có hai điều quan trọng với anh ta: dòng tiền và một đội ngũ ổn định. Công nghệ là một hộp đen, nếu nó hoạt động, thế là đủ.

Tiền đầu tiên, bạn cần phải chứng minh rằng thiết lập hiện tại đang làm anh ta mất tiền. Chi phí / giờ của một nhà phát triển và thời gian biên dịch nhanh hơn bao nhiêu giờ sẽ cứu anh ta? Làm toán. Ngoài ra, biên soạn các bài báo hoặc lời chứng thực về các rủi ro của đường dẫn mã hiện tại và cho anh ta thấy những con số đáng sợ: "vì Thực tiễn mã hóa / mã hóa xấu, công ty chúng tôi đã mất $ XXXK".

Thứ hai nhóm, ông chủ của bạn có thể bị mắc kẹt với các lập trình viên cục cằn cũ, những người không muốn thay đổi cách của họ. Nếu điểm đầu tiên được thiết lập, bạn cũng cần đề xuất một giải pháp cho vấn đề này. Bạn có bao nhiêu ? Thật thú vị khi nhấn mạnh rằng nó sẽ khó thay thế một ai đó bởi vì đường ống mã hóa hiện tại là bizantine. Bạn cần đề xuất một kế hoạch để cập nhật nhóm. Tìm hiểu họ về thực tiễn tốt nhất trong ngành và kiểm tra xem họ có tuân theo các quy tắc mới không.

Cuối cùng, bạn cần đề xuất một kế hoạch để thay đổi cơ sở mã, được chia thành các dự án nhỏ, với các mốc quan trọng và phân bổ nguồn lực. Trên thực tế, bạn đang bán mình với tư cách là người quản lý dự án và những thay đổi là bắt buộc để có một đường dẫn mã vững chắc.

Bạn có làm việc tại một tổ chức tin rằng làm mọi thứ tốt, hiệu quả và đổi mới dẫn đến thành công và lợi nhuận; hoặc rằng việc theo đuổi doanh thu, và tập trung vào việc duy trì doanh số là những người thuê thành công?

Các công ty hoạt động như bạn đang mô tả là cố thủ công nghệ. Trong một thị trường cạnh tranh, họ sẽ không thể cạnh tranh với một công ty tập trung vào các cá nhân và đổi mới.

Nếu bạn là người bạn nói, thì hãy làm việc ở đâu đó để tôn vinh và thưởng cho tinh thần của bạn. Cuối cùng, sau nhiều năm ổn định, bạn sẽ bắt đầu thỏa hiệp với cùng một triết lý mà cấp trên của bạn chấp nhận. Đi làm việc ở một nơi khác (có thể là một tổ chức nhỏ hơn) coi trọng công việc khó khăn, cảm hứng, sáng tạo và tiến bộ.

Nếu bạn không mạo hiểm và làm điều này sớm, cuối cùng bạn sẽ ổn định và bạn sẽ không thể tiếp tục nuôi dưỡng sự tò mò và sáng tạo của mình vì nó trái ngược về mặt triết học trong nhóm đồng đẳng hiện tại của bạn.

Xuất sắc là một thái độ và một thế giới quan.

Chỉ cần biết rằng trải nghiệm này đã cho bạn cái nhìn sâu sắc để biết những gì cần tránh, hãy chú ý đến sự tự mãn và bảo vệ để bạn có thể phát hiện sớm.

Trong cuộc phỏng vấn tiếp theo, hãy đặt ra những câu hỏi như "Những sáng kiến ​​nào đến từ nhân viên của bạn", "Một số thay đổi đến từ sự sáng tạo của cá nhân là gì?", "Những tài năng cá nhân nào tôi có thể mang lại cho nhóm này?", "Điều gì thúc đẩy thành công của tổ chức của bạn ? "," Làm thế nào để tổ chức của bạn liên tục nắm bắt sự đổi mới công nghệ? "... Câu trả lời cho những câu hỏi như thế này là vô cùng hay. Nhiều tổ chức không có tầm nhìn, hoặc những người tạo ra tầm nhìn đã biến mất, và tổ chức được điều hành bởi kế toán. Nếu bạn đang phỏng vấn với Giám đốc Công nghệ - hãy hỏi anh ta nếu anh ta thấy tổ chức này là một công ty công nghệ.

Nếu bạn không thích môi trường bạn đang làm việc thì bạn đang tự làm mất tinh thần. Bạn cần được bao quanh bởi những người có cùng sở thích và mục tiêu như bạn làm một cách chuyên nghiệp. Tôi biết đôi khi nói thì dễ hơn làm, nhưng cảm giác nhìn lại vài năm và cảm giác như thể bạn đã lãng phí thời gian của mình còn tệ hơn cả nỗi sợ mạo hiểm.

Thay vào đó, nếu bạn muốn phát triển trong một hệ thống hoặc môi trường sử dụng công nghệ và / hoặc phương pháp cụ thể thì tôi khuyên bạn nên tìm một dự án bên ngoài công việc mà bạn có thể đóng góp. Ít nhất thì sự đa dạng khi làm việc trên cả hai hệ thống sẽ đáp ứng nhu cầu về một cái gì đó khác biệt trong khi bạn tìm thấy nơi bạn thuộc về.

Dường như với tôi bạn là cá ra khỏi nước. Đi tìm cơ thể của bạn của đại dương và bơi!