Привет! Меня зовут Анна Ширшова, я уже 14 лет работаю в Data Science. В этом материале вы найдете мой личный чек‑лист по развитию карьеры: как ставить цели, где искать возможности, какие ошибки тормозят рост и как их обходить. 

Работу в ВТБ я начала в качестве лида команды, которую сама собирала с нуля. За время работы она была расширена до целого Кластера моделирования для СRM и оптимизации. В него вошли четыре команды из DE, DS, MLOPs, системных аналитиков и тестировщиков, руководителем которого являюсь. 

Некоторые коллеги, которые тогда вошли в команду в качестве junior DS, сейчас уже являются лидерами (product owner) команд Кластера. На основе своего опыта найма и развития сотрудников в сжатые сроки, в этой статье делюсь как стопперами, которые, на мой взгляд, мешают развитию карьеры, так и возможными путями по их устранению.

Эта статья — саммари и дополнение моего выступления на Data Fest 2025. Запись выступления вы можете найти по ссылке (таймкод — 07.31.30).

Немного о задачах, которые мы решаем, и особенностях нашей работы

Мы строим предсказательные модели для портфеля розничного бизнеса банка и работаем с объемом данных свыше 100 млн записей на один временной срез, а количество предсказательных признаков, включаемых нами в первичный анализ для моделирования, в этом году достигло около 40 тыс. признаков. Используем широкий спектр методов машинного обучения от деревьев решений и логистической регрессии до нейросетевых подходов, решаем NLP-задачи, в том числе с использованием LLM, строим кластеризации и рекомендательные системы, поддерживаем свой AutoML. 

Основные приложения наших решений: привлечение и удержание клиентов банка, анализ уровня клиентской удовлетворенности и мнений клиентов, профилирование клиентов из разных сегментов (масс, привилегия, старшее поколение, молодежь и др.), анализ склонности к продуктам и услугам, включая рекомендации, оптимизация процессов банка (например, шаблонизация и генерация текстов смс-сообщений, поиск лучших путей коммуникации и др.), поиск инсайтов о клиентах на основе транзакционных и прочих данных (анализ интересов, предсказание сумм и категорий след. транзакции и т.д.). Мы поддерживаем весь жизненный цикл модели от получения верхнеуровневой постановки задачи от бизнес-заказчика и адаптации ее на язык ML до внедрения и поддержки модели в промышленную среду. Работаем в проектах (все задачи подкреплены фин. эффектами) по agile, но с фиксированными проектными контрольными точками, с быстрыми темпами разработки.

Ключи успеха

Какие же факторы позволяют добиваться успехов как в карьере, так и в любом рабочем проекте?

Я выделяю три основных:

1. Результаты (целеполагание, декомпозиция и планирование, реализация и ретро-анализ);

2. Реклама (имидж, софт-скиллы, личные качества, нетворкинг);

3. Самосовершенствование (обучение, адаптация, открытость возможностям).

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

Карьера — это тоже проект. Мы ставим цели, планируем, декомпозируем, оцениваем ресурсы, находим оптимальные решения и не забываем про ретро-анализ. 

Результаты

На Data Fest 2025 меня спросили: имеет ли значение для роста карьеры подхалимство руководителю? Так вот, каким бы ни был замечательным человеком в жизни сотрудник и даже если вы с ним друзья много лет, или если сотрудник регулярно «угодничает», но при этом не приносит результатов в профессиональной деятельности – вряд ли он сможет рассчитывать на повышение. Ведь в любом бизнесе ключевое — это достижение высоких результатов и KPI. Мне как руководителю важна возможность положиться на своих сотрудников и знание, что даваемые задачи будут выполнены в срок и качественно, без частых напоминаний, переделок и срывов дедлайнов — соответственно, сотрудники, следующие этим нехитрым правилам, автоматически попадают в лист надежных. Ни один руководитель не будет рад, если ему некому будет поручить задания, и доделывать все придется самому, даже если сотрудники хором будут говорить, какой он хороший. 

Сам по себе результат — только конечный итог. Куда важнее результативность (способность достигать поставленных целей) и эффективность (достижение этих целей при минимальных затратах ресурсов). И, как следует из определений, без хорошо поставленной цели не бывает хороших результатов. 

Цели

