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

Рассказываю о философии «липкой паутины» и о том, как я сделал инструмент, который превращает разрозненные дела в целостную систему. Без дедлайнов и уведомлений.

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

Традиционные инструменты (канбан, 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 не понимают, как работает их собственный ИИ;

и как избежать судьбы «ученика Герострата» - человека, который разрушил будущее, не осознавая, что делает.

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

Потому что наивность - роскошь, которую человечество не может себе позволить в эпоху ИИ.

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

Прежде чем приступить к готовке настоящей Системы управления информационной безопасности (СУИБ) по ISO/IEC 27001:2022, важно осознать масштаб: у нас в хозяйстве Яндекс 360 множество сервисов с уникальным вкусом и историей, каждый из которых требует бережного подхода и особой организации защиты.

Стандартизация для нас — способ не «пересолить» сложность и хаос: и мы выбрали ISO как универсальное мерило баланса. Наш главный секрет: процессы изначально проектируются по стандарту ISO, а по мере расширения области действия сертификации новые сервисы — Диск, Мессенджер, Телемост, Календарь — поступают на общий дегустационный стол сертификации и достойно занимают своё место в большом ИБ‑меню.

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

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

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

Когда мы запускали наш API на Cloudflare Workers, они казались идеальным выбором для сервиса API-аутентификации. Глобальная периферийная инфраструктура, автоматическое масштабирование и оплата только за использование. Разве это не замечательно?

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

TL;DR:

• Мы перешли с Cloudflare Workers на Go-серверы
• Снизили задержки в шесть раз
• Устранили сложные механизмы обхода кэшей и оверхед конвейеров данных
• Упростили архитектуру, перейдя от распределённой системы к простому приложению
• Обеспечили возможность самохостинга и платформонезависимость

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

Привет, Хабр! Меня зовут Артем Грищенко, я middle iOS-разработчик продуктов Future Crew в МТС. Если ты начинающий разработчик — скорее всего, у тебя есть мечта: вырасти, перестать быть «новичком» и почувствовать уверенность в своих силах. Чаще всего говорят: «Это долгий процесс, наберись терпения». И действительно, путь у каждого свой. Но у всех карьерных путей есть общее: рост возможен только при увеличении зоны ответственности. Об этом часто забывают, годами просиживая на одном месте. 

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

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

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

Поздравляю. У вас вырос корпоративный IT-монстр.

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

Существует множество различных сводов знаний, применимых к комплексным программным системам: PMBoK для управления проектами, BABoK для бизнес-анализа, BPM CBOK для управления бизнес-процессам, EABoK для управления кооперативной архитектурой, а также SWEBoK по программной инженерии. Практически во всех сводах знаний делается акцент именно на внедрение и смежные активности, забывая про то, что имплементация программного продукта завершается его передачей в поддержку. Одним из немногих литературных источников по данной тематике является ITIL [2], описывающий четыре домена знаний, позволяющих осуществлять сопровождение решения после его реализации.

В контексте BABoK и расчета бизнес-кейса, выполняемого при предпроектном обследовании, довольно часто рассчитывается показатель TCO (Total Cost of Ownership, совокупная стоимость владения), демонстрирующий постоянные и переменные затраты, которые понесет компания при внедрении программного обеспечения. Одной из постоянных статей затрат является сумма поддержки и развития информационной системы. Таким образом, знание особенностей выполнения этапа поддержки и развития программной системы позволяет рационально планировать затраты и разумно ограничивать содержание проекта имплементации.

Привет, Хабр! Я — Алексей Григорьев, лид iOS-разработки продуктов Future Crew в MWS. Наша команда со стартап-вайбом: технологий свежих много, стек обновляется часто, требования к скорости внедрения — высокие. Нужны мотивированные сотрудники, но нет времени и сил искать готовых сеньоров. Поэтому мы ставим на рост внутри команды. Не просто не боимся брать стажеров и джунов — нам даже это интересно. От первого лица почитать историю о том, как мы вырастили джуна до мидла за год, можно тут. 

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