Tôi là trưởng nhóm với hơn 5 nhà phát triển. Tôi có một nhà phát triển (hãy gọi anh ta là A ), một lập trình viên giỏi, người viết mã sạch, dễ hiểu. Tuy nhiên anh ấy hơi khó quản lý, và đôi khi tôi tự hỏi liệu anh ấy có thực sự hoạt động kém hay không.

1. Công ty của chúng tôi yêu cầu các nhà phát triển chỉ ra tiến trình công việc trong trình theo dõi lỗi mà chúng tôi sử dụng, không quá nhiều để giám sát các lập trình viên mà phải giữ cho các bên liên quan được thông báo về tiến trình. Vấn đề là, A chỉ cập nhật tiến trình nhiệm vụ khi nó được thực hiện (có thể 3 tuần sau khi nó được thực hiện lần đầu tiên) và điều này khiến mọi người tự hỏi điều gì đang diễn ra vào giữa tuần phát triển. Anh ta sẽ không thay đổi thói quen của mình mặc dù nhiều lần thăm dò. (Không sao, các nhà phát triển ghét giấy tờ, tôi cũng vậy)
2. 2-3 tháng gần đây anh ấy nghỉ phép khá thường xuyên do nhiều sự kiện khác nhau - hoặc anh ấy bị ốm hoặc phải tham dự rất nhiều sự kiện cá nhân, v.v. (Không sao, những điều tồi tệ xảy ra trong một chuỗi. Đó chỉ là sự trùng hợp)
3. Chúng tôi xác định nước rút, hoặc lộ trình cho mỗi tháng. Và khi bắt đầu chạy nước rút, chúng tôi sẽ thảo luận về số lượng công việc mà mỗi nhà phát triển phải làm trong một lần chạy nước rút và các nhà phát triển phải thiết lập lượng thời gian họ cần cho mỗi nhiệm vụ . Anh ấy thường sẽ không thể hoàn thành tất cả chúng. (Không sao, các nhà phát triển thường xuyên thiếu thời hạn không phải do lỗi của họ).
4. Tôi có trụ sở tại Singapore. Không chắc chắn nếu điều đó quan trọng. Vâng, người châu Á được biết là kín đáo, nhưng điều đó có quan trọng không?

Nếu chỉ có một hoặc hai trong số các sự kiện trên xảy ra, tôi sẽ không cảm thấy rằng A hoạt động kém, nhưng tất cả đều xảy ra cùng nhau. Vì vậy, tôi có cảm giác rằng A đang hoạt động kém và có lẽ-- Chúa cấm --- buông lơi.

Đây chỉ là một cảm giác dựa trên nhiều năm kinh nghiệm làm lập trình viên của tôi. Nhưng tôi có thể sai.

Thật khó để đo lường công việc của một lập trình viên, vì không phải cả hai nhiệm vụ đều giống nhau và thiếu mục tiêu tiêu chuẩn để đo lường sự cam kết của lập trình viên đối với công ty của bạn. Hoàn toàn không thể biết được lập trình viên đang thực hiện công việc của mình hay nghỉ việc. Tất cả những gì bạn có thể làm là tin tưởng họ-- vâng, tin tưởng và trao quyền tự chủ cho họ là cách tốt nhất để các lập trình viên làm việc, tôi biết điều đó, vì vậy đừng bắt đầu một bài giảng về lý do tại sao bạn cần tin tưởng các lập trình viên của mình, cảm ơn bạn nhiều - nhưng nếu họ lạm dụng lòng tin của bạn, bạn có thể biết?

Kết quả:

Tôi đã nói chuyện thẳng thắn với anh ấy về nhận thức của tôi về màn trình diễn của anh ấy. Anh ta phẫn nộ khi tôi đề nghị tôi có cảm giác rằng anh ta không biểu diễn ở mức tốt nhất. Anh cảm thấy đây là một cảm giác hoàn toàn không công bằng. Sau đó tôi trả lời rằng đây là cảm giác của tôi và tôi không biết liệu cảm giác của mình có đúng hay không. Anh ta sẽ không có điều này và kết thúc cuộc thảo luận ngay lập tức.

Trước khi rời đi, anh nói rằng "sẽ cố gắng cống hiến nhiều hơn cho công ty" với giọng điệu rất lạnh lùng. Tôi ngạc nhiên trước phản ứng của anh ấy. Tôi chắc chắn rằng tôi đã xúc phạm anh ta theo một số cách. Dù vậy, không chắc chắn liệu đó có phải là điều đúng đắn để tôi thẳng thắn với anh ấy không.

Câu hỏi của tôi là: Làm thế nào bạn có thể biết liệu các lập trình viên của bạn đang hoạt động kém? Chắc chắn có những người lãnh đạo nhóm kinh nghiệm, những người hiểu rõ hơn tôi về điều này? 

Ghi chú thêm:

1. Tôi ghét vi mô. Vì vậy, tất cả những gì chúng tôi có cho quy trình phần mềm của mình là Sprint (nơi các nhiệm vụ được ưu tiên và được giao, và vào cuối tháng, đánh giá về số lượng công việc được thực hiện). Các nhà phát triển sẽ yêu cầu cập nhật các nhiệm vụ khi họ thực hiện hàng ngày.
2. Không có cuộc họp chờ, hoặc bất cứ điều gì thuộc loại này. Chủ yếu là vì chúng tôi có quyền tự do làm việc tại nhà và mọi người đều trân trọng sự tự do này.
3. Mặc dù tôi là người đặt ra thời hạn, nhưng các nhà phát triển sẽ cung cấp ước tính cho từng nhiệm vụ và tôi sẽ quyết định - dựa trên ước tính - các nhiệm vụ đi vào một giai đoạn nước rút cụ thể. Nếu họ không thể hoàn thành nhiệm vụ vào cuối giai đoạn nước rút, tôi sẽ đẩy họ sang kế tiếp. Vì vậy, về mặt lý thuyết, người ta chỉ có thể thực hiện 1 hoặc 2 nhiệm vụ trong toàn bộ lần chạy nước rút và sau đó đẩy 99 nhiệm vụ còn lại sang lần chạy nước rút tiếp theo và anh ta vẫn ổn miễn là điều này - dưới dạng cập nhật tiến độ công việc hàng ngày

Đây sẽ là một vấn đề dễ dàng đáng ngạc nhiên để giải quyết.

Có một cuộc họp thứ hai với anh ta. Nói với anh ấy rằng bạn chấp nhận rằng có lẽ nhận thức của bạn về thực tế có lỗi. Sau đó, đủ điều kiện với "tuy nhiên, nếu đó là trường hợp thì chúng ta cần phải làm việc cùng nhau để cải thiện nhận thức của tôi." Cuối cùng thách thức anh ta giải quyết vấn đề đó, vì vậy anh ta không cảm thấy bị quản lý vi mô.

Điều này chính xác đã xảy ra với tôi một thời gian dài trước đây. Đối với tôi, vấn đề là tôi không thích khả năng ai đó có thể nghĩ rằng tôi đang tìm kiếm thêm tín dụng chỉ đơn giản là làm công việc của mình. Và điều đó là đủ công bằng, nhưng phải có một vòng phản hồi thường xuyên giữa bất kỳ thành viên nào của nhân viên và quản lý trực tiếp của họ.

Nếu không thì bạn sẽ gặp những vấn đề này.

Thường xuyên, có kế hoạch, 1: 1 là một ý tưởng tuyệt vời. Và, như mọi người đã chỉ ra, standups không cần phải trực giao để làm việc tại nhà. Nhưng họ phải liên quan đến ba câu hỏi: Hôm qua bạn đã làm gì? Bạn lên kế hoạch làm gì hôm nay? Và người mà hầu hết mọi người đều quên ... Điều gì (nếu có gì) đang giữ bạn lại?

Điều đó nói rằng, bạn nên cố gắng ngăn chặn các tình huống trong đó các thành viên trong nhóm không bao giờ làm việc cùng nhau. Tôi đã làm việc trong tình huống đó trước đây và nó gây ra sự ngờ vực trong đội và bên ngoài nó. Có một ngày bình thường mà tất cả các bạn đến văn phòng. Có một cuộc họp thường xuyên nơi mọi người có thể nói lên một số ý tưởng về việc cải thiện các quy trình hoặc bất cứ điều gì.

Đừng biến nó thành một sự kiện báo cáo trực tuyến. Làm cho nó một cơ hội để chỉ nói chuyện. Bạn sẽ ngạc nhiên về những gì bạn học. Nếu có thể, hãy biến nó thành một sự kiện xã hội, đi uống vài ly vào thời gian làm việc như một bài tập gắn kết.

