А вы отток за следующий год измеряли? Сравнили с оттоком за предыдущий? Именно среди тех, кого хотели сохранить, кто нормально работал.
ИМХО, такая среда ведёт к очень быстрому естественному отбору по определённым показателям. Что-то большое и общее такой командой уже не построить. Но если взаимодействие внутри команды не предполагается, то да, такое может работать. Ну или если на рынке большая очередь кандидатов на эту позицию ;)
Дима, привет :) ИМХО, любую попытку сгладить жёсткость и выдать обратную связь иначе, кроме как констатацией фактов, можно классифицировать как ту или иную манипулятивную технику.
А так-то ты же правильно пишешь во втором абзаце: тут же главное не загнать человека в защитную стойку, когда он будет защищаться и всё отрицать вместо того, чтобы признать проблему и обдумать причины. Ну или честно сказать, что проблемы не видит, но подумает про это.
Поэтому качество и способ донесения фидбэка полностью определяет, воспримет его сотрудник или нет.
В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.
Ошиблись. Два с половиной ;)
Контроль за архитектурой, периодические рефакторинги слабых мест — это очень важно, и мы их делаем. Если приводить аналогию — испачкаться не страшно. Плохо — не мыться и зарастать грязью. Мы периодически моемся :)
Для сравнения, есть у нас пара мест в проекте, где за этим следили плохо — и там, да, ад. Но это не зависит от времени жизни проекта. Ад там появился буквально за пару месяцев.
Наши врачи и мы сами придерживаемся принципов доказательной медицины. Поэтому ваш вопрос мне понятен и закономерен. Задача, как правильно отделять препараты с клинически доказанной эффективностью от препаратов, для которых двойное слепое плацебо-контролируемое исследование не проводилось, актуальна и обязательно будет решаться.
Тяжёлый вопрос, да. Просто оставлю ссылку на Джоэля здесь: habr.com/post/219651 — она очень в тему.
От себя могу сказать, что переписывание на совсем новую технологию имеет смысл, только когда старая себя исчерпала как технически, так и экономически. Например, на поиск разработчика тратится полгода. Или добавление новой простой фичи занимает столько же ;). Но «исчерпала» — это очень растяжимое и неточное понятие, к сожалению.
Во втором пункте главное, чтобы сериализация была абстрагирована от бизнес-логики. Я бы построил промежуточный слой абстракций, которые работают с API вне зависимости от сериализации, а потом реализовал её на быстром XML (кстати, в моём мире это не самый быстрый и лёгкий способ). В вероятном будущем, когда мы упираемся в производительность, меняется только слой сериализации на другую реализацию, оставляя всё остальное без изменений. Это как раз про два решения — быстрое, которое закладывает фундамент для правильного, и, собственно, правильное.
Библиотека внутренних наработок хорошее дело. Поэтому код стоит писать так, чтобы компоненты были максимально отчуждаемыми, и, при желании, их можно было вынести и реюзать. Готов поспорить, что такой подход, нормально реализованный, тоже глобально не влияет на TTM фичи.
Ну а по поводу отказа от кнопочки, которая тащит глобальное усложнение архитектуры — тут вообще, думаю, спорить смысла нет. Просто садимся вместе с продуктологом и понимаем, так ли сильно она важна. И, если действительно критично важна (такое тоже бывает в реальности), то тут уж делать особо нечего — придумываем, как можно такую кнопочку делать по-другому.
В общем, я к тому, что быстрые решения могут быть правильными, а правильные — быстрыми ;). Опять же, очень важно понимать, что быстрые и неправильные тоже делать можно, но не забывать про них и как-то потом с ними разбираться.
Очень нечасто такое случается. Обычно — при старте какого-то нового проекта. И стек должен быть очень понятно обоснован. Например, сейчас пилим новый проект в инфраструктуре большого Яндекса, поэтому технологии там немного другие. В основном касается внутренних решений и ограничения, которое они накладывают на компоненты.
Опять же с дисклеймером, что это всё только про Здоровье.
Сначала понимаем, что конкретно хотим проверить, как это посчитать, и минимальное количество работы, которое для этого сделать надо. В общем, готовим дизайн эксперимента. Это делает продуктолог и техлиды в части аккуратного выбора костылей, чтобы они потом максимально пригодились.
Потом собираем MVP из этих костылей, запускаем на пользователей и смотрим, соответствует ли поведение метрик нашей гипотезе. В зависимости от результатов, решаем — заменяем костыли на нормальное решение или выпиливаем всё навиг.
Критерий (выпиливать / не выпиливать), кстати, довольно сложно формализуется, и (есть такой грех) не всегда устанавливается при старте эксперимента. Иногда и постфактум смотрим.
Если фича совсем простая, но мы в неё верим — просто делаем, выкатываем и наблюдаем ступеньки на соответствующих графиках. Если ничего важного не упало, то оставляем.
Ну и третий — самый неприятный случай, когда для эксперимента, действительно, надо много разработки разработать. Иногда и так случается, но крайне редко.
Наша работа не ценна сама по себе. Продукт нашей работы — это не код и не архитектура. Наш продукт — это система, которая позволяет пользователю решить свою задачу. И я изо всех сил мотивирую команду мыслить именно решением задач пользователя. А код, который не в проде, задач пользователя решить не может…
Другой вопрос — имеет ли смысл «навешивать» на программиста ещё и ответственность за «дотащить релиз». Я считаю, что да, это — часть мотивации думать не только о коде, но и о продукте. Но моё мнение тоже абсолютно субъективное ;)
Спасибо! Если видим такой потенциально редкий, но сложный в обработке кейс, кто-то из команды обычно задаёт вопрос, насколько он реален и масштабен. После этого обсуждаем минут 10-15 вместе с продуктологами. Если поймём, что достаточно редкий — просто оставляем в виде техдолга. Примерно как управление рисками.
Были случаи, когда мы сильно ошибались, и приходилось всё-таки придумывать, как обрабатывать такие недоделки. Уже на ходу и в менее комфортных условиях. Но таких ситуаций на два порядка меньше, чем случаев, когда кейс так и не возник.
Я как-то договорился на существенно меньшее количество командировок и проработал в компании ещё 5 лет.
Это нормально и даже хорошо. В моём понимании контроффер — про дополнительные деньги или более высокую позицию (или обещание их) в ответ на оффер. С командировками — решение проблемы, которая наконец-то вскрылась.
К сожалению, в крупных компаниях больше ценится лояльность, чем профессиональные качества. Поэтому, выражать своё недовольство руководителю стратегически не выгодно.
Вот совсем не понимаю это. Для меня сотрудник, который всегда со мной соглашается, даже если совсем не согласен, несравнимо менее ценен, чем сотрудник, который спорит там, где не согласен. И «шансов на продвижение» у человека, отстаивающего своё мнение, несравнимо больше.
Наверное, у нас не «большая корпорация» просто ;)
Например, в компании есть возможность перейти в другое подразделение. Тогда, при сокращении команды, заявивший такое намерение даже в прошлом, наверняка первым потеряет своё место и будет последним кандидатом на повышение.
На сокращение или повышение должны влиять исключительно профессиональные компетенции разработчика.
Ну, ещё бывает, что он просто не может найти общего языка с командой. В этом случае возможность такому сотруднику куда-то перейти — это очень хорошо для всех. Но, кажется, это не тот случай, который мы обсуждаем.
В целом, лояльность — это про «считать компанию / отдал / продукт своим». В нелояльности при прочих равных нет ничего плохого, пока она не начинает приобретать открытую фазу и влиять на окружающих типа «Вася, я не понимаю, как вообще ты можешь в таком бессмысленном проекте как наш работать, да ещё и удовольствие от этого получать...». С таким да, надо аккуратно бороться (обычно «просто поговорить» помогает).
По разному реагируют. Часто помогают хорошему разработчику перейти в соседний отдел на более интересные задачи. В то же время, я (к сожалению) знаю руководителей, которые обвиняли в нелояльности и увольняли. Но, вероятно, это и к лучшему для конкретного сотрудника :)
Но вообще, стандартный хороший алгоритм — понять, насколько устал, и не поможет ли, скажем, отпуск или другие задачи. Если всё очень плохо — помочь найти новую работу в рамках компании.
серьезно? Как показывает мой опыт, ругать у начальства всегда получается лучше чем хвалить. Делают они это без затей, иногда с матом и огоньком.
Сильно зависит. Мне гораздо чаще попадались такие, которые негатив не хотели и не умели.
Вопрос, кто вы такой чтобы я делился своими личными переживаниями с вами?
Это верно, да. Личными переживаниями точно делиться не обязательно. Но если есть какой-то негатив по отношению к рабочим вопросам: неинтересная задача, низкая зарплата, устал и хочу в отпуск, то делиться ими необходимо. Понимаю, что для описанного интроверта это очень сложно. Именно тут и должен эмоциональный интеллект руководителя работать. Но, опять же, это, блин, долгая и сложная работа — всё-таки понять, что не так и поправить.
Про деньги. Ребята, давайте не будем утрировать. Если говорить про зарплату, то «Велика не будет» — это всё-таки не про наши реалии. Но сводить все потребности разработчика к деньгам такая же глупость, как и говорить, что признание, самосовершенствование и хорошие люди вокруг (есть такая известная пирамидка) можгут заменить адекватную зарплату.
Не, автор, по-моему, немного другое имел в виду. Если с человеком хорошо и много работать, а он уходит в соседнюю компанию, то удерживать его с помощью денег сверху — так себе идея.
Попробую перефразировать: для того, чтобы в нашем стартапе (это важно!) занимать какую-то ответственную позицию (для примера — лида направления) нужно иметь моторчик в одном месте и умение чётко свои мысли выражать.
Иначе направление просто не сможет работать с той скоростью, которую нам надо поддерживать, а ребята там будут страдать от овертаймов и постоянного давления (звучит не то, чтобы бело и пушисто, есть, что громко заклеймить, но как есть).
Поэтому лид должен иметь качества, чтобы структурировать входящий поток задач, чётко сигнализировать о проблемах у себя и у ребят в команде, уметь находить с ними общий язык и в свою очередь понимать, что у них болит.
Вот и получается, что если Ася не смогла / не решилась / не сочла нужным сформулировать мне своё желание стать лидом, то точно также она, вероятно, не сможет / не решится / не сочтёт нужным сформулировать проблемы направления или решить его боль.
ИМХО, такая среда ведёт к очень быстрому естественному отбору по определённым показателям. Что-то большое и общее такой командой уже не построить. Но если взаимодействие внутри команды не предполагается, то да, такое может работать. Ну или если на рынке большая очередь кандидатов на эту позицию ;)
А так-то ты же правильно пишешь во втором абзаце: тут же главное не загнать человека в защитную стойку, когда он будет защищаться и всё отрицать вместо того, чтобы признать проблему и обдумать причины. Ну или честно сказать, что проблемы не видит, но подумает про это.
Поэтому качество и способ донесения фидбэка полностью определяет, воспримет его сотрудник или нет.
Ошиблись. Два с половиной ;)
Контроль за архитектурой, периодические рефакторинги слабых мест — это очень важно, и мы их делаем. Если приводить аналогию — испачкаться не страшно. Плохо — не мыться и зарастать грязью. Мы периодически моемся :)
Для сравнения, есть у нас пара мест в проекте, где за этим следили плохо — и там, да, ад. Но это не зависит от времени жизни проекта. Ад там появился буквально за пару месяцев.
Спасибо :)
От себя могу сказать, что переписывание на совсем новую технологию имеет смысл, только когда старая себя исчерпала как технически, так и экономически. Например, на поиск разработчика тратится полгода. Или добавление новой простой фичи занимает столько же ;). Но «исчерпала» — это очень растяжимое и неточное понятие, к сожалению.
Во втором пункте главное, чтобы сериализация была абстрагирована от бизнес-логики. Я бы построил промежуточный слой абстракций, которые работают с API вне зависимости от сериализации, а потом реализовал её на быстром XML (кстати, в моём мире это не самый быстрый и лёгкий способ). В вероятном будущем, когда мы упираемся в производительность, меняется только слой сериализации на другую реализацию, оставляя всё остальное без изменений. Это как раз про два решения — быстрое, которое закладывает фундамент для правильного, и, собственно, правильное.
Библиотека внутренних наработок хорошее дело. Поэтому код стоит писать так, чтобы компоненты были максимально отчуждаемыми, и, при желании, их можно было вынести и реюзать. Готов поспорить, что такой подход, нормально реализованный, тоже глобально не влияет на TTM фичи.
Ну а по поводу отказа от кнопочки, которая тащит глобальное усложнение архитектуры — тут вообще, думаю, спорить смысла нет. Просто садимся вместе с продуктологом и понимаем, так ли сильно она важна. И, если действительно критично важна (такое тоже бывает в реальности), то тут уж делать особо нечего — придумываем, как можно такую кнопочку делать по-другому.
В общем, я к тому, что быстрые решения могут быть правильными, а правильные — быстрыми ;). Опять же, очень важно понимать, что быстрые и неправильные тоже делать можно, но не забывать про них и как-то потом с ними разбираться.
Сначала понимаем, что конкретно хотим проверить, как это посчитать, и минимальное количество работы, которое для этого сделать надо. В общем, готовим дизайн эксперимента. Это делает продуктолог и техлиды в части аккуратного выбора костылей, чтобы они потом максимально пригодились.
Потом собираем MVP из этих костылей, запускаем на пользователей и смотрим, соответствует ли поведение метрик нашей гипотезе. В зависимости от результатов, решаем — заменяем костыли на нормальное решение или выпиливаем всё навиг.
Критерий (выпиливать / не выпиливать), кстати, довольно сложно формализуется, и (есть такой грех) не всегда устанавливается при старте эксперимента. Иногда и постфактум смотрим.
Если фича совсем простая, но мы в неё верим — просто делаем, выкатываем и наблюдаем ступеньки на соответствующих графиках. Если ничего важного не упало, то оставляем.
Ну и третий — самый неприятный случай, когда для эксперимента, действительно, надо много разработки разработать. Иногда и так случается, но крайне редко.
Наша работа не ценна сама по себе. Продукт нашей работы — это не код и не архитектура. Наш продукт — это система, которая позволяет пользователю решить свою задачу. И я изо всех сил мотивирую команду мыслить именно решением задач пользователя. А код, который не в проде, задач пользователя решить не может…
Другой вопрос — имеет ли смысл «навешивать» на программиста ещё и ответственность за «дотащить релиз». Я считаю, что да, это — часть мотивации думать не только о коде, но и о продукте. Но моё мнение тоже абсолютно субъективное ;)
Были случаи, когда мы сильно ошибались, и приходилось всё-таки придумывать, как обрабатывать такие недоделки. Уже на ходу и в менее комфортных условиях. Но таких ситуаций на два порядка меньше, чем случаев, когда кейс так и не возник.
Это нормально и даже хорошо. В моём понимании контроффер — про дополнительные деньги или более высокую позицию (или обещание их) в ответ на оффер. С командировками — решение проблемы, которая наконец-то вскрылась.
Вот совсем не понимаю это. Для меня сотрудник, который всегда со мной соглашается, даже если совсем не согласен, несравнимо менее ценен, чем сотрудник, который спорит там, где не согласен. И «шансов на продвижение» у человека, отстаивающего своё мнение, несравнимо больше.
Наверное, у нас не «большая корпорация» просто ;)
На сокращение или повышение должны влиять исключительно профессиональные компетенции разработчика.
Ну, ещё бывает, что он просто не может найти общего языка с командой. В этом случае возможность такому сотруднику куда-то перейти — это очень хорошо для всех. Но, кажется, это не тот случай, который мы обсуждаем.
В целом, лояльность — это про «считать компанию / отдал / продукт своим». В нелояльности при прочих равных нет ничего плохого, пока она не начинает приобретать открытую фазу и влиять на окружающих типа «Вася, я не понимаю, как вообще ты можешь в таком бессмысленном проекте как наш работать, да ещё и удовольствие от этого получать...». С таким да, надо аккуратно бороться (обычно «просто поговорить» помогает).
Но вообще, стандартный хороший алгоритм — понять, насколько устал, и не поможет ли, скажем, отпуск или другие задачи. Если всё очень плохо — помочь найти новую работу в рамках компании.
Сильно зависит. Мне гораздо чаще попадались такие, которые негатив не хотели и не умели.
Это верно, да. Личными переживаниями точно делиться не обязательно. Но если есть какой-то негатив по отношению к рабочим вопросам: неинтересная задача, низкая зарплата, устал и хочу в отпуск, то делиться ими необходимо. Понимаю, что для описанного интроверта это очень сложно. Именно тут и должен эмоциональный интеллект руководителя работать. Но, опять же, это, блин, долгая и сложная работа — всё-таки понять, что не так и поправить.
Про деньги. Ребята, давайте не будем утрировать. Если говорить про зарплату, то «Велика не будет» — это всё-таки не про наши реалии. Но сводить все потребности разработчика к деньгам такая же глупость, как и говорить, что признание, самосовершенствование и хорошие люди вокруг (есть такая известная пирамидка) можгут заменить адекватную зарплату.
Иначе направление просто не сможет работать с той скоростью, которую нам надо поддерживать, а ребята там будут страдать от овертаймов и постоянного давления (звучит не то, чтобы бело и пушисто, есть, что громко заклеймить, но как есть).
Поэтому лид должен иметь качества, чтобы структурировать входящий поток задач, чётко сигнализировать о проблемах у себя и у ребят в команде, уметь находить с ними общий язык и в свою очередь понимать, что у них болит.
Вот и получается, что если Ася не смогла / не решилась / не сочла нужным сформулировать мне своё желание стать лидом, то точно также она, вероятно, не сможет / не решится / не сочтёт нужным сформулировать проблемы направления или решить его боль.
Как-то так