Làm thế nào để đứng vững khi đồng nghiệp đang bỏ bê quá trình?


14

Vấn đề tôi đang gặp phải:

  1. Các thành viên trong nhóm của tôi bắt đầu làm việc trên các dự án mà không có tài liệu kỹ thuật / chức năng sẵn sàng - ngay cả khi quy trình của công ty chúng tôi chỉ ra những điều này nên có trước khi bắt đầu.
  2. Các thành viên trong nhóm của tôi chấp nhận các giải pháp rẻ tiền, không có cấu trúc và sẽ thực hiện các vụ hack thực sự xấu vào phần mềm mà không cần suy nghĩ kỹ khi quản lý dự án lưu ý rằng họ có 'thời gian hạn chế'.
  3. Các thành viên trong nhóm của tôi bắt đầu làm việc với các dự án làm việc cùng với một dự án còn dang dở từ một nhóm khác - chưa được kiểm tra và chưa hoàn thành. (gây ra rất nhiều việc làm thêm).
  4. Các cải tiến và toàn bộ (các) giai đoạn của phần mềm không được lên kế hoạch đúng và thường dẫn đến kết thúc / thiết kế không hoàn thành khi nhà phát triển phụ trợ phải bắt đầu công việc.

Những vấn đề này đã được thảo luận không ngừng trong nhiều lần kể từ khi tôi bắt đầu làm việc ở đây. Mọi người đều đồng ý và điểm mấu chốt là chúng tôi phải thực thi quy trình, điều đó có nghĩa là nhà phát triển back-end sẽ không bắt đầu cho đến khi mọi thứ được quan tâm.

Những vấn đề này cứ tiếp tục xảy ra - và tôi đang thực sự mất động lực đến mức tôi thực sự khó chịu với chính công việc và một số đồng nghiệp của mình.

Các thành viên trong nhóm của tôi phàn nàn rất nhiều - nhưng chỉ hướng về nhau. They keep on going - whatever the situation is. Kết quả?

  1. Tôi phát triển không an toàn, có lẽ đó là tôi?
  2. Đây có phải là cách mọi thứ phải đi?

Câu hỏi của tôi? How can I say no against work ignoring the process if everyone else seems to mindlessly accept?.

Đó là không giống như một số nhà phát triển gây phiền nhiễu, người chỉ tìm kiếm một cái gì đó để làm bitch mọi lúc.


Đây là công việc của QA để đảm bảo rằng quy trình được tuân thủ.
mouviciel

Chúng tôi có quản lý, bán hàng, quản lý dự án và đội ngũ phát triển. QA còn thiếu - thật không may.
Wesley van Opdorp

Vai trò của một quá trình không rõ ràng đối với mọi người, và do đó nó không được áp dụng như bình thường. Đây là lý do tại sao QA tồn tại: để thực thi quy trình. Xác định một quy trình mà không có người chịu trách nhiệm thực thi nó cũng giống như xác định luật mà không có cảnh sát và thẩm phán.
mouviciel

Ông chủ của bạn đã nói gì, khi bạn thảo luận điều này với anh ta?

Câu trả lời:


8

Mọi người đã thực sự đồng ý chưa?

Tôi đã từng có một tình huống, nơi chúng tôi muốn cải thiện các quy trình. Chúng tôi đã tạo ra một quy trình của một Quy trình khác nhau và mọi người dường như đồng ý.

Nhưng sau đó, bất cứ khi nào tôi muốn theo quy trình này, đã được gọi là một ngoại lệ, do 'vấn đề quan trọng hơn', luôn luôn nghe có vẻ hợp lý ngay từ cái nhìn đầu tiên. Vì vậy, trong Hiệu ứng, quy trình không bao giờ được tuân theo thực tế, nhưng mọi người đều nghĩ 'về nguyên tắc, chúng tôi đang theo quy trình'.

Vấn đề là: nếu bạn đề xuất một cải tiến, có ai không đồng ý (ai không thích cải tiến?). Nhưng nếu bạn trình bày các chi phí, thông thường, có nhiều bất đồng. Và mất đi cách thuận tiện để làm mọi việc là một chi phí rất lớn đối với hầu hết mọi người.

