Làm thế nào để bạn quản lý các dự án còn lại của nhân viên khác? [đóng cửa]

Nó xảy ra rằng một số người đột nhiên rời khỏi công ty. Bây giờ công việc của anh ta cần phải được hoàn thành và bạn đang được giao nó. Không biết anh ấy đã làm gì (đã hoàn thành 90% hay 9%), làm thế nào để bạn quản lý phần còn lại?

1. Tôi có nên bắt đầu từ đầu không? Điều gì nếu nó được thực hiện 90%?
2. Tôi có nên thử và hiểu bất cứ điều gì anh ấy đã làm không? Điều gì nếu nó chỉ là vô nghĩa?

Để tìm ra những gì cần làm, bạn cần phải biết những gì bạn có, và nó có hình dạng tốt như thế nào.

Vì vậy, hãy bắt đầu với việc xem nhanh tất cả các nguồn và xem những gì bạn có. Nếu nó rõ ràng một cách sinh động thì dễ nhất là chỉ cần hoàn thành những gì còn thiếu. Làm các bài kiểm tra đơn vị để tìm hiểu những gì hoạt động và những gì không.

Nếu nó không rõ ràng một cách rõ ràng thì hãy bắt đầu tìm hiểu những gì hoạt động với các bài kiểm tra đơn vị mới. Nếu điều này là không thể thì hãy đưa ra với trưởng nhóm của bạn rằng bạn có một vấn đề và bạn có thể không thể làm được. Sau đó, anh ta có thể quyết định liệu công việc còn lại có nên được cứu vãn hay không, nếu nó quá tệ và bạn cần làm lại nó.

Ngoài những gì người khác viết, tôi sẽ đề nghị bạn nói chuyện với bất cứ ai có liên hệ trực tiếp với anh chàng. Tôi hiểu từ mô tả của bạn rằng anh ta đang làm việc một mình, anh ta có phải đã báo cáo với ai đó không? Và có thể có nhân viên QA đã kiểm tra những gì anh ta đã tạo ra ... Những người này (thường) nên có ít nhất một ý tưởng sơ bộ về việc anh chàng đã đi được bao xa với dự án của mình trước khi rời đi. Tất nhiên trừ khi thông tin / sản phẩm do anh cung cấp hóa ra hoàn toàn không đáng tin cậy, góp phần vào việc sa thải anh.

Thảo luận điều này với người quản lý của bạn và phân bổ khung thời gian cho việc thăm dò / kiểm tra ban đầu của mã còn sót lại và hiểu đặc tả và yêu cầu. Đây có thể là khoảng một ngày cho một dự án theo thang thời gian của một vài người, nhiều nhất là một tuần cho một dự án của một hoặc nhiều người làm việc, v.v.

Sau khi khám phá ban đầu này, bạn nên có một ước tính sơ bộ về

• sản phẩm này phải làm gì
• Hiện tại nó có thể làm gì và tốt như thế nào,
• mất bao nhiêu thời gian và rủi ro để viết lại từ đầu,
• mất bao nhiêu thời gian và rủi ro để hoàn thành những gì đã làm.

Sau đó, bạn có thể ngồi xuống với người quản lý của bạn một lần nữa để đưa ra quyết định.

Theo kinh nghiệm của tôi đây không phải là một tình huống hiếm gặp. Thật không may, bạn thực sự có hai vấn đề ở đây :

1) Phần còn lại của dự án này 2) Những lý do khiến bạn gặp rắc rối này ngay từ đầu

Đối với (1) bạn cần xem xét kích thước / độ phức tạp của dự án. Nếu đó là một tuần làm việc, có lẽ bạn cần phải bắt đầu lại. Nếu đó là công việc đáng giá trong một năm, bạn có thể cần phải xem những gì bạn có thể cứu vãn từ mã hiện có.

Dù bằng cách nào, bạn cần thực hiện các bước sau ngay lập tức:

a) Nói với người quản lý của bạn rằng bạn có một vấn đề lớn

