Управление разработкой *

Cloud Gaming и VDI — разные технологии, применяемые для разных задач и даже для разной целевой аудитории. Вместе с тем, если заглянуть к ним под капот, можно увидеть, что у технологий есть много общего — например, одинаковые принципы стриминга видеопотока, методы сжатия передаваемых по сети данных и борьбы с потерями сетевых пакетов. Таким образом, при разработке Cloud Gaming можно отчасти опираться на технологии, примененные в VDI, и наоборот. Именно так мы и поступили при создании сервиса VDI (Cloud Desktop) для облака VK Cloud.

Привет, Хабр. Меня зовут Кирилл Черников. Я руководитель Команды клиентской разработки в VK Tech. В этой статье я расскажу об особенностях Cloud Gaming и VDI, о разнице в требованиях к сервисам, сложностях адаптации игрового решения к задачам VDI и о полученных результатах на примере сервиса VK Play Cloud и платформы VK Cloud.

Очень часто основная сложность заключается в том, что команды берут в работу задачи, которые находятся в отрыве от ключевой цели, определённой бизнесом. Четкое понимание ответа на вопрос «Зачем мы это делаем?» даст не только большей координации в работе, но и большего экономического эффекта от выполнения тех или иных инициатив. Практика показала, что внедрение методологии OKR и её активное продвижение внутри компании помогает привнести ясность в работу сотрудников.

Разработать электронную начинку радиоэлектронного прибора — половина дела. Вторая половина — корпус.

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

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

Немного обо мне. Меня зовут Юрий, через месяц будет 16 лет с моей первой записи в трудовой книжке о работе в IT. Закончил мехмат, немного занимался наукой, работал в крупном американском аутсорсе, затем в красно-синем российском банке и последние 8 лет тружусь в технологических и AI стартапах. Да, столько опыта, а хоть что то написать решил только сейчас. В общем погнали.

Я лично не разделяю руководство в директивном смысле и лидерство на какие то разные сущности и считаю, что это лишь разные грани одного и тоже умения сподвигать людей выполнять коллективно задачи, превосходящие возможности одного человека. Это можно сравнить с кластерными технологиями как в режиме single‑master так и в режиме multi‑master.

Как ни странно даже если кажется, что ты single‑master и якобы единолично руководишь группой разработчиков или нескольким группами, то есть либо master более высокого порядка либо неявный master в виде «опытного разработчика», которые в значительной степени оказывают влияние на процесс, либо и то и другое, поэтому как принято в мат. доказательствах будем рассматривать более общий случай multi‑master. Это к тому, что все мы «стоим на плечах гигантов» и благодарны за советы старших товарищей.

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

Все разработчики знают, что такое техдолг.

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

Предлагаю разобраться, что же это такое, откуда берется и что с этим всем можно делать.

История Solar appScreener началась в одной из российских IT-компаний, в которой тогда работала команда основателей «Солара». Они занимались консалтинговым бизнесом и наблюдали кардинальные изменения на рынке, которые стали почвой для будущей разработки продукта в сегменте application security.

К 2014-2015 гг. проблема безопасной разработки приложений стала острой и заметной не только для отраслевого сообщества, но и регулярно привлекала внимание общественности. Более чем в 75% успешных кибератак уже тогда эксплуатировались «дыры» в ПО, которое в то время было самых слабым звеном с т.з. технической защиты. Например, 15% от всего количества опубликованных уязвимостей приходилось на уязвимости для платформы Android. Громким событием первой половины 2010-х также был хакерский взлом AppStore, в ходе которого в ряд приложений был внедрен вредоносный код XCodeGhost.

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

Так возникла идея российского AppSec-продукта: для отечественных компаний, на родном языке, с понятными рекомендациями, четким анализом и наукоемкими технологиями под капотом.

Любой тимлид когда-то был джуном, а многие крепкие команды начинали как стартап на энтузиазме. Пока вас трое-пятеро — всё просто: драйв, мемы, кофе на кухне и общее чувство плеча. Но команда растёт — и вот вместо «давайте быстро созвонимся» появляются OKR, аллхэндсы и три уровня согласований.

Главная задача руководителя при этом не меняется: как замотивировать людей, чтобы им было интересно работать. И, увы, универсальной кнопки не существует — то, что отлично работает в стартапе из десяти человек, не взлетает в корпорации на тысячи. Впрочем, если бы все было так просто...

Меня зовут Антон Дмитриев и я хэд разработки Почтовых систем МойОфис — гибкой системы с почтой, календарем, контактами, задачами и документами. Основное ядро продукта написано на Go, но технологический стек включает Python, C++, JavaScript/TypeScript и React.

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

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

Автоматизация CI/CD для embedded-систем решает эти проблемы, хотя требует начальных усилий на настройку инфраструктуры.

Почему одни команды релизят предсказуемо и без героизма, а другие тушат пожары на продакшене каждую неделю?

Мы решили выяснить, какие инженерные практики превращают разработку в систему с понятными процессами и предсказуемыми результатами.

Исследование 100+ респондентов.

Всем привет! Меня зовут Саша Симоненко, и я операционный директор кибербез компании Xilant. Эта статья родилась из моего сентябрьского выступления на конференции KazHackStan 2025 в Алматы, где рассказывал, как качественные бизнес-требования помогают избежать проблем с безопасностью.

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

На конференции PMSOFT этого года услышал утверждение, которое потом подтвердили преподаватели МГТУ им. Баумана на курсе «ИИ в управлении проектами»: «ИИ не будет управлять проектами. ИИ будет избавлять менеджеров от рутины, чтобы те сосредоточились на стратегии». Это не маркетинг. Это то, что я наблюдаю на практике последние 8 месяцев.

В 2025 году аудитория ВКонтакте достигла 92,5 млн пользователей в месяц. Пользователи ВКонтакте активно используют все внутренние сервисы, в том числе мини-приложения и игры, которые любой внешний разработчик может представить многомиллионной аудитории с помощью VK Mini Apps.

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

Подготовил обзор 10 популярных таск-трекеров и основных обновлений, которые выкатили в 2025 году.

Рассказываю про новые возможности для автоматизации, AI-помощники и AI-агенты, переосмысление UI-дизайна, новые интеграции и гибкие настройки под разные команды.

19 видов диаграмм, история и будущее Ганта, выбор между скрам и канбан, основы тайм‑менеджмента, краткий курс по менеджменту, геймификация канбана, кросс‑командные проекты и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Как систематизировать работу с техническим долгом

Техдолг растёт, пока его никто не контролирует. Мы решили это так: выделили отдельную доску в Jira, разделили процесс на Backlog → To Discuss → Ready for Development → В работе, проводим регулярный груминг, оцениваем и приоритизируем задачи, сделали быстрые фильтры и дашборд для контроля времени.

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

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

Устали от того, что 2SP+2SP ≠ 4SP? Не знаете, как объяснить, что у одной команды фича на M большемерит, а у другой команды фича на L маломерит и потому они займут примерно одинаковое время? Тогда вам сюда!

В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках. Это — с одной стороны. С другой стороны — ругают LLM, потому что код там не всегда чистый и, дескать, программирование с LLM — это не программирование вовсе, и навыки такого программиста ничего не стоят.

Мне приходит на ум то, что в принципе мы подобный слом уже видели лет 15–20 назад. Для программиста старой школы сутью программирования, собственно, было постановка задачи, её реализация с помощью алгоритма и оптимизация этого алгоритма по скорости. Сам инструмент — язык, а уж тем более чистота кода — считалась вторичной. Задачей программиста было написание в принципе работающей программы.

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

Требования к программистам поменялись из-за изменения бизнес-требований. Если раньше задачей программиста было придумать и реализовать программу (он одновременно был и бизнес-аналитиком, и дизайнером, и архитектором, и алгоритмистом), то сейчас появилась возможность создавать ТЗ и интерфейс не программистам. Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.

Инновационный процесс принято разделять на две принципиально разные, но взаимодополняющие фазы: нечёткую начальную (Fuzzy Front End, FFE) и структурированную завершающую (Structured Back End, SBE).

OKR — штука в целом полезная, если знаете, зачем и как её внедрять.

Сегодня я не собираюсь вам продавать OKR как «идею» или «мечту» как способ достичь того, что не получается с помощью обычных средств. Моя цель сейчас — скорее, рассказать вам, как сделать в инструменте удобный механизм ведения Целей и Результатов (а именно так переводятся Objectives and Key Results) их дальнейшего отслеживания. В качестве инструмента будет выступать Jira, в качестве дополнительного удобства — плагин Structure с его удобными фишками. Рассказ будет поделен на 2 части — о создании механизма и о создании мониторинга.

В конце вас ждёт инструмент, который поможет вам сэкономить на покупке платного плагина для Jira. И который вы сделаете сами с помощью этого гайда.

Часть 1. Создаём механизм

На этапе, когда в компании началось массовое внедрение и команды начали знакомиться с этим подходом, предлагалось ведение всех целей в таблицах и файлах-документах. Для одной команды — вполне себе неплохой вариант, но когда команд за 30 и часть Целей зависит от других Целей, то понять общую картину в куче Excel-таблиц, где каждая команда, хоть и соблюдая общие принципы, но всё же ведет все по-своему — становится крайне тяжело.  И мне это очень не понравилось.

Я решил попробовать найти или сделать механизм для этого.

В бигтехе — всё ради системы. В Soft Media Group — всё ради людей. Здесь ценят чужое время, дают ответственность и не делают культ из митингов. Именно поэтому те, кто однажды ушёл, часто возвращаются.

В статье рассказываем, кто такие Soft Media Group и как работа в небольшой команде помогает развивать ключевые скиллы.