Российский IT-бизнес любит сюрпризы от государства. Обычно они прилетают в самый неподходящий момент. На этот раз из проекта поправок к Налоговому кодексу.
С 1 января 2026 года может исчезнуть льгота по нулевой ставке НДС для ПО из реестра Минцифры. Та самая, ради которой тысячи компаний годами шли через бюрократический квест, чтобы попасть в реестр.
Генеративные модели работают в основном на цифровых вычислениях: десятки или сотни шагов через большие сети на GPU. Это энергозатратно и не всегда быстро. Для AR/VR, где всё должно летать прямо здесь и сейчас, такой подход слишком тяжеловесный.
Учёные из UCLA пошли другим путём: пусть вместо транзисторов работает свет, а тяжёлую математику решают интерференция и дифракция.
У нас было:
• 11 общебанковских целевых сервисов, называемых платформой или платформенными сервисами,
• 75 бизнес-продуктов с бэкграундом в виде форков не поддерживаемых легаси сервисов,
• 583 строчки/задачи в Google Таблицах в виде продукт/платформенный сервис, на который ему надо перейти/срок завершения перехода.
Но если ты РМ, то по факту обязан хоть раз в жизни столкнуться в с висячным легаси-проектом, который заведомо не завершится в указанные сроки с указанной постановкой задачи.
Итак, меня зовут Алевтина, я РМ в Альфа-Банке, канале ЮЛ, и в моей жизни случился такой проект. В этой статье я расскажу, как я решала проблему прозрачности легаси-проекта, какие шаги предпринимала для того, чтобы проект сдвинулся с мёртвой точки, и какой результат был достигнут по итогам рефакторинга проекта.
Когда человек решает идти по пути менеджера в разработке, например, в начале карьеры или, особенно, уже работая в команде разработки, то приходится фокусироваться на знаниях, которые порой трудно классифицировать и уложить в своей голове. В отличие от разработчика, чей фокус часто сужен до решения конкретных технических задач, менеджеру приходится иметь дело с менее осязаемыми инструментами: процессами, коммуникацией и людьми. В основе своей они имеют другую природу, потому что здесь больше неопределенности и различных инструментов, которые должны помогать в работе. Часто менеджер фокусируется на выполнении правил фреймворка, на механике какого‑нибудь инструмента или метода, забывая, что в конечном итоге пользователь должен получить ценность. Вполне возможна ситуация, при которой все условия фреймворка выполнены, процесс разработки «настроен», на доске сотни выполненных задач, но пользы от них не так много, как кажется. И заказчики, и конечные пользователи могут не оценить вклад команды разработки и самого менеджера. Ситуация, увы, частая и очень обидная. Главная сложность заключается не в изучении теории, а в её применении на практике, где ключевую роль также играет и «социальный фактор».
Попытки внедрить новые практики, такие как Scrum или Kanban, часто наталкиваются на сопротивление команды, которой комфортно работать в существующем workflow. Иногда проблема усиливается часто меняющимися менеджерами, каждый из которых приносит «волшебную таблетку», оставляя после себя след из никому не понятных артефактов. В результате процессы внедряются поверхностно, лишь создавая видимость изменений. Команда двигает тикеты на Kanban‑доске — значит, у нас «Kanban». Проводятся спринты — значит, у нас «Scrum». Но настоящей ценности такие формальные преобразования не приносят.
Идеальной методологии тестирования не существу… А вот и да, существует.
Привет, Хабр. На связи Константин Синанов, директор отделения аутсорсинга экспертизы тестирования, и Александр Александров, ведущий инженер-тестировщик в IBS. В этой статье мы расскажем о системном подходе к тестированию, который применяется в нашей компании на проектах любой сложности.
Хабр привет! Меня зовут Кристина Ширкунова, я ведущий аналитик в «Ренессанс жизнь», а до этого 5 лет работала в заказной разработке. Я участвовала в большом количестве проектов: начиная от обычных сайтов и заканчивая цифровой трансформацией достаточно крупных компаний. Почти в каждом проекте требовалось верхнеуровневое описание, потому что проекты были разные, объем большой и команды часто обновлялись. Именно об этом я и написала: как сделать верхнеуровневое описание функциональности максимально эффективно для команды.
В этой статье я расскажу, как создать верхнеуровневое описание, которое прекратит хаos в проекте, ускорит онбординг в разы и станет вашим главным аргументом в спорах о требованиях.
Один из самых результативных инструментов управления командой эффективного руководителя является фасилитация. При этом важно понимать специфику фасилитации руководителя. Традиционно фасилитатор как бы вне процесса обсуждения и поиска решения, его функция помогать команде, причем сам фасилитатор может и не обладать компетенцией в обсуждаемой ситуации, да и ответственность за принятое группой решение он тоже не несет. В случае же эффективного руководителя есть своя специфика - у фасилитатора и компетенция есть, и ответственность за принятое решение прежде всего лежит на нем. В связи с этим важно учесть особенности, которые имеет фасилитация руководителя.
Во-первых, самый главный смысл фасилитации команды руководителем – это вовлечение всей команды в поиск решения, то есть создания ситуации, когда решение будет не навязано сверху, а родится самими сотрудниками, а значит и выполнение этого решения будет более результативным, так как это их собственное решение.
Во-вторых, в мозговом штурме, а это и есть главный инструмент и смысл фасилитации, есть возможность услышать мнение каждого, а значит можно найти решение, которое сам руководитель в силу своих особенностей мог бы и не увидеть. Тут, кстати, очень важно узнать мнение Людей-Логики в команде, так как именно они могут быть генераторами идей. Обычно свое мнение они не спешат высказывать публично, на фасилитации же им проще это сделать.
В-третьих, участвуя в фасилитации и не высказывая свое мнение открыто, что запрещено самой логикой фасилитации, руководитель получает возможность услышать мнение тех, кто больше, чем он имеет отношение к реальной деятельности. Ведь часто бывает, что руководитель, который сам уже давно не работает «в полях» имеет не совсем объективное представление о реальности, и на основании этого искаженного мнения строит свое стратегическое планирование. Именно это бывает у успешных руководителей, которые пытаются подогнать реальность под свое представление о ней, что и приводит к потерям в эффективности бизнеса и даже его краху, примеры Motorola и Nokia отличная тому иллюстрация.
Я давно носил мысль о том, чтобы изложить на бумаге свое видение о том, каким образом, какими инструментами и по каким шагам можно было бы организовать внедрение полноценного QA в процесс разработки аппаратного обеспечения. И вот относительно недавно, в рамках тестового задания при собеседовании, мне довелось составить подобного рода документ описывающий весь процесс от аудита до практически полной автоматизации процесса тестирования. Для того, чтобы получить на него всестороннюю обратную связь и услышать мнения на этот счет - я решил написать статью об этом.
Материал может быть полезен руководителям и тем, кто внедряет тестирование в текущие, возможно уже состоявшиеся процессы разработки. Насчет управления качеством и тестирования можно было бы написать целую книгу, я решил лишь описать основными вехами, как и с какой стороны подойти к этой непростой задаче.
Всем интересующимся - добро пожаловать под кат!
Каждая компания двигается по шкале от незрелой к зрелой и обратно. Это всегда динамика. Сегодня вы образец, завтра вы устаревшая помойка. Если 10 лет назад для наведения порядка внедрялся какой-нибудь "каскадо-водопадный PMI", 5 лет назад гибко-адаптивный Agile-OKR, то сейчас есть динамика к культуре проведения экспериментов*.
Произошло это по разным причинам, главными считаю - изменение горизонта планирования и задачи на сокращение издержек. На сегодня, нужно планировать либо на 30 лет вперед и бороться за новые рынки (в том число создавать их), либо сосредоточиться исключительно на текущей выручке.
*Статья состоит из двух блоков - критика и предложение. Контекст: продуктовая ИТ компания среднего уровня, не стартап и не из ТОП 50.
Альтернативная нотация описания функциональной архитектуры и архитектуры интеграций для решения задач ИТ-развития в рамках проектных задач, продуктового развития и инициатив бизнеса для командной работы в едином информационном поле бизнес и системных аналитиков, архитекторов, разработчиков, тестировщиков и специалистов поддержки.
Каждый разработчик рано или поздно сталкивается с ситуацией: из команды уходит «тот самый» человек, который держал в голове половину архитектуры. Вместе с ним уходит не только опыт, но и часть будущего проекта. В статье делюсь мыслями и подходами, как минимизировать потери при передаче знаний, какие форматы работают, а какие — нет, и почему документация должна быть живой, а не мёртвым архивом на Wiki.
Агентные ИИ-системы обещают ускорить разработку, но ускоряют только там, где уже налажен быстрый поток поставки: автономные продуктовые команды, короткие циклы, непрерывная обратная связь. Реальность же прозаична: по DORA многие организации релизят реже раза в неделю, у четверти change failure rate доходит до 40%, а инциденты чинятся неделями.
В статье разбираемся, почему без «взрослого» Agile и DevOps ИИ-агенты всего лишь делают узкие места заметнее, и как организационная агентность (право и способность команд действовать) становится предпосылкой для реальной выгоды от ИИ.
Привет. Меня зовут Антон Глоба, я предприниматель и основатель контент-агентства.
В жизни каждого предпринимателя бывает момент, когда кажется, что все рухнуло. Для меня это был 2014-й: у Банк24.ру отозвали лицензию, а на моем счету зависла вся предоплата по крупному контракту. Тогда я впервые увидел, что спасает бизнес в кризис — не деньги, а люди и их принципы.
Привет, Хабр!
Часто тимлидов интерсует вопрс: как измерить продуктивность разработчиков так, чтобы это имело смысл? Часто можно наблюдать, как одни менеджеры пытаются оценивать работу команды количеством коммитов, другие — числом закрытых тасков, третьи искали «та самый единственная метрика», которая покажет продуктивность сразу всех и каждого. Такой метрики не существует, и погоня за ним часто приводит к курьёзным (а иногда и печальным) результатам.
В этой статье я поделюсь свежим подходом к этой проблеме — фреймворком SPACE. Он предлагает смотреть на продуктивность инженеров комплексно, по нескольким измерениям сразу. Но для начала давайте разберёмся, почему вообще так сложно измерить эффективность разработки.
Подготовил сборник из 150+ тестовых заданий для продактов и проджектов – забирайте, чтобы повысить свои шансы пройти собесы и трудоустроиться в нужную компанию!
В сборнике найдете тестовые от таких компаний как: Яндекс, Т-Банк, ВК, Авито, Озон, АльфаБанк, МТС, Сбер, AviaSales, SkyEng, 2ГИС, inDrive, HeadHunter, Нетология, Мегафон и многих других.
В этой статье я собрал то, о чём люди обычно спорят в комментариях. Мы поболтали с комьюнити про ИИ на июльском фестивале для айтишников. Чтобы приблизить условия к диванным обсуждениям, уселись на пуфиках, а желающим выдали трубку мира.
Никаких регалий, экранов, душной модерации с «нативными» интеграциями. Просто накидывали на вентилятор боли и передавали друг другу микрофон. Это был чистый экспромт без заготовок, даже с матом, но в статье мы его убрали, чтобы не ранить чувства читателя.
Мы очистили обсуждение от корпораций, брендов и даже имён, собрали дебаты в нашем шатре и не афишировали их на лендинге фестиваля. Были сомнения, придут ли люди, будут ли открыты, но я считаю, всё получилось.
Когда мы начали расти в отделе, мне казалось логичным ввести разные системы контроля: отслеживание рабочего стола, трекеры времени, «умные» дашборды. Хотелось прозрачности — чтобы понимать, кто чем занят и как распределяются часы.
Мы пробовали разные инструменты — Time Doctor, Insider и тд. На первый взгляд все выглядело удобно: дашборд продуктивности, графики активности, таблицы задач. Но на деле сотрудники ощущали себя дискомфортно, чувствуя себя под слежкой, ведь так оно и было. Мое мнение теперь: мы ошиблись и потратили время и средства на инструменты, которые не принесли пользы. И вообще для программы отслеживания рабочего времени нужно переименовать в инструменты слежки за сотрудниками. Как будто сериал “Разделение” воплотился в жизнь. Но обо всем по порядку
В крупных компаниях одной из важных руководящих ролей является операционный директор. Его задачи включают в себя контроль операционных аспектов стратегии компании и предоставление необходимой информации генеральному директору и совету директоров, а также внешним сторонам. Роль операционного директора может варьироваться в зависимости от размера компании.
В этой статье попробуем разобраться, кто же такой Chief Operating Officer, какие задачи он выполняет и какие качества необходимы, чтобы им стать.
Запустил свой B2B ИТ-стартап, потерял много денег, еще больше нервов, набрался опыта и ушел в наём. Какие выводы я сделал и какие советы могу дать начинающим стартаперам.
Привет! Меня зовут Андрей, в ЮMoney я работаю с 2019 года, возглавляю новое бизнес-направление — BaaS, а до этого руководил стримом карточных продуктов. В этой статье отвечу на вопрос: что делать бизнесу, если он хочет выпускать свои карты и кошельки, но не хочет получать лицензию ЦБ и строить банковскую инфраструктуру с нуля?
Ответ на этот запрос рынка — подход Banking-as-a-Service (BaaS). Я расскажу, как мы в ЮMoney прошли путь от первых кобрендинговых карт до полноценной платформы и запустили BaaS-решение ЮSoft. В статье разберу мировой BaaS-тренд, рассмотрю предпосылки запуска у нас и оценю конкретные выгоды для российских компаний: от снижения затрат до новых источников дохода.
