일정 압력을 이해할 수 있습니다. 사용자는 회사의 생명력이므로 사용자를 기쁘게하고 싶습니다. 그러나 특정 변경 사항으로 인해 모든 것이 더 쉬워 질 것입니다. 불행히도, 우리 조직의 경영진은 그러한 변화에 대한 본능적 인 저항을 가지고 있으며,이 저항은 너무 강해서 장기적인 개선을 방해하고 있습니다.

예를 들어, Apple은 최근 iOS 프로그램에 대한 자동 참조 계산을 도입했습니다. 이것은 이전에 사용해야했던 수동 유지 / 릴리스 호출에 비해 크게 개선 된 것입니다. 코드를 작성하고 유지 관리하기가 더 쉽습니다. 전환 자체가 충돌을 일으킬 수 있습니다. 그러나 일단 문제가 해결되면 임의의 이상한 충돌이 발생할 수 있습니다.

최근에 상사에게 자동 참조 카운트로 전환하고 싶다고 언급했습니다. 그의 반응은 눈에 띄는 개선에 집중하고 싶었다는 것입니다. 이 반응은 그가 그에게서 나아가고있는 압력에 의해 주도되었을 가능성이 있으며 아마도 CEO의 말일 수도 있습니다.

비슷한 예가 많이 있습니다. 공통점은 무언가를 고쳐야하지만 수정의 단기 비용이 단기 이익보다 중요하다는 점입니다. 여기서 "단기"는 "다음 몇 주 안에"로 정의됩니다.

상황을 어떻게 처리해야합니까?

편집 : 답변 주셔서 감사합니다. 계속 오세요 내 상황과 관련이 있기 때문에 관리자와 CEO가 모두 프로그래머라는 것을 분명히해야합니다. 그러나 CEO는 이제 이것이 무엇인지 잊었을 수 있습니다. 분명히 그들의 프로그래머 측은 다른 압력에 압도되었습니다.

당신은 정말 기술 부채 에 대해 이야기하고 있습니다. 은유가 관리자에게 도움이 될 수 있습니다. 나는 종종 소프트웨어의 기술적 부채가 더러운 부엌에서 요리하는 것과 비교된다. 싱크대와 카운터 및 스토브에 더러운 접시가 쌓여 있고 바닥에 쓰레기가 있으면 식사 시간이 더 오래 걸립니다. 그러나 다음 식사를 준비하는 가장 빠른 방법은 혼란을 해결하는 것입니다. 부엌을 청소하고 깨끗하게 유지하면 다음 식사가 늦어 지지만 이후의 모든 식사 배달이 개선됩니다. 그리고 식당의 배고픈 사람이 지저분한 부엌을 볼 수없고 요리를 시작하기 전에 왜 정리해야하는지 이해하지 못하는 것처럼, 경영진은 코드에서 혼란을 볼 수 없습니다. 당신은 그들에게 엉망을 보여 주거나 엉망으로 인한 품질 문제와 지연을 보여 주어야합니다.

아마도 긴급한 작업과 중요한 작업에 대해 이야기 할 수도 있습니다. 중요한 작업을 수행하지 않으면 긴급 작업에 시간이 오래 걸리고 비용이 더 많이 듭니다.

프로그래머 는 경력의 어느 시점 에서나 어느 곳에서나 프로그래머를 괴롭히는 무언가를 우연히 발견 했습니다.이 코드는 리팩터링해야하고, 아키텍처상의 문제가 있으며,이 모듈은 유지 보수가 불가능합니다. 그러나 현재 조직의 문화 때문에, 직접 눈에 띄는 혜택 만 제공하는 업무에 집중하도록 압박을 받고 있습니다 .

고전적인 빙산의 비밀 이 다시 한번 있습니다. 비밀은 빙산이 수중 90 % 인 것처럼 모든 개발 프로젝트 의 대부분과 마찬가지로 사실 : 작업의 90 %가 최종 사용자에게 완전히 보이지 않을 것입니다. 이 코드는 최종 사용자 에게 영향 을 미치지 만 관리자는 차이를 볼 수없고 모든 것이 제대로 작동 할 때 유지 보수 / 릴리스 및 자동 참조 호출을 리팩토링하는 데 6 시간을 소비 한 이유를 염두에 두지 않습니다.

