[GeekNews] 개발자가 "No"라고 말할 때 물어봐야 할 4가지 질문

출처

- 원글 : 4 Questions to Ask Devs When They Say "No" (skiplevel.co)

- 번역 : 개발자가 "No"라고 말할 때 물어봐야 할 4가지 질문 | GeekNews (hada.io)

 

이 글은 원글과 GeekNews의 요약을 보고 개인 의견 메모를 위해 작성되었습니다.

---

요약

• 개발자들이 No라고 할 때, 이에 대응하는 것은 제품 관리자로서 권한을 주장하고 목표를 달성하는 데 도움이 됨
• 기술적 이유로 인해 기능을 제시된 시간 내에 구현할 수 없다고 할 때, 올바른 질문을 통해 상황을 타개할 수 있음

1. 기능을 구축하는 데 있어 다른 기술적 해결책이 있을까요?

• 기능을 구축하는 방법은 여러 가지가 있으며, 처음 시도하는 방법이 항상 최적은 아님
• 개발자들은 최신 기술을 사용하여 멋진 기능을 구축하고자 하지만, 이는 단순성을 위한 최적화보다 과도한 엔지니어링으로 이어질 수 있음
• 특정 기술 세트를 가진 개발자들은 그들의 지식 범위 밖에 있는 더 간단한 해결책을 인지하지 못할 수도 있음
• 그래서 엔지니어가 기술 솔루션에 대해 더 창의적으로 생각하도록 유도하는 것이 좋음
• 내가 함께 일했던 최고의 제품 관리자 중 일부는 기술 환경에 대한 충분한 기술적 통찰력과 지식을 갖추고 있어 엔지니어가 틀에서 벗어난 사고를 할 수 있도록 통찰력 있는 질문을 던질 수 있었음

2. 이러한 제약 조건을 가진 상태에서 해결책을 제시해야 한다면 어떻게 하실껀가요?

• 당신이 제안한 해결책에 개발자들이 문제를 제기한다면, 그들에게 그들의 해결책을 요청해볼 것
• 개발자들은 창의력과 혁신의 보고이며, 더 단순한 버전의 기능이 있는지 물어봄으로써 그들에게 창의적인 사고를 할 기회를 제공함
• 문제의 핵심을 이해하면 개발자들은 창의적으로 생각하고 프로젝트의 제약 조건 내에서 작동하는 해결책을 찾아냄

3. 이 기능에 대해 단계적 접근 방식을 고려할 수 있을까요?

• 기술적 복잡성을 이유로 기능 구현이 불가능하다고 말할 때, 프로젝트를 단계별로 나누어 다른 릴리스 날짜로 구성할 수 있는지 물어봄
• 한 번에 웅장한 비전을 제공하고 싶은 유혹이 있지만, 단계적 접근 방식은 더 반복적이며 구체적인 결과를 더 빨리 제공함
• 우선 순위가 변경될 수 있으며, 단계적 접근 방식은 개발자와 함께 다음에 추가해야 할 기능을 조정할 수 있게 함

4. 작업을 가능하게 하기 위해 어떤 장애물을 제거하거나 해결할 수 있을까요?

• 자원 기반의 이의 제기에 대한 질문으로, 개발자들이 제한된 자원(예: 시간 또는 사용 가능한 개발자)을 이유로 들 때, 그들의 시간을 확보하기 위해 적극적으로 작업을 제거함
• 가능한 방법: 작업을 완전히 제거하거나, 개발자가 필요하지 않은 작업을 수행하거나, 다른 팀과/또는 제3자와의 의사소통을 맡거나, 프로세스를 소유하고 레거시 기능을 폐기함으로써 작업을 쉽게 만들 수 있음

결론

• 개발자들에게 "안 된다"는 말에 "밀어붙이기"가 불편할 수 있지만, 이를 통해 더 많은 존중을 받을 수 있음
• 엔지니어가 반대하는 이유가 무엇인지 조금 더 깊이 파고들어 그 이유를 파악하고 반대 의견을 하나씩 제거해 나가야 함
• 이러한 질문은 엔지니어가 특정 기능을 구현할 때 직면할 수 있는 고유한 어려움과 제약을 인정하는 것이기 때문에 모두 좋은 질문임
• 또한 팀과 프로젝트를 돕기 위해 직접 팔을 걷어붙이고 궂은 일을 하거나 요구 사항과 일정에 맞게 조정하는 등 기꺼이 자신의 역할을 하겠다는 의사를 분명히 밝히는 것이기도 함

 

---

개인 의견

(나를 포함해서!!) 개발자들과 일을 하다보면 굉장히 많은 안돼요!에 마주친다.

이를 설득하는 일은 항상 어렵다. 

이 글에 나온 것처럼 시간의 제약, 기술적 한계 등에 부딪히기 때문이다.

 

개인적인 경험으로 어떤 도구를 도입하려고 주변 사람들을 설득할 때가 떠오른다.

몇 번을 이야기해도 사람들은 내가 말했던 단어와 개념조차 가물가물하게 기억했다.

절망적인 상황으로 느껴졌다.

• 이게 왜 필요한지?
• 쓰면 어떤 점이 좋은지?

이런 질문이 나오면 오히려 감사할정도로 사람들은 무심했다.

 

당시 우리 팀의 팀장님께서도 좋은 말씀을 해주셨다.

사람들이 한 번에 모든 이야기를 이해할 거라고 생각하면 안된다.

충분히 이해할 때까지 몇 번이고 품어주어야 한다고.

 

하지만 아이러니하게도 설득과 공감대는 세미나가 아닌

커피 한잔하면서 나눈 잡담 속에서 피어났던 기억이 난다.

 

시간이 흐른 현재,

나는 무심함을 탓하지 않는다.

왜냐하면 아직 그만큼 공감대를 형성하지 못했기 때문이라고 생각한다.

 

상대방을 설득하기 전에

상대와 작게 나마 이야기를 나눈 적이 있는지 한번 더 반성해보아야 겠다.