Практики работы с OKR: реальные примеры из команды Авито
В финальном эпизоде нашего открытого курса по методологии OKR вместе с Сергеем Кузиным, ведущим agile-коучем Авито, структурируем все этапы работы: разбираем каждый из них на примере Авито и узнаем, как извлечь максимум пользы из ретроспективы по итогам цикла.
Все серии курса для вашего удобства собрали здесь: можно повторить пройденное в любое время, а также поделиться советами с коллегами!
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
70% процессов и изменений в организациях либо не достигают целей, либо превращаются в бессмысленные ритуалы
В июне выступал на TeamLead Conf в Петербурге с темой «Жизненный цикл процесса: от идеи до отмены». Поговорили о том, почему не все процессы должны жить вечно, как вовремя их пересматривать и когда полезнее закрыть, чем пытаться чинить.
По результатам оценок участников конференции, мой доклад попал в топ-5 — очень приятная неожиданность.
Ну что вы скажете? С 12 минут до 3 секунд(!) сократил время поиска инструкций полнотекстовый поиск в KMS Gran.
Один из наших клиентов - IT-компания - хранила документацию в Google Docs и Telegram, что вызывало путаницу. В 2024 году внедрили базу знаний KMS Gran, создав разделы "Проекты", "API-документация" и "Ошибки и уроки".
Результат спустя год:
время поиска инструкций сократилось до 3 секунд
скрипты автоматизировали уведомления о новых версиях API, уменьшив время согласования релизов на 30%.
за 6 месяцев количество багов в коде снизилось на 25%, так как разработчики быстро находили решения по прошлым ошибкам.
Статистика показала, что раздел "Ошибки и уроки" просматривали 80% команды, что привело к добавлению видео-разборов типичных ошибок.
А какие процессы хотелось бы улучшить в вашей команде?
Сервис «Контур.Толк» провёл исследование с участием 1500 респондентов из разных регионов страны: им нужно было назвать фразы, которые чаще всего раздражают в деловой переписке и на созвонах.
На первом месте оказались старые добрые канцеляризмы вроде «прошу рассмотреть возможность», «принять к сведению» и «ожидаем вашу позицию». Их считают пустыми, вымученными и не несущими смысла. Сразу за ними — англицизмы и айтишный сленг. Например, «синканемся», «скипнуть», «замэтчиться», «закоммититься» и прочее, что больше похоже на корпоративное заклинание, чем на внятную речь.
Вот как выглядит топ-10 слов и выражений, которые россияне терпеть не могут в деловой коммуникации:
Канцеляризмы: «принять к сведению», «прошу рассмотреть»;
Как построить отказоустойчивую инфраструктуру на базе Bare Metal: кейс компании SEOWORK
SEOWORK — платформа для мониторинга и аналитики поискового маркетинга. Компания развернула IT-инфраструктуру на выделенных серверах Selectel.
Основа инфраструктуры — выделенные серверы в дата-центрах уровня Tier III. Они связаны локальной сетью со скоростью до 10 Гбит/с и изолированы от интернета.
За производительность отвечают процессоры AMD EPYC™ 7452 (32 ядра), 512 ГБ RAM на сервер и быстрые SSD-диски корпоративного класса в RAID объемом до 20 ТБ.
Вся инфраструктура Selectel по умолчанию соответствует требованиям 152-ФЗ и защищена от DDoS-атак на уровнях L3-L4. Независимый трехмесячный пентест выстроенной системы, выполненный по заказу SEOWORK, подтвердил ее защищенность.
Подробнее о том, как компания развернула на Bare Metal производительную и отказоустойчивую инфраструктуру с SLA 99,8%, которая ежедневно обрабатывает более 600 ГБ данных, читайте в Академии Selectel.
Что почитать проджект менеджерам (и не только проджект)
Самое смешное, что мне этого автора рекомендовали не один раз, но я упорно рекомендацию игнорировал, так как бизнес-литературу вообще недолюбливаю. Я периодически себя заставляю ее читать, но для меня это обычно проходит с болью: либо это сухо написанная, душноватая теория с некоторыми абстрактными кейсами, либо книга, где автор через каждые пару страниц напоминает, какой он крутой и сколько денег он зарабатывает в секунду (не верите? Ден Кеннеди — пример).
Автор который меня реально удивил и чьи книги я бы назвал супер полезными - Элияху Голдратт, а его книги «Цель: процесс непрерывного совершенствования» и «Критическая цепь»— это настоящие пособие для тех, кто занимается менеджментом и хочет понимать принципы, цели и проблемы бизнеса как сложного механизма (а еще, как со всем этим справляться), а еще понимать, как стоит и не стоит управлять сложными проектами с точки зрения ресурсов и времени.
В чем основное ВАУ автора? Дело в том, что что книги вроде как не совсем учебник, а написаны в формате романа. Не ожидая чего-то прямневообразимого, я сел за чтение… и все. Оторваться совершенно невозможно!
«Цели..» - это история директора загибающегося завода и его битвы за то, чтобы их не закрыли к чертям. Через его проблемы, поражения и победы происходит понятное и практически применимое раскрытие основных принципов организации высокоэффективного бизнеса
«Критическая цепь» - в схожем стиле, но с новыми героями, рассказывает про разработку нового, более практичного метода управления проектами, который основывается на теории ограничений
И самое классное: ты не просто читаешь про какие-то абстрактные теории и героические кейсы, а за счет интересного повествования оказываешься полностью погружен в проблему, сопереживаешь герою и подсознательно пытаешься найти решение.
Спойлеры излишни, но, жти произведения реально помогут лучше разобраться в том:
как определить правильную цель своего бизнеса;
из-за чего даже самое передовое предприятие может рухнуть;
что за «узкие места», как с ними бороться и как не создать новые;
почему работа отнимает все отведенное на нее время;
как ускорять выполнение проектов при ограниченных ресурсах;
как сделать процесс совершенствования постоянным и чем, должны заниматься настоящие руководители.
Ну и многое другое. Короче, всем менеджерам — в список к прочтению под номером 1!Прочитав, я жалею о двух вещах. Первое — что не прочел книжки раньше раньше (и это не фигура речи). Это крутой бизнес-учебник. Второе — что они слишком быстро кончились. Но это дает повод больше познакомиться с творчеством автора.
Если вам нравится читать и узнавать про бизнес и менеджмент, то приходите на мой канал
Поделюсь сегодня опытом по составлению Go-to-market-strategy. Ошибки, которые совершают фаундеры при выводе стартапов на рынок, в целом, однотипны: это попытки сделать все фичи сразу, игнорирование действий конкурентов, некачественный анализ рынка или аудитории, ошибки при расчете Unit-экономики. Об этом мы уже много раз говорили. Поэтому сегодня расскажу о нескольких “подводных камнях”, которые не очевидны сразу, особенно тем, кто запускает стартап впервые.
Распыление усилий на все сегменты ЦА на первоначальных этапах
Да, создавать портрет клиента и сегментировать аудиторию необходимо. Но на самом первом этапе не стоит распределять внимание на все сегменты и пытаться угодить всем. Сосредоточиться лучше на самом большом/платёжеспособном сегменте аудитории, который будет основным. Все остальные сегменты “подтянутся” в процессе доработки продукта.
Распределение равных усилий между каналами продвижения
Здесь так же как с сегментами аудитории, лучше сосредоточиться на одном-двух каналах, где ваша аудитория точно присутствует и которые приносят вам лиды и заявки. Набор каналов продвижения можно постепенно расширять, тестируя различные гипотезы. Результаты по всем подтвердившимся гипотезам - масштабировать.
Попытки строго следовать намеченному плану
Фаундеру стартапа необходим план. Однако еще больше необходима готовность от него отступить в случае необходимости. У проекта должен быть план не только на полгода-год, но и на 2-3 года вперед. Это план должен содержать в себе прогноз по рынку - куда будет двигаться ваша сфера и будет ли ваш продукт соответствовать потребностям аудитории? При этом, важно понимать, что любой прогноз может не сбыться, поэтому придется быть подвижным и что-то менять в проекте и своём подходе к его реализации.
Вывод продукта на рынок - самый волнительный и ответственный момент для любого стартапа. Будьте гибкими, но последовательными!
Новая статья на Habr: Опыт t2 по масштабированию BI на 4500+ пользователей
Опубликовали большой кейс о том, как компания t2 (бывший Tele2) решила одну из главных проблем российского рынка аналитики — нехватку западных BI-решений.
Главные цифры кейса: 4500+ пользователей FineBI 400+ разработчиков отчетности Кластерная архитектура с 6 нодами 3 года успешной эксплуатации
Ключевые инсайты: ✅ Как организовать автоматизированное обучение пользователей ✅ Почему безлимитные лицензии стали ключевым мотиватором миграции ✅ Как построить внутреннее сообщество поддержки в Telegram ✅ Зачем нужна поэтапная миграция с участием бизнес-пользователей
Для кого будет полезно Руководителям аналитики — практический опыт масштабирования BI IT-директорам — архитектурные решения и организация процессов Аналитикам — понимание современных self-service подходов Всем, кто планирует миграцию — реальные уроки и рекомендации
Бонус от GlowByte В статье также рассказываем об образовательном ретрите по FineBI, который стартует 25 августа: 🔸 13-дневный марафон с обновленной программой 🔸 3 эксклюзивных вебинара: FineReport Pro, AI в аналитике, 3D-визуализация 🔸 Реальные кейсы от t2, Уралсиб, Циан и других компаний 🔸 Система призов за лучшие домашние задания
ERP-проектов на базе 1С всё больше, так что упомянуть это свежевышедшее издание книги не будет лишним.
Автор вроде бы опытный методист, теорией не перегружает, говорит на языке бизнеса. В книге по верхам собрано всё: от оценки сроков и бюджета до управления конфликтами и рисками. Акцент сделан на практику внедрения ERP на платформе «1С:ERP».
ЦА книги - это заказчик системы. А поскольку ассоциация 1С с продуктами для регламентированного учета всё ещё актуальнее других, отдельная глава посвящена тому, чем ERP-система отличается от системы для бухучёта (и почему она такая дорогая🌚).
Дальше - про стартовый этап проекта: про функциональные требования и их сбор, у кого и как собирать, в каком формате про выбор подрядчика (тендер) и этапы RFI, RFP, RFQ (если кто не знал, что это) про fit-gap-анализ (в среде 1С это зовут еще выявлением функциональных разрывов) и об оценке IT-инфраструктуры, включая нагрузочное тестирование, и расчет окупаемости.
Сам процесс внедрения может идти по принятым подходам (PMBOK, ISO, ГОСТ 34, Agile), а может и по фирменным методикам 1С (ТБР и т.д.). Стандартная модель - каскадная: инициация → анализ → проектирование → разработка → тестирование → ввод в эксплуатацию. Акцент на важности реинжиниринга бизнес-процессов (чтобы не автоматизировать хаос).
Отдельная глава - про стороны проекта внедрения. Команда исполнителя (внедренцы, методисты, разработчики), рабочая группа заказчика (ключевые пользователи), управляющий комитет (топы, принимающие решения).Само собой, говорится про важность мотивации, коммуникации и командообразования — иначе всё развалится.
Документация - тут всё очень кратко, в основном про использование бизнес-нотаций (IDEF0, BPMN, EPC) и прототипирование.
Говоря про сроки и бюджет, автор касается методов оценок (аналогия, экспертная, PERT, «сверху вниз» и «снизу вверх») и вспоминает классику - «мифический человеко-час», ошибки планирования, скрытые доработки. Отдельная глава - про управление рисками, про типовые риски (текучка кадров, ошибки ТЗ, сопротивление пользователей), управление|борьбу с ними.
По разработке и вводу в эксплуатацию - акценты на использовании нескольких контуров или баз (тестовая, рабочая и даже “грязевая” для экспериментов), и конечно же, на важности обучения пользователей и сбору обратной связи Ну и “жизнь после смерти” - собственно, перевод проекта на стадию поддержки и сопровождения, поддержка пользователей и развитие системы.
Из интересного: второе издание книги оказалось стереотипным, т.е. перепечаткой с первого издания 2021 года. Конечно, хотелось бы обновлений - уж столько поменялось и в самих ИС, и в российском контексте их внедрения, - но, похоже, что у фирмы 1С всё хорошо и без этого и книга - своего рода стандарт.
Кому рекомендую: прежде всего, тем, кто готовится на роль ПМа в проектах 1С, особенно идущим на собесы, - идеальный конспект идеального внедрения (пусть его и не существует). Особенно в сочетании с одностраничными планами (приложил пример, который лично мне нравится больше других). Ну и тем, кто хочет слегка систематизировать проектный опыт.
Обзоры и дайджесты по проектному управлению - на нашем канале.
В новом выпуске «Свободного слота» разбираемся, как пробивать непопулярные решения и объяснять их команде без потерь. Гость сегодняшнего эпизода — Сергей Щербинин, CEO Faust Consulting, основатель сообщества «Безвотэтоговсего». Вместе с ведущими Сашей Прокшиной и Сашей Афёновым обсуждаем:
что такое принцип ПВО;
как не продать душу дьяволу ради результата;
как заставить себя и команду делать то, что не хочется, но очень надо.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Иконка WhatsApp* на сайте: почему цвет фона лучше не менять?
Я сознательно убрал логотип WhatsApp* с сайта своей адвокатской практики. Это было единственное изменение в предложенном макете дизайна.
Иконка WhatsApp* располагалась почти на всех страницах сайта: "Главная", "Контакты", "Адвокат" и так далее. Потенциальный клиент мог кликнуть по иконке и создать чат со мной.
Но был нюанс - мой веб-дизайнер представил иконку WhatsApp*, заменив на ней фон.
Изобразительный товарный знак WhatsApp* известен цветовым сочетанием белого, серого и зеленого. На моем же сайте использованы другие основные цвета: синий, желтый и белый.
Веб-дизайнер отрисовал иконку WhatsApp* в цветах моего сайта. Получилось стильно, но рискованно. Почему?
В самом размещении логотипа WhatsApp* на сайте нет нарушения интеллектуальных прав правообладателя товарного знака - ВотсАпп ЛЛК (Калифорния, США). Тому есть простое объяснение.
Товарный знак нужен исключительно для индивидуализации конкретных товаров. Потребитель видит товар и связывает его с конкретным производителем.
Например, вы видите сайт с именем "WhatsApp*" в доменной зоне ".com" и понимаете: здесь предлагаются к продаже товары правообладателя этого товарного знака.
В моем случае логотип WhatsApp* на сайте не предназначен для индивидуализации моих услуг под брендом "WhatsApp*". Логотип лишь информирует о том, что клик по нему переведет пользователя сайта в чат с адвокатом - владельцем сайта.
Чисто информационная функция. Как следствие - изображение логотипа занимает незначительное место на экране сайта либо помещается в один ряд с иконками иных способов связи: e-mail, телефон и так далее.
Другое дело - возможность нарушения авторских прав:
Значит, есть автор произведения искусства. И у него есть право на единоличное использование картинки, в том числе в сети "Интернет".
2. Автор картинки передал интеллектуальные права на нее компании - владельцу товарного знака WhatsApp*. И компания запретила менять цвет в логотипе.
Об этом я узнал из Условий предоставления услуг WhatsApp*: пользователю разрешено использовать логотип с учетом Руководства по фирменному стилю WhatsApp*.
В Руководстве отсутствует разрешение менять фирменные цвета. Более того, в разделе "Вопросы-ответы" дан прямой запрет на изменение цвета в логотипе.
3. Я рискую получить иск о нарушении исключительного права на произведение искусства.
Логотип WhatsApp* зарегистрирован в России, что позволяет его владельцу обратиться с иском в суд. Основание - переработка логотипа без разрешения владельца и размещение переработанного произведения в сети "Интернет".
Поэтому вы не найдете на моем сайте иконку WhatsApp*: ее фирменный стиль выбивается из моего стиля, а изменение стиля WhatsApp* незаконно.
Поговорите с вашим адвокатом. Он предложит вариант оформления на сайте кнопки, которая ведет на чат в мессенджере WhatsApp*.
Узнать мой вариант решения можно, перейдя на сайт моей адвокатской практики. Ссылка в профиле.
Мысли вслух: при желании можно оспорить сам факт создания логотипа, ведь произведение должно носить творческий характер. Но есть ли творчество в том, чтобы на зеленом фоне круга поместить телефонную трубку?
* Деятельность компании Meta Platforms Inc. (Facebook и Instagram) на территории РФ запрещена.
Практически каждый день я читаю и узнаю что-то новое про разработку. Решил начать вести посты в формате "Я узнал о... (какой-то факт)"
В краткой форме буду рассказывать о чем-то, что узнал за последнее время
---
Я узнал о... #1: FinOps
Задумка FinOps заключается в том, что мы начинаем считать расходы на DevOps и инфраструктуру в компании. Чтобы потом всё это счастье оптимизировать и сэкономить (в идеале, спрогнозировать расходы и риски).
Само название меня немного насмешило, потому что взяли "Ops" и добавили к нему другой префикс, чтобы выглядело солиднее
Стартапы очень любят таким же образом добавлять слово "Tech" ко всему подряд. Началось с EdTech и понеслось... AgroTech, FoodTech, PetTech, SleepTech, SexTech, HrTech.
Возвращаясь к сути: FinOps - это когда на уровне компании мы перманентно мониторим инфраструктуру, её загрузку и расходы, а затем ищем способы оптимизации.
McKinsey говорит, что от ~20% расходов на инфраструктуру в бигтехах уходят впустую. Следовательно, раз это нижняя планка, в среднем можно брать ~30%.
Например:
сервера, которые взяли с запасом, и >50% ресурсов не используются (но оплачиваются);
сервера для тестировщиков и стейджинга, которые мы купили и забыли про них;
прожорливые сервера у проектов, которые не особо-то рентабельны (и стоит подумать уже об оптимизации кода).
Контроль делается за счёт того, что:
Мы начинаем в целом считать инфраструктуру, чтобы понимать, что в компании есть;
Затем мы начинаем мониторить утилизацию инфраструктуры, чтобы находить простаивающие ресурсы;
Каждый инстанс закрепляем за конкретной командой или человеком, чтобы посчитать ROI этой команды в контексте инфраструктуры.
Дополнительный бонус: CTO проще объяснить фин. директору, куда и зачем мы платим, и сколько примерно денег потребуется на следующий период.
Есть софт, чтобы считать инфраструктуру в гетерогенных облаках. Есть Kubecost, который умеет считать расходы в k8s. Есть разные опции в Terraform, чтобы считать стоимость инфраструктуры.
Даже есть подходы, когда инстанс нельзя использовать, пока не добавишь его в директорию всех инстансов компании. Но как это всё использовать - пока не вникал. Просто теперь знаю, что такие опции есть
Когда это нужно?
Пока расходы меньше $30к/мес. - должно хватать гугл-таблицы и зоркого взгляда CTO/DevOps'а. И дружеского вопроса команде: - "А зачем нам это?".
Когда расходы >$30к/мес. и оперативной памяти ответственного лица не хватает - можно начинать думать об автоматизации сбора метрик. Иначе до этого момента автоматическое сведение метрик воедино рискует просто не окупиться
---
Мой Telegram канал про разработку. Мой open source проект для бекапа PostgreSQL - GitHub.
Потихоньку или “громко”: стратегии вывода стартапа на рынок
Когда все гипотезы проверены, тестирования пройдены, MVP собран, наступает волнительный и ответственный момент - вывод стартапа на рынок. Это не должно выглядеть так: запустили рекламу, сидим и ждем. Момент выхода и все процессы, которые сопровождают его, должны быть тщательно продуманы и собраны в стратегию.
Если рассматривать широко, существует два подхода к этому процессу - мягкий и жесткий. Можно встретить термины Soft Launch и Hard Launch. Они разные, но оба совершенно оправданы и эффективны по-своему.
Мягкий запуск напоминает подъем по лестнице. Ступень за ступенью, шаг за шагом, стартап выходит на новые и новые сегменты аудитории. При таком подходе есть возможность протестировать дополнительные гипотезы и понять, насколько хорошо аудитория на них реагирует. Эта стратегия идеально подойдет тем проектам, которые до конца не уверены в позиционировании или необходимости тех или иных фичей. Всегда есть шанс тихонько “откатить” какие-то детали продукта без последствий.
Жесткий запуск - это громкий выход, который заметят все. Здесь всегда много маркетинга, задействованы все каналы: соцсети, СМИ, инфлюенсеры. Цель одна: максимально быстро попасть в головы и умы пользователей и занять там много места. Здесь нет возможности доработок, зато есть шанс не оставить места для конкурентов. Жёсткий запуск - всегда риск, однако есть шанс начать получать прибыль уже с самого первого дня.
Универсального рецепта, как выходить на рынок, не существует. Лучше всего простраивать его в процессе работы над продуктом, исходя из тех принципов поведения аудитории, которые вы должны понять еще на этапе анализа идеи.
💡 Статический сайт в облаке Gramax. Можно опубликовать свою документацию буквально за пару кликов, для этого не нужен сервер или хостинг. Достаточно нажать «Опубликовать в облако» и войти в почтовый аккаунт.
💡 Фильтр по содержимому. В каталоге можно создавать статьи и абзацы для разных сборок. На портале для чтения они будут фильтроваться с помощью переключателя.
💡 Браузерная версия на мобильном. Браузерную версию Gramax можно использовать на мобильном телефоне. Доступны все действия, как при работе на компьютере.
А также:
📌 Новая главная страница. Улучшили внешний вид главной страницы. Добавили возможность создавать вложенные группы.
📌 Транскрипция речи с помощью ИИ. Если в пространстве включены ИИ-функции, редактор может автоматически транскрибировать аудиозаписи в текст.
📌 Просмотр изменений после синхронизации. После синхронизации автоматически открывается окно сравнения ревизий: сравнивается новая версия каталога с версией до синхронизации.
Об этих и других изменениях читайте в Release Notes 🔥
На управленческих курсах часто приводят подобную картинку, которая показывает, что чем дальше человек становится управленцем, тем меньше он становится специалистом.
Иллюстрация из прекрасного курса Владимира Мартынова
То есть, с ростом управленческих навыков - Soft Skills, «проседают» технические навыки - Hard Skills. И это правда, с этим спорить я и не собираюсь. Но, в некоторых головах причинно-следственная связь срабатывает наоборот: «чтобы расти как управленец нужно срочно тупеть!».
Причем в этой среде наблюдается натуральное соревнование насколько ты отупел:
-«Я не технарь, я в этом не понимаю!»
-«А я еще больше не технарь, я в этом не понимаю еще больше! Ха-ха!»
А ведь раньше эти персонажи были, в общем-то, неплохими техническими специалистами.
Что интересно, там, где причинно-следственная связь между hard-soft skills не перевёрнута с ног на голову, даже среди управленцев высокого уровня много хороших специалистов, отлично разбирающихся в том, чем они управляют. И это не только на уровне IT-директоров, а даже на уровне вице-президентов огромных холдингов.
И дальше происходит следующая вещь: формируется круг общения «близких по духу». Это естественное состояние человека, окружать себя людьми со схожими взглядами, менталитетом и ценностями. Так вот, в этот круг отлично вписываются те, кто был изначально тупым! И не то что бы они делали это специально, нет. Тут наблюдается синдром товарища Даннинга-Крюггера не в виде привычной «дразнилки», а как реальный диагноз. Тупой просто не понимает, что он тупой. Потому что тупой.
И вот тут с приходом ИИ произошла некоторая синергия. Если раньше такой персонаж достаточно быстро отсеивался – набор случайных фраз "на тему" и "google-знания" заканчивались при первой же серьезной "проверке боем", то сейчас при помощи ИИ этими персонажами генерируются "мысли", очень похожие на осмысленные. Почти неотличимые. В которых нельзя четко сказать, что "вот здесь ошибка", но при попытке осознать мысль целиком получается чушь. Такая связка: управленец, сознательно отключивший свои Hard-скилы + "дурак с ИИ" в итоге приводит к деградации всей системы.
Но позвольте, а как же тогда реальное дело, там же это быстро выявится?
А тут всё просто – реальных дел… нет в контролируемых параметрах! Ни одного проекта и контракта за три года? Клиенты разбежались, репутация упала под плинтус? Да кого это интересует, этот вопрос даже не поднимается. Показателем всего становится то, что лучше всего видно и просто измерить – шум. Самая заметная обезьяна в стае – не самая умная, а самая визгливая.
Попытка вернуть контекст в практическое русло тут же называется «токсичностью» и отсутствием Positive thinking. В лучшем случае – «душнотой».
Законный вопрос – но можно же показать, доказать, обосновать что вот это сгенерированное связкой дурак+ИИ – чушь.
Да, можно. Но тут два момента:
1. Эта чушь уже оттранслировалась наружу. «В этой клинике сердечо-сосудистой хирургии нам предложили покупать их циркониевые браслеты» 8-O. Вы второй раз обратитесь в такую клинику?
2. Это занимает чудовищное количество времени и сил. Просто указать на ошибку недостаточно: «жи-ши пиши с буквой И». Будут многочасовые споры с контр-аргументами «А я вот в твиттере писал жЫзнь и всё было отлично! И знакомые одноклассники так писали!». И это при том, что цель – написать научный труд. Вместо сосредоточения на науке приходится объяснять, что совать пальцы в розетку – плохая идея.
Но оно же продолжает жить и двигаться? Да, у любого достаточно крупного тела большая инерция, нет такой точки перелома "было-стало". Изменения не появляются в какой-то момент, а прорастают незаметно.
Так и здесь: Бежало. Шло. Замедлилось. Остановилось. Сдохло.
Зафиксировать следы - первое, что нужно сделать после обнаружения нарушения ваших интеллектуальных прав.
Обычно такая фиксация проводится на веб-сайте виновника владельцем интеллектуальной собственности.
Ниже даны пять способов фиксации нарушения, которые суды принимают:
1. Самозащита. Вы определяете веб-сайт нарушителя, выбираете его страницы или их отдельные блоки, делаете снимки экранов.
Используете сервисы, встроенные в систему вашего компьютера или смартфона. Например, сервис работы со скриншотами в браузере Яндекса.
2. Автофиксация. Вам доступны специальные веб-сервисы для автоматической фиксации данных на сайте нарушителя.
Например, программный комплекс "Вебджастис". Его алгоритм собирает пакет сведений о сайте и условиях его работы, делает снимки экранов. И передает вам документ в формате pdf.
3. Нотариальный осмотр. Когда-то единственный способ закрепления следов. По вашей инициативе нотариус описывает сайт нарушителя и делает нужные скриншоты.
4. Осмотр правоохранителей. Например, следователь может осмотреть сайт в ходе проверки вашего сообщения о преступлении.
Копию протокола осмотра по запросу суда можно будет вовлечь в арбитражный процесс по нарушению интеллектуальных прав.
5. Адвокатский осмотр. С помощью адвокаты вы выбираете веб-ресурс для осмотра. После чего адвокат фиксирует условия осмотра и содержимое страниц сайта, передает вам сделанные скриншоты.
Поговорите с вашим адвокатом. Он поможет выбрать способ с учетом конкретной ситуации.
Если забыл какой-либо из способов фиксации, сообщите в комментариях. Приму с благодарностью.
Книга нарушает интеллектуальные права: виноват издатель или курьер?
Оба держали книгу в руках, пока она шла к покупателю.
Компания-издатель работала над оригинал-макетом, выпускала книгу и предлагала ее к продаже на своем сайте. Фирма-курьер доставила книгу покупателю.
В адрес издательства и курьера пришли претензии с требованием возместить вред за незаконное использование в издании фрагмента чужого произведения.
Претензии от "настоящего" автора фрагмента. Полагаю, именно он был тем самым покупателем книги))
Очевидно, издателю придется несладко: закон считает нарушением ситуацию, когда опубликовано чужое произведение без согласия настоящего автора.
Но как быть с фирмой-курьером?
Если не вылезут всякого рода неожиданности, то курьеру ничего не будет.
На то есть пять причин:
1. Издатель - продавец книги, так как именно он администрирует сайт и предлагает к продаже книгу.
2. Издатель вправе не только продать книгу, но и взять на себя обязанность доставить ее покупателю. В законе это называется продажей товара с условием о его доставке покупателю.
3. Издатель вправе доставить книгу своими силами. Или отправить ее с помощью фирмы-курьера.
Предварительно с такой фирмой заключается агентский договор. В нем описывается схема доставки книги и получения за нее вознаграждения.
Агентский договор не наделяет курьера статусом продавца. Это важно!
4. Покупатель обязан принять книгу, доставленную курьером. Исключение из этого правила может быть, но маловероятно.
Пример исключения - между покупателем и издателем напрямую заключен договор возмездного оказания услуги по доставке книги.
5. Закон описывает ситуации использования произведения. Одна из них - распространение его экземпляра путем продажи.
Фирма-курьер не продавала книгу. Она лишь исполнила свои обязательства перед издательством: отвезла книгу покупателю.
Поговорите со своим адвокатом, если ваш бизнес связан с услугами доставки. Адвокат оценит ваш договор с издательством и проработает риски.
А вам приходилось отбиваться от обладателей интеллектуальной собственности при доставке?
Как не просто получить диплом, а действительно перестроить мышление и построить карьеру? В статье «Куда пойти учиться?» топ-менеджер Альфа-Банка рассказывает, как запускаются и развиваются магистерские программы по продуктовому подходу и HR-аналитике в партнёрстве с ВШЭ.
Обучение построено на решении реальных бизнес-задач, а выпускники выходят готовыми управлять цифровыми продуктами и внедрять ИИ в HR. Уникальная программа, разработанная совместно с ВШЭ, даёт студентам практический опыт, доступ к ведущим HR Tech‑мероприятиям и возможность выстроить нетворк с экспертами рынка.
Как проходит отбор, каким требованиям должен соответствовать кандидат и почему магистратура — это не просто диплом, а полноценный карьерный рывок? Читайте о новом формате обучения и реальных историях роста в статье!
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
В новом выпуске нашего курса по методологии OKR вместе с Сергеем Кузиным, ведущим agile-коучем Авито, разбираем виды ключевых результатов и выясняем, какие цифры и почему важны для разных типов целей.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
