brunch

매거진 IT회사에서 PM으로 일합니다

라이킷 14

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 이서 Jun 24. 2023

프로젝트는 '알아서' 할 수 없어요

사업쪽 담당자들을 만날 일이 많다.

비즈니스에서는 수익을 창출해야 하니, 이런저런 요구사항들을 들고 온다. 당연하다. 회사는 돈을 버는 곳이지, IT 기술을 실험하는 연구소 아니기 때문이다. IT부서는 그런 니즈를 명확히 인지하고 있다.

그런데 사업과 미팅을 하다 보면, 아래와 같은 어려움을 자주 겪는다.

요구 사항이 구체적이지 않다

'느낌'만 가지고 무작정 다짜고짜 회의를 잡아버리는 것이다. 이는 대기업 특히 IT기반이 아닌 제조업 중심의 대기업이 심한 편인데, 'IT서비스는 개발쪽에서 알아서 다 한다' 라는 생각이 지배적이기 때문이다.

예를 들어보자.

새로운 전자레인지를 만들고 싶은 사업부가 있다. '어떤 음식이든 자동으로 만들어주는 전자레인지를 개발한다' 가 목표다. 그래서 가전 개발팀을 전부 불러 모은다. 사업부 PM은 화면에 PPT를 띄운다. 그의 제품은 '파스타' , '피자' 등 음식을 전자레인지 안에 넣으면, 전자레인지가 자동으로 내부를 스캔해서 음식을 만들어준다. '어떤 음식이든' 자동으로 다 완성시켜줘야 하기 때문이다. 개발팀에서는 그렇게는 불가능하다고 말한다. 전자레인지가 음식을 자동으로 스캔, 종류를 판단하기는 어렵다고 말한다. 그걸 들은 사업부 담당자는 말한다.

그럼 알아서 잘 만들어 주세요.
'자동'이 핵심이에요.
제가 어떤거 원하는지 느낌 잘 아시겠죠?

요구사항이 구체적이지 않은 클라이언트와 상대하는 일은 IT서비스 담당자에게 비일비재 하다. 익숙하다. 하지만, 당연하다는 듯 개발팀에 요구사항 구체화까지 알아서 하라는 사업부 담당자와 일하기는 쉽지 않다. 조금만 고민을 해 보고 왔으면 좋으련만, 당연히 안되는 걸, 그 당연한 걸 설명해야 하는 IT담당자의 속은 타들어간다.

전설의 Wireless 샤워기, 개발자분들이 알아서 해 주세요.

위와 같은 그림을 정성스레 PPT로 그려서, 사업부장/개발팀장 모두 모아놓고 광을 팔면 다 죽자는 소리다. 사업부장은 당연히 박수치며 좋아하겠지. 큰 거 한방만 노리는 임원들은 얼씨구나 하겠지. 사장은 쾌재를 부르겠지. 요구사항 정의에 고민은 커녕, 의견 수렴도 하지 않은 부실한 사업모델.

개발팀 : "저걸 어떻게 구현하죠?"
사업팀 : "그건 개발에서 고민해 주셔야죠."
개발팀 : "아니 상식적으로 저게 말이 안되잖아요."
사업팀 : "답답하시네. 관점을 바꿔 생각하셔야죠. 기존 틀에 박힌 관습으로는 아무것도 혁신할 수 없습니다. 왜 꼭 물 자체가 샤워기로 이동해야 할까요? 수소 원자와 산소 원자만을 샤워헤드로 이동시킨 후, 샤워헤드 내에서 수소와 산소를 결합하여 물분자로 만들면 되잖아요. 화학 안배우셨어요? 제가 이렇게까지 알려드려야 하나요?"
개발팀 : "......"

