우선순위를 끊임없이 고민하기
그리고 배포 이후 달라지는 게 무엇인지 미리 확인하기
얼마 전 한 프로젝트의 막바지 업무를 빠듯한 타임라인 내에서 끝냈다. 조금이라도 시간을 낭비할 수 없었기에 며칠 되지 않는 시간이더라도, 타임라인을 굉장히 촘촘하게 짜야했고, 데일리 단위의 타임라인이 아니라 몇 시간 단위의 타임라인을 설정했다. 촉박한 타임라인 속에서 프로젝트를 마무리하며 가장 크게 느낀 것 두 가지를 써본다.
천성이 계획과는 거리가 멀어서, 계획이나 일정을 잡는 게 아직도 쉽지는 않다. 더구나 조직 내에서의 계획은 리스크, 예상 결과, 리소스 등을 고려해야 하니 더더욱. 별 다른 방도는 없다고 느낀다 일정, 계획에 대한 연습을 계속 연습하는 수밖에.
우선순위를 끊임없이 고민하기
조직 차원에서 일정이나 마일스톤이 변경될 때 가장 먼저 고려해야 하는 것은 중 하나는 바로 우선순위다. 일정이나 계획, 마일스톤의 변경은 예고를 하고 다가오지 않는다. 보통 어느 순간 갑자기 훅 하면서 다가온다. 그럴 때 가장 먼저 해야 하는 건 우선순위에 대한 확인이다.
기존에 설정한 우선순위가 유효하기 때문에 기존 업무를 그대로 진행해도 되는지, 아니면 우선순위가 뒤바뀌었기 때문에 우선순위와 이에 따른 계획, 또 계획에 따라오는 할 일을 변경해야 하는지를 확인해야 한다. 보통 일정이나, 계획이 바뀌면 우선순위가 바뀌는 경우가 상당히 많다. 그래서 조직 차원에서의 일정이나 마일스톤이 변경되면 우선순위에 대한 변경을 가장 먼저 신경 써야 한다.
데드라인은 똑같은데, 조직 차원에서의 일정과 계획, 마일스톤이 바뀌었다고 기존 업무에 더해서 새로운 업무만 늘어난다면, 구성원들은 지치고 부정적인 반응을 내비칠 수밖에 없다. 따라서 기존 업무보다 우선하는 새로운 업무가 생긴다면, 새로운 업무와 기존 업무에 대한 데드라인을 다시 정해야 한다.
새로운 업무로 인해 밀리는 기존 업무가 있으면, 얼마나 밀리는지를 확인해야 한다. 또 얼마나 밀리는지 확인했다면, 또 상위 레벨과 함께 이 정도까지 밀려도 괜찮은지를 확인해야 한다. 반대로 상위 레벨에서 우선순위가 높은 새로운 업무를 전달하면서, 기존 업무는 언제까지 밀려도 괜찮다는 이야기를 할 수도 있다. 이런 경우에는 새롭게 설정된 업무의 데드라인과 기존 업무의 데드라인을 명확하게 구성원들에게 설명할 수 있어야 한다.
때로는 이런 우선순위 및 데드라인, 그리고 이에 따른 업무의 달성 여부를 분기, 월 단위가 아니라 일 혹은 시간 단위로 체크해야 하는 경우도 있다. 너무 마이크로 매니징을 하는 느낌이라 이렇게 일 단위로까지 내려와서 체크하는 걸 별로 좋아하지는 않는다. 다만 경험이 많지 않은 구성원들과 함께 일하는 경우 혹은 중요한 마일스톤이 있을 경우 등 이렇게 디테일하게 체크를 해야 하는 경우가 발생할 수 있다. 이런 경우가 나오지 않는 게 최선이겠지만, 이런 상황에서는 반드시 체크를 해줘야 한다.
배포 전, 어떤 부분을 확인할지 명확하게 정리하기
IT 프로덕트에 변화가 생기거나 업데이트를 하는 경우, 내부적으로 반드시 필요한 절차가 하나 있는데 바로 배포다. 배포 없이는 어떠한 변화도 일어나지 않는다. 배포를 디테일하게 나눠보면 이미지 변경, 마이그레이션 등등이 있다. 비개발자 입장에서 이미지 변경, 마이그레이션 등등은 아직도 어려운 개념이지만, 중요한 것은 배포 이후 프로덕트에 변화가 생긴다는 것이다.
IT 프로덕트는 배포 전과 배포 후로 나뉜다. 예를 들어서 배포 전에는 공유 기능이 없었는데, 공유 기능을 개발하고 이를 배포한 뒤 공유 기능이 만들어지는 식이다. 공유 기능을 만들었다고 하더라도 배포를 하지 않으면 실제 유저들은 공유 기능을 사용할 수 없다. 한마디로 배포는 신규 기능이나, 기능 변화 등을 적용하는 과정이라고 할 수 있다.
배포가 끝나면, 프로덕트에 변화가 생긴다. 즉, 배포 이후 프로덕트에 변화가 잘 적용이 되었는지 문제가 없는지를 확인해야 한다는 것이다. 프로덕트가 문제없이 잘 변화되었는지, 다른 예상치 못한 이슈는 없는지 빠른 시간 안에 확인하기 위해서는 사전에 QA 시트 혹은 체크리스트를 작성하고 이를 공유해야 한다. 사전에 배포 이후 체크리스트를 작성하기 위해서는, 각 작업자들이 어떤 부분을 작업하고 있고, 유저 입장에서 어떤 부분이 바뀌는지를 확실하게 알고 있어야 한다.
사전에 체크리스트를 확실하게 만들고, 배포가 끝난 후, 체크리스트를 보면서 배포가 잘 되었는지를 확인해야 문제가 있어도 빠르게 대처할 수 있다. 만약 체크리스트 없이 배포가 끝나고 잘 되었겠지 하고 넘어가는 경우, 문제가 없다면 다행이지만, 나중에 문제를 발견하면 해결하기가 훨씬 더 어려워진다. 체크리스트에 기반해 배포 직후 문제가 있는지 없는지 여부를 확인한다면, 더 빠르게 더 적은 리소스로 문제를 해결할 수 있다. 롤백을 한 다음 다시 문제를 해결할 수도 있고, 핫픽스를 올려서 문제가 되는 부분을 빠르게 고칠 수도 있다.
따라서 배포가 예정되어 있다면, 사전에 배포 이후 어떤 부분을 체크할지 명확하게 정리해야 한다. IT 프로덕트에서 프로덕트가 끝나지 않는 한 배포는 계속된다. 따라서 배포 전 체크리스트를 만드는 일은 계속해서 해나가야 한다. 배포 전 체크리스트 작성, 배포, 배포 후 체크리스트 확인이 배포와 관련한 하나의 작은 사이클이다.
