🗞️ Мифы о работе проджектом в заказной разработке

Этот пост - часть письма из рассылки “Уложиться в срок”. Подписывайтесь и будете получать каждый месяц по одному письму от меня, с информацией о проектном менеджменте :)

Тот самый случай, когда выпуск появился после одного вопроса студента. Цитирую его:

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

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

Большинство Менеджеров проектов - в аутсорсе

Что логично, на самом деле. Задача менеджера проекта - обеспечить процесс оказания услуг (ведения проекта) - прозрачностью. Все процедуры направлены именно на это. Если выходить за рамки ИТ, то в Строительстве, Машиностроение - даже в инхаус будут вестись проекты по стандартам, с необходимостью соблюдения менеджером проектов всех процедур и ритуалов. Это же подтверждает и статистика - 40% всех респондентов из мира аутсорс.

Исследование рынка PM 2023. Распределение респондентов по сферам

Статистика стабильна в том числе по разным странам:

Если смотреть на отчет Pulse of Profession от PMI, то он тоже говорит, что IT-организации (к сожалению, явно не выделяют аутсорс ли это или консалтинг) - занимают 18% рынка менеджеров проектов.

Где начинают свою работу Менеджеры?

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

График показывает - большая доля специалистов уровня Junior и ниже - в Аутсорсе. Соизмеримые доли в строительстве и рознице :). Тем не менее, из этого исследования можно сделать вывод - если вы начинаете вашу карьеру как менеджер проектов - вероятно это будет студия заказной разработки, системный интегратор или, другими словами - аутсорс.

Что думают менеджеры об этом?

Чтобы было не только мое мнение, я спросил тех, кто уже работает в компаниях заказной разработки или работал в Заказной и Продуктовой разработке - что бы они ответили на вопрос в начале статьи? Привожу ответы без изменений, орфография и стиль - сохранены :)

Соучредитель фирмы заказной разработки

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

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

Конечно мы предлагаем рынку и аутстафф услуги, но на самом деле, если ты не 20+ человек отдаешь, не особо заработаешь.

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

ответ - уточняйте в какую компанию идете, портфолио, общайтесь с теми кто там работал, не делайте выводов по 1 ответу, валидируйте.

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

к нам приходят примерно джун или джун + например бизнес аналитики(банки телеком и тд) через 1-2 года выходят системными аналитиками и др корпорации выкупают х2.

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

Действующий менеджер проектов в Аутсорс компании

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

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

Про перепродажи. Да, такое имеет место быть, и не только в ИТ. Сейчас замечаю, что конкретно у нас перепродаж больше стало (даже просят не афишировать, что мы отдельная контора) Это выливается в неудобство общения, работы и возможно разные требования в договорах заказчик-подрядчик и подрядчик-субподрядчик. Конкретный пример: у нас рабочие часы - с 7 до 16Мск, а у клиента с заказчиком - с 10 до 19Мск. Эти три часа не входят в нашу зону, но клиент конечно хочет, чтобы мы ее покрывали. Но есть и некоторый плюс перепродаж: возможно твоя контора не могла напрямую зайти к крупному заказчику и получить бесценный опыт работы. И в будущем, можно сыграть не очень честно: зайти напрямую, как уже проверенных специалистов с опытом в конкретных проектах)

Действующий менеджер проектов с опытом работы в Заказной и Инхаус командах

А где это не адский конвейер? “Обычному проджекту” не легче с ситуацией, когда расчётный срок исполнения проекта 12 месяцев, а надо сделать за 11 или даже 9. Тут же аврал-пожар на ровном месте и “каждая минута на счету”. К тому же я не встречал ситуаций, когда у проджекта 1, хоть и крупный, проект. Их всегда несколько и сраки (не сроки, но они тоже) горят.

Действующий менеджер проектов в Заказной разработке

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

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

Действующий менеджер проектов, который работает над гос.проектом

В средних компаниях (свыше 150-250 чел)

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

В больших компаниях таких как Барс , ОТР, БФТ, Ланит ( и т.д из топ 100) проблемы другого характера и получить опыт заказной разработки в этих компаниях на старте карьеры это большая удача и возможность получить хороший фундамент практического опыта, но без возможности быстрого роста ЗП в х2 через 6-12 мес.

Тезис - «каждая минута на счету»

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

Если твоя зарплата фикс и на этапе трудоустройства ты не сумел договориться % от суммы этапа работ проекта или по завершении отчетного периода/года, то надрываться, овертаймить по ночам, стрессовать, ругаться, депрессовать, срываться на коллег по просроченным задачам и губить свое здоровье не имеет особого смысла. Вы не виноваты. Вы не супермен/вумен с З/П senior (350+). Факапы это нормально и неизбежны. Это ваш опыт. На многие факторы проекта РМ не способен повлиять. Просто смиритесь и принимайте ситуацию. Работайте над тем, где в ваших силах изменить ситуацию, делайте то, что у вас лучше всего получается. Не нужно бояться просить помощи у стейкхолдеров компании, особенно , если не большой опыт РМ.

Если РМ одновременно руководит 2 проектами, то это тоже нормальная практика для маленьких компаний и маленьких проектов. Здесь действительно возможно начнется борьба за каждую свободную минуту, особенно у начинающих РМ с опытом 0-2 года.

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

Если РМ с нулевым опытом дают сразу 2-3 проекта одновременно , то из вас будут «выжимать все соки» и вы рискуете разочароваться в профессии.

