Tôi là một người quản lý. Làm thế nào tôi có thể cải thiện mối quan hệ công việc và giao tiếp với các lập trình viên? [đóng cửa]

Một chút nền tảng đầu tiên. Tôi là quản lý dự án tại công ty cỡ trung bình. Tôi bắt đầu học chuyên ngành CS và có một chút tiếp xúc với lập trình, nhưng sau vài tháng tôi biết đó không phải là con đường của mình, vì vậy tôi đã chuyển sang quản lý. Đó là một quyết định đúng đắn và sau khi tốt nghiệp tôi đã làm việc trong ngành quản lý phần mềm tại nhiều công ty khác nhau (được 5 năm rồi).

Gần đây, chúng tôi đã có một dự án rất đau đớn. Đó là điều tồi tệ nhất trong những điều tồi tệ nhất, với nhiều sai lầm cả về phía chúng tôi và phía khách hàng và chỉ cần kết thúc nó mà không thua lỗ. Nó đã dẫn đến nhiều tình huống bực bội, một trong số đó leo thang đến mức một trong những nhà phát triển cấp cao của chúng tôi rời công ty sau cuộc cãi vã với chúng tôi (ban quản lý). Đây là một lá cờ đỏ đối với tôi: tôi đã làm điều gì đó cực kỳ sai lầm. (đối với bản ghi, đối số là về một số ước tính thời gian sai)

Tôi đã tìm kiếm nhiều nơi để tìm câu trả lời và một người bạn đã chỉ cho tôi trang web này. Có rất nhiều câu hỏi ở đây về sự thất vọng với quản lý. Tôi có thể hiểu rằng những trải nghiệm tồi tệ chung dẫn đến sự miễn cưỡng chung đối với "những kẻ mặc đồ".

Tôi là người đó trong bộ đồ. Nó có thể không giống như vậy, nhưng tất cả những gì tôi muốn là một dự án thành công và với nguồn lực hạn chế, nó phải đưa ra những quyết định đau đớn. Đó là công việc của tôi. Một trong những điều mà nhà phát triển cấp cao nói trên phàn nàn là thiết bị làm việc. Thành thật mà nói, tôi không biết rằng các máy tính chúng tôi không phù hợp để làm việc. Sau này, tôi đã hỏi nhiều lập trình viên và sự đồng thuận chung là chúng ta cần máy móc tốt hơn. Tôi đã sửa nó từ đó, nhưng rõ ràng có một khoảng cách giao tiếp rất lớn giữa tôi và các lập trình viên. Một số nhà phát triển xuất sắc nhất là những người nhút nhát và im lặng nhất. Tôi biết điều đó, và nó không bao giờ là vấn đề trong một cuộc phỏng vấn. Mọi người là khác nhau, và có thế mạnh ở các lĩnh vực khác nhau.

Trường hợp của các PC yếu chỉ là một trong số nhiều điều khiến tôi nghĩ rằng có vấn đề về giao tiếp. Làm thế nào tôi có thể cải thiện giao tiếp với các lập trình viên mà không bị đe dọa và lặp đi lặp lại?

Điều tôi hy vọng là mọi người đừng phàn nàn về những điều tốt đẹp. Nếu bạn yêu nơi làm việc của bạn và yêu (hoặc ít nhất là thích :)) người quản lý của bạn, xin vui lòng cho tôi biết về họ. Họ đang làm gì đúng? Tương tự, nếu bạn ghét nó, xin vui lòng mô tả chi tiết tại sao. Tôi đang tìm kiếm câu trả lời về việc cải thiện giao tiếp vì tôi nghĩ đó là vấn đề của tôi, nhưng tôi có thể sai.

Ồ Cam ơn vi đa hỏi. Về mặt kỹ thuật, giống như bạn, tôi đoán tôi là quản lý, vì tôi dành nhiều thời gian hơn để giao tiếp và lãnh đạo các nhóm hơn là viết mã .... nhưng đây là công việc của tôi từ cả hai đầu của chân trời quản lý. Cho dù tôi là nhà phát triển hay người quản lý làm việc cho người quản lý khác, đây là một số nội dung giúp tôi liên lạc với quản lý của mình:

• Tại sao? là một câu hỏi rất quan trọng - hầu như bất kỳ câu trả lời thực tế nào cũng có "lý do" đằng sau nó và rằng "tại sao" có thể quan trọng hơn câu hỏi thực tế. Có một vài tiếp tuyến này:
  • Nhà phát triển Tại sao - Nhà phát triển sẽ có rất nhiều câu trả lời hoàn toàn không có ý nghĩa đối với quản lý. Tôi chắc chắn đã làm, và một trong những cách tôi tham gia quản lý là thực sự giỏi trong việc giải thích các đội "whys" trong điều khoản quản lý có thể hiểu. Nếu bạn không có "loa cho các chuyên viên máy tính" trên tay, bạn có thể học cách nói chuyện bằng cách khôi phục câu trả lời của họ cho câu hỏi tại sao trong các ẩn dụ thường được hiểu hơn. Giữ nó cho đến khi cả hai bạn hiểu và đồng ý về những gì đang xảy ra.
  • Tại sao quản lý- "tại sao" của bạn cũng quan trọng như vậy. Tại sao bạn cần ước tính thời gian? Bạn đang sử dụng chúng để làm gì? Làm thế nào chúng ta sẽ trở thành một công ty nếu họ quá cao hoặc quá thấp? Đây là thứ mà bạn với tư cách là người quản lý có thể có những hiểu biết sâu sắc, nhưng đây là tất cả những điều tốt cho nhà phát triển. Bí quyết là, nhà phát triển có thể không hỏi. Quản lý đã yêu cầu anh ta một cái gì đó, và anh ta sẽ làm tốt nhất có thể để chính xác, kịp thời và chu đáo - nhưng nếu anh ta không biết "tại sao" thì anh ta có thể tối ưu hóa theo cách bạn muốn. Đưa ra lý do tại sao của bạn và yêu cầu anh ta làm điều tương tự - giới thiệu lại câu trả lời theo cách riêng của anh ta.

Về ước tính thời gian cụ thể - Tôi đã phải làm rất nhiều và tôi hoàn toàn có lợi từ việc nói với nhóm phát triển của mình "Tôi cần điều này bởi vì tôi sẽ xin thêm tiền để trả lương cho chúng tôi, tôi sẽ tin tưởng vào những gì bạn nói với tôi và Tôi sẽ sử dụng số của bạn ... điều đó có nghĩa là nếu bạn đánh bóng thấp tôi, tất cả chúng ta đều bị lừa bởi vì tôi sẽ không thể xin tiền lần thứ hai - chúng ta phải sống với những gì chúng ta đề xuất ". Với bối cảnh đó, các nhà phát triển đã thay đổi từ các ước tính thấp đã cố gắng cho tôi thấy họ tự tin và xuất sắc như thế nào với các ước tính cao đến gần hơn với cài đặt kỳ vọng thực sự.

• Không ai sai - Câu hỏi "tại sao" kéo dài với một hệ quả - hỏi "tại sao" thay vì nói "đó là thái quá! Không thể nào!" giữ cho cuộc trò chuyện trôi chảy Đôi khi có một sự mất kết nối nghiêm trọng giữa những gì ai đó đang được hỏi và những gì người hỏi đang hỏi. Quản lý tốt nhất của tôi đã rất ngạc nhiên với câu trả lời của tôi, và khi ngạc nhiên, họ chớp mắt ngạc nhiên và sau đó hỏi "tại sao bạn lại nói như vậy?". Họ không nói (ngay lập tức) - "bạn cần thay đổi nó". Tôi đã giảm số lượng đề xuất để đáp ứng mục tiêu cạnh tranh, nhưng chỉ sau khi nói mạnh mẽ về cách chúng ta có thể thay đổi cảnh và tạo bối cảnh khác cho câu hỏi.

• lắng nghe tiếng ồn xung quanh, lựa chọn từ ngữ và khoảng cách giữa các từ - Đây là một loạt những thứ tôi thích và đánh cắp để sử dụng bản thân:

  • đi chơi trong khu vực làm việc, làm việc gì đó có ích cho riêng bạn (đừng cố gắng tham gia vào công việc của nhà phát triển, họ biết bạn không phải là nhà phát triển) và chỉ lắng nghe. Làm thế nào để nhóm giải quyết vấn đề? Vấn đề lớn của họ là gì? Bạn sẽ không bao giờ nghe thấy sự gầy gò thực sự trong đánh giá trực tiếp của họ về bạn hoặc quản lý, nhưng bạn có thể cảm nhận thực sự tốt về các vấn đề đang ở đâu. Hãy chắc chắn rằng bạn đang làm một cái gì đó của riêng bạn có hiệu quả. Không ai thích gián điệp, nhưng trừ khi tinh thần thấp đến mức bạn không thể ở gần họ mà mọi người phải sơ tán, năng suất trong phạm vi gần phải được chấp nhận.
  • tìm kiếm các lựa chọn từ - chúng thường quan trọng như chính các từ đó. Khi tôi đã sử dụng những từ đặc biệt tích cực hoặc tiêu cực, quản lý của tôi thường hỏi tôi tại sao tôi chọn những từ đó khi đó là tình huống mà họ không quen thuộc.
  • tìm kiếm tạm dừng, khoảng cách và ngôn ngữ cơ thể. Nếu có khoảng cách quyền lực giữa bạn và nhà phát triển (và có vẻ như có), họ có thể không muốn mâu thuẫn hoặc đối đầu với bạn. Nhưng bản năng cơ bản để nói "này, bạn sai rồi" thường biểu hiện ở đâu đó.

• mở ra càng nhiều phương tiện liên lạc càng tốt - sẵn sàng trò chuyện trực tiếp, qua điện thoại, qua email, qua IM - bất cứ điều gì và mọi thứ để thiết lập luồng giao tiếp. Mọi người rất đa dạng đến nỗi chỉ cần một mẹo sẽ không hiệu quả. Và tôi thấy đó là công việc của người quản lý là người giao tiếp đa định dạng chứ không phải nhà phát triển.

• Làm cho nó đáng để nói chuyện với bạn Nếu ai đó nói với bạn về một vấn đề và có thể là một giải pháp khả thi, anh ta nên và có thể chấp nhận rằng bạn là người quản lý và do đó có thể quyết định ủng hộ một giải pháp khác hoặc không có giải pháp nào cả vì bạn không nghĩ rằng nó có giá trị rắc rối. Nhưng sau lần thứ ba, điều này xảy ra, đặc biệt nếu nó xảy ra mà không có lời giải thích về 99% mọi người sẽ ngừng nói với bạn bất cứ điều gì.

Và đây là một điều cực kỳ khó khăn với tôi, nhưng đã làm việc rất tốt khi tôi có thể làm điều đó - nhận thức được sự khác biệt giữa người hướng nội và người hướng ngoại . Rất có thể bạn là người hướng ngoại - đó là lý do tại sao công việc của bạn có vẻ tốt và vị trí phát triển thì không. Các nhà phát triển, phần lớn, là người hướng nội. "Hướng nội" không có nghĩa là "không thể giao tiếp", nhưng nó có nghĩa là mô hình, quá trình và vận tốc của chúng khác nhau đáng kể và sự thôi thúc giao tiếp không ngừng là hầu như không tồn tại. Lập kế hoạch trong thời gian và không gian yên tĩnh (nhưng được sắp xếp lại) để cho những suy nghĩ hướng nội xuất hiện. Nhiều người bạn hướng nội của tôi nói với tôi rằng họ chỉ chờ tôi "im lặng trong 5 phút" để họ có thể cùng nhau suy nghĩ và trả lời. Đây'5 điều người hướng ngoại nên biết về người hướng nội và Rands trong Repose trên Nerd Cave - một ví dụ đặc biệt dành cho nhà phát triển về những điều tuyệt vời cho người hướng nội . Nhân tiện, Rands là khá tuyệt vời. Bản thân anh ta là một người đam mê, vì vậy anh ta đến từ một nhà phát triển tập trung, có thể không thích nếu đó không phải là phong cách của bạn, nhưng anh ta hài hước và có một số hiểu biết thực sự tốt về phát triển nhóm.

Tôi nghĩ rằng những điều số 1 tôi yêu thích về những người quản lý yêu thích của tôi là:

• họ đã cam kết sâu sắc và hào hứng với dự án như tôi (nếu không nói là nhiều hơn)

• Tôi chưa bao giờ nghi ngờ rằng họ có lưng của tôi - tôi biết chắc chắn rằng khi họ đứng trước cấp độ thẩm quyền tiếp theo, tôi (hoặc đồng nghiệp của tôi) sẽ không bao giờ là con dê ghẻ. Nó sẽ luôn là một thất bại nhóm, nếu có thất bại.

• Tôi đã được trao quyền sở hữu một cái gì đó quan trọng và phù hợp với các kỹ năng của tôi vào thời điểm đó, nhưng có đủ nguồn lực để mở rộng các kỹ năng của tôi và hoàn thành công việc.

• họ đã xem tôi như một cá nhân và là một phần của đội - họ đã tích cực tham gia để biết điểm mạnh và điểm yếu của tôi và làm việc để giúp tôi phát huy điểm mạnh và gia tăng điểm yếu của mình.

• họ đã nhận thức được các mục tiêu cá nhân của tôi và quan tâm đến việc kết hợp chúng nhiều nhất có thể

• họ đã thẳng thắn khi làm tôi hạnh phúc không thể và sẽ không được ưu tiên. Có một giá trị thực sự khi nghe "Tôi biết bạn ghét loại công việc này, nhưng tôi cần bạn làm nó - đây là cách nó sẽ không tồn tại mãi mãi ...".

• luôn luôn có thời gian trong một tuần (có thể không phải ngay lập tức) để giải thích bức tranh lớn

• gần như không có phản hồi và trạng thái không có ngón tay trỏ nhưng rất nhiều sự công nhận cho từng công việc.

• luôn luôn có sự thật Nếu một cái gì đó nhạy cảm và không thể được thảo luận, họ nói như vậy điểm trống. Nếu có gì đó không chắc chắn, họ đã cho một mức độ tự tin.

Phần dễ nhất trước tiên: có một lá cờ đỏ kỹ thuật trong bài viết của bạn: Tôi rùng mình khi bạn đề cập đến "ước tính sai lầm" - đó là một ước tính, nó KHÔNG THỂ ĐƯỢC MISTAKEN , đó là lý do tại sao nó được gọi là ước tính. Nó có thể tắt một chút, nó có thể tắt rất nhiều, đó là lý do tại sao nó được gọi là ước tính. Nếu bạn đang lấy ước tính làm phúc âm, đó sẽ là một trong những vấn đề chính mà các nhà phát triển "của bạn" đang gặp phải với phong cách của bạn.

Tuy nhiên, tôi 100% đồng ý với bạn về những khó khăn khi giao tiếp với các nhà phát triển. Tôi đã có một tiết lộ vài năm trước, với tư cách là một nhà phát triển trong một khóa đào tạo quản lý dự án. Tôi đã thấy một số nhà phát triển đồng nghiệp của tôi hoàn toàn chống lại quản lý sau khi một bầu không khí thảo luận cởi mở được tạo ra (quản lý đã có mặt ở đây). Tất cả những gì sai là lỗi của các nhà quản lý trong mắt các nhà phát triển. Các kicker là quản lý không có ý tưởng về gần như tất cả các vấn đề lớn được nêu ra ngày hôm đó. Các nhà phát triển đã cho rằng tất cả rõ ràng đến mức ban lãnh đạo không thể bỏ lỡ và ban quản lý cho rằng các nhà phát triển sẽ nói với họ những gì họ cần.

Do đó, IMHO phần đầu tiên của câu trả lời phải là để cho các nhà phát triển của bạn biết rằng bạn không phải là người tâm lý, và trên thực tế có lẽ hết sức ngu ngốc khi nói về khía cạnh kỹ thuật. Bạn đang dựa vào, tin tưởng và tin tưởng họ sẽ đến với bạn một cách kịp thời. Bạn ở đó để làm cho cuộc sống của họ dễ dàng hơn, không khó khăn hơn.

Và bất cứ điều gì bạn làm, KHÔNG hỏi họ những câu hỏi mà bạn không thực sự muốn biết câu trả lời - tham khảo "ước tính sai lầm" ở trên ;-). Đó là kryptonite của nhà phát triển.

Có rất nhiều thứ hay ho ở đây nhưng tôi cảm thấy cần phải nói những điều sau đây .. Xin lỗi vì sự khắc nghiệt .. Nhưng điều này cần phải được nói:

• 5 năm làm Thủ tướng và không biết nhà phát triển cần loại PC nào, thật quá đáng.
• Để một nhà phát triển bỏ việc vì điều kiện làm việc tồi tệ như lá cờ đỏ thực sự đầu tiên của bạn, là điên rồ.

Những gì tôi nghĩ bạn có là một vấn đề Tin cậy , hơn cả vấn đề giao tiếp. Không ai nói điều gì sai vì họ không tin những gì bạn sẽ làm với thông tin đó và thậm chí có thể sợ nó sẽ được sử dụng để chống lại họ. Các nhà phát triển đã nói với bạn về tất cả những vấn đề này đã làm như vậy bởi vì không có hậu quả trong việc đó, anh ấy đã bỏ việc.

Cá nhân tôi sẽ không bao giờ thuê một PM không có kinh nghiệm phát triển trong nền tảng của mình. Tôi nghĩ trong dự án tiếp theo của bạn, bạn nên dành một phần nhỏ thời gian của mình như là một phần của Dev. đội . Nói 8 giờ một tuần, làm việc như nhà phát triển Jr dưới sự lãnh đạo của nhóm.

Điều này thực sự sẽ mở mắt cho sự năng động của một nhóm phát triển, bởi vì ngay bây giờ, bạn thậm chí không phải là một phần của nhóm đó, bạn là người ngoài cuộc. Thực tế là nhà phát triển của bạn bỏ qua đã gây sốc cho bạn, chứng minh điều đó. Mọi người trong đội đều biết anh không vui. Và không ai trong số họ nói với bạn:

"Chúng tôi sẽ mất người tốt nhất của chúng tôi nếu bạn không làm gì đó"

Đó phải là cờ đỏ # 2.

Là người quản lý Tôi chắc chắn bạn đã nghe về kaizen , một trong những nguyên lý của Hệ thống sản xuất Toyota có nghĩa là cải tiến liên tục .

Bạn thừa nhận bạn có một vấn đề, vì vậy, đó là một khởi đầu tuyệt vời.

Kaizen có năm yếu tố chính:

• Vòng kết nối chất lượng : Các nhóm gặp nhau để thảo luận về các mức chất lượng liên quan đến tất cả các khía cạnh hoạt động của công ty.

• Tinh thần được cải thiện : Tinh thần mạnh mẽ trong lực lượng lao động là một bước quan trọng để đạt được hiệu quả và năng suất lâu dài, và kaizen đặt nó như một nhiệm vụ nền tảng để giữ liên lạc thường xuyên với tinh thần nhân viên.

• Làm việc theo nhóm : Một công ty mạnh là một công ty gắn kết với nhau từng bước. Kaizen nhằm mục đích giúp nhân viên và quản lý xem mình là thành viên của một nhóm, thay vì đối thủ cạnh tranh.

• Kỷ luật cá nhân : Một nhóm không thể thành công nếu không có mỗi thành viên trong nhóm tự mạnh. Một cam kết về kỷ luật cá nhân của mỗi nhân viên đảm bảo rằng nhóm sẽ vẫn mạnh.

• Đề xuất cải tiến : Bằng cách yêu cầu phản hồi từ mỗi thành viên trong nhóm, ban quản lý đảm bảo rằng tất cả các vấn đề được xem xét và giải quyết trước khi chúng trở nên quan trọng.

( Nguồn )

Nếu bạn nhìn vào điều này, một sự thay đổi liên tục trên các yếu tố đó là sự nhấn mạnh vào tinh thần đồng đội và phản hồi.

Một ví dụ, bạn nói rằng bạn đã có một đối số theo ước tính thời gian. Bạn có chịu trách nhiệm cho những ước tính thời gian? Bạn có nói chuyện với nhóm về điều đó? Tôi xin lỗi nhưng tôi đã thấy các nhà quản lý chỉ rút ra một số từ. Một điều rất quan trọng: không bao giờ mặc cả theo thời gian ước tính nhóm của bạn cung cấp cho bạn. Rất nhiều nhà quản lý tưởng tượng rằng nếu họ có thể đáp ứng thời hạn ngắn hơn nếu nhóm của họ làm việc chăm chỉ hơn. Đây là một lời nói dối. Chín phụ nữ không thể có con trong một tháng, hãy nhớ điều đó.

Vì vậy, lời khuyên đầu tiên của tôi:

Lắng nghe : bắt đầu với một e-mail đơn giản cho nhóm: "Cách tốt nhất để nhóm phát triển đưa ra phản hồi cho ban quản lý về hiệu suất quản lý là gì?". Lặp lại với nhóm và thực hiện sự đồng thuận. Nhiệm vụ của bạn là cho phép nhóm phát triển phần mềm tuyệt vời, không phải chăn dắt chúng. Giữ nó trong tâm trí.

Trung thực và trung thành : Nếu không có ai trả lời khi bạn hỏi điều gì đó, thì đó là vì họ không tin bạn sẽ lắng nghe hoặc tệ nhất là họ tin rằng bạn sẽ trừng phạt họ vì điều đó. Vì vậy, hãy trung thực. Nếu ai đó nói bạn hút, hãy coi đây là phản hồi và đừng trả thù. Hiểu lý do của họ, cải thiện nó.

Và cuối cùng, mặc dù tôi đã thấy một số bài phê bình về nó ở đây, tôi muốn khuyên bạn nên đọc một cuốn sách có tên là Tháng huyền thoại: Các tiểu luận về Kỹ thuật phần mềm . Cuốn sách nói về kinh nghiệm của Fred Brooks tại IBM trong khi quản lý sự phát triển của OS / 360. Mặc dù một vài điều ở đây và có thể có ngày, đó là bước khởi đầu để hiểu quá trình phát triển của phần mềm phức tạp hoạt động như thế nào. S.Lott trích dẫn Tuyên ngôn Agile , điều mà tôi không đặc biệt quan tâm đến nó, nhưng nó cũng đáng để đọc.

Đọc này:

http://agilemanifesto.org/

• Các cá nhân và tương tác qua các quy trình và công cụ

• Phần mềm làm việc trên tài liệu toàn diện

• Hợp tác khách hàng qua đàm phán hợp đồng

• Đáp ứng để thay đổi theo kế hoạch

Trong nhiều trường hợp, tổ chức (tức là sếp của bạn) yêu cầu bạn

• theo một quá trình rõ ràng bị phá vỡ để kết luận hợp lý của nó dẫn đến một "cuộc diễu hành tử thần". Điều này dẫn đến lần lượt tranh luận và từ chức.

• tạo quá mức, giá trị thấp, tài liệu không sử dụng.

• tham gia vào kiểm soát thay đổi phức tạp a / k / đàm phán hợp đồng. Mỗi thay đổi người dùng đòi hỏi một nghi thức phức tạp để "chất lượng" và "ưu tiên" thay đổi. Thực sự, đó là tất cả về "đóng băng" - ngăn chặn sự thay đổi.

• Thực hiện theo kế hoạch không phân biệt hậu quả. Một số tổ chức đánh giá đúng thời gian giao phần mềm bị hỏng (hoặc thậm chí vô dụng). Đó là kế hoạch có giá trị, không phải là giải pháp của một vấn đề kinh doanh.

Có thể vấn đề không phải là kỹ năng giao tiếp cá nhân của bạn.

Có thể là toàn bộ "môi trường" hoặc "phương pháp" phát triển bị phá vỡ nghiêm trọng, và cảm giác xấu chỉ là một triệu chứng của các thực hành xấu nói chung.

Đối với tôi điều này nghe có vẻ như bạn chưa bao giờ nói chuyện với các nhà phát triển trong một bầu không khí dễ dàng. Cuộc nói chuyện của bạn với họ chỉ đơn thuần là bản chất chính thức? Điều đó thật tệ.

Tại sao bạn không làm quen với họ và do đó biết được điều gì tốt và điều gì xấu về công ty, nơi làm việc và các dự án của họ? Tôn trọng họ và kiếm được sự tôn trọng của họ, bằng cách thể hiện sự quan tâm và đánh giá cao cho công việc của họ.

Nếu họ tin tưởng bạn và không cần phải lo lắng về việc cung cấp cầm đồ, rất có thể họ thậm chí sẽ nói với bạn những sự thật không hấp dẫn.

Tôi là một Trưởng nhóm và nhóm của tôi tin tưởng tôi. Tôi bảo vệ họ. Tôi nhận tất cả lỗi lầm và tôi chia sẻ danh tiếng với họ. Quản lý của chúng tôi bảo vệ tôi. Điều đó thúc đẩy tinh thần. Chúng tôi đã có một dự án thực sự khó khăn và một khách hàng gần như xấu xa, gần như không thể hoàn thành nhưng cuối cùng chúng tôi đã làm được, bởi vì chúng tôi nói về mọi thứ một cách rất thẳng thắn và cởi mở.

Vỗ tay! Vỗ tay! Vỗ tay! Bạn chắc chắn nên là một người tốt, vì bạn đã mở ra để xem những gì có thể được thực hiện để có được công việc tốt hơn.

