나쁜 개발자의 징후입니까? [닫은]

나는 비즈니스 모델이 변화한다는 사실을 깨닫지 못하고 코드 썩음에 대한 고객의 사양 변경을 비난했습니다. 나는 이제 그것을 나쁜 개발자의 표시로 본다 (나는 바꿨다!).

그러나 지금 나는 내 자신의 다른 '왜곡'을 본다. 최근 몇 번이나 나는 '둥근 구멍에 사각형 못을 맞추는 것과 같다'고 말하면서 프로젝트가 진행되지 않는 것에 대한 고객의 결정을 비난했습니다.

태도를 바꿔야 할 곳을 찾아야 할 징후가 있습니까? 고객이 항상 옳습니까, 아니면 때때로 좌절감을 느끼는 것이 정당합니까?

나는 당신이 나쁜 개발자라고 말하지 않을 것입니다. 문제를 알고 있으면 이미이 정의를 벗어나게됩니다.

요구 사항 변경. 그것은 주어진 것입니다. 좋은 개발자는 이것을 고려해야합니다. 현대의 많은 프로그래밍 기술이 이에 대처하는 데 도움이됩니다.

원래 사양을 그대로 유지하는 것은 현실적이지 않습니다. 또한 현실적으로 요구 사항이 항상 변화하고 있습니다.

고객이 항상 옳은 것은 아닙니다. 하지만 우리가 원하는 것보다 더 자주 '옳다'(그가 완전히 꺼져 있지 않으면 그를 수용하려고한다). 그러나 그가 잘못된 방향으로 프로젝트를 추진하는 것을 보았을 때, 자신이 옳다고 생각하는 것을 옹호하십시오.

이러한 것들에 대한 엄격한 규칙은 없으며, 숙련되고 숙련 된 개발자조차 완벽한 '젠'을 달성하지 못했습니다. 유일한 잘못된 접근법은 이것들을 개선하려고하지 않습니다.

클라이언트 인 경우가 있습니다. 그러나 그것은 당신의 문제이기도합니다.

개발자 인 경우와 고객 인 경우가 있습니다. 그러나 일반적으로 둘 다 당신의 문제이므로 자신을 비난하는 태도는 더 무력한 경향이 있습니다. 왜냐하면 그것이 손가락을 가리키는 대신 문제 해결 측면에서 잘못되기 때문입니다. 따라서 숙련 된 개발자에게 종종 제공됩니다.

더 나은 태도는 IMHO가 책임없이 그것을 보는 것입니다. "항상 요구 사항을 변경하기 때문에 코드가 까다로운 고객의 잘못입니다."그런 다음 "이 고객은 원하는 것을 파악하고 있으므로 피드백, 빠른 프로토 타입 및 유연성이 더 중요합니다." 완전성, 견고성 및 속도보다 중요합니다. "

선의 마음의 종류 : 판단하지 말고 그대로보십시오.

첫째, 고객은 그들이 볼 때까지 원하는 것을 알지 못합니다. 이는 고객 참여가 많은 Agile 패러다임의 작은 반복에 대한 호소의 일부입니다. 둘째, 코드가 완성 될 때 제품이 "완료"될 것으로 기대하지 마십시오.

Microsoft는 고객에게 직접 문제를 추적하기 위해 'Watson'(창이 터질 때받는 피드백 메시지 보내기)이라는 제품을 사용합니다. 추적 성은 문제가 발생한 사용자에게 문제를 추적하는 좋은 방법입니다. 요청하면 추적 성을 얻을 수 있습니다. 또는 리소스가있는 경우 기능을 제품에 통합하십시오. 핵심은 문제 / 개선을 추적하여 해결 될 수 있도록하는 것입니다.

마지막으로, 고객이 변질 될 수 있는지 확인하십시오. 그러한 경우, 나는 빙산의 비밀 에 집중하려고 노력합니다 .

변화하는 요구 사항은 인생의 힘든 사실입니다. 그러나 코드 썩음은 그로 인한 것이 아닙니다.

코드 부패는 자주 운동하지 않는 코드의 일부가있을 때 발생합니다. 따라서 "다른 것에 영향을 미치지 않아야합니다"라는 변경을 수행하면 버그가 발생할 수 있습니다. 즉, 일광을 보지 못하는 코드는 서서히 분해되어 작동이 중지 된 시점을 말할 수 없습니다.

그렇습니다. 사용자의 잘못이 아니라 귀하의 잘못입니다.

실제 솔루션? 모든 코드를 자주 테스트 하십시오. 물론 가장 좋은 방법은 적용 범위가 좋은 자동 테스트를하는 것입니다.

고객의 결정은 큰 문제가 될 수 있으며 고객 관계를 관리하는 담당자가 아닌 경우 다루기가 매우 어려울 수 있습니다. 고객과 거래하는 사람에게 말을 걸고 고객이 결정을 내릴 때까지 진행이 이루어질 수 없다고 침착하게 설명 할 수 있습니다. 당신이 경우 있는 고객 관계를 담당하고, 당신은 그들이 프로젝트를 계속하기 전에 결정을 내리는 데 필요한 것을 클라이언트에게 있습니다. 당신의 태도가 진정되기 위해서는 정밀한 점검이 필요하지 않을 수도 있습니다. ;)

