Ну, что начнем!
Всем привет! Это Mechanica и мы запустили телеграм-канал для диджитал-менеджеров 🥳.
Канал зайдет проджекту, продакту, скрам-мастеру, IT-директору, маркетологу, предпринимателю — подрядчику или продуктовой стороне. Всем, кто создает что-то новое в диджитал.
Темы постов, которые вы можете увидеть здесь в ближайшее время:
- Деньги в проекте/продукте
- Новые бизнес-модели
- Должности в диджитал: какие и зачем
- «Как ты сюда попал?»
- Манипуляции клиент/подрядчик
- Разработка для менеджера: поверхностно, но масштабно
- Предпроектное обследование
- Образование для digital-менеджера
Контент основан на реальных событиях, опыте, общении с людьми из продуктов. В канале вы будете встречать инсайты и размышления от своих коллег, интервью и живой контент. Одна только рубрика «Как ты сюда попал?» чего стоит! Оценивайте посты, чтобы мы понимали куда лучше двигаться.
Новый полезный материал будет выходить регулярно — раз в неделю, первый пост уже сегодня. Так что подписывайтесь и наслаждайтесь😉
Всем привет! Это Mechanica и мы запустили телеграм-канал для диджитал-менеджеров 🥳.
Канал зайдет проджекту, продакту, скрам-мастеру, IT-директору, маркетологу, предпринимателю — подрядчику или продуктовой стороне. Всем, кто создает что-то новое в диджитал.
Темы постов, которые вы можете увидеть здесь в ближайшее время:
- Деньги в проекте/продукте
- Новые бизнес-модели
- Должности в диджитал: какие и зачем
- «Как ты сюда попал?»
- Манипуляции клиент/подрядчик
- Разработка для менеджера: поверхностно, но масштабно
- Предпроектное обследование
- Образование для digital-менеджера
Контент основан на реальных событиях, опыте, общении с людьми из продуктов. В канале вы будете встречать инсайты и размышления от своих коллег, интервью и живой контент. Одна только рубрика «Как ты сюда попал?» чего стоит! Оценивайте посты, чтобы мы понимали куда лучше двигаться.
Новый полезный материал будет выходить регулярно — раз в неделю, первый пост уже сегодня. Так что подписывайтесь и наслаждайтесь😉
Эффективная ставка
Уже много раз написали, что означают модели оплаты фикс-прайс, ТМ и ретейнер. Сегодня поговорим о ставках — как считаются и как меняются на длительном промежутке.
Эффективная ставка — реальное соотношение затраченного времени и полученных денег по итогам какого-то периода. В моменте она может быть 3000 руб/ч, по итогам месяца 2500 руб/ч, а в среднем по году вообще 1800 руб/ч. Как это происходит часто становится понятно только в процессе работы. Поэтому тем, кто не работал по всем моделям будет полезно.
1. Фикс-прайс (проект)
Когда нужно сделать разово небольшой продукт. Подрядчик оценивает объем работ в часах. Например, 1000 часов по ставке 2500 руб/ч. Стоимость фиксируют — за полную реализацию задач заказчик заплатит ровно 2,5 млн рублей. Если получится организовать работу так, что команда справится за 500 часов (например, используют готовые решения или прошлые наработки), то подрядчик реализует проект по эффективной ставке 5000 руб/ч. Если выяснится, что не заложили важный блок и разработка займет 1500 часов, то проект в итоге будет реализован по ставке 1666 руб/ч.
Заказчику: подходящая модель, если готовы переложить всю ответственность на подрядчика за фиксированную стоимость и не волнует стоимость часа на этом небольшом объеме работ.
Подрядчику: закладываете риски в оценку, тщательно трекаете проект и есть вероятность получить высокую маржинальность на небольшом объеме часов. Но при переключении между такими небольшими заказами будут простои, которые уменьшат эффективную ставку.
2. Фикс-прайс (непрерывная разработка)
Когда нужно несколько месяцев выполнять отдельные задачи. Длительная разработка, как правило, дробится на отдельные задачи, которые передают подрядчику по-отдельности «по-фиксе». Например, также по ставке 2500 руб/ч. Кроме выполнения каждой задачи подрядчику придется разобраться в легаси, оценить задачу, иногда развернуть копию площадки, а после тестирования исправить баги. В таком формате 160 рабочих часов в месяце превращаются в 100 часов реализованных и оплаченных задач. То есть не 400к в месяц, а 250к рублей. При этом все задачи выполнены, а времени потрачено 160 часов. Так ставка превратилась из 2500 в 1562 руб/час.
Заказчику: в отличие от проекта придется заниматься декомпозицией задач своими силами. Но так будет больше контроля над оценками, что хорошо при долгосрочной работе. Это такой псевдо-ТМ для неопытных подрядчиков. Поэтому часто применяется агентствами при передаче задач на субподряд.
Подрядчику: когда у заказчика собственная декомпозиция, стоимость детализирована и сработать по сверхставкам тут не получится. Максимум, чтобы ставка хотя бы не снижалась — трекать все доп. работы (devops, баги, риски) и договариваться об их оплате (стремиться к ТМ). А еще не допускать простои между задачами, договариваться о минимальном объеме часов в месяц и включать проактивность на максимум.
3. ТМ (проект)
Если фикс-прайс задачу можно выполнить быстрее, то по ТМ заказчик оплачивает фактически потраченные часы на задачу. Подрядчик не может увеличить эффективную ставку, но и от ее просадки из-за рисков и дополнительных работ подрядчик застрахован.
Все задачи трекаются и оплачиваются по затраченным часам. Треки проверяются (обычно на здравый смысл), поэтому «накрутить» часы не получится. Для заказчика устанавливается вилка стоимости и минимальный порог часов, который гарантированно выкупается.
Заказчику: нужно договариваться о границах «от» и «до» и проверять структуру затреканных часов (чтобы по дефолту не выставлялся счет на «до»). Если есть большая доля неопределенности в проекте и он может оказаться как сложнее, так и гораздо проще в реализации, то это ниболее честная схема.
Подрядчику: договариваться о гарантированном выкупе часов по оценке «от» и следить за эффективностью, чтобы это не превратилось в фикс-прайс (по часам уже дошли до максимальной оценки, а работы еще вагон).
Уже много раз написали, что означают модели оплаты фикс-прайс, ТМ и ретейнер. Сегодня поговорим о ставках — как считаются и как меняются на длительном промежутке.
Эффективная ставка — реальное соотношение затраченного времени и полученных денег по итогам какого-то периода. В моменте она может быть 3000 руб/ч, по итогам месяца 2500 руб/ч, а в среднем по году вообще 1800 руб/ч. Как это происходит часто становится понятно только в процессе работы. Поэтому тем, кто не работал по всем моделям будет полезно.
1. Фикс-прайс (проект)
Когда нужно сделать разово небольшой продукт. Подрядчик оценивает объем работ в часах. Например, 1000 часов по ставке 2500 руб/ч. Стоимость фиксируют — за полную реализацию задач заказчик заплатит ровно 2,5 млн рублей. Если получится организовать работу так, что команда справится за 500 часов (например, используют готовые решения или прошлые наработки), то подрядчик реализует проект по эффективной ставке 5000 руб/ч. Если выяснится, что не заложили важный блок и разработка займет 1500 часов, то проект в итоге будет реализован по ставке 1666 руб/ч.
Заказчику: подходящая модель, если готовы переложить всю ответственность на подрядчика за фиксированную стоимость и не волнует стоимость часа на этом небольшом объеме работ.
Подрядчику: закладываете риски в оценку, тщательно трекаете проект и есть вероятность получить высокую маржинальность на небольшом объеме часов. Но при переключении между такими небольшими заказами будут простои, которые уменьшат эффективную ставку.
2. Фикс-прайс (непрерывная разработка)
Когда нужно несколько месяцев выполнять отдельные задачи. Длительная разработка, как правило, дробится на отдельные задачи, которые передают подрядчику по-отдельности «по-фиксе». Например, также по ставке 2500 руб/ч. Кроме выполнения каждой задачи подрядчику придется разобраться в легаси, оценить задачу, иногда развернуть копию площадки, а после тестирования исправить баги. В таком формате 160 рабочих часов в месяце превращаются в 100 часов реализованных и оплаченных задач. То есть не 400к в месяц, а 250к рублей. При этом все задачи выполнены, а времени потрачено 160 часов. Так ставка превратилась из 2500 в 1562 руб/час.
Заказчику: в отличие от проекта придется заниматься декомпозицией задач своими силами. Но так будет больше контроля над оценками, что хорошо при долгосрочной работе. Это такой псевдо-ТМ для неопытных подрядчиков. Поэтому часто применяется агентствами при передаче задач на субподряд.
Подрядчику: когда у заказчика собственная декомпозиция, стоимость детализирована и сработать по сверхставкам тут не получится. Максимум, чтобы ставка хотя бы не снижалась — трекать все доп. работы (devops, баги, риски) и договариваться об их оплате (стремиться к ТМ). А еще не допускать простои между задачами, договариваться о минимальном объеме часов в месяц и включать проактивность на максимум.
3. ТМ (проект)
Если фикс-прайс задачу можно выполнить быстрее, то по ТМ заказчик оплачивает фактически потраченные часы на задачу. Подрядчик не может увеличить эффективную ставку, но и от ее просадки из-за рисков и дополнительных работ подрядчик застрахован.
Все задачи трекаются и оплачиваются по затраченным часам. Треки проверяются (обычно на здравый смысл), поэтому «накрутить» часы не получится. Для заказчика устанавливается вилка стоимости и минимальный порог часов, который гарантированно выкупается.
Заказчику: нужно договариваться о границах «от» и «до» и проверять структуру затреканных часов (чтобы по дефолту не выставлялся счет на «до»). Если есть большая доля неопределенности в проекте и он может оказаться как сложнее, так и гораздо проще в реализации, то это ниболее честная схема.
Подрядчику: договариваться о гарантированном выкупе часов по оценке «от» и следить за эффективностью, чтобы это не превратилось в фикс-прайс (по часам уже дошли до максимальной оценки, а работы еще вагон).
4. ТМ (непрерывная разработка)
Самый понятный и применимый формат работы по TM — долгосрочно выполнять отдельные задачи (развитие какого-то сервиса, работа с бесконечно формируемым бэклогом). Но при длительной работе с отдельными задачами присутствует все тот же эффект простоев — когда одна задача закончилась, а следующая еще не началась. Заказчик не платит за это время, что логично.
Подрядчику: заранее формировать объемы от заказчика и держать очередь из задач — не допускать простоев. Так эффективная ставка будет стремиться к той, по которой выкупаются часы (к номинальной ставке).
Заказчику: обе стороны заинтересованы в максимальной скорости реализации без простоев. Экономия здесь возможна только на скорости — больше простоев = ниже скорость разработки = никакая это не экономия.
5. Retainer (от анг. — слуга, вассал)
Это когда заказчик/продукт покупает все время специалистов (160 часов в месяц) и направляет их работу в нужное русло. Ставка здесь фиксируется и ни от чего не зависит (если только от срока выкупа, за который дается скидка). Если команда простаивает, заказчик все-равно платит за это время.
От компетенций команды сильно зависит скорость работы — возможность работать в неопределенности, проактивность, опыт в предметной области. Из одной выделенной команды на ретейнере можно выжать больше профита, чем из другой. Потому что закрывают больше задач, не простаивают, участвуют в формировании бэклога, стратегии развития и просто проактивны.
Эффективная ставка для подрядчика зафиксирована (оплачены будут все 160 часов), а вот для заказчика эффективная ставка зависит от того:
- насколько профессиональная команда;
- насколько хорошо организована непрерывная разработка.
Заказчику: затраты на команду фиксированные, а профит зависит от того, к чему были приложены усилия этой команды и как была организована работа. Если у компании есть достаточный поток задач, чтобы выкупить команду на год, то при правильной организации это будет гораздо выгоднее. Плюс наращиваются компетенции внутри компании.
Подрядчику: срок работы с клиентом зависит от профессионализма подрядчика. Если плохо работать и/или не общаться с заказчиком о его бизнесе = работать с ним не долго = искать нового клиента = простаивать.
Самый понятный и применимый формат работы по TM — долгосрочно выполнять отдельные задачи (развитие какого-то сервиса, работа с бесконечно формируемым бэклогом). Но при длительной работе с отдельными задачами присутствует все тот же эффект простоев — когда одна задача закончилась, а следующая еще не началась. Заказчик не платит за это время, что логично.
Подрядчику: заранее формировать объемы от заказчика и держать очередь из задач — не допускать простоев. Так эффективная ставка будет стремиться к той, по которой выкупаются часы (к номинальной ставке).
Заказчику: обе стороны заинтересованы в максимальной скорости реализации без простоев. Экономия здесь возможна только на скорости — больше простоев = ниже скорость разработки = никакая это не экономия.
5. Retainer (от анг. — слуга, вассал)
Это когда заказчик/продукт покупает все время специалистов (160 часов в месяц) и направляет их работу в нужное русло. Ставка здесь фиксируется и ни от чего не зависит (если только от срока выкупа, за который дается скидка). Если команда простаивает, заказчик все-равно платит за это время.
От компетенций команды сильно зависит скорость работы — возможность работать в неопределенности, проактивность, опыт в предметной области. Из одной выделенной команды на ретейнере можно выжать больше профита, чем из другой. Потому что закрывают больше задач, не простаивают, участвуют в формировании бэклога, стратегии развития и просто проактивны.
Эффективная ставка для подрядчика зафиксирована (оплачены будут все 160 часов), а вот для заказчика эффективная ставка зависит от того:
- насколько профессиональная команда;
- насколько хорошо организована непрерывная разработка.
Заказчику: затраты на команду фиксированные, а профит зависит от того, к чему были приложены усилия этой команды и как была организована работа. Если у компании есть достаточный поток задач, чтобы выкупить команду на год, то при правильной организации это будет гораздо выгоднее. Плюс наращиваются компетенции внутри компании.
Подрядчику: срок работы с клиентом зависит от профессионализма подрядчика. Если плохо работать и/или не общаться с заказчиком о его бизнесе = работать с ним не долго = искать нового клиента = простаивать.
Системный аналитик (Википедия) — «в целом термин не имеет устойчивой трактовки и в организациях различного класса (научных, исследовательских, коммерческих) он получает несколько различную смысловую нагрузку».
И это подтверждается когда заходишь на Skillbox или HH. Множество курсов и еще больше вакансий с разными описаниями, требованиями, обязанностями, но с многочисленными производными названиями: бизнес-аналитик, системный аналитик, mobile-аналитик, продуктовый аналитик, аналитик данных, веб-аналитик, UX-аналитик.
Попробуем фундаментально подойти к вопросу и разберемся, кто такие аналитики, и зачем они нужны в IT.
Анализ (др.-греч. «разложение, разделение, расчленение...») — исследование с помощью выделения и изучения отдельных частей объектов исследования. Противоположное анализу — синтез (др.-греч. «соединение, складывание...»).
Аналитика (др.-греч. «искусство анализа») — здесь было «очень длинное и размытое древнегреческое определение из википедии, которое не очень нам помогает в вопросе». Поэтому если упростить, то получится, что аналитика — это рассуждения по предмету анализа.
Аналитик — специалист, занимающийся изучением аналитических исследований и обобщений в определенной сфере деятельности, который в совершенстве владеет методами анализа, обычно способен прогнозировать процессы и разрабатывать перспективные программы развития.
Системный аналитик
Во многих статьях и вакансиях аналитика в IT позиционируют как переводчика с языка заказчика на язык программиста, но это не все, что он должен делать. Чтобы поставить программистам правильную задачу на основе требований заказчика ему нужно эти требования привести в порядок. Требования заказчика могут:
противоречить друг другу;
- быть не реализуемыми в рамках текущих бизнес-процессов;
- быть не реализуемыми технически;
- быть не реализуемыми финансово (можно сделать, но неоправданно дорого);
- быть просто не озвучены и их нужно как-то дособрать.
Конечный продукт системного аналитика — это понимание требований и четкий план их реализации с учетом существующих систем и технологий (в компании и в мире).
Mobile-аналитик, продуктовый аналитик, веб-аналитик, UX-аналитик — это просто позиционирование системного аналитика в разных предметных областях. Системный аналитик, который имеет опыт работы именно в мобильных технологиях, будет востребованнее в мобильном продукте.
И это подтверждается когда заходишь на Skillbox или HH. Множество курсов и еще больше вакансий с разными описаниями, требованиями, обязанностями, но с многочисленными производными названиями: бизнес-аналитик, системный аналитик, mobile-аналитик, продуктовый аналитик, аналитик данных, веб-аналитик, UX-аналитик.
Попробуем фундаментально подойти к вопросу и разберемся, кто такие аналитики, и зачем они нужны в IT.
Анализ (др.-греч. «разложение, разделение, расчленение...») — исследование с помощью выделения и изучения отдельных частей объектов исследования. Противоположное анализу — синтез (др.-греч. «соединение, складывание...»).
Аналитика (др.-греч. «искусство анализа») — здесь было «очень длинное и размытое древнегреческое определение из википедии, которое не очень нам помогает в вопросе». Поэтому если упростить, то получится, что аналитика — это рассуждения по предмету анализа.
Аналитик — специалист, занимающийся изучением аналитических исследований и обобщений в определенной сфере деятельности, который в совершенстве владеет методами анализа, обычно способен прогнозировать процессы и разрабатывать перспективные программы развития.
Системный аналитик
Во многих статьях и вакансиях аналитика в IT позиционируют как переводчика с языка заказчика на язык программиста, но это не все, что он должен делать. Чтобы поставить программистам правильную задачу на основе требований заказчика ему нужно эти требования привести в порядок. Требования заказчика могут:
противоречить друг другу;
- быть не реализуемыми в рамках текущих бизнес-процессов;
- быть не реализуемыми технически;
- быть не реализуемыми финансово (можно сделать, но неоправданно дорого);
- быть просто не озвучены и их нужно как-то дособрать.
Конечный продукт системного аналитика — это понимание требований и четкий план их реализации с учетом существующих систем и технологий (в компании и в мире).
Mobile-аналитик, продуктовый аналитик, веб-аналитик, UX-аналитик — это просто позиционирование системного аналитика в разных предметных областях. Системный аналитик, который имеет опыт работы именно в мобильных технологиях, будет востребованнее в мобильном продукте.
Бизнес-аналитик
Если системный аналитик приводит в порядок уже сформировавшиеся требования и правильно доносит их до разработчиков. То бизнес-аналитик эти требования должен сформировать.
Например, из ничего. Что-то в бизнесе нужно проанализировать и сформулировать задачу. Например, «У нас падает показатель возврата клиентов на протяжении последних 2 лет. Нам необходимо усилить нашу программу лояльности и внедрить механики омниканального накопления баллов и партнерский кэшбэк».
В консалтинговом бизнесе бизнес-аналитиком называется высшая позиция для консультанта. То есть такой человек может корректировать и развивать бизнес. У системного аналитика более локальная задача.
Бизнес-аналитик должен разбираться в бизнесе (как ни странно), моделировать бизнес-процессы, разрабатывать бизнес-требования. Бизнес-аналитику тоже необходимо понимать возможности технологий и их использования, но это не IT-специалист.
Конечный продукт бизнес-аналитика — это видение проблем и инструментов решения этих проблем, к которым затем формируются требования. Упущенная выгода, кстати, тоже определяется как один из видов бизнес-проблем, которую должны решать бизнес-аналитики.
Бизнес-аналитик звучит круто, но часто системного аналитика вполне достаточно.
Что отличает хорошего аналитика от обычного
Обычный аналитик может проанализировать данные и рассказать текущую картину. То есть просто перевести цифры на человеческий язык.
Сильный аналитик способен проанализировать текущую ситуацию, определить проблемы, рассмотреть их в составе всей системы, заглянуть вперед (как эта ситуация может развиваться в будущем), и предложить стратегию + конкретные решения в рамках этой стратегии.
Если системный аналитик приводит в порядок уже сформировавшиеся требования и правильно доносит их до разработчиков. То бизнес-аналитик эти требования должен сформировать.
Например, из ничего. Что-то в бизнесе нужно проанализировать и сформулировать задачу. Например, «У нас падает показатель возврата клиентов на протяжении последних 2 лет. Нам необходимо усилить нашу программу лояльности и внедрить механики омниканального накопления баллов и партнерский кэшбэк».
В консалтинговом бизнесе бизнес-аналитиком называется высшая позиция для консультанта. То есть такой человек может корректировать и развивать бизнес. У системного аналитика более локальная задача.
Бизнес-аналитик должен разбираться в бизнесе (как ни странно), моделировать бизнес-процессы, разрабатывать бизнес-требования. Бизнес-аналитику тоже необходимо понимать возможности технологий и их использования, но это не IT-специалист.
Конечный продукт бизнес-аналитика — это видение проблем и инструментов решения этих проблем, к которым затем формируются требования. Упущенная выгода, кстати, тоже определяется как один из видов бизнес-проблем, которую должны решать бизнес-аналитики.
Бизнес-аналитик звучит круто, но часто системного аналитика вполне достаточно.
Что отличает хорошего аналитика от обычного
Обычный аналитик может проанализировать данные и рассказать текущую картину. То есть просто перевести цифры на человеческий язык.
Сильный аналитик способен проанализировать текущую ситуацию, определить проблемы, рассмотреть их в составе всей системы, заглянуть вперед (как эта ситуация может развиваться в будущем), и предложить стратегию + конкретные решения в рамках этой стратегии.
Экспертиза
Не все, кто называет себя экспертами, задумываются о том, что такое экспертиза. Понятие стало обыденным и его используют все кому не лень, особенно агентства. Заявляя, что «у нашей команды экспертиза в ритейле», например.
Есть несколько уровней экспертизы, давайте разбираться.
Уникальная экспертиза
Экспертом вы будете считать только того, кто разбирается в том, в чем вы не разбираетесь. У него есть в этом опыт, а у вас нет. Он может поделиться своей экспертизой и вы будете в восторге от его экспертности.
Например: компания хочет построить внутри продуктовую команду для создания и развития своих сервисов лояльности, но никогда этого не делала. И на рынке почти никто не делал. Экспертизы внутри нет, как это делать непонятно. Раньше разовые проекты отдавались подрядчикам по фикс-прайс.
Консалтинговое агентство, которое занимается построением продуктовых процессов и команд. Единственное на рынке, кто занимается этим. Имеет несколько продуктовых команд, большой пул аутсорс-ресурсов и успешно интегрирует их в разные бизнесы клиентов.
Такое агентство может быть для этой компании настоящим экспертом. Обычно подобные кейсы настоящей уникальной экспертизы встречаются редко. Услуги такого агентства будут стоить максимально дорого.
Экспертиза — я тоже знаю
Когда вы и другой эксперт имеете одинаковый опыт в какой-то сфере. Тут тоже можно получить ощутимую пользу за счет эффекта синергии, обмена опытом.
Например, ритейлер после проверки MVP онлайн-сервиса по доставке еды привлекает команду, которая уже запускала такой сервис для службы доставки еды.
Ритейлер и сам прекрасно понимает, что и как нужно делать. Внешняя команда тоже в контексте, и можно эффективно работать, говоря на одном языке.
Есть и другие команды на рынке, но их всего несколько. Такой подрядчик не несет уникальной экспертизы, но тоже очень ценится клиентами. Хоть и стоить будет уже дешевле.
«Экспертиза» — я тоже знаю и все остальные тоже знают
Частый кейс на рынке заказной разработки. Агентства декларируют уникальную экспертизу в ecommerce, разработав 3 интернет-магазина на Битриксе.
Человек со стороны продукта не видит никакой экспертизы в таком подрядчике. Видит одно из 100 предложений, которое можно сравнить только по цене.
Не все, кто называет себя экспертами, задумываются о том, что такое экспертиза. Понятие стало обыденным и его используют все кому не лень, особенно агентства. Заявляя, что «у нашей команды экспертиза в ритейле», например.
Есть несколько уровней экспертизы, давайте разбираться.
Уникальная экспертиза
Экспертом вы будете считать только того, кто разбирается в том, в чем вы не разбираетесь. У него есть в этом опыт, а у вас нет. Он может поделиться своей экспертизой и вы будете в восторге от его экспертности.
Например: компания хочет построить внутри продуктовую команду для создания и развития своих сервисов лояльности, но никогда этого не делала. И на рынке почти никто не делал. Экспертизы внутри нет, как это делать непонятно. Раньше разовые проекты отдавались подрядчикам по фикс-прайс.
Консалтинговое агентство, которое занимается построением продуктовых процессов и команд. Единственное на рынке, кто занимается этим. Имеет несколько продуктовых команд, большой пул аутсорс-ресурсов и успешно интегрирует их в разные бизнесы клиентов.
Такое агентство может быть для этой компании настоящим экспертом. Обычно подобные кейсы настоящей уникальной экспертизы встречаются редко. Услуги такого агентства будут стоить максимально дорого.
Экспертиза — я тоже знаю
Когда вы и другой эксперт имеете одинаковый опыт в какой-то сфере. Тут тоже можно получить ощутимую пользу за счет эффекта синергии, обмена опытом.
Например, ритейлер после проверки MVP онлайн-сервиса по доставке еды привлекает команду, которая уже запускала такой сервис для службы доставки еды.
Ритейлер и сам прекрасно понимает, что и как нужно делать. Внешняя команда тоже в контексте, и можно эффективно работать, говоря на одном языке.
Есть и другие команды на рынке, но их всего несколько. Такой подрядчик не несет уникальной экспертизы, но тоже очень ценится клиентами. Хоть и стоить будет уже дешевле.
«Экспертиза» — я тоже знаю и все остальные тоже знают
Частый кейс на рынке заказной разработки. Агентства декларируют уникальную экспертизу в ecommerce, разработав 3 интернет-магазина на Битриксе.
Человек со стороны продукта не видит никакой экспертизы в таком подрядчике. Видит одно из 100 предложений, которое можно сравнить только по цене.