Рубрика «управление персоналом» - 104

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

Эффективность и прозрачность это никогда не одно и то же. Можно прозрачно делать неэффективные вещи, а эффективно делать вещи непрозрачные.

Построение структуры работы это сложный, индивидуальный процесс, с налётом дерзости. Потому что нужна не только смелость и рефлексия («мы работаем неэффективно, почему?»), но и умение делать изящные нагромождения.

Дерзкая птица структур: development flow - 1
Читать полностью »

8 простых шагов к провалу начинающего менеджера по разработке - 1

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

Как преуспеть в новой роли? Как опять пройти через все ступени и достичь такого уровня результатов и доверия, которого все ожидают, особенно вы сами? Сотни книг и тысячи блогов пытаются найти эти ответы, так что не буду притворяться, что у меня есть секрет успеха. Но я знаю несколько способов, которые совершенно точно гарантируют вам провал.
Читать полностью »

Про мотивацию с приставкой «Супер» - 1

Помните нетленные строчки БГ из песни «Поезд в огне»? «Их дети сходят с ума от того, что им нечего больше хотеть…». На этом фоне захотелось погрузиться в тему мотивации персонала, отыскав что-нибудь экзотическое. Честно говоря, в самом начале идея казалась банальной, но, как известно, удача упорству благоволит. Давайте же покопаемся в этом роге корпоративного изобилия и мотивирующих излишеств.Читать полностью »

В статье я расскажу о моём опыте работы на должности тимлида в компании по разработке сайтов. Чтобы всем было полезнее и проще читать, статья разбита на главы, каждая из которых рассказывает об одной отдельной проблеме и её решению. Хотя по возможности будет сохранена хронология событий.

Надеюсь, что описанный ниже опыт станет для кого-то чужими граблями, а в комментариях я и сам почерпну что-то от более опытных коллег.

Читать полностью »

Почему решились организовывать практику, как выбирали ребят, какие задачи им ставили и за что хотели прибить в процессе.

«Малявки, но хорошие»: как мы брали студентов на практику - 1
Читать полностью »

Наем удаленного разработчика или тестировщика, с которым до начала работы не предусмотрено личных встреч, представляется серьезным риском. Присутствие кандидата создает иллюзию контроля над ситуацией. А куда же без него?

Приняв для себя идеологию удаленной работы вместе со всеми ее преимуществами, вроде доступа к лучшим кадрам по всей стране, «Максилект» встал перед выбором: либо оплачивать всем кандидатам приезд в офис, либо выстраивать процессы таким образом, чтобы в найме не оставалось места иллюзиям.

image

О том, как рекрутеры участвуют в оценке квалификации технарей, нужен ли senior’у диплом, при чем тут веб-камеры и какова на самом деле цена ошибки найма, рассказывает Максим Коротков, генеральный директор компании.
Читать полностью »

До Saint TeamLead Conf, конференции про боли тимлида, осталось две недели. В этой конференции мы уже не хотели просто обозначить как можно больше проблем, а хотели раскрыть каждую тему с разных точек зрения. Мы с программным комитетом, основываясь в том числе и на февральской TeamLead Conf, собрали воедино все основные направления деятельности тимлида (не будем забывать, что пока все вкладывают в эту роль разное). Полученное обобщили, структурировали и использовали как кирпичики для построения программы: коммуникации; измерения и оценка; работа со знаниями; построение команды и выстраивание процессов; мотивация команды; и работа над собой, которая и включает то самое: «Я стал тимлидом, и что теперь».

Расписание получилось, как мне кажется, очень взвешенное и сбалансированное, по каждому из 10 направлений есть несколько докладов, причем выступления внутри одной секции идут друг за другом и участнику не понадобится выбирать, какой доклад про коммуникации ему интереснее. Просто приходишь 24 сентября, в понедельник, во второй зал, удобно располагаешься, раскладываешь брошюру и блокнот — и впитываешь чужой опыт. В перерывах задаешь вопросы и общаешься с «коллегами по несчастью». Это будет удобно, и, мы надеемся, позволит каждому найти советы под свои задачи.

Под катом коротко о каждой теме, чтобы показать вам нашу продуманную структуру конференции. Но доклада 32, поэтому в целом это длинно.

«Святой» Тимлид и его последователи - 1

TL;DR: Вот ссылка на расписание, можно потыкать только в отдельные доклады — в них всех много живого опыта, практики и вполне конкретных рекомендаций.
Читать полностью »

image

Дела у вас пойдут плохо, если не контролировать качество продаж. Причем контроль нужно внедрять до оценки качества.

Часто бывает иначе. Точка приносит мало денег? Отлично, давайте всех уволим. Не будет считать затраты на увольнение, обучение и поиск новых сотрудников. Просто разгоним «плохих» и наберем «хороших».

В результате «хорошие» оказываются ещё хуже. Как так? Управленческие действия опирались на некорректные показатели.

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

У старых методов присутствуют недостатки, которые мы исправили в сервисе оценки действий сотрудников на базе Ivideon.
Читать полностью »

Это краткое отступление в текущей серии статей о том, как избегать введения сервисов для различных сущностей. Интересный разговор за ужином привёл к мыслям, которые я решил записать.

Закон Амдала

В 1967 году Джин Амдал представил довод против параллельных вычислений. Он утверждал, что рост производительности ограничен, поскольку только часть задачи поддаётся распараллеливанию. Размер остальной «последовательной части» отличается в разных задачах, но она есть всегда. Этот довод стал известен как закон Амдала.

Если построить график «ускорения» выполнения задачи в зависимости от количества выделенных ей параллельных процессоров, вы увидите следующее:

Издержки согласования в коллективах - 1
Это асимптотический график для фрагмента, который не поддаётся распараллеливанию («последовательная часть»), поэтому существует верхний предел максимального ускорения
Читать полностью »

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

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js