Цели в карьере. Умение ставить цели работает и в карьере: сначала важно понять, чего ты хочешь (а не чего ждут от тебя), потом — как карьерная цель помогает тебе лично в жизни, как соотносится с твоими интересами и ценностями, и только потом — какие шаги приведут к результату. 

Цель — это не просто ориентир, а движущая сила роста. Карьера в Data Science — проект, который может иметь длинный горизонт, и без вдохновляющей цели легко перегореть на полпути. 

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

Кроме того, поскольку ранее я работала преимущественно с задачами оценки рисков, антифрода, регуляторными моделями, моделями БКИ и коллекшн, а с CRM в меньшей степени, то углубление в CRM показалось более релевантным для расширения навыков. 

Наконец, поскольку ранее у меня был опыт работы в консалтинге, хотелось сохранить возможность развивать и проявлять soft skills помимо кодинга. Так и получилось: сейчас я часто выступаю консультантом для бизнес-заказчиков — погружаюсь в экспертную область каждого бизнеса, рассказываю доступным языком, как работают те или иные методы машинного обучения и ИИ, и формализую бизнес-задачи, переводя их на язык математики. Также удалось сохранить творческую составляющую в работе — как Product Owner я придумываю новые ML и ИИ-решения. 

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

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

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

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

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

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

• Если вы задумываетесь о смене направления, начните с пет-проекта, проанализируйте, какие текущие навыки уже можно применить в новой области. 

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

Поясню классификацию целей по времени на примере моего плана развития кластера. 

У меня есть образ идеальной команды — это команда, каждый сотрудник которой уже является экспертом в своем направлении (DS, DE, MLOPs), может самостоятельно и корректно реализовать любую задачу из соответствующих направлению этапов жизненного цикла модели, имеет познания в смежных направлениях. И по сути, это такая творческая, заинтересованная группа, которая хочет производить классные и полезные продукты (как бизнесу, так и клиентам, а, может, и обществу в целом), вместе брейнстормит и изобретает новые решения, совместно развивается, в том числе в научной деятельности, поддерживает друг друга и создает приятную для работы атмосферу, место, где комфортно трудиться. Можно назвать это «рабочей семьей», у которой цель — не сидеть на месте и постоянно развиваться. Это долгосрочная цель, маяк, к которому я стремлюсь и на основе которого выстраиваю свои действия (возможно, идея может показаться утопичной мечтой, но, как говорится, дорогу осилит идущий). Если кому‑то это не откликается, наши пути просто расходятся — и это абсолютно нормально. 

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

Цели в рабочих задачах. Максимально распространенная ошибка, которую наблюдаю в сообществе DS — недостаточное внимание к бизнес-цели разрабатываемой модели, когда за технической реализацией забывается сутевая составляющая. 

Это неминуемо приводит к методологическим ошибкам: 

• Неверно формируется выборка для разработки — она не является репрезентативной относительно сегмента применения модели, забываются исключения (например, не исключив «текущих дефолтов», предсказывая выход в просроченную задолженность, Gini автоматически завысится), некорректно выбираются отчетные даты, период разработки, целевые переменные и т.д. 

Например, если event rate (доля целевого события) распределяется в два плато по 6 месяцев каждое с сильно отличными значениями, а для моделирования обычно используется период стабильности event rate, возникает вопрос — что выбрать? Можно взять наиболее актуальный период, но лучше уточнить у бизнес-заказчика, есть ли какие-то ожидания по event rate в будущем (и подстроиться под них), или, быть может, проводились какие-то особые кампании/происходили ситуации, которые объясняют такой график в прошлом, что поможет определиться с периодом. На практике, к сожалению, нечасто о таком задумываются, хотя это база. 

• «Стреляние из пушки по воробьям» — построение модели в случаях, где достаточно обойтись ретро-аналитикой и экспертными решениями.

Сталкивалась со случаями, когда моделью предсказывали ретро-частоты события (а не «будущее», хоть и в ретро), в то время как для этого достаточно было взять сами частоты, и модель не нужна.

• Отсутствие сутевого анализа признаков модели и их связи с целевой переменной. 

