The best e-business partner
BRUNCH
시스템 개발은 계약서에서 시작됩니다.
견적이 오가고,
범위가 정해지고,
일정이 확정됩니다.
서명하는 순간 우리는
발주자와 수행사,
즉 계약 관계가 됩니다.
형식은 분명합니다.
책임도 구분되어 있습니다.
그러나 수많은 현장을 지나며
분명히 느낀 점이 있습니다.
프로젝트의 성패는
계약 조항이 아니라
사람과 사람 사이의 방향에서
갈린다는 사실입니다.
계약은 출발점일 뿐입니다.
의뢰자 입장에서는
당연한 말씀을 하십니다.
“계약한 대로 정확히 해주시면 됩니다.”
맞는 말씀입니다.
계약은 신뢰의 최소 단위이니까요.
그러나 시스템 개발은
계약서에 적힌 문장만으로
완성되는 일이 아닙니다.
사업은 변합니다.
시장 반응도 달라집니다.
운영을 시작하면 예상하지 못한
요구가 반드시 등장합니다.
그 순간 선택이 갈립니다.
“계약 범위 밖입니다.”
혹은
“지금 상황이라면 방향을
이렇게 조정하는 것이 맞겠습니다.”
두 문장의 차이는
단순한 표현의 차이가 아닙니다.
그 온도 차이가
결국 프로젝트의 결과를 바꿉니다.
실패는 기술이 아니라 관계에서 시작됩니다.
20년 넘게 현장을 지켜보며
반복해서 확인한 것이 있습니다.
시스템이 무너지는 이유는
기술 부족보다 관계의 단절에서
먼저 시작된다는 점입니다.
현장에서는 이런 말들이 오갑니다.
“우리는 비용을 지불했습니다.”
“우리는 계약대로만 진행합니다.”
그리고 그 사이에서
서로의 언어를 이해하려는
노력이 사라집니다.
개발자는 구조로 생각합니다.
사업가는 매출과 시장으로 판단합니다.
이 두 언어가 번역되지 않으면
같은 목표를 향해 가는 듯 보이지만
실제로는 서로 다른
방향을 보고 달리게 됩니다.
의뢰자는 단순한 고객이 아닙니다.
많은 대표님들께서
이렇게 말씀하십니다.
“전문가이시니 알아서 잘 설계해 주시겠지요.”
그러나 시스템은 기술로만
완성되지 않습니다.
그 안에는 사업의 철학이
담겨야 합니다.
이 서비스는 왜 존재하는가.
어떤 고객을 잡으려 하는가.
수익은 어디에서 발생하는가.
우리는 무엇을 포기할 것인가.
이 질문에 대한 답은
개발사가 대신 정할 수 없습니다.
개발사는 구조를 설계합니다.
하지만 방향은 의뢰자가
제시해야 합니다.
그래서 의뢰자는 단순한
발주자가 아니라
공동 설계자에 가깝습니다.
개발사 역시 단순 외주가 되어서는 안 됩니다.
반대로 개발사도 책임에서
자유로울 수 없습니다.
“요청받은 기능만 정확히 구현하면 됩니다."
이 태도로는
오래 함께 갈 수 없습니다.
진정한 파트너라면
의뢰자가 아직 보지 못한
위험까지 먼저 고민해야 합니다.
이 구조는 확장에 한계가 있습니다.
이 기능은 운영비 부담이 큽니다.
이 모델은 모객이 쉽지 않을 수 있습니다.
때로는 듣기 불편한 말씀을
드려야 할 때도 있습니다.
그러나 그 대화가 없다면
프로젝트는 ‘납품’으로 끝나고 맙니다.
결국 질문은 하나입니다.
이번 프로젝트를
거래로 마무리할 것인지,
함께 키워갈 것인지.
납품이라면 계약 관계로 충분합니다.
그러나 성장은 동반자 관계가
아니면 어렵습니다.
계약은 종이에 남습니다.
동반자는 결과에 남습니다.
그리고 시장은
누가 옳았는지를
기억하지 않습니다.
무엇이 살아남았는지만 기억합니다.
http://
갈등은 기능에서
생기는 것이 아니라,
서로 다른 기대의 온도에서
시작된다는 것을..
어쩌면 우리는 시스템을 만드는 일이 아니라,
함께 감당할 책임의 범위를 조율하는 일을 하고 있는지도 모릅니다.
그 방향이 같을 때만 계약은 결과로 남습니다.
출처 : 브런치,[by 박민정] – [의뢰자와 개발사는 계약자인가, 동반자인가?] [원문 링크]
