Проджект маминой подруги!

От души 🤝

🔥Более подробная инструкция для скиллсета из предыдущего поста на VC: https://vc.ru/hr/1272240-skillset-prodzhekta-maminoi-podrugi-besplatno-dlya-vseh Кто может – поддержите лайком! 🦸‍♂️ @moms_pm

🙌🙌🙌🙌 Скиллсет проджекта маминой подруги бесплатно для всех! Теперь каждый сможет оценить себя по 170 soft skills и hard skills, чтобы понять +- свой грейд и куда развиваться. 🟢Как сделать копию себе? 1. Авторизируйтесь в Google 2. Жмите "Файл", затем "Создать копию" 4. Ищите скиллсет на своём Google диске 5. Открывайте и пользуйтесь 🟡Как работает скиллсет? Копируете скиллсет, во вкладке «Skills» в столбце «С» оцениваете себя по всем скиллам относительно желаемой позиции или как есть сейчас. ➕Слева ввеху есть плюсик с подсказками и справа есть описание оценок. - Positiion map: сравнение вашей оценки со всеми грейдами - Spider chart: графики для визуалов - Grades: сетка грейдов (моя, но вы сможете отредактировать) Скиллсет поможет увидеть текущие навыки и что надо прокачать в первую очередь. Грейды в каждой компании разные, поэтому отталкивайтесь от реалий, анализируйте и делайте осознанные выводы из скиллсета для своего развития. 🟥 Скачать скиллсет: [Template_Download PM Skillset by Semyon Kolosov] 🔜 Если нашли ошибку, опечатку или есть вопросы – пишите, пожалуйста, в комментариях. 🦸‍♂️ @moms_pm

🎤Создайте и отрепетируйте свой питч для собесов и не только Это крайне важно и 90% проджектов (да и все) делают это плохо. С чего начинается любой собес? Просят – расскажите о своём опыте! А самые крутые справшивают – как вы сейчас себя позиционируете? 🪑И дальше 2 стула: 1. Кто-то тараторит всё подряд долго/нудно/быстро/неструктурно 2. Кто-то говорит коротко, но не по делу или несвязно Во всех случаях слушающий теряет нить повествования, напрягается, скучает и что происходит? Правильно! В первую же минуту вы портите впечатление о себе. Слушающий делает вывод, что человек неструктурный, непоследовательный и не может выражать свои мысли. Для проджекта это фиаско! Дальше что хотите рассказывайте, вас будут слушать через эту призму. ❗️ Важно! На открытых собесах в ютубчике все эти речи слушают, но там образоватльные цели. В жизни вы сделаете длинными речами только плохо себе. Что делать? Сядьте, выпишите свой опыт работы или возьмите резюме. Потом сами или через GPT сформулируйте короткий питч про себя. Чтобы было понятно: Я позиционирую себя, как [грейд][проджект]. Опыт работы в [cферах] N лет. В основном делал проекты [типа][масштаба] N, ключевыми результатами считаю [1,2,3]. Сейчас ищу [компанию][вызов] N. Как бы сказал Олег: «Это сделать не просто сложно, это 3,14здец, как сложно». Но драфт за драфтом сокращайте свой питч и отрепетируйте его много раз перед зеркалом, чтобы создавать крутое первое впечатление о себе. ➡️Ещё полезности на эту тему: - Беречь чужое время = быть круче в глазах других! - Основы решения задач и коммуникации Кто уже читал мою книгу, наверняка, заметили, что все отмечают структурность кандидата на собесе. Удачи вам на собесах! Всё получится! 🦸‍♂️ @moms_pm

Про меня написали в книге 😎 Открываю книгу по проджект-менеджменту, а там… До меня наконец-то доехал авторский экземпляр книги Семёна Колосова @simon_said, для которой я дал небольшое интервью) Для меня это первое сознательное появление в книге по теме продуктов / проектов! Видео, подкасты, статьи — это все было. А вот книги — это что-то новенькое) Спасибо Семену за идею! Ждите во всех книжных магазинах страны 😎 А я возьмусь за чтение — как раз приболел и пришлось активный отдых поменять на пассивный Что думаете насчет мыслей из моего интервью? Откликается?

🦖 Системы баг-трекинга (Часть 3),(Часть 2), (Часть 1) 1️⃣Пишите баги понятно: какое окружение, при каком сценарии сломались, на каком устройстве (если актуально), ссылки на логи, request/response, ссылка на требование. Одним словом, максимально понятно и так, чтобы можно было воспроизвести без дополнительных 100500 вопросов. К слову, пиши понятно относится и к постановке задач ко всей команде. 2️⃣В багах должен быть лог работы над ним. Не просто статусы по воркфлоу, а QA должен писать и разработчик те проблемы, которые, к примеру, не дают починить баг быстро. Например, уточняем требования, выяснили, что есть вот такая то проблема и так далее. Баг, даже и хорошо оформленный, которые висит в статусе «in progress» неделю, плохой баг : ) 3️⃣Все баги должны заноситься в BTS. Даже небольшие, да, их можно так сильно не расписывать, но лог ошибок вестись должен всегда. 4️⃣Если внутри команды есть автоматизация, задачи по автоматизации также должны вестись в BTS и их всегда нужно учитывать и закладывать на них время. ❗️Заключительный пост всё также от Леси Якобовой 🫡 🦸‍♂️ @moms_pm

Отправка книг началась! Вы знаете, что мои конкуренты и завистники взломали СДЭК.😂 . Из-за этого на месяц опоздал мой заряженный на успех первый тираж. Многие уже купили книги сами, а я начинаю рассылку всем, кто написал в комментах под первым постом про книгу. Всем напишу и договоримся о доставке. Спасибо, что первыми поддержали тогда своими комментариями - пишите мне в любое время, задавайте вопросы, если будут. Также буду отправлять/лично передавать всем, кто участвовал в интервью. Сначала местным, потом буду думать про Польшу, Черногорию, Стамбул, Францию, Дубай, Ереван, Германию, Барселону. Всем огромное спасибо за поддержку и помощь! Вы топ 🚀 🦸‍♂️ @moms_pm

🥷 Виды тестирования (Часть 2), (Часть 1) Тут всё очень сильно зависит от проекта, сроков и требований. Упороться по видам тестирования можно всегда, но это база: 1️⃣Функциональное тестирование мастхев любого проекта. Без него ничего не будет. Проверяет, что функционал работает так, как задмуывался. 2️⃣ Тестирование безопасности. Очень специфический вид тестирования и обычный QA этим не занимается, НО всегда нужно обращаться внимание на вопрос безопасности, особенно, если есть данные, которые мы не хотим, чтобы утекли. Всегда нужно знать, кто внутри компании занимается этим видом тестирования. 3️⃣Тестирование интеграций. Все просто, когда наш сервис взаимодействует с другим или другими. Является зачастую частью функционального тестирования или как отдельный вид, в случае, если мы тестируем только бек. Всегда нужно знать, есть ли у нас интеграции и задавать вопрос QA: «А как мы, собственно, будем тестировать это?». 4️⃣Нагрузочное тестирование. Нужно всегда, если ваше приложение высоконагруженное или вы ситуативно ожидаете большую нагрузку на ваш микросервис. Обычно таким видом тестирования промышляют отдельные QA. 5️⃣База: smoke тестирование или тестирование базового сценария, чтобы убедиться, что оно работает. К слову, чтобы бы круто, если бы его проводили разработчики, а потом уже отдавали QA на более глубокое тестирование. 6️⃣База: sanity тестирование или когда ты берешь одну функцию и тестируешь ее и в хвост и в гриву. Например, у нас был рефакторинг и мы очень опасаемся, что сломалась система оплаты. В этом случае, мы выделяем время и сначала делаем регрессионное тестирование, а потом врубаем sanity на полную и гоняем самые приоритетные или самые задетые рефакторингом части. 7️⃣База: регресионное тестирование. Без него ни жизни нет, ни смысла. Прежде чем выпускать наше творение в прод нужно провести регресс. Он проверить все изменения, которые были внесены и проверит, что мы по дороге ничего не сломали в старом функционале. ❗️Пост всё также от Леси Якобовой 🫡 🦸‍♂️ @moms_pm

🥷 Понимание процессов QA для проджекта (Часть 1) В моей книге есть интервью с Лесей Якубовой. Подписка тут даже не обсуждается ❗️ Я обновляю скиллсет по книге и спросил Лесю о том, что базово должен знать проджект про QA, чтобы жить и не тужить. Что получилось ниже. 🔴Понимание процессов QA: 1️⃣Привлекать QA в работе над фичей нужно уже на этапе требований. 2️⃣У QA должна быть возможность задать все доп.вопросы по новой задаче автору требования или его представителю. А если задача уже в работе, то нужно убедиться, что есть хорошая связка между разработчиком и QA. Связка – когда они в контакте друг с другом и активно взаимодействуют по задаче. 3️⃣Понимать, что для тестирования нужно время и закладывать время в проекте нужно не по остаточному принципу, а с учетом рисков возникновения багов. 3️⃣🔤1️⃣Если внутри команды есть автоматизация тестирования, то нужно не забывать ее включать во временные рамки реализации задачи. 4️⃣Документация на проекте должна быть и на неё тоже нужно время (причём в случае, если QA её пишут, то нужно им давать время, чтобы не копился тех долг, если пишет проджект или продакт, то нужно убедиться, что она должна быть и должна быть максимально актуальной). 5️⃣Любой процесс тестирования должен сопровождаться артефактом: чек-лист, тест-кейс, тест-план (если это уместно или нужно заказчику), результаты тестирования. Имхо, нет артефакта и пруфов, значит не было тестирования. 6️⃣Внутри команды должно быть правило, не отдавать на тестирование задачу, если разработчик на базовом уровне сам её не проверил. Новая сборка, которая крашится на старте – плохой паттерн. QA расстраивается от такого. ❗️В след постах будет про виды тестирования и системы баг-трекинга 🦸‍♂️ @moms_pm

💡Основы решения задач и коммуникации Очень хорошая обзорная лекция старшего партнёра McKinsey Владимира Чернявского про подходы решения задач и коммуникации 🟥Смотреть: тут (а лучше скачать, так как ссылка не моя) Особенно, часть про коммуникацию. Если вы начинающий проджект или проджект, который так не делает, как говорится в лекции, то обязательно берите на заметку – вы станете круче! Такие подходы и мышление выделят вас! PS: ссори за качество скрина, лучше никак 👽 @simon_said