Привет) Всё верно. Потому и указал, что книги это основа, а видео на ютубе это огранка духа времени, как раз то, о чём вы говорите - некий доп.материал облагораживающий знания фундаментальные текущими обстоятельствами на рынке.
Токены в этой части упоминаются в рамках классического понимания, для общего представления, т.к. эта часть про архитектуру структурного построения дизайн-системы по её сущностям. В третей части мы как раз раскроем тему про токены более подробно, не в таком устаревшем и простом понимании, как упоминается в данной части.
"Но некоторые утверждения, как выше, базируются, в большей степени, на персональном опыте" - это верно. Именно привносим свой взгляд на вещи. Возможно, кто-то найдёт в этом свою правду и поможет развить курс.
Что конкретны вы подразумеваете под инженерной средой с реальным опытом проектирования продуктов, производств и комплексов?
Справедливое замечание. Но поскольку эта статья носит скорее философский характер, как некое размышление о производственных процессах, мы не углублялись в Голоссарий.
В следующей статье мы подвергнем критике атомарную дизайн-систему и дадим свои термины и определения. Там всё более конкретно, поскольку вторая часть ближе к конкретике и практике, в силу имеющегося опыта и экспертизы.
Спасибо за комментарий. Как и указано в начале, статья носит "сугубо философский характер, некий взгляд на вещи, на то, каким путём имеет смысл идти в выстраивании рабочих процессов над продуктом". Это некое размышление о том, что нужно выстраивать "язык общения" между отделами ради достижения общей цели - качественного продукта, который бы не являлся статьёй расходов. Тут скорее про путь к зрелости команд и владельцев бизнеса, про то, как на наш взгляд было бы уместнее выстраивать рабочие процессы внутри команд. Оценку зрелости предлагает CMMI модель, но не предлагает решений. Мы, в свою очередь, хотим дать пищу для размышлений о том, что необходимо искать пути решения для построения таких процессов управления командами, вкупе с методологиями Srum и т.д., с помощью которых можно достичь более эффективных показателей производств. Того уровня зрелости, при котором it-продукт будет частью бизнеса, что является инструментом на рынке, а не статьёй расходов.
В связи с тем, что у нас не хватает компетенций по всем направлениям, чтобы вывести общую формулу, мы пошли по пути некой идеи, философии и личного взгляда на подобные вещи, которые кто-то разделит, раскритикует, дав в свою очередь пищу для размышлений нам или дополнит своими компетенциями, переосмыслит со своей точки зрения.
В принципе, эта статья является вводной как раз для более конкретных статей.
Следующая статья выйдет в ближайшие дни. Она будет посвящена критике атомарной дизайн-системы, где мы предложим свой взгляд на вещи, более конкретный и обоснованный.
Если кому-то поможет понять устройство рынка в дизайне, то уже хорошо
Да, есть такое.
Привет) Всё верно. Потому и указал, что книги это основа, а видео на ютубе это огранка духа времени, как раз то, о чём вы говорите - некий доп.материал облагораживающий знания фундаментальные текущими обстоятельствами на рынке.
ссылку на "забытое" тогда, ибо иначе обвинения беспочвенны, так можно про каждую статью сказать
Да я просто обожаю loveform. А что такое этот loveform?
Спасибо за комментарий.
Токены в этой части упоминаются в рамках классического понимания, для общего представления, т.к. эта часть про архитектуру структурного построения дизайн-системы по её сущностям. В третей части мы как раз раскроем тему про токены более подробно, не в таком устаревшем и простом понимании, как упоминается в данной части.
Понял. Спасибо за развёрнутый ответ.
Спасибо за комментарий
"Но некоторые утверждения, как выше, базируются, в большей степени, на персональном опыте" - это верно. Именно привносим свой взгляд на вещи. Возможно, кто-то найдёт в этом свою правду и поможет развить курс.
Что конкретны вы подразумеваете под инженерной средой с реальным опытом проектирования продуктов, производств и комплексов?
Спасибо за комментарий.
Справедливое замечание. Но поскольку эта статья носит скорее философский характер, как некое размышление о производственных процессах, мы не углублялись в Голоссарий.
В следующей статье мы подвергнем критике атомарную дизайн-систему и дадим свои термины и определения. Там всё более конкретно, поскольку вторая часть ближе к конкретике и практике, в силу имеющегося опыта и экспертизы.
Спасибо за комментарий.
Как и указано в начале, статья носит "сугубо философский характер, некий взгляд на вещи, на то, каким путём имеет смысл идти в выстраивании рабочих процессов над продуктом". Это некое размышление о том, что нужно выстраивать "язык общения" между отделами ради достижения общей цели - качественного продукта, который бы не являлся статьёй расходов. Тут скорее про путь к зрелости команд и владельцев бизнеса, про то, как на наш взгляд было бы уместнее выстраивать рабочие процессы внутри команд. Оценку зрелости предлагает CMMI модель, но не предлагает решений. Мы, в свою очередь, хотим дать пищу для размышлений о том, что необходимо искать пути решения для построения таких процессов управления командами, вкупе с методологиями Srum и т.д., с помощью которых можно достичь более эффективных показателей производств. Того уровня зрелости, при котором it-продукт будет частью бизнеса, что является инструментом на рынке, а не статьёй расходов.
В связи с тем, что у нас не хватает компетенций по всем направлениям, чтобы вывести общую формулу, мы пошли по пути некой идеи, философии и личного взгляда на подобные вещи, которые кто-то разделит, раскритикует, дав в свою очередь пищу для размышлений нам или дополнит своими компетенциями, переосмыслит со своей точки зрения.
В принципе, эта статья является вводной как раз для более конкретных статей.
Следующая статья выйдет в ближайшие дни. Она будет посвящена критике атомарной дизайн-системы, где мы предложим свой взгляд на вещи, более конкретный и обоснованный.