Типы задач в Jira: основы, не зная которых рабочие процессы обречены на провал
Рассмотрим главную сущность Jira Software Atlassian — Issue. Она же тикет, таск и задача. Не все
Мы уже рассказали о том, как общаться с разработчиками на старте проекта и о проблемах дизайна и технического задания при работе с командой на аутсорсе. Осталось понять, как оценивать результаты работы разработки вашего проекта.
В ходе разработки трудно сказать, что всё готово, и можно переходить к следующему этапу. Известная буддийская притча гласит: «Чтобы что-то закончилось, нужно только одно: чтобы оно началось. Кроме разработки». Потому что «Обновляйся или умри». Если разработка началась, то она не закончится никогда.
Первый критерий готовности проекта: если он проходит визит-эффект, его можно сдавать и внедрять.
Нужно ли дёргать разработчиков во время разработки? Да, нужно. Но важно чувствовать грань между держанием руки на пульсе, чтобы ваш проект не попал в нижний приоритет, и бесконечными сообщениями в чатиках «А как дела? А сейчас? А вот сейчас?».
В ходе просмотров и апдейта не мучайте ребят вопросами, сообщениями об ошибках. 99% того, что пишут на таких этапах — информационный мусор, который не помогает, а сжигает время и внимание разработчиков и тестировщиков. Важные задачи и/или смену приоритетов обсуждайте на спринтах.
Чтобы этого избежать — обсуждайте правила коммуникации до старта проекта.
Для нас комфортен темп общения 2 раза в месяц, на некоторых проектах — отчётность раз в неделю.
Заказчики, не должно быть такого, что вам не хотят показывать результат хотя бы раз в месяц. Если такое происходит — бейте тревогу. Отсутствие гибкости в коммуникации — серьёзный минус, признак того, что проект развивается не туда. Каждое общение позволит вам быть в курсе проекта, знать, что происходит у разработчиков: кто-то уволился, заболел, умер, что угодно.
Важно: хорошая команда называет сроки проектов с учётом рисков.
Отдельное внимание стоит уделить процессу интеграции. Всегда (всегда!) интеграция затягивается, потому что коммуникация между командами не выстроена. Чтобы наладить коммуникацию, нужно уже на этапе ТЗ договориться с заказчиком об общении с командой сервисов интеграции.
Будьте в копии переписки и, если не понимаете, о чём идёт речь, просто следите за общением обеих сторон. Оно должно быть осмысленным и содержать все технические подробности.
Неправильно, если разработчик напишет в банк так:
Банк, у вас транзакции не проходят!
А вот если напишет:
Банк, сегодня в 14:06 по Мск транзакция типа «Списание с карты (номер 1234567890qwerty)» подвисла и до сих пор висит со статусом pending. Ранее мы договаривались об обработке транзакций за минуту. Скажите, как это исправить? PS: обращаемся к среде bank-test–1 по выданным ранее доступам.
Если в ответ на такое письмо банк молчит, то вынимайте банку душу — доставайте, пока кто-нибудь не примет меры.
Однако заказчикам стоит понимать, что заставлять разработчиков бегать за другими вашими подрядчиками тоже неправильно.
Договоритесь c разработчиками об определённых условиях участия на этапе интеграции, чтобы всем было удобно.
К концу проекта точно возникнет проблема улучшений, несмотря на то, что всё сделано по ТЗ. Разумеется, принимать работу, когда есть откровенные баги, легко воспроизводимые и явно противоречащие ТЗ — нельзя. Если же сервис работает, пользователь может купить, найти, послушать, посмотреть — в общем всё, что вы задумали, — смело запускайте проект. Если очень страшно, то зажмурьтесь. Посмотрите, в каком виде запускаются сервисы на американском рынке, как они выглядят, как работают. Зайдите на Producthunt или Crunchbase и поищите проекты с низким рейтингом — которые недавно добавились и не имеют заметных достижений. Проходит время — выкатывается редизайн и проект взлетает и т.д.
Как только проект запустится — пользователи сами скажут, что надо исправлять, а что нет. Список задач сформируется сам собой.
Сервис запущен, всё работает. Понимание заказчиком процесса разработки значительно возросло. Теперь возникает вопрос: как пользоваться продуктом и не сидеть на абонементе аутсорсеров?
Очень просто — разработчики должны передать заказчику минимум два документа:
Дополнительно должно появиться:
Чтобы убедиться, что ваш проект готов, напишите нам. Сделаем аудит и проконтролируем команду разработки. Удачи с проектом! :)