최근에 중소 기업의 웹 개발자로 경력을 시작했습니다. 시작하자마자 기존 응용 프로그램을 확장하는 작업을 받았습니다 (수년에 걸쳐 여러 프로그래머가 개발 한 잘못 코딩 됨, 구조가 다른 여러 가지 방식으로 동일한 작업을 처리 함).

요청한 기능으로이 응용 프로그램을 성공적으로 확장 한 후 응용 프로그램을 완전히 유지 관리하는 작업을 수행했습니다. 이것은 물론 문제가 아니기 때문에 생각했습니다. 그러나 기존 코드를 개선 할 수 없으며 버그가보고 될 때만 버그 수정에만 집중할 수 있다고 들었습니다.

그때부터 나는 위와 같은 세 가지 프로젝트를 더 가지고 있었고 지금도 유지해야합니다. 그리고 응용 프로그램을 처음부터 새로 만들 수있는 4 개의 프로젝트가 있었으며이를 유지 관리해야합니다.

지금은 유지 관리해야하는 각 응용 프로그램에 대해 매일 사용자의 메일 (읽기 관리자)로부터 미쳐지기 시작했습니다. 그들은 다른 두 개의 새로운 프로젝트를 진행하면서이 메일을 직접 처리 할 수있을 것으로 기대합니다 (그리고 이미 5 개의 프로젝트가 추가되어 있습니다). 슬픈 점은 내가 코딩 한 모든 것에 대한 버그 보고서를 아직받지 못했다는 것입니다. 이를 위해 가끔씩 수행 할 수있는 180 도의 다른 변경 요청 만 받았습니다.

어쨌든, 이것이 정상입니까? 제 생각에는 전체 개발자 팀과 동등한 작업을하고 있습니다.

처음에 상황이 달라졌을 때 바보였습니까?

이 게시물이 큰 폭동으로 변한 것 같지만 모든 개발자에게 동일하지는 않다고 알려주십시오.

추신 내 급여는 슈퍼마켓에서 계산원의 급여보다 낮지 않으면 거의 같습니다.

인턴십 중 하나에서 버그 수정에 많은 시간을 보냈다는 것을 알았습니다. 당신은 엔트리 레벨의 직원으로서 가장 섹시한 일을하지 않을 것이며, 아무도 원치 않는 그런 일을 할 것이라는 것을 알아야합니다. 불행한 일이지만 모든 직업에있어서의 방식입니다.

또한 회사에있어 코드가 깔끔한 것보다 작동하는 것이 중요하다는 것을 인식해야합니다. 회사의 관점에서 기존 구조를 변경하면 이미 수행 된 작업을 다시 수행하고 훨씬 더 많은 오류가 발생할 수 있으므로 비용이 낭비됩니다. 일반적으로 이러한 유형의 회사는 컴퓨터 / 소프트웨어 회사가 아니기 때문에 관리자가 때때로 이러한 주요 정밀 검사를 수행해야한다는 기술적 배경 지식이 없습니다. 즉, 회사가 기술적으로 유능한 사람들에 의해 운영되고 좋은 코드의 가치를 이해하는 경우 때로는 전투를 선택해야하지만 더 많은 여유가 생길 수 있습니다 (비즈니스의 주요 목적은 여전히 ​​돈을 버는 것입니다) ).

즉, 소프트웨어에 표시를 남기고 더 의미있는 작업을 원한다는 것은 무리가 없습니다. 또한 여러 관리자의 요청을 처리하는 동시에 한 번에 많은 프로젝트를 처리해야합니다.

프로그래머는 처음부터 자신의 코드를 작성하는 것보다 다른 사람의 코드를 유지 관리하고 수정하는 데 더 많은 시간을 할애하는 것이 사실입니다. 이것이 당신에게 문제라면 아마도 취미로 발전하고 다른 직업을 추구해야 할 것입니다. 코드 유지에 문제가 없지만 효과적으로 사용되지 않거나 압도적이라고 생각되면 관리자와상의해야합니다. 문제가 그보다 심각하거나 관리자가 기술을 효과적으로 관리하는 방법을 모른다고 느끼는 경우 다른 회사에서 직책을 찾는 것이 좋습니다. 당신의 저임금이 주어진다면, 이것은 아마도 최선의 행동 과정 일 것입니다.

관리에 작업 부하 관리 및 작업 우선 순위 지정에 문제가있는 것 같습니다. 관리자에게 말을 걸어 과부하가 걸렸다는 사실을 이해하도록해야합니다. 모든 사람이 즉시 이행하려는 요청으로 계속해서 폭행하면 효과적인 업무를 수행 할 수 없습니다.

따라서 한 작업에서 다른 작업으로 건너 뛰어 많은 시간을 낭비 할 수 있습니다. 효과적인 소프트웨어 개발 작업을 위해서는 업무에 몰입하고 전념 할 수 있어야합니다. 중단이 많을수록 컨텍스트 전환에 더 많은 시간이 낭비됩니다. 연구는 담그고의 상태에 도착하기 약 15 분 정도 소요됩니다 것을 보여줍니다 흐름이 우리의 마음이 가장 효율적으로 작동합니다. 15 분마다 중단이 발생하면 절대 흘러 가지 않습니다. 이는 귀하와 회사 모두에게 엄청난 낭비입니다.

따라서 관리자와보다 합리적인 작업 모드 를 협상 해야 합니다 . 여기에는 들어오는 요청의 우선 순위를 정하고 어느 정도 미리 계획 해야합니다 . 모든 사용자 요청은 우선 순위에 따라 순서대로 목록에 유지되어야합니다. 그리고 우선 순위는 요청자에 의해 결정되어서는 안되며 (당연히 모든 사람이 자신의 요청이 지구상에서 가장 중요하다고 생각하기 때문에) 귀하가 아니라 귀하가 유지하는 전체 제품 범위에 대한 충분한 비즈니스 지식과 개요를 가진 사람 ( 제품 소유자 ).

이상적으로는 모든 수신 요청을 JIRA 또는 Mantis 와 같은 이슈 트래커에 입력해야합니다 . 또는 최소한 귀하가 아닌 제품 소유자에게 우송하십시오. 또한 "내 요청이 아직 준비되지 않은 이유는 무엇입니까?!"에 대한 사용자의 모든 불만 사항도 처리해야하므로 개발 작업에 집중할 수 있습니다. 이것이 불가능한 경우, 수신 요청을보고 처리 할 때 최소한 일부 창을 협상하여 개발을 위해 시간의 중단없는 부분을 예약해야합니다.

이것이 가능하다면, 다음 단계는 어느 정도 미리 계획하는 것입니다. 즉, 우선 순위가 가장 높은 요청을 구현하는 데 필요한 시간을 예상 한 다음 시간을 스프린트 ( 일주일에 한 주 이상) 로 예약 하고 다음 스프린트에 충분한 작업을 할당하여 시간을 처리하십시오.

비상 사태에 대비하여 시간의 일부를 유지하고 싶지만 나머지는 미리 계획 할 수 있습니다. 또한 다른 프로젝트에 대한 작업을 별도의 "줄무늬"로 구성하는 것을 선호 할 수도 있습니다. 즉, 월요일에 프로젝트 A, 화요일에 수요일에 프로젝트 B, 목요일 아침에 프로젝트 C, 오후에 D 프로젝트 등을 수행하는 것이 좋습니다. 컨텍스트 전환을 줄입니다.

이렇게하면 다음 1 주 또는 몇 주 안에 무엇을해야할지 대략적으로 알 수 있습니다. 또한 이는 고객에게 로드맵을 제공합니다. 고객은 언제 어떤 요청을 구현했는지 확인할 수 있습니다. 관리자에게 "민첩한"이라는 단어를 언급하고 싶거나 말고 싶지 않을 수도 있습니다. 이것은 기본적으로 민첩한 개발 이지만 일부 사람들은 실제로 그것이 무엇인지 알지 못하고 민첩성을 반대합니다.