Có rất nhiều lời khuyên tuyệt vời ở đây và tôi không muốn loại bỏ bất kỳ lời khuyên nào, vì vậy tôi sẽ đăng bài này dưới dạng một câu trả lời riêng biệt.

Đầu tiên, rõ ràng với tôi (và rõ ràng là những người khác) rằng bạn chưa phát hiện ra gốc rễ của vấn đề . Bạn đang nhìn chằm chằm vào một triệu chứng và cố gắng chữa trị điều đó. Bạn cần tìm hiểu điều gì gây ra nhiều xích mích giữa bạn và nhà phát triển này. Có lẽ bạn quá độc đoán (Chủ sở hữu sản phẩm của tôi gần đây đã tự mô tả mình có "Quyền lực vô hạn" đối với một dự án và điều đó gây khó chịu cho tôi, mặc dù cô ấy đã cười khi nói điều đó). Có lẽ anh ấy đang gặp vấn đề nghiêm trọng trong gia đình (sẽ giải thích tất cả thời gian nghỉ việc). Có một vấn đề gốc ở đây và cho đến khi bạn tìm thấy nó, điều này sẽ không được khắc phục.

Nắm bắt tốt!

Nếu màn trình diễn của anh ấy có thể tốt hơn, thật tuyệt khi bạn đã xác định điều đó. Tuy nhiên, hãy nhớ rằng nếu hiệu suất kém của anh ấy vẫn là hiệu suất tốt khi so sánh, thì bạn cần phải cẩn thận để tránh mất một nhà phát triển tốt. Các nhà phát triển giỏi rất khó có được, và các nhà phát triển giỏi đòi hỏi một bộ rất cụ thể. Có lẽ hãy xem thử Joel để xem nhu cầu của anh ta có được đáp ứng không.

Tìm nguồn gốc của vấn đề

Nếu anh ấy không hài lòng với điều gì đó liên quan đến công việc anh ấy đang làm, thì bạn chỉ có thể khắc phục bằng cách xác định nguồn gốc của vấn đề. Hãy để tôi rõ ràng, bạn nói lập trình viên của bạn đã viết mã tốt. Điều đó có nghĩa là anh ấy thích lập trình. Điều rõ ràng hơn là anh ấy thất vọng trong công việc (từ mô tả của bạn về cuộc họp), và có lẽ bạn đúng rằng hiệu suất của anh ấy ở dưới mức cần thiết, nhưng đừng giả sử . Hãy nhớ rằng nhiều lập trình viên không có kỹ năng xã hội.

Bạn cũng không hoàn hảo

Hãy nhớ rằng đôi khi bạn sẽ có những xung đột về tính cách, đặc biệt là với những người hướng nội . Nếu điều này hóa ra là xung đột về tính cách, hãy xem xét bạn sẽ đi bao xa để tăng hiệu suất (xem 1)

Tất cả đã nói

Tôi đã viết một bài blog về Quản lý lập trình viên. Tôi nghĩ bạn nên đọc nó.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

Tôi không thể nhấn mạnh đủ phần cuối của bài viết đó.

Nếu nhà phát triển của bạn là bất kỳ tốt, họ muốn viết mã.

Lập trình viên của bạn, ngay cả khi anh ta đang nghỉ ngơi, không muốn bị trì hoãn. Bạn phải tìm ra gốc rễ của vấn đề này, và nó có thể trở thành một thứ đơn giản không thể sửa được và anh ta phải buông tay, nhưng dù đó là gì, bạn không thể đưa ra quyết định sáng suốt mà không xác định được.

Khi nó cảm thấy ai đó đang "hơi khó quản lý" như bạn mô tả, để hiểu rõ hơn làm thế nào để thực hiện và liệu có những vấn đề (khách quan hoặc chủ quan) ảnh hưởng đến năng suất của các thành viên đội dev, hãy xem xét việc thành lập một thực hành thường xuyên 1: 1 của với bạn các thành viên trong nhóm, như được trình bày trong một bài viết xuất sắc Bản cập nhật, Lỗ thông hơi và Thảm họa :

