# Продуктовая разработка и аутсорсинг: как выбирать Canonical: https://www.kt-team.ru/blog/proddev-vs-outsource-part-1 Source: https://www.kt-team.ru/blog/proddev-vs-outsource-part-1 Canonical URL: https://www.kt-team.ru/blog/proddev-vs-outsource-part-1 Original URI: /blog/proddev-vs-outsource-part-1 ## SEO / GEO Metadata - Title: Продуктовая разработка vs аутсорсинг: как выбрать подход для IT-проекта. Часть 1 - Description: Сравнение продуктовой разработки и аутсорса: когда бизнесу выгоднее создавать команду in-house, а когда эффективнее привлекать внешнего IT-подрядчика - Canonical: https://www.kt-team.ru/blog/proddev-vs-outsource-part-1 - Robots: not specified - Open Graph tags: 4 - Twitter tags: 4 - JSON-LD blocks: 2 ## Layout Blocks ### ИИ / AI AI решения инструменты кейсы карьера +7 (495) 204-14-33 Стать клиентом --- ### Продуктовый подход в аутсорс-разработке. Закулисье работы в крупном IT-интеграторе. Часть 1 Продуктовый подход в аутсорс-разработке. Закулисье работы в крупном IT-интеграторе. Часть 1 Время на прочтение: 6 мин. Как бизнес смотрит на разработчиков? Знакома ли тебе ситуация, когда заказчик смотрит на разработчика как на поставщика фич, а не как на члена команды, участвующего в развитии продукта? Бывает ли, что необходимость некоторых фич, которые хочет внедрить заказчик, неясна? Более того, нет понимания итоговых цифр и метрик проекта. Нет точного ориентира, каким уровнем качества нужно обеспечить конкретную фичу. Нужен ли интерфейс или достаточно указывать настройки в файлах, нужно ли вынести функционал в микросервис или достаточно встроить его в текущую архитектуру и так далее… При таком отношении разработчиков часто оценивают по количеству фич. Фактический уровень качества определяется в этом случае субъективно (по ситуации) или в зависимости от бюджета. Но когда компания скатывается в ускорение фич, о качестве думать некогда. Никто не видит побед, многие достижения обесцениваются. Досадно, если, кроме технической команды, никто не может оценить красоту кода и вместо «как офигенно» маркетолог говорит: «Почему так долго, вот ещё пара задач, акция завтра». Из-за сложившихся стереотипов может казаться, что это особенность аутсорса. Но всегда ли команда, которая развивает свой собственный продукт, избавлена от таких проблем? Правда ли, что в продуктовых компаниях нет заказчика, поэтому работать там можно в расслабленном темпе, спокойнее? Обсудим в этой статье, что же такое продуктовая разработка, в чём её особенности и почему она может отсутствовать в продуктовой компании, но быть у IT-интегратора. Мифы о продуктовой и аутсорс-разработке Под аутсорс-разработкой понимают работу по созданию софта на заказ — для внешних заказчиков. Под продуктовой разработкой подразумевают создание и развитие собственного IT-продукта. Заказчик здесь внутренний, например это маркетинговый отдел или отдел продуктовой аналитики. Внутренний заказчик может мало чем отличаться от внешнего: он тоже требует определённого результата к определённому сроку. И ему важно, чтобы этот результат нужным образом приближал достижение его бизнес-целей. Часто встречается мнение, что для аутсорса характерен проектный подход. Есть сроки и техническое задание: в сроки нужно вписаться, ТЗ — выполнить. От продуктовой же разработки ожидают продуктового подхода. Казалось бы, очевидно. Но давай разберёмся на практике, так ли это? Продуктовый подход — это фокус на бизнес-целях: результат разработки должен решать конкретные задачи и быть рентабельным. «Продуктовый подход» не равно «продуктовая компания» — его вполне может применять и IT-интегратор! Из-за сложившихся стереотипов о проектном и продуктовом подходах в среде разработчиков курсируют пять предрассудков об аутсорс-компаниях: 1 требования заказчиков постоянно меняются («им не угодишь»), критерии качества размыты; 2 труд разработчиков ценен только количеством реализованного функционала; 3 аутсорс — это работа в жёстких рамках, сроки всегда ограничены («надо было вчера»), работает конвейер (есть «план выработки» и норматив на выполнение операций); 4 работать на аутсорсе скучно и трудно, а вот создание собственных продуктов компании — это креатив, фонтан интересных и уникальных задач, решать которые легко и приятно; 5 качество кода, культура кода в продуктовой компании всегда выше. Расскажем на примере компании kt.team, почему эти утверждения далеко не всегда справедливы. Мы придерживаемся продуктового подхода к разработке, хотя у нас есть не только собственные продукты, но и проекты на аутсорс. Познакомиться с некоторыми из них можно на странице «Проекты, над которыми мы работаем прямо сейчас». Не всех мы можем называть открыто, со многими действует NDA (соглашение о неразглашении). Итак, разберёмся, насколько справедливы стереотипы про продуктовые и аутсорс-компании в IT. Пришлем вам необходимые материалы или КП Напишите нам: clients@kt.team Ответим в течение 30 минут! Критерии качества Миф об аутсорсинге ‍При работе на аутсорс качество оценивается субъективно, критерии качества размыты и зависят от прихоти заказчика, а требования могут меняться по пять раз в день («заказчику не угодишь»). Миф о продуктовых компаниях ‍Команды разработчиков самостоятельно формируют объективные требования к качеству. Реальность ‍Оценка качества зависит не от типа компании, а от принципов работы, принятых в ней, и от наличия объективных метрик. Критерии качества размываются, когда заказчики относятся к разработчикам как к кодерам, безвольным исполнителям заказа. В таких случаях и возникают идеи оценивать труд, например, по количеству строк кода. Ведь другой ценности заказчик не видит. Другое дело, когда компания позиционирует себя как партнёр по поставке IT-решений, и заказчики воспринимают её соответственно. Фичи и изменения обсуждаются совместно с учётом стратегических целей. В этом случае измерить качество гораздо проще: оно зависит от достижения целей. Мы привыкли работать с заказчиками именно так. Поэтому кодеров у нас в компании нет — только software-инженеры. Решения они принимают, ориентируясь на долгосрочные цели проекта, декомпозированную карту среднесрочных целей и метрики, которые сбалансированы по качеству и количеству. Эти данные позволяют самостоятельно определять критерии достаточности качества: где достаточно захардкодить в константу, а где — сделать интерфейс управления, где предусмотреть гибкость и расширяемость, а где достаточно быстрого решения. Пример Мы создавали новый сервис для международной компании — производителя продуктов питания. Заказчик поставил цель: с помощью IT-инструментов достичь нужного уровня рентабельности. Вместе с заказчиком мы посчитали, какие параметры юнит-экономики нам для этого нужны: увеличить средний чек — на 50 %; увеличить конверсию — незначительно; увеличить APC (average payment count, рус. среднее число платежей за год) — до 12, т. е. перевести в режим покупки продукта по ежемесячной подписке. Провели анализ целевой аудитории, выделили два крупных сегмента: оптовые покупатели и мамочки. Воронку продаж пересмотрели с точки зрения этих новых сегментов и построили план по развитию продукта на год. После достижения текущих целей будем масштабировать результат. Признание заслуг Миф об аутсорсинге ‍Есть стереотип, что в аутсорсинговых IT-компаниях менеджерам лишь бы побыстрее проект закрыть да акт подписать, а разбираться, кто молодец и где чья победа, некогда. Миф о продуктовых компаниях ‍В продуктовых компаниях разработчики получают больше признания, потому что здесь они больше влияют на продукт и больше вовлекаются в процесс. Реальность ‍Чтобы вклад каждого сотрудника оценивался справедливо, нужно заранее определить, кто за что отвечает, и установить объективные метрики — мы уже обсудили это в прошлом пункте. Иногда разработчики отстраняются от целей бизнеса и говорят, что бизнес-метрики — это не их дело, «нужно просто качественно реализовывать свою задачу». В таком случае ничего странного, что заказчик низко ценит их труд. Он не видит их вклада в достижение целей. И даже если продукт полностью цифровой, победа будет чьей угодно, но только не IT-специалистов. Маркетологи скажут, что это всё они, ведь за лиды и задачи по SEO были ответственны они. Логисты скажут, что без остатков в каталоге и нормальной отгрузки продаж бы не было. Начальник скажет, что это его прозорливое око за всем углядело. Болтливый бездельник всем всё пообещает, и, даже если его обещания выполнит кто-то другой, это будет его победа. Но если вдруг случится беда (а беду при определённом уровне управленческого зуда можно найти всегда), виноватым окажется разработчик. Ведь любую неудачу, тщательно покопавшись в аналитике, при большом желании можно привязать к любой цифре (а в нашей практике до работы с цифрами даже не доходит). Вот только всё это с одинаковой вероятностью случается и в продуктовых, и в аутсорс-компаниях. При продуктовом подходе победа — это не выполнение как можно большего количества фич, победа — это успешная гипотеза, которая позволила достичь бизнес-целей. И даже плохая гипотеза — не поражение, ведь она помогла лучше понять продукт и ускориться. Тут просто нет проигрышных ситуаций. Таким образом, признание не зависит от того, работаешь ты в продуктовой компании или в аутсорсинговой. Главное — как изначально распределена ответственность за будущий результат между сторонами заказчика и исполнителя. Чтобы объективно оценивать вклад всех сторон, мы используем методику Impact Mapping. Статья об этом методе уже есть в блоге — «Impact Mapping, юнит-экономика и PDCA: грамотное управление разработкой e-Commerce». Ещё три мифа об отличиях продуктовой разработки от аутсорсинга мы рассмотрим в следующей части статьи. Опубликуем её в субботу, 14 марта 2020 г. Следи за новостями ;) Пришлем вам необходимые материалы или КП Напишите нам: clients@kt.team Ответим в течение 30 минут! Оглавление Как бизнес смотрит на разработчиков? Мифы о продуктовой и аутсорс-разработке Критерии качества Признание заслуг Реальность Другие статьи Смотреть все B2B-порталы в различных отраслях: ключевые кейсы и примеры использования 21/11/2024 Подробнее Реальные кейсы цифровой трансформации: от роста прибыли «Магнита» до автоматизации в медицине и образовании 19/8/2025 Подробнее Интеграция с «Честным ЗНАКом»: как дистрибьютору избежать штрафов, блокировок и потерь в логистике 19/12/2025 Подробнее Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта Ок Давайте обсудим ваш проект С вами свяжутся персональные менеджеры clients@kt.team Email: @kt_team_it Telegram: О нас Услуги Кейсы Блог Карьера Основы ценообразования Бизнес-стажировка Отзывы PIM/MDM-системы ESB-интеграции DevOps Low-code Микросервисы B2B-порталы и e-commerce PWA Magento Калькулятор проекта Unit-экономика © 2026 ООО «КТ Групп» ООО «КОМПЛИЦЕРТЕ ТЕХ» Komplizierte Technologien, GmbH Россия Тольятти, ул. 40 лет Победы, 41 Москва, Романов переулок, 2с1, пространство Noodome clients@kt.team +7 (495) 204-14-33 Положение о работе с персональными данными → ![image](/assets/original/6847c6ccd11c5b3358506a2c676107128d67a10d22fd0de7b2b-74fdcc4399.avif) ![Реальные кейсы цифровой трансформации: от роста прибыли «Магнита» до автоматизации в медицине и образовании](/assets/original/realnye-kejsy-cifrovoj-transformacii-ot-rosta-pribyli-magnita-do-avtom-887b0bd976.avif) ![image](/assets/original/694501c7336a512564f09149d5aeff01-f0fe-4d7d-8201-d6832f0437fa-b84bb0e7da.webp) --- О нас Услуги Кейсы Блог Карьера Основы ценообразования Бизнес-стажировка Отзывы PIM/MDM-системы ESB-интеграции DevOps Low-code Микросервисы B2B-порталы и e-commerce PWA Magento Калькулятор проекта Unit-экономика © 2026 ООО «КТ Групп» ООО «КОМПЛИЦЕРТЕ ТЕХ» Komplizierte Technologien, GmbH Россия Тольятти, ул. 40 лет Победы, 41 Москва, Романов переулок, 2с1, пространство Noodome clients@kt.team +7 (495) 204-14-33 Положение о работе с персональными данными →