Как создаются программные решения. Описание процесса для клиента IT-компании. Прозрачность в процессе выполнения проекта.

Об IT - просто

Как создаются программные решения. Описание процесса для клиента IT-компании.

Прозрачность в процессе выполнения проекта

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

Это дает вам 2 важные вещи:

  1. Контроль вашего собственного проекта. Вы видите затраты календарных сроков и денег, видите промежуточные результаты и можете сопоставить план и факт. И оперативно принимать решение по продолжению работ с этим подрядчиком.
  2. Вы можете на лету тестировать версии, понимать что удобно, а что нет, где вы ошиблись в постановке задачи (а вы обязательно ошибетесь и не раз), где вас неправильно поняли - и все это оперативно вырулить в нужное русло, корректируя требования к продукту.

Как это реально реализуется?

Проект делится на спринты. За этим термином стоят обычные интервалы времени в 2-3 недели.

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

В конце спринта команда представляет вам сделанный результат. И вы можете руками потрогать создаваемый продукт, сразу видеть что нравится, а что нет и оперативно откорректировать все, что не нравится.

Это нормально - не знать на старте все детали того, что должно получиться. Четко вы должны представлять на старте только цели и задачи, которые должен решить продукт.

Agile-процесс создания продукта напоминает прорисовку картины. Сначала общие контуры, потом детализация все глубже и глубже. И вы участвуете в этом вместе с командой, вы видите все этапы и направляете процесс туда, куда вам надо.

В следующей статье я хочу рассказать, почему иметь на старте ТЗ это не всегда хорошая идея. Она хорошая, если вы до мельчайших подробностей представляете ваш будущий продукт и можете нарисовать его интерфейсы с закрытыми глазами.