Ага

Привет, Ксюша :) ПМ вообще как-то не аджайловый термин. Это из такого ванильного менеджемента. Но протоптанный путь это: тестировщик - аналитик - владелец продукта. То есть можно начать карьеру хоть с ручного тестировщика, изучить продукт, понять как работает компания и вырасти.

Привет, Ксюша :) ПМ вообще как-то не аджайловый термин. Это из такого ванильного менеджемента. Но протоптанный путь это: тестировщик - аналитик - владелец продукта. То есть можно начать карьеру хоть с ручного тестировщика, изучить продукт, понять как работает компания и вырасти.

Тут вот дискуссия идет о роли PM'а в Agile и куда ему неприкаянному быть и мол SCRUM мастер он хреновый будет. Роль SCRUM мастера разработчики любят оставлять себе. Вот только хороший SCRUM мастер - это драйвер для бизнеса, а не драйвер процессов. Я видел разработчиков, который мастерили команды - они просто следовали практикам без понимания зачем это придумано, у них нет навыков управления развитием команды в части увеличения ROI. У PM'а есть и это его основная задача. Я не говорю про PM'а, который только и умеет что колбаски в диаграмме Ганта рисовать, записывать и передевать требования. SCRUM-мастер - это реальный очень сильный руководитель, которому надо добиваться от dev team и от PO (!) достижения результата без применения директивных подходов в управлении. И да, не каждый PM на это способен, но если говорить не о человеке, а о роли, то PM'у все же ближе роль SCRUM-майстера.

Где в манифесте или в принципах есть утверждение что PM не может быть в Agile? Может в названиях не всегда присутствует. Но при масштабировании все более ярко эта роль выражается. В DSDM вообще она так и называется - менеджер проекта.

Тут вот дискуссия идет о роли PM'а в Agile и куда ему неприкаянному быть и мол SCRUM мастер он хреновый будет. Роль SCRUM мастера разработчики любят оставлять себе. Вот только хороший SCRUM мастер - это драйвер для бизнеса, а не драйвер процессов. Я видел разработчиков, который мастерили команды - они просто следовали практикам без понимания зачем это придумано, у них нет навыков управления развитием команды в части увеличения ROI. У PM'а есть и это его основная задача. Я не говорю про PM'а, который только и умеет что колбаски в диаграмме Ганта рисовать, записывать и передевать требования. SCRUM-мастер - это реальный очень сильный руководитель, которому надо добиваться от dev team и от PO (!) достижения результата без применения директивных подходов в управлении. И да, не каждый PM на это способен, но если говорить не о человеке, а о роли, то PM'у все же ближе роль SCRUM-майстера.

Где в манифесте или в принципах есть утверждение что PM не может быть в Agile? Может в названиях не всегда присутствует. Но при масштабировании все более ярко эта роль выражается. В DSDM вообще она так и называется - менеджер проекта.

Привет,меня зовут Ксюша. Сейчас учусь ещё /программная инженерия/ прохожу курсы middlePM / есть своя команда в одной молодежной организации (Team Leader в команде) Так вот,вопрос, как лучше "войти в IT" Возможно советы с чего начать как РМ, мне все это нравится, но как зацепиться где-то,пока не знаю . Возможно ваш личный опыт.

Привет,меня зовут Ксюша. Сейчас учусь ещё /программная инженерия/ прохожу курсы middlePM / есть своя команда в одной молодежной организации (Team Leader в команде) Так вот,вопрос, как лучше "войти в IT" Возможно советы с чего начать как РМ, мне все это нравится, но как зацепиться где-то,пока не знаю . Возможно ваш личный опыт.

Самый хорошй путь через специальность Тестировщик. имхо.

плюсую. роль скрам мастера куда как тяжелее

Откуда знаешь?

Если ПМ из навыков может похватсться только виртуозным владением плеткой, сертификатом спеца по выпечке пряников и навыками хирургической манипуляции гант-чартом, то он, видимо, впал в кому примерно в 2003 и только что из нее вышел.

Спасибо за ответ. Принципе,так и планирую, а реально ли прийти в компанию и получать обучение допустим, тестировщика или лучше таки курсы ?

Вполне реально, достаточно изучить основы и показать себя хорошо на собеседовании. Есть примеры (в т.ч. свой). Курсы это плюс, но многие компании сами взращивают своих спецов, даже стажировки по тестированию и программированию делают. Удачи!

Привет! Анатолий Кульбацкий, продакт и руководитель аналитиков в Яндекс.Транспорте.

Это часть работы над картой и элементами, которые на ней отображаем. Поменяли и в Мобильных Картах и в Транспорте. Стало удобнее/неудобнее?

https://youtu.be/B1D1nl7jUBE

Да это же git)

))) Дмитрий , Дмитрий М имел в виду,что это чисто визуально напоминает гит в плане ветвления с последующими мержами и т.п. при условии,конечно,что вы пользовались визуальными инструментами для гита ,а не только баш )) такие пироги,я полагаю.. а само видео прикольное и даже поучительное .приятно осознавать ,что в СССР хоть где то был некий порядок ))

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

Graph theory Simplified

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

Политика запрещена в чате

особенно для студентов!

Я считаю, что и свадьбу можно по Скраму организовать

Таких уже даже в фантастически увотерфоленных банках не осталось.

Коллеги, прочитал небольшую статью про одного разработчика и он задался следующими вопросами (а что думаете Вы?): 1. Ежедневные собрания Это идет в разрез с большинством книг для управленца, где говорится: собрания - способ потратить время, и не брать на себя ответственность, чем меньше собраний - тем лучше. В скраме рекомендуются ежедневные собрания (Стэндапы). 2. Отсутствие персональной ответственности Везде в книгах пишется: "за код отвечает команда". А как тогда мотивировать выдающихся людей, как выяснять кто тянет команду вверх, а кто вниз? С кого спрашивать за допущенные ошибки? В книгах по менеджменту обычно говорится: "нет ответственного, считай что задача не будет выполнена".

1. Стендапы, как это ни звучит пародоксально, нужны чтобы уменьшить время на собрания

У нас синхронизация и вне стендапов происходит

Думаю зависит от команды и от целей. Если команда слаженная, если отвественность команды позволяет раьботать без тотального контроля и постоянного форсирования - можно не каждый день. Если хотябы один пункт не выполняется - каждый каждый каждый день. Кроме тего, регулярные собрания как раз поддерживают в сотрудниках чуство отвественности и иметь отвественных за каждыую отдельну часть проекта, а не искать потом крайнего по всему проекту в целом. Регулярные собрания нужны так же при личночтных конфликтах в команде. Стендапы от обычных собраний отличаются повешенной оперативность.

Каким образом?

1. Стендапы, как это ни звучит пародоксально, нужны чтобы уменьшить время на собрания

если кратко мои мысли: 1. собрание собранию рознь, не нужно вешать ярлыки, если исходить из эффективности стендапов, и понимать их цель, то это не будет способом потратить время, и тем более не брать ответственность, если один из смыслов закоммититься перед командой что ты хочешь сегодня успеть сделать, чтобы продвинуться к достижению целей спринта. 2. одно другому не мешает, ключевое - чтобы индивидуальные интересы не перевешивали интересы команды