1
Karma
0
Global rating
Alina M @alina_pro_it
User
Information
- Rating
- Does not participate
- Location
- Buenos Aires, Аргентина
- Registered
- Activity
Specialization
Project Director, Product Manager
Lead
Project management
Building a team
Development of tech specifications
Optimization of business processes
Negotiation
People management
Organization of business processes
Strategic planning
Business process management
Company management
Ахаахах)
Я не очень люблю нетворкинг, который маскируется под дружбу с шашлыками и баней. Не люблю дружбу с выгодой.
Но было бы интересно послушать, как это работает?
А можно подробнее про Хабр? Расскажите, пожалуйста, как Хабр помогает искать работу?
Хабр-карьера меня не впечатлила.
Я глянула одним глазком, но если честно, не нашла ничего подходящего.
А вы там находили, да?
Спасибо за комментарий ☺️
Про телеграм скажу, конечно:
Во-первых, надо разделить мух от котлет: есть связь в телеграме с рекрутерами, а есть именно поиск вакансий.
Для обоих кейсов характерно следюущее: платная учётка не имеет никакого значения (у меня для общения с рекрутерами специально выделена отдельная, не Premium учётка телеграм).
Поиск вакансий в телеграм
1. Это не прямо очень эфективно и используя я их только для того, чтобы там выхватить те самые прямые контакты рекрутера.
2. Однако у меня есть набор телеграм-каналов по моей тематике: продуктовые вакансии, C-Level-вакансии, вакансии из индустрии. В этих каналах почти всё для рынка РФ, но иногда находится то, что интересно мне. И из них опять же я иду писать в личку рекрутерам.
И наконец связь с рекрутерами в телеге
1. Это самое приятное для чего в терминах поиска может пригодиться телега.
2. Я сразу делаю папочки с разными рекрутерами по статусу их ответа на мои сообщения, там можно и созвониться при большом желании, и отправить резюме и всё очень приятно, знакомо и понятно.
Отличный кейс, спасибо что поделились!
Знаете, это прекрасная иллюстрация того, что рынок неоднороден. У меня в итоге есть офферы, но важно, что только через прямые контакты — 3 оффера на senior+ позиции, некоторые из которых создали специально для меня.
Ваши 30-50% ответов — это фантастический показатель! Возможно, разница в том, что я искала позиции уровня Senior/Lead Product Manager вне РФ с соответствующей компенсацией (верхний квартиль рынка). А какие у вас были требования к вакансии?
Согласна насчёт ответственного подхода. Именно поэтому я задокументировала весь процесс: записала все отклики, анализировала конверсий по странам/ платформам/ позициям/ индустриям, тестировала разные подходов к компенсационным ожиданиям.
Кстати, для российского рынка и middle-позиций hh действительно может работать лучше. Мой фокус был на глобальных компаниях — там другие каналы поиска эффективнее.
Да, надо про это написать, конечно, подробнее.
Да, 7 лет hh отработал прекрасно. Сейчас всё очень плохо как-то)
А здесь у нас смешались цели, которые не противоречат друг другу, а существуют в параллельных вселенных.
Цель статьи и подходов, описанных в ней, — показать, какие существуют методы оценки задач в зависимости от того, насколько точными они должны быть. То есть эти подходы описывают то, что происходит до очередной итерации разработки, и то, что нужно получить после неё. Подходы к оценке совершенно не зависят от того, как мы будем решать проблему с коллегой, который не уложился в оценку. Это тема другой большой статьи.
Способ оценки не связан с тем, в каких величинах команда будет логировать время. Мы всегда логируем время в часах, несмотря на то, что в какой-то момент было необходимо использовать Hard+ mode для оценки.
Какой бы подход к оценке вы ни выбрали, это не избавит от проблем плохого менеджмента внутри спринта.
Помогать коллеге, которому нужна поддержка, важно и необходимо при любом подходе к оценке, описанном в этой статье.
Очень важно понимать, что ввод условных единиц, описанных в статье, имеет смысл, когда нужна очень точная оценка. (Например, с датой релиза никак нельзя ошибиться!) В случаях, когда происходит трансформаций чего угодно во что угодно — это прекрасный метод оценки и прогноза, только он не имеет ничего общего с методом оценки Hard или Hard+.
Если мы занимаемся любым упрощениями, которые также описаны в статье, то ввод условных единиц не имеет никакого смысла и гораздо проще прикинуть, что «я для себя оценил задачу в 8 часов, то Володя будет делать её 12, а Петя 16».
Я ни в коем случае не вкладывала в слово «угадывание» уничижительного смысла. Я сама угадывала и продолжаю угадывать там, где это уместно.
Всей этой статьёй я хотела рассказать, что важно найти тот способ оценки, который соответствует целям и возможностям команды в данный момент. Угадывание здесь используется только как противопоставление расчёту.
Я считаю, что угадывание — это процесс, основанный на субъективных данных говорящего, а расчёт — это то, что основано на данных и формулах, которыми эти данные связаны.
Поэтому я совершенно не могу согласиться с тезисом, что «планирование = прогноз = угадывание».
Докажем от обратного: в случае
итерации, когда уже существуют условные единицы для расчёта (например, объём работы S) и скорость (V), для расчёта времени (T) ничего, кроме голой математики, не требуется. Это противоречит понятию угадывания.
И подчеркну: я ничего против угадывания не имею. В своей бирюзовой компании я никогда не буду тратить время на справедливую оценку объёма и честный расчёт скорости.
Напомню формулу
, о которой идёт речь.
Позволю себе не согласиться. Со временем величина S будет становиться всё точнее и точнее. Команда или лид начнут понимать сложность такого типа задач. Именно сложность. Не скорость выполнения, потому что она(скорость), как вы верно заметили, у всех разная.
Ещё раз напомню, что S — это не часы, не минуты и даже не недели. S — это не время. Это объем или сложность задач.
Во-первых, это не часы — это условные единицы. Это крайне важно. В часах выражается время, а не объем.
Да, вы правы, что это относительная мера не внутри спринта, а всё же относительная мера внутри команды.
Тут стоит сделать мне важное замечание — спасибо, что указали на это.
Идеально, чтобы с течением времени оценка в условных единицах примерно одинаковых по сложности задач стремились к постоянной величине.
Поэтому я рекомендую оценивать максимально декомпозированную = понятную задачу.
Надеюсь, что важное замечание из параграфа выше закрыло этот вопрос.
Или всё же нет?
Привет, спасибо за вопрос — это тянет прямо на отдельную статью или, как минимум, на пост.
Сначала короткий ответ: если вы хотите получить расчётное = точное время выполнения ваших задач, то необходимо взять формулу простейшей математики и посчитать
, а для формулы нам необходимы объем (S) и скорость (V). Без использования формулы, ваше время будет угадыванием, а не расчётом.
А теперь длинный ответ.
Давайте снова немного теории:
Сторипоинты/ майки и другие прекрасные «величны», которые я измеряю в условных единицах (у.е) — это нично иное, как попытка сравнить задачи между собой. Это не абсолютные значения, а скорее относительные.
Эти самые сторипоинты/ майки — это относительная мера объёма — S — Scope. И они нам нужны, чтобы мы оценили объем (или можно сказать, сложность задач), есть ответили на вопрос — как много всего нам надо сделать?
Часы/ дни/ недели — это, в общем случае, мера времени — T — Time. Время нам нужно, что мы сначала оценили, а потом и высчитали — как долго мы будем всё это делать.
Благодаря оценке хочется получить время — T, потому что информативно — выражается в потятных часах/днях/неделях. Но без знания скорости команды и объёма задач из бэклога, время не высчитывается, а просто угадывается.
Потому очень важный вывод звучит так: для получения именно расчётного, а не угаданное время
(в часах/ днях/ неделях), вам нужно:
Оценить объём
: зачем оценивать? Вкаждой новой итерации у вас разный объем задач — очевидно, а что не очевидно — с каждой итерацией вы все лучше управляетесь с расставлением условных един для своих задач, сравнивая из друг с другом.
Взять скорость
вашей команды из предыдущей итерации. Именно для того, чтобы эту скорость откуда-то взять первые несколько итераций у нас проходит по эгидой — «прикидываем».
Посчитать (а не угадывать) время выполнения ваших задач по формуле
.
Ответила на вопрос @gun_dose?
Договор 🤝
Спасибо, что дополняете - да, красота и простота не были в списке целей этой статьи, потому подумаю, как писать реалистичнее.
Комментарий - это не всегда противоречие, к счастью.
Однако комментарий, начинающийся со слов "Это не считая того...", по риторике выглядит, как оппозиция.
А если это было просто дополнение, то спасибо - всегда приятно, когда дополняете.
А почему статья "розовая"?
Разночтения возможны и компании сами иногда не понимают кто им нужен: проджект, продакт или маркетолог. И в итоге продакт становится маркетологом, проджект - продактом, а маркетолога вообще не нанимаем "потому что дорого".
Канонически (скажем, по учебнику): проджект отвечает на вопрос - Как? и Когда? сделается проект, а продакт - Что? и Зачем? мы делаем в продукте.
Но как я и сказала, компании чаще из-за экономии, но не редко из-за незнания роли и смешивают.
Я описывала канонического продакта, но всегда открыта к обсуждению того, кого компании считают таковыми)
Судя по тому, сколько ваших комментов под каждой моей публикацией, я бы поспорила кто из нас спамер, товарищ!
Я ждала вашего вопроса и спасибо вам за него!
Давайте обсудим - расскажи, пожалуйста, почему ты думаешь, что это чек-лист проджекта?
Не очень поняла почему малой ценности? Расскажи подробнее, пожалуйста.
Я не думала про "типичных менеджеров любого отдела", если честно - писала о том, что делала, делаю и, вероятнее всего, продолжу делать сама.
Тренируем образное мышление :)
Покажите старые, видимо неаккуратно искала :)