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

Работая над статьёй ИИ не изменит IT, я обратила внимание, что ключ ко многим проблемам нейросетей — это закон Гудхарта: «Когда мера становится целью, она перестаёт быть хорошей мерой». Закон этот настолько универсальный, что захотелось посвятить ему отдельную статью.

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

«Сделал и забыл» — это не про сайты, не про SEO и не про цифровой маркетинг. В этой статье разберёмся, почему это не чья-то злая воля, а системная закономерность. И как, понимая её, выстраивать устойчивые процессы.

Сотни сообщений без смысла, игнор просьб, срочные задачи в полночь — вот настоящая «корпоративная культура». Я собрал 7 самых больных кейсов рабочего общения.

Говорят, стажёрам нельзя доверять прод — сломают, наделают ошибок, а потом мучайся. В «Авито» решили доказать обратное: дать ответственность сразу и посмотреть, что будет.

В статье — о том, как выглядят испытания для стажёров и у кого точно нет шансов попасть в команду.

У разработчика решений для сервисной поддержки есть сервисная поддержка, которая работает на базе своего решения для сервисной поддержки. Можно запутаться? Да, если не отлажены процессы, но это не наш случай.

Привет, Хабр! Меня зовут Лера, я — тимлид аналитиков в той самой поддержке ITSM 365. Расскажу, как кастомизировали нашу систему под свои потребности и какие функции помогают мне управлять командой, а команде — закрывать основные задачи.

Всем привет! Меня зовут Олег Смоляков, в Яндексе я больше 15 лет занимался разработкой, а теперь отвечаю за улучшение процесса найма разработчиков.

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

TLDR: мы решили обновить процесс найма, вместо порой хаотичных собеседований в каждом отдельном сервисе внедряем единую систему оценки по профессии и уровню (например, «Senior C++ Developer»), кандидат, успешно прошедший оценку навыков, теперь сможет претендовать на аналогичные вакансии в любом из 90+ сервисов компании, а всё это вместе делает процесс найма прозрачным, понятным, без дублирования технических интервью и в целом эффективным для всех участников.

А теперь подробнее о том, почему мы на это пошли и как всё устроено.

В ИТ любят свободу. Проекты собираются за неделю, команды работают из разных часовых поясов, и мысль о том, что всех нужно оформить в штат, звучит как нечто из другой эпохи. Гибкость - это ведь суть всей индустрии: не держать, а подключать. Аутстафф стал естественным продолжением этой логики. Появился запрос - подключили двух разработчиков через партнёра, подписали договор, оплатили часы, и всё по-честному.

Но с точки зрения закона это далеко не всегда так просто. Аутстафф живёт где-то между аутсорсом, фрилансом и трудовым наймом, и от того, как именно выстроены отношения, зависит, на чьей стороне окажется инспектор. И вот здесь многие бизнесы начинают спотыкаться: формально всё чисто, а по сути нет.

Если убрать красивые слова, аутстафф - это ситуация, когда один работодатель «предоставляет» своих сотрудников другому. Формально они числятся в первой компании, а трудятся у второй. Для IT это удобно: не нужно расширять штат, платить взносы, вести кадровые документы, оформлять отпуска. Можно собрать проектную команду из десяти человек за два дня.

Но инспекции и суды такие конструкции воспринимают с настороженностью. Причина проста: слишком часто под аутстаффом прячут обычные трудовые отношения, чтобы сэкономить на налогах. ФНС и трудовая инспекция научились это видеть. Им не нужны слова «гибкая модель» и «оптимизация», они смотрят на то, кто управляет человеком, кто даёт задачи, кто несёт ответственность за результат и кто получает от этого прибыль.

Если разработчик сидит в офисе заказчика, имеет корпоративный e-mail, доступ к Jira и Confluence, участвует в стендапах, слушает руководителя проекта и работает по внутреннему графику, то все разговоры о том, что он «чужой сотрудник», бессмысленны. Он ваш.
Даже если у него в трудовой записано другое юрлицо, даже если все деньги проходят через подрядчика.

За последние годы рынок IT сильно изменился. Сейчас найм Junior-разработчиков стал гораздо выгоднее для компаний: конкуренция среди молодых специалистов выросла, а текучка кадров снизилась. Разберём, почему именно сейчас лучшее время инвестировать в молодых разработчиков.

