Лапаев Иван 
Тендеры и лиды
Информация
«Нужно срочно. Просто подвиньте остальные задачи».
Фраза знакомая почти любой команде, где одни и те же разработчики, тестировщики, дизайнеры или аналитики работают сразу над несколькими проектами.
Проблема обычно не в самой срочной задаче. Иногда она действительно важнее всего остального.
Проблема начинается в момент, когда новый приоритет меняют в одном месте, а последствия для остальных проектов остаются невидимыми.
Разработчик переключается на два дня. Основная задача сдвигается. Тестировщик к новому сроку уже занят другим проектом. Следующий специалист тоже недоступен.
В итоге двухдневное переключение может обернуться заметно большим переносом запуска.
А менеджер узнаёт об этом не тогда, когда приоритет изменили, а на следующей планёрке.
Именно поэтому при работе нескольких проектов на общей команде недостаточно просто определить, что сейчас важнее.
Нужно понимать: что произойдёт с остальным планом, если мы действительно поставим этот проект первым?
Представим ближайшие десять рабочих дней.
Три проекта рассчитывают на одного backend-разработчика:
проекту А нужно 5 дней;
проекту Б — 4 дня;
проекту В — 3 дня.
Каждый менеджер строит свой план отдельно.
У проекта А всё сходится.
У проекта Б тоже.
У проекта В — никаких проблем.
Но вместе проекты требуют 12 рабочих дней одного человека при доступных десяти.
Конфликт существует уже сейчас, хотя внутри каждого проекта план выглядит реалистично.
Именно здесь часто возникает иллюзия контроля.
Карточки заполнены. Сроки стоят. Диаграмма Ганта построена. У каждого проекта назначены исполнители.
Но один и тот же день специалиста оказался обещан сразу нескольким менеджерам.
Сам по себе высокий приоритет эту проблему не решает.
Он только отвечает на вопрос: кто получит дефицитный ресурс первым?
Если проект А становится самым важным, это означает не только «А идёт первым».
Это одновременно означает: Б начнётся позже. В, скорее всего, тоже сдвинется.
То есть изменение приоритета — это изменение расписания.
Теперь представим другой сценарий.
Разработчик работает над основной задачей. До передачи на тестирование осталось три дня.
Появляется срочное исправление, и разработчика переключают на него на два дня.
На первый взгляд последствия очевидны:
+2 дня к сроку.
Но после этих двух дней разработчик заканчивает основную работу позже первоначального плана.
Тестировщик, который должен был принять задачу, к новой дате уже занят другим проектом.
Освободится он только через несколько дней.
После тестирования работу должен забрать ещё один специалист — и его расписание тоже изменилось.
В результате двухдневное переключение разработчика может дать совсем не двухдневный перенос запуска.
Проекты при этом даже не обязаны быть технически связаны.
Их связывают люди.
Один backend-разработчик заканчивает работу в проекте А и должен перейти в проект Б.
Один тестировщик участвует в трёх инициативах.
Один аналитик нужен сразу нескольким менеджерам.
Поэтому локальное решение внутри одного проекта способно изменить сроки совершенно другого.
У каждого проекта обычно есть убедительная причина быть важным.
У одного — обязательство перед клиентом.
У второго — релиз, который уже обещали руководству.
У третьего — проблема в продакшене.
У четвёртого — зависимость другой команды.
В итоге в трекере появляется несколько задач с высоким приоритетом.
Но исполнитель всё равно не может выполнять их одновременно.
Если общей очереди нет, её начинают заменять договорённости.
Кто-то написал раньше.
Кто-то эскалировал вопрос руководителю.
Кто-то попросил «буквально на пару часов».
Кто-то просто оказался настойчивее.
Получается странная ситуация: формально приоритетами управляет компания, а фактически — коммуникация между отдельными людьми.
При этом последствия нового решения для остальных проектов остаются за пределами разговора.
Особенно неприятно, что со стороны такая система может выглядеть вполне продуктивной:
Люди заняты.
Задачи закрываются.
Каждую неделю что-то выпускается.
Но менеджеру всё сложнее ответить на простой вопрос: что мы действительно успеем до конца квартала?
Чтобы назвать срок, приходится собирать информацию вручную:
Спросить разработчика.
Проверить, когда освободится тестирование.
Уточнить состояние соседнего проекта.
Посмотреть отпуска.
Проверить, не появился ли новый срочный запрос.
Пока сведения собираются, часть из них уже успевает измениться.
Постепенно происходят ещё три вещи.
Каждый менеджер считает, что специалист должен продвигать именно его проект.
Человек переключается между задачами, вспоминает контекст, возвращается обратно.
Если срок регулярно меняется без понятной связи с конкретным решением, доверие к плану падает.
Следующий срок уже воспринимается не как обязательство, а как пожелание.
Проекты без настойчивого внутреннего заказчика проигрывают тем, вокруг которых постоянно возникает давление.
Через квартал команда может обнаружить, что сделала очень много работы, но почти не продвинула то изменение продукта, которое собиралась реализовать изначально.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13801 тендер
проведено за восемь лет работы нашего сайта.
Можно идеально вести карточки.
Можно регулярно обновлять статусы.
Можно построить красивую диаграмму Ганта.
И всё равно обещать время одного человека нескольким проектам одновременно.
Проблема здесь не в отсутствии информации о задачах.
Не хватает общего расписания ограниченных ресурсов.
Чтобы понять, выполним ли план, нужно одновременно знать:
какие проекты претендуют на одних и тех же людей;
в каком порядке эти проекты должны выполняться;
сколько работы требуется на этапах;
когда специалисты доступны;
какие этапы зависят друг от друга;
что изменится при смене очередности.
Поэтому инструмент для такой работы полезно проверять не количеством функций, а одним практическим тестом: повысили приоритет одного проекта — можете ли вы сразу увидеть, какие остальные сроки изменились и почему?
Если нет, последствия всё равно придётся собирать вручную.
Полностью избавиться от срочных запросов невозможно.
Но можно перестать узнавать об их последствиях постфактум.
Если несколько проектов используют одну команду, их нельзя планировать как независимые.
Каждый менеджер может построить идеальный собственный план на время, которое уже занято в чужом.
Поэтому проекты должны существовать в общей картине загрузки.
При конфликте должно быть понятно, какой проект получает специалиста первым.
Не обязательно навсегда.
Очередь может меняться.
Но в конкретный момент времени у команды должна быть одна версия ответа на вопрос: что мы делаем раньше, а что ждёт?
Если у каждого менеджера своя очередь, общей очереди фактически нет.
Когда приходит срочная задача, полезно сначала ответить на четыре вопроса:
Какие специалисты ей понадобятся?
Что они должны были делать в это время?
Какие следующие этапы сдвинутся?
Какие обещанные результаты из-за этого перестают помещаться в план?
После этого уже можно принимать решение.
Например:
«Исправление действительно важнее. Берём его первым. Тогда интеграция начнётся позже, а релиз проекта Б переносится. С его владельцем согласуем новый срок».
Это совсем другой разговор, чем:
«Давайте возьмём, а остальное как-нибудь постараемся успеть».
После изменения приоритета старые обещания не должны продолжать существовать параллельно с новым расписанием.
Если очередь изменилась — изменился и прогноз.
Важно обновить даты затронутых работ и сообщить их владельцам.
Ещё полезнее сохранять предыдущую версию плана вместе с причиной изменения.
Тогда спустя месяц можно увидеть не просто факт переноса, а его источник:
поменяли приоритет;
изменили оценку;
сотрудник отсутствовал;
работа фактически заняла больше времени;
появилась новая задача.
Если команда регулярно занимается поддержкой, исправлениями и незапланированными запросами, эта работа существует независимо от того, есть ли она в квартальном плане.
Если всё доступное время заранее обещано проектам развития, любой новый запрос автоматически потребует переноса.
Часть известных работ можно оценить заранее.
Для непредвиденных имеет смысл оставлять резерв и корректировать его размер по фактической статистике.
Да.
Но только если это прогноз, который связан с реальной доступностью команды, а не набор желательных дат.
На квартал можно определить важные результаты, оценить основные этапы и проверить, помещаются ли они в доступное время специалистов.
Ближайшие работы распланировать подробнее.
Дальние оставить более крупными блоками.
По мере уточнения оценок прогноз будет меняться.
Спринт или недельный план при этом никуда не исчезает.
Он отвечает на вопрос: что команда делает сейчас?
А общее планирование нескольких проектов отвечает на другой: если мы изменим то, что делаем сейчас, что произойдёт с остальными результатами квартала?
Это разные уровни управления.
Можно быстро понять, есть ли эта проблема у вашей команды.
Попробуйте ответить «да» или «нет» на пять вопросов.
1. Есть ли одна общая очередь проектов?
Не отдельные приоритеты внутри каждого проекта, а единый порядок для проектов, которые используют общую команду.
2. Видно ли в одном месте, что один специалист уже обещан нескольким проектам?
До того, как конфликт проявится фактически.
3. Можно ли до изменения приоритета увидеть затронутые сроки?
Не после очередной планёрки, а в момент принятия решения.
4. Пересчитывается ли весь затронутый план?
Или менеджерам приходится вручную менять даты в нескольких местах.
5. Можно ли потом понять, почему срок изменился?
Например, сравнить текущий план с предыдущим и увидеть причину перепланирования.
Если на несколько вопросов ответ отрицательный, скорее всего, значительная часть планирования всё ещё происходит в головах менеджеров и в личных договорённостях.
У меня проблема была именно такой: несколько проектов конкурировали за одну команду, приоритеты регулярно менялись, а последствия для остальных сроков приходилось пересобирать вручную.
Мне хотелось не ещё одной доски задач, а способа связать: приоритет проектов → доступность людей → последовательность этапов → прогноз сроков.
Так появился KORDO ONLINE.
В нём проекты, этапы, исполнители и их доступность участвуют в одном расписании.
Когда порядок проектов меняется, можно пересчитать план и увидеть последствия по проектам и по сотрудникам.
При этом расписание всё равно остаётся прогнозом.
Оно не принимает управленческие решения вместо руководителя и не делает оценки автоматически правильными.
Но позволяет обсуждать изменение приоритета вместе с его последствиями, а не обнаруживать их через несколько недель.
Я сделал открытое демо KORDO именно для такого сценария: можно поменять порядок проектов и посмотреть, как это отражается на расписании общей команды.
Попробовать KORDO ONLINE можно без регистрации на демо-портфеле всем желающим.
Вспомните последний срочный запрос в вашей команде.
В момент, когда его поставили первым, вы уже знали, какие проекты из-за этого придётся подвинуть?
Или это выяснилось позже?
Иван, автор KORDO ONLINE
