• Как стать продакт-менеджером с 0 из другой профессии. Часть 1
    0

    с другой стороны непонятно, чем вы лучше — пришел какой-то анонимный Андрей с горы и вещает с табуреточки

  • Как стать продакт-менеджером с 0 из другой профессии. Часть 1
    0

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

    это правда, но не вся правда. суть не в плане развития, а в опыте создания, запуска и развития продуктов.

    вам нужно опыт получить, а не план, алё

  • Как стать продакт-менеджером с 0 из другой профессии. Часть 1
    0

    "С другой стороны, обилие инфо-жуликов на данном рынке"

    какое обилие, о чем вы говорите?

  • Нужна ли сертификация для бизнес-аналитика?
    +1
    Certified Analytics Professional (CAP) радикально отличается от остальных перечисленных в статье сертификаций тем, что это действительно сертификация по аналитике (количественным методам исследования данных бизнеса), а не анализу.

    Поэтому тут надо выбирать аккуратно, про что вы больше:
    — моделирование процессов (см. BPM CBOK)
    — организационное развитие + автоматизацию бизнеса (IIBA, BABOK)
    — анализ бизнес-показателей (CAP)
    — построение аналитических хранилищ и дэшбордов (DAMA DMBOK)
    — инженерию требований (IREB CPRE)
    — системное моделирование (OMG UML/SysSML)
    — бизнес-анализ в Agile (что бы это ни было)
    и т.д…
  • Нужна ли сертификация для бизнес-аналитика?
    0
    Большая часть аналитиков не считает, что сертификация не приводит к более высокой зарплате.

    Сложная логика высказывания. Двойное отрицание можно заменить утверждением.
  • Нужна ли сертификация для бизнес-аналитика?
    0
    International Requirements Engineering Board (IREB) предлагает несколько уровней сертификации CBRE для аналитиков требований, что больше подходит для аналитиков в ИТ.

    CBRE — это такая компания, занимающаяся недвижимостью.

    У IREB — CPRE (Certified Professional on Requirements Engineering), вот тут я описывал, как подготовиться и пройти экзамен.
  • Как я прошел обучение в учебном центре «Специалист» при МГТУ им. Н.Э.Баумана по курсу CCNA Безопасность в сетях Cisco
    0
    ок, я проходил в 2012 году курс, который вёл сам директор курса, дровишки оттуда
    www.specialist.ru/course/mobr-a

    видимо запустили какие-то совместные программы, если так
  • Как я прошел обучение в учебном центре «Специалист» при МГТУ им. Н.Э.Баумана по курсу CCNA Безопасность в сетях Cisco
    +1

    Кстати, breaking news — Специалист не имеет никакого отношения к бауманке, кроме того, что арендовал у нее помещения


    Так что это название примерно как трактир «У кота»

  • Зачем IT-специалисты преподают на курсах и к чему готовиться, если решил стать спикером
    0

    По статистике результатов выпускников

  • SEMAT? Приятно познакомиться
    0
    а как сейчас, появился?
  • Почему управлять государством должен продуктовый менеджер?
    0
    эта та самая банковская система, в которой выплаты по эквайрингу идут 2 дня в рабочие дни?
  • Почему управлять государством должен продуктовый менеджер?
    0
    вот например классика, Стаффорд Бир, Мозг Фирмы: gtmarket.ru/library/basis/5789
  • Почему управлять государством должен продуктовый менеджер?
    +3
    эта та самая банковская система, в которой платежи между банками по выходным не ходят?
  • Почему управлять государством должен продуктовый менеджер?
    +1

    я знаком с Ильей, он как-то ко мне советоваться приходил


    но чем Илья как предприниматель-менеджер гениальнее любого другого предпринимателя, который смог сделать любой другой небольшой, например, неайтишный бизнес?

  • Почему управлять государством должен продуктовый менеджер?
    +1
    какие ваши доказательства?
  • Почему управлять государством должен продуктовый менеджер?
    +1
    «Это типичная ошибка управления продуктом, когда люди мечутся между придумыванием новых фич и точечными правками.»

    Основная проблема в развитии госуправления — не только и не столько в отсутствии продуктового подхода, сколько в отсутствии системного моделирования инициатив. Если вы посмотрите на пояснительные записки большинства законопроектов (а законопроект — это по сути и есть гипотеза), то они все оперируют очень локальными мирками «Если — То».

    Что и приводит к эффектам, похожим на экологические эффекты — «давайте убъём всех волков и овцам станет хорошо».

    С системным моделированием в продуктовом мире тоже плохо.
  • Почему управлять государством должен продуктовый менеджер?
    +4
    «Мы наблюдаем тотальную некомпетентность руководства многих государств, но потрясающий профессионализм в успешных IT-стартапах.»

    Откуда выводы про профессионализм в успешных стартапах? Почему это не просто отдельные кейсы, сочетающие N талантов + M удачи?

    Вы вообще понимаете, что в стартапе главное предпринимательство, живучесть, а в зрелом продукте — менеджемент, и это совсем не одно и то же?

    Менеджмент стремится сохранить и преумножить существующее, предпринимательство стремится найти устойчивую модель бизнеса/системы (хотя бы на N лет).
  • Почему управлять государством должен продуктовый менеджер?
    0
    «Фокусировали на них внимание ученых и экспертов. И щелкали их как семечки, одну за одной.»

    Откуда убеждённость, что щёлкали бы?

    Вы же понимаете, что в запутанной системе «решение» одной проблемы может приводить к куче неочевидных побочных эффектов и новых проблем?

    Нельзя проблемы такого масштаба решать по одной, алё.
  • Почему управлять государством должен продуктовый менеджер?
    0
    «Мы бы вытаскивали самые приоритетные задачи из общечеловеческого бэклога.»

    Почему ссылка на Atlassian, а не на хотя бы en.wikipedia.org/wiki/List_of_global_issues
    ?
  • Почему ПМ часто проигрывают аналитикам, а те в свою очередь часто пасуют перед тестерами?
    0
    мой текст показывает, что без знания фактуры нельзя давать категоричные оценки

    рекомендую не использовать такие примеры, которые иллюстрируют неизвестно что

    если хотите демонстрировать свою экспертизу, то либо на своем опыте либо на достоверных исследованиях индустрии
  • Почему ПМ часто проигрывают аналитикам, а те в свою очередь часто пасуют перед тестерами?
    +1
    Но по мере развития проекта появляются рабочие варианты системы и ее начинают активно тестировать. И вот тут наш всеобщий любимец, красавец-мачо аналитик — почему-то оказывается в тени у тестера, а то и терпит конфуз от неготовности ответить на его вопросы.

    Мало того, обнаруживается скрытая противоречивость требований, зафиксированных аналитиком и утвержденных заказчиком на ранних стадиях разработки, не говоря уже о не-полноте этих требований. И все чаще аналитик выглядит ротозеем, пропустившим противоречие требований или их не полноту.


    непонятно, почему вдруг такие красочные категоричные эпитеты из крайности в крайность — то мачо, то ротозей-пустослов.

    аналитик обязан аккуратно перемещаться по логическим уровням проектирования:
    — уровень потребностей заинтересованных лиц
    — уровень требований надсистемы
    — уровень требований к системе
    — уровень требований к подсистеме

    на каждом уровне происходит умножение в среднем на X 5-10 требования, поэтому если он сразу сунется в детали, то там и погибнет в аналитическом параличе

    я давно, ещё в том же 2010-м году рекомендовал выстраивать сотрудничество между аналитиком и тестером, привлекать тестеров для рецензирования требований ДО старта проекта: sqadays.com/ru/talk/12354

    у аналитика и тестера разные направленности мышления — позитивное и негативное, поэтому они друг друга дополняют

    надеяться, что аналитик в одиночку каким-то чудом одним кулём и каскадом разработает полный комплект полных непротиворечивых требований без обратной связи — это утопия

    опять же этим ролям нужно выстраивать взаимодополняющий тандем, а не конкурировать, кто из них умнее

    для софтверных проектов, чтобы не возиться с 3-4 уровнями требованиями, придумали специальные инструменты-техники, как оставаться на уровне смысла и сути — user stories + use cases

    Первенство по экспертизе относительно возможностей системы неуклонно переходит к тестеру, а аналитик, со своими аналитическими документами, — все больше становиться похожим на бесполезного пустослова.


    непонятно, о какой экспертизе о возможностях системы идёт речь, если, например:

    а) о разработке требований для выбора готового решения, например, CRM. пока решение не выбрано, как может тестировщик знать его лучше? да даже если и выбрано, откуда уверенность, что он знает все возможные решения?

    б) о разработке требований к новой системе. никакой системы ещё нет. в чём может быть экспертом тестировщик? в типовых багах требований? да. в типовых необработанных ситуациях — да. но не в системе же, которой ещё нет.

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

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

    в некоторых компаниях, занимающихся внедрением, функции аналитика и тестировщика объединяют в одном человеке и это работает хорошо
  • Почему ПМ часто проигрывают аналитикам, а те в свою очередь часто пасуют перед тестерами?
    +1
    От заказчика приходит категорическое требование: реализовать «возможность множественного выбора значений из справочников разрабатываемой системы». ДевЛид и ПМ в шоке: Требование режет на корню простую архитектуру заложенную в основу разрабатываемой и в разы увеличивает бюджет проекта.

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

    А во всех остальных случаях в реальной работе множественный выбор оказывается даже вредным и совершенно не нужным заказчику. В итоге бюджет увеличивается «на копейки».

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


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

    Пока не разобрались, зачем — торговаться рано, незачем. Как только разобрались — ПМ помогает торговаться. Но тут конечно многое ещё зависит от того, что продаём — человекочасы разработчиков, свою платформу, что-то ещё? — от этого сильно меняется переговорная позиция
  • Почему ПМ часто проигрывают аналитикам, а те в свою очередь часто пасуют перед тестерами?
    +1
    В результате проект сдали а тендер за следующий аналогичный проект ПМ проиграл, другому ПМ из конкурирующей компании. Этим ПМ-ом оказался его бывший аналитик, к тому времени перекупленный конкурентами. Вот наглядный пример к чему приводит нежелание работать с требованиями в части менеджмента.


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

    это кейс про управление экспертизой и мотивацией, а не про требования
  • Почему ПМ часто проигрывают аналитикам, а те в свою очередь часто пасуют перед тестерами?
    +1
    Спасибо за оценку

    по поводу рекомендаций — у автора хороший заход, но в середине текста он почему-то начинает скакать по оценкам и ситуациям, имеющим непонятную природу, так что внятно прокомментировать сложно, но я попробую:

    я почти никогда не встречал, чтобы ПМы «пасовали» перед аналитиками. обычно или ПМы были сами бывшие аналитики и хорошо понимали, чего хотеть от аналитика и как выстраивать с ним отношения либо сознательно занимались не-аналитической работой, которой в проекте тоже может быть много, а с аналитиком выстраивали здоровые отношения, т.к. понимали, что они работают друг на друга

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

    поверьте, в общем случае это громадный объём работ и я как аналитик всегда был счастлив, чтобы её делал кто-то другой, не я

    как аналитик я был сильно заинтересован в том, чтобы у ПМа была достаточная информация для УПРАВЛЕНИЯ требованиями, т.к. я глубоко убеждён, что если на проекте роли ПМа и аналитика разделены по людям, то первый должен заниматься УПРАВЛЕНИЕМ требованиями, а второй — их разработкой. поэтому я обычно все вопросы про приоритеты, сроки и бюджеты по требованиям отдавал ПМу, а ему для ответов на эти вопросы конечно приходилось погружаться в мои требования, а мне — ему их представлять. это не rocket sсience, просто сотрудничество. откуда тут берётся конкуренция, которую рисует автор — мне непонятно, она вредна

    поэтому с ситуациями типа этой не сталкивался:

    «пм знаком с ним только поверхностно. И особо в структуризацию и детализацию требования не вникал. Типа — «не царское это дело»… И сталкивается с классической ситуацией: На встрече выясняется, как это бывает практически во всех случаях, что для разработки не хватает либо времени либо денег, а то одновременно и того и другого.

    ПМ тут же начинает «жать на все педали» чтобы «продавить документ» и выторговать общую запланированную сумму…»


    ПМ ведёт торговлю на реестре, причём с приоритетами и оценками по частям, а не общей суммой.

    Реестр требований — это основа для планирования, оценки, контрактации и сдачи работ. Если ПМ этого не понимает, то это дикость конечно, но если он в целом толковый, можно ему оперативно объяснить, что это один из основных его инструментов управления.

    Но тут может вмешаться аналитик с предложением пройтись по документу и определиться, а все ли описанное в документе на самом деле так «необходимо-надобно» заказчику?

    вопрос правильный, но переговоры про ценность и приоритеты должен вести ПМ, как человек, знающий ещё и стоимость, сроки и риски по каждому требованию/блоку, а не только требования. тут явное нарушение ролей.
  • Почему ПМ часто проигрывают аналитикам, а те в свою очередь часто пасуют перед тестерами?
    +4
    Автору вообще известен случай, когда одна очень известная и богатая компания, разработчик очень известного программного продукта, решила (в придачу к отделу тестирования) обзавестись ещё и отделом аналитики.

    Кончилось всё тем, что «маститого гуру», заведующего такими трудами созданного аналитического отдела, — с треском уволили, а сам отдел расформировали по отделам тестирования и сопровождения.


    С 2009 по 2011-й год я по запросу CTO выстроил отдел системных аналитиков в Лаборатории Касперского с 10 до 35 человек, потом мою должность сократили, а отдел переподчинили руководителю пула из более чем 200 тестировщиков, где уже была успешная практика управления отпусками, а большее было и не нужно.

    Так что видимо речь о моём кейсе, но я с удовольствием дополню его от первого лица.

    1. «маститого гуру» — в 2009-м году я не был маститым гуру, а просто был неплохим аналитиком уровня middle, но который:
    а) регулярно писал в блог свои заметки про разработку (2005-2004) и потом про анализ и проектирование (2005-2008)
    б) я имел опыт управления программами нескольких ИТ-конференций, помогал с их запуском в россии — РИТ, ClientSide, HighLoad
    в) я имел несколько выступлений на этих конференциях
    г) у меня был опыт работы не только аналитиком, но и архитектором
    д) у меня был очень хороший английский
    е) я прошёл входной тест на Customer Requirements на Brainbench лучше всех кандидатов, да и вообще в России
    ж) активно интересовался вопросами управления, читал литературу по нему, проходил подготовку (например, тренинг по конфликтологии на зимней психологической школе СПбГУ)

    Так что маститым гуру я тогда (да и сейчас) себя не считаю, несмотря на то, что ПОСЛЕ выхода из Каспера вместе с Сергеем Нужненко создал Школу системного анализа, которая существует уже 10 лет и обучила 1000 человек и был основным автором федерального профстандарта системного аналитика.

    Мой текущий блог по ИТ-анализу, где можно оценить мою маститость сейчас.

    То, что я проработал в компании 2 года менеджером среднего звена, не имея вообще никакого опыта в управлении (даже тим-лидом, не то что руководителем группы) — это само по себе неплохое достижение, кмк.

    2. Теперь про самое интересное — «с треском уволили, а сам отдел расформировали по отделам тестирования и сопровождения».

    У меня были годовые цели — на 2009-й год — довести численность отдела с 10 до 25 человек, на 2010-й год — довести численность отдела до 35 человек.

    Я благополучно воспользовался отраслевыми связями, накопленными на форуме UML2.ru и за 2 неполных года нанял достаточно крутых специалистов, многие из которых до сих пор (спустя 10 лет) работают в Каспере.

    Будучи сторонником демократичного стиля управления и децентрализации управления, я очень много полномочий отдал руководителям групп, которые создал в отделе.

    Изначально меня хотели нанять не просто руководителем отдела, а ещё и главным аналитиком, чтобы я работал в проектах. Но увидев цели по найму (это в среднем по +2 человека в месяца), я отказался от идеи участия в проектах, ограничился только наймом людей и выстраиванием процессов.

    И получилось что в начале 2011-года моя работа по собственно комплектации отдела закончилось, у меня не было работы в департаменте и компании, а зарплата как руководителя была очень недетской.

    В компании в это время в связи с временным приходом американского инвестора решили в кои-то веки пересчитать расходы, в том числе пересмотреть нормы на менеджмент (и правильно сделали).

    Более того, возникла анекдотическая ситуация, что американский CFO, сидя в самолете с CTO, спросил последнего — «у вас ведь там в департаменте 30 аналитиков, они же бумажки пишут? если мы вместо них 30 разработчиков наймем — мы же быстрее разрабатывать будем»? CTO этот «запрос» передал мне. Я прошёлся по каждому из своих руководителей проектов, задал простой вопрос — «насколько сдвинется твой проект, если с него сейчас снять аналитика?». На основе ответов ПМ-ов посчитал ROI аналитиков, получил цифры от 150 до 600%, отдал CTO.

    Поэтому когда CTO и HR пришли закрывать отдел, уволили ТОЛЬКО меня, все остальные ребята остались на своих местах-проектах и продолжили приносить пользу.

    Я никогда за должность не держался и делать корпоративную карьеру не собирался, платить мне и получать бешеную зп менеджера было не рационально.

    Так что закончилась моя проектная работа по построению системно-аналитической компетенции в компании, а не необходимость в компетенции вообще :)

    В чём был треск, я не вижу. Я ушёл изучать управление продуктами и предпринимательство. Индустрия получила ШСА, Product Camp Russia, профстандарты.

    Так что ваши эти «маститый гуру» и «с треском уволили» — это всё для красного словца.

    NB: если что, этот поток на Хабре, в который вы пишете, тоже создавал я :)

  • Интервью с ProductCamp: конференция по принципу опенсорса, где каждый участник — организатор
    0
    « Продакт-менеджеры стали ее проводить, когда еще нигде в России не было должности продакт-менеджера. »
    это неправда, были, много в телекоме, фарме

    «В том же Касперском не было такой позиции, были только проджект и руководитель интернет-проектов.»
    это неправда, были и Product Manager и Product Marketing Manager и Product Delivery Manager и много — целых 3 департамента

    я не понимаю, зачем вы это пишете, не общаясь с источниками
  • Интервью с ProductCamp: конференция по принципу опенсорса, где каждый участник — организатор
    0
    Мой рассказ про появление первого Product Camp Moscow: medium.com/product-story/product-camp-russia-bc74d0f358d1
  • Анонс. Профессия системный аналитик: развитие сообществ, популяризация профессии и подготовка
    –2

    Изначально это была роль, популяризованная в конце 90-х в RUP'е


    Сейчас в мире она в основном вытеснена понятием Business Analyst

  • Анонс. Профессия системный аналитик: развитие сообществ, популяризация профессии и подготовка
    +1
  • Удобный сайт
    0
    прочитал и прослезился
  • Как делать в два раза больше и получать от этого удовольствие
    0
    Непонятно, какой бизнес анализировал бизнес-аналитик в этом кейсе
  • Учеба это не лотерея, метрики лгут
    0
    а вот и статистика. правда, ожидаемо, не российская: cirr.org/data
  • Как сделать курс по Аджайл на принципах Аджайл
    0
    да, появился, спасибо
  • Как сделать курс по Аджайл на принципах Аджайл
    0
    ок, спасибо, запустил анонс

    получил 10 минут назад оповещение, что мне доступен курс, захожу:
    «Мои курсы
    Пока нет доступных курсов.»

    Может как-то оттестировать получше сценарии использования вашего сайта? Это же наверное не только бесплатных курсов касается.
  • Как сделать курс по Аджайл на принципах Аджайл
    0
    «Инструмент Canvas» в программе звучит как «инструмент доска, холст». чего доска? какая доска?

    сначала был популярен Business Model Canvas, потом каждый мало-мальски эксперт начал генерить в своей теме Product Canvas, Feature Canvas, Project Canvas и т.д.

    например, тот же Project Canvas — это по сути устав проекта, Project Charter, упакованный в горизонтальной ориентации на один лист A4, A3, A2

    так же и со всеми остальными холстами
  • Как сделать курс по Аджайл на принципах Аджайл
    0
    и кстати напомню участникам, что бесплатность обманчива и вы это в какой-то момент поймёте. например, 1 час рабочего времени разработчика в мск стоит в среднем 1 тр, 6 недель X 2 часа X 2 раза в неделю — это уже 24 часа.

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

    поэтому с позиции авторов я бы сделал курс платным, хотя бы 100 р за занятие — так будет больше мотивация, вовлечённость и стремление получить законченную картину мира

    если цели чисто рекламные, собрать базу лидов, то конечно надо оставлять как есть
  • Как сделать курс по Аджайл на принципах Аджайл
    0
    Не очень понятна фраза «смогли найти ценность» для бесплатного продукта. Что это значит?

    Можно пообещать разные темы рассказать:
    как стать крутым DevOps-ом
    как зарабатывать на биткойнах
    как построить свой умный дом
    как найти себе пару с помощью доступного дата-майнинга
    и т.д.

    И на любую из них собрать от 100 до 10 тыс заявок. Это подтверждение привлекательности оффера, а не ценности.

    Ценность можно будет подтвердить косвенно хотя бы ретеншеном, если из 100 записавшихся до конца дойдут хотя бы 50%.

    а то с бесплатными продуктами какая штука — когда люди ищут мобильное приложение на конкретную тему, то скачивают всё похожее в количестве 5-15 штук, а пользуются, как понятно, 1-2 максимум

    когда люди заходят на Курсеру, у них разбегаются глаза, записываются на 20 курсов, проходят в лучшем случае 1

    я готов поанонсировать курс по своим каналам, но сразу предвижу вопрос регистрантов — на сайте не хватает ссылки на вводный вебинар или указания, что участник получит на него ссылку после регистрации
  • Как большие IT-компании переводили свой штат на удаленную работу
    0

    https://tildaweb.pro/beefree_main


    Ссылка не работает

  • Развитие аналитиков
    0

    Странно, что в список телеграмм-групп не попала крупнейшая русскоязычная по системному анализу в ИТ t.me/analyst_ru

  • Людей, разбирающихся в работе программиста, можно встретить где угодно
    0
    этож добрый старый programming-motherfucker.com