Менеджмент

21 июля 2026 года Госдума приняла законопроект «О цифровых валютах и цифровых правах» сразу во втором и третьем чтениях.

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

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

Формально законодательная процедура ещё не завершена: документ должен пройти Совет Федерации, быть подписан Президентом и официально опубликован. Но сомнений в том, что закон будет окончательно принят, практически нет.

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

За последний год мы переписали почти всю проектную документацию в markdown и положили в тот же git, где лежит код. Причина простая: после перехода на Cursor и Claude Code так было удобнее работать. Модели нормально обрабатывают markdown и не лопатят десятистраничный google-док, диффы видно в PR, доки лежат рядом с кодом, который описывают. Всегда можно обратиться к инфе по проекту, внести обновления - короче пользоваться документом, а не хранить его для красоты.

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

Дать клиенту доступ в GitHub/GitLab — так себе затея сразу по нескольким причинам: там лежит то, что ему видеть не надо, это лишний разговор про безопасность, да и сам интерфейс гитхаба человека не из айтишки отпугивает. Плюс требуется регистрация. В итоге мы делали то же, что, по-моему, делают все: копировали markdown в google docs, чтобы клиент мог прочитать и покомментировать, а потом при каждом изменении заново выгружали и сводили комментарии руками. Год так жили.

Что смотрели, прежде чем пилить своё:

GitBook и Mintlify хотят, чтобы ты писал в их редакторе. Ради шеринга пришлось бы бросить тот самый workflow, ради которого мы в git и переехали. Плюс ценник.

Вчера, 21 июля, помимо того, что госдума приняла законопроект о регулировании криптовалютного рынка, Павел Дуров анонсировал встроенный в Telegram некастодиальный Gram Wallet. Это означает, что ключи, позволяющие распоряжаться криптовалютой, будут храниться у самого пользователя, а не у оператора сервиса.

Как сообщил Дуров, Gram Wallet должен появиться во всех приложениях Telegram уже этим летом. По его словам, пользователям станут доступны мгновенные переводы криптовалюты без комиссии. В основе переводов будет находиться блокчейн TON.

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

В статье рассматриваются ответы на следующие вопросы:

1) Что такое программа для ЭВМ с юридической точки зрения

2) Какие элементы программы для ЭВМ защищаются авторским правом?

3) Кто признается автором программы для ЭВМ?

4) Основные сценарии создания программы и распределения прав на нее

5) Личные неимущественные права автора программы для ЭВМ

6) Имущественные (исключительные) права автора программы для ЭВМ

7) Предоставление права использования и отчуждение исключительных прав

8) Права законного пользователя программы для ЭВМ

9) Ответственность за нарушение прав на программное обеспечение

ЕГЭ обычно сдают выпускники, но в мае 2025 его сдавали и мы, командой из 300+ человек, разбросанных по 177 школам Санкт-Петербурга, от центра до Кронштадта. Задача была одна — не дать упасть системе видеонаблюдения. Именно тогда мы поняли, что следующий подобный проект должен быть устроен иначе.

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

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

Поделюсь своими мыслями о том:

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

Привет, Хабр! Автор этой статьи — Александр, аналитик Directum Projects, и у него для вас провокационный вопрос: «Кто не любит деньги?». Пока вы думаете об ответе, дадим свою версию. Это руководитель проекта.

Привет, Хабр!

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

Я в IT уже пять лет. Из них последние два — в условиях, когда часть людей в офисе, часть в других городах, среди новых сотрудников все больше тех, кто родился в 2000-х. Ежедневные стендапы, квартальный фидбэк, контроль по онлайн-статусу — все это когда-то работало. Потом перестало.

Знаете, чем меня лично привлекал фриланс 15 лет назад? Примерно тем же, чем привлекает и сегодня — СВО-БО-ДОЙ. Фрилансер — это в первую очередь «свободный», и уже потом «копьеносец». Или, если хотите, сперва «вольный», и уже потом «стрелок». И в этом основная ценность данного формата работы, которая для меня до сих перевешивает многие плюшки найма по трудовому договору типа ДМС с ремонтом зубов, социального страхования или пенсии от государства.

Буду ли я отчаянно сопротивляться попыткам любого удаленного работодателя контролировать мою работу, пытающегося загнать меня в рамки и алгоритмы? Конечно, буду. Иначе, простите, зачем мне вообще фриланс?

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

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

Как мы сегодня измеряем работу разработчиков: velocity, story points, lead time, cycle time, число PR и закрытых тасок. Строим красивые дашборды, считаем DORA-метрики, прогнозируем сроки, оцениваем загрузку команд.