Vui lòng tìm bên dưới những gì tôi đã chứng kiến ​​ở một người quản lý tuyệt vời và đã nhận nuôi cá nhân khi tôi lãnh đạo nhóm với tư cách là thành viên cấp cao.

• M entor hơn quản lý.
• Một thành viên trong nhóm chậm nói lên suy nghĩ và mối quan tâm của họ. Hãy là tất cả tai của nó. Hãy những người xây dựng.
• N từng phản bội các thành viên trong nhóm bằng cách chơi chính trị gây chia rẽ. Điều này trở lại sớm hơn và âm thầm.
• Một nger không. Không bao giờ có khuôn mặt nhăn nhó khi bạn ở cùng đội của bạn, hãy đến những gì có thể. Điều này thực sự khó khăn.
• G thực sự và công khai đánh giá cao người chiến thắng cho công việc tốt của mình. Trong cùng một chiều rộng, rất nhẹ nhàng và khéo léo sắp xếp công việc không phải là người cho bất kỳ sai trái, cho người chịu trách nhiệm, cô lập và không cởi mở.
• E ncourage sở hữu và lãnh đạo trong mỗi cá nhân. Điều này thúc đẩy tinh thần và cam kết của người đó, bởi vì anh ta sẽ cảm thấy được tôn trọng.
• R oam xung quanh với nhóm của bạn một lần trong một thời gian. Điều này gây ra / tăng liên kết trong các thành viên trong nhóm.

Chúc bạn may mắn trong nỗ lực chân thành của mình :)

Nói chung, những kẻ trong chiến hào bắt đầu cảm thấy khác biệt khi họ cảm thấy sự kìm kẹp của họ không được nghe thấy bởi những người có thể và sẽ khắc phục tình huống. Khi họ thậm chí không cảm thấy họ có thể nắm bắt mà không mạo hiểm khi đứng trong công ty, điều đó còn tồi tệ hơn.

Tôi là một chàng trai lý thuyết-Y, và hầu hết các "công nhân tri thức" có xu hướng; Có cơ hội, chúng tôi thích công việc của chúng tôi và muốn làm tốt điều đó. Tuy nhiên, nhược điểm của nơi làm việc Theory-Y là nó có thể không rõ ràng ngay lập tức có vấn đề, bởi vì mọi người, muốn làm tốt và do đó không muốn tạo ra sóng, sẽ tìm cách khắc phục vấn đề đó, hoặc đơn giản là bỏ qua nó. Điều này dẫn đến sự thất vọng dồn nén, cuối cùng sẽ nổ tung trong toàn bộ khuôn mặt của đội. Một cửa hàng được điều hành bởi người quản lý Theory-X có thể sẽ có những người phàn nàn sớm hơn nhiều; các nhân viên chỉ ở trong đó vì tiền, vì vậy nếu công việc tệ hơn bình thường, họ sẽ nắm bắt.

Đối với những gì bạn có thể làm, trong một môi trường với người cao niên và lãnh đạo trong phòng thực hiện công việc, họ là tài sản tốt nhất của bạn. Nói chuyện với họ. Bạn có thể lên lịch 30 phút mỗi tuần cho "hai chiều", trong đó khách hàng tiềm năng cung cấp cho bạn thông tin cập nhật và những lo ngại về dự án hàng ngày và bạn cung cấp cho họ thông tin cập nhật về phía doanh nghiệp và lên kế hoạch với họ để giải quyết các mối quan ngại trước khi chúng trở thành vấn đề ảnh hưởng nghiêm trọng đến đội.

Trong Agile, vào cuối mỗi lần "chạy nước rút" hoặc "lặp lại" (là một đơn vị công việc phát triển thường kéo dài từ một đến ba tuần), toàn bộ nhóm, từ hầu hết các thành viên cơ sở cho đến Thủ tướng, đều có "hồi tưởng ". Họ nhìn lại những gì họ đã làm, những gì đã làm đúng, những gì không và xác định những điều cần tiếp tục và những điều cần thay đổi. Có một số định dạng và bạn có thể tự phát minh ra, nhưng kết quả của retro nên là mọi người cảm thấy giọng nói của họ đã được nghe, và kết quả là mọi thứ sẽ thay đổi.

Nói về Agile; công việc đầu tiên của tôi là cho một công ty nhỏ, và "nhỏ", ý tôi là toàn bộ công ty không thể tạo ra một đội bóng mềm. Có bốn lập trình viên khi tôi bắt đầu, và điều đó đã giảm xuống còn hai trước khi tôi rời đi. Người sáng lập, Chủ tịch, Giám đốc điều hành và 95% cổ đông trong công ty đã cai trị nó bằng nắm đấm sắt, và ông là nguồn lập kế hoạch duy nhất trong tổ chức, có nghĩa là không có nhiều. Ông chủ là một người nghiện công việc và mong mọi người khác cũng vậy; Tất cả mọi thứ bạn phải đưa ra không nhiều hơn hoặc ít hơn mong đợi của anh ấy, và vì điều này anh ấy đã trả một mức lương nhập cảnh cho những người đã làm việc cho anh ấy trong một thập kỷ.

Tôi rời công ty đó và bắt đầu làm việc cho một công ty khác làm những việc RẤT khác nhau; họ đã thực hành phương pháp cơ bản SCRUM Agile, với các phần nổi bật hàng ngày, lập trình cặp, nhóm chạy nước rút và hồi tưởng. Trong một ngày hai tuần một lần vào đầu mỗi lần chạy nước rút, chúng tôi không làm gì ngoài việc lên kế hoạch cho hai tuần tiếp theo. Đối với một phần lớn của một ngày khác, chúng tôi không làm gì ngoài việc nhìn lại những gì chúng tôi đã làm và tìm cách cải thiện như một đội. Có những nhà phát triển ngồi cạnh tôi là những MVP của Microsoft, hoàn thành công việc, khuyến khích và bổ sung cho những gì tôi đang làm.

Đêm. Và. Ngày. Điểm khác biệt chính? Đầu tiên, tôi không cảm thấy mình sẽ tự sát vì dự án; một nguyên lý cơ bản của Agile là tốc độ phát triển bền vững. Thứ hai, tôi đã có tiếng nói trong việc quyết định tôi sẽ làm công việc của mình như thế nào. Tôi đã phải thực hiện công việc, nhưng nếu tôi bị "ợ nóng" về những gì tôi dự kiến ​​sẽ rút ra trong lần chạy nước rút tiếp theo, tôi có thể nói lên ý kiến ​​đó và nó sẽ được lắng nghe và cân nhắc. Nếu tôi cảm thấy có một cách tốt hơn, tôi có thể nói như vậy và nó sẽ được giải trí.

Theo như tìm kiếm giải pháp và giải quyết vấn đề, bạn phải cẩn thận để không trông giống như bạn đang làm việc từ trên xuống. Đối với máy tính; nói rằng RMR của bạn (doanh thu hàng tháng định kỳ) chỉ cho phép công ty nâng cấp bốn máy tính trong hai tuần. Bốn máy tính đầu tiên không nên đi đến khách hàng tiềm năng và người cao niên; họ nên tìm đến những người có máy tính chậm nhất. Nếu bạn tặng tiền thưởng cho đội, đừng chỉ đưa chúng cho "những người cao niên và người dẫn đầu có giá trị của chúng tôi, nếu không có ai thì điều này sẽ không thể xảy ra"; MỌI NGƯỜI trong nhóm dev của bạn đã làm điều đó xảy ra. Nếu một thiếu niên có khiếu nại, hãy nghe anh ta nói; chỉ vì anh ấy là đàn em không có nghĩa là anh ấy không biết gì cả.

Cải thiện quan hệ:
Chỉ cần có một dự án khó khăn? Cho họ nghỉ ngơi sau đó. Thời gian nghỉ để đi thư giãn, lấy hơi thở của họ.
Coders hóa đơn quyền Những điều này là một cho trước. Những điều cơ bản nên đi mà không nói. Nếu bạn vi phạm những điều này, bạn đang lạm dụng codemonkey của mình.
Bài kiểm tra Joel tôi đồng ý với hầu hết trong số họ. Nhưng một số thực sự phụ thuộc. Nếu bạn đang thiếu một số thứ, có lẽ bạn đang làm cho cuộc sống của các lập trình viên của bạn khó khăn hơn thì nó cần phải như vậy.
Nợ kỹ thuật . Vì vậy, bạn có thể thúc đẩy để hoàn thành, nhưng bạn phải nhận ra rằng bằng cách cắt giảm các khoản nợ kỹ thuật, bạn sẽ mất nhiều thời gian hơn vào một ngày sau đó để khắc phục. Nếu ngày đó đến trước khi kết thúc dự án, bạn đã thực sự thất vọng.
RSA animate: Động lựcĐây là một chút tuyệt vời mà thực sự cho thấy làm thế nào để thúc đẩy những người lao động tri thức.
Ngày tự do để mã những gì họ muốn. Từ video RSA. Đừng nhớ tên, nhưng công ty mà nó đề cập có một lời giải thích ngắn về nó trên trang web của họ. Có vẻ đó là ý tưởng hay cho tôi. Trong hầu hết các cửa hàng, có những thứ mà mọi người đều biết là bị vỡ, nhưng không ai có thời gian để sửa, và đó không phải là ưu tiên cao. Điều này cho phép họ giải quyết nợ kỹ thuật. Nó cũng cho phép họ thể hiện những ý tưởng tuyệt vời của họ.

