Я работал в разнообразных технологических компаниях: от «традиционных» центров программирования и консалтингов до инвестиционных банков и быстрорастущих технологических фирм. Также я общался с разработчиками ПО, работающими в стартапах, банковской сфере, автомобилестроении, big tech и в более «традиционных компаниях». В этой выборке была приличная доля компаний из Кремниевой долины и тех, которые находятся вне её.
Я заметил, что компании Кремниевой долины часто «схватывают» то, что их традиционные конкуренты не могут даже понять и реализовать на практике — особенно в Европе. Эти практики приводят к ускоренным инновациям на уровне компаний, более качественному профессиональному росту инженеров и просто к «оптимальности» в лучшем значении этого слова. В свою очередь, компании Кремниевой долины могут платить (и платят!) больше, и могут получить больше пользы от одного и того же человека.
В этой статье я буду использовать термин «компания в стиле Кремниевой долины», подразумевая современные компании, оптимально использующие каждого разработчика ПО и традиционно находящиеся в Кремниевой долине (хотя многие новые компании этого типа обосновываются уже не там). Такие компании сравнимы по КПД инженера с Meta* или Google. Они используют схожие методологии и часто могут привлекать персонал из других компаний «в стиле Кремниевой долины».
Вот основное, что эти компании понимают лучше, чем многие другие.
▍ 1. Автономность разработчиков ПО
В «традиционных» компаниях разработчики получают назначенные им рабочие задания, чаще всего через тикеты JIRA. Эти тикеты проверяются менеджером продукта или проекта и в них содержатся основные и ключевые подробности для выполнения работы. И от разработчиков ожидается, что они будут делать только это. Вопросов почти не требуется, если только для уточнения подробностей тикета.
Но в компании «в стиле КД» вы этого почти не увидите. В них есть проекты, менеджеры программ и менеджеры по разработке. Но по большей мере от инженеров ожидается, что они сами поймут, «как» выполнять работу, в том числе и принимать серьёзные решения. В некоторых местах каждым проектом руководит инженер, упрощающий разбиение работы на части. В других местах эту работу могут выполнять менеджеры по разработке или сеньор-разработчики. Как бы это ни происходило, всех инженеров мотивируют смотреть на картину в целом, чтобы они могли быть гибкими и решать любые проблемы.
Компании «в стиле КД» мотивируют инженеров брать инициативу в свои руки. В них часто можно увидеть сервисы и функции, предложенные инженерами, или команды, тратящие время на выплату технического долга, который решили устранить люди в команде. И очень редко менеджеры говорят инженерам, что им нужно делать, разбивают их работу на мелкие части и занимаются микроменеджментом. Люди находятся на самоуправлении.
В традиционных компаниях от разработчиков ожидается, что они будут выполнять назначенную им работу. В компаниях в стиле КД ожидается, что они будут решать проблемы бизнеса. Разница огромна. Она влияет на повседневную жизнь любого инженера.
В традиционных компаниях такая ситуация часто приводит к тому, что разработчики оказываются в иерархической структуре. Я как-то общался с людьми из банка, у них было шесть уровней руководства проектами. Разработчики находились на двух нижних. Решения могли принимать сотрудники начиная с третьего уровня. По сути, те, кто выполняет работу, по определению не имеют права голоса. Нужно ли говорить, что у этого банка были проблемы с работой его программного отдела?
Сравните это с компаниями, где признаётся способность инженеров решать практические вопросы лучше, чем кто-либо другой. Руководители знают, что в интересах бизнеса делиться с ними всем релевантным бизнес-контекстом и дать им свободу реализации.
▍ 2. Любопытные решатели проблем, а не безмозглый ресурс
Традиционные компании склонны считать, что 8 часов времени инженера должны тратиться на кодинг. Любое время, проведённое не за компьютером и не за написанием кода, часто воспринимается как пустые траты. И это оправдывается высокой зарплатой разработчиков. Я слышал, что эту логику кто-то объяснял так:
Разработчикам ПО платят больше, чем многим другим должностям. Поэтому нужно и загружать их соответственно. Мы не можем позволить им работать вхолостую.
Компании «в стиле КД» воспринимают разработчиков ПО как людей, лучше всего подходящих для решения задач организации. Они нанимают не только за технические навыки, но и за навыки коммуникации и решения проблем. Они мыслят примерно так:
Разработчики ПО — одни из самых высокооплачиваемых людей в нашей компании. Так получилось потому, что благодаря кодингу и решению задач они одни из самых полезных людей. Мы хотим познакомить их с бизнесом, чтобы параллельно с выполнением своей «обычной» работы они могли находить возможности, оказывающие сильное влияние на бизнес.
На практике, мотивированный инженер может приносить во много раз больше пользы, чем «заводской рабочий», которому просто говорят, что делать. В худшем случае, когда спецификация работы четка и корректна, оба человека обеспечат одинаковый результат. Однако инженеры, мотивированные решать задачи, часто останавливаются и задумываются, прежде чем браться за работу, выявляя наиболее важные возможности. Вот примеры пары разговоров, которые у меня были в компаниях «в стиле КД» после того, как я задал инженеру вопрос, сможет ли он сделать X:
- «Я немного изучил вопрос, и хотя мы можем сделать X, если у нас получится уменьшить масштаб проекта на эту функцию, которая никак не повлияет на пользу для бизнеса, то мы сможем выпустить это без изменений в коде, просто модифицировав несколько файлов конфигурации.»
- "Меня тревожит, сможем ли мы выпустить проект, и я думаю, что мы должны поставить это на паузу. Я изучил, что делают наши конкуренты, один из них выпустил похожую функцию, но откатил её, столкнувшись с расследованием регулирующего органа. Мы спрашивали у юридического отдела, можно ли вообще выпускать это?"
- «Я изучил наш бэклог и обнаружил, что проект Y очень похож на X. Если бы мы скомбинировали проект X и проект Y, то смогли бы выпустить две вещи, потратив лишь незначительное количество лишних ресурсов.»
- «Мы могли бы построить этот проект сейчас на легаси-инфраструктуре, но потом нам придётся мигрировать на новую инфраструктуру, которая будет готова через месяц. Можно ли отложить проект на месяц, пока не будет готова новая инфраструктура, чтобы избежать двойной работы? Для бизнеса нет никаких веских причин выпускаться в этом месяце, так что я настоятельно рекомендую подождать»
В окружении, стимулирующем к решению проблем и к достижению результатов, а не следованию указаниям, принимаются более качественные решения.
▍ 3. Прозрачность внутренних данных, кода и документации
Степень прозрачности в компаниях КД высока. Хотя есть и исключения — предположительно, Apple и Palantir стремятся предоставлять своим инженерам минимально возможный объём информации, по моим наблюдениям, большинство компаний «в стиле КД» максимально делятся знаниями. Разумеется, насколько это возможно в соответствии с требованиями GDPR, PII и других законов.
Сотрудники (и не только инженеры) часто имеют доступ к бизнес-метрикам в реальном времени, а также источники данных для написания собственных запросов и создания произвольных отчётов. В Skyscanner мы ежедневно получали электронные письма со сводками по дневному доходу с разбивкой по пунктам. В Uber сотрудники еженедельно получают рассылку о росте компании.
С ростом и выходом на IPO компаний происходит консолидация этой информации. Однако у инженеров всё равно остаётся доступ к бизнес-данным их организации, которые помогают им в принятии решений.
В традиционных компаниях практически ничего подобного нет. Инженеры получают спецификацию, а уже руководство понимает, почему принимается решение — по крайней мере, принцип таков.
▍ 4. Доступ к бизнесу и бизнес-метрикам
В компаниях КД ожидается, что каждый участник команды понимает, на какую часть бизнеса и как влияет его работа. Цели команды редко заключаются лишь в выпуске фичи: они выбирают, уменьшить ли отток клиентов на 2%, выпустив Фичу 1, или повысить прогноз дохода на $10 миллионов в год, выпустив Проект X.
Инженеров КД мотивируют взаимодействовать с остальной частью бизнеса и образовывать связи не только с коллегами-инженерами. На практике часто оказывается так, что сеньор-разработчики занимаются следующим: от проведения совещаний 1:1 с менеджерами продуктов до участия в сессиях исследований клиентов. Но я видел и то, как новички-инженеры без малейших проблем работали напрямую с руководителями бизнеса.
В традиционных компаниях, напротив, разработчикам часто мешают общаться с остальной частью бизнеса. Конечно, это презентуется не так. Обычно говорится: «Мы хотим защитить своих разработчиков от отвлекающих факторов». Но я слышал истории о том, как менеджер по разработке хотел пригласить участников своей команды на презентацию продукта, однако менеджер по продукту запретил это делать. «Нам нужно, чтобы они работали, мы не можем позволить, чтобы их отвлекали», — стандартное объяснение.
Когда инженер в традиционной компании создаёт взаимосвязи за пределами своей команды, ему часто говорят, что он «недостаточно сосредоточен», «тратит время» или занимается «не своим делом». Подобные «необычные» действия даже часто фиксируются как отрицательные в оценке его производительности.
Мне кажется безумием, что компании запирают своих лучших решателей задач в загоне с формулировкой «вы просто пишете код», но такое происходит. И те же компании, которые пытаются мерить продуктивность разработки метриками, связанными со строками кода или коммитами, удивляются, почему их инженеры не нацелены на продукт или не осведомлены о нём.
▍ 5. Коммуникация «инженер-инженер» вместо «треугольной» коммуникации
Если вы инженер и у вас есть вопрос о том, как другая команда делает то или иное, то процесс коммуникации в традиционной компании и компании «в стиле КД» строится по-разному.
Традиционные компании стимулируют к иерархической коммуникации. Это происходит и для «защиты» инженеров, и потому, что менеджеры в таких организациях стремятся быть информационными центрами, не отдавая никому власти над этой сферой. Вот как часто происходит передача вопроса к другой команде:
Компании «в стиле КД» стимулируют к коммуникации «инженер-инженер» и и избавлению от промежуточных звеньев. Это быстрее во всех случаях. А в случаях, когда инженер другой команды не может помочь, этот процесс можно откатить к «традиционной» модели с менеджером, помогающим в дискуссии:
▍ 6. Инвестирование в снижение неудовлетворённости разработчиков
Разработка может быть стрессовым процессом. Не из-за написания кода — это-то легко! — но из-за сопровождающих его вещей. Настройки зависимостей. Развёртывания в продакшене или тестовых окружениях. CI/CD. Мониторинга и систем уведомлений. Всё это не так серьёзно, когда команда состоит из небольшого количества людей. Но она всё равно будет разрастаться.
Однако с ростом компании удовлетворённость разработчиков снижается. Всё начинается с мелочей: увеличивается время сборки, добавляются зависимости, требуется вносить изменения в разных сервисах. Потом приходится разбираться, какая команда отвечает за какой сервис, мелкие миграции разрастаются из-за влияния на несколько команд, а потом даже иногда приходится заново создавать архитектуру для всей системы.
Фреймворки и инструментарий быстро меняются и инструментарий редко поспевает за развитием. Компании, которым важно, чтобы инженеры сосредоточились на быстром решении задач, создают различные инфраструктурные, платформенные и SRE-команды, уменьшающие неудобства разработчиков.
Хотя может показаться контринтуитивным нанимать разработчиков ПО, занимающихся ускорением работы других разработчиков ПО, часто это не так. Это обеспечивает большую выгоду, помогает компаниям двигаться быстрее и разгрузить разработчиков.
▍ 7. Более оптимальное использование --> более высокая {автономность, зарплата}
Многим компаниям в стиле КД, стремящимся конкурировать в сфере зарплат инженеров, нужно обеспечивать их оптимальное применение, чтобы приносимая этими разработчиками польза превышала их зарплаты. Эта оптимизация может использоваться как при масштабировании, так и при росте бизнеса. Оптимизацию повышают такие вещи, как снижение времени, потраченного на ненужную коммуникацию, так и совершенствование инструментария. Для обеспечения высокой оптимизации следует давать инженерам достаточную автономность, чтобы они могли делать вклад в бизнес.
Google, Meta* и другие успешные компании платят сегодня высокие зарплаты за использование масштаба. Инженер в таких компаниях часто создаёт фичи, используемые миллионами клиентов. Такая оптимизация и принесение пользы оплачивают себя сами.
Стартапы в стиле КД используют разработчиков ПО для роста бизнеса. Именно так разработчик ПО в Fog Creek Software реализовал идею рекламы на миллион долларов. Именно так несколько инженеров и дизайнеров разрабатывали кнопку Like в Facebook**. Польза этой кнопки для бизнеса исчисляется миллиардами долларов: она позволила Meta* (пере-)таргетировать рекламу и «отслеживать» пользователей за пределами сайта Facebook**.
Если бы эти люди работали в «традиционной» среде, их идеи остались бы только идеями. Стартапы «в стиле КД» мотивируют инженеров придумывать идеи для бизнеса и реализовывать их. От этого выигрывают все: и люди с идеями, и бизнес.
Компании, оптимально использующие инженеров, не будут испытывать трудностей с оплатой их труда по рынку или выше. Basecamp — хороший пример компании не из «Big tech», оптимально использующей инженеров, что позволяет ей также платить зарплату по верху рынка Сан-Франциско, при этом оставаясь прибыльной.
▍ Технические отделы — это центр извлечения прибыли, а не источник затрат
Ещё один способ взглянуть на то, как работают компании «в стиле КД» — это увидеть, что они считают технические отделы центром извлечения прибыли, а не источником затрат. Изучая таблицу из двенадцати самых «дорогих» (на июль 2022 года) компаний, можно заметить очевидные тенденции:
▍ Самая большая разница
Существует множество аспектов в различиях между разными компаниями в том, как они относятся к инженерам. Однако самый важный заключается в том, что компании «в стиле КД» считают инженеров генераторами пользы и творческими решателями задач. Традиционные компании воспринимают их как заводских рабочих.
Эта разница в мышлении приводит к тому, что прогрессивно мыслящие компании могут и платить инженерам больше, и давать им больше свободы. Польза от заводского рабочего чётко определена и с её учётом можно выполнять планирование. С другой стороны, творческий решатель задач может при правильном использовании принести в десять раз больше пользы. Разумнее платить ему больше, давать больше свободы, позволяя делать больший вклад в бизнес.
Поработав в стиле Кремниевой долины, вы с трудом вернётесь на «традиционное» рабочее место, где у каждого есть своя чёткая роль, а попытки выйти за её рамки вызывают непонимание.
Разработчику ПО приятнее работать там, где он решает задачи, а не воспринимается как заводской рабочий.
Meta Platforms*, а также принадлежащие ей социальные сети Facebook** и Instagram**
* — признана экстремистской организацией, её деятельность в России запрещена
** — запрещены в России
Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх ????️
Комментарии (18)
Apoheliy
02.10.2023 15:01+11Похоже на восторженно-идеалистические картинки от Valve: каждый занимается тем проектом, каким хочет; и если что-то надоело, то вместе с рабочим местом перемещаешься к новой команде.
Потом вдруг проходит информация, что и у Valve есть дедлайны и сдачи продуктов. Просто наружу они выставляют красивую картинку. Для привлечения, так сказать.
Если же посмотреть со стороны в целом, то этому больше подходит термин "разводилово". Хотя, наверное, часть инженеров именно так и работают. Но, опасаюсь, далеко не все.
xxxphilinxxx
02.10.2023 15:01+13А теперь воплотим абстракции в реальность, но пойдем не идеальным, а ИМХО более вероятным путем.
Раз инженеры получают право голоса, этот голос должен стать частью процесса, а не хватанием за руку в последний момент, следовательно, у инженера появляются новые обязанности, при этом навыки управленца+PO+архитектора в комплекте не идут. Добавим эффективное самоуправление на уровне команды - уже минимум три роли с тимлидом и получаем требования как минимум на ведущего специалиста. Опционально добавим девопс без системных администраторов, работу линией техподдержки, дежурства, прочие процессуальные события, так что в итоге на работу собственно исходным инженером остается один-два дня в неделю. Добавим плоскую структуру компании, так что эти требования автоматически применяются абсолютно ко всем инженерам. Разумеется, бизнесу очень выгодно, когда в проекте есть люди "и швец, и жнец, и на дуде игрец", да еще и инициативные, но где набрать столько универсальных пассионариев, что делать с остальными и можно ли все еще называть такую позицию просто инженером?
Ну и пара очевидностей. Первая: если менеджер не интересуется мнением специалистов, допускает тупики, игнорирует смежные проекты, не имеет долгосрочных планов, то это некомпетентный менеджер. Вторая: стиль КД даже в тексте статьи очень часто соседствует со словом "стартап", а в стартапах так-то традиционный уклад с несколькими уровнями менеджеров встречается все же нечасто.
ozzyBLR
02.10.2023 15:01+8Чем крупнее компания, тем больше уровней иерархии. Если кто-то может привести пример компании крупнее 3к работников со всего парой уровней по вертикали - было бы интересно узнать. И разделение как раз происходит на уровне права принимать решение.
Кмк, в статье несколько идеализируется возможность инжерена в "компании в стиле КД" принимать серьёзные решение. Пожалуй, в более реалистичном сценарии инженер может дать обратную связь или предложение - и это послание будет эффективно услышано и рассмотрено.
Yuri_nedre
02.10.2023 15:01+3Это утопия, когда команда на тысячи человек заявляет, что все равны, все могут принимать решение и т.д.
gsl23
02.10.2023 15:01Плюсую. Известно, же как раз что в крупных компаниях наоборот много уровней иерархии инженеров, и высшие имеют большие полномочия в принятии решений, сравнимые в топ менеджерами.
Взять тот же МС, иерархия выглядет примерно так
Junior Software Engineer
Intermediate Software Engineer
Senior Software Engineer
Staff Software Engineer
Senior Staff Software Engineer
Principal Software Engineer
Distinguished Software Engineer
Fellow
Senior Fellow ...
Я думаю, общий посыл статьи правильный, просто диавол как всегда в деталях..
kasiopei
02.10.2023 15:01+3Описанное больше походит на подразделение инновации. Некая сытая фирма инвестирует деньги в разработку нового и предоставляется свобода творчества. А вот когда система уже создана и ее нужно обслуживать, то все будет по классике. Тут уже личный вклад не влияет и приходят всякие мастера работы ртом, кумовство, игры престолов....
APXEOLOG
02.10.2023 15:01+4Я заметил, что компании Кремниевой долины часто «схватывают» то, что их традиционные конкуренты не могут даже понять и реализовать на практике — особенно в Европе. ... В свою очередь, компании Кремниевой долины могут платить (и платят!) больше, и могут получить больше пользы от одного и того же человека.
Я в компаниях КД не работал, но я слышал, что там люди очень любят работать по 60 часов в неделю и больше. Не удивительно, что они получают больше пользы от человека (особенно по сравнению с Европой, где с этим делом все довольно строго и люди работают положеные 40 часов в неделю)
В «традиционных» компаниях разработчики получают назначенные им рабочие задания, чаще всего через тикеты JIRA. Эти тикеты проверяются менеджером продукта или проекта и в них содержатся основные и ключевые подробности для выполнения работы. И от разработчиков ожидается, что они будут делать только это. Но в компании «в стиле КД» вы этого почти не увидите. В них есть проекты, менеджеры программ и менеджеры по разработке. Но по большей мере от инженеров ожидается, что они сами поймут, «как» выполнять работу, в том числе и принимать серьёзные решения.
Не совсем понятно, что мешает в тикете описать "что" нужно сделать, а "как" сделать может и разработчик решить. Или смысл в том, что вместо тикета разработчику надо просто в мессенджер скинуть идею из головы?
Компании «в стиле КД» мотивируют инженеров брать инициативу в свои руки. В них часто можно увидеть сервисы и функции, предложенные инженерами, или команды, тратящие время на выплату технического долга, который решили устранить люди в команде. И очень редко менеджеры говорят инженерам, что им нужно делать, разбивают их работу на мелкие части и занимаются микроменеджментом. Люди находятся на самоуправлении. В традиционных компаниях от разработчиков ожидается, что они будут выполнять назначенную им работу. В компаниях в стиле КД ожидается, что они будут решать проблемы бизнеса.
Даже если бизнес понимает, что технический долг - это его проблема, все равно есть определенный порог risk/reward между "сделать фичу и усилить позиции на рынке, но огрести позднее" и "пофиксить техдолг и не огрести позднее, но уступить конкурентам". Причем у каждого инженера этот порог будет своим. И у CEO компании тоже. Было бы интересно узнать, как в "КД-компаниях" решают данную проблему мнений.
В компаниях КД ожидается, что каждый участник команды понимает, на какую часть бизнеса и как влияет его работа. Цели команды редко заключаются лишь в выпуске фичи: они выбирают, уменьшить ли отток клиентов на 2%, выпустив Фичу 1, или повысить прогноз дохода на $10 миллионов в год, выпустив Проект X.
Кто считает эти показатели? Или каждый разработчик в КД по совместительству бизнес-аналитик?
Однако с ростом компании удовлетворённость разработчиков снижается. Всё начинается с мелочей: увеличивается время сборки, добавляются зависимости, требуется вносить изменения в разных сервисах. Потом приходится разбираться, какая команда отвечает за какой сервис, мелкие миграции разрастаются из-за влияния на несколько команд, а потом даже иногда приходится заново создавать архитектуру для всей системы.
Судя по всему еще надо следить за бинес показателями компании, отслеживать всех конкуретнтов и их прогресс, постоянно общаться с инженерами из соседних команд и просчитывать всякие обоснования и ROI для всех планируемых фич. Интересно, на сон время остается?
12 самых «дорогих» компаний с указанием, является ли разработка ПО их центром получения прибыли. Корреляция или причинно-следственная связь?
Во-первых, я думаю Engineering в данном контексте используется в более широком смысле, чем просто "разработка ПО". Создание телефонов и автомобилей это тоже Engineering. Во-вторых, не понятно что вообще должен показывать этот график. То, что компании, которые разрабатывают инженерные решения, считают инжереный отдел источником прибыли? Вот это прям неожиданность.
Разумнее платить ему больше, давать больше свободы, позволяя делать больший вклад в бизнес.
Вывод мне нравится, статья конечно под вопросом
Ivan22
02.10.2023 15:01+2На практике часто оказывается так, что сеньор-разработчики занимаются следующим: от проведения совещаний 1:1 с менеджерами продуктов до участия в сессиях исследований клиентов. Но я видел и то, как новички-инженеры без малейших проблем работали напрямую с руководителями бизнеса.
Это плюс или минус? А если я не хочу никаких совещаний с менеджерами продуктов и тем более с руководителями бизнесов??? Я могу просто писать код с нормальным ТЗ??
Portnov
02.10.2023 15:01+2Ну т.е. в описанной идилии разработчики просто берут работу ПМа (организацию коммуникаций, распределение работ, отслеживание сроков) на себя. Вопрос, кто же получает зарплату за эту работу, в статье оставлен за скобками :)
(тут должна быть картинка с двоими из ларца).
Monnoroch
02.10.2023 15:01берут работу ПМа ... на себя
Судя по статье, еще аналитика, тестировщика, UX дизайнера и много еще чего.
Вопрос, кто же получает зарплату за эту работу, в статье оставлен за скобками
Это получется та же логика, что и фуллстак-разработчик должен работать 80 часов, ведь он и бэкэнд и фронтенд делает. Нет, у него одна ЗП, и он разделяет свои 40 часов на разные типы деятельности: что больше всего прямо сейчас нужно, тем и занимается.
xxxphilinxxx
02.10.2023 15:01Ну, фулстек - это все еще разработчик ПО, цельное понятие, и его обязанности мало отличаются от обязанностей более узких специалистов; а вот с аналитикой, контролем качества, менеджментом и т.д. уже скрестить сложнее. Вообще по ТК за совмещение должностей даже без увеличения рабочих часов полагается доплата, если, конечно, должность не прописана как "делать всё и вся" и работник на это согласился.
Monnoroch
02.10.2023 15:01В FAANG контрактах есть пункт "должностные обязанности" и в нем буквально написано "поддерживать и улучшать продукты компании". Такая вот должность, при чем для всех IC уровней одинаковая.
vvbob
02.10.2023 15:01+1Более оптимальное использование --> более высокая {автономность, зарплата}
Более оптимальное - это масло масляное, бывает либо оптимальное, либо не оптимальное. Оптимальность это экстремум функции по критериям оптимизации, он может быть только один, никакого "более" тут быть не может.
А в целом текст выглядит как очередной сектантский булшит инфоцыган. Ага, плоская структура и инженеры принимающие важные решения в компаниях из нескольких тысяч человек. Решения они принимают, а кто их исполняет? Если все такие самостоятельные, то что будем делать с другим инженером, который принятое решение выполнять не собирается и у него другой взгляд на вещи? Ладно, эти двое как-то договорятся, а что насчет остальных? А что будет с ответственностью? Если принятое каким-либо Васей решение в курилке окажется полной ерундой и приведет к миллионным убыткам, Васю поругают и продолжат прислушиваться к его ценным (как у того раввина из анекдота) идеям? Думаю если где-то что-то похожее и есть, то это просто показуха, не может огромная структура успешно конкурировать если в ней каждый инженер решает что важно, а что нет.
HenryPootle
02.10.2023 15:01+1Важные решения никто не заставляет принимать. Но общение по мелким вопросам в матричной организации гораздо проще, чем в иерархической. Но, зато в матричной и спросить потом не с кого за факап - "Мы пахали"(с) анекдот . Работал и там и там.
vvbob
02.10.2023 15:01Общение, это хорошо, но так и иерархической системе, хороший профессиональный менеджер никогда не принимает решения не проконсультировавшись со специалистами и не выслушав разные точки зрения, но в конечном итоге отвечает за него он сам, независимо от того что ему насоветовали спецы. А тут в описанных в статье фирмах - анархия какая-то, у семи нянек,
четырнадцать сисекдитя без глаза, у всех своё особо ценное мнение, все торопятся его высказать, но никто ни за что толком не отвечает.
(это я не поспорить, в качестве дополнения..)
rkfddf
02.10.2023 15:01Я работал в крупнейших технологических корпорациях, на довольно высоких должностях и не очень. И в небольших и крошечных фирмах тоже По пункту № 3 - прозрачность данных. Они везде прозрачные, как ты их не разделяй и не шифруй, какие грифы не вешай. Иначе невозможно работать, поэтому есле кому они нужны, то они их получат.
И по пункту № 5 - коммуникация. Для нормальной работы как раз нужно разграничивать и ограничивать круг общения работников любого уровня - даже директора при их возможностях забить сотрудниками актовые залы сильно ограничивают свой круг общения. Иначе невозможно работать. Есть приоритеты, планы и бюджеты и даже просто отвлекать сотрудников сильно вредно. Они могут быть и открыты и висеть на доске в коридоре, только не все их погут понять. И это перекрывается пунктом 3.
Остальное - вода, для наполнения статьи. Может иметь значение, может не иметь значения, зависит от других факторов, не перечисленных в статье. Называется корпоративной культурой и вырабатывается внутри коллектива, какого б он размера не был.
Survtur
Там на самом верху проект-инженер?