회사에서 현재 위치를 소중하게 생각하더라도 유지 관리하는 프로젝트가 많을수록 협상력 이 높아집니다 .

이러한 모든 프로젝트를 유지하기 위해 새로운 직원을 찾아서 훈련시키는 것은 회사에 상당한 시간 (= 돈)이 걸립니다. 그리고 코드가 이러한 응용 프로그램의 레거시 부분보다 훨씬 낫다는 것을 올바르게 지적 할 수 있으므로 동일한 금액의 유사한 기능의 후보를 쉽게 찾을 수는 없습니다. 그들이 근로 조건을 개선하지 않는다면, 다음 사람이 당신만큼 빨리 지치게 할 것입니다 ... 당신을 지키는 것이 그들 자신의 최선의 이익 임을 이해 하도록 노력하십시오. 당신이있는 곳에서 당신을 행복하게하기 위해 :-) 이것은 당신에게 위의 조건들을 협상하고 /하거나 급여 인상을 요구할 힘을 줄 수 있습니다.

얼마나 많은 협상력을 가지고 있는지-그것은 큰 문제입니다. 귀하의 경영진은 이러한 아이디어에 대해 개방적이거나 개방적이지 않을 수 있으며, 귀하의 불만을 진지하게 받아 들일만큼 귀하를 존중하거나 존중하지 않을 수 있습니다. 그러나 카드를 잘 사용하면 기회가 생깁니다. 그리고 그들이 거부하면 ... 당신은 항상 더 나은 직장을 찾을 수 있습니다. (슬프게도) 당신의 경험은 상당히 전형적인 것이지만,이 상황은 모든 초보자에게 동일하지는 않습니다. 그러나 실제로 더 좋은 직장이 있습니다. 직장의 질은 지리적 위치와 느슨하게 상관되어 있지만 북유럽에서는 평균 확률보다 높습니다. 따라서 현재 상태가 눈에 띄게 향상되지 않으면 완전히 지쳐 버려지기 전에 즉시 살펴보기 시작해야 합니다.

아직 일자리가있는 동안 구직을하는 것이 엄청나게 좋습니다. 따라서 즉시 돈이 필요하기 때문에 첫 번째 제안을 수락 할 필요는 없습니다. 결국 더 좋은 곳을 찾을 것입니다 :-)

추신 내 급여는 슈퍼마켓에서 계산원보다 낮은 경우 거의 동일합니다.

나는 그것을 읽을 때까지 협상하는 방법에 대해 뭔가 쓰고 싶었다. 이제 내가 말할 수있는 것은 휴가입니다! 그것이 학위를 가진 개발자가 일반적으로 얻는 것의 절반이라고 가정합니다. 그리고 상황이 개선되고 즉시 10 % 증가한다고 가정하면 도착하는 데 걸리는 시간을 스스로 알아낼 수 있습니다. 또한 직업에 대해 배우지 않은 것처럼 보이며 훌륭한 엔지니어들에 둘러싸여 있지 않은 것처럼 보이므로 시간 낭비입니다.

나는 또한 비슷한 상황에 있었고, 당신이 그 궤도에 머물면 결코 끝나지 않는다고 말할 수 있습니다. 경영진은 계속해서 당신에게 그것을 삽질 할 것입니다. 왜냐하면 그들은 할 수 있기 때문입니다.

이 주제에 대해 몇 가지 추가 생각이 있습니다.

1. 당신이 사랑하는 것을하십시오. 마음에 들지 않으면 자신이 좋아할만한 것이 무엇인지 찾아보십시오.

2. 통신. 비현실적인 기대에 부응하기 위해 당신의 능력을 분명히 전달하십시오. 비슷한 경험에서 건축가 (가장 삽질 한 사람)는 "다른 사람들의 기대를 관리해야한다"고 말했다.

3. 탈진. 번 아웃을 경험하지 않았다면 운명을 유혹하지 마십시오. 그것은 당신의 삶과 영혼을 당신의 마음에서 빨아들입니다. 최선의 노력에도 불구하고, 업무 목표는 회색, 음산하고 의미가 없습니다. 모든 비용을 타지 않도록해야하므로이 조언을 전합니다.

4. 훈련. 여기는 안감입니다. 당신의 훈련과 경험은 실망스럽고 미달 된 반면, 당신의 경력에 ​​매우 귀중합니다. 이것은 가능한 많은 학습을 흡수하고 피할 수없는 유리 천장을 지연시킬 수 있기 때문에 이것을 실현하는 은총의 은혜입니다.

어떤 재능과 기술을 키우고 있는지에 집중하십시오 ... 다음은 경력의 다음 기회를 통해 당신을 안내 할 것입니다.

당신은 여기서 여러 가지 문제를 다루고 있습니다 ... 명백한 것으로 시작합시다 ...

이것이 정상입니까?

지옥 아니 그러나 ... 그것은 일반적입니까? 불행히도, 그렇습니다.

버그 수정 좌절에 대하여

그것이 당신이 처리해야 할 나머지 혼란과 그들이 당신에게 오버로드하는 여러 프로젝트를 용서하지는 않지만, 나는 단지 "버그-픽스"만 접근하고 개발자로서 당신을 실망시키는 것에 대해 간단히 말하고 싶습니다. , 회사 및 경영진에게 완벽하게 합리적인 접근 방법이 될 수 있습니다.

더 많은 버그와 비용에 대한 표면

더 많은 코드를 터치할수록 의도가 개선 되더라도 버그가 발생할 가능성이 높습니다. 이는 연장 된 개발 시간, 테스트 시간 및 비용을 의미합니다. 중간 이상에서 결함이있는 서비스 릴리스로 넘어 가면 큰 문제가됩니다.

로그의 소음 / 안개

SCM의 관점에서, 버그 수정과 관련된 변경 사항을 명확하게보고 싶을 때 서비스 릴리스의 지점에서 직접 작업하는 경우에도 의미가 있습니다. 실제로 1 줄 코드 변경이 필요한 버그 수정을 둘러싼 수천 가지 변경 사항이있는 15 개의 커밋이 있으면 다소 성가신 일입니다.

따라서 신입 사원이기 때문에 소프트웨어 리팩토링 및 / 또는 향상을 자제하도록 요청하는 것이 훨씬 합리적이며, 내 생각으로는 버그 수정을 통해 가능한 한 "외과 적"이 될 수 있습니다. 그것은 단지 두통을 막아줍니다.

그것에 대해 뭔가 할 수 있습니까?

그렇다고 코드의 건강과 관련된 사람들의 마음의 건강을 모두 달성 할 수있는 방법이 있다는 의미는 아닙니다. 후배이기 때문에 다른 사람이 변경 사항, 특히 버그 수정을 검토하고 서비스 릴리스 빌드로 변경하기 전에 승인을 받아야합니다. 그것은 급진적 인 변화를 막거나 제한하고 더 안전합니다.

지옥에서 온 프로젝트

크랩 코드, 프로그래머 무리, 복제, 크랩 아키텍처

다시 말하지만, 악마의 옹호자는 여기에 초기 요청에 중요하지 않은 몇 가지 비트가 포함되어 있음을 보여줍니다.

내 요점은 이것입니다 : 나는 실제로이 상태에 있지 않은 코드베이스를 실제로 거의 차지하지 않았습니다. 그리고 내가했던 오프 기회에, 그들은 최근에 아주 훌륭한 프로그래머들에 의해 시작된 프로젝트 나 프로토 타입으로 시작되었습니다. 그러나 놀랍게도 대다수는 쓰레기처럼 보였으며, 그중 무서운 숫자는 실제 쓰레기였습니다. 선량하거나 위대한 프로그래머가 시작한 사람들조차도 결국 쓰레기, 마감일 및 기타 도움을 줄 수 있습니다 ...

실제 산업 소프트웨어 엔지니어링에 오신 것을 환영합니다!