Và vì tình yêu của chúa, hãy cố gắng giữ một tuần làm việc 40 giờ. Ngoài ra, flextime. Flextime có thể bù đắp cho cả một thế giới nhảm nhí. Cho tôi ít nhất.

Cải thiện giao tiếp giữa lập trình viên và ông chủ
Điều đó khó khăn hơn đối với tôi. Toàn bộ điều tồi tệ đó là nhiều hơn một kỹ năng của ông chủ sau đó là trọng tâm của một lập trình viên. Tôi có thể nói một số điều cơ bản như ước tính thời gian chỉ là ước tính. Đi bộ trên nước và thực hiện các yêu cầu dễ dàng nếu chúng bị đóng băng. Có thể yêu cầu các lập trình viên nhút nhát trình bày về dự án của họ tại một bài đánh giá mã hoặc một cái gì đó. Thực hành làm cho hoàn hảo, ya? Nhưng tôi muốn cúi đầu trước lời khuyên của người khác về điều này.

"Tương tự, nếu bạn ghét nó, xin vui lòng mô tả chi tiết tại sao."
Vâng, điều đó sẽ mở ra lũ lụt ở đây. Và nếu tôi không sử dụng openID rõ ràng có thể liên kết với tôi, có lẽ tôi cũng sẽ trút giận. Nếu bạn thực sự muốn có một danh sách khổng lồ những việc không nên làm, hãy hỏi trên một diễn đàn thân thiện hơn với việc đăng bài nặc danh.

Tôi luôn thấy rằng mọi người nói chung sẽ không đối xử với bạn tốt hơn bạn đối xử với họ (mặc dù họ có thể đối xử với bạn tệ hơn). Cá nhân tôi (tôi là một nhà phát triển) phản ứng với sự trung thực bằng sự trung thực, tôn trọng với sự tôn trọng, tin tưởng với sự tin tưởng, v.v. Bạn nên có một cuộc trò chuyện thân mật với nhóm của bạn trong một bầu không khí trung lập, và nói với họ những gì bạn vừa nói với chúng tôi. Điểm bị lãng quên trong môi trường "chúng ta so với họ" độc hại là tất cả nên là "chúng ta". Cả quản lý và công nhân cần phải biết điều đó, và doanh nghiệp phải hỗ trợ điều đó.

Chúc may mắn.

Bây giờ bạn có một hồ sơ đã được chứng minh không chỉ chấp nhận phản hồi, mà còn hành động trên nó. Bạn đã chứng minh rằng bạn có ảnh hưởng với những người ra quyết định cao hơn và bạn có thể hoàn thành công việc cho nhóm của mình. Điều đó làm cho một sự khác biệt lớn. Lập trình viên của tôi là người hướng nội nhiều hơn, nhưng chúng tôi thích nói về lập trình. Một môi trường không chính thức là tốt, nhưng mọi người vẫn cần phải chuyên nghiệp. Cho phép mọi người trút giận một số, nhưng đảm bảo các cuộc thảo luận có hiệu quả và không chỉ là một phiên làm việc.

Từ kinh nghiệm của tôi, yếu tố quan trọng nhất để tôi thích hoặc không thích người quản lý của mình là nếu anh ấy / cô ấy hiểu sự phát triển nói chung và hiểu công việc tôi đang làm. Một số kết quả tích cực được liệt kê ở đây:

• Tôi không phải lãng phí quá nhiều thời gian để biện minh cho lý do tại sao một thay đổi sẽ mất nhiều thời gian hoặc không thể thực hiện được. Vâng, về mặt kỹ thuật, bất kỳ thay đổi nào cũng có thể được thực hiện và quản lý cấp trên thường yêu cầu thực hiện bằng mọi cách. Nhưng ít nhất trong tình huống như vậy, người quản lý trực tiếp của bạn đứng về phía bạn, yêu cầu thêm thời gian (thay vì đẩy bạn hoặc đốt cháy bạn).
• Tôi biết tôi có cơ hội tốt hơn để được hỗ trợ trong trường hợp xấu (hack WTF, vấn đề sản xuất, v.v.). Thông thường, người không có kỹ thuật có xu hướng đổ lỗi cho nhà phát triển trong tình huống như vậy trong khi một người quản lý giỏi HIỂU R what những gì đang thực sự xảy ra và hỗ trợ nhà phát triển của anh ấy / cô ấy (không chỉ biết hoặc sẵn sàng làm theo cách đó để trở nên tốt đẹp).
• Tôi biết công việc và hiệu suất của tôi sẽ được đánh giá bởi một người thích hợp.

Theo tôi, nếu bạn không lập trình nữa và thường trong một lịch trình hoặc ngân sách dự án chặt chẽ, cơ hội cho các nhà phát triển của bạn thích là rất thấp. Nếu đó là trường hợp, tốt nhất bạn nên tiến lên nhanh chóng và có người khác làm người quản lý trực tiếp. Xin lỗi tôi nghe có vẻ tệ trong đoạn này nhưng đó là cách tôi nhìn thấy nó. Bạn dường như là một người tốt và xứng đáng với một số sự thật.

Tôi cũng là một trong những người mặc com lê, và đã được hơn 15 năm. Tôi là một nhà phát triển phần mềm khi tôi bắt đầu và tôi vẫn viết mã khi có cơ hội. Vì vậy, tôi nghĩ rằng tôi có thể nói chuyện cho cả hai bên và tôi có một chút kinh nghiệm trong những tình huống này. Tôi cũng có các thông tin, chẳng hạn như "Nhân viên của năm", được bầu bởi nhân viên, khiến tôi tự tin khi xử lý các tình huống này.

Những gì tôi chứng kiến ​​rất thường xuyên là có sự khác biệt đáng kể trong hệ thống giá trị và phương pháp / phương pháp hoạt động được thực hiện giữa quản lý và nhà phát triển.

Đối với rất nhiều nhà phát triển, sự chân thành, trung thực và nếu không thì một môi trường làm việc linh hoạt là rất cao trong danh sách. Thật không may, các giá trị rất giống nhau không cao trong danh sách quản lý hàng đầu. Và điều này chắc chắn dẫn đến các cuộc đụng độ lớn, đặc biệt nếu quản lý cấp trung (bạn và tôi) quyết định hoàn toàn nắm quyền quản lý cao nhất. Cách duy nhất để thoát khỏi điều này (theo quan điểm của tôi) là đứng vững trước đội của bạn, ủng hộ họ mọi cách và xây dựng mối quan hệ tin cậy thông qua giao tiếp cởi mở và quan trọng nhất là bằng cách làm những gì bạn đang nói (thường trái ngược với những gì bạn nhận được từ quản lý cấp cao, nơi chính trị hoàn toàn áp đảo sự chân thành).

Đồng thời bản thân bạn cần duy trì hoạt động, vì vậy bạn phải tìm cách giao tiếp với quản lý cấp cao bằng ngôn ngữ họ hiểu và chơi trò chơi của họ. Đó là thách thức thực sự của quản lý cấp trung.

Tôi tin rằng với năng suất hạnh phúc của nhà phát triển, tất cả đều bắt nguồn từ những điều nhỏ nhặt. Toán học hoạt động khá tuyệt vời cho quản lý. Hãy cho tôi một chiếc bánh rán (-25 xu) vào buổi sáng và tôi sẽ làm việc chăm chỉ gấp đôi cả ngày (+ nhiều đô la). Không phải là chúng tôi chủ động phá hoại mọi thứ bằng cách làm việc chậm khi chúng tôi không hài lòng, đó là chúng tôi đang làm việc trên các hệ thống cực kỳ phức tạp và cực kỳ khó tập trung khi chúng tôi thất vọng về điều gì đó. Có lẽ tốt hơn là chúng ta không viết mã nhiều khi chúng ta tức giận.

Ước tính, tuy nhiên, phải được giải quyết bởi chính họ. Mọi vấn đề tôi có thể được giải quyết bằng cách đưa cho tôi một chiếc bánh rán, ngoại trừ những ước tính không thực tế . Đúng hay sai đây là cách nhà phát triển nhìn thấy nó: Quản lý có mọi thứ để đạt được (như một chiếc thuyền mới) bằng một ước tính ngắn hơn, trong khi các nhà phát triển có mọi thứ để mất (như giấc ngủ của một tháng). Ban quản lý chịu trách nhiệm, vì vậy họ luôn giành chiến thắng trong cuộc chiến ước tính. Tôi nghĩ hệ thống ước tính hoạt động tốt nhất khi các nhà phát triển quyết định thời hạn (chúng tôi đủ khó để đưa ra ước tính chính xác, vậy người quản lý sẽ làm thế nào?), Nhưng quản lý thúc đẩy họ tham vọng một cách tích cực, với sự hiểu biết rằng không có nhà phát triển nào bị cản trở được một chút.

Xem xét loại phản ứng nào bạn đưa ra cho một lập trình viên có thể có câu hỏi, nhận xét hoặc quan tâm. Có một, "Bạn muốn gì bây giờ ?" hoặc "Tại sao bạn làm phiền tôi với điều này ?" loại phản ứng? Làm thế nào tốt là bạn đang khuyến khích các nhà phát triển nói lên mối quan tâm và ý kiến? Đó chỉ là một điểm khởi đầu.

Thứ hai, hãy cẩn thận về nơi bạn đang cố gắng để có những cuộc thảo luận này. Tôi nghi ngờ tôi sẽ rất cởi mở khi thảo luận về cỗ máy làm việc của mình với ai đó trong khối tiếp theo nếu tôi biết người quản lý của mình đang ở trong tầm nghe của toàn bộ sự việc. Nếu bạn muốn mọi người đưa ra phản hồi cởi mở và trung thực, cần phải có một chút riêng tư để biết câu trả lời của họ sẽ không được phát công khai hoặc sử dụng để chống lại họ.

Thứ ba, xem xét loại kỹ năng Trí tuệ cảm xúc nào bạn có. Trí thông minh cảm xúc cho người quản lý dự án: Những kỹ năng con người bạn cần để đạt được kết quả nổi bật của Anthony Mersino sẽ là một đề xuất sách tôi nhận được hôm qua từ một bữa trưa và tìm hiểu về EQ. Nếu bạn thực sự muốn đi sâu vào tâm lý học ở đây, có nhiều công cụ hồ sơ cá nhân khác nhau có thể được sử dụng, ví dụ Enneagram, phong cách xã hội và MBTI.

Cuối cùng, hãy xem xét văn hóa trong công ty của bạn là gì. Là sai lầm một cái gì đó quét dưới tấm thảm? Có phải những lời phàn nàn là không không có thể khiến ai đó gặp rắc rối thực sự dễ dàng? Những hành vi nào được khen thưởng hoặc khuyến khích và được chấp nhận và chấp nhận? Trong khi một số điều này là quan sát, một số trong đó cũng có thể yêu cầu một số cuộc trò chuyện nên được tổ chức cách xa văn phòng hoặc trong một căn phòng nơi không có khả năng bị nghe lén. Bạn có thể sẽ lặp đi lặp lại trong việc cố gắng sử dụng điều này ngay từ đầu. Đó không phải là một điều tồi tệ nếu bạn đang cố gắng thiết lập một thực tiễn mới và khiến mọi người tham gia lên tiếng nếu văn hóa chủ yếu là nơi mọi người chỉ biết "hút nó lên". Điều này có thể gây xúc động hơn so với các câu trả lời khác nhưng đây sẽ là những gì tôi

Các nhà phát triển cảm thấy rằng bạn là người ủng hộ của họ? Điều đó có nghĩa là họ biết rằng họ có thể tự do chia sẻ với bạn những lo lắng / thất vọng của họ mà không bị đánh đập? Họ có cảm thấy rằng bạn chiến đấu cho họ? Họ có cảm thấy rằng bạn đánh giá cao công việc của họ? Họ có cảm thấy rằng bạn thực sự muốn họ thành công trong sự nghiệp của họ?

Nếu họ cảm thấy được đánh giá cao, có lẽ bạn sẽ giao tiếp tốt hơn.

Là một nhà phát triển Tôi là một mọt sách lớn và thiếu các kỹ năng xã hội và tôi không đưa ra lời xin lỗi nào về nó. Rốt cuộc, tôi là tài năng, và bạn đã thuê tôi vì tài năng của tôi. Nếu bạn cần bướm xã hội để thực hiện công việc, bạn có một phòng đầy những người quản lý dự án thay vì nhà phát triển.

Tôi biết rằng một số nhà phát triển rất thông minh về mặt xã hội, nhưng tôi nghĩ rằng trung bình nghiêng về mọt sách hướng nội.

Khi ai đó yêu cầu tôi làm điều gì đó, tôi hoàn toàn không suy luận và thực hiện CHÍNH XÁC những gì được yêu cầu. Có vẻ như với một số người quản lý dự án, tôi luôn gặp phải vấn đề vì họ mong đợi tôi đưa ra những suy luận về dự án của họ mà tôi hoàn toàn không làm, vì vậy đôi khi mọi thứ không diễn ra như họ mong đợi mặc dù họ hóa ra chính xác là những gì họ đã yêu cầu. Tôi nghĩ lý do điều này xảy ra với một số người quản lý dự án là vì họ không cung cấp các HLD, BRD chất lượng cao và đặt quá nhiều giá trị trong khía cạnh xã hội của quản lý dự án thay vì màu đen và trắng.

Tôi nghĩ rằng đây là nơi thế giới va chạm. Tôi nghĩ trong thế giới quản lý dự án, các kỹ năng xã hội và chất lượng của kẹo cá nhân là những yếu tố quan trọng, nhưng với những nhà phát triển như tôi thì điều đó hoàn toàn không có nghĩa gì. Nó không gây ấn tượng cho tôi để hiểu về tầm quan trọng của nhiệm vụ này hoặc nhiệm vụ đó. Tôi thậm chí không muốn ra ngoài ăn trưa hoặc uống bia như một số người ở đây đã gợi ý.

Những gì tôi thực sự muốn là các HLD và BRD chất lượng cao, tốt. Tôi muốn lịch trình và thời hạn có thể đạt được, và nếu thiết kế hoặc kế hoạch mới được giới thiệu, tôi muốn lịch trình và thời hạn được điều chỉnh lại. Tôi đã làm việc trong các dự án mà các yêu cầu dường như thay đổi nhanh chóng - với tôi đây là lá cờ đỏ của tôi mà tôi đang đối phó với lãnh đạo dự án chất lượng kém. Là một nhà phát triển, điều tồi tệ nhất bạn có thể làm là mang lại cho tôi các yêu cầu dự án mới hàng ngày, đặc biệt là sau khi chúng tôi đã có lịch trình hoặc đã thực hiện các cam kết về lịch trình. Thật không thể chịu đựng được khi các yêu cầu mới được đưa vào, mà không phải bồi thường cho thời hạn. Làm việc nhiều giờ hơn, làm việc muộn, tôi không có vấn đề gì với điều đó, nhưng đó không phải là thứ luôn luôn định lượng với sự phát triển. Một số thay đổi có thể mất thêm một vài giờ, Một số thay đổi có thể mất vài tuần để R & D, thử nghiệm, QA thích hợp, v.v ... Không phải lúc nào cũng giống như nướng bánh, đôi khi một thay đổi duy nhất đối với các yêu cầu có thể giống như thay đổi toàn bộ công thức. Tôi đã chứng kiến ​​các nhà quản lý dự án tan chảy và nổi giận trong các cuộc gọi hội nghị vì thời hạn của họ sẽ không cho phép phát triển thêm, nhưng họ đang yêu cầu phát triển không theo yêu cầu dự án ban đầu của họ.

Tôi chỉ có thể đưa ra sự thiên vị và kinh nghiệm cá nhân của riêng tôi làm ví dụ vì vậy xin đừng suy luận rằng tôi đang nói thay mặt cho tất cả các nhà phát triển. Tôi chỉ nhìn thấy những điều này thông qua thế giới vi mô của sự nghiệp của riêng tôi, nhưng bài đăng này mô tả chính xác các điều kiện khiến tôi ném vào khăn tục ngữ.

Bạn có thường xuyên nói chuyện với các nhà phát triển của mình không? Tôi không có nghĩa là các cuộc họp trạng thái dự án, câu hỏi về việc cung cấp hoặc các chủ đề khác mà bạn mang đến cho họ - bạn có thường xuyên ngồi xuống với một trong những lập trình viên của bạn, hỏi họ mọi thứ đang diễn ra như thế nào và chỉ lắng nghe .

Rất nhiều câu trả lời khác thực sự tốt - bạn nên xem xét sự phát triển nhanh. Bạn cần các nhà phát triển của bạn học hỏi và phát triển vai trò của họ. Nhưng nếu bạn không thực sự lắng nghe những gì nhà phát triển của bạn đang nói (hoặc không!) Thì bạn cần phải quan tâm đến vấn đề đó trước tiên.

Tài liệu tham khảo tốt về một người - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Ngắn và ngọt. Excel tại những gì bạn làm - điều này sẽ tăng cường giao tiếp.

Điều gì xuất sắc có ý nghĩa với các nhà phát triển của bạn? .. Đọc, đọc lại, có, thậm chí học PeopleWare

Tất cả các ý tưởng và ý kiến ​​tuyệt vời trong các bài viết ở trên!

Đây là một ý tưởng: gửi nhân viên CNTT của bạn đến các hội thảo truyền thông tại trường cao đẳng cộng đồng địa phương của bạn - tất nhiên là do công ty trả tiền.

Hãy chắc chắn rằng a) các hội thảo có một danh tiếng tốt, và b) không gửi nhân viên của bạn với nhau. Họ sẽ có xu hướng gắn bó với nhau và không hòa nhập với các thành viên khác trong lớp, không chỉ làm giảm giá trị của các hội thảo, mà còn gây ra sự gián đoạn cho những người khác.

Giao tiếp theo định hướng nhóm năng suất là một kỹ năng mà bất cứ ai cũng có thể học, nhưng là một vấn đề tôi cảm thấy thiếu trong hầu hết các con đường kinh viện.

Ý tưởng này không phải là một viên đạn ma thuật, nhưng nó là một mảnh nền tảng tốt của câu đố. Các cộng sự của bạn không chỉ học cách giao tiếp với nhau tốt hơn, mà phần thưởng sẽ là, họ cũng sẽ bắt đầu hiểu và tôn trọng công việc của BẠN hơn (giao tiếp là cốt lõi của PM).

Chỉ cần 2 bit của tôi :)

Chỉ cần đưa ra một câu trả lời từ một khuyến nghị đã được đưa ra trong một vài câu trả lời đã có. Michael Lopp (hay còn gọi là rands ) đã viết về việc quản lý các nhà phát triển và "nhập tâm" vào blog của mình, Rands in Repose , và trong một cuốn sách, Quản lý con người ( nguồn sách ). Cuốn sách chứa hầu hết nội dung được chỉnh sửa từ các bài đăng của anh ấy trước năm 2007 và cung cấp một cách tốt để bắt kịp với các phần liên quan đến quản lý của blog của anh ấy (anh ấy cũng nói về ví dụ như đánh bạc, và liệu bạn có muốn đọc đó là vấn đề khác không). Bài viết của anh ấy nói chung rất hay và thường hài hước, vì vậy có rất ít rủi ro khi đọc anh ấy.

Đưa đội ra ngoài uống bia (và bạn đang mua).

Tôi đến bữa tiệc muộn, nhưng chỉ thấy câu hỏi này.

Một điều tôi không thấy giải quyết rất tốt là:

Grunt không bao giờ nói toàn bộ sự thật với bộ đồ. Rands nói điều này trong DNA nhưng không đề cập trực tiếp, anh ấy thuộc một chủ đề khác.

Bạn đang mặc một bộ đồ, và bạn ký séc. Bạn đại diện cho sự quan tâm của công ty. Bạn không đại diện cho các kỹ sư. Nếu bạn đã làm, bạn sẽ không ký séc của họ, họ sẽ ký séc của bạn.

Điều này tất nhiên không phải là tin tức cho bạn hoặc các kỹ sư. Nhưng khi một kỹ sư biết rằng đưa ra một số vấn đề nhất định - vấn đề - với nơi làm việc của anh ta sẽ gây ra xung đột đáng kể - sự đánh đổi rủi ro / phần thưởng không có lợi cho kỹ sư. Các kỹ sư được trả tiền để sản xuất sản phẩm, không khởi động các cuộc chiến văn hóa nơi làm việc. Tham gia vào đó là một cách nhanh chóng để làm sai công việc.

Vì vậy, một phần của nhiệm vụ quản lý là cung cấp một cách để các kỹ sư cởi mở về các vấn đề, mà không phát sinh phản ứng chính trị & sự nghiệp của công ty. Thật tuyệt khi có tăng lương, sau khi tất cả, và có những công ty khác, nếu điều này không cảm thấy mến.

Tôi ngạc nhiên khi không ai đề cập đến cuốn sách tuyệt vời này đang xử lý chính xác câu hỏi và chủ đề của bạn - "Peopleware: Productive Project and Teams" của DeMarco và Lister . Từ biên tập: các vấn đề chính của phát triển phần mềm là con người, không phải kỹ thuật . Ba đánh giá đầu tiên trên amazon sẽ dễ dàng đủ sức thuyết phục tôi mua cuốn sách này nếu tôi ở trong hoàn cảnh của bạn.

Rất nhiều câu trả lời ở đây có những điểm rất hay, nhưng tôi chỉ muốn đưa vào một vài tài nguyên có thể giúp ích. Tôi đã ở trong một vài tình huống hoặc tự vỡ vụn thành một mớ hỗn độn khổng lồ hoặc được giải quyết rất hiệu quả vì sự liên lạc giữa những người liên quan. Ba cuốn sách đã giúp cá nhân tôi cải thiện kỹ năng giao tiếp của mình, đặc biệt là trong các tình huống căng thẳng cao, nơi có rất nhiều vấn đề:

• Cuộc trò chuyện khó khăn: Làm thế nào để thảo luận về vấn đề gì nhất
• Cuộc trò chuyện quan trọng: Công cụ để nói chuyện khi cổ phần cao
• Các cuộc đối đầu quan trọng: Các công cụ để giải quyết các lời hứa bị phá vỡ, vi phạm các kỳ vọng và hành vi xấu

Từ việc đọc câu hỏi của bạn, tôi nghĩ bạn thấy giá trị của giao tiếp. Cá nhân tôi cảm thấy rằng giao tiếp quan trọng đối với người quản lý hoặc lãnh đạo hơn là kỹ năng kinh doanh hoặc kỹ thuật. Những người mà bạn đang lãnh đạo nên có những kỹ năng cứng mà bạn cần để hoàn thành phần lớn dự án. Một nhà lãnh đạo kỹ thuật hoặc quản lý dự án giỏi sẽ có thể tập trung vào giao tiếp, cho dù đó là trong nhóm hoặc giữa nhóm với khách hàng hoặc nhóm và thực thể kinh doanh (hoặc thậm chí là sự kết hợp của cả ba).

Đọc một vài cuốn tiểu thuyết tuyệt vời cung cấp cái nhìn sâu sắc về quan điểm của lực lượng lao động kỹ thuật:

• Tin tặc, Steven Levy - http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Doumund_Coupland
• Nhà thờ và Chợ, Eric Raymond - http://en.wikipedia.org/wiki/Cathère_and_the_Bazaar

Đây là những điều quan trọng như bất kỳ cuốn hồi ký điển hình về quản lý (Drucker et al).

Tôi đã thực hiện nhiều vai trò khác nhau trong nhiều năm - nhà phát triển, nhà phát triển cao cấp, lãnh đạo kỹ thuật, v.v.

Từ câu hỏi của bạn - khá rõ ràng là các nhà phát triển của bạn không nói cho bạn biết vì họ không nghĩ bạn có thể giúp đỡ.

Điều này có thể là vì 2 lý do.

