관리자는 모든 데모 후 요구 사양을 계속 변경합니다.

내 작업 환경의 배경

관리자는 컴퓨터 나 소프트웨어에 대한 배경 지식이나 지식이 없습니다. 그는 자신의 삶에서 어떤 형태 (물리적 거리 10 피트 이하도)를 보지 못했을 가능성이 높습니다.

구현하라는 요청의 복잡성을 이해하는 사람 은 없습니다 . 내가 세미 하드 코딩하면 아무도 알지 못할 정도로.

에 조엘의 테스트 우리는 믿을 수없는 점수 0 점을.

문제

• 관리자와 때때로 다른 "노인"은 요구 사항 사양을 계속 변경합니다. 좋은 엔지니어링을 수행하고 패치가 아닌 "수정"이 아닌 변경은 기본 디자인을 변경해야합니다.
• 없다 절대적으로 아무도 코드를 보이는 아무도 할 수 없습니다 의미 (아마 아무도하거나 완료해야하는 경우에도 방법을 알고하지 않기 때문에)
  • 문제의 복잡성 또는 솔루션의 우아함을 이해하십시오.
  • 접근 방식 개선을 제안하십시오.
  • 코드의 품질을 평가하십시오.
  • 코드를 개선 할 수있는 곳을 지적하십시오.
• 문법적으로 의미가 있지만 다른 방식으로는 의미가없는 많은 전문 용어가 사용됩니다.
• 소프트웨어 회사처럼 느끼거나 행동하거나 일하지 않습니다.

질문

어떻게해야합니까? 특히 내 코드에서 개선점을 지적 할 사람이 없다는 것에 관한 것입니다.

최신 정보

HLGEM (및 다른 사람들)에게 내가 그것을 시도하고 고치기 위해 무엇을했는지에 대한 대답. 나는 Redmine을 설정하고 모든 사람에게 소스 제어를 소개하겠다고 제안했습니다. 나는 분산 (git 또는 mercurial)을 추천 할 것이지만 중앙 집중식에 대해 이야기하고 팀이 결정하도록 할 것이라고 말했다. 응답은 일이 완료되고 몇 주 안에 완료 될 것이라는 것이 었습니다. 그것을 보지 못했고 회사의 다른 부분에서 그것을 사용하는지 알지 못합니다.

짧은 버전 :

운영.

다소 긴 버전 :

경우 관리자가 프로젝트를 실행하는 방법을 알고하지 않으며, 수석가 함께가는 경우에, 당신은 일을 해결없이 기회 옆에 있습니다.

소프트웨어 프로젝트를 관리하려면 관리자가 소프트웨어에 대해 이해해야합니다. 관리자가 그렇지 않은 경우 먼저 배워야합니다. 경영진과 상급자를 설득 할 수있는 기회는 무엇입니까? 그들에게 무언가를 가르 칠 기회는 무엇입니까?

나는 한 번 비슷한 상황에 처해있었습니다 (노인은 없었습니다). 나는 끔찍한 년을 그만두고 결코 뒤돌아 보지 않았습니다 (혐오감을 제외하고).

요구 사양을 계속 변경하십시오. 좋은 엔지니어링을 수행하고 패치가 아닌 "수정"이 아닌 변경은 기본 디자인을 변경해야합니다.

실제 세계처럼 들립니다. 이것은 언제 어디서나 발생합니다. 그렇습니다. 그러나 일종의 민첩한 태도로 견딜 수 있습니다. 또한 소프트웨어의 장점 중 하나는 전성입니다. 도전으로 받아들이십시오.

문법적으로 의미가 있지만 다른 방식으로는 의미가없는 많은 전문 용어가 사용됩니다.

다시, 너무 익숙하지 않은 ;-)

구현하라는 요청의 복잡성을 이해하는 사람은 없습니다.

당신도 아니에요? 당신이 그것을 이해한다면, 그것을 이해하는 사람이 거울에있는 것입니다. 따라서 회사의 복지에 대한 귀하의 책임은 공식 타이틀이 제시하는 것보다 무거울 것입니다. 문제를 이해하고 관리자가 이해하지 못하는 경우 회사에 올바르게 지시 할 수 있도록 경영진에게 명확하게 설명하는 것은 귀하의 책임입니다. 가장 가까운 관리자 가 기술적으로 유능 해야 한다고 가정하는 것이 합리적 일 수 있습니다 (관리자 인 동안 전문가이지만 최소한 약간의 유능한 자임). 당신은 그들을 도울 수 있습니다.

간단한 이스케이프 솔루션은 회사를 전환하는 것입니다. 그러나 다른 옵션으로 Joel 테스트의 항목을 구현하는 것이 좋습니다. 5의 항목은 경영진과 더 많은 협력이 필요하지만 항목 1-4는 다른 사람에게 묻지 않고 설정할 수있는 항목입니다.

즉, 여기 SE의 아무도 당신의 정확한 상황을 알 수 없습니다. 당신이 무능한 멍청이들로 붐비는 회사에있을 가능성이 있으며, 그러한 혼란에서 좋은 것을 만드는 것은 누구에게나 너무 많은 것일 수 있습니다. 상황을 직접 평가해야합니다.

의견 중 하나에서 이것이 첫 번째 직업이라고 말합니다. 관리자는 종종 내 경험에 전념하는 소프트웨어 전문점을 제외하고는 기술적 인 사람이 아닙니다. 이것은 삶의 일부입니다, 그냥 익숙해 지십시오.

솔루션의 우아함을 고맙게 여기는 사람이 없기 때문에 울고 울립니다. 여기서 진정한 문제는 솔루션의 우아함을 평가할 사람이 없다는 것이 아니라 솔루션이 생각만큼 좋지 않다는 것을 가르쳐 줄 사람이 없다는 것입니다. 거의 모든 새로운 프로그래머는 실제 기술을 과대 평가합니다. 멘토가 없으면 더 나은 관행을 도울 사람이 없습니다. 멘토 할 사람이 없으면 로컬 사용자 그룹에 가입하고 적극적으로 참여하여 멘토링 할 사람을 얻습니다. 더 나은 것은 결국 더 나은 직업을 찾는 데 도움이 될 것입니다.

Joel 시험에서 0 점을 받았습니까? 당신이 유일한 코더라면 (그리고 당신이 쓴 것을 들으면서 들리는) 소스 컨트롤을 사용하지 않는 이유는 무엇입니까? 무엇이 당신을 방해하고 있습니까? 당신이 유일한 코더가 아니라면 왜 코드 리뷰를 할 수있는 사람이 없습니까? 우리의 모든 개발자는 코드 검토를 수행합니다. 특히 관리자가 비 기술적 인 경우 관리 기능이 아닙니다.

거의 모든 장소에서 요구 사항이 변경됩니다. 비즈니스 요구는 지속적으로 변화하고 프로그래머가 아닌 사람들은 종종 무언가를 할 때까지 프로그램이 무엇을하는지 시각화 할 수 없습니다. 그런 다음 그것이 필요하지 않다는 것을 깨닫습니다. 그것이 이전의 방법이 그 변화를 잘 처리하지 못했기 때문에 애자일이 실제로 등장한 이유입니다.

경영진이 데이터를 직접 입력하지 않더라도 버그 추적을 설정하십시오. 누군가가 당신에게 언급 한대로 새로운 버그 / 기능을 입력 할 책임이 있습니다. 관리자에게 다른 27 가지 사항이 할당 된 변경 사항을 원할 때 관리자에게 알리는 데 도움이되며 여기에 새로운 변경 사항을 수용하기 위해 우선 순위 목록을 아래로 내리십시오. 구현 한 버그 수정 및 기능의 수를 계산할 수 있으므로 검토 시간에 도움이됩니다. 모두가 그것을 사용하지 않는다면, 적어도 당신은 자신의 일을 할 수 있습니다. 소프트웨어를 설치할 수 없으면 Excel 스프레드 시트를 사용하십시오. 몇 가지 주도권을 가지십시오. 결과를 표시 할 수 있으면 다른 사람들이 더 관심을 갖습니다. 한 사람에게 너무 많은 작업이 있다고 생각되면 버그 추적기가 도움이 될 것입니다.

세련된 데모를 제공하지 마십시오! 데모는 종이에 펜으로 적힌 것처럼 보입니다. 인터페이스가 세련 될수록 비전문가는 인터페이스가 완성되었다고 생각합니다.

예를 들어 모범 사례와 semi_hard 코드를 따르지 않으면 아무도 알지 못하지만 알지 못하고 조잡하고 나쁜 습관에 빠질 것입니다. 그것은 다음 직장에서 당신을 잘 섬길 수 없습니다. 따라서 상황에 따라 가능한 올바른 방법으로 일을하십시오. 테스트를 작성하고 (개발 시간의 일부로 이것을 고려하고, 특별히 추정치의 일부라고 말하지 않더라도 관리에 제공하는 모든 추정치에 시간을 두십시오) 이러한 테스트를 사용하여 확인하십시오 나중에 변경해도 다른 내용은 깨지지 않습니다.

이를 성장하고 개선 할 수있는 귀중한 기회로보아야합니다. 경력의 그 단계에서 많은 사람들이 가지고있는 것보다 실제 코딩에 더 많은 자유가 있습니다. 따라서 성공적인 구현 프로젝트 포트폴리오를 만들 수있는 기회를 고려하십시오. 다음 작업을 찾으러 갈 때, 소스 제어, 제도적 버그 추적, X 번의 성공적인 프로젝트 구현 생성 등과 같은 업적을 지적하면 나머지와 차별화됩니다.

또한 기대치를 상향 조정하는 방법을 배울 수있는 좋은 기회가 있습니다. 이것은 당신의 경력의 나머지 부분에 도움이 될 수있는 능력입니다. 당신은 여기서 이것을하려고 노력할 때 잃을 것이 없습니다. 일들은 이미 좋지 않습니다. 그러나 나중에 더 나은 곳에서 도움이 될 정치 기술을 배울 수 있습니다. 비용-편익 분석을 배우십시오. 대화 할 때 설득력을 가질 수 있도록 비즈니스 영역을 이해하는 법을 배웁니다. 회사의 이익과 이익 측면에서 이야기하는 법을 배우십시오. 배정 된 모든 업무에 대한 추정을 수행하십시오. 경영진이 귀하에게 제공하는 것과 일치하지 않더라도, 귀하가 추정 한 것과 실제로 업무를 추정하는 능력을 향상시키기 위해 실제로 무엇을했는지 기록하십시오. 역사적으로 예측이 관리보다 더 정확했음을 보여줄 수 있다면, 추정치가 너무 낮다고 말하면들을 가능성이 더 높습니다. 그러나보다 정확한 추정치와 가장 중요한 것은 프로젝트를 수행하고 작동시킬 수있는 능력을 먼저 기록해야합니다. 다시 한 번 당신이 경력을 쌓을 때 좋은 기술입니다.

무엇보다도 수동적이지 않으며 위에서부터 개선이 이루어질 것으로 기대합니다.

내가 당신이라면 다른 직업을 찾으려고 노력할 것입니다. 왜? 안타깝게도 관리자가 "좋지 않다"는 것을 알고 있습니다. 그래도 관리자와 몇 가지 작업을 시도해야합니다.

떠나고 싶지 않거나 다른 사람과 대화하지 않으려면 스스로 무언가를 찾아야합니다. 회사 내에서 코드에 대해 아는 사람이없는 경우 관리자가 요구 사항을 충족한다는 것을 어떻게 알 수 있습니까? 그냥 말하면

이에 대해 관리자와 선배에게 문의하십시오. 문제를 설명 하고 해결책을 제안하십시오. 전달하고자하는 일반적인 메시지를 알 수 있도록 대화를 조금 준비하십시오.

대화가 끝나면 잠시 시간을 내십시오 . 상황이 변하는 지 확인하십시오. 그렇지 않은 경우 변경 사항을 직접 구현하고 변경 사항 의 긍정적 인 결과를 관리자와 노인에게 보여 주십시오 .

대화가 도움이되지 않고 변경 사항이 기각되면 해당 장소에서 얼마나 일하고 싶은지 스스로 평가 해야합니다 . 그렇습니다. 일이 나쁠 수도 있지만 급여는 좋으며 출퇴근 시간은 5 분입니까? 직업의 긍정적 인면이 부정적인면을 능가합니까? 나는 그렇지 않다, 나는 새로운 직업을 찾기 시작했다.

문제는 발권 시스템과 버전 관리가 기술적 인 문제이므로 비 기술적 인 관리자의 입력에 관계없이이 작업을 수행해야합니다. 이것은 기술적으로 모범 사례로 가정해야하며 이들이 설정되어 있지 않은 경우이를 실현하기 위해 스스로 취해야합니다.

비 기술적 인 관리자가 결함 추적, 소스 제어 및 지속적인 통합의 이점을 이해할 것으로 기대할 수 없습니다. 이것이 그들이 기술이 아닌 이유이며, 알고 있거나 걱정해서는 안되며, 도메인 및 비즈니스 지식 전문가입니다. 그들이 제공해야 할 유일한 것은 높은 수준의 방향과 요구 사항입니다.

비 기술적 인 관리자도 있는데, 가서 시험을보고 허가를 요청하지 않았기 때문에 Joel Test 점수를 4에서 8로 올릴 수있었습니다.

당신의 그룹은 강력한 기술 리더가 필요하며 아무도 그 판을 밟지 않았습니다.

http://community.rallydev.com/ 을 확인하십시오. Agile 프로젝트 관리 및 결함 추적을 훌륭하게 수행하는 커뮤니티 에디션이 있습니다. 이것만으로 Joel 점수가 올라가고 설정하는 데 서버 공간이나 시간이 전혀 들지 않습니다.

이것이 당신과 다른 "수석"이 기본적으로 유일한 사람들 코딩 인 작은 상점이라면, 실제로 "Joel Test"를 만족시키기 위해해야 ​​할 일을 관리자에게 표시하는 것은 당신의 책임 일 수 있습니다 .

요구 사항의 변화는 항상 존재하며, 귀하의 임무는 민첩한 개발 의 기본 원칙 중 하나 인이를 수용하는 것입니다 .

개발 후반에도 변화하는 요구 사항을 환영합니다. 민첩한 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.

그러나 변화하는 요구 사항에 적응한다는 것은 다른 민첩한 원칙을 따르는 것을 의미합니다. 즉, 관리 수준에서 관리자는 모든 변경 사항에 비용이 발생한다는 점을 관리자에게 투명하게 제시 할 수 있어야합니다. 프로젝트 범위를 마감 기한을 충족하도록 변경하거나 마감 기한을 변경해야합니다 (후자는 권장하지 않음).

이것이 관리자가 모든 요구 사항을 충족시키는 프로젝트 인 경우 민첩한 고객 인 것처럼 행동하고 그들에게 동일한 것을 설명해야합니다 (범위 <-> 마감 기한 ).

그러나 소규모 회사의 개발자 수준에서는 코딩 부분이 민첩한 권장 사항을 준수하도록하는 것이 귀하의 책임이라고 생각합니다.

이들은 당신이 몇 가지 단계가 있습니다 절대적으로 할 필요가 있고, 아마 당신은 그들에게 자신을 수행해야합니다 :

• 버전 관리 시스템 이 있어야합니다 (소규모 팀을 위해 설정하는 데 하루가 소요됨).
• 당신이 있어야합니다 자주 출시 할 수 있도록 빌드 스크립트를 (꽤 빠른 또한 설정하는)
• 자동화 된 단위 테스트 를 사용해야합니다 (이는 코딩 방식이며 전체 디자인을 근본적으로 지시하므로 밀접하게 결합 된 프로젝트의 중간에 추가하기 어려울 수 있음)
• 또한 자동화 된 빌드 및 테스트와 기능 및 GUI 테스트 (쓰기가 조금 더 어렵다)를 보장하기 위해 지속적인 통합 시스템을 설정할 수 있습니다.

자신의 머신에 SVN 저장소를 로컬로 가질 수 있습니다. 간단한 TODO 목록은 가난한 사람의 버그 추적 시스템 역할을 할 수 있습니다. 그리고 빌드 스크립트를 가지고 있지 않다는 변명의 여지가 없습니다.

또한 범위 / 마감일 타협에 대한 진술을하기 전에 특정 기능에 소요되는 시간을 예측해야합니다. 이는 일반적으로 민첩한 세계에서 "이상적인 날"에 이루어집니다. 즉, 각 기능의 상대적인 노력을 예측하기 위해 최선을 다하고 실제 코딩 속도를 사용하여 얼마나 잘 예측했는지 확인하고 그에 따라 "곡선"의 크기를 조정해야합니다. ).

팀에 책임 레이어가 누락 된 것 같습니다. 프로젝트 관리자, 시스템 분석가, 비즈니스 분석가 및 개발자가 있어야합니다. 프로젝트 관리자 역할은 다른 작업 중에서 고객-프로젝트 커뮤니케이션 전략을 정의하고 시행하는 역할을합니다.

관리자는 코드 나 복잡성을 이해하지 않아도됩니다. 이해, 자원, 비용 및 위험.

소스 코드 버전, 코드 품질, 복잡성 등은 PM 책임 또는 선임 개발자입니다.

해결책은 다음과 같습니다.

1- 프로젝트 팀 구조 및 책임 정의

2- 관리 불량으로 인한 소프트웨어 오류 발생시 관리자 교육-기술적 세부 사항을 피하십시오. 인터넷 검색을 통해 몇 가지 예를 찾을 수 있습니다.

특히 내 코드에서 개선점을 지적 할 사람이 없다는 것에 관한 것입니다.

사람들이 코드를보고 있도록 코드 검토를 설정하려고 시도 할 수 없습니까? 코드에 구조를 부여하는 데 도움이되는 규칙과 표준이 있습니까? 이것은 물론 당신이 유일한 개발자는 아니라고 가정합니다.

당신이 좋은 곳보다 적을 지 모르지만 결국에는 효과가있는 것처럼 보입니까? 프로젝트가 완료되고 상황이 진행되고 있습니까? 일이 끝나고 있습니까? 덕트 테이프 프로그래머 는 읽을 수있는 Joel 기사입니다.

옵션 1- '이 프로젝트에 대한 모든 변경 사항을 적용하여 배포 할 때까지 시스템이 매우 느리게 실행됩니다'또는 '고객이이를 파악할 수 없습니다'라고 알려주십시오. 관리자는 스파게티 코드는 신경 쓰지 않지만 고객은 신경 쓰입니다. 코드 작성이 아니라 이해하는 방식으로 문제를 해결하십시오.

옵션 2-원하는 것을 제공하십시오. 그들이 당신이 말하는 것에 대해 불평 할 때 '그러나 그것은 당신이 요구 한 것입니다'