Управление проектами *

Привет! Меня зовут Николай Огоров, я 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. В каждой отрасли свои нюансы: у производителей оборудования — длинные циклы продаж и сложные спецификации, у химических компаний — строгие требования к сертификации и логистике. Универсальных решений на рынке просто нет. Поэтому компаниям приходится разрабатывать системы на заказ.

Эффективная разработка — это не просто быстрое написание кода или выбор самой дешевой команды на рынке. Это умение с минимальными затратами получить результат, который отвечает бизнес-требованиям.

На эффективность разработки влияет масса факторов, но в этой статье мы остановимся на влиянии технологий. От того, на какой платформе строится система и какие инструменты используют разработчики, напрямую зависит, во сколько обойдется проект и как быстро он окупится.

На какие статьи расходов влияют технологии и как их можно оптимизировать

Не все знают, что среди айтишных лидеров мнений есть довольно популярная точка зрения, что пулл-реквесты в корпоративной разработке - это далеко не оптимальная практика.

Короче, давайте с источниками и мемчиками пройдемся по теме ревью и пулл-реквестов.

2.5 года назад я решил попробовать себя в IT-стартапах. Потратив несколько лет, более 6 миллионов рублей, мы пришли к тому, что закрываем проекты. В статье – путь от идеи сервисов постинга и биржи автоматической рекламы до их релиза, а также о всех трудностях, неудачах и успехах во время разработки.

​​

За годы работы в бигтехе я работал с десятками плохих менеджеров. В статье — топ-7 паттернов слабого управления. Кратко и по делу объясняю, почему они возникают и что с этим можно сделать.

Хочу поговорить о парадоксе, в который мы сами себя загоняем: мы не верим в осуществимость своих желаний только потому, что считаем невозможным договориться с человеком, от которого зависит их осуществление. Самый главный баг, который мы часто не чиним, — это наше собственное убеждение в том, что «договориться невозможно». Исправление этого бага открывает дорогу для реализации всех остальных идей.
Весь наш опыт убеждает нас в том, что в некоторых ситуациях попытка открыто обсудить вопрос с высокой вероятностью приведет к проблеме: когда мы вынуждены проявить несогласие или ожидаем несогласие от другого, то есть риск испортить отношения, проиграть, оказаться виновным / неправым, потерять лицо, впустую потратить время и т.д. Поэтому мы либо избегаем обсуждения — ведь «оно бесполезно», «будет только хуже», «ему/ей всё равно ничего не объяснишь». Либо (если чувствуем в себе силы — а у нас их часто бывает хоть отбавляй, если мы уверены в своей правоте) мы бросаемся в бой. Обе этих реакции естественны для нас, так как мы не чувствуем себя в безопасности.

В статье мы разберём, почему даже самые важные разговоры так часто остаются только в планах или превращаются в конфликты. Вы узнаете, откуда берутся привычки молчать или давить, как они работают и к каким последствиям приводят. А также вы получите простой, но действенный инструмент, который поможет взвесить ВСЕ риски.

Хабр привет! Меня зовут Арина Касаткина, я системный аналитик в MPSTATS. В фокусе моей работы сейчас — поддержка и развитие продукта, однако мой профессиональный опыт включает в себя комплексную работу с внутренними бизнес-процессами компаний: от анализа процессов до их автоматизации. Например, именно так был выстроен процесс работы с инициативами сотрудников, о чём я и хочу подробнее рассказать.

В любой компании есть сотрудники с идеями, но часто эти идеи остаются неуслышанными. Это приводит к потере потенциала, демотивации команды и повторным предложениям одних и тех же инициатив. Решение — создание централизованного и системного процесса работы с инициативами. Как аналитик может стать драйвером этого изменения? Давайте разберемся.

Лучших инженеров увольняют не потому, что они плохи. А потому что они слишком правы. Их слова рушат иллюзию контроля — и показывают, что план не сработает. Но без них компании быстро понимают, какой ценой даётся это «спокойствие».

Если вы хоть раз планировали релиз или запуск проекта, вы наверняка сталкивались с Гант‑чартом — визуальной магией, где каждая задача превращается в горизонтальную полосу или проще — «колбаску».

Любой человек, который читает научные публикации и сам пишет статьи для научных рецензируемых журналов, на мой взгляд, обязан быть в курсе этого эссе, фактически взорвавшего научный мир двадцать лет назад. Суть статьи заключена в её заголовке: автор на основании выдвинутых им предположений построил статистическую модель, которая предсказала, что большинство опубликованных результатов, вероятно, являются ложноположительными – то есть, говоря простым языком, согласно Иоаннидису большинство опубликованных результатов (якобы найденных взаимосвязей и зависимостей) на самом деле являются ложными.