Тимлид и проджект менеджер в чем разница

Разработка веб-сервиса: зачем на проекте тимлид, ПМ и тестировщик?

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

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

«Может, все-таки обойдемся без проджект-менеджера?»

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

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

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

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

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

«Так, хорошо, проджект-менеджер организует работу команды. Зачем тогда тимлид?»

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

Команда состоит из разработчиков различного уровня — junior, middle, senior. Начинающие программисты решают небольшие и относительно простые задачи, опытные разработчики — пишут сложные части кода. Среди задач тимлида в команде — руководство процессом, принятие ключевых решений и контроль качества.

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

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

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

«Ок, тимлид тоже нужен. Но если он контролирует качество, зачем платить тестировщику?»

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

Но каждое приложение все равно проходит QA-тестирование. Тесты бывают двух типов:

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

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

«А что, вообще не тестировать нельзя?» — возражают некоторые. Здесь ответ однозначен: нет, нельзя. Даже если над проектом работают профессионалы с большим опытом, вероятность появления багов сохраняется. Например, если два разработчика напишут хороший код, то при объединении этих фрагментов все равно могут возникать ошибки — это нормальная ситуация. Веб-сервис или мобильное приложение — комплексная структура, и сложно заранее предположить, как на практике станут взаимодействовать ее части, даже если сами по себе они работают без проблем. Чем сложнее продукт, тем больше вероятность, что появится ошибка, которая может стоить заказчику лояльности пользователей. Эту проблему как раз решает многоэтапное тестирование.

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

Заказчики иногда спрашивают: «Но ведь даже после тестирования появляются баги, в чем тогда смысл?». К сожалению, даже опытный тестировщик не выявит все баги. Некоторые из ошибок имеют «плавающий» характер: они могут не воспроизвестись при тестах, но спонтанно появиться после запуска приложения. Но это не значит, что можно отказаться от проверок. Одна всплывающая ошибка не так критична для репутации приложения, как целый набор багов.

«И что в итоге? Сколько стоит разработка веб-сервиса?»

Цена создания веб-сервиса или мобильного приложения включает в себя оплату работы членов команды. Чтобы результат удовлетворил и заказчика, и целевую аудиторию, над ним трудятся не только разработчики, но и:

• проджект-менеджер;
• тимлид;
• тестировщик.

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

Тимлид и проджект менеджер в чем разница

Чем отличается продакт-менеджер от проджект-менеджера?

Содержание

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

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

Чем отличается продакт-менеджер и проджект-менеджер

Для понимания отличий между двумя специалистами достаточно рассмотреть базовые определения понятий:

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

Получайте статьи и полезные материалы о мире IT

Полезные материалы по продакт-менеджменту, аналитике, маркетингу и разработке каждую неделю

Нас читает более 11 000 человек

Таблица сравнения продакт-менеджера и проджект-менеджера

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

Кто важнее в команде:
продакт или проджект?

Данным вопросом часто задаются собственники бизнесов для понимания, кого нанимать в команду в первую очередь. Чтобы получить доходчивый ответ, посмотрите на картинку →

Допустим, заднее колесо — проджект, а переднее — продакт. Если убрать одно из них, велосипед поедет? Вряд ли, придется потратить много усилий.

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

А если нанять одного специалиста, который будет выполнять функции продакт и проджект? Это вполне возможно, но давайте посмотрим еще на одно изображение →

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

С продакт- и проджект-менеджером принцип аналогичный.

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

Ключевые навыки продакт-менеджера

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

Также он должен владеть следующими навыками:

• Понимание основ бизнеса. Объем и возможности рынка, анализ конкурентов, позиционирование продукта, ценообразование, каналы продвижения, взаимодействие с партнерами, создание финансовой модели и т.д.
• Экспертность в нише продукта. Знание потребностей клиентов; понимание, какой продукт будет удобным для конечного потребителя.
• Умение принимать сложные решения. Для достижения успеха принимаются десятки решений, порой они очень сложные, но нацелены на конечный результат.
• Лидерство. Нужно уметь вести людей за собой, мотивировать их на работу, когда уже не хочется выполнять ее.
• Сбор и анализ данных. Работа с популярными системами метрики, сбор необходимых данных и их анализ для внесения изменений в работу.
• А/В тестирование. Важно не только предполагать успешные решения, но и уметь тестировать их за короткий промежуток времени.
• Прототипирование интерфейсов. Нельзя постоянно занимать время разработчиков для создания многочисленных интерфейсов новых продуктов или функций. Необходимо уметь делать прототипы с помощью специального программного обеспечения для быстрого тестирования на потенциальных потребителях.

Ключевые навыки проджект-менеджера

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

Также он должен владеть следующими навыками:

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

За что отвечают продакт и проджект?

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

Возьмем пример с уборкой.

Продакт-менеджер определяет задачу — надо сделать генеральную уборку (отвечает на вопрос, что сделать).

• Проджект-менеджер — формирует план уборки с точными сроками и необходимыми ресурсами (отвечает на вопрос, как сделать).

За что отвечает продакт-менеджер

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

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

Таким образом, продакт должен задавать себе вопросы:

• что мы создаем?
• какую проблему это решит?
• какую пользу это принесет?

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

За что отвечает проджект-менеджер

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

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

Таким образом, проджект должен задавать себе вопросы:

• какие ресурсы нужны?
• кто и что будет делать?
• когда будет получен результат?

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

С кем коммуницируют продакт и проджект

Несмотря на разный спектр обязанностей и зоны ответственности, современный подход создания новых продуктов предусматривает тесную взаимосвязь продакта и проджекта. Менеджеры постоянно контактируют между собой, командами и топ-менеджерами.

Коммуникации продакт-менеджера

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

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

Коммуникации проджект-менеджера

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

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

Роли в разработке IT-продукта: аккаунт, проджект-менеджер, тимлид

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

Разберемся с терминологией

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

• Аккаунт-менеджер (англ. account manager) выступает гарантом соблюдения обязательств перед клиентом, развивает с ним партнерские отношения, курирует команды проектов, решает любые нестандартные задачи и спорные вопросы.
• Проджект-менеджер (англ. project manager) помогает в непосредственной реализации технических задач: общение с командой разработчиков, бюджет, содержание и сбор требований по проекту, постановка целей, распределение задач и контроль за соблюдением сроков.
• Тимлид (англ. Team lead) необходим на масштабных проектах повышенной сложности (например, при разработке банковских продуктов). Он является руководителем группы разработчиков и отвечает за техническое управление.

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

Менеджеры на проекте

При формировании команды важно сразу определить, кто из участников за какие функции отвечает. Например, у нас для этого разработана документация – в частности, матрица RACI для распределения зон ответственности. Эта инструкция помогает закрепить обязанности за каждым участником проекта и избежать спорных ситуаций. Такой документ бывает необходим на старте и в процессе работы. Матрица зон ответственности также выступает в качестве индикатора и помогает выяснить, есть ли в команде все необходимые специалисты.

Рассмотрим подробнее, каким образом могут быть распределены обязанности между аккаунт-менеджером, руководителем проекта и тимлидом.

Аккаунт-менеджер – «правая рука» клиента на проекте

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

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

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

Проджект-менеджер или руководитель проекта

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

В числе его задач:

• Согласование с заказчиком плана работ, а также сроков.
• Формирование, организация и контроль работы команды.
• Распределение зон ответственности среди ключевых участников.
• Контроль соблюдения требований к разрабатываемому ПО, выполнения ограничений по сроку и бюджету.
• В случае изменений задач или любых отклонений от плана – анализ и корректирующие меры, согласованные с заказчиком, а также сбор и контроль метрик.

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

Руководитель группы разработчиков или тимлид

Тимлид подключается в первую очередь к масштабным проектам, где требуется техническое управление. В числе его задач:

Формирование сплоченной команды, ее микроклимата и корпоративной культуры.

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

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

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

Пример первый

Какие есть риски, когда роли на проекте смешиваются – показывает следующий пример. Представим, что штатной IT-команде нужно провести регрессионное тестирование в короткий срок. Для того чтобы успеть выполнить задачу, важно правильно определить объем работы. Сроки реализации могут затянуться, если владелец продукта хочет на всякий случай протестировать все целиком, проджект – фичи вместе с затронутой ими функциональностью, а тимлид – только новые фичи. Если порядок принятия технических решений не определен заранее, то выполнение задачи усложняется, появляются риски, что проект не уложится в сроки или бюджет.

Пример второй

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

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

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

Выводы

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

Заклятые друзья: почему проджект-менеджер и тимлид всё время ругаются

Привет! Я Саша Ворожищев, руководитель направления Flutter/iOS в AGIMA. Сейчас у нас в компании мир и покой, но мы еще помним времена, когда проджекты и тимлиды постоянно ссорились. Ссорились, само собой, из-за работы: каждый хотел доминировать на проекте и по-своему понимал задачи. Иногда к решению конфликтов подключались буквально все — вплоть до топ-руководителей. В итоге мы придумали, как не допускать таких стычек. И я расскажу об этом подробно.

Кто эти люди и что им делить

Вы точно знаете, чем занимаются проджект и тимлид, но давайте синхронизируемся. Это важно, потому что в разных компаниях эти роли понимают по-разному. Вот как их видим мы.

Проджект-менеджер (Project Manager). Отвечает за планирование и организацию процесса. Его цель — реализовать проект за определенный срок и уложиться в определенный бюджет. Он управляет ресурсами, ставит задачи и приоритеты, работает с заказчиком. ПМ владеет навыками управления рисками и конфликтами.

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

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

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

Разберем, почему они возникают, на конкретных примерах.

Кейс №1. Тимлид и проджект по-разному видят цели проекта

Срок сдачи проекта уже подходит. Заказчик давить на менеджера: хочет выкатить проект к определенной дате. Менеджер торопит команду, чтобы не нарушить обязательства. За неделю до релиза тимлид говорит: «У нас код так себе, нужен рефакторинг». Менеджер с ним спорит, времени нет. Но тимлид стоит на своем: отдавать проект со слабым кодом — плохая идея.

Как работать с проблемой:

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

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

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

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

Кейс №2. Тимлид и проджект не могут решить, кто главнее

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

Многое на проекте зависит от стиля лидерства. В этом случае проблема была как раз в том, что ребята пытались управлять по-разному. Наш CTO Андрей Непряхин недавно написал о стилях лидерства подробную статью. Пересказывать ее не буду. Напомню только, что стилей 4: диктатор, формалист, либерал, демократ.

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

✔️ Обсудить различия в стиле лидерства. Руководители могут выбрать тот стиль, который соответствует интересам проекта. Можно использовать методы анализа конфликтов, такие как техника «Взвешенного среднего» или метод «Четыре столпа».

✔️ Найти компромисс. Если руководители не могут найти общий язык, можно попытаться найти компромисс, который бы учитывал интересы обоих руководителей.

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

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

Кейс №3. У проджекта и тимлида разное отношение к планированию

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

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

Кейс №4. Проджект и тимлид по-разному оценивают риски

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

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

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

Кейс №5. Изначально проблемный проект

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

Тут нужно понимать, что к новому руководителю приковано внимание руководства. Значит, и ожидания высокие. Чувствуя такую ответственности, проджект/тимлид начинает давить на вторую сторону. Конфликты неизбежны, как минимум поначалу.

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

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

✔️ Установить приоритеты. Лучше сосредоточиться на задачах, которые имеют наибольшую значимость для проекта.

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

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

✔️ Проявлять гибкость. Проджект/тимлид должен быть гибким и готовым менять стратегию, если текущая не работает.

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

✔️ Установить реалистичные ожидания. Проджект/тимлид должны определить, чего реально достичь в оставшееся время. Заказчик должен понимать, что проект можно завершить только в определенных параметрах и с учетом рисков.

Итого: основные причины конфликтов

1. Человеческий фактор.

Что помогает решать конфликты

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

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

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

Что на эту тему почитать проджекту:

• Deadline. Роман об управлении проектами. Том ДеМарко.
• Цель. Процесс непрерывного улучшения. Элияху М. Голдратт.
• Искусство управления IT-проектами. Скотт Беркун.

Что на эту тему почитать тимлиду:

• Как пасти котов. Наставление для программистов, руководящих другими программистами. Рейнвотер Дж. Ханк.
• Семь навыков высокоэффективных людей. Стивен Кови.
• Практика лидерства. Питер Ф. Друкер.

Какой конфликт считать здоровым

Разберемся, что такое «адекватный конфликт» — это конфликт, при котором проект не страдает ни в финансовой части, ни в части качества кода. Что-то вроде конфликта интересов.

Рассмотрим самый распространенный случай. Что важно проджекту на проекте? Сделать его качественно и быстро. Он хочет, чтобы заказчик был доволен, и это правильно. В этом его основополагающая цель. Тимлиду важно правильно распределить ресурсы, оптимизировать их работу и нагрузку, сделать качественные решения. Иногда ему нужно отвлечь сотрудника от рабочего процесса, чтобы тот не выгорал. Нужно подумать, в какой релиз попадет задача.

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

Когда эскалировать конфликт руководству

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

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

Подводим итоги: как не допустить конфликтов между тимлидом и проджект-менеджером

1. Установить ясные роли и обязанности. Проджект и тимлид должны понимать, какие задачи им предстоит выполнять и как их работа взаимосвязана друг с другом.
2. Определить ясные цели и ожидания. При определении целей проекта и ролей проджекту и тимлиду необходимо ясно определить ожидания руководства и заказчика, а также предупредить об опасностях и рисках, связанных с проектом.
3. Создать коммуникационный план. Необходимо разработать план коммуникации, который определит частоту и формат взаимодействия между менеджером и тимлидом. Этот план должен учитывать разные каналы связи и быть связанным с целями проекта.
4. Определить и настроить процессы управления проектом. Нужно определить единый процесс управления проектом, который поможет понять, как они должны работать вместе, чтобы достичь общих целей.
5. Создать сплоченную команду. Создайте атмосферу доверия и взаимопонимания в команде, чтобы каждый участник мог высказывать свои мысли и мнение, и был готов помочь друг другу при возникновении проблем.
6. Регулярно обновлять статус текущих планов и этапов. Конфликты могут возникать, когда что-то в проекте неожиданно меняется. Регулярно срезайтесь и актуализируйте данные.

Расскажите, как обстоят дела у вас. Тимлид и проджект ругаются? Или в основном они лучшие друзья? И если есть проблемы, как вы их решаете?

А еще подписывайтесь на телеграм-канал AGIMA Dev. Вообще мы там рассказывает о разработке, но иногда и об управлении разработкой. И вообще давайте больше общаться — так что жду вас в тг.

Что еще почитать про управление разработкой:

• Как управлять конфликтами в команде разработки.
• Как мотивировать команду: основные правила и принципы.
• Как мы делаем тестирование прозрачным. Всё об инфраструктуре QA.
• Матрица компетенций: важный инструмент для мотивации команды.

• IT-компании
• управление проектами
• управление продуктом
• project management
• teamlead
• управление разработкой
• разрешение конфликтов