Управление персоналом *

«Да кто такой этот ваш аджайл?! Мы же не продуктовая команда!», «И как меня угораздило в это вляпаться?!» — такие выражения (и много чего еще) я слышала на командных встречах архитекторов компании в роли агента изменений.

Всем привет! Я – Мадина, скрам-мастер в Департаменте управления технологиями МТС, у нас это подразделение называют Департаментом Technology Governance (TechGov).

Одно дело — внедрять скрам или канбан в командах разработки и совсем другое — внедрять гибкие подходы в Центрах компетенций или практик. Таких, например, как архитектура, управление производственным процессом, R&D или даже сам Центр практик Agile.

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

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

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

Частая проблема — задачи не делегируются вовсе. Закоренелые айтишники норовят сделать всё собственными руками. И только когда понимают, что сами не справятся, начинают делегировать. Но лучше ошибиться, делегировав задачу, чем вообще забыть про неё, не сделав этого.

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

Я уже много лет занимаюсь созданием IT-продуктов. Всё это время для себя и коллег собираю метафоры, которые позволяют наглядно показать, как нужно и как ненужно выстраивать работу по созданию ПО.

По мере работы над IT-продуктом мы узнаем что-то новое о рынке и пользователях и за счет этих знаний продукт перестраиваем. В физическом мире довольно сложно постоянно перестраивать, а в IT – это повседневная задача. По мере перестройки системы мы получаем результат, который все лучше и точнее попадает в запросы клиентов, что и приводит нас к прибыли.

Я рассмотрю 5 моих любимых метафор, которые помогают сонастраивать общее видение процесса для команды разработки и заказчика:

Правильно выбранная CRM-система помогает избавиться от повседневной рутины и использовать рабочую энергию более продуктивно. Рассказываем, как выбрать CRM под ваши цели и делимся подборкой сервисов.

Мы изучили отчеты опубликованные министерством труда и социальной защиты Российской Федерации, а также открытые данные Федеральной службы по экологическому, технологическому и атомному надзору. (Официальные документы приведены.)

На 2020-2022 год наблюдается сокращение случаев производственного травматизма, однако в абсолютных числах ситуация следующая:

Набирая It-специалистов для решения разного рода задач, компании или департаменты стараются брать от middle и выше, казалось бы, это удобно. Вот придёт такой человек в компанию, рассказали о структуре - он вник в структуру, разъяснили как коммуницировать - коммуницирует, описали задачу - сразу приступит к работе над своим блоком и решает. В том числе и все имеющиеся подзадачи - закрывает, и кампания (департамент / компания) идет семимильными шагами к релизу продукта. А потом?!

Но где их набраться, таких специалистов, которые сразу станут не только "пломбировочным материалом в дырах проекта", но и в дальнейшем станут заниматься развитием проекта!?

На такие задачи есть HR-мудрецы! Скажете Вы.

Да. Они могут найти решение, но им заявку кто подаёт?! Тот кому нужны ответы на вопросы: Сможешь? - Смогу. Как..? - Вот так. Ок, берём.

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

Привет, Хабр, меня зовут Герман, и я лид разработки, вышедший из фронтов. Сегодня я хочу обсудить тему культуры собеседований, а точнее, тот хаос что творится на этом поприще. А заодно — узнать, что об этом думает комьюнити in situ.

Без эмоций невозможно представить нашу жизнь, они сопровождают нас всегда. Мы думаем, что младенец проявляет эмоции только тогда,  когда расплакался. Но это лишь их пик, а на самом деле, чтобы он ни делал, они всегда служат фоном. Когда человек спокоен, нам лишь кажется, что ничего не происходит, но даже  когда он спит, он испытывает эмоции. Речь в статье пойдёт о том, как экологично контролировать и выражать свои эмоции так, чтобы не причинять вреда другим.

Николай Юдин, кандидат психологических наук и психолог-консультант, расскажет насколько эмоции важны в профессиональной и личной сфере.

Я начинал карьеру как фронтенд-разработчик и прошел по всем стандартным этапам: от джуниора до сеньора и тимлида, потом стал руководителем отдела. И дальше, конечно, планировал стать CTO — Chief Technical Officer. И только через несколько лет узнал, что мои представления о том, какие навыки нужны на этой должности, были далеки от реальности.

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

Как вы знаете, я работаю техническим директором в Decart IT-production. Мы делаем разные классные штуки: от стартапов и программ до чего-то более масштабного, например, https://vt.tiktok.com/ZSLLr7FBA/?t=1. Сегодня я хочу рассказать вам о нашей новой разработке – Huntlee.

Начнем с того, что это вообще такое.

Huntlee – приложение для помощи рекрутерам, которое автоматизирует рутинные процессы и ускоряет процесс поиска потенциальных работников, увеличивая доступный ресурс рекрутера до двух месяцев. 

Публикуем вторую часть материала о новшествах в системе управления персоналом Shopify. Читайте также первую часть.

Наша команда как и многие другие работала с облачными продуктами Atlassian: Jira и Confluence. Осенью прошлого года, Atlassian отправила нам письмо счастья.

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

Можно ли организовать весь этот процесс по-человечески, чтобы он приносил реальную пользу обеим сторонам? В чем секрет адекватного ревью? Как общаться с людьми (не имея диплома по психологии)? И зачем в принципе эти встречи нужны компаниям и сотрудникам? Отвечаю на личном опыте.

В условиях современного, динамично развивающегося бизнеса удержание лучших сотрудников — одна из главных задач для большинства компаний. Согласно исследованию 2020 года, 63,3% из опрошенных 600 организаций уверены: удержать специалистов на самом деле сложнее, чем их найти.

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

71% руководителей утверждают, что решающее значение для успеха их компании, в том числе в «войне за таланты», имеет вовлеченность персонала. При этом лишь 20% сотрудников по всему миру действительно вовлечены в свою работу. Почему же их так мало? Как исправить ситуацию и какие данные взять на вооружение? Рассказываем под катом.

Эта статья будет полезна прежде всего работадателям, HR, но так же и тимлидерам и всем, кто принимает участие прямое или косвенно в вопросах, касающихся найма сотрудников в IT сфере.

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

По мере развития моих проектов я все острее чувствую необходимость нанять ассистента. Долгое время не понимал, как подойти к этому вопросу: как его выбрать? Сколько ему платить? Как организовать работу? Недавно познакомился с Мариной Кнауб в нашем HR-чате. Сейчас она работает проджект-менеджером онлайн-проектов и часто нанимает ассистентов, SMM-специалистов и других подрядчиков для предпринимателей и компаний. Мы поговорили о всех тонкостях найма помощников для бизнеса и теперь делимся опытом с вами!

Роль тимлида сложная и интересная. Это первый шаг в менеджерском треке развития, но далеко не последний. Какой шаг будет следующим? Иногда сразу CTO. Но чаще – это руководитель уже нескольких проектов и нескольких команд: Delivery Manager, Руководитель Разработки, Engineering Manager и другие аналогичные названия этой роли.

Но переходить сложно. Это уже другой уровень управления, а значит требуются совсем иные инструменты и подходы. Ведь теперь вы не погружены в код, и не управляете сотрудниками напрямую. Теперь у вас в подчинении тимлиды, а уровень ответственности гораздо выше.
Про роль Delivery Manager-а и сложности перехода на нее предлагаю почитать.