Làm thế nào để tôi đối phó với một đồng nghiệp chậm chạp và thiếu quyết đoán trong đội? [đóng cửa]

Tôi đã làm việc trên một dự án mới. Dự án hoạt động như thế này: Người dùng cuối có thể truy cập webapp bằng liên kết và anh ta có thể thêm nhiều hệ thống trên mạng của mình và quản lý chi tiết hệ thống cụ thể đó. Phần của tôi liên quan đến giao diện người dùng và máy chủ web, được thực hiện bằng python. Con trăn của tôi thực sự giao tiếp với một dự án khác hoàn toàn được thực hiện trong c & c ++. Dự án c / c ++ là ứng dụng chính thực hiện tất cả các chức năng. Con trăn của tôi gửi yêu cầu người dùng đến nó và hiển thị phản hồi từ nó cho người dùng.

Tôi rất quen thuộc với công việc của mình và tôi sẽ hoàn thành nó sớm thôi. Vì đó không phải là nhiều công việc trong đó. Và tôi là một người thích làm việc. Tôi dành phần lớn thời gian ở văn phòng và chỉ về nhà khi cảm thấy buồn ngủ.

Ứng dụng c / c ++ được quản lý bởi một đồng nghiệp khác có hơn 5 năm kinh nghiệm và có thể làm mọi việc nhanh hơn tôi rất nhiều, nhưng anh ta không bao giờ làm điều đó. Có thể anh ấy không thích làm điều đó. Ứng dụng của anh gặp sự cố thường xuyên khi con trăn của tôi giao tiếp với nó hoặc trả về các giá trị sai. Nó đầy lỗi. Vì ứng dụng của tôi phụ thuộc vào nó, tôi gặp khó khăn khi xây dựng nó. Thay vì sửa các lỗi, anh ấy yêu cầu tôi làm chậm công việc của mình. Anh ấy yêu cầu tôi nói với người quản lý rằng công việc của tôi cần rất nhiều thời gian. Anh ta đang yêu cầu tôi đánh lừa người quản lý và thậm chí buộc tôi phải làm việc chậm chạp như anh ta.

Trong cuộc họp dự án, khi người quản lý hỏi anh ta về các lỗi, anh ta nói rằng anh ta đã sửa mọi thứ và nó hoạt động tốt. Vì anh ấy là đồng nghiệp của tôi, tôi không thể nói bất cứ điều gì với người quản lý. Tôi rõ ràng cần phải có mối quan hệ tốt với các đồng nghiệp của mình hơn người quản lý của mình, vì hầu hết thời gian chúng tôi sẽ ở bên đồng nghiệp chứ không phải với người quản lý.

Tôi không thể nói với người quản lý bất cứ điều gì liên quan đến việc này, vì nếu người quản lý hỏi anh ta tại sao, thì anh ta có thể nghĩ rằng tôi đã phàn nàn về anh ta với người quản lý. Và anh cứ nằm trong cuộc họp. Và vì anh ấy sửa lỗi từ từ, nó thậm chí còn làm chậm công việc của tôi. Bây giờ tôi đã nghĩ đến việc làm việc trên phần đầu của ứng dụng của mình và hoàn thiện nó để trong thời gian đó anh ấy có thể làm cho dự án của mình ổn định. Bây giờ anh ấy đang yêu cầu tôi nói với người quản lý rằng phần trước của tôi đòi hỏi rất nhiều công việc và tôi có thể cần nhiều thời gian hơn, đơn giản là để anh ấy có thể kéo dự án xuống. Và điều đáng buồn là người quản lý thực tế của chúng tôi đã đến Mỹ, vì vậy chúng tôi có một người quản lý tạm thời và anh chàng này không biết nhiều về dự án, vì vậy c, c ++ chỉ đánh lừa anh ta.

Bất cứ ai có thể đề nghị tôi làm thế nào tôi đối phó với điều này? Tôi muốn kết thúc dự án sớm. Làm thế nào tôi có thể làm cho anh ta làm việc ngay cả bằng cách duy trì một mối quan hệ tốt với anh ta?

Phản hồi ý kiến:

Nếu anh ta thực sự cố tình lừa dối công ty, bạn nên báo cáo anh ta cho quản lý.

Tôi mới đến công ty này và anh chàng kia đã ở đó nhiều năm. Và tôi mới bắt đầu biết các đồng nghiệp của mình. Nếu tôi trực tiếp đi và phàn nàn anh ta, tôi không nghĩ rằng tôi có thể tạo mối quan hệ tốt với các đồng nghiệp khác. Thậm chí anh ta có sức mạnh để đánh lừa họ. Tôi không nói anh ta là một kẻ xấu, anh ta có thể làm việc, nhưng anh ta không làm việc đó.

Công ty của bạn không có bất kỳ loại hệ thống theo dõi lỗi?

Ở đây hệ thống theo dõi lỗi thực tế không có ở đó. Công ty cố gắng hoàn thành dự án càng sớm càng tốt và đưa nó cho QA. Và sau đó sửa các lỗi được báo cáo bởi QA.

Đây là lý do tại sao các công ty nên cung cấp cho nhân viên cổ phiếu / quyền chọn hoặc một số loại quyền sở hữu. Bằng cách đó, bạn có thể nói với anh chàng theo nghĩa đen "Bạn đang làm tôi tăng trưởng tiền tệ ... bạn cũng không muốn kiếm tiền à?".

Công ty có các lựa chọn cổ phiếu mà họ đã cho tôi 2500 cổ phiếu, chủ yếu là ông cũng sẽ có thêm một số.

Thâm niên không xứng đáng với một số lợi ích của sự nghi ngờ. Bạn thực sự cần nói chuyện với anh ấy trước và cố gắng hiểu vấn đề. Anh ta có thể ra khỏi chiều sâu của anh ta, bạn có thể giúp anh ta, có thể dễ dàng có các biến bạn không biết. Bây giờ có thể khó khăn, nhưng bạn có thể dễ dàng làm cho tình hình tồi tệ hơn nhiều bằng cách nhảy súng.

Tôi thậm chí còn làm điều đó, đầu tiên ứng dụng của anh ấy không xử lý nhiều yêu cầu cùng một lúc, anh ấy đang sử dụng một hàng đợi để xử lý các yêu cầu tôi gửi cho anh ấy. Tôi thậm chí còn gợi ý cho anh ấy một số ý tưởng của tôi về nó. Ông nói rằng ông đã có những ý tưởng này, và sẽ thực hiện chúng. Giải thích của ông là: "Mọi thứ cần có thời gian nhất định để thực hiện và đây là một dự án có thể cần hai năm để hoàn thành và chúng tôi được yêu cầu hoàn thành nó trong hai tháng". Tôi đã từng có một thời gian khó mã hóa trong vài tuần đầu tiên vì lỗi này. Nhưng bây giờ anh ấy đã sửa nó. Nhưng anh ta đang sử dụng một hàng đợi duy nhất cho một yêu cầu của người dùng và điều đó hiện đang làm chậm ứng dụng, vì nó xử lý một yêu cầu tại một thời điểm.

QA đang làm gì trong suốt thời gian này? Tại sao họ không báo cáo / xác nhận trạng thái của (các) dự án?

Người quản lý là người quyết định khi nào nên đưa cho QA. Cho đến bây giờ nó vẫn chưa được trao cho QA. Ông nói chúng ta nên cho nó vào cuối tháng này.

Bạn đang ở trong một tình huống tồi tệ, tôi sẽ không muốn ở trong đôi giày của bạn. Không chắc là bạn có thể sắp xếp nó mà không gây xung đột với đồng nghiệp.

Đây là những gì tôi sẽ làm:

• Đừng trở thành đối tác của anh ta trong tội ác. Từ chối nói dối về tình trạng của dự án của bạn hoặc dự án của anh ấy.

• Thực hiện (trong thời gian rảnh nếu cần thiết) báo cáo lỗi cho ứng dụng của bạn, vì vậy tất cả các lỗi được gửi qua email đến đồng nghiệp và người quản lý của bạn. Nếu lỗi do ứng dụng của anh ta gây ra, hãy hiển thị nó trong email (đặt [XYZ APP BUG] trong chủ đề email hoặc một cái gì đó).

• Duy trì cơ sở dữ liệu lỗi (bên cạnh việc gửi lỗi qua email). Bạn có thể nói rằng mục đích chính của nó là theo dõi các lỗi của bạn , trong khi thực tế bạn sẽ theo dõi hầu hết các lỗi của anh ấy . Trong số những thứ khác, cần theo dõi mất bao lâu để sửa lỗi cụ thể.

• Có tất cả các giao tiếp giữa các quá trình với ứng dụng của anh ấy được bao phủ bằng các bài kiểm tra ("khi tôi gửi cho bạn cái này, bạn nên trả lại cho tôi kiểu đó"). Bạn có thể thiết lập một tác vụ cron chạy các bài kiểm tra này mỗi ngày và nếu chúng thất bại, email sẽ được gửi cho mọi người.

