Привет! Спасибо за классный материал. Сам побывал пару лет руководителем и остались двойственные ощущения. ?
Ты пишешь, что убирать неруководительские задачи надо делегированием, автоматизацией и прочим. Основное все же делегирование, да? А что если нет желающих получить новые обязанности? Среднему разработчику вполне тепло и комфортно с текущим кругом обязанностей, а если что, найти другой проект проще простого. Вдохновлять к великим свершениям? На практике такого никогда не видел, хотя часто слышал про такой вариант.
Финансовые показатели — это супер нечувствительная метрика. Есть, конечно, исключения типа изменений, связанных с рекламой или если сайт занимается продажами. Но в массе свой, например, более удобный способ написания комментов на Хабре скорей всего не прокрасит деньги, но может прокрасить time spent.
Поэтому в общей массе придумывают другие метрики, которые поддерживают видение того, как должен развиваться продукт. Если всем ок такие метрики, то в чем проблема?
Спасибо за статью, стимулирующую дальнейшие размышления.
Я не в коем случае не хочу как-то обесценить труд автора и допускаю, что это только моя проблема, но я вообще не понимаю статей про DDD без конкретных примеров. А это примерно все статьи о DDD, что я видел на Хабре. Все они обмазывают тематику толстыми слоями терминов без толики объяснений практической пользы от введения каждого из них. То есть статьи не рассказывают "зачем", а рассказывают "как этим пользоваться".
К примеру в этой статье вводится понятие Единый язык, но что вообще такое конкретно? Это статья в базе знаний со списком терминов, которые должны использовать все от аналитика до тестировщика? Много слов вокруг термина, но ноль слов про суть.
Есть ли какой-то емкий гайд, туториал, что угодно про DDD с конкретным примером?
По заголовку ожидал анализа самих документов, а по факту автор собрала только шумиху вокруг. Не надо так.
Если почитать сами слитые документы, то ИМХО все претензии сводятся "ФБ недостаточно хорошо решает эту проблему". То есть все же по факту решает, но по оценочному суждению тёти недостаточно хорошо. Также по факту ФБ проводит соответствующие исследования и делает их доступными 80к+ сотрудникам внутри.
Да, обычно эти предложения заканчиваются - отличная идея, вот когда сделаете ВСЕООО, можем вам выделить рабочее время. Это просто утопия
Я описал свой опыт. Да, не всегда мои предложения проходили, и мне не выделяли ресурсов, но иногда проходили и помогали мне расти как в компании, так и личностно. Жаль, что у вас иной опыт Но вас же никто не держит на вашем месте, правда?
Вы так и не сказали, чем классическая схема плоха для сотрудника, а на аргумент с планированием сказали, что это сложно дляруководства.
Я бы уходил бы от этого противопоставления "дворяне и холопы", это непродуктивно на мой взгляд. Любая дихотомия в целом вредна.
Agile схема (в противовес классической) хороша в первую очередь для бизнеса. Уменьшает time to market. Тут жешь, кто первый того и тапки, тот собрал основную массу сливок. А если бизнесу хорошо, то и сотрудникам хорошо во всех планах. Если в вашей компании иначе, опять-таки, никто вас там насильно не держит :) Поверьте, есть нормальные в этом плане места.
я несколько раз встречал
Расскажите, пожалуйста, подробнее. Как это выглядит? О чем проект, какой размер, сколько людей задействовано, какие артефакты на выходе проектирования, сколько это занимало, кто привлекался? Я допускаю, что так бывает, но уверен, что это не тот подход, который подходит для всех проектов. Интересно послушать про такой опыт.
При этом текущие задачи никто не отменял, и естественно человек будет перерабатывать, чтобы привнести вам улучшение.
Не надо перерабатывать. Надо так: видишь возможность сделать лучше в проекте, собираешь данные (а это, правда, немного минут в день, но можно долго ждать ответов), что измениться, если это поправить. Готовишь предложение вида "если сделать это, будет вот так вот". Если все правильно понял и команда "купила", то тебе выделят какое-то количество рабочего времени на твоей проект. Вообще хорошо, если работы там, например, на пару человек и это так важно, что тебе part-time дают других коллег. Дальше это делаешь, и под конец будет тебе плюшка за инициативность, вклад, кооперацию и пр.
Все правильно, дотошное планирование не нужно, потому что выгоднее занести плетку в виде pr над каждым сотрудником и собирать плоды их работы раз в полгода. Действительно, это выгодно руководству, собственникам компании, но не ее сотрудникам.
Экий вы фантазер :) Я же говорю, вы хотите не то чтобы невозможного, а просто откровенно вредного для всех. Или у вас есть живые примеры того, что вы описываете? Был бы рад ознакомиться. Допускаю, что я просто за 13+ лет в ИТ не все еще видел :)
Да, вы правы, я во многом транслирую позицию Сережи, т.к. долго работал в Я и все это прочувствовал с обоих сторон (разработчик и руководитель).
Решение о премировании все равно остается за руководством, поэтому решения о любимчиках все так же актуальны.
Это как раз решается на этапе калибровки. Решения всегда принимаются коллективно. То есть минимизируется фактор "любимчика" одного конкретного руководителя.
pr усугубляет положение разработчиков "на поддержке" или тех, кто занимается рутинной, постоянной работой"
Абсолютно в любом проекте есть место для улучшений. Ни разу не видел обратного. Было бы желание. По крайней мере за 7+ лет в Яндексе не видел обратных ситуаций.
Решили применять pr потому что это выгодно компании и позволяет выжимать максимум...
Вопрос компенсации, конечно, важен и это много обсуждали. Вкратце, Яндекс дает большую компенсацию в горизонте 4-5 лет за счет акций и их постепенного вестинга. Также в Я понятно как расти, что очень важно.
Вообще не понял, причем тут процентный бонус
Вы пишите, что надо "Для всей команды, индивидуальное вознаграждение соразмерно текущей зарплате". Процентный бонус — это бонус, который дается как процент от зп. То есть если ты молодец — вот тебе 15% от твоей зп, это покрывает аругмент "соразмерно текуще плате".
Ну вы сейчас подтверждаете только тезис о том, что руководству проще и выгоднее не планировать и выжимать из сотрудников результат путем введения pr
Нет :) Я объяснил, почему это не работает (дотошное планирование) и что делается вместо.
Возможно, мы имеем в виду разный контекст. Я говорю про большие проекты с 150+ разработчиками и 1000+ внешних коллег.
Спасибо. 1. Этот пункт как раз одна из причин появления PR. До PR во многих компаниях (скажем так без открытия NDA) была статистически значимая разница в компенсации как для конкретных людей в рамках одного отдела, так и целых отделов. Люди все разные, бывают активные "продаваны себя", а есть просто ребята, которые хорошо делают свою работу и сильно себя не пропихивают. Последних довольно просто переманить повышением, и тогда компания теряет отличного кадра из-за недосмотра конкретного руководителя. Ну и есть еще ряд причин почему плохо повышать только тех, кто просит. Можно вспомнить также стат. значимую разницу в компенсации между мужчинами и женщинами. Про это просто тысячи исследований. Также (говоря про диспропорции между отделами) одни руководители просто чаще и выше поднимали своих подчиненных, чем другие, и объяснить это чем-то кроме индивидуальных особенностей руководителей было сложно. PR все вышеописанные ситуации сглаживает. Есть и минусы, конечно, но много где решили, что плюсы перевешивают.
2.1. Много где (в т.ч. в упомянутых в статьей компаниях) есть процентные бонусы от текущей зп. по итогам квартала-полугодия. 2.2. Это хорошо звучит на бумаге, но по факту современный крупный проект — это очень сложная система, с кучей неявных зависимостей, а продукт надо пилить прямо сейчас. Часто жертвуют предварительным планированием, в пользу раннего старта работ. Сокращение планирования до разумных пределов я считаю абсолютно нормальным, т.к., как я уже говорил, продукт постоянно меняется, есть куча бегущих в разные стороны команд и поэтому сделать предсказание вида "ну 3 этап будет длиннее предыдущего, т.к. скорей всего нам не успеют вовремя выделить ML-разработчика, также другие команды нафигачат фич и команда тестирования все не будет успевать, а еще в это время команда инфраструктуры может переводить нас на новые балансеры, что увеличит цикл разработки". Если аппелировать же к "профессионализму руководства", то это тупиковый путь. Искать виноватых в сложных проектах — это просто тратить кучу времени в пустоту. Куда эффективнее пытаться улучшить процессы на простых и понятных участках, типа "скорость выкатки новой фичи с т.з. разработки" или "среднее время зависания задач в статусах "готово к тестированию" и "тестируется".
Это процессы здорового человека, спору нет. Только performance review — это же ортогональная история, это больше фреймворк, а вы описываете реализацию. Причём эта реализация в целом фреймворко независимая :)
Честно говоря, гнобить что-то — это самое простое. Очевидно, идеальной системы вознаграждения не будет, пока принимают решения люди и нет объективных метрик измерения труда.
Автор, что вы предлагаете помимо абсолютно невнятного "бороться"?
Поддержу первое, что CSS :empty тут скорее вредит, т.к. размазывает логику между JS и CSS, и в целом это неожиданное поведение, что не только JS управляет тут видимостью. Нарушает one way flow. ИМХО, правильнее было бы все-таки вытащить внутренний флаг видимости из Footer.
Не поддержу про оптимизации. Тут автор статьи прав. Не надо плодить сущности без необходимости. Это усложняет, утяжеляет код без какой-либо причины. А еще мемоизацию можно неверно реализовать и породить кучу багов.
Информации много в сети. Посмотрите, пожалуйста, репортажи с полей того же Лядова (the люди на YouTube). У него есть выпуски из Северной и Южной. Думаю, обе серии стоит посмотреть для контраста.
В статье ж пишет, что экспертизу должны растить подчинённые. Твоя ж задача теперь это искать таланты и помогать им расти.
Техлид, в моем понимании, это как раз эксперт без команды, но с решающим словом с т. з. реализации.
Привет! Спасибо за классный материал. Сам побывал пару лет руководителем и остались двойственные ощущения. ?
Ты пишешь, что убирать неруководительские задачи надо делегированием, автоматизацией и прочим. Основное все же делегирование, да? А что если нет желающих получить новые обязанности? Среднему разработчику вполне тепло и комфортно с текущим кругом обязанностей, а если что, найти другой проект проще простого. Вдохновлять к великим свершениям? На практике такого никогда не видел, хотя часто слышал про такой вариант.
Финансовые показатели — это супер нечувствительная метрика. Есть, конечно, исключения типа изменений, связанных с рекламой или если сайт занимается продажами. Но в массе свой, например, более удобный способ написания комментов на Хабре скорей всего не прокрасит деньги, но может прокрасить time spent.
Поэтому в общей массе придумывают другие метрики, которые поддерживают видение того, как должен развиваться продукт. Если всем ок такие метрики, то в чем проблема?
АБТ эксперимент из ветки — это исключение. Обычно новую фичу закрывают флагом и открывают во время АБТ.
Спасибо за крутую статью!
А есть данные по западным компаниям, сколько в проценте на доход уходит на компенсацию сотрудникам?
Спасибо Падла и Аркадий. Посмотрю. Хорошо бы, правда, суть вещей в статьях раскрывать, а не кидаться книжками )
Спасибо за статью, стимулирующую дальнейшие размышления.
Я не в коем случае не хочу как-то обесценить труд автора и допускаю, что это только моя проблема, но я вообще не понимаю статей про DDD без конкретных примеров. А это примерно все статьи о DDD, что я видел на Хабре. Все они обмазывают тематику толстыми слоями терминов без толики объяснений практической пользы от введения каждого из них. То есть статьи не рассказывают "зачем", а рассказывают "как этим пользоваться".
К примеру в этой статье вводится понятие Единый язык, но что вообще такое конкретно? Это статья в базе знаний со списком терминов, которые должны использовать все от аналитика до тестировщика? Много слов вокруг термина, но ноль слов про суть.
Есть ли какой-то емкий гайд, туториал, что угодно про DDD с конкретным примером?
По заголовку ожидал анализа самих документов, а по факту автор собрала только шумиху вокруг. Не надо так.
Если почитать сами слитые документы, то ИМХО все претензии сводятся "ФБ недостаточно хорошо решает эту проблему". То есть все же по факту решает, но по оценочному суждению тёти недостаточно хорошо. Также по факту ФБ проводит соответствующие исследования и делает их доступными 80к+ сотрудникам внутри.
Что вы предлагаете то?
Я описал свой опыт. Да, не всегда мои предложения проходили, и мне не выделяли ресурсов, но иногда проходили и помогали мне расти как в компании, так и личностно. Жаль, что у вас иной опыт Но вас же никто не держит на вашем месте, правда?
Я бы уходил бы от этого противопоставления "дворяне и холопы", это непродуктивно на мой взгляд. Любая дихотомия в целом вредна.
Agile схема (в противовес классической) хороша в первую очередь для бизнеса. Уменьшает time to market. Тут жешь, кто первый того и тапки, тот собрал основную массу сливок. А если бизнесу хорошо, то и сотрудникам хорошо во всех планах. Если в вашей компании иначе, опять-таки, никто вас там насильно не держит :) Поверьте, есть нормальные в этом плане места.
Расскажите, пожалуйста, подробнее. Как это выглядит? О чем проект, какой размер, сколько людей задействовано, какие артефакты на выходе проектирования, сколько это занимало, кто привлекался? Я допускаю, что так бывает, но уверен, что это не тот подход, который подходит для всех проектов. Интересно послушать про такой опыт.
Не надо перерабатывать. Надо так: видишь возможность сделать лучше в проекте, собираешь данные (а это, правда, немного минут в день, но можно долго ждать ответов), что измениться, если это поправить. Готовишь предложение вида "если сделать это, будет вот так вот". Если все правильно понял и команда "купила", то тебе выделят какое-то количество рабочего времени на твоей проект. Вообще хорошо, если работы там, например, на пару человек и это так важно, что тебе part-time дают других коллег.
Дальше это делаешь, и под конец будет тебе плюшка за инициативность, вклад, кооперацию и пр.
Экий вы фантазер :) Я же говорю, вы хотите не то чтобы невозможного, а просто откровенно вредного для всех. Или у вас есть живые примеры того, что вы описываете? Был бы рад ознакомиться. Допускаю, что я просто за 13+ лет в ИТ не все еще видел :)
Да, вы правы, я во многом транслирую позицию Сережи, т.к. долго работал в Я и все это прочувствовал с обоих сторон (разработчик и руководитель).
Это как раз решается на этапе калибровки. Решения всегда принимаются коллективно. То есть минимизируется фактор "любимчика" одного конкретного руководителя.
Абсолютно в любом проекте есть место для улучшений. Ни разу не видел обратного. Было бы желание. По крайней мере за 7+ лет в Яндексе не видел обратных ситуаций.
Вопрос компенсации, конечно, важен и это много обсуждали. Вкратце, Яндекс дает большую компенсацию в горизонте 4-5 лет за счет акций и их постепенного вестинга. Также в Я понятно как расти, что очень важно.
Вы пишите, что надо "Для всей команды, индивидуальное вознаграждение соразмерно текущей зарплате". Процентный бонус — это бонус, который дается как процент от зп. То есть если ты молодец — вот тебе 15% от твоей зп, это покрывает аругмент "соразмерно текуще плате".
Нет :) Я объяснил, почему это не работает (дотошное планирование) и что делается вместо.
Возможно, мы имеем в виду разный контекст. Я говорю про большие проекты с 150+ разработчиками и 1000+ внешних коллег.
Спасибо.
1. Этот пункт как раз одна из причин появления PR. До PR во многих компаниях (скажем так без открытия NDA) была статистически значимая разница в компенсации как для конкретных людей в рамках одного отдела, так и целых отделов.
Люди все разные, бывают активные "продаваны себя", а есть просто ребята, которые хорошо делают свою работу и сильно себя не пропихивают. Последних довольно просто переманить повышением, и тогда компания теряет отличного кадра из-за недосмотра конкретного руководителя. Ну и есть еще ряд причин почему плохо повышать только тех, кто просит. Можно вспомнить также стат. значимую разницу в компенсации между мужчинами и женщинами. Про это просто тысячи исследований.
Также (говоря про диспропорции между отделами) одни руководители просто чаще и выше поднимали своих подчиненных, чем другие, и объяснить это чем-то кроме индивидуальных особенностей руководителей было сложно.
PR все вышеописанные ситуации сглаживает. Есть и минусы, конечно, но много где решили, что плюсы перевешивают.
2.1. Много где (в т.ч. в упомянутых в статьей компаниях) есть процентные бонусы от текущей зп. по итогам квартала-полугодия.
2.2. Это хорошо звучит на бумаге, но по факту современный крупный проект — это очень сложная система, с кучей неявных зависимостей, а продукт надо пилить прямо сейчас. Часто жертвуют предварительным планированием, в пользу раннего старта работ. Сокращение планирования до разумных пределов я считаю абсолютно нормальным, т.к., как я уже говорил, продукт постоянно меняется, есть куча бегущих в разные стороны команд и поэтому сделать предсказание вида "ну 3 этап будет длиннее предыдущего, т.к. скорей всего нам не успеют вовремя выделить ML-разработчика, также другие команды нафигачат фич и команда тестирования все не будет успевать, а еще в это время команда инфраструктуры может переводить нас на новые балансеры, что увеличит цикл разработки".
Если аппелировать же к "профессионализму руководства", то это тупиковый путь. Искать виноватых в сложных проектах — это просто тратить кучу времени в пустоту. Куда эффективнее пытаться улучшить процессы на простых и понятных участках, типа "скорость выкатки новой фичи с т.з. разработки" или "среднее время зависания задач в статусах "готово к тестированию" и "тестируется".
Ха, извини, это был коммент к предыдущей статье https://habr.com/ru/post/549322/
Это процессы здорового человека, спору нет. Только performance review — это же ортогональная история, это больше фреймворк, а вы описываете реализацию. Причём эта реализация в целом фреймворко независимая :)
Честно говоря, гнобить что-то — это самое простое. Очевидно, идеальной системы вознаграждения не будет, пока принимают решения люди и нет объективных метрик измерения труда.
Автор, что вы предлагаете помимо абсолютно невнятного "бороться"?
Поддержу первое, что CSS :empty тут скорее вредит, т.к. размазывает логику между JS и CSS, и в целом это неожиданное поведение, что не только JS управляет тут видимостью. Нарушает one way flow. ИМХО, правильнее было бы все-таки вытащить внутренний флаг видимости из Footer.
Не поддержу про оптимизации. Тут автор статьи прав. Не надо плодить сущности без необходимости. Это усложняет, утяжеляет код без какой-либо причины. А еще мемоизацию можно неверно реализовать и породить кучу багов.
Информации много в сети. Посмотрите, пожалуйста, репортажи с полей того же Лядова (the люди на YouTube). У него есть выпуски из Северной и Южной. Думаю, обе серии стоит посмотреть для контраста.
Если останутся вопросы, жду вас снова.
Я не готов с вами дальше спорить на эту тему. Я вижу, что это бесполезно.
Было бы видно, не было бы статьи.
Если у тебя 10 страниц текста, легко не заметить что-то необычное.