Javier 는 변화하는 요구 사항이 인생의 어려운 사실이라는 것을 잘 지적합니다. 개발자가 의사 결정을 내려야하는 제품을 개발하는 경우가 너무 많아서 이러한 상황에 너무 좌절합니다. 제 의견은 "고객이 왜 경영진이 고객과이를 알아낼 수 없습니까?"또는 "고객이 원하는 것을 모르면 왜이 프로젝트를 시작 했습니까?" 늦게 개발 ".

간단한 사실 : 이것은 프로그래밍 / 소프트웨어 개발뿐만 아니라 모든 단계에서 항상 발생합니다. 사람들이 결코 마음을 바꾸지 않고, 적응하지 않고, 변화를 해결하지 않으면 세상은 단순히 매우 지루하고 매우 다른 곳이 될 것입니다. 사람들은 자신이받은 것을보고 개선하는 경향이 있습니다. 코드와 동일한 작업을 수행하지 않습니까? 내가 만족하지 않는 코드 블록이 있다면 (비효율적이고 지저분하다), 나는 그것을 향상시킬 것이다. (운영 체제가 나에게 불평합니까? ... 명명되지 않은 특정 OS를 사용하고 있지만 일반적으로 그렇지 않은 경우가 있습니다)

프로그래머로서 우리는 일을 개선 할 수있는 기회를 잡아야하며 우울하거나 짜증나 지 않아야합니다. 사람들과 대화하고, 스타일을 개선하고, 업무 윤리를 개선하고, 열린 마음으로 물건에 접근하고, 어제보다 나아지도록 자신을 밀어 올리십시오. 당신의 경력을 발전시키고 너무 쉽게 정착하지 마십시오.

모든 사람이이 답변에 동의하지는 않지만이 질문에 대한 답변이 더 넓은 관점을 다루는 것이 중요하다고 생각합니다.

클라이언트와 상호 작용할 때는 프로그래밍이 아닙니다. 당신은 배우고 가르치고 있습니다.

고객에게 정보를 제공하고 프로세스에 대해 교육하십시오. 변화가 일어날 것입니다. 그들에게 당신이 그것들을 구현하려고 노력할 것이라고 알려주지 만, 비용이 더 많이 든다. 그들이 결정하게하십시오.

그들이 묻는 질문이 본질적으로 기술적 인 경우에도 기술적 인 세부 사항을 다루지 마십시오. 당신은 약간 방어적인 느낌이 들기 때문에 도전을 받고 / 도전을 받고 싶어합니다. 하지 마라. 그들은 세부 사항에 신경 쓰지 않고 45 초 후에 듣기를 멈출 것입니다.

미리 알려주지 않았다면 업계 표준과 모범 사례 또는 자신이하는 일에 대한 다른 변명에 대해 알 것으로 기대하지 마십시오. 나는 영업 사원에게 업계의 표준이라고 말해 줄 때까지만 수수료를 볼 수 없을 때 싫어. 나는 그것을 알 것으로 기대되어서는 안됩니다. 제 답변은 "저도 바보 같은 느낌을 주나요?"

고객과 함께있을 때는 다른 사람이나 방에있는 것보다 더 많은주의를 기울이십시오. 길 들여진 개는 이것의 천재입니다. 특히 음식이 있다면.

요구 사항 관리가 잘못되었거나 분석이 잘못되었습니다. 비즈니스 분석가 (있는 경우) 또는 요구 사항을 얻는 사람은 고객과 함께 앉아 클라이언트가 생각하지 못하는 요구 사항도 모두 요구해야합니다. 고객은 일반적으로 원하는 모든 것을 알지 못하며 훌륭한 비즈니스 분석가가 모든 것을 파악하도록 도와줍니다.

애플리케이션이 프로토 타이핑 / 연구 단계를 넘어 가기 전에 항상 비즈니스 요구 사항 문서를 설정하고 사인온해야하는 이유가 여기에 있습니다.

이제이 문서가 실제로 최종이라는 아이디어는 잘못되었지만 고객이 실제로 원하는 것을 더 잘 이해하는 데 도움이됩니다. 유지 관리 성을 염두에두고 코드를 작성하는 한 문제를 최소화 할 수 있습니다.

그리고 다시 변명의 여지가 필요한 경우, BRD에 대한 지연, 클라이언트가 사인 온한 것 등의 지연을 비난 할 수 있습니다.

(물론, 이것은 필요할 경우에 대한 변명 일뿐입니다. 항상 무언가를 변경하도록 계획해야 합니다 )

에머슨 (Emerson)의 인용에서, "어리석은 일관성은 작은 마음의 혼잡이다 ..."가장 자주 간과되는 단어는 어리석은 것 입니다. 일관성은 특정 환경에서 협상 할 수 없지만 종종 비판적 사고와 분석을 대체합니다.

한편, 많은 개발 모델은 설명하는 환경을 돕기 위해 특별히 설계되었습니다. 따라서 모델을 위반해야하는 경우, 우선 모델을 제대로 구현하지 않았거나 모델이 잘못되었습니다.

그러나 규칙을 위반하는 데 합리적이고 합리적인 근거가 있고, 불량한 방법으로보다 깔끔한 코드를 생성 할 수 있다는 것을 보여줄 수 있다면 현명한 경로를 취하는 것을 두려워해서는 안됩니다.