Quick wins что это
quick win
быстрая победа
(ITIL Continual Service Improvemen
Деятельность по совершенствованию, возврат инвестиций от которой ожидается в кратчайшее время при относительно небольших затратах и усилиях.
См. тж. принцип Парето.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
quick win
(ITIL Continual Service Improvement)
An improvement activity that is expected to provide a return on investment in a short period of time with relatively small cost and effort.
See also Pareto principle.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
Тематики
Смотреть что такое «quick win» в других словарях:
Quick-Win — Unter dem Begriff schneller Erfolg (englisch quick win) versteht man, aus betriebswirtschaftlicher Sicht, eine Strategie mit dem Ziel zunächst jene Vorhaben zu realisieren, die schnell zu sichtbaren, verbesserten Ergebnissen führen. Die erzielten … Deutsch Wikipedia
Quick-win — Unter dem Begriff schneller Erfolg (englisch quick win) versteht man, aus betriebswirtschaftlicher Sicht, eine Strategie mit dem Ziel zunächst jene Vorhaben zu realisieren, die schnell zu sichtbaren, verbesserten Ergebnissen führen. Die erzielten … Deutsch Wikipedia
quick win — n. Everyone in business is always looking for quick wins, small steps or initiatives that will produce immediate, positive results … Business English jargon and slang
Win Elliot — Win Elliott (born Irwin Elliot Shalek; May 7, 1915 in Chelsea, Massachusetts September 17, 1998 [ [http://www.highbeam.com/doc/1P1 19525453.html Longtime Sportcaster Win Elliot Dies AP Online] ] in Norwalk, Connecticut) was a fight announcer… … Wikipedia
Quick-change — is a performance style in which a performer or magician changes quickly within seconds from one costume into another costume in front of the audience.Modern Quick Change ArtistsThere are few internationally acclaimed quick change artists, all of… … Wikipedia
quick on the trigger — or[trigger happy]
quick on the trigger — or[trigger happy]
quick on the draw — See: QUICK ON THE TRIGGER … Dictionary of American idioms
quick on the draw — See: QUICK ON THE TRIGGER … Dictionary of American idioms
Quick As a Flash — was a 30 minute radio quiz program which featured drama segments with guest actors from radio detective shows.Created by director Richard Lewis and emcee Ken Roberts, the program debuted over the Mutual network Sunday, July 16, 1944. Sponsored by … Wikipedia
quick trick — noun : honor trick * * * Bridge. a card, or group of cards, that will probably win the first or second trick in a suit, regardless of who plays it or at what declaration. [1925 30] * * * quick trick noun (bridge) A card that should win a trick in … Useful english dictionary
quick wins
Смотреть что такое «quick wins» в других словарях:
quick win — n. Everyone in business is always looking for quick wins, small steps or initiatives that will produce immediate, positive results … Business English jargon and slang
Quick Recall — is an academic competition comparable to Quiz Bowl. Quick Recall, featuring 2 halves of tossup and bonus questions, is used primarily for traditional academic competition in Kentucky. In Ohio, Quick Recall is different as it offers a round of… … Wikipedia
Quick Step — Infobox Cycling team teamname=Quick Step Innergetic code=QST base= BEL founded=2003 disbanded= manager=Patrick Lefevere teammanager= discipline=Road status=ProTour season=2003 2004 2005 2006 2007 2008 oldname=Quick Step Davitamon (QSD) Quick Step … Wikipedia
WINS (AM) — Infobox Radio station name = WINS city = New York City area = New York City area branding = 1010 WINS slogan = All news, all the time airdate = 1924 (as WGBS) frequency = 1010 kHz HD Radio 102.7 3 FM (HD Radio) format = Commercial, News power =… … Wikipedia
Smiley Quick — Lyman Loren Smiley Quick (March 19, 1909 ndash; December 23, 1979) was an American professional golfer who played on the PGA Tour in the 1940s and 1950s.Quick was born in Centralia, Illinoiscite web | title=Today in Golf History: March 19 |… … Wikipedia
Get-rich-quick scheme — Easy money redirects here. For other uses, see Easy Money (disambiguation). A get rich quick scheme is a plan to acquire high rates of return for a small investment. The term get rich quick has been used to describe shady investments since at… … Wikipedia
The Quick and the Dead (1995 film) — Infobox Film name = The Quick and the Dead caption = The Quick and the Dead Theatrical poster director = Sam Raimi producer = Joshua Donen Patrick Markey Allen Shapiro writer = Simon Moore starring = Sharon Stone Gene Hackman Russell Crowe… … Wikipedia
ITIL Planning to implement service management — The planning to implement service management is a set in the Information Technology Infrastructure Library (ITIL) framework. This set is about the alignment of business needs and IT provision requirements. Besides, this set describes how to… … Wikipedia
Due Diligence Process Management — (DDPM) ist ein Prozessmanagement Verfahren zur Prozessoptimierung und dient als Basis für umfassende Veränderungen in Unternehmen. Außerdem ermöglicht das Verfahren eine Unternehmensbewertung nach Aspekten des Prozessmanagements. Folgende… … Deutsch Wikipedia
Crime Syndicate of America — For the concept of crime syndicates in general, see Organized crime. Crime Syndicate of America The anti matter Crime Syndicate of Amerika (and counterparts) feature on the cover of the JLA: Earth 2 graphic novel. Art by Frank Quitely. Upside… … Wikipedia
Crime Syndicate — Infobox comics organization name=Crime Syndicate of America imagesize= caption= The antimatter Crime Syndicate of AmeriKa (and counterparts) feature on the JLA: Earth 2 cover. Art by Frank Quitely. publisher=DC Comics debut=Historical Syndicate:… … Wikipedia
Управление инновациями может стать ключевым источником дифференциации, но цифровые стратегии терпят неудачу скорее из-за малых амбиций, чем слишком больших.
Известные кейсы демонстрируют критическую необходимость бизнесу трансформировать свои модели. Kodak изобрела цифровую фотографию, а Blockbuster разработала платформу для Video on Demand раньше, чем Netflix. Но эти исторически успешные, лидирующие на рынке организации лишились своих позиций еще в первой волне цифровой трансформации, фокусируясь на стандартах прошлого.
Цифровизация бизнеса уже расширила охват аудитории и смежных рынков, улучшила процессы и повысила производительность, а также начала систематически использовать большие данные в процессах. Компании сосредоточились на создании контекста для внедрения цифровых технологий.
И если лидеры индустрий давно осознают новую реальность, строя и воплощая амбициозные планы, то большинство компаний все еще находится в Status Quo, опасаясь вступать в инновационную игру. На практике – это большая опасность и риск долгосрочного выживания.
Сегодня быть цифровым означает использовать данные для принятия более качественных и быстрых решений, принимать риск, делегировать принятие решений более мелким командам и разрабатывать гораздо более итеративные и быстрые способы решения задач, интегрируясь в смежные (и не очень) отрасли.
Digital mindset институционализирует межфункциональное сотрудничество, делает иерархичные структуры плоскими и создает среду для генерации новых идей, фокусируюсь на дополнительных KPI в узко сегментированных цифровых бизнес-моделях.
На практике цифровая трансформация бизнеса начинается с личной трансформации его лидеров. И на ранних стадиях важно правильно расставлять акценты.
Планирование на три года может обернуться неудачей, если изменения в технологиях и динамике рынка будут происходит быстрее. В быстроразвивающейся и непредсказуемой технологической отрасли вам понадобится более итеративный и гибкий подход к планированию, который уравновешивает стратегический планы сверху и понимание рынка и задач снизу.
Цифровая трансформация – это многоступенчатый процесс, эволюционно адаптируемый на основе опыта и уровня цифровой зрелости компании. Важно управлять приоритетными инициативами как портфелем. И в первую очередь развертывать те, которые имеют краткосрочное влияние.
Quick wins помогут профинансировать следующие шаги, высвободив капитал и ресурсы, необходимые для стратегически приоритетных задач. Такой подход позволит продемонстрировать прогресс стэйк холдерам и акционерам компании:
— продумайте, какие ресурсы и возможности можно разделить между бизнес-единицами, подразделениями или регионами;
— развивайте сотрудников, которые выходят за рамки своих ролей, действуя в соответствии с потребностями и темпом Digital рынков;
В эпоху цифровых технологий компании и люди должны быстро учиться и быстро реагировать на изменение рыночных условий:
— изучите бизнес-модели цифровой экономики и их влияние на конкурентные преимущества вашей компании;
— осознайте масштаб и поймите импульс, необходимый для Digital Disruption вашей компании;
— отформатируйте организационную структуру с фокусом на развитие людей, механизмы финансирования и Digital KPIs;
— дайте право на ошибку сотрудникам и развивайте сильную Agile-культуру.
Безусловно, это не исчерпывающий набор установок, но отправная точка, которая позволит компании сформулировать свой vision цифровой трансформации и начать двигаться с необходимой скоростью и в нужном направлении.
Quick Win. Тактика быстрых побед при внедрении ITSM
Внедрение практик ITSM – долгий, сложный, дорогостоящий процесс, который требует от организации перелопатить всю свою ИТ-структуру, чтобы из этого внедрения получилось что-то стоящее и всё окупилось. Но что делать, если компания не готова к резким изменениям или не хочет рисковать непрерывностью своих рабочих процессов? Внедрять ITSM малыми порциями, достигая при каждом новом шаге маленьких, но быстрых результатов. Поговорим о тактике Quick Win.
Немного об истоках ITSM – библиотеке ITIL
Когда встаёт вопрос внедрения или апгрейда процессов управления ИТ, организации обращаются к библиотеке ITIL. ITIL – это не методология, не стандарт, а набор практик управления ИТ-сервисами (ITSM), которые можно использовать в организации для повышения прозрачности процессов, экономии ресурсов и т. п. В библиотеку ITIL попадают только практики, которые сработали в конкретных организациях, доказали свою эффективность «в поле». Ключевой принцип ITIL – Аdopt and Аdapt (принять и адаптировать под себя).
От главного принципа ITIL и отталкивается стратегия внедрения ITSM Quick Win. Не нужно во что бы то ни стало навязывать своей компании новые процессы и нормативы строго в таком варианте и объёмах, как это описано в ITIL. Проявите гибкость и фантазию, масштабируйте предложенные решения под себя и вносите их маленькими порциями, шаг за шагом. Также в Quick Win важно отталкиваться от качества сервиса. Эффект от повышения качества услуг отразится на всех сторонах бизнеса.
Для примера возьмём процесс управления изменениями. Это эффективный, но громоздкий процесс. Он не заработает, если в организации не внедрены также процессы управления инцидентами и конфигурациями. А внедрять процесс управления изменениями в компании, у которой ещё нет нужного уровня зрелости, будет долго, дорого и неэффективно. Что тогда делать? Не внедрять всё разом, а двигаться малыми шагами, внедрять частично, то, что на данный момент по силам, – в итоге это постепенно будет давать небольшие улучшения, но не ударит по организации большими стрессами и издержками.
Три простых шага
Возьмём стандартную ситуацию для средних размеров компании, где ИТ-инфраструктура выстроена относительно хаотично. Какие-то процессы контроля ИТ построились сами независимо от ITIL. В какой-то момент руководитель узнал, что есть ITIL, и загорелся его внедрить.
1. Первое, что нужно сделать, – определить, где находится организация на позиции зрелости.
Организация в любом случае как-то взаимодействует с клиентами. Если у нее нет управления инцидентами, наверняка есть некое управление запросами клиентов, решениями аварийных ситуаций, сбоев и т. д. По сути, это стихийно сформировавшийся процесс, который так или иначе напоминает айтиловское управление инцидентами. То есть мы определяем начальную точку и точку, в которую хотим прийти. Но это не должна быть точка «мы хотим процессы ровно как в
ITIL». Должна быть сформулирована цель изменений, которые намерилась производить компания. Например, «мы хотим добиться того, чтобы разрешения сбоев, связанных с клиентским обслуживанием, производились быстрее и прозрачнее».
2. Дальше смотрим на то, что уже есть в организации, что предлагает ITSM.
Обнаруживаем процессы, похожие на то, что описано в ITIL, и разрабатываем план их усовершенствования с ориентацией на лучшие практики ITSM.
3. Начинаем внедрение ITSM с усовершенствования уже имеющихся практик.
Можно даже не переназывать сущности, дабы не плодить их и не ломать сложившееся восприятие. То есть «сбои» на «инциденты» менять не нужно. А вот внедрить новые этапы будет полезным. Например, не у всех в процессах управления инцидентами есть этап классификации. Если его внедрить, то админы больше не будут перекидывать между собой задачи, это сразу будут делать специалисты Service Desk. И это сразу даст профит – разгрузит ИТ-администраторов от непрофильной работы (присвоения инцидентам классов), и эти функции будут выполнять менее квалифицированные сотрудники, чьё время стоит дешевле.
Выбирая, какие процессы ITSM внедрить, ориентируйтесь не на потенциальные выгоды, а на актуальные возможности компании
Важно правильно выбрать, какой именно из процессов ITSM начать внедрять. Например, процесс управления проблемами – мощный и проактивный процесс. Но в проактивности кроется сложность внедрения. Ведь согласно этому процессу нужно мониторить всё, что у компании есть, чтобы предсказывать, где в следующий момент в её ИТ-процессах что-то отвалится и как можно это предотвратить. Процесс управления проблемами завязан на аналитике, которую поставляет огромное количество других процессов (управление мощностями, непрерывностью и доступностью). А эти процессы сами по себе тоже сложны для незрелой организации.
Если невозможно внедрить процесс частично, нужно внедрить другой, смежный. В данном примере это может быть процесс управления инцидентами – реактивный и понятный. Если у компании есть ресурсы для ретроспективного анализа, можно внедрить реактивное управление проблемами. Достаточно выделить человека, который будет анализировать причины, пытаться докопаться до них и решать проблемы.
Не надо заниматься лишней теплогенерацией. Если компания не доросла до процесса управления проблемами, его и не нужно внедрять только для того, чтобы «внедрить ITIL» или «внедрить ITSM-систему». Нужного эффекта это не даст. А вот внедрение управления качеством услуги или хотя бы управления услугами как таковыми принесёт быстрые плоды. Например, если ввести каталогизацию, большое количество повторяющихся услуг просто отпадёт, неструктурированный список из 2000 дублирующихся услуг трансформируется в каталог из 200 понятных и востребованных услуг. Времени на выполнение работ по такому изменению будет затрачено меньше, чем на внедрение управления проблемами, а выгоды будут получены быстрее. Всегда нужно выбирать то, что потребует меньше времени и усилий, но даст результат здесь и сейчас.
Это и есть Quick Win. Когда организация не пытается охватить сразу всё и воспроизвести внутри компании «Интернационал». Когда компания просто улучшает то, что уже есть: стоит улучшить одно направление, сразу появляется что улучшить в другом. Так по крупицам в компании появляются элементы лучших практик из ITIL. Основная фишка – делать минимальное количество телодвижений, получая максимальную пользу.
Фильтры восприятия фич из вашего Product Backlog
Если все фичи в процессе разработки продукта кажутся одинаково важными, то выбрать самую приоритетную из них порою очень сложно. Тогда на помощь менеджеру продукта могут прийти полезные фильтры для определения приоритетов.
Я хорошо представляю, как тяжело выбирать фичи для разработки, когда ваш product backlog просто ломится от “вкусных” фич. Но нам, менеджерам продуктов, приходится совершать этот выбор ежедневно. Потому что наша основная задача — дать пользователю value, как можно скорее и как можно больше. И мы не можем сидеть сложа руки. Наша задача — быстро принимать решения в условиях некоторой неопределенности.
Вопрос звучит просто: какая фича самая важная для нас сейчас? Но если они почти все важные? Этот вопрос слабо помогает нам в принятии решения.
Рассмотрим набор фильтров, которые помогут глубже понять степень важности или степень влияния фичи на ваш продукт. А это понимание поможет принять правильное в данный момент и в данном месте решение.
1. Стратегическая/тактическая
Фича соответствует нашей долговременной стратегии или нет. Например, для нас стратегическая фича — интеграция с Jira. Эта фича позволит нам уйти от прямой конкуренции с Jira и занять новую нишу — софт для менеджеров продуктов. Пример тактической функции — поддержка нового стандарта GDRP, который должен быть внедрен до 25 мая 2018 года, иначе мы рискуем попасть на большой штраф.
2. Влияет на метрику/не влияет (долги, баги)
Фича может улучшать какие-то конкретные показатели, например, увеличивать конверсию из регистраций в покупку подписки. А может, вообще не влиять в случае с фиксом багов или с переходом на новую библиотеку по обработке фотографий.
3. Улучшает UX/портит UX
Фича может улучшать UX и делать жизнь пользователя в вашем продукте лучше, а может, наоборот, усложнять его жизнь, но при этом повышать доход.
4. Нужна многим клиентам/нужна единицам
Сравните: фича, которая касается onboarding и которую увидят и прочувствуют абсолютно все новые пользователи, и фича, которая понадобится пользователям только на 7 день после регистрации. Например, экспорт в PDF time tracking отчета.
5. Нужна часто клиентам/нужна редко
Фича shortcuts или hot keys нужна часто тем пользователям, которые активно пользуются Hygger, в отличие от фичи «Смена типа доски с Канбан на Спринт», которая нужна только один раз, когда клиент импортирует свои данные в Hygger из Jira или Trello.
6. Время и стоимость разработки: высокие/низкие
Тут все просто: нужно оценить трудозатраты на разработку фичи. Если есть функции с маленькими затратами, но с большим value, то их надо делать первыми. Мы их еще называем Quick Wins. Но нельзя забывать и про большие функции с большим value. Их желательно разбивать на более мелкие куски и делать постепенно. Ибо они могут дать хороший value вашему продукту.
7. Время и стоимость внедрения: высокие/низкие
Себестоимость фичи складывается не только из времени разработки. Для фичи надо написать документацию, снять и смонтировать видео, сделать рассылку, настроить ивенты в аналитике, сделать Dashboard в BI туле, провести вебинар и так далее.
8. Требует vip клиент/требует не платящий клиент
Если фичу просит vip клиент, логотип которого вы гордо показываете всем посетителям на лендинге, то не спешите говорить «нет».
9. Ожидаемая/нет
Если в вашем продукте не будет ожидаемой по модели Кано функции, то пользователь просто уйдет. Например, если бы в Hygger не было комментариев у задач, вряд ли бы у нас были пользователи.
10. Желаемая/нет
Пример желаемой по Кано функции — объем доступной памяти на Dropbox. Чем больше памяти доступно пользователю, тем выше его удовлетворенность. Как правило, это линейные свойства продукта, то есть, чем этого больше, тем лучше. Другие примеры:
11. Восхищающая/нет
Если ваша фича является восхищающей по Кано, то она станет «пасхалкой» для пользователя. То есть, это всегда что-то неожиданное, то, чего пользователь совсем не ожидает от вашего продукта. Например, в случае с Hygger, это может быть 2-х уровневое комментирование задач или возможность с помощью тачпада перемещаться по доске в разных направлениях.
Если этой функции не будет в вашем продукте, ну и ладно — пользователи даже не заметят этого. Но, с другой стороны, пользователи могут быть настолько впечатлены функцией, что поделятся своим открытием с другими.
12. Есть у конкурентов/инновация
Если фича есть у конкурентов, это значит только то, что она есть у конкурентов. А вдруг ей никто не пользуется, и конкурент собирается ее скоро «выпилить»? Но иногда фича у конкурентов становится ожидаемой по Кано, и нам приходится ее повторять у себя. А лучше делать новые и классные фичи первыми!
13. Идея проработана/не проработана
Вы готовы отдавать фичу в разработку? Не спешите, убедитесь, что она детально изучена и описана так, что ее четко и ясно поймут ваши программисты и тестировщики. Степень детализации выбирать вам — вы как product manager лучше знаете ваших людей. Если понимаете друг друга с полуслова — отлично, можно не писать «Войну и мир». Работаете с банковским продуктом, у вас в команде есть свои бизнес-аналитики — прекрасно, пусть они моделируют фичу в UML хоть во всех 7 диаграммах.
14. Уверенность в том, что выстрелит: высокая/низкая
Оцените в процентах вероятность того, что фича действительно оправдает возложенные на нее ожидания.
15. Измерима/нет
Идеально, если все фичи измеримые. Это дает нам возможность численно оценить их вклад в успех продукта.
16. Проблема выявлена на UX
Если проблема выявлена на юзабилити-тестировании (UX-тестировании), то это придает нам уверенности в том, что мы решаем реальные проблемы пользователей, а не «галлюцинируем», как в случае с гипотезами, которые мы сами формулируем.
Конечно, наблюдение проблемы у 5 человек — это одно, а гипотеза на основе анализа поведения 1000000 пользователей — это другое. Тогда и не стоит это сравнивать, а надо формулировать гипотезы и проверять их asap.
17. Технический долг
Команда со временем накапливает технические долги, которые надо отдавать. Это может быть временный, не очень красивый код, который решает задачу, но топорно. Это может быть заглушка для функции, которая может быть вызвана в очень исключительной ситуации.
Если такие долги не отдавать, то со временем могут «накапать» очень большие проценты и на рефакторинг кода может уйти намного больше времени, чем эти долги позволили выиграть на старте.
Lean Prioritization или как мы приоритезируем в Hygger
Далеко не факт, что в вашем продукте будут нужны все эти фильтры. Как правило, менеджер продукта выбирает 3-7 критериев и использует их для скоринга фич. В результате, каждая фича получает числовое значение, и их уже можно сравнивать в одной плоскости.
Мы в Hygger.io используем метод Lean Prioritization. Он легковесен и эффективен, поэтому мы им пользуемся практически каждый день.
Это метод, представляющий собой 2×2 матрицу, которая помогает в принятии решений и определяет, что важно, что рискованно, и куда направлять свои усилия. Матрица активно применяется и для определения приоритетов в разработке продуктов.
Если не поддерживать бэклог постоянно, он быстро может стать свалкой для десятков, сотен и даже тысяч фич и багов.
Используя Lean Prioritization для работы с матрицей можно просто нарисовать большой знак плюс «+» на доске и задать значения «Value» и «Efforts» вдоль вертикальной и горизонтальной осей. Однако, многие согласятся, — эффективнее и удобнее будет использовать специальный онлайн инструмент, особенно, если у вас распределенная команда.
В Hygger это Backlog Priority Chart, где, помимо параметров Value и Efforts, предлагаются 4 сегмента: Big Bets, Quick Wins, Time Sinks и Maybes, каждый из которых представляет собой степень приоритетности:
Наверняка, список способов для определения приоритетности продуктовых фич может быть расширен. А по каким критериям вы оцениваете фичи? Возможно, у вас есть решение, которое может помочь другим?