Дмитрий Сорокин | Дневник_Манагера

#кейсы

Кейс №2. Гарантийная поддержка.

По окончании сложного интеграционного проекта по FixPrice с долгими согласованиями и отладкой со стороны клиента, он попросил исправить оставшиеся проблемы в формате гарантийной бесплатной полугодовой поддержки, ссылаясь на пункт подписанного договора. Для исполнителя проект вышел в ноль, дальнейшее развитие не предполагается. Текущие работы закрыты актом. Заказчик — банк в лице их PM требует заключения соглашения, отказывается возмещать риски, признавать работы выше скоупа, требует в будущем исправлять дефекты. Исполнитель не может позволить себе вписываться в такую кабалу, т.к. это чревато непредвиденным объемом работы за свой счет.
Как стоит поступить PM’у исполнителя в этом случае?

❕Сразу оговорюсь, кейс не мой, но он реальный. Есть решение, какие действия были предприняты. Однако давайте сперва ваши версии обсудим.

#мнение #полезности #моимысли

Когда ты только устроился в компанию, тебя подключили на действующий проект, и нужно быстро разобраться в продукте, который разрабатывается командой. Первым делом стоит идти к QA, потому что, как правило, лучше всех он знает все сильные и слабые стороны и может провести вас по продукту. Это хорошая практика, которая экономит ваше время на самостоятельное изучение. Если QA нет/сам недавно подключился к проекту и еще не ориентируется, как и вы, то ищем того, кто ориентируется. Всегда есть такой человек. Все просто.

#полезности #знания

Вчера ProductCamp опубликовал мою статью “Как стать звездой на рынке ИТ: резюме и LinkedIn, которые покорят работодателя”. Статья будет полезна тем, кто сейчас находится в активном поиске работы на международном рынке и рынке СНГ. А также тем, кто только планирует выход в поле. Запомните, перед "боем" нужна хорошая подготовка. С ней вы будете вооружены и очень опасны. Поэтому рекомендасьон-лосьон к прочтению. 😉

Также, сообщаю, что я точечно и в индивидуальном порядке помогаю “упаковаться” специалистам для поиска. Особенно на менеджерские позиции. Даже если вы С-левел.👑 Конкретные пункты (1-15), в чем я могу помочь можете посмотреть по ссылке здесь.

#мойстатус #моимысли #новости #партнерский_материал

Заметка дневника.
Ни для кого не секрет, что последние 2 года рынок ИТ переживает непростые времена. Поэтому поиск работы становится очень актуальным для кандидатов. На этой почве я уже набил руку, т.к. сам был в поиске, и смело могу сказать, что работает хорошо, а что нет. Особенно для менеджерских позиций. К поиску ведь нужно относиться тоже как к проекту, следовательно, нужно организовать и настроить процесс, подготовить окружение и необходимые инструменты, просчитать риски и т.п. Ко мне даже обращаются некоторые ребята за консультацией. Честно сказать, я испытываю приятные ощущения от помощи. Это здорово! Поэтому если нужна консультация в помощи составления эффективного резюме, упаковке классного Linkedin, который будет привлекать работодателей и к вам будут добавляться интересные контакты, а ваша аналитика повысится минимум в х5 раз, то велкам.

Скоро состоится важное мероприятие для ПМов — ProductCamp. Я уже второй год сотрудничаю с ними. На этот раз я пишу для них статью упаковки резюме и Linkedin-профиля. Тезисно. Ключевые моменты. Надеюсь, моя статья выйдет в прод и будет красоваться на их странице. 🙌🏻

#горькаяправда #мнение #моимысли

Английский или чего никогда не сделает русскоговорящий

Знакомо вам то чувство, когда ты, русскоговорящий, сомневаешься в своем уровне английского? Когда тебе кажется, что вот бы был у меня хотя бы С1 или С4, тогда бы не было проблем вообще? Когда ты всю жизнь собесился в компании с русскоговорящими и они тебе отказывают, говоря, что у тебя недостаточный уровень английского? Конечно знакомо!

Так вот, который раз я убеждаюсь, что русскоговорящие НЕАДЕКВАТНО оценивают твои знания, и так же нетактично ведут себя в этом плане. Сегодня я общался с Product Director в рамках финального интервью одной компании. Она — американка из Флориды. Беседа была в полунеформальном формате.
Я получил от нее непредвзятый, откровенный фидбэк, что у меня отличный английский! Добавила, что это непросто знать чужой язык и так мочь передавать мысли бегло. Было очень приятно такое слышать.

Каждый русскоговорящий, изучая иностранный язык, немного/много принижает свои достижения и навыки, почему-то. Такие уж мы. 🤷🏻‍♂️ Это плохо, кстати. Нужно переучиваться. В таком окружении это непросто, но возможно.

Ключевое:
Русскоговорящий никогда не похвалит тебя за твой английский, а даже сделает замечание и еще будет исправлять — это плохой поинт.
Не слушайте русскоговорящих и(или) шлите их нахер, чтобы не закапывать мотивацию продолжать улучшать язык.
По-возможности, собесьтесь в иностранные компании, чтобы вас оценивали по достоинству и не принижали.
Всем мир! ✌🏻

#новости #горькаяправда

Уверен, многих интересует, почему, все же, лопнул пузырь ИТ и каковы этому причины. 🧐 Лично я интересуюсь этим с прошлого года, общаюсь с разными экспертами, мониторю рынки. И не так давно я наткнулся на интересный пост одного парня, который детально на примере объяснил одну из главных причин. До этой информации, я лишь догадывался, т.к. конкретных аргументов я не находил. А теперь они есть. Так вот, одна из главных причин кризиса в ИТ — это Закон №174. Согласно положению этого Закона компании, которые ранее могли получить налоговые льготы на развитие и исследования (R&D), теперь вынуждены платить значительные средства, даже если они работают в убыток. Это в США. Однако многие европейские государства тоже рассматривают такую практику. Отсюда и в Европе большая конкуренция на рабочие места помимо США.

🔗 Чуть детальнее можно почитать, что писал парень здесь.

​#кейсы #инсайты

Так как предыдущий кейс — мой реальный, то я расскажу, как я поступил и что конкретно сделал.

1. Это Тим Лид (назовем его Петя), а не обычный рядовой тиммэйт.
2. В работе у нас было несколько проектов, на которых он был задействован. Также, были задачи с конкретными сроками, за которые он был ответственен, его команда, за которыми он следил, координировал, ревьюил код и т.д.
3. Человек не удосужился банально уведомить ни меня, ни даже своего члена команды.

Алгоритм действий:
1. Поинтересовался у команды, а затем у СЕО, где он. Никто не знал.
2. Написал ему. Спустя 2-3 ч — тишина. Позвонил — тишина.
3. Обратился к его коллеге (назовем Коля), с которым он сидел рядом и часто общался. Тот тоже не знал, где Петя. Тогда я попросил Колю связаться с Петей.
4. Пошел к СЕО сообщить о случившемся, дабы у нее не было вопросов. Поинтересовался, как часто от Пети случается такое. Узнал, что часто. Это уже 6-7 раз в теч. года. Офигел. Понял причину, почему Петя не выглядел лидером для команды — безответственность. СЕО тоже пыталась связаться с Петей. Облом.
5. Ушел думать, что с ним делать. Параллельно анализировал статус задач, прикидывал, где мы можем просесть из-за отсутствия Пети мин. на день-два.
5. После обеда Петя ответил Коле — он устал и решил(!) взять выходной. Второй раз офигел от его поведения. Мой коллега тоже. Раз уж он ответил только Коле, то попросил Колю узнать у Пети, когда тот вернется — завтра или(!) послезавтра.
6. Злой ушел размышлять, что с этим можно сделать, как поступить, когда Петя вернется — наказать или нет.
7. Петя вернулся через 2 дня. После анализа статуса задач и сроков, решил, что более правильно будет сфокусироваться на проекте, срок сдачи которого был ближе всего => не ломая производительность Пети выговором и давлением.
8. Вызвал его на беседу 1-1. Сперва поинтересовался о его самочувствии и что он сам думает об этом всем. Он согласился, что неправильно поступил. Я же лишь спокойно и тактично призвал его к ответственности, напомнив, что такое поведение некорректно само по себе и что мы все договорились соблюдать правила об уведомлении, если что-то случается. Он согласился и пошел на рабочее место.

