프로그래머가 여러 프로젝트에서 동시에 작업하는 것이 정상입니까?

현재 직장에는 두 가지 프로젝트가 있습니다. 첫 번째는 매우 큰 시스템이고 두 번째는 더 작지만 크기도 큽니다 (첫 번째 프로젝트는 12 년 동안, 두 번째는 4 년 동안 개발 중입니다).

처음에는 첫 번째 프로젝트에서만 일하고 있었고 익숙해 지려고 노력했습니다. 그런 다음 두 번째 프로젝트로 옮겨서 시도해 보았으므로 첫 번째 프로젝트에 대한 나의 지식은 그늘이되었습니다. 이제 두 프로젝트를 동시에 작업해야합니다.

Java를 사용하더라도 서로 다른 프레임 워크를 사용하고 이해할 코드 및 비즈니스 논리의 양이 너무 커서 두 프로젝트를 모두 머리에 담을 수 없기 때문에 매우 어렵습니다.

내 전문 지식이 매우 스쿼시되었지만, 단일 프로젝트에서만 작업 할 경우 어떤 일이 발생하지 않습니까? 아니면 우려를 제기하거나 고용주를 변경해야합니까?

사람들이 "네, 멀티 태스킹은 정상입니다"라고 말할 때 나는 완전히 동의하지 않습니다

정상 이 아닙니다 ! 개발자가 여러 프로젝트에서 멀티 태스킹을하는 것은 부자연 스럽습니다 (나중에 자세히 설명하겠습니다). 반면에 멀티 태스킹은 개발자들 사이에서 매우 일반적 입니다. 이것은 분명히 익숙해 져야 할 것입니다. 따라서 귀하의 질문에 대한 진정한 대답은 멀티 태스킹 방법 입니다.

우선, "당신은 훌륭한 직원"이기 때문에 단순히 운명을 받아들이지 말아야합니다. 즉, 처리 할 수있는 것보다 더 많은 작업을 수행해야합니다. 전혀 그렇지 않습니다. 다른 사람이 없기 때문에 사람들에게 여러 작업이 제공되는 경우가 있습니다. 때때로 관리자는 업무를 처리 할 수 ​​없으므로 위임 하여 프로젝트 일정을 제대로 처리 할 수 없기 때문에 팀에 멀티 태스킹을 시행 합니다. 따라서 업무 의 일부 이거나 다른 사람이 무능 하기 때문에 멀티 태스킹을 요청 받았는지 확실히 확인해야합니다.. 어느 쪽이든, 당신은 그것이 수용 가능한지 아닌지를 스스로 판단 할 수 있습니다. [직장과 함께] 편안하지 않으면 직장을 구할 수있는 다른 장소가 있습니다. [개발자 인 귀하는 필수품입니다. 고용주는 이것을 알고 당신이 그것을 깨닫지 않기를기도합니다.]

이제 멀티 태스킹에 대해 사람들이 "예, 앞뒤로 전환하고 각 프로젝트에서 같은 양을하고 있는지 확인하십시오"라고 말하면 100 % 동의하지 않습니다. 미안하지만 그것은 매우 나쁜 조언입니다.

먼저 소프트웨어를 개발할 때 두뇌가 어떻게 작동하는지 알아야합니다 (다른 작업이 관련되어 있음을 알고 있지만 그에 중점을 두겠습니다). 먼저 "유선"을 가져와야합니다. 즉, 머리에 모든 것이 매핑 된 위치에 집중해야합니다. 모든 변수 및 메소드 이름, 코드의 워크 플로우, 객체 모델, 나란히 진행되는 스레드, 모든 것. "지역에"도착하는데 보통 15 분에서 20 분 정도 걸립니다.

그 상태에 도달하면 자전거를 타는 것처럼 실제로 비행하고 코드를 작성합니다. 당신이 중단되는 순간 당신은 그것을 모두 잃을 수 있습니다. 중단이 충분히 길면 (5 분, 10 분, 30 분) 해당 상태를 잃어 버리고 다시 시작해야합니다.

따라서 멀티 태스킹은 "영역"을 떠나 다른 것으로 이동해야하기 때문에 끔찍합니다. 끊임없이 전환한다면 새로운 작업 / 프로젝트로 변경할 때마다 영역에 다시 들어가기 위해 15-20 분을 잃을 필요가 있기 때문에 생산적이지 않다는 것을 의미합니다 (뇌를 천천히 녹이는 것은 말할 것도 없습니다).

멀티 스레딩과 같습니다. 어떤 시점에서 몇 사이클마다 스레드 컨텍스트를 전환하는 비용이 너무 높아 CPU가 실제 작업을 실행하는 것보다 컨텍스트 전환에 더 많은 시간을 소비하게됩니다.

이 문제에 대한 Joel Spolsky의 기사를 읽는 것이 좋습니다.

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

그래서 내 충고는 : 멀티 태스크가 일반적이기 때문에 멀티 태스크를 수행하는 방법을 배우십시오. 또한 편안하게 작업하십시오. 어떤 사람들은 멀티 태스킹을 할 때 다른 사람들보다 집중하는 데 더 많은 시간을 할애 할 수 있습니다. 그리고 그것도 괜찮습니다. 일반적인 것으로 간주되는 것이 일반적이기 때문에 아닙니다.

요엘은 이렇게 말했습니다.

사실,이 모든 것의 진정한 교훈은 사람들이 한 번에 여러 가지 작업을해서는 안된다는 것입니다. 그들이 무엇인지 알고 있는지 확인하십시오. 훌륭한 관리자는 사람들이 한 가지에 집중하고 실제로 달성 할 수 있도록 책임을 장애물 제거라고 생각합니다.

예, 예상됩니다. 그리고 환영했다.

이것을 볼 수있는 몇 가지 방법이 있습니다 :

1. 당신은 멀티 태스킹을 기대하고 있으며 초점을 맞추는 것은 거의 불가능합니다. 이로 인해 최적이 아닌 엔지니어링 프로세스, 때때로 전환 ​​할 때 혼란, 착취 감, 좌절감, 스트레스 등이 발생합니다. 물론 이것은 모두 부정적인 것입니다. 하나,

2. 귀하는 여러 프로젝트를 신뢰하며, 이는 귀하가 생산 한 결과와 고용주가 귀하의 능력에 대해 가지고있는 신뢰를 잘 반영합니다. 그들에게 신뢰가 보장됨을 보여줄 수있는 기회입니다.

조언은 즉각적인주의가 필요한 작업과 기다릴 수있는 작업에 대한 냉정한 판단 을 개발 하는 것입니다. 때때로 대답은 기다릴 수 없으며 결과를 제공하기 위해 창의적인 접근 방식을 취해야한다는 것입니다 (프로젝트 A에 대해서는 약간, 프로젝트 B에 대해서는 약간 헹구고 반복). 이런 상황에서 번창 할 수있는 기술을 기르십시오.

일반적으로 (항상 그런 것은 아니지만) 이것은 더 많은 책임, 저글링 할 프로젝트 및 더 많은 기대로 보상됩니다. 어느 시점에서이 작업의 일부를 위임 할 수 있고 기대할 수 있습니다. 성공의 척도입니다.

따라서, 당신의 성장하는 저글링 기술이 현재 회사에 의해서만 이용 되더라도, 이것은 좋은 기술이며 당신의 경력에서 당신을 잘 도울 것입니다.

가치있는 것을 위해, 나는 주로 주요 프로젝트, 작은 프로젝트, 오래된 프로젝트의 유지 보수 및 지원, 그리고 적어도 하나의 다른 프로젝트를 관리하고 있습니다. 실망스럽고 혼란스럽고 성가 시며 매우 감사합니다.

예! 서비스 회사 xD에서 일할 때 그것은 완전히 "정상"/ 보통입니다

또한 오픈 소스 프로젝트와 공동 작업하는 경우 규칙

아마도 이상적인 상태는 아니지만 일상의 빵일 것입니다.

일반적입니다. 그러나 당신이 설명 한 이유로 좋지 않습니다. 컨텍스트 전환은 생산성으로 전환되므로 가능하면 하루 중 하나와 같이 한 프로젝트에서 많은 시간 동안 작업 해보십시오.

저는 매일 2 ~ 3 개의 서로 다른 프로젝트를 적극적으로 수행합니다. 그리고 수십 개를 더 유지하십시오. 몇 주에 약간 압도적입니다. 일부 프로젝트는 거대하고 일부는 너무 작아서 며칠 안에 코딩되어 거의 변경이 필요하지 않습니다. 상황은 다양하지만 문제, 해결 방법, 기술 및 비즈니스 영역을 다르게 생각하고 해결하는 다른 방법에 노출됩니다. 나는 그것을 즐긴다.

따라서 귀하의 질문에 대답하기 위해, 그것은 매우 일반적입니다.

Multitasking Gets There Later 라는 기사를 확인하십시오 . 이 그래프는 이야기를 알려줍니다.

다시 말해, 회사는 프로그래머가 한 번에 하나 이상의 프로젝트에서 작업하게하여 시간을 낭비하고 있습니다. 단 3 개의 프로젝트만으로 낭비는 40 %입니다! 나머지 시간은 3 개의 프로젝트로 나뉩니다.

멀티 태스킹의 이유는 종종 "더 많은 일을 수행"으로 표현됩니다. 그러나 그것은 잘못된 추론입니다. 멀티 태스킹은 모든 릴리스를 지연시킵니다. 이 이미지는 이중 작업의 효과와 한 번에 하나의 프로젝트를 마무리하는 효과를 보여줍니다.

(이미지는 오버 헤드를 완전히 무시합니다. 실제로 낭비되는 시간은 두 프로젝트 모두 20 % 후에 만들 것입니다.)

회사에 따라 다릅니다. IMO 주로 하나의 프로젝트에서만 작업하는 것이 바람직하지만, 특히 소규모 회사에서는 불가능합니다.

물론 버그 수정 등은 항상 모든 프로젝트에서 발생할 수 있습니다.

예, 제 경험상 이는 정상입니다 (일부 '프로젝트'가 동일한 제품의 유지 보수 및 기능 프로젝트와 같이 매우 유사하더라도). 충돌과 비현실적인 기대를 피하기 위해 프로젝트 관리자 및 관리자와 동의하여 각 프로젝트에 일정 시간을 할당하십시오 (예 : 프로젝트 X에서는 3 일, 매주 프로젝트 Y에서는 2 일). 그런 다음 일반적으로 원하는대로 할당을 분배 할 수 있습니다 (예 : X의 Mon-Wed, Y의 Thu-Fri).

때때로 한 프로젝트가 "예외를 던지고" 지금 작업해야 할 때가 있습니다 . 여기서해야 할 일이 두 가지 있습니다.

1. 단순한 프로젝트 관리자가 아니라 실제로 예외적인지 확인하십시오. 후자의 경우에는 되돌립니다.
2. 각 프로젝트에서 동일한 비율로 작업하도록 시간 할당을 교환하십시오.

다시 전환 할 때 프로젝트의 프레임 워크 또는 비즈니스 로직으로 속도를 회복하기가 어렵다면, 작업하는 동안 가능한 많은 문서를 작성할 기회를 가져야합니다. 복잡한 시스템이 어떻게 작동하는지 자세히 설명하면 나중에 프로젝트로 쉽게 돌아올 수 있습니다. 또한이 문서는 동료가 도움을 필요로하는 경우 도움이 될 수 있습니다.

프로젝트에 이미 기술 문서가 포함되어 있다면 복잡한 영역에서 작업 할 때 생각을 적어 두는 것이 좋습니다. 이렇게하면 다음에 다시 전환 할 때 사고 과정을 시작할 수 있습니다.

글쎄, 그것은 정상이 아니어야하지만 현재 고용주에서 어깨에 많은 프로젝트가 있습니다. 인정하는 데 익숙해 져야합니다. 내가 줄 수있는 가장 중요한 팁은 항상 작업의 우선 순위를 정하는 것입니다. 상사가 우선 과제가 무엇인지 말하고 그 일만하도록 강요하십시오. 다른 프로젝트에 대해 불평하는 사람에게 압력을 가하지 마십시오. 이력서를 반드시 업데이트 할 필요는 없지만로드가 합리적으로 처리 할 수있는 것 이상으로 에스컬레이션되지 않도록하십시오.

나는 그것이 정상이라고 생각합니다. 내 직업이 현재 작동하는 방식 (저는 약 40 명의 개발자, 총 회사 규모는 약 700 명인 회사에 있습니다). 그리고 보통 작은 티켓 / 결함이 많은 하나의 "장기"프로젝트가있어서 장기 프로젝트에서 보통 50 %의 작은 티켓과 50 %의 작업으로 끝나게됩니다. 어려운 것은 지속적인 중단으로 인해 장기 프로젝트가 느려지고 탈선 될 수 있다는 것입니다.

여러 프로젝트에서 작업하는 것이 일반적이라고 생각합니다. 핵심은 처음에 시스템의 전체적인 관점에서 약간의 모호함에 직면한다는 것을 받아들이는 것입니다.

더 큰 그림을 얻으려고 노력하면 선명도가 높아지고 시스템에서 움직이는 / 고정 된 부품과 변경 사항이 시스템에 미치는 영향을 알 수 있습니다.

일정 기간 동안 작업하는 다양한 시스템에서 공통적 인 패턴을 찾는 방법을 배우게됩니다. 이것들은 다른 프로젝트에 적용하여 한 번에 머리에 보관 해야하는 세분화 된 정보의 양을 줄입니다.

사소하지 않은 프로젝트에는 둘 이상의 사람이 할당되어 있습니다. 이것은 당신이 다른 사람들과 협력하고 그들이 당신을 기다릴 필요가있을뿐만 아니라 그들의 일을하기를 기다려야한다는 것을 의미합니다.

사람들을 유휴 상태로 두는 대신 여러 프로젝트를 활성화하여 필요한 경우 항상 열려있는 작업을 수행하는 것이 일반적입니다.

그래도 각 프로젝트마다 상당한 규모의 작업을 수행해야 "영역에 도달"하고 생산성을 높일 수 있습니다.

나는 그것이 정상 / 일반이라고 말하는 사람들에 동의합니다.

긍정적 인 것으로 보시면, 더 유용 해지고 융통성있는 것으로 보이며 일을 해낼 수있는 사람에게 가십시오! 결국 2 개의 시스템을 알게되면 더 가치가있을 것입니다.

IMHO는 평범 할뿐만 아니라 바람직합니다.

내가 경험 한 최악의 개발 작업은 몇 달 동안 같은 응용 프로그램의 동일한 부분에서 동일한 작은 부분을 작업하는 것이 었습니다. 지겨움. 그리고 당신이 지루할 때, 당신은 공에서 눈을 떼고 ...

나는 당신이 어떻게 느끼고 있는지 이해합니다. 특히 고용주가 개발에 중점을 두지 않은 경우, 새로운 고용주가 관련 처리 된 개발을 이해하게하는 것은 어렵습니다.

문제는 한 번에 1 개보다 3 개 더 많은 돈을 모으기 위해 3 개의 작업이 진행되고 있으며 통계에 따르면 성능이 40 % 감소한다는 것입니다. 40 %의 이익 손실 ..

이전에는 직무, 티켓 및 지원 등의 작은 작업으로 한 번에 하나의 큰 프로젝트에 집중할 수있는 조직화를 위해 일했습니다. 우리는 오전 8시에서 오전 10 시까 지 티켓이 있었고 현재 시스템에 대한 지원이있는 거래를했습니다. 이메일 / 전화 / 헬프 데스크를 통해 제공되는 다음 10:00-16:30 또는 완료 시간은 완전한 발전이었습니다. 이것은 extreemley에서 잘 작동했습니다. 전화와 이메일을받을 수있는 헬프 데스크가 있었기 때문에 아침에 티켓을 발급하고 나머지 시간을 개발할 수있었습니다. 문제는 관리 수준이 좋지 않은 경우입니다. 관리자는이 모든 것을 가능하게하며 매일 직면하는 문제에 대한 지원이나 이해없이 사실에 대해 무지합니다.

특히 관리자의 지원과 이해에 대한 마지막 일에 감사를 드렸습니다. 덕분에 인생이 쉬워지고 스트레스가 줄어들 었으며 모든 일을 끝냈습니다.

또 다른 문제는 보스의 사랑 돈, 그들은 돈으로 프로젝트를 보는 것입니다. 그들이 동시에 £ 20,000에 5 개의 프로젝트를 가지고있을 때 (그리고 당신은 솔로 개발자 인 경우) 책에서 £ 100,000가되는 것입니다. 이러한 요구 사항이 충족되지 않으면 회사의 평판이 손상되고 마감 시간이 누락되고 집중력이 부족하여 시스템에 버그가 있습니다.

나는 당신에게 완전히 동정합니다, 지금 당신의 입장에 있습니다.

프로젝트를 설명하는 방법에 따라 다릅니다. 일반적으로 개발자는 몇 가지 문제를 해결하고 회사에서 여러 제품을 사용하는 것보다 하나 이상의 제품을 사용하는 경우

사랑의 파트너와 같은 소프트웨어 프로젝트는 많고 많을 수 있지만 한 번에 하나씩 만 좋습니다.

@Martin Wickman이 말한 것에 덧붙여 작업 전환을 많이하지 마십시오. 예를 들어, 프로젝트 A에서 AM으로 작업하고 프로젝트 B에서 PM으로 작업하십시오. 또한 기능 추가를 거부하십시오. 풀 타임으로 프로젝트를 진행하지 않을 때는 더욱 고통 스럽습니다.