... Tôi không gợi ý rằng cứ 1: 1 là một công việc quanh co để khám phá những thảm họa khẩn cấp ẩn sâu, nhưng bạn muốn tạo ra một nơi hàng tuần, nơi sự bất mãn có thể lặng lẽ xuất hiện. Tỷ lệ 1: 1 là cơ hội để bạn thực hiện bảo trì phòng ngừa hàng tuần đồng thời hiểu được sức khỏe của nhóm của bạn.

... Âm thanh bao quanh chế độ thành công 1: 1 là im lặng. Tất cả các bài nghe, đặt câu hỏi và thảo luận xảy ra trong 1: 1 là bảo trì phòng ngừa quản lý. Bạn sẽ thấy khi quan tâm đến một dự án bắt đầu suy yếu dần và hành động trước khi nó trở thành sự không hài lòng trong công việc. Bạn sẽ nghe về sự căng thẳng giữa hai nhân viên và kiểm duyệt một cuộc thảo luận trước khi nó trở thành một trận đấu la hét trong một cuộc họp. Phần thưởng của bạn cho văn hóa lành mạnh 1: 1 là thiếu kịch tính .

_{Một điểm rất mạnh của bài viết được đề cập là nó độc lập , theo nghĩa là bên cạnh việc giải thích các lợi ích, nó cũng cung cấp một bộ các khuyến nghị thực tế về cơ bản cho phép một người bắt đầu thực hành thường xuyên 1: 1 mà không cần đào sâu vào các nguồn khác (mặc dù đang tìm kiếm thông tin bổ sung sẽ không bị tổn thương, bạn biết).}

Rõ ràng, có một vấn đề truyền thông lớn ở đây. Anh ấy có thể đang làm công việc tuyệt vời nhưng nếu bạn có cảm giác rằng bạn không biết anh ấy định làm gì thì đó chính là một vấn đề. Và nếu bạn không biết anh ấy đang làm gì thì đồng nghiệp của anh ấy cũng có thể không biết. Điều này có thể gây ra vấn đề khi anh ta kiểm tra mã cũ hai tuần của mình. Đặc biệt nếu có bất kỳ ai làm việc trong một khu vực tương tự.

Bạn luôn có thể đề nghị anh ấy kiểm tra / cung cấp cập nhật thường xuyên hơn để giảm thiểu các loại xung đột này. Điều này có thể cho phép bạn thực hiện yêu cầu của mình theo cách giúp đỡ nhóm thay vì "Tôi không biết bạn đang làm gì".

Tôi biết rằng standup nhận được rất nhiều sự ghét bỏ nhưng nó không thực sự phải được giữ trong cùng một phòng. Một cuộc gọi nhanh hoặc một nhóm cập nhật Skype mỗi ngày một lần rất nhanh chóng và giữ cho mọi người trên cùng một trang.

Tôi hiện đang làm việc từ Ấn Độ với một nhóm ở Ireland và tôi không thể tưởng tượng việc không liên lạc với từng người trong số họ hàng ngày và tôi có thể biết đại khái họ đang ở đâu hoặc tôi có thể tìm hiểu rất nhanh.

Vô nghĩa

Cập nhật trạng thái hàng ngày là vô nghĩa. Có người báo cáo 'hôm nay tôi hoàn thành 2,5%', 'hôm nay tôi hoàn thành 3,74%' thật nực cười.

Nó không cung cấp giá trị cho các bên liên quan và gây khó chịu cho những người thực hiện công việc.

Để họ làm việc, không bị xáo trộn.

Vô căn cứ

Trên cơ sở nào bạn cho rằng nhà phát triển A đang 'hoạt động kém'? Nếu công việc của anh ấy / cô ấy được hoàn thành đúng hạn, điều đó sẽ đủ tốt.

Bạn nói rằng bạn ghét vi mô, nhưng những gì bạn đã mô tả chính xác là như vậy.

Công ty của chúng tôi yêu cầu các nhà phát triển chỉ ra tiến trình công việc trong trình theo dõi lỗi mà chúng tôi sử dụng, không quá nhiều để giám sát các lập trình viên mà phải giữ cho các bên liên quan được thông báo về tiến trình. ... Các nhà phát triển sẽ yêu cầu cập nhật các nhiệm vụ khi họ thực hiện hàng ngày.

Điều này là vô nghĩa (xem ở trên) vô nghĩa. Nhóm của bạn không lật bánh mì kẹp thịt, họ đang chế tạo các giải pháp kỹ thuật. Tiến độ không phải là tuyến tính, cũng không dễ dàng đo lường hoặc thậm chí ước tính. Ngay cả khi nó là, các phép đo hoặc ước tính hàng ngày như vậy không có giá trị.

