본문 바로가기

Log/essay

개발자랑 기획자랑

Photo by Daniel Seßler on Unsplash

사례

1. 

기획자가 문제P 를 해결하기 위해, 기존 기능A 를 수정해 달라고 했다.

수정했다.

2. 

예상치 못한 상황이 있어서 기능A-1 이 있어야한다고 한다.

(많은 에러와 사투끝에 작동하게)  만들어줬다.

3.

A-1 기능이 문제가 있다고 한다.

보니깐 코드는 문제가 없다. 회의 끝에 상황파악이 됐다.

A-1은 기획자가 말한 기능은 다 되지만, A-1로 문제P 를 해결할수 없다. (또다른 문제 P-1에 대응이 안되기때문)

여기서 마인드가 갈린다!

기획자: 아니 당연히 전체적으로 A기능을 만들기 위해 A-1 을 만드는건데.. 당연히 P-1도 대응되면서 근본적인 원인을 해결하도록 짜야지.. (어이가 없고, 말도 잘 안통해서 빡침)

개발자: 명세대로 A-1 기능을 짬. 다른 고려사항도 많았는데  A-1가 A 문제 해결이 될거라고 기획한게 잘못된거아님? (도대체 어쩌라고) (의미없는곳에 코드작성하냐고 쏟아부은 나의 노력과 시간을 생각하면 또 빡침)

 

결국 A-1 기능은 없던걸로...

그리고 다음 회의시간에 또 이야기하기로~ㅋㅋ

개발자 변호

개발자가 전체적으로 보기가 불가능에 가깝다.

코드, 프로젝트, CI/CI,  DDD, Design Pattern, math, Cloud, 짜면서 새로운것을 또 학습해야한다.

그리고 실패(에러)에 실패를 거쳐,  작동하는거다. 기획자의 요구안에 또다른 우주가 있다. 그 우주안에서 깨달음을 얻고 시행착오를 겪고 또 성장하고 고뇌하고 하.. 

기획자 보다 개발자가 그것에 쏟아내는 자원이 비교가 안된다.  일주일 날라가는건 진짜 아무것도 아니다.

(공장에서 찍어내는 듯한 작업은 제외) 창의적인것을 원한다면, 진짜 개발자를 불쌍히 여겨야한다.

개발자의 시간을 존중해줘야 한다.

 

개발자는 개발을 안하면 기획자나 비지니스를 이해할수 있다. 근데 개발이라는 악령에 씌어서 그런거다.

개발을 하면 항상 최악의 상황을 대비해서 만들어야한다. 극단적인 input도 견뎌야한다. (그래서 말까지 극단적일수도..)

기획자 변호

하지만 비지니스를 보면 기획자를 이해할수 있다. 개선하는게 목적이 있는데, 도대체 (알지도못하는) 저기서 왜이렇게 오래걸리고, 안된다고 하는지.. 다 안된다고 하고.. 짜증을 낸다. 비지니스에서 필요한건데 비지니스는 1도 생각하지 않고, 문제만 보고.. 크게 볼줄도 모르면서.. 우물안에서 컴퓨터하는 개구리 같아보인다.

 

비지니스가 없으면 개발이고 뭐고 없는데 말이다.

결론

기획자는 요구사항 이야기할때, 큰 그림을 한번 이야기해야한다.

개발자도 큰 그림을 들었으면, 고려해야한다. 앞의 요구사항만 문제해결하려고 하면 안된다.

근데 이것도 경력 꽤 오래된 시니어들은 여유가 쫌 있으니 가능한거지 100의 80은 절대 못한다. (내코가 석자..)

 

개발자가 주인의식을 가지고 일하면 전부다 해결되는거다.

근데 주인이 아닌데 어떻게 주인의식이 생기나.. ㅜ

그래도 개발자들이여 예쁘게 말하자.. 말끊지말고..

알아도 문제를 집어내기만하면 대화가 안된다.. 사람과 대화를 하자. 다른 사람들은 컴퓨터가 아니다.

 

내 결론은 개발자가 말을 예쁘게 하자는거다.

(아무리 아닌거 알아도.. 근데 막상 이 상황이 오면 아무리 선비여도 폭주(+고집)해버리는게 개발자 종특이다.)

아니면 자체 서비스의 주인(Founder)이 되던가

 

PS. 사내문화와 개발방법론을 쫌더 공부하는것도 좋을것 같다. -> 외주받는거면 무의미