Как оценивать сроки в проекте с долгосрочной поддержкой?

Ситуация: есть проект, который начат почти 20 лет назад. Какие‑то части проекта никто никогда не трогал, потому что никто как следует ими не пользовался, либо ими пользуется кто‑то один и привык ко всем их странностям. Где‑то вносились правки в режиме «подпереть шваброй», причём в большом количестве. А какие‑то части поддерживаются в более‑менее хорошем состоянии. Какие‑то части были внесены в систему контроля версий ещё тогда, а где‑то полноценное ведение истории изменений начали вести только пару лет назад, отчего приходится проводить мини‑расследование, чтобы понять, когда и почему была внесена та или иная правка. Поведение каких‑то частей более‑менее задокументировано, а как должны работать другие части не смог бы сказать и тот, кто их делал, не говоря уже о том, что он давно покинул проект. И вопрос: как в таких случаях оценивать сроки? В каких‑то местах, исходя из объёма работы, назначаешь срок в неделю, а потом оказывается, что всё почти уже сделано кем‑то до тебя. Но чаще наоборот, начинаешь вносить какие‑то простые изменения, но каждая новая правка или что‑то ломает, или вскрывает прошлые недоработки, которые ни на что не влияли раньше, но теперь их тоже нужно исправлять. И каждый раз приходится отодвигать сроки, и задача, которую планировал закончить за день, растягивается на недели. Задачи, которые обещали сделать к какому‑то сроку, откладываются, а задача, на которую потратили месяц отбрасывается, потому что она и так заняла много времени и в таком виде её выкатывать нельзя, а если просто поставить на паузу, она будет мешать выполнить другие задачи. Есть ли какие‑то хитрости для таких случаев? Можно ли заранее узнать, что задача затянется? На каком этапе стоит сказать «стоп, мы это не потянем»? И как случайно не отбросить задачу, которая могла бы быть сделана за пол‑часа, хотя изначально казалось, что займёт неделю?

Михаил!

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

Предлагаю внедрить в ваш типовой рабочий процесс инструмент понижения неопределённости — любая задача, фича, проект начинаются с явного этапа исследования и оценки. Принцип: «исполнитель понимает задачу».

Например, приходит к вам внутренний клиент и просит вкрутить новую фичу. Вы не обещаете ему сроки сразу, а говорите, что вам нужно икс дней на исследование и планирование. Пропустить этот этап нельзя. Если он согласен потратить ваше время таким образом, вы садитесь и собираете себе техническое задание — что и в каких модулях нужно поменять, какие краевые условия, какие подводные камни и так далее. Результат этой работы — задание и план с промежуточными контрольными точками — «гвоздями в гусенице». Если клиенту план окей, вы начинаете работу.

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

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

Что касается управления, когда задача уже в работе — «стоп, мы это не потянем» и подобное — дедлайн ваш главный советчик. Если вы собрали план с промежуточными контрольными точками, отправились его реализовывать и видите, что «гвозди» срываются так, что уже и общий дедлайн под угрозой, надо остановиться и решить, что делать.

В общем случае лучше упрощать решение — флексить, но не отказываться от задачи вовсе и не сдвигать срок. В конечном счёте вам платят за результат в срок, если результата нет, причины, честно говоря, клиентам не так уж и важны.

Когда настроите нормальную прогнозируемую работу с текущей системой, подумайте о постепенной переработке легаси. Один из рабочих подходов — «построить сбоку». С таким подходом вы какое‑то время не трогаете «олд‑щит», а нужные вам штуки строите параллельно с ним. Пример — новый сайт бюро.

P. S. Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.

Управление проектом
Отправить
Поделиться
Запинить

Комментариев пока нет

Рекомендуем другие советы