<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Self-Development on Константин Заваров</title><link>https://zavarov.com/blog/self-development/</link><description>Recent content in Self-Development on Константин Заваров</description><generator>Hugo</generator><language>ru</language><copyright>Copyright © 2026, Konstantin Zavarov.</copyright><lastBuildDate>Sun, 29 Sep 2024 15:17:01 +0300</lastBuildDate><atom:link href="https://zavarov.com/blog/self-development/index.xml" rel="self" type="application/rss+xml"/><item><title>10 смертных грехов начинающего продакт-менеджера</title><link>https://zavarov.com/10-evils/</link><pubDate>Sun, 29 Sep 2024 15:17:01 +0300</pubDate><guid>https://zavarov.com/10-evils/</guid><description>&lt;p>&lt;em>Оригинал статьи опубликован на &lt;a href="https://habr.com/ru/articles/838694/" target="_blank" rel="noopener noreferrer">habr.com&lt;/a>.&lt;/em>&lt;/p>
&lt;p>«Смертные грехи» можно использовать в качестве чек-листа для самопроверки как начинающим, так и более опытным менеджерам.&lt;/p>
&lt;p>Итак, ошибки и как их исправить.&lt;/p>
&lt;h2 id="1-вера-в-многозадачность">1. Вера в многозадачность&lt;a class="heading-anchor" href="#1-%d0%b2%d0%b5%d1%80%d0%b0-%d0%b2-%d0%bc%d0%bd%d0%be%d0%b3%d0%be%d0%b7%d0%b0%d0%b4%d0%b0%d1%87%d0%bd%d0%be%d1%81%d1%82%d1%8c" aria-label="Copy link to this section">&lt;svg viewBox="0 0 16 16" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">&lt;path d="M6.5 9.5a3.5 3.5 0 0 0 5 0l2-2a3.5 3.5 0 0 0-5-5l-1 1"/>&lt;path d="M9.5 6.5a3.5 3.5 0 0 0-5 0l-2 2a3.5 3.5 0 0 0 5 5l1-1"/>&lt;/svg>&lt;/a>&lt;/h2>
&lt;p>Каждый продакт-менеджер сталкивается с огромными потоками информации, включая всевозможные инициативы и идеи по развитию продукта, которые ни один человек не в состоянии «переварить» за отведенное время. Стейкхолдеры продавливают свое мнение, пользователи жалуются, календарь трещит от встреч, а Product Backlog растет день ото дня.&lt;/p></description></item><item><title>Мышление письмом</title><link>https://zavarov.com/text/</link><pubDate>Tue, 24 Sep 2024 15:17:01 +0300</pubDate><guid>https://zavarov.com/text/</guid><description>&lt;p>Нашел увлекательное &lt;a href="https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D1%8B%D1%81%D0%BA%D0%B8%D0%BD,_%D0%90%D0%BD%D0%B4%D1%80%D0%B5%D0%B9_%D0%98%D0%B3%D0%BE%D1%80%D0%B5%D0%B2%D0%B8%D1%87" target="_blank" rel="noopener noreferrer">интервью Андрея Стыскины&lt;/a> (директор в Amazon, ex-CEO поискового портала в Яндекс), в котором Андрей рассказывает про некоторые интересные особенности внутренней культуры Amazon, в частности, про «документоцентричный» подход к проведению рабочих встреч и принятию решений.&lt;/p>
&lt;ol>
&lt;li>Любая рабочая встреча — это совместная работа ее участников над проработкой заранее подготовленного документа посвященного определенной проблеме. Часть времени (от 10 до 20 минут) участники встречи самостоятельно изучают документ, в оставшееся время обсуждают и комментируют его. Если после встречи остаются открытые вопросы, то назначается следующая встреча в таком же формате. Процесс продолжается до тех пор, пока требования не будут однозначно сформулированы и согласованы всеми заинтересованными сторонами.&lt;/li>
&lt;li>Проработка требований к любому продукту или фиче происходит методом &lt;a href="https://www.youtube.com/watch?v=4VOgUMqcHhU" target="_blank" rel="noopener noreferrer">«Working Backwards»&lt;/a> через написание двух документов «Press Release» и «FAQ». Руководитель продукта задолго до релиза пишет press release, тем самым формируя видение идеального результата запуска продукта, на которое смогут ориентироваться участники продуктовой команды в процессе работы над продуктом.&lt;/li>
&lt;li>Все решения принимаются только через ревью документов, а не в устной беседе на встрече или в курилке, как это часто происходит в нашей действительности.&lt;/li>
&lt;/ol>
&lt;p>Вспоминая работу в Яндексе (великом, но не таком глобальном, для сравнения — в 2024 г. капитализация Яндекс составляла 10 млрд долл., а Amazon — 2 трлн. долл.), могу сказать, что внутренняя культура компании способствует тому, чтобы сотрудники излагали свои мысли текстом: в Яндексе принято вести подробную документацию в wiki; детально расписывать требования в трекере задач; обсуждать вопросы в комментариях и вести внутренние блоги как открытые, так и анонимные. Чем более весомую позицию занимает сотрудник, тем более убедительно и лаконично работает с текстом, и излагает свои мысли.&lt;/p></description></item><item><title>Про сертификацию Certified Scrum Product Owner</title><link>https://zavarov.com/cspo/</link><pubDate>Sat, 13 Feb 2021 12:00:00 +0300</pubDate><guid>https://zavarov.com/cspo/</guid><description>&lt;p>Марти Каган в своей книге &lt;a href="https://www.amazon.com/EMPOWERED-Ordinary-Extraordinary-Products-Silicon/dp/111969129X" target="_blank" rel="noopener noreferrer">Empowered: Ordinary People, Extraordinary Products&lt;/a> советует начинающим продакт-менеджерам обязательно пройти обучение и получить сертификат CSPO в начале своего профессионального пути. Хочу рассказать, чего можно ожидать от этого обучения / сертификации, кроме еще одной ачивки (к тому же, достаточно не дешевой).&lt;/p>
&lt;p>Тренинг проходит 2 полных дня, в первый день изучаются и отрабатываются в группах основы agile и scrum, очень кратко затрагиваются другие методологии продуктовой разработки. Для тех, кто только вступает в профессию это однозначно полезный день, он даст более глубокое и осознанное понимание scrum. Эти знания полезно использовать как фундамент для оценки и сравнения процессов в своей компании / или в своем продукте.&lt;/p>
&lt;p>Более опытные продакты смогут формализовать и структурировать свои знания и опыт. Большинство из нас работает с командой разработки напрямую, и глоток свежих идей поможет принести в команду творчества и вовлеченности.&lt;/p></description></item></channel></rss>