
Содержание
Введение
Когда мы запускали разработку сервиса для управления проектами, не было задачи сделать универсальный продукт. Всё началось с проблем, с которыми сталкивались мы сами: запутанные задачи, несвязанные проекты, ручной учёт, отсутствие общей картины. Сначала мы хотели просто наладить работу внутри команды. А в итоге пришли к решению, которое оказалось полезным для команд из самых разных сфер — от агентств до строителей.
Чтобы понять, что действительно важно для пользователей, мы применили метод Jobs To Be Done. Это помогло увидеть общие задачи, которые люди хотят решать с помощью сервиса, и отказаться от избыточных функций. В этой статье расскажем, как мы шли от первых интервью и какие решения оказались ключевыми.

Что помогло понять пользователей
На старте мы отказались от опросов и анкет. В B2B они не работают: слишком разный контекст, слишком много нюансов. Мы выбрали метод глубинных интервью по Jobs To Be Done. В процессе общались с командами из разных отраслей — маркетинг, консалтинг, строительство, дизайн, некоммерческие организации.
Несмотря на разницу в задачах и масштабах, запросы были похожи. Всем было нужно:
- Видеть, кто что делает и в какие сроки
- Работать по понятной структуре, без хаоса
- Быстро передавать задачи между сотрудниками
- Контролировать деньги внутри проекта
Это подтвердило: универсальные решения действительно возможны. Главное — не гадать, а внимательно слушать.
Почему база знаний стала важной частью
Первоначально модуль базы знаний не был в приоритете. Мы думали, что компании будут использовать внешние инструменты или вообще обойдутся без него. Но почти сразу стало ясно: отсутствие удобного внутреннего хранилища сильно тормозит работу.
Многие команды сталкивались с одними и теми же трудностями:
- Сотрудники не знали, где найти инструкции или шаблоны
- Новые специалисты долго входили в курс дела
- Одни и те же вопросы приходилось решать по несколько раз

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

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

Василий Ферапонтов
Директор направления облачных продуктовЭто подтвердило: решение может быть адаптировано под разные команды без глубокой кастомизации. Главное — простая структура и чёткая логика.
Как мы используем ИИ и зачем он нужен
Сейчас мы активно тестируем внедрение ИИ. Но делаем это не потому, что «так модно», а потому что в некоторых местах он действительно упрощает работу.
Что мы пробуем:
- Автоматическая постановка задач по шаблону
- Напоминания и прогнозирование дедлайнов
- Генерация отчётов по итогам проектов
Мы видим ИИ как помощника. Он должен снимать рутину, а не усложнять процессы

Василий Ферапонтов
Директор направления облачных продуктовОсобенно полезными такие сценарии оказались для команд, которые работают в диаграмме Ганта. Это один из примеров, когда опыт конкретной отрасли помогает улучшить функции для всех пользователей.
Выводы
За время разработки мы убедились, что хороший продукт не рождается из гипотез. Он появляется тогда, когда команда слушает пользователей, адаптирует решения и не боится менять приоритеты. Мы не стремились создать сервис «для всех», но реальная практика показала, что с правильной логикой и простой структурой он подходит разным командам.

Сегодня Аспро.Cloud — это не просто таск-трекер. Это платформа, которая помогает видеть работу целиком: от задач до денег, от знаний до командных процессов. И мы продолжаем развивать её на основе обратной связи.
Понравилась статья?
А что вы думаете по этому поводу? Поделитесь с нами
Комментарии