У интернет-магазина перестала проходить оплата. Заказчик написал руководителю, тот перенёс обращение в чат проекта и отметил доступного разработчика. Исполнитель нашёлся, оплату восстановили.
Так Вячеслав Коэн из UserTech описывает один случай в своей команде. Разбираем, что помогло передать задачу конкретному человеку и где нужен запасной порядок, если он не ответит.
Вечернее сообщение, рабочие часы разработчика
По рассказу Вячеслава Коэна, сбой обнаружили вечером после планового обновления WordPress, примерно за месяц до нашей переписки. Прежде чем отметить разработчика в чате, руководитель посмотрел его доступность в CRM — системе, где команда учитывает работу.
У разработчика эти часы были обозначены как рабочие. Он сотрудничал с командой как подрядчик, сообщил Вячеслав Коэн. Вечернее обращение попало в часы, когда исполнитель сам планировал быть доступным. Считать это историей о вызове человека в его свободное время было бы неточно.
В начале каждой недели программист сообщает, в какие часы он сможет подключаться к задачам. Мы ориентируемся на этот график при распределении работы. Обычно задачи плановые, но иногда возникают и аварийные ситуации, требующие оперативного вмешательства.
Вячеслав Коэн рассказал, что разработчик подключился, восстановил оплату, затем внёс в CRM затраченное время и выполненные работы. По его словам, в заранее обозначенные рабочие часы повышенная ставка не применяется. В описанном случае работа пришлась именно на такие часы.
Случай описан со слов руководителя команды. По этому рассказу нельзя определить правовой статус отношений и соблюдение требований закона.
Доступен — значит уже взял задачу?
Календарь помог найти человека, которому можно передать обращение. Но отметка о доступности и подтверждение конкретной задачи — разные вещи. Из сообщения в общем чате ещё не видно, кто приступил к исправлению.
Здесь полезно разделить две роли: кто ищет исполнителя и кто берётся за сбой. В описанном случае первым был руководитель, вторым — разработчик. Если договариваться о такой схеме заранее, стоит определить, каким сообщением исполнитель подтверждает, что подключился. До этого подтверждения человек, распределяющий задачи, будет знать, что передачу ещё нужно завершить.
В ответе Вячеслава Коэна есть существенная оговорка. Он пишет, что договор не предусматривает наказания за отсутствие ответа, и добавляет:
Однако если бы сотрудник без объяснения причин отсутствовал онлайн в часы, которые сам обозначил как доступные, это стало бы поводом пересмотреть формат сотрудничества.
Слово «сотрудник» сохранено из ответа; выше Вячеслав Коэн назвал разработчика подрядчиком. До выбора часов полезно выяснить, что означает доступность: возможность написать, обязанность следить за обращениями или готовность начать работу. Это условие вашей договорённости, а не то, что можно установить по одному статусу «онлайн».
Кто подхватит задачу, если первый не ответил
В описанном случае свободный разработчик нашёлся. Вячеслав Коэн также объяснил, как команда, по его словам, действовала бы при его недоступности:
Если бы сотрудник не ответил, мы сначала попробовали бы подключить другого программиста, который в этот момент работает. Если таких специалистов нет, обратились бы к тем, кто находится онлайн, но не планировал работать в это время. За срочное подключение предусмотрена дополнительная оплата, и, разумеется, всё происходит добровольно, без принуждения.
Так руководитель описывает принятый порядок. Вячеслав Коэн уточнил, что критического сбоя, при котором никто не мог бы подключиться, у них пока не было.
Здесь остаётся вопрос: что делать, если исполнителя нет? В таком случае руководителю или другому назначенному человеку придётся решить, кого ещё можно привлечь и что сообщить заказчику. Пересылка обращения в общий чат сама по себе не отвечает ни на один из этих вопросов.
Как передать задачу и не потерять её по дороге
Ниже — схема для обсуждения в проектной команде. Это предложение редакции, не восстановленная переписка UserTech. Она помогает проверить именно передачу задачи: кто за неё отвечает на каждом этапе.
Один человек принимает обращение заказчика, выясняет, что перестало работать, и ищет доступного исполнителя. Понятно, кто держит связь с заказчиком, пока разработчик ещё не подключился.
Разработчик сообщает, что берёт задачу, и когда вернётся с первым результатом проверки. Подтвердить начало работы можно раньше, чем станет известен срок исправления.
По истечении заранее согласованного времени назначенный человек ищет замену. Если подключиться некому, он сообщает заказчику о задержке и договаривается о следующем обновлении, не обещая неподтверждённый срок ремонта.
Исполнитель сообщает, что сделал. В команде заранее определено, кто проверит результат и подтвердит заказчику восстановление работы. Время и выполненные действия фиксируют для согласованного расчёта.
Если речь о подключении вне заранее обозначенных рабочих часов, доплату стоит подтвердить до начала работы: размер или способ расчёта и кто её согласует. Одного обещания «оплатим срочность» для понятного расчёта недостаточно.
Пример редакции для обсуждения условий, не цитата эксперта
«Как я подтверждаю, что взял срочную задачу? Если подтверждения от меня нет, через какое время вы ищете замену? И кто всё это время отвечает заказчику?»
Профессиональные сведения Вячеслава Коэна — в профиле собеседника.
