7 апреля в 17:00 мск пройдет Junior Analyst Meetup. Это бесплатный онлайн-митап, который подготовили сотрудники NAUMEN.
Встреча будет интересна тем, кто ищет себя в айти / тем, кто определился с направлением «аналитика» и хочет прокачать свои скиллы.
О докладах и дополнительных бонусах читайте ниже.
Привет, Хабр! Меня зовут Виталий, и за 9-летний опыт работы PM и 2-летний Agile coach в энтерпрайзе я часто сталкивался с ситуациями, как продуктовые планы влияли на ИТ-команды. Некоторые из таких ситуаций были безобидными, другие могли угробить всю компанию.
Подробнее рассмотрим три ключевые ситуации и их последствия:
1. несвоевременное предоставление планов;
2. задачи с фиксированным сроком;
3. отсутствие планов или плохо проработанные задачи.
Если хотите об этом поразмыслить, добро пожаловать под кат.
Хотя эта статья не является пошаговым учебным инструктажем, все же многим будет полезна. В ней мы, команда Внедренческого центра «Раздолье», поделимся опытом внедрений и расскажем о решениях, которые принимаем на проектах, связанных с межцеховым планированием.
Тема эффективного межцехового планирования актуальна для многих, и чтобы помочь с ней разобраться, расскажем о проверенных нами приемах и решениях на примере внедрения «1С:ERP» на конкретном производственном предприятии.
Кратко обобщим характеристику одного из типов предприятий, с которыми мы постоянно работаем. Как правило, это предприятие из отрасли машиностроения или приборостроения, которое занимается выпуском сложных изделий под заказ. Часто на таком предприятии работают и с коммерческими заказами, и с гособоронзаказами. Цикл производства изделий составляет несколько месяцев (в данном примере - около девяти). Как и у многих, производство разделено на заготовительное и сборочное.
Меня зовут Павел Кондратьев, я руководитель проектов в ГК Юзтех. Управляю разработкой мобильных и веб-приложений. В статье, которую я сделал с платформой по управлению проектами WEEEK, хочу ответить на вопросы о том, как часто результат зависит от работы других команд, как синхронизировать разработку, грамотно управлять поставкой и ожиданиями в условиях постоянно изменяющихся требований. Также расскажу, как учесть риски проектов и что с ними делать.
Впервые статья была опубликована на vc.ru, в связи с актуальностью дублирую материал на Habr.
Кого из этих зверей выбрать символом поздравительных открыток? Или, чтобы придать солидности: Какой из этих двух логотипов принесет успех транснациональной корпорации с оборотом 3 млрд. евро?
Всем привет! Меня зовут Наташа Бакалдина, и я QA Lead в HiFi‑стриминге Звук. В этой статье я хочу поделиться опытом и рассказать о проведенном в нашей команде эксперименте, в ходе которого одна из метрик статистики по багам внезапно помогла планировать спринты лучше.
Когда полтора года назад я пришла в компанию, то попала сразу на большой редизайн, затрагивающий все экраны и огромное количество логики. Как и любое крупное изменение, это привело к увеличению количества багов, нарастающими с появлением каждой новой фичи сверху.
Но, вот, наконец, редизайн был окончен. Все фичи выпущены, а количество багов не уменьшилось. Мы задумались, в чем же может быть причина? Некачественное тестирование? Непроработанные задачи? Может быть, обычная нехватка времени? Чтобы не тратиться на пустую рефлексию, было решено провести эксперимент, который должен был выявить узкие места, сделать процессы еще прозрачнее, поправить метрики и повлиять на планирование там, где это нужно.
Добрый день! Меня зовут Игорь. Уже 3 года Я делаю бесплатный сервис для создания ментальных карт MIND IN MAP 🍀. За это время, я создал сотни ментальных карт для работы и учебы. В этой статье я делюсь опытом. Покажу как создавать ментальные карты и расскажу, где это можно делать бесплатно.
Планирование — важная задача не только для тимлида или менеджера. Часто разработчику приходится отвечать на вопрос «когда это будет готово?».
В этой заметке я хотел бы разобрать подходы, которые эффективно использовать в ситуациях, когда что-то должно быть сделано кем-то к какому-то сроку. Например, выпуск релиза с фичей или передача готового функционала другой команде для интеграции. Или другая команда меняет структуру базы данных в соответствии со своими планами, и вам надо заранее к этому подготовиться. Или заканчивается поддержка старого интерфейса в совместно используемой библиотеке. То есть некие события в будущем, к которым нам надо что-то сделать на своей стороне. Но вообще, приёмы, которые я предлагаю в этой статье, подходят ко многим проектам, не только в разработке.
