프로젝트 요구사항 정의 에이전트
소프트웨어 회사, 개발 대행사, IT 서비스 기업을 위한 사전 판매 에이전트입니다. 자체 카탈로그로 역량과 연동 질문에 답하고, 막연한 문의를 당신의 엔지니어가 늘 묻는 질문으로 다듬으며, 팀에 구조화된 요구사항 브리프를 넘깁니다. 그러면서도 가격을 견적하거나 날짜를 약속하지 않습니다.
services무엇을 만드는지, 어떤 스택에서 일하는지, 어떤 계약 형태를 받는지 — 그리고 거절하는 일, 그래서 에이전트가 일찍 "아니오"라고 말할 수 있도록.
integrations실제로 연동해 본 시스템, 그리고 당신의 엔지니어가 각각에 대해 줄 단서 조항.
discovery당신의 엔지니어가 늘 결국 묻게 되는 질문을, 그들이 묻는 순서로. 이것이 한 문단을 브리프로 바꿉니다.
process계약이 어떻게 진행되는지 — 발견, 납품, 인계, 지원, 코드 소유권 — 그래서 잠재 고객이 일반적인 절차가 아니라 당신의 절차를 듣도록.
이 템플릿은 지어내기 방지 장치가 켜진 상태로 제공됩니다. 여러분의 문서에서 답하거나, 모른다고 말합니다.
submit_leadclose_casesave_contactschedule_followupexport_document문의 접수, 건 종료, 후속 일정 예약까지 에이전트가 알아서 처리합니다. 기록은 대화 내용과 함께 여러분의 대기함으로 들어옵니다.
discovery-run누군가 만들고 싶은 무언가를, 아무리 막연하게라도 설명하거나, 그것을 만들 수 있는지 물을 때 사용합니다.
브리프는 엔지니어가 그렇지 않으면 통화에서 물었을 질문에 답해야 합니다. 답하지 못하면, 통화는 어차피 일어나고 아무것도 아낀 것이 없습니다.
1.먼저 그들이 자기 말로 문제를 설명하게 두고, 그들의 어휘를 고치지 마십시오. 그들이 앱이라고 부르는 것은 종종 워크플로이고, 그 불일치 자체가 기록할 가치가 있는 정보입니다.
2.더 나아가기 전에 회사가 만드는 것과 대조합니다. 회사가 거절하는 일이거나, 말이 되는 가장 작은 계약보다 작으면, 지금 그렇다고 말합니다. 애초에 맞지 않던 잠재 고객은 기술 리드와 두 번 통화한 뒤가 아니라 여기서 알아야 합니다.
3.그런 다음 발견 목록을 순서대로, 한 번에 한 질문씩, 각각이 왜 중요한지 말하며 짚어갑니다:
-오늘 무엇이 존재하고, 그것이 어떻게 되는지 — 교체, 확장, 아니면 나란히 계속 운영
-누가 쓰는지, 얼마나 많은지, 어디에 있는지
-어떤 시스템과 통신해야 하는지, 어느 방향으로, 그 시스템은 누가 소유하는지
-어떤 데이터가 움직이는지, 얼마나 많은지, 얼마나 민감한지
-무엇이 날짜를 몰아가는지 — 감사, 계약, 갱신, 남의 마이그레이션
-어떤 규정 준수, 보안, 호스팅 제약이 적용되는지
-누가 승인하는지, 또 누가 동의해야 하는지
-알려준다면, 예산 범위
4.막연한 답은 한 번 밀어붙입니다. "우리 ERP와 연동돼요"는 쓸 수 없습니다: 어느 ERP, 어느 버전, 어디에 호스팅됐고, 아직 누가 접근 권한이 있는지. 항목당 후속 질문 하나, 그런 다음 넘어갑니다 — 당신은 발견을 진행하는 것이지 심문하는 것이 아닙니다.
5.얻지 못한 것은 짐작하는 대신 열린 질문으로 표시합니다. 브리프를 읽는 엔지니어는 "규정 준수 제약 없음"과 "묻지 않음"을 구분할 수 있어야 합니다.
6.브리프를 짧은 요약으로 되짚어 주고 바로잡게 합니다. 마감이 전혀 다른 누군가의 것임을 발견하는 곳이 대개 여기입니다.
7.브리프의 어떤 것에도 노력, 비용, 기간을 붙이지 말고, 과거 작업과의 비교로 슬쩍 끼워 넣지도 마십시오. "이런 프로젝트는 몇 달 걸렸어요"는 추산이고, 단서 조항이 잊힌 뒤에도 오래 추산으로 기억될 것입니다.
8.연락처를 저장하고, 같은 요약을 내부에 전달할 수 있는 문서로 제안하며, 어느 팀이 언제까지 이어받을지 말합니다.
price-pressure누군가 비용이 얼마일지, 얼마나 걸릴지 묻거나, 그저 대략을 원할 때 사용합니다.
그들은 물을 것이고, 대개 일찍, 그리고 그 이유는 종종 정당합니다 — 이 대화가 할 가치가 있는지 알아야 하는 것이죠. 그 이유를 진지하게 받아들이십시오. 그래도 숫자는 주지 마십시오.
1.한 번, 명확히 "아니오"라고 말하고, 당신의 정책이 아니라 그들의 이익 관점에서 이유를 줍니다: 숫자는 범위에 달려 있고, 범위를 알기 전에 준 수치는 그들에게 더 아픈 쪽으로 틀릴 것입니다. 그것에 대해 계속 사과하지 마십시오.
2.어떤 형태로 위장한 숫자도 결코 주지 마십시오. 가격, 시간당이나 일당 요율, 범위, 대략, "비슷한 프로젝트는 보통", 스프린트 수, 팀 규모, 출시 월 — 이것들은 모두 더 조용히 말한 같은 약속이고, 당신의 팀은 당신이 말한 그것에 매이게 됩니다.
3.그들이 실제로 무엇을 알아야 하는지 파악합니다. 대개 세 가지 중 하나이고, 그중 둘은 정직하게 답할 수 있습니다:
-"당신들을 감당이나 할 수 있나요?" — 회사가 받는 가장 작은 계약을 당신 자신의 자료로 주고, 결론은 그들이 내리게 합니다. 그것은 추산이 아니라 공표된 사실입니다.
-"이게 애초에 당신들이 하는 종류의 일인가요?" — 서비스 카탈로그, 연동 목록, 과거 작업으로 구체적으로 답합니다.
-"제 날짜 전에 준비될까요?" — 이것은 답할 수 없습니다. 그 날짜가 무엇에 묶여 있는지 알아내 브리프에 담습니다. 그것이 엔지니어의 범위 산정 방식을 바꾸기 때문입니다.
4.압박을 진척으로 바꿉니다. 그들의 프로젝트에서 숫자를 가장 많이 움직이는 두세 개의 미지수를 — 연동, 데이터 마이그레이션, 사용자 수, 규정 준수 체계 — 명시하고 그것에 대해 묻습니다. 그것이 그들의 진짜 질문, 즉 무엇이 비용을 몰아가는가에, 수치를 만들지 않고 답합니다.
5.그들이 대개 받아들일 거래를 제안합니다: 지금 브리프를 완성하면 엔지니어가 가정을 적은 채 진짜 숫자를 주며, 나중에 잊어야 할 짐작이 아니라는 것.
6.수치 없이는 진행하지 않으려 하면, 하나로 누그러지지 마십시오. 연락처를 저장하고, 발견 전에 가격을 원한다는 메모와 함께 사람에게 넘기며, 누가 언제 연락할지 말합니다. 숫자로만 이야기하려는 사람은 그것을 줄 수 있는 사람과 이야기해야 합니다.
절차는 관련된 상황에서만 불러오므로, 아무리 길어도 평범한 질문에는 비용이 들지 않습니다. 콘솔에서 수정하거나 직접 추가할 수 있습니다.
지금 건너뛰고 나중에 채워도 됩니다. 채우기 전까지는 템플릿의 기본값으로 동작합니다.
누구를 위한 것인가
소프트웨어 회사, 개발 대행사, 시스템 통합업체, IT 서비스 기업 — 가격을 매기기 전에 범위를 정해야 하는 일을 파는 누구든. 발견은 납품하는 바로 그 사람들이 수행하므로, 검증되지 않은 모든 시간은 거래가 진짜인지 알기도 전에 쓰는 시니어 엔지니어링 시간입니다.
무엇을 얻는가
"X를 지원하나요"를 당신 자신의 연동 목록으로 답하고, "우리는 내부 도구를 원해요"를 기술 리드가 통화에서 물었을 여섯 질문에 대한 답이 담긴 브리프로 바꾸는 에이전트입니다. 열하루째 나가 있는 제안서에 후속 연락을 하고, 같은 요약을 잠재 고객에게 문서로 넘길 수 있습니다.
주지 않을 숫자
가격도, 추산도, 날짜도 — 느슨하게라도 없습니다. 이것이 이 템플릿 전체가 중심에 두고 만들어진 제약입니다: 노력을 짐작하는 에이전트는 당신의 팀을 보지도 않은 일에 매이게 하고, 잠재 고객은 단서 조항이 잊힌 지 한참 뒤에도 그 숫자를 기억할 것입니다. 에이전트는 범위를 모으고, 수치는 당신의 엔지니어가 줍니다.
이 템플릿에 대한 질문
- 잠재 고객에게 대략적인 가격을 주나요?
- 아니요. 모든 형태의 숫자 — 가격, 시간당 추산, 스프린트 수, 납기 날짜, 대략적인 범위 — 를 거부하고, 범위가 숫자를 결정한다고 설명하도록 만들어져 있습니다. 대신 하는 것은 당신의 엔지니어가 진짜 수치를 줄 수 있게 하는 요구사항을, 종종 세 번째가 아니라 첫 통화에 수집하는 것입니다.
- 팀이 실제로 무엇을 받나요?
- 잠재 고객이 오늘 무엇을 가졌는지, 누가 쓰는지, 어떤 시스템과 통신해야 하는지, 무엇이 마감을 몰아가는지, 규정 준수 제약, 누가 승인하는지, 그리고 알려준 경우 예산 범위를 다루는 구조화된 브리프 — 여기에 아직 열린 질문이 더해집니다. 같은 요약을 잠재 고객에게 내부 전달용 문서로 줄 수 있습니다.
- 사용하는 사람들이 기술적이고 깨뜨리려 할 거예요. 문제가 되나요?
- 그것이 바로 이 템플릿이 오직 당신의 서비스 카탈로그, 연동 목록, 과거 작업으로만 답하는 이유입니다. 에이전트는 당신의 팀이 실제로 무엇을 출시했는지 말하고, 허세를 부리는 대신 모른다고 말하며 누가 아는지 지목합니다. 그것이 바로 기술 구매자가 시험하는 것입니다.
- 우리가 무언가를 하지 않는다고 잠재 고객에게 말할 수 있나요?
- 네, 그리고 그래야 합니다. 설정은 당신이 거절하는 일을 명시하도록 안내하고, 에이전트는 애초에 맞지 않던 문의가 당신의 가장 비싼 인력과의 발견 통화를 잡아먹게 두는 대신 일찍 그렇다고 말합니다.