Как аналитик, как я могу смягчить последствия срыва сроков из-за непредвиденных блокировщиков?

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

Я сочувствую вашей проблеме.

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

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

Это также означает, что пропущенный крайний срок не обязательно является большой проблемой. Сроки ВСЕГДА срываются. Пропущенный крайний срок допустим, если все заранее знают, что крайний срок сдвигается, что предпринимаются разумные усилия, чтобы закрыть проект, что непредвиденные препятствия устраняются по мере их возникновения. Большинство людей рациональны и понимают, что в каждом проекте есть непредвиденные проблемы.

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

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

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

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

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

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

Также вполне возможно, что тот факт, что они не являются техническими, не имеет значения. Они хотят результатов и не заботятся об оправданиях, даже если они их много или не понимают.

Вы сказали:

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

Ключ, который вам нужно понять, это то, что всегда будут «проблемы» с данными. По своей природе данные представляют собой цифровое представление какого-либо реального события или какой-либо осязаемой вещи. Вы никогда не дойдете до стадии, когда ваши данные всегда будут «идеальными» в смысле полноты и точности. Иногда проблемы будут настоящими ошибками (клиент живет в Нью-Йорке, но ваша система неправильно имеет адрес в Калифорнии). Но в других случаях, даже если данные технически совершенны, будут проблемы с интерпретацией (клиент живет и работает в Калифорнии, но у него есть склад в Нью-Йорке, на который доставляется ваш продукт — что вы используете? как их адрес? Ваш отдел доставки говорит Нью-Йорк, ваша команда по выставлению счетов говорит Калифорнию). Правда в том,деловой мир завален заброшенными усилиями по аналитике и бизнес-аналитике, потому что компании отказываются от них из-за неспособности достичь идеальных результатов или просто из-за шока, когда результаты не идеальны. То, что данные достаточно хороши для операционных целей, не всегда означает, что они достаточно хороши для аналитики.

Таким образом, вы должны научиться производить с несовершенными входными данными. Ключом к этому является понимание недостатков, устранение их там, где это возможно, и объяснение их как части вашего результата вместо того, чтобы пытаться скрыть или скрыть их или, что еще хуже, предполагать, что вам нужно исправить их все до завершения проекта. Очевидно, что действительно есть случаи, когда вы не можете просто «жить» с результатами (половина адресов ваших клиентов неверны из-за ошибки в вашем ETL), но есть и другие случаи, когда объяснение как часть результата может помочь в общении. влияние проблем на результат («этот отчет основан на адресе доставки, хотя у некоторых клиентов платежные адреса находятся в разных штатах» или «тенденция, которую мы

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