Size: a a a

2019 November 09

КР

Константин Рассафоно... in QA Alliance
Понятнок дело, что выхлоп деятельности должен быть оцене положительно
источник

R(

Roman (rpwheeler) in QA Alliance
И с чего бы это новые команды будут заниматься тем же?
источник

R(

Roman (rpwheeler) in QA Alliance
У команд могут быть немножко разные задачи и домены.
источник

КР

Константин Рассафоно... in QA Alliance
Roman (rpwheeler)
Чем выгодно?
Договориться дешевле когда мало, а потом скажем ускорить онбординг большого числа людей, потому что в единой аппарате две команды работают и могут параллельно больше людей вводить в курс дела
источник

КР

Константин Рассафоно... in QA Alliance
Roman (rpwheeler)
... но не только лишь все :) Получается кому-то полезна, а кто-то продолжает с галлонами и милями (причём разными милями).
А вот как раз это пример в мою пользу
США давно хотели присоединиться к СИ, трагические события помешали это сделать, а теперь поменять систему очень дорого
источник

R(

Roman (rpwheeler) in QA Alliance
В совершенно практической ситуации команда А могла работать в рамках одной компании, а команда Б в рамках другой. Потом компания А купила компанию Б, но приводить их к общему глоссарию некогда да и никто не собирался, зачем, они вообще в разных странах.

Потом появились команды А1 и Б1 как усиление А и Б.

Потом появятся А2 и Б2 и Б3.

Общего глоссария так и не будет, но всё работает.
источник

КР

Константин Рассафоно... in QA Alliance
Roman (rpwheeler)
В совершенно практической ситуации команда А могла работать в рамках одной компании, а команда Б в рамках другой. Потом компания А купила компанию Б, но приводить их к общему глоссарию некогда да и никто не собирался, зачем, они вообще в разных странах.

Потом появились команды А1 и Б1 как усиление А и Б.

Потом появятся А2 и Б2 и Б3.

Общего глоссария так и не будет, но всё работает.
Вполне разумно оставить всё как есть в такой ситуации. Она не совпадает с моим примером, а как я говорил, у такой деятельности должна быть оценка, выдающая в прогнозе хорошую экономию. Потому что если прогноз говорит "на 2% эффективнее станем", очевидно что всю пользу съедят неучтенные факторы-помехи
источник

R(

Roman (rpwheeler) in QA Alliance
Поехали дальше.

Итак, пусть было две команды. Одна из них отвечает за мобильное приложение, а вторая за админку в которой составляется контент, который приложение отображает.
Проходит какое-то время.

Теперь команд пять. Третья отвечает за отчёты которые запрашиваются заказчиками, четвёртая за интеграцию со сторонними системами куда может передаваться собранная в приложении информация, пятая за платежи,

Та-да-да-дам. Второй звонок.

Что в мобильный клиент, что в отчёты залетают новые фичи. Скажем, в мобильный клиент залетает своя интеграция со стандартом Mobile Device Management.
В отчёты залетает Tableau.
В платежи залетает какой-то Bluefin.
В команду интеграций залетает такое что без специальных платных тренингов вообще не разберёшься как работает.

Если вы хотите чтобы КАЖДАЯ команда владела словарём КАЖДОЙ другой, вам надо потратить в пять раз больше времени, чтобы КАЖДЫЙ программист и тестировщик в другой команде получил ту же информацию. Кроме того они гарантированно забудут её без практики (а практики у них нет, потому что они на своих задачах), и через пол-года у тебя будут спрашивать опять "а что такое это MDM?"

Если вы хотите чтобы владела не только словарём, но и практикой по фичам, вам надо потратить ещё больше времени.

Очень скоро руководство обламывается с мечтами об общем и универсальном,  до него доходит что каждое направление пусть лучше проверяет специалист по данному направлению.
источник

КР

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

Пример наоборот. Покупаем 1 или даже 3 команды целиком из очередного развалившегося гигантв типа рамблера.

Если нам нечего им показать в качестве документации по стандартам принятым и терминологии (и другому множеству вещей), мы рискуем получить совершенно замкнутый анклав сработавшихся разработчиков, которые плохо интегрируются во взаимодействия с другими командами и проектами. Зачастую это вообще не проблема, но если есть понимание, что к примеру возможно перераспределение людей на другие составы, с перемешиванием "старых" и "новых", или укрепление "анклава" командой из местных, можем получить проблемы интеграции, а то и ситуацию когда весь анклав проще уволить.
А договорились бы на берегу - или упростили бы интеграцию в состав предприятия, или не наняли бы тех из них, кто сходу не согласен
источник

R(

Roman (rpwheeler) in QA Alliance
> Тогда теряется взаимозаменяемость людей, вплоть до того что в команде пилит каждый свой кусок и про других ничего знать не знает.

Не теряется. Её не было, нет и не будет, как не заменишь фронтендера на джаваскрипте айосником или пхпшником.
источник

КР

Константин Рассафоно... in QA Alliance
Roman (rpwheeler)
> Тогда теряется взаимозаменяемость людей, вплоть до того что в команде пилит каждый свой кусок и про других ничего знать не знает.

Не теряется. Её не было, нет и не будет, как не заменишь фронтендера на джаваскрипте айосником или пхпшником.
Пример - общие компоненты фронтенда для разных проектов
источник

R(

Roman (rpwheeler) in QA Alliance
Константин Рассафонов
Пример - общие компоненты фронтенда для разных проектов
Если они были. Или есть. Или будут. В админке кастомные, в отчётах Tableau . Общего аж база данных.
источник

КР

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

КР

Константин Рассафоно... in QA Alliance
Roman (rpwheeler)
Если они были. Или есть. Или будут. В админке кастомные, в отчётах Tableau . Общего аж база данных.
Если мы приводим примеры, то тогда имеет смысл в их рамках обсуждать же. Понятное дело, если ежу очевидно отсутствие пользы от гармонизации или её невозможность, гармонизацию делать не нужно
источник

R(

Roman (rpwheeler) in QA Alliance
>  можем получить проблемы интеграции, а то и ситуацию когда весь анклав проще уволить

Разумеется можем получить. Но можем получить и по куче других причин, вроде, как я уже указал "неинтересно" или "несовместимость" и пр.

В этом плане я таки сторонник аналога lazy initialization — заводите введение в понятия тогда когда оно вам реально понадобится или вот-вот понадобится. Потому что если заведёте его сильно заранее без практики, всё забудется под потоком текучки.
источник

КР

Константин Рассафоно... in QA Alliance
В компании на 500 человек с 10+ фронтенд командами "общие компоненты", "дизайн система" - это буквально есть графический/кодовый глоссарий единый для всех. И его ввод может экономить ощутимые деньги и время, особенно если его поддержку удалось успешно вывести на "техническую" команду
источник

КР

Константин Рассафоно... in QA Alliance
Может, не обязательно сэкономит
источник

КР

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

R(

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

КР

Константин Рассафоно... in QA Alliance
с такими компонентами кстати даже тестировать лучше - любой тестер с любого  продукта знает ожидаемое поведение UI элементов
источник