이 문제와 관련하여 취할 수있는 사실은 다음과 같습니다.

• 프로그래머가 아니라면 경영진 은 빙산의 비밀을 이해하지 못할 것입니다.
• 이것은 악의가 아니라 악의의 문제입니다. CEO는 좋은 제품을 원합니다. 그는 좋은 제품에 들어가는 모든 것을 이해하지 못합니다.
• CEO (및 귀하의 직속 상사)는 어리석지 않습니다. 왜 이것과 다른 빙산 문제에 시간을 투자해야하는지에 대한 사실과 구체적인 데이터를 연구하고 준비 하십시오.

잊지 마십시오-당신은 회사 남자 또는 여자입니다. 코드 맨이 아닙니다 . 성공 또는 실패에 관심이있는 회사를 위해이 제품을 개발 중입니다. 프로젝트 및 프로젝트 제안서에이를 반영해야합니다. 회사와 제품에 대한 귀하의 열정을 보여주고, 귀하의 지식을 보여주고, 상사와 CEO에게 그들이 당신에게 와서 무언가를 필요로한다고 믿어야한다는 것을 증명하십시오. 제품에 가치를 더하거나 (사본을 구매하는 사람들이 많을 때) 시간을 절약하거나 (제품이 고장 났을 때 화난 고객을 줄임), 이것이 어떻게 수익에 기여하는지 보여줍니다.

당신은하지 않습니다.

나는이 질문과 모든 질문을 약간의 막 다른 골목으로 본다. 사람들에게 어떤 것도 "설득"할 수 없습니다. 그들이 이미 이와 같은 것을 알지 못하거나 조사하고 있다면, 뒤집지 않을 가능성이 있습니다. 그리고 많은 양의 데이터가 그렇지 않으면 설득 할 수 없습니다. 변화는 내면에서 와야합니다. 말을 물로 인도 할 수는 있지만 마실 수는 없습니다.

다음 기술 견적에 원하는 변경 사항을 적용합니다. 애플이 소개 한이 새로운 프레임 워크로 업그레이드해야한다. 로드맵에 ARC를 사용하지 마십시오. 옵션이 없습니다. ARC로 마이그레이션하는 것이 유일한 방법입니다.

전에 비슷한 질문에 답변 했으므로 중복으로 간주 될 수 있습니다. 기본적으로 "리팩토링 노력"을하기 위해 사인 오프를하지는 않을 것입니다. 코드를 깔끔하게 만드는 방법은 보이 스카우트 규칙을 따르는 것입니다.

실제 부채를 갚는 것처럼 극복 할 수없는 일처럼 보일 수도 있습니다 (또는 지저분한 집을 청소하는 것). 속임수는 "청결한 섬"을보기 시작할 때까지 하나씩 더 잘 만드는 것입니다. 중요한 추진력이 있으면 팀의 다른 개발자가이를 알아 채고 결국 작업에 기여하기 시작합니다.

"Uncle"Bob Martin 의 Clean Coder 를 읽는 것이 좋습니다 . 좋은 코드를 작성하는 것은 직업의 일부입니다. 당신은 당신의 일을 할 수있는 권한을 요구하지 않고 그냥 할 수 있습니다.

이러한 성격의 다른 질문과 마찬가지로 경영진이 이해할 수있는 숫자를 제공해야합니다. 이러한 개선 사항을 구현하여 얼마나 많은 시간을 절약 할 수 있는지, "무작위 이상한 충돌"이 얼마나 적게 발생하는지 등을 나타내는 숫자. 충돌이 최종 사용자에게 표시되고이를 방지하기 위해 수행 된 모든 것이 비즈니스에 도움이된다는 것을 확신시킵니다.

또한 이러한 개선 사항을 본인의 시간 (예 : 근무 시간 외)에 구현 한 후 나중에 관리에 대한 이점을 보여줄 수 있습니다. 나는 경영진이 당신이 무엇을 전달하려고하는지 이해하지 못하거나 당신이 그것을 시도하기 위해 시간을 할당하고 싶지 않다는 것이 분명 할 때만 이것을 할 것입니다.

행운을 빕니다!

비즈니스 사례 제시

엔지니어 권장 사항이 종종 무시되는 데는 여러 가지 이유가 있습니다. 거의 모든 이유를 처리하는 가장 좋은 방법은 왜해야하는지에 대한 비즈니스 사례입니다. 고전적인 비용 / 이익 분석. 이것은 설득력있는 주장을 할뿐만 아니라 상사들에게 상류층에게 가져갈 무언가를줍니다.

• 초기 비용은 얼마입니까?
• 지속적인 비용은 얼마입니까?
• 예상되는 돈 / 시간 절약은 무엇이며 어디에서 오는가?
• ROI를 확인하는 데 시간이 얼마나 걸립니까?

비즈니스 사례를 수행 할 때는 항상 데이터를 사용하여 인수를 백업해야합니다.

• 개발이 현재 해결하거나 완화 할 문제를 처리하는 데 시간이 얼마나 걸립니까?
• 이 문제가 제거되거나 완화 될 문제와 관련하여 몇 건의 사용자 불만이 발생합니까?
• 다른 이점은 무엇입니까?

숫자를 정렬하고 거칠지 만 간단한 방정식으로 만듭니다. X를해야하고 회사 Y에게 이익이 될 것입니다.

참고 : 학문적으로 좋은 아이디어를 구현하는 것이 엄청나게 비싸더라도 놀라지 마십시오.

이런 종류의 변경은 리팩토링 범주에 속합니다. 민첩한 접근 방식은 AMPLE 리팩토링 시간을 추정 한 각 스토리에 통합해야한다는 것입니다. 이것이 바로 그 이유입니다. 엔지니어를 제외하고는 아무도 왜 이런 일을하고 싶어하는지 이해하지 못할 것입니다. 올바르게 코딩하는 방법을 결정하는 것은 자신의 일이 아닙니다.

따라서 다음에해야 할 일이 많을 때 이러한 변경 사항이 그 일부인지 확인하십시오. 추정치를 제공하는 경우 리팩토링에 대한 추정치에 30 %를 추가해야합니다. 추정치를 제공하지 않는 경우 작업의 일부로 리팩토링을 수행하십시오.

그것은 당신을 더 느리게 만들 수 있습니다-글쎄요, 그것은 그것을 보는 방법이 아닙니다. 그것을 보는 방법은 현재 속도가 환상이며 본질적으로 당신이 사슬을 지나가는 거짓말이라는 것입니다. 이 작업으로 인해 수행 속도가 느려집니다.

콘크리트를 기초로 사용하지 않았을 때 더 빨리 집을 지을 수 있으며 고객에게는 좋아 보이지만 고객이 기초의 필요성을 보지 못하더라도 빌더 할 필요가있다. (이것은 실제로 흥미로운 평행선이다. 건축업자가 항상 자신이 알아야 할 일을하는 것은 아니기 때문에 강제로 법을 통과시켜야한다. 소프트웨어 개발을 관장하는 법은 없다. 결정하고 종종 잘못 결정합니다 ...)

관리자와 CEO가 모두 프로그래머가 될만큼 운이 좋다고 언급했습니다. 그래서 그들은 아마 않는 기술 부채가 무엇인지 이해합니다.

사실을 기반으로 상황을 해결하려고 시도하여 상황을 처리해야합니다. 즉, 원하는 기술적 개선이 이루어 지지 않을 가능성이 있습니다 (사실은 그러한 방식으로 성 가실 수 있습니다).

귀하의 직무는 발생하는 특정 기술 부채 상환의 비용과 이점을 이해하도록하는 것입니다. 그들의 업무는 자원을 가장 잘 사용하는 것이 자원을 지불하거나 다른 일을하는 것인지를 결정하는 것입니다.

