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

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

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

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

Привет! На связи Ира Белица и Святослав Сычев. Мы работаем в Mindbox над высоконагруженным продуктом рассылок: более 850 наших клиентов генерируют свыше 20 тысяч RPS. Такой продукт требует много ИТ-поддержки, при этом клиенты постоянно запрашивают новые функции. Отсюда рассинхрон в команде: разработчикам важно поддерживать стабильность рассылок, менеджерам продукта — помогать клиентам решать их проблемы, зачастую с помощью новых фичей.

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

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

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

«Ваша документация — отстой!», «Я её никогда не читаю, всё равно там ерунда написана!», «Эти документаторы опять всё напутали», «Да любая нейросеть быстро напишет это в сто раз лучше», «Там никогда не найти ничего нужного», «А разве у нас есть документация?»

Обратная связь от читателей-пользователей далеко не всегда бывает конструктивной и вдохновляющей. Почему же так получается? Давайте разберём пять основных претензий читателей к технической документации и подумаем, что со всем этим делать.

Хабр, привет! Cегодня хочу рассказать про такой популярный инструмент управления проектами как матрица RACI.

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

Про то какие роли существуют в IT команде в разрезе этапов создания цифровых продуктов я ранее писал в Telegram канале сообщества IT'S Analysis.

Привет, Хабр! Меня зовут Настя, я — старший тестировщик ITFB Group. Представьте ситуацию (быть может, вы в ней даже уже бывали): вы пришли в компанию, и вас просят подхватить уже действующий проект, причём нужно поскорее войти в курс дела. С чего начинать, за что хвататься? Позвольте помочь: я расскажу вам о том, как можно заходить в новый проект, как его анализировать и где искать точки роста проекта и команды.

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

Нам, людям, свойственно совершать ошибки, и это ок. Главное — проанализировать, что пошло не так. Чтобы вы извлекали вывод без вреда, вот вам ТОП-5 ситуаций, которых вы можете избежать в своём бизнесе во имя прибыли, а не убытка.

Мне очень повезло, что я был за рулем, в этот гнусный октябрьский день. Так бы пошел водку пить. А так — вполне себе ничего: едешь, куда глаза глядят, рефлексируешь, и материшься: “за что же мне, хорошему, такая жопа”?

Миллион долларов на разработку уже был потрачен. Первые пользователи потихоньку покупали платные подписки и ставили звездочки в сторах. Но это и близко не окупало затрат на команду. 

Quickwit – это поисковой движок нового поколения, альтернатива для Elasticsearch, Loki и Splunk. Одна из главных особенностей Quickwit, заключается в том, что индексы хранятся в объектном хранилище (s3, minio, другие s3-совместимые проекты). Такая архитектура позволяет сократить использование вычислительных ресурсов и хранилища в несколько раз.

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

Привет! Я Мусали Генжеханов, СТО в компании 05.ru. Расскажу о том, как предпочёл офферу мечты путь джедая в Махачкале и почему решил развиваться внутри одной компании.

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

Да, на работе надо работать, но … разве таким способом? У автора статьи тоже был период работы с утра и до победного. Но был ли от этого толк? 

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

Привет, Хабр! На связи Кирилл Веркин. Вообще, я занимаю в СберМаркете должность Senior QA, но ради большей производительности команды стал немного кодером.

Эта статья может быть интересна тем, кто замечает, что задачи в команде часто теряются, и хочет автоматизировать процесс напоминалок. Я делюсь кодом, поясняя ключевые моменты для таких же новичков в Go. Мой код написан для сочетания GitLab, Jira и Mattermost (корпоративный мессенджер, которым мы пользуемся в СберМаркете), но подобное решение можно реализовать и с другими сервисами.

Всех приветствую в своей новой статье! Меня зовут Елизавета Акманова. С некоторыми читателями уже знакомы с предыдущих тем, для новых представлюсь: я системный/бизнес аналитик с опытом работы 3 года. Было много проектов разного уровня и сложности: начиная с монолитов в команде из 4 человек, заканчивая 50+ микросервисами из 90 человек. Но все проекты объединяло одно: API. Абсолютно в каждом присутствовал этот термин, приходилось работать с проектированием API, и сегодня я хотела бы рассказать про подходы, как это можно делать и подчеркнуть особенно метод API-first. 

Когда я работал программистом, мне было интересно не только написание кода. Я всегда любил анализировать, как в целом происходит работа в нашем отделе. Практически с самого начала карьеры мне казалось, что «изнутри» я вижу слабые места процессов и понимаю, как можно их улучшить и сделать проще. Шло время, опыт увеличивался, а желание влиять на происходящее постепенно становилось всё больше.

И вот, в какой-то момент мне захотелось попробовать себя в роли руководителя, но возникла проблема: я не знал, как им стать. Ответа на вопрос: «Что нужно делать, чтобы занять свою первую управленческую должность?» не было. Точнее, он был, но лишь в теории.

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

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

Рассмотрим такую спорную, но при этом полезную вещь как измерение метрик код ревью. Не секрет, что это один из неотъемлемых этапов в процессе разработки и возникающие проблемы могут в конечном итоге сказаться на расходах компании и удовлетворении от работы в команде. Чтобы этого не было, необходимо вовремя понимать есть ли проблемы, определять причины, находить решения и проверять их эффективность. В части этих вопросов нам и может помочь статистика. Можно найти как отдельные приложения сфокусированные на метриках, так и гитхаб-экшны. В данной статье речь пойдет о гитхаб-экшне Pull Request Analytics Action.