Về cơ bản, cố gắng không lãng phí thời gian của bạn để tranh luận với anh ấy về lỗi và thay vào đó tập trung vào công việc của bạn. Nếu ứng dụng của anh ấy bị hỏng và do đó bạn không thể làm việc trên ứng dụng của mình và người quản lý sẽ không làm gì với nó - tốt, đó là vấn đề quản lý và bạn được bảo vệ với cơ sở dữ liệu lỗi, email và báo cáo thử nghiệm.

Tuy nhiên, coi chừng và đừng đánh giá thấp anh ta. Kẻ lười biếng lâu năm như anh ta có thể có một mẹo hoặc hai tay áo lên. Anh ta có thể khiến cả đội chống lại bạn hoặc một cái gì đó, nhưng điều đó phụ thuộc vào tình huống cụ thể của bạn và nó nằm ngoài phạm vi của câu hỏi này.

Tôi sẽ đưa ra một quan điểm hơi gây tranh cãi: Bạn nói rằng bạn đang làm việc nhiều giờ như bạn có thể tỉnh táo. Vì vậy, có lẽ anh ấy không đặc biệt bất công khi nói "bạn đang làm cho tôi trông tệ và tôi thực sự làm việc nhiều giờ như tôi muốn." Có lẽ anh ta đã ở đó và làm điều đó và có thể anh ta bị kiệt sức. Tôi hứa với bạn rằng bạn sẽ làm nếu bạn tiếp tục.

Đi ra ngoài uống nước với anh ấy một đêm và xem liệu bạn không thể xây dựng mối quan hệ cá nhân tốt hơn để dựa vào chuyên môn của mình. Có thể bằng cách anh ấy đồng ý đưa thêm một chút và bạn đồng ý đưa vào ít hơn một chút, cả hai bạn có thể làm việc với nhau tốt hơn nhiều.

Nếu tôi là bạn, tôi cũng sẽ rất cẩn thận với toàn bộ thái độ "công việc, công việc của bạn" này. Giữa hai bạn, bạn có một sản phẩm để ra khỏi đó và điều này có thể không tốt cho sản phẩm đó, điều này không tốt cho cả công ty hoặc khách hàng và họ trả tiền cho cả hai bạn làm việc .

Tuy nhiên, tôi vẫn đồng ý với các quan điểm khác rằng bạn cần xem lại tầm quan trọng của mối quan hệ với người quản lý của bạn và bạn cần cẩn thận khi tin tưởng đồng nghiệp của mình. Tôi chỉ nói rằng có lẽ, chỉ là có thể, bạn cần nhìn vào hành động của chính bạn cũng như của anh ấy.

Giữ hồ sơ. Ghi lại mọi lỗi bạn gặp phải khi liên lạc với phía anh ấy, khi bạn yêu cầu anh ấy sửa chữa và khi nào (nếu có) anh ấy đã làm điều đó. Đó là cách duy nhất tôi biết để đối phó với tình huống này. Vì vậy, khi người quản lý của bạn đến gặp bạn hỏi tại sao mọi thứ không tiến triển, bạn có thể thể hiện rõ ràng mà không bị coi là một người đánh cá hay một đồng nghiệp xấu.

Tôi muốn chỉ ra một khả năng khác chưa được nêu ra. Bạn nói rằng anh ấy muốn bạn làm chậm công việc của bạn. Bạn có nghĩa là anh ấy đang nói "làm việc ít giờ hơn" hoặc anh ấy đang nói "viết một số bài kiểm tra, kiểm tra thêm, viết một số tài liệu" và những điều khác bạn nghĩ sẽ làm bạn chậm lại? Tôi đã thấy những người mới chạy xung quanh viết mã trong 16 giờ mỗi ngày và sau đó phàn nàn về các lỗi trong mã họ đang gọi khi thực tế họ đang truyền tham số không hợp lệ, họ không kiểm tra giá trị trả về, v.v. Tôi không thể loại trừ rằng đồng nghiệp của bạn đang nghĩ về những điều này.

Lần tới khi bạn đang họp và anh ấy nói tất cả mã của anh ấy đều ổn, hãy nói "ồ, tốt, điều tôi đã nói với bạn khoảng một giờ trước, nơi nó nổ tung khi tôi gọi XYZ với một ngày không phải là ngày làm việc, đã được sửa chưa? " Một trong ba điều sẽ xảy ra:

• Anh ta sẽ nói dối, và nói rằng không có vấn đề như vậy, bạn sẽ nói "có như vậy! Chúng tôi đã thảo luận về nó! Tôi đã gửi email cho bạn!" và toàn bộ sự việc sẽ đến sự chú ý của người quản lý
• Anh ấy sẽ nói với bạn rằng trên thực tế, đó không phải là lỗi trong mã của anh ấy, đó là lỗi trong mã của bạn, bởi vì bạn chỉ cần vượt qua ngày làm việc và bạn sẽ sớm tìm ra những gì anh ấy đã nghĩ nhưng không nói
• Anh ta sẽ nói "không, người mà anh vừa nói với tôi về việc tôi sẽ giải quyết hôm nay, nhưng mọi thứ khác đều tốt." Nếu anh ấy nói điều đó, chỉ cần cảm ơn anh ấy bây giờ.

Bạn có thể biết rằng những ngày dài mã hóa nhanh của bạn không tạo ra mã tốt và ai đó (người quản lý của bạn có thể) có thể dịch cho nhà phát triển khác để giải thích cho bạn vấn đề là gì. Hoặc, bạn có thể biết rằng bạn đang làm việc với một con rắn nói dối, người sẽ khiến bạn trông xấu để bảo vệ vị trí cushy của anh ta. Đưa mọi thứ ra ngoài không thể thực sự làm điều đó tồi tệ hơn. Hoặc, bạn có thể nhận được đủ chuyển động từ anh ta mà bạn có thể chịu đựng được, mà không bị cuốn vào chính trị.

Những gì bạn có là một vấn đề chính trị. Đầu tiên, ý kiến ​​của người quản lý của bạn là rất xa, quan trọng hơn nhiều so với bạn nghĩ. Anh chàng này đang đổ lỗi cho bạn về sự chậm trễ và bạn đang để anh ta. Bạn là người sẽ bị đuổi việc nếu ai đó bị ném xuống dưới xe buýt. Theo như người quản lý biết, bạn là người không có khả năng thực hiện công việc kịp thời.

Bảo vệ bản thân theo bất kỳ cách nào bạn có thể, thông qua theo dõi lỗi, email, v.v., nhưng KHÔNG đi cùng với giả vờ đây là sự chậm trễ của bạn không phải của anh ấy. Không bao giờ đưa cho sếp một báo cáo tình trạng giả, nó sẽ quay lại cắn bạn. Nói với sếp sự thật về những vấn đề bạn gặp phải (và đưa ra bằng chứng) với mã của anh ta không hoạt động.

Người này đang yêu cầu bạn buông lơi để anh ta trông không tệ là một con rắn (đó là một sự xúc phạm đối với cộng đồng rắn (tham khảo Firefly tinh tế), xin lỗi tất cả những con rắn thực sự ngoài kia). Anh ta sẽ làm bất cứ điều gì để ném bạn dưới xe buýt thay vì anh ta. Không tin tưởng anh ấy.

Đầu tiên và quan trọng nhất:

Vì anh ấy là đồng nghiệp của tôi, tôi không thể nói bất cứ điều gì với người quản lý.

Bạn hoàn toàn có thể và nên chắc chắn rằng người quản lý của bạn biết sự thật, ngay cả khi đồng nghiệp của bạn đang nói dối. Nếu bạn không muốn nói bất cứ điều gì trong một cuộc họp với cả 3 bạn trong phòng, điều đó hoàn toàn dễ hiểu. Nhưng ít nhất bạn nên kéo người quản lý của mình (người thực sự chứ không phải tạm thời) sang một bên và cho họ biết rằng công việc của bạn sắp hoàn thành và đang chờ sửa lỗi từ đầu của nhà phát triển khác trước khi toàn bộ ứng dụng sẵn sàng cho thời gian chính . Đừng buộc tội đồng nghiệp của bạn nói dối, nhưng đừng ngồi đó và để sếp của bạn hoạt động với thông tin không đầy đủ.

Báo cáo tình trạng của bạn một cách trung thực. Nếu công việc của bạn đang bị các lỗi phát sinh ở đầu phát triển khác, tài liệu mà bạn đã tìm thấy lỗi trong C / C ++ và đã báo cáo chúng (vui lòng cho tôi biết bạn đang sử dụng một số dạng tài liệu để lại dấu vết giấy).

Trong lúc này, hãy tiếp tục và kết thúc công việc của bạn, và cho sếp của bạn biết khi nào bạn hoàn thành. Nếu người quản lý của bạn muốn biết lý do tại sao phần còn lại của dự án chưa hoạt động, bạn có thể giới thiệu anh ta với nhà phát triển khác và có thể đề cập rằng có lẽ rất phức tạp / lớn / yêu cầu rất nhiều thử nghiệm / nhà phát triển khác rất bận / v.v. Nếu bạn biết C / C ++, bạn có thể đề nghị trợ giúp về logic ứng dụng chính để giúp mọi thứ chuyển động theo đó. Vâng, bạn sẽ làm công việc của người kia, nhưng điều đó rõ ràng rằng bạn là nhân viên làm việc chăm chỉ và làm việc hiệu quả, còn anh chàng kia thì không, không đề cập đến việc khiến bạn trở nên có giá trị hơn với sếp. Nó thậm chí có thể gây áp lực lên nhà phát triển khác để đẩy mạnh mọi thứ và hoàn thành chúng nhanh hơn.