Да, наверное, если в модели 500+ признаков, и это нейросеть, то с интерпретируемостью посложнее, но когда рассматриваем бустинги и регрессию, то сделать анализ shap, провести биннинг признаков где необходимо, посмотрев тренд значений vs event rate (привет, OptBinning!), понимать смысл и алгоритм расчета признаков — это, считаю, обязательные элементы для каждого уважающего себя DS, который демонстрирует и защищает свою модель перед бизнесом. 

• Построение неокупаемых моделей — Gini высокий, но модель уходит «в стол», так как, например, event rate целевой переменной изначально настолько низкий, что улучшение за счет модели не позволяет окупить стоимость ее разработки и внедрения в приемлемые сроки.

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

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

С моей точки зрения, DS в первую очередь нужно быть аналитиками, а уже потом моделистами, так как выбор метода ML — это дело техники после проработки архитектуры решения. Согласно нашей структуре, за бизнес-KPI отвечают бизнес-заказчики, но всегда рекомендую ставить себя на их место и решать именно бизнесовую проблему. На практике (на тех же собеседованиях) фокус кандидатов часто направлен на техническую часть, но не каждый может сформулировать, какие бизнес-задачи были решены и как техническое решение повлияло на бизнес-результат, также часто вижу непонимание алгоритмов, лежащих в основе того или иного метода ML (а как без этого делать выбор?). Предполагаю, что причиной такой ситуации может быть недостаточное внимание аналитике в быстрых ML-курсах. Берите на заметку, что подтянуть и чем блеснуть =). 

Когда бизнес-цель сформулирована, она, фактически, определяет весь pipeline моделирования. И от нее, как от центра, можно раскрутить всю «улитку» решения, отвечая на простые вопросы (см. Рисунок 1). Конечно, могут быть варианты в выборе методов, но граничные условия проектной работы (сроки, количество доступных ресурсов и т.д.) сузят их до конечного числа способов для тестирования. 

Специалиста высокого уровня/эксперта отличает умение решать задачи, сформулированные верхнеуровнево, например, «разработать модель X для решения бизнес-задачи Y» — такой специалист сам «раскрутит» решение и наметит для себя шаги по его реализации, а также обоснует, почему выбрал именно такой путь.

Методы целеполагания. Помочь в постановке цели нам могут такие техники, как SMART + ER (evaluate/re-do). Также помогает подробное изложение цели на бумаге, представление ее зрительного образа и своих чувств после достижения цели (на этом шаге может оказаться, что хотите вы вовсе не то, что сформулировали изначально), а еще описание цели в виде интеллект-карт.

Но, пожалуй, ни одна из этих техник в применении к ML-проектам, не является эффективной на 100%. 

Действительно, если говорим о SMART(ER), возникают вопросы и к конкретности, и к измеримости, к достижимости, реалистичности, ограниченности по времени:

• часто отсутствует точная постановка задачи и план использования модели у заказчиков на старте проекта; 

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

• почти каждая новая задача — RnD;

• почти всегда в новых задачах нельзя заранее гарантировать значение метрик качества модели (Gini, F1 и т.д.) и положительный результат;

• конечная эффективность всего решения зависит от совокупности факторов, в т.ч. внешних (стратегия применения модели бизнес-заказчиков, резкое изменение экономических условий и др.) — так, Gini модели может быть высоким, а скрипты коммуникации составлены неудачно, в итоге отклик будет низким, и общее решение не принесет ожидаемого эффекта;

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

• описание по SMART всех целей занимает долгое время.

Так что поможет сотруднику справиться с этими вызовами и как даже в условиях неопределенности увеличить вероятность успеха? 

Перечислю несколько рекомендаций на основе своей практики.

1. Важно синхронизировать свои возможности и ожидания заказчиков, как упоминалось выше. Также можно явно подсветить заказчикам этапы, на которых могут появиться «развилки», потенциально ведущие к усложнению задачи, увеличению сроков/требуемых ресурсов. 

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

3. Декомпозиция на отдельные подзадачи, которые уже проще разложить по SMART. Например, подготовка отчета в определенном формате и т.д. 

4. В RnD-задачах создание на первом шаге прототипа (MVP), с дальнейшим масштабированием, если MVP устроит заказчика.  

5. Планирование.

6. Мониторинг промежуточных результатов, корректировка целей. Обеспечение прозрачности (статус-чеки) для всех участников процесса.

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

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