코드와 관련이없는 사람들이 "숨겨진"기능을 향상시키는 이점을보기가 어려울 수있는 것처럼, 프로그래머가 비즈니스 영역에 어느 정도 혜택이 발생할 때 코드 변경이 눈에 띄는 이점을 보는 것은 어려울 수 있습니다. 개발자에게 숨겨져 있습니다.

가시적 인 기능이 기술 부채를 지불하는 것보다 시간이 더 가치있는 이유를 경영진이 설명 할 수 있다면 좋지만 실제로는 결정을 내리는 것이 당신의 일이 아닙니다. 그래서 당신에게 그것을 설명하는 것은 당신을 행복하게하는 것을 제외하고는 사업에 큰 도움이되지 않습니다. 그리고 어떤 방식으로, 그들이 주장한다고해서 그들이 일을한다고 믿지 않는 것입니다. 그들이 당신을 미세 관리 할 때 그것을 좋아하지 않으면 이해해야합니다.

따라서 모든 기술 부채의 상태와이를 무시하고 지불하는 것의 비용 및 이점을 알고있는 한, 작업을 완료 한 것입니다. 경영진이 자신의 업무를 수행하는 것을 정말로 신뢰 하지 않는 한 , 해결해야 할 다른 질문이 훨씬 더 큰 문제가 있습니다.

어쩌면 이것은 대답이 아니지만 내가 한 실수를 기반으로 한 응답 일 수 있습니다. 또한 내가 여기서 읽은 몇 가지 철학에 대한 의견 불일치.

• 프로그래머가 가장 잘 알고 있다는 신념을 두려워하지 마십시오.
• 솔직 해지십시오. 진행하면서 리팩토링하지만 자신의 목적에 맞게 견적을 작성하지 마십시오.
• 코드를 소유하지 않았습니다. 책임자가 승인하지 않은 작업을 수행하지 마십시오.
• 당신은 무언가에 대해 옳을 수 있습니다. 당신은 틀렸을 수도 있지만 ... 지불 한 일을해야합니다.

그러나 개선에 대한 훌륭한 조언을 따르십시오.

당신은 분명히 뾰족한 머리 보스 (PHB)를 위해 일합니다. 그는 더 이상 프로그래밍하지 않으며, 만약 그렇게했다면 아마 실제로는 좋지 않았을 것입니다. (하지만 그는 "const correctness"와 "segmentation fault"와 같은 문구를 사용하여 자신의 줄무늬를 얻었습니다. )-이것이 경영진을 위해 선정 된 방법입니다.

PHB가 기능을 제공하기 때문에 CEO (실제로 Mohawk을 보유한)는 PHB를 좋아합니다 . 모든 스프린트는 자랑스럽게 새로운 눈금 상자 (모호한 레이블로 약간 잘못 정렬 됨), 스파클링 아이콘 (아직 어떤 환경에서도 작동하지 않지만 Citrix에서는 8 비트 색상) 및 형식 (경쟁 조건으로 인해 무작위 충돌이 있음)을 자랑스럽게 보여줍니다. 맞춤형 xml 변형 기반 C에서 10 년 전의 기존 가드 개발 전설 중 하나에 의해 쓰여졌 기 때문에 개발 팀의 어느 누구도 감히 감히하지 않는 로컬 데이터베이스를 구현했으며 5 자의 문자가 필요한지 여부에 관계없이 5 개의 문자 이름을 가진 매크로로 모든 것을 수행합니다. 아니).

실제로 "작업 비트"를 수행하는 프로그래머 (화이트 보드에 원 그리기, 소리 치기 및 미니어처 Battenburgs 섭취와 같은 모든 실제 작업이 불편하게 발생하는 비트를 알고 있음)는 정상적인 시스템에서 방금 수행 한 작업을 알고 있습니다. 유지 관리되지 않은 정글에서 10 일 동안 열성적으로 해킹을했을 경우 테스트를 포함하여 1 일 또는 2 일 정도 소요될 것입니다. 그러나 제정신 이 있는 곳에서 시스템을 얻는 데는 명백한 외부 보상이 거의없는 상태에서 6 개월 동안 진정으로 열심히 일할 수 있습니다.

