The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Команда, работающая удаленно, требует гораздо большей дисциплины, чем группа, находящаяся в одном офисе. Прежде всего, я имею в виду дисциплину в общении. В Zerocracy мы разрабатываем программное обеспечение удаленно уже пять лет. Мы строго управляем задачами через системы учета (например, GitHub, JIRA, Trac, Basecamp и т. д.) и отговариваем от любых неформальных коммуникаций, таких как Skype, HipChat, электронная почта или телефонные звонки. Для нас каждая задача - это изолированная задача со своим жизненным циклом, своими участниками и своей целью. За эти годы мы усвоили несколько уроков, которыми хотим поделиться. Если вы также работаете удаленно с вашей командой, вы можете найти их полезными.
Каждый тикет (или “ошибка”) является связью между двумя людьми: тем, кто определяет проблему и тем, кто ее решает. Если это баг, я сообщаю о нем, а вы его исправляете. Если это вопрос, я прошу объяснения, а вы его объясняете. Если это задача, я приказываю вам ее выполнить, а вы ее выполняете. В любом случае, участвуют два основных персонажа. Независимо от количества людей, занятых в решении тикета, только эти два персонажа имеют формальные роли.
Ответственность того, кто сообщает о тикете, заключается в защите проблемы. Когда я сообщаю о баге, мне нужно настаивать на его существовании - это моя работа. Другие люди могут сказать мне, что я ошибаюсь и что бага там нет. Они могут сказать, что не могут его воспроизвести. Они могут сказать, что мое описание задачи слишком нечеткое и его никто не понимает. Таких проблем может быть много. Моя задача - сделать все возможное, чтобы сохранить тикет активным. Очевидно, если баг не воспроизводится, я буду вынужден закрыть тикет. Однако, пока тикет не закрыт, я его ангел-хранитель.
С другой стороны, ответственность того, кто решает тикет, заключается в защите решения. Когда тикет назначен мне для решения, моя задача - убедить сообщающего о проблеме, что мое решение достаточно хорошее. Он может сказать мне, что мое решение недостаточно, не самое эффективное или неполное. Моя задача - настаивать на том, что я прав, а он неправ. Конечно, разумным способом. И чтобы создать решение, которое будет принято как достаточное, мне нужно сначала понять проблему, изучить все возможные варианты и предложить наиболее элегантную реализацию. Но все это вторично. Первым делом я буду сосредоточен на том, как убедить сообщающего о проблеме. Я всегда буду помнить, что моя основная цель - закрыть тикет.
Моя точка здесь в том, что независимо от количества людей, участвующих в обсуждении тикета, всегда помните, что происходит - один человек продает свое решение другому человеку. Все остальные вокруг - это помощь или отвлечение (см. ниже).
Помните, что тикет не является чатом. Вы не там для разговоров. Вы там, чтобы закрыть. Когда тикет назначен вам, сосредоточьтесь на его закрытии как можно скорее (Always Be Closing, помните?).
Также имейте в виду, что чем раньше вы закроете тикет, тем лучше работу вы выполните для проекта. Долгоиграющие тикеты - это управленческий кошмар. Их сложно отслеживать и контролировать. Трудно понять, что происходит. Вы видели двухлетние тикеты в проектах с открытым исходным кодом, в которых есть сотни комментариев и никаких результатов? Это ошибка их менеджеров проекта и участников тикетов. Каждый тикет должен быть коротким и сосредоточенным — 1) проблема, 2) уточняющий вопрос, 3) краткое объяснение, 4) решение, 5) закрыт, спасибо всем. Это идеальный сценарий.
Как только вы понимаете, что ваш тикет превращается в долгую дискуссию, попытайтесь закрыть его еще быстрее. Как я могу закрыть его, если автор не согласен с моим решением? Найдите временное решение, которое удовлетворит автора и позволит вам закрыть тикет. Используйте “TODO” в своем коде или грязные обходные пути - все это лучше, чем долго висящий тикет.
Как только вы видите, что решение предоставлено и достаточно, чтобы закрыть тикет, попросите его автора закрыть его. Явно попросите об этом; не мудрите с “похоже, это решение может быть принято, если вы не против”. Будьте ясны в своем намерении закрыть тикет и двигаться дальше. Попробуйте так: “@jeff, пожалуйста, закройте тикет, если у вас нет больше вопросов”.
Каждый раз, когда вы создаете ошибку и создаете новый тикет, вы используете ресурсы проекта. Каждый отчет об ошибке означает потраченные деньги на проект: 1) деньги за ваше время, потраченное на поиск проблемы и составление отчета о ней; 2) время менеджера проекта, который работает с тикетом и находит исполнителя, который его исправит; 3) время исполнителя, который пытается понять ваш отчет и предложить решение; а также 4) время всех остальных, кто будет участвовать в обсуждении.
Если вы закрываете тикет без должного решения проблемы, вы выбрасываете эти деньги в корзину. Как только тикет начат, нет обратного пути. Мы не можем просто сказать: “Ну, проигнорируйте его; он больше не важен”. Ваш тикет уже потратил время проекта и бюджетные ресурсы, и чтобы превратить их в что-то полезное, вы должны убедиться, что будет доставлено какое-то решение.
Это может быть временное решение. Это может быть изменение одной строки в документации проекта. Это может быть маркер TODO в коде, который говорит, что “мы знаем о проблеме, но не будем ее исправлять, потому что ленивые”. Любое решение подойдет, но не ничего.
Посмотрите на это с другой стороны. Когда вы начали этот тикет, у вас было что-то в голове. Что-то было не так с продуктом. Вот почему вы сообщили об ошибке. Если вы закрываете тикет, даже не затрагивая эту часть кода, кто-то другой будет иметь ту же проблему через несколько дней или лет. И тогда проект снова должен будет заплатить за похожий тикет или обсуждение той же проблемы. Даже если вы уверены, что проблема, которую вы обнаружили в коде, на самом деле не проблема, попросите исполнителя тикета задокументировать это прямо в исходном коде, чтобы предотвратить подобную путаницу в будущем.
Каждый раз, когда вы отправляете сообщение в тикет, обратитесь к кому-то. В противном случае, если вы пишете просто потому что хотите выразить свое мнение, ваши комментарии становятся “шумом” в коммуникации. Помните, тикет - это разговор между двумя людьми: один из них сообщил о проблеме, а другой пытается ее исправить. Комментарии вроде “А что если мы попробуем другой подход” или “Я помню, у меня была похожая проблема некоторое время назад” очень раздражают и отвлекают. Давайте будем честными, никому на самом деле не нужны или не интересны “мнения”. В тикете нам нужны только решения.
Если вы считаете, что тикет должен быть закрыт, потому что предложенное решение уже достаточно хорошее, обратитесь со своим комментарием к автору тикета. И начните его с “@jeff, я думаю, что решение, которое у вас уже есть, достаточно хорошее, потому что…”. Таким образом, вы поможете ответственному закрыть тикет и двигаться дальше.
Если вы считаете, что решение неправильное, обратитесь со своим комментарием к исполнителю тикета, начиная с “@jeff, я считаю, что ваше решение недостаточно хорошее, потому что…”. Таким образом, вы поможете автору тикета сохранить тикет открытым до появления правильного решения.
Еще раз, не загрязняйте воздух общими мнениями. Вместо этого, будьте очень конкретными и займите определенную позицию - вам нравится решение и вы хотите закрыть тикет, или вам оно не нравится и вы хотите, чтобы тикет оставался открытым. Все, что находится между этими крайностями, только усложняет ситуацию и не помогает проекту вообще.
Я думаю, это очевидно, но повторю еще раз: каждую ошибку нужно воспроизводить. Каждый раз, когда вы сообщаете об ошибке, вы должны объяснить, как именно продукт работает неправильно. Да, ваша задача - доказать, что программное обеспечение не работает так, как задумано, или не достаточно документировано, или не отвечает требованиям и т. д.
Каждый отчет об ошибке должен следовать простой формуле: “У нас есть это, а должно быть вот это, исправьте”. Каждый билет, будь то ошибка, задача, вопрос или предложение, должен быть оформлен таким образом. Отправляя его, вы просите проект перейти от точки А к точке Б. Что-то не так в точке А, и для всех нас будет гораздо лучше быть в точке Б. Поэтому очевидно, что вам нужно объяснить, где находятся эти точки А и Б. Было бы очень желательно, если бы вы могли объяснить, как туда попасть - как воспроизвести проблему и как ее исправить.
Даже когда у вас есть вопрос, вы все равно должны следовать этому формату. Если у вас есть вопрос, это означает, что документация проекта недостаточно полна для того, чтобы найти ответ там. Это то, что не работает. Вы должны попросить исправить. Вместо того, чтобы сообщать: “Как мне использовать класс X?”, скажите что-то вроде: “Текущая документация не полна; она не объясняет, как мне использовать класс X. Пожалуйста, исправьте”.
Если вы не можете объяснить, как туда попасть, сообщите об этом в билете: “Я вижу, что этот класс не работает так, как должен, но я не знаю, как воспроизвести проблему и как ее исправить”. Это даст всем ясное сообщение о том, что вы понимаете, что ваш отчет об ошибке не идеален. Первым шагом для ее решения будет уточнение проблемы и поиск способа ее воспроизведения. Если такой реплики найти не удастся, очевидно, вашу ошибку придется закрыть.
Позвольте мне повторить еще раз: каждый билет переносит проект от точки А, где что-то идет не так, к точке Б, где это исправлено. Ваша задача, как автора билета, нарисовать эту линию - ясно и однозначно.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-28 at 14:46
