ReScript, BuckleScript та інші звірі на React fwdays | 27 березня. Давай з нами!
×Закрыть
Business Development Manager в IT-tuning
  • Почему на самом деле вы не хотите быть Project Manager

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

  • Outsourcing vs software consultancy: как поднять рейты до 75 USD/час

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

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

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

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

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

    спасибо !

  • Курс Business Analysis

    В составлении программы участвуют специалисты в бизнес-анализе, системном анализе, 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

  • Митап «Blockchain для „чайников“»

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

  • Встреча «Формируем нефункциональные требования»

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

  • Как начать в IT Business Analysis без опыта?

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

    Поддержал: Yuri Opanasenko
  • Почему не у всех получится делать продукты

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

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

  • Почему не у всех получится делать продукты

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

  • Приоритизация задач: высшая математика или легкая разминка перед завтраком?

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

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

    Поддержали: Sergey Martynenko, Serhiy Berezhnyy
  • Не прошлым, а будущим: как IT-индустрия может сформировать новый имидж Харькова

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

  • «Продуктове» мислення для аутсорсингових компаній: від виконавців до консультантів

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

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

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

    Поддержали: Oksana Krykun, Denys Kostin
  • Как прошла 5-я конференция ITEM: IT Open Air в Днепре

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

  • О чем молчат сотрудники аутсорсинговых IT-компаний: о проблемах в работе IT-компаний

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

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

    3-4 — когда пора вводить в проект аналитика, нужен ли аналитик на небольших проектах и как закрывать активности этой роли если его нет
    и
    7-9 — зачем клиенту и команде аналитик. когда и как продать.
    Очень мало и достаточно низкий приоритет вопросов, связанных с аналитиком.
    А ведь по сути, это чуть ли не единственная профессия, в профессиональные навыки которого должно входить определение (и даже ограничение, от слова «границы») того, ЧТО нужно сделать, того, что потом оценивать PМ-ам и «продавать» команде:
    — Определение особенностей и целей бизнеса клиента, выявление реальных потребностей, которые должны быть удовлетворены, благодаря продукту, который мы для них делаем (знаем, что и зачем делаем — делаем сознательнее и заинтересованнее);
    — Определение бизнес-среды заказчика и условий, которые диктуют те или иные deadline-ы (Так узнаем, что именно важно для клиента на разных этапах, т.е. критерии, наиболее ценные для него, влияющие на его удовлетворенность, понимаем, ПОЧЕМУ он «продавливает» сроки и пр. Т.о. сознательнее строим свою работу, не отвлекаемся на неважные в данный момент детали)
    — Определение видения и роадмапа развития продукта клиента; партнеров и поставщиков, подрядчиков клиента в том направлении его бизнеса, которому способствует продукт (так мы понимаем, какой должны быть архитектура продукта и понимаем, как она может развиваться. Не говоря уже об идентификации рисков.)
    — Сбор и анализ данных о результате delivery продукта (или его части, scope-а проекта)

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

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

  • Суб’єктивний погляд на Data Science в Україні

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

    Поддержал: Bohdan Pavlyshenko
  • Суб’єктивний погляд на Data Science в Україні

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

  • Карьерный путь Product Owner -> Product Manager

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

    Поддержал: Maxim Tereschenko
  • Карьерный путь Product Owner -> Product Manager

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

  • Карьерный путь Product Owner -> Product Manager

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

    Следовательно, кто может стать product manager: в первую очередь разработчик, возможно, бизнес-аналитик. А вообще не важно, как называется должность, важно то, что человек делает и чем интересуется.

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

  • Outsourcing IT, или о колониальной сырьевой экономике

    Cамую главную цель эта достигла — дискуссия развернулась!
    Плохо, если начинается конфронтация, отстаиваение единственно верной точки зрения, обвинения в адрес оппонентов из-за задетого чувства собственного достоинства. Это ослепляет и ограничивает варианты развития. К счастью, судя по комментариям, таких немного (хотя, у автора это слегка чувствувется, но думаю, это намеренная провокационная позиция ;) ).

    Все верно, если речь про outstaffing, а также про outsoursing без хорошего business analysis и project management (а таких в Украине очень много).
    Очень серьезный риск — потеря квалифицированных специалистов. Да, возможности для разработчиков и тестировщиков повысить свою квалификацию намного выше, работая на зарубежных заказчиков, особенно с командировками). Но что будет делать компания, когда она не сможет предложить своему выросшему работнику подобных задач?

    Но! если outsoursing компания имеет план Б, развивает внутреннюю экспертизу (сохраняет знания) и продает ее, если обеспечивает своим сотрудникам возможность развивать новые направления — это совсем другой outsoursing. Давайте заниматься аутсорсингом, но мыслить стратегически.

    Поддержал: Артем Кравченко
  • Outsourcing IT, или о колониальной сырьевой экономике

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

← Сtrl 123 Ctrl →