it-swarm-vi.com

Có phải bình thường để lập trình viên làm việc trên nhiều dự án cùng một lúc

Trong một công việc hiện tại tôi có hai dự án để làm việc. Đầu tiên là hệ thống rất lớn và hệ thống thứ hai nhỏ hơn nhưng cũng lớn (dự án đầu tiên đang được phát triển trong 12 năm, thứ hai trong 4 năm).

Lúc đầu tôi chỉ làm việc với dự án đầu tiên và đang cố gắng làm quen với nó. Sau đó tôi được chuyển đến dự án thứ hai và thử ở đó, vì vậy kiến ​​thức của tôi về dự án đầu tiên trở nên mờ ám. Bây giờ tôi phải làm việc trên cả hai dự án cùng một lúc.

Điều này rất khó đối với tôi vì mặc dù cả hai đều sử dụng Java, nhưng họ sử dụng các khung khác nhau và số lượng mã và logic nghiệp vụ để hiểu là rất lớn nên tôi thực sự không thể giữ cả hai dự án đó trong đầu.

Điều đó có bình thường không và tôi nên làm quen với nó, mặc dù chuyên môn của tôi trở nên rất bí ẩn, điều gì sẽ không xảy ra nếu tôi chỉ làm việc trong một dự án duy nhất? Hoặc tôi nên nêu lên một mối quan tâm hoặc có thể thay đổi nhà tuyển dụng?

40
user1449

Tôi hoàn toàn không đồng ý khi mọi người nói "có, đa tác vụ là bình thường"

Đó là không bình thường! Hoàn toàn không, việc nhà phát triển thực hiện đa tác vụ trong một số dự án là điều không tự nhiên (tôi sẽ giải thích thêm sau). Mặt khác, đa tác vụ là rất chung trong số các nhà phát triển. Đây chắc chắn là thứ bạn nên làm quen. Vì vậy, câu trả lời thực sự cho câu hỏi của bạn là: làm thế nào để đa tác vụ?

Trước hết, bạn không nên đơn giản chấp nhận số phận của mình vì "bạn là một nhân viên xuất sắc" và điều đó có nghĩa là bạn cần phải đảm nhận nhiều nhiệm vụ hơn mức bạn có thể đảm nhận. Không hề, bạn thì không. Đôi khi mọi người được giao nhiều nhiệm vụ vì không có ai khác. Đôi khi các nhà quản lý không thể xử lý công việc của họ để họ ủy thác, thực thi đa tác vụ trong nhóm của họ vì họ không thể xử lý lịch trình dự án của họ đúng cách. Vì vậy, bạn chắc chắn nên cố gắng xác định xem bạn có được yêu cầu đa tác vụ không vì đó là một phần công việc của bạn hoặc bởi vì người khác không đủ năng lực. Dù bằng cách nào, bạn có thể tự đánh giá xem điều đó có chấp nhận được hay không. Nếu bạn không thoải mái [với công việc của mình], có những nơi khác bạn có thể đi tìm việc. [Bạn, nhà phát triển, là hàng hóa. Nhà tuyển dụng biết điều này và cầu nguyện rằng bạn không bao giờ nhận ra nó.]

Bây giờ về đa tác vụ, tôi không đồng ý 100% khi mọi người nói "có, chỉ cần chuyển đổi qua lại và đảm bảo rằng bạn đang thực hiện cùng một số tiền cho mỗi dự án". Xin lỗi nhưng đó là một lời khuyên rất tệ.

Trước tiên, bạn phải nhận ra bộ não của bạn hoạt động như thế nào khi bạn phát triển một phần mềm (tôi biết có những nhiệm vụ khác liên quan nhưng hãy tập trung vào đó). Trước tiên bạn cần phải có "dây", nghĩa là bạn cần tập trung rất nhiều và tập trung vào một vị trí mà bạn có mọi thứ được ánh xạ trong đầu. Tất cả các tên biến và phương thức, dòng công việc của mã của bạn, mô hình đối tượng, các luồng đi cạnh nhau, mọi thứ. Thông thường tôi phải mất 15 có thể 20 phút để có được "trong khu vực".

