• Правила разработки в Яндекс.Здоровье
    0
    В нашем сервисе две миллисекунды, действительно, ничего не решают. В системах, для которых 2ms критичны, очевидно, совсем другие подходы и правила.
  • Правила разработки в Яндекс.Здоровье
    0
    В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.

    Ошиблись. Два с половиной ;)

    Контроль за архитектурой, периодические рефакторинги слабых мест — это очень важно, и мы их делаем. Если приводить аналогию — испачкаться не страшно. Плохо — не мыться и зарастать грязью. Мы периодически моемся :)

    Для сравнения, есть у нас пара мест в проекте, где за этим следили плохо — и там, да, ад. Но это не зависит от времени жизни проекта. Ад там появился буквально за пару месяцев.
  • Правила разработки в Яндекс.Здоровье
    0

    Спасибо :)

  • Правила разработки в Яндекс.Здоровье
    +1
    Наши врачи и мы сами придерживаемся принципов доказательной медицины. Поэтому ваш вопрос мне понятен и закономерен. Задача, как правильно отделять препараты с клинически доказанной эффективностью от препаратов, для которых двойное слепое плацебо-контролируемое исследование не проводилось, актуальна и обязательно будет решаться.
  • Правила разработки в Яндекс.Здоровье
    0
    Напишите в личку, пожалуйста — обязательно разберёмся.
  • Правила разработки в Яндекс.Здоровье
    0
    Тяжёлый вопрос, да. Просто оставлю ссылку на Джоэля здесь: habr.com/post/219651 — она очень в тему.

    От себя могу сказать, что переписывание на совсем новую технологию имеет смысл, только когда старая себя исчерпала как технически, так и экономически. Например, на поиск разработчика тратится полгода. Или добавление новой простой фичи занимает столько же ;). Но «исчерпала» — это очень растяжимое и неточное понятие, к сожалению.
  • Правила разработки в Яндекс.Здоровье
    0
    Я с вами очень во многом согласен.

    Во втором пункте главное, чтобы сериализация была абстрагирована от бизнес-логики. Я бы построил промежуточный слой абстракций, которые работают с API вне зависимости от сериализации, а потом реализовал её на быстром XML (кстати, в моём мире это не самый быстрый и лёгкий способ). В вероятном будущем, когда мы упираемся в производительность, меняется только слой сериализации на другую реализацию, оставляя всё остальное без изменений. Это как раз про два решения — быстрое, которое закладывает фундамент для правильного, и, собственно, правильное.

    Библиотека внутренних наработок хорошее дело. Поэтому код стоит писать так, чтобы компоненты были максимально отчуждаемыми, и, при желании, их можно было вынести и реюзать. Готов поспорить, что такой подход, нормально реализованный, тоже глобально не влияет на TTM фичи.

    Ну а по поводу отказа от кнопочки, которая тащит глобальное усложнение архитектуры — тут вообще, думаю, спорить смысла нет. Просто садимся вместе с продуктологом и понимаем, так ли сильно она важна. И, если действительно критично важна (такое тоже бывает в реальности), то тут уж делать особо нечего — придумываем, как можно такую кнопочку делать по-другому.

    В общем, я к тому, что быстрые решения могут быть правильными, а правильные — быстрыми ;). Опять же, очень важно понимать, что быстрые и неправильные тоже делать можно, но не забывать про них и как-то потом с ними разбираться.
  • Правила разработки в Яндекс.Здоровье
    +1
    Очень нечасто такое случается. Обычно — при старте какого-то нового проекта. И стек должен быть очень понятно обоснован. Например, сейчас пилим новый проект в инфраструктуре большого Яндекса, поэтому технологии там немного другие. В основном касается внутренних решений и ограничения, которое они накладывают на компоненты.
  • Правила разработки в Яндекс.Здоровье
    0
    Опять же с дисклеймером, что это всё только про Здоровье.

    Сначала понимаем, что конкретно хотим проверить, как это посчитать, и минимальное количество работы, которое для этого сделать надо. В общем, готовим дизайн эксперимента. Это делает продуктолог и техлиды в части аккуратного выбора костылей, чтобы они потом максимально пригодились.

    Потом собираем MVP из этих костылей, запускаем на пользователей и смотрим, соответствует ли поведение метрик нашей гипотезе. В зависимости от результатов, решаем — заменяем костыли на нормальное решение или выпиливаем всё навиг.

    Критерий (выпиливать / не выпиливать), кстати, довольно сложно формализуется, и (есть такой грех) не всегда устанавливается при старте эксперимента. Иногда и постфактум смотрим.

    Если фича совсем простая, но мы в неё верим — просто делаем, выкатываем и наблюдаем ступеньки на соответствующих графиках. Если ничего важного не упало, то оставляем.

    Ну и третий — самый неприятный случай, когда для эксперимента, действительно, надо много разработки разработать. Иногда и так случается, но крайне редко.
  • Правила разработки в Яндекс.Здоровье
    +2
    Насчёт прода — это ИМХО, одно из самого важного.

    Наша работа не ценна сама по себе. Продукт нашей работы — это не код и не архитектура. Наш продукт — это система, которая позволяет пользователю решить свою задачу. И я изо всех сил мотивирую команду мыслить именно решением задач пользователя. А код, который не в проде, задач пользователя решить не может…

    Другой вопрос — имеет ли смысл «навешивать» на программиста ещё и ответственность за «дотащить релиз». Я считаю, что да, это — часть мотивации думать не только о коде, но и о продукте. Но моё мнение тоже абсолютно субъективное ;)
  • Правила разработки в Яндекс.Здоровье
    +3
    Спасибо! Если видим такой потенциально редкий, но сложный в обработке кейс, кто-то из команды обычно задаёт вопрос, насколько он реален и масштабен. После этого обсуждаем минут 10-15 вместе с продуктологами. Если поймём, что достаточно редкий — просто оставляем в виде техдолга. Примерно как управление рисками.

    Были случаи, когда мы сильно ошибались, и приходилось всё-таки придумывать, как обрабатывать такие недоделки. Уже на ходу и в менее комфортных условиях. Но таких ситуаций на два порядка меньше, чем случаев, когда кейс так и не возник.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –1
    Я как-то договорился на существенно меньшее количество командировок и проработал в компании ещё 5 лет.

    Это нормально и даже хорошо. В моём понимании контроффер — про дополнительные деньги или более высокую позицию (или обещание их) в ответ на оффер. С командировками — решение проблемы, которая наконец-то вскрылась.

    К сожалению, в крупных компаниях больше ценится лояльность, чем профессиональные качества. Поэтому, выражать своё недовольство руководителю стратегически не выгодно.

    Вот совсем не понимаю это. Для меня сотрудник, который всегда со мной соглашается, даже если совсем не согласен, несравнимо менее ценен, чем сотрудник, который спорит там, где не согласен. И «шансов на продвижение» у человека, отстаивающего своё мнение, несравнимо больше.

    Наверное, у нас не «большая корпорация» просто ;)

    Например, в компании есть возможность перейти в другое подразделение. Тогда, при сокращении команды, заявивший такое намерение даже в прошлом, наверняка первым потеряет своё место и будет последним кандидатом на повышение.

    На сокращение или повышение должны влиять исключительно профессиональные компетенции разработчика.

    Ну, ещё бывает, что он просто не может найти общего языка с командой. В этом случае возможность такому сотруднику куда-то перейти — это очень хорошо для всех. Но, кажется, это не тот случай, который мы обсуждаем.

    В целом, лояльность — это про «считать компанию / отдал / продукт своим». В нелояльности при прочих равных нет ничего плохого, пока она не начинает приобретать открытую фазу и влиять на окружающих типа «Вася, я не понимаю, как вообще ты можешь в таком бессмысленном проекте как наш работать, да ещё и удовольствие от этого получать...». С таким да, надо аккуратно бороться (обычно «просто поговорить» помогает).
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    +1
    По разному реагируют. Часто помогают хорошему разработчику перейти в соседний отдел на более интересные задачи. В то же время, я (к сожалению) знаю руководителей, которые обвиняли в нелояльности и увольняли. Но, вероятно, это и к лучшему для конкретного сотрудника :)

    Но вообще, стандартный хороший алгоритм — понять, насколько устал, и не поможет ли, скажем, отпуск или другие задачи. Если всё очень плохо — помочь найти новую работу в рамках компании.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    +3
    серьезно? Как показывает мой опыт, ругать у начальства всегда получается лучше чем хвалить. Делают они это без затей, иногда с матом и огоньком.

    Сильно зависит. Мне гораздо чаще попадались такие, которые негатив не хотели и не умели.

    Вопрос, кто вы такой чтобы я делился своими личными переживаниями с вами?

    Это верно, да. Личными переживаниями точно делиться не обязательно. Но если есть какой-то негатив по отношению к рабочим вопросам: неинтересная задача, низкая зарплата, устал и хочу в отпуск, то делиться ими необходимо. Понимаю, что для описанного интроверта это очень сложно. Именно тут и должен эмоциональный интеллект руководителя работать. Но, опять же, это, блин, долгая и сложная работа — всё-таки понять, что не так и поправить.

    Про деньги. Ребята, давайте не будем утрировать. Если говорить про зарплату, то «Велика не будет» — это всё-таки не про наши реалии. Но сводить все потребности разработчика к деньгам такая же глупость, как и говорить, что признание, самосовершенствование и хорошие люди вокруг (есть такая известная пирамидка) можгут заменить адекватную зарплату.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    +1
    Не, автор, по-моему, немного другое имел в виду. Если с человеком хорошо и много работать, а он уходит в соседнюю компанию, то удерживать его с помощью денег сверху — так себе идея.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    0
    Да-да, я даже дисклеймер специально для этого написал ;)
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –6
    Попробую перефразировать: для того, чтобы в нашем стартапе (это важно!) занимать какую-то ответственную позицию (для примера — лида направления) нужно иметь моторчик в одном месте и умение чётко свои мысли выражать.

    Иначе направление просто не сможет работать с той скоростью, которую нам надо поддерживать, а ребята там будут страдать от овертаймов и постоянного давления (звучит не то, чтобы бело и пушисто, есть, что громко заклеймить, но как есть).

    Поэтому лид должен иметь качества, чтобы структурировать входящий поток задач, чётко сигнализировать о проблемах у себя и у ребят в команде, уметь находить с ними общий язык и в свою очередь понимать, что у них болит.

    Вот и получается, что если Ася не смогла / не решилась / не сочла нужным сформулировать мне своё желание стать лидом, то точно также она, вероятно, не сможет / не решится / не сочтёт нужным сформулировать проблемы направления или решить его боль.

    Как-то так
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    +1
    Я обычно вижу, когда человек чем-то озабочен. И да, иногда приходится долго разговаривать прежде, чем причина прояснится.

    Разговаривать регулярно надо. Раз в одну-две недели как минимум.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –5
    «сотрудник должен» и «сотрудник обязан»

    Ужасно :) Там «обязан» только в одном месте. Про встречи 1-1 и по отношению к руководителю.

    На самом деле, да, там есть пара категоричных мест, но они скорее про «отсутствие химии».
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –4
    Да. Самый мой грустный опыт — вижу, что человек заскучал и его подзавалило какими-то бессмысленными задачами.
    — вижу, что надоели текущие задачи
    — да, изрядно
    — давай, что-нибудь интересное дам? Смотри, есть A, B и С. «A» интересно?
    — ну да, интересно

    И через две недели оффер без вариантов…
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    0
    Тьфу, как текста много написалось. tl;dr: руководителю имеет смысл проявлять немножко чуткости и пытаться оценить, что сотруднику интересно и что могло бы хотеться, и немножко упреждающе делать соответствующие предложения. Особенно когда речь идёт о нематериальной мотивации.


    Надо бы этот абзац сверху поста вставить. Ровно о том и писал.

    Про «сам виноват» — утрированно вышло, да. Но тут как раз про то, нужно пытаться оценить, что нужно человеку, проявляя чуткость. И если при этому слышать в ответ «всё хорошо», хотя реально совсем не хорошо, то не получается «химии». Не получается нормально с человеком сработаться, он не доволен — ну зачем его держать.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –6
    Возможно, тут начинается наша специфика. У нас полно сложных задач и, если человек их хочет, он может их брать, условно, в любое время. С другой стороны, у нас нет, например, сложных алгоритмов или ML. И как-то не хочется обманывать ребят и говорить «подожди немного, они обязательно будут»
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –2
    Спасибо за адекватный комментарий :).

    Никакие офферы, контр-офферы или контр-контр-офферы не заставят меня считать ребят предателями. Особенно, если они пришли и прямо со мной разговаривают на эту тему. Более того, я считаю, что само по себе собеседование и получение оффера — это довольно полезный шаг для каждого. И да, было дело, что я сам убеждал одного из своих ребят не бояться и принимать оффер одной заграничной компании вместо того, чтобы отговаривать. Потому что ему в тот момент была нужна поддержка.

    Спросить «точно ли ты решил его принимать?» — это не про контр-оффер, а про нормальное обсуждение плюсов и минусов новой работы и сравнением её с текущей. И я очень рад, что ребята обсуждают её и иногда соглашаются остаться после вполне честного, без манипуляций, разговора.

    Ещё раз проговорить перспективы при таком разговоре — да. Перебивать цену и повышать зарплату (или тем более — обещать золотые горы) — нет.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –6
    Сейчас найти отличного фронта достаточно проблематично

    Про фронта знаю, поверьте :)

    Из-за такой политики есть риск потерять ценного сотрудника и искать замену месяцами.

    Сморите, тут всё довольно сложно. Делать контр-оффер, когда факт оффера уже случился — плохо и не честно по отношению к сотруднику. Типа, «ты внезапно стал молодец». Ценный сотрудник ценным стал не внезапно. И если на момент, когда ему делают оффер, он не ощущает своей ценности (в том числе и материальной) и не видит перспектив — это огромнейшая ошибка руководителя. Наверное, для исправления этой ошибки действительно можно использовать контр-офферы. Но именно такие контр-офферы мне глубоко неприятны.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –3
    Да, возможно так оно и есть :( Видимо, мне всегда везло работать с хорошими и (за небольшим исключением) достаточно компетентными людьми.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    +3
    Это чрезвычайная ситуация. Да, придётся повышать. Но (поскольку бюджет, очевидно, ограничен) повышать не тем, кто придёт с оффером, а наиболее ценным. И отпускать остальных.

    И, да, готов выслушать упрёки, что это не оптимально с точки зрения удержания команды и стратегия «повышать только с офферами» более выигрышная по количеству оставшихся людей.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –1
    При найме я говорю, что зарплата большая. Больше, чем у других с аналогичными скиллами. И что требования тоже будут высокими. А дальше кандидат сам делает выбор. Но в целом, да. Некоторые не готовы (и я их вполне понимаю и считаю их действия логичными).
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –1
    Ладно, раз уж предлагал честно…

    Вы, Роман, себе какую-то странную «модель тупого менеджера в вакууме» сочинили, а теперь пытаетесь меня в неё запихнуть :). А то, что невпихивается — допридумывали.

    Заходите как-нибудь в гости, расскажу, как у нас всё устроено. Потому что меня искренне пугает мир, в котором живут менеджеры-упыри и беспомощные программисты, который вы здесь нарисовали. И если мне их этого мира хотя бы одного разработчика удастся вытащить в реальность, то уже жизнь не зря прожита ;)
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    +3
    Ну, я тут вижу несколько подходов:
    1. Ничего не менять, сказать «молодец, что остался, рад, что ты такой лояльный»
    2. Сказать «молодец, что у тебя семья, вот тебе прямо сейчас +20%»
    3. Озвученный выше
    4. Пообещать повышение через X месяцев в рамках периодического пересмотра

    Мне из них больше всего нравится 3. Четвёртый с первого взгляда кажется тоже неплохим, но де-факто, он примерно совпадает со вторым, но только ещё и вместо повышения — обещание.

    P.S. Руководителю в этот момент хорошо бы озаботиться и посмотреть, не продолбал ли он рынок зарплат.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    +2
    Ну так тут задача руководителя — не доводить людей до состояния, когда они пойдут за контр-офферами. В том числе и своевременным повышением зарплаты. Основной смысл в том, что ждать и тянуть до тех пор, пока пойдут за офферами в другие компании — не очень честная и дальновидная стратегия.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –2
    «Конечно, жалко. Денег никогда не бывает много. Будь я один, я, может быть, и работал бы бесплатно, но при наличии семьи у меня нет на это морального права. Конкретно в этом случае я долго колебался, прежде чем принять окончательное решение. Все же мне действительно нравится наш коллектив.»

    — Ну в таком случае, давай прикинем, можно ли тебе их здесь получить и как это сделать.

    Но уже немного смахивает на манипуляцию, честно говоря.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –4

    Комментарий наполнен такой болью и обидой (видимо, на кого-то вполне конкретного), что просто не могу не ответить.


    Есть объём задач, которые надо делать, чтобы двигаться вперёд. И их нужно выполнять. Бывают такие задачи, которые надо делать прямо сейчас, но рук под которые не хватает. Иногда приходится искать человека месяцами. И, да, к сожалению реальность (которая не про мир розовых пони) такова, что задачи, которые делать некому, время от времени нужно делать asap.


    И в этом случае приходится взвешивать уже не зарплаты Васи и Пети, а время, за которое команда сможет эту задачу решить. Если для решения задачи единственным вариантом будет найм переплаченного специалиста, то я найму переплаченного специалиста.


    Во всех других вариантах нанимать переплаченного специалиста я не буду по причинам, которые описал.

  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –7
    Нет. Как не знают и зарплаты друг друга. Но ваш второй вопрос не соответствует цитате, которую вы привели, поэтому не вполне корректен ;).
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –6
    Интересные выводы o_O. Похоже, действительно, из заголовка ;)
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    –4
    Да, моя зарплата тоже «тест на публичность» проходит :). Но он субъективный, конечно. Поэтому правильно добавить «в моём понимании».
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    0
    Видимо, специфичная терминология Яндекса ;)
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    0
    Всё зависит от руководителя, конечно, но для меня это звучит дико. У нас несколько раз были такие случаи. Не уволили никого ;).
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    0
    На которОй. Поправил. Спасибо!
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    +1
    Хорошая реплика. Уточнил бы, «а 20%-то жалко, поди?» и смотрел, что скажет. Вполне возможно, что скажет, «да не, мне здесь нормально, всего хватает». Это значит, что ему хорошо и он мотивирован. Или скажет «я планирую их заработать и здесь» — опять же, отличный повод про это поговорить. В общем, я только за.

    На самом деле, любому разработчику следует время от времени на собеседования ходить. Чтобы понимать, что и где требуется и не застревать в «локальной компетентности» текущей компании. За одно — может чего полезного принесёт.
  • Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    +8
    Я несколько раз наблюдал, как после ухода ключевого сотрудника из небольшой компании, её штормило примерно неделю, а потом всё приходило в норму и было гораздо лучше, чем раньше ;).

    Но опять же, люди внезапно смертны. Поэтому в любом случае bus-factor надо делать хоть немного, но больше единицы.