“맞춤형 소프트웨어 회사”는 기술 부채를 어떻게 처리합니까?

"맞춤형 소프트웨어 회사"란 무엇입니까?

"맞춤형 소프트웨어 회사"란 주로 맞춤형 소프트웨어를 만들어 돈을 버는 회사를 의미합니다. 예를 들어 대행사 또는 미들웨어 회사 또는 Redify 와 같은 계약자 / 컨설턴트가 있습니다 .

"맞춤형 소프트웨어 회사"의 반대는 무엇입니까?

위의 비즈니스 모델과 반대되는 것은 배포 가능한 데스크톱 / 모바일 앱이든 SaaS 소프트웨어이든 장기 제품에 중점을 둔 회사입니다.

기술적 부채를 쌓는 확실한 방법 :

SaaS 제품군에 집중하려고하는 회사에서 일하고 있습니다. 그러나 특정 제약 조건으로 인해 때때로 특정 고객의 의지에 구부러지고 해당 고객에게만 사용할 수있는 사용자 지정 소프트웨어의 비트를 작성하게됩니다.

이것은 기술적 부채를 발생시키는 확실한 방법입니다. 이제 핵심 제품에는 아무것도 추가하지 않는 유지 관리 할 소프트웨어가 약간 있습니다.

맞춤 작업이 기술 부채를 창출하는 확실한 방법이라면 대행사는 어떻게 처리합니까?

그렇게 생각하게되었습니다. 비즈니스 모델의 중심으로 핵심 제품이없는 회사는 항상 맞춤형 소프트웨어 작업을 수행하고 있습니다. 기술 부채 개념에 어떻게 대처합니까? 어떻게 기술 파산을 일으키지 않습니까?

사용자 별 요구 사항을 모든 사람에게 유용한 것으로 구부릴 수 있다면 좋습니다. 고객이 기능에 대한 지속적인 지원 비용을 기꺼이 지불하려는 경우에도 좋습니다. 그러나 소규모 팀이고 모든 기능을 지원하는 데 어려움을 겪고 있다면 가장 필요한 기능에 대해 어려운 결정을 한 다음 코드베이스에서 뿌리 내리는 데 시간을 투자하는 것 외에는 아무것도 없습니다.

SaaS는 사용 통계를 수집 할 수있는 좋은 위치에 있습니다. 누가 무엇을 사용하고 있는지 추적 할 수 있도록 기능을 아직 구성하지 않았 으면합니다. 우리의 경험은 가장 관용적 인 고객이 일반적으로 가장 역기능 적이라는 것입니다. 당신이 그에게 MS-Access-export 버튼을 줄 때까지 발을 각인하고 숨을 쉬었던 그 사람은 아마도 1 년 이상 그것을 사용하지 않았을 것입니다. 한 명의 고객 만 사용하더라도 일부 기능은 유지됩니다. 그 고객은 시끄럽고 만족스럽지 않을 때마다 다른 곳으로 비즈니스를 가져가겠다고 위협하기 때문입니다. 이 기능을 중단하면 고객에게 비용이 발생하지만 해당 기능을 지원하는 데 소요되는 시간은 수십 년에 걸쳐 수십 명의 고객에게 비용이들 수 있습니다. 관리 팀의 품질을 측정 한 것입니다.

기능을 중단 할 때는 6 개월에서 3 년 사이에 합리적인시기에 고객 (또는 최소한 영향을받은 사람들)에게 미리 결정을 알리십시오. 실제로 사용자 별 기능을 작성하기로 동의 한 경우 영업 직원이 시작부터 만료 날짜를 작성하도록 할 수 있습니다. 이를 "지원 수명"이라고 부르고 더 오래 원할수록 더 많은 비용이들 것이라는 점을 분명히하십시오. 내 보낸 XML 파일을 MS 액세스 형식으로 변환하는 스크립트 또는 더 나은 RDBMS를 선택하는 것에 대한 약간의 조언과 같이 기능이 진행될 때 고객이 실수하지 않도록 클라이언트에 대한 해결 방법을 제공하십시오.

예방 조치로 우리에게 도움이 된 것은 매월 영업 팀의 보고서를 개발 팀 및 경영진에게 보내는 것입니다. 이 보고서는 클라이언트의 의견-가장 인기있는 기능, 가장 많이 요청 된 기능, 제안 된 기능 중 가장 인기있는 내용을 다룹니다. 이것은 개발자에게는 흥미롭지 만 영업 팀에게는 실질적인 이점이 있습니다. 영업 팀은 이제 더 많은 그림의 맥락에서 각 기능에 대해 조금 더 생각하고 끝없는 기능 요청 스트림을 보내고 우선 순위를 정하는 대신 어느 고객이 가장 시끄러 웠는지 그 결과 각 기능이 제품의 전반적인 가치 제안에서 어느 위치에 적합한 지 더 잘 알고 있기 때문에 협상에서 새로운 기능 요청에 대해서는 영업 직원이 더 많은 비용을 부담하게 만들었습니다.

자동화 된 테스트가 많이 포함 된 모듈 식 코드를 사용하면 제품의 기능을 해킹하고 다시 해킹 할 때 도움이되지만 궁극적으로 이것은 프로그래밍 문제가 아니라 관리 문제입니다. 판매를위한 코드 작성은 바보의 게임입니다.

사용자 정의 개발 요청에 직면하면 요청을 3 개의 더미로 나누는 멋진 필터 를 통해 필터링합니다 .

1. 모두에게 유용하고 구현하기 쉬운 멋진 것들
2. 모두에게 유용하고 구현하기 어려운 멋진 것들
3. 어쨌든 실제로 필요하지 않은이 클라이언트에만 필요한 어리석은 일 중 하나

• 카테고리 1은 현재 개발주기에서 구현됩니다.
• 카테고리 2는 다음 개발주기에서 구현됩니다.
• 카테고리 3은 대부분의 고객이 자신의 요청이 가치가 없다는 것을 깨닫고 1 개월의 개발 시간을 인용합니다.

솔직히 이것은 실패하지 않았으며 카테고리 3 기능을 구현하지 않았다고 생각합니다. 물론 고객 중 누구도 걷지 않았습니다 (판매를 통해 다른 방법으로는 판매하지 않았을 것입니다 :)

(이 경험은 ISV 회사에있었습니다)

특정한 제약 때문에 우리는 때때로 특정 고객의 의지에 구부러지고 그 고객에게만 사용될 수있는 커스텀 소프트웨어의 비트를 끝냅니다.

문제는 하나의 클라이언트에만 사용되는 코드를 만드는 것이 아닙니다. 문제는 한 고객에게만 사용되는 코드를 해당 기능이 필요하지 않은 다른 많은 고객에게 판매하는 제품에 통합한다는 것입니다.

비즈니스 모델의 중심으로 핵심 제품이없는 회사는 항상 맞춤형 소프트웨어 작업을 수행하고 있습니다. 기술 부채 개념에 어떻게 대처합니까? 어떻게 기술 파산에 빠지지 않습니까?

그들은 제품을 제공합니다. 그리고 나서 그들은 움직입니다. 계약중인 제품을 개발할 때 해당 프로젝트에서 수행하는 모든 작업은 해당 클라이언트를위한 것입니다. 개발 중에 발생했을 수있는 기술 부채는 계약 종료 후 고객의 문제가되고 개발자는 다른 고객을 위해 다른 프로젝트로 이동합니다.

그렇다고 엉뚱한 일을하는 것은 괜찮다는 의미는 아닙니다. 귀하의 최우선 목표는 고객이 귀하와 계속 일하기를 원하게하는 것이며, 양질의 업무를 수행하는 것이 그곳에가는 방법입니다. 또한 기술 부채가 계약 개발자에게 문제가되지는 않습니다. 일관되게 깨끗한 코드를 직접 작성하더라도 이미 부채 더미가 발생한 프로젝트에서 일할 때 고용 될 수 있습니다. 그것은 좋을 수 있습니다 (클라이언트는 엉망을 정리하기 위해 돈을 지불하고 싶습니다). ).

나는 사용자 정의 작업이 기술 부채를 발생 시킨다는 전제에 동의하지 않습니다. 기술적 부채를 피한다고해서 특정 종류의 기능을 피한다는 의미는 아닙니다. 이는 불필요한 강성, 종속성 문제 및 코드 기반을 변경하기 어려운 (즉, 비용이 많이 드는) 것을 피하는 것을 의미합니다. 사용자 정의 기능은이 중 어느 것도 의미하지 않습니다. 기능의 좁은 기반을 의미합니다. 따라서 핵심은 구현에서 가능한 한 많은 공통적이고 재사용 가능한 로직을 고려하여 요청하는 고객을 위해 배치 할 수있는 자체 독립형 모듈로 맞춤형 일회성 항목을 남겨 두는 것입니다.

예를 들어 고객이 인트라넷에 설치할 내부 웹 응용 프로그램 인 결과물이 있다고 가정 해 봅시다. 어느 날 고객이 와서 브라우저 인터페이스 대신 "리치 클라이언트"데스크톱 응용 프로그램이있는 버전을 만들 경우 회사에 돈을 가득 채운 덤프 트럭을 운전할 것을 제안합니다. 시스템이 잘 설계되고 종속성이 잘 관리되는 경우 이는 새로운 프리젠 테이션 컴포넌트를 작성하는 동안 도메인, 데이터 액세스 및 서비스 컴포넌트를 재사용하는 것입니다. 1999 년으로 돌아 가기를 원하는 데스크톱 고객이 한 명 뿐이지 만 기술 부채는 고려 대상이 아닙니다.

프로젝트의 상황, 계약 회사의 통제 수준, 계약 회사가 전체 수명주기 동안 사용자 지정 소프트웨어를 관리했는지 여부, 금액에 따라 실제로 달라지는 많은 문제와 같이 대답하기가 다소 복잡한 질문입니다. 코드베이스에 접근 할 수있는 다른 사람들의 "간섭", 관련된 모든 사람들의 태도, 프로젝트의 복잡성 및 사용 된 방법론 ...

모든 시스템에는 어느 정도의 기술 부채가 있습니다. 항상 깨끗한 코드 기반을 유지하기 위해 노력하는 개발자의 노력으로 인해 특히 눈에 띄지 않을 수도 있지만 시스템이 완벽하지 않으며 주요 재 설계로 인해 겉보기에는 결백하지만 오래 지속되는 문제가 분명해질 수 있습니다. 그렇다면 계약 회사는 어떻게 이것을 처리합니까?

많은 경우에 그렇지 않습니다. 종종 한 회사에서 소프트웨어를 작성하고 다른 회사에서 소프트웨어를 수정하는 경우가 많으며 계약을 체결 한 각 회사가 마감 기한이 지남에 따라 코드베이스가 실제로 엉망이되어 코드를 깨끗하게 유지하는 시간을 정당화하지는 않습니다 ( 마감일이 누락 될 위험이있는 경우 간혹 테스트를 거칩니다.

다른 경우에는 계약 프로젝트를 잘 관리 할뿐만 아니라 기존 코드베이스를 찾은 것보다 더 나은 상태로 유지할 시간을 찾는 회사를 찾습니다. 이들은 신중한 계획을 세우고 기술 부채의 원천 (보통 새로운 작업에 가장 큰 영향을 미치는 원천)을 파악하고 기술 부채 관리에 기여하는 테스트 사례 및 수정 사항을 제공하고이 모든 것을 프로젝트 일정에 반영하는 전략을 고안합니다. .

사용자 정의 소프트웨어가 중앙 제품을 작성하는 대신 기술적 부채를 보장합니까? 짧은 대답은 '아니오'이지만 적극적으로 다루지 않으면 기술 부채가 발생할 가능성이 높습니다. 이것은 다른 소프트웨어 프로젝트와 동일합니다. 전체 수명주기 동안 프로젝트를 완전히 제어하면 기술 부채를 처리 할 수있는 더 좋은 기회가 있습니다. 그렇지 않은 경우 이전 회사가 남긴 코드에서 발생했을 수있는 기술 부채를 처리해야합니다.

반면, 비즈니스 모델에 관계없이 소프트웨어 작성이 기술 부채를 보장하는지 묻는 질문이있는 경우. 대답은 절대적입니다. 실제 문제는 어떤 회사가 기술 부채를 어떻게 처리 하는가입니다. 가능한 빨리 기술 부채에 대해 상환하기 위해 예정된 시간에 발생하고 처리하도록하거나 지속적인 코드 기반을 관리하도록 하시겠습니까? 그 대답은 회사의 개별 우선 순위와 발생한 기술적 부채가 재정적으로 적절한 지 여부에 달려 있습니다.

커스텀 소프트웨어는 기술 부채를 보장하지는 않지만 두 명의 마스터를 지원합니다.

맞춤형 소프트웨어 회사는 당면한 작업에 정확히 맞는 소프트웨어를 제작하여 제공하고 필요한 경우 유지 관리합니다. 진정한 맞춤형 소프트웨어는 종종 새로운 기능을 추가 할 필요가 없습니다.

이 질문에 설명 된 문제는 제품 회사가 다른 일반 제품에 사용자 지정 기능을 구축 할 때입니다. 제품이 전체적으로 사용자 정의 된 경우 한 고객의 요구 사항이 변경된 경우에만 제품이 이동합니다. 제품이 완전히 일반적인 제품인 경우 새로운 기능을 추가하여보다 매력적인 제품을 만들 때만 움직입니다. 그러나 다른 일반 제품에 사용자 정의 기능이 있으면 서로 다른 속도로 움직이는 두 개의 코드 청크가 밀접하게 접촉합니다. 지진을 유발하는 지각판과 마찬가지로 이러한 코드 청크 사이의 인터페이스는 "핫스팟"이며 문제가 생겼습니다.