Резюме:
Отсутствие члена команды без уведомления спровоцировало конфликт и очередной раз подорвало его репутацию со стороны команды и руководства.
Я выбрал мягкую модель диалога с ним, чтобы остаться друзьями, а не врагами. После диалога Петя не был раздражен или напуган, не был в стрессе — все то, что могло снизить его производительность. Я понимал, что низкая производительность может растянуться на какое-то время и вызвать проблемы со сроками и(или) качеством продукта.
Тем не менее, после долгих размышлений и анализа, к сожалению, я пришел к решнию, что после сдачи важного проекта, на котором он работал, нам с ним придется расстаться. С таким вариантом согласилась и СЕО, т.к. систематическое нарушение корпоративных правил, дисбаланс и разобщенность в команде нам было не нужно. Забегая наперед, после его увольнения, команда стала более оживленной и сплоченной.

#кейсы

Запускаю рубрику кейсов.
Суть проста:
Я публикую ситуационный кейс. Вы в комментариях пишете свое мнение по решению этого кейса. Как правило, в подобных кейсах нет единого правильного ответа. Все основывается только на нескольких факторах, например, таких как: здравый смысл, бизнес-ценности заказчика и(или)компании, сроки проекта, логика и т.п. Все кейсы с позиции менеджера.
Итак, полетели! 🚀


Кейс №1.

Контекст:
Вы — Проектный менеджер в небольшой международной аутсорсинговой ИТ-компании, где нет ни одного русскоговорящего сотрудника, кроме вас. В этой компании вы работает уже 6-й месяц. Команда состоит преимущественно из филиппинцов, иранцев, иракцев, пакистанцев, индийцев. В работе у вас 6 проектов. Команда на все проекты — 30+ чел. Все проекты разной сложности, условиями и заказчиками. Один из проектов — самый серьезный с точки зрения бюджета, сроков, важности заказчика. Дедлайны на нем и некоторых других конкретные и четкие. Вы уже прошли стадию знакомства с командой, наладили контакт так, что команда склонна вам доверять и видит в вас лидера. Работа в офисе. 5 дней в неделю. Все, вроде бы, идет неплохо. Но в один из дней в офис не приходит ваш Тим Лид. Ни вас, никого другого о своем отсутствии заранее он не уведомил. До этого у вас с ним конфликтов и поводов никаких не было. С командой, вроде бы, конфликтов не наблюдалось. Настроение у него было, как всегда обычное. Что вы будете делать в этой ситуации? 🤔

#новости #полезности

OpenAI только несколько часов назад выпустила инструмент Sora, который позволяет генерировать видео по тексту! Теперь можно превращать идеи и скрипты в видеоролики. 🚀🙀

Подробнее на инструмент тут: https://openai.com/sora

#юмор #горькаяправда 😁

​#инсайты #горькаяправда #моимысли

Я думаю многие в курсе, что рынок ИТ до сих пор переживает не лучшие времена... Недавно читал новость, что пошла очередная волна сокращений в мире. Это затрагивает и международный рынок, и страны СНГ, которые работают с зарубежными заказчиками. Чуть лучше себя чувствуют продуктовые компании. Причины разные: экономический кризис, ИИ, перенасыщение инвестиций инвесторов и венчурных фондов в стартапы с 20-21-го годов. Вот, результат.
Самая главная проблема относительно рабочих мест, на мой взгляд — это ИИ, который развивается бешеными темпами. Что разработчики негодуют, что менеджеры или маркетологи. Там, где ИИ может технически или визуально что-то заменить/создать с нуля дешевле рабочей силы, те специалисты в опасности. Возможно, чуть в более выигрышной позиции роли, где нужно управлять человеческими ресурсами и обслуживать сервисы и(или) hardware на базе AI/ML.

Как снизить риски, быть востребованным и не остаться на морозе? Рецепт простой:

