Интересно. А вот как по мне — так это абсолютно нормальный случай. Архитектор и аналитик находятся на одном уровне коммуникаций, просто аналитик выясняет функциональные требования системы, а архитектор — нефункциональные.
Конечно в какой-то конкретной команде всю коммуникацию можно держать через аналитиков. Но с таким же успехом тогда её можно построить и через архитектора. Это порочная практика в обоих случаях.
Ещё один момент, почему архитектор должен понимать язык бизнеса — архитектор участвует в пресейлах. А это значит, что надо уметь хорошо молоть языком и диаграммы рисовать не только в UML и с представителями заказчика говорить на одном языке.
Подобные проекты делаются по другому: сначала аналитики должны составить ТЗ и утвердить его у заказчика, а потом по ТЗ всё это реализовывают разработчики.
При составлении ТЗ можно как анализировать исходники старого продукта, так и вообще забить на них и ограничиться только стандартным выявлением требований путем интервьюирования заинтересованых лиц.
Я подчеркну: обычный процесс выявления требований обязательно должен присутствовать, а вот анализ исходников можно и опустить.
За столько лет наверняка там что-то осталось в текущей системе такого, что уже больше не требуется. Но из анализа исходников вы этого никогда не узнаете. Так же из аналлиза исходников вы не узнаете о нефункциональных требованиях.
Смотря что значит «серьезные». За большим количеством серьезных проектов скрывается относительно простая бизнес-логика, где знания алгоритмизации и математики неприменимы, потому что всё, что надо уже реализовано в стандартных или сторонних библиотеках.
Конечно какая-то база нужна, однако среди моего круга общения много тех, кто базу получил ещё до института, просто потому что это было интересно.
Ничуть не умаляю необходимость образования, однако всё же считаю что образование != диплом.
Нет, сделка будет занимать времени ровно столько, сколько и сейчас.
Этот механизм с выгрузками нужен что бы котролировать, что в базе данные не пропадают и не меняются.
Так же как консистентность данных можно обеспечить без блокчейна, точно так же с блокчейном можно добиться инконсистентности — ещё жива в памяти история с форком Etherium.
Но если в случае обычных пользователей ещё можно надеяться на здравый смысл и то, что постепенно все пользователи переползут на «правильную» ветку, то вот с госорганами на такое расчитывать не стоит, так как согласование подобного шага легко может занять пару лет у ГАИ.
Можно подумать, что «нормальные» компании не делают ошибок или у них никогда не случаются технические проблемы. Мы живем в реальном мире, а не идеальном, и от ошибок никто не застрахован.
Так же мы живем в мире где на открытом рынке присутствует большое количество игроков и покупатель волен выбирать сам, услугами кого он хочет воспользоваться — «ИП Рога и Копыта» или «ОАО Надежная Компания».
Мотивация у людей может быть разная и не надо подводить всё к единому знаменателю.
Так же наличие у ошибки ФИО не исправит её. Репутация компании-то может быть и подмокнет, а может и нет. А вот репутация автомобиля подмокнет абсолютно точно.
А что делать в случае, когда нерадивый менеджер страховой компании «Рога и Копыта» по ошибке внесёт в блокчейн кучу записей о выплатах по вашему автомобилю в связи с авариями?
Что делать в случае, когда коррумпированый сотрудник ГАИ внесет или НЕ внесет какие-то записи?
Так а что по поводу постройки маршрута от большого по площади магазина? Я на вскидку вижу проблему, что пользователь может быть далеко от той точки, от которой вы строите маршрут, но при этом его местоположение всё-таки «у Ашана». Но может возникнуть ситуация, что магазины через которые проложен маршрут не находятся в его поле зрения или заставляют его делать крюк.
Вы это как-то решаете?
Или эта проблема надумана и на практике такое крайне редко?
В примере пользователь строит маршрут от Ашана, который довольно большой сам по себе, но маршрут строится от какой-то конкретной точки. То есть делается предположение, что если пользователь у Ашана, то значит вот конкретно в этой точке — но это может быть не всегда верно. Пользователь может быть в 50 метрах оттуда и в его видимости может не быть магазинов, от которых построен маршрут. Как вы решаете эту проблему?
GPS-позиционирование внутри ТЦ может быть очень грубым, но пробовали ли вы его как-то задействовать? Не знаю как контакт и фейсбук, но телеграм точно позволяет отправить местоположение и есть боты которые это используют.
Вся эта чехарда с отпечатком пальца на входе выглядит как очередной попил: на нафига нужно всё это bio-smart оборудование, если автора провели без него, в сопровождении?
Улучшение транспортной системы в целом это очень хорошо, но если рассматривать только скорость движения наземного транспорта, то её можно было бы сильно увеличить только за счет отмены турникетов на входе.
В УК РФ и сейчас есть статья 122 — Заражение ВИЧ-инфекцией. При этом она наказывает не только за само заражение, но так же и за «заведомое поставление другого лица в опасность заражения» (122 п.1). Вот не знаю только, насколько широка практика применения этой статьи. Подозреваю, что она практически не применяется, так как доказательства собрать тяжело.
Интересно было бы в этом разрезе сравить УК РФ с кодексами других стран.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Конечно в какой-то конкретной команде всю коммуникацию можно держать через аналитиков. Но с таким же успехом тогда её можно построить и через архитектора. Это порочная практика в обоих случаях.
Ещё один момент, почему архитектор должен понимать язык бизнеса — архитектор участвует в пресейлах. А это значит, что надо уметь хорошо молоть языком и диаграммы рисовать не только в UML и с представителями заказчика говорить на одном языке.
При составлении ТЗ можно как анализировать исходники старого продукта, так и вообще забить на них и ограничиться только стандартным выявлением требований путем интервьюирования заинтересованых лиц.
Я подчеркну: обычный процесс выявления требований обязательно должен присутствовать, а вот анализ исходников можно и опустить.
За столько лет наверняка там что-то осталось в текущей системе такого, что уже больше не требуется. Но из анализа исходников вы этого никогда не узнаете. Так же из аналлиза исходников вы не узнаете о нефункциональных требованиях.
Конечно какая-то база нужна, однако среди моего круга общения много тех, кто базу получил ещё до института, просто потому что это было интересно.
Ничуть не умаляю необходимость образования, однако всё же считаю что образование != диплом.
Ничего общего с блокчейном я тут не вижу.
Этот механизм с выгрузками нужен что бы котролировать, что в базе данные не пропадают и не меняются.
Но если в случае обычных пользователей ещё можно надеяться на здравый смысл и то, что постепенно все пользователи переползут на «правильную» ветку, то вот с госорганами на такое расчитывать не стоит, так как согласование подобного шага легко может занять пару лет у ГАИ.
Так же мы живем в мире где на открытом рынке присутствует большое количество игроков и покупатель волен выбирать сам, услугами кого он хочет воспользоваться — «ИП Рога и Копыта» или «ОАО Надежная Компания».
Мотивация у людей может быть разная и не надо подводить всё к единому знаменателю.
Так же наличие у ошибки ФИО не исправит её. Репутация компании-то может быть и подмокнет, а может и нет. А вот репутация автомобиля подмокнет абсолютно точно.
Что делать в случае, когда коррумпированый сотрудник ГАИ внесет или НЕ внесет какие-то записи?
Вы это как-то решаете?
Или эта проблема надумана и на практике такое крайне редко?
GPS-позиционирование внутри ТЦ может быть очень грубым, но пробовали ли вы его как-то задействовать? Не знаю как контакт и фейсбук, но телеграм точно позволяет отправить местоположение и есть боты которые это используют.
Интересно было бы в этом разрезе сравить УК РФ с кодексами других стран.