Agile *

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

Меня зовут Илона Ноженко и так сложилось, что я любитель поработать в энтерпрайзах — тех самых неповоротливых или, как их порой величают, кровавых. У меня за плечами инхаус-работа в четырех крупных компаниях, сегодня я работаю в банке «Открытие». Что еще интересного могу рассказать о себе? Много вкладываюсь в развитие бизнеса и продактов, правда, для этого мне пришлось пройти путь запуска своих идей на рынок.

Как вообще я стала собирать истории про взаимоотношения агентов изменений и корпкультуры? Где-то в 2018 году знакомые и коллеги зачастили ко мне с вопросами типа «как, ты еще держишься?». Я немного напряглась — не от того, что вопрос сам по себе сложный, а от того, почему у людей вообще появляется такая мысль. Ведь тут явно сквозит какой-то не очень позитивный контекст и им явно от чего-то больно. Вот это «от чего-то» я и стала изучать.

Эта статья — не про то, как бороться с выгоранием от работы или как трансформировать культуру (это огромные темы для отдельных выступлений, хотя косвенно сегодня они будут затрагиваться). Мне хочется осветить тему с такой стороны: как мы, агенты изменений, можем провоцировать систему и корпкультуру на то, что они начинают давать сдачи и съедают нас с потрохами.

Если у вас средний или крупный бизнес, а ваш бюджет измеряется миллионами рублей, вы без труда найдёте удобную систему управления проектами. На рынке их более ста. Но если у вас малый бизнес, а бюджет ограничен (скажем, 5000 рублей в месяц – это потолок), вам остаётся выбирать из того, что есть.

Привет, Хабр! Я – Юля, руководитель небольшой компании по производству упаковочных материалов, и я “съела” собаку на доступных решениях по управлению малыми командами.

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

Большая подборка полезных telegram-каналов и чатов для product managers, project managers и product owners. Здесь ты найдешь как крупные популярные каналы с десятками тысяч подписчиков от знаменитых продактов, так и ламповые каналы на пару сотен человек без рекламы и смс.

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

Разработка ПО — довольно формализованная (в хорошем смысле),и активно развивающаяся отрасль, работающая с нематериальными результатами интеллектуальной деятельности. Есть лучшие практики больших компаний, есть опыт стартапов. И те и другие во многом стремятся использовать современные методологии разработки ПО, которые часто дорабатывают под себя. Ведь они обеспечивают собранность, систематизированность и прозрачность данных, помогают видеть процесс от А до Я, отслеживать эффективность и прочее, прочее, прочее.

Я не так давно пришёл в современное IT (около полугода назад), но за это небольшое время успел оценить, какую пользу приносят передовые практики управления разработкой, собственно, разработке. Я был приятно удивлен и слегка ошарашен. Настолько, что подумал — а почему бы не применить все это хозяйство к чему-то “не айтишному”? Скажем, к малому бизнесу, а именно - мелкому ритейлу товаров на маркетплейсах (МП)? 

Тут необходима ремарка. У меня давно была мечта: вне зависимости от места работы я хотел иметь свой маленький бизнес, который я буду параллельно выстраивать и развивать. Поэтому сейчас в отрыве от основной работы я продавец на одном из маркетплейсов.

Привет! Меня зовут Андрей, я продакт-менеджер команды Passenger в inDriver. В этой статье расскажу, как из маленькой якутской команды мы превратились в большой департамент, который работает из разных точек мира. И не просто превратились, а еще и научились эффективно работать и взаимодействовать друг с другом (по крайней мере, нам так кажется). Погнали!

Важное уточнение: все города я буду указывать с часовым поясом в скобках, чтобы вы понимали нашу распределенность :)

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

Этой статьёй я хочу ещё раз напомнить, как инструменты командного взаимодействия решают проблемы качественной разработки, что ответственность за качество лежит на всей команде и что agile-понятия «Прозрачность» и «Предсказуемость» часто теряются на фоне клепания тасок в Jira. Несмотря на свою очевидность, Agile-практики применяются не везде, где могли бы приносить пользу, либо применяются с ошибками и антипаттернами, противоречащими самой культуре Agile. Я расскажу, с какими сложностями столкнулся на разных этапах распространения этой культуры и что делал, чтобы их преодолеть.

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

Подобная статья должна была появиться раньше, лет десять или пятнадцать назад, когда Agile только начинал внедряться в ИТ-компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, , если бы менеджеры сразу подходили к вопросу правильно, не отвлекаясь на лишние действия …

Зато за это время накопился опыт "внедрений" Agile в разных условиях, в разных компаниях, который следует обобщить и повсеместно распространять.

Всем привет! Я Виталий Дощенко, ньюбиз-директор AGIMA. Обычно на Хабре мы рассказываем, как работаем над цифровыми продуктами. Над мобильными приложениями, высоконагруженными системами или чат-ботами. Но только не в этот раз. В этой статье я расскажу, как Канбан-метод помог нам устранить последствия пожара. Не того пожара, где куча задач и ты ничего не успеваешь, а самого настоящего пожара, который чуть не уничтожил дом моей семьи.

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

Впервые прочитав эту цитату Кони Бюрера, который работал в Rational Software, я полагал, что корень всех проблем, возникающих при разработке ПО, кроется именно здесь. С тех пор я повзрослел, оброс шлейфом скепсиса и перестал писать код для продакшена. Я больше не несу ответственности за разработку, тестирование или поставку отдельных классов, компонентов и даже сервисов. Я отвечаю за максимально быструю и качественную поставку бизнес-ценности в рамках одного из ключевых бизнесов ЦФТ - сервиса денежных переводов Золотая корона.

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

Нам понадобятся две программы:

1.      Evernote – это система заметок, которые хранятся в блокнотах и помечаются метками. Очень похожа на Confluence.

2.      Trello – это доска задач с определенными правилами, на которой мы отображаем движение задачи по этапам. 

Представим, что наше движение к достижению цели – это движение ракеты. Сначала мы находимся на высоте 0 метров, далее 10 000м, через минуту 20 000м, далее 30 000м и 40 000м. Эти отметки мы будем использовать как ориентиры и начнем наш маршрут в «космос». 

Формирование меток

Заходим в Evernote и создаем 4 метки так, как показано на рисунке. Этими метками мы будем ориентироваться в пространстве заметок. В скобках после названия метки показано количество заметок, имеющих такую метку. Например, у меня есть 36 заметок с меткой «20.000м Цели».

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

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

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

Меня зовут Дмитрий Сыцко, я расскажу про реинжиниринг на примере Московского кредитного банка (МКБ).

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

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

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

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

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

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

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

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

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

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

В октябре 2021 года меня пригласили провести стратегическую сессию для одной компании, которая занимается комплексным озеленением общественных и корпоративных пространств. Задачей мероприятия была презентация бизнес-целей на ближайшие несколько лет и синхронизация коллектива вокруг них. Всего в компании работает 120+ человек, на встрече присутствовал бек офис, 30 человек.

Генеральный директор компании – приверженец бирюзовых принципов и адепт самоорганизующихся систем. Моей задачей было донесение идеи, что каждый член команды – внутренний предприниматель со своими внутренними заказчиками, услугами и продуктами, из чего и сотканы процессы, а качество которых складывается в общее качество деятельности компании.

Начало декабря. Утро понедельника. В переговорной собралась команда для обсуждения планов на спринт.

Накидали несколько задач из бэклога. По требованиям — всё понятно, по срокам — всё адекватно, но в воздухе чувствуется какая-то недосказанность.

Владелец продукта кивнул, принимая тяжёлое, но важное для команды решение, и твёрдо произнёс: «Нам нужно поставить ёлку».

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

В мире на сегодня накопилось много неприятных вещей и тенденций, о которых почему-то стало неприлично негативно высказываться. Даже фраза появилась: «Вы не понимаете, это другое!»  Немалая часть явлений так или иначе связана с ИТ. В рамках проводимого мероприятия «Стань автором, получи футболку!» решил выложить на обсуждение некоторые моменты с комментариями, почему я считаю их вредными, а иногда и опасными.

Поехали.