1. Следить за новостями рынка и постоянно обучаться новому, актуальному типа ИИ-инструментов, Machine Learning, RPA, Deep Learning, etc., и думать, где это можно применить в своей работе либо присматривать новое место с такими направлениями, т.к. технологии будут развиваться и эволюционировать в этом направлении еще очень долго.
2. Переквалифицироваться со специальности, которая в вашей зоне риска. На мой взгляд, это копирайтеры, маркетологи, таргетологи, визуализаторы и некоторые дизайнеры, тестировщики в какой-то степени и т.д.
3. Брать инициативу в свои руки и создавать новые рабочие места самому. Сейчас рынок не кандидатов, а нанимателей. Конкуренция большая. Любой кризис — это возможности! Просто знайте это. Их только найти нужно. Поэтому это одна из причин, почему я создаю свой продукт с современными технологиями и набираю команду.

Кстати, у меня есть две новости:
1. У нас в проекте появился разработчик, с которым мы будет разрабатывать нашу умную платформу.
2. Освободилось место для PM. В пятницу опубликовал пост об этом в Linkedin. За полдня я получил больше 15 заявок в личку(!). Учитывая, что я не рекрутер/HR, я думаю, это близко к много. В тот момент я в какой-то степени прочувствовал боль рынка в лице кандидатов как наниматель, что даже на пет-проект люди готовы идти, чтобы получить/прокачать/поддержать в тонусе свои навыки. 😢 Однако, я понял, что еще сильнее хочу реализовать свою цель, чтобы помочь людям, дав им крутой и удобный инструмент, который максимально поможет решить их задачи.

А вчера я поделился со своим HRBP/СОО безумной идеей, но очень крутой — решения вопроса урегулирования процесса найма с двух сторон. Рассказывать пока не буду. Все узнаете со временем.
Я очень верю и надеюсь изменить процессы в области найма в ИТ. А может, и не только в ИТ. 😌 Главное, чтобы хватило ресурсов, мотивации, сил и энергии, ну и поддержки людей со стороны. Она очень подбадривает. 🫱🏻‍🫲🏽

#полезности #знания #мнение

Почему Story Points, а не человеко-часы, и как это работает на самом деле? 🤔
Часть 3 (финалка)

❗️Все три части рекомендую читать строго по порядку, а не отдельно одну.

Окей, а с помощью метода критического пути, за какое время этот проект может быть выполнен и объясни, как ты считал.

Метод критического пути — это техника управления проектами, которая используется для определения последовательности задач, которые являются критическими для завершения проекта вовремя. Это называется “критическим путем”. Задачи на этом пути не могут быть отложены без влияния на общий срок выполнения проекта.
Для расчета критического пути нам нужно знать продолжительность каждой задачи и зависимости между задачами. В вашем примере мы не знаем точную продолжительность каждой задачи, но мы можем использовать Story Points как приближенную оценку.

Допустим, что каждый Story Point соответствует одному дню работы. Тогда продолжительность каждой задачи будет следующей:
1. Дизайн пользовательского интерфейса: 13 дней
2. Разработка базы данных: 8 дней
3. Разработка API: 5 дней
4. Тестирование и отладка: 20 дней

Теперь давайте предположим, что задачи должны выполняться в следующем порядке:
1. Дизайн пользовательского интерфейса
2. Разработка базы данных
3. Разработка API
4. Тестирование и отладка

Тогда критический путь будет включать все эти задачи, и общее время выполнения проекта будет равно сумме времени выполнения всех задач на критическом пути, то есть 13 + 8 + 5 + 20 = 46 дней.

А как бы выглядела диаграмма критического пути для этого проекта?

Представьте себе таблицу с четырьмя строками, по одной на каждую задачу (A, B, C и D). В каждой строке есть два столбца: один для раннего старта и финиша, и другой для позднего старта и финиша.
• Задача A (Дизайн пользовательского интерфейса) начинается в день 0. Она длится 13 дней, поэтому ранний и поздний финиш — это день 13.
• Задача B (Разработка базы данных) начинается сразу после завершения задачи A, то есть в день 14. Она длится 8 дней, поэтому ранний и поздний финиш — это день 22.
• Задача C (Разработка API) начинается сразу после завершения задачи B, то есть в день 23. Она длится 5 дней, поэтому ранний и поздний финиш — это день 28.
• Задача D (Тестирование и отладка) начинается сразу после завершения задачи C, то есть в день 29. Она длится 20 дней, поэтому ранний и поздний финиш — это день 49.
Критический путь — это последовательность всех этих задач, потому что они должны выполняться одна за другой, и ни одна из них не может быть отложена без влияния на общий срок выполнения проекта.

