Цели попиарить продукт нет - удалил все, что показалось намеком на пиар! Рассказывать о преимуществах таких известных продуктов как Jira, Youtrack и прочих нам показалось не имеет смысла - уж очень много статей про все плюсы и минусы.
Если говорить про сам продукт - развернут внутри сети компании. Мы используем он-лайн, чтобы не только в рамках офиса подключаться, а еще и извне.
Пока мы для себя эту метрику не реализовали - это в планах на ближайшее время.
В нашем случае, реализовывать планируем следующим образом - есть пул задач (по сути это стандартные у многих компаний, выработанные задачи) у менеджера (руководителя) проекта, на эти задачи требуется определенное время (оно может быть как оценено менеджером, так и вычислено на основе опыта работы с разными людьми). Дальше, надеюсь, вы догадались как будем считать эффективность - как дельту времени фактически затраченного времени к оцененной на эти задачи.
Автоматизировать подобные расчеты мы планируем с помощью собственной ERP-системы, которая будет учитывать не просто время выполнения, но еще и объем(сложность) задачи и качество ее выполнения.
Зарплата в нашей компании по всем направлениям на уровне рынка не только региона (Томска), а на уровне рынков Москвы и Санкт-Петербурга. "Плюшки" идут как дополнительные бонусы компании, ценность которых это в первую очередь забота о сотрудниках с их увлечениями и потребностями.
Отдельно по зарплатным вилкам и подходам в нашей компании будет статья в одной из ближайших публикаций.
На самом деле нет. Со стороны фронтендеров не было ребят, которые высказывали свои предложения.
Как я уже говорил самым главным фактором для нас был минимальный уровень необходимых знаний и сил, чтобы запустить автоматизацию QA специалистами. Кроме того, мы изначально постарались заложить единообразие API и e2e автотестов. Единообразие в части языка программирования.
Хочу отметить, что в статье главной задачей было поделиться тем опытом, который накопился за полгода работы, не пытаясь никого агитировать на использование стека технологий. Каждый, конечно же, вправе сам принять решение и выбрать фреймворк и стек технологий в зависимости от той ситуации, что есть на проекте, его стадии и имеющихся QA-специалистах.
Про стабильные/нестабильные тесты - померить это можно на временной дистанции по кол-ву падений прогонов тестов. Если говорить про наши автотесты, то мы считаем, что текущие API-автотесты стабильные, как для прод-сервера, так и для stage. Тесты падают крайне редко и по примерной оценке падения не превышают 1-2% от всех совершенных прогонов.
Извиняюсь за довольно поздний ответ, но все же прокомментирую, что имелось ввиду. У нас в компании изначально так сложилось, что автотестов не было и при внедрении были сложности организационные, касающиеся встраивания во флоу работы, понимания зон ответственности, ускорения исправления падающих тестов и ряд других проблем, которые мешали встроить в пул реквесты. Оповещений о том, что упал тест или прошли тесты было крайне много в каналах оповещения и потому реакция на исправление была долгой. Решение, которое в итоге предложили для этого проекта связано еще и с архитектурой самого проекта - ему больше 8 лет в продакшене, проект на микросервисной архитектуре, довольно много неоптимизированных участков кода со стороны бэка.
Варианты запуска автотестов с пул реквестами отлично работают на меньших по масштабу проектах в компании.
Изначально такой флоу и был - каждый раз автоматический запуск тестов после каждой сборки. Но как оказалось на практике - когда тот же офис в день пересобирается больше 10 раз - на падающие тесты просто не остается времени, чтобы отсеять реальное падение теста с ошибкой от всех остальных ситуаций.
Мы пришли к такой схеме:
Получается дважды в день контролируем работоспособность основного тестового набора (утром проверяем готов ли офис/стейдж и не поломали ли чего за вчера, а вечером проверяем прод). При этом, при проверке переданных задач, QA-инженеры запускают автотесты и по сути контролируют выполнение тестов в течение дня.
Да цены такие же на самокаты. Но цель была не удивить плюшками, самокатами и т.п., а рассказать про то, как устроена наша внутренняя культура и учитываются интересы и ценности молодых сотрудников.
Антон, к сожалению не помню, проводил ли именно я ваше собеседование.
Со своей стороны приношу искренние извинения, если в чем-то обидели и по итогу собеседования сложилось такое негативное впечатление о компании.
Приглашаю вас просто прийти к нам в офис и еще раз пообщаться, готов лично рассказать про нашу Smart Академию, подготовку студентов, обсудить технологические стеки и языки программирования.
В компании конечно есть "возрастные" сотрудники (сюда отнесу всех, не только программистов). Приведу пример на личном опыте - несмотря на то, что сам не из буммеров, люблю прокатиться на самокате на работу и также со всеми участвую в решении проблем компании. Таких примеров очень много у нас. Про спортивные команды вообще молчу - есть как футбольная, так и волейбольная. Плюс не забываем про тренажерный зал.
Добавлю, что впринципе, если человек ощущает себя моложе своих лет, это совсем не плохо, а при этом если еще и ведет активную жизнь, то и чувствует себя счастливым и полным сил.
О зарплате, грейдах и развитии в нашей компании подготовлю в ближайшее время еще ряд статей, где сможем рассказать наш подход и обсудить все интересующие вопросы.
Да, отчасти вы правы, но посмотрите сами - поколение людей меняется, а со сменой поколений меняются и ценности и подходы и методы! Как компания мы готовы предлагать все самое лучшее нашим специалистам. Более того, скажу что мы постоянно добавляем еще много интересных и полезных бонусов для привлечения самых талантливых ребят в команду!
У нас в компании это действительно выстроено как процесс и конфликт интересов разрешается очень легко (при необходимости подключаюсь лично и разбираюсь в ситуации). Для того, чтобы не было спорных моментов как только мы поправили уязвимость - мы публикуем внутри проекта это и показываем, что именно было исправлено.
Важно, что мы не отбираем ни у кого деньги, а наоборот вознаграждаем) Т.е. фонд выделен отдельный от всех остальных премий в компании.
Спасибо за совет.
К хорошему быстро привыкаешь)) и кажется что вернуться даже в 2014 в части дизайна/аналитики/разработки/тестирования - это так больно=))
Все верно, рассматривали риски, связанные с оплатой.
Спасибо за коммент.
Цели попиарить продукт нет - удалил все, что показалось намеком на пиар! Рассказывать о преимуществах таких известных продуктов как Jira, Youtrack и прочих нам показалось не имеет смысла - уж очень много статей про все плюсы и минусы.
Если говорить про сам продукт - развернут внутри сети компании. Мы используем он-лайн, чтобы не только в рамках офиса подключаться, а еще и извне.
Пока мы для себя эту метрику не реализовали - это в планах на ближайшее время.
В нашем случае, реализовывать планируем следующим образом - есть пул задач (по сути это стандартные у многих компаний, выработанные задачи) у менеджера (руководителя) проекта, на эти задачи требуется определенное время (оно может быть как оценено менеджером, так и вычислено на основе опыта работы с разными людьми). Дальше, надеюсь, вы догадались как будем считать эффективность - как дельту времени фактически затраченного времени к оцененной на эти задачи.
Автоматизировать подобные расчеты мы планируем с помощью собственной ERP-системы, которая будет учитывать не просто время выполнения, но еще и объем(сложность) задачи и качество ее выполнения.
Зарплата в нашей компании по всем направлениям на уровне рынка не только региона (Томска), а на уровне рынков Москвы и Санкт-Петербурга. "Плюшки" идут как дополнительные бонусы компании, ценность которых это в первую очередь забота о сотрудниках с их увлечениями и потребностями.
Отдельно по зарплатным вилкам и подходам в нашей компании будет статья в одной из ближайших публикаций.
На самом деле нет. Со стороны фронтендеров не было ребят, которые высказывали свои предложения.
Как я уже говорил самым главным фактором для нас был минимальный уровень необходимых знаний и сил, чтобы запустить автоматизацию QA специалистами. Кроме того, мы изначально постарались заложить единообразие API и e2e автотестов. Единообразие в части языка программирования.
Хочу отметить, что в статье главной задачей было поделиться тем опытом, который накопился за полгода работы, не пытаясь никого агитировать на использование стека технологий. Каждый, конечно же, вправе сам принять решение и выбрать фреймворк и стек технологий в зависимости от той ситуации, что есть на проекте, его стадии и имеющихся QA-специалистах.
Про стабильные/нестабильные тесты - померить это можно на временной дистанции по кол-ву падений прогонов тестов. Если говорить про наши автотесты, то мы считаем, что текущие API-автотесты стабильные, как для прод-сервера, так и для stage. Тесты падают крайне редко и по примерной оценке падения не превышают 1-2% от всех совершенных прогонов.
Извиняюсь за довольно поздний ответ, но все же прокомментирую, что имелось ввиду. У нас в компании изначально так сложилось, что автотестов не было и при внедрении были сложности организационные, касающиеся встраивания во флоу работы, понимания зон ответственности, ускорения исправления падающих тестов и ряд других проблем, которые мешали встроить в пул реквесты. Оповещений о том, что упал тест или прошли тесты было крайне много в каналах оповещения и потому реакция на исправление была долгой. Решение, которое в итоге предложили для этого проекта связано еще и с архитектурой самого проекта - ему больше 8 лет в продакшене, проект на микросервисной архитектуре, довольно много неоптимизированных участков кода со стороны бэка.
Варианты запуска автотестов с пул реквестами отлично работают на меньших по масштабу проектах в компании.
Приветствую Алексей!
Изначально такой флоу и был - каждый раз автоматический запуск тестов после каждой сборки. Но как оказалось на практике - когда тот же офис в день пересобирается больше 10 раз - на падающие тесты просто не остается времени, чтобы отсеять реальное падение теста с ошибкой от всех остальных ситуаций.
Мы пришли к такой схеме:
Получается дважды в день контролируем работоспособность основного тестового набора (утром проверяем готов ли офис/стейдж и не поломали ли чего за вчера, а вечером проверяем прод). При этом, при проверке переданных задач, QA-инженеры запускают автотесты и по сути контролируют выполнение тестов в течение дня.
Да цены такие же на самокаты. Но цель была не удивить плюшками, самокатами и т.п., а рассказать про то, как устроена наша внутренняя культура и учитываются интересы и ценности молодых сотрудников.
Антон, к сожалению не помню, проводил ли именно я ваше собеседование.
Со своей стороны приношу искренние извинения, если в чем-то обидели и по итогу собеседования сложилось такое негативное впечатление о компании.
Приглашаю вас просто прийти к нам в офис и еще раз пообщаться, готов лично рассказать про нашу Smart Академию, подготовку студентов, обсудить технологические стеки и языки программирования.
В компании конечно есть "возрастные" сотрудники (сюда отнесу всех, не только программистов). Приведу пример на личном опыте - несмотря на то, что сам не из буммеров, люблю прокатиться на самокате на работу и также со всеми участвую в решении проблем компании. Таких примеров очень много у нас. Про спортивные команды вообще молчу - есть как футбольная, так и волейбольная. Плюс не забываем про тренажерный зал.
Добавлю, что впринципе, если человек ощущает себя моложе своих лет, это совсем не плохо, а при этом если еще и ведет активную жизнь, то и чувствует себя счастливым и полным сил.
О зарплате, грейдах и развитии в нашей компании подготовлю в ближайшее время еще ряд статей, где сможем рассказать наш подход и обсудить все интересующие вопросы.
Да, отчасти вы правы, но посмотрите сами - поколение людей меняется, а со сменой поколений меняются и ценности и подходы и методы! Как компания мы готовы предлагать все самое лучшее нашим специалистам. Более того, скажу что мы постоянно добавляем еще много интересных и полезных бонусов для привлечения самых талантливых ребят в команду!
У нас в компании это действительно выстроено как процесс и конфликт интересов разрешается очень легко (при необходимости подключаюсь лично и разбираюсь в ситуации). Для того, чтобы не было спорных моментов как только мы поправили уязвимость - мы публикуем внутри проекта это и показываем, что именно было исправлено.
Важно, что мы не отбираем ни у кого деньги, а наоборот вознаграждаем) Т.е. фонд выделен отдельный от всех остальных премий в компании.