Меня зовут Владимир, я внутренний аудитор. В своей работе я анализирую самые разнообразные бизнес-процессы и проекты.

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

Моя статья будет полезна и интересна:

• самому широкому кругу читателей – понимать, что такое RPA-роботы, для чего они нужны и как можно оценить эффективность их внедрения;

• топ-менеджерам – определить какие вопросы следует задать ИТ-команде и на что обратить внимание при реализации проектов;

• менеджерам ИТ-проектов – заранее оценивать риски и знать какие подводные камни могут быть;

• владельцам процессов – знать, как доказать реальную эффективность от внедрения RPA-роботов и подобных автоматизированных решений;

• финансистам – корректно подсчитать экономические эффекты.

После продажи своего розничного бизнеса в 2023 году решал чем же мне заниматься дальше. Занимался узконаправленной торговлей для мастеров индустрии красоты. Хотелось расширить ЦА. Несколько недель я планировал и размышлял на тему розничного магазина продуктовой торговли. И вдруг в какой‑то момент я подумал — «а может общепит?». От этой мысли меня бросило в дрожь. «Вот оно» — подумал я. У меня есть опыт розничной торговли и работы с массовым клиентом, но общепит не имеет всех минусов присущих розничной торговле. Это был чистый восторг.

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

Но все таки я всегда мечтал о том, чтобы сделать что‑то самостоятельно. Сделать свой бренд, сделать что‑то с самого нуля. Мне нравится создавать, и я это умею.

Это будет — Рамен, решил я! Именно про Рамен я подумал в тот же момент, когда я подумал про общепит. Сам Рамен родом из Китая, где он звучит как «ламянь». В ближневосточных странах это слово трансформировалось в «лагман». Само слово «рамен» это Японская вариация блюда. В Японии это блюдо трансформировалось и его приспособили к бизнесу и подаче в условиях огромного спроса. Именно из Японии Рамен попал в западный мир и приобрел бешеную популярность в Корее, США и некоторых странах Европы. Именно в пик этой популярности появилась и лапша быстрого приготовления — его величество «Доширак».

Всем привет!

Меня зовут Александр, я руковожу группой тестирования в мобильном приложении Ozon Seller.

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

Я пришёл в Ozon в 2022 году на позицию тестировщика, а уже через год стал руководителем группы. Причём произошло это, как и предыдущие два раза, достаточно спонтанно и неожиданно.

И вот однажды ко мне в офисе подходит один разработчик из смежной команды и спрашивает: «Расскажи, а в чём секрет? Как ты смог так быстро стать руководителем?»
Вопрос был для меня довольно неожиданным, потому что раньше я особо об этом не задумывался. Я буквально несколько секунд подумал и ответил примерно так: «Я просто старался хорошо делать свою работу, проявлял инициативу и не боялся брать на себя ответственность».

Интересный факт: через год этот человек и сам стал руководителем группы (не знаю, помогли ему мои советы или так совпало, но как есть).

И вот спустя время я всё же решил подумать над этим вопросом чуть глубже и сегодня хочу поделиться с вами своими мыслями.

На тему менеджмента и лидерства написано множество книг, в том числе и конкретно про IT сферу. Но, как правило, в них даны советы и рекомендации для тех кто уже является руководителем.

Но руководителями ведь не рождаются, ими становятся.

И как быть тем, кто только стремится стать лидером? Что делать, как себя вести, какие навыки развивать?

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

Когда люди начали собираться для обсуждения — будь то советы, кружки, комитеты — кого-то назначали фиксировать, «протоколировать». Чаще всего это была простая запись вручную: кто присутствовал, что обсуждали, какие решения приняты. Такой подход живёт даже сегодня в небольших организациях.

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

Позже, в XIX–XX веках, появились стенографические методы: сокращения, скоропись — чтобы не упускать ход речи. Но даже стенографист не успевал за несколькими говорящими подряд.

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

Всем привет! Я Тёма Логинов, за 4 года работы в digital я неоднократно искал работу, нанимал людей и помогал это делать другим.

Многие компании оформляют вакансии по-тупому: предлагают работу за три рубля или вешают на одного сотрудника работу целого отдела. Рассказываю, как распознать такие вакансии, чтобы уберечь себя от работы на муд***.