🔗Как выглядела бы схема этого примера можно посмотреть ЗДЕСЬ.

#полезности #знания #мнение

Почему Story Points, а не человеко-часы, и как это работает на самом деле? 🤔
Часть 2

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

Приведу приближенный к реальной ситуации пример:

Допустим, у вас есть новый проект по разработке мобильного приложения. Вы с командой провели сессию планирования и определили следующие основные задачи:
1️⃣ Дизайн пользовательского интерфейса
2️⃣ Разработка базы данных
3️⃣ Разработка API
4️⃣ Тестирование и отладка

Вы оценили каждую задачу в Story Points следующим образом:
1️⃣ Дизайн пользовательского интерфейса: 13 Story Points
2️⃣ Разработка базы данных: 8 Story Points
3️⃣ Разработка API: 5 Story Points
4️⃣ Тестирование и отладка: 20 Story Points

Общий объем работы составляет 46 Story Points.

Теперь, допустим, вы предполагаете, что ваша команда может выполнить около 10 Story Points за двухнедельную итерацию (это ваша начальная скорость). Используя эту оценку, вы можете предсказать, что проект будет завершен примерно за 5 итераций, или 10 недель.
Это, конечно, приближенная оценка, и реальные сроки могут отличаться. Однако, это дает вам и вашему заказчику общее представление о том, сколько времени может занять проект, и позволяет вам начать планирование.
После первой итерации у вас будет реальные данные о скорости команды, которые вы сможете использовать для корректировки вашего прогноза. Это одно из преимуществ использования Story Points и Agile методологии — они позволяют вам адаптироваться к изменениям и уточнять ваши прогнозы по мере продвижения проекта.

Окей, а как понять, сколько это будет в реальных единицах времени?

Для расчета времени выполнения проекта нам нужно знать скорость команды (velocity), то есть сколько Story Points команда обычно выполняет за итерацию. Допустим, скорость команды составляет 10 Story Points за двухнедельную итерацию (это пример, и реальная скорость команды может отличаться).
Тогда, если общий объем работы составляет 46 Story Points, мы можем вычислить количество итераций, разделив общий объем работы на скорость команды:

🔖 Количество итераций = Общий объем работы/Скорость команды = 46 SP/10 SP в итерацию = 4.6 итераций

Поскольку каждая итерация длится две недели, общее время выполнения проекта составит:
🔖 Время выполнения проекта = Количество итераций Х Длительность итерации = 4.6 Х 2 недели/итерацию = 9.2 недели

Итого: примерно 9 недель и 1 день. Учтите, что это приближенное значение, и на самом деле время выполнения проекта может варьироваться в зависимости от многих факторов, таких как, например, стабильность интернет-соединения и др; технические проблемы, человеческий фактор, экономический, политическикй, прочие риски.

Если в команде вы используете относительную оценку задач, то какие цифры окончания работ мне как ПМу нужно озвучить заказчикам и стейкхолдерам?

Я бы использовал данные о скорости команды (velocity), чтобы преобразовать Story Points в конкретные сроки для заказчиков и стейкхолдеров.
Например, если команда обычно выполняет 10 Story Points за двухнедельную итерацию, и у нас есть проект, оцененный в 50 Story Points, я бы сообщил заказчикам, что проект, вероятно, будет завершен примерно через 5 итераций, или 10 недель.
Это, конечно, приближенная оценка, и реальные сроки могут отличаться. Однако, это дает заказчикам и стейкхолдерам общее представление о том, сколько времени может занять проект, и позволяет им начать планирование.
Важно помнить, что все оценки являются прогнозами и могут быть неточными. Главное — это не точность, а то, как мы используем эти оценки для управления проектом и обеспечения его успешного выполнения.

#полезности #знания #мнение

Почему Story Points, а не человеко-часы, и как это работает на самом деле? 🤔
Часть 1

