Увидел про GetKanban, это крутой способ познакомить с теорией.
Но кажется, не хватает чего-то с процессной практикой, какие статусы на досках, чего значат, какие типы задач по ним едут, там ведь всегда куча нюансов...
Ну это политика компании не указывать вилки в своих вакансиях, ни обсуждаютс с кандидатом лично.
Это связано с несколькими причинами:
Ищем по одной вакансии разные уровни специалистов. Как например здесь, готовы брать даже подающего надежды джуна и побитого жизнью сеньора. Указывать вилку вида 60к - 400к кажется будет достаточно странно.
Мы международная компания, у нас часть разработчиков не в России, по этому, там зарплаты например европейские, которые от зарплат российских отличаются. Например, собеседовали человека из Кракова, он будучи мидлом хотел сильно больше, чем мидл из Омска. Хотя позиция одна и делать надо одно и то же. И отсутствие жесткой вилки позволяло нам спокойно сделать ему оффер.
Мы не разглашаем зарплаты внутри компании, по крайней мере горизонтально. Чтобы между сотрудниками не было конфликтов вида "а фигли я делаю в два раза больше, а получаю на 30% меньше чем Вася". Потому что, то сколько ты делаешь не всегда находится в прямой зависимости от твоей зарплаты. В частности, смотри вопрос про географию.
Вот это если несколько подробней, надеюсь стало понятней.
В том числе потому, что мы уже нанимали людей в команду, выставляя такую вакансию, особых проблем не было, нашли подходящего человека достаточно быстро.
Я недавно в нашей продуктовой компании грейды писал под WP разработчиков. Получились требования как к серьезном full stackам.
Да, и команда занимается не только прототипированием, но и быстрой разработкой всяких внутренних тулзов и автоматизациями.
Предвидя вопрос, а почему не взять коробку на рынке просто заплатив за неё - потому что коробки в последнее время все облачные, а у компании пунктик на этот счёт.
Честно говоря не очень понял, почему это динамический импорт, а не автоспорт проекта.
На конкретном примере, у меня есть модули с переводом приложения на разные локали, обычно это импортируемый js объект с парой тысяч ключей — строк перевода.
На последнем проекте я экспериментировал с тем, что по умолчанию испортился только модуль английского языка при инициализации приложения. В момент получения данных пользователя, если у него выбран не английский язык — динамически испортится модуль с нужным языком.
И если пользователь меняет язык, происходит проверка, загружен ли этот язык и если, происходит его динамический импорт.
В JIRA, есть кастомных пользовательские поля которые можно цеплять к схеме уведомлений проекта, так что сделать больше 1 исполнителя на задачку — настраивается за час максимум если есть опыт и за день если нет.
Ну вот да, у нас сейчас есть целый пул не стандартных задач по JIRA которые не сделать только через её настройки. И пока путь:
— Выстрелить WebHook'ом в наш сервис по работе с JIRA
— Обработать запрос
— Сделать необходимые изменения используя JIRA REST API
Кажется значительно проще, чем напрягать коллег пишущих на Java сделать вводную в язык, потом неделю разворачивать локальное окружение, потом напрягать DevOps'ов делать полноценный DevStage с CI/CD (вместо просто поднятия копии из бэкапа)…
Если вы знакомы с Java, со стеком JIRA, то да, пишется за час. А если на Java никогда не писал, сейчас работаешь PM'ом и в последний раз коммерческий код писал полтора года назад на PHP…
Ясно, жалко, видимо пока мы все продолжим страдать с этой капчей, как вариант, сделаем отправку уведомления в Slack при получение такой ошибки, чтобы фиксить проблему оперативней.
Спасибо, задумались о том, чтобы активно начать использовать вашу либу.
Скажите, а как в итоге справились с авторизацией, у нас периодически наши костыли перестают работать, потому что JIRA начинает требовать введение капчи, есть какой-то рецепт?
Увидел про GetKanban, это крутой способ познакомить с теорией.
Но кажется, не хватает чего-то с процессной практикой, какие статусы на досках, чего значат, какие типы задач по ним едут, там ведь всегда куча нюансов...
Да, но это сейчас общая проблема иностранного софта для российских компаний, которые работают чисто на внутренний российский рынок, не только Jira.
Понятно.
Однако вакансии разработчиков мы на иностранных сайтах не публикуем, там как правило публикуются вакансии специалистов с не русским native языком.
Кстати, нужного специалиста на эту позицию мы уже нашли и наняли)
Согласен с тем, что инициатива идиотская.
Но перебеубедить в этом фаундеров у нас пока не получилось.
Да, и?
А из-за чего вы оцениваете вакансию как классную, просто для понимания, что зацепило?
Ну это политика компании не указывать вилки в своих вакансиях, ни обсуждаютс с кандидатом лично.
Это связано с несколькими причинами:
Ищем по одной вакансии разные уровни специалистов. Как например здесь, готовы брать даже подающего надежды джуна и побитого жизнью сеньора. Указывать вилку вида 60к - 400к кажется будет достаточно странно.
Мы международная компания, у нас часть разработчиков не в России, по этому, там зарплаты например европейские, которые от зарплат российских отличаются. Например, собеседовали человека из Кракова, он будучи мидлом хотел сильно больше, чем мидл из Омска. Хотя позиция одна и делать надо одно и то же. И отсутствие жесткой вилки позволяло нам спокойно сделать ему оффер.
Мы не разглашаем зарплаты внутри компании, по крайней мере горизонтально. Чтобы между сотрудниками не было конфликтов вида "а фигли я делаю в два раза больше, а получаю на 30% меньше чем Вася". Потому что, то сколько ты делаешь не всегда находится в прямой зависимости от твоей зарплаты. В частности, смотри вопрос про географию.
Вот это если несколько подробней, надеюсь стало понятней.
Нет, не боимся.
В том числе потому, что мы уже нанимали людей в команду, выставляя такую вакансию, особых проблем не было, нашли подходящего человека достаточно быстро.
Ну вот мы ищем. Вилку не указываем, потому что готовы на эту позицию брать и мидла и сеньора, а вилки у них разные.
https://spb.hh.ru/vacancy/50585643
Я недавно в нашей продуктовой компании грейды писал под WP разработчиков. Получились требования как к серьезном full stackам.
Да, и команда занимается не только прототипированием, но и быстрой разработкой всяких внутренних тулзов и автоматизациями.
Предвидя вопрос, а почему не взять коробку на рынке просто заплатив за неё - потому что коробки в последнее время все облачные, а у компании пунктик на этот счёт.
Вот и имеем целую команду вордпрессеров.
Честно говоря не очень понял, почему это динамический импорт, а не автоспорт проекта.
На конкретном примере, у меня есть модули с переводом приложения на разные локали, обычно это импортируемый js объект с парой тысяч ключей — строк перевода.
На последнем проекте я экспериментировал с тем, что по умолчанию испортился только модуль английского языка при инициализации приложения. В момент получения данных пользователя, если у него выбран не английский язык — динамически испортится модуль с нужным языком.
И если пользователь меняет язык, происходит проверка, загружен ли этот язык и если, происходит его динамический импорт.
В JIRA, есть кастомных пользовательские поля которые можно цеплять к схеме уведомлений проекта, так что сделать больше 1 исполнителя на задачку — настраивается за час максимум если есть опыт и за день если нет.
— Выстрелить WebHook'ом в наш сервис по работе с JIRA
— Обработать запрос
— Сделать необходимые изменения используя JIRA REST API
Кажется значительно проще, чем напрягать коллег пишущих на Java сделать вводную в язык, потом неделю разворачивать локальное окружение, потом напрягать DevOps'ов делать полноценный DevStage с CI/CD (вместо просто поднятия копии из бэкапа)…
За совет с ScriptRunner'ом тоже спасибо.
Скажите, а как в итоге справились с авторизацией, у нас периодически наши костыли перестают работать, потому что JIRA начинает требовать введение капчи, есть какой-то рецепт?
И ещё, вы плагины свои для JIRA не пишите?