Để chứng minh điều đó, tôi đã đặt câu hỏi khác nhau: 'Hãy ưu tiên tất cả những việc tôi phải làm (thực hiện các tính năng, loại bỏ lỗi, tuân theo quy trình cải tiến, dọn dẹp bàn làm việc, đến đúng giờ)'.

Sau khi quá trình kết thúc sau khi làm sạch bàn và không muộn 5 phút. Vì vậy, về cơ bản, họ đã đồng ý với một cái gì đó hoàn toàn khác so với tôi đề xuất.

Vấn đề có thể là, họ không muốn trả chi phí cho chất lượng. Điều đó có thể dẫn họ hợp lý hóa bạn phê bình như rên rỉ, nhưng theo kinh nghiệm của tôi, nó không phải là. Nợ kỹ thuật có thể không nhìn thấy được, và rất dễ để quy nó vào hoàn cảnh, nhưng cuối cùng, thực tế xảy ra.

Hy vọng, đến lúc đó họ mới nhận ra, hoặc bạn đã chuyển Jobs.


2
'theo quy trình được cải tiến' là tùy chọn duy nhất không hướng đến mục tiêu nên kết quả không có gì bất ngờ. Trong bối cảnh này, nó có vẻ giống như "đó là quy trình theo mục đích vì quá trình" và không phải là hoạt động hướng đến mục tiêu (chất lượng cao hơn, năng suất, v.v.).
MaR

"Quá trình cải tiến" là một thời gian ngắn cho những thứ như "thử nghiệm ít nhất là bề ngoài trước khi triển khai", và đó định hướng mục tiêu: mục tiêu là giảm công việc cần thiết để dọn dẹp mọi thứ sau đó, đó là điều không thể tránh khỏi. Không phải là tôi kéo một quá trình ra khỏi không khí mỏng và biến nó thành giáo điều. Nó bắt nguồn từ các vấn đề định kỳ ảnh hưởng đến năng suất. Những gì tôi gọi là 'quá trình' trong bài đăng này ít nhiều để theo dõi 2 hoặc ba mục kiểm tra của joel.
keppla

1
điều tôi muốn chỉ ra là vấn đề là bạn bán "quy trình" như thế nào. Tôi muốn nói "kiểm tra ít nhất là bề ngoài trước khi triển khai" sẽ đạt điểm cao hơn nhiều so với "theo quy trình cải tiến" so với "làm sạch bàn".
MaR

@MaR: Tôi đồng ý, tôi đã bỏ qua khía cạnh đó trong bài viết của mình. Trong công việc, tôi không nói 'làm ơn làm theo quy trình', nhưng nhiều thứ như 'chúng tôi đã đồng ý, rằng chúng tôi phải kiểm tra trước, để tránh làm phiền khách hàng hơn nữa với dịch vụ bị hỏng, một lần nữa. Tại sao bây giờ chúng ta bỏ qua điều đó? '
keppla

3

Có lẽ đó là bạn

Bạn dường như ủng hộ một cách mã hóa có cấu trúc và có tổ chức, các đồng đội của bạn dường như có cách tiếp cận "hoàn thành công việc" hơn. Bây giờ bạn đề cập rằng nó dẫn đến rất nhiều "lãng phí thời gian" vì vậy có lẽ một số cấu trúc theo thứ tự và không có lý do gì cho công việc cẩu thả. Tuy nhiên, các dự án phần mềm có xu hướng trôi chảy và thực thi quá nhiều cấu trúc cũng sẽ gây ra nhiều chi phí tổ chức.

Có lẽ tất cả bạn nên gặp nhau ở giữa và thử một cách tiếp cận nhanh nhẹn và tương tác hơn, nhưng có cấu trúc.


1
Nếu các đồng đội không thích cách tiếp cận 'của anh ấy', tại sao họ lại đồng ý ngay từ đầu? Đọc bài đăng của anh ấy, tôi không có ấn tượng gì, đó chỉ là đề xuất của anh ấy. Và, ngay cả một phê duyệt chất lỏng không hoạt động mà không có thông số kỹ thuật, sự khác biệt theo ý kiến ​​của tôi không phải là sự vắng mặt, mà là đặc tính tạm thời rõ ràng của thông số kỹ thuật.
keppla

