안정감
제안을 비교할 수 있고, 검수가 인상을 둘러싼 다툼이 되지 않습니다.
답을 알아 두면 좋은 질문들.
그중 어느 하나에 “모르겠습니다”라는 답이 나온다면, 바로 그 지점에서 제가 도울 수 있습니다. 결정이 내려지고 돈이 움직이기 전에 이사회, 사무총장, 군수, 대표이사에게 드리는 질문입니다.
- 시스템이 무엇을 해야 하는지를 공급업체에 검증할 수 있는 방식으로 설명할 수 있는가?
- 우리의 일상 업무 가운데 예외 없이 작동해야 하는 시나리오는 무엇인가?
- 우리 데이터는 어떻게 되며, 공급업체를 바꾸고 싶을 때 계약에서 어떻게 빠져나오는가?
- 시스템은 얼마나 빠르게, 어느 정도의 데이터량에서 작동해야 하는가?
그래서 얻는 것.
더 나은 성과
공급업체의 템플릿에 있는 것이 아니라, 귀 조직에 필요한 것을 받게 됩니다.
더 적은 암초와 실수
요구사항을 도입 이후가 아니라 도입 이전에 정리해 두었으므로 가동 후 수정이 줄어듭니다.
이 단계에서 실수의 비용. 요구사항이 불분명하면 부속 계약, 가동 후 수정, 검수를 둘러싼 분쟁으로 이어집니다. 자문가에게 드는 비용은 대개 잘못 고른 기술 하나, 맞지 않는 공급업체 하나, 계약 속 함정 하나보다 적습니다.
요구사항은 공급업체와 나누는 대화의 통화입니다.
입찰 공고를 내거나 제안 요청서를 보내기 전에 귀 조직의 프로세스 언어로 작성해 두면, 제안을 비교할 수 있고 이후 공급업체에 책임을 물을 수 있습니다. 이것이 저의 가장 중요한 역량입니다. 조직의 필요를 업무 요구사항, 시나리오, 검수 기준으로 옮기는 일입니다.
받으시는 것.
- 인터뷰, 프로세스 맵, 데이터 모델, 연동, 테스트 시나리오.
- 무엇보다 도입의 성공 기준에 대한 답: 왜 이 일을 하며 어떤 결과를 기대하는가.
- 경영진에게 아이디어는 있지만 이를 정리할 시간이 없을 때: 한 번의 대화 후 약 2일 안에 콘셉트나 프로토타입.
이 단계에서 제가 일하는 방식.
- 인터뷰와 프로세스 맵프로세스에서 일하는 구성원 및 프로세스 담당자와 진행합니다. 현재 상태와 기대하는 상태에 대한 기술이 만들어집니다.
- 요구사항과 시나리오데이터 모델, 연동, 화면, 알림, 규칙, 테스트 시나리오, 그리고 사용 편의성, 속도, 데이터량에 대한 요구사항도 포함합니다.
- 검수 기준시스템이 의도한 대로 작동하는지 알 수 있는, 검증 가능한 기준입니다. 공급업체는 이를 도입 후가 아니라 제안 전에 받습니다.
“그는 변화의 큰 방향을 각 부서에 던져야 할 질문, 합의해야 할 요건, 경영진이 내려야 할 결정으로 구체화할 줄 압니다.”
이 단계에서의 제 역량.
업무 부서 사용자가 제기한 문제는 IT 세계가 이해하는 언어로, 기술의 가능성은 경영진의 의사결정 언어로 옮깁니다.
이 단계에 관해 가장 많이 받는 질문.
왜 입찰 전에 요구사항을 정리해야 합니까?
그래야 제안을 비교할 수 있고 공급업체에 책임을 물을 수 있습니다. 요구사항이 없으면 약속을 비교하는 데 그치고, 검수는 막연한 인상에 의존하게 됩니다.
경영진이 요구사항을 정리할 시간이 없다면 어떻게 합니까?
약 15분의 대화면 충분합니다. 약 이틀 뒤에 콘셉트나 프로토타입을 가지고 돌아오며, 프로젝트에 첫 비용이 발생하기 전에 이를 보고 방향을 판단할 수 있습니다.