company_banner

Какие ошибки делают руководители на удалёнке

    Привет, Хабр! Я не разработчик, а менеджер. Меня некоторое время учили управлять людьми, а потом я погрузилась в мрачный мир разработки, где всё идёт не так, как говорят в университете. Сейчас я руковожу практикой управления жизненным циклом программного обеспечения и хочу рассказать несколько, возможно, важных для тимлидов и ПМ'ов вещей, которые касаются перехода на удалёнку. Потому что в наших командах люди было уже начинали так косячить. А потом покажу и расскажу про наш стек автоматизации для удалёнки, и о том, как мы аппрувим релизы из чатов на телефоне одной кнопкой, а не поднимая VPN в защищённый периметр, и это ускорило согласования, и это помогает согласовывать день в день.

    Первый совет — хватит доставать своих людей!



    Я знаю, звучит очень глупо, но многие руководители, не видя людей рядом, начинают как-то компенсировать своё желание убедиться, что они работают. Происходят вот такие чаты:


    Дятел-менеджмент в чистом виде

    Если стоит задача повысить эффективность команды сейчас и в перспективе — оставьте людей в покое. И установите 15-минутные дейли по утрам. Я уже успела увидеть и общепроектные синхры раз в четыре часа, и дейли по два часа, и впадающих во фрустрацию менеджеров, привыкших договариваться сидя лицом к лицу с кем-то.

    Что у нас случилось с удалённой разработкой в КРОК


    Мы очень просто перешли, поскольку у нас и так геораспределённая структура офисов разработки. За последние годы привыкли, что рабочий день кого-то из разработчиков может начинаться с 11 вечера по Москве. Соответственно, для команд с такими участниками проблем по управлению почти не было, а вот для тех, кто работал в одной временной зоне, сложности могли появиться. Например, в одной из моих команд понадобились новые встречи в Zoom для синхрона, и начали подбирать оптимальное время. Сначала делали на понедельник и среду, а потом на среду и пятницу, потому что некоторые из разработчиков предпочли работать на выходных и отдыхать в понедельник-вторник. Отчасти это связано с тем, что их меньше достают в чатах в эти дни.

    Вторая важная вещь — у нас уже были готовы инструменты связки чатов, трекеров, корпоративной соцсети и весь CI/CD-девопсный стек, и всё это было частично перелинковано так, чтобы данные из одной системы автоматом заносились в другую. Например, договорились о чём-то в чате, можно сказать боту, чтобы он занёс это в Джиру. И он занесёт. Если делать это самостоятельно, то нужно зайти, протыкать все поля и так далее, ну и как-то подключиться к защищённому периметру. А с ботом проще. Самое сложное — система авторизации. Её мы продумали, докрутили и сделали ещё больше года назад.

    Как всё начиналось. Сначала все перешли на удалёнку и неделю привыкали. У кого-то стулья плохие и спина болит, у кого-то дома дети за ноги кусают, у кого-то жена обрадовалась, что муж проводит больше времени с семьёй, и просит раз в пять минут открыть банку. Неделю устаканивались инструменты. Потом вдруг разработчики поняли, что они счастливы, что сидят дома. И не надо никуда ходить, никуда ездить, а на встречах сразу понятно, кто был нужен, а кого просто ради ритуала назначили. Ну и собрания стали начинаться вовремя, потому что нет причин опаздывать. Потом начали страдать менеджеры, потому что общение с заказчиком превратилось в ад. Мы начали ставить в календарь регулярные трёхчасовые встречи (три-четыре дня подряд), просто чтобы пройтись с юристом по пунктам договора, иначе всё это зависало бы на месяцы. Пока работает.

    Следующий шаг — вопрос того, что разработчикам на удалёнке нужна мотивация. Не такая, как в офисе. Очень важно не давить, очень важно ставить интересную задачу и давать образ целевого результата. Иначе будет прокрастинация, причём лидер её сам спроецирует. Вылезать из кровати, чтобы делать что-то скучное, просто физически сложно. Лидерам внутри проекта надо на равных давать простор для принятия решения. У нас ситуация в том, что ТЗ обычно не меняется, но власть в рамках спринта принадлежит команде, а не менеджеру проекта.

    Естественно, по дороге дальше можно наломать довольно забавных дров.

    Что может пойти не так?


    Ну, для начала надо помнить, что, несмотря на аврал (а он был много у кого после перехода на удалёнку), процессы лучше соблюдать. Одному из заказчиков мы отгружаем релиз из нашего dev в его dev. Синхро после пулла к ним. Мы отгрузили релиз, они должны были провести интеграционные тесты и регресс. И запаблишить у себя в прод. И вот на следующий день они пишут и просят нас накатить этот релиз им в тест-среду. Потому что они сразу выложили его на прод, а потом вспомнили, что хорошо бы синхронизировать наши окружения. К счастью, релиз не шлёпнулся, но, с моей точки зрения, это выглядит несколько, небезопасно что ли.

    Ещё у одного заказчика мы восстанавливали один из сторонних проектов после переноса работ на удалёнку. Там всё куда проще: специалисты заказчика выставили БД наружу, заодно зачем-то выставили plain text с паролями, тоже наружу. Какие-то юные кулхацкеры взломали это всё, естественно.

    Про ежедневный дайджест с уязвимостями Zoom и финал истории с утечкой записей вы, наверное, знаете. Не все руководители (часто от бизнеса, ставящие задачи ИТ) понимали, что такое Zoom, как он точно работает, и что не стоит некоторые конфиденциальные вещи говорить под запись. Мы сделали памятку для заказчиков, как пользоваться каким каналом. Вроде, помогло. По крайней мере, многие пожилые инженеры с производств вздохнули чуть свободнее. И перестали присоединять к общим конференциям «mydomain.ru», не уточная, знают ли они этого сотрудника.

    Ещё один наш заказчик забыл, что в офисе остались цветы, которые надо поливать. Это мы случайно выяснили при анализе угроз. Цветы спасли.

    Встречи с заказчиком разделились на те, где люди дома всё ещё носят галстуки и те, где можно позволить себе сидеть в пижамах. На одну из наших встреч ведущий разработчик вышел из ванной, прямо в пене. Никто не возражал.



    У тех специалистов по Agile, кто привык разговаривать, оклеивая стены стикерами, наступил творческий коллапс, потому что теперь так делать стало нельзя. Во многих случаях проблему решили Trello или Miro. Всем стало легче. Я с удовольствием наблюдаю, как мои коллеги учатся общаться в новой среде с нуля, и их социальность не даёт им таких бонусов, как раньше.

    Хороший подход — записать где-то близко режимы каждого разработчика. У нас с этим привычно из-за географии, но добавления вроде «с 16:00 до 19:00 только через телефон в срочных случаях» очень помогают. Именно вот тут очень классно работает аппрув реквеста по док-файлу и результатам проверок: можно сделать даже из кровати, если хочется. Потому что иначе придётся ждать следующего рабочего утра восьми-девяти часов. Такой же простой стек мы стараемся донести тем заказчикам, с кем плотно работаем, потому что если мы привыкли, что документ проходит от системы к системе, то у заказчика тот же атлассиан-стек может быть недоступен, и надо будет отправлять *.docx-файлы с промежуточными отчётами.

    Ещё в ряде команд возникла проблема с тем, что встречи в календарь присылаются без заглядывания в этот самый календарь. На один слот может приходиться по три приглашения, причём сам слот уже занят. Это тоже решается организационно и просто.

    Вот ещё наши разработчики рассказывают:

    Сделали бота для демо — плюсовать тому, кому все плюсуют. И нормально с детьми сидим.
    У меня был один из ужасных случаев — у нас был большой проект по внедрению прикладной системы в территориально-распределённой компании. Я находился на Дальнем Востоке с небольшой командой, а основная команда находилась в Москве. Между инсталляциями связь была через механизмы репликации данных, поэтому перед опытной эксплуатацией нам нужно было проверить, как репликация работает под нагрузкой: за три часа на расстоянии 10 000 км надо прогнать объём документов 10 Гб и посмотреть справится ли сеть, не будет ли конфликтов при обработке данных, нет ли взаимных блокировок. Естественно, составили тест-планы, назначили ответственных, окно тестирования. Все на готовности запускать, всё супер, запускаем! И тут понимаем, что пакет данных для репликации запустил наш внедренец на рабочей базе, перепутав настройки. Как итог: временное снижение быстродействия системы, конфликты репликации на рабочей базе, звонки от пользователей, администраторов ИТ-департамента и толпа бегающих консультантов с нашей стороны. От заказчика услышали огроменный нагоняй и то как надо осторожнее подходить к процессу тестирования. Зато есть плюс… провели репликацию на боевой базе сразу и получили подтверждение от заказчика, что система справилась с нагрузкой несмотря на наш косяк.
    Никакой разницы с обычной разработкой на удалёнке нет. Ты ж всё равно работаешь с сервисами. Давно был случай, когда мой коллега при регламентных работах случайно прибил VPN-сервер, через который подключался для обслуживания этого VPN-сервера… При пятиминутном окне для обновления системы под нагрузкой резко отваливался доступ в момент после остановки приложения и до запуска новой версии (в эпоху полуручных обновлений)… Или когда запускаешь команды rm -rf /data, а потом понимаешь, что это у тебя продуктив, и быстрее-быстрее ctrl-c.
    Чатопс курильщика:



    Сделали редеплой релиза на уже зарелизенную машину коллеге. Занулив его работу. Ну, бывает.

    А есть примеры по стеку?


    Да, вот они:

    Связь запроса


    Гитлаб + тимсити

    Боты помогают

    Гитлаб + джира



    Гитлаб + тимсити

    Схема сборки

    Пример конвейера разработки

    Это пример техстека с чатопсом



    Сам девопс и CI/CD-инструменты у нормальных команд давно отработаны. С точки зрения управления процессом важно то, что на каждом шаге нужно снижать количество неудобных действий, оставляя только полезные. Например, вы выше видите ботов, которые докладывают о состоянии релиза — такие push куда удобнее, чем заходить и смотреть, как он там. Но настоящая ценность появляется тогда, когда всё это позволяет создать непрерывный процесс от «обсудили задачу в чате» до «поставились все задачи со ссылками на обуждение», «прикрепилось ТЗ и пронеслось через все системы» до билда, плюс по пути снялись все нужные метрики вроде меток самооценки. Для разработчиков этот проект был челенджем, потому что обычно они пишут код, а не рисуют архитектуры, пишут концепции и т. д. И если разработка автоматизирована максимально, то у многих команд автоматизация обмена документами или апрувлами не очень хорошо реализована.

    Вот пример. Задача считается выполненной, когда каждая строка в ТЗ будет представлять собой рабочую ссылку на кросс-таблицу.

    Шаги такие
    Сделали страницу с ТЗ:



    В каждом разделе ТЗ поставили якоря, на которые можно переходить из других документов. Каждый раздел мы сделали ссылкой на кросс-таблицу для обеспечения обратного перехода.

    Сделали страницу с содержанием (структурой) «Концепции»:



    Здесь аналогично. В каждом разделе якоря, на которые можно переходить из других документов. Каждый раздел мы сделали ссылкой на кросс-таблицу для обеспечения обратного перехода.

    Кросс-таблица ТЗ-Концепция:



    По ссылке можно перейти в ТЗ (заголовки строк) или в «Концепцию» (заголовки колонок). На перекрестии строк и столбцов мы разместили ссылку на задачу в Jira и фамилию ответственного за выполнение. А также чекбокс со статусов задачи. Когда все ссылки из документов ТЗ и «Концепция» будут вести к одной из строк таблицы, мы добьёмся цели. Дополнительная цель — реализовать содержимое Концепции. Для контроля мы используем содержимое ячеек. В итоге каждая из строк должна содержать одну или более заполненных ячеек со статусом «решён».

    Я руководитель, на чём сейчас сосредоточиться?





    Важный приоритет — не быстро деливерить, а нормально общаться. Мир уже изменился, и теперь есть две важные угрозы для компаний: профессиональное выгорание (это если заниматься дятел-менеджментом и «выжимать» людей) и вопрос полного перестроения структур управления, когда команды понимают, что могут делать всё достаточно автономно и с новым неформальным лидером. Это может кончиться тем, что в момент конца кризиса вся команда, которую с таким трудом искали и обучали, встанет и уйдёт разом на собственный проект. Поэтому ещё раз повторю — даже если у вас производительность упала, не доставайте своих людей. Это в ваших же интересах.

    Если интересно обсудить уже чисто процесс руководства отдельно, то мы делаем вебинар 27-го в 16:00, вот тут можно записаться. Там будет про то, как можно строить процесс, разные ошибки и управленческие кейсы, разделение ответственности (особенно с ИБ), про документооборот между разработчиками, аналитиками, тестировщиками, немного про CI/CD. Ну и даже если вам кажется, что вы и так всё знаете, можно сделать как настоящий джедай — записаться на вебинар, убавить звук и сидеть делать свою работу!
    КРОК
    IT-компания

    Комментарии 41

    • НЛО прилетело и опубликовало эту надпись здесь
        +1
        Ну на третью проблему есть контраргумент. Задачу может зафиксировать сам исполнитель, поставив автором инициатора. И только после подтверждения, что всё правильно понято — приступать.
        Но это уж если совсем всё плохо.
          0
          А почему вы не приступили? Я же поставил задачу, чего вы от меня ждёте?


          Такое может случаться сплошь и рядом
            +2
            Здесь поможет только регламентация процесса. Или смена работы.
            Можно как минимум обсудить это с начальством. Не факт, что он не поймёт. :)
          • НЛО прилетело и опубликовало эту надпись здесь
              +7
              Но ведь у начальника постановка задач не единственная функция. Более того, он вообще может это делать изредка, и не придавать значения формулировкам.

              Я могу задать и встречный вопрос. А зачем мне сотрудник, который не может донести до меня мысль, что я неправильно ставлю задачу? :)

              Ну и да, я работал в условиях, когда у начальника попросту не хватало времени нормально зафиксировать задачу. Как-то мне это тогда не казалось проблемой, помочь ему в этом.
                +2

                У нас это менеджер делает, и это часть его работы: общаться, не только с заказчиком, но и с разработчиком.

                  +6
                  У всех по разному. Но на удалёнке крайне важно зафиксировать задачу. Свидетелей нет, разбирательства ничего не докажут, начальник по умолчанию прав.

                  Просто напишите письмо с описанием того, как вы поняли задачу и отошлите начальнику.

                  Тут, как раз, учше всего — устно, чтоб потом можно было переиграть, а исполнитель ничего доказать не смог начинает играть в обратную сторону: вот моя постановка задачи, вот тут всё описано, вот до этого мы договорились… а если какие и были возражения устные — так это ж вам, наверное, приснилось… письменных возражений нет, значит и жалоб нет.
                    0
                    Полностью согласен. Худой мир лучше доброй войны.
            0
            Я фрилансер, у меня 4 проекта висят в режиме «пока непонятно, ждем денег на этой неделе». И так уже месяц. И 3 из них хорошие вменяемые вполне коммуникабельные клиенты.

            Ну как бы они тоже просто не знают, чего ждать. США просто в шоке, для их горизонта планирования карантин сравним с ядерной войной.
              0
              Вы так говорите, будто такие ошибки допускаются только сейчас: в условиях карантина и удалёнки. Такое сплошь и рядом было, есть и, к сожалению, будет.
              +15
              Очень толковая статья. Один их тех случаев, когда на русском вдруг появляется более толковый текст на эту актуальную тему, чем в англоязычном пространстве.
                +2
                Потом вдруг разработчики поняли, что они счастливы, что сидят дома.

                Они сами это вам рассказали? Вот прямо все-все, включая тех, у кого однушка, жена, дети и сосед с дрелью? Примеры совсем не абстрактные, если что. В небольшой однушке, если живёшь не один, достаточно сложно выстроить продуктивный режим работы. А на созвонах я регулярно и детей, и дрель слышу.

                  +2
                  Речь про средние результаты опроса, и, скорее, касаются вообще возможности работать удалённо, когда не надо ходить на встречи по офису. Вы абсолютно правы, если рабочее место не готово дома, то офис — это спасение.
                    +1
                    На мой вкус, готовность рабочего места определяется не только наличием отдельной комнаты или оборудованного стола. Готовность — она еще в голове у самого человека. Кто не готов, тот и в офисе будет дурака валять и ходить коллег отвлекать, а кто готов, он и в однушке с двумя детьми будет продуктивно работать. Да, поначалу сложно, еще и с близкими надо договариваться, рамки выстраивать на основе компромисса, но было бы желание.

                    Я вас (автора) поддержу: по моим личным наблюдениям люди скорее счастливы, чем нет. Им не надо тратить 2 часа в день на дорогу, у них выровнялся work/life balance. Семью видеть стали, в конце концов, не только на фотографиях в вотсапе…
                    0
                    Вы детей и дрель только слышите или они явно мешают коммуникации?
                    +5
                    > аппрувим

                    > дейли

                    > синхры

                    > перелинковано

                    > Синхро после пулла

                    > запаблишить у себя в прод

                    Даже мне, не вебмакаке, а инженеру и системному администратору (нет, не макаке с докером) это режет глаза.

                    Русский язык достаточно красив и богат, а вы зачем-то используете в рассказе такую вот хню.
                      +5
                      Это от восхищения собственным охизмом. Ну типа показать она эффективный манагер. Чаптер лид.
                        +3
                        веб
                        администратор
                        Русский язык достаточно красив и богат, а вы зачем-то используете в рассказе такую вот х**ню.
                        Ну а вы тогда зачем используете в комментарии такую вот «х**ню», вместо этого вашего красиво-богатого языка? Может, стоит признать, что заимствование слов — это нормальный естественный процесс?
                          –1

                          Заимствование слов — это не жаргон. Оно подчиняется фонетической системе, и почти всегда встречается тогда когда в языке нет подходящего по значению аналога.


                          Какого аналога нет в русском языке?
                          "Подтверждаем"? "Ежедневный"? "Согласования"? Кстати "Синхронизации" тоже существуют, и это нормальное слово со своим лексическим значением, а вот "синхры" я даже не знаю что это.


                          Вы не до конца процитировали меня, я не писал слово "веб", я писал слово "вебмакака" — это не жаргон, это уничижительное название прослойки, придуманное согласно правилам этой самой прослойки.
                          Администратор — так же не является жаргоном, поскольку полностью подчиняется правилам русского языка в который было заимствовано: падежи, части речи, и тд.


                          Опять таки, я не претендую на генератор истины в последней инстанции, рассказ сам по себе неплох, идеи здравые, но большое количество жаргонов на абзац — режет глаз.

                            0
                            Администратор — так же не является жаргоном, поскольку полностью подчиняется правилам русского языка в который было заимствовано: падежи, части речи, и тд.
                            Ну, те же «аппрувим» и «перелинковано» прекрасно подчиняются правилам русского языка. А вот какой-нибудь «кофе» — не подчиняется. И что теперь делать — пить только чай?)
                              0

                              Нет не подчиняется. Оба слова находятся вне и фонетической и грамматической системы, поскольку не адаптированы к нашей морфологии + семантике и тд итп. От того что вы натянете туда полтора правила русского языка (хотя я и не о них говорил) — слово не станет заимствованным.


                              Сравните с администратором: одушевленное существительное мужского рода второго склонения, обозначает лицо, которое чем-то управляет, "управитель" с латыни.
                              Аппрув — дословно переводится как "одобрить", т.е. согласно правилам русского языка, УЖЕ является глаголом, и в случае заимствования оно само по себе уже означало бы законченное действие. А значит никаких "аппрувить" или "зааппрувить" здесь быть не может, с т.з. морфологии это нонсенс вида "маслянное масло". В случае же жаргона, этим словом можно играть как душе вздумается, например придумать слово "перенедозааппрувленный".
                              В свою очередь слово "администратор" произошло от совсем другого латинского глагола "adminstrare" — управлять, которое в свою очередь морфологически состоит из приставки "ad" имеющей собственное лексическое значение + корня ministrare который в свою очередь произошел от другого слова, и тд, и тп, но даже учитывая ЭТО, в русском языке сформировался совершенно другой глагол, созданный согласно морфологическим правилам нашего языка — "администрировать".


                              Так или иначе, большое количество жаргонов в тексте режет глаз, а их применимость учитывая наличие вполне себе одинаковых по значению аналогов, больше напоминает какой-то карго-культ вперемешку с восхищением всем иностранным, нежели заимствование слов.

                                +1
                                Аппрув — дословно переводится как «одобрить», т.е. согласно правилам русского языка, УЖЕ является глаголом, и в случае заимствования оно само по себе уже означало бы законченное действие.
                                Быть может, вы хорошо знаете латынь, раз так уверенно рассуждаете про администратора. Но тут дали маху. Approval — вполне себе существительное. Да и кто вообще дословно переводит с языка на язык, что за нелепица?

                                Реальная разница между аппрувить и администрировать лишь в том, что второе слово употребляют чуть дольше и оно уже стало вам привычным. Дедок из глубинки вас с вашим администраторством не поймет. Ну а мне привычно аппрувить и мержить. Да и «пойдем на дейли» зачастую звучит не реже, чем «пойду за кофе».
                                  0

                                  Будет лучше, если вы мне будете отвечать филологической терминологией, а то "нелепица" больше похоже на отсутствие аргументов.


                                  А вот за "approval" вы верно подметили, еще раз подтвердив, что это не заимствованное слово, а жаргон. Все дело в том, что при заимствовании иностранных слов, заимствуется лишь одна морфема, а остальные формируются уже согласно фонетической (да и морфологической) системы нашего языка. В тексте же речь шла о слове "аппрувим", из которого легко выцеживается морфема "аппрув". Не "аппровал", а именно "аппрув", поскольку именно это слово используется в конференциях. Вы ведь не говорите "let's do approval", верно? Вы говорите "let's approve", следовательно автор написала именно то слово, которое сочла нужным написать, но поскольку как я уже указал выше, это жаргон, то и произошел подобный нонсенс как создание глагола из глагола что в случае заимствования попросту не имеет необходимости, вроде двойного отрицания. Вы ведь не говорите описывая себя "я не невеселый!", да? Вы просто говорите "я веселый", хотя первое выражение и имеет лексический смысл и любой вас поймет, просто с поправкой на нашу семантику, это не не корректно.


                                  Вот например есть заимствованное слово "сканер", оно одинаково звучит как в иностранном варианте, так и в русскоязычном, практически транслиттерированно. Но когда мы делаем ДЕЙСТВИЕ сканером, мы ведь не говорим "давайте проведем сканнинг", да? Мы говорим "давайте проведем сканирование", т.е. это существительное сформировалось из той же морфемы что и "scanner", но уже по правилам нашего русского языка. И появилось это заимствованное слово, потому что в нашем языке аналога нет.


                                  Именно по этой причине ваше "пойдем на дейли" больше смахивает на блатную феню, нежели на диалог разумных существ: "чалился на киче, внатуре".

                                    +1
                                    Будет лучше, если вы мне будете отвечать филологической терминологией, а то «нелепица» больше похоже на отсутствие аргументов.
                                    Видите ли, в чем дело. Вам показалось, что лингвисты, филологи и составители словарей занимаются законотворчеством. Так вот это не так. Они лишь с некоторым опозданием описывают то, что уже случилось.

                                    Факт в том, что слово «аппрув» уже стало частью русского языка. Всё, с этим ничего не поделать. Да, его используют лишь в некоторых профессиональных кругах, в частности, среди программистов и маркетологов, ну и что? Обычный человек вообще использует в повседневной жизни порядка двадцати — пятидесяти тысяч слов из не менее миллиона существующих в языке. То, что вы обзовете это профессиональным сленгом, или используете любой другой термин, не изменит уже свершившегося события. Ну а если для вас это «больше смахивает на блатную феню, нежели на диалог разумных существ», то это сугубо ваши проблемы.
                                      +1
                                      Часто замечаю, что англицизмами бросаются как раз не очень умные люди ради выпендрёжа, а не по необходимости. Даже не удивляюсь, когда некоторые русскоговорящие американцы используют меньше англицизмов, чем некоторые россияне. Просто уровень интеллекта выше, словарный запас больше и нет необходимости выпендриваться таким способом.
                              0
                              Администратор — так же не является жаргоном, поскольку полностью подчиняется правилам русского языка в который было заимствовано: падежи, части речи, и тд.

                              ЕМНИП, по тем же правилам "так же" в этом случае было бы логичней написать слитно (по аналогии с "то же" vs "тоже"). Хотя, могу и ошибиться. Ну и… Администратор совершенно точно не является жаргоном, а насчёт слова "администратор" спорить не буду. :)

                            +3
                            Лучше читать англицизмы, чем мат
                              0
                              Одно-единственное уместно вставленное нецензурное слово производит потрясающее впечатление. Но оно должно быть только одно (на весь фильм, например, или на всю страницу).
                              Исходный комментарий этой ветки стилистически прекрасен, в отличие от всех последующих.
                              0
                              Жаль, плюсануть не могу)
                                0
                                Если слова тупо короче, почему бы их не заюзать?
                                Вообще в ИТ-среде переводить всё подряд на великий и могучий это довольно странно, даже абстрагируясь от коммуникации с иностранными коллегами и предположив, что мы окуклились сугубо в своей социально-лингвистической группке.
                                Вспоминаю великое «Исключительная Ситуация Времени Выполнения» вместо «Runtime Error» в одной из книжек по программированию, которую довелось лично читать.
                                  0

                                  Как вариант, потому что статью могут читать не IT-шники. Как вариант, потому что статью могут читать такие IT-шники как я, которые не в теме, и которым бы хотелось узнать значения непонятных слов, но только вот этих слов НЕТ В СЛОВАРЯХ и НЕТ В ПЕРЕВОДЧИКАХ, потому что арго, и именно потому-что это арго — к этим словам невозможно подобрать ассоциативный ряд.


                                  Вот сравните например с коротким словом "админ". Да, это сокращение от слова "администратор", но поскольку это сокращение построено ПРАВИЛЬНО, то его поймет в принципе не только IT-шник. Как и будет более менее ясно, о чем идет речь.


                                  Но что такое "синхры"? Даже в упомянутом контексте? Это процесс синхронизации? Это механизм? Это какая-то технология типа rsync? Что такое "дейли", и почему Гугол с Вики в один голос дают мне ирландскую фамилию и топонимы ?


                                  Знаете, я вот могу скомпилировать ядро, и даже обозвать его при этом ведром. Я могу "запецкать скриптец для синка видосиков с локалхоста на хоум-сервачок на целке с гигом мозгов". Но я никогда не напишу это в статье, которую будет читать вся планета, хотя бы из уважения к читателям. И таки да, я много раз перечитаю статью перед окончательной ее публикацией (запаблишингом в ворлд, ага), иначе в ней так и останется ерунда вроде проецирования прокрастинации:


                                  будет прокрастинация, причём лидер её сам спроецирует
                                    0
                                    Как вариант, потому что статью могут читать не IT-шники.

                                    Ни в коем случае не оправдывая неумеренное использование неустоявшихся англицизмов — имхо, это довольно спорный аргумент, если понимать его как предложение писать любую статью на специализированную тему так, чтобы её могли понять любые неспециалисты. Думаю, вполне очевидно, что в общем случае это невозможно. Позволю себе привести произвольно выбранную цитату из источника, в котором весь текст, за редкими исключениями в виде логических формул, на русском языке:


                                    Контекст системной поддержки может быть задан номологически или формально, но, если задача уточняется как выяснение условий достаточности соответствующего критерия — а это, например, транслируемость парадигмальной референции в случае каузального объяснения или необходимость подпадания случаев употребления знака под закон или правило, в случае номологического объяснения — то уместно перевести объяснение на уровень отношений между токенами знаков и индивидуальными полаганиями: как интра-, так и интер-субъектных. Удобный известный способ говорить об условиях чего бы то ни было на этом уровне — использовать понятие конвенции. Оно само, разумеется, требует расшифровки, но даже в непроясненном виде им можно воспользоваться для описания того, что можно назвать индивидуальными условиями референции, имя в виду отношение каких бы то ни было устанавливаемых семантических характеристик к субъектам их полагания определяющими референт того или иного термина.

                                    Положа руку на сердце — Вы готовы подписаться, что этот текст поймёт любой человек, не являющийся опытным специалистом в пространстве дисциплин тематики текста? Если что, там точно не об IT-шной техподдержке. :) Тема книги "Онтологические проблемы референции" лежит в области пересечения онтологии и эпистемологии, авторы предлагают ознакомиться с современными достижениями в проблематике связи языка и мира. Авторы пытаются вводить в курс дела постепенно, но вынужденно предполагают уже какой-то существенный бэкграунд (простите) у читателя, в противном случае объём текста, наверное, вырос бы в десятки, если не сотни раз. И поверьте, даже с опытом и предварительным знакомством читать такую литературу, сохраняя ясное понимание происходящего, очень тяжело ввиду высокой когнитивной нагрузки на протяжении всего текста. Соответственно, содержательные статьи на темы обсуждаемых вопросов, будут априори непонятны неспециалистам, неважно на каком языке они написаны.


                                    Обобщая приведённый пример на тему IT (и вообще): если статья пишется для того, чтобы в ней было что-то интересное для тех, кто уже в теме, то она частично или целиком будет непонятна неподготовленному читателю независимо от языка. Если же она пишется для объяснения чего-то любому неспециалисту, то специалисту она будет неинтересна. На двух стульях усидеть не получится.

                                      0
                                      Как вариант, потому что статью могут читать не IT-шники

                                      Простите, но много ли вы "не IT-шников" здесть видели? :)

                                    0
                                    Поддержу: неприятно бросается в глаза применение в печатной всё же статье своеобразного арго, которым и в устной-то речи далеко не всегда пользуются.

                                    Здорово, что есть обзор ситуации и какая-никакая аналитика; всё же статья оставляет ощущение описания ситуации as-is.

                                    Хотелось бы увидеть систематизацию проблем, суть и степень влияния на результат, варианты решений.
                                    0

                                    Ошибка – использовать в работе телеграм как средство коммуникации.

                                      +1

                                      Ну, лучше телеграма пока ничего не придумали.

                                      0
                                      Главный вопрос — он всегда про деньги.
                                      Приятно, что хоть кто-то соблюдает закон и оплачивает работу в нерабочие дни как и положено.
                                        0
                                        Я возможно скажу какую-то глупость, но если в нерабочий день заниматься работой, то нерабочий день по факту превращается в рабочий с соотв. последствиями например в виде оплаты.
                                          0
                                          Вы, возможно, не слишком внимательно слушали выступления президента страны тогда, да.
                                          Он чётко всё рассказал про оплату и работу.
                                        +1
                                        Статья
                                        Какие ошибки делают руководители на удалёнке
                                        обещает мне толковый список ошибок, но по факту имеет мало связанные и еще менее структурированные истории, которые куда более бы гармонично читались бы английском, нежели на рунглише с дописыванием русских окончаний вороху английских термионов и глаголов.
                                        Из статьи я понял, что не нужно пинать инженера каждые 15 минут, а нужно сделать 15 минутную летучку раз в день, а еще понял какой автор молодец и что вебинар нас ждет.
                                        Хех, я понимаю что если все разложить по полочкам здесь то вебинар смысла не имеет, но и после такого материала уже мотивация продолжать серьезно пострадала.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое