Size: a a a

2019 November 09

R(

Roman (rpwheeler) in QA Alliance
Ну хлоп же ж вашу материнскую плату. UI может не быть. Вообще. Совсем. Абсолютно.
источник

КР

Константин Рассафоно... in QA Alliance
Roman (rpwheeler)
Советую забыть про универсальные правила для всех независимо от количества человек.
Потому что и общего кода может не быть, и общих компонент, и общего глоссария.
Могут быть команды / проекты без UI , которым дизайн система нужна как абстрактному пожарному абстрактный курс по парусному спорту.  
И с knowlege transfer могут быть проблемы просто если не налажено.
Я про универсальные правила для всех ни разу не утверждал, ну ёлки-палки
источник

КР

Константин Рассафоно... in QA Alliance
Привожу примеры, когда это возможно и выгодно
источник

R(

Roman (rpwheeler) in QA Alliance
Константин Рассафонов
Но если есть планы по наращиванию составов - то лучше раньше начать готовить почву, чем потом сделать единую систему и всех людей через "неинтересно" перетаскивать и переписывать все фронтенд продукты
Кому лучше? Любая подготовка это расходы. Кто будет прописывать эти расходы и планы заранее?
источник

КР

Константин Рассафоно... in QA Alliance
Нет ui- нет общих ui компонентов, мы же тут со здравым смыслом воевать не собираемся?
источник

КР

Константин Рассафоно... in QA Alliance
Roman (rpwheeler)
Кому лучше? Любая подготовка это расходы. Кто будет прописывать эти расходы и планы заранее?
Есть к примеру исторические данные по онбордингу, можно оценить использование условно-одинаковых ui элементов или любых их аналогов для рассматриваемого проекта. И банально посчитать, сколько тратится на переизобретение велосипеда каждой командой по-отдельности, а сколько примерно потратится на хороший велосипед для всех. Не идеальный причем велосипед, он не все задачи всех команд покроет. Но сумма экономии может оказаться выше
источник

КР

Константин Рассафоно... in QA Alliance
Давайте аргументы друг друга не только анализировать, но из текста синтез проводить. Универсальных правил нет. Каждое производство уникально по-своему. Есть теорема Гёделя о неполноте, которая говорит что всё формализовать нельзя. Но это ж не повод даже не пытаться использовать сильные и полезные стороны формализации? А здравый смысл или эвристики использовать там где формализация имеет слабые места. Или, если угодно, делать наоборот. И дополнять эвристики формализацией
источник

R(

Roman (rpwheeler) in QA Alliance
Константин Рассафонов
Есть к примеру исторические данные по онбордингу, можно оценить использование условно-одинаковых ui элементов или любых их аналогов для рассматриваемого проекта. И банально посчитать, сколько тратится на переизобретение велосипеда каждой командой по-отдельности, а сколько примерно потратится на хороший велосипед для всех. Не идеальный причем велосипед, он не все задачи всех команд покроет. Но сумма экономии может оказаться выше
"Может-то он может, только кто ж ему даст". (из анекдота, но суровая реальность).
источник

R(

Roman (rpwheeler) in QA Alliance
Константин Рассафонов
Есть к примеру исторические данные по онбордингу, можно оценить использование условно-одинаковых ui элементов или любых их аналогов для рассматриваемого проекта. И банально посчитать, сколько тратится на переизобретение велосипеда каждой командой по-отдельности, а сколько примерно потратится на хороший велосипед для всех. Не идеальный причем велосипед, он не все задачи всех команд покроет. Но сумма экономии может оказаться выше
На практике использование одинаковых элементов может сделать хуже, если вместо выбора элементов под специфику решат слепить "из того что было".
источник

КР

Константин Рассафоно... in QA Alliance
Разумеется
источник

КР

Константин Рассафоно... in QA Alliance
Поэтому надо оценить есть ли выгода, и браться за дело, если выгода ожидается значительная
источник

КР

Константин Рассафоно... in QA Alliance
Для верности умножить на Пи все предполагаемые затраты на такую разработку
источник

КР

Константин Рассафоно... in QA Alliance
И если выгода всё ещё значительная - тогда делать
источник

КР

Константин Рассафоно... in QA Alliance
Примеры тех же фронтовых дизайн систем есть. Например, Тинькофф банк любит о них рассказывать, а знакомые оттуда подтверждают, что фишка "взлетела"
источник

R(

Roman (rpwheeler) in QA Alliance
Константин Рассафонов
Давайте аргументы друг друга не только анализировать, но из текста синтез проводить. Универсальных правил нет. Каждое производство уникально по-своему. Есть теорема Гёделя о неполноте, которая говорит что всё формализовать нельзя. Но это ж не повод даже не пытаться использовать сильные и полезные стороны формализации? А здравый смысл или эвристики использовать там где формализация имеет слабые места. Или, если угодно, делать наоборот. И дополнять эвристики формализацией
Практическая деятельность иных компаний куда больше похожа на Законы Мэрфи, комикс Дилберт, анекдот "думай, не думай, а прыгать надо", "бери больше, кидай дальше, пока летит — отдыхай" и пр.
Я-то знаю про дизайн-системы, но суровая реальность практической работы показывает ой-ой-ой.  Причём люди которые этой практической работой управляют полагают что рациональны как раз они, оперативно пытаясь заткнуть текущие дыры вместо того чтобы "остановиться. оглянуться".
источник

КР

Константин Рассафоно... in QA Alliance
Да, такие вещи проваливаются. Как и любая деятельность, гарантий не даёт даже страховая
источник

R(

Roman (rpwheeler) in QA Alliance
источник

КР

Константин Рассафоно... in QA Alliance
Но ведь и эвристики могут проваливаться, по определению своему
источник

R(

Roman (rpwheeler) in QA Alliance
"Тем, кто любит колбасу и уважает закон, не стоит видеть, как делается то и другое." — на этом месте я сказал "тем кто пользуется нашим продуктом лучше тоже не знать как он делается".
источник

R(

Roman (rpwheeler) in QA Alliance
Константин Рассафонов
Но ведь и эвристики могут проваливаться, по определению своему
Совершенно именно так.
источник