Привет! 2-3 августа в Перми мы проведем уже традиционную конференцию про разработку и управление в IT-компаниях — Ural Digital Weekend 2024. Сейчас готова программа всех секций. Рассказываем, кто выступит в 2024 году.
Управление разработкой *
Планирование, отслеживание и контроль
Новости
Ловушка фичеризма: почему продукт страдает, когда мы зациклены на функциональности
Наполняя сервис функциями, которые непременно будут нужны и понятны для пользователя, легко перестараться и произвести эффект ровно противоположный. Часто те, кто «живут» своим продуктом, забывают, что все его преимущества и удобства — не данность для пользователя, а дополнительная когнитивная нагрузка, которая может начать зашкаливать, если создатели сервиса не будут периодически заземляться.
Под катом небольшое, но осмысленное размышление о том, почему фичеристский подход может убить пользу продукта, и как подойти к разработке так, чтобы этого все‑таки не произошло.
Техдолг: как разгребать задачи, чтобы не тормозить развитие продукта. Инструкция с шаблоном
Привет! На связи Ира Белица и Святослав Сычев. Мы работаем в Mindbox над высоконагруженным продуктом рассылок: более 850 наших клиентов генерируют свыше 20 тысяч RPS. Такой продукт требует много ИТ-поддержки, при этом клиенты постоянно запрашивают новые функции. Отсюда рассинхрон в команде: разработчикам важно поддерживать стабильность рассылок, менеджерам продукта — помогать клиентам решать их проблемы, зачастую с помощью новых фичей.
В этой статье расскажем, как научились договариваться между собой и выстроили процесс работы с техдолгом. Теперь разработке не приходится постоянно тушить пожары, менеджеры продукта знают, когда получат очередную доработку, а клиентам гарантирован надежный сервис и инструменты для решения задач.
Внутри — шаблон модели для автоматического скоринга техдолга. Копируйте его, чтобы приоритизировать бэклог и систематически его вычищать.
Измерение продуктивности разработчиков с помощью данных, полученных от людей
Измерение производительности разработчиков — сложная задача. Традиционные метрики, ориентированные на время цикла разработки и пропускную способность — ограничены, и нет очевидных ответов на вопрос, к каким метрикам ещё можно обратиться. Качественные метрики предлагают мощный способ измерения и понимания производительности разработчиков с помощью данных, полученных от самих разработчиков. Организациям следует уделять первоочередное внимание измерению производительности разработчиков с помощью данных, полученных непосредственно от людей, а не от систем.
Истории
Почему пользователи ненавидят вашу документацию и как это исправить
«Ваша документация — отстой!», «Я её никогда не читаю, всё равно там ерунда написана!», «Эти документаторы опять всё напутали», «Да любая нейросеть быстро напишет это в сто раз лучше», «Там никогда не найти ничего нужного», «А разве у нас есть документация?»
Обратная связь от читателей-пользователей далеко не всегда бывает конструктивной и вдохновляющей. Почему же так получается? Давайте разберём пять основных претензий читателей к технической документации и подумаем, что со всем этим делать.
Что такое матрица RACI? Как этот инструмент управления проектами может повысить производительность
Хабр, привет! Cегодня хочу рассказать про такой популярный инструмент управления проектами как матрица RACI.
Эта матрица используется для уточнения ролей и обязанностей сотрудников по каждой задаче, этапу и решению, которые принимаются на протяжении всего проекта.
Про то какие роли существуют в IT команде в разрезе этапов создания цифровых продуктов я ранее писал в Telegram канале сообщества IT'S Analysis.
Как лиду тестирования войти в проект
Привет, Хабр! Меня зовут Настя, я — старший тестировщик ITFB Group. Представьте ситуацию (быть может, вы в ней даже уже бывали): вы пришли в компанию, и вас просят подхватить уже действующий проект, причём нужно поскорее войти в курс дела. С чего начинать, за что хвататься? Позвольте помочь: я расскажу вам о том, как можно заходить в новый проект, как его анализировать и где искать точки роста проекта и команды.
Как мы снизили Cycle Time и увеличили Change Frequency
Раньше у нас был единый и большой департамент, который отвечал за разработку всего интернет-банка и мобильного банка. Он состоял из отделов, через которые проходили все разрабатываемые продукты и сервисы. Последовательное согласование тормозило жизненный цикл продукта, в частности Time to market.
Было принято решение поменять модель — перейти к кросс-командной организационной архитектуре, когда каждая команда является самостоятельной единицей, может делать End-to-end-разработку от начала сбора требований до разработки и эксплуатации на продакшен.
Клиентская миграция: как бизнес переводит клиентов из старого приложения в новое
Как не устроить клиентам шоковый переход и почему выкатывать неидеальное приложение на пользователей — нормально.
5 советов, которые нужно услышать прежде чем заказывать разработку сайта
Нам, людям, свойственно совершать ошибки, и это ок. Главное — проанализировать, что пошло не так. Чтобы вы извлекали вывод без вреда, вот вам ТОП-5 ситуаций, которых вы можете избежать в своём бизнесе во имя прибыли, а не убытка.
Шина для Росатома: собрали ядро из опенсорса и прошли сертификацию ФСТЭК
Возможно, вы слышали много историй про то, как для какой-то крупной компании разрабатывается система, которая потом становится просто неприменимой примерно нигде, включая изначальную компанию.
Мы Гринатом — условно говоря, ИТ-интегратор Росатома, но не только. Наш основной заказчик ставит задачу на отраслевые решения. То есть по факту мы делаем решения для Росатома, но при этом учитываем, что другим российским компаниям они тоже нужны. И в этом месте случается самое интересное: эти решения должны быть конкурентными, применимыми за пределами контура заказчика и вообще работать.
В 2022 году у всех стала «болеть» шина. На самом деле наша история началась в 2017-м, но к 2020 году у нас уже был проект, который можно было доделать до отраслевого решения. А когда доделали — решили вывести его на коммерческий рынок, чтобы шину как продукт могла купить любая российская компания, которой это нужно.
Но у нас в задаче она должна иметь 4-й уровень доверия ФСТЭК и входить в реестр российского ПО.
В общем, мы взяли опенсорсное ядро Apache NiFi под лицензией Apache 2.0, выделили ядро и коннекторы, провели многоступенчатый аудит кода, модифицировали его под локальные требования и засертифицировали во ФСТЭК свой форк, а потом к этой стабилизированной версии дописали всё остальное, что нужно. К слову, лицензия Apache 2.0 позволяет сильно перерабатывать исходный код и распространять результат коммерчески как самостоятельное произведение. Ничего сверхоригинального, но это много довольно тяжёлой работы. Про неё и расскажу подробнее под катом.
Как бизнесу перестать быть заложником IT (или зачем Маск — X распечатал)
Мне очень повезло, что я был за рулем, в этот гнусный октябрьский день. Так бы пошел водку пить. А так — вполне себе ничего: едешь, куда глаза глядят, рефлексируешь, и материшься: “за что же мне, хорошему, такая жопа”?
Миллион долларов на разработку уже был потрачен. Первые пользователи потихоньку покупали платные подписки и ставили звездочки в сторах. Но это и близко не окупало затрат на команду.
Quickwit. Когда Elasticsearch слишком дорогой
Quickwit – это поисковой движок нового поколения, альтернатива для Elasticsearch, Loki и Splunk. Одна из главных особенностей Quickwit, заключается в том, что индексы хранятся в объектном хранилище (s3, minio, другие s3-совместимые проекты). Такая архитектура позволяет сократить использование вычислительных ресурсов и хранилища в несколько раз.
Ближайшие события
Жёсткое руководство
В последнее время всё чаще можно услышать об ужесточении чего-либо, в любой из сфер жизни. Поповское слово "милосердие" стало архинепопулярным во времена быстрых перемен. Массам предлагается образ "твёрдой руки", и массы взывают к "наведению порядка жёсткой рукой". В этом статье попробую рассказать, почему это всегда плохо как минимум при построении управления внутри коммерческой компании.
Из бэкендера в CTO, минуя корпорации: личный опыт
Привет! Я Мусали Генжеханов, СТО в компании 05.ru. Расскажу о том, как предпочёл офферу мечты путь джедая в Махачкале и почему решил развиваться внутри одной компании.
19:43, еще не завтракал…
Это подпись к посту в ленте одного руководителя крупной российской компании. Была и подходящая фотография, иллюстрирующая, что человек работает на разрыв аорты.
Да, на работе надо работать, но … разве таким способом? У автора статьи тоже был период работы с утра и до победного. Но был ли от этого толк?
В данной статье попробуем разобраться, что может стоять за такой демонстрацией миру себя и причины, почему наш герой так поздно завтракает.
Как я написал для своей команды бот-напоминалку на Golang и втрое сократил время на ревью задач
Привет, Хабр! На связи Кирилл Веркин. Вообще, я занимаю в СберМаркете должность Senior QA, но ради большей производительности команды стал немного кодером.
Эта статья может быть интересна тем, кто замечает, что задачи в команде часто теряются, и хочет автоматизировать процесс напоминалок. Я делюсь кодом, поясняя ключевые моменты для таких же новичков в Go. Мой код написан для сочетания GitLab, Jira и Mattermost (корпоративный мессенджер, которым мы пользуемся в СберМаркете), но подобное решение можно реализовать и с другими сервисами.
Подход к разработке API API-first: как внедрить и почему это работает
Всех приветствую в своей новой статье! Меня зовут Елизавета Акманова. С некоторыми читателями уже знакомы с предыдущих тем, для новых представлюсь: я системный/бизнес аналитик с опытом работы 3 года. Было много проектов разного уровня и сложности: начиная с монолитов в команде из 4 человек, заканчивая 50+ микросервисами из 90 человек. Но все проекты объединяло одно: API. Абсолютно в каждом присутствовал этот термин, приходилось работать с проектированием API, и сегодня я хотела бы рассказать про подходы, как это можно делать и подчеркнуть особенно метод API-first.
Хочу стать тимлидом: как выбрать свой путь от специалиста в руководители
Когда я работал программистом, мне было интересно не только написание кода. Я всегда любил анализировать, как в целом происходит работа в нашем отделе. Практически с самого начала карьеры мне казалось, что «изнутри» я вижу слабые места процессов и понимаю, как можно их улучшить и сделать проще. Шло время, опыт увеличивался, а желание влиять на происходящее постепенно становилось всё больше.
И вот, в какой-то момент мне захотелось попробовать себя в роли руководителя, но возникла проблема: я не знал, как им стать. Ответа на вопрос: «Что нужно делать, чтобы занять свою первую управленческую должность?» не было. Точнее, он был, но лишь в теории.
В тот период я считал, что стать руководителем без опыта ещё сложнее, чем джуниору после курсов найти первую работу. Какое-то время мне пришлось ждать своего шанса, и вот он наконец-то представился. Сегодня, уже имея за плечами опыт, я знаю несколько способов это сделать. Я хочу рассказать о существующих путях от специалиста в менеджеры, какие из них, на мой взгляд, проще, а какие, наоборот, труднее.
Мы поговорим о том, какой путь выбрал я сам, и по какому шли мои коллеги. В конце постараемся вместе ответить на вопрос: «Как выбрать путь, подходящий для вас?». На тот момент я бы очень хотел прочесть такой гайд, но его ещё никто не написал. Это и побудило меня к созданию этой статьи:)
Простой инструмент измерения и анализа Code Review
Рассмотрим такую спорную, но при этом полезную вещь как измерение метрик код ревью. Не секрет, что это один из неотъемлемых этапов в процессе разработки и возникающие проблемы могут в конечном итоге сказаться на расходах компании и удовлетворении от работы в команде. Чтобы этого не было, необходимо вовремя понимать есть ли проблемы, определять причины, находить решения и проверять их эффективность. В части этих вопросов нам и может помочь статистика. Можно найти как отдельные приложения сфокусированные на метриках, так и гитхаб-экшны. В данной статье речь пойдет о гитхаб-экшне Pull Request Analytics Action.
Вклад авторов
nmivan 2664.0romas1982 1226.0semen_grinshtein 917.2kesn 624.0fillpackart 604.0m1rko 595.2alizar 583.2ru_vds 573.2olegbunin 482.0uyga 471.0