Мы познакомились с очень интересным человеком, благодаря которому нам удалось расширить кругозор и понимание того, чем может заниматься аналитик.
Итак, в сегодняшнем интервью мы поговорим о применении навыков аналитика в крупных производственных компаниях, о методологиях Lean Manufacturing, Six Sigma и Process Quality Control, и других штуках, которыми аналитику на постсоветском пространстве не всегда свойственно заниматься.
Роман Баканович (РБ): Привет! Наконец, удалось созвониться! Спасибо, что нашел наше сообщество!
Петр Мурышкин (ПМ): Привет! Спасибо вашему сообществу — вы собрали много полезной информации о бизнес-анализе. Ну и пообщаться о нашей профессии на русском всегда интересно =)
РБ: По традиции, для начала расскажи, пожалуйста, о себе.
ПМ: Меня зовут Петр Мурышкин (https://de.linkedin.com/in/muryshkin/en), родом я из Санкт-Петербурга, в 1998 году переехал в Германию и с тех пор здесь живу и работаю.
Начинал свою карьеру в ИТ с разработчика (около 10 лет занимался программированием), потом уже переключился на бизнес-анализ. Спустя некоторое отошел от непосредственно бизнес-анализа. Например, сейчас на проекте (это стратегический открытый государственно-общественный проект с солидным бюджетом, fiware.org) занимаюсь больше структурированием организации проекта и его внутренних процессов. При этом применяю отдельные техники бизнес-анализа.
РБ: Это интересно. Расскажи, пожалуйста, подробнее.
ПМ: Да, это довольно интересно. Много простора для креатива. В последнее время начал подробно интересоваться DevOps, а именно пытаюсь применить понятия автоматизации и оптимизации производства к процессам труда в ИТ, поскольку в какой-то момент я понял, что индустриальная революция, которая произошла в промышленности, только начинается в ИТ индустрии — и у этого направления, как я предполагаю, довольно большой потенциал.
РБ: Какие навыки аналитика актуальны в твоей работе?
ПМ: Первое и, на мой взгляд, самое главное — это помощь в принятии решений: часто приходится помогать бизнес-стороне заказчика определяться с выбором продуктов. Чтобы решение было основано на фактах, помогаю составить понимание бизнес-целей (зачем, собственно, продукт нужен), границы проекта (с помощью юзкейсов) и далее определить приоритеты. Анализ заинтересованных сторон — полезная техника, т.к. часто возникают сложности в коммуникации. Приходится выявлять потребности отдельних ЗЛ (заинтересованных лиц) и затем уже улаживать разногласия.
РБ: Какие качества важны для аналитика?
ПМ: Перечислять все, что пишут в книжках, не буду. Наиболее очевидной будет способность “эффективно” читать и писать. Политически сбалансированная настойчивость в сборе информации и умение прорабатывать большие объемы информации (часто с незнакомыми терминами и в незнакомых областях) и выявлять важные моменты, цепляться за “угловатости” представленных концепций и несостыковок в них. Бизнес-аналитик, выбравший путь генералиста, приходит в компанию, о специфических деталях внутренней жизни которой он вначале практически ничего не знает, слушает, задает много внешне глупых вопросов, собирает и структурирует информацию о бизнесе, а потом через некоторое время уже сам рассказывает сотрудникам, как работает их предприятие, иногда вскрывая “неожиданные” или, если быть более точным, вытесненные коллективным сознанием факты.
РБ: Наверняка, после того, как аналитик накопит знания в определенной области (бизнес- или технологической), не так просто потом перейти в другую область?
ПМ: Да, у нас действительно непросто переходить из одной области в другую: от более опытного аналитика ожидают привязки к определенной отрасли. Например, от enterprise аналитика могут ожидать глубоких знаний в какой-то технологии. В свое время мне не хотелось связывать свою карьеру с определенной технологией (а именно, одной крупной e-commerce платформой), но в то же время была возможность погрузиться в бизнес-домен.
Это мне помогло определиться с направлением. Сейчас специализируюсь на моделировании и анализе процессов. Прошел вводные курсы по ITIL и Six Sigma.
Например, в прошлом году в одном из подразделений одного из крупнейших индустриальных концернов разбирались с внутренними процессами ИТ команды в центре компетенции Java. Несмотря на сравнительно небольшое количество сотрудников (примерно 60 человек в команде), компания тратила три недели, пока новый член команды сможет начать работу. Моей задачей было описать внутрение процессы, выявить проблемные точки и предложить доступное в заданных рамках решение.
РБ: А что обычно является результатом твоей работы?
ПМ: Как всегда, работа начинается с бумаги и ручки: после интервью с заинтересованными лицами определяем все элементы процесса, анализируем его, и строим модель. Достигнув коллективного понимания и принятия модели акутальной реальности вместе с ее проблемами и ограничениями, начинаем работать с ожиданиями и пожеланиями взаимодействующих сторон. В итоге получается “будущая” модель процесса, в которой часто исключаются слабые или лишние с точки зрения эффективности производительности звенья. Иногда к сожалению получается так, что после завершения моей деятельности даже специалисты со стажем неожиданно для всех теряют места в проектах.
Однажды столкнулся с представителем компании, выполняющей подобные заказы менеджмента официально и прямым текстом: аналитически выявить потенциалы возможных сокращений, одновременно повышая эффективность бизнеса путем реструктуризации процессов. Меня лично интересует однако, прежде всего, понимание того, что происходит в подлежащей совместному определению объективной реальности всеми участниками. Путь к этому лежит через интервью, просто живое человеческое общение и доступные визуальные схемы переплетений процессов, систем и организаций. При этом, конкретная нотация является лишь вспомогательным средством для коммуникации, будь то ARIS, UML, BPMN или просто flow chart.
Несмотря на всю технологию, людей (что вполне нормально) в конце концов, занимают вопросы из серии “почему и зачем мы здесь и что все это значит”, равно как и психологические аспекты: за сильный фокус на сугубо интеллектуальную деятельность иногда приходится платить высокую эмоциональную цену, и это также нельзя, как я считаю, оставлять без внимания. Как мне сказали на курсах, “never blame the people — blame the organization!”
Для ИТ процессов в целом, на мой взгляд, понятию Value Сhain стоит уделять гораздо больше внимания, т.к. тот же DevOps его в некоторой степени отражает, но на сегодняший день по-прежнему есть большой простор для улучшений, особенно в области массового производства ПО. С коллегами и единомышленниками, встретившимися мне на моем пути, мы создали исследовательскую группу Special Interest Group for Software Production Lines (http://sigspl.org/) с целью агрегировать и структурировать современные методы автоматизации и обеспечения качества при производстве ПО.
Хотелось бы видеть прозрачные и измеряемые процессы производства ПО и при этом иметь возможность также объективно измерить уровень качества “мягкого” продукта, как это возможно уже сегодня для бесчисленных промышленных артефактов.
Всех заинтересовавшихся приглашаю в группу http://sigspl.org/contact/.
РБ: Расскажи, пожалуйста, чуть больше о роли аналитика в DevOps
ПМ: Для меня было интересно опробовать идею, когда можно создать виртуальную модель мира при производстве ПО и видеть, как этот процесс происходит — в режиме реального времени! В рамках Sigspl.org мы решили заняться исследовательской работой. На данный момент это деятельность, финансируемая из частных средств. Поэтому мы проводим “полевую работу”, ориентируясь в своих карьерных планах на более или менее случайно попадающиеся нам проекты, где методики Devops и разработанные нами в SIGSPL приемы играют ключевую роль, даже если это никем официально не озвучено. К примеру, мой коллега участвует в реструктуризационном проекте одной из крупнейших страховых компаний, целью которого является улучшение самого процесса разработки ПО. Их задача — ускорить поставку новой версии собственного ПО предприятия с 9 месяцев до 5 дней, т.е. оптимизировать все процессы таким образом, чтобы можно было выводить “в продакшн” пусть и малые, но все-таки улучшения продукта как можно раньше. Я еще помню те времена, когда раз в 3 месяца команда собирается, и в выходные все молятся, чтобы релиз получился. В моей практике был проект с бюджетом в 30 млн евро. Результатом работы был код, размещенный на Github. Европейская Комиссия имела много вопросов касательно того, куда был потрачен бюджет. Мы предложили провести независимый контроль качества продукта. В итоге улучшили и автоматизировали процесс QA (Quality Assurance). Мы рассматривали каждый компонент системы как отдельный сервис. Это позволило сделать процесс производства ПО более прозрачным и эффективным.
РБ: Насколько понимаю, как раз для этого ты и изучал Six Sigma?
ПМ: Все верно. Как оказалось применять SixSigma именно для разработки ПО все еще редкость, хотя, как оказывается, компания Sun Systems была в свое время пионером и на этом поле. Данная методология позволяет согласно своему дизайну сократить среднестатистическое количество ошибок от 100 000 до 1. Условием, является, правда, абсолютная прозрачность и измеряемость производственнных процессов с точки зрения научной физики. Звучит довольно интересно, особенно, для области разработки ПО.
DevOps данную проблему в некторой степени решает. Но SixSigma позволяет пойти дальше. Есть одна сложность: данную методологию можно применить только там, где можно измерить результат. SixSigma отлично работает в инжиниринге, когда нужно проводить контроль качества.
При разработке ПО есть слишком много факторов, котороые количественно измерить довольно сложно. Сам процесс налаживания SixSigma в предприятии довольно затратный. Поэтому аналитик здесь может здорово помочь с определением ожидаемого результата, т.е. провести подготовительную работу и в итоге сэкономить предприятию время и деньги в случае, если то не готово внедрять SixSigma.
РБ: Если разделить анализ на 2 категории: бизнес-анализ и системный анализ, для какой из категории применение SixSigma как инструмента наиболее актуально?
ПМ: Сложно сказать, т.к. четкого разделения на такие роли, как правило, нет. На одном из проектов у меня был случай, когда внутри компании было отдельное подразделение бизнес-анализа. Это была абсолютная роскошь. Мы работали в связке с SME (Subject Matter Experts), т.е. людьми с большим опытом, которые были экспертами в своей области и наблюдали десятилетиями, как системы появлялись и умирали. В итоге моей задачей было обрабатывать приходящие запросы от бизнеса, анализировать их и предлагать решения. В случае успешного решения мы отстаивали наше предложение перед командой из двух бизнес-архитекторов, которые надевали “скептические шляпы” и пытались найти слабые места в нашем решении в обязательной формальной и одновременно коллегиальной сессии. Но нередко до этого не доходило, т.к. выполняя роль аналитика, мы уже приходили к выводу, что сам запрос не был оправдан с точки зрения пользы для бизнеса, или недостаточно проработан, чтобы тратить время на его ИТ дизайн, а тем более техническую разработку.
РБ: Какие инструменты используешь в своей работе?
ПМ: Если говорить о моделировании, то довольно часто — MS Visio. Если у клиента есть Confluence, то используем отличный плагин Gliffy. Рекомендую.
Если начать с ранних активностей, когда нужно собрать информацию о бизнесе клиента, о контексте системы, то пока инструменты стандартные (MS Word и ему подобные). Но уже некоторое время в сообществе SIGSPL.org в рамках оптимизации процесса ПО мы обсуждаем и автоматизацию процесса бизнес-анализа. Так, аналитик мог бы иметь инструмент, использующий NLP (Natural Language Processing, см. диссертацию Л. Кофа), с помощью которого было бы возможным проанализировать всю доступную информацию (документы, контент в системах, описания задач и т.д.) и собирать информацию о сущностях, которыми бизнес оперирует. Это позволило бы более быстро составить диаграмму домена (или даже формальную онтологию) и убедиться, что в дальнейшем не будут пропущены требования касательно отдельных сущностей. Следующим шагом можно было бы составить систематизированные “пакеты требований” и словари для определенной предметной области, которые можно использовать повторно от проекта в проекту аналогично библиотекам с программным кодом.
РБ: Мысль довольно интересная.
ПМ: Спасибо =) Мы в рамках sigspl.org как раз этим в т.ч. и занимается. Хотелось бы найти больше единомышленников, а то очень уж глобальная тема.
Одна из задач, которую мы хотим решить — стандарт качества ПО и прозрачная возможность его измерять. Сегодня в Европе есть общепринятые стандарты качества: стандарт энергоэффективности бытовых приборов и даже зданий (этикетка энергоэффективности, 2009/125/EC ), и стандарт оптимизации мощности вычислительных систем (ISO/IEC 14756:1999). Если бы можно было применить нечто подобное в ИТ индустрии относительно процессов создания программного обеспечения, то компании, заказывающие разработку ПО, могли бы выбирать между вендорами, основываясь также и на объективном уровне качества производства. С другой стороны, и ИТ вендоры могли бы обоснованно заявить: “У нас качество производства ПО класса А++”. Соответственно, и высокая цена могла бы быть при этом чем-то подкреплена.
РБ: Как занимаешься саморазвитием? Конечно, помимо курсов по Six Sigma =)
ПМ: Книги и целенаправленный нетворкинг. К примеру, за последнее время было очень интересно познакомиться с книгой Velocity (“Новая цель”), которая описывает бизнес-трансформацию некоего гипотетического производства совершенно другой отрасли, но тем не менее многим странно узнаваемого. О нашей отрасли стоит назвать книги Mythical Man Month (Fred Brooks) и The Phoenix Project (Kim Gene). В целом, накопив знания из книг по DevOps, начинаешь черпать знания из научных публикаций и смежных отраслей. Опять же, про Six Sigma узнал когда-то случайно при общении с коллегами из другого отдела.
Также для расширения кругозора рекомендую thoughtworks и их радар технологий.
РБ: Спасибо! Было интересно пообщаться. Последним будет традиционный вопрос: что бы ты пожелал участникам сообщества analyst.by? =)
ПМ: Чего бы пожелать.. Интересных проектов, крепкого здоровья и чтобы они победили complexity, а не complexity — их.
Спасибо, интереснейшая статья
Спасибо, было интересно почитать о вашем опыте и интереса — они довольно сильно отличаются от оных меня и моих коллег.
Ваши планы, связанные с sigspl.org также впечатляют)
Мне немного не хватило деталей о проектах, чтобы составить более полное впечатление о вашей работе - то ли формат интервью не позволяет, то ли подписанное NDA, но лично мне эта часть показалась наименее раскрытой. Буду признательна, если расскажете в комментариях к статье или же следующей статьей)
Уважаемая Мелисса, благодарю за просьбу рассказать больше о деталях проектов. Пожалуйста, уточните, какого именно плана детали Вас интересуют.
Петр добрый день,
В качестве примера я приведу следующий абзац.
На сколько я поняла, вы в этом абзаце упоминаете сразу два проекта (один — вашего коллеги, второй — ваш).
Поправьте меня пожалуйста, если я вас неверно поняла и проектов с примерам тут больше (или меньше).
«К примеру, мой коллега участвует в реструктуризационном проекте одной из крупнейших страховых компаний, целью которого является улучшение самого процесса разработки ПО. Их задача — ускорить поставку новой версии собственного ПО предприятия с 9 месяцев до 5 дней, т.е. оптимизировать все процессы таким образом, чтобы можно было выводить “в продакшн” пусть и малые, но все-таки улучшения продукта как можно раньше. Я еще помню те времена, когда раз в 3 месяца команда собирается, и в выходные все молятся, чтобы релиз получился. »
Мне было не совсем понятно, в чем была проблема, как и почему вы ее решали. Сделать более короткие итерации было конечной целью (или сделать итерации с релизом не в пятницу) или же проблема была в другом?
«В моей практике был проект с бюджетом в 30 млн евро. Результатом работы был код, размещенный на Github. Европейская Комиссия имела много вопросов касательно того, куда был потрачен бюджет. Мы предложили провести независимый контроль качества продукта. В итоге улучшили и автоматизировали процесс QA (Quality Assurance). Мы рассматривали каждый компонент системы как отдельный сервис. Это позволило сделать процесс производства ПО более прозрачным и эффективным.»
Вопрос в принципе аналогичен — в чем была исходная проблема и как вы ее решали. Мне не очень понятно, как рассматривание каждого компонента системы, как отдельного сервиса помогло вам сделать процесс производства прозрачным и эффективным. Измеряли ли вы эффективность до и после?
Заранее спасибо за пояснения)
Спасибо Вам Мелисса за отличные и интересные вопросы; попробую на них ответить.
В. Сколько примеров из проектов упоминается?
А. Три :-) 1. проект коллеги в страховой компании. 2. мой проект для Еврокомиссии. 3. Побочное замечание, что в еще одном, третьем проекте где Ваш покорный слуга имел счастье участвовать, команда и правда собиралась для релиза каждые три месяца, но не в пятницу, а в воскресенье, с участием представителей заказчиков. Нервотрепка, не то слово.
В. В чем была проблема в первом проекте (коллеги) и как и почему ее решали?
А. Как Вы правильно поняли, конечная цель здесь значительно сократить итерации.
В. Пояснения касательно проекта с ЕС.
А. Формулировка пожалуй действительно слишком туманная и если честно, мне сейчас кажется проще еще раз кратко обрисовать что происходило в проекте, чем пытаться вспомнить что может скрываться за этой фразой. Возможно, мы что-то потеряли и не нашли при вычитке.
Итак, задачей проекта было поставить ряд ПО компонентов разного характера, и продемонстрировать их в демонстрационной системе. В мою задачу входила техническая реализация вспомогательной системы типа ОТК (отдел технического контроля), чтобы стандартизовать приемку максимально большого числа вообще-то очень разных по своей природе компонентов. Мы определились, что решим проблему стандартизации приемки компонентов, представляющих из себя сервисные компоненты (т.е. как правило это были вебсервисы c RESful API разнообразных архитектур).
Надеюсь, я в достаточной мере смог Вам ответить. Если что-то еще неясно, спрашивайте.
Петр! Спасибо за статью! отправила Вам в линкедине запрос