Làm thế nào tôi nên quản lý một nhóm với các cấp độ kỹ năng khác nhau?


15

Tôi sẽ làm việc trong một dự án phần mềm với một số người bạn của tôi và tôi đã được bổ nhiệm làm trưởng nhóm kỹ thuật. Không ai trong số họ là một lập trình viên tồi cả, nhưng tôi có nhiều kinh nghiệm hơn họ. Tôi cần có khả năng phân phối công việc giữa mọi người trong nhóm, đồng thời đảm bảo rằng chúng tôi không giẫm lên ngón chân của nhau; rằng họ đáp ứng các tiêu chuẩn tương đối cao về chất lượng và khả năng mở rộng mà chúng tôi cần để làm cho dự án này thành công, mà không yêu cầu tôi phải xem xét mọi thứ họ cam kết.

Làm thế nào tôi nên duy trì các tiêu chuẩn trong khi tránh quản lý vi mô? Liệu có đủ để tạo một số sơ đồ, lên lịch một số đánh giá mã và tin tưởng rằng tôi có thể sửa bất cứ thứ gì chúng có thể phá vỡ hay tôi nên đi theo lộ trình TDD và viết các bài kiểm tra rõ ràng cho nhóm để thỏa mãn?


11
Có một đội có cùng cấp độ kỹ năng?
P.Brian.Mackey

@ P.Brian.Mackey: Ý tôi là khá khác biệt.
Jon Purdy

@Jon: Tôi thực sự hy vọng bạn biết những gì bạn đang nhận được vào bản thân mình. Hãy chắc chắn rằng họ có một số "thịt lợn" trong thỏa thuận từ việc đi (!). Tôi có cảm giác mơ hồ bạn cần một người có nhiều kinh nghiệm ở đó với bạn, nếu, dường như, họ thậm chí không thể viết bài kiểm tra đơn vị và (!) Không tự mình phát hiện ra cách làm điều đó: Tôi nghĩ rằng có lẽ bạn đang nói quá kỹ năng của họ. Không cần phải nói, giả sử nhiều năng lực hơn trường hợp không phải là một kỹ thuật quản lý dự án tốt.
Henrik

@Henrik: Tôi biết những gì tôi đang tham gia, tôi không có nhiều kinh nghiệm quản lý các nhà phát triển khác và muốn nhận một số lời khuyên về cách đảm bảo mọi việc diễn ra suôn sẻ. Tôi hoàn toàn tự tin vào khả năng của họ và tôi nghĩ mọi người đang đọc nhiều tiêu cực hơn vào câu hỏi của tôi so với thực tế tôi đặt ở đó. Tôi mới tham gia lập trình được hơn một nửa cuộc đời, vì vậy tôi đã phạm rất nhiều sai lầm mà những kẻ có kinh nghiệm 2 năm 3 này vẫn chưa mắc phải.
Jon Purdy

Là cho một công ty hoặc dự án phụ?
Marcie

Câu trả lời:


10

Bạn nên xem lại một số mã của họ và để họ xem xét lẫn nhau. Không phải bạn muốn trở thành Cảnh sát Kiểm tra, mà muốn cung cấp phản hồi thường xuyên nhất có thể. Là một nhà phê bình có thể củng cố sự hiểu biết của họ. Hãy để họ xem lại mã của bạn là tốt. Hãy là người mẫu.

Lưu ý bên lề: không nên có bất ngờ trong quá trình đánh giá anual.


2
+1 cho "Trở thành người mẫu." Đó là lợi ích lớn nhất tôi từng thấy trong các bài đánh giá mã: học hỏi từ sự khéo léo của người khác. Điều đó, và bắt lỗi khiếm khuyết thường xuyên.
Peter K.

1
Một công cụ để xem xét mã trong khi là "luyện ngục" là [ code.google.com/p/gerrit/]
Henrik

9

Trên tất cả : truyền đạt kỳ vọng của bạn và thiết kế theo nhiều cách khác nhau có thể. Sơ đồ là tốt cho một số; giao diện xác định làm việc cho người khác; lập trình cặp cũng hoạt động; đánh giá mã chính thức cũng có thể giúp một số người.

Tôi cũng khuyên bạn nên sử dụng tự động hóa càng nhiều càng tốt:

  • Yêu cầu nhóm sử dụng một công cụ như NDepend hoặc Resharper nếu bạn ở trong vương quốc .Net. Tinh chỉnh các quy tắc tiêu chuẩn nếu bạn không thích chúng.
  • Tự động hóa thử nghiệm của bạn nhiều như thực tế.

