Сотни сообщений без смысла, игнор просьб, срочные задачи в полночь — вот настоящая «корпоративная культура». Я собрал 7 самых больных кейсов рабочего общения.
Говорят, стажёрам нельзя доверять прод — сломают, наделают ошибок, а потом мучайся. В «Авито» решили доказать обратное: дать ответственность сразу и посмотреть, что будет.
В статье — о том, как выглядят испытания для стажёров и у кого точно нет шансов попасть в команду.
Привет, Хабр.✌️ Это Люба и Кристина, менеджеры разработки в Контуре. Кроме менеджерских дел мы ведём в Контуре настолки про Kanban.
В Контуре уже несколько лет существует практика игры в GetKanban. Все началось с появления нескольких игровых комплектов в офисе, а сейчас это стало регулярной активностью со своей командой организаторов, онлайн-версией и удобными инструментами. Игра стала популярной благодаря своей механике: она в доступной форме объясняет базу Kanban-метода и помогает выявить узкие места в реальных процессах команды. В статье расскажем о том, какую пользу приносит игра, кто больше всего интересуется ею в Контуре, как организован процесс и кто такие ангелы.
Многие считают ITIL (Information Technology Infrastructure Library) устаревшим набором практик, которые не работают на современных процессах. Опыт «Петрович-ТЕХа» доказывает обратное.
Привет, Хабр! Меня зовут Антон Скутин и я business relationship & service level manager в «Петрович-ТЕХ». Вырос из специалиста техподдержки в лида направления качества и сервиса, в компании уже шесть лет, веду телеграм-канал BRM о своей работе. Расскажу про опыт, как мы в «Петрович-ТЕХ» внедрили ITIL и получили реальный профит. В процессе роста компании мы выделили три временных этапа внедрения ITIL-практик.
Статья написана по мотивам моего доклада для конференции DevOps Conf.
Меня зовут Илья Куликов, я руковожу разработкой веб-терминалов в компании «Столото». Сегодня хочу рассказать, как мы превратили ручные релизы и вечные конфликты в почти автономный CI/CD. За почти 10 лет в компании я прошёл путь от бэкенд-разработчика до руководителя направления, в «Столото» же за это время родился и вырос целый продукт — веб-терминал для агентов розничной сети. Изначально у нас был парк дорогих аппаратных терминалов, установленных у агентов. Но как расширить сеть и снизить входной порог? Возникла идея: а что, если сделать аналогичное приложение в браузере? Тогда любой желающий мог бы стать агентом — достаточно старого ноутбука и договора с нами. Так появился полноценный веб-аналог аппаратного терминала со всеми необходимыми функциями для продажи лотерей.
Но вместе с ростом продукта росла и боль: релизы занимали часы, всё постоянно ломалось на проде, а после каждого деплоя команда судорожно грепала логи в поисках причины падения. Мы поняли: без серьёзной перестройки процессов дальше — только хуже. И тогда решили кардинально пересмотреть наш подход к CI/CD. Отказались от классического GitFlow в пользу trunk-based development, полностью перестроили пайплайны в GitLab и внедрили автоматизацию на всех этапах — от сборки и тестирования до деплоя и мониторинга.
В этой статье я делюсь реальным опытом:
- как мы ушли от ручных релизов к автоматическому деплою в прод;
- какие практики и инструменты позволили нам перестать бояться каждого коммита;
- как повысить качество кода и ускорить вывод фич на рынок без ущерба для стабильности.
Этот материал будет особенно полезен техлидам, инженерам DevOps, разработчикам и командам, которые всё ещё живут в мире ручных деплоев, боятся нажимать «мердж» в пятницу вечером. Если вы задумываетесь, как перейти от хаоса к предсказуемости в релизах — вы по адресу.
А как мы этого добились — читайте под катом!
Вы уже научились отслеживать среднюю скорость запросов на проекте, и это большой шаг. Без преувеличений и какой либо иронии.
И теперь, когда вы перешли от "не измеряем ничего" до "измеряем среднее" — вы попали в ловушку.
Пока вы с удовольствием наблюдаете в отчетах красивые 200ms — ваши пользователи стучат в службу поддержки со словами "у меня все висит".
И они не врут, у них действительно TTF порядка 6 секунд. Но и вы не врете, у вас действительно 200ms в отчете!
Врет метрика, а вы ей верите.
Давайте разбираться.
За последние годы рынок IT сильно изменился. Сейчас найм Junior-разработчиков стал гораздо выгоднее для компаний: конкуренция среди молодых специалистов выросла, а текучка кадров снизилась. Разберём, почему именно сейчас лучшее время инвестировать в молодых разработчиков.
У нас есть легковые машины, грузовые машины, битумовозы, спецтехника и много чего ещё интересного. Всё это управляется через диспетчерскую, и там были некоторые костыли, обусловленные системой учёта. Например, нельзя было отправить пескоразбрасыватель, мобильную систему пылеподавления либо грузовик навалочной погрузки куда-то по сложному маршруту. Или чтобы они отработали не полную смену, потому что всё квантовалось сменами.
Копились и другие проблемы.
Например, пользователи стали продвинутыми и жаловались на дружелюбность интерфейса. На самом деле тяжело представить в одном предложении слова «дружелюбность интерфейса» и нашу старую систему заявок на транспорт.
Всё это работало только под IE/Edge, не поддерживало Хромиум, конфликтовало с требованиями ИБ.
Бизнес регулярно генерировал новые фичи, но некоторые из них было проблематично реализовывать в действующей системе.
Мы давно задумывались о рефакторинге или миграции, суть споров сводилась к самопису или «коробке».
Мы всё проанализировали и решили, что надо взять готовую «коробку», которую потом нужно будет допилить процентов этак на 10.
В итоге оказалось, что сначала мы допилили процентов на 20, а потом от исходной «коробочной» версии осталось процентов 10, и вся разработка переехала к нам внутрь.
Сейчас я расскажу о дьявольском опыте использования чужой «коробочной» версии как фреймворка для своей разработки. Забегая вперёд — второй раз мы в это не полезли бы.
Рассказываю о философии «липкой паутины» и о том, как я сделал инструмент, который превращает разрозненные дела в целостную систему. Без дедлайнов и уведомлений.
Если вы когда-нибудь чувствовали, что тонете в бесконечных списках задач, выставляете галочки в трекере, но при этом не видите общего прогресса — вы не одиноки. Я много лет искал систему, которая показывала бы не просто «что сделано», а «как всё связано». И нашёл её в самом неожиданном месте — наблюдая за тем, как обычный паук плетёт свою сеть.
Традиционные инструменты (канбан, TODO-листы) учитывают задачи, но игнорируют связи между ними. Они измеряют скорость, но убивают целостность. Паутина же — идеальная визуальная метафора для любой сложной системы. И сегодня я покажу, как эта метафора воплотилась в работающий инструмент — Stickyweb.
Утечка оперативной памяти в Apple Calculator достигает 32 ГБ.
Эта память не используется, не выделяется, она просто утекает. Простецкое приложение калькулятора страдает большей утечкой памяти, чем компьютеры десятилетие назад.
Случись такое в 2000-х, это бы привело к внесению срочных патчей и служебной проверке. Сегодня же это лишь очередной баг-репорт в очереди.
Мы урегулировали программные катастрофы такой степени, что утечка 32 ГБ в калькуляторе уже не удивляет. И дело не в ИИ. Кризис с качеством ПО начался за несколько лет до появления ChatGPT. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.
Я ненавижу идею соло-разработки. Не просто не люблю презираю как явление, которое почему-то принято романтизировать. Не сами игры, ведь я, как и вы, искренне восхищаюсь такими кейсами, как Animal Well, Stardew Valley, Papers, Please и многие другие. Нам всем нужна путеводная звезда. Но я ненавижу то, как этот путь “одиночки-страдальца” нормализуют и даже стандартизируют, превращая исключение из правил в какой-то достижимый идеал.
И ведь что странно: сколько бы я ни читал историй этих самых “одиночек”, там всегда красной нитью сквозит тема благодарности друзьям, семье, первым тестерам, людям к которым они обращались за помощью. Но мы почему-то переворачивая страницу запоминаем лишь то, что кто-то один, оказывается, страдал.
Осознанно выбирать путь тотальной изоляции — самая неблагодарная, деструктивная и попросту неправильная вещь, которую можно сделать со своим творческим потенциалом. Вы спросите:
— «А какая тогда альтернатива?»
Больше восьми лет я работал backend‑разработчиком. Мы создавали веб‑приложения для автоматизации логистики и закупок. Команда росла, процессы крепли. Всё было правильно и красиво: CI/CD, код‑ревью, споры о чистоте архитектуры и идеальном нейминге. Мир был прост, предсказуем и казалось, что так будет всегда.
Но однажды утром всё изменилось.
Проходя интервью на управленческие позиции в IT (например, Team Lead), часто можно попасть на секцию по опыту менеджмента командой. Казалось бы, рассказываешь о своем опыте, о принятых решениях и в целом о том, как успешно твоя команда выпускает релизы... Пока тебя не спросят «Ну а как ты понимаешь, что команда работает хорошо?».
Или ты вроде все делаешь «правильно» на проекте, но недовольство заказчика растет, и твои люди подают заявления, потому что выгорели.
И в голове щелкнет: что‑то я, видимо, упускаю.
Часто Kanban ассоциируется с продуктовыми командами. Но мы в Точка Банк решили внедрить его в Devexp — это команда, которая занимается предоставлением и сопровождением, а также разработкой и развитием инфраструктуры и сервисов для разработчиков. У ребят уже была небольшая база в виде простой панели в проекте Jira, но отсутствовали необходимые процессные метрики. Мы использовали системный подход STATIK, но адаптировали его с учётом специфики инженерной работы.
Меня зовут Андрей Муликов, я тимлид и менеджер проектов в инфраструктурной разработке. В статье рассказываю, какие шаги добавили в базовый алгоритм, и на что важно обращать внимание, когда меняешь сложные процессы.
И сразу отвечу на вопрос, зачем это вообще может понадобиться.
Есть четыре типовых ситуации:
1. Вы или проходите собеседование, или уже вышли на новую работу. Если собеседуетесь — то хорошо бы понять, насколько вы вообще готовы ввязаться в происходящее и чем оно может вам грозить. Если же уже вышли на работу — значит, в ближайший квартал от вас будут ждать какого-то результата, и вам надо не распыляться на все сразу, а найти точку приложения своих усилий, чтобы решить какую-нибудь проблему, показать результат и доказать руководителю свою ценность.
2. Участие в due diligence. Ваша компания планирует покупку стороннего бизнеса. Тут аудит нужен для того, чтобы не повестись сходу на красивые продающие слова и не купить кота в мешке. С большой вероятностью, техническая сторона при объединении бизнесов может оказаться в вашей зоне ответственности, и нужно понимать, чем это грозит.
3. У вас попросили консультацию — на профессиональной основе или в формате помощи другу.
4. Вы не собираетесь ни на новую работу, ни покупать чей-то бизнес — вам просто кажется, что у вас сейчас на работе что-то идёт не так, и вы хотите всё оценить и понять, что именно.
В этой статье я расскажу, как адекватно и полноценно оценить состояние разработки. Меня зовут Андрей Бирюков, в разработке я 25 лет — начинал как разработчик, сейчас руковожу разработкой и клиентскими сервисами в InfoWatch. С этой темой я выступал на CTO conf, теперь подготовил для вас текстовую версию.
Кажется, что «Лента» — это про тележки и кассы. Но внутри — полноценный инженерный контур: Big Data, DevOps, микросервисы и собственные платформенные решения.
В статье — как Lenta Tech ломает стереотип «ретейл ≠ айти» и почему туда переходят разработчики из бигтеха.
В командах часто тратят часы на ручное обновление статусов задач, проставление дат релизов и уведомления коллег о готовности работы.
В этой статье я покажу, как с нуля настроить правило в Jira Automation: от выбора триггера и условий до действий с задачами. Даже если вы никогда не работали с Jira Automation, следуя шагам, вы сможете создать свой первый рабочий сценарий за 10 минут.
О чем статья: Это художественное произведение, основанное на реальных событиях, о том, как собрать команду и штурмовать самые перспективные мероприятия на стыке науки и технологий. Одновременно это — руководство для тех, кто хочет впервые принять участие в хакатоне и не сгореть. Прочитав его, вы получите один из вариантов развития событий со стороны менеджера проектов.
«Проект провалился ровно в 23:47. Не в четверг, а в среду, что было особенно обидно. Gantt-чарт, ещё утром сиявший аккуратными зелёными полосками, теперь напоминал окопы под Верденом. Иван, молча смотрел в экран. Разработчик, наблюдал уже третий сон. Роман, безуспешно пытался разобраться с бэкендом. А до дедлайна оставалось 14 часов. И это был мой звёздный час как проджект-менеджера».
Как до этого дошло...
Cursor — это не просто новая IDE, а умная среда разработки с полноценными AI-агентами, способная понимать проект, анализировать код и помогать разработчикам, аналитикам и продакт-менеджерам работать быстрее и точнее. В этой статье я подробно расскажу, как Cursor помогает ускорять разработку, автоматизировать рутину и улучшать качество кода за счёт интеграции искусственного интеллекта в повседневные процессы.
Мы привыкли думать, что «общество не допустит» появления опасного ИИ. Но что, если это иллюзия - такая же, как вера Германии в 1940-м, что атомная бомба невозможна? История показывает: технологии не ждут морального одобрения. Они распространяются тогда, когда становятся возможными - независимо от этики, запретов и «общественного мнения».
Сегодня ИИ уже здесь. Он открыт, глобален и децентрализован. Llama 3, Mistral, Qwen - доступны любому студенту. А миллионы решений о кредитах, найме и даже приговорах уже принимаются алгоритмами без участия человека.
Но главная угроза - не в «восстании машин». Она в том, что мы сами перестаём думать, делегируя всё больше решений системам, которые «знают лучше». И даже те, кто имеет доступ к самым продвинутым ИИ, часто не понимают, как они работают. Это не сознание - это статистическая интуиция, «инопланетный разум», который эффективен, но непрозрачен.
В статье мы разбираем:
почему «подпольный ИИ» - худший сценарий, а открытость - единственный шанс на контроль;
как формируется эпистемологическое неравенство: массовый ИИ для всех, а элитный - для избранных;
почему даже CEO не понимают, как работает их собственный ИИ;
и как избежать судьбы «ученика Герострата» - человека, который разрушил будущее, не осознавая, что делает.
Это не призыв к запретам. Это призыв к ответственности: развивать не только ИИ, но и наш собственный разум, чтобы научиться понимать то, что мы не понимаем.
Потому что наивность - роскошь, которую человечество не может себе позволить в эпоху ИИ.
