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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Несмотря на упоминание различных способов разработки программных систем, существует три классические модели, применимые в том числе для внедрения коробочных программных решений [1]:

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

Под катом принципы декомпозиции (с обобщёнными примерами) и история этих принципов

....................................................................................................

ИИ-ассистенты обещают ускорение, но полевой эксперимент METR с 16 разработчиками и 136 реальными багами показал обратное: с Cursor задачи выполнялись в среднем на ~19% дольше. Писать код действительно выходило быстрее, зато время съедали промптинг, ожидание ответов, проверка результатов и IDE-оверхед. Разбираемся, где ломается обещанная эффективность, как на неё влияют внимание и «поток», и когда ИИ в разработке реально окупается.

Жёсткость неустойчива. Жёсткие процессы, фреймворки и механизмы управления проектами могут давать краткосрочные результаты, но подрывают долгосрочную устойчивость.

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

Привет, Хабр! Меня зовут Алексей Грохотов, я разрабатываю продукт Сфера.Архитектура в ИТ‑холдинге Т1. Перед нашей командой стояла задача перенести документы из Orbus iServer в Сфера.Архитектуру. Iserver — это набор инструментов для описания, поддержки и трансформации архитектуры предприятия. Он в значительной степени интегрирован с Microsoft Office, например, все схемы в этом инструментарии создаются в Visio.

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

Продолжение статьи о разработке B2B платформы международной торговли

Прошло несколько месяцев с момента публикации первой части, где мы рассказали о концепции и начальном этапе разработки LiqTrade. За это время проект прошел путь от MVP до полноценной production‑ready платформы.

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

Дисклеймер: Если вы ищете статью в стиле «10 строк кода, и ваш стартап взлетел» — это не здесь. Здесь будет про то, как мы 3 раза переписывали систему ролей, боролись с circular dependencies и почему наш bundle вырос до 1.2 МБ (спойлер: мы его победили).

Представьте, что вы лидер молодого, но быстрорастущего стартапа в области ML. Вам предстоит собрать команду, и вы думаете о том, каких специалистов вам предстоит найти:

- Data Scientist — для создания прототипов моделей машинного обучения, подходящих по задачи вашего проекта;

- ML Engineer — для внедрения в эксплуатацию моделей и сценариев, масштабирования;

- Data Engineer — для создания ETL‑процессов, систематизации сбора и хранения данных;

- DevOps/MLOps — для автоматизации процессов и развития инфраструктуры;

- SRE — для обеспечения мониторинга и надёжности вашей инфраструктуры.

Организовать работу всех направлений с нуля будет задачей не из лёгких. Но как принять этот вызов, если вы не обладаете экспертизой во всех направлениях?

За последние ~5 лет я много раз сталкивался с задачей собирать логи: обычно из маленьких или средних по размеру кодовой базы проектов. Отправлять логи из кода не проблема, у Java и Go для этого есть библиотеки практически из коробки. А вот разворачивать что-то для их сбора — головняк. Понятно, что решаемый (ещё до ChatGPT, а сейчас так тем более), но всё же. Все системы логов, прежде всего, ориентированы на большой-большой enterprise мир и его требования, а не на простых смертных с несколькими палками, клеем и дедлайном "вчера".

Запуск ELK для меня каждый раз испытание: куча настроек, нетривиальный деплой, а при заходе в UI разбегаются глаза от вкладок. С Loki и Graylog — немного проще, но всё равно функций сильно больше, чем мне нужно. При этом разделять логи между проектами, добавлять других пользователей в систему так, чтобы они не видели лишнего — тоже не самый очевидный процесс.

Поэтому примерно год назад я решил, что сделаю свою систему для сбора логов для себя: максимально простую в использовании и запуске. Чтобы разворачивалась на сервере одной командой, вообще без настроек и без лишних вкладок в интерфейсе. Собственно, так появился и теперь вышел в open source Log Bull: система для сбора логов для разработчиков с проектами middle-sized размера.

(спойлер: в конце будет ссылка на GitHub)

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

Потом проект стартует…

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

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

Привет, Хаброжители! Хотите узнать, как вывести продукт на новый уровень и сделать его более эффективным с точки зрения бизнеса? Тогда разработка, основанная на гипотезах (Hypothesis Driven Development, HDD) от Алекса Коуэна станет незаменимым подходом в управлении продуктом.

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

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

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

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

Но что делать когда этого не достаточно и пользователи все равно жалуются?