Có một số vấn đề trong công việc. Hãy lưu ý rằng:

1. Bạn đang đưa ra giả định về động lực của người khác
2. Bạn đang tô màu sự thật với ý kiến.
3. Người ngoài cuộc (bất kỳ ai khác) không biết về lịch sử và không nhận thức được sự thất vọng của bạn với đồng nghiệp.
4. Bạn có thể trông trẻ con nếu có vẻ như bạn đang chơi một trò chơi "gotcha". Đồng nghiệp của bạn có thể chơi nó tốt hơn - sau tất cả, anh ta vẫn có một công việc phải không?

Do đó, khi trình bày trạng thái của dự án của bạn:

1. Đừng nhắc đến người khác.
2. Khi báo cáo lỗi hoặc sự cố với mã - không phải nhà phát triển. Nói "Cuộc gọi đến phương thức FooBar () đang trả về 1 khi nó sẽ trả về 2". Sau đó, bất kỳ vấn đề không phải là một cuộc tấn công cá nhân, bạn chỉ đang nói về mã - không phải người.
3. dính vào sự thật mà bạn có bằng chứng cho.
4. Nếu đồng nghiệp của bạn bị phòng thủ hoặc thù địch, hãy đặt câu hỏi. "Tôi không hiểu tại sao bạn nghĩ rằng tôi nên làm _ "
5. Hãy quên lãng những nô lệ xã hội hoặc những người vô tội. Giả vờ bạn không nhận được cuộc tấn công cá nhân.
6. Ngủ nhiều vào buổi tối trước bất kỳ cuộc họp trạng thái nào, vì vậy bạn nhanh nhẹn về mặt tinh thần.
7. Tài liệu, tài liệu, tài liệu.
8. Đừng ngại yêu cầu anh chàng này giúp bạn một số vấn đề thú vị, anh ta có thể đưa bạn đến nếu anh ta cảm thấy rằng bạn tôn trọng anh ta. Đây là về xây dựng mối quan hệ. (lưu ý đây không phải là hút lên - đây là một cái gì đó khác)
9. Hãy chuẩn bị rời đi nếu bạn phải như vậy, theo cách đó bạn không cần thiết hoặc bị mắc kẹt trong tình cảm. Điều này sẽ giúp giữ đầu của bạn trong các cuộc họp.

"Tôi là một người thích làm việc. Tôi dành phần lớn thời gian ở văn phòng và chỉ về nhà khi cảm thấy buồn ngủ."

Điều này không lành mạnh và không thể được các đồng nghiệp mong đợi, trừ khi bạn được đền bù đến mức có thể nghỉ việc nhiều năm vì sự kiệt sức không thể tránh khỏi. (Một cái gì đó như quyền sở hữu> 10% trong công ty hoặc trên $ 200ka năm). Duy trì chuyên môn để đi đến điểm mà anh ta có thể phát triển rất nhanh cần có thời gian. Một số thời gian của bạn nên được dành cho việc phát triển chuyên môn.

"Dự án c / c ++ là ứng dụng chính thực hiện tất cả các chức năng. Con trăn của tôi gửi yêu cầu người dùng đến nó và hiển thị phản hồi từ nó cho người dùng. ... Có thể anh ta không thích làm điều đó."

Python là ngôn ngữ nhanh nhẹn hơn C / C ++. Ứng dụng của ông dường như chứa tất cả các chức năng; ứng dụng của bạn chỉ là UI. Nhiều khả năng hơn không, đây không phải là khó khăn bằng nhau. Anh ta có thể không được sản xuất mã một cách nhanh chóng; nhưng mã hóa chất lượng tốt hơn nhiều so với mã hóa số lượng. Bạn rất có thể có những kỳ vọng không thực tế về việc anh ấy có thể viết mã nhanh như thế nào trong những giờ anh ấy sẵn sàng / dự kiến ​​làm việc (thường là ~ 40 giờ một tuần và hãy nhớ rằng nếu anh ấy ở đó trong nhiều năm, anh ấy có thể tích lũy các nhiệm vụ khác như quản lý người khác hoặc giúp duy trì tuổi già các dự án chiếm một phần đáng kể trong tuần làm việc).

