Задача
Обычная биржа фриланса плохо подходит для инженерного заказа. Заказчику важна не цена и рейтинг, а специализация, опыт работы с конкретными технологиями и производствами, владение расчётными и CAD-инструментами, наличие сертификаций и способность сдать результат в требуемом формате.
Сам заказ тоже сложнее типовой цифровой услуги. Разработка производственной линии или комплекта технической документации состоит из обследования, расчётов, нескольких версий решения, согласования спецификации и финальной приёмки. Состав передаваемых материалов и критерии готовности нужно зафиксировать до начала работ и держать доступными всю сделку — иначе на приёмке выясняется, что стороны понимали задачу по-разному.
И третье: между незнакомыми компанией и инженером нет доверия. Заказчик не хочет платить вперёд, инженер — работать без гарантии оплаты. Кто-то должен держать деньги и разбирать спор, если он случится.
Решение
Специализации как управляемый справочник, а не теги. Инженер указывал отрасли, инженерные дисциплины, типы работ, программные инструменты, языки, формат сотрудничества и доступность. Справочник позволял различать проектирование производственного оборудования, автоматизацию, промышленный дизайн и подготовку электротехнической документации — и использовать эти различия в поиске и рекомендациях, а не полагаться на совпадение слов в описании. К профилю прикладывались примеры проектов и документы, а контактные и платёжные данные и профессиональные подтверждения проходили проверку; её статус был виден заказчику до начала переговоров.
Задание как конструктор с этапами. Заказчик выбирал предметную область и тип работ, формулировал ожидаемый результат, описывал исходные условия, прикладывал технические материалы и задавал бюджет или способ его согласования, сроки, требуемые компетенции и критерии приёмки. Сложная работа разбивалась на этапы, у каждого — своё содержание, результат, срок и сумма. Такая структура заранее показывала обеим сторонам, что считается завершением части работ, и позволяла рассчитываться постепенно. Черновик можно было передать коллегам на внутреннее согласование, а перед публикацией система проверяла обязательные поля и показывала итоговый вид задания.
Рекомендации в обе стороны. Механизм сопоставлял требования проекта с профилями специалистов и их историей на площадке: релевантные компетенции, опыт, подтверждённый профиль, доступность, качество предыдущих контрактов. Инженеру показывались подходящие открытые проекты, заказчику — специалисты, которых можно пригласить персонально, а после публикации система помогала выделить наиболее релевантные входящие предложения. Финальное решение оставалось за человеком.
Предложение с прослеживаемой историей. Отклик был отдельным объектом: подход к решению, условия, сроки, стоимость, возможная декомпозиция на этапы, сопроводительное письмо, уточняющие вопросы и материалы под конкретный заказ. Заказчик фильтровал предложения, собирал короткий список и приглашал выбранных к обсуждению. До заключения контракта стороны уточняли объём и условия, но изменения не перезаписывали исходное предложение бесследно: актуальная редакция связывалась с предыдущими договорённостями, чтобы было видно, как сформировались финальные условия.
Рабочее пространство контракта. Согласованные параметры превращались в контракт: стороны, содержание работ, этапы, суммы, сроки, критерии приёмки, порядок передачи результатов. Подтверждение обеих сторон переводило проект в работу. В рабочем пространстве собирались переписка, исходные файлы и новые версии материалов, состояния этапов, переданные результаты и комментарии к ним, запросы на изменение условий и финансовая история. Файлы связывались с этапами и сообщениями, а история версий отличала промежуточную редакцию чертежа от результата, переданного на официальную проверку.
Изменение объёма — отдельная процедура. Если требования менялись, стороны оформляли это через платформу: описывали новый объём, влияние на сроки и стоимость и подтверждали обновлённые условия. Согласованные дополнительные работы отделялись от обычных комментариев в переписке — именно на этой границе чаще всего расходятся устные договорённости.
Деньги привязаны к этапу, а не к пользователю. Платёж связывался с конкретной сделкой и её этапом, комиссия рассчитывалась площадкой, история операций сохранялась целиком. Система поддерживала внесение средств заказчиком, подтверждение платежа, удержание суммы до выполнения согласованного этапа, выплату инженеру, отмену и возврат. Повторные запросы не создавали дублирующих операций, а состояние контракта менялось только после подтверждённого финансового результата. Администратор мог найти транзакцию по пользователю, контракту или внешнему идентификатору и передать исключительный случай на ручную обработку.
Спор с полным контекстом. Если стороны не сходились по результату или оплате, контракт переводился в спор. Модератор видел исходное задание, согласованные изменения, переписку, версии файлов, решения по приёмке и финансовые операции — то есть разбирал ситуацию целиком, а не по пересланным письмам. Решение могло подтвердить приёмку, вернуть этап на доработку, скорректировать финансовое завершение в допустимых пределах или закрыть контракт по согласованному сценарию. Все действия модератора протоколировались и были видны участникам сделки.
Результат
Компания-заказчик проходит путь от технической потребности до принятого результата в одном продукте: структурированное задание, профильный специалист, зафиксированные условия, работа по этапам и приёмка с историей версий. Права в корпоративном кабинете разделены, поэтому подготовку задания, общение с кандидатами, согласование условий и финансовые действия можно вести разными людьми.
Инженер получил специализированный канал заказов вместо конкуренции с массовым фрилансом, профессиональный профиль, в котором видна его квалификация, и рабочее пространство, где зафиксировано, что именно и к какому сроку он сдаёт. Репутация учитывает не только оценку, но и историю завершённых контрактов, соблюдение обязательств и предметную область работ; заказчик тоже накапливает историю на площадке.
Сама платформа перестала быть доской объявлений. Встроенный финансовый и арбитражный контур позволил ей не только знакомить стороны, но и сопровождать сделку до конца: отдельные очереди в администрировании показывали публикации на проверке, сделки без движения, задержанные платежи и обращения с приближающимся сроком ответа. Продукт построен на ASP.NET.
