Тема доклада – разработка и внедрение в новой реальности. Когда мы согласовали эту тему, я наивно полагал, что новая реальность уже понятна и неопределенность снизилась. Но как говорится в известном анекдоте: «Только показалось, что хуже уже быть не может, и снизу постучали». Тем не менее я думаю, что доклад остается актуальным, и те техники, приемы, подходы, о которых пойдет речь, будут полезны.
Все, что я буду рассказывать, исходит из практического опыта. Это не просто теоретические рекомендации или методы, прочитанные в книгах, хотя я действительно прочитал о них в книгах. Это то, что было реально опробовано в работе нашего подразделения БИТ:ERP в компании «Первый БИТ»:
-
Мы занимаемся внедрением 1С:ERP в торгово-производственных компаниях. Среднее количество пользователей на наших проектах – 1000 человек. Минимальный проект за последние несколько лет насчитывал 100 пользователей, самый крупный – в районе 4000.
-
Есть продуктовая разработка – как на платформе 1С, так и на Python, Java, C++.
-
Некоторые знают нас по активности в части open-source движения – наши разработки можно увидеть на GitHub. Например, PinkRabbitMQ – компонента для обмена с RabbitMQ.
-
И у нас относительно новое направление – это промышленная автоматизация, Industrial Internet of Things (IIoT), промышленный интернет вещей. Это сборка шкафов управления, программирование логических контроллеров, SCADA-системы и так далее.
На слайде – цитата Виктора Франкла. Это австрийский психиатр, философ, психолог, невролог, практик. В юности он был узником нацистского концлагеря, и на основе своего опыта написал множество трудов. Его книга «Скажи жизни: Да!» произвела на меня сильное впечатление. Она переведена на русский язык, и это, пожалуй, то, что я рекомендовал бы прочесть в первую очередь.
Слова на слайде отражают наблюдения Виктора Франкла о жизни в концлагере. Я считаю, что этот же подход нужно использовать и в текущих обстоятельствах, в текущей реальности:
«Первыми ломались те, кто верил, что скоро все закончится. За ними идут те, кто не верил, что это когда-нибудь закончится. Выжили те, кто сосредоточился на своих действиях, без ожиданий того, что может произойти или не случиться».
В нашем случае это значит, что лучше сконцентрироваться не на обсуждении новостей и просмотре новостных лент Telegram-каналов. На это мы повлиять не можем, а время, силы, энергию и внимание это у нас отжирает.
Нужно сконцентрироваться на том, на что мы можем повлиять – на нашей работе и том, что мы делаем. Поэтому дальше доклад будет про подход к новой реальности в рамках того решения, которое предложил Виктор Франкл.
Риски
Изначально я формулировал на этом слайде факты новой реальности. Сейчас слайд называется «Риски», потому что неопределенность повысилась:
-
Понятное дело, что санкции никуда не денутся, но если раньше у нас импортозамещение позиционировалось в виде западозамещения, то в ближайшее время оно действительно может стать импортозамещением – в силу того, что оборудование из Азии тоже будет использовать проблемно.
-
Обострение дефицита специалистов 1С – это риск, который сейчас есть, а как дальше будет развиваться ситуация – непонятно.
-
И падение спроса на автоматизацию. Казалось бы, этот риск исключает предыдущий, но есть опасения, что для нас актуальны оба этих риска. Чуть позже я объясню, почему.
-
И расширение государственного вмешательства в экономику – это тоже риск, потому что мы привыкли работать в одной среде, а она может оказаться другой. Сейчас степень государственного вмешательства в экономику высокая, остается примерно на том же уровне, что и раньше. И пока предпосылок для ее расширения не видно – мы как работали, так и работаем. Но это не перестает быть риском.
Импортозамещение инструментария внедренцев
Теперь по конкретным инструментам. Первое, что мы сделали у себя в подразделении для работы с рисками – это начали переход с Windows на Linux.
На рынке часто встречается ситуация, когда интегратор переводит клиентов с Windows на Linux, при этом сами разработчики 1С, консультанты, внедренцы, администраторы цинично продолжают работать на Windows – применяют новые практики к заказчику, не применяя их к себе.
В принципе, это нормальный подход, потому что перевести на Linux сервер 1С и перевести на Linux пользовательское рабочее место, особенно рабочее место разработчика – это разные вещи.
Но мы решили начать с себя и действительно перевели всех сотрудников нашего подразделения на Linux. Сейчас все рабочие станции разработчиков работают под Linux. И большинство серверов тоже под Linux.
На слайде – реальный скриншот, как выглядит конфигуратор на Linux. Если коротко, по итогам всех страданий, выполнения инструкций, подгрузки виндовских шрифтов и так далее – он выглядит практически так же.
А это – скриншот Visual Studio Code, в котором у нас редактируется автотесты на Gherkin. Мы используем Vanessa Automation, поэтому нам было важно, чтобы с редактором кода тоже было удобно работать.
У нас было три этапа перехода на Linux:
-
До начала перехода казалось, что Linux – это страшно и непонятно. Все привыкли к Windows, никто не хотел переходить. Под «никто» я имею в виду разработчиков.
-
Потом, когда причина и необходимость перехода стала очевидна, мы начали искать решения – стали анализировать, насколько сложно будет перейти.
-
А когда мы все проанализировали, возникло другое ощущение – что перейти будет совсем легко, все произойдет чуть ли не по щелчку пальцев. Правда, это оказалось не совсем так. В итоге сложность перехода оказалась где-то посередине между «это очень сложно, на грани невозможного» до «все очень просто, за один день перейдем».
Мы посмотрели, какие основные приложения у разработчика 1С:
-
Конфигуратор. Я думаю, что примерно 60% рабочего времени у разработчика так или иначе открыт конфигуратор, он в нем работает.
-
Браузер – чтобы что-то гуглить, читать.
-
Редактор кода, чтобы редактировать, просматривать сценарии – у нас это Visual Studio Code.
-
Разумеется, 1С в режиме предприятия, чтобы смотреть, что я сделано, и пользоваться DevOps-сервисами.
И все.
А поскольку у нас полностью облачная инфраструктура, все работают через удаленный рабочий стол, нам показалось, что если вдруг какое-то приложение не работает под Linux на удаленном рабочем столе, – разработчик может запускать его на своем личном компьютере.
Чтобы говорить о нашем опыте более практически, не ограничиваясь рекомендацией: «Переходите все на Linux!», я подготовил список того, что нам было бы полезно знать перед началом перехода.
-
Во-первых, задача организации на Linux рабочего места для пользователя, который будет интерактивно работать с системой через пользовательский интерфейс, и задача организации на Linux администрирования серверных приложений (для сервера 1С:Предприятия, сервера баз данных, брокера сообщений RabbitMQ и т.д.) – это разные задачи. Людей, умеющих организовать рабочее место на Linux для пользователя, гораздо меньше, чем тех людей, которые хорошо умеют администрировать серверы на Linux.
-
Во-вторых, работа конфигуратора 1С под Linux имеет ряд особенностей. Часть из этих особенностей хорошо описана в документации – любой человек, который начинает работать в Linux, достаточно быстро разберется со шрифтами и поймет, что нужно сделать, чтобы это нормально работало. Важно, чтобы когда вы запустите 1С:Конфигуратор и убедитесь, что он в принципе работает под Linux, этим дело не закончится. В нашей практике возник вопрос стабильности работы и подвисания. Причем подвисание нерегулярное и даже недостаточно частое для того, чтобы администратор, который все это настраивает, мог это обнаружить. Это обнаруживается в течение рабочего дня – за 8 часов разработчик с этим сталкивается. Такие плавающие проблемы доставляют много нервов, и тратится много времени. При этом надо помнить о том, что пока опыт работы разработчиков 1С на Linux еще не такой большой. На форумах, в том числе партнерском, не так много релевантных тем. И когда ты гуглишь проблему, возникшую при работе конфигуратора 1С на Linux, высока вероятность, что никакого решения не найдешь. Тем не менее у нас все получилось – все это работает.
-
Следующая проблема, которая для нас тоже стала неожиданной – это то, что ряд типовых конфигураций 1С совсем не рассчитаны на Linux. Самый болезненный для нас пример – это сборщик мобильных конфигураций. Мы разрабатываем тиражное решения БИТ:MDT для терминалов сбора данных, и наш программный продукт в пике разработки релизился до сотни сборок в день. При этом фирма «1С» говорит, что сборщик не будет поддерживать Linux, и правильнее делать сборку через веб-сервис. Но веб-сервис и сборщик решают разные задачи. И сто раз зайти вручную, собрать, подождать и дальше продолжить цикл тестирования – это явно не то решение, которое нас устроит. Поэтому часть серверов у нас пока что остаются на Windows.
-
Ну и помните о том, что для Linux мощностей потребуется больше – в первую очередь, оперативной памяти. Но если вы уже работаете в облаке, и потребляете облачные ресурсы, для вас это серьезной проблемой не будет, потому что виртуальная память сейчас относительно дешевая.
Миграция с Atlassian Jira на Yandex Tracker
Дальше – миграция с Atlassian.
До февраля 2022 года мы использовали облачные продукты Atlassian для управления процессами и документацией – это Atlassian Jira, Atlassian Confluence и Jira Service Desk. Понятное дело, что с 24 февраля достаточно резко стало невозможно им пользоваться с точки зрения оплаты. А в последнее время и официально, даже если ты решил вопрос с оплатой, то все равно, скорее всего, пользоваться не сможешь.
На скриншоте пример Scrum-доски, спринт конкретной команды, как это выглядит в Yandex Tracker. Сразу скажу, что мы посмотрели достаточно много продуктов, и Yandex Tracker оказался практически единственным, который нам подошел.
У нас были специфичные требования – к примеру, у нас было требование, что мы не хотим сами хостить систему. Возможно, если вы готовы развернуть сервис на своих серверах администрировать его 24/7, 365 дней в году, наверное, у вас будет какой-то другой выбор. Мы этот выбор не рассматривали, поэтому выбрали Yandex Tracker, потому что больше ничего не нашли из того, что там подходит.
Из минусов – понятное дело, что это далеко не Jira, но все основные функции там есть, и работать действительно можно и удобно. Там есть:
-
бэклог;
-
канбан-доски;
-
все необходимые поля;
-
интеграция с Yandex Wiki.
Но там нет интеграции с Git – она формально есть, галочка стоит, но исходите из того, что интеграции там нет. Те, кто пользуется Git, может попробовать и поймет, о чем я.
Еще неожиданно понравилось, что там верная терминология. Тех, кто заморачивается с продуктовой разработкой, может смущать тот факт, что в Jira пространство для задач называется «проектом», при том, что мы работаем над продуктом. А Yandex Tracker развивался как Service Desk, поэтому у него термин «очередь». Этот термин тоже не очень удачный, но гораздо удачнее, чем «проект», с моей точки зрения, потому что нет никакой путаницы с продуктовым подходом.
Миграция с Atlassian Confluence на Yandex Wiki
С Yandex Wiki ситуация обратная. Если Yandex Tracker у нас хорошо зашел – им без проблем пользуются и наши разработчики, и сотрудники заказчика. То с Yandex Wiki возникли проблемы. Он удобен только для тех, кто знает Markdown, и любит на нем писать. Для всех остальных пользователей, кто привык работать в Word или в Confluence, в Yandex Wiki будет сложно. Имейте это в виду.
Тем не менее на Yandex Wiki мы тоже перешли, во многом потому, что у нас нет больших требований к Wiki-системе. Мы делаем упор не на мертвую документацию, существующую отдельно от кода где-то там в Wiki. Мы при любой возможности предпочитаем написать сценарий тестирования в виде автотеста, который будет каждый раз обновляться и прогоняться при мерже в мастер.
По лайфхакам о том, на что мы успели перейти за последнее время – я все, что мог, рассказал.
Уровень зарплаты vs Число специалистов
Теперь расскажу о дефиците специалистов 1С.
Многие знают картинку, которая иллюстрирует главный тезис экономической теории – чем больше спрос, тем больше предложений. Но это – наивная экономическая теория, вернее, представление об экономической теории от тех людей, которые не читали экономическую литературу.
А те, кто читал экономическую литературу, знают, что специалисты по 1С не могут взяться откуда-то мгновенно, их количество на рынке условно постоянное и может увеличиваться по мере роста зарплаты только в долгосрочной перспективе. А в краткосрочной перспективе зависимость между спросом и предложением выглядит, как на этом слайде.
Но по нашему опыту зависимость спроса и предложения на рынке труда 1С-ников выглядит еще хуже – отсюда и дефицит специалистов.
Мы наблюдаем тенденцию: чем выше зарплату готовы платить компании – тем меньше специалистов на рынке.
Причем на предыдущем слайде была правда: количество специалистов 1С действительно может не меняться. Но если взять из них тех, кто действительно готов работать, их число сокращается.
Я не беру сейчас тимлидов, не беру сеньоров, я беру середнячков, на которых держится любая продуктовая разработка. Без них ни одна задача, по сути, не будет выполнена – тимлид не может сделать всё в одиночку.
Итого, середнячок. У него работа ассоциируется с зарплатой – чтобы получить зарплату, нужно поработать. Но как только он достигает комфортного для него уровня оплаты, он старается меньше работать, а большую часть времени посвящает своим увлечениям и хобби.
Если у тимлида хобби – это работа, он без проблем отправляет запросы на мерж в мастер в субботу или воскресенье, то от середнячка, конечно, такого не видишь. Понятное дело, что в свободное время человек отдыхает, занимается теми делами, которые его интересуют.
Это приводит к тому, что человек, который раньше вкалывал на проектах внедрения ERP, идет к заказчику на спокойную работу с меньшей загрузкой. И там получает те же деньги, которые получал раньше, но много работал.
Отсюда как раз утверждение, что падение спроса на автоматизацию и дефицит специалистов – не обязательно взаимоисключающие вещи, они могут совпасть.
ТОП-4 вопроса по Agile
Теперь дам ответы на вопросы, на которые меня попросили ответить в докладе организаторы.
Вопрос №1. Что выбрать: каскад или agile?
Первый вопрос – что выбрать в рамках проекта: каскад или agile?
Я взял на себя обязательство ответить в докладе на этот вопрос, но шансов быть услышанным и понятым у меня мало, потому что я отвечал на него много раз.
В 2017-м году на конференции Инфостарта я рассказывал, как выбирать Agile, и почему мы выбрали на конкретном проекте Agile.
Потом пытался ответить примерно на тот же самый вопрос в 2018 году.
И в 2019 году было примерно все то же самое.
В течение многих лет я пытался ответить на этот вопрос, используя ответы из книги Джеффа Сазерленда, которая называется «Искусство делать вдвое больше работы за вдвое меньшее время» или в русском варианте «Scrum: Революционный метод управления проектами». Книга реально интересная – если не читали, обязательно прочитайте.
Но если мы говорим про компанию и про команду, которая задает вопрос «Каскад или Agile?», эта книга особо не поможет в выборе, потому что эта книга про тех, кто такой вопрос не задает.
Если у вас вопрос: «Что выбрать: каскад или Agile?», то гораздо более правильный вопрос, который вам надо задать и единственный, это: «Что произойдет, если задача не будет решена в поставленный срок?» Ответ на этот вопрос вам нужно просто продиагностировать:
-
Если задача такова, что ее нельзя зафейлить, а последствиями срыва дедлайна будет «полярный лис», причем в жестких проявлениях (например, компания разорится, всех уволят и так далее) – однозначно ответ Agile, других вариантов нет.
-
А если проект задержится, задачи профакапятся, но на самом деле ничего страшного не произойдет – тогда каскад. В Agile даже лезть не стоит. Честно, это глупо. Ничем хорошим это не закончится.
Могу объяснить почему.
-
Agile – не гарантия успеха. Не гарантия, что работа будет сделана экономно. Даже не гарантия, что она будет сделана быстро.
Но если вы делаете проект по Agile, вы заранее узнаете о том, что он «не взлетит», и система не запустится. Это значит, что вы можете что-то с этим сделать. Если у вас задача, которую вы не имеете права зафейлить, вы, разумеется, будете пытаться сделать так, чтобы ее не зафейлить. Именно поэтому вы можете сменить команду внедрения, вы можете оказать какое-то воздействие на ключевых пользователей. Вы можете много чего сделать. В крайнем случае, если что-то пойдет совсем не так, вы можете резюме на HeadHunter выложить. -
А если мы говорим про каскад, то о фейле вы обычно узнаете внезапно – после большого взрыва, когда уже поздно что-то менять.
Важное ограничение: это утверждение применимо только тогда, когда вы не купили почасовку под брендом Agile. Я имею в виду «купили» в широком смысле – т.к. вы могли купить, условно, внутреннего подрядчика.
Вопрос №2. Чем отличается Agile от «почасовки»?
Отсюда второй вопрос: а чем отличается Agile от «почасовки»?
Если задать этот вопрос рядовым членам команды исполнителя, в большинстве случаев они честно скажут: «Да ничем не отличается, просто такой модный термин – Agile. Scrum проще продавать, поэтому мы раньше делали “почасовку”, сейчас мы делаем Scrum, а на самом деле разницы какой нет». А разница большая.
-
Если выбирать между «почасовкой» и каскадом, я бы выбрал каскад – там хотя бы какие-то шансы у вас появляются.
-
Шансы, конечно, есть и в «почасовке», но их меньше. Поэтому будьте аккуратны.
Чтобы разобраться в том, работает ваш подрядчик по Agile или нет, задавайте вопросы и оценивайте по Станиславскому «верю-не верю». Если специалисты подрядчика действительно работают по Agile, они смогут ответить на вопрос таким образом, чтобы вы поверили, что они действительно понимают, о чем говорят. Даже если вы не поймете какие-то детали.
Коротко расскажу про ключевые отличия Agile-подхода от «почасовки»:
-
Это мотивация команды. В Agile-подходе у команды нет мотивации закрыть больше часов – в документах по схеме мотивации подрядчика не должно быть ничего про часы.
-
У вас с подрядчиком нет торга по поводу трудоемкости конкретной задачи. Учет рабочего времени ведется – если он не ведется, это бардак, не имеющий никакого отношения к Agile, даже если кто-то говорит обратное. Но учет времени используется не для торга с заказчиком, не для подтверждения выполненных работ, а только для того, чтобы повысить эффективность. Просто потому, что конкретный лог часов помогает команде на ретроспективе понять, на чем она продолбалась, и что нужно изменить, чтобы в следующий раз быть эффективнее
-
Lean-мышление. Это борьба с потерями времени в производстве, избавление от незавершенки и так далее. Там достаточно много всего. Я уже рассказывал на конференции Инфостарта об этом.
-
Эмпирический подход.
-
Современные инженерные практики.
Вопрос №3. Как может быть в Agile-проекте фиксированный бюджет?
Третий вопрос – как в Agile-проекте может быть фиксированный бюджет.
Даю короткий ответ: в Agile-проекте бюджет фиксирован по определению, поэтому он только такой может быть. Если у вас не фиксированный бюджет, у вас не Agile-проект. Это определение.
На слайде – тезисно перечислены отличия подходов Agile и каскада относительно бюджета:
-
Agile – это про бизнес-ценность про outcome.
-
А каскад – это про артефакты, про результаты, про output.
Именно поэтому в Agile неважно, что конкретно мы делаем, важнее принести бизнес-ценность. А в каскаде – наоборот.
Вопрос №4. Продукт vs Проект. Когда продуктовый подход не подходит?
Ну и последний, четвертый вопрос: Продуктовый подход или проектный подход: когда продуктовый подход не подходит?
На него у меня короткий ответ:
-
Если вам не подходит Agile, тогда и продуктовый подход вам не подойдет.
-
И обратное утверждение тоже верно.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.
Приглашаем на конференции Инфостарта 2025 годаINFOSTART TEAMLEAD EVENT
Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров. INFOSTART A&PM EVENT (Анализ & Управление проектами)
Практическая конференция для аналитиков и руководителей проектов 1С. |