В гостях — Алексей Лустин
Ведущий — Сергей Горшенин
Дорогие друзья, я приветствую вас в студии программы «Готовые решения». Представляю нашего гостя – это человек с двадцатилетним стажем работы в области информационных технологий, айтишник, технический директор и просто хороший человек. Наш сегодняшний гость — Алексей Лустин.
Здравствуй, Сергей. Здравствуйте, коллеги.
______________________________________________________________________________________________________
Хронологическая справка
Лустин Алексей Александрович родился в городе Анадыре в 1980 году, учился в Воронежском Техническом Университете по специальности «Инженер САПР». С 1995 года — IT-специалист. Начинал как программист-внедренец 1С в городе Липецке, занимался автоматизацией бизнес-процессов в сети Уютерра. С 2008 года — ведущий специалист Java, Rails. В 2008 году переезжает в Москву. С 2012 по 2014 год — заместитель начальника отдела инновационного развития и системного анализа в ГК «Связной». В настоящее время является техническим директором, тренером, архитектором-консультантом компании «Серебряная пуля».
Алексей, для начала я предлагаю тебе немного рассказать о себе, чтобы обозначить то, о чем мы будем говорить в дальнейшем.
Это достаточно сложно, как и любое начало. Если коротко, то о себе я говорю в таком ключе, что родился я на Чукотке, далеко-далеко, рядом с полярным кругом. IT занимаюсь лет с 12, то есть, на самом деле не 20, а по-моему, уже 22 года. Прошел путь от обычного заправщика картриджей, оператора по заполнению приходных накладных, до архитектора, технического директора и так далее.
Как я его прошел? Здесь, наверное, нужно рассказать длиннее.
Я приехал с Чукотки в 97 году, чтобы поступить в институт, потому что основная плеяда хороших преподавателей была сосредоточена в центральном регионе, а не на Дальнем Востоке. Может быть, еще в Новосибирске, но в целом на тот момент качественное образование в сфере IT можно было получить в технических городах – либо в Москве, либо в Воронеже, либо, конечно же, в Санкт-Петербурге. К сожалению, на Дальнем Востоке такого не было. Чтобы обеспечить себя деньгами, а время было тяжелое, я брался за любую работу по IT. Это и администратор компьютерного клуба, и сборщик компьютерной техники, и разработчик 1С, как ни странно, еще на старой-старой версии. А еще я пробовал свои силы как разработчик на Java, когда она только начинала развиваться, и как разработчик баз данных на Clipper, кто ещё помнит такие вещи. По тем временам это было достаточно весело.
А после окончания этапа студенчества уже началась серьезная жизнь, и там я прошел другой путь: был и программистом, и менеджером проектов в зависимости от того, какова была глобальная цель тех работодателей, на кого я работал (владельцев бизнеса, IT-директоров или IT-руководителей в целом).
Ну а потом, в Липецке, я работал в компании Уютерра — это достаточно большой российский холдинг, объединяющий в себе сеть магазинов непродовольственных товаров – на тот момент там было порядка 112 супермаркетов от Благовещенска до Калининграда.
Чуть позже, в порядке своего собственного развития, я по собственной инициативе переехал в Москву, поближе к грандам нашей отрасли, чтобы действительно получить опыт и поделиться своими подходами. Так я попал в «Связной» и проработал там порядка 4 лет. Я там был и ведущим программистом, и внутренним техническим лидером, в последний год моя роль в компании называлась «Центр компетенции по 1С». Чтобы вы понимали, там около 200 специалистов по 1С.
Ну, зная Связной, я понимаю уровень, да.
Да. Вот такой жизненный путь. С точки зрения моего личного к нему отношения.
Итак, в 95-ом году ты начинал IT-специалистом. Как ты считаешь, отличается ли модель IT-специалиста 95-го года от IT-специалиста 2015-го?
Вообще ничего не поменялось, на мой взгляд.
А как же изменения в парадигмах, в концепциях, в развитии технологий?
Парадигмы не изменились. Все парадигмы, на которых мы сейчас паразитируем, придуманы четверкой авторов – это Брукс, Вирт, Уорд и Хьюдак. Они, собственно, и придумали эти парадигмы в 93-94х годах (я не говорю про инженерию программного обеспечения, которая придумана в 70-ых). Все, что сейчас происходит с технологиями, заложено именно там. Ничего не меняется. С другой стороны, растет только практика применения этих парадигм, то есть IT-специалист, начинавший в 95-м году, имеет, условно, 20 лет опыта применения этих парадигм. Это единственное его конкурентное преимущество по отношению к человеку, начинающему в 2005-м. Просто человек, начинающий в 2005-м, имеет 10 лет практики. Вот и вся разница. А парадигмы одни и те же.
Хорошо. А давай вспомним 95-ый год. Всё-таки айтишники тогда — это люди, которые любили IT, они приходили в эту сферу в 12, в 15 лет… Не секрет, что сейчас некоторые из айтишников выбирают IT только потому, что это модно.
Да, сейчас действительно большая мода на IT. Но и тогда выбирали, потому что это было модно. Например, можно вспомнить «бум доткомов» 2000 года, который затронул и Россию, потому что и тогда была мода на IT. Да и за 3 года до этого, в 97-м, мода на инженерные специальности тоже была очень большой.
Объясню почему. В России на тот момент была вообще нехватка специалистов по IT любого характера. За хорошего IT-специалиста готовы были платить большие деньги. За юристов, экономистов уже не готовы были платить, а за IT готовы. Это было достаточно интересное время. Если вспомнить, что в 93-м году проходной балл на инженерные специальности был 9 — три тройки, то в 97-м году на инженерные специальности, связанные с IT, проходной балл уже был в районе 14-15 – одна четверка, две пятерки. Это показатель. И, по-моему, этот проходной балл до сих пор не снижается. Что в начале двухтысячных, что сейчас проходной балл и требования к IT-специальностям остаются на уровне 97, 98, 99-х годов.
С другой стороны, и тогда в IT шли в том числе за модой. Поэтому сейчас многие из тех, кто начинал тогда, уже больше не IT-специалисты. Часть из них бизнесмены, кто-то стал экономистом, кто-то ушел.
Там остались не те, кто пришел за модой, а те, кто действительно это любил. И если мы видим IT-специалиста с десятилетним стажем, то он, скорее всего, прошел через все кризисы этого роста – 1, 3, 5 лет. Как в семейной жизни – ты женился на IT, потом через год понял, на ком ты женился, через 3 года вы поссорились, а через 5 лет вы наконец-то достигли некого такого «дзена», когда вы понимаете, что вам друг от друга надо.
Такая философия.
У тебя довольно интересный опыт, но при этом по тебе не скажешь, что ты – айтишник, хотя ты сам упорно на этом настаиваешь. Почему?
У меня есть два тезиса, которые отражают мой опыт и вообще общую концепцию того, что я за специалист: это Overskilled – так называемый «перебор по навыкам» (их слишком много), и одновременно Troubleshooting – это «человек – решатель проблем». Я обычно говорю, что я могу решить любую проблему в IT. За счет опыта, за счет методики, за счет выработанных алгоритмов – вообще любую. Потому что любая проблема может быть решена. Неважно, связана эта проблема с 1С или не связана. Не может быть нерешенных проблем. Это первое.
Так как я с таким подходом живу очень давно, ты представляешь, какое количество проблем я уже решил? Именно поэтому, собственно, у меня перебор по навыкам. Я могу решить проблему с Ruby, с С++, с Ассемблером даже могу, если будут проблемы. С 1С, естественно, с бизнес-приложениями, с приложениями, написанными сторонними разработчиками, с OpenSource, Commerce приложениями. Я все это уже просто пережил. Учет картриджей? Да, пожалуйста.
Тогда у меня возникает встречный вопрос. Моя карьера началась в далеком двухтысячном, причем я начинал именно с 1С. Но спустя 6-7 лет я перестал быть одинэсником в прямом смысле этого слова, хотя, наверное, где-то в глубине души я до сих пор еще программирую на семерке. Но почему ты с таким богатым техническим опытом до сих пор еще считаешь себя одинэсником?
На самом деле я обычно называю себя специалистом по бизнес-приложениям. А в России, да и не только в России, создавать бизнес-приложения без платформы 1С невозможно.
Можно ли сказать, что в данном случае 1С — самая распространенная платформа для создания бизнес-приложений, по крайней мере, в России?
1С — это реализация концепций проблемно-ориентированного языка. Давай вернемся опять в 95-й. Была проблема. Бизнесов стало много. Вот представь, сколько конфигураций сейчас в России, написанных с нуля, не беря в расчет типовые. То есть де-факто мы можем говорить, что каждый 1С-специалист написал свою конфигурацию с нуля. Плохую, хорошую — не важно. На портале INFOSTART.RU сейчас зарегистрировано 450 тысяч активных пользователей, 1С-специалистов, то есть мы можем говорить, что каждый из них написал свою конфигурацию.
Знаешь, далеко ходить не буду, у меня, например, 4 полноценных программных комплекса. Это не считая мелких наработок и отчетов.
Я обычно сторонник говорить, что сколько специалистов 1С, столько нетиповых конфигураций 1С, написанных с нуля. А сколько в России бизнесов? Их гораздо больше.
Наверное, все-таки моделей бизнесов?
Да, моделей бизнесов. Чаще всего архитектура бизнеса прямо пропорциональна архитектуре команды, создающей этот бизнес. Не бывает одинаковых бизнесов и одинаковых процессов тоже не бывает. Даже если они базируются на одних и тех же принципах, конкретная реализация всегда разная. Надо с этим смириться.
Откуда вообще родилась платформа 1С и ее язык для разработки бизнес-приложений? Все это появилось в ответ на проблему, которая заключалась в том, что в России рос бизнес – происходил переход от старого строя к новому: появлялось много мелких предприятий, рост был очень бурный. Возникло много маленьких бизнесов. Они не могли все работать по «шаблонным» бизнес-практикам («бестпрактиксам»).
Тогда таких практик еще и не было как таковых в России.
Да, и консалтинга как такового для этого рынка еще не было. Но уже нужно было как-то работать.
Появилась потребность в языке для быстрого описания бизнес-процессов. Потому что ни в одной платформе вы не найдете языка, на котором можно писать «Документы.ПриходнаяНакладная.Провести()» (зарегистрировать, распечатать, послать на принтер, зачесть продажу и так далее). А это нужно было описывать.
Условно, идея была в том, что даже бухгалтер сможет описать свой бизнес-процесс. Это не совсем сработало – все равно потребовались специальные люди, которые обладают алгоритмической базой, и могут описывать бизнес-процессы на специальном DSL-языке (проблемно-ориентированном языке). Но таким образом можно было сократить расходы и быстро автоматизировать любой бизнес из 5-10 человек.
По сути, таким образом экономилось время и затраты на создание этих базовых классов, базовых моделей, потому что они по факту уже были.
Да, это был огромный скачок. Дело в том, что на тот момент, в 95-м году, основным языком разработки бизнес-приложений был C++, который обладал низким уровнем абстракции.
Тогда еще на Clipper очень многое писалось, насколько я помню.
Clipper – это тоже был слишком низкоуровневый язык. Тогда только-только появлялась Java, как некий фреймворк, который поднимал уровень абстракции. Но он поднимал этот уровень только на один этап вверх – позволял компонентную модель строить, а 1С прыгнула прямо через 5 уровней наверх, сразу на уровень бизнесмена. Даже теперь, по прошествии 20 лет, ни за рубежом, ни в России до сих пор нет подобного языка, который позволял бы описывать бизнес-процессы напрямую.
Сейчас у банков есть попытки создать язык для автоматизации трейдеров и описания их алгоритмов в неком DSL-языке – они пытаются подобное в Java-мире (или, точнее, в функциональном мире) сделать. А у нас такой язык, условно, существует уже 20 лет, поэтому мы здесь в выигрышном положении. И вряд ли в ближайшее время там появится язык такого же уровня, позволяющий настолько же эффективно нивелировать работу системы на базовых уровнях, чтобы можно было на первом этапе не останавливаться на проблемах с кодом, с памятью, чтобы сразу можно было думать о пользе бизнесу.
Вспомни, для чего придумали Agile? Для того чтобы разработчики на сторонних платформах начинали задумываться о пользе для конечного пользователя. Не делали космические алгоритмы управления памятью, а думали, как эти алгоритмы могут быть полезны бизнесу. Не бизнесмену в рубашке (собственнику, который в это деньги вкладывает), а конечному пользователю — кладовщику, оператору, бухгалтеру.
Есть еще такой момент: как обосновать для бизнеса необходимость оптимизации какого-то алгоритма для того, чтобы выиграть полтора мегабайта памяти? На С++ доказать технико-экономическое обоснование такой оптимизации для бизнеса почти невозможно. А одинэснику с этим проще, его задачи приближены к бизнес-целям, поэтому он может объяснить, что станет быстрее, что улучшится (причем саму оптимизацию по памяти он может реализовать как раз с помощью С++).
И если вернуться к тому, почему я себя считаю 1С-специалистом — я всегда работаю с бизнесменами. Изначально, еще 20 лет назад, я начинал в Фонде обязательного медицинского страхования. Моей первой задачей была автоматизация сбора платежей по ОМС. Моим первым заказчиком был руководитель этого Фонда ОМС, он объяснил стратегическую бизнес-цель: зачем ему это надо и так далее. А техническая реализация и связанные с ней технические риски были полностью на моей стороне – выбор платформы, будет ли это Access, Clipper и так далее, полностью ложился на меня.
Это была моя первая задача – мне на тот момент было 15 лет и специалистов в нашем городе по базам данных вообще просто не было. Кроме меня и Андрея, моего коллеги — хорошего С++ программиста. И еще у нас в команде был «старший товарищ», радиотехник лет 35 – он нам объяснял, как все технически реализовать, и потом «причесывал» сделанное. А мы, молодые ребята, взяли стратегическую цель человека, который отвечал за все окружное обязательное медицинское страхование, и попытались это реализовать. Плохо, хорошо, с ошибками — уже не имеет значения. Наверное, если он нас сейчас увидит, то скажет, что мы все там сделали плохо. Но это нормально.
Можно ли сказать, что это он за вас тогда решил, что вам надо развиваться, что, поставив свою цель во главу вашей работы, он дал вам толчок к дальнейшему развитию?
Да, конечно, на нас тогда сильно повлияло то, что он в нас поверил. Мы были молодые парни-десятиклассники, на олимпиадах побеждали, такие айтишники до мозга костей – но, по факту, мы были пацаны без опыта работы. А он рискнул и дал нам возможность попытаться что-то сделать. И мы старались, да. Ради того, чтобы быть рядом с компьютерами и вообще быть рядом во всем. Это была такая хорошая мотивация.
Я помню начало своей карьеры – это был Водоканал, там был 1С. Я застал 1С под DOS версии 2.0, потом переход на 7.5, на 7.7. Но когда я начал писать что-то под 7.7, я очень быстро понял, что мне не хватает того самого бухгалтерского бэкграунда. Я тогда пошел на трехмесячные курсы, и вот это для меня, наверное, с одной стороны, послужило толчком к дальнейшему развитию, а с другой стороны – послужило неким щелчком к тому, чтобы я от программирования начал двигаться дальше, уже вглубь бизнес-процессов. Не получится ли так, что IT-специалисты, которые пишут программы или приложения под различные бизнес-задачи, будут двигаться к тому, чтобы уйти от программирования и перейти в смежные плоскости, на другие платформы, под другие задачи или в другую область вообще?
Да обычно так и происходит. Мир делится. Сначала у тебя просто есть какие-то навыки программирования. Ты можешь писать на Pascal, на С++ что-то, какие-то алгоритмы. Это базовый навык – на этом этапе опыта работы с бизнес-задачами у тебя еще нет. Но вот тебе попадает 1С-платформа. Ты пробуешь решать бизнес-задачи с помощью нее, пропускаешь это через себя и возникает твой первый уровень. А что дальше — ты сам решаешь. Можешь уйти в бизнесмены — такое случается. Возможно, ты просто поймешь, что IT — это не твое.
Ты можешь уйти в бизнес-методологи (или иначе это называется аналитик-методолог). Это не тот, кто описывает методологию, а тот, кто пытается быть связующим звеном между разработчиками (теми, кто создает какой-то продукт), и бизнес-заказчиками. Это какой-то аналитик, который изучает бизнес-процессы, пытается найти скрытые требования, и, возможно, привлекает внешних методологов.
Это, наверное, что-то близкое к архитектору?
Нет, это больше относится к системному анализу. Архитектор — он компонентные модели строит, а этот специалист – своеобразный проектировщик, он больше занимается анализом того, как именно нужно построить конечную модель.
Так или иначе, ты начинаешь специализироваться. Ты можешь в этот момент захотеть уйти из 1С-мира, потому что вдруг решишь, что сам все сможешь спроектировать на каком-то низкоуровневом ПО. Берешь, например, Java, так как она бесплатная, и начинаешь что-то на ней проектировать. В итоге люди либо начинают заниматься чем-то другим, либо, что происходит чаще всего, возвращаются обратно к 1С, но уже с другим знанием.
Количество опыта прямо пропорционально количеству совершенных по мере роста ошибок. Это такая особенность. Поэтому в итоге ты все равно в большинстве случаев возвращаешься в 1С мир. Может быть, в другом качестве – например, как бизнес-заказчик, или как главный архитектор, посматривая на 1С со стороны, но все равно с ней работая. Потому что 1С – это платформа автоматизации бизнес-процессов, и ты никуда от нее особо и не уходишь.
А как же насчет репутации одинэсника? Я помню, когда я начинал, надо мной многие мои однокурсники посмеивались. Дескать, вот мы программируем на нормальных полноценных языках, а ты программируешь на языке, который мало того, что сделан на С, так еще и пишется по-русски.
К сожалению или к счастью, у меня в работе было множество команд, которые не одинэсники. Я вообще иногда считаю себя помимо 1С-специалиста еще и специалистом по Ruby on Rails и по Java – так сложилось, что у меня есть опыт написания приложений на этих фреймворках. Но там есть другая проблема. Люди, которые пишут на .NET, на Java, на чем угодно, они слишком далеки от народа. Они не автоматизируют бизнес. Они пишут некие компоненты для бизнеса, а точнее компоненты для тех программистов, которые из этих компонентов потом будут строить бизнес-приложение.
По сути, они строят кубики, из которых дальше уже кто-то будет выстраивать конечный продукт.
Да, именно так это и работает. Ведь мы никогда не задумываемся о том, что есть люди, которые пишут на Ассемблере программы, реализующие логику микросхем. А там же тоже есть внутренние алгоритмы – различные южные, северные мосты.
Давай проще. Вот мы каждый день управляем мышкой, мы не задумываемся, каким образом движение мышки передается на экран.
Да, где-то есть люди, которые программируют микрокристаллы внутри микроконтроллеров. Есть специальность «Физическая химия», где учат работать на уровне микроконтроллеров, программировать там. Для них 2 байта — это много. У них там память не гигабайтами меряется, а байтами. Эти люди отдают свои готовые компоненты другим людям, которые уже описывают работу с устройствами на чем-то более высокоуровневом, например, на С++. Потом еще какие-то люди берут эти компоненты, написанные на C++, и делают из них свои приложения, компоненты или библиотеки – уже на .NET или на Java, или еще на чем-то. А потом приходят одинэсники, берут эти компоненты и делают из них конечное бизнес-приложение. Так это и работает.
Давай вернемся к одинэсникам. Можно ли сказать, исходя из твоих слов, что возникает некое противоречие, что ты, с одной стороны, не хочешь быть одинэсником, но тебе приходится.
Надо быть одинэсником, но не надо быть одинэсником. Вот так звучит противоречие. Для удобства понимания надо просто убрать слово 1С. 1С — это ЗАО «1С», это фирма, которая развивает, которая вкладывает и деньги, и методологию внутрь этой платформы. Надо быть специалистом по автоматизации бизнеса, но не надо быть специалистом по автоматизации бизнеса. Напоминает шизофрению. Но в целом ты просто должен научиться переключать тумблер.
Вот когда ты общаешься с бизнес-заказчиком, твоя задача – ни в коем случае не обсуждать с ним какие-то технические моменты — технические долги, техническую архитектуру. Заказчик не знает, как тебе выстроить кластер — горизонтально или вертикально, как тебе выстроить стойки и так далее. Он тебе говорит некое пожелание. Обобщенно, заказчик хочет получить какое-то предполагаемое визуальное поведение формочки в целом. Если, конечно, это не заказчик, который заказывает у тебя компилятор.
… Скажем так, если твой заказчик — это представитель бизнеса, а не представитель IT-отрасли.
Да. Мы говорим о конечном бизнесе. Я просто очень много работал именно в конечных отраслях, то есть занимался конечной автоматизацией. Это достаточно сложный процесс – там нужно научиться переключать тумблер, чтобы специализироваться на бизнес-платформе – например, быстро отстроить прототип, если надо экспериментировать с проектами. Это свой навык.
Но когда ты возвращаешься в свой внутренний IT-мир, тебе нужно переключить тумблер обратно, и там ты уже не должен быть одинэсником, специалистом по бизнес-платформам. Ты должен быть просто специалистом по разработке. И там ты уже забываешь, что это 1С – у тебя просто есть язык, есть компоненты, есть алгоритмы (теория алгебраических множеств, например) и так далее. Там ты уже вспоминаешь все, чему тебя учили в институте, если он у тебя, конечно, был профильный.
Хорошо. Давай вернемся к репутации 1С-специалистов. Какова, на твой взгляд, репутация одинэсника у бизнеса?
У бизнеса отличная. Только 1С-специалист может на спор за двое суток автоматизировать полфирмы, условно. Пусть коряво накидать прототип, но в который можно запустить уже кладовщика и пользователя. Он начнет ругаться, но в целом он уже начнет генерировать какие-то данные, уже будет польза. То есть скорость запуска 1С-решений высокая.
Но это, скорее, заслуга платформы?
И специалистов, которые знают, как все это запустить. Поэтому репутация 1С у бизнеса в целом хорошая. Когда мы только начинаем запускать бизнес, он привыкает к тому, что мы все для него делаем очень быстро. Условно – мы прототип запустили, а теперь нам надо массово запустить всю компанию. Естественно, качество такой первоначальной автоматизации близко к нулю, но сам по себе прототип работающий. И когда мы дальше пытаемся переключиться на то, чтобы повышать качество самого решения, то здесь мы уже начинаем терять репутацию у бизнеса, потому что перестаем его удовлетворять.
То есть мы ему дали 80%, например, за 2 дня, а оставшиеся 20% мы доводим до ума несколько месяцев. Его это уже не устраивает.
И вот тут возникает дилемма. За репутацию приходится бороться. Бизнесмены, на самом деле, очень любят 1С: она быстрая, недорогая, можно запуститься «на коленке», на маленьком компьютере под столом. Если вы запускаете прототип на 10 пользователей, то там, по-серьезному, даже сервер не нужен.
1С позволяет осуществить быстрый запуск. Для бизнесмена это понятно. Существует такая парадигма: чем полгода считать технико-экономическое обоснование одного проекта, проще 100 неуспешных проектов запустить за это же время, понести эти затраты, и один из них вдруг выстрелит. Для бизнеса эта модель успешней, поэтому 1С-ники для них очень важны. По этой же причине большинство специалистов по 1С чаще всего приближены к центру финансовой ответственности. Не к ключевым пользователям, а к людям, владеющим бюджетами.
Ты имеешь в виду бухгалтерию, финансистов?
Да. Тех, кто владеет бюджетами на автоматизацию. Вплоть до коммерческого директора. В моей практике 1С-специалисты чаще всего завязаны либо на коммерческого директора, курирующего IT, либо на главного логистического специалиста (на того, кто отвечает за оперативную деятельность всего предприятия) — то есть, напрямую на топ-менеджера, минуя средний уровень руководителей. Это обычная практика в конечном бизнесе.
Они, по сути, на разных уровнях абстракции работают.
Да. 1С-специалисты не хотят спускаться вниз, не хотят разбираться в технических деталях, а специалисты по другим платформам не хотят подниматься до бизнес-целей. Консалтинг в соседних платформах пытается научить .NET-чиков любить бизнес, а мне приходится учить одинэсников любить IT, то есть совершенно наоборот, хотя принцип ровно тот же.
Но если с «чистыми» разработчиками у нас ситуация понятна, остается вопрос по поводу типовых одинэсников: почему их это устраивает? Ведь в результате получается, что, помимо того, что они хорошо относятся к бизнесу и любят его, они должны еще и любить своих смежников. Как они на это смотрят?
По-разному. Во-первых, там ключевой момент, что все одинэсники врут. Им удобнее быть одинэсниками, понятнее, спокойнее.
Последние лет 10 мне приходится проводить собеседования на внутренние вакансии. Пообщавшись с большим количеством 1С-разработчиков, я отметил интересный момент: большинство из них говорят, что они именно специалисты по 1С, хотя по факту 80% разработчиков 1С имеют в запасе знания по какому-то второму языку – это может быть Android, может быть Clojure функциональный, но они это не афишируют. Возможно дома, возможно вечерами. JavaScript, HTML. L на конце HTML означает language — язык.
Одинэсник является специалистом по конечной автоматизации бизнеса, а это подразумевает под собой знание не только 1С. Поэтому когда одинэсник говорит, что он только одинэсник, он врет, потому что он обязан работать с XML в последней 8 платформе. Если он работает с веб-сервисами, то язык WSDL (Web Services Description Language), это тоже L — язык. Он не может говорить, что он только специалист по 1С, но ему удобней называться одинэсником, потому что тогда ему дают одну платформу, не лезут в его маленький мирок и дают спокойно заниматься автоматизацией. Поэтому до последних пор большинство людей в этом смысле все устраивало.
Сейчас, последние года полтора я замечаю, что одинэсников такое положение дел уже не совсем устраивает, потому что потребности бизнеса растут, да и разработка в основном начинает требоваться тогда, когда бизнес рассчитан уже не на 5 пользователей.
Если 5 пользователей, то не обязательно нанимать разработчика – можно взять какое-то готовое типовое решение или какой-то облачный продукт, работающий в режиме сервиса. Сейчас, последние 6 лет, чтобы быстро стартовать бизнесу, достаточно взять типовой облачный сервис, заплатить операционные затраты баксов 20 в месяц, и все, можно думать о цели своего бизнеса. На первом этапе (примерно первый год) разработчики не нужны.
Разработчики становятся нужны, когда бизнес уже развивается, выходит на использование передовых технологий, требует доработок высокого уровня. Поэтому последние полтора года я замечаю, что одинэсники начинают задумываться о дальнейшем росте, доставать из загашников свои знания, начинают учить Python, .NET, 1С плюс XML, 1С плюс HTML… Я, например, специалист 1С плюс Web. Если просмотреть присланные резюме, у большинства кроме 1С написана еще какая-то платформа. Чтобы как-то специализироваться, что вот я для бизнеса делаю не только 1С, но еще какую-то особую «штучку».
Нельзя забывать о том, что есть статья Сергея Нуралиева, опубликованная в феврале 2014-го – он там определил, что одинэсникам недостаточно оставаться просто одинэсниками, необходимо развиваться дальше и специализироваться. Там перечислены шесть основных направлений развития для 1С-специалистов (аналитик, разработчик, эксперт по оптимизации, специалист по юзабилити, специалист по новым направлениям разработки и руководитель проекта). Поэтому, когда мы говорим «типовой одинэсник» — это мем из двухтысячных годов. Их больше нет. Они вместе с «семеркой», наверное, и умерли.
Я могу сказать, что по PHP специалисты тоже, кстати, не подарок совершенно и качество у них страдает. Но их все устраивает, потому что столько всего написано на этом РНР, что, казалось бы, можно с этим дальше спокойно жить. Но сейчас там тоже уже везде используется Node.js или Ruby on Rails, куда уже без него. И РНР специалистам тоже становится плохо, и они начинают перепрофилироваться, куда-то уходить… Это текущий тренд.
А если вернуться к тому, о чем ты говорил – про разделение разработчиков «чистых» и 1С-разработчиков. Как сделать так, чтобы не было двух отделов, был один отдел, и при этом одни с другими дружили и жили в мире и согласии?
У каждой из этих двух сторон свои законы – профессиональная разработка на промышленных языках с одной стороны и разработка на платформе бизнес-приложений с другой. Разработчики 1С живут по методологии компании «1С», которая опубликована на ИТС, описана в желтых книжках и так далее. А разработчики .NET, Java, Phyton живут по своим книжкам. Для того чтобы объединить и тех и других, пришлось их спустить в 95-й год, и показать им четыре книжки тех авторов, про которых я уже упоминал (Брукс, Вирт, Уорд и Хьюдак).
Это реальный случай из моей практики, когда двум командам разработчиков дали почитать книжки про основополагающие концепции программирования. Так получилось, что никто из них этих книжек раньше не читал – эта теория оказалась для них новой. И через две недели, когда они все это прочитали и сформулировали для себя в голове концепцию DSL языков, они начали спорить. На самом деле весь этот холивар был ни о чем. Священные войны, кто лучше: 1С или .NET, — вообще слишком затратно. Они просто под разные задачи заточены.
И сработал следующий ход. Выделили одного (максимум двух) специалистов .NET или Java на две 1С-команды по 5 человек. И эти двое (по одному на команду, взаимозаменяемые, две команды обеспечивают) – они помогают сократить количество технических проблем для 1С-команды, когда они борются с производительностью в рабочей базе, и получается, что они друг другу помогают.
То есть дотнетчик скрыт от бизнеса, ему позволяется заниматься своими космическими вещами, а одинэсники не подставляются перед бизнесом, потому что у них бекэндом есть специалист на высокоуровневом языке, который нивелирует их технические просчеты. Вот так это и сработало – получилось хорошо.
Бывало, что кто-то из одинэсников приходит к этому дотнетчику (назовем его Сергей к примеру) и говорит: «Сережа, научи меня .NET, я хочу попробовать». И тот его учит. А Сергей, как показывает практика, тоже рано или поздно спросит: «Слушай, расскажи мне про 1С, чего здесь происходит?» И в итоге одинэсник учит особенностям 1С-платформы дотнетчика.
А потом возникает восклицание: человек из 1С, который действительно хочет заниматься разработками и программированием, говорит: «Какая классная штука — .NET», но и .NET-чик в определенный момент говорит: «Какая классная штука 1С, 1С — рулез», я даже помню эту цитату. Вот так это и объединяется.
Я сейчас задам чуть отвлеченный вопрос. Вот ты технический директор, я IT-директор. Я вижу определенную разницу в том, как ты решил проблему в своем коллективе, и как я бы ее решил, потому что, например, из тех 4 книг, из тех 4 авторов, которых ты назвал, я читал только 2, ну и плюс, трехтомник Дональда Кнута тоже об искусстве программирования. Но на твой взгляд, если мы говорим об управлении командами, в чем разница между техническим директором и IT-директором? Ведь и один, и второй работают в области информационных технологий. По сути, это две смежных позиции, но разница в подходах очень существенна.
Я не очень люблю, когда меня называют техническим директором, потому что это, по моему мнению, только одна ипостась.
Разница между техническим директором и IT-директором только в одном: кто чем оперирует, базовые понятия. Для IT-директора базовым понятием является риск, который может быть пересчитан в деньги – то есть, IT-директор управляет рисками денежными, командными, психологическими и так далее. А я управляю противоречиями. А техническое (инженерное) противоречие — это понятие родом из изобретательства.
Вот ты никогда не думал, как создавались ракеты? Есть целый алгоритм, как создать изобретение, целая концепция — как разрешать противоречия. Изобретение нельзя делать революционно, нельзя допустить «застой», но нужна эволюция. Как ее обеспечить? Нужно управлять каждым противоречием, нивелировать его, повышать идеальность и так далее.
Я управляю противоречиями. Я не зря говорю: я решаю проблемы, потому что проблемы — это противоречия, когда что-то хорошо и плохо одновременно. Что-то, что невозможно выбрать одно из двух: «Надо быть одинэсником, но нельзя быть одинэсником» – вот, например, противоречие.
Поэтому разница между IT-директором и техническим только в базисном понятии: риск или противоречие. Но в целом подходы везде одинаковые.
Я вообще сторонник технократии, считаю, что технический директор, да и вообще любой управляющий персонал должен обладать техническим базисом. Я не могу по-другому считать.
Давай продолжим тему информации и технологий. Мы говорили о том, как сторонние разработчики могут помогать 1С-никам. А может ли быть наоборот? Могут ли 1С-ники помогать сторонним разработчикам и если да, то чем?
Да. Из практики: конторе, где я работал, внезапно оказалась нужна WMS – у них совершенно случайно образовался склад на 7 тысяч квадратов. Я тогда работал в «Уютерре», был там совсем не одинэсником, а разработчиком на Java, Ruby on Rails и даже немного на С++ писал драйвера. В качестве моего первого тестового задания директор Уютерры дал мне на месяц линуксовую консоль, принтер этикеток и сказал: «Вот тебе принтер этикеток (DZBZ2 Godex он назывался), напиши к нему адаптер, напиши драйвер».
Я напоминаю — я только что вышел из 1С, у меня только что закончилась эра, когда я в течение года пробовал совместно запустить свой франч – я только что был во франчайзи, и тут внезапно я становлюсь разработчиком на С++, причем должен писать под Linux. Что произошло с моим мозгом дальше – страшно вспомнить. В течение месяца мне пришлось вспомнить работу с памятью, работу с блочными устройствами и так далее… Но я не сдался. Это к вопросу о том, «как».
Была проблема. А я же говорил, что могу решить любую проблему. Мне нарисовали проблему: нужно автоматизировать работу китайской машины с неизвестным драйвером, имеющую описание на китайском языке. По факту, эту задачу можно было решить только методом подбора. И это мое первое тестовое задание, так я учился.
Так вот, тогда у этой компании, у «Уютерры», возникла потребность в системной работе со складом, и для этого им пришлось писать свою WMS на 1С с нуля. С нуля — это долго. Поэтому, чтобы быстрее запуститься, мы в содружестве с Андреем Межовым выступили неким тандемом. Андрей – Java-программист, достаточно известная личность, он на Инфостарте зарегистрирован, у него множество статей про интеграцию Java и 1С.
Так вот, я передавал ему свои знания по платформе 1С – рассказывал, какие платформенные 1С-ные объекты нужно брать для реализации конкретной бизнес-задачи (например, для инвентаризации и т.д.), а он получал быстрый запуск.
Конечно, он все равно кодировал на 1С-платформе в Java-стиле. Три месяца плевался – говорил, что это отстой и т.д. Но потом сказал, что «1С – рулез». Я не скажу, что я ему очень сильно помог, но мы здесь выступили тандемом, и он смог быстрее запустить бизнес-задачу. Не удивлюсь, если потом окажется, что он в процессе рефакторинга этой WMS-системы на 1С ее просто выкинул и написал потом новую с нуля. Но я ему помог быстрее понять контекст задачи, как работает складская логистика в торговле. Это довольно большая проблема. Понять, как работает кассир на кассе – не каждый дотнетчик сможет.
Да, это надо увидеть глазами и прочувствовать на себе.
Это типовая проблема, которую можно перевести в деньги – я обычно люблю деньгами, затратами людей убеждать. Когда приходится общаться с заказчиком, приходится деньгами мерить.
Типовая проблема: я прихожу к тебе как заказчик, и ты дотнетчик, или явер, или питонер. Я прихожу к тебе и говорю: «Мне на кассу нужно простое кассовое ПО». Обычно люди отвечают: «Сформулируйте бизнес-требование, напишите бумажку, тогда я начну». Что делает одинэсник: «Какие бизнес-требования? И так все понятно. Этой торговле 2 с половиной тысячи лет, все требования давно описаны. Значит, сейчас сделаем. Сколько денег дадите?» То есть, совершенно наоборот.
И мы, получается, полезны для дотнетчиков именно знанием методологии, бизнес-требований, мы можем спроектировать модель (первый концептуальный проект) и не тратить на это время.
Мне сейчас очень понравилось, как ты коснулся темы затрат. В последнее время — возможно, благодаря облачным вычислениям — очень часто стала проявляться такая ситуация, когда команду разработчиков выносят куда-то в регионы. Я, как IT-директор, вижу в этом, в первую очередь, снижение затрат. Какие плюсы и минусы видишь в этом ты, именно с точки зрения технического директора? Можно ли сказать, что от этого страдает качество кода? Или все-таки дело в затратах?
Качество от этого страдает точно.
Качество кода страдает однозначно?
Все страдает. Во-первых, когда у тебя сложнораспределенная команда, управлять этим почти невозможно. Единственный, кто умеет этим управлять – это, по-моему, Александр Белов. У него единственного опыт управления успешный.
У разработчиков такой команды должен быть особый психотип. Ты не можешь где-нибудь в Ижевске или Екатеринбурге нанять человека с характером стационарного разработчика. Тебе нужно искать совершенно другого человека, который сумеет работать в удаленной команде, отчитываясь перед «центром».
В распределенной команде затраты на управляемость в целом повышаются. Кажется, что ты экономишь на деньгах, на ФОТ (фонде оплаты труда) за счет того, что уходишь в регионы, но ты начинаешь терять на управляемости.
Когда ты строишь свою команду, тебе в любом случае нужно делать отдельный маленький отдел разработки методологический, обособленный, со своим руководителем, с офис-менеджером и так далее. Тогда это хоть как-то работает. Тогда этот центр затрат окупается, потому что он делает конечный продукт. Это из практики.
Если тебе кто-то говорит, что разработка в распределенной команде будет более выгодной, то они врут, они просто говорят, что по деньгам, по ФОТ это будет менее затратно. Но общий объем затрат — это называется общая стоимость владений – на удаленной разработке, скорее всего, получится более высоким. И дело здесь не в качестве, а в затратах, которые ты будешь нести.
То есть я правильно понимаю, что зачастую говорят о том, что прямые затраты — эти первоначальные инвестиции (если так можно сказать) будут меньше, но вот о косвенных, которые влияют на общие косты, — о них действительно либо забывают, либо специально умалчивают?
Обычно люди, когда выводят офис вовне, осознают ситуацию с косвенными затратами примерно так: ух ты, оказывается, косвенные затраты получаются гораздо выше, чем в той же Москве, в Питере или других центральных городах.
А есть разница между разработчиками простыми и разработчиками 1С именно с точки зрения удаленных компаний?
Из практики я не видел. Деньги разные, а процентовка та же.
На удаленном офисе тебе все равно понадобится «чемпион», стоимость которого будет раза в два выше, чем типовая средняя планка по зарплате. И в итоге тебе нужно будет это маленькое лидерство компенсировать за счет затрат на офис, может быть, даже сокращать затраты на маркетинг, бухгалтерию. Но иногда и бухгалтер нужен будет местный на всякий случай, или офис-менеджер. Практика такая.
Я ж сам выходец из регионов. Я же в Москве-то только последние года 4, а до этого меня помотало от Ростова до Пскова и даже в Сибири я, так получилось, был некоторое время. Я в основном, в регионах работал.
Хорошо. А если использовать какие-нибудь новомодные инструменты для групповой разработки в облаках, где все работают в одном месте и вживую не общаются?
Во-первых, для 1С мира это еще пока не создано. Есть наши попытки в содружестве с ребятами, специалистами по Linux, сейчас развернуть облачный конфигуратор – специальную систему для групповой разработки конфигурации в облаке с настроенным окружением, со всем инструментарием. Этот конфигуратор сейчас проходит внутреннее бета-тестирование. Может быть, удастся выкатить его в ближайшее время или сама компания 1С, возможно, сделает что-то подобное в перспективе.
Правильно ли я понимаю, что это просто некая виртуальная машина с запущенным конфигуратором, тогда вопрос — как там организован множественный доступ, как идет совместная разработка в нем?
Давай так, отделим мух от котлет. Убираем слово 1С. Инфраструктура разработчика в облаке — это большая проблема сейчас на всем рынке. В 1С, в Java, в .NET, в Java Script и так далее.
Сейчас есть такой концепт Vagrant. 1С: Битрикс его использует (только начал использовать). Это когда к тебе приезжает маленькая виртуальная настроенная машина с развернутым Битриксом – чтобы ты не тратил время, а сразу начинал кодировать. Точно так же ты можешь Битрикс развернуть у себя локально на виртуальной машине, или где-то в облаке – своем, если оно у тебя есть, или в частном – как угодно. В итоге мы оперируем этими маленькими виртуальными операционными системами, которые приезжают к тебе предустановленными и автоматически обновляются. Такой тренд везде. Поэтому слово 1С убираем – это везде сейчас так.
Это сокращает затраты. Например, на покупку железа. Потому что если представить себе некий идеальный стационарный компьютер разработчика 1С, то он сейчас будет стоить, наверное, порядка 40 тысяч рублей, если покупать его совсем-совсем дешево. Хотя по нынешним ценам даже, наверное, уже 60. Там должно быть что-то наподобие i7 (многоядерщик), 16 гигов оперативки и SSD-винт терабайтник для работы с кэшем конфигуратора, чтобы все туда влезало.
Ну да, софтовые требования растут быстрее.
Да, и надо окупить 90 тысяч рублей. Если ты работаешь в Москве, можно это как-то сделать, а в регионе 90 тысяч рублей даже с кредитом окупить достаточно сложно.
А при использовании удаленного окружения тебе достаточно просто браузера или какого-то стационарного клиента, который будет с этим работать по сети. При развитии каналов связи (а они еще развиваются) это будет достаточно хорошо и удобно. Поэтому это действительно интересный тренд.
А как в вашем случае с облачным конфигуратором будет влиять скорость канала? Вроде как понятно, что это будет влиять на отображение картинки, но насколько будет хороша производительность на стороне облака? И от чего она будет зависеть?
Из практики — производительность там будет в 3-4 раза выше, чем, допустим, у тебя на локальной машине даже с SSD. Потому что производительность самого решения уже зависит от поставщика этого решения.
Все наши конечные бизнес-решения, конечный консалтинг, практики мы все-таки продаем. Но инструментарий для того, чтобы люди развивались, мы выкладываем в OpenSource.
Как образовалось наше сообщество? Мы делились своими инструментами, своими наработками. Да и Инфостарт так образовывался. Весь инструментарий выложен. Так мы, получается, его отлаживаем. Инструментарий (тот же Снегопат), он же во многом производительнее, чем 1С, в несколько раз. Работа с конфигурацией, работа напрямую с 1С-ным хранилищем там тоже реализована в несколько раз быстрее, чем штатная работа. За счет того, что есть хорошие Си-шники, иногда ассемблеристы попадаются.
Ну да, Мерседес AMG, он, конечно, лучше, чем просто Мерседес, потому что доводится до ума.
Да, например, есть мнение о том, что 1С на виртуальных машинах тормозит и снижает производительность раза в два. Но есть и другое мнение, что если правильно настроить виртуализацию, то она не будет проигрывать по производительности. А если грамотно настроить параллельность потоков, то есть немного по-другому реализовать код внутреннего инструментария, распараллелив потоки, то можно выиграть по сравнению с обычной типовой машиной раза в два с половиной. Это из практики.
Поэтому производительность там на самом деле получается выше, чем на локальной машине за счет того, что ты внедряешь эту многопоточность или, иными словами, подход MapReduce, — когда мы распараллеливаем поток и потом финально только собираем. То есть синхронно происходит только поток сборки, а распределение нагрузки должно происходить горизонтально. Но это уже зона архитектуры. Приблизительно так же и 1С-ный кластер работает в 8.3. Весь код должен быть асинхронным, должен выполняться в несколько потоков, чтобы это можно было параллелить, управлять памятью и так далее.
Ты говоришь о том, что 1C-ники лукавят, когда говорят, что знают только 1С, потому что помимо этого они знают и другие языки программирования. Не значит ли это, что мы стоим на грани какого-то переломного момента? Раньше 1С-ником назывался тот, кто программировал в 1С. Теперь же он должен разбираться в виртуальных машинах, знать XML, должен понимать, как настраиваются сервера Postgre под Linux...
То, о чем ты говоришь, называется «Эксперт по производительности». Ему нравится разбираться, как ведет себя 1С в окружении Linux или в окружении Windows. Он изучает производительность на разных серверах – на Windows Server 2012, Windows Server 2008 – они разных денег стоят. Что-то из них ему удобнее, он может с этим работать. Он совершенно не занимается автоматизацией бизнеса, но все равно он специалист 1С. Эта грань нивелируется. Он просто специалист, эксперт по инфраструктуре, окружению для 1С.
Ставишь такому человеку, например, сервер приложений Tomcat на Java, и он говорит: «А, какая-то очередная службочка, не 1С-ная, ну да, на Java, но ведет себя так же». И он внезапно становится специалистом по поддержке инфраструктуры для серверов приложений.
Правильно ли я понимаю, что в отличие от айтишника 95го года, который сам ставил 1С, и потом за два дня давал бизнесу какое-то полуработающее, но работающее решение, нынешний 1С-ник, в узком смысле, играет главенствующую роль, а остальные 2 отдела разработки выполняют поддерживающую функцию? Не получается ли так, что за счет этого мы и приходим к «миру во всем мире»?
Может быть и так, но тут есть другой вопрос. Снова в деньгах. Бог с ним, с технократией, технические вопросы там все решены. Теперь вопрос, как это монетизировать и как на этом заработать.
Так вот сейчас, при переходе в «модель сервиса» начинается новая модная тема — это микросервисы, микрокоманды. Люди начинают говорить о том, что IT вдруг становится не центром затрат (как служба поддержки), а центром заработка. По новой идеологии, любая IT-служба должна зарабатывать, поэтому фактически мы должны на внутреннюю службу повесить биллинг (подсчет выгоды), и условно 1С-ник покупает у дотнетчика какую-то его услугу.
По сути, некий внутренний хозрасчет.
Да, и если каждый микропроцесс там будет делать микрокоманда, то они друг у друга просто покупают эти сервисы на партнерских отношениях. Причем модель франчайзинга и типового «обновлятора» – это тоже просто один из сервисов. Для бизнес-заказчика он выглядит как типовой 1С-ник, который приезжает, обновляет ИТС, может поговорить с бухгалтером по душам, рассказать ему о нововведениях, которые он вычитал на ИТС. Это сервис, поддержка за базовые деньги. Но этот сервис также обеспечивает и проектную деятельность, потому что если у тебя есть служба такой поддержки, то за счет нее развивается в целом также еще и отдел разработки, ведь на самом деле настоящие требования от бизнес-заказчика приносят сотрудники этого сервиса, потому что они с пользователями по душам разговаривают.
Можно сказать, что это, по сути, некая техподдержка?
Нельзя. Техподдержка – это те, которые технарят и больше ничего не делают. В реальности это не так.
Происходит следующее: человек поехал, обновил ИТС, поговорил с бухгалтером по расчету зарплаты, и вернулся обратно в команду разработки. В этот момент бухгалтер направил на разработку требование добавить реквизит «Ромашка» (это реальное требование, оно действительно так звучало). Настоящий разработчик смотрит и негодует: что за реквизит «Ромашка», о чем речь вообще?
А тут к ним приходит тот самый «обновлятор», и объясняет, что там, на самом деле, проблема вот в чем: большая ротация персонала, человек может уволиться и вернуться в следующем году, они таких сотрудников на жаргоне называют «ромашками». Потому что у них два трудовых договора, а справка 2-НДФЛ одна. Поэтому и попросили добавить такой реквизит в справочник сотрудников, чтобы не было проблем с налоговой. Оказалось, что они об этом «за чаем» поговорили во время обновления ИТС. Следовательно, и не надо ничего дорабатывать, потому что это и так есть в стандартном функционале ЗУП.
В результате получилось, что аналитиком здесь выступил вот этот человек, который съездил и пообщался.
Но это опять же при условии, что он хорошо знает типовую конфигурацию, и вообще понимает суть проблемы, а также специфику бизнеса – то есть это должен быть 1С-ник определенного уровня.
Да. Но он же этого уровня должен достигнуть.
Само собой.
Проблему людей, которые не развиваются, можно решить двумя способами. Что сейчас происходит на рынке?
Есть люди вроде нас с тобой, которые развиваются сами, понимая, что иначе нельзя. По этому поводу есть закон Мура, который говорит о том, что дальнейшее развитие технологий идет быстрее и быстрее. Значит, нам надо накопить базовый инструментарий, чтобы успевать за развитием, чтобы быть быстрее, чем развитие. И тогда мы сможем быть в тренде и нивелируем эти риски, поскольку сейчас думаем о том, что будет завтра.
А есть другие люди, которых вынуждает уже сама платформа. Ты ведь знаешь, что очень многие ушли из 1С мира только потому, что слышали, что 1С платформа — плохо и так далее. Но на самом деле, они не смогли перестроиться от подхода 7.7 к подходу 8, от подхода 8 к подходу 8.3. Я очень часто говорю о том, что подход 8.3 в Java-мире (и не только) — это стандарт де-факто: трехзвенка с вызовом от клиента и выполнением на сервере. Если бы кто-то из Java-разработчиков пришел бы сейчас в 1С разработку, то в 1С 8.3 он был на коне, потому что здесь для него все было бы знакомо
Я помню, когда я переходил с Delphi на программирование в семерке, я, наверное, в течение нескольких месяцев программировал следующим образом: сначала в голове формировал код в английском варианте, а потом переводил это все в русский код на 1С. И ошибки отлавливал ровно таким же способом.
Ну, это такие затраты на переходный период. Цель-то хорошая.
Да, на выходе получилось хорошо.
А второй тип людей — это те, которые не успевают за развитием (развитие-то идет непрерывно). И в итоге их либо выкидывают с рынка, либо подставляют, либо переквалифицируют, либо увольняют.
Либо ты развиваешься, либо тебя развивают, либо ты вообще выпадаешь из этой схемы?
Да. Можно вообще уехать, сбежать. На моей памяти был случай, как айтишник уехал в «глушь, в Саратов» и стал фермером. Ему это надоело, он понял, что IT —не его. И это тоже нормально.
Мы же говорим о том, что любую проблему можно решить – иногда проблему можно решить, просто «зафиксировав убытки». Если мы понимаем, что IT – это не наше, мы можем иногда (очень редко) зафиксировать убытки и сказать – все, я не IT-шник.
Это в любой области, в принципе.
Да, слово IT убираем, и на самом деле фиксация убытков есть в любой методологии. Так бывает, это не страшно.
Раньше я тоже был ортодоксом. Например, когда был явером, я негативно относился к 1С. Когда я был 1С-ником, считал Java слишком медленной. Но теперь, после того как я побывал «по обе стороны баррикад», я пришел к некому гетерогенному подходу (к некому «дзену»), что нет «плохого» и «хорошего», а есть проблема, есть язык и есть решение. Главное, чего хочет человек, к чему он испытывает любовь, желание и так далее.
Мы возвращаемся к тому, что в приоритете те люди, которые любят то, чем занимаются. Их главный мотив — не деньги, а любовь к делу и саморазвитие.
Они развиваются. Они обычно на слуху и виден результат их работы. А есть и те люди, которые не хотят развиваться и выполняют какую-то рутинную работу. Не скажу, что я согласен с их взглядами, но такие люди тоже необходимы.
Мы сейчас говорим про развитие и про разные типы людей. Насколько я знаю, ты участник различных сообществ, в том числе и 1С-ных. Мы только что говорили о том, что меняются парадигмы, концепция. На твой взгляд, будет ли какое-то изменение в самих сообществах? Будут ли они как-то перестраиваться, например, тот же Инфостарт, будет ли смена состава, аудитории?
Инфостарт в любом случае будет развиваться. Куда он денется, он с 2006-го развивается. Я в Инфостарт-сообществе зарегистрировался в 2007 году.
Мы с тобой одногодки.
До этого я общался на 1С ProClub и 1С++. На Мисте мне не очень нравилось, потому что там было мало практики, я не развивался там. Поговорить там наверное можно было, но только этот разговор меня никак не развивал. А на форуме 1С++ было более профессиональное общение и авторы этой компоненты меня многому научили. Поэтому у них на форуме я общался, учился у них, и они меня учили.
Кстати, знаешь, как мы пришли на Инфостарт? Просто в определенный момент в 2007м мы решили опубликовать там свои наработки – тогда больше было некуда опубликовать, и нам тут нравилась система рейтинга «+1». Это было классно. Мы, как конечные пользователи «плюсиков», ими в то время «мерились» :)
Помню, помню.
Я с тех пор наблюдаю, что сообщество Инфостарт развивается, видоизменяется. Становится меньше троллинга, больше профессионализма, больше возможности получить ответ. Общение «ни о чем» уходит в социальные сети, а в профессиональных сообществах остается профессионализм. Когда ты выдаешь публикацию, задаешь вопрос на форуме, и в результате получаешь вменяемую критику.
Есть подход GitHub — это когда идет социализация с помощью кода. Там ты публикуешь код наработки, там изначально используется подход «меньше слов — больше дела». А на Инфостарте ты публикуешь сами наработки, и люди их оценивают. В сторону такой коммуникации, как мне кажется, и будет стремиться дальнейшее развитие везде. На ХабраХабр таким же образом общаются сайтописатели на PHP – там тоже большинство ссылок о том, что «ребята, я сделал, вот ссылка на мой код». А в комментариях люди в качестве ответов дают новые ссылки и т.д. Профессиональные сообщества развиваются не как сообщества «пообщаться», а как сообщества «помочь».
Новый виток пошел в развитии.
Да. Один мой знакомый из Сколково говорил, что активность — это то же самое, что и записи в регистре сведений, активити стрим. Главное, какая сущность является регистратором для этой активности.
Общение становится неформальным, а сущность становится профессиональной. Такой тренд я наблюдаю последние года три – он пришел из Америки, там уже есть примеры, как это все еще и капитализировать. В Россию такой подход пока не пришел, но скорее всего, придет. И я думаю, что Инфостарт будет первым, кто это привнесет.
Ты всю передачу держишь в руке патрон. Я знаю, что ваша команда на данный момент называется «Серебряная пуля». Но при этом написание сайта SilverBulleters. Если бы была просто Серебряная пуля – тогда было бы Silver Bullet. И если взять некую аналогию и транскрипцию, то получается, что вы – серебряные билетеры. Вопрос следующий: кому и что вы продаете? Серебряные пули или все-таки осиновый кол и чеснок?
В любом действии должна быть философия. В том числе, и в названии.
Помнишь, я говорил про 4 авторов: Брукс, Вирт, и Уорд и Хьюдак. Это же 2 лагеря. Брукс и Вирт там за одно воевали. А Уорд и Хьюдак — за другое. И там у Вирта есть цитата, которую знает большинство айтишников. Это — «Серебряной пули не существует», нет технологии, которая была бы «Серебряной пулей».
Так вот, серебряная пуля не существует, а люди – «серебряные пули» есть. То есть технологии может не быть, но зато есть человек, который решит проблему. А теперь переведи мне, пожалуйста «человек-серебряная пуля» на английский язык. Или «люди — серебряная пуля». Вот этот обыгрыш и лег в основу названия сайта, потому что это отражает тот концепт, который мы для себя выбрали.
То есть разница в названии компании и названии сайта латиницей — сознательная?
Да, и в это заложена большая философия. Делалось так, чтобы заложить туда больше философского смысла и, возможно, меньше маркетинговой привлекательности. Потому что мы технари, наша задача – решить конкретные проблемы. Как мы это делаем – отдельный вопрос. Инструменты все бесплатные. А вот знания о том, где ткнуть в паркет и как решить проблему – это и есть платный продукт. Это мало кто делает. Мы выбрали для себя такую монетизацию, такую нишу.
Хорошо, Алексей, я тебя благодарю за беседу. Что бы ты пожелал нашим зрителям напоследок?
Я все-таки большинству людей советую сейчас, особенно в текущих реалиях, попробовать разработать, спроектировать, спрогнозировать некую стратегию своего развития в целом. Поступить как стратег по отношению к себе. Попробовать создать план того, как ты будешь развиваться сам, как ты будешь общаться лично, как ты будешь отдыхать и т.д. Желательно, чтоб вы его создали года на 3 вперед, попробовали накидать, ведь тут не страшно ошибиться.
Главное — движение. Развиваться можно в любом направлении. Я советую больше делать какие-то вещи руками, хотя бы прототипы. Желаю вам в будущем трехлетии и в ближайший год побольше интересной работы в целом и поменьше проблем дома. Чтобы жены вас понимали, близкие, родители.
Леша, спасибо тебе большое. Друзья, делайте больше ошибок и получайте больший опыт. С вами была программа «Готовые решения» и я, Сергей Горшенин. Ну, а пока — конец процедуры.
______________________________________________________________________________________________________
Посмотреть и послушай нас можно здесь:
youtube
itunes
podfm
Ведущий — Сергей Горшенин
Дорогие друзья, я приветствую вас в студии программы «Готовые решения». Представляю нашего гостя – это человек с двадцатилетним стажем работы в области информационных технологий, айтишник, технический директор и просто хороший человек. Наш сегодняшний гость — Алексей Лустин.
Здравствуй, Сергей. Здравствуйте, коллеги.
______________________________________________________________________________________________________
Хронологическая справка
Лустин Алексей Александрович родился в городе Анадыре в 1980 году, учился в Воронежском Техническом Университете по специальности «Инженер САПР». С 1995 года — IT-специалист. Начинал как программист-внедренец 1С в городе Липецке, занимался автоматизацией бизнес-процессов в сети Уютерра. С 2008 года — ведущий специалист Java, Rails. В 2008 году переезжает в Москву. С 2012 по 2014 год — заместитель начальника отдела инновационного развития и системного анализа в ГК «Связной». В настоящее время является техническим директором, тренером, архитектором-консультантом компании «Серебряная пуля».
Алексей, для начала я предлагаю тебе немного рассказать о себе, чтобы обозначить то, о чем мы будем говорить в дальнейшем.
Это достаточно сложно, как и любое начало. Если коротко, то о себе я говорю в таком ключе, что родился я на Чукотке, далеко-далеко, рядом с полярным кругом. IT занимаюсь лет с 12, то есть, на самом деле не 20, а по-моему, уже 22 года. Прошел путь от обычного заправщика картриджей, оператора по заполнению приходных накладных, до архитектора, технического директора и так далее.
Как я его прошел? Здесь, наверное, нужно рассказать длиннее.
Я приехал с Чукотки в 97 году, чтобы поступить в институт, потому что основная плеяда хороших преподавателей была сосредоточена в центральном регионе, а не на Дальнем Востоке. Может быть, еще в Новосибирске, но в целом на тот момент качественное образование в сфере IT можно было получить в технических городах – либо в Москве, либо в Воронеже, либо, конечно же, в Санкт-Петербурге. К сожалению, на Дальнем Востоке такого не было. Чтобы обеспечить себя деньгами, а время было тяжелое, я брался за любую работу по IT. Это и администратор компьютерного клуба, и сборщик компьютерной техники, и разработчик 1С, как ни странно, еще на старой-старой версии. А еще я пробовал свои силы как разработчик на Java, когда она только начинала развиваться, и как разработчик баз данных на Clipper, кто ещё помнит такие вещи. По тем временам это было достаточно весело.
А после окончания этапа студенчества уже началась серьезная жизнь, и там я прошел другой путь: был и программистом, и менеджером проектов в зависимости от того, какова была глобальная цель тех работодателей, на кого я работал (владельцев бизнеса, IT-директоров или IT-руководителей в целом).
Ну а потом, в Липецке, я работал в компании Уютерра — это достаточно большой российский холдинг, объединяющий в себе сеть магазинов непродовольственных товаров – на тот момент там было порядка 112 супермаркетов от Благовещенска до Калининграда.
Чуть позже, в порядке своего собственного развития, я по собственной инициативе переехал в Москву, поближе к грандам нашей отрасли, чтобы действительно получить опыт и поделиться своими подходами. Так я попал в «Связной» и проработал там порядка 4 лет. Я там был и ведущим программистом, и внутренним техническим лидером, в последний год моя роль в компании называлась «Центр компетенции по 1С». Чтобы вы понимали, там около 200 специалистов по 1С.
Ну, зная Связной, я понимаю уровень, да.
Да. Вот такой жизненный путь. С точки зрения моего личного к нему отношения.
ИТ-парадигмы от четверки авторов
Итак, в 95-ом году ты начинал IT-специалистом. Как ты считаешь, отличается ли модель IT-специалиста 95-го года от IT-специалиста 2015-го?
Вообще ничего не поменялось, на мой взгляд.
А как же изменения в парадигмах, в концепциях, в развитии технологий?
Парадигмы не изменились. Все парадигмы, на которых мы сейчас паразитируем, придуманы четверкой авторов – это Брукс, Вирт, Уорд и Хьюдак. Они, собственно, и придумали эти парадигмы в 93-94х годах (я не говорю про инженерию программного обеспечения, которая придумана в 70-ых). Все, что сейчас происходит с технологиями, заложено именно там. Ничего не меняется. С другой стороны, растет только практика применения этих парадигм, то есть IT-специалист, начинавший в 95-м году, имеет, условно, 20 лет опыта применения этих парадигм. Это единственное его конкурентное преимущество по отношению к человеку, начинающему в 2005-м. Просто человек, начинающий в 2005-м, имеет 10 лет практики. Вот и вся разница. А парадигмы одни и те же.
Хорошо. А давай вспомним 95-ый год. Всё-таки айтишники тогда — это люди, которые любили IT, они приходили в эту сферу в 12, в 15 лет… Не секрет, что сейчас некоторые из айтишников выбирают IT только потому, что это модно.
Да, сейчас действительно большая мода на IT. Но и тогда выбирали, потому что это было модно. Например, можно вспомнить «бум доткомов» 2000 года, который затронул и Россию, потому что и тогда была мода на IT. Да и за 3 года до этого, в 97-м, мода на инженерные специальности тоже была очень большой.
Объясню почему. В России на тот момент была вообще нехватка специалистов по IT любого характера. За хорошего IT-специалиста готовы были платить большие деньги. За юристов, экономистов уже не готовы были платить, а за IT готовы. Это было достаточно интересное время. Если вспомнить, что в 93-м году проходной балл на инженерные специальности был 9 — три тройки, то в 97-м году на инженерные специальности, связанные с IT, проходной балл уже был в районе 14-15 – одна четверка, две пятерки. Это показатель. И, по-моему, этот проходной балл до сих пор не снижается. Что в начале двухтысячных, что сейчас проходной балл и требования к IT-специальностям остаются на уровне 97, 98, 99-х годов.
С другой стороны, и тогда в IT шли в том числе за модой. Поэтому сейчас многие из тех, кто начинал тогда, уже больше не IT-специалисты. Часть из них бизнесмены, кто-то стал экономистом, кто-то ушел.
Там остались не те, кто пришел за модой, а те, кто действительно это любил. И если мы видим IT-специалиста с десятилетним стажем, то он, скорее всего, прошел через все кризисы этого роста – 1, 3, 5 лет. Как в семейной жизни – ты женился на IT, потом через год понял, на ком ты женился, через 3 года вы поссорились, а через 5 лет вы наконец-то достигли некого такого «дзена», когда вы понимаете, что вам друг от друга надо.
Такая философия.
У тебя довольно интересный опыт, но при этом по тебе не скажешь, что ты – айтишник, хотя ты сам упорно на этом настаиваешь. Почему?
У меня есть два тезиса, которые отражают мой опыт и вообще общую концепцию того, что я за специалист: это Overskilled – так называемый «перебор по навыкам» (их слишком много), и одновременно Troubleshooting – это «человек – решатель проблем». Я обычно говорю, что я могу решить любую проблему в IT. За счет опыта, за счет методики, за счет выработанных алгоритмов – вообще любую. Потому что любая проблема может быть решена. Неважно, связана эта проблема с 1С или не связана. Не может быть нерешенных проблем. Это первое.
Так как я с таким подходом живу очень давно, ты представляешь, какое количество проблем я уже решил? Именно поэтому, собственно, у меня перебор по навыкам. Я могу решить проблему с Ruby, с С++, с Ассемблером даже могу, если будут проблемы. С 1С, естественно, с бизнес-приложениями, с приложениями, написанными сторонними разработчиками, с OpenSource, Commerce приложениями. Я все это уже просто пережил. Учет картриджей? Да, пожалуйста.
«НЕ МОЖЕТ БЫТЬ НЕРЕШЕННЫХ ПРОБЛЕМ»
Специалист по бизнес-приложениям
Тогда у меня возникает встречный вопрос. Моя карьера началась в далеком двухтысячном, причем я начинал именно с 1С. Но спустя 6-7 лет я перестал быть одинэсником в прямом смысле этого слова, хотя, наверное, где-то в глубине души я до сих пор еще программирую на семерке. Но почему ты с таким богатым техническим опытом до сих пор еще считаешь себя одинэсником?
На самом деле я обычно называю себя специалистом по бизнес-приложениям. А в России, да и не только в России, создавать бизнес-приложения без платформы 1С невозможно.
Можно ли сказать, что в данном случае 1С — самая распространенная платформа для создания бизнес-приложений, по крайней мере, в России?
1С — это реализация концепций проблемно-ориентированного языка. Давай вернемся опять в 95-й. Была проблема. Бизнесов стало много. Вот представь, сколько конфигураций сейчас в России, написанных с нуля, не беря в расчет типовые. То есть де-факто мы можем говорить, что каждый 1С-специалист написал свою конфигурацию с нуля. Плохую, хорошую — не важно. На портале INFOSTART.RU сейчас зарегистрировано 450 тысяч активных пользователей, 1С-специалистов, то есть мы можем говорить, что каждый из них написал свою конфигурацию.
«1С — ЭТО РЕАЛИЗАЦИЯ КОНЦЕПЦИЙ ПРОБЛЕМНО-ОРИЕНТИРОВАННОГО ЯЗЫКА»
Знаешь, далеко ходить не буду, у меня, например, 4 полноценных программных комплекса. Это не считая мелких наработок и отчетов.
Я обычно сторонник говорить, что сколько специалистов 1С, столько нетиповых конфигураций 1С, написанных с нуля. А сколько в России бизнесов? Их гораздо больше.
Наверное, все-таки моделей бизнесов?
Да, моделей бизнесов. Чаще всего архитектура бизнеса прямо пропорциональна архитектуре команды, создающей этот бизнес. Не бывает одинаковых бизнесов и одинаковых процессов тоже не бывает. Даже если они базируются на одних и тех же принципах, конкретная реализация всегда разная. Надо с этим смириться.
Откуда вообще родилась платформа 1С и ее язык для разработки бизнес-приложений? Все это появилось в ответ на проблему, которая заключалась в том, что в России рос бизнес – происходил переход от старого строя к новому: появлялось много мелких предприятий, рост был очень бурный. Возникло много маленьких бизнесов. Они не могли все работать по «шаблонным» бизнес-практикам («бестпрактиксам»).
Тогда таких практик еще и не было как таковых в России.
Да, и консалтинга как такового для этого рынка еще не было. Но уже нужно было как-то работать.
Появилась потребность в языке для быстрого описания бизнес-процессов. Потому что ни в одной платформе вы не найдете языка, на котором можно писать «Документы.ПриходнаяНакладная.Провести()» (зарегистрировать, распечатать, послать на принтер, зачесть продажу и так далее). А это нужно было описывать.
Условно, идея была в том, что даже бухгалтер сможет описать свой бизнес-процесс. Это не совсем сработало – все равно потребовались специальные люди, которые обладают алгоритмической базой, и могут описывать бизнес-процессы на специальном DSL-языке (проблемно-ориентированном языке). Но таким образом можно было сократить расходы и быстро автоматизировать любой бизнес из 5-10 человек.
По сути, таким образом экономилось время и затраты на создание этих базовых классов, базовых моделей, потому что они по факту уже были.
Да, это был огромный скачок. Дело в том, что на тот момент, в 95-м году, основным языком разработки бизнес-приложений был C++, который обладал низким уровнем абстракции.
Тогда еще на Clipper очень многое писалось, насколько я помню.
Clipper – это тоже был слишком низкоуровневый язык. Тогда только-только появлялась Java, как некий фреймворк, который поднимал уровень абстракции. Но он поднимал этот уровень только на один этап вверх – позволял компонентную модель строить, а 1С прыгнула прямо через 5 уровней наверх, сразу на уровень бизнесмена. Даже теперь, по прошествии 20 лет, ни за рубежом, ни в России до сих пор нет подобного языка, который позволял бы описывать бизнес-процессы напрямую.
Сейчас у банков есть попытки создать язык для автоматизации трейдеров и описания их алгоритмов в неком DSL-языке – они пытаются подобное в Java-мире (или, точнее, в функциональном мире) сделать. А у нас такой язык, условно, существует уже 20 лет, поэтому мы здесь в выигрышном положении. И вряд ли в ближайшее время там появится язык такого же уровня, позволяющий настолько же эффективно нивелировать работу системы на базовых уровнях, чтобы можно было на первом этапе не останавливаться на проблемах с кодом, с памятью, чтобы сразу можно было думать о пользе бизнесу.
Вспомни, для чего придумали Agile? Для того чтобы разработчики на сторонних платформах начинали задумываться о пользе для конечного пользователя. Не делали космические алгоритмы управления памятью, а думали, как эти алгоритмы могут быть полезны бизнесу. Не бизнесмену в рубашке (собственнику, который в это деньги вкладывает), а конечному пользователю — кладовщику, оператору, бухгалтеру.
Есть еще такой момент: как обосновать для бизнеса необходимость оптимизации какого-то алгоритма для того, чтобы выиграть полтора мегабайта памяти? На С++ доказать технико-экономическое обоснование такой оптимизации для бизнеса почти невозможно. А одинэснику с этим проще, его задачи приближены к бизнес-целям, поэтому он может объяснить, что станет быстрее, что улучшится (причем саму оптимизацию по памяти он может реализовать как раз с помощью С++).
И если вернуться к тому, почему я себя считаю 1С-специалистом — я всегда работаю с бизнесменами. Изначально, еще 20 лет назад, я начинал в Фонде обязательного медицинского страхования. Моей первой задачей была автоматизация сбора платежей по ОМС. Моим первым заказчиком был руководитель этого Фонда ОМС, он объяснил стратегическую бизнес-цель: зачем ему это надо и так далее. А техническая реализация и связанные с ней технические риски были полностью на моей стороне – выбор платформы, будет ли это Access, Clipper и так далее, полностью ложился на меня.
Это была моя первая задача – мне на тот момент было 15 лет и специалистов в нашем городе по базам данных вообще просто не было. Кроме меня и Андрея, моего коллеги — хорошего С++ программиста. И еще у нас в команде был «старший товарищ», радиотехник лет 35 – он нам объяснял, как все технически реализовать, и потом «причесывал» сделанное. А мы, молодые ребята, взяли стратегическую цель человека, который отвечал за все окружное обязательное медицинское страхование, и попытались это реализовать. Плохо, хорошо, с ошибками — уже не имеет значения. Наверное, если он нас сейчас увидит, то скажет, что мы все там сделали плохо. Но это нормально.
Можно ли сказать, что это он за вас тогда решил, что вам надо развиваться, что, поставив свою цель во главу вашей работы, он дал вам толчок к дальнейшему развитию?
Да, конечно, на нас тогда сильно повлияло то, что он в нас поверил. Мы были молодые парни-десятиклассники, на олимпиадах побеждали, такие айтишники до мозга костей – но, по факту, мы были пацаны без опыта работы. А он рискнул и дал нам возможность попытаться что-то сделать. И мы старались, да. Ради того, чтобы быть рядом с компьютерами и вообще быть рядом во всем. Это была такая хорошая мотивация.
Разные уровни абстракции
Я помню начало своей карьеры – это был Водоканал, там был 1С. Я застал 1С под DOS версии 2.0, потом переход на 7.5, на 7.7. Но когда я начал писать что-то под 7.7, я очень быстро понял, что мне не хватает того самого бухгалтерского бэкграунда. Я тогда пошел на трехмесячные курсы, и вот это для меня, наверное, с одной стороны, послужило толчком к дальнейшему развитию, а с другой стороны – послужило неким щелчком к тому, чтобы я от программирования начал двигаться дальше, уже вглубь бизнес-процессов. Не получится ли так, что IT-специалисты, которые пишут программы или приложения под различные бизнес-задачи, будут двигаться к тому, чтобы уйти от программирования и перейти в смежные плоскости, на другие платформы, под другие задачи или в другую область вообще?
Да обычно так и происходит. Мир делится. Сначала у тебя просто есть какие-то навыки программирования. Ты можешь писать на Pascal, на С++ что-то, какие-то алгоритмы. Это базовый навык – на этом этапе опыта работы с бизнес-задачами у тебя еще нет. Но вот тебе попадает 1С-платформа. Ты пробуешь решать бизнес-задачи с помощью нее, пропускаешь это через себя и возникает твой первый уровень. А что дальше — ты сам решаешь. Можешь уйти в бизнесмены — такое случается. Возможно, ты просто поймешь, что IT — это не твое.
Ты можешь уйти в бизнес-методологи (или иначе это называется аналитик-методолог). Это не тот, кто описывает методологию, а тот, кто пытается быть связующим звеном между разработчиками (теми, кто создает какой-то продукт), и бизнес-заказчиками. Это какой-то аналитик, который изучает бизнес-процессы, пытается найти скрытые требования, и, возможно, привлекает внешних методологов.
Это, наверное, что-то близкое к архитектору?
Нет, это больше относится к системному анализу. Архитектор — он компонентные модели строит, а этот специалист – своеобразный проектировщик, он больше занимается анализом того, как именно нужно построить конечную модель.
Так или иначе, ты начинаешь специализироваться. Ты можешь в этот момент захотеть уйти из 1С-мира, потому что вдруг решишь, что сам все сможешь спроектировать на каком-то низкоуровневом ПО. Берешь, например, Java, так как она бесплатная, и начинаешь что-то на ней проектировать. В итоге люди либо начинают заниматься чем-то другим, либо, что происходит чаще всего, возвращаются обратно к 1С, но уже с другим знанием.
Количество опыта прямо пропорционально количеству совершенных по мере роста ошибок. Это такая особенность. Поэтому в итоге ты все равно в большинстве случаев возвращаешься в 1С мир. Может быть, в другом качестве – например, как бизнес-заказчик, или как главный архитектор, посматривая на 1С со стороны, но все равно с ней работая. Потому что 1С – это платформа автоматизации бизнес-процессов, и ты никуда от нее особо и не уходишь.
«КОЛИЧЕСТВО ОПЫТА ПРЯМО ПРОПОРЦИОНАЛЬНО КОЛИЧЕСТВУ ОШИБОК»
А как же насчет репутации одинэсника? Я помню, когда я начинал, надо мной многие мои однокурсники посмеивались. Дескать, вот мы программируем на нормальных полноценных языках, а ты программируешь на языке, который мало того, что сделан на С, так еще и пишется по-русски.
К сожалению или к счастью, у меня в работе было множество команд, которые не одинэсники. Я вообще иногда считаю себя помимо 1С-специалиста еще и специалистом по Ruby on Rails и по Java – так сложилось, что у меня есть опыт написания приложений на этих фреймворках. Но там есть другая проблема. Люди, которые пишут на .NET, на Java, на чем угодно, они слишком далеки от народа. Они не автоматизируют бизнес. Они пишут некие компоненты для бизнеса, а точнее компоненты для тех программистов, которые из этих компонентов потом будут строить бизнес-приложение.
По сути, они строят кубики, из которых дальше уже кто-то будет выстраивать конечный продукт.
Да, именно так это и работает. Ведь мы никогда не задумываемся о том, что есть люди, которые пишут на Ассемблере программы, реализующие логику микросхем. А там же тоже есть внутренние алгоритмы – различные южные, северные мосты.
Давай проще. Вот мы каждый день управляем мышкой, мы не задумываемся, каким образом движение мышки передается на экран.
Да, где-то есть люди, которые программируют микрокристаллы внутри микроконтроллеров. Есть специальность «Физическая химия», где учат работать на уровне микроконтроллеров, программировать там. Для них 2 байта — это много. У них там память не гигабайтами меряется, а байтами. Эти люди отдают свои готовые компоненты другим людям, которые уже описывают работу с устройствами на чем-то более высокоуровневом, например, на С++. Потом еще какие-то люди берут эти компоненты, написанные на C++, и делают из них свои приложения, компоненты или библиотеки – уже на .NET или на Java, или еще на чем-то. А потом приходят одинэсники, берут эти компоненты и делают из них конечное бизнес-приложение. Так это и работает.
Давай вернемся к одинэсникам. Можно ли сказать, исходя из твоих слов, что возникает некое противоречие, что ты, с одной стороны, не хочешь быть одинэсником, но тебе приходится.
Надо быть одинэсником, но не надо быть одинэсником. Вот так звучит противоречие. Для удобства понимания надо просто убрать слово 1С. 1С — это ЗАО «1С», это фирма, которая развивает, которая вкладывает и деньги, и методологию внутрь этой платформы. Надо быть специалистом по автоматизации бизнеса, но не надо быть специалистом по автоматизации бизнеса. Напоминает шизофрению. Но в целом ты просто должен научиться переключать тумблер.
Вот когда ты общаешься с бизнес-заказчиком, твоя задача – ни в коем случае не обсуждать с ним какие-то технические моменты — технические долги, техническую архитектуру. Заказчик не знает, как тебе выстроить кластер — горизонтально или вертикально, как тебе выстроить стойки и так далее. Он тебе говорит некое пожелание. Обобщенно, заказчик хочет получить какое-то предполагаемое визуальное поведение формочки в целом. Если, конечно, это не заказчик, который заказывает у тебя компилятор.
… Скажем так, если твой заказчик — это представитель бизнеса, а не представитель IT-отрасли.
Да. Мы говорим о конечном бизнесе. Я просто очень много работал именно в конечных отраслях, то есть занимался конечной автоматизацией. Это достаточно сложный процесс – там нужно научиться переключать тумблер, чтобы специализироваться на бизнес-платформе – например, быстро отстроить прототип, если надо экспериментировать с проектами. Это свой навык.
Но когда ты возвращаешься в свой внутренний IT-мир, тебе нужно переключить тумблер обратно, и там ты уже не должен быть одинэсником, специалистом по бизнес-платформам. Ты должен быть просто специалистом по разработке. И там ты уже забываешь, что это 1С – у тебя просто есть язык, есть компоненты, есть алгоритмы (теория алгебраических множеств, например) и так далее. Там ты уже вспоминаешь все, чему тебя учили в институте, если он у тебя, конечно, был профильный.
Хорошо. Давай вернемся к репутации 1С-специалистов. Какова, на твой взгляд, репутация одинэсника у бизнеса?
У бизнеса отличная. Только 1С-специалист может на спор за двое суток автоматизировать полфирмы, условно. Пусть коряво накидать прототип, но в который можно запустить уже кладовщика и пользователя. Он начнет ругаться, но в целом он уже начнет генерировать какие-то данные, уже будет польза. То есть скорость запуска 1С-решений высокая.
«1С ПОЗВОЛЯЕТ ОСУЩЕСТВИТЬ БЫСТРЫЙ ЗАПУСК»
Но это, скорее, заслуга платформы?
И специалистов, которые знают, как все это запустить. Поэтому репутация 1С у бизнеса в целом хорошая. Когда мы только начинаем запускать бизнес, он привыкает к тому, что мы все для него делаем очень быстро. Условно – мы прототип запустили, а теперь нам надо массово запустить всю компанию. Естественно, качество такой первоначальной автоматизации близко к нулю, но сам по себе прототип работающий. И когда мы дальше пытаемся переключиться на то, чтобы повышать качество самого решения, то здесь мы уже начинаем терять репутацию у бизнеса, потому что перестаем его удовлетворять.
То есть мы ему дали 80%, например, за 2 дня, а оставшиеся 20% мы доводим до ума несколько месяцев. Его это уже не устраивает.
И вот тут возникает дилемма. За репутацию приходится бороться. Бизнесмены, на самом деле, очень любят 1С: она быстрая, недорогая, можно запуститься «на коленке», на маленьком компьютере под столом. Если вы запускаете прототип на 10 пользователей, то там, по-серьезному, даже сервер не нужен.
1С позволяет осуществить быстрый запуск. Для бизнесмена это понятно. Существует такая парадигма: чем полгода считать технико-экономическое обоснование одного проекта, проще 100 неуспешных проектов запустить за это же время, понести эти затраты, и один из них вдруг выстрелит. Для бизнеса эта модель успешней, поэтому 1С-ники для них очень важны. По этой же причине большинство специалистов по 1С чаще всего приближены к центру финансовой ответственности. Не к ключевым пользователям, а к людям, владеющим бюджетами.
Ты имеешь в виду бухгалтерию, финансистов?
Да. Тех, кто владеет бюджетами на автоматизацию. Вплоть до коммерческого директора. В моей практике 1С-специалисты чаще всего завязаны либо на коммерческого директора, курирующего IT, либо на главного логистического специалиста (на того, кто отвечает за оперативную деятельность всего предприятия) — то есть, напрямую на топ-менеджера, минуя средний уровень руководителей. Это обычная практика в конечном бизнесе.
Они, по сути, на разных уровнях абстракции работают.
Да. 1С-специалисты не хотят спускаться вниз, не хотят разбираться в технических деталях, а специалисты по другим платформам не хотят подниматься до бизнес-целей. Консалтинг в соседних платформах пытается научить .NET-чиков любить бизнес, а мне приходится учить одинэсников любить IT, то есть совершенно наоборот, хотя принцип ровно тот же.
L на конце HTML (DSL, XML, WSDL, и т.д.) означает language — язык.
Но если с «чистыми» разработчиками у нас ситуация понятна, остается вопрос по поводу типовых одинэсников: почему их это устраивает? Ведь в результате получается, что, помимо того, что они хорошо относятся к бизнесу и любят его, они должны еще и любить своих смежников. Как они на это смотрят?
По-разному. Во-первых, там ключевой момент, что все одинэсники врут. Им удобнее быть одинэсниками, понятнее, спокойнее.
Последние лет 10 мне приходится проводить собеседования на внутренние вакансии. Пообщавшись с большим количеством 1С-разработчиков, я отметил интересный момент: большинство из них говорят, что они именно специалисты по 1С, хотя по факту 80% разработчиков 1С имеют в запасе знания по какому-то второму языку – это может быть Android, может быть Clojure функциональный, но они это не афишируют. Возможно дома, возможно вечерами. JavaScript, HTML. L на конце HTML означает language — язык.
Одинэсник является специалистом по конечной автоматизации бизнеса, а это подразумевает под собой знание не только 1С. Поэтому когда одинэсник говорит, что он только одинэсник, он врет, потому что он обязан работать с XML в последней 8 платформе. Если он работает с веб-сервисами, то язык WSDL (Web Services Description Language), это тоже L — язык. Он не может говорить, что он только специалист по 1С, но ему удобней называться одинэсником, потому что тогда ему дают одну платформу, не лезут в его маленький мирок и дают спокойно заниматься автоматизацией. Поэтому до последних пор большинство людей в этом смысле все устраивало.
Сейчас, последние года полтора я замечаю, что одинэсников такое положение дел уже не совсем устраивает, потому что потребности бизнеса растут, да и разработка в основном начинает требоваться тогда, когда бизнес рассчитан уже не на 5 пользователей.
Если 5 пользователей, то не обязательно нанимать разработчика – можно взять какое-то готовое типовое решение или какой-то облачный продукт, работающий в режиме сервиса. Сейчас, последние 6 лет, чтобы быстро стартовать бизнесу, достаточно взять типовой облачный сервис, заплатить операционные затраты баксов 20 в месяц, и все, можно думать о цели своего бизнеса. На первом этапе (примерно первый год) разработчики не нужны.
Разработчики становятся нужны, когда бизнес уже развивается, выходит на использование передовых технологий, требует доработок высокого уровня. Поэтому последние полтора года я замечаю, что одинэсники начинают задумываться о дальнейшем росте, доставать из загашников свои знания, начинают учить Python, .NET, 1С плюс XML, 1С плюс HTML… Я, например, специалист 1С плюс Web. Если просмотреть присланные резюме, у большинства кроме 1С написана еще какая-то платформа. Чтобы как-то специализироваться, что вот я для бизнеса делаю не только 1С, но еще какую-то особую «штучку».
Нельзя забывать о том, что есть статья Сергея Нуралиева, опубликованная в феврале 2014-го – он там определил, что одинэсникам недостаточно оставаться просто одинэсниками, необходимо развиваться дальше и специализироваться. Там перечислены шесть основных направлений развития для 1С-специалистов (аналитик, разработчик, эксперт по оптимизации, специалист по юзабилити, специалист по новым направлениям разработки и руководитель проекта). Поэтому, когда мы говорим «типовой одинэсник» — это мем из двухтысячных годов. Их больше нет. Они вместе с «семеркой», наверное, и умерли.
Я могу сказать, что по PHP специалисты тоже, кстати, не подарок совершенно и качество у них страдает. Но их все устраивает, потому что столько всего написано на этом РНР, что, казалось бы, можно с этим дальше спокойно жить. Но сейчас там тоже уже везде используется Node.js или Ruby on Rails, куда уже без него. И РНР специалистам тоже становится плохо, и они начинают перепрофилироваться, куда-то уходить… Это текущий тренд.
«80% 1С-РАЗРАБОТЧИКОВ ИМЕЮТ ВТОРОЙ ЯЗЫК В БАЗЕ»
А если вернуться к тому, о чем ты говорил – про разделение разработчиков «чистых» и 1С-разработчиков. Как сделать так, чтобы не было двух отделов, был один отдел, и при этом одни с другими дружили и жили в мире и согласии?
У каждой из этих двух сторон свои законы – профессиональная разработка на промышленных языках с одной стороны и разработка на платформе бизнес-приложений с другой. Разработчики 1С живут по методологии компании «1С», которая опубликована на ИТС, описана в желтых книжках и так далее. А разработчики .NET, Java, Phyton живут по своим книжкам. Для того чтобы объединить и тех и других, пришлось их спустить в 95-й год, и показать им четыре книжки тех авторов, про которых я уже упоминал (Брукс, Вирт, Уорд и Хьюдак).
Это реальный случай из моей практики, когда двум командам разработчиков дали почитать книжки про основополагающие концепции программирования. Так получилось, что никто из них этих книжек раньше не читал – эта теория оказалась для них новой. И через две недели, когда они все это прочитали и сформулировали для себя в голове концепцию DSL языков, они начали спорить. На самом деле весь этот холивар был ни о чем. Священные войны, кто лучше: 1С или .NET, — вообще слишком затратно. Они просто под разные задачи заточены.
И сработал следующий ход. Выделили одного (максимум двух) специалистов .NET или Java на две 1С-команды по 5 человек. И эти двое (по одному на команду, взаимозаменяемые, две команды обеспечивают) – они помогают сократить количество технических проблем для 1С-команды, когда они борются с производительностью в рабочей базе, и получается, что они друг другу помогают.
То есть дотнетчик скрыт от бизнеса, ему позволяется заниматься своими космическими вещами, а одинэсники не подставляются перед бизнесом, потому что у них бекэндом есть специалист на высокоуровневом языке, который нивелирует их технические просчеты. Вот так это и сработало – получилось хорошо.
Бывало, что кто-то из одинэсников приходит к этому дотнетчику (назовем его Сергей к примеру) и говорит: «Сережа, научи меня .NET, я хочу попробовать». И тот его учит. А Сергей, как показывает практика, тоже рано или поздно спросит: «Слушай, расскажи мне про 1С, чего здесь происходит?» И в итоге одинэсник учит особенностям 1С-платформы дотнетчика.
А потом возникает восклицание: человек из 1С, который действительно хочет заниматься разработками и программированием, говорит: «Какая классная штука — .NET», но и .NET-чик в определенный момент говорит: «Какая классная штука 1С, 1С — рулез», я даже помню эту цитату. Вот так это и объединяется.
О разнице между техническим и ИТ-директором
Я сейчас задам чуть отвлеченный вопрос. Вот ты технический директор, я IT-директор. Я вижу определенную разницу в том, как ты решил проблему в своем коллективе, и как я бы ее решил, потому что, например, из тех 4 книг, из тех 4 авторов, которых ты назвал, я читал только 2, ну и плюс, трехтомник Дональда Кнута тоже об искусстве программирования. Но на твой взгляд, если мы говорим об управлении командами, в чем разница между техническим директором и IT-директором? Ведь и один, и второй работают в области информационных технологий. По сути, это две смежных позиции, но разница в подходах очень существенна.
Я не очень люблю, когда меня называют техническим директором, потому что это, по моему мнению, только одна ипостась.
Разница между техническим директором и IT-директором только в одном: кто чем оперирует, базовые понятия. Для IT-директора базовым понятием является риск, который может быть пересчитан в деньги – то есть, IT-директор управляет рисками денежными, командными, психологическими и так далее. А я управляю противоречиями. А техническое (инженерное) противоречие — это понятие родом из изобретательства.
Вот ты никогда не думал, как создавались ракеты? Есть целый алгоритм, как создать изобретение, целая концепция — как разрешать противоречия. Изобретение нельзя делать революционно, нельзя допустить «застой», но нужна эволюция. Как ее обеспечить? Нужно управлять каждым противоречием, нивелировать его, повышать идеальность и так далее.
Я управляю противоречиями. Я не зря говорю: я решаю проблемы, потому что проблемы — это противоречия, когда что-то хорошо и плохо одновременно. Что-то, что невозможно выбрать одно из двух: «Надо быть одинэсником, но нельзя быть одинэсником» – вот, например, противоречие.
Поэтому разница между IT-директором и техническим только в базисном понятии: риск или противоречие. Но в целом подходы везде одинаковые.
Я вообще сторонник технократии, считаю, что технический директор, да и вообще любой управляющий персонал должен обладать техническим базисом. Я не могу по-другому считать.
«ЛЮБОЙ УПРАВЛЯЮЩИЙ ДОЛЖЕН ОБЛАДАТЬ ТЕХНИЧЕСКИМ БАЗИСОМ»
О взаимодействии 1С-ников со сторонними разработчиками
Давай продолжим тему информации и технологий. Мы говорили о том, как сторонние разработчики могут помогать 1С-никам. А может ли быть наоборот? Могут ли 1С-ники помогать сторонним разработчикам и если да, то чем?
Да. Из практики: конторе, где я работал, внезапно оказалась нужна WMS – у них совершенно случайно образовался склад на 7 тысяч квадратов. Я тогда работал в «Уютерре», был там совсем не одинэсником, а разработчиком на Java, Ruby on Rails и даже немного на С++ писал драйвера. В качестве моего первого тестового задания директор Уютерры дал мне на месяц линуксовую консоль, принтер этикеток и сказал: «Вот тебе принтер этикеток (DZBZ2 Godex он назывался), напиши к нему адаптер, напиши драйвер».
Я напоминаю — я только что вышел из 1С, у меня только что закончилась эра, когда я в течение года пробовал совместно запустить свой франч – я только что был во франчайзи, и тут внезапно я становлюсь разработчиком на С++, причем должен писать под Linux. Что произошло с моим мозгом дальше – страшно вспомнить. В течение месяца мне пришлось вспомнить работу с памятью, работу с блочными устройствами и так далее… Но я не сдался. Это к вопросу о том, «как».
Была проблема. А я же говорил, что могу решить любую проблему. Мне нарисовали проблему: нужно автоматизировать работу китайской машины с неизвестным драйвером, имеющую описание на китайском языке. По факту, эту задачу можно было решить только методом подбора. И это мое первое тестовое задание, так я учился.
Так вот, тогда у этой компании, у «Уютерры», возникла потребность в системной работе со складом, и для этого им пришлось писать свою WMS на 1С с нуля. С нуля — это долго. Поэтому, чтобы быстрее запуститься, мы в содружестве с Андреем Межовым выступили неким тандемом. Андрей – Java-программист, достаточно известная личность, он на Инфостарте зарегистрирован, у него множество статей про интеграцию Java и 1С.
Так вот, я передавал ему свои знания по платформе 1С – рассказывал, какие платформенные 1С-ные объекты нужно брать для реализации конкретной бизнес-задачи (например, для инвентаризации и т.д.), а он получал быстрый запуск.
Конечно, он все равно кодировал на 1С-платформе в Java-стиле. Три месяца плевался – говорил, что это отстой и т.д. Но потом сказал, что «1С – рулез». Я не скажу, что я ему очень сильно помог, но мы здесь выступили тандемом, и он смог быстрее запустить бизнес-задачу. Не удивлюсь, если потом окажется, что он в процессе рефакторинга этой WMS-системы на 1С ее просто выкинул и написал потом новую с нуля. Но я ему помог быстрее понять контекст задачи, как работает складская логистика в торговле. Это довольно большая проблема. Понять, как работает кассир на кассе – не каждый дотнетчик сможет.
Да, это надо увидеть глазами и прочувствовать на себе.
Это типовая проблема, которую можно перевести в деньги – я обычно люблю деньгами, затратами людей убеждать. Когда приходится общаться с заказчиком, приходится деньгами мерить.
Типовая проблема: я прихожу к тебе как заказчик, и ты дотнетчик, или явер, или питонер. Я прихожу к тебе и говорю: «Мне на кассу нужно простое кассовое ПО». Обычно люди отвечают: «Сформулируйте бизнес-требование, напишите бумажку, тогда я начну». Что делает одинэсник: «Какие бизнес-требования? И так все понятно. Этой торговле 2 с половиной тысячи лет, все требования давно описаны. Значит, сейчас сделаем. Сколько денег дадите?» То есть, совершенно наоборот.
И мы, получается, полезны для дотнетчиков именно знанием методологии, бизнес-требований, мы можем спроектировать модель (первый концептуальный проект) и не тратить на это время.
О снижении затрат
Мне сейчас очень понравилось, как ты коснулся темы затрат. В последнее время — возможно, благодаря облачным вычислениям — очень часто стала проявляться такая ситуация, когда команду разработчиков выносят куда-то в регионы. Я, как IT-директор, вижу в этом, в первую очередь, снижение затрат. Какие плюсы и минусы видишь в этом ты, именно с точки зрения технического директора? Можно ли сказать, что от этого страдает качество кода? Или все-таки дело в затратах?
Качество от этого страдает точно.
Качество кода страдает однозначно?
Все страдает. Во-первых, когда у тебя сложнораспределенная команда, управлять этим почти невозможно. Единственный, кто умеет этим управлять – это, по-моему, Александр Белов. У него единственного опыт управления успешный.
У разработчиков такой команды должен быть особый психотип. Ты не можешь где-нибудь в Ижевске или Екатеринбурге нанять человека с характером стационарного разработчика. Тебе нужно искать совершенно другого человека, который сумеет работать в удаленной команде, отчитываясь перед «центром».
В распределенной команде затраты на управляемость в целом повышаются. Кажется, что ты экономишь на деньгах, на ФОТ (фонде оплаты труда) за счет того, что уходишь в регионы, но ты начинаешь терять на управляемости.
Когда ты строишь свою команду, тебе в любом случае нужно делать отдельный маленький отдел разработки методологический, обособленный, со своим руководителем, с офис-менеджером и так далее. Тогда это хоть как-то работает. Тогда этот центр затрат окупается, потому что он делает конечный продукт. Это из практики.
Если тебе кто-то говорит, что разработка в распределенной команде будет более выгодной, то они врут, они просто говорят, что по деньгам, по ФОТ это будет менее затратно. Но общий объем затрат — это называется общая стоимость владений – на удаленной разработке, скорее всего, получится более высоким. И дело здесь не в качестве, а в затратах, которые ты будешь нести.
То есть я правильно понимаю, что зачастую говорят о том, что прямые затраты — эти первоначальные инвестиции (если так можно сказать) будут меньше, но вот о косвенных, которые влияют на общие косты, — о них действительно либо забывают, либо специально умалчивают?
Обычно люди, когда выводят офис вовне, осознают ситуацию с косвенными затратами примерно так: ух ты, оказывается, косвенные затраты получаются гораздо выше, чем в той же Москве, в Питере или других центральных городах.
А есть разница между разработчиками простыми и разработчиками 1С именно с точки зрения удаленных компаний?
Из практики я не видел. Деньги разные, а процентовка та же.
На удаленном офисе тебе все равно понадобится «чемпион», стоимость которого будет раза в два выше, чем типовая средняя планка по зарплате. И в итоге тебе нужно будет это маленькое лидерство компенсировать за счет затрат на офис, может быть, даже сокращать затраты на маркетинг, бухгалтерию. Но иногда и бухгалтер нужен будет местный на всякий случай, или офис-менеджер. Практика такая.
Я ж сам выходец из регионов. Я же в Москве-то только последние года 4, а до этого меня помотало от Ростова до Пскова и даже в Сибири я, так получилось, был некоторое время. Я в основном, в регионах работал.
Об облаках
Хорошо. А если использовать какие-нибудь новомодные инструменты для групповой разработки в облаках, где все работают в одном месте и вживую не общаются?
Во-первых, для 1С мира это еще пока не создано. Есть наши попытки в содружестве с ребятами, специалистами по Linux, сейчас развернуть облачный конфигуратор – специальную систему для групповой разработки конфигурации в облаке с настроенным окружением, со всем инструментарием. Этот конфигуратор сейчас проходит внутреннее бета-тестирование. Может быть, удастся выкатить его в ближайшее время или сама компания 1С, возможно, сделает что-то подобное в перспективе.
Правильно ли я понимаю, что это просто некая виртуальная машина с запущенным конфигуратором, тогда вопрос — как там организован множественный доступ, как идет совместная разработка в нем?
Давай так, отделим мух от котлет. Убираем слово 1С. Инфраструктура разработчика в облаке — это большая проблема сейчас на всем рынке. В 1С, в Java, в .NET, в Java Script и так далее.
Сейчас есть такой концепт Vagrant. 1С: Битрикс его использует (только начал использовать). Это когда к тебе приезжает маленькая виртуальная настроенная машина с развернутым Битриксом – чтобы ты не тратил время, а сразу начинал кодировать. Точно так же ты можешь Битрикс развернуть у себя локально на виртуальной машине, или где-то в облаке – своем, если оно у тебя есть, или в частном – как угодно. В итоге мы оперируем этими маленькими виртуальными операционными системами, которые приезжают к тебе предустановленными и автоматически обновляются. Такой тренд везде. Поэтому слово 1С убираем – это везде сейчас так.
Это сокращает затраты. Например, на покупку железа. Потому что если представить себе некий идеальный стационарный компьютер разработчика 1С, то он сейчас будет стоить, наверное, порядка 40 тысяч рублей, если покупать его совсем-совсем дешево. Хотя по нынешним ценам даже, наверное, уже 60. Там должно быть что-то наподобие i7 (многоядерщик), 16 гигов оперативки и SSD-винт терабайтник для работы с кэшем конфигуратора, чтобы все туда влезало.
Ну да, софтовые требования растут быстрее.
Да, и надо окупить 90 тысяч рублей. Если ты работаешь в Москве, можно это как-то сделать, а в регионе 90 тысяч рублей даже с кредитом окупить достаточно сложно.
А при использовании удаленного окружения тебе достаточно просто браузера или какого-то стационарного клиента, который будет с этим работать по сети. При развитии каналов связи (а они еще развиваются) это будет достаточно хорошо и удобно. Поэтому это действительно интересный тренд.
А как в вашем случае с облачным конфигуратором будет влиять скорость канала? Вроде как понятно, что это будет влиять на отображение картинки, но насколько будет хороша производительность на стороне облака? И от чего она будет зависеть?
Из практики — производительность там будет в 3-4 раза выше, чем, допустим, у тебя на локальной машине даже с SSD. Потому что производительность самого решения уже зависит от поставщика этого решения.
Все наши конечные бизнес-решения, конечный консалтинг, практики мы все-таки продаем. Но инструментарий для того, чтобы люди развивались, мы выкладываем в OpenSource.
Как образовалось наше сообщество? Мы делились своими инструментами, своими наработками. Да и Инфостарт так образовывался. Весь инструментарий выложен. Так мы, получается, его отлаживаем. Инструментарий (тот же Снегопат), он же во многом производительнее, чем 1С, в несколько раз. Работа с конфигурацией, работа напрямую с 1С-ным хранилищем там тоже реализована в несколько раз быстрее, чем штатная работа. За счет того, что есть хорошие Си-шники, иногда ассемблеристы попадаются.
Ну да, Мерседес AMG, он, конечно, лучше, чем просто Мерседес, потому что доводится до ума.
Да, например, есть мнение о том, что 1С на виртуальных машинах тормозит и снижает производительность раза в два. Но есть и другое мнение, что если правильно настроить виртуализацию, то она не будет проигрывать по производительности. А если грамотно настроить параллельность потоков, то есть немного по-другому реализовать код внутреннего инструментария, распараллелив потоки, то можно выиграть по сравнению с обычной типовой машиной раза в два с половиной. Это из практики.
Поэтому производительность там на самом деле получается выше, чем на локальной машине за счет того, что ты внедряешь эту многопоточность или, иными словами, подход MapReduce, — когда мы распараллеливаем поток и потом финально только собираем. То есть синхронно происходит только поток сборки, а распределение нагрузки должно происходить горизонтально. Но это уже зона архитектуры. Приблизительно так же и 1С-ный кластер работает в 8.3. Весь код должен быть асинхронным, должен выполняться в несколько потоков, чтобы это можно было параллелить, управлять памятью и так далее.
Об экспертах в мире 1С-программирования
Ты говоришь о том, что 1C-ники лукавят, когда говорят, что знают только 1С, потому что помимо этого они знают и другие языки программирования. Не значит ли это, что мы стоим на грани какого-то переломного момента? Раньше 1С-ником назывался тот, кто программировал в 1С. Теперь же он должен разбираться в виртуальных машинах, знать XML, должен понимать, как настраиваются сервера Postgre под Linux...
То, о чем ты говоришь, называется «Эксперт по производительности». Ему нравится разбираться, как ведет себя 1С в окружении Linux или в окружении Windows. Он изучает производительность на разных серверах – на Windows Server 2012, Windows Server 2008 – они разных денег стоят. Что-то из них ему удобнее, он может с этим работать. Он совершенно не занимается автоматизацией бизнеса, но все равно он специалист 1С. Эта грань нивелируется. Он просто специалист, эксперт по инфраструктуре, окружению для 1С.
Ставишь такому человеку, например, сервер приложений Tomcat на Java, и он говорит: «А, какая-то очередная службочка, не 1С-ная, ну да, на Java, но ведет себя так же». И он внезапно становится специалистом по поддержке инфраструктуры для серверов приложений.
Правильно ли я понимаю, что в отличие от айтишника 95го года, который сам ставил 1С, и потом за два дня давал бизнесу какое-то полуработающее, но работающее решение, нынешний 1С-ник, в узком смысле, играет главенствующую роль, а остальные 2 отдела разработки выполняют поддерживающую функцию? Не получается ли так, что за счет этого мы и приходим к «миру во всем мире»?
Может быть и так, но тут есть другой вопрос. Снова в деньгах. Бог с ним, с технократией, технические вопросы там все решены. Теперь вопрос, как это монетизировать и как на этом заработать.
Так вот сейчас, при переходе в «модель сервиса» начинается новая модная тема — это микросервисы, микрокоманды. Люди начинают говорить о том, что IT вдруг становится не центром затрат (как служба поддержки), а центром заработка. По новой идеологии, любая IT-служба должна зарабатывать, поэтому фактически мы должны на внутреннюю службу повесить биллинг (подсчет выгоды), и условно 1С-ник покупает у дотнетчика какую-то его услугу.
«НОВАЯ МОДНАЯ ТЕМА — МИКРОСЕРВИСЫ, МИКРОКОМАНДЫ»
По сути, некий внутренний хозрасчет.
Да, и если каждый микропроцесс там будет делать микрокоманда, то они друг у друга просто покупают эти сервисы на партнерских отношениях. Причем модель франчайзинга и типового «обновлятора» – это тоже просто один из сервисов. Для бизнес-заказчика он выглядит как типовой 1С-ник, который приезжает, обновляет ИТС, может поговорить с бухгалтером по душам, рассказать ему о нововведениях, которые он вычитал на ИТС. Это сервис, поддержка за базовые деньги. Но этот сервис также обеспечивает и проектную деятельность, потому что если у тебя есть служба такой поддержки, то за счет нее развивается в целом также еще и отдел разработки, ведь на самом деле настоящие требования от бизнес-заказчика приносят сотрудники этого сервиса, потому что они с пользователями по душам разговаривают.
Можно сказать, что это, по сути, некая техподдержка?
Нельзя. Техподдержка – это те, которые технарят и больше ничего не делают. В реальности это не так.
Происходит следующее: человек поехал, обновил ИТС, поговорил с бухгалтером по расчету зарплаты, и вернулся обратно в команду разработки. В этот момент бухгалтер направил на разработку требование добавить реквизит «Ромашка» (это реальное требование, оно действительно так звучало). Настоящий разработчик смотрит и негодует: что за реквизит «Ромашка», о чем речь вообще?
А тут к ним приходит тот самый «обновлятор», и объясняет, что там, на самом деле, проблема вот в чем: большая ротация персонала, человек может уволиться и вернуться в следующем году, они таких сотрудников на жаргоне называют «ромашками». Потому что у них два трудовых договора, а справка 2-НДФЛ одна. Поэтому и попросили добавить такой реквизит в справочник сотрудников, чтобы не было проблем с налоговой. Оказалось, что они об этом «за чаем» поговорили во время обновления ИТС. Следовательно, и не надо ничего дорабатывать, потому что это и так есть в стандартном функционале ЗУП.
В результате получилось, что аналитиком здесь выступил вот этот человек, который съездил и пообщался.
Но это опять же при условии, что он хорошо знает типовую конфигурацию, и вообще понимает суть проблемы, а также специфику бизнеса – то есть это должен быть 1С-ник определенного уровня.
Да. Но он же этого уровня должен достигнуть.
Само собой.
О переходном периоде
Проблему людей, которые не развиваются, можно решить двумя способами. Что сейчас происходит на рынке?
Есть люди вроде нас с тобой, которые развиваются сами, понимая, что иначе нельзя. По этому поводу есть закон Мура, который говорит о том, что дальнейшее развитие технологий идет быстрее и быстрее. Значит, нам надо накопить базовый инструментарий, чтобы успевать за развитием, чтобы быть быстрее, чем развитие. И тогда мы сможем быть в тренде и нивелируем эти риски, поскольку сейчас думаем о том, что будет завтра.
А есть другие люди, которых вынуждает уже сама платформа. Ты ведь знаешь, что очень многие ушли из 1С мира только потому, что слышали, что 1С платформа — плохо и так далее. Но на самом деле, они не смогли перестроиться от подхода 7.7 к подходу 8, от подхода 8 к подходу 8.3. Я очень часто говорю о том, что подход 8.3 в Java-мире (и не только) — это стандарт де-факто: трехзвенка с вызовом от клиента и выполнением на сервере. Если бы кто-то из Java-разработчиков пришел бы сейчас в 1С разработку, то в 1С 8.3 он был на коне, потому что здесь для него все было бы знакомо
Я помню, когда я переходил с Delphi на программирование в семерке, я, наверное, в течение нескольких месяцев программировал следующим образом: сначала в голове формировал код в английском варианте, а потом переводил это все в русский код на 1С. И ошибки отлавливал ровно таким же способом.
Ну, это такие затраты на переходный период. Цель-то хорошая.
Да, на выходе получилось хорошо.
А второй тип людей — это те, которые не успевают за развитием (развитие-то идет непрерывно). И в итоге их либо выкидывают с рынка, либо подставляют, либо переквалифицируют, либо увольняют.
Либо ты развиваешься, либо тебя развивают, либо ты вообще выпадаешь из этой схемы?
Да. Можно вообще уехать, сбежать. На моей памяти был случай, как айтишник уехал в «глушь, в Саратов» и стал фермером. Ему это надоело, он понял, что IT —не его. И это тоже нормально.
Мы же говорим о том, что любую проблему можно решить – иногда проблему можно решить, просто «зафиксировав убытки». Если мы понимаем, что IT – это не наше, мы можем иногда (очень редко) зафиксировать убытки и сказать – все, я не IT-шник.
Это в любой области, в принципе.
Да, слово IT убираем, и на самом деле фиксация убытков есть в любой методологии. Так бывает, это не страшно.
Раньше я тоже был ортодоксом. Например, когда был явером, я негативно относился к 1С. Когда я был 1С-ником, считал Java слишком медленной. Но теперь, после того как я побывал «по обе стороны баррикад», я пришел к некому гетерогенному подходу (к некому «дзену»), что нет «плохого» и «хорошего», а есть проблема, есть язык и есть решение. Главное, чего хочет человек, к чему он испытывает любовь, желание и так далее.
«ЕСТЬ ПРОБЛЕМА, ЕСТЬ ЯЗЫК, ЕСТЬ РЕШЕНИЕ»
«Из любви к искусству»
Мы возвращаемся к тому, что в приоритете те люди, которые любят то, чем занимаются. Их главный мотив — не деньги, а любовь к делу и саморазвитие.
Они развиваются. Они обычно на слуху и виден результат их работы. А есть и те люди, которые не хотят развиваться и выполняют какую-то рутинную работу. Не скажу, что я согласен с их взглядами, но такие люди тоже необходимы.
Мы сейчас говорим про развитие и про разные типы людей. Насколько я знаю, ты участник различных сообществ, в том числе и 1С-ных. Мы только что говорили о том, что меняются парадигмы, концепция. На твой взгляд, будет ли какое-то изменение в самих сообществах? Будут ли они как-то перестраиваться, например, тот же Инфостарт, будет ли смена состава, аудитории?
Инфостарт в любом случае будет развиваться. Куда он денется, он с 2006-го развивается. Я в Инфостарт-сообществе зарегистрировался в 2007 году.
«ИНФОСТАРТ В ЛЮБОМ СЛУЧАЕ БУДЕТ РАЗВИВАТЬСЯ»
Мы с тобой одногодки.
До этого я общался на 1С ProClub и 1С++. На Мисте мне не очень нравилось, потому что там было мало практики, я не развивался там. Поговорить там наверное можно было, но только этот разговор меня никак не развивал. А на форуме 1С++ было более профессиональное общение и авторы этой компоненты меня многому научили. Поэтому у них на форуме я общался, учился у них, и они меня учили.
Кстати, знаешь, как мы пришли на Инфостарт? Просто в определенный момент в 2007м мы решили опубликовать там свои наработки – тогда больше было некуда опубликовать, и нам тут нравилась система рейтинга «+1». Это было классно. Мы, как конечные пользователи «плюсиков», ими в то время «мерились» :)
Помню, помню.
Об ИТ-сообществах
Я с тех пор наблюдаю, что сообщество Инфостарт развивается, видоизменяется. Становится меньше троллинга, больше профессионализма, больше возможности получить ответ. Общение «ни о чем» уходит в социальные сети, а в профессиональных сообществах остается профессионализм. Когда ты выдаешь публикацию, задаешь вопрос на форуме, и в результате получаешь вменяемую критику.
Есть подход GitHub — это когда идет социализация с помощью кода. Там ты публикуешь код наработки, там изначально используется подход «меньше слов — больше дела». А на Инфостарте ты публикуешь сами наработки, и люди их оценивают. В сторону такой коммуникации, как мне кажется, и будет стремиться дальнейшее развитие везде. На ХабраХабр таким же образом общаются сайтописатели на PHP – там тоже большинство ссылок о том, что «ребята, я сделал, вот ссылка на мой код». А в комментариях люди в качестве ответов дают новые ссылки и т.д. Профессиональные сообщества развиваются не как сообщества «пообщаться», а как сообщества «помочь».
Новый виток пошел в развитии.
Да. Один мой знакомый из Сколково говорил, что активность — это то же самое, что и записи в регистре сведений, активити стрим. Главное, какая сущность является регистратором для этой активности.
Общение становится неформальным, а сущность становится профессиональной. Такой тренд я наблюдаю последние года три – он пришел из Америки, там уже есть примеры, как это все еще и капитализировать. В Россию такой подход пока не пришел, но скорее всего, придет. И я думаю, что Инфостарт будет первым, кто это привнесет.
«ОБЩЕНИЕ СТАНОВИТСЯ НЕФОРМАЛЬНЫМ, А СУЩНОСТЬ СТАНОВИТСЯ ПРОФЕССИОНАЛЬНОЙ»
О философии Серебряной пули
Ты всю передачу держишь в руке патрон. Я знаю, что ваша команда на данный момент называется «Серебряная пуля». Но при этом написание сайта SilverBulleters. Если бы была просто Серебряная пуля – тогда было бы Silver Bullet. И если взять некую аналогию и транскрипцию, то получается, что вы – серебряные билетеры. Вопрос следующий: кому и что вы продаете? Серебряные пули или все-таки осиновый кол и чеснок?
В любом действии должна быть философия. В том числе, и в названии.
Помнишь, я говорил про 4 авторов: Брукс, Вирт, и Уорд и Хьюдак. Это же 2 лагеря. Брукс и Вирт там за одно воевали. А Уорд и Хьюдак — за другое. И там у Вирта есть цитата, которую знает большинство айтишников. Это — «Серебряной пули не существует», нет технологии, которая была бы «Серебряной пулей».
Так вот, серебряная пуля не существует, а люди – «серебряные пули» есть. То есть технологии может не быть, но зато есть человек, который решит проблему. А теперь переведи мне, пожалуйста «человек-серебряная пуля» на английский язык. Или «люди — серебряная пуля». Вот этот обыгрыш и лег в основу названия сайта, потому что это отражает тот концепт, который мы для себя выбрали.
«СЕРЕБРЯНАЯ ПУЛЯ НЕ СУЩЕСТВУЕТ, А ЛЮДИ – «СЕРЕБРЯНЫЕ ПУЛИ» ЕСТЬ»
То есть разница в названии компании и названии сайта латиницей — сознательная?
Да, и в это заложена большая философия. Делалось так, чтобы заложить туда больше философского смысла и, возможно, меньше маркетинговой привлекательности. Потому что мы технари, наша задача – решить конкретные проблемы. Как мы это делаем – отдельный вопрос. Инструменты все бесплатные. А вот знания о том, где ткнуть в паркет и как решить проблему – это и есть платный продукт. Это мало кто делает. Мы выбрали для себя такую монетизацию, такую нишу.
Хорошо, Алексей, я тебя благодарю за беседу. Что бы ты пожелал нашим зрителям напоследок?
Я все-таки большинству людей советую сейчас, особенно в текущих реалиях, попробовать разработать, спроектировать, спрогнозировать некую стратегию своего развития в целом. Поступить как стратег по отношению к себе. Попробовать создать план того, как ты будешь развиваться сам, как ты будешь общаться лично, как ты будешь отдыхать и т.д. Желательно, чтоб вы его создали года на 3 вперед, попробовали накидать, ведь тут не страшно ошибиться.
Главное — движение. Развиваться можно в любом направлении. Я советую больше делать какие-то вещи руками, хотя бы прототипы. Желаю вам в будущем трехлетии и в ближайший год побольше интересной работы в целом и поменьше проблем дома. Чтобы жены вас понимали, близкие, родители.
Леша, спасибо тебе большое. Друзья, делайте больше ошибок и получайте больший опыт. С вами была программа «Готовые решения» и я, Сергей Горшенин. Ну, а пока — конец процедуры.
______________________________________________________________________________________________________
Посмотреть и послушай нас можно здесь:
youtube
itunes
podfm