40+ часов даунтайма, лежащие базы и тонны упущенной прибыли. Что делает премиальный хостинг с ценником выше рынка, когда у него без конца падает инфраструктура, и как на это реагируют клиенты.
Итеративный дизайн на самом деле не только про дизайн, но и про подход к созданию продукта. Он связывает дизайнеров, команду разработки, PO (product owner), PM (project manager) и пользователей в систему, где каждый влияет на то, каким становится продукт.
Дизайнер перестаёт быть исполнителем макетов и становится участником продуктовых решений. Разработчик перестаёт просто отрисовывать экраны по макету и влияет на продукт на протяжении всего его жизненного цикла, замечает то, что не видно на этапе проектирования, и предлагает свои гипотезы. Пользователь получает возможность формировать будущее продукта через свою обратную связь, а команда быстрее проверять гипотезы и корректировать направление работы. PO перестаёт быть просто постановщиком задачи, он помогает расставлять приоритеты и принимает решения на основе того, что показала каждая итерация.
В этой статье поделимся опытом использования итеративного подхода в дизайне в разных масштабах: на крупных веб-сервисах и больших продуктовых итерациях, на маленьких недельных спринтах и на более локальных задачах — презентациях, сайтах, лендингах. С какими сложностями столкнулись, в чём преимущества и недостатки.
Через несколько лет после сдачи проекта новая команда открывает модель. Формально всё на месте: проектная документация сохранена, каталоги и базы данных переданы, архив доступен. Но как только нужно продолжить работу — внести изменение, проверить выпуск или подключить нового подрядчика, — появляется главный вопрос: можно ли понять, почему данные устроены именно так?
Я давно сознательно избегал трех бесячих тем: фронтир-моделей, автономных агентов ради самих агентов и разговоров про AI-native компании. Потому что вокруг них сейчас слишком много маркетинга и слишком мало инженерной конкретики.
Но после доклада AWS про команды в мире агентского ИИ стало понятно, что интересный вопрос тут не какая модель победит, а какая операционная модель переживет удешевление разработки и придумали ли уже что-то по делу. Статья перед тобой разбор тысяч публикаций про то что думают всяки MAANG о том какие команды в итоге получатся.
Принятие решений на основании данных, это то, что отличает профи от дилетанта.
Добрый день! Меня зовут Игорь. Я практикующий маркетолог. Сегодня расскажу как маркетологу принимать решения на основе данных и при чем тут философия
Привет, Хабр! Когда заходит речь о SOC, в голове обычно всплывает техническая картина: вредонос на рабочей станции, фишинговое письмо, подозрительные PowerShell-команды, сканирование портов, эксплуатация уязвимости, скомпрометированный аккаунт, аномалия в инфраструктуре. Для крупного ритейла этой картины давно мало. О том, как киберугрозам противодействуют в М.Видео расскажет Евгений Прошин, руководитель отдела мониторинга и реагирования на инциденты.
Дашборд зеленеет, число багов падает, команда получает похвалу — а через пару недель прод ловит инцидент на ровном месте. Так бывает, когда метрики дефектов становятся целью для отчёта и начинают подменять реальное управление качеством. В статье — шесть типовых ошибок: от количества багов как личного KPI до доли переоткрытых задач, которую легко обойти красивой статистикой.
Помните времена, когда трава была зеленее, мобильный интернет помегабайтным, а Apple осваивала непаханые поля смартфоно-игровых ферм? Начало 2010-х было очень интересным временем, когда мобильные студии создавали целые новые жанры, пытались перенести или адаптировать старые концепции и игры, попутно решая задачи, от которой у десктопного разработчика начинал дергаться глаз. Вот и EA решили взять культовые франшизы SimCity и The Sims со всеми их терабайтами ассетов, сложнейшей симуляцией дорог, пробок и отдельных симов, и попробовать затолкнуть это в карман.
В кармане у пользователя тогда лежал условный iPhone 4 или 5 с уже тогда куцым бюджетом оперативной памяти в районе 100–300 МБ на всё про всё, но айфоновладельцы были "платящей" аудиторией, поэтому игровое подразделение метило в основном в них. Как не превратить смартфон в обогреватель и словить ООМ в первые минуты игры? Выкинуть честную симуляцию на помойку, превратить симов в конечные автоматы, а город сделать хитрой иллюзией из текстурных атласов и таймеров. Раскажу немного как устроены SimCity BuildIt и The Sims Mobile с инженерной изнанки, кода почти не будет, да он и не нужен тут для понимания, а еще будет немного грустинки по российскому подразделению EA, и фотки с закрытия офиса в 2016.
Самый дорогой сотрудник для компании — тот, который уже найден, но еще не может приступить к работе.
Каждый час между принятием решения о найме и фактическим выходом сотрудника означает потерянное рабочее время, дополнительную нагрузку на HR и задержку бизнес-процессов.
И хотя кадровый документооборот давно стал электронным, само оформление сотрудников редко можно назвать быстрым. Причина проста — документы по-прежнему приходится получать, проверять, сопоставлять и переносить в корпоративные системы.
В итоге документы остаются одним из последних бюрократических барьеров между кандидатом и его выходом на работу. Под катом рассказываем, как Smart Engines удалось решить эту задачу и сократить обработку кадрового пакета до нескольких секунд.
Разбираем, зачем электронные производственные журналы нужны в промышленной архитектуре, если уже есть SCADA, MES и ERP. Поговорим о ручных данных с площадки, мобильном и голосовом вводе, связке с отчётами и API, а также о том, где AI действительно помогает, а где его нужно обязательно проверять.
Открыть список задач → переключиться на диаграмму Ганта → открыть карточку задачи → перейти в профиль исполнителя → вернуться обратно на вкладку с диаграммой. Повторить десятки раз. Время уходит не на решение задач, а на переключение между вкладками и попытки понять, что вообще сейчас происходит.
Рассказываем не про плохого Ганта — а про полезные функции нормальной диаграммы. Читайте статью, чтобы узнать, как делать максимум с помощью проектного инструмента и перестать топтаться на одном месте.
«Автоматизируй! AI! ИИ-агенты!» слышит ИТ-директор каждый божий день. В переговорках только и разговоров, что об автоматизации. При этом 95% ИИ-пилотов в компаниях проваливаются, то есть не достигают измеримого ROI. Давайте разбираться, почему, несмотря на популярность технологии, ИИ-инициативы в компаниях обречены.
В 2025 году группа японских исследователей выдвинули гипотезу: если нанести на тело коровы чёрно-белые полосы, как у зебры, то количество укусов кровососущих мух сократится. Учёные создали три группы японских чёрных коров: неокрашенных, с чёрными полосами на белом фоне и с белыми полосами на чёрном фоне — полную имитацию зебры. Результат: у коров, раскрашенных как зебры, количество укусов снизилось на 50%. Именно такое чередование цветов, а не просто полоски, сбивало мух с толку. Но увы, за этот эксперимент с коровами-зебрами ученые получили лишь Шнобелевскую премию по биологии. Есть ощущение, что их явно недооценили...
Проблема: 20+ проектировщиков наружных сетей связи при оформлении тома рабочей документации НСС (наружных сетей связи) тратили несколько дней на ручное черчение продольных профилей сети с выявлением коллизий с другими наружными сетями и на ручное вычисление всех необходимых позиций спецификации оборудования и материалов по данному разделу.
Решение: внедрение технологии информационного моделирования наружных сетей связи, позволяющее с помощью создания 3D-модели наружных сетей связи генерировать продольные профили сети и спецификацию из нее за несколько часов, устраняя коллизии с другими сетями (водоснабжение, водоотведение, электроснабжение, освещение, тепловая сеть) в автоматизированном режиме.
Результат: время получения основных графических данных рабочей документации по наружным сетям связи в среднем по рядовому тому рабочей документации сократилось с нескольких дней до нескольких часов, риск допуска ручных ошибок свелся до нуля, адаптация проектировщиков для применения данной технологии — 3-5 дней.
Привет, Хабр! Меня зовут Рудольф Караджаян, я — руководитель проекта внедрения и развития технологий информационного моделирования наружных внутриплощадочных сетей в ПИК Digital. Сегодня расскажу, как мы решили одну из непростых задач в BIM-автоматизации — помогли перейти проектировщикам наружных сетей связи на технологию информационного моделирования, при этом сэкономив часы рутинного и монотонного труда и снизив риск ошибки до нуля.
Любому руководителю, у которого к команде есть эксперт, предлагаю сделать татуировку: эксперт всегда должен быть доступен. Под экспертом я понимаю человека со сверхкомпетенциями – сеньора, суперархитектора, мегаспеца по выруливанию сложных ситуаций с клиентами.
Никогда не загружайте эксперта на фуллтайм, не давайте длинных неделимых задач (которые нельзя в любой момент отложить), не отдавайте в длинные проекты на линейных ролях (разработчик, аналитик, консультант). Любая загрузка, которая делает эксперта недоступным для команды – зло.
Рассказ
ИИ-офис молчал всю ночь. Это было плохо.
Обычно корпоративный ИИ-офис не молчит. Он шуршит фоном: нарезает записи в протоколы, собирает письма, подсвечивает риски, сравнивает версии договоров, ловит просрочки, пишет «рекомендовано назначить ответственного» и прочую административную поэзию, за которую раньше платили живым людям с лицами, кредитами и отпускными.
Молчание означало одно из трёх: либо всё сломалось, либо закончились токены, либо система нашла способ решить проблему без меня.
Третий вариант был самым неприятным.
Я проснулся в 5:40, потому что телефон завибрировал на тумбочке. На экране было сообщение от финансового директора:
«Андрей Сергеевич, вы точно согласовали выгрузку всего пакета по банку во внешний контур?»
Сон сразу закончился.
Есть фразы, после которых организм просыпается без кофе. «К вам пришли из налоговой». «Подрядчик снял людей». «Дизель встал, бетон греть нечем». И вот теперь в этот список добавилось: «..вы точно согласовали выгрузку всего пакета во внешний контур...»
Формулы Microsoft Excel позволяют мгновенно и без ошибок производить сложнейшие расчеты. Их ценность возрастает в разы, когда приходится работать с огромными массивами данных. Стоит запустить правильный алгоритм, и Excel за считаные секунды перелопатит тонны информации, выдав готовый результат.
В этой статье мы разберем пять ключевых типов формул и функций, которые заложат прочный фундамент для вашей аналитической работы. Попутно мы покажем несколько простых способов их ввода в таблицу.
Привет, Хабр! Я Максим, руковожу разработкой систем наблюдаемости и надежности в ижевском ИТ-хабе Т-Банка. Моя статья — часть проекта «20 в 20», в котором мы рассказываем о региональных ИТ-хабах и о том, как в них растут команды и инженерные практики.
Когда в 2019 году у нас внезапно исчез Splunk, мы столкнулись не только с технической, но и с организационной задачей. Нужно было за короткий срок построить собственную платформу наблюдаемости, которая выдержит нагрузку, не упрется в вендорский замок и сможет развиваться вместе с бизнесом.
Так появился Sage Observability — платформа, через которую мы видим состояние всего ИТ-стека: от инфраструктуры до бизнес-метрик, клиентских приложений и инцидентов.
Но сам продукт — только половина истории. Вторая половина — то, как мы строили команду вокруг него: как делили зоны ответственности, меняли процессы, внедряли архитектурный комитет, перераспределяли дежурства и учились работать распределенной командой без потери контекста.
Рассказываю свою историю, добро пожаловать под кат!
В современной разработке компоненты с открытым исходным кодом (Open Source Software, OSS) стали абсолютным стандартом. От небольших библиотек до целых фреймворков вроде Spring или Hibernate — FOSS (Free and Open Source Software) значительно ускоряет разработку и снижает издержки.
Однако, несмотря на кажущуюся «бесплатность», использование свободных лицензий в коммерческих продуктах влечет за собой серьезные правовые риски. Неправильное обращение с лицензионными требованиями может привести к потере коммерческой тайны, невозможности отчуждения исключительных прав на ваш продукт или его лицензирования на ваших условиях и к судебным разбирательствам.
Цель этой статьи — предоставить максимально подробное и практическое руководство для разработчиков и технических директоров. Мы разберем, как безопасно использовать FOSS‑лицензии в реалиях российского законодательства и международной практике, и как защитить свой проект от фатальных ошибок.
Каждый ноет на ретро. Мы научились ныть так, что работать стало комфортнее и эффективнее. В статье расскажу, что нам помогло.
