В этом году на INFOSTART EVENT 2018 Education в Петербурге собрались 1С-ники не только со всех концов России и СНГ, но даже из Европы и Северной Америки. Нашим зарубежным гостем стал Алексей Королев, главный специалист по управлению ИТ-рисками компании Wirecard Technologies, Мюнхен.
– Как вам конференция?
Все отлично, приехал с удовольствием. Это уже третья по счету, в которой я участвую. В первый раз я был от компании «Первый БИТ». Тогда мы помогали с организацией и делали небольшие подарки – черные смешные носки, до сих пор у меня пара лежит.
Сейчас я работаю в компании, которая в сентябре вошла в индекс DAX 30 – это тридцатка крупнейших компаний ФРГ, публично торгующих на бирже.
– Что вас сподвигло на переезд и работу за рубежом? Это же серьезный вызов, и профессиональный, и в жизненном плане.
Интерес. Хотелось попробовать реализовать себя за рубежом, понять, насколько те навыки, которые я накопил за годы работы в 1С, будут востребованы там. Плюс это – вызов в личностном и карьерном плане, выход из зоны комфорта. Любой случай переезда за границу связан с трудностями: и в информационном, и в личностном, и в профессиональном планах. Это, действительно, интересный челлендж.
– С какими трудностями связана для вас работа за рубежом? Насколько востребован был ваш опыт применения 1С? И вообще, каковы горизонты возможностей самореализации для специалиста, по сравнению с Россией?
Возможностей меньше. Здесь надо понимать, что за границей, к сожалению, 1С пока не является общеизвестным брендом. И большинство компаний не знает, что есть такая программа для автоматизации бизнеса, такой классный инструмент. 1С International делает, безусловно, правильные и нужные шаги в этом направлении, но пока известным в мире брендом в автоматизации бизнеса платформа 1С не стала. И понятно, что навыки разработки и внедрения 1С, решения на ее базе, мало применимы за рубежом как таковые.
Я переезжал в Германию как руководитель проектов, поэтому было необязательно владеть конкретным языком программирования. В принципе, не важно, на каком языке ведется проект, цикл одинаковый, по большому счету. Какие-то навыки, конечно, потерялись, не используются. Например, за годы работы в 1С я хорошо освоил бухгалтерию, но в Германии, в новых условиях, эти навыки потерялись. Потому что бухгалтерия там другая, и конфигурации 1С, по большому счету, никому в Германии не нужны.
Поэтому горизонт реализации ограничен, но там есть, куда расти и куда двигаться. В частности, полгода назад я перешел на новую должность – сейчас работаю главным специалистом по управлению рисками в ИТ. Тоже достаточно интересная сфера, связанная с безопасностью, со стратегическим планированием. Опыт все равно остается, он никуда не пропадает. Просто ты его накапливаешь, собираешь, как конструктор: там поработал, что-то изучил, здесь поработал, что-то узнал, и в итоге получается набор навыков. И ты пытаешься их применить.
– С какими профессиональными сложностями связана работа за рубежом?
Главная трудность была в начале работы, года 4 назад. Тогда был резкий переход от 1С к работе с другими решениями, и было непонятно, чего вообще ждать. Но потом стало ясно, что в целом процессы одинаковые, что с 1С, что с любым другим решениям. Сейчас принципиальных сложностей, наверное, уже не осталось, потому что за годы работы я освоился и представляю, как все устроено, что и как работает.
– Технологии универсальные, они не меняются?
Да, ничего не меняется. Недавно в одном из выступлений, посвященных Agile и подобным вещам, также прозвучало мнение, что они используются в разработке одинаково везде. Что в 1С, что в Java, что в Python: методология не меняется.
– Что для вас, как специалиста по рискам и руководителя проектов в IT, – управление проектами: это руководство людьми или все-таки управление задачами?
В первую очередь, это управление задачей как таковой. В целом основная проблема любого проекта – понять, что именно надо сделать. Очерчивание рамок проекта – одна из ключевых вещей. Она определяет все остальное: и бюджет, и команду, которая будет все делать, и риски, которые есть. Один из рисков – недооценка проекта с точки зрения объемов. И главная задача управления проектом – решить это. Вторая задача – исполнение проекта. Здесь тоже есть ряд особенностей, за которыми надо следить. В проектном менеджменте 30-40% успеха лежат именно в управлении исполнением.
– Это контроль ответственности или исполнительности?Именно контроль за выполнением тех задач, которые были поставлены. И тут соблюдается определенный баланс: чем профессиональнее команда, тем слабее может быть контроль за выполнением конкретных задач проекта. Чем слабее команда, тем больше контроль.
– Как вы собираете команду? Какие качества должны быть у человека, чтобы попасть в нее?
Замечательный вопрос! Если бы еще у меня был безлимитный доступ к ресурсам. (Смеется). Но жизнь другая, и на проект собираешь команду из того, кто есть, а не из тех, кого хочешь. Но идеальная команда – та, которой ты можешь доверять. Причем это доверие на уровне технологий, уверенность в том, что человек сможет выбрать, до определенного уровня, подходящий способ. Доверие с точки зрения ответственности: ты можешь дать человеку задачу и быть уверенным, что он будет делать ее самостоятельно, и не придется проверять каждую неделю, на каком она уровне исполнена. Это ключевые моменты – ответственность и определенная компетенция, которая позволяет решать задачи самостоятельно. Тогда можно доверять реализацию, а следить – только за какими-то отдельными моментами. Это – идеал.
Но в реальности так не бывает. Еще ситуация сильно зависит от того, какая организационная структура в компании. Если она проектная, ты можешь подбирать нужных специалистов, а если больше линейная, где имеются отделы с определенной спецификой, то ты подбираешь специалистов из них под конкретную задачу. Например, мне нужно было развернуть кластер серверов в рамках проекта. В компании из 5 тысяч человек есть специальный отдел, который занимается развертыванием серверов. Ты даешь им задачу, они все делают, все поставлено на поток. Если возникают вопросы конфигурирования, они тоже решаются в более или менее частном порядке.
То есть управление проектами в нашей компании больше похоже на выполнение задач разными отделами. И там даже нет такого понятия, как выделенная команда. По сути, у тебя есть спонсор проекта, который за него платит, есть ключевые заказчики, которые напрямую влияют на него или зависят от него. Но это не команда, это – стейкхолдеры, которые зависят от проекта. А в команде будет примерно 3 человека – спонсор, руководитель проекта и, может быть, какой-то внешний консультант, который помогает при внедрении. И получается команда плавающая: какие-то люди приходят, что-то делают, потом уходят. Это немного отличается от проектных внедрений, которые были до этого в моей карьере. Но это просто другой способ управления, другие задачи.
– А какая методология управления разработками вам больше нравится? Понятно, что все зависит от специфики проекта, но в какой удобнее работать?
– Исходя из моего характера, мне больше подходит Agile. И я получил большое удовольствие от одного проекта, когда был SCRUM-мастером. Мне очень понравилась такая работа с людьми. Вообще больше люблю работать с людьми, чем с технологиями: я больше персональщик, чем технолог.
Но в целом нет четкого предпочтения, потому что все зависит от проекта, от того, что нужно сделать. Например, у меня был крупный проект перехода с одного сервера на другой, и его по Agile было сложно сделать. Нам необходимо было заранее спланировать весь процесс перехода от и до, четко определить, что нужно сделать, в какие сроки, надо было все это контролировать. А с учетом того, что проект был завязан на уведомлениях пользователей, нужно было известить всех клиентов об изменениях. Плюс это решение, сильно интегрированное со всеми остальными сервисами компании, и нужно было сначала подготовиться изнутри. По Agile можно было выполнить какие-то этапы процесса, но по большому счету смысла в этом нет. И мы делали проект в стандартной методологии управления «водопад».
Но опять же: все зависит от сферы применимости проекта, от того, что мы делаем и зачем, в какие сроки, как часто будут изменения по ходу постановки задачи. Если предполагается большое количество изменений, то лучше Agile. Если мы говорим о каком-то фиксированном проекте по объему и срокам, особенно если он – краткосрочный, не дольше 3 месяцев, то Agile вызывает большие накладные расходы, которые никаких особенных бонусов не принесут. Поэтому надо просто смотреть, что выгоднее использовать в конкретный момент.
– Если в команде возникают противоречия, какие способы достичь согласия вы используете? И вообще нужен ли компромисс?
Компромисс нужен. Это один из самых конструктивных выходов из конфликта. Если мы говорим с точки зрения методологий, то ни одна из них «серебряной пулей» решения конфликтов не обладает. Например, в Agile конфликт будет больше преодолеваться с точки зрения доверия на уровне заказчика. А в Waterfall упор идет на обращение к документации, и решение будет приниматься, исходя из договоров, которые были подписаны на начальном этапе. В то же время предполагается, что в Agile эти конфликты будут всплывать раньше, потому что продукт показываем раньше, а значит, и о проблемах узнаем заранее. Но в реальности, порой, не так. Бывает, что проект – это мина замедленного действия, и она взорвется позже. Так что у любой методологии есть и плюсы, и минусы, и идеального решения конфликтов нет.
– А если конфликтуют между собой сами разработчики? Один программист говорит, что хочет воспользоваться неким алгоритмом решения задачи, а другой настаивает на своем. Как найти оптимальный вариант?
У Agile чуть более подготовленные инструменты для этого, есть, например, ретроспективы. SCRUM-мастер выступает фасилитатором, это его задача – выявить внутренние конфликты, помочь их преодолеть, организовать работу команды в нужном направлении. В Waterfall, на самом деле, то же самое. Руководитель проекта должен делать те же вещи, но нет ярко выраженных инструментов управления конфликтами. Тем не менее, никто не мешает использовать элементы Agile, скажем, ретроспективы. Допустим, поработала команда в течение недели, потом можно устроить встречу, поговорить, что сделано, какие есть достижения, какие проблемы, и так далее. В принципе, ничто не мешает эти инструменты использовать. В общем, коучинг команды и разрешение конфликтов в Waterfall с руководителя проектов никто не снимал.
– Помимо того, чтобы учиться решать конфликты, нужно обладать большим количеством знаний, навыков, умений, чтобы управлять, особенно в сфере автоматизации бизнеса. Как, на ваш взгляд, должен быть устроен процесс сбора, систематизации и передачи корпоративных знаний, опыта, и как это происходит у вас в компании? Может, у немцев есть какие-то свои секреты?
Никаких секретов нет. В Германии, США и в любой другой стране есть те же самые проблемы. Кто-то их решает более успешно, кто-то – менее. Но если говорить про компанию Wirecard, то, несмотря на то, что у нее немецкие корни, сейчас она очень интернациональная: в ней работают люди, наверное, сотни национальностей. Я видел карту в кабинете у коллег, где флажками указаны города, откуда люди приехали работать. И свободных мест там мало. Мне кажется, в нашей компании люди почти из всех более-менее известных стран. Поэтому говорить о том, что есть некая культура педантичности, присущей немцам, я не могу.
– Но, наверное, есть опыт с учетом мультикультурности…
Да, здесь опыт даже очень интересный. У всех свои культура, идеи, знания. Но все-таки мне кажется, что российский бизнес более активен в плане конкуренции, в плане внедрения новых решений и развития. Потому что Германия – консервативная страна. Возьмем, к примеру, компанию BMW. У них есть определенный сегмент на рынке. Понятно, что они борются за внешние рынки, и я могу ошибаться конечно, но внутри страны у них конкуренция между BMW, Audi и Mercedes слабая. Они рынок поделили, давно все автоматизировали, и вряд ли у них будет желание полностью менять систему учета. Если бизнес у них растет, то не взрывными темпами, как у нас. С другой стороны, если российская компания пришла на новый рынок, нужно полностью менять информационную систему, потому что она не справляется. А немецкие системы написаны лет 10 назад. И все прекрасно работает, нет смысла менять.
У них нет взрывных точек роста. Вот Максим Михайлов говорил на конференции о международных рынках. Так, в США появился новый рынок марихуаны, который никто не автоматизировал. Но такие рынки появляются раз в десятилетие, и они очень ограничены. В России экономика развивается, бизнес растет взрывными темпами. И если раньше 10 рабочих мест могли в Excel вести учет, то когда рабочих мест будет 100, Excel уже не справится. И программное обеспечение нужно менять, модернизировать.
– А как для этого передавать технологии, опыт, знания внутри компании? Как использовать накопленный опыт для развития?
Существует целая отрасль – менеджмент знаний, рассказывающая, как управлять знаниями, собирать их и кооперировать, передавать от одного человека к другому. Но простого решения, которое даст ответ, как все это сделать, нет. Это сложный процесс, потому что знания могут быть не только у людей, но у машин, и у клиентов, и у процессов. И знания могут быть разнородными. Например, вот знание – человек научился классно заворачивать гайки. И у него есть ноу-хау, благодаря которому он заворачивает 50 гаек в час, пока остальные – только 20. Сначала нужно найти эти знания, а затем научить остальных. Это нетривиальная задача, и менеджмент знаний позволяет увидеть процессы, описать их, сказать остальным, что их надо использовать.
– Если бы в вашей команде был такой человек, и со всеми своими уникальными знаниями он бы ушел. Это же существенная потеря для бизнеса? Как сделать так, чтобы хоть часть знаний и компетенций осталась?
Здесь идет речь об управлении рисками. В частности, на интервью, посвященных рискам, я выясняю, какие уязвимости есть в другом подразделении. И я часто вижу, что одно из наших «узких мест» – это слабый менеджмент знаний, процесс их передачи от одного человека другому. Решение на самом деле одно: выявлять таких людей, стараться как можно больше собирать информацию от них, выводить эти данные в твердотельный накопитель, переводить на бумагу, в компьютер.
Это сложный процесс. Во-первых, надо найти людей, которые собирают в себя долгое время знания, выявить их. Здесь может помочь выстроенный, более или менее автоматизированный процесс в рамках управления процессами. Если в типовой бизнес-задаче ты постоянно обращаешься к какому-то одному человеку, то значит, этот человек и является «хранителем знаний» для этой задачи. Это так называемое слабое звено с точки зрения процессов. Надо, чтобы процессы были более предсказуемыми, чтобы были какие-то метрики, и решения основывались на правилах, а не на мнении одного человека. Если у нас есть программа, она менее уязвимая к случайностям. Она тоже может «потеряться», но на текущий момент клонировать программу проще и дешевле, чем человека. Поэтому слабые звенья в процессах надо убирать, а сами процессы автоматизировать, делать более предсказуемыми.
– Ганс-Юрген Циммерман, немецкий, кстати, экономист и инженер, писал, что не существует универсального механизма формального описания областей знаний с высокой степенью неопределенности, поэтому нужно подстраиваться под конкретные задачи. Согласны ли вы с тем, что нам никогда не удастся решить эту проблему?
Может, нам и не удастся создать сильный автоматизированный интеллект, который сможет принимать решения в рамках нечеткой логики. Это очень сложные моменты...
Возьмем пешеходный переход. Как люди переходят дорогу? Они видят, что горит зеленый, идут, а если красный – стоят. Но если красный горит уже 5 минут, они понимают: что-то не так, надо что-то делать. Человек может выдержать 5 минут, но через 10 минут он подумает, что надо идти, потому что светофор просто сломался. А попробуйте описать все это роботу. Он же будет стоять и ждать зеленого. Поэтому ему надо прописать, где граница, когда можно идти, а когда – нет. Например, задать, что через минуту идти можно, даже если горит красный, а до того, как истечет минута, – нельзя. Человек может определить эту границу самостоятельно, исходя из своего опыта, из того, сколько рядом машин. Описать эти моменты нечеткой логикой в каких-то универсальных решениях невозможно. И вопрос со светофором – это бинарная логика: горит – не горит. Это еще более-менее просто формализовать. А есть гораздо более сложные вещи.
Но когда мы говорим про автоматизацию бизнеса, то он, как правило, все-таки строится не на интуитивных вещах. Естественно, когда речь о принятии каких-то стратегических решений, там, может, и интуиция сработает. Представьте, сидит директор некой корпорации, с ним за столом три-четыре человека, они пытаются заключить сделку о покупке компании стоимостью 100 млн долларов. Как такое решение принимается? Наверняка, сначала компанию изучили, проанализировали ее деятельность, подсчитали, какие будут выгоды. Вроде, все нормально. Но в любой момент директор может сказать, что ему все это не нравится, и он передумал. Отказался, просто потому, что у него чуйка сработала, он почувствовал, что что-то не то. Как это объяснить? Невозможно! Просто интуиция сработала.
– А что для вас – интуиция?
Сложно сказать. Это просто некий инсайт со стороны подсознания, когда по каким-то неявным параметрам или сигналам оно срабатывает и подсказывает, что здесь что-то не в порядке. Мы говорим про интуицию больше на бытовом уровне, а не в автоматизации. Но если вернуться к вопросам бизнеса, то на нижнем и среднем уровне это процесс более или менее логичен. То есть мы можем достаточно логично выстроить быстрые процессы, алгоритмами все это описать. Но чем выше поднимаешься, тем эта алгоритмизация теряется. У автоматизации есть границы. И не то чтобы она там теряла смысл, она просто либо становится слишком дорогая, либо слишком сложная. Но это – про самый верхний уровень управления.
Я могу, конечно, ошибаться, но мне кажется, что когда речь идет о стратегическом управлении, автоматизация может быть только на уровне сбора данных, как поддержка принятия решения. Но какого-то универсального алгоритма, который определяет, как мы принимаем решение о покупке компании по перечню параметров, невозможно придумать. Это все равно будет все исходить из видения развития бизнеса, каких-то предположений о движениях рынка. Невозможно же алгоритмизировать или собрать как-то в базу данных информацию о том, что руководитель был на встрече директоров и там где-то услышал краем уха, что планируется покупка какого-то завода. Этот контекст невозможно алгоритмизировать.
– Если бы речь шла только о бизнесе. Но все гораздо сложнее, например, при запуске боеголовок…
Да, это вообще абсолютные вещи, которые до конца не детерминированы. Могу согласиться, что есть большое количество непредсказуемых вещей. Сильный автоматизированный интеллект еще не появился, но, насколько я могу судить, это пока и не нужно. Мы все равно находимся на том этапе, когда 90% проблем, которые у нас есть, можно решить с помощью четкой логики. И когда мы говорим про четкую логику, там достаточно маленький пласт проблем, которые в автоматизации бизнеса встречаются. Понятно, что есть бизнес, который построен на вещах, использующих нечеткую логику. Но это отдельная тема, и это уже автоматизация конкретных преимуществ компании.
– А как вы себе представляете автоматизацию с помощью нечеткой логики? Это применимо, если говорить про корпоративное обучение, например?
В обучении можно говорить о четких вещах, потому что можно придумать какие-то алгоритмы. Например, перед тем как человек приходит в компанию, можно проверить уровень его подготовки по опроснику. Найти его слабые и сильные стороны и предложить некие курсы для повышения компетенций. В принципе, тут все алгоритмизируется.
– В этом году наша конференция с приставкой Education, поэтому такой вопрос: если бы вы могли вернуться на несколько минут в студенческие годы, какой бы вы дали себе совет, зная, что будете работать айтишником и 1С-разработчиком?
Возможно, я посоветовал бы себе поменять вуз. Но, скорее, мой главный совет самому себе 15 лет назад – не идти по пути наименьшего сопротивления. Когда я поступал, я мог выбрать любой факультет и любую специальность. Я поступил в Уральский государственный технический университет в Екатеринбурге – пошел по легкому пути. Университет был вблизи моего дома, в 10 минутах, не надо было никуда ездить, я хорошо знал кафедру, специальность казалась подходящей – «Прикладная информатика в экономике». Но, несмотря на то, что я в принципе доволен своим обучением, думаю, оно могло быть более сильным, если бы я учился, например, в МГУ или МФТИ. Именно с точки зрения ИТ – хотелось бы большего от университета.
Однако еще раз повторю, главная ошибка – я шел по пути наименьшего сопротивления. И это было не совсем верно. И сейчас бы, наверное, я порекомендовал себе самому следующее: если у тебя есть возможность и надо сделать выбор, надо брать сложное. Это будет тяжелее, но если ты не примешь это решение, то не поймешь, сможешь ты это сделать или нет. И если все получится, то ты молодец. А если не сможешь, ты тоже молодец, потому что попробовал. Получается, когда ты идешь по какому-то сложному пути, ты в любом случае в выигрыше. И с точки зрения того, что ты попробовал, и если получится, ты молодец, и если не получится – все равно молодец, потому что приобрел огромный опыт, даже если он отрицательный. Может, что-то не получилось, но ты попытался, и это уже круто.
– Алексей, спасибо вам за беседу!
Подкаст интервью с Алексеем Королевым
Уважаемые читатели! Приглашаем вас стать спикерами нашей рубрики и дать интервью, в котором вы сможете поделиться своим профессиональным опытом, историями успеха ваших компаний и высказаться по широкому кругу вопросов из сферы ИТ и 1С-разработки. Просто обратитесь в редакцию Инфостарт: dkochergov@infostart.ru, +7(812)309-06-46, доб. 138.