Nguy hiểm

Reexamine là nền tảng cho 'cảm giác' của bạn rằng nhà phát triển A đang 'hoạt động kém'. Bạn nghĩ rằng anh ấy / cô ấy có thể làm tốt hơn, nhưng trên cơ sở bằng chứng gì?

Không hài lòng! = Kém

Tiếp tục như được mô tả, và tại một số điểm, nhà phát triển A có thể sẽ quyết định rằng anh ấy / cô ấy bị đánh giá thấp, đã cung cấp đủ cho công ty và sẽ tìm một công ty khác. Ép 0,01% nỗ lực cuối cùng từ nhân viên ít quan trọng hơn nhiều so với việc giữ chân họ trong thời gian dài.

Các nhà phát triển có thể ghét nỗ lực ghi lại những gì họ làm và cập nhật trạng thái - nhưng đó là một phần của việc trở thành một nhà phát triển chuyên nghiệp. Tôi sẽ đề nghị bạn có thể cố gắng chỉ ra cho anh ấy rằng những cập nhật muộn của anh ấy về nhật ký các vấn đề của bạn đang gây ra nhận thức tiêu cực không cần thiết về công việc của anh ấy. Nếu anh ta không thấy rằng việc anh ta không giao tiếp là một vấn đề về hiệu suất - tốt, bạn là trưởng nhóm của anh ta; nói với anh ấy rằng nó là.

Về ước tính - đó là một vấn đề kinh điển. Tôi khuyên bạn nên đọc "Ước tính phần mềm - Làm sáng tỏ nghệ thuật đen" của Steve McConnell. Trong trường hợp này, bạn đưa ra ấn tượng rằng hầu hết các nhà phát triển của bạn đánh giá thấp. Đây là, tò mò, bình thường, và hiếm khi giải quyết. Tôi sẽ đề nghị rằng bạn có một vấn đề với chính quá trình ước tính, chứ không phải là cá nhân này.

Cố gắng 'đóng vòng lặp' của ước tính-đo lường-đánh giá và cải thiện. Sau đó, nếu các nhà phát triển của bạn đến đúng giờ thường xuyên hơn và cá nhân này thì không, bạn có thể xem xét những gì cần làm về anh ta.

Cuối cùng, có cuộc họp đứng lên. Ngay cả khi đó là bởi Tin nhắn tức thời. Tất cả những gì bạn muốn là mọi người đều biết "những gì tôi đã làm, những gì tôi đang làm hôm nay, bất kỳ vấn đề nào". Và nếu có vấn đề, hãy đưa chúng ngoại tuyến để thảo luận sau. Đó là những gì tôi đã làm trước đây và nó đã thành công cho đội đó.

Điều đầu tiên, tại sao nước rút của bạn dài như vậy? Nước rút không bao giờ vượt quá hai tuần. Tôi nghĩ rằng phần lớn vấn đề của bạn nằm ở đó. Tôi sẽ khuyên bạn nên rút ngắn thời gian chạy nước rút trên cơ sở dùng thử và sau đó phân tích lại câu hỏi của bạn.

Những gì về kiểm tra mã trong? Anh ấy có kiểm tra mã của mình mọi lúc không? Cá nhân tôi nghĩ rằng các lập trình viên không thực sự là những người quản lý và bạn càng cố gắng quản lý, họ sẽ càng thất vọng. Trên thực tế, tôi ghét phải thực hiện các nhiệm vụ cập nhật đó và có lẽ đó là lý do tại sao PM và L dẫn đến đó. Nhưng đồng thời, tôi cũng cung cấp một trạng thái trong các cuộc họp scrum hoặc bất cứ khi nào chúng ta gặp nhau. Bây giờ khi bạn thực hiện một nhiệm vụ, họ có cam kết với dòng thời gian không hay chính bạn là người chỉ định cho họ dòng thời gian?

Do đó, cách duy nhất tôi có thể biết nếu ai đó đang thực hiện là ánh xạ dòng thời gian đã cam kết đến% công việc đã hoàn thành. Bây giờ tất nhiên, nếu ai đó nói rằng anh ta sẽ mất hai ngày để viết một phương pháp cộng hai số, bạn biết có một vấn đề vì vậy dòng thời gian nên là một cái gì đó thực tế và được cả hai bên đồng ý.