Khi bạn đến trạng thái đó, bạn thực sự đang bay và viết mã giống như bạn đang đi xe đạp. Khoảnh khắc bạn bị gián đoạn bạn có thể mất tất cả. Nếu sự gián đoạn đủ dài (5, 10 có thể 30 phút), bạn sẽ mất trạng thái tâm trí đó và sẽ phải bắt đầu lại tất cả.

Vì vậy, đa tác vụ là khủng khiếp vì nó buộc bạn phải rời khỏi "khu vực" và chuyển sang một thứ khác. Nếu bạn liên tục chuyển đổi, điều đó có nghĩa là bạn không làm việc hiệu quả bởi vì mỗi khi bạn chuyển sang một nhiệm vụ/dự án mới, bạn cần mất 15-20 phút để quay lại khu vực đó (không đề cập đến việc nó làm não bạn chậm lại).

Giống như đa luồng: tại một số điểm, chi phí chuyển đổi bối cảnh luồng mỗi chu kỳ cặp đôi quá cao nên CPU cuối cùng sẽ dành nhiều thời gian chuyển đổi bối cảnh hơn là thực hiện các tác vụ thực tế.

Tôi đặc biệt khuyên bạn nên đọc một bài viết từ Joel Spolsky về vấn đề này:

http://www.joelonsoftware.com/articles/fog0000000022.html

Vì vậy, lời khuyên của tôi là: hãy thử học cách (không) đa tác vụ vì nó thực sự phổ biến. Nhưng cũng chắc chắn rằng bạn cảm thấy thoải mái khi làm điều đó. Một số người có thể mất nhiều thời gian hơn để tập trung và sẽ chịu đựng nhiều hơn những người khác khi đa tác vụ; và điều đó cũng tốt Không phải vì nó phổ biến mà nên được coi là bình thường.

Joel nói điều đó tốt khi anh nói:

Trong thực tế, bài học thực sự từ tất cả những điều này là bạn không bao giờ nên để mọi người làm việc trên nhiều thứ cùng một lúc. Hãy chắc chắn rằng họ biết nó là gì. Các nhà quản lý giỏi thấy trách nhiệm của họ là loại bỏ những trở ngại để mọi người có thể tập trung vào một việc và thực sự hoàn thành nó.

54
Alex

Vâng, nó được mong đợi. Và hoan nghênh.

Có một vài cách để xem xét điều này:

  1. Bạn đang được mong đợi đa nhiệm vụ và gần như không thể tập trung. Điều này dẫn đến các quy trình kỹ thuật dưới tối ưu, thỉnh thoảng nhầm lẫn khi bạn chuyển đổi qua lại, cảm giác bị lợi dụng, thất vọng, căng thẳng, v.v ... Tất nhiên điều này là tiêu cực; Tuy nhiên,

  2. Bạn đang được tin tưởng với nhiều dự án, điều này phản ánh tốt về kết quả bạn tạo ra và sự tin tưởng mà chủ nhân của bạn có trong khả năng của bạn. Đó là một cơ hội để cho họ thấy sự tin tưởng được bảo hành.

Lời khuyên của tôi là phát triển khả năng phán đoán tỉnh táo trong đó nhiệm vụ đòi hỏi sự chú ý ngay lập tức của bạn và có thể chờ đợi. Đôi khi câu trả lời là không thể chờ đợi và bạn cần thực hiện một cách tiếp cận sáng tạo để cung cấp kết quả (một chút cho dự án A, sau đó một chút cho dự án B, sau đó rửa sạch và lặp lại). Tu luyện các kỹ năng để phát triển mạnh trong loại tình huống này.

Thông thường (mặc dù không phải lúc nào cũng vậy), điều này sẽ được khen thưởng với nhiều trách nhiệm hơn, nhiều dự án hơn để tung hứng và nhiều kỳ vọng hơn. Tại một số điểm, bạn sẽ có thể, và dự kiến, sẽ ủy thác một số công việc này. Đó là thước đo thành công.

Vì vậy, ngay cả khi các kỹ năng tung hứng ngày càng tăng của bạn chỉ được khai thác bởi công ty hiện tại của bạn, đây là những kỹ năng tốt cần có và sẽ phục vụ bạn tốt trong sự nghiệp.

Đối với những gì nó có giá trị, tôi thường làm việc trong một dự án lớn, một dự án nhỏ hơn, bảo trì và hỗ trợ các dự án cũ và quản lý ít nhất một dự án khác. Thật là bực bội, khó hiểu, mệt mỏi, và tôi rất biết ơn.

33
b w

Đúng! Điều đó hoàn toàn "bình thường"/thông thường khi bạn làm việc trong một công ty dịch vụ xD

Ngoài ra nếu bạn cộng tác với các dự án nguồn mở, đó là quy tắc

Có thể không phải là và trạng thái lý tưởng, nhưng là bánh mì hàng ngày.

15
yeradis

Nó phổ biến. Nhưng nó không tốt, vì những lý do mà bạn đã vạch ra. Chuyển ngữ cảnh ăn thành năng suất, vì vậy nếu bạn có thể, hãy cố gắng làm việc trên một dự án trong một khoảng thời gian lớn, ví dụ: một ngày.

12
Anthony

Tôi tích cực làm việc trên 2 đến 3 dự án khác nhau mỗi ngày. Và duy trì thêm vài chục. Một số tuần nó có một chút áp đảo. Một số dự án rất lớn, một số rất nhỏ, chúng được mã hóa trong một vài ngày và hiếm khi cần thay đổi. Nó khác nhau, nhưng nó giúp tôi tiếp xúc với những cách suy nghĩ và giải quyết vấn đề khác nhau, công nghệ khác nhau và lĩnh vực kinh doanh. Tôi thích nó.

Vì vậy, để trả lời câu hỏi của bạn, vâng, nó rất phổ biến.

9
CaffGeek

Kiểm tra bài viết có tên Đa nhiệm đưa bạn đến đó sa . Biểu đồ này kể câu chuyện:

enter image description here

Nói cách khác, công ty đang lãng phí thời gian bằng cách để các lập trình viên của họ làm việc trên nhiều dự án cùng một lúc. Chỉ với ba dự án, lãng phí là 40%! Phần còn lại của thời gian được chia thành ba dự án.

Lý do đa nhiệm thường được nêu là "hoàn thành nhiều việc hơn". Nhưng đó là lý luận bị lỗi. Đa nhiệm chỉ dẫn đến việc trì hoãn tất cả các bản phát hành. Hình ảnh này cho thấy hiệu quả của tác vụ kép so với hoàn thành một dự án tại một thời điểm:

enter image description here

(Hình ảnh bỏ qua hoàn toàn chi phí. Trong thực tế, thời gian lãng phí sẽ khiến cả hai dự án 20% sau đó.)

8
Martin Wickman

Có, theo kinh nghiệm của tôi là bình thường (ngay cả khi một số 'dự án' khá giống nhau, ví dụ: dự án bảo trì và tính năng trên cùng một sản phẩm). Để tránh xung đột và kỳ vọng không thực tế, hãy đồng ý với người quản lý dự án và người quản lý của bạn để phân bổ các phân số thời gian nhất định của bạn cho từng dự án (ví dụ: ba ngày cho dự án X, hai cho dự án Y mỗi tuần). Thông thường, bạn có thể phân phối các phân bổ đó theo cách bạn muốn, ví dụ: Thứ Hai-Thứ Tư trên X, Thu-Fri trên Y.

Thỉnh thoảng sẽ có lúc một dự án "ném ngoại lệ" và cần phải được thực hiện trên ngay bây giờ. Có hai điều cần làm ở đây:

  1. đảm bảo rằng nó thực sự là một ngoại lệ, không chỉ là một người quản lý dự án khó khăn: Đẩy lùi trong trường hợp sau.
  2. trao đổi phân bổ thời gian của bạn để bạn vẫn làm việc cùng một phần trên mỗi dự án.
4
user4051

Nó phụ thuộc vào công ty. IMO mong muốn chủ yếu chỉ làm việc trên một dự án, nhưng điều đó thường không thể thực hiện được, đặc biệt là với các công ty nhỏ.

Tất nhiên, sửa lỗi, vv luôn có thể xảy ra với bất kỳ dự án.

4
user281377

Nếu bạn cảm thấy khó có thể lấy lại tốc độ với khung công tác hoặc logic kinh doanh của dự án khi bạn quay lại với nó, bạn nên tận dụng cơ hội để viết càng nhiều tài liệu càng tốt trong khi bạn đang làm việc với nó. Chi tiết về cách một hệ thống phức tạp hoạt động, theo cách nói của bạn, sẽ làm cho việc quay lại dự án sau này dễ dàng hơn nhiều. Ngoài ra, tài liệu này có thể hữu ích cho đồng nghiệp của bạn nếu họ cần hỗ trợ.

Nếu dự án đã có phạm vi bảo hiểm tốt về tài liệu kỹ thuật, việc viết ra những suy nghĩ của bạn khi bạn làm việc trên các khu vực phức tạp vẫn có ích. Bằng cách đó bạn có thể tiếp nhận quá trình suy nghĩ của mình vào lần tiếp theo bạn quay lại.

3
Matt G

Vâng, điều đó không bình thường nhưng tôi có nhiều dự án trên vai tại nhà tuyển dụng hiện tại. Phải mất một số làm quen với tôi thừa nhận. Lời khuyên quan trọng nhất tôi có thể đưa ra là luôn ưu tiên công việc của bạn. Buộc sếp của bạn cho bạn biết nhiệm vụ ưu tiên là gì và chỉ làm việc đó. Đừng tạo áp lực từ bất cứ ai phàn nàn về các dự án khác của bạn. Bạn không nhất thiết phải cập nhật sơ yếu lý lịch của mình nhưng đảm bảo tải không leo thang vượt quá mức bạn có thể xử lý hợp lý.

2
ChaosPandion

Tôi nghĩ đó là bình thường. Cách thức làm việc của tôi ngay bây giờ (Tôi đang ở trong một công ty có khoảng 40 nhà phát triển, tổng quy mô công ty khoảng 700). Và tôi thường có một dự án "dài hạn" với nhiều vé/lỗi nhỏ xuất hiện nên thường kết thúc là 50% vé nhỏ và 50% làm việc cho dự án dài hạn. Điều có thể khó khăn là sự gián đoạn liên tục có thể làm chậm và làm hỏng dự án dài hạn ..

0
Bmw

Tôi nghĩ rằng nó là bình thường để làm việc trên nhiều dự án. Điều quan trọng là chấp nhận rằng bạn sẽ phải đối mặt với một số sự mơ hồ về mặt bức tranh tổng thể của hệ thống ban đầu.

Nếu bạn cố gắng để có được bức tranh lớn hơn, bạn sẽ có được sự rõ ràng và có thể phát hiện ra các bộ phận chuyển động/cố định trong hệ thống và các thay đổi của bạn ảnh hưởng đến hệ thống như thế nào.

Trong một khoảng thời gian, bạn sẽ học cách tìm ra các mẫu chung trong các hệ thống khác nhau mà bạn làm việc. Những điều này bạn có thể áp dụng cho các dự án khác của mình, điều này sẽ làm giảm lượng thông tin chi tiết mà bạn cần lưu giữ trong đầu.

0
Pradeep

Trong bất kỳ dự án không tầm thường nào, có nhiều hơn một người được giao cho nó. Điều này có nghĩa là bạn cần cộng tác với những người khác và chờ họ thực hiện công việc của họ, cũng như họ cần chờ bạn.

Thay vì có những người ngồi không, thường có nhiều dự án hoạt động để luôn có một nhiệm vụ mở phải làm nếu cần.

Bạn vẫn nên làm việc với số lượng lớn trong từng dự án để bạn có thể "trong khu vực" và làm việc hiệu quả.

0
user1249