Ну, в целом - если прищуриться и скрестить пальцы в кармане – всё так. Реально, очень хорошая штука. Без шуток. Как готовая модель управления – идеальна, насколько вообще может быть идеальна готовая модель управления.
Но по порядку.
👉Первое, что напрочь игнорируют люди при натягивании TTOP на какой-нибудь сферический предмет – область применения. То, что я написал в самом начале
Team Topologies это методология построения командной работы, ставящая во главу угла БЫСТРОЕ ДОСТИЖЕНИЕ РЕЗУЛЬТАТА
Прямо на обложке одной из двух основополагающих книг методики достаточно внятным шрифтом написано «organizing business and technology teams for fast flow». FAST, БЛЯТЬ, FLOW. Флоу само по себе во всей этой теории воспринимается с примесью не только поставки, но и скорости. А тут еще и фаст.
Короче, Вы поняли: главное – скорость. А теперь давайте подумаем, когда важна скорость? Даже так: СКОРОСТЬ. Первое, что приходит на ум: необходимо пофиксить баги. Выпустить патчи. Еще когда?...
Знаете, скорость в целом никогда не была главной проблемой при разработке. Сейчас, с увеличением роли ИИ, станет еще меньшей.
Надо пояснить? Ну ок.
➡️Смотрите, сколько реально новых фич способен клиент ввести в свой «рацион»? и в какой промежуток времени? Реально ли больше, чем команда способна произвести? А если выкинуть «мусорные» фичи, типа «давайте ебанем на кнопки вместо томатно-красного бисмарк-фуриозо»? Это первый аспект.
➡️Второй аспект в скорости – это возникновение бэклога, но уже на стороне клиента, когда у него накапливаются изменения, которые он еще не использовал. По итогу вы растягиваете «время до оценки» на неопределенный, возможно даже, бесконечный срок.
➡️Третий аспект: ИИ мало того, что уменьшает время разработки, так и позволяет в определенных условиях – стабильный продукт на стабильном рынке, возможно даже чисто внутреннем для компании – обходиться без команды, как таковой, достаточно обеспечить функцию контроля одним зевающим кожаным.
Так что, если у Вас нет необходимости в fast flow – начните думать по-другому. Не как натянуть сову на глобус, а как взять от этой совы что-то, что будет реально полезно в конкретной ситуации. А то и сову порвёте, и головой крутить на 360 не сможете. Я периодически говорю об этом по разным поводам. Теория – это хорошо. Но её необходимо анализировать перед применением.
👉Второе, что сразу бросается в глаза – в TTOP остается очень много серых зон, которые регламентируются «самосознанием» команд. Этаким коллективным бессознательным, которое должно управлять адаптивностью команд.
Ну правда, как часто вы вообще становились свидетелем того, что команды берут на себя дополнительную ответственность или, наоборот, отдают свой сервис другому? Подобные процессы намного чаще сопровождаются решением сверху и стенаниями с обоих сторон.
Так что бросьте. TTOP – вообще не про гибкость и адаптацию. Более того, TTOP тут само себе противоречит, с одной стороны призывая к адпативности, с другой - настаивая на том, что лучшее, что может случится с Вашей компанией - долгоиграющая команда. Я утрирую, там есть поползновения в сторону золотой середины, но кого это ебёт.
👉Отсюда мы получаем очередную границу применимости TTOP – финансы. Беда всех проектных кроссплатформенных команд: они очень неохотно делятся кадрами. А если у вас в них занято подавляющее большинство сотрудников, то оптимизация их использования при низкой адаптивности будет минимальной. Именно поэтому столь впечатляющий список гигантов, использующих подход Team Topologies, и столь плохо модель применима в варианте «как есть» на чём-то более мелком.
А озвучки не будет. В Google поменяли что-то в проверке доступности и теперь их aistudio мне недоступна даже через три весёлых буквы. Пока разбираться лень
#медведьразмышляет #управление #ttop