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

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

Ошибка №1. Непонимание метрики Remaining estimate и ее расчёта

Уверен, что все знают эту метрику, но на всякий случай введу в контекст: Remaining estimate — это сроки завершения проекта с учётом уже реализованной его части и переоценки оставшейся. Это теория, где всегда всё логично и просто.

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

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

Решение

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

Ошибка №2. Отсутствие понимания статуса проекта и текущих задач 

Анна Устина

проджект-менеджер Joy Dev

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

И ситуация, когда он ответ не получает в формате “здесь и сейчас”, может привести к не прозрачности процесса, а иногда и к появлению желания у клиента поменеджерить проект самостоятельно."

Решение

Проджекту в помощь придумано большое количество инструментов: это daily, статусы задач в системе учёта версий, ежедневные отчёты о проделанной работе, документирование статусов, наличие и количество комментариев в коммитах. 

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

Аня Устина, проджект-менеджер Joy Dev

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

Ошибка №3. Накопление технического долга и его устранение

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

Что происходит в реальной жизни? 

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

Как я это вижу со стороны?

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

Решение

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

Своевременные отчёты QA, отслеживание статистики по багам и реворкам, тестирование бизнес-логики проекта - всё это необходимый стартер-пак любого менеджера.

Ошибка №4. Неверное построение юнит-экономики и кэш-флоу

Анна Устина

проджект менеджер Joy Dev

“Начинающий проджект при составлении юнит-экономики проекта не в полной мере понимает принципы её составления: откуда берутся показатели, какие необходимо считать. Глобальная ошибка здесь - это непонимание промежутков времени для расчёта и принципов работы с кэш-флоу. Ошибочные цифры не дают чёткой картины понимания прибыльности проекта и целесообразности его ведения.”

Решение

Для начала давайте поймём, с чем имеем дело.

Юнит-экономика — это: 

1. Лакмусовая бумажка эффективности работы команды на проекте

2. Уникальная возможность для проджекта прокачать внимательность и увеличить понимание проекта

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

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

Неправильно настроенный процесс - это когда в команду вы пришли такой крутой, а потом все узнали, что вы делали расчёты “как-то так”, чем и провалили проект.

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

Ошибка №5. Проведение сырого демо заказчику

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

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

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

Решение

Легко сказать: “Исключите все варианты провала”. Но как это сделать?

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

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

Ошибка №6. Отсутствие ретроспективы и подведения итогов 

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

Решение 

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

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

Классическая ретроспектива проводится в несколько этапов: 

• выделение проблем, 

• группировка этих проблем, 

• голосование за самые критичные, 

• мозговой штурм по вариантам решения, 

• фиксация лучших вариантов в виде договоренностей внутри команды.

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

Ошибка №7. Формирование борды и workflow прохождения спринта

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

• пропуск дискавери фаз для задач следующих спринтов, 

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

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

• неправильно расставлены приоритеты задач

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

Решение

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

ВАЖНО! Обратите внимание команды на важный функционал и задачи спринта, а также на то, что не критично сейчас. При Agile подходе спринт и его задачи могут меняться. После одного-двух спринтов вы с руководителем продукта можете перейти к “грумингу” - вычесывание бэклога от ненужных задач, которые могли отвалиться на этапе внесения корректировок клиентом. 

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

Ошибка №8. Взять ответственность на себя в ущерб прозрачности

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

Решение

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

Ошибка №9. Менеджеринг в “розовых” очках

Анна Устина

проджект менеджер Joy Dev

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

Решение 

Умейте говорить клиенту “нет” - основной поинт сохранения энергии в целом и нервных клеток команды в частности. Используйте универсальную формулу, которая звучит так: “Нет, потому что…”

… потому что не указаны границы полномочий

… потому что сроки не позволяют этого сделать в требуемом объёме

… потому что тогда это будет сделано в ущерб качеству

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

Ошибка №10. Непрозрачное ведение проекта перед клиентом 

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

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

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

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

Решение

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

Вот мы и обсудили первые 10 ошибок начинающего проджекта, но не думайте, что их так мало. Оставайтесь с нами, и в следующем материале узнаете ещё о 10 ошибках, на которые стоит обратить внимание. А если вы хотите завершать проекты в срок - мы готовы помочь вам в этом, пишите нам на почту hello@joy-dev.com