PHB는 6 개월 만에 후크 또는 사기꾼 으로 영업 사원 (실제로 판매하는 제품을 제공하는 마술사 여야 함)이 새로운 구매 및 업그레이드를 유혹하는 데 사용할 수있는 응용 프로그램에 30 개 또는 40 개의 새로운 기능 을 제공 할 수 있음을 알고 있습니다. .

그러나 PHB에게 회비를 지불하기 위해 : 진드기 상자와 양식이 없으면 판매가 정체되거나 감소 할 수 있으며 경쟁 업체는 시장 점유율을 확보 할 수 있으며 이는 대안보다 나쁠 수 있습니다.

내가 결론을 내린 것은 소란을 피할 수있는 유일한 방법은 소프트웨어를 어떻게 수행해야하는지에 대한 당신의 비전을 공유하고 그 철학에 견딜 수있는 몇 명의 사람들과 함께 새로운 스타트 업에서 일하는 것입니다. 여전히 거기에 도착하고 있습니다!)

다른 답변에는 언급되지 않은 또 다른 숨겨진 비용이 있습니다. 즉, 우수한 엔지니어는 설명 된 환경 유형을 떠나는 경향이 있습니다. 결국 야심이나 리팩토링 능력을 가진 사람은 회사를 떠났고, 상황은 매우 나쁠 수 있으며 아마도 고칠 수 없을 것입니다. 불행히도 당신은 오만 ( "나는 당신의 최고의 프로그래머 중 하나입니다"), 그리고 멍청한 멍청이 ( "내가 원하는 것을하지 않으면 떠날 것입니다")없이 관리자에게 이것을 말할 수 없습니다. 그러나 재취업 상태가되지 않도록 출구 인터뷰에서 언급해야합니다.

당신은 옳고 그름 둘 다입니다. 그것이 바로 이러한 문제가 오랫동안 지속되어 어려운 감정을 일으키는 이유입니다.

이유가 위에서 명확하게 언급 된 이유 : 경영진은 돈으로 생각합니다. 또는 더 구체적으로 : 수익. 그들에게 비용이 있지만 고객에게 직접 가시성이없는 무언가는 수익을 추가하지 않으므로 나쁜 계획입니다.

당신의 비전도 옳습니다. 고객에게는 좋지만 장기적으로는 좋습니다. 단기 계획에 비해 향후 귀하의 활동으로 인해 더 많은 수익이 발생할 수 있습니다.

당신은 관리자가 아니며, 수익을 직접 책임지는 사람이 아닙니다 (물론 가정합니다). 따라서 당신은 (관리에 대한 느낌) 문제와 문제를 섞고 있으며 작업에 집중하고 있지 않습니다. 소프트웨어를 더욱 확장하십시오.

단단하고 명확한 단어이지만 통신 오류로 인해 대부분의 문제가 발생합니다. 둘 다 같은 것을 원하지만 단기 결정은 다르게 이루어집니다. 개발자와 관리자의 관점이 다르기 때문입니다.

이 문제를 어떻게 해결합니까? 여러 가지 문제에 대해 서로 의사 소통하고 이해합니다. 그것은 고객 참여와 만족에 가장 초점이 될 것입니다.

안정적이고 미래에 증명할 수있는 방법으로이 문제를 해결하려면 오래된 코드에서 버그 수정 비용을 측정하십시오. 이전 소프트웨어를 사용하는 데 추가로 걸리는 시간과 새 코드베이스를 사용하는 방법을 측정하십시오.

이를 증명하기 위해 예를 들어 다음과 같은 매우 간단한 작업을 수행 할 수 있습니다. 버전 관리에서 소프트웨어를 분기합니다. 먼저 경영진이 원하는 것을 수행하므로 해당 기능을 작성하십시오. 이 작업을 수행하지만 계약에 따라 다른 방식으로 보여줄 시간이 있습니다. 그런 다음 새 브랜치에서 동일한 작업을 수행하지만 먼저 제거하려는 문제를 해결하십시오. 그런 다음 솔루션을 개발하십시오.