Почему это может быть более эффективным подходом:
1️⃣ Абстракция: Story Points оценивают сложность задачи, а не просто время, необходимое для ее выполнения. Это учитывает неопределенность и риск, что делает оценку более реалистичной.
2️⃣ Гибкость: Оценка в часах предполагает, что все члены команды работают с одинаковой скоростью, что редко бывает верно. Story Points учитывают различия в производительности и опыте членов команды.
3️⃣ Фокус на ценности: Использование Story Points помогает команде сосредоточиться на доставке ценности, а не просто на выполнении задач. Это способствует более продуктивной и сотрудничеству ориентированной культуре.
4️⃣ Меньше давления: Оценка в часах может создать давление на команду, чтобы они работали быстрее, что может привести к снижению качества. Story Points позволяют команде работать в более расслабленном темпе, сохраняя при этом высокую производительность.

❗️Однако, важно понимать, что Story Points и оценка в часах не взаимоисключающие. Они могут работать вместе для достижения большей точности.

Story Points — это мера, которая используется в Agile и Scrum для оценки сложности задачи. Они не имеют абсолютного значения и служат для сравнения относительной сложности различных задач в рамках одного проекта.
1 Story Point обычно определяется как наименьшая единица работы, которую команда может выполнить. Это может быть, например, простая задача, которую можно выполнить за короткое время без значительных усилий.

Определение значения Story Point может быть сложным, и это часто требует обсуждения в команде. Вот некоторые стратегии, которые могут помочь:
1️⃣ Сравнение задач: Команда выбирает две задачи и обсуждает, какая из них сложнее. Затем они присваивают этой задаче больше Story Points.
2️⃣ Метод покер-планирование: Каждый член команды оценивает задачу в Story Points независимо. Затем команда обсуждает свои оценки и приходит к соглашению.
3️⃣ Использование шкалы Фибоначчи: Задачи оцениваются по шкале Фибоначчи (1, 2, 3, 5, 8, 13, и т.д.), что отражает неопределенность и риск, связанные с более сложными задачами.

⚠️ Важно помнить, что Story Points — это инструмент для команды, а не для сторонних стейкхолдеров. Они помогают команде лучше понять свою работу и улучшить свое планирование и прогнозирование.

Story Points дают нам общее представление о сложности задачи, а затем мы можем использовать исторические данные о скорости работы команды (сколько Story Points команда обычно завершает за итерацию) для преобразования этих Story Points в конкретные сроки. Это называется скоростью команды (velocity).
Например, если ваша команда обычно завершает 20 Story Points за двухнедельную итерацию, и у вас есть задача, оцененная в 5 Story Points, вы можете ожидать, что эта задача будет завершена примерно за треть этого времени, то есть примерно за 5 дней.
Этот подход учитывает многие факторы, которые трудно учесть при оценке в часах, такие как прерывания, затраты времени на согласование и общение, технические трудности и так далее. Это делает его более гибким и адаптивным, что особенно важно в быстро меняющемся мире IT.

А если это новый проект и нет никаких исторических данных о производительности команды?

В новом проекте, когда у нас еще нет исторических данных о скорости команды, оценка может быть более сложной. Однако, даже в этом случае, Story Points могут быть полезными.
Во-первых, мы можем начать с оценки задач в Story Points, чтобы получить представление о сложности каждой задачи относительно других. Затем мы можем использовать опыт и знания команды, чтобы сделать образованную догадку о том, сколько Story Points команда может завершить за итерацию. Это будет нашей начальной скоростью (velocity).
Во-вторых, после первой итерации у нас будут реальные данные о скорости команды, которые мы можем использовать для более точного прогнозирования в будущем. С течением времени, по мере того как команда продолжает работать над проектом, наши прогнозы станут все более точными.

​#полезности #знания

Какие технические вопросы могут задавать PMам на тех. интервью?

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

🔗 ТЕХ. ВОПРОСЫ

#партнерский_материал #полезности #знания

Прошел курс венчурного аналитика и успешно защитил с командой кейс.🏆

