User
Возможно вы читали первую часть статьи про код ревью со стороны ревьювера (кстати, мы уже успели ее обсудить в последнем выпуске подкаста "Цинковый прод").
Так как статья набрала много лайков, пишу обещанное продолжение про код ревью с другой стороны — со стороны автора изменений кода
Как обычно, будем говорить MR (Merge Request) вместо CL, потому что термин CL мало кто понимает.
Оригинал инструкции для авторов MR по версии Google можно посмотреть здесь, а я дам краткую выжимку.
Итак, поехали
• Почему спортсмен сам идет к тренеру и рассказывает о том, что у него не получается, а в офисе часто наоборот?
• Как влиять на сотрудников?
• Как вести коллектив к цели за счет его собственной энергии?
В этой статье я постарался интересно и вдумчиво изложить свой опыт управления сотрудниками.
Привет! Я Юля, менеджер продукта в Тинькофф Кассе. Мы делаем интернет-эквайринг для бизнеса, и в разработке продукта участвуют 30 команд. При создании новой фичи какие-то команды могут действовать обособленно, но это редкость. В большинстве случаев командам при разработке нужна помощь друг друга. Расскажу, как у нас получилось сделать так, чтобы не было очередей из команд.
Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.
Обычное дело: в команду приходит заказчик, приносит суперзадачу — киллер-фичу, которая по приблизительным оценкам будет приносить не меньше N денег в секунду. Очень важная и нужная штука. Потом проходит 3 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала.
Почему?
– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;
– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;
– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;
– задача потерялась в недрах бэклога — продакт проглядел.
Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.
Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.
Привет, меня зовут Дима, я ведущий ИТ бизнес-партнёр в Петрович-Тех. Сегодня расскажу вам историю о том, как мы запускали продуктовый подход в инхаус-разработке.
В 2020 году задачи бизнеса сыпались в «общий котел», коллеги из бизнеса буквально бились за ИТ-ресурсы по принципу «чьё важнее». Команды разработки формировались по принципу «кто делал что-то похожее», оценки делались примерные, с умножением на «пи» или на «е».
Эта статья о том, как мы разбирали 1С УТ на продукты и сервисы, запускали “почти что Scrum-подход с элементами Kanban”, учились отвечать на вопросы “сколько ждать хотя бы примерно?” и “когда уже будет готово?” через метрики и перцентили – и как в конечном итоге благодаря продуктовому подходу нам удалось удвоить пропускную способность команд.
*args или **kwargs.
Привет, я Саша, продакт лид, отвечаю за развитие data-продуктов. Делать пользователей счастливее — моя работа. Но мне важно делать счастливее не только их, но и людей вокруг — коллег, с которыми мы создаем продукты.
Внедрением практик для мотивации команды я занимаюсь более 6 лет, сначала в n1.ru, а теперь в Lamoda Tech. Сегодня хочу поделиться самыми простыми из них. Это быстрые рецепты, которыми мы пользуемся, чтобы поддержать живую, драйвовую атмосферу внутри команды, даже когда все работают в разных концах земного шара и не хотят включать камеру на созвонах.
«Локус» и «Небьюла» вместе с «Хьюго» составляют тройку престижнейших фантастических литературных премий. При этом устроены они совершенно по-разному. За «Хьюго» голосуют участники фестиваля WorldCon. «Локус» вручается с 1971 года, а победителей выбирают читатели одноименного издания. А победители «Небьюлы» (впервые вручена в 1966 году) выбираются членами жюри. Любопытно, что в последние годы читатели «Локуса» и судьи «Небьюлы» проявляют удивительное единодушие. Четыре раза за последние пять обе премии имели общего лауреата.
Всем привет! Меня зовут Дмитрий, я более 7 лет занимаюсь трансформациями компаний и построением процессов в области создания продуктов и управления проектами с помощью Гибких подходов управления Agile. Недавно меня пригласили в один развивающийся американский стартап, который делает SAAS B2B продукт.
Оптимизация процессов, как много в этой фразе многозначности!
Как она по-разному понимается инженерами и менеджерами!
(Картина для привлечения внимания, создана в Kandinsky 2.2)
В статье ниже я разберу, что делать с этой самой оптимизацией процессов и рассмотрю несколько примеров. Переходите под кат :)
Все мы люди, даже те, что роботы. Поэтому тревожимся о том, как сделать больше и не выгореть, расстраиваемся, когда не всё удаётся, и стремимся быть эффективнее себя вчерашних. Расскажем, как роботы планируют задачи, какими инструментами пользуются и почему иногда стоит порезать слона на стейки.
Приветствую! Меня зовут Алексей Денискин, я тимлид мобильной команды СберМаркета. В этой статье я на примере покажу, как организовать CI для мобильных приложений на Android и iOS. Я буду использовать GitLab CI, но описанный подход применим к большинству стандартных стеков.
Привет, Хабр! Меня зовут Сабина Метляева. Я работаю в GlowByte менеджером проектов MLOps. Помимо управления проектами, занимаюсь созданием обучающих материалов, изучаю и внедряю инструменты по оптимизации своей работы и команды в целом, провожу обучение. Об одном из таких инструментов, который мы применили у себя на практике, хочу рассказать в этой статье. Речь пойдёт о матрице компетенций.
Эта статья покажет, как использовать графически-текстовые методы для структуризации процессов и разработки ПП, как при продуктовом подходе, так и при проектном.