в облаке
Попробовать

Что значит управлять проектом?

05.10.2008 01:25

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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