Это не работает

Original author: Frank Denis
  • Translation
8 утра. Как и в любой другой день, я быстро просматриваю уведомления GitHub через Octobox.

  • «Проблема»
  • «Не работает»
  • «Сломанный»
  • «Сбой»
  • «Ошибка»
  • «Баг»
  • «Не работает»
  • «Поломка»
  • «Не могу выстроить»
  • «Не удалось установить»
  • «Не работает»
  • «Помощь»
  • «Не компилируется»
  • «Ошибка»
  • «Не подключается»
  • «Проблема»

Отлично. Ничего особенного.

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

Почему бы не опубликовать код? Это может быть полезно другим людям, и удобно, если код будет заархивирован и проиндексирован на GitHub.

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

Система отслеживания ошибок может быстро начать заполняться. «Спасибо, это именно то, что мне нужно» — было бы очень приятно такое прочитать, но вы никогда не увидите такого комментария. Вероятнее всего:

«Это не работает».

Очевидно, что проект ДЕЙСТВИТЕЛЬНО «работает». Вы уже пару дней пользуетесь им ежедневно, и он делает именно то, что вам нужно.

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

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

В системе отслеживания проблем GitHub мы не обращаемся за помощью. Мы жалуемся на то, что пытались сделать, но «не сработало».

Безусловно, это ведь трекер проблем. Это место, где можно жаловаться, а не оставлять положительные отзывы.

Однако часто упускается из виду то психологическое воздействие, которое это может иметь.

Каждый новый заполненный вопрос сродни новому пункту в списке дел разработчика проекта. С этим нужно как-то справляться. Читая и пытаясь понять его, и отвечая на него, чтобы решить проблему незнакомца. Уже одно это оказывает некоторое психологическое давление. Наблюдать за ростом списка открытых проблем — это стресс. Это похоже на бесконечный список дел, о котором вы никогда не просили, и закрытие которого, не решит ваших собственных проблем.

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

Хотя это, конечно, не было намерением, но у этого бесконечного негатива есть последствия. Это заставляет разработчиков постепенно чувствовать себя дерьмом. Их программное обеспечение — просто куча мусора, которая ничего не может сделать, кроме как терпеть неудачу.

По мере роста количества проектов, которые вы выпускаете как проекты с открытым исходным кодом, растет и количество проблем. Жалобы приходят даже на проекты, которыми вы больше не пользуетесь. Можно ли игнорировать эти проблемы? Каждый раз, когда вы публикуете новый проект, вы подписываете неявный договор с «сообществом» о его поддержке на всю жизнь. А поддержка — это не столько исправление ошибок, сколько помощь пользователям в решении проблем, которые у вас никогда не возникали, коренные причины которых часто совершенно не связаны с вашими проектами.

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

Добавление категорий и шаблонов не помогает. Отзывы о том, что «Это не работает» для решения отдельных проблем в конечном итоге попадут в категории, в которых вы можете ожидать фактические отчеты об ошибках. Таким образом, вам все равно нужно проверять, что стоит за каждым описанием «не работает» на случай, если настоящий отчет об ошибке будет за этим скрываться.

За некоторыми из этих проблем «не работает» кроются анонимные сотрудники компании, которые открывают проблемы с аккаунтами, в которых нет активности на GitHub, помимо открытия тикетов поддержки и «запросов функций». С голосами «большого пальца вверх» от аналогичных аккаунтов, появляющихся сразу после публикации. „Не работает. Мы ждем решения“. Если это не заявка «не работает», то это команда: „Отметьте новый выпуск. Это блокирует наши процессы“.

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

Есть ощущение, что установка бесплатного программного обеспечения дает возможность получать бесплатную поддержку от сопровождающих. И до некоторой степени это так. Потому что сложно сказать „сделай домашнее задание“ и закрыть заявку. Каждая закрытая заявка требует обоснования, которое будет жить вечно в истории системы отслеживания проблем, и на что люди будут смотреть, даже спустя годы. Таким образом, вам, возможно, придется продолжать решать проблемы пользователей, даже если они совершенно не связаны с тем, как вы сами запускаете программное обеспечение.

»Не устанавливается на платформе Titan под управлением BeOS для iPhone 4 (китайская версия 2.7 Pro)"

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

«Я не знаю» и «мне все равно» были бы честными ответами. Первое не является веским основанием для закрытия вопроса. Последнее будет иметь неприятные последствия. Итак, вы проводите время в поиске этой непонятной вещи в Google, пытаетесь понять проблему пользователя на основе кусочков головоломки, которую вам каким-то образом удается собрать, и предварительно находите надежный ответ. Все, что вам действительно нужно, — это решить эту проблему наилучшим образом: самими пользователями.