b) Nhận thông số kỹ thuật của dự án và hiểu rõ về những gì bạn cần đạt được - hoặc nói chuyện với các nhà tài trợ dự án nếu không có thông số kỹ thuật.

c) Nói chuyện với các nhà quản lý / khách hàng, v.v. và tìm hiểu xem có ai có / nghĩ rằng họ có bất kỳ ý tưởng nào về tình trạng của dự án không.

Khi bạn đã thực hiện điều đó, bạn sẽ ở vào vị trí để bắt đầu kiểm tra mã / đưa ra chiến lược.

(Tôi không nghĩ các bài kiểm tra đơn vị sẽ giúp bạn nhiều - họ có thể cho bạn biết nếu các chức năng đã được viết thực sự hoạt động, nhưng họ không cho bạn biết những chức năng nào nên có ở đó.)

Những gì tôi không có tiếp theo là có được một cái nhìn tổng quan về kiến ​​trúc của mã tồn tại và cách điều này ánh xạ tới vấn đề được xác định trong thông số kỹ thuật. Sau đó, chúng tôi làm việc với các thành phần phụ của từng thành phần chính này và xem chúng phù hợp với bức tranh lớn như thế nào. Làm điều này sẽ cho bạn biết (đại khái) những thành phần nào bị thiếu.

Một khi bạn biết những gì tồn tại, bạn cần bắt đầu kiểm tra mã hiện có để xem nó có làm những gì nó phải làm hay không.

Khi bạn đã hoàn thành tất cả những điều này, bạn sẽ ở vào vị trí để ước tính số lượng công việc còn lại phải làm.

Về phần (2) công ty của bạn có thể cần xem xét các chính sách tuyển dụng / chính sách giữ chân nhân viên, tìm cách giữ cho các lập trình viên có trách nhiệm với tiến độ.

Cuối cùng, bạn cũng nên xem xét làm thế nào bạn có thể ngăn chặn điều này xảy ra với công ty nếu bạn vội vàng rời đi.

Bạn chắc chắn cần phải thử và chạy phần mềm để xem những gì hoạt động và những gì không.

Sau đó, bạn sẽ cần phải xem xét những gì tài liệu đã được để lại. Có yêu cầu bằng văn bản? Có các nhiệm vụ cụ thể - các nhiệm vụ được theo dõi theo một cách nào đó? Có ai đã thử nó chưa - nếu vậy, họ sẽ biết cái gì đã làm và cái gì không.

Tôi nghĩ rằng một kế hoạch hành động sẽ là:

1. Đánh dấu những yêu cầu nào đã được hoàn thành (bằng cách chạy nhanh qua hệ thống như một người thử nghiệm)

2. Nhìn vào mã - bạn có thể hiểu ý nghĩa của nó không? Nó có được viết tốt không?

Rõ ràng nếu nó được thực hiện 90% và mã được viết tốt, bạn sẽ hoàn thành nó.

Chưa được đề cập.

Cố gắng liên lạc với anh chàng mà nhảy. Nó không thể trong mọi trường hợp. Nhưng nếu anh ấy khỏe mạnh và ít nhất thích một chút công việc của mình, anh ấy sẽ giúp đỡ và cho bạn một câu trả lời trung thực về sự tiến bộ và những phần còn thiếu. Và anh ấy có thể giải thích bức tranh lớn cho bạn.

Xin chúc mừng, đây là cơ hội để bạn tỏa sáng và tạo ấn tượng thực sự tích cực với sếp của bạn. Những gì bạn có ở đây là một cơ hội vô giá. Vậy bạn cần làm gì và làm thế nào?

Đầu tiên, lấy mã. Anh ta có thể đã không kiểm tra tất cả mọi thứ trong (anh chàng đã làm điều này với chúng tôi đã không) và do đó, có người có quyền quản trị rút nó ra khỏi máy tính của anh ta và kiểm tra nó cho bạn.

