Комментарии 19
В них есть проекты, менеджеры программ и менеджеры по разработке. Но по большей мере от инженеров ожидается, что...
Там на самом верху проект-инженер?
Похоже на восторженно-идеалистические картинки от Valve: каждый занимается тем проектом, каким хочет; и если что-то надоело, то вместе с рабочим местом перемещаешься к новой команде.
Потом вдруг проходит информация, что и у Valve есть дедлайны и сдачи продуктов. Просто наружу они выставляют красивую картинку. Для привлечения, так сказать.
Если же посмотреть со стороны в целом, то этому больше подходит термин "разводилово". Хотя, наверное, часть инженеров именно так и работают. Но, опасаюсь, далеко не все.
А теперь воплотим абстракции в реальность, но пойдем не идеальным, а ИМХО более вероятным путем.
Раз инженеры получают право голоса, этот голос должен стать частью процесса, а не хватанием за руку в последний момент, следовательно, у инженера появляются новые обязанности, при этом навыки управленца+PO+архитектора в комплекте не идут. Добавим эффективное самоуправление на уровне команды - уже минимум три роли с тимлидом и получаем требования как минимум на ведущего специалиста. Опционально добавим девопс без системных администраторов, работу линией техподдержки, дежурства, прочие процессуальные события, так что в итоге на работу собственно исходным инженером остается один-два дня в неделю. Добавим плоскую структуру компании, так что эти требования автоматически применяются абсолютно ко всем инженерам. Разумеется, бизнесу очень выгодно, когда в проекте есть люди "и швец, и жнец, и на дуде игрец", да еще и инициативные, но где набрать столько универсальных пассионариев, что делать с остальными и можно ли все еще называть такую позицию просто инженером?
Ну и пара очевидностей. Первая: если менеджер не интересуется мнением специалистов, допускает тупики, игнорирует смежные проекты, не имеет долгосрочных планов, то это некомпетентный менеджер. Вторая: стиль КД даже в тексте статьи очень часто соседствует со словом "стартап", а в стартапах так-то традиционный уклад с несколькими уровнями менеджеров встречается все же нечасто.
КД, КД, КД, КД, КД.
Все ждал слово «бирюзовый».
Чем крупнее компания, тем больше уровней иерархии. Если кто-то может привести пример компании крупнее 3к работников со всего парой уровней по вертикали - было бы интересно узнать. И разделение как раз происходит на уровне права принимать решение.
Кмк, в статье несколько идеализируется возможность инжерена в "компании в стиле КД" принимать серьёзные решение. Пожалуй, в более реалистичном сценарии инженер может дать обратную связь или предложение - и это послание будет эффективно услышано и рассмотрено.
Это утопия, когда команда на тысячи человек заявляет, что все равны, все могут принимать решение и т.д.
Плюсую. Известно, же как раз что в крупных компаниях наоборот много уровней иерархии инженеров, и высшие имеют большие полномочия в принятии решений, сравнимые в топ менеджерами.
Взять тот же МС, иерархия выглядет примерно так
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 ...
Я думаю, общий посыл статьи правильный, просто диавол как всегда в деталях..
Описанное больше походит на подразделение инновации. Некая сытая фирма инвестирует деньги в разработку нового и предоставляется свобода творчества. А вот когда система уже создана и ее нужно обслуживать, то все будет по классике. Тут уже личный вклад не влияет и приходят всякие мастера работы ртом, кумовство, игры престолов....
Я заметил, что компании Кремниевой долины часто «схватывают» то, что их традиционные конкуренты не могут даже понять и реализовать на практике — особенно в Европе. ... В свою очередь, компании Кремниевой долины могут платить (и платят!) больше, и могут получить больше пользы от одного и того же человека.
Я в компаниях КД не работал, но я слышал, что там люди очень любят работать по 60 часов в неделю и больше. Не удивительно, что они получают больше пользы от человека (особенно по сравнению с Европой, где с этим делом все довольно строго и люди работают положеные 40 часов в неделю)
В «традиционных» компаниях разработчики получают назначенные им рабочие задания, чаще всего через тикеты JIRA. Эти тикеты проверяются менеджером продукта или проекта и в них содержатся основные и ключевые подробности для выполнения работы. И от разработчиков ожидается, что они будут делать только это. Но в компании «в стиле КД» вы этого почти не увидите. В них есть проекты, менеджеры программ и менеджеры по разработке. Но по большей мере от инженеров ожидается, что они сами поймут, «как» выполнять работу, в том числе и принимать серьёзные решения.
Не совсем понятно, что мешает в тикете описать "что" нужно сделать, а "как" сделать может и разработчик решить. Или смысл в том, что вместо тикета разработчику надо просто в мессенджер скинуть идею из головы?
Компании «в стиле КД» мотивируют инженеров брать инициативу в свои руки. В них часто можно увидеть сервисы и функции, предложенные инженерами, или команды, тратящие время на выплату технического долга, который решили устранить люди в команде. И очень редко менеджеры говорят инженерам, что им нужно делать, разбивают их работу на мелкие части и занимаются микроменеджментом. Люди находятся на самоуправлении. В традиционных компаниях от разработчиков ожидается, что они будут выполнять назначенную им работу. В компаниях в стиле КД ожидается, что они будут решать проблемы бизнеса.
Даже если бизнес понимает, что технический долг - это его проблема, все равно есть определенный порог risk/reward между "сделать фичу и усилить позиции на рынке, но огрести позднее" и "пофиксить техдолг и не огрести позднее, но уступить конкурентам". Причем у каждого инженера этот порог будет своим. И у CEO компании тоже. Было бы интересно узнать, как в "КД-компаниях" решают данную проблему мнений.
В компаниях КД ожидается, что каждый участник команды понимает, на какую часть бизнеса и как влияет его работа. Цели команды редко заключаются лишь в выпуске фичи: они выбирают, уменьшить ли отток клиентов на 2%, выпустив Фичу 1, или повысить прогноз дохода на $10 миллионов в год, выпустив Проект X.
Кто считает эти показатели? Или каждый разработчик в КД по совместительству бизнес-аналитик?
Однако с ростом компании удовлетворённость разработчиков снижается. Всё начинается с мелочей: увеличивается время сборки, добавляются зависимости, требуется вносить изменения в разных сервисах. Потом приходится разбираться, какая команда отвечает за какой сервис, мелкие миграции разрастаются из-за влияния на несколько команд, а потом даже иногда приходится заново создавать архитектуру для всей системы.
Судя по всему еще надо следить за бинес показателями компании, отслеживать всех конкуретнтов и их прогресс, постоянно общаться с инженерами из соседних команд и просчитывать всякие обоснования и ROI для всех планируемых фич. Интересно, на сон время остается?
12 самых «дорогих» компаний с указанием, является ли разработка ПО их центром получения прибыли. Корреляция или причинно-следственная связь?
Во-первых, я думаю Engineering в данном контексте используется в более широком смысле, чем просто "разработка ПО". Создание телефонов и автомобилей это тоже Engineering. Во-вторых, не понятно что вообще должен показывать этот график. То, что компании, которые разрабатывают инженерные решения, считают инжереный отдел источником прибыли? Вот это прям неожиданность.
Разумнее платить ему больше, давать больше свободы, позволяя делать больший вклад в бизнес.
Вывод мне нравится, статья конечно под вопросом
На практике часто оказывается так, что сеньор-разработчики занимаются следующим: от проведения совещаний 1:1 с менеджерами продуктов до участия в сессиях исследований клиентов. Но я видел и то, как новички-инженеры без малейших проблем работали напрямую с руководителями бизнеса.
Это плюс или минус? А если я не хочу никаких совещаний с менеджерами продуктов и тем более с руководителями бизнесов??? Я могу просто писать код с нормальным ТЗ??
Ну т.е. в описанной идилии разработчики просто берут работу ПМа (организацию коммуникаций, распределение работ, отслеживание сроков) на себя. Вопрос, кто же получает зарплату за эту работу, в статье оставлен за скобками :)
(тут должна быть картинка с двоими из ларца).
берут работу ПМа ... на себя
Судя по статье, еще аналитика, тестировщика, UX дизайнера и много еще чего.
Вопрос, кто же получает зарплату за эту работу, в статье оставлен за скобками
Это получется та же логика, что и фуллстак-разработчик должен работать 80 часов, ведь он и бэкэнд и фронтенд делает. Нет, у него одна ЗП, и он разделяет свои 40 часов на разные типы деятельности: что больше всего прямо сейчас нужно, тем и занимается.
Ну, фулстек - это все еще разработчик ПО, цельное понятие, и его обязанности мало отличаются от обязанностей более узких специалистов; а вот с аналитикой, контролем качества, менеджментом и т.д. уже скрестить сложнее. Вообще по ТК за совмещение должностей даже без увеличения рабочих часов полагается доплата, если, конечно, должность не прописана как "делать всё и вся" и работник на это согласился.
Более оптимальное использование --> более высокая {автономность, зарплата}
Более оптимальное - это масло масляное, бывает либо оптимальное, либо не оптимальное. Оптимальность это экстремум функции по критериям оптимизации, он может быть только один, никакого "более" тут быть не может.
А в целом текст выглядит как очередной сектантский булшит инфоцыган. Ага, плоская структура и инженеры принимающие важные решения в компаниях из нескольких тысяч человек. Решения они принимают, а кто их исполняет? Если все такие самостоятельные, то что будем делать с другим инженером, который принятое решение выполнять не собирается и у него другой взгляд на вещи? Ладно, эти двое как-то договорятся, а что насчет остальных? А что будет с ответственностью? Если принятое каким-либо Васей решение в курилке окажется полной ерундой и приведет к миллионным убыткам, Васю поругают и продолжат прислушиваться к его ценным (как у того раввина из анекдота) идеям? Думаю если где-то что-то похожее и есть, то это просто показуха, не может огромная структура успешно конкурировать если в ней каждый инженер решает что важно, а что нет.
Важные решения никто не заставляет принимать. Но общение по мелким вопросам в матричной организации гораздо проще, чем в иерархической. Но, зато в матричной и спросить потом не с кого за факап - "Мы пахали"(с) анекдот . Работал и там и там.
Общение, это хорошо, но так и иерархической системе, хороший профессиональный менеджер никогда не принимает решения не проконсультировавшись со специалистами и не выслушав разные точки зрения, но в конечном итоге отвечает за него он сам, независимо от того что ему насоветовали спецы. А тут в описанных в статье фирмах - анархия какая-то, у семи нянек, четырнадцать сисек дитя без глаза, у всех своё особо ценное мнение, все торопятся его высказать, но никто ни за что толком не отвечает.
(это я не поспорить, в качестве дополнения..)
Я работал в крупнейших технологических корпорациях, на довольно высоких должностях и не очень. И в небольших и крошечных фирмах тоже По пункту № 3 - прозрачность данных. Они везде прозрачные, как ты их не разделяй и не шифруй, какие грифы не вешай. Иначе невозможно работать, поэтому есле кому они нужны, то они их получат.
И по пункту № 5 - коммуникация. Для нормальной работы как раз нужно разграничивать и ограничивать круг общения работников любого уровня - даже директора при их возможностях забить сотрудниками актовые залы сильно ограничивают свой круг общения. Иначе невозможно работать. Есть приоритеты, планы и бюджеты и даже просто отвлекать сотрудников сильно вредно. Они могут быть и открыты и висеть на доске в коридоре, только не все их погут понять. И это перекрывается пунктом 3.
Остальное - вода, для наполнения статьи. Может иметь значение, может не иметь значения, зависит от других факторов, не перечисленных в статье. Называется корпоративной культурой и вырабатывается внутри коллектива, какого б он размера не был.
Прикольно, буду теперь говорить про свою работу, что она «в стиле КД».
В комментариях много непонимания и несогласия про организацию рабочего процесса таким вот образом. Но для меня это обычное дело и из опыта вижу, что успеха и прогресса в этом реально больше. Зона влияния шире, рост как профессионала быстрее.
Но реальные минусы, с которыми приходится сталкиваться в российских реалиях: профита приносишь гораздо больше, а зарплатные вилки на рынке труда рассчитаны под специалистов, работающих не в «стиле КД». Ну и не везде готовы предоставлять свободу инициатив, т.к привычка работать в другой парадигме. Работу найти тот еще кейс из-за этого всего. Но когда находишь, довольны все.
И да, автор прав, работа по таскам точно не подходит.
Что понимают технологические компании и чего не понимают традиционные компании о разработчиках ПО