Запити із завданнями та погодженням

«Виходить новий колега» — це не одна заявка. Це ноутбук, два облікові записи, телефонний номер і, можливо, доступ ззовні. Кожна частина належить іншій команді, і ви все одно хочете мати одну справу, яка каже, на чому все стоїть.

Саме для цього є запит. Це заявка, яка створює свої завдання тієї миті, коли її подано, і кожне завдання стає окремою заявкою в команді, яка ним займається.

Запит — це не друга річ, яку треба вести. Він живе на шаблоні заявки: під «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» і з'являється лише поки запит відкритий.

Робити це може лише адміністратор. Оператор, який міг би перепризначати, зміг би перепризначити на себе й потім вирішити.

Перепризначення створює нове посилання, а старе вмирає одразу — навіть якщо його хтось переслав.

Саме перенесення з'являється в тому самому списку: хто переніс, коли, від кого й кому.

Ніхто не може вирішувати від чужого імені. Посилання — єдиний шлях, і те, хто його отримав, записано у справі.