Cách tiếp cận nhanh có tương thích với việc có nhà thầu trong đội ngũ nhân viên không?

Một mặt, cách tiếp cận nhanh nhẹn nhấn mạnh một nhóm chặt chẽ giữ nhau có trách nhiệm và chấp nhận quyền sở hữu tập thể của dự án.

Mặt khác, các công ty sử dụng các lập trình viên hợp đồng để họ có thể quản lý các đỉnh và thung lũng tài trợ mà không cần sa thải nhân viên thực tế. Nếu thiếu kinh phí, các nhà thầu là người đầu tiên ra đi, ngay cả khi họ là thành viên tích hợp đầy đủ của đội (và có nhân viên thì không). Các công ty cũng chỉ muốn giữ các nhà thầu xung quanh trong một khoảng thời gian giới hạn. Điều này phần nào được giảm nhẹ bởi khả năng một số nhà thầu có thể được đưa vào như những nhân viên bình thường.

Vì vậy, câu hỏi của tôi về việc có một mâu thuẫn cơ bản của việc có một đội ngũ nhanh nhẹn với sự kết hợp của các nhân viên và nhà thầu, và các trạng thái khác nhau rất lớn đòi hỏi?

EDIT: Các câu trả lời chỉ ra rằng tôi có thể không thể hiện sự căng thẳng mà tôi đang đối mặt tốt, vì vậy hãy để tôi thực hiện một cú đánh khác.

Tôi là một nhân viên cố định. Cách tiếp cận nhanh nhẹn (ít nhất là được thực hiện ở đây) khuyến khích tôi thấy tất cả các thành viên trong nhóm, cả nhân viên thường trực và nhà thầu, là thành viên bình đẳng của một nhóm gắn kết. Cách tiếp cận của công ty đối với các nhà thầu khuyến khích tôi xem họ như những nguồn lực có thể sử dụng mà chúng ta không nên gắn bó quá mức.

Tôi tò mò làm thế nào những người khác đã giải quyết căng thẳng này.

Nhiều đội chỉ làm việc với các nhà thầu nhanh nhẹn. Một số công ty như Th ThinkWorks dựa trên ý tưởng "bán" các đội nhanh nhẹn. Chúng tôi là một nhóm gồm 10 nhà thầu làm việc cho một công ty viễn thông lớn, tất cả từ cùng một công ty hợp đồng.

Nơi tôi thấy vấn đề là khi có 2 công ty cho thuê cơ thể trong cùng một đội ... sau một thời gian, nhóm trở nên có vấn đề (dù sao cũng không liên quan gì đến nhanh nhẹn).

Vâng, điều này chắc chắn có thể làm việc. Bí quyết là:

a) Cấu trúc sắp xếp hợp đồng đúng cách - nếu bạn đang trả tiền cho việc làm việc thì các nhà thầu ít quan tâm đến việc làm nhiều hơn là tát mọi thứ lại với nhau để đặt ít giờ hơn vào "mảnh"
b) Bán cho quản lý của bạn mà không phải mỗi xu họ trả cho đi thẳng vào sản phẩm - sẽ có một số khóa đào tạo / lập kế hoạch / thảo luận sẽ diễn ra trên đồng hồ và cuối cùng là cải thiện sản phẩm nói trên. Đây là phần khó nhất đối với tôi.
c) Chọn đúng nhà thầu - toàn bộ điều nhanh nhẹn bắt đầu được đền đáp nếu bạn có thể liên tục thuê cùng một phi hành đoàn.

Tôi cũng thường cho rằng loại kịch bản này được hỗ trợ rất nhiều bởi các thực hành nhanh nhẹn - nếu bạn có người đến và rời nhóm mọi lúc, có thể kiểm tra, kích hoạt và bắt đầu mã hóa thậm chí còn quan trọng hơn nó .

Để đáp ứng với chỉnh sửa của bạn, có nhiều cặp mắt khác nhau để xem xét tình huống. Vì vậy, để giúp làm rõ bất kỳ sự nhầm lẫn tiềm năng nào, nó giúp hiểu được quan điểm nào được áp dụng.

Từ quan điểm nhóm phát triển, không có sự khác biệt giữa nhà thầu và nhân viên. Tất cả chúng ta đều ở cùng một đội, và tất cả chúng ta đều có chung một mục tiêu. Thêm và loại bỏ các thành viên trong nhóm sẽ có sự gián đoạn tương tự cho dù họ là nhân viên hay nhà thầu. Tất cả các thành viên trong nhóm có trách nhiệm như nhau.

Từ góc độ quản lý, có một sự khác biệt. Công ty đang cố gắng bảo vệ tài nguyên quý giá nhất của mình - nhân viên. Vì lý do đó, công ty sẽ thích giữ nhân viên của mình hơn các nhà thầu. Nếu một nhà thầu chứng minh được giá trị của đội, công ty có thể sẽ cố gắng chuyển đổi nhà thầu thành nhân viên. Những loại quyết định sống ngoài quá trình phát triển hàng ngày.

Các quy trình nhanh nhẹn quan tâm nhiều hơn đến các hoạt động phát triển hàng ngày và quản lý cách bạn cung cấp một sản phẩm chất lượng. Các quy trình nhanh ít quan tâm đến các trách nhiệm quản lý như quyết định thuê / chữa cháy / hợp đồng và quan tâm nhiều hơn đến cách chúng tôi sử dụng các tài nguyên trong tay.

Câu trả lời trước

Nó không phải là một mâu thuẫn cơ bản, nhưng nó có một số thách thức đào tạo. Các quy trình Agile thúc đẩy một môi trường cố vấn rất tự nhiên. Về cơ bản, các lập trình viên nhân viên cuối cùng sẽ luôn là tiếng nói của kinh nghiệm - ít nhất là khi nó liên quan đến văn hóa doanh nghiệp và các chi tiết cụ thể về cách nhóm làm việc nhanh nhẹn.

Có một số lượng lớn các lập trình viên hợp đồng thường xuyên sẽ đưa ra những thách thức tương tự cho dù bạn có nhanh nhẹn hay không. Bạn phải giáo dục nhân viên hợp đồng về cách bạn kinh doanh - điều này bao gồm các quy trình phát triển và thanh toán. Bạn phải giáo dục lập trình viên hợp đồng về thiết kế hiện tại của hệ thống để họ có thể bắt đầu đóng góp nhanh nhất có thể. Các hy vọng là nhân viên hợp đồng là nghiên cứu nhanh chóng, và có thể bắt đầu đóng góp cho dự án thực sự nhanh chóng. Đào tạo tại chỗ (OJT) hoạt động khá tốt ở đây.

Những gì nó có được là bạn sẽ đạt được năng suất ban đầu khi bạn thuê các nhà phát triển và nhà thầu mới cho đến khi họ đạt được tốc độ. Bạn càng làm điều đó, nó càng ảnh hưởng tiêu cực đến hiệu suất của nhóm bạn. Hense, câu ngạn ngữ cũ "Thêm nhiều nhà phát triển vào một dự án đã muộn sẽ khiến nó muộn hơn". (Tôi tin rằng đó là Fred Brooks, trừ khi anh ấy trích dẫn người khác).

Là một nhà thầu quan tâm rất nhiều đến Agile và sản xuất phần mềm xuất sắc, tôi có thể hứa rằng có những nhà thầu ngoài kia sẽ không bao giờ sản xuất mã slap-dash nếu họ có thể giúp đỡ và luôn đặt trái tim vào bất cứ điều gì họ đang làm việc.

Bí quyết là tìm những nhà thầu đó. Tìm kiếm bằng chứng rằng họ đã chuẩn bị để tiến xa hơn một chút - blog, tham gia nói chuyện, đóng góp nguồn mở, hội thảo, khuyến nghị, v.v. Hỏi về kinh nghiệm Agile trước đây của họ và tìm kiếm bằng chứng rằng họ yêu thích công việc của họ. Nhìn chung, chúng tôi hiểu rằng chúng tôi thuê tạm thời và một số người trong chúng tôi thích điều này, sử dụng thời gian giữa các hợp đồng để trau dồi kỹ năng và mở rộng kiến ​​thức.

Nếu bạn có thể tìm thấy các nhà thầu thực sự tuyệt vời, họ sẽ tăng cường sự gắn kết của nhóm của bạn thay vì làm mất giá trị của nó. Giữ chúng tôi tại chỗ trong suốt thời gian của dự án, sau đó cho chúng tôi đi khi nhóm xuống dốc. Chúng tôi sẽ có một kỳ nghỉ và có mặt để khởi động dự án tiếp theo, nếu bạn cần chúng tôi.

Bạn hoàn toàn đúng khi bạn nói rằng các hợp đồng tạm thời ảnh hưởng tiêu cực đến nhóm. Trong thực tế, vận tốc được ràng buộc với một cấu hình nhóm cụ thể. Bất kỳ sự đến hoặc đi mới nào đều làm mất hiệu lực tính toán vận tốc bạn đã làm trong nhiều tháng.

Tuy nhiên, nó có thể hoạt động khi các nhà thầu không tạm thời. Tôi đã làm việc trong dự án nơi nhóm được xây dựng trên 95% nhà thầu với một hoặc hai nhân viên. Các nhà thầu đã ở đó trong 2 hoặc 3 năm cho đến khi dự án được phát hành. Sau khi phát hành các nhân viên làm bảo trì. Cách làm việc này rất phổ biến.

Để tóm tắt:

Agile và đặc biệt là Scrum sẽ cung cấp tất cả các lợi ích của nó trong một nhóm ổn định .