고객의 요청을“몇 가지 필드 만 추가 할 수 있습니까?”유형의 요청을 처리하는 방법은 무엇입니까?

매우 일반적으로 한 고객 만 원하는 필드에 대한 기능 요청이 있습니다. 이로 인해 애플리케이션 코드가 복잡해집니다. 필드를 추가 한 후 몇 개월 후에 데이터베이스를 살펴보면 실제로 추가 필드를 사용하지 않는 것을 알 수 있습니다. 또한 매우 오래된 응용 프로그램이므로 단일 필드를 추가하려면 코드를 여러 번 변경하고 보고서를 변경해야하며 필드를 볼 필요가없는 다른 고객에게 영향을 미치지 않도록해야합니다.

• 고객에게 실제로 이러한 기능 요청이 필요한지 어떻게 확인할 수 있습니까?

• "정말 필요하지 않다"고 정중하게 어떻게 말합니까?

현재 특정 기능 요청에 대한 요금을 청구하기 시작했습니다. (이전에는 일반적으로 기능 요청이 무료였습니다) 다른 작업을 수행 할 수 있습니까?

추가 기능에 대한 비용을 지불하고 있습니까? 그렇다면 사용 여부에 관계없이 비즈니스가 아닙니다. 그들이 지불 한 것을 줘. 그러나 그렇지 않은 경우 추가 수입없이 기능을 계속 추가 할 의사가 있는지 결정하는 것은 귀하의 책임입니다.

비슷한 상황이 있습니다. 우리가 처리하는 방식은 신뢰 기반 관계를 구축하여 "이것이 필요 없다"고 말하는 자유를줍니다. 시간과 여유가 필요하며 많은 대화를 나눌 준비가되어 점심과 기타 지루한 작업을해야합니다. 이 지루한 회의는 중요한 기능을 만드는 데 집중할 수있는 장기적으로 비용을 지불합니다.

말하는 것은 또한 그들이 요구하는 것이 실제로 그렇게 중요한지 확인할 수있게합니다.

난 당신이 "정말 필요합니까?"에 들어갈 수 있다고 생각하지 않습니다 고객과의 논쟁. 개인적으로 "귀하의 회사가 더 많은 돈을 벌 수있는 방법은 무엇입니까?"라고 묻고 싶습니다. 그러나 문제의 일부 사실, 어떤 관리자는 어떤 이유로 그것을 추적하고 싶어하고 그들이 길을 찾는 데 사용하고 있습니다. 원치 않는 경우 요청을하지 말라고 너무 많은 돈을 청구하거나 청구하지 마십시오.

애플리케이션이 더 많은 고객 필드를보다 쉽게 ​​처리 할 수있는 방법을 고려하십시오.

1. 고객이 보고서 및 양식의 레이블을 설정하여 기존 필드를 활용할 수 있도록합니다.
2. 기존 또는 추가 사용자 정의 필드 테이블에 일반 필드 (String12)를 추가하십시오.
3. 이것이 모두 데이터 입력에 의해 처리되고 테이블에 새 열을 만들 필요가없는 사용자 정의 필드 시스템을 갖습니다 (이것이 help라고하는 것을 기억할 수 없습니다).

기존 고객이 시스템을 넘어서고 있음을 알 수 있습니다. 산업이 변화하면서 새로운 요구 사항이 나타나고 있습니다.

죄송하지만 기술적 인 이유만으로 이익을 얻는 것이 아니라 고객에게 원하는 것을 제공 할 수없는 경우 그 속도를 따라야합니다. 새로운 이민자가 더 많은 분야로 시장에 진출하는 것은 어렵지 않으므로 그렇게하지 마십시오.

잠시 동안 창 반대편에서 살펴본 결과, 마지막 작업에서 최종 사용자가 "사용자 정의"열을 엔티티 / 테이블에 추가 할 수있는 ERP 시스템에 노출되었습니다. 간단한 상호 작용으로 일대일 매핑으로 열을 두 번째 테이블에 동적으로 추가하는 것처럼 보였습니다. 예를 들어 :

정적 열이있는 WIDGET 테이블 :

• WIDGET_ID
• WIDGET_NAME
• WIDGET_COST
• 기타

사용자 정의 열이있는 WIDGETCUSTOM 테이블 :

• WIDGET_ID
• WIDGET_WEIGHT
• DID_BOB_WORK_ON_WIDGET
• 기타

WIDGET_ID 열은 서로 묶을 수 있습니다. 위젯을 편집 할 때 추가 필드가 자동으로 표시되어 동적 보고서에 포함하거나 검색 할 수 있습니다. 데이터베이스는 여전히 데이터베이스를 추적하고 필요한 경우 해당 열을 색인화 할 수 있기 때문에 상당히 효율적이었습니다.

프로그래밍 관점에서 나는 그것이 어떻게 제정신을 유지하는지 알 수 있습니다. 모든 고객은 자신 만의 맞춤 열을 가질 수 있지만 이러한 맞춤 열은 핵심 로직을 방해하지 않습니다.

기능 "요청"은 바로 요청입니다. 그들이 요구를하고 있다면, 회사가 코드베이스를 "혼잡"시키는 것이 얼마나 가치가 있는지 결정해야합니다. 그것이 풍토병 문제가되면 당신은 그것을 막을 수 있지만, 그들이 당신이 요구하는 것 또는 그것에 가까운 것에 기꺼이 지불하고 여기저기서 몇 가지 특징 일뿐이라면, 돈과 함께 가라고 말합니다.

더 나아가, 이것이 제품에 대한 지속적인 문제이고 여러 고객이 이러한 종류의 사용자 정의를 찾고 있다면 아마도 앱의 이러한 부분을 재고하고 고객이이를 수행 할 수있는 방식으로 융통성있게 만들어야 할 때입니다. 그 자체로, 임시보고, 유연한 데이터 수집 등이 있습니다. 이러한 성가심을 판매 지점으로 바꾸십시오. "주식 데이터 모델이 충분하지 않습니다. 맞춤형 옵션을 확인하십시오! 직접 할 수 있습니다!"

해당 기능에서 수행 할 작업을 정확하게 지정하고 예상 시간을 적용하여 작성해야합니다. 고객이 추가 입력란을 원할 경우 요금을 청구하십시오. 고객에게 기능을 만든 후 기능을 추가하려면 괜찮지 만, 경우에 따라 작동하는 데 약간의 비용이 더 든다고 고객에게 말합니다.

나는 그들이 당신이 그것을 사용하는지 여부를 걱정하는 이유를 이해하는데 어려움을 겪고 있습니다. 간단합니다. 원하는 것을 만들고 지불하면됩니다.

코드베이스 혼란? 새로운 기능에서 작업 할 때 코드를 리팩터링해야하는 경우 코드를 청구하십시오.

"몇 가지 추가 필드 만 추가"를 포함하여 추가 할 몇 가지 기능 목록을 작성하십시오. 고객에게 목록을 보여주고 어떤 고객이 먼저 원하는지 피드백을 요청하십시오. 자원이 제한되어 있으며 한 번에 모든 것을 할 수는 없다고 설명하십시오. 피드백을 사용하여 응용 프로그램과 함께 가고 싶은 방향을 결정하십시오.

고객이 몇 가지 추가 필드가 정말 주장하는 경우 그 중요하고 당신은 여전히 그들을 추가하지에 결정, 희망 고객은 아직도 당신이 대신 구현 된 기능의 혜택을 볼 수 있습니다.

일종의 풀 시스템에서 도움이 될 것 같습니다. 사용자가 다음에 구현할 기능을 선택하도록 허용하지만 언제든지 개발할 수있는 수를 제한하십시오. Kanban 보드는 이것으로 훌륭합니다. 사용자에게 priortiztion 프로세스의 소유권을 부여 할 수 있습니다 (일명 책임과 스트레스 감소). 사용자가 다음에 어떤 기능을 개발할 것인지 결정하고 다른 요청은 제 거한다는 사실을 알고 있으면 실제로 필요한 것을 결정하는 데 더 많은 투자를 할 것입니다.

고객이 소프트웨어를 실제로 사용하는 방법을 확인하기 위해 "사무실에서 하루"를 보내도록 고객에게 요청해야한다고 생각합니다 ... 잠깐만 ... 시간당 $ 250를 고용하면 알게 될 것입니다. 또한 금도금하지 마십시오. 그냥 작동하게하십시오. 대부분의 비즈니스는 제대로 작동 할 때보기 흉하지 않게 신경 쓰지 않습니다.

요청을 추적하십시오. 큰 기능 을 디자인 / 개발할 때 해당 릴리스에 포함 할 우선 순위가 지정된 몇 가지 요청을 선택하십시오.

요청에 대한 표준 협상 시스템을 구축하십시오. fogbugz와 같은 버그보고 또는 기능 요청 시스템을 기반으로 한 것일 수 있습니다. 고객이 요청을하고 다음을 기준으로 우선 순위를 정하십시오.

• 기능의 기술적 타당성 / 비용
• 기능 요청이 "유료"요청입니까? 계약서에 있거나 지불 한 경우
• 기능이 "이해"합니까? 이것은 약간의 기술이지만 일반적으로 충분한 고객이 기능을 요구하면 무료로 구현하십시오. 제품을 개선하고 다음 고객에게 더 쉽게 판매 할 수있는 기회입니다
• 사용하지 않은 유료주기가 있습니까? 계약의 일부로 유지 보수 / 지원을위한 월 단위 시간을 포함하고 (수치가 매우 낮더라도 권장합니다), 사용하지 않는 경우 이러한 종류의 변경 작업을 시작하십시오.

고객이 애플리케이션의 총 소유 권한을 보유한 경우 고객이 요청한대로 수행하십시오. 그들이 돈을 날려 보자. 그건 그들 꺼야.

그러나 그렇지 않은 경우 이러한 보조 필드에 대한 솔루션으로 이동하여 코어 데이터 모델 외부에 저장해야합니다. 그런 다음 데이터베이스보기와 같은 것을 사용하여이 특정 고객에 대한 추가 필드를 다시 병합 할 수 있습니다. (저장되는 데이터의 특성에 따라 보조 저장소를 수행하는 몇 가지 방법이 있습니다. 가장 간단한 것은 기본 테이블의 일부 PK와 기본 키가 동일한 테이블이지만 사용시 비효율적입니다 인덱싱과 같은 기능이 필요한 필드의 기능을 원할 때만 문제가됩니다.)

이 단계에서 구현할 리소스가 충분하지 않다는 고객의 요청을 취소 할 수도 있습니다. 그 시점에서 원하는 것을 저렴하게 구현할 수있게 될 시점 (최상의 견적)을 나타내는 로드맵을 가리키면 실제로 도움이됩니다. 그리고 당신은 해야 하면 해당 메타 기능이 기본 응용 프로그램의 핵심 판매 기능되면서, 싸게 기능을 지원하는 것이 가능하게된다 상태로 응용 프로그램을 받고 우선 순위.