Thật khó để tranh luận với một trường hợp thử nghiệm thất bại hoặc công cụ kiểm tra tự động, miễn là chúng được thiết lập tốt.


3
Lập trình viên xấu có thể thiết lập trường hợp kiểm tra xấu?
JeffO

1
Các công cụ như Resharper là def. gọn gàng, nhưng chắc chắn không miễn phí. Kiểm thử tự động yêu cầu viết mã có thể kiểm tra có thể đặt ra một yêu cầu không thực tế nếu mức độ kỹ năng của họ vượt quá mức.
P.Brian.Mackey

@Jeff: Họ không phải là những lập trình viên tồi, chúng tôi chỉ có những nền tảng khác nhau và tôi có nhiều năm với họ. Có lẽ tôi và anh chàng giàu kinh nghiệm nhất sẽ viết bài kiểm tra, nếu có.
Jon Purdy

@Jeff O: Sau đó đưa họ ra khỏi đội.
Peter K.

@ P.Brian.Mackey: Không có thông số kỹ thuật về các công cụ miễn phí trong câu hỏi. Nếu mã không thể kiểm tra được, hãy đưa họ ra khỏi đội. Cố gắng chỉ cho họ cách viết mã có thể kiểm tra và nếu họ không cải thiện được gì, hãy đưa họ ra khỏi nhóm.
Peter K.

5

Nếu bạn thực sự làm việc với nhiều cấp độ kỹ năng khác nhau trong cùng một dự án thì sẽ có một số vấn đề. Câu hỏi là khi nào bạn đối phó với họ? Họ sẽ viết mã xấu đến mức bạn có thể tốt hơn nếu không có sự trợ giúp của họ? Điều này sẽ tạo ra căng thẳng cá nhân? Bạn sẽ kết thúc tình bạn? Những câu hỏi không ai có thể trả lời ngoài bạn.

Giả sử mọi người sẽ ở lại trong đội, tôi khuyên bạn nên chia nhỏ các bài tập thành các phần nhỏ (phần lớn hơn sẽ chuyển sang các anh chàng lành nghề hơn) và để các nhà phát triển lành nghề nhất tái cấu trúc khi bạn hoàn thành. Hãy chắc chắn để chạy QA trong khoảng thời gian chặt chẽ, đều đặn. Điều này khá gần với những gì xảy ra trong thực tế.


3

Càng nhiều càng tốt, tránh xa cỏ dại. Trong bất kỳ nhóm nào, nếu bạn là người lãnh đạo, bạn cần lưu một đoạn băng thông nhất định cho các cuộc khủng hoảng và bức tranh lớn. Các sơ đồ là tốt và các tiêu chuẩn mã hóa luôn lành mạnh, nhưng thiết lập các quy trình nơi mọi người kiểm tra công việc của nhau thậm chí còn tốt hơn (kiểm tra chéo, đánh giá ngang hàng, lập trình cặp). Không phải ai trong nhóm cũng cần trở thành một ngôi sao - nhóm thường có thể khắc phục mọi điểm yếu trong các cá nhân.

Điều tôi khuyên bạn là bạn nên chống lại sự thôi thúc, càng nhiều càng tốt, để nói cho mọi người biết những lỗi bạn thấy trong mã hóa của họ - thay vào đó, dẫn họ đến việc tự nhìn thấy nó. Vẫn là một phần của đánh giá hợp tác về công việc phát triển, nhưng hãy đảm bảo rằng bạn không đóng góp nhiều hơn các thành viên khác. Thay vào đó, hãy nỗ lực thêm vào việc khuyến khích mọi người nhìn thấy những gì bạn nhìn thấy và đưa ra nhiều lời giải thích về lý do tại sao những điều bạn thấy quan trọng.

Đừng lo lắng quá nhiều về sự chồng chéo - ngoài sự đột phá hợp lý của công việc, bạn có thể yêu cầu các thành viên trong nhóm tự kiểm tra và sau đó chỉ cần xác minh rằng giao tiếp đã xảy ra. Nhóm sẽ nhanh chóng bắt đầu nhìn nhau như một cách để đạt được sự đồng thuận và điều đó làm cho công việc của bạn dễ dàng hơn khoảng 20 lần - sau đó, tất cả những gì bạn phải làm là phá vỡ mối quan hệ khi các khu vực chính không đồng ý.

Sau đó tiết kiệm nỗ lực của bạn để nhìn vào nhóm tập thể. Mỗi người sẽ có một số điểm mạnh tuyệt vời và một số điểm yếu hấp dẫn. Lý tưởng nhất là bạn sẽ bắt đầu ném công việc vào những người phù hợp với điểm mạnh của họ trong khi vẫn cho họ cơ hội khắc phục điểm yếu theo cách không vô hiệu hóa năng suất của đội.

Ngôi sao vàng cuối cùng của đội ngũ lãnh đạo nhóm đang khiến mọi người nhận ra điểm yếu của họ theo cách mà họ có động lực và đủ thông tin để bắt đầu sửa chữa chúng.


2

Hãy ngồi xuống và thảo luận về các công nghệ và bộ công cụ mà mọi người trong nhóm đồng ý. Một số người có thể có nhiều kinh nghiệm hơn trong các công cụ đã thỏa thuận so với những người khác trong nhóm, vì vậy những người có kinh nghiệm hơn phải sẵn sàng và đồng ý chia sẻ kinh nghiệm và kiến ​​thức với những người còn lại.

Thảo luận, Đồng ý, Viết ra, Mô hình hóa và truyền đạt các tiêu chuẩn (như quy ước đặt tên, thực hành mã hóa tốt nhất và cấu trúc thư mục).

Làm kiểm tra liên tục và thường xuyên và kiểm tra QA. Thông báo cho người đó càng sớm càng tốt khi bạn thấy sự không nhất quán.


2

Tôi sẽ nói 'hãy lấy người có kinh nghiệm nhất trong nhóm để tổ chức nó', nhưng có vẻ như bạn là người đó.

Nếu bạn có thể, hãy chia dự án thành hai cấp độ. Lớp ứng dụng / lớp trình điều khiển là một sự phân chia tốt. Tạo thành hai nhóm nhỏ trong nhóm của bạn và khiến một người trong mỗi nhóm chịu trách nhiệm về cấp độ đó. Điều đó có thể làm việc cực kỳ tốt.

Từ chức chính mình với nó. Bạn sẽ phải xem lại mọi thứ họ cam kết, đặc biệt sớm. Nếu mọi thứ đang diễn ra sôi nổi, bạn sẽ chỉ cần chú ý vào mã. Việc xem xét sẽ không làm bạn mất nhiều thời gian, và nó sẽ mang lại cho bạn rất nhiều điều tự tin đang diễn ra tốt đẹp. Nhiều khả năng bạn sẽ thấy ai đó đang sử dụng semaphores không chính xác hoặc đang viết phiên bản riêng của chức năng thư viện hoặc một số sự điên rồ như vậy. Kinh nghiệm của tôi là bạn phải xem mã vì nó đang được viết cho các vấn đề về mã trong nụ.


Đồng ý về phần xem xét mã. Bạn phải hướng dẫn họ càng sớm càng tốt.

2

Những gì thường được mong đợi của một lãnh đạo kỹ thuật trong công ty của bạn? Tôi là người quản lý và đã ở vị trí này một vài lần và sắp làm lại từ đầu tuần này (thuê người mới và những người khác tham gia vào một nhóm gồm những người có kinh nghiệm 20 năm và 4 năm).

Tôi là người quản lý và có thể là người lãnh đạo kỹ thuật (trong vài năm qua, tôi đã đóng vai trò thứ hai để phát triển sự lãnh đạo trong nhóm. Trong mọi trường hợp, một số suy nghĩ:

  • Đánh giá các kỹ năng và điểm yếu của toàn đội.
  • Tạo một kế hoạch tăng trưởng - Trong khi trọng tâm của bạn đang phát triển những thành viên yếu nhất, bạn thực sự nên tập trung vào việc phát triển mọi người với tư cách cá nhân và theo nhóm.
  • Truyền đạt kế hoạch này và đặt kỳ vọng của mọi người.
  • Phân phối việc học và xác nhận trên toàn đội. Trong khi bạn, với tư cách là người lãnh đạo, chính công việc của tôi, phân phối công việc sẽ giúp các thành viên nhóm cao cấp hơn của bạn trở thành người lãnh đạo.
  • Tạo một vòng phản hồi thường xuyên. Gặp gỡ với các thành viên trong nhóm để đánh giá tiến độ và cung cấp thông tin phản hồi.
  • Điều chỉnh kế hoạch, khi cần thiết, để đảm bảo thành công.
  • Nếu ai đó không làm việc và sẽ không, ngay cả với sự giúp đỡ hợp lý, hãy sẵn sàng đẩy họ ra. Điều này rất phức tạp, nhưng nếu bạn đã đặt kế hoạch, kỳ vọng và cung cấp vòng phản hồi, bạn sẽ ở vị trí tốt hơn nhiều để thực hiện.
  • Giữ một mắt trên tinh thần đồng đội. Loại tình huống này có thể làm những điều tuyệt vời để phát triển một nhóm hoặc tách nó ra. Kỹ năng lãnh đạo và đầu tư của bạn trong nhóm sẽ đi một chặng đường dài để thiết lập kết quả.

1

Hãy thử xem xét những gì cần xác định "Kiến trúc phần mềm". Tạo các mô-đun có thể phát triển riêng là một trong những lý do chính để thực hiện thiết kế và phân tích trả trước. Tôi biết rằng làm loại công việc này là không hợp thời, nhưng nó hoạt động trong mọi trường hợp, trái ngược với một số trường hợp mà các phương pháp phát triển mới hơn tán thành.


1

Là nhà phát triển giàu kinh nghiệm nhất trong nhóm, tôi mong đợi từ sự huấn luyện nặng nề của bạn .

Hãy để nhóm tự phân công công việc cho mình bằng kanban , và sau đó dành cả ngày của bạn để lập trình cặp với mỗi người trong số họ.

Khi bạn thấy một thói quen xấu hoặc một cái gì đó họ nên (tất cả) nhận thức được, hãy dừng mọi thứ lại và vẽ lên bảng trắng.

Sau một vài tuần, bạn sẽ có thể chậm lại trong việc huấn luyện nặng vì các kỹ năng chung của đội sẽ tiếp cận với bạn.


1

Có một vài danh sách khác nhau mà tôi muốn xem xét từ vị trí của bạn:

  1. Làm thế nào để tôi biết nhóm này. Bạn có biết điểm mạnh và điểm yếu của mọi người trong đội không? Bạn có biết làm thế nào để tận dụng tốt nhất của mỗi người? Bạn có biết cách phân chia công việc một cách tương đối công bằng cho mọi người không? Những loại câu hỏi này là một cái gì đó để hỏi và hiểu rằng có thể có sự thay đổi trong các danh sách này theo thời gian vì một số người có thể phát triển một số kỹ năng có thể thay đổi cách họ được xem. Khi bạn được bổ nhiệm có kỳ vọng rằng một số người trong nhóm có bạn không? Câu hỏi cuối cùng đó có thể khó khiến mọi người trả lời trung thực nhưng nó có thể giúp ích rất nhiều nếu điều đó có thể được tiết lộ và thảo luận một cách có ý nghĩa mà không khuấy động sự xúc phạm hoặc phẫn nộ có thể khá dễ dàng nếu một số điều được thảo luận là rất cá nhân với một số người Mọi người. Đừng cố lấy ý kiến ​​cá nhân trong một cuộc họp nhóm,

  2. Làm thế nào để tôi biết bản thân mình. Những yếu tố từ nền tảng của bạn đang sử dụng để yêu cầu một số cơ quan kỹ thuật ở đây? Những điểm mạnh và điểm yếu nào bạn mang đến cho đội? Bạn có dự kiến ​​sẽ được vào các chiến hào thường xuyên? Có thực hành nào bạn thấy rằng bạn muốn giới thiệu với nhóm này để giúp họ điều khiển chúng không? Có những dấu hiệu cảnh báo mà bạn nhớ từ kinh nghiệm trong quá khứ có thể hữu ích để xem liệu có bất kỳ thứ nào trong số này đang bắt đầu xuất hiện trong công việc mà nhóm đang làm không.

Theo một cách nào đó tất cả sôi sục để giao tiếp. Chúc may mắn!


0

có một bài thuyết trình (hàng tuần) thường xuyên về một số chủ đề công nghệ và để nó xoay quanh nhóm. Bằng cách đó mọi người sẽ học được điều gì đó. Và để các thành viên trẻ tuổi trình bày quá, không có cách nào tốt hơn để thực sự hiểu một cái gì đó hơn là dạy nó. Bạn có thể phải giúp họ chọn chủ đề.

Một số huấn luyện về cách nói chuyện có thể dành cho tất cả mọi người. Tôi đã có một giáo sư đại học đã làm điều đó cho tôi và nó rất hữu ích.

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