Как мы построили работу над проектом, который принес компании €5М за год. Опыт Helmes Bel

 

Как собрать классную команду и настроить процессы в ней так, чтобы получить не менее €5М за год?

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

Своим опытом успешной проектной работы поделился Алексей Асташкин — Lead Developer/Product Owner в Helmes Bel.

Рекомендуем также посмортеть другие материалы Kraftblick.Media о крупных проектах:

Иногда можем нажать на “ядерную кнопку”. Как в ScienceSoft выигрывают большие сделки.

Как Blinger продает банкам и другим энтерпрайзам. Интервью с CBDO Артемом Карпеченко.

Как продавать SaaS решения энтерпрайзам от 20,000/mo за подписку? Советы от EPOM, Ad Tech команды в 60+ человек.

Как банки выбирают подрядчиков? Интервью c CIO Хоум Кредит Банка.

Как мы построили работу над проектом, который принес компании €5М за год. Опыт Helmes Bel

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

Портфолио компании включает решения для более чем 500 организаций и предприятий по всему миру.

Сейчас я занимаю позицию Product Owner в Helmes Bel.

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

Затем перешел от чистой разработки к управлению проектами.

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

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

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

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

Где искать знания и как понять, что нужно заказчику

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

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

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

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

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

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

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

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

Прочитайте еще:  Как получать деньги от клиента круглый год: идеи для Q1-Q4 от Telesphor Software

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

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

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

Именно поэтому важно предлагать свои решения, даже если они совершенно отличаются от того, как представляет себе проект ваш клиент.

Только тогда можно двигаться дальше.

Сколько человек должно быть в проектной команде

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

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

Но все зависит от конкретного проекта. В наших командах было по 4-5 разработчиков, 2-3 тестировщика, Product Owner и менеджер, взаимодействующий с конечным заказчиком.

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

Решающими факторами в выборе состава команды должен быть объем работы, сроки и требования заказчика. Все это нужно четко обсудить перед стартом (о том, как планировать работу над проектом — далее).

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

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

Непосредственно в Helmes Bel очень грамотно выстроена “team model” (это целая система закономерностей командной работы, метод коллективной оценки сотрудников). И людей мы подбираем согласно ей.

Собеседования с менеджером или Product Owner проекта — важная часть подготовительного этапа.

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

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

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

Стоит стремиться сформировать такой коллектив, в котором коллеги делятся опытом и прислушиваются друг к другу, даже если один по рангу выше другого.

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

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

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

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

Прочитайте еще:  Как создать интерес у инвесторов и получить высокую оценку при капитализации IT компании

Кстати, рабочий чат, в котором можно общаться на неформальные темы, — очень важная часть процесса взаимодействия членов команды.

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

Что важно для старта проекта

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

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

Эти вопросы примерные.

Но вот какую стратегию мы разработали для нашего проекта:

  • Разговаривать с заказчиком как можно чаще.

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

  • Всегда держать в голове бюджет проекта.

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

  • Помнить о дедлайнах.

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

  • Планировать работу заранее, учитывая риски.

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

Как составить конкретный план действий

Я считаю, бессмысленно планировать на целый год и тем более на пять лет вперед.

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

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

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

Кстати, видение можно корректировать раз в 3-6 месяцев.

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

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

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

В идеале таким должен быть каждый основатель проекта или Product Owner. На нашем крупном проекте этим занимался я.

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

Затем происходит приоритизация задач. Каким образом действовали мы.

Мы работали согласно подходу WSJF (Weighted Shortest Job First): наиболее важная, но при этом маленькая, работа должна быть сделана в первую очередь. Эта модель приоритизации характерна для Scaled Agile подхода.

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

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

Я закладывал в наш план 20% дополнительного времени именно на риски.

Как мы построили работу над проектом, который принес компании €5М за год. Опыт Helmes Bel

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

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

Прочитайте еще:  Как квалифицировать лиды, чтобы освободить время топовых сейлзов

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

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

Готовый квартальный план может выглядеть примерно так:

Как мы построили работу над проектом, который принес компании €5М за год. Опыт Helmes Bel

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

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

Если оценка прошла успешно и план утвержден, переходим к его реализации.

Как разделить план на элементы

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

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

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

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

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

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

Для этого можно использовать интернет-инструменты, например, Trello.

Я со своей командой работал в программе Jira: там легко обмениваться задачами и следить за процессом их выполнения.

Что поможет в тестировании

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

Я рекомендую их документировать, можно в TestRail, например. Это удобно. И даже если один тестировщик увольняется в середине проекта и на его место приходит другой, ему будет легко сориентироваться.

Грубо говоря, там написано: “Сделай это, нажми эту кнопку— получишь такой результат”.

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

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

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

У нас без этого обошлось, но ситуации разные бывают, и это надо учитывать.

Как понять, что проект успешен

Говорить о том, что проект развивается и движется по правильному пути, можно только при условии соблюдения следующих трех факторов:

  • Команда довольна тем, что она делает
  • Заказчик доволен на каждом из этапов
  • Вы укладываетесь в сроки и бюджет

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

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

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

Материал подготовлен при участии журналиста Kraftblick.Media Маргариты Золотаревой

0 0 голос
Рейтинг статьи
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

    Свежие статьи