Если у вас один клиент, или вы внедряете систему собственными силами, то, возможно, вам и удастся подручными средствами типа переписки по мылу и табличек в эксель управлять этим процессом и задачами. В случае, когда у вас несколько тысяч задач в месяц, то вы никогда не обеспечите требуемый уровень качества работы с заказчиками и собственными разработчиками-программистами без соответствующих инструментариев по управлению проектами разработки. Большинство использует редмайн, джиру и т.д. Мы же используем трекстудио из-за соотношения цены и качества. Неограниченное количество лицензий позволяет бесплатно подключать нужное количество пользователей, как со стороны заказчика, так и внутри компании.
Любые системы для разработки подразумевают наличие стандартного или уникального жизненного цикла задачи, или требования. В данном примере мы нарисовали блок-схему, которая реализована в наших требованиях-задачах.
Рассмотрим, как это работает на практике:
Куратор заказчика создает требование или задачу, где пишет наименование задачи, и описывает так называемые хотелки, можно приложить нужные картинки. Выбираем исполнителя, и необходимую дату выполнения.
Можем заранее проставить бюджет в часах, если мы системный аналитик или разработчик.
В описании пишем текст технического задания.
Также можем вставить какую-то картинку. Мозила Файрфокс поддерживает драг энд дроп и копипаст картинок в тело задачи. При сохранении требования статус присваивается «новый», и пока требование не принято в работу.
Для отправки требования в работу куратор заказчика нажимает кнопку «оценить разработчику» - эта задача у нас ставится на разработчика, или «оценить бюджет», задачу выполняет системный аналитик.
Можно задачу отклонить или поставить на паузу. В блок-схеме эти состояния выделены красным и зеленым цветом. Из отклонено возврата в начало нет, из паузы можно вернуться в то состояние, откуда была пауза.
Можно отправить сразу в разработку, если у нас нет необходимости согласовывать бюджет с заказчиком, или по договоренности с заказчиком мы выставляем стоимость после выполнения задачи. Иногда бывают такие задачи, которые заранее не оценить.
При переводе задачи на разработчика в описании мы можем что-то дописать для уточнения, и выбрать нужного разработчика из списка. В список автоматом попадают разработчики, имеющие доступ к данному проекту.
У разработчика задача появляется в списке задач, после чего разработчик должен оценить примерное время на выполнение данной задачи.
Задача приняла состояние Оценка бюджета, и системный аналитик должен проверить адекватность планируемого времени, который проставил разработчик, и конвертировать часы данного разработчика в деньги для заказчика, в данном случае рубли.
После оценки бюджета задача попадает к заказчику для утверждения бюджета (или отклонения)
Если бюджет утвержден, ТЗ может уточниться и переводится в разработку.
В процессе разработки, если задача закрывается не сразу, а выполняется с перерывами, можно отмечать промежуточные часы и результаты.
После завершения кодирования, задача уходит тестировщику, после, на тестирование заказчику.
Задачу можно оправить на доработку разработчику.
После утверждения заказчиком, задача закрывается и попадает в листы учета рабочего времени и акты выполненных работ.
