Управление сроками проекта. Основные виды задержек в проектах

Задержки - один из главных врагов проекта. Чем больше задержек - тем выше риски, что проект не запустится.

Разберем типы задержек и как их избежать.

Ключевой принцип - делать важные действия заблаговременно + иметь одинаковые ожидания с заказчиком по взаимодействию и кто, что, когда должен предоставить.

Не дает вовремя контент. Нужно заранее запрашивать у него контент + договориться о сроках, когда он сможет это точно дать. И не стесняться его дергать по этим моментам. Это же его проект.

Нет времени на проверку сайта. Можно сделать видео, как мы проверяем сайт и дать его клиенту. Это упростит ему проверку. Также можно напомнить о сроках этапа (особенно если он сам ставил дедлайн).

Пропадает и не выходит на связь. Заранее согласовать, что не пропадаем надолго + взять телефонный номер для возможности его вызвонить по телефону.

Тянет с решением по хостингу или выбору провайдера АПИ. В идеале не брать в этап задачи, по которым нет определенности. Просто отложить в другой этап. Если же очень хочет в этап добавить - то пусть определяется. Т.е. в этап должны попадать работы, по которым есть полная определенность (если нет определенности - предлагать делать прототипное решение).

Долго формулирует задачи на следующий этап. Надо это делать заранее, до момента когда кончится этап. В идеале это надо делать непрерывно в беклоге - добавлять идеи на будущее, детализировать. Также можно предложить ему, что можно реализовать в проекте (исходя из его общей концепции проекта).

Долго оформляет бумаги между этапами + обработка счетов. В плане счетов - в идеале работать по 100% предоплате. По бумагам - напирать на общие дедлайны, которые есть у проекта.

Делает сначала простое, а сложное оставляет на конец этапа. В этапе надо сначала делать самые проблемные моменты, т.к. возможно здесь потребуется решение извне (от заказчика) и это еще создаст задержку. Если в этапе есть АПИ - лучше начать с него.

Слишком поздно задает вопросы по неясным задачам. Все непонятное лучше выявлять сразу. Иначе вы можете в целом не туда двигаться (по смежным задачам). Также детализация задачи может занять еще времени (например, заказчик не сразу даст информацию, а исполнитель в это время может простаивать. А мог бы задать все вопросы по неясным задачам, а пока делать другие задачи параллельно).

Долго не приступает к задачам (ввиду загрузки или по др причинам). Если задачи долго висят в ожидании на выполнение у исполнителя, значит есть перекос в распределении задач. Необходимо по возможности эти задачи раскидать на других.

Долго задача висит В работе. В идеале любая задача должна решаться за 1 день. Если задача растягивается на несколько дней - это плохая ситуация. Значит задача поставлена как один большой ком, а не декомпозирована на отдельные задачи. Либо исполнитель этой задачи не может ее решить нормальным способом и ищет обходные (зачастую костыльные) пути. Чем дольше выполняется задача, тем выше вероятность сложного трудоемкого неэффективного решения.

Не выставлены вовремя задачи. Необходимо следить за загрузкой исполнителей на проектах и лучше выставлять больше и наперед, нежели создавать ненужные простои.

Выставление простых задач на опытных, а новички сидят без дела потом. Все простые задачи должны идти в первую очередь на новичков (если они есть в проекте).

Долго не проверяются задачи. Если задача долго висит на проверке, то исполнителю сложнее потом въехать, что там было по задаче и как лучше поправить. В идеале проверять по горячему: человек сделал задачу и тестер сразу проверяет и дает правки по задаче, если они есть. И разработчик сразу забывает об этой задаче и может двигаться дальше.

Задачи плохо поставлены. Если задача поставлена плохо, то будет куча уточняющих вопросов, это занимает время разработчика и автора задачи + создает задежки, когда они состыкуются по обсуждению этих вопросов. Если есть много вопросов по задаче или необходимо много обсуждать - это недоработка автора задачи. Всегда у задачи должна быть вся необходимая конкретика: скрин, URL, логин и т.д.

Менеджер играет роль сломанного телефона между разработчиками и заказчиком. Если менеджер плохо понимает задачи и только занимается пинг понгом сообщений между исполнителем и заказчиком - это очень плохая ситуация. В этом случае проще напрямую взаимодействовать заказчику с исполнителем. Менеджер должен получать пожелания от клиента в любой форме, детализировать их и приводить к нужному формату, чтобы у исполнителя не возникало доп вопросов по задаче, и он мог сразу приступать к ее выполнению.

Нет ориентации на дедлайн проекта. Если в проекте нет дедлайна, то и выполняться он может бесконечно долго. Обязательно должна быть ориентация на дедлайн и редлайн (внутренний дедлайн по этапу). Помимо дедлайна этапа в проекте должна быть и план дата по внедрению всего проекта, которую надо почаще напоминать клиенту (иначе он может бесконечно улучшать продукт без запуска).

Не используется диаграмма выполнения работ по этапу. Диаграмма дает сразу представление как дела идут по проекту. Как часто обновляется оценка? Успеваем мы или нет? (линия сделано под редлайном и дедлайном или нет). Именно эта диаграммы должна быть мерилом текущего состояния этапа.

Плохое техническое задание на этап:

• это куча изменений по ходу этапа,
• это споры, кто как понял, что написано в ТЗ (возможные разногласия с заказчиком)
• это дополнительные обсуждения по детализации задач
• это сложность проверки задач по соответствию ТЗ
• это промахи в оценке этапа
• это сложность в декомпозиции задач. Приходится ставить задачи одним большим комом.

Обязательно уделяйте внимание созданию качественного ТЗ, это упрощает все последующие работы, связанные с реализацией по ТЗ.

Неумение вести клиента по процессу (клиент захватывает инициативу). Если клиент начинает наводить свои порядки в этапе - ничего хорошего не жди. В итоге менеджер начинает играть роль секретаря клиента, клиент по наитию будет вводить практики, которые удобны лично ему, будет постоянно висеть над разработчиками в проекте.

Необходимо максимально точно придерживаться основного процесса разработки, что принят у нас. Если мы отходим где-то от процесса, то делаем это осознанно, с некой целью и пониманием ситуации, а не под давлением со стороны заказчика.

Долго делается верстка на стороне. В идеале самим делать верстку (если есть на проекте верстальщик). Либо другой хороший вариант - верстка заранее уже готова. Если же уже есть внешний исполнитель на верстку, то согласовать даты, что и когда может отдать верстальщик, и дотошно двигать по этому плану + писать в общий чат, когда идет задержка по этим датам.

Не дают информацию по API. В идеале надо собрать всю информацию по API ДО этапа, а не вовремя. Если нет информации - то пока не брать просто в этап, а перенести на следующий.

Также можно на ранних стадиях проекта сразу сказать клиенту, какую информацию по АПИ ему необходимо вытащить из поставщика АПИ.

Задержки в проекте - одна из ключевых проблем. Менеджер проекта - ключевой человек, который может повлиять на уменьшение этих задержек.

Необходимо знать типы задержек, откуда они появляются и заранее принимать меры в проекте по их нейтрализации.

Для этого необходимо иметь правильные договоренности с заказчиком и командой на проекте, а также заблаговременно решать вопросы, которые могут спровоцировать задержки.

Источник: