Какие данные нельзя публиковать в проекте на фриланс-бирже

Какие данные нельзя публиковать в проекте на фриланс-бирже

В проекте на фриланс-бирже легко переборщить с деталями. Заказчик хочет, чтобы фрилансер понял задачу, и по привычке вставляет в текст всё подряд: имя руководителя, доступы, скриншоты, договор, реквизиты, внутренние комментарии. На выходе получается не бриф, а утечка.

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

Ниже разберём, какие данные нельзя публиковать в проекте на фриланс-бирже, и как переписать описание так, чтобы фрилансер понял задачу без лишнего риска. Сохраняем смысл. Убираем лишнее.

1. Личные и идентифицирующие данные заказчика

Первый слой риска — всё, что позволяет связать проект с конкретным человеком или конкретной компанией. Это может быть полное имя руководителя, личный телефон, почта с фамилией, внутренний номер сотрудника, точное название отдела, адрес офиса, а иногда даже редкая формулировка должности. Если проект видят десятки исполнителей, такие данные быстро расходятся дальше, чем хотелось бы.

Встречается и более тонкая проблема: заказчик пишет не «нужен дизайн лендинга», а «нужен дизайн лендинга для нового продукта компании N, запуск 14 октября, согласование через Анну Петрову». Вроде бы ничего критичного, но этого уже достаточно, чтобы понять, кто заказчик, когда у него запуск и кто отвечает за сроки. Такие связки лучше убирать полностью или заменять на нейтральные формулировки.

Если задача касается внутреннего аккаунта, филиала или персонального кабинета, не публикуйте название, по которому можно найти владельца. Лучше писать «нужна настройка страницы компании» или «нужна доработка личного кабинета клиента». Коротко. Без привязки к фамилиям.

2. Доступы, коды и сведения для входа в системы

Логины, пароли, токены, API-ключи, одноразовые коды и резервные коды восстановления нельзя публиковать ни в каком виде. Не в тексте проекта, не в скриншоте, не в PDF, не в комментарии к файлу. Один забытый токен в открытом проекте потом ищут всем отделом, а иногда и с участием службы безопасности.

Нередко заказчик прикладывает «для удобства» доступ к тестовой админке, ссылку на облачную папку с уже сохранённым паролем или скрин входа, где в строке браузера виден session token. Такой материал уже нельзя считать безопасным описанием задачи. Если без доступа совсем не обойтись, публикуют только факт наличия доступа, а сами реквизиты передают в закрытом сообщении после выбора исполнителя.

Отдельная ловушка — скриншоты с открытыми вкладками, где видны email, логин и код подтверждения. На первый взгляд это просто подтверждение проблемы, но на практике это уже готовый набор для входа. Два изображения могут стоить дороже всей задачи.

Полезно заранее свериться с правила сайта profreelance.biz. Сайт фриланса. Сайт и не выкладывать то, что администрация потом удалит вручную. Проверка перед публикацией занимает минуты.

3. Внутренняя информация о бизнесе, которая не нужна для отклика

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

Хороший тест простой: если фрагмент текста отвечает не на вопрос «что нужно сделать?», а на вопрос «как устроен наш бизнес изнутри?», его лучше убрать. Например, фраза «нужно обновить описание каталога перед закрытием старого склада и переходом на новую логистику» полезна только наполовину. Для фрилансера важнее: «нужно обновить 120 карточек товара по новому шаблону». Число тут не случайное. Оно показывает объём и не раскрывает стратегию.

То же касается внутренних регламентов, планов запуска и переписки, где сотрудники обсуждают слабые места продукта. Если проект требует контекста, используйте обезличенный бриф: краткая цель, 3–5 требований, 1 срок, 1 критерий результата. Остальное — в закрытый файл. Без историй из кухни.

4. Материалы с ограничением по конфиденциальности

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

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

Особенно осторожно стоит относиться к материалам, где есть коммерческая тайна: черновики рекламных кампаний, неанонсированные продукты, тексты до публикации, схемы ценообразования, внутренние отчёты. Если файл нужен фрилансеру для понимания стиля, лучше оставить 1–2 фрагмента и удалить все служебные поля. Если нужна структура, дайте структуру, а не сырой документ.

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

5. Платежные и юридически чувствительные данные

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

Юридически чувствительные данные тоже требуют аккуратности. Например, в проекте не нужно писать номер доверенности, серию паспорта директора, данные для налогового отчёта или скан свидетельства, если задача — всего лишь подготовить лендинг, адаптировать договор или настроить верстку. Для постановки задачи достаточно описания, сроков и роли документа. Всё остальное передаётся только тем, кому это действительно положено.

Иногда заказчик думает, что фрилансеру «и так пригодится» номер счёта для выставления счёта или оплаты. Нет. Для отклика это не нужно. Для старта работы достаточно согласовать формат расчётов уже после выбора исполнителя, а ещё лучше — использовать безопасную сделку на ProFreelance, если она подходит под ваш формат взаимодействия.

6. Персональные данные третьих лиц, не участвующих в проекте

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

Особенно часто это случается в проектах по аналитике, поддержке, маркетингу и HR. Заказчик хочет показать реальный кейс и прикрепляет выгрузку из базы: 300 строк с email, телефоном и историей заказов. Для фрилансера это полезно как пример формата, но опасно как набор персональных данных. Безопаснее создать копию и заменить всё на маски: «клиент 01», «менеджер А», «покупка 12.06».

Если нужен визуальный пример, возьмите только те части, где нет идентификаторов. Две обезличенные строки часто лучше, чем одна настоящая. И уж точно спокойнее.

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

7. Как переписать описание проекта без раскрытия секретной информации

Переписать проект можно по простому алгоритму из 4 шагов. Сначала оставьте только цель: что нужно получить в конце. Потом добавьте объём: сколько страниц, блоков, файлов, экранов или записей. Затем впишите требования к формату. И только после этого посмотрите, какие детали не нужны для отклика и могут выдать лишнее.

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

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

Ещё один практический приём — проверка по трём вопросам: можно ли по этому фрагменту понять, кто заказчик; можно ли использовать его для входа в систему; можно ли по нему восстановить внутреннюю схему бизнеса. Если хотя бы один ответ «да», фрагмент надо убрать или заменить. Это не теория, а обычная гигиена публикации.

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

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