Менеджмент

Meet-Up: делаем видеоконференцсвязь (ВКС), которая не бесит

TL;DR: Накатили свою платформу для видеозвонков на Laravel + WebRTC. До 1000 человек в комнате, без лимитов времени, разворачивается за час на VPS. Коробочная версия + облако. Ищем тестировщиков, которые будут ломать и критиковать.

Disclaimer: ещё один велосипед

Да, мы знаем. На рынке есть Zoom, TrueConf, Телемост, VK Teams и ещё десяток решений.

Но когда на очередном созвоне коллега 20 минут не может подключиться, а ты платишь за функции типа "3D-аватары" и "встречи в метавселенной", которыми никто не пользуется - начинаешь думать.

А можно ли проще?

Спойлер: можно.

Разберемся поподробнее...

Пятница, конец спринта. Команда сдала всё в срок. Клиент доволен. Тишина в эфире. Я смотрю на экран и понимаю, работу затащили, как и всегда, но какой ценой?
Команда не выгорела, а я — да.

Выгорел, следя, чтоб не выгорела команда — иронично.

Специалисты, поработавшие много лет в IT, иногда чем-то напоминают людей преклонного возраста, которые встретившись, начинают рассказывать о наболевшем.

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

Привет, Хабр! Меня зовут Егор Дудин, я технический руководитель юнита «Деловые услуги» в Авито Услуги. В этой статье я излагаю своё видение построения и работы с обратной связью и её роли в крупной IT-компании. 

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

Под катом - кейсы из практики, примеры работы с фидбэком и 13 советов от меня.

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

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

Фаза 1 – высокие стандарты как источник перфекционистской культуры

Высокие стандарты – это естественная часть профессиональной среды. Однако проблемы начинаются, когда эти стандарты превращаются в культуру, где нет места для «неидеального» процесса. Это происходит незаметно:

На днях я стряхнул пыль с небольшого пет-проекта. Это простой блог, наверняка каждый из вас хотя бы думал о таком для себя.
В 2015 году я бы просто закинул файлы по FTP на хостинг за 100 рублей. Время деплоя: 30 секунд.
В 2026 году я потратил 4 часа. Я настраивал Edge Middleware, дебажил рассинхрон HTML между клиентом и сервером (hydration mismatch) и разбирался, почему облако не хочет дружить с моей базой данных из-за долгого пробуждения функций (холодного старта).

Где мы свернули не туда?
Это колесо Сансары, которое дало новый оборот.

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

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

Детективный контроль позволяет выявлять подобные случае по мере возникновения неблагоприятных событий. Наоборот, предиктивный контроль пресекает подобные исходы на корню. Именно на последних мы и остановим внимание в данной статье. Применительно к программному обеспечению подобный вид проверок тесно связан с термином SOD (Segregation of Duties).

Цель данной работы состоит применение методологии SOD в проектах внедрения корпоративных информационных систем, что обеспечит реализацию бизнес-процессов компании в ИТ-решении образом, исключающим/минимизирующим мошеннические действия со стороны работников. Достижение заявленной цели потребует решения следующих задач:

Привет, Хабр! Меня зовут Кияшева Екатерина, я занимаюсь качеством. Сегодня хочу поделиться опытом о метриках качества системно. Предложить примеры, провести взаимосвязи: Метрики ⇔ Процессы ⇔ Области управления. Эта статья для руководителей, кто и сам ищет решения, чтобы метрики: 

• не ломали команду,

• не показывали погоду, 

• работали в пользу продукта и бизнеса. 

Ограничения и рекомендации:

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

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

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

Я выбрала метрики завершенного цикла (рефлексии): они строятся на основе операционных и служат фундаментом для стратегических. Это позволило рассмотреть QA со всех ракурсов и не закопаться в деталях. Определение типов метрик приведено в разделе «О метриках».

Привет! Я Алексей, мне 31 год, и почти десять лет я работаю в ЮMoney — сейчас на должности менеджера по продукту. Как правило, крупные компании берут на такую позицию внешних кандидатов с опытом и наработанными твёрдыми навыками. У меня же опыта работы в этой сфере не было, зато я хорошо знал продукт благодаря многолетней работе в службе поддержки. Это и стало ключевым фактором при выборе кандидата.

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

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

Живой пример

Однажды мне в руки «по наследству» от предыдущего руководителя достался проект по автоматизации взаимодействия с подрядчиками. Задача важная: подрядчиков более 50, привлекаемых сотрудников — несколько тысяч, за всеми нужен учёт и контроль, который на тот момент осуществлялся полностью вручную, и занимался этим не один-два человека, а аж целый отдел. Неудивительно, что внутренний аудит это не устраивало, и нам было велено «срочно все автоматизировать». Генеральный директор поставил свою визу и отметил в календаре дату, когда ему нужен результат — через год.

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

