Сразу скажу, подход актуален для больших компаний с множеством продуктов и соответственно множеством команд, либо для компаний с большими и сложными продуктами.
Как обычно устроен департамент разработки
Всё казалось бы хорошо и это вполне жизнеспособная модель, до того момента, пока не начинаются следующие проблемы:
Рост числа продуктов. Нужно нанимать либо новых людей, либо переводить команду на новый продукт, но при этом старый продукт никуда не девается. Влечет за собой рост числа разработчиков, рост затрат на разработку и поддержку.
Bus фактор - ушёл ключевой разработчик, какой-нибудь тимлид и продукт начинает рассыпаться под вопросами - почему реализовано так, а не иначе, почему работает именно так, а по другому не работает, что с чем связано и почему нельзя удалить этот "ненужный сервис". Зачастую это приводит к разработке продуктов с нуля и постепенному переносу части старой функциональности в "новый и красивый" продукт. Через время всё повторяется.
Устаревание кода - Вы выпустили продукт, он работает, а команда перешла на разработку второго, третьего продукта. И вдруг требуется внести правки в давно выпущенный продукт, а там Вы обнаруживаете устаревшие библиотеки, старую декомпозицию, забытые костыли т.д. Ещё хуже может быть когда продукт выпущенный 3 года назад вдруг ломается и никто не помнит что там и как. Я не говорю уже об угрозах безопасности и быстродействии.
Адовый Onboarding - разработчики приходят и уходят, а продукт остается. Теперь представьте себе ситуацию, когда надо ввести джуна, мидла или не дай бог сениора на большой проект, который разрабатывался 5 лет, имеет сотни апишек, десятки сущностей и миллионы разных нюансов. Это же касается и перехода разработчиков между продуктами.
Где документация? Проблема заключается в том, что когда вы погружены в продукт - многие вещи Вам кажутся естественными и даже если вы стараетесь вести документацию, зачастую она далеко не полная.
Одинаковые вещи в разных продуктах. Пилят по своему, со своими костылями, получается пустая трата человеко-часов, особенно когда на каком-нибудь демо 3 разные команды показывают как они запилили одни и те же вещи.
Есть ещё много связанных проблем, Я лишь обозначил самые явные.
Как же быть?
Я предлагаю следующий подход:
Функциональные команды вместо продуктовых
Чтобы не дублировать компетенции в разных продуктах, не дублировать одинаковые сервисы, получить некую унификацию технологий Я предлагаю сосредоточиться на функциональных командах разработки, вместо продуктовых. Например сейчас у нас в компании Я выделяю 6 функциональных команд:
команда по приему и хранению данных (самый highload проекта)
команда обработки данных (пилят апишки для взаимодействия с данными)
команда интеграций (с оборудованием, другими сервисами и контрагентами)
интерфейсная команда (наш фронтенд)
команда тестирования
команда DevOps (CI/CD и поддержка)
Какие плюсы?
Библиотечный подход. Так как команды сосредоточены на своей функциональной области, они могут выработать общие паттерны работы, лучшие практики и заложить их в функциональные библиотеки, которые будут переиспользоваться между продуктами. Библиотеки будут покрыты тестами и задокументированы, потому что им не надо распыляться на весь продукт, они сосредоточены на своей компетенции.
Ускорение разработки новых продуктов. За счет того, что каждый продукт это набор функциональных модулей, продукты можно собирать как кубики lego уже из имеющихся библиотек. Нужно будет лишь немного подпилить напильником под нужные требования.
Отпадает необходимость в раздувании штата разработчиков.
Упрощение поддержки. Так как вы пользуетесь одним и тем же набором инструментов из раза в раз, отследить баг в любом из продуктов гораздо проще и быстрее.
Bus фактор не такой болезненный, т.к. от конкретного разработчика теперь не так сильно всё зависит.
Опять таки это не все плюсы, Я выделил самые явные.
Как оно должно работать
За каждым продуктом также остаются аналитики и ПМ-ы.
Аналитики составляют бизнес требования выделяют сущности и расписывают их взаимодействия, составляя тем самым первый уровень документации.
Затем, с тимлидами команд, бизнес требования и сущности разносятся по функциональным областям.
Далее пишется более техническая документация как и что должно работать, с какими библиотеками и сервисами.
По документации выставляются задачи, которые уже берут разработчики.
ПМ-ы курируют задачи по своему продукту и контролируют сборку продукта воедино согласно документации.
Тестеры покрывают продукт E2E тестами.
При появлении новых требований, шаги со 2 по 7 повторяются.
Естественность процесса
Те, кто работал в компаниях над разными продуктами думаю замечали, что функциональные компетенции складываются естественным образом даже внутри продуктовых команд, ведь кто-то хорошо может написать сложные взаимодействия и апи-шки, а кто-то упарывается по highload. Проблема в том что эти компетенции заперты внутри продукта, они не развиваются и не делятся опытом с другими разработчиками, запертыми на других продуктах.
К тому же на разработчиках зачем то висит бремя знаний о всей работе и нюансах продукта, они становятся точкой истины. Хотя у продукта есть аналитки и ПМ-ы, которые должны разбираться в своём продукте лучше всех.
Есть ли минусы?
Конечно, минусы есть в любом подходе, иначе бы подход без минусов применялся везде.
Например тут уже не будет возможности не документировать продукт, потому что нет документации - нет продукта, а это временное снижение скорости, пока к подходу не привыкнут. Также возрастёт важность ПМ-ов, по контролю хода разработки.
Думаю при ознакомлении с материалом у Вас сразу возникли возможные проблемы в голове, так что не вижу смысла их описывать.
Однако плюсы представленного подхода сильно перевешивают его минусы (для меня), поэтому и был написан данный материал.
В итоге
В итоге советую хотя бы мысленно прикинуть, какие проблемы в вашей компании данный подход может решить и стоит ли это тех минусов, которые он породит.
Спасибо за внимание
Комментарии (25)
Batalmv
14.11.2023 13:57+4Ну вы же понимаете, что проблемы растут совершенно из другого места?
Вот смотрите
Рост числа продуктов. Нужно нанимать либо новых людей, либо переводить команду на новый продукт, но при этом старый продукт никуда не девается. Влечет за собой рост числа разработчиков, рост затрат на разработку и поддержку.
Bus фактор - ушёл ключевой разработчик, какой-нибудь тимлид и продукт начинает рассыпаться под вопросами - почему реализовано так, а не иначе, почему работает именно так, а по другому не работает, что с чем связано и почему нельзя удалить этот "ненужный сервис". Зачастую это приводит к разработке продуктов с нуля и постепенному переносу части старой функциональности в "новый и красивый" продукт. Через время всё повторяется.
Устаревание кода - Вы выпустили продукт, он работает, а команда перешла на разработку второго, третьего продукта. И вдруг требуется внести правки в давно выпущенный продукт, а там Вы обнаруживаете устаревшие библиотеки, старую декомпозицию, забытые костыли т.д. Ещё хуже может быть когда продукт выпущенный 3 года назад вдруг ломается и никто не помнит что там и как. Я не говорю уже об угрозах безопасности и быстродействии.
Адовый Onboarding - разработчики приходят и уходят, а продукт остается. Теперь представьте себе ситуацию, когда надо ввести джуна, мидла или не дай бог сениора на большой проект, который разрабатывался 5 лет, имеет сотни апишек, десятки сущностей и миллионы разных нюансов. Это же касается и перехода разработчиков между продуктами.
Где документация? Проблема заключается в том, что когда вы погружены в продукт - многие вещи Вам кажутся естественными и даже если вы стараетесь вести документацию, зачастую она далеко не полная.
Одинаковые вещи в разных продуктах. Пилят по своему, со своими костылями, получается пустая трата человеко-часов, особенно когда на каком-нибудь демо 3 разные команды показывают как они запилили одни и те же вещи.
Рост числа продуктов влияет на количество людей, так как банально растет нагрузка. и с этим сделать НИЧЕГО нельзя. Просто тупо стало больше и все
Уход разработчика с компетенциями вы можете только появлением нового, так как банально команда потеряла бойца и надо количественно и качественно вернуть "как было раньше". Если же его компетенции были уникальными - это пробема шаринга компетенций (но на это также нужны ресурсы) либо доки, чтобы при необходимости ее быстро получить.
Устаревание кода - это просто данность. Какие-то версии библиотек устаревают, появляются новые версии API, ... это часть нагрузки по поддержке, которую вы либо делаете, либо нет. Но если нет - придет "незаметный" доселе песец в какой-то момент
Дока - ее просто надо писать
------------------
Решение есть, если вы унифицировали стек и процессы. Если стек продуктов разный - чуда нет, и либо разработчикам надо изучать разные вариации, либо вы просто делитесь по стеку в все. Вот просто все. Процессы не так критичны, но уменьшают время вливания.
Т.е. ключ к решению проблем в УНИФИКАЦИИ стека и стремлению к ней. Тогда вы можете делить команды как вам нравится. Если ее нет - нет возможности делить и все :)
Если у вас куча сортов "говна мамонтов. динозавров и неандертальцев" - опять же, чуда нет. Чтобы его сопровождать и иногда развивать, его надо "раздать" и поставить задачу овладеть знанием, документировать и т.д
------------------
Ваш подход по сути и есть этим подходом, но его "основа" - стек. По сути вы просто разделили команды по компетенциям и все. Но это обычно есть и так, как минимум в вашем случае. Редко бывают вменяемые full-stack, а еще если со знанием специфических решения типа big data / integration ... Тут скорее вопрос ... а что, неужели вы до того жили по другому?
Т.е. стек первичен, вторичен и вообще - определяющий все это деление :)
------------------
Если компнуть глубже, то все условно проще и лежит в банальной политической плоскости.
Там где ИТ работает ОК, бизнесу нормально работать с ИТ, как ген подрядчиком. И тогда работает ваш "изобретенный" подход. Просто никому не интересно, да и не получится дробить ИТ на удельные княжества.
Если же ИТ в таком виде себя дискредетирует внутри большой организации, выдает плохой продукт, с задержками, с дефицитом ресурсов, начинается естественная борьба за ресурсы, которая заканчивается обособлением команд, которые удалось "урвать" под себя. Остальные довольствуются остатками и т.п.
И дальше по циклу, от централизации до раздробленности :)
kolkoni Автор
14.11.2023 13:57-2Рост числа продуктов влияет на количество людей, так как банально растет нагрузка. и с этим сделать НИЧЕГО нельзя. Просто тупо стало больше и все
Просто тупо - это ключевое
Я вижу фонтаны излияний, которые больше похожи на нытье человека, который не хочет менять привычный порядок вещей, который нагрел себе место и не хочет двигаться. Отсюда и заявления типа Устаревание кода - это просто данность, сразу четко виден подход х%як х%як, в продакшн и забыли.
Batalmv
14.11.2023 13:57+3Я вижу фонтаны излияний, которые больше похожи на нытье человека, который не хочет менять привычный порядок вещей, который нагрел себе место и не хочет что-то менять.
Да нет. Я просто имею некий опыт:
принимал активное участие в разных трансформациях в больших компаниях
создавал с нуля продуктовые команды
участовал в консалтингах на тему "как нам трансформироваться"
отвечал за портфель проектов по направлению
Понятно вы тоже не вчера родились и мы просто обмениваемся
По тому что вам бросилось в глаза
Устаревание кода - это просто данность
Ну да, а как. Выходят новые версии библиотек, API, фреймфорков ... да всего. И чем больше у вас систем, тем больше FTE надо. Простая математика, и все. Спасает унификация стека )о чем я и написал). А все эти деления без унификации не помогут, так как если у вас зависимость на 100 "библиотек" и 5 версий в год, то потенциально у вас 500 изменений. А если 10 библиотек - то 50. Вот и все
-------------------------
Кстати про библиотекти хотел написать, а тут вы тригернули
Это редко работает по куче причин.
Причина первая: команда внутреннего ИТ по качеству не сравнится з командой, которая двигает условный open source проект з 10к внедрений. Там и людей побольше, и компетенции получше, а главное - так 10к внедрений и тонны обратной связи. Поэтому когда я беру в проект такую библиотеку, я знаю что ее до меня протестило в боевых условиях 10к команд. А в случае локальной ее писал Вася, а проверил Петя. Как бы scale matters.
Причина вторая: сроки и ответственность
К примеру, я руководитель продуктовой команды. У меня есть бюджет (часто в миллионах), сроки и все остальное. В том числе бонусы, а также понимание что от этого зависит бизнес результат вертикали и бонусы ее руководителя. Т.е. как бы все серьезно. И да, у меня есть команда, ресурсы, средства мотивации ...
Есть два варианта. Сделать фичу своей командой либо отдать кому-то, в вашей орг. структуре другой команде. Первый способ в целом приемлим, если у меня есть на это ресурс, задача в плане не тормозит другие и т.д. Синица в руках, как говорится.
Второй способ порождает зависимость на Васю. И тут интереснее. А если косяк - мне надо еще и Васю пинать. А если Вася увволился? А если Вася поообещал, а потом к нему пришел руководитель другой команды, и Васю переключили на другую фичу. И я уже "как фанера над Парижем". А идем выше: бонусы, результаты ... С кем я пойду на ковер объяснять, что продукт не взлетел, потому что Вася либо его босс три-два-расы? Даже если я и возьму Вася для ритуального жертвоприношения ... спрос за итог с меня. И никому не интересно. Поэтому зачем мне непонятный "журавль в небе"?
Причина три: создавая библиотеки, вы создаете зависимости. Так технические, так и в планах проектов. И кто-то их должен разруливать. Если это делать самим ПМам/руководителям продуктовых команд - вы как ИТ создаете на ровном месте кучу гемороя. Типа пишите либы и переиспользуйте код, но как это все уложить в сроки, согласовать версии, поставки, тестовые среды - сами, все сами. Я думаю не взлетит. Либо ИТ выступает в роли разруливателя и планировщика.
--------------
У меня есть очень успешный опыт активного участия в роли архитектора/продвигателя интеграционной команды в большой организации. Но как оказалось, на долгой дистанции, команду нужно все время держать "в тонусе", а чуть что не так - и сразу куча проблем. Если делаеш интеграцию под ключ и сам сводишь сроки, ресурсы и т.д. - работает. Как только команда типа просто делает заказы - со временем подход стал давать сбои. И народ начинаает смотреть в сторону - давай интегранемся напрямую, на фиг на эти :)
kolkoni Автор
14.11.2023 13:57Да нет. Я просто имею некий опыт
Не только Вы имеете опыт.
И чем больше у вас систем, тем больше FTE надо.
Дэк о чем и речь, если написали как есть, запустили и забыли так и будет. А если часть функционала пишется командой, которая на этом функционале специализируется, она оборачивает его в библиотеку и поддерживает. Вот с этим опыт предостаточно и работает оно отлично.
Это редко работает по куче причин
В компании 15+ продуктов, но все продукты базируются на неком бойлерплейте и имеют похожие функциональности. Оборачиваете бойлерплейт в библиотеку, оборачиваете общие функциональности в библиотеку, используете. Вышла обнова - обновили библиотеку, обновили сервисы. Никто не говорит свой nest.js с нуля написать. Микросервисы общие нельзя делать потому что вход выход несколько отличается, разные продукты и правообладатели, а вот использовать общую библиотеку в 2 сервисах совсем другое дело.
Есть два варианта
А есть вариант посадить аналитика, разбить проект на сущности и функциональности, посмотреть что уже реализовано и MVP составить из того что есть среди реализованных функциональностей (если требуется быстрый запуск, что происходит в 90% случаев, всякие гос контракты и т.п.). А потом параллельно допилить в разных командах части системы.
Сделать фичу своей командой
Если речь идёт исключительно о фиче внутри продукта - смотрите к чему фича относится функционально и в той команде её делают. Не понимаю какие проблемы у Вас с постановкой, но они явно есть, потому что не пообщеал, а вот задача в спринте и цель спринта, взял и сделал.
создавая библиотеки, вы создаете зависимости
Проекты в любом случае, если это не какие то велосипеды основаны на библиотеках, которые НАДО обновлять. И судя по всему Вы этого не делаете?
все время держать "в тонусе"
Ну так если 5 лет заниматься одним продуктом, о каком тонусе идёт речь? А вот если это разные продукты, но при этом ты делаешь что-то именно в своей компетенции, с тонусом проблем нет. К тому же можно перейти в другую команду с другими компетенциями и поднять тонус там.
Как только команда типа просто делает заказы
Смотря речь о ком, джуны мидлы 99% класть хотели на все нюансы продуктов, дайте четкую задачу, мы сделаем. А у сеньеров и лидов в развлечениях разные продукты, шлифование библиотек, брейнштормы как правильно сделать что-то чтобы можно было зашить в библиотеку и переиспользовать на других проектах
Batalmv
14.11.2023 13:57+2В компании 15+ продуктов, но все продукты базируются на неком бойлерплейте и имеют похожие функциональности.
Ну видите, мы пришли к единому мнению. Все пляшет от единого стека. Все остальное, как распределить разработчиков напоминает спор, как копать картошку, справа налево или слева направо :) Ну честно.
К примеру, в одной организации, большой, где я проработал лет 8 было 500+ официально зарегистрированных систем в поддержке. Ну как бы ... вы поняли.
Просто ... ну блин. Мы живете в мире близком к идеальному и рассказываете как его сделать лучше :) Это конечно круто, но мало полезно тем, кто к такому почти никогда не придет в силу размера :)
mikeGolovanov
14.11.2023 13:57+5Уважаемый автор
Работал в трех больших компаниях. Устройство ИТ сильно отличается от приведенных Вами схем.
Большие компании (мы же обсуждаем компании со штатом развития ИТ в несколько тысяч сотрудников и более?) с разным бизнесом (а бизнес бывает не только продуктовым) по-разному структурируют и управляют своим ИТ. Было бы здорово четко описать границы применимости Вашей идеи.
В статье, к большому сожалению, не приведено ни одного измеримого показателя "лучше/хуже" при сравнении подходов, а так же статистики, показывающей, что описанные ограничения действительно являются ключевыми/критичными для бизнеса значимого количества ИТ компаний.
Как уже писали в других комментариях, было бы здорово почитать о результатах применения описанного подхода в Вашей компании
kolkoni Автор
14.11.2023 13:57Устройство ИТ сильно отличается от приведенных Вами схем
Можно пример? Потому что Я вижу размышления только про продуктовый подход, который висит из всех щелей откуда хоть что-то можно услышать про менеджмент. Яндекс, майкрософт, гугл, всякие банки, операторы связи и т.д. (см. любую конференцию)
Большие компании
Тут скорее про количество продуктов или их величину
ни одного измеримого показателя "лучше/хуже" при сравнении подходов, а так же статистики
Потому что подход на стадии внедрения. Ну сразу могу сказать, на 8 продуктов вместо 8 команд продуктовых из разномастных спецов, нужно 6 функциональных команд с другим подходом. Плюс планируется ещё несколько продуктов, на которые не надо нанимать новую команду, а функционал поделить и реализовать имеющимися командами.
mikeGolovanov
14.11.2023 13:57+1Сразу хочу принести свои извинения за сарказм в ответах. Не судите строго, постарайтесь найти рациональное зерно
Устройство ИТ сильно отличается от приведенных Вами схем
Можно пример?
Банк не производит ИТ-продукт, вернее не продает его на рынке, у него ИТ направлено на обеспечение финансовых услуг. Проектное управление ИТ-разработками, закупки ИТ-продуктов и найм интеграторов для адаптации/внедрения купленных продуктов/платофрм с последующим взращиванием собственной экспертизы, годовое бюджетирование итд. Внутри контура проектного управления резвитесь в Agile, но в срок заранее зафиксированный результат, за фикс денег при фикс ресурсах чтобы был. И каждый Project Manager за выданные проекту людские ресурсы стоит горой, каждый Product Manager стоит горой за людские ресурсы в его ИТ-системе, мнение пользователей не главный приоритет, главное нахватать больше функционала и расширить штат под собой. Строгое разделение команд разработки различных ИТ-систем, свой огородик с заборчиком трехметровой высоты, колючая проволока и мины для соседей.
Фирма-аутсорсер не производит ИТ-продукт, а продает услуги заказной разработки ПО. ИТ-продукта нет, а разработка есть. Милое дело жонглировать разработчиками между разными заказами для тушения пожаров и перепродажи одного разработчика в разные заказы одновременно. Совсем другой стиль управления.
Фирмы-аутстаферы вообще отдельная песня.
И все это непродуктовая разработка и не очень продуктовый подход.
Тут скорее про количество продуктов или их величину
На этом спринте команда напилит фичу в Oracle Siebel CRM, на следующем спринте их уже ждет PM, отвечающий за Oracle ERP, а самой продуктивной команде дадут покоммитить в ядро Oracle Database два спринта подряд. Вечером можно в Java virtual machine пару оптимизаций впилить. И ведь есть ИТ-продукты в полный рост и продуктовый подход к разработке есть.
А в Яндексе хоть каждый день меняй команды между поисковиком и такси.
Как говорится, one size fit them all. Везде библиотечный подход, типовые кубики.
Потому что подход на стадии внедрения.
Сначала проведем задуманные организационные изменения, потом договоримся о правилах оценки их результатов, а уж затем по факту посчитаем сколько на это ушло денег/времени и какая случилась выгода/экономия. Если в конце случится fail и ситуация станет хуже чем до, то строго посмотрим на того, кто придумал эти изменения и не будем слушать его идеи три месяца. Best practices менеджмента. Рекомендовано к использованию в крупных компаниях.
hVostt
14.11.2023 13:57Концепция маленьких продуктовых команд аля "гаражный кооператив", в принципе работает. Но качество по факту очень часто страдает, на уровне средней паршивости. Некогда потому что.
ncix
14.11.2023 13:57+4С таким подходом хорошо пилить типовые решения, если же в проекте много RnD, матричный подход начинает сбоить, т.к. члены функциональной команды не погружены в проект на 100%, у них много параллельных проектов, они теряют фокус.
kolkoni Автор
14.11.2023 13:57много RnD
Можно пример? Потому что RnD может быть продуктовый, что обычно не нужно, это задача менеджмента и аналитиков понять боль бизнеса. А может быть RnD функциональный, который целиком уходит в какую то из команд, прорабатывается и возможно внедряется и на других продуктах.
они теряют фокус
Документация, спринты, цели спринтов помогают четко понимать что мы делаем и куда идём
olku
14.11.2023 13:57+2Порекомендую книжку Team Topologies, где Conway's law разобран со всех сторон. Объясняет высокую эффективность автономных команд в микросервисной культуре компании.
onets
14.11.2023 13:57А для PM и аналитиков разве не существует bus factor?
kolkoni Автор
14.11.2023 13:57Задача ПМ-а и аналитика разобраться в продукте с точки зрения бизнеса и все знания задокументировать. То есть бизнес процессы и сущности будут задокументированы и понятны всем кому нужно, а разрабам это и вовсе не нужно, особенно джунам и мидлам, которые в основном чисто механическую работу делают.
Ну и тут писал
Bus фактор не такой болезненный
Полностью он конечно же не уйдет. Тут вопрос выгоды, что проще - найти пм-а или сеньера?
Kharl27
14.11.2023 13:57К минусам этой структуры обязательно надо добавить нагрузку на исполнителей работ. У них и так будет "каша" с задачами из разных продуктов так еще и два руководителя. Создаваемые "team" должны иметь руководителей или как минимум координатора команды, это еще плюс компетентный человек в нынешнем кризисе кадров.
При уходе тимлида одной команды появляется риск того что пострадают все продукты организации. В данной схеме все три продукта если, допустим "team 2" начнет плохо работать как команда.
Это по моему является наиболее сложной проблемой нежели документация.kolkoni Автор
14.11.2023 13:57Каша с задачами решается четкими целями в спринте. У каждой функциональной команды свой руководитель. А ПМ-у да, нужно будет с них спрашивать. Плюс команды работают уже по проработанной аналитиками бизнес логике. На низовом уровне ничего не изменится.
При уходе тимлида одной команды появляется риск того что пострадают все продукты организации
Не соглашусь. Это так, когда тим лид отвечает за продукт. А когда тим лид отвечает за функциональную область, он прорабатывает эту область со всей командой и вся команда примерно всё знает, потому что ей не нужно распыляться на знание всего продукта
mikeinside
14.11.2023 13:57Если бы мне сказали, что теперь я не решаю задачи, а делаю только одну часть:
"- команда обработки данных (пилят апишки для взаимодействия с данными)"
я бы очень скоро сошел сума от такой рутинной работы, так что не уверен, что это хороший подход на перспективу.kolkoni Автор
14.11.2023 13:57Что лучше? - "ты отвечаешь за интеграции" или "вот тебе 8 продуктов, одни написаны 5 лет назад, другие вот в процессе написания, изучай потому что написаны с разными подходами и вот тебе пачка задач во всех продуктах по чуть чуть в разных частях и ты не должен ничего сломать." Учитывая что у тебя большая часть команды мидлы, периодически приходят джуна, а сеньеров штук 5 и они заняты другими продуктами
mikeinside
14.11.2023 13:57У вас пример как в мемчике "Ты хочешь, чтобы тебе оторвали голову или на дачу?"
- на дачу.
Давайте более реально. Вот тебе или 2-3 олдскульных проекта вести или писать чисто интеграции.
Конечно же, вести продукт целиком. Когда вы сужаете труд человека до узкой задачи, это превращается в рутину, а с рутиной прогер максимально быстро выгорает, падают все показатели и в целом бизнесу это не выгодно.kolkoni Автор
14.11.2023 13:57Давайте более реально
Более чем реально. Вести продукт или писать интеграции? О какой позиции речь? Тимлид или сеньер Я полагаю? Так они сами не пишут, они рулят кучей интеграций, решают какие то архитектурные вопросы, как это всё упаковать, универсиализировать и т.д. Если на таком примере - поддерживать 2 старых продукта или заниматься продумывать интеграцию с разными сервисами. По мне так второе звучит интереснее.
sshmakov
Вы изобрели т.н. "сильную матрицу"
kolkoni Автор
То что читал про сильную матрицу немного про другое, может скинете что где прочитать, чтобы сказать да, это просто аналогия сильной матрицы?
sshmakov
Какой-то авторитетный пруф я вам не найду, помимо того, что вы сами можете нагуглить (раз, два). Тем более, что принцип сильной матричной структуры простой - двойственность управления, функциональное и проектное, сотрудники объединены в отделы по функциональности (разработчики - в отделы разработки, тестировщики - в отдел тестирования, и т.д.), т.е. в проекте сотрудники из разных отделов.