프로그래밍 작업에서 누락 된 마감일이 일반적입니까? [닫은]

18

oDesk에서 프리랜서로 일했습니다. 나는 주어진 시간에 몇 가지 일을 일찍했지만 마감일을 놓친 것은 처음이었습니다. 그것은 매우 긴 직업이었고 최선을 다했지만 여전히 마감일을 놓쳤습니다. 지금, 나는 매우 무서워. 마감일을 놓친 것은 내 잘못이기 때문이다.

내 질문은 : 이것은 큰 관심사이거나 프로그래밍 작업에서 흔히 볼 수있는 마감일을 놓친 것이므로 이것에 대해 너무 걱정하지 않아야합니까?

freelancing deadlines

1

환경에 전적으로 의존합니다. 예를 들어, 나의 마지막 직업은 추정치에 따라 고객에게 요금을 청구하는 디지털 대행사였습니다. 마감일을 놓치면 사업에서 돈을 잃었습니다. 현재 진행중인 업무는 매우 역동적이므로 마감일이 전혀 없습니다. 다른 곳에서주의를 기울여야 할 경우 적절한 시간을 주어야합니다. 아마도 귀하의 질문에 이것을 포함시키는 것이 답변에 도움이 될 것입니다.

— Simon Whitehead

가능한 복제 소프트웨어 개발에서 잠재적 지연을 전달하는 가장 효과적인 방법

— gnat

3

놓친 마감일에 공통적으로 모든 작업

— 스티븐 A. 로우

2

누락 된 마감일에 대해 고객과 의사 소통하기를 바랍니다. 마감 기한이 지났지 만 예상치 못한 일이 발생하지 않아야합니다. 마감일 이 다가오는 것을보고 이에 대해 의사 소통 할 수 있어야합니다. 일반적으로 "아직 준비되지 않았습니다."

— Bobson

6

빨리하고, 싸게하고, 잘하십시오 : 2 개를 선택하십시오.

— Reactgular

45

예. 누락 된 마감일은 소프트웨어 개발에서 일반적입니다.

많은 프리랜서들이 기술 부채가 발생하거나 깔개 밑에 먼지를 숨겨 마감 시한을 맞 춥니 다.

의역 프레드릭 브룩스 ' 신화 남자의 달 :

프레드릭 브룩스, The Mythical Man Month의 저자

프로젝트 리더가 토목 공학 작업과 동일한 방식으로 소프트웨어 작업을 계속 평가하기 때문에 마감일이 종종 누락됩니다. 소프트웨어는 명확한 표준이없는 새로운 수공예 산업이기 때문에 결함이 있습니다. 이것은 당신이 실수로 코드를 작성하기 위해 프로그래머의 "허가" 를 취소 할 수 없으며 제목없이 프로그래밍을 위해 누군가를 고소 할 수 없다는 것입니다.
소프트웨어 개발에는 다른 분야에는없는 고유 한 복잡성이 있습니다. 큰 프로그램은 자동차보다 더 많은 구성 요소를 가질 수 있으며 이러한 구성 요소는 더 다양한 방식으로 상호 작용할 수 있습니다.
소프트웨어는 시각화하기 어렵 기 때문에 프로젝트의 다른 측면을보기 위해 다른 종류의 다이어그램이 사용되며 이러한 측면은 직교하지 않을 수 있습니다. 반면에 토목 공학에는 청사진, 배선 등을 모두 동일한 차트 (또는 레이어)에서 직교 방식으로 볼 수있는 청사진이 있습니다.
교량 또는 건물이 반으로 건축 된 후 클라이언트가 프로젝트 범위를 완전히 변경하는 것은 일반적이지 않습니다. 이것은 종종 소프트웨어 프로젝트의 경우입니다.
소프트웨어 개발 분야의 최신 기술은 소프트웨어 프로젝트가 반복 가능하고 거의 위험이없는 시점에 도달하지 못했습니다. Microsoft와 같은 최대 규모의 소프트웨어 회사도 마감일을 몇 달 또는 몇 년 전에 놓칠 수 있습니다.
대부분의 스팀웨어 는 이러한 종류의 문제로 인해 절단 된 소프트웨어 프로젝트 일뿐 입니다.

결론적으로:

소프트웨어 개발 프로세스의 수공예 특성으로 인해 잘못된 추정 및 복잡도의 과소 평가는 미숙 한 분야로 남아 있습니다.

— 툴 린즈 코르도바
소스

11

+ 좋은 대답이지만 기계 및 토목 공학에 약간의 노출이 있었기 때문에 프로그래머가 다리와 다른 것들을 건축하는 방법에 대해 잘 모르는 경우 다리와 다른 것들을 쉽게 비교하는 방법이 재미 있습니다.

— Mike Dunlavey

3

나는 소프트웨어가 계획이라는 아이디어에 동의하고 싶습니다 (엔지니어링 계획의 관점에서-프로젝트의 모든 세부 사항을 설명합니다). 엔지니어링의 경우 물리적 건설 시간이 지배적이므로 계획의 큰 차이가 그 역할을하지 않습니다. 그러나 소프트웨어는 단지 계획으로 만 구성되어 있기 때문에 ... "소프트웨어 개발 분야의 최신 기술은 소프트웨어 프로젝트가 반복 가능하고 거의 위험이없는 시점에 도달하지 못했습니다." 반복적이고 자동화 할 수있는 작업은 여러 번 수행 할 필요는 없지만 한 번만 수행하여 복사 할 수 있습니다.

— Maciej Piechotka

2

@ user61852 : 당신은 나를 오해했습니다. 엔지니어링에 대한 '계획'은 컴퓨터 과학에 대한 '소스'입니다. 즉, 모든 구성 요소에 대한 자세한 설명입니다. 일단 구성 요소를 make갖추면 (입력 하거나 무엇이든) 컴퓨터 과학에서 '계획'이란 무엇입니까? 계획의 혁신. 차이점은 make컴퓨터 공학에서 테스트와 통합을 포함한 소스 코드 작성에 몇 달이 걸리고 엔지니어링에서는 계획에 몇 개월 (구조 계산 포함)이 걸리고 건축에는 몇 년이 걸리므로 계획의 차이는 영향이 적다는 것입니다 후자에.

— Maciej Piechotka

1

@ user61852 : 반복성과 관련하여 컴퓨터가 가장 중요한 것은 자동화입니다. 간단한 블로그를 작성해야한다고 가정하십시오. 정확한 '견적'이있을 때 워드 프레스 (또는 다른 블로깅 시스템)가 설치되어 있으므로 브리지를 사용하지 않아도됩니다. 당신은 여전히 다른 환경을 가지고 있기 때문에 바위가 다르거 나 조류 서식지가 있거나 전망을 파괴 할 수 있으므로 더 조심스럽게 적응해야합니다. 프로그래머는 도구를 만드는 데 더 많은 책임이있을 수 있습니다 (표준 브리지 모델).

— Maciej Piechotka

2

신화적인 남자 달 인용에 대한 보너스; Frederick Brooks는 기술이 아닌 사람들에게 초점을 맞추기 때문에이 세월이 지나도 견뎌냈습니다.

— Michael Shopsin

3

일자리를 계속 얻으려면 누락 된 마감일이 일반적인 관행이되지 않아야합니다.

그렇게 말하면, 일반적으로 상황이 발생하는 경우를 대비하여 추정치에 추가 "흔들리는"방을 남겨두고 싶습니다. 추가 시간에 추가했다는 사실을 밝힐 필요는 없습니다. 부당하게 만들지 마십시오. 아마도 총 시간의 5-10 % 사이입니까? 당신이 알게 될 유일한 방법은 몇 번하는 것입니다.

추정치를 제대로 활용하려면 특정 유형의 위젯을 코딩하는 데 걸리는 시간을 알아야합니다. 예를 들어 클라이언트 X에 대해 무한 스크롤 위젯을 작성해야한다고 가정합니다. 1 주일이 소요되는 경우 버그없이 프로덕션에 배포하기 위해 무한 스크롤 추정치의 기준으로 사용할 수 있습니다.

— TJ 트랩
소스

2

견적을 할 때 항상 20 %의 여유를줍니다. 5-10 %가 너무 적습니다. 나는 그것이 당신이 얼마나 산만 해 졌는지에 달려 있다고 생각합니다. 솔로 개발자는 전혀 산만하지 않을 수도 있습니다

— BЈовић

저는 솔로 개발자이며 일반적으로 프로젝트의 10 % 마진을 얻습니다.

— Konsole

흠 ... Hofstadter's_law

— Philip

1

5-20 %에 비해 100 % 마진이 더 좋다고 생각합니다. 진심으로. 옵션을 훨씬 더 잘 탐색 할 수 있습니다. 그리고 Stack Exchange에 대한 추가 질문에 답변하십시오.