요구사항 정의 단계는 프로젝트에서 가장 중요하다. 정말 가장 중요하다. 건물을 올리는 과정에서 상세 설계도를 그리는 과정과 같다. 위와 같은 사업의 태도는, 그 중요한 설계도를 알아서 그려달라고 하는 꼴이다. 방 배치는 어떻고, 채광은 어떻고, 몇 층으로 올릴지, 단열은, 자재는, 창문은 어디에, 이런 것들을 시공하는 분들께 '알아서 해 주세요' 라고 말하는 꼴이다. 구체적인 설계도 없이 어떻게 건물을 올리는가.

요구사항 정의 단계에서 프로젝트가 '어떤 제품을 만들지' , '구현 가능한지' 등에 대해 구체적인 고민을 하지 않으면 프로젝트는 반드시 산으로 간다. 개발자들은 고통을 겪는다. 클라이언트들은 구체적인 최종 목표에 대해, 화면의 흐름과 목적, 이 제품이 '할 수 있는 일'이 무엇인지 명확히 고민해 가져와야 한다. 기술적인 걸 잘 몰라서 고민이 어려운가? 그렇다면 개발자들과 아이데이션을 하자고 부탁해야 한다. 모여서 잠시 이야기하면 10분 내에 가능/불가능 여부가 나온다. 멋대로 상상해서 그려놓고 '해줘, 안되면 사장님께 이를거야' 라고 말하면, 모두가 슬픈 상황이 나올 수 밖에 없다.

또한 사업부 PM이 요구사항만 틱 던지고, 뒤로 빠져 사라지는 일은 없어야 한다. 프로젝트의 모든 관련자들은 제품 생산이 진행되는 모든 과정에 끝가지 참여해야 한다. '자 됐지? 이제 알아서 잘 만들어 와' 라는 태도로 임하면, 아마도 원하는 제품을 받기 어려울 것이다. 일은 '같이' 하는거다.

완벽한 프로젝트 목표 정의, 구체적인 요구사항 계획, 비즈니스 케이스 도출, 만족스러운 제품 이 모든 것들은 별개로 존재하지 않는다. 모두 같은 흐름 속에 존재한다. 사업부에서는 반드시 그 점을 인지해야 한다. 모든 과정에 모든 프로젝트 관련자들은 함께 끝까지 참여해야 한다. 실패를 방지하려면 반드시 그래야 한다. C레벨을 포함한 이해관계자들은 소프트웨어 프로젝트에 반드시 다양한 방식으로 참여해야 하며, 성공/실패 여부를 떠나 그 결과에 대해 일정한 책임까지 져야 한다.

프로젝트는 '알아서 굴러가지 않는다'

무턱대고 시킨다고 제품이 튀어나오지 않는다. 이건 특히 대기업, 제조업 일 경우 심하다. IT서비스를 구현하는 데 들어가는 인력과 자원이 우스운가? 그 소중한 리소스를 할당 받지 못해 발을 동동 구르는 조직들이 많다. 그런 자원을 말도 안되는 광팔이 프로젝트에 투입시켜놓고 나몰라라 한다니. 그 책임은 대체 누가 어떻게 지는 것인가?

대충 상상속으로 몇 번 그려본 아이디어를 가지고, 개발자들을 불러모아 '알아서 해 주세요' 라고 말하지 말라. 제품이 구체적으로 어떻게 구동할지 고민하고 고민하고 또 고민한 후, 명확한 요구조건을 스스로도 납득할 수 있는 문서로 산출할 수 있을 때. 그 때 IT서비스와 함께 이야기 해 보자. 구현에 대해 기술적으로 자신이 없다면, 아이디어 단계에서 개발팀과 간단히 이야기를 하라. 물론, 그런 자유롭고, 수평적인 문화를 만들어 주는 것은 회사의 몫이다. 누차 이야기 하는, 문화의 중요성이다.

아이디어만 던져주면 알아서 해 주는 팀은 회사 내 어디에도 없어요.

같이 해야죠.

우린 그런걸 '프로젝트'라고 부른답니다.

keyword