Đối phó với các lập trình viên không linh hoạt

Đôi khi các lập trình viên làm việc trong một dự án trong thời gian dài trở nên không linh hoạt, và điều đó trở nên khó khăn để lý luận với họ. Ngay cả khi chúng tôi có thể thuyết phục họ, họ vẫn không thể thực hiện các đề xuất của chúng tôi.

Chẳng hạn, gần đây tôi đã tham gia một dự án trong đó quá trình xây dựng và phát hành quá phức tạp và có những rào cản không cần thiết.

Tôi đã gợi ý rằng chúng ta nên loại bỏ một số chi phí phát triển (như điền vào một vài bảng tính) chỉ bằng cách tích hợp các công cụ quản lý lỗi và kiểm soát phiên bản (cả hai đều là các công cụ IBM-Rational để tích hợp có thể là một nỗ lực rất dễ dàng). Ngoài ra, nếu chúng tôi sử dụng các công cụ như Maven & Ant (dự án liên quan đến Java và một số sản phẩm COTS), việc xây dựng và phát hành có thể được đơn giản hóa để giảm lỗi và can thiệp thủ công.

Tôi đã thuyết phục được người khác và tôi sẵn sàng nỗ lực phát triển một bằng chứng về khái niệm. Nhưng nhà phát triển 'Senior' không sẵn lòng, có thể vì quy trình hiện tại khiến anh ta có giá trị hơn.

Làm thế nào để chúng ta xử lý tình huống này mà không phát triển ma sát trong đội?

Bạn là thành viên nhóm mới và bạn muốn thay đổi một số khía cạnh cơ bản về cách thức hoạt động của nhóm. Chúc may mắn, tôi cảm thấy một đội hạnh phúc trong tương lai của bạn.

Ok, một số lời khuyên thiết thực:

Chứng minh bản thân với đội. Bạn sẽ cần phải làm điều này từ góc độ kỹ thuật và độ tin cậy. Nếu bạn muốn mọi người theo dõi bạn, bạn cần cho họ một lý do để làm điều đó.

Hiểu lịch sử của phương pháp luận. Tại sao nó tồn tại? Vấn đề gì đã được giải quyết vào thời điểm đó? Hãy chắc chắn rằng giải pháp của bạn thực sự là một lợi ích cho nhóm. Có thể những thay đổi của bạn tốt hơn, nhưng chúng có thể không thực sự giải quyết được vấn đề mà nhóm gặp phải.

Nhận biết rào cản của bạn. Tìm hiểu lý do cho sự kháng cự của họ và làm việc trên các mặt hàng đó.

Nếu bạn muốn trở thành tác nhân thay đổi, hãy học cách trở thành tác nhân thay đổi thành công . Hàng chục cuốn sách và các nguồn khác có sẵn để cung cấp cho bạn nhiều thông tin hơn bạn sẽ nhận được ở đây.

Và, vâng, tôi chúc bạn may mắn. Nhưng làm ơn, vì hạnh phúc của bạn và hạnh phúc của đội bạn, hãy thông minh về điều đó. Mong muốn của bạn để thực hiện một thay đổi quá trình, mà không đầu tư năng lượng để tạo ra con đường đúng, có thể gây hại nhiều hơn là tốt.

Tôi đã ở vị trí bạn đã đề cập. Tôi đã dành nhiều năm làm nhà phát triển Java và cuối cùng đã đi vào một công việc mà tất cả họ đều sử dụng Smalltalk. Phản ứng đầu tiên của tôi là "OMG, họ đang sử dụng công nghệ lỗi thời này" và tôi bắt đầu thử giải quyết các vấn đề cụ thể của Smalltalk bằng các giải pháp Java. Tôi chỉ có thể tưởng tượng những gì tôi phải đau đầu với các nhà phát triển khác và họ ghét Java với niềm đam mê.

Mãi cho đến khi tôi được giao một dự án cỡ trung bình để làm việc trong khi tôi được hai nhà phát triển cấp cao cố vấn trong suốt vài tháng, tôi bắt đầu hiểu ngôn ngữ của Smalltalk và học cách thích nó. Kể từ khi rời bỏ Công việc đó và quay trở lại phát triển Java, tôi cảm thấy linh hoạt hơn rất nhiều khi tôi có thể thực hiện một dự án và thực hiện nó bất kỳ ngôn ngữ nào mà công ty sử dụng. Điều cốt lõi để khiến những người này hiểu là ngôn ngữ không có gì hơn phương tiện. Tôi cũng đã dành thời gian để dạy bản thân Lisp và Erlang, nhưng điều đó có thể không hiệu quả với tất cả mọi người.

Là một chiến lược xây dựng đội nhóm, tôi muốn giới thiệu Bảy ngôn ngữ trong bảy tuần cho những người bạn gặp khó khăn.

Tôi đoán nó cũng phụ thuộc vào việc những người này sẵn sàng đầu tư bao nhiêu thời gian để trở nên linh hoạt hơn. Vấn đề với hầu hết các trường đại học (ít nhất là những trường tôi đã thấy) là họ thiên về một ngôn ngữ cụ thể và sinh viên của trường trở thành "thể chế hóa" như bạn đã đề cập. Tôi nghĩ một phần trong chiến lược của bạn nên là trau dồi sự linh hoạt trong nhóm của bạn. Điều này có thể được bổ sung với Phát triển theo hướng tên miền .

(1) Mô hình hóa một miền (Một đơn giản) (2) Triển khai nó bằng hai ngôn ngữ khác nhau (ví dụ Java và Lisp)

Một lần nữa, đây là giả định rằng họ có động lực để làm những điều trên và sẵn sàng đầu tư thời gian của riêng họ để đạt được điều này.

Hi vọng điêu nay co ich

Tôi có thể đang theo dõi hoàn toàn sai ở đây, nhưng dường như các vấn đề tương tự là phổ biến ở quy mô rộng hơn, và liên quan đến chủ nghĩa bảo thủ của con người. Mọi người thường từ chối thay đổi các mẫu hành vi nổi tiếng, vì những lý do quá nhiều để đề cập.

Là một nhà phát triển người Nga (và do đó ít thấy chủ nghĩa thực dụng phương Tây hợp lý), tôi thấy lý luận thực tế sẽ kém thuyết phục hơn nhiều so với cố gắng đi trong đôi giày của người khác.

Nói cách khác, bạn đã đề cập rằng lập trình viên cao cấp đánh giá cao vị trí của chính mình liên quan đến sơ đồ làm việc hiện tại. Có lẽ bạn nên thuyết phục anh ấy rằng cách làm mới sẽ khiến vị trí của anh ấy trở nên có giá trị hơn, và có nhiều cách để làm điều đó. Ví dụ: bạn có thể yêu cầu anh ấy thực sự phát âm ý tưởng của bạn và nhận được tín dụng cho nó, hoặc bạn có thể tìm thấy một vị trí cụ thể trong quy trình mà anh ấy có thể kiểm soát độc quyền, v.v.

Tôi tin rằng linh hoạt bên ngoài những lợi thế rõ ràng của ý tưởng của bạn, có thể là phép thuật kỳ diệu của bạn ở đây.

Tôi đã thuyết phục được người khác và tôi sẵn sàng nỗ lực phát triển một bằng chứng về khái niệm. Nhưng nhà phát triển 'Senior' không sẵn lòng, có thể vì quy trình hiện tại khiến anh ta có giá trị hơn.

Thay vì truyền tham vọng vào nhân vật của nhà phát triển cao cấp (di chuyển xấu), có lẽ bạn nên cố gắng hiểu lý do tại sao anh ta không nhiệt tình:

• Có thể anh ấy nghĩ bạn là một trong những người giám sát ý tưởng của họ. Có thể anh ta nghi ngờ rằng bạn có thể cung cấp cho họ.

• Có thể anh ấy nghĩ rằng bạn đang phóng đại các vấn đề. (Họ không thể tệ đến thế ...)

• Có thể anh ấy nghĩ rằng bạn không hoàn toàn nắm bắt các rủi ro kỹ thuật.

• Có lẽ anh ấy nghĩ (biết) có nhiều việc quan trọng hơn để làm ngay bây giờ.

• Có lẽ bạn chỉ chà anh ta sai cách.

Lời khuyên của tôi sẽ là chứng minh bản thân với anh ấy. Giống như bằng cách phân phối các dự án mà bạn đã thực sự được giao. Khi anh ấy tin tưởng vào khả năng và phán đoán của bạn nhiều hơn, thì hãy xem lại vấn đề này.

