Разработка и внедрение в новой реальности: можете не меняться. Выживание не является обязанностью

Тема доклада – разработка и внедрение в новой реальности. Когда мы согласовали эту тему, я наивно полагал, что новая реальность уже понятна и неопределенность снизилась. Но как говорится в известном анекдоте: «Только показалось, что хуже уже быть не может, и снизу постучали». Тем не менее я думаю, что доклад остается актуальным, и те техники, приемы, подходы, о которых пойдет речь, будут полезны.

Все, что я буду рассказывать, исходит из практического опыта. Это не просто теоретические рекомендации или методы, прочитанные в книгах, хотя я действительно прочитал о них в книгах. Это то, что было реально опробовано в работе нашего подразделения БИТ: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-подхода от «почасовки»:

1. Это мотивация команды. В Agile-подходе у команды нет мотивации закрыть больше часов – в документах по схеме мотивации подрядчика не должно быть ничего про часы.

2. У вас с подрядчиком нет торга по поводу трудоемкости конкретной задачи. Учет рабочего времени ведется – если он не ведется, это бардак, не имеющий никакого отношения к Agile, даже если кто-то говорит обратное. Но учет времени используется не для торга с заказчиком, не для подтверждения выполненных работ, а только для того, чтобы повысить эффективность. Просто потому, что конкретный лог часов помогает команде на ретроспективе понять, на чем она продолбалась, и что нужно изменить, чтобы в следующий раз быть эффективнее

3. Lean-мышление. Это борьба с потерями времени в производстве, избавление от незавершенки и так далее. Там достаточно много всего. Я уже рассказывал на конференции Инфостарта об этом.

4. Эмпирический подход.

5. Современные инженерные практики.

Вопрос №3. Как может быть в Agile-проекте фиксированный бюджет?

Третий вопрос – как в Agile-проекте может быть фиксированный бюджет.

Даю короткий ответ: в Agile-проекте бюджет фиксирован по определению, поэтому он только такой может быть. Если у вас не фиксированный бюджет, у вас не Agile-проект. Это определение.

На слайде – тезисно перечислены отличия подходов Agile и каскада относительно бюджета:

• Agile – это про бизнес-ценность про outcome.

• А каскад – это про артефакты, про результаты, про output.

Именно поэтому в Agile неважно, что конкретно мы делаем, важнее принести бизнес-ценность. А в каскаде – наоборот.

Вопрос №4. Продукт vs Проект. Когда продуктовый подход не подходит?

Ну и последний, четвертый вопрос: Продуктовый подход или проектный подход: когда продуктовый подход не подходит?

На него у меня короткий ответ:

• Если вам не подходит Agile, тогда и продуктовый подход вам не подойдет.

• И обратное утверждение тоже верно.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.