Вы наверняка замечали, что в начале общения ИИ кажется очень толковым и понятнливым, правда почему спустя 10-20 сообщений начинает путаться, повторно совершить те же ошибки которые уже совершал или выдавать рассчеты с ошибками. Это не случайность, а следствие мироустройства. Давай разберемся почему это происходит и как именно ИИ все “помнит” и почему его память устроена иначе чем у человека.
Что делать, если через пару месяцев аутсорс-команда исчезнет, а проект с кодом, который вы видите впервые в жизни, целиком остаётся на вас? История и маленькие практические советы по выживанию от разработчика — для команд, которым предстоит забирать проект в условиях отсутствия документации, и для тех, кто внезапно оказался за это ответственным.
Лично мне нравится LLM как инструмент, усиливающий мои интеллектуальные возможности. Я использую его ежедневно — для поиска информации, для создания и перевода текстов, в качестве ассистента по подсчёту калорий и, само собой, для разработки приложений. Немного попрактиковавшись с генерацией pull request'ов через OpenAI Codex для модулей своего проекта TeqCMS, я пришёл к выводу, что в "грядущую эпоху вытеснения разработчиков моделями" настоящую ценность представляет вовсе не код и даже не проектная документация. Главный артефакт — это инструкции, настраивающие контекст для Агента, и история запросов, с помощью которых генерируется код.
Как часто оценка по задаче совпадает с реальными трудозатратами?
Умение точно оценить объём работ спасает от переработок, напряжённой обстановки на проекте, поддерживает доверительные отношения в команде и показывает вас с хорошей стороны перед заказчиком.
Но интуитивные и ставшие традиционными способы оценки задач дают низкую точность. Пора взять на вооружение другой способ, дающий 90+% точность в оценке.
Если вы хоть раз были на стороне бизнеса, наверняка слышали (или говорили):
Сколько можно делать такую простую штуку?; Они что, не понимают, как это важно?
Но тут надо смотреть шире...
Все знают аббревиатуру CI/CD. Continuous Integration and Continuous Delivery - Непрерывная интеграция и Непрерывная поставка. Но едва ли можно найти более неправильно понимаемую нашей индустрией идею, чем непрерывная интеграция. Практика, которая была придумана, чтобы её делали разработчики, почему-то превратилась в объект работы девопсов, хотя к культуре DevOps ну вообще никакого отношения, по идее, иметь не должна.
Так что вот вам статья про то, как так вышло, что сейчас под CI понимают что угодно, кроме того, чем она, на самом деле, является.
Как AI-системы теряют 30% смысла при обработке документации?
Проблема кроется в процессе chunking — разбиении документов на фрагменты. Когда связанная информация оказывается в разных частях, контекст теряется. Разберем механизмы работы RAG-систем и покажем, как писать документацию, которая работает для людей и машин.
Модель Кано, фреймворки, отсутствие ТЗ, отпуска на проекте, много гайдов по инструментам и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Пошаговое руководство по использованию Git, Obsidian, Markdown и любимого IDE для разработки требований и трассируемого в них программного кода.
Привет, Хабр!
Многие ИТ-компании находится в постоянном поиске баланса между автономией команд и централизацией процессов. Эта дилемма не обошла стороной и нас в Content AI. В силу нескольких причин пришлось отказаться от классической плоской структуры, которая подразумевала минимальное количество уровней управления, в пользу иерархической, где напротив, есть довольно четкое распределение ролей и зон ответственности.
Попросили руководителя нашего отдела разработки — Александра Субботина и его подчиненных, рассказать о причинах смены подхода к распределению ролей в командах и вызовах, с которыми столкнулись в процессе перехода.
Все подробности — под катом.
————
Привет, Хабр!
Если вы ощущаете, что стали частью распределённой системы с бесконечными входящими — поздравляю, вы тимлид. И, скорее всего, вам не весело. Вы не пишете код. Вы не думаете стратегически. Зато вы таскаете ведро с пробоинами по палубе, где вечно течёт.
У большинства тимлидов, особенно в условиях активного роста компании или распределённой разработки, есть общее ощущение перегруженности. Неважно, какая индустрия, стек, удалёнка или офис — ощущение одно: «весь день был занят, но результат размыт».
Меня зовут Владимир Казеннов. С недавнего времени я руковожу группой развёртывания программного обеспечения (ПО) MES-систем в одном из подразделений нашей дружной ИТ-команды «Северстали». Сегодня я немного приоткрою завесу тайны, покрывающую корпоративный деплой.
По инструментам всё достаточно просто. На столе у нас GitLab, ему когда‑то очень‑очень давно помогал Jenkins, немного Vault, чуть‑чуть Helm. Далее погружаемся в кубер, в его лучшую версию на все времена — RKE (Rancher Kubernetes Engine), там уже и Graylog наблюдает за нами, рядом же крутится Kafka c Redis.
80% компаний используют генеративный ИИ без реальной отдачи. Этот «парадокс Gen AI» разрешают ИИ-агенты: они автоматизируют сложные процессы, повышают оперативность и открывают новые источники дохода.
Узнайте, как перейти от экспериментов к масштабируемому влиянию на бизнес.
ITSM живет с нами уже 30 лет. За это время многое изменилось: технологии, версии ITIL, бюджеты на реализацию. Что осталось неизменным — так это завышенные ожидания, которые часто идут вразрез с реальностью.
Напомню, что ITSM (Information Technology Service Management, Управление ИТ-услугами) — это подход к управлению ИТ-деятельностью, который рассматривает ИТ-ресурсы как услуги, предоставляемые бизнесу для достижения его целей.
Сегодня я хотел обсудить самые распространенные «мифы», которые громогласно и красиво рассказывают со сцен отраслевых мероприятий и на вебинарах признанные специалисты, консультанты, продавцы, эксперты в области ITSM, и то, как потом эти «мифы» разбиваются о скалы суровой реальности.
Миф № 1: Я легко пройду сквозь бюрократию и быстро внедрю сервисный подход! Ведь это же прогресс и инновации, за этим будущее!
Реальность: нет, это будет долго и больно.
Привет, Хабр! Меня зовут Тигран Басеян и я — руководитель MTS Link Доски, CEO geekz.ru, развиваю российскую методологию управления ИТ в организациях РИТМ, преподаватель ВШЭ и автор телеграм-канала Black Product Owner (Чёрный продакт), где рассказываю о продакстве, менеджменте и стартапах. В индустрии уже больше 15 лет. Руководил различными технологическими командами и продуктами, в том числе высоконагруженными.
И раньше я никогда правильно не использовал модель Кано. Это метод, который появился в Японии в 1980-х годах и используется для измерения эмоциональной реакции клиентов на отдельные функции.
Если бы в 2017 году, когда я работал над платформенным продуктом, я применил модель Кано грамотно, проект мог бы обойтись без лишних затрат времени и нервов. Но тогда мне казалось, что Кано — это какая-то скучная теория для учебников по менеджменту.
Спойлер: это не так. Модель Кано — один из самых мощных инструментов для управления ожиданиями пользователей и для приоритизации фич. Главное — уметь ей пользоваться на практике, а не просто пересказывать графики из Википедии.
В этой статье я разложу всё по полочкам: какие бывают категории фич, почему пользователи однажды перестают радоваться вашим «фишкам» и как построить опрос, чтобы Кано действительно заработала в ваших продуктах. Без воды — только факты, кейсы и практические советы.
Разработчики делают задания ради галочки, в их глазах больше не горит огонь, а число инновационных идей от девелоперов уменьшилось? Нет, сотрудники не обленились. Им просто не хватает мотивации для эффективной работы. Разбираемся вместе с командой системы управления проектами Kaiten и консультантом по современному менеджменту Neogenda Марией Савельевой, как вернуть мотивацию IT-команде.
Когда говорят про аутстаффинг, в большинстве случаев речь идет о разработке: фронтенд, бэкенд, DevOps, тестирование. Это то, что легко измерить в часах и тасках. Но в работе над цифровым продуктом бывают моменты, когда задача не в том, чтобы «написать код», а в том, чтобы разобраться, что именно нужно писать и зачем. И вот тогда на первый план выходят не программисты.
Привет, Хаброжители!
Издательство «Питер» представляет книгу-гид в мире профессионального роста. Автор Гергели Орош, прошедший путь от джуниора до принципал-разработчика в Uber, делится ценными инсайтами о том, как прокачать карьеру в IT. В этой статье мы немного больше расскажем о книге, которая представляет собой структурированное руководство, основанное на реальном опыте работы в крупных технологических компаниях. Как она называется? Разработчик ПО: Путеводитель по карьерной лестнице для будущих сеньоров, техлидов и стаффов.
Привет! Меня зовут Сергей Господчиков, и в IT я, страшно подумать, с 1992 года. Именно тогда я начал работать программистом и писать свой первый код, за который мне платили деньги. Примерно в 2001 году я стал руководить людьми и прошел путь от главного инженера до генерального директора, попутно попробовав себя в ролях CIO, CTO, CEO и даже преподавая проектный менеджмент. И все эти годы я постоянно проводил различные изменения.
Сейчас я работаю с командами разработки в качестве методолога продуктового подхода и практикую Канбан-метод. В этой статье поделюсь с вами своим опытом проведения изменений. А именно — практическими инструментами, которые сам использую почти ежедневно.
Жизнь вокруг нас меняется очень динамично, и не все изменения нам нравятся. Точнее, давайте так — не каждое изменение мы принимаем. Так что эта статья для большинства из нас. Для тех, кто восемь часов в день, как минимум, проводит на своей (конечно же, любимой) работе. Инструменты, которые я опишу, также подходят для планирования и проведения изменений в семейном кругу. Однако в этом случае нужно быть очень аккуратным, чтобы не навредить вашим отношениям. Кстати, я в браке уже 28 лет. Ребята, оно реально работает. Но, как говорится, это уже совсем другая история.
Так вот, про изменения. Задумывались ли вы когда-нибудь почему предложенные вами изменения не вызывают восторг у окружающих и остаются лишь мечтами, несмотря на то, что с вашей точки зрения они очень полезны? Но остальные, к вашему удивлению, почему-то так не думают и не спешат делать то, что вы задумали. Бывало?
Таск-трекер без бизнес-процессов ― деньги на ветер! Самая частая ошибка ― пытаться заводить задачи, не продумав сам процесс. В этом тексте показываем 6 универсальных процессов, которые можно внедрить буквально за 10 минут: от онбординга до работы с подрядчиками.