Đừng nói dối anh ta; Nhưng một lần nữa đừng chỉ trích anh ấy. Nói về cách hệ thống của anh ấy tuyệt vời; cấp nó cần nhiều công việc hơn cho đến khi nó hoàn thành. Cung cấp cho người quản lý của bạn một bản cập nhật trạng thái chính xác mà không cần đặt tên / gán lỗi. Viết một phiên bản giả lập của hệ thống của anh ấy phù hợp với cùng tiêu chuẩn mà hệ thống của anh ấy phải tuân thủ. Đảm bảo hệ thống của bạn hoạt động hoàn hảo với hệ thống giả lập của bạn với bộ kiểm tra tự động. Sau đó, hệ thống của bạn có thể được hoàn thành (ví dụ, nó đồng bộ hóa hoàn hảo với mô hình giả), ngay cả khi hệ thống trực tiếp vẫn bị lỗi.

Sau đó, bạn có thể viết một bộ kiểm tra tự động cho hệ thống của mình được gọi bên ngoài phù hợp với các tiêu chuẩn đã thỏa thuận. Ví dụ: kiểm tra hơn Foo (1,2,3) trả lời phản hồi của "Bar 4 5 6". Điều này có thể giúp anh ta xác định các lỗi và tăng tốc độ phát triển của mình (và không cần phải làm rối mã của anh ta). Khi những điều đó được thực hiện, bạn sẽ có thể chuyển sang một dự án / nhiệm vụ khác (chẳng hạn như giúp anh ta với các phần C / C ++).

Như những người khác đã đề cập, cư xử chuyên nghiệp là điều quan trọng nhất cho sự nghiệp lâu dài của bạn. Và thành thật mà nói, miễn là bạn cư xử chuyên nghiệp, bạn sẽ ở trong tình trạng khá tốt, bất kể những người xung quanh cư xử thế nào.

Trong tình huống này, có một vài cân nhắc bạn cần tính đến.

Trước tiên, bạn cần hiểu rằng bạn chịu trách nhiệm cho chương trình của bạn làm việc theo các thông số kỹ thuật mong muốn, theo thời hạn nhất định. Nếu chương trình của bạn tương tác với chương trình của người khác, bạn cũng có trách nhiệm đảm bảo rằng chương trình khác cũng hoạt động theo cùng thời hạn. Nói cách khác: Nếu người khác bỏ lỡ thời hạn của họ, thì bạn cũng đã bỏ lỡ thời hạn, ngay cả khi một phần của dự án của bạn đã đúng hạn. Trong thuật ngữ quản lý, điều này được gọi là sở hữu các đầu vào .

Bạn đã lưu ý chính xác rằng khi đồng nghiệp của bạn tuyên bố trong một cuộc họp rằng các lỗi chương trình của anh ta đã được sửa, bạn không thể ngay lập tức tuyên bố anh ta không đúng với người quản lý (người quản lý của bạn sẽ xem đó là "ném đồng nghiệp của bạn xuống xe buýt"; một sự nghiệp rất xấu). Mặt khác, đã chỉ ra rằng thật không chuyên nghiệp khi không tuyên bố trạng thái thực sự của dự án cho người quản lý. Cả hai bên đều hoàn toàn chính xác.

Vì vậy, nếu nó xấu khi mâu thuẫn với đồng nghiệp của bạn trước mặt người quản lý, và cũng không tệ khi không mâu thuẫn với anh ta, vậy bạn sẽ làm gì?

Câu trả lời thực sự khá đơn giản: Bạn cần nói chuyện với đồng nghiệp của mình thật tốt trước cuộc họp với người quản lý và cho họ biết rằng tại cuộc họp sắp tới, bạn sẽ cần nói với người quản lý về những rắc rối bạn gặp phải chương trình của họ và điều đó ảnh hưởng đến khả năng bạn giao dự án của bạn đúng hạn và liệu bạn có thể làm gì để giúp họ giải quyết những rắc rối bạn gặp phải. Bạn cần có cuộc trò chuyện này ít nhất hai ngày trước cuộc họp, nơi bạn sẽ nói với người quản lý, và tốt nhất là trước cả tuần.

Trong hầu hết các trường hợp, chỉ cần nói với đồng nghiệp của bạn rằng bạn sẽ phải liệt kê chương trình của họ là rủi ro tại một cuộc họp cụ thể sẽ khiến họ có động lực để giải quyết các vấn đề bạn gặp phải và bạn không bao giờ phải nói chuyện với người quản lý . Ở những người khác, nơi các vấn đề được điều khiển theo lịch trình nhiều hơn, đồng nghiệp sẽ thường đồng ý với bạn và hai bạn có thể đi đến người quản lý cùng nhau.

Tôi chưa bao giờ có một đồng nghiệp nào không nhanh chóng sửa chữa mọi thứ cho tôi hoặc người khác đồng ý với những lo lắng của tôi, khi bày tỏ theo cách này. Nhưng nếu điều đó xảy ra, bằng cách đưa ra cảnh báo trước cho đồng nghiệp, bạn vẫn ở vị trí tốt hơn khi nói chuyện với người quản lý. Vì bạn đã nói chuyện với đồng nghiệp và cố gắng tự mình đưa ra giải pháp và cảnh báo họ trước rằng bạn sẽ cần nêu vấn đề tại cuộc họp này, đồng nghiệp của bạn sẽ không ngạc nhiên khi họ làm vậy và người quản lý đã thắng Tôi không nghĩ rằng bạn chỉ đang cố gắng thay đổi sự đổ lỗi.

Xin vui lòng nhớ rằng khi bạn bày tỏ mối quan tâm của mình, với đồng nghiệp hoặc người quản lý, rằng mối quan tâm của bạn là về chương trình của đồng nghiệp đang trả lại dữ liệu xấu (hoặc bất cứ điều gì khác đang làm); đây là những thứ có thể đo lường được có thể được xác minh và sửa chữa. Mối quan tâm của bạn không phải là về việc đồng nghiệp của bạn chậm chạp hay thiếu quyết đoán; đây không phải là những điều có thể đo lường được, có thể đúng hoặc không đúng và không thể sửa được bằng cách đưa chúng lên trong một cuộc họp trước mặt sếp.

Bạn đang sử dụng hệ thống theo dõi lỗi nào? Tôi đã dự kiến ​​rằng ít nhất là để làm nổi bật nơi các lỗi không được sửa chữa trong thời gian tới. Trường hợp mã của bạn đang chờ đầu vào từ lớp khác, độ trễ sẽ được tô sáng trong tài liệu theo dõi dự án. Đây cũng không phải là xảy ra?

Nghe có vẻ như tôi có quản lý dự án không đầy đủ ở đây. Bạn cần phải a) theo dõi các lỗi đang ảnh hưởng đến bạn và b) theo dõi các cuộc thảo luận bằng văn bản.

Đồng nghiệp của bạn không nên yêu cầu bạn tăng thời gian phát triển để bù đắp sự thiếu ý chí của anh ấy. Tại một số điểm, đây là điều sẽ phải được giải quyết với người quản lý của bạn. Khi mọi thứ trở nên ổn định, bạn đang che đậy cho đồng nghiệp của mình và điều đó gần như chắc chắn sẽ gây tác dụng ngược.

Không có gì sai khi gắn bó với một đồng nghiệp, nhưng đối với một người nào đó mong đợi bạn nói dối sếp hàng ngày phải ra đi. Tôi không thể tôn trọng anh ấy như một người và sẽ không muốn có người này như một người quen thông thường. Anh ta muốn trở thành một kẻ thù, mang nó lên.

Làm thế nào bạn có thể tranh luận sự chậm trễ trên lớp ứng dụng vì mặt trước? Đó là lý do tại sao bạn làm điều này để chúng có thể tách rời. Điều gì tiếp theo, anh ta thậm chí còn chậm trễ hơn bởi vì ai đó muốn xây dựng một mặt trận huy động?

Hoàn thành công việc của bạn Tài liệu về bất kỳ vấn đề bạn gặp phải với một thất bại trên ứng dụng của mình. Và sau đó ĐI VỀ NHÀ! Tôi không quan tâm nếu bạn buồn ngủ hay không. Tìm một số người bạn có giá trị.

Tôi vừa đọc "Bộ giải mã sạch" của RC Martin (Chú Bob). Điểm chính của cuốn sách là các lập trình viên nói chung không nhận được nhiều sự tôn trọng vì họ không cư xử chuyên nghiệp . Điều đó có nghĩa chủ yếu là họ không giao tiếp hiệu quả với ban quản lý về tình trạng của dự án.

Nói dối chắc chắn là một hình thức giao tiếp rất rất xấu. Đồng nghiệp của bạn đang cực kỳ không chuyên nghiệp và bạn cũng vậy. Cả hai bạn đều không làm gì tốt để cải thiện nhận thức của các lập trình viên.

Tôi sẽ khuyên bạn đi ngay để quản lý. Tuy nhiên, tôi đã gặp rắc rối trong quá khứ vì đã quá "trung thực" (trong một số tình huống không liên quan), vì vậy tôi không chắc bạn nên nghe theo lời khuyên của tôi. Ngoài ra, như nhiều người đã chỉ ra, có thể nhận thức của bạn về tình huống không chính xác như bạn nghĩ.

Thật khó khăn và không hợp lý để ước tính nỗ lực và độ phức tạp tương đối của một dự án khác nếu bạn không quen thuộc với cơ sở mã. Bạn nói rằng mã của anh ấy dễ bị lỗi, nhưng nó có thể rất tốt với tất cả các vấn đề còn lại ở mức độ trừu tượng rất cao ... Vấn đề là, đó là mã duy nhất mà giao diện người dùng của bạn cần!

Hoặc, có thể anh ta là một nhân viên tồi và đưa công ty đi nhờ. Tôi không thể nói, và bạn cũng có thể không có tất cả thông tin bạn cần biết.

Tôi muốn đề xuất một chiến thuật giữa chừng. Lần tới khi bạn gặp, hãy mang một số chi tiết về một lỗi lớn trong mã của anh ấy đang ảnh hưởng đến bạn. Khi anh ấy nói mọi thứ đều ổn, hãy lịch sự nói rằng có một vấn đề nổi cộm đang cản trở tiến trình của bạn.

Về mặt chính trị, nói như thế cho phép bạn khẳng định rằng anh ta không hoàn toàn chính xác, trong khi vẫn cho anh ta một cơ hội để chơi câm và không được đưa vào phòng thủ.

Người quản lý của bạn nên hỏi trong cuộc họp tiếp theo nếu nó cố định. Nếu không, áp lực rơi vào anh ta để sửa một lỗi. Nếu nó là sửa chữa, hãy nói cảm ơn, bây giờ nó hoạt động rất tốt và bạn đã tìm thấy một trình chặn mới. Nếu bạn muốn trở nên đặc biệt tốt đẹp, hãy nói rằng bạn đã gặp nó ngay trước cuộc họp.

Bạn không nói dối, bạn cũng không đứng về phía bạn. Bạn đang chơi chính trị bằng cách kêu gọi sự chú ý đến các vấn đề và để đồng nghiệp của bạn giữ thể diện nếu mọi thứ thực sự không được tiến hành tốt.

Thật hấp dẫn khi chỉ nói chuyện với người quản lý của bạn, nhưng đừng quên bạn phải làm việc với ai trong số họ.

Câu trả lời của Pat rất tuyệt. Tôi đồng ý 100%. Đừng đi lén một cuộc họp với ông chủ. Hoặc là mang nó với đồng nghiệp của bạn giữa 4 mắt hoặc làm điều đó với cả 3 bạn. Nhưng đề nghị của Pat tập trung vào các vấn đề về mã và không tập trung vào con người là cách đúng đắn.

Btw, 40h / tuần là đủ anh chàng. Bạn cần giữ cho động lực của bạn cao!

Yêu cầu một số người khác để giúp bạn cả trong thử nghiệm tích hợp. Người đó sẽ có thể nói nơi xảy ra vấn đề. Như cám dỗ đã chỉ ra tôi tự hỏi tại sao thậm chí không có một excel để theo dõi các vấn đề! vì không có theo dõi, giống như mọi lần anh chàng khác trốn thoát khi nói mọi thứ đều ổn như bây giờ! Nó không hoạt động theo cách đó!

Đó là mô-đun của bạn nếu bạn cần hoàn thành nó, bạn cần giương cờ Đỏ về những gì gây ra sự chậm trễ về phía bạn. Kinh nghiệm trong MERE Years không có gì để làm, đó chỉ là kiến ​​thức và đó là những gì người quản lý của bạn nên nhấn mạnh. Như đã nói, tôi cảm thấy có một sự quản lý dự án kém ở đây.

1. Thể hiện sự chủ động bằng cách yêu cầu các nhiệm vụ bổ sung và hỏi làm thế nào bạn có thể thêm giá trị cho tổ chức là cách tốt nhất để kiếm được lòng tin.

Người quản lý của bạn có thể không đủ kỹ thuật để tìm ra ai đang làm chậm dự án, nhưng họ có thể đủ thông minh để nhận ra rằng một nhà phát triển đang tích cực tìm kiếm nhiệm vụ mới đang làm hỏng nhiệm vụ hiện tại của họ. Điều này sẽ dẫn đến một cuộc trò chuyện nơi bạn có thể nói rõ rằng bạn đang chờ sửa lỗi từ những người khác trong nhiệm vụ hiện tại của bạn. Đóng khung thảo luận về cách bạn có thể thêm giá trị bổ sung cho tổ chức bằng cách sử dụng hiệu quả thời gian rảnh của mình, chứ không phải làm thế nào đồng nghiệp của bạn quá chậm với các sửa lỗi của anh ấy.