Если вам доведётся работать в компании крупнее чем три человека, наверняка часть работы будет в таск-трекере. Сейчас покажем, что это такое.
Что такое таск-трекер
Таск-трекер — это калька с английского task tracker, что переводится как «отслеживание задач». Это то место, куда стекаются и где распределяются все задачи между всеми программистами. Там же может храниться вспомогательная информация по каждой задаче, вестись обсуждение, плестись интриги, разворачиваться семейные драмы.
В общем, таск-трекер — это бесконечная мучительная планёрка для айтишников. Или не мучительная.
Бизнес-процессы в таск-трекере
Часто таск-трекер настраивают так, что задачи автоматически двигаются между разными участниками в зависимости от их роли в команде. Например, это может быть так:
- У фронтенд-разработчика появляется в трекере задача «Добавить стиль для новой кнопки поиска в меню».
- Фронт берёт её в работу, делает и нажимает в трекере внутри задачи кнопку «Готово».
- Задача относится к категории «Фронтенд», поэтому она автоматически попадает в работу к тестировщику сайта. Срок выполнения тоже меняется автоматически.
- Тестировщик открывает задачу, смотрит, что от него нужно, и идёт прогонять новый стиль через тесты.
- Если все тесты прошли удачно — он закрывает задачу и она улетает дальше в отдел релизов. Если тест не пройден — в задачу ставится пометка и она снова возвращается фронтендеру, который ей занимался.
При этом продвинутые таск-трекеры следят за кучей параметров: как долго задачи были в работе, сколько сделано сразу, сколько вернулось, кто самый результативный и так далее. Этим часто пользуются менеджеры, когда им нужно оптимизировать процесс разработки и найти слабые места.
Таск-трекеры могут интегрироваться с другими системами: гитами, средами тестирования, средами разработки и т. д. Это нужно для крупных компаний, где любой шаг нужно стандартизировать.
Что такое баг-трекер
Баг-трекер — это трекер багов или ошибок, которые нужно исправить в программе. Там есть много из того, что есть в таск-трекере:
- задача (описание ошибки),
- степень критичности,
- когда появилась,
- кто ответственный.
Также считается хорошим тоном добавить в описание ошибки то, как её можно воспроизвести, — так программисты быстрее поймут, что нужно поправить.
Но баг-трекере есть свои нюансы: в зависимости от степени критичности ошибки они могут двигать другие задачи и внезапно становиться важнее всех остальных.
Иногда в компаниях для отработки багов используют тот же таск-трекер, что и для обычных задач, но хорошим тоном считается завести отдельный баг-трекер и собирать туда только ошибки.
Почему программисты не любят таск-трекеры
На самом деле здесь всё зависит от продакт-менеджера.
Если продакт адекватный, следит за нагрузкой команды и грамотно распределяет задачи среди участников, то таск-трекер воспринимается просто как рабочий инструмент.
А если продакт неопытный и каждую неделю наваливает задач выше головы, а потом ещё меняет их в течение дня, то тут таск-трекер — это инструмент пыток, а не повышения продуктивности. Ещё вариант — использовать все фишки таск-трекера, даже если они не нужны. Именно из-за таких ситуаций в ИТ ходят шутки про Jira и другие трекеры:
А можно как-то без всего этого?
Если вы пишете программу или сервис один — то можно: вы сами решаете, что делать сейчас, а что потом. Если вас двое-трое, то тоже всё можно решить в чатиках и при личном общении.
Но когда команда вырастает больше пяти человек, а у продукта появляются первые пользователи, лучше пользоваться трекером — с ним меньше вероятность пропустить важную задачу.
В больших компаниях трекер — обязательная часть процесса, потому что компания не умеет работать с людьми, только с процессами. Если что-то не зафиксировано, не описано и не согласовано, в компании этого нет. Придётся терпеть.