Мне приходилось видеть ошибки там, где их просто невозможно допустить, если хотя бы немного взглянуть на ситуацию/задачу верхнеуровнево и стратегически. Этот навык «общей логики», на мой взгляд, очень важно иметь специалисту для работы и карьерного роста. При всем желании, есть случаи, где невозможно формализовать советы в общие правила, так как тогда понадобится перечислить все возможные ошибки во всех возможных ситуациях, которых бесконечно много (вспомните такие попытки в руководствах пользования бытовой техникой и на упаковках продуктов). Более того, в одной ситуации совет может работать, а в другой нет, поэтому при отсутствии навыков критического мышления и логики регулярные ошибки просто неизбежны. 

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

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

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

1. Полезно примерять на себя идею или результаты готового решения. Например, наша доменная область (банковская) изначально близка сотрудникам, так как почти каждый человек в своей жизни использовал банковские услуги. Поэтому, продумывая решение, можно задаваться вопросом: а понравилось бы оно мне или сработало на мне как на клиенте банка? Готовые скоринговые баллы моделей также можно проверять на адекватность и отлаживать «на себе», если есть отношение к рассматриваемому сегменту.

Декомпозиция и планирование

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

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

Важно учесть и продумать при этом следующие моменты:

Риски, уроки прошлого, проработка запасных вариантов  

• Риски: время на требуемые итерации (доработки) решения, частота инфраструктурных сбоев;

• Матрица зависимостей задач;

• Ретро-анализ: сроки выполнения похожих задач, при схожих компетенциях сотрудников, удачи/неудачи;

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

• Гэп-анализ: доступность имеющихся ресурсов на рассматриваемый период, в том числе в других командах, с которыми есть зависимости, и т.д.

Расстановка приоритетов

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

Обычно для фасилитации процесса я рекомендую в первую очередь направлять письма и решать небольшие вопросы, где кто-то от вас зависит, а далее уже реализовывать более «тяжелые» задачи.

Знание себя и своих привычек

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

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

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

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

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

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

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

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

Рассмотренные примеры — не только об эффективности, но и о заботе о себе, об обеспечении себе комфортных условий работы. 

Реализация

Вопросы в зоне/вне зоны влияния

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

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

Обоснованность действий 

При реализации задачи важно уметь обосновывать свои шаги и решения, а для этого полезно задавать себе вопросы:

• Зачем я это делаю?

• Почему я делаю именно так? Есть ли альтернативные варианты, и чем мой способ лучше других?

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

• Перепроверка результатов. 

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

• Как выполнялись подобные задачи ранее, какие выводы были сделаны из прошлого опыта? 

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

• Какие есть зависимости с задачами других сотрудников/команд?

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

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

Важно помнить о том, что:

• Есть несдвигаемые сроки — не стоит лишний раз проверять терпение руководителей и заказчиков, генерируя регулярные сдвиги.

• Не стоит недооценивать свой вклад в общее дело — работа каждого участника команды влияет на десятки смежных процессов и других команд. 

Пример: если сотрудник не знает, какую роль имеет выполняемая им задача в бизнес-процессе, то у него может снизиться уровень ответственности. Так, сдвиг выполнения задачи на неделю может казаться ему незначительным, но, вот незадача, на следующей неделе заказчик ушел в отпуск и не смог согласовать вовремя результат, далее, оказалось, что ресурсы разработчиков заняты, потому что они планировались в соответствии с отсутствием каких-либо сдвигов, и уже аллоцированы на другой проект, потом внезапно появились проблемы с инфраструктурой, а после — отпуск уже у самого сотрудника-исполнителя, и вот задержка в неделю превратилась в сдвиг срока решения на месяц, что уже критично для проекта. 

Еще один пример: допустим, перед сотрудником стоит задача подготовить отчет за одну неделю, но случился сбой в инфраструктуре, и он не может реализовать необходимые расчеты. Как вы думаете, в каком из двух случаев действия сотрудника будут одобрены руководителем: 1) сотрудник по прошествии недели не сделал отчет, пришел на встречу с руководителем через неделю, и отсутствие отчета обосновал неработающим ПО; 2) сотрудник завел заявку о неисправности ПО, сразу уведомил руководителя о проблеме, запросил другие задачи, не связанные с работой неисправного оборудования? Ответ очевиден. 

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

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