Управление разработкой *

В последнее время часто звучат мрачные прогнозы (и даже скрытая реклама) о том, что крупные языковые модели (LLM) уничтожат программирование как профессию. Многие обсуждения лишены нюансов, поэтому я хотел бы внести свои пояснения. С одной стороны звучат заявления вроде: «Я использовал $LLM_SERVICE_PROVIDER, чтобы создать маленькую временную программу, и скоро все программисты останутся без работы за $ARBITRARY_TIME_WINDOW». С другой – категорический отказ признавать какую-либо пользу таких инструментов. Думаю, лучше всего прояснить эту ситуацию можно на примере другой отрасли, где подобные технологии появились раньше: перевод.

В прошлой части мы разобрали:

1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;

2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;

3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;

4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.

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

1. Как не допустить появления связанной архитектуры и сразу сделать хорошо?

2. Как исправить уже связанную архитектуру?

В этой части постараюсь развернуто ответить именно на первый, оставив второй на десерт.

Привет, Хабр!

Если вы не разработчик и не понимаете, каким способом разработка определяет приоритет вашей задачи (спойлер: лунный календарь или ретроградный Меркурий к этому не имеют отношения), то эта статья будет вам полезна. 

Если вы продакт-менеджер, который видел все в этой жизни, и отчаялся настолько, что уже готов приоритизировать бэклог по картам таро, то эта статья будет вам полезна. 

Если вы разработчик и устали гореть от того, что задачи в бэклоге выстраиваются по пирамиде Маслоу или рандомайзеру, то эта статья будет вам полезна (как минимум, разбавите рутину на следующем стендапе). 

В общем, в новом посте рассказываем про популярные способы для приоритизации бэклога команды разработки и почему мы запилили свой. 

Всем привет! Меня зовут Александр Бондаренко, работаю CPO в Garage Eight. Это следующая статья из цикла про то, как строить продукт. Как и другие современные компании, мы постоянно ищем способы улучшить свои продукты. Но бесконечные улучшения могут навредить. Почему? И где та точка, в которой нужно остановиться? Разбираю в статье.

Цель этой статьи  — показать, в каких случаях Agile не принесет ожидаемого эффекта, рассмотреть наиболее распространенные случаи его некорректного применения и обозначить ключевые моменты, на которые важно обратить внимание перед началом Agile-трансформации.

Привет, Хабр!

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

Сегодня хочу поделиться историей о том, как мы внедряли сервис на основе Telegram-бота с элементами искусственного интеллекта для решения конкретной бизнес-задачи. Это история про то, как мы начали с MVP, постепенно добавляли ИИ, и как это помогло сотрудникам сэкономить время и повысить точность выполнения операций.

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

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

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

Кроме того, наряду с обычными жалобами на время компиляции, я начал замечать от раздражённых разработчиков на Rust и подобные заявления: «Почему Rust Project не занимается активнее этой важной и очевидной проблемой? Почему с этим что-нибудь не сделают?». Я участник рабочей группы по производительности компилятора Rust, поэтому воспринимаю такие вопросы очень серьёзно. И, разумеется, у меня есть мнение по этому поводу. В этом посте я приведу свои размышления, способные служить ответами на эти (и похожие) вопросы.

Предупреждение: все выраженные в этом посте мнения исключительно мои и необязательно отражают точку зрения Rust Project (группы контрибьюторов и мейнтейнеров тулчейна Rust).

Недавно я опубликовал на Хабре статью про один из наших проектов — корпус эпилятора. Показал цену: примерно 300$ за корпус. И получил комментарии, что цена чудовищная и это ненормально.

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

ИИ обучается на существующих данных, как джуниор-разработчик на Stack Overflow, и становится похож на мидла. Но сможет ли он когда-нибудь дорасти до сеньора?

Заголовки вроде «Программисты будут не нужны через пять лет» появляются всё чаще, а модели, такие как ChatGPT и GitHub Copilot, демонстрируют впечатляющие способности в написании кода, однако мы считаем, что никаких серьезных изменений в IT-сфере в ближайшие годы не случится. В этой статье мы предлагаем к обсуждению свои аргументы для такого непопулярного мнения.

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

Почти 10 лет назад мы начали создавать платформу с базовыми технологическими компонентами. Эта платформа, которая впоследствии превратилась в Platform V, стала основой одного из трёх ключевых технических фундаментов, предоставляющих универсальные компоненты для создания цифровых решений. А сейчас Сбер уже развивает пять ключевых платформ. Три из них — технологические фундаменты: работа с данными, инфраструктурой и базовыми модулями, с которых мы начали платформизацию. Остальные две платформы включают в себя инструменты для эффективной командной работы и коммуникаций.

Всем привет! Я Александр Родов, ведущий разработчик в «БАРС Груп», автор и руководитель разработки сервиса генерации печатных форм Sprinter. Этой статьёй мы продолжаем рассказ о возможностях использования библиотек DocumentFormat.OpenXml для генерации печатных файлов «офисных» форматов.

В первой и второй частях речь шла о разработке печати сведений о заказе в интернет-магазине в формате docx. В третьей и заключительной части мы поговорим о печати xlsx, необходимость которой встречается в требованиях к реализации ПО не реже, а, быть может, даже чаще, чем docx. Электронные таблицы дают пользователю больше возможностей по просмотру и анализу данных, позволяют вычислять агрегационные значения и строить простые аналитические модели. В нашем примере мы рассмотрим заполнение ячеек таблицы, их стилизацию и настройку формул для вычислений.

Можно получить любой отчет, просто написав, что тебя интересует. Или назначить задачу, не заходя в Jira. Тестировал неделю. Рассказываю, стоит ли овчинка выделки и как это меняет рабочий процесс.

Вчера коллега потратил 10 минут, чтобы создать простую задачу в Jira. Выбирал тип, заполнял поля, искал, кому назначить. Обычная история.

Но теперь это можно сделать за 1 минуту, даже не заходя в интерфейс Jira.

Ваше приложение на Go начало тормозить. Первая мысль? Наверное, база данных медленно отвечает. Вторая? Может, сеть лагает. Мы начинаем строить догадки, добавлять кэши, оптимизировать запросы, переписывать SQL-конструкции, дергать девопсов... и часто бьем мимо цели. Мы тратим часы, а то и дни, на оптимизацию того, что и так работало нормально, в то время как настоящая проблема прячется в совершенно неожиданном месте нашего собственного кода. Знакомая боль, не правда ли? В этой статье мы разбираем как работать со встроенным профайлером в Пo.

Сегодняшняя ситуация вокруг спецоперации в Украине и последовавшие рестрикции со стороны европейских стран и США обнажили и без того известные проблемы импортозамещения западной продукции. Не исключением в этом вопросе стало программное обеспечение (далее – ПО), о старте импортозамещения которого заговорили еще в 2016 года. По изначальному плану замещение программного обеспечения должно было завершиться в 2024 году. Однако, не смотря на столь амбициозный план, ощутимых результатов это не дало как несколько лет назад, так и сейчас. Да, конечно, на протяжение всего этого времени публиковалось множество материалов на тему успешного замещения части западного ПО отечественным, однако это была лишь каплей в море ИТ-решений и технологий.

Последовавший в начале 2022 года уход из России практически всех известных вендоров от Microsoft, до SAP и Oracle, показал нашу сильную зависимость от прививаемого годами зарубежного ИТ-сервиса. По существу, начало полноценного замещения зарубежного ПО началось именно с этого момента, когда российские компании поставили перед фактом остановки поддержки, продления лицензий и работы самого ИТ-решения. Большинство ИТ-менеджером и директоров судорожно стало думать о переходе на российские аналоги, в частности на продукты 1С, как базового корпоративного решения. Однако, использование нового ПО на предприятии возможно лишь после его имплементирования, процесс которого оказался также сильно завязан на страны запада.

В это статье мы рассмотрим вопрос импортозамещения приложений класса ERP и ERP2, принимая во внимание тот факт, что это далеко не единственный компонент корпоративной информационной системы (далее – КИС). Для целей удобства повествования термины программное обеспечение, информационные и корпоративные системы, а также ERP-системы для нас будут тождественны. В работах [1-2] выделяют четыре основных уровня задач для внедрения КИС, к которым относят процессы, данные, приложения и технику, а также два вспомогательных: управление проектном и изменениями. Собственно говоря, процесс внедрения и импортозамещения ERP-систем мы будем рассматривать сквозь указанные 6-ть параметров.

Доброго времени суток!