Trước hết, không đồng ý với điều gì đó không giống như cam kết với điều gì đó :) Có lẽ đồng đội của anh ấy không thấy bất kỳ sự thay thế nào khác. Ngay cả khi quy trình là ý tưởng quản lý, có lẽ nó cần một số sự thích ứng với thực tế để đảm bảo mua lại của tất cả các bên. Tôi đồng ý rằng cần phải có một số thông số kỹ thuật nhưng không may đôi khi chỉ định một cái gì đó có thể khó khăn như việc xây dựng nó. Một quy trình lặp, nhanh nhẹn có thể cho phép đặc tả kết tinh khi chúng đi cùng
Homde

Ông tuyên bố rõ ràng, rằng nhóm của ông đã đồng ý, không phải là họ không đồng ý. Xin đừng hiểu sai ý tôi, tôi không chống lại các quy trình nhanh, nhưng chúng cũng chỉ là: các quy trình, cần ít nhất một cam kết cơ bản. Nếu tất cả mọi người bỏ qua Standup, không ai giữ được Backlog, 'thông số kỹ thuật' chỉ là 'bằng cách này ...' người ta sẽ nhận được trong khi vượt qua người quản lý, ngay cả một quy trình nhanh nhẹn cũng chết. Và, theo kinh nghiệm của tôi, đó thậm chí còn không vẽ một bức tranh đen. Không phải mọi công ty đều là google. Hầu hết dường như reseble Dilbert chặt chẽ hơn.
keppla

2
Tôi đồng ý, họ cần tìm một quy trình mà mọi người đều có thể mua vào. Thỏa thuận ngầm không có giá trị gì. Có lẽ họ cần phải thử nghiệm và xem những gì hiệu quả với họ, hoặc là đồng đội của anh ta đơn giản là không đủ năng lực và cần phải bị sa thải :) Tôi đã nhận thấy một điều về các quy trình mặc dù ngay cả khi có mua thì cũng cần phải ít nhất "Process-nazi" đảm bảo quá trình trở thành thói quen. Chỉ hoạt động nếu quy trình có mua vào
Homde

... Btw, tôi sẽ không sử dụng google làm ví dụ điển hình cho quy trình. Họ dường như phải chịu đựng một trường hợp nghiêm trọng của kỹ sư do nhiều chi phí cấu trúc. Lần cuối tôi nghe nói họ đang cố gắng lấy lại nguồn gốc khởi nghiệp của mình
Homde

2

Ai chịu trách nhiệm cho những người này? Ai đó đã thuê họ và ai đó có thể sa thải họ / giữ họ có trách nhiệm.

"Công ty của tôi yêu cầu ..." là vô nghĩa nếu không có sự thực thi.

Bạn không thể yêu cầu thời gian mà không cho phép quá trình sản xuất.

Có vẻ như sự thiếu kiểm soát này và kỳ vọng không thực tế là lý do cho chất lượng kém.

Bạn có thể: rời đi, trở thành nhà phát triển chính, không làm gì hoặc bắt đầu làm việc với những người cảm thấy theo cách bạn làm. Hãy chắc chắn rằng mọi người đều biết bạn sẽ làm theo đúng quy trình cho đến khi ai đó tìm ra cách tốt hơn và thay đổi chúng. Âm thanh như "Quy tắc nhà Cider."


2

Có vẻ như bạn không muốn đồng nghiệp của mình tuân theo một quy trình hoàn toàn khác, bạn chỉ muốn họ đưa ra quyết định khác nhau trong đó. Chắc chắn, có những quy tắc (hướng dẫn?) Về những gì họ nên làm, và họ bỏ qua chúng. Nhưng vấn đề bạn mô tả là họ phải đưa ra quyết định (để bắt đầu làm việc với dự án hoặc từ chối một đặc tả) và họ quyết định tiếp tục. Quyết định đó sẽ không thay đổi nếu bạn tiếp tục nhắc nhở họ về các quy tắc; họ không quan tâm nhiều đến các quy tắc như bạn làm . Họ muốn cảm thấy hữu ích, và nói không không làm cho họ cảm thấy hữu ích .

