Комментарии 10
А на картинке то таймЛид не врет - если будут плохо грести и лодка потонет, то он, возможно и выплывет, а гребцы точно нет...
А галеры часто вели бой с помощью пушек, а потому скорость и маневренность для них не были столь критичны.
PS Источник этих сведений, правда, особым авторитетом не отличался: это была статья в журнале про компьютерные игры (впрочем — в весьма толковом журнале, ныне, увы — помершем). Так что прошу эти сведения рассматривать не более, чем как информацию для размышления, требующую, вообще-то, независимой проверки. Но в контексте этой самой картинки, думаю, эта информация небезынтересна.
Интересно, но без примера непонятно.) Можно пример хотя бы абстрактного проекта на LTS?
Пока все очень туманно и неясно откуда деньги в таких командах, кто ставит задачи, как находятся желающие их решать и самое главное, какой срок жизни у предполагаемого проекта. Пока больше похоже на «рандомно наговнокодили и разбежались») не в обиду всей статье, конечно.
Если разрабатывается какая-то инфраструктура, а не customer-facing часть продукта, то инженеры зачастую лучше знают, что надо делать, и где болит.
Как результат, инженеры в команде раз в Х времени собираются, брейнштормят идеи, голосуют за приоритеты и значимость этих идей.
На основании этого, каждый инженер решает над чем ему интересно будет работать в следующйи большой кусок времени (например, полугодие).
Менеджер в этой ситуации помогает найти партнеров в других командах, которые могут как-то выиграть от вашего проекта. так же менеджер могжет помочь в корректировке приоритетности проектов, потому что у менеджера больше контекста о том, чем занимаются и другие соседние команды, и какие-то ваши проекты могут решить больше не только внутри команды, но и у соседних команд.
Кмк, это может хорошо работать в больших компаниях, где есть много команд, и развесистая инфраструктура, которые поддерживают и развивают сотни людей.
О, спасибо! Сразу понятнее.
Да, пожалуй, если это, например, команда разработки фреймворка или БД, то инженеры могут нагенерить толковых задач.
На продуктовые команды, получается, LTS не очень ложится? С трудом представляю как инженеры изучают рынки, предлагают фичи с предсказуемым и измеримым результатом, работают с маркетингом для освещения релиза и пр.
Мне кажется, что в продуктовых командах инженеры могут сами придумывать и решать технические задачи по улучшению перформанса. В случае же, новых фичей, бизнес может дать направление куда копать на следующие полгода, в дальше уже инженеры решат как копать. У меня по подобной схеме работы есть опыт только в разработке инфраструктуры, так что могу только теоретизировать про продукт.
Эта концепция (LST) как и вся статья в целом больше похожа на желаемое виденье устройства владельцами стартап-проектов.
Особенно насмешило "цикл развития разработчика (от джуна к миддлу или от миддла к синьору) сократился до 1-3 лет". А потом мы видим сеньоров с опытом 2 года, которые иногда даже не знают, что такое git. Выдача желаемого за действительное. В действительности же от разработчиков требуется наличие все большего количества знаний. Например, если раньше (лет 10 назад) сеньору-разработчику было достаточно знаний реляционных СУБД с практическим опытом в 1-2 реализациях. То сегодня - это знания джуна, а сеньор уже должен иметь знания в 2-3 типах СУБД и практический опыт в нескольких реализациях каждого типа. А знания всяких распределенных кластерных систем (типа Hadoop), всякие middleware-системы и прочее и прочее...
Ну в целом стоит отметить, что примерно таким подходом работает Valve вот уже третий десяток лет. Соответственно за это время проявились и преимущества и недостатки этого подхода...
если ответственность разделена между всеми - это значит что никто ответственности не несёт, либо это круговая порука.
Могут ли IT-команды существовать без лидера: концепция Liquid Super Teams