Люто плюсую. Была очень удивлена, что весь текст про работу с людьми. Перед тем как идти в PM в первую очередь стоит задуматься, чем он занимается, помимо работы с людьми.

@Sergey Korolev, как ваши успехи? Очевидно, вы действительно хороший руководитель и предприниматель, отличный подход к развитию бизнеса (судя по этой и другим статьям).
Вы пишете про такие направления, как "

инжиниринг, дизайн и продакт-менеджмент. Данная тройка составляет базис нашей consultancy-модели совместно с новыми доменами — business advisory и сервисом найма на стороне клиента.

"
С инжинирингом и, возможно, дизайном все понятно — T-shaped специалисты-инженеры однозначно будут стоить дороже, да еще и как команда. Наверняка, вас ценят как технического партнера, <технического> консультанта.

А вот с продакт-менеджмент, business advisory и сервисом найма на стороне клиента — как вы эти экспертизы развивали (развиваете)? Что прокачиваете? Как и что продаете? .

И второй вопрос — у вас вообще ничего не сказано о маркетинге, как сервисе. А без него, мне кажется, бизнес-консалтинг такой себе. Закрываете ли вы вопросы исследования рынка, продвижения?

спасибо !

В составлении программы участвуют специалисты в бизнес-анализе, системном анализе, UX. Преподаватели курса (несмотря на то, что участвуют несколько человек, программа, занятия и задания согласованные) :
— Анастасия Горева (www.linkedin.com/...​/anastasia-goreva-0662264) — занятия, касающие анализа бизнеса и процесса работы ВА
— Татьяна Хмеленко ( www.linkedin.com/in/tatyanakhmelenko) — занятия по документации, выявлению и анализу требований
— Яна Коверник, системный аналитик в компании Simcord, до этого CS, — занятия по анализу требований, диаграммы, техническому дизайну
— Игорь Ямшанов ( www.linkedin.com/in/I Yamshanov) — занятия по работе с пользователями
— Екатерина Загоровская ( www.linkedin.com/in/kate-zagorovskaya ) - занятия по UX

Начало в 19:15. Ориентировочное время окончания — 21:30

Внимание! Адрес проведения мероприятия «Формируем нефункциональные требования» изменился! г. Харькв, ул. Отакара Яроша 18, бизнес-центр «Солярис», 4 этаж, дверь 404

Истории некоторых наших выпускников (обычно на ВА идут те, кто уже имеет некоторый опыт работы в IT, но в последнем выпуске был, например, человек из охранного агентства):
— через HR в продуктовой комании, постепенно показывая свои интерес к продукту
— через TechWriter
— BA trainee в «конвейерную» компанию
— через тестировщика
Основной совет — ходить по собеседованиям. Посылать резюме, даже если нет нужных лет опыта. Больше шансов будет в тех компаниях, где проекты связаны с предметной областью, которую знаете вы. Ищите такие.
На собеседованиях главное показать не только знания и горящие глаза, но и
— аналитический склад ума
— понимание струкртуры и принципы работы ПО (в зависимости от того, в какую компанию идете)
— демонстрация работ, которые делали в качестве заданий на курсах или в ходе самостоятельного обучения. Вы должны смочь объяснить, почему вы сделали так, какие могли бы быть варианты и пр.
— понимание ожиданий от вас со стороны клиентов и разработчиков.

Евгений, Сергей, вас читать — одно удовольствие!
Теперь все очень хорошо складывается:
— Бизнес- архитектор — это про стратегию развития бизнеса, про ввод и вывод новых ценностных предложений. Ряда ценностных предложений. Продукт — это часть одного ценностного предложения.
-Product Manager — это про этот самый продукт, про его эволюцию, жизненный цикл. Про маркетинг и продажи этого продукта. В нтересах текущей бизнес- стратегии и бизнес- архитектуры: структуры бизнеса, его подразделений, форм и процессов создания и предоставления ценности.
— BA (жаль, Денис Гобов не в этой цепочке))) — это про конкретный функционал, удовлетворяющий стратегию развития продукта в рамках текущей бизнес-архитектуры.
— PM — это про организацию работы по (выявлению и) имплементации конкретного функционала.
Но если почитать ВоК-и, то видно, что они пересекаются. То есть границы плавающие, и эти зоны переходят в компетенции разных ролей от компании к компании и даже от проекта к проекту.

Поэтому в зависимости от степени интеграции аутсорсинговой команды в проект клиента мы можем говорить либо про продуктовый подход, либо про Business transformation.
Спасибо вам!
Женя, вам отдельное спасибо за ссылки на Поттера и Леонард, обязательно ознакомлюсь! И, поймите, нам, аутсорсинговым хомякам, сначала «продуктовый подход» очень сильно помогает понять как специальную секцию BABOK-a, о которой пишет Денис ниже, и потом только перейти к Business Architecture и понять, наконец, что такое Digital Transformation)))

А в чем, собственно, спор? Если сравнивать BABOK и ProdBOK, очевидно, что Продукт — это про жизненный цикл продукта, а ВА — привлекает я им на этапе разработки концепции, решения, доработки. И, да, должен думать о бизнесе в рамках своих конкретных задач.

Есть очень хорошая статья (на английском)

статья — супер ) Ее ценность в том, что она систематизирует техники по целям и условиям приоритезации. Например: приоритезация для выбора фич для MVP и приоритезация для спринта — разные цели, разные техники.
Тоже всегда рекомендую.