이제 동일한 솔루션이 있지만 완전히 다르게 개발되었습니다. 그로부터 사례를 만들고 안정성, 필요한 코드 양 및 코드 자체와 같은 일부 관리 정보를 포함하여 솔루션을 나란히 배치하십시오.

이제 커피를한데 모아서 누가 옳은지 토론하지 말고 회사의 두 방향의 영향에 대해 토론하십시오. 그렇게하면 정말 유용하고 더 나쁘게 논의되지 않는 회의가 만들어 지므로 둘 다 필요한 분위기를 만들지 않기 때문입니다. 그것은 당신의 제품을 더 좋게 만들지 않을 것입니다.

코드 검토가있는 경우 ARC를 사용하여 코드를 개선해야한다는 기술 티켓을 작성하고 관리자에게 지정하십시오.

그를 설득하십시오. 그와 비슷한 기술 향상 및 프로젝트에 대한 이점에 대한 몇 가지 작은 예를 설명하십시오.

경영진이 기꺼이 구매하려는 유일한 방식으로 이러한 변경 사항을 판매해야합니다.

관리 기능을 갖추어야 만하는 사용자를위한 기능을 찾으십시오. 그러나 코드에서 약간의 개선 없이는 불가능합니다.

고객이 부가 가치로 인식하는 것을 제공하는 데 회사가 개발에 집중하도록하는 것은 상사의 일입니다. 이 인식을 바꿀 수있는 두 가지 요소가 있습니다.

1. 클라이언트 요청을 전달하는 데 얼마나 걸립니까?
2. 당신이 할 것이라고 말하면 전달합니까?

대부분의 경우 3 주에 배달하지만 4 번에 배달하는 것보다 6 주가 걸리고 5 번에 배달한다고합니다.

관리 및 향상이 쉬운 최신 코드 기반을 사용하면 더 빠르게 제공하고 예측 가능성을 높일 수 있습니다. 버그 수정에 너무 많은 시간을 할애한다면 새로운 기능을 추가 할 수있는 리소스가 줄어 듭니다. 코드 수정에 소요되는 리소스 양과 기능이 얼마나 정확한지 평가하십시오. 이 방법은 현재 상사의 철학에 따라 현재 코드 비용이 너무 많이 드는지 확인하는 방법입니다.

관리 관성으로 인해 우리의 손을 거의 미끄러 뜨릴 수있는 20 억 달러의 기회에 대해 말씀 드리겠습니다.

우리 중 일부는 고객의 목소리에 귀를 기울이며 원하는 것을 이해한다는 의미가 있습니다. 항상 그가 요구하는 것은 아니지만, 고객과 대화를 나눌 수있는 위치에 있다면 결국 원하는 것을 상호 이해하게됩니다. 그런 다음 명시 적으로 요청을 시작할 수 있습니다.

즉, 고객과 대화를 나눌 사람을 이해하는 것이 중요합니다. 일반적으로 비즈니스 개발 담당자와 일부 주요 디자이너가이 작업을 수행합니다. 경쟁이있는 경우 고객이이 대화를하고 있다고 예상 할 수 있습니다.

동시에 개발자가 자신의 분야에서 최신 상태를 유지하는 것이 중요합니다.

우리의 상황에서는 기존 고객과 기존 기술을 기반으로하는 다소 효과적인 제품이 있었으며 고객은 빠른 업그레이드가 필요했습니다. 그들이 실제로 필요한 것은 완전한 교체 제품 이었지만 회사의 사고 방식은 우리를 즉시 경쟁력있는 위치로 만들 수 있었으며 기존 제품을 수정하면 고객이 법적으로 경쟁력을 갖출 필요없이 계속해서 우리와 함께 할 수 있다는 것이 었습니다. 우리 경영진은 그들이이 시장을 소유하고 있다고 생각했습니다. 문제는 기존 제품 구조가 업그레이드하기에 충분히 유연하지 않았기 때문에 업그레이드 요청을 처리 할 수 ​​없다는 것이 었습니다.

