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

Сколько и куда инвестировать в дев-инструменты и платформу, как считать отдачу от оптимизаций (хоть от снижения CPU), и где гонять тесты — на пресабмите или на интеграции? Простых ответов нет. В этой статье я предлагаю целостную модель баланса между затратами разработки и создаваемой ценностью с учётом рисков: успех продукта, продуктивность команды, эффективность ресурсов и стратегические возможности. Дам практичные ориентиры для продактов, инженеров и менеджеров, а также покажу, как инфраструктура и архитектура сдвигают этот баланс и где именно выгодно усиливать автоматизацию и проверки.

Всем привет! На связи команда Центра разработки решений ALM‑стримов «ALM 2.0 Платформа» и «Динамическое моделирование баланса». В этой статье расскажем, как в нашей компании создаётся современная ALM‑система: на основе импортонезависимых решений, с расчётным ядром на Spark/Hadoop и интуитивно‑понятной интерфейсной частью на React/Java/Postgres. Ещё расскажем, как устроены витрины, где живёт логика и как запускаются пользовательские расчеты.

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

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

Всем привет! Меня зовут Александр Пряхин, я технический руководитель в Авито Подработке. В этой статье я рассмоатриваю подходы к измерению качества стабильной работы системы, а не только её отказов. Я постараюсь описать, что такое бюджет качества и почему его стоит считать; как SLA, SLO и SLI помогают наводить порядок и принимать решения; и главное – почему техническое качество напрямую становится зоной ответственности тимлида и как через метрики команда может начать говорить с бизнесом на одном языке.

CRM создаёт иллюзию контроля: карточки есть, статусы двигаются, отчёты красивые. Но если менеджер забудет сделать звонок или назначить встречу — клиент уходит к конкурентам. Мы решили проверить, можно ли что-то с этим сделать.

Как разработчику не остаться должником при исполнении договора? Разбираем на примере одного судебного спора. Исключаем совершение подобных ошибок.

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

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

Добрый день, уважаемое сообщество Хабра! Я тимлид, и сегодня хочу поделиться с вами опытом поиска работы в 2025 году. Это первый раз в жизни, когда я искал новую должность, уже будучи лидом. В последнее время тема поиска работы всесторонне рассматривается с точки зрения разработчиков. Но как новые предложения ищут лиды?

Предлагаю вам вместе со мной посмотреть на ключевые особенности рынка вакансий лидов в России. Моё мини‑исследование не претендует на объективность: только одно (ладно, два) резюме и только один всем известный сайт поиска работы. Однако можно понять некоторые общие закономерности и обсудить то, как видят нас, лидов, наши потенциальные работодатели. Ну и поделиться друг с другом своими историями в комментариях.

Если вы лид, либо смотрите в эту сторону, а также если вы HR, приглашаю вас дальше.

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

Я расскажу вам о своем опыте тимлида командой разработки в крупном банке, где старые управленческие привычки иногда брали верх над здравым смыслом. Это субъективная точка зрения на реальную ситуацию, где я — Д«Артаньян, а все остальные — редиски.

Made only by human brains

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

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

Вероятно, можно! Для этого требуется выполнить 3 шага:

1) написать и опубликовать книгу;
2) поработать и заработать;
3) стать известным, используя один из доступных вариантов,

где пункты 2 и 3 скорее всего не зависят от пункта 1. В этой иронии - больше правды..

Я не делал «крутой ИИ».
Я сделал систему, которая не давала людям уйти обратно к старым процессам.

Первый этап — показал простоту. Второй — показал надёжность. Третий — показал интеллект.

Именно поэтому этот проект стал основой для всей команды ИИ в компании.
Потому что мы доказали:

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

Если вы тоже работаете в корпорации, где «это невозможно», где «нет бюджета», где «это не наша задача» —
начните с каркаса.
Сделайте так, чтобы сегодня стало легче.
И завтра — уже сами будут просить: «А теперь ты сможешь…?»

В 2025-м в британских банках всё ещё крутится софт, написанный в 1960-х. Его понимают единицы — чаще всего сотрудники предпенсионного возраста. Исследование Baringa показало: почти 40% банков поддерживают код 1970-х годов, а половина организаций полагается всего на одного-двух специалистов для обслуживания критически важных систем.

Корни таких ситуаций лежат в монополии на знания о вашей системе, когда всё держится на двух‑трёх людях. Они в голове носят знания, которых нет ни у кого. И если что-то с ними случится, то все процессы встанут.

Я — Владимир Макеев, CEO Surf. В мобильной разработке часто сталкиваюсь с аналогичными  внутренними процессами у заказчиков. В статье расскажу, как «вечная» система тянет компанию ко дну, сколько бюджета тратится на старый стек и как перейти на новый без больших потерь для бизнеса.

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

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

Всё дело в том, что почти все до сих пор неправильно рассказывают другим об этих оценках.

Недавно мы с командой работали с клиентом из финансового сектора: у него есть сайт и личный кабинет, давно написанные на PHP (бэк и фронт), и задача — обновить дизайн и пользовательский опыт без глобальных изменений «под капотом».

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

Эта заметка развернулась из комментария к статье: Таски есть, системы нет.

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

В заметке я постараюсь выйти на эту ключевую проблему и затронуть вопросы вида:

Из чего такая система должна произрастать? Какие к ней требования? Есть ли примеры?

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

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

Представьте идеальную IT-команду: блестящие специалисты, амбициозный проект, всё для успеха. Но проходит несколько месяцев, и что-то ломается. В чатах исчезают мемы и жаркие споры об архитектуре, остаются лишь сухие «залил пул-реквест». Разработчик, горевший своим делом, теперь молча соглашается с любым решением. Даже успешный релиз не хочется отмечать — будто это не победа, а просто конец очередного марафона.

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

Правда в том, что люди уходят не только из-за денег. Гораздо чаще — из-за ежедневного обесценивания, абсурдного контроля и ощущения бессмысленности. 58% IT-специалистов готовы на меньшую зарплату, но не готовы мириться с токсичной культурой управления (Harvard Business Review).

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

Всем привет! Меня зовут Роман, я руковожу разработкой. Когда‑то начинал разработчиком, потом тимлид, сейчас управляю лидами.

В моём багаже опыта — работа работа в интеграторе, потом в небольшой компании из сферы SMS‑маркетинга, череда позиций в in‑house разработке в разных отраслях. А сейчас я снова в айтишечке, в заказной разработке.

И вот что забавно: на протяжении всей карьеры меня преследует один и тот же вопрос — как правильно поставить задачу и как отследить реальное состояние разрабатываемой системы.

Казалось бы, инструментов хватает: Jira, YouTrack, Trello, GitLab, Confluence и ещё десятки. Но если копнуть глубже, становится понятно: каждый из них решает только кусочек головоломки. Целостной картины всё равно нет. Она появляется только в голове после погружения, но и тут засада — голов в проекте много, и у каждой своя картинка.

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

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

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