Между тем стресс усиливается. Каждая новая заявка вызывает стресс и беспокойство. Не о содержании, а о том, что нужно сделать, чтобы ее закрыть. Сколько времени и сил на это потребуется.

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

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

Обратная связь — это здорово. Понимание того, что проект полезен для других, — это здорово и воодушевляет. Возможность сообщать об ошибках и вносить предложения очень эффективна. Но это не то, для чего в основном используется трекер проблем GitHub. Он используется, чтобы пожаловаться или попросить персональную помощь, описывая то, что было испробовано, но не увенчалось успехом, как «ошибку» или как «проблему» в программном обеспечении, которое «сломано», «дает сбой» и «не работает».

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

Однако у них есть тренинги. Они знают, как обращаться с разными типами клиентов. Их можно передать другим людям. У них есть соответствующие навыки и опыт.

У сопровождающих проекта этого нет. Кроме того, сотрудники службы поддержки поддерживают продукты компании. Они, безусловно, разделяют корпоративную культуру, однако жалобы направлены на работу компании, а не на их собственную работу.

Заявка «не работает» в личном трекере проблем проекта — это то, что мы берем на себя. Не к кому обратиться за помощью, чтобы решить эту проблему наилучшим образом, нет менеджера или коллеги, которым можно было бы передать дело. Игнорирование этого не заставит его исчезнуть. Он по-прежнему будет появляться каждый божий день, пока в конечном итоге не закроется.

А до этого момента накапливающиеся заявки «не работает» делают вашу работу ненужной и неприятной.

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

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

Однако проблемы сильно различаются от одного проекта к другому. В проекте, предназначенном для использования только людьми, уже знакомыми с предметной областью, проблемы «не работает» встречаются гораздо реже. Но вместо бесплатного центра обслуживания клиентов система отслеживания проблем может стать бесплатной консультационной службой, в которой люди спрашивают, как создать приложение или протокол, когда ваше программное обеспечение каким-либо образом используется. Трудно не помочь. Трудно сказать нет. Итак, проводите время, решая проблемы других людей, в то время как вы боретесь со своей собственной, не связанной с этим работой? Только так они сами решат вопрос. Если вы хотите, чтобы его закрыли досрочно, вам нужно обоснование. «Извините, у меня нет времени» — не повод оставлять заявку открытой. Даже если это правда и лучшее, что можно сделать для собственного психического здоровья.

Открытое общение — это здорово и необходимо. И средство отслеживания проблем, безусловно, очень ценный инструмент. Но это топология «многие к немногим», подпитывающая постоянный поток негатива (в своей форме), который в конечном итоге может быть разрушительным для ума.

Mitigations


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

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

С github-auto-locker закрытые задачи автоматически блокируются через пару месяцев. Если вопрос закрыт, дело закрыто. «Я тоже», всплывающее на тему, о которой говорилось много лет назад, раздражает. Если есть что-то новое, откройте новую заявку, тем более что программное обеспечение могло сильно измениться с момента первоначального обсуждения, и контекст может отличаться.

После 30 дней бездействия проблемы закрываются меткой тайм-аута. Если так долго не было никакой активности, маловероятно, что если оставить заявку открытой, что-то изменится. Возможно, это был запрос функции, в реализации которого никто не заинтересован. Возможно, составителя отчета просили сообщить подробности, но он не собирается их сообщать. Может быть, никто не знает, как ответить на вопрос или что это вообще значит.

Ярлык тайм-аута не означает, что проблема будет проигнорирована. На закрытый, не помеченный вопрос, возможно, стоит по-новому взглянуть позже, когда позволит время. Многие запросы функций были закрыты в этом состоянии, но в конечном итоге были реализованы позже.

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

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




image

Вакансии
НПП ИТЭЛМА всегда рада молодым специалистам, выпускникам автомобильных, технических вузов, а также физико-математических факультетов любых других высших учебных заведений.

У вас будет возможность разрабатывать софт разного уровня, тестировать, запускать в производство и видеть в действии готовые автомобильные изделия, к созданию которых вы приложили руку.

В компании организован специальный испытательный центр, дающий возможность проводить исследования в области управления ДВС, в том числе и в составе автомобиля. Испытательная лаборатория включает моторные боксы, барабанные стенды, температурную и климатическую установки, вибрационный стенд, камеру соляного тумана, рентгеновскую установку и другое специализированное оборудование.

Если вам интересно попробовать свои силы в решении тех задач, которые у нас есть, пишите в личку.



О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.

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

НПП ИТЭЛМА
Компоненты для роботизированного транспорта

Comments 19

    +2
    Спасибо за отличный перевод.
      +5
      Наконец, я научился говорить «нет» или «я не знаю».

      С этого надо было начинать, и статьи бы не было, потому что не было бы проблемы. У меня такой же багтрекер, и меня совершенно не напрягает то, что мой багтрекер — это багтрекер.
        +1

        Я правильно понимаю, что вы предлагаете научиться работать под давлением, и не упоминать в принципе, что давление существует?

          –1

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


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

          … а ты сидишь среди этого весь в белом и довольный.


          Никогда не участвуй в забеге дебилов. Даже если ты придёшь первым — ты всё равно будешь дебил.
            +4

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


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


            Мораль истории: не стесняйтесь написать просто письмо благодарности автору понравившегося вам инструмента, их очень приятно получать!

        +7
        Являясь мейнтейнером крупного опенсорс проекта (карточная онлайн игра, MTG) — я положительно отношусь к обратной связи от пользователей. Количество переходит в качество.

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

          Я думаю, что это очень сильно зависит от природы проекта. Одно дело игра «сапёр», где пользователь только кнопки нажимает. И совсем другое дело библиотеки с пользовательскими коллбэками, которые исполняются в непредсказуемых средах. Там просто невозможно выдать инструкцию, которая позволит «решить проблему самостоятельно».

            0
            библиотеки с коллбэками, которые исполняются в непредсказуемых среда

            Это уже отличный шанс подумать об автоматическом тестировании в разных окружениях. Благо очень многие CI и другие сервисы выделяют бесплатные квоты для опенсорсных проектов. Даже у гитхаба есть свои actions. Можно настроить и проверить любые ситуации, автоматизировать рутинные задачи и тем самым облегчить поддержку. Еще и такой важный опыт прибавится по работе со всеми этими инструментами.
              +3

              Не поверите, у меня на проектах есть непрерывная интеграция и всякие юнит-тесты. Меня удивляет, что вы предположили, что я не умею пользоваться этим инструментарием :)
              Только этот инструмент не панацея — нельзя проверить любые ситуации, особенно в случае, когда вы вызываете чужой код.


              Более того, я регулярно сталкиваюсь с ситуацией, когда мой код проверил входные данные, и отказался работать, выдав соответствующее сообщение. Только пользователь, который написал кривой коллбэк, обвиняет меня: «не работает». И когда багзилла заполняется подобными баг-репортами, и на исследование каждого «бага» у вас уходит пара часов, руки опускаются. Если бы 100% баг-репортов были бы действительно о багах в моём коде, это было бы счастье.

                0

                Нельзя ли просить пользователей формировать минимальный код, воспроизводящий проблему?

                  +3

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


                  Это не конец мира, с этим можно успешно жить ;)
                  Собственно, вся статья заключается в том, что поддержка открытого проекта — это серьёзное давление, и к этому надо быть готовым.

          +1

          На тему github-auto-locker есть вот этот смешной пример: https://github.com/facebook/react/issues/10021#issuecomment-573023802


          На протяжении года пользователи воюют с ботом и доказывают ему, что фича им нужна.

            +7

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

              +2

              Поддержка — понятие очень расплывчатое. Лично мне надоело каждый раз час-два ковырять issue, чтобы в итоге обнаружить, что проблема не в моём коде (и да, не всегда можно проверить входные данные). И я хорошо понимаю человека, у которого опускаются руки решать чужие проблемы.

                –3

                Встретились два любителя перекладывать проблемы на другого.)


                Вообще, типичная причина этого — невразумительное сообщение об ошибке.

              0
              Система отслеживания проблем GitHub не раз заставляла меня плакать. Я не мог заснуть после того, как закрыл заявки без уважительных причин.

              Страдалец какой

                +1
                это нормально — возраст, опыт и склонности характера у всех разные.

                если бы у вас в 15 лет был такой проект и смартфон с подключенными нотификациями?
                Я вот помню как я не спал ночами, чтобы в школу принести свою новую самописную игрушку на Электронике МК-61
                +3
                По-моему у автора какое-то психологическое отклонение. Интересно было бы услышать мнение специалиста в данной области. Одно дело — желание помочь пользователям. Но не спать ночами из-за того, что у кого-то на другом конце света кривые руки и он не может сам решить свои проблемы? Это уже перебор.
                  +3

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


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


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


                  Несмотря на то, что у меня пригорело от этого чувака, в его словах есть доля правды.


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

                  Only users with full accounts can post comments. Log in, please.