제품 개발을 위한 아이디어 선택 방법: 공급업체가 들을 수 있어야 합니다…

이 기사에서는 제품의 기능 개발을 위한 아이디어 선택에 대한 경험을 공유하고 기본 개발 벡터를 유지하는 방법을 알려줍니다.

우리는 자동 결제 시스템(ACS) - 청구를 개발 중입니다. 용어
당사 제품의 수명은 14년입니다. 이 기간 동안 시스템은 산업용 평가기의 첫 번째 버전에서 서로를 보완하는 18개의 제품으로 구성된 모듈식 컴플렉스로 ​​발전했습니다. 프로그램 수명의 가장 중요한 측면 중 하나는 지속적인 개발입니다. 그리고 개발에는 아이디어가 필요합니다.

아이디어

소스

5가지 소스가 있습니다.

1. 기업 정보 시스템 개발자의 주요 친구는 클라이언트. 그리고 클라이언트는 의사 결정자, 프로젝트 후원자, 프로세스 소유자 및 실행자, 사내 IT 전문가, 일반 사용자 및 다양한 수준에 관심이 있는 많은 사람들의 집합적 이미지입니다. 고객의 각 대리인이 잠재적으로 아이디어를 제공하는 공급자라는 점은 우리에게 중요합니다. 최악의 경우 시스템 문제에 대한 부정적인 피드백만 받습니다. 기껏해야 고객의 요구 사항에 대한 구조화된 정보를 제공하면서 개선을 위한 아이디어의 지속적인 출처가 되는 고객 측 사람이 있습니다.
2. 우리 판매자 및 계정 관리자 개선을 위한 두 번째로 중요한 아이디어 소스입니다. 그들은 업계 대표들과 활발하게 소통하고 잠재 고객으로부터 청구 기능에 대한 직접적인 요청을 받습니다. 판매자와 계정은 기능의 모든 중요한 변경 사항과 경쟁사의 최신 소프트웨어 업데이트를 인식하고 다양한 솔루션의 장단점을 정당화할 수 있어야 합니다. 일부 청구 기능이 사실상의 표준이 되어 소프트웨어가 완전한 것으로 간주될 수 없는지 가장 먼저 느끼는 것은 우리 직원들입니다.
3. 제품 소유자 우리의 최고 관리자 또는 매우 경험이 풍부한 프로젝트 관리자 중 한 명입니다. 회사의 전략적 목표를 염두에 두고 이에 따라 제품 개발 계획을 조정합니다.
4. 건축가, 선택/사용된 기술 솔루션의 가능성과 한계 및 제품 개발에 미치는 영향을 이해하는 사람.
   개발 및 테스트 팀. 제품 개발에 직접 참여하는 사람들.

히트 분류

편지, 티켓, 구두 요청과 같은 소스에서 원시 데이터를 받습니다. 모두
항소는 다음과 같이 분류됩니다.

• 상담 "어떻게 하죠?", "어떻게 작동하나요?", "왜 작동하지 않나요?", "이해가 안 돼요..."라는 의미로. 이 유형의 통화는 레벨 1 지원 라인으로 이동합니다. 상담을 다른 유형의 항소로 재교육하는 것이 가능합니다.
• 사건 "작동하지 않음" 및 "오류"를 의미합니다. 2 및 3 지원 라인으로 처리됩니다. 신속하게 패치를 수정하고 릴리스해야 하는 경우 지원에서 개발로 직접 이전할 수 있습니다. 변경 요청으로 재분류하여 백로그로 보낼 수 있습니다.
• 변경 및 개발 요청. 지원 라인을 우회하여 제품 백로그에 들어가십시오. 그러나 그들에게는 별도의 처리 절차가 있습니다.

조회수에 대한 통계가 있습니다. 출시 직후 조회수는 짧은 시간 동안 10-15 % 증가합니다. 사용자가 많은 새로운 클라이언트가 우리 클라우드 서비스에 오면 전화가 폭주하기도 합니다. 사람들은 새로운 소프트웨어 기능을 사용하는 방법을 배우고 있으므로 조언이 필요합니다. 작은 클라이언트라도 시스템에서 작업을 시작할 때 한 달에 100시간 이상의 상담을 쉽게 태울 수 있습니다. 따라서 새로운 클라이언트를 연결할 때 항상 초기 상담을 위한 시간을 예약합니다. 종종 우리는 특정 전문가를 뽑기도 합니다. 물론 임대료는 이러한 인건비를 갚지 못하지만 시간이 지남에 따라 상황은 평준화됩니다. 적응기간은 원칙적으로 1개월에서 3개월 정도 소요되며 그 이후에는 상담의 필요성이 현저히 줄어듭니다.

이전에는 자체 작성 솔루션을 사용하여 통화를 저장했습니다. 그러나 점차 Atlassian 제품으로 전환했습니다. 먼저 Agile 작업을 쉽게 하기 위해 개발을 이관한 다음 지원을 이관했습니다. 이제 모든 중요한 프로세스가 Jira SD에 상주하며 다양한 Jira용 플러그인과 Confluence가 함께 제공됩니다. 자체 작성 솔루션은 회사 활동에 중요하지 않은 프로세스에만 남아 있습니다. 우리의 작업은 이제 종단 간이며 한 시스템에서 다른 시스템으로 이동하지 않고도 지원과 개발 간에 이전될 수 있습니다.

