Проектное управление по "методу параноика" или как мы всей командой учились у Вадима Митякина

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

Среди наших работ - корпоративные порталы, витрины и интернет-магазины с десятками тысяч товаров, сервисы по подписке, LMS-системы, личные кабинеты дилеров и пациентов.

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

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

1.Разрыв между продажами и производством

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

Но отказаться от фиксовой оценки тоже нельзя, поскольку бизнесу нужно знать какие затраты закладывать в бюджет и просто T&M или оценка широкой вилкой не подходят.

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

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

2. Необходимость модернизации тех процесса.

Проекты становились более многослойными: больше интеграций, реализация LMS, геймификация, сложные ролевые модели, конструкторы внутри админ. части и т.д.

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

Это могли быть критичные проблемы с обменом данными со сторонней базой заказчика, которые ставили проекты на паузу на месяцы, пока заказчики приводили инфраструктуру в порядок со своей стороны. Или резкие “развороты” проекта в другое направление, после того, как часть проекта была реализована, потому что кто-то из C-level компании заказчика обратил внимание на проект и решил, что всё движется в неверном направлении. В крайних случаях приходилось переписывать почти всю архитектуру проекта, или целиком “выкидывать” куски готового, но не актуального функционала.

На выходе: перерасход бюджета и сильные выходы за сроки проекта или снижению планки качества.

3. Взаимодействие с более крупными заказчиками требовало переосмысления позиционирования

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

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

Все это привело к тому, что ключевые участники команд оказались на групповом консалтинговом треке Вадима Митякина для диджитал-компаний. (https://mityakin.com/)

С Вадимом мы познакомились в Перми на конференции Ural Digital Weekend летом 2025 года и разговорились после его доклада, что нас и привело к идеи посотрудничать. Оказалось, что Вадим в свое время уже сталкивался с теми же проблемами и его “Метод параиноика” затрагивает все вопросы, которые нас волнуют. Метод предлагает решения. Конечно, мы не хотели изобретать велосипед.

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

Рынок изменился таким образом, что сейчас цифровые продукты служат фундаментом успешного бизнеса. Они влияют на выручку, издержки, скорость принятия решений и конкурентоспособность. Цифровые продукты перестали быть «вспомогательным решением», неправильно воспринимать их просто как инструмент “автоматизации”. Множество компаний работают благодаря цифровым продуктам, даже если они не считают себя IT-бизнесом.

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

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

В этот момент компания стоит перед выбором одной из двух стратегий:

1. Взять готовое, проверенное решение - “седину”

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

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

2. Создать новый цифровой продукт - “мозги”

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

После появления продукта начинается третий этап — развитие и сопровождение, то, что в методе относится к категории “процессы”: улучшения, релизы, итерации, поддержка, развитие архитектуры.

И рано или поздно цикл повторяется: продукт устаревает → бизнес снова выбирает между готовым решением или созданием нового.

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

• Мозги - разработка уникального решения: высокий уровень неопределенности, много проектирования, создание принципиальной схемы решения задачи с нуля. Когда команда проекта формируется постепенно - чем больше мы понимаем о будущем продукта, тем понятнее какие специалисты нужны. Нельзя запланировать состав команды заранее, когда у продукта вообще нет очертаний - может это веб-сервис, может приложение с голосовым управлением, может ИИ- агент.
• Седина - реализация проекта, где уже есть опыт, наработки, решения, повторяемость. Переиспользование наколенной экспертизы. Предсказуемость, стабильность, четкие границы.
• Процедуры - развитие и поддержка продукта: важно качество, скорость реакции, управляемость.

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

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

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

Одним из центральных элементов обучения стала концепция воронки неопределённости: любая работа над продуктом начинается с большого количества неизвестных.

Клиент может приходить с идеей или задачей, но:

• цели могут быть сформулированы не до конца,
• у разных участников проекта своё понимание результата,
• ограничения ещё не выявлены,
• ключевые решения находятся “в воздухе”

Важная идея метода - неопределенность должна снижаться последовательно по ходу проекта. Закрыть все проблемы и принять все решения на старте проекта или еще на pre-sale этапе - невозможно. Только если это не переиспользование ранее созданного продукта, опять же, тогда да, но все равно остается неопределенность, связанная с индивидуальными особенностями конкретного бизнеса.

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

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

Но по ходу обучения мы поняли, что можем пойти еще дальше, например выделять потенциально проблемные обмены и интеграции, важные для будущего проекта, и начинать тестировать реализуемость задуманного функционала чуть ли не на старте проекта. Не на уровне чтения документации, а максимально приближенно к практике. Так мы будем либо заранее уверены что все “заведется”, либо начнем решать проблему задолго до того, как она станет “острой”.

Метод выделяет пять уровней “слоев” проекта:

1. Бизнес-уровень — цели компании, роль инструмента, бизнес-эффект, сценарии использования.
2. Функциональный уровень — что система должна уметь делать; функции, сценарии, роли, процессы.
3. Интерфейсный уровень — пользовательские пути, UX-решения, экраны, взаимодействия.
4. Технический уровень — архитектура, интеграции, ограничения, технологии, подходы к реализации и код.
5. Организационный уровень — команда и роли, распределение ответственности, процессы согласований.

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

У нас отчасти эти “слои” были стадиями проекта. Они были последовательными и линейными. Кроме организационного. Что порождало много сложностей, из-за того, что все эти “слои” взаимосвязаны. Помимо примера который уже был, где мы доходит до разработчика (технического уровня) уже к концу проекта и узнаем о сложностях в реализации, можно вспомнить также знакомый многим пример, когда к финальной стадии проекта появляется важный стейкхолдер и оказывается, что не было учтены какие-то важные нюансы бизнес-процессов. И затем отказываются принимать проделанную работу и мило просят переделать половину готового продукта. Это следствие того, что бизнес “слой” проекта часто теряется после первичных встреч и договоренностей. Хотя для бизнес-образующего цифрового продукта такое просто недопустимо, на вовлечении ЛПР-ов со стороны бизнеса нужно настаивать на адекватном регулярном процессе согласования - нужны регулярные срезы, чтобы постоянно уменьшать неопределенность, пока не поздно.

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

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

• Концепция - поиск того решения, которое потенциально удовлетворит целям бизнеса, но также впишется в ограничения и технологические возможности. По методу - результатом работы должен стать путь очень упрощенный, но рабочий прототип. И речь не про интерактивный прототип в Figma или Axure, а именно набросок готового продукта с минимальной технической реализацией.
• Верхнеуровневое проектирование - создание фундамента UX, UI и технической архитектуры. На выходе - более детализированный прототип, который использует общую дизайн систему, с навигацией, но без прикладной функциональности
• “Раны” - циклы выпуска продукта
• а) Детальное проектирование - проектирование конкретного релиза и защита решения перед разработчика
  b) Реализация - реализация принятого от проектировщиков решения

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

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

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

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

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

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