А вот измерение инженерных решений на зачаточном уровне. В лучше случае ADR и запись в трекере техдолга. Чаще — вообще ничего.

Существующая оценка качества инженерии субъективна.

Обычно это мнение тимлида с 3–5 годами опыта в одной-двух предметных областях. При этом именно инженерные решения определяют стоимость разработки через год-два: смогут ли десять разработчиков одновременно работать над кодом и можно ли вообще масштабировать продукт без переписывания половины кодовой базы.

Сегодняшняя парадигма проста: чтобы большой проект не развалился, достаточно вытягивать DESIGN + держать выше среднего CODE QUALITY. А 2026 год показал, насколько все забивают на SECURITY, а с перформансом справляются тем, что бигтехи держат под это отдельные перф-команды: как будто уже написание (или проектирование+генерация) эффективного алгоритма больше не влияет на то, кто действительно Senior.

Бизнесу почему-то ценен разработчик, который закрывает пять задач в день (Я слышал, что в Яндексе это даже нужно для подтверждения грейда). Даже если через полгода выясняется, что каждая новая задача требует правок в двадцати файлах, а LLM не хватает контекста, чтобы просто разобраться в архитектуре проекта.

Мы научились измерять скорость разработки. Но почти не измеряем качество инженерии. 

Что вообще такое инженерный уровень?

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

Меня зовут Юлия Аравина, я психолог и коуч IT-руководителей, а также наставник на курсах «Управление командой» и «Технический директор — СТО» в Яндекс Практикуме PRO. В этой статье я хочу разобрать, почему команда перестаёт доверять руководителю, за счёт чего формируется доверие и как его восстановить.

В прошлой статье я поспешил с публикацией и лишь в общих чертах объяснил, что такое Napominator Home. Сегодня, как и обещал, публикую подробное руководство, которое охватывает все этапы: от установки до ежедневного использования.

В этой статье вы узнаете, как установить систему, настроить её компоненты и пользоваться всеми функциями.

Расширенное редактирование и продвинутые ИИ-функции

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

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

Есть фраза, от которой у меня до сих пор дёргается глаз: «Да там ничего сложного — просто раскатим Scrum на все команды». Обычно её уверенно произносит человек, который пару недель назад сходил на двухдневный курс, получил красивый сертификат — и теперь искренне считает, что понял, как устроена разработка.

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

Сразу оговорюсь: проблема не в Scrum. Scrum — хороший инструмент, я сам его люблю и использую. Проблема в том, что его продают и покупают как серебряную пулю — универсальное лекарство от всех болезней доставки. А потом искренне недоумевают, почему на нескольких командах, которые пилят один продукт, всё превращается в хаос из зависимостей, интеграционного ада и созвонов ради созвонов.

Ниже — три вещи, на которых я набил шишки лично: (1) откуда взялся миф о всемогущем Scrum и почему сам Scrum Guide с ним не согласен; (2) почему «голый» Scrum, натянутый на несколько команд с одним продуктом, — это заявка на провал; (3) что реально работает в этом контексте — от LeSS до Team Topologies — и как в эпоху AI выбор смещается в сторону лёгких, потоковых, адаптивных подходов. Без хайпа, с источниками и из практики.

Предыдущие статьи серии:

1) Что спрашивают на собесах в 2025–2026: разбираем данные с 9 247 технических интервью

2) Реальные задачи с собеседований в Яндекс, VK, Ozon и Сбер — Go, Java, Python, React

И снова привет. Последняя статья из серии разбора данных моего пет-проекта. Поэтому сразу с места в карьер.

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

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

Я Наташа, менеджер проектов в Selectel. Уже дважды я выносила спринты из команд ногами вперед, и хочу поделиться этим опытом с теми, кто ищет предсказуемости и результативности в сложных технических продуктах.

Мы не планировали делать из этого материал. Просто в какой-то момент накопилось достаточно данных по запросам внутри корпоративной библиотеки Alpina Digital, чтобы можно было ответить на вопрос, какие книги читает нага IT-аудитория.

Через библиотеку проходят сотни тысяч сессий чтения от сотрудников крупных компаний. Разработчики, тимлиды, продакты, аналитики. Данные анонимизированные — мы видим агрегированную статистику по ролям, без привязки к конкретным людям. Выборка специфическая: только те компании, у которых есть корпоративная подписка, так что это не срез всего рынка. Но паттерны получились любопытные.

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

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

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

Чтобы упростить навигацию по материалам INFOSTART TEAM EVENT 2026, доклады собрали в пять профессиональных маршрутов: для ИТ-директоров, DevOps-инженеров, аналитиков, разработчиков 1С и руководителей проектов.

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