Немного о TTOP. Часть II. Про что это? Продолжение

Практические нотации.

Два главных паттерна, а скорее даже вывода TTOP: типы команд и виды взаимодействий.

Тут я ввиду отсутствия устоявшегося русскоязычного аналога приведу и англоязычные оригиналы.

Типы команд

👉Stream-aligned team – команда, ориентированная на поток – по сути это кросс-функциональная команда, заточенная на постоянную работу непосредственно над «ценностью».

В TTOP используется слово «value» в смысле чего-то, что имеет значение для конечного пользователя. При этом у этих ценностей существует иерархия – логично подразумевается, что одна команда в размере 5-9 человек не может целиком отвечать за какой-нибудь большой продукт, поэтому воспринимать «ценность» следует, скорее, как некую функциональность, службу, делить которую на какие-то части не имеет смысла либо в виду потери связанности, либо в виду того, что команда вменяемого размера способна справиться с ней самостоятельно.

Предполагается, что этот тип – базовый в компании, их число может достигать 80% от всех команд разработки. Собственно, главные особенности таких команд – минимальные горизонтальные зависимости от остальных и end-to-end ответственность за продукт.

👉Enabling team – команда-помощник. Пожалуй, самый размытый типаж. Некоторые люди вообще понимают эти команды как некоторое подобие наполеоновской гвардии, которая приходит в отчаянный момент и всех спасает.

На самом деле – это более широкое понятие, скорее про в целом оценить необходимое воздействие, возможно обучить базовым навыкам. Своеобразный менторинг. Команда не обязательно должна быть постоянно в статусе «enabling» - это может быть команда другого типа, которая обладает требуемыми навыками, предположим, потоковой команды – таким образом, это скорее уже описание взаимодействия, чем типа команды. Главное – это взаимодействие должно носить временный характер.

👉Complicated subsystem team – команда сложных подсистем. Отвечают за разработку механизмов, которые будут использоваться другими командами по библиотечному принципу. К примеру, распознавание лиц.

👉Platform team – команда инструмента. Кажется, что это очень похоже на предыдущий тип, но нет. Я осознанно заменил «платформу» на инструмент, чтобы было понятнее, что имеется в виду. «Platform» тут скорее говорит о большем масштабе, чем «subsystem». Большей трудоёмкости, необходимости постоянной поддержки и совершенствования.

Это команды, разрабатывающие и сопровождающие «ценности», но не для клиента, а для других команд. Типа разнообразных бэкстейдж-инструментов, готовых сред разработки, пайплайнов, инструментов мониторинга.

Режимы взаимодействия.

👉Collaboration – тесное взаимодействие. Две команды работают вместе для решения общей задачи.

Сотрудничество в таком формате подразумевается только с одной командой в один момент времени ввиду высоких накладных расходов. По этой же причине рассматривается исключительно как временная мера, которая имеет возможность перерасти во взаимодействие X-as-a-Service.

👉X-as-a-Service – использование результата деятельности другой команды, как сервис, некий «чёрный ящик», с известными входными и выходными параметрами, без непосредственного взаимодействия с разработчиками.

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

👉Facilitating – помощь. Одна команда помогает другой в рамках решения общей задачи. Да-да, это именно про взаимодействие с enabling team. Чтобы не повторяться – вернитесь и прочтите, если не помните.

Вот в целом и всё. И как я уже говорил – вроде всё по делу. И, как я уже говорил – есть «но». Я дам немного времени Вам отдохнуть и даже может быть самим подумать, что не так с TTOP. Даже скорее, где и почему TTOP теряет свою охуенность.

А озвучки не будет. В Google поменяли что-то в проверке региона и теперь их aistudio мне недоступна даже через три весёлых буквы. Пока разбираться лень

#медведьразмышляет #управление #ttop