고객이 참을성이 없어 경쟁 소스와 대화를 시작했습니다. 우리는 그 시장에 대한 "소유권"과 2 십억 달러의 수익을 잃었습니다. 그러나 일단 시장이 우리를 경쟁력있는 위치에 놓으면 경영진은 사업을 중단하거나 경쟁 할 수밖에 없었다. (로드 블록이었던 대부분의 사람들은 결국 해고당했습니다.) 우리는 경쟁하고 가장 얇은 실로 사업을 다시 잡을 수있었습니다.

나는 처음에이 기회가 우리의 손을 거의 미끄러 뜨렸다 고 말했다. 내가 언급 한 수익으로 사업을 되찾았습니다. 처음에 고객의 관심사에 더 잘 적응할 수 있었다면 실제 경쟁은 없었을 것입니다.

내가 제공하는 테이크 아웃은 다음과 같습니다. 항상 개인 능력에서 최첨단을 유지하십시오. 항상 유연하고 고객의 요구에 빠르게 적응할 수있는 제품을 개발하십시오. 이렇게 생각하지 않는 회사를 위해 너무 오래 일하면 시들고 개인적인 동기가 약해집니다. 나는 그것이 일어나는 것을 보았다.

어떤 이유에서든 제품을 개선 할 아이디어가 있으면 다음과 같은 질문을 해보십시오.-이것이 고객이 원하는 것입니까? 고객의 의견에 따라 제품 개발에 대한 내 생각을 확인할 수 있습니까? 우리 회사는 고객의 요구를 해결할 수있는 위치에 있습니까? 그렇다면 어떻게? -제품 개발 제안과 관련하여 설득력있는 사례를 제시 할 수있는 위치에 있어야합니다.

모든 분야와 산업에서 공통된 비즈니스 언어는 돈입니다. 설명하는 문제는 프로그래밍 문제가 아니라 비즈니스 문제입니다. 사업 제안에 대한 적절한 답변을 얻으려면 사업 언어로 구성해야합니다. 즉, 모든 비용과 혜택을 포함한 대체 프로젝트 계획을 제시 할 수 있어야합니다.

기회 비용, ROI (투자 수익) 및 NPV (순 현재 가치)와 같은 사항에 대해 알아야합니다. 이를 수행하기 위해 MBA가 필요하지 않지만 인력 비용, 간접비 및 수익 가능성과 같이 사용하지 못할 수있는 데이터에 액세스해야합니다. 어려운 숫자를 사용하여 한 경로가 다른 경로보다 더 많은 가치를 제공 할 것이라는 명확한 주장을 할 수 있다면 경영진으로부터 많은 관심을받을 것입니다.

아주 작은 팀의 새로운 개발자 였을 때, 나는 자유 시간에 이런 종류의 많은 개선을했습니다. 나는 그것을 즐겼다. 밤에 아내와 함께 거실에 앉아있는 동안 로그온하고 흥미로운 새로운 기술을 시험해 보았습니다. 상급 개발자이자 더 큰 팀의 관리자가되면서 자유 시간이 사라졌습니다. 우리는 기능과 중요한 수정 작업을 수행하기 위해 추가 시간을 일하고있었습니다. 비록 우리 모두가 그것이 얼마나 중요한지 알지만, 정기적 인 가사 작업에 누군가의 시간을 보내는 것을 정당화하는 것은 정말로 어려워졌습니다.

상사는 유지 보수 비용을 낮추고, 미래 성장 비용을 줄이며, 재능있는 개발 팀을 참여시키는 등의 중요성에 대해 설명 할 필요가 없습니다. 그렇다면 큰 문제가 있습니다. 그러나 그들이 필요한 것은 계획입니다. 지금은 "기능 추가"측면에 대한 모든 종류의 계획, 일정, 로드맵, 약속 및 압력이 있다고 생각하기 때문에 개발자 팀의 단순한 희망과 개방형 요청과 경쟁합니다.

시도 할 수있는 한 가지는 문서화 된 계획을 세우는 것입니다. 릴리스에 연결하거나 새로운 기능에 대한 기준을 종료 할 수 있는지 확인하십시오. "참조 횟수를 다시 계산하는 데 시간을 소비하는"요청은 상사가 승인하기 어려울 수 있지만 4 주 후 5 일 동안의 일정을 예약하는 것이 더 쉬울 수 있습니다. 그러나 기본적으로 새로운 기능이 계획 및 예약되어 있음을 알거나, 그 기능을 모방하거나, "사실상"부분을 주입하려고합니다.

해당 유형의 제품에 5 %의 시간을 할당하여 소규모로 시작한 다음 자신의 기술 로드맵 우선 순위를 점차적으로 구축하고 비즈니스 사례, ROI, 위험 수준 등을 각각 정당화하는 데 계속 의존하십시오. 시간이 지남에 따라 더 많은 훌륭한 아이디어를 빨리 찾을 수 있기 때문에 곧 보스의 도전을 맛볼 수 있습니다.

행운을 빕니다!

자동 참조 계산 요청이 거부 된 이유는 다음과 같습니다.

1. 개선이 아닙니다 . hello world보다 큰 것이 있으면 변경이 잘못된 방향으로 진행됩니다. 리팩토링의 양은 변경이 필요하지 않으면 항상 잘못된 방향으로 가고 있다는 사실을 바꾸지 않습니다. 요점은 변경 사항이 중요한시기를 파악하여 새로운 문제를 일으킬 위험이 여전히 있다는 것을 아는 것입니다. 경영진은 최종 사용자가 그것을 볼 수 없다면 위험할만한 가치가 없다고 분명히 말했습니다.
2. 참조 카운팅은 완전히 미친 기능입니다. 기존의 유명 회사에서 일부 기능을 구현하는 것을 보았고 즉시 동일한 기능이 필요하다고 생각했습니다. 글쎄, 코드베이스가 애플이 사용하는 것과 완전히 다를 가능성이 큽니다. 아마도 참조 카운트가 작동하지 않거나 시간 낭비 일 것입니다. 코드의 어느 곳에 나 참조 카운팅 프리미티브를 확산시킬 필요가없는 다른 방법을 찾아야합니다. 아마도 당신의 리팩토링 계획은 코드베이스에서 수천 번의 수정을 필요로 할 것입니다. 시간과 돈 낭비.
3. 잘못된 문제를 해결하고 있습니다. 경영진은 일반적으로 시스템에 어떤 종류의 문제가 있는지 알고 있습니다. 재 계산 솔루션이 해결하는 관련없는 메모리 누수 문제는 그 중 하나가 아닙니다. 컴퓨터가 메모리를 처리하는 방법에 대한 가상의 문제가 아니라 실제 문제에 중점을 둡니다.
4. 애플 을 구현하는 데 시간이 너무 오래 걸린다. 애플은 프로그래머와 관리자가 적은 사소한 팀보다 약간 큰 회사이다. 그들은 단지 가격을 지불함으로써 큰 ​​변화를 할 수 있습니다. 무언가를 구현하는 데 몇 백만이 걸리면 땅콩입니다. 소기업이 같은 일을하려고하면 돈이 빨리 소진 될 것입니다. 소프트웨어 개발은 ​​이미 매우 비싸다. 불필요한 비용을 추가해도 1 비트는 도움이되지 않습니다. 메모리 관리와 관련이없는 기능 중 하나는 플러드 게이트를 여는 것입니다. 승인 후 프로그래머의 절반은 자신의 "개선"을 구현하기를 원합니다. 끝없는 이야기이며 회사는 대신 유용한 무언가를 할 수 있습니다.

문제를 처리하는 데 사용할 수있는 몇 가지 단계는 다음과 같습니다.

1. 기능을 삭제
2. 실제 문제가 무엇인지 알아보십시오
3. 유용한 일을 시작하십시오
4. 시간을 어떻게 사용하는지 신중하게 계획하십시오
5. 당신의 개선이 돈을 어떻게 가져오고 있는지 알아보십시오
6. 대부분의 돈을 가져 오는 기능 만 선택하십시오
7. 소프트웨어 개발의 프로그래밍 측면은 전체 시스템의 일부에 불과하다는 점을 인식하십시오. 개선 된 기능은 결코 가치가 없습니다.