— Acumenus

예, 15 년 경력의 베테랑 프로젝트 관리자가 1.5 년 동안 신인 소프트웨어 엔지니어에게 압력을 가한 후 더 적극적으로 조정하고 프로젝트가 시작될 때 개발자가 느슨해지는 것처럼 행동하는 것은 개발자의 잘못입니다. . 나는 소프트웨어를 전혀 쓸 수없는 관리자 나 PM을 위해 일한 적이 없으며, 일자리를 계속 얻으려면 마감일을 놓친 것이 일반적인 관례가되지 말라고 말하는가? 대부분의 PM이 말 그대로 직무 능력이 없기 때문에 누락 된 마감일은 풍토병입니다 . 저의 최고 관리자는 여전히 소프트웨어 엔지니어가 아니며 자신의 한계를 알고있었습니다.

— 낙관적

3

누락 된 마감일은 소프트웨어 개발에서 드문 일이 아닙니다. 소프트웨어 프로젝트에 소요되는 시간을 정확하게 추정하는 것은 거의 불가능합니다.

전문성은 당신이 그것을 다루는 방법에 표시됩니다. 마감 기한을 놓칠 것임을 알면 가능한 빨리 클라이언트에 알리면 계획을 세울 수 있습니다.

— 필립
소스

2

상당히 흔하지 만 더 잘할 수 있습니다. 스토리 포인트 와 같은 추상적 인 것을 사용하여 추정을보고 실제 추정치를 계산하기 위해 속도 를 추적 할 수 있습니다. 이러한 개념은 가장 일반적으로 스크럼과 관련이 있지만 스크럼을 수행하지 않더라도 사용할 수 있습니다.

속도에 대한 놀라운 점은 개발자가 추정에 어려움을 겪는 중단 및 예기치 않은 복잡성과 같은 모든 무형의 것들을 포함한다는 것입니다. 모든 확률은 시간이 지남에 따라 평균화됩니다. 평균 10 주에 걸쳐 속도 추정치는 약 5 % 내에서 정확했습니다. 그러나 동일한 작업을 몇 시간 만에 예상 할 때 동일한 팀이 지속적으로 30-50 % 정도 과소 평가합니다.

— 칼 빌레펠트
소스

1

저의 이론 (증명되지 않은)은 인간이 복잡한 일을 2-3 개씩 과소 평가하기 위해 진화했다는 것입니다. 의회는 NASA에 다음과 같은 질문을 할 때마다 : 셔틀을 만들거나 달로 이동하는 데 드는 비용은 일주일 안에 몇 주 안에 돌아옵니다. 예상 비용이 모두 소진 된 후 3 배의 비용이 발생한다는 사실을 알게되었습니다.

우리는 1970 년대에 농담을했습니다. 프로그래머 추정값을 두 배로 늘리고 다음 시간 단위로 옮깁니다. 따라서 프로그래머가 2 주 안에 완료 할 수 있다고 말하면 4 개월 후에 완료됩니다.

부엌을 리모델링 한 사람은 일반적으로 '2 주 후에 할게요'라고 생각합니다. 그들은 약 6 주 후에 끝냅니다.

— 메러디스 가난한
소스

1

NASA는 내 질문과 어떤 관련이 있습니까?

1

요컨대, 인간 진화는 당신의 질문과 어떤 관련이 있습니까? NASA는 대규모 프로젝트를 과소 평가하는 훈련되고 경험 많은 사람들의 공개 기록에 명확하게 기록 된 예입니다. 요컨대, 당신의 경험은 '자연적'입니다.

— Meredith Poor

나는 대부분의 사람들의 추정치가 적어도 두 배로 떨어졌지만 다음 시간 단위는 ... 음. 어쨌든 NASA는 이미 수행 방법을 알고있는 작업을 평가하는 데 매우 능숙합니다. 문제는 사람들이 자신이 모르는 것을 알지 못할 때 작업을 평가하는 데 능숙하지 않다는 것입니다. NASA가 진정으로 선구자적인 일을 많이한다는 점에서, 그들이 일을 시작하기 전까지 그들이 무엇을하고 있는지에 대해 잘 모르는 것은 놀라운 일이 아닙니다. 따라서 초기 과소 평가의 이유. 또한 어떤 사람들은 낙관적 인 경향이 있고 어떤 사람들은 비관적 인 경향이 있습니다. 진화가 확실하지 않다.

— 덩크