Все заголовки правильные. В целом отражает то, о чем думают и говорят в харьковском IT Кластере. Однако пока это все сложно реализуемо. Основные причины (личные наблюдения):
1. Зацикливание IT на самом себе (и, как вариант, IT-образования — на программировании). Обмен опытом и «синергия» (в том числе в вопросах о креативной экономике) с не-IT значительно бы расширило кругозор и возможности сформировать новый имидж Харькова.
2. Относительно низкий уровень менеджмента (я про те самые 300 мелких компаний). Имею ввиду классику управления проектами (бизнесом). Думаю, что общий уровень компаний в городе значительно бы увеличил интерес со стороны потенциальных зарубежных заказчиков. Но пока, наверное...см. п. 3
3. Каждая компания занята своим собственным развитием и выживанием: те, что покрупнее пока не понимают, зачем им консолидировать усилия и в чем именно; те, что поменьше, хотели бы, но некому их консолидировать и направлять (в кластер пока массово не вступают).

Класс! Статья вышла как раз в тот день, когда мы обсуждали все эти вопросы с группой PM/ВА в Харькове :)

Проблема в тому, що ми не можемо зробити цю революцію самі.

Оксана, ELEKS, у вас есть единомышленники! Сеем зерно в головах ребят, которые, надеемся, разнесут его по своим компаниям. И тоже начинаем с ВА :)
И по поводу сложностей: стоит начать с client discovery, чтобы понять, что там за бизнес, на какой стадии зрелости руководители (и, соответственно, компания), какой портфель продуктов, какое место занимает тот продукт, над которым мы работаем в этом портфеле и т.д. Так будет понятнее, на каком языке говорить с клиентом, на чем делать акцент. Уверена, вы тоже это делаете ;)

А кто был на продуктовом потоке? Очень интересно, о чем шла речь.

Хорошо, что провели такой опрос! Он просто показывает насколько у наших компаний односторонний взгляд, согласна с комментом Beaver Green. И для конфы есть 2 варианта:
1) давать ребятам то, что они хотят — инструменты и кейсы, как разрулить ситуацию,
2) изменить подход к позиционированию компании и сервиса
И хотелось бы, чтобы акцент делался на (2). Однако, есть риск, что это не встретит одобрения у целевой аудитории, ведь они скажут, что «мы на эти вопросы повлиять не можем» :(.

Например, вот, что удивило

3-4 — когда пора вводить в проект аналитика, нужен ли аналитик на небольших проектах и как закрывать активности этой роли если его нет

7-9 — зачем клиенту и команде аналитик. когда и как продать.

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

Да, конечно, держать такого аналитика в штате может показаться дорого. Ведь это скорее расходы pre-sale и вряд ли он будет billable. В таком случае нужно, чтобы sales или РМ, или Delivery/Account manager или CEO этим занимались. Поэтому и хотелось бы больше подобных «пинков» с конференций.

2. Если Data Science приносит деньги компании, то их интересы будут защищены, независимо от того, собраны все data scientists в одном отделе или в разных.
А с точки зрения обмена опытом — это то же самое,что и вопрос построения процессов работы компании — заложен в них обмен опытом между проектами или нет.
А вообще — это стандартный вопрос : функционален или проектная структура. Все зависит от типа работ и специализации компании: если выполняются работы для заказчиков из разных бизнес-доменов, то лучше и разные отделы(проекты). Если все работают над общей задачей и отдельные специалисты и группы связаны с другими data scientists плотнее, чем с не data scientists, то целесообразнее один департамент.

Хорошие вопросы, но в принципе, ответы не сложные, с точки зрения бизнеса:
1. Менеджер такой (как и любой другой) команды/проекта — это прежде всего специалист в построении эффективного процесса, который достигает цели потребителей/заказчиков работы команды. Ему совсем не обязательно быть спецом в Data Science. Он, безусловно, должен знать, что это и какова специфика работы с данными (чтобы обеспечить инфраструктуру и др условия достижения цели), но прежде всего ему необходимо понимать, для чего работает эта команда, как она связана с другими, что дает бизнесу (заказчику и той компании, в которой работает).
Как с этим обстоит дело в индустрии — тоже интересно узнать, т.к. Не приходилось, к сожалению, сталкиваться с It компаниями с реальными Data Science проектами.
Но был такой опыт: команда математиков разрабатывал алгоритм анализа торговых сигналов трейдеров. Это алгоритм должен был быть встроен в торговую платформу и предотвращая убыточные сделки. Руководил командой специалист-математик с многолетним опытом в предметной области — FOREX. Он плотно общался с архитектором торговой платформы, в которую должен был быть встроен алгоритм. В основном за чашкой кофе и на философские темы. Наверное, они друг другу помогали и это отражалось на продукте, но не могу быть в этом уверена. К тому же, эти дядьки много лет работали вместе над этим продуктом.
Сказать, что программе общались с математиками — скорее нет, это были разные замкнутые в себе сисемы.

Так а с чем же вы не согласны? :) я же то же самое пишу: в работе project manager тоже мало креатива и много менеджмента, поэтому я и рисую именно такой карьерный путь из project manager. Далеко не каждый project manager обладает техническим опытом (что отнюдь не делает его плохим PjM.
Но если project manager совмещает в себе те роли, которые я написала выше (а это частое явление в маленьких компаниях), то он уже должен определиться, что ему ближе — менеджмент или креатив. Если креатив — то искать свой продукт :)

А из project manager в product manager, на мой взгляд, не совсем целесообразнее путь. Если PM на самом деле занимался управлением проектами, то ему лучше развиваться (если он, конечно, хочет изменения функций, расширения менеджерских полномочий) в account management, operations management.
В те направления, где требуется то, что ПМ умеет и знает инструменты.
Если же мы говорим о ПМ, который совмещает роли pm-ba- team lead, то можно и в product.

Да, Вы правы, для разработчиков это действительно возможность расширить и углубить свои компетенции. А вот для outsoursing компаний (а следовательнои для экономики Украины) — это большой риск.
Ваша компания имеет план реакции на случай потери данного заказчика?