Наша специфика такова, что разработчикам необходимо писать много кода, в том числе и старшим. Для этого они должны хорошо ориентироваться в технологиях/фреймворках/библиотеках, которые мы используем.
Так вот, если сразу начинать с пункта 3, мы не сможем понять — человек сам может писать код, или он может только рассказывать "как космические корабли бороздят просторы Вселенной". К сожалению, второй вариант встречается довольно часто. Как вы понимаете, рассказать как устроен, например, FaceBook и разработать аналогичное решение — "две большие разницы" (С).
Таким образом получается, что до пункта 3 еще дойти надо. Если человек не знает, как в java коллекциями пользоваться — его мнение по архитектуре уже не такое ценное, просто потому, что понятно, что он руками вообще ничего не делал (потому как вопросы по технологии, мягко говоря, не сложные).
За 7 с чем то лет регулярных собеседований со стороны нанимателя родился следующий алгоритм:
Слушаем про опыт кандидата, например пару последних или самых интересных проектов, задаём вопросы пытаясь понять, что люди делали и в чем сложность и какова роль кандидата.
Гоняем кандидата по основам технологии (в нашем случае java) от простого к сложному, понимая глубину знаний.
Спрашиваем "А как бы ты сделал ..." — какое-нибудь решение из нашей практики.
Занимает обычно до 1.5 часа. Бывает, что с первых фраз видно хорошего человека, или наоборот, только к концу человек раскрывается.
Имел возможность наблюдать ее в действительно больших организациях (тысячи сотрудников). Да, она работает не супер-эффективно, но в условиях таких масштабов все остальное работает еще хуже.
К вопросу о двух руководителях. В крупных (да и не очень) компаниях применяется подход — линейный менеджер + операционный менеджер (в случае проектной деятельности — это проджект менеджер).
Линейный менеджер — это тот самый руководитель, который нанимает и увольняет людей и следит за их развитием. А проджект занимается управлением проектом. Говорить о том, что проджект не руководит ничем — нельзя, его власть просто ограничена его полем деятельности. Линейный тоже не император))
Очень хорошо, что вы занимаетесь системно.
Отжимания, приседания и подтягивания это действительно очень полезно. Движение — это жизнь.
НО. Вы должны определиться, где ваша основная цель: рост мышц, рост силовых показателей, поддержание существующей формы, и т.д.
После некоторого числа рост количества отжиманий/подтягиваний/приседаний й в повторении не будет давать видимого эффекта вообще. Поэтому в зависимости от вашей цели тренировочная программа должна быть разной.
Единственная общая часть — если вы действительно много сил отдаёте тренировкам, спортивное питание (протеин, bcaa, и т.д.) в меру вам не повредит. Будете быстрее восстанавливаться, результаты будут расти быстрее.
Я в целом посыл статьи понимаю, и согласен что ПМу тяжело живётся. К сожалению, я в таких ситуациях бывал. Я — тот самый начальник, который через голову ПМ пытается решить проблему напрямую с командой(( И что в этот момент чувствует ПМ я прекрасно понимаю. Но у меня свои задачи и некоторые проблемы решаются только так.
Понимаете, ведь так можно любую правильную ситуацию объяснить- команда неадекватная, токсичная и т.д. А ведь повсеместно именно управленческие просчёты и недоработки оборачиваются сверхурочными (по ночам перед релизом), конфликтами (делай быстрее, пусть даже лажу) и так далее. Не отрицая в полной мере посыла статьи, скажу — у руководителя работа такая, он ответственное лицо, валить все на команду нельзя.
Вот вы говорите — неприятие чужих. Но ведь задачи руководителя как раз: установить авторитет, установить правила, стать своим. Если он не может этого сделать "неформально" — зачастую формальные кнуты и пряники не помогут. Сколько не давай полномочий такому человеку — его мало кто будет воспринимать как главного.
Разработчики довольно часто думают, что руководитель не нужен, они все делают сами. Все потому, что его работа в основном не имеет "материального " результата. Однако, если правильно объяснить команде, в чем собственно состоят обязанности руководителя, и для чего он делает те или иные вещи — будет значительно проще.
Вопрос в том, что делать когда ПМ тоже токсичен для команды. Ведь не бывает дыма без огня, обычно люди проявляют негатив не просто так, а по делу, или как минимум имеют повод.
Не проблема распарсить код, но это влияет на время компиляции. Особенно если классов много.
Все зависит от задачи. Нам, как оказалось, оно не сильно нужно)
Даже не вдаваясь в подробности ( что внутри solr и elastic тот же lucene, и что на рынке bpmn движков звенящая пустота — jbpm да activiti) хочу задать вопрос.
А что Вы подразумеваете под масштабированием? Вы же наверное догадываетесь, что CUBA — это в основном корпоративные приложения, порталов- миллионников и соц-сетей на ней не делают. Не буду говорить, что проблем с масштабированием совсем нет, они есть, но лежат в другом месте, если можно так выразиться.
Первый пункт — действительно непростая задача. Конкретно для наших приложений мы решили ее построением дерева зависимостей при компиляции классов. В момент когда какой-то класс меняется мы ищем все классы, зависящие от него (которые его импортят) и компилируем их тоже. Это хорошо работает, особенно если мы перезагружаем сразу целый функциональный модуль. В одном из наших проектов мы весь пользовательский интерфейс делали динамически компилируемым.
Как автор похожего решения хотел бы задать вам несколько вопросов.
1. Как реализована совместная компиляция и обновление зависимостей? Например я компилирую класс, от которого зависят другие динамически скомпилированные классы?
2. Есть ли кэш классов, и где он хранится (если есть)?
3. Не пробовали ли вы подружить вашу загрузку классов со Spring, или чем-то похожим?
gtimelog действительно выглядит минималистично и приятно.
Однако, как я уже писал, Lori Timesheets решает немного другую задачу — учет времени на уровне компании. В нашем случае нет необходимости иметь данные по каждой минуте, проведенной сотрудником в курилке, на кухне или в соц. сетях. Есть необходимость постоянно собирать данные по затраченному на конкретные проекты времени, формировать статистические отчеты, считать зарплаты и переработки.
И как оказалось (или как нам кажется), таких систем не очень много. А подходящих именно нам на 100% мы ни одной не нашли.
Как было написано в начале этой статьи, мы несколько лет пользовались системой учета времени написанной не нами. Так что, технически, мы не писали систему учета времени первым делом. Просто старая система с самого начала не соответствовала нашим требованиям на 100% и со временем приносила все больше проблем. Когда наши мучения достигли определенной точки — мы решили систему поменять. Посмотрев на аналоги и оценив время разработки, взвесив все, мы решили, что дешевле и быстрее разработать ее на нашей собственной платформе. При таком подходе мы на 100% удовлетворили наши требования, и кроме того получили неплохой демонстрационный продукт.
Кроме того, Lori Timesheets в настоящее время является не трекером времени, а корпоративной системой учета рабочего времени. Ее задача состоит не только в том, чтобы позволять вводить время, но и в том, чтобы дать механизм контроля и утверждения введенных таймшитов, обеспечить разделение доступа к различным задачам и проектам, упростить сбор статистики. Возможно, со временем в Lori Timesheets появится модуль трекера времени, но пока таких потребностей у нас нет.
Позвольте и мне задать Вам вопрос: какой системой учета/трекинга времени пользуетесь Вы?
Проблема (на мой взгляд) в том, что интерфейс зачастую подогнан под требования Vaadin, то есть использует VerticalLayout, HorizontalLayout и так далее. Чтобы уйти от этого (например использовать кастомную html верстку), требуется усилий ничуть не меньше, чем верстать html с нуля на каком нибудь client-side фреймворке. То есть приложение вынужденно подгоняется под возможности фреймворка и имеет соответствующий вид. Для корпоративных приложений это приемлемо, для публичных — вряд ли.
Наша специфика такова, что разработчикам необходимо писать много кода, в том числе и старшим. Для этого они должны хорошо ориентироваться в технологиях/фреймворках/библиотеках, которые мы используем.
Так вот, если сразу начинать с пункта 3, мы не сможем понять — человек сам может писать код, или он может только рассказывать "как космические корабли бороздят просторы Вселенной". К сожалению, второй вариант встречается довольно часто. Как вы понимаете, рассказать как устроен, например, FaceBook и разработать аналогичное решение — "две большие разницы" (С).
Таким образом получается, что до пункта 3 еще дойти надо. Если человек не знает, как в java коллекциями пользоваться — его мнение по архитектуре уже не такое ценное, просто потому, что понятно, что он руками вообще ничего не делал (потому как вопросы по технологии, мягко говоря, не сложные).
За 7 с чем то лет регулярных собеседований со стороны нанимателя родился следующий алгоритм:
Слушаем про опыт кандидата, например пару последних или самых интересных проектов, задаём вопросы пытаясь понять, что люди делали и в чем сложность и какова роль кандидата.
Гоняем кандидата по основам технологии (в нашем случае java) от простого к сложному, понимая глубину знаний.
Спрашиваем "А как бы ты сделал ..." — какое-нибудь решение из нашей практики.
Занимает обычно до 1.5 часа. Бывает, что с первых фраз видно хорошего человека, или наоборот, только к концу человек раскрывается.
Имел возможность наблюдать ее в действительно больших организациях (тысячи сотрудников). Да, она работает не супер-эффективно, но в условиях таких масштабов все остальное работает еще хуже.
К вопросу о двух руководителях. В крупных (да и не очень) компаниях применяется подход — линейный менеджер + операционный менеджер (в случае проектной деятельности — это проджект менеджер).
Линейный менеджер — это тот самый руководитель, который нанимает и увольняет людей и следит за их развитием. А проджект занимается управлением проектом. Говорить о том, что проджект не руководит ничем — нельзя, его власть просто ограничена его полем деятельности. Линейный тоже не император))
Очень хорошо, что вы занимаетесь системно.
Отжимания, приседания и подтягивания это действительно очень полезно. Движение — это жизнь.
НО. Вы должны определиться, где ваша основная цель: рост мышц, рост силовых показателей, поддержание существующей формы, и т.д.
После некоторого числа рост количества отжиманий/подтягиваний/приседаний й в повторении не будет давать видимого эффекта вообще. Поэтому в зависимости от вашей цели тренировочная программа должна быть разной.
Единственная общая часть — если вы действительно много сил отдаёте тренировкам, спортивное питание (протеин, bcaa, и т.д.) в меру вам не повредит. Будете быстрее восстанавливаться, результаты будут расти быстрее.
Я в целом посыл статьи понимаю, и согласен что ПМу тяжело живётся. К сожалению, я в таких ситуациях бывал. Я — тот самый начальник, который через голову ПМ пытается решить проблему напрямую с командой(( И что в этот момент чувствует ПМ я прекрасно понимаю. Но у меня свои задачи и некоторые проблемы решаются только так.
Постоянно встречаю — зачем эти оценки, планы — трата времени. Мы делаем как делаем. Так что видимо не все понимают(
правильную — читать провальную
Понимаете, ведь так можно любую правильную ситуацию объяснить- команда неадекватная, токсичная и т.д. А ведь повсеместно именно управленческие просчёты и недоработки оборачиваются сверхурочными (по ночам перед релизом), конфликтами (делай быстрее, пусть даже лажу) и так далее. Не отрицая в полной мере посыла статьи, скажу — у руководителя работа такая, он ответственное лицо, валить все на команду нельзя.
Вот вы говорите — неприятие чужих. Но ведь задачи руководителя как раз: установить авторитет, установить правила, стать своим. Если он не может этого сделать "неформально" — зачастую формальные кнуты и пряники не помогут. Сколько не давай полномочий такому человеку — его мало кто будет воспринимать как главного.
Разработчики довольно часто думают, что руководитель не нужен, они все делают сами. Все потому, что его работа в основном не имеет "материального " результата. Однако, если правильно объяснить команде, в чем собственно состоят обязанности руководителя, и для чего он делает те или иные вещи — будет значительно проще.
Вопрос в том, что делать когда ПМ тоже токсичен для команды. Ведь не бывает дыма без огня, обычно люди проявляют негатив не просто так, а по делу, или как минимум имеют повод.
Все зависит от задачи. Нам, как оказалось, оно не сильно нужно)
А что Вы подразумеваете под масштабированием? Вы же наверное догадываетесь, что CUBA — это в основном корпоративные приложения, порталов- миллионников и соц-сетей на ней не делают. Не буду говорить, что проблем с масштабированием совсем нет, они есть, но лежат в другом месте, если можно так выразиться.
Первый пункт — действительно непростая задача. Конкретно для наших приложений мы решили ее построением дерева зависимостей при компиляции классов. В момент когда какой-то класс меняется мы ищем все классы, зависящие от него (которые его импортят) и компилируем их тоже. Это хорошо работает, особенно если мы перезагружаем сразу целый функциональный модуль. В одном из наших проектов мы весь пользовательский интерфейс делали динамически компилируемым.
1. Как реализована совместная компиляция и обновление зависимостей? Например я компилирую класс, от которого зависят другие динамически скомпилированные классы?
2. Есть ли кэш классов, и где он хранится (если есть)?
3. Не пробовали ли вы подружить вашу загрузку классов со Spring, или чем-то похожим?
gtimelog действительно выглядит минималистично и приятно.
Однако, как я уже писал, Lori Timesheets решает немного другую задачу — учет времени на уровне компании. В нашем случае нет необходимости иметь данные по каждой минуте, проведенной сотрудником в курилке, на кухне или в соц. сетях. Есть необходимость постоянно собирать данные по затраченному на конкретные проекты времени, формировать статистические отчеты, считать зарплаты и переработки.
И как оказалось (или как нам кажется), таких систем не очень много. А подходящих именно нам на 100% мы ни одной не нашли.
Поэтому-то мы и решили написать свою.
Как было написано в начале этой статьи, мы несколько лет пользовались системой учета времени написанной не нами. Так что, технически, мы не писали систему учета времени первым делом. Просто старая система с самого начала не соответствовала нашим требованиям на 100% и со временем приносила все больше проблем. Когда наши мучения достигли определенной точки — мы решили систему поменять. Посмотрев на аналоги и оценив время разработки, взвесив все, мы решили, что дешевле и быстрее разработать ее на нашей собственной платформе. При таком подходе мы на 100% удовлетворили наши требования, и кроме того получили неплохой демонстрационный продукт.
Кроме того, Lori Timesheets в настоящее время является не трекером времени, а корпоративной системой учета рабочего времени. Ее задача состоит не только в том, чтобы позволять вводить время, но и в том, чтобы дать механизм контроля и утверждения введенных таймшитов, обеспечить разделение доступа к различным задачам и проектам, упростить сбор статистики. Возможно, со временем в Lori Timesheets появится модуль трекера времени, но пока таких потребностей у нас нет.
Позвольте и мне задать Вам вопрос: какой системой учета/трекинга времени пользуетесь Вы?
Поправьте пожалуйста.
О конференции — будет интересно, с удовольствием бы посетил.