Что делать?

0. Определить приоритеты бизнеса.

1. Определить зоны ответственности.
— команд.
— каждого члена команды.

2. Разработать фреймворк принятия решений
— понимание того, как мы фиксируем договоренности, как контролируем промежуточные и финальные результаты, система отчетности.
— понимание того, в каких случаях сотрудники обращаются к руководителю, а в каких - решение принимают самостоятельно.

3. Провести оценку навыков и результативности сотрудников
— Наличие процесса оценки навыков сотрудников и их результативности + предоставление фидбека и последующий мониторинг прогресса.
— Наличие системы развития сотрудников внутри компании.

4. Провести ревью орг. структуры
— Проанализировать, тратят ли сотрудники 85% своего времени на ключевые задачи?
— Определить нехватку ролей внутри команд.
— Определить, какой функционал и кому можно делегировать (текущим сотрудникам или с помощью найма).

Вряд ли о собеседованиях возможно сказать что-то принципиально новое. Но, по-моему, читать и писать о них всё равно полезно: их проводят очень по-разному, поэтому чем больше понимаешь, как смотрят на них разные люди, тем лучше можешь проявить себя с обеих сторон (и как кандидат, и как собеседующий).

Кирилл Розов @kirich1409, известный многим Android-разработчикам, на нашей конференции Mobius выступал с докладом «Как пройти архитектурную секцию собеседования». А заодно на той же конференции ответил Анне Жарковой @anioutka на более общие вопросы о собеседованиях в целом, не связанные с мобильной разработкой.

По ссылкам вы уже можете увидеть обе видеозаписи, а для Хабра мне захотелось ещё и выписать текстом отдельные тезисы из его ответов. Не потому что подписываюсь под каждым словом (с чем-то можно поспорить), а как раз потому что считаю полезным видеть разные точки зрения. Смело дополняйте в комментариях своими мнениями — так точек зрения станет ещё больше, неплохой способ провести вечер пятницы.

Авторы отправили 675 заявок на Технотекст, а мы их перебрали и готовы показать номинантов. Короткие списки получились очень даже длинными, что не может не радовать.

Победителей объявим до 14 апреля. Критерии оценки, списки судей и подборки статей по номинациям — в этом посте.

Привет, Хабр!

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

Но что, если обновлений насчитывается 250+ типов? А если поддерживаемых ОС — порядка 250? И для тестирования требуется 7500+ тестовых машин? Такой вот типичный хайлоад. Который должен постоянно масштабироваться…

Я — Иван Лауре, менеджер по тестированию в «Лаборатории Касперского». Именно так, как я описал выше, выстроено «выкатывание» у нас. В этой статье я расскажу о центральной части всего процесса — как мы тестируем обновления для более чем 500 уникальных версий ПО, да и саму распределенную систему тестирования. Не сомневаюсь, что наш опыт будет вам полезен.