Уложитесь в мой дедлайн?
Oops! Something went wrong while submitting the form.
Чтобы завершать проекты вовремя и не тратить ресурсы впустую, нужен эффективный менеджмент. Но что если у вас нет штатной команды управления проектами и вы не хотите тратить время и деньги на её создание? Консультация по управлению проектами — первое, с чего можно начать. Рассказываем, почему без проектного менеджмента обойтись не получится, в чем плюсы и минусы аутсорса и когда лучше обратиться к экспертам в управлении проектами.
Команда по управлению проектами занимается организацией, мониторингом и контролем проекта.
По степени вовлечения в проект такой команды можно условно выделить проектный менеджмент “под ключ” и разовые консультации. В первом случае на выходе вы получите пошаговый план проекта, организацию рабочих процессов на каждом этапе разработки и готовый продукт. При разовой консультации — ответы на вопросы, например, как лучше выстроить коммуникацию и процессы в удаленной команде или как принимать выполненные задачи у команды разработчиков.
Для разработки IT-продуктов чаще всего используется гибкая методология Scrum. В классической Scrum команде есть Scrum-мастер, владелец продукта (Product Owner) и команда разработчиков (Development Team). Scrum-мастер и владелец продукта управляют процессом. Разработчики создают продукт.
Расскажем подробнее о Scrum-мастере и владельце продукта.
Scrum-мастер отвечает за взаимодействие членов команды, устранение проблем в работе команды, следование намеченному плану работ. Это полноценный участник команды, который участвует в технической реализации продукта, но в большей степени отвечает за атмосферу в команде и следование методологии Scrum.
Владелец продукта (PO) понимает основную идею продукта и бизнес-цели проекта. Его задача — сделать так, чтобы результат работы команды соответствовал им. PO видит продукт на макроуровне и дает направление команде, приоритезирует задачи и контролирует конечный результат.
Чаще всего владелец продукта — это представитель заказчика. Он понимает, каким должен быть результат, но не знает, как к нему прийти. Поэтому для управления проектом нужен проектный менеджер
Проектный менеджер или PM координирует процесс разработки и общается с заказчиком. Дело в том, что заказчик и разработчик живут в разных мирах. Разработчик хочет прокачивать экспертизу и не всегда точно оценивает время, нужное на разработку фичи, а заказчик хочет быстрее запустить приложение с наименьшими затратами. Заказчику нужны сроки и гарантии, а разработчики не могут гарантировать, что приложение будет работать.
Так вот, если заказчик будет напрямую работать с разработчиками, будет больно всем: разработчики обещают “что-то когда-то” сделать, заказчик не понимает, когда все заработает. Благо, есть PM.
PM — это переводчик между разработчиками и заказчиком. Он понимает, что хочет видеть заказчик и какие задачи нужно поставить разработчикам, чтобы получить нужный продукт. Ему ясно, когда приложение полетит в релиз, каким оно должно быть и как планировать производительность разработчиков. И самое главное — он дает гарантии и несет за них ответственность.
Роли Scrum-мастера, PMа и владельца продукта не может совмещать в себе один человек. Но и будучи владельцем продукта нанять сразу PMа и Scrum-мастера при ограниченных бюджетах — это слишком дорого для стартапа. Затраты на найм, оборудование и обучение. И все это ради разработки одного приложения.
Институт управления проектами (PMI) говорит, что более 68% стартапов и компаний отдают проектный менеджмент подрядчикам. Мы тоже думаем, что проще отдать на аутсорс менеджмент проекта тем, у кого есть опыт и экспертиза. В долгосрочной перспективе вы экономите без потери в качестве.
Даже если вы отдали проектный менеджмент на аутсорс, нужно иметь представление о структуре управления проектами. Так вы будете понимать, на каком этапе находится проект, что вас ждет и когда нужно активно общаться с проектной командой.
На этом этапе PM и заказчик определяет ключевые вехи и цели проекта. Составляют треугольник управления проектом — функциональность приложения, стоимость и время. Попутно формируется команда разработчиков, распределяются роли и зоны ответственности, определяется канал коммуникации.
Если заказчик хочет получить качественный продукт в рамках бюджета, он должен много общаться с проектной командой на этапе инициализации. Ведь на старте команде нужно как больше информации о продукте: что он может делать, какая цель, какие приоритеты. От этого сильно зависят сроки и стоимость.
Часто бывает, что учли все “хотелки” и примерная оценка — 1000 часов разработки. Круто, что это выяснилось на этапе инициализации и можно включить режим “отсекаем все лишнее”.
Из будней PMов…
Чат со службой поддержки? — Да не, текстовая форма “Опишите свою проблему” сойдет.
Интеграция Google и Apple Pay? — Хватит Яндекс Кассы.
По итогам инициализации команда пишет проектную документацию с требованиями к продукту — эта дока нужна на планировании.
На этапе инициализации уже есть примерная оценка в часах. Но детальную оценку и план реализации делают на втором этапе.
PM и команда составляют задачи, оценивают их и назначают ответственных за выполнение — из этого рождается подробный план реализации проекта. Его проектный менеджер согласует с заказчиком.
Если итоги планирования все еще грустные для заказчика, а-ля 800 часов разработки вместо желаемых 500, можно уйти на шаг назад и выкинуть еще что-то из MVP. Да, управление стартапом — дело такое, только успевай отсекать все лишнее.
Заказчик “дал добро” — время кодить.
Исполнение и контроль формально разные фазы проекта, но мы их рассматриваем вместе. Исполнение без контроля в IT — это неработающий продукт.
Разработчик начинает делать таску. 20 часов, бум. “Фича работает” — говорит он.
Подключаем тестировщика. Берем первый флоу — фича работает. Берем второй флоу — упс, фича не работает.
Формально, разработчик прав, фича работает. Но только в одном из сценариев. А заказчику нужно стабильно работающее приложение во всех сценариях использования.
“Если фича работает с первого раза, то там точно есть баг” — народная мудрость
На этом этапе происходит основная работа — создается продукт. При работе по Scrum команда итеративно делает части продукта, фиксит баги, согласует результаты с заказчиком и переходит к следующей части. План может меняться на ходу: заказчик урезал бюджет вдвое или понял, что и без Яндекс.Кассы проживет.
Для заказчика главное — не терять видение конечной цели продукта и ясно доносить ее до PMа. А PM уже переведет это все разработчикам.
Результат работы — релиз.
Последняя фаза жизненного цикла проекта — это передача готового продукта заказчику.
После релиза команда разработчиков улучшает код, фиксит баги и пишет тех. документацию к продукту, чтобы продукт не был привязан к конкретным разработчикам и мог изменяться другими.
Есть идея и команда разработчиков, но не знаете, как организовать работу внутри команды? Эксперты проектного управления помогут организовать процессы на всех этапах разработки: подскажут, как лучше выстраивать работу команды и как интегрировать новые механизмы работы в привычные.
Бюджет сгорает, а результата нет? Возможно, ваша команда по разработке не знает, как довести проект до релиза. Эксперт внесет ясность в то, что сейчас творится на проекте, найдет затыки, и придумает, как их исправить.
Планируете создать команду по управлению проектами, но не знаете, как выращивать PMов? Обратиться к консалтинговой компании для коучинга специалистов — рабочий вариант.
Многие аутсорсинговые агентства тренируют новичков в проектном менеджменте: делятся методологией управления проектами, дают практические инструменты и учат ими пользоваться.
Как вы уже поняли, аутсорсинг проектного менеджмента — это не только про решение горящих проблем в моменте, но и про долгосрочные преимущества. Вот некоторые из них.
Вы нанимаете подрядчика и пользуетесь сторонней экспертизой по договору. Это значит, что вам не нужно открывать новые вакансии, вкладываться в развитие персонала и создавать внутреннюю инфраструктуру. Платите только за результат.
Аутсорсинг проектного менеджмента — гибкий вид сотрудничества. Упакованный проектный менеджмент, внедрение отдельных методов и инструментов или разовая консультация — все это можно получить на аутсорсе. Заказчику главное определиться со своими “хотелками”, а агентство уже скажет, сможет помочь или нет. Если вдруг по ходу консультации поняли, что нужен проектный менеджмент “под ключ”, не проблема — всегда можно расширить контракт.
Эксперты проектного менеджмента уже набили свои шишки. И зачем наступать на грабли самому, если можно посоветоваться с тем, кто знает, как их обойти. Эксперты уже знают узкие места проектов, помогают минимизировать их эффект на ранних стадиях. Чем меньше рисков и узких мест, тем быстрее реализуется проект и меньше денег потратит заказчик.
Может показаться, что лучше аутсорса ничего нет. Неправда, есть свои минусы и “ловушки”, которые нужно учитывать.
Будьте готовы, что проектный менеджер будет задавать много вопросов о бизнес-процессах. И в ваших же интересах рассказать ему как можно подробнее о них. Так, продукт будет полностью соответствовать вашим требованиям, а не додумкам PMа о том, как это должно работать.
При этом если ваша компания уже владеет жирной долей рынка, конкуренты не дремлют и хотят знать вашу внутреннюю кухню. Есть риск, что конкурент зайдет в вeб-студию за информацией. А веб-студия не откажет в помощи. Разумеется, за вознаграждение.
Или другой кейс, у вас уже есть готовый дизайн. Веб-студия начинает разрабатывать продукт по вашему готовому дизайну, но потом вдруг отказывается продолжать. Возможно, они просто продали ваш дизайн другому заказчику.
Чтобы обезопасить себя, можно подписать соглашение о неразглашении конфиденциальной информации. В таком случае даже если агентство выкинет “финт ушами”, вы сможете взыскать с них компенсацию.
Лучше не рисковать и на этапе выбора подрядчика внимательно изучать отзывы.
{{tg-banner}}
Отдавая разработку продукта на аутсорс, вы становитесь зависимыми от подрядчика. Если у них дела пойдут плохо, или они внезапно сократят штат разработчиков, запуск продукта будет под угрозой — грустная ситуация. Здесь тоже помогут отзывы и здравая оценка стабильности компании.
Если с отзывами все в порядке, ребята давно на рынке и не собираются никуда уходить, нужно узнать, как происходит процесс передачи проекта. Нужный вам вариант — детальная тех.документация проекта.
Зависимость от веб-студии самая высокая на старте проекта, то есть только 3-4 месяца. К релизу проекта разработчики составляют тех.документацию, чтобы поддержкой проекта могла заниматься другая команда, которую вы наберете за это время месяца.
На аутсорсе бывает так, что веб-студия просит полную предоплату, что-то разрабатывает, кормит заказчика завтраками и обещает вот-вот запустить ракету. По факту заказчик получает часть забагованного продукта и счет еще на месяц разработки со словами: “Ну тут, это, проблемки возникли”.
Чтобы не получилось такой ситуации, нужно проверять, что вэб-студия работает по методологии Scrum. Для заказчика — это идеальный вариант. Каждые две недели он платит только за работающие фичи. Если приложение забаговано или что-то идет не так, есть вариант отказаться от сотрудничества, забрать то, что уже есть и найти другого подрядчика. Вы рискуете только стоимостью двухнедельного спринта.
Знаете, бывает, что наняли дизайнера, а он сделал технически не реализуемый прототип. Или senior React Native разработчик на деле оказался совсем не senior и совсем не React Native.
Мы в Purrweb знаем, что лучше один раз проконсультироваться в начале проекта и минимизировать фундаментальные риски на старте, чем тушить пожары через два месяца.
<a class="blog-modal_opener">Свяжитесь с нами</a>, если вам нужна помощь на любом этапе проекта.
.svg)
.webp)
