О, хороший длиннопост и без комментариев - классика Хабра!
Буду исправлять, потому как ненавижу тишину и под своими постами. Не уверен, что осилю за раз, так что буду отписывать по ходу чтения. Опыт похожий, но со стороны архитектора и большего числа проектов, видно и другие детали.
на старте проекта закладывались вопросы и риски, которые невозможно было решить без серьезного пересмотра требований к решению и как результат последующего перезапуска проекта.
Это логично, потому что Закон Парето никто не отменял. Основной загвоздкой является клиент. Пару раз довелось работать с консультантами из больших с самого начала. Много раз видел выкладки с рекомендацией консультанта и абсолютно другое требование в RFP.
консультант уже не несет прямой ответственности за качество требований перед клиентом
В половине проектов, я видел консультантов и в стадии разработки на должности типа Program Architect и даже на стадии первичных UAT. Big4 стараются гарантировать обоснованность своей работы (они очень дорого берут за свое имя и потому сильно дорожат им) и доказать свою незаменимость (как раз основываясь на решениях клиента "вопреки" и на факте изменения требований с течением времени). Им очень выгодно нести эту ответственность, так как на самом деле они играют в стрелки, обосновывая проблемы либо решениями заказчика, либо ошибками разработчика (а там часто ещё и обслуживанием занимается кто-то третий). Проект то явно на год (-ы) разработки и любой аудитор захочет сидеть и назначать виноватых за большие деньги в течении всего этого срока.
На самом раннем этапе внедрять процедуру управления изменениями, показывать клиенту риски, включая технологические риски
Отлично, только у нас не ватерфол, так что проработанных требований всё равно не будет, а если вы уже согласились (подписали), то уповать вам стоит только на адекватность заказчика. Обычно все понимают правила игры, но в случае форс мажора (допустим смена руководителей или промах по бюджету и срокам), вполне могут вспомнить формальности.
Обычно все стороны хороши. И сейлзы со стороны разработчика (ваши) вписывают вас в проект не глядя, чтоб получить свои лёгкие деньги. Никогда не видел, чтоб бонус они получали по факту сдачи проекта клиенту. Только серьёзные убытки заставили одну компанию включить архитектора в пресейл, чтоб он мог делать ту самую валидацию требований, до подписания и взятых обязательств.
Мне кажется вполне нормальным, что Salesforce хочет, чтоб её сотрудники (включая Slack, Mulesoft, Tableau и остальных) разбирались в продуктах компании (коих дофига), хотя бы на базовом уровне. Именно для этого и есть Trailhead. Без этого не будет единой экосистемы, а просто набор продуктов без связки. Это противоречит и логике и бренду.
Традиционная - это какая? Традиций, знаете ли, как спортзалов... 5 подходов по 5 повторов или 3 по 8 и т.д. ? Название исследования подчёркивает упор на молодых женщин. А что там внутри, есть сравнение по полу и возрасту?
Это типа должно было звучать надмено и олдфажно? Третий пень... То что было вчера припомнить не проблема. А вот то что было лет 20 - 30 назад (что по срокам жизни человека даже не половина) - уже совсем другая, "не велосипедная" история. Вряд ли я бы сейчас без гуглежа запустил Дум с бластером на 4-ке SX, а когда-то был аникейщиком и зарабатывал на пиво. Разница лишь в том, что в отличии он новичка, я буду точно знать что искать.
Один раз сделав всё правильно, вы никогда этого не забудете
То что учил несколько лет и потом не использовал - уходит в void. Это и с иностранными языками и с математикой работает. Я могу помнить какие то термины и правила, но "сесть и поехать" уж точно нет.
Так, ChatGPT начнёт использовать модель GPT-4 по умолчанию, а также будет предлагать пользователям примеры подсказок. Они помогут лучше формулировать свои запросы. Опция предлагаемых ответов позволит ChatGPT развивать беседу, давая пользователю варианты продолжения обсуждения.
То есть решили проработать пользователей, вместо проработки модели...
Если верить Mi Band 5, то пробежка 5км (11 км/ч) сжигает меньше (около 100КК) чем быстрый шаг (6км/ч) на ту же дистанцию на том же маршруте. Ну и разница во времени конечно решает. Так что вместо часа ходьбы эффективней по калориям будет медленный бег (6-7 км/ч) на то же время.
Кассе не нужен ассортимент. Если грубо то нужен прайслист, ограничения, способы оплаты, скидки/предложения. Ассортимент включает в себя большую долю услуг и продуктов, которые не продаются, а по сему и кассе с этим делать нечего.
Большинство систем в крупном ритейле имеют хотя бы частично server-driven UI, так что на самом деле клиент кассы знает только часть данных - то что попало в кэш.
Это уже зависит от регулятора. Если магазин не прижимают, то они будут делать что хотят.
Ценник товара, в большинстве развитых стран, является обязательным (есть, конечно, исключения для ряда случаев). Такой ценник, как и реклама и акционное предложение являются public offer (публичная оферта?). А значит вам обязаны продать товар по этой цене. На самом деле по меньшей из двух цен - стоимость товара и акционная цена (есть всякие доп. регуляции об акциях и скидках, так что нельзя сделать "скидку" увеличивающую цену товара). Но тут надо читать мелкий шрифт под акционной ценой (там часто пишут срок и условия действия акции), так чтоб не попасть в убыток, если этот ценник забыли убрать или перепутали. Так что если касса знает, что срок истёк, но на плакате, ценнике и тд, этой даты нет, то всё равно действует оферта. Есть еще вариант, когда акция есть, но часть товара не доступна. Типа 1+1 на йогурт, но на полке только один. И тогда тоже вам должны либо изменить цену на тот единственный (50%), либо выдать ваучер (rain check) на второй йогурт. Касса вполне может и не знать про акцию, так как у акций много источников и есть шанс, что дистрибуция данных еще не прошла успешно по всем точкам. От исполнения обязательств оферты это не освобождает.
Кейс и-кома - это совсем другое и там всё намного проще технически. Регуляторы обычно даже дают стейты для каждого действия. Типа чек после оплаты, оплата после получения и тд.
В разных регионах разная фискализация: где-то, принтер, где-то сервис, где-то спец память и тд. Но в любом случае, если вы продолжаете продажи товаров требующих фискализацию (а кое где - это все товары вообще) во время недоступности сервиса/принтера, чеки надо выдавать всё равно. Для этого от налоговой получают блокнот с отрывными чеками. А тетрадь - для записи транзакций если касса всё-таки не доступна (обычно просто суммируют товары и средства), чтоб потом внести в систему.
Товар учитывается по разным показателям. Современные кассы - это просто клиент сложной системы. Счетчики товара на сервере(-ах) учитывают все транзакции: продажу, возврат, получение товара, списание и тд. Всё это по категории, магазину, кассе, кассиру и другим параметрам.
Но именно по транзакциям - завершённым сделкам. Так как кто-то мог не заплатить, спрятать, испортить товар, то есть еще и пересчёты (полные и частичные).
Так что магазин высчитывает баланс инвентаризации исходя из теоретических и фактических данных с поправкой на погрешность (статистика на основе истории товара и магазина). Что то типа: получено 100 йогуртов, продано 90, вернулись 3, испортилось 2, на полках 5, на складе 0, статистическая погрешность 1 = на полке 5 и 6 +/-1 гуляют по магазину в данный момент.
А что мешает создать стандарт/обновить существующий на штрихкоды/qr-code?
То, что по CI-CD нельзя переставить железо. Новый стандарт - новые сканеры. В каждую точку их нужно купить, поставить, настроить, утилизировать старые. Даже если сканер стоит 1 доллар, то в средней сети таких сканеров в ежедневной работе будет порядка 100к, и они в 1000 разных мест страны, куда нужно выслать оборудование и техника. А вот техник уже точно не поедет за доллар. Так что бюджет подобного решения будет стоить миллионы для каждой сети, не говоря уже об производителях товаров и упаковки, которые эти новые коды должны печатать. Ну и, конечно, такое изменение в один миг не провернешь, а значит будут годы параллельной работы старого и нового решения. И ради чего тратить миллиарды, у нас уже всё настолько хорошо, что только вот штрих код мешает зажить в раю?
Еще тетрадка и блокнотик с отрывными чеками. Потому что налоговой всё-равно, что при наличии питания и отсутствии сети касса не встанет: найдут незарегистрированные транзакции - и "встанет" вся сеть.
И сейчас никто, почему-то, не смог обойти САР теорему. IT большинства розничных магазинов приходится решать кучу NP-полных задач и, в отличии от очередных теоретиков-публицистов, там хорошо знают почему дела обстоят именно так, а не иначе.
О, хороший длиннопост и без комментариев - классика Хабра!
Буду исправлять, потому как ненавижу тишину и под своими постами. Не уверен, что осилю за раз, так что буду отписывать по ходу чтения. Опыт похожий, но со стороны архитектора и большего числа проектов, видно и другие детали.
Это логично, потому что Закон Парето никто не отменял. Основной загвоздкой является клиент. Пару раз довелось работать с консультантами из больших с самого начала. Много раз видел выкладки с рекомендацией консультанта и абсолютно другое требование в RFP.
В половине проектов, я видел консультантов и в стадии разработки на должности типа Program Architect и даже на стадии первичных UAT. Big4 стараются гарантировать обоснованность своей работы (они очень дорого берут за свое имя и потому сильно дорожат им) и доказать свою незаменимость (как раз основываясь на решениях клиента "вопреки" и на факте изменения требований с течением времени). Им очень выгодно нести эту ответственность, так как на самом деле они играют в стрелки, обосновывая проблемы либо решениями заказчика, либо ошибками разработчика (а там часто ещё и обслуживанием занимается кто-то третий). Проект то явно на год (-ы) разработки и любой аудитор захочет сидеть и назначать виноватых за большие деньги в течении всего этого срока.
Отлично, только у нас не ватерфол, так что проработанных требований всё равно не будет, а если вы уже согласились (подписали), то уповать вам стоит только на адекватность заказчика. Обычно все понимают правила игры, но в случае форс мажора (допустим смена руководителей или промах по бюджету и срокам), вполне могут вспомнить формальности.
Обычно все стороны хороши. И сейлзы со стороны разработчика (ваши) вписывают вас в проект не глядя, чтоб получить свои лёгкие деньги. Никогда не видел, чтоб бонус они получали по факту сдачи проекта клиенту. Только серьёзные убытки заставили одну компанию включить архитектора в пресейл, чтоб он мог делать ту самую валидацию требований, до подписания и взятых обязательств.
Мне кажется вполне нормальным, что Salesforce хочет, чтоб её сотрудники (включая Slack, Mulesoft, Tableau и остальных) разбирались в продуктах компании (коих дофига), хотя бы на базовом уровне. Именно для этого и есть Trailhead. Без этого не будет единой экосистемы, а просто набор продуктов без связки. Это противоречит и логике и бренду.
Давно пора, а то фолбэк никто не выключает ::фейспалм::
Традиционная - это какая? Традиций, знаете ли, как спортзалов... 5 подходов по 5 повторов или 3 по 8 и т.д. ? Название исследования подчёркивает упор на молодых женщин. А что там внутри, есть сравнение по полу и возрасту?
Это типа должно было звучать надмено и олдфажно? Третий пень... То что было вчера припомнить не проблема. А вот то что было лет 20 - 30 назад (что по срокам жизни человека даже не половина) - уже совсем другая, "не велосипедная" история. Вряд ли я бы сейчас без гуглежа запустил Дум с бластером на 4-ке SX, а когда-то был аникейщиком и зарабатывал на пиво. Разница лишь в том, что в отличии он новичка, я буду точно знать что искать.
То что учил несколько лет и потом не использовал - уходит в void. Это и с иностранными языками и с математикой работает. Я могу помнить какие то термины и правила, но "сесть и поехать" уж точно нет.
То есть решили проработать пользователей, вместо проработки модели...
Как то грустно у вас
Если верить Mi Band 5, то пробежка 5км (11 км/ч) сжигает меньше (около 100КК) чем быстрый шаг (6км/ч) на ту же дистанцию на том же маршруте. Ну и разница во времени конечно решает. Так что вместо часа ходьбы эффективней по калориям будет медленный бег (6-7 км/ч) на то же время.
Кассе не нужен ассортимент. Если грубо то нужен прайслист, ограничения, способы оплаты, скидки/предложения. Ассортимент включает в себя большую долю услуг и продуктов, которые не продаются, а по сему и кассе с этим делать нечего.
Большинство систем в крупном ритейле имеют хотя бы частично server-driven UI, так что на самом деле клиент кассы знает только часть данных - то что попало в кэш.
Кэширование и локальный репозиторий с иерархическими правилами и сдвигами.
Это уже зависит от регулятора. Если магазин не прижимают, то они будут делать что хотят.
Ценник товара, в большинстве развитых стран, является обязательным (есть, конечно, исключения для ряда случаев). Такой ценник, как и реклама и акционное предложение являются public offer (публичная оферта?). А значит вам обязаны продать товар по этой цене. На самом деле по меньшей из двух цен - стоимость товара и акционная цена (есть всякие доп. регуляции об акциях и скидках, так что нельзя сделать "скидку" увеличивающую цену товара). Но тут надо читать мелкий шрифт под акционной ценой (там часто пишут срок и условия действия акции), так чтоб не попасть в убыток, если этот ценник забыли убрать или перепутали. Так что если касса знает, что срок истёк, но на плакате, ценнике и тд, этой даты нет, то всё равно действует оферта. Есть еще вариант, когда акция есть, но часть товара не доступна. Типа 1+1 на йогурт, но на полке только один. И тогда тоже вам должны либо изменить цену на тот единственный (50%), либо выдать ваучер (rain check) на второй йогурт. Касса вполне может и не знать про акцию, так как у акций много источников и есть шанс, что дистрибуция данных еще не прошла успешно по всем точкам. От исполнения обязательств оферты это не освобождает.
Кейс и-кома - это совсем другое и там всё намного проще технически. Регуляторы обычно даже дают стейты для каждого действия. Типа чек после оплаты, оплата после получения и тд.
Уже не так.
В разных регионах разная фискализация: где-то, принтер, где-то сервис, где-то спец память и тд. Но в любом случае, если вы продолжаете продажи товаров требующих фискализацию (а кое где - это все товары вообще) во время недоступности сервиса/принтера, чеки надо выдавать всё равно. Для этого от налоговой получают блокнот с отрывными чеками. А тетрадь - для записи транзакций если касса всё-таки не доступна (обычно просто суммируют товары и средства), чтоб потом внести в систему.
Товар учитывается по разным показателям. Современные кассы - это просто клиент сложной системы. Счетчики товара на сервере(-ах) учитывают все транзакции: продажу, возврат, получение товара, списание и тд. Всё это по категории, магазину, кассе, кассиру и другим параметрам.
Но именно по транзакциям - завершённым сделкам. Так как кто-то мог не заплатить, спрятать, испортить товар, то есть еще и пересчёты (полные и частичные).
Так что магазин высчитывает баланс инвентаризации исходя из теоретических и фактических данных с поправкой на погрешность (статистика на основе истории товара и магазина). Что то типа: получено 100 йогуртов, продано 90, вернулись 3, испортилось 2, на полках 5, на складе 0, статистическая погрешность 1 = на полке 5 и 6 +/-1 гуляют по магазину в данный момент.
То, что по CI-CD нельзя переставить железо. Новый стандарт - новые сканеры. В каждую точку их нужно купить, поставить, настроить, утилизировать старые. Даже если сканер стоит 1 доллар, то в средней сети таких сканеров в ежедневной работе будет порядка 100к, и они в 1000 разных мест страны, куда нужно выслать оборудование и техника. А вот техник уже точно не поедет за доллар. Так что бюджет подобного решения будет стоить миллионы для каждой сети, не говоря уже об производителях товаров и упаковки, которые эти новые коды должны печатать. Ну и, конечно, такое изменение в один миг не провернешь, а значит будут годы параллельной работы старого и нового решения. И ради чего тратить миллиарды, у нас уже всё настолько хорошо, что только вот штрих код мешает зажить в раю?
Еще тетрадка и блокнотик с отрывными чеками. Потому что налоговой всё-равно, что при наличии питания и отсутствии сети касса не встанет: найдут незарегистрированные транзакции - и "встанет" вся сеть.
И сейчас никто, почему-то, не смог обойти САР теорему. IT большинства розничных магазинов приходится решать кучу NP-полных задач и, в отличии от очередных теоретиков-публицистов, там хорошо знают почему дела обстоят именно так, а не иначе.
Мета только и делает, что разрабатывает аналоги. Это новость - аналог новости.