Тезис «является ли мифом или единичным неудачным опытом»

Заказная разработка это всегда сложность. Это всегда хороший практический опыт (даже если он неудачный).

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

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

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

Мой опыт

Я проработал в компании системном интеграторе 9 лет. Как-то собирал статистику, что за это время я написал более 20000 электронных писем (10-15 писем в день) :)

За этот промежуток времени:

• Я прошел через все роли в команде разработки: разработчик, анаилитик, руководитель проекта, системный архитектор, руководитель отдела.
• Участвовать в пре-сейлах, оценке проектов.
• Выучил и на практике опробовал различные подходы к ведению проектов.
• Участвовал в переговорах с людьми разного уровня.
• Работал над проектами в банковской сфере, металлургии, нефтедобыча, электрогенерация.
• Все это дало мне широкий взгляд на одни и те же вопросы, опыт общения с разными людьми.
• Делал проекты на разных технологиях (хотя и консервативны достаточно)
• Седина проступила… Нервная работа, тем не менее.

Спустя 7-8 лет, я до сих пор “выезжаю” знаниями, полученными в период работы в аутсорсинговой компании.

Детально по тезисам из изначального сообщения

Считают каждую минуту

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

• Заказчик принципиально хочет оплачивать только время команды, потраченное на его проект. В этом случае будут считать время на проект.
• Компания работает на Upwork (биржа для фриланса), где отчет по времени требуют заказчики. Аналогично пункту выше.
• Компания не доверяет разработчикам, кто работает удаленно и требует трэкать (или установить специальное ПО) время во время рабочего дня. Я встречал такой же кейс и в Продуктовой разработке. То есть, это необязательно относится к компании Заказной разработки. Зависит от культуры внутри компании. Для примера, CrocoTime отчитывается, что их ПО используется в АльфаБанке, ГазпромНефть, ТезТур.

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

Перепродажа ресурсов

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

Но у меня и сейчас в продуктовой компании ровно тоже самое :) У меня прилетают запросы срочные от соседних команд, команда поддерживает несколько сервисов и постоянно происходит переключение контекста (между сервисами). Не вижу разницы здесь.

Обучение и развитие

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

У команды дополнительно были подписки на системы обучения. В моей бытности - это был Pluralsight. Если нужно было обучиться, взять курс с этой платформы - все было доступно. В принципе, Microsoft предлагает сейчас тоже самое :)

Качество кода / решений

А вот тут явный минус. В силу природы работы компании, когда необходимо сделать быстро, в срок, когда проект “одноразовый”, когда необходимо сокращать издержки - начинает страдать качество решений. Меньше тестов, код упрощается, нет времени делать его “масштабированным”, если проект на 1-2 разработчика, то и Code review может быть пропущен. Потому что это все уходит в жертву сделать проект в срок.

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

Если же это команда “аутстаффа”, то история отчасти похожая. У команды разработки нет времени и интереса погрузиться в контекст проекта, освоить все проекты. Они временные участники проекта. И это тоже относится к природе человека - когда вы точно знаете, что скоро это закончится - нет интереса инвестировать время в качество (из Теории игр).

Плюс, компания ищет возможности использовать инструменты, которые ускоряют процессы разработки. Таким образом, они проявляют интерес к Low-code или No-code решениям. Быстро получить результат.

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

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

Хотя, если верить Федору Борщеву - это не всегда так. Но и он соглашается про качество кода в аутсорсе и с тем, что аутсорс сделает решение быстрее, чем инхаус.

Переход в продуктовую компанию

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

Будет ли сложно? Конечно! Но эта сложность не является следствием ситуации на рынке сегодня. И вашем понимании того, как работает продуктовая компания.

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

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

Смещен фокус у менеджера. Если в Заказной компании - нужно смотреть на то, что хочет Заказчик. В продуктовой - ориентир на пользователя / потребителя (но иногда и на стейкхолдера).

Но тут не буду подробнее. Оставлю ссылку на статью об этом.

Подводя итог

Работа в проджектом в компании заказной разработки vs продуктовая компания - требует больше вовлеченности. Интенсивность работы будет выше. Но, при этом, когда я перешел в продуктовую компанию, я для себя отметил, что люди крайне неэффективны - митинги, общения за кофе-поинтом, тренинги и т.д. - мало работают :) Здесь, я думаю, правдиво. Но при этом, в заказной разработке вы будете перерабатывать, если сами этого хотите.

Чтобы не попасть в подобную компанию (о которой рассказывает миф) - смотрите отзывы, ищите людей кто работает там, спросите у них как им нравится работа и рекомендовали бы они пойти туда работать. Поговорите с теми, кто уже уволился из этой компании. LinkedIn и Хабр в помощь :)

Приняв правила - можно вырасти. У меня знакомый проджект в международной компании заказной разработки за 6 лет дорос до Директора проектного офиса :) Мне кажется, что это хорошая карьера.

Слухи негативные распускают те, кто столкнулся с галерами в самом худшем понимании. К сожалению, такие случаи наиболее громкие, хотя и не частые - посмотрите на статистику - 30-40% проджектов работают в компаниях заказной разработки! Также, на мой взгляд, популяризировали этот миф - ресурсы типа ebanoe.it (читать с осторожностью, не для слабонервных). Негативные истории захватывают умы сильнее, чем положительные.

Пойдя в компанию заказной разработки - вы быстро вырастите, как профессионал. У вас будет множество возможностей для этого!

Успевайте в срок!

Станислав