Внедрили Agile, проводите дейли и ретроспективы, делите работу на спринты — но результата нет. Пожары задач, техдолг растет, команды не успевают. В чем проблема?
Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. Я считаю, что если Agile не работает в вашей компании — то методология тут ни при чем.
Разберемся, в чем настоящая проблема и как ее решить.
Привет! С вами Антон Тарабрин, заместитель начальника отдела эксплуатации в РТЛабс. Хочу поделиться опытом организации работы команды инженеров, занятой на поддержке 60+ информационных систем (ИС) и взаимодействующей с разными командами разработчиков — от внутренней до внешней разработки.
Расскажу, как мы сделали организационные задачи более прозрачными, и, надеюсь, наш опыт будет полезен.
Если в вашей команде больше семи человек, то вы наверняка сталкивались с тем, что во время ретро часть участников «отваливается»: кто-то молчит, а кто-то участвует формально. Однако чтобы встреча прошла успешно и стала источником задач для улучшений, это должен быть разговор всей команды, а не простая расклейка стикеров. А что если добавить в этот процесс геймификацию?
Меня зовут Лея, я менеджер проектов в Lamoda. Я решила сделать ретро полезным и интересным для команды, вдохновившись примером одного из хабровчан и популярными играми. Опишу процесс на примерах с Pac-Man и Тетрисом, полученный результат и оставлю для вас рекомендации для применения в своей команде.
Привет, Хабр! Меня зовут Юля Анпилогова, я менеджер команды индивидуальных интеграций CDEK. Мы стали первыми, кто не только запустил интеграцию с Wildberries по схеме DBS (delivery by seller — доставка силами продавца), но и создал единую точку подключения к маркетплейсам WB и Ozon. Этот опыт оказался похож на квест. Курьеры, не привыкшие спрашивать код, лимиты запросов API Wildberries и покупательница Елена, заказавшая тестовый ежедневник — всё это оказалось его частью. Сегодня в статье расскажу, как мы прошли этот путь.
В проектном офисе (PMO) несколько специалистов разного профиля работают на общий результат. С одной стороны, каждый занят своими задачами, а с другой – все друг от друга зависят. Отсюда и специфика: важна не личная продуктивность сама по себе, а эффективное управление потоками.
На подстанциях и ОРУ уровень ошибки измеряется не в пикселях, а в деньгах и месяцах простоя. Для инженеров, которые работают с объектами 110–220 кВ, переход с «чистого» 2D в ТИМ – это не про модный 3D-рендер, а про единый источник правды, автоматическую РД и корпоративную стандартизацию.
Этот кейс – про то, как компания, одной из первых начавшая внедрять Smart Grid в России, шагнула в ТИМ, сохранив инженерам привычную DWG-среду и добавив ей третье измерение смысла – насыщенную данными информационную модель.
Хабр, привет!
В INTEKEY мы прошли путь от стартапа до компании с солидным портфелем проектов, и за это время успели изучить все возможные вариации IT-договоров. Мы систематизировали этот опыт вместе с нашими партнерами — юридической компанией «Зарцын и Партнеры» при личном участии основателя Людмилы Харитоновой — и готовы поделиться решениями, которые превратят ваш договор из формального документа в реальный инструмент управления проектом.
Особое внимание в этой статье мы уделим новым законодательным требованиям 2025 года — от ужесточения 152-ФЗ о персональных данных до новых критериев для реестра отечественного ПО. Эти изменения существенно повлияли на риски IT-проектов, и мы покажем, как адаптировать ваши договоры к текущим реалиям.
Например, в управлении транспортом статичные данные (например, сет за «типичный вторник») не дают протестировать систему в условиях праздника, крупной аварии, сессии у студентов, скидки 99% на Лабубу в крупном супермаркете и так далее.
Что мы сделали:
— Стали брать реальные данные с прода, которые выбиваются за стандартные представления.
— Обезличивать их.
— Использовать ML-модель для генерации сценариев, где эти данные увязываются с остальными в системе. Это типа генерации новых данных с усилением трендов и их пересечением.
То есть фактически по модели швейцарского сыра — мы имеем один статичный срез, а затем начинаем ходить в прод и искать новые дырки. Потом соединяем несколько дырок в новом слое и накладываем слои друг на друга, чтобы посмотреть, не будет ли сквозного отверстия.
Цель — не просто нагрузить систему, а протестировать жизнеспособность архитектуры в похожих на реальные условиях.
Очень упрощая, наши наборы тестов учатся нестандартным ситуациям с прода и включают их и в тестовые выборки данных, и в юнит-тесты, и такие ситуации не только покрываются как частные случаи, но и включаются в сложные сценарии, где 3 малозначимых отказа могут привести к аварии.
Я думаю, что это будущее тестирования сложных систем, и мы с командой уже затащили это в автоматический пайплайн.
Привет! Меня зовут Николай Огоров, я Big Data-инженер в Авито. В этой статье я и мой коллега Айк Оганесян расскажем, как обеспечили пользователей инструментами, которые дают им возможность самим создавать витрины в хранилище Авито без привлечения специалистов. Эта история больше про подходы, решения и философию, которые позволяют жить в парадигме, когда потребностей на создание объектов DWH стало сильно больше, чем возможностей Data-инженеров.
Привет, Хабр! Меня зовут Антон Филимонов, я руководитель Центра компетенций по разработке прикладных решений в «Газпром ЦПС». Чтобы успевать за быстроизменяющейся рыночной средой и быть эффективной, наша компания должна уметь формировать новые команды и выводить их на оперативный ритм в короткие сроки.
В этой статье я поделюсь опытом, как можно сократить время формирования эффективных команд, и покажу, что давление и шторм на ранних стадиях – не всегда плохо. Расскажу про базовые этапы формирования команд на примере модели Такмана и закона Йеркса-Додсона, а также на примере 5 типовых сценариев продемонстрирую как управляемое давление применяется для сокращения времени на формирование команды. Этот материал будет полезен тем руководителям, у которых есть задача быстрее вывести команду проекта на устойчивый рост продуктивности.
При проектировании сложных объектов – будь то нестандартное оборудование, разветвленная сеть трубопроводов или сосуды и аппараты – трехмерная модель перестает быть просто визуализацией. Она становится центральным элементом, на основе которого принимаются ключевые решения. При этом любая, даже незначительная ошибка – например, в длине шпильки или геометрии перехода – влечет за собой целую цепочку проблем: от дополнительных согласований до изменения всей конструкции. Все это приводит к многократному увеличению сроков сдачи проекта конечному пользователю.
Именно лишние часы рутинной и неэффективной работы чаще всего задерживают этап разработки конструкторской документации. Вместо решения сложных и интересных задач, специалисты вынуждены выполнять однотипные и монотонные операции.
«Нанософт» выпустила обновление, которое решает ключевые задачи конструкторов. В nanoCAD Механика PRO 2.0 заметно прокачаны модули для проектирования емкостного оборудования и трубопроводов, добавлена поддержка стандартов (ГОСТ, ОСТ, ISO), введен новый мастер соединений и полноценный растровый инструмент для оцифровки архива чертежей. Основная цель – не просто расширить функционал, а принципиально повысить эффективность работы и вернуть фокус туда, где он действительно нужен – в инженерный замысел и контроль модели.
В этом посте разбираем, как именно обновление будет полезно инженерам, которые проектируют емкостное оборудование и трубопроводные системы в нефтехимической, нефтеперерабатывающей и смежных отраслях.
Привет! Меня зовут Екатерина Морозова и я менеджер продукта «Спортивный помощник». В этой статье я расскажу, как работает наш чат-бот и как мы подняли процент закрытия чатов ботом до более, чем 80%.
Все говорят LLM, а я скажу NLU. А может ли бот без LLM обеспечить высокий процент автоматизации? Да, но…
Путь Спортивного помощника начался в далеком 2022 году. О генеративных моделях тогда было мало известно, и мы стояли перед выбором решения для автоматизации обработки вопросов клиентов в службу поддержки. Кнопочные боты показывали низкую эффективность, поэтому выбор был очевиден - использовать технологии распознавания естественного языка (NLU - Natural-language understanding) для определения намерения клиента.
Я не инженер и не продуктовый менеджер. Я продолжаю работать в маркетинге как проектный менеджер и остаюсь скорее гуманитарием, но после переезда в Европу в моём окружении стало много специалистов из IT. Я наблюдаю, как они организуют работу, ведут проекты, договариваются о задачах — и многое из этого оказалось неожиданно практичным, рациональным и универсальным.
Ниже — практики, которые я подсмотрела у техлидов и продуктовых команд. Это не попытка «учить» разработчиков тому, что они и так знают лучше меня. Скорее, я описываю опыт со стороны — как человек, который постоянно учится у них дисциплине управления временем.
Буду рада комментариям: так ли это работает внутри ваших команд.
Для успешного делегирования нужно сочетание обычного и эмоционального интеллекта, системное видение результата и процесса, а также доверие, чтобы предоставить команде пространство для ошибок и поиска. Это искусство, которым можно овладевать постепенно. Обычные руководители передают команде операционные задачи, а настоящие лидеры – стратегические, давая возможность по мере готовности браться за все более сложные проекты и повышать уровень общего результата. Давайте рассмотрим 3 причины, по которым делегировать не получается.
Каждый менеджер хотя бы раз ловил себя на мысли: «Если не я, то кто?» Это вроде бы простая фраза, но за ней скрывается куда больше, чем желание увидеть проект успешным. Она задаёт тон всей культуре управления: той, где руководитель становится «героем», который раз за разом вытаскивает команду из дедлайнов, конфликтов и хаоса.
Это состояние хорошо знакомо большинству менеджеров — особенно тем, кто пришёл из экспертизы. Кажется естественным заменить коллегу, подхватить чужую задачу, переписать решение за сотрудника, «чтобы точно всё было правильно». Но то, что ощущается как ответственность и участие, часто оказывается одной из самых разрушительных привычек для команды и для самого менеджера.
Привет, Хабр! В предыдущем материале мы упомянули, что при работе с текстовыми корпусами embedding-модели не всегда оптимальный инструмент. В этой публикации на примере задачи поиска релевантных документов по запросу рассмотрим ограничения такого варианта решения, разберем на практике гибридный подход и оценим его эффективность.
Меня зовут Вадим Скляров, я аналитик компании MWS, и уже по традиции мы будем разбираться в технической задаче с позиции системного и бизнес-анализа:
— сформулируем основные моменты, которые нужно знать и описать, прежде чем передать проект команде разработки;
— рассмотрим, как быстро проверить подходы к решению.
Все вокруг твердят о рисках, «риски надо учитывать», «риски нужно минимизировать», но мало кто системно объясняет, какие вообще риски бывают и как их классифицировать именно применительно к Delivery Management.
Мы решили попробовать в Kaiten новый подход: прежде чем идти с вопросом к коллеге, спроси сначала у нейросети. И это сработало хорошо — взаимодействие в команде стало эффективнее, а точечное использование ИИ превратилось в системную практику. Про наш опыт с нейросетями — ниже.
С помощью электронного документооборота физические лица могут получать госуслуги, устраиваться на работу, поступать в ВУЗ, оформлять кредиты, не выходя из дома. Организациям данный механизм позволяет сокращать издержки, связанные с созданием, обработкой и пересылкой документов. Электронный документооборот ускоряет и упрощает процесс обмена документами между компаниями и государственными органами. Более того, подключение к системам ЭДО сейчас нужно не только для удобства, но и в отдельных случаях является необходимостью: некоторыми документами можно обмениваться только в электронном виде. Системы ЭДО требуется для работы с маркированными товарами, прослеживаемостью, маркетплейсами и электронными торговыми площадками, для сдачи отчетности в ФНС и в другие государственные структуры.
Спрос на разработку ПО в корпоративном секторе постоянно растет. Поток задач у ИТ-подразделений не кончается, но вместе с ним растет и нагрузка на бюджеты. В таких условиях выигрывает тот, кто находит пути эффективной разработки: быстрее, дешевле, без потери качества. В этой статье разберем, из чего складываются затраты на разработку ПО и как их уменьшить.
Как измерить эффективность разработки
В первую очередь разберемся, о разработке каких систем идет речь. Показательный пример — CRM-система для B2B. В каждой отрасли свои нюансы: у производителей оборудования — длинные циклы продаж и сложные спецификации, у химических компаний — строгие требования к сертификации и логистике. Универсальных решений на рынке просто нет. Поэтому компаниям приходится разрабатывать системы на заказ.
Эффективная разработка — это не просто быстрое написание кода или выбор самой дешевой команды на рынке. Это умение с минимальными затратами получить результат, который отвечает бизнес-требованиям.
На эффективность разработки влияет масса факторов, но в этой статье мы остановимся на влиянии технологий. От того, на какой платформе строится система и какие инструменты используют разработчики, напрямую зависит, во сколько обойдется проект и как быстро он окупится.
На какие статьи расходов влияют технологии и как их можно оптимизировать
