В чём ошибаются менеджеры и что с этим делать

5 ошибок менеджера проектов из личного опыта эксперта Практикума.

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

Здесь важно понимать, чего конкретно ждёт клиент, и корректировать ожидания, если они перестают совпадать с реальностью.

Представим ситуацию: заказчик хочет создать сложный веб-сервис. Понимания результата у него пока нет, но он хочет быстрее запустить разработку. Менеджер оценивает ситуацию: навскидку такой проект может занять 9 месяцев. Чтобы команда могла начать работу сразу, без проектирования всего проекта, лучше использовать схему Time & Material. В таком случае клиент оплачивает время команды и управляет приоритетами в разработке самостоятельно.

Проджект озвучивает план клиенту, тот соглашается. Кажется, всё в порядке: менеджер скорректировал ожидания и снял лишние риски.

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

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

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

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

Представьте себе ёлочку. Какая она получилась? Какой формы и размера? Есть ли на ней игрушки? Похожа ли она на реальное дерево?

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

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

В моей практике был такой случай: клиент попросил менеджера скрыть со страниц интернет-магазина товары, которых нет в наличии. Менеджер поставил задачу: «Скрыть товары не в наличии». Задача несложная, разработчик разберётся. Что могло пойти не так?

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

В чём ошибка: экономить время на продумывании ТЗ. Проджект уже понял задачу и мысленно уже написал ТЗ, поэтому есть соблазн опустить подробности. Разработчик и так разберётся или, по крайней мере, уточнит непонятное.

Но программисты, как и другие люди, плохо читают мысли. А ещё — очень редко признаются в том, что чего-то не поняли. Скорее всего, исполнитель молча начнёт копать не туда, потратит время и может даже навредить.

Как работать с ошибкой: научиться смотреть на ТЗ глазами новичка. Представьте, что вы не знаете ничего, кроме того, что зафиксировано в задаче. Получится ли сделать её? Хватает ли контекста? Нужно ли что-то угадывать или додумывать? Понятно ли, какой нужен результат?

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

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

Люди склонны ошибаться при оценке времени, чаще — в большую сторону. Работа трудносжимаема: её можно сделать за 150% времени, но крайне сложно за 50%, поэтому менеджеры стараются называть сроки с запасом. Но разработчики нередко не укладываются даже в дедлайны с запасом, команда подводит заказчика и теряет прибыль.

В чём ошибка: отпускать контроль за сроками.

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

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

На старте карьеры я обращался к программистам по любым вопросам: в моих глазах они были экспертами во всём, что касается веб-разработки. Когда я набрался опыта, то стал замечать, что некоторые разработчики не знают того, что знаю я.

Иногда это касалось элементарных вещей. Например, в моей практике программисты часто вставляли на сайт растянутую или сжатую картинку. Я недоумевал: неужели они думают, что так и надо? Чтобы разработчики получали заряд мотивации и быстрее подтягивали азы, я всегда высказывал им своё негодование. Но это не работало: в ответ приходил только негатив.

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

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

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

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

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

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

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

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