Средняя и крупная организация — это не система, которую можно описать одной схемой. Это поле борьбы и согласования множества истин.
Как работать с этой сложностью? Через методологию "Точек зрения", где фреймворки — не шаблоны, а структуры для диалога.
Представьте, что вы работаете по скраму, но без скрам-мастера. Его задачи распределены между участниками команды. Представили? Отлично! Усложним задачу: представьте, что тимлида тоже нет. «Хаос» — скажете вы? Вовсе нет! Мы так работаем уже несколько лет.
Привет, я — Иван Зверев, фулстэк в Додо. Сегодня я расскажу о том, как круто может самоорганизоваться здоровая команда, если довериться ей, обозначить прозрачные правила работы и дать свободу экспериментировать с процессами. Вперёд!
В этой статье я хочу рассказать об опыте проектного управления в условиях Agile.
Проект, о котором я рассказываю, внедрен в Сбере два года назад. Я выбрал его в качестве примера во‑первых потому, что он успешно внедрился, и опыт был признан заказчиками положительным, а во‑вторых, на нем можно наглядно проговорить плюсы выделения независимого руководителя проекта.
Для упрощения восприятия сократил немного деталей, но с сохранением сути.
Представленные данные на экране Сбербанк Онлайн — вымышленные.
Описание постановки задачи
Подразделением, отвечающим за улучшение клиентского опыта в Сбербанк Онлайн (далее — СБОЛ), была поставлена задача «Отображать секции „Инвестиции“ и „Сбережения и пенсии“ в раскрытом виде, на экране „Накопления“ с выводом текущего состояния счета и дохода по каждому из продуктов.
Корпоративное обучение стало неотъемлемой частью работы любой команды или бизнеса. С ним сталкиваются все: от небольших стартапов до крупнейших корпораций. И это неудивительно — в меняющемся мире постоянно появляются новые инструменты, подходы и способы оптимизации. Обучение уже вошло в обязательные HR-стратегии: крупные компании запускают корпоративные университеты, внедряют внутренние платформы, организуют курсы и привлекают внешних подрядчиков.
Однако до сих пор обучение чаще всего рассматривается как надстройка. Оно не встроено в рабочий процесс, а существует параллельно — как что-то дополнительное. Такой подход кажется привычным, но и команда, и руководители всё чаще отмечают его слабые стороны.
В этом эссе — попытка переосмыслить культуру не как мораль и "систему ценностей", а как онтологию: систему сущностей, отношений и паттернов.
Я покажу, как культура теннисистов, шахматистов и open-source разработчиков строится на признании, стыде и неформальных правилах.
И почему попытки «внедрить культуру» превращаются её в имитацию.
Одно недопонимание на встрече может стоить вам недель переделок. В этой статье рассказываем, какие визуальные нотации помогут бизнес-аналитикам и командам понимать друг друга без лишних ошибок. Простые схемы и диаграммы, которые ускорят работу и сделают процессы понятнее для всех: от заказчика до разработчика. Узнайте, как выбирать и применять BPMN, ERD, Sequence Diagram и User Story Mapping в реальных проектах.
Более 30 лет я преподаю — в Вышке, РАНХиГС, Бауманке. За это время сменилось несколько президентов, десяток министров образования, бесчисленное количество реформ, стандартов, платформ и лозунгов. А я, человек с двумя дипломами — инженерным и философским, — всё это время смотрел на систему изнутри и задавал один и тот же вопрос: а что, черт возьми, такое образование на самом деле?
Вроде бы всё написано в законе: образование — это услуга. Рыночная. Сервис для потребителей (студентов), заказчиков (государства, работодателей) и поставщиков (вузов, школ). Просто, понятно, современно.
Но чем дольше я преподаю, тем сильнее ощущаю: это ложь.
Не злая, не корыстная — просто онтологическая ошибка. Потому что если образование — это услуга, то почему вся система медленно, но верно деградирует, а "невидимая рука рынка" образовательных услуг все больше напоминает не руку, а заднее место? Почему даже при растущем финансировании, новом оборудовании и «умных» досках — теряется самое главное?
Не знания. Не навыки. А смысл системы.
В 90-е можно было списать всё на бедность. В нулевые — на отсталость технологий.
Но сейчас? Сейчас у нас есть интернет, онлайн-курсы, ИИ, который пишет за студентов курсовые, дипломы и даже диссертации. А функционеры системы образования смотрят на это, и прячут свои мозги как страус — в песок.
И тут возникает вопрос, который уже нельзя игнорировать: а что, если старая онтология мертва? Что если «услуга», «потребитель», «ЗУНы» и «компетенции» — это архаизмы, которые ИИ просто добивает окончательно?
Привет, Хабр.
Хочу на основе одного проекта поделиться личным опытом: как от полного хаоса в разработке и управления API в виде спецификаций в Confluence мы пришли к удобному и понятному процессу с OpenAPI-спеками и кодогенерацией.
Покажу несколько вариантов, как можно работать с API на практике, с плюсами, минусами и неочевидными граблями каждого из этих подходов: от проектирования и разработки до внесения и согласования изменений.
В статье не будет никакой теории, все примеры и подходы взяты из моей практики, но не ищите тут открытий и откровений. Зачем я её написал? Хочу показать, что выстроить удобный процесс разработки API не сложно, и это принесёт много пользы проекту и команде.
В рамках еженедельных образовательных стримов прошла встреча по фреймворку для продуктовых команд - Scrum. Я скептически относилась к нему в десятые, когда "внедрение" было скорее модным, чем полезным. Но сегодня, имея в организационной структуре компании выделенные продуктовые команды можно точно сказать - Scrum лучший набор инструментов для разработки/создания нового продукта (и речь не только о цифровом продукте, конечно).
Запись встречи можно посмотреть здесь. Отвечу на любые вопросы. Ниже кратко резюме:
Scrum — фреймворк из группы гибких подходов (Agile). Может быть в комбинации с другими гибкими фреймворками. Немного о терминологии:
🕊️ Методология - система принципов, практик, процессов и правил для управления проектами на уровне всей компании. Правила организации процесса готовки с набором кулинарных книг и требованиям к кухне.
🕊️ Фреймворк - гибкая структура с набором рекомендаций, но без строгих правил. Позволяет адаптироваться под контекст. Рецепт конкретного блюда, где, вместо молока, если у вас аллергия, вы не можете добавить воду. Приготовьте другое блюдо.
🕊️ Подход - общая стратегия или философия управления проектами. Будете ли вы пользовать книгой рецептов при готовке или нет? Концептуально. Если да - европейская кухня или русская?
🕊️ Метод - конкретный способ решения задачи в рамках методологии или фреймворка. Обжаривать на открытом огне или с крышкой?
🕊️ Инструмент - инструмент. Не знаю, какое ему дать определение) Ложка, масло.
Итак:
🕊️ Подход: проектный
🕊️ Методология: Agile
🕊️ Фреймворк: Scrum
🕊️ Метод: Спринт, бэклог, ретроспектива и т.д.
🕊️ Инструмент: Agile poker planning, диаграмма сгорания спринта, kanban-board и т.д.
Чуть более 10 лет назад, когда я служил не очень большим, но и не очень маленьким начальником в федеральном министерстве, мне предложили пройти российско-китайскую программу в Китайской академии руководящих кадров Пудун (CELAP) в Шанхае. Ядумал, что это будет очередная командировка с ритуальными поклонами.
Оказалось — нет. Совсем нет.
Если говорить ИТ метафорами, нам дали доступ в бэкенд системы управления Китаем. Представьте себе, что вы — инженер, и вас внезапно пригласили заглянуть внутрь исходного кода ОС, на которой держится страна с населением 1,4 миллиарда.
Таково ощущение от первых дней в Пудуне.
CELAP — не просто академия. Это один из самых закрытых и влиятельных центров подготовки элиты КНР, прямо в подчинении Центрального комитета КПК.
Сюда не попасть по конкурсу или связям — попасть можно только по решению системы. Здесь не просто учат не менеджеров.
Здесь программируют будущих архитекторов государственной политики — тех, кто будет решать, где расти чипам, как развивать ИИ, куда направить триллионы инвестиций. И да, я был там не как турист. Я был — как слушатель. И этот опыт переписал моё понимание того, как можно управлять сложностью в масштабах страны.
Эта статья — продолжение разговора, который я начал в своих предыдущих текстах о паттернах поведения в профессиональной среде. Тех скрытых, устойчивых способах реагирования, которые проявляются, когда ситуация становится неоднозначной, напряжённой, а «волшебный пендель» уже не работает.
Реакция читателей была поразительной: многие узнали в этих описаниях своих коллег, начальников, а иногда — и самих себя. Это подтвердило главное: мы действительно действуем по скрытым, глубинным схемам, особенно в стрессе.
Я не ставлю диагнозов. Я не клинический психолог. Я — руководитель, наблюдающий за тем, как люди ведут себя под давлением, в конфликте, в тишине.
И со временем я заметил: в неопределённости мы не выбираем, кем быть. Мы возвращаемся к «заводским настройкам» — к тем автоматизмам, которые и формируют паттерны поведения. Я назвал их метафорически — «социопат», «дохристианин», «кантианец», «христианин», «буддист» — не как вероисповедание, а как архетипы отношения к миру, к другому человеку, к несправедливости.
Навести порядок в управлении — значит создать определенную систему, стандартизировать ее и поддерживать этот порядок в процессе выполнения работ. У руководителя сегодня голова идет кругом от количества методов, фреймворков, инструментов и моделей управления. Пришло время и в этом аспекте навести порядок.
Заголовок звучит масштабно, но суть проста: я хочу показать и доказать, что древняя книга гаданий на самом деле один из первых в мире инструментов для принятия решений в условиях неопределённости.
Я хочу показать не эзотерику, а логику «И-цзин» для того, чтобы понять, когда пора менять стратегию, почему команда выгорает или как рынок может обрушиться ещё до кризиса. Речь не о мистике, а о структуре перемен — как они устроены, по каким законам развиваются.
Я выстрадал предлагаемую на ваш суд модель за более чем 20 лет практической работы с разными командами, проектами и кризисами.
В процессе работы мне пришло понимание: самое сложное это не бежать за целями сломя голову, а понять, на каком этапе эволюции сложной системы мы сейчас живём. Не «что делать», а «какой сейчас ритм» — зарождение, рост, стабильность или упадок.
Логика триединства «И-цзин» не даёт инструкций, но помогает прочувствовать состояние времени сложной системы: где внешняя среда уже изменилась, а мы тянем прошлое, где человек выгорает, а система требует прыжка.
Это не про KPI и цели, а про синхронность, коэвоюцию, уместность, согласованность, естественную иерархию. И когда перестаёшь бороться с течением своими "глупыми" целями, а начинаешь читать потоки, то решения приходят не из шаблонов, а из ясности.
За годы профессионального пути мне довелось побывать в самых разных ролях: от рядового сотрудника до руководителя, от наставника до консультанта. Я работал и в государственных учреждениях, и в частных компаниях, и в крупных корпорациях, и в небольших стартапах.
И повсюду, вне зависимости от масштаба, культуры или отрасли, я сталкивался с одним и тем же явлением: в любом коллективе рано или поздно обнаруживается человек особого типа. Это может быть мужчина или женщина, интроверт или «душа компании», молодой или опытный, умный или не очень. У него есть ключевая черта: социопатия.
Не в клиническом смысле, а как стиль существования в социуме.
Социопат — это человек, для которого власть и статус — не инструменты, а цели и самоидентификация. Социопат не строит отношения — он строит иерархию. Для него вы никогда не бываете просто человеком. Вы всегда ресурс, средство, препятствие или жертва.
Цель любого его взаимодействия — не диалог и общение, а победа и доминирование, не сотрудничество, а подчинение или в крайнем случае — влияние и манипуляция.
В этой статье я не буду пересказывать научные исследования (это уже сделали специалисты). Вместо этого я поделюсь личным опытом — своими ошибками, наблюдениями и выводами, накопленными за годы профессиональной деятельности. Пусть мой опыт станет для вас инструкцией по распознаванию таких людей, руководством по защите от их влияния и, что особенно важно, предостережением — как самому не стать тем, кого мы только что описали.
По ходу Жизни, мы развиваемся, у нас раскрывается определенное Мировоззрение и мы что то делаем в своей Жизни согласно нее.
В моем случае, мое Мировоззрение привело к тому, что я реализовываю один Проект через два Стартапа. Об этом Проекте и будет речь в этой статье.
За год команда разработки Kaiten выросла в 3 раза, и привычные процессы перестали работать: доска переполнилась, потерялась прозрачность, а чтобы узнать, на каком этапе работа, приходится проваливаться в каждую карточку.
Вместе с Юрой Юрковым, Delivery Manager Kaiten, расскажем, как мы прошли путь трансформации, какие решения сработали и как не потерять управление в момент масштабирования. Если вы в похожей ситуации — читайте статью и используйте наш опыт, чтобы быстрее навести порядок.
Когда хирург сказал «ампутация», мой мозг выдал исключение LifeCriticalInterrupt. Как Python-инженер, дообучавший трансформеры, я столкнулся с фатальным сбоем в базовой платформе — собственном теле. Потеря ноги казалась крахом pipeline’а жизни. Но год спустя я понял: это не баг, а требование к пересборке архитектуры.
Изначально я не собирался так делать. Хотел обойтись списком в телефоне и парой заметок. Но через неделю невеста намекнула (наорала), что либо помогаешь, либо прощаемся.
Тогда я открыл таск-трекер «просто, чтобы разгрести бардак» — и втянулся больше, чем в собственный стартап. В статье — наша история, фейлы и результат.
Привет, Хабр!
Внутренние продукты умирают чаще, чем живут. Причём гибнут не на проде, не из-за кривого кода и не от того, что разработка пошла не по плану. Они разваливаются на самом старте — когда гипотеза ещё не успела обрести форму, но уже обросла Jira-задачами. Где-то я видел, что 9 из 10 новых инициатив не переживают первую встречу с пользователем. Почему? Потому что команды бегут в реализацию, не удостоверившись: а надо ли это вообще кому-нибудь?
Классический двухнедельный Scrum здесь не спасёт. Он хорош, когда вы уже уверены в направлении. А вот когда на старте всё зыбко и туманно, нужен отдельный, чётко спланированный discovery-конвейер. Такой, в котором каждые три недели появляется не слайд, а артефакт — проверенный, валидированный, готовый к следующему шагу. И вот хорошо вписывается 5D Discovery.
Пандемия заставила нас работать из дома, но перенесла в Zoom все офисные проблемы. Бесконечные стендапы, тотальный контроль и выгорание от видеозвонков — классический Agile даёт сбой. Но его можно спасти асинхронными практиками.
Читайте в статье:
✔️ Почему 80% митингов можно заменить письменной коммуникацией?
✔️ Как GitLab добиться результатов без ежедневных созвонов?
✔️ Чек-лист перехода на async-работу без потери эффективности.
