Часовой механизм вместо хаоса: как проектировать кросс-продуктовые решения и не сойти с ума
Как же справиться с хаосом при проектировании кросс-продуктовых решений? Анна Курындина на конференции Analyst Days 20 поделилась своим опытом, рассказывая о том, как обеспечить сотрудничество между продуктами как слаженный механизм, а не как отдельные части. В своём докладе Анна подчеркнула, что кросс-продуктовые решения — это не просто набор продуктов, а целостный сценарий, который работает как оркестр, где аналитик — дирижёр.
Она на практике показала, как кросс-продуктовые требования соединяют бизнес и системные уровни, чтобы сформировать единый сценарий взаимодействия. Работа над этим, как выясняется, требует от аналитика не только знаний, но и дипломатии: важно включать в процесс всех заинтересованных лиц и справляться с различными форматами и протоколами.
Анна также остановилась на важности унификации форматов и протоколов для обеспечения устойчивости решений и на необходимости учёта нефункциональных требований, таких как безопасность и нагрузка. Эти аспекты, как правило, часто забываются, но они критичны для успешного запуска.
Для тех, кто пропустил этот вдохновляющий доклад или хочет освежить память, мы подготовили видеозапись. Не упустите шанс углубиться в детали того, как проектировать реально работающие кросс-продуктовые решения.
Многие компании предлагают своим заказчикам не простое программное обеспечение, а целые решения для удовлетворения их потребностей, которые состоят из множества взаимодействующих друг с другом продуктов и компонентов. Разработка и проектирование таких решений задача не из легких, особенно когда дело касается выявления и документирования требований к нему. Порой случается, что команды разработки начинают делать свою часть работы, не видя общей картины, и готовое решение может быть не удобным для использования или вовсе не закрыть потребность заказчика. Для того чтобы такое решение функционировало корректно, приносило наибольшую пользу, а сценарии использования были простыми, понятными и завершенными, необходимо учесть ряд особенностей на этапе сбора и документирования требований.
Суть и раскрытие проблематики будет осуществляться на примере большой фичи (решения) из реальной практики — «Отправка обновлений ПО из управляющего приложения на управляемые продукты».
Доступно только после покупки 😊
