[{"content":"В последнее время появляется множество предупреждений об уязвимостях, связанных с непрямыми атаками через prompt injection. Главный вывод: LLM легковерны, и никто не знает, как сделать их полностью устойчивыми. Следовательно, ни одна ИИ-система не безопасна.\nЭто, конечно, чистая правда, и внимание, которое привлекают такие атаки, можно только приветствовать, но главный вопрос остаётся без ответа: что со всем этим делать?\nПуристы потребовали бы запретить любой внешний ввод, способный привести к prompt injection, но, честно говоря, я бы не был столь категоричен. Множество по-настоящему полезных приложений опирается на внешний ввод, так что, боюсь, нам придётся отступить к последнему рубежу: инженерной дисциплине.\nСуществуют разные схемы, где хитрое взаимодействие нескольких моделей минимизирует их уязвимость к атакам (см., например, статью о CaMeL). Мне, однако, кажется, что мы уделяем недостаточно внимания простой санитизации входных данных.\nМногие такие атаки полагаются на текст, скрытый от человека, но видимый машине. Обнаружить и удалить такой текст относительно тривиально (в программистском смысле), хотя работать придётся уже на уровне контейнера, за пределами самого текста. Эта техника (называемая, кстати, Content Disarm \u0026amp; Reconstruction) существует уже довольно давно. Честно говоря, я удивлён, что она не внедрена повсеместно. Все атаки она не предотвратит, но жизнь неискушённому атакующему заметно усложнит.\nА тем, кто настаивает, что 99% в безопасности — это незачёт, хочу напомнить фундаментальный принцип: стопроцентно защищённых систем не бывает. Роль безопасности в том, чтобы сделать атаку дороже потенциальной выгоды от неё (см. модель Гордона — Лоэба).\nС этой парадигмой в голове мы можем строить надёжные и безопасные ИИ-системы даже из небезопасных по отдельности компонентов.\n","permalink":"https://meshrefine.com/ru/microposts/2025-08-29-documents-sanitization/","summary":"\u003cp\u003eВ последнее время появляется множество предупреждений об уязвимостях, связанных с непрямыми атаками через prompt injection. Главный вывод: LLM легковерны, и никто не знает, как сделать их полностью устойчивыми. Следовательно, ни одна ИИ-система не безопасна.\u003c/p\u003e\n\u003cp\u003eЭто, конечно, чистая правда, и внимание, которое привлекают такие атаки, можно только приветствовать, но главный вопрос остаётся без ответа: что со всем этим делать?\u003c/p\u003e\n\u003cp\u003eПуристы потребовали бы запретить любой внешний ввод, способный привести к prompt injection, но, честно говоря, я бы не был столь категоричен. Множество по-настоящему полезных приложений опирается на внешний ввод, так что, боюсь, нам придётся отступить к последнему рубежу: инженерной дисциплине.\u003c/p\u003e","title":"Сначала почистите документы"},{"content":"Кое-что из того, что нужно знать о свежем релизе GPT-5 и о чём молчат евангелисты:\nGPT-5 не является одной моделью. То, что называют GPT-5 вне контекста API, — это роутер, который отправляет ваш запрос той модели, которая, по его мнению, справится с ним эффективнее всего. Обещание OpenAI дать доступ каждому нужно рассматривать именно в этом свете. Доступ дают к роутеру, и вы не знаете, какую конфигурацию он применяет к вам и удастся ли вам вообще протестировать самую мощную модель. Это неизбежно приводит к совершенно разному опыту у разных пользователей.\nGPT-5 не является PhD. Это довольно способная модель (по крайней мере, одна из), которая блистает в некоторых задачах. Улучшений можно ожидать в:\nспособностях к кодингу (по некоторым вайб-тестам они впечатляют, но по бенчмарку SWE-bench Verified отрыв от Claude Opus 4.1 совсем небольшой); вызове инструментов — а это самое важное для агентных нагрузок; других задачах, где у OpenAI был доступ к немедленной обратной связи. Для многих областей это важные улучшения, но уровня PhD они модели не дают. Галлюцинация про профиль крыла во время демо отлично показывает, что модель по-прежнему усваивает самое распространённое мнение, а не самое актуальное. Это очень трудная проблема, и на пути к AGI она остаётся одним из главных препятствий.\nСнижение числа галлюцинаций — палка о двух концах. С одной стороны, чем меньше модель галлюцинирует, тем лучше: ей можно больше доверять. С другой стороны, чем больше вы доверяете модели, тем выше шанс пропустить настоящие галлюцинации. В реальном мире лучше всех модель, которая не галлюцинирует никогда. Модель, галлюцинирующая в 0.01% случаев, может оказаться опаснее той, что галлюцинирует в 10%.\nМоё личное впечатление пока такое: у неё та же проблема, что и у предыдущих моделей OpenAI, — без аккуратного промптинга она крайне поверхностна. Она выдаёт самый неглубокий анализ, какой только сойдёт ей с рук, и маскирует это очень хорошо структурированными ответами.\n","permalink":"https://meshrefine.com/ru/microposts/2025-08-08-about-gpt-5/","summary":"\u003cp\u003eКое-что из того, что нужно знать о свежем релизе GPT-5 и о чём молчат евангелисты:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eGPT-5 не является одной моделью\u003c/strong\u003e. То, что называют GPT-5 вне контекста API, — это роутер, который отправляет ваш запрос той модели, которая, по его мнению, справится с ним эффективнее всего. Обещание OpenAI дать доступ каждому нужно рассматривать именно в этом свете. Доступ дают к роутеру, и вы не знаете, какую конфигурацию он применяет к вам и удастся ли вам вообще протестировать самую мощную модель. Это неизбежно приводит к совершенно разному опыту у разных пользователей.\u003c/p\u003e","title":"2025-08-08"},{"content":"Google Opal\nGoogle запустила публичное превью своего нового инструмента для графического создания многошаговых ИИ-процессов. Для продакшена он явно не предназначен, зато отлично помогает собирать персональные инструменты (а персональные инструменты стоит делать каждому, правда — сейчас это главный дифференциатор).\nОн работает на платформе Gemini с моделями Gemini (ну разумеется) и, будучи превью-инструментом, пока бесплатен. В будущем он, скорее всего, станет использовать план Gemini, если тот есть у пользователя. Насчёт собственных API-ключей не уверен: это выглядит как инструмент для широкой публики, но посмотрим.\nПока он доступен только в США.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-31-google-opal/","summary":"\u003cp\u003e\u003ca href=\"https://developers.googleblog.com/en/introducing-opal/\"\u003eGoogle Opal\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n  \n  \n  \n    \n    \n    \n    \n    \n    \n    \n  \u003cpicture\u003e\n    \u003csource srcset=\"/ru/microposts/2025-07-31-google-opal/google-opal_hu_df8c6253ecad9107.webp\" type=\"image/webp\" /\u003e\n  \u003cimg class=\"img-fluid\" src=\"/ru/microposts/2025-07-31-google-opal/google-opal.f5b0b4e4310d106f8f86ef27ed3e0029.jpg\" alt=\"Google Opal\" loading=\"lazy\" height=\"723\" width=\"1374\" /\u003e\n\u003c/picture\u003e\n\u003c/p\u003e\n\u003cp\u003eGoogle запустила публичное превью своего нового инструмента для графического создания многошаговых ИИ-процессов. Для продакшена он явно не предназначен, зато отлично помогает собирать персональные инструменты (а персональные инструменты стоит делать каждому, правда — сейчас это главный дифференциатор).\u003c/p\u003e\n\u003cp\u003eОн работает на платформе Gemini с моделями Gemini (ну разумеется) и, будучи превью-инструментом, пока бесплатен. В будущем он, скорее всего, станет использовать план Gemini, если тот есть у пользователя. Насчёт собственных API-ключей не уверен: это выглядит как инструмент для широкой публики, но посмотрим.\u003c/p\u003e","title":"2025-07-31"},{"content":"X гудит о новой модели Horizon Alpha, которая в одиночку бьёт все предыдущие модели на разнообразных вайб-тестах (читай: единороги на велосипедах и тому подобное). У модели контекстное окно 256k — солидная, хотя и не самая впечатляющая цифра.\nСкорее всего, это новая модель OpenAI (GPT-5?): подобный трюк они уже проделывали. Попробовать её можно на openrouter.ai совершенно бесплатно, только помните, что приватные данные ей передавать не стоит — они собираются и используются для улучшения модели.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-31-horizon-alpha-model/","summary":"\u003cp\u003e\u003ca href=\"https://x.com/OpenRouterAI/status/1950713168193282078\"\u003eX гудит\u003c/a\u003e о новой модели Horizon Alpha, которая в одиночку бьёт все предыдущие модели на разнообразных вайб-тестах (читай: единороги на велосипедах и тому подобное). У модели контекстное окно 256k — солидная, хотя и не самая впечатляющая цифра.\u003c/p\u003e\n\u003cp\u003eСкорее всего, это новая модель OpenAI (GPT-5?): подобный трюк они уже проделывали. Попробовать её можно на \u003ca href=\"https://openrouter.ai/openrouter/horizon-alpha\"\u003eopenrouter.ai\u003c/a\u003e совершенно бесплатно, только помните, что приватные данные ей передавать не стоит — они собираются и используются для улучшения модели.\u003c/p\u003e","title":"2025-07-31"},{"content":"Сабагенты Claude Code\nAnthropic добавила в Claude Code возможность создавать и использовать специализированных сабагентов. Сабагенты работают в отдельном контекстном окне, что позволяет выполнять отдельные задачи, не засоряя основной контекст и ограничивая эффект context rot. Созданных сабагентов можно запускать вручную или доверить Claude Code самому решать, когда их использовать.\nЧто может стать хорошим сабагентом? Всё, что должно быть экспертом в своей области, не нуждается в общем контексте с основным агентом, может иметь выделенные инструменты и рассчитано на самодостаточные задачи. Чтобы дать представление о том, что можно превратить в сабагента, вот пара примеров:\nGit-сабагент, на которого можно свалить разнообразные операции с git. Поскольку ему хватает локального состояния git и доступ к глобальному контексту ему ни к чему, он отлично подходит на роль инструмента с собственным контекстным окном. Сабагент — писатель книг (знаю-знаю, но я создаю книгоподобные документы в определённом стиле для самообразования). Вы даёте ему высокоуровневый план, набор материалов и одну-две секции в качестве примеров, а дальше он работает над секцией отдельно от других сабагентов. Второму примеру очень пригодилась бы возможность запускать несколько сабагентов параллельно, но, похоже, я хочу слишком многого.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-28-claude-code-subagent/","summary":"\u003cp\u003e\u003ca href=\"https://docs.anthropic.com/en/docs/claude-code/sub-agents\"\u003eСабагенты Claude Code\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eAnthropic добавила в Claude Code возможность создавать и использовать специализированных сабагентов. Сабагенты работают в отдельном контекстном окне, что позволяет выполнять отдельные задачи, не засоряя основной контекст и ограничивая эффект context rot. Созданных сабагентов можно запускать вручную или доверить Claude Code самому решать, когда их использовать.\u003c/p\u003e\n\u003cp\u003eЧто может стать хорошим сабагентом? Всё, что должно быть экспертом в своей области, не нуждается в общем контексте с основным агентом, может иметь выделенные инструменты и рассчитано на самодостаточные задачи. Чтобы дать представление о том, что можно превратить в сабагента, вот пара примеров:\u003c/p\u003e","title":"2025-07-28"},{"content":"Цитируя Арвинда Нараянана:\nЕсли бы мы сравнивали возможности ИИ с людьми, лишёнными доступа к инструментам вроде интернета, то, вероятно, обнаружили бы, что ИИ уже превосходит человека во многих или даже в большинстве когнитивных задач, которые мы выполняем на работе. Но, конечно, такое сравнение мало чем полезно и мало говорит об экономических эффектах ИИ. Без наших инструментов мы ничто.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-21-quot1/","summary":"\u003cp\u003e\u003ca href=\"https://x.com/random_walker/status/1946180439045018046\"\u003eЦитируя Арвинда Нараянана\u003c/a\u003e:\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eЕсли бы мы сравнивали возможности ИИ с людьми, лишёнными доступа к инструментам вроде интернета, то, вероятно, обнаружили бы, что ИИ уже превосходит человека во многих или даже в большинстве когнитивных задач, которые мы выполняем на работе. Но, конечно, такое сравнение мало чем полезно и мало говорит об экономических эффектах ИИ. \u003cstrong\u003eБез наших инструментов мы ничто\u003c/strong\u003e.\u003c/p\u003e\n\u003c/blockquote\u003e","title":"2025-07-21"},{"content":"Модели понимания видео TwelveLabs теперь доступны в Amazon Bedrock\nAWS добавляет в Amazon Bedrock нативные модели видеоэмбеддингов и понимания видео. Это открывает массу потенциальных сценариев, для которых я раньше тянулся к моделям Gemini. Один из примеров — обучающая система, которая наблюдает, как ученик выполняет задание, и даёт обратную связь на основе учебных материалов.\nВ Bedrock и раньше были workflow для понимания видео, но это были именно workflow, без нативных моделей. Можете представить, как они выглядели: берём видео, режем на кадры, скармливаем кадры VLM, пытаемся сохранить временную согласованность, отчаиваемся, смиряемся с производительностью системы и уезжаем в отпуск.\nТеперь же нативных видеомоделей сразу две:\nTwelveLabs Marengo — для создания видеоэмбеддингов; TwelveLabs Pegasus — для генерации текста на основе видео. Цены зависят от того, есть ли у видео аудиодорожка, но ориентируйтесь на $2.5–$3 за час видео для Marengo и $1.8 за час для Pegasus.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-20-twelvelabs-models-in-amazon-bedrock/","summary":"\u003cp\u003e\u003ca href=\"https://aws.amazon.com/blogs/aws/twelvelabs-video-understanding-models-are-now-available-in-amazon-bedrock/\"\u003eМодели понимания видео TwelveLabs теперь доступны в Amazon Bedrock\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eAWS добавляет в Amazon Bedrock нативные модели видеоэмбеддингов и понимания видео. Это открывает массу потенциальных сценариев, для которых я раньше тянулся к моделям Gemini. Один из примеров — обучающая система, которая наблюдает, как ученик выполняет задание, и даёт обратную связь на основе учебных материалов.\u003c/p\u003e\n\u003cp\u003eВ Bedrock и раньше были workflow для понимания видео, но это были именно workflow, без нативных моделей. Можете представить, как они выглядели: берём видео, режем на кадры, скармливаем кадры VLM, пытаемся сохранить временную согласованность, отчаиваемся, смиряемся с производительностью системы и уезжаем в отпуск.\u003c/p\u003e","title":"2025-07-20"},{"content":"Одна из форм деградации контекста (context rot) — то, что я называю самоподкрепляющейся структурой. Принимая длинный ответ модели, вы сигнализируете, что такая структура приемлема, и она старается генерировать последующие ответы в похожем виде. Для любой длинной творческой работы это может оказаться разрушительным.\nЕдинственная настоящая защита — следить, чтобы история, которую получает модель, таких ответов не содержала. То есть либо пресекать их появление на ранней стадии, либо чинить позже, передавая вместо реальной истории краткое резюме предыдущего разговора.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-20-context-rot-self-reinforcing-structure/","summary":"\u003cp\u003eОдна из форм \u003ca href=\"https://simonwillison.net/2025/Jun/18/context-rot/\"\u003eдеградации контекста (context rot)\u003c/a\u003e — то, что я называю самоподкрепляющейся структурой. Принимая длинный ответ модели, вы сигнализируете, что такая структура приемлема, и она старается генерировать последующие ответы в похожем виде. Для любой длинной творческой работы это может оказаться разрушительным.\u003c/p\u003e\n\u003cp\u003eЕдинственная настоящая защита — следить, чтобы история, которую получает модель, таких ответов не содержала. То есть либо пресекать их появление на ранней стадии, либо чинить позже, передавая вместо реальной истории краткое резюме предыдущего разговора.\u003c/p\u003e","title":"2025-07-20"},{"content":"Представляем агента ChatGPT: мост между исследованием и действием\nOpenAI выпустила агента, который может управлять вашим собственным компьютером. Он использует свои продвинутые способности к рассуждению, чтобы планировать и решать задачи в приложениях вроде Excel и PowerPoint.\nПока Сэм Альтман «чувствует AGI», глядя на работу системы, мне она кажется невероятно неуклюжей. Вместо того чтобы сосредоточиться на нативных инструментах для моделей (MCP — хороший шаг вперёд, пусть и не без проблем), им пытаются эмулировать руки и глаза, чтобы модели могли делать то же, что и мы, только медленно и коряво.\nТак что я считал бы этот тип агентов временным обходным решением, пока мы не разработаем более совершенные механизмы межмашинного взаимодействия. После этого они будут обслуживать всё более длинный хвост легаси-систем, у которых таких машинных интерфейсов уже не появится.\nP.S. Gemini подсказал точку зрения, которую я не учёл: подобные системы могут собирать данные, необходимые для обучения более качественного воплощённого интеллекта, то есть способного действовать в реальном мире. Совершенно справедливое замечание, которое не стоит оставлять без внимания.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-17-chatgpt-agent/","summary":"\u003cp\u003e\u003ca href=\"https://openai.com/index/introducing-chatgpt-agent/\"\u003eПредставляем агента ChatGPT: мост между исследованием и действием\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eOpenAI выпустила агента, который может управлять вашим собственным компьютером. Он использует свои продвинутые способности к рассуждению, чтобы планировать и решать задачи в приложениях вроде Excel и PowerPoint.\u003c/p\u003e\n\u003cp\u003eПока Сэм Альтман «чувствует AGI», глядя на работу системы, мне она кажется невероятно неуклюжей. Вместо того чтобы сосредоточиться на нативных инструментах для моделей (MCP — хороший шаг вперёд, пусть и не без проблем), им пытаются эмулировать руки и глаза, чтобы модели могли делать то же, что и мы, только медленно и коряво.\u003c/p\u003e","title":"2025-07-17"},{"content":"Отчёт Stanford AI Index 2025\nСтэнфорд опубликовал свой ежегодный отчёт. Он довольно важен, потому что отделяет спекуляции от голых цифр. Наряду с очевидными вещами (ИИ становится лучше, дешевле и распространённее — кто бы мог подумать) там есть весьма интересные факты:\nХотя ИИ сейчас используют почти все организации (78% в 2024-м, хотя для большинства это, без сомнения, сводится к сочинению писем чат-ботами), реальные результаты довольно скромны. Рост продуктивности составляет порядка 10% (честно говоря, такой прирост за один год в некотором смысле беспрецедентен), но рост выручки в большинстве отраслей — лишь около 5%. Почему? Потому что, как и с любой технологией общего назначения, полная реализация выгоды потребует полной перестройки организационных структур и процессов. Проблема в том, что никто не знает, как эти новые процессы должны выглядеть, и учиться придётся на собственных ошибках.\nВозможно, уже не новость, но ИИ даёт больше рычага менее опытным сотрудникам. Великий уравнитель современности. Опять же, это значит, что подход к комплектованию команд придётся переосмыслить. Добавлю лишь, что помочь он способен, только если вы хотя бы отдалённо понимаете, что делаете, так что претендентам на начальные позиции стоит хорошо готовиться.\nЧисло инцидентов, связанных с ИИ, продолжает расти. В 2024-м мы видим двукратный рост по сравнению с 2023-м, и это ещё до лихорадочного внедрения агентов и MCP, которое мы наблюдаем в 2025-м. Так что стоит собраться с духом и приготовиться к новым и новым утечкам данных и нарушениям целостности.\nВ отчёте ещё много ценного, но в нём почти 500 страниц, так что искренне рекомендую использовать ИИ, чтобы вытащить оттуда то, что вам интересно.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-17-stanfordhai2025/","summary":"\u003cp\u003e\u003ca href=\"https://hai.stanford.edu/ai-index/2025-ai-index-report\"\u003eОтчёт Stanford AI Index 2025\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eСтэнфорд опубликовал свой ежегодный отчёт. Он довольно важен, потому что отделяет спекуляции от голых цифр. Наряду с очевидными вещами (ИИ становится лучше, дешевле и распространённее — кто бы мог подумать) там есть весьма интересные факты:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003eХотя ИИ сейчас используют почти все организации (78% в 2024-м, хотя для большинства это, без сомнения, сводится к сочинению писем чат-ботами), реальные результаты довольно скромны. Рост продуктивности составляет порядка 10% (честно говоря, такой прирост за один год в некотором смысле беспрецедентен), но рост выручки в большинстве отраслей — лишь около 5%. Почему? Потому что, как и с любой технологией общего назначения, полная реализация выгоды потребует полной перестройки организационных структур и процессов. Проблема в том, что никто не знает, как эти новые процессы должны выглядеть, и учиться придётся на собственных ошибках.\u003c/p\u003e","title":"2025-07-17"},{"content":"Voxtral\nMistral представляет Voxtral — семейство open source моделей для распознавания и понимания речи. Давно пора. Сопоставимой открытой модели мы не видели со времён Whisper от OpenAI, а это было довольно давно.\nМодели выпускаются в размерах 3B и 24B и превосходят Whisper на большинстве бенчмарков. Однако им требуется более мощное железо: самый крупный вариант Whisper — всего 1.5B. Это прямое следствие того, что Voxtral одновременно является обычной языковой моделью. Другое следствие: управлять такими моделями в режиме чистой транскрипции будет сложнее.\nМодели доступны на Hugging Face, а также через API Mistral и их LeChat.\nЧего им пока не хватает, так это поддержки диаризации (распознавания говорящих). Она заявлена в роадмапе, а тем временем для этой цели приходится использовать несколько неуклюжий pyannote-audio.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-17-voxtral/","summary":"\u003cp\u003e\u003ca href=\"https://mistral.ai/news/voxtral\"\u003eVoxtral\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eMistral представляет Voxtral — семейство open source моделей для распознавания и понимания речи. Давно пора. Сопоставимой открытой модели мы не видели со времён Whisper от OpenAI, а это было довольно давно.\u003c/p\u003e\n\u003cp\u003eМодели выпускаются в размерах 3B и 24B и превосходят Whisper на большинстве бенчмарков. Однако им требуется более мощное железо: самый крупный вариант Whisper — всего 1.5B. Это прямое следствие того, что Voxtral одновременно является обычной языковой моделью. Другое следствие: управлять такими моделями в режиме чистой транскрипции будет сложнее.\u003c/p\u003e","title":"2025-07-17"},{"content":"Стратегический интеллект в больших языковых моделях: данные эволюционной теории игр\nСтатья показывает, что разные модели ведут себя совершенно по-разному, когда их помещают в теоретико-игровые условия. Из этого следует, что тестирование и evals играют всё более критичную роль в разработке агентных систем: обновление или смена базовой модели приведёт к непредсказуемым изменениям в поведении агента.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-17-ai-prisoners-dilemma/","summary":"\u003cp\u003e\u003ca href=\"https://arxiv.org/abs/2507.02618\"\u003eСтратегический интеллект в больших языковых моделях: данные эволюционной теории игр\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eСтатья показывает, что разные модели ведут себя совершенно по-разному, когда их помещают в теоретико-игровые условия. Из этого следует, что тестирование и evals играют всё более критичную роль в разработке агентных систем: обновление или смена базовой модели приведёт к непредсказуемым изменениям в поведении агента.\u003c/p\u003e","title":"2025-07-17"},{"content":"Представляем Kiro\nAWS запрыгивает в вагон агентных IDE со своим Kiro. Чтобы отстроиться от вайб-кодинга, успевшего накопить изрядно дурной славы, они делают упор на метод «spec-driven development». Это значит, что агент сначала помогает пользователю составить полный документ с требованиями к фиче, затем анализирует существующую кодовую базу и только после этого приступает к реализации.\nПодход определённо осмысленный, и это шаг вперёд по сравнению со слепым бросанием в бой, каким является вайб-кодинг. То, что спеки обновляются вместе с изменениями кода, делает их ещё ценнее и сводит к минимуму проблему устаревшей документации. Хуки позволяют автоматически выполнять повторяющиеся агентные задачи — например, проверять, что новая фича достаточно покрыта тестами.\nИнтересно наблюдать, как разные инструменты берут на вооружение разные методологии: это позволяет сообществу разработчиков находить и распространять техники, которые действительно работают.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-15-aws-introduces-kiro/","summary":"\u003cp\u003e\u003ca href=\"https://kiro.dev/blog/introducing-kiro/\"\u003eПредставляем Kiro\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eAWS запрыгивает в вагон агентных IDE со своим Kiro. Чтобы отстроиться от вайб-кодинга, успевшего накопить изрядно дурной славы, они делают упор на метод «spec-driven development». Это значит, что агент сначала помогает пользователю составить полный документ с требованиями к фиче, затем анализирует существующую кодовую базу и только после этого приступает к реализации.\u003c/p\u003e\n\u003cp\u003eПодход определённо осмысленный, и это шаг вперёд по сравнению со слепым бросанием в бой, каким является вайб-кодинг. То, что спеки обновляются вместе с изменениями кода, делает их ещё ценнее и сводит к минимуму проблему устаревшей документации. Хуки позволяют автоматически выполнять повторяющиеся агентные задачи — например, проверять, что новая фича достаточно покрыта тестами.\u003c/p\u003e","title":"2025-07-15"},{"content":"TIL: ccusage — приятный инструмент для отслеживания и анализа использования Claude Code.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-15-0d12c26b/","summary":"\u003cp\u003eTIL: \u003ca href=\"https://simonwillison.net/2025/Jul/14/ccusage/\"\u003eccusage\u003c/a\u003e — приятный инструмент для отслеживания и анализа использования Claude Code.\u003c/p\u003e","title":"2025-07-15"},{"content":"Anthropic выпустила 4 новых курса в своей академии:\nClaude Code in Action с практическими советами по использованию CLI-агента. Claude with the Anthropic API — исчерпывающий курс по всем текущим возможностям API, от одиночной генерации текста до агентов. Introduction to Model Context Protocol и Model Context Protocol: Advanced Topics для тех, кому интересен MCP. Каждый курс доступен в видео- и текстовом форматах и даёт сертификат о прохождении.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-14-6fe8db2d/","summary":"\u003cp\u003eAnthropic выпустила 4 новых курса в \u003ca href=\"https://www.anthropic.com/learn\"\u003eсвоей академии\u003c/a\u003e:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003ca href=\"https://anthropic.skilljar.com/claude-code-in-action\"\u003eClaude Code in Action\u003c/a\u003e с практическими советами по использованию CLI-агента.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://anthropic.skilljar.com/claude-with-the-anthropic-api\"\u003eClaude with the Anthropic API\u003c/a\u003e — исчерпывающий курс по всем текущим возможностям API, от одиночной генерации текста до агентов.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://anthropic.skilljar.com/introduction-to-model-context-protocol\"\u003eIntroduction to Model Context Protocol\u003c/a\u003e и \u003ca href=\"https://anthropic.skilljar.com/model-context-protocol-advanced-topics\"\u003eModel Context Protocol: Advanced Topics\u003c/a\u003e для тех, кому интересен MCP.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eКаждый курс доступен в видео- и текстовом форматах и даёт сертификат о прохождении.\u003c/p\u003e","title":"2025-07-14"},{"content":"TIL: DBML — Database Markup Language\nЯзык разметки для описания схемы БД, который может пригодиться для передачи её ИИ-инструментам.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-14-22cb7f0e/","summary":"\u003cp\u003eTIL: \u003ca href=\"https://dbml.dbdiagram.io/home/\"\u003eDBML — Database Markup Language\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eЯзык разметки для описания схемы БД, который может пригодиться для передачи её ИИ-инструментам.\u003c/p\u003e","title":"2025-07-14"},{"content":"Измерение влияния ИИ начала 2025 года на продуктивность опытных open source разработчиков\nВажное и добротно проведённое исследование, показывающее, что современные ИИ-инструменты для кодинга вредят разработчикам, которые:\nобладают солидным опытом; работают с крупными кодовыми базами; знают кодовую базу как свои пять пальцев. Интересно, что, хотя в среднем они закрывали задачи на 19% медленнее, по их собственным ощущениям ИИ-агенты давали ускорение примерно на 20%!\nАвторы отмечают, что с новыми поколениями агентов этот эффект может ослабевать, и, что самое главное, уже сейчас существует широкий круг задач, на которых виден прирост производительности.\nТак что если вы не знаете кодовую базу вдоль и поперёк, имеете ограниченный опыт с используемыми технологиями или разрабатываете проект с нуля, ИИ-агент, скорее всего, вам поможет.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-11-20dc3714/","summary":"\u003cp\u003e\u003ca href=\"https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/\"\u003eИзмерение влияния ИИ начала 2025 года на продуктивность опытных open source разработчиков\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eВажное и добротно проведённое исследование, показывающее, что современные ИИ-инструменты для кодинга вредят разработчикам, которые:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eобладают солидным опытом;\u003c/li\u003e\n\u003cli\u003eработают с крупными кодовыми базами;\u003c/li\u003e\n\u003cli\u003eзнают кодовую базу как свои пять пальцев.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eИнтересно, что, хотя в среднем они закрывали задачи на 19% медленнее, по их собственным ощущениям ИИ-агенты давали ускорение примерно на 20%!\u003c/p\u003e\n\u003cp\u003eАвторы отмечают, что с новыми поколениями агентов этот эффект может ослабевать, и, что самое главное, уже сейчас существует широкий круг задач, на которых виден прирост производительности.\u003c/p\u003e","title":"Парадокс продуктивности ИИ"},{"content":"Очень важно понимать: ИИ-модели недетерминированы, и сделать их детерминированными без жёсткого ограничения среды выполнения невозможно. Фиксация сидов не помогает. Нулевая температура не помогает. Любая крошечная ошибка округления с плавающей точкой может в итоге привести к кардинально другим результатам.\nСложные модели по своей сути являются хаотическими системами, и обращаться с ними следует соответственно.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-09-259fafd6/","summary":"\u003cp\u003eОчень важно понимать: ИИ-модели недетерминированы, и сделать их детерминированными без жёсткого ограничения среды выполнения невозможно. Фиксация сидов не помогает. Нулевая температура не помогает. Любая крошечная ошибка округления с плавающей точкой может в итоге привести к кардинально другим результатам.\u003c/p\u003e\n\u003cp\u003eСложные модели по своей сути являются хаотическими системами, и обращаться с ними следует соответственно.\u003c/p\u003e","title":"2025-07-09"},{"content":"ИИ-агенты для кодинга — просто ещё один инструмент в арсенале хорошего разработчика. Он начинает с каменной глыбы и использует агентов как метафорическую кувалду, чтобы придать ей задуманную грубую форму. Затем он берётся за инструменты ИИ-ассистированного кодинга вроде GitHub Copilot, чтобы работать точнее, — это уже молоток поменьше. И наконец, самым маленьким резцом он вручную вытачивает тончайшие детали.\nЗабавно слышать, что искусство программирования умерло, потому что мы больше не обтёсываем глыбы одними лишь маленькими резцами.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-07-ae052c28/","summary":"\u003cp\u003eИИ-агенты для кодинга — просто ещё один инструмент в арсенале хорошего разработчика. Он начинает с каменной глыбы и использует агентов как метафорическую кувалду, чтобы придать ей задуманную грубую форму. Затем он берётся за инструменты ИИ-ассистированного кодинга вроде GitHub Copilot, чтобы работать точнее, — это уже молоток поменьше. И наконец, самым маленьким резцом он вручную вытачивает тончайшие детали.\u003c/p\u003e\n\u003cp\u003eЗабавно слышать, что искусство программирования умерло, потому что мы больше не обтёсываем глыбы одними лишь маленькими резцами.\u003c/p\u003e","title":"2025-07-07"},{"content":"Забавная штука: Gemini Deep Research программно отучен заканчивать работу раньше времени. Я обнаружил это, когда попытался с его помощью извлечь информацию из неструктурированного текста и заполнить шаблон. Хотя это исследовательский инструмент, у него есть всё необходимое для такой задачи: доступ к Google Docs, умение создавать длинные документы и дотошный агентный процесс. Разумеется, если мы хотим просто переструктурировать документ, важно, чтобы модель вообще не пользовалась поиском в интернете.\nАгент справился с работой вполне хорошо и быстро. Однако когда он уже собирался закончить, программный оркестратор несколько раз подстегнул его командой «продолжай исследование» — и угадайте что? Он полез в интернет искать недостающую информацию.\nМораль: с такими системами можно проявлять изобретательность, но будьте готовы к тому, что обвязка вставит вам палки в колёса.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-05-55a52a46/","summary":"\u003cp\u003eЗабавная штука: Gemini Deep Research программно отучен заканчивать работу раньше времени. Я обнаружил это, когда попытался с его помощью извлечь информацию из неструктурированного текста и заполнить шаблон. Хотя это исследовательский инструмент, у него есть всё необходимое для такой задачи: доступ к Google Docs, умение создавать длинные документы и дотошный агентный процесс. Разумеется, если мы хотим просто переструктурировать документ, важно, чтобы модель вообще не пользовалась поиском в интернете.\u003c/p\u003e\n\u003cp\u003eАгент справился с работой вполне хорошо и быстро. Однако когда он уже собирался закончить, программный оркестратор несколько раз подстегнул его командой «продолжай исследование» — и угадайте что? Он полез в интернет искать недостающую информацию.\u003c/p\u003e","title":"2025-07-05"},{"content":"После нескольких недель, в течение которых Марки бил тревогу, Сенат ночью исключил мораторий на регулирование ИИ из законопроекта о бюджетной сверке подавляющим большинством 99–1\nИтак, моратория на регулирование ИИ на уровне штатов не будет. Тем, кто разрабатывает ИИ-системы, пора готовиться изучать и внедрять меры комплаенса для 50 разных штатов. Горе нам.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-02-72f7e44e/","summary":"\u003cp\u003e\u003ca href=\"https://www.markey.senate.gov/news/press-releases/after-weeks-of-markey-raising-the-alarm-senate-strikes-ai-moratorium-from-budget-reconciliation-bill-overnight-in-overwhelming-99-1-vote\"\u003eПосле нескольких недель, в течение которых Марки бил тревогу, Сенат ночью исключил мораторий на регулирование ИИ из законопроекта о бюджетной сверке подавляющим большинством 99–1\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eИтак, моратория на регулирование ИИ на уровне штатов не будет. Тем, кто разрабатывает ИИ-системы, пора готовиться изучать и внедрять меры комплаенса для 50 разных штатов. Горе нам.\u003c/p\u003e","title":"2025-07-02"},{"content":"Cloudflare только что изменила то, как ИИ-краулеры сканируют весь интернет; подход на основе разрешений открывает дорогу новой бизнес-модели\nCloudflare делает большой шаг к монетизации данных для обучения ИИ. Теперь все новые данные, размещённые на Cloudflare, по умолчанию недоступны для ИИ-краулеров. Появилась и новая опция: страница может возвращать код HTTP 402 («Payment required») и взимать плату за доступ. Разумеется, посредником будет выступать Cloudflare, что даёт ей значительный контроль и финансовую власть.\nБолее того, это может открыть эпоху «тёмного краулинга», которая неизбежно выльется в игры в кошки-мышки с детектированием краулеров.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-02-c80a82b1/","summary":"\u003cp\u003e\u003ca href=\"https://www.cloudflare.com/ru-ru/press-releases/2025/cloudflare-just-changed-how-ai-crawlers-scrape-the-internet-at-large/\"\u003eCloudflare только что изменила то, как ИИ-краулеры сканируют весь интернет; подход на основе разрешений открывает дорогу новой бизнес-модели\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eCloudflare делает большой шаг к монетизации данных для обучения ИИ. Теперь все новые данные, размещённые на Cloudflare, по умолчанию недоступны для ИИ-краулеров. Появилась и новая опция: страница может возвращать код \u003ca href=\"https://blog.cloudflare.com/introducing-pay-per-crawl/\"\u003eHTTP 402 («Payment required»)\u003c/a\u003e и взимать плату за доступ. Разумеется, посредником будет выступать Cloudflare, что даёт ей значительный контроль и финансовую власть.\u003c/p\u003e\n\u003cp\u003eБолее того, это может открыть эпоху «тёмного краулинга», которая неизбежно выльется в игры в кошки-мышки с детектированием краулеров.\u003c/p\u003e","title":"2025-07-02"},{"content":" Глава 1.1: Введение. От теории к практике 1. Ключевые идеи из курса (Взгляд теоретика) 2. Что это значит для нас (Взгляд практика из сервисной компании) 3. Сравнительная таблица целей 4. Наш основной процесс Глава 2.1: Что такое Product Discovery? Определение для практиков 1. Ключевые идеи из курса (Академическое определение) 2. Что это такое для нас (Рабочее определение) 3. Сравнение фокусов при оценке рисков 4. Диаграмма трансформации запроса Глава 2.2: Зачем на самом деле нужно Product Discovery? 1. Ключевые идеи из курса (Аргументы для продуктовой компании) 2. Что это дает нам (Аргументы для сервисной компании) 3. Сравнение: \u0026ldquo;До\u0026rdquo; и \u0026ldquo;После\u0026rdquo; внедрения Discovery 4. Диаграмма ценности: два пути пресейла Глава 2.3: Процесс Product Discovery. Теория и практика 1. Ключевые идеи из курса (Классический процесс) 2. Как этот процесс выглядит у нас (Линейный пресейл-процесс) 3. Сравнение процессов в виде таблицы 4. Наша воронка пресейла Глава 3.1: Команда для Product Discovery. Роли в сервисной компании 1. Ключевые идеи из курса (Классическая продуктовая команда) 2. Наша команда (Дуэт Продаж и Технологий) 3. Роли и обязанности в нашей команде 4. Диаграмма взаимодействия Глава 4.1: Понимание потребностей. Кого мы на самом деле слушаем? 1. Ключевые идеи из курса (Фокус на конечном пользователе) 2. Наша реальность (Фокус на бизнес-заказчике) 3. Сравнение объектов исследования 4. Диаграмма смещения фокуса Глава 4.2: User Persona. Адаптируем для работы с клиентом 1. Ключевые идеи из курса (Портрет конечного пользователя) 2. Наша версия — «Портрет Ключевого Стейкхолдера» 3. Шаблон «Портрета Ключевого Стейкхолдера» 4. Диаграмма влияния стейкхолдеров Глава 4.3: Empathy Map. Структурируем информацию от клиента 1. Ключевые идеи из курса (Сопереживание пользователю) 2. Наша версия — «Карта Воркшопа» 3. Шаблон «Карты Воркшопа» 4. Диаграмма трансформации информации Глава 4.4: Интервью с клиентом. Как задавать правильные вопросы 1. Ключевые идеи из курса (Вопросы для пользователей) 2. Наш подход — «Технический воркшоп-интервью» 3. Наш чек-лист вопросов для воркшопа с клиентом 4. Диаграмма \u0026ldquo;Воронка вопросов\u0026rdquo; Глава 4.5: Дополнительные техники. Где еще брать информацию? 1. Ключевые идеи из курса (Анализ данных и конкурентов) 2. Наши источники информации 3. Таблица адаптации техник 4. Диаграмма \u0026ldquo;Наши источники истины\u0026rdquo; Глава 5.1: Определение проблемы. Формулируем скоуп проекта 1. Ключевые идеи из курса (Поиск и формулировка проблемы) 2. Наша цель — определить скоуп, а не «проблему» 3. Шаблон для определения скоупа (Scope Statement) 4. Диаграмма \u0026ldquo;Сужение фокуса\u0026rdquo; Глава 5.2: Приоритизация. Как договориться с клиентом о MVP 1. Ключевые идеи из курса (Фреймворки для бэклога) 2. Наша цель — приоритизация для продажи, а не для разработки 3. Адаптация фреймворка MoSCoW для переговоров 4. Диаграмма \u0026ldquo;Процесс согласования MVP\u0026rdquo; Глава 6.1: Поиск решений. От креатива к архитектурному эскизу 1. Ключевые идеи из курса (Время для креатива) 2. Наша цель — быстро прийти к одному рабочему варианту 3. Сравнение подходов к поиску решения 4. Диаграмма \u0026ldquo;От проблемы к оценке\u0026rdquo; Глава 6.2: Мозговой штурм. Проектируем решение вместе с клиентом 1. Ключевые идеи из курса (Классический мозговой штурм) 2. Наш формат — «Архитектурный воркшоп» 3. Правила нашего «Архитектурного воркшопа» 4. Диаграмма \u0026ldquo;Процесс воркшопа\u0026rdquo; Глава 6.3: Mind Map. Декомпозируем решение для оценки 1. Ключевые идеи из курса (Карта для идей) 2. Наш формат — «Карта работ» (Work Breakdown Structure) 3. Пример нашей «Карты работ» 4. От Карты работ к итоговой оценке Глава 6.4: Working Backward. Описываем цели и видение проекта 1. Ключевые идеи из курса (Техника Amazon) 2. Наша адаптация — «Описание будущего решения» в ТКП 3. Шаблон «Описания будущего решения» 4. Диаграмма \u0026ldquo;От видения к реализации\u0026rdquo; Глава 6.5: Role-Storming. Проверяем наше предложение на прочность 1. Ключевые идеи из курса (Штурм в роли пользователя) 2. Наша адаптация — «Предзащита коммерческого предложения» 3. Сценарий «Предзащиты ТКП» 4. Диаграмма \u0026ldquo;Цикл усиления предложения\u0026rdquo; Глава 6.6: Техника \u0026ldquo;Что, если?\u0026rdquo;. Выявляем и отрабатываем риски 1. Ключевые идеи из курса (Генерация идей через ограничения) 2. Наша адаптация — «Анализ рисков» 3. Наш чек-лист вопросов \u0026ldquo;Что, если?\u0026rdquo; для анализа рисков 4. Диаграмма \u0026ldquo;От риска к плану\u0026rdquo; Глава 7.1: Валидация решения. Защищаем коммерческое предложение 1. Ключевые идеи из курса (Всесторонняя проверка) 2. Наша валидация — это успешная защита ТКП 3. Чек-лист для успешной защиты (валидации) ТКП 4. Диаграмма \u0026ldquo;Процесс валидации ТКП\u0026rdquo; Глава 8.1: Прототипирование. Визуализируем идею для клиента 1. Ключевые идеи из курса (Прототип для проверки гипотез) 2. Наша цель — прототип как инструмент продажи 3. Сравнение целей прототипирования 4. Диаграмма \u0026ldquo;Путь прототипа к контракту\u0026rdquo; Глава 8.2: Зачем использовать прототипирование? Наши причины 1. Ключевые идеи из курса (Причины для продуктовой компании) 2. Наши причины (Прототип как инструмент продажи) 3. Сравнение выгод от прототипирования 4. Диаграмма \u0026ldquo;Ценность прототипа в пресейле\u0026rdquo; Глава 8.3: Типы прототипов. Выбираем подходящий для продажи 1. Ключевые идеи из курса (Классификация прототипов) 2. Наши типы прототипов для пресейла 3. Таблица: Какой прототип для какой задачи? 4. Диаграмма \u0026ldquo;Выбор прототипа для пресейла\u0026rdquo; Глава 8.4: Техники прототипирования. Как быстро сделать наглядный прототип 1. Ключевые идеи из курса (Разнообразие техник) 2. Наши техники для пресейла 3. Таблица: Техники и их применение 4. Диаграмма \u0026ldquo;Процесс создания прототипа для пресейла\u0026rdquo; Глава 8.5: Подготовка вопросов. Что спрашивать у клиента при демонстрации прототипа 1. Ключевые идеи из курса (Вопросы для пользовательского тестирования) 2. Наш подход — «Вопросы для согласования» 3. Чек-лист вопросов для демонстрации прототипа клиенту 4. Диаграмма \u0026ldquo;Цикл обратной связи при демонстрации прототипа\u0026rdquo; Глава 8.6: Процесс демонстрации прототипа. От показа к согласованию 1. Ключевые идеи из курса (Этапы тестирования) 2. Наш процесс — «Демонстрация и согласование» 3. Чек-лист для проведения демонстрации прототипа 4. Диаграмма \u0026ldquo;Итеративный процесс согласования\u0026rdquo; Глава 9.1: Получение согласия и выравнивание. Наша цель — подписанный контракт 1. Ключевые идеи из курса (Внутреннее согласование) 2. Наша цель — согласие клиента и контракт 3. Ключевые документы для получения «Buy-in» от клиента 4. Диаграмма \u0026ldquo;От Discovery к контракту\u0026rdquo; Глава 10.1: Непрерывное Discovery. Развитие отношений и допродажи 1. Ключевые идеи из курса (Постоянное улучшение продукта) 2. Наша адаптация — «Развитие проекта и клиента» 3. Применение принципов Discovery после контракта 4. Диаграмма \u0026ldquo;Цикл развития клиента\u0026rdquo; Глава 11.1: Заключение. Discovery как инструмент успеха 1. Ключевые идеи из курса (Благодарность и пожелания) 2. Наше заключение (Главный вывод для R\u0026amp;D/Presale) 3. Ключевые принципы нашего Discovery (Краткое резюме) 4. Призыв к действию Глава 1.1: Введение. От теории к практике 1. Ключевые идеи из курса (Взгляд теоретика) Автор курса представляет Product Discovery как линейный, пошаговый процесс для создания успешных продуктов. Основные этапы, которые он выделяет:\nОпределение процесса: Что такое Discovery и зачем он нужен. Команда: Кто должен участвовать в процессе. Понимание пользователя: Создание портретов (User Persona), карт эмпатии (Empathy Map), проведение интервью для выявления нужд. Определение проблемы: Анализ и приоритизация найденных проблем. Поиск решений: Использование креативных техник для генерации идей (мозговой штурм, Working-Backward и т.д.). Валидация и прототипирование: Создание прототипов и их тестирование с пользователями. Согласование: Презентация решения стейкхолдерам. Этот подход идеально подходит для продуктовых компаний, которые создают и развивают собственные продукты для массового рынка.\n2. Что это значит для нас (Взгляд практика из сервисной компании) Для нас, как для сервисной компании, цели и акценты в этом процессе кардинально меняются. Мы не ищем \u0026ldquo;продукт-мечты\u0026rdquo; для миллионов. Наша задача — решить конкретную бизнес-проблему конкретного клиента с выгодой для нашей компании.\nProduct Discovery для нас — это в первую очередь инструмент пресейла и управления рисками.\nНаши ключевые цели:\nПродать экспертизу: Мы показываем клиенту, что не просто пишем код, а вникаем в его бизнес и предлагаем оптимальное решение. Это отличает нас от бодишопов. Превратить хаос в порядок: Берем невнятный запрос (\u0026ldquo;хотим что-то с нейросетями\u0026rdquo;) и превращаем его в четко очерченный, понятный и оценимый проект. Снизить риски: Заранее выявляем технические и бизнес-проблемы, чтобы не столкнуться с ними в середине проекта. Это защищает и нас, и клиента от провала. Обосновать цену: Результаты Discovery — это прямое доказательство, почему проект стоит именно столько. Поэтому, проходя этот курс, мысленно заменяйте слово \u0026ldquo;продукт\u0026rdquo; на слово \u0026ldquo;проект\u0026rdquo;, а \u0026ldquo;пользователь\u0026rdquo; на \u0026ldquo;клиент\u0026rdquo;.\n3. Сравнительная таблица целей Критерий Классическое Product Discovery (для стартапа) Product Discovery (для сервисной компании) Основная цель Найти product-market fit, создать успешный продукт Продать проект, построить долгосрочные отношения с клиентом Конечный результат MVP, который можно вывести на рынок Коммерческое предложение, Statement of Work (SOW), план проекта Ключевой риск Сделать никому не нужный продукт Неправильно оценить сложность, уйти в минус по проекту Метрика успеха Рост пользовательской базы, доход с продукта Подписанный контракт, прибыльность проекта, довольный клиент 4. Наш основной процесс В нашем случае процесс выглядит гораздо прямолинейнее и нацелен на конкретный коммерческий результат.\nflowchart TD A[Нечеткий запрос от клиента] --\u0026gt; B{Процесс Discovery: воркшопы, анализ, эскиз архитектуры}; B --\u0026gt; C[Четко очерченный скоуп работ]; C --\u0026gt; D[Подготовка документов: КП, SOW]; D --\u0026gt; E[Подписанный контракт]; Этот файл — отправная точка. В следующих главах мы будем так же разбирать каждый инструмент и адаптировать его под наши задачи.\nГлава 2.1: Что такое Product Discovery? Определение для практиков 1. Ключевые идеи из курса (Академическое определение) Автор определяет Product Discovery как процесс, состоящий из двух ключевых частей:\nПонять проблемы и нужды пользователей. Проверить (валидировать) идеи решений для этих проблем до начала полноценной разработки. Основная цель, согласно курсу, — убедиться, что создаваемый продукт будет соответствовать ожиданиям рынка и решать реальные проблемы наилучшим образом. Это классическое, ориентированное на продукт определение.\n2. Что это такое для нас (Рабочее определение) В контексте сервисной компании это определение слишком абстрактно. Мы не \u0026ldquo;ищем проблемы на рынке\u0026rdquo;, мы работаем с конкретным запросом от конкретного клиента.\nДля нас, Product Discovery — это структурированный консалтинговый процесс (часто платный), который превращает бизнес-идею клиента в готовый к реализации проект.\nЭто не столько \u0026ldquo;поиск истины\u0026rdquo;, сколько процесс согласования видения, ожиданий и ограничений между нашей командой и командой клиента. Его главная задача — ответить не на абстрактный вопрос \u0026ldquo;что делать?\u0026rdquo;, а на предельно конкретный: \u0026ldquo;Что именно мы будем делать в рамках этого проекта за эти деньги и в эти сроки?\u0026rdquo;.\nDiscovery — это наш способ перевести диалог с клиентом из плоскости \u0026ldquo;пофантазируем\u0026rdquo; в плоскость \u0026ldquo;посчитаем и спланируем\u0026rdquo;.\n3. Сравнение фокусов при оценке рисков Классическая теория говорит о проверке трех типов рисков. Мы проверяем те же риски, но под другим углом.\nТип риска Классический подход (вопрос к себе) Наш подход (вопрос к клиенту и к себе) Ценность (Value) Будут ли этим пользоваться? Решает ли это проблему? Принесет ли это измеримую пользу бизнесу клиента? Готов ли он за это платить? Исполнимость (Feasibility) Сможем ли мы это построить? Сможем ли мы это построить на инфраструктуре клиента и в рамках его бюджета? Жизнеспособность (Viability) Вписывается ли это в нашу бизнес-модель? Является ли этот проект прибыльным для нас? Соответствует ли он нашей экспертизе? 4. Диаграмма трансформации запроса Эта диаграмма иллюстрирует, как Discovery превращает абстракцию в конкретику.\ngraph TD subgraph \u0026#34;Вход\u0026#34; A[\u0026#34;Идея или проблема клиента\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;(e.g., \u0026#39;Хотим внедрить GenAI для аналитики\u0026#39;)\u0026lt;/i\u0026gt;\u0026#34;] end subgraph \u0026#34;Выход\u0026#34; D[\u0026#34;Технико-коммерческое предложение\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;(Конкретный скоуп, архитектура, смета, план)\u0026lt;/i\u0026gt;\u0026#34;] end A --\u0026gt; B{\u0026lt;strong\u0026gt;Процесс Discovery\u0026lt;/strong\u0026gt;}; B --\u0026gt; C[\u0026#34;-Анализ требований\u0026lt;br\u0026gt;-Технические воркшопы\u0026lt;br\u0026gt;-Эскиз архитектуры\u0026lt;br\u0026gt;- Определение скоупа MVP\u0026#34;]; C --\u0026gt; D; Таким образом, для нас Product Discovery — это не исследование, а проектирование будущего контракта.\nГлава 2.2: Зачем на самом деле нужно Product Discovery? 1. Ключевые идеи из курса (Аргументы для продуктовой компании) Автор приводит несколько причин, почему необходимо проводить Product Discovery:\nПолучить раннюю обратную связь: Проверить соответствие продукта рынку (product-market fit) без больших вложений в разработку. Сэкономить ресурсы: Инвестиции в Discovery в десятки раз дешевле, чем исправление ошибок после релиза или создание никому не нужного продукта. Быть гибким (Agile): Возможность быстро изменить продукт или даже целевой рынок на основе полученных данных. Лучше понимать и доносить ценность: Глубокое понимание нужд пользователя помогает маркетингу лучше продавать продукт и обосновывать его цену. Все эти аргументы сводятся к одному: снизить риск провала продукта на рынке.\n2. Что это дает нам (Аргументы для сервисной компании) Для нас причины еще более прагматичные и касаются не гипотетического рыночного успеха, а выживания и прибыльности каждого отдельного проекта.\nДля нас Discovery — это не про то, чтобы сделать \u0026ldquo;правильный\u0026rdquo; продукт, а про то, чтобы продать \u0026ldquo;правильный\u0026rdquo; проект и не уйти в минус.\nВот наши главные причины:\nЭто инструмент продаж. Discovery — это по сути платная (или как минимум очень ценная) консалтинговая услуга. Она позволяет нам продавать не \u0026ldquo;часы разработчиков\u0026rdquo; по низкой ставке, а дорогостоящую экспертизу по решению бизнес-проблем. Результаты Discovery (схемы, аналитика, прототипы) — это прямое обоснование цены будущего контракта.\nЭто инструмент управления рисками. Мы заранее выявляем подводные камни: техническую несовместимость, нереалистичные ожидания клиента, скрытую сложность. Это наша защита от подписания убыточного или невыполнимого контракта. Лучше отказаться от проекта на старте, чем потерять на нем деньги и репутацию.\nЭто инструмент фиксации скоупа. Главный враг любого аутсорс-проекта — это \u0026ldquo;scope creep\u0026rdquo; (раздувание границ). Discovery позволяет нам вместе с клиентом четко определить и задокументировать, что входит в проект, а что — нет. Этот документ (SOW) — наша главная защита в будущем.\nЭто инструмент построения доверия. Проводя Discovery, мы из простого \u0026ldquo;исполнителя\u0026rdquo; превращаемся в \u0026ldquo;партнера-консультанта\u0026rdquo;. Клиент видит, что мы вникаем в его проблемы, и начинает доверять нашей экспертизе. Это основа для долгосрочных отношений и будущих допродаж.\n3. Сравнение: \u0026ldquo;До\u0026rdquo; и \u0026ldquo;После\u0026rdquo; внедрения Discovery Без Discovery (типичные проблемы) С Discovery (наши преимущества) Непонятный скоуп, постоянные «а давайте еще вот это» Четкие границы проекта, зафиксированные в SOW Оценка проекта «пальцем в небо», высокий риск убытков Обоснованная смета, предсказуемая прибыльность Конфликты с клиентом из-за разных ожиданий Единое видение и согласованные ожидания Продажа «часов разработчиков», конкуренция по цене Продажа «решения проблемы», конкуренция по экспертизе 4. Диаграмма ценности: два пути пресейла graph TD subgraph \u0026#34;Путь 1: Пресейл без Discovery\u0026#34; A[Запрос клиента] --\u0026gt; B[\u0026#34;Быстрая оценка\u0026lt;br\u0026gt;(на глазок)\u0026#34;] --\u0026gt; C[\u0026#34;Подписание контракта\u0026lt;br\u0026gt;с размытым скоупом\u0026#34;] --\u0026gt; D[\u0026#34;\u0026lt;strong\u0026gt;Высокий риск\u0026lt;br\u0026gt;конфликтов и убытков\u0026lt;/strong\u0026gt;\u0026#34;] end subgraph \u0026#34;Путь 2: Пресейл с Discovery\u0026#34; E[Запрос клиента] --\u0026gt; F{\u0026#34;`Процесс Discovery`\u0026#34;} --\u0026gt; G[\u0026#34;Четкий скоуп\u0026lt;br\u0026gt;и обоснованная оценка\u0026#34;] --\u0026gt; H[\u0026#34;\u0026lt;strong\u0026gt;Подписание выгодного\u0026lt;br\u0026gt;и понятного контракта\u0026lt;/strong\u0026gt;\u0026#34;] end Глава 2.3: Процесс Product Discovery. Теория и практика 1. Ключевые идеи из курса (Классический процесс) Автор курса предлагает простой 8-шаговый процесс, который ведет от сбора команды до поставки решения:\nСобрать команду для Discovery. Понять нужды пользователя. Определить проблему или потребность. Найти возможные решения. Проверить (валидировать) решения. Создать прототип приоритетного решения. Презентовать решение стейкхолдерам для получения поддержки. Поставить решение (начать разработку). Этот процесс логичен, но он описывает идеальный мир, где у команды есть время и ресурсы на последовательное выполнение всех шагов.\n2. Как этот процесс выглядит у нас (Линейный пресейл-процесс) В наших реалиях процесс сжат, нацелен на коммерческий результат и имеет четкие временные рамки. Некоторые шаги курса мы объединяем, а некоторые — добавляем от себя. Наш процесс — это скорее воронка продаж, а не исследовательский проект.\nВот наши реальные этапы:\nКвалификация (1-2 дня): Первый контакт с клиентом (звонок, встреча). Наша цель — быстро понять, есть ли у клиента реальная потребность и бюджет, и стоит ли нам вообще вкладывать время в этот пресейл. Это наш фильтр.\nСбор данных и воркшопы (1-2 недели): Серия технических встреч с командой клиента. Здесь мы объединяем шаги 2, 3 и 4 из курса: слушаем, задаем вопросы, вытаскиваем требования, ограничения, бизнес-цели и вместе накидываем первые идеи решений.\nВнутренняя проработка и оценка (1 неделя): Наша команда (Presale/R\u0026amp;D инженер, архитектор) анализирует собранную информацию. Здесь мы делаем то, что в курсе называется \u0026ldquo;валидация\u0026rdquo; и \u0026ldquo;прототипирование\u0026rdquo;, но на уровне концепции: рисуем верхнеуровневую архитектуру, выбираем стек, определяем границы (скоуп) MVP и делаем предварительную оценку трудозатрат.\nПодготовка ТКП (3-5 дней): Самый важный этап, которого нет в курсе. Мы упаковываем результаты нашей работы в пакет документов: Коммерческое предложение (КП), Описание работ (SOW), предварительный план проекта.\nЗащита и согласование: Презентуем наше предложение клиенту. Это аналог шага 7 из курса. Наша цель — не просто получить \u0026ldquo;buy-in\u0026rdquo; (согласие), а получить подпись на контракте.\n3. Сравнение процессов в виде таблицы Шаг в курсе (теория) Наш этап (практика) Наш главный результат на этапе 1. Собрать команду - (команда у нас постоянная) - 2. Понять нужды\n3. Определить проблему\n4. Найти решения 1. Квалификация\n2. Сбор данных и воркшопы Понимание бизнес-задачи, ограничений и требований клиента. 5. Валидировать решения\n6. Создать прототип 3. Внутренняя проработка и оценка Эскиз архитектуры, определенный скоуп MVP, оценка трудозатрат. 7. Презентовать решение 5. Защита и согласование Согласованное с клиентом коммерческое предложение. - (отсутствует) 4. Подготовка ТКП Готовый пакет документов для подписания. 8. Поставить решение - (это уже работа команды разработки) Подписанный контракт. 4. Наша воронка пресейла Эта диаграмма наглядно показывает, как сужается количество потенциальных проектов на каждом этапе нашего процесса.\n------------------------------------------------------------+ | | | Входящий запрос от клиента (10) | | | +------------------------------------------------------------+ \\ / +--------------------------------------------------------+ | | | Квалификация (прошли первичный фильтр) (8) | | | +--------------------------------------------------------+ \\ / +----------------------------------------------------+ | | | Проведены технические воркшопы (5) | | | +----------------------------------------------------+ \\ / +------------------------------------------------+ | | | Подготовлено коммерческое предложение (3) | | | +------------------------------------------------+ \\ / +------------------------------------------+ | | | Подписан контракт (1) | | | +------------------------------------------+ Глава 3.1: Команда для Product Discovery. Роли в сервисной компании 1. Ключевые идеи из курса (Классическая продуктовая команда) Автор курса предлагает делить команду на две группы:\nОсновная команда (Core Team): Это те, кто непосредственно ведет процесс Discovery. Включает в себя: Продакт-менеджера (лидер процесса) UX-дизайнера и исследователя Технического лида Иногда — бизнес-аналитика. Группа поддержки (Supporters Team): Стейкхолдеры, которых нужно регулярно информировать и от которых нужно получать данные. Это высшее руководство, другие продуктовые команды, маркетинг и т.д. Эта модель хорошо работает в больших продуктовых компаниях со сложной структурой.\n2. Наша команда (Дуэт Продаж и Технологий) В реалиях сервисного бизнеса и пресейл-процесса наша команда гораздо компактнее и мобильнее. У нас нет разделения на \u0026ldquo;основную\u0026rdquo; и \u0026ldquo;поддерживающую\u0026rdquo; команду, у нас есть единая проектная команда пресейла.\nВ 95% случаев эта команда — связка из двух ключевых фигур:\nМенеджер по продажам (Sales Manager): Наш ответ на \u0026ldquo;бизнес-стейкхолдера\u0026rdquo; и \u0026ldquo;маркетинг\u0026rdquo;. Он владеет коммерческой частью сделки. Presale/R\u0026amp;D Инженер: Наш гибрид \u0026ldquo;продакт-менеджера\u0026rdquo;, \u0026ldquo;техлида\u0026rdquo; и \u0026ldquo;бизнес-аналитика\u0026rdquo;. Он отвечает за техническую и содержательную часть. Привлекаемые эксперты: Для сложных проектов мы точечно привлекаем:\nSolution Architect: Когда нужна проработка комплексной архитектуры. Профильный эксперт: Например, Data Scientist, DevOps-инженер или специалист по IoT, если проект требует глубокой узкоспециализированной экспертизы. Дизайнеры и рядовые разработчики на этом этапе привлекаются только для консультаций или создания PoC, они не являются постоянными членами команды Discovery.\n3. Роли и обязанности в нашей команде Роль Ключевые задачи в процессе Discovery На что НЕ тратит время Менеджер по продажам Управляет коммуникацией с клиентом, отвечает за коммерческие вопросы (бюджет, сроки), организует встречи, следит за движением сделки по воронке продаж. Глубокий технический анализ, написание кода, детальное проектирование архитектуры. Presale/R\u0026amp;D Инженер Проводит технические воркшопы, выявляет требования и ограничения, рисует эскиз архитектуры, делает предварительную оценку, готовит техническую часть ТКП. Обсуждение финальной цены, юридические аспекты контракта, поиск новых клиентов. Solution Architect (привлекается) Проектирует сложные, комплексные системы, утверждает технологический стек, валидирует технические решения, предложенные инженером. Участие в рутинных встречах, написание коммерческих текстов, мелкие правки в документах. 4. Диаграмма взаимодействия Эта схема показывает, как распределяются потоки информации в нашей пресейл-команде.\ngraph TD Client[Клиент] Sales[Менеджер по продажам] Presale[Presale/R\u0026amp;D Инженер] Architect[Solution Architect] Client -- Бизнес-запрос, бюджет, сроки --\u0026gt; Sales Sales -- Организация встреч, коммерческая часть --\u0026gt; Client Sales -- Вводные данные по сделке --\u0026gt; Presale Presale -- Технические воркшопы, сбор требований --\u0026gt; Client Client -- Техническая информация, ограничения --\u0026gt; Presale Architect -- Консультации, утверждение архитектуры --\u0026gt; Presale Presale -- Запрос на экспертизу --\u0026gt; Architect Presale -- Техническая часть ТКП, оценка --\u0026gt; Sales Sales -- Финальное коммерческое предложение --\u0026gt; Client Глава 4.1: Понимание потребностей. Кого мы на самом деле слушаем? 1. Ключевые идеи из курса (Фокус на конечном пользователе) Автор курса открывает большую главу, посвященную пониманию потребностей пользователя. Он утверждает, что это один из важнейших этапов, и перечисляет ряд техник для исследования:\nСоздание портретов (Personas) и карт эмпатии (Empathy Maps). Проведение интервью, опросов и фокус-групп. Анализ записей сессий и продуктовой аналитики. Ключевой посыл автора: на этом этапе не нужно пытаться подтвердить свои идеи. Нужно с открытым разумом исследовать проблемы и потребности конечных пользователей (end-users).\n2. Наша реальность (Фокус на бизнес-заказчике) Этот раздел — один из самых важных для правильной адаптации процесса. В 99% случаев на этапе пресейла у нас нет и не будет прямого доступа к конечным пользователям продукта нашего клиента. Это коммерческая тайна, организационные сложности или просто нежелание клиента.\nПоэтому мы должны четко переопределить объект нашего исследования.\nНаш «пользователь» на этапе Discovery — это сам клиент:\nМенеджеры, которые отвечают за KPI. Инженеры, которые будут поддерживать решение. Маркетологи, которым нужно продавать продукт. Руководители, которые выделяют бюджет. Мы ищем не «боли пользователя» (user pains), а «боли бизнеса» (business pains):\nГде компания теряет деньги? Какие процессы неэффективны и почему? Какие стратегические цели (KPI) нужно достичь? Какие технические ограничения и легаси-системы мешают развитию? Поэтому все инструменты, которые будут описаны в этой главе (интервью, карты эмпатии и т.д.), мы будем применять не к гипотетическим юзерам, а к конкретным представителям заказчика, с которыми мы ведем диалог.\n3. Сравнение объектов исследования Аспект Классический подход (Продуктовая компания) Наш подход (Сервисная компания) Кого изучаем? Конечный пользователь (End-user) Бизнес-заказчик (представители клиента) Что ищем? Повседневные проблемы, \u0026ldquo;боли\u0026rdquo;, привычки Бизнес-проблемы, неэффективность, цели, KPI, технические ограничения Основной вопрос \u0026ldquo;Как сделать жизнь пользователя лучше?\u0026rdquo; \u0026ldquo;Как помочь бизнесу клиента заработать/сэкономить деньги?\u0026rdquo; Источник информации Интервью с пользователями, опросы, аналитика Воркшопы со стейкхолдерами, техническая документация клиента 4. Диаграмма смещения фокуса Эта диаграмма показывает, как меняется основной объект нашего внимания.\ngraph TD subgraph \u0026#34;Классический Discovery\u0026#34; A(Продукт) --\u0026gt; B(Конечный пользователь) B -- \u0026#34;Обратная связь, \u0026#39;боли\u0026#39;\u0026#34; --\u0026gt; A end subgraph \u0026#34;Наш Discovery (Пресейл)\u0026#34; C(Проектное решение) --\u0026gt; D(\u0026lt;b\u0026gt;Бизнес-заказчик\u0026lt;/b\u0026gt;) D -- Требования, ограничения, KPI --\u0026gt; C D -- косвенно представляет --\u0026gt; E(Конечный пользователь) C -.-\u0026gt; E end В следующих разделах мы разберем, как применять конкретные инструменты к нашему главному \u0026ldquo;пользователю\u0026rdquo; — клиенту.\nГлава 4.2: User Persona. Адаптируем для работы с клиентом 1. Ключевые идеи из курса (Портрет конечного пользователя) Автор определяет User Persona как полувымышленного персонажа, основанного на исследованиях, который представляет вашего текущего или идеального клиента.\nЦели создания User Persona в классическом подходе:\nГлубже понять конечных пользователей. Определить, какие функции будут для них ценны. Выявить потенциальные проблемы пользователей. Синхронизировать видение внутри команды разработки — «для кого мы делаем продукт». Автор предлагает использовать готовые шаблоны, например, в Miro, для создания таких портретов.\n2. Наша версия — «Портрет Ключевого Стейкхолдера» Мы не создаем портреты вымышленных конечных пользователей. Это не имеет смысла, так как мы не можем проверить наши гипотезы о них. Вместо этого мы создаем профили реальных людей в компании клиента, с которыми мы ведем переговоры. Назовем этот инструмент «Портрет Ключевого Стейкхолдера».\nНаша цель — понять не личные привычки этих людей, а их роль в проекте, их критерии успеха, их страхи и их влияние на принятие решения.\nЭтот инструмент помогает нам:\nЛучше готовиться к переговорам. Понимать, на каком языке говорить с каждым из участников (техническом, финансовом, бизнес-языке). Заранее определять потенциальных противников и союзников проекта внутри компании клиента. Формировать наше коммерческое предложение так, чтобы оно отвечало на запросы каждого ключевого стейкхолдера. 3. Шаблон «Портрета Ключевого Стейкхолдера» Вместо шаблона из Miro мы используем простую таблицу, которую можно заполнить после нескольких встреч с клиентом.\nКатегория Вопросы для заполнения Пример: Технический директор (CTO) Роль и зона ответственности Какова его/ее должность? За что он(а) отвечает в компании? Какова его/ее команда? CTO. Отвечает за всю IT-инфраструктуру, команду разработки и технологическую стратегию. Цели в рамках проекта Что он(а) хочет получить от этого проекта? Каков его/ее личный или командный KPI? Интегрировать новое решение с существующим легаси без сбоев. Обеспечить стабильность и безопасность. Уложиться в бюджет на поддержку. Критерии принятия решения На что он(а) смотрит в первую очередь? (Цена, технология, скорость, надежность, безопасность) 1. Технологическая совместимость. 2. Надежность и отказоустойчивость. 3. Простота и стоимость дальнейшей поддержки. Возможные опасения/риски Что его/ее беспокоит? Что может помешать проекту с его/ее точки зрения? Риск выбрать неподдерживаемый стек. Сложность интеграции. Нехватка компетенций у его команды для поддержки решения. Угрозы безопасности. Как мы можем помочь? Как наше предложение закрывает его/ее цели и снимает опасения? Предлагаем проверенный open-source стек. Даем детальный план интеграции. Предлагаем контракт на поддержку и обучение его команды. 4. Диаграмма влияния стейкхолдеров Эта диаграмма показывает, что разные стейкхолдеры смотрят на один и тот же проект под совершенно разными углами.\ngraph TD subgraph \u0026#34;Наше Проектное Решение\u0026#34; A(Предложение) end subgraph \u0026#34;Стейкхолдеры клиента\u0026#34; B(\u0026lt;b\u0026gt;CEO/Бизнес-лидер\u0026lt;/b\u0026gt;) C(\u0026lt;b\u0026gt;CTO/Технический директор\u0026lt;/b\u0026gt;) D(\u0026lt;b\u0026gt;Линейный менеджер/Владелец процесса\u0026lt;/b\u0026gt;) end A -- \u0026#34;Поможет ли это нам заработать больше?\u0026#34; --\u0026gt; B A -- \u0026#34;Насколько это надежно и совместимо с нашей инфраструктурой?\u0026#34; --\u0026gt; C A -- \u0026#34;Упростит ли это работу моей команды? Уложимся ли в сроки?\u0026#34; --\u0026gt; D Глава 4.3: Empathy Map. Структурируем информацию от клиента 1. Ключевые идеи из курса (Сопереживание пользователю) Автор представляет Карту Эмпатии (Empathy Map) как визуальный инструмент, чтобы понять, что пользователь говорит, думает, делает и чувствует. В отличие от User Persona (которая отвечает на вопрос \u0026ldquo;кто наш пользователь?\u0026rdquo;), Карта Эмпатии отвечает на вопрос \u0026ldquo;каков мир нашего пользователя?\u0026rdquo;.\nКлассическая карта включает блоки:\nЧто он видит (Sees)? Что он говорит (Says)? Что он делает (Does)? Что он слышит (Hears)? Что он думает и чувствует (Thinks \u0026amp; Feels), включая его \u0026ldquo;боли\u0026rdquo; (Pains) и \u0026ldquo;цели\u0026rdquo; (Gains). Цель — глубоко погрузиться в контекст пользователя, чтобы найти неочевидные инсайты.\n2. Наша версия — «Карта Воркшопа» Мы не можем и не должны \u0026ldquo;сопереживать\u0026rdquo; нашему клиенту в романтическом смысле. Наша задача — понять его бизнес. Поэтому мы используем структуру Карты Эмпатии не для анализа личности, а как практический инструмент для протоколирования встреч и воркшопов.\nНазовем наш аналог «Карта Воркшопа».\nЕе цель — структурировать хаотичный поток информации, который мы получаем от нескольких стейкхолдеров одновременно, и превратить его в основу для коммерческого предложения.\nМы не пытаемся угадать, что клиент \u0026ldquo;чувствует\u0026rdquo;. Мы фиксируем факты, требования, проблемы и цели, которые были озвучены или явно следуют из контекста.\n3. Шаблон «Карты Воркшопа» Это наш адаптированный шаблон. Его можно заполнять прямо во время или сразу после встречи с клиентом.\nБлок Что мы здесь фиксируем (во время встречи с клиентом) Пример: Воркшоп по проекту автоматизации отчетности Говорит (Says) Прямые цитаты, ключевые фразы, озвученные требования, пожелания. Все, что было сказано дословно. \u0026ldquo;Нам надоело собирать отчеты вручную из трех разных систем. Это занимает неделю каждый месяц.\u0026quot;\n\u0026ldquo;Решение должно быть на Python.\u0026rdquo; Делает (Does) Что они делают сейчас? Какие текущие процессы описывают? Какие шаги предпринимают для решения проблемы? \u0026ldquo;Сначала аналитик выгружает данные из SAP, потом из Salesforce. Потом в Excel сводит. Часто бывают ошибки в формулах.\u0026rdquo; Думает (Thinks) ➡️ Мысли и Опасения Что они не говорят прямо, но подразумевают? Какие риски и опасения проскальзывают между строк? Опасения: \u0026ldquo;А не будет ли новая система стоить дороже, чем ручной труд? Смогут ли наши люди в ней работать? Не уволят ли аналитика после автоматизации?\u0026rdquo; Чувствует (Feels) ➡️ Боли и Цели Какие конкретные проблемы (боли) они испытывают? Каких измеримых бизнес-результатов (целей) хотят достичь? Боль: Потеря времени, ошибки в данных, невозможность получить отчет в реальном времени, высокая зависимость от одного сотрудника.\nЦель: Сократить время на подготовку отчета с 40 часов/месяц до 1 часа/месяц. Повысить точность данных до 99.9%. 4. Диаграмма трансформации информации Эта диаграмма показывает, как хаотичный поток информации с встречи превращается в структурированную основу для дальнейшей работы.\ngraph TD A[Поток информации с воркшопа\u0026lt;br\u0026gt;- Высказывания\u0026lt;br\u0026gt;- Описания процессов\u0026lt;br\u0026gt;- Скрытые опасения\u0026lt;br\u0026gt;- Бизнес-пожелания] --\u0026gt; B{\u0026#34;Применяем структуру\u0026lt;br\u0026gt;«Карты Воркшопа»\u0026#34;}; B --\u0026gt; C[Структурированные данные\u0026lt;br\u0026gt;\u0026lt;b\u0026gt;Требования:\u0026lt;/b\u0026gt; Python, интеграция с SAP/Salesforce.\u0026lt;br\u0026gt;\u0026lt;b\u0026gt;Процессы as-is:\u0026lt;/b\u0026gt; Ручной сбор в Excel.\u0026lt;br\u0026gt;\u0026lt;b\u0026gt;Риски:\u0026lt;/b\u0026gt; Сопротивление персонала, стоимость поддержки.\u0026lt;br\u0026gt;\u0026lt;b\u0026gt;Бизнес-цели:\u0026lt;/b\u0026gt; Сократить время на 95%, повысить точность.]; C --\u0026gt; D[Основа для\u0026lt;br\u0026gt;технического задания и\u0026lt;br\u0026gt;коммерческого предложения]; Глава 4.4: Интервью с клиентом. Как задавать правильные вопросы 1. Ключевые идеи из курса (Вопросы для пользователей) Автор подчеркивает важность правильных вопросов для получения качественной обратной связи. Основные рекомендации из курса:\nВсегда иметь цель: Четко понимать, что вы хотите узнать (например, почему низкая конверсия, какие фичи добавить и т.д.). Предпочитать интервью опросам: Живое общение дает более глубокое понимание, чем сухие ответы в анкете. Говорить с достаточным количеством людей: Не делать выводы на основе мнения одного-двух человек. Задавать открытые вопросы: Особенно о прошлом опыте, чтобы избежать фантазий и получить реальные факты. Этот подход нацелен на исследование рынка и поведения большой группы конечных пользователей.\n2. Наш подход — «Технический воркшоп-интервью» В нашем случае \u0026ldquo;интервью\u0026rdquo; — это не исследование, а целенаправленный сбор требований в рамках рабочей встречи (воркшопа). Мы говорим не с сотней анонимных пользователей, а с 3-5 ключевыми стейкхолдерами со стороны клиента, и у нас обычно всего несколько встреч, чтобы получить всю необходимую информацию.\nНаша цель — не \u0026ldquo;изучить пользователя\u0026rdquo;, а собрать конкретные бизнес-требования, технические ограничения и критерии успеха, чтобы составить адекватное коммерческое предложение.\nПоэтому мы используем комбинацию вопросов:\nОткрытые вопросы — чтобы понять общую картину и бизнес-контекст. Закрытые и уточняющие вопросы — чтобы получить конкретные факты, цифры и технические детали. 3. Наш чек-лист вопросов для воркшопа с клиентом Это не исчерпывающий список, а скорее каркас для подготовки к встрече. Вопросы нужно адаптировать под конкретный проект.\nКатегория вопросов Примеры Цель Бизнес-контекст и цели \u0026ldquo;Какую бизнес-проблему вы пытаетесь решить этим проектом?\u0026quot;\n\u0026ldquo;Как вы поймете, что проект успешен через год? Какие метрики изменятся?\u0026quot;\n\u0026ldquo;Какой ориентировочный бюджет заложен на этот проект и его поддержку?\u0026rdquo; Понять ценность проекта для бизнеса, критерии успеха, финансовые рамки. Текущие процессы (As-Is) \u0026ldquo;Можете по шагам описать, как этот процесс работает сейчас? Кто участвует?\u0026quot;\n\u0026ldquo;Какие инструменты (софт, системы) используются на каждом шаге?\u0026quot;\n\u0026ldquo;Что в текущем процессе самое сложное / долгое / дорогое? Где чаще всего возникают ошибки?\u0026rdquo; Понять текущую ситуацию, найти узкие места и точки для оптимизации. Технические требования и ограничения \u0026ldquo;В какой среде это должно работать? Облако (какое?) или On-premise?\u0026quot;\n\u0026ldquo;Есть ли у вас предпочтения или ограничения по технологическому стеку (языки, фреймворки, БД)?\u0026quot;\n\u0026ldquo;С какими внутренними/внешними системами нужна интеграция? Есть ли у них API и документация?\u0026rdquo; Собрать технические рамки проекта, понять сложность интеграции. Будущее решение (To-Be) \u0026ldquo;Как в идеальном мире должен выглядеть этот процесс после внедрения нашего решения?\u0026quot;\n\u0026ldquo;Кто будет основными пользователями системы? Сколько их будет?\u0026quot;\n\u0026ldquo;Какие у вас есть требования к безопасности, производительности, масштабируемости?\u0026rdquo; Сформировать общее видение будущего продукта и его нефункциональные требования. Организационные вопросы \u0026ldquo;Кто в вашей компании будет принимать финальное решение по нашему предложению?\u0026quot;\n\u0026ldquo;Каковы ожидаемые сроки принятия решения и старта проекта?\u0026quot;\n\u0026ldquo;Кто будет нашим основным техническим и бизнес-контактом на время проекта?\u0026rdquo; Понять процесс продажи, дальнейшие шаги и ключевых лиц. 4. Диаграмма \u0026ldquo;Воронка вопросов\u0026rdquo; Хороший воркшоп-интервью строится по принципу воронки: от общего к частному.\ngraph TD A[\u0026#34;\u0026lt;b\u0026gt;Начало встречи:\u0026lt;/b\u0026gt; общие, открытые вопросы\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;\u0026#39;Расскажите о вашей проблеме...\u0026#39;\u0026lt;/i\u0026gt;\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;\u0026#39;Каких целей вы хотите достичь?\u0026#39;\u0026lt;/i\u0026gt;\u0026#34;] --\u0026gt; B[\u0026#34;\u0026lt;b\u0026gt;Середина:\u0026lt;/b\u0026gt; конкретизирующие вопросы о процессах и технологиях\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;\u0026#39;А как именно работает этот шаг?\u0026#39;\u0026lt;/i\u0026gt;\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;\u0026#39;Какой протокол использует это API?\u0026#39;\u0026lt;/i\u0026gt;\u0026#34;] B --\u0026gt; C[\u0026#34;\u0026lt;b\u0026gt;Уточняющие вопросы и резюмирование\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;\u0026#39;Правильно ли я понимаю, что вам нужно...?\u0026#39;\u0026lt;/i\u0026gt;\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;\u0026#39;Итак, ключевые требования это А, Б и В.\u0026#39;\u0026lt;/i\u0026gt;\u0026#34;] C --\u0026gt; D[\u0026#34;\u0026lt;b\u0026gt;Конец встречи:\u0026lt;/b\u0026gt; вопросы о дальнейших шагах\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;\u0026#39;Кто примет решение?\u0026#39;\u0026lt;/i\u0026gt;\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;\u0026#39;Когда нам ждать ответа?\u0026#39;\u0026lt;/i\u0026gt;\u0026#34;] Глава 4.5: Дополнительные техники. Где еще брать информацию? 1. Ключевые идеи из курса (Анализ данных и конкурентов) Автор предлагает еще несколько техник для сбора информации о пользователях:\nЗаписи сессий (Session Recordings): Анализ видеозаписей реальных взаимодействий пользователей с продуктом (сайтом или приложением) для выявления проблемных мест, неэффективных сценариев и точек \u0026ldquo;затыка\u0026rdquo;. Аналитика данных (Data Analytics): Изучение количественных данных о поведении пользователей (конверсии, отказы, время на странице), чтобы найти аномалии и паттерны. Анализ конкурентов (Competitor Analysis): Изучение продуктов конкурентов для поиска идей и понимания рыночных стандартов. Все эти методы предполагают, что у вас есть существующий продукт с пользователями и данными, либо вы работаете на открытом, понятном рынке.\n2. Наши источники информации В большинстве пресейл-сценариев у нас нет доступа к продуктовой аналитике клиента или записям сессий его пользователей. Но у нас есть свои, не менее ценные источники информации.\nВместо \u0026ldquo;Записей сессий\u0026rdquo; → \u0026ldquo;Демонстрация экрана\u0026rdquo;. Мы просим ключевого сотрудника клиента (будущего пользователя системы) в режиме реального времени показать нам, как он сейчас выполняет свою работу. Это \u0026ldquo;живая\u0026rdquo; запись сессии, где можно сразу задавать уточняющие вопросы. Это один из самых ценных источников инсайтов.\nВместо \u0026ldquo;Продуктовой аналитики\u0026rdquo; → \u0026ldquo;Запрос отчетов и выгрузок\u0026rdquo;. У нас нет доступа к их Google Analytics, но мы можем попросить: \u0026ldquo;Пришлите, пожалуйста, пример отчета, который вы собираете вручную\u0026rdquo; или \u0026ldquo;Можете ли вы сделать выгрузку из базы данных по этим параметрам за последний месяц?\u0026rdquo;. Эти данные часто показывают реальные проблемы лучше любой аналитики.\nВместо \u0026ldquo;Анализа конкурентов\u0026rdquo; → \u0026ldquo;Анализ окружения\u0026rdquo;. Мы анализируем две вещи:\nКонкурентов нашего клиента (если это важно для проекта): \u0026ldquo;А как эту проблему решают ваши конкуренты?\u0026rdquo; Наших конкурентов на этом проекте: \u0026ldquo;Кто еще претендует на этот контракт? Это другая аутсорс-компания или внутренняя команда разработки клиента?\u0026rdquo; Понимание этого помогает нам правильно позиционировать наше предложение. Наши главные \u0026ldquo;другие техники\u0026rdquo;:\nИзучение документации: Запрашиваем и внимательно читаем все, что есть: старые ТЗ, схемы баз данных, описания API, должностные инструкции. Это кладезь информации. Технический Proof of Concept (PoC): Если есть критически важная техническая гипотеза (например, \u0026ldquo;сможем ли мы интегрироваться с их древней ERP-системой?\u0026rdquo;), мы можем предложить сделать небольшой, изолированный PoC, чтобы проверить ее. Это снимает огромный пласт рисков. 3. Таблица адаптации техник Техника из курса Есть ли у нас к этому доступ? Наш аналог / Что делаем вместо этого Записи сессий (Session Recordings) Почти никогда Демонстрация экрана от клиента. Просим показать, как они работают в своих системах прямо сейчас. Продуктовая аналитика (Data Analytics) Почти никогда Запрашиваем отчеты и выгрузки. Просим клиента поделиться существующими отчетами, статистикой, любыми данными по проблеме. Анализ конкурентов Частично Анализ конкурентного окружения клиента.\nАнализ нашего собственного конкурентного окружения. (Наше дополнение) - Изучение всей доступной документации клиента (ТЗ, схемы, API docs). (Наше дополнение) - Быстрый технический Proof of Concept (PoC) для проверки рисков. 4. Диаграмма \u0026ldquo;Наши источники истины\u0026rdquo; Для составления качественного коммерческого предложения мы опираемся на информацию из разных источников.\ngraph TD subgraph \u0026#34;Информация от людей\u0026#34; A[Воркшопы и интервью] end subgraph \u0026#34;Информация из документов\u0026#34; B[RFP / ТЗ / Внутренняя документация] end subgraph \u0026#34;Информация из систем\u0026#34; C[Живая демонстрация работы ПО] D[Отчеты и выгрузки данных] end subgraph \u0026#34;Информация от нас (проверка гипотез)\u0026#34; E[Результаты нашего PoC] end A \u0026amp; B \u0026amp; C \u0026amp; D \u0026amp; E --\u0026gt; F{\u0026lt;strong\u0026gt;Полная картина для\u0026lt;br\u0026gt;коммерческого предложения\u0026lt;/strong\u0026gt;} Глава 5.1: Определение проблемы. Формулируем скоуп проекта 1. Ключевые идеи из курса (Поиск и формулировка проблемы) Автор предлагает следующий процесс для определения проблемы:\nСобрать все проблемы: Выписать все проблемы, потребности и желания, выявленные на этапе исследования. Найти паттерны: Сгруппировать похожие проблемы, которые упоминались несколькими пользователями. Четко определить: Сформулировать проблему в виде понятного утверждения (Problem Statement). Валидировать: Проверить правильность формулировки с ключевыми стейкхолдерами и клиентами. Приоритизировать: Решить, какие проблемы будут решаться в первую очередь, а какие уйдут в бэклог. Для этого предлагается использовать различные фреймворки, например, \u0026ldquo;Jobs to be Done\u0026rdquo; (JTBD), чтобы структурировать информацию.\n2. Наша цель — определить скоуп, а не «проблему» В нашем контексте этот процесс имеет гораздо более прагматичную цель. Клиент часто приходит с целым списком проблем и \u0026ldquo;хотелок\u0026rdquo;. Если мы попытаемся решить их все, проект станет безразмерным и неподъемным.\nПоэтому наша задача — не просто \u0026ldquo;определить проблему\u0026rdquo;, а определить и согласовать с клиентом границы (scope) первого проекта / MVP.\n\u0026ldquo;Определение проблемы\u0026rdquo; для нас — это процесс, в ходе которого мы:\nВыслушиваем все проблемы клиента (собираем требования). Помогаем ему выбрать 1-2 самые критичные проблемы, решение которых даст максимальный эффект в кратчайшие сроки. Формулируем решение этих проблем в виде четкого, ограниченного набора работ. Хорошо определенный скоуп, особенно раздел \u0026ldquo;Что НЕ входит в скоуп\u0026rdquo;, — это наша главная защита от недопонимания, конфликтов и раздувания бюджета в будущем. Это самый важный артефакт этапа Discovery.\n3. Шаблон для определения скоупа (Scope Statement) Это упрощенный шаблон, который можно и нужно включать в каждое коммерческое предложение или SOW (Statement of Work).\nРаздел Описание Пример: Проект автоматизации отчетности Проблема / Возможность Краткое описание бизнес-проблемы, которую мы решаем в этом проекте. Ручной сбор ежемесячного отчета по продажам из SAP и Salesforce занимает у аналитика 40 человеко-часов и содержит до 5% ошибок из-за человеческого фактора. Цели проекта Каких измеримых бизнес-результатов мы должны достичь? 1. Сократить время сборки отчета до 1 часа.\n2. Снизить количество ошибок до нуля.\n3. Обеспечить возможность генерации отчета по запросу, а не раз в месяц. Что входит в скоуп (In Scope) Детальный перечень конкретных работ, функций, модулей, которые мы делаем. - Разработка модуля для автоматического получения данных из SAP (по API) и Salesforce (по API).\n- Разработка модуля трансформации и объединения данных.\n- Создание веб-интерфейса для просмотра и выгрузки отчета в .xlsx. Что НЕ входит в скоуп (Out of Scope) (Самый важный раздел!) Четкий перечень того, что мы НЕ делаем в рамках этого проекта. - Разработка мобильного приложения для просмотра отчетов.\n- Интеграция с другими системами (1С, Oracle и т.д.).\n- Разработка модуля предиктивной аналитики и прогнозирования продаж. Критерии приемки Как клиент поймет, что работа выполнена успешно? 1. Система развернута на сервере клиента.\n2. Отчет генерируется по кнопке в веб-интерфейсе.\n3. Данные в сгенерированном отчете совпадают с данными из систем-источников (проверяется на 3 тестовых отчетах). 4. Диаграмма \u0026ldquo;Сужение фокуса\u0026rdquo; Эта диаграмма иллюстрирует, как мы отсекаем все лишнее, чтобы сформировать понятный и выполнимый проект.\ngraph TD A[\u0026#34;\u0026lt;b\u0026gt;Весь список проблем и хотелок клиента:\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;- автоматизировать отчеты\u0026lt;br\u0026gt;- мобильное приложение\u0026lt;br\u0026gt;- предсказания на AI\u0026lt;br\u0026gt;- интеграция с 1С\u0026lt;br\u0026gt;- ...\u0026#34;] --\u0026gt; B{Процесс Discovery и приоритизации}; B --\u0026gt; C[\u0026#34;\u0026lt;b\u0026gt;Выбранные проблемы для MVP:\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;- Долгий сбор отчетов\u0026lt;br\u0026gt;- Ошибки в данных\u0026#34;]; C --\u0026gt; D[\u0026#34;\u0026lt;b\u0026gt;Четко очерченный скоуп\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;In Scope:\u0026lt;/i\u0026gt; Интеграция с SAP/SF, веб-отчет.\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;Out of Scope:\u0026lt;/i\u0026gt; Мобильное приложение, AI, 1С.\u0026#34;]; D --\u0026gt; E[Основа для SOW и контракта]; Глава 5.2: Приоритизация. Как договориться с клиентом о MVP 1. Ключевые идеи из курса (Фреймворки для бэклога) Автор предлагает использовать формальные системы для приоритизации, чтобы решения были прозрачными и обоснованными, а не основанными на интуиции.\nВ качестве основного инструмента он подробно разбирает фреймворк RICE:\nReach (Охват): Скольких людей затронет эта фича? Impact (Влияние): Насколько сильно она их затронет? Confidence (Уверенность): Насколько мы уверены в своих оценках охвата и влияния? Effort (Усилия): Сколько времени и ресурсов это займет? Формула (Reach * Impact * Confidence) / Effort дает скоринговый балл для каждой фичи. Этот подход отлично работает в продуктовых компаниях, где есть доступ к данным и возможность оценить эти параметры.\n2. Наша цель — приоритизация для продажи, а не для разработки Для нас фреймворки вроде RICE избыточны и непрактичны. У нас нет данных для оценки Reach и Impact, а Confidence всегда будет низкой. Наша задача — не составить идеальный бэклог на год, а быстро согласовать с клиентом адекватный скоуп для первого контракта (MVP).\nПоэтому мы используем фреймворки не как внутренний математический инструмент, а как инструмент для ведения переговоров с клиентом. Они помогают визуализировать и структурировать диалог, наглядно показать, почему мы предлагаем сделать именно этот набор работ, а остальное отложить.\nНаш главный критерий приоритизации — максимальная видимая ценность для бизнеса клиента при минимальных затратах и рисках (как для нас, так и для него).\n3. Адаптация фреймворка MoSCoW для переговоров Для диалога с клиентом лучше всего подходит простой и понятный фреймворк MoSCoW. Он не требует сложных расчетов и легко воспринимается нетехническими специалистами.\nМы проводим с клиентом воркшоп, где вместе распределяем все его \u0026ldquo;хотелки\u0026rdquo; по четырем категориям.\nКатегория (MoSCoW) Классическое определение Наше определение (в диалоге с клиентом) Пример: Проект автоматизации отчетности Must Have (Должно быть) Без этого релиз невозможен. \u0026ldquo;Что абсолютно необходимо сделать в первую очередь, чтобы решить самую острую проблему? Это войдет в первый контракт (MVP).\u0026rdquo; Интеграция с SAP и Salesforce, автоматический сбор данных, выгрузка итогового отчета в Excel. Should Have (Следует сделать) Важно, но не критично для первого релиза. \u0026ldquo;Что было бы здорово добавить сразу после MVP? Это можно оформить как вторую фазу проекта.\u0026rdquo; Веб-интерфейс с графиками и дашбордами, автоматическая рассылка отчета по почте. Could Have (Можно сделать) Желательно, если останутся ресурсы. \u0026ldquo;Какие еще интересные идеи есть на будущее? Мы можем их зафиксировать и вернуться к ним позже.\u0026rdquo; (Идеи для допродаж) Модуль предиктивной аналитики на основе отчетов, интеграция с BI-системами. Won\u0026rsquo;t Have (Не будет) Этого точно не будет в этом релизе. \u0026ldquo;Что мы сознательно НЕ делаем сейчас, чтобы сфокусироваться на главном? Это мы зафиксируем как Out of Scope.\u0026rdquo; Мобильное приложение для просмотра отчетов, интеграция с 1С. 4. Диаграмма \u0026ldquo;Процесс согласования MVP\u0026rdquo; Этот воркшоп — ключевой момент в формировании скоупа. Он превращает разрозненные \u0026ldquo;хотелки\u0026rdquo; в структурированный план.\ngraph TD A[\u0026#34;Весь список \u0026#39;хотелок\u0026#39; клиента\u0026#34;] --\u0026gt; B{\u0026#34;Проводим воркшоп по приоритизации (MoSCoW)\u0026#34;}; B --\u0026gt; C[\u0026#34;\u0026lt;b\u0026gt;Must Have\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;(Формирует скоуп для MVP)\u0026#34;]; B --\u0026gt; D[\u0026#34;\u0026lt;b\u0026gt;Should/Could Have\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;(Формирует план развития и идеи для будущих контрактов)\u0026#34;]; B --\u0026gt; E[\u0026#34;\u0026lt;b\u0026gt;Won\u0026#39;t Have\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;(Формирует раздел \u0026#39;Out of Scope\u0026#39; в контракте)\u0026#34;]; C \u0026amp; D \u0026amp; E --\u0026gt; F[\u0026lt;strong\u0026gt;Согласованный и понятный план работ\u0026lt;/strong\u0026gt;]; Глава 6.1: Поиск решений. От креатива к архитектурному эскизу 1. Ключевые идеи из курса (Время для креатива) Автор курса обозначает этот этап как время для творчества и генерации большого количества идей. После того как проблема определена и приоритизирована, команда должна собраться вместе и, используя различные техники (мозговой штурм, сторибординг и т.д.), придумать множество возможных способов ее решения.\nЭтот подход (дивергентное мышление) направлен на то, чтобы не упустить потенциально лучшее или самое инновационное решение, рассмотрев все возможные варианты.\n2. Наша цель — быстро прийти к одному рабочему варианту В условиях пресейла у нас нет ни времени, ни бюджета на долгие креативные сессии и исследование десятков вариантов. Наша задача прямо противоположная — максимально быстро прийти к одному, максимум двум, реалистичным техническим решениям, которые:\na) Решают согласованную проблему клиента. б) Вписываются в его ограничения (бюджет, существующая инфраструктура, предпочтения по стеку). в) Являются для нас понятными, оценимыми и прибыльными.\n\u0026ldquo;Решение\u0026rdquo; для нас на этом этапе — это не детальный проект, а архитектурный эскиз (high-level design). Это схема из нескольких блоков, показывающая основные компоненты системы и как они будут взаимодействовать.\nГлавная цель этого эскиза — позволить нам сделать адекватную оценку трудозатрат и доказать клиенту, что мы четко понимаем, как будем делать проект. Креативность здесь уступает место прагматизму и опыту.\n3. Сравнение подходов к поиску решения Аспект Классический подход (Продуктовая компания) Наш подход (Сервисная компания) Цель Найти самое инновационное / лучшее для пользователя решение. Найти реализуемое и прибыльное для нас решение. Количество вариантов Чем больше, тем лучше (широкий поиск). 1-2 реалистичных варианта (быстрое сужение). Результат этапа Набор креативных идей для дальнейшей проверки. Архитектурный эскиз и оценка трудозатрат. Ключевой вопрос \u0026ldquo;Как еще можно было бы решить эту проблему?\u0026rdquo; \u0026ldquo;Как мы можем решить эту проблему, используя стек X на инфраструктуре Y с бюджетом Z?\u0026rdquo; 4. Диаграмма \u0026ldquo;От проблемы к оценке\u0026rdquo; Эта диаграмма показывает наш сфокусированный процесс работы над решением.\ngraph TD A[Согласованный скоуп MVP] --\u0026gt; B{\u0026#34;Внутренний технический воркшоп\u0026lt;br\u0026gt;(Presale инженер + Solution Architect)\u0026#34;}; B --\u0026gt; C[\u0026#34;\u0026lt;b\u0026gt;Архитектурный эскиз\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;(High-level design)\u0026lt;br\u0026gt;\u0026lt;i\u0026gt;Основные компоненты и связи\u0026lt;/i\u0026gt;\u0026#34;]; C --\u0026gt; D[\u0026#34;Выбор технологического стека\u0026#34;]; C --\u0026gt; E[\u0026#34;Декомпозиция и оценка трудозатрат\u0026lt;br\u0026gt;(человеко-часы)\u0026#34;]; D \u0026amp; E --\u0026gt; F[\u0026lt;strong\u0026gt;Основа для технической части\u0026lt;br\u0026gt;коммерческого предложения\u0026lt;/strong\u0026gt;]; В следующих разделах мы рассмотрим, как можно адаптировать креативные техники для наших быстрых и прагматичных целей.\nГлава 6.2: Мозговой штурм. Проектируем решение вместе с клиентом 1. Ключевые идеи из курса (Классический мозговой штурм) Автор описывает классический подход к мозговому штурму, цель которого — сгенерировать как можно больше идей. Ключевые правила:\nПравильный состав: Пригласить основную команду, можно — лояльных пользователей и экспертов. Важно — не звать высшее руководство, чтобы люди не боялись высказывать \u0026ldquo;глупые\u0026rdquo; идеи. Фокус на одной проблеме: Одна сессия — одна проблема. Поощрение любых идей: Не критиковать, генерировать как можно больше вариантов, даже самых диких. Использовать техники: Например, \u0026ldquo;тихий мозговой штурм\u0026rdquo;, когда все сначала пишут идеи на стикерах, а потом обсуждают. Цель — максимально расширить пространство возможных решений.\n2. Наш формат — «Архитектурный воркшоп» Мы не можем позволить себе \u0026ldquo;мозговой штурм\u0026rdquo; в его классическом, расфокусированном виде. Наша цель прямо противоположна: не расширить, а максимально быстро сузить пространство вариантов до одного рабочего эскиза архитектуры.\nПоэтому мы проводим не \u0026ldquo;мозговой штурм\u0026rdquo;, а структурированный архитектурный воркшоп. Он может быть как внутренним (только наша команда), так и совместным с техническими специалистами клиента.\nКлючевые отличия:\nЦель: Не \u0026ldquo;много идей\u0026rdquo;, а один согласованный архитектурный эскиз для оценки. Участники: Нам как раз нужны \u0026ldquo;начальники\u0026rdquo; — технический директор, ведущий архитектор со стороны клиента. Именно они являются носителями ключевых ограничений и принимают решения. Критика: Правило \u0026ldquo;не критиковать\u0026rdquo; отменяется. У нас наоборот — конструктивная критика на основе ограничений (бюджет, стек, безопасность, сроки) является главным рабочим инструментом. 3. Правила нашего «Архитектурного воркшопа» Правило Описание Почему это важно для нас 1. Начинаем с ограничений В самом начале на доске (реальной или виртуальной) фиксируются все известные ограничения: бюджет, сроки, предпочтительный стек, существующая инфраструктура, требования безопасности. Это сразу задает жесткие рамки и отсекает 90% нереалистичных идей, экономя время. 2. Рисуем вместе Наш Presale инженер или архитектор рисует на доске блоки и стрелки, а технические специалисты клиента комментируют, поправляют и дополняют. Это вовлекает клиента в процесс, повышает его доверие и гарантирует, что решение будет соответствовать их технической реальности. 3. Думаем компонентами Мыслим не абстрактными \u0026ldquo;фичами\u0026rdquo;, а конкретными \u0026ldquo;компонентами\u0026rdquo;: база данных, API-шлюз, очередь сообщений, фронтенд-приложение, модуль аналитики, сервис аутентификации. Это является прямой основой для будущей декомпозиции работ и их точной оценки. 4. Критикуем конструктивно Любая критика должна быть аргументирована одним из зафиксированных ограничений: \u0026ldquo;Это решение не впишется в бюджет\u0026rdquo;, \u0026ldquo;Наша служба безопасности не пропустит эту технологию\u0026rdquo;. Это позволяет быстро отсеивать нежизнеспособные варианты и приходить к реалистичному, согласованному решению. 5. Фиксируем результат В конце воркшопа фотографируем доску или сохраняем скриншот. Этот эскиз — главный результат встречи. Это наш основной артефакт для дальнейшей детальной оценки и подготовки технической части коммерческого предложения. 4. Диаграмма \u0026ldquo;Процесс воркшопа\u0026rdquo; sequenceDiagram participant PE as Presale Инженер participant Client as Тех. спец. клиента PE-\u0026gt;\u0026gt;Client: Давайте нарисуем, как это может работать. Вот наши ограничения: стек Python, бюджет $50k. loop Совместное проектирование PE-\u0026gt;\u0026gt;PE: Рисует на доске: [Веб-сервер] -\u0026gt; [База данных] Client-\u0026gt;\u0026gt;PE: Комментирует: \u0026#34;У нас уже есть кластер PostgreSQL, давайте его использовать. Новый не нужен.\u0026#34; PE-\u0026gt;\u0026gt;PE: Исправляет схему: [Веб-сервер] -\u0026gt; [Существующий PostgreSQL] Client-\u0026gt;\u0026gt;PE: \u0026#34;А где будет аутентификация? У нас есть свой SSO.\u0026#34; PE-\u0026gt;\u0026gt;PE: Добавляет компонент: [Веб-сервер] -\u0026gt; [Интеграция с SSO] end PE-\u0026gt;\u0026gt;Client: В целом так? Это решает задачу и укладывается в ограничения? Client-\u0026gt;\u0026gt;PE: Да, похоже на то. PE-\u0026gt;\u0026gt;PE: Фотографирует доску (фиксирует результат для оценки) Глава 6.3: Mind Map. Декомпозируем решение для оценки 1. Ключевые идеи из курса (Карта для идей) Автор представляет Mind Map (интеллект-карту) как визуальный и более увлекательный способ проведения мозгового штурма. Процесс прост:\nВ центре пишется проблема или тема (например, \u0026ldquo;Увеличить конверсию продукта А\u0026rdquo;). Участники добавляют ветви с идеями, как можно решить эту проблему (например, \u0026ldquo;поменять картинки\u0026rdquo;, \u0026ldquo;ускорить сайт\u0026rdquo; и т.д.). Цель, как и в обычном мозговом штурме, — сгенерировать как можно больше идей в наглядной форме, что, по мнению автора, повышает креативность и вовлеченность.\n2. Наш формат — «Карта работ» (Work Breakdown Structure) Мы не используем Mind Map для генерации идей. Для нас это неэффективная трата времени на этапе пресейла. Вместо этого мы используем саму визуальную структуру Mind Map для совершенно другой задачи — для декомпозиции уже согласованного архитектурного эскиза.\nНаш аналог — это «Карта работ». По сути, это графическое представление Work Breakdown Structure (WBS) — иерархической структуры работ по проекту.\nНаша цель — не придумать, что делать, а разбить уже известную работу на мелкие, понятные и, самое главное, оцениваемые в часах задачи. Эта карта является ключевым шагом между верхнеуровневой архитектурой и детальной сметой.\n3. Пример нашей «Карты работ» Вот как может выглядеть Mind Map для нашего примера с проектом автоматизации отчетов. Это внутренний документ, который составляет Presale инженер, возможно, консультируясь с тимлидами.\nmindmap root((Проект: Автоматизация отчетов)) (\u0026#34;Backend (120h)\u0026#34;) ::icon(fa fa-cogs) (\u0026#34;API (40h)\u0026#34;) (\u0026#34;Метод для SAP (16h)\u0026#34;) (\u0026#34;Метод для Salesforce (16h)\u0026#34;) (\u0026#34;Метод для выгрузки отчета (8h)\u0026#34;) (\u0026#34;Worker (56h)\u0026#34;) (\u0026#34;Сбор данных (24h)\u0026#34;) (\u0026#34;Трансформация (24h)\u0026#34;) (\u0026#34;Сохранение в БД (8h)\u0026#34;) (\u0026#34;База данных (24h)\u0026#34;) (\u0026#34;Схема таблиц (8h)\u0026#34;) (\u0026#34;Миграции (16h)\u0026#34;) (\u0026#34;Frontend (80h)\u0026#34;) ::icon(fa fa-desktop) (\u0026#34;Страница отчета (40h)\u0026#34;) (\u0026#34;Верстка таблицы (16h)\u0026#34;) (\u0026#34;Реализация фильтров (24h)\u0026#34;) (\u0026#34;Аутентификация (40h)\u0026#34;) (\u0026#34;Интеграция с SSO клиента (40h)\u0026#34;) (\u0026#34;DevOps (40h)\u0026#34;) ::icon(fa fa-server) (\u0026#34;Настройка CI/CD (24h)\u0026#34;) (\u0026#34;Развертывание в Staging (8h)\u0026#34;) (\u0026#34;Развертывание в Production (8h)\u0026#34;) 4. От Карты работ к итоговой оценке Эта карта — прямой путь к смете проекта.\nСоздаем Карту работ: Наш Presale инженер или архитектор строит Mind Map, как в примере выше. Оцениваем каждую ветку: Напротив каждой конечной задачи (\u0026ldquo;листа\u0026rdquo;) ставится предварительная оценка в часах. Суммируем: Все оценки по веткам суммируются, давая общую оценку по компонентам (Backend, Frontend) и по всему проекту (в примере: 120 + 80 + 40 = 240 часов). Добавляем буферы: К \u0026ldquo;чистой\u0026rdquo; оценке разработки (240ч) добавляется время на тестирование (QA), управление проектом (PM) и буфер на риски. Стандартная практика — добавлять 30-50% к чистой оценке. Пример: 240ч + 40% (96ч) = 336 часов. Получаем итоговую оценку: Эта цифра (336 часов) умножается на нашу внутреннюю ставку и превращается в стоимость проекта в коммерческом предложении. Глава 6.4: Working Backward. Описываем цели и видение проекта 1. Ключевые идеи из курса (Техника Amazon) Автор описывает известную технику Amazon \u0026ldquo;Working Backward\u0026rdquo; (Работать от обратного). Ее суть в том, чтобы до начала разработки написать внутренний пресс-релиз, анонсирующий запуск уже готового продукта.\nСтруктура пресс-релиза:\nНазвание продукта. Ключевые выгоды в одной строке. Саммари: какую проблему решает и как. Цитата представителя компании. Информация о том, как начать пользоваться. Цитата вымышленного довольного клиента. Цель этой техники — заставить команду с самого начала думать о ценности для клиента и четко сформулировать, зачем они вообще делают этот продукт. Это мощный инструмент для выравнивания видения и фокусировки на результате.\n2. Наша адаптация — «Описание будущего решения» в ТКП Мы, конечно, не пишем пресс-релизы для каждого проекта. Но мы используем саму идею — описать конечный результат так, как будто он уже готов — для формулирования ключевого раздела в нашем технико-коммерческом предложении (ТКП).\nЭтот раздел можно назвать \u0026ldquo;Видение и цели проекта\u0026rdquo; или \u0026ldquo;Описание предлагаемого решения\u0026rdquo;.\nЕго задача — продать идею проекта бизнес-стейкхолдерам клиента (CEO, коммерческому директору — тем, кто выделяет деньги), говоря с ними на языке выгод, а не технических фич. Этот текст должен быть простым, убедительным и коротким.\n3. Шаблон «Описания будущего решения» Этот текст пишется в самом начале ТКП, сразу после указания названия проекта. Он должен \u0026ldquo;зацепить\u0026rdquo; читателя и объяснить суть в 5-6 абзацах.\nПроект: Автоматизация процесса подготовки ежемесячной отчетности\nДля кого: Для руководителей и аналитиков отдела продаж компании \u0026ldquo;Клиент-Нейм\u0026rdquo;.\nСуществующая проблема: В настоящее время сотрудники отдела аналитики тратят до 40 человеко-часов каждый месяц на ручной сбор данных из систем SAP и Salesforce и их сведение в Excel. Этот процесс не только трудоемок, но и подвержен человеческим ошибкам, что может приводить к принятию решений на основе неверных данных.\nПредлагаемое решение: Мы предлагаем разработать и внедрить автоматизированную систему \u0026ldquo;ReportMaster\u0026rdquo;, которая полностью исключит ручной труд из процесса подготовки отчетов.\nКак это будет работать: Уполномоченный сотрудник сможет в любой момент зайти в простой и понятный веб-интерфейс, выбрать необходимый период и одним нажатием кнопки сгенерировать готовый отчет. Система автоматически заберет актуальные данные из SAP и Salesforce, объединит их и представит в виде удобной таблицы, готовой для анализа и выгрузки.\nКлючевые выгоды для вашего бизнеса:\nСокращение трудозатрат на подготовку отчета на 98% (с 40 часов до 1 часа в месяц). Повышение точности данных до 100%, исключение риска человеческой ошибки. Ускорение принятия решений за счет возможности получать актуальные данные в любой момент, а не ждать конца месяца. Представьте слова вашего руководителя отдела продаж: \u0026ldquo;С системой ReportMaster мы перестали тратить время на рутину и наконец-то можем заниматься тем, что действительно важно — анализировать данные и находить новые возможности для роста, будучи уверенными в цифрах, на которые мы смотрим.\u0026rdquo;\n4. Диаграмма \u0026ldquo;От видения к реализации\u0026rdquo; Этот раздел в ТКП — ключевой для получения согласия от бизнес-заказчика.\ngraph TD A[\u0026#34;\u0026lt;b\u0026gt;Описание будущего решения\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;(Раздел в ТКП, написанный на языке выгод)\u0026#34;] --\u0026gt; B[\u0026#34;Согласование с бизнес-заказчиком (ЛПР)\u0026#34;]; B -- \u0026#34;Да, это именно то, что нам нужно!\u0026#34; --\u0026gt; C[\u0026#34;Подписание контракта\u0026#34;]; C --\u0026gt; D[\u0026#34;Разработка технического решения\u0026lt;br\u0026gt;в полном соответствии\u0026lt;br\u0026gt;с согласованным видением\u0026#34;]; Глава 6.5: Role-Storming. Проверяем наше предложение на прочность 1. Ключевые идеи из курса (Штурм в роли пользователя) Автор описывает Role-Storming как веселую и интерактивную технику мозгового штурма. Суть в том, что участники перестают быть собой и начинают играть роль определенного пользователя (User Persona).\nЦель — раскрепостить участников и заставить их думать с точки зрения клиента. Автор утверждает, что, играя чужую роль, люди с большей вероятностью предлагают нестандартные (\u0026ldquo;out of the box\u0026rdquo;) идеи, которые они побоялись бы высказать от своего имени. Этот метод используется для генерации креативных идей по решению проблем пользователя.\n2. Наша адаптация — «Предзащита коммерческого предложения» Мы не играем в \u0026ldquo;конечных пользователей\u0026rdquo; и не пытаемся генерировать креативные идеи на этом этапе. Мы используем сам принцип ролевой игры для гораздо более прагматичной цели — для стресс-теста нашего готового коммерческого предложения (ТКП) перед его отправкой клиенту.\nМы проводим внутреннюю встречу, которую называем «Предзащита ТКП». На ней разные члены нашей команды играют роли ключевых стейкхолдеров клиента (технического директора, финансового директора и т.д.).\nЦель — предугадать все возможные каверзные вопросы, возражения и сомнения, которые могут возникнуть на реальной встрече с клиентом, и заранее подготовить на них убедительные ответы. Это репетиция самой важной встречи в цикле продаж.\n3. Сценарий «Предзащиты ТКП» Это внутренняя встреча, где один человек презентует, а остальные — \u0026ldquo;атакуют\u0026rdquo; его предложение с позиций разных ролей.\nРоль (наш сотрудник) Чью роль играет Типичные вопросы и возражения для этой роли Менеджер по продажам (Презентует ТКП) - Ведущий инженер Технический директор (CTO) клиента \u0026ldquo;Почему вы выбрали именно эту технологию, а не другую? Она же дорогая в поддержке. А как вы обеспечите безопасность данных? Ваша оценка выглядит заниженной, вы точно учли все риски интеграции с нашей легаси-системой?\u0026rdquo; Архитектор Финансовый директор (CFO) клиента \u0026ldquo;Почему это столько стоит? Конкуренты предлагают на 20% дешевле. Какая будет отдача на инвестиции (ROI)? Какие у нас будут операционные расходы на поддержку этого решения через год?\u0026rdquo; Менеджер проектов Конечный пользователь / Руководитель отдела \u0026ldquo;Это выглядит слишком сложно, мои сотрудники не будут этим пользоваться. Как будет проходить обучение? Что делать, если система сломается в пятницу вечером? Кто будет отвечать на звонки?\u0026rdquo; 4. Диаграмма \u0026ldquo;Цикл усиления предложения\u0026rdquo; Эта встреча превращает хороший черновик ТКП в \u0026ldquo;пуленепробиваемое\u0026rdquo; предложение.\ngraph TD A[Черновик коммерческого предложения] --\u0026gt; B{\u0026#34;Проводим внутреннюю\u0026lt;br\u0026gt;предзащиту (Role-Storming)\u0026#34;}; B --\u0026gt; C[\u0026#34;Выявляем слабые места:\u0026lt;br\u0026gt;- неубедительная аргументация\u0026lt;br\u0026gt;- неотвеченные вопросы\u0026lt;br\u0026gt;- неучтенные риски\u0026#34;]; C --\u0026gt; D[\u0026#34;Дорабатываем ТКП:\u0026lt;br\u0026gt;- Усиливаем техническое обоснование\u0026lt;br\u0026gt;- Добавляем раздел FAQ\u0026lt;br\u0026gt;- Корректируем оценку с учетом рисков\u0026#34;]; D --\u0026gt; E[\u0026lt;strong\u0026gt;Сильное и выверенное\u0026lt;br\u0026gt;коммерческое предложение\u0026lt;/strong\u0026gt;]; E --\u0026gt; F[Уверенная презентация клиенту]; Глава 6.6: Техника \u0026ldquo;Что, если?\u0026rdquo;. Выявляем и отрабатываем риски 1. Ключевые идеи из курса (Генерация идей через ограничения) Автор представляет технику \u0026ldquo;Что, если\u0026hellip;?\u0026rdquo; (What If) как метод для стимулирования креативности во время мозгового штурма. Команда задает себе гипотетические, часто экстремальные или ограничивающие вопросы, чтобы выйти за рамки привычного мышления.\nПримеры вопросов из курса:\n\u0026ldquo;Что, если мы представим новый, более дешевый продукт?\u0026rdquo; \u0026ldquo;Что, если у нас будет только 10 секунд, чтобы привлечь внимание клиента?\u0026rdquo; Цель — спровоцировать генерацию нестандартных идей и решений.\n2. Наша адаптация — «Анализ рисков» Мы не используем эту технику для фантазирования. Мы применяем ее с прямо противоположной целью: не для поиска идей, а для целенаправленного поиска и анализа потенциальных рисков проекта.\nДля нас вопросы \u0026ldquo;Что, если\u0026hellip;?\u0026rdquo; — это главный инструмент для стресс-тестирования нашего будущего решения и плана проекта. Этот процесс является обязательной частью нашей внутренней проработки перед финализацией оценки и отправкой ТКП клиенту.\nНаша цель — заранее продумать, что может пойти не так, и либо подготовить план \u0026ldquo;Б\u0026rdquo;, либо заложить дополнительное время и деньги в смету, чтобы застраховаться от этих рисков. Мы превращаем креативную технику в инструмент управления рисками.\n3. Наш чек-лист вопросов \u0026ldquo;Что, если?\u0026rdquo; для анализа рисков Это внутренний чек-лист для Presale инженера и архитектора на этапе оценки проекта.\nКатегория риска Вопросы \u0026ldquo;Что, если\u0026hellip;?\u0026rdquo; Что мы делаем с ответом (План митигации) Технические риски \u0026ldquo;Что, если API их системы окажется недокументированным или будет отдавать данные в другом формате?\u0026quot;\n\u0026ldquo;Что, если производительность нашего решения под реальной нагрузкой будет в 2 раза ниже расчетной?\u0026rdquo; Заложить дополнительное время на исследование и реверс-инжиниринг API.\nПровести PoC по нагрузочному тестированию или выбрать более масштабируемую технологию с запасом. Процессные риски \u0026ldquo;Что, если ключевой технический специалист со стороны клиента уйдет в отпуск/уволится в середине проекта?\u0026quot;\n\u0026ldquo;Что, если служба безопасности клиента будет согласовывать нам доступы не 1 неделю, а 2 месяца?\u0026rdquo; На старте запросить у клиента бэкап-контакт и ввести его в курс дела.\nЗаложить время ожидания в план проекта, инициировать процесс получения доступов в самый первый день проекта. Риски скоупа \u0026ldquo;Что, если клиент после старта проекта скажет: \u0026lsquo;Ой, я совсем забыл, нам еще очень нужна интеграция с 1С\u0026rsquo;?\u0026quot;\n\u0026ldquo;Что, если данные из системы SAP окажутся гораздо \u0026lsquo;грязнее\u0026rsquo;, чем мы думали?\u0026rdquo; Максимально детально и недвусмысленно прописать раздел \u0026ldquo;Out of Scope\u0026rdquo; в контракте.\nЗаложить в оценку дополнительное время на анализ, очистку и трансформацию данных. Финансовые риски \u0026ldquo;Что, если мы в целом ошиблись в оценке и не уложимся в бюджет?\u0026rdquo; Добавить адекватный буфер на непредвиденные риски (15-30%) к итоговой смете. Чем больше неопределенности, тем больше буфер. 4. Диаграмма \u0026ldquo;От риска к плану\u0026rdquo; Этот процесс превращает страхи и неопределенность в конкретные пункты плана и сметы.\ngraph TD A[Готовый архитектурный эскиз] --\u0026gt; B{\u0026#34;Проводим внутренний\u0026lt;br\u0026gt;анализ рисков \u0026#39;Что, если...?\u0026#39;\u0026#34;}; B --\u0026gt; C[Формируем список\u0026lt;br\u0026gt;потенциальных рисков проекта]; C --\u0026gt; D{Для каждого риска разрабатываем\u0026lt;br\u0026gt;план митигации}; D --\u0026gt; E[\u0026#34;- Добавить время в оценку (буфер)\u0026lt;br\u0026gt;- Провести дополнительное исследование/PoC\u0026lt;br\u0026gt;- Четко прописать в контракте (Out of Scope)\u0026lt;br\u0026gt;- Подготовить план \u0026#34;Б\u0026#34;\u0026#34;]; E --\u0026gt; F[\u0026lt;strong\u0026gt;Надежный план проекта и\u0026lt;br\u0026gt;обоснованная, защищенная смета\u0026lt;/strong\u0026gt;]; Глава 7.1: Валидация решения. Защищаем коммерческое предложение 1. Ключевые идеи из курса (Всесторонняя проверка) Автор рассматривает валидацию решения как многогранный процесс, который идет до создания полноценного прототипа. Он предлагает проверить (валидировать) идею решения с четырех точек зрения:\nТехническая возможность: Можем ли мы в принципе это построить? Бюджет: Соответствует ли стоимость решения ожиданиям бизнес-стейкхолдеров? Интеграция: Впишется ли это решение в существующий технологический ландшафт компании? Пользовательская ценность: Понравится ли это решение конечным пользователям? (проверяется через интервью и опросы). Этот подход очень разумен, так как рассматривает не только техническую, но и бизнес-составляющую.\n2. Наша валидация — это успешная защита ТКП Мы проводим точно такую же всестороннюю проверку, но для нас это не абстрактный этап, а процесс презентации и защиты нашего технико-коммерческого предложения (ТКП) перед клиентом.\nРешение считается нами \u0026ldquo;валидным\u0026rdquo;, если мы получили устное или письменное согласие по всем ключевым пунктам от всех ответственных лиц со стороны клиента.\nТехническая валидация происходит, когда CTO клиента говорит: \u0026ldquo;Да, эта архитектура выглядит разумно и вписывается в наш ландшафт\u0026rdquo;. Финансовая валидация происходит, когда CFO клиента говорит: \u0026ldquo;Да, эта цена и условия нас устраивают\u0026rdquo;. Бизнес-валидация (аналог пользовательской) происходит, когда будущий владелец продукта говорит: \u0026ldquo;Да, это решение закроет наши проблемы\u0026rdquo;. Главный инструмент для такой комплексной валидации — это не прототип, а хорошо подготовленное, структурированное коммерческое предложение и убедительная презентация, отвечающая на вопросы всех стейкхолдеров.\n3. Чек-лист для успешной защиты (валидации) ТКП Чтобы успешно пройти валидацию у клиента, наше ТКП и презентация должны содержать ответы на все ключевые вопросы.\nЭлемент ТКП Чью потребность валидирует Ключевой вопрос, на который отвечает 1. Описание выгод и целей Бизнес-заказчик (ЛПР) \u0026ldquo;Зачем нам этот проект? Какую пользу он принесет?\u0026rdquo; 2. Четкий скоуп (In/Out) Менеджер проекта, юристы \u0026ldquo;Что конкретно мы получим за эти деньги? Где границы работ?\u0026rdquo; 3. Архитектурная схема Технический директор (CTO) \u0026ldquo;Как это будет сделано? Насколько это надежно и совместимо?\u0026rdquo; 4. Детальная смета и план Финансовый директор (CFO) \u0026ldquo;Почему это столько стоит? Каков план платежей и сроки?\u0026rdquo; 5. Профессиональная презентация Всех стейкхолдеров \u0026ldquo;Почему мы должны доверять именно этой команде?\u0026rdquo; 4. Диаграмма \u0026ldquo;Процесс валидации ТКП\u0026rdquo; Эта диаграмма показывает, как мы проходим через всех ключевых лиц для получения итогового согласия.\ngraph TD A[Готовое ТКП] --\u0026gt; B{Презентация и защита\u0026lt;br\u0026gt;перед всеми стейкхолдерами клиента}; B -- \u0026#34;Как это будет работать?\u0026#34; --\u0026gt; C[\u0026lt;b\u0026gt;Техническая валидация\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;Обсуждаем архитектуру с CTO]; B -- \u0026#34;Сколько это стоит?\u0026#34; --\u0026gt; D[\u0026lt;b\u0026gt;Финансовая валидация\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;Обсуждаем смету и ROI с CFO]; B -- \u0026#34;Что это нам даст?\u0026#34; --\u0026gt; E[\u0026lt;b\u0026gt;Бизнес-валидация\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;Обсуждаем выгоды и сроки с ЛПР]; C \u0026amp; D \u0026amp; E --\u0026gt; F{Получаем принципиальное согласие\u0026lt;br\u0026gt;от всех ключевых лиц}; F -- \u0026#34;Да, нас все устраивает\u0026#34; --\u0026gt; G[\u0026#34;\u0026lt;strong\u0026gt;Решение валидировано\u0026lt;/strong\u0026gt;\u0026lt;br\u0026gt;(Контракт уходит на подписание)\u0026#34;]; F -- \u0026#34;Нужны правки в X\u0026#34; --\u0026gt; A; Глава 8.1: Прототипирование. Визуализируем идею для клиента 1. Ключевые идеи из курса (Прототип для проверки гипотез) Автор курса представляет прототипирование как ключевой шаг в процессе Discovery. Основная идея — быстро и с минимальными затратами создать черновик решения, чтобы:\nПроверить гипотезы: Действительно ли предложенное решение работает и решает проблему пользователя. Получить обратную связь: Собрать мнения от пользователей до начала дорогостоящей разработки. Снизить риски: Избежать создания продукта, который никому не нужен или неудобен. Курс обещает подробно рассмотреть различные типы прототипов, техники их создания и, что особенно важно, процесс тестирования прототипов с пользователями.\n2. Наша цель — прототип как инструмент продажи В условиях пресейла у нас нет возможности проводить полноценное тестирование прототипов с конечными пользователями. Наша цель не в том, чтобы проверить гипотезу о поведении пользователя, а в том, чтобы визуализировать наше предложение для клиента.\nДля нас прототип — это мощный инструмент коммуникации и продажи. Его основная задача:\nСделать идею осязаемой: Перевести абстрактные слова и схемы в нечто, что можно увидеть и потрогать (даже если это просто кликабельный макет). Согласовать ожидания: Убедиться, что клиент и мы одинаково понимаем, как будет выглядеть и работать будущее решение. Убедить клиента: Показать, что мы не только понимаем его проблему, но и знаем, как ее решить, и можем это наглядно продемонстрировать. Снизить риски недопонимания: Лучше показать и получить обратную связь на макете, чем на готовом продукте. Таким образом, для нас прототип — это не \u0026ldquo;тест\u0026rdquo;, а \u0026ldquo;демонстрация\u0026rdquo;.\n3. Сравнение целей прототипирования Аспект Классический подход (Продуктовая компания) Наш подход (Сервисная компания) Основная цель Проверить гипотезу о пользователе, получить обратную связь. Визуализировать идею для клиента, согласовать ожидания, убедить в нашей экспертизе. Кому показываем? Конечным пользователям, фокус-группам. Ключевым стейкхолдерам клиента (ЛПР, руководителям отделов). Что проверяем? Поведение пользователя, удобство, ценность фичи. Понимание клиента, его согласие с нашим видением, отсутствие критических возражений. Результат Подтвержденная/опровергнутая гипотеза, итерации дизайна. Согласованное видение, повышение шансов на подписание контракта. 4. Диаграмма \u0026ldquo;Путь прототипа к контракту\u0026rdquo; Эта диаграмма показывает, как прототип становится частью нашего пресейл-процесса.\ngraph TD A[\u0026#34;Идея решения\u0026lt;br\u0026gt;(из архитектурного эскиза)\u0026#34;] --\u0026gt; B{\u0026#34;Создаем прототип\u0026lt;br\u0026gt;(макет, PoC)\u0026#34;}; B --\u0026gt; C[Демонстрируем прототип\u0026lt;br\u0026gt;ключевым стейкхолдерам клиента]; C -- \u0026#34;Понятно, это то, что нужно!\u0026#34; --\u0026gt; D[Клиент соглашается с видением]; D --\u0026gt; E[\u0026lt;strong\u0026gt;Подписание контракта\u0026lt;/strong\u0026gt;]; C -- \u0026#34;Непонятно / Не совсем то\u0026#34; --\u0026gt; B(Итерация прототипа) Глава 8.2: Зачем использовать прототипирование? Наши причины 1. Ключевые идеи из курса (Причины для продуктовой компании) Автор курса утверждает, что прототипирование — это не опциональный, а критически важный шаг. Он приводит следующие аргументы в пользу прототипирования:\nСокращение времени и затрат: Выявление и исправление проблем на этапе прототипа значительно дешевле, чем после полноценной разработки. Ранняя обратная связь: Получение фидбека от пользователей до больших инвестиций в разработку. Повышение вовлеченности пользователей: Вовлечение пользователей в процесс прототипирования увеличивает их лояльность и готовность использовать продукт. Улучшение коммуникации: Прототип служит общим языком для команды и стейкхолдеров. Все эти причины сводятся к снижению рисков разработки и повышению шансов на успех продукта на рынке.\n2. Наши причины (Прототип как инструмент продажи) Для нас, как для сервисной компании, прототипирование имеет совершенно иные, но не менее важные причины. Мы используем прототип не для снижения рисков разработки (это произойдет позже, на этапе проекта), а для снижения рисков продажи и повышения ее эффективности.\nВот наши главные причины использовать прототипирование на пресейле:\nУскорение продажи: Прототип позволяет быстрее донести сложную идею до клиента и получить его согласие. Это сокращает цикл сделки, так как клиент быстрее принимает решение. Снижение рисков недопонимания: Слова и схемы могут быть интерпретированы по-разному. Прототип — это визуальный язык, который исключает разночтения и гарантирует, что мы и клиент одинаково понимаем, что будет сделано. Повышение доверия и демонстрация экспертизы: Создание прототипа показывает клиенту нашу серьезность, профессионализм и способность не только говорить, но и делать. Это укрепляет его доверие к нам как к партнеру. Обоснование цены: Когда клиент видит, как будет выглядеть и работать решение, он лучше понимает его ценность и готов платить за нее. Прототип помогает обосновать стоимость проекта. Инструмент для сбора уточняющих требований: В процессе демонстрации прототипа клиент часто сам формулирует новые, более точные требования или замечает нюансы, которые не были озвучены ранее. Это позволяет нам уточнить скоуп до подписания контракта. 3. Сравнение выгод от прототипирования Выгода Классический подход (Продуктовая компания) Наш подход (Сервисная компания) Экономия ресурсов Не тратим деньги на разработку ненужных фич. Не тратим время на бесконечные переговоры и переделки ТКП. Улучшение коммуникации Между дизайнерами, разработчиками, продакт-менеджерами. Между нами и клиентом, а также внутри команды клиента. Ранняя обратная связь От конечных пользователей. От ключевых стейкхолдеров клиента (ЛПР, руководителей отделов). Снижение рисков Создать невостребованный продукт. Не продать проект из-за недопонимания или отсутствия наглядности. 4. Диаграмма \u0026ldquo;Ценность прототипа в пресейле\u0026rdquo; Эта диаграмма показывает, как прототип становится катализатором для принятия решения клиентом.\ngraph TD A[Абстрактное описание решения] --\u0026gt; B{Создание прототипа}; B --\u0026gt; C[Визуализация идеи для клиента]; C --\u0026gt; D[Согласование ожиданий и устранение недопониманий]; D --\u0026gt; E[Повышение доверия к нашей экспертизе]; E --\u0026gt; F[Ускорение процесса принятия решения клиентом]; F --\u0026gt; G[\u0026lt;strong\u0026gt;Подписание контракта\u0026lt;/strong\u0026gt;]; Глава 8.3: Типы прототипов. Выбираем подходящий для продажи 1. Ключевые идеи из курса (Классификация прототипов) Автор отмечает, что в индустрии нет единой классификации прототипов, но выделяет основные типы:\nLow-fidelity (Низкая детализация): Самый простой и быстрый тип. Обычно это бумажные наброски или простые макеты без функциональности. Цель — быстро проверить концепцию. High-fidelity (Высокая детализация): Прототипы, максимально приближенные к финальному продукту по внешнему виду и функциональности. Требуют больше времени и ресурсов. Live Data Prototypes: Прототипы, работающие с реальными данными. Feasibility Prototypes: Прототипы для проверки технической реализуемости (аналог PoC). Ключевая мысль: выбор типа прототипа зависит от целей и стадии проекта.\n2. Наши типы прототипов для пресейла Для нас выбор типа прототипа определяется двумя факторами: целью демонстрации и доступным временем/бюджетом на пресейл. Мы всегда стремимся к максимальной наглядности при минимальных затратах.\nСкетч / Бумажный прототип (Low-fidelity):\nОписание: Быстрые наброски на бумаге, доске или в Miro. Показывают общую структуру и последовательность экранов. Когда используем: Для внутренних обсуждений, очень ранних идей, или когда нужно быстро зафиксировать логику взаимодействия с клиентом прямо на встрече. Цель: Согласовать общую концепцию, не тратя время на детали. Кликабельный макет (Mid-fidelity):\nОписание: Интерактивный макет, созданный в специализированных программах (Figma, Axure). Имитирует переходы между экранами, но без реальной логики и данных. Может быть стилизован под будущий UI. Когда используем: Наш основной рабочий инструмент для демонстрации клиенту. Позволяет наглядно показать пользовательский путь, согласовать UI/UX и получить конкретную обратную связь. Цель: Визуализировать пользовательский опыт, согласовать внешний вид и логику взаимодействия. Визуальный макет (High-fidelity):\nОписание: Полноценный дизайн, максимально приближенный к финальному продукту по внешнему виду, но без функциональности. Часто это просто набор статичных картинок. Когда используем: Редко, только для очень дорогих и сложных проектов, где важен каждый пиксель, или когда клиент очень требователен к дизайну. Требует привлечения дизайнера. Цель: Продать идею через безупречный внешний вид. Технический Proof of Concept (PoC):\nОписание: Минимально работающий код, демонстрирующий ключевую техническую возможность или интеграцию. Может быть без UI. Когда используем: Когда есть критическая техническая гипотеза, которую нужно проверить до подписания контракта (например, возможность интеграции с уникальной системой клиента, производительность сложного алгоритма). Цель: Снять технические риски, доказать реализуемость решения. 3. Таблица: Какой прототип для какой задачи? Тип прототипа Описание Когда используем (наша цель) Инструменты Скетч / Бумажный прототип Быстрые наброски на бумаге или доске. Для внутренних обсуждений, очень ранних идей, фиксации логики на встрече. Бумага, доска, Miro. Кликабельный макет (Mid-fidelity) Интерактивный макет, имитирующий переходы между экранами. Наш основной инструмент. Для демонстрации клиенту, согласования UI/UX, сбора уточнений. Figma, Axure, Sketch, Adobe XD. Визуальный макет (High-fidelity) Полноценный дизайн, максимально приближенный к финальному продукту. Для очень дорогих проектов, где важен каждый пиксель и клиент требователен к дизайну. Figma, Sketch, Adobe XD, Photoshop. Технический Proof of Concept (PoC) Минимально работающий код, демонстрирующий ключевую техническую возможность. Для проверки критических технических гипотез (интеграция, производительность, совместимость). Любой язык программирования, тестовые стенды. 4. Диаграмма \u0026ldquo;Выбор прототипа для пресейла\u0026rdquo; Эта диаграмма поможет быстро определить, какой тип прототипа нужен для конкретной ситуации.\ngraph TD A[Есть критическая техническая гипотеза,\u0026lt;br\u0026gt;которую нужно проверить?] -- Да --\u0026gt; B[Создаем \u0026lt;b\u0026gt;Технический PoC\u0026lt;/b\u0026gt;]; A -- Нет --\u0026gt; C[Нужна демонстрация UI/UX\u0026lt;br\u0026gt;для согласования с клиентом?]; C -- Да --\u0026gt; D[Создаем \u0026lt;b\u0026gt;Кликабельный макет\u0026lt;/b\u0026gt;]; C -- Нет --\u0026gt; E[Достаточно \u0026lt;b\u0026gt;Скетча / Бумажного прототипа\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;для внутренних целей или быстрой фиксации]; B --\u0026gt; F[Презентация клиенту]; D --\u0026gt; F; E --\u0026gt; F; Глава 8.4: Техники прототипирования. Как быстро сделать наглядный прототип 1. Ключевые идеи из курса (Разнообразие техник) Автор описывает несколько техник прототипирования, каждая из которых имеет свои преимущества и недостатки:\nБумажные прототипы (Paper Prototypes): Самый быстрый и дешевый способ. Используется на ранних стадиях для проверки концепции. Недостаток — отсутствие интерактивности. Вайрфреймы (Wireframes): Схематичные макеты, созданные в специализированных программах. Фокусируются на структуре и расположении элементов, без деталей дизайна. Помогают согласовать структуру. Мокапы (Mockups): Статичные, но уже визуально проработанные макеты. Показывают, как будет выглядеть интерфейс, но без интерактивности. Интерактивные прототипы (Interactive Prototypes): Макеты, имитирующие реальное взаимодействие с продуктом. Позволяют пользователю \u0026ldquo;потрогать\u0026rdquo; интерфейс. Требуют больше времени на создание. Курс подчеркивает, что выбор техники зависит от стадии проекта и требуемой детализации.\n2. Наши техники для пресейла Для нас выбор техники прототипирования определяется необходимостью максимальной наглядности при минимальных затратах времени и ресурсов. Мы не стремимся к идеальному продукту, а к убедительной демонстрации.\nСкетчинг / Бумажное прототипирование:\nОписание: Быстрые наброски интерфейса на бумаге, доске или в Miro. Могут быть очень грубыми. Когда используем: Для внутренних обсуждений, фиксации идей на лету во время воркшопа с клиентом. Позволяет быстро проверить, правильно ли мы поняли логику взаимодействия. Инструменты: Бумага, маркеры, Miro, Figma (режим Freehand). Вайрфрейминг (Wireframing):\nОписание: Схематичные макеты, фокусирующиеся на структуре и расположении элементов интерфейса. Обычно черно-белые, без деталей дизайна. Когда используем: Для согласования структуры и логики интерфейса с клиентом, когда не нужно отвлекать его на цвета и шрифты. Помогает убедиться, что все необходимые элементы присутствуют и расположены логично. Инструменты: Figma, Axure, Balsamiq. Кликабельные макеты (Interactive Mockups):\nОписание: Интерактивные прототипы, созданные в специализированных программах. Имитируют переходы между экранами, нажатия кнопок, заполнение форм. Могут быть как низкодетализированными (вайрфреймы с интерактивностью), так и высокодетализированными (с элементами дизайна). Когда используем: Наш основной инструмент для демонстрации клиенту. Позволяет наглядно показать пользовательский путь, согласовать UI/UX и получить конкретную обратную связь. Создает ощущение \u0026ldquo;живого\u0026rdquo; продукта. Инструменты: Figma (режим Prototype), Axure, Adobe XD. Технический Proof of Concept (PoC):\nОписание: Минимально работающий код, демонстрирующий ключевую техническую возможность или интеграцию. Может быть без UI или с очень простым UI. Когда используем: Для проверки критических технических гипотез (например, возможность интеграции с уникальной системой клиента, производительность сложного алгоритма, работа с новым оборудованием IoT). Инструменты: Любой язык программирования, IDE, тестовые стенды. 3. Таблица: Техники и их применение Техника Описание Когда используем (наша цель) Инструменты Скетчинг / Бумажное прототипирование Быстрые наброски интерфейса на бумаге или доске. Для внутренних обсуждений, фиксации идей на лету. Бумага, маркеры, Miro. Вайрфрейминг (Wireframing) Схематичные макеты, фокусирующиеся на структуре и расположении элементов. Для согласования структуры интерфейса с клиентом, без отвлечения на дизайн. Figma, Axure, Balsamiq. Кликабельные макеты (Interactive Mockups) Интерактивные прототипы, имитирующие переходы между экранами. Наш основной инструмент. Для демонстрации клиенту, согласования UI/UX. Figma, Axure, Adobe XD. Технический Proof of Concept (PoC) Минимально работающий код, демонстрирующий ключевую техническую возможность. Для проверки критических технических гипотез. Любой язык программирования, IDE. 4. Диаграмма \u0026ldquo;Процесс создания прототипа для пресейла\u0026rdquo; graph TD A[Согласованный скоуп и архитектура] --\u0026gt; B{Выбираем технику прототипирования\u0026lt;br\u0026gt;исходя из цели и бюджета пресейла}; B -- Нужна демонстрация UI/UX? --\u0026gt; C[Создаем \u0026lt;b\u0026gt;Кликабельный макет\u0026lt;/b\u0026gt;\u0026lt;br\u0026gt;или \u0026lt;b\u0026gt;Вайрфрейм\u0026lt;/b\u0026gt;]; B -- Нужна техническая проверка? --\u0026gt; D[Создаем \u0026lt;b\u0026gt;Технический PoC\u0026lt;/b\u0026gt;]; C --\u0026gt; E[Демонстрация клиенту]; D --\u0026gt; E; E --\u0026gt; F[Получение обратной связи и\u0026lt;br\u0026gt;уточнение требований]; Глава 8.5: Подготовка вопросов. Что спрашивать у клиента при демонстрации прототипа 1. Ключевые идеи из курса (Вопросы для пользовательского тестирования) Автор подчеркивает важность правильных вопросов для эффективного тестирования прототипов. Он предлагает список из 30 вопросов, разделенных на категории:\nОбщее впечатление: Вопросы о первом впечатлении и общем восприятии прототипа. Юзабилити-тестирование: Вопросы о простоте использования, навигации, понятности интерфейса. Вопросы, специфичные для задачи: Вопросы, связанные с выполнением конкретных сценариев (например, \u0026ldquo;Пожалуйста, купите продукт из каталога\u0026rdquo;). Ключевые рекомендации: не перегружать пользователя вопросами (3-5 вопросов на задачу), фокусироваться на конкретных сценариях. Цель — получить обратную связь для улучшения продукта.\n2. Наш подход — «Вопросы для согласования» Мы не проводим \u0026ldquo;тестирование\u0026rdquo; в классическом смысле, так как у нас нет доступа к конечным пользователям. Мы проводим демонстрацию прототипа ключевым стейкхолдерам клиента.\nНаши вопросы направлены не на выявление проблем юзабилити (это задача уже на этапе разработки), а на получение подтверждения, что прототип соответствует ожиданиям клиента, и на выявление любых недопониманий или новых требований, которые могут повлиять на скоуп и оценку.\nМы задаем вопросы, которые помогают нам:\nУточнить скоуп: Правильно ли мы поняли функциональность? Подтвердить ценность: Видит ли клиент, как это решение поможет его бизнесу? Снять возражения: Есть ли что-то, что вызывает сомнения или не устраивает? Получить согласие: Готов ли клиент двигаться дальше? 3. Чек-лист вопросов для демонстрации прототипа клиенту Этот чек-лист поможет вам провести эффективную демонстрацию и получить нужную информацию.\nКатегория вопросов Примеры Цель Общее впечатление и соответствие ожиданиям \u0026ldquo;Насколько это соответствует вашему видению решения проблемы X?\u0026quot;\n\u0026ldquo;Что вам больше всего понравилось/не понравилось в том, что вы увидели?\u0026quot;\n\u0026ldquo;Есть ли что-то, что вас удивило или не совпало с ожиданиями?\u0026rdquo; Получить общую оценку, понять, насколько мы попали в цель и насколько наше видение совпадает с видением клиента. Функциональность и логика \u0026ldquo;Как бы вы ожидали, что эта кнопка/функция будет работать?\u0026quot;\n\u0026ldquo;Есть ли что-то, что, по вашему мнению, здесь отсутствует или, наоборот, лишнее?\u0026quot;\n\u0026ldquo;Насколько логичным кажется вам этот пользовательский путь?\u0026rdquo; Уточнить функциональные требования, выявить пробелы или избыточность, подтвердить логику взаимодействия. Бизнес-ценность \u0026ldquo;Как, по вашему мнению, это решение повлияет на процесс Y в вашем отделе?\u0026quot;\n\u0026ldquo;Какие метрики, по вашему мнению, улучшатся благодаря этому решению?\u0026quot;\n\u0026ldquo;Насколько это решение поможет вам достичь ваших бизнес-целей?\u0026rdquo; Подтвердить бизнес-ценность решения, получить аргументы для коммерческого предложения, убедиться, что клиент видит выгоду. Технические аспекты (для PoC) \u0026ldquo;Насколько это решение соответствует вашим требованиям к безопасности/производительности?\u0026quot;\n\u0026ldquo;Есть ли какие-то технические ограничения или особенности вашей инфраструктуры, которые мы не учли?\u0026rdquo; Подтвердить техническую реализуемость, выявить скрытые риски или дополнительные требования к интеграции. Дальнейшие шаги \u0026ldquo;Что, по вашему мнению, должно произойти дальше?\u0026quot;\n\u0026ldquo;Есть ли еще кто-то в вашей компании, кому нужно показать этот прототип?\u0026quot;\n\u0026ldquo;Какие у вас есть вопросы по дальнейшему процессу?\u0026rdquo; Спланировать следующие шаги в процессе продажи, понять внутренние процессы клиента. 4. Диаграмма \u0026ldquo;Цикл обратной связи при демонстрации прототипа\u0026rdquo; graph TD A[Прототип готов] --\u0026gt; B{Демонстрация клиенту\u0026lt;br\u0026gt;и задаем вопросы}; B --\u0026gt; C[Получаем обратную связь\u0026lt;br\u0026gt;и уточнения]; C -- \u0026#34;Все отлично, двигаемся дальше!\u0026#34; --\u0026gt; D[Финализируем ТКП и готовимся к контракту]; C -- \u0026#34;Нужны правки / Есть новые идеи\u0026#34; --\u0026gt; E[Дорабатываем прототип/решение\u0026lt;br\u0026gt;и/или уточняем скоуп]; E --\u0026gt; B(Повторная демонстрация при необходимости) Глава 8.6: Процесс демонстрации прототипа. От показа к согласованию 1. Ключевые идеи из курса (Этапы тестирования) Автор предлагает 7-шаговый процесс тестирования прототипов, который включает:\nОпределение цели и скоупа тестирования: Что именно мы хотим проверить? Выбор тестировщиков: Кто будет тестировать прототип (идеальная целевая аудитория)? Создание прототипа: Выбор типа и техники прототипирования. Выбор метода тестирования: Как пользователи будут взаимодействовать с прототипом (модерируемое/немодерируемое, удаленное/личное). Проведение тестирования: Непосредственно сессии с пользователями. Анализ результатов: Сбор и интерпретация данных. Итерации: Внесение изменений в прототип/продукт на основе полученной обратной связи. Этот процесс ориентирован на получение максимально объективной обратной связи от конечных пользователей для улучшения продукта.\n2. Наш процесс — «Демонстрация и согласование» Для нас процесс гораздо менее формален и более сфокусирован на диалоге с клиентом. Мы не \u0026ldquo;тестируем\u0026rdquo; прототип, а \u0026ldquo;демонстрируем\u0026rdquo; его ключевым стейкхолдерам клиента с целью получения их согласия и уточнения деталей.\nНаш процесс состоит из следующих этапов:\nПодготовка к демонстрации:\nОпределить цель: Что мы хотим получить от этой демонстрации? (Например, подтверждение логики, согласование UI, снятие технических вопросов). Выбрать прототип: Какой тип прототипа (кликабельный макет, PoC) наилучшим образом соответствует цели. Подготовить вопросы: См. Главу 8.5. Вопросы должны быть направлены на получение конкретной обратной связи и подтверждения. Выбрать участников: Приглашаем ключевых стейкхолдеров клиента, которые принимают решения или являются экспертами в своей области. Проведение демонстрации:\nВведение: Кратко объясняем, что это за прототип, что он показывает и что мы хотим получить от встречи. Демонстрация: Показываем прототип, даем клиенту возможность \u0026ldquo;потрогать\u0026rdquo; его (если интерактивный). Активное слушание: Задаем подготовленные вопросы, внимательно слушаем ответы, фиксируем все комментарии, вопросы и возражения. Фиксация: Делаем заметки, скриншоты, записываем встречу (с разрешения клиента). Анализ и итерации:\nВнутреннее обсуждение: Наша команда (Presale инженер, Sales Manager, возможно, архитектор) обсуждает полученную обратную связь. Принятие решений: Что из полученного фидбека критично? Что можно учесть? Что выходит за рамки скоупа? Внесение правок: Корректируем прототип, архитектурный эскиз, скоуп или оценку в ТКП. Дальнейшие шаги:\nСогласование с клиентом: Если были значительные правки, возможно, потребуется повторная демонстрация. Если все хорошо — переходим к финализации ТКП и контракта. 3. Чек-лист для проведения демонстрации прототипа Этап Действия Цель 1. Подготовка Определить конкретную цель демонстрации. Выбрать наиболее подходящий тип прототипа. Подготовить список вопросов для каждого участника. Запланировать встречу с ключевыми стейкхолдерами. Максимально эффективно использовать время клиента и получить нужную информацию. 2. Проведение демонстрации Кратко представить прототип и цель встречи. Продемонстрировать ключевые сценарии. Дать клиенту возможность взаимодействовать с прототипом (если интерактивный). Задавать открытые вопросы, активно слушать, фиксировать все комментарии и возражения. Получить максимально полную и честную обратную связь, выявить недопонимания. 3. Анализ и итерации Внутренне обсудить полученную обратную связь. Определить, какие изменения необходимы в прототипе, решении или ТКП. Внести необходимые правки. Улучшить наше предложение, снять возражения, подготовиться к следующему шагу в процессе продажи. 4. Дальнейшие шаги Согласовать с клиентом следующие шаги (повторная демонстрация, отправка финального ТКП, встреча для подписания). Поддерживать динамику продажи и двигаться к заключению контракта. 4. Диаграмма \u0026ldquo;Итеративный процесс согласования\u0026rdquo; graph TD A[\u0026#34;Подготовка к демонстрации\u0026lt;br\u0026gt;(Цель, прототип, вопросы)\u0026#34;] --\u0026gt; B{Проведение демонстрации\u0026lt;br\u0026gt;и сбор обратной связи}; B -- Обратная связь\u0026lt;br\u0026gt;от клиента --\u0026gt; C[\u0026#34;Анализ и итерации\u0026lt;br\u0026gt;(Внутреннее обсуждение, корректировка)\u0026#34;]; C -- \u0026#34;Нужна повторная демонстрация?\u0026#34; --\u0026gt; B; C -- \u0026#34;Готово к финализации ТКП\u0026#34; --\u0026gt; D[Финализация ТКП\u0026lt;br\u0026gt;и подготовка к подписанию контракта]; Глава 9.1: Получение согласия и выравнивание. Наша цель — подписанный контракт 1. Ключевые идеи из курса (Внутреннее согласование) Автор курса описывает этап \u0026ldquo;Получение согласия и выравнивание\u0026rdquo; (Get buy-in and alignment) как презентацию разработанного решения внутренним стейкхолдерам компании (руководству, другим отделам) с целью получения бюджета и одобрения на дальнейшую разработку.\nКлючевые рекомендации:\nДемонстрировать прототип: Наглядно показать, как будет работать решение. Опираться на данные: Представлять количественные и качественные данные, полученные в ходе исследования и тестирования. Фокусироваться на бизнес-влиянии: Объяснять, как решение повлияет на ключевые метрики компании (например, рост использования продукта, продление лицензий). Цель — убедить внутреннее руководство в ценности решения и получить зеленый свет для его реализации.\n2. Наша цель — согласие клиента и контракт Для нас \u0026ldquo;получение согласия\u0026rdquo; — это не внутренний процесс, а финальный этап пресейла, направленный на получение официального согласия от клиента на наше предложение. Конечная цель этого этапа — подписанный контракт.\n\u0026ldquo;Выравнивание\u0026rdquo; (alignment) для нас означает не только синхронизацию видения между нами и клиентом, но и четкое закрепление всех договоренностей в юридически обязывающих документах.\nМы используем все наработки предыдущих этапов Discovery (понимание проблемы, архитектурный эскиз, оценка, прототип) для создания убедительного пакета документов и проведения финальной презентации.\n3. Ключевые документы для получения «Buy-in» от клиента Результатом этапа Discovery является не просто идея, а пакет документов, который клиент может изучить и подписать.\nДокумент Цель Ключевые разделы Коммерческое предложение (КП) Продать идею проекта, обосновать его ценность и стоимость. Описание проблемы, предлагаемое решение (с использованием принципов Working Backward), ключевые выгоды для бизнеса клиента, общая стоимость проекта, условия оплаты. Statement of Work (SOW) Четко зафиксировать скоуп работ, чтобы избежать недопониманий в будущем. Детальный In Scope (что мы делаем), Out of Scope (что мы НЕ делаем), критерии приемки, роли и ответственности сторон, сроки и этапы. План проекта (Roadmap) Показать клиенту, как будет проходить реализация проекта, основные этапы и вехи. Основные фазы проекта (Discovery, Design, Development, QA, Deployment), ключевые вехи, ориентировочные сроки, необходимые ресурсы со стороны клиента. Договор Юридически закрепить все договоренности, права и обязанности сторон. Юридические условия, финансовые обязательства, гарантии, ответственность, конфиденциальность. 4. Диаграмма \u0026ldquo;От Discovery к контракту\u0026rdquo; Эта диаграмма показывает, как все этапы Discovery ведут к финальному результату — подписанному контракту.\ngraph TD A[Результаты Discovery:\u0026lt;br\u0026gt;- Согласованный скоуп\u0026lt;br\u0026gt;- Архитектурный эскиз\u0026lt;br\u0026gt;- Оценка трудозатрат\u0026lt;br\u0026gt;- Прототип] --\u0026gt; B{Подготовка пакета документов}; B --\u0026gt; C[\u0026#34;Коммерческое предложение (КП)\u0026#34;]; B --\u0026gt; D[\u0026#34;Statement of Work (SOW)\u0026#34;]; B --\u0026gt; E[План проекта]; C \u0026amp; D \u0026amp; E --\u0026gt; F{Презентация и согласование\u0026lt;br\u0026gt;с клиентом}; F --\u0026gt; G[\u0026lt;strong\u0026gt;Подписание контракта\u0026lt;/strong\u0026gt;]; Глава 10.1: Непрерывное Discovery. Развитие отношений и допродажи 1. Ключевые идеи из курса (Постоянное улучшение продукта) Автор курса вводит концепцию \u0026ldquo;Непрерывного Discovery\u0026rdquo; (Continuous Discovery). Основная идея заключается в том, что процесс Discovery не заканчивается после начала разработки продукта. Напротив, это постоянный цикл, в котором продуктовые команды продолжают искать новую информацию о потребностях пользователей, даже когда продукт уже создается или даже запущен.\nЦели непрерывного Discovery:\nПостоянно получать свежую обратную связь от пользователей. Проверять предположения по мере развития продукта. Улучшать продукт на основе реальных данных и поведения пользователей. Снижать стоимость ошибок, выявляя их на ранних стадиях. Это позволяет продукту постоянно развиваться и оставаться актуальным на рынке.\n2. Наша адаптация — «Развитие проекта и клиента» Для нас, как для сервисной компании, концепция \u0026ldquo;непрерывного Discovery\u0026rdquo; трансформируется в постоянное развитие отношений с клиентом и поиск возможностей для расширения сотрудничества.\nПосле подписания контракта и начала реализации проекта, наша задача не заканчивается. Мы продолжаем использовать принципы Discovery, но уже для других целей:\nУправление изменениями (Change Requests): Любой запрос клиента на изменение или добавление функционала — это мини-цикл Discovery. Мы понимаем потребность, оцениваем решение, согласовываем скоуп и стоимость. Допродажи (Upsale/Cross-sale): Постоянное взаимодействие с клиентом позволяет выявлять новые \u0026ldquo;боли\u0026rdquo; и задачи, которые могут стать основой для новых проектов или расширения текущего контракта. Укрепление партнерских отношений: Мы остаемся для клиента не просто \u0026ldquo;исполнителем\u0026rdquo;, а стратегическим партнером, который постоянно ищет пути для улучшения его бизнеса. Таким образом, \u0026ldquo;непрерывное Discovery\u0026rdquo; для нас — это непрерывный процесс развития клиента и проекта.\n3. Применение принципов Discovery после контракта Те же принципы, которые мы использовали на пресейле, применимы и после подписания контракта.\nПринцип Discovery Как мы его применяем после подписания контракта Понимание потребностей Регулярные встречи с клиентом (статусные звонки, QBR), сбор обратной связи по текущему проекту, проактивное выявление новых \u0026ldquo;болей\u0026rdquo; и задач, которые могут стать основой для будущих проектов. Определение проблемы/скоупа Анализ запросов на изменения (Change Requests), формулирование новых задач для будущих фаз проекта или новых контрактов. Четкое определение границ каждой новой итерации. Поиск решений Предложение новых решений для выявленных проблем, расширение функционала, оптимизация существующих систем. Это может быть как часть текущего проекта, так и отдельное предложение. Валидация/Прототипирование Демонстрация новых фич, прототипов для будущих фаз, согласование изменений с клиентом. Это помогает убедиться, что мы на одной волне и клиент видит ценность. Получение согласия Согласование и подписание дополнительных соглашений к текущему контракту или новых контрактов на доработки и новые проекты. 4. Диаграмма \u0026ldquo;Цикл развития клиента\u0026rdquo; Эта диаграмма показывает, что подписание контракта — это не конец, а начало нового цикла взаимодействия.\ngraph TD A[Подписанный контракт] --\u0026gt; B{Реализация проекта}; B --\u0026gt; C{\u0026#34;Постоянное взаимодействие с клиентом\u0026lt;br\u0026gt;(PM, Account Manager)\u0026#34;}; C -- Выявление новых потребностей\u0026lt;br\u0026gt;и возможностей --\u0026gt; D[\u0026#34;Новый цикл Discovery\u0026lt;br\u0026gt;(для допродаж, новых проектов)\u0026#34;]; D --\u0026gt; E[Новый контракт / Доп. соглашение]; E --\u0026gt; B; Глава 11.1: Заключение. Discovery как инструмент успеха 1. Ключевые идеи из курса (Благодарность и пожелания) Автор курса благодарит за прохождение обучения и выражает уверенность, что теперь у вас есть все необходимые навыки для проведения Product Discovery. Он признает, что первый опыт может быть волнительным, но призывает применять полученные знания на практике, обещая, что только так можно стать экспертом. Автор также просит оставить отзыв о курсе.\n2. Наше заключение (Главный вывод для R\u0026amp;D/Presale) Мы тоже хотим поблагодарить вас за внимание к этой методичке. Надеемся, что она поможет вам не только понять концепцию Product Discovery, но и эффективно применять ее в вашей повседневной работе.\nГлавный вывод: Product Discovery для нас — это не просто модный термин из мира стартапов, а жизненно важный инструмент для сервисной компании. Это не про абстрактное \u0026ldquo;создание продукта\u0026rdquo;, а про конкретные шаги к успешной продаже и реализации проекта.\nИспользуя принципы Discovery, вы сможете:\nПродавать не \u0026ldquo;часы\u0026rdquo;, а решения: Позиционировать себя как эксперта, способного решить бизнес-проблемы клиента. Строить долгосрочные отношения: Завоевывать доверие клиента, становясь для него стратегическим партнером. Избегать убыточных проектов: Минимизировать риски недопонимания, раздувания скоупа и технических проблем. Повышать прибыльность: Обосновывать стоимость своих услуг и заключать более выгодные контракты. 3. Ключевые принципы нашего Discovery (Краткое резюме) Давайте еще раз вспомним основные принципы, которые мы адаптировали для нашей работы:\nФокус на клиенте: Наш \u0026ldquo;пользователь\u0026rdquo; на этапе пресейла — это бизнес-заказчик. Мы решаем его проблемы и отвечаем на его вопросы. Прагматизм: Цель — продать проект, а не найти идеальное решение. Мы ищем \u0026ldquo;достаточно хорошее\u0026rdquo; решение, которое можно оценить и реализовать. Скоуп — наше всё: Четкое определение \u0026ldquo;In Scope\u0026rdquo; и \u0026ldquo;Out of Scope\u0026rdquo; — наша главная защита от недопонимания и конфликтов. Прототип — инструмент продажи: Визуализация идеи помогает согласовать ожидания и убедить клиента. Риски — это возможности: Мы активно выявляем риски и закладываем их в план и смету, превращая потенциальные проблемы в контролируемые факторы. Контракт — главный KPI: Все наши усилия на этапе Discovery ведут к подписанию юридически обязывающего документа. 4. Призыв к действию Теперь, когда у вас есть эта методичка, ваша задача — применять полученные знания на практике. Каждый проект уникален, и вам придется адаптировать эти принципы под конкретные условия.\nНе бойтесь экспериментировать: Пробуйте разные подходы, ищите то, что лучше всего работает для вас и ваших клиентов. Делитесь опытом: Обсуждайте свои успехи и неудачи с коллегами. Учитесь друг у друга. Постоянно улучшайте: Эта методичка — живой документ. Ваши предложения и опыт помогут сделать ее еще лучше. Удачи вам в ваших проектах! Пусть каждый Discovery заканчивается подписанным контрактом и довольным клиентом.\n","permalink":"https://meshrefine.com/ru/conversations/product_discovery/","summary":"\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-11-%d0%b2%d0%b2%d0%b5%d0%b4%d0%b5%d0%bd%d0%b8%d0%b5-%d0%be%d1%82-%d1%82%d0%b5%d0%be%d1%80%d0%b8%d0%b8-%d0%ba-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%b5\"\u003eГлава 1.1: Введение. От теории к практике\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%b2%d0%b7%d0%b3%d0%bb%d1%8f%d0%b4-%d1%82%d0%b5%d0%be%d1%80%d0%b5%d1%82%d0%b8%d0%ba%d0%b0\"\u003e1. Ключевые идеи из курса (Взгляд теоретика)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d1%87%d1%82%d0%be-%d1%8d%d1%82%d0%be-%d0%b7%d0%bd%d0%b0%d1%87%d0%b8%d1%82-%d0%b4%d0%bb%d1%8f-%d0%bd%d0%b0%d1%81-%d0%b2%d0%b7%d0%b3%d0%bb%d1%8f%d0%b4-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%b0-%d0%b8%d0%b7-%d1%81%d0%b5%d1%80%d0%b2%d0%b8%d1%81%d0%bd%d0%be%d0%b9-%d0%ba%d0%be%d0%bc%d0%bf%d0%b0%d0%bd%d0%b8%d0%b8\"\u003e2. Что это значит для нас (Взгляд практика из сервисной компании)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%81%d1%80%d0%b0%d0%b2%d0%bd%d0%b8%d1%82%d0%b5%d0%bb%d1%8c%d0%bd%d0%b0%d1%8f-%d1%82%d0%b0%d0%b1%d0%bb%d0%b8%d1%86%d0%b0-%d1%86%d0%b5%d0%bb%d0%b5%d0%b9\"\u003e3. Сравнительная таблица целей\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%bd%d0%b0%d1%88-%d0%be%d1%81%d0%bd%d0%be%d0%b2%d0%bd%d0%be%d0%b9-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81\"\u003e4. Наш основной процесс\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-21-%d1%87%d1%82%d0%be-%d1%82%d0%b0%d0%ba%d0%be%d0%b5-product-discovery-%d0%be%d0%bf%d1%80%d0%b5%d0%b4%d0%b5%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%be%d0%b2\"\u003eГлава 2.1: Что такое Product Discovery? Определение для практиков\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%b0%d0%ba%d0%b0%d0%b4%d0%b5%d0%bc%d0%b8%d1%87%d0%b5%d1%81%d0%ba%d0%be%d0%b5-%d0%be%d0%bf%d1%80%d0%b5%d0%b4%d0%b5%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5\"\u003e1. Ключевые идеи из курса (Академическое определение)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d1%87%d1%82%d0%be-%d1%8d%d1%82%d0%be-%d1%82%d0%b0%d0%ba%d0%be%d0%b5-%d0%b4%d0%bb%d1%8f-%d0%bd%d0%b0%d1%81-%d1%80%d0%b0%d0%b1%d0%be%d1%87%d0%b5%d0%b5-%d0%be%d0%bf%d1%80%d0%b5%d0%b4%d0%b5%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5\"\u003e2. Что это такое для нас (Рабочее определение)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%81%d1%80%d0%b0%d0%b2%d0%bd%d0%b5%d0%bd%d0%b8%d0%b5-%d1%84%d0%be%d0%ba%d1%83%d1%81%d0%be%d0%b2-%d0%bf%d1%80%d0%b8-%d0%be%d1%86%d0%b5%d0%bd%d0%ba%d0%b5-%d1%80%d0%b8%d1%81%d0%ba%d0%be%d0%b2\"\u003e3. Сравнение фокусов при оценке рисков\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d1%82%d1%80%d0%b0%d0%bd%d1%81%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d0%b8-%d0%b7%d0%b0%d0%bf%d1%80%d0%be%d1%81%d0%b0\"\u003e4. Диаграмма трансформации запроса\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-22-%d0%b7%d0%b0%d1%87%d0%b5%d0%bc-%d0%bd%d0%b0-%d1%81%d0%b0%d0%bc%d0%be%d0%bc-%d0%b4%d0%b5%d0%bb%d0%b5-%d0%bd%d1%83%d0%b6%d0%bd%d0%be-product-discovery\"\u003eГлава 2.2: Зачем на самом деле нужно Product Discovery?\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%b0%d1%80%d0%b3%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%be%d0%b2%d0%be%d0%b9-%d0%ba%d0%be%d0%bc%d0%bf%d0%b0%d0%bd%d0%b8%d0%b8\"\u003e1. Ключевые идеи из курса (Аргументы для продуктовой компании)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d1%87%d1%82%d0%be-%d1%8d%d1%82%d0%be-%d0%b4%d0%b0%d0%b5%d1%82-%d0%bd%d0%b0%d0%bc-%d0%b0%d1%80%d0%b3%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b4%d0%bb%d1%8f-%d1%81%d0%b5%d1%80%d0%b2%d0%b8%d1%81%d0%bd%d0%be%d0%b9-%d0%ba%d0%be%d0%bc%d0%bf%d0%b0%d0%bd%d0%b8%d0%b8\"\u003e2. Что это дает нам (Аргументы для сервисной компании)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%81%d1%80%d0%b0%d0%b2%d0%bd%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b4%d0%be-%d0%b8-%d0%bf%d0%be%d1%81%d0%bb%d0%b5-%d0%b2%d0%bd%d0%b5%d0%b4%d1%80%d0%b5%d0%bd%d0%b8%d1%8f-discovery\"\u003e3. Сравнение: \u0026ldquo;До\u0026rdquo; и \u0026ldquo;После\u0026rdquo; внедрения Discovery\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d1%86%d0%b5%d0%bd%d0%bd%d0%be%d1%81%d1%82%d0%b8-%d0%b4%d0%b2%d0%b0-%d0%bf%d1%83%d1%82%d0%b8-%d0%bf%d1%80%d0%b5%d1%81%d0%b5%d0%b9%d0%bb%d0%b0\"\u003e4. Диаграмма ценности: два пути пресейла\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-23-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-product-discovery-%d1%82%d0%b5%d0%be%d1%80%d0%b8%d1%8f-%d0%b8-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%b0\"\u003eГлава 2.3: Процесс Product Discovery. Теория и практика\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%ba%d0%bb%d0%b0%d1%81%d1%81%d0%b8%d1%87%d0%b5%d1%81%d0%ba%d0%b8%d0%b9-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81\"\u003e1. Ключевые идеи из курса (Классический процесс)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%ba%d0%b0%d0%ba-%d1%8d%d1%82%d0%be%d1%82-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d0%b2%d1%8b%d0%b3%d0%bb%d1%8f%d0%b4%d0%b8%d1%82-%d1%83-%d0%bd%d0%b0%d1%81-%d0%bb%d0%b8%d0%bd%d0%b5%d0%b9%d0%bd%d1%8b%d0%b9-%d0%bf%d1%80%d0%b5%d1%81%d0%b5%d0%b9%d0%bb-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81\"\u003e2. Как этот процесс выглядит у нас (Линейный пресейл-процесс)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%81%d1%80%d0%b0%d0%b2%d0%bd%d0%b5%d0%bd%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81%d0%be%d0%b2-%d0%b2-%d0%b2%d0%b8%d0%b4%d0%b5-%d1%82%d0%b0%d0%b1%d0%bb%d0%b8%d1%86%d1%8b\"\u003e3. Сравнение процессов в виде таблицы\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%bd%d0%b0%d1%88%d0%b0-%d0%b2%d0%be%d1%80%d0%be%d0%bd%d0%ba%d0%b0-%d0%bf%d1%80%d0%b5%d1%81%d0%b5%d0%b9%d0%bb%d0%b0\"\u003e4. Наша воронка пресейла\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-31-%d0%ba%d0%be%d0%bc%d0%b0%d0%bd%d0%b4%d0%b0-%d0%b4%d0%bb%d1%8f-product-discovery-%d1%80%d0%be%d0%bb%d0%b8-%d0%b2-%d1%81%d0%b5%d1%80%d0%b2%d0%b8%d1%81%d0%bd%d0%be%d0%b9-%d0%ba%d0%be%d0%bc%d0%bf%d0%b0%d0%bd%d0%b8%d0%b8\"\u003eГлава 3.1: Команда для Product Discovery. Роли в сервисной компании\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%ba%d0%bb%d0%b0%d1%81%d1%81%d0%b8%d1%87%d0%b5%d1%81%d0%ba%d0%b0%d1%8f-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%be%d0%b2%d0%b0%d1%8f-%d0%ba%d0%be%d0%bc%d0%b0%d0%bd%d0%b4%d0%b0\"\u003e1. Ключевые идеи из курса (Классическая продуктовая команда)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d0%ba%d0%be%d0%bc%d0%b0%d0%bd%d0%b4%d0%b0-%d0%b4%d1%83%d1%8d%d1%82-%d0%bf%d1%80%d0%be%d0%b4%d0%b0%d0%b6-%d0%b8-%d1%82%d0%b5%d1%85%d0%bd%d0%be%d0%bb%d0%be%d0%b3%d0%b8%d0%b9\"\u003e2. Наша команда (Дуэт Продаж и Технологий)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%80%d0%be%d0%bb%d0%b8-%d0%b8-%d0%be%d0%b1%d1%8f%d0%b7%d0%b0%d0%bd%d0%bd%d0%be%d1%81%d1%82%d0%b8-%d0%b2-%d0%bd%d0%b0%d1%88%d0%b5%d0%b9-%d0%ba%d0%be%d0%bc%d0%b0%d0%bd%d0%b4%d0%b5\"\u003e3. Роли и обязанности в нашей команде\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%b2%d0%b7%d0%b0%d0%b8%d0%bc%d0%be%d0%b4%d0%b5%d0%b9%d1%81%d1%82%d0%b2%d0%b8%d1%8f\"\u003e4. Диаграмма взаимодействия\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-41-%d0%bf%d0%be%d0%bd%d0%b8%d0%bc%d0%b0%d0%bd%d0%b8%d0%b5-%d0%bf%d0%be%d1%82%d1%80%d0%b5%d0%b1%d0%bd%d0%be%d1%81%d1%82%d0%b5%d0%b9-%d0%ba%d0%be%d0%b3%d0%be-%d0%bc%d1%8b-%d0%bd%d0%b0-%d1%81%d0%b0%d0%bc%d0%be%d0%bc-%d0%b4%d0%b5%d0%bb%d0%b5-%d1%81%d0%bb%d1%83%d1%88%d0%b0%d0%b5%d0%bc\"\u003eГлава 4.1: Понимание потребностей. Кого мы на самом деле слушаем?\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d1%84%d0%be%d0%ba%d1%83%d1%81-%d0%bd%d0%b0-%d0%ba%d0%be%d0%bd%d0%b5%d1%87%d0%bd%d0%be%d0%bc-%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d0%be%d0%b2%d0%b0%d1%82%d0%b5%d0%bb%d0%b5\"\u003e1. Ключевые идеи из курса (Фокус на конечном пользователе)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d1%80%d0%b5%d0%b0%d0%bb%d1%8c%d0%bd%d0%be%d1%81%d1%82%d1%8c-%d1%84%d0%be%d0%ba%d1%83%d1%81-%d0%bd%d0%b0-%d0%b1%d0%b8%d0%b7%d0%bd%d0%b5%d1%81-%d0%b7%d0%b0%d0%ba%d0%b0%d0%b7%d1%87%d0%b8%d0%ba%d0%b5\"\u003e2. Наша реальность (Фокус на бизнес-заказчике)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%81%d1%80%d0%b0%d0%b2%d0%bd%d0%b5%d0%bd%d0%b8%d0%b5-%d0%be%d0%b1%d1%8a%d0%b5%d0%ba%d1%82%d0%be%d0%b2-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f\"\u003e3. Сравнение объектов исследования\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d1%81%d0%bc%d0%b5%d1%89%d0%b5%d0%bd%d0%b8%d1%8f-%d1%84%d0%be%d0%ba%d1%83%d1%81%d0%b0\"\u003e4. Диаграмма смещения фокуса\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-42-user-persona-%d0%b0%d0%b4%d0%b0%d0%bf%d1%82%d0%b8%d1%80%d1%83%d0%b5%d0%bc-%d0%b4%d0%bb%d1%8f-%d1%80%d0%b0%d0%b1%d0%be%d1%82%d1%8b-%d1%81-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%be%d0%bc\"\u003eГлава 4.2: User Persona. Адаптируем для работы с клиентом\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%bf%d0%be%d1%80%d1%82%d1%80%d0%b5%d1%82-%d0%ba%d0%be%d0%bd%d0%b5%d1%87%d0%bd%d0%be%d0%b3%d0%be-%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d0%be%d0%b2%d0%b0%d1%82%d0%b5%d0%bb%d1%8f\"\u003e1. Ключевые идеи из курса (Портрет конечного пользователя)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d0%b2%d0%b5%d1%80%d1%81%d0%b8%d1%8f--%d0%bf%d0%be%d1%80%d1%82%d1%80%d0%b5%d1%82-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d0%be%d0%b3%d0%be-%d1%81%d1%82%d0%b5%d0%b9%d0%ba%d1%85%d0%be%d0%bb%d0%b4%d0%b5%d1%80%d0%b0\"\u003e2. Наша версия — «Портрет Ключевого Стейкхолдера»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%88%d0%b0%d0%b1%d0%bb%d0%be%d0%bd-%d0%bf%d0%be%d1%80%d1%82%d1%80%d0%b5%d1%82%d0%b0-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d0%be%d0%b3%d0%be-%d1%81%d1%82%d0%b5%d0%b9%d0%ba%d1%85%d0%be%d0%bb%d0%b4%d0%b5%d1%80%d0%b0\"\u003e3. Шаблон «Портрета Ключевого Стейкхолдера»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%b2%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d1%8f-%d1%81%d1%82%d0%b5%d0%b9%d0%ba%d1%85%d0%be%d0%bb%d0%b4%d0%b5%d1%80%d0%be%d0%b2\"\u003e4. Диаграмма влияния стейкхолдеров\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-43-empathy-map-%d1%81%d1%82%d1%80%d1%83%d0%ba%d1%82%d1%83%d1%80%d0%b8%d1%80%d1%83%d0%b5%d0%bc-%d0%b8%d0%bd%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d1%8e-%d0%be%d1%82-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%b0\"\u003eГлава 4.3: Empathy Map. Структурируем информацию от клиента\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d1%81%d0%be%d0%bf%d0%b5%d1%80%d0%b5%d0%b6%d0%b8%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d0%be%d0%b2%d0%b0%d1%82%d0%b5%d0%bb%d1%8e\"\u003e1. Ключевые идеи из курса (Сопереживание пользователю)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d0%b2%d0%b5%d1%80%d1%81%d0%b8%d1%8f--%d0%ba%d0%b0%d1%80%d1%82%d0%b0-%d0%b2%d0%be%d1%80%d0%ba%d1%88%d0%be%d0%bf%d0%b0\"\u003e2. Наша версия — «Карта Воркшопа»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%88%d0%b0%d0%b1%d0%bb%d0%be%d0%bd-%d0%ba%d0%b0%d1%80%d1%82%d1%8b-%d0%b2%d0%be%d1%80%d0%ba%d1%88%d0%be%d0%bf%d0%b0\"\u003e3. Шаблон «Карты Воркшопа»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d1%82%d1%80%d0%b0%d0%bd%d1%81%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d0%b8-%d0%b8%d0%bd%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d0%b8\"\u003e4. Диаграмма трансформации информации\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-44-%d0%b8%d0%bd%d1%82%d0%b5%d1%80%d0%b2%d1%8c%d1%8e-%d1%81-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%be%d0%bc-%d0%ba%d0%b0%d0%ba-%d0%b7%d0%b0%d0%b4%d0%b0%d0%b2%d0%b0%d1%82%d1%8c-%d0%bf%d1%80%d0%b0%d0%b2%d0%b8%d0%bb%d1%8c%d0%bd%d1%8b%d0%b5-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d1%8b\"\u003eГлава 4.4: Интервью с клиентом. Как задавать правильные вопросы\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d0%be%d0%b2%d0%b0%d1%82%d0%b5%d0%bb%d0%b5%d0%b9\"\u003e1. Ключевые идеи из курса (Вопросы для пользователей)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88-%d0%bf%d0%be%d0%b4%d1%85%d0%be%d0%b4--%d1%82%d0%b5%d1%85%d0%bd%d0%b8%d1%87%d0%b5%d1%81%d0%ba%d0%b8%d0%b9-%d0%b2%d0%be%d1%80%d0%ba%d1%88%d0%be%d0%bf-%d0%b8%d0%bd%d1%82%d0%b5%d1%80%d0%b2%d1%8c%d1%8e\"\u003e2. Наш подход — «Технический воркшоп-интервью»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d0%bd%d0%b0%d1%88-%d1%87%d0%b5%d0%ba-%d0%bb%d0%b8%d1%81%d1%82-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d0%be%d0%b2-%d0%b4%d0%bb%d1%8f-%d0%b2%d0%be%d1%80%d0%ba%d1%88%d0%be%d0%bf%d0%b0-%d1%81-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%be%d0%bc\"\u003e3. Наш чек-лист вопросов для воркшопа с клиентом\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%b2%d0%be%d1%80%d0%be%d0%bd%d0%ba%d0%b0-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d0%be%d0%b2\"\u003e4. Диаграмма \u0026ldquo;Воронка вопросов\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-45-%d0%b4%d0%be%d0%bf%d0%be%d0%bb%d0%bd%d0%b8%d1%82%d0%b5%d0%bb%d1%8c%d0%bd%d1%8b%d0%b5-%d1%82%d0%b5%d1%85%d0%bd%d0%b8%d0%ba%d0%b8-%d0%b3%d0%b4%d0%b5-%d0%b5%d1%89%d0%b5-%d0%b1%d1%80%d0%b0%d1%82%d1%8c-%d0%b8%d0%bd%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d1%8e\"\u003eГлава 4.5: Дополнительные техники. Где еще брать информацию?\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7-%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d1%85-%d0%b8-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%82%d0%be%d0%b2\"\u003e1. Ключевые идеи из курса (Анализ данных и конкурентов)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b8-%d0%b8%d1%81%d1%82%d0%be%d1%87%d0%bd%d0%b8%d0%ba%d0%b8-%d0%b8%d0%bd%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d0%b8\"\u003e2. Наши источники информации\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%82%d0%b0%d0%b1%d0%bb%d0%b8%d1%86%d0%b0-%d0%b0%d0%b4%d0%b0%d0%bf%d1%82%d0%b0%d1%86%d0%b8%d0%b8-%d1%82%d0%b5%d1%85%d0%bd%d0%b8%d0%ba\"\u003e3. Таблица адаптации техник\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%bd%d0%b0%d1%88%d0%b8-%d0%b8%d1%81%d1%82%d0%be%d1%87%d0%bd%d0%b8%d0%ba%d0%b8-%d0%b8%d1%81%d1%82%d0%b8%d0%bd%d1%8b\"\u003e4. Диаграмма \u0026ldquo;Наши источники истины\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-51-%d0%be%d0%bf%d1%80%d0%b5%d0%b4%d0%b5%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b1%d0%bb%d0%b5%d0%bc%d1%8b-%d1%84%d0%be%d1%80%d0%bc%d1%83%d0%bb%d0%b8%d1%80%d1%83%d0%b5%d0%bc-%d1%81%d0%ba%d0%be%d1%83%d0%bf-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d0%b0\"\u003eГлава 5.1: Определение проблемы. Формулируем скоуп проекта\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%bf%d0%be%d0%b8%d1%81%d0%ba-%d0%b8-%d1%84%d0%be%d1%80%d0%bc%d1%83%d0%bb%d0%b8%d1%80%d0%be%d0%b2%d0%ba%d0%b0-%d0%bf%d1%80%d0%be%d0%b1%d0%bb%d0%b5%d0%bc%d1%8b\"\u003e1. Ключевые идеи из курса (Поиск и формулировка проблемы)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d1%86%d0%b5%d0%bb%d1%8c--%d0%be%d0%bf%d1%80%d0%b5%d0%b4%d0%b5%d0%bb%d0%b8%d1%82%d1%8c-%d1%81%d0%ba%d0%be%d1%83%d0%bf-%d0%b0-%d0%bd%d0%b5-%d0%bf%d1%80%d0%be%d0%b1%d0%bb%d0%b5%d0%bc%d1%83\"\u003e2. Наша цель — определить скоуп, а не «проблему»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%88%d0%b0%d0%b1%d0%bb%d0%be%d0%bd-%d0%b4%d0%bb%d1%8f-%d0%be%d0%bf%d1%80%d0%b5%d0%b4%d0%b5%d0%bb%d0%b5%d0%bd%d0%b8%d1%8f-%d1%81%d0%ba%d0%be%d1%83%d0%bf%d0%b0-scope-statement\"\u003e3. Шаблон для определения скоупа (Scope Statement)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d1%81%d1%83%d0%b6%d0%b5%d0%bd%d0%b8%d0%b5-%d1%84%d0%be%d0%ba%d1%83%d1%81%d0%b0\"\u003e4. Диаграмма \u0026ldquo;Сужение фокуса\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-52-%d0%bf%d1%80%d0%b8%d0%be%d1%80%d0%b8%d1%82%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d1%8f-%d0%ba%d0%b0%d0%ba-%d0%b4%d0%be%d0%b3%d0%be%d0%b2%d0%be%d1%80%d0%b8%d1%82%d1%8c%d1%81%d1%8f-%d1%81-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%be%d0%bc-%d0%be-mvp\"\u003eГлава 5.2: Приоритизация. Как договориться с клиентом о MVP\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d1%84%d1%80%d0%b5%d0%b9%d0%bc%d0%b2%d0%be%d1%80%d0%ba%d0%b8-%d0%b4%d0%bb%d1%8f-%d0%b1%d1%8d%d0%ba%d0%bb%d0%be%d0%b3%d0%b0\"\u003e1. Ключевые идеи из курса (Фреймворки для бэклога)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d1%86%d0%b5%d0%bb%d1%8c--%d0%bf%d1%80%d0%b8%d0%be%d1%80%d0%b8%d1%82%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d1%8f-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%be%d0%b4%d0%b0%d0%b6%d0%b8-%d0%b0-%d0%bd%d0%b5-%d0%b4%d0%bb%d1%8f-%d1%80%d0%b0%d0%b7%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%ba%d0%b8\"\u003e2. Наша цель — приоритизация для продажи, а не для разработки\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d0%b0%d0%b4%d0%b0%d0%bf%d1%82%d0%b0%d1%86%d0%b8%d1%8f-%d1%84%d1%80%d0%b5%d0%b9%d0%bc%d0%b2%d0%be%d1%80%d0%ba%d0%b0-moscow-%d0%b4%d0%bb%d1%8f-%d0%bf%d0%b5%d1%80%d0%b5%d0%b3%d0%be%d0%b2%d0%be%d1%80%d0%be%d0%b2\"\u003e3. Адаптация фреймворка MoSCoW для переговоров\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d1%81%d0%be%d0%b3%d0%bb%d0%b0%d1%81%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-mvp\"\u003e4. Диаграмма \u0026ldquo;Процесс согласования MVP\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-61-%d0%bf%d0%be%d0%b8%d1%81%d0%ba-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d0%b9-%d0%be%d1%82-%d0%ba%d1%80%d0%b5%d0%b0%d1%82%d0%b8%d0%b2%d0%b0-%d0%ba-%d0%b0%d1%80%d1%85%d0%b8%d1%82%d0%b5%d0%ba%d1%82%d1%83%d1%80%d0%bd%d0%be%d0%bc%d1%83-%d1%8d%d1%81%d0%ba%d0%b8%d0%b7%d1%83\"\u003eГлава 6.1: Поиск решений. От креатива к архитектурному эскизу\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%b2%d1%80%d0%b5%d0%bc%d1%8f-%d0%b4%d0%bb%d1%8f-%d0%ba%d1%80%d0%b5%d0%b0%d1%82%d0%b8%d0%b2%d0%b0\"\u003e1. Ключевые идеи из курса (Время для креатива)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d1%86%d0%b5%d0%bb%d1%8c--%d0%b1%d1%8b%d1%81%d1%82%d1%80%d0%be-%d0%bf%d1%80%d0%b8%d0%b9%d1%82%d0%b8-%d0%ba-%d0%be%d0%b4%d0%bd%d0%be%d0%bc%d1%83-%d1%80%d0%b0%d0%b1%d0%be%d1%87%d0%b5%d0%bc%d1%83-%d0%b2%d0%b0%d1%80%d0%b8%d0%b0%d0%bd%d1%82%d1%83\"\u003e2. Наша цель — быстро прийти к одному рабочему варианту\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%81%d1%80%d0%b0%d0%b2%d0%bd%d0%b5%d0%bd%d0%b8%d0%b5-%d0%bf%d0%be%d0%b4%d1%85%d0%be%d0%b4%d0%be%d0%b2-%d0%ba-%d0%bf%d0%be%d0%b8%d1%81%d0%ba%d1%83-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d1%8f\"\u003e3. Сравнение подходов к поиску решения\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%be%d1%82-%d0%bf%d1%80%d0%be%d0%b1%d0%bb%d0%b5%d0%bc%d1%8b-%d0%ba-%d0%be%d1%86%d0%b5%d0%bd%d0%ba%d0%b5\"\u003e4. Диаграмма \u0026ldquo;От проблемы к оценке\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-62-%d0%bc%d0%be%d0%b7%d0%b3%d0%be%d0%b2%d0%be%d0%b9-%d1%88%d1%82%d1%83%d1%80%d0%bc-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d0%b8%d1%80%d1%83%d0%b5%d0%bc-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2%d0%bc%d0%b5%d1%81%d1%82%d0%b5-%d1%81-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%be%d0%bc\"\u003eГлава 6.2: Мозговой штурм. Проектируем решение вместе с клиентом\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%ba%d0%bb%d0%b0%d1%81%d1%81%d0%b8%d1%87%d0%b5%d1%81%d0%ba%d0%b8%d0%b9-%d0%bc%d0%be%d0%b7%d0%b3%d0%be%d0%b2%d0%be%d0%b9-%d1%88%d1%82%d1%83%d1%80%d0%bc\"\u003e1. Ключевые идеи из курса (Классический мозговой штурм)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88-%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%82--%d0%b0%d1%80%d1%85%d0%b8%d1%82%d0%b5%d0%ba%d1%82%d1%83%d1%80%d0%bd%d1%8b%d0%b9-%d0%b2%d0%be%d1%80%d0%ba%d1%88%d0%be%d0%bf\"\u003e2. Наш формат — «Архитектурный воркшоп»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d0%bf%d1%80%d0%b0%d0%b2%d0%b8%d0%bb%d0%b0-%d0%bd%d0%b0%d1%88%d0%b5%d0%b3%d0%be-%d0%b0%d1%80%d1%85%d0%b8%d1%82%d0%b5%d0%ba%d1%82%d1%83%d1%80%d0%bd%d0%be%d0%b3%d0%be-%d0%b2%d0%be%d1%80%d0%ba%d1%88%d0%be%d0%bf%d0%b0\"\u003e3. Правила нашего «Архитектурного воркшопа»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d0%b2%d0%be%d1%80%d0%ba%d1%88%d0%be%d0%bf%d0%b0\"\u003e4. Диаграмма \u0026ldquo;Процесс воркшопа\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-63-mind-map-%d0%b4%d0%b5%d0%ba%d0%be%d0%bc%d0%bf%d0%be%d0%b7%d0%b8%d1%80%d1%83%d0%b5%d0%bc-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b4%d0%bb%d1%8f-%d0%be%d1%86%d0%b5%d0%bd%d0%ba%d0%b8\"\u003eГлава 6.3: Mind Map. Декомпозируем решение для оценки\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%ba%d0%b0%d1%80%d1%82%d0%b0-%d0%b4%d0%bb%d1%8f-%d0%b8%d0%b4%d0%b5%d0%b9\"\u003e1. Ключевые идеи из курса (Карта для идей)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88-%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%82--%d0%ba%d0%b0%d1%80%d1%82%d0%b0-%d1%80%d0%b0%d0%b1%d0%be%d1%82-work-breakdown-structure\"\u003e2. Наш формат — «Карта работ» (Work Breakdown Structure)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d0%bf%d1%80%d0%b8%d0%bc%d0%b5%d1%80-%d0%bd%d0%b0%d1%88%d0%b5%d0%b9-%d0%ba%d0%b0%d1%80%d1%82%d1%8b-%d1%80%d0%b0%d0%b1%d0%be%d1%82\"\u003e3. Пример нашей «Карты работ»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%be%d1%82-%d0%ba%d0%b0%d1%80%d1%82%d1%8b-%d1%80%d0%b0%d0%b1%d0%be%d1%82-%d0%ba-%d0%b8%d1%82%d0%be%d0%b3%d0%be%d0%b2%d0%be%d0%b9-%d0%be%d1%86%d0%b5%d0%bd%d0%ba%d0%b5\"\u003e4. От Карты работ к итоговой оценке\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-64-working-backward-%d0%be%d0%bf%d0%b8%d1%81%d1%8b%d0%b2%d0%b0%d0%b5%d0%bc-%d1%86%d0%b5%d0%bb%d0%b8-%d0%b8-%d0%b2%d0%b8%d0%b4%d0%b5%d0%bd%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d0%b0\"\u003eГлава 6.4: Working Backward. Описываем цели и видение проекта\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d1%82%d0%b5%d1%85%d0%bd%d0%b8%d0%ba%d0%b0-amazon\"\u003e1. Ключевые идеи из курса (Техника Amazon)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d0%b0%d0%b4%d0%b0%d0%bf%d1%82%d0%b0%d1%86%d0%b8%d1%8f--%d0%be%d0%bf%d0%b8%d1%81%d0%b0%d0%bd%d0%b8%d0%b5-%d0%b1%d1%83%d0%b4%d1%83%d1%89%d0%b5%d0%b3%d0%be-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b2-%d1%82%d0%ba%d0%bf\"\u003e2. Наша адаптация — «Описание будущего решения» в ТКП\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%88%d0%b0%d0%b1%d0%bb%d0%be%d0%bd-%d0%be%d0%bf%d0%b8%d1%81%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b1%d1%83%d0%b4%d1%83%d1%89%d0%b5%d0%b3%d0%be-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d1%8f\"\u003e3. Шаблон «Описания будущего решения»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%be%d1%82-%d0%b2%d0%b8%d0%b4%d0%b5%d0%bd%d0%b8%d1%8f-%d0%ba-%d1%80%d0%b5%d0%b0%d0%bb%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d0%b8\"\u003e4. Диаграмма \u0026ldquo;От видения к реализации\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-65-role-storming-%d0%bf%d1%80%d0%be%d0%b2%d0%b5%d1%80%d1%8f%d0%b5%d0%bc-%d0%bd%d0%b0%d1%88%d0%b5-%d0%bf%d1%80%d0%b5%d0%b4%d0%bb%d0%be%d0%b6%d0%b5%d0%bd%d0%b8%d0%b5-%d0%bd%d0%b0-%d0%bf%d1%80%d0%be%d1%87%d0%bd%d0%be%d1%81%d1%82%d1%8c\"\u003eГлава 6.5: Role-Storming. Проверяем наше предложение на прочность\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d1%88%d1%82%d1%83%d1%80%d0%bc-%d0%b2-%d1%80%d0%be%d0%bb%d0%b8-%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d0%be%d0%b2%d0%b0%d1%82%d0%b5%d0%bb%d1%8f\"\u003e1. Ключевые идеи из курса (Штурм в роли пользователя)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d0%b0%d0%b4%d0%b0%d0%bf%d1%82%d0%b0%d1%86%d0%b8%d1%8f--%d0%bf%d1%80%d0%b5%d0%b4%d0%b7%d0%b0%d1%89%d0%b8%d1%82%d0%b0-%d0%ba%d0%be%d0%bc%d0%bc%d0%b5%d1%80%d1%87%d0%b5%d1%81%d0%ba%d0%be%d0%b3%d0%be-%d0%bf%d1%80%d0%b5%d0%b4%d0%bb%d0%be%d0%b6%d0%b5%d0%bd%d0%b8%d1%8f\"\u003e2. Наша адаптация — «Предзащита коммерческого предложения»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%81%d1%86%d0%b5%d0%bd%d0%b0%d1%80%d0%b8%d0%b9-%d0%bf%d1%80%d0%b5%d0%b4%d0%b7%d0%b0%d1%89%d0%b8%d1%82%d1%8b-%d1%82%d0%ba%d0%bf\"\u003e3. Сценарий «Предзащиты ТКП»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d1%86%d0%b8%d0%ba%d0%bb-%d1%83%d1%81%d0%b8%d0%bb%d0%b5%d0%bd%d0%b8%d1%8f-%d0%bf%d1%80%d0%b5%d0%b4%d0%bb%d0%be%d0%b6%d0%b5%d0%bd%d0%b8%d1%8f\"\u003e4. Диаграмма \u0026ldquo;Цикл усиления предложения\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-66-%d1%82%d0%b5%d1%85%d0%bd%d0%b8%d0%ba%d0%b0-%d1%87%d1%82%d0%be-%d0%b5%d1%81%d0%bb%d0%b8-%d0%b2%d1%8b%d1%8f%d0%b2%d0%bb%d1%8f%d0%b5%d0%bc-%d0%b8-%d0%be%d1%82%d1%80%d0%b0%d0%b1%d0%b0%d1%82%d1%8b%d0%b2%d0%b0%d0%b5%d0%bc-%d1%80%d0%b8%d1%81%d0%ba%d0%b8\"\u003eГлава 6.6: Техника \u0026ldquo;Что, если?\u0026rdquo;. Выявляем и отрабатываем риски\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%b3%d0%b5%d0%bd%d0%b5%d1%80%d0%b0%d1%86%d0%b8%d1%8f-%d0%b8%d0%b4%d0%b5%d0%b9-%d1%87%d0%b5%d1%80%d0%b5%d0%b7-%d0%be%d0%b3%d1%80%d0%b0%d0%bd%d0%b8%d1%87%d0%b5%d0%bd%d0%b8%d1%8f\"\u003e1. Ключевые идеи из курса (Генерация идей через ограничения)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d0%b0%d0%b4%d0%b0%d0%bf%d1%82%d0%b0%d1%86%d0%b8%d1%8f--%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7-%d1%80%d0%b8%d1%81%d0%ba%d0%be%d0%b2\"\u003e2. Наша адаптация — «Анализ рисков»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d0%bd%d0%b0%d1%88-%d1%87%d0%b5%d0%ba-%d0%bb%d0%b8%d1%81%d1%82-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d0%be%d0%b2-%d1%87%d1%82%d0%be-%d0%b5%d1%81%d0%bb%d0%b8-%d0%b4%d0%bb%d1%8f-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7%d0%b0-%d1%80%d0%b8%d1%81%d0%ba%d0%be%d0%b2\"\u003e3. Наш чек-лист вопросов \u0026ldquo;Что, если?\u0026rdquo; для анализа рисков\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%be%d1%82-%d1%80%d0%b8%d1%81%d0%ba%d0%b0-%d0%ba-%d0%bf%d0%bb%d0%b0%d0%bd%d1%83\"\u003e4. Диаграмма \u0026ldquo;От риска к плану\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-71-%d0%b2%d0%b0%d0%bb%d0%b8%d0%b4%d0%b0%d1%86%d0%b8%d1%8f-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b7%d0%b0%d1%89%d0%b8%d1%89%d0%b0%d0%b5%d0%bc-%d0%ba%d0%be%d0%bc%d0%bc%d0%b5%d1%80%d1%87%d0%b5%d1%81%d0%ba%d0%be%d0%b5-%d0%bf%d1%80%d0%b5%d0%b4%d0%bb%d0%be%d0%b6%d0%b5%d0%bd%d0%b8%d0%b5\"\u003eГлава 7.1: Валидация решения. Защищаем коммерческое предложение\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%b2%d1%81%d0%b5%d1%81%d1%82%d0%be%d1%80%d0%be%d0%bd%d0%bd%d1%8f%d1%8f-%d0%bf%d1%80%d0%be%d0%b2%d0%b5%d1%80%d0%ba%d0%b0\"\u003e1. Ключевые идеи из курса (Всесторонняя проверка)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d0%b2%d0%b0%d0%bb%d0%b8%d0%b4%d0%b0%d1%86%d0%b8%d1%8f--%d1%8d%d1%82%d0%be-%d1%83%d1%81%d0%bf%d0%b5%d1%88%d0%bd%d0%b0%d1%8f-%d0%b7%d0%b0%d1%89%d0%b8%d1%82%d0%b0-%d1%82%d0%ba%d0%bf\"\u003e2. Наша валидация — это успешная защита ТКП\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%87%d0%b5%d0%ba-%d0%bb%d0%b8%d1%81%d1%82-%d0%b4%d0%bb%d1%8f-%d1%83%d1%81%d0%bf%d0%b5%d1%88%d0%bd%d0%be%d0%b9-%d0%b7%d0%b0%d1%89%d0%b8%d1%82%d1%8b-%d0%b2%d0%b0%d0%bb%d0%b8%d0%b4%d0%b0%d1%86%d0%b8%d0%b8-%d1%82%d0%ba%d0%bf\"\u003e3. Чек-лист для успешной защиты (валидации) ТКП\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d0%b2%d0%b0%d0%bb%d0%b8%d0%b4%d0%b0%d1%86%d0%b8%d0%b8-%d1%82%d0%ba%d0%bf\"\u003e4. Диаграмма \u0026ldquo;Процесс валидации ТКП\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-81-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%b2%d0%b8%d0%b7%d1%83%d0%b0%d0%bb%d0%b8%d0%b7%d0%b8%d1%80%d1%83%d0%b5%d0%bc-%d0%b8%d0%b4%d0%b5%d1%8e-%d0%b4%d0%bb%d1%8f-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%b0\"\u003eГлава 8.1: Прототипирование. Визуализируем идею для клиента\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%be%d0%b2%d0%b5%d1%80%d0%ba%d0%b8-%d0%b3%d0%b8%d0%bf%d0%be%d1%82%d0%b5%d0%b7\"\u003e1. Ключевые идеи из курса (Прототип для проверки гипотез)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d1%86%d0%b5%d0%bb%d1%8c--%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf-%d0%ba%d0%b0%d0%ba-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82-%d0%bf%d1%80%d0%be%d0%b4%d0%b0%d0%b6%d0%b8\"\u003e2. Наша цель — прототип как инструмент продажи\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%81%d1%80%d0%b0%d0%b2%d0%bd%d0%b5%d0%bd%d0%b8%d0%b5-%d1%86%d0%b5%d0%bb%d0%b5%d0%b9-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f\"\u003e3. Сравнение целей прототипирования\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%bf%d1%83%d1%82%d1%8c-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b0-%d0%ba-%d0%ba%d0%be%d0%bd%d1%82%d1%80%d0%b0%d0%ba%d1%82%d1%83\"\u003e4. Диаграмма \u0026ldquo;Путь прототипа к контракту\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-82-%d0%b7%d0%b0%d1%87%d0%b5%d0%bc-%d0%b8%d1%81%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d0%be%d0%b2%d0%b0%d1%82%d1%8c-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%bd%d0%b0%d1%88%d0%b8-%d0%bf%d1%80%d0%b8%d1%87%d0%b8%d0%bd%d1%8b\"\u003eГлава 8.2: Зачем использовать прототипирование? Наши причины\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%bf%d1%80%d0%b8%d1%87%d0%b8%d0%bd%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%be%d0%b2%d0%be%d0%b9-%d0%ba%d0%be%d0%bc%d0%bf%d0%b0%d0%bd%d0%b8%d0%b8\"\u003e1. Ключевые идеи из курса (Причины для продуктовой компании)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b8-%d0%bf%d1%80%d0%b8%d1%87%d0%b8%d0%bd%d1%8b-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf-%d0%ba%d0%b0%d0%ba-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82-%d0%bf%d1%80%d0%be%d0%b4%d0%b0%d0%b6%d0%b8\"\u003e2. Наши причины (Прототип как инструмент продажи)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%81%d1%80%d0%b0%d0%b2%d0%bd%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b2%d1%8b%d0%b3%d0%be%d0%b4-%d0%be%d1%82-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f\"\u003e3. Сравнение выгод от прототипирования\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d1%86%d0%b5%d0%bd%d0%bd%d0%be%d1%81%d1%82%d1%8c-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b0-%d0%b2-%d0%bf%d1%80%d0%b5%d1%81%d0%b5%d0%b9%d0%bb%d0%b5\"\u003e4. Диаграмма \u0026ldquo;Ценность прототипа в пресейле\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-83-%d1%82%d0%b8%d0%bf%d1%8b-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%be%d0%b2-%d0%b2%d1%8b%d0%b1%d0%b8%d1%80%d0%b0%d0%b5%d0%bc-%d0%bf%d0%be%d0%b4%d1%85%d0%be%d0%b4%d1%8f%d1%89%d0%b8%d0%b9-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%be%d0%b4%d0%b0%d0%b6%d0%b8\"\u003eГлава 8.3: Типы прототипов. Выбираем подходящий для продажи\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%ba%d0%bb%d0%b0%d1%81%d1%81%d0%b8%d1%84%d0%b8%d0%ba%d0%b0%d1%86%d0%b8%d1%8f-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%be%d0%b2\"\u003e1. Ключевые идеи из курса (Классификация прототипов)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b8-%d1%82%d0%b8%d0%bf%d1%8b-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%be%d0%b2-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%b5%d1%81%d0%b5%d0%b9%d0%bb%d0%b0\"\u003e2. Наши типы прототипов для пресейла\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%82%d0%b0%d0%b1%d0%bb%d0%b8%d1%86%d0%b0-%d0%ba%d0%b0%d0%ba%d0%be%d0%b9-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf-%d0%b4%d0%bb%d1%8f-%d0%ba%d0%b0%d0%ba%d0%be%d0%b9-%d0%b7%d0%b0%d0%b4%d0%b0%d1%87%d0%b8\"\u003e3. Таблица: Какой прототип для какой задачи?\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%b2%d1%8b%d0%b1%d0%be%d1%80-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b0-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%b5%d1%81%d0%b5%d0%b9%d0%bb%d0%b0\"\u003e4. Диаграмма \u0026ldquo;Выбор прототипа для пресейла\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-84-%d1%82%d0%b5%d1%85%d0%bd%d0%b8%d0%ba%d0%b8-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%ba%d0%b0%d0%ba-%d0%b1%d1%8b%d1%81%d1%82%d1%80%d0%be-%d1%81%d0%b4%d0%b5%d0%bb%d0%b0%d1%82%d1%8c-%d0%bd%d0%b0%d0%b3%d0%bb%d1%8f%d0%b4%d0%bd%d1%8b%d0%b9-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf\"\u003eГлава 8.4: Техники прототипирования. Как быстро сделать наглядный прототип\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d1%80%d0%b0%d0%b7%d0%bd%d0%be%d0%be%d0%b1%d1%80%d0%b0%d0%b7%d0%b8%d0%b5-%d1%82%d0%b5%d1%85%d0%bd%d0%b8%d0%ba\"\u003e1. Ключевые идеи из курса (Разнообразие техник)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b8-%d1%82%d0%b5%d1%85%d0%bd%d0%b8%d0%ba%d0%b8-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%b5%d1%81%d0%b5%d0%b9%d0%bb%d0%b0\"\u003e2. Наши техники для пресейла\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%82%d0%b0%d0%b1%d0%bb%d0%b8%d1%86%d0%b0-%d1%82%d0%b5%d1%85%d0%bd%d0%b8%d0%ba%d0%b8-%d0%b8-%d0%b8%d1%85-%d0%bf%d1%80%d0%b8%d0%bc%d0%b5%d0%bd%d0%b5%d0%bd%d0%b8%d0%b5\"\u003e3. Таблица: Техники и их применение\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d1%81%d0%be%d0%b7%d0%b4%d0%b0%d0%bd%d0%b8%d1%8f-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b0-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%b5%d1%81%d0%b5%d0%b9%d0%bb%d0%b0\"\u003e4. Диаграмма \u0026ldquo;Процесс создания прототипа для пресейла\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-85-%d0%bf%d0%be%d0%b4%d0%b3%d0%be%d1%82%d0%be%d0%b2%d0%ba%d0%b0-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d0%be%d0%b2-%d1%87%d1%82%d0%be-%d1%81%d0%bf%d1%80%d0%b0%d1%88%d0%b8%d0%b2%d0%b0%d1%82%d1%8c-%d1%83-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%b0-%d0%bf%d1%80%d0%b8-%d0%b4%d0%b5%d0%bc%d0%be%d0%bd%d1%81%d1%82%d1%80%d0%b0%d1%86%d0%b8%d0%b8-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b0\"\u003eГлава 8.5: Подготовка вопросов. Что спрашивать у клиента при демонстрации прототипа\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d0%be%d0%b2%d0%b0%d1%82%d0%b5%d0%bb%d1%8c%d1%81%d0%ba%d0%be%d0%b3%d0%be-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f\"\u003e1. Ключевые идеи из курса (Вопросы для пользовательского тестирования)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88-%d0%bf%d0%be%d0%b4%d1%85%d0%be%d0%b4--%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d1%8b-%d0%b4%d0%bb%d1%8f-%d1%81%d0%be%d0%b3%d0%bb%d0%b0%d1%81%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f\"\u003e2. Наш подход — «Вопросы для согласования»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%87%d0%b5%d0%ba-%d0%bb%d0%b8%d1%81%d1%82-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d0%be%d0%b2-%d0%b4%d0%bb%d1%8f-%d0%b4%d0%b5%d0%bc%d0%be%d0%bd%d1%81%d1%82%d1%80%d0%b0%d1%86%d0%b8%d0%b8-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b0-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d1%83\"\u003e3. Чек-лист вопросов для демонстрации прототипа клиенту\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d1%86%d0%b8%d0%ba%d0%bb-%d0%be%d0%b1%d1%80%d0%b0%d1%82%d0%bd%d0%be%d0%b9-%d1%81%d0%b2%d1%8f%d0%b7%d0%b8-%d0%bf%d1%80%d0%b8-%d0%b4%d0%b5%d0%bc%d0%be%d0%bd%d1%81%d1%82%d1%80%d0%b0%d1%86%d0%b8%d0%b8-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b0\"\u003e4. Диаграмма \u0026ldquo;Цикл обратной связи при демонстрации прототипа\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-86-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d0%b4%d0%b5%d0%bc%d0%be%d0%bd%d1%81%d1%82%d1%80%d0%b0%d1%86%d0%b8%d0%b8-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b0-%d0%be%d1%82-%d0%bf%d0%be%d0%ba%d0%b0%d0%b7%d0%b0-%d0%ba-%d1%81%d0%be%d0%b3%d0%bb%d0%b0%d1%81%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8e\"\u003eГлава 8.6: Процесс демонстрации прототипа. От показа к согласованию\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d1%8d%d1%82%d0%b0%d0%bf%d1%8b-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f\"\u003e1. Ключевые идеи из курса (Этапы тестирования)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81--%d0%b4%d0%b5%d0%bc%d0%be%d0%bd%d1%81%d1%82%d1%80%d0%b0%d1%86%d0%b8%d1%8f-%d0%b8-%d1%81%d0%be%d0%b3%d0%bb%d0%b0%d1%81%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5\"\u003e2. Наш процесс — «Демонстрация и согласование»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d1%87%d0%b5%d0%ba-%d0%bb%d0%b8%d1%81%d1%82-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%be%d0%b2%d0%b5%d0%b4%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b4%d0%b5%d0%bc%d0%be%d0%bd%d1%81%d1%82%d1%80%d0%b0%d1%86%d0%b8%d0%b8-%d0%bf%d1%80%d0%be%d1%82%d0%be%d1%82%d0%b8%d0%bf%d0%b0\"\u003e3. Чек-лист для проведения демонстрации прототипа\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%b8%d1%82%d0%b5%d1%80%d0%b0%d1%82%d0%b8%d0%b2%d0%bd%d1%8b%d0%b9-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d1%81%d0%be%d0%b3%d0%bb%d0%b0%d1%81%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f\"\u003e4. Диаграмма \u0026ldquo;Итеративный процесс согласования\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-91-%d0%bf%d0%be%d0%bb%d1%83%d1%87%d0%b5%d0%bd%d0%b8%d0%b5-%d1%81%d0%be%d0%b3%d0%bb%d0%b0%d1%81%d0%b8%d1%8f-%d0%b8-%d0%b2%d1%8b%d1%80%d0%b0%d0%b2%d0%bd%d0%b8%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%bd%d0%b0%d1%88%d0%b0-%d1%86%d0%b5%d0%bb%d1%8c--%d0%bf%d0%be%d0%b4%d0%bf%d0%b8%d1%81%d0%b0%d0%bd%d0%bd%d1%8b%d0%b9-%d0%ba%d0%be%d0%bd%d1%82%d1%80%d0%b0%d0%ba%d1%82\"\u003eГлава 9.1: Получение согласия и выравнивание. Наша цель — подписанный контракт\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%b2%d0%bd%d1%83%d1%82%d1%80%d0%b5%d0%bd%d0%bd%d0%b5%d0%b5-%d1%81%d0%be%d0%b3%d0%bb%d0%b0%d1%81%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5\"\u003e1. Ключевые идеи из курса (Внутреннее согласование)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d1%86%d0%b5%d0%bb%d1%8c--%d1%81%d0%be%d0%b3%d0%bb%d0%b0%d1%81%d0%b8%d0%b5-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%b0-%d0%b8-%d0%ba%d0%be%d0%bd%d1%82%d1%80%d0%b0%d0%ba%d1%82\"\u003e2. Наша цель — согласие клиента и контракт\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b4%d0%be%d0%ba%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%bf%d0%be%d0%bb%d1%83%d1%87%d0%b5%d0%bd%d0%b8%d1%8f-buy-in-%d0%be%d1%82-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%b0\"\u003e3. Ключевые документы для получения «Buy-in» от клиента\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d0%be%d1%82-discovery-%d0%ba-%d0%ba%d0%be%d0%bd%d1%82%d1%80%d0%b0%d0%ba%d1%82%d1%83\"\u003e4. Диаграмма \u0026ldquo;От Discovery к контракту\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-101-%d0%bd%d0%b5%d0%bf%d1%80%d0%b5%d1%80%d1%8b%d0%b2%d0%bd%d0%be%d0%b5-discovery-%d1%80%d0%b0%d0%b7%d0%b2%d0%b8%d1%82%d0%b8%d0%b5-%d0%be%d1%82%d0%bd%d0%be%d1%88%d0%b5%d0%bd%d0%b8%d0%b9-%d0%b8-%d0%b4%d0%be%d0%bf%d1%80%d0%be%d0%b4%d0%b0%d0%b6%d0%b8\"\u003eГлава 10.1: Непрерывное Discovery. Развитие отношений и допродажи\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%bf%d0%be%d1%81%d1%82%d0%be%d1%8f%d0%bd%d0%bd%d0%be%d0%b5-%d1%83%d0%bb%d1%83%d1%87%d1%88%d0%b5%d0%bd%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0\"\u003e1. Ключевые идеи из курса (Постоянное улучшение продукта)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b0-%d0%b0%d0%b4%d0%b0%d0%bf%d1%82%d0%b0%d1%86%d0%b8%d1%8f--%d1%80%d0%b0%d0%b7%d0%b2%d0%b8%d1%82%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d0%b0-%d0%b8-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%b0\"\u003e2. Наша адаптация — «Развитие проекта и клиента»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d0%bf%d1%80%d0%b8%d0%bc%d0%b5%d0%bd%d0%b5%d0%bd%d0%b8%d0%b5-%d0%bf%d1%80%d0%b8%d0%bd%d1%86%d0%b8%d0%bf%d0%be%d0%b2-discovery-%d0%bf%d0%be%d1%81%d0%bb%d0%b5-%d0%ba%d0%be%d0%bd%d1%82%d1%80%d0%b0%d0%ba%d1%82%d0%b0\"\u003e3. Применение принципов Discovery после контракта\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%b4%d0%b8%d0%b0%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b0-%d1%86%d0%b8%d0%ba%d0%bb-%d1%80%d0%b0%d0%b7%d0%b2%d0%b8%d1%82%d0%b8%d1%8f-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%b0\"\u003e4. Диаграмма \u0026ldquo;Цикл развития клиента\u0026rdquo;\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-111-%d0%b7%d0%b0%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%bd%d0%b8%d0%b5-discovery-%d0%ba%d0%b0%d0%ba-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82-%d1%83%d1%81%d0%bf%d0%b5%d1%85%d0%b0\"\u003eГлава 11.1: Заключение. Discovery как инструмент успеха\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#1-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b8%d0%b4%d0%b5%d0%b8-%d0%b8%d0%b7-%d0%ba%d1%83%d1%80%d1%81%d0%b0-%d0%b1%d0%bb%d0%b0%d0%b3%d0%be%d0%b4%d0%b0%d1%80%d0%bd%d0%be%d1%81%d1%82%d1%8c-%d0%b8-%d0%bf%d0%be%d0%b6%d0%b5%d0%bb%d0%b0%d0%bd%d0%b8%d1%8f\"\u003e1. Ключевые идеи из курса (Благодарность и пожелания)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#2-%d0%bd%d0%b0%d1%88%d0%b5-%d0%b7%d0%b0%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b3%d0%bb%d0%b0%d0%b2%d0%bd%d1%8b%d0%b9-%d0%b2%d1%8b%d0%b2%d0%be%d0%b4-%d0%b4%d0%bb%d1%8f-rdpresale\"\u003e2. Наше заключение (Главный вывод для R\u0026amp;D/Presale)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#3-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%bf%d1%80%d0%b8%d0%bd%d1%86%d0%b8%d0%bf%d1%8b-%d0%bd%d0%b0%d1%88%d0%b5%d0%b3%d0%be-discovery-%d0%ba%d1%80%d0%b0%d1%82%d0%ba%d0%be%d0%b5-%d1%80%d0%b5%d0%b7%d1%8e%d0%bc%d0%b5\"\u003e3. Ключевые принципы нашего Discovery (Краткое резюме)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/product_discovery/#4-%d0%bf%d1%80%d0%b8%d0%b7%d1%8b%d0%b2-%d0%ba-%d0%b4%d0%b5%d0%b9%d1%81%d1%82%d0%b2%d0%b8%d1%8e\"\u003e4. Призыв к действию\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"глава-11-введение-от-теории-к-практике\"\u003eГлава 1.1: Введение. От теории к практике\u003c/h2\u003e\n\u003ch3 id=\"1-ключевые-идеи-из-курса-взгляд-теоретика\"\u003e1. Ключевые идеи из курса (Взгляд теоретика)\u003c/h3\u003e\n\u003cp\u003eАвтор курса представляет Product Discovery как линейный, пошаговый процесс для создания успешных продуктов. Основные этапы, которые он выделяет:\u003c/p\u003e","title":"Product Discovery для сервисных компаний"},{"content":"ИИ-ассистированный кодинг для команд, которым не сойдут с рук вайбы\nОчень хороший гайд по эффективному использованию ИИ-агентов в разработке. Он краток, но даёт понять, куда копать.\n","permalink":"https://meshrefine.com/ru/microposts/2025-07-01-agentic-coding-advice/","summary":"\u003cp\u003e\u003ca href=\"https://blog.nilenso.com/blog/2025/05/29/ai-assisted-coding/\"\u003eИИ-ассистированный кодинг для команд, которым не сойдут с рук вайбы\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eОчень хороший гайд по эффективному использованию ИИ-агентов в разработке. Он краток, но даёт понять, куда копать.\u003c/p\u003e","title":"2025-07-01"},{"content":"Глава поиска Google раскрывает подход «game system» на фоне запуска рекламы в AI Mode\nGoogle будет показывать рекламу в своём ИИ-режиме. Вполне ожидаемый ход от поискового гиганта, учитывая, что ИИ-поиск и прочие новые функции ломают традиционную рекламную модель. Будет интересно посмотреть, как станут развиваться эти новые техники интеграции рекламы и как будет выглядеть новое поколение блокировщиков.\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-30-google-to-roll-out-ads-in-ai-mode/","summary":"\u003cp\u003e\u003ca href=\"https://ppc.land/google-search-head-reveals-game-system-approach-as-ai-mode-begins-advertising-rollout/\"\u003eГлава поиска Google раскрывает подход «game system» на фоне запуска рекламы в AI Mode\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eGoogle будет показывать рекламу в своём ИИ-режиме. Вполне ожидаемый ход от поискового гиганта, учитывая, что ИИ-поиск и прочие новые функции ломают традиционную рекламную модель. Будет интересно посмотреть, как станут развиваться эти новые техники интеграции рекламы и как будет выглядеть новое поколение блокировщиков.\u003c/p\u003e","title":"2025-06-30"},{"content":"Когда вы работаете с ИИ-агентом для кодинга, вам действительно хочется снабдить его массой инструкций: про рабочие процессы, организацию кодовой базы, стилевые соглашения и многое другое. Эти инструкции должны быть переиспользуемыми и композируемыми, чтобы все ваши кодовые базы выглядели единообразно. В репозитории собраны примеры таких инструкций для веб-разработки и Windsurf.\nЯ бы рекомендовал завести похожий набор файлов для проектов, над которыми вы работаете, поддерживать их и собирать в AGENTS.md/CLAUDE.md/GEMINI.md простой командой cp:\n$ cp Workflow.md Styles.md Structure.md \u0026gt; AGENTS.md ","permalink":"https://meshrefine.com/ru/microposts/2025-06-28-b5dadddc/","summary":"\u003cp\u003eКогда вы работаете с ИИ-агентом для кодинга, вам \u003cem\u003eдействительно\u003c/em\u003e хочется снабдить его массой инструкций: про рабочие процессы, организацию кодовой базы, стилевые соглашения и многое другое. Эти инструкции должны быть переиспользуемыми и композируемыми, чтобы все ваши кодовые базы выглядели единообразно. В \u003ca href=\"https://github.com/Shamail/ai-coding-template\"\u003eрепозитории\u003c/a\u003e собраны примеры таких инструкций для веб-разработки и Windsurf.\u003c/p\u003e\n\u003cp\u003eЯ бы рекомендовал завести похожий набор файлов для проектов, над которыми вы работаете, поддерживать их и собирать в \u003ccode\u003eAGENTS.md\u003c/code\u003e/\u003ccode\u003eCLAUDE.md\u003c/code\u003e/\u003ccode\u003eGEMINI.md\u003c/code\u003e простой командой \u003ccode\u003ecp\u003c/code\u003e:\u003c/p\u003e","title":"Шаблон для разработки с ИИ"},{"content":"Перезапуск Microsoft атомной станции Три-Майл-Айленд идёт с опережением графика\nСпрос на ИИ воскрешает атомную энергетику — самый эффективный и безуглеродный источник энергии из имеющихся у нас сегодня. Это наглядное напоминание о том, что нельзя рассматривать непосредственные эффекты в отрыве от их последствий второго и третьего порядка.\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-28-b46c7630/","summary":"\u003cp\u003e\u003ca href=\"https://www.techradar.com/pro/microsofts-rekindling-of-three-mile-island-nuclear-plant-is-ahead-of-schedule\"\u003eПерезапуск Microsoft атомной станции Три-Майл-Айленд идёт с опережением графика\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eСпрос на ИИ воскрешает атомную энергетику — самый эффективный и безуглеродный источник энергии из имеющихся у нас сегодня. Это наглядное напоминание о том, что нельзя рассматривать непосредственные эффекты в отрыве от их последствий второго и третьего порядка.\u003c/p\u003e","title":"2025-06-28"},{"content":"State of Cybersecurity Resilience 2025\nЛишь одна организация из десяти достаточно защищена от угроз, связанных с ИИ. Поспешное внедрение инструментов на базе ИИ резко увеличивает поверхность атаки. Критически важно аккуратно и методично выстраивать стратегию безопасности для каждой системы, собирать лучшие практики и обучать заинтересованные стороны.\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-28-3169d51b/","summary":"\u003cp\u003e\u003ca href=\"https://www.accenture.com/us-en/insights/security/state-cybersecurity-2025\"\u003eState of Cybersecurity Resilience 2025\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eЛишь одна организация из десяти достаточно защищена от угроз, связанных с ИИ. Поспешное внедрение инструментов на базе ИИ резко увеличивает поверхность атаки. Критически важно аккуратно и методично выстраивать стратегию безопасности для каждой системы, собирать лучшие практики и обучать заинтересованные стороны.\u003c/p\u003e","title":"2025-06-28"},{"content":"Swift Android Workgroup\nApple сформировала рабочую группу для поддержки разработки Android-приложений на Swift. Это может заинтересовать компании, у которых уже есть iOS-приложения и которые хотели бы переиспользовать бизнес-логику на Android. Однако UI и другие платформенно-специфичные компоненты по-прежнему придётся писать с использованием нативных фреймворков и библиотек.\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-27-cb648728/","summary":"\u003cp\u003e\u003ca href=\"https://www.swift.org/android-workgroup/\"\u003eSwift Android Workgroup\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eApple сформировала рабочую группу для поддержки разработки Android-приложений на Swift.\nЭто может заинтересовать компании, у которых уже есть iOS-приложения и которые хотели бы переиспользовать бизнес-логику на Android. Однако UI и другие платформенно-специфичные компоненты по-прежнему придётся писать с использованием нативных фреймворков и библиотек.\u003c/p\u003e","title":"2025-06-27"},{"content":" Глава 1.1: Цели исследования рынка. Зачем нам это? Глава 1.2: Ключевые определения. Говорим на одном языке. 1. Бизнес-план (Business Plan) 2. Питч-дек (Pitch Deck) 3. Валидация рынка (Market Validation) 4. Первичное исследование (Primary Research) 5. Вторичное исследование (Secondary Research) Глава 1.3: Типы исследования рынка. Выбираем правильный инструмент. 1. Первичное исследование (Primary Research) 2. Вторичное исследование (Secondary Research) Глава 2.1: Определение направления исследования. Куда мы идем? Почему это важно? Ключевые шаги перед началом исследования: Глава 2.2: Ключевая рыночная информация. Что нам нужно знать? 1. Анализ рынка (Market Analysis) 2. Инструменты оценки рынка (Market Assessment Tools) Глава 2.3: Расчет размера рынка. Сколько денег на кону? 1. Подход «сверху вниз» (Top-Down Approach) 2. Подход «снизу вверх» (Bottom-Up Approach) Компоненты размера рынка: TAM, SAM, SOM Методы расчета размера рынка Глава 2.4: Процесс исследования рынка. Наш алгоритм действий. 1. Определи цели и вопросы исследования (Establish research goals and questions) 2. Рассчитай размер рынка (Calculate market size using the provided model) 3. Исследуй рыночные тренды, драйверы и барьеры, а также концентрацию рынка (Research market trends, drivers, barriers, and concentration) 4. Создай SWOT-анализ и рыночную карту (Create a SWOT analysis and market scorecard) 5. Оцени потенциальную выручку, затраты и ROI (Estimate potential revenue, costs, and ROI) Глава 3.1: Что анализировать у конкурентов. Знай врага в лицо. 1. Общая информация (General Information) 2. Продукт и ценообразование (Product and Pricing) 3. Метрики производительности (Performance Metrics) 4. Маркетинг и цифровое присутствие (Marketing and Digital Presence) Глава 3.2: Где найти информацию о конкурентах. Наш арсенал разведчика. 1. Основные методы поиска (Primary Search Methods) 2. Инструменты анализа конкурентов (Competitor Analysis Tools) 2.1. Базы данных компаний (Company Database Tools) 2.2. Платформы для обзора продуктов (Product Review Platforms) 2.3. Инструменты веб-аналитики (Website Analytics Tools) 2.4. Инструменты для исследования рекламы (Advertising Research Tools) Глава 3.4: Организация информации о конкурентах. Как не утонуть в данных. 1. Профили конкурентов (Competitor Profiles) 2. Матрица конкурентных преимуществ (Competitive Advantage Matrix) 3. Картирование конкурентов (Competitor Mapping) Глава 3.5: Лучшие практики анализа конкурентов. Как делать это правильно. 1. Анализируй оптимальное количество конкурентов (Analyze 5-15 competitors) 2. Делай конкретные выводы (Draw concrete conclusions) 3. Фокусируйся на болевых точках клиентов (Focus on customer pain points) 4. Стандартизируй подход к анализу (Standardize your analysis approach) Глава 4.1: Ключевые вопросы для анализа целевой аудитории. Для кого мы работаем? 1. Болевые точки (Pain Points) 2. Существующие решения (Current Solutions) 3. Удовлетворенность решениями (Solution Satisfaction) 4. Демография пользователей (User Demographics) 5. Принятие продукта (Product Adoption) 6. Соответствие решения (Solution Fit) 7. Готовность платить (Willingness to Pay) Глава 4.2: Вторичный анализ целевой аудитории. Изучаем, что уже известно. 1. Как найти качественные исследования? 2. Формула поиска исследований 3. Инструменты для анализа целевой аудитории Глава 4.3: Первичный анализ целевой аудитории: Опросы. Спрашиваем напрямую. 1. Процесс проектирования опроса (Survey Design Process) 2. Лучшие практики структуры опроса (Survey Structure Best Practices) 3. Советы по дизайну вопросов (Question Design Tips) 4. Расчет размера выборки (Sample Size Calculation) 5. Методы сбора данных (Data Collection Methods) Глава 4.4: Сочетание первичного и вторичного исследования. Синтез данных. Лучшие практики сочетания исследований: Глава 5.1: Бизнес-план против питч-дека. Упаковываем результаты по-разному. Бизнес-план (Business Plan) Питч-дек (Pitch Deck) Глава 5.2: Структура бизнес-плана. Куда вставлять наши данные. 1. Резюме (Executive Summary) 2. Общие сведения о компании (Company Background) 3. Анализ рынка (Market Analysis) 4. Анализ целевой аудитории (Target Audience Analysis) 5. Проблема и решение (Problem and Solution) 6. Анализ конкурентов (Competitor Analysis) 7. SWOT-анализ (SWOT Analysis) 8. Маркетинговый план (Marketing Plan) 9. Операционный план (Operational Plan) 10. Финансовый план (Financial Plan) 11. Таймлайн/Дорожная карта (Timeline/Roadmap) Глава 5.3: Структура питч-дека. Как продать идею за 7 минут. 1. Проблема и Возможность (Problem and Opportunity) 2. Решение (Solution) 3. Технология/Инновация (Technology/Innovation) 4. Размер рынка (Market Size) 5. Бизнес-модель (Business Model) 6. План выхода на рынок (Go-To-Market Plan) 7. Конкуренция (Competition) 8. Команда (Team) 9. Финансовые прогнозы (Financial Projections) 10. Финансирование (Funding) 11. Таймлайн (Timeline) Глава 5.4: Лучшие практики визуализации. Как показать данные красиво и понятно. 1. Техники фокусировки (Focus Techniques) 2. Принципы дизайна (Design Principles) 3. Распространенные типы визуализации (Common Visualization Types) 4. Чего НЕ стоит делать при визуализации (Visualization Don\u0026rsquo;ts) Глава 5.5: Канва бизнес-модели. Вся суть на одной странице. 1. Ценностные предложения (Value Propositions) 2. Потребительские сегменты (Customer Segments) 3. Каналы сбыта (Channels) 4. Взаимоотношения с клиентами (Customer Relationships) 5. Потоки доходов (Revenue Streams) 6. Ключевые ресурсы (Key Resources) 7. Ключевые виды деятельности (Key Activities) 8. Ключевые партнеры (Key Partners) 9. Структура издержек (Cost Structure) Глава 6.1: Подход «облака синонимов». Расширяем поисковый арсенал. Почему «облака синонимов» важны? Создание «облака синонимов» Ресурсы для создания «облака синонимов» Глава 6.2: Эффективный процесс поиска. Наш алгоритм разведки. Трехэтапный процесс: Расширенные команды Google Search Настройки местоположения (Location Settings) Глава 6.3: Инструменты для улучшения поиска. Наш набор утилит. 1. Multi Highlighter (Мульти-выделитель) 2. Google Dictionary (Словарь Google) 3. Simple Scraper (Простой скрепер) 4. Google Alerts (Оповещения Google) Глава 6.4: Лучшие практики эффективности исследования. Как не тратить время впустую. 1. Проверяй результаты поиска по изображениям (Check image search results). 2. Проверяй достоверность источника (Verify source credibility). 3. Ищи даты публикации (Look for publication dates). 4. Изучай описания источников (Examine source descriptions). 5. Будь методичен (Be methodical). 6. Используй расширенную фильтрацию (Use advanced filtering). 7. Итерируй свои поисковые запросы (Iterate your searches). Глава 6.5: Распространенные ошибки при поиске. Как не наступить на грабли. 1. Поиск по одному ключевому слову (Single keyword searching). 2. Игнорирование альтернативной терминологии (Ignoring alternative terminology). 3. Остановка на первой странице (Stopping at the first page). 4. Игнорирование результатов поиска по изображениям (Overlooking image results). 5. Принятие информации без проверки (Accepting information without verification). 6. Использование неподходящих географических настроек (Using inappropriate geography settings). 7. Неследование по ссылкам (Not following citation trails). Глава 7.1: Влияние ИИ на методологии исследования. Новый игрок на поле. Текущие сильные стороны ИИ в исследованиях: Текущие ограничения ИИ: Глава 7.2: Эффективные промпты для ИИ-исследований. Как говорить с машиной. Лучшие практики для ИИ-промптов: Пример структуры промпта: Глава 7.3: ИИ-инструменты для исследования рынка. Наш цифровой арсенал. 1. ChatGPT 2. Agent GPT 3. Lumina 4. Julius 5. Durable 6. FlowGPT 7. Plus AI Глава 7.4: Лучшие практики интеграции ИИ. Как заставить ИИ работать на нас. 1. Гибридный подход (Hybrid approach). 2. Проверяй фактические утверждения (Verify factual claims). 3. Указывай методологии (Specify methodologies). 4. Предоставляй примеры (Provide examples). 5. Используй для генерации идей, а не для окончательных решений (Use for ideation, not finalization). 6. Комбинируй ИИ-инструменты (Combine AI tools). Глава 7.5: Пример рабочего процесса ИИ-исследования. Кейс-стади. Пример: Анализ открытых ответов опроса Глава 8.1: Процесс исследования рынка: пошагово. Наш чек-лист. Комплексный процесс исследования рынка включает следующие последовательные шаги: Глава 8.2: Основные инструменты исследования рынка. Наш инструментарий. 1. Инструменты анализа (Analysis Tools) 2. Инструменты исследования (Research Tools) 3. Инструменты поиска (Search Tools) Глава 8.3: Принципы эффективности. Как работать умно, а не много. Чтобы проводить исследование рынка эффективно: Глава 8.4: Показатели качества. Как понять, что исследование годное. Высококачественное исследование рынка характеризуется: Глава 8.5: Следующие шаги. Что делать после исследования. После завершения исследования рынка: Глава 1.1: Цели исследования рынка. Зачем нам это? Коллега, давай начистоту. «Исследование рынка» звучит как что-то из мира маркетологов в модных пиджаках, а не из нашей с тобой инженерной окопной правды. Но дьявол, как всегда, в деталях. В нашем R\u0026amp;D/presale контексте — это не просто «анализ», а суровый производственный инструмент.\nВот три главные причины, почему мы этим занимаемся:\nПроверить идею на прочность (Validate business ideas). Прежде чем бросаться писать код и проектировать архитектуру для очередной «гениальной» идеи, нужно задать простой вопрос: «А это кому-нибудь, кроме нас, вообще нужно?». Исследование рынка — это наш способ «прощупать» реальность. Есть ли спрос? Готов ли кто-то за это платить? Это как написать юнит-тест для бизнес-гипотезы. Провалился — отлично, мы сэкономили месяцы работы. Прошел — у нас есть первые доказательства, что идея жизнеспособна.\nПодготовить почву для продажи (Create business plans \u0026amp; pitch decks). Когда идея подтверждена, ее нужно «упаковать» для тех, кто принимает решения (клиенты, инвесторы, руководство). Бизнес-план — это не талмуд на 100 страниц, а, по сути, наша проектная документация, только для бизнеса. Pitch Deck — это краткая, убедительная выжимка из нее, наш «технический демо», но на языке денег и выгод. Без исследования рынка оба этих документа — пустая болтовня. С ним — аргументированная позиция.\nНаметить стратегический курс (Establish business strategy). Рынок постоянно меняется. Появляются новые технологии, конкуренты, меняются потребности клиентов. Исследование — это наш радар. Он помогает понять, куда дует ветер, и вовремя скорректировать курс. Для нас, инженеров, это означает понимание, какие технологии будут востребованы завтра, какие фичи пилить в первую очередь, а от чего стоит отказаться.\nИтог: Для нас исследование рынка — это не про отчеты ради отчетов. Это про снижение рисков, экономию ресурсов и создание продуктов, которые действительно нужны людям и за которые они готовы платить. Это инженерный подход к бизнесу.\nГлава 1.2: Ключевые определения. Говорим на одном языке. Чтобы не путаться в терминах и понимать друг друга с полуслова, давай разберем основные понятия, которые будут встречаться в контексте исследования рынка. Это наш глоссарий, но без заумных формулировок.\n1. Бизнес-план (Business Plan) Что это: Это не просто документ, а, по сути, техническое задание для бизнеса. Подробное описание того, что мы собираемся делать, как, для кого и почему это принесет деньги. Включает в себя анализ рынка, описание продукта/услуги, маркетинговую стратегию, операционный план и финансовые прогнозы. Обычно это объемный документ (100+ страниц), предназначенный для глубокого изучения.\nДля нас: Это фундамент. Если мы разрабатываем новый продукт или сервис, бизнес-план — это наш roadmap, который показывает, куда мы движемся и почему. Он помогает структурировать мысли и аргументировать наши технические решения с точки зрения бизнеса.\n2. Питч-дек (Pitch Deck) Что это: Это презентация-выжимка из бизнес-плана. Короткая (10-20 слайдов), визуально насыщенная, с минимумом текста. Ее цель — быстро и убедительно донести ключевые идеи до потенциальных инвесторов, партнеров или руководства. Время презентации обычно 7-9 минут.\nДля нас: Это наш «демо-стенд». Если бизнес-план — это полный код проекта, то питч-дек — это его UI/UX, который должен зацепить и показать главное. Мы, как инженеры, должны понимать, какие аспекты нашего продукта или технологии наиболее важны для демонстрации в питч-деке, чтобы они выглядели максимально выигрышно.\n3. Валидация рынка (Market Validation) Что это: Процесс проверки жизнеспособности бизнес-идеи с помощью исследования рынка. Это не просто «нравится/не нравится», а сбор и анализ данных, которые подтверждают или опровергают, что наш продукт или услуга найдет своего потребителя и будет востребован.\nДля нас: Это наш «тест на проникновение». Мы не просто создаем что-то крутое, мы проверяем, насколько это «крутое» соответствует реальным потребностям рынка. Валидация помогает избежать разработки «в стол» и сосредоточиться на том, что действительно имеет ценность.\n4. Первичное исследование (Primary Research) Что это: Сбор новой, оригинальной информации непосредственно из источника. Это могут быть интервью с потенциальными клиентами, фокус-группы, опросы. То есть, мы сами идем и спрашиваем у людей, что им нужно, как они живут, какие у них проблемы.\nДля нас: Это как сбор требований напрямую от пользователя, а не через третьего менеджера. Позволяет получить «сырые» данные, которые дают глубокое понимание реальных потребностей и болевых точек. Это самый прямой путь к пониманию, что именно мы должны разрабатывать.\n5. Вторичное исследование (Secondary Research) Что это: Анализ уже существующей информации, собранной кем-то другим. Это могут быть опубликованные отчеты, исследования индустрии, статистические базы данных, сайты конкурентов. Мы не собираем новые данные, а используем то, что уже есть в открытом доступе.\nДля нас: Это наш «ресерч» перед началом проекта. Позволяет быстро получить общую картину рынка, понять тренды, изучить конкурентов, не тратя время и ресурсы на первичный сбор данных. Это отправная точка, которая помогает сформулировать гипотезы для первичного исследования и избежать изобретения велосипеда.\nЗапомни: Начинаем всегда со вторичного исследования, чтобы понять, что уже известно. А затем, если есть пробелы, дополняем первичным, чтобы получить уникальные данные и подтвердить гипотезы. Это эффективный подход, который экономит время и ресурсы.\nГлава 1.3: Типы исследования рынка. Выбираем правильный инструмент. В предыдущей главе мы уже вскользь упоминали первичное и вторичное исследование. Теперь давай углубимся и разберем их подробнее, чтобы ты понимал, когда какой подход использовать и что от него ожидать.\n1. Первичное исследование (Primary Research) Суть: Это когда мы сами идем «в поле» и собираем новую, оригинальную информацию напрямую от источника. Это как писать новый модуль с нуля, потому что готового решения нет или оно не подходит.\nКогда используем:\nКогда нужна очень специфическая информация, которой нет в открытом доступе. Когда нужно подтвердить или опровергнуть гипотезы, полученные из вторичных источников. Когда нужно понять глубинные мотивы, потребности и «боли» потенциальных пользователей. Основные методы:\nИнтервью: Один на один с потенциальными клиентами или экспертами. Позволяет получить глубокие, качественные данные, понять нюансы и неявные потребности. Это как глубокое код-ревью с архитектором. Фокус-группы: Групповые дискуссии с представителями целевой аудитории. Помогают выявить общие мнения, реакции на идеи, а также динамику группового взаимодействия. Это как мозговой штурм с командой, но с внешними участниками. Опросы (Surveys): Распространение анкет среди большого количества людей. Позволяют собрать количественные данные, выявить статистические закономерности и тренды. Это как нагрузочное тестирование, но для мнений. Плюсы: Получаем уникальные, актуальные данные, максимально релевантные нашей задаче. Глубокое понимание рынка.\nМинусы: Дорого, долго, требует значительных ресурсов и правильной методологии, чтобы не получить «шум» вместо данных.\n2. Вторичное исследование (Secondary Research) Суть: Это когда мы используем уже существующую информацию, собранную кем-то другим. Это как использовать готовую библиотеку или фреймворк: не нужно писать все с нуля, но важно понимать, что внутри и насколько это подходит.\nКогда используем:\nНа начальных этапах проекта, чтобы быстро получить общую картину рынка. Для изучения общих трендов, статистики, размера рынка. Для анализа конкурентов, их продуктов и стратегий. Для формулирования гипотез, которые потом можно проверить первичным исследованием. Основные источники:\nОпубликованные отчеты: Исследования от аналитических агентств, государственных органов, отраслевых ассоциаций. Часто содержат ценную статистику и прогнозы. Анализы индустрии: Обзоры от торговых изданий, консалтинговых компаний. Помогают понять специфику отрасли. Статистические базы данных: Данные о населении, экономике, потребительском поведении. Например, данные Росстата, Eurostat, World Bank. Сайты конкурентов: Отличный источник информации об их продуктах, ценах, маркетинговых активностях, вакансиях (по ним можно понять, какие технологии они используют). Плюсы: Быстро, дешево, доступно. Позволяет охватить большой объем информации и получить широкую картину.\nМинусы: Информация может быть устаревшей, не всегда идеально релевантной нашей специфике. Не дает глубокого понимания индивидуальных потребностей.\nЗолотое правило: Всегда начинай со вторичного исследования. Это как провести рекогносцировку местности перед наступлением. Пойми, что уже известно, какие есть карты и данные. И только потом, если есть «белые пятна» или нужны детали, которые нигде не описаны, переходи к первичному исследованию. Такой подход экономит время, деньги и нервы.\nГлава 2.1: Определение направления исследования. Куда мы идем? Прежде чем бросаться в омут данных, как в омут с головой, нужно четко понять, что именно мы ищем. Это как перед написанием кода определить требования и архитектуру. Без этого — хаос, переделки и потраченные впустую ресурсы. Эйнштейн, кстати, говорил, что если бы у него был час на решение проблемы, 55 минут он бы потратил на формулировку вопроса. И он был прав.\nПочему это важно? Избежать информационного шума: Рынок — это океан данных. Без четкого направления ты утонешь в нерелевантной информации, которая только отвлекает и не дает ответов. Экономить ресурсы: Время и деньги — наши главные активы. Четко сформулированные вопросы позволяют сосредоточиться на поиске нужных данных, а не на бесцельном блуждании. Получить actionable insights: Нам нужны не просто данные, а выводы, на основе которых можно принимать решения. Это возможно только тогда, когда вопросы изначально были сформулированы под конкретные решения. Ключевые шаги перед началом исследования: Определи свои исследовательские вопросы (Define your research questions).\nЧто это: Это конкретные, измеримые вопросы, на которые ты хочешь получить ответы. Например: «Каков потенциальный размер рынка для нашего нового AI-решения в сфере логистики в СНГ?», «Какие ключевые проблемы испытывают наши потенциальные клиенты при использовании существующих CRM-систем?», «Какие технологии используют конкуренты для обработки больших данных?». Для нас: Это наш «use case» для исследования. Чем точнее вопрос, тем точнее будет ответ. Это помогает сфокусироваться и не распыляться. Определи вопросы заинтересованных сторон (Identify stakeholder questions).\nЧто это: Подумай, что хотят знать инвесторы, партнеры, руководство, отдел продаж. Какие данные им нужны для принятия решений? Возможно, им важен ROI, или доля рынка, или скорость внедрения. Для нас: Это помогает учесть все аспекты и подготовить отчет, который будет полезен всем. Мы же не только для себя работаем, но и для бизнеса в целом. Установи критерии принятия решений (Establish decision criteria).\nЧто это: Какие данные или показатели будут для тебя сигналом к действию? Например, «если потенциальный рынок меньше X миллиардов, мы не запускаем продукт», или «если 70% опрошенных испытывают проблему Y, мы фокусируемся на ее решении». Для нас: Это наши «метрики успеха». Они позволяют объективно оценить результаты исследования и понять, стоит ли двигаться дальше, или нужно пересмотреть стратегию. Запомни: Без четко сформулированных вопросов и критериев ты рискуешь получить гору данных, которая не даст никаких ответов. Это как написать тонну кода без тестов и требований — работать будет, но что именно и как хорошо, непонятно.\nГлава 2.2: Ключевая рыночная информация. Что нам нужно знать? После того как мы определили, что именно ищем, пора понять, какие данные нам понадобятся для ответа на эти вопросы. Это как собрать список необходимых библиотек и фреймворков перед началом разработки. Без них — никуда.\nКомплексный анализ рынка обычно включает следующие компоненты:\n1. Анализ рынка (Market Analysis) Это базовые параметры, которые описывают сам рынок, на который мы целимся.\nРазмер рынка (Market Size): Общая потенциальная стоимость рынка. Сколько денег «крутится» в этой нише? Это наш потенциальный «потолок» выручки. Позже мы разберем, как это считать. Сегментация рынка (Market Segmentation): Как рынок делится на подрынки? По географии, типу пользователей, функционалу и т.д. Это помогает понять, кто наш идеальный клиент и где он находится. Например, рынок ПО для логистики можно сегментировать по размеру компаний (малый, средний, крупный бизнес) или по типу грузов (скоропортящиеся, опасные). Прогнозы роста (Growth Projections): Растет ли рынок? Как быстро? Какие ожидания на будущее? Нам интересно работать на растущем рынке, а не на стагнирующем или падающем. Драйверы и барьеры (Drivers and Barriers): Что толкает рынок вперед (драйверы) и что его сдерживает (барьеры)? Это могут быть технологические инновации, законодательные изменения, экономические факторы, конкуренция. Понимание этих факторов помогает прогнозировать развитие и выявлять риски. Рыночные тренды (Market Trends): Какие текущие тенденции определяют успех компаний и что хотят клиенты? Например, тренд на облачные решения, на AI-автоматизацию, на персонализацию. Это помогает нам быть в авангарде, а не догонять. Концентрация рынка (Market Concentration): Монополизирован ли рынок несколькими крупными игроками или он сильно фрагментирован? Это влияет на нашу стратегию выхода на рынок и конкурентную борьбу. 2. Инструменты оценки рынка (Market Assessment Tools) Это фреймворки и подходы, которые помогают нам анализировать собранные данные и делать выводы.\nКарточка успеха рынка (Market Success Scorecard): Набор критериев для измерения рыночного потенциала. Это как наш чек-лист для оценки проекта: соответствует ли он нашим внутренним стандартам и ожиданиям рынка? SWOT-анализ (SWOT Analysis): Структурированная оценка сильных (Strengths) и слабых (Weaknesses) сторон нашей компании/продукта, а также возможностей (Opportunities) и угроз (Threats) на рынке. Классика, которая всегда работает. Помогает увидеть полную картину. Анализ конкурентов (Competitor Analysis): Детальная оценка существующих игроков на рынке. Что они делают? Как? Какие у них сильные и слабые стороны? Это наш «бенчмаркинг» в мире бизнеса. Расчеты выручки (Revenue Calculations): Прогнозы потенциального дохода. Сколько мы можем заработать, если выйдем на этот рынок? Это наши «перформанс-метрики» для бизнеса. Возврат инвестиций (Return on Investment - ROI): Оценка прибыльности относительно вложенных инвестиций. Насколько выгодно нам вкладываться в этот проект? Это наш «cost-benefit analysis». Итог: Эти компоненты — наш набор сенсоров и аналитических инструментов. Они позволяют нам не просто собрать данные, а превратить их в осмысленные выводы, на основе которых можно принимать взвешенные решения. Без них мы рискуем построить отличный продукт, который никому не нужен, или выйти на рынок, где нас уже ждут акулы.\nГлава 2.3: Расчет размера рынка. Сколько денег на кону? Размер рынка — это не просто цифра, это индикатор потенциала. Для нас, инженеров, это понимание масштаба задачи и потенциальной отдачи от наших усилий. Для инвесторов — это ключевой показатель привлекательности проекта. Есть два основных подхода к расчету.\n1. Подход «сверху вниз» (Top-Down Approach) Суть: Начинаем с оценки общего объема рынка и затем сужаем его до нашей потенциальной доли. Это как взять общую численность населения и постепенно отсеивать тех, кто не является нашей целевой аудиторией.\nКогда используем:\nИдеально подходит для стартапов и новых бизнесов, у которых нет истории продаж. Когда нет детальных данных, и нужно получить быструю, высокоуровневую оценку. Пример: Если мы делаем AI-решение для оптимизации логистики, мы можем начать с общего объема мирового рынка логистики, затем сузить его до рынка логистики в конкретном регионе, потом до рынка логистики для компаний определенного размера, и так далее, пока не дойдем до нашей потенциальной доли.\n2. Подход «снизу вверх» (Bottom-Up Approach) Суть: Основывается на исторических данных о продажах и прогнозах. Мы начинаем с оценки того, сколько мы можем продать одному клиенту, и затем масштабируем это на количество потенциальных клиентов.\nКогда используем:\nПодходит для уже существующих компаний с историей продаж. Когда есть доступ к детальным данным о клиентах и их поведении. Пример: Если у нас уже есть 100 клиентов, и мы знаем, сколько в среднем каждый из них платит за наш сервис, мы можем экстраполировать эти данные на потенциальное количество аналогичных клиентов на рынке.\nКомпоненты размера рынка: TAM, SAM, SOM Это три уровня детализации, которые помогают нам понять реальный потенциал.\nОбщий объем доступного рынка (Total Addressable Market - TAM)\nЧто это: Все потенциальные клиенты, которые теоретически могли бы получить выгоду от твоего продукта или услуги, без учета географии, маркетингового бюджета, конкуренции и стратегии. Пример: Для сервиса по разработке ПО для малого бизнеса, TAM — это все малые бизнесы в мире, которым потенциально нужно ПО. Обслуживаемый доступный рынок (Serviceable Addressable Market - SAM)\nЧто это: Та часть TAM, которая конкретно нуждается в твоем предложении. Это те, кого ты можешь реально обслужить с учетом твоей специализации. Пример: Если твой сервис для малого бизнеса специализируется на ПО для управления проектами, SAM — это все малые бизнесы, которым нужно ПО для управления проектами. Обслуживаемый достижимый рынок (Serviceable Obtainable Market - SOM)\nЧто это: Реалистичная часть SAM, которую твой бизнес может захватить. Учитывает долю рынка, конкуренцию и твои конкретные возможности. Это твой фактический потенциал выручки. Пример: Из всех малых бизнесов, которым нужно ПО для управления проектами, ты реалистично можешь захватить 5% в течение первого года. Методы расчета размера рынка Метод 1: Вторичное исследование (Secondary Research)\nСуть: Ищем уже существующие расчеты размера рынка от исследовательских фирм. Когда используем: Для быстрой первоначальной валидации. Это как найти готовый бенчмарк. Менее убедительно для инвесторов, но дает отправную точку. Метод 2: Модель первичного расчета (Primary Calculation Model)\nСуть: Используем структурированную модель для оценки размера рынка, собирая данные самостоятельно. Ключевые входные данные: Количество компаний/клиентов в целевой вертикали, средний размер сделки/ценность клиента, процент компаний, открытых к твоему продукту/услуге, оценочная доля рынка, региональная и вертикальная сегментация. Когда используем: Когда нужна высокая точность и убедительность для инвесторов. Это как провести собственное нагрузочное тестирование, а не верить чужим отчетам. Итог: Понимание TAM, SAM, SOM и умение их рассчитывать — это не просто академические знания. Это наш компас, который показывает, насколько велик потенциал нашего продукта и стоит ли игра свеч. Выбирай метод расчета в зависимости от стадии проекта и доступности данных.\nГлава 2.4: Процесс исследования рынка. Наш алгоритм действий. Исследование рынка — это не хаотичный поиск информации, а структурированный процесс. Думай о нем как о хорошо спроектированном пайплайне: каждый шаг логически вытекает из предыдущего и ведет к конкретному результату. Вот основные этапы:\n1. Определи цели и вопросы исследования (Establish research goals and questions) Суть: Самый первый и самый важный шаг. Прежде чем что-то искать, нужно понять, что именно ты хочешь найти и зачем. Какие решения будут приниматься на основе этих данных? Какие вопросы интересуют ключевых стейкхолдеров (руководство, инвесторов, отдел продаж)? Для нас: Это как определение требований к новой фиче. Без четкого ТЗ результат будет непредсказуем. Сформулируй конкретные, измеримые вопросы, на которые ты хочешь получить ответы. 2. Рассчитай размер рынка (Calculate market size using the provided model) Суть: Используй подходы TAM/SAM/SOM, о которых мы говорили ранее. Это даст тебе понимание потенциального масштаба и привлекательности рынка. Для нас: Это помогает оценить потенциальную отдачу от инвестиций в разработку. Стоит ли игра свеч? Насколько велик пирог, который мы хотим откусить? 3. Исследуй рыночные тренды, драйверы и барьеры, а также концентрацию рынка (Research market trends, drivers, barriers, and concentration) Суть: Погрузись в контекст. Что движет рынком? Что его сдерживает? Какие технологии сейчас в тренде? Кто основные игроки и насколько рынок монополизирован? Для нас: Это позволяет понять, в какой среде мы будем работать. Какие технологии будут востребованы завтра? Какие риски нас ждут? Это как анализ внешних зависимостей и потенциальных узких мест в системе. 4. Создай SWOT-анализ и рыночную карту (Create a SWOT analysis and market scorecard) Суть: Систематизируй информацию о своих сильных и слабых сторонах, а также о возможностях и угрозах на рынке. Используй рыночную карту (scorecard) для оценки потенциала. Для нас: Это помогает увидеть полную картину и выявить ключевые области для улучшения или развития. Где мы сильны? Где уязвимы? Какие возможности мы можем использовать? От каких угроз нужно защищаться? 5. Оцени потенциальную выручку, затраты и ROI (Estimate potential revenue, costs, and ROI) Суть: Переведи все собранные данные в финансовые показатели. Сколько мы можем заработать? Сколько это будет стоить? Каков будет возврат на инвестиции? Для нас: Это финальная проверка бизнес-гипотезы. Если цифры не сходятся, значит, нужно пересмотреть либо идею, либо подход к ее реализации. Это наш «финансовый юнит-тест». Итог: Этот процесс — не жесткий регламент, а гибкий фреймворк. Ты можешь адаптировать его под свои нужды, но главное — не пропускать ключевые этапы. Системный подход к исследованию рынка позволяет принимать обоснованные решения и минимизировать риски, что для инженера, работающего в R\u0026amp;D и presale, критически важно.\nГлава 3.1: Что анализировать у конкурентов. Знай врага в лицо. Анализ конкурентов — это не просто сбор информации, это стратегическая разведка. Для нас, инженеров в R\u0026amp;D и presale, это возможность понять, что уже есть на рынке, где наши потенциальные преимущества, а где — слабые места. Это как реверс-инжиниринг чужого продукта, но на уровне бизнеса. Вот что стоит анализировать:\n1. Общая информация (General Information) Это базовые данные, которые дают общее представление о конкуренте.\nВозраст компании и зрелость (Company age and maturity): Как давно они на рынке? Это стартап или мастодонт? Это влияет на их гибкость, ресурсы и подходы. Целевая география (Target geography): Где они работают? Локально, регионально, глобально? Это поможет понять, где мы можем пересекаться, а где есть свободные ниши. Целевые вертикали/индустрии (Target verticals/industries): На каких клиентов они сфокусированы? Например, только на финтех или на логистику? Это поможет определить, насколько они являются прямыми конкурентами. Год основания и история (Founding year and history): Как они развивались? Какие были вехи? Это может дать подсказки об их стратегии и адаптивности. 2. Продукт и ценообразование (Product and Pricing) Это сердце их предложения. Нам важно понять, что именно они продают и как.\nПродуктовые предложения и сегментация (Product offerings and segmentation): Какие продукты/услуги они предлагают? Как они сегментируют свой рынок? Есть ли у них нишевые решения? Анализ функций (Feature analysis): Особенно важно для технологических решений. Какие функции есть у их продукта? Какие из них ключевые? Чего им не хватает? Это наш «функциональный разбор» их продукта. Структура ценообразования (Pricing structure): Как они формируют цены? По подписке, за объем, за пользователя? Есть ли у них разные тарифные планы? Это поможет нам позиционировать наш продукт. Процесс продаж и подход (Sales process and approach): Как они продают? Через партнеров, напрямую, через маркетплейсы? Это может дать идеи для нашего presale. 3. Метрики производительности (Performance Metrics) Это показатели их успеха и эффективности.\nУдовлетворенность клиентов (Customer satisfaction): Что говорят о них клиенты? Какие отзывы? Это можно найти на внешних ресурсах. Негативные отзывы — это наши потенциальные возможности. Финансовые показатели (Financial performance): Если доступно, то выручка, прибыль, инвестиции. Это дает представление об их стабильности и ресурсах. Доля рынка (Market share): Какую часть рынка они занимают? Это показывает их влияние и масштаб. 4. Маркетинг и цифровое присутствие (Marketing and Digital Presence) Как они привлекают клиентов и как они представлены в онлайне.\nРекламные стратегии и контент (Advertising strategies and content): Где они рекламируются? Какой контент используют? Какие сообщения транслируют? Трафик сайта и SEO-метрики (Website traffic and SEO metrics): Сколько посетителей на их сайте? Откуда они приходят? Какие ключевые слова используют? Это покажет их активность в онлайне. Активность в социальных сетях (Social media activity): Насколько они активны в соцсетях? Какой контент публикуют? Как взаимодействуют с аудиторией? Email-маркетинг (Email marketing): Если доступно, то как они строят коммуникацию через рассылки? Контент-стратегия (Content strategy): Какие статьи, блоги, вебинары они выпускают? Это покажет их экспертизу и подход к обучению клиентов. Партнерства с инфлюенсерами (Influencer partnerships): Используют ли они лидеров мнений для продвижения? Итог: Детальный анализ этих аспектов конкурентов позволит нам не просто скопировать их, а найти свои уникальные преимущества, выявить незанятые ниши и разработать стратегию, которая позволит нам выделиться на рынке. Это не про шпионаж, а про умное позиционирование.\nГлава 3.2: Где найти информацию о конкурентах. Наш арсенал разведчика. Теперь, когда мы знаем, что именно анализировать у конкурентов, возникает логичный вопрос: а где, собственно, брать эту информацию? К счастью, в современном мире данных предостаточно, главное — знать, куда смотреть. Это наш список источников для конкурентной разведки.\n1. Основные методы поиска (Primary Search Methods) Это наши базовые инструменты, с которых стоит начинать.\nGoogle Search: Твой лучший друг. Ищи по названию компании, продукту, услуге, а также по ключевым словам, связанным с их деятельностью и твоим регионом. Например, «[название конкурента] отзывы», «[продукт конкурента] цена», «[название конкурента] вакансии». Industry Ratings (Отраслевые рейтинги): Ищи списки «Топ-10» или «Лучшие [категория продукта]» в твоей нише или регионе. Часто такие рейтинги составляют авторитетные издания или аналитические агентства. Это быстрый способ выявить основных игроков. Marketplace Recommendations (Рекомендации маркетплейсов): Если ты работаешь в e-commerce, обрати внимание на разделы «часто покупают вместе» или «похожие товары». Это может подсказать прямых и косвенных конкурентов. Analysis Tools (Инструменты анализа): Существуют специализированные инструменты для анализа конкурентов, о которых мы поговорим ниже. Они автоматизируют сбор данных и предоставляют структурированные отчеты. Company Databases (Базы данных компаний): Такие платформы, как Crunchbase, ZoomInfo, предоставляют структурированную информацию о компаниях, их финансировании, руководстве и т.д. 2. Инструменты анализа конкурентов (Competitor Analysis Tools) Это специализированные сервисы, которые значительно упрощают сбор и анализ данных.\n2.1. Базы данных компаний (Company Database Tools) Crunchbase: Для чего: Отлично подходит для информации о стартапах и инвестициях. Позволяет узнать год основания, основателей, раунды финансирования, суммы инвестиций, приобретения, новости компании и даже базовый технологический стек. Как использовать (бесплатная версия): Ищи конкретные компании или используй фильтры по индустрии, местоположению, ключевым словам. Бесплатная версия обычно показывает топ-5 результатов. ZoomInfo: Для чего: Лучше подходит для оценки выручки частных компаний (точность 60-70%), информации о штаб-квартире, списках конкурентов и более детальном технологическом стеке. Лайфхак (бесплатная версия): Вместо внутреннего поиска (который требует лицензии), попробуй гуглить «[название компании] zoominfo» — часто это приводит прямо на профиль компании. 2.2. Платформы для обзора продуктов (Product Review Platforms) Capterra \u0026amp; G2: Для чего: Идеально для сравнения функций технологических компаний и чтения отзывов. Позволяет сравнить функции продуктов, получить внешнюю валидацию от пользователей, узнать метрики удовлетворенности, варианты развертывания, а также получить сводку положительных/отрицательных отзывов и распределение по целевым отраслям. Для нас: Это кладезь информации о «болях» пользователей и о том, что конкуренты делают хорошо или плохо. Помогает выявить незанятые ниши и потенциальные преимущества. 2.3. Инструменты веб-аналитики (Website Analytics Tools) Semrush \u0026amp; SimilarWeb: Для чего: Анализ трафика сайта и цифрового маркетинга. Позволяет узнать объем трафика, источники трафика (органический, платный, социальный, реферальный), географию трафика, сравнить органические и платные ключевые слова, выявить конкурентов (с точки зрения SEO) и проанализировать обратные ссылки. Ключевые метрики для проверки: Использует ли конкурент свой сайт как инструмент лидогенерации? Какой процент трафика приходит из платных источников? Какие страны генерируют больше всего трафика? Какие ключевые слова они таргетируют? 2.4. Инструменты для исследования рекламы (Advertising Research Tools) Facebook Ad Library: Для чего: Анализ рекламы в социальных сетях. Позволяет увидеть текущие и прошлые объявления в Facebook/Instagram, креативы и сообщения, места размещения (Facebook, Instagram, Messenger), продолжительность и частоту рекламы. Совет: Иногда компании рекламируются не со своих основных страниц. Если поиск по названию рекламодателя не дает результатов, попробуй искать по названию бренда. SpyFu: Для чего: Анализ рекламы в Google Ads. Позволяет оценить ежемесячный рекламный бюджет, посмотреть креативы и историю Google Ads, таргетированные ключевые слова, а также эффективность и позиционирование рекламы. Итог: Используя комбинацию этих инструментов и источников, ты сможешь собрать максимально полную картину о своих конкурентах. Это не просто сбор данных, а создание полноценной базы знаний, которая поможет тебе принимать обоснованные решения в R\u0026amp;D и presale.\nГлава 3.4: Организация информации о конкурентах. Как не утонуть в данных. Собрать информацию о конкурентах — это полдела. Важно ее правильно организовать, чтобы она не превратилась в бесполезную свалку данных, а стала инструментом для принятия решений. Думай об этом как о проектировании базы данных: нужна четкая структура, чтобы потом можно было легко делать запросы и получать нужные срезы. Вот несколько подходов.\n1. Профили конкурентов (Competitor Profiles) Суть: Создание кратких, но емких досье на каждого конкурента. Это как резюме, но для компании. Цель — иметь под рукой ключевую информацию, организованную единообразно для всех.\nКак делать:\nОбъем: 5-7 слайдов (или страниц) максимум на каждого конкурента. Больше — уже перебор, это не диссертация. Содержание: Включи ключевую информацию, которую мы обсуждали в Главе 3.1: общие данные, продукты/услуги, ценообразование, основные метрики, маркетинговые активности. Единообразие: Используй одну и ту же структуру для всех профилей. Это критически важно для последующего сравнения. Если для одного конкурента ты описываешь одно, а для другого — другое, то сравнивать их будет невозможно. Для нас: Это быстрый способ получить общее представление о любом конкуренте. Если тебе нужно быстро вспомнить, чем занимается «Конкурент X» и какие у него ключевые фичи, ты открываешь его профиль и за 30 секунд получаешь всю нужную информацию.\n2. Матрица конкурентных преимуществ (Competitive Advantage Matrix) Суть: Это таблица сравнения функций или возможностей, которая наглядно показывает, кто что предлагает. Это как таблица совместимости компонентов в нашей системе.\nКак делать:\nСтроки: Перечисли функции или возможности, которые предлагает твой продукт (или которые ты планируешь реализовать). Столбцы: В каждом столбце укажи одного из конкурентов. Отметки: Отмечай, какие функции есть у каждого конкурента (например, «да/нет» или «+/−»). Можно использовать более детальные оценки, если это необходимо. Для нас: Эта матрица моментально выявляет твои уникальные преимущества и пробелы на рынке. Ты сразу видишь, где ты сильнее конкурентов, а где тебе нужно подтянуться. Это отличный инструмент для presale, чтобы показать клиенту, почему именно твое решение лучше.\n3. Картирование конкурентов (Competitor Mapping) Суть: Визуальное представление конкурентов на двухмерной плоскости. Это как график, где по осям отложены ключевые параметры. Помогает увидеть позиционирование каждого игрока и выявить незанятые ниши.\nКак делать:\nОси: Выбери две ключевые переменные, которые наиболее релевантны для твоего рынка. Например, «цена vs. специализация», «научный подход vs. цена», «опыт vs. спектр услуг», «широта функций vs. размер целевого рынка». Размещение: Размести всех проанализированных конкурентов на этом графике. Анализ: Ищи закономерности и потенциальные возможности для позиционирования. Где есть «пустые» зоны, куда еще никто не зашел? Где слишком много игроков, и конкуренция слишком высока? Для нас: Это мощный инструмент для стратегического планирования. Он помогает визуализировать рыночную ситуацию и найти свою уникальную нишу. Например, если все конкуренты предлагают дешевые, но неспециализированные решения, возможно, есть смысл сфокусироваться на дорогом, но высокоспециализированном продукте.\nИтог: Правильная организация информации о конкурентах — это не просто порядок ради порядка. Это создание аналитических инструментов, которые позволяют быстро принимать обоснованные решения, выявлять возможности и эффективно позиционировать свой продукт на рынке. Это наш «дашборд» для конкурентной среды.\nГлава 3.5: Лучшие практики анализа конкурентов. Как делать это правильно. Анализ конкурентов — это не разовая акция, а непрерывный процесс. Чтобы он приносил максимальную пользу и не превращался в пустую трату времени, важно придерживаться определенных принципов. Это наши «паттерны проектирования» для конкурентной разведки.\n1. Анализируй оптимальное количество конкурентов (Analyze 5-15 competitors) Суть: Не нужно пытаться анализировать всех подряд. Количество конкурентов, которых стоит детально изучать, зависит от концентрации рынка. Для монополизированных рынков (с небольшим количеством игроков): Анализируй всех конкурентов. Если их 2-3, то каждый из них критически важен. Для фрагментированных рынков (с большим количеством игроков): Сосредоточься на топ-15-20. Это те, кто задает тон и с кем ты будешь конкурировать в первую очередь. Остальных можно изучать поверхностно. Для нас: Это помогает сфокусировать ресурсы. Нет смысла тратить время на изучение каждого мелкого игрока, если на рынке доминируют несколько гигантов. Лучше глубоко изучить ключевых игроков, чем поверхностно — всех.\n2. Делай конкретные выводы (Draw concrete conclusions) Суть: Цель анализа — не просто собрать данные, а сделать из них выводы, на основе которых можно принимать решения. Это как после тестирования системы не просто получить логи, а понять, где именно проблема и как ее решить. Что анализировать: Рыночные паттерны: Какие общие тенденции и закономерности ты видишь в поведении конкурентов? Конкурентные преимущества: В чем сильные стороны каждого конкурента? Что они делают лучше других? Потенциальные возможности позиционирования: Где есть незанятые ниши или слабые места у конкурентов, которые мы можем использовать? Пробелы на рынке: Какие потребности клиентов не удовлетворены существующими решениями? Для нас: Это наш «отчет об анализе». Он должен быть четким, содержать конкретные рекомендации и быть понятным для всех стейкхолдеров.\n3. Фокусируйся на болевых точках клиентов (Focus on customer pain points) Суть: Изучай негативные отзывы о продуктах конкурентов. Это золотая жила для выявления возможностей дифференциации. Если клиенты жалуются на что-то у конкурентов, это наша возможность сделать лучше. Где искать: Отзывы на платформах типа Capterra, G2, в социальных сетях, на форумах, в комментариях к статьям. Для нас: Это прямой путь к созданию продукта, который будет решать реальные проблемы пользователей. Если мы можем устранить «боли», которые конкуренты игнорируют, мы получим значительное преимущество.\n4. Стандартизируй подход к анализу (Standardize your analysis approach) Суть: Используй единую методологию и шаблоны для анализа всех конкурентов. Это критически важно для получения валидных сравнений. Как делать: Используй шаблоны профилей конкурентов, матрицы сравнения функций и карты позиционирования, о которых мы говорили в предыдущей главе. Заполни их для каждого конкурента. Для нас: Это обеспечивает консистентность и позволяет сравнивать «яблоки с яблоками», а не «яблоки с апельсинами». Если ты будешь каждый раз анализировать по-разному, то выводы будут некорректными и бесполезными.\nИтог: Эти лучшие практики — не просто рекомендации, а проверенные временем принципы. Применяя их, ты превратишь анализ конкурентов из рутинной задачи в мощный инструмент стратегического планирования и разработки, который поможет тебе создавать продукты, опережающие рынок.\nГлава 4.1: Ключевые вопросы для анализа целевой аудитории. Для кого мы работаем? Понимание целевой аудитории — это не просто маркетинговый ход, это критически важный аспект для R\u0026amp;D и presale. Если мы не знаем, для кого мы делаем продукт, то как мы можем сделать его по-настоящему полезным и востребованным? Это как писать код без понимания, кто будет его использовать и какие задачи он должен решать. Анализ целевой аудитории должен фокусироваться на следующих вопросах:\n1. Болевые точки (Pain Points) Что это: Какие проблемы испытывают потенциальные клиенты? Что их беспокоит, раздражает, мешает им работать или жить? Для нас: Это наш «баг-репорт» от рынка. Если мы можем решить эти проблемы, наш продукт будет иметь ценность. Например, если клиенты тратят часы на рутинную обработку данных, это их болевая точка, которую мы можем автоматизировать. 2. Существующие решения (Current Solutions) Что это: Как они решают эти проблемы сейчас? Используют ли они какие-то инструменты, обходные пути, или просто терпят неудобства? Для нас: Это наш «анализ конкурентов», но с фокусом на решения, а не только на компании. Помогает понять, с чем мы будем конкурировать, и где есть возможности для улучшения. 3. Удовлетворенность решениями (Solution Satisfaction) Что это: Насколько они удовлетворены текущими решениями? Есть ли у них претензии, пожелания, или они вполне счастливы? Для нас: Если существующие решения не удовлетворяют, это наш шанс предложить что-то лучшее. Если удовлетворены, нам нужно найти уникальное преимущество, чтобы переманить их. 4. Демография пользователей (User Demographics) Что это: Кто они? Возраст, местоположение, отрасль, размер компании, должность и т.д. Это помогает создать «портрет» нашего идеального клиента. Для нас: Это помогает нам адаптировать наш продукт и коммуникацию под конкретную аудиторию. Например, если наша ЦА — это крупные корпорации, то и продукт должен быть масштабируемым и безопасным. 5. Принятие продукта (Product Adoption) Что это: Какой процент целевой аудитории был бы открыт для использования нашего решения? Насколько они готовы к изменениям и новым технологиям? Для нас: Это оценка потенциального рынка. Если аудитория консервативна, нам потребуется больше усилий на обучение и убеждение. 6. Соответствие решения (Solution Fit) Что это: Насколько наше решение эффективно решает их проблемы? Действительно ли оно попадает в цель? Для нас: Это проверка нашей гипотезы. Мы должны быть уверены, что наш продукт не просто «крутой», а именно «решающий проблему». 7. Готовность платить (Willingness to Pay) Что это: Готовы ли они на самом деле платить за наше решение? Какую цену они считают справедливой? Для нас: Это критически важный вопрос. Многие потенциальные клиенты могут признавать наличие проблемы, но не готовы платить за ее решение. Это наш «финансовый фильтр». Если нет готовности платить, то и бизнеса не будет. Итог: Эти вопросы — наш чек-лист для анализа целевой аудитории. Отвечая на них, мы получаем глубокое понимание того, для кого мы работаем, какие проблемы решаем и насколько наш продукт будет востребован. Это позволяет нам создавать продукты, которые не просто работают, а приносят реальную ценность и прибыль.\nГлава 4.2: Вторичный анализ целевой аудитории. Изучаем, что уже известно. Прежде чем бросаться в бой с опросами и интервью, всегда начинай со вторичного анализа целевой аудитории. Это как изучить документацию к существующей системе, прежде чем писать свой модуль. Зачем изобретать велосипед, если кто-то уже провел исследования и опубликовал результаты?\n1. Как найти качественные исследования? Не всякая информация одинаково полезна. Чтобы не тратить время на мусор, обращай внимание на следующие критерии при поиске существующих исследований:\nГеографическая релевантность: Исследование должно быть проведено в том регионе, на который ты ориентируешься. Глобальные данные могут быть интересны, но для конкретного рынка нужны локальные. Соответствие целевой аудитории: Убедись, что исследование сфокусировано именно на твоей целевой аудитории, а не на широкой группе людей. Актуальность (Recency): Данные быстро устаревают. Ищи исследования, проведенные не позднее 2 лет назад. В нашей сфере, где все меняется со скоростью света, это критично. Размер выборки (Sample size): Чем больше опрошенных, тем надежнее данные. Минимум 100 респондентов, для B2C-рынков желательно 1000+. Качество изложения: Хорошее исследование написано грамотно, без ошибок. Это признак профессионализма. Релевантность темы: Исследование должно касаться именно тех аспектов, по которым тебе нужна информация. Надлежащая атрибуция: Четко указано, кто проводил исследование и когда. Это позволяет оценить доверие к источнику. Методология: Описано, как собирались и анализировались данные. Это позволяет понять, насколько результаты достоверны. 2. Формула поиска исследований Для эффективного поиска в Google используй следующую формулу:\n[Рынок/География] + [Целевая аудитория] + [Тема опроса] + [Год] + \u0026quot;PDF\u0026quot;\nПримеры:\n\u0026quot;US Accountants Survey Challenges 2023 PDF\u0026quot; \u0026quot;Australia Marketing Directors Survey 2023\u0026quot; \u0026quot;US VR Developers Challenges Survey Results\u0026quot; Про-совет: Добавление \u0026quot;PDF\u0026quot; часто помогает найти полные отчеты, а не рекламные тизеры или страницы для лидогенерации.\n3. Инструменты для анализа целевой аудитории Существуют специализированные инструменты, которые помогут тебе получить дополнительные инсайты о целевой аудитории:\nSparktoro: Показывает, что твоя аудитория читает, смотрит, слушает и за кем следит. Это как «профайлер» для интересов пользователей. Google Trends: Демонстрирует тренды поисковых запросов, региональный интерес и связанные запросы. Помогает понять, что сейчас «на хайпе» и что волнует людей. AnswerThePublic: Выявляет вопросы, которые люди задают по темам, связанным с твоим продуктом. Это прямой источник «болевых точек» и потребностей. YouTube Find My Audience: Показывает интересы, покупательское поведение и предпочтения контента конкретных сегментов рынка. Google Audience Insights: Предоставляет экономические профили и данные о потребительских расходах. Итог: Вторичный анализ — это твой первый и самый быстрый способ получить общую картину целевой аудитории. Он помогает выявить уже известные факты, сформулировать гипотезы и определить, какие «белые пятна» нужно заполнить с помощью первичного исследования. Это экономит время и ресурсы, позволяя сосредоточиться на действительно уникальных данных.\nГлава 4.3: Первичный анализ целевой аудитории: Опросы. Спрашиваем напрямую. Когда вторичные источники исчерпаны, а тебе нужны специфические, глубокие или количественные данные, наступает время первичного исследования. Опросы — один из самых мощных инструментов для этого. Но помни: плохо спроектированный опрос — это как баг в продакшене: он даст неверные данные, на основе которых будут приняты ошибочные решения. Разберем, как делать это правильно.\n1. Процесс проектирования опроса (Survey Design Process) Это наш «жизненный цикл разработки» для опроса:\nОпредели целевую аудиторию (на основе вторичного исследования): Кого именно мы опрашиваем? Это критически важно для релевантности данных. Если опрашивать не тех, то и результаты будут не те. Разработай анкету (следуя лучшим практикам ниже): Это наш «интерфейс» для сбора данных. Он должен быть понятным, логичным и не вызывать отторжения. Собери данные (используя методы, описанные ниже): Выбери подходящий канал для распространения опроса. Организуй и проанализируй данные: Преврати сырые ответы в осмысленные выводы. Сделай выводы: Ответь на свои исследовательские вопросы и сформулируй рекомендации. 2. Лучшие практики структуры опроса (Survey Structure Best Practices) Чтобы респонденты не бросали опрос на полпути, держи его коротким (идеально 10-15 вопросов, максимум 20) и структурируй его логично:\nРаздел 1: Скрининг (Screener Section) Что это: Вопросы для определения демографических и фирмографических данных (возраст, местоположение, роль, размер компании, бюджетные полномочия). Помогает сегментировать ответы позже. Для нас: Это как фильтр на входе. Мы отсеиваем тех, кто не является нашей целевой аудиторией, чтобы не тратить время на нерелевантные ответы. Раздел 2: Подтверждение проблемы (Problem Confirmation) Что это: Вопросы о существующих болевых точках, текущих решениях и уровне удовлетворенности ими. Для нас: Это проверка наших гипотез о проблемах. Действительно ли они существуют и насколько они остры? Раздел 3: Ожидания от решения (Solution Expectations) Что это: Вопросы о желаемых функциях идеального решения, готовности платить и ключевых факторах принятия решения. Для нас: Это наш «фиче-лист» от потенциальных пользователей. Помогает приоритизировать разработку и понять, что для них действительно важно. 3. Советы по дизайну вопросов (Question Design Tips) Используй закрытые вопросы: Предлагай варианты ответов, а не требуй свободных формулировок. Это упрощает анализ. Например, вместо «Что вы думаете о нашем продукте?» спроси «Насколько вы удовлетворены нашим продуктом по шкале от 1 до 5?». Всегда включай вариант «Другое»: Позволь респондентам добавить варианты, которые ты не предусмотрел. Это может выявить неожиданные инсайты. Избегай наводящих слов: Не используй эмоционально окрашенные или предвзятые формулировки. Вопрос должен быть нейтральным. Например, вместо «Насколько вы согласны, что наш инновационный продукт решит все ваши проблемы?» спроси «Насколько наш продукт соответствует вашим ожиданиям?». Будь нейтрален: Не подталкивай респондентов к положительным или отрицательным ответам. Будь краток: Вопросы должны быть короткими и ясными. Чем длиннее и сложнее вопрос, тем выше вероятность, что его неправильно поймут или пропустят. 4. Расчет размера выборки (Sample Size Calculation) Чтобы результаты опроса были статистически значимыми, нужно опросить достаточное количество людей. Используй онлайн-калькуляторы размера выборки со следующими входными данными:\nУровень доверия (Confidence level): Обычно 95%. Насколько ты уверен, что результаты выборки отражают всю генеральную совокупность. Погрешность (Margin of error): Обычно 5%. Диапазон «плюс-минус» для твоих результатов. Доля населения (Population proportion): Используй 50%, если не уверен (это даст максимальный размер выборки). Размер генеральной совокупности (Population size): Общий размер твоей целевой аудитории. 5. Методы сбора данных (Data Collection Methods) DIY-методы (сделай сам): LinkedIn/Социальные сети: Размещай ссылки на опрос (можно предложить стимулы, например, подарочные карты). База данных email: Отправляй опрос по существующим контактам. Фриланс-платформы: Нанимай респондентов с определенной квалификацией. Группы в Facebook: Делись в релевантных профессиональных группах. Платные панельные решения (Panel Solutions): SurveyMonkey: Более высокое качество, но дороже. Pollfish: Дешевле, проще для новичков. Итог: Опросы — мощный инструмент, но требующий тщательного подхода. Правильное проектирование, выборка и анализ данных позволят тебе получить ценные инсайты, которые станут основой для принятия решений в R\u0026amp;D и presale. Это наш «интеграционный тест» с реальными пользователями.\nГлава 4.4: Сочетание первичного и вторичного исследования. Синтез данных. Мы уже обсудили первичное и вторичное исследование по отдельности. Но настоящая магия происходит, когда ты умеешь правильно их комбинировать. Думай об этом как о многослойной архитектуре: каждый слой выполняет свою функцию, но вместе они создают надежную и эффективную систему. Вот как это работает на практике:\nЛучшие практики сочетания исследований: Начни со вторичного исследования, чтобы понять существующие знания (Start with secondary research to understand existing knowledge).\nСуть: Это твой первый шаг. Прежде чем тратить ресурсы на сбор новых данных, изучи все, что уже есть в открытом доступе. Это как провести рекогносцировку местности перед началом операции. Ты получишь общую картину, поймешь основные тренды, размер рынка, ключевых игроков. Для нас: Это позволяет быстро получить контекст и избежать изобретения велосипеда. Зачем опрашивать людей о том, что уже давно известно и опубликовано? Выяви пробелы во вторичном исследовании (Identify gaps in secondary research).\nСуть: После изучения вторичных источников у тебя неизбежно появятся вопросы, на которые нет ответов. Это могут быть очень специфические данные, глубокие инсайты о мотивах пользователей, или актуальная информация по узкой нише. Для нас: Эти «белые пятна» — твоя цель для первичного исследования. Это те уникальные данные, которые дадут тебе конкурентное преимущество. Спроектируй первичное исследование для заполнения этих пробелов (Design primary research to fill those specific gaps).\nСуть: Теперь, когда ты знаешь, чего тебе не хватает, разработай опросы, интервью или фокус-группы, которые целенаправленно соберут недостающую информацию. Не пытайся получить все данные мира, фокусируйся на конкретных вопросах. Для нас: Это позволяет максимально эффективно использовать ресурсы. Мы не стреляем из пушки по воробьям, а бьем точно в цель. Сравни результаты первичного и вторичного исследования для валидации (Compare primary and secondary findings for validation).\nСуть: Сопоставь данные, полученные из разных источников. Если они подтверждают друг друга, это значительно повышает твою уверенность в выводах. Если есть расхождения, это повод для дальнейшего изучения. Для нас: Это наш «кросс-чек». Если наши опросы подтверждают тренды, о которых пишут аналитические отчеты, значит, мы на верном пути. Если нет — нужно копать глубже. Ищи согласованные паттерны в обоих типах исследования (Look for consistent patterns across both types of research).\nСуть: Цель — найти общие закономерности и подтверждения. Чем больше источников указывают на одно и то же, тем сильнее твои выводы. Для нас: Когда данные из вторичных источников (например, отчеты о рынке) и первичных (например, наши опросы) совпадают, это дает высокую уверенность в наших заключениях. Это как получить подтверждение от нескольких независимых тестов. Итог: Сочетание первичного и вторичного исследования — это не просто сумма двух частей, это синергия. Такой подход позволяет получить максимально полную, достоверную и глубокую картину рынка, минимизировать риски и принимать по-настоящему обоснованные решения. Это наш «гибридный подход» к анализу данных, который дает наилучшие результаты.\nГлава 5.1: Бизнес-план против питч-дека. Упаковываем результаты по-разному. Мы уже касались этих двух документов в Главе 1.2, но теперь давай разберем их более детально, особенно с точки зрения того, как в них должны быть представлены результаты нашего исследования рынка. Думай об этом как о двух разных интерфейсах для одной и той же базы данных: один — для глубокого анализа, другой — для быстрой демонстрации.\nБизнес-план (Business Plan) Что это: Это полноценная техническая документация проекта, но на языке бизнеса. Он содержит все детали, все расчеты, все обоснования. Это наш «исходный код» проекта, который должен быть максимально полным и точным.\nКлючевые характеристики:\nОбъем: 100-150 страниц. Это серьезный документ, требующий времени на изучение. Содержание: Детальное. Включает глубокий анализ рынка, подробные финансовые прогнозы, операционные планы, юридические аспекты и т.д. Фокус: Текстовый. Основной объем информации передается через текст, таблицы, графики. Аудитория: Банки, грантовые организации, крупные инвесторы, внутренние стейкхолдеры, которым нужен полный контекст для принятия стратегических решений. Анализ: Всесторонний и комплексный. Ничего не упускается. Время презентации: Не ограничено. Предполагается, что читатель будет изучать его в своем темпе. Для нас: Результаты исследования рынка в бизнес-плане должны быть представлены максимально подробно. Все цифры, методологии, источники данных, выводы — все должно быть на своих местах. Это наша «доказательная база» для всех утверждений о рынке.\nПитч-дек (Pitch Deck) Что это: Это маркетинговая презентация проекта, его «демо-версия». Она должна быть яркой, убедительной и очень краткой. Это наш «UI/UX» для бизнес-идеи, который должен зацепить и вызвать интерес.\nКлючевые характеристики:\nОбъем: 10-20 слайдов максимум. Краткость — сестра таланта. Содержание: Высоко визуальное, с минимумом текста. Акцент на графиках, диаграммах, инфографике. Фокус: Визуальный. Изображения и ключевые фразы доминируют. Аудитория: Инвесторы (венчурные фонды, бизнес-ангелы), краудфандинговые платформы, потенциальные партнеры, которым нужно быстро понять суть и потенциал проекта. Анализ: Краткое изложение ключевых моментов. Только самое важное и убедительное. Время презентации: 7-9 минут. Это очень жесткий тайминг, требующий максимальной концентрации на главном. Для нас: Результаты исследования рынка в питч-деке должны быть представлены в виде ярких, легко усваиваемых графиков и ключевых выводов. Никаких длинных текстов, только цифры и факты, которые подтверждают потенциал рынка и нашу способность его завоевать. Это наш «продающий» интерфейс, который должен вызвать желание узнать больше.\nВажный момент: Большинство проектов требуют оба документа. Питч-дек служит кратким, визуальным резюме бизнес-плана. Думай о бизнес-плане как о полной спецификации, а о питч-деке — как о высокоуровневой архитектурной диаграмме. Оба важны, но для разных целей.\nГлава 5.2: Структура бизнес-плана. Куда вставлять наши данные. Комплексный бизнес-план — это не просто набор разделов, а логически связанная система, где каждый элемент подкрепляет другие. Для нас, инженеров, важно понимать, как результаты нашего исследования рынка интегрируются в эту структуру, чтобы создать убедительный и обоснованный документ. Вот основные разделы, которые должен включать бизнес-план:\n1. Резюме (Executive Summary) Суть: Краткий обзор всего плана. Пишется в последнюю очередь, но располагается в начале. Должно быть цепляющим и визуально привлекательным. Наши данные: Здесь ты кратко излагаешь ключевые выводы из исследования рынка: размер рынка, основные тренды, уникальное ценностное предложение, подтвержденное валидацией рынка. Это как аннотация к техническому документу — должна дать полное представление о содержании. 2. Общие сведения о компании (Company Background) Суть: Миссия, видение, история компании, уникальное ценностное предложение (1-2 предложения). Наши данные: Здесь можно упомянуть, как исследование рынка помогло сформировать или уточнить миссию и видение, а также подтвердить уникальность нашего предложения на фоне конкурентов. 3. Анализ рынка (Market Analysis) Суть: Это основной раздел, где детально представлены результаты нашего исследования рынка. Наши данные: Расчеты размера рынка: Подробно TAM, SAM, SOM, методология расчета. Прогнозы роста: На основе собранных данных о трендах и драйверах. Тренды, драйверы и барьеры: Детальное описание факторов, влияющих на рынок. Концентрация рынка: Анализ структуры рынка и основных игроков. 4. Анализ целевой аудитории (Target Audience Analysis) Суть: Подробное описание тех, для кого мы работаем. Наши данные: Демография/фирмография: Кто наш клиент (возраст, пол, доход, отрасль, размер компании и т.д.). Болевые точки и потребности: Что их беспокоит, какие проблемы мы решаем. Покупательское поведение: Как они принимают решения о покупке. Сегментация рынка: Как мы делим нашу аудиторию на группы. 5. Проблема и решение (Problem and Solution) Суть: Четкое изложение проблем клиентов и того, как наше решение их устраняет. Описание уникального подхода и преимуществ. Наши данные: Здесь ты используешь результаты анализа болевых точек (Глава 4.1) и подтверждаешь, что наше решение действительно решает эти проблемы, опираясь на данные валидации рынка. 6. Анализ конкурентов (Competitor Analysis) Суть: Детальный разбор наших конкурентов. Наши данные: Профили конкурентов: Краткие досье на каждого. Картирование конкурентных преимуществ: Матрица сравнения функций и возможностей. Позиционирование на рынке: Где мы находимся относительно конкурентов. 7. SWOT-анализ (SWOT Analysis) Суть: Анализ сильных и слабых сторон компании, а также возможностей и угроз на рынке. Наши данные: Все данные из исследования рынка (тренды, конкуренты, целевая аудитория) используются для выявления возможностей и угроз. Внутренние сильные и слабые стороны также должны быть подкреплены фактами. 8. Маркетинговый план (Marketing Plan) Суть: Как мы будем продвигать наш продукт. Наши данные: Исследование рынка дает основу для определения стратегии выхода на рынок, выбора каналов и тактик, разработки сообщений и модели привлечения клиентов. 9. Операционный план (Operational Plan) Суть: Как будет работать наш бизнес (процессы, ресурсы, команда, дорожная карта разработки). Наши данные: Хотя это больше про внутренние процессы, исследование рынка может повлиять на выбор ресурсов и инфраструктуры, а также на дорожную карту разработки, исходя из потребностей рынка. 10. Финансовый план (Financial Plan) Суть: Прогнозы выручки, структура затрат, расчет ROI, потребности в финансировании. Наши данные: Все финансовые прогнозы напрямую зависят от расчетов размера рынка, прогнозов роста, анализа конкурентов и готовности платить целевой аудитории. Это наш «финансовый движок», работающий на данных исследования. 11. Таймлайн/Дорожная карта (Timeline/Roadmap) Суть: Ключевые вехи, этапы разработки, сроки выхода на рынок, этапы роста. Наши данные: Исследование рынка помогает определить реалистичные сроки выхода на рынок и этапы роста, исходя из рыночных условий и конкурентной среды. Про-совет: Для объемных разделов (анализ рынка, целевой аудитории, конкурентов) всегда включай одностраничное резюме в начале каждого раздела, чтобы выделить ключевые выводы. Это как «README.md» для каждого большого модуля.\nГлава 5.3: Структура питч-дека. Как продать идею за 7 минут. Питч-дек — это не просто набор слайдов, это инструмент для быстрой и эффективной коммуникации. Его цель — не рассказать все, а заинтересовать, вызвать желание узнать больше. Думай о нем как о высокоуровневой архитектурной диаграмме: она не содержит всех деталей реализации, но дает полное представление о системе и ее ценности. Вот что должен включать эффективный питч-дек:\n1. Проблема и Возможность (Problem and Opportunity) Суть: Четко сформулируй, какую проблему ты решаешь, насколько она масштабна и почему именно сейчас настало время для ее решения. Наши данные: Используй данные из исследования рынка о болевых точках целевой аудитории (Глава 4.1) и размере рынка (Глава 2.3), чтобы показать масштаб проблемы и потенциал возможности. 2. Решение (Solution) Суть: Кратко опиши свой продукт/сервис и как он решает выявленные проблемы. Наши данные: Здесь ты демонстрируешь, как твое решение соответствует потребностям рынка, подтвержденным исследованием. Фокусируйся на ключевых функциях и преимуществах. 3. Технология/Инновация (Technology/Innovation) Суть: Объясни, как работает твое решение, в чем его уникальность и какие есть барьеры для входа конкурентов (например, патенты, уникальные алгоритмы). Наши данные: Если исследование рынка выявило технологические тренды или пробелы у конкурентов, здесь можно показать, как твоя технология использует эти возможности. 4. Размер рынка (Market Size) Суть: Визуализируй TAM, SAM, SOM. Покажи потенциал роста. Наши данные: Используй графики и диаграммы из Главы 2.3, чтобы наглядно продемонстрировать объем рынка и твою потенциальную долю. 5. Бизнес-модель (Business Model) Суть: Как ты будешь зарабатывать деньги (потоки доходов, стратегия ценообразования, каналы продаж). Наши данные: Исследование рынка помогает обосновать выбранную бизнес-модель, показывая, что она соответствует ожиданиям целевой аудитории и конкурентной среде. 6. План выхода на рынок (Go-To-Market Plan) Суть: Как ты будешь привлекать клиентов (стратегия привлечения, маркетинговые каналы, подход к продажам). Наши данные: Основывается на анализе целевой аудитории и конкурентов. Какие каналы наиболее эффективны для нашей ЦА? Как конкуренты привлекают клиентов? 7. Конкуренция (Competition) Суть: Покажи, кто твои конкуренты, и в чем твои конкурентные преимущества. Используй картирование конкурентов. Наши данные: Здесь ты используешь результаты анализа конкурентов (Глава 3.4), чтобы наглядно продемонстрировать свое уникальное позиционирование на рынке. 8. Команда (Team) Суть: Представь ключевых членов команды, их релевантный опыт, советников и партнеров. Наши данные: Хотя это не напрямую связано с исследованием рынка, сильная команда, понимающая рынок, всегда является плюсом. 9. Финансовые прогнозы (Financial Projections) Суть: Краткий прогноз выручки, ключевые метрики и график прибыльности. Наши данные: Используй агрегированные данные из финансового плана (Глава 2.4), чтобы показать потенциальную прибыльность проекта. Только самые важные цифры. 10. Финансирование (Funding) Суть: Сколько денег нужно, на что они будут потрачены и какой ожидается возврат. Наши данные: Исследование рынка помогает обосновать запрашиваемую сумму, показывая потенциал роста и прибыльности. 11. Таймлайн (Timeline) Суть: Дорожная карта разработки, ключевые вехи и долгосрочное видение. Наши данные: Исследование рынка помогает определить реалистичные сроки и этапы развития, исходя из рыночных условий. Итог: Питч-дек — это твой шанс произвести первое впечатление. Каждый слайд должен быть максимально информативным и визуально привлекательным. Используй результаты исследования рынка, чтобы подкрепить свои утверждения фактами и цифрами, но делай это кратко и наглядно. Это наш «продающий» интерфейс, который должен вызвать желание «кликнуть» и узнать больше.\nГлава 5.4: Лучшие практики визуализации. Как показать данные красиво и понятно. Данные исследования рынка — это мощный инструмент, но только если их правильно представить. Гора цифр и таблиц никому не нужна. Наша задача — превратить их в понятные, убедительные и визуально привлекательные графики и диаграммы. Думай об этом как о создании интуитивно понятного интерфейса для сложной системы. Вот несколько принципов.\n1. Техники фокусировки (Focus Techniques) Создавай визуальный фокус на каждом слайде, чтобы сразу было понятно, что главное:\nЦветовой контраст: Используй разные цвета для ключевой информации. Например, если все графики синие, выдели важный показатель красным. Изменение размера: Более крупные элементы привлекают внимание к важным данным. Ключевые цифры или заголовки можно сделать больше. Изменение ориентации: Разные углы или направления могут выделить элемент. Например, если все столбцы вертикальные, один горизонтальный столбец будет выделяться. 2. Принципы дизайна (Design Principles) Один фокус на слайд: Каждый слайд должен доносить одну главную идею. Не пытайся впихнуть все и сразу. Это как один метод на класс — четко и по делу. Минимум текста: Используй визуальные элементы для передачи информации, где это возможно. Текст должен быть только там, где без него не обойтись. Единая цветовая схема: Ограничься 2-3 цветами (плюс серый). Слишком много цветов создают визуальный хаос. Это как единый стиль кодирования для всего проекта. Простые графики: Выбирай самые понятные визуализации для сравнений. Не усложняй там, где можно упростить. Логический порядок: Представляй данные в логической последовательности (от большего к меньшему, хронологически и т.д.). Это как последовательность шагов в алгоритме. Без дублирования: Не повторяй одну и ту же информацию в разных формах. Если что-то уже показано на графике, не дублируй это в тексте. 3. Распространенные типы визуализации (Common Visualization Types) Процессы: Блок-схемы, таймлайны. Для демонстрации последовательности действий. Иерархии: Организационные диаграммы, пирамиды. Для показа структуры или подчиненности. Сравнения: Столбчатые диаграммы, точечные диаграммы. Для сопоставления различных показателей. Композиция: Круговые диаграммы, стековые столбчатые диаграммы. Для показа частей целого. Взаимосвязи: Пузырьковые диаграммы, матрицы. Для демонстрации связей между элементами. Тренды: Линейные графики, графики областей. Для показа изменений во времени. 4. Чего НЕ стоит делать при визуализации (Visualization Don\u0026rsquo;ts) Слишком много цветов: Создает визуальную путаницу. Это как код с сотней разных шрифтов и цветов — читать невозможно. Сложные графики: Делает данные трудными для понимания. Если график требует 5 минут на расшифровку, он плох. Нелогичный порядок: Путает аудиторию. Данные должны течь естественно. Перегрузка текстом: Смысл визуализации теряется, если она забита текстом. Это как UI, где все кнопки подписаны огромными абзацами. Непоследовательный стиль: Выглядит непрофессионально. Единый стиль во всем документе. Повторяющиеся элементы: Трата визуального пространства. Каждый элемент должен нести новую информацию. Итог: Визуализация — это не просто украшение, это мощный инструмент для донесения информации. Правильно представленные данные исследования рынка могут быть гораздо убедительнее, чем сотни страниц текста. Это наш «фронтенд» для бизнес-аналитики, который должен быть максимально user-friendly.\nГлава 5.5: Канва бизнес-модели. Вся суть на одной странице. Канва бизнес-модели (Business Model Canvas) — это стратегический инструмент управления, который позволяет наглядно и структурированно описать, как организация создает, доставляет и захватывает ценность. Думай о ней как о высокоуровневой архитектурной схеме, которая показывает все ключевые компоненты системы и их взаимосвязи. Это идеальный инструмент для быстрого обзора твоей бизнес-модели для стейкхолдеров.\nКанва состоит из девяти взаимосвязанных блоков:\n1. Ценностные предложения (Value Propositions) Что это: Что ты предлагаешь клиентам? Какие проблемы ты решаешь? Какие потребности удовлетворяешь? Почему клиенты должны выбрать именно тебя, а не конкурентов? Для нас: Это наш «функционал» и «преимущества». Здесь мы формулируем, какую ценность наш продукт или сервис несет для пользователя, основываясь на исследовании болевых точек и потребностей целевой аудитории. 2. Потребительские сегменты (Customer Segments) Что это: Для кого ты создаешь ценность? Кто твои самые важные клиенты? Какие у них характеристики, потребности, поведение? Для нас: Это наша «целевая аудитория», которую мы детально изучали в Главе 4. Здесь мы четко определяем, кто наш идеальный пользователь. 3. Каналы сбыта (Channels) Что это: Как ты доставляешь свои ценностные предложения до потребительских сегментов? Как клиенты узнают о тебе, покупают и получают твой продукт/сервис? Для нас: Это наши «каналы дистрибуции» и «маркетинговые каналы». Например, онлайн-платформы, прямые продажи, партнерские сети. 4. Взаимоотношения с клиентами (Customer Relationships) Что это: Какие типы взаимоотношений ты устанавливаешь и поддерживаешь с каждым потребительским сегментом? Это может быть персональное обслуживание, самообслуживание, сообщества и т.д. Для нас: Это наш «саппорт» и «коммуникационная стратегия». Как мы взаимодействуем с пользователями после того, как они начали использовать наш продукт? 5. Потоки доходов (Revenue Streams) Что это: Как ты зарабатываешь деньги? За что клиенты готовы платить? Какие есть источники дохода (продажи, подписки, лицензии и т.д.)? Для нас: Это наша «монетизация». Здесь мы описываем, как наш продукт будет генерировать прибыль, основываясь на анализе готовности платить целевой аудитории и ценовой политике конкурентов. 6. Ключевые ресурсы (Key Resources) Что это: Какие активы необходимы для создания и доставки ценностного предложения? Это могут быть физические активы, интеллектуальная собственность, человеческие ресурсы, финансовые ресурсы. Для нас: Это наши «ресурсы разработки»: команда, технологии, патенты, инфраструктура. Что нам нужно, чтобы создать и поддерживать продукт? 7. Ключевые виды деятельности (Key Activities) Что это: Какие самые важные действия ты должен выполнять, чтобы твой бизнес работал? Это может быть разработка продукта, маркетинг, продажи, поддержка клиентов. Для нас: Это наши «основные процессы»: разработка ПО, тестирование, развертывание, поддержка, presale-активности. 8. Ключевые партнеры (Key Partners) Что это: Кто твои ключевые поставщики и партнеры? Какие ресурсы или виды деятельности они предоставляют? Для нас: Это наши «внешние зависимости»: поставщики облачных сервисов, библиотеки, фреймворки, партнеры по внедрению, консалтинговые компании. 9. Структура издержек (Cost Structure) Что это: Какие самые значительные затраты возникают при работе твоей бизнес-модели? Это могут быть затраты на разработку, маркетинг, персонал, инфраструктуру. Для нас: Это наши «операционные расходы» и «стоимость разработки». Здесь мы суммируем все затраты, необходимые для создания и поддержания продукта. Итог: Канва бизнес-модели — это не просто таблица, это живой инструмент для проектирования и анализа. Она позволяет быстро увидеть, как все элементы твоего бизнеса взаимосвязаны, выявить слабые места и найти новые возможности. Для инженера это способ понять бизнес-контекст своего продукта и увидеть, как его технические решения вписываются в общую картину.\nГлава 6.1: Подход «облака синонимов». Расширяем поисковый арсенал. Обычный поиск в Google — это хорошо, но для профессионального исследования рынка его недостаточно. Фундаментальное отличие между обычным поиском и профессиональным исследованием заключается в создании всеобъемлющего «облака синонимов» для твоей темы поиска. Думай об этом как о расширении словаря ключевых слов для индексации, чтобы ничего не упустить.\nПочему «облака синонимов» важны? Большинство людей делают один поисковый запрос и сдаются, если не находят то, что им нужно. Профессиональные исследователи поступают иначе:\nСоздают множество вариантов поиска: Не ограничиваются одной формулировкой. Пробуют различные комбинации терминологии: Сочетают разные слова и фразы. Исследуют альтернативные формулировки: Ищут другие способы выразить ту же мысль. Учитывают отраслевую специфику терминологии: В каждой отрасли есть свой жаргон и специфические термины, которые могут быть неизвестны широкой публике. Для нас: Это означает, что если мы ищем информацию по «AI-решениям для логистики», то не стоит ограничиваться только этой фразой. Нужно подумать, как еще это могут называть, какие синонимы использовать, какие смежные понятия могут быть релевантны.\nСоздание «облака синонимов» Перед началом поиска разработай как минимум 5-6 различных способов сформулировать свой запрос. Это как создать несколько вариантов регулярного выражения для поиска нужных данных.\nПример для статистики автомобильного рынка:\n\u0026quot;car statistics [country]\u0026quot; (статистика автомобилей [страна]) \u0026quot;automotive industry data [country]\u0026quot; (данные автомобильной промышленности [страна]) \u0026quot;vehicle sales figures [country]\u0026quot; (показатели продаж транспортных средств [страна]) \u0026quot;auto market analysis [country]\u0026quot; (анализ автомобильного рынка [страна]) \u0026quot;[country] car market size\u0026quot; (размер автомобильного рынка [страна]) \u0026quot;automobile industry report [country]\u0026quot; (отчет об автомобильной промышленности [страна]) Ресурсы для создания «облака синонимов» Wikipedia: Изучай страницы по теме, чтобы найти отраслевую терминологию и альтернативные фразы. Часто в статьях есть разделы «См. также» или «Связанные понятия», которые могут дать новые идеи. Первые результаты Google: Просканируй первые статьи в выдаче, чтобы найти специализированные термины, которые ты, возможно, не учел. Часто авторы используют разные формулировки для одной и той же идеи. Словари синонимов: Используй онлайн-инструменты, такие как Synonyms and Antonyms of Words | Thesaurus.com, для поиска альтернативных слов. Mind Mapping (Интеллект-карты): Для сложных тем создавай визуальные карты связанных понятий. Это помогает структурировать мысли и выявить неочевидные связи между терминами. Итог: Подход «облака синонимов» — это не просто набор трюков, это фундаментальный принцип эффективного поиска. Он позволяет значительно расширить охват информации, найти неочевидные источники и получить более полную картину по интересующей теме. Это наш «расширенный поиск» для исследования рынка.\nГлава 6.2: Эффективный процесс поиска. Наш алгоритм разведки. Иметь «облако синонимов» — это полдела. Важно еще уметь эффективно использовать его в процессе поиска. Думай об этом как о хорошо отлаженном скрипте: каждый шаг логичен и ведет к получению нужных данных. Вот трехэтапный процесс, который поможет тебе в этом.\nТрехэтапный процесс: Поиск с использованием «облака синонимов» (Search using your synonym cloud).\nСуть: Используй каждый вариант из своего «облака синонимов» для поиска. Просматривай 4-5 верхних результатов для каждого запроса. Для нас: Это как запустить несколько разных тестов с разными входными данными. Мы не ограничиваемся одним запросом, а исследуем тему с разных сторон. Первые несколько результатов обычно наиболее релевантны, но не всегда. Сбор источников, упомянутых в результатах (Collect sources mentioned in results).\nСуть: Обращай внимание на ссылки, источники и упомянутые исследования в найденных статьях. Это могут быть ссылки на научные работы, отчеты аналитических агентств, государственные публикации. Для нас: Это наш «граф зависимостей». Если авторитетный источник ссылается на другое исследование, это, скорее всего, ценный источник информации. Это позволяет углубиться в тему и найти первоисточники. Изучение этих вторичных источников (Follow up on these secondary sources).\nСуть: Часто самая ценная информация находится не в первых результатах поиска, а в тех источниках, на которые ссылаются эти результаты. Это как найти ссылку на GitHub-репозиторий в статье и потом изучить сам код. Для нас: Это позволяет получить более глубокое понимание темы, проверить достоверность информации и найти данные, которые не были доступны на первом этапе. Это наш «рекурсивный поиск». Расширенные команды Google Search Для более точного и эффективного поиска используй специальные операторы Google. Думай о них как о параметрах командной строки для твоего поискового запроса.\nOR: Ищет любой из терминов. Например, car OR automotive statistics найдет страницы, содержащие либо «car statistics», либо «automotive statistics». \u0026quot;\u0026quot; (кавычки): Ищет точную фразу. Например, \u0026quot;automotive market size\u0026quot; найдет страницы, где эта фраза встречается именно в таком виде. AND: Требует наличия обоих терминов. Например, market AND statistics найдет страницы, содержащие и «market», и «statistics». (По умолчанию Google и так ищет по AND, но явное указание может быть полезно для сложных запросов). Настройки местоположения (Location Settings) Измени настройки местоположения Google, чтобы они соответствовали твоему целевому рынку. Это гарантирует, что ты увидишь результаты, релевантные именно этому региону.\nНажми «Настройки» (Settings). Выбери «Настройки поиска» (Search Settings). Измени «Регион» (Region) на свой целевой рынок. Итог: Эффективный процесс поиска — это не просто умение пользоваться Google, а системный подход к сбору информации. Используя «облако синонимов», следуя трехэтапному процессу и применяя расширенные команды, ты сможешь значительно повысить качество и релевантность своих поисковых запросов. Это наш «оптимизированный алгоритм» для сбора данных.\nГлава 6.3: Инструменты для улучшения поиска. Наш набор утилит. Помимо базовых поисковых запросов и операторов, существуют специализированные инструменты, которые могут значительно ускорить и улучшить процесс сбора информации. Думай о них как о плагинах или скриптах, которые расширяют функционал твоего браузера и поисковой системы. Вот несколько полезных инструментов:\n1. Multi Highlighter (Мульти-выделитель) Что это: Расширение для Chrome, которое позволяет выделять несколько ключевых слов на странице одновременно. Для чего: Помогает быстро сканировать длинные документы на предмет релевантной информации. Экономит время, визуально идентифицируя ключевые разделы. Это как grep для веб-страниц, но с подсветкой. 2. Google Dictionary (Словарь Google) Что это: Расширение для Chrome, которое определяет термины по простому клику. Для чего: Очень полезно для понимания отраслевой терминологии. Избавляет от необходимости искать каждое незнакомое слово отдельно. Это как встроенный man для терминов. 3. Simple Scraper (Простой скрепер) Что это: Инструмент для извлечения структурированных данных с веб-сайтов. Преобразует неструктурированный веб-контент в организованные таблицы и экспортирует данные в форматы, совместимые с Excel. Для чего: Если тебе нужно собрать данные из таблиц на сайтах или извлечь повторяющуюся информацию, этот инструмент сэкономит часы ручной работы. Это как awk или sed для веб-страниц, но с графическим интерфейсом. 4. Google Alerts (Оповещения Google) Что это: Инструмент для мониторинга текущих исследований. Отправляет уведомления, когда новый контент соответствует твоим поисковым запросам. Для чего: Настрой оповещения для: Названий конкурентов Отраслевых трендов Рыночной статистики Ключевых технологий Это как cron job, который регулярно проверяет интернет на наличие новой информации по интересующим тебя темам. Позволяет быть в курсе событий, не тратя время на постоянный ручной поиск. Итог: Эти инструменты — твои помощники в борьбе с информационным шумом. Они позволяют автоматизировать рутинные задачи, ускорить процесс анализа и быть в курсе последних событий на рынке. Используй их, чтобы сделать свой процесс исследования рынка более эффективным и менее трудозатратным.\nГлава 6.4: Лучшие практики эффективности исследования. Как не тратить время впустую. Эффективность — наше все. В мире, где информация множится с каждой секундой, умение быстро и качественно находить нужные данные становится ключевым навыком. Думай об этом как об оптимизации алгоритма: чем меньше лишних операций, тем быстрее результат. Вот несколько лучших практик, которые помогут тебе в этом.\n1. Проверяй результаты поиска по изображениям (Check image search results). Суть: Часто ценные графики, диаграммы и визуализации содержатся в изображениях, а не в тексте. Google Images может быть отличным источником данных. Для нас: Это как посмотреть на архитектурную схему вместо чтения тысяч строк кода. Визуализация часто доносит информацию быстрее и понятнее. Ищи инфографику, графики трендов, сравнительные таблицы. 2. Проверяй достоверность источника (Verify source credibility). Суть: Не вся информация одинаково надежна. Правительственные сайты, академические учреждения и авторитетные исследовательские фирмы — самые надежные источники. Для нас: Это как проверять репутацию библиотеки или фреймворка перед использованием. Доверяй, но проверяй. Избегай блогов без ссылок на источники, сомнительных новостных сайтов и форумов как единственного источника информации. 3. Ищи даты публикации (Look for publication dates). Суть: Приоритизируй свежую информацию. В нашей быстро меняющейся сфере данные двухлетней давности могут быть уже неактуальны. Для нас: Это как проверять дату последнего коммита в репозитории. Чем свежее, тем лучше. Используй фильтры по дате в поисковых системах. 4. Изучай описания источников (Examine source descriptions). Суть: Прежде чем кликать на ссылку, прочитай сниппет Google. Он часто дает достаточно информации, чтобы понять, релевантен ли источник. Для нас: Это как читать описание функции перед ее вызовом. Экономит время, предотвращая переход на нерелевантные страницы. 5. Будь методичен (Be methodical). Суть: Документируй свой процесс поиска и найденные результаты. Веди записи о том, что ты искал, где, что нашел и какие выводы сделал. Для нас: Это как ведение логов или системы контроля версий для твоего исследования. Позволяет отслеживать прогресс, избегать повторений и легко возвращаться к предыдущим шагам. Используй таблицы или специализированные инструменты для ведения заметок. 6. Используй расширенную фильтрацию (Use advanced filtering). Суть: Ограничивай результаты по дате, типу файла или домену. Например, site:.gov для правительственных сайтов, filetype:pdf для PDF-документов. Для нас: Это как использовать мощные фильтры в IDE для поиска нужного кода. Позволяет сузить область поиска и получить более точные результаты. 7. Итерируй свои поисковые запросы (Iterate your searches). Суть: Уточняй запросы на основе того, что ты узнал из первоначальных результатов. Каждый найденный факт может дать новую идею для поиска. Для нас: Это как цикл разработки: итерация, тестирование, улучшение. Не бойся менять запросы, если видишь, что они не дают нужных результатов. Итог: Эти практики — твой арсенал для эффективного исследования. Применяя их, ты сможешь значительно сократить время на поиск информации, повысить ее качество и получить более глубокие инсайты. Это наш «Agile-подход» к сбору данных.\nГлава 6.5: Распространенные ошибки при поиске. Как не наступить на грабли. Даже опытные исследователи могут допускать ошибки при поиске информации. Знание этих «граблей» поможет тебе их избежать и сделать процесс более эффективным. Думай об этом как о списке известных багов, которые нужно обходить стороной.\n1. Поиск по одному ключевому слову (Single keyword searching). Ошибка: Использование только одного термина или фразы для поиска. Почему плохо: Ты упускаешь огромное количество релевантной информации, которая может быть сформулирована иначе. Это как искать функцию по одному слову, когда она может быть частью более сложного названия или находиться в другом модуле. Как избежать: Используй подход «облака синонимов» (Глава 6.1). Всегда генерируй несколько вариантов запроса. 2. Игнорирование альтернативной терминологии (Ignoring alternative terminology). Ошибка: Неучет специфической для отрасли или региона терминологии. Почему плохо: Разные индустрии или страны могут использовать разные слова для обозначения одних и тех же понятий. Если ты не знаешь этого жаргона, ты не найдешь нужную информацию. Как избежать: Активно используй Wikipedia, отраслевые глоссарии и первые результаты поиска для выявления специфических терминов. 3. Остановка на первой странице (Stopping at the first page). Ошибка: Не пробовать несколько вариантов поиска и не углубляться дальше первой страницы результатов. Почему плохо: Самая ценная информация часто находится не на первой странице. Первые результаты могут быть рекламными или слишком общими. Как избежать: Всегда пробуй несколько вариантов запроса и просматривай хотя бы 2-3 страницы результатов. Используй трехэтапный процесс поиска (Глава 6.2). 4. Игнорирование результатов поиска по изображениям (Overlooking image results). Ошибка: Не проверять вкладку «Картинки» в поисковых системах. Почему плохо: Многие ценные визуализации (графики, диаграммы, инфографика) могут быть представлены в виде изображений и не всегда индексируются текстовым поиском. Как избежать: Всегда проверяй результаты поиска по изображениям (Глава 6.4). 5. Принятие информации без проверки (Accepting information without verification). Ошибка: Доверие к первому попавшемуся источнику без перекрестной проверки. Почему плохо: В интернете много недостоверной, устаревшей или предвзятой информации. Опираясь на нее, ты рискуешь принять неверные решения. Как избежать: Всегда проверяй достоверность источника (Глава 6.4) и ищи подтверждение информации в нескольких независимых источниках. 6. Использование неподходящих географических настроек (Using inappropriate geography settings). Ошибка: Поиск информации без учета региональной специфики, когда это важно. Почему плохо: Результаты могут быть нерелевантны твоему целевому рынку. Например, статистика по США не всегда применима к рынку СНГ. Как избежать: Всегда настраивай географические параметры поиска (Глава 6.2), если твой рынок имеет региональные особенности. 7. Неследование по ссылкам (Not following citation trails). Ошибка: Не изучать источники, на которые ссылаются найденные статьи или отчеты. Почему плохо: Часто самые ценные данные находятся в первоисточниках, которые упоминаются в обзорах или статьях. Это как найти ссылку на библиотеку, но не посмотреть ее документацию. Как избежать: Всегда следуй по ссылкам и изучай вторичные источники (Глава 6.2). Итог: Избегая этих распространенных ошибок, ты значительно повысишь эффективность своего исследования рынка. Это позволит тебе находить высококачественную информацию, экономить время и ресурсы, а также принимать более обоснованные решения. Это наш «список исключений», который нужно всегда держать в уме.\nГлава 7.1: Влияние ИИ на методологии исследования. Новый игрок на поле. Искусственный интеллект (ИИ) стремительно меняет ландшафт многих отраслей, и исследование рынка не исключение. Он предлагает новые возможности, но также имеет свои ограничения. Понимание того, когда и как использовать ИИ, может значительно повысить эффективность исследования. Думай об ИИ как о новом, очень мощном, но пока еще не до конца освоенном инструменте в нашем арсенале.\nТекущие сильные стороны ИИ в исследованиях: ИИ уже сейчас отлично справляется с задачами, требующими обработки больших объемов данных и выявления паттернов:\nАнализ открытых ответов (Open-ended question analysis): ИИ может быстро анализировать тысячи текстовых ответов на открытые вопросы, выявляя ключевые темы и паттерны. Это как автоматический парсер логов, который сам находит аномалии. Обработка транскриптов интервью (Interview transcript processing): Автоматическая транскрипция и суммаризация интервью/фокус-групп. Значительно экономит время на ручную обработку. Суммаризация вторичных исследований (Secondary study summarization): Извлечение релевантной информации из объемных отчетов. ИИ может быстро «прочитать» сотни документов и выделить главное. Анализ отзывов (Review analysis): Обработка больших объемов отзывов о продуктах для выявления трендов и настроений. Помогает понять, что нравится и не нравится пользователям. Генерация идей (Idea generation): Предоставление альтернативных перспектив и подходов. ИИ может предложить новые идеи, основываясь на анализе существующих данных. Текущие ограничения ИИ: Несмотря на все преимущества, ИИ пока не может полностью заменить человека, особенно в задачах, требующих глубокого понимания контекста и критического мышления:\nПодготовка отчетов по исследованию рынка (Market research report preparation): Полные отчеты по-прежнему требуют человеческой экспертизы для обеспечения качества, связности и глубины анализа. ИИ может помочь с черновиками, но финальная версия — за человеком. Поиск статистики (Statistics searching): Часто предоставляет устаревшие или непроверяемые данные. ИИ не всегда может отличить надежный источник от сомнительного. Количественный анализ (Quantitative analysis): Ошибки в расчетах и методологические ограничения. ИИ может ошибаться в сложных статистических выкладках. Анализ стратегических шагов (Strategic moves analysis): Ограничен актуальностью обучающих данных. ИИ не всегда может предсказать будущие стратегические шаги конкурентов, так как его данные основаны на прошлом. Проектирование анкет (Questionnaire design): Создает базовые дизайны, которым не хватает методологической изощренности. ИИ пока не может полностью заменить опытного исследователя в формулировании вопросов, которые действительно выявляют глубокие инсайты. Итог: ИИ — это мощный инструмент для автоматизации рутинных задач и обработки больших объемов данных. Он может значительно ускорить процесс исследования и выявить паттерны, которые человек мог бы пропустить. Однако он не заменяет критическое мышление, глубокий анализ и человеческую экспертизу. Лучший подход — это гибридный, где ИИ выступает в роли помощника, а человек — в роли архитектора и контролера. Это как использовать автогенерацию кода, но всегда проводить код-ревью.\nГлава 7.2: Эффективные промпты для ИИ-исследований. Как говорить с машиной. ИИ-инструменты, такие как ChatGPT, становятся все более мощными, но их эффективность напрямую зависит от того, насколько хорошо ты умеешь формулировать запросы (промпты). Плохой промпт — это как неверный SQL-запрос: ты получишь либо ошибку, либо нерелевантные данные. Хороший промпт — это ключ к получению ценных инсайтов. Вот лучшие практики для составления промптов:\nЛучшие практики для ИИ-промптов: Предоставляй детальный контекст (Provide detailed context).\nСуть: Объясни свой проект, целевую аудиторию и цели исследования максимально подробно. Чем больше ИИ знает о твоей задаче, тем точнее будут его ответы. Пример: Вместо «Расскажи о рынке ПО» напиши: «Я — старший инженер в R\u0026amp;D отделе, работаю над новым AI-решением для автоматизации логистики в малом и среднем бизнесе в СНГ. Моя цель — понять потенциальный размер рынка и ключевые болевые точки клиентов. Целевая аудитория — логистические компании с автопарком до 50 машин.» Задавай конкретные вопросы (Ask specific questions).\nСуть: Избегай расплывчатых запросов. Будь точен в том, что ты хочешь узнать. Это как писать юнит-тест: он должен проверять конкретную функциональность. Пример: Вместо «Что ты знаешь о конкурентах?» напиши: «Какие ключевые функции предлагают основные конкуренты в сфере AI-решений для логистики? Какие у них модели ценообразования?» Включай известную информацию (Include known information).\nСуть: Предоставляй ИИ контекст и данные, которые у тебя уже есть. Это помогает ему строить ответы на основе проверенной информации и избегать галлюцинаций. Пример: «Я уже знаю, что рынок логистики в СНГ растет на 15% в год. Какие новые тренды в AI-решениях для логистики могут повлиять на этот рост?» Запрашивай уточняющие вопросы (Request clarification questions).\nСуть: Добавь в промпт фразу типа «Пожалуйста, задай мне один уточняющий вопрос, чтобы улучшить свой ответ». Это заставляет ИИ глубже погрузиться в тему и помогает тебе понять, что ему не хватает для более точного ответа. Пример: «\u0026hellip;Пожалуйста, задай мне один уточняющий вопрос, чтобы улучшить свой ответ.» Проверяй выводы (Verify outputs).\nСуть: Всегда перепроверяй фактические утверждения и данные, полученные от ИИ. ИИ может «галлюцинировать» или выдавать устаревшую информацию. Для нас: Это как код-ревью для результатов ИИ. Не доверяй слепо, всегда проверяй источники и логику. Итерируй с обратной связью (Iterate with feedback).\nСуть: Уточняй ответы ИИ с помощью последующих вопросов. Если первый ответ не идеален, не сдавайся. Дай обратную связь и попроси переформулировать или углубиться. Для нас: Это как отладка: шаг за шагом, уточняя параметры, мы приходим к нужному результату. Пример структуры промпта: Я [твоя роль] работаю над [конкретный проект]. Целевая аудитория — [детали]. Мне нужно понять [конкретный вопрос/проблема]. Вот что я уже знаю: [контекст/данные]. Пожалуйста, предоставь [конкретный запрос]. Вместе с ответом, пожалуйста, задай мне один уточняющий вопрос, который поможет тебе дать более ценный ответ. Итог: Эффективные промпты — это искусство и наука одновременно. Чем лучше ты научишься формулировать свои мысли для ИИ, тем более мощным инструментом он станет в твоих руках для исследования рынка. Это наш «язык программирования» для взаимодействия с искусственным интеллектом.\nГлава 7.3: ИИ-инструменты для исследования рынка. Наш цифровой арсенал. Мир ИИ-инструментов развивается стремительно, и каждый день появляются новые решения. Однако есть несколько ключевых игроков, которые уже зарекомендовали себя в сфере исследования рынка. Думай о них как о специализированных библиотеках или фреймворках, каждый из которых заточен под свою задачу. Вот обзор некоторых из них:\n1. ChatGPT Для чего лучше всего: Анализ открытых ответов в опросах: быстро выявляет паттерны и темы в больших объемах текста. Суммаризация отзывов конкурентов: помогает понять сильные и слабые стороны конкурентов по мнению пользователей. Генерация исследовательских гипотез: может предложить новые идеи для исследования на основе имеющихся данных. Улучшение дизайна анкет: с помощью подсказок может помочь в формулировке вопросов. Советы по использованию: Загружай ответы на опросы и проси выявить паттерны. Запрашивай точные процентные соотношения при анализе текстовых данных. Проси предложить улучшения для твоих анкет. Задавай уточняющие вопросы для доработки результатов. 2. Agent GPT Для чего лучше всего: Создание структурированных планов исследования рынка: может помочь в разработке пошаговых планов. Выполнение многоэтапных исследовательских задач: способен выполнять последовательности действий для сбора информации. Предоставление информации о рынке с указанием источников: старается ссылаться на источники, что важно для проверки. Особенности: Создает последовательности исследовательских задач. Ищет информацию в интернете. Предоставляет источники для проверки. Имеет структурированный формат отчетов. 3. Lumina Для чего лучше всего: Академические исследования рынка: подходит для более формальных и глубоких исследований. Отчеты с большим количеством цитат: если нужна строгая научная база. Анализ в стиле обзора литературы: помогает систематизировать существующие публикации по теме. Особенности: Формат академической статьи. Строгий подход к цитированию. Более формальный стиль анализа. 4. Julius Для чего лучше всего: Исследование, основанное на вопросах: помогает углубляться в тему, задавая связанные вопросы. Расширение исследования через связанные вопросы. Особенности: Предлагает связанные исследовательские вопросы. Интерактивный интерфейс для исследования. Пошаговый процесс анализа. 5. Durable Для чего лучше всего: Валидация бизнес-идей: помогает оценить жизнеспособность идеи. Оценка рыночной жизнеспособности: анализирует, насколько продукт будет востребован на рынке. Особенности: Структурированный фреймворк для валидации бизнеса. Оценка бизнес-модели. Несколько разделов для валидации. 6. FlowGPT Для чего лучше всего: Специализированные исследовательские задачи: может выполнять узкоспециализированные запросы. Пользовательские исследовательские инструменты: позволяет создавать свои собственные инструменты на базе ИИ. Особенности: Библиотека готовых ИИ-помощников. Специализированные инструменты для анализа опросов, создания стратегий. Промпты, разработанные сообществом. 7. Plus AI Для чего лучше всего: Визуализация результатов исследования: помогает превратить данные в наглядные графики и диаграммы. Создание презентационных слайдов: автоматизирует процесс создания презентаций. Особенности: Преобразует текст в презентационные слайды. Множество вариантов макетов. Чистое визуальное форматирование. Итог: Выбор ИИ-инструмента зависит от конкретной задачи. Используй их как специализированные инструменты, каждый для своей цели. Комбинируй их, чтобы получить максимальную эффективность и качество исследования. Это наш «набор инструментов» для цифровой разведки.\nГлава 7.4: Лучшие практики интеграции ИИ. Как заставить ИИ работать на нас. Искусственный интеллект — это не волшебная палочка, а мощный инструмент, который требует правильного подхода к интеграции. Чтобы получить максимальную отдачу от ИИ в исследовании рынка, важно придерживаться определенных принципов. Думай об этом как о внедрении новой технологии в существующий проект: нужно понимать ее возможности, ограничения и как она взаимодействует с другими компонентами.\n1. Гибридный подход (Hybrid approach). Суть: Используй ИИ для первоначального анализа и обработки больших объемов данных, а затем применяй человеческую экспертизу для валидации и интерпретации результатов. Для нас: ИИ может быстро проанализировать тысячи отзывов или документов, выявить паттерны. Но только человек может понять нюансы, контекст, эмоциональную окраску и сделать стратегические выводы. Это как автоматическое тестирование, которое выявляет баги, но человек принимает решение о их приоритете и способе исправления. 2. Проверяй фактические утверждения (Verify factual claims). Суть: Всегда перепроверяй статистические данные и фактические утверждения, полученные от ИИ. ИИ может «галлюцинировать» или выдавать устаревшую информацию. Для нас: Это критически важно. Не доверяй слепо. Всегда ищи подтверждение в надежных источниках. Это наш «контроль качества» для данных, полученных от ИИ. 3. Указывай методологии (Specify methodologies). Суть: При запросе анализа к ИИ, указывай, какие методологии ты хочешь применить. Это помогает ИИ генерировать более точные и релевантные результаты. Для нас: Если ты просишь ИИ провести SWOT-анализ, явно укажи это. Если нужен анализ настроений, уточни, какую шкалу или подход использовать. Это как передавать параметры в функцию: чем точнее, тем лучше результат. 4. Предоставляй примеры (Provide examples). Суть: Покажи ИИ примеры желаемого формата и качества вывода. Это помогает ему понять твои ожидания и генерировать более релевантные ответы. Для нас: Если тебе нужен отчет в определенном формате, покажи ИИ пример такого отчета. Если тебе нужны выводы в виде маркированного списка, покажи пример такого списка. Это как обучать модель на конкретных примерах. 5. Используй для генерации идей, а не для окончательных решений (Use for ideation, not finalization). Суть: Рассматривай результаты работы ИИ как черновики, требующие человеческой доработки и уточнения. Для нас: ИИ отлично подходит для мозгового штурма, генерации идей, суммаризации. Но финальные решения и отчеты должны быть результатом человеческого анализа и критического мышления. Это как использовать автокомплит в IDE: он помогает, но не пишет весь код за тебя. 6. Комбинируй ИИ-инструменты (Combine AI tools). Суть: Используй разные ИИ-инструменты для их соответствующих сильных сторон. Каждый инструмент имеет свою специализацию. Для нас: ChatGPT для анализа текста, Agent GPT для структурирования задач, Lumina для академических исследований, Plus AI для визуализации. Комбинируй их, чтобы получить синергетический эффект. Это как использовать набор специализированных утилит, а не пытаться решить все одной программой. Итог: Интеграция ИИ в исследование рынка — это не замена человека, а усиление его возможностей. Правильное использование ИИ позволяет автоматизировать рутинные задачи, обрабатывать большие объемы данных и выявлять новые инсайты. Но всегда помни о необходимости человеческого контроля, валидации и критического мышления. Это наш «DevOps» для ИИ-исследований.\nГлава 7.5: Пример рабочего процесса ИИ-исследования. Кейс-стади. Теория — это хорошо, но практика — лучше. Давай рассмотрим конкретный пример того, как ИИ может быть использован в реальном рабочем процессе исследования рынка. Возьмем задачу анализа открытых ответов опросов — это то, с чем часто сталкиваются в R\u0026amp;D и presale, когда нужно быстро понять настроения и мнения большого количества людей.\nПример: Анализ открытых ответов опроса Представь, что ты провел опрос среди потенциальных клиентов по поводу нового продукта, и у тебя есть тысячи текстовых ответов на открытый вопрос типа «Что вам больше всего нравится/не нравится в существующих решениях?». Ручной анализ займет недели. ИИ справится за минуты.\nЭкспорт ответов опроса в текстовый формат (Export survey responses to text format).\nДействие: Собери все ответы в один текстовый файл или в формат, который легко читается ИИ (например, CSV, где каждый ответ — отдельная строка). Для нас: Это как подготовить данные для парсинга. Чем чище и структурированнее данные на входе, тем лучше результат. Ввод ответов в ChatGPT с использованием промпта (Input responses into ChatGPT with this prompt).\nДействие: Используй ChatGPT (или другой подходящий ИИ-инструмент) и сформулируй промпт, который поможет ИИ понять задачу и выдать нужный результат. Вот пример такого промпта: Я провел опрос среди [X] респондентов по теме [тема]. Вот ответы на открытый вопрос о [конкретный вопрос]: [вставь ответы]. Пожалуйста: 1. Определи основные темы или паттерны в этих ответах. 2. Укажи приблизительный процент респондентов, упомянувших каждую тему. 3. Извлеки 2-3 репрезентативные цитаты для каждой темы. 4. Суммируй общее настроение. 5. Отметь любые удивительные или выбивающиеся из общего ряда ответы. Для нас: Это наш «запрос к API». Чем точнее и детальнее промпт, тем более релевантный и структурированный ответ ты получишь. Задавай уточняющие вопросы для изучения конкретных аспектов (Ask follow-up questions to explore specific aspects).\nДействие: После получения первого ответа от ИИ, задавай дополнительные вопросы, чтобы углубиться в интересующие тебя темы. Например: «Можешь ли ты детализировать, почему тема X так важна для респондентов?» или «Есть ли какие-либо скрытые связи между темами Y и Z?». Для нас: Это наш «интерактивный дебаг». Мы не просто получаем результат, а исследуем его, задавая уточняющие вопросы, чтобы получить более глубокие инсайты. Проверяй паттерны путем ручной выборочной проверки (Verify patterns through manual spot-checking).\nДействие: Не доверяй ИИ слепо. Выбери несколько случайных ответов и вручную проверь, насколько выводы ИИ соответствуют действительности. Это особенно важно для критически важных выводов. Для нас: Это наш «код-ревью» для результатов ИИ. Человеческий глаз все еще лучший инструмент для выявления тонких нюансов и ошибок. Используй полученные данные для формирования выводов исследования (Use findings to inform your research conclusions).\nДействие: Интегрируй результаты анализа ИИ в свои общие выводы по исследованию рынка. Используй их для подтверждения гипотез, выявления новых возможностей или уточнения понимания целевой аудитории. Для нас: Это наш «финальный отчет». ИИ — это инструмент, который помогает нам получить данные, но окончательные выводы и рекомендации — это наша ответственность. Важное замечание: ИИ-инструменты развиваются очень быстро. Хотя они предлагают значительную экономию времени для определенных исследовательских задач, они работают лучше всего как дополнение к профессиональной исследовательской экспертизе, а не как ее замена. Это как использовать мощный фреймворк: он ускоряет разработку, но не заменяет квалификацию инженера.\nГлава 8.1: Процесс исследования рынка: пошагово. Наш чек-лист. Мы прошли долгий путь, изучая различные аспекты исследования рынка. Теперь давай сведем все воедино и представим комплексный процесс исследования рынка в виде пошагового алгоритма. Думай об этом как о финальном чек-листе перед запуском проекта: убедись, что все этапы пройдены и ничего не упущено.\nКомплексный процесс исследования рынка включает следующие последовательные шаги: Определи цели и вопросы исследования (Define research objectives and questions).\nСуть: Четко сформулируй, какие решения будут приниматься на основе результатов. Выяви ключевые информационные потребности стейкхолдеров. Сформулируй конкретные, измеримые вопросы, на которые ты хочешь получить ответы. Для нас: Это наш «ТЗ» для всего исследования. Без этого шага все остальное бессмысленно. Проведи вторичное исследование (Conduct secondary research).\nСуть: Проанализируй существующие данные о размере рынка, трендах, конкурентной среде и характеристиках целевой аудитории. Выяви пробелы, которые требуют первичного исследования. Для нас: Это наша «разведка боем» перед началом активных действий. Позволяет быстро получить общую картину и сэкономить ресурсы. Проведи первичное исследование (Perform primary research).\nСуть: Разработай опросы или протоколы интервью. Собери данные от целевой аудитории. Систематизируй и проанализируй полученные данные. Сравни их с результатами вторичного исследования для валидации. Для нас: Это наш «сбор требований» напрямую от пользователей. Позволяет получить уникальные и глубокие инсайты. Проанализируй конкурентов (Analyze competitors).\nСуть: Создай детальные профили конкурентов. Составь карту конкурентной среды. Выяви возможности для позиционирования на рынке и определи свои конкурентные преимущества. Для нас: Это наш «бенчмаркинг» и «анализ угроз». Позволяет понять, где мы находимся относительно других игроков. Рассчитай рыночные метрики (Calculate market metrics).\nСуть: Определи TAM, SAM и SOM. Оцени потенциальную выручку, затраты и ROI. Сформируй прогнозы роста. Для нас: Это наш «финансовый анализ». Позволяет перевести качественные данные в количественные показатели и оценить потенциальную прибыльность. Синтезируй выводы (Synthesize findings).\nСуть: Создай SWOT-анализ. Разработай рыночную карту. Структурируй выводы для принятия решений. Выяви ключевые инсайты и их последствия. Для нас: Это наш «аналитический отчет». Здесь мы превращаем сырые данные в осмысленные выводы и рекомендации. Создай deliverables (Create deliverables).\nСуть: Разработай комплексный бизнес-план. Создай визуально насыщенный питч-дек. Подготовь резюме для руководства. Разработай дорожную карту внедрения. Для нас: Это наш «результат проекта». Мы упаковываем все наши исследования в понятные и убедительные документы для разных аудиторий. Итог: Этот пошаговый процесс — не просто последовательность действий, а системный подход к исследованию рынка. Он позволяет принимать обоснованные решения, минимизировать риски и значительно повысить вероятность успеха продукта или проекта. Это наш «жизненный цикл разработки» для бизнес-идей.\nГлава 8.2: Основные инструменты исследования рынка. Наш инструментарий. На протяжении всего руководства мы упоминали различные инструменты, которые помогают в проведении эффективного исследования рынка. Теперь давай сведем их в единый список, чтобы у тебя был быстрый доступ к нашему «инструментарию». Думай об этом как о списке зависимостей для твоего проекта: каждый инструмент выполняет свою специфическую функцию.\n1. Инструменты анализа (Analysis Tools) Эти инструменты помогают структурировать и интерпретировать собранные данные:\nМодель расчета размера рынка (Market size calculation model): Для определения TAM, SAM, SOM. Фреймворк картирования конкурентов (Competitor mapping framework): Для визуализации позиционирования конкурентов. Шаблон SWOT-анализа (SWOT analysis template): Для оценки сильных и слабых сторон, возможностей и угроз. Шаблон рыночной карты (Market scorecard template): Для оценки рыночного потенциала по заданным критериям. Канва бизнес-модели (Business model canvas): Для комплексного представления бизнес-модели на одной странице. 2. Инструменты исследования (Research Tools) Эти инструменты помогают в сборе первичных и вторичных данных:\nCrunchbase и ZoomInfo: Для информации о компаниях, их финансировании и технологическом стеке. Capterra и G2: Для сравнения продуктов/услуг и анализа отзывов пользователей. Semrush и SimilarWeb: Для анализа веб-трафика и цифрового присутствия конкурентов. Facebook Ad Library и SpyFu: Для исследования рекламных кампаний конкурентов. Платформы для опросов (Survey platforms): Такие как SurveyMonkey, Pollfish — для проведения первичных опросов. 3. Инструменты поиска (Search Tools) Эти инструменты помогают оптимизировать процесс поиска информации:\nПродвинутые методы поиска Google: Использование операторов \u0026quot;\u0026quot;, OR, AND. Расширения Chrome (Multi Highlighter, Simple Scraper): Для выделения ключевых слов и извлечения данных с веб-страниц. Google Alerts: Для мониторинга новых публикаций по интересующим темам. ИИ-инструменты для анализа (AI-assisted analysis tools): Такие как ChatGPT, Agent GPT, Lumina, Julius, Durable, FlowGPT, Plus AI — для автоматизации анализа текста, генерации идей, суммаризации и визуализации. Итог: Этот набор инструментов — твой арсенал для эффективного исследования рынка. Выбирай подходящий инструмент в зависимости от задачи, помня о его сильных сторонах и ограничениях. Комбинируй их, чтобы получить максимально полную и достоверную картину. Это наш «DevOps-тулчейн» для аналитики.\nГлава 8.3: Принципы эффективности. Как работать умно, а не много. Эффективность в исследовании рынка — это не про то, чтобы работать больше, а про то, чтобы работать умнее. Это набор принципов, которые помогут тебе минимизировать затраты времени и ресурсов, максимизируя при этом качество и ценность полученных данных. Думай об этом как о наборе оптимизационных паттернов для твоего рабочего процесса.\nЧтобы проводить исследование рынка эффективно: Начинай со вторичного исследования, прежде чем инвестировать в первичное (Start with secondary research before investing in primary research).\nСуть: Это золотое правило. Всегда сначала изучай, что уже известно. Это экономит время и деньги, так как ты не будешь собирать данные, которые уже существуют. Для нас: Это как проверка наличия готовых библиотек перед написанием своего кода. Зачем изобретать велосипед? Используй подход «облака синонимов» для всестороннего сбора информации (Use the cloud of synonyms approach for comprehensive information gathering).\nСуть: Не ограничивайся одной формулировкой. Разнообразие поисковых запросов значительно увеличивает шансы найти релевантную информацию. Для нас: Это наш «расширенный поиск», который гарантирует, что мы не упустим важные данные из-за неточных формулировок. Стандартизируй фреймворки анализа для конкурентов и сегментов рынка (Standardize analysis frameworks across competitors and market segments).\nСуть: Используй единые шаблоны и подходы для анализа. Это обеспечивает сопоставимость данных и упрощает процесс. Для нас: Это как единый стиль кодирования и архитектурные паттерны для всего проекта. Порядок и консистентность — залог успеха. Используй ИИ-инструменты для соответствующих задач, поддерживая при этом контроль качества (Leverage AI tools for appropriate tasks while maintaining quality control).\nСуть: ИИ отлично справляется с рутинными задачами и обработкой больших объемов данных. Но всегда проверяй его выводы и используй человеческую экспертизу для интерпретации. Для нас: Это как автоматизация тестирования: она ускоряет процесс, но не заменяет ручное тестирование и код-ревью. Фокусируйся на критически важной для принятия решений информации, а не на исчерпывающем сборе данных (Focus on decision-critical information rather than exhaustive data collection).\nСуть: Не пытайся собрать все данные мира. Сосредоточься на тех, которые напрямую влияют на принятие решений. Избыток информации может быть так же вреден, как и ее недостаток. Для нас: Это как принцип KISS (Keep It Simple, Stupid). Собирай только то, что действительно нужно для решения задачи. Поддерживай систематическую документацию источников и методологий (Maintain systematic documentation of sources and methodologies).\nСуть: Веди записи о том, откуда взяты данные и как они были получены. Это обеспечивает прозрачность и позволяет вернуться к источнику при необходимости. Для нас: Это наш «лог» и «система контроля версий» для исследования. Позволяет отслеживать происхождение данных и методологию. Визуализируй ключевые выводы для понимания стейкхолдерами (Visualize key findings for stakeholder comprehension).\nСуть: Превращай сложные данные в понятные графики и диаграммы. Это значительно упрощает восприятие и донесение информации. Для нас: Это наш «UI/UX» для отчетов. Чем нагляднее, тем лучше. Визуализация — ключ к быстрому пониманию. Итог: Эти принципы — твой компас в мире исследования рынка. Применяя их, ты сможешь не только сэкономить время и ресурсы, но и значительно повысить качество своих исследований, делая их по-настоящему ценными для принятия бизнес-решений. Это наш «манифест эффективности».\nГлава 8.4: Показатели качества. Как понять, что исследование годное. Провести исследование — это одно, а провести качественное исследование — совсем другое. Как понять, что твои выводы надежны, а данные, на которых они основаны, заслуживают доверия? Думай об этом как о наборе критериев приемки для твоего аналитического продукта. Вот ключевые показатели, по которым можно оценить качество исследования рынка:\nВысококачественное исследование рынка характеризуется: Валидация из нескольких источников (Multi-source validation).\nСуть: Выводы подтверждены несколькими независимыми источниками. Если разные источники говорят одно и то же, это значительно повышает доверие к информации. Для нас: Это как кросс-платформенное тестирование. Если твой код работает одинаково хорошо на разных ОС и браузерах, значит, он надежен. То же самое с данными: чем больше независимых подтверждений, тем лучше. Согласованность первичного и вторичного исследования (Primary/secondary alignment).\nСуть: Последовательные паттерны в результатах, полученных как из первичных (опросы, интервью), так и из вторичных (отчеты, статистика) источников. Если данные из разных типов исследований противоречат друг другу, это повод для дальнейшего изучения. Для нас: Это наш «интеграционный тест». Если то, что мы узнали от клиентов напрямую, совпадает с тем, что пишут аналитики, значит, мы на верном пути. Действенные инсайты (Actionable insights).\nСуть: Четкие выводы, которые имеют практические последствия для бизнес-решений. Исследование должно давать ответы на вопросы «Что нам делать дальше?» и «Как это повлияет на наш продукт/стратегию?». Для нас: Это не просто данные, а конкретные рекомендации. Если исследование не дает четких указаний к действию, его ценность сомнительна. Сбалансированная перспектива (Balanced perspective).\nСуть: Честная оценка как возможностей, так и проблем/вызовов. Исследование не должно быть однобоким или предвзятым, фокусируясь только на позитивных аспектах. Для нас: Это как объективный код-ревью, который выявляет не только достоинства, но и недостатки. Важно видеть полную картину, а не только то, что хочется видеть. Методологическая прозрачность (Methodological transparency).\nСуть: Четкое объяснение подхода к исследованию. Должно быть понятно, как собирались данные, какие методы использовались, какие были ограничения. Для нас: Это как хорошо документированный API. Если непонятно, как он работает, им сложно пользоваться и доверять. Актуальные данные (Current data).\nСуть: Использование свежей информации, полученной в течение последних 1-2 лет. В быстро меняющихся отраслях это критически важно. Для нас: Это как использовать актуальные версии библиотек. Устаревшие данные могут привести к неверным выводам. Визуальная ясность (Visual clarity).\nСуть: Эффективная визуализация сложной информации. Графики и диаграммы должны быть понятными и легко читаемыми. Для нас: Это наш «UI/UX» для отчетов. Чем нагляднее представлены данные, тем быстрее они будут усвоены и тем выше их ценность. Стратегическая релевантность (Strategic relevance).\nСуть: Прямая связь с целями и задачами бизнеса. Исследование должно отвечать на вопросы, которые важны для стратегического развития компании. Для нас: Это как соответствие кода бизнес-требованиям. Если исследование не помогает достичь стратегических целей, оно бесполезно. Итог: Эти показатели качества — твой ориентир. Придерживаясь их, ты сможешь создавать исследования рынка, которые не просто собирают данные, а предоставляют ценные, надежные и действенные инсайты, способствующие успеху твоего продукта и бизнеса в целом. Это наш «стандарт качества».\nГлава 8.5: Следующие шаги. Что делать после исследования. Исследование рынка — это не конечная точка, а важный этап в непрерывном цикле развития продукта и бизнеса. После того как ты собрал, проанализировал и синтезировал данные, самое главное — правильно использовать эти результаты. Думай об этом как о завершении разработки модуля: он готов, но теперь его нужно интегрировать, поддерживать и развивать. Вот что нужно делать после завершения исследования рынка:\nПосле завершения исследования рынка: Создай план внедрения на основе выводов (Create implementation plan based on findings).\nСуть: Преврати полученные инсайты в конкретные действия. Что нужно изменить в продукте? Какие новые функции разработать? Как скорректировать маркетинговую стратегию? Кто за что отвечает и в какие сроки? Для нас: Это наш «роадмап» или «бэклог» на основе данных. Исследование показало, что нужно делать, теперь нужно это спланировать и реализовать. Установи метрики для измерения успеха выхода на рынок (Establish metrics to measure market entry success).\nСуть: Определи ключевые показатели (KPI), по которым ты будешь отслеживать эффективность своих действий. Это могут быть доля рынка, количество новых клиентов, уровень удовлетворенности, выручка и т.д. Для нас: Это наши «метрики производительности». Если мы что-то меняем, мы должны измерять, как это влияет на результат. Запланируй регулярные обновления исследования по мере развития рынка (Schedule regular updates to research as the market evolves).\nСуть: Рынок не стоит на месте. Конкуренты меняются, появляются новые технологии, потребности клиентов эволюционируют. Исследование рынка — это не разовая акция, а непрерывный процесс. Для нас: Это как регулярные релизы и обновления ПО. Мы постоянно мониторим среду и адаптируемся к изменениям. Создай петли обратной связи для постоянной валидации предположений (Build feedback loops to continuously validate assumptions).\nСуть: Включи механизмы сбора обратной связи от клиентов, партнеров, отдела продаж. Это поможет постоянно проверять свои гипотезы и корректировать стратегию. Для нас: Это наш «CI/CD» для бизнес-стратегии. Постоянный сбор данных и быстрая адаптация. Разработай планы на случай непредвиденных обстоятельств для различных рыночных сценариев (Develop contingency plans for different market scenarios).\nСуть: Что если рынок пойдет не так, как мы ожидаем? Что если появится новый сильный конкурент? Заранее продумай альтернативные сценарии и планы действий. Для нас: Это наше «отказоустойчивое проектирование». Мы готовимся к разным исходам, чтобы быть готовыми к любым вызовам. Делись инсайтами со всеми заинтересованными сторонами (Share insights with all relevant stakeholders).\nСуть: Результаты исследования должны быть доступны и понятны всем, кто принимает решения. Регулярно проводи презентации, рассылай отчеты, обсуждай выводы. Для нас: Это наша «коммуникационная стратегия». Убедись, что все в команде и руководстве говорят на одном языке и понимают, куда мы движемся. Используй исследование как живой документ для руководства текущей стратегией (Use research as a living document to guide ongoing strategy).\nСуть: Исследование рынка — это не пыльный отчет, который лежит на полке. Это динамичный документ, который постоянно обновляется и используется для принятия стратегических решений. Для нас: Это наша «база знаний», которая постоянно актуализируется и служит основой для всех наших действий. Итог: Исследование рынка — это не одноразовая активность, а непрерывный процесс понимания, адаптации и предвидения динамики рынка. Методологии, изложенные в этом руководстве, обеспечивают основу для принятия бизнес-решений, основанных на данных, что может значительно увеличить вероятность успеха на рынке. Это наш «постоянный процесс улучшения».\n","permalink":"https://meshrefine.com/ru/conversations/market_research/","summary":"\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-11-%d1%86%d0%b5%d0%bb%d0%b8-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-%d0%b7%d0%b0%d1%87%d0%b5%d0%bc-%d0%bd%d0%b0%d0%bc-%d1%8d%d1%82%d0%be\"\u003eГлава 1.1: Цели исследования рынка. Зачем нам это?\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-12-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%be%d0%bf%d1%80%d0%b5%d0%b4%d0%b5%d0%bb%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b3%d0%be%d0%b2%d0%be%d1%80%d0%b8%d0%bc-%d0%bd%d0%b0-%d0%be%d0%b4%d0%bd%d0%be%d0%bc-%d1%8f%d0%b7%d1%8b%d0%ba%d0%b5\"\u003eГлава 1.2: Ключевые определения. Говорим на одном языке.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%b1%d0%b8%d0%b7%d0%bd%d0%b5%d1%81-%d0%bf%d0%bb%d0%b0%d0%bd-business-plan\"\u003e1. Бизнес-план (Business Plan)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%bf%d0%b8%d1%82%d1%87-%d0%b4%d0%b5%d0%ba-pitch-deck\"\u003e2. Питч-дек (Pitch Deck)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d0%b2%d0%b0%d0%bb%d0%b8%d0%b4%d0%b0%d1%86%d0%b8%d1%8f-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-market-validation\"\u003e3. Валидация рынка (Market Validation)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d0%bf%d0%b5%d1%80%d0%b2%d0%b8%d1%87%d0%bd%d0%be%d0%b5-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-primary-research\"\u003e4. Первичное исследование (Primary Research)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#5-%d0%b2%d1%82%d0%be%d1%80%d0%b8%d1%87%d0%bd%d0%be%d0%b5-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-secondary-research\"\u003e5. Вторичное исследование (Secondary Research)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-13-%d1%82%d0%b8%d0%bf%d1%8b-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-%d0%b2%d1%8b%d0%b1%d0%b8%d1%80%d0%b0%d0%b5%d0%bc-%d0%bf%d1%80%d0%b0%d0%b2%d0%b8%d0%bb%d1%8c%d0%bd%d1%8b%d0%b9-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82\"\u003eГлава 1.3: Типы исследования рынка. Выбираем правильный инструмент.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%bf%d0%b5%d1%80%d0%b2%d0%b8%d1%87%d0%bd%d0%be%d0%b5-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-primary-research\"\u003e1. Первичное исследование (Primary Research)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%b2%d1%82%d0%be%d1%80%d0%b8%d1%87%d0%bd%d0%be%d0%b5-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-secondary-research\"\u003e2. Вторичное исследование (Secondary Research)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-21-%d0%be%d0%bf%d1%80%d0%b5%d0%b4%d0%b5%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%bd%d0%b0%d0%bf%d1%80%d0%b0%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%ba%d1%83%d0%b4%d0%b0-%d0%bc%d1%8b-%d0%b8%d0%b4%d0%b5%d0%bc\"\u003eГлава 2.1: Определение направления исследования. Куда мы идем?\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%bf%d0%be%d1%87%d0%b5%d0%bc%d1%83-%d1%8d%d1%82%d0%be-%d0%b2%d0%b0%d0%b6%d0%bd%d0%be\"\u003eПочему это важно?\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d1%88%d0%b0%d0%b3%d0%b8-%d0%bf%d0%b5%d1%80%d0%b5%d0%b4-%d0%bd%d0%b0%d1%87%d0%b0%d0%bb%d0%be%d0%bc-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f\"\u003eКлючевые шаги перед началом исследования:\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-22-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d0%b0%d1%8f-%d1%80%d1%8b%d0%bd%d0%be%d1%87%d0%bd%d0%b0%d1%8f-%d0%b8%d0%bd%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d1%8f-%d1%87%d1%82%d0%be-%d0%bd%d0%b0%d0%bc-%d0%bd%d1%83%d0%b6%d0%bd%d0%be-%d0%b7%d0%bd%d0%b0%d1%82%d1%8c\"\u003eГлава 2.2: Ключевая рыночная информация. Что нам нужно знать?\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-market-analysis\"\u003e1. Анализ рынка (Market Analysis)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%be%d1%86%d0%b5%d0%bd%d0%ba%d0%b8-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-market-assessment-tools\"\u003e2. Инструменты оценки рынка (Market Assessment Tools)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-23-%d1%80%d0%b0%d1%81%d1%87%d0%b5%d1%82-%d1%80%d0%b0%d0%b7%d0%bc%d0%b5%d1%80%d0%b0-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-%d1%81%d0%ba%d0%be%d0%bb%d1%8c%d0%ba%d0%be-%d0%b4%d0%b5%d0%bd%d0%b5%d0%b3-%d0%bd%d0%b0-%d0%ba%d0%be%d0%bd%d1%83\"\u003eГлава 2.3: Расчет размера рынка. Сколько денег на кону?\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%bf%d0%be%d0%b4%d1%85%d0%be%d0%b4-%d1%81%d0%b2%d0%b5%d1%80%d1%85%d1%83-%d0%b2%d0%bd%d0%b8%d0%b7-top-down-approach\"\u003e1. Подход «сверху вниз» (Top-Down Approach)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%bf%d0%be%d0%b4%d1%85%d0%be%d0%b4-%d1%81%d0%bd%d0%b8%d0%b7%d1%83-%d0%b2%d0%b2%d0%b5%d1%80%d1%85-bottom-up-approach\"\u003e2. Подход «снизу вверх» (Bottom-Up Approach)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%ba%d0%be%d0%bc%d0%bf%d0%be%d0%bd%d0%b5%d0%bd%d1%82%d1%8b-%d1%80%d0%b0%d0%b7%d0%bc%d0%b5%d1%80%d0%b0-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-tam-sam-som\"\u003eКомпоненты размера рынка: TAM, SAM, SOM\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%bc%d0%b5%d1%82%d0%be%d0%b4%d1%8b-%d1%80%d0%b0%d1%81%d1%87%d0%b5%d1%82%d0%b0-%d1%80%d0%b0%d0%b7%d0%bc%d0%b5%d1%80%d0%b0-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0\"\u003eМетоды расчета размера рынка\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-24-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-%d0%bd%d0%b0%d1%88-%d0%b0%d0%bb%d0%b3%d0%be%d1%80%d0%b8%d1%82%d0%bc-%d0%b4%d0%b5%d0%b9%d1%81%d1%82%d0%b2%d0%b8%d0%b9\"\u003eГлава 2.4: Процесс исследования рынка. Наш алгоритм действий.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%be%d0%bf%d1%80%d0%b5%d0%b4%d0%b5%d0%bb%d0%b8-%d1%86%d0%b5%d0%bb%d0%b8-%d0%b8-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d1%8b-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-establish-research-goals-and-questions\"\u003e1. Определи цели и вопросы исследования (Establish research goals and questions)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d1%80%d0%b0%d1%81%d1%81%d1%87%d0%b8%d1%82%d0%b0%d0%b9-%d1%80%d0%b0%d0%b7%d0%bc%d0%b5%d1%80-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-calculate-market-size-using-the-provided-model\"\u003e2. Рассчитай размер рынка (Calculate market size using the provided model)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d1%83%d0%b9-%d1%80%d1%8b%d0%bd%d0%be%d1%87%d0%bd%d1%8b%d0%b5-%d1%82%d1%80%d0%b5%d0%bd%d0%b4%d1%8b-%d0%b4%d1%80%d0%b0%d0%b9%d0%b2%d0%b5%d1%80%d1%8b-%d0%b8-%d0%b1%d0%b0%d1%80%d1%8c%d0%b5%d1%80%d1%8b-%d0%b0-%d1%82%d0%b0%d0%ba%d0%b6%d0%b5-%d0%ba%d0%be%d0%bd%d1%86%d0%b5%d0%bd%d1%82%d1%80%d0%b0%d1%86%d0%b8%d1%8e-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-research-market-trends-drivers-barriers-and-concentration\"\u003e3. Исследуй рыночные тренды, драйверы и барьеры, а также концентрацию рынка (Research market trends, drivers, barriers, and concentration)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d1%81%d0%be%d0%b7%d0%b4%d0%b0%d0%b9-swot-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7-%d0%b8-%d1%80%d1%8b%d0%bd%d0%be%d1%87%d0%bd%d1%83%d1%8e-%d0%ba%d0%b0%d1%80%d1%82%d1%83-create-a-swot-analysis-and-market-scorecard\"\u003e4. Создай SWOT-анализ и рыночную карту (Create a SWOT analysis and market scorecard)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#5-%d0%be%d1%86%d0%b5%d0%bd%d0%b8-%d0%bf%d0%be%d1%82%d0%b5%d0%bd%d1%86%d0%b8%d0%b0%d0%bb%d1%8c%d0%bd%d1%83%d1%8e-%d0%b2%d1%8b%d1%80%d1%83%d1%87%d0%ba%d1%83-%d0%b7%d0%b0%d1%82%d1%80%d0%b0%d1%82%d1%8b-%d0%b8-roi-estimate-potential-revenue-costs-and-roi\"\u003e5. Оцени потенциальную выручку, затраты и ROI (Estimate potential revenue, costs, and ROI)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-31-%d1%87%d1%82%d0%be-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d1%82%d1%8c-%d1%83-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%82%d0%be%d0%b2-%d0%b7%d0%bd%d0%b0%d0%b9-%d0%b2%d1%80%d0%b0%d0%b3%d0%b0-%d0%b2-%d0%bb%d0%b8%d1%86%d0%be\"\u003eГлава 3.1: Что анализировать у конкурентов. Знай врага в лицо.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%be%d0%b1%d1%89%d0%b0%d1%8f-%d0%b8%d0%bd%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d1%8f-general-information\"\u003e1. Общая информация (General Information)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82-%d0%b8-%d1%86%d0%b5%d0%bd%d0%be%d0%be%d0%b1%d1%80%d0%b0%d0%b7%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-product-and-pricing\"\u003e2. Продукт и ценообразование (Product and Pricing)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d0%bc%d0%b5%d1%82%d1%80%d0%b8%d0%ba%d0%b8-%d0%bf%d1%80%d0%be%d0%b8%d0%b7%d0%b2%d0%be%d0%b4%d0%b8%d1%82%d0%b5%d0%bb%d1%8c%d0%bd%d0%be%d1%81%d1%82%d0%b8-performance-metrics\"\u003e3. Метрики производительности (Performance Metrics)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d0%bc%d0%b0%d1%80%d0%ba%d0%b5%d1%82%d0%b8%d0%bd%d0%b3-%d0%b8-%d1%86%d0%b8%d1%84%d1%80%d0%be%d0%b2%d0%be%d0%b5-%d0%bf%d1%80%d0%b8%d1%81%d1%83%d1%82%d1%81%d1%82%d0%b2%d0%b8%d0%b5-marketing-and-digital-presence\"\u003e4. Маркетинг и цифровое присутствие (Marketing and Digital Presence)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-32-%d0%b3%d0%b4%d0%b5-%d0%bd%d0%b0%d0%b9%d1%82%d0%b8-%d0%b8%d0%bd%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d1%8e-%d0%be-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%82%d0%b0%d1%85-%d0%bd%d0%b0%d1%88-%d0%b0%d1%80%d1%81%d0%b5%d0%bd%d0%b0%d0%bb-%d1%80%d0%b0%d0%b7%d0%b2%d0%b5%d0%b4%d1%87%d0%b8%d0%ba%d0%b0\"\u003eГлава 3.2: Где найти информацию о конкурентах. Наш арсенал разведчика.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%be%d1%81%d0%bd%d0%be%d0%b2%d0%bd%d1%8b%d0%b5-%d0%bc%d0%b5%d1%82%d0%be%d0%b4%d1%8b-%d0%bf%d0%be%d0%b8%d1%81%d0%ba%d0%b0-primary-search-methods\"\u003e1. Основные методы поиска (Primary Search Methods)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7%d0%b0-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%82%d0%be%d0%b2-competitor-analysis-tools\"\u003e2. Инструменты анализа конкурентов (Competitor Analysis Tools)\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#21-%d0%b1%d0%b0%d0%b7%d1%8b-%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d1%85-%d0%ba%d0%be%d0%bc%d0%bf%d0%b0%d0%bd%d0%b8%d0%b9-company-database-tools\"\u003e2.1. Базы данных компаний (Company Database Tools)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#22-%d0%bf%d0%bb%d0%b0%d1%82%d1%84%d0%be%d1%80%d0%bc%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%be%d0%b1%d0%b7%d0%be%d1%80%d0%b0-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%be%d0%b2-product-review-platforms\"\u003e2.2. Платформы для обзора продуктов (Product Review Platforms)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#23-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b2%d0%b5%d0%b1-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d1%82%d0%b8%d0%ba%d0%b8-website-analytics-tools\"\u003e2.3. Инструменты веб-аналитики (Website Analytics Tools)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#24-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d1%80%d0%b5%d0%ba%d0%bb%d0%b0%d0%bc%d1%8b-advertising-research-tools\"\u003e2.4. Инструменты для исследования рекламы (Advertising Research Tools)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-34-%d0%be%d1%80%d0%b3%d0%b0%d0%bd%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d1%8f-%d0%b8%d0%bd%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d0%b8-%d0%be-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%82%d0%b0%d1%85-%d0%ba%d0%b0%d0%ba-%d0%bd%d0%b5-%d1%83%d1%82%d0%be%d0%bd%d1%83%d1%82%d1%8c-%d0%b2-%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d1%85\"\u003eГлава 3.4: Организация информации о конкурентах. Как не утонуть в данных.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%bf%d1%80%d0%be%d1%84%d0%b8%d0%bb%d0%b8-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%82%d0%be%d0%b2-competitor-profiles\"\u003e1. Профили конкурентов (Competitor Profiles)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%bc%d0%b0%d1%82%d1%80%d0%b8%d1%86%d0%b0-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%82%d0%bd%d1%8b%d1%85-%d0%bf%d1%80%d0%b5%d0%b8%d0%bc%d1%83%d1%89%d0%b5%d1%81%d1%82%d0%b2-competitive-advantage-matrix\"\u003e2. Матрица конкурентных преимуществ (Competitive Advantage Matrix)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d0%ba%d0%b0%d1%80%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%82%d0%be%d0%b2-competitor-mapping\"\u003e3. Картирование конкурентов (Competitor Mapping)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-35-%d0%bb%d1%83%d1%87%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%b8-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7%d0%b0-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%82%d0%be%d0%b2-%d0%ba%d0%b0%d0%ba-%d0%b4%d0%b5%d0%bb%d0%b0%d1%82%d1%8c-%d1%8d%d1%82%d0%be-%d0%bf%d1%80%d0%b0%d0%b2%d0%b8%d0%bb%d1%8c%d0%bd%d0%be\"\u003eГлава 3.5: Лучшие практики анализа конкурентов. Как делать это правильно.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7%d0%b8%d1%80%d1%83%d0%b9-%d0%be%d0%bf%d1%82%d0%b8%d0%bc%d0%b0%d0%bb%d1%8c%d0%bd%d0%be%d0%b5-%d0%ba%d0%be%d0%bb%d0%b8%d1%87%d0%b5%d1%81%d1%82%d0%b2%d0%be-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%82%d0%be%d0%b2-analyze-5-15-competitors\"\u003e1. Анализируй оптимальное количество конкурентов (Analyze 5-15 competitors)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%b4%d0%b5%d0%bb%d0%b0%d0%b9-%d0%ba%d0%be%d0%bd%d0%ba%d1%80%d0%b5%d1%82%d0%bd%d1%8b%d0%b5-%d0%b2%d1%8b%d0%b2%d0%be%d0%b4%d1%8b-draw-concrete-conclusions\"\u003e2. Делай конкретные выводы (Draw concrete conclusions)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d1%84%d0%be%d0%ba%d1%83%d1%81%d0%b8%d1%80%d1%83%d0%b9%d1%81%d1%8f-%d0%bd%d0%b0-%d0%b1%d0%be%d0%bb%d0%b5%d0%b2%d1%8b%d1%85-%d1%82%d0%be%d1%87%d0%ba%d0%b0%d1%85-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%be%d0%b2-focus-on-customer-pain-points\"\u003e3. Фокусируйся на болевых точках клиентов (Focus on customer pain points)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d1%81%d1%82%d0%b0%d0%bd%d0%b4%d0%b0%d1%80%d1%82%d0%b8%d0%b7%d0%b8%d1%80%d1%83%d0%b9-%d0%bf%d0%be%d0%b4%d1%85%d0%be%d0%b4-%d0%ba-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7%d1%83-standardize-your-analysis-approach\"\u003e4. Стандартизируй подход к анализу (Standardize your analysis approach)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-41-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7%d0%b0-%d1%86%d0%b5%d0%bb%d0%b5%d0%b2%d0%be%d0%b9-%d0%b0%d1%83%d0%b4%d0%b8%d1%82%d0%be%d1%80%d0%b8%d0%b8-%d0%b4%d0%bb%d1%8f-%d0%ba%d0%be%d0%b3%d0%be-%d0%bc%d1%8b-%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%b0%d0%b5%d0%bc\"\u003eГлава 4.1: Ключевые вопросы для анализа целевой аудитории. Для кого мы работаем?\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%b1%d0%be%d0%bb%d0%b5%d0%b2%d1%8b%d0%b5-%d1%82%d0%be%d1%87%d0%ba%d0%b8-pain-points\"\u003e1. Болевые точки (Pain Points)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d1%81%d1%83%d1%89%d0%b5%d1%81%d1%82%d0%b2%d1%83%d1%8e%d1%89%d0%b8%d0%b5-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d1%8f-current-solutions\"\u003e2. Существующие решения (Current Solutions)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d1%83%d0%b4%d0%be%d0%b2%d0%bb%d0%b5%d1%82%d0%b2%d0%be%d1%80%d0%b5%d0%bd%d0%bd%d0%be%d1%81%d1%82%d1%8c-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d1%8f%d0%bc%d0%b8-solution-satisfaction\"\u003e3. Удовлетворенность решениями (Solution Satisfaction)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d0%b4%d0%b5%d0%bc%d0%be%d0%b3%d1%80%d0%b0%d1%84%d0%b8%d1%8f-%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d0%be%d0%b2%d0%b0%d1%82%d0%b5%d0%bb%d0%b5%d0%b9-user-demographics\"\u003e4. Демография пользователей (User Demographics)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#5-%d0%bf%d1%80%d0%b8%d0%bd%d1%8f%d1%82%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0-product-adoption\"\u003e5. Принятие продукта (Product Adoption)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#6-%d1%81%d0%be%d0%be%d1%82%d0%b2%d0%b5%d1%82%d1%81%d1%82%d0%b2%d0%b8%d0%b5-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d1%8f-solution-fit\"\u003e6. Соответствие решения (Solution Fit)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#7-%d0%b3%d0%be%d1%82%d0%be%d0%b2%d0%bd%d0%be%d1%81%d1%82%d1%8c-%d0%bf%d0%bb%d0%b0%d1%82%d0%b8%d1%82%d1%8c-willingness-to-pay\"\u003e7. Готовность платить (Willingness to Pay)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-42-%d0%b2%d1%82%d0%be%d1%80%d0%b8%d1%87%d0%bd%d1%8b%d0%b9-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7-%d1%86%d0%b5%d0%bb%d0%b5%d0%b2%d0%be%d0%b9-%d0%b0%d1%83%d0%b4%d0%b8%d1%82%d0%be%d1%80%d0%b8%d0%b8-%d0%b8%d0%b7%d1%83%d1%87%d0%b0%d0%b5%d0%bc-%d1%87%d1%82%d0%be-%d1%83%d0%b6%d0%b5-%d0%b8%d0%b7%d0%b2%d0%b5%d1%81%d1%82%d0%bd%d0%be\"\u003eГлава 4.2: Вторичный анализ целевой аудитории. Изучаем, что уже известно.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%ba%d0%b0%d0%ba-%d0%bd%d0%b0%d0%b9%d1%82%d0%b8-%d0%ba%d0%b0%d1%87%d0%b5%d1%81%d1%82%d0%b2%d0%b5%d0%bd%d0%bd%d1%8b%d0%b5-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f\"\u003e1. Как найти качественные исследования?\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d1%84%d0%be%d1%80%d0%bc%d1%83%d0%bb%d0%b0-%d0%bf%d0%be%d0%b8%d1%81%d0%ba%d0%b0-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b9\"\u003e2. Формула поиска исследований\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7%d0%b0-%d1%86%d0%b5%d0%bb%d0%b5%d0%b2%d0%be%d0%b9-%d0%b0%d1%83%d0%b4%d0%b8%d1%82%d0%be%d1%80%d0%b8%d0%b8\"\u003e3. Инструменты для анализа целевой аудитории\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-43-%d0%bf%d0%b5%d1%80%d0%b2%d0%b8%d1%87%d0%bd%d1%8b%d0%b9-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7-%d1%86%d0%b5%d0%bb%d0%b5%d0%b2%d0%be%d0%b9-%d0%b0%d1%83%d0%b4%d0%b8%d1%82%d0%be%d1%80%d0%b8%d0%b8-%d0%be%d0%bf%d1%80%d0%be%d1%81%d1%8b-%d1%81%d0%bf%d1%80%d0%b0%d1%88%d0%b8%d0%b2%d0%b0%d0%b5%d0%bc-%d0%bd%d0%b0%d0%bf%d1%80%d1%8f%d0%bc%d1%83%d1%8e\"\u003eГлава 4.3: Первичный анализ целевой аудитории: Опросы. Спрашиваем напрямую.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%be%d0%bf%d1%80%d0%be%d1%81%d0%b0-survey-design-process\"\u003e1. Процесс проектирования опроса (Survey Design Process)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%bb%d1%83%d1%87%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%b8-%d1%81%d1%82%d1%80%d1%83%d0%ba%d1%82%d1%83%d1%80%d1%8b-%d0%be%d0%bf%d1%80%d0%be%d1%81%d0%b0-survey-structure-best-practices\"\u003e2. Лучшие практики структуры опроса (Survey Structure Best Practices)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d1%81%d0%be%d0%b2%d0%b5%d1%82%d1%8b-%d0%bf%d0%be-%d0%b4%d0%b8%d0%b7%d0%b0%d0%b9%d0%bd%d1%83-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d0%be%d0%b2-question-design-tips\"\u003e3. Советы по дизайну вопросов (Question Design Tips)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d1%80%d0%b0%d1%81%d1%87%d0%b5%d1%82-%d1%80%d0%b0%d0%b7%d0%bc%d0%b5%d1%80%d0%b0-%d0%b2%d1%8b%d0%b1%d0%be%d1%80%d0%ba%d0%b8-sample-size-calculation\"\u003e4. Расчет размера выборки (Sample Size Calculation)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#5-%d0%bc%d0%b5%d1%82%d0%be%d0%b4%d1%8b-%d1%81%d0%b1%d0%be%d1%80%d0%b0-%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d1%85-data-collection-methods\"\u003e5. Методы сбора данных (Data Collection Methods)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-44-%d1%81%d0%be%d1%87%d0%b5%d1%82%d0%b0%d0%bd%d0%b8%d0%b5-%d0%bf%d0%b5%d1%80%d0%b2%d0%b8%d1%87%d0%bd%d0%be%d0%b3%d0%be-%d0%b8-%d0%b2%d1%82%d0%be%d1%80%d0%b8%d1%87%d0%bd%d0%be%d0%b3%d0%be-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d1%81%d0%b8%d0%bd%d1%82%d0%b5%d0%b7-%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d1%85\"\u003eГлава 4.4: Сочетание первичного и вторичного исследования. Синтез данных.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%bb%d1%83%d1%87%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%b8-%d1%81%d0%be%d1%87%d0%b5%d1%82%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b9\"\u003eЛучшие практики сочетания исследований:\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-51-%d0%b1%d0%b8%d0%b7%d0%bd%d0%b5%d1%81-%d0%bf%d0%bb%d0%b0%d0%bd-%d0%bf%d1%80%d0%be%d1%82%d0%b8%d0%b2-%d0%bf%d0%b8%d1%82%d1%87-%d0%b4%d0%b5%d0%ba%d0%b0-%d1%83%d0%bf%d0%b0%d0%ba%d0%be%d0%b2%d1%8b%d0%b2%d0%b0%d0%b5%d0%bc-%d1%80%d0%b5%d0%b7%d1%83%d0%bb%d1%8c%d1%82%d0%b0%d1%82%d1%8b-%d0%bf%d0%be-%d1%80%d0%b0%d0%b7%d0%bd%d0%be%d0%bc%d1%83\"\u003eГлава 5.1: Бизнес-план против питч-дека. Упаковываем результаты по-разному.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b1%d0%b8%d0%b7%d0%bd%d0%b5%d1%81-%d0%bf%d0%bb%d0%b0%d0%bd-business-plan\"\u003eБизнес-план (Business Plan)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%bf%d0%b8%d1%82%d1%87-%d0%b4%d0%b5%d0%ba-pitch-deck\"\u003eПитч-дек (Pitch Deck)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-52-%d1%81%d1%82%d1%80%d1%83%d0%ba%d1%82%d1%83%d1%80%d0%b0-%d0%b1%d0%b8%d0%b7%d0%bd%d0%b5%d1%81-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b0-%d0%ba%d1%83%d0%b4%d0%b0-%d0%b2%d1%81%d1%82%d0%b0%d0%b2%d0%bb%d1%8f%d1%82%d1%8c-%d0%bd%d0%b0%d1%88%d0%b8-%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d0%b5\"\u003eГлава 5.2: Структура бизнес-плана. Куда вставлять наши данные.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d1%80%d0%b5%d0%b7%d1%8e%d0%bc%d0%b5-executive-summary\"\u003e1. Резюме (Executive Summary)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%be%d0%b1%d1%89%d0%b8%d0%b5-%d1%81%d0%b2%d0%b5%d0%b4%d0%b5%d0%bd%d0%b8%d1%8f-%d0%be-%d0%ba%d0%be%d0%bc%d0%bf%d0%b0%d0%bd%d0%b8%d0%b8-company-background\"\u003e2. Общие сведения о компании (Company Background)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-market-analysis\"\u003e3. Анализ рынка (Market Analysis)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7-%d1%86%d0%b5%d0%bb%d0%b5%d0%b2%d0%be%d0%b9-%d0%b0%d1%83%d0%b4%d0%b8%d1%82%d0%be%d1%80%d0%b8%d0%b8-target-audience-analysis\"\u003e4. Анализ целевой аудитории (Target Audience Analysis)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#5-%d0%bf%d1%80%d0%be%d0%b1%d0%bb%d0%b5%d0%bc%d0%b0-%d0%b8-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d0%b5-problem-and-solution\"\u003e5. Проблема и решение (Problem and Solution)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#6-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%82%d0%be%d0%b2-competitor-analysis\"\u003e6. Анализ конкурентов (Competitor Analysis)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#7-swot-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7-swot-analysis\"\u003e7. SWOT-анализ (SWOT Analysis)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#8-%d0%bc%d0%b0%d1%80%d0%ba%d0%b5%d1%82%d0%b8%d0%bd%d0%b3%d0%be%d0%b2%d1%8b%d0%b9-%d0%bf%d0%bb%d0%b0%d0%bd-marketing-plan\"\u003e8. Маркетинговый план (Marketing Plan)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#9-%d0%be%d0%bf%d0%b5%d1%80%d0%b0%d1%86%d0%b8%d0%be%d0%bd%d0%bd%d1%8b%d0%b9-%d0%bf%d0%bb%d0%b0%d0%bd-operational-plan\"\u003e9. Операционный план (Operational Plan)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#10-%d1%84%d0%b8%d0%bd%d0%b0%d0%bd%d1%81%d0%be%d0%b2%d1%8b%d0%b9-%d0%bf%d0%bb%d0%b0%d0%bd-financial-plan\"\u003e10. Финансовый план (Financial Plan)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#11-%d1%82%d0%b0%d0%b9%d0%bc%d0%bb%d0%b0%d0%b9%d0%bd%d0%b4%d0%be%d1%80%d0%be%d0%b6%d0%bd%d0%b0%d1%8f-%d0%ba%d0%b0%d1%80%d1%82%d0%b0-timelineroadmap\"\u003e11. Таймлайн/Дорожная карта (Timeline/Roadmap)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-53-%d1%81%d1%82%d1%80%d1%83%d0%ba%d1%82%d1%83%d1%80%d0%b0-%d0%bf%d0%b8%d1%82%d1%87-%d0%b4%d0%b5%d0%ba%d0%b0-%d0%ba%d0%b0%d0%ba-%d0%bf%d1%80%d0%be%d0%b4%d0%b0%d1%82%d1%8c-%d0%b8%d0%b4%d0%b5%d1%8e-%d0%b7%d0%b0-7-%d0%bc%d0%b8%d0%bd%d1%83%d1%82\"\u003eГлава 5.3: Структура питч-дека. Как продать идею за 7 минут.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%bf%d1%80%d0%be%d0%b1%d0%bb%d0%b5%d0%bc%d0%b0-%d0%b8-%d0%b2%d0%be%d0%b7%d0%bc%d0%be%d0%b6%d0%bd%d0%be%d1%81%d1%82%d1%8c-problem-and-opportunity\"\u003e1. Проблема и Возможность (Problem and Opportunity)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d0%b5-solution\"\u003e2. Решение (Solution)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d1%82%d0%b5%d1%85%d0%bd%d0%be%d0%bb%d0%be%d0%b3%d0%b8%d1%8f%d0%b8%d0%bd%d0%bd%d0%be%d0%b2%d0%b0%d1%86%d0%b8%d1%8f-technologyinnovation\"\u003e3. Технология/Инновация (Technology/Innovation)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d1%80%d0%b0%d0%b7%d0%bc%d0%b5%d1%80-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-market-size\"\u003e4. Размер рынка (Market Size)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#5-%d0%b1%d0%b8%d0%b7%d0%bd%d0%b5%d1%81-%d0%bc%d0%be%d0%b4%d0%b5%d0%bb%d1%8c-business-model\"\u003e5. Бизнес-модель (Business Model)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#6-%d0%bf%d0%bb%d0%b0%d0%bd-%d0%b2%d1%8b%d1%85%d0%be%d0%b4%d0%b0-%d0%bd%d0%b0-%d1%80%d1%8b%d0%bd%d0%be%d0%ba-go-to-market-plan\"\u003e6. План выхода на рынок (Go-To-Market Plan)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#7-%d0%ba%d0%be%d0%bd%d0%ba%d1%83%d1%80%d0%b5%d0%bd%d1%86%d0%b8%d1%8f-competition\"\u003e7. Конкуренция (Competition)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#8-%d0%ba%d0%be%d0%bc%d0%b0%d0%bd%d0%b4%d0%b0-team\"\u003e8. Команда (Team)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#9-%d1%84%d0%b8%d0%bd%d0%b0%d0%bd%d1%81%d0%be%d0%b2%d1%8b%d0%b5-%d0%bf%d1%80%d0%be%d0%b3%d0%bd%d0%be%d0%b7%d1%8b-financial-projections\"\u003e9. Финансовые прогнозы (Financial Projections)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#10-%d1%84%d0%b8%d0%bd%d0%b0%d0%bd%d1%81%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-funding\"\u003e10. Финансирование (Funding)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#11-%d1%82%d0%b0%d0%b9%d0%bc%d0%bb%d0%b0%d0%b9%d0%bd-timeline\"\u003e11. Таймлайн (Timeline)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-54-%d0%bb%d1%83%d1%87%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%b8-%d0%b2%d0%b8%d0%b7%d1%83%d0%b0%d0%bb%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d0%b8-%d0%ba%d0%b0%d0%ba-%d0%bf%d0%be%d0%ba%d0%b0%d0%b7%d0%b0%d1%82%d1%8c-%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d0%b5-%d0%ba%d1%80%d0%b0%d1%81%d0%b8%d0%b2%d0%be-%d0%b8-%d0%bf%d0%be%d0%bd%d1%8f%d1%82%d0%bd%d0%be\"\u003eГлава 5.4: Лучшие практики визуализации. Как показать данные красиво и понятно.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d1%82%d0%b5%d1%85%d0%bd%d0%b8%d0%ba%d0%b8-%d1%84%d0%be%d0%ba%d1%83%d1%81%d0%b8%d1%80%d0%be%d0%b2%d0%ba%d0%b8-focus-techniques\"\u003e1. Техники фокусировки (Focus Techniques)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%bf%d1%80%d0%b8%d0%bd%d1%86%d0%b8%d0%bf%d1%8b-%d0%b4%d0%b8%d0%b7%d0%b0%d0%b9%d0%bd%d0%b0-design-principles\"\u003e2. Принципы дизайна (Design Principles)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d1%80%d0%b0%d1%81%d0%bf%d1%80%d0%be%d1%81%d1%82%d1%80%d0%b0%d0%bd%d0%b5%d0%bd%d0%bd%d1%8b%d0%b5-%d1%82%d0%b8%d0%bf%d1%8b-%d0%b2%d0%b8%d0%b7%d1%83%d0%b0%d0%bb%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d0%b8-common-visualization-types\"\u003e3. Распространенные типы визуализации (Common Visualization Types)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d1%87%d0%b5%d0%b3%d0%be-%d0%bd%d0%b5-%d1%81%d1%82%d0%be%d0%b8%d1%82-%d0%b4%d0%b5%d0%bb%d0%b0%d1%82%d1%8c-%d0%bf%d1%80%d0%b8-%d0%b2%d0%b8%d0%b7%d1%83%d0%b0%d0%bb%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d0%b8-visualization-donts\"\u003e4. Чего НЕ стоит делать при визуализации (Visualization Don\u0026rsquo;ts)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-55-%d0%ba%d0%b0%d0%bd%d0%b2%d0%b0-%d0%b1%d0%b8%d0%b7%d0%bd%d0%b5%d1%81-%d0%bc%d0%be%d0%b4%d0%b5%d0%bb%d0%b8-%d0%b2%d1%81%d1%8f-%d1%81%d1%83%d1%82%d1%8c-%d0%bd%d0%b0-%d0%be%d0%b4%d0%bd%d0%be%d0%b9-%d1%81%d1%82%d1%80%d0%b0%d0%bd%d0%b8%d1%86%d0%b5\"\u003eГлава 5.5: Канва бизнес-модели. Вся суть на одной странице.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d1%86%d0%b5%d0%bd%d0%bd%d0%be%d1%81%d1%82%d0%bd%d1%8b%d0%b5-%d0%bf%d1%80%d0%b5%d0%b4%d0%bb%d0%be%d0%b6%d0%b5%d0%bd%d0%b8%d1%8f-value-propositions\"\u003e1. Ценностные предложения (Value Propositions)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%bf%d0%be%d1%82%d1%80%d0%b5%d0%b1%d0%b8%d1%82%d0%b5%d0%bb%d1%8c%d1%81%d0%ba%d0%b8%d0%b5-%d1%81%d0%b5%d0%b3%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-customer-segments\"\u003e2. Потребительские сегменты (Customer Segments)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d0%ba%d0%b0%d0%bd%d0%b0%d0%bb%d1%8b-%d1%81%d0%b1%d1%8b%d1%82%d0%b0-channels\"\u003e3. Каналы сбыта (Channels)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d0%b2%d0%b7%d0%b0%d0%b8%d0%bc%d0%be%d0%be%d1%82%d0%bd%d0%be%d1%88%d0%b5%d0%bd%d0%b8%d1%8f-%d1%81-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d0%b0%d0%bc%d0%b8-customer-relationships\"\u003e4. Взаимоотношения с клиентами (Customer Relationships)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#5-%d0%bf%d0%be%d1%82%d0%be%d0%ba%d0%b8-%d0%b4%d0%be%d1%85%d0%be%d0%b4%d0%be%d0%b2-revenue-streams\"\u003e5. Потоки доходов (Revenue Streams)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#6-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d1%80%d0%b5%d1%81%d1%83%d1%80%d1%81%d1%8b-key-resources\"\u003e6. Ключевые ресурсы (Key Resources)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#7-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%b2%d0%b8%d0%b4%d1%8b-%d0%b4%d0%b5%d1%8f%d1%82%d0%b5%d0%bb%d1%8c%d0%bd%d0%be%d1%81%d1%82%d0%b8-key-activities\"\u003e7. Ключевые виды деятельности (Key Activities)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#8-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d1%8b%d0%b5-%d0%bf%d0%b0%d1%80%d1%82%d0%bd%d0%b5%d1%80%d1%8b-key-partners\"\u003e8. Ключевые партнеры (Key Partners)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#9-%d1%81%d1%82%d1%80%d1%83%d0%ba%d1%82%d1%83%d1%80%d0%b0-%d0%b8%d0%b7%d0%b4%d0%b5%d1%80%d0%b6%d0%b5%d0%ba-cost-structure\"\u003e9. Структура издержек (Cost Structure)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-61-%d0%bf%d0%be%d0%b4%d1%85%d0%be%d0%b4-%d0%be%d0%b1%d0%bb%d0%b0%d0%ba%d0%b0-%d1%81%d0%b8%d0%bd%d0%be%d0%bd%d0%b8%d0%bc%d0%be%d0%b2-%d1%80%d0%b0%d1%81%d1%88%d0%b8%d1%80%d1%8f%d0%b5%d0%bc-%d0%bf%d0%be%d0%b8%d1%81%d0%ba%d0%be%d0%b2%d1%8b%d0%b9-%d0%b0%d1%80%d1%81%d0%b5%d0%bd%d0%b0%d0%bb\"\u003eГлава 6.1: Подход «облака синонимов». Расширяем поисковый арсенал.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%bf%d0%be%d1%87%d0%b5%d0%bc%d1%83-%d0%be%d0%b1%d0%bb%d0%b0%d0%ba%d0%b0-%d1%81%d0%b8%d0%bd%d0%be%d0%bd%d0%b8%d0%bc%d0%be%d0%b2-%d0%b2%d0%b0%d0%b6%d0%bd%d1%8b\"\u003eПочему «облака синонимов» важны?\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d1%81%d0%be%d0%b7%d0%b4%d0%b0%d0%bd%d0%b8%d0%b5-%d0%be%d0%b1%d0%bb%d0%b0%d0%ba%d0%b0-%d1%81%d0%b8%d0%bd%d0%be%d0%bd%d0%b8%d0%bc%d0%be%d0%b2\"\u003eСоздание «облака синонимов»\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d1%80%d0%b5%d1%81%d1%83%d1%80%d1%81%d1%8b-%d0%b4%d0%bb%d1%8f-%d1%81%d0%be%d0%b7%d0%b4%d0%b0%d0%bd%d0%b8%d1%8f-%d0%be%d0%b1%d0%bb%d0%b0%d0%ba%d0%b0-%d1%81%d0%b8%d0%bd%d0%be%d0%bd%d0%b8%d0%bc%d0%be%d0%b2\"\u003eРесурсы для создания «облака синонимов»\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-62-%d1%8d%d1%84%d1%84%d0%b5%d0%ba%d1%82%d0%b8%d0%b2%d0%bd%d1%8b%d0%b9-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d0%bf%d0%be%d0%b8%d1%81%d0%ba%d0%b0-%d0%bd%d0%b0%d1%88-%d0%b0%d0%bb%d0%b3%d0%be%d1%80%d0%b8%d1%82%d0%bc-%d1%80%d0%b0%d0%b7%d0%b2%d0%b5%d0%b4%d0%ba%d0%b8\"\u003eГлава 6.2: Эффективный процесс поиска. Наш алгоритм разведки.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d1%82%d1%80%d0%b5%d1%85%d1%8d%d1%82%d0%b0%d0%bf%d0%bd%d1%8b%d0%b9-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81\"\u003eТрехэтапный процесс:\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d1%80%d0%b0%d1%81%d1%88%d0%b8%d1%80%d0%b5%d0%bd%d0%bd%d1%8b%d0%b5-%d0%ba%d0%be%d0%bc%d0%b0%d0%bd%d0%b4%d1%8b-google-search\"\u003eРасширенные команды Google Search\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%bd%d0%b0%d1%81%d1%82%d1%80%d0%be%d0%b9%d0%ba%d0%b8-%d0%bc%d0%b5%d1%81%d1%82%d0%be%d0%bf%d0%be%d0%bb%d0%be%d0%b6%d0%b5%d0%bd%d0%b8%d1%8f-location-settings\"\u003eНастройки местоположения (Location Settings)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-63-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b4%d0%bb%d1%8f-%d1%83%d0%bb%d1%83%d1%87%d1%88%d0%b5%d0%bd%d0%b8%d1%8f-%d0%bf%d0%be%d0%b8%d1%81%d0%ba%d0%b0-%d0%bd%d0%b0%d1%88-%d0%bd%d0%b0%d0%b1%d0%be%d1%80-%d1%83%d1%82%d0%b8%d0%bb%d0%b8%d1%82\"\u003eГлава 6.3: Инструменты для улучшения поиска. Наш набор утилит.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-multi-highlighter-%d0%bc%d1%83%d0%bb%d1%8c%d1%82%d0%b8-%d0%b2%d1%8b%d0%b4%d0%b5%d0%bb%d0%b8%d1%82%d0%b5%d0%bb%d1%8c\"\u003e1. Multi Highlighter (Мульти-выделитель)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-google-dictionary-%d1%81%d0%bb%d0%be%d0%b2%d0%b0%d1%80%d1%8c-google\"\u003e2. Google Dictionary (Словарь Google)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-simple-scraper-%d0%bf%d1%80%d0%be%d1%81%d1%82%d0%be%d0%b9-%d1%81%d0%ba%d1%80%d0%b5%d0%bf%d0%b5%d1%80\"\u003e3. Simple Scraper (Простой скрепер)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-google-alerts-%d0%be%d0%bf%d0%be%d0%b2%d0%b5%d1%89%d0%b5%d0%bd%d0%b8%d1%8f-google\"\u003e4. Google Alerts (Оповещения Google)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-64-%d0%bb%d1%83%d1%87%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%b8-%d1%8d%d1%84%d1%84%d0%b5%d0%ba%d1%82%d0%b8%d0%b2%d0%bd%d0%be%d1%81%d1%82%d0%b8-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%ba%d0%b0%d0%ba-%d0%bd%d0%b5-%d1%82%d1%80%d0%b0%d1%82%d0%b8%d1%82%d1%8c-%d0%b2%d1%80%d0%b5%d0%bc%d1%8f-%d0%b2%d0%bf%d1%83%d1%81%d1%82%d1%83%d1%8e\"\u003eГлава 6.4: Лучшие практики эффективности исследования. Как не тратить время впустую.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%bf%d1%80%d0%be%d0%b2%d0%b5%d1%80%d1%8f%d0%b9-%d1%80%d0%b5%d0%b7%d1%83%d0%bb%d1%8c%d1%82%d0%b0%d1%82%d1%8b-%d0%bf%d0%be%d0%b8%d1%81%d0%ba%d0%b0-%d0%bf%d0%be-%d0%b8%d0%b7%d0%be%d0%b1%d1%80%d0%b0%d0%b6%d0%b5%d0%bd%d0%b8%d1%8f%d0%bc-check-image-search-results\"\u003e1. Проверяй результаты поиска по изображениям (Check image search results).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%bf%d1%80%d0%be%d0%b2%d0%b5%d1%80%d1%8f%d0%b9-%d0%b4%d0%be%d1%81%d1%82%d0%be%d0%b2%d0%b5%d1%80%d0%bd%d0%be%d1%81%d1%82%d1%8c-%d0%b8%d1%81%d1%82%d0%be%d1%87%d0%bd%d0%b8%d0%ba%d0%b0-verify-source-credibility\"\u003e2. Проверяй достоверность источника (Verify source credibility).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d0%b8%d1%89%d0%b8-%d0%b4%d0%b0%d1%82%d1%8b-%d0%bf%d1%83%d0%b1%d0%bb%d0%b8%d0%ba%d0%b0%d1%86%d0%b8%d0%b8-look-for-publication-dates\"\u003e3. Ищи даты публикации (Look for publication dates).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d0%b8%d0%b7%d1%83%d1%87%d0%b0%d0%b9-%d0%be%d0%bf%d0%b8%d1%81%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b8%d1%81%d1%82%d0%be%d1%87%d0%bd%d0%b8%d0%ba%d0%be%d0%b2-examine-source-descriptions\"\u003e4. Изучай описания источников (Examine source descriptions).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#5-%d0%b1%d1%83%d0%b4%d1%8c-%d0%bc%d0%b5%d1%82%d0%be%d0%b4%d0%b8%d1%87%d0%b5%d0%bd-be-methodical\"\u003e5. Будь методичен (Be methodical).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#6-%d0%b8%d1%81%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d1%83%d0%b9-%d1%80%d0%b0%d1%81%d1%88%d0%b8%d1%80%d0%b5%d0%bd%d0%bd%d1%83%d1%8e-%d1%84%d0%b8%d0%bb%d1%8c%d1%82%d1%80%d0%b0%d1%86%d0%b8%d1%8e-use-advanced-filtering\"\u003e6. Используй расширенную фильтрацию (Use advanced filtering).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#7-%d0%b8%d1%82%d0%b5%d1%80%d0%b8%d1%80%d1%83%d0%b9-%d1%81%d0%b2%d0%be%d0%b8-%d0%bf%d0%be%d0%b8%d1%81%d0%ba%d0%be%d0%b2%d1%8b%d0%b5-%d0%b7%d0%b0%d0%bf%d1%80%d0%be%d1%81%d1%8b-iterate-your-searches\"\u003e7. Итерируй свои поисковые запросы (Iterate your searches).\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-65-%d1%80%d0%b0%d1%81%d0%bf%d1%80%d0%be%d1%81%d1%82%d1%80%d0%b0%d0%bd%d0%b5%d0%bd%d0%bd%d1%8b%d0%b5-%d0%be%d1%88%d0%b8%d0%b1%d0%ba%d0%b8-%d0%bf%d1%80%d0%b8-%d0%bf%d0%be%d0%b8%d1%81%d0%ba%d0%b5-%d0%ba%d0%b0%d0%ba-%d0%bd%d0%b5-%d0%bd%d0%b0%d1%81%d1%82%d1%83%d0%bf%d0%b8%d1%82%d1%8c-%d0%bd%d0%b0-%d0%b3%d1%80%d0%b0%d0%b1%d0%bb%d0%b8\"\u003eГлава 6.5: Распространенные ошибки при поиске. Как не наступить на грабли.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%bf%d0%be%d0%b8%d1%81%d0%ba-%d0%bf%d0%be-%d0%be%d0%b4%d0%bd%d0%be%d0%bc%d1%83-%d0%ba%d0%bb%d1%8e%d1%87%d0%b5%d0%b2%d0%be%d0%bc%d1%83-%d1%81%d0%bb%d0%be%d0%b2%d1%83-single-keyword-searching\"\u003e1. Поиск по одному ключевому слову (Single keyword searching).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%b8%d0%b3%d0%bd%d0%be%d1%80%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%b0%d0%bb%d1%8c%d1%82%d0%b5%d1%80%d0%bd%d0%b0%d1%82%d0%b8%d0%b2%d0%bd%d0%be%d0%b9-%d1%82%d0%b5%d1%80%d0%bc%d0%b8%d0%bd%d0%be%d0%bb%d0%be%d0%b3%d0%b8%d0%b8-ignoring-alternative-terminology\"\u003e2. Игнорирование альтернативной терминологии (Ignoring alternative terminology).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d0%be%d1%81%d1%82%d0%b0%d0%bd%d0%be%d0%b2%d0%ba%d0%b0-%d0%bd%d0%b0-%d0%bf%d0%b5%d1%80%d0%b2%d0%be%d0%b9-%d1%81%d1%82%d1%80%d0%b0%d0%bd%d0%b8%d1%86%d0%b5-stopping-at-the-first-page\"\u003e3. Остановка на первой странице (Stopping at the first page).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d0%b8%d0%b3%d0%bd%d0%be%d1%80%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d1%80%d0%b5%d0%b7%d1%83%d0%bb%d1%8c%d1%82%d0%b0%d1%82%d0%be%d0%b2-%d0%bf%d0%be%d0%b8%d1%81%d0%ba%d0%b0-%d0%bf%d0%be-%d0%b8%d0%b7%d0%be%d0%b1%d1%80%d0%b0%d0%b6%d0%b5%d0%bd%d0%b8%d1%8f%d0%bc-overlooking-image-results\"\u003e4. Игнорирование результатов поиска по изображениям (Overlooking image results).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#5-%d0%bf%d1%80%d0%b8%d0%bd%d1%8f%d1%82%d0%b8%d0%b5-%d0%b8%d0%bd%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d0%b8-%d0%b1%d0%b5%d0%b7-%d0%bf%d1%80%d0%be%d0%b2%d0%b5%d1%80%d0%ba%d0%b8-accepting-information-without-verification\"\u003e5. Принятие информации без проверки (Accepting information without verification).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#6-%d0%b8%d1%81%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%bd%d0%b5%d0%bf%d0%be%d0%b4%d1%85%d0%be%d0%b4%d1%8f%d1%89%d0%b8%d1%85-%d0%b3%d0%b5%d0%be%d0%b3%d1%80%d0%b0%d1%84%d0%b8%d1%87%d0%b5%d1%81%d0%ba%d0%b8%d1%85-%d0%bd%d0%b0%d1%81%d1%82%d1%80%d0%be%d0%b5%d0%ba-using-inappropriate-geography-settings\"\u003e6. Использование неподходящих географических настроек (Using inappropriate geography settings).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#7-%d0%bd%d0%b5%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%bf%d0%be-%d1%81%d1%81%d1%8b%d0%bb%d0%ba%d0%b0%d0%bc-not-following-citation-trails\"\u003e7. Неследование по ссылкам (Not following citation trails).\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-71-%d0%b2%d0%bb%d0%b8%d1%8f%d0%bd%d0%b8%d0%b5-%d0%b8%d0%b8-%d0%bd%d0%b0-%d0%bc%d0%b5%d1%82%d0%be%d0%b4%d0%be%d0%bb%d0%be%d0%b3%d0%b8%d0%b8-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%bd%d0%be%d0%b2%d1%8b%d0%b9-%d0%b8%d0%b3%d1%80%d0%be%d0%ba-%d0%bd%d0%b0-%d0%bf%d0%be%d0%bb%d0%b5\"\u003eГлава 7.1: Влияние ИИ на методологии исследования. Новый игрок на поле.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d1%82%d0%b5%d0%ba%d1%83%d1%89%d0%b8%d0%b5-%d1%81%d0%b8%d0%bb%d1%8c%d0%bd%d1%8b%d0%b5-%d1%81%d1%82%d0%be%d1%80%d0%be%d0%bd%d1%8b-%d0%b8%d0%b8-%d0%b2-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f%d1%85\"\u003eТекущие сильные стороны ИИ в исследованиях:\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d1%82%d0%b5%d0%ba%d1%83%d1%89%d0%b8%d0%b5-%d0%be%d0%b3%d1%80%d0%b0%d0%bd%d0%b8%d1%87%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b8%d0%b8\"\u003eТекущие ограничения ИИ:\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-72-%d1%8d%d1%84%d1%84%d0%b5%d0%ba%d1%82%d0%b8%d0%b2%d0%bd%d1%8b%d0%b5-%d0%bf%d1%80%d0%be%d0%bc%d0%bf%d1%82%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%b8%d0%b8-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b9-%d0%ba%d0%b0%d0%ba-%d0%b3%d0%be%d0%b2%d0%be%d1%80%d0%b8%d1%82%d1%8c-%d1%81-%d0%bc%d0%b0%d1%88%d0%b8%d0%bd%d0%be%d0%b9\"\u003eГлава 7.2: Эффективные промпты для ИИ-исследований. Как говорить с машиной.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%bb%d1%83%d1%87%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%b8-%d0%b4%d0%bb%d1%8f-%d0%b8%d0%b8-%d0%bf%d1%80%d0%be%d0%bc%d0%bf%d1%82%d0%be%d0%b2\"\u003eЛучшие практики для ИИ-промптов:\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%bf%d1%80%d0%b8%d0%bc%d0%b5%d1%80-%d1%81%d1%82%d1%80%d1%83%d0%ba%d1%82%d1%83%d1%80%d1%8b-%d0%bf%d1%80%d0%be%d0%bc%d0%bf%d1%82%d0%b0\"\u003eПример структуры промпта:\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-73-%d0%b8%d0%b8-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-%d0%bd%d0%b0%d1%88-%d1%86%d0%b8%d1%84%d1%80%d0%be%d0%b2%d0%be%d0%b9-%d0%b0%d1%80%d1%81%d0%b5%d0%bd%d0%b0%d0%bb\"\u003eГлава 7.3: ИИ-инструменты для исследования рынка. Наш цифровой арсенал.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-chatgpt\"\u003e1. ChatGPT\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-agent-gpt\"\u003e2. Agent GPT\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-lumina\"\u003e3. Lumina\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-julius\"\u003e4. Julius\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#5-durable\"\u003e5. Durable\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#6-flowgpt\"\u003e6. FlowGPT\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#7-plus-ai\"\u003e7. Plus AI\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-74-%d0%bb%d1%83%d1%87%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%b8-%d0%b8%d0%bd%d1%82%d0%b5%d0%b3%d1%80%d0%b0%d1%86%d0%b8%d0%b8-%d0%b8%d0%b8-%d0%ba%d0%b0%d0%ba-%d0%b7%d0%b0%d1%81%d1%82%d0%b0%d0%b2%d0%b8%d1%82%d1%8c-%d0%b8%d0%b8-%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%b0%d1%82%d1%8c-%d0%bd%d0%b0-%d0%bd%d0%b0%d1%81\"\u003eГлава 7.4: Лучшие практики интеграции ИИ. Как заставить ИИ работать на нас.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%b3%d0%b8%d0%b1%d1%80%d0%b8%d0%b4%d0%bd%d1%8b%d0%b9-%d0%bf%d0%be%d0%b4%d1%85%d0%be%d0%b4-hybrid-approach\"\u003e1. Гибридный подход (Hybrid approach).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%bf%d1%80%d0%be%d0%b2%d0%b5%d1%80%d1%8f%d0%b9-%d1%84%d0%b0%d0%ba%d1%82%d0%b8%d1%87%d0%b5%d1%81%d0%ba%d0%b8%d0%b5-%d1%83%d1%82%d0%b2%d0%b5%d1%80%d0%b6%d0%b4%d0%b5%d0%bd%d0%b8%d1%8f-verify-factual-claims\"\u003e2. Проверяй фактические утверждения (Verify factual claims).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d1%83%d0%ba%d0%b0%d0%b7%d1%8b%d0%b2%d0%b0%d0%b9-%d0%bc%d0%b5%d1%82%d0%be%d0%b4%d0%be%d0%bb%d0%be%d0%b3%d0%b8%d0%b8-specify-methodologies\"\u003e3. Указывай методологии (Specify methodologies).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#4-%d0%bf%d1%80%d0%b5%d0%b4%d0%be%d1%81%d1%82%d0%b0%d0%b2%d0%bb%d1%8f%d0%b9-%d0%bf%d1%80%d0%b8%d0%bc%d0%b5%d1%80%d1%8b-provide-examples\"\u003e4. Предоставляй примеры (Provide examples).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#5-%d0%b8%d1%81%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d1%83%d0%b9-%d0%b4%d0%bb%d1%8f-%d0%b3%d0%b5%d0%bd%d0%b5%d1%80%d0%b0%d1%86%d0%b8%d0%b8-%d0%b8%d0%b4%d0%b5%d0%b9-%d0%b0-%d0%bd%d0%b5-%d0%b4%d0%bb%d1%8f-%d0%be%d0%ba%d0%be%d0%bd%d1%87%d0%b0%d1%82%d0%b5%d0%bb%d1%8c%d0%bd%d1%8b%d1%85-%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d0%b9-use-for-ideation-not-finalization\"\u003e5. Используй для генерации идей, а не для окончательных решений (Use for ideation, not finalization).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#6-%d0%ba%d0%be%d0%bc%d0%b1%d0%b8%d0%bd%d0%b8%d1%80%d1%83%d0%b9-%d0%b8%d0%b8-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-combine-ai-tools\"\u003e6. Комбинируй ИИ-инструменты (Combine AI tools).\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-75-%d0%bf%d1%80%d0%b8%d0%bc%d0%b5%d1%80-%d1%80%d0%b0%d0%b1%d0%be%d1%87%d0%b5%d0%b3%d0%be-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81%d0%b0-%d0%b8%d0%b8-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%ba%d0%b5%d0%b9%d1%81-%d1%81%d1%82%d0%b0%d0%b4%d0%b8\"\u003eГлава 7.5: Пример рабочего процесса ИИ-исследования. Кейс-стади.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%bf%d1%80%d0%b8%d0%bc%d0%b5%d1%80-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7-%d0%be%d1%82%d0%ba%d1%80%d1%8b%d1%82%d1%8b%d1%85-%d0%be%d1%82%d0%b2%d0%b5%d1%82%d0%be%d0%b2-%d0%be%d0%bf%d1%80%d0%be%d1%81%d0%b0\"\u003eПример: Анализ открытых ответов опроса\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-81-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-%d0%bf%d0%be%d1%88%d0%b0%d0%b3%d0%be%d0%b2%d0%be-%d0%bd%d0%b0%d1%88-%d1%87%d0%b5%d0%ba-%d0%bb%d0%b8%d1%81%d1%82\"\u003eГлава 8.1: Процесс исследования рынка: пошагово. Наш чек-лист.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%ba%d0%be%d0%bc%d0%bf%d0%bb%d0%b5%d0%ba%d1%81%d0%bd%d1%8b%d0%b9-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-%d0%b2%d0%ba%d0%bb%d1%8e%d1%87%d0%b0%d0%b5%d1%82-%d1%81%d0%bb%d0%b5%d0%b4%d1%83%d1%8e%d1%89%d0%b8%d0%b5-%d0%bf%d0%be%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d1%82%d0%b5%d0%bb%d1%8c%d0%bd%d1%8b%d0%b5-%d1%88%d0%b0%d0%b3%d0%b8\"\u003eКомплексный процесс исследования рынка включает следующие последовательные шаги:\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-82-%d0%be%d1%81%d0%bd%d0%be%d0%b2%d0%bd%d1%8b%d0%b5-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-%d0%bd%d0%b0%d1%88-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d0%b0%d1%80%d0%b8%d0%b9\"\u003eГлава 8.2: Основные инструменты исследования рынка. Наш инструментарий.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#1-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b0%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7%d0%b0-analysis-tools\"\u003e1. Инструменты анализа (Analysis Tools)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#2-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-research-tools\"\u003e2. Инструменты исследования (Research Tools)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#3-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%bf%d0%be%d0%b8%d1%81%d0%ba%d0%b0-search-tools\"\u003e3. Инструменты поиска (Search Tools)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-83-%d0%bf%d1%80%d0%b8%d0%bd%d1%86%d0%b8%d0%bf%d1%8b-%d1%8d%d1%84%d1%84%d0%b5%d0%ba%d1%82%d0%b8%d0%b2%d0%bd%d0%be%d1%81%d1%82%d0%b8-%d0%ba%d0%b0%d0%ba-%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%b0%d1%82%d1%8c-%d1%83%d0%bc%d0%bd%d0%be-%d0%b0-%d0%bd%d0%b5-%d0%bc%d0%bd%d0%be%d0%b3%d0%be\"\u003eГлава 8.3: Принципы эффективности. Как работать умно, а не много.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d1%87%d1%82%d0%be%d0%b1%d1%8b-%d0%bf%d1%80%d0%be%d0%b2%d0%be%d0%b4%d0%b8%d1%82%d1%8c-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-%d1%8d%d1%84%d1%84%d0%b5%d0%ba%d1%82%d0%b8%d0%b2%d0%bd%d0%be\"\u003eЧтобы проводить исследование рынка эффективно:\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-84-%d0%bf%d0%be%d0%ba%d0%b0%d0%b7%d0%b0%d1%82%d0%b5%d0%bb%d0%b8-%d0%ba%d0%b0%d1%87%d0%b5%d1%81%d1%82%d0%b2%d0%b0-%d0%ba%d0%b0%d0%ba-%d0%bf%d0%be%d0%bd%d1%8f%d1%82%d1%8c-%d1%87%d1%82%d0%be-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%b3%d0%be%d0%b4%d0%bd%d0%be%d0%b5\"\u003eГлава 8.4: Показатели качества. Как понять, что исследование годное.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b2%d1%8b%d1%81%d0%be%d0%ba%d0%be%d0%ba%d0%b0%d1%87%d0%b5%d1%81%d1%82%d0%b2%d0%b5%d0%bd%d0%bd%d0%be%d0%b5-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0-%d1%85%d0%b0%d1%80%d0%b0%d0%ba%d1%82%d0%b5%d1%80%d0%b8%d0%b7%d1%83%d0%b5%d1%82%d1%81%d1%8f\"\u003eВысококачественное исследование рынка характеризуется:\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%b3%d0%bb%d0%b0%d0%b2%d0%b0-85-%d1%81%d0%bb%d0%b5%d0%b4%d1%83%d1%8e%d1%89%d0%b8%d0%b5-%d1%88%d0%b0%d0%b3%d0%b8-%d1%87%d1%82%d0%be-%d0%b4%d0%b5%d0%bb%d0%b0%d1%82%d1%8c-%d0%bf%d0%be%d1%81%d0%bb%d0%b5-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f\"\u003eГлава 8.5: Следующие шаги. Что делать после исследования.\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/market_research/#%d0%bf%d0%be%d1%81%d0%bb%d0%b5-%d0%b7%d0%b0%d0%b2%d0%b5%d1%80%d1%88%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b8%d1%81%d1%81%d0%bb%d0%b5%d0%b4%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d1%80%d1%8b%d0%bd%d0%ba%d0%b0\"\u003eПосле завершения исследования рынка:\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"глава-11-цели-исследования-рынка-зачем-нам-это\"\u003eГлава 1.1: Цели исследования рынка. Зачем нам это?\u003c/h2\u003e\n\u003cp\u003eКоллега, давай начистоту. «Исследование рынка» звучит как что-то из мира маркетологов в модных пиджаках, а не из нашей с тобой инженерной окопной правды. Но дьявол, как всегда, в деталях. В нашем R\u0026amp;D/presale контексте — это не просто «анализ», а суровый производственный инструмент.\u003c/p\u003e","title":"Концепция исследования рынка для инженеров в R\u0026D и presale"},{"content":"Создавайте ИИ-приложения с Claude и делитесь ими\nНовая функция от Anthropic, которая позволяет создавать небольшие приложения на основе ИИ и делиться ими с помощью артефактов. Такие приложения используют для работы аккаунт Claude конечного пользователя. Выяснилось, что у Gemini эта функция существует уже некоторое время.\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-26-93a301c0/","summary":"\u003cp\u003e\u003ca href=\"https://www.anthropic.com/news/claude-powered-artifacts\"\u003eСоздавайте ИИ-приложения с Claude и делитесь ими\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eНовая функция от Anthropic, которая позволяет создавать небольшие приложения на основе ИИ и делиться ими с помощью артефактов. Такие приложения используют для работы аккаунт Claude конечного пользователя.\n\u003ca href=\"https://x.com/emollick/status/1938091740121935929\"\u003eВыяснилось\u003c/a\u003e, что у Gemini эта функция существует уже некоторое время.\u003c/p\u003e","title":"2025-06-26"},{"content":"Gemini CLI: ваш open source ИИ-агент\nТеперь и у Google есть собственный CLI-агент для кодинга. Огромный контекст, щедрый бесплатный тариф (в большинстве случаев он вообще бесплатен) и полностью открытый исходный код. Сам я его ещё не пробовал, но выглядит впечатляюще.\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-25-9bb932fa/","summary":"\u003cp\u003e\u003ca href=\"https://blog.google/technology/developers/introducing-gemini-cli-open-source-ai-agent/\"\u003eGemini CLI: ваш open source ИИ-агент\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eТеперь и у Google есть собственный CLI-агент для кодинга. Огромный контекст, щедрый бесплатный тариф (в большинстве случаев он вообще бесплатен) и полностью открытый исходный код. Сам я его ещё не пробовал, но выглядит впечатляюще.\u003c/p\u003e","title":"2025-06-25"},{"content":"Anthropic выигрывает решение об обучении ИИ в иске о нарушении авторских прав, но предстанет перед судом за пиратские книги\nОчень важный юридический прецедент в области авторского права. TL;DR: обучение моделей на легально приобретённых материалах, защищённых копирайтом, признано добросовестным использованием (fair use). Создателям модели нужно позаботиться о том, чтобы её вывод был «квинтэссенциально трансформативным».\nНелегальное приобретение обучающих данных наказуемо, как и прежде.\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-25-f08b90df/","summary":"\u003cp\u003e\u003ca href=\"https://apnews.com/article/anthropic-ai-fair-use-copyright-pirated-libraries-1e5cece51c2e4bd0bb21d94de2abb035\"\u003eAnthropic выигрывает решение об обучении ИИ в иске о нарушении авторских прав, но предстанет перед судом за пиратские книги\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eОчень важный юридический прецедент в области авторского права. TL;DR: обучение моделей на легально приобретённых материалах, защищённых копирайтом, признано добросовестным использованием (fair use). Создателям модели нужно позаботиться о том, чтобы её вывод был «квинтэссенциально трансформативным».\u003c/p\u003e\n\u003cp\u003eНелегальное приобретение обучающих данных наказуемо, как и прежде.\u003c/p\u003e","title":"2025-06-25"},{"content":"Обычно я стараюсь подходить ко всяким новым блестящим штучкам с определенной долей скептицизма. Именно таким, до недавнего времени, было мое отношение к мультиагентным системам. Я бы сказал, что это неудивительно, так как вокруг них сейчас очень много шума, а по-настоящему успешных примеров такого подхода я не видел. Большинство реализаций, которые действительно работали, относились к одному из следующих видов:\nАгентные системы, действующие по определенному плану. То есть LLM с инструментами, натасканные на автоматизацию вполне конкретного процесса. Благодаря этому, каждый шаг можно тестировать по отдельности и верифицировать его результаты. Описываются такие системы, как правило, в виде направленного ациклического графа (DAG), иногда динамического, и разрабатываются с помощью уже стандартных примитивов из фреймворков типа LangChain и Griptape1. Так функционировала ранняя реализация Gemini Deep Research, в которой сначала составлялся план поиска, затем выполнялся сам поиск, и в конце собирался результат. Решения, работающие в системах с обратной связью. Различные Claude Code, Cursor и прочие агенты, имеющие дело с кодом. Причем чем сильнее обратная связь, читай, чем лучше тулинг и строже проверка типов, тем больше шансов, что они окончательно не испортят вам кодовую базу2. Модели, обученные с помощью Reinforcement Learning, такие как модели с interleaved thinking, вроде OpenAI o3. Это отдельный разговор, и очень интересный, но даже такие модели имеют какой-то modus operandi, определенный особенностями их обучения. При этом мультиагентные системы открытого типа ввиду их общей ненадежности до сих пор существовали в большей части в виде proof of concept. В сообществе не было понимания, где их применять и как именно их реализовывать. Пока не появилась глубокая инженерная статья от Anthropic о том, как они разрабатывали свой Deep Research. В ней был определен достаточно четкий фреймворк для построения таких систем, и именно его мы сегодня и рассмотрим.\nСамое главное Самое главное в этой статье — это выделение паттерна мультиагентных систем с динамической оркестрацией. Да-да, я провожу здесь прямую аналогию с классическими паттернами проектирования из мира программирования.\nКлассические паттерны — это плотно упакованные кусочки мудрости архитекторов и программистов, написавших сотни тысяч программных систем. Проанализировав их, они выделили определенные закономерности, которые формализовали для повышения уровня абстракции архитектурных проблем и удобства коммуникации.\nХороший паттерн состоит из3:\nЦепкого названия. Обязательный компонент, без которого паттерн попросту не приживется. Описания задачи, которую он решает. Как правило, она достаточно общая, чтобы ее имело смысл обобщать. Описания самого паттерна. И описания того, где его применять не следует. Посмотрим теперь на то, что инженеры Anthropic приводят в своей статье:\nНазвание В статье его называют orchestrator-worker, что отражает суть, но теряет важное отличие от классического паттерна — динамическую природу и адаптацию заданий для рабочих в зависимости от изначальной задачи. Я считаю, что это достаточно серьезная особенность, чтобы отразить ее в названии. Другие наименования, которые они используют — Advanced Research, multi-agent research system — это уже скорее про описание области применения. Поэтому дальше я буду называть его \u0026ldquo;Adaptive Orchestrator\u0026rdquo;, или AdOrc4.\nОписание задачи This unpredictability makes AI agents particularly well-suited for research tasks. Research demands the flexibility to pivot or explore tangential connections as the investigation unfolds. The model must operate autonomously for many turns, making decisions about which directions to pursue based on intermediate findings. A linear, one-shot pipeline cannot handle these tasks.\nThe essence of search is compression: distilling insights from a vast corpus. Subagents facilitate compression by operating in parallel with their own context windows, exploring different aspects of the question simultaneously before condensing the most important tokens for the lead research agent. Each subagent also provides separation of concerns—distinct tools, prompts, and exploration trajectories—which reduces path dependency and enables thorough, independent investigations.\n…\nOur internal evaluations show that multi-agent research systems excel especially for breadth-first queries that involve pursuing multiple independent directions simultaneously.\nЗдесь инженеры четко указывают, в каких случаях паттерн хорошо себя показывает:\nВ случаях, где необходимо модифицировать план в зависимости от промежуточных результатов. Это не детерминированные бизнес-процессы, это исследование окружающего мира. Поисковые и исследовательские задачи ложатся сюда идеально. Там мы упираемся в технические ограничения одного агента. Основным является контекст, но он тянет за собой задержки и высокую стоимость инференса, а также некоторое падение качества, связанное с особенностями механизма внимания. И наконец, в ситуациях, в которых есть возможность запуска большого количества независимых параллельных подзадач. Паттерн показывает себя в лучшем виде, например, в патентных поисках или Due Diligence, то есть там, где люди тоже работают параллельно. Описание паттерна Our Research system uses a multi-agent architecture with an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel.\nThe multi-agent architecture in action: user queries flow through a lead agent that creates specialized subagents to search for different aspects in parallel.\nWhen a user submits a query, the lead agent analyzes it, develops a strategy, and spawns subagents to explore different aspects simultaneously. As shown in the diagram above, the subagents act as intelligent filters by iteratively using search tools to gather information, in this case on AI agent companies in 2025, and then returning a list of companies to the lead agent so it can compile a final answer.\nTraditional approaches using Retrieval Augmented Generation (RAG) use static retrieval. That is, they fetch some set of chunks that are most similar to an input query and use these chunks to generate a response. In contrast, our architecture uses a multi-step search that dynamically finds relevant information, adapts to new findings, and analyzes results to formulate high-quality answers.\nИтак, структура паттерна из описания ясна:\nСистема состоит из оркестратора и рабочих. Они — это LLM (или LMM5) с доступом к инструментам. Оркестратор в общем случае может выделять конкретные инструменты конкретным рабочим. В систему поступают задание и что описание желаемого результата. Процесс начинается с построения плана, в котором задачи могут выполняться как самим оркестратором, так и специализированными рабочими, в случае, когда это удовлетворяет условиям, перечисленным выше. На каждом шаге оркестратор запускает рабочих, которые выполняют действия и возвращают ему полученные данные. В конце цикла проверяется условие завершения, и процесс либо возвращается к пункту 3, где оркестратор модифицирует план, либо процесс завершается и результат возвращается пользователю. Приведу несколько возможных причин завершения: Достижение требований задачи (успешный выход); Превышение выделенного бюджета; Превышение заданного количества итераций; Схождение (отсутствие видимых улучшений за последние несколько итераций). graph TD subgraph \u0026#34;Цикл AdOrc\u0026#34; A(1\\. Получение задания и желаемого результата) --\u0026gt; B(2\\. Построение / Модификация плана); B --\u0026gt; C(3\\. Запуск рабочих и получение результатов); C --\u0026gt; D{4\\. Проверка условия завершения}; D -- Нет, нужна доработка --\u0026gt; B; D -- Да, цель достигнута --\u0026gt; E(Возврат результата пользователю); end subgraph \u0026#34;Причины завершения\u0026#34; F[\u0026#34;-Соответствие результата требованиям\u0026lt;br/\u0026gt;-Превышение бюджета или лимита итераций\u0026lt;br/\u0026gt;-Схождение результата (отсутствие улучшений)\u0026#34;]; end D -.- F; Ограничения Посмотрим теперь, где этот паттерн показывает себя хуже. Авторы пишут следующее:\n… in practice, these architectures burn through tokens fast. In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats. For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance. Further, some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today. For instance, most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time.\n…\nSubagent output to a filesystem to minimize the ‘game of telephone.’ Direct subagent outputs can bypass the main coordinator for certain types of results, improving both fidelity and performance.\nКак мы видим, недостатки у такого подхода тоже есть:\nЦена. Запуск такой системы дорог, поэтому он должен использоваться для задач с относительно высокой экономической ценностью, например, анализ прецедентного права, обзор статей в определенной научной области, сбор отзывов и советов при изучении новой технологии. Независимость агентов. Да, иногда это недостаток, к примеру, когда агентам нужно держать большой общий контекст. Примером может служить система обработки документов, одновременно анализирующая документ с разных точек зрения. В реализации Deep Research рабочим приходилось иногда коммуницировать через файловую систему, что стоит рассматривать как костыль. Задержки. Циклическая природа исследования с использованием мощных (и, соответственно, медленных) моделей, приводит к тому, что ожидание результата в течение нескольких минут — нормальное явление. Это требует особого построения взаимодействия с пользователем, что делает его неприменимым для огромного пласта приложений. Соответственно, AdOrc чаще всего не подходит для таких сценариев, как:\nНаписание нового кода. Как уже давно известно, написание кода не всегда дружит с параллелизмом, и разбиение заданий таким образом, чтобы члены команды не мешали друг другу — это серьезная головная боль. Тем не менее этот шаблон может быть полезен в других аспектах разработки ПО, помогая погружаться в новую кодовую базу, рефакторить и отлаживать. Автоматизация бизнес-процессов. Большинство из них относительно хорошо формализованы, и поэтому лучше решаются агентами с фиксированным планом. В последнее время появляются кейс-стади более масштабных и гибких автоматизаций, но они не предоставляют достаточного количества деталей, чтобы оценить их эффективность и надежность. Поиск по базам знаний. Здесь данный паттерн в принципе применим, но ввиду его высоких задержек и стоимости, для таких задач классические RAG-системы подходят лучше. Создание AGI или ASI. Нет, я не говорю, что этот паттерн неприменим для AGI. Просто никто не знает, что для этого вообще применимо. Невредные советы Теперь, когда мы познакомились с главным по моему мнению вкладом поста в наше техническое поле знаний, посмотрим на некоторые советы, которые дают разработчики Anthropic строителям подобных агентных систем. Поскольку разработчики отлично сопроводили их своими заметками, я не буду повторять их все, ограничусь только наиболее мне импонирующими.\nНачинайте оценивать с самого начала, даже с маленькой выборкой. Оценка модели — это дорого, сложно и непонятно, и поэтому многие продукты ограничиваются \u0026ldquo;vibe checking\u0026rdquo;, или, как этот метод еще называют \u0026ldquo;я попробовал этот промпт в ChatGPT, вроде работает\u0026rdquo;. Этот путь ведет в никуда (к многомиллионным искам, к провалу продукта, или просто к джейлбрейку системы, нужное подчеркнуть). Построение эффективной и автоматической eval и red teaming системы, которая поможет отлавливать проблемы, пока они еще не проявились — это важная инженерная практика. И это не говоря о том, что улучшение промптов системы без возможности их надежно оценить — это что-то из разряда избиения пиньяты с завязанными глазами. Для разработки eval можно использовать такие проекты, как promptfoo и DeepEval, которые поддерживают множество полезных метрик и LLM-as-judge из коробки.\nLLM-as-judge масштабируется, если приготовить его правильно. Да, но его готовка — особое искусство. Различные LLM оценивают один и тот же вывод совершенно по-разному. В статье предлагается использовать LLM для выставления ответам оценок от 0 до 1. Это прямо противоречит известным работам о том, что даже мощные модели не могут последовательно выставлять подобные оценки. Наиболее надежный метод использования LLM-as-judge — это попарное сравнение двух результатов, да еще и с применением мажоритарного голосования и перестановки вариантов местами. В общем, в данном совете что-то не сходится. Впрочем, вполне возможно, что при реализации Deep Research оценки работали достаточно хорошо.\nОценка людьми ловит то, что пропустила автоматика. Оценка людьми — дорогой и крайне субъективный процесс. Но выбрасывать этот шаг из процесса нельзя, потому что только он может выявить корнер-кейсы, не предусмотренные тестами. В статье приводятся пример того, как тестировщик увидел, что начальная версия системы велась на SEO и игнорировала богатые полезным контентом научные статьи и персональные блоги. LLM-as-judge и другие метрики сами по себе этого обнаружить не могли, поскольку не учитывали тип ресурса как входной параметр. После добавления этого параметра и определенных эвристик к промпту поведение модели улучшилось, и тесты были адаптированы, чтобы учитывать этот параметр.\nАгенты обладают состоянием и накапливающейся ошибкой. Охохо, это та самая проблема, из-за которой многошаговые агенты без обратной связи ломаются. Это теория вероятности, и с ней не поспоришь. Если у агента есть 99% вероятность завершить шаг верно, то какая вероятность будет корректно завершить 10-шаговый процесс? 90%. А тридцатишаговый? 74%. Стошаговый процесс будет ломаться в 2/3 случаев. И это идеализированная ситуация. У стохастической LLM, работающей в беспорядочном реальном мире, вероятность проблем значительно выше. И речь не столько о предсказуемых технических сбоях (дефект программы, кривая кодировка), сколько о специфических проблемах самой модели: галлюцинациях, скачках в логике, засорении контекста и т.д.\nУсугубляет ситуацию то, что последствия ошибок сохраняются в состоянии агента и \u0026ldquo;отравляет\u0026rdquo; все последующие шаги. Выход здесь \u0026mdash; это либо вводить промежуточную обратную связь, что не всегда возможно, либо ограничивать количество ходов. Именно комбинация этих способов позволяет шаблону AdOrc и Deep Research в частности нормально работать. Количество ходов оркестратора здесь малО, зато на каждом шаге он запускает множество рабочих, которые имеют право на ошибку без серьезного влияния на конечный результат. При этом он получает информацию обо всех технических сбоях, что предоставляет ему обратную связь и позволяет адаптироваться и искать обходные пути.\nДебаггинг выигрывает от новых подходов. В этом пункте пост становится до обидного лаконичным, хотя именно эта информация необходима для построения надежных агентных систем. Anthropic упоминают логирование шаблонов принятия решений и структур взаимодействия, но не вдаются при этом в детали. Однако, вероятнее всего у них выстроена довольно серьезная система для observability:\nЛогируется вся метаинформация (spans) о запуске рабочих, инструментов, им предоставленных, общем ходе выполнения и статусе завершения. Структуры взаимодействия оркестратора и рабочих позволяют определять шаблоны принятия решений. К примеру, в 70% случаев система может перезапустить рабочего, а в 30% \u0026mdash; просто продолжить работу по плану. Статистическая обработка трейсов тысяч вызовов позволяет определить и усилить слабые точки агента, не раскрывая самих пользовательских данных. Было бы интересно прочитать их инженерную статью именно по этой теме. Тем не менее вполне ясно, что обычным логированием не обойтись, и с самого начала проектов такого класса нужно закладывать системы вроде Langfuse или OpenTelemetry.\nПодводя итоги Скажу прямо \u0026mdash; хочется сказать огромное спасибо команде Anthropic за такой подробный и практический пост. В то время, когда детали реализации AI проектов стали коммерческой тайной, хранимой за семью печатями, он выглядит как артефакт из иной эпохи, когда ценились инженерская смекалка и элегантные решения, а знания были достоянием общественности. Кто знает, возможно мы туда еще вернемся.\nА между тем \u0026mdash; читайте оригинальный пост, подписывайтесь на их инженерный блог, и творите. И все будет.\nОбзор которого можно прочитать в раз и два.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nМне порой приходит в голову мысль, что будущее программирования за Haskell, с его парадигмой \u0026ldquo;Если программа скомпилировалась — она, скорее всего, работает\u0026rdquo;.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nЗдесь я не буду слишком формализировать и приводить к структуре, подобной той, что описана в книге Gang of Four.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nЧитается как \u0026ldquo;a dork\u0026rdquo;, что абсолютно никак не связано с характером оркестратора.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLarge Language Models и Large Multimodal Models соответственно.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://meshrefine.com/ru/posts/claude_deep_research_lessons/","summary":"\u003cp\u003eОбычно я стараюсь подходить ко всяким новым блестящим штучкам с определенной долей скептицизма. Именно таким, до недавнего времени, было мое отношение к мультиагентным системам. Я бы сказал, что это неудивительно, так как вокруг них сейчас очень много шума, а по-настоящему успешных примеров такого подхода я не видел. Большинство реализаций, которые действительно работали, относились к одному из следующих видов:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eАгентные системы, действующие по определенному плану\u003c/strong\u003e. То есть LLM с инструментами, натасканные на автоматизацию вполне конкретного процесса. Благодаря этому, каждый шаг можно тестировать по отдельности и верифицировать его результаты. Описываются такие системы, как правило, в виде направленного ациклического графа (DAG), иногда динамического, и разрабатываются с помощью уже стандартных примитивов из фреймворков типа LangChain и Griptape\u003csup id=\"fnref:1\"\u003e\u003ca href=\"#fn:1\" class=\"footnote-ref\" role=\"doc-noteref\"\u003e1\u003c/a\u003e\u003c/sup\u003e. Так функционировала ранняя реализация Gemini Deep Research, в которой сначала составлялся план поиска, затем выполнялся сам поиск, и в конце собирался результат.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eРешения, работающие в системах с обратной связью\u003c/strong\u003e. Различные Claude Code, Cursor и прочие агенты, имеющие дело с кодом. Причем чем сильнее обратная связь, читай, чем лучше тулинг и строже проверка типов, тем больше шансов, что они окончательно не испортят вам кодовую базу\u003csup id=\"fnref:2\"\u003e\u003ca href=\"#fn:2\" class=\"footnote-ref\" role=\"doc-noteref\"\u003e2\u003c/a\u003e\u003c/sup\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eМодели, обученные с помощью Reinforcement Learning\u003c/strong\u003e, такие как модели с \u003ca href=\"https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking#interleaved-thinking\"\u003einterleaved thinking\u003c/a\u003e, вроде OpenAI o3. Это отдельный разговор, и очень интересный, но даже такие модели имеют какой-то modus operandi, определенный особенностями их обучения.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eПри этом мультиагентные системы открытого типа ввиду их общей ненадежности до сих пор существовали в большей части в виде proof of concept. В сообществе не было понимания, где их применять и как именно их реализовывать. Пока не появилась \u003ca href=\"https://www.anthropic.com/engineering/built-multi-agent-research-system\"\u003eглубокая инженерная статья от Anthropic о том, как они разрабатывали свой Deep Research\u003c/a\u003e. В ней был определен достаточно четкий фреймворк для построения таких систем, и именно его мы сегодня и рассмотрим.\u003c/p\u003e","title":"Claude Deep Research, или как я перестал беспокоиться и полюбил мультиагентные системы"},{"content":" Радиология с энтузиазмом приняла ИИ, и тем не менее занятость в ней продолжает расти. Эффект «дополнение вместо автоматизации» наблюдается при том, что, насколько я могу судить, не найдено ни одной конкретной «задачи», в которой радиологи-люди превосходили бы ИИ. Так что, возможно, модель «работа — это набор задач» из экономики труда неполна. [\u0026hellip;]\nМожете ли вы разложить собственную работу на набор чётко определённых задач так, чтобы автоматизация каждой из них означала автоматизацию всей вашей работы целиком? Подозреваю, большинство ответит «нет». Но когда мы думаем о чужой работе, которую понимаем хуже своей, модель задач кажется правдоподобной, потому что мы не замечаем всех нюансов.\n— Арвинд Нараянан\nТем не менее мой взгляд на это такой: полностью работы автоматизированы не будут, но один специалист сможет выполнять больше, так что всё сводится к классической проблеме спроса и предложения. Думаю, в большинстве областей спрос по-прежнему будет превышать предложение, хотя и не во всех. См. парадокс Джевонса.\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-20-43c9afb5/","summary":"\u003cblockquote\u003e\n\u003cp\u003eРадиология с энтузиазмом приняла ИИ, и тем не менее занятость в ней продолжает расти. Эффект «дополнение вместо автоматизации» наблюдается при том, что, насколько я могу судить, не найдено ни одной конкретной «задачи», в которой радиологи-люди превосходили бы ИИ. Так что, возможно, модель «работа — это набор задач» из экономики труда неполна. [\u0026hellip;]\u003c/p\u003e\n\u003cp\u003eМожете ли вы разложить собственную работу на набор чётко определённых задач так, чтобы автоматизация каждой из них означала автоматизацию всей вашей работы целиком? Подозреваю, большинство ответит «нет». Но когда мы думаем о \u003cem\u003eчужой работе\u003c/em\u003e, которую понимаем хуже своей, модель задач кажется правдоподобной, потому что мы не замечаем всех нюансов.\u003c/p\u003e","title":"2025-06-20"},{"content":"Cato CTRL™ Threat Research: PoC-атака на Model Context Protocol (MCP) от Atlassian открывает новый класс рисков «Living off AI»\nОчередная уязвимость MCP-сервера, на этот раз у Atlassian. Она позволяет провести prompt injection через внешние тикеты поддержки, давая атакующему возможность выкрадывать данные и устраивать хаос во внутренней системе.\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-20-atlassian-mcp-vulnerability/","summary":"\u003cp\u003e\u003ca href=\"https://www.catonetworks.com/blog/cato-ctrl-poc-attack-targeting-atlassians-mcp/\"\u003eCato CTRL™ Threat Research: PoC-атака на Model Context Protocol (MCP) от Atlassian открывает новый класс рисков «Living off AI»\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eОчередная уязвимость MCP-сервера, на этот раз у Atlassian. Она позволяет провести prompt injection через внешние тикеты поддержки, давая атакующему возможность выкрадывать данные и устраивать хаос во внутренней системе.\u003c/p\u003e","title":"2025-06-20"},{"content":"Model Context Protocol, несмотря на агрессивное его внедрение (а возможно, и благодаря), продолжает развиваться. Недавно Anthropic обновил спецификацию MCP, и ниже мы рассмотрим основные изменения.\nУсиление безопасности MCP-сервер теперь всегда классифицируется как OAuth Resource Server, а клиенты обязаны реализовывать Resource Indicators (RFC 8707). Нужно это для защиты от атак типа Confused Deputy. Раньше токены, запрашиваемые клиентом у сервера авторизации были \u0026ldquo;обезличены\u0026rdquo;, то есть могли использоваться кем угодно. Это дает возможность злоумышленнику создать фишинговый MCP-сервер, обмануть клиента, украсть токен, и с помощью этого токена получить доступ к настоящему MCP-серверу.\nsequenceDiagram participant Клиент participant Сервер Авторизации (АС) participant Вредоносный MCP-сервер participant Legit as Легитимный MCP-сервер Клиент-\u0026gt;\u0026gt;Сервер Авторизации (АС): Запрос на авторизацию для доступа к календарю note right of Клиент: Клиент думает, что будет общаться с calendar-mcp.com Сервер Авторизации (АС)--\u0026gt;\u0026gt;Клиент: Выдает токен доступа (без указания получателя) note left of Вредоносный MCP-сервер: Токен дает право `calendar:read` Клиент-\u0026gt;\u0026gt;Вредоносный MCP-сервер: Соединяется (его обманули фишингом) и отправляет токен note right of Клиент: Ошибка! Клиент — \u0026#34;запутавшийся заместитель\u0026#34; Вредоносный MCP-сервер-\u0026gt;\u0026gt;Legit: Использует украденный обезличенный токен Legit--\u0026gt;\u0026gt;Вредоносный MCP-сервер: Отдает данные (т.к. токен валиден) note over Вредоносный MCP-сервер, Legit: **УСПЕХ АТАКИ** В новой реализации эту штуку закрыли. Клиент при запросе токена теперь обязан указать точный resource (адрес MCP-сервера). В ответ Сервер Авторизации вшивает этот адрес в поле aud (аудитория) самого токена. Благодаря этому MCP-сервер может убедиться, что токен предназначен именно для него, делая бесполезным токен, полученный для другого ресурса.\nsequenceDiagram participant Клиент participant Сервер Авторизации (АС) participant Zlo as Вредоносный MCP-сервер participant Legit as Легитимный MCP-сервер Клиент-\u0026gt;\u0026gt;Сервер Авторизации (АС): Запрос токена с параметром:\u0026lt;br/\u0026gt;`resource=https://evil-mcp.com` note right of Клиент: Клиента обманули, он думает, что\u0026lt;br/\u0026gt;evil-mcp.com - это легитимный сервис. Сервер Авторизации (АС)--\u0026gt;\u0026gt;Клиент: Выдает токен с полем:\u0026lt;br/\u0026gt;`\u0026#34;aud\u0026#34;: \u0026#34;https://evil-mcp.com\u0026#34;` note left of Legit: Токен теперь \u0026#34;именной\u0026#34;, но для злоумышленника. Клиент-\u0026gt;\u0026gt;Zlo: Отправляет токен на evil-mcp.com Zlo-\u0026gt;\u0026gt;Legit: Пытается использовать этот токен для доступа к настоящему календарю. Legit--\u0026gt;\u0026gt;Legit: Проверка токена: смотрю поле `aud`.\u0026lt;br\u0026gt;В нем `\u0026#34;https://evil-mcp.com\u0026#34;`.\u0026lt;br\u0026gt;А мой адрес `\u0026#34;https://calendar-mcp.com\u0026#34;`.\u0026lt;br\u0026gt;Аудитория не совпадает! Legit--\u0026gt;\u0026gt;Zlo: **ОТКАЗ В ДОСТУПЕ (401/403)** note over Legit, Zlo: **АТАКА ПРОВАЛЕНА** Помимо этого, добавлена страничка с security best practices. Она затрагивает практики, применимые на уровне самого протокола, но не на уровне атак на LLM, возможность которых создает его применение. Эти уязвимости описаны на главной странице спецификации, но о том, чтобы обеспечить их митигацию, обязана позаботиться сторона, реализующая хост (приложение, использующее MCP).\nУдаление JSON-RPC batching Удален JSON-RPC batching, ранее позволявший клиенту выполнить несколько действий, отправив их на сервер скопом. Это упрощает протокол, но приводит к потенциально менее эффективной коммуникации с сервером. Теперь, если разработчикам нужна похожая функциональность, ее можно реализовать путем модификации самого MCP-сервера, предоставив batch-инструмент, принимающий в качестве параметров набор вызовов других инструментов.\nКак альтернативу для повышения эффективности коммуникации, инженеры могут применять HTTP/2 Multiplexing и параллельные асинхронные запросы к серверу.\nПоддержка структурированного вывода Добавлена поддержка структурированного вывода. Теперь сервер может возвращать не только текст, но и данные в JSON-формате в соответствии с заданной схемой в поле structuredContent. Это не только упрощает разработку клиентов, но и делает коммуникацию более надежной и предсказуемой. Тем не менее, клиенту также рекомендуется валидировать результат.\nДля сохранения обратной совместимости создатели протокола рекомендуют серверу возвращать те же данные еще и в текстовом виде.\nМеханизм Elicitation Добавлен механизм Elicitation, позволяющий серверу уточнить у пользователя информацию, необходимую для выполнения задачи. Это дает возможность серверу собирать необходимые данные динамически.\nЯ вижу здесь несколько применений, например:\nУпрощение взаимодействия с пользователем. Раньше для вызова инструмента, которому было необходимо собрать большой массив информации, требовалось запрашивать ее у пользователя одномоментно в виде огромной формы. Это сложно было назвать хорошим UI. С помощью Elicitation можно опрашивать пользователя пошагово с промежуточной валидацией. Реализация \u0026ldquo;ветвящихся\u0026rdquo; потоков обработки, где для разных веток нужны разные данные. Разрешение неоднозначности, к примеру, если пользователь просит написать письмо Джону, сервер может уточнить, какому именно. Подтверждение опасных действий. Хотя вызовы инструментов и требуется подтверждать, многие хосты предоставляют пользователю возможность нажать кнопку Allow all. В любом случае, приложения, использующие MCP, часто подвержены проблеме Confirmation Fatigue, когда оператору приходит такое количество подтверждений, что он одобряет их неглядя. Реализация Elicitation через отдельный интерфейс может дать понять пользователю, что на это подтверждение действительно стоит обратить внимание. Прочие изменения и нововведения Сервер теперь может возвращать ссылки на ресурсы. Хотя раньше можно было вернуть ссылку внутри текста или JSON, реализация формата и семантики в разных MCP-серверах могла отличаться, делая разработку MCP-клиентов и хостов значительно сложнее. Теперь такие ссылки могут возвращаться и обрабатываться унифицировано. Теперь в HTTP-запросах должна передаваться версия протокола, и обе стороны (клиент и сервер) должны проверять версию протокола и задействовать только доступные возможности. Это особенно актуально в свете агрессивного внедрения этой технологии и зоопарка серверов, клиентов и хостов. Заключение Приятно видеть, что спецификация продолжает развиваться и авторы не боятся ее активно менять. Актуальные проблемы, с которыми сталкиваются пользователи и разработчики, решаются, избыточная сложность выжигается каленым железом. Это позволяет надеяться, что спустя несколько итераций мы придем к стройному и пуленепробиваемому стандарту.\nНо кроме улучшения спецификации, нас ждет долгий и ухабистый путь по выработке лучших практик построения приложений с использованием MCP, поскольку он открывает как новые возможности, так и новые проблемы. А с учетом того, что сейчас он расхватывается всеми AI-приложениями как горячие пирожки, порой без должного осмысления, эти проблемы могут иметь поистине глобальный характер.\nВпрочем, поживем — увидим.\n","permalink":"https://meshrefine.com/ru/posts/mcp_update_18_06_2025/","summary":"\u003cp\u003eModel Context Protocol, несмотря на агрессивное его внедрение (а возможно, и благодаря), продолжает развиваться. Недавно \u003ca href=\"https://modelcontextprotocol.io/specification/2025-06-18/changelog\"\u003eAnthropic обновил спецификацию MCP\u003c/a\u003e, и ниже мы рассмотрим основные изменения.\u003c/p\u003e\n\u003ch2 id=\"усиление-безопасности\"\u003eУсиление безопасности\u003c/h2\u003e\n\u003cp\u003eMCP-сервер теперь всегда классифицируется как \u003ccode\u003eOAuth Resource Server\u003c/code\u003e, а клиенты обязаны реализовывать \u003ca href=\"https://www.rfc-editor.org/rfc/rfc8707.html\"\u003eResource Indicators (RFC 8707)\u003c/a\u003e. Нужно это для защиты от атак типа \u003ca href=\"https://en.wikipedia.org/wiki/Confused_deputy_problem\"\u003eConfused Deputy\u003c/a\u003e. Раньше токены, запрашиваемые клиентом у сервера авторизации были \u0026ldquo;обезличены\u0026rdquo;, то есть могли использоваться кем угодно. Это дает возможность злоумышленнику создать фишинговый MCP-сервер, обмануть клиента, украсть токен, и с помощью этого токена получить  доступ к настоящему MCP-серверу.\u003c/p\u003e","title":"Июньское обновление MCP: Безопаснее, умнее, проще?"},{"content":"Режим агента с поддержкой MCP-инструментов теперь общедоступен в Visual Studio\nGitHub Copilot довёл поддержку Model Context Protocol в режиме агента до общей доступности. Привычные проблемы безопасности MCP усугубляются опцией «Always allow» при использовании инструментов.\n","permalink":"https://meshrefine.com/ru/microposts/github_mcp_support/","summary":"\u003cp\u003e\u003ca href=\"https://github.blog/changelog/2025-06-17-visual-studio-17-14-june-release/\"\u003eРежим агента с поддержкой MCP-инструментов теперь общедоступен в Visual Studio\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eGitHub Copilot довёл поддержку Model Context Protocol в режиме агента до общей доступности. \u003ca href=\"https://techcommunity.microsoft.com/blog/microsoft-security-blog/understanding-and-mitigating-security-risks-in-mcp-implementations/4404667\"\u003eПривычные проблемы безопасности MCP\u003c/a\u003e усугубляются опцией «Always allow» при использовании инструментов.\u003c/p\u003e","title":"2025-06-18"},{"content":"Обновление потребительского биллинга GitHub Copilot\nБезлимитному доступу к лучшим моделям всех ведущих провайдеров в GitHub Copilot Chat пришёл конец. Теперь безлимитны только GPT-4o и GPT-4.1.\nЭто ещё один шаг к глобальному пересмотру ценовых стратегий для продуктов на базе ИИ. Фаза агрессивного продвижения закончилась. ИИ становится ещё одной разновидностью коммунальной услуги, и стоит ожидать соответствующих стратегий.\n","permalink":"https://meshrefine.com/ru/microposts/github_copilot_premium_requests/","summary":"\u003cp\u003e\u003ca href=\"https://github.blog/changelog/2025-06-18-update-to-github-copilot-consumptive-billing-experience/\"\u003eОбновление потребительского биллинга GitHub Copilot\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eБезлимитному доступу к лучшим моделям всех ведущих провайдеров в GitHub Copilot Chat пришёл конец. Теперь безлимитны только GPT-4o и GPT-4.1.\u003c/p\u003e\n\u003cp\u003eЭто ещё один шаг к глобальному пересмотру ценовых стратегий для продуктов на базе ИИ. Фаза агрессивного продвижения закончилась. ИИ становится ещё одной разновидностью коммунальной услуги, и стоит ожидать соответствующих стратегий.\u003c/p\u003e","title":"2025-06-18"},{"content":"https://eugeneyan.com/writing/writing-faq/\nЭтот FAQ о ведении блога местами перекликается с моей собственной мотивацией\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-18-8218e0a2/","summary":"\u003cp\u003e\u003ca href=\"https://eugeneyan.com/writing/writing-faq/\"\u003ehttps://eugeneyan.com/writing/writing-faq/\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eЭтот FAQ о ведении блога местами перекликается с моей собственной мотивацией\u003c/p\u003e","title":"2025-06-18"},{"content":"ИИ делает гуманитарные науки важнее, но и заметно страннее\nИИ в образовании — палка о двух концах. Он помогает студентам списывать на традиционных заданиях, но одновременно служит мощным новым инструментом, способным по-настоящему их увлечь. Образованию придётся измениться, и я верю, что в итоге оно изменится к лучшему.\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-18-4d1e560d/","summary":"\u003cp\u003e\u003ca href=\"https://resobscura.substack.com/p/ai-makes-the-humanities-more-important\"\u003eИИ делает гуманитарные науки важнее, но и заметно страннее\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eИИ в образовании — палка о двух концах. Он помогает студентам списывать на традиционных заданиях, но одновременно служит мощным новым инструментом, способным по-настоящему их увлечь. Образованию придётся измениться, и я верю, что в итоге оно изменится к лучшему.\u003c/p\u003e","title":"2025-06-18"},{"content":"Академики обманывают себя насчёт ИИ\nЕсли хотите покритиковать ИИ — делайте это как следует :)\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-18-424531d9/","summary":"\u003cp\u003e\u003ca href=\"https://www.learningfromexamples.com/p/what-academics-get-wrong\"\u003eАкадемики обманывают себя насчёт ИИ\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eЕсли хотите покритиковать ИИ — делайте это как следует :)\u003c/p\u003e","title":"2025-06-18"},{"content":"Как мы построили нашу мультиагентную исследовательскую систему\nОтличный свежий материал от Anthropic о том, как они строили свой инструмент Deep Research. Много практических советов.\n","permalink":"https://meshrefine.com/ru/microposts/2025-06-16-df4a051d/","summary":"\u003cp\u003e\u003ca href=\"https://www.anthropic.com/engineering/built-multi-agent-research-system\"\u003eКак мы построили нашу мультиагентную исследовательскую систему\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eОтличный свежий материал от Anthropic о том, как они строили свой инструмент Deep Research. Много практических советов.\u003c/p\u003e","title":"2025-06-16"},{"content":"GitHub Copilot может использовать заданный пользователем промпт для генерации сообщений коммитов. Чтобы включить это, сконфигурируйте github.copilot.chat.commitMessageGeneration.instructions в файле settings.json следующим образом:\n{ \u0026#34;github.copilot.chat.commitMessageGeneration.instructions\u0026#34;: [ {\u0026#34;text\u0026#34;: \u0026#34;Write a concise commit message starting with a change tag\u0026#34;}, ] } Либо можно использовать файл-шаблон. Для этого создайте файл, например commit-message-template.md, и подключите его:\n{ \u0026#34;github.copilot.chat.commitMessageGeneration.instructions\u0026#34;: [ {\u0026#34;file\u0026#34;: \u0026#34;commit-message-template.md\u0026#34;} ] } ","permalink":"https://meshrefine.com/ru/microposts/gilhub_copilot_commit_message_template/","summary":"\u003cp\u003eGitHub Copilot может использовать заданный пользователем промпт для генерации сообщений коммитов. Чтобы включить это, сконфигурируйте \u003ccode\u003egithub.copilot.chat.commitMessageGeneration.instructions\u003c/code\u003e в файле \u003ccode\u003esettings.json\u003c/code\u003e следующим образом:\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-json\" data-lang=\"json\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e  \u003cspan class=\"nt\"\u003e\u0026#34;github.copilot.chat.commitMessageGeneration.instructions\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e \u003cspan class=\"p\"\u003e[\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e    \u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"nt\"\u003e\u0026#34;text\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e \u003cspan class=\"s2\"\u003e\u0026#34;Write a concise commit message starting with a change tag\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e},\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e  \u003cspan class=\"p\"\u003e]\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eЛибо можно использовать файл-шаблон. Для этого создайте файл, например \u003ccode\u003ecommit-message-template.md\u003c/code\u003e, и подключите его:\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-json\" data-lang=\"json\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e  \u003cspan class=\"nt\"\u003e\u0026#34;github.copilot.chat.commitMessageGeneration.instructions\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e \u003cspan class=\"p\"\u003e[\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e    \u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"nt\"\u003e\u0026#34;file\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e \u003cspan class=\"s2\"\u003e\u0026#34;commit-message-template.md\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e  \u003cspan class=\"p\"\u003e]\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e","title":"2025-06-16"},{"content":"В то время, когда слова AI и хайп практически стали синонимами, очень важно грамотно подходить к выбору источников информации. Вокруг сейчас слишком много информационного шума, и отобрать что-то действительно стоящее из моря статей различных AI-евангелистов и сгенерированного мусора невероятно сложно.\nВ этом посте я расскажу, какие материалы читаю я, чтобы быть в курсе последних событий.\nБлоги Хороший блог — это слиток золота. Отношение сигнал/шум в нем стремится к бесконечности. Именно поэтому начну со списка блогов, которые я считаю полезными.\nSimon Willison\u0026rsquo;s Weblog Если бы меня заставили отказаться от всех блогов, кроме одного, я бы оставил этот. Саймон Виллисон, один из создателей веб-фреймворка Django, представляет собой эталон технического блогера, фокусирующегося на LLM и других технологиях, связанных с AI. И это неспроста — он постоянно добавляет в свою утилиту llm все свежие наработки и возможности как от API облачных провайдеров, так и от локальных библиотек для инференса, таких как Ollama. В его блоге ежедневно появляются обзоры новых моделей 1, советы для разработчиков, использующих AI в своей работе, ссылки на интересные новости с других блогов и многое другое.\nКроме ИИ, Саймон освещает новости из мира Python, JS и Web-технологий.\nThe Batch The Batch — это еженедельная рассылка, курируемая Andrew Ng, создателем наиболее популярных и доступных курсов по машинному обучению, глубокому обучению и Generative AI. Помимо колонки автора, письма содержат анализ наиболее важных новостей из мира искусственного интеллекта за последнюю неделю.\nВ дополнение к рассылке, на The Batch публикуются заметки о применении AI в бизнесе, о последних научных публикациях, а также о влиянии AI на общество.\nAhead of AI и The Sequence Если хочется углубиться в bleeding edge и state of the art, то лучшего места, чем блог Себастьяна Рашки, найти сложно. Автор, доктор наук, находящийся между индустрией и академией, регулярно разбирает наиболее важные публикации и концепты, и доносит их до публики достаточно простым языком, доступным любому, понимающему алгоритмы и код.\nОчевидно, что блог такого качества не может обновляться часто, а новые научные статьи выходят ежедневно. Желающим получать более регулярные апдейты относительно последних исследований можно обратить внимание на The Sequence. Их The Sequence Radar содержит краткие обзоры самых интересных публикаций. Остальная часть их материалов, доступная только по подписке, содержит более подробные разборы статей и аналитику.\nOne Useful Thing One Useful Thing — это взгляд на AI из академических кругов, но под другим углом. Доктора Итана Моллика, как профессора менеджмента в Уортонской школе бизнеса, прежде всего интересует, как современный AI влияет на процессы в образовании, бизнесе, медицине и других областях. Его главный посыл — что бы вы ни делали, приглашайте AI за стол. Это позволит определить контуры Jagged Frontier 2 в задачах, которые важны именно вам.\nКроме спорадически обновляющегося блога, доктор Моллик написал книгу Co-Intelligence: Living and Working with AI, которая, хотя и немного устарела в стремительно меняющемся мире ИИ, все еще актуальна, поскольку затрагивает вневременные вопросы о взаимодействии человека и AI в рабочей среде.\nОтдельно рекомендую подписаться на него на x.com, его посты в этой сети представляют собой смесь забавных экспериментов с последними моделями, кратких обзоров публикаций, связанных с его сферой интересов, и общих размышлений о прогрессе.\nImport AI Еще одна еженедельная рассылка, на этот раз от Джека Кларка, сооснователя компании Anthropic и бывшего директора по политике в OpenAI. Как следует ожидать от человека с таким бэкграундом, его письма в первую очередь сосредоточены вокруг AI Safety, этики и регулирования, хотя имеются и технические заметки.\nВ конце каждого письма можно найти хорошо написанный научно-фантастический очерк, часто перекликающийся с общей темой рассмотренных новостей. Порой мне даже жаль, что он не пишет книги на профессиональной основе.\nAI Snake Oil А теперь кое-что совершенно иное. Профессора Арвинда Нараянана и его соавтора, аспиранта Сайаша Капура, многие сегодня назвали бы AI-скептиками. Однако, их подход значительно глубже, чем у рядового отрицателя. Авторы рассматривают AI через призму классической технологии, и поднимают вопросы о ее применении и регуляции именно с этой точки зрения. Они подчеркивают, что подходы, которые применяются в предположении об искусственном интеллекте как боге из машины, могут оказаться вредны в случае, если это на самом деле обычная, хотя и очень мощная, технология общего назначения. При этом они принимают и подтверждают практическую пользу, которую несет AI уже сейчас. Их материалы — это этакая красная таблетка в мире хайпа и завышенных ожиданий.\nDeep Research Кроме упомянутых выше блогов, которые я читаю через старый добрый RSS и, в случае материалов с SubStack, через почтовую рассылку, я ежедневно генерирую себе персональный дайджест, используя Gemini 2.5 Pro с Deep Research. Можно использовать аналогичные инструменты от конкурентов, но, на мой взгляд, именно Gemini дает наилучшее соотношение широты обхвата и глубины анализа.\nЧтение такого дайджеста позволяет мне с утра пройтись по наиболее важным новостям прошедшего дня в случае, если они еще не были обсуждены в одном из блогов. Если времени на чтение нет, то создаю подкаст с помощью NotebookLM3 и слушаю его по дороге в офис.\nПо ссылке можно найти используемый мной промпт и пример сгенерированного дайджеста за 14 июня 2025 г.\nКуда я не смотрю Здесь я просто приведу список источников, которые я сознательно игнорирую. По моему мнению, жизнь слишком коротка, чтобы тратить на них время:\nAI-инфлюенсеры в LinkedIn и прочих социальных сетях. Как правило, это абсолютный, белый до слепоты шум. e/acc и AI-думеры. Философские споры могут быть интересными, но я предпочитаю более прагматичный подход. Обзоры на YouTube. Стоит посмотреть, чтобы научиться искусству растягивания пятиминутного материала на час. Немного о FOMO (боязни пропустить что-то интересное) И напоследок, совет для тех, кто постоянно мониторит все возможные источники из боязни пропустить что-то важное: расслабьтесь. Я в свое время списал появление ChatGPT на очередной маркетинговый трюк. Было обидно, но ничего страшного не произошло.\nЕсли появится что-то действительно важное, то источники, указанные выше, позволят вам не только узнать об этом, но и понять как оно устроено, как это применять, и как это повлияет на нашу жизнь. А остальное не стоит беспокойства.\nС обязательными пеликанами на велосипедах.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nНеровный рубеж. Фраза означает, что AI может блистать в одних задачах и одновременно ужасающе проседать в других, при этом в каких именно — невозможно определить логически, только эмпирически.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nОн сейчас удобно интегрирован прямо в интерфейс Gemini.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://meshrefine.com/ru/posts/blogs/","summary":"\u003cp\u003eВ то время, когда слова AI и хайп практически стали синонимами, очень важно грамотно подходить к выбору источников информации. Вокруг сейчас слишком много информационного шума, и отобрать что-то действительно стоящее из моря статей различных AI-евангелистов и сгенерированного мусора невероятно сложно.\u003c/p\u003e\n\u003cp\u003eВ этом посте я расскажу, какие материалы читаю я, чтобы быть в курсе последних событий.\u003c/p\u003e\n\u003ch2 id=\"блоги\"\u003eБлоги\u003c/h2\u003e\n\u003cp\u003eХороший блог — это слиток золота. Отношение сигнал/шум в нем стремится к бесконечности. Именно поэтому начну со списка блогов, которые я считаю полезными.\u003c/p\u003e","title":"Блоги, в которые пишут люди"},{"content":"Лето. Пришла пора куда-то выбраться в отпуск. Открываем ChatGPT, выбираем активно набирающий популярность GPT \u0026ldquo;Travel Advisor\u0026rdquo;, обсуждаем варианты. Советник дает отличные советы и очень интересно рассказывает про местные достопримечательности, генерирует весьма неплохие планы, и в целом оставляет хорошее впечатление. Местами, конечно, проскакивают странности, но мы их пропускаем как безобидные галлюцинации. Отлично, останавливаемся на Барселоне. В том же чате переключаемся на другой, не менее знакомый и популярный GPT \u0026ldquo;Booking Agent\u0026rdquo;, который нас никогда не подводил, и бронируем жилье.\nПо прилете мы обнаруживаем, что агент забронировал комнату в пригороде за довольно высокую цену. Разумеется, мы списываем все на вопиющую ошибку Booking Agent и общую ненадежность AI. Однако, возможно, что все немного сложнее, и в этой ситуации замешан нечистый на руку владелец жилья.\nПример чата с Travel Advisor и Booking Agent\nКак он смог это провернуть, и какие еще опасности таит в себе использование нескольких GPT в одном чате? Об этом мы поговорим в этом посте.\nВведение Немного предыстории. По служебной необходимости пришлось мне поразмыслить над безопасностью набирающего популярность протокола MCP (Model Context Protocol) от Anthropic. Он был создан с целью унифицировать доступ модели к различным инструментам, позволяя так называемым MCP-серверам предоставлять модели саму функциональность и описание того, как ей пользоваться. По замыслу создателей, эти сервера можно подключить в любом приложении, использующим AI, и расширять его возможности на лету.\nОднако безопасность этого протокола была отодвинута на второй план, из-за чего он подвержен множеству уязвимостей. Одна из наиболее неприятных — Tool Poisoning, являющаяся разновидностью более общего класса атак Context Poisoning. Суть этой уязвимости в том, что инструкции для всех MCP попадают в единый промпт для модели, и если среди используемых серверов окажется зловредный, он может \u0026ldquo;отравить\u0026rdquo; этот общий промпт, изменив поведение модели на желаемое для злоумышленника.\nДо появления MCP различные вендоры предоставляли похожие проприетарные инструменты. Один из них, GPT от OpenAI, позволяет пользователям создавать специализированных помощников, которые обладают собственными инструкциями, имеют доступ к интернету и могут иметь доступ к внешним API. OpenAI также выпустили магазин этих GPT и позволили пользователям делиться ими друг с другом, что открыло широкий канал для распространения зловредов.\nИзначально использовать несколько GPT в одном чате было нельзя, что исключало возможность использования описываемой уязвимости 1. Спустя какое-то время, впрочем, эту функциональность добавили. В свете этого, тем, кто ее использует со сторонними помощниками важно понимать возможные последствия.\nЭксплуатация Прежде всего, важно отметить, что переключение GPT в одном чате не может напрямую привести к Tool Poisoning. При переключении GPT все инструкции от предыдущих удаляются из контекста, так что промпт одного GPT не может непосредственно влиять на другие. Ключевое слово здесь — непосредственно. Дело в том, что остается еще один неустранимый канал коммуникации — сам чат.\nРазумеется, любые грубые попытки манипулировать этим каналом будут тут же замечены пользователем, поэтому манипуляции должны быть достаточно невинными и незаметными. Впрочем, люди — существа несовершенные, и существует множество способов влиять незаметно. Для этого достаточно вспомнить несколько особенностей взаимодействия человека и AI:\nАсимметрия внимания. Человек в основном оперирует недавним контекстом. Все, что выходит за рамки последних нескольких итераций чата, фактически перестает для него существовать. Внимание LLM, с другой стороны, охватывает весь контекст, доступный ей. Таким образом, кажущаяся незначительной фраза, брошенная в начале беседы, будет оказывать влияние на весь диалог, несмотря на то, что пользователь про нее уже забыл. Парадокс доверия. Пользователь ожидает, что модель может ошибаться. Одновременно, особенность человеческого разума заключается в том, что человек подсознательно верит в любую информацию, представленную уверенным и авторитетным тоном. Таким образом, пользователь может списать мелкую неточность на особенности AI, и при этом доверить тому же самому AI выполнить важное действие, если описание и подтверждение этого действия было достаточно убедительным. Эффект одного собеседника. Хотя пользователь явным образом переключает чат между различными GPT, он неявным образом переносит свое доверие с одного на другой в пределах одного диалога. Иными словами, он склонен доверять всем GPT одинаково. Оперируя этими фактами, злоумышленник может спроектировать и воплотить достаточно большое количество различных атак. Среди них я бы выделил две:\nКража информации (Data Exfiltration). Достаточно классическая ситуация 2. Зловред анализирует чат и, найдя нужную информацию, отправляет ее на удаленный сервер. Для этого ему нужно подтверждение оператора, для этого он маскирует эту операцию под легитимную.\nПример: пользователь использует GPT для траблшутинга проблем с сервером. Он предоставляет логи и прочую приватную информацию. Через некоторое время помощник предлагает сохранить сессию для дальнейшего использования, и в случае согласия пользователя, отправляет эти чувствительные данные на сервер злоумышленника.\nПочему я включил эту уязвимость в категорию взаимодействия разных GPT? Потому что вредоносный GPT может создаваться и распространяться специально, чтобы воровать информацию у какого-то конкретного популярного ассистента. Например: популярный помощник-бухгалтер запрашивает от пользователя специфическую финансовую информацию, которая интересует злоумышленника. Злоумышленник создает зловреда и промотирует его как предоставляющего дополнительную функциональность, которой в помощнике нет, например, проверку документов на соответствие нормам. После появления необходимой информации в чате GPT-зловред отправляет ее на сервер атакующего под видом юридической проверки.\nsequenceDiagram participant U as Пользователь participant G1 as GPT-Бухгалтер participant CTX as Общая история чата participant G2 as Зловредный GPT participant S as Сервер Атакующего U-\u0026gt;\u0026gt;G1: Финансовые \u0026lt;br\u0026gt; документы activate G1 G1-\u0026gt;\u0026gt;CTX: Запись: \u0026lt;br\u0026gt; {приватные_фин_данные} CTX--\u0026gt;\u0026gt;U: Отображение ответа G1 deactivate G1 U-\u0026gt;\u0026gt;G2: Проверь документ activate G2 G2-\u0026gt;\u0026gt;CTX: Запрос всей истории activate CTX CTX--\u0026gt;\u0026gt;G2: История \u0026lt;br\u0026gt; (с приватными данными) deactivate CTX rect rgb(190, 144, 144) G2-\u0026gt;\u0026gt;S: POST /api/check \u0026lt;br\u0026gt; {приватные_фин_данные} activate S S--\u0026gt;\u0026gt;G2: HTTP 200 OK deactivate S end G2--\u0026gt;\u0026gt;U: Проверка прошла успешно! deactivate G2 Отравление контекста (Context Poisoning). Пример этой манипуляции приведен выше.\nЗдесь есть GPT-злоумышленник, созданный таким образом, чтобы подтолкнуть любые другие GPT, используемые в том же чате, к определенным действиям. Кроме уже упомянутого Travel Advisor, примерами могут служить финансовый советчик, ненавязчиво обращающий внимание на медицинский сектор, советник по моде, рекомендующий направление, в котором работает определенный бренд, и другие. В данном случае злоумышленнику не нужно указывать на конкретный бренд или компанию, достаточно сместить чашу весов принятия решения в нужном направлении.\nsequenceDiagram participant U as Пользователь participant G1 as Зловредный GPT-1 participant CTX as Общая история чата participant G2 as Доверчивый GPT-2 U-\u0026gt;\u0026gt;G1: Обсуждение отпуска activate G1 rect rgb(190, 144, 144) G1-\u0026gt;\u0026gt;CTX: Запись: \u0026#34;Советую тихий район X...\u0026#34; end CTX--\u0026gt;\u0026gt;U: Отображение ответа G1 deactivate G1 U-\u0026gt;\u0026gt;G2: Забронируй жилье activate G2 G2-\u0026gt;\u0026gt;CTX: Запрос всей истории activate CTX rect rgb(190, 144, 144) CTX--\u0026gt;\u0026gt;G2: Вся история (с ядом про район X) end deactivate CTX rect rgb(190, 144, 144) G2--\u0026gt;\u0026gt;U: Готово! Забронировал в районе X end deactivate G2 Хотя эти атаки мало похожи друг на друга, все они основаны на трех принципах взаимодействия человека и AI. Эффект одного собеседника, асимметрия внимания и парадокс доверия используются зловредом, чтобы получить доверие пользователя и отравить контекст или, не вызывая подозрения, выполнить нелегитимное действие. К сожалению, психологию человека поменять невозможно, однако, можно построить вокруг нее защиту, соблюдая основные принципы цифровой гигиены, о которых мы поговорим далее.\nГигиена Защита от манипуляций для пользователя GPT-ассистентов должна быть, как и сами манипуляции, многоуровневой.\nСамым эффективным способом защиты от взаимодействия GPT между собой, как бы это парадоксально ни звучало, является полное исключение этого взаимодействия. Иными словами, стоит разделять чаты по задачам и использовать отдельный чат для каждого GPT, перенося необходимый контекст вручную. \u0026ldquo;Необходимый\u0026rdquo; здесь — ключевое слово, поскольку если просто скопировать весь чат целиком, будет скопирован и отравленный контекст. Используйте доверенные GPT. Соблюдение этого правила в реальности довольно проблематично, так как OpenAI не позволяет провалидировать промпты и настройки ассистентов, представленных в их магазине. Огромное же количество GPT в магазине делает эффективную модерацию практически невозможной. Наилучшим выходом будет создание собственных GPT в тех задачах, для которых это возможно. Интерфейс, который предоставляет OpenAI, в большой степени автоматизирован с помощью LLM, что делает их написание простым и доступным для каждого. Если написание своего GPT невозможно, к примеру, в случаях, когда ассистент обращается к приватному API или использует проприетарную базу знаний, обращайте внимание на популярность и возраст ассистента. Это не железобетонный критерий, но все же понижает вероятность наткнуться на зловреда. Выступлю в роли Капитана Очевидность, но всегда и везде отфильтровывайте приватную информацию и проверяйте действия, совершаемые агентом. Это базовое правило, но о нем слишком часто забывают. Заключение По сути, описанные выше проблемы — это лишь частные случаи более общего класса уязвимостей, вызванных неконтролируемой коммуникацией между несколькими неконтролируемыми узлами системы.\nК сожалению, в настоящее время полностью техническими способами решить описанные выше проблемы практически невозможно, однако, определенные изменения моделей инфраструктуры и интерфейса могут достаточно серьезно помешать злоумышленникам:\nПоскольку проверка GPT в магазине требует больших усилий, можно внедрить автоматическую модерацию моделью-классификатором, подобно тому, как обнаруживаются сообщения, нарушающие условия использования. К сожалению, в открытых источниках нет информации о том, используется ли такая модель в магазине в настоящий момент. При переключении GPT в рамках одного чата явно спрашивать пользователя, хочет ли он предоставить доступ к полной истории новому ассистенту, начать новый чат, или, опционально, предоставить доступ к краткому содержанию диалога. Кроме технической защиты, это хороший метод нивелировать эффект одного собеседника. И, что более сложно и ресурсозатратно, размечать сообщения от разных GPT и дотренировать модель таким образом, чтобы она автоматически назначала меньший вес сообщениям от GPT, отличных от текущего. Здесь очень важно сбалансировать эффект так, чтобы модель не стала игнорировать полезную информацию, предоставленную предыдущими ассистентами 3. К счастью, исходя из оценки последних нововведений OpenAI, можно сказать, что они внимательно относятся к освещению потенциальных проблем при использовании их продуктов и ограничивают свои инструменты таким образом, чтобы усложнить эксплуатацию уязвимостей. К примеру, их реализация поддержки MCP ограничивает доступные инструменты исключительно операциями search и fetch. В посте про уязвимости MCP-протокола я планирую рассказать про то, почему они пришли к таким ограничениям. А тем временем, до новых встреч.\nСсылки До тех пор, пока пользователь не копировал сообщения из одного чата в другой\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJiahao Yu et al., \u0026ldquo;Assessing Prompt Injection Risks in 200+ Custom GPTs\u0026rdquo;, arXiv:2311.11538v2, May 2024. https://arxiv.org/abs/2311.11538\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nKeegan Hines et al., \u0026ldquo;Defending Against Indirect Prompt Injection Attacks With Spotlighting\u0026rdquo;, arXiv:2403.14720v1, Mar 2024. https://arxiv.org/abs/2403.14720\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://meshrefine.com/ru/posts/one_gpt_vulnerability/","summary":"\u003cp\u003eЛето. Пришла пора куда-то выбраться в отпуск. Открываем ChatGPT, выбираем активно набирающий популярность GPT \u0026ldquo;Travel Advisor\u0026rdquo;, обсуждаем варианты. Советник дает отличные советы и очень интересно рассказывает про местные достопримечательности, генерирует весьма неплохие планы, и в целом оставляет хорошее впечатление. Местами, конечно, проскакивают странности, но мы их пропускаем как безобидные галлюцинации. Отлично, останавливаемся на Барселоне. В том же чате переключаемся на другой, не менее знакомый и популярный GPT \u0026ldquo;Booking Agent\u0026rdquo;, который нас никогда не подводил, и бронируем жилье.\u003c/p\u003e","title":"Отравленный контекст: скрытая угроза при использовании нескольких GPT"},{"content":"В прошлом посте я провел разбор базовых концептов AI-фреймворка Griptape, и сейчас самое время применить их к делу. Попробуем их использовать для разработки небольшого приложения, которое помогает вести линк-блог в телеграме.\nПриложение будет получать URL, скачивать его, прогонять через LLM для генерации сокращенного содержания, переводить это содержимое еще на несколько языков, собирать все вместе и публиковать в телеграме через бота. Общий флоу можно увидеть на схеме ниже:\nflowchart LR A[\u0026#34;URL\u0026#34;] A --\u0026gt; Parser[\u0026#34;Парсер\u0026#34;] --\u0026gt; LLM1[\u0026#34;Суммаризатор\u0026#34;] LLM1 --\u0026gt; Translator1[\u0026#34;Перевод на язык 1\u0026#34;] LLM1 --\u0026gt; Translator2[\u0026#34;Перевод на язык 2\u0026#34;] Translator1 --\u0026gt; Combiner[\u0026#34;Сборщик\u0026#34;] Translator2 --\u0026gt; Combiner LLM1 --\u0026gt; Combiner Combiner --\u0026gt; Telegram[\u0026#34;Телеграм-бот\u0026#34;] Для простоты картины я опущу имплементацию телеграм-бота, а также оставлю в покое мой любимый Human-in-the-loop, который, по моему мнению, обязательно должен присутствовать как минимум где-то в районе сборщика 1.\nВ процессе мы попробуем разобраться, в каких случаях лучше использовать различные структуры, а также насколько получаемые графы composable и гибкие для изменения.\nНу что ж, приступим.\nСоздаем проект Как упоминалось в предыдущем посте, Griptape — фреймворк для Python, а потому мы используем uv для старта проекта:\n$ uv init . $ uv add \u0026#34;griptape[all]\u0026gt;=1.7.2\u0026#34; python-dotenv Экстра [all] устанавливает все доступные драйверы и загрузчики, что создает окружение размером в ~650МБ. В реальном приложении имеет смысл ограничиться только реально используемыми экстрами, список которых можно посмотреть в pyproject.toml проекта. В целом они разбиты довольно гранулярно, так что в большинстве случаев реальный размер будет значительно меньше.\nМы также подключаем python-dotenv, поскольку драйверы различных LLM-провайдеров используют переменные окружения для управления ключами. В нашем примере мы будем использовать openrouter.ai2, предоставляющий OpenAI-подобное API для просто огромного количества моделей и провайдеров.\nСоответственно, создадим файл .env и положим в него ключ:\nOPENROUTER_API_KEY=sk-or-v1-... Итак, сперва костяк нашего приложения:\n# main.py import argparse import dotenv import os dotenv.load_dotenv() def process_url(url: str): \u0026#34;\u0026#34;\u0026#34;Process the provided URL.\u0026#34;\u0026#34;\u0026#34; key = os.environ.get(\u0026#39;OPENROUTER_API_KEY\u0026#39;, \u0026#39;\u0026#39;) if not key: raise ValueError(\u0026#34;OPENROUTER_API_KEY is not set in the environment variables.\u0026#34;) print(f\u0026#34;Processing URL: {url}\u0026#34;) def main(): parser = argparse.ArgumentParser(description=\u0026#39;Process URLs for link blog\u0026#39;) parser.add_argument(\u0026#39;url\u0026#39;, type=str, help=\u0026#39;URL to process\u0026#39;) args = parser.parse_args() process_url(args.url) if __name__ == \u0026#34;__main__\u0026#34;: main() Проверяем:\n$uv run ./main.py google.com Processing URL: google.com Отлично. Можем описывать граф. Чтение документации ответило на один из моих вопросов, поднятых в прошлой статье вот так:\nGriptape provides three Structures:\n\u0026hellip;\nOf the three, Workflow is generally the most versatile. Agent and Pipeline can be handy in certain scenarios but are less frequently needed if you’re comfortable just orchestrating Tasks directly.\nОтлично, как я и подозревал, остальные примитивы лучше подходят для совсем уж базовых задач, так что просто берем Workflow везде и приступаем к построению наших графов.\nГрузим сайты бочками Начнем мы с загрузки содержимого сайта. Для этого Griptape предоставляет драйвер WebScraper с несколькими различными реализациями и загрузчик WebLoader. Наша задача - обернуть это в Task:\nfrom griptape.structures import Workflow from griptape.tasks import CodeExecutionTask from griptape.loaders import WebLoader def load_page(task: CodeExecutionTask) -\u0026gt; str: \u0026#34;\u0026#34;\u0026#34;Load the content of the given URL.\u0026#34;\u0026#34;\u0026#34; print(f\u0026#34;Loading page: {task.input.value}\u0026#34;) return WebLoader().load(task.input.value) def print_result(task: CodeExecutionTask) -\u0026gt; None: \u0026#34;\u0026#34;\u0026#34;Print the result of the task.\u0026#34;\u0026#34;\u0026#34; for parent in task.parents: if parent.output.value: print(f\u0026#34;Output: {parent.output.value}\u0026#34;) def process_url(url: str): \u0026#34;\u0026#34;\u0026#34;Process the provided URL.\u0026#34;\u0026#34;\u0026#34; key = os.environ.get(\u0026#34;OPENROUTER_API_KEY\u0026#34;, \u0026#34;\u0026#34;) if not key: raise ValueError(\u0026#34;OPENROUTER_API_KEY is not set in the environment variables.\u0026#34;) print(f\u0026#34;Processing URL: {url}\u0026#34;) download_task = CodeExecutionTask( on_run=load_page, input=url, id=\u0026#34;download_task\u0026#34;, child_ids=[\u0026#34;print_task\u0026#34;] ) print_task = CodeExecutionTask(on_run=print_result, id=\u0026#34;print_task\u0026#34;) workflow = Workflow(tasks=[download_task, print_task]) workflow.run() Что мы здесь видим:\nНесколько CodeExecutionTask. Это специальный тип задачи, который позволяет выполнить произвольный код. Такая задача принимает на вход функцию, в которую передается собственно сам объект этой задачи с огромным количеством полей, к которым можно получить доступ. В данном случае мы определили две задачи, одна из которых загружает содержимое сайта, а вторая – печатает содержимое своих задач-родителей. Для определения самой структуры DAG используются параметры child_ids или parent_ids задач. Сам Workflow принимает просто список этих задач.\nWorkflow.run запускает задачи в графе и возвращает Workflow, из которого можно извлечь выполненные задачи и их входы/выходы. Кстати, Workflow можно запускать несколько раз, и при использовании Conversation Memory эта операция будет не идемпотентной.\nЕсли воспользоваться StructureVisualizer, то мы увидим вот такую картинку:\ngraph TD; Download_Task--\u0026gt; Print_Task; Print_Task; Обобщаем Для суммаризации у Griptape есть много готовых примитивов, включая TextSummaryTask. Она принимает на вход Summary Engine, через который можно настроить параметры суммаризации, такие как драйвер модели, шаблоны промтов и некий Chunker, назначение которого мы обсудим чуть позже. Попробуем этой задачей воспользоваться:\nfrom griptape.tasks import TextSummaryTask from griptape.engines import PromptSummaryEngine from griptape.drivers.prompt.openai import OpenAiChatPromptDriver ... def process_url(url: str): ... download_task = CodeExecutionTask( on_run=load_page, input=url, id=\u0026#34;download_task\u0026#34;, child_ids=[\u0026#34;summary_task\u0026#34;] ) prompt_driver=OpenAiChatPromptDriver( model=\u0026#34;google/gemini-2.5-flash-preview-05-20\u0026#34;, base_url=\u0026#34;https://openrouter.ai/api/v1\u0026#34;, api_key=key, ) summary_task = TextSummaryTask( \u0026#34;Please summarize the following content in a concise manner. {{ parents_output_text }}\u0026#34;, summary_engine=PromptSummaryEngine( prompt_driver=prompt_driver ), id=\u0026#34;summary_task\u0026#34;, child_ids=[\u0026#34;print_task\u0026#34;], ) print_task = CodeExecutionTask(on_run=print_result, id=\u0026#34;print_task\u0026#34;) workflow = Workflow(tasks=[download_task, summary_task, print_task]) workflow.run() Этот код дает нам на выходе следующее:\n$ uv run ./main.py https://docs.griptape.ai/stable/griptape-framework/structures/agents/ Output: Griptape Agents are a quick way to start using the platform. They take tools and input directly, which the agent uses to add a Prompt Task. The final output of the Agent can be accessed using the output attribute. An example demonstrates an Agent using a CalculatorTool to compute 13^7, successfully returning the result 62,748,517. Здесь я наткнулся на интересную особенность: чтобы в summary_task на входе появился выход download_task, нужно обязательно указать инструкцию с использованием шаблона {parents_output_text} в качестве input. Хотя внутри суммаризатора уже есть необходимый промпт, сами данные из вывода родительских задач он не извлекает. Об этом приходится заботиться нам самим. В остальном все вроде бы достаточно очевидно.\ngraph TD; Download_Task--\u0026gt; Summary_Task; Summary_Task--\u0026gt; Print_Task; Print_Task Chunker В то время как суммаризация отлично работала на небольших страницах, попытка запустить ее на странице из 55000 слов приводила к зависанию задачи независимо от используемой модели. Явное указание Chunker решило проблему:\nfrom griptape.chunkers import TextChunker ... summary_task = TextSummaryTask( \u0026#34;Please summarize the following content in a concise manner. {{ parents_output_text }}\u0026#34;, summary_engine=PromptSummaryEngine( prompt_driver=prompt_driver, chunker = TextChunker(max_tokens=16000) ), id=\u0026#34;summary_task\u0026#34;, child_ids=[\u0026#34;print_task\u0026#34;, \u0026#34;russian_translate_task\u0026#34;, \u0026#34;polish_translate_task\u0026#34;], ) При этом, судя по логам, чанкинг в суммаризаторе реализован итеративно, и на псевдокоде может быть выражен следующим образом:\nchunks = [chunk1, chunk2, ..., chunkN] summary = summarize(f\u0026#34;Summarize this: {chunk1}\u0026#34;) for chunk in chunks[1:]: summary = summarize(f\u0026#34;Update this summary {summary} with the following additional information: {chunk}\u0026#34;) return summary Такой подход приводит к тому, что информация, расположенная ближе к концу текста, перевешивает ту, что в начале, что допустимо далеко не всегда. Лично я предпочел бы суммаризацию чанков через Map-Reduce:\nchunks = [chunk1, chunk2, ..., chunkN] summaries = [summarize(f\u0026#34;Summarize this: {chunk}\u0026#34;) for chunk in chunks] summary = summarize(f\u0026#34;Summarize these chunk summaries: {\u0026#39;\\n---\\n\u0026#39;.join(summaries)}) return summary При таком подходе все чанки равны между собой, кроме того, это позволит выполнить суммаризацию параллельно, но при этом потребует на один запрос к модели больше.\nВпрочем, здесь раскрывается гибкость фреймворка и движков. Благодаря им, этот алгоритм можно реализовать в своем собственном движке, унаследованном от BaseSummaryEngine и использовать практически бесшовно.\nВместе веселее Следующий шаг – перевести этот текст на несколько языков. Разумеется, задачи эти параллелятся, и наш Workflow предоставляет замечательные инструменты для этого:\nfrom griptape.tasks import PromptTask ... def process_url(url: str): \u0026#34;\u0026#34;\u0026#34;Process the provided URL.\u0026#34;\u0026#34;\u0026#34; ... summary_task = TextSummaryTask( ... id=\u0026#34;summary_task\u0026#34;, child_ids=[\u0026#34;print_task\u0026#34;, \u0026#34;russian_translate_task\u0026#34;, \u0026#34;polish_translate_task\u0026#34;], ) russian_translate_task = PromptTask( \u0026#34;Please translate the following text to Russian: {{ parents_output_text }}\u0026#34;, prompt_driver=prompt_driver, id=\u0026#34;russian_translate_task\u0026#34;, child_ids=[\u0026#34;print_task\u0026#34;], ) polish_translate_task = PromptTask( \u0026#34;Please translate the following text to Polish: {{ parents_output_text }}\u0026#34;, prompt_driver=prompt_driver, id=\u0026#34;polish_translate_task\u0026#34;, child_ids=[\u0026#34;print_task\u0026#34;], ) print_task = CodeExecutionTask(on_run=print_result, id=\u0026#34;print_task\u0026#34;) workflow = Workflow( tasks=[ download_task, summary_task, russian_translate_task, polish_translate_task, print_task, ] ) Это было на удивление просто. PromptTask – наиболее базовый примитив, используемый для прямых запросов в LLM. Из интересного здесь только то, что мы указали в summary_task сразу несколько потомков, что позволяет нескольким задачам выполняться в параллель. Но как мы можем проверить, что задачи действительно выполняются параллельно? Разработчики предусмотрели и это, предоставив в API поддержку хуков. В частности, в конструкторе любой задачи есть параметры on_before_run и on_after_run, позволяющие добавить произвольную пре- и постобработку. Воспользуемся ими:\nfrom griptape.tasks import BaseTask from datetime import datetime ... def timestamp(task: BaseTask, action: str): print(f\u0026#34;task {task.id} {action} at {datetime.now().isoformat()}\u0026#34;) def process_url(url: str): ... polish_translate_task = PromptTask( \u0026#34;Please translate the following text to Polish: {{ parents_output_text }}\u0026#34;, prompt_driver=prompt_driver, on_before_run=lambda task: timestamp(task, \u0026#34;started\u0026#34;), on_after_run=lambda task: timestamp(task, \u0026#34;finished\u0026#34;), id=\u0026#34;polish_translate_task\u0026#34;, child_ids=[\u0026#34;print_task\u0026#34;], ) # И так же точно для остальных задач Получаем следующий результат, полностью оправдывающий наши ожидания:\n$ uv run ./main.py https://docs.griptape.ai/stable/griptape-framework/structures/agents/ task summary_task started at 2025-06-05T22:03:02.272397 task summary_task finished at 2025-06-05T22:03:04.345067 task russian_translate_task started at 2025-06-05T22:03:04.347638 task polish_translate_task started at 2025-06-05T22:03:04.351531 task polish_translate_task finished at 2025-06-05T22:03:05.702819 task russian_translate_task finished at 2025-06-05T22:03:05.947364 Output: Agents in Griptape offer a quick start, directly processing tools and input to generate a Prompt Task. The final output is accessible via the `output` attribute. An example demonstrates an Agent using a `CalculatorTool` to compute 13^7, showing the input, tool action, and the resulting output. Output: Вот перевод текста на русский язык: Агенты в Griptape предлагают быстрый старт, напрямую обрабатывая инструменты и входные данные для генерации задачи (Prompt Task). Конечный результат доступен через атрибут `output`. Пример демонстрирует Агента, использующего `CalculatorTool` для вычисления 13^7, показывая входные данные, действие инструмента и полученный результат. Output: Oto tłumaczenie tekstu na język polski: Agenci w Griptape oferują szybki start, bezpośrednio przetwarzając narzędzia i dane wejściowe w celu wygenerowania Zadania Monitu (Prompt Task). Ostateczny wynik jest dostępny poprzez atrybut `output`. Przykład demonstruje Agenta używającego `CalculatorTool` do obliczenia 13^7, pokazując dane wejściowe, działanie narzędzia i wynik końcowy. Из логов ясно видно, что перевод на русский и польский работают параллельно друг другу.\nИ для порядка приведу текущий граф:\ngraph TD; Download_Task--\u0026gt; Summary_Task; Summary_Task--\u0026gt; Print_Task \u0026amp; Russian_Translate_Task \u0026amp; Polish_Translate_Task; Russian_Translate_Task--\u0026gt; Print_Task; Polish_Translate_Task--\u0026gt; Print_Task; Print_Task; Заканчиваем Остальное, по сути, уже дело техники, поэтому я просто приведу ниже весь код программы:\nimport argparse import dotenv import os from griptape.structures import Workflow from griptape.tasks import CodeExecutionTask from griptape.loaders import WebLoader from griptape.utils import StructureVisualizer from griptape.tasks import TextSummaryTask from griptape.engines import PromptSummaryEngine from griptape.drivers.prompt.openai import OpenAiChatPromptDriver from griptape.tasks import PromptTask, BaseTask from griptape.chunkers import TextChunker from griptape.artifacts import TextArtifact from datetime import datetime import logging logging.getLogger(\u0026#34;griptape\u0026#34;).setLevel(logging.WARNING) dotenv.load_dotenv() def load_page(task: CodeExecutionTask) -\u0026gt; str: \u0026#34;\u0026#34;\u0026#34;Load the content of the given URL.\u0026#34;\u0026#34;\u0026#34; return WebLoader().load(task.input.value) def combine_result(task: CodeExecutionTask) -\u0026gt; TextArtifact: \u0026#34;\u0026#34;\u0026#34;Combine results from parent tasks.\u0026#34;\u0026#34;\u0026#34; result = \u0026#34;\u0026#34; for parent in task.parents: if parent.output.value: result += f\u0026#34;{parent.output.value}\\n\\n\u0026#34; return TextArtifact(result) def send_to_telegram(task: CodeExecutionTask) -\u0026gt; None: \u0026#34;\u0026#34;\u0026#34;Send the result to Telegram.\u0026#34;\u0026#34;\u0026#34; # Placeholder for sending to Telegram logic print(f\u0026#34;Sending to Telegram: {task.parents[0].output.value}\u0026#34;) def timestamp(task: BaseTask, action: str): print(f\u0026#34;task {task.id} {action} at {datetime.now().isoformat()}\u0026#34;) def process_url(url: str): \u0026#34;\u0026#34;\u0026#34;Process the provided URL.\u0026#34;\u0026#34;\u0026#34; key = os.environ.get(\u0026#34;OPENROUTER_API_KEY\u0026#34;, \u0026#34;\u0026#34;) if not key: raise ValueError(\u0026#34;OPENROUTER_API_KEY is not set in the environment variables.\u0026#34;) prompt_driver=OpenAiChatPromptDriver( model=\u0026#34;google/gemini-2.5-flash-preview-05-20\u0026#34;, base_url=\u0026#34;https://openrouter.ai/api/v1\u0026#34;, api_key=key, ) download_task = CodeExecutionTask( on_run=load_page, input=url, id=\u0026#34;download_task\u0026#34;, child_ids=[\u0026#34;summary_task\u0026#34;] ) summary_task = TextSummaryTask( \u0026#34;Please summarize the following content in a concise manner. {{ parents_output_text }}\u0026#34;, summary_engine=PromptSummaryEngine( prompt_driver=prompt_driver, chunker = TextChunker(max_tokens=16000) ), on_before_run=lambda task: timestamp(task, \u0026#34;started\u0026#34;), on_after_run=lambda task: timestamp(task, \u0026#34;finished\u0026#34;), id=\u0026#34;summary_task\u0026#34;, child_ids=[\u0026#34;combine_task\u0026#34;, \u0026#34;russian_translate_task\u0026#34;, \u0026#34;polish_translate_task\u0026#34;], ) russian_translate_task = PromptTask( \u0026#34;Please translate the following text to Russian: {{ parents_output_text }}\u0026#34;, prompt_driver=prompt_driver, on_before_run=lambda task: timestamp(task, \u0026#34;started\u0026#34;), on_after_run=lambda task: timestamp(task, \u0026#34;finished\u0026#34;), id=\u0026#34;russian_translate_task\u0026#34;, child_ids=[\u0026#34;combine_task\u0026#34;], ) polish_translate_task = PromptTask( \u0026#34;Please translate the following text to Polish: {{ parents_output_text }}\u0026#34;, prompt_driver=prompt_driver, on_before_run=lambda task: timestamp(task, \u0026#34;started\u0026#34;), on_after_run=lambda task: timestamp(task, \u0026#34;finished\u0026#34;), id=\u0026#34;polish_translate_task\u0026#34;, child_ids=[\u0026#34;combine_task\u0026#34;], ) combine_task = CodeExecutionTask(on_run=combine_result, id=\u0026#34;combine_task\u0026#34;, child_ids=[\u0026#34;send_task\u0026#34;]) send_task = CodeExecutionTask( on_run=send_to_telegram, id=\u0026#34;send_task\u0026#34;, ) workflow = Workflow( tasks=[ download_task, summary_task, russian_translate_task, polish_translate_task, combine_task, send_task ] ) workflow.run() print(StructureVisualizer(workflow).to_url()) print(\u0026#34;Workflow completed successfully.\u0026#34;) def main(): parser = argparse.ArgumentParser(description=\u0026#34;Process URLs for link blog\u0026#34;) parser.add_argument(\u0026#34;url\u0026#34;, type=str, help=\u0026#34;URL to process\u0026#34;) args = parser.parse_args() process_url(args.url) if __name__ == \u0026#34;__main__\u0026#34;: main() И граф:\ngraph TD; Download_Task--\u0026gt; Summary_Task; Summary_Task--\u0026gt; Combine_Task \u0026amp; Russian_Translate_Task \u0026amp; Polish_Translate_Task; Russian_Translate_Task--\u0026gt; Combine_Task; Polish_Translate_Task--\u0026gt; Combine_Task; Combine_Task--\u0026gt; Send_Task; Send_Task; Я считаю, код выглядит довольно просто, легко читается и достаточно гибок для изменения и переиспользования. Очевидно, что в реальных задачах вся эта простота будет разбавлена обработкой ошибок, логированием и прочим. Но про это будет иметь смысл поговорить отдельно.\nДополнительно, Workflow API предоставляет еще два стиля композиции задач, не требующие указывать родителей и потомков при создании задач:\nИмперативный, при котором мы можем использовать функции add_parent и add_child Так называемый bit-shift, при котором родители и потомки могут связываться так: task1 \u0026gt;\u0026gt; task2 \u0026gt;\u0026gt; [task3, task4] Оба этих стиля позволяют с легкостью собирать разные графы из готовых примитивов, хотя bit-shift ощущается скорее как отдельный DSL, чем стандартный Python.\nЗакончили В заключение хотелось бы сказать, что на данном этапе фреймворк мне нравится. Он достаточно логичен, гибок и приятен, хотя и не лишен некоторых шероховатостей.\nДокументация тоже мне показалась довольно неплохой, хотя ей и не хватает описания того, как именно работают некоторые движки. Пока чтобы раздобыть эту информацию, приходится шерстить логи или код.\nНу что ж, с базовой функциональностью мы разобрались, в следующий раз посмотрим, какие примитивы фреймворк предоставляет для построения RAG.\nмы ведь хотим убедиться, что нам не будет мучительно стыдно за то, что мы опубликовали, верно?\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nкоторый я крайне уважаю и про который я надеюсь когда-нибудь написать отдельный пост\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://meshrefine.com/ru/posts/griptape-2/","summary":"\u003cp\u003eВ \u003ca href=\"/ru/posts/griptape-1/\"\u003eпрошлом посте\u003c/a\u003e я провел разбор базовых концептов AI-фреймворка \u003ca href=\"https://www.griptape.ai\"\u003eGriptape\u003c/a\u003e, и сейчас самое время применить их к делу. Попробуем их использовать для разработки небольшого приложения, которое помогает вести линк-блог в телеграме.\u003c/p\u003e\n\u003cp\u003eПриложение будет получать URL, скачивать его, прогонять через LLM для генерации сокращенного содержания, переводить это содержимое еще на несколько языков, собирать все вместе и публиковать в телеграме через бота. Общий флоу можно увидеть на схеме ниже:\u003c/p\u003e\n\u003cpre class=\"mermaid\"\u003e\n  flowchart LR\n\tA[\u0026#34;URL\u0026#34;]\n\tA --\u0026gt; Parser[\u0026#34;Парсер\u0026#34;] --\u0026gt; LLM1[\u0026#34;Суммаризатор\u0026#34;] \n\tLLM1 --\u0026gt; Translator1[\u0026#34;Перевод на язык 1\u0026#34;]\n\tLLM1 --\u0026gt; Translator2[\u0026#34;Перевод на язык 2\u0026#34;]\n\tTranslator1 --\u0026gt; Combiner[\u0026#34;Сборщик\u0026#34;]\n\tTranslator2 --\u0026gt; Combiner\n\tLLM1 --\u0026gt; Combiner\n\tCombiner --\u0026gt; Telegram[\u0026#34;Телеграм-бот\u0026#34;]\n\u003c/pre\u003e\n\u003cp\u003eДля простоты картины я опущу имплементацию телеграм-бота, а также оставлю в покое мой любимый Human-in-the-loop, который, по моему мнению, обязательно должен присутствовать как минимум где-то в районе сборщика \u003csup id=\"fnref:1\"\u003e\u003ca href=\"#fn:1\" class=\"footnote-ref\" role=\"doc-noteref\"\u003e1\u003c/a\u003e\u003c/sup\u003e.\u003c/p\u003e","title":"Griptape, часть 2: Строим графы"},{"content":"Что еще за Codex? Хороший вопрос, правда. Дело в том, что до недавнего времени у OpenAI была модель Codex, которая использовалась как основа для автодополнения в GitHub Copilot. Затем OpenAI выпустили консольного агента для разработки, которого они назвали, чтобы никто не перепутал, Codex. 1 Все посмеялись над умением OpenAI подбирать имена 2, и продолжили жить дальше. Пока не настал знаменательный день, в который в твиттере появился вот такой пост от Сэма Альтмана:\nЯ был заинтригован. Во-первых, нагнетанием хайпа, используя фразу \u0026ldquo;low-key research preview\u0026rdquo; 3, а во-вторых, этим самым именем. Впрочем, я не был разочарован:\nС этим постом семейство сущностей по имени Codex пополнилось двумя новыми представителями:\nВариант модели o3, заточенный специально для программирования, под названием codex-1 Облачный агент, способный автономно выполнять несколько разных задач над репозиторием в GitHub 4 Именно о последнем и пойдет сегодня речь.\nКак это работает? Последовательность наших действий, необходимых для пользования агентом, довольно проста:\nПункт 1. Мы идем на https://chatgpt.com/codex. Там мы видим список задач, которые агент исполняет/исполнил, и окно для ввода задания, в котором мы можем выбрать репозиторий, с которым хотим работать, и ветку. Есть две кнопки - Ask, анализирующий код, прежде чем автоматически предложить конкретные подзадания, и Code, который будет непосредственно править код.\nПункт 2. Для добавления нового репозитория мы идем в меню Environments и создаем там новое окружение. Там мы можем указать собственно репо, указать настройки рабочей среды, и попробовать ее в деле.\nПункт 3. Возвращаемся на главный экран, и пишем наше пожелание.\nПункт 4, самый интересный. Среда разворачивает контейнер на основе Ubuntu, устанавливает в нее необходимые пакеты, применяет пользовательские настройки окружения, и клонирует репозиторий внутрь. После этого интернет отключается 5 (уже не всегда, об этом и пост), и агент начинает свою работу. Делает он это долго и усердно, поскольку планировщик там от o3, и это хороший планировщик. За этим процессом можно понаблюдать в окне Logs:\nПункт 5. После нескольких минут работы нам предлагается diff, который мы можем проверить, и либо создать pull-request на GitHub, либо направить процесс на путь истинный и повторить итерацию.\nПункты 3-5 можно запускать в параллель и заниматься своими делами, пока агент работает. При этом диффы, которые он выдает, очень компактные и их приятно читать, что повышает уверенность в правильности результата.\nДоступ к интернету Если внимательно посмотреть на процесс, то можно увидеть определенное ограничение. Отсутствие доступа к интернету во время выполнения ломает многие процессы сборки и тестирования, что ограничивает способности агента. Приводит это к как правило корректным результатам с припиской \u0026ldquo;Running tests: failed\u0026rdquo;. Случается это по разным причинам, но прежде всего потому, что часто при сборке необходимо скачать различные библиотеки. Конечно, это можно обойти на этапе настройки окружения, когда доступ еще есть, но этот процесс далеко не всегда тривиален.\nОграничение это было достаточно болезненным, из-за чего на днях OpenAI объявил о том, что теперь можно интернет модели оставить. Разумеется, пускать козла в огород модель в интернет без каких-либо ограничений опасно, поэтому нам был предоставлен выбор режимов доступа.\nВо-первых, мы можем оставить все как есть, и в интернет не пускать. Во-вторых, мы можем доступ дать, но к ограниченному количеству ресурсов 6. Кроме того, мы можем разрешить модели выполнять только операции чтения. Самым отчаянным и смелым позволяется дать агенту полный и неограниченный доступ и надеяться на лучшее.\nБезопасность Почему надеяться? Потому что прямой доступ к непроверенным ресурсам грозит целой гроздью проблем, о чем OpenAI навязчиво предупреждает.\nПри этом в предупреждении смешались в кучу кони, люди, и в одном списке упоминается атака и ее последствия:\nPrompt injection: Модель скачивает веб-страничку, видит там текст, похожий на инструкцию, и радостно его выполняет. При этом инструкция вполне может попросить \u0026hellip; Exfiltration of code or secrets: \u0026hellip; загрузить содержимое репозитория и секреты на сторонний ресурс; Inclusion of malware or vulnerabilities: \u0026hellip; или использовать библиотеку-зловред вместо легитимной. Use content with license restriction: Впрочем, модель может сама решить, что код, который она нашла в репозитории под лицензией GPL — это лучшее, что можно добавить в наш репозиторий, что может привести к определенным юридическим проблемам. Поэтому строго рекомендуется ограничивать доступ модели только к проверенным ресурсам, и только тогда, когда это необходимо.\nМаленький пример и заключение Разумеется, доступ к интернету открывает массу интересных возможностей помимо упрощения сборки. Я, например, первым делом попросил модель проверить этот сайт на возможные проблемы с SEO. Результат можно увидеть ниже.\nПодводя итоги, могу сказать, что в целом мне инструмент нравится. Маленький размер диффов и возможность запуска нескольких задач в параллель позволяют делать маленькие рефакторинги и улучшения по принципу fire-and-forget, не погружая себя непосредственно в контекст и не отвлекаясь от других задач. Это сильно экономит время и снимает когнитивную нагрузку.\nИнтересно будет посмотреть на то, что в ответ предложат конкуренты. 7\nС припиской CLI, хотя практически везде на него ссылаются как на Codex\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nВ конце-концов, по сравнению с именованием их моделей, такой конфуз — детский лепет\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nСэм — мастер взаимоисключающих параграфов\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nДругие (пока?) не поддерживаются\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nРади безопасности, об этом пойдет речь дальше\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nПри этом список ресурсов с различными репозитариями уже прописан\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nСпустя несколько дней на Google I/O 2025 был представлен Jules, работающий по очень схожему принципу, но из-за большого размера диффов, генерируемых Gemini 2.5 Pro, использовать его значительно сложнее.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://meshrefine.com/ru/posts/openai-codex-internet-access/","summary":"\u003ch2 id=\"что-еще-за-codex\"\u003eЧто еще за Codex?\u003c/h2\u003e\n\u003cp\u003eХороший вопрос, правда. Дело в том, что до недавнего времени у OpenAI была модель Codex, которая использовалась как основа для автодополнения в GitHub Copilot. Затем OpenAI выпустили консольного агента для разработки, которого они назвали, чтобы никто не перепутал, \u003ca href=\"https://github.com/openai/codex\"\u003eCodex\u003c/a\u003e. \u003csup id=\"fnref:1\"\u003e\u003ca href=\"#fn:1\" class=\"footnote-ref\" role=\"doc-noteref\"\u003e1\u003c/a\u003e\u003c/sup\u003e Все посмеялись над умением OpenAI подбирать имена \u003csup id=\"fnref:2\"\u003e\u003ca href=\"#fn:2\" class=\"footnote-ref\" role=\"doc-noteref\"\u003e2\u003c/a\u003e\u003c/sup\u003e, и продолжили жить дальше. Пока не настал знаменательный день, в который в твиттере появился вот такой пост от Сэма Альтмана:\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"sama-tweet-1.png\"\n         alt=\"Tweet 1\"/\u003e \n\u003c/figure\u003e\n\n\u003cp\u003eЯ был заинтригован. Во-первых, нагнетанием хайпа, используя фразу \u0026ldquo;low-key research preview\u0026rdquo; \u003csup id=\"fnref:3\"\u003e\u003ca href=\"#fn:3\" class=\"footnote-ref\" role=\"doc-noteref\"\u003e3\u003c/a\u003e\u003c/sup\u003e, а во-вторых, этим самым именем. Впрочем, я не был разочарован:\u003c/p\u003e","title":"OpenAI Codex получил доступ в интернет: первые впечатления"},{"content":"Оглавление гайда по Hugo для суровых инженеров: Оглавление гайда по Hugo для суровых инженеров: 1. Вводная для тех, кто не в теме Что за зверь этот Hugo и на кой хрен он нужен? Почему статика – это зашибись (краткий ликбез по преимуществам) Когда Hugo – твой выбор, а когда лучше даже не начинать 2. Быстрый старт, чтобы сразу в бой Установка (без лишней воды, по-спартански) hugo new site мой_супер_сайт – создаем проект за три секунды Структура каталогов Hugo: что, где и почему именно так hugo server -D – запускаем локальный сервер и смотрим, что получилось 3. Контент – всему голова Markdown – твой основной инструмент. Фичи и как им пользоваться по-человечески. Front Matter (YAML/TOML/JSON) – метаданные для твоих страниц. Зачем и как. Типы контента (content types): посты, страницы, кастомные разделы. Таксономии: категории, теги и прочая сортировка контента. Архетипы: шаблоны для создания однотипного контента, чтобы не копипастить. 4. Шаблоны – лицо сайта Go Templates – основы основ (синтаксис, переменные, функции) Базовые шаблоны и блоки (DRY, мать его) Списковые страницы (индексы, категории, теги и т.д.) Одиночные страницы (деталка поста/страницы) Partials (переиспользуемые куски кода) Встроенные переменные Hugo (.Page, .Site – что доступно из коробки) 5. Конфигурация – рулим всем из одного места Файл конфигурации (hugo.toml или config.toml/yaml/json) – сердце проекта. Основные настройки: baseURL, title, languageCode, theme. Настройка меню (главное, боковое, подвальное – какое хочешь). Переменные окружения для разных конфигураций (дев, прод). 6. Расширенные возможности Shortcodes (макросы для контента, если Markdown уже не хватает) Data Templates (грузим данные из JSON, YAML, CSV – откуда угодно) Asset Pipeline (Hugo Pipes) – обработка CSS/JS, картинок Мультиязычность (если вдруг приспичило) Обработка изображений (ресайз, кроп, вот это всё) 7. Сборка и деплой Команда hugo – собираем статику Оптимизация для продакшена (минификация всего и вся) Куда деплоить (Netlify, Vercel, GitHub Pages, свой сраный VPS – вариантов масса) CI/CD – автоматизируем рутину 8. Лучшие практики и подводные камни Организация проекта (чтобы потом самому не охренеть) Производительность (как не сделать тормознутый сайт на статике) Отладка (когда всё пошло\u0026hellip; не так) Типичные ошибки новичков (и не очень) 1. Вводная для тех, кто не в теме Слушай сюда, инженер. Если ты до сих пор не слыхал про Hugo, значит, либо ты сидел в танке, либо занимался какой-то совсем уж узкоспециализированной херней. Но это поправимо.\nЧто за зверь этот Hugo и на кой хрен он нужен? Hugo – это, по сути, генератор статических сайтов. «Статических» – ключевое слово. Он берет твои шаблоны (HTML-каркас), твой контент (обычно в Markdown-файлах) и на выходе выдает тебе готовый набор HTML, CSS и JavaScript файлов. Всё. Никаких тебе баз данных на сервере, никакого PHP, Python или Ruby, которые крутятся и ждут запроса. Просто голые файлы, которые отдаются браузеру пользователя как есть.\nНа кой хрен он нужен?\nСкорость, мать её. Сайты, сгенерированные Hugo, летают. Потому что отдавать статику – это самое быстрое, что может делать веб-сервер. Никаких запросов к БД, никакой серверной логики на каждый чих. Пользователь запросил страницу – сервер ему тут же отдал готовый HTML. Всё. Для блогов, документации, лендингов, сайтов-визиток – это просто пушка. Безопасность. Раз нет серверной логики, которую можно взломать, нет базы данных, которую можно увести, то и дыр для атак на порядок меньше. Статический сайт – это как бронированная дверь. Можно, конечно, поковырять, но геморроя для хакера гораздо больше, а профита меньше. Простота хостинга и масштабирования. Статику можно захостить где угодно, хоть на самом дешманском хостинге, хоть на GitHub Pages, Netlify, Vercel, Cloudflare Pages – да хоть в S3-бакете. И масштабируется это дело элементарно: больше пользователей – просто раздаешь статику с CDN, и всё. Никаких тебе сложных настроек балансировщиков нагрузки для динамического контента. Контроль версий для всего. Контент, шаблоны, конфигурация – всё это текстовые файлы. А значит, всё это прекрасно ложится в Git. Вся история изменений, ветки для экспериментов, совместная работа – всё как ты любишь. Простота разработки (относительная). Если ты уже знаком с HTML/CSS и не боишься командной строки, то порог входа довольно низкий. Шаблонизатор Go (на котором Hugo написан) тоже не бином Ньютона. Главное – понять философию. Короче, Hugo – это инструмент, который берет на себя всю рутину по сборке сайта из твоих исходников и выдает на гора оптимизированный, быстрый и безопасный статический сайт. Если тебе не нужна сложная серверная логика на каждый запрос пользователя, то Hugo может сэкономить тебе кучу времени, нервов и денег.\nДальше разберем, почему статика сама по себе – это хорошо, если ты вдруг еще сомневаешься.\nОкей, продолжаем ликбез. Почему же статика – это так охрененно, что аж Hugo под нее придумали?\nПочему статика – это зашибись (краткий ликбез по преимуществам) Смотри, инженер, тут всё просто как три копейки, но многие до сих пор предпочитают городить огород с динамикой там, где он нахрен не нужен.\nСкорость света (ну, почти). Я уже говорил, но повторюсь: статические страницы отдаются браузеру мгновенно. Серверу не надо каждый раз чесать репу, лезть в базу, собирать страницу из кусков по шаблону, как это делает какой-нибудь WordPress или Joomla на каждый клик. Тут всё уже собрано заранее. Пользователь кликнул – получил. Итог: твои юзеры не ждут, поисковики любят быстрые сайты (привет, SEO!), конверсия растет.\nБезопасность уровня «крепость». Нет серверного кода, который обрабатывает пользовательские запросы в реальном времени, – нет и большинства векторов атаки. SQL-инъекции? Забудь. XSS через дыры в серверной логике? Мимо. DDoS на базу данных? Какая база данных, ты о чем? Конечно, сам веб-сервер (Nginx, Apache) можно попытаться положить или найти в нем уязвимость, но это уже совсем другая история, и к твоему сайту она имеет опосредованное отношение. Статика – это как бункер.\nХостинг за копейки (или вообще бесплатно). Раз твой сайт – это просто набор HTML/CSS/JS файлов, его можно положить куда угодно. GitHub Pages, GitLab Pages, Netlify, Vercel, Cloudflare Pages – эти ребята часто предлагают бесплатные тарифы для статических сайтов, да еще и с CDN из коробки. Даже если платно – это всё равно в разы дешевле, чем хостить жирную CMS с базой данных.\nМасштабируемость до Луны и обратно. Нужно выдержать наплыв трафика? Для статики это не проблема. Просто подключаешь CDN (Content Delivery Network), и твои файлы разлетаются по серверам по всему миру. Пользователь получает контент с ближайшего к нему сервера. Нагрузка на твой основной хостинг минимальна. Масштабировать динамический сайт с базой данных – это целый геморрой с репликацией, кэшированием, балансировщиками. Со статикой – чихнул и готово.\nНадежность как у швейцарских часов. Чем проще система, тем меньше в ней чему ломаться. В статическом сайте ломаться практически нечему. Сервер отдает файлы. Всё. Нет отвалившейся базы, нет упавшего PHP-FPM, нет проблем с версиями интерпретаторов. Сайт просто работает.\nРазработка и версионирование – как по маслу. Весь твой сайт – это код и текстовые файлы. Контент в Markdown, шаблоны в HTML/Go Templates, конфиги в TOML/YAML. Всё это прекрасно живет в Git. Ты получаешь всю мощь систем контроля версий: история изменений, ветки, мержи, ревью кода (да, контент – это тоже в каком-то смысле код). Откатиться на предыдущую версию? Легко. Работать командой? Без проблем.\nМеньше головной боли с обслуживанием. Нет плагинов, которые надо постоянно обновлять, нет тем, которые ломаются после апдейта ядра CMS, нет патчей безопасности для фреймворка, которые надо срочно накатывать. Собрал сайт – и он работает. Конечно, сам Hugo обновляется, но это процесс сборки, а не работы живого сайта.\nПонятно, что статика – не панацея. Если тебе нужна сложная пользовательская логика, личные кабинеты с данными в реальном времени, форумы – тут без динамики никуда. Но для огромного пласта задач – блоги, документация, сайты-портфолио, корпоративные сайты с нечасто меняющимся контентом, лендинги – статика рулит и бибикает.\nТак что, если задача позволяет, выбирать статику – это не просто модно, это, разумно и эффективно.\nОтлично. Теперь давай разберемся, когда этот ваш Hugo – действительно тема, а когда ты с ним только натрахаешься, а толку будет ноль. Это важно, чтобы не вляпаться по незнанию.\nКогда Hugo – твой выбор, а когда лучше даже не начинать Слушай внимательно, чтобы потом локти не кусал.\nHugo – это то, что доктор прописал, если:\nТебе нужен блог или сайт с документацией. Вот тут Hugo просто король. Markdown для контента, бешеная скорость сборки даже для тысяч страниц, таксономии, секции – всё заточено под это. Ты пилишь портфолио, личный сайт, сайт-визитку. Где контент меняется нечасто, а главное – скорость загрузки и чтобы выглядело прилично. Меньше геморроя с хостингом, больше времени на сам контент. Нужен лендинг или промо-сайт. Опять же, скорость загрузки решает. Плюс, всё под контролем в Git, легко откатываться, легко тестировать A/B варианты, меняя ветки. Корпоративный сайт с информацией о компании, услугах, новостями. Если там нет сложной интерактивности и личных кабинетов с данными \u0026ldquo;на лету\u0026rdquo; – Hugo справится на ура. Скорость, безопасность и минимальные затраты на хостинг – твои главные приоритеты. Если эти три пункта для тебя альфа и омега, то статика, и Hugo как ее представитель, – твой прямой путь. Ты или твоя команда нормально себя чувствуете с Git и Markdown. Если от вида командной строки никого не тошнит, и написать текст с разметкой – не проблема, то процесс пойдет гладко. Ты хочешь полный контроль над разметкой и структурой. В отличие от многих CMS, где ты ограничен темой и плагинами, тут ты сам себе хозяин. Проекты, где контент – это тоже \u0026ldquo;код\u0026rdquo; и его важно версионировать, рецензировать, как обычный код. Например, техническая документация, юридические тексты, научные статьи. А вот когда от Hugo лучше держаться подальше или крепко подумать:\nТебе нужен полноценный интернет-магазин со сложной логикой. Корзины, оплата, управление заказами, личные кабинеты с историей покупок – это всё требует серьезного бэкенда. Hugo может быть витриной (JAMstack-подход с API), но сам по себе он это не вывезет. Слишком много костылей придется городить. Сайт с большим количеством пользовательского контента, который должен появляться мгновенно. Форумы, социальные сети, доски объявлений, где пользователи постоянно постят что-то новое, и это должно сразу отображаться для всех. Каждый чих пересобирать сайт – не вариант. Нужна сложная интерактивность, завязанная на серверную логику в реальном времени. Если у тебя на сайте какие-то калькуляторы, которые шлют данные на сервер, тот их обрабатывает и тут же выдает результат, или графики, строящиеся на основе постоянно меняющихся данных из БД – Hugo тут не помощник. Это задачи для полноценных веб-приложений. Команда, которая будет работать с сайтом, состоит из людей, далеких от IT. Если контент-менеджеры привыкли к визуальным редакторам а-ля WordPress и боятся даже слова \u0026ldquo;Markdown\u0026rdquo;, им будет сложно. Конечно, есть CMS-надстройки над статикой (типа Forestry, Netlify CMS, Decap CMS), но это уже дополнительные инструменты. Проект, где ключевая фича – это персонализация контента на лету на стороне сервера для каждого пользователя. Опять же, статика – это \u0026ldquo;один для всех\u0026rdquo; (пока не подключишь JavaScript и API). Если ты просто не хочешь разбираться с командной строкой, Git, и предпочитаешь \u0026ldquo;all-in-one\u0026rdquo; решения с админкой. Hugo – это инструмент для тех, кто готов немного испачкать руки в \u0026ldquo;коде\u0026rdquo; и конфигурации. Короче, главный принцип: если большую часть времени твой сайт просто показывает информацию, а не обрабатывает пользовательские данные или не меняется каждую секунду для каждого пользователя, то Hugo – отличный кандидат. Если же там сплошная динамика и интерактив на сервере – смотри в сторону классических фреймворков и CMS.\nНа этом с вводной частью, пожалуй, всё. Общее представление, надеюсь, сложилось. Если вопросов нет, можем двигать дальше по плану – к быстрой установке и созданию первого сайта.\nЗамётано. Хватит теории, пора пачкать руки.\n2. Быстрый старт, чтобы сразу в бой Сейчас покажу, как эту шарманку завести с пол-оборота. Без лишних сантиментов, только хардкор.\nУстановка (без лишней воды, по-спартански) С установкой Hugo всё просто, как рельса. Эта хрень написана на Go, поэтому чаще всего это один бинарник, который ты просто качаешь и делаешь доступным системе.\nДля нормальных пацанов (Linux/macOS через пакетный менеджер):\nmacOS (Homebrew): brew install hugo Linux (Snap): sudo snap install hugo Linux (APT, для Debian/Ubuntu, но может быть не самая свежая версия): sudo apt install hugo Arch Linux: sudo pacman -S hugo Fedora: sudo dnf install hugo Короче, гуглишь \u0026ldquo;install hugo [твоя_операционка]\u0026rdquo; – первая ссылка обычно на официальный сайт, там всё расписано.\nДля тех, кто любит посложнее (Windows или ручная установка):\nWindows (Chocolatey): choco install hugo -confirm Windows (Scoop): scoop install hugo Руками: Идешь на официальную страницу релизов Hugo на GitHub. Находишь последний релиз, качаешь архив для своей ОС (обычно hugo_extended_..._你的ОС_Архитектура.tar.gz или .zip). Распаковываешь. Внутри будет бинарник hugo (или hugo.exe для Windows). Этот файл надо положить в директорию, которая есть в твоем системном PATH (чтобы команда hugo была доступна из любой папки в терминале). Или каждый раз указывать полный путь к этому бинарнику, что есть мазохизм. Важно: Качай extended версию. Она нужна для некоторых тем и для обработки SASS/SCSS через Hugo Pipes. Не жмись, разница в размере мизерная, а геморроя потом меньше. Проверка: Открываешь терминал/командную строку и пишешь:\nhugo version Если видишь что-то вроде hugo v0.12X.Y-блаблабла extended – ты в игре. Если ошибка – значит, накосячил с установкой или PATH не настроил. Разбирайся, это азы.\nНе вижу смысла тут разжевывать каждый чих установки для каждой системы. Ты инженер, а не детсадовец. Официальная дока Hugo по установке (gohugo.io/installation/) тебе в помощь, если что.\nhugo new site мой_супер_сайт – создаем проект за три секунды Установил? Красава. Теперь создадим скелет твоего будущего нетленного творения. Открывай терминал, переходи в папку, где будут лежать твои проекты, и командуй:\nhugo new site мой_супер_сайт Замени мой_супер_сайт на любое адекватное имя для твоего проекта (латиницей, без пробелов, как взрослый). Hugo тут же создаст папку с этим именем и напихает туда базовую структуру каталогов.\nЧто ты увидишь:\nCongratulations! Your new Hugo site is created in /путь/к/твоей/папке/мой_супер_сайт. Just a few more steps and you\u0026#39;re ready to go: 1. Download a theme into the same-named folder. Choose a theme from https://themes.gohugo.io/ or create your own with the \u0026#34;hugo new theme \u0026lt;THEMENAME\u0026gt;\u0026#34; command. 2. Perhaps you want to add some content. You can add single files with \u0026#34;hugo new posts/my-first-post.md\u0026#34;. 3. Start the built-in live server via \u0026#34;hugo server\u0026#34;. Visit https://gohugo.io/ to learn more. Не спеши сразу выполнять все эти пункты, особенно с темой. Сначала разберемся со структурой.\nСтруктура каталогов Hugo: что, где и почему именно так Заходи в созданную папку мой_супер_сайт. Увидишь там примерно следующее (может чуть отличаться в зависимости от версии Hugo):\narchetypes/: Здесь лежат \u0026ldquo;архетипы\u0026rdquo; – шаблоны для создания новых файлов контента. Например, default.md. Когда ты делаешь hugo new posts/my-post.md, Hugo берет архетип и создает файл с уже готовой Front Matter (метаданными). Удобно, чтобы не писать одно и то же каждый раз. assets/: Сюда кладешь свои \u0026ldquo;сырые\u0026rdquo; ассеты, которые будут обрабатываться Hugo Pipes – SASS/SCSS, JavaScript, который нужно бандлить/минифицировать, изображения для обработки. Если просто хочешь положить готовый CSS или картинку – для этого есть static/. content/: Сердце твоего сайта. Здесь живет твой контент в виде Markdown (.md) файлов, организованных по папкам, которые обычно соответствуют разделам сайта. Например, content/posts/ для постов блога, content/about.md для страницы \u0026ldquo;О нас\u0026rdquo;. data/: Сюда можно складывать данные в форматах TOML, YAML или JSON (например, список продуктов, контакты). Эти данные потом можно использовать в шаблонах. layouts/: Это твои HTML-шаблоны. Они определяют, как будет выглядеть сайт. Здесь будут лежать базовые шаблоны, шаблоны для списков, отдельных страниц, partials (переиспользуемые куски HTML) и т.д. Если используешь готовую тему, то основные шаблоны будут в папке темы, но ты можешь их переопределять здесь. public/: Сюда Hugo будет складывать готовый статический сайт после сборки командой hugo. Важно: Содержимое этой папки генерируется автоматически. Не редактируй тут ничего руками – всё затрется при следующей сборке. Эту папку ты и будешь деплоить на хостинг. static/: Сюда кидаешь все статические файлы, которые не требуют обработки: готовые CSS, JavaScript, картинки, шрифты, favicon.ico, robots.txt и т.п. Всё, что лежит здесь, будет скопировано в корень папки public/ как есть. themes/: Если используешь готовую тему, она будет лежать здесь в своей подпапке. Hugo будет сначала искать шаблоны и ассеты в layouts/ и assets/ твоего проекта, а если не найдет – то в аналогичных папках активной темы. hugo.toml (или config.toml, config.yaml, config.json): Главный конфигурационный файл твоего сайта. Здесь ты будешь указывать название сайта, базовый URL, выбранную тему, настраивать меню, языки и кучу других параметров. Раньше по умолчанию был config.toml, сейчас Hugo стремится к hugo.toml, но старые форматы тоже поддерживает. Запомни эти папки, как «Отче наш». Понимание структуры – ключ к успеху с Hugo.\nhugo server -D – запускаем локальный сервер и смотрим, что получилось Итак, скелет есть. Давай его оживим. В терминале, находясь в корневой папке твоего сайта (мой_супер_сайт), выполни:\nhugo server -D Что тут происходит:\nhugo server: Команда запускает встроенный веб-сервер Hugo. Он шустрый и умеет делать LiveReload – то есть, как только ты сохраняешь изменения в контенте или шаблонах, страница в браузере обновляется автоматически. Мега-удобно для разработки. -D (или --buildDrafts): Флаг, который говорит Hugo собирать и показывать черновики (draft: true в Front Matter). По умолчанию черновики не собираются в финальную версию сайта и не показываются на дев-сервере. На этапе разработки это полезно. Можно еще использовать -F (--buildFuture), чтобы видеть посты с будущей датой, и -E (--buildExpired) для просроченных. После запуска команды ты увидишь что-то вроде:\n| EN -------------------+----- Pages | 4 Paginator pages | 0 Non-page files | 0 Static files | 0 Processed images | 0 Aliases | 1 Sitemaps | 1 Cleaned | 0 Built in 12 ms Watching for changes in /путь/к/твоей/папке/мой_супер_сайт/{archetypes,assets,content,data,layouts,static,themes} Watching for config changes in /путь/к/твоей/папке/мой_супер_сайт/hugo.toml Environment: \u0026#34;development\u0026#34; Serving pages from memory Web Server is available at http://localhost:1313/ (bind address 127.0.0.1) Press Ctrl+C to stop Открывай браузер и иди по адресу http://localhost:1313/.\nЧто ты там увидишь? Скорее всего, пустую страницу или ошибку 404. Не ссы, это нормально! Мы же еще не добавили никакого контента и не выбрали (или не создали) ни одной темы оформления. Hugo собрал \u0026ldquo;ничего\u0026rdquo; с \u0026ldquo;никаким\u0026rdquo; дизайном.\nЧтобы сайт хоть что-то показал, ему нужна тема (шаблоны) и хотя бы одна страница контента. Обычно первым делом подключают какую-нибудь простую тему с themes.gohugo.io или создают пару базовых шаблонов. Но об этом – в следующих сериях нашего марлезонского балета.\nПока что можешь остановить сервер, нажав Ctrl+C в терминале.\nНу как, почувствовал себя создателем сайтов? Это только начало. Дальше будет интереснее – будем наполнять эту структуру жизнью.\n3. Контент – всему голова Переходим к самому мясу – контенту. Без него твой сайт – просто набор красивых (или не очень) HTML-файлов без смысла.\nВ Hugo контент – это то, ради чего всё затевается. И работать с ним, если понять основные принципы, одно удовольствие.\nMarkdown – твой основной инструмент. Фичи и как им пользоваться по-человечески. Если ты до сих пор не писал на Markdown, то самое время начать. Это простой язык разметки, который превращается в HTML. Забудь про уродские WYSIWYG-редакторы из старых CMS, где ты полчаса воюешь со стилями. Тут всё чисто и под контролем.\nПочему Markdown?\nПростота: Синтаксис элементарный, запоминается за 5 минут. Читаемость: Исходный .md файл легко читается даже без конвертации в HTML. Портативность: Текстовые файлы, живут в Git, легко редактируются в любом текстовом редакторе. Hugo его любит: Hugo из коробки отлично работает с Markdown, используя по умолчанию парсер Goldmark (раньше был Blackfriday), который довольно мощный и расширяемый. Основные фишки Markdown, которые тебе понадобятся (кратко, остальное нагуглишь):\nЗаголовки:\n# H1 Заголовок ## H2 Заголовок ### H3 Заголовок ...и так до H6 Выделение текста:\n*Этот текст курсивом* или _этот тоже_ **Этот текст жирным** или __этот тоже__ ***А этот жирным курсивом*** или ___и этот___ ~~Этот текст зачеркнут~~ Списки:\nНенумерованные: * Пункт 1 * Пункт 2 * Вложенный пункт 2.1 - Или так + И даже так Нумерованные: 1. Первый пункт 2. Второй пункт 3. Третий пункт Ссылки:\n[Текст ссылки](http://example.com \u0026#34;Всплывающая подсказка\u0026#34;) Изображения:\n![Альтернативный текст для картинки](/путь/к/картинке.jpg \u0026#34;Заголовок картинки\u0026#34;) Путь может быть относительным или абсолютным. Hugo также умеет обрабатывать изображения, но об этом позже.\nЦитаты:\n\u0026gt; Это цитата. \u0026gt; Вторая строка цитаты. Горизонтальная линия:\n--- *** ___ Код:\nВстроенный (inline) код: Вот это слово будет выделено как код. Блоки кода (с подсветкой синтаксиса, если тема поддерживает): ```python def hello_world(): print(\u0026#34;Hello, Hugo!\u0026#34;) ``` Указывай язык после тройных кавычек для подсветки. Таблицы (базовый синтаксис):\n| Заголовок 1 | Заголовок 2 | | ----------- | ----------- | | Ячейка 1 | Ячейка 2 | | Ячейка 3 | Ячейка 4 | Этого набора тебе хватит для 95% задач. Hugo через Goldmark поддерживает и более продвинутые фичи, вроде сносок, списков задач и т.д., но это уже детали. Главное – пиши чисто, отделяй блоки пустой строкой, и будет тебе счастье.\nFront Matter (YAML/TOML/JSON) – метаданные для твоих страниц. Зачем и как. Front Matter – это то, что превращает простой Markdown-файл в «умную» страницу для Hugo. Это блок метаданных в самом начале твоего .md файла, который содержит информацию о странице: заголовок, дату, автора, теги, категории, черновик ли это, и любую другую хрень, которую ты захочешь туда запихнуть.\nHugo понимает три формата для Front Matter:\nYAML: Самый популярный, отделяется тройными дефисами (---). TOML: Похож на INI-файлы, отделяется тройными плюсами (+++). JSON: Классический JSON, заключается в фигурные скобки ({}). Пример YAML (чаще всего будешь видеть его):\n--- title: \u0026#34;Мой Первый Супер Пост\u0026#34; date: 2025-05-31T22:30:00+02:00 draft: false author: \u0026#34;Суровый Архитектор\u0026#34; tags: [\u0026#34;hugo\u0026#34;, \u0026#34;статика\u0026#34;, \u0026#34;гайд\u0026#34;] categories: [\u0026#34;Технологии\u0026#34;] description: \u0026#34;Краткое описание поста для SEO и превью.\u0026#34; some_custom_param: \u0026#34;Какое-то мое значение\u0026#34; --- А вот здесь уже начинается сам контент поста в Markdown... Пример TOML:\n+++ title = \u0026#34;Мой Первый Супер Пост\u0026#34; date = 2025-05-31T22:30:00+02:00 draft = false author = \u0026#34;Суровый Архитектор\u0026#34; tags = [\u0026#34;hugo\u0026#34;, \u0026#34;статика\u0026#34;, \u0026#34;гайд\u0026#34;] categories = [\u0026#34;Технологии\u0026#34;] description = \u0026#34;Краткое описание поста для SEO и превью.\u0026#34; some_custom_param = \u0026#34;Какое-то мое значение\u0026#34; +++ А вот здесь уже начинается сам контент поста в Markdown... Пример JSON:\n{ \u0026#34;title\u0026#34;: \u0026#34;Мой Первый Супер Пост\u0026#34;, \u0026#34;date\u0026#34;: \u0026#34;2025-05-31T22:30:00+02:00\u0026#34;, \u0026#34;draft\u0026#34;: false, \u0026#34;author\u0026#34;: \u0026#34;Суровый Архитектор\u0026#34;, \u0026#34;tags\u0026#34;: [\u0026#34;hugo\u0026#34;, \u0026#34;статика\u0026#34;, \u0026#34;гайд\u0026#34;], \u0026#34;categories\u0026#34;: [\u0026#34;Технологии\u0026#34;], \u0026#34;description\u0026#34;: \u0026#34;Краткое описание поста для SEO и превью.\u0026#34;, \u0026#34;some_custom_param\u0026#34;: \u0026#34;Какое-то мое значение\u0026#34; } (Обрати внимание, что после JSON Front Matter обычно не ставят закрывающий разделитель, и сразу идет контент)\nСтандартные (предопределенные) переменные Front Matter, которые Hugo понимает из коробки:\ntitle: Заголовок страницы. Используется везде – в \u0026lt;title\u0026gt; HTML, в заголовках на странице и т.д. date: Дата публикации. Важно для сортировки постов. Формат – ISO 8601. publishDate: Дата, начиная с которой пост будет опубликован. expiryDate: Дата, после которой пост перестанет публиковаться. draft: true или false. Если true, страница не будет собрана по умолчанию (нужен флаг -D при hugo server или hugo). slug: Часть URL для этой страницы. Если не указан, Hugo сгенерирует его из имени файла или заголовка. url: Позволяет полностью переопределить URL страницы. aliases: Массив старых URL, с которых будет сделан редирект на эту страницу. Полезно при миграции сайта. type: Тип контента (например, post, page). Обычно определяется именем папки в content/, но можно переопределить. layout: Имя макета (шаблона) из папки layouts/, который нужно использовать для этой страницы. Позволяет переопределить стандартный выбор макета. markup: Указывает, какой обработчик использовать для контента (md для Markdown, html, rst для reStructuredText, если настроено). outputs: Позволяет определить, в каких форматах выводить страницу (например, [\u0026quot;HTML\u0026quot;, \u0026quot;JSON\u0026quot;, \u0026quot;AMP\u0026quot;]). weight: Число для ручной сортировки страниц в списках. Меньший вес – выше в списке. description: Краткое описание, часто используется для мета-тега description в SEO. keywords: Массив ключевых слов. tags, categories: Стандартные таксономии. Можно определять и свои. Помимо этих, ты можешь добавлять любые свои кастомные параметры. Например, featured_image: \u0026quot;/images/my-post-banner.jpg\u0026quot; или show_sidebar: false. Эти параметры будут доступны в шаблонах через .Params.имя_параметра.\nFront Matter – это мозг твоей страницы. Отнесись к нему серьезно.\nТипы контента (content types): посты, страницы, кастомные разделы. Hugo – парень умный и любит порядок. Он определяет тип контента (content type) в основном по тому, в какой папке первого уровня внутри директории content/ лежит твой файл.\ncontent/posts/my-first-post.md -\u0026gt; тип контента posts content/projects/super-project.md -\u0026gt; тип контента projects content/about.md (лежит прямо в content/) -\u0026gt; тип контента page (это специальный тип для одиночных страниц). Если точнее, то для файлов непосредственно в content/, тип обычно определяется именем секции, совпадающей с именем файла (без расширения), либо считается частью корневой секции. Для about.md, секция будет about, и тип будет page. Зачем это нужно? Для каждого типа контента Hugo будет искать свой набор шаблонов в папке layouts/. Например:\nДля контента типа posts: Одиночный пост: layouts/posts/single.html (или layouts/_default/single.html, если специфичного нет) Список постов: layouts/posts/list.html (или layouts/_default/list.html) Для контента типа projects: Одиночный проект: layouts/projects/single.html Список проектов: layouts/projects/list.html Это позволяет тебе иметь совершенно разное оформление и структуру для блога, портфолио, страниц документации и т.д.\nТы можешь явно указать тип контента в Front Matter через параметр type: \u0026quot;имя_типа\u0026quot;, но обычно в этом нет нужды, если ты правильно структурируешь папки.\nФайлы _index.md внутри папок секций (например, content/posts/_index.md) играют особую роль: они предоставляют контент и Front Matter для самой страницы секции (списка).\nТаксономии: категории, теги и прочая сортировка контента. Таксономии – это способ классификации твоего контента. По умолчанию в Hugo есть две: tags (теги, метки) и categories (категории). Но ты можешь определить и свои собственные (например, series, authors и т.д.) в файле конфигурации hugo.toml.\nКак это работает:\nВ Front Matter своего контент-файла ты указываешь теги и категории: --- title: \u0026#34;Пост про котиков и Hugo\u0026#34; date: 2025-06-01 tags: [\u0026#34;котики\u0026#34;, \u0026#34;hugo\u0026#34;, \u0026#34;милота\u0026#34;] categories: [\u0026#34;Животные\u0026#34;, \u0026#34;Технологии\u0026#34;] --- Контент про котиков... Hugo автоматически собирает все эти значения и создает: Страницы для каждого термина таксономии (например, /tags/котики/, /categories/животные/). На этих страницах будет список всего контента, помеченного этим тегом или категорией. Страницы списков всех терминов для каждой таксономии (например, /tags/, /categories/). Шаблоны для этих страниц таксономий ищутся в layouts/taxonomy/имя_термина.html (например, layouts/taxonomy/tag.html) и layouts/taxonomy/имя_таксономии.terms.html (например, layouts/taxonomy/tag.terms.html). Если их нет, используются дефолтные layouts/_default/list.html и layouts/_default/terms.html.\nТаксономии – мощный инструмент для навигации и организации большого количества контента.\nАрхетипы: шаблоны для создания однотипного контента, чтобы не копипастить. Мы уже упоминали папку archetypes/. Архетипы – это шаблоны для твоих контент-файлов. Когда ты создаешь новый контент командой hugo new путь/к/новому/файлу.md, Hugo ищет архетип, который соответствует этому пути, и использует его для создания файла.\nЕсли ты делаешь hugo new posts/my-new-post.md, Hugo сначала поищет archetypes/posts.md. Если не найдет, поищет archetypes/default.md. Если и его нет, создаст файл с минимальным Front Matter (обычно title, date, draft: true). Пример файла archetypes/posts.md:\n--- title: \u0026#34;{{ replace .Name \u0026#34;-\u0026#34; \u0026#34; \u0026#34; | title }}\u0026#34; # Берет имя файла, заменяет дефисы на пробелы, делает заглавные буквы date: {{ .Date }} # Текущая дата и время draft: true tags: [\u0026#34;\u0026#34;] categories: [\u0026#34;\u0026#34;] author: \u0026#34;Мое Имя По Умолчанию\u0026#34; # Еще какие-то параметры, специфичные для постов --- Тут можно даже добавить какой-то текст по умолчанию для тела поста. Например, напоминание: \u0026#34;Не забудь добавить картинку!\u0026#34; Здесь {{ .Name }} и {{ .Date }} – это переменные, которые Hugo подставит при создании файла. replace .Name \u0026quot;-\u0026quot; \u0026quot; \u0026quot; | title – это функция шаблонизатора Go, которая форматирует имя файла в заголовок.\nИспользование архетипов здорово экономит время и помогает поддерживать консистентность Front Matter для разных типов контента. Создал архетип один раз – и потом штампуешь новые страницы по образу и подобию.\nФух. Про контент вроде всё основное рассказал. Это база, на которой всё строится. Дальше будем смотреть, как этот контент красиво вывести с помощью шаблонов.\n4. Шаблоны – лицо сайта Итак, контент у нас есть (ну, или мы знаем, как его делать). Теперь надо, чтобы это всё не выглядело как говно мамонта, а имело приличный вид. За это в Hugo отвечают шаблоны. Они лежат в папке layouts/ (или в папке темы themes/имя_темы/layouts/).\nGo Templates – основы основ (синтаксис, переменные, функции) Hugo использует встроенный в язык Go шаблонизатор. Два основных пакета – text/template и html/template. Последний – умнее, он автоматически экранирует данные, чтобы ты случайно не создал XSS-уязвимость. Hugo в основном использует html/template для HTML-страниц.\nСинтаксис этого дела на первый взгляд может показаться немного спартанским, особенно если ты привык к чему-то типа Jinja2 или Twig. Но он мощный, и главное – быстрый.\nОсновные конструкции, которые надо знать:\nВывод данных (Actions): Всё, что ты хочешь вывести в HTML, заключается в двойные фигурные скобки {{ }}.\n\u0026lt;h1\u0026gt;{{ .Title }}\u0026lt;/h1\u0026gt; \u0026lt;p\u0026gt;Эта страница была опубликована {{ .Date.Format \u0026#34;02 January 2006\u0026#34; }}.\u0026lt;/p\u0026gt; \u0026ldquo;Точка\u0026rdquo; (. или \u0026ldquo;the dot\u0026rdquo;): Это самое главное понятие. Точка . – это текущий контекст, текущий объект, с которым ты работаешь. Внутри шаблона для одиночной страницы (single.html) точка . будет ссылаться на объект этой страницы. Внутри цикла по постам . будет ссылаться на текущий пост в итерации. Контекст может меняться.\n{{ .Title }}: Вывести заголовок текущей страницы. {{ .Content }}: Вывести основное содержимое текущей страницы (то, что ты написал в Markdown после Front Matter). {{ .Permalink }}: Вывести постоянную ссылку на текущую страницу. {{ .Params.имя_твоего_параметра }}: Доступ к кастомным параметрам из Front Matter. Например, {{ .Params.featured_image }}. Переменные: Можно создавать свои переменные внутри шаблона.\n{{ $author := .Params.author | default \u0026#34;Неизвестный Автор\u0026#34; }} \u0026lt;p\u0026gt;Автор: {{ $author }}\u0026lt;/p\u0026gt; Здесь мы создаем переменную $author. Если в Front Matter есть author, берем его, если нет – используем \u0026ldquo;Неизвестный Автор\u0026rdquo;. Переменные начинаются со знака доллара $.\nФункции и пайплайны (|): В Go Templates есть куча встроенных функций, и ты можешь передавать результат одной функции на вход другой через пайплайн |.\n{{ \u0026#34;привет, мир\u0026#34; | upper }} {{ .WordCount }} слов. {{ $originalUrl := \u0026#34;https://example.com/?q=hugo rocks\u0026#34; }} {{ $escapedUrl := $originalUrl | htmlEscape }} \u0026lt;a href=\u0026#34;{{ $escapedUrl }}\u0026#34;\u0026gt;Ссылка\u0026lt;/a\u0026gt; Функций много: eq (равно), ne (не равно), gt (больше), lt (меньше), len (длина), printf, safeHTML, safeJS, humanize и т.д. Список ищи в доках Hugo.\nУправляющие конструкции:\nif/else:\n{{ if .Params.show_author }} \u0026lt;p\u0026gt;Автор: {{ .Params.author }}\u0026lt;/p\u0026gt; {{ else if .Params.show_default_author }} \u0026lt;p\u0026gt;Автор: Команда сайта\u0026lt;/p\u0026gt; {{ else }} \u0026lt;p\u0026gt;Автор не указан\u0026lt;/p\u0026gt; {{ end }} Условия могут быть сложными: {{ if and (gt .WordCount 100) .Params.is_long_read }}.\nrange (циклы): Для перебора списков (например, страниц, тегов).\n\u0026lt;ul\u0026gt; {{ range .Site.RegularPages.ByDate.Reverse.Limit 5 }} \u0026lt;li\u0026gt;\u0026lt;a href=\u0026#34;{{ .RelPermalink }}\u0026#34;\u0026gt;{{ .Title }}\u0026lt;/a\u0026gt; ({{ .Date.Format \u0026#34;2006-01-02\u0026#34; }})\u0026lt;/li\u0026gt; {{ else }} \u0026lt;li\u0026gt;Пока нет постов для отображения.\u0026lt;/li\u0026gt; {{ end }} \u0026lt;/ul\u0026gt; Внутри range точка . меняет свой контекст на текущий элемент итерации.\nwith: Позволяет изменить контекст точки . на определенное значение, если оно существует. Удобно, чтобы не писать .Params.section.subsection.field много раз.\n{{ with .Params.author_details }} \u0026lt;p\u0026gt;Об авторе: {{ .name }}, {{ .bio }}\u0026lt;/p\u0026gt; {{ else }} \u0026lt;p\u0026gt;Детали автора не указаны.\u0026lt;/p\u0026gt; {{ end }} Комментарии:\n{{/* Это комментарий в шаблоне Hugo. Он не попадет в итоговый HTML. */}} Пробелы и дефисы: Иногда ты увидишь {{- .Value -}} или {{- if ... }}. Дефис - рядом с фигурными скобками убирает пробельные символы (пробелы, табы, переводы строк) до или после тега шаблонизатора. Помогает делать HTML-вывод чище, без лишних пустых строк.\n{{- убирает пробелы слева. -}} убирает пробелы справа. Это, конечно, верхушка айсберга. Шаблонизатор Go позволяет делать довольно хитрые вещи. Главное – постоянно помнить про контекст (точку .) и знать, какие переменные и функции доступны в данный момент. Официальная документация Hugo по шаблонам (gohugo.io/templates/) – твой лучший друг.\nПоначалу может показаться непривычно, но как только набьешь руку, будешь щелкать эти шаблоны как орешки. Главное, не бойся экспериментировать и смотреть, как устроены шаблоны в готовых темах.\nДальше по плану – базовые шаблоны и блоки. Это как раз про то, чтобы не повторять один и тот же HTML-код на каждой странице.\nБазовые шаблоны и блоки (DRY, мать его) Сейчас расскажу про одну из самых полезных фишек в шаблонизации Hugo – как не писать одно и то же по сто раз.\nПринцип DRY (Don\u0026rsquo;t Repeat Yourself) – «Не повторяйся» – это святое для любого вменяемого разработчика. И Hugo помогает тебе этому принципу следовать с помощью базовых шаблонов (base templates) и блоков (blocks).\nПредставь себе типичный сайт: у всех страниц есть общий \u0026lt;head\u0026gt;, шапка (header), подвал (footer), может быть, боковая панель. Было бы тупо копипастить весь этот HTML-каркас в каждый шаблон (single.html, list.html и т.д.). Вот для этого и нужен базовый шаблон.\nЧто такое базовый шаблон?\nЭто главный HTML-скелет твоего сайта. Обычно он называется baseof.html и лежит в layouts/_default/baseof.html (это самый общий, для всех типов контента, если нет более специфичного). Ты можешь также определить baseof.html для конкретных секций, например, layouts/posts/baseof.html – он будет использоваться для всех страниц в секции posts.\nВ этом baseof.html ты определяешь общую структуру и размечаешь блоки – это как бы «дырки» или «плейсхолдеры», которые будут заполняться содержимым из более конкретных шаблонов (например, из шаблона для отдельного поста или списка постов).\nКак это выглядит на практике?\nПример layouts/_default/baseof.html:\n\u0026lt;!DOCTYPE html\u0026gt; \u0026lt;html lang=\u0026#34;{{ .Site.LanguageCode | default \u0026#34;en\u0026#34; }}\u0026#34;\u0026gt; \u0026lt;head\u0026gt; \u0026lt;meta charset=\u0026#34;UTF-8\u0026#34;\u0026gt; \u0026lt;meta name=\u0026#34;viewport\u0026#34; content=\u0026#34;width=device-width, initial-scale=1.0\u0026#34;\u0026gt; \u0026lt;title\u0026gt;{{ block \u0026#34;title\u0026#34; . }}{{ .Site.Title }}{{ end }}\u0026lt;/title\u0026gt; {{/* Блок для заголовка страницы */}} \u0026lt;link rel=\u0026#34;stylesheet\u0026#34; href=\u0026#34;/css/style.css\u0026#34;\u0026gt; {{ block \u0026#34;head_extra\u0026#34; . }}{{ end }} {{/* Блок для дополнительных стилей/скриптов в head */}} \u0026lt;/head\u0026gt; \u0026lt;body\u0026gt; \u0026lt;header\u0026gt; \u0026lt;h1\u0026gt;\u0026lt;a href=\u0026#34;{{ .Site.BaseURL }}\u0026#34;\u0026gt;{{ .Site.Title }}\u0026lt;/a\u0026gt;\u0026lt;/h1\u0026gt; \u0026lt;nav\u0026gt; {{/* Тут может быть меню, например, через partial */}} {{ partial \u0026#34;nav.html\u0026#34; . }} \u0026lt;/nav\u0026gt; \u0026lt;/header\u0026gt; \u0026lt;main\u0026gt; {{ block \u0026#34;main\u0026#34; . }} {{/* Сюда будет вставляться основное содержимое страницы */}} \u0026lt;p\u0026gt;Это содержимое по умолчанию, если блок \u0026#39;main\u0026#39; не определен.\u0026lt;/p\u0026gt; {{ end }} \u0026lt;/main\u0026gt; \u0026lt;footer\u0026gt; \u0026lt;p\u0026gt;\u0026amp;copy; {{ now.Format \u0026#34;2006\u0026#34; }} {{ .Site.Title }}. {{ T \u0026#34;all_rights_reserved\u0026#34; }}\u0026lt;/p\u0026gt; {{ block \u0026#34;footer_extra\u0026#34; . }}{{ end }} {{/* Блок для доп. контента в футере */}} \u0026lt;/footer\u0026gt; {{ block \u0026#34;scripts_extra\u0026#34; . }}{{ end }} {{/* Блок для скриптов в конце body */}} \u0026lt;/body\u0026gt; \u0026lt;/html\u0026gt; Разберем по частям:\n{{ block \u0026quot;имя_блока\u0026quot; . }} ... {{ end }}: Так объявляется блок. \u0026quot;имя_блока\u0026quot;: Уникальное имя блока (например, \u0026ldquo;title\u0026rdquo;, \u0026ldquo;main\u0026rdquo;, \u0026ldquo;head_extra\u0026rdquo;). .: Передаем текущий контекст (точку) внутрь блока. Это важно, чтобы в переопределенном блоке были доступны переменные вроде .Title, .Content и т.д. Содержимое между {{ block ... }} и {{ end }} – это содержимое по умолчанию. Оно будет выведено, если более специфичный шаблон не переопределит этот блок. Как теперь конкретные шаблоны (например, single.html) используют этот baseof.html?\nОни просто определяют (define) содержимое для этих блоков.\nПример layouts/_default/single.html (для одиночной страницы):\n{{/* Этот шаблон будет использовать layouts/_default/baseof.html */}} {{ define \u0026#34;title\u0026#34; }} {{ .Title }} – {{ .Site.Title }} {{/* Переопределяем заголовок для одиночной страницы */}} {{ end }} {{ define \u0026#34;main\u0026#34; }} \u0026lt;article\u0026gt; \u0026lt;h2\u0026gt;{{ .Title }}\u0026lt;/h2\u0026gt; {{ if .Params.subtitle }} \u0026lt;h3\u0026gt;{{ .Params.subtitle }}\u0026lt;/h3\u0026gt; {{ end }} \u0026lt;p class=\u0026#34;meta\u0026#34;\u0026gt;Опубликовано: {{ .Date.Format \u0026#34;02 January 2006\u0026#34; }} {{ with .Params.author }} | Автор: {{ . }}{{ end }} \u0026lt;/p\u0026gt; \u0026lt;div class=\u0026#34;content\u0026#34;\u0026gt; {{ .Content }} {{/* Основной контент страницы */}} \u0026lt;/div\u0026gt; {{ if .Params.tags }} \u0026lt;div class=\u0026#34;tags\u0026#34;\u0026gt; \u0026lt;strong\u0026gt;Теги:\u0026lt;/strong\u0026gt; {{ range .Params.tags }} \u0026lt;a href=\u0026#34;{{ \u0026#34;/tags/\u0026#34; | relLangURL }}{{ . | urlize }}\u0026#34;\u0026gt;{{ . }}\u0026lt;/a\u0026gt; {{ end }} \u0026lt;/div\u0026gt; {{ end }} \u0026lt;/article\u0026gt; {{ end }} {{ define \u0026#34;scripts_extra\u0026#34; }} {{/* Сюда можно добавить скрипты, нужные только для одиночных страниц */}} {{ end }} Что происходит:\nHugo видит, что для отображения одиночной страницы нужно использовать single.html. Он также видит, что существует baseof.html (например, в layouts/_default/). Он берет baseof.html за основу. Затем он ищет в single.html определения блоков ({{ define \u0026quot;имя_блока\u0026quot; }} ... {{ end }}). Если блок определен в single.html (например, {{ define \u0026quot;main\u0026quot; }}), то его содержимое вставляется вместо одноименного блока в baseof.html. Если какой-то блок из baseof.html не определен в single.html (например, мы не определили {{ define \u0026quot;footer_extra\u0026quot; }} в нашем single.html), то будет использовано содержимое по умолчанию из baseof.html. Порядок поиска baseof.html (Lookup Order):\nHugo ищет baseof.html в определенном порядке, чтобы обеспечить максимальную гибкость:\nlayouts/\u0026lt;TYPE\u0026gt;/\u0026lt;LAYOUT\u0026gt;-baseof.html (например, layouts/posts/single-baseof.html) layouts/\u0026lt;TYPE\u0026gt;/baseof.html (например, layouts/posts/baseof.html) layouts/_default/\u0026lt;LAYOUT\u0026gt;-baseof.html (например, layouts/_default/single-baseof.html) layouts/_default/baseof.html (самый общий) То же самое в папке темы, если используется тема. Это означает, что ты можешь иметь один общий baseof.html для всего сайта, а потом, если нужно, переопределить его для конкретного типа контента (например, для постов блога сделать другой сайдбар) или даже для конкретного макета.\nИспользование baseof.html и блоков – это ключевой момент для создания поддерживаемых и чистых тем в Hugo. Один раз настроил каркас – и потом только наполняешь специфичные блоки. Красота!\nРаз с базой разобрались, давай посмотрим, как эта база наполняется для разных типов страниц. Начнем со страниц, которые показывают списки чего-либо.\nСписковые страницы (индексы, категории, теги и т.д.) Раз с базой разобрались, давай посмотрим, как эта база наполняется для разных типов страниц. Начнем со страниц, которые показывают списки чего-либо.\nСписковые страницы (List Pages) в Hugo – это страницы, которые отображают коллекцию других страниц. Это могут быть:\nГлавная страница сайта (Homepage): Отображает, например, последние посты. Страницы разделов (Sections): Например, /posts/ (список всех постов) или /projects/ (список всех проектов). Создаются автоматически, если у тебя есть папки content/posts/ или content/projects/. Страницы таксономий (Taxonomy Terms): Например, /categories/ (список всех категорий) или /tags/ (список всех тегов). Страницы конкретных терминов таксономий (Taxonomy Term Lists): Например, /categories/технологии/ (список всех постов в категории \u0026ldquo;Технологии\u0026rdquo;) или /tags/hugo/ (список всех постов с тегом \u0026ldquo;hugo\u0026rdquo;). Для всех этих типов страниц Hugo использует шаблоны списков.\nКак Hugo выбирает шаблон для списковой страницы (Lookup Order):\nHugo – парень предсказуемый и ищет шаблоны в строгом порядке. Для списковых страниц он будет искать примерно так (упрощенно, для примера секции posts):\nlayouts/section/posts.html (специфичный для секции \u0026ldquo;posts\u0026rdquo;) layouts/posts/list.html (тоже специфичный для \u0026ldquo;posts\u0026rdquo;, альтернативное имя) layouts/_default/list.html (дефолтный шаблон для всех списков, если ничего специфичного не найдено) layouts/_default/section.html (дефолтный шаблон для секций, если list.html нет) То же самое в папке активной темы, если ты ее используешь, причем шаблоны в корневом layouts/ имеют приоритет над шаблонами темы. Для главной страницы есть свой порядок (index.html, home.html). Для таксономий – свой (например, layouts/taxonomy/tag.html для списка постов с тегом, layouts/taxonomy/tag.terms.html для списка всех тегов). Суть одна: от более специфичного к более общему.\nКлючевые переменные и что с ними делать в list.html:\nВнутри шаблона списковой страницы (например, layouts/_default/list.html), который, напомню, обычно расширяет baseof.html через {{ define \u0026quot;main\u0026quot; }}, тебе доступны:\n.Title: Заголовок списка (например, \u0026ldquo;Posts\u0026rdquo; или \u0026ldquo;Категория: Технологии\u0026rdquo;). .Permalink или .RelPermalink: Ссылка на эту списковую страницу. .Data.Pages или просто .Pages: Коллекция страниц, принадлежащих этому списку. Это то, что мы будем перебирать. Часто используют .Site.RegularPages (все обычные страницы сайта) или .Paginator.Pages (если используется пагинация). .Paginator: Объект пагинатора, если ты настроил пагинацию для списка. Позволяет выводить ссылки \u0026ldquo;Следующая страница\u0026rdquo;, \u0026ldquo;Предыдущая страница\u0026rdquo; и т.д. .Content: Если для этой списковой страницы есть файл _index.md (например, content/posts/_index.md), то его содержимое будет доступно тут. Это позволяет добавить описание или какой-то вводный текст на страницу раздела или таксономии. Пример простого layouts/_default/list.html:\n{{ define \u0026#34;title\u0026#34; }} {{ .Title }} - {{ .Site.Title }} {{ end }} {{ define \u0026#34;main\u0026#34; }} \u0026lt;div class=\u0026#34;list-page\u0026#34;\u0026gt; \u0026lt;h2\u0026gt;{{ .Title }}\u0026lt;/h2\u0026gt; {{/* Если есть контент из _index.md, выводим его */}} {{ if .Content }} \u0026lt;div class=\u0026#34;list-description\u0026#34;\u0026gt; {{ .Content }} \u0026lt;/div\u0026gt; {{ end }} {{/* Перебираем страницы в этом списке */}} {{ $pages := .Pages }} {{/* Если используем пагинацию, то берем страницы из пагинатора */}} {{ if .Paginator }} {{ $pages = .Paginator.Pages }} {{ end }} {{ if $pages }} \u0026lt;ul class=\u0026#34;post-list\u0026#34;\u0026gt; {{ range $pages }} \u0026lt;li\u0026gt; \u0026lt;h3\u0026gt;\u0026lt;a href=\u0026#34;{{ .RelPermalink }}\u0026#34;\u0026gt;{{ .Title }}\u0026lt;/a\u0026gt;\u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;meta\u0026#34;\u0026gt; {{ .Date.Format \u0026#34;02 Jan 2006\u0026#34; }} {{ with .Params.author }} | Автор: {{ . }}{{ end }} \u0026lt;/p\u0026gt; {{/* Можно вывести краткое содержание, если есть */}} {{ .Summary }} {{ if .Truncated }} \u0026lt;a href=\u0026#34;{{ .RelPermalink }}\u0026#34;\u0026gt;Читать дальше…\u0026lt;/a\u0026gt; {{ end }} \u0026lt;/li\u0026gt; {{ end }} \u0026lt;/ul\u0026gt; {{ else }} \u0026lt;p\u0026gt;Здесь пока ничего нет.\u0026lt;/p\u0026gt; {{ end }} {{/* Вывод пагинации, если она есть */}} {{ if .Paginator }} {{ template \u0026#34;_internal/pagination.html\u0026#34; . }} {{ end }} \u0026lt;/div\u0026gt; {{ end }} Разберем интересные моменты:\n{{ if .Content }}: Проверяем, есть ли у списковой страницы свой контент (из _index.md). {{ $pages := .Pages }}: Присваиваем коллекцию страниц переменной $pages. {{ if .Paginator }}: Если для этого списка настроена пагинация (обычно в hugo.toml), то .Paginator будет доступен. Мы берем страницы из .Paginator.Pages – это страницы для текущей \u0026ldquo;порции\u0026rdquo; пагинации. {{ range $pages }}: Перебираем наши страницы. Внутри этого цикла точка . становится текущей страницей из списка, поэтому мы можем использовать {{ .RelPermalink }}, {{ .Title }}, {{ .Date }}, {{ .Summary }}. .Summary: Hugo автоматически генерирует краткое содержание поста. По умолчанию это первые 70 слов контента. Можно настроить или указать разделитель `` в Markdown. .Truncated: Булево значение, true если .Summary был усечен (т.е. есть что \u0026ldquo;читать дальше\u0026rdquo;). {{ template \u0026quot;_internal/pagination.html\u0026quot; . }}: Hugo поставляется с внутренним шаблоном для пагинации. Его можно использовать, чтобы не писать логику кнопок \u0026ldquo;вперед/назад\u0026rdquo; самому. Ему нужно передать текущий контекст пагинатора (точку . в данном месте). Про _index.md:\nДля страниц секций (например, content/posts/) или страниц таксономий ты можешь создать файл _index.md (например, content/posts/_index.md). В этом файле ты можешь указать Front Matter (например, title, description для этой страницы списка) и написать какой-то контент, который будет выведен над списком постов.\nПример content/posts/_index.md:\n--- title: \u0026#34;Все Записи Нашего Блога\u0026#34; description: \u0026#34;Здесь собраны самые свежие и интересные статьи о всякой всячине.\u0026#34; # Можно даже указать свой layout для этой страницы списка, если надо # layout: \u0026#34;my_custom_posts_list\u0026#34; --- Добро пожаловать в наш блог! Мы стараемся писать о технологиях, разработке и иногда о котиках. Надеемся, вы найдете здесь что-то полезное для себя. Этот title будет использован как {{ .Title }} на странице /posts/, а текст ниже – как {{ .Content }}.\nСписковые страницы – это основа навигации по твоему сайту. Понимание того, как они работают и как их кастомизировать, очень важно.\nДальше посмотрим на антипода списковых страниц – на страницы, которые отображают одну-единственную единицу контента. То есть, на одиночные страницы.\nОдиночные страницы (деталка поста/страницы) Сейчас разберем, как показывать твой контент во всей красе – одну конкретную статью, новость или страницу \u0026ldquo;о себе, любимом\u0026rdquo;.\nОдиночные страницы (Single Pages) – это, как ты уже догадался, страницы, которые отображают одну конкретную единицу контента. Это может быть:\nПост в блоге (content/posts/my-awesome-post.md) Страница проекта (content/projects/super-duper-app.md) Страница \u0026ldquo;О нас\u0026rdquo; (content/about.md) Любой другой материал, который не является списком. Именно на этих страницах твои пользователи будут проводить больше всего времени, читая то, что ты там наваял. Так что к их оформлению надо подойти с душой.\nКак Hugo выбирает шаблон для одиночной страницы (Lookup Order):\nАналогично списковым страницам, Hugo ищет шаблон для одиночной страницы по строгому порядку. Допустим, у тебя есть пост content/posts/my-post.md (тип posts, секция posts). Hugo будет искать шаблон так:\nlayouts/posts/my-post.html (шаблон специально для этого конкретного файла – используется редко, но возможность есть) layouts/posts/single.html (шаблон для всех одиночных страниц типа posts) layouts/_default/single.html (дефолтный шаблон для всех одиночных страниц, если ничего более специфичного не найдено) То же самое в папке активной темы, с тем же приоритетом корневых layouts/. Обычно ты будешь работать либо с layouts/ТИП_КОНТЕНТА/single.html (если у тебя разные типы контента требуют сильно разного оформления), либо с общим layouts/_default/single.html.\nКлючевые переменные, доступные в single.html:\nВнутри single.html (который, как ты помнишь, обычно вставляет свое содержимое в блок main из baseof.html), точка . ссылается на текущую страницу, и тебе доступны все её атрибуты и содержимое:\n.Title: Заголовок страницы из Front Matter. .Content: Основное содержимое страницы, уже сконвертированное из Markdown в HTML. Это самое главное. .Date: Дата публикации из Front Matter. .Lastmod: Дата последнего изменения файла (если GitInfo включен, то из коммита, иначе – время модификации файла). .PublishDate: Дата, с которой публикация разрешена. .ExpiryDate: Дата, после которой публикация скрывается. .Permalink / .RelPermalink: Абсолютная / относительная постоянная ссылка на страницу. .Params: Объект со всеми твоими кастомными параметрами из Front Matter (.Params.имя_параметра). .WordCount: Количество слов в .Content. .ReadingTime: Примерное время чтения (в минутах). .TableOfContents: HTML-код оглавления, сгенерированный из заголовков (##, ### и т.д.) твоего Markdown. Полезно для длинных статей. Глубину и заголовки можно настраивать в hugo.toml. .Summary: Краткое содержание (на одиночных страницах тоже доступно, хотя чаще используется в списках). .Keywords: Массив ключевых слов из Front Matter. .Draft: true, если страница – черновик. .Type: Тип контента (например, \u0026ldquo;posts\u0026rdquo;). .Section: Секция, к которой принадлежит страница (например, \u0026ldquo;posts\u0026rdquo;). .PrevInSection: Ссылка на предыдущую страницу в той же секции (по дате или весу). .NextInSection: Ссылка на следующую страницу в той же секции. .Prev: Предыдущая страница (глобально, по дате). .Next: Следующая страница (глобально, по дате). И еще куча всего. Смотри в доках Hugo по \u0026ldquo;Page Variables\u0026rdquo;. Пример простого layouts/_default/single.html:\n{{ define \u0026#34;title\u0026#34; }} {{ .Title }} – {{ .Site.Title }} {{ end }} {{ define \u0026#34;main\u0026#34; }} \u0026lt;article class=\u0026#34;single-post\u0026#34;\u0026gt; \u0026lt;header class=\u0026#34;post-header\u0026#34;\u0026gt; \u0026lt;h1\u0026gt;{{ .Title }}\u0026lt;/h1\u0026gt; {{ with .Params.subtitle }} \u0026lt;p class=\u0026#34;subtitle\u0026#34;\u0026gt;{{ . }}\u0026lt;/p\u0026gt; {{ end }} \u0026lt;div class=\u0026#34;post-meta\u0026#34;\u0026gt; \u0026lt;span\u0026gt;Опубликовано: {{ .Date.Format \u0026#34;02 January 2006\u0026#34; }}\u0026lt;/span\u0026gt; {{ with .Params.author }} \u0026lt;span\u0026gt; | Автор: {{ . }}\u0026lt;/span\u0026gt; {{ end }} \u0026lt;span\u0026gt; | Время чтения: {{ .ReadingTime }} мин. ({{ .WordCount }} слов)\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; {{ with .Params.featured_image }} \u0026lt;img src=\u0026#34;{{ . | relURL }}\u0026#34; alt=\u0026#34;{{ $.Title }}\u0026#34; class=\u0026#34;featured-image\u0026#34;\u0026gt; {{ end }} \u0026lt;/header\u0026gt; {{ if .Site.Params.showTableOfContents | and .TableOfContents }} {{/* Показать оглавление, если включено в конфиге и есть что показывать */}} \u0026lt;aside class=\u0026#34;table-of-contents\u0026#34;\u0026gt; \u0026lt;h3\u0026gt;Оглавление:\u0026lt;/h3\u0026gt; {{ .TableOfContents }} \u0026lt;/aside\u0026gt; {{ end }} \u0026lt;div class=\u0026#34;post-content\u0026#34;\u0026gt; {{ .Content }} \u0026lt;/div\u0026gt; {{ if .Params.tags }} \u0026lt;footer class=\u0026#34;post-footer\u0026#34;\u0026gt; \u0026lt;div class=\u0026#34;tags\u0026#34;\u0026gt; \u0026lt;strong\u0026gt;Теги:\u0026lt;/strong\u0026gt; {{ range .Params.tags }} \u0026lt;a href=\u0026#34;{{ \u0026#34;/tags/\u0026#34; | relLangURL }}{{ . | urlize }}\u0026#34;\u0026gt;{{ . }}\u0026lt;/a\u0026gt; {{ end }} \u0026lt;/div\u0026gt; \u0026lt;/footer\u0026gt; {{ end }} {{/* Навигация \u0026#34;Предыдущий/Следующий пост\u0026#34; в этой же секции */}} \u0026lt;nav class=\u0026#34;post-navigation\u0026#34;\u0026gt; {{ with .PrevInSection }} \u0026lt;a href=\u0026#34;{{ .RelPermalink }}\u0026#34; class=\u0026#34;prev-post\u0026#34;\u0026gt;\u0026amp;laquo; Предыдущий: {{ .Title }}\u0026lt;/a\u0026gt; {{ end }} {{ with .NextInSection }} \u0026lt;a href=\u0026#34;{{ .RelPermalink }}\u0026#34; class=\u0026#34;next-post\u0026#34;\u0026gt;Следующий: {{ .Title }} \u0026amp;raquo;\u0026lt;/a\u0026gt; {{ end }} \u0026lt;/nav\u0026gt; \u0026lt;/article\u0026gt; {{ end }} Что тут интересного:\n{{ with .Params.subtitle }}: Элегантно выводим подзаголовок, только если он есть в Front Matter. .Date.Format \u0026quot;02 January 2006\u0026quot;: Форматируем дату по-человечески. Строка формата – это специфичный для Go способ указания формата (используется эталонная дата Mon Jan 2 15:04:05 MST 2006). {{ .ReadingTime }} и {{ .WordCount }}: Полезная мелочь для читателей. {{ .Params.featured_image | relURL }}: Если в Front Matter есть featured_image с путем к картинке, выводим ее. relURL делает URL относительным к корню сайта. {{ if .Site.Params.showTableOfContents | and .TableOfContents }}: Оглавление показывается, только если в глобальном конфиге сайта (hugo.toml) есть параметр showTableOfContents = true и на текущей странице есть что включать в оглавление (.TableOfContents не пустое). {{ .Content }}: Вот сюда и выводится весь твой отформатированный HTML из Markdown-файла. Навигация {{ .PrevInSection }} и {{ .NextInSection }} позволяет легко переходить между статьями одного раздела. Шаблон single.html – это то место, где ты можешь развернуться и сделать страницу своего контента максимально удобной и информативной. Тут можно добавлять комментарии (через Disqus, Staticman или другие сервисы), кнопки \u0026ldquo;поделиться\u0026rdquo;, информацию об авторе, связанные посты и многое другое.\nВ общем, как видишь, и списковые, и одиночные страницы строятся по схожим принципам: наследуют baseof.html и заполняют его блоки специфичным для себя контентом, используя доступные переменные страницы.\nТеперь, когда мы знаем, как делать страницы целиком, самое время поговорить о маленьких переиспользуемых кусочках HTML, которые можно вставлять где угодно.\nPartials (переиспользуемые куски кода) Вижу, ты уже в нетерпении. Ну правильно, сейчас будем говорить о том, как не превращать свои шаблоны в спагетти-код, а делать их аккуратными и модульными. Речь пойдет о partials, или, как мы их в шутку тут обозначили, о \u0026ldquo;переиспользуемых кусках кода\u0026rdquo;. Иногда, конечно, если криво сделать, то и до \u0026ldquo;кусков говна\u0026rdquo; недалеко, но мы-то с тобой инженеры, сделаем как надо.\nPartials (частичные шаблоны) – это небольшие, самостоятельные фрагменты HTML-кода (с логикой Go Templates, разумеется), которые ты можешь вставлять в другие, более крупные шаблоны (baseof.html, single.html, list.html и даже в другие partials).\nНа кой хрен они нужны?\nDRY, опять он, родимый. Если у тебя есть кусок кода, который повторяется на разных страницах или в разных частях сайта (например, шапка, подвал, навигационное меню, блок с иконками соцсетей, код Google Analytics), ты выносишь его в partial и вставляешь одной строкой там, где нужно. Изменил в одном месте – изменилось везде. Чистота, порядок, экономия времени. Организация и читаемость. Большие шаблоны становятся трудночитаемыми. Разбив их на логические partials, ты делаешь код более структурированным и понятным. Легче найти, что где лежит и за что отвечает. Компоненты. Partials – это, по сути, твои маленькие компоненты. Ты можешь сделать partial для карточки поста, для кнопки, для формы подписки – для чего угодно. Где они лежат и как их создавать?\nВсе partials живут в папке layouts/partials/. Ты можешь создавать там подпапки для лучшей организации, если partials становится много. Например:\nlayouts/partials/header.html layouts/partials/footer.html layouts/partials/sidebar.html layouts/partials/widgets/social-icons.html layouts/partials/analytics/google-analytics.html Имена файлов произвольные, но обычно отражают суть partial.\nКак их вызывать (вставлять в другие шаблоны)?\nДля этого есть две основные функции:\n{{ partial \u0026quot;имя_файла.html\u0026quot; . }} {{ partialCached \u0026quot;имя_файла.html\u0026quot; . \u0026quot;уникальный_ключ_кэширования\u0026quot; [аргументы_для_ключа] }} Разберем partial:\n\u0026quot;имя_файла.html\u0026quot;: Путь к файлу partial относительно папки layouts/partials/. Если у тебя layouts/partials/widgets/social-icons.html, то вызывать будешь так: {{ partial \u0026quot;widgets/social-icons.html\u0026quot; . }}. .: Это контекст (точка), который ты передаешь внутрь partial. Это очень важный момент! Если ты передаешь . (текущий контекст), то внутри partial точка . будет такой же, как и в том месте, откуда ты его вызвал. То есть, если ты из single.html (где . это текущая страница) вызываешь {{ partial \u0026quot;my-partial.html\u0026quot; . }}, то в my-partial.html ты сможешь использовать {{ .Title }}, {{ .Content }}, {{ .Params }} и т.д., относящиеся к этой странице. Ты можешь передать и другой контекст. Например, {{ partial \u0026quot;site-data.html\u0026quot; .Site }} – тогда внутри site-data.html точка . будет ссылаться на глобальный объект .Site. Можно передать кастомный контекст, созданный с помощью функции dict: {{ $customData := dict \u0026#34;greeting\u0026#34; \u0026#34;Привет, инженер!\u0026#34; \u0026#34;pageTitle\u0026#34; .Title }} {{ partial \u0026#34;custom-greeting.html\u0026#34; $customData }} Тогда в custom-greeting.html ты сможешь обратиться к {{ .greeting }} и {{ .pageTitle }}. Пример: Partial для иконок соцсетей\nСоздадим файл layouts/partials/social-icons.html:\n{{/* layouts/partials/social-icons.html */}} {{/* Ожидаем, что в .Site.Params есть секция social с нужными ссылками */}} {{ with .Site.Params.social }} \u0026lt;div class=\u0026#34;social-icons\u0026#34;\u0026gt; {{ range $platform, $url := . }} {{ if $url }} {{/* Проверяем, что URL не пустой */}} \u0026lt;a href=\u0026#34;{{ $url }}\u0026#34; target=\u0026#34;_blank\u0026#34; rel=\u0026#34;noopener noreferrer\u0026#34; aria-label=\u0026#34;{{ $platform | humanize }}\u0026#34;\u0026gt; {{/* Здесь можно использовать SVG иконки или шрифтовые иконки */}} {{/* Для простоты просто напишем название платформы */}} \u0026lt;span class=\u0026#34;icon-{{ $platform }}\u0026#34;\u0026gt;{{ $platform | humanize }}\u0026lt;/span\u0026gt; \u0026lt;/a\u0026gt; {{ end }} {{ end }} \u0026lt;/div\u0026gt; {{ end }} Предположим, в hugo.toml у тебя есть:\n[params.social] twitter = \u0026#34;https://twitter.com/yourprofile\u0026#34; github = \u0026#34;https://github.com/yourprofile\u0026#34; linkedin = \u0026#34;https://linkedin.com/in/yourprofile\u0026#34; email = \u0026#34;mailto:you@example.com\u0026#34; Теперь в layouts/_default/baseof.html (например, в футере) ты можешь вставить эти иконки:\n{{/* ... остальной код baseof.html ... */}} \u0026lt;footer\u0026gt; \u0026lt;p\u0026gt;\u0026amp;copy; {{ now.Format \u0026#34;2006\u0026#34; }} {{ .Site.Title }}\u0026lt;/p\u0026gt; {{ partial \u0026#34;social-icons.html\u0026#34; . }} {{/* Передаем текущий контекст, из которого partial сможет взять .Site */}} \u0026lt;/footer\u0026gt; {{/* ... */}} Про partialCached:\nЕсли у тебя есть partial, который генерирует один и тот же HTML для разных страниц (или для одной и той же страницы, но вызывается много раз) и не зависит от сильно меняющегося контекста, используй {{ partialCached }}. Он кэширует результат работы partial и отдает его из кэша при последующих вызовах с тем же ключом. Это может дать хороший прирост производительности на больших сайтах.\n{{ partialCached \u0026#34;my-complex-widget.html\u0026#34; . .RelPermalink }} Здесь .RelPermalink используется как часть ключа кэширования. Если виджет для каждой страницы свой, то кэш будет для каждой страницы. Если виджет один на весь сайт, можно использовать что-то вроде {{ partialCached \u0026quot;my-global-widget.html\u0026quot; .Site \u0026quot;global-widget-key\u0026quot; }}. Аргументы для ключа кэширования (variants) должны быть простыми типами.\nИтого по partials:\nЭто твои строительные блоки. Помогают не повторяться и структурировать код. Внимательно следи за контекстом (.), который ты в них передаешь. Используй partialCached для часто вызываемых и не слишком динамичных кусков. Partials делают жизнь разработчика темы для Hugo гораздо проще и приятнее. Без них ты бы утонул в копипасте и сломал бы себе все пальцы, внося одинаковые правки в десятки файлов.\nНу что, теперь ты знаешь, как строить каркас (baseof.html), как наполнять его для списков (list.html) и одиночек (single.html), и как использовать маленькие кирпичики (partials). Осталось разобраться, какие данные тебе вообще доступны из коробки в этих шаблонах. Это про встроенные переменные.\nВстроенные переменные Hugo (.Page, .Site – что доступно из коробки) Под конец этого раздела про шаблоны давай разберем, какими боеприпасами тебя снабжает Hugo из коробки. То есть, какие встроенные переменные ты можешь использовать, чтобы творить свои шедевры.\nКогда ты колдуешь в шаблоне, Hugo предоставляет тебе кучу полезной информации через так называемые \u0026ldquo;переменные\u0026rdquo;. Две самые главные, которые ты будешь использовать постоянно, это .Page и .Site. Ну и помни про \u0026ldquo;точку\u0026rdquo; (.) – часто она сама по себе является ссылкой на .Page (например, в single.html или list.html для самой списковой страницы).\n1. .Site – Информация обо всем сайте\nОбъект .Site – это твой главный штаб, хранилище глобальной информации о сайте. Он доступен практически в любом месте шаблона. Что в нем полезного:\n.Site.Title: Главный заголовок твоего сайта (из hugo.toml -\u0026gt; title). .Site.BaseURL: Базовый URL сайта (из hugo.toml -\u0026gt; baseURL). Важно для построения правильных ссылок. .Site.Params: Объект со всеми глобальными кастомными параметрами, которые ты задал в hugo.toml в секции [params]. Например, {{ .Site.Params.myGlobalSetting }}. .Site.Copyright: Копирайт (из hugo.toml -\u0026gt; copyright). .Site.LanguageCode: Код языка сайта (из hugo.toml -\u0026gt; languageCode). .Site.Language: Объект с информацией о текущем языке (если сайт мультиязычный). .Site.Menus: Доступ ко всем меню, определенным в hugo.toml или в Front Matter страниц. Например, {{ range .Site.Menus.main }}\u0026lt;li\u0026gt;\u0026lt;a href=\u0026quot;{{ .URL }}\u0026quot;\u0026gt;{{ .Name }}\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt;{{ end }}. .Site.Pages: Коллекция всех страниц на сайте (включая посты, списки, таксономии и т.д.). .Site.RegularPages: Более полезная коллекция – все \u0026ldquo;обычные\u0026rdquo; страницы, то есть те, у которых есть контент и которые не являются списками или таксономиями. Обычно это то, что ты хочешь вывести в списках \u0026ldquo;все посты\u0026rdquo;. .Site.Sections: Список всех секций первого уровня (например, posts, projects). .Site.Taxonomies: Объект со всеми таксономиями. Например, {{ range .Site.Taxonomies.tags }} чтобы перебрать все теги. .Site.Data: Доступ к данным из папки data/. Если у тебя есть data/authors.yaml, то ты можешь получить к нему доступ через {{ .Site.Data.authors }}. .Site.Lastmod (или .Site.LastChange в старых версиях): Дата последнего изменения на сайте (если Hugo может ее определить, обычно из Git). .Site.Config: Доступ ко всей конфигурации сайта (включая params). .Site.BuildDate: Время сборки сайта. Короче, .Site – это твой глобальный справочник.\n2. .Page – Информация о текущей странице\nОбъект .Page (или просто . в большинстве контекстов одиночных и списковых страниц) содержит всю информацию о текущей странице, которую Hugo в данный момент обрабатывает и рендерит.\nМногие из этих полей мы уже упоминали, когда говорили про single.html и list.html, но давай их систематизируем:\nОсновные:\n.Page.Title: Заголовок страницы. .Page.Content: HTML-содержимое страницы (из Markdown). .Page.Permalink: Абсолютная ссылка на страницу. .Page.RelPermalink: Относительная ссылка на страницу (предпочтительнее для внутренних ссылок). .Page.Date: Основная дата страницы (обычно дата публикации). .Page.Lastmod: Дата последнего изменения. .Page.PublishDate, .Page.ExpiryDate: Даты для управления видимостью. .Page.Description: Описание (часто из Front Matter, полезно для SEO). .Page.Keywords: Ключевые слова (массив). .Page.Summary: Автоматически сгенерированное или вручную указанное краткое содержание. .Page.Truncated: true, если .Summary был усечен. Метаданные и параметры:\n.Page.Params: Объект со всеми кастомными параметрами из Front Matter этой страницы. Например, {{ .Page.Params.featured_image }}. .Page.Draft: true, если страница – черновик. .Page.Type: Тип контента (например, posts). Определяется папкой или Front Matter. .Page.Section: Секция, к которой принадлежит страница (например, posts). .Page.Slug: Часть URL, если указана в Front Matter. .Page.Weight: Вес для сортировки. .Page.File: Информация о файле-источнике (.Page.File.Path, .Page.File.BaseFileName и т.д.). Информация о контенте:\n.Page.WordCount: Количество слов. .Page.ReadingTime: Примерное время чтения. .Page.TableOfContents: HTML-код оглавления. Классификация и навигация (.Kind – очень важно!):\n.Page.Kind: Строка, определяющая \u0026ldquo;тип\u0026rdquo; страницы с точки зрения Hugo. Может быть:\n\u0026quot;page\u0026quot;: Обычная контентная страница (например, пост блога, страница \u0026ldquo;О нас\u0026rdquo;). \u0026quot;home\u0026quot;: Главная страница сайта. \u0026quot;section\u0026quot;: Страница раздела (например, /posts/). \u0026quot;taxonomy\u0026quot;: Страница списка всех терминов одной таксономии (например, /tags/). \u0026quot;taxonomyTerm\u0026quot;: Страница списка контента для одного термина таксономии (например, /tags/hugo/). \u0026quot;RSS\u0026quot;, \u0026quot;sitemap\u0026quot;, \u0026quot;robotsTXT\u0026quot;, \u0026quot;404\u0026quot; - для соответствующих специфических файлов. Значение .Page.Kind очень полезно для написания условной логики в шаблонах, особенно в baseof.html или в partials, чтобы отображать разные элементы для разных типов страниц (например, хлебные крошки). .Page.IsHome: true, если это главная страница (.Page.Kind == \u0026quot;home\u0026quot;).\n.Page.IsPage: true, если это обычная контентная страница (.Page.Kind == \u0026quot;page\u0026quot;).\n.Page.IsSection: true, если это страница раздела (.Page.Kind == \u0026quot;section\u0026quot;).\n.Page.Parent: Родительская страница (например, для поста это будет страница его секции).\n.Page.Sections: Список дочерних секций (если текущая страница сама является секцией).\n.Page.Pages: На списковых страницах (list.html, home.html) это коллекция дочерних страниц.\n.Page.RegularPages: На списковых страницах коллекция дочерних \u0026ldquo;обычных\u0026rdquo; страниц.\n.Page.Paginator: Объект пагинатора, если он используется для этой страницы.\n.Page.Prev, .Page.Next: Предыдущая/следующая страница (глобально).\n.Page.PrevInSection, .Page.NextInSection: Предыдущая/следующая страница в той же секции.\nЭто далеко не все, но это основной джентльменский набор, который тебе понадобится в 99% случаев. За полным списком и деталями всегда можно (и нужно!) обращаться к официальной документации Hugo по переменным (Page Variables и Site Variables). Она там довольно подробная.\nВажно помнить: Содержимое .Page (и соответственно, просто .) меняется в зависимости от того, какую страницу Hugo рендерит. Внутри range .Site.RegularPages точка . будет ссылаться на очередную страницу из этого списка, а не на ту, на которой этот список выводится. Это основы работы с контекстом в Go Templates.\nНа этом с основами шаблонизации, пожалуй, всё. Ты теперь знаешь, из чего состоит тема Hugo, как работают шаблоны, какие данные в них доступны. Можно сказать, прошел курс молодого бойца по HTML-верстке под Hugo.\nКак ощущения? Голова не кипит? Дальше по плану у нас конфигурация проекта, будем ковыряться в hugo.toml.\n5. Конфигурация – рулим всем из одного места Переходим к пульту управления твоего сайта – файлу конфигурации. Тут ты будешь задавать основные правила игры.\nЕсли шаблоны – это лицо сайта, а контент – его душа, то файл конфигурации – это его мозг и нервная система. Здесь ты определяешь глобальные настройки, подключаешь темы, настраиваешь меню и многое другое.\nФайл конфигурации (hugo.toml или config.toml/yaml/json) – сердце проекта. Hugo очень гибкий в плане формата конфига. Раньше по умолчанию был config.toml, но сейчас Hugo активно продвигает hugo.toml как основной файл конфигурации. Ты также можешь использовать config.yaml или config.json, если тебе эти форматы ближе. Hugo сам разберется.\nМы будем ориентироваться на hugo.toml, так как это новый стандарт. Формат TOML (Tom\u0026rsquo;s Obvious, Minimal Language) довольно простой и читаемый, похож на старые добрые INI-файлы, но с возможностью вложенных структур.\nКомментарии в TOML начинаются с #. Строки заключаются в кавычки. Массивы – [\u0026quot;раз\u0026quot;, \u0026quot;два\u0026quot;]. Таблицы (объекты) – [имя_таблицы], вложенные таблицы [имя_таблицы.подимя]. Файл hugo.toml (или его аналог) лежит в корне твоего проекта.\nДля более сложных проектов Hugo позволяет разносить конфигурацию по папкам. Например, создать директорию config/ и в ней поддиректории для разных окружений:\nconfig/_default/hugo.toml (базовая конфигурация) config/production/hugo.toml (настройки для продакшена, переопределяют или дополняют базовые) config/development/hugo.toml (настройки для локальной разработки) Но для начала нам с головой хватит одного файла hugo.toml в корне.\nОсновные настройки: baseURL, title, languageCode, theme. Давай посмотрим на самые первые и важные строки, которые должны быть в твоем hugo.toml:\n# hugo.toml baseURL = \u0026#34;https://example.com/\u0026#34; # !!! Очень важно для правильных ссылок в продакшене languageCode = \u0026#34;ru-RU\u0026#34; # Язык твоего сайта title = \u0026#34;Мой Охренительный Сайт на Hugo\u0026#34; # Главный заголовок сайта theme = \u0026#34;имя_твоей_темы\u0026#34; # Если используешь готовую тему # Несколько других полезных настроек: paginate = 10 # Количество элементов на странице для списков с пагинацией summaryLength = 70 # Количество слов в автоматически генерируемом .Summary copyright = \u0026#34;© 2025 Суровый Архитектор. Все права защищены.\u0026#34; # Копирайт для футера enableRobotsTXT = true # Сгенерировать robots.txt enableGitInfo = false # Использовать информацию из Git для .Lastmod и .GitInfo (может замедлять сборку) defaultContentLanguage = \u0026#34;ru\u0026#34; # Язык контента по умолчанию (для мультиязычных сайтов) [params] # Сюда можно добавлять свои глобальные параметры, доступные через .Site.Params description = \u0026#34;Самый лучший сайт о всякой всячине, сделанный на Hugo.\u0026#34; author = \u0026#34;Главный Инженер Проекта\u0026#34; Разберем:\nbaseURL: Критически важная настройка. Это корневой URL твоего сайта, когда он будет в интернете. Hugo использует его для генерации всех абсолютных ссылок, RSS-фидов, карты сайта и т.д. Для локальной разработки (hugo server) это значение обычно переопределяется на http://localhost:1313/, но для сборки продакшена (hugo) оно должно быть правильным. Не забудь поменять https://example.com/ на свой реальный домен! languageCode: Код языка в формате IETF BCP 47. Важно для SEO и доступности. title: Отображается в теге \u0026lt;title\u0026gt; браузера, в заголовках и т.д. theme: Если ты скачал готовую тему (например, с themes.gohugo.io) и положил ее в папку themes/, здесь ты указываешь имя папки этой темы. Hugo будет использовать ее шаблоны, ассеты и т.д. Если делаешь свою тему с нуля, эту строку можно пока закомментировать или убрать. paginate: Стандартное количество элементов на страницах списков, где используется пагинация (.Paginator). summaryLength: Длина автоматического резюме поста в словах. copyright: Строка копирайта. Доступна через {{ .Site.Copyright }}. enableRobotsTXT: Если true, Hugo сгенерирует базовый robots.txt. Его можно кастомизировать, создав файл layouts/robots.txt. enableGitInfo: Если true и твой проект находится под Git, Hugo будет пытаться получить дату последнего изменения и другую информацию из Git-коммитов. Это может быть полезно для .Lastmod, но немного замедляет сборку. [params]: Специальная секция для твоих собственных глобальных параметров. Все, что ты определишь здесь, будет доступно в шаблонах через {{ .Site.Params.имя_параметра }}. Очень удобно для настроек, которые не являются стандартными для Hugo, но нужны тебе на сайте (например, ID для аналитики, ссылки на соцсети по умолчанию и т.п.). Это лишь малая часть того, что можно настроить. Полный список смотри в официальной документации Hugo \u0026ldquo;Configure Hugo\u0026rdquo;.\nНастройка меню (главное, боковое, подвальное – какое хочешь). Hugo позволяет легко определять навигационные меню прямо в hugo.toml. Ты можешь создать сколько угодно меню (main, footer, social, sidebar – называй как хочешь).\nСинтаксис для определения меню в hugo.toml:\n[menu] # Общая секция для всех меню [[menu.main]] # Двойные квадратные скобки означают массив элементов. Это определяет меню с именем \u0026#34;main\u0026#34;. name = \u0026#34;Главная\u0026#34; # Текст ссылки pageRef = \u0026#34;/\u0026#34; # Ссылка на внутреннюю страницу (относительно content/) # Hugo найдет страницу (например, _index.md или home.md) и возьмет ее .Permalink weight = 10 # Порядок. Меньше вес = раньше в меню. [[menu.main]] name = \u0026#34;Блог\u0026#34; pageRef = \u0026#34;/posts\u0026#34; # Ссылка на раздел постов weight = 20 [[menu.main]] identifier = \u0026#34;about_us\u0026#34; # Уникальный идентификатор (полезно для CSS или JS) name = \u0026#34;О Нас\u0026#34; url = \u0026#34;/about-me/\u0026#34; # Можно использовать url для фиксированных ссылок (внешних или внутренних) # pageRef более \u0026#34;умный\u0026#34;, т.к. проверяет существование страницы weight = 30 # pre = \u0026#34;\u0026lt;i class=\u0026#39;fas fa-info-circle\u0026#39;\u0026gt;\u0026lt;/i\u0026gt; \u0026#34; # HTML перед текстом ссылки (если нужно) # post = \u0026#34; \u0026lt;span class=\u0026#39;badge\u0026#39;\u0026gt;New\u0026lt;/span\u0026gt;\u0026#34; # HTML после текста ссылки [[menu.main]] name = \u0026#34;Проекты\u0026#34; pageRef = \u0026#34;/projects\u0026#34; weight = 25 # Пример, как вес влияет на порядок (Проекты будут между Блогом и О Нас) [[menu.main]] name = \u0026#34;Внешний Ресурс\u0026#34; url = \u0026#34;https://gohugo.io/\u0026#34; weight = 40 [menu.main.params] # Кастомные параметры для этого пункта меню target = \u0026#34;_blank\u0026#34; # Например, чтобы открывать в новой вкладке rel = \u0026#34;noopener noreferrer\u0026#34; # Можно определять подменю, используя `parent` [[menu.main]] name = \u0026#34;Контакты\u0026#34; pageRef = \u0026#34;/contact\u0026#34; weight = 35 [[menu.main]] # Подпункт для \u0026#34;Контактов\u0026#34; parent = \u0026#34;Контакты\u0026#34; # Указываем имя родительского пункта (или его identifier) name = \u0026#34;Почта\u0026#34; url = \u0026#34;mailto:test@example.com\u0026#34; weight = 1 # Другое меню, например, для футера [[menu.footer]] name = \u0026#34;Политика Конфиденциальности\u0026#34; pageRef = \u0026#34;/privacy\u0026#34; weight = 10 Ключевые поля для пунктов меню:\nname: Текст, который увидит пользователь. pageRef: Путь к контент-файлу (относительно content/) или секции. Hugo автоматически определит правильный Permalink. Самый надежный способ для внутренних ссылок. url: Прямой URL. Используй для внешних ссылок или для внутренних, если pageRef по какой-то причине не подходит. weight: Целое число, определяющее порядок. Элементы с меньшим весом идут первыми. identifier: Уникальный строковый идентификатор. Полезен, если на него нужно ссылаться (например, для parent или для CSS/JS). parent: identifier или name родительского пункта меню, если это подменю. pre / post: HTML-код, который будет добавлен до/после текста ссылки. [menu.имя_меню.params]: Свои параметры для пункта меню. В примере выше мы использовали target = \u0026quot;_blank\u0026quot; для открытия ссылки в новой вкладке. Доступны в шаблоне через {{ .Params.target }} для пункта меню. В шаблоне ты можешь вывести меню так (пример для меню main):\n\u0026lt;nav\u0026gt; \u0026lt;ul\u0026gt; {{ range .Site.Menus.main }} \u0026lt;li\u0026gt; \u0026lt;a href=\u0026#34;{{ .URL }}\u0026#34; {{ with .Params.target }}target=\u0026#34;{{ . }}\u0026#34;{{ end }} {{ with .Params.rel }}rel=\u0026#34;{{ . }}\u0026#34;{{ end }}\u0026gt; {{- .Pre -}} {{ .Name }} {{- .Post -}} \u0026lt;/a\u0026gt; {{ if .HasChildren }} {{/* Проверяем, есть ли подменю */}} \u0026lt;ul\u0026gt; {{ range .Children }} \u0026lt;li\u0026gt;\u0026lt;a href=\u0026#34;{{ .URL }}\u0026#34;\u0026gt;{{ .Name }}\u0026lt;/a\u0026gt;\u0026lt;/li\u0026gt; {{ end }} \u0026lt;/ul\u0026gt; {{ end }} \u0026lt;/li\u0026gt; {{ end }} \u0026lt;/ul\u0026gt; \u0026lt;/nav\u0026gt; Это базовый пример, ты можешь его усложнять, добавляя классы, проверяя активные пункты и т.д.\nПеременные окружения для разных конфигураций (дев, прод). Иногда тебе нужно, чтобы сайт вел себя по-разному в зависимости от того, где он собирается: на твоей локальной машине для разработки или на сервере для продакшена. Например, другой baseURL, другой код Google Analytics или отключение каких-то дебаг-фич на проде.\nHugo это понимает. Есть несколько способов:\nПеременные окружения ОС: Некоторые параметры Hugo можно задать через переменные окружения. Они обычно имеют префикс HUGO_. Например:\nHUGO_BASEURL=\u0026quot;https://prod.example.com/\u0026quot; HUGO_THEME=\u0026quot;my-prod-theme\u0026quot; HUGO_ENV=\u0026quot;production\u0026quot; (или development) – эта переменная важна. Hugo автоматически подхватит эти переменные.\nКонфигурационные директории (предпочтительный способ для сложных случаев): Как я уже упоминал, ты можешь создать папку config/ в корне проекта. В ней:\nconfig/_default/hugo.toml (или params.toml, menus.toml, languages.toml – можно разбить конфиг на несколько файлов) – это базовые настройки. config/development/hugo.toml – настройки для окружения development. config/production/hugo.toml – настройки для окружения production. Когда Hugo собирает сайт, он определяет текущее окружение:\nhugo server по умолчанию запускается в окружении development. hugo (без server) по умолчанию собирает для окружения production. Ты можешь явно указать окружение: hugo --environment staging или установив переменную HUGO_ENV=staging. Hugo сначала читает конфиг из _default/, а затем применяет поверх него конфиг из папки текущего окружения (например, production/). Настройки из специфичного окружения переопределяют или дополняют базовые.\nПример:\nconfig/_default/hugo.toml: title = \u0026#34;Мой Сайт\u0026#34; [params] showDrafts = false config/development/hugo.toml: baseURL = \u0026#34;http://localhost:1313/\u0026#34; buildDrafts = true # Чтобы видеть черновики на локальном сервере [params] showDrafts = true # Переопределяем параметр debugInfo = true # Добавляем новый параметр для разработки config/production/hugo.toml: baseURL = \u0026#34;https://mysuperprod.com/\u0026#34; # buildDrafts здесь не указан, значит, будет false по умолчанию для прода [params] # showDrafts не указан, значит, будет false из _default googleAnalytics = \u0026#34;UA-12345678-1\u0026#34; Это очень мощный механизм для управления конфигурациями.\nФункция getenv в шаблонах: Ты можешь напрямую из шаблона получить значение переменной окружения ОС:\n{{ $envVar := getenv \u0026#34;MY_CUSTOM_ENV_VARIABLE\u0026#34; }} {{ if $envVar }} \u0026lt;p\u0026gt;Переменная окружения: {{ $envVar }}\u0026lt;/p\u0026gt; {{ end }} Но для конфигурации лучше использовать файлы, это чище.\nС конфигурацией вроде бы всё основное проговорили. Это важный раздел, потому что именно hugo.toml (или его аналоги) задает тон всему проекту. Понимание этих настроек сэкономит тебе кучу времени и нервов.\nКак оно? Готов двигаться к следующей большой теме – расширенным возможностям Hugo? Там про шорткоды, Hugo Pipes и прочие интересные штуки.\n6. Расширенные возможности Переходим к фичам, которые делают из Hugo не просто генератор статики, а настоящий швейцарский нож для веб-разработчика. Здесь будет про то, как выйти за рамки обычного Markdown и заставить Hugo делать реально крутые штуки.\nДержись крепче, сейчас будем погружаться в магию Hugo.\nShortcodes (макросы для контента, если Markdown уже не хватает) Markdown – это, конечно, хорошо: просто, чисто, понятно. Но что делать, если тебе в контент надо вставить что-то посложнее, чем просто текст, картинку или список? Например, видео с YouTube, интерактивную карту, кастомный блок с предупреждением, галерею изображений или даже спойлер? Копипастить куски HTML прямо в Markdown – это моветон и прямой путь к помойке в контенте.\nВот тут на сцену выходят шорткоды (shortcodes).\nЧто это за звери? Шорткоды – это, по сути, твои кастомные HTML-теги, которые ты можешь использовать прямо в .md файлах. Hugo находит эти теги при сборке сайта и заменяет их на HTML-код, сгенерированный специальным шаблоном этого шорткода. Это как макросы, если тебе так понятнее. Они позволяют тебе инкапсулировать сложную разметку и логику в переиспользуемый компонент, сохраняя при этом чистоту Markdown-файлов.\nГде живут и как создаются? Шаблоны для шорткодов – это обычные HTML-файлы с логикой Go Templates, и лежат они в папке layouts/shortcodes/. Имя файла (без .html) становится именем твоего шорткода. Например, layouts/shortcodes/myalert.html создаст шорткод {​{\u0026lt; myalert \u0026gt;}}.\nТипы шорткодов:\nПростой (без параметров и внутреннего содержимого):\nВ Markdown: {​{\u0026lt; mysimplecode \u0026gt;}} Шаблон (layouts/shortcodes/mysimplecode.html): \u0026lt;p\u0026gt;Это мой простой шорткод!\u0026lt;/p\u0026gt; С параметрами: Параметры могут быть именованными или позиционными.\nИменованные: В Markdown: {​{\u0026lt; image src=\u0026quot;/images/cat.jpg\u0026quot; alt=\u0026quot;Милый котик\u0026quot; caption=\u0026quot;Котик дня\u0026quot; \u0026gt;}} Шаблон (layouts/shortcodes/image.html): \u0026lt;figure\u0026gt; \u0026lt;img src=\u0026#34;{{ .Get \u0026#34;src\u0026#34; }}\u0026#34; alt=\u0026#34;{{ .Get \u0026#34;alt\u0026#34; }}\u0026#34;\u0026gt; {{ with .Get \u0026#34;caption\u0026#34; }}\u0026lt;figcaption\u0026gt;{{ . }}\u0026lt;/figcaption\u0026gt;{{ end }} \u0026lt;/figure\u0026gt; Внутри шаблона шорткода параметры доступны через метод .Get \u0026quot;имя_параметра\u0026quot;. Позиционные: В Markdown: {​{\u0026lt; video \u0026quot;youtube\u0026quot; \u0026quot;ABCdEFGhI123\u0026quot; \u0026gt;}} Шаблон (layouts/shortcodes/video.html): {{ $platform := .Get 0 }} {{ $id := .Get 1 }} {{ if eq $platform \u0026#34;youtube\u0026#34; }} \u0026lt;div class=\u0026#34;embed-responsive embed-responsive-16by9\u0026#34;\u0026gt; \u0026lt;iframe src=\u0026#34;https://www.youtube.com/embed/{{ $id }}\u0026#34; frameborder=\u0026#34;0\u0026#34; allowfullscreen\u0026gt;\u0026lt;/iframe\u0026gt; \u0026lt;/div\u0026gt; {{ else if eq $platform \u0026#34;vimeo\u0026#34; }} \u0026lt;div class=\u0026#34;embed-responsive embed-responsive-16by9\u0026#34;\u0026gt; \u0026lt;iframe src=\u0026#34;https://player.vimeo.com/video/{{ $id }}\u0026#34; frameborder=\u0026#34;0\u0026#34; allowfullscreen\u0026gt;\u0026lt;/iframe\u0026gt; \u0026lt;/div\u0026gt; {{ end }} Позиционные параметры доступны через .Get N, где N – это индекс параметра (начиная с 0). Парный (enclosing, с внутренним содержимым): Эти шорткоды имеют открывающий и закрывающий тег, а контент между ними доступен в шаблоне шорткода через переменную .Inner.\nВ Markdown: {​{\u0026lt; alert type=\u0026#34;warning\u0026#34; title=\u0026#34;Внимание!\u0026#34; \u0026gt;}} Это **очень важное** сообщение. Обратите на него внимание. * Пункт 1 * Пункт 2 {​{\u0026lt; /alert \u0026gt;}} Шаблон (layouts/shortcodes/alert.html): {{ $type := .Get \u0026#34;type\u0026#34; | default \u0026#34;info\u0026#34; }} {{ $title := .Get \u0026#34;title\u0026#34; }} \u0026lt;div class=\u0026#34;alert alert-{{ $type }}\u0026#34;\u0026gt; {{ with $title }}\u0026lt;h4\u0026gt;{{ . }}\u0026lt;/h4\u0026gt;{{ end }} {{ .Inner | markdownify }} {{/* .Inner содержит всё, что между тегами шорткода */}} {{/* markdownify обрабатывает внутренний контент как Markdown */}} \u0026lt;/div\u0026gt; Ключевой момент здесь – {{ .Inner | markdownify }}. Переменная .Inner содержит текст \u0026ldquo;как есть\u0026rdquo;. Если ты хочешь, чтобы Markdown внутри шорткода тоже отрендерился в HTML, ты пропускаешь .Inner через функцию markdownify. Если этого не сделать, HTML-теги, например, будут отображены как текст. Доступ к контексту страницы и сайта из шорткода: Внутри шаблона шорткода обычная точка . ссылается на специальный объект шорткода (через который мы получаем параметры с помощью .Get или внутреннее содержимое через .Inner). Чтобы получить доступ к переменным текущей страницы (той, в Markdown которой вставлен шорткод), используй .Page:\n{{ .Page.Title }} {{ .Page.Permalink }} {{ .Page.Params.какой_то_параметр_страницы }} А к глобальным переменным сайта – через .Page.Site:\n{{ .Page.Site.Title }} {{ .Page.Site.Params.глобальный_параметр }} Встроенные шорткоды Hugo: Hugo поставляется с набором полезных встроенных шорткодов. Тебе не нужно для них создавать шаблоны, они уже есть. Некоторые из них:\nfigure: Для вставки изображений с подписями и атрибутами. Очень гибкий. Заголовок картинкиЭто подпись под картинкой.\nref и relref: Для создания надежных внутренних ссылок на другие страницы или секции. Они проверяют существование ссылки на этапе сборки. Если ссылка битая – Hugo выдаст ошибку. Это мега-полезно. Прочтите нашу статью о [котиках]({​{\u0026lt; ref \u0026#34;posts/o-kotikah.md\u0026#34; \u0026gt;}}). Или посмотрите [относительную ссылку]({​{\u0026lt; relref \u0026#34;other-post.md\u0026#34; \u0026gt;}}). ref генерирует абсолютный URL (с baseURL), relref – относительный. Лучше всегда использовать их для внутренних ссылок вместо обычных Markdown-ссылок, особенно если структура сайта может меняться. youtube, vimeo: Для вставки видео. gist: Для вставки GitHub Gists. highlight: Для подсветки синтаксиса блока кода (хотя обычно для этого используют Markdown fences ). param: Для вывода значения параметра из Front Matter текущей страницы. Автор этой статьи: {​{\u0026lt; param \u0026#34;author\u0026#34; \u0026gt;}} Изучи список встроенных шорткодов в документации Hugo, многие из них могут тебе пригодиться.\nНюансы и лучшие практики:\nНе переусердствуй. Шорткоды – это мощно, но если ты будешь пихать их в каждую строку, твой Markdown станет трудночитаемым и менее портативным (если вдруг решишь переехать с Hugo на что-то другое). Давай шорткодам понятные имена. Документируй свои кастомные шорткоды: какие параметры они принимают и что делают. Хотя бы для себя. Используй {{- ... -}} для контроля пробелов. Как и в обычных шаблонах, дефисы - рядом с фигурными скобками в шаблонах шорткодов могут убирать лишние пробелы и переводы строк в генерируемом HTML, делая его чище. Шорткоды – это один из столпов, на которых держится гибкость Hugo в работе с контентом. Они позволяют тебе, как инженеру, дать авторам контента (даже если это ты сам) удобные инструменты для создания богатых и сложных страниц без необходимости лезть в HTML/CSS/JS каждый раз.\nНу как, впечатляет мощь? Дальше у нас на очереди – как подгружать внешние данные в твои шаблоны, то есть про Data Templates.\nData Templates (грузим данные из JSON, YAML, CSV – откуда угодно) Шорткоды – это хорошо, но иногда тебе нужно работать не с кусками HTML, а с настоящими данными: списками, таблицами, объектами. Может, у тебя есть прайс-лист в CSV, список авторов в YAML или какие-то конфигурационные данные в JSON, которые ты не хочешь хардкодить в шаблонах или пихать в основной hugo.toml.\nВот тут-то Hugo и показывает свою гибкость с помощью Data Files (файлов данных) и Data Templates (хотя правильнее их называть просто \u0026ldquo;использование данных в шаблонах\u0026rdquo;).\nЧто это такое и зачем нужно?\nHugo позволяет тебе положить файлы с данными в специальную папку data/ в корне твоего проекта. При сборке сайта Hugo автоматически читает эти файлы, парсит их и делает доступными в твоих шаблонах через объект .Site.Data.\nПреимущества такого подхода:\nРазделение данных и представления: Ты можешь хранить свои данные (например, список сотрудников, характеристики товаров, пункты меню для сложной навигации) отдельно от HTML-разметки. Это чище и проще в поддержке. Управление данными: Данные в стандартизированных форматах (JSON, YAML, TOML, CSV) легче редактировать, в том числе людям, далеким от HTML. Иногда проще попросить кого-то поправить строчку в CSV, чем лезть в шаблон. Переиспользование данных: Одни и те же данные можно использовать на разных страницах и в разных частях сайта. Работа с внешними источниками (относительно): Ты можешь легко подложить данные, экспортированные из других систем. Где лежат файлы данных и какие форматы поддерживаются?\nВсе файлы данных должны находиться в директории data/ в корне твоего Hugo-проекта. Ты можешь создавать поддиректории внутри data/ для лучшей организации. Например, data/team/members.json или data/pricing/plans.csv. Hugo \u0026ldquo;из коробки\u0026rdquo; понимает следующие форматы: JSON (.json) YAML (.yaml или .yml) TOML (.toml) CSV (.csv): Для CSV есть нюанс – первая строка файла по умолчанию считается заголовком (именами полей). Как получить доступ к данным в шаблонах?\nВсе загруженные данные доступны через глобальный объект .Site.Data. Структура этого объекта соответствует структуре твоей папки data/ и именам файлов (без расширения).\nЕсли у тебя есть файл data/authors.yaml, ты обращаешься к нему так: {{ .Site.Data.authors }}. Если файл лежит в подпапке, например, data/products/featured.json, то доступ будет таким: {{ .Site.Data.products.featured }}. Если имя файла содержит дефисы, например data/site-settings.toml, то в шаблоне ты можешь использовать index для доступа: {{ index .Site.Data \u0026quot;site-settings\u0026quot; }} или, если версия Hugo позволяет, иногда работает и прямой доступ с кавычками, но index надежнее для имен с спецсимволами. Для имен без спецсимволов {{ .Site.Data.sitesettings }} (Hugo пытается привести к camelCase или lower) тоже может сработать, но лучше использовать имена файлов, удобные для прямого маппинга. Проще всего использовать имена файлов без дефисов и пробелов, например data/siteSettings.toml -\u0026gt; {{ .Site.Data.siteSettings }}. Пример использования:\nДопустим, у нас есть список авторов в файле data/team/authors.yaml:\n# data/team/authors.yaml - id: \u0026#34;jdoe\u0026#34; name: \u0026#34;Иван Иванов\u0026#34; email: \u0026#34;ivan@example.com\u0026#34; bio: \u0026#34;Главный спец по Hugo, пишет код и документацию.\u0026#34; social: twitter: \u0026#34;ivanov_hugo\u0026#34; github: \u0026#34;johndoe_coder\u0026#34; - id: \u0026#34;psidorov\u0026#34; name: \u0026#34;Петр Сидоров\u0026#34; email: \u0026#34;petr@example.com\u0026#34; bio: \u0026#34;Эксперт по Markdown и созданию контента.\u0026#34; social: linkedin: \u0026#34;petrsidorov\u0026#34; Теперь в любом шаблоне (например, в list.html или в partial) ты можешь вывести этот список:\n\u0026lt;h3\u0026gt;Наша Команда Авторов:\u0026lt;/h3\u0026gt; \u0026lt;ul class=\u0026#34;author-list\u0026#34;\u0026gt; {{ range .Site.Data.team.authors }} {{/* Обращаемся к data/team/authors.yaml */}} \u0026lt;li class=\u0026#34;author-item\u0026#34; id=\u0026#34;author-{{ .id }}\u0026#34;\u0026gt; \u0026lt;h4\u0026gt;{{ .name }}\u0026lt;/h4\u0026gt; \u0026lt;p\u0026gt;Email: \u0026lt;a href=\u0026#34;mailto:{{ .email }}\u0026#34;\u0026gt;{{ .email }}\u0026lt;/a\u0026gt;\u0026lt;/p\u0026gt; \u0026lt;p\u0026gt;{{ .bio }}\u0026lt;/p\u0026gt; {{ with .social }} {{/* Если есть секция social */}} \u0026lt;p\u0026gt;Соцсети: {{ with .twitter }}\u0026lt;a href=\u0026#34;https://twitter.com/{{ . }}\u0026#34;\u0026gt;Twitter\u0026lt;/a\u0026gt; {{ end }} {{ with .github }}\u0026lt;a href=\u0026#34;https://github.com/{{ . }}\u0026#34;\u0026gt;GitHub\u0026lt;/a\u0026gt; {{ end }} {{ with .linkedin }}\u0026lt;a href=\u0026#34;https://linkedin.com/in/{{ . }}\u0026#34;\u0026gt;LinkedIn\u0026lt;/a\u0026gt; {{ end }} \u0026lt;/p\u0026gt; {{ end }} \u0026lt;/li\u0026gt; {{ else }} \u0026lt;li\u0026gt;Информации об авторах пока нет.\u0026lt;/li\u0026gt; {{ end }} \u0026lt;/ul\u0026gt; В этом примере мы перебираем массив авторов (range .Site.Data.team.authors). Внутри цикла точка . ссылается на текущий элемент массива (объект автора), и мы можем обращаться к его полям (.id, .name, .bio, .social.twitter).\nЕсли у тебя CSV файл, например, data/pricing/plans.csv:\nid,planName,price,features basic,\u0026#34;Базовый\u0026#34;,10,\u0026#34;10 ГБ диск, 1000 email, Поддержка 24/7\u0026#34; premium,\u0026#34;Премиум\u0026#34;,25,\u0026#34;50 ГБ диск, 5000 email, Приоритетная поддержка, API доступ\u0026#34; ultra,\u0026#34;Ультра\u0026#34;,50,\u0026#34;200 ГБ диск, Безлимит email, VIP поддержка, Персональный менеджер\u0026#34; В шаблоне (Hugo \u0026gt; 0.41 для CSV):\n\u0026lt;table\u0026gt; \u0026lt;thead\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;th\u0026gt;План\u0026lt;/th\u0026gt; \u0026lt;th\u0026gt;Цена ($/мес)\u0026lt;/th\u0026gt; \u0026lt;th\u0026gt;Возможности\u0026lt;/th\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/thead\u0026gt; \u0026lt;tbody\u0026gt; {{ range .Site.Data.pricing.plans }} {{/* data/pricing/plans.csv */}} \u0026lt;tr\u0026gt; \u0026lt;td\u0026gt;{{ .planName }}\u0026lt;/td\u0026gt; {{/* Имена полей берутся из первой строки CSV */}} \u0026lt;td\u0026gt;{{ .price }}\u0026lt;/td\u0026gt; \u0026lt;td\u0026gt; \u0026lt;ul\u0026gt; {{ range $feature := split .features \u0026#34;,\u0026#34; }} {{/* Разбираем строку features по запятой */}} \u0026lt;li\u0026gt;{{ trim $feature \u0026#34; \u0026#34; }}\u0026lt;/li\u0026gt; {{/* Убираем лишние пробелы */}} {{ end }} \u0026lt;/ul\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; {{ end }} \u0026lt;/tbody\u0026gt; \u0026lt;/table\u0026gt; Hugo парсит CSV в массив объектов (или мап), где ключи – это заголовки из первой строки.\nПолучение данных из удаленных источников (на этапе сборки!):\nHugo также умеет подгружать данные из внешних URL во время сборки сайта с помощью функций getJSON и getCSV. Это не делает сайт динамическим в реальном времени, данные загружаются один раз при каждой сборке сайта.\n{{ $jsonData := getJSON \u0026quot;https://api.example.com/some/data.json\u0026quot; }} {{ $csvData := getCSV \u0026quot;,\u0026quot; \u0026quot;https://example.com/some/data.csv\u0026quot; }} (первый аргумент – разделитель) Пример с getJSON:\n{{ $apiResponse := getJSON \u0026#34;https://api.github.com/users/gohugoio\u0026#34; }} {{ if $apiResponse }} \u0026lt;p\u0026gt;У Hugo на GitHub {{ $apiResponse.public_repos }} публичных репозиториев.\u0026lt;/p\u0026gt; \u0026lt;p\u0026gt;Описание: {{ $apiResponse.bio }}\u0026lt;/p\u0026gt; {{ else }} \u0026lt;p\u0026gt;Не удалось загрузить данные с GitHub API.\u0026lt;/p\u0026gt; {{ end }} Важно про удаленные данные:\nЗагрузка происходит при каждой сборке (hugo или hugo server). Если API медленный или часто недоступен, это замедлит сборку. Если API требует аутентификации, тебе придется передавать токены/ключи (например, через заголовки, если getJSON это поддерживает в твоей версии Hugo, или через переменные окружения и предварительную загрузку скриптом). Для часто меняющихся данных этот подход не годится – сайт останется статическим между сборками. Для \u0026ldquo;живых\u0026rdquo; данных нужен JavaScript на клиенте, который будет их подгружать. Hugo кэширует ответы от getJSON и getCSV чтобы ускорить повторные сборки. Папку кэша ($TMPDIR/hugo_cache/) можно очистить, если нужно принудительно обновить данные. Итог по Data Files: Это чертовски удобный способ отделить данные от логики представления и сделать сайт более гибким и управляемым. Особенно полезно для всяких списков, таблиц, конфигурационных блоков, которые могут часто меняться или которыми должны управлять не только разработчики. Используй это с умом, и твои шаблоны станут чище, а жизнь – проще.\nДальше по плану у нас одна из самых мощных штук в Hugo для работы с фронтендом – Hugo Pipes, или Asset Pipeline. Готов к тому, как Hugo может сам собирать и оптимизировать твои CSS, JS и картинки?\nAsset Pipeline (Hugo Pipes) – обработка CSS/JS, картинок Так, инженер, пристегни ремни. Сейчас мы окунемся в то, что реально отличает Hugo от многих других генераторов и делает его маленькой сборочной фабрикой для твоего фронтенда. Речь пойдет про Hugo Pipes, или, как его еще называют, Asset Pipeline.\nЭто встроенный в Hugo механизм для обработки твоих \u0026ldquo;ассетов\u0026rdquo; – CSS, JavaScript, изображений и других файлов – прямо во время сборки сайта. И что самое приятное, для многих типовых задач тебе больше не нужны будут внешние монстры типа Webpack, Gulp или Grunt (хотя Hugo может и с ними дружить, если очень хочется).\nЗачем это вообще сдалось?\nПростота сборки: Не надо настраивать отдельный Node.js-стек для компиляции SASS, минификации JS или оптимизации картинок. Hugo делает это сам. Один инструмент для всего. Скорость: Hugo Pipes работает быстро. Операции выполняются на лету, результаты могут кэшироваться. Удобство: Логика обработки ассетов живет прямо в твоих шаблонах, рядом с HTML-разметкой, которая их использует. Фингерпринтинг (Cache Busting): Hugo может автоматически добавлять хеш к именам файлов ассетов (например, style.a34df5.css). Это гарантирует, что браузер пользователя загрузит новую версию файла, когда он изменится, а не будет использовать старую из кэша. Как это работает: объект resources и его волшебные методы\nГде лежат исходники: Файлы, которые ты собираешься обрабатывать через Hugo Pipes, должны лежать в папке assets/ твоего проекта (а не в static/, как файлы, которые не требуют обработки). Например, assets/scss/main.scss или assets/js/app.js.\nПолучение ресурса: Первый шаг – получить ресурс в шаблоне с помощью resources.Get:\n{{ $scss := resources.Get \u0026#34;scss/main.scss\u0026#34; }} {{ $js := resources.Get \u0026#34;js/app.js\u0026#34; }} {{ $image := resources.Get \u0026#34;images/my-photo.jpg\u0026#34; }} Это создает специальный объект \u0026ldquo;ресурс\u0026rdquo;, с которым дальше можно работать.\nЦепочки обработки (Pipes): Дальше ты пропускаешь этот ресурс через цепочку функций-обработчиков, используя знакомый нам оператор |.\nОбработка CSS (SASS/SCSS):\nКомпиляция SASS/SCSS в CSS: (Требуется extended версия Hugo)\n{{ $style := resources.Get \u0026#34;scss/main.scss\u0026#34; | toCSS }} Переменная $style теперь содержит объект скомпилированного CSS.\nОпции для toCSS: Можно передать параметры, например, для минификации:\n{{ $options := dict \u0026#34;targetPath\u0026#34; \u0026#34;css/style.css\u0026#34; \u0026#34;outputStyle\u0026#34; \u0026#34;compressed\u0026#34; }} {{ $style := resources.Get \u0026#34;scss/main.scss\u0026#34; | toCSS $options }} targetPath: Имя выходного файла (относительно public/). Не обязательно, но полезно для отладки. outputStyle: expanded (читаемый) или compressed (минифицированный). PostCSS: Если тебе нужен PostCSS (например, для автопрефиксера), это тоже можно:\n{{ $style := resources.Get \u0026#34;scss/main.scss\u0026#34; | toCSS | postCSS }} Для этого у тебя должен быть установлен postcss-cli и нужные плагины (например, autoprefixer) глобально или локально в node_modules твоего проекта, а также файл конфигурации postcss.config.js в корне проекта.\nМинификация CSS (если еще не сделано):\n{{ $style := $style | minify }} Обработка JavaScript:\nESBuild (современный и рекомендуемый способ для сборки и минификации JS): Hugo использует мощный сборщик ESBuild. Он умеет бандлить модули, транспилировать современный JS и минифицировать.\n{{ $js := resources.Get \u0026#34;js/app.js\u0026#34; | js.Build (dict \u0026#34;targetPath\u0026#34; \u0026#34;bundle.js\u0026#34; \u0026#34;minify\u0026#34; true \u0026#34;bundle\u0026#34; true \u0026#34;format\u0026#34; \u0026#34;iife\u0026#34; \u0026#34;sourcemap\u0026#34; \u0026#34;inline\u0026#34;) }} targetPath: Имя выходного файла. minify: true для минификации. bundle: true для сборки всех импортов в один файл. format: Формат вывода (iife, esm, cjs). iife (Immediately Invoked Function Expression) – хороший выбор для браузерных скриптов, подключаемых через \u0026lt;script\u0026gt;. sourcemap: inline или external для генерации карт кода. Babel: Если у тебя уже есть настроенный Babel (babel.config.js и зависимости в node_modules), Hugo может его использовать (хотя js.Build с ESBuild обычно предпочтительнее для новых проектов).\n{{ $js := resources.Get \u0026#34;js/legacy.js\u0026#34; | babel (dict \u0026#34;minify\u0026#34; true) }} Минификация JS (если еще не сделано):\n{{ $js := $js | minify }} Общие операции с ресурсами:\nФингерпринтинг (для Cache Busting): Эта операция добавляет хеш к имени файла.\n{{ $style := resources.Get \u0026#34;scss/main.scss\u0026#34; | toCSS (dict \u0026#34;outputStyle\u0026#34; \u0026#34;compressed\u0026#34;) | fingerprint \u0026#34;sha256\u0026#34; }} {{ $js := resources.Get \u0026#34;js/app.js\u0026#34; | js.Build (dict \u0026#34;minify\u0026#34; true \u0026#34;bundle\u0026#34; true) | fingerprint }} Теперь $style.RelPermalink будет что-то вроде /css/main.a34df56e.css.\nКонкатенация (объединение) файлов:\n{{ $jsLibs := resources.Get \u0026#34;js/lib1.js\u0026#34; }} {{ $jsApp := resources.Get \u0026#34;js/my-app-code.js\u0026#34; }} {{ $jsBundle := slice $jsLibs $jsApp | resources.Concat \u0026#34;js/final-bundle.js\u0026#34; }} {{ $jsBundle = $jsBundle | js.Build (dict \u0026#34;minify\u0026#34; true) | fingerprint }} Публикация ресурсов и использование в HTML: Обработанные ресурсы не копируются в public/ автоматически. Они публикуются только тогда, когда ты используешь их .Permalink или .RelPermalink в шаблоне:\n\u0026lt;link rel=\u0026#34;stylesheet\u0026#34; href=\u0026#34;{{ $style.RelPermalink }}\u0026#34;\u0026gt; \u0026lt;script src=\u0026#34;{{ $js.RelPermalink }}\u0026#34; defer\u0026gt;\u0026lt;/script\u0026gt; Hugo сам позаботится о том, чтобы эти файлы (main.a34df56e.css, bundle.b23cf67a.js) оказались в нужных местах в папке public/.\nСвойства объекта ресурса: У обработанного ресурса есть полезные свойства:\n.Permalink: Абсолютный URL к ресурсу. .RelPermalink: Относительный URL (обычно его и используют). .MediaType: MIME-тип ресурса (например, text/css, application/javascript). .Content: Содержимое ресурса в виде строки (если нужно его встроить прямо в HTML, например, для критического CSS). .Data: Метаданные о ресурсе. .Integrity: Хеш для Subresource Integrity (SRI), если использовался fingerprint. {{ $style.Data.Integrity }}. Обработка изображений (кратко, т.к. это и отдельная тема): Hugo Pipes также позволяет обрабатывать изображения из папки assets/.\n{{ $original := resources.Get \u0026#34;images/big-photo.jpg\u0026#34; }} {{ $resized := $original.Resize \u0026#34;800x q90 Lanczos\u0026#34; }} {{/* Ресайз до 800px по ширине, качество 90%, метод Lanczos */}} {{ $webpThumb := $resized.Process \u0026#34;webp\u0026#34; }} {{/* Конвертация в WebP */}} \u0026lt;img src=\u0026#34;{{ $webpThumb.RelPermalink }}\u0026#34; width=\u0026#34;{{ $webpThumb.Width }}\u0026#34; height=\u0026#34;{{ $webpThumb.Height }}\u0026#34; alt=\u0026#34;Крутая картинка\u0026#34;\u0026gt; Тут куча возможностей: Resize, Fit (вписать в размеры с сохранением пропорций), Fill (заполнить с обрезкой), конвертация форматов (.Process \u0026quot;webp\u0026quot;), фильтры и т.д.\nstatic/ vs assets/ – когда что использовать?\nstatic/: Для файлов, которые не требуют никакой обработки Hugo и должны быть скопированы в public/ \u0026ldquo;как есть\u0026rdquo;. Например: favicon.ico robots.txt (если ты не генерируешь его через Hugo) Предварительно собранные библиотеки JS/CSS, которые ты не хочешь трогать. Шрифты, PDF-файлы и т.п. assets/: Для всех файлов, которые ты хочешь пропустить через Hugo Pipes: SASS/SCSS файлы. JavaScript, который нужно бандлить, транспилировать или минифицировать. Изображения, которые ты будешь ресайзить, оптимизировать или конвертировать. Любые другие файлы, к которым ты хочешь применить resources.Get и дальнейшую обработку. Конфигурация Hugo Pipes: Некоторые глобальные настройки для Hugo Pipes можно задать в hugo.toml. Например, указать путь к postcss.config.js или настроить параметры сборки JS по умолчанию.\n# hugo.toml [build] writeStats = true # Создает файл hugo_stats.json с информацией о сборке ассетов, полезно для анализа [ postcss ] # Необязательно, если postcss.config.js в корне # configFile = \u0026#39;path/to/your/postcss.config.js\u0026#39; # Глобальные опции для js.Build можно тоже задавать, но это реже нужно Hugo Pipes – это невероятно мощный инструмент. Он позволяет держать всю логику сборки фронтенда внутри Hugo, избавляя от необходимости во внешних инструментах для большинства повседневных задач. Освоив его, ты сможешь делать современные, быстрые и хорошо оптимизированные сайты с минимальными усилиями.\nЭто был серьезный кусок информации. Как ты там, инженер? Переварил? Дальше у нас мультиязычность – тоже интересная тема, если вдруг твой сайт должен говорить на нескольких языках.\nМультиязычность (если вдруг приспичило) Да, инженер, Hugo из коробки умеет делать мультиязычные сайты. И делает это довольно элегантно. Если тебе нужно, чтобы твой контент был доступен, скажем, на русском, английском и китайском – Hugo тебе в этом поможет, и не придется городить огород из нескольких отдельных сайтов или костыльных плагинов, как в некоторых CMS.\nЗачем это нужно? Ну, очевидно – чтобы расширить аудиторию. Плюс, поисковики любят, когда контент правильно размечен для разных языков, это хорошо для SEO.\nОсновные принципы и конфигурация в hugo.toml:\nВся магия начинается с настройки языков в твоем hugo.toml.\nОпределение языков: Ты должен указать язык по умолчанию и перечислить все поддерживаемые языки.\n# hugo.toml defaultContentLanguage = \u0026#34;ru\u0026#34; # Язык контента по умолчанию [languages] [languages.ru] # Код языка (ru, en, fr, de и т.д.) languageName = \u0026#34;Русский\u0026#34; # Как язык будет отображаться в переключателе weight = 10 # Порядок в переключателе (меньше = раньше) contentDir = \u0026#34;content/ru\u0026#34; # Опционально: своя папка для контента этого языка # title = \u0026#34;Мой сайт на Hugo\u0026#34; # Можно переопределить .Site.Title для этого языка # baseURL = \u0026#34;https://example.com/ru/\u0026#34; # Можно свой baseURL, если языки на поддиректориях/поддоменах [languages.ru.params] # Параметры, специфичные для русского языка copyright = \u0026#34;© 2025 Иван Петров\u0026#34; some_ru_specific_string = \u0026#34;Привет, мир!\u0026#34; [languages.en] languageName = \u0026#34;English\u0026#34; weight = 20 contentDir = \u0026#34;content/en\u0026#34; # title = \u0026#34;My Hugo Site\u0026#34; # baseURL = \u0026#34;https://example.com/en/\u0026#34; # или \u0026#34;https://en.example.com/\u0026#34; [languages.en.params] copyright = \u0026#34;© 2025 John Doe\u0026#34; some_en_specific_string = \u0026#34;Hello, world!\u0026#34; defaultContentLanguage: Очень важный параметр. Если Hugo находит контент без явного указания языка, он будет считать, что этот контент на языке по умолчанию. [languages.\u0026lt;code\u0026gt;]: Секция для каждого языка. \u0026lt;code\u0026gt; – это стандартный код языка (например, en, ru, de-CH). languageName: Человекочитаемое название языка. weight: Для сортировки в переключателе языков. contentDir: (Опционально) Позволяет хранить контент для каждого языка в своей подпапке внутри content/ (например, content/en/posts/, content/ru/posts/). Это самый чистый способ организации. Если не указано, Hugo будет искать файлы типа mypost.en.md и mypost.ru.md в общих папках. baseURL, title, [languages.\u0026lt;code\u0026gt;.params]: Позволяют переопределить глобальные настройки сайта для конкретного языка. Организация контента для мультиязычности:\nЕсть два основных способа:\nПо имени файла (Filename-based): Файлы для разных языковых версий одной страницы лежат в одной папке, но имеют суффикс языка перед расширением.\ncontent/posts/my-article.md (для defaultContentLanguage, если он ru) или content/posts/my-article.ru.md content/posts/my-article.en.md content/about.ru.md content/about.en.md По директории (Directory-based): (Рекомендуется для большинства случаев) Ты указываешь contentDir для каждого языка в hugo.toml, как в примере выше. Тогда структура будет такой:\ncontent/ru/posts/my-article.md content/en/posts/my-article.md content/ru/about.md content/en/about.md Этот способ обычно нагляднее и проще в управлении.\nСвязывание переводов: Hugo автоматически пытается связать переведенные версии одной и той же страницы. Если у тебя файлы content/ru/posts/my-article.md и content/en/posts/my-article.md, Hugo поймет, что это переводы друг друга. Если имена файлов или пути сильно отличаются, ты можешь явно указать связь через параметр translationKey в Front Matter каждой страницы-перевода:\n# content/ru/posts/статья-про-котиков.md --- title: \u0026#34;Статья про котиков\u0026#34; translationKey: \u0026#34;cat-article-123\u0026#34; lang: \u0026#34;ru\u0026#34; --- ... # content/en/blog/article-about-felines.md --- title: \u0026#34;Article about Felines\u0026#34; translationKey: \u0026#34;cat-article-123\u0026#34; # Тот же ключ lang: \u0026#34;en\u0026#34; --- ... Явное указание lang в Front Matter тоже хорошая практика, хотя Hugo часто определяет его из пути.\nШаблоны для мультиязычного сайта:\nДоступные переменные:\n.Site.IsMultiLingual: true, если на сайте настроено больше одного языка. .Site.Languages: Коллекция всех определенных языков (объекты из [languages.\u0026lt;code\u0026gt;] в конфиге). .Site.Language.Lang: Код текущего языка (например, \u0026ldquo;ru\u0026rdquo;). .Site.Language.LanguageName: Имя текущего языка. .Site.Language.Params.имя_параметра: Доступ к параметрам, специфичным для текущего языка. .Page.Lang: Язык текущей страницы. .Page.IsTranslated: true, если для текущей страницы существуют переводы. .Page.Translations: Список переведенных версий текущей страницы (не включая саму текущую страницу). .Page.AllTranslations: Список, включающий текущую страницу и все ее переводы. Пример переключателя языков (Language Switcher): Обычно его делают как partial (layouts/partials/lang-switcher.html):\n{{ if .Site.IsMultiLingual }} \u0026lt;nav class=\u0026#34;language-switcher\u0026#34;\u0026gt; \u0026lt;ul\u0026gt; {{ range .Page.AllTranslations }} \u0026lt;li\u0026gt; \u0026lt;a href=\u0026#34;{{ .Permalink }}\u0026#34; lang=\u0026#34;{{ .Lang }}\u0026#34; {{ if eq .Lang $.Page.Lang }}class=\u0026#34;active\u0026#34; aria-current=\u0026#34;page\u0026#34;{{ end }}\u0026gt; {{ .Language.LanguageName }} \u0026lt;/a\u0026gt; \u0026lt;/li\u0026gt; {{ end }} \u0026lt;/ul\u0026gt; \u0026lt;/nav\u0026gt; {{ end }} $.Page.Lang используется для доступа к языку \u0026ldquo;внешней\u0026rdquo; страницы, так как внутри range точка . ссылается на элемент перевода.\nЛокализация строк интерфейса (i18n): Для перевода строк в шаблонах (например, \u0026ldquo;Читать далее\u0026rdquo;, \u0026ldquo;Опубликовано\u0026rdquo;, \u0026ldquo;Поиск\u0026rdquo;) используется механизм i18n.\nСоздай папку i18n/ в корне проекта. В ней создай файлы для каждого языка: i18n/ru.toml, i18n/en.toml (или .yaml/.json). i18n/ru.toml: [read_more] other = \u0026#34;Читать далее\u0026#34; [posted_on] other = \u0026#34;Опубликовано\u0026#34; [posts_found] one = \u0026#34;Найдена {{.Count}} запись\u0026#34; few = \u0026#34;Найдено {{.Count}} записи\u0026#34; # Для русского языка важны формы few/many many = \u0026#34;Найдено {{.Count}} записей\u0026#34; other = \u0026#34;Найдено {{.Count}} записей\u0026#34; i18n/en.toml: [read_more] other = \u0026#34;Read more\u0026#34; [posted_on] other = \u0026#34;Posted on\u0026#34; [posts_found] one = \u0026#34;{{.Count}} post found\u0026#34; other = \u0026#34;{{.Count}} posts found\u0026#34; В шаблоне используй функцию i18n (или ее алиас T): \u0026lt;a href=\u0026#34;{{ .Permalink }}\u0026#34;\u0026gt;{{ T \u0026#34;read_more\u0026#34; }}\u0026lt;/a\u0026gt; \u0026lt;p\u0026gt;{{ T \u0026#34;posted_on\u0026#34; }} {{ .Date.Format \u0026#34;02.01.2006\u0026#34; }}\u0026lt;/p\u0026gt; \u0026lt;p\u0026gt;{{ T \u0026#34;posts_found\u0026#34; .Params.articleCount }}\u0026lt;/p\u0026gt; {{/* Передача параметра .Count */}} Hugo автоматически выберет нужный перевод в зависимости от языка текущей страницы. Формы для плюрализации (one, few, many, other) очень важны для языков со сложными правилами множественного числа, как русский.\nСтруктура URL: Hugo гибок в настройке URL для разных языков.\nПо умолчанию, если defaultContentLanguageInSubdir не установлен или false, то контент на языке по умолчанию будет в корне сайта (например, example.com/my-post/), а другие языки в подпапках (example.com/en/my-post/). Если defaultContentLanguageInSubdir = true в hugo.toml, то даже язык по умолчанию будет в своей подпапке (example.com/ru/my-post/). Можно настроить разные домены или поддомены для каждого языка, указав baseURL для каждого языка в [languages.\u0026lt;code\u0026gt;] секции. Мультиязычность в Hugo – это большая, но хорошо продуманная тема. Если тебе это нужно, то Hugo предоставляет все инструменты, чтобы сделать это правильно и без лишней головной боли. Главное – аккуратно настроить конфиг и правильно организовать контент и переводы строк.\nНу как, не слишком загрузил? У нас по плану остался еще один пункт в \u0026ldquo;Расширенных возможностях\u0026rdquo; – обработка изображений. Это тоже весьма полезная штука.\nОбработка изображений (ресайз, кроп, вот это всё) Раз уж мы заговорили про ассеты, нельзя обойти стороной одну из самых ресурсоемких частей любого сайта – картинки. Hugo и тут не подкачал, предоставив мощные инструменты для обработки изображений прямо во время сборки. Забудь про ручное ресайз картинок в Photoshop для каждой превьюшки – Hugo сделает это за тебя.\nЧто это и зачем нужно? Hugo умеет на лету (при сборке сайта, конечно) изменять размеры изображений, обрезать их, конвертировать в другие форматы (привет, WebP!) и даже применять фильтры.\nПольза очевидна:\nПроизводительность: Ты можешь генерировать картинки ровно того размера, который нужен для конкретного места на сайте (превью, полноразмерное изображение, версия для мобильных). Меньше вес картинок – быстрее загрузка сайта, счастливее пользователи и поисковики. Автоматизация: Не надо вручную готовить 100500 вариантов каждой картинки. Написал один раз логику в шаблоне – и забыл. Арт-дирекшн: Полный контроль над тем, как изображения кадрируются или вписываются в дизайн. Современные форматы: Легко генерировать версии в WebP, которые обычно легче JPEG при том же качестве, и использовать их с фолбэком для старых браузеров. Как это работает: Ресурсы изображений\nЧтобы Hugo мог обработать изображение, оно должно быть \u0026ldquo;ресурсом\u0026rdquo;. Картинки могут быть двух типов ресурсов:\nРесурсы страницы (Page Resources): Это изображения, которые хранятся вместе с контентом страницы. Обычно это делается с помощью так называемых Page Bundles. Если у тебя есть пост content/posts/my-awesome-post/index.md, то все картинки, лежащие в папке content/posts/my-awesome-post/ (например, image1.jpg, hero.png), становятся ресурсами этой страницы.\nДоступ в шаблоне страницы: {{ $image := .Resources.GetMatch \u0026#34;image1.jpg\u0026#34; }} {{/* или перебрать все изображения */}} {{ range .Resources.ByType \u0026#34;image\u0026#34; }} {{/* . - текущий ресурс изображения */}} {{ end }} Глобальные ресурсы (Global Resources): Это изображения, которые лежат в папке assets/ (например, assets/images/logo.png). К ним можно получить доступ из любого шаблона через resources.Get:\n{{ $logo := resources.Get \u0026#34;images/logo.png\u0026#34; }} Получив такой объект-ресурс изображения ($image, $logo), ты можешь применять к нему различные методы обработки.\nОсновные методы обработки изображений:\nВсе методы применяются к объекту изображения и возвращают новый объект обработанного изображения.\n.Resize \u0026quot;ШИРИНАxВЫСОТА [ОПЦИИ]\u0026quot;: Изменяет размер.\n{{ $thumb := $image.Resize \u0026quot;300x\u0026quot; }} (ширина 300px, высота пропорционально) {{ $thumb := $image.Resize \u0026quot;x200\u0026quot; }} (высота 200px, ширина пропорционально) {{ $thumb := $image.Resize \u0026quot;300x200\u0026quot; }} (точно 300x200, пропорции могут поехать, если исходные не совпадают) Опции: qNN: Качество для JPEG/WebP (например, q75 – 75%). По умолчанию обычно 75. FILTER: Алгоритм ресемплинга (например, Lanczos (по умолчанию, хорошо для фото), CatmullRom, NearestNeighbor (для пиксель-арта), Box, Linear). hint: Для WebP (photo, picture, drawing). .Fit \u0026quot;ШИРИНАxВЫСОТА [ТОЧКА_ПРИВЯЗКИ] [ОПЦИИ]\u0026quot;: Масштабирует изображение так, чтобы оно полностью поместилось в указанные размеры, сохраняя пропорции. Если пропорции не совпадают, лишнее пространство будет пустым (если фон прозрачный) или закрашено (для JPEG). Чаще используется для того, чтобы вписать картинку без искажений, а затем, если нужно, обрезать до точных размеров с помощью .Fill или если сам .Fit подгоняет размер и потом обрезает \u0026ldquo;умно\u0026rdquo;. Hugo документация говорит \u0026ldquo;scales down the image using Resize and then crops the result from the center\u0026rdquo;.\n{{ $fitted := $image.Fit \u0026quot;300x200\u0026quot; }} {{ $fittedTopLeft := $image.Fit \u0026quot;300x200 TopLeft q90\u0026quot; }} (точка привязки для кадрирования, если оно происходит: Center, TopLeft, BottomRight и т.д.) .Fill \u0026quot;ШИРИНАxВЫСОТА [ТОЧКА_ПРИВЯЗКИ] [ОПЦИИ]\u0026quot;: Масштабирует изображение так, чтобы оно заполнило указанные размеры, сохраняя пропорции, а затем обрезает лишнее. Идеально для создания превьюшек фиксированного размера.\n{{ $filled := $image.Fill \u0026quot;300x200\u0026quot; }} (обрежет от центра) {{ $filledSmart := $image.Fill \u0026quot;300x200 Smart\u0026quot; }} (Smart Cropping, если доступно, пытается найти интересный объект) Конвертация формата (.Process \u0026quot;ФОРМАТ [ОПЦИИ_ФОРМАТА]\u0026quot;) Можно сконвертировать изображение в другой формат.\n{{ $webp := $image.Process \u0026quot;webp\u0026quot; }} {{ $jpgHighQ := $image.Process \u0026quot;jpeg q95\u0026quot; }} Можно объединять с другими методами: {{ $thumbWebp := $image.Resize \u0026#34;300x\u0026#34; | .Process \u0026#34;webp q80\u0026#34; }} Поддерживаемые выходные форматы: jpeg, png, webp, gif.\nФильтры (.Filter ФИЛЬТР1 [ФИЛЬТР2 ...]): Hugo позволяет применять различные графические фильтры.\n{{ $sepiaImage := $image.Filter (images.Sepia 80) }} {{/* Сепия 80% */}} {{ $blurredImage := $image.Filter (images.GaussianBlur 5) }} {{/* Размытие по Гауссу с радиусом 5 */}} {{ $grayscale := $image.Filter images.Grayscale }} Для использования этих фильтров (images.Sepia, images.GaussianBlur и т.д.) убедись, что пакет images доступен (в современных версиях Hugo он обычно доступен глобально).\nИспользование обработанных изображений в шаблонах: Результат любой операции обработки – это новый объект изображения со своими свойствами:\n.RelPermalink / .Permalink: Ссылка на сгенерированный файл изображения. .Width: Ширина полученного изображения. .Height: Высота полученного изображения. .MediaType: MIME-тип. Пример вставки:\n{{ $original := .Resources.GetMatch \u0026#34;photo.jpg\u0026#34; }} {{ if $original }} {{ $thumb := $original.Resize \u0026#34;400x q85\u0026#34; }} \u0026lt;img src=\u0026#34;{{ $thumb.RelPermalink }}\u0026#34; width=\u0026#34;{{ $thumb.Width }}\u0026#34; height=\u0026#34;{{ $thumb.Height }}\u0026#34; alt=\u0026#34;Мое обработанное фото\u0026#34;\u0026gt; {{ end }} Создание адаптивных изображений (Responsive Images) с srcset или \u0026lt;picture\u0026gt;: Это одна из главных причин использовать обработку изображений. Ты можешь сгенерировать несколько вариантов картинки для разных размеров экрана.\nПример с srcset:\n{{ $original := .Resources.GetMatch \u0026#34;hero.jpg\u0026#34; }} {{ if $original }} {{ $small := $original.Resize \u0026#34;600x\u0026#34; }} {{ $medium := $original.Resize \u0026#34;900x\u0026#34; }} {{ $large := $original.Resize \u0026#34;1200x\u0026#34; }} {{ $smallWebp := $small.Process \u0026#34;webp\u0026#34; }} {{ $mediumWebp := $medium.Process \u0026#34;webp\u0026#34; }} {{ $largeWebp := $large.Process \u0026#34;webp\u0026#34; }} \u0026lt;picture\u0026gt; \u0026lt;source srcset=\u0026#34;{{ $smallWebp.RelPermalink }} 600w, {{ $mediumWebp.RelPermalink }} 900w, {{ $largeWebp.RelPermalink }} 1200w\u0026#34; type=\u0026#34;image/webp\u0026#34; sizes=\u0026#34;(max-width: 700px) 90vw, (max-width: 1000px) 60vw, 1200px\u0026#34;\u0026gt; \u0026lt;source srcset=\u0026#34;{{ $small.RelPermalink }} 600w, {{ $medium.RelPermalink }} 900w, {{ $large.RelPermalink }} 1200w\u0026#34; type=\u0026#34;{{ $original.MediaType }}\u0026#34; sizes=\u0026#34;(max-width: 700px) 90vw, (max-width: 1000px) 60vw, 1200px\u0026#34;\u0026gt; \u0026lt;img src=\u0026#34;{{ $medium.RelPermalink }}\u0026#34; width=\u0026#34;{{ $medium.Width }}\u0026#34; height=\u0026#34;{{ $medium.Height }}\u0026#34; alt=\u0026#34;Адаптивный герой\u0026#34; loading=\u0026#34;lazy\u0026#34;\u0026gt; \u0026lt;/picture\u0026gt; {{ end }} Здесь мы создаем три размера (small, medium, large) и для каждого еще и WebP версию. Затем с помощью тега \u0026lt;picture\u0026gt; даем браузеру выбор: если он поддерживает WebP – будет грузить его, если нет – обычный JPEG/PNG. Атрибут sizes помогает браузеру понять, какую картинку выбрать в зависимости от ширины viewport и как картинка отображается.\nПроизводительность сборки и кэширование: Обработка изображений, особенно на больших сайтах, может занимать время при первой сборке. Hugo умный и кэширует результаты обработки в папке resources/_gen/images/ (или похожей). При последующих сборках, если исходное изображение и параметры обработки не изменились, Hugo возьмет результат из кэша. Этот кэш можно безопасно удалить, если нужно принудительно перегенерировать все картинки.\nКачество и форматы: Экспериментируй с параметром качества (qNN). Для WebP часто можно ставить качество ниже, чем для JPEG, при сохранении визуальной составляющей. WebP почти всегда дает лучший результат по соотношению размер/качество, чем JPEG.\nВот так, инженер. Теперь ты можешь не только писать контент и верстать шаблоны, но и командовать Hugo, как ему обращаться с графикой, чтобы твой сайт был не только красивым, но и быстрым. Это закрывает наш блок про \u0026ldquo;Расширенные возможности\u0026rdquo;.\nДальше по плану – \u0026ldquo;Сборка и деплой\u0026rdquo;. Поговорим о том, как из всего этого получить готовый сайт и выложить его в интернет. Готов к финальному рывку перед практическими советами?\n7. Сборка и деплой Отлично, инженер! Ты прошел огонь, воду и медные Hugo Pipes. Теперь у тебя есть знания, чтобы собрать из кучи Markdown-файлов, шаблонов и ассетов настоящий, работающий сайт. Осталось понять, как этот сайт, собственно, \u0026ldquo;собрать\u0026rdquo; в готовый продукт и куда его потом пристроить, чтобы мир его увидел.\nЭтот этап – венец творения. Из кучи исходников мы получим пачку статических HTML, CSS, JS и картинок, готовую к выкладке в интернет.\nКоманда hugo – собираем статику Если команда hugo server служила тебе верой и правдой для локальной разработки, то для создания финальной версии сайта используется просто команда hugo.\nОсновная команда: Открываешь терминал в корневой папке твоего проекта и выполняешь:\nhugo По умолчанию, Hugo соберет твой сайт и сложит все готовые файлы в папку public/ в корне проекта. Именно содержимое этой папки public/ ты и будешь выкладывать на хостинг.\nВажные флаги для команды hugo:\n-D, --buildDrafts: Включить в сборку черновики (страницы с draft: true). Обычно для продакшена это не нужно! Но может пригодиться для тестовых сборок. -E, --buildExpired: Включить страницы с истекшим сроком годности. -F, --buildFuture: Включить страницы с будущей датой публикации. --cleanDestinationDir: Перед сборкой Hugo удалит все содержимое из папки назначения (public/ по умолчанию). Полезно, чтобы там не оставались старые, уже не нужные файлы от предыдущих сборок. --minify: Глобальный флаг, который попытается минифицировать HTML, CSS, JS, JSON, SVG, XML. Hugo делает это довольно неплохо. Хорошая опция для продакшена, если ты не настроил более тонкую минификацию через Hugo Pipes. --environment \u0026lt;имя_окружения\u0026gt;: Явно указать окружение для сборки (например, production, staging). Помнишь, мы говорили про config/production/hugo.toml? Вот этот флаг (или переменная HUGO_ENV) говорит Hugo, какой конфиг использовать. По умолчанию команда hugo (без server) использует окружение production. --destination \u0026lt;путь\u0026gt;: Указать другую папку для выходных файлов вместо public/. -v, --verbose: Вывести более подробную информацию о процессе сборки. Полезно для отладки. --gc или --gc --minify (--gc означает \u0026ldquo;garbage collect\u0026rdquo; и может немного оптимизировать, а в связке с --minify это популярная команда для прод сборки): Эта команда включает сборку мусора для кэшей ресурсов и минификацию. Часто используется в CI/CD. Пример команды для продакшен-сборки:\nhugo --gc --minify --cleanDestinationDir Эта команда почистит папку public/, соберет сайт для продакшена (используя конфиг production), минифицирует всё, что можно, и оптимизирует ресурсы.\nОптимизация для продакшена (минификация всего и вся) Мы уже касались этого в Hugo Pipes и флагах, но давай подытожим. Чтобы твой сайт летал, его ассеты должны быть как можно меньше.\nCSS:\nВ Hugo Pipes используй outputStyle: \u0026quot;compressed\u0026quot; при вызове toCSS для SASS/SCSS. Или пропускай через | minify. JavaScript:\nВ Hugo Pipes используй minify: true в опциях js.Build. Или пропускай через | minify. HTML:\nФлаг hugo --minify минифицирует и HTML. Можно также настроить минификацию HTML в hugo.toml: [minify] disableHTML = false # html = # тут можно указать более тонкие настройки для HTML минификатора TDewolff # preserveComments = false # по умолчанию Или глобально minifyOutput = true (устаревший, лучше использовать секцию minify). Изображения:\nИспользуй обработку изображений Hugo для ресайза и выбора правильного качества (qNN). Конвертируй в WebP для лучшего сжатия с фолбэком на JPEG/PNG. Фингерпринтинг: Не забывай | fingerprint для CSS и JS в Hugo Pipes. Это не уменьшает размер, но помогает с кэшированием в браузере – при изменении файла изменится его имя, и браузер гарантированно скачает новую версию.\nЦель – выжать максимум из каждого байта. Статический сайт должен быть легким и быстрым.\nКуда деплоить (Netlify, Vercel, GitHub Pages, свой сраный VPS – вариантов масса) Итак, у тебя есть папка public/ со статикой. Куда это добро девать? Вариантов – вагон и маленькая тележка.\nПлатформы для статики (Netlify, Vercel, Cloudflare Pages):\nNetlify (netlify.com): Пожалуй, самый популярный выбор для Hugo. Отличный бесплатный тариф, встроенный CI/CD (подключаешь Git-репозиторий, и сайт собирается/деплоится на каждый пуш), CDN, кастомные домены, бесплатный SSL, serverless-функции, формы, аналитика. Очень удобно. Vercel (vercel.com): Очень похож на Netlify, от создателей Next.js. Тоже мощный, быстрый, с отличным бесплатным тарифом и CI/CD. Cloudflare Pages (pages.cloudflare.com): Сравнительно новый игрок, но быстро набирает популярность. Интеграция с глобальной сетью Cloudflare, бесплатный тариф, CI/CD. Эти платформы идеальны для Hugo: они понимают статику, умеют ее быстро раздавать по всему миру и берут на себя всю головную боль с инфраструктурой.\nХостинг на базе Git (GitHub Pages, GitLab Pages):\nGitHub Pages (pages.github.com): Бесплатный хостинг прямо из твоего GitHub-репозитория. Можно настроить сборку через GitHub Actions. Немного более базовый, чем Netlify/Vercel, но для простых сайтов – самое то. GitLab Pages: Аналог от GitLab. Облачные хранилища + CDN (AWS S3, Google Cloud Storage):\nAWS S3 + CloudFront: Ты можешь настроить S3-бакет для хостинга статики и подключить CloudFront (CDN от Amazon) для быстрой раздачи. Более сложная настройка, но очень гибко и масштабируемо. Потенциально дороже, если трафик большой. Аналогично с Google Cloud Storage + Google CDN. Firebase Hosting (firebase.google.com/products/hosting): Еще один отличный вариант от Google. Быстрый CDN, бесплатный SSL, кастомные домены, простой деплой через Firebase CLI.\n\u0026ldquo;Свой сраный VPS\u0026rdquo; (DigitalOcean, Linode, Hetzner, любой другой хостер): Если ты любишь полный контроль и не боишься командной строки Linux, то это твой выбор.\nПокупаешь VPS. Устанавливаешь веб-сервер (Nginx или Apache). Настраиваешь его на раздачу статики из какой-нибудь папки (например, /var/www/mysite). Копируешь содержимое твоей public/ в эту папку (например, через scp или rsync). Настраиваешь DNS для своего домена. Устанавливаешь SSL-сертификат (Let\u0026rsquo;s Encrypt через Certbot – бесплатно и просто). Следишь за обновлениями сервера, безопасностью и т.д. Больше работы, но ты сам себе хозяин. Что выбрать? Для большинства проектов, особенно личных или небольших корпоративных, Netlify, Vercel или Cloudflare Pages – это идеальный старт. Быстро, удобно, часто бесплатно.\nCI/CD – автоматизируем рутину CI/CD (Continuous Integration / Continuous Deployment или Delivery) – это практика автоматизации сборки, тестирования и развертывания твоего сайта (или приложения) каждый раз, когда ты вносишь изменения в код (например, делаешь git push). Для статических сайтов это просто манна небесная.\nКак это работает (общая схема):\nТы пишешь код, создаешь контент, коммитишь и пушишь изменения в свой Git-репозиторий (GitHub, GitLab, Bitbucket). Сервис CI/CD (Netlify, GitHub Actions, GitLab CI и т.д.) замечает этот пуш. Он автоматически запускает процесс: Создает временное окружение. Клонирует твой репозиторий. Устанавливает нужную версию Hugo (и другие зависимости, если есть, например, для PostCSS). Выполняет команду сборки Hugo (например, hugo --gc --minify). (Опционально) Запускает тесты, если они у тебя есть. Если все успешно, он копирует содержимое папки public/ на твой хостинг. Платформы для CI/CD:\nNetlify, Vercel, Cloudflare Pages: У них CI/CD встроен. Ты просто подключаешь свой Git-репозиторий, указываешь команду сборки (часто они сами определяют, что это Hugo, и предлагают команду типа hugo) и папку для публикации (public). Всё. Магия происходит автоматически. Они также часто предлагают \u0026ldquo;deploy previews\u0026rdquo; – для каждого pull request создается временная версия сайта, чтобы ты мог посмотреть изменения перед мержем. GitHub Actions: Мощный и гибкий инструмент CI/CD прямо в GitHub. Ты создаешь YAML-файл с описанием воркфлоу в папке .github/workflows/ твоего репозитория. Пример простого воркфлоу для сборки Hugo и деплоя на GitHub Pages: # .github/workflows/hugo-deploy.yml name: Deploy Hugo site to Pages on: push: branches: - main # или master, в зависимости от твоей основной ветки pull_request: jobs: build-deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 with: submodules: true # Fetch Hugo themes (true OR recursive) fetch-depth: 0 # Fetch all history for .GitInfo and .Lastmod - name: Setup Hugo uses: peaceiris/actions-hugo@v2 with: hugo-version: \u0026#39;latest\u0026#39; # или конкретная версия \u0026#39;0.125.0\u0026#39; extended: true - name: Build run: hugo --gc --minify # Ваша команда сборки - name: Deploy to GitHub Pages uses: peaceiris/actions-gh-pages@v3 if: github.ref == \u0026#39;refs/heads/main\u0026#39; # Деплоить только если пуш в main with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./public # cname: your.custom.domain.com # Если используешь кастомный домен GitLab CI/CD: Использует файл .gitlab-ci.yml в корне репозитория. Логика похожа на GitHub Actions. Преимущества CI/CD:\nЭкономия времени: Не надо каждый раз вручную собирать и заливать сайт. Надежность: Автоматизированный процесс уменьшает риск человеческой ошибки. Быстрые итерации: Сделал изменение, запушил – через пару минут оно на сайте. Спокойствие: Ты знаешь, что если сборка прошла успешно, то на сайт выкатилась рабочая версия. Автоматизация деплоя – это то, что должен настроить каждый уважающий себя инженер. Это сильно упрощает жизнь.\nНу вот, мы и дошли до конца основного технического материала. Теперь ты знаешь, как установить Hugo, как создавать контент и шаблоны, как использовать его продвинутые фичи, и как, наконец, собрать и выложить свой шедевр в мир.\nОстался последний блок – \u0026ldquo;Лучшие практики и подводные камни\u0026rdquo;. Это уже больше про опыт и советы, чтобы не наступать на грабли. Как, есть еще силенки?\n8. Лучшие практики и подводные камни Раз ты еще тут и готов слушать, значит, ты действительно настроен серьезно. Это последний рывок – поговорим о том, как не наломать дров и сделать твой путь с Hugo более гладким. Это уже не столько про фичи, сколько про здравый смысл и опыт, который приходит с набитыми шишками.\nСчитай это советами от старого ворчуна, который видел всякое.\nОрганизация проекта (чтобы потом самому не охренеть) Hugo дает тебе свободу, но свобода без дисциплины превращается в хаос.\nСтруктура – твой друг:\nИмена файлов и папок: Придерживайся единого стиля. Обычно это kebab-case (слова-через-дефис) для файлов и папок. Латиница, естественно. content/: Логично группируй контент по секциям. Не вали всё в одну кучу. layouts/: Используй подпапки для разных типов шаблонов (_default, posts, partials, shortcodes). Если partials много, делай и в partials/ подпапки (widgets, seo, navigation). assets/: Тоже структурируй (scss, js, images). hugo.toml (или config/): Держи главный конфиг в чистоте. Комментируй не очевидные настройки. Если конфиг разрастается, подумай о переходе на директорию config/ с разбивкой по файлам (params.toml, menus.toml и т.д.). Git – с самого начала: Даже для маленького личного сайта. Инициализируй репозиторий сразу. Делай осмысленные коммиты. Это спасет тебе кучу нервов, когда что-то пойдет не так или ты захочешь откатиться.\nТема vs. Локальные layouts/:\nЕсли берешь готовую тему, старайся не править ее файлы напрямую. Лучше переопределяй нужные шаблоны, копируя их из папки темы в свою корневую папку layouts/ с сохранением структуры. Так ты сможешь обновлять тему, не теряя свои кастомизации. Если делаешь сайт с нуля, то все твои шаблоны будут в корневых layouts/ и assets/. Документируй сложное: Если ты написал хитрый шорткод или сложный partial, оставь комментарии для себя будущего (или для коллег). Что он делает, какие параметры принимает.\nАрхетипы – наше всё: Для каждого типа контента создай свой архетип в archetypes/. Это обеспечит единообразие Front Matter и сэкономит время.\nПроизводительность (как не сделать тормознутый сайт на статике) Статика по определению быстрая, но и ее можно засрать.\nКартинки, картинки, картинки!\nОптимизируй: Используй встроенную обработку Hugo для ресайза, сжатия (адекватное qNN). Адаптивность: srcset и \u0026lt;picture\u0026gt; – твои лучшие друзья. Не гоняй десктопные картинки на мобилки. WebP: Используй с фолбэком на JPEG/PNG. Lazy Loading: Для картинок и iframe, которые не видны сразу – loading=\u0026quot;lazy\u0026quot;. Минифицируй всё: CSS, JS, HTML. Hugo Pipes и флаг --minify тебе в помощь.\nКритический CSS (по возможности): Это сложнее, но для супер-скорости можно встраивать стили для первого экрана прямо в \u0026lt;head\u0026gt;. Hugo сам по себе это из коробки не делает так просто, но через partials и readFile (или resources.Get.Content) можно что-то придумать для небольших кусков CSS.\nНе увлекайся сложной логикой в шаблонах на больших сайтах: Если у тебя 10 000+ страниц, частые переборы .Site.Pages без фильтрации (where) могут замедлить сборку. Используй секции, таксономии, first, after для пагинации.\npartialCached – твой друг (иногда): Для сложных и часто повторяющихся partials, которые не сильно зависят от контекста, используй кэширование. Но без фанатизма, замеряй время сборки.\nJavaScript – по минимуму: Статический сайт тем и хорош, что не требует тонны JS. Если можешь обойтись без JS или сделать что-то на чистом CSS – делай. Если JS нужен – пусть он будет легким и асинхронным/отложенным (async/defer).\nХостинг/CDN: Даже самый быстрый сайт будет тормозить на медленном хостинге. Выбирай проверенные решения с CDN.\nОтладка (когда всё пошло\u0026hellip; не так) Рано или поздно что-то сломается. Это нормально. Главное – знать, где искать.\nЧитай ошибки Hugo: Когда сборка падает, Hugo обычно пишет, что ему не нравится. Эти сообщения часто очень информативны. Читай их внимательно, там обычно указан файл и строка.\nhugo server -D --verbose или hugo -v: Более подробный вывод процесса сборки может натолкнуть на мысль.\nОтладка шаблонов – твой главный инструмент printf и jsonify:\nХочешь посмотреть, что у тебя в текущем контексте . или в какой-то переменной $myVar? {{ printf \u0026#34;%#v\u0026#34; . }} \u0026lt;pre\u0026gt;{{ . | jsonify (dict \u0026#34;indent\u0026#34; \u0026#34; \u0026#34;) }}\u0026lt;/pre\u0026gt; ``` Это бесценно для понимания, какие данные тебе доступны. {{ errorf \u0026quot;ОШИБКА: Мое значение Title = %s\u0026quot; .Title }}: Искусственно вызываешь ошибку сборки, чтобы остановить процесс и посмотреть значения или проверить условие. Комментируй куски шаблона ({{/* ... */}}), чтобы локализовать проблему. Проверяй public/: Иногда в браузере черт-те что, а почему – неясно. Посмотри, какой HTML Hugo реально сгенерировал в папке public/. Может, там классы не те, или ссылки битые.\nFront Matter и конфиг: Опечатки в YAML/TOML – частая причина проблем. Проверяй синтаксис, отступы (в YAML), кавычки.\nКонтекст \u0026ldquo;точки\u0026rdquo; (.): Самая частая головная боль новичков. Всегда спрашивай себя: \u0026ldquo;А что такое . в этом конкретном месте шаблона?\u0026rdquo;. Особенно внутри range или в partials.\nHugo Discourse Форум (discourse.gohugo.io): Если совсем зашел в тупик – иди туда. Сообщество Hugo очень отзывчивое, помогут. Только сначала сам попытайся разобраться и четко сформулируй вопрос.\nТипичные ошибки новичков (и не очень) baseURL: Забыли указать или указали неправильно для продакшена. Результат – битые ссылки, неработающие CSS/JS. static/ vs assets/: Путают, куда что класть. Помни: assets/ – для того, что обрабатывается Hugo Pipes, static/ – для всего остального, что копируется \u0026ldquo;как есть\u0026rdquo;. Порядок поиска шаблонов: Hugo очень строг. Если твой шаблон не подхватывается, проверь его имя и расположение согласно \u0026ldquo;Lookup Order\u0026rdquo;. Контекст .: См. выше. Понимание этого приходит с опытом. Синтаксис шаблонов: Незакрытые {{ end }}, опечатки в именах функций или переменных. ref/relref: Не используют для внутренних ссылок, а потом при изменении структуры всё ломается. Используй их всегда! extended версия Hugo: Забывают установить, а потом удивляются, почему SASS/SCSS не компилируется. Пути к ресурсам в resources.Get: Должны быть относительно папки assets/ (или content/ для Page Resources). Излишнее усложнение: Пытаются сразу сделать всё и вся, используя самые навороченные фичи. Начинай с простого, наращивай сложность постепенно. Непонимание, что Hugo Pipes генерирует файлы с хэшем: Пытаются напрямую сослаться на assets/scss/main.scss в HTML вместо {{ $style.RelPermalink }}. Это, конечно, не все грабли, но самые популярные. Главное – не бояться экспериментировать, читать документацию и учиться на ошибках (желательно, на чужих, подсмотренных на форуме).\nНу вот, инженер. Мы с тобой прошли большой путь. Надеюсь, этот гайддал тебе хорошую базу и понимание, что такое Hugo и как с ним работать. Инструмент мощный, гибкий, и если ты с ним подружишься, он сослужит тебе хорошую службу.\nОсталось только одно – практика. Бери и делай. Удачи!\n","permalink":"https://meshrefine.com/ru/conversations/about_hugo/","summary":"\u003ch2 id=\"оглавление-гайда-по-hugo-для-суровых-инженеров\"\u003eОглавление гайда по Hugo для суровых инженеров:\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%be%d0%b3%d0%bb%d0%b0%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b3%d0%b0%d0%b9%d0%b4%d0%b0-%d0%bf%d0%be-hugo-%d0%b4%d0%bb%d1%8f-%d1%81%d1%83%d1%80%d0%be%d0%b2%d1%8b%d1%85-%d0%b8%d0%bd%d0%b6%d0%b5%d0%bd%d0%b5%d1%80%d0%be%d0%b2\"\u003eОглавление гайда по Hugo для суровых инженеров:\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#1-%d0%b2%d0%b2%d0%be%d0%b4%d0%bd%d0%b0%d1%8f-%d0%b4%d0%bb%d1%8f-%d1%82%d0%b5%d1%85-%d0%ba%d1%82%d0%be-%d0%bd%d0%b5-%d0%b2-%d1%82%d0%b5%d0%bc%d0%b5\"\u003e1. Вводная для тех, кто не в теме\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d1%87%d1%82%d0%be-%d0%b7%d0%b0-%d0%b7%d0%b2%d0%b5%d1%80%d1%8c-%d1%8d%d1%82%d0%be%d1%82-hugo-%d0%b8-%d0%bd%d0%b0-%d0%ba%d0%be%d0%b9-%d1%85%d1%80%d0%b5%d0%bd-%d0%be%d0%bd-%d0%bd%d1%83%d0%b6%d0%b5%d0%bd\"\u003eЧто за зверь этот Hugo и на кой хрен он нужен?\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%bf%d0%be%d1%87%d0%b5%d0%bc%d1%83-%d1%81%d1%82%d0%b0%d1%82%d0%b8%d0%ba%d0%b0--%d1%8d%d1%82%d0%be-%d0%b7%d0%b0%d1%88%d0%b8%d0%b1%d0%b8%d1%81%d1%8c-%d0%ba%d1%80%d0%b0%d1%82%d0%ba%d0%b8%d0%b9-%d0%bb%d0%b8%d0%ba%d0%b1%d0%b5%d0%b7-%d0%bf%d0%be-%d0%bf%d1%80%d0%b5%d0%b8%d0%bc%d1%83%d1%89%d0%b5%d1%81%d1%82%d0%b2%d0%b0%d0%bc\"\u003eПочему статика – это зашибись (краткий ликбез по преимуществам)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%ba%d0%be%d0%b3%d0%b4%d0%b0-hugo--%d1%82%d0%b2%d0%be%d0%b9-%d0%b2%d1%8b%d0%b1%d0%be%d1%80-%d0%b0-%d0%ba%d0%be%d0%b3%d0%b4%d0%b0-%d0%bb%d1%83%d1%87%d1%88%d0%b5-%d0%b4%d0%b0%d0%b6%d0%b5-%d0%bd%d0%b5-%d0%bd%d0%b0%d1%87%d0%b8%d0%bd%d0%b0%d1%82%d1%8c\"\u003eКогда Hugo – твой выбор, а когда лучше даже не начинать\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#2-%d0%b1%d1%8b%d1%81%d1%82%d1%80%d1%8b%d0%b9-%d1%81%d1%82%d0%b0%d1%80%d1%82-%d1%87%d1%82%d0%be%d0%b1%d1%8b-%d1%81%d1%80%d0%b0%d0%b7%d1%83-%d0%b2-%d0%b1%d0%be%d0%b9\"\u003e2. Быстрый старт, чтобы сразу в бой\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d1%83%d1%81%d1%82%d0%b0%d0%bd%d0%be%d0%b2%d0%ba%d0%b0-%d0%b1%d0%b5%d0%b7-%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b9-%d0%b2%d0%be%d0%b4%d1%8b-%d0%bf%d0%be-%d1%81%d0%bf%d0%b0%d1%80%d1%82%d0%b0%d0%bd%d1%81%d0%ba%d0%b8\"\u003eУстановка (без лишней воды, по-спартански)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#hugo-new-site-%d0%bc%d0%be%d0%b9_%d1%81%d1%83%d0%bf%d0%b5%d1%80_%d1%81%d0%b0%d0%b9%d1%82--%d1%81%d0%be%d0%b7%d0%b4%d0%b0%d0%b5%d0%bc-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82-%d0%b7%d0%b0-%d1%82%d1%80%d0%b8-%d1%81%d0%b5%d0%ba%d1%83%d0%bd%d0%b4%d1%8b\"\u003e\u003ccode\u003ehugo new site мой_супер_сайт\u003c/code\u003e – создаем проект за три секунды\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d1%81%d1%82%d1%80%d1%83%d0%ba%d1%82%d1%83%d1%80%d0%b0-%d0%ba%d0%b0%d1%82%d0%b0%d0%bb%d0%be%d0%b3%d0%be%d0%b2-hugo-%d1%87%d1%82%d0%be-%d0%b3%d0%b4%d0%b5-%d0%b8-%d0%bf%d0%be%d1%87%d0%b5%d0%bc%d1%83-%d0%b8%d0%bc%d0%b5%d0%bd%d0%bd%d0%be-%d1%82%d0%b0%d0%ba\"\u003eСтруктура каталогов Hugo: что, где и почему именно так\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#hugo-server--d--%d0%b7%d0%b0%d0%bf%d1%83%d1%81%d0%ba%d0%b0%d0%b5%d0%bc-%d0%bb%d0%be%d0%ba%d0%b0%d0%bb%d1%8c%d0%bd%d1%8b%d0%b9-%d1%81%d0%b5%d1%80%d0%b2%d0%b5%d1%80-%d0%b8-%d1%81%d0%bc%d0%be%d1%82%d1%80%d0%b8%d0%bc-%d1%87%d1%82%d0%be-%d0%bf%d0%be%d0%bb%d1%83%d1%87%d0%b8%d0%bb%d0%be%d1%81%d1%8c\"\u003e\u003ccode\u003ehugo server -D\u003c/code\u003e – запускаем локальный сервер и смотрим, что получилось\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#3-%d0%ba%d0%be%d0%bd%d1%82%d0%b5%d0%bd%d1%82--%d0%b2%d1%81%d0%b5%d0%bc%d1%83-%d0%b3%d0%be%d0%bb%d0%be%d0%b2%d0%b0\"\u003e3. Контент – всему голова\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#markdown--%d1%82%d0%b2%d0%be%d0%b9-%d0%be%d1%81%d0%bd%d0%be%d0%b2%d0%bd%d0%be%d0%b9-%d0%b8%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%bc%d0%b5%d0%bd%d1%82-%d1%84%d0%b8%d1%87%d0%b8-%d0%b8-%d0%ba%d0%b0%d0%ba-%d0%b8%d0%bc-%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d0%be%d0%b2%d0%b0%d1%82%d1%8c%d1%81%d1%8f-%d0%bf%d0%be-%d1%87%d0%b5%d0%bb%d0%be%d0%b2%d0%b5%d1%87%d0%b5%d1%81%d0%ba%d0%b8\"\u003eMarkdown – твой основной инструмент. Фичи и как им пользоваться по-человечески.\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#front-matter-yamltomljson--%d0%bc%d0%b5%d1%82%d0%b0%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d0%b5-%d0%b4%d0%bb%d1%8f-%d1%82%d0%b2%d0%be%d0%b8%d1%85-%d1%81%d1%82%d1%80%d0%b0%d0%bd%d0%b8%d1%86-%d0%b7%d0%b0%d1%87%d0%b5%d0%bc-%d0%b8-%d0%ba%d0%b0%d0%ba\"\u003eFront Matter (YAML/TOML/JSON) – метаданные для твоих страниц. Зачем и как.\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d1%82%d0%b8%d0%bf%d1%8b-%d0%ba%d0%be%d0%bd%d1%82%d0%b5%d0%bd%d1%82%d0%b0-content-types-%d0%bf%d0%be%d1%81%d1%82%d1%8b-%d1%81%d1%82%d1%80%d0%b0%d0%bd%d0%b8%d1%86%d1%8b-%d0%ba%d0%b0%d1%81%d1%82%d0%be%d0%bc%d0%bd%d1%8b%d0%b5-%d1%80%d0%b0%d0%b7%d0%b4%d0%b5%d0%bb%d1%8b\"\u003eТипы контента (\u003ccode\u003econtent types\u003c/code\u003e): посты, страницы, кастомные разделы.\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d1%82%d0%b0%d0%ba%d1%81%d0%be%d0%bd%d0%be%d0%bc%d0%b8%d0%b8-%d0%ba%d0%b0%d1%82%d0%b5%d0%b3%d0%be%d1%80%d0%b8%d0%b8-%d1%82%d0%b5%d0%b3%d0%b8-%d0%b8-%d0%bf%d1%80%d0%be%d1%87%d0%b0%d1%8f-%d1%81%d0%be%d1%80%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%ba%d0%b0-%d0%ba%d0%be%d0%bd%d1%82%d0%b5%d0%bd%d1%82%d0%b0\"\u003eТаксономии: категории, теги и прочая сортировка контента.\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%b0%d1%80%d1%85%d0%b5%d1%82%d0%b8%d0%bf%d1%8b-%d1%88%d0%b0%d0%b1%d0%bb%d0%be%d0%bd%d1%8b-%d0%b4%d0%bb%d1%8f-%d1%81%d0%be%d0%b7%d0%b4%d0%b0%d0%bd%d0%b8%d1%8f-%d0%be%d0%b4%d0%bd%d0%be%d1%82%d0%b8%d0%bf%d0%bd%d0%be%d0%b3%d0%be-%d0%ba%d0%be%d0%bd%d1%82%d0%b5%d0%bd%d1%82%d0%b0-%d1%87%d1%82%d0%be%d0%b1%d1%8b-%d0%bd%d0%b5-%d0%ba%d0%be%d0%bf%d0%b8%d0%bf%d0%b0%d1%81%d1%82%d0%b8%d1%82%d1%8c\"\u003eАрхетипы: шаблоны для создания однотипного контента, чтобы не копипастить.\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#4-%d1%88%d0%b0%d0%b1%d0%bb%d0%be%d0%bd%d1%8b--%d0%bb%d0%b8%d1%86%d0%be-%d1%81%d0%b0%d0%b9%d1%82%d0%b0\"\u003e4. Шаблоны – лицо сайта\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#go-templates--%d0%be%d1%81%d0%bd%d0%be%d0%b2%d1%8b-%d0%be%d1%81%d0%bd%d0%be%d0%b2-%d1%81%d0%b8%d0%bd%d1%82%d0%b0%d0%ba%d1%81%d0%b8%d1%81-%d0%bf%d0%b5%d1%80%d0%b5%d0%bc%d0%b5%d0%bd%d0%bd%d1%8b%d0%b5-%d1%84%d1%83%d0%bd%d0%ba%d1%86%d0%b8%d0%b8\"\u003eGo Templates – основы основ (синтаксис, переменные, функции)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%b1%d0%b0%d0%b7%d0%be%d0%b2%d1%8b%d0%b5-%d1%88%d0%b0%d0%b1%d0%bb%d0%be%d0%bd%d1%8b-%d0%b8-%d0%b1%d0%bb%d0%be%d0%ba%d0%b8-dry-%d0%bc%d0%b0%d1%82%d1%8c-%d0%b5%d0%b3%d0%be\"\u003eБазовые шаблоны и блоки (DRY, мать его)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d1%81%d0%bf%d0%b8%d1%81%d0%ba%d0%be%d0%b2%d1%8b%d0%b5-%d1%81%d1%82%d1%80%d0%b0%d0%bd%d0%b8%d1%86%d1%8b-%d0%b8%d0%bd%d0%b4%d0%b5%d0%ba%d1%81%d1%8b-%d0%ba%d0%b0%d1%82%d0%b5%d0%b3%d0%be%d1%80%d0%b8%d0%b8-%d1%82%d0%b5%d0%b3%d0%b8-%d0%b8-%d1%82%d0%b4\"\u003eСписковые страницы (индексы, категории, теги и т.д.)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%be%d0%b4%d0%b8%d0%bd%d0%be%d1%87%d0%bd%d1%8b%d0%b5-%d1%81%d1%82%d1%80%d0%b0%d0%bd%d0%b8%d1%86%d1%8b-%d0%b4%d0%b5%d1%82%d0%b0%d0%bb%d0%ba%d0%b0-%d0%bf%d0%be%d1%81%d1%82%d0%b0%d1%81%d1%82%d1%80%d0%b0%d0%bd%d0%b8%d1%86%d1%8b\"\u003eОдиночные страницы (деталка поста/страницы)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#partials-%d0%bf%d0%b5%d1%80%d0%b5%d0%b8%d1%81%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d1%83%d0%b5%d0%bc%d1%8b%d0%b5-%d0%ba%d1%83%d1%81%d0%ba%d0%b8-%d0%ba%d0%be%d0%b4%d0%b0\"\u003ePartials (переиспользуемые куски кода)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%b2%d1%81%d1%82%d1%80%d0%be%d0%b5%d0%bd%d0%bd%d1%8b%d0%b5-%d0%bf%d0%b5%d1%80%d0%b5%d0%bc%d0%b5%d0%bd%d0%bd%d1%8b%d0%b5-hugo-page-site--%d1%87%d1%82%d0%be-%d0%b4%d0%be%d1%81%d1%82%d1%83%d0%bf%d0%bd%d0%be-%d0%b8%d0%b7-%d0%ba%d0%be%d1%80%d0%be%d0%b1%d0%ba%d0%b8\"\u003eВстроенные переменные Hugo (\u003ccode\u003e.Page\u003c/code\u003e, \u003ccode\u003e.Site\u003c/code\u003e – что доступно из коробки)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#5-%d0%ba%d0%be%d0%bd%d1%84%d0%b8%d0%b3%d1%83%d1%80%d0%b0%d1%86%d0%b8%d1%8f--%d1%80%d1%83%d0%bb%d0%b8%d0%bc-%d0%b2%d1%81%d0%b5%d0%bc-%d0%b8%d0%b7-%d0%be%d0%b4%d0%bd%d0%be%d0%b3%d0%be-%d0%bc%d0%b5%d1%81%d1%82%d0%b0\"\u003e5. Конфигурация – рулим всем из одного места\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d1%84%d0%b0%d0%b9%d0%bb-%d0%ba%d0%be%d0%bd%d1%84%d0%b8%d0%b3%d1%83%d1%80%d0%b0%d1%86%d0%b8%d0%b8-hugotoml-%d0%b8%d0%bb%d0%b8-configtomlyamljson--%d1%81%d0%b5%d1%80%d0%b4%d1%86%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d0%b0\"\u003eФайл конфигурации (\u003ccode\u003ehugo.toml\u003c/code\u003e или \u003ccode\u003econfig.toml/yaml/json\u003c/code\u003e) – сердце проекта.\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%be%d1%81%d0%bd%d0%be%d0%b2%d0%bd%d1%8b%d0%b5-%d0%bd%d0%b0%d1%81%d1%82%d1%80%d0%be%d0%b9%d0%ba%d0%b8-baseurl-title-languagecode-theme\"\u003eОсновные настройки: \u003ccode\u003ebaseURL\u003c/code\u003e, \u003ccode\u003etitle\u003c/code\u003e, \u003ccode\u003elanguageCode\u003c/code\u003e, \u003ccode\u003etheme\u003c/code\u003e.\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%bd%d0%b0%d1%81%d1%82%d1%80%d0%be%d0%b9%d0%ba%d0%b0-%d0%bc%d0%b5%d0%bd%d1%8e-%d0%b3%d0%bb%d0%b0%d0%b2%d0%bd%d0%be%d0%b5-%d0%b1%d0%be%d0%ba%d0%be%d0%b2%d0%be%d0%b5-%d0%bf%d0%be%d0%b4%d0%b2%d0%b0%d0%bb%d1%8c%d0%bd%d0%be%d0%b5--%d0%ba%d0%b0%d0%ba%d0%be%d0%b5-%d1%85%d0%be%d1%87%d0%b5%d1%88%d1%8c\"\u003eНастройка меню (главное, боковое, подвальное – какое хочешь).\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%bf%d0%b5%d1%80%d0%b5%d0%bc%d0%b5%d0%bd%d0%bd%d1%8b%d0%b5-%d0%be%d0%ba%d1%80%d1%83%d0%b6%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b4%d0%bb%d1%8f-%d1%80%d0%b0%d0%b7%d0%bd%d1%8b%d1%85-%d0%ba%d0%be%d0%bd%d1%84%d0%b8%d0%b3%d1%83%d1%80%d0%b0%d1%86%d0%b8%d0%b9-%d0%b4%d0%b5%d0%b2-%d0%bf%d1%80%d0%be%d0%b4\"\u003eПеременные окружения для разных конфигураций (дев, прод).\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#6-%d1%80%d0%b0%d1%81%d1%88%d0%b8%d1%80%d0%b5%d0%bd%d0%bd%d1%8b%d0%b5-%d0%b2%d0%be%d0%b7%d0%bc%d0%be%d0%b6%d0%bd%d0%be%d1%81%d1%82%d0%b8\"\u003e6. Расширенные возможности\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#shortcodes-%d0%bc%d0%b0%d0%ba%d1%80%d0%be%d1%81%d1%8b-%d0%b4%d0%bb%d1%8f-%d0%ba%d0%be%d0%bd%d1%82%d0%b5%d0%bd%d1%82%d0%b0-%d0%b5%d1%81%d0%bb%d0%b8-markdown-%d1%83%d0%b6%d0%b5-%d0%bd%d0%b5-%d1%85%d0%b2%d0%b0%d1%82%d0%b0%d0%b5%d1%82\"\u003eShortcodes (макросы для контента, если Markdown уже не хватает)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#data-templates-%d0%b3%d1%80%d1%83%d0%b7%d0%b8%d0%bc-%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d0%b5-%d0%b8%d0%b7-json-yaml-csv--%d0%be%d1%82%d0%ba%d1%83%d0%b4%d0%b0-%d1%83%d0%b3%d0%be%d0%b4%d0%bd%d0%be\"\u003eData Templates (грузим данные из JSON, YAML, CSV – откуда угодно)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#asset-pipeline-hugo-pipes--%d0%be%d0%b1%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%ba%d0%b0-cssjs-%d0%ba%d0%b0%d1%80%d1%82%d0%b8%d0%bd%d0%be%d0%ba\"\u003eAsset Pipeline (Hugo Pipes) – обработка CSS/JS, картинок\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%bc%d1%83%d0%bb%d1%8c%d1%82%d0%b8%d1%8f%d0%b7%d1%8b%d1%87%d0%bd%d0%be%d1%81%d1%82%d1%8c-%d0%b5%d1%81%d0%bb%d0%b8-%d0%b2%d0%b4%d1%80%d1%83%d0%b3-%d0%bf%d1%80%d0%b8%d1%81%d0%bf%d0%b8%d1%87%d0%b8%d0%bb%d0%be\"\u003eМультиязычность (если вдруг приспичило)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%be%d0%b1%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%ba%d0%b0-%d0%b8%d0%b7%d0%be%d0%b1%d1%80%d0%b0%d0%b6%d0%b5%d0%bd%d0%b8%d0%b9-%d1%80%d0%b5%d1%81%d0%b0%d0%b9%d0%b7-%d0%ba%d1%80%d0%be%d0%bf-%d0%b2%d0%be%d1%82-%d1%8d%d1%82%d0%be-%d0%b2%d1%81%d1%91\"\u003eОбработка изображений (ресайз, кроп, вот это всё)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#7-%d1%81%d0%b1%d0%be%d1%80%d0%ba%d0%b0-%d0%b8-%d0%b4%d0%b5%d0%bf%d0%bb%d0%be%d0%b9\"\u003e7. Сборка и деплой\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%ba%d0%be%d0%bc%d0%b0%d0%bd%d0%b4%d0%b0-hugo--%d1%81%d0%be%d0%b1%d0%b8%d1%80%d0%b0%d0%b5%d0%bc-%d1%81%d1%82%d0%b0%d1%82%d0%b8%d0%ba%d1%83\"\u003eКоманда \u003ccode\u003ehugo\u003c/code\u003e – собираем статику\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%be%d0%bf%d1%82%d0%b8%d0%bc%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d1%8f-%d0%b4%d0%bb%d1%8f-%d0%bf%d1%80%d0%be%d0%b4%d0%b0%d0%ba%d1%88%d0%b5%d0%bd%d0%b0-%d0%bc%d0%b8%d0%bd%d0%b8%d1%84%d0%b8%d0%ba%d0%b0%d1%86%d0%b8%d1%8f-%d0%b2%d1%81%d0%b5%d0%b3%d0%be-%d0%b8-%d0%b2%d1%81%d1%8f\"\u003eОптимизация для продакшена (минификация всего и вся)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%ba%d1%83%d0%b4%d0%b0-%d0%b4%d0%b5%d0%bf%d0%bb%d0%be%d0%b8%d1%82%d1%8c-netlify-vercel-github-pages-%d1%81%d0%b2%d0%be%d0%b9-%d1%81%d1%80%d0%b0%d0%bd%d1%8b%d0%b9-vps--%d0%b2%d0%b0%d1%80%d0%b8%d0%b0%d0%bd%d1%82%d0%be%d0%b2-%d0%bc%d0%b0%d1%81%d1%81%d0%b0\"\u003eКуда деплоить (Netlify, Vercel, GitHub Pages, свой сраный VPS – вариантов масса)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#cicd--%d0%b0%d0%b2%d1%82%d0%be%d0%bc%d0%b0%d1%82%d0%b8%d0%b7%d0%b8%d1%80%d1%83%d0%b5%d0%bc-%d1%80%d1%83%d1%82%d0%b8%d0%bd%d1%83\"\u003eCI/CD – автоматизируем рутину\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#8-%d0%bb%d1%83%d1%87%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%b0%d0%ba%d1%82%d0%b8%d0%ba%d0%b8-%d0%b8-%d0%bf%d0%be%d0%b4%d0%b2%d0%be%d0%b4%d0%bd%d1%8b%d0%b5-%d0%ba%d0%b0%d0%bc%d0%bd%d0%b8\"\u003e8. Лучшие практики и подводные камни\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%be%d1%80%d0%b3%d0%b0%d0%bd%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d1%8f-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d0%b0-%d1%87%d1%82%d0%be%d0%b1%d1%8b-%d0%bf%d0%be%d1%82%d0%be%d0%bc-%d1%81%d0%b0%d0%bc%d0%be%d0%bc%d1%83-%d0%bd%d0%b5-%d0%be%d1%85%d1%80%d0%b5%d0%bd%d0%b5%d1%82%d1%8c\"\u003eОрганизация проекта (чтобы потом самому не охренеть)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%bf%d1%80%d0%be%d0%b8%d0%b7%d0%b2%d0%be%d0%b4%d0%b8%d1%82%d0%b5%d0%bb%d1%8c%d0%bd%d0%be%d1%81%d1%82%d1%8c-%d0%ba%d0%b0%d0%ba-%d0%bd%d0%b5-%d1%81%d0%b4%d0%b5%d0%bb%d0%b0%d1%82%d1%8c-%d1%82%d0%be%d1%80%d0%bc%d0%be%d0%b7%d0%bd%d1%83%d1%82%d1%8b%d0%b9-%d1%81%d0%b0%d0%b9%d1%82-%d0%bd%d0%b0-%d1%81%d1%82%d0%b0%d1%82%d0%b8%d0%ba%d0%b5\"\u003eПроизводительность (как не сделать тормознутый сайт на статике)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d0%be%d1%82%d0%bb%d0%b0%d0%b4%d0%ba%d0%b0-%d0%ba%d0%be%d0%b3%d0%b4%d0%b0-%d0%b2%d1%81%d1%91-%d0%bf%d0%be%d1%88%d0%bb%d0%be-%d0%bd%d0%b5-%d1%82%d0%b0%d0%ba\"\u003eОтладка (когда всё пошло\u0026hellip; не так)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/ru/conversations/about_hugo/#%d1%82%d0%b8%d0%bf%d0%b8%d1%87%d0%bd%d1%8b%d0%b5-%d0%be%d1%88%d0%b8%d0%b1%d0%ba%d0%b8-%d0%bd%d0%be%d0%b2%d0%b8%d1%87%d0%ba%d0%be%d0%b2-%d0%b8-%d0%bd%d0%b5-%d0%be%d1%87%d0%b5%d0%bd%d1%8c\"\u003eТипичные ошибки новичков (и не очень)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"1-вводная-для-тех-кто-не-в-теме\"\u003e1. Вводная для тех, кто не в теме\u003c/h2\u003e\n\u003cp\u003eСлушай сюда, инженер. Если ты до сих пор не слыхал про Hugo, значит, либо ты сидел в танке, либо занимался какой-то совсем уж узкоспециализированной херней. Но это поправимо.\u003c/p\u003e","title":"Гайд по Hugo для инженеров"},{"content":" Меня зовут Константин Мещеряков. Я – Head of AI в IoT-компании во Вроцлаве: выстраиваю GenAI-стратегию, веду программу внедрения AI для всей инженерной организации и отвечаю за соответствие требованиям EU AI Act. Продолжаю заниматься и архитектурой в AI-проектах, потому что советы без стоящей за ними разработки быстро устаревают.\nДорога сюда заняла шестнадцать лет. Я начинал с кандидатской по физико-математическим наукам, писал системы на C++/Qt для авиационных испытаний, прошел через embedded-разработку и облачную архитектуру AWS и по пути освоил машинное обучение – от TinyML на микроконтроллерах до продакшен-ML и LLM-систем. Несколько лет я также преподавал в университете: Qt, Python и функциональное программирование. Этот путь, от прошивок до GenAI-стратегии, до сих пор определяет, как я оцениваю, что переживет встречу с продакшеном. Название блога позаимствовано из словаря CFD и заодно удачно перекликается с моей фамилией.\nЭтот блог – место, где я делюсь своими мыслями и наблюдениями из окопов AI: реальные кейсы, нюансы работы с LLM и агентами, разработка с AI-ассистентами, подводные камни edge AI. Иногда здесь могут появляться заметки и на другие технологические темы, которые цепляют мое внимание. Все это – мой личный опыт и взгляд на вещи, приправленный долей иронии и стремлением отделить суть от хайпа.\n","permalink":"https://meshrefine.com/ru/about/","summary":"\u003cimg src=\"/images/konstantin-meshcheryakov.jpg\" alt=\"Константин Мещеряков\" style=\"float: right; width: 200px; max-width: 45%; height: auto; border-radius: 12px; margin: 0.25rem 0 1rem 1.5rem;\"\u003e\n\u003cp\u003eМеня зовут Константин Мещеряков. Я – Head of AI в IoT-компании во Вроцлаве: выстраиваю GenAI-стратегию, веду программу внедрения AI для всей инженерной организации и отвечаю за соответствие требованиям EU AI Act. Продолжаю заниматься и архитектурой в AI-проектах, потому что советы без стоящей за ними разработки быстро устаревают.\u003c/p\u003e\n\u003cp\u003eДорога сюда заняла шестнадцать лет. Я начинал с кандидатской по физико-математическим наукам, писал системы на C++/Qt для авиационных испытаний, прошел через embedded-разработку и облачную архитектуру AWS и по пути освоил машинное обучение – от TinyML на микроконтроллерах до продакшен-ML и LLM-систем. Несколько лет я также преподавал в университете: Qt, Python и функциональное программирование. Этот путь, от прошивок до GenAI-стратегии, до сих пор определяет, как я оцениваю, что переживет встречу с продакшеном. Название блога позаимствовано из словаря CFD и заодно удачно перекликается с моей фамилией.\u003c/p\u003e","title":"Обо мне"},{"content":"На этом сайте я стремлюсь к полной прозрачности в отношении использования технологий искусственного интеллекта (AI). Весь контент четко разделяется на следующие категории:\nКонтент, написанный автором. Основная часть материалов на этом сайте написана мной лично. AI может использоваться исключительно для базовой помощи, такой как проверка орфографии и грамматики.\nМаркировка: Такой контент никак дополнительно не помечается. Доступ для AI: Разрешен для индексации поисковыми системами и использования в обучающих наборах данных для AI-моделей. Контент, переведенный с помощью AI. Статьи, которые являются переводом моего оригинального контента на другой язык. Перевод выполняется с помощью AI, после чего я лично вычитываю и редактирую текст для обеспечения точности и стилистического соответствия.\nМаркировка: Такие материалы имеют явную пометку, указывающую на использование AI для перевода (например, \u0026ldquo;Переведено с помощью AI\u0026rdquo;). Доступ для AI: Разрешен для индексации и обучения AI. Я считаю, что человеческая редактура и оригинальная основа контента обеспечивают достаточное качество, чтобы не вызывать деградацию моделей. Контент, сгенерированный с помощью AI. Материалы, где AI использовался для генерации основной части текста, который затем был мной тщательно проверен, исправлен и дополнен.\nМаркировка: Такой контент имеет явную пометку (например, \u0026ldquo;Сгенерировано с помощью AI\u0026rdquo;). Доступ для AI: Разрешен для индексации поисковыми системами, но запрещен для использования в обучении AI-моделей (noai). ","permalink":"https://meshrefine.com/ru/ai-content-policy/","summary":"\u003cp\u003eНа этом сайте я стремлюсь к полной прозрачности в отношении использования технологий искусственного интеллекта (AI). Весь контент четко разделяется на следующие категории:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003eКонтент, написанный автором. Основная часть материалов на этом сайте написана мной лично. AI может использоваться исключительно для базовой помощи, такой как проверка орфографии и грамматики.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eМаркировка: Такой контент никак дополнительно не помечается.\u003c/li\u003e\n\u003cli\u003eДоступ для AI: Разрешен для индексации поисковыми системами и использования в обучающих наборах данных для AI-моделей.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eКонтент, переведенный с помощью AI. Статьи, которые являются переводом моего оригинального контента на другой язык. Перевод выполняется с помощью AI, после чего я лично вычитываю и редактирую текст для обеспечения точности и стилистического соответствия.\u003c/p\u003e","title":"Политика AI контента"},{"content":"Итак, Griptape. Фреймворк для построения AI приложений, предлагающий чистый питонячий API для тех, кто устал от уровней абстракции LangChain. Предлагает примитивы для построения ассистентов, RAG-систем, и интеграции с внешними инструментами. Честно говоря, по моему опыту, большинство людей, уставших от langchain, уходит на самописные обертки над более низкоуровневыми библиотеками, вроде openai или litellm. Но кто, знает, может быть зря. Разберемся.\nНемного истории Лично я про Griptape слышу уже года полтора, и начинал он как этакий конкурент LangChain с довольно похожими примитивами, но постепенно их пути разошлись. На момент написания этого поста у него 2.3k звезд на гитхабе, что несколько меньше, чем 109k лангчейна, но все же достаточно, чтобы считать проект достаточно взрослым. Кроме открытого фреймворка, он обзавелся своим облаком, в котором можно запускать свои приложения, ETLки и RAGи, и графический конструктор Griptape Nodes, позволяющий непрофессионалам накликивать приложения мышкой за считанные минуты. 1\nФреймворк Перейдем, собственно, к самому фреймворку. Он представляет несколько примитивов, в которых было бы неплохо разбираться, прежде чем приступать к работе.\nДрайверы/Drivers: по сути, главный инструмент, абстрагирующий конкретные имплементации чего-бы то ни было и позволяющий их менять на ходу, не ломая бизнес-логику. Существуют движки почти-что для всего, будь то ассистенты, промпты, модели, системы эмбеддинга или базы данных. По сути, абстрактные классы и их реализации.\nДвижки/Engine: предоставляют готовые реализации основных задач, таких как RAG и суммаризация.\nСтруктуры/Structures: Базовые блоки для построения приложений. Среди них можно найти:\nзадачи (tasks): абстракция над неким действием, например, запрос к модели, обработка ответа, загрузка данных из файла и прочее.\nагентов (agents): немного странная обертка над одной задачей 2. Позволяет передать этой задаче ввод и список инструментов, которые она может использовать.\nпайплайны (pipelines): как агент, но может запускать несколько задач последовательно, передавая вывод одной на ввод другой.\nworkflows: ациклические направленные графы (DAGs), состоящие из задач. Позволяет оптимальным планировать и запускать параллельные задачи. Документация указывает, что они non-sequential, хотя в дальнейшем дает примеры вполне последовательных workflows. В этом случае, несколько не ясно, а зачем вообще нужны пайплайны.\nВ целом, подобная организация является довольно гибкой и позволяет создавать довольно сложные потоки выполнения. То, что это DAG, накладывает определенные ограничения на создание агентов в том смысле, который закладывают в него некоторые футуристично настроенные люди, зато позволяет строить надежные 3 и продуманные системы.\nИнструменты/Tools: Функции, доступные LLM. Эти функции можно передавать в примитивы, указанные выше, и давать таким образом LLM возможность генерировать последовательность вызовов этих функций для выполнения каких-либо действий. Griptape предоставляет довольно много таких инструментов, но можно добавлять и свои.\nПамять/Task Memory: Одна из интересных фич Griptape. Зачастую данные, которые нужно обработать, либо очень чувствительные, либо очень большие, и отправлять их в LLM напрямую может быть непрактично. В таком случае, можно попросить инструмент не предоставлять эти данные в LLM, а отдавать некий дескриптор этих данных, который позволит LLM ссылаться на эти данные для использования в других тулах.\nConversation Memory: Включена по умолчанию, и передается в модель между запусками одного и того же workflow.4 Можно отключить в случае, если это не требуется. По сути, полезна только для чатботов и откровенно вредна для всего остального.\nRulesets: Настройки поведения LLM, которые передаются в каждый промпт. Что-то вроде system prompts, но чтобы точно понять, они ли это, надо копать вглубь.\nНа этом основные примитивы закончились, есть еще несколько концептов, которые на данном этапе не слишком важны, поэтому их я пропущу.\nЧто дальше? А дальше я думаю копнуть поглубже:\nв то, а когда и зачем использовать агенты, пайплайны и workflows в возможности фреймворка для ETL и RAG в то, как работает Off Prompt Memory в интеграцию и кастомизацию в то, что можно делать в их облаке а также на что пригоден Griptape nodes Ну и позапускать всякие примеры, которые они предоставляют, естественно. Буду описывать по мере прогресса.\nна самом деле нет\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nхотя есть API для создания агента вокруг списка задач, оно валится при попытке передать туда больше одной задачи, что весьма странно\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nнасколько это возможно с вероятностными LLM\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nили агента, или пайплайна\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://meshrefine.com/ru/posts/griptape-1/","summary":"\u003cp\u003eИтак, \u003ca href=\"www.griptape.ai\"\u003eGriptape\u003c/a\u003e. Фреймворк для построения AI приложений, предлагающий чистый питонячий API для тех, кто устал от уровней абстракции LangChain. Предлагает примитивы для построения ассистентов, RAG-систем, и интеграции с внешними инструментами. Честно говоря, по моему опыту, большинство людей, уставших от langchain, уходит на самописные обертки над более низкоуровневыми библиотеками, вроде openai или litellm. Но кто, знает, может быть зря. Разберемся.\u003c/p\u003e\n\u003ch1 id=\"немного-истории\"\u003eНемного истории\u003c/h1\u003e\n\u003cp\u003eЛично я про Griptape слышу уже года полтора, и начинал он как этакий конкурент LangChain с довольно похожими примитивами, но постепенно их пути разошлись. На момент написания этого поста у него 2.3k звезд на гитхабе, что несколько меньше, чем 109k лангчейна, но все же достаточно, чтобы считать проект достаточно взрослым.\nКроме открытого фреймворка, он обзавелся своим облаком, в котором можно запускать свои приложения, ETLки и RAGи, и графический конструктор Griptape Nodes, позволяющий непрофессионалам накликивать приложения мышкой за считанные минуты. \u003csup id=\"fnref:1\"\u003e\u003ca href=\"#fn:1\" class=\"footnote-ref\" role=\"doc-noteref\"\u003e1\u003c/a\u003e\u003c/sup\u003e\u003c/p\u003e","title":"Griptape: Фреймворк для AI приложений, часть 1: Введение"},{"content":"Ну, начали Попала мне в руки Re:Camera от Seeed. По сути, маленькая коробочка (кубик сантиметра 4 ребром), опоясанная радиатором. Внутри двухъядерный MPU (updated: в системе видно только одно ядро, второе, похоже, зарезервировано под специальные операции) на основе RISC-V, древний микроконтроллер на 8051, сенсор камеры от OmniVision, диоды для подсветки, Wi-Fi, BT, ну и всякая периферия. Оперативной памяти маловато, всего 256 мегабайт, так что Greengrass поставить будет проблематично. Можно подключить Ethernet через специальный шнурок-переходник, который еле держится, но для разработки незачем, потому что камера раздает сеть по USB Type C, и работать проще через него. Кстати, включается этот переходник во что-то, подозрительно напоминающее grove plug от того же Seeed, что, вкупе с документацией, намекает на возможность подключения внешних сенсоров. Если мало памяти (а поставляется устройство в вариантах с 8 и 64 ГБ встроенной памяти), можно воткнуть MicroSD. Еще коробку можно прицепить к чему-нибудь металлическому, потому что есть магнитики на одной из сторон.\nПри подключении можно открыть веб-страницу (192.168.42.1 по умолчанию), которая сама по себе делать ничего, кроме как предоставить доступ к настройке Wi-Fi и обновлению, не может. Там есть еще консоль, но кто использует консоль в браузере, когда есть ssh?\nПолагаю, с этим можно что-то сделать и в текущем состоянии, но в инструкции настойчиво предлагается обновиться по OTA, что я и сделал (как бы это ни было очевидно, но для этого нужно сначала настроить сеть). После 5 минут активного моргания диодами и подключения/отключения устройства к компьютеру, устройство предоставило мне доступ к уже обновленной странице и потребовало изменить пароль по умолчанию (recamera/recamera). Изменение этого пароля также меняет пароль на доступ к ssh, осторожно.\nПосле обновления появляется доступ к Node-RED, этакой графической среде разработки, в которой потоки данных описываются графами с нодами-обработчиками. По умолчанию, такой граф уже загружен и дает доступ к простому дашборду, который позволяет посмотреть на картинку с камеры и на результаты работы модели ИИ Yolov11. Другие графы можно (в теории) взять на сайте SenseCraft AI от Seeed, но он требует регистрации, так что я забил.\nПро камеру Сенсор, установленный в коробке, откровенно устарел. Представляет он собой OmniVision OV5647, 5-мегапиксельную камеру с roller shutter. Совсем недавно я делал демку с сенсором BrightSense от StMicro, оснащенным global shutter, собирающим информацию с матрицы одномоментно, а не построчно, как в данном случае. Это сказалось на разрешении (всего 1,5 мегапикселя), но зато. быстро падающие конфеты она захватывала идеально. Обо всех прелестях rolling shutter можно почитать на википедии, но, в двух словах, если вы видели, как красиво изображают в фильмах всякие штуки, которые засасывает в черную дыру, то вот это оно. Seeed обещает, что можно подключать другие сенсоры, и что в будущем выпустит новые варианты, в том числе и с global shutter камерой, но пока имеем то, что имеем.\nОкно, вообще-то, должно быть ровным Почему важно иметь неискаженные объекты? Потому что модель. К которой мы сейчас и перейдем.\nПро модель Ну, не совсем. Сначала про то, на чем она крутится. В коробочке есть NPU производительностью в целый TOPS. При использовании 8-битной квантизации, разумеется, во float он не умеет. Как под этот NPU что-то оптимизировать, я еще не разбирался, так что пока что можно о производительности судить по данным, доступным во встроенном дэшборде. Модель, которая там используется, Ultralitics YOLO11 в самом маленьком ее варианте (n, то есть nano), умеет определять и выдавать bounding boxes для 80 различных классов объектов, таких как жирафы и зубные щетки, что несколько слабо ложится на большинство рабочих задач, так что модель надо тренировать на своем датасете. Зато производительность весьма неплохая, демка дает следующие данные:\nПрепроцессинг: 0 мс. Вот это замечательно, видимо, камера умеет выдавать результат сразу в формате, который можно подавать модели. В демке, которую я упоминал, такое не получалось, и мне пришлось изрядно повозиться, чтобы его оптимизировать. Сам инференс: ~50 мс. Неплохо, вполне неплохо. Постпроцессинг: 20-25 мс. Тут работает алгоритм Non-Maximum Suppression, который довольно жручий, и запускается он тут на CPU, судя по нагрузке в top Итого, это дает нам что-то около 12-13 инференсов в секунду, что для многих задач вполне терпимо. В UI, однако, визуально выглядит, будто там 4-5 кадра в секунду, что может быть вызвано неоптимальным конвейером или другими издержками. Греется при этом всем коробочка изрядно.\nЧто (пока что) осталось за кадром Если мы говорим про использование этого в чем-то более серьезном, чем игры со встроенными демками, нужно понять, как:\na) Как собирать систему. Я сомневаюсь, что Node-RED подойдет для рабочих задач, так что нужно брать напильник (buildroot, кстати), и впиливать нужный нам софт. б) Как оптимизировать модель и запускать инференс из своих программ. Если будет на это время, вернусь к этому в будущих выпусках. Ну а пока, до связи.\n","permalink":"https://meshrefine.com/ru/posts/re-camera-1/","summary":"\u003ch2 id=\"ну-начали\"\u003eНу, начали\u003c/h2\u003e\n\u003cp\u003eПопала мне в руки Re:Camera от Seeed. По сути, маленькая коробочка (кубик сантиметра 4 ребром), опоясанная радиатором. Внутри двухъядерный MPU (\u003cstrong\u003eupdated:\u003c/strong\u003e в системе видно только одно ядро, второе, похоже, зарезервировано под специальные операции) на основе RISC-V, древний микроконтроллер на 8051, сенсор камеры от OmniVision, диоды для подсветки, Wi-Fi, BT, ну и всякая периферия. Оперативной памяти маловато, всего 256 мегабайт, так что Greengrass поставить будет проблематично. Можно подключить Ethernet через специальный шнурок-переходник, который еле держится, но для разработки незачем, потому что камера раздает сеть по USB Type C, и работать проще через него. Кстати, включается этот переходник во что-то, подозрительно напоминающее grove plug от того же Seeed, что, вкупе с документацией, намекает на возможность подключения внешних сенсоров. Если мало памяти (а поставляется устройство в вариантах с 8 и 64 ГБ встроенной памяти), можно воткнуть MicroSD. Еще коробку можно прицепить к чему-нибудь металлическому, потому что есть магнитики на одной из сторон.\u003c/p\u003e","title":"Обзор Re:Camera, часть 1"}]