Устраиваясь на работу в корпорацию или стартап, разработчики часто вливаются в одну и ту же иерархию команды: во главе стоит тимлид, за ним — синьоры, потом — мидлы и так далее. И кажется, к формату top-down все привыкли. Но значит ли, что он не требует изменений? В этой статье рассмотрим альтернативу такому подходу.
Как показывают тренды последних лет, рабочие паттерны сотрудников в IT сделали крутой поворот. Прежде всего, цикл развития разработчика (от джуна к миддлу или от миддла к синьору) сократился до 1-3 лет. Это ускорило текучку кадров и сформировало тренд на быструю смену работы. Также многие компании перешли на удалёнку, благодаря чему сотрудники начали чувствовать себя мобильнее. В частности, разработчики стали чаще брать сторонние проекты, что не просто помогло им зарабатывать больше, но и повысило мотивацию активнее прокачивать скиллы (чтобы оставаться востребованными на биржах фриланса).
Успело ли предложение работодателей адаптироваться под эти тренды? Судя по всему, не очень: HR-специалисты и бизнес-стратеги уже забили тревогу, осознав, что в долгосрочной перспективе компании могут остаться без эксклюзивных «прав» на опытных профессионалов. И пока представители корпоративной среды думали над системой мотивации и бонусов, на LinkedIn стала набирать обороты статья Паки МакКормика (Packy McCormick) о новой концепции формирования команд Liquid Super Teams. Что это такое, и почему LST может стать перспективным расширением методологии Agile, обсудим далее.
Если объяснять общими словами, Liquid Super Team — это группа людей (каждый со своими сильными сторонами, способностями и сетью знакомств), которые объединяются для достижения совместной цели.
Термин распространился благодаря основателю социального клуба Not Boring из Нью-Йорка, тому самому Паки МакКормику, чья статья стала виральной в профессиональных кругах. Комментарии к ней сделали Джордж Катсимихас (George Katsimihas), CFO Exergy Solutions и Шон Канунго (Shawn Kanungo), экс-специалист по стратегическим инновациям Deloitte.
Важные моменты из их эссе, видео и постов, которые помогут лучше понять идею LST:
Да, может показаться, что LST — аналог обычной стартап-команды. Однако Паки МакКормик утверждает, что эти понятия стоит разделять: LST — формат, работающий для краткосрочных проектов и рассчитанный на тактические, а не на стратегические активности.
Чтобы объяснить, как работают LST, МакКормик приводит в пример марвеловских Мстителей: каждый супергерой имеет уникальные возможности и прекрасно справляется с проблемами сам по себе, однако когда приходит время решать глобальную, комплексную задачу (например, спасение мира), герои аккумулируют усилия и начинают действовать сообща.
Во-первых, как мы уже упоминали, в этом формате организации команды сошлись все тренды (быстрая смена работы, удаленка, фриланс, проектная занятость). Во-вторых, преимущества для себя увидели не только рядовые сотрудники, но и HR-специалисты, менеджеры по стратегическому развитию и руководители крупных корпораций. Об этих потенциалах поговорим дальше.
Вертикальная иерархия — знакомый и понятный всем принцип организации людей. Но когда такая структура перемещается в корпоративный фрейм, появляется конфликт начальника и подчинённого. Рядовой сотрудник (агент из нижней части иерархии) каждый день получает всё больше информации о проекте / продукте, поэтому владеет актуальными и ценными знаниями. Между тем руководитель (принципал) располагает меньшим количеством информации, находясь выше в иерархии (и он должен принимать стратегически важные решения). Эта асимметричность распределения данных экономически влияет на любую корпорацию с вертикальной иерархией и иногда приводит к дополнительным издержкам.
LST решают дилемму «принципал-агент», делая гибким даже лидерство: в команде могут появляться временные руководители, но период их активности будет ограничен их же интересом в какой-то части проекта. В остальное время членам LST просто незачем тратить силы на лишнюю занятость. Что касается принятия ключевых решений: в LST члены команды должны делать это с помощью совместных обсуждений / голосований (например, по типу голосования через токены в DAO).
Эксклюзивные «права» на профессионалов высокого ранга могут быть выгодны только крупнейшим IT-корпорациям, которые используют традиционный трудовой договор как гарантию, что уникальный рабочий капитал конкретной личности не уйдёт в чужие руки. Для остальных бизнесов держать в штате высококвалифицированных специалистов — неэффективная трата ресурсов: эксперту вряд ли необходимо участвовать в рутинных процессах, так как его задача — помогать в решении особо важных вопросов, а потому ему больше подходит проектная занятость.
В этом смысле LST — наиболее эргономичная форма организации экспертных команд. Она помогает сконцентрировать таланты (которые вряд ли бы оказались сотрудниками одной компании), чтобы преодолеть комплексную мультидисциплинарную проблему, требующую инновационного подхода. В этом случае мотивация участников смещается с желания получить вознаграждение на шанс поучаствовать в разработке чего-то уникального и расширить собственные возможности благодаря обмену опытом с такими же высококлассными специалистами.
Работая в статичном коллективе, сотрудники редко задумывались о развитии эмоционального интеллекта или адаптивности — по этой причине некоторые консервативные работодатели долго не делали софт скиллы своим must have-ом. Однако теперь, когда работа в целом перешла в более гибкий формат (благодаря удалёнке и постоянной текучке), сотрудники могут не видеть своих новых коллег годами, сохраняя при этом необходимость работать с ними. В таких условиях команда будто постоянно обновляется, и у HR-специалистов и менеджеров появляется новый вызов — быстро интегрировать сотрудников в новые группы. С другой стороны, у самих сотрудников появляется понимание, что быть гибким звеном коллектива — норма.
В этом контексте LST опередили складывающуюся практику, так как сделали софт скилы ключевыми навыками членов команды из-за необходимости самоорганизовываться, передавать эстафету лидерства и коллективно принимать решения. Чтобы оперативно проходить социальные кризисы, участникам коллектива предлагается изучить принципы Servant Leadership: эмпатия к другим участникам, внимание к своему ментальному здоровью, умение слушать, договариваться, принимать разные роли и быстро формировать коммьюнити.
Несмотря на то, что Liquid Super Team новый термин, который ещё не успел получить практические применение, многим разработчикам подобный формат работы знаком: сюда относятся и PET-проекты с претензией на реальный MVP нового продукта, и part-time работа в стартапе. Такие сторонние активности сотрудников, к сожалению, нечасто фиксируются работодателями, а потому редко интегрируются в корпоративные процессы. Тем не менее в некоторых IT-корпорациях все же практикуют что-то похожее на LSP — эти кейсы мы и рассмотрим.
Как обычно, на стороне корпоративных инноваций оказался Google. С 2004 года компания активно использует правило 20 процентов, благодаря которому сотрудники могут посвящать пятую часть своего рабочего времени сторонним проектам. При этом IT-специалист, разрабатывающий собственный продукт или сервис, может привлекать к задачам заинтересованных коллег или экспертов со стороны, формируя гибкую команду.
После введения этой инициативы, у компании появились сервисы Gmail и Google News. Правда, по словам некоторых сотрудников, сегодня правило 20 процентов не соблюдается так строго, потому что все рабочие процессы перешли в гибкий формат: в рабочие часы можно ходить на лекции, участвовать в воркшопах и других активностях, которые способствуют профессиональному развитию и поддерживают мотивацию сотрудников.
Side project time позволяет Google демонстрировать разработчикам, что их автономность и предприимчивость играет ключевую роль в коллективном деле и, как следствие, в общем росте компании: именно благодаря поощрению инициатив «снизу» и временной передачи лидерства у компании есть шанс попробовать формат LST, адаптировать его под себя и плавно переходить на сторону Cooperation Economy.
Когда продакт-оунеры обращаются с проблемой в консалтинг, им необходимо сформировать рабочую группу из представителей своей компании, аналитиков консалтинга и, если задача комплексная, сторонних экспертов из других консалтинговых фирм. В итоге во время работы над проектом на разных этапах к задачам временно подключаются некоторые специалисты, чтобы помочь решить отдельные вопросы — такой формат иногда называют multi-teaming. Внутри него сложно поддерживать строгую вертикальную иерархию, так как в проекте принимают участие сотрудники нескольких «иерархий». Как результат — в группах редко появляется постоянный лидер, а модерация членов команды осуществляется средствами мягкого менеджмента.
Этот опыт взаимодействия специалистов в консалтинге похож на организацию работы в LST и был бы её идеальным аналогом, если бы консультанты, эксперты и аналитики могли самостоятельно подключаться к интересующим их проектам. Пока же это остаётся привилегией отдельных сотрудников.
DAO стала примером того, как функции руководителя можно переместить с участников команды на независимое звено — код программы. Сам Паки МакКормик также использует DAO в своей статье, позиционируя децентрализованную систему как «организационную структуру в интернете, предназначенную для гибкого экономического сотрудничества» (до этого о DAO чаще говорили в контексте венчурных фондов и инвесторов).
DAO близка к концепции LST, так как её члены могут свободно перемещаться между автономными организациями, применяя свою экспертизу там, где она действительно необходима. Кроме того, в отличие от типичного трудоустройства, DAO не заставляют участников подписывать трудовые договоры и отдавать свой профессиональный капитал исключительно одной компании.
Также DAO строится исключительно на добровольных началах (участие подкреплено мотивацией людей достичь одной цели), и в ней отсутствует формальное лидерство, так как весь корпоративный контроль над участниками (вплоть до повседневных операций и графика зарплат), делегирован коду программы. В общем, в перспективе децентрализованные организации действительно могут подкрепить концепцию LST и передать опыт организации гибких команд корпоративным игрокам рынка.
К сожалению, прямого руководства по созданию команд нового типа ни создатель концепции, ни профессиональное коммьюнити ещё не подготовили. Тем не менее можно сформулировать некоторые практические принципы построения LST для корпоративных работодателей и стартапов.
Релевантность, а не гонка за трендами — вот, что должно стать вашим ориентиром. Помните, что LST лучше всего работают для решения мультидисциплинарных, комплексных, тактических задач, требующих особой экспертизы. Соответственно, в корпоративной среде LST подойдут для временных спецпроектов, а в стартапах — для преодоления определённого этапа развития.
Прежде всего обратите внимание на способы поиска сотрудников для LST. Схантить классных специалистов через открытые платформы или биржи фриланса очень трудно, поэтому работайте через реферальные системы и ищите профессионалов через рекомендации от других экспертов (по методу Snowball).
Также подумайте о том, как расставить акценты в своём HR-предложении: членов временных экспертных команд скорее всего заинтересует уникальность проекта, доступ к данным и фреймворкам, а также возможность обмениваться опытом с другими экспертами (очевидно, материальное вознаграждение или социальные плюшки тут проигрывают). Будьте готовы к тому, что у временных сотрудников есть особые требования и параллельная занятость в других компаниях, поэтому придётся быть гибкими и идти навстречу, чтобы заполучить их профессиональный капитал.
Выбирайте специалистов не только по хард, но и по софт скиллам. Так как LST — непостоянная команда, времени на притирку у участников нет. Соответственно, софт скиллы превращаются в главный актив сотрудников, от которого зависит продуктивность коммуникации, а значит, и эффективность совместной работы.
И последнее: не бойтесь фрилансеров и отсутствия официальных трудовых договоров — этого не избежать при гибком трудоустройстве.
Самый сложный пункт программы, ведь он часто зависит от микроклимата в коллективе (в случае стартапа) или корпоративной культуры (в случае большой компании). Например, в 2021 году для рассредоточения ответственности и ликвидации контроля эксперты предлагали переходить к новой форме менеджмента — Action Management. Его суть заключается в том, чтобы поощрять предприимчивость членов команды и уважать автономность их профессиональных интересов. Всё это должно способствовать развитию атмосферы, где эксперименты, самообучение и инициативы движут рабочие процессы.
В контексте LST Action Management выглядит особо актуально. Однако, наряду с ним важно продумать систему коллективного принятия решений (кстати, её можно позаимствовать из DAO, придумав особый аналог токенам).
Как видно, LST — ещё не самая завершённая концепция организации команды. Но если воспринимать её как open-end систему, располагающую к экспериментам, можно обнаружить комфортные для конкретного коллектива форматы работы без лидера (ну, или хотя бы с очень плоской иерархией). В любом случае только практика и время подскажут вам, нужно ли оставаться внутри top-down структуры или стоит переходить к гибким командам по типу LST.
Пока вы выбираете самый продуктивный формат работы своей команды, мы продолжаем делать Telegram-бота Get Me It для анонимного и быстрого налаживания контакта между вами и работой мечты. Настраивайте фильтры в боте и получайте самые релевантные предложения под ваши запросы.
Следуйте за белым кроликом, кликнув на картинку ниже????
Как показывают тренды последних лет, рабочие паттерны сотрудников в IT сделали крутой поворот. Прежде всего, цикл развития разработчика (от джуна к миддлу или от миддла к синьору) сократился до 1-3 лет. Это ускорило текучку кадров и сформировало тренд на быструю смену работы. Также многие компании перешли на удалёнку, благодаря чему сотрудники начали чувствовать себя мобильнее. В частности, разработчики стали чаще брать сторонние проекты, что не просто помогло им зарабатывать больше, но и повысило мотивацию активнее прокачивать скиллы (чтобы оставаться востребованными на биржах фриланса).
Успело ли предложение работодателей адаптироваться под эти тренды? Судя по всему, не очень: HR-специалисты и бизнес-стратеги уже забили тревогу, осознав, что в долгосрочной перспективе компании могут остаться без эксклюзивных «прав» на опытных профессионалов. И пока представители корпоративной среды думали над системой мотивации и бонусов, на LinkedIn стала набирать обороты статья Паки МакКормика (Packy McCormick) о новой концепции формирования команд Liquid Super Teams. Что это такое, и почему LST может стать перспективным расширением методологии Agile, обсудим далее.
Что такое LST
Если объяснять общими словами, Liquid Super Team — это группа людей (каждый со своими сильными сторонами, способностями и сетью знакомств), которые объединяются для достижения совместной цели.
Термин распространился благодаря основателю социального клуба Not Boring из Нью-Йорка, тому самому Паки МакКормику, чья статья стала виральной в профессиональных кругах. Комментарии к ней сделали Джордж Катсимихас (George Katsimihas), CFO Exergy Solutions и Шон Канунго (Shawn Kanungo), экс-специалист по стратегическим инновациям Deloitte.
Важные моменты из их эссе, видео и постов, которые помогут лучше понять идею LST:
- в таких командах отсутствует лидер, а ответственность за решения распределена между участниками;
- каждый мотивирован вносить вклад, так как результат совместной работы представляет его личный интерес (Cooperation Economy);
- участники не связаны фиксированными обязательствами, руководствуются собственной мотивацией и могут вовлекаться в процессы при наличии интереса (главные принципы взаимодействия — optionality, flexibility, and individualism);
- параллельно члены команды могут состоять в нескольких LST, постоянно прокачивая себя и умножая свой профессиональный капитал.
Да, может показаться, что LST — аналог обычной стартап-команды. Однако Паки МакКормик утверждает, что эти понятия стоит разделять: LST — формат, работающий для краткосрочных проектов и рассчитанный на тактические, а не на стратегические активности.
Чтобы объяснить, как работают LST, МакКормик приводит в пример марвеловских Мстителей: каждый супергерой имеет уникальные возможности и прекрасно справляется с проблемами сам по себе, однако когда приходит время решать глобальную, комплексную задачу (например, спасение мира), герои аккумулируют усилия и начинают действовать сообща.
Почему в профессиональных кругах все заговорили о LST
Во-первых, как мы уже упоминали, в этом формате организации команды сошлись все тренды (быстрая смена работы, удаленка, фриланс, проектная занятость). Во-вторых, преимущества для себя увидели не только рядовые сотрудники, но и HR-специалисты, менеджеры по стратегическому развитию и руководители крупных корпораций. Об этих потенциалах поговорим дальше.
Решение дилеммы «принципал-агент»
Вертикальная иерархия — знакомый и понятный всем принцип организации людей. Но когда такая структура перемещается в корпоративный фрейм, появляется конфликт начальника и подчинённого. Рядовой сотрудник (агент из нижней части иерархии) каждый день получает всё больше информации о проекте / продукте, поэтому владеет актуальными и ценными знаниями. Между тем руководитель (принципал) располагает меньшим количеством информации, находясь выше в иерархии (и он должен принимать стратегически важные решения). Эта асимметричность распределения данных экономически влияет на любую корпорацию с вертикальной иерархией и иногда приводит к дополнительным издержкам.
LST решают дилемму «принципал-агент», делая гибким даже лидерство: в команде могут появляться временные руководители, но период их активности будет ограничен их же интересом в какой-то части проекта. В остальное время членам LST просто незачем тратить силы на лишнюю занятость. Что касается принятия ключевых решений: в LST члены команды должны делать это с помощью совместных обсуждений / голосований (например, по типу голосования через токены в DAO).
Сокращение издержек
Эксклюзивные «права» на профессионалов высокого ранга могут быть выгодны только крупнейшим IT-корпорациям, которые используют традиционный трудовой договор как гарантию, что уникальный рабочий капитал конкретной личности не уйдёт в чужие руки. Для остальных бизнесов держать в штате высококвалифицированных специалистов — неэффективная трата ресурсов: эксперту вряд ли необходимо участвовать в рутинных процессах, так как его задача — помогать в решении особо важных вопросов, а потому ему больше подходит проектная занятость.
В этом смысле LST — наиболее эргономичная форма организации экспертных команд. Она помогает сконцентрировать таланты (которые вряд ли бы оказались сотрудниками одной компании), чтобы преодолеть комплексную мультидисциплинарную проблему, требующую инновационного подхода. В этом случае мотивация участников смещается с желания получить вознаграждение на шанс поучаствовать в разработке чего-то уникального и расширить собственные возможности благодаря обмену опытом с такими же высококлассными специалистами.
Акцент на софт скиллах
Работая в статичном коллективе, сотрудники редко задумывались о развитии эмоционального интеллекта или адаптивности — по этой причине некоторые консервативные работодатели долго не делали софт скиллы своим must have-ом. Однако теперь, когда работа в целом перешла в более гибкий формат (благодаря удалёнке и постоянной текучке), сотрудники могут не видеть своих новых коллег годами, сохраняя при этом необходимость работать с ними. В таких условиях команда будто постоянно обновляется, и у HR-специалистов и менеджеров появляется новый вызов — быстро интегрировать сотрудников в новые группы. С другой стороны, у самих сотрудников появляется понимание, что быть гибким звеном коллектива — норма.
В этом контексте LST опередили складывающуюся практику, так как сделали софт скилы ключевыми навыками членов команды из-за необходимости самоорганизовываться, передавать эстафету лидерства и коллективно принимать решения. Чтобы оперативно проходить социальные кризисы, участникам коллектива предлагается изучить принципы Servant Leadership: эмпатия к другим участникам, внимание к своему ментальному здоровью, умение слушать, договариваться, принимать разные роли и быстро формировать коммьюнити.
Как концепция работает на практике
Несмотря на то, что Liquid Super Team новый термин, который ещё не успел получить практические применение, многим разработчикам подобный формат работы знаком: сюда относятся и PET-проекты с претензией на реальный MVP нового продукта, и part-time работа в стартапе. Такие сторонние активности сотрудников, к сожалению, нечасто фиксируются работодателями, а потому редко интегрируются в корпоративные процессы. Тем не менее в некоторых IT-корпорациях все же практикуют что-то похожее на LSP — эти кейсы мы и рассмотрим.
Side project time или Genius hour в Google
Как обычно, на стороне корпоративных инноваций оказался Google. С 2004 года компания активно использует правило 20 процентов, благодаря которому сотрудники могут посвящать пятую часть своего рабочего времени сторонним проектам. При этом IT-специалист, разрабатывающий собственный продукт или сервис, может привлекать к задачам заинтересованных коллег или экспертов со стороны, формируя гибкую команду.
После введения этой инициативы, у компании появились сервисы Gmail и Google News. Правда, по словам некоторых сотрудников, сегодня правило 20 процентов не соблюдается так строго, потому что все рабочие процессы перешли в гибкий формат: в рабочие часы можно ходить на лекции, участвовать в воркшопах и других активностях, которые способствуют профессиональному развитию и поддерживают мотивацию сотрудников.
Side project time позволяет Google демонстрировать разработчикам, что их автономность и предприимчивость играет ключевую роль в коллективном деле и, как следствие, в общем росте компании: именно благодаря поощрению инициатив «снизу» и временной передачи лидерства у компании есть шанс попробовать формат LST, адаптировать его под себя и плавно переходить на сторону Cooperation Economy.
Проектные группы в консалтинге
Когда продакт-оунеры обращаются с проблемой в консалтинг, им необходимо сформировать рабочую группу из представителей своей компании, аналитиков консалтинга и, если задача комплексная, сторонних экспертов из других консалтинговых фирм. В итоге во время работы над проектом на разных этапах к задачам временно подключаются некоторые специалисты, чтобы помочь решить отдельные вопросы — такой формат иногда называют multi-teaming. Внутри него сложно поддерживать строгую вертикальную иерархию, так как в проекте принимают участие сотрудники нескольких «иерархий». Как результат — в группах редко появляется постоянный лидер, а модерация членов команды осуществляется средствами мягкого менеджмента.
«Без гибких команд современному консалтингу, наверное, было бы сложно существовать: в современных условиях рынка тебе нужно быть максимально адаптивным, чтобы предлагать разнообразным клиентам эффективные решения. В этой реальности невозможно не привлекать сторонних экспертов или не «жонглировать» сотрудниками между командами для решения узко профессиональных вопросов.»
Ясер Масуум, бизнес-консультант в компании большой четвёрки
Этот опыт взаимодействия специалистов в консалтинге похож на организацию работы в LST и был бы её идеальным аналогом, если бы консультанты, эксперты и аналитики могли самостоятельно подключаться к интересующим их проектам. Пока же это остаётся привилегией отдельных сотрудников.
DAO (Децентрализованная автономная организация)
DAO стала примером того, как функции руководителя можно переместить с участников команды на независимое звено — код программы. Сам Паки МакКормик также использует DAO в своей статье, позиционируя децентрализованную систему как «организационную структуру в интернете, предназначенную для гибкого экономического сотрудничества» (до этого о DAO чаще говорили в контексте венчурных фондов и инвесторов).
DAO близка к концепции LST, так как её члены могут свободно перемещаться между автономными организациями, применяя свою экспертизу там, где она действительно необходима. Кроме того, в отличие от типичного трудоустройства, DAO не заставляют участников подписывать трудовые договоры и отдавать свой профессиональный капитал исключительно одной компании.
Также DAO строится исключительно на добровольных началах (участие подкреплено мотивацией людей достичь одной цели), и в ней отсутствует формальное лидерство, так как весь корпоративный контроль над участниками (вплоть до повседневных операций и графика зарплат), делегирован коду программы. В общем, в перспективе децентрализованные организации действительно могут подкрепить концепцию LST и передать опыт организации гибких команд корпоративным игрокам рынка.
Как построить LST?
К сожалению, прямого руководства по созданию команд нового типа ни создатель концепции, ни профессиональное коммьюнити ещё не подготовили. Тем не менее можно сформулировать некоторые практические принципы построения LST для корпоративных работодателей и стартапов.
1. Формируйте LST, когда это действительно нужно
Релевантность, а не гонка за трендами — вот, что должно стать вашим ориентиром. Помните, что LST лучше всего работают для решения мультидисциплинарных, комплексных, тактических задач, требующих особой экспертизы. Соответственно, в корпоративной среде LST подойдут для временных спецпроектов, а в стартапах — для преодоления определённого этапа развития.
2. Меняйте своё HR-предложения
Прежде всего обратите внимание на способы поиска сотрудников для LST. Схантить классных специалистов через открытые платформы или биржи фриланса очень трудно, поэтому работайте через реферальные системы и ищите профессионалов через рекомендации от других экспертов (по методу Snowball).
Также подумайте о том, как расставить акценты в своём HR-предложении: членов временных экспертных команд скорее всего заинтересует уникальность проекта, доступ к данным и фреймворкам, а также возможность обмениваться опытом с другими экспертами (очевидно, материальное вознаграждение или социальные плюшки тут проигрывают). Будьте готовы к тому, что у временных сотрудников есть особые требования и параллельная занятость в других компаниях, поэтому придётся быть гибкими и идти навстречу, чтобы заполучить их профессиональный капитал.
Выбирайте специалистов не только по хард, но и по софт скиллам. Так как LST — непостоянная команда, времени на притирку у участников нет. Соответственно, софт скиллы превращаются в главный актив сотрудников, от которого зависит продуктивность коммуникации, а значит, и эффективность совместной работы.
И последнее: не бойтесь фрилансеров и отсутствия официальных трудовых договоров — этого не избежать при гибком трудоустройстве.
3. Рассредотачивайте ответственность
Самый сложный пункт программы, ведь он часто зависит от микроклимата в коллективе (в случае стартапа) или корпоративной культуры (в случае большой компании). Например, в 2021 году для рассредоточения ответственности и ликвидации контроля эксперты предлагали переходить к новой форме менеджмента — Action Management. Его суть заключается в том, чтобы поощрять предприимчивость членов команды и уважать автономность их профессиональных интересов. Всё это должно способствовать развитию атмосферы, где эксперименты, самообучение и инициативы движут рабочие процессы.
В контексте LST Action Management выглядит особо актуально. Однако, наряду с ним важно продумать систему коллективного принятия решений (кстати, её можно позаимствовать из DAO, придумав особый аналог токенам).
Как видно, LST — ещё не самая завершённая концепция организации команды. Но если воспринимать её как open-end систему, располагающую к экспериментам, можно обнаружить комфортные для конкретного коллектива форматы работы без лидера (ну, или хотя бы с очень плоской иерархией). В любом случае только практика и время подскажут вам, нужно ли оставаться внутри top-down структуры или стоит переходить к гибким командам по типу LST.
Пока вы выбираете самый продуктивный формат работы своей команды, мы продолжаем делать Telegram-бота Get Me It для анонимного и быстрого налаживания контакта между вами и работой мечты. Настраивайте фильтры в боте и получайте самые релевантные предложения под ваши запросы.
Следуйте за белым кроликом, кликнув на картинку ниже????
Комментарии (10)
sky2high0
08.04.2022 22:35+2Интересно, но без примера непонятно.) Можно пример хотя бы абстрактного проекта на LTS?
Пока все очень туманно и неясно откуда деньги в таких командах, кто ставит задачи, как находятся желающие их решать и самое главное, какой срок жизни у предполагаемого проекта. Пока больше похоже на «рандомно наговнокодили и разбежались») не в обиду всей статье, конечно.
aigoncharov
09.04.2022 01:27Если разрабатывается какая-то инфраструктура, а не customer-facing часть продукта, то инженеры зачастую лучше знают, что надо делать, и где болит.
Как результат, инженеры в команде раз в Х времени собираются, брейнштормят идеи, голосуют за приоритеты и значимость этих идей.
На основании этого, каждый инженер решает над чем ему интересно будет работать в следующйи большой кусок времени (например, полугодие).
Менеджер в этой ситуации помогает найти партнеров в других командах, которые могут как-то выиграть от вашего проекта. так же менеджер могжет помочь в корректировке приоритетности проектов, потому что у менеджера больше контекста о том, чем занимаются и другие соседние команды, и какие-то ваши проекты могут решить больше не только внутри команды, но и у соседних команд.
Кмк, это может хорошо работать в больших компаниях, где есть много команд, и развесистая инфраструктура, которые поддерживают и развивают сотни людей.sky2high0
09.04.2022 11:25О, спасибо! Сразу понятнее.
Да, пожалуй, если это, например, команда разработки фреймворка или БД, то инженеры могут нагенерить толковых задач.
На продуктовые команды, получается, LTS не очень ложится? С трудом представляю как инженеры изучают рынки, предлагают фичи с предсказуемым и измеримым результатом, работают с маркетингом для освещения релиза и пр.
aigoncharov
09.04.2022 12:33Мне кажется, что в продуктовых командах инженеры могут сами придумывать и решать технические задачи по улучшению перформанса. В случае же, новых фичей, бизнес может дать направление куда копать на следующие полгода, в дальше уже инженеры решат как копать. У меня по подобной схеме работы есть опыт только в разработке инфраструктуры, так что могу только теоретизировать про продукт.
anaken
11.04.2022 09:01+1Эта концепция (LST) как и вся статья в целом больше похожа на желаемое виденье устройства владельцами стартап-проектов.
Особенно насмешило "цикл развития разработчика (от джуна к миддлу или от миддла к синьору) сократился до 1-3 лет". А потом мы видим сеньоров с опытом 2 года, которые иногда даже не знают, что такое git. Выдача желаемого за действительное. В действительности же от разработчиков требуется наличие все большего количества знаний. Например, если раньше (лет 10 назад) сеньору-разработчику было достаточно знаний реляционных СУБД с практическим опытом в 1-2 реализациях. То сегодня - это знания джуна, а сеньор уже должен иметь знания в 2-3 типах СУБД и практический опыт в нескольких реализациях каждого типа. А знания всяких распределенных кластерных систем (типа Hadoop), всякие middleware-системы и прочее и прочее...
SharpNesla
11.04.2022 09:04Ну в целом стоит отметить, что примерно таким подходом работает Valve вот уже третий десяток лет. Соответственно за это время проявились и преимущества и недостатки этого подхода...
bigbadmutuh
11.04.2022 12:43+1если ответственность разделена между всеми - это значит что никто ответственности не несёт, либо это круговая порука.
MAXH0
А на картинке то таймЛид не врет - если будут плохо грести и лодка потонет, то он, возможно и выплывет, а гребцы точно нет...
mvv-rus
Читал когда-то, про гребной флот, что в античности на боевом флоте гребцами были вольные люди, а не рабы, как на галерах Нового Времени. Потому что тогдашний бой был основан на активном маневрировании: ударить врага своим тараном тараном, уклониться от чужого таранного удара, подойти на расстояние абордажа. И потому для успеха гребцы должны были выкладываться в полную силу, и даже больше. И вольный человек, дороживший своей жизнью, свободой и честью мог сделать то, чего ни от раба, которому и жизнь-то такая рабская не дорога, не говоря уж об отсутстующей свободе, никак не добиться, никаким кнутом.
А галеры часто вели бой с помощью пушек, а потому скорость и маневренность для них не были столь критичны.
PS Источник этих сведений, правда, особым авторитетом не отличался: это была статья в журнале про компьютерные игры (впрочем — в весьма толковом журнале, ныне, увы — помершем). Так что прошу эти сведения рассматривать не более, чем как информацию для размышления, требующую, вообще-то, независимой проверки. Но в контексте этой самой картинки, думаю, эта информация небезынтересна.