Làm thế nào để thuyết phục đồng nghiệp của tôi rằng làm việc đúng sẽ giúp họ tiết kiệm thời gian

Gần đây tôi đã bắt đầu tại một công ty mới, với một số ít lập trình viên. Đây là một công ty có quy mô trung bình, với khoảng 70 nhân viên, nhưng CNTT chỉ có 9-10 và có 3 "lập trình viên" bên cạnh tôi. Tuy nhiên, những kẻ này có kinh nghiệm rất hạn chế và đang làm rất nhiều thứ thực sự khủng khiếp. Ví dụ, một trong những dự án của chúng tôi là một trang web PHP. Phần lớn mã được lưu trữ trong bộ điều khiển PHP 20.000 dòng, với ~ 6000 dòng JavaScript được nhúng trong PHP.

Tôi tiếp tục đưa ra những gợi ý nhỏ ở đây và ở đó nhưng không ai nghe, mọi người nói rằng họ quá bận để thực hiện đề xuất của tôi. Vấn đề là, họ không nên bận rộn như vậy, và sẽ không nếu mọi việc được thực hiện đúng. Họ dành phần lớn thời gian để sửa chữa những thứ liên tục bị phá vỡ. Nếu mỗi dự án được xây dựng chính xác, tôi có thể tự làm tất cả.

Tôi nên làm theo cách tiếp cận nào để thuyết phục những người này hoặc người quản lý rằng mọi thứ cần thay đổi, và việc thay đổi mọi thứ sẽ tiết kiệm được rất nhiều thời gian? Tôi có nên bỏ qua việc cố gắng thuyết phục đồng nghiệp của mình và đi thẳng đến người quản lý, với một đề xuất kinh doanh về cách công ty sẽ tiết kiệm một loạt tiền nếu họ bắt đầu làm đúng?

Tôi đã thấy rằng nguyên nhân chính cho công việc cẩu thả, bên ngoài lập trình viên đơn giản là không quan tâm, là do thiếu kiến ​​thức. Thật không may trong rất nhiều môi trường, thiếu kiến ​​thức được xem thường hơn là thảo luận công khai.

Một số kỹ thuật mà tôi đã sử dụng thành công để thúc đẩy thảo luận, tăng trưởng và hứng thú chung về lập trình là:

• Các phiên công nghệ túi màu nâu hàng tuần (Cho họ nghiên cứu một chủ đề và trình bày).
• Hàng ngày hoặc hàng tuần một trong các buổi cố vấn giữa các thành viên cơ sở và cấp cao.
• Đánh giá mã (nhấn mạnh vào việc học, không chỉ ra sai lầm).

Học là truyền nhiễm. Khi bạn nuôi dưỡng một môi trường khuyến khích việc học, bạn không chỉ tạo ra các nhà phát triển tốt hơn mà còn cho những người khác trong nhóm của bạn biết rằng họ là một phần của một cái gì đó lớn hơn một cách để có được một mức lương.

Khi thấy rằng bạn được thuê làm nhà phát triển PHP và công việc của bạn là sửa chữa mọi thứ, tôi khuyên bạn nên đến lúc bạn uốn cong cơ bắp.

Nếu tôi ở vị trí của bạn, tôi sẽ làm một cuộc khảo sát tốt về mã và xem các lỗi xảy ra lặp đi lặp lại. Chặn thời gian họp mỗi tuần để đi qua những điều này với nhóm. Đừng chỉ ngón tay hoặc tên tên, chỉ cho thấy cách thực hiện nhiệm vụ đó đúng cách.

Tiếp theo, vì bạn đã thấy cần sửa chữa, hãy lập một danh sách. Nếu nó nhanh và dễ làm, hãy làm nó. Nếu nó sẽ làm cho cuộc sống của bạn dễ dàng hơn để làm nó .... làm điều đó. Lập danh sách tất cả những việc cần làm và đặt vé cho họ và xem khi nào mọi người có chu kỳ để thực hiện chúng. Nếu ai đó đang sửa một lỗi trong khu vực có vấn đề, hãy hướng dẫn họ cách khắc phục đúng.

Nếu nó đòi hỏi một sự thay đổi lớn, hãy ngồi xuống với nhóm và những người nắm giữ cổ phần và thảo luận về các lựa chọn.

Có một chính sách mở cửa, nơi bạn sẽ giúp mọi người. Hãy là một người giáo dục và không đe dọa. Không, "bạn phải làm theo cách này" và hơn thế nữa "sẽ tốt hơn nếu được thực hiện theo cách này". Giải thích các ưu điểm để thực hiện theo cách bạn đề xuất và các nhược điểm của cách thực hiện. Mọi người sẽ sẵn sàng làm điều đó đúng cách nếu họ cảm thấy họ đã học được điều gì đó thay vì được nói theo cách của họ là sai và làm theo cách khác b / c bạn nói như vậy.

Quan điểm của ban quản lý về vấn đề Nếu họ đã chấp nhận thời gian phát triển liên quan đến số lượng lỗi, tại sao họ lại mạo hiểm? Khi lợi ích dài hạn mâu thuẫn với các mục tiêu ngắn hạn, họ thường mất. Bạn đang yêu cầu họ lùi lại một bước. Họ có thể nghĩ rằng điều này sẽ gây ra một sự chậm trễ kéo dài. Bạn phải thuyết phục họ rằng nó sẽ không cùng với các lợi ích bổ sung. Nếu họ không nghĩ rằng họ có một mớ hỗn độn, hãy yêu cầu họ giải thích lý do tại sao phải mất quá nhiều thời gian để nhanh chóng giới thiệu các lỗi mới với mỗi "sửa chữa".

Chất lượng mã phụ thuộc vào nhiều tình huống và tình huống. Bán hàng, tiếp thị và quản lý sẽ khiến bạn tin rằng mọi thời hạn thất bại có nghĩa là công ty sẽ bỏ lỡ một cú bắn vào nhà đầu tư mạo hiểm trị giá hàng triệu đô la. Thực tế là, họ không muốn gửi tin xấu cho 1% khách hàng của bạn, những người thực sự không cần tính năng này. Tôi cực đoan và thường rơi vào một nơi nào đó ở giữa, vì vậy các nhà phát triển cần tìm hiểu thế nào là một trường hợp khẩn cấp thực sự. Sau đó, dễ dàng hơn để thuyết phục họ dành thời gian để làm điều đó đúng thay vì cần thời gian để làm điều đó. Bạn phải hiểu những rủi ro.

Giống như một cuốn tiểu thuyết tuyệt vời, lần đầu tiên mã không được viết tốt, nhưng thật không may, nó vẫn được xuất bản quá thường xuyên. Bắt đầu với một cái gì đó cơ bản như thiết lập một tiêu chuẩn mã hóa. Mọi người đều có một, nhưng nhiều người như trong hoàn cảnh của bạn, họ không được chính thức hóa và họ cũng không nghiêm ngặt. "Làm bất cứ điều gì bạn muốn." là một tiêu chuẩn rất dễ bảo trì. Bước tiếp theo là xác định cách bạn sẽ duy trì tiêu chuẩn của mình.

Bạn có một nhiệm vụ lớn trước bạn. Có thể một vài lập trình viên vĩ đại đã phát triển các kỹ năng và thói quen của họ đến mức họ không bao giờ phải thỏa hiệp với chất lượng mã của họ hoặc mắc nợ kỹ thuật, nhưng hãy chờ xem điều gì sẽ xảy ra khi nhà đầu tư thiên thần hứa hẹn mọi người sẽ giàu có.

Ngồi và viết nguyên mẫu (hoặc một số mô-đun nếu toàn bộ dự án quá lớn) sử dụng thiết kế thực sự tốt khi bạn thấy phù hợp. Sau đó trình bày / thảo luận với nhóm. Nó có thể dễ dàng hơn để thuyết phục bằng ví dụ.

Trong quá trình này, bạn cũng có thể phát hiện ra rằng một số công cụ, thư viện, cách tiếp cận hoặc tương tự không tốt. Luôn đánh giá trước và yêu cầu nhóm của bạn sử dụng nó sau. Coi chừng tiếp thị giá rẻ xung quanh các công cụ không đạt chuẩn.