Nếu bạn muốn hành vi của họ thay đổi, thì việc liên tục nhắc nhở họ về các quy tắc có lẽ không hiệu quả lắm; nó có nhiều khả năng dẫn đến họ bỏ qua bạn. Cố gắng tìm cách thay đổi quy trình để khiến họ cảm thấy hữu ích hơn trong khi vẫn tuân theo quy trình. Bạn có thể thực hiện một số loại đánh giá mã, kiểm tra mã của nhau và học hỏi lẫn nhau để ngăn chặn việc hack thành mã sản xuất không? Bạn có thể thay đổi cách các thông số kỹ thuật (docs / ext.interfaces / front-end) được xử lý từ một quyết định kết thúc / chưa hoàn thành đen trắng thành một quy trình hợp tác hơn, trong đó gần cuối của đặc tả mà nhà phát triển được yêu cầu giúp hoàn thành? (Và, bạn nên chấp nhận rằng các yêu cầu sẽ thay đổi)

Chủ yếu không phải bạn, không phải họ, đó là quá trình. Nếu bạn (và PM của bạn) có thể tìm ra cách nào đó để tổ chức những thứ mà mọi người không phải đi ngược lại với tính cách của họ rất nhiều, quá trình sẽ được thực hiện nhanh hơn nhiều.


2

Đây là về điểm mà tôi sẽ đăng ký với phiên họp kín với trưởng nhóm của mình. Hy vọng rằng bạn có một mối quan hệ làm việc đủ tốt với người lãnh đạo mà bạn có thể làm cho điều đó rất không chính thức.

Mục đích của cuộc họp là tìm hiểu lý do tại sao nhóm làm việc theo cách họ đang làm. Nếu mọi người đã cùng nhau, gật đầu, mỉm cười và đồng ý với một quy trình mới, vậy tại sao họ vẫn không thay đổi? Rất có thể là nó chạy sâu hơn rất nhiều so với việc không quan tâm hoặc không đủ năng lực. Có khả năng có những người lái xe đang làm việc mà mắt thường không nhìn thấy được.

Bắt đầu cuộc họp giả định rằng đồng nghiệp của bạn sẽ, nếu có thể, sẽ tuân theo một quy trình dẫn đến ít hoảng loạn hơn, nợ kỹ thuật ít hơn và chất lượng sản phẩm lớn hơn - sau tất cả, ai không muốn điều đó? Vậy lực lượng vô hình là gì?

Có vẻ như có rất nhiều triển khai / tích hợp trước khi hoàn thành công việc thiết kế và nguyên mẫu UI. Công ty có thiếu những người có thể làm công việc trả trước đó không? Có lẽ bạn có thể tình nguyện. Có một vấn đề nhận được sự đồng thuận với các bên liên quan? Có lẽ nhóm của bạn có thể tìm ra một cách giao tiếp mới với họ hoặc có thể thực hiện một cách tiếp cận mới để ghi lại các giả định.

Nếu bạn bắt đầu với từng người một, nơi bạn hỏi người dẫn đầu của bạn tại sao sau đó bạn có thể mở ra một cuộc thảo luận để tránh sự phòng thủ và tập trung vào các vấn đề và giải pháp.

Một mẹo khác có thể là hỏi xem bạn có thể tiên phong một cách làm việc mới không. Nhận được sự ủng hộ từ nhóm của bạn để buộc vấn đề một chút và cho phép bạn thực hiện phương pháp mà bạn ủng hộ - nó có thể sẽ đưa ra các vấn đề khi bạn vứt bỏ "hệ thống", vì vậy bạn muốn ban quản lý đứng sau bạn. Nhưng nếu bạn trở nên năng suất hơn và không căng thẳng, bạn sẽ cung cấp một trường hợp tốt để thay đổi cách thức của mọi thứ, và bạn có khả năng giành được những người ủng hộ.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.