Некоторое время назад я обнаружила интересный и полезный метод для простого и эффективного разделения пользовательских историй на более легковесные. Agile-тренер и соучредитель Scrum Alliance Mike Cohn отметил, что "почти каждая история может быть разделена с помощью одной из пяти техник". Он обобщает эти пять техник под аббревиатурой "SPIDR".
Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки, сколько заявок приходит от какого филиала, сколько распределяется на какого специалиста поддержки, что чаще всего ломается и требует внимания. Понять объективно, а не в ощущениях. И понимать регулярно.
Нет, я не помешан на метриках и отчётах. Знаю много случаев, когда управленческие решения принимаются вовсе без данных, и оно срабатывает. Что уж там говорить, с 2009 года, когда появилась компания, мы в нашей компании принимаем сотни решений каждый год, и только часть из них основана на каких-либо измеримых показателях.
С другой стороны, всегда, когда речь идёт про часто повторяющийся процесс, опирающийся на труд персонала, я агитирую за наличие разумного набора метрик. Так можно убрать разрыв между «я думаю» и «на самом деле», так можно увидеть где теряются деньги и другие ресурсы, так можно проще запустить процесс и сделать его лучше. Вот почему в первых же консалтинговых проектах в 2005-м мы с клиентами проектировали для каждого процесса метрики его эффективности, производительности и прочего. Вот почему сейчас для каждой новой команды разработки ПО вопрос измерения я с клиентами начинаю обсуждать как только речь заходит об организации работы. Без фанатизма, а как один из инструментов наладки.
Кроме метрик, вторая моя любимая тема — поток создания ценности. Этой идеей я увлёкся намного позже, когда до меня, наконец-то, дошло, как можно построить работающий (а не декларируемый) поток в интеллектуальной работе по разработке программного обеспечения. Спасибо ребятам из IT Revolution, они (в числе прочих) помогли мне сложить для себя новую, понятную, непротиворечивую и весьма прикладную картину мира. Многое встало на свои места. Несколько десятков команд мы помогли организовать по принципам потока создания ценности и я вижу, насколько мощный это инструмент.
«Процесс разработки больших программных систем чрезвычайно сложен и непредсказуем. Программные проекты часто прерываются, выходят за рамки сроков и бюджета или приводят к некачественным результатам, отделяя технологию программирования от установившихся инженерных дисциплин».
Впервые прочитав эту цитату Кони Бюрера, который работал в Rational Software, я полагал, что корень всех проблем, возникающих при разработке ПО, кроется именно здесь. С тех пор я повзрослел, оброс шлейфом скепсиса и перестал писать код для продакшена. Я больше не несу ответственности за разработку, тестирование или поставку отдельных классов, компонентов и даже сервисов. Я отвечаю за максимально быструю и качественную поставку бизнес-ценности в рамках одного из ключевых бизнесов ЦФТ - сервиса денежных переводов Золотая корона.
Менеджеры обладают всеми возможностями, чтобы заставить команду страдать
Как менеджеры, мы находимся в наилучшем положении, чтобы погрузить в уныние наши команды. Если вы менеджер, стремящийся действительно максимально причинить боль своим людям, обратите внимание! Мы рассмотрим три самых популярных способа.
Правда, мы сфокусируемся только на антипаттернах управления проектами, при том, что есть много других возможностей сделать людей в вашей команде несчастными.
Три секретных антипаттерна
1. «Белка в колесе»
2. «Миллион Agile-встреч»
3. «Гантаголик»
И сразу ссылка:
С вами так бывало? Послушаешь новый альбом и так зацепит, что обязательно нужно со всеми поделиться. Примерно это случилось со мной и книжкой «Shape Up». У меня за плечами десяток лет работы продуктовым дизайнером, и я не раз видел, как проекты проваливаются, поскольку никто так и не смог точно понять, что нужно сделать.
Я также видел, как чёткое понимание цели и жёсткие решения на пути к ней позволяли команде добиться результатов. Хочу, чтобы этого добилось как можно больше людей. Мой посильный вклад — этот перевод.
Приятного чтения и успешных проектов!
Привет, Хабр! Меня зовут Артём Кротов, я работаю руководителем направления развития гибких практик в команде Мир Plat.Form. В статье хочу рассказать, на какое обучение и сертификацию стоит обратить внимание разработчикам и вообще ИТ-специалистам, которые уже понимают, как они хотели бы развиваться по треку hard skills, но в теме soft skills не разбирались.
Если про Scrum и Kanban вы слышали только в контексте типов досок в Jira, а под CI понимаете Bamboo, Jenkins или Gitlab, то моя статья будет для вас полезной. Итак, погнали!
Всем привет! Меня зовут Владимир Тутынин, я методолог продуктового подхода и сегодня расскажу о своем методе планирования. Вы увидите, какие шаги я выполняю и какими инструментами пользуюсь для достижения результата.
Нам понадобятся две программы:
1. Evernote – это система заметок, которые хранятся в блокнотах и помечаются метками. Очень похожа на Confluence.
2. Trello – это доска задач с определенными правилами, на которой мы отображаем движение задачи по этапам.
Представим, что наше движение к достижению цели – это движение ракеты. Сначала мы находимся на высоте 0 метров, далее 10 000м, через минуту 20 000м, далее 30 000м и 40 000м. Эти отметки мы будем использовать как ориентиры и начнем наш маршрут в «космос».
Формирование меток
Заходим в Evernote и создаем 4 метки так, как показано на рисунке. Этими метками мы будем ориентироваться в пространстве заметок. В скобках после названия метки показано количество заметок, имеющих такую метку. Например, у меня есть 36 заметок с меткой «20.000м Цели».
Расскажу о календарях YouGile, Битрикс-24, Weeek, ClickUp, Wrike, Asana, Trello. Давно анализирую системы управления проектами, делаю обзоры, сравниваю функции, подкидываю идеи по продукту разработчикам. Протестировала более 50 систем.
Все календари проектов похожи. Задачи попадают туда с досок или из списков и to-do-листов, если проставлены даты. Есть цветная маркировка и фильтрация. Можно добавить задачу, изменить сроки перетаскиванием, завершить.
Системы расположила по порядку: от тех, что точно останутся доступны в России – до работающих с ограничениями. В конце – сравнительная таблица.
История методик управления проектами
С древнейших времен люди поняли, что для достижения какой-то поставленной цели или задачи гораздо выгоднее, быстрее и эффективнее объединиться. Мамонта в одиночку не завалить, в пещере одному небезопасно и даже урожай одному не собрать. Вместе как минимум - веселее.
С точки зрения структуры и подготовки организации к цифровой трансформации есть два основных подхода: оптимизация и реинжиниринг бизнес-процессов. В этом посте я хочу подробно остановиться именно на эволюционном реинжиниринге: способе, при котором предприятия не меняют свою продуктовую линейку в отличие от реинжиниринга революционного.
Ярким и показательным примером подхода на базе революционного реинжиниринга можно считать переориентацию китайских заводов, которые с машиностроения смогли переключиться на производство масок в начале пандемии, удовлетворив образовавшийся острый дефицит.
Оптимизация же производства нацелена в большей степени на изменение текущих процессов, когда компания сохраняет базу, определяет конкретные методики работы, выделяет неэффективные аспекты в своей работе.
Меня зовут Дмитрий Сыцко, я расскажу про реинжиниринг на примере Московского кредитного банка (МКБ).
Сегодня мы находимся на третьей волне Agile, которая характеризуется стремлением бизнеса быстро и оптимально адаптироваться к динамичным внешним условиям с использованием гибких подходов и практик. Базовый механизм, гарантирующий создание свойства адаптации, заключается в переосмыслении жесткой иерархической структуры управления в сторону подвижной, ориентированной по направлению доставляемой ценности конечному потребителю.
В данной статье будет сделана попытка ретроспективно описать эмпирический опыт поиска волн для компании, находящейся в данный момент вне гребня.
«Не жизнь, а сказка, – сказал мне мой дедушка, наблюдая за моей удаленной работой, – разве могли мы мечтать о такой работе, трудясь от звонка до звонка на своих заводах?»
Действительно, кому-то удаленный формат работы, который предоставила нам пандемия, может показаться сказкой – но по факту 2021 стал временем больших перемен и массовых увольнений.
Наукоемкое производство в наши дни нельзя представить без применения самых новейших методов управления и бизнес-инжиниринга. Если еще каких-то лет 15 назад наукоемкое производство в России почти отсутствовало, то сейчас в этой сфере наблюдаются подвижки, а значит растёт потребность в применении методов его управления и анализа.
А чем оценивается эффективность бизнес-процессов? Правильно, общей ценностью для предприятия, а также конкурентоспособности используемой технологии. Именно от этого зависит достижение всех показателей, важных для удовлетворения целей бизнеса.
В посте я расскажу про методы повышения качества, которые сейчас получили особую популярность — построенные на основе методологий Lean Six Sigma, а также обсудим гибкие методики на основе подходов Agile и гибридных подходов PRINCE2. Разберу плюсы каждого из подхода и разберу необходимые шаги и условия для их внедрения.
Всё это в разрезе создания ПО (также подойдет и для производства радиокомпонентов).
* В статье пойдет речь о кейсе трансформации компании, чье название в этой статье нельзя упоминать. Но чтобы вы все-таки чуть лучше понимали контекст, далее в тексте я буду использовать термины "Красно-белый оператор" (КБО) и его банк (КБО Банк)
Для начала, думаю, будет нелишним начать с предыстории и предпосылках начала трансформации КБО.
Итак, в начале 2019г. КБО принимает стратегию трансформации компании в продуктовую экосистему. Что это и зачем?
Технический долг — головная боль многих разработчиков. Это та ситуация, когда ты видишь, что можно сделать лучше, но не делаешь этого из-за высокой нагрузки, малого количества времени и ещё по тысяче причин. В итоге долг накапливается, накапливается, накапливается... А потом что-то происходит.
Как сделать так, чтобы иметь возможность разгребать технический долг, поговорим в этой статье.
«Всё, договорились, скрам-мастером теперь будет Полина», — отлично, кто-то договорился о том, что я буду скрам-мастером. Отрицание, гнев, торг, депрессия, принятие.
Привет, меня зовут Полина, и я — системный аналитик. Некоторые компании нанимают отдельных обученных скрам-мастеров для более эффективного ведения и мониторинга процессов внутри команд разработки. Но на такой путь готовы не все. Более распространен подход, где скрам-мастер выбирается непосредственно среди участников команды разработки, и сотрудник совмещает свои прямые обязанности и скрам-мáстерство. В этой статье я не буду рассматривать плюсы и минусы каждого из подходов, но расскажу о том, а что же, собственно, делать, если скрам-мастерство пришло к тебе, а ты не был к этому морально готов.
Всем привет. Меня зовут Рома, я-разработчик. За короткое время, в одной команде, на одном проекте, я поработал в трёх разных вариациях скрама. Ощущались они по-разному, и каждый новый вариант нравился мне меньше предыдущего. В этой статье я поделюсь своим опытом и выводами.
Представьте ситуацию: вы приходите в новую компанию, погружаетесь в проект, но с первого же дня не успеваете в сроки. Вы собираетесь с мыслями: формализуете бэклог, выделяете MVP, но все равно не успеваете даже с минимальным жизнеспособным продуктом. Через пару спринтов получаете среднюю скорость команды, делите сумму оценок задач бэклога на скорость и высчитываете реалистичную дату реализации проекта. Готовите внушительное обоснование руководству, «посыпаете голову пеплом» и согласуете новый срок его сдачи. Продолжаете работать, но всё равно не успеваете. Очевидно, что-то идет не так, отсюда зреет вопрос «доколе?»
Меня зовут Алексей, я IT product manager, занимаюсь развитием внутренних систем в ВТБ Лизинг. В ситуации выше смешались проекты, продукты и agile, но так даже интереснее и жизненнее. В этой статье я расскажу, как мы выходили из подобной ситуации.
Данная статья поможет разобраться в том, что из себя представляет позиция Engineering Manager, причём тут Tech Lead и как с этим жить?