Служба поддержки может блестяще укладываться в метрику SLA (service level agreement) и «закрывать» сотни чатов в день. Парадокс, но при этом обычно повышается температура: выгорают сотрудники, подгорает у клиентов и они уходят, и, как следствие, сгорает синим пламенем прибыль компании. Ещё один парадокс: это руководство компании само поставило специалистов в такие условия.

Готовых модулей для связки 1С с маркетплейсами сделали уже много, и на лендингах они все выглядят примерно одинаково: заказы, остатки, цены – все в комплекте. Разница проявляется позже — на возвратах, пересорте, маркировке, нескольких складах и попытках переехать на другую конфигурацию 1С без полной пересборки процессов.

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

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

В этот раз отличился Telegram-канал «Топор. Экономика», выдав новость, собравшую миллионы просмотров (на момент публикации 3 млн. просмотров). Звучит она так:

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

Всем привет! На связи снова Карьерный Хакер — тот самый консультант по поиску работы, который не ленится изучать технологии, амбассадор здравого смысла на рынке труда и в HR Tech :)

Сегодня расскажу, как я поймала баги при AI-оценке релевантности опыта, когда тестировала самые популярные в России HR Tech-решения.

Также обсудим, куда уходят ваши персональные данные при интеграции российских ATS с зарубежными AI и какие есть риски на уровне государства при «сливе» данных о кадровых резервах страны в Пентагон по мнению GPT (надеваем шапочки из фольги).

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

Погнали :-)

Всем привет!

Я недавно закончил подготовку курса по управлению проектами на основе 8-го издания PMBoK и у меня появилось время поделиться здесь своими мыслями по поводу особенностей управления проектами с разных точек зрения и в разных отраслях.

Сегодняшний пост будет, в основном, посвящен обзору PMBoK 8, его ключевым особенностям и отличиям от предыдущих изданий. На всякий случай, если кто вдруг не в курсе, PMBoK, также известный как Project Management Body of Knowledge или Свод Знаний по Управлению Проектами – это основной руководящий документ сообщества PMI (Project Management Institute https://www.pmi.org/). С момента своего появления в 1996 году, PMBoK пережил несколько переизданий, часть из которых оставили большой след в области управления проектами и в профессиональной жизни многих руководителей проектов.

Особняком стоит 7-е издание, на данный момент – предпоследнее, которое тоже сильно повлияло на отрасль и участников, но этот след справедливее было бы назвать травмой. Несмотря на наличие большого количества передовых идей и внедрение новых подходов, 7-е издание оказалось воспринято сообществом неоднозначно и скорее даже с негативом. Уж слишком радикальными и, что самое главное, не всегда релевантными и практически применимыми оказались нововведения. Да и в целом, документ производит впечатление какого-то компромиссного недоразумения, в котором собрали новые концепции, скопипастили определения и целые разделы из предыдущих изданий, но местами просто не проверили соответствие одного другому.

Как одна журнальная статья, написанная 70 лет назад, поменяла всю инвестиционную индустрию и принесла ее автору Нобелевскую премию.

В одном из последних интервью ее автор вспоминал: «Когда люди восторгаются моей Нобелевской премией, я люблю говорить им, что Нобелевская премия не была моей самой большой наградой. Моя самая большая награда была вручена мне в мужском туалете большого отеля в Вашингтоне, округ Колумбия, после ужина, где-то между Рождеством и Новым годом 1990 года»...

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

Я разбираю систему из четырёх метрик — estimation accuracy, task complexity, variability и volatility — которая помогает видеть устойчивость проекта, прогнозировать перегрев и принимать управленческие решения без усиления контроля над командой.

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

Сегодня мы в Beeline Cloud решили поделиться свежими публикациями на нашей DIY-площадке «вАЙТИ». Это — подробные технологические материалы и относительно легкие разборы смежных тем: от лайфхаков по теме eCommerce-разметки и React Server Components до опыта разработки видеоаналитики на базе открытых решений.

Недавно один мой приятель после релокации переехал из дома в квартиру. Места стало меньше — и в приглашении на день рождения дочери появилась фраза:
“No more physical toys.”

Не потому что он стал «строгим родителем».
А потому что складывать уже некуда, игрушек слишком много и каждая новая мгновенно обесценивает предыдущие.

В бизнесе мы ведём себя точно так же. Мы обожаем новые «игрушки»: