Transcription
Чем занимается 1С программист уровня сир на удалёнке? Я это покажу вам на примере своего типичного рабочего дня. Так, поехали!
Меня зовут Алексей Лапицкий. Я в IT уже более 30 лет, и на фрилансе, и в 1С я работал более 20 лет. Сегодня, в первой части, я вам расскажу кратко о том, чем я занимаюсь в свой типичный рабочий день по 1С как программист уровня сир.
Это видео будет полезно тем, кто собирается войти в профессию и думает, подойдёт она им или нет. Это видео также будет полезным тем, кто уже давно в профессии и хотел бы как-то развивать свои навыки, кто, может быть, чем-то не удовлетворён или выгорает постоянно. И в этой первой части вы посмотрите, в чём отличается ваш рабочий день и мой рабочий день, и сделаете какие-то выводы.
А далее самое интересное будет во второй части: я более подробно расскажу о каждом этапе своего рабочего дня, дам развёрнутые комментарии по каждой из задач и по каждому из временных промежутков, которые были у меня в течение этого рабочего дня. Конечно, надо понимать, что этот рабочий день не записывался специально онлайн на моей работе. Это видео смонтировано таким образом, чтобы дать вам максимально усреднённый взгляд на то, как работают 1С программисты высшего уровня, уровня сир.
И если вы стремитесь к этому уровню, то вы должны понимать, что вас ждёт. А если вы собираетесь переходить сюда из другой сферы деятельности, то это вам даст понимание, к чему вы в итоге придёте, и, возможно, вы откажетесь от карьеры в этом направлении, увидев то, чем занимаются 1С программисты. Частенько люди неверно себе представляют о том, что их ждёт с развитием карьеры в какой-то области, и имеют какие-то мифы и ложное представление об этом. А в этом видео я хочу развеять эти ваши мифы и показать реальную жизнь, реальную рабочую рутину 1С программиста, чтобы вы знали, к чему вы, скорее всего, придёте и чем занимается 90% 1Сников этого уровня.
Это видео относится именно к высокому уровню программистов, потому что программисты начинающего уровня занимаются другими задачами, и их рабочий день проходит немного в другом ритме. Или, наоборот, если вы никогда не были программистом, у вас нет знакомых программистов, это видео окажется для вас также полезным. Оно даст вам представление о том, чем занимаются люди в этой профессии, какие задачи решают.
Итак, поехали!
Начинается рабочий день, естественно, в 7 утра. Завтрак, всякие утренние процедуры – на этом не будем останавливаться.
Дальше я сажусь за компьютер и просматриваю свой список типичных задач на день. И вообще, этот список, который остался с прошлых дней, с прошлых месяцев. Перечень задач может быть как состоять из одной задачи в хороших компаниях, где налажены процессы, так и из пары сотен давно зависших задач в компаниях, в которых не очень хорошо налажен процесс постановки задач. И из этого списка задач я понимаю уже, какие задачи мне взять в текущую работу, потому что у меня уровень позволяет определить важность и срочность этих задач. И я беру какие-то из этих задач.
Сегодня я выбрал для себя следующие задачи: это обновить расширение, код-ревью сделать, деплой, обсудить с аналитиками и заказчиком новую задачу, обсуждение архитектуры задачи с коллегами. Далее есть задача сделать форму документа и написать в ней обработчики. Дальше у нас будет ещё в конце дня собеседование с новыми кандидатами, и я должен в нём участвовать. Также ещё нужно изучить HTTP-сервис поставщиков, чтобы потом делать с ним различные манипуляции. Этот HTTP-сервис новый, неизвестный, и прежде чем что-то программировать, надо сначала изучить его API. Соответственно, вот наш план, который я выписал в столбик – это, так сказать, рабочие задачи. А вот зелёненьким отмечены личные задачи, которые мне надо ещё сделать в течение дня: соответственно, обед, перерыв на чай, немного прогуляться, перерыв на кофе и сходить в супермаркет за едой.
Начинается рабочий день в 8:00. Я сажусь, начинаю писать форму документа. При этом я обнаруживаю, что некоторые триггеры сработали в системе тестирования и мониторинга производительности, и они показывают, что у нас какая-то большая, огромная нагрузка на SQL-сервер. Я понимаю, поскольку это моя зона ответственности как программиста высокого уровня – следить за производительностью, за тем, чтобы все системы работали без сбоев, чтобы наши пользователи не жаловались, чтобы им было комфортно работать. Поэтому я не могу игнорировать этот триггер. Откладываю задачу по написанию формы документа и начинаю изучать, что же там произошло, в чём причина. И этим самым я занимаюсь до 9:00 утра.
Примерно в это время я заканчиваю с этой задачей, разбираюсь, в чём причина, исправляю её, отправляю необходимые уведомления нашим коллегам, чтобы они тоже были в курсе, что я эту задачу уже решил.
По плану у нас на 9:30 назначен был созвон с аналитиками, и примерно в 9:30 я освободился и сообщил аналитикам, что готов подключиться к звонку. И мы начали созваниваться с заказчиком и аналитиком, и со мной совместно, и обсуждать некоторую задачу, связанную с развитием нашей системы автоматизации, с развитием программы 1С в нашей компании.
А я, для тех, кто не понимает, в чём суть аналитиков, заказчиков и технических специалистов, немного быстро поясню, что тут происходит. Значит, есть заказчики задачи, то есть те люди, те организации, которые говорят: "Мы хотим сделать то-то, то-то, и сделайте нам это в 1С". Это могут быть внутренние заказчики, какие-то из других отделов, сотрудники, которые дают заявку на развитие системы 1С, чтобы в 1С какой-то новый функционал появился. Эта задача поступает аналитикам 1С, и аналитики готовят техническое задание для программистов, для технических специалистов вроде меня. И аналитики должны связаться с заказчиками, с постановщиками задачи, более подробно с ними обсудить эти все нюансы. И на основании этих бесед аналитик 1С составляет некую бумагу, некоторый электронный документ текстовый, в котором он подробно описывает, что за задача, как она должна быть решена. А чтобы более качественно сделать техническое задание, аналитику 1С иногда требуется помощь технических специалистов вроде меня, то есть программистов 1С в данном случае. И поэтому здесь будет созвон с заказчиками задачи, с нашими аналитиками и со мной, и, может быть, кто-то ещё будет подключаться. И вот мы тут примерно в течение получаса занимаемся тем, что обсуждаем перспективы этой новой задачи: стоит ли делать этот функционал и каким образом это будет реализовано в 1С. Я даю свои консультации и слушаю, чтобы аналитики случайно не дали ложные надежды нашим заказчикам. Здесь я особо ничего не решаю, просто даю свои экспертные консультации.
Итак, наступает 10 часов. Мне нужно сбегать за едой, потому что впереди ждёт перерывы на чай, перекусы, обед и потом перерыв на кофе. Поэтому я должен быстренько сбегать в магазин. Я никому ничего не сообщаю, просто одеваюсь и иду туда, потому что магазин находится неподалёку. Никто меня не потеряет, я на удалёнке, и пока у меня никаких задач особо быстрых, срочных нет, я могу спокойно сходить в магазин и закупиться едой на ближайший день.
Далее, в этом периоде с 10 до 11:00 у нас назначен плановый созвон с коллегами, потому что у нас есть много-много разных задач. А у нас много программистов, и мы постоянно развиваем функционал нашей системы 1С. И существует несколько конфигураций, которые у нас развиваются. Эти конфигурации должны друг с другом как-то соединяться и не конфликтовать, поэтому постоянно нужно держать связь с коллегами, рассказывать о том, чем я занимаюсь. Коллеги рассказывают о том, чем они занимаются, и мы периодически решаем архитектурные вопросы, мы обсуждаем, как лучше сделать ту или иную доработку в 1С.
Итак, в 11 часов это всё заканчивается приблизительно, и я дальше хочу сделать себе перерыв на чай. Но у меня есть ещё задача по написанию формы доработки документа и обработчиков, поэтому я открываю свою конфигурацию, начинаю её делать. Примерно обдумываю в течение 15 минут, а что должно быть на этой форме документа, накидываю обработчиков. И поскольку я уже засиделся, кровь застоялась, мне нужно как-то пойти размяться, и я иду немножко попить чай, кофе и делаю это вдалеке от компьютера для того, чтобы максимально, максимально перезагрузиться. Это всё – перерыв на чай – продолжается не более 10 минут. Я смотрю в окно, сижу в кресле, может быть, делаю парочку упражнений, и вот 10 минут проходит, и я продолжаю делать форму документа и дописывать в ней обработчики.
12 часов. Я продолжаю писать форму, и нам нужно ещё раз созвониться по той самой задаче с аналитиками и заказчиками. Это уже более короткий звонок: возникли непредвиденные вопросы. И краем уха слушаю, о чём там идёт разговор, и когда мне задают какой-то вопрос, я могу просто на него ответить, не отвлекаясь от своей основной задачи.
Дальше подходят уже 13:00. В это время я решаю, что надо обедать, но не полностью. Я могу себе посвятить этот час обеду, я могу какую-то только часть из этого времени посвятить, потому что задач много, и я по плану должен сделать ещё сегодня обновить расширение. Казалось бы, эта задача не для синьора, но расширение сложное, поэтому задача повисла на мне. Я скачиваю обновление расширения и запускаю обновление текущей версии на новую версию. И пока это всё происходит – скачивание и предварительное сравнение, объединение – я иду, делаю себе обед, обедаю, смотрю, чтобы расширение обновлялось в плановом порядке, чтобы не происходило никаких сбоев. И когда я вижу, что этот процесс идёт ровно, я собираюсь и иду немножко прогуляться, потому что голова сильно у меня в течение дня с общением с заказчиками, с той срочной задачей по восстановлению производительности, с устранением сбоев при обсуждении новой задачи с заказчиками и при обсуждении новой архитектуры с коллегами. Голова кипит, мозг уже плохо соображает, поэтому я традиционно немножко гуляю, ну, в течение, примерно, 10-15 минут вокруг дома, чтобы хотя бы немножко перезагрузиться.
Итак, 14:00. Я возвращаюсь и уже готов к новым свершениям, поскольку коллеги написали мне, что нужен срочный деплой и нужно срочно проверить задачу другого коллеги. Я делаю код-ревью этого коллеги, который пришёл мне. Код-ревью – это значит, я должен проверить чей-то чужой код и поместить его уже в рабочую конфигурацию. Передаю это дальше тестировщикам.
Дальше подходит 15:00. Код-ревью, деплой закончен. Я продолжаю расширение, а как раз оно там уже почти завершилось в автоматическом, полуавтоматическом режиме, и поэтому я его просто дозавершаю и переношу уже всё в тестовый контур, чтобы отдать это нашим тестировщикам. Наконец-то руки у меня добрались до изучения HTTP-сервиса поставщиков. Эта задача важная, но не срочная, и я решаю потихоньку начать её изучать, потому что в скором времени, в течение ближайшего месяца, нам понадобится сделать обмен данными с этим поставщиком. А чтобы быть готовым к этому, нужно заранее посмотреть, какие у них есть методы, попробовать их и позадавать вопросы этим поставщикам в случае того, если они у меня возникнут. Потому что если мы вдруг начнём делать все эти доработки прямо завтра, а это будет мне незнакомо, и придётся всё в срочном порядке решать, а мне бы очень этого не хотелось. Поэтому я делаю это заранее.
Итак, подходит 16:00. Ко мне обращаются младшие коллеги, просят помочь с решением некой задачи, на которой они подзависли, не могут никак справиться. Поэтому в 16:00 я подключаюсь по Зуму к нашим коллегам и помогаю разобраться с их небольшими вопросами, которые они как новички не могут решить. А я как старший специалист уже могу им быстренько помочь, подсказать пути решения. Конечно, я всё за них не пишу, я просто направляю их, так сказать, на путь истинный. И я дальше продолжаю изучать HTTP-сервис поставщиков.
Итак, 17:00. Вроде как рабочий день по плану должен быть закончен. Но наш HR-отдел до сих пор не созвонился со мной по поводу собеседования, поэтому собеседование отложилось внезапно на 17:00. Они мне об этом сообщили буквально за полчаса, сказали, что извините, простите, но надо участвовать в собеседовании. Поэтому я превышаю свой рабочий день здесь, восьмичасовой, и иду участвовать также в Зуме в этом собеседовании с потенциальным кандидатом на работу. HR-отдел просматривает резюме кандидатов на работу 1С программистами, выбирает из них некоторых, назначает собеседование, и в этом собеседовании должен участвовать какой-то технический специалист, желательно среднего или высокого уровня. Ну вот сегодня эта роль досталась мне. Я, как и все программисты, не люблю участвовать в собеседованиях, но это требуется в данном случае. Поэтому я превышаю свой рабочий день и иду участвовать в Зуме, задавать вопросы потенциальному кандидату, чтобы понять, подходит он в нашу компанию или нет, знает ли он необходимые технологии, которые мы используем, или нет, и вообще, на какую зарплату его примерно можно будет взять.
На этом первая часть видео подходит к концу, и мы переходим ко второй части видео, где я более подробно расскажу про каждый из этапов и поясню, что там происходило и почему это так происходило. А также вы узнаете много интересных лайфхаков, которые я для себя разработал, работая в течение 30 лет в IT. И я занимался не только 1С, я занимался много разными ещё другими технологиями и языками, а также работаю на фрилансе.
Итак, переходим ко второй части, где я более подробно расскажу о том, чем я занимался в течение рабочего дня и почему я этим занимался. Также я дам вам небольшие лайфхаки по каждому из событий, происходивших в течение этого дня.
Итак, самое первое, что было у меня в 8 часов – это планирование. И я начал работать над первой задачей. Как я планировал, я взял одну самую важную, срочную задачу и поставил её в приоритет для себя. Это для меня было изучение HTTP-сервиса поставщиков. Поставил в приоритет и собирался именно ей заниматься большую часть дня. Также я себе поставил три задачи средней важности, срочности, которую надо сделать в течение дня, желательно сделать, но уже во вторую очередь. Также обсуждение задачи с аналитиками и заказчиками у меня не является первоочередной задачей, потому что, ну, в принципе, аналитики и заказчики на данном этапе могли бы и сами разобраться с этой задачей. И далее у меня задачи низкой важности, срочности, которые я могу вообще отменить, и ничего от этого не случится. Это участие в собеседовании, где я буду участвовать в качестве технического специалиста с новыми кандидатами на работу. То есть, поскольку для меня это не является первоочередной задачей, то есть не меня берут на работу, и это задача скорее моего руководства и HR-отдела, то для меня это низкий приоритет, а для них это высокий приоритет. Поэтому я сюда поставил, что можно, в принципе, и избежать этого.
Вот далее мне нужно обновить расширение. Это такая тоже рутинная, простая работа, которая не является ни важной, ни срочной. Если это расширение обновится через неделю, ничего страшного не произойдёт. Сделать форму документа и написать в ней обработчики. Она пока что висит в бэклоге, в неразобранных задачах, и её пока некому взять в работу. Поэтому я на всякий случай поставил её себе в задачи, потому что её надо кому-то будет сделать в течение ближайшего месяца. И я надеюсь, что какой-то другой сотрудник у нас появится, который возьмёт её в работу. Ну, сотрудник более низкой квалификации, чем я, потому что эта задача не является задачей для высококвалифицированного 1Сника. Поэтому лучше подождать, пока появится кто-то другой. Но если он не появится, а у меня останется свободное время, тогда это буду делать я. И дальше, естественно, вот я записал, что мне нужно ещё сходить в магазин и пару раз чаю попить, перезагрузить мой мозг, пообедать и немного, как по традиции, прогуляться, тоже развеять голову.
Все планы обычно записываются на таких вот досках виртуальных. Все команды 1Сников обычно в той или иной степени используют что-то подобное: какую-то систему постановки задач, систему планирования, систему учёта рабочего времени. А вот самая простейшая Канбан-доска, которая состоит из трёх колонок. Первое – это некие неразобранные задачи, которые нужно взять в работу когда-нибудь. Следующее – это то, что находится в процессе работы. Третья колонка – это то, что было уже выполнено. Ну, третья колонка нужна для того, чтобы разбираться в учёте рабочего времени, в основном для руководства и для того, чтобы сотрудники 1С, и я в том числе, понимали, что когда-то было сделано, и в случае чего, если нужно посмотреть, что там происходило в этот момент, эта колонка очень хорошо поможет разобраться, почему та или иная была задача сделана и что в ней происходило, почему такие решения были приняты, а не другие. У этих Канбан-досок может быть совершенно разный вид, но тем не менее, три вот эти базовые колонки, как правило, всегда сохраняются: это неразобранное, в работе и выполненное. А каждая команда может настраивать её под себя, добавлять какие-то свои колонки, превращать её в какой-то другой вид. И все эти, так называемые, системы учёта времени, системы планирования времени устроены плюс-минус одинаково. Вы можете пользоваться какой-то одной из них. Команды программистов они используют некий софт, некую программу, которая позволяет более удобно организовать процесс планирования, процесс учёта поставленных задач и процесс выполнения. Кто чем занят, сразу видно, и какие задачи остались, и что уже было выполнено.
Ну вот, как вы видите, для планирования я использовал метод разбиения задач на высоко важные, средней важности и низкой важности, то есть на три группы я делю задачи. И для каждой группы выделяю небольшое количество задач. А важная задача всегда одна. Как вы видите, вот я поставил себе изучение сервиса важную задачу, и она у меня одна. А задач средней сложности могут быть две-три в течение дня. А всё остальное сбрасывается в низкой важности, низкой срочности, и, возможно, до них программист уже никогда не дойдёт в течение дня. В чём преимущество этого метода разбиения на важность задач? Это вы всегда будете знать, какая главная задача у дня, и средние задачи не дадут застрять на одной проблеме весь день. То есть если что-то пошло не так с первой задачей, то есть если первая задача оказалась слишком сложной, вы остановились на каком-то трудном месте и никак не можете двинуться дальше, то есть что-то остановилось, мозг не может, мозг не может решить эту задачу. И тогда на помощь приходят средние задачи. Вы берёте, отвлекаетесь от первой задачи, от самой важной, потому что она застряла, или, может быть, вы ждёте какой-то информации от других коллег или от каких-то поставщиков. И пока вы ждёте, пока ваш мозг придумает какие-то решения или пока ваши коллеги подключатся, в это время можно заняться средними задачами. Также если ваш мозг устанет решать важные, срочные задачи, и ваш мозг уже на пределе своих возможностей, то вы берёте какие-то простые задачи, и мозг уже на автопилоте их решает. Вот так устроен мой рабочий день.
Есть ещё один небольшой лайфхак. Чтобы избежать выгорания, вы из этого бэклога, который здесь находится на Канбан-доске, берёте не те задачи, которые важные, срочные и так далее. Вы просто смотрите, какая задача вам нравится, какую задачу вам бы хотелось решить. Таким образом вы избежите выгорания, потому что когда вы делаете вашу любимую задачу, та, которая вас сильно зажигает, та, которая вам очень сильно нравится, это способствует минимальному выгоранию, и можете там много часов делать эту задачу практически не уставая. Но для бизнеса, для рабочих процессов всегда придётся, конечно, брать те задачи, которые спускаются сверху, те, которые ставят вам поставщики, те, которые ставят вам ваше начальство, те, которые устанавливает приоритет для вас ваш лист.
Дальше, я когда начал работать, у меня прилетело уведомление от нашей системы мониторинга. Что такое система мониторинга? Ну, у каждой команды она своя, нет какой-то универсальной системы мониторинга. У нас это всё настроено по-простому: системные администраторы настроили мониторинг производительности на сервере. И если эта система мониторинга замечает какие-то критические отклонения от правильного функционирования SQL-сервера, и эта система формирует уведомления и рассылает эти уведомления всем высококвалифицированным программистам, потому что джунам рассылать это нет смысла. Это всё рассылает руководству и программистам уровня сир и мидл. Поэтому я, поскольку первый пришёл на работу в 8 утра, а остальные приходят немного попозже, я увидел, что прилетело уведомление: что-то случилось у нас с MSSQL. Скоро уже придут наши пользователи, включать свои компьютеры, запускать программы, и они, скорее всего, будут испытывать проблемы. И поэтому я захожу в систему мониторинга, смотрю, в чём там были ошибки, и пытаюсь с этим разобраться.
Если в двух словах описать, что такое высокая нагрузка на SQL, но в данном случае простыми словами. Ну, представьте, что есть библиотека, и в ней есть библиотекарь. И к нему приходят разные люди и делают запрос. В какой-то момент этих запросов становится слишком много, а библиотекарей слишком мало для данного количества пользователей запросов. Получается, что высокая нагрузка возникла на библиотекарей. И вот это, в принципе, почти то же самое, что высокая нагрузка на SQL-сервер. Кстати, есть на моём канале видео, где я объясняю про SQL-запросы.
Естественно, у меня все мои планы откладываются дальше. И вот эта внезапная работа она выходит на первое место, и я не могу просто сидеть, делать что-то другое, потому что эта задача относится к сфере важных и срочных. Ну, такое бывает не каждый день, но сегодня это случилось. Поэтому все свои планы я откладываю во вторую очередь и начинаю сразу заниматься этой важной и срочной задачей.
Поскольку проблема с SQL-сервером оказалась очень серьёзной, в процессе её решения я начал испытывать некоторый стресс от этого и даже не понимал, удастся ли эту проблему до момента, когда пользователи уже начнут работать с нашей 1С. И я применяю в таких случаях всегда метод, который называется ПДР, то есть остановиться, сделать паузу, сделать глубокий вдох и не паниковать, и не бросаться что-то сразу решать, делать какие-то непонятные действия. Посидеть 1-2 минуты, подышать, успокоиться, посмотреть в окно и снять таким образом панику, потому что проблема оказалась более серьёзной, чем я.
Дальше из метода ПДР идёт Д – диагностика. Надо собрать всю доступную информацию о проблеме, посмотреть логи, сообщения, отзывы пользователей, которые накопились за это время. И вот я какое-то время изучал, делал эту диагностику и пока не предпринимал никаких действий для решения этой проблемы, потому что следующий пункт ПДД – ПДД – декомпозиция. Нужно проблему разбить на мелкие части. Я начал последовательно двигаться в решении этой задачи, как раз разбив её на мелкие: посмотрел, что с индексами, посмотрел, какие запросы были сделаны к SQL-серверу и какие из них наиболее тяжёлые и какие из них могли привести именно к высокой нагрузке. Когда я выяснил, что действительно некие запросы привели к нагрузке, повышенной на сервер, я начал уже выполнять четвёртый пункт ПДД – Р – решение. И я начал решать эту наиболее вероятную причину, то есть, скорее всего, какой-то запрос приводит к высокой нагрузке на SQL-сервер. И это оказалось действительно так. В конце концов, чуть-чуть попозже, уже после 9:00 утра, мне удалось решить эту проблему, и пользователи, которые начали уже потихоньку заходить в базу данных, даже не заметили этой проблемы.
Всё это было решено. Здесь есть такой лайфхак, что решение этой проблемы желательно задокументировать где-то, записать в систему планирования, сделать себе задачу уже по факту её решения. Казалось бы, что задачи на доску Канбан должны попадать только те, которые плановые. То есть вы запланировали когда-то эту задачу, сделали её, и потом она отправилась в колонку "решённая задача". Но в моём случае эта задача не была запланирована, поэтому она как бы и никогда и не окажется на этой доске, и никто потом никогда не узнает, что она существовала и как я её решал. Поэтому, чтобы облегчить себе и своим коллегам решение этой задачи в будущем и чтобы руководство знало, чем мы тут занимаемся, я создаю себе эту задачу самостоятельно и помещаю её, которая была выполнена, в колонку "выполнено" и описываю, что случилось и как я это решил. Таким образом, и я и у себя в голове лишний раз откладываю систему решения этой задачи и подобных задач, а также для своих коллег в будущем. Может быть, я уже не буду здесь работать, а другие коллеги смогут в истории посмотреть и понять, как решать эту проблему. Может быть, я неправильно решу эту проблему, и она приведёт к ещё большим проблемам в будущем. А если с сантехнической ассоциацией привести, ну, вот какая-то течь в трубе, да? Я взял изоленту, замотал, вроде не течёт. Я успешно рапортовал о выполнении этой задачи, все довольны на какое-то время. Но потом эта течь прорвала и окончательно всё затопила всё здание. Вот, то есть задача была решена, но была решена, получается, неверно. Фиксация решения этой задачи в планировщике задач она поможет в будущем разобраться, что было сделано не так. В будущем при решении подобной задачи мы будем делать более правильные шаги.
Дальше у нас идёт срочный созвон с аналитиками и заказчиками. В общем-то, он был плановый, он был вставлен в мой план, но я не знал, когда точно этот будет созвон, в какое время. Аналитики и заказчики согласовали время на 9:30, и мне пришлось подключаться именно в это время, оставить все свои задачи. Благо, проблема с MSSQL была уже решена, и я смог спокойно, уже без нервов, в полной концентрации подключиться к созвону в Зуме.
С нашими заказчиками и аналитиками. Это всё продолжается, к счастью, недолго, и в 10 часов я уже свободен. Дальше я могу делать другие задачи. Но такое бывает не всегда. Зачастую созвоны с заказчиками и с коллегами начинаются вроде как в запланированное время, и все вроде как люди умные и с высшими образованиями, все понимают, что такое продуктивность, что такое эффективность. Но тем не менее, эти звонки продолжаются очень долго и обычно выходят за отведённые плановые рамки. И в итоге по этим звонкам, по итогам созвона, не принимаются никаких решений, не назначаются никакие ответственные и не делаются никакие выводы, которые там были озвучены. Вы собрались, грубо говоря, поговорили о том, о сём, посмотрели на приятные лица, сказали умные мысли, но результата никакого нет от этого созвона. Есть ещё даже такие всякие шутки, что если вам надоело работать, вы устали работать, то устройте созвон с коллегами. То есть, подразумевается, что вы так сможете расслабиться и немножко отдохнуть.
[музыка]
Дальше, у меня 10 часов. Я должен сбегать в супермаркет, чтобы запастись продуктами, закупиться едой. Иначе я останусь голодным. Голова уже, конечно, находится в небольшом напряжении к этому моменту, и как раз поход в супермаркет меня должен немножко расслабить. В 10:30 мы начинаем обсуждение архитектуры новой задачи с коллегами. Здесь я участвую как технический специалист, который отвечает за одну из самых главных конфигураций, которая находится у нас на предприятии. Я занимаюсь поддержкой решения под названием ERP. А другие коллеги собираются посылать в нашу систему, в мою конфигурацию, какие-то новые данные, и я должен понять, как нам более эффективно это организовать, как мне организовать приём данных.
Вот многие думают, что программисты только пишут код и вообще ни с кем не общаются. Но, как вы видите, вот уже почти 11:00 утра, и я кода совсем мало написал. Здесь поэтому выходит на одно из первых мест умение общаться с коллегами, умение общаться с людьми, то есть коммуникативная компетентность. Почему это важно? Это нужно для понимания задач. Чтобы создать правильное решение, нужно точно понять, чего хочет заказчик, чего хотят ваши коллеги, и нужно задавать вопросы, уточнять детали. Это потребуется от вас умение как раз общаться с людьми, умение коммуницировать, так сказать, софт скиллы. В IT редко работают в одиночку. Даже программисты всегда разбиваются на команды. Работа в команде, потому что проекты крупные. Умение объяснить свои идеи и понять коллег — это очень критично для успеха проекта. Потому что если вы где-то промолчали, где-то не смогли правильно объяснить, либо не стали отстаивать свою точку зрения корректным способом, задача будет решена, скорее всего, неэффективно. И это приведёт к стрессу, к выгоранию и к неэффективной работе всей команды. Бывает зачастую так, что подключается к разработке какая-то команда со своим проектом, и они вообще не задают никаких вопросов другим программистам, которые заняты на других проектах, но которые связаны. И в итоге эта команда может сделать такое решение, которое будет несовместимо с текущей архитектурой, и придётся это всё переделывать. Вот такая цена коммуникативной компетентности получается, что в наше время для программиста — это очень важный навык, коммуникативная компетентность. А для тех, кто хочет карьерного роста, очень важный навык. Хорошие коммуникативные навыки помогут вам стать тимлидом или менеджером даже проекта в будущем, или пойти даже выше по карьере. Потому что человек, который не умеет общаться, он никогда не станет хорошим, эффективным, успешным руководителем.
[музыка]
Дальше, в 11 часов я всё-таки решил добить эту форму документа, написать не обработчики, хотя бы немного. Почему я решил всё-таки на этой задаче остановиться? Потому что 11 часов, и голова у меня уже после вот этих всяких срочных важных дел перегрелась, я устал, моё мозговое топливо закончилось. Я решил заняться вот таким простым делом: потыкать в экран, попереставлять элементы и написать какие-то простейшие кодовые конструкции, а потом пойти сделать перерыв на чай. Нужно использовать перерывы всё-таки с пользой. Например, короткий поход в магазин или немножко перерыв на чай поможет освежить мысли и всё-таки повысить продуктивность. А если сидеть, сидеть и пытаться стимулировать себя какими-то кофеинами, энергетиками и прочими штуками, в итоге это ни к чему стратегически не приведёт к хорошему. Надо оптимально выбирать время для этих перерывов. Например, поход в магазин во время обеденного перерыва может сэкономить время после работы, потому что обычно люди после работы идут в магазин закупаться продуктами, тратят ваше личное время. Получается, а если я в рабочее время сбегал в магазин, то таким образом я сэкономил своё личное время. Ну, тем не менее, поскольку это занимает 10-15 минут, и на работе это не особо сказывается. Знаете, вот люди ходят покурить или где-то там пить чай, а я в это время сбегаю в магазин. То есть, ничего страшного не произойдёт, если люди могут сходить в курилку, то я могу сходить в это время в супермаркет, поскольку я не курящий. Вот. Можно также в магазине продолжать обдумывать приятное с полезным, пока вы стоите в очереди, например, ждёте что-то там в магазине, или пока идёте по дороге в магазин. В это время всё равно мозг продолжает что-то обдумывать, обдумывать ваши задачи. Профессия 1С устроена таким образом, да, и вообще профессия программистов устроена таким образом, что они постоянно, постоянно обдумывают свои рабочие задачи даже во внерабочее время. Есть даже научное исследование, что сначала людям давали подумать над некой задачей, потом давали им перерыв и замеряли импульсы от головного мозга, и они увидели, что импульсы в головном мозге не снижаются даже во время перерыва. То есть, человек, даже если не обдумывает конкретную задачу, то он всё равно в каком-то фоновом образом продолжает её обдумывать. Это вам скажет любой опытный программист. Он не может точно сказать, сколько он работал над конкретной задачей, потому что получается, что он думает над ней постоянно, даже во время отдыха, во время прогулки. Я часто замечал, что приходит какая-то идея в обдумывание старой какой-то сложной задаче, которую я не мог решить, меня осеняет, и я понимаю, как её нужно сделать. Вот. Конечно же, если я собрался пойти в супермаркет, и в это время там поломался бы SQL-сервер, конечно, я бы всё это отложил. Тут надо понимать, что важно, а что не важно. Обеды, походы в супермаркет надо отложить, если случилось что-то важное, срочное. Помните, конечно, всегда о балансе. То есть, короткие перерывы на личные дела, они всегда помогают избежать выгорания и высокую продуктивность в течение рабочего дня.
[музыка]
Приходит 12:00. Я должен доделать форму документа. Я такой человек, который, если уж взялся за что-то, то ему нужно всё доделать до какого-то приемлемого результата. Решаю доделать эту задачу, несмотря на то, что она неважная, надо её завершить. Также у меня в это время ещё один созвон с аналитиками, который мы начали сегодня уже рано утром, и сейчас нужно ещё раз ненадолго подключиться. Такое бывает частенько в течение рабочего дня. Кто-то просит посоветоваться с программистом. В работе программиста будет встречаться постоянно. А чтобы не сойти с ума, чтобы не выгореть, чтобы быть продуктивным, я всегда использую метод Помодоро. То есть, работаю 25 минут, потом 5 минут отдыхаю, потом опять 25 минут работаю и 5 минут отдыхаю. Ну, стараюсь работать по этому методу. То есть, я прямо включаю таймер. У меня есть онлайн-программа, которую можно включить одной кнопочкой, и она начинает обратный отсчёт. И как только прозвенел таймер, я сразу стараюсь отойти от компьютера и чем-то другим заняться: заварить чай или просто посмотреть 5 минут в окно. И желательно в это время, конечно, ничего не читать, никакие чаты, просто отойти от компьютера, заняться чем-то совершенно другим: поприседать, помыть посуду, загрузить посудомоечную машину и так далее и тому подобное. Ну, конечно, я человек не идеальный, и Помодоро я стараюсь применять, но не всегда это возможно, особенно когда какая-то проблема. Но даже вот возвращаясь к моей проблеме, связанной с SQL, которая возникла, я даже тогда стараюсь использовать этот метод, потому что это помогает перезагрузить мозг, помогает улучшить продуктивность. Как это ни странно, даже вот простое отвлечение на 5 минут улучшает производительность труда, ускоряет время решения задачи. Как вот, как это казалось бы, не странно, да? Вроде надо сидеть и до победного думать над задачей, вроде как вы вошли в поток, и я вошёл в поток, и нужно продолжать работать. Но моя практика показывает, что так, так не работает. Что лучше отойти маленько, перезагрузиться, посмотреть в окно, и в результате всё будет решено намного быстрее и эффективнее. И в итоге в конце рабочего дня я не буду чувствовать себя сильно уставшим.
[музыка]
В 13:00 я понял, что мне нужно пообедать и сделать обновление расширения. Почему я всё-таки не беру свою важную задачу? Почему я решил заняться расширением? А всё просто: я уже не способен решать сложные задачи. Я понимаю, что я устал, топливо в мозгах закончилось, и нужно подождать, пока оно восстановится. Поэтому я беру какую-то более-менее простую задачу, ставлю её на автоматические проверки, и пока эта проверка идёт, я готовлюсь к обеду и занимаюсь потом прогулкой. Прогулка у меня вокруг дома там минут 10-15, просто чтобы развеяться немного, отойти от рабочего места. Это всегда очень хорошо работает и помогает мне. Во время обеда я не просто тупо гуляю, слушаю музыку. Ну, обычно что-нибудь обдумываю, какие-то всё равно рабочие процессы в голове крутятся, и как будто каждый шаг он придаёт некий ритм мозгу, и кажется, что производительность с каждым шагом у меня восстанавливается. Вот такой у меня лайфхак. Для меня лично такая лёгкая прогулка помогает после обеда восстановить продуктивность. Ну, можно слушать какие-нибудь подкасты во время этой прогулки. Но поскольку эта прогулка короткая, обеденная, я стараюсь ничего такого умного не слушать, может быть, раз что какую-то музыку такую лёгкую, без слов, что-то такое, чтобы перезагрузиться, совершенно лёгкое, ритмичное. Вот ещё хороший способ, который я иногда применяю, это что-то типа медитации или дыхательных упражнений. Тоже отойти от компьютера, посмотреть в окно, немножко подышать и так далее. И все эти вот вещи, которые я говорю: подышать, помедитировать, там, прогуляться — это, конечно, всё тоже требует некого усилия, потому что, ну, проще всего сесть в кресло и начать листать какие-то Telegram-чаты и тому подобное делать. Но это не способствует увеличению продуктивности и ещё больше утомляет мозг. Поэтому, ну, я как-то стараюсь, ввёл себе привычку не заниматься листанием ленты, не занимаюсь просмотром YouTube. Я стараюсь просто смотреть в окно и просто ходить туда-сюда, может быть, посуду помыть или приготовить какую-то еду во время обеда, загрузить стиральную машину, развесить бельё, или просто выйти на улицу, походить взад-вперёд, но не заниматься листанием чатов, потому что это очень сильно приводит к выгоранию и к ещё большей усталости, и таким образом, что в обеденный перерыв я не смогу отдохнуть.
[музыка]
Дальше, мне в 14:00 коллеги попросили ускорить код-ревью и деплой. Я решил отложить всё и заняться этим делом. Это заняло у меня почти целый час. Код-ревью на мне висит эта задача, потому что я один из старших специалистов. У нас есть ещё люди, которые могут заниматься код-ревью и деплоем, но для этой конфигурации я единственный человек, который занимается деплоем. Что такое деплой? Это значит, взять чьи-то изменения кода и перенести их в рабочую базу либо в тестовую базу и передать их тестировщику. То есть, в нашем случае это тестовая база. Есть несколько специалистов, несколько программистов 1С, которые работают со мной совместно в одной и той же конфигурации. Мы используем хранилище, и в этом хранилище накапливаются их доработки. Эти доработки я должен проверить, посмотреть, насколько правильный, эффективный и соответствующий стандартам код они написали, и либо разрешить эти изменения, либо перенести эти изменения в рабочую базу, либо отклонить эти изменения и сказать, чтобы эти программисты их переделали более правильным образом. А эта задача очень важная и ответственная, и программисты некоторые не любят, когда их код критикуют, когда их код кто-то проверяет. Я даже сам такое не очень люблю, но это очень важный этап в переносе изменений в рабочую базу. Потому что ваш код смотрит кто-то своими глазами, он всё равно находит какие-то недочёты и нюансы, а программист всегда пишет свой код таким образом, чтобы облегчить себе жизнь, и зачастую даже опытные, грамотные программисты пишут код, не соответствующий стандартам. И коллеги должны указать программисту на то, что он должен переписать этот код, он должен привести какое-то соответствие стандартам или внутренним стандартам, или стандартам 1С. Даже опытные программисты зачастую пишут неэффективный код, потому что они, может быть, не заметили, либо не знали, либо не захотели, либо их кто-то отвлёк, и они вот написали какой-то неэффективный код 1С, а коллеги во время проверки, во время код-ревью, это могут заметить и указать на эту ошибку, на этот недочёт, и это приведёт к увеличению общей производительности системы 1С. Ну, деплой — это перенос изменений из хранилища в тестовую базу. В моём случае, в некоторых случаях, это перенос в рабочую базу. У нас устроено так, что сначала разработчики пишут свой код, потом я её проверяю, и дальше это изменение отправляется на тестирование профессиональным тестировщиком. А наши тестировщики прогоняют, и если нет ошибок, то они разрешают деплой в рабочую базу. А если у них возникают ошибки, то процесс повторяется с самого начала. То есть, разработчики исправляют, потом я опять делаю, делаю код-ревью, деплой и так далее по циклу. У нас всё вот такой восьмёрочкой движется, то есть непрерывная разработка и улучшение. Чтобы никто ни на кого не обижался во время код-ревью и деплоя, лучше всего установить некоторые чёткие критерии, чтобы все понимали, по каким принципам будет проверяться код, а не просто так, что я вот, мне вот не нравится ваш код, и поэтому я его отвергаю. Ну, какие-то стандарты кодирования должны быть всем понятны, тогда будет меньше обид, меньше конфликтов. Если я, как человек, который проверяет чужой код, как ревью, нахожу какие-то проблемы, ошибки, то я не должен просто возвращать этот код тому, кто его написал, а я должен предложить своё решение, я должен высказать своё видение проблемы и как я предлагаю сделать, потому что просто так вернуть без комментариев — это неправильно. И я не фокусируюсь на каких-то мелких стилистических ошибках, тех вещах, которые в принципе можно пропустить. Вот. Также код-ревью полезен для самообразования и для образования коллег, потому что в процессе код-ревью я сам вижу интересные моменты, интересные приёмы, которые мои коллеги применяют в своём коде, и таким образом я сам обучаюсь на коде чужих людей. И всегда помните, когда делаете код-ревью или когда-то кто-то делает ревью вашего кода, что это делается для улучшения качества кода и для развития команды, а не для критики коллег. И никто вас не критикует лично, вам помогают развиваться, и вы помогаете развиваться своим коллегам.
[музыка]
Я заканчиваю это в 15:00 и продолжаю доделывать обновление расширения. Такая рутинная задача наконец-то подходит к концу, и я начинаю изучать HTTP-сервис поставщиков, который я и собирался сегодня поставить в максимальный приоритет. Но в итоге я пришёл к нему уже почти в конце рабочего дня. Тем не менее, я до него дошёл, и это очень-очень хорошо. Изучение HTTP-сервиса поставщиков я сегодня планирую закончить, и для себя выписываю какие-то важные моменты. Понимаю, что там всё работает так, как описано в документации. Документация у них хорошая, это радует. Это способствует моему быстрому погружению в тему, и я уже могу эту задачу в конце дня переместить в раздел выполненное. Также, по сути, я занимаюсь самообучением, когда разбираюсь в этом HTTP-сервисе. Там я подмечаю много интересных решений и планирую их использовать тоже в своей работе. Вот получается, что я занимаюсь таким образом и одновременно самообразованием. Также часто бывает, что разработчики говорят: "Ой, я не буду брать эту задачу или не хочу брать задачу, потому что я с ней никогда не сталкивался, я лучше возьму ту, с которой я уже давно работаю". Это вроде как мне легче, проще. Вот. Ну, я на своей практике развивался таким образом, что всегда брал те задачи, в которых я вообще не разбираюсь, и это приводило к очень-очень быстрому прогрессу. Одно время у меня даже был ритуал, что по каким-то дням, например, вторник, четверг, я просто садился прямо 8 утра перед рабочим днём и начинал читать какую-то статью, и прямо читал эти статьи целый час и пробовал те методы, которые описаны в статьях, применять на практике, применять на своей рабочей базе, делал какие-то запросы интересные, читал статьи, в которых рассказывают про какие-то сложные методы выборки из базы данных.
[музыка]
В 16:00 я ещё продолжал изучать HTTP-сервис, как ко мне позвонили мои коллеги, написали в чат, попросили связаться с ними по видео и прояснить некоторые моменты, которые они не понимают. То есть, это был запрос от младших разработчиков 1С. Но я сначала, конечно, доизучал HTTP-сервис, потому что это очень важная задача. Я понимал, что мне осталось совсем чуть-чуть, я её доделал, и примерно в 16:30 я запустил созвон со своими младшими коллегами, с джунами, которые просили им помочь в решении какой-то срочной важной задачи, которую они не понимают. Общались в течение получаса, я им показывал, направлял, так сказать, на путь истинный насчёт помощи новичкам. Что я могу рассказать? Какие эффективные лайфхаки и методы я для себя понял? Нужно объяснять людям информацию не монологом, а диалогом. Что я имею в виду? Если новичок задал мне какой-то вопрос, и я начинаю долго-долго рассказывать про решение этой проблемы, конечно же, любой человек уже забудет, что там я в начале рассказывал, и, конечно же, я выгляжу очень умным специалистом, но это не помогает новичку стать эффективным. Это неэффективный способ передачи информации. Монолог не является эффективным способом передачи информации. Если вам приходится обучать, например, сотрудников, ну, вот вы сделали какую-то фичу, добавили колонку, сделали новый отчёт, и его надо передать на использование каким-то пользователям. И как объяснить пользователю, что вы? Потому что просто отдать отчёт, сказать: "Пользуйтесь" — это неправильно и неэффективно. То есть, вы должны открыть отчёт и показать пользователю быстро, как он работает, потом попросить пользователя записать эту информацию. То есть, второй раз вы уже показываете то же самое, и пользователь записывает для себя важные моменты. И третий этап — это попросить пользователя воспроизвести под вашим присмотром то, что вы только что ему объяснили. Вот этот способ у меня был наиболее эффективным. Все пользователи были в восторге. Пользуйтесь вот этим лайфхаком. Помните, что у всех людей, пользователей разная скорость восприятия, скорость обучения. Не давайте всем какой-то быстрый или медленный метод. Если пользователь медленно воспринимает информацию или он устал, то нужно сделать перерыв.
[музыка]
Здесь превышение рабочего дня. Но иногда рабочий день превышает. Иногда я превышаю по инициативе, просто какая-то задача нравится, и мне хочется немножко подольше над ней поработать. Вот. А иногда коллеги из других отделов просят или заставляют меня поучаствовать в какой-то задаче. И вот в этот раз нужно поучаствовать в собеседовании. Конечно, это очень важное мероприятие, чтобы к нам пришли те сотрудники, которые владеют нужными нам технологиями. И пока я жду подключение к собеседованию, я завариваю себе чай, немножко перезагружаюсь, смотрю в окно и делаю пару упражнений. И тут я совершенно честно вам рассказываю, это не какой-то прикол, ни какая-то шутка, это действительно меня перезагружает. Итак, вот у меня в общих чертах схема, чем я занимался в течение рабочего дня. Жёлтым помечен чужой код, красным помечен новый код, который я сам писал. Здесь зелёным — это вообще всё прочее, что не относилось к написанию кода. Всегда нужно в течение рабочего дня оставлять хотя бы час на то, чтобы заниматься непредвиденными делами. Что такое непредвиденные дела? Это на что мы не оставили времени. Мы запланировали много-много дел, плотно-плотно забили свой график, а в итоге оказалось, что у нас ещё какие-то есть дела. Недостаток планирования, по сути. Поэтому лучше всего из восьмичасового рабочего дня загружать рабочими делами 6-7 часов, и 1-2 часа оставлять на ошибки планирования, грубо говоря. А если так получится, что, например, у вас остались вечером эти 1-2 часа, то можно изучать документацию, можно взять ещё одну задачу из бэклога, коих там обычно в этом бэклоге, в списке задач, большое-большое множество. У меня всегда, даже когда я был на фрилансе, такая была стопка из нерешённых задач, порядка пятидесяти. И даже когда я везде работал программистом 1С, уже на где-то на постоянке или на совместительстве, там тоже всегда в бэклоге от 20 до 100 задач были в планах. Поэтому задач всегда много, задач вам хватит. Лучше всего оставить 1-2 часа свободных и потом взять эту задачу из бэклога, чем испытывать стресс, когда у вас времени не хватает. То есть, оставляйте небольшой запас по времени. Такой мой лайфхак. Какие плюсы вообще вы можете из жизни программиста понять? Это постоянное развитие. То есть, если вы хотите быть программистом 1С, то у вас такой будет плюс, что вы постоянно, постоянно развиваетесь и всё время будете узнавать что-то новое. Ну, для кого-то плюс, а для кого-то, может быть, и минус. Решение интересных задач и решение этих задач часто похоже на решение головоломок. То есть, вам всегда придётся решать какую-то головоломку. Нет такого, что вот я беру задачу и решаю её по шаблону. Такие шаблонные задачи обычно решают только ну, джуны, начинающие программисты, или те, которые вообще первый раз увидели 1С, им даются всегда какие-то стандартные, типичные задачи. А если вы уже опытный программист, то вам всегда будет попадаться какая-то головоломка, и это будет происходить каждый день. Востребованность. Да, у программистов 1С высокая востребованность, и зарплаты на данный момент, конец двадцать четвёртого года, постоянно растут. Кроме того, вы можете ещё и всегда найти какую-то подработку в другом месте или на фрилансе. Гибкость рабочего времени — это тоже большой плюс. Вы можете работать или удалённо, или по гибкому графику, а также находить опять же где-то подработки. Ну, а минусы: высокая ответственность. Никто не любит ответственность, это всегда перегружает голову, это всегда приводит к какому-то большому напряжению и стрессу. Постоянная концентрация тоже очень сильно напрягает и приводит к выгоранию, к напряжению, к стрессам, и работа требует постоянного и долгого-долгого фокусирования на какой-то задаче. Сидячий образ жизни. Ну, разумеется, важно следить за здоровьем, не засиживаться на рабочем месте. Я стараюсь по Помодоро работать: 25 минут поработал, 5 минут встал, походил маленько, чем-то другим позанимался. На удалёнке это очень удобно, можно домашние дела в течение дня частично уже решить: там, помыть посуду, прибраться, постирать, развесить бельё, спеть какую-то песню. Минус — это стресс от дедлайнов, от горящих сроков. Нужно постоянно думать о том, как сделать задачу в какие-то сжатые сроки. Редко бывает, что у вас есть какая-то задача с неопределённым временем. Всегда-всегда есть срок, к которому надо всё успеть. И минус — это или плюс — это необходимость постоянного обучения, потому что технологии постоянно всегда очень быстро развиваются, и если оставаться на одном месте, то зарплата расти не будет, и коллеги убегут вперёд. Вы после внезапного увольнения или закрытия этого бизнеса останетесь на рынке труда с невостребованными знаниями, и придётся догонять ваших конкурентов. Но в целом, как мне кажется, плюсы перевешивают минусы, иначе я бы тут так долго не работал. А в IT я уже более 30 лет, из них на фрилансе более 20 лет, и в 1С. И как вы видите на схеме, большую часть рабочего времени я вообще не писал ни одной строчки кода. Я изучал HTTP-сервис, я разговаривал с коллегами, я общался с аналитиками, и я разбирался в проблемах на SQL, а там тоже не нужно было никакой код писать. Я занимался обновлением расширения, а там тоже код не нужно писать. А по сути, код я писал совсем немного сегодня. И работа опытного разработчика как раз больше чем наполовину связана с тем, что вы не пишете код, а вы занимаетесь другими делами. Хотя иногда в некоторых фильмах вы можете увидеть, что суперпрограммисты целыми днями пишут код, и на экране у них всё время какой-то код. Но по факту оказывается, что чем более опытный разработчик, тем меньше он занят написанием кода. А вот такое интересное наблюдение. Но вы можете писать свой код в свободное от работы время, так сказать, брать какие-то новые задачи для себя или заниматься сверхурочной работой, и тогда писать ваш любимый код, если вам, конечно, сильно хочется. Ну, эта схема может привести вас, конечно, к быстрому выгоранию. Соблюдайте баланс рабочего времени. Эту схему я прикреплю к описанию, скачивайте её по ссылке. А на этом про рабочий день всё. С вами был Алексей Лапицкий. Пока-пока.
[музыка]
[музыка]