이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
업무 시스템의 IT 니즈를 파악하기 위한 접근 방식을 처음 배운 것은 학내 행정 업무 자동화 프로젝트에서 실무 담당자를 인터뷰하면서였습니다. 개발자 관점에서 생각한 기능과 실제 담당자가 필요로 하는 것이 다른 경우가 많았는데, 직접 업무 흐름을 관찰하고 질문하는 과정에서 실제 불편 지점이 드러났습니다.
현재 어떻게 하고 있는지를 먼저 보는 것이 중요했는데, 담당자가 설명하는 것보다 실제 화면을 보면서 작업을 따라가니 놓쳤던 예외 케이스가 보였습니다. As-Is 흐름도를 그려 담당자와 함께 확인하자, 제가 오해한 부분이 빠르게 드러났고 수정이 쉬웠습니다.
우선순위 파악도 중요했는데, 모든 불편을 한 번에 해결하려다 보면 핵심과 부수 기능을 구분하기 어렵습니다. 담당자가 가장 자주 하는 작업을 먼저 해결하는 것이 체감 효과가 높았습니다. IT 니즈는 말이 아니라 현장 관찰에서 찾아야 한다는 결을 배웠습니다.
업무 시스템의 IT 니즈를 파악하고 개선한 뒤 효과를 어떻게 확인할지도 중요한 과제였습니다. 담당자가 가장 자주 하는 작업을 먼저 해결하는 방향으로 우선순위를 정했는데, 개선 후에 실제로 그 작업이 얼마나 빨라졌는지 확인하고 싶었습니다. 개선 전에 담당자가 같은 작업을 처리하는 데 걸리는 시간을 기록해뒀다가, 개선 후에 다시 측정하니 단순한 체감이 아닌 비교 가능한 수치로 효과를 볼 수 있었습니다. 담당자의 만족도를 확인하는 과정에서 구현한 기능 중 실제로 사용되지 않는 것이 있다는 것도 알게 됐는데, 다시 확인하니 처음 파악 단계에서 놓쳤던 업무 흐름이 있었다는 것을 발견했습니다. IT 니즈 파악은 한 번으로 끝나는 것이 아니라 개선 이후에도 실제 사용 패턴을 관찰하면서 보완해야 한다는 것을 이 경험에서 배웠습니다.
업무 시스템의 IT 니즈를 파악할 때 한 부서의 담당자만 인터뷰하면 전체 그림을 놓치는 경우가 있었습니다. 한 프로젝트에서 입력을 담당하는 부서와 그 데이터를 조회하는 부서의 요구 사항이 상충하는 상황이 생겼습니다. 입력하는 쪽에서는 빠르게 저장하는 것이 중요하다고 했는데, 조회하는 쪽에서는 세부 항목을 더 많이 입력해달라는 요청이 있었습니다. 각각의 불편이 얼마나 자주 발생하는지, 업무 흐름에 얼마나 영향을 주는지를 정리해서 두 부서 담당자가 함께 논의하는 자리를 만드니, 서로 상황을 모르고 있었다는 것을 알게 됐고 중간에서 타협점을 찾는 방향으로 논의가 이어졌습니다. IT 니즈 파악에서 이해관계자가 여럿일 때는 각자의 요구를 모아서 함께 논의하는 자리를 만드는 것이 상충 관계를 해소하는 데 효과적이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.