1. Họ không nghĩ bạn có sức mạnh để sửa chữa mọi thứ. Tuy nhiên, tôi nghĩ điều này là không thể bởi vì sau đó bạn có thể sẽ biết điều đó và cả các nhà phát triển cũng sẽ than vãn về điều đó với bạn.
2. Bạn là kiểu người khi một nhà phát triển gặp phải vấn đề của bạn, thực hiện một hoặc nhiều điều sau đây
   • Khi họ gặp bạn có vấn đề, bạn nói với họ - tôi thích giải pháp chứ không phải vấn đề.
   • Bạn lắng nghe họ một cách tử tế & sau đó giao nhiệm vụ cho họ khắc phục vấn đề. Bạn cho họ nói về những gì một vinh dự cho họ được giao trách nhiệm khắc phục vấn đề. Theo thời gian, các chàng trai của bạn hiểu rằng khi họ gặp bạn có vấn đề, họ sẽ kết thúc với công việc làm thêm, vì vậy họ không gặp bạn khi gặp vấn đề.
   • Bạn phủ nhận nó là một vấn đề. Bạn đưa ra lý do thuyết phục cho việc này. Nhưng khi điều này tiếp tục xảy ra, theo thời gian các chàng trai của bạn biết rằng không có điểm nào tiếp cận bạn với một vấn đề.
   • Bạn nói "Có, tôi hiểu". Bạn nói rằng loại công cụ này thỉnh thoảng xảy ra & không có gì có thể làm. Nếu đây là một mô hình, thì một lần nữa các bạn của bạn hiểu nó.

Nếu đó là bất kỳ hoặc tất cả những điều trên, thì bạn cần phải khắc phục nó.

Điều tôi ghét nhất là mọi người ở giữa tôi, nhà phát triển và người dùng cuối. Các nhà quản lý tốt nhất cho phép tôi làm điều này và thay đổi giải pháp của chúng tôi để phù hợp với những gì tôi nghĩ người dùng muốn hoặc có thể làm với.

Thực tiễn tồi tệ nhất đối với tôi thường là ăn mặc "tốt" - thường thì người quản lý có chính họ, hoặc BA hoặc ai đó viết thông số kỹ thuật mà các nhà phát triển phải giải thích và thực hiện, với thời gian đã được thỏa thuận trước.

Nếu đó là một giải pháp tùy chỉnh thường thì ngay cả các nhà phát triển cũng không biết sẽ mất bao lâu và thường thì khách hàng không có manh mối gì là tốt nhất cho họ. Đó là lý do tại sao phát triển lặp đi lặp lại là tuyệt vời. Không phải là cách mà hầu hết các giao dịch được thực hiện mặc dù vậy một người quản lý giỏi sẽ chiến đấu để làm việc như trên.

Cuối cùng, một số nhà phát triển không giỏi giao tiếp và không thể liên quan đến khách hàng. Chúng có lẽ phù hợp nhất với các vấn đề với các yêu cầu rõ ràng, đặc biệt là các yêu cầu kỹ thuật rõ ràng. Có lẽ bạn cần các nhà phát triển là những người giao tiếp tốt hơn và muốn làm việc để giải quyết các vấn đề bận rộn không phải là kỹ thuật thuần túy.

Nó rất dễ dàng để giữ cho đội hạnh phúc

Hãy cố gắng lắng nghe họ nhiều lần câu hỏi của họ cũng có câu trả lời. tôi sẽ khuyến khích thành viên trong nhóm gặp vấn đề và giải pháp có thể xảy ra.

Đi chơi nhóm là một ý tưởng tốt (có thể là một số kế hoạch trò chơi)

Nếu dự án của bạn yêu cầu một số đêm muộn và cuối tuần làm việc và bạn nghĩ rằng bạn thực sự không thêm nhiều giá trị cho nhóm vẫn là một ý tưởng tốt để dành thời gian để ăn gì đó và đánh giá cao nhóm về những nỗ lực của họ và nếu có thể sắp xếp một số PTO

thực hiện hai tháng 1: 1 với mọi thành viên trong nhóm để đảm bảo rằng họ cảm thấy thoải mái.

Cuối cùng nhưng không kém phần quan trọng, đó có thể là một ý tưởng tốt để bạn hiểu dự án theo chức năng và phần nào về mặt kỹ thuật.

Xin vui lòng cho tôi biết nếu bạn có thêm câu hỏi

Tôi cũng (người Pháp tha thứ cho tiếng Anh của tôi), người có nền tảng kỹ thuật khoa học nhưng không phải là nền tảng phần mềm CNTT ban đầu. Vì vậy, tôi không có mối quan hệ đặc biệt với tiền mã hóa lúc ban đầu nhưng tôi đã là một kỹ sư chất lượng thống kê từ trường Deming, nơi có một sự dạy dỗ khác biệt lớn đối với mọi trường "hiện đại" theo sau mặc dù họ giả vờ thừa kế từ Deming. Tệ nhất là 6 sigma, lean đã tốt hơn nhưng thật không may, điều này đã xảy ra là http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

Phần đầu Six Sigma được Motorola lấy từ Quản lý chất lượng Toyota (TQM) để đạt được sáu mức chất lượng sigma, và sau đó thông qua Allied Signal và GE, nó đã biến thành các dự án của Black Belts dựa trên số liệu thống kê để trở thành một chương trình giảm chi phí cần ROI rõ ràng. Nói cách khác, chúng tôi chê bai chương trình từ triết lý lãnh đạo đến một loạt các dự án một lần để cắt giảm chi phí. Đó là một sự khốn hoàn toàn của bản gốc, và nó hiếm khi dẫn đến sự thay đổi lâu dài, bền vững vì sự lãnh đạo và văn hóa bị thiếu.

Một điều tương tự đã xảy ra với nạc khi nó bị giảm xuống một bộ công cụ (ví dụ: ánh xạ dòng giá trị, bảng KPI, ô, kanban).

Không có cách nào mà Lean và Six Sigma phản ánh suy nghĩ ban đầu của các công ty xuất sắc của Nhật Bản hoặc giáo viên của họ như Deming.

Ngày nay, phong trào Agile giống như nạc (xem khóa học của Jeff Sutherland và sự tôn vinh của ông về Deming http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum / ), nó tốt hơn Waterfall nhưng vẫn còn rất xa so với cách dạy ban đầu của Deming bởi vì thay vì đọc Deming trong văn bản gốc của mình, gurus chỉ gói lại cho anh ta khoảng không bao giờ trích dẫn toàn bộ 14 nguyên tắc Quản lý của mình, và bán các công cụ và hội thảo có ít giá trị của họ.

Bây giờ khi nói đến lĩnh vực phần mềm, có những người một mặt biết các nguyên tắc chung nhưng không có ý tưởng thực sự về cách áp dụng chúng và mặt khác, những người đang viết phần mềm mà bỏ qua các nguyên tắc vì họ chỉ lắng nghe các bậc thầy giả mạo đã bán cho họ các công cụ mà không cho họ biết các nguyên tắc thực sự và thực tế họ nên xây dựng các công cụ quản lý của riêng họ.

Vì vậy, đối với tôi, người quản lý dự án phần mềm nên nỗ lực đi sâu hơn vào hoạt động hàng ngày của mã hóa phần mềm, không chỉ lập kế hoạch trong Microsoft Project (hoặc biểu đồ phân tích với Agile) hoặc trình bày tốt đẹp trong Powerpoint cho quản lý cấp trên mà còn có một số giá trị cho nhóm phát triển. Khi nhóm phát triển gặp sự cố ngay cả khi đó là sự cố kỹ thuật, người quản lý dự án có thể giúp định hướng chẩn đoán bằng mắt bên ngoài. Anh ta có thể xem mã, ngay cả khi anh ta không hiểu chi tiết nhỏ, anh ta có thể hỏi một số câu hỏi ngây thơ có thể khiến các nhà phát triển nhận ra họ không nghĩ về đầu mối đó (tôi có rất nhiều ví dụ cá nhân nhưng nó quá dài nên tôi sẽ thay vì viết một bài viết trên blog của tôi).

Một thứ khác là tôi cố gắng có nhận thức chung về sự tiến hóa trong lĩnh vực này như các khuôn khổ mới, mô hình kiến ​​trúc mới bằng cách đọc các bài viết kỹ thuật. Tôi sẽ tham gia vào một số bài kiểm tra tích hợp, tự mình viết một số tài liệu (những người lập trình ghét vì vậy tôi làm cho họ, tất nhiên họ sẽ nuôi tôi bằng cốt lõi), bất cứ điều gì tôi có thể làm thực tế để giúp đội.

Nói chung, các nhà phát triển cảm thấy như họ đang làm việc chăm chỉ, và đó là sự thật, tôi thường nói với họ rằng tôi đang làm phần dễ dàng bằng cách duy trì sự trừu tượng, tuy nhiên tôi vẫn cố gắng giúp đỡ một cách cụ thể khi cần - vì quản lý vi mô cũng không tốt vì nó có thể tạo ra cảm giác nhiễu.

Kết luận: loại bỏ các khẩu hiệu với các nhà phát triển (thực tế là một trong 14 nguyên tắc của Deming), cho họ thấy bạn quan tâm đến phần mềm cụ thể của dự án, không phải về tài liệu hoặc cuộc họp của bạn với quản lý cấp trên.