Продакт менеджер
Расскажу, как мы оптимизировали обучение моделей, внедрив инструмент Kubeflow Pipelines в нашу практику. Я хочу показать, чем Kubeflow Pipelines может быть полезен ML-специалисту и как в нём без потери существующей кодовой базы можно запускать готовые пайплайны.
Наличие внушительного портфеля ПО в компании не равно умению эффективно им управлять. Развитие функции SAM (Software Asset Management) часто кажется слишком сложным процессом и не входит в число приоритетов бизнеса. Однако зрелый процесс управления программными активами поможет сэкономить компании немало денег и времени в долгосрочной перспективе.
В этой статье разберемся в том, зачем нужна оценка зрелости управления программными активами, какие уровни зрелости бывают и как пройти путь от полного хаоса в лицензиях и ПО до построения полноценного процесса, который поможет в достижении бизнес-целей.
Этот пост — обзор полезных в практике PM источников знаний, созданный на основе рекомендаций специалистов и руководителей ЕАЕ-Консалт. В материале постарались отразить не только специфическую литературу и документы для PM, но также книги из смежных отраслей знания, ценных, а иногда и необходимых в проектном управлении.
В начале своей карьеры в области IT большинство разработчиков выполняют простые, незначительные задач. Такой подход принят для того, чтобы ввести сотрудника в проект, а также постепенно наращивать технические и социальные навыки. Так, поэтапно, сотрудник из рядового стажера, выполняющего «мартышкин труд», вырастает до настоящего специалиста, который приносит пользу команде.
В то же время с ростом навыков увеличивается и сложность задач. Сначала они достаточно простые, в них из постановки ясно, что нужно сделать. Далее становится сложнее. Одного названия задачи недостаточно, чтобы понять, что требуется. На помощь обычно приходит более опытный член команды, который сможет объяснить, что к чему. В какой-то момент «бывший стажер» сам становится этим самым членом команды. Прорабатывать требования и решение задачи теперь необходимо самому. И тут начинают возникать вопросы. Я расскажу про свой опыт решения задач с таким подходом и как это отражалось на работе нашей команды.
Привет! Меня зовут Роман Бунин, я BI-евангелист Yandex DataLens. При росте объёма данных, что неизбежно для любой компании, загрузка дашбордов может замедляться до десятков секунд. И чем больше появляется данных, тем медленнее становятся дашборды, особенно если вы хотите строить их по детализированным таблицам.Связка базы данных ClickHouse и BI-системы Yandex DataLens — популярное решение для анализа данных: эти инструменты нативно интегрируются и быстро работают вместе. В этой статье вместе с моим коллегой, архитектором Yandex Cloud Игорем Путятиным, покажем, как на основе таблицы из 150 миллионов строк построить максимально быстрый дашборд, и расскажем о технических ограничениях.
Целью данной статьи является защита точки зрения того, что Системный аналитик с бизнес-навыками или наоборот Бизнес-аналитик с навыками системного анализа это то, что сейчас востребовано бизнесом, хотя открыто это и не прокламируется. Данное мнение базируется только на личном опыте.
Я решил поговорить об этой, казалось бы зажеванной теме по одной простой причине: у меня вызывает недоумение почему многие путаются в оценках. Поэтому я решил немного уменьшить эту путаницу и помочь коллегам использовать оценки по назначению.
Не откладываем рефакторинг в долгий ящик, чтобы сэкономить на поддержании продукта. Иначе – риск израсходовать горы бюджета, когда рефакторить будет слишком поздно.
Правильная оценка задач - один из важных аспектов, определяющих успех в работе над проектом.
Всем привет! Меня зовут Маргарита, я UI/UX дизайнер в компании Tourmaline Core. В этой статье решила поделиться своим опытом, набитыми шишками и успешными практиками, и разобраться, что нужно учесть при оценке времени выполнения задачи.
Статья будет полезна как начинающим дизайнерам, так и другим специалистам, сталкивающимся с горящими дедлайнами и проблемами в оценке задач.
«Да кто такой этот ваш аджайл?! Мы же не продуктовая команда!», «И как меня угораздило в это вляпаться?!» — такие выражения (и много чего еще) я слышала на командных встречах архитекторов компании в роли агента изменений.
Всем привет! Я – Мадина, скрам-мастер в Департаменте управления технологиями МТС, у нас это подразделение называют Департаментом Technology Governance (TechGov).
Одно дело — внедрять скрам или канбан в командах разработки и совсем другое — внедрять гибкие подходы в Центрах компетенций или практик. Таких, например, как архитектура, управление производственным процессом, R&D или даже сам Центр практик Agile.
Мой путь агента изменений был нелегок и тернист, я набила кучу шишек, случались и провалы. Но я извлекла из этой истории много уроков и, кажется, мы с командой смогли нащупать верную дорогу, используя здравый смысл, и начали ощущать пользу от внедряемых изменений. В этой статье я расскажу о том, как мы организовали работу команды архитекторов с помощью Agile, с какими трудностями столкнулись и что получили в итоге.
Цель данной статьи дать понимание для бизнеса какие зоны ответственности попадают в роль менеджера по продукту, как это пересекается между стандартным бизнес подходом и нужен ли бизнесу подход по управлению продуктом, а вмести с этим выделенная организационная функция.
Много всего говорится, да не всё в дело годится
Ранее я уже рассказывал про такой брак в потоке задач, как «НЕфункциональные задачи»[1].
Сейчас я хочу описать «псевдозадачи» - ещё один вид брака потока задач. Объяснить, что это такое? Разъяснить, как определить «псевдозадачи»? Ведь они имеют все необходимые обязательные атрибуты «задачи».
Целесообразность этого заключается в том, чтобы исключить Имитацию Бурной Деятельности – ИБД, разрастание формализма и бюрократизма.
Псевдозадача — это, по сути, задача ради задачи – самоцель.
Как правило, такие задачи:
Привет, Хабр! Меня зовут Дима, я руковожу отделом в Петрович-Тех. Мы делаем ИТ для строительного ритейла, моя команда занимается поддержкой. В статье хочу рассказать о том, как мы наводили порядок в работе с бэклогом для внутреннего продукта – что делать, когда постоянно много задач, приоритеты меняются, стейкхолдеры недовольны.
Когда речь заходит о продуктах внешних, для такого контекста есть немало полезных подходов и практик: всевозможные Scrum/Kanban, спринты, скоринг и приоритизация бэклога, кросс-функциональные команды из людей с T-shaped навыками и продуктовым образом мышления.
По сравнению с внешними, внутренние продукты зачастую “догоняют”. Для внешних – 2-недельные спринты и разные там CI/CD; для внутренних – непрерывный поток задач, задачи берутся в работу по мере поступления. Работа делается, но сложно давать прогнозы, когда что будет готово — в любой момент времени может прилететь непредсказуемое количество задач, которые поменяют все планы. Не хватает людей на развитие внутренних продуктов – “вот сначала разберёмся со срочными задачами бизнеса, тогда займёмся этим”.
В какой-то момент мы решили, что “хватит это терпеть” – попробовали радикально изменить работу с бэклогом внутренних продуктов. Стали приоритизировать задачи, активнее вовлекли стейкхолдеров в процесс планирования, отфильтровали неважные задачи, наладили процесс работы с багами и инцидентами.
В результате сейчас для каждой задачи из бэклога мы знаем, на кого она влияет, сколько таких людей, откуда задача взялась, какие там ключевые метрики и приоритеты относительно других задач. Очередь из просроченных задач практически сведена на нет.
Давайте расскажу, как мы к этому пришли.
Привет! С вами Миша Наер и Ваня Звягин — дизайнеры нефинансового вовлечения.
Понимание задачи — это документ, который помогает составить и зафиксировать единое представление о задаче у дизайнеров и стейкхолдеров.
С одной стороны, написанное кажется очевидным. Прежде чем начать, нужно понять, чего ждет заказчик. Но иногда этот этап хочется пропустить, потому что дизайнеру кажется: вроде и так все понятно. Иногда такой артефакт, как понимание задачи, есть, но содержит саму задачу, пересказанную другими словами, а не цель этой задачи.
В статье расскажем, как написать полезное понимание задачи, на примере боевых задач из мобильного банка Тинькофф.
Привет! Меня зовут Артем Коньков, я frontend-разработчик в СберМаркете. А еще, я тот человек, который в фильмах ужасов спускается в темный подвал вопреки инстинкту самосохранения. Во-первых, потому что это интересно, а во-вторых — кто-то же должен это делать!
Это история о том, как мое любопытство превратило небольшую задачу в настоящий квест длиной в 5 спринтов. Надеюсь, мой пример поможет вам меньше бояться подобных задач, и даст мотивацию копать глубже. А в конце статьи я расскажу, как правильно закреплять результаты, чтобы такая масштабная работа не была проделана впустую. Но сначала немножко контекста.
Я сейчас занимаюсь тем, что помогаю акаунту в несколько десятков разработчиков зарелизить проект качественно и в срок. Среди прочего у проекта есть проблема с разбиением задач на тикеты в JIRA. Просто для понимания масштаба – проекту год, разработчиков грубо говоря три дюжины, номер последнего тикета 12000+. При этом много тикетов с тегов investigate, много тикетов в результате которых создается pull request на 20 строк при том, что для достижения результата который «можно пощупать руками» (tangible) нужно 100 строк и остальные 80 строк размазаны по другим спринтам и другим командам. Это ведет к следующим проблемам