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

Привет, Хабр! В предыдущем материале мы упомянули, что при работе с текстовыми корпусами embedding-модели не всегда оптимальный инструмент. В этой публикации на примере задачи поиска релевантных документов по запросу рассмотрим ограничения такого варианта решения, разберем на практике гибридный подход и оценим его эффективность.

Меня зовут Вадим Скляров, я аналитик компании MWS, и уже по традиции мы будем разбираться в технической задаче с позиции системного и бизнес-анализа:

— сформулируем основные моменты, которые нужно знать и описать, прежде чем передать проект команде разработки;

— рассмотрим, как быстро проверить подходы к решению.

Все вокруг твердят о рисках, «риски надо учитывать», «риски нужно минимизировать», но мало кто системно объясняет, какие вообще риски бывают и как их классифицировать именно применительно к Delivery Management.

Мы решили попробовать в Kaiten новый подход: прежде чем идти с вопросом к коллеге, спроси сначала у нейросети. И это сработало хорошо — взаимодействие в команде стало эффективнее, а точечное использование ИИ превратилось в системную практику. Про наш опыт с нейросетями — ниже.

С помощью электронного документооборота физические лица могут получать госуслуги, устраиваться на работу, поступать в ВУЗ, оформлять кредиты, не выходя из дома. Организациям данный механизм позволяет сокращать издержки, связанные с созданием, обработкой и пересылкой документов. Электронный документооборот ускоряет и упрощает процесс обмена документами между компаниями и государственными органами. Более того, подключение к системам ЭДО сейчас нужно не только для удобства, но и в отдельных случаях является необходимостью: некоторыми документами можно обмениваться только в электронном виде. Системы ЭДО требуется для работы с маркированными товарами, прослеживаемостью, маркетплейсами и электронными торговыми площадками, для сдачи отчетности в ФНС и в другие государственные структуры.

Спрос на разработку ПО в корпоративном секторе постоянно растет. Поток задач у ИТ-подразделений не кончается, но вместе с ним растет и нагрузка на бюджеты. В таких условиях выигрывает тот, кто находит пути эффективной разработки: быстрее, дешевле, без потери качества. В этой статье разберем, из чего складываются затраты на разработку ПО и как их уменьшить.

Как измерить эффективность разработки

В первую очередь разберемся, о разработке каких систем идет речь. Показательный пример — CRM-система для B2B. В каждой отрасли свои нюансы: у производителей оборудования — длинные циклы продаж и сложные спецификации, у химических компаний — строгие требования к сертификации и логистике. Универсальных решений на рынке просто нет. Поэтому компаниям приходится разрабатывать системы на заказ.

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

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

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

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

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

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

​​

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

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

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

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

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

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

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

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

PMBoK весит 400 страниц и стоит как ползарплаты джуна. Я сейчас расскажу всё то же самое за 10 минут. Без воды, без "процессов интеграционного управления" и без желания покончить с собой на странице 237.

Это начинается незаметно. Сначала — просто «временное решение». Потом — «сделаем рефакторинг». Но «потом» не наступает никогда. Мы называем это техническим долгом, словно он когда-то будет погашен, но прекрасно знаем — чаще всего это просто красивое описание хаоса. 

Уже несколько лет я занимаюсь определением стоимости проектов по разработке, но в первые годы постоянно терпел провалы. Да, можно создать API за неделю, но если вы берёте за это копейки и работаете, как проклятый, то больше похожи на волонтёра, которому компенсируют хлеб и воду. Я бессчётное количество выставлял слишком низкий ценник, делал больше, чем от меня требовалось, а потом ощущал себя болваном. Этот пост — не какой-то манифест гуру; всему этому я научился, набив достаточно шишек. Если вы занимаетесь разработкой на фрилансе, возможно, мои ошибки уберегут вас от части мучений.

Вы когда-нибудь выставляли цену за проект, думая, что он займёт месяц, но в результате спустя четыре месяца давали скидку, лишь бы покончить с этим кошмаром?

У нас грядет кризис и, говоря «у нас», я имею в виду именно у нас, в России.

Это статья 2008 года, но она актуальна и сейчас, когда Сбер уволили 13 тысяч сотрудников и ещё собирается, и среди уволенных много IT, а Росатом разогнал один из отделов IT и джуны и senior и teamlead'ы по году не могут найти работу

Я очень сомневаюсь, что кризис в Европе приведет к реально серьезным проблемам, потому что европейский кризис это очень хорошая российская реальность. А уж о кризисе в Америке могут мечтать только очень наивные люди. Китай не даст! Наш же кризис, хотя на него, конечно, и влияет ситуация в Европе и Америке, все-таки имеет свои суверенные корни, и это - абсолютно не рыночная, неэффективная модель экономики.

В связи с этим, можно ожидать и массовое применение инструмента, который так любят неэффективные руководители – оптимизация. При этом, вполне рабочий инструмент бизнеса, каковым может быть оптимизация, если ее правильно понимать как построение оптимальной, в смысле наилучшей для данных условий модели бизнеса, понимается банально как «резка костов», то есть сокращение издержек.

Глупость, конечно, редкая, но как всякая глупость вещь распространенная.

Кстати, в этой связи мне очень понравилось высказывание, что я прочитал в журнале Mens Health (времен главреда Безуглого…) «Надо не меньше тратить, а больше зарабатывать! » Поэтому мне захотелось обсудить Три основных маразма, в которые может превращается оптимизация при ее неправильном использовании, может это кому-то пригодится.

Меня зовут Алекс Гусев. Я продолжаю публикацию заметок о своём персональном опыте использования агента Codex от OpenAI для разработки веб-приложений. В этой статье я расскажу о своих выводах относительно организации каталогов верхнего уровня в проектах, разрабатываемых в паре с ИИ-агентами.

Посмотреть результат применения излагаемого подхода можно в проекте "flancer64/pwa-home-call".

Конечно, существуют и успешные кейсы внедрения ИИ в бизнес, но даже в удачных случаях всё не так гладко. Успешное внедрение всегда сопряжено с множеством оговорок и допущений. Эта статья будет интересна тем, у кого получилось, и тем, у кого не получилось, и тем, кто только собирается внедрить искусственный интеллект в свой бизнес.

Откуда у C‑level берётся представление о розовых единорогах?

У нас было пять руководителей проекта, семь лет разработки, несколько почти законченных решений, меняющиеся цели, задачи и разнообразные системы всех цветов и размеров. Не то, чтобы это было нужно для успешной реализации, но раз уж начал пилить долгострой, то иди в своём увлечении до конца. Единственное, что меня пугало — это разработка серебряной пули, которая якобы исправит все проблемы. В ИТ нет ничего более иллюзорного, чем попытка разработать универсальную систему для решения всех проблем. И я знал, что мы скоро в это окунёмся.