14 заметок с тегом

Управление проектами

Как не проваливать дедлайны

У нас remote-frst команда. Remote-first — это когда офис/коворкинг по желанию, а изначально мы ориентируем, что работа будет удаленной. Remote-first держится на ответственности и сдерживании обещаний.

Про ответственность я уже много раз писал (и буду писать), сегодня хочу поговорить про дедлайны. У нас сотрудники самостоятельно выбирают дедлайны для задач. Потому что именно они обещают клиенту сделать определенные задачи к какому-либо времени. И срыв дедлайнов крайне редкое событие в компании. Сейчас расскажу каким правилам мы придерживаемся, чтоб не срывать дедлайны.

  1. Всегда можно передоговориться. Иногда что-то случается, и становится понятно, что дедлайн не будет соблюдён. В таком случае мы стараемся как можно раньше передоговориться с клиентов. Если времени до дедлайна останется немного, то можем ограничить функционал задачи или её объем. К примеру, делаем анализ конкурентов, и первой итерацией только 3-5 основных конкурентов, а второй всех остальных. Это важно, потому что наш ЛПР тоже мог кому-то пообещать показать нашу работу.
  1. Создаем внутренние дедлайны. Чтоб не делать всё в последний день, мы создаем внутренние дедлайны. Дизайнеры готовят креативы к такому числу, мы готовим посадочные к такому числу. А в такой то день согласовываем с клиентом. В идеале если после всего этого еще остается 2 дня, если что-то пойдет не так.
  1. Создаем буфер. Это от 2 до 6 часов в неделю, которые отводятся для срочных задач или если что-то пойдет не так. Если срочных задач нет, то делаем что-то сверху.
  1. Еженедельная встреча с клиентом. Сложно говорить клиенту, что ты не сделал какую-то задачу. Еженедельная встреча с клиентом для нас обязательна. Там мы обещаем клиенту что-то сделать на следующую неделю. И через неделю отчитываемся о проделанной работе с результатами в цифрах.
  1. Дедлайн от согласования. Если для выполнения задачи нужно согласования третьего лица, то мы делаем плавающий дедлайн от дня согласования. К примеру, мы подготовим КП за неделю, после того как получим доступы в рекламные кабинеты и метрику от вас.

А вы что делаете, чтоб не срывать дедлайны?

Почему мы указываем проект или имя вначале документа, письма, задачи

В IT-Agency есть правило, мы всегда вначале документа пишем проект или имя. Этот «тег» показывает про кого этот документ.

Аналогично поступаем и для email, чатов и задач. К примеру:

yandex.ru: Еженедельный план-факт за 08.07.2024 — 14.07.2024
Антон Рожков: заявление на отпуск с 08.07.2024 — 14.07.2024
yandex.ru: подготовить ретаргетинговые аудитории по недошедшим до продажи клиентам

Это сильно упрощает, сразу видно про какой проект документ. Гораздо легче искать документ в поиске Google Drive или Yandex Disk или письмо в почтовом ящике.

16 дн   IT-Agency   Управление проектами

Почему не нужно вводить трекинг времени насильно

Я застал еще времена, когда трекинг времени был обязательным в IT-AGENCY. В те времена, отделы «продавали» своё время. Поработал больше часов → заработал больше.

Сейчас мы продаем команды, людей и трекинг времени стал обязательным только для внештата. Если взялся сделать задачу к Y дню — делай, а за сколько часов ты её сделаешь — вторично.

Для младших и мидлов я рекомендую самостоятельно следить за своим временем. Это помогает натренировать насмотренность. Сколько может занимать та или иная задача? А можно ли как-то оптимизировать выполнение этой задачи?

Но вот самая главная причина:
Когда мидл станет старшим, одной из задач по старту нового проекта будет разработка гантта. Выполнять работу по запуску проекта будут мидлы и младшие. Если ты не трекал сам своё время, то как ты поймешь сколько времени займет запуск проекта у мидла и младшего?

Заставлять трекать время — это микроменеджмент. Рекомендовать трекать время — основа для роста для самого специалиста.

Ранее Ctrl + ↓