Производственная система «Росатом» (ПСР) – это культура бережливого производства и система непрерывного совершенствования процессов для обеспечения конкурентного преимущества на мировом уровне.
Она была разработана на базе лучших образцов отечественного и зарубежного опыта, в частности, системы научной организации труда, производства и управления (НОТПиУ) Министерства среднего машиностроения СССР и Toyota Production System японской автомобильной компании «Тойота».
Шалом алейкум, Хабр! В интересное время живём. Наши «любимые» ведомства делают всё, чтобы общение стало максимально «доступным» — но исключительно в тех местах, где удобнее контролировать. Пока уголовной статьи за дискредитацию этих усилий нет, напишу этот пост.
А если без шуток — блокировка звонков в Telegram и WhatsApp резко сделала актуальным вопрос: где теперь созваниваться? Мы привыкли решать рабочие дела в телеге или вотсапе, а теперь приходится крутиться. Меня лично накрыло вчера: Google Meet внезапно отвалился, и урок английского сорвался.
Поэтому собрал небольшой топ сервисов, где звонить можно без VPN и танцев с бубном. Ниже — список, проверенный на себе и коллегах. В конце бонус — варианты связи для родителей и бабушек.
TL;DR
Автоматическое ревью кода с помощью ИИ уже работает в продакшене крупнейших компаний. Microsoft обрабатывает 600 000 пулл-реквестов в месяц, экономя сотни тысяч часов. ByteDance достигла 75% точности с 12 000 активных пользователей еженедельно. Google автоматизировал 7,5% всех комментариев ревьюеров. В статье — детальный разбор архитектур, метрики эффективности и пошаговое руководство по внедрению с расчётом окупаемости.
Многие конторы ставят трекеры, чтобы наблюдать за работой сотрудников — кто‑то скриншотит экраны каждые 3 секунды, кто‑то следит за простоем курсора мыши. Многие верят, что именно так можно повысить эффективность. Откуда они вообще это взяли? И так ли это? Рассматриваю вопрос мониторинга с точки зрения науки о поведении людей на работе — организационной психологии. Делаю обзор исследований, шучу сомнительные шутки, обсуждаю альтернативы — и это все под катом.
Кажется, выстраиваешь стартап на доверии, а потом внезапно обнаруживаешь, что главный технический специалист… не оставил тебе даже пароля от GitHub. Ни в шутку, ни в полсилы. Всё, с чем работала команда: домены, серверы, CI/CD, база клиентов, мониторинг - оказалось привязано к личным аккаунтам подрядчика. Контроль потерян. А вернуть всё не факт, что возможно.
И самое болезненное: с юридической точки зрения уязвимы не только основатели, но и инвесторы, заказчики, партнёры. Ни один NDA тут не спасёт, если изначально не были расставлены границы доступа, конкретный перечень информации и ответственности. В этом тексте не морализаторство, а подробный разбор, как такие истории случаются, чем они грозят и что можно сделать заранее, чтобы однажды не зависеть от настроения одного человека.
От ручного ада в большой компании до автоматизированного техрадара с живыми правилами и визуализацией.
Мы запустили собственную платформу полного цикла производства ПО с ИИ‑агентами — MWS DevRails. Решение позволяет управлять жизненным циклом продукта и контролировать все этапы создания ПО: от проектирования и анализа до разработки, тестирования и выхода официального релиза. В платформу интегрированы ролевые ИИ-агенты, которые автоматизируют до 40% задач.
И сегодня больше расскажем о других фреймворках и библиотеках, предлагающих возможности ИИ-агентов для обработки данных и визуализации содержимого датасетов.
Почему ваша BPMN-стратегия — это путь в никуда. Научный взгляд на управленческий тупик.
Мы привыкли доверять стандартам. Но что если главный стандарт описания бизнес-процессов — BPMN — фундаментально порочен?
Это не просто мнение, это факты из когнитивной психологии и исследований IT-проектов:
🧠 Когнитивная перегрузка: Человеческий мозг не способен эффективно работать с сотней визуальных символов. BPMN нарушает базовые принципы эргономики.
🌉 Коммуникационный разрыв: BPMN так и не стал единым языком для бизнеса и IT, порождая бесконечные ошибки "перевода".
🏢 Архитектурный тупик: Даже в связке с мощными ERP-системами, BPMN лишь автоматизирует "функциональные колодцы", а не создает целостную систему.
В своей новой статье я провожу параллель между провалом советского проекта ОГАС и современными проблемами "цифровизации". И показываю, как наследие той самой инженерной школы в виде языка ДРАКОН и современных платформ (АСис) позволяет построить то, о чем все говорят, но никто не умеет — настоящую, работающую холакратию.
Готовы посмотреть на управление процессами под другим углом? Читайте полную версию.
Карта стейкхолдеров, карта эмпатии, agile чаще проваливается, мотивация по Герчикову, эффект Черномырдина, цезари, запрещенные фразы и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Здесь приведен перевод критической статьи из блога "John Farrier for software engineers" об "исследовании" о том, что "Agile-проекты проваливаются на 268% чаще".
Привет! Меня зовут Ваня Тришкин, я тестировщик в KTS.
В своей прошлой статье я рассказывал об основных инструментах тестировщика, которые нередко приносят пользу в работе менеджеров. Тогда я затронул тему DevTools и сделал краткий обзор возможностей, которые дает этот инструмент, однако подробно останавливаться на них не стал, чтобы не растягивать публикацию. Пришло время разобрать их детально.
Сегодня я не просто опишу панель DevTools, а приведу примеры сценариев, в которых она может понадобиться менеджеру. Заодно для каждого инструмента я дам небольшие упражнения, которые помогут закрепить материал и увереннее пользоваться тулзами на практике.
Привет, Хабр.
Хочу на основе одного проекта поделиться личным опытом: как от полного хаоса в разработке и управления API в виде спецификаций в Confluence мы пришли к удобному и понятному процессу с OpenAPI-спеками и кодогенерацией.
Покажу несколько вариантов, как можно работать с API на практике, с плюсами, минусами и неочевидными граблями каждого из этих подходов: от проектирования и разработки до внесения и согласования изменений.
В статье не будет никакой теории, все примеры и подходы взяты из моей практики, но не ищите тут открытий и откровений. Зачем я её написал? Хочу показать, что выстроить удобный процесс разработки API не сложно, и это принесёт много пользы проекту и команде.
Вы часто слышите на конференциях: «Нужно быть продуктовой компанией!», «Проводите CustDev!», «Замеряйте метрики!». А на совещании звучит: «Почему мы не проводим A/B-тесты?», «Давайте сделаем CustDev с 100 пользователями!». Вы видите, что команда уходит в бессмысленную активность, а руководство требует «быть как Яндекс». В суровой реальности B2B-сделок, кастомных внедрений и длинных циклов продаж "продуктовые советы" часто разбиваются о необходимость сделать сложную интеграцию, соблюсти нефункциональные требования и договориться с комитетом из десяти человек.
Эта статья для CPO/PM и руководителей B2B, у кого сделки длятся 6–12 месяцев, решение покупает комитет, а 70% усилий уходят в интеграции и надёжность. Разбираем, где продуктовые практики дают отдачу, а где решают доменная экспертиза и безупречный delivery. Короче для тех, кто разрывается между «давайте сделаем продукт» и суровой реальностью проектов, кастома и длинных B2B-сделок. Разберёмся, когда CustDev и «быстрые эксперименты» дают ценность, а когда решает именно контекст и предметная экспертиза, чем полезна продуктовая функция, где PM не обязателен, и как управлять в циклах 6–12 месяцев без самообмана и продуктового фетишизма.
Ну и традиционно подписывайтесь на канал StrategicMove, там будет оповещение о новых вебинарах и полезностях.
Представьте город без карты. Дома построены, улицы проложены, люди живут своей жизнью — но никто не знает, как всё это связано между собой. Каждый архитектор чертит по-своему: у одного — квадраты, у другого — кружки, а у третьего — загадочные стрелки, ведущие в никуда. Когда решения принимаются «на глаз», последствия не заставят себя ждать. В результате, ценные находки теряются в ворохе несогласованных схем. Именно так выглядит ИТ-ландшафт без продуманной системы архитектурных артефактов. Сегодня я расскажу, как мы в МТС наводим в этом хаосе порядок, почему выбрали путь EAoaP — и что сделали, чтобы эта красивая теория прижилась в реальной, живой экосистеме из сотен продуктов.
Привет, Хабр! Меня зовут Наиль Миннахметов и я — корпоративный архитектор в МТС. В прошлом –– разработчик, аналитик и консультант в телекоме, финтехе, eCom, ритейле, логистике, фарме и FMCG. Занимался много чем, но всегда это было связано с IT. Я помогал разным бизнесам расти, становиться надёжнее или зарабатывать больше.
Прочитал статью Программисты против вайбкодеров и решил поделиться собственным опытом вайб-кодинга, но уже без рекламы ТГ-каналов и бесполезных цитат авторитетных источников. Пока писал, появилась еще одна статья Революция вайб-кодинга отменяется, но уже с противоположным мнением.
Но теория без практики так и остается теорией, именно поэтому мне и захотелось рассказать о практическом применении вайб-кодинга в реальном проекте с конкретными фактами, а не маркетинговыми лозунгами.
Эта статья - подведение итогов небольшого эксперимента (над собой) по использованию вайб-кодинга в С++ проекте, что для программиста с 30-летним стажем работы стало практически вызовом и серьезным выходом из зоны комфорта. Но сейчас все проблемы решены, и в соответствии с Хабрахаком я решил оформить полученные выводы в письменном виде для их систематизации, а заодно и для получения обратной связи.
Если вы хоть раз работали в стартапе или команде с неопытным менеджером, то знаете этот особый вид утреннего кофе. Ты садишься за рабочий стол, открываешь чат, и ещё до первого глотка узнаёшь: "Всё отменяем! Срочно делаем вот это!"
Привет! Это снова я, Паша Лукьянов. Я по-прежнему deputy CTO в AGIMA и по-прежнему рассказываю о принципах работы архкомитета у нас в компании. В первой части статьи я объяснил, из каких критериев состоят наши Definition of Ready (DoR) и Definition of Done (DoD), а также что представляет собой наша статусная модель. А теперь поговорим об этапах проработки архитектурных документов. Если вы внедряете архитектурный комитет в своей компании и прописываете процессы — вам сюда.
Pet-проект которой далеко зашел, но так и не дошел до цели!
Ретроспектива моей первой попытки создать полезный и востребованный пользователям продукт, ошибки, которые мы допустили, и сделанные выводы.
Развитие IT-технологий приводит к очевидному росту различных киберпреступлений, осуществляемых посредством взлома этих самых IT-технологий. Чтобы защищаться от таких посягательств, владельцы программ, сервисов, крупных IT-систем вынуждены самостоятельно заказывать такие взломы у сторонних лиц с целью выявления уязвимостей и их устранения. Такой процесс называется «пентестом», и помимо технической составляющей здесь присутствует очень много юридических нюансов, потому что взламывать – незаконно (сюрприз, да?). Давайте разбираться.
Я фанат изобразительного искусства и часто хожу в галереи. Это мое, так называемое, место силы. Мне важна не сколько техника, а то, какие эмоции вызывает картина. Настоящее произведение отзывается где-то глубоко глубоко внутри, и этот отклик у каждого свой.
Как-то раз, я долго стояла перед картиной, на которой два джигита пытались поймать дикую лошадь. Для меня это было о свободе, о том щемящем чувстве, когда понимаешь, что она может вот-вот исчезнуть. Я ставила себя на место этой лошади и проживала каждую эмоцию. Муж, который был рядом, не понял, как можно так долго смотреть на одну картину. Для него это была просто сценка, для меня — целая история с сильным личным откликом.
Два человека могут смотреть на одну и ту же картину, но видеть в ней разное. На восприятие влияет личный опыт, характер, текущие переживания, настроение, яркие эмоции из детства. В коммуникациях все происходит так же. Мы можем участвовать в одном и том же разговоре, но понимать и чувствовать его совершенно по-разному. Для большей наглядности предлагаю рассмотреть три истории из моей жизни.
