작업과 승인이 있는 요청

“새 동료가 출근합니다”는 티켓 하나가 아닙니다. 노트북 한 대, 계정 두 개, 내선 번호 하나, 어쩌면 외부 접근 권한까지 뜻합니다. 각 조각은 다른 팀에 속하지만, 진행 상황을 알려 주는 사안 하나는 여전히 필요합니다.

그것을 위한 것이 요청입니다. 요청은 접수되는 순간 자기 작업을 만드는 티켓이며, 각 작업은 그 일을 맡는 팀에서 자기 티켓이 됩니다.

요청은 따로 관리해야 하는 두 번째 물건이 아닙니다. 티켓 템플릿 위에 얹혀 있습니다. “Settings → Request workflows”에 모든 티켓 템플릿이 있고, 그중 하나에 작업을 붙입니다.

작업마다 칸 몇 개를 채웁니다. “Task”는 요청자가 읽는 이름이고, “Handled by”는 그것을 받는 팀입니다. “Ticket title”과 “What the team has to do”는 그 작업에서 나오는 티켓을 채웁니다.

작업 여러 개가 같은 팀을 가리켜도 됩니다. 그러면 그 팀은 항목이 여럿 적힌 티켓 하나가 아니라 티켓 여러 개를 받습니다.

팀이 없는 작업은 아예 제시되지 않습니다. 칸에 그렇게 적혀 있습니다. “Not assigned yet — this task is not offered”. 그래서 아직 완성되지 않은 계획도 저장할 수 있습니다.

작업 위에 계획 전체를 요약하는 문장이 있습니다. 기본값으로 무엇이 만들어지는지, 요청자가 얼마나 바꿀 수 있는지, 누가 승인하는지를 말합니다. 설정을 바꾸면 문장도 다시 쓰입니다.

“Ticket title” 앞에는 고정 문구 “Parent ticket title -”가 있습니다. 새 티켓은 요청의 제목으로 시작하고, 그 뒤에 입력한 제목이 이어집니다. 예를 들어 “New colleague in accounting - Set up notebook and docking station”처럼 됩니다. 그래서 전문 팀은 작업이 어느 요청에 속하는지 알 수 있습니다. 칸을 비워 두면 그 대신 작업 이름이 이어집니다.

“Main category”와 “Subcategory”는 새 티켓의 카테고리를 미리 채웁니다. “Handled by”에 있는 팀의 카테고리만 나옵니다. 티켓이 그 팀에서 만들어지기 때문입니다. 팀을 바꾸면 두 칸이 모두 비워집니다. 둘 다 정하거나 둘 다 정하지 않습니다. 비어 있으면 티켓은 카테고리 없이 만들어집니다.

요청의 이름은 작업 위에 있습니다. 옆에 있는 연필로 이름을 바꿉니다. 이 이름은 티켓 템플릿에 속하므로 “Settings → Templates”와 새 티켓 양식에서도 바뀝니다.

새 티켓 양식에서 템플릿을 고르면 “What is needed?” 상자가 나타나고, 작업마다 고를 수 있는 줄이 하나씩 생깁니다.

방식은 세 가지이며 작업마다 정합니다. “Selectable, off by default”는 비어 있는 상태로 시작하고, “Selectable, on by default”는 선택된 상태로 시작하며 해제할 수 있고, “Always — cannot be deselected”는 언제나 실행됩니다.

언제나 실행되는 작업도 “(always included)” 표시와 함께 보여 줍니다. 어차피 일어날 일이라도 요청자가 알아야 하기 때문입니다.

상자 아래에 무엇이 만들어질지 적혀 있습니다. “Each selected item becomes its own ticket for the team that handles it.”

템플릿이 고객에게 공개되어 있으면 고객도 요청을 낼 수 있습니다. 그 스위치는 템플릿에 있습니다.

그때 고객에게는 자기 요청만 보입니다. 그 요청이 만든 것이라도 전문 팀의 티켓은 보이지 않습니다. 그 티켓에는 접속 정보와 내부 메모가 들어 있기 때문입니다. 그 티켓의 내부 메모는 요청의 이력에도 나타나지 않습니다. 전문 팀이 자기 티켓을 닫으면 그 첨부 파일은 “Internal” 배지를 달고 요청으로 복사되며, 고객은 보지도 내려받지도 못합니다.

