> 어제(글을 올리는 지금 기준으로는 지난주 목요일)는 야간 반영의 날이었습니다. 서비스가 하나 올라왔습니다.(개발쪽 생각을 하니, 출시라는 표현보다는 메모리에 올라온다. 개념이 강한 것 같네요

> 어제(글을 올리는 지금 기준으로는 지난주 목요일)는 야간 반영의 날이었습니다. 서비스가 하나 올라왔습니다.(개발쪽 생각을 하니, 출시라는 표현보다는 메모리에 올라온다. 개념이 강한 것 같네요.) ​ BA는 사업부서의 요구사항을 개발부서에 전달하다 보니 직접 개발을 하지 않습니다. 대신 요구사항을 IT 기능으로 분리하여 개발을 요청하게 되고, 요청한 사항이 잘 반영되었는지 테스트를 해야합니다. 늘 이것을 어떻게 테스트 할지는 고민인 것 같습니다. 서비스가 상용환경에 반영되고 버튼을 하나둘 눌러봅니다. 안되는 것이 있으면 "어딘가"에 적습니다. 이 "어딘가"가 큰 고민거리가 되는 것 같습니다. 그 어딘가에 대한/관련된 고민들을 나눕니다. 테스트한 결과는 이메일에 적습니다. 어느 탭, 어느 위치에 어떤 기능이 잘 작동 안합니다. 필요시에는 사진을 붙이고 URL도 넣습니다. 이내 쏟아지는 업무에 이메일은 사라지고, 다른 문제들로 확인이 되지 않습니다. 당장 당사자들이 봤는지 모를 때가 많습니다. ​ E-mail처럼 틀이 갖추어져 있지는 않지만 즉시 확인할 수 있는 장점이 있습니다. 개발자가 봤는지도 그때그때 확인할 수 있습니다. ​ Excel과 같은 Business Tool을 사용할 때도 있습니다. 좀더 형식화해서 쓴다는 것인데요. 보기에는 좋지만, 보안프로그램으로 암호화가 되면 개발 부서와 공유하기가 쉽지 않습니다. ​ 일정을 등록해서 업체에 Messenger로 번번이 알려주어야 합니다. ​ 너무 변수가 많아서 자동화툴은 생각조차 못합니다. 캐시 삭제를 해야한다던지, 캡차를 써야 한다던지 변수가 많습니다. ​ 그때 그때 형편에 맞추어서 툴을 사용하는게 맞는 것 같습니다. 전체 조직의 문화가 바뀌지 않는한 과거의 데이터를 참조 한다 던가의 행위가 없습니다. 과거에 그 서비스가 어떻게 출시되었고, 테스트는 진척이 어떻게 되는지 확인이 안되는 상황을 방지하려고 애쓸 것입니다. ​ 정말 훌륭한 조직 관리자라면 이런 산출물이 제대로 관리 안되는 것을 분명히 지적하여 관리해야할 것 같습니다. 그래야 관리를 하려고 하고, 관리를 하려면 통일이 필요하다는 것을 알게 될 것입니다. 그런데 ... 이또한 관리자가 바뀌면 변합니다. 지금 상태가 자연 상태라고 볼 수 있습니다. 그래서 ... 결국 소스 코드 이 자체에 집중해야 한다는 생각도 합니다. (서비스 입장에서는) 하지만, 관리의 영역(사업부서와의 의사소통)에 있어서는 "통일화된 저장 장소"는 반드시 필수적이라는 생각도 듭니다.