Nếu bạn muốn theo đuổi dòng "cải tiến quy trình" ngay bây giờ, lời khuyên của tôi sẽ là thực hiện từ từ, trong các bước nhỏ.

Hãy nhớ rằng chắc chắn có nguy cơ rằng những thay đổi được đề xuất của bạn ảnh hưởng lớn đến năng suất của nhóm và thậm chí khả năng duy trì phần mềm hiện có của họ. Nếu điều đó xảy ra, người phụ trách có khả năng nhận được nhiều sự ủng hộ nhất từ ​​quản lý cấp cao.

Thể chế về những gì cụ thể? Công nghệ, mô hình, thực tiễn?

Nếu họ đã ở trong tổ chức / dự án trong một thời gian dài, rất có thể họ là nhà phát triển cấp cao và có trách nhiệm / kinh nghiệm để thực hiện các cuộc gọi đó và có kinh nghiệm trong dự án thay vì chỉ bị coi là thí nghiệm của 5 con khỉ .

Giải pháp cho việc thuyết phục họ sẽ phụ thuộc vào chủ đề là gì, vì nếu một mô hình / công nghệ đã được chọn, sẽ có một lý do chính đáng, và sẽ phải có một lý do tốt hơn để thay đổi để biện minh cho công việc và làm quen, v.v. ., nếu vậy, một giải pháp dành cho một kiến ​​trúc sư / nhà phát triển cấp cao tổ chức một cuộc họp để quyết định một cách dân chủ giải pháp tốt nhất.

Nếu đội thực sự CÓ những khối đường không cần thiết thì có lẽ họ sẽ rất vui khi có bạn giúp họ sửa chúng. Tuy nhiên, xin lưu ý rằng có thể có lý do rất chính đáng để họ ở đó và bạn sẽ trông thật ngu ngốc nếu bạn phải nói "ồ, ý tưởng tuyệt vời của tôi không hoạt động sau đó" sau khi bán nó cho mọi người trong một thời gian dài.

Điều tra đầu tiên, và sau đó đi về phía trước. Cũng lưu ý rằng việc có thể HIỂN THỊ cách bạn đề xuất cải thiện sẽ tốt hơn nhiều so với rửa tay.

Tôi muốn nói rằng bạn là người "Lập trình viên không linh hoạt". Bạn chưa quen với dự án, nhưng bạn khăng khăng rằng ý tưởng của bạn là tốt nhất và anh chàng đang dẫn dắt dự án, người đã làm việc lâu hơn và biết hệ thống bên trong và bên ngoài chỉ là rocker của anh ấy.

Tôi khá có kinh nghiệm và được đánh giá khá cao và thường xuyên được giao nhiệm vụ sửa chữa các dự án đang gặp khó khăn với tư cách là thành viên đội hổ. Ngay cả sau đó tôi vẫn dành thời gian để tìm hiểu về tiếng gáy, tiếng rít, sự năng động của đội, dự án và thực tiễn của họ và không điên cuồng đi vào và nói với họ điều này như thế nào và điều đó là sai. Trên thực tế, tôi không bao giờ nói những gì họ đang làm là sai bởi vì điều đó không nhận được phản hồi tôi muốn và thông thường những gì họ đang làm không sai, nó chỉ cần một số điều chỉnh.

Mỗi dự án là duy nhất. Mỗi đội là duy nhất. Giải pháp của bạn có thể tốt hơn cho bạn và nhà phát triển, nhưng có thể không tốt hơn cho khách hàng tiềm năng, khách hàng, doanh nghiệp hoặc dự án nhưng vì bạn không có kinh nghiệm với dự án để biết rõ hơn, bạn sẽ không biết Câu trả lời cho điều đó.

Cách tốt nhất để khiến mọi người làm những gì bạn muốn là khiến họ nghĩ mọi thứ là ý tưởng của họ. Vì vậy, thay vì trực tiếp đưa ra gợi ý, trình bày các lựa chọn. Nếu ý tưởng của bạn rõ ràng tốt hơn các lựa chọn thay thế, hãy cho nhà phát triển cấp cao cơ hội chọn chúng và biến chúng thành của riêng mình. Đừng lo lắng về việc nhận tín dụng. Những người quan trọng sẽ biết chuyện gì đang xảy ra.