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

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

«Проект провалился ровно в 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. Наша команда со стартап-вайбом: технологий свежих много, стек обновляется часто, требования к скорости внедрения — высокие. Нужны мотивированные сотрудники, но нет времени и сил искать готовых сеньоров. Поэтому мы ставим на рост внутри команды. Не просто не боимся брать стажеров и джунов — нам даже это интересно. От первого лица почитать историю о том, как мы вырастили джуна до мидла за год, можно тут. 

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

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

Мы тут в свободное время пилим проект, который должен решить боль многих айтишников, — автоматизировать рутинный поиск работы. Идея выросла в Telegram-бота «Аврора» , который на "автопилоте" ищет вакансии на hh.ru и откликается на них.

Но чтобы "автопилот" был полезным, он должен быть надежным. Никому не нужен ассистент, который при первом же деплое новой версии или падении сервера забывает, что он делал, и какие вакансии уже отправил.

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

Под катом — наш подход к Graceful Shutdown, восстановлению сессий и немного про то, как LLM (в нашем случае Gemini) генерирует поисковые запросы.

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

Привет, Хабр! Я Владимир Комаров — программист, администратор, архитектор данных и инфраструктуры, преподаватель и автор. В этой статье по мотивам моего доклада на Highload++ мы посмотрим, как развивались системы управления базами данных: с чего всё начиналось, как система хранения данных СУБД эволюционировала, и в каком состоянии эта область находится сейчас. А заодно узнаем, существует ли идеальная СУБД, и если нет, то как приблизиться к идеалу.

Вряд ли найдётся кто-либо, кто в здравом уме и ясной памяти будет отрицать необходимость документации. Любой продукт имеет (или должен иметь) свою документацию. Как минимум – инструкцию о том, как этим продуктом пользоваться. Производители почти всегда указывают – «прежде чем начать пользоваться нашим продуктом, внимательно ознакомьтесь с инструкцией».  

Но дело почти никогда не ограничивается инструкцией пользователя. Производители также составляют и другую документацию – техническую, эксплуатационную.

Но ЧТО же должен создавать автор документации? Что должна в себя включать документация, когда, на каком этапе и в каком объёме она должна создаваться, ЧТО она должна содержать, когда, кому и при каких обстоятельствах она может потребоваться?

В данной статье мы и поразмышляем об этом...

(Перевод моего выступления на  P.I.W.O в июне, слегка подчищенный и приближенный к формату блога).

…звучит как-то не очень. Я сделала все эти слайды в Inkscape с ПК под управлением KDE Linux, плюс я регулярно пользуюсь Firefox. Но это всего лишь я. А что насчёт вас? Вы используете свободное ПО? Поднимите руки! [в аудитории поднимаются руки] Конечно же! Что за чепуха, «Свободное ПО не победило». Кто-то подменил мои слайды… Эй, ведущий конференции!

Ведущий: В другом каталоге.

[Перехожу в каталог с названием другой каталог и открываю файл твои слайды тупица.pdf]

Вот они мои слайды.

Всех приветствую, меня зовут Дорота, и сегодня я буду говорить о том, как …

Как писать концепцию проекта, ставить задачи, адаптировать agile, почему метод персон и JTBD нерабочие, как починить сторипойнты, что делать, если менеджер - петух, и как тушить пожары, сколько зарабатывают ПМы в банках и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

AI давно обещает избавить менеджеров от рутины, но делает ли он это на самом деле?

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

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

Чтобы понять почему так происходит, придется обсудить петухов. Не с целью оскорбить а с целью разобраться. Это, пожалуй, самая точная метафора про управление командой.

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

Удаленная команда требует другого мышления: в коммуникации, в управлении, в культуре. Нужны правильные инструменты и подходы. О них и поговорим ниже.

Привет, Хабр! Меня зовут Антон Ивахненко, я технический директор группы Рунити и по совместительству — СТО в РБК.

Когда-то я сам впервые оказался в роли СТО. Тогда Рунити еще не существовало, и разработка в компании была относительно небольшой. А потом — слияния, рост, новые структуры, десятки направлений. Со временем мне довелось искать и адаптировать руководителей разработки, выстраивать команды с нуля и смотреть, как люди по-разному проживают одну и ту же роль. Кто-то брался тащить всё на себе, кто-то терял темп на втором месяце, кто-то выстраивал всё удивительно спокойно — и всё работало.

За годы я повидал много историй — и своих, и чужих. В статье поделюсь личным опытом: как зайти в роль СТО, удержаться в ней первые месяцы и не выгореть.