Из ведущего аналитика в тимлиды: как принять проект с командой и не пожалеть?
Привет, Хабр! Меня зовут Дима, и я долгое время работал руководителем отдела аналитиков и технических писателей.
В ходе работы ко мне часто обращались за помощью и ресурсами тимлиды и руководители других подразделений. Самая сложная ситуация была, когда этими тимлидами были мои же ведущие аналитики, которым только что передали проекты и команды по наследству.
Это происходило потому, что ведущие аналитики уже погружены в предметную область проекта, знают ключевых специалистов заказчика, общаются с разработчиками и техническими писателями. Поэтому им первым предлагали отдать проект, когда тимлид покидал компанию.
Конечно, аналитикам говорили, что проект амбициозный, настоящий вызов и точка роста для хорошего ведущего специалиста! И аналитики, полные энтузиазма, брали ответственность за проект и команду.
Они закапывались в курсы, изучали международные стандарты, скачивали книги, в которых дают советы: “Обсудите с руководителем и согласуйте цели на 3 месяца”, “Проведите 1-1 с каждым членом команды” и т. д. И они всё это делали.
Руководитель говорил им, что надо доделать сервис и закрыть этап проекта. Члены команды утверждали, что в целом всё идёт неплохо. И новый тимлид принимал проект, радуясь, что всё складывается так хорошо.
Но в моей практике были случаи, когда запускать проект приходили тимлиды уже с готовым бизнес-планом: “Проработаю на проекте несколько первых этапов - исследование, сбор требований и архитектурное проектирование, а потом уйду, оставив это на реализацию какому-то бедолаге.
Как вы понимаете, на реализуемость проект никто не проверял. У тимлида была другая цель - подружиться со всеми, дать множество обещаний, подписать бумаги, а потом, сославшись на обстоятельства, которые мало от него зависят, уйти.
Работа над таким проектом превращалась в ад для нового тимлида. На него давили со всех сторон: заказчик, руководство, подчиненные. Ведь три предыдущих этапа проекта прошли успешно! Все решения готовы и согласованы, есть сформированная сильная команда! С заказчиком отличные отношения! Почему в таких, казалось бы, идеальных условиях новый тимлид не может реализовать проект?
Каждый день превращался в борьбу не на один фронт с заказчиком, а на пять:
с сотрудниками, которых раздражало, что тимлид превращал их работу в бардак;
с руководством, которому не нравилось снижение качества результатов работы команды;
со смежными командами, чью работу тимлид блокировал, а на них также давили сроки и руководство;
с заказчиком, которому в этой ситуации всё не нравилось;
с самим собой, ведь раньше тимлид был отличным аналитиком, выдающим каждый день качественный результат, а теперь его работа всех не устраивает.
И через пару месяцев ведущие аналитики выгорали и делали выводы, что управление командами и проектами не для них.
Но именно ведущий аналитик обладает всеми навыками и инструментами для выявления подобных ситуаций. Кто, как не он, умеет скрупулезно собирать и систематизировать информацию, чтобы делать на её основе точные выводы? Главное подойти к передаче команды и проекта как к сложному аналитическому исследованию, а не как к награде за отличную работу.
Важно понять, что от начальных условий результат проекта зависит не меньше, чем от ваших компетенций. Поэтому возникла идея написания статьи. В ней я хочу проговорить, как аналитику подготовиться к беседе с руководителем и принять решение о взятии ответственности за проект и команду.
Статья будет полезна:
ведущим аналитикам (разработчикам, техническим писателям, да и в целом любым хардкорным технарям), которые планируют занять роль тимлида;
тимлидам, которые готовят себе заместителей или ищут замену;
методологам и HR, которые выстраивают онбординг тимлидов.
Ведущим аналитикам она поможет применить знакомые инструменты сбора, систематизации, анализа информации и моделирования процессов, чтобы:
провести аудит реальной ситуации в проекте и команде;
систематизировать руководящие процессы в единую картину;
отделить легаси условия проекта и команды от своих недостатков;
составить план развития компетенций, чтобы закрыть недостатки, снижающие эффективность работы;
подготовиться к негативу и снизить уровень стресса, чтобы не выгореть в первые месяцы;
с учетом начальных условий и рисков обсудить с руководителем условия перехода на новую должность.
Методологам, руководителям и HR статья поможет стандартизировать набор артефактов для процесса оффбординга (передачи дел), которые должны быть заранее подготовлены и переданы от старых тимлидов к новым, особенно в экстренных условиях.
Немного о контексте компании.
Наши тимлиды разрабатывали модули для внутренней платформы и параллельно работали во внешних проектах по адаптации платформы под требования заказчиков. Одним из основных модулей платформы была система управления проектами. Каждый руководитель и тимлид должен был уметь в ней работать и использовать в годовом, квартальном и проектном планировании.
Поэтому в статье я рассматриваю роль тимлида, который не только руководит командой, но и выполняет функции управления проектами - как внутренними, так и внешними.
Ну что, давайте начнём!
1. От сильного специалиста к слабому тимлиду
В предыдущем разделе мы уже упомянули, что ведущие аналитики нередко начинают подготовку к новой роли с изучения курсов, международных стандартов и книг, описывающих компетенции и техники идеальных руководителей. Например, IPMA Individual Competence Baseline (IPMA ICB), разработанный Международной ассоциацией управления проектами, или Project Manager Competency Development Framework (PMCD Framework), разработанный организацией PMI - создателем PMBOK, или ГОСТ Р 53892-2010 "Руководство по оценке компетентности менеджеров проектов".
В них подробно описано, что тимлид должен уметь работать с требованиями, планировать работы, оценивать ресурсы, риски, нанимать людей, быть порядочным, подавать хороший пример команде и т. д.
Но стандарты избыточны, и аналитику не хватает времени систематизировать описанные в них процессы и компетенции, отсортировать по приоритетам и понять, какие в первую очередь надо изучить и как их наложить на реальную сложившуюся ситуацию.
Поэтому по любому входящему запросу от заказчика, руководителя и смежной команды аналитик “подрывается” сам и начинает давить на команду. В результате вся команда работает в непрекращающемся стрессе. Ресурсы тратятся на активности, которые не улучшают результат и не отвечают ожиданиям стейкхолдеров.
Но хочется отметить, что проблемы на проектах у начинающих тимлидов могут возникнуть не только из-за недостатка управленческого опыта и незнания стандартов. Я уже рассказывал о случае с нереализуемым проектом, когда новому тимлиду не хватило опыта и знаний, чтобы выполнить принятые обязательства.
Были и другие случаи сложных проектов, например:
с потерянными коммитами;
с изматывающими “юридическими войнами”;
со сложной организацией работы из-за государственной тайны.
Подробнее об этих проектах
На проектах с потерянными коммитами заказчики и подрядчики говорили новому тимлиду о договоренностях и требованиях, которые обещал выполнить предыдущий тимлид.
В некоторых случаях это были реальные коммиты, а иногда - только попытки продавить свои интересы через нового, но не до конца погруженного и уверенного в своих силах тимлида.
Чем честнее был новый тимлид, тем активнее стейкхолдеры этим пользовались для продавливания своих интересов. Особенно много боли такие коммиты приносили, если проект шёл несколько лет и часть формальных переписок терялась или оставалась у предыдущего тимлида.
Когда новый тимлид был на стороне исполнителя, он часто приходил и просил у меня ресурсы. Но их не всегда хватало, особенно в конце квартала. И ему приходилось идти извиняться и “слёзно умолять” заказчика отказаться от коммитов или просить подчиненных, чтобы отработали коммиты внеурочно и бесплатно.
Если новый тимлид выступал со стороны приемки (заказчика), то на него давили подрядчики. Требовали подписать акты и протоколы с реализацией, отличающейся от требований технического задания. Новый тимлид вставал перед выбором: подписать и взять на себя ответственность или начинать судебный процесс.
Случалось, что проекты превращались в изматывающие “юридические войны”. Например, в длительных проектах менялось руководство заказчика. А новое, чтобы не брать ответственность и не подписывать акт выполненных работ, нанимало экспертов, аудиторов с целью максимально препятствовать сдаче проекта. В результате проект для нового тимлида превращался в многомесячную подготовку доказательной базы и обоснование того, что все работы выполнены.
Иногда проекты несли юридические риски, например, срыв срока предусматривал уголовную ответственность. Новоиспеченный тимлид получал официальные уведомления о том, что все соисполнители, участвующие в работе, готовы к испытаниям и ожидают только подтверждения готовности от него. И, конечно, у него не было понимания, реально ли у других соисполнителей всё готово или они хотят формально себя подстраховать.
Были проекты, где каждое слово в техническом задании, включая тему, было засекречено. Постепенно на таких проектах у тимлидов сдавали нервы, и внутренний голос начинал спрашивать: "А ты неделю назад на статусе по проектам случайно тему проекта не назвал, когда была включена запись экрана? А вчера, отвечая на сотое сообщение в чате, ничего лишнего не написал? А в среду на созвоне на листе бумаги ручкой писал заметки, там случайно не осталось чего, а где теперь этот листок?" Даже опытные тимлиды выгорали на таких проектах за пару месяцев из-за максимально сложных и стрессовых переключений контекста между задачами и проектами.
Эти случаи показывают, что результат работы нового тимлида зависит не только от его компетенций, но и от состояния проекта и условий, в которых предстоит работать.
Чтобы помочь аналитику собрать ключевую информацию о проекте до принятия ответственности и на её основе подготовиться к беседе с руководителем, мы выполним шаги процесса, показанного ниже.
Процесс состоит из шести этапов:
собираются данные о планах, рисках, коммитах и результатах предыдущих этапов работ;
составляются реестр и план руководящих процессов в компании и реестр рисков дополняется рисками по критическим процессам;
отделяются легаси условия проекта от собственных недостатков тимлида и формируется план обучения;
оцениваются дополнительные возможности (рычаги) влияния на команду и проект, которые могут уменьшить уровень стресса и сделать проект более управляемым;
на основании собранных материалов формируется краткое резюме по текущему состоянию дел, основным рискам и результатам (именно его увидит ваш руководитель);
на основании шаблона подготовки к встрече формируется сценарий встречи, включающий цели, задачи, план встречи, условия, на которых вы готовы принять проект, и материалы, обосновывающие вашу позицию.
Чем больше рисков и хуже легаси условия, тем больше вы вправе попросить взамен. Речь не только о зарплате: это ещё время на аудит результатов проекта, менторство, дополнительные ресурсы и право пересмотреть план. Если договориться не получается, это тоже результат: он подсказывает, что от проекта лучше отказаться.
Давайте перейдём к первому этапу процесса - анализу обстановки на проекте.
2. Изучаем обстановку на проекте
В первую очередь надо прийти к предыдущему тимлиду и вашему непосредственному руководителю и узнать, как организованы (AS IS) процессы планирования, отчетности и управления рисками.
Эти процессы и получаемые в них артефакты критически важны, чтобы понять, где вы находитесь, что было запланировано, что сделано, что упущено, что предстоит сделать в ближайшее время и что может вам помешать.
В стандартах по управлению проектами написано, что проекты уникальны. Проблемы и риски, которые возникают при их выполнении, тоже уникальны. И если предыдущий тимлид не планировал работы, не фиксировал результаты и не вёл реестр рисков, то вы никогда не узнаете, на что подписываетесь.
Зная риски, вы сможете оценить текущую ситуацию, свои силы и правильно построить беседу с руководителем. И уменьшить вероятность ситуации, когда план проекта нереализуем.
Ниже перечислены вопросы по процессам планирования, отчетности и управления рисками, которые следует задать. Звездочкой отмечены наиболее приоритетные.
Важно понимать, что к анализу ответов на вопросы надо подходить так же серьезно, как вы подходите к сбору требований перед проектированием архитектуры сложного сервиса. Но при этом не стоит переусердствовать и задавать сразу все вопросы из списка. Если вам скажут, что есть методика планирования, то сначала изучите её: скорее всего, она ответит на 80% вопросов. Если вы просто скинете или прочитаете своему руководителю весь список, то у него появится вопрос к вашей адекватности.
Вопросы по процессам планирования, отчетности и управления рисками
По процессам планирования и отчетности задаем следующие вопросы:
по входным артефактам:
где описана методика планирования: *
где описаны требования, ограничения и допущения плана;
где описана структура плана;
где описана форма документов с планом;
на каких данных строится план; *
какие исходные данные подтверждены, какие надо перепроверить; *
какая уверенность в оценке для каждой задачи;
как рассчитывалась длительность этапов и задач;
какие работы учитывали, а какими пренебрегали;
какие задачи плана имеют максимальный приоритет и почему (ценность для заказчика); *
как определялись приоритеты и кто может их изменить;
сколько времени даётся на сбор исходных данных для плана и подготовку плана; *
где описана методика с критериями оценки качества плана; *
на какой состав команды рассчитан план; *
есть ли матрица компетенций, требуемых для проекта, и описание, какими специалистами компании и команды они закрываются; *
где фиксируются плановые отпуска и отсутствия сотрудников; *
учитывает ли план отпуска; *
есть ли планы за предыдущие годы: *
насколько факт совпал с планом, по какому принципу добавлялись или исключались задачи; *
где перечень результатов предыдущих этапов;
где находятся доказательства их готовности (протоколы испытаний, записи демонстраций и т. д.); *
есть ли подтверждения качества этих результатов; *
какие результаты необходимо перепроверять, актуализировать; *
где инструкция по созданию и утверждению плана;
где ведется реестр коммитов: *
какие коммиты есть в рамках плана с руководством, смежными командами и заказчиками; *
какие коммиты есть с сотрудниками; *
кто, кому и когда зафиксировал коммит; *
где он зафиксирован (чат, письмо, документ); *
есть ли план передачи (и согласования) результатов внутри компании и с заказчиком;
какие санкции или последствия наступят при невыполнении коммитов; *
кто является владельцем каждой задачи;
где описан реестр стейкхолдеров (матрица влияний, лица, принимающие решения, лица, влияющие на решения); *
есть ли нарушенные коммиты за предыдущие годы (если есть, то учтены ли они в плане, если нет, то какие последствия по ним будут); *
по выходным артефактам:
где описана методика подготовки отчетности по проекту: *
в каком формате нужно отчитываться (шаблон отчета); *
с какой периодичностью нужно отчитываться; *
сколько времени дают на подготовку отчетности; *
какие инструменты необходимо использовать;
какие метрики считаются доказательством выполнения плана; *
где описана методика контроля сроков проекта;
где описана методика контроля качества проекта;
где отчеты по фактическому состоянию проекта; *
где отчёты за предыдущие годы, кварталы и этапы;
где описана методика контроля объема работ и затраченных ресурсов.
По процессам управления рисками задаем следующие вопросы:
где описана методика управления рисками (ведения реестра рисков, оценки вероятности и ущерба, мониторинга рисков, реагирования на риски);
какие риски наиболее актуальны для проекта и почему (технические, организационные, регуляторные, юридические, ресурсные, рыночные, личные конфликты лида с руководством); *
сколько времени выделяется на анализ рисков, оценку вероятности возникновения и величины последствий, формирование реестра и плана реагирования; *
сколько времени выделяется на мониторинг рисков; *
есть ли реестры рисков за предыдущие годы:
какие риски сработали;
какой был ущерб;
какие получилось нейтрализовать с помощью плана реагирования, а какие нет и почему;
в каких отношениях мы со стейкхолдерами, принимающими результаты (лицами, принимающими решения и лицами, влияющими на решения); *
какие задачи и ситуации становились причиной конфликтов и эскалаций между членами команды, заказчиками, командами; *
по каким причинам ушёл предыдущий тимлид; *
с кем в первую очередь из команды надо провести 1-1; *
какие риски нельзя транслировать в команду.
Большую часть вопросов выше опытный аналитик может составить сам, смоделировав процессы планирования, отчетности и управления рисками. Например, “happy path” типового процесса планирования выглядит так:
В конце года, квартала и/или этапа проекта начинается планирование следующего периода. Сначала тимлид или руководитель проектов собирает данные для планирования. Далее по принятой в компании методике формирует цели, декомпозирует задачи, оценивает их с учетом рисков и приоритетов.
Когда план готов, проводится оценка его качества. Это важный этап, т. к. часть работ в плане может не учитываться, некоторые оценки могут быть слишком абстрактными. Например, если компания уже несколько раз проходила сертификацию изделий в ФСБ, то вся документация уже готова, и это типовая задача, а значит, в плане может быть указана точная оценка.
А если в компании никто не занимался сертификацией и планируется привлечение подрядчика, то оценка сроков по задаче ценности не имеет. Срыв сроков сертификации должен быть в реестре рисков, а в плане должен быть резерв по времени для этой задачи. Если оценки слишком общие, большая часть работ и рисков не учтена, то план не должен проходить этап оценки качества.
После оценки качества план утверждается. Дополнительно может проводиться защита плана перед руководителем или специальной экспертной комиссией. Далее контролируется выполнение плана и готовится отчетность.
Как видно по схеме, процесс управления рисками тесно связан с планированием. Хороший план должен учитывать риски, их вероятность и тяжесть последствий.
Как вы могли заметить, даже упрощенная схема процесса позволяет сформулировать и задать самые важные вопросы по входным и выходным артефактам, по временным и качественным параметрам. Согласитесь, странно, если артефактов нет, на сбор данных и планирование не выделяется время и никто не контролирует качество плана? Значит, план - только формальный документ, который никому не нужен и на который нельзя ориентироваться.
Собрав информацию о рисках, важно не забыть обсудить их с юристом. По реестру коммитов и плану передачи результатов уточните, потребуются ли от вас какие-то подписи, если да, то какую ответственность они предусматривают.
Если к текущему времени у вас не получилось собрать базовую информацию по состоянию дел, рискам и результатам, то возможны ситуации, когда всё очень плохо и вам не хотят показывать реальную картину, или предыдущий тимлид пришел из организации, где не было планирования и управления рисками.
В обеих ситуациях надо пойти к руководителю и сказать, что у вас нет минимальных данных для принятия решения. Чтобы потом о нём не жалеть, не отказываться от команды и не делать проекту ещё хуже, уточните, есть ли возможность отсрочить принятие решения и провести аудит плана, рисков и результатов проекта.
Если времени не дают и торопят, то лучше отказаться от проекта. А если по какой-то причине отказаться нельзя, то попробуйте договориться взять на себя временно роль и. о. тимлида, пока будет идти поиск подходящего кандидата. Это всегда можно обосновать желанием дальше развиваться в направлении аналитики, проектирования высоконагруженных систем и автоматизации процессов с последующим переходом в архитекторы, а не на руководящую должность.
Если есть возможность, то все полученные данные лучше обсудить с более опытным непредвзятым коллегой-тимлидом, чтобы он оценил, стоит ли брать ответственность за такой проект.
К этому моменту вы уже проанализировали ситуацию и подготовили следующие артефакты:
годовые, квартальные и поэтапные планы проекта с пониманием, насколько они актуальны и качественны;
реестр коммитов с сотрудниками, смежными командами, заказчиками;
ретроспективные данные по планам, рискам и коммитам;
перечень результатов предыдущих этапов со ссылками на артефакты, подтверждающие их актуальность;
реестр рисков по проекту, сотрудникам, процессам, юридическим моментам и т. д.;
оценку более опытных коллег, насколько стоит связываться с таким проектом.
Если вы пока ещё согласны принять проект и команду, то переходите к следующему шагу - анализу остальных руководящих процессов компании, в которых участвует тимлид.
3. Изучаем руководящие процессы
Анализ процессов планирования, отчётности и управления рисками даёт самые важные артефакты для принятия решения о взятии ответственности за команду и проект. Но это малая часть процессов, в которых участвует тимлид. Есть другие активности, которые сильно влияют на качество работы команды. Например, найм и онбординг сотрудников, разбор инцидентов на проде, подготовка к релизам, передача дел в случае отпуска или форс-мажора и т. д.
Поэтому на следующем шаге надо составить реестр руководящих процессов тимлида в компании, а потом постараться наложить их на свой календарь и план проекта. Это позволит понимать, где вы сейчас находитесь, и видеть самые критичные и близкие активности. Также это поможет увидеть конфликты между проектными и руководящими активностями и составить план для их разрешения.
В реестре руководящих процессов по каждому критичному необходимо уточнить:
есть ли инструкция или методика с описанием процесса;
какие артефакты входные;
какие артефакты выходные;
частота запуска;
триггеры запуска;
ценность процесса;
сколько времени тратится на подготовку процесса;
сколько времени тратится на выполнение основных этапов процесса;
как оценивается качество результата процесса;
примеры входных и выходных артефактов;
владелец процесса.
Если процесс критический для руководства, вас или команды, а по нему нет описания, артефактов и примеров, то можно смело заносить его в риски и заранее продумать, как его выполнять, когда он внезапно “прилетит”.
Если описание, артефакты, примеры и владелец есть, то это минимизирует риск, можно вносить процесс в календарь и планово к нему готовиться.
В предыдущей компании я частично выполнял роль методолога и формализовал большое количество процессов, включая руководящие. Ниже приведён их список.
Их очень много, все они важны. Но чтобы делать их качественно, надо работать над ними по 16 часов в сутки без выходных и ничем больше не заниматься. В реальной жизни это невозможно. Ведь если возникает проблема, например, баг на проде, который блокирует заказчика, вы как тимлид бросаетесь её решать и на несколько дней выпадаете из рабочего процесса.
Календарь поможет увидеть процессы, которые будут на ближайшей неделе, а приоритеты помогут понять, какие из них настолько важны, что их надо просматривать, даже когда “горит прод”, а какими можно пренебречь.
Ниже приведен список процессов, в которых участвовали тимлиды и заместители руководителей отделов нашей компании. Звездочкой отмечены наиболее приоритетные, по которым желательно уточнить описанную выше информацию.
Список руководящих процессов
годовые:
годовое планирование целей и задач команды; *
годовое планирование целей и задач тимлида; *
подготовка плана развития команды;
подготовка плана развития тимлида;
подготовка списка командировок;
подготовка списка внешних обучений;
планирование отпусков; *
планирование изменений;
аудит и верификация существующих процессов;
планирование расширения профессиональных связей и влияния;
анализ своих слабых сторон как источников рисков; *
подготовка реестра рисков на следующий год; *
анализ сработавших за год рисков; *
оценка годовых результатов команды; *
оценка работы сотрудников; *
оценка годовых результатов тимлида; *
планирование профессионального продвижения тимлида как лидера, управленца и технического специалиста;
оценка эффекта от изменений;
оценка личного психологического и физического состояния (уровня стресса);
оценка баланса между работой и личной жизнью;
планирование мер по сохранению психологического и физического состояния (снижение уровня стресса);
планирование мер по сохранению баланса между работой и личной жизнью;
ежеквартальные:
квартальное планирование целей и задач команды; *
квартальное планирование целей и задач тимлида; *
квартальное планирование целей и задач отдельных сотрудников; *
планирование и согласование отпусков и плановых отсутствий; *
оценка мотивации сотрудников;
квартальное планирование изменений;
планирование коммуникаций с заинтересованными сторонами; *
анализ своих слабых сторон как источников рисков; *
уточнение реестра рисков; *
анализ сработавших за квартал рисков; *
анализ признаков выгорания сотрудников; *
оценка команды по результатам квартала; *
оценка квартальных задач сотрудников и подготовка обратной связи;
оценка личных результатов квартала тимлида; *
подготовка отчетности по кварталу; *
планирование расширения профессиональных связей и влияния;
планирование контроля качества результата работы;
оценка личного психологического и физического состояния (уровня стресса);
оценка баланса между работой и личной жизнью;
планирование мер по сохранению психологического и физического состояния (снижение уровня стресса);
планирование мер по сохранению баланса между работой и личной жизнью;
ежемесячные процессы:
ежемесячное планирование команды;
ежемесячное планирование тимлида;
анализ сработавших за месяц рисков; *
оценка результатов месяца работы команды;
оценка личных результатов месяца работы тимлида;
оценка личного психологического и физического состояния (уровня стресса);
анализ рисков по итогам месяца (планирование реагирования на риски);
процессы спринта:
планирование спринта тимлида; *
подготовка и проведение триажирования задач; *
подготовка и проведение груминга задач; *
балансирование команды в задачах (перераспределение задач с учетом загрузки и компетенций);
подготовка и проведение планирования спринта команды; *
релиз задач; *
подготовка и проведение ретро;
анализ результатов спринта команды;
фиксация результатов спринта тимлида;
проведение 1-1 с сотрудниками; *
проведение 1-1 с руководителем; *
анализ признаков выгорания сотрудников;
организация шаринга знаний;
ретро по личным результатам спринта;
анализ психологического состояния сотрудников;
анализ сильных и слабых сторон сотрудников;
анализ рисков (планирование реагирования на риски); *
еженедельные процессы:
планирование недели тимлида;
планирование недели команды;
анализ личных результатов недели тимлида;
анализ результатов недели команды;
актуализация статусов проектов (эпиков);
анализ рисков (планирование реагирования на риски);
ежедневные процессы:
планирование дня тимлида; *
проверка готовности команды (health-check); *
проверка метрик сервисов; *
проведение синка с командой; *
пополнение и актуализация бэклога; *
разбор и устранение инцидентов с прода; *
анализ проблемных задач и решение срочных вопросов, блокирующих работу команды; *
фиксация результатов дня тимлида; *
фиксация результатов дня команды; *
анализ рисков (планирование реагирования на риски); *
процессы по запросу:
инициация нового проекта;
планирование проекта; *
подготовка задания на найм нового сотрудника;
анализ кандидатов;
проведение собеседований;
организация онбординга нового сотрудника; *
организация оффбординга (передачи дел) сотрудника;
увольнение сотрудника;
подготовка и участие во встречах; *
решение конфликтов внутри команды; *
решение конфликтов между смежными командами, подразделениями и заказчиком; *
ретро по крупным инцидентам;
передача дел в случае форс-мажора; *
подготовка заявки на повышение грейда сотрудника;
передача дел на отпуск; *
составление индивидуального плана развития сотрудника;
подготовка внеплановых отчетов для руководства;
подготовка отчетности по проекту; *
подготовка мини-обучений для развития и внедрения изменений;
закрытие проекта.
К текущему моменту у вас появятся следующие артефакты:
реестр рисков, дополненный проблемами по критическим процессам;
реестр руководящих процессов, наложенный на календарь и план проекта;
план решения конфликтов между проектными и руководящими активностями.
Дальше вам потребуется:
отделить легаси условия проекта и команды от своих недостатков;
подготовить план развития компетенций.
Давайте этим займемся.
4. Отделяем легаси условия от своих недостатков
Теперь надо отделить легаси (начальные) условия от ваших недостатков. Для этого составьте список ваших слабых сторон и снова пересмотрите и дополните реестр рисков, учитывая их. Вы должны понять, какие риски возникают или усиливаются от ваших недостатков, а на какие они не влияют.
Риски, которые уже сработали или с высокой вероятностью произойдут и на которые вы не влияете, - это легаси условия.
Если риски появляются или становятся критичными именно из-за ваших слабых сторон и вы можете на них повлиять, то оценивайте это как следствие отсутствия у вас руководящих компетенций.
Дополнительно может быть промежуточная серая зона - когда у вас не получилось собрать данные по риску и пока не ясно, можете ли вы на него влиять. Такие риски лучше вынести в отдельный список и считать легаси условиями, пока не появится уточняющая информация.
Также к легаси условиям относите риски, которые вы можете усугубить, но у вас нет полномочий, чтобы на них повлиять. Например, вы недостаточно погружены в предметную область. Вы знаете, какими курсами это можно закрыть. Но руководитель говорит, что времени на обучение нет. Значит, это тоже легаси условия.
Для определения своих слабых сторон и составления плана развития попросите обратную связь у коллег, уходящего тимлида или руководителя.
Если это не помогло, то в самом базовом виде можно использовать фреймворки компетенций IPMA Individual Competence Baseline (IPMA ICB) и Project Manager Competency Development Framework (PMCD Framework).
Например, PMCD говорит, что хороший руководитель должен:
иметь хорошую теоретическую базу по управлению проектами и командами (окончить курсы и пройти сертификацию для оценки знаний);
иметь опыт применения техник и инструментов для управления проектами и командой;
обладать отличными личными компетенциями (софтами).
Кроме описанных выше, в стандарте есть ещё две области компетенций:
специфические для отрасли;
специфические для организации.
Этих областей компетенций хватит, чтобы грубо оценить, что вам надо развивать в первую очередь и на какие курсы идти. Стоит учесть, что отсутствие пары компетенций усиливает риски.
Например, вы сильный системный аналитик, проектирующий высоконагруженные решения. У вас хорошие аналитические харды, вы знаете специфику организации: как работают разработчики, QA, DevOps-инженеры, как выпускаются релизы.
Вам предложили взять проект по развитию сервиса формирования отчетности по градостроительной деятельности. Давайте оценим ваши компетенции:
теоретическая база по управлению проектами и командами почти отсутствует;
опыт применения техник и инструментов для управления проектами почти отсутствует;
личные компетенции (софты) есть, но специфичны для системного аналитика;
компетенции, специфические для отрасли, частично присутствуют, т. к. вы уже несколько лет проектировали сервисы в сфере градостроительной деятельности;
компетенции, специфические для организации, хорошие, т. к. вы прекрасно знаете, как работают разработчики, QA, DevOps.
С таким набором компетенций (только одна из четырех практических областей закрыта хорошо), если времени на обучение нет, и передаваемый проект “горит", лучше от него отказаться. Вы не успеете быстро закрыть свои недостатки и только усугубите ситуацию на проекте. Лучше передать такой проект тому, у кого меньше проблемных областей компетенций.
Если время на обучение есть, составьте плотный план: погружение в управление проектами и командами, изучение специфики отрасли, развитие софтов. Просите хотя бы на время выделить себе в помощь сотрудников, которые помогут нивелировать ваши слабые стороны. И отметьте в реестре рисков, что вы можете обострить все процессы, где нужны планирование, управление командой, эффективная коммуникация и знание специфики отрасли, например, квартальное планирование, сложные переговоры, конфликты между смежными командами и т. д.
При переходе из аналитика в тимлиды важно учитывать, что хорошие для системного аналитика софты могут казаться заказчику и коллегам “токсичными”. Для аналитика важно скрупулезно подходить к требованиям и архитектуре. А привычка задавать много вопросов может восприниматься заказчиком и командой как микроменеджмент или попытка “докопаться” до мелочей. Вместо того чтобы управлять специалистами, которых вам дадут в помощь, вы рискуете настроить их против себя.
К данному моменту у вас должны дополнительно появиться:
оценка своих недостатков;
реестр рисков, дополненный с учетом недостатков;
план развития компетенций;
список легаси условий, который будет аргументом при обсуждении с руководителем условий принятия проекта и команды.
Дальше нужно оценить, насколько управляемы процессы работы с проектом и командой: от этого напрямую зависит уровень негатива и стресса на проекте в первые месяцы работы.
5. Оцениваем управляемость процессов работы с проектом и командой
Выполнив предыдущие пункты статьи, вы уже отлично поработали над предсказуемостью и управляемостью процессов работы тимлида и команды, а значит, и над снижением уровня стресса и негатива:
теперь у вас в календаре есть ближайшие критичные проектные и управленческие активности с приоритетами, инструкциями и примерами, вы можете заранее к ним подготовиться, врасплох они вас уже не застанут;
у вас есть реестр рисков, вероятность их возникновения и план реагирования на каждый;
у вас есть реестр коммитов и план подготовки и передачи результатов, поэтому вы знаете, кому, что и когда должны отдать;
у вас есть понимание своих слабых сторон и план их устранения и минимизации ущерба, если они сработают;
у вас есть план решения конфликтов между критичными руководящими процессами и активностями проекта.
Следующим шагом важно уточнить у руководителя и старого тимлида, какие ещё рычаги у вас есть для влияния на проект, команду, заказчиков, процессы:
есть ли возможность пересмотреть объём, план, приоритет работ;
есть ли возможность запросить дополнительные ресурсы для закрытия своих слабых сторон и развития руководящих компетенций;
есть ли возможность отказаться от коммитов;
есть ли возможность перераспределить роли или ротировать сотрудников, которые будут против вашего назначения;
есть ли возможность запрашивать помощь у других команд и отделов компании;
есть ли возможность нанимать или увольнять сотрудников;
какими способами можно мотивировать сотрудников (рост зарплаты, должности, компетенций и т. д.);
есть ли возможность подготовить в команде своего заместителя (в том числе оплатить ему обучение, аналогичное вашему);
есть ли возможность отказываться от выполнения и эскалировать запросы на новые задачи от смежных подразделений.
Для разговора с руководителем подготовьте список рисков, которые можно на него переложить. Он может завязать на себя часть сложных коммуникаций с заказчиком, сотрудниками, смежными командами. Освободить вас от части отчётности или снизить требования к объёму её подготовки. В итоге в реестре рисков вы отметите, какие риски могут быть эскалированы вашему руководителю. Если вы согласуете этот перечень на итоговой беседе, то частично негатив и плохо управляемые риски будут уходить к нему, минуя вас.
Будет отлично, если вы найдёте опытного ментора или коллегу, который поможет в первый раз пройти все процессы, чтобы качество результата было максимально предсказуемым.
С ним можно открыто разобрать сработавшие риски: какие ваши решения повлияли на ситуацию и как снизить вероятность повтора, а какие обстоятельства были вне зоны вашего влияния.
К этому моменту вы собрали все материалы, которые помогут в будущем сделать вашу работу и работу вашей команды максимально предсказуемой и управляемой, а следовательно, снизить уровень негатива и стресса.
Но даже если у вас есть план реагирования на каждый риск и рычаги влияния на планы, коммиты и команду, негатива в первые месяцы всё равно может быть очень много.
Переизбыток негатива и стресса, а также ощущение, что любые ваши действия либо не приносят результата, либо только ухудшают ситуацию, могут привести к апатии. Вы перестанете использовать рычаги, просматривать реестр рисков и методически бороться с неэффективностью. Просто будете смотреть, как всё "догорает", и даже радоваться этому.
Поэтому важно дополнительно оценить, насколько психологически сложной для вас будет работа в первые месяцы.
Допустим, рисков много, рычагов почти нет, впереди конфликты с заказчиками и внутри команды. При этом вы тяжело переносите критику, у вас нет ментора и поддержки близких. В такой ситуации стоит серьёзно подумать об отказе от проекта, чтобы сохранить сам проект, а также свои нервные клетки и здоровье близких.
Если близкие, ментор и руководитель вас поддерживают, есть рычаги управления проектом и командой, вы легко переносите конфликты и стресс, регулярно занимаетесь спортом, прогулками и хобби, то можно браться даже за сложные проекты.
Но важно понимать, что спорт, прогулки, хобби и поддержка близких только замедляют выгорание, а не устраняют причину тревожности и негатива - непредсказуемую и неуправляемую организацию работы.
Поэтому важно регулярно оценивать свое состояние, состояние коллег и проекта. Для этого можно посоветовать чаще смотреть в календарь и стараться разносить критические активности по времени. И дополнительно поднять приоритет и добавить в календарь ежемесячные процессы:
оценки личного психологического и физического состояния (уровня стресса) тимлида;
оценки результатов работы команды;
оценки личных результатов работы тимлида;
анализа сработавших рисков.
Если количество конфликтов, сработавших рисков, уровень стресса и негатива растут, а качество результата не повышается, то это тревожный сигнал. Либо проекту уже не помочь, либо ваших ресурсов и опыта недостаточно, чтобы вывести его из кризиса. И лучше заранее обсудить с руководителем такую ситуацию, чтобы она попала в реестр рисков и было понятно, как вы будете на неё реагировать.
К текущему моменту у вас должны дополнительно появиться:
список возможных рычагов влияния на проект;
список рисков для эскалации руководителю;
оценка уровня стресса и негатива;
реестр рисков, дополненный планом реагирования на случай, когда уровень стресса и негатива растет, а качество результата не повышается.
Теперь можно перейти к последнему шагу - подготовке к беседе с руководителем.
6. Готовимся к беседе с руководителем
На текущий момент вы собрали все материалы, которые потребуются для встречи с руководителем, на которой вы обговорите и зафиксируете условия принятия проекта и команды.
Информации, которую вы собрали, может быть очень много, поэтому подготовьте краткое резюме по состоянию дел. В нём укажите:
этапы, которые выполнили;
документы, которые собрали;
краткую выжимку по каждому документу (плану, реестру рисков, реестру результатов со статусом подтверждения, реестру коммитов и т. д.).
Резюме надо выслать заранее, чтобы руководитель успел с ним ознакомиться и при необходимости дозапросить у вас данные или перепроверить их лично.
Далее можно начинать подготовку ко встрече и разговору с руководителем. Ниже приведен шаблон подготовки к встрече.
Шаблон подготовки к встрече
Подготовка к встрече
Цель встречи: обговорить и зафиксировать условия принятия проекта и команды
Состав участников:
аналитик (будущий тимлид);
руководитель тимлида.
Материалы для подготовки:
краткое резюме, агрегирующее информацию, которую получилось выяснить (отправляется руководителю до встречи или указывается ссылка в повестке);
список легаси условий - текущая ситуация на проекте (проблемы с планом, проверяемостью результатов, потерей коммитов и т. д.);
предложения по дополнительному аудиту;
предложения по плану и графику вашего развития (обучения) и его совмещению с выполнением проекта;
предлагаемый список рисков для эскалации;
предлагаемые условия перехода (зарплатные ожидания, повышение в должности, менторство, развитие);
список возможных рычагов влияния на проект (пересмотр плана, отказ от коммитов, запрос дополнительных ресурсов, ротация нелояльных сотрудников и т. д.);
условия отказа от роли тимлида (если вскроются критические риски или ситуация на проекте не улучшится за 3 месяца);
предлагаемые измеримые признаки, по которым будет оцениваться состояние проекта.
Анализ сторон
Сторона: аналитик (будущий тимлид).
Цели: принять проект и команду на выгодных условиях или отказаться от них.
Мотивы:
карьерный рост;
увеличение зарплаты;
развитие компетенций;
минимизация рисков, стресса и конфликтов;
сохранение лояльности (хороших отношений с руководством).
Сторона: руководитель.
Цели: передача проекта.
Мотивы:
увеличение зарплаты (получение премии за закрытый проект);
закрытие проекта с минимальными рисками для компании.
Возможные возражения руководителя и ответы на них:
Возражения от руководителя | Ответ на возражение |
Руководитель давит, чтобы вы взяли проект, но условия вас не устраивают. | Я разделяю ваше беспокойство по проекту и сам хочу, чтобы он успешно завершился. Я понимаю, насколько он сложный и что мгновенно найти для него руководителя не получится. И готов временно взять роль и. о. тимлида, пока не найдется новый. Но дальше я хочу приносить пользу компании как аналитик, развивая аналитические харды, проектирование высоконагруженных систем и автоматизацию процессов с последующим переходом в архитекторы, а не на руководящую должность. |
Руководитель предлагает слишком высокие KPI при скромных бонусах и рычагах. | Я могу попробовать взять ответственность за эти KPI. Но при текущих легаси условиях и без необходимых рычагов (например, права пересмотреть сроки или получить дополнительные ресурсы) риск их не выполнить очень высок. Если KPI важны для вас, давайте обсудим, какие инструменты вы можете дать для их достижения. |
Если после беседы не хватает данных, чтобы принять решение (руководитель согласился на часть ваших условий, но их может быть недостаточно, чтобы вытянуть проект из кризиса). | Чтобы взять на себя ответственность за команду и проект с предложенными рычагами, мне нужно более точно понимать его состояние. Можете дать 3 дня на аудит плана, рисков и результатов проекта? Это значительно снизит риск, что я соглашусь, а потом откажусь и сделаю проекту хуже. |
Если руководитель настаивает, что ситуация лучше и проще, чем вы думаете. Или говорит, что другой аналитик взял аналогичный проект без дополнительных условий и успешно его завершил. | Я допускаю, что вы правы. Но собранная информация показывает, что рисков значительно больше. И если мы их не учтём, то повторим ошибку предыдущего тимлида. |
Матрица приемлемых условий (нужно скорректировать оценку в центральном столбце и посчитать сумму, которая для вас будет приемлемой, чтобы принять проект и команду)
Параметр | Минимальное значение | Допустимое значение | Максимальное значение |
Риски | 1 (есть юридические риски) | 5 (рисков много, но часть берёт на себя руководитель, плюс будет ментор) | 10 (минимальны – результаты подтверждаются, есть время на аудит, есть ментор и т. д.) |
Заработная плата | 1 (не поднимется) | 5 (существенное увеличение заработной платы) | 10 (существенное увеличение заработной платы, плюс премия или процент от проекта) |
Должность | 1 (останется прежней) | 5 (повысится, но при выполнении условий или KPI) | 10 (повысится) |
Уровень компетенций | 1 (останется прежним) | 5 (будет выделено время на развитие критичных компетенций) | 10 (будут выделены время и средства на развитие всех компетенций) |
Следите на встрече за тем, чтобы оценка предлагаемых вам условий не была ниже той, на которую вы рассчитывали.
Наша позиция
Готовы взять проект и команду, если вознаграждение будет соответствовать ответственности и рискам.
Готовы мягко отказаться, если риски и ответственность больше, чем вознаграждение.
Задачи встречи
Рассказать краткое резюме по тому, что получилось выяснить по проекту и рискам.
Обговорить и зафиксировать:
список легаси условий;
договоренности по дополнительному аудиту;
план и график вашего развития (обучения) и его совмещение с выполнением проекта;
список рисков для эскалации;
условия перехода;
рычаги влияния на проект;
условия отказа от проекта;
измеримые признаки, по которым будет оцениваться состояние проекта (отказ или успешное закрытие).
План встречи с таймингами:
рассказать краткое резюме по тому, что получилось выяснить (15 минут);
обсудить каждый пункт из задач выше и зафиксировать решение (10 минут на каждый пункт);
зафиксировать результат встречи в Meeting Notes (20 минут).
7. Подводим итоги
Если вы хороший аналитик, то прекрасно понимаете: перед тем как принимать решение о реализации сложной системы, надо тщательно собрать и проанализировать все требования.
Проект и команда - это тоже очень сложные динамические системы. Не стоит брать на себя ответственность за них без тщательной предварительной подготовки.
Не обольщайтесь проектом как “вызовом и точкой роста”. Отличные аналитические харды и новая должность сами по себе не добавят вам ни ресурсов, ни полномочий, ни времени и не помогут "вытащить" безнадежный проект.
Для обсуждения с руководителем условий принятия проекта и команды постарайтесь подготовить:
описание текущего состояния проекта и команды;
перечень результатов с указанием, какие из них подтверждены, а какие - нет;
предложения по дополнительному аудиту результатов;
список критичных рисков;
перечень ваших недостатков;
план и график вашего развития;
список возможных рычагов влияния на проект;
предлагаемые условия перехода;
условия отказа от проекта;
предлагаемые измеримые признаки, по которым будет оцениваться состояние проекта;
ответы на возможные возражения руководителя и формулировки мягкого отказа.
Вы должны понимать, что от начальных условий результат проекта зависит не меньше, чем от ваших компетенций. Поэтому очень важно выяснить эти условия, обговорить, письменно зафиксировать и получить рычаги, с помощью которых их можно изменять.
Чтобы из хорошего аналитика стать хорошим тимлидом, нужны ресурсы, поддержка и рычаги влияния на работу. Если вместо них вам передают только роль тимлида и ответственность, есть риск потерять аналитические харды, так и не развив управленческие. Кроме того, перегрузка может привести к выгоранию, конфликтам с близкими и коллегами, хроническому стрессу и обострению проблем со здоровьем.
Надеюсь, что, выполнив шаги из разделов 2-6 статьи, вы сможете повысить вероятность принять проект и команду на условиях, соразмерных рискам, и стать хорошим тимлидом!
Спасибо, до новых встреч!
Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.