Pull to refresh
152
0
Egor Tolstoy @YourDestiny

Пользователь

Send message
Тогда вам правда хорошо подойдет ktor. Список прочих фреймворков, поддерживающих Kotlin, есть вот тут: kotlinlang.org/lp/server-side
Там такое распределение:
— Китай
— США
— Индия
— Россия
— Германия
Я бы советовал начать с Atomic Kotlin.
Прямо на 100% сервисных команд у нас нет, но у некоторых такая работа может съедать прямо значимый кусок времени. Сервисную работу напрямую в OKR мы не отражаем. Туда могут попасть, например, цели по ускорению потока, более качественному обслуживанию, или созданию какой-то новой ценности. Соответственно, при постановке OKR команда рассчитывает ресурсы исходя из своих прогнозов по загруженности потоком операционных задач.
Не соглашусь :) Вот несколько популярных мобильных конференций:
uikonf.com
swiftconf.com
altconf.com
Статья про то, как попасть в ПК любой конференции. Где-то это волонтерство, где/то нет. Обычно членам ПК предлагаются дополнительные плюшки – билеты и проживание на конфе, проходки на другие ивенты, подарки и всякое такое. За каждую конференцию из сотни я не могу говорить, к сожалению :)
На текущий момент себе участников в ПК мы не ищем. У каждой другой конференции свои правила, и в большинстве случаев это действительно волонтерская работа.
Нет, в нашем случае это оплачиваемая работа.
Отличный вопрос, чтобы закинуть в issues в плейбуке!
Не очень понял, к чему вопрос :) Проясните?
> А теперь это ревью. Оценки, ошибки, балы. Пока что в одной компании, потом данные передаются другой и понеслась. Пожизненно «клейменный» индивидум.
Интересная интерпретация, но пока меня в мировой заговор еще вроде бы не втянули. Но я буду следить за появлением рептилоидов, спасибо :)

А по существу всех комментариев попробую ответить. В статье я уже писал, как и говорил в подкасте, на который дал ссылку в другом комментарии, что перфоманс ревью у нас работает в связке с OKR, методологией целеполагания и каскадирования целей с уровня компании до уровня конкретных команд. Именно эта связка позволяет убедиться, что команды ставят важные цели, поддерживающие цели всей компании, и достигают их. Это помогает избежать ситуации, когда все работают не на результат, а на то, чтобы понравиться своим соседям.
Основные цели – оценить вклад каждого человека в общий результат и дать ему конструктивный фидбэк про то, что было хорошо, а что можно улучшить. Система мотивации есть, но детали раскрывать, к сожалению, не могу.
Один из показательных примеров:
«Полностью соответствует ожиданиям, молодец», и оценка «Сильно превышает ожидания» (5). Здесь несоответствие принятой системе оценки, где за соответствие ожиданиям принята оценка 3. Затем респондент уходит в отпуск и не может ничего исправить.
Вот мы тут, как и в верхней ветке, ударяемся в частности, обсуждая абстрактный пример :) Здесь можно закопаться очень сильно, рассказывая о том, как построены процессы разработки в Avito, почему у нас разработчик действительно должен думать о проблемах пользователя, откуда ему брать время на обучение и всякое такое.

Статья немного не об этом – она о самом процессе performance review. А если есть желание узнать больше деталей про то, как вообще работает Avito, приходите к нам на любой митап, с радостью расскажем! :)
Мы сейчас говорим немного не по существу. Я привел абстрактный пример того, как может выглядеть селф-ревью от разработчика и фидбэк от его коллег. Обсуждать конкретику из такого примера, мне кажется, не имеет смысла.

Если говорить по существу, то суть оценки как раз таки в перекрестном ревью от очень разных типов коллег – твоего менеджера, заказчиков, пиров и подчиненных. Каждый из них оценивает твою деятельность через призму своего опыта. Нет речи о формализации вроде «Вася ошибается в оценке в среднем на 3 часа, а Петя на 1 час, значит Петя молодец».

Подробно про такие штуки, кстати, недавно поговорили в подкасте Podlodka. Там как раз обсуждали разные подходы к оценке эффективности, в том числе и операционные метрики.
Это – лишь крайний шаг, которым пользуются в 1% случаев. Мотивация к введению этой фичи, как и способ бороться со злоупотреблением я описал в статье.
400 человек ставят оценки, но их никто не оценивает. Некоторые более равны, чем остальные.

Тут все просто. Performance review мы раскатывали постепенно. Начинали с пары команд, потом увеличивали их количество, потом выросли до всего технического департамента. Но до сих пор в ревью не участвуют некоторые функции (финансы, HR, бухгалтерия, юристы), у которых своя методика оценки эффективности. Это не мешает им участвовать в качестве тех, кто дает оценку – отсюда и появилась эта разница.

Нормализацию оценок сделали, но про то что оценка стейкхолдера делится на 1 — «Сейчас мы смотрим на это ретроспективно», таак мило.

Обычно менеджер следит за тем, чтобы количество участников в каждой группе было примерно сбалансировано, так что это скорее исключение. Стейкхолдеров чаще всего больше одного.

Корректировка оценок менеджерами — вообще отлично — «иногда случаются проблемы… человек жёстко стоит на своем». Это явно огромная проблема, приходится корректировать вручную чтобы всё четко сошлось и менеджеру бонус дали.

Да, это действительно проблема – человек может уйти в отпуск, например.

80% = 49.6 оценки. Сколько из них были скорректированы в худшую сторону? Как сильно отражается эта коррекция на зарплате?

Тут такое распределение:
— Уменьшено на 2 балла: 5 оценок
— Уменьшено на 1 балл: 39 оценок
— Увеличено на 1 балл: 10 оценок
— Изменено на «затрудняюсь оценить»: 8 оценок

На зарплате это никак не отражается, может влиять на бонус – но с учетом примерно равного распределения по группам и общего количества респондентов около 10, изменение одной оценки не оказывает заметного влияния.
Это просто пример :)
Но вообще, у нас для релизов мобильных приложений (а пример как раз о них) заведен релизный поезд, который ездит строго по расписанию. Из-за ряда особенностей, в том числе потому, что мобильное приложение — монолит by design, возможна ситуация, когда один разработчик может притормозить всю выкатку.
А в таск трекере менеджер на это завел таску? Программист сам своим временем распоряжается? Программист должен в конце дня завести таску «общался с Ивановым 1 час»?

В разных командах планирование у нас построено по-разному. В большинстве случаев работы по наставничеству просто учитываются в фокус-факторе сотрудника.

Это же забота менеджера?

Зачастую ментором может выступать ведущий разработчик в команде.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity