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

Когда я был ещё джуном, мой менеджер иногда на наших еженедельных встречах тет-а-тет делился своим возмущением. Он указывал на проект, над которым работала другая команда, и говорил: «Я не верю, что этот проект достигнет какого-то успеха. Они решают не ту задачу». Я отвечал любопытством: «Но вы же старший, почему бы просто не пойти и не поговорить с ними?» Мне казалось странным, что при наличии возможности повлиять на ситуацию человек предпочитает молчать.

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

Представьте себе, что вы работаете над относительно простым монолитным приложением в команде из пяти человек. К сожалению, каждый из вас выгружает код в основную ветку всякий раз, когда завершает работу над порученной ему функцией (или, что еще хуже, когда захочет). Вы то и дело правите код друг друга: используете разные соглашения по именованию, переписываете и, возможно, дублируете код. Именно так может выглядеть разработка в отсутствие процесса код-ревью.

Команда работает на полную, задачи в трекере есть, но релизы выходят нерегулярно. Стейкхолдеры спрашивают «когда будет готово?» — а вы не знаете, что ответить.

Знакомо?

Меня зовут Артём Герасимов, я владелец продукта SimpleOne SDLC. В этой статье расскажу, как превратить хаос в управляемый процесс разработки — без внедрения тяжёлых фреймворков, бюрократии и микроменеджмента.

Всем привет! Меня зовут Артём Харченков, я руководитель направления Java-разработки компании Crosstech Solutions Group. В этой статье хочу поделиться практическим опытом построения команды с нуля: от ситуации, когда вся экспертиза сосредоточена в одном человеке, до управления большой командой из пятидесяти специалистов, которые параллельно развивают несколько продуктов в различных классах решений информационной безопасности.

Долгое время казалось, что 5–6 лет коммерческого опыта — это условный "безопасный уровень", после которого поиск работы перестает быть проблемой и превращается в формальность. Ты понимаешь рынок, знаешь, как проходить собеседования, и примерно представляешь, чего от тебя ждут.

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

Привет, Хаббррр! Сейчас я расскажу, как использую агенты, чтобы упростить себе backend-разработку и не тратить на рефакторинг больше, чем на написание кода.

Какие задачи идеально подходят для оптимизации с помощью ИИ, а какие не стоит отдавать агенту.

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

Как уже упоминалось выше, понимание ЖЦ производства ИС является фундаментом профессиональной грамотности для любого профессионала IT-отрасли, от разработчика до топ-менеджера. Это не просто абстрактная теория, а практический инструмент, который напрямую влияет на вклада каждого специалиста в общий успех проекта, превращая хаотическую деятельность в управляемый процесс. Поскольку в последнее время значительно меняются условия ИТ-производства, смещаются акценты, размываются границы этапов и прочее, важно иметь представление об основных устоявшиеся стандартах. Поэтому перед тем как преступить к подробному рассмотрению стадий и этапов современного ИТ-производства пройдемся кратко по магистральным трендам.

Всем привет! Меня зовут Дарья Андреева, я руковожу командой бэкенда Биллинга и B2B‑платформы Яндекс 360. Наша команда, чтобы сократить TTM и освободить разработчиков от рутины, создаёт удобные внутренние инструменты. Сегодня я хочу поделиться своим опытом и порассуждать о внутренних инструментах.

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

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

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

Блокировки обходятся бизнесу не менее 1 000 р/день на сотрудника, но реальные потери сильно зависят от отрасли и региона, в отдельных случаях потери могут быть на порядки больше - и 10 000 и 100 000 р/день не предел.

Месяц работы за один вечер: сравнил Claude Opus 4.5 и китайский GLM-4.7 в vibe coding на задаче локального транскрайбера для NDA-встреч. Где критические баги, а где архитектурный идеал — и почему дорогой инструмент в 7 раз не всегда оправдан.

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

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

Вот примеры из моей жизни (в разное время в разных компаниях было):

Проблема 1. "CRM тормозит. Надо чтоб при поднятии трубки на SIP-телефоне у того, кто трубку поднял карточка новая всплывала".
Причина: Оказалось, что почти на каждую задачу в CRM выполнялся запрос типа "select * from cards;"
И это как-то работало в тестах на 5 карточках, но через 2-3 месяца работы крупного агентства недвижимости этот запрос перестал работать быстро.
Решение: Закомментировал вызов этого запроса в той части кода которая вызывалась на событие "подняли трубку", передал отчёт (по сути ТЗ) разработчикам и они доделали так: при звонке ДО поднятия трубки делаем "select id from cards where phone=...;" и потом уже при поднятии трубки человеку отдаём карточку либо новую либо уже заполненную (id нашли до поднятия трубки).

Меня зовут Станислав Решетнев, я руковожу отделом разработки в компании Sape по направлению Link Building (инструменты для продвижения в поисковых системах). В моем ведении находятся команды продуктовой разработки и команда внутренней Платформы. Чтобы лучше понимать эффективность сотрудников и видеть проблемные места, я создал инфополе с метриками продуктивности команд.

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

Я — Антон Марунько, руководитель в продуктовых компаниях уже более шести лет, помогаю строить и обучать команды в сфере IT.

Команда работает больше, процессов добавили, людей наняли. А результат тот же. Или хуже. Почему улучшения не работают? Рассказал, как перестать улучшать всё подряд и начать делать команду быстрее:

• Почему масштабирование команды не даёт результата (и что делать вместо этого);
• Когда стоит делегировать задачи, а когда нет;
• Как найти одно узкое место, которое тормозит всю систему.

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

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

Однажды фраза из к/ф "Человек с бульвара Капуцинов" навела меня на размышления о моем пути в ИТ-профессии. В отличие от Билли, мне повезло: я не просто встретил хороших людей, а прочитал умные книги, которые эти люди написали. Когда я вспоминаю годы, когда только становился программистом, отчётливо вижу те издания, которые заложили мой будущий фундамент. Это были не просто инструкции, а встречи с людьми, которые изменили мой взгляд на программирование и управление. Удивительно, насколько сильно несколько толковых книг могут повлиять на судьбу человека!

Refactoring Мартина Фаулера научил меня профессиональному отношению к коду и привычке доводить детали до совершенства. Не писать идеально с первого раза невозможно. Но постоянно улучшать, рефакторить, делать код чище и понятнее. Это не про перфекционизм, а про уважение к тем, кто будет читать этот код завтра. Фаулер однажды сказал: "I am not a good engineer, I am an engineer with good habits". Эта фраза стала для меня ключевой. Я понял, что хороший код это не про талант, а про привычки. Про то, что ты делаешь каждый день, даже когда никто не смотрит.

Хороший ли я программист? Если коротко — я не знаю, что это значит.

Вот я программирую уже 52 года, с 1973 года, спасибо урокам в государственной средней школе — тогда это было редкостью и не все школы давали подобную возможность. Я работал в 15 разных компаниях в самых разных отраслях. Болше скажу, я основал две небольшие софтверные компании — одну в 1985 году и вторую в 1987-м, и руководил ими до 1994 года. А потом я вышел на пенсию в 2021-м году.

Так что же, я хороший программист потому, что я в целом 52 года в отрасли и всё это время программирую?

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

Долговечность — это преимущество лишь в том смысле, что ты всё это время сумел оставаться ценным и востребованным, но это не обязательно значит, что ты хорош.

Берем интервью и лезем «под капот» к тем, кто задает вектор развития современных технологий в компании - к CTO.

Сегодня у нас в гостях человек с интересным бэкграундом: от разработки защищенных смартфонов на стыке «железа» и жестких гостандартов до управления современными ИТ-командами. Мы поговорили о том, каково делать продукт, когда 80% решений нельзя «загуглить», почему чиновники так и не оценили отечественные гаджеты и чем инженеры старой закалки круче современных «смузи-разработчиков». Погружаемся в мир реверс-инжиниринга, китайских заводов и суровой инженерной реальности.

Переписать решение с Python на Go и получить ускорение в 35 раз — звучит приятно. Но можно ведь пойти дальше, вспомнить о возможностях современных процессоров и увеличить отрыв Go до 200 раз! Статья написана по мотивам доклада для Golang Conf.

Привет, Хабр! Я — Игорь Вагулин, работаю тимлидом департамента IaaS в Cloud.ru, крупнейшем в России облачном провайдере IaaS- и PaaS-сервисов. Прогресс в производительности процессоров и видеокарт привел к тому, что мы можем использовать полный перебор там, где мы раньше обходились приближениями. Сегодня на примере алгоритма DRS-платформы Cloud.ru Evolution рассмотрим, как он может быть решен на разных версиях операций с плавающей точкой процессоров x86 и Arm, в чем сложности задействования SIMD-операций, почему это сложнее на Go и как это обойти.

Когда появился рабочий заголовок этой статьи, казалось, что тема простая и даже вполне очевидная. Ну что тут обсуждать — пришел ИИ, тестовые задания ушли в историю, это и так должно быть понятно, просто помашем им вслед. Но чем дольше была работа над материалом, просмотр старых статей и комментариев на Хабре, и вспоминая собственный опыт команды найма в SSP SOFT, тем сильнее приходило ощущение: «Прошлое не сдается без боя» и «Как же все запущено (в нашей индустрии)».

Сегодня поговорим об одной из тех коварных проблем, которую не увидишь невооруженным глазом, но которая способна тихо и методично «убивать» вашу печатную плату уже после производства. Речь пойдет о кислотных ловушках (acid traps). Это не брак оборудования, а прямое следствие некоторых решений на этапе проектирования. Давайте разберемся, что это, почему возникает и как этого легко избежать.

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

Однако распространять на другие отделы то, что было написано кем-то на коленке, слишком накладно. Нужен системный подход и отдельный стек, который лучше подходит для подобных вещей.

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