И вот мой честный фидбэк по нему:
Автор курса — Денис Калышкин — работает в венчурном фонде с 2014, сейчас — главный аналитик в IB2F Global Ventures. Эксперт в доменах AI, IoT, AR/VR, Robotics/Drones, SaaS, RPA & Automation. Инвестирует в стартапы в основном, которые делают бизнес в Америке на сериях Angel/Seed и Series Z. По образованию — Rocket Scientist (Московский физико-технический институт). Имеет степень магистра финансов (Высшая школа экономики).

1️⃣ Если вы новичок в венчурной и стартапной областях, то курс точно будет вам полезен, как минимум для расширения кругозора, а как максимум — для запуска стартапа или старта карьеры венчурным аналитиком.
2️⃣ Он абсолютно беспалтный и доступен каждому. Это объясняется тем, что Денис создает базу знаний для потенциальных стажеров и аналитиков. Иногда с потоков курса он берет себе ребят в команду на стажировку. Или кто-то идет в другой фонд, или же запустит свой стартап. Да и просто он любит обучать людей.
3️⃣ Денис подробно рассказывает про азы и всю “кухню”: что такое венучрный фонд, стартап и как они работают, критерии анализа стартапов, инвест меморандумы, ошибки, due diligence и многое другое.
4️⃣ Есть еженедельные аудио-сессии с вопросами Денису по темаем курса, на которые он с удовольствием отвечает.
5️⃣ Ты попадаешь в комьюнити единомышленников, нетворкаешь и обрастаешь полезными связями, которые точно лишними не будут.
6️⃣ Ты можешь создать свою команду и быть капитаном в ней, как сделал я, либо влиться в чью-то, в которой ты с ребятами выполняете задания и готовитесь вместе к защите будущего кейса перед постановочной комиссией и зрителями. Все материалы для подготовки будут.
7️⃣ Если ты Продакт, планируешь свитчиться на эту роль или просто интересуешься, то эти знания точно будут хорошим подспорьем, потому что, как мы знаем, хороший Продакт — совего рода, предприниматель, который должен ориентироваться в продукте, его нюансах, рынке, улучшении показателей, слабых зонах и т.д.

Как попасть на курс?
🏁 Ближайший поток (12-й) стартует 19 января 2024.
📌 Регистрацию на курс проходить не нужно. Достаточно лишь подписаться на Телеграм-канал и ждать запуска курса.

#полезности #инсайты #знания #мнение

❓Проектный менеджер это о результатах или процессах? Или может о процессах ради результата?

Где-то видел под одним постом такой комментарий: “Как PMу перевести достижения в цифры? Это же работа про процессы, а не про результаты 🤔 никак не могу понять, в примерах гугла только "делал, вёл, поддерживал.”

PM — это о результатах, которые он получил, настраивая определенные процессы. Одно без другого не имеет смысла. Если вы настроите процессы, но они не принесут результаты, то значит в процессах не было смысла.

🤫Забирайте список достижений в цифрах для своего крутого резюме:

• Увеличил производительность команды на Х%
• Увеличил размер команды на Х человек
• Вел в параллели Х проектов
• Закрыл в срок успешно Х проектов
• Увеличил прибыль компании на Х%
• Уменьшил средний цикл разработки фичи на Х% или часов
• Управление проектом стоимостью в Х$
• Снизил в Х раз среднюю стоимость фичи
• Средняя частота релизов выросла с Х до 2Х в месяц
• Управление несколькими командами, до Х человек одновременно
• Сэкономил Х% временных затрат ежеквартально
• Сократил сумму потерь на Х%

#мойстатус #новости

На данный момент я заканчиваю курс венчурного аналитика. Осталось только с командой защитить кейс продукта Shopify.
Причем здесь венчурный аналитик спросите вы? А притом, что на этом курсе подсвечиваются не только сторона венчурного аналитика, но и вся кухня венчурных фондов и инвестиций, акселераторов, бизнес-ангельской деятельности, а также стартапов. Очень круто понимать и знать весь жизненный цикл стартапа и все нюансы перед тем, как просить инвестиции у инвесторов.

Как только пройдет моя защита, я поделюсь этим курсом здесь. Кстати, он совершенно бесплатный! Это большая редкость получить такие знания совершенно задаром.