Сегодня мы рассмотрим методы формализации требований: Use Case и User Story. В статье рассмотрим оба метода, сравним их преимущества и недостатки. А также рассмотрим, когда и при каких ситуациях использовать каждый из методов.
Мир быстро меняется. И поиск инновационных решений для решения сложных проблем имеет решающее значение. Традиционные методы часто оказываются неэффективными. Особенно, когда речь идет о работе с OKR, где компании ставят себе амбициозные цели результаты.
Чтобы устранить этот пробел, лучше использовать системный подход, к примеру, ТРИЗ - теория решения изобретательских задач - для выработки более эффективных и инновационных ответов на вызовы.
Что такое ТРИЗ?
Про ТРИЗ можно рассказывать много. Но если коротко, то ТРИЗ - теория решения изобретательских задач, была разработана советским изобретателем и писателем-фантастом Генрихом Альтшуллером. Это инструмент решения проблем, анализа и прогнозирования, созданный на основе изучения закономерностей изобретательства. Основная цель ТРИЗ - создание алгоритмического подхода к изобретению новых и совершенствованию существующих систем. Он помогает выявить и разрешить противоречия и использует набор из 40 изобретательских принципов для поиска инновационных решений.
Давайте разберем, в чем преимущество метода ТРИЗ в достижении OKR.
Преимущество 1. Выявление реальной проблемы
ТРИЗ использует концепцию «идеального результата», чтобы сосредоточиться на том, чего команда действительно хочет достичь.
«Идеальный результат» в ТРИЗ означает наилучший возможный исход, когда проблема полностью решена с минимальными затратами или сложностью, часто описывается как достижение желаемой функции без каких-либо негативных побочных эффектов или компромиссов.
Определяя идеальное конечное состояние, команды могут выявлять и устранять коренные причины проблем, а не только их симптомы. Например, если команда стремится повысить удовлетворенность клиентов, ТРИЗ поможет определить, в чем заключается реальная проблема - в качестве продукции или в процессах обслуживания клиентов.
А в чем твой вклад как руководителя? ©
Как-то раз на перфоманс ревью был ошарашен отзывом одной из сотрудниц, назовём её Катя: не вижу вклад тимлида в работу команды.
На всякий случай, перфоманс ревью — процесс регулярной оценки сотрудников во многих компаниях, где учитывается мнение руководителя, коллег и подчинённых, если они есть.
Для меня это было неожиданно и очень больно — я-то был доволен собой. Команда за полгода стала работать гораздо лучше, это было видно по результатам квартала и метрикам перфоманса. Похоже, не всем видно.
В последнее время много обсуждаются разные новомодные методики управления проектами, Agile-методики, методики разработки продукта… Или не «методики», а «методологии»?.. Или «методы»?.. Как правильнее-то?
Вроде интуитивно разница чувствуется. И даже чувствуется, что в 90% случаев (в контексте управления проектами), эти термины полностью взаимозаменяемы. Но иногда, нет-нет, но все-таки вспоминаются слова из песни: «непонятно, что конкретно ты имела в виду»*…
Надо бы разобраться…
Scrum, один из наиболее популярных фреймворков для управления проектами, часто вызывает множество вопросов и разногласий по поводу своего применения. В процессе своей работы я неоднократно сталкивался с тем, что разные люди по-разному понимают и интерпретируют Scrum. Это побудило меня создать статью, которая поможет быстрее разобраться в его основах и особенностях.
В данной статье я постарался изложить основные принципы Scrum, опираясь на Scrum Guide, и дополнить их своими личными наблюдениями и опытом. Я включил множество иллюстраций и примеров из практики, чтобы сделать материал более понятным и полезным. Надеюсь, что эта статья станет ценным ресурсом для тех, кто хочет глубже понять и эффективно использовать Scrum в своей работе.
Мы привыкли жаловаться на бесконечные встречи и чаты, на то что не хватает времени на главное, всё занято текучкой. И даже воспринимаем это как данность, как необходимое зло, издержки профессии. Так ли это? Посмотрим, сколько рефально стоит коммуникация. Команде в целом, и руководителям лично. С помощью каких инструментов сократить эти расходы и какой выигрыш можно получить.
Друзья, привет!
Меня зовут Егор Пахомов, последние 3 года я работаю в Альфе: развиваю цифровые продукты в web- и mobile-каналах, управляю несколькими командами разработки. Ещё несколько команд собрал, организовал и бережно передал коллегам. Одновременно у меня в управлении было до 40 сотрудников: аналитиков, разработчиков, тестировщиков, дизайнеров.
Сегодня расскажу, что нужно, чтобы построить сильную продуктовую команду. После прочтения статьи вы будете чуть лучше понимать:
— На что обращать внимание на собеседовании и какие вопросы задавать кандидатам.
— С какими сложностями можно столкнуться при формировании команды.
— Как инженеры будут создавать продукт, а не просто выполнять таски.
— Как сформировать по‑настоящему сплочённый коллектив.
Будет полезно настоящим и будущим тимлидам, продактам, вникающие в Agile, тем, кто нанимает и собеседует или ищет работу в продукте и хочет понимать, на что смотреть в вакансии.
Теперь мы оцениваем баги через тг-бота, не тратим 2 ч. времени на встречи, фиксим самые критичные, но не теряем и минорные.
Современное развитие в области встроенной разработки и электроники с учётом бизнес-процессов ускоряется, часто следуя принципам Agile и Scrum. Применение этих методик требует осторожности из-за длительного производственного цикла встроенной разработки, который затрудняет быстрые изменения.
Меня зовут Арсентий Гусев, я руководитель группы embedded-разработки в отделе робототехники Яндекс Маркета. И мне бы хотелось рассказать об опыте, который приобрела наша команда в рамках работы над проектом складского робота. В этой статье определим критерии, предпосылки и предложим инструменты для ускорения разработки и снижения её стоимости.
Проблема в оценке требуемого времени на решение задач состоит в том, что часто оценки времени оказываются недостоверными и недооцененными. Это может привести к несоблюдению сроков выполнения задач, задержкам в проекте и дополнительным расходам. Причины этой проблемы могут быть разными:
Скрам - это новый ватерфол, который все полюбили, ведь любить нужно новое и модное, а старое и не модное принято презирать. Скрам это лекарство от всех болезней, однако оно не помогает, если его неправильно принимать. Скрам это благословение и проклятие в одном флаконе, дар небес, который мы не заслужили, и наказание за грехи, которые мы не совершали. Скрам проник в самое сердце нашей индустрии, и теперь медленно убивает ее изнутри. Возникает один вопрос.
Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть 1, Часть 2, Часть 3, Часть 4, Часть 5. Сегодня мы обсудим создание площадки обучения DevOps в стенах компании для обмена опытом между коллегами разных подразделений, повышения компетенции и культуры обучения.
Итак, проблема, которую мы будем решать — это смещение фокуса с развития на поддержку.
Иногда мне кажется, что шутки о том, что руководство внедряет Agile, чтобы успеть больше при меньших затратах, не так уж и далеки от истины. Я редко видел, чтобы команды разработчиков понимали Agile как что-то большее, чем просто набор церемоний, чаще всего ассоциируемых со Scrum.
Из моих наблюдений, все попытки оптимизации работы команды часто сводятся к изменению внутренних процессов внутри нее самой. При этом, важнейшие решения принимаются вне команды, оставаясь в водопадной модели. Это создает диссонанс: с одной стороны, руководство компаний стремится к гибкости, с другой — продолжает следовать жестким паттернам, ограничивая команду и не позволяя ей полностью раскрыть свой потенциал.
Привет! На связи Денис, RTE в компании «Автомакон».
Сегодня заметка короткая в связи с тем, что следующая часть будет довольно объемной. К тому же, не хочется заставлять вас ждать. Кроме того, сегодня как раз расскажу про обновленный шаг модели.
Может ли команда начинающих специалистов создать интересный и сложный продукт, который будет работать стабильно? Мой ответ - да, но есть нюансы.
В этой статье расскажу про путь моей команды: как мы создавались, как разработали уникальный продукт и как в итоге распались.
Экстремальное программирование (XP) — это одна из методологий Agile. Несмотря на название, некоторые практики уже стали стандартом в индустрии — например, рефакторинг и непрерывная интеграция. XP сосредоточена на упрощении процесса разработки, минимизации документации и максимизации обратной связи от заказчиков.
Я нашел свою систему «Личного планирования», о чем я поделился в этой статье и передаю этот опыт студентам курсов по менеджменту в Практикуме.
В этой статье расскажу:
— Зачем начинать планирование в начале дня,
— Почему нужно ограничивать количество задач и блокировать время для их выполнения,
— Какие приложения помогают отслеживать продуктивность,
— Зачем подводить итоги дня и анализировать свою эффективность.
Привет, Хабр. Меня зовут Марина Заботина, я аккаунт-директор в диджитал-агентстве Далее. Сегодня хочу поднять животрепещущую тему — зачем и как прокачивать технический бэкграунд проджект-менеджеру. В статье будут результаты опроса, который я провела среди разработчиков и ПМов, моя личная история прокачки. В финале отдаю глоссарий терминов для новичков.
Фокус-группы, исследования целевой аудитории, оценка конкурентов — всё это не дает гарантии того, что ваш продукт действительно нужен пользователям. Это прогнозы, которые могут не сбыться. Чтобы узнать наверняка, нужно создать и выпустить на рынок минимально жизнеспособный продукт. Привет, я Артём Трубин, CPO компании ActiveCloud. В этой статье расскажу, в чем разница между PoC, MVP и MLP и как, при запуске нового продукта, снизить риски с их помощью.
Эта статья -- про английский. Про английский в англоговорящих командах, где наряду с не-носителями языка работают самые настоящие нейтивы: американцы, британцы и т.д.
Начну с того, что попрошу вас представить кое-что. Нарисуйте себе картинку, где вы планируете искать работу в англоговорящей команде. Но ваш английский уж до того пропах нафталином, что, пожалуй, соваться на этот рынок стоит только после всеобъемлющего повторения базы. И я говорю не только о ставших притчей во языцех временах английского языка.
Вы находите буклетик, где очередная школа английского языка предлагает айтишнику "вспомнить всё" в одном из своих курсов. Вы внимательно изучаете программу курса (здесь, на пункте "произношение популярных айтишных слов", ваш речевой аппарат могут схватить судороги, а язык захочет вырваться наружу, шепелявя что-нибудь th-содержщее).
Но вот вы видите блок уроков, посвящённых идиомам. Идиомам. И-ди-о-мам. Кому они нужны, эти идиомы? Разве айтишники используют их в командном общении?
Вот тут вы должны удивлённо вскинуть брови, потому что, скажу я вам, идиомы так часто используются в командной работе, что, пожалуй, могут потягаться с фразовыми глаголами.
Давайте-ка вспомним что такое "идиома". А что такое идиома вообще? Идиома -- то набор слов, который имеет смысл в определенном языке, но не может быть дословно переведён без потери смысла на другой язык. Ну, например, в русском есть идиома "быть на седьмом небе". В английском языке тоже есть такая идиома, но звучать она будет по-другому -- to be on cloud nine.
Так уж случилось, что в интернациональных командах очень часто члены команды имеют классный английский (как нейтивы, так и не-нейтивы), а, значит, их речь наполнена всем: фразовыми глаголами, идиомами, сленгом и т.п.
