업무 프로세스가 없나요?

1. “다른 경기장은 들어갈 수 없네요. 게임이 멈춰요.” 오류는 대체로 이렇게 온다. 대답은 언제나 같다. “제가 한 번 해 볼깨요.” 2. 문제를 찾아가는 과정은 지리하지만 해결하고 나면 기분은 좋다. 그래서 아주 급한 일이 있지 않으면 문제 해결을 먼저 하려고 한다. 3. 첫번째 인덱스로 들어간 경기장에서는 죽지 않는데 다른 경기장만 들어가면 데디케이티드 서버가 죽어버린다. 데디케이티드 서버 로그를 보니 내가 해결하기 어려운 부분이라 클라이언트 프로그래머에게 부탁들 하고, 난 내 업무로 돌아왔다. 4. 한 두시간 쯤 후에 클라이언트 프로그래머가 와서 상황을 설명해줬다. 쉽게 이야기하면 다른 클라이언트 프로그래머가 경기장에 설정을 추가했는데 그 설정을 모든 경기장에 추가해줘야 정상 동작을 한다고 한다. 곤란…..해 졌다. 5. 곤란한 이유는 이걸 누가해야 하는지 안 정해져있다. [[ 프로그래머가 필요해서 추가 ]] - 이것을 맵 마다 추가해주는 것은 경기장 제작하는 그래픽 디자이너가 하나? - 데이터니까 기획자가 하나? - 프로그래머가 필요해서 추가했으니까 맵이 제작되면 프로그래머가 직접 해야 하나? 6. 대부분 팀에서 문제가 시작되는 지점이다. “제가 하겠습니다”라고 말하면 이 게임이 종료될 때까지 그 팀에서 이 일을 하게 될 것이다. ( 나를 위한 변명을 하자면 “내가 할께요”라고 말하기도 난감하다. 저 부분은 서버 프로그래머와는 전혀 관련이 없는 부분이라 여러모로 생뚱맞다. ) 7. 결국 난 문제 해결을 기획팀에 떠 넘기기로 했다. 기획을 불러 설명을 해 주고 이런 작업을 해 줘야 한다고 말을 한다. —> 기획자는 난감해 한다 (의도했던 바이다) —> 그래픽 디자이너를 불러서 함께 이야기해보자고 제안한다. 그래픽 디자이너에게 똑같이 다시 설명한다. 8. 결론은 해피엔딩. 그래픽 디자이너가 선뜻 자신이 하겠다고 이야기했다. 별 다른 문제없이 잘 마무리 됐다. 9. 회사에서 각 파트의 업무, 서로간의 햡업은 이렇게 만들어진다. 문제가 생기고, 원인을 찾고, 해야할 일이 만들어지고, 그 일을 누가 할 지 결정하고. 10. (1) 그래픽 디자이너가 경기장 모델링 완성 (2) 언리얼에 IMPORT하면서 필요한 설정 기본값으로 추가 (3) 기획팀에서 경기장 세부정보를 엑셀에 기록 (4) 엑셀 데이터를 XML로 뽑고 클라이언트에서 추가 코딩해줘야 하는 것 확인 (5) 맵 정보를 젠킨스에 추가해주고 클라이언트, 데디케이티드 서버 빌드. (6) XML 파일을 이용해서 DB 스키마와 쿼리 뽑아서 DB에 추가 (7) 게임서버 리로드 11. 경기장 추가 프로세스. 6단계에서 한 단계가 추가됐다. 한단계 한단계 추가될 때마다 하루가 날아가지만 이렇게 단계를 만들어놔야 나중에 경기장이 추가될 때 시간이 줄어준다. 12. 업무 프로세스는 이런식으로 만들어진다. 13. 업무 프로세스는 이미 존재하는 것을 따라가는게 아니다. 팀원의 노력과 협력으로 만들어가는 것이다. 이런 프로세스가 모여서 팀 문화가 되고 팀 문화가 모여 회사의 개성이 된다.