Size: a a a

Архитектура ИТ-решений

2021 January 11

ОИ

Олег Игонин... in Архитектура ИТ-решений
Vladislav Isaykin
помните шутку с бардаком и автоматизацией?
что толку вам от процессов, документации, подходов и практик если затык на этапе сбора требований и их уточнения
Мне как аналитику из клетки к оунерам надо вырываться. Чем не цель?
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
В первую очередь выстройте работу с постановкой вам задач.
Нужно донести, что если вам на входе пришло говно, то на выходе может быть конфетка. Но из говна.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Я особо не вижу других вариантов, если простой подход поиска стейкхолдеров и попытка с ними связаться блокируется?
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Для этого нужно с аналитиков потребовать обоснованности требований. Хоть какого-то.
источник

VI

Vladislav Isaykin in Архитектура ИТ-решений
Олег Игонин
Мне как аналитику из клетки к оунерам надо вырываться. Чем не цель?
у вас как аналитика нет цели куда то вырываться, у вас по дефолту должен быть чел который знает что хочет бизнес, иначе получите ту же ситуацию
в эту игру нельзя играть одному
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Alexander Luchkov
В первую очередь выстройте работу с постановкой вам задач.
Нужно донести, что если вам на входе пришло говно, то на выходе может быть конфетка. Но из говна.
У меня задачи приходят на высоком уровне, дальше начинаются уточнения с моей стороны. Кажется, что я один пока что могу формулировать цели проектов. Пока что документация, которую я видел не содержит цели, только требования.
Приёмку организовывать надо, но требуется сформировать стандарт или использовать его. У нас вроде есть формат А3, которые в теории содержит цели проекта и стейкхолдеров, но я его не запрашивал, т.к. только недавно о них узнал.
Определить пакет документов проекта - также важно.
источник

VI

Vladislav Isaykin in Архитектура ИТ-решений
ну тогда все просто
источник

VI

Vladislav Isaykin in Архитектура ИТ-решений
пишите реализацию, согласуете, делаете
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Vladislav Isaykin
у вас как аналитика нет цели куда то вырываться, у вас по дефолту должен быть чел который знает что хочет бизнес, иначе получите ту же ситуацию
в эту игру нельзя играть одному
У нас такой есть, но у него был missconnect с бизнесом.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Я в своё время (с год назад) написал себе же инструкцию:
источник

VI

Vladislav Isaykin in Архитектура ИТ-решений
Олег Игонин
У нас такой есть, но у него был missconnect с бизнесом.
его missconnect  его проблема
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
В случае, если Project Owner или Team Lead* берёт на себя обязанность общения с внешними стейкхолдерами (выявлением их целей, бизнес-требований, получением входящих материалов для работы и т.д.), то аналитик в данном случае использует PO/TL как proxy для получения и верификации бизнес-требований и бизнес-целей. При этом, аналитик концентрируется на самом техническом решении, отдавая определение "видения" проекта и его архитектуры на плечи PO/TL, оспаривая его решения только при нахождении логических несоответствий.
* На позиции PO/TL может находиться Бизнес-аналитик, но таких случаев в этой компании я пока не встречал.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
В этом случае ваши аналитические способности явно ограничены, и вы не можете качественно выполнять обязанности уровня проекта:
•  Вы не способны качественно рассматривать, а также валидировать экономическое обоснование проекта и его цели. Человек, отвечающий за передачу информации, может выставлять собственные цели и/или цели нашей компании за цели стейкхолдеров.
•  Скорее всего, собранные бизнес-требования переданные в вас, будут подвержены искажениям и, вероятно, не в достаточном объёме. Готовьтесь к внезапному получению больших паков новых требований на этапе разработки. Уточняйте детали в местах логических несостыковок требований, используйте дедукцию, индукцию и ваш предыдущий опыт.
•  Зачастую, решение приходит к вам в виде точки зрения конкретного человека. В данном случае можно инициировать рассмотрение архитектурной составляющей проекта как инициативу, при необходимости подключая архитектора или других экспертов (разработчиков, DevOps, администраторов).
•  Любые метрики должны иметь точку опоры со стороны бизнеса (их ожидания). Иначе они могут быть либо завышены, либо занижены. Редко когда в таком формате удаётся получить адекватные требования по метрикам от стейкхолдеров.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
В этой позиции следует экономить силы и не думать слишком много, с минимальными затратами создать проект технического решения или макет, после чего отправить его на согласование. Только так вы сможете быстро и безболезненно получить толковый фидбек от заказчиков или уведёте проект на согласование (которое он так и так будет проходить), освободив своё рабочее время для других проектов. При блокировке стейкхолдеров, цена усилий, которые вы потратите на попытки докопаться до чистых требований стейкхолдеров будет очень велика и это негативно повлияет на вашу работу в отделе в целом.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Олег Игонин
У меня задачи приходят на высоком уровне, дальше начинаются уточнения с моей стороны. Кажется, что я один пока что могу формулировать цели проектов. Пока что документация, которую я видел не содержит цели, только требования.
Приёмку организовывать надо, но требуется сформировать стандарт или использовать его. У нас вроде есть формат А3, которые в теории содержит цели проекта и стейкхолдеров, но я его не запрашивал, т.к. только недавно о них узнал.
Определить пакет документов проекта - также важно.
Тогда получается что вы :
1. Выявляете потребности
2. Разрабатываете требования
3. Разрабатываете методы испытаний
4. Разрабатываете решения
5. Осуществляете надзор за этим.

У вас пупок не развязывается в одно лицо такое делать?))
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Vladislav Isaykin
его missconnect  его проблема
Я так не считаю. Это моя проблема, если я забочусь об успехе проекта.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Олег Игонин
Я так не считаю. Это моя проблема, если я забочусь об успехе проекта.
А вам бонусы за успехи проекта платят?
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Alexander Luchkov
Тогда получается что вы :
1. Выявляете потребности
2. Разрабатываете требования
3. Разрабатываете методы испытаний
4. Разрабатываете решения
5. Осуществляете надзор за этим.

У вас пупок не развязывается в одно лицо такое делать?))
Завязывается. Очень больно, долго и попа горит. Хотя испытания я не описываю, а надзор - только выборочный.
источник

VI

Vladislav Isaykin in Архитектура ИТ-решений
ну если у вас столько героизма и альтруизма и похоже мазохизма, то ок))
источник