그리고 당신은 재미가 뭔지 알아? 웹 개발 세계에서는 종종 더 나쁩니다. 즐겨! :)

손과 시간이 충분하지 않은 너무 많은 프로젝트 및 요청

문제는 아마도 여기에 있습니다.

• 당신의 관리는 (의도적으로) 당신을 학대합니다 .
• 당신의 동료들은 (의도적으로) 당신을 학대합니다 .
• 당신의 (무의식적으로) 당신의 엉덩이를 덮지 않고 전투를 충분히 싸울 수 없습니다 .

관리자는 관리하기에는 너무 많은 프로젝트를 진행하고 있음을 알고 있어야합니다. 그렇지 않은 경우 최대한 빨리 확인하십시오. 또한 공원에서 모두 닉 닉이 아니며 압력을 받았다는 것을 알리고 중지해야 함을 확인하십시오.

주변을 둘러보고 동료가 직접 ( "X는 처리 할 수있을 것입니다"라고 말함으로써) 직접 또는 더 많은 작업과 프로젝트를 편향시키지 않도록하십시오. 이것, 다른 사람을 찾으십시오. "

개인 일화 : 몇 년 전에 인턴쉽을했고 마지막 날 평가를 받았을 때 상사는 전반적으로 내 작업에 매우 만족했지만 관리자 중 한 사람이 그들이 나를 데리러 올 것으로 예상했을 때 다른 인턴에서 "너무 재미없는 작업"을 언로드 하고있었습니다. 나는 그들이 실망감 을 느꼈고, 나는 의도가 정반대 였을 때 느슨해 보이고 싶다는 생각에 사로 잡혔다. 나는 더 어려운 과제를 잡고 다른 젊은 인턴이 더 적은 머리카락을 다루려고 노력했다. 풀링 문제. 나는 그의 직책에 있었다면 나는 도전의 부족으로 지루했을 것이고 아마도 그가 한 방식을 느꼈을 것임을 거의 알지 못했습니다. 요점은, 아무도 3 가지에 대해 틀린 가정을하지 않도록 의사 소통을해야한다는 것입니다.

• 할 수있는 일 ,
• 하고 싶은 일 ,
• 그리고 당신이 기꺼이 할 일 .

따라서 이런 식으로하게하는 것은 부분적으로 당신의 잘못이기도합니다. 그러나 그것은 정상입니다. 모두가 배워야 할 교훈입니다. N - O의 두 글자로되어 있습니다.

일반적으로 더 길지만 더 많은 비용이 들지 않는 답변을 위해 접두사로 사용합니다. 아니, 나는 할 수 없습니다. 아니요, 어떻게해야할지 모르겠습니다. 아니요, 본인이 본인인지 잘 모르겠습니다. 아니, 난 그런 적 없어

처음에는 "그렇다, (결과적으로) 할 것이다"라고 말하고 시간을 더 들여서 일을 쌓아 올릴 수 있다고 느끼는 것은 매우 쉽다. 당신의 시간은 당신의 기술 이후에 가장 귀중한 자산이며 당신과 회사에 있다는 것을 이해해야합니다. 잘못 사용하면 프로젝트, 마감일 및 예산에 영향을 미칩니다 . 저것과 같이 쉬운.

또한보고 할 사람이 너무 많을 까봐 걱정이됩니다. 여러 고객과 거래해야하는 여러 프로젝트 소유자 또는 주요 이해 관계자가있는 것이 좋습니다. 그러나 전반적으로, 특히 신입 사원은 대부분 소수의 관리자에게만보고해야합니다 (대부분은 직속 관리자, 아마도 수석 또는 수석 개발자). 어떻게 이런 식으로 얻었습니까? 모르겠어요 회사의 조직 문제 일 수도 있고, 호의를 표한 다음 직접 연락하여 "아니오"라고 말하지 않은 결과 일 수도 있습니다. 또는 내가 아는 모든 것에 대해 직무 관리자가 작업 파견과 관련된 문제 일 수 있습니다 (실제로 추측하고 있지만 패턴은 인식 가능하고 잘 알려져 있습니다).

다음과 같이 빨리 수행하는 것이 좋습니다. 직접 관리자에게 직접 이야기하고, 다른 관리자가 약간 압박 적이거나 (아마도 덜 성가신) 너무 많은 사람들이 쌓은 물건이 있다고 설명하고 우선 순위를 정할 대상을 알기 위해서는 그의 의견이 필요할 것입니다.

180도 변경 요청

이것들은 또 다른 큰 문제입니다. 그것들은 아마도 당신의 잘못이 아닐 수도 있지만, 그것들을 해결하도록 도울 수 있습니다.

"180-degress 변경 요청"은 아름답고 정확하게 호출 할 때 요구 사항이 점점 흐려 지므로 시간이 지남에 따라 요구 사항을 해결하기 위해 열심히 노력하지 않는다는 분명한 신호입니다 .

일반적으로 누군가 전화로 (또는 발로 더 나은) 발걸음을 내딛고 이해 당사자 들의 손을 잡고 명확하게 말해야합니다. 올바른 방향으로 향하고 있습니까? " 처음에는 명확한 답변을 얻지 않아도되지만 시간이 지날수록 더 명확 해 지거나이 프로젝트는 재난이 기다리고 있습니다.

일반적으로 나는 모든 이해 당사자를 손에 쥐고, 방에 넣고, 논쟁을 불러 일으키고, 점진적으로 문제를 해결하고,이를 해결하기 위해 우선 순위를 얻는다. 그러나 귀하의 경우에는 이미 전화를 걸지 않은 것일 수 있습니다. 그러나 당신은 그들이 실제로 당신에게 프로젝트의 책임을 주었다고 언급합니다. 실제로 그러한 경우 책임을지고 그렇게하십시오. 그리고 "우리는 그렇게 할 수 없다 " 고 말 하거나 "우리는 그렇게하지 않을 것" 이라고 부끄러워 하지 마십시오 . 프로젝트의 범위를 제한하는 것이 정말 중요합니다.

범위가 없으면 토론 끝에 명확한 요구 사항이 없습니다.

이메일 과부하

사람들은 사용하는 통신 매체에 따라 다르게 행동하는 경향이 있습니다. 개인적으로, 나는 다소 부드러운 말을하는 사람이지만 (대부분 외국에서 일하고 있으므로 전화를 많이하지 않기로 결심합니다) 생산성에 따라 선호하는 순서대로 선호합니다.

• 사람들과 직접 대면 하고
• 전화로 사람들과 대화하고
• 메신저를 통해 사람들과 대화하고
• 이메일을 통해 사람들과 대화합니다.

전자 메일은 추적, 확인, 메모 전송에 유용합니다.

문제 지점을 예약, 계획 및 논의 할 때 쓸모가 없습니다. 그 사람이 문을 열 때까지 문을 두드리고 메모장과 문서 사본으로 앉아서 물건을 명확히하십시오. 완료되면 이메일을 보내고 확인을 요청하십시오. 봉투에 다른 것을 몰래 넣는 부정적인 대답이나 약간의 숨겨진 시도로 다시 돌아 오면 대변인의 사무실을 다시 포위하십시오.

이것은 소프트웨어 공학입니다. 키보드로 타이핑하지 않으면 생산성이 높아지고 실제로 처리해야 할 쓰레기를 미리 줄일 수 있습니다.

팀의 일의 가치

팀의 일에 해당하는 일을하고 있습니까? 아마도.

당신은 팀의 일에 상응하는 일을하고 있습니까? 아마 아닙니다.

내 말은 당신의 팀은 아마도 바쁘게 일하고 있고 당신은 과로 한 것입니다. 그리고 그것은 문제입니다 : 당신은 현재 프로젝트 타임 라인에서 밀려나거나 시간을내어 누군가에게 주어져야하는 것들로 과부하가 걸리게됩니다.

처음에 상황이 달라졌을 때 바보였습니까?

아니; 파티에 처음입니다. 처음 끊어진 관계 나 관계입니다. 당신은 그것을 극복합니다.

이 게시물이 큰 폭동으로 변한 것 같지만 모든 개발자에게 동일하지는 않다고 알려주십시오.

이것은 혼란스러운 조직의 모든 개발자에게도 동일합니다. 스타트 업 또는 잘 설립 된 거대 기업이며 규모의 오른쪽에서 생존 가능성을 높이기 위해 일을 조금씩 움직일 경험이나 자신감이 없습니다.

추신 내 급여는 슈퍼마켓에서 계산원보다 낮은 경우 거의 동일합니다.

나는 엉뚱한 것처럼 보이는 직업에 대해 적절한 급여를 받았다. 수표의 숫자가 아니라 문맥입니다. 귀하가하는 일, 나이, 거주 및 근무 장소 등

즉, 당신이 심한 임금을받지 못하고 너무 많이 일하고 완전히 후배가 아니라면 그 인상을 요청하거나 새로운 일자리를 얻으십시오!

간단 해:

• 그들이 당신이하는 일을 소중히 여기면 기꺼이 인상에 동의 할 것입니다.
• 그렇지 않다면,이 회사의 미래는 매우 장미 빛으로 보이지 않습니다 (적어도 당신에게 중요한 것은). 따라서 떠나는 것에 대해 나쁘게 느끼지 마십시오.

인상을 요구하는 것을주의 입니다 당신이 처음에 그렇게 생각 enclined되지 않는다하더라도, 좋은 일이. 그것은 당신이하는 일을 추적하고, 기내에서 계속 기꺼이하면서 다른 옵션을 주시한다는 것을 암시합니다. 직업 면접이나 일반적으로 흥정하는 것처럼 요청하는 데 익숙해지는 것이 좋습니다. 실습이 필요하며 직접 연락하지 않으면 하늘에서 떨어지지 않습니다. 일부 회사는 요청하지 않고 정기적으로 모금을 배포 할 것입니다.하지만 반값을 줄이고 행복을 기꺼이 바꾸지 않는다는 사실을 알기에 충분히 영리하기 때문입니다. 그들이 직접 제안한 인상 제안을 올리는 것이 다소 불안합니다.

이 요청을 진행하는 방법은이 프로젝트의 범위를 약간 벗어 났으므로 자세한 내용은 다루지 않겠습니다. 그러나 SCM 커밋 ID, 수정 된 버그 및 업적에 대한 기록을 작성하고 팀의 전반적인 노력과 비교하여 보고서를 준비하는 것이 좋습니다. 이 방법:

• 효과적으로 동료보다 더 많은 일을했는지 ​​여부 를 스스로 측정 할 수 있습니다 .
• 귀하의 요청이 정당하지 않다고 말하면 귀하의 입장을 견딜 수 있습니다 .

다른 사람들의 의견 외에도 :

1. 예, 엔트리 레벨 직원에게는 다른 사람이 원하지 않는 작업이 제공되는 것이 일반적입니다.

2. 이것을 미래의 경력을위한 빌딩 블록으로보아야합니다.

그래서 어떻게해야합니까? 전문 개발자로서 자신을 증명하려면 작업이 구조화되고 계획되어 있는지 확인해야합니다. 그렇지 않으면 현재하고있는 좋은 일을 바탕으로하기가 어려울 수 있습니다. 따라서 다음과 같은 작업을 수행해야합니다 ( 당신은 아직 아닙니다).

1. 각 프로젝트에 대한 작업을 정확하게 기록하십시오. 따라서 프로젝트 A의 버그를 수정하는 데 1 시간을 소비한다면 이번에는 기록하십시오. 작업 부하에 대해 논의하려는 경우 관리자에게 보여줄 때 유용합니다.

2. 단위 테스트를 작성하십시오. 당신이 유지 관리하는 프로젝트 중 일부는 버그로 가득 차 있다고 언급하므로 단위 테스트는 거의 없습니다. 각 버그 보고서에 대해 버그를 복제하는 단위 테스트를 작성한 다음 버그를 수정하십시오. 이를 통해 회귀가 발생하지 않도록하고 코드의 품질을 향상 시키며 기회가 주어질 경우 코드를 리팩터링 할 수있는 플랫폼 역할을합니다 (예 : 이해 관계자에게 일부 부분을 다시 쓰면 개선 될 수 있음을 설득하는 데 도움이 될 수 있음) 단위 테스트 스위트로 인해 새로운 버그가 발생하지 않는 품질).

3. 새로운 직업을 찾으십시오-한 번에 많은 프로젝트에서 작업하고 코드를 처음부터 작성했으며 전체 프로젝트 라이프 사이클을 경험했을 것입니다. 이는 다른 곳에 적용하기에 좋은 경험입니다.

귀하의 상황은 약간 초조하지만 여전히 정상입니다. 그러나 당신이 그것을 처리하는 방식은 매우 나쁩니다. 해야 할 일은 다음과 같습니다.

• 상사와 대면하십시오. 나쁜 코드베이스가 실제로 얼마나 많은 시간을 소비했는지에 대한 증거 (수)가 있어야합니다. 그가 기술 부채와 같은 것을 이해하지 못하면 언급을 중단하십시오. 머리가 아파서 '나쁜 태도'사람으로 표시 될 수 있습니다. 상사에게 그의 일을하도록 가르치는 것은 당신의 일이 아닙니다.

• 자신의 백 로그 (kanban)를 유지하십시오. 새로운 작업이 끝나면 종료하고 예상 완료 시간을 알려줍니다.

• 응답 시간을 늘리고 하루에 두 번만 이메일을 확인하십시오. 일반적으로 점심 식사 전과 떠나기 직전. (이메일을 확인한 후에는 머리가 깨질 수 있으므로 코딩을해서는 안됩니다).

• 각 작업의 일부로 작은 코드를 개선하십시오. 사용중인 코드, 기술 및 도구를 개선하는 것은 단순히 당신의 일입니다. 또한 장기적으로 당신의 도덕성을 향상시킬 것입니다.

• 낮에는 프로젝트 전환이 없습니다. 오늘은 단순히 프로젝트 X에서 작업하고 있으며 내일 Y에 대한 다른 작업을 시작합니다.

• 게이트 유지를 위해 하루에 1 시간을 할당하십시오. 그것은 사소한 작은 작업을 의미합니다. 이 작업이 10 분 이상 걸리는 경우 (이유가 무엇이든 상관 없음) 백 로그로 이동하여 관리자에게 지연 될 것이라고 알립니다.

이제 어려운 부분이 온다. 현재 관리자는 서로 의사 소통하지 않고 자신의 프로젝트를 최대 우선 순위로 완료한다고 가정합니다. 당신이 논쟁의 중간에 있기 때문에 이것은 당신의 머리에 많은 스트레스를 가져옵니다. 관리자가 작업 조정을 시작하도록해야합니다. 결국 당신은 훌륭하고 간단한 백 로그를 가져야하며 관리자는 당신없이 서로를 괴롭 히어야합니다.

간단한 역할 연기를 해봅시다. 3 개의 관리자와 프로젝트가 있습니다 (프로젝트 X의 Xavier, 프로젝트 Y의 Yvonne, 프로젝트 Z의 Zed). X의 경우 5 일, Y의 경우 5 일 동안 2 주 동안 백 로그가 있습니다.

• Z는 몇 가지 작업을 수행하도록 요청합니다 (1 일)
• 11 일 후에 완료 될 것이라고 응답합니다.
• Z는 간단한 작업이며 하루 이상 걸리지 않아야한다고 응답합니다 (Z는 작은 압력을 가함).
• 귀하는 현재 X에서 근무하고 후자는 Z에서 근무하고 있다고 응답합니다. 그 후 그녀의 업무를 수행 할 수 있습니다.
• Z는 어쨌든 자신의 임무를 즉시 수행해야한다고 응답합니다 (압력 증가, X 및 Y 영역에 대한 직접적인 위반).
• 그녀는 그녀의 임무를 수행하면 X와 Y의 업무가 지연 될 것이라고 대답합니다. CC X와 Y도 있습니다.

이제 두 가지 끝이 있습니다.

• 관리자들은 서로 짖기 시작할 것입니다. 많은 이메일, 아마도 회의가있을 것입니다.

• 아무 일도 일어나지 않을 것입니다. Z는 이틀 후 그의 임무가 어디 있는지 묻습니다. 귀하는 현재 X를 위해 일하고 있으며 프로젝트 Z에 대해서는 언급하지 않았습니다. 다시 CC X.

이제 이런 유형의 행동으로 해고 당할 수 있습니다. 그러나 당신의 상황은 지속될 수 없으며, 당신은 아마 곧 종료 될 것입니다. 이 솔루션은 관리자가 서로 경쟁하는 경우에만 작동합니다 (매우 일반적인 경우). 누군가가 불평 할 경우에 대비하여 자신의 작업 기록 (백 로그)을 보관해야합니다.

7 년 전 저는 100 % 정도의 유지 보수 작업을하고 있었으며 이에 관한 기사를 썼습니다 : 유지 보수 프로그래밍의 기술 . 유용한 부분은 다음과 같습니다.

1. 그것을 좋아하십시오

유지 보수 프로그래밍을 좋아하는 사람은? 개발자는 팀의 수석 아키텍트가되는 것을 꿈꾸며, 기존 소프트웨어를 유지 관리하면 거의 벌과 같은 느낌이 듭니다. 유지 관리 프로그래밍에는 고유 한 문제가 있으며 많은 창의성, 적응성, 인내심, 규율 및 의사 소통이 필요합니다. 이력서에“건축 된 n-tier 24/7 엔터프라이즈 응용 프로그램”과 같은 강력한 항목이 있으면 좋을 것 같지만 고용주는 실제로 문제를 해결하는 사람들을 소중하게 생각합니다. 유지 보수 프로그래밍은 문제 해결 기술을 보여줄 수있는 좋은 기회가 될 수 있습니다.

문제는 더 자주 듣는 뭔가처럼 들립니다. 그것은 매일 WTF 에 쉽게 맞을 수있는 직업인 것 같습니다 .

많은 조직이 품질보다는 영업 또는 기능 추진에 더 중점을 둡니다. 그 회사들이 보지 못하는 것은 소프트웨어의 외부 품질 이상이 있다는 것입니다. 워드 커닝햄 은 기술 부채 라는 용어를 만들었다 .

기술 부채에 대해서는 Steve McConnell 을 읽어 보시기 바랍니다 . 그는 흥미로운 점이 있습니다. Google Tech Talk에서 Ken Swaber는 애자일 소프트웨어 개발에 대해 이야기 합니다. 좋은 부분은 당신과 비슷한 이야기에 관한 것입니다. 그는 리팩토링을 하지 않고 다양한 프로그래머가 10 년 동안 프로그래밍 한 후 "브레인 데드"가 된 소프트웨어 프로젝트에 대해 이야기합니다 . 이 비디오를 보면 당신이 묘사 한 것과 많은 유사점을 보게 될 것입니다.

모든 소프트웨어 시스템은 확장 될 때 품질이 저하됩니다. 실제로 극복하기 위해서는 꼭 필요한 일이다. 리먼 법은 아주 잘이 원리를 설명한다. 궁극적으로 다음 질문으로 귀결 될 것입니다. "상사가 리팩토링을하도록 설득하려면 어떻게해야합니까?" .

비슷한 문제에 어떻게 접근 했습니까?

• 상사와 대면하여 개발을 계속할 때 코드 품질이 저하된다고 설명했습니다 ( Lehman Laws ).
• 나는 상사에게 기술 부채 의 개념을 설명하려고 노력했다 . 그리고 그가 당신을 일하게하는 방식은 장기적으로 그에게 돈이 드는 방법입니다.
• 실제로 문제가 얼마나 심각한지를 보여주기 위해 (내 시간에) 정적 코드 분석을 수행했습니다. 상사는 소프트웨어를 이해하지 못하지만 숫자를 이해합니다. 코드 메트릭스에 결함이 있지만 측정 할 수있는 것이있는 것이 좋습니다. 이러한 측정 항목에 대한 일반적인 측정 값을 찾으십시오.이를 자신의 코드베이스와 비교할 때 놀라게됩니다.
• 도움이되지 않고 변화가 없다면, 새로운 기능을 사용하려면 코드베이스의 다른 부분을 일부 재 작업해야한다는 것을 설명해야합니다. 중복 코드가 있고 변경 비용이 중복되는 것을 변경하려는 경우 설명하십시오.
• 이전 요점에 대한 일반적인 답변은 아무도이 재 작업에 대해 요청하지 않았으므로 지불하지 않았다는 것입니다. "아마도"이 재 작업은 불필요한 것입니다. 소프트웨어는 항상 변경해야한다고 설명해야합니다. 리먼 율법이 말하는 것처럼 ; 사용 상태를 유지하려면 변경해야합니다. 그렇지 않은 경우 변경 한 다른 프로그램은 항상 유효합니다. 변화를 기대하고 생존 할 변화에 적응할 수있는 사람들입니다. 이것이 민첩한 소프트웨어 개발 에 관한 것입니다. ( 위키 백과 )

요즘 상사는 기술 부채 개념을 사용하여 고객에게 때때로 우리가 구축 한 소프트웨어의 일부를 재 작업해야한다고 설명합니다. 그것을 증명하기 위해-합리적인 보스가 있다면 더 나은 것을 바꿀 수 있습니다.

당신이 직면 한 상황은 많은 신입생들에게 거의 동일합니다.

이것은 경력의 초기 단계에서 발생합니다. 여기에 문제가 있습니다. 우리는이 문제를 극복하고 회사에 대한 가치를 증명해야합니다 (중소형이든 MNC 이든 ). 우리는 상황이 우리에게 무엇을 요구하는지에 대한 결정을 내릴 수 있어야합니다. 따라서 작업에 노력을 기울이는 데 아무런 해가 없습니다. 당신이 가치가 있다면, 회사는 주목할 것입니다! Adios와 행운을 빕니다.

제 생각에는 리팩토링을 금지하는 회사는 효과가 없습니다. 리팩토링은 필수적인 소프트웨어 개발 기술이며, 버전 관리 툴은 매우 쉽게 (A 리팩토링 실제로 사건의 '몸통'손상없이 분리의 변화를 개발할 수 않는 무언가를 휴식을). 으로 삼촌 밥 말한다 (의역) : "당신은 전문을하고 직업 권리를 할 물어하지 있어야합니다."

유지 관리 프로그래밍은 잘못된 코드를 계속 유지한다는 의미는 아닙니다.

5 년 전에 친구 중 한 명으로부터이 이메일을 받았습니다.

Email body:    

새로 연수 된 엔지니어 엔지니어가 상사에게 "평가의 의미는 무엇입니까?"

보스 : "사임의 의미를 알고 있습니까?"

연수생 : "그렇습니다"

보스 : "사 평가와 비교하여 평가가 무엇인지 이해하도록하겠습니다."

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

연수생 : "예, 충분합니다. 이제 내 미래를 이해했습니다. 감정을 평가하려면 사임해야합니다 ... !!!"

내가 당신이라면, 나는 무료로 응용 프로그램을 재건 작업 후 늦은 시간을 보낼 것입니다. 아마도 재미있는 작업 일 것입니다. 완료하면 상사에게 보여주십시오. 그것이 작동하고 유지 보수를하고 있다면 걱정할 필요가 없습니다. 이것은 당신의 일을 훨씬 쉽게 해줄 것이며 회사에서 당신의 잠재력에 대한 상위층의 시선을 열 것입니다.

저는 시간당 10 달러에 파트 타임 인턴십을하는 풀 타임 대학생입니다. 지루하고 반복적이며 쉬운 품질 관리를합니다. 나는 언젠가 이것이 더 크고 더 나은 곳으로가는 문을 열 것이라는 것을 알고 있기 때문에 나는 내가 운이 좋다고 생각한다.

예, 항상 본인과 다른 사람이 작성한 응용 프로그램을 유지 관리해야합니다. 유일한 유지 관리가 필요없는 프로그램을 작성하는 경우는 예외입니다. 따라서 유지 관리를 잘하는 것이 좋습니다.

귀하의 접근 방식의 결함에 대한 귀하의 질문에 미묘한 힌트가 있다고 생각합니다. 즉, 버그 수정에는 코드 개선이 필요하지 않습니다.

그러나 기존 코드를 개선 할 수 없으며 버그가보고 될 때만 버그 수정에만 집중할 수 있다고 들었습니다.

누군가가 "코드를 개선하지 않고 버그를 수정해야한다"고 말한 것을 믿을 수 없습니다. 이 어려운 둘 다 와 불가능합니다. 할 수없는 것은 기존 코드 기반에서 사용 된 접근 방식이 마음에 들지 않거나 이해하기 어렵다는 이유로 응용 프로그램을 다시 작성하는 것입니다.

내 조언은 리팩토링하는 법을 배우는 것입니다. 버그를 고칠 때마다 최소한 일부 코드를 개선 할 수있는 기회가 있습니다. 코드베이스가 리팩토링되는 정도는 버그가 무엇인지, 코드가 얼마나 좋은지 나쁜지에 달려 있습니다. 그러나 버그를 수정하고 고의로 코드를 남겨두면 작업을 수행하지 않고 기술적 부채가 발생 합니다.

일부 버그는 실제로 리팩토링으로 간단히 수정되며 때로는 코드를 이해하는 데 도움이 되도록 리팩토링하는 것이 유용 합니다 . 리팩토링은 코드의 유지 관리 성과 일관성을 향상시켜야하기 때문입니다.

버그 수정을 추정 할 때는 대개 주요 리 팩터가 최선의 방법인지 결정하고이를 고려합니다. 단위 테스트와 동일합니다. 이 두 가지 모두 시간을 요하는 선택 사항이 아니라 코드 작성 방식의 일부 여야합니다.

"버그를 고칠 때 코드를 개선 할 수 있습니까?"라고 묻지 말아야합니다. 당신은 어쨌든해야합니다. "리팩토링을 사용하여 버그를 해결할 수 있습니까?"라고 묻지 않아야합니다. 애플리케이션이 버그를 일으키는 코드가 리팩토링이 절실히 필요한 경우 어쨌든 수행해야합니다. "이 버그를 고칠 때 단위 테스트를 작성할 수 있습니까?"라고 묻지 말아야합니다. 버그 수정을 시작하기 전에 회귀 테스트를 작성해야하기 때문입니다.

NB :이 답변에 대한 일부 속성은 Jeff Atwood에게 가야한다고 생각합니다.

이것은 돈에 관한 것입니다. 내 생각에, 당신은 아마도 당신이 이미 지불 한 것보다 더 많은 것을 얻은 고객에게는 너무 친절 할 것입니다.

새로운 요청에 대한 가격 견적을 배우십시오. 이것은 쉬운 일이 아니며 고객은 종종 당신을 시험해 볼 것입니다. 가능하면 숙련 된 프로젝트 / 제품 관리자의 도움을 받으십시오.

일단 돈으로 생각하면 경영진과의 의사 소통이 훨씬 쉬워집니다. 현재 고객이 풀 타임 돈을 제공하는 경우 새 프로젝트를 선택하지 않아야합니다. 그러나 경영진이 여전히 당신을 괴롭 히려고 시도한다는 것을 이해할 것입니다.

실제로 회사에 가치가 있다면, 협상력을 얻게 될 것입니다. 직원 수를 늘리고, 새로운 프로젝트를 줄이거 나, 유지 관리 부하를 줄이거 나 급여를 늘리도록 요청할 수 있습니다.

기존 코드를 개선하는 것이 금지되어있는 정도까지 귀하를 미세 관리하는 것은 고용주의 결정이 아니어야합니다. 자신의 전문적인 판단을 사용하십시오. 작업을 추정 할 때 향후 생산성을 향상시킬 경우 리팩토링이 가능하도록 추가 시간을 고려할 것입니다.

어쨌든, 당신은 당신의 고용주와 효과적으로 의사 소통을하지 않는 것 같습니다.

1. 리팩토링으로 돈을 절약 할 수 있다는 증거가 있습니다. 리팩토링 프로젝트를위한 제안서를 작성하고 비즈니스가 얼마나 많은 시간과 돈을 절약 할 수 있는지 보여줍니다. 코드 변경 내용과 소요 시간을 정확하게 설명하십시오.

2. 정확한 로그를 유지하여 코딩, 회의 및 이메일 응답에 소비 한 시간을 기록하십시오. 일정이 뒤처지면 보호 할 것입니다.

3. 천천히 해. 약간 직관적 인 것처럼 보일 수 있지만 모든 것을 빨리하면 시간이 남용됩니다. 덜하면 사람들은 당신의 시간을 더 존중할 것입니다. 예를 들어 하루에 한두 번만 이메일을 확인합니다. 그렇지 않으면 화상의 위험이 있습니다.

4. 임금을 고려할 때 두통을 겪을 가치가 없습니다. 매일 정시에 떠나십시오. 추가 보상없이 추가 시간을 투자하지 마십시오. 예외적으로 좋은 승진 옵션이 있거나 회사의 명성이 이력서를 크게 높일 경우 예외입니다.

더 많이 알지 못하면, 당신이 당신의 관리자들에게 더 개방적으로 노력할 것을 제안합니다. 아마 당신의 작업 견적을 높이기 시작합니다. 작업량이 얼마나 많은지 지속적으로 알려줍니다. 또한 상사와 만나 향후 6 개월 이내에 급여 인상을 원한다고 설명하고 임금 인상을 달성하기 위해 성과를 개선 할 수있는 방법을 문의해야합니다.

행운을 빕니다.

내 경험상, 학업 세계 또는 기술 중심 스타트 업의 첫 6-12 개월은 진정한 빈 슬레이트를 경험할 수있는 유일한 두 분야입니다. 둘 다 자체 비용을 부담하지만 코드 작성을 좋아하고 종종 야생에서 발견되는 코드의 품질에 끔찍한 경우 경력 중 하나를 다음 방향으로 지정해야합니다.

고용주와 대화하고 해결이 가능한지 확인하십시오. 당신이 이것에 대해 머리를 숙이고있는 것처럼 들리며 나쁜 프로그래머가되는 것과는 아무런 관련이 없습니다.

소규모 웹 회사는 동시에 많은 프로젝트를 진행하는 경향이 있으며, 그로 인해 여러 가지면에서 귀하를 한 자리에있게됩니다. 자신의 상황을 최대한 활용하거나 가능하다고 생각되면 새로운 직업을 찾으십시오. 나는 더 나은 코딩 작업이 있다고 약속 하므로이 첫 번째 작업이 당신을 놀라게하지 마십시오.

행운을 빌어 요. 당신과 동료 모두 중력이나 노력을 이해하기를 바랍니다!

개인적인 경험

여기의 많은 사람들처럼 나는 또한 당신의 상황을 인식합니다. 나는 기본적으로 저임금으로 첫 코딩 작업을 받았으며 구조가 좋지 않은 많은 빌드 코드를 유지해야했습니다. 처음에 나는 새로운 것을 배우는 것이 재미 있다는 것을 알았지 만 결국에는 유지해야 할 많은 프로젝트, 새로운 프로젝트를 만들며 화이트 보드가 매일 커져가는 지점으로 점점 커져갔습니다. 작동하지 않았습니다.

2 년 동안 그것을 끝내고 나서, 나는 두 달 후에 나에게 완벽하게 맞는 또 다른 코딩 작업을 발견했습니다.

