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