Комментарии 31
Вы изобрели т.н. "сильную матрицу"
То что читал про сильную матрицу немного про другое, может скинете что где прочитать, чтобы сказать да, это просто аналогия сильной матрицы?
Какой-то авторитетный пруф я вам не найду, помимо того, что вы сами можете нагуглить (раз, два). Тем более, что принцип сильной матричной структуры простой - двойственность управления, функциональное и проектное, сотрудники объединены в отделы по функциональности (разработчики - в отделы разработки, тестировщики - в отдел тестирования, и т.д.), т.е. в проекте сотрудники из разных отделов.
Вы проверили этот подход на своей компании? Без описания личного опыта «плюсы сильно перевешивают минусы» не звучит достаточно веско.
Ну вы же понимаете, что проблемы растут совершенно из другого места?
Вот смотрите
Рост числа продуктов. Нужно нанимать либо новых людей, либо переводить команду на новый продукт, но при этом старый продукт никуда не девается. Влечет за собой рост числа разработчиков, рост затрат на разработку и поддержку.
Bus фактор - ушёл ключевой разработчик, какой-нибудь тимлид и продукт начинает рассыпаться под вопросами - почему реализовано так, а не иначе, почему работает именно так, а по другому не работает, что с чем связано и почему нельзя удалить этот "ненужный сервис". Зачастую это приводит к разработке продуктов с нуля и постепенному переносу части старой функциональности в "новый и красивый" продукт. Через время всё повторяется.
Устаревание кода - Вы выпустили продукт, он работает, а команда перешла на разработку второго, третьего продукта. И вдруг требуется внести правки в давно выпущенный продукт, а там Вы обнаруживаете устаревшие библиотеки, старую декомпозицию, забытые костыли т.д. Ещё хуже может быть когда продукт выпущенный 3 года назад вдруг ломается и никто не помнит что там и как. Я не говорю уже об угрозах безопасности и быстродействии.
Адовый Onboarding - разработчики приходят и уходят, а продукт остается. Теперь представьте себе ситуацию, когда надо ввести джуна, мидла или не дай бог сениора на большой проект, который разрабатывался 5 лет, имеет сотни апишек, десятки сущностей и миллионы разных нюансов. Это же касается и перехода разработчиков между продуктами.
Где документация? Проблема заключается в том, что когда вы погружены в продукт - многие вещи Вам кажутся естественными и даже если вы стараетесь вести документацию, зачастую она далеко не полная.
Одинаковые вещи в разных продуктах. Пилят по своему, со своими костылями, получается пустая трата человеко-часов, особенно когда на каком-нибудь демо 3 разные команды показывают как они запилили одни и те же вещи.
Рост числа продуктов влияет на количество людей, так как банально растет нагрузка. и с этим сделать НИЧЕГО нельзя. Просто тупо стало больше и все
Уход разработчика с компетенциями вы можете только появлением нового, так как банально команда потеряла бойца и надо количественно и качественно вернуть "как было раньше". Если же его компетенции были уникальными - это пробема шаринга компетенций (но на это также нужны ресурсы) либо доки, чтобы при необходимости ее быстро получить.
Устаревание кода - это просто данность. Какие-то версии библиотек устаревают, появляются новые версии API, ... это часть нагрузки по поддержке, которую вы либо делаете, либо нет. Но если нет - придет "незаметный" доселе песец в какой-то момент
Дока - ее просто надо писать
------------------
Решение есть, если вы унифицировали стек и процессы. Если стек продуктов разный - чуда нет, и либо разработчикам надо изучать разные вариации, либо вы просто делитесь по стеку в все. Вот просто все. Процессы не так критичны, но уменьшают время вливания.
Т.е. ключ к решению проблем в УНИФИКАЦИИ стека и стремлению к ней. Тогда вы можете делить команды как вам нравится. Если ее нет - нет возможности делить и все :)
Если у вас куча сортов "говна мамонтов. динозавров и неандертальцев" - опять же, чуда нет. Чтобы его сопровождать и иногда развивать, его надо "раздать" и поставить задачу овладеть знанием, документировать и т.д
------------------
Ваш подход по сути и есть этим подходом, но его "основа" - стек. По сути вы просто разделили команды по компетенциям и все. Но это обычно есть и так, как минимум в вашем случае. Редко бывают вменяемые full-stack, а еще если со знанием специфических решения типа big data / integration ... Тут скорее вопрос ... а что, неужели вы до того жили по другому?
Т.е. стек первичен, вторичен и вообще - определяющий все это деление :)
------------------
Если компнуть глубже, то все условно проще и лежит в банальной политической плоскости.
Там где ИТ работает ОК, бизнесу нормально работать с ИТ, как ген подрядчиком. И тогда работает ваш "изобретенный" подход. Просто никому не интересно, да и не получится дробить ИТ на удельные княжества.
Если же ИТ в таком виде себя дискредетирует внутри большой организации, выдает плохой продукт, с задержками, с дефицитом ресурсов, начинается естественная борьба за ресурсы, которая заканчивается обособлением команд, которые удалось "урвать" под себя. Остальные довольствуются остатками и т.п.
И дальше по циклу, от централизации до раздробленности :)
Рост числа продуктов влияет на количество людей, так как банально растет нагрузка. и с этим сделать НИЧЕГО нельзя. Просто тупо стало больше и все
Просто тупо - это ключевое
Я вижу фонтаны излияний, которые больше похожи на нытье человека, который не хочет менять привычный порядок вещей, который нагрел себе место и не хочет двигаться. Отсюда и заявления типа Устаревание кода - это просто данность, сразу четко виден подход х%як х%як, в продакшн и забыли.
Я вижу фонтаны излияний, которые больше похожи на нытье человека, который не хочет менять привычный порядок вещей, который нагрел себе место и не хочет что-то менять.
Да нет. Я просто имею некий опыт:
принимал активное участие в разных трансформациях в больших компаниях
создавал с нуля продуктовые команды
участовал в консалтингах на тему "как нам трансформироваться"
отвечал за портфель проектов по направлению
Понятно вы тоже не вчера родились и мы просто обмениваемся
По тому что вам бросилось в глаза
Устаревание кода - это просто данность
Ну да, а как. Выходят новые версии библиотек, API, фреймфорков ... да всего. И чем больше у вас систем, тем больше FTE надо. Простая математика, и все. Спасает унификация стека )о чем я и написал). А все эти деления без унификации не помогут, так как если у вас зависимость на 100 "библиотек" и 5 версий в год, то потенциально у вас 500 изменений. А если 10 библиотек - то 50. Вот и все
-------------------------
Кстати про библиотекти хотел написать, а тут вы тригернули
Это редко работает по куче причин.
Причина первая: команда внутреннего ИТ по качеству не сравнится з командой, которая двигает условный open source проект з 10к внедрений. Там и людей побольше, и компетенции получше, а главное - так 10к внедрений и тонны обратной связи. Поэтому когда я беру в проект такую библиотеку, я знаю что ее до меня протестило в боевых условиях 10к команд. А в случае локальной ее писал Вася, а проверил Петя. Как бы scale matters.
Причина вторая: сроки и ответственность
К примеру, я руководитель продуктовой команды. У меня есть бюджет (часто в миллионах), сроки и все остальное. В том числе бонусы, а также понимание что от этого зависит бизнес результат вертикали и бонусы ее руководителя. Т.е. как бы все серьезно. И да, у меня есть команда, ресурсы, средства мотивации ...
Есть два варианта. Сделать фичу своей командой либо отдать кому-то, в вашей орг. структуре другой команде. Первый способ в целом приемлим, если у меня есть на это ресурс, задача в плане не тормозит другие и т.д. Синица в руках, как говорится.
Второй способ порождает зависимость на Васю. И тут интереснее. А если косяк - мне надо еще и Васю пинать. А если Вася увволился? А если Вася поообещал, а потом к нему пришел руководитель другой команды, и Васю переключили на другую фичу. И я уже "как фанера над Парижем". А идем выше: бонусы, результаты ... С кем я пойду на ковер объяснять, что продукт не взлетел, потому что Вася либо его босс три-два-расы? Даже если я и возьму Вася для ритуального жертвоприношения ... спрос за итог с меня. И никому не интересно. Поэтому зачем мне непонятный "журавль в небе"?
Причина три: создавая библиотеки, вы создаете зависимости. Так технические, так и в планах проектов. И кто-то их должен разруливать. Если это делать самим ПМам/руководителям продуктовых команд - вы как ИТ создаете на ровном месте кучу гемороя. Типа пишите либы и переиспользуйте код, но как это все уложить в сроки, согласовать версии, поставки, тестовые среды - сами, все сами. Я думаю не взлетит. Либо ИТ выступает в роли разруливателя и планировщика.
--------------
У меня есть очень успешный опыт активного участия в роли архитектора/продвигателя интеграционной команды в большой организации. Но как оказалось, на долгой дистанции, команду нужно все время держать "в тонусе", а чуть что не так - и сразу куча проблем. Если делаеш интеграцию под ключ и сам сводишь сроки, ресурсы и т.д. - работает. Как только команда типа просто делает заказы - со временем подход стал давать сбои. И народ начинаает смотреть в сторону - давай интегранемся напрямую, на фиг на эти :)
Да нет. Я просто имею некий опыт
Не только Вы имеете опыт.
И чем больше у вас систем, тем больше FTE надо.
Дэк о чем и речь, если написали как есть, запустили и забыли так и будет. А если часть функционала пишется командой, которая на этом функционале специализируется, она оборачивает его в библиотеку и поддерживает. Вот с этим опыт предостаточно и работает оно отлично.
Это редко работает по куче причин
В компании 15+ продуктов, но все продукты базируются на неком бойлерплейте и имеют похожие функциональности. Оборачиваете бойлерплейт в библиотеку, оборачиваете общие функциональности в библиотеку, используете. Вышла обнова - обновили библиотеку, обновили сервисы. Никто не говорит свой nest.js с нуля написать. Микросервисы общие нельзя делать потому что вход выход несколько отличается, разные продукты и правообладатели, а вот использовать общую библиотеку в 2 сервисах совсем другое дело.
Есть два варианта
А есть вариант посадить аналитика, разбить проект на сущности и функциональности, посмотреть что уже реализовано и MVP составить из того что есть среди реализованных функциональностей (если требуется быстрый запуск, что происходит в 90% случаев, всякие гос контракты и т.п.). А потом параллельно допилить в разных командах части системы.
Сделать фичу своей командой
Если речь идёт исключительно о фиче внутри продукта - смотрите к чему фича относится функционально и в той команде её делают. Не понимаю какие проблемы у Вас с постановкой, но они явно есть, потому что не пообщеал, а вот задача в спринте и цель спринта, взял и сделал.
создавая библиотеки, вы создаете зависимости
Проекты в любом случае, если это не какие то велосипеды основаны на библиотеках, которые НАДО обновлять. И судя по всему Вы этого не делаете?
все время держать "в тонусе"
Ну так если 5 лет заниматься одним продуктом, о каком тонусе идёт речь? А вот если это разные продукты, но при этом ты делаешь что-то именно в своей компетенции, с тонусом проблем нет. К тому же можно перейти в другую команду с другими компетенциями и поднять тонус там.
Как только команда типа просто делает заказы
Смотря речь о ком, джуны мидлы 99% класть хотели на все нюансы продуктов, дайте четкую задачу, мы сделаем. А у сеньеров и лидов в развлечениях разные продукты, шлифование библиотек, брейнштормы как правильно сделать что-то чтобы можно было зашить в библиотеку и переиспользовать на других проектах
В компании 15+ продуктов, но все продукты базируются на неком бойлерплейте и имеют похожие функциональности.
Ну видите, мы пришли к единому мнению. Все пляшет от единого стека. Все остальное, как распределить разработчиков напоминает спор, как копать картошку, справа налево или слева направо :) Ну честно.
К примеру, в одной организации, большой, где я проработал лет 8 было 500+ официально зарегистрированных систем в поддержке. Ну как бы ... вы поняли.
Просто ... ну блин. Мы живете в мире близком к идеальному и рассказываете как его сделать лучше :) Это конечно круто, но мало полезно тем, кто к такому почти никогда не придет в силу размера :)
Уважаемый автор
Работал в трех больших компаниях. Устройство ИТ сильно отличается от приведенных Вами схем.
Большие компании (мы же обсуждаем компании со штатом развития ИТ в несколько тысяч сотрудников и более?) с разным бизнесом (а бизнес бывает не только продуктовым) по-разному структурируют и управляют своим ИТ. Было бы здорово четко описать границы применимости Вашей идеи.
В статье, к большому сожалению, не приведено ни одного измеримого показателя "лучше/хуже" при сравнении подходов, а так же статистики, показывающей, что описанные ограничения действительно являются ключевыми/критичными для бизнеса значимого количества ИТ компаний.
Как уже писали в других комментариях, было бы здорово почитать о результатах применения описанного подхода в Вашей компании
Устройство ИТ сильно отличается от приведенных Вами схем
Можно пример? Потому что Я вижу размышления только про продуктовый подход, который висит из всех щелей откуда хоть что-то можно услышать про менеджмент. Яндекс, майкрософт, гугл, всякие банки, операторы связи и т.д. (см. любую конференцию)
Большие компании
Тут скорее про количество продуктов или их величину
ни одного измеримого показателя "лучше/хуже" при сравнении подходов, а так же статистики
Потому что подход на стадии внедрения. Ну сразу могу сказать, на 8 продуктов вместо 8 команд продуктовых из разномастных спецов, нужно 6 функциональных команд с другим подходом. Плюс планируется ещё несколько продуктов, на которые не надо нанимать новую команду, а функционал поделить и реализовать имеющимися командами.
Сразу хочу принести свои извинения за сарказм в ответах. Не судите строго, постарайтесь найти рациональное зерно
Устройство ИТ сильно отличается от приведенных Вами схем
Можно пример?
Банк не производит ИТ-продукт, вернее не продает его на рынке, у него ИТ направлено на обеспечение финансовых услуг. Проектное управление ИТ-разработками, закупки ИТ-продуктов и найм интеграторов для адаптации/внедрения купленных продуктов/платофрм с последующим взращиванием собственной экспертизы, годовое бюджетирование итд. Внутри контура проектного управления резвитесь в Agile, но в срок заранее зафиксированный результат, за фикс денег при фикс ресурсах чтобы был. И каждый Project Manager за выданные проекту людские ресурсы стоит горой, каждый Product Manager стоит горой за людские ресурсы в его ИТ-системе, мнение пользователей не главный приоритет, главное нахватать больше функционала и расширить штат под собой. Строгое разделение команд разработки различных ИТ-систем, свой огородик с заборчиком трехметровой высоты, колючая проволока и мины для соседей.
Фирма-аутсорсер не производит ИТ-продукт, а продает услуги заказной разработки ПО. ИТ-продукта нет, а разработка есть. Милое дело жонглировать разработчиками между разными заказами для тушения пожаров и перепродажи одного разработчика в разные заказы одновременно. Совсем другой стиль управления.
Фирмы-аутстаферы вообще отдельная песня.
И все это непродуктовая разработка и не очень продуктовый подход.
Тут скорее про количество продуктов или их величину
На этом спринте команда напилит фичу в Oracle Siebel CRM, на следующем спринте их уже ждет PM, отвечающий за Oracle ERP, а самой продуктивной команде дадут покоммитить в ядро Oracle Database два спринта подряд. Вечером можно в Java virtual machine пару оптимизаций впилить. И ведь есть ИТ-продукты в полный рост и продуктовый подход к разработке есть.
А в Яндексе хоть каждый день меняй команды между поисковиком и такси.
Как говорится, one size fit them all. Везде библиотечный подход, типовые кубики.
Потому что подход на стадии внедрения.
Сначала проведем задуманные организационные изменения, потом договоримся о правилах оценки их результатов, а уж затем по факту посчитаем сколько на это ушло денег/времени и какая случилась выгода/экономия. Если в конце случится fail и ситуация станет хуже чем до, то строго посмотрим на того, кто придумал эти изменения и не будем слушать его идеи три месяца. Best practices менеджмента. Рекомендовано к использованию в крупных компаниях.
Банк не производит ИТ-продукт, вернее не продает его на рынке, у него ИТ направлено на обеспечение финансовых услуг
Каждый банковский продукт, особенно для бизнеса, это обычно отдельное IT решение, то есть с точки зрения разработчика - продукт, по крайней мере в тех банках, с которыми работал.
Далее Вы там накидали чего-то не понятно к чему относящемуся. PM должен стоять горой за свой продукт, а не за людские ресурсы. То о чем Вы говорите, это когда почему то PM занимается не своей работой. И главное чтобы продукт выполнял свои функции и работал, а не чтобы за продуктом было закреплено как можно больше народа, которому нужно платить зарплаты и которую нужно менеджерить.
Фирма-аутсорсер не производит ИТ-продукт
А результатом заказной разработки что является? И не надо никем жонглировать, каждый выполняет свои функциональные обязанности.
На этом спринте команда напилит фичу в Oracle Siebel CRM, на следующем ...
Ну так это о чем Я и говорил, что предлагал. Вместо того чтобы кто-то был завязан на CRM, кто-то на ERP, кто-то ещё на чем то. Сейчас во многих компаниях именно такая привязка к одному продукту.
А в Яндексе хоть каждый день меняй команды между поисковиком и такси.
Нет, вообще не так, там жесткая завязка под один продукт, у каждого продукта свой тулинг, свои либы, стандарты и т.д. Нельзя вот так взять и перейти из поиска в такси и даже из такси в доставку еды.
Как говорится, one size fit them all. Везде библиотечный подход, типовые кубики.
Вот как раз таки мало где. О чем и речь.
Рекомендовано к использованию в крупных компаниях.
Ну примерно так и делаем, но спасибо за совет.
Я Вам всячески намекаю, что описанное решение не универсально и имеет ограниченную область применения. Многие в комментариях пишут про эти ограничения.
Ограничения вызваны размером компании, особенностями бизнес модели, однородностью ИТ-ладншафта итд итп.
Предлагаю по части Банков остановить дискуссию. Слишком разный у нас опыт работы в этой части.
Про Oracle см Ваши выводы про Яндекс, ситуация один в один.
Фирма-аутсорсер не производит ИТ-продукт
А результатом заказной разработки что является?
Концепция проста и незатейлива - "запилил" ровно то и ровно так, как было в ТЗ и давай до свидания до следующего тендера на развитие ИТ-системы. И не факт, что следующий тендер выиграет этот же аутсорсер. Если вдруг аутсорсеру захочется начать продавать результат "запила" или целиком релиз ИТ-системы заказчика as is другим заказчикам, то набираем попкорн и смотрим битву юристов. Свои три рубля ставлю на на отдел договоров и юридическую службу крупного заказчика.
Какой тут ИТ-продукт у аутсорсера? Зачем аутсорсеру делать больше/лучше/по-другому чем в ТЗ. Стараемся любыми путями сдать работу вовремя и не пронести сроки. Режем косты (в том числе, жонглируя разработчиками, если есть угроза из-за проноса сроков влететь на штрафы).
При этом не надо путать аутсорсера с вендрором или системным интегратором.
Как говорится, one size fit them all. Везде библиотечный подход, типовые кубики.
Вот как раз таки мало где. О чем и речь.
Зачастую мало где, не потому что, там сидят недогадливые/ленивые менеджеры, а наоборот, догадливые менеджеры понимают, что для их случая подход работать не будет. Возвращаемся к ограничениям подхода.
Рекомендовано к использованию в крупных компаниях.
Ну примерно так и делаем, но спасибо за совет.
Хм. Тут же был сарказм во весь рост с моей стороны.
Так делать можно в маленькой и потому гибкой компании. После нескольких неудач подход начинает быстро эволюционировать. Об этом ниже.
В итоге советую хотя бы мысленно прикинуть, какие проблемы в вашей компании данный подход может решить
В крупных компаниях давно уже "прикидывают" гораздо более структурированно, чем "мысленно". Приблизительный алгоритм:
Идея. Идеолог бодро формулирует "плюсы представленного подхода сильно перевешивают его минусы (по моему мнению)"
Обоснование актуальности идеи для всей компании или четкое понимание в какой части компании идея может выстрелить. Поиск похожих кейсов в отрасли.
Формализация правил и сроков оценки эффекта от внедрения идеи
Предварительный расчет потенциальных затрат/прибыли/экономии/рисков с учетом, что изменения будут проведены не за день, а эффект может проявиться или быть измерен ощутимо позже окончания изменений
Составление детализированного календарного и ресурсного плана, списка контрольных точек, перечня рисков и методов управления рисками
Принятие решения делаем/не делаем. С зонами и размерами ответственности участников внедрения идеи
Выполнение изменений с оценкой прогресса в промежуточных контрольных точках
Финальная оценка эффекта
Подведение итогов. Иногда совмещенное с увольнениями особо отличившихся "героев-иделогов" и поверивших в них лиц, принимающих решения. Но это случается очень очень редко.
Вся эта тяжелая бюрократия ради того, что есть риск так навнедрять "универсальных" идей в широких масштабах крупной компании, что никакие фе-фе-фе, публичный позор, лишения идеологов премий/бонусов, а так же увольнения не компенсируют убытков.
Итог (на мой взгляд).
Автор молодец, что самостоятельно придумал и удачно внедрил идею (хотя она не совсем оригинальна) в своей фирме.
Что можно сделать лучше:
Явно выделить ключевые факторы успешности кейса. Почему получилось в этой фирме, какие именно условия должны быть выполнены, чтобы повторять успех устойчиво и независимо от личных качеств повторяющих в других фирмах.
Описать ограничения подхода. При каких условиях успеха не добиться. Частично в статье это уже сделано.
Я Вам всячески намекаю, что описанное решение не универсально и имеет ограниченную область применения
Первое предложение в этом материале: Сразу скажу, подход актуален для больших компаний с множеством продуктов и соответственно множеством команд, либо для компаний с большими и сложными продуктами.
Концепция проста и незатейлива - "запилил" ровно то и ровно так, как было в ТЗ и давай до свидания до следующего тендера на развитие ИТ-системы.
Если все так делают, не значит что Вы должны. По крайней мере Я делаю не так. Но вот кто так делает, это многое о них говорит, как о профессионалах и людях в целом.
Автор молодец, что самостоятельно придумал и удачно внедрил идею
Спасибо. Ещё не внедрил, в процессе. Я скорее не придумал, а просто формализовал то, что вижу вокруг и чего не вижу в трендах по менеджменту.
Что можно сделать лучше
Как будут итоги внедрения второй материал выйдет, со ссылкой на этот.
Первое предложение в этом материале
Ждем инфы о внедрении подхода из Яндекса и других Майкрософтов с Ораклами
Концепция проста и незатейлива - "запилил" ровно то и ровно так, как
было в ТЗ и давай до свидания до следующего тендера на развитие
ИТ-системы.Если все так делают, не значит что Вы должны. По крайней мере Я делаю не так.
Это раз https://www.tadviser.ru/index.php/Статья:ИТ-аутсорсинг_(мировой_рынок)
Цитата: Объем глобального рынка ИТ-аутсорсинга по итогам 2021 года достиг $360 млрд, увеличившись почти на 13% в сравнении с 2020-м. Такие данные в конце апреля 2022 года обнародовали аналитики Statista.
Это два: https://www.tadviser.ru/index.php/Статья:ИТ-аутсорсинг_(рынок_России)
Тройка аутсорсеров-лидеров по выручке в РФ за 2020
Ланит - 24,9 млрд рублей
Айтеко - 14,9 млрд рублей
Инфосистемы Джет - 14,8 млрд рублей
Но вот кто так делает, это многое о них говорит, как о профессионалах и людях в целом.
У вышеуказанных фирм дела на грани разорения?
А на мировом рынке тоже не знают, что аутсорсинг не торт и они не такие как надо профи?
Вопросы риторические.
Концепция маленьких продуктовых команд аля "гаражный кооператив", в принципе работает. Но качество по факту очень часто страдает, на уровне средней паршивости. Некогда потому что.
С таким подходом хорошо пилить типовые решения, если же в проекте много RnD, матричный подход начинает сбоить, т.к. члены функциональной команды не погружены в проект на 100%, у них много параллельных проектов, они теряют фокус.
много RnD
Можно пример? Потому что RnD может быть продуктовый, что обычно не нужно, это задача менеджмента и аналитиков понять боль бизнеса. А может быть RnD функциональный, который целиком уходит в какую то из команд, прорабатывается и возможно внедряется и на других продуктах.
они теряют фокус
Документация, спринты, цели спринтов помогают четко понимать что мы делаем и куда идём
Порекомендую книжку Team Topologies, где Conway's law разобран со всех сторон. Объясняет высокую эффективность автономных команд в микросервисной культуре компании.
А для PM и аналитиков разве не существует bus factor?
Задача ПМ-а и аналитика разобраться в продукте с точки зрения бизнеса и все знания задокументировать. То есть бизнес процессы и сущности будут задокументированы и понятны всем кому нужно, а разрабам это и вовсе не нужно, особенно джунам и мидлам, которые в основном чисто механическую работу делают.
Ну и тут писал
Bus фактор не такой болезненный
Полностью он конечно же не уйдет. Тут вопрос выгоды, что проще - найти пм-а или сеньера?
К минусам этой структуры обязательно надо добавить нагрузку на исполнителей работ. У них и так будет "каша" с задачами из разных продуктов так еще и два руководителя. Создаваемые "team" должны иметь руководителей или как минимум координатора команды, это еще плюс компетентный человек в нынешнем кризисе кадров.
При уходе тимлида одной команды появляется риск того что пострадают все продукты организации. В данной схеме все три продукта если, допустим "team 2" начнет плохо работать как команда.
Это по моему является наиболее сложной проблемой нежели документация.
Каша с задачами решается четкими целями в спринте. У каждой функциональной команды свой руководитель. А ПМ-у да, нужно будет с них спрашивать. Плюс команды работают уже по проработанной аналитиками бизнес логике. На низовом уровне ничего не изменится.
При уходе тимлида одной команды появляется риск того что пострадают все продукты организации
Не соглашусь. Это так, когда тим лид отвечает за продукт. А когда тим лид отвечает за функциональную область, он прорабатывает эту область со всей командой и вся команда примерно всё знает, потому что ей не нужно распыляться на знание всего продукта
Если бы мне сказали, что теперь я не решаю задачи, а делаю только одну часть:
"- команда обработки данных (пилят апишки для взаимодействия с данными)"
я бы очень скоро сошел сума от такой рутинной работы, так что не уверен, что это хороший подход на перспективу.
Что лучше? - "ты отвечаешь за интеграции" или "вот тебе 8 продуктов, одни написаны 5 лет назад, другие вот в процессе написания, изучай потому что написаны с разными подходами и вот тебе пачка задач во всех продуктах по чуть чуть в разных частях и ты не должен ничего сломать." Учитывая что у тебя большая часть команды мидлы, периодически приходят джуна, а сеньеров штук 5 и они заняты другими продуктами
У вас пример как в мемчике "Ты хочешь, чтобы тебе оторвали голову или на дачу?"
- на дачу.
Давайте более реально. Вот тебе или 2-3 олдскульных проекта вести или писать чисто интеграции.
Конечно же, вести продукт целиком. Когда вы сужаете труд человека до узкой задачи, это превращается в рутину, а с рутиной прогер максимально быстро выгорает, падают все показатели и в целом бизнесу это не выгодно.
Давайте более реально
Более чем реально. Вести продукт или писать интеграции? О какой позиции речь? Тимлид или сеньер Я полагаю? Так они сами не пишут, они рулят кучей интеграций, решают какие то архитектурные вопросы, как это всё упаковать, универсиализировать и т.д. Если на таком примере - поддерживать 2 старых продукта или заниматься продумывать интеграцию с разными сервисами. По мне так второе звучит интереснее.
Декомпозиция отдела разработки