개발자가 "No"라고 말할 때 물어봐야 할 4가지 질문
(newsletter.skiplevel.co)- 개발자들이 No라고 할 때, 이에 대응하는 것은 제품 관리자로서 권한을 주장하고 목표를 달성하는 데 도움이 됨
- 기술적 이유로 인해 기능을 제시된 시간 내에 구현할 수 없다고 할 때, 올바른 질문을 통해 상황을 타개할 수 있음
1. 기능을 구축하는 데 있어 다른 기술적 해결책이 있을까요?
- 기능을 구축하는 방법은 여러 가지가 있으며, 처음 시도하는 방법이 항상 최적은 아님
- 개발자들은 최신 기술을 사용하여 멋진 기능을 구축하고자 하지만, 이는 단순성을 위한 최적화보다 과도한 엔지니어링으로 이어질 수 있음
- 특정 기술 세트를 가진 개발자들은 그들의 지식 범위 밖에 있는 더 간단한 해결책을 인지하지 못할 수도 있음
- 그래서 엔지니어가 기술 솔루션에 대해 더 창의적으로 생각하도록 유도하는 것이 좋음
- 내가 함께 일했던 최고의 제품 관리자 중 일부는 기술 환경에 대한 충분한 기술적 통찰력과 지식을 갖추고 있어 엔지니어가 틀에서 벗어난 사고를 할 수 있도록 통찰력 있는 질문을 던질 수 있었음
2. 이러한 제약 조건을 가진 상태에서 해결책을 제시해야 한다면 어떻게 하실껀가요?
- 당신이 제안한 해결책에 개발자들이 문제를 제기한다면, 그들에게 그들의 해결책을 요청해볼 것
- 개발자들은 창의력과 혁신의 보고이며, 더 단순한 버전의 기능이 있는지 물어봄으로써 그들에게 창의적인 사고를 할 기회를 제공함
- 문제의 핵심을 이해하면 개발자들은 창의적으로 생각하고 프로젝트의 제약 조건 내에서 작동하는 해결책을 찾아냄
3. 이 기능에 대해 단계적 접근 방식을 고려할 수 있을까요?
- 기술적 복잡성을 이유로 기능 구현이 불가능하다고 말할 때, 프로젝트를 단계별로 나누어 다른 릴리스 날짜로 구성할 수 있는지 물어봄
- 한 번에 웅장한 비전을 제공하고 싶은 유혹이 있지만, 단계적 접근 방식은 더 반복적이며 구체적인 결과를 더 빨리 제공함
- 우선 순위가 변경될 수 있으며, 단계적 접근 방식은 개발자와 함께 다음에 추가해야 할 기능을 조정할 수 있게 함
4. 작업을 가능하게 하기 위해 어떤 장애물을 제거하거나 해결할 수 있을까요?
- 자원 기반의 이의 제기에 대한 질문으로, 개발자들이 제한된 자원(예: 시간 또는 사용 가능한 개발자)을 이유로 들 때, 그들의 시간을 확보하기 위해 적극적으로 작업을 제거함
- 가능한 방법: 작업을 완전히 제거하거나, 개발자가 필요하지 않은 작업을 수행하거나, 다른 팀과/또는 제3자와의 의사소통을 맡거나, 프로세스를 소유하고 레거시 기능을 폐기함으로써 작업을 쉽게 만들 수 있음
결론
- 개발자들에게 "안 된다"는 말에 "밀어붙이기"가 불편할 수 있지만, 이를 통해 더 많은 존중을 받을 수 있음
- 엔지니어가 반대하는 이유가 무엇인지 조금 더 깊이 파고들어 그 이유를 파악하고 반대 의견을 하나씩 제거해 나가야 함
- 이러한 질문은 엔지니어가 특정 기능을 구현할 때 직면할 수 있는 고유한 어려움과 제약을 인정하는 것이기 때문에 모두 좋은 질문임
- 또한 팀과 프로젝트를 돕기 위해 직접 팔을 걷어붙이고 궂은 일을 하거나 요구 사항과 일정에 맞게 조정하는 등 기꺼이 자신의 역할을 하겠다는 의사를 분명히 밝히는 것이기도 함
제가 PM/PO 로서, 프로젝트 사업부서-IT부서간 조율 역할을 할때 도움이 되었던 2가지 방법론이 있는데요.
물론, 전제는 사업부서나 IT부서나 '말귀를 알아먹는다'라는 전제가 필요합니다.
첫번째는, 단계적으로 진행한다.
두번째는, 규모를 줄인다.
두가지입니다.
사업부서나 IT부서의 프로젝트 진행함에 있어 가장 큰 애로사항은 '기간'입니다.
기간은 정해졍있고, 볼륨은 그 기간안에 못할것 같은 경우가 가장 많죠.
이럴땐 '단계적'으로 한다. phase1, 2,3.. 와 같이 순차적 일정으로요. 가장 중요한 기능을 phase1에 덜 중요한걸 phase2..에 이런식으로요.
그런데 이렇게 단계적으로 못하는 프로젝트, 즉 한방에 오픈해야 하는 것들은,
규모를 '기간'에 맞게 줄여야 합니다. phase 1,2,3에 들어갈 것 중 '진짜 필요한 기능' 외에는 날려야 합니다.
이 두가지 방법론이면 '말귀 알아듣는 사업부서/IT부서'면 대부분 동의합니다.
프로젝트가 빠그러져서 각자의 상사에게 깨지는것 보다는 낫거든요..
쩝.
모두 힘내세요^^
PS:
마지막 양념이 있는데요.
위와 같이 2가지 방법을 써도 개발자들은 난색을 표하는 경우가 많아요.
그럴때
"프로젝트 기간 중간쯤 한번 체크해 봅시다. 기간이 더 필요할 것 같으면 제가 책임지고 기간 연장 하겠습니다"
하면 개발자들의 얼굴이 펴지는 경우가 많아요.
그래서 중간쯤 체크하면 기간이 더 필요없는 경우가 95%였습니다.
또 개발자들 코딩하기 시작하면 금방 하는 경우가 많거든요.
개발자와 조율해야하는 역할의 사람으로써 이런 대화가 가능한 개발자와 일하고 싶네요. 일단 안된다고 하는 개발자만 만나봐서 속상합니다. 이래저래 구슬러보고 물어보다보면 본인이 모르는 방법이 있었던 경우가 대부분인데 말이죠..
한국은 No라고 하면 안 됩니다. 한국의 엔지니어 및 개발자들은 영업의 하위부서고, 직급도 낮고 제아무리 책임자라도 타 부서 책임자보다 지위가 낮기 때문에 타 부서 요구에 응해야 하는 게 대한민국 조직 사회의 철칙이죠. 따라서 이 글은 한국에서 가장 쓸모없는 글이라 하겠습니다 젠장.
엔지니어 이전에 사람인걸요. 엔지니어로써 습관성 No는 문제인건 동감합니다만 PM/PO 쪽에서 저런 질문을 지니고 있으면 큰 힘이 될 것 같네요.