Size: a a a

2019 November 08

MT

Maria Teryokhina in QA Alliance
Не про человечество сейчас, а про 600 человек всего лишь :)
источник

R(

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

MT

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

MT

Maria Teryokhina in QA Alliance
Общаюсь я с ними, и мне очень тяжко...
источник

R(

Roman (rpwheeler) in QA Alliance
"А кому сейчас легко?"
источник

MT

Maria Teryokhina in QA Alliance
Так вот как сделать так, чтобы они коммуницировали при ОТСУТСТВИИ единого понятийного аппарата?
источник

MT

Maria Teryokhina in QA Alliance
Раз мы за практику, скажите, пожалуйста, как это сделать?
источник

R(

Roman (rpwheeler) in QA Alliance
Я не понял проблемы.

Есть команда/подразделение Т, которая работает со своим понятийным аппаратом. отличающимся от общего.
Люди которые приходят в команду Т знакомятся с этой практикой и учат этот понятийный аппарат  T(D).
Людям которые не приходят в команду Т понятийный аппарат команды Т(D) может быть не нужен.
Они общаются в пределах существующего пересекающегося аппарата.

В пределах той же компании есть команда/подразделение W. У них другие задачи, они используют другой аппарат, общаться с T им не очень надо, скорее по поводу релизов и фич, и это осуществляется, ну пусть, через общие описания фич и интерфейсов.

При этом у команд T и W всё равно есть расхождения. Им нужно общее только на том стыке где они собственно пересекаются.
источник

R(

Roman (rpwheeler) in QA Alliance
Грубо говоря, они общаются как две разных библиотеки (програмных функций) — там где одной библиотеке надо вызывать другую, есть общий интерфейс. Внутри же у каждой может быть нечто совершенно своё, а "единая система оценки роста" им может быть нужна как рыбке зонтик, зайцу велосипед, от жилетки рукава и от мёртвого осла уши.
источник
2019 November 09

КР

Константин Рассафоно... in QA Alliance
А что в таком случае мешает, при наличии времени и ресурсов индуктивно отработать "знакомятся с практикой и учат понятийный аппарат" на все остальные команды?
Тем самым получив искомый понятийный аппарат общий для организации. Не для всего мира, о чём тут кажется никто ни разу не просил.
Но если мы можем онбордить в команде 1 работника в день/неделю/месяц, имеем запас средств и желание/необходимость, мы можем провксти эту операцию для остальных участников из других команд, предварительно выбрав конкретный аппарат, хоть T, хоть W
источник

R(

Roman (rpwheeler) in QA Alliance
Константин Рассафонов
А что в таком случае мешает, при наличии времени и ресурсов индуктивно отработать "знакомятся с практикой и учат понятийный аппарат" на все остальные команды?
Тем самым получив искомый понятийный аппарат общий для организации. Не для всего мира, о чём тут кажется никто ни разу не просил.
Но если мы можем онбордить в команде 1 работника в день/неделю/месяц, имеем запас средств и желание/необходимость, мы можем провксти эту операцию для остальных участников из других команд, предварительно выбрав конкретный аппарат, хоть T, хоть W
А зогчем оно нужно?

Подразделение T 10 лет работает без этого общего опарата, подразделение W тоже без него лет 5 работает. Они пересекаются через какую-то вообще третью систему CDB, из которого W вызывает данные которые положило туда T.  Как софт от T обрабатывает эти данные W не знает и не интересуется. T немножко интересуют случаи использования этих данных, но именно случаи использования, а не понятийный аппарат команды W. W отвечает за GUI часть и немножко за клиентское API. У T нет GUI вообще, и своё API, которое с API W не пересекается вообще никак.

Для материализации аналогии (упрощая): допустим, T заносит в базу данных регистрацию авто и ДТП или другие неприятности с ними происходящие. W работает над клиентом, который эти данные достаёт и показывает информацию по конкретному номеру — владелец, история владения, попадал ли он в ДТП или другие происшествия.

Какие-то общие понятия у них будут, но унификация до чего-то совсем общего им нужна как рыбке зонтик.
источник

КР

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

КР

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

R(

Roman (rpwheeler) in QA Alliance
Maria Teryokhina
И все-таки я попробую, ради интереса...
@rpwheeler , предположим, что основываясь на гипотезе «ненужности и отсутствия» общего языка, нужно (мне конкретно- это чтоб не было вопроса «кому нужно?») организовать взаимодействие 100+ тестировщиков (хотя бы, если не говорить о ещё 500+ разработчиках и аналитиках) для обмена опытом/знаниями, для анализа текущей ситуации на всех проектах (>70), для дальнейшего упрощения выбора людей на проекты и для составления списка бэст практик, стратегии тестирования, единой системы оценки роста сотрудников, и ещё пачки целей.
Так вот, эти люди из 4 стран, общий язык- Английский (кто-то лучше говорит, кто-то хуже).
Если нет единого понятийного аппарата, то каким образом Вы предлагаете это сделать: то есть наладить коммуникацию хотя бы? Придумать свой новый понятийный аппарат или что?
Продолжая тему. Я давно отношусь с подозрением к любым "единым системам", и много раз с ехидством спрашивал как же ж это мы жили без бэст практик и единой системы сидения на офисных креслах.

"Упрощение выбора людей на проекты" я не знаю что за зверь. Всё сложно, если у вас не штампованные стандартные люди-клоны на выбор, я не знаю как это упростить. Везде где видел, индивидуальные команды выбирали под себя.

"Бэст практик" и "единую систему оценки роста"  да отведут от меня феи :) . Недавно присутствовал в обсуждении "системы роста", и когда я сказал что с такой системой для роста проще сменить работу, почему-то все одобрительно заржали.

Единую стратегию тестирования для разных команд в разных областях (API, Web, Mobile) я вообще не представляю. Мобильщикам нужны интерфейс гайдлайны, бэкэндщикам они не нужны. Перфоманс у тех и тех разный.

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

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

R(

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

Есть такой принцип YAGNI
источник

R(

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

КР

Константин Рассафоно... in QA Alliance
Roman (rpwheeler)
> но может пригодится

Есть такой принцип YAGNI
У команды может не быть информации о том, что к примеру создадут третью команду, или продукт разделят на части. Создание единой системы в таком случае может сэкономить время на старт нового проекта. Разумеется может не окупиться, но если планируется резкий рост и набор, можно оценить как полезное действие
источник

КР

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

R(

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

R(

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