Для начала представлюсь: я бэкенд-разработчик с опытом более 8 лет. Участвовал в разнообразных проектах: в стартапах, в галерах, в крупных корпорациях и в среднем бизнесе. К сожалению, найти идеальную статистику по данной теме не представляется возможным, однако из общения с бывшими коллегами я понимаю, что то, что будет описано ниже, — не только мой личный опыт, но и то, что регулярно происходит в других компаниях.

Если вы проджект-менеджер и не поймёте содержание этой статьи, это только подтверждает, что вы не способны контролировать данный процесс, и вас практически наверняка водят за нос. Хотя текст по написанию планировался максимально понятным и наглядным с учётом специфики проблематики.

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

Прежде чем мы приступим к разбору, хочу уточнить, что я прямой апологет бритвы Оккама, и важным правилом в моём подходе является не плодить сущности без необходимости. Если возможно написать сервис в 100 строк — лучше написать так. Потом, если потребуется, его будет несложно переработать под более удачную архитектуру.

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

Project 1 — съедал арт‑директоров, которые не выдерживали нагрузки и требований по проекту. За полгода сменилось 4 человека. Были горе‑разработчики, которые не могли внятно объяснить, что они сделали. Ненадёжный СТО отвалился на пятом месяце работы (из 12). Команда не выдерживала темпа, и из‑за этого сдвигался весь глобальный план. Пришлось навалится командой топ менеджеров и встать у руля проекта, в результате чего проект был реализован срок.

Project 2 — не вовлечённые проектные менеджеры. Был очень сложный проект с множеством багов на проекте, сложной архитектурой и особенностями и сложностями продукта. Проект начал работать только после прихода четвёртого ПМа. Были некомпетентные разработчики, которые срывали релизы. Всё удалось настроить, но ушло на это почти 5 месяцев и смена менеджера проекта.

Project 3 — за год сменилось три тимлида разработки, из‑за чего постоянно происходил новый найм, онбординг и замедление команды.

Project 4 — в начале проекта не были уточнены требования. На пресейле проект продали красиво, предложили больше тз, а делать начали «на коленке». В итоге вместо двух месяцев разработка заняла восемь, но всё‑таки проект дотянули и сдали. Помогло то, что вся работа шла через эскроу счета и команда обязана была доделать проект, чтобы получить вознаграждение за работу.

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

Учёные из Университета Утрехта совместно с Complexity Science Hub решили глубоко разобраться в распространении генеративного ИИ в программировании. Они изучили более 80 миллионов изменений кода на платформе GitHub, сделанных в период с 2018 по 2024 год. Исследователи разработали специальный нейросетевой классификатор, способный отличить код, написанный человеком, от кода, созданного с помощью генеративных алгоритмов.

Выяснилось, что лидерами в этой «гонке автоматизации» стали программисты из Соединённых Штатов. Уже к концу 2024 года более 30% всех Python-функций, написанных разработчиками в США, были результатом работы искусственного интеллекта. Европейские страны, такие как Германия и Франция, также активно следуют этому тренду, достигая показателей в 24,3% и 23,2% соответственно.

Любопытно, что среди стран Азии картина выглядит иначе: если в Индии использование ИИ достигло уровня 21,6%, то в России и Китае показатели значительно ниже — 15,4% и 11,7% соответственно. Эксперты связывают это с различиями в экономических и технологических условиях, а также с возможными регуляторными ограничениями.

Интересным аспектом исследования стало выявление групп, наиболее охотно передающих рутину программирования алгоритмам. Оказалось, что новички, которые недавно начали карьеру на GitHub, особенно склонны использовать нейросети в своей работе — они доверяют ИИ около 41% задач. Опытные программисты более консервативны и чаще предпочитают писать код вручную, полагаясь на алгоритмы лишь в 28% случаев.

Все уже пошутили и запомнили что если в тексте — , то его писал ChatGPT. А если нет, то человек?

Эта статья - самый подробный гайд в рунете, как отличить текст, сгенерированный Gen AI от текста, написанного человеком и как самому, используя GenAI писать очеловеченный текст. Я разберу реальные приемы, маркеры, ошибки и вооружу вас важными знаниями

Переход в лиды из разработчика — дело не простое. Нужно научиться слушать людей, видеть их сильные стороны, разбираться в мотивации и много чего еще. Сейчас я Dev Lead в Exante. Мы разрабатываем внутренние сервисы для узкого круга заказчиков. Мой путь в лиды начался с неформального лидерства и первых попыток менторства. О том, что я узнал, какие фейлы прошёл и чему научился за это время — под катом.