Как узнавать про новые задачи в Jira

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

Зачем оперативно узнавать о новых задачах:

• Чтобы быть в курсе проекта и его изменений, не выпадать из его информационного поля, понимать какие задачи предстоят команде и вам лично в будущем.
• Чтобы классифицировать задачи, определять их серьезность и приоритет. Чем раньше мы поймем какой приоритет у той или иной задачи, тем быстрее начнем заниматься самым важным, не распыляя свои усилия на незначительные проблемы.
• Чтобы следить за дубликатами или ненужными задачами. Часто я сталкиваюсь с ситуациями, когда разные члены команды описывают какую-то проблему в разных тикетах и по-разному. Бывает, что эти тикеты противоречат друг другу. Иногда в задачах описывается откровенный трэш. Отслеживание подобных задач позволяет не запутаться в бэклоге, не давать бэклогу замусориваться.
• Чтобы уточнять задачи с неправильным, недостаточным или непонятным описанием, а также отслеживать взаимосвязи задач. Автор задачи может даже не догадываться, что описание этой задачи непонятно другим. Автор может быть более погружен в контекст проблемы или просто вот так формулирует свои мысли. Игнорирование таких тикетов приводит к тому, что задача может быть неверно интерпретирована исполнителем, и время будет потрачено на неверную реализацию.

Я рекомендую всем участникам проектных команд отслеживать изменения бэклога в ежедневном режиме, чтобы области ответственности пересекались. Благо, что даже на крупных проектах это не занимает много времени. По опыту своих проектов могу сказать, что команда из 70+ сотрудников на интенсивном, живом проекте создает примерно 50+ задач ежедневно. Ознакомление с ними занимает примерно 30-40 минут.

В своей работе я использую Jira от Atlassian. Это очень удобный баг/таск рекер. Jira имеет обширные инструменты для настройки email-уведомлений:

• Если вы Team Lead проекта, вам автоматически будут приходить уведомления по факту создания нового тикета. Это не всем подходит, т.к. team lead у проекта может быть только один.
• Если вы Component Lead, то есть отвечаете только за часть проекта, вы будете узнавать о тикетах, назначенных на этот компонент. Также неудобно, что и в предыдущем пункте
• Можно попросить администратора Jira создать Notification Scheme в вашем проекте, чтобы отправлять уведомления определенным членам команды или группам. Например, по факту создания тикета. Если что-то захочется поменять в Notification Scheme, придется снова обращаться к администратору

Для себя я выбрал более простой и индивидуальный способ узнавать о “новинках” - подписки на фильтры. Подписки можно настраивать самостоятельно, без администратора и независимо от вашей роли в проекте. Этот способ хорош еще и тем, что позволяет получать уведомления с нужной вам периодичностью и сразу по всем нужным проектам. Для меня оптимальна периодичность - раз в сутки.

1. Перейдите в меню Issues -> Search for Issues.

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

2. Я использую JQL для поиска, но можно воспользоваться и Basic фильтрами.

Чтобы при помощи JQL найти задачи, созданные за последние 24 часа (от текущего времени), нужно ввести такой запрос: "project = “Ваш проект” AND created >=-1d".

Или для нескольких проектов: "project in (“Ваш проект 1”, “Ваш проект 2”, “Ваш проект 3”) AND created >=-1d".

3. Далее необходимо сохранить ваш запрос под каким-нибудь именем (кнопка Save As)

4. Нажав на ссылку Details, кликните на “New subscription”

5. В открывшемся окне задайте нужную периодичность получения писем.

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

6. Вуаля. Подписка настроена.

Вам будут приходить письма примерно такого вида

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

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

Фото заголовка pixabay.com

Команда и области ответственности

Периодически слышу реплики типа “Все же взрослые люди, должны понимать, что нужно делать!”, “Он знает что эта задача важна, почему он ее не сделал/сделал не так/не вовремя/подставьте свой вариант”. Такие реплики - про командную работу. Мы часто ждем каких-то определенных действий от своих коллег. Либо не ждем, а находимся в своем уютном мирке и не хотим выглядывать за его пределы. Коллеги при этом могут даже не догадываться, что от них что-то требуется.

Эту ситуацию очень четко характеризует известный анекдот:

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

Командир: - ?.

Админ, проверяя автомат: - С моей стороны пули вылетели. Проблемы у вас.

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

Говоря и делая подобное, люди подразумевают, что все за пределами их собственной области ответственности делается как-то само и автоматически. Разработал задачу - ее как-то протестируют. Протестировал фичу - ее как-то передадут пользователям. В конце концов, зачем нам нужны процессы и различные системы автоматизации, правда же? И зачем нужны все эти менеджеры, которые должны передавать информацию и координировать задачи?

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

Какие ключевые слова приходят вам в голову, когда вы думаете про командную работу? Лично мне такие: гребем в одной лодке, взаимовыручка, единство, синергия, общий результат.

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

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

Сделал свою часть Java-кода? Отлично! Теперь убедись пожалуйста, что разработчик БД провел все нужные оптимизации на базе.

Протестировал фичу и нашел кучу ошибок? Хорошо! Теперь совместно с разработчиком пойми, какие из них наиболее критичные, и убедись, что разработчик принялся их исправлять.

Понимаешь, что не успеваешь к сроку? Ладно. Позови РМ-а и вместе с ним пойми, что правильнее будет сделать следующим шагом.

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

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

Фото pixabay.com

Человек-катализатор

Замечали ли вы, что в некоторых коллективах работается как-то легче, чем в других? А какие-то команды более сплоченные, чем другие.

Сегодня поговорим про человека-катализатора. Это не что-то из области прикладной химии. Впрочем и про химию тоже. Про химию человеческих взаимоотношений.

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

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

Мне не все равно, у меня есть цель

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

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

Про деревообрабатывающую промышленность

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

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