요청이 이메일로 들어오면 보통 티켓이 됩니다. 그러면 워크플로를 나중에 시작합니다. 이때 티켓 머리글에 있는 “Start workflow” 단추를 씁니다.

대화 상자의 “Template”에서 알맞은 템플릿을 고릅니다. 그 아래에 새 티켓 양식과 같은 “What is needed?” 상자가 나타납니다. 요청에 적힌 것을 고릅니다.

“Title”에서 티켓 제목을 고칩니다. 작업 제목은 이 제목으로 시작합니다. 그 아래에 템플릿의 추가 항목이 있습니다. 거기에 요청의 내용을 입력합니다. 필수 항목에는 별표가 붙어 있습니다.

“Start”를 누르면 양식에서 낸 요청과 똑같이 작업이 만들어집니다. 템플릿에 승인이 필요하면, 승인이 날 때까지 티켓과 그 작업은 잠겨 있습니다.

티켓 하나에는 워크플로를 하나만 시작할 수 있습니다. 시작하고 나면 단추가 사라집니다. 닫힌 티켓과, 그 자체가 작업인 티켓에도 이 단추는 없습니다. 티켓을 처리할 수 있는 사람이면 누구나 시작할 수 있습니다.

요청 자체에서는 작업이 “Workflow tasks” 아래에 나열되고 옆에 개수가 적힙니다. 예를 들어 “1 of 4 done”처럼 나옵니다.

각 줄에 작업 이름, 그 티켓의 번호, 팀, 담당자가 보이며, 이름을 누르면 그 티켓으로 갑니다.

“완료”는 별도의 표시가 아니라 티켓의 상태에서 나옵니다. 티켓 목록에서 닫힘으로 치는 것이 여기서도 완료입니다. 같은 것을 두 가지로 세면 언젠가는 어긋나기 때문입니다.

이 묶음은 요청에만 나타납니다. 보통 티켓에는 나오지 않습니다.

전문 팀이 자기 티켓을 닫으면 그 “Closing comment”가 요청에 들어옵니다. 요청에서는 내부 메모로 나타나며, 첫 줄에 작업의 번호와 이름이 적힙니다. 고객은 이 메모를 보지 못합니다.

접속 정보와 요청 담당자가 전달해야 할 모든 것은 종료 댓글에 적습니다. 전문 팀의 다른 댓글은 모두 그 팀의 티켓에 남습니다. 팀이 댓글 없이 닫으면 메모는 만들어지지 않습니다.

승인은 개별 작업이 아니라 요청 전체를 다룹니다. 애플리케이션 여덟 개를 요청해도 부서장에게 가는 메일은 여덟 통이 아니라 한 통입니다.

같은 계획의 “Approvals”에서 설정하며, 그 위의 문장이 규칙을 말합니다. “One approval covers the whole request. Add a second stage only when single tasks need their own release.” 단계마다 칸이 다섯 개 있습니다. “Name”은 단계의 이름, “Covers”는 무엇에 적용되는지, “Decided by”는 승인자가 어디서 오는지, “Approver”는 그 사람, “Remind after (hours)”는 재알림을 정합니다.

승인자에게 티켓 시스템의 계정은 필요 없습니다. 이메일 주소를 넣으면 링크로 결정합니다. 분기에 두 번 승인하는 부서장 때문에 담당자 자리를 쓸 일이 없습니다.

메일에는 페이지로 가는 링크가 정확히 하나만 들어 있습니다. 메일 안에 승인 단추나 거절 단추를 일부러 두지 않았습니다. 모든 링크를 열어 보는 바이러스 검사기가 대신 승인해 버리기 때문입니다.

그 페이지의 제목은 단계 이름입니다. 요청의 번호와 제목, 요청자, 그리고 “This decision covers” 아래에 이 결정이 다루는 작업이 보이며, 그 아래에 의견 칸과 단추 두 개가 있습니다.

링크는 영원히 살아 있지 않으며, 페이지에 기한이 적혀 있습니다. “Please decide by …” 유효 기간은 14일입니다. 그 뒤에는 페이지에 링크가 무효이거나 만료되었다는 말만 나오며, 관리자가 “Reassign”으로 요청을 다시 보냅니다.

결정은 되돌릴 수 없으며, 결정 뒤에 페이지가 그렇게 알려 줍니다. “A decision cannot be changed.”

어떤 작업에는 별도의 승인이 필요합니다. 외부 접근 권한은 노트북과 같은 일이 아닙니다.

그럴 때는 두 번째 단계를 추가하고 작업의 “Extra approval”에서 그것을 고릅니다. “None — the request approval is enough”로 되어 있는 동안에는 요청 승인만으로 충분합니다. 두 단계는 차례로가 아니라 동시에 요청됩니다. 단계는 고른 작업 가운데 하나라도 그 단계에 관계될 때만 요청됩니다. 요청 전체에 대한 단계는 항상 요청됩니다.

작업은 그것에 관계된 모든 단계가 동의해야 풀립니다. 자기 단계가 없는 작업은 곧바로 시작되지만, 요청 전체에 대한 단계가 아직 기다리는 중이면 예외입니다. 그때는 요청이 승인되는 즉시 시작됩니다.

그때까지 그 작업은 잠겨 있습니다. 티켓은 “Waiting for approval” 상태이고 담당자가 없습니다. 카드에는 상태 단추 대신 “This ticket is waiting for approval and cannot be worked on yet.”라고 적혀 있습니다. 그전에는 어떤 경로로도 담당자가 정해지지 않습니다.

이 잠금은 티켓 목록의 일괄 작업에도 그대로 적용됩니다. 거기서 그런 티켓을 고르면 이유가 나옵니다. “This ticket is waiting for approval and cannot be worked on yet.”

그래도 티켓은 곧바로 만들어집니다. 그래야 전문 팀이 무엇이 올지 보고, 아무도 요청을 지켜보고 있을 필요가 없습니다.

단계마다 재알림을 시간 단위로 정할 수 있습니다.

답이 오지 않으면 그 시간이 지난 뒤 같은 메일이 다시 나가며, 처음과 같은 링크가 들어 있습니다. 첫 메일을 갖고 있는 사람은 그것을 그대로 써도 됩니다.

재알림을 두지 않으면 요청은 다시 묻지 않고 그냥 기다립니다.

없는 것은 시간이 지나면 자동으로 승인되는 기능입니다. 칸 아래에 그대로 적혀 있습니다. “A request is never approved automatically. If nobody reacts, it keeps waiting.” 스스로 동의해 버리는 기한은 승인이 아니라 형식일 뿐입니다.

거절하려면 사유를 적어야 합니다. 사유가 없으면 페이지가 거절을 받지 않습니다.

칸에 그 글이 어디로 가는지 적혀 있습니다. “Comment (required when you reject — the requester will see it)”. 내부 메모를 여기에 적으면 안 됩니다.

요청자는 사유가 담긴 메일을 받으므로 왜 진행되지 않는지 물어볼 필요가 없습니다.

승인에는 사유가 필요하지 않습니다. 예상되는 결과이기 때문입니다.

두 번째 단계만 거절하면 그 거절은 그 단계의 작업에만 미칩니다. 요청의 나머지는 계속 진행됩니다.

거절된 작업은 “Rejected” 상태가 되고 끝난 것으로 셉니다. 그래야 요청이 결코 오지 않을 것을 기다리며 매달려 있지 않습니다.

요청이 거절되면 다른 승인자에게는 더 이상 메일이 가지 않습니다. 그들의 링크에는 “This request has already been rejected. Your decision is no longer needed.”라고 나옵니다. 티켓의 목록에서는 그 단계에 “No longer needed: the request was rejected.”라고 표시됩니다.

요청의 “Approvals”에는 단계마다 한 줄씩 승인자와 상태가 보이며, 아직 열려 있는 요청에는 얼마나 기다렸는지도 함께 나옵니다.

결정한 뒤에는 그 줄에 언제 어떤 의견과 함께 결정했는지가 보입니다. 그것이 감사 기록이며 사안에 남습니다.

승인자가 휴가 중이면 관리자가 요청을 다른 주소로 옮깁니다. 단추 이름은 “Reassign”이며 요청이 열려 있는 동안에만 나타납니다.

이것은 관리자만 할 수 있습니다. 담당자가 옮길 수 있다면 자기에게 옮긴 다음 스스로 결정할 수 있게 됩니다.

옮기면 새 링크가 만들어지고 이전 링크는 즉시 죽습니다. 누군가 전달했더라도 마찬가지입니다.

옮긴 일 자체도 같은 목록에 남습니다. 누가 언제 누구에게서 누구에게로 옮겼는지가 적힙니다.

누구도 다른 사람의 이름으로 결정할 수 없습니다. 링크가 유일한 길이며, 누가 그것을 받았는지가 사안에 기록됩니다.