Сотрудники Sminex каждый день заходят на удобный корпоративный портал — почитать новости, заказать канцелярию или подать заявку на программу обучения, предложить идею или воспользоваться одним из сервисов. В серии статей расскажем, как с помощью индивидуальных разработок мы объединили в коробочном решении множество процессов и почему при переходе на наш портал в нём сложно узнать платформу «Битрикс 24».

Проходя интервью на управленческие позиции в IT (например, Team Lead), часто можно попасть на секцию по опыту менеджмента командой. Казалось бы, рассказываешь о своем опыте, о принятых решениях и в целом о том, как успешно твоя команда выпускает релизы... Пока тебя не спросят «Ну а как ты понимаешь, что команда работает хорошо?».

Или ты вроде все делаешь «правильно» на проекте, но недовольство заказчика растет, и твои люди подают заявления, потому что выгорели.

И в голове щелкнет: что‑то я, видимо, упускаю.

И сразу отвечу на вопрос, зачем это вообще может понадобиться. 

Есть четыре типовых ситуации:

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

2. Участие в due diligence. Ваша компания планирует покупку стороннего бизнеса. Тут аудит нужен для того, чтобы не повестись сходу на красивые продающие слова и не купить кота в мешке. С большой вероятностью, техническая сторона при объединении бизнесов может оказаться в вашей зоне ответственности, и нужно понимать, чем это грозит.

3. У вас попросили консультацию — на профессиональной основе или в формате помощи другу.

4. Вы не собираетесь ни на новую работу, ни покупать чей-то бизнес — вам просто кажется, что у вас сейчас на работе что-то идёт не так, и вы хотите всё оценить и понять, что именно.

В этой статье я расскажу, как адекватно и полноценно оценить состояние разработки. Меня зовут Андрей Бирюков, в разработке я 25 лет — начинал как разработчик, сейчас руковожу разработкой и клиентскими сервисами в InfoWatch. С этой темой я выступал на CTO conf, теперь подготовил для вас текстовую версию.

Рубрика «Кем работать в IT» — интервью с представителями IT-профессий, в которых специалисты рассказывают о тонкостях своей работы: плюсах, минусах, подводных камнях и заработной плате. Мы надеемся, что джунам и стажёрам она поможет больше узнать о том, что их ожидает на карьерном пути, а профессионалам — посмотреть на свою специальность через чужой опыт и, может быть, открыть для себя что-то новое.

Сегодня о своём опыте работы нам рассказал Артём Бачевский, владелец продукта в компании «Солар».   

Час интервью. Два часа на отчет. Раньше это были обсуждения, правки и поиск формулировок. Сегодня ИИ подсказывает выводы и рекомендации, позволяя эксперту сосредоточиться на анализе.

В этом кейсе рассказываем, как за три недели для компании HT Lab разработали сервис на нашей платформе PanteonOS, который автоматизирует обработку интервью и структурирует ответы по компетенциям, помогая экспертам быстрее готовить отчеты.

В мире IT, где всё меняется быстрее, чем обновляются версии фреймворков, умение мыслить критически стало новой суперспособностью. Без него — ни код написать, ни аргументировать архитектурное решение, ни выстоять в баталиях в комментариях на Хабре. Но за кулисами этого умения скрывается обратная сторона: постоянные сомнения, паралич анализа и выгорание от бесконечных «почему». Разберёмся, где заканчивается здоровый скепсис и становится невыносимо душно, и как развить в себе критическое мышление, не превращаясь в его жертву.

Если отбросить модные определения, критическое мышление — это умение не принимать информацию на веру. Это привычка проверять, искать второе мнение, анализировать, сопоставлять и только потом делать вывод.

Пример из практики любого разработчика: ты читаешь статью про новый паттерн проектирования — допустим, про Domain-Driven Design. Хочется сразу внедрить: «О, вот оно, правильное решение!» Но критически мыслящий инженер сначала посмотрит на контекст, изучит критику подхода, попробует на тестовом проекте и только потом решит, подходит ли это под конкретный продукт.

Именно это отличает критическое мышление от просто аналитического: не просто рассуждать, а искать объективность, балансировать между гипотезами и фактами.