Tiếp theo xử lý vấn đề. Lấy các yêu cầu và lưu ý phần nào dường như có mã được viết và phần nào không. Đây là danh sách sơ bộ những gì chưa hoàn thành. Nó sẽ phát triển khi bạn làm bước tiếp theo. Sau đó đi qua mã và đánh giá nó và chạy nó và xem những gì hiện đang hoạt động và những gì dường như không hoạt động mặc dù có mã được viết. Thêm các phần không làm việc vào danh sách. Tìm kiếm các bài kiểm tra đơn vị (Tôi sẽ ngạc nhiên nếu bạn tìm thấy chúng, những người bảo lãnh ngay trước hạn chót vì họ biết rằng họ đang thất bại có xu hướng không viết chúng). Bây giờ ít nhất bạn có một ý tưởng tốt về việc nó xấu như thế nào. Cũng xem qua các yêu cầu và xem những câu hỏi bạn cần trả lời. Rất nhiều thời gian, thất bại của dự án xảy ra do kết quả của những yêu cầu kém và một nhà phát triển không muốn (vì vô số lý do) để đặt thêm câu hỏi.

Bây giờ bạn thực hiện kế hoạch dự án của bạn. Bắt đầu với một danh sách các câu hỏi bạn có từ các yêu cầu (viết chính thức trong tài liệu) và sau đó liệt kê những điều bạn cần làm để hoàn thành công việc. Hãy ước tính khoảng thời gian mỗi người sẽ mất. Xác định xem những gì hiện đang tồn tại có thể cứu vãn được (và nếu không, hãy chuẩn bị để biện minh tại sao không).

Bây giờ có một cuộc họp với người quản lý dự án (và sếp của bạn nếu họ là hai người khác nhau) và nói với anh ấy hoặc cô ấy những tin xấu. (Hầu như luôn luôn là tin xấu khi ai đó rời đi đột ngột và bạn phải chọn nơi họ rời đi, các nhà phát triển giỏi không để mọi người rơi vào tình trạng khó khăn - ít nhất họ để lại một danh sách những gì họ đã làm và những việc còn lại phải làm . Ngoại lệ có thể là nếu ai đó rời đi do vấn đề sức khỏe.) Trong cuộc thảo luận của bạn, bạn có thể nhận được một số câu trả lời bạn cần và bạn và Thủ tướng có thể làm lại kế hoạch dự án một chút.

Theo dõi cuộc họp bằng cách gửi Thủ tướng và các bên liên quan quan trọng khác (Thủ tướng sẽ xác định ai), một bản sao các câu hỏi của bạn cần được trả lời và kế hoạch dự án bạn đã thực hiện.

Bây giờ bạn có những gì bạn cần để bắt đầu mã hóa thực tế, vì vậy hãy bắt tay vào làm.

Trong khi đó, có lẽ bạn đã được kéo ra một cái gì đó khác để cứu vãn dự án này. Hãy chắc chắn rằng công việc của bạn đã được định hình để người khác nhận hoặc cho bạn nhận sau khi bạn hoàn thành dự án. Điều đó có nghĩa là các loại điều tương tự, một tài liệu mà bạn nói những gì đã được thực hiện và không phải là một kiểm tra tất cả mã nguồn (không cần thiết cho thân cây nếu không được thực hiện, nhưng ở đâu đó người khác có thể truy cập nó .

Nếu bạn chưa bị loại bỏ công việc hiện tại, thì bạn cần phải làm việc với sếp của bạn bao nhiêu thời gian trong ngày làm việc bạn sẽ dành cho mỗi công việc. Đây là một trong những thời điểm mà có thể cần thêm giờ và sẽ được đánh giá cao. Càng gần với thời hạn thực tế, quản lý càng tuyệt vọng, bạn có thể có thể trả hết tiền làm thêm giờ hoặc một khoản tiền thưởng lớn nếu thời hạn kết thúc. Nếu công việc này sẽ trì hoãn đáng kể công việc khác, thì bạn cần chắc chắn rằng các bên liên quan trong dự án đó nhận thức được điều đó.

Một khi bạn thành công trong việc cứu vãn dự án, hãy đảm bảo khoe khoang về điều đó trong bài đánh giá hiệu suất tiếp theo của bạn.