※ 아래 예시는 정말로 비정상적인 상황이며,

그래서 작성자는 이렇게 일하는 사람들이랑 일 못하겠다고 사표를 던진 상황입니다.

1. 관리대상의 상태값 정의.

개발(프로그래머)은 말단사용자(액터)가 누군지 명확하게 모름. 그래서 누가 어떻게 가져갔을 경우에 어떻게 상태값을 줘야하는지 개발이 정한다는건 말이 안됨.

기획레벨에서 상태값이나, 목록에 표시될 조건값 정해주면 그때부터 DB설계해서 데이터 값이나 코드 정하고 구현 들어가야하는데, 기획에서 이거 안정하고 개발이 정해달라고 짬때리길래 한번 버럭하고 엎었음.

2. 빠른 문서화작업

기획문서(화면설계서) 보다보면 스무스하게 어떤 데이터가 어디서 입력되고 어디서 어떻게 표기된다는게 보이면 정말 좋은 기획서인데, 기획자들도 사람이니까 놓치는게 생기고 머리속에 있는걸 문서에 다 못옮겨서 빠뜨리는 경우가 생길 수 있음.

그럼 개발이 구현하다가 ⁉️하고 의문생겨서 기획한테 물어보러 가는데, 아무튼 이상한 부분에 문의를 해서 답변을 받았고 합의가 됐으면 그걸 당연히 문서 업데이트를 해야하잖아?

우리회사 기획팀은 그 문서 업데이트를 안하더라고.

3. 테스트 시나리오 작성

뭔가를 기획을 해서 만들었을 때 그게 재대로 만들어졌는지 판단할 수 있는 사람은 첫번째가 그걸 만들어달라고 요구한 클라이언트겠지만, 클라이언트의 요구사항을 개발팀에 전달한 기획자들이 두번째정도로 잘 알고 있을거란말입니다.

그래서 기획안이 완료가 되면 바로 해야하는게 테스트 시나리오를 작성을 해야되요.

어떤기능을 눌렀을 때 예상되는 시나리오를 만들어서 그대로 직접 테스트를 진행을 하던지, QA팀이나 외주 테스터들한테 넘기는거죠.

근데 우리회사 기획팀은 그걸 작성을 안하더라. 3년동안 단 한번도. QA팀 따로 없는 좆소니까 개발자까지 테스트에 투입하는건 알겠는데, 우린 다들 알고있죠? 만든놈한테 문제있는지 물어보면 죽어도 못찾는거.

대충 케이스 잡아서 적어보긴 했는데, 이거 어디다가 설명할 필요도 없이 개발방법론 두세개만 읽어봐도 다 써있는 당연히 필요한 내용입니다.

이런거 안해주는 회사면 최대한 빠르게 도망치세요