Làm theo cách này - Nếu bạn có thể viết một đoạn mã trong một giờ, hãy cho anh ta một giờ + một số bộ đệm. Nếu anh ấy giao nó cho bạn trong khoảng thời gian đó, tôi nghĩ sau đó các bạn đang làm tốt. Nếu anh ta không hỏi anh ta và sau đó tùy thuộc vào bạn để quyết định xem anh ta có cung cấp một lời giải thích hợp lý hay không.

Một điều mà bạn có thể làm là tích hợp một cái gì đó như XPlanner với công cụ tạo phiên bản.

Tôi không nghĩ rằng nghề lập trình vốn đã khác với các ngành nghề khác khi nói đến việc xác định một người nào đó đang chùn bước. Bạn có thể phải đi với ruột của bạn.

Cá nhân tôi nghĩ rằng thật lạ khi A từ chối cung cấp thông tin cập nhật trong nhiều tuần. Tôi là một lập trình viên làm việc tại nhà, và có một hợp đồng ngầm giữa tôi và chủ nhân của tôi rằng tôi cần cung cấp thông tin cập nhật hàng ngày về tiến trình của mình. Đây không phải là những cập nhật "chính thức", nó chỉ là một email ngắn hoặc IM cho anh ấy biết những gì đang xảy ra với phần mềm tôi được trả tiền để tạo. Bản cập nhật mất ít hơn một hoặc hai phút để viết và đóng cửa cho cả hai chúng tôi. Để sửa lỗi, tôi đánh dấu vé là đã được giải quyết trong trình theo dõi lỗi của chúng tôi vào cuối ngày. Đây không phải là những thủ tục khó khăn đối với tôi, mặc dù tôi thích một môi trường làm việc thoải mái với rất ít giấy tờ.

Ngay cả những cập nhật thông thường cũng sẽ được đánh giá cao đến từ anh ấy, tôi chắc chắn. Bạn nghe rất, rất khoan dung trong bài viết của bạn. Nếu bạn đã nghi ngờ rằng anh ta bị trì hoãn trong một thời gian dài, bạn không cần một lý do nào khác để giải quyết vấn đề đó với anh ta.

Nổi bật hàng ngày ngay cả khi qua Skype hoặc trong phòng trò chuyện là cách giải quyết vấn đề này nhưng không phải nếu bạn coi đó là bản cập nhật cho các bên liên quan. Khi mỗi ngày một lần, cả nhóm chỉ kiểm tra để nói những gì họ đang làm, những thách thức họ gặp phải và những gì họ dự định làm tiếp theo, bạn sẽ nhận được một số chiến thắng:

• Cho dù bạn đang lãng phí thời gian vì những lý do tốt hay xấu, thì việc gì đó mất quá nhiều thời gian sẽ minh bạch hơn, khuyến khích các nhà phát triển của bạn yêu cầu giúp đỡ khi họ cần và không tham gia nghiên cứu mà có lẽ không cần phải xảy ra hoặc giải quyết vấn đề cho thử thách của nó khi đầu vào từ các thành viên còn lại sẽ giúp họ đánh bại nó nhanh hơn rất nhiều.

• Bạn, với tư cách là người quản lý có thể thấy nơi mọi người gặp phải rào cản thường xuyên nhất, điều này giúp bạn ước tính tốt hơn và có thể giải quyết các vấn đề cơ bản gây lãng phí thời gian / tiền bạc.

• IMO, nó thực sự giúp nhóm học tập đánh giá thấp các ước tính tốt hơn khi họ có thể thấy mọi người thường mất bao lâu để hoàn thành những việc thậm chí tương đối đơn giản.

• Bạn sẽ thường xuyên được nhắc nhở về những điều cần được truyền đạt theo cách ưu tiên lại khi các thành viên trong nhóm của bạn cho bạn biết họ dự định làm gì tiếp theo.

Vì vậy, hãy quên '% hoàn thành.' Chỉ cần thực hiện quy trình về việc khiến mọi người trung thực với chính mình cũng như với mọi người khác, đưa ra các ước tính tốt hơn / đáng tin cậy hơn khi họ có thêm kinh nghiệm về nó và giúp mọi người có thêm một chút động lực để báo cáo mà không cần phải suy nghĩ - bài tập tuyệt vời về việc đặt một số vào một cái gì đó mà bạn thực sự không thể.

Có vẻ như quản lý cấp trên hiểu rằng thời hạn không phải lúc nào cũng bị ảnh hưởng. Làm nổi bật hàng ngày sẽ cung cấp cho bạn nhiều đạn hơn trên mặt trận đó bởi vì bạn sẽ có nhiều ý tưởng cụ thể hơn về lý do tại sao chúng không bị tấn công.

Và đừng làm điều đó trước tiên. Luôn luôn là một IMO sai lầm. Mọi người cần thời gian để chìm sâu vào vấn đề trước khi họ có thể báo cáo một cách đáng tin cậy hơn về tất cả các vấn đề, IMO.

Những quan điểm nhanh chóng liên quan nhiều đến giao tiếp hơn là trách nhiệm và đơn giản là đặt mục tiêu, hơn bất cứ điều gì là những gì làm cho nhanh nhẹn theo ý kiến ​​của tôi. Phần còn lại tôi có thể lấy hoặc rời đi, đặc biệt là Scrum, mà tôi đã xem là dầu rắn của các bên liên quan / điều hành.

Đánh giá thấp?

Cường độ tăng và chảy trong sự nghiệp của một người. Nếu anh ta đáng giá hơn anh ta, thì hãy nói chuyện với anh ta và cố gắng làm cho công việc của anh ta dễ dàng hơn. Hoặc người khác bắt đầu tìm kiếm một sự thay thế.

Giao tiếp

Đừng dựa vào các cuộc họp hàng tuần. Hầu hết mọi người sẽ không làm một bản hoàn chỉnh. Lịch trình nhiều hơn 1: 1s. Hỏi họ xem mọi thứ đang diễn ra như thế nào, những gì bạn có thể làm tốt hơn và những gì bạn cảm thấy họ có thể làm tốt hơn. Đôi khi, sẽ không có gì để nói, nhưng không sao. Khi có nhiều hơn 1: 1, bạn sẽ tăng khả năng họ sẽ nhớ đề cập đến điều gì đó.

Có một phương tiện liên lạc bền bỉ hơn

Bạn có thể lấy thêm thông tin từ mọi người nếu bạn không cảm thấy như là một việc vặt thêm. Nếu tất cả đều ở xa, hãy để họ sử dụng chương trình trò chuyện với khả năng ghi nhật ký như Hipchat hoặc IRC. Có một phương tiện giao tiếp bền bỉ hơn khuyến khích mọi người nói nhiều hơn. Dẫn dắt bằng ví dụ và nói chuyện thường xuyên, để khuyến khích người khác làm điều tương tự. Ít nhất một lần một ngày, mọi người nói họ đang ở đâu với các dự án của họ. Đôi khi, chỉ bằng cách nhìn vào trò chuyện, bạn có thể cảm nhận được mọi thứ đang tiến triển như thế nào.

Kiểm soát nguồn

Có tất cả mọi người kiểm tra mã của họ hàng ngày. Nếu bạn đang sử dụng git, hãy để họ đẩy đến chi nhánh của chính họ trên repo của công ty. Bằng cách nhìn vào các cam kết, bạn có thể biết họ đang làm như thế nào.

Tách phương tiện khỏi đầu

Các bên liên quan muốn được cập nhật? Giải quyết với các bên liên quan. Một phần công việc của bạn với tư cách là người quản lý là trở thành một chiếc ô, vì vậy các lập trình viên của bạn có thể tập trung vào công việc của họ. Xem qua nhật ký trò chuyện và cam kết, sau đó viết tóm tắt về cách mọi thứ đang diễn ra.

Đây là những gợi ý của tôi:

1. Đổi mới: Trí tưởng tượng và sáng tạo được sử dụng để giảm chi phí và cải thiện tình hình hiện tại.

2. Công ty: Sẵn sàng giúp đỡ người khác hoàn thành mục tiêu của họ

3. Sáng kiến: Cố gắng làm những công việc và công việc không thường xuyên.

4. Tham dự: Vắng mặt hoặc trễ, Dưới tiêu chuẩn.

5. Cảnh giác: Có khả năng hiểu nhanh thông tin và tình huống mới

6. Độ chính xác và chất lượng: Đánh giá mã, giao hàng đúng thời gian, tỷ lệ phát hành).