Инструменты для планирования и тайм-менеджмента в компании

Николай Лукиных

Руководитель проектов в Galileosky

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

1. Что cделали?
2. Какие проблемы возникли в процессе?
3. Что планируют делать?

Если день насыщенный, то вспомнить все задачи и проблемы, возникшие во время решения, сложно. Обычный блокнот, таблицы Excel, календарь в Google — всё не то. Отдельная проблема — не забывать фиксировать типы активности и потраченное время. Нужны инструменты для планирования и отслеживания работы.

Нашёл два решения.

• Worklog в Jira от Atlassian. Плюс — нет лишних пунктов и действий. Минус — Worklog только в Jira, а Jira не всегда под рукой. Нужно было что-то мобильное и простое, работающее быстро и с напоминаниями.
• Приложение aTimeLogger. Удобный интерфейс, возможность ставить цели и задавать категории активности, выгружать отчеты за любой промежуток времени.

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

Дополнительная польза — спустя месяц чётко увидел, что много времени занимают совещания с коллегами и клиентами. Следующим шагом стала оптимизация этих процессов.

HelpdeskEddy +Jira + ChatBot для оптимизации работы с коллегами и клиентами

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

Исторически сложилось, что отдел технической поддержки Galileosky работал в HelpdeskEddy. А отдел разработки —  в Jira. И результате выстраивания процессов взаимодействия двух отделов встал вопрос: как обмениваться информацией. На помощь пришло готовое решение от HelpdeskEddy, автоматизация от Jira и желание сделать всё удобно и практично.

Штатная интеграция позволяет через интерфейс HepldeskEddy создавать разные задачи и оставлять комментарии напрямую в Jira. Со стороны Jira есть возможность отслеживать такие обновления. Для корректности ввели рубрикатор с кодовыми словами #решение, #вопрос, #исполнитель и так далее.

Использование такой связки инструментов для планирования позволило частично автоматизировать взаимодействие отделов из простой интеграции — создание и комментирование задач — в полноценную среду общения двух отделов.

Работа технической поддержки — не только общение с разработчиками, а прежде всего взаимодействие с клиентами. Здесь на помощь пришёл встроенный функционал HelpdeskEddy – ChatBot и база знаний.

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

Jira + автоматизация для оптимизации рабочего процесса

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

К примеру, при создании эпика в SCRUM мы каждый раз создавали задачи на анализ, декомпозицию, тестирование, документирование, а также указывали, кто и что будет делать. А сейчас внедрили механизм, который автоматически указывает, какие задачи нужны при создании эпика. Затем создаются задачи и сразу ставятся ответственные, прописываются все названия и устанавливаются все связи. Экономит и время, и бережет нервы от выполнения однотипных действий.

Это только одна из 20 автоматизаций, которой мы пользуемся в Galileosky. Также в списке:

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

Наш идеальный workflow

Мы не претендуем на звание идеального workflow для всех. Вот то, что помогает в работе нам.

• Self testing. По внутренней договоренности вынесли этот статус в отдельный пункт. Каждый разработчик до отправки на ревью проверяет свой код на работоспособность, где это возможно. Часто задачи много раз мигрировали между статусом Self testing и In progress. Так мы видим кто пишет с минимальными итерациями — специалист потом делится опытом.

• Waiting dependeces. Это стало причиной для введения нового статуса — «Ожидает зависимостей». Чтобы не портить промежуточную статистику, сделали для нее статус «Выполнено». Однако при необходимости мы можем вернуть задачу обратно в работу.

• Correction. Мы стремимся быть лучше каждый день, каждый спринт и писать код так, чтобы ревьюверу приходилось тратить минимум времени. Статус Correction нужен ревьюверу для того, чтобы отправить задачу после ревью на коррекцию. Каждый переход в статус «Коррекция» подсчитывается. Далее по результатам месяца мы смотрим, чей код и как часто подвергался коррекциям. После этого проводим работы по улучшению кода и стараемся добиться более чёткого написания согласно внутреннему codestyle.