Làm thế nào tôi có thể thay đổi văn hóa công ty cẩu thả? [đóng cửa]

Đôi khi khi tôi gặp một vấn đề cần giải quyết, tôi thấy rằng cách dễ nhất để giải quyết nó là viết một chương trình nhỏ như một công cụ cá nhân. Tôi không làm cho nó siêu hữu dụng hoặc siêu mạnh mẽ, vì tôi là người duy nhất sẽ sử dụng nó và tôi không có thời gian để tinh chỉnh nó và kiểm tra kỹ lưỡng.

Sau đó, một đồng nghiệp nhìn thấy chương trình và yêu cầu nó, bởi vì anh ta đã gặp phải vấn đề tương tự và công cụ có thể giúp đỡ. Tôi từ chối trách nhiệm "Nó không đẹp nhưng sẽ hoàn thành công việc" và để anh ấy có nó.

Điều tiếp theo tôi biết, cấp trên của tôi đang gọi cho tôi, nói với tôi rằng anh ta đang cố gắng để phần mềm hoạt động trên máy tính của khách hàng nhưng nó hiển thị thông báo lỗi X. WTF ?? Phần mềm đó chưa sẵn sàng để phát hành, tôi cũng không nói rằng nó cần phải sẵn sàng để phát hành. Nhưng vì một số lý do, cấp trên của tôi nghĩ rằng nó đủ tốt và phát hành nó mà không cần nói với nhà phát triển ban đầu.

Bây giờ, vấn đề đặc biệt này là dễ dàng để khắc phục với a MessageBox.Show("DO NOT GIVE TO CLIENTS!");. Tuy nhiên, vấn đề là dấu hiệu của một vấn đề sâu sắc hơn nhiều: văn hóa công ty của chúng ta rất cẩu thả. Phần mềm cẩu thả là OK và quá trình cẩu thả là OK. Đừng lo lắng về tương lai - hãy nỗ lực vừa đủ để làm cho nó hầu như không hoạt động ngay bây giờ, đặt các tệp nhị phân vào một tệp .zip và gửi nó. Đủ tốt cho công việc của chính phủ

Đây là một công ty nhỏ với 10 nhân viên toàn thời gian, đang phát triển và đã xuất hiện được một thời gian. Đừng hiểu lầm tôi; Tôi thích làm việc ở đây và tôi yêu công ty. Đừng bảo tôi chạy; Tôi muốn trở thành một phần của công ty tốt hơn. Làm thế nào để bạn bắt đầu mang lại sự thay đổi tốt cho loại văn hóa này?

Cách duy nhất để thay đổi là làm cho mọi người khác nhìn thấy nhược điểm của một nền văn hóa cẩu thả và, có lẽ quan trọng hơn là có quản lý mua để sửa nó. Trong thực tế, điều đó không xảy ra và bạn sẽ không thể thay đổi nó. Đó có thể không phải là câu trả lời mà bạn mong đợi được nghe, nhưng sau năm năm cố gắng và thất bại trong một số công việc để thay đổi văn hóa cẩu thả, tôi có thể nói với một số người có thẩm quyền rằng thường không đáng để nỗ lực làm.

Bước đầu tiên sẽ là tìm hiểu xem có ai biết hoặc quan tâm đến văn hóa cẩu thả không; nếu bạn là người duy nhất nhìn thấy bất kỳ vấn đề nào, những nỗ lực của bạn là vô ích.

Bạn có thể cần phải ngồi xuống với đồng nghiệp và sếp và giải thích rằng bạn những gì bạn có là một nguyên mẫu và chưa sẵn sàng cho khách hàng sử dụng. Nếu họ muốn nó sẵn sàng cho khách hàng sử dụng, bạn có thể thực hiện những thay đổi đó trong một thời gian đủ nhưng xin vui lòng không mang những thứ "nhanh và bẩn" và chuyển nó cho khách hàng. Chỉ vì một cái gì đó hoạt động không làm cho nó tốt là bài học để học. Trong khi bạn từ chối trách nhiệm, có một điều cần nói để tôn trọng nó vì nếu không đây là điều có thể xảy ra.

