<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:cc="http://cyber.law.harvard.edu/rss/creativeCommonsRssModule.html">
    <channel>
        <title><![CDATA[Stories by Ekaterina Yanke on Medium]]></title>
        <description><![CDATA[Stories by Ekaterina Yanke on Medium]]></description>
        <link>https://medium.com/@ekaterinayanke?source=rss-41304787e7da------2</link>
        <image>
            <url>https://cdn-images-1.medium.com/fit/c/150/150/1*ws0MGNacyw6YakBsuVZ3QA.jpeg</url>
            <title>Stories by Ekaterina Yanke on Medium</title>
            <link>https://medium.com/@ekaterinayanke?source=rss-41304787e7da------2</link>
        </image>
        <generator>Medium</generator>
        <lastBuildDate>Sun, 15 Nov 2026 03:31:54 GMT</lastBuildDate>
        <atom:link href="https://medium.com/@ekaterinayanke/feed" rel="self" type="application/rss+xml"/>
        <webMaster><![CDATA[yourfriends@medium.com]]></webMaster>
        <atom:link href="http://medium.superfeedr.com/" rel="hub"/>
        <item>
            <title><![CDATA[Product Manager’s Interaction with Stakeholders]]></title>
            <link>https://medium.com/@ekaterinayanke/product-managers-interaction-with-stakeholders-1a272be44e86?source=rss-41304787e7da------2</link>
            <guid isPermaLink="false">https://medium.com/p/1a272be44e86</guid>
            <category><![CDATA[product-management]]></category>
            <category><![CDATA[stakeholder-engagement]]></category>
            <dc:creator><![CDATA[Ekaterina Yanke]]></dc:creator>
            <pubDate>Mon, 18 Dec 2023 17:32:13 GMT</pubDate>
            <atom:updated>2023-12-18T17:58:16.624Z</atom:updated>
            <content:encoded><![CDATA[<p>This is an aspect often underestimated by many junior product managers. Being immersed in research, writing user stories, and leading agile processes with the team can distract from managing stakeholder expectations. This oversight can be a stumbling block in advancing to senior positions.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*hP3NjdKVITKDOJtuY_RQYg.png" /></figure><p>Let me share my perspective on effective stakeholder engagement.</p><p><strong>Active Communication<br></strong>The best way to truly understand stakeholders is to communicate directly with them! Forget about emails and general meetings. Set up personal 1-to-1 meetings at least once a month. During these meetings, you can align on goals, inquire about expectations, offer help, discuss progress, and brainstorm ideas. This is crucial, as it’s easier to sell an idea to a group of stakeholders if you’ve already convinced each of them individually.</p><p><strong>Individual Approach</strong><br>If you’re responsible for a product with multiple stakeholders, don’t show the same document to everyone. Each stakeholder has their own goals and interests. Tailor your roadmaps to each stakeholder, focusing on the details relevant to them. This approach helps to concentrate on the specifics that matter to each stakeholder. Remember, their expectations and interests are diverse.</p><p><strong>Initiate Feedback Collection</strong><br>Sometimes, stakeholders may need to realize how they can contribute. Take the first step if you believe someone’s insight or experience can improve the situation. Schedule a meeting, propose ideas for collaboration, or request initial feedback.</p><p><strong>And, of course, don’t forget the obvious:</strong></p><ul><li>Please list your stakeholders and discuss it with your manager so no one is left out.</li><li>Keep track of course changes, timelines, and plans with stakeholders, and always record agreements in writing.</li><li>Be open to new suggestions ;)</li></ul><p>These tips will help you enhance your interactions with your stakeholders!</p><p>Russian version is here: <a href="https://t.me/it_people_management/67">https://t.me/it_people_management/67</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=1a272be44e86" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Пошаговая инструкция решения конфликта]]></title>
            <link>https://medium.com/@ekaterinayanke/%D0%BF%D0%BE%D1%88%D0%B0%D0%B3%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D0%B8%D1%8F-%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F-%D0%BA%D0%BE%D0%BD%D1%84%D0%BB%D0%B8%D0%BA%D1%82%D0%B0-12d82bc4496?source=rss-41304787e7da------2</link>
            <guid isPermaLink="false">https://medium.com/p/12d82bc4496</guid>
            <category><![CDATA[management]]></category>
            <category><![CDATA[teamwork]]></category>
            <category><![CDATA[conflict]]></category>
            <dc:creator><![CDATA[Ekaterina Yanke]]></dc:creator>
            <pubDate>Wed, 27 Jul 2022 14:19:13 GMT</pubDate>
            <atom:updated>2022-07-27T14:19:13.361Z</atom:updated>
            <content:encoded><![CDATA[<p>Недавно был интересный разговор с дизайнером. Оказалось, что в их команде разработчики не тестируют свой код, ручных тестеров нет, только автоматизаторы, Все баги находят дизайнеры уже на этапе дизайн-ревью (когда якобы все готово к релизу). Из-за этого уже на последней стадии задача возвращается с десятками ошибок и доработок. На исправление уходит много времени, спринты затягиваются на недели.</p><p>Вспомнила, что в моей команде в начале прошлого года тоже была похожая ситуация, только у нас все баги сваливались на ручных тестировщиков. А результатом все равно был заваленный спринт.</p><p>Обе ситуации конфликтные, ретроспективы жесткие, все валят вину друг на друга, все всем недовольны. Разработчики считали, что если есть тестировщики, они пусть и ошибки и находят, тестировщики обижались, что разработчики ленятся проверять свой код и отдают детский ошибки, дизайнеры жаловались, что фича функционально работает, но не соответствует дизайну и не могли понять, почему и разработчики и тестировщики это пропустили. А я, как менеджер, была озадачена только одним — решить конфликт и доставлять ценность в прод быстрее.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*c17MFsURj-rUZ3xS" /></figure><p>За 10 лет работы я, конечно, поняла, что идеальных процессов не существует. Состав команды всегда разный, уровень ребят тоже, кто-то готов на себя брать больше, кто-то еще не умеет, а кто-то просто не знает, чего именно от него ждут и делает так, как привык в прошлой команде. На этом фоне в любой (особенно новой) команде обязательно наступит конфликтная ситуация.</p><h3>Разрешить ситуацию поможет общение!</h3><p><strong>Шаг #1. Остыть самому и дать остыть команде</strong></p><p>Не стоит проводить разбор ситуации и пытаться найти решение сразу после конфликта. Допустим, ты с командой встретился на митинге, увидел, что спринт завален, все немного поспорили… Ставить ретроспективу в этот же день не стоит. Все придут с заведомо неподходящим настроем. А вот закончить задачу, выкатить ее в прод и на следующий день собраться на обсуждение — правильная идея.</p><p><strong>Шаг #2. Выбрать подходящий формат</strong></p><p>Пообщаться можно на командной ретроспективе, или с каждым 1-на-1, это зависит от того, сколько человек участвует в обсуждении и насколько сильно команда завязла в конфликте. При сложных нерешенных конфликтах, когда люди начинают закрываться и занимать оборонительную позицию (не слышат аргументов и не идут на контакт) лучше встречаться 1-на-1, так у коллег не будет ощущения, что ты привел их на показательную казнь перед всей командой.</p><p><strong>Шаг #3. Смягчить почву</strong></p><p>Если вы с коллегой уже успели поругаться, например, случайно грубо поговорили, то вам будет сложно продолжить общение даже через какое-то время. Классный хак — извиниться. Не важно, кто был прав, в начале разговора извинись ты — это обезоружит собеседника, ему будет неловко общаться с тобой с позиции обиженного и нападавшего.</p><p><strong>Шаг #4. Определить цель встречи</strong></p><p>Не важно какое у тебя мнение (что тестировать должен тестировщик а не разработчик, или разработчик, а не дизайнер), твоя задача — узнать мнение коллеги, ведь только так вы найдете компромиссное решение.</p><ul><li><strong>Плохая цель:</strong> “Я задолбался тестировать за тобой баги, давай подумаем, как бы так сделать, чтобы их стало меньше”.</li><li><strong>Хорошая цель:</strong> “Я беспокоюсь, что наша команда снизила продуктивность, а наши пользователи стали все реже получать новый функционал, и он часто выезжает на прод с ошибками. Давай вместе подумаем, почему так произошло и как мы это можем исправить”.</li></ul><p><strong>Шаг #5. Задать правильные вопросы</strong></p><p>Настало самое интересное! Вот примеры вопросов, которые могут могут помочь разобраться в ситуации, если представить, что будет разговор с разработчиком:</p><ul><li>Как ты думаешь, почему у по последним задачам так много ошибок?</li><li>В требованиях и макетах было достаточно подробно описано, как должен работать этот функционал?</li><li>Ты самостоятельно сверял макет/требования, прежде чем передвинуть задачу на тестирование/дизайн-ревью? … Почему нет?</li><li>Как ты думаешь, кто в команде должен искать ошибки? … Почему он?</li><li>Как ты видишь свою роль (роль тестировщика, дизайнера, менеджера) в процессе поиска ошибок? … Почему?</li><li>Как ты думаешь, что можно изменить в процессе, чтобы всем было комфортно, а качество улучшилось?</li></ul><p>Все вопросы должны быть открытые, не пытайся навязать свое видение человеку, он это обязательно заметит и фокус будет провален ;)</p><p><strong>Шаг #6. Взять паузу (опционально)</strong></p><p>Если в разговоре решение не находится — возьми перерыв. Резюмируя все ответы коллеги, и предлагаешь пойти подумать за кадром, чтобы встретиться в следующий раз и договориться о решении.</p><p><strong>Шаг #7. Найти совместное решение</strong></p><p>Все поделились своей болью и предложили решения. Теперь осталось их зафиксировать, выбрать компромисс и убедиться, что все согласны попробовать новый план действий со следующего спринта. Сразу обозначь коллегам, что через спринт действующие лица еще раз соберутся на встречу, чтобы проверить, как общее решение подействовало на ситуацию.</p><p><strong>Все! 🙌</strong></p><p>За прошлый год такой подход я использовала не только для решения разногласий в скрам-команде, но и для нахождения общего языка между менеджерами, дизайнерами и юристами, а еще между менеджерами продукта и бизнес-лидерами направлений. Не важно кто действующие лица, главное не ленись разговаривать 😉</p><p>Долго? — Да, находить общие решения с привлечением всех задействованных персонажей и правда долго, сложно и не всегда комфортно. Но только так конфликт перейдет из негативного блокера в продуктивную коммуникацию. А совместное решение проблем мотивирует ребят и сплачивают команду!</p><p>— <br>Мои заметки на другие темы <a href="https://t.me/it_people_management">тут</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=12d82bc4496" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Как сделать встречи эффективнее, когда ты remote? 10 ошибок в рабочей коммуникации]]></title>
            <link>https://medium.com/@ekaterinayanke/%D0%BA%D0%B0%D0%BA-%D1%81%D0%B4%D0%B5%D0%BB%D0%B0%D1%82%D1%8C-%D0%B2%D1%81%D1%82%D1%80%D0%B5%D1%87%D0%B8-%D1%8D%D1%84%D1%84%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D0%B5%D0%B9-%D0%BA%D0%BE%D0%B3%D0%B4%D0%B0-%D1%82%D1%8B-remote-10-%D0%BE%D1%88%D0%B8%D0%B1%D0%BE%D0%BA-%D0%B2-%D1%80%D0%B0%D0%B1%D0%BE%D1%87%D0%B5%D0%B9-%D0%BA%D0%BE%D0%BC%D0%BC%D1%83%D0%BD%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B8-6a78b10a086f?source=rss-41304787e7da------2</link>
            <guid isPermaLink="false">https://medium.com/p/6a78b10a086f</guid>
            <category><![CDATA[meetings]]></category>
            <category><![CDATA[meeting-people]]></category>
            <category><![CDATA[communication]]></category>
            <category><![CDATA[work-communication]]></category>
            <dc:creator><![CDATA[Ekaterina Yanke]]></dc:creator>
            <pubDate>Mon, 23 May 2022 10:13:47 GMT</pubDate>
            <atom:updated>2022-05-23T10:17:56.057Z</atom:updated>
            <content:encoded><![CDATA[<p>За последние пару лет на удаленный формат работы перешли, даже те компании, которые раньше не могли себе представить эту опцию. Вынужденный переход не для всех был легким и успешным, от некоторых знакомых я продолжала слышать, что работать удаленно сложнее и неэффективно. Какое то время я наблюдала, задавала вопросы и пыталась понять, что именно по мнению людей делает удаленных сотрудников менее эффективными. Вывод пришел достаточно быстро — неумение коммуницировать с распределенной командой.</p><p>Я насчитала целых 10 ошибок в ежедневной рабочей коммуникации, которые мы совершаем. Кто-то их совершает, потому что не знает, что это ошибка — просто не умеет иначе. А кто-то совершает их находясь в потоке, и только спустя пару дней понимает, что накосячил (это про меня 😆). Предлагаю разобрать ошибки, чтобы их было проще узнавать и избегать в работе.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*l3e3rEijLmveyo5khTv94w.png" /></figure><p><strong>Ошибка №1<br></strong>На любой возникший в течение дня вопрос мы срочно ставим созвон с коллегами.</p><p><strong>Как исправить: </strong>Разобраться, срочный ли вопрос. Если вопрос действительно горит — встреча будет отличным решением, если нет, лучше не полениться и отправить вопрос в письменном виде. Это позволит коллегам ответить на вопрос в удобное для них время, и не отвлечет их от других задачи и обязанностей.</p><p><strong>Ошибка №2<br></strong>Собираем на встречу сразу всех, чтобы быстро найти решение с одними, а все остальные были в курсе событий.</p><p><strong>Как исправить: </strong>Не смешивать две разные задачи: поиск решения и информирование. Чем больше людей участвует во встрече, тем сложнее удержать фокус внимания всех собравшихся, и сложнее вести обсуждение (не зря для многолюдных мероприятий придумали специальные форматы общения с обязательным модератором).</p><p>Приглашаем на встречу только необходимых для решения коллег, так будет проще провести встречу. А у остальных останется больше времени на решение других задач, ведь проинформировать о принятом решении можно и отдельно ;)</p><p><em>Кстати, </em><a href="https://t.me/it_people_management/26"><em>тут лежит моя заметка</em></a><em> про слишком большое количество встреч и их печальное влияние на продуктивность.</em></p><p><strong>Ошибка №3<br></strong>В календаре заполняем только тему встречи, например, “Обсудим воронку”, ведь ввести в курс дела можно и на встрече.</p><p><strong>Как исправить: </strong>В описание мероприятия расшифровываем цель встречи. Это позволит коллегам прийти на встречу подготовленными, например, выгрузить свеженькую аналитику по воронке в том разрезе, который мы планируем обсудить.</p><p><strong>Ошибка №4<br></strong>Ставим встречи поверх других встреч с надеждой, что предыдущая закончится раньше и мы еще один вопросик успеем порешать.</p><p><strong>Как исправить: </strong>Чтобы получить на встречу “свеженького” коллегу даем ему время выдохнуть и переключиться с прошлой встречи. В идеале оставлять между встречами минимум 10 минут перерыва, чтобы участники успели закончить начатое, выгрузить это из операционки и, если повезет, загрузить контекст следующей встречи.</p><p><strong>Ошибка №5<br></strong>Готовим материалы, например, данные о рынке на 40 страниц или таблицу на 10 листов, и собираем встречу, чтобы “быстренько” их озвучить и принять решение.</p><p><strong>Как исправить: </strong>Все люди воспринимают информацию по-разному: кто-то отлично усваивает информацию с первого раза на слух, кому-то требуется прочитать и переварить увиденное. Всегда, когда возможно, прикрепляем материалы для изучения в календарь или отправляйте их заранее всем участникам, чтобы встретить на созвоне поменьше недоумения.</p><p><strong>Ошибка №6<br></strong>Не дублируем договоренности по итогам встречи в письменном виде, ведь все взрослые люди, и так запомнили.</p><p><strong>Как исправить: </strong>Всегда писать Follow up в котором:</p><ul><li>дублировать цель встречи</li><li>фиксировать принятые договоренности и возникшие вопросы</li><li>меншенить ответственных за договоренность/вопрос</li><li>указывать следующие шаги с указанной датой</li></ul><p>Да, это занимает время (это, кстати, еще одна причина, по которой нельзя ставит встречу на встречу), но значительно повышает шанс выполнения договоренностей 😉</p><p><strong>Ошибка №7<br></strong>Не включаем камеру, потому что голова сегодня грязная, дома не прибрано, а я все равно буду слайды показывать — на них посмотрят.</p><p><strong>Как исправить: </strong>Всегда включаем камеру, ведь коммуникация бывает вербальная (слова) и невербальная (мимика, жесты). Транслируя что-то коллегам без камеры, мы теряем часть посыла, из-за этого нас могут неверно понять. Шеринг экрана это хорошо, но для лучшего раскодирования информации слушатель должен рядом видеть “говорящую голову”.</p><p><strong>Ошибка №8<br></strong>Не включаем камеру, потому что “не я на этой встрече выступаю, послушаю без камеры”.</p><p><strong>Как исправить: </strong>Всегда включаем камеру, потому что включенная камера заставляет нас концентрироваться на выступающем. Когда камера ON уже неловко пойти наливать чай, проверять телефон или играть с котом, а значит, мы даем себе больше шансов услышать то, что рассказывает выступающий.</p><p><strong>Ошибка №9<br></strong>Подключаемся ко встрече из неудобного для разговора места, например, транспорта или больницы, чтобы сделать два дела одновременно.</p><p><strong>Как исправить: </strong>Стараемся находить для встречи тихое спокойное место. Посторонний шум создает барьеры восприятия — он не просто мешает расслышать говорящего, но и просто сконцентрироваться на обсуждаемой теме.</p><p>Помехи при этом создаются для всех участников — так мы создаем проблемы не только себе, но и коллегам.</p><p>Кстати, шумы (помехи) бывают разные, это не обязательно звук чего-либо. Когда мы говорим слишком тихо или слишком громко — это физический шум, и он тоже мешает получать информацию.</p><p><strong>Ошибка №10<br></strong>Ставим встречу во время обеда или больничного коллеги, ведь вопрос важный, откладывать нельзя.</p><p><strong>Как исправить: </strong>Даем коллегам заслуженное время на еду или выздоровление, а встречу планируем после. Еще один вид шума — физиологический. Например, если человек голоден или заболел, он будет хуже воспринимать информацию.</p><blockquote><strong>Подведем итог! </strong>Встреча — синхронный и дорогой для компании формат коммуникации. Встреча это не только время, которое она занимает, к ней нужно подготовиться, после нее нужно подвести итог и спланировать следующие шаги. Чтобы встречи в remote-формате были эффективнее, прививайте правильную культуру коммуникации в компании. Вполне может быть, что причина снижения продуктивности не в удаленном формате работы, а в неумении этот формат организовать 😉</blockquote><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=6a78b10a086f" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Да я сам вечером быстренько сделаю…]]></title>
            <link>https://medium.com/@ekaterinayanke/%D0%B4%D0%B0-%D1%8F-%D1%81%D0%B0%D0%BC-%D0%B2%D0%B5%D1%87%D0%B5%D1%80%D0%BE%D0%BC-%D0%B1%D1%8B%D1%81%D1%82%D1%80%D0%B5%D0%BD%D1%8C%D0%BA%D0%BE-%D1%81%D0%B4%D0%B5%D0%BB%D0%B0%D1%8E-d29f228761aa?source=rss-41304787e7da------2</link>
            <guid isPermaLink="false">https://medium.com/p/d29f228761aa</guid>
            <category><![CDATA[management-skills]]></category>
            <category><![CDATA[delegate]]></category>
            <category><![CDATA[management-and-leadership]]></category>
            <dc:creator><![CDATA[Ekaterina Yanke]]></dc:creator>
            <pubDate>Thu, 12 May 2022 08:23:08 GMT</pubDate>
            <atom:updated>2022-05-12T08:23:31.845Z</atom:updated>
            <content:encoded><![CDATA[<p><strong>Неумение делегировать</strong> — балласт, который <strong>тянет руководителя назад на позицию исполнителя.</strong></p><p>Ответь на вопросы, чтобы понять, как у тебя обстоят дела 👇</p><p>– Ты делегировал задачу и можешь спокойно дождаться результата, или будешь часто проверять прогресс выполнения?<br>– Ты часто считаешь, что если ты сделаешь задачу сам, то получится лучше?<br>– Тебе кажется, что самостоятельно быстрее, ведь ты загружен, а времени учить кого-то и отвечать на вопросы у тебя нет?<br>– Ты рад бы поделиться хоть чем-то из списка своих задач, но рядом никогда нет подходящего специалиста?<br>– У тебя есть ощущение, что если подчиненный добьется успеха в выполнении задания, то он тебя перерастет и двинет с твоего места?<br>– Ты думаешь, что если передашь все задачи подчиненным, то у тебя не останется работы?</p><p><strong>Если у тебя много ответов “да”, значит </strong>с делегированием у тебя <strong>что-то пошло не так</strong>.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*mBDWLCFlpGB0PH8IUHhJJw.png" /></figure><p>Частая история, когда руководитель вырастает из исполнителя — это значит, что он настолько круто научился что-то делать, что его достижения оценили. И, конечно, на новой позиции возникает ряд страхов, например, страх не оправдать ожиданий или страх новых задач и обязанностей. Такие страхи заставляют молодых руководителей делать работу за своих подчиненных продактов/дизайнеров/разработчиков, вместо того, чтобы взяться за более интересные и ценные задачи: стратегию, процессы, обучение, партнерства.</p><p><strong>Вот несколько советов, как научиться делегировать:</strong></p><p>1️⃣ Спроси, был ли у коллеги опыт решать такие задачи, если нет, то хочет ли он научиться. Случается, что человек просто не хочет развиваться в части новых обязанностей, но это не тема данной заметки.</p><p>2️⃣ Четко проговори (а потом и в письменном виде в чатик отправь) что ты просишь сделать и какой дедлайн. При постановке цели проверь ее по SMART, а то вдруг ты просишь сделать что-то непонятное или недостижимое.</p><p>3️⃣ Если поручаешь что-то новичку, сразу договоритесь о том, как часто и в каком объеме ему доступна твоя помощь.</p><p>4️⃣ Замотивируй исполнителя — объясни, какой ему профит от того, что ты на него возлагаешь. Банально, но, если человек не понимает зачем ему сгрузили задание, он с высокой вероятностью завалит его выполнение.</p><p>5️⃣ Начни с небольших и обязательно не срочных задач. Так ты подстрахуешь себя и своего коллегу от страха провала.</p><p>6️⃣ Когда кто-то приходит к тебе вопросом в том, в чем ты эксперт, вместо решения, задай ему парочку открытых вопросов, например, “Как ты пробовалэто решить. Что именно не сработало?” или “А ты уже погуглил?” — методика из коучинга, которая запустит в коллеге механизм самопоиска решения, благодаря чему тебе не придется за него думать.</p><p>7️⃣ Про то, что достичь цели можно разными способами, и твое решение не обязательно единственно верное даже писать не буду. Ой, написала? 😀</p><p><strong>Напоследок:</strong></p><p>➕ Если ты хочешь стать продуктивнее — учись делегировать. “Сделаю сам” немасштабируемая история, т.к. в неделе все еще 40 рабочих часов.</p><p>➕ Если тебя только что посвятили в руководители, не стесняйся попросить обучение, чтобы задачи новой должности тебя не стрессовали (правильному делегированию, как и многому другому можно и нужно учиться).</p><p>➕ Если ты кого-то повысил в должности, помоги ему научиться, ведь его успехи автоматом засчитаются тебе ;)</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=d29f228761aa" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Продуктовый дизайнер — проектировщик клиентского опыта или раскрашиватель прототипов?]]></title>
            <link>https://medium.com/@ekaterinayanke/%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2%D1%8B%D0%B9-%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD%D0%B5%D1%80-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D1%89%D0%B8%D0%BA-%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D1%81%D0%BA%D0%BE%D0%B3%D0%BE-%D0%BE%D0%BF%D1%8B%D1%82%D0%B0-%D0%B8%D0%BB%D0%B8-%D1%80%D0%B0%D1%81%D0%BA%D1%80%D0%B0%D1%88%D0%B8%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C-%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D1%82%D0%B8%D0%BF%D0%BE%D0%B2-452b53f8ed46?source=rss-41304787e7da------2</link>
            <guid isPermaLink="false">https://medium.com/p/452b53f8ed46</guid>
            <category><![CDATA[product-management]]></category>
            <category><![CDATA[teamwork]]></category>
            <category><![CDATA[product-mistakes]]></category>
            <category><![CDATA[product-design]]></category>
            <dc:creator><![CDATA[Ekaterina Yanke]]></dc:creator>
            <pubDate>Fri, 15 Apr 2022 10:27:55 GMT</pubDate>
            <atom:updated>2022-04-15T10:27:55.272Z</atom:updated>
            <content:encoded><![CDATA[<p><strong>Продуктовый дизайнер — проектировщик клиентского опыта или раскрашиватель прототипов?</strong></p><p>Мне кажется, что во многих российских компаниях с продуктовыми дизайнерами до сих пор происходит такая же ситуация, которая была с менеджерами продукта лет 5–7 назад — мы нанимаем этого специалиста в команду, хотим, чтобы он обладал кучей разных классных навыков, а по факту позволяем ему только раскрашивать прототипы.</p><p>Есть и более прогрессивные компании, где позиция продуктовый дизайнер раскладывается аж на несколько сотрудников: ресечер, проектировщик и UIщик, но я в таких, к сожалению, пока не работала 🙂</p><p><strong>На примере горы Казбек рассмотрим некоторые требования к продуктовым дизайнерам </strong>🙃</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*5sIccSCz-5XvUjxd8exStw.png" /></figure><p>1. Отрисовывать ин­тер­фей­сы и проводить дизайн-кон­троль;<br>2. Под­дер­жи­вать и рас­ши­рять ди­зайн-си­сте­му;<br>3. Проектировать пользовательский путь с разным уровнем; детализации прототипов;<br>4. Проводить анализ решений конкурентов;<br>5. Ис­сле­до­вать бизнес-про­цес­сы;<br>6. Со­став­лять и приоритизировать про­дук­то­вые ги­по­те­зы;<br>7. Про­ве­рять гипотезы (юзабилити тесты на прототипах, first-click тест);<br>8. Про­во­дить более серьезные ди­зайн-ис­сле­до­ва­ния (например, eye-tracking);<br>9. Оценивать внедрения по метрикам.</p><p><strong>Теперь признаемся себе, какие из пунктов выполняют дизайнеры в наших командах.</strong> Из моего опыта, чаще всего дизайнеры выполняют только половину — верхушку горы. И на это может несколько причин. Вот самые распространенные из них:</p><p>1️⃣ <strong>Неравномерное распределение дизайнеров на команды.</strong> Часто встречается схема, когда дизайнер работает в паре с двумя-тремя продуктовыми менеджерами (читай на 2–3 продукта). Не удивительно, что такой организацией процесса дизайнер ставится в вынужденный перегруз ручной работы — на исследования и анализ им просто не хватает времени.</p><p>2️⃣ <strong>Неумение менеджеров делегировать.</strong> Это то, что я вижу на каждом втором менеджере продукта — из-за неумения во время привлечь дизайнера к процессу и проблем с донесением задачи, продакт садится и самостоятельно создает высокодетализированный прототип в Miro. Зачастую дизайнер все равно переделывает полученный прототип в лучшую сторону. Так получается, что продакт делает лишнюю работу, тратит время, которое мог бы выделить на другие задачи. А некоторые дизайнеры принимают прототип “как есть”, и рисуют по нему UI — так менеджер продукта и вся команда лишаются мозга дизайнера, и используют его только в качестве рук. Оплата высококвалифицированному специалисту производится, но команда и бизнес не получают полный профит.</p><p>Менеджерам полезно помнить, что <strong>рутинное рисование макетов приводит к остановке развития дизайнера, к неудовлетворению работой, к выгоранию</strong>. Ну и самим продактам остается меньше времени на исследовательские и бизнесовые задачи, потому что рабочий день занят работой другого специалиста, а это уже тормозит и развитие самого менеджера. Вот такой “забавный” круговорот неразвития сотрудников в командах.</p><p>—</p><p>Заметка основана на недавних рассуждениях о продуктовых дизайнерах, их компетенциях и зонах ответственности, с одним из представителей профессии. <a href="https://t.me/Sayhigleb">Глеб</a>, спасибо, за идею для заметки 😉</p><p>Мои размышления на другие темы <a href="https://t.me/it_people_management">тут</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=452b53f8ed46" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Культура в компании. Как найти свой match]]></title>
            <link>https://medium.com/@ekaterinayanke/%D0%BA%D1%83%D0%BB%D1%8C%D1%82%D1%83%D1%80%D0%B0-%D0%B2-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D0%B8%D0%B8-%D0%BA%D0%B0%D0%BA-%D0%BD%D0%B0%D0%B9%D1%82%D0%B8-%D1%81%D0%B2%D0%BE%D0%B9-match-e6b1d8fbcd0d?source=rss-41304787e7da------2</link>
            <guid isPermaLink="false">https://medium.com/p/e6b1d8fbcd0d</guid>
            <category><![CDATA[corporate-culture]]></category>
            <dc:creator><![CDATA[Ekaterina Yanke]]></dc:creator>
            <pubDate>Tue, 05 Apr 2022 16:04:38 GMT</pubDate>
            <atom:updated>2022-04-05T16:04:38.653Z</atom:updated>
            <content:encoded><![CDATA[<p>На прошлой неделе было аж два диалога на тему культуры. Первый, когда подруга позвонила посоветоваться, какой из 2 офферов выбрать. Компании в разных странах, делают разные продукты и несут разную миссию — выбор был не очевиден. Второй — <a href="https://t.me/producthr">пост</a> Тани Гороховской “Выбирайте компанию в соответствии с ценностями” в ее канале. Я решила поразмышлять, как же перед трудоустройством проверить, что транслируемые ценности правда, как часто делать health-чек в процессе работы, и когда уже точно пора валить?</p><p><strong>Для меня корпоративная культура, это принятые в компании нормы взаимоотношений между сотрудниками, стиль их мышления, ритуалы и правила ежедневного использования и,</strong> <strong>конечно, стиль управления и лидерства.</strong></p><p>Случается, что на собеседовании и сайте компании для соискателей транслируются одни позиции и смыслы, а менеджмент в повседневных рабочих процессах, общении и требованиях все это перечеркивает и рисует совершенно другую картинку. Так может случиться, если руководство считает культуры ерундой и отдает её на откуп отделу кадров. HR копируют тезисы от других компаний, надеясь, что это будет привлекать кандидатов, а может даже искренне веря, что написанное приживется.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*utiTwaAcyWVYUn57-no1Wg.png" /></figure><p>Бывает и иначе, с таким исходом я столкнулась на текущем месте работы. Уверена, что это не единичное явление. <strong>Созданная при основании стартапа культура, на этапе масштабирования съелась культурой компании-инвестора</strong> 🍴. В самом начале от стартапа ждали лишь положительный результат, никто не лез во внутренние устройство. А когда результат появляется и встает вопрос роста, появились потребности в дополнительных инвестициях, а чтобы их выделить, инвесторы начали присматриваться повнимательнее и добавили своих людей в управленческий совет. Так начался процесс принудительного прививания сотрудникам ценностей и правил, которых до этого не было. С подобным изменением сталкиваются и сотрудники пережившие продажу компании.</p><p><strong>Новое руководство = новые правила</strong>. <br>Вернусь таки к вопросам. Начну с первого вопроса.</p><h3><strong>Как проверить культуру перед трудоустройством? </strong>🔍</h3><p>В книжке HBR культуры компаний предлагают оценивать <strong>по степени взаимодействия в них людей</strong> и <strong>по тому, как люди реагируют на изменения</strong>.</p><p>Для соискателя это означает, что перед устройством на работу, ему нужно получить отчет на ряд вопросов, и смэтчить ответы со своим представлением компании-мечты. Вопросы, например, могут быть такими:</p><p>❓ Расскажите про миссию компании и ее ценности. Расскажите цели на этот год.<br>❓ Как формулируются цели и ставятся задачи: сверху вниз или снизу вверх.<br>❓ На какой срок ставятся цели? Бывает ли смена курса? Как часто: раз в год, раз в квартал, раз в неделю? Как на это реагируют сотрудники? Достигаются ли поставленные цели? Как часто не достигаются и в чем сотрудники видит причину?<br>❓ Кто несет ответственность за невыполнение: команда, конкретный сотрудник или руководство? Какие меры применяются в данном случае?<br>❓ Есть ли у сотрудников доступ до высшего руководства? Насколько основатели открыто делятся происходящим в компании? Как организован этот процесс?<br>❓ Всем ли подразделениям компании доступны KPI друг друга?<br>❓ У сотрудников есть общие на команду KPI или есть еще и персональные?<br>❓ Как оценивается уровень удовлетворенности сотрудников работой в компании? Что по результатам последней оценки сотрудники считают самым крутым, а что просят изменить?<br>❓ Какое обучение предусмотрено для сотрудников (командное/персональное)? Есть ли карта роста? Расскажите, кем я могу стать в вашей компании через 3 года.</p><p>Вопросы каждый может составить под себя, но даже получив ответы на вопросы из примера можно понять, насколько руководство открыто, насколько прозрачны процессы и кто несет ответственность, интересует ли компанию благополучие и развитие сотрудников и еще много всякого интересного. Замечательно, если получится задать одни и те же вопросы сначала HR, а потом занимающему менеджеру, а может даже и команде, если такой этап собеседования предполагается. Дальше стоит сходит почитать, что транслируют сотрудники в соц сетях и на конференциях. Выбор компании мечты — это ресечь, который не нужно лениться проводить ;)</p><p>Я работала с разными людьми, все они хорошие, но разные — кто-то хочет принимать участие в жизни компании, влиять на это, а некоторым комфортно быть отличным исполнителем решений, который кто-то принял за них. И это нормально. Не нормально, когда от людей с исполнительским складом личности требуют предпринимательского подхода, а амбициозным предпринимателям спускают задачи с четким ТЗ.</p><h3>Как часто делать health-чек культуры в процессе работы, и когда уже точно пора валить? 🕰</h3><p>На работе мы проводим треть взрослой жизни, поэтому не надо объяснять, почему важно, чтобы там было комфортно. Я считаю, что каждый должен четко понимать, из чего складывается его мотивация. Если мотивация сотрудника маппится на культуру и ценности компании — хорошо всем: сотрудник доволен и работает продуктивно, цели бизнеса достигаются. Если происходит рассинхрон — человек чувствует недовольство и тревогу, это сказывается на его здоровье и производительности, и, конечно, на компании — она теряет мотивированного сотрудника. Тут стоит задуматься обеим сторонам ;)</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*XyX-CIq7StwraOgIAfUFTA.png" /></figure><p>Для себя я взяла квартал, как период health-чек происходящего в компании — не слишком короткий период, чтобы не принимать импульсивных решений, и не слишком длинный, чтобы подвести итоги, пока они еще свежи в памяти. Если несколько периодов подряд динамика негативная — значит мои ценности и ценности/культура компании расходятся все дальше. А это звоночек, что пора валить 🏃‍♀🏃.</p><p>Это, кстати, не означает, что компания стала плохой. Для меня это означает, что мы стали слишком разными и нам больше не по пути :)</p><p>— <br>Мои размышления на другие темы <a href="https://t.me/it_people_management">тут</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=e6b1d8fbcd0d" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Пошаговый рецепт приготовления интервью]]></title>
            <link>https://medium.com/@ekaterinayanke/%D0%BF%D0%BE%D1%88%D0%B0%D0%B3%D0%BE%D0%B2%D1%8B%D0%B9-%D1%80%D0%B5%D1%86%D0%B5%D0%BF%D1%82-%D0%BF%D1%80%D0%B8%D0%B3%D0%BE%D1%82%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%B2%D1%8C%D1%8E-975afae5c166?source=rss-41304787e7da------2</link>
            <guid isPermaLink="false">https://medium.com/p/975afae5c166</guid>
            <category><![CDATA[product-management]]></category>
            <category><![CDATA[customer-development]]></category>
            <category><![CDATA[interview]]></category>
            <dc:creator><![CDATA[Ekaterina Yanke]]></dc:creator>
            <pubDate>Fri, 16 Jun 2017 07:23:45 GMT</pubDate>
            <atom:updated>2022-07-27T14:22:17.960Z</atom:updated>
            <content:encoded><![CDATA[<blockquote>Совершенно не о том, как важно и полезно говорить с пользователями, а о том, как это сделать в первый раз.</blockquote><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*FOKrISkDEqyAYuZ7mFqcjg.jpeg" /></figure><h3>Предисловие</h3><p>Не нужно пытаться сделать все идеально с первого раза. Цель первых 2–3 интервью — понять, что это не страшно, проанализировать случившееся, и скорректировать план дальнейших действий.</p><h3><strong>Ингредиенты</strong></h3><ul><li>блокнот и ручка;</li><li>смартфон с диктофоном;</li><li>заинтересованный (или тот, кого хочется заинтересовать) коллега;</li><li>таблетки от интровертности.</li></ul><h3>Преподготовка</h3><p>Прикидываем, кого приглашать в качестве респондента, и о чем его спрашивать. Для этого нужно зафиксировать (обязательно на бумаге) свои текущие гипотезы и представления о проблемах пользователей.</p><p>Итак, описываем основное:</p><ul><li>проблемы пользователей;</li><li>текущие способы решения проблем (не обязательно с помощью конкурирующих продуктов, подойдут и оффлайн аналоги);</li><li>что случается с пользователями, если они не могут решить свои проблемы;</li><li>платят ли они за решение проблемы, сколько платят.</li></ul><h3>Поиск респондентов</h3><p>Для первой пары интервью (очень часто) подходят друзья друзей или бывшие коллеги коллег. Шаг с поиском респондента для многих самый страшный, ведь нужно говорить с незнакомыми людьми, просить их о чем-то. Самое простое — скинуть страшное и неприятное на знакомых, пусть они заочно вас представят и договорятся о встрече. От вас потребуется только вводное письмо, чтобы ваши знакомые поняли о чем они просят своих друзей.</p><p>Люди любят помогать другим и решать чужие проблемы, поэтому уговаривать их долго не придется. Необходимо всего лишь закинуть запрос по (примерно) такой форме: “Дорогие коллеги, наверняка у вас есть друзья и знакомые, которые месяц назад сталкивались с такой-то проблемой и удачно с ней справились (или нет). Я приступил к работе над продуктом, который предназначен для решения подобных проблем. Пока еще я мало знаю об этом, поэтому экспертиза ваших знакомых будет очень-очень-сильно-сильно полезна для меня. Пожалуйста, найдите мне несколько человек, готовых уделить мне 30 минут времени для беседы (по скайпу, телефону или я приеду куда и когда скажет респондент).”</p><p>Я проверяла эту схему много раз. Она точно работает!</p><p>Считаем, что первая партия респондентов найдена. Чтобы найти следующих, придется навязываться людям лично. К слову, это сильно проще делать после первых положительно-проведенных интервью ;)</p><p>Чтобы найти людей для дальнейших интервью нужно:</p><ul><li>попросить контакт у того, кого вам любезно нашли коллеги;</li><li>разместить опрос на сайте компании с просьбой оставить контакты для дальнейшей беседы;</li><li>попросить у техподдержки контакты особо активных пользователей (этим наверняка есть чем поделиться);</li><li>закинуть запос в паблики в соцсетях;</li><li>сделать рассылку по базе клиентов.</li></ul><p>Схема та же: кратко описываем суть проблемы (многие боятся, что им будут что-то продавать, поэтому можно развеять этот страх), акцентируем внимание на важности опыта и экспертизы, указываем время и способ связи. Все это укомплектовываем в короткое и емкое послание, чтобы его дочитали.</p><h3>Подготовка</h3><p><strong>Структура. </strong>Структура нужна для того, чтобы избежать неловких пауз. Нет смысла строго придерживаться заготовленной структуры, непринужденная беседа проходит легче сухого опроса по списку. Если респондент захлебываясь рассказывает о чем-то, не перебиваем его ради следующего вопроса по списку.</p><p>Люди любят рассказывать о проблеме и своих мужественных решениях, и совершенно не любят рассказывать незнакомым людям о своей работе и семье. Поэтому, сначала спрашиваем про проблему, а личные вопросы для статистики оставляем под конец.</p><p><strong>Вопросы. </strong>Вопросы задаем только открытые и только про прошлый опыт. Цель — узнать, как человек в действительность решал задачу, а не как он думает, он будет решать эту задачу в следующий раз. Разница здесь в том, что мечты с реальностью расходятся примерно всегда.</p><p>Базовые вопросы:</p><ul><li>Как вы решали проблему (покупали машину, бронировали отель, вызывали няню, выбирали парикмахера) последний раз?</li><li>Почему именно тогда возникла потребность в товаре/услуге? Разовая потребность или регулярная?</li><li>Сколько дней/месяцев заняли поиски?</li><li>Какими устройствами пользовались? Какой у вас планшет? Приложение скачали или в мобильной версии сайта смотрели?</li><li>Кого звали на помощь/привлекали посоветоваться?</li><li>Сколько заплатили? Почему решили не платить?</li></ul><p>И так далее. После каждого вопроса смело спрашиваем “А почему?”, и просим рассказать подробнее о том, как человек пришел к такому решению, считает ли он его удобным/выгодным/быстрым и так далее и, что важно, почему.</p><p><strong>Коллега.</strong> Он поможет проверить структуру и вопросы. А еще на нем потренироваться можно.</p><p>С коллегой сразу договариваемся, что интервью проводит не он, он будет сидеть и все внимательно фиксировать (на бумажку и на диктофон). Это поможет главному актеру не терять зрительный контакт и не отвлекаться на пометки.</p><p><strong>Пометки.</strong> Придумываем знаки, которыми можно помечать важные моменты. Например, если респондент высказался с агрессией, ставим символ молнии, если рассмеялся — веселый смайлик. Если повторил одно и то же 3 раза — восклицательный знак. Пометки помогут расшифровывать записи после интервью и вспоминать эмоциональную окраску послания.</p><h3>Интервью</h3><p>Тут все просто:</p><ul><li>Не опаздываем.</li><li>Представляется (говорим “я” вместо “мы” — компании безлики, а вы тот самый живой человек, который так зависит от экспертного опыта).</li><li>За минуту рассказываем, о чем и для чего мы все это устроили, успокаиваем, что данные не будет нигде опубликованы.</li><li>Спрашиваем, сколько у вашего респондента времени на беседу. Если видим, что респондент торопится, не затягиваем встречу. Люди часто втягиваются и тратят на беседу больше времени, чем хотели. Действуем по ситуации, но, точно не будет лишним заложить на беседу в 2 раза больше оговоренного времени, чтобы не поглядывать нервно на часы, опаздывая на следующее мероприятие.</li><li>Не перебиваем и не вбрасываем свои предположения. Любое предположение — это закрытый вопрос. Даем человеку сказать мысль своими словами, даже если кажется, что его мысль понятна.</li><li>Если человек с болью в голосе рассказывает, что он не мог с чем-то справиться на его текущем девайсе, не упускаем возможности и просим показать, как он это делает.</li><li>Проблема точно не там, где кажется, поэтому, на всякий случай в любой ситуации спрашиваем “А почему?”.</li><li>О неудачном опыте слушаем вдвойне внимательно (иногда люди придумывают ограничения, которые мешают им решить проблему);</li><li>При наличии решения (макетов, прототипов), показываем их в самом конце. Сначала вопросы о прошлом/текущем опыте, любые попытки обсудить что-то еще — после;</li><li>В конце договариваемся о повторном общении, например, чтобы потестировать прототип продукта. Пригодится!</li></ul><h3>Обработка результатов</h3><p>С обработкой записей затягивать не стоит. Ценные эмоции и детали забываются уже на следующий день.</p><p>Лучше всего пройтись по заметкам сразу после интервью, дописать важные моменты, сделать дополнительные пометки, зафиксировать инсайты и места, где гипотезы подтверждаются или опровергаются.</p><p>После примерно 6–8 интервью будут заметны схожие поведенческие шаблоны, их тоже стоит сразу помечать.</p><p>Если после 10 интервью не встретилось ни одного шаблона, не подтвердилось ни одной гипотезы, и не нашлось ни одного инсайта, скорее всего, что-то идет не так (не те люди, не те вопросы).</p><p>Не стоит настраиваться на негатив, наверняка все получится ;)</p><h3>Сколько интервью нужно провести</h3><p>На этот вопрос каждый отвечает по-своему. Все зависит от задачи и её сложности. В поиске новых идей при полном незнании ЦА может хватить 10 интервью, для подтверждения гипотезы — 30. Ваша цель — снизить риски, поэтому главное не врать себе. Если вашу гипотезу подтвердило 3 человека, это еще не значит, что нужно отправлять в разработку навороченную фичу. Однако, если 10 из 10 опрошенных (которые прям точно ваша ЦА) говорят, что им не нравится пони, и четко аргументируют почему, это явно звоночек о том, что не стоит торопиться забивать склады этими милыми созданиями.</p><p>Я обычно поступаю так: если гипотеза явно опровергается, я отбрасывают её, если же складывается несколько явных поведенческих шаблонов, на основании которых можно принимать решение о запуске нового функционала — я запускаю опрос на большей аудитории для количественного подтверждения.</p><h3>Напоследок</h3><p>Не обязательно проводить все интервью по одному шаблону, результат все равно не сойдет за количественное исследование. Куда полезнее анализировать каждое интервью, улучшать вопросы, менять структуру — в общем, искать идеальный рецепт для своей задачи.</p><p>— <br><a href="https://t.me/it_people_management">Читать</a> заметки про People management &amp; Soft skills</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=975afae5c166" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Целых 6 видов MVP]]></title>
            <link>https://medium.com/@ekaterinayanke/%D1%86%D0%B5%D0%BB%D1%8B%D1%85-6-%D0%B2%D0%B8%D0%B4%D0%BE%D0%B2-mvp-9517d7afc9a0?source=rss-41304787e7da------2</link>
            <guid isPermaLink="false">https://medium.com/p/9517d7afc9a0</guid>
            <category><![CDATA[mvp]]></category>
            <category><![CDATA[lean-startup]]></category>
            <category><![CDATA[product-management]]></category>
            <dc:creator><![CDATA[Ekaterina Yanke]]></dc:creator>
            <pubDate>Mon, 15 May 2017 07:33:17 GMT</pubDate>
            <atom:updated>2022-07-27T14:21:54.148Z</atom:updated>
            <content:encoded><![CDATA[<p><em>Вы называете первую версию продукта MVP?<br>Если да — статья для вас!</em></p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*nL7CIiWLgmf09VSuj-e-wA.jpeg" /></figure><p>Точно не помню откуда, но я давно знала, что MVP совсем не обязательно первая версия продукта. Я считала, что MVP — прототип, который можно выбросить, если идея не выстрелит. Или же выбросить и запилить нормально с нуля, если идея взлетит.</p><p>Зимой прочитала книжку Синди Альварес “Как создать продукт, который купят. Метод Lean Customer Development”, которая подкинула несколько новых знаний.</p><h3>Итак, MVP != первая версия продукта</h3><p>Да, пожалуй, лучше повторить, что MVP не обязательно продукт. Поэтому, не нужно называть так первый релиз продукта или фичу с урезанным (но запиленным сразу по всем правилам с заделом на будущее) функционалом.</p><p>MVP — лишь способ проверки гипотез.</p><h3><strong>6 способов проверки гипотез (или 6 видов MVP)</strong></h3><p>Пройдемся по всем без “воды”.</p><h3>1. MVP для предварительного заказа</h3><p><strong>Когда использовать:</strong> если разработка продукта потребует значительных затрат времени и ресурсов (например, вы придумали инновационный чайник) и/или для обеспечения рентабельности потребуется большое количество клиентов.</p><p><strong>Что делать:</strong> создать краудфандинговую кампанию на Boomstarter или запилить лендинг на конструкторе сайтов.</p><p><strong>Цель:</strong> получить предоплату, которая будет являться доказательством того, что люди действительно будут платить за продукт.</p><h3>2. Клиентообразующий MVP</h3><p><strong>Когда использовать:</strong> есть идея, но вы не являетесь экспертом области, поэтому вам нужно углубиться в мир клиентов, чтобы понять, сможет ли (и как) ваш продукт этот мир изменить; еще подойдет для онлайн-продуктов, консалтингового рынка, бесплатных и социальных товаров.</p><p><strong>Что делать:</strong> создать группы в социальных сетях.</p><p><strong>Цель:</strong> создать базу клиентов до разработки продукта, чтобы определить контент и функции будущего продукта; оценить заинтересованность потенциальных клиентов.</p><p><strong>Важно:</strong> не путайте интерес к теме с готовностью платить.</p><h3>3. MVP “Консьерж”</h3><p><strong>Когда использовать: </strong>если ваши клиенты работают в оффлайне и плохо разбираются в технологии; если вы работаете с продуктом с трудно предсказуемой логистикой.</p><p><strong>Что делать: </strong>вручную помогать клиентам решать их задачи (например, до разработки сервиса по доставке покупок на дом, по телефону узнать, что хочет купить клиент, потом сходить в магазин, купить это и доставить ему домой).</p><p><strong>Цель: </strong>на основе индивидуального подхода к каждому клиенту получить опыт работы с продуктом еще до его автоматизации, оценить спрос и понять, кого действительно интересует услуга.</p><h3>4. MVP “Волшебник страны Оз”</h3><p><strong>Когда использовать: </strong>если продукт требует разработки сложных алгоритмов или автоматизации процессов; если вы работаете в сложных отраслях (финансовой, юриспруденции).</p><p><strong>Что делать: </strong>прежде чем делать сложный функционал, разместить на сайте форму для заявки из двух полей (описание, контакты). Обработать форму силами специалиста офиса и отправить результат клиенту. С виду это будет выглядеть, как будто заявка обработана системой.</p><p><strong>Цель:</strong> узнать о частотности запросов и выглядеть в лице клиентов серьезной компанией (раз предлагаете автоматизированные услуги).</p><h3>5. MVP для одновариантного использования</h3><p><strong>Когда использовать: </strong>вы предполагаете, что часть продукта нужно выделить в самостоятельный продукт; вы выходите на рынок, где доминирует более сложный и дорогой продукт.</p><p><strong>Что делать:</strong> вместо внедрения функционала в текущий ресурс, создать отдельную страницу (отдельный домен и дизайн), на которую пустить небольшое количество нового трафика.</p><p><strong>Цель: </strong>продукт, который предлагает решить только одну 1 из существующих проблем, поможет проверить гипотезу о ценности и жизнеспособности именно этой функциональности.</p><h3>6. MVP “Чужой продукт”</h3><p><strong>Когда использовать: </strong>если выходите на рынок, где работают зрелые конкуренты; хотите разработать продукт с трудно предсказуемой логистикой или ограничены в инженерных ресурсах.</p><p><strong>Что делать: </strong>для желающих предлагать, например, дополнительные услуги в сфере туризма (а в будущем открыть нового туроператора), подключить на свой сайт базу поиска конкурентов, и начать с продажи услуг по оформлению документов, виз.</p><p><strong>Цель:</strong> проверить свои силы, знания области и протестировать маркетинговые каналы.</p><h3>Если подытожить</h3><p>MVP продукта может быть группой в соцсети, краудфандинговой кампанией, лендингов или вовсе не существовать в онлайне (в случае с консьержем). Все это означает, что проверить гипотезу можно без команды разработки и бюджета.</p><p>Никто не запрещает придумать свои способы проверки гипотез или комбинировать предложенные в книге. Главное — не обманывать себя, сначала проверять, а потом вкладывать ресурсы в разработку.</p><p>— <br><a href="https://t.me/it_people_management">Читать</a> заметки про People management &amp; Soft skills</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=9517d7afc9a0" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Как я выступила потенциальным клиентом online школ английского языка]]></title>
            <link>https://medium.com/@ekaterinayanke/%D0%BA%D0%B0%D0%BA-%D1%8F-%D0%B2%D1%8B%D1%81%D1%82%D1%83%D0%BF%D0%B8%D0%BB%D0%B0-%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%BC-%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D0%BE%D0%BC-online-%D1%88%D0%BA%D0%BE%D0%BB-%D0%B0%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%BE%D0%B3%D0%BE-%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0-cecf31a23cba?source=rss-41304787e7da------2</link>
            <guid isPermaLink="false">https://medium.com/p/cecf31a23cba</guid>
            <category><![CDATA[english-learning]]></category>
            <category><![CDATA[product-management]]></category>
            <dc:creator><![CDATA[Ekaterina Yanke]]></dc:creator>
            <pubDate>Tue, 14 Feb 2017 09:05:14 GMT</pubDate>
            <atom:updated>2017-02-14T09:08:40.073Z</atom:updated>
            <content:encoded><![CDATA[<p>Решила я взять несколько уроков английского по Skype, чтобы подтянуть разговорный навык. Когда я задумалась о школе, на ум сразу пришла Skyeng. Хорошая реклама, отзывы и постоянное упоминания продукта на различных продуктовых мероприятиях сформировали положительное впечатление и желание попробовать, поэтому я сразу отправила заявку на пробное занятие. Потом мне стало интересно, какие еще аналоги существуют на рынке. Я посмотрела еще 4 школы из выдачи google, и отправила вторую заявку в Инглекс.</p><p>Со мной связались менеджеры обеих школ, и я рассказала им всю правду о своих намерениях:</p><ul><li>хочу взять несколько разговорных занятий один на один с преподавателем, чтобы побороть неловкость и подтянуть навык общения;</li><li>учусь в группе в offline школе, бросать не собираюсь, потому что там носители языка и вообще все нравится;</li><li>мне не нужна грамматика, так как ее я прохожу с группой;</li><li>выбираю между 2 школами (даже названия скрывать не стала).</li></ul><p>Менеджеры назначили мне пробные занятия. Все шло замечательно.</p><p>Первое пробное занятие было в Инглекс. Оно было коротким, кажется, не более 30 минут. Приятная девушка общалась со мной на английском, задавала вопросы и терпеливо ждала, пока я озвучу вымученный (зато на английском!) ответ. После нескольких вопросов она сказала, что понимает мой уровень и мою задачу, и готова предложить занятия по разговорному курсу, а тратить время на теорию нет смысла, ведь ее я прохожу в группе. Мне озвучили стоимость занятий (она соответствовала цене, указанной на сайте), и сообщили, что менеджер школы перезвонит мне через несколько дней, сразу после пробного занятия в Skyeng.</p><p>Если занятие в школе, о которой я раньше не знала прошло так замечательно, я ожидала, что Skyeng будет бомбой. Да что уж там, подсознательно я уже выбрала Skyeng.</p><p>Но, что-то пошло не так.</p><p>На пробном от Skyeng девушка была столь же милой, но говорить начала по-русски. Занятие длилось около 50 минут, 20 из которых была реклама платформы, возможностей учить там грамматику, писать эссе и т.д (половину этого уже рассказал менеджер во время первого звонка). После рекламирования всех плюшек я услышала предложение по обучению и стоимость. Мне предлагался полный курс с грамматикой. Стоимость занятия соответствовала указаной на сайте только в том случае, если я оплачу сразу 64 занятия на сумму 44 160 руб.</p><p>И тут наступил ступор — это предложение совершенно не отвечало моей потребности. Разве я не говорила менеджеру, что мне нужно несколько уроков (64 и несколько не одно и то же), что мне не нужна грамматика? Почему нельзя было сразу раскрыть стоимость для небольшого количества занятий?</p><p>Менеджер Инглекс позвонил в обозначенное время, и я приняла их предложение, а менеджер Skyeng был вторым, поэтому никакие варианты особых условий роли не сыграли.</p><p>Skyeng, ну как же так? Я до сих пор хочу, чтобы вы были бомбой! Наверно, это сила сформировавшегося впечатления. Возможно, я не ваша ЦА, возможно, вы рассчитываете на клиентов с долгим сроком обучения. Но зачем тогда тратить ресурсы на таких как я? Вы могли отсеять меня на первом звонке менеджера, если бы он сразу сказал, что у вас нет курса под мои нужны, а цена получится сильно выше.</p><p>Вот и получается, что классный продукт (из-за бизнес-процессов) теряет клиентов или тратит ресурсы не на свою ЦА.</p><p>Для себя я галочку поставила, в своей работе буду за такими нюансами следить. Буду рада, если мое непрошеное признание поможет продактам Skyeng сократить издержки, или заполучить новую группу клиентов.</p><p>Ну, кроме всего этого, спасибо Инглекс, что вы есть! Мне с вами хорошо :)</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=cecf31a23cba" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[О ценности понимания целевой аудитории]]></title>
            <link>https://medium.com/@ekaterinayanke/%D0%BE-%D1%86%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8-%D0%BF%D0%BE%D0%BD%D0%B8%D0%BC%D0%B0%D0%BD%D0%B8%D1%8F-%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-2c0723daf402?source=rss-41304787e7da------2</link>
            <guid isPermaLink="false">https://medium.com/p/2c0723daf402</guid>
            <category><![CDATA[product-management]]></category>
            <category><![CDATA[target-customer]]></category>
            <dc:creator><![CDATA[Ekaterina Yanke]]></dc:creator>
            <pubDate>Fri, 10 Feb 2017 10:45:44 GMT</pubDate>
            <atom:updated>2017-02-10T10:45:57.040Z</atom:updated>
            <content:encoded><![CDATA[<p>Ехала я как-то в электричке из отдаленного района в сторону центра города (направление “на юг”). Казалось бы, что можно вынести из этой непримечательный поездки?</p><p>В тамбуре встречаются два местных музыканта, молодой и пожилой. Чтобы вы понимали, они профессионалы: один носит гитару с усилком, второй какое-то оборудование для проигрывания минуса и микрофон.</p><p>Возникает спор. Молодой утверждает, что это его электричка, напоминает пожилому про их прошлый спор на эту тему. В очередной раз обсуждается возможность разделения маршрутов электропоездов.</p><p>Пожилой ничего не отвечает и заходит в вагон. Осматривается, решает воздержаться от исполнения и садится на свободное место. Молодой исполняет композицию в соседнем вагоне и, продвигаясь в голову электропоезда, заходит в наш вагон.</p><p><em>Хм, что-то тут не моя аудитория, — говорит пожилой.<br>Ну так, это же “на юг”, я над аудиторией уже много лет работаю! — отвечает молодой.</em></p><p>Молодой исполняет очередной хит, собирает деньги (минимум двое из вагона дают деньги, это неплохой показатель для местных музыкантов) и отправляется в следующий вагон.</p><p>Нужно ли здесь подвести итог? — Нет, ведь все очевидно и так.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=2c0723daf402" width="1" height="1" alt="">]]></content:encoded>
        </item>
    </channel>
</rss>