어쨌든 여러 번 문제가 될 수있는 것은 프로젝트 만이 아닙니다. 나는 일에 대한 인정과 존경을받을 때 직장에서 더 편하다고 느낍니다. 현재 상황의 문제는 고용주가 다른 모든 버그를 제거하는 데 걸리는 시간이 아니라 생성 된 프로젝트에서 발생하는 버그만 알아 차릴 수 있다는 것입니다.

봉급

더 많은 돈을 원한다면 종종 얻을 수 있습니다. 저는 2 년 안에 급여를 33 % 인상하기 위해 협상했습니다.

기본적으로, 업무의 가치와 회사에 필요한 금액을 생각하십시오. 그들이 당신에게 벌어 들인 급여를 줄 여유가 없다면, 회사는 그들의 비용을 보거나 사업이 작동하지 않는다는 것을 깨달아야합니다.

그리고 여기에 많은 사람들이 언급했듯이, 당신은 매우 귀중한 회사 퍼즐 조각입니다. 지옥, 당신은 아마 그 퍼즐을 해결할 수있는 유일한 사람 일 것입니다. :)

이 Stack Exchange 사이트의 사기꾼이기 때문에 아직 댓글을 달 수 없으므로 여기에 정보를 추가하면됩니다.

1. 방금 시작한 이래로 Microsoft, Amazon 또는 이와 유사한 대기업에서 일하지 않으면 급여가 별빛이 아닙니다. 그러나 식료품 점 직원이어서는 안됩니다! 오랫동안 참지 말고, 현재하고있는 일에 대한 경험을 쌓고 더 나은 기회가 생길 때 계속 나아가십시오.

2. 엔트리 레벨 공연의 경우 이것은 정상입니다. 작업량이 너무 많지만 작업 유형이 예상됩니다. 더 나은 개발자가 되려면 다른 사람의 실수에서 배워야합니다. 많이 볼수록 더 좋아집니다. 그러나 그것은 나쁜 습관을 배우지 않고 배울 것을 찾고 있음을 의미합니다 ...

3. 유지 보수와 프로젝트 작업의 비율은 시간이 지남에 따라 변해야합니다. 그렇지 않다면 그것은 당신이 일하는 회사가 좋은 개발자를 유지하는 방법을 깨닫지 못한다는 것을 의미합니다. 그들은 당신이 매일 같은 일을하도록하려고합니다. 당신이 원하는 곳, 연봉 및 직업 기대치를 현명하게 결정하고 그에 따라 움직이십시오.

4) 당신이 행복하지 않으면 떠나십시오! 어리석은 사람들을 다루기에는 인생이 너무 짧습니다.

모두 제일 좋다.

할 일 목록을 추적하기 위해 이슈 트래커를 사용하기 시작합니다.

이렇게하면 중요한 내용을 추적하는 데 도움이 될뿐만 아니라 사용자와 상사가 현재 작업량을 파악하는 데 도움이됩니다.

또한 두 번째 개발자를 고용 한 경우 (또는 사용자가 종료하고 교체 작업이 이제 작업 부하를 차지할 경우) 작업 부하를 관리하는 데 도움이되고 서로 발가락을 밟지 않아도됩니다.

이 체인을 깨는 유일한 방법은 유연성을 위해 설계되었으며 전체 단위 + 통합 테스트를 거친 새로운 인프라를 개발하는 것입니다.

이 정보를 경영진에게 판매 할 경우 (다른 개발자 및 관리자에게 1 : 1 미팅에서 개념에 서명), 애플리케이션 코드의 대부분이 인프라에 있고 상태가 쉬운 상태에 천천히 도달 할 수 있습니다. 실제 응용 프로그램은 가벼우 며 꽤 빨리 쓸 수 있습니다.

인프라의 개발로 인해 기존 애플리케이션의 일부를 처음에 교체하고 전체 애플리케이션을 교체하는 데 몇 년이 소요될 수 있습니다.

장기적으로는 새로운 응용 프로그램의 개발 시간과 미래의 기존 응용 프로그램의 유지 관리 시간을 크게 줄일 수 있습니다.

새로운 개발에는 한 명 이상의 개발자로 구성된 팀과 함께 최소 80 %의 헌신이 필요합니다 (바람직하게는 더 많음). 모든 개발자는 창의적으로 사고하고 기존의 선입견을 어길 수 있어야합니다.

이러한 새로운 인프라를 정의하고 높은 수준으로 설계 한 다음 동료 및 관리자에게 정의를 제시하십시오.

근무 조건으로 정의 및 설계를 기반으로 이러한 문제를 해결하는 새로운 인프라 팀을 이끌고 새로운 개발자가 필요한 경우 지원하는 동안 오래된 것을 유지하도록 요청하십시오 (최대 10-20 % 시간). 경영진이 아이디어에 동의하면 조건을 재협상하도록 요청할 수 있습니다. 거부하면 다른 직업을 찾을 준비를하십시오. (직업에는 기술, 지식 및 경험이 필요하다는 것을 기억하십시오. 그들은 당신이 믿고 지불하는 것만 큼 쉽게 교체 할 수는 없습니다.)

관리자가 이러한 모든 변경 요청 (유지 관리 요청)을 알고 있습니까? 귀하는 제재 권한이없는 그러한 요청을 통해 귀하의 시간이 걸러지고 있음을 알고 있습니까? 아니면 관리자가 요청할 때마다 변경을합니까?

전화의 첫 번째 포트는 관리자의 책상에 모두 넣는 것 같습니다. 아무도 당신에게 직접 오지 않아야합니다. 문제는 일반적으로 지원 팀과 같은 모든 분야를 통해 발생합니다. 짧은 인계 기간 (보통 1 주 정도) 동안 코드를 지원하는 것이 일반적입니다. "중간 규모"로 분류되는 회사에서는 변경 비용이 발생하고 청구 (전송 청구)되어야하며, 이는 우회되고있는 것처럼 보입니다 (그들이 범람하는 것은 당연합니다.

문제 제기 및 변경 요청에 대한 적절한 요청 절차가 있어야합니다. 지원 / 유지 보수는 버그 및 문제 수정에 관한 것입니다 (원래 사양에는 맞지만 코드의 버그 또는 외부 이벤트 (예 : 전원 차단 또는 손상된 업스트림 시스템 등)로 인해 실패 함).

귀사에서이 중 어느 것도 제공하지 않고 무수한 임의 요청에 대처하고 책임을 져야한다면 진지하게 고려해야합니다. 급여는 항상 바닥이 좋지 않습니다. 첫 번째 프로그래밍 작업 (거의 25 년 전)에서 저는 같은 회사에서 8 년을 보냈으며 임금은 거의 올라가지 않았습니다. 떠난 지 2 년 만에 나는 그것을 두 배로 늘렸다. 그리고 2 년 후 나는 내가 처음 시작했던 것보다 10 배 이상 집으로 돌아가고 있었다 (그러나 독립 계약자였다). 언제나처럼, 당신은 박차를 얻고, 무역을 배우고, 따뜻한 환경으로 배를 뛰어 넘습니다.

아마도 당신은 관리자에게 가서 다음과 같이 말할 수 있습니다. "봐, 나는 너에게 솔직 할거야. 내 임금은 끔찍하다. 나는 X에서 엔트리 레벨 프로그래머로 이것을 N 배 얻을 수있다.

A, B 및 C로 너무 많은 일을하고 있습니다. 이것을 유지할 수 없습니다. 솔직히 말해서, 의도 된 바가 없습니다. 저는이 문제를 해결하거나 사직서를 남겨두고이 방에서 나갈 것입니다. 이제이 모든 것이 공중에 나왔으니 어떻게하면이 일을 제대로 할 수 있을까요? "

대답은 이해할 수있는 용어로 시도하고 설명하는 것입니다.

• 오일 교환과 같습니다. 긴급하지는 않지만 정기적으로 수행해야합니다.
• 녹 위에 페인트하면 멋지게 보입니다. 피가 나올 때까지
• 강화지지없이 새로운 지붕 안뜰 지붕 책상을 구축하십시오. 아마도 잠시 동안 작동 할 것입니다. 그러면 사람들이 무너져 다치게되고 책임을 져야합니다.
• a / c는 훌륭합니다. 창 단위는 하나 또는 두 개의 방에 적합합니다. 146 개의 창문 단위 에어컨을 아파트 건물에 넣으려고하면 문제가 발생합니다.
• 5 명의 아이들을 가르치는 것은 좋습니다. 10도 나쁘지 않습니다. 그러나 한계가 있습니다. 비공식적으로 75 명의 아이들을 가르치면 이것을 볼 수 있습니다.

이것들이 공명하지 않으면. 휴가를 떠나십시오 – 당신이 다음 날이 아니라 서면으로 제안하는 날! 새 직장을 찾은 후에는 ZERO 통지를 남기십시오. 말 그대로 그날 들어오지 마십시오. 그러나 당신이 한 일을 아는 동료가 있는지 확인하십시오. 이것은 회사가 도움을받을 수 있다면 무례 함과 오만이 대가를 치르고 있음을 보여줌으로써 실제로 회사를 도울 것입니다. 지난 회사는 6 개월 안에 4 개의 기술을 남겼습니다. 그것은 적어도 성명서를 발표하고 떠날 사람에게 한 번 좋은 기회를 주었다.

마지막으로,이 업무 단계는 NORM이며 20 년 전 민첩, tdd, bdd 및 리팩토링이 표준이되기 전의 표준이라는 것을 알고 있어야합니다. "내가 직접이 작업을 수행했는데 문제없이 작동했습니다." 물론 말과 마차는 150 년 전에 잘 작동했습니다. 기술 분야에서 20 년 전의 기술은 150 년 전의 교통 기술만큼 구식입니다. 그들이 이것을 거부한다면. 그들이 고집하는 괜찮은 현재의 기술 개발자를 고용하지 않을 것이라는 것을 알고 계십시오. 그들은 최악의 최악의 상황을 겪게되며 사업을 심각하게 해칠 것입니다. 그들이 기술에 의존하고 적응할 수 없다면 그들은 실패 할 것이고 결국 그것은 당신에게 최고의 보상이 될 것입니다. 그것'

경영진이 근본적으로 당신을 존중하지 않거나 업무 부하를 이해하지 못하는 것 같습니다.

모든 기능 요청을 구현해서는 안됩니다. 관리자는 귀하와 들어오는 요청 사이의 버퍼 역할을 수행해야합니다 (가장 간단한 중단 / 수정 요청 제외). 그런 다음 귀하와 함께 앉아 승인 된 요청에 대한 가능성과 우선 순위를 결정해야합니다.

또한, 그들이 지불하는 금액을 (최소한) 2 배로 만들어야합니다.

아마도 당신과 함께 일하기 위해서는 적어도 1 명 이상의 개발자가 필요할 것 같지만, 그들이 지불하는 것은 거의 없을 것 같습니다.

그들이 당신에게 적절하게 돈을 지불하지 않거나 당신의 업무량을 관리하는데 도움이되지 않는다면, 나는 새로운 직업을 찾고있을 것입니다. 팀 의 일원 이되고 프로젝트를 완료하기 위해 경영진과 협력하는 곳에서 일하고 싶습니다 . 가급적 빨리 가라 앉는 배에서 내리십시오.

하나의 팀에서 영웅이되는 것은 당신을 태워 버릴 것입니다.

나는 학생 일 뿐이지 만 (인턴쉽 경험에서) 그것은 꽤 정상입니다. 이것이 지원 및 웹 응용 프로그램에서 작업 할 때 얻는 것입니다.

코딩을 시작하기 전에 클라이언트 (관리자)가 원하는 것을 이해하는 것이 좋습니다. 때때로 그들은 스스로 모르기 때문에 무언가에 동의 할 때까지 함께 일하기 때문에 까다로울 수 있습니다. 코딩하기 전에 최종 솔루션에 모두 동의해야합니다.

또한 관리자 인 경우 코드에서 거의 모든 것을 변경할 수 있습니다. 동작을 변경하거나 버그를 일으키지 않도록하십시오. 관리자는 현재 상황에 익숙하고 기쁘고 새로운 변경에 대한 비용을 지불하고 싶지 않기 때문에 어떤 것도 변경할 수 없습니다.

마지막으로, 다른 일을하기 때문에 처리 할 수없는 경우 걱정하지 마십시오. 나는 사람들에게 당신이 일에 압도 당하고 그들의 요청에 시간이 걸린다는 것을 사람들에게 알리라고 조언합니다. 관리자가 아니라면 게으른 것 같아요. 당신이 이미 일을하고 더 많은 사람들을 고용 할 수 있다는 것을 그들에게 알려주십시오. 그 일이 한 사람에게는 너무 많다는 것을 알 수있는 다른 방법은 없습니다.

이것은 프로젝트 관리 문제입니다. 어떤 종류의 프로젝트 관리를 사용하여 가장 우선 순위가 높은 것을 결정하십시오.

a) 작업 할 항목의 백 로그가 필요합니다. 코드 개선 계획을 백 로그에 넣습니다.

b) 모든 버그는 백 로그에 들어갑니다

c) 백 로그가 우선 순위를 갖습니다.

d) 우선 순위대로 모두 수행합니다.

버그는 우선 순위가 높을 수 있지만 일단 수정하면 새로운 기능이나 리팩토링 디자인에 소요되는주기가 있습니다.

수정해야 할 문제 / 버그가있는 섹션을 전달할 때 점진적으로 리팩토링 개선을 수행하는 것이 가장 쉽습니다. 그런 다음 경영진에게 "A를 수정해야했지만 B는 근본적으로 고장 났으며 나중에 C가 더 쉬워 지도록 솔루션 C를 수정해야했습니다."A = 버그, B = The 안티 패턴, C = 솔루션, D = 미래 이익

만약 투자 가치가있는 일을 정당화 할 수 없다면, 사업 사람들은 결코 그것을 받아들이지 않을 것입니다.

이것은 평소와 같이 사업입니다. 그곳에서 계속 일하는 한 악용 될 것입니다. 자신이하고있는 일에 대해 행복하게 느끼기보다는이 모델을 계속 사용하는 것이 회사의 최대 관심사입니다. 그것이 올 때, 그들은 실제로 신경 쓰지 않습니다. 그것은 그들을 위해 신뢰할 수있는 코드를 만드는 것에 관한 것이며 당신이 일인 밴드라면 그들은 확실히 당신을 은행으로 만들고 있습니다. 왜 변할까요?

이 모든 것의 좋은 소식은 그들이 모르더라도 VIP입니다. 내가 제안하는 것은 배를 뛰어 넘기 전에 더 많은 기회를 잡은 다음 공을 잡고 더 높은 급여를 요구하는 것입니다. 더 나은 기회로 이동하지 않으면. 제 생각에, 당신은 좀 더 흥미로운 일을 곧 찾아야 할 것입니다. 당신이 할 수있는 한 높게 목표로하십시오. 개발자 샵에 도착하면 Google과 같은 행복을 느끼게되며, 진정한 개발자 행복을 느낄 수있는 공동 개발자 문화가 형성됩니다.

내가 개인적으로 한 일은 헤드 헌터 계약자 조직을 사용하고 내 계약자로부터 꾸준한 고용을 유지하면서 한 벨트에서 다른 벨트로 빠르게 많은 경험을 쌓았습니다. 그것은 당신이 지루 해지는 것을 막고 당신에게 도전합니다. 결국, 여가 시간에 나는 실제 사업에 꽃을 피우는 소규모 사업체를 건설 한 다음 계약 업무를하지 않고 배를 ed습니다.