Bạn không thể sửa chữa ngu ngốc. Nếu sếp của bạn đang làm những việc như bạn mô tả thì không chắc bạn sẽ có thể thay đổi điều đó. Đặc biệt nếu anh ta không phải là chủ sở hữu - hãy nhớ rằng, anh ta có áp lực đến từ hướng khác, và hướng đó ký vào séc trả lương của anh ta. Tương tự với các đồng nghiệp khác của bạn. Cách hành động đầu tiên tốt nhất bạn có thể làm là tập thói quen bảo vệ bản thân. Sử dụng các kỹ thuật như hộp thông báo mà bạn mô tả. Giữ tất cả các email. Nhận càng nhiều càng tốt ở dạng viết. Bằng cách này, bạn sẽ không gặp khó khăn khi sự ngu ngốc xảy ra. Sau đó, khi bạn được thăng chức, hãy tạo ra những thay đổi bạn muốn với những người dưới sự giám sát của bạn.

Vào một ngày khác, một đồng nghiệp đã kể cho tôi một câu chuyện về một công cụ kiểm tra đơn giản để cho phép một kỹ sư trong phòng thí nghiệm đưa ra một lệnh duy nhất cho một widget và thay đổi một biến đi theo lệnh. Điều này đã được viết 9 năm trước và cuối cùng anh biết, nó vẫn còn được sử dụng cho đến ngày hôm nay. Một công cụ được viết trong vài giờ với thử nghiệm tối thiểu để chứng minh, trong phòng thí nghiệm, rằng một cái gì đó hoạt động, là cơ sở cho toàn bộ công cụ kiểm tra phòng thí nghiệm kỹ thuật. Một khi bạn viết mã, nó tồn tại. Nếu nó làm điều gì đó hữu ích và được người khác nhìn thấy, mọi người sẽ muốn nó. Nếu nó tốt với những gì nó làm, mọi người sẽ yêu cầu nó làm X. Điều tiếp theo bạn biết, công cụ đơn giản của bạn là một thành phần quan trọng.

Tôi nghĩ rằng trách nhiệm đầu tiên thuộc về nhà phát triển phần mềm để đảm bảo rằng bất kỳ ai nhìn vào mã hoặc sử dụng công cụ đều hiểu rằng đó là nguyên mẫu hay không phải là hệ thống sản xuất và nói tại sao lại như vậy. Có vẻ như bạn đã làm điều đó, tuy nhiên (các) đồng nghiệp của bạn đã bỏ qua việc thực hiện trách nhiệm đó. Để giải quyết vấn đề này, tôi khuyên bạn nên nói chuyện với họ, nhắc lại rằng đây không phải là mã sản xuất và chỉ được viết để tạo thuận lợi cho công việc của bạn. Nếu họ thấy nó hữu ích, có lẽ đề nghị làm việc trên công cụ hoặc hỗ trợ những người khác làm việc trên công cụ để cải thiện nó và làm cho nó phù hợp hơn cho sản xuất.

Theo như quá trình tổ chức hoặc văn hóa thay đổi, hy vọng nó sẽ mất một thời gian. Bắt đầu bằng cách đặt một ví dụ. Nếu bạn chưa đọc Lập trình viên thực dụng , hãy làm như vậy. Hãy lưu ý về các mẹo như Chăm sóc về thủ công của bạn, trở thành chất xúc tác cho sự thay đổi (chỉ cho mọi người những cách tốt hơn), Đừng sống với Windows bị hỏng, khắc phục vấn đề không phải là sự đổ lỗi. Có vẻ như bạn nhận ra một số vấn đề được giải quyết bởi những lời khuyên này, vì vậy hãy bắt đầu làm việc và sống một ví dụ cho các đồng nghiệp của bạn.

Cho đến khi những người ra quyết định không còn thúc đẩy hậu quả của mã xấu và sẵn sàng trả / thay đổi cách khắc phục vấn đề.

Đây là những quyết định khó khăn cho các công ty nhỏ và đang phát triển. Họ không biết đặt mọi nỗ lực vào đâu. Có một rủi ro làm cho mã quá mạnh mẽ khi các quy tắc kinh doanh và đôi khi toàn bộ các ngành nghề kinh doanh xuất hiện, thay đổi và biến mất trong đêm.

Phấn đấu viết mã tốt. Hãy chắc chắn rằng bạn thông báo cho mọi người về hậu quả để họ có thể đưa ra quyết định sáng suốt. Nếu mã xấu được đưa vào sản xuất, hãy theo dõi chặt chẽ nếu bạn có thể và tiếp tục đề xuất cải thiện mã đặc biệt nếu phần đó của doanh nghiệp trở nên quan trọng.

Làm cho mọi người chờ đợi những gì bạn thấy là mã khả thi tối thiểu dường như vượt quá mong đợi hiện tại của họ.

Tôi chỉ ra rằng một phần của vấn đề ở đây là bạn đã viết một công cụ nhanh và bẩn ngay từ đầu. Cấp, có lý do tốt. Cấp, nó đã làm công việc. Nhưng , tôi đã thấy rằng bất cứ điều gì giải quyết vấn đề, sẽ rơi vào cái bẫy của một giải pháp "đủ tốt", nếu bạn bắt đầu giải quyết nó.

Nếu đồng nghiệp của bạn muốn nó, hoặc lịch sự nói với anh ta rằng nó không đầy đủ chức năng và bạn đang giữ chìa khóa. Thỉnh thoảng bạn có thể chạy nó cho anh ấy. Hoặc, thêm chức năng bổ sung, tốt nhất là từ đầu dự án.

Tất cả các công cụ nhanh chóng và bẩn thỉu của tôi tại thời điểm này đến từ một tập tin bộ xương được thử nghiệm rất nhiều. Nó cho phép tôi đi nhanh chóng, cung cấp cho tôi một điểm khởi đầu làm việc và để tôi quên đi việc thêm tất cả các cạnh cùn cần thiết đó. Tôi không phải lo lắng về thư viện getopts và những điều kỳ quặc của nó. Tôi không cần nhớ chi tiết về quản lý bộ nhớ khi tôi sử dụng python. Xây dựng chương trình để nó thực hiện một nhiệm vụ đơn giản và chỉ một . Điều đó giúp dễ dàng kiểm tra nếu họ đang cố gắng uốn cong nó ra khỏi hình dạng.

Cuối cùng, tận dụng kiến ​​trúc máy trạng thái hữu hạn. Nếu bạn biết đi trong tất cả các trạng thái có thể, sẽ dễ dàng hơn nhiều để đảm bảo rằng không có vấn đề gì, người dùng không bao giờ có thể nhảy các bài hát. Tôi có một chương trình mà tôi đã viết để theo mô hình này. Nó chấp nhận các tệp đầu vào tùy ý, mà nó đọc qua từng byte. Ngay cả khi khách hàng bảo nó đọc tệp thực thi nhị phân, nó sẽ không gặp vấn đề gì. Vì nó sẽ không tìm thấy bất cứ thứ gì nó tìm kiếm, nên bộ đệm bên trong sẽ lấp đầy. Điều đó sẽ khiến nó dễ dàng dọn dẹp, đóng cửa và báo cáo với người dùng rằng họ cần tôi xem xét nó.

Chà, câu trả lời không liên quan nhiều đến lập trình, ngoại trừ phần mềm là một thứ tốt mà rất khó để đánh giá chất lượng.

Bạn có thể không thể thay đổi văn hóa, bởi vì mọi người có thể không có động cơ thực sự để không cẩu thả, bởi vì những người bị ảnh hưởng bởi chất lượng phần mềm không liên quan nhiều đến quy trình. Ví dụ, khách hàng của bạn có thể được yêu cầu mua và sử dụng phần mềm để thực hiện công việc của họ, nhưng có ít lợi ích cá nhân về hiệu quả của phần mềm đó, vì cá nhân họ sẽ không bị đổ lỗi cho các vấn đề hoặc phần thưởng cho những ưu điểm của nó (phần lớn bởi vì không ai thực sự biết nếu phần mềm cạnh tranh sẽ tốt hơn). Vì vậy, bạn có thể chỉ phải đáp ứng các yêu cầu tính năng của họ mà không mất quá nhiều thời gian, nhưng không phải lo lắng nhiều về việc liệu nó có lỗi hay không. Vì vậy, tất cả các bạn có thể khá cẩu thả mà không có hậu quả (với bất kỳ ai đưa ra bất kỳ quyết định nào ảnh hưởng đến bạn).

Tôi không biết có phải trường hợp như vậy không, nhưng nếu bạn gặp khó khăn trong việc thay đổi văn hóa vì những người bạn đang cố gắng thay đổi sẽ không thực sự tốt hơn nếu họ làm vậy.

Nếu họ sẽ tốt hơn, bạn có thể có thời gian dễ dàng hơn vì bạn có thể thuyết phục họ tại sao họ lại như vậy. Thật không may, nếu không có một số loại tình hình chính trị mà làm luộm thuộm OK họ có lẽ sẽ không được cẩu thả ở nơi đầu tiên, do đó, nó có thể sẽ khó khăn. Bạn luôn có thể thử lập luận "một ngày nào đó bạn có thể có một công việc đòi hỏi phải làm mọi thứ đúng" (có lẽ nhiều cụm từ ngoại giao hơn ...)