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

Нанимать джунов — это настоящая pain in ass. Откликов приходит больше ста в неделю, а кандидаты отличаются по уровню: одни только вчера окончили курсы, другие — почти мидлы. Пока разберем все отклики, проверим тестовые, проведем собеседования — проходит полтора месяца. А потом найденный сотрудник не проходит испытательный, и все повторяется снова.

Чтобы облегчить поиск, мы в Mindbox настроили конвейер стажировок. Теперь на отбор тратим меньше времени, а получаем разработчиков, знакомых с процессами, проверенных «в бою» и лояльных к компании. В статье — подробная инструкция для нанимающих менеджеров: как построить процесс, проводить собеседования и онбордить стажеров.

Далее >>>

Об авторе

Меня зовут Глеб Ковалев, я ведущий frontend-разработчик в Mindbox. Пару лет назад я начал проводить стажировки для frontend-разработчиков. А сейчас начинающих фронтов мы нанимаем преимущественно через стажировки. О том, как это происходит, расскажу в этой статье.

Приветствую! Меня зовут Борис, я руководитель отдела фронтенд-раработки в ЮМoney и продакт-менеджер платформенной команды. О сложностях управления подобными командами и проблемах, которые иногда возникают, уже рассказывал в своей предыдущей статье. Сегодня хочу поделиться историей о том, как в условиях ограниченных ресурсов нам удалось выстроить консистентность пользовательского интерфейса в сервисе, который состоит более чем из 70 микросервисов и охватывает разные направления бизнеса.

Так почему же Contract First оказался не так хорош на практике?

Это связано с тем, что в теории Contract First не учитывает необходимость постоянных доработок контракта и коммуникации между командами. Основная проблема кроется не в инструментах, а в процессах разработки API: если они выстроены плохо, коммуникация нарушается. Именно процессы — а не недостаток компетенций или инструментов — являются источником проблем.

Привет, Хабр! Меня зовут Алексей Панаэтов, я технический лидер Центра геосервисов в МТС Web Services. Каждый руководитель рано или поздно задается вопросом о количественной оценке эффективности команды. Метрики помогают принимать решения объективно, но их очень сложно строить, когда в работе активно используются множества разных инструментов: трекеры задач, системы контроля версии, корпоративный мессенджер и другие. К ним нужно сначала получить доступ, затем выгрузить и обработать нужные данные. Ad-hoc-методы вроде csv-файлов и таблиц Excel подходят для разового анализа, но их тяжело поддерживать.

Я тоже столкнулся с этой проблемой и для ее решения создал и выложил в открытый доступ код CaptainBridge — инструмент, который помогает собирать и строить метрики эффективности команды.

Привет! Меня зовут Арсен, я разработчик в DDPlanet и сегодня хочу поделиться нашим опытом разработки системы KPI для оценки производительности сотрудников в нашей компании. Как мы пришли к необходимости такой системы, как реализовывали первую и последующие версии и почему выбрали те или иные инструменты при разработке.

Меня зовут Кристина Павлив, я руководитель продукта в МТС: с нуля прорабатывала идею и развиваю приложение МТС Field, которым пользуются наши полевые инженеры.

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

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

Привет! На связи команда Spectr!

1-2 августа в Перми мы проведем уже традиционную конференцию про разработку и управление в IT-компаниях — Ural Digital Weekend 2025. Сейчас уже готова программа всех секций. Рассказываем, кто выступит в 2025 году.

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

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

Всем привет) Я - Саша Зебелева, налаживаю процессы в IT командах.
Регулярно пишу в свой канал про жизнь и работу. Заходите на огонек 🔥

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

Антон Назаров - бывший инженер-разработчик с карьерой в EPAM, Electrolux, Grid Dynamics, Autodesk, Everli. Сейчас у него:

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

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

Привет, Хабр! Я Лера, технический писатель в Авито. Помимо работы с технической документацией, я люблю читать книги, которые помогают расти профессионально. Одна из таких книг — Dare to Lead Брене Браун, она не про графики и KPI, а про то, как быть смелым, человечным лидером в мире, где давление дедлайнов и технические вызовы могут заглушить всё остальное.

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

Магии не существует, а есть способы планирования, которые помогают работать эффективнее и продвигаться в больших и сложных делах. Мы собрали 42 способа, инструмента, подхода к планированию: как базовые, так и новаторские. Разберем, как ими пользоваться и насколько они хороши.

ЭТП ГПБ и VESNA — это синергия опыта и инноваций, создающая цифровую экосистему для бизнеса и государства. От автоматизации закупок до комплексных ИТ-решений — компании продолжают задавать тренды в цифровой трансформации, обеспечивая клиентов передовыми технологиями и надежными сервисами.

Это история о том, как я устал держать в голове инфраструктуру по всем своим проектам.

Прод падает — а ты тратишь время на то чтобы вспомнить где лежит Grafana, где настраивается DNS, чей Docker Registry мы используем, есть ли у нас CDN и какой.

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

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

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

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

Привет. Меня зовут Карина, я PM сервиса «Майснаб». Мне всегда казалось, что корректно сформулированный фидбек о работе — то, чего хотят все. Он как навигатор в Google Maps: не просто говорит, что ты не там, а показывает, где свернуть, чтобы прийти куда нужно.

Сегодня поговорим о том, что многие делают, но мало кто делает правильно — о безопасной разработке и DevSecOps. Для этого мы пригласили Романа Гаголушко, руководителя отдела консалтинга безопасной разработки в Бастионе. Передаем ему слово.

Небольшой дисклеймер.

За годы работы в сфере безопасности разработки я насмотрелся:

— на вопиющие случаи игнорирования базовых принципов безопасности (и не только при разработке);

— на неэффективные попытки внедрения Dev «Sec» Ops;

— на откровенную и безрезультатную имитацию бурной деятельности;

— на такую же безрезультатную трату бюджета при закупке неподходящих инструментов анализа кода;

— на безразличие;

— на нежелание видеть очевидные вещи;

— на непонимание ИБ и БР со стороны разработки.

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

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

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

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

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

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

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

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

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

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

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