Были и “домашние задания” с разборами в лайве - создание нового для нас артефакта - “функциональной модели”.

Самое важное именно в прохождение консалтингового трека, в отличии от простого чтения книги - адаптация методологии конкретно под нашу ситуацию.

Значительную часть наших проектов составляет тип “Процедуры” где мы выступаем в роли продакшена. Но в последнее время мы начали получать проекты типа “Мозги” и “Седина”. К таким проектам мы и стремимся. Но проекты типа “Процедуры” для нас пока что необходимы, хотя раньше мы думали что надо ими пренебрегать. Нам надо направлять усилия и в их сторону - стратегически планировать под них и продажи и производство, чтобы они покрывали нашу точку безубыточности. Это нормально, что более значительные проекты сейчас занимают небольшую часть нашего производства - мы будем адаптироваться под них постепенно. Т.е. нам надо искусственно ограничивать кол-во или объем проектов типа "седина" и “мозги” для нас, чтобы уменьшать риски и продолжать быть финансово устойчивыми.

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

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

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

Во первых, надо идентифицировать тип проекта. Если это не совсем типовой “процессный” проект, то надо выделить время и составить верхнеуровневую функциональную модель проекта. Это продемонстрирует для самих заказчиков масштаб их проекта - чаще всего они сами не догадываются. И это будет фундаментом для того чтобы сравнить наше видение проекта с видением заказчика. Затем оценивать уже отдельные функциональные единицы, чтобы сразу можно было очертить из него MVP.

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

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

Раньше мы делали этот документ уже после подписания договора.

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

Еще и сам Business Case можно модернизировать. Сейчас он "критерии успеха проекта" и мы представим их в виде таблицы, где напротив каждого критерия будем отмечать функцию будущего продукта, которая за этот критерий отвечает. Это поможет лучше сориентироваться при груминге сметы - приоритезировать функции, не выкинуть критически необходимое.

А еще - почему бы не поделиться с потенциальным клиентом наши статьи и записи вебинаров? Они ответят на часть его вопросов и заодно продемонстрируют нашу экспертизу.

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

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

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

Из этого всего родилась идея проведения эксперимента нового формата взаимодействия с потенциальными новыми заказчиками:

• Отправляем презентацию о том, что клиент получит по результатам бриффинга. В презентации коротко рассказываем, как мы сужаем неопределенность что это необходимо для того, чтобы составить КП. Это должно быть триггером выхода на коммуникацию с нами, мы показываем что заинтересованы в продуманном подходе, а не просто хотим побыстрее стрясти денег.
• Бриффуем клиента
• После бриффа составляем функциональную модель, а также “транзакционную модель”, которая показывает роль продукта в бизнесе. А также Business Case.
• Отправляемся на вторую встречу с заказчиками, обсуждаем артефакты, проверяем насколько мы правильно поняли их видение, делимся своими соображениями
• Составляем КП, разбитое по ключевым сценариям или функциями, также как и функциональная модель. Оцениваем сроки на отдельные релизы, а не весь проект. Демонстрируем вместе с презентацией о нашем технологическом процессе.

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

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

Во вторых, мы переформатируем портфолио, чтобы наши проекты были понятнее потенциальным заказчикам. Сейчас это больше похоже на технические описание работы, что понятно скорее коллегам по отрасли. А мы наконец дойдем до того, чтобы описывать именно бизнес уровень проекта. Например, даже само название кейса - “Пример: проект “доска объявлений для недропользователе” - “мы помогали продавать участки с залежами природных ископаемых”.

И в дополнение - пришло видение нового слогана - “Мы делаем digital- инструменты для коммуникаций в фарме и медицине”. Идея в том, что мы пишем про коммуникации в целом, чтобы показать, что мы возьмемся решить его задачу целиком - от проектирования и до создания контента. Также и в других материалах, например в презентации или на сайте покажем воронку коммуникаций фармкомпаний с клиентами и с врачами/провизорами. Чтобы показать какие коммуникации мы помогаем поддерживать ( привлечение, удержание, вовлечение ).

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

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

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

Владимир Волчанин

Поделиться

Больше полезной информации
у нас в Telegram-канале

Подписаться