Для большинства видеорегистраторов это верно. Наверное, в 90% всех регистраторов именно так. Хотя для других категорий потребительской электроники это анахронизм.
Вообще-то, Playme – российский бренд, созданный специально для продажи автомобильных устройств на территории России и в странах СНГ. Под этим брендом продаются как OEM, так и ODM модели, собранные в Китае (отдельные устройства) и на заводах Южной Кореи (комбо-устройства). Первые модели сигнатурных РД действительно появились под брендом Playme (Silent и Soft) — но вот насколько к ним имеет отношение сама компания — вопрос.
Качество у них достаточно неплохое, но цены несколько завышены — видимо, пытаются таким образом себя спозиционировать как премиум-бренд — как тот же AdvoCam сейчас или Carcam раньше.
У нас какая идея? Сколько показал — столько и потратил реально. Показывают они по 40 часов в неделю, значит и тратят на работу столько же.
Наши процессы организованы таким образом, чтобы сотрудники в своей работе не зависели от коллег: сел — и работаешь. Таким образом когда и сколько работать отдается на откуп самим сотрудникам. Сложно быть сфокусированным 6 часов подряд? Работай с перерывами по 4. Или по 2. Днем или ночью. На буднях или по выходным. Нам все-равно. Главное чтобы результат был.
Эффективный сотрудник будет делать больше, получать столько же. А через пару-тройку кварталов ему, как человеку с высокой производительностью, предложат пройти тест на следующую позицию, на которой оплата в 2 раза выше.
Так что эффективным сотрудникам есть смысл работать 40 часов. Да и прости сидеть и тупить в монитор не всем нравится.
Да, конечно есть. И у меня лично, и у каждого сотруника в компании. Мой карьерный рост — это SVP of Engineering and Operations. Данная позиция появилась только с этого года — растем быстро, начальству приходится выстраивать под собой больше линеек.
Вышеупомянутый юнит-тестировщик может стать лидом, например, или архитектором (в своем направлении)?
У нас нет понятия «лид». Юнит-тестировщий — это обычно самый низкий грейд, Software Engineer, получающий $15/час. Если юнит-тестировщик из месяца в месяц показывает отличную производительность, то его начальник рекомендут ему пройти тест на Software Architect, по результату которого юнит-тестировщий уже начинает получать $30/час и будет рекомендован в команду, где нужны более сильные исполнители.
При восьмичасовом рабочем дне реальная производительность человека 4-5 часов, у меня больше 6 ни разу не удалось показать. Значит ли это, что у вас люди реально логируют часов по 5 в день, или же они колбасят в день часов по 10, чтобы получить те самые залогированные 8 часов?
Я про свой опыт отвечу. Сажусь после завтрака за комп, включаю ворк-смарт тул — и пошел работать. Совещания, почта, документация, эскалации, опять совещания. Всё на сегодня сделал, выключил ворксмарт, посмотрел — 8 часов накапало. А то и 10. Если 10 — то завтра можно чуть меньше поработать.
Можно успеть и за 30, но если отрепортить только 30 часов, то и зарплата придет за 30 часов. Поэтому вам самому выгоднее отработать 40 часов. А если вы за 40 часов сделаете больше чем ваши коллеги, то вы попадает по top-performers, откуда вас могут повысить на следующий грейд с соответствующим увеличением зп в 2 раза.
Классный вопрос, достойный отдельной статьи, а то и нескольких.
Я сам, до того как присоединился к Aurea, был апологетом Скрама, DevOps, и так далее. Теперь, имея возможность сравнить Scrum с WSPro (наша собственная методология), я могу сказать что для больших компаний, ориентированных на быстрый рост с сохранением производительности, Scrum не тянет. Уж слишком Scrum-команды получаются изолированными друг от друга и делают всё кто во что горазд. Внедрить одинаковые процессы, технологии, тулы в 100 скрам-команд практически невозможно. А это значит, что получить унифицированную метрику между командами и людьми из разных комнад не получится. Более того, даже внутри одной команды объективно отследить кто тут лучший работник очень сложно. А это в свою очередь не дает понять какая же из Скрам-команд лучше, и почему же они лучше, и, соответственно, нет возможности внедрить лучшие практики из этой команды в другие.
Да, такая позиция есть. У нас в продуктовой организации 3 линейки: L3, L2 и L1.
L3 — это как раз те, про кого вы спрашиваете.
L2 — пишут технические спецификации, но еще не достаточные для разработки по ним.
L1 — это уже почти технари. По их спекам «и дурак» напишет.
Реально хороших и профессиональных Менеджеров и Бизнесменов с большой буквы ооочень мало, но они очень нужны.
А Вы уверены что они очень нужны? Вот я тоже так думал, пошел работать в одну из дочек Сбера. Позиция Операционный директор с перспективой стать Ген Диром. Думал, сейчас горы сверну, внедрю по всей России электронный документооборот… ага, сейчас. Все коллеги-начальники вокруг думают только о себе и своих бонусах, и, следовательно, очень много политики. Чтобы работать в таких компаниях — это надо иметь соответствующий характер. Я не шмогла. Уволился через 8 месяцев и потом еще 2 месяца отходил от этого опыта, тупо валяясь на диване или играя в комп. Мда.
Мой бывший начальник из ГридДинамикс до сих пор надо мной подтрунивает по этому поводу :) Типа ну что, поднял Российский IT? :)
У нас в компании есть 2 типа СЕМов — ПродактСЕМ и КорСЕМ.
ПродактСЕМ больше ориентированы на классический Project Management: scope management, release management, timelines, risks/issues management, очень много общения с «братскими» организациями — SaaSOps, Product Management, Support, Professional Services. ПродактСЕМы заказывают выполнение работы у КорСЕМов.
КорСЕМы больше ориентированы на то, что бы поставить процессы и натренировать людей в команде таким образом, чтобы на выходе было хорошее качество и производительность команды постоянно росла. То есть это более технический человек, который хорошо разбирается в технологиях и инженерных практиках. Я там выше расписал чуть подробнее.
Если у вас технические специалисты не могут получать больше, чем менеджеры, то действительно сильных технических специалистов у вас никогда не будет.
Вот купили мы в июне прошлого года JiveSoftware — компанию, которая базируется в Портлэнде — считайте та же Силиконовая долина. Для девелоперов там были созданы все условия — высокие зарплаты, отличный офис в центре города, 5 сортов разливного пива(!!!) в офисе, не говоря уже о еде, треннингах, массажистах и так далее. То есть инженеры у них работали очень даже квалифицированные (могли себе позволить заманить). Так вот — после покупки этой компании мы стали ставить своих иженеров ($50/час которые) в пары с Джайверами — всего за 3 месяца мы наняли 100 новых сотрудников через Кроссовер. И знаете что? Все Джайверы сказали, что наши ребята очень сильные и с ними здорово работать. Я специально постоянно всех спрашивал, так как самому было интересно сравнить наших ребят с коллегами из крутой компанией в Силиконовой долине.
Пришел начальник транспортного цеха. Вопрос понравился.
У нас в компании каждый СЕМ должен хорошо разбираться не только в ProjectManagement'е, но и иметь сильные знания в технологиях и инженерных практиках: как правильно организовать код-ревью, continuous integration, test driven development, branching strategy, deployment automation, environment provisioning automation, и так далее.
Ну а поддерживать/улучшать свои технические знания ему помогает одна из его прямых обязанностей, которую мы называем «Gemba Walk», а Toyota — «Walk the line»: чтобы менеджер имел возможность грамотно улучшить процесс — он должен видеть этот процесс вживую. В Toyota менеджеров посылают на заводы, где они ходят за рабочими и смотрят что и как они делают. Мы же от своих менеджеров ожидаем, что раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием. Это позволяет им разобраться почему top-performers работают так быстро, научиться у них, а потом изменять процессы/тулы/подходы/практики соответственно и обучать уже всю команду.
А еще, так как один СЕМ обычно поддерживает несколько продуктов (от 5 до 10), то у него есть возможность выучить и разные технологии, увидеть в деле и сравнить различные архитектурные подходы. В общем, поле для профессионального роста просто огромное.
Да, раз в неделю выбираю одного скип-левел и примерно час общаюсь с ним, разбираясь в деталях работы. Обычно беру ту область, где на текущий момент надо срочно что-то улучшить.
А можно примеры Quality Bars? Конечно. Ничего сверхъестественного в них нет. Вот, например, QB для техподдержки на открытие задачи в инжиниринг:
Description
— Who is involved
— What issue occurred
— When the issue occurred
— Where the issue occured (platform, product, device, OS)
— How the issue occured — steps to reproduce
Expected results vs. actual results:
— What is the expected result
— What is the actual result
— Screenshots or log files proving the issue occured
Тут главное, что у нас отслеживается % принятия задач следующей командой. Когда только внедрили такой QB — отказов было очень многои мы активно обучали поддержку правильно вводить данные. Теперь отказ снизили до 8% и продолжаем снижать. В итоге инженерам нет необходимости общаться с техподдержкой, проясняя детали — вся необходимая информация есть в задаче.
И, конечно, все QBs постоянно улучшаются базируясь на обратной связи.
А еще просто приятно работать в компании, которая успешна финансово и не зависит ни от каких «раундов инвестиций». И очень интересен опыт участия в покупках с другой стороны — когда ты покупаешь, а не когда тебя. Вот где все веселье.
Почему 200? Я только что перечитал свои комментарии — фигурируют цифры в 2000 и 3000 :) Когда инжиниринг организация централизованная и обслуживает более десятка компаний одновременно, а ты управляешь разработкой только 25 продуктами из 100, и при этом организация еще и растет как на дрожжах — сложно уследить сколько реально сотрудников работает на данный момент. Вчера уточник у начальника — уже к отметке 5000 подбираемся. И все 100% — удаленно через Кроссовер.
Более года назад, когда я устраивался, они были другими чем сейчас. Конкретно уже не сформулирую, но вот что-то типа такого:
Что происходит с производительностью команды при ее росте? Я помню ответил тогда, что производительность каждого отдельного сотрудника падает из-за необходимости координации своих действий с коллегами, тогда как объем выполненных командой работ растет при условии, что поставлены правильные процессы. Это сейчас, проработав в Aurea больше года, я понимаю, что был наивен :) Собственными руками ращу несколько команд, и при этом растет производительность каждого сотрудника.
Еще был очень интересный вопрос по поводу планирования проектов. Давалось описание проекта, который надо реализовать и дополнительная информация с техническими и процессными требованиями. Далее 4 менеджера составили 4 различных проектных плана. Моя задача была расставить эти планы от лучшего к худшему и объяснить — почему.
Для большинства видеорегистраторов это верно. Наверное, в 90% всех регистраторов именно так. Хотя для других категорий потребительской электроники это анахронизм.
Качество у них достаточно неплохое, но цены несколько завышены — видимо, пытаются таким образом себя спозиционировать как премиум-бренд — как тот же AdvoCam сейчас или Carcam раньше.
Наши процессы организованы таким образом, чтобы сотрудники в своей работе не зависели от коллег: сел — и работаешь. Таким образом когда и сколько работать отдается на откуп самим сотрудникам. Сложно быть сфокусированным 6 часов подряд? Работай с перерывами по 4. Или по 2. Днем или ночью. На буднях или по выходным. Нам все-равно. Главное чтобы результат был.
Так что эффективным сотрудникам есть смысл работать 40 часов. Да и прости сидеть и тупить в монитор не всем нравится.
Да, конечно есть. И у меня лично, и у каждого сотруника в компании. Мой карьерный рост — это SVP of Engineering and Operations. Данная позиция появилась только с этого года — растем быстро, начальству приходится выстраивать под собой больше линеек.
У нас нет понятия «лид». Юнит-тестировщий — это обычно самый низкий грейд, Software Engineer, получающий $15/час. Если юнит-тестировщик из месяца в месяц показывает отличную производительность, то его начальник рекомендут ему пройти тест на Software Architect, по результату которого юнит-тестировщий уже начинает получать $30/час и будет рекомендован в команду, где нужны более сильные исполнители.
Я про свой опыт отвечу. Сажусь после завтрака за комп, включаю ворк-смарт тул — и пошел работать. Совещания, почта, документация, эскалации, опять совещания. Всё на сегодня сделал, выключил ворксмарт, посмотрел — 8 часов накапало. А то и 10. Если 10 — то завтра можно чуть меньше поработать.
Я сам, до того как присоединился к Aurea, был апологетом Скрама, DevOps, и так далее. Теперь, имея возможность сравнить Scrum с WSPro (наша собственная методология), я могу сказать что для больших компаний, ориентированных на быстрый рост с сохранением производительности, Scrum не тянет. Уж слишком Scrum-команды получаются изолированными друг от друга и делают всё кто во что горазд. Внедрить одинаковые процессы, технологии, тулы в 100 скрам-команд практически невозможно. А это значит, что получить унифицированную метрику между командами и людьми из разных комнад не получится. Более того, даже внутри одной команды объективно отследить кто тут лучший работник очень сложно. А это в свою очередь не дает понять какая же из Скрам-команд лучше, и почему же они лучше, и, соответственно, нет возможности внедрить лучшие практики из этой команды в другие.
L3 — это как раз те, про кого вы спрашиваете.
L2 — пишут технические спецификации, но еще не достаточные для разработки по ним.
L1 — это уже почти технари. По их спекам «и дурак» напишет.
Как-то так.
А Вы уверены что они очень нужны? Вот я тоже так думал, пошел работать в одну из дочек Сбера. Позиция Операционный директор с перспективой стать Ген Диром. Думал, сейчас горы сверну, внедрю по всей России электронный документооборот… ага, сейчас. Все коллеги-начальники вокруг думают только о себе и своих бонусах, и, следовательно, очень много политики. Чтобы работать в таких компаниях — это надо иметь соответствующий характер. Я не шмогла. Уволился через 8 месяцев и потом еще 2 месяца отходил от этого опыта, тупо валяясь на диване или играя в комп. Мда.
Мой бывший начальник из ГридДинамикс до сих пор надо мной подтрунивает по этому поводу :) Типа ну что, поднял Российский IT? :)
ПродактСЕМ больше ориентированы на классический Project Management: scope management, release management, timelines, risks/issues management, очень много общения с «братскими» организациями — SaaSOps, Product Management, Support, Professional Services. ПродактСЕМы заказывают выполнение работы у КорСЕМов.
КорСЕМы больше ориентированы на то, что бы поставить процессы и натренировать людей в команде таким образом, чтобы на выходе было хорошее качество и производительность команды постоянно росла. То есть это более технический человек, который хорошо разбирается в технологиях и инженерных практиках. Я там выше расписал чуть подробнее.
Вот купили мы в июне прошлого года JiveSoftware — компанию, которая базируется в Портлэнде — считайте та же Силиконовая долина. Для девелоперов там были созданы все условия — высокие зарплаты, отличный офис в центре города, 5 сортов разливного пива(!!!) в офисе, не говоря уже о еде, треннингах, массажистах и так далее. То есть инженеры у них работали очень даже квалифицированные (могли себе позволить заманить). Так вот — после покупки этой компании мы стали ставить своих иженеров ($50/час которые) в пары с Джайверами — всего за 3 месяца мы наняли 100 новых сотрудников через Кроссовер. И знаете что? Все Джайверы сказали, что наши ребята очень сильные и с ними здорово работать. Я специально постоянно всех спрашивал, так как самому было интересно сравнить наших ребят с коллегами из крутой компанией в Силиконовой долине.
Пришел начальник транспортного цеха. Вопрос понравился.
У нас в компании каждый СЕМ должен хорошо разбираться не только в ProjectManagement'е, но и иметь сильные знания в технологиях и инженерных практиках: как правильно организовать код-ревью, continuous integration, test driven development, branching strategy, deployment automation, environment provisioning automation, и так далее.
Ну а поддерживать/улучшать свои технические знания ему помогает одна из его прямых обязанностей, которую мы называем «Gemba Walk», а Toyota — «Walk the line»: чтобы менеджер имел возможность грамотно улучшить процесс — он должен видеть этот процесс вживую. В Toyota менеджеров посылают на заводы, где они ходят за рабочими и смотрят что и как они делают. Мы же от своих менеджеров ожидаем, что раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием. Это позволяет им разобраться почему top-performers работают так быстро, научиться у них, а потом изменять процессы/тулы/подходы/практики соответственно и обучать уже всю команду.
А еще, так как один СЕМ обычно поддерживает несколько продуктов (от 5 до 10), то у него есть возможность выучить и разные технологии, увидеть в деле и сравнить различные архитектурные подходы. В общем, поле для профессионального роста просто огромное.
А можно примеры Quality Bars? Конечно. Ничего сверхъестественного в них нет. Вот, например, QB для техподдержки на открытие задачи в инжиниринг:
Description
— Who is involved
— What issue occurred
— When the issue occurred
— Where the issue occured (platform, product, device, OS)
— How the issue occured — steps to reproduce
Expected results vs. actual results:
— What is the expected result
— What is the actual result
— Screenshots or log files proving the issue occured
Тут главное, что у нас отслеживается % принятия задач следующей командой. Когда только внедрили такой QB — отказов было очень многои мы активно обучали поддержку правильно вводить данные. Теперь отказ снизили до 8% и продолжаем снижать. В итоге инженерам нет необходимости общаться с техподдержкой, проясняя детали — вся необходимая информация есть в задаче.
И, конечно, все QBs постоянно улучшаются базируясь на обратной связи.
Кстати, отличная книга — всем рекомендую! У нас она обязательна к прочтению всеми уровня Software Engineering Manager и выше.
Что происходит с производительностью команды при ее росте? Я помню ответил тогда, что производительность каждого отдельного сотрудника падает из-за необходимости координации своих действий с коллегами, тогда как объем выполненных командой работ растет при условии, что поставлены правильные процессы. Это сейчас, проработав в Aurea больше года, я понимаю, что был наивен :) Собственными руками ращу несколько команд, и при этом растет производительность каждого сотрудника.
Еще был очень интересный вопрос по поводу планирования проектов. Давалось описание проекта, который надо реализовать и дополнительная информация с техническими и процессными требованиями. Далее 4 менеджера составили 4 различных проектных плана. Моя задача была расставить эти планы от лучшего к худшему и объяснить — почему.