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

Многие нам говорят: "Но ведь есть basecamp, assembla, trac, jira, зачем вы делаете что-то свое, какой в этом смысл?"

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

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

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

Существуют смешанные (интеграционные) решения, которые объединяют в себе функции баг-трэкинга и планировщика задач. Assembla из их числа.

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

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

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

Вот это и есть та большая разница между системой управления процессом разработки и системами баг-трекинга и управления задачами.

Еще интересные статьи на эту тему: