Я работаю в агентстве веб-разработки, и недавно мы взялись за устаревший проект для нового клиента, который хочет внести изменения в свой сайт. Текущий набор изменений, над которыми я работаю, довольно велик, и ни у меня, ни у моих коллег нет опыта. Код ужасно плохо управляется, а структура в лучшем случае сложна.
Я нахожусь на среднем уровне и работаю в группе техобслуживания, хотя характер этих изменений довольно значительно отличается от всего, что было раньше. Несколько недель назад руководство попросило меня оценить эти изменения и сказало, что они нужны им быстро, и у них практически нет времени, чтобы изучить кодовую базу. Я просматривал дизайны и оценивал работы на лицо. При ближайшем рассмотрении оказалось, что работа и проект в целом намного сложнее. Эти работы не только займут больше времени, я даже не уверен, что смогу завершить их в разумные сроки на данный момент.
Вот кикер. После моих первоначальных оценок руководство попросило меня срезать жир и еще больше сократить время разработки, оставив все еще мало времени для изучения кодовой базы проекта. Я начал работу на этой неделе и понял, что это, вероятно, невозможно в рамках текущих сроков, однако мне сказали уложиться в эти сроки, как и было согласовано.
В целом мне нравится моя работа и проекты, над которыми я работаю, однако этот проект пришел прямо от высшего руководства, и до меня почти не было консультаций с разработчиками, и, хотя это редко, это ситуация, в которой я оказывался раньше. Как я могу справиться с этой ситуацией?
Поскольку вы уже предоставили оценку, в будущем утройте свои оценки! Мое общее правило при оценке программного обеспечения, над которым я никогда раньше не работал и не знаком с используемыми технологиями, состоит в том, чтобы взять любую мою первоначальную догадку и утроить ее. Это много раз спасало мою шкуру за эти годы, и теперь это лучшая практика, которой я живу.
При этом, поскольку вы уже предоставили число, ваша первая задача — сбросить ожидания теперь, когда вы немного углубились в него. Можно вернуться к боссам и сказать, что это займет гораздо больше времени, им это не понравится, учитывая, что вы уже предоставили номер, так что будьте готовы установить надежную защиту.
Вам также следует поработать с начальством и посмотреть, не сможете ли вы разделить работу на этапы и сначала создать минимально жизнеспособный продукт (MVP), а затем уже работать над дополнительными функциями 1 . Когда-то у меня был очень большой проект, который был непосильным, и как только проект был разделен на 3 отдельных этапа, им стало намного легче управлять.
Кроме того, если вы не знакомы с используемыми технологиями, было бы неплохо посмотреть, сможете ли вы найти опытного консультанта, а затем получить от него несколько часов, чтобы получить хорошее начало, по крайней мере, рассказать вам о движущихся частях. и соединить несколько точек для вас. Вы можете потратить дни на исследования/обучение или потратить несколько часов времени, чтобы получить поток информации, которая позволит вам взяться за дело.
Самое главное в подобных ситуациях — это общение , не заходите в коробку и выходите в эфир за неделю до дедлайна, а потом говорите, что вам нужно еще два месяца. Это только плохо отразится на вас . Вы должны регулярно сообщать обновления бизнесу/своему менеджеру, вплоть до того, чтобы ставить перед ними работу и спрашивать, соответствует ли это их ожиданиям, затем вы принимаете их отзывы и внедряете обратно в продукт для следующего раунда разработки. Это базовый план итеративной разработки с использованием гибкой разработки программного обеспечения. Ключевым моментом в этом процессе является то, что вы постоянно показываете прогресс, поэтому, когда крайний срок приближается, никто не удивится, если в продукте многого «не хватает».
1: Минимально жизнеспособный продукт — это подмножество функций, которые минимально необходимы для того, чтобы конечные пользователи могли использовать приложение для достижения своих основных целей. Примером может служить транспорт: вы можете начать со скейтборда в качестве своего первого MVP, поскольку он доставит вас туда, куда вы направляетесь. Затем вы сделаете из него самокат, чтобы им было легче управлять. Затем вы добавляете функции, пока не получите велосипед, который поможет вам приложить больше усилий. Затем вы добавляете функции, чтобы сделать мотоцикл, и, наконец, вы работаете над превращением продукта в автомобиль. В зависимости от точных требований может оказаться, что скутер на самом деле является MVP, но в любом случае есть некоторое подмножество общего списка характеристик, которого будет достаточно, чтобы передать продукт в руки конечных пользователей, чтобы начать собирать обратная связь для остальной части разработки.
Работая в агентстве веб-разработчиков, я точно знаю, что вы имеете в виду, и мне пришлось быстро учиться, столкнувшись с точно такой же проблемой. Менеджеры по работе с клиентами просят вас дать оценки, а затем торгуются по ним.
Ситуация, в которой вы сейчас находитесь, я бы сказал, чем раньше вы поднимете этот вопрос, тем лучше. Расскажите им о своих опасениях, о том, что вы узнали и почему это произошло. Если вы подчеркнете проблему, а не укажете пальцем, это направит вас и команду на правильный курс, чтобы предотвратить это снова. Чем раньше вы что-то упомянете, тем лучше это будет для вас и вовлеченной команды.
Либо попытайтесь найти время, чтобы исследовать и узнать о технологиях, либо, возможно, поищите кого-то, кто знает это, для справки или помощи в работе над этим.
Вот некоторые вещи, которые я усвоил, давая оценки в среде, похожей на то, что вы описываете:
Вы среднего уровня, поэтому есть вероятность, что ваше мнение уважают и имеют за собой некоторый авторитет. Поэтому, когда вас просят быстро оценить работу, просто скажите, что вам нужно время, чтобы оценить работу, чтобы дать более точную оценку. Даже если они будут настаивать, предупредите, что это может быть неточным, если они будут торопить вас. Это возлагает на них ответственность, поскольку вы заранее предупреждаете их, если что-то пойдет не так.
Предостережения - король. Всегда предупреждайте, если вы не уверены. Например, «это займет 2 дня, если «X», «Y» и «Z» предоставлены и четко задокументированы» или указать, что это устаревшая кодовая база, которая сопряжена с ее сложностями и т. д. «2 дня, если мы знаем технологии, если это не займет больше времени" такие вещи. Это заставляет человека, спрашивающего, понять, что это зависит от отсутствия сложностей, которые вы не успели рассмотреть, поскольку вас торопят.
По оценке, пять себе как минимум 20% передышки (больше, если вы не знаете, во что вы собираетесь), таким образом, если что-то пойдет не так, у вас будет какая-то прокладка на всякий случай. Также у вас есть время, чтобы отдать его на тот случай, если вас попросят снять его, если вы можете себе это позволить.
Общаться. Выразите свои опасения, оговорки и сомнения. Они не захотят идти к клиенту и говорить ему, что либо это будет стоить дороже, либо это займет больше времени. Постоянно говорите им и клиенту, что вы делаете и какие у вас есть проблемы, надеюсь, вы уже делаете это в ежедневном стендапе.
Если сроки недостижимы и ваша оценка неверна, вы должны сообщить об этом как можно скорее. Могут быть другие способы смягчить это, о которых вы не знаете, и позволять этому доходить до последней минуты, безусловно, не очень хорошая идея.
О желании бросить курить: никогда не бросайте по первому импульсу, вместо этого установите таймер и посмотрите, сохраняются ли по истечении 30/60/90 дней те же самые обстоятельства, которые заставляют вас бросить курить. Особенно в этой ситуации то, как компания справляется с ней, будет очень хорошим сигналом, хотите ли вы продолжать работать в этом месте или нет.
А на будущее попрактикуйтесь #noestimatesили станьте намного лучше в оценке, выявлении рисков, продаже компромиссов и установке буферов внутри ваших оценок, чтобы предотвратить повторение чего-то подобного. Некоторым из этого вы можете научиться из книг, но многое зависит от опыта (как этот).
Эрик
Лилиенталь