이 번들에서 우리는 모든 작업, 계획 및 실제 인건비에 대한 데이터를 얻고 고객을 위한 다양한 청구 옵션을 사용하며 내부 요구 사항에 대한 문서를 생성하고 고객에게 보고서를 작성할 수 있습니다.

변경 요청 처리

일반적으로 이러한 요청은 기능 요구 사항의 형태로 제공됩니다. 당사의 분석가는 요청을 연구하고 사양 및 최상위 TOR를 생성합니다. 이 승인 요청을 제출한 사람에게 사양 및 TOR를 전송합니다. 고객과 동일한 언어를 사용하는지 확인해야 합니다.

우리가 서로를 올바르게 이해했다는 고객의 확인을 받은 분석가는 요청을 제품 백로그에 입력합니다.

제품 기능 관리

백로그에는 수신된 변경 및 개발 요청이 누적됩니다. 5개월에 한 번씩 이사, 유지보수, 개발, 영업 책임자 및 시스템 설계자로 구성된 기술 협의회가 만납니다. 토론 형식에서 협의회는 백로그에서 애플리케이션을 분석하고 우선 순위를 지정하고 다음 릴리스에서 구현하기 위한 XNUMX개의 개발 작업에 동의합니다.

실제로 기술 협의회는 응용 프로그램에 기록된 요구 사항을 고려하여 산업 및 시장의 요구 사항에 응답합니다. 관련성이 거의 없는 모든 것은 백로그에 남아 있으며 개발에 도달하지 않습니다.

변경 요청 및 재정의 분류

개발 비용이 많이 듭니다. 따라서 변경 요청이 직원이 아닌 클라이언트로부터 온 경우 어떤 옵션이 있는지 즉시 알려드립니다.

변경 요청은 다음과 같이 분류됩니다. 산업별 요구 사항 또는 기업의 개별 특성 상당한 양의 새로운 기능 또는 작은 수정. 작은 수정 사항과 개별 요청은 무리 없이 처리됩니다. 개별 요청은 그와 함께하는 프로젝트 작업의 일부로 특정 클라이언트에 대해 계산되고 구현됩니다.

이것이 대규모 산업 요구 사항이 아니고 기능의 양이 많은 경우 주요 기능과 함께 판매될 새로운 별도의 모듈을 개발하기로 결정할 수 있습니다. 고객으로부터 그러한 요청을 받으면 모듈 개발 비용을 충당하고 고객에게 모듈을 무료 또는 부분 지불로 제공하고 모듈을 공개 도메인에 판매할 수 있습니다. 이러한 상황에서 클라이언트는 방법론적 부담의 일부를 담당하고 실제로 모듈의 파일럿 구현을 수행합니다.

이것이 업계에서 막대한 요구 사항인 경우 기본 제품에 새로운 기능을 포함하도록 결정할 수 있습니다. 이 경우 비용은 전적으로 당사가 부담하며 새로운 기능은 현재 버전의 프로그램에 나타납니다.
이전 고객에게는 업데이트가 제공됩니다.

또한 여러 고객이 비슷한 요구를 가지고 있을 수도 있지만 대량 제품을 끌어들이지는 않습니다. 이 경우 이러한 고객에게 사양을 보내고 고객 간에 개발 비용을 분담할 것을 제안할 수 있습니다. 결국 모두가 승리합니다. 고객은 저렴한 비용으로 기능을 구현하고 우리는 제품을 풍부하게 하며 잠시 후 다른 시장 참여자도 사용할 수 있는 기능을 얻을 수 있습니다.

개발자

개발은 매년 5개의 주요 릴리스를 준비합니다. 각 릴리스에서 기술 위원회로부터 받은 XNUMX가지 작업을 구현하는 데 시간이 할당됩니다. 따라서 매출액 뒤에는 제품 개발을 잊지 않습니다.

각 릴리스는 적절한 테스트 및 문서 세트를 거칩니다. 또한 이 릴리스는 해당 고객의 테스트 환경에 설치되며 고객은 모든 것을 세심하게 확인한 후 릴리스가 프로덕션으로 전송됩니다.

릴리스 시스템 외에도 고객이 XNUMX개월 동안 오류로 생활하지 않도록 빠른 버그 수정 형식이 있습니다. 이 중간 형식을 사용하면 첫 번째 우선 순위의 사건에 신속하게 대응하고 명시된 SLA를 이행할 수 있습니다.

위의 모든 내용은 주로 기업 부문과 온프레미스 솔루션에 해당됩니다. SMB 부문에 초점을 맞춘 클라우드 서비스의 경우 고객이 제품 개발에 참여할 수 있는 폭 넓은 기회가 없습니다. SMB의 임대 형식은 이를 제안하지도 않습니다. 기업 측의 명확한 요구 사항 형태의 변경 요청 대신 서비스에 대한 일반적인 피드백과 바람만 있습니다. 우리는 귀를 기울이려고 노력하지만 제품은 방대하고 한 고객이 자신의 오래된 역사적 시스템에서 친숙한 것을 가져오려는 욕구는 시스템 전체의 개발 전략과 모순될 수 있습니다.

출처 : habr.com