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

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

В этой статье — мой личный фреймворк стратегического мышления, применимый на любом этапе карьеры, особенно полезный для Senior и Senior+ инженеров. Он основан на почти 20 годах опыта работы с платформами, продуктами и командами в сферах облачной инфраструктуры и сетей — от гиперскейлеров до стартапов (и до, и после IPO), а также крупных корпораций.

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

Композитная архитектура — это подход к проектированию ПО, при котором приложение строится из набора слабосвязанных, независимо разрабатываемых, развёртываемых и масштабируемых компонентов. Эти компоненты взаимодействуют только через чётко определённые интерфейсы (чаще всего API).

Привет, Хабр! Меня зовут Денис Улизко, я CPO продукта AoS (Automation of Sales) B2B CRM-системы, которой мы заменили устаревшую международную CRM. Наше основное преимущество — гибкость под наши запросы. В AoS мы можем реализовать то, что вендоры никогда не сделают или затянут лет на шесть. Однако процесс перехода со старой CRM шел сложнее, чем планировалось, из-за ее многолетнего вплетения в платформы МТС. В какой-то момент разработка AoS оказалась в кризисе и встал вопрос о прекращении разработки.

На самом деле с такой ситуацией может столкнуться любой проект, даже сильный и с хорошими перспективами: команда истощена, упущены сроки, доверие бизнеса под угрозой. Нужно заново фокусировать цели и раскрывать потенциал продукта. Спасти его может антикризисное управление — и в этом материале я поделюсь стратегией, которую применил с CRM AoS. Она включает в себя три этапа: работу с людьми («Кто?»), фокусирование ресурсов на ключевых целях («Что?») и оптимизацию процессов («Как?»). Мне потребовалось около пяти месяцев, чтобы в продукт снова поверили, и он сдвинулся с мертвой точки.

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

Так что не судите строго — делюсь тем, что получилось, возможно, многое можно было сделать лучше или правильнее. Буду рад вашим советам!

У меня был сайт интернет‑магазина лабораторного оборудования, который постоянно ломался. Любое изменение — и что‑то отваливалось в другом месте. В итоге я решил: хватит мучиться, надо что‑то с этим делать. И попробовал создать новый сайт через нейросеть — через Claude.

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

Нужно было создать новый каталог для 400+ позиций лабораторного оборудования. Но это не классический интернет‑магазин с корзиной и оплатой, а каталог с формой «запросить цену» — в сфере B2B так часто работают.

Стоимость минуты простоя в iGaming может приносить миллионы упущенной прибыли и более тяжелые репутационные потери. Когда real‑time ставки замирают, а букмекерские терминалы уходят в ступор - это не просто баг. Это экзамен на зрелость команды и процессов. Что мы делаем после - определяет, повторится ли он снова.

Привет, Хабр, меня зовут Станислав, я Product manager! Представьте ситуацию: вы, как продакт, несколько недель потратили на исследования, кастдевы, прототипирование и дизайн. Вы выносили идею, защитили её перед стейкхолдерами и теперь, сияя от предвкушения, приносите команде разработки новый, идеально продуманный флоу. А в ответ — тишина. Или, что хуже, шквал вопросов в стиле «а зачем?», «у нас и так всё работает» и «это всё сломает».

Знакомо? Прежде чем записывать команду в ретрограды и саботажники, давайте разберёмся. То, с чем вы столкнулись — не вредность, а фундаментальный баг (или фича?) человеческой психики. Имя ему — сопротивление изменениям.

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

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

В контексте искусственного интеллекта Open Source-инструменты включают библиотеки, фреймворки, датасеты, модели и платформы, которые помогают разработчикам создавать, обучать и тестировать ИИ-системы.

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

Кажется, что всё ещё можно сделать чуть-чуть лучше, чуть-чуть полнее, чуть-чуть красивее… И всё.

Привет, Хабр! Меня зовут Александр Петрушин, я старший разработчик в VK Tech, и сегодня хочу рассказать о нашем опыте создания технического радара.

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

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

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

Без ссылок и подтверждений.

Про условную большую компанию в РФ.
Может потом примеры приведу... Посмотрим.

Итак... Если компания большая. Есть акционеры, руководство, несколько отделов.
Почти наверняка есть IT отдел, который состоит из 3 отделов: разработчики, эксплуатация, безопасники.

Предположим, что Я начальник этого отдела, у меня есть бюджет на работу отдела, есть некоторый функционал, который отдел должен делать.

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

Да нифига: аутсорсинг!

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

Иногда кажется, что команда вроде бы стабильная, спринты идут по плану — а под конец снова в панике жмёмся к дедлайну, выкидываем фичи и дорабатываем вечерами. Чтобы такого не происходило, я хочу рассказать про простую и очень рабочую модель — 3–3–3. Она помогает прогнозировать скорость команды без гаданий на story points и держать реалистичный фокус: сколько мы реально успеем, а не сколько хочется.

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

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

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

Мне 38, программирую с института — заканчивала по специальности. За 15 лет в IT успела побывать всем, кем только можно: техлид, архитектор, DevOps, backend, frontend. Когда в отрасли так долго, трудно найти что-то, чего не делала.

Разрабатывая девайсы, мы проходим полный цикл создания устройства: ES, EVT, DVT, PVT-этапы. Это международный инженерный фреймворк, его использует множество компаний. Но акцент во фреймворке на валидации и доработке хардверной части. О том, что в рамках каждого этапа требуется от софта, говорят мало и редко. Поэтому расскажу, как мы вписываем разработку программного обеспечения в основные этапы разработки «железа» и что требуют от software-команды на каждом этапе создания умных устройств Sber. Если вы хотите разрабатывать софт в хардверной компании или уже занимаетесь этим, но пока не работали в рамках фреймворка полного цикла — точно будет интересно.

Всем привет. Меня зовут Александр Виноградов, я главный архитектор Ви.Tech – ИТ-дочки ВсеИнструменты.ру. Последние 9 лет занимаюсь ИТ-архитектурой и менеджментом в архитектуре, и сегодня бы хотел поделиться с вами своим топом заблуждений про эту самую архитектуру из серии: «если бы мне каждый раз давали рубль, когда я слышу...». 

Кому будет полезна эта статья:

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

Вы узнаете, что:

— Не существует «правильных» технологий (и postgres не лучше mysql).
— Архитектор не должен писать код (и почему).
— Что покупка коробочных решений не избавляет от проблем.

И как же из паразита сделать симбиота? Agile — слово, которое стартапы любят произносить на каждом питче.

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

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

До недавнего времени я по большей мере игнорировал этот ажиотаж. Я читал заголовки, время от времени просил Claude или ChatGPT помочь мне в отладке, но ничего больше. Пришла пора учиться вайб-кодингу!

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

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

– Почему часть важных изменений в команде не приживается и откатывается к началу, хотя, кажется, мы все вместе нашли консенсус?
– Да каким образом мы снова не попали в сроки проекта, хотя у нас прекрасная опытная команда.
– Какова причина нежелания команды переходить на актуальный стек? Или наоборот, почему члены команды упорно тащат в ключевой проект сырые фреймворки и необкатанные подходы?
– Снова по итогам проекта у нас переусложненная и запутанная архитектура. Что мы делаем не так?

Давайте разбираться!

За 20+ лет в разработке я прошёл путь от студента с книгой по C++ до техлида, но понял: управление людьми приносит меньше удовольствия, чем написание кода. Карьерный рост — это не всегда движение вверх по иерархии, иногда стоит выбрать то, что действительно нравится, а в IT можно хорошо зарабатывать просто программируя.