[💬] 기획서 쓸때 제발 다른 변수 좀 생각해줘라

[익명(223.38)]

어떤 기능 만들면 재밌을듯 하고 그거에만 대해서 기획서 쓰지말고 기능이 도입됐을때 다른 기능과 맞물리는지 또는 그 기능에 대해 추가 기능은 없는지 , 맞물렸을때 어떻게 되는지 이런거 좀 써줘

- dc official App

[익명(218.234)]

나도 플머고 기획자 개패고 다니는데 이건 힘들다고 생각, 처음엔 재미만 생각하는게 맞음, 개발 현실성 범위 내에서

[익명(223.38)]

패고 다닌다기보다는 서로 크로스체크 해야하는데 그런 행위를 안하니까 나도 놓치는 부분이 있으면 나중에 완성되고나서 큰 문제가 생길수도있으니까 불안해서 그럼 - dc App

[익명(218.234)]

그런 체킹이하면 회의의 영역이라 생각, 인터넷에 올리는 기획서들은 컨셉서이기 때문에 회의할 대상이 없음 그러니 당연한 모습이라 생각함, 회의하고 부딫히면서 타협해나가야지.

[익명(223.38)]

대부분 경험해본게 회의때 개발이 기획한테 조언을 하지 기획이 개발한테 이런 부분은 이러이러해서 신경써줘야해요 이런식으로 진행해본적이 별로없었어 개발이 기획한테 이러면 어떻게되나요? 이러면 아 그건 생각못했네요 이렇게 흘러가고 - dc App

[익명(119.194)]

역시 플머는 달라 콘

[익명(175.194)]

팩트는 기획도 기획서 쓸 때 그런 부분을 생각은 한다는 거임. 근데 완벽하지 않은 거고.

[익명(175.194)]

문제가 실제로 없었으면 아무 문제도 없으니 그냥 넘어가고, 문제가 생겼고 그걸 개발이 알아차렸을 때만 사건이 터지기 때문에 이런 말이 나오는 거

[익명(175.194)]

뭐 기술부채같은 문제로 상황이 꼬인 게 아니라면 기획의 책임이 더 큰 건 사실이지만, 한 직군이 모든 상황을 고려해서 계획을 짤 수는 없음. 여럿이 크로스체크하는 게 그거 때문인 거고

[익명(118.36)]

각 파트별로 집중하는 영역이 달라서가 아닐까 싶네.

[익명(218.49)]

기획할 때는 일단 재미에 집중하는게 맞음. 그러고 나서 기술에 타협해나가는 거지