Мне 25 лет, и я работаю DevOps-инженером четвёртый год. Начинал системным администратором.
За это время сменил 5 работ. Первые три был сисадмином. На четвертой работе я был уже DevOps.
«Мы передали им всю документацию, но они все равно постоянно отвлекают нас вопросами». Знакомо? В этой статье разбираем, почему классический сценарий передачи проекта в IT почти всегда ведет к хаосу. Почему код и документация — это лишь верхушка айсберга?
Что общего у падения уровня преступности в Нью-Йорке 90-х, грязной чашки и ваших годовых KPI?
В статье разбираем принцип «Теории разбитых окон», чтобы вовремя увидеть и устранить скрытые угрозы, которые подрывают вашу корпоративную культуру и съедают прибыль.
Привет, Хабр!
Меня зовут Софья Петаева, я руковожу отделом системного анализа. Уже почти 10 лет в этой теме, и за это время я научилась не только смотреть на результат работы аналитиков, но и понимать, как они его добиваются. В последнее время мне часто приходится организовывать аналитиков и придумывать новые процессы. Это и помогло мне лучше понять их работу.
В этой статье я расскажу о Discovery-фазе, о том, какие ошибки мы сделали, на каких граблях потанцевали, и как эти уроки до сих пор влияют на нашу работу и принятие решений.
Привет, Хабр! Меня зовут Надежда Гольдман, и я руковожу IT-проектами в Lenta Tech («Группа Лента»). Год назад я была администратором, а сегодня веду комплексные проекты и отвечаю за результаты команды.
Расскажу, как прошел мой переход: с какими вызовами столкнулась, что помогло и какие советы могу дать тем, кто хочет повторить этот путь.
Любые процессы — это по сути отдельные продукты, со своими фичами, багами и, конечно пользователями. На первый взгляд процессы разных команд схожи друг с другом и состоят из однородного набора практик и принципов.
Однако опытные команды всегда адаптируют под себя популярные подходы, чтобы успешно применять их в работе со своими продуктами. Часто итоговые различия кроются в микропроцессах — небольших уникальных практиках, присущих опыту конкретной команды в конкретный момент времени.
В статье расскажем: почему процесс — это продукт, зачем переделывать популярные практики под себя, как запускать компромиссные процессы и развивать их в большие практики, как отдельный микропроцесс «пост дизайн ревью» в свое время открыл нам путь к большому и взрослому процессу дизайн ревью.
Этот опыт настиг меня в самом начале карьеры Руководителя ИТ-проектов (далее – РП). Поэтому все истории мне пришлось пройти, не имея ни многолетнего опыта управления проектами, ни вообще какого-либо образования менеджера.
Все что у меня было — это большое желание расти и достигать поставленных целей. А инструменты мне пришлось искать по пути) И я не о типичных пунктах из PMBoK!
Меня зовут Алина Прасковина, я руководитель проектов в MONS, «КОРУС Консалтинг». И прежде чем раскрыть секреты своей системы, расскажу предысторию: как же так случилось, что на еще совсем юного РП свалилось такое количество проектов?
Я собрал 21 рабочих способа, как использовать канбан-доску: для планирования рабочих и командных задач, ведения личных дел, семейных развлечений и подготовки к апокалипсису. Надеюсь, вы найдёте что-то интересное для себя.
Привет, Хабр! Я Максим Катрушенко, главный специалист по анализу данных и машинному обучению в ПГК Диджитал. В своей статье расскажу, как мы разработали систему оптимизации распределения вагонов на ремонт для одного из крупнейших железнодорожных операторов России Первой грузовой компании (ПГК). Внедрили методологию оценки экономического эффекта через сравнение с «идеальным сценарием». За два с половиной года работы система обработала рекомендации для более чем 50,000 вагонов.
Представьте переговорку, где за большим дубовым столом встретились маркетинг, продажи, продукт и разработка. У каждого свой фокус: маркетинг думает про охваты и лиды, продажи — про квартальные цифры, продукт — про клиентскую ценность, разработка прикидывает, как это всё сделать и не порвать команду. Всё вроде направлено на рост компании, но без чёткой структуры вы увидите не общий путь команды к цели, а четыре параллельных маршрута.
Хорошая стратсессия помогает превратить поток мнений в согласованный план, в который команда верит и готова его реализовать. И ключ здесь — организация процесса.
Я Соня, Product Operations manager в hh.ru. Моя суперсила — создавать структуры, где люди смело говорят о важном, зная, что будут услышаны, а бизнес-цели достигаются по плану без шантажа и манипуляций. В этой статье я поделюсь прикладными советами, как можно превратить стратегическую сессию из дорогостоящих посиделок в место сбора команды с общей целью.
База знаний может стать центром обучения в проектном офисе, где кросс-проектный опыт и стандарты определяют успех. Как? Разберем в статье.
Российский 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.
