avl (avl) wrote,
avl
avl

Category:

17. Бизнес управляет

(В оригинале Business Drives)

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

Бизнес-заказчики обычно планируют определенный возврат вложений (ROI) перед тем как инициировать процесс разработки. Архитектор должен иметь это в виду, ограничивая те инициативы со стороны разработки, чтобы избежать принятия решений, которые могут привести к перерасходу бюджета. Возврат вложений должен рассматриваться как один из главных интересов заказчика во время переговоров о ценности той или иной функциональности по сравнению со стоимостью ее реализации. Например, архитектор должен учитывать интересы заказчика, не соглашаясь на желание разработки использовать технологию, имеющую неприемлемо высокую стоимость лицензии или техподдержки готового продукта.

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

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

Долгосрочные интересы разработки лучше всего соблюдаются, если процессом управляет заказчик.

Автор оригинала - Dave Muirhead.

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!
Tags: 97_things_architect_should_know, Программирование, Развитие
Subscribe

  • Один день на яхте

    Давно, очень давно хотелось оказаться на яхте. И вот наконец удалось реализовать мечту, пока что на 1 день. Главное — что оказалось, что никого из…

  • Подарок на 8 марта :)

    Фирма удивила, подарив 8 марта ВСЕМ сотрудникам смарт-часы от неизвестного производителя с нанесенным своим логотипом :) Да, в Словении 8 марта -…

  • Автомобильное...

    Ездишь себе, ездишь, стараешься машины поддерживать в исправном состоянии... А потом подходит очередной техосмотр - и машина вдруг впервые за 7 лет…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments