Допустим, команда разработки берет на поддержку новый проект — нужно исправлять ошибки в коде, восстанавливать работу приложений, если что-то упало.
ПМ требует, чтобы команда разработки отвечала на все вопросы клиента в течение часа. И в Skype, и в Jira. Тимлид понимает, что команда так не сможет — мало людей в команде.
Задачи тимлида:
понять причину запроса, легализовать запрос менеджера, зафиксировать договоренности.
💬Выясняем контекст
Обсуждаем для того, чтобы понять причину такого запроса. Например, проектный менеджер считает, что у разработчиков небольшая загрузка и искренне не понимает, чем команда занимается.
Легализуем запрос
Легализация — это когда мы ищем варианты как можно достичь желаемого и предлагаем решение. А не молча принимаем невыполнимую задачу. Часто все упирается в основные ресурсы — время и количество специалистов на проекте.
Ресурсов просим столько, сколько нужно для комфортной работы. Даже если вы уверены, что это тяжело выполнимо. Возможно, менеджер увидит решение, которое вам было не видно. Например, в другой команде временно освободились два разработчика — их можно подключить на помощь.
Если не хватает времени, то пробуем уменьшить задачу: неважное убираем, самые сложные части пытаемся облегчить.
Например, следить за задачами в Skype — нетиповая задача для нас, требует много сил на переключение между мессенджерами и перечитывания чата, чтобы понять был запрос от клиента или нет.
Сворачиваем задачу до типовой — просим оформлять все задачи в Jira. Разработчик экономит время и внимание — задача теперь описана явно, не нужно её где-то искать. Оформляет задачи сам клиент — опять же экономим время.
Фиксируем договоренность
Договоренность явно фиксируем ,письменно — в почте, например. Чтобы убедиться, что все поняли договоренность одинаково.
Пример предложения ПМу:
«Чтобы разработка отвечала на вопросы в течение дня, нам нужно нанять ещё двух человек. Мы уже ищем, но это займет не меньше двух месяцев.
Чтобы не терять задачи и все видели их статус, предлагаем создавать все задачи в Jira. Техподдержка может запросы и создавать тикеты?
Мы можем выделить одного разработчика чтобы он отвечал только на вопросы клиента. Но тогда скорость разработки снизится, и мы выпустим релиз на 3 месяца позже, а новые задачи брать не сможем. Мы бы хотели избежать этого варианта. Но если нет другого выбора, то давайте обсудим новые даты релизов».
Пример
Допустим, в понедельник тимлид просит разработчика исправить ошибку в приложении. Разработчик соглашается: задача большая — займет у вас минимум неделю, поэтому обещаете отдать результат в пятницу. Тимлид согласен на такой срок.
Во вторник тимлид просит срочно разобраться почему у клиента не работает приложение.
Возникает конфликт задач — в пятницу ждут релиз, а расследование проблемы оттянет релиз минимум на день.
❌ Если разработчик молча возьмется за расследование: то тимлид не поймет, что будет задержка релиза. А разработчику либо обидится на требование релиза в пятницу (“ну это же было очевидно, что релиз перенесется — я же расследовал проблему”), либо начнет перерабатывать, пытаясь успеть к сроку по всем задачам — выдохнется и следующую неделю не сможет продуктивно работать.
✅ Хороший вариант:
Разработчик пытается понять причину срочности расследования. И почему эту задачу должен делать именно он. Может оказаться, что у тимлида просто нет времени разбираться в срочности задачи. Тогда можно предложить обсудить с проектным менеджером.
Легализует — предлагает тимлиду варианты:
“если взять расследование сейчас, то срок релиза перенесется минимум на день — будет не раньше понедельника. Но расследование может затянуться.
Давай или отдадим задачу кому-то другому, или перенесем релиз?
Если помочь с расследованием некому, то давай я возьмусь, а в конце дня напишу тебе — я завтра вернусь к релизу или нужно будет еще время на расследование. Тогда и решим что сделать.
Что думаешь?”.
Если тимлид согласен, то отписываем в почту или в Slack (неважно где, главное, чтобы было письменно зафиксировано и оба увидели сообщение). Получаем согласие тимлида и приступаем к расследованию. Вечером созваниваемся.
Пара советов
- Не стоит идти на принцип — «мы так не можем и не обсуждается/это не наши проблемы — сами разбирайтесь». Пойти на принцип — явно войти в затяжной конфликт. Менеджер все еще будет недоволен. Возможно, что обиженный менеджер будет неосознанно саботировать вашу работу, не будет идти навстречу, когда нужна будет его помощь.
- Не соглашайтесь обрабатывать некоторые вопросы мимо процесса. Типа «вообще, мы сначала обрабатываем только критические инциденты, которые блокируют бизнес клиента. Но, то что вы просите мы будем обрабатывать вне очереди». Мимо процесса — значит тимлид будет вынужден вручную проводить задачи по процессу. Процесс не масштабирует — тимлид в отпуске и все остановилось. Потом ещё и другие ПМ будут стараться двигать свои задачи вне очереди — тогда конфликтом интересов будет трудно управлять.
- Фиксируйте договоренность — не должно быть так, что «поговорили и разошлись». Потом все забудут или окажется, что кто-то неправильно понял договоренность. Можно выслать письмо на участников процесса — разработчики, проектный менеджер.
- Не стесняйтесь напоминать о договоренностях: если договорились, что клиент сам создает задачи в Jira, то просите, чтобы проектный менеджер это явно с клиентом проговорил. Если вам обещали, что откроют вакансии, чтобы нанять еще людей — спрашивайте “когда?”, каждый раз возвращайтесь. Если сроки постоянно переносят — передоговаривамся.