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 [đóng]

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?

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

Nó 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ụ rất phổ biến 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 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ồi.

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, quy trình làm 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 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).

Nó 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 là 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ó.

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 kỳ vọng sẽ đa tác 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 sự phán đoán tỉnh táo về những 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). Trau dồi 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.

Vâ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.

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.

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.

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

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:

(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 đó.)

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.

Có, theo kinh nghiệm của tôi, điều đó 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ổ một số phân số thời gian của bạn cho mỗi 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ụ: Mon-Wed 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 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.

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ó độ bao phủ tốt của tài liệu kỹ thuật, việc viết ra những suy nghĩ của bạn khi làm việc trên các khu vực phức tạp vẫn có thể 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.

Chà nó 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ý.

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 ..

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.

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ó 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ả.

Tôi đồng ý với những người nói đó là bình thường / phổ biến.

Hãy xem nó như một điều tích cực, bạn sẽ trở nên hữu ích hơn, được xem là linh hoạt, một chàng trai có thể hoàn thành công việc! Có thể có giá trị hơn khi cuối cùng bạn đã biết 2 hệ thống từ trong ra ngoài.

IMHO, không chỉ là bình thường, mà còn là mong muốn.

Công việc phát triển tồi tệ nhất tôi từng có là làm việc trên cùng một phần nhỏ của cùng một phần của cùng một ứng dụng trong nhiều tháng. Sự nhàm chán. Và khi bạn buồn chán, bạn rời mắt khỏi quả bóng ...

Tôi hiểu cảm giác của bạn như thế nào, thật khó để làm cho các nhà tuyển dụng mới hiểu được sự phát triển được xử lý có liên quan, đặc biệt nếu nhà tuyển dụng của bạn không tập trung vào phát triển.

Vấn đề là họ thấy 3 Công việc đang được làm việc cùng nhau nhiều hơn một người kiếm tiền cùng một lúc và số liệu thống kê cho thấy hiệu suất giảm 40%. Đó là mất 40% lợi nhuận ..

Tôi đã làm việc trước đây cho một sự phân chia cho phép tôi tập trung vào 1 dự án lớn tại một thời điểm với các công việc nhỏ ở giữa, vé và hỗ trợ, v.v. Chúng tôi đã làm việc trong một thỏa thuận trong đó 8: 00-10: 00AM là Vé và hỗ trợ cho các hệ thống hiện tại thông qua email / điện thoại / bộ phận trợ giúp sau đó 10:00 - 16:30 hoặc thời gian hoàn thành của bạn đã phát triển toàn diện. Điều này hoạt động tốt extreemley, bởi vì chúng tôi có một bộ phận trợ giúp để nhận các cuộc gọi và email, tôi đã có thể thực hiện các vé vào buổi sáng và phát triển phần còn lại của ngày. Vấn đề là nếu bạn có quản lý kém. Một người quản lý làm cho tất cả những điều này xảy ra, và không có sự hỗ trợ hay hiểu biết của họ về những thách thức mà bạn phải đối mặt hàng ngày, họ không biết gì về thực tế.

Tôi rất biết ơn đặc biệt là trong công việc cuối cùng của tôi về sự hỗ trợ và hiểu biết từ người quản lý của tôi, nó làm cho cuộc sống của tôi dễ dàng hơn, ít căng thẳng hơn và chúng tôi vẫn hoàn thành TẤT CẢ công việc ..

Một vấn đề khác là, tiền tình yêu của Boss, họ thấy các dự án bằng tiền, Khi họ có 5 Dự án với giá 20.000 bảng cùng một lúc (và bạn là nhà phát triển solo) có 100.000 bảng trong sách .. Trông rất hay trên giấy nhưng có thể làm tổn hại danh tiếng của công ty khi những điều này không được đáp ứng, thời hạn bị bỏ lỡ và hệ thống bị lỗi vì thiếu tập trung.

Tôi hoàn toàn thông cảm với bạn, tôi đang ở vị trí của bạn ngay bây giờ.

Nó phụ thuộc vào cách bạn mô tả dự án. Thông thường nhà phát triển làm việc với một số vấn đề và nếu trong công ty có nhiều sản phẩm hơn bạn làm việc với nhiều người.

Các dự án phần mềm, như các đối tác tình yêu, có thể nhiều, và nhiều người giỏi, nhưng chúng chỉ tốt nếu mỗi lần một.

Thêm vào những gì @Martin Wickman nói, cố gắng không chuyển đổi tác vụ nhiều. Ví dụ làm việc AM trên dự án A, PM trên dự án B. Cũng nói không với việc thêm tính năng; điều đó đau đớn hơn khi bạn không làm việc toàn thời gian cho dự án.