Ожидаемые результаты
Ожидаемые результаты – это конкретные результаты, которые предполагается достичь в ходе реализации проекта в количественном и качественном выражении. К описанию ожидаемых результатов необходимо подходить очень серьёзно и ответственно, поскольку они являются критериями эффективности проекта.
Основные характеристики результатов:
— соответствие результатов цели и задачам проекта;
— измеримость (это касается не только количественных, но и качественных показателей);
Главное: перечень ожидаемых результатов в целом должен соответствовать списку поставленных конкурсантом задач.
Вместе с тем, следует охарактеризовать некоторые элементы формулирования ожидаемых результатов:
— направленность не на предотвращение следствий проблем, а на устранение их причин;
— направленность действий на выработку у целевой группы способности к последующему самообеспечению;
— вовлечение в реализацию проекта представителей целевой группы.
Бюджет
Важным этапом создания социального проекта является описание бюджета. Каждый этап реализации проекта требует определённых затрат денежных средств и материальных ресурсов. Поэтому важно после описания методов и шагов точно просчитать, сколько будет стоить каждый метод и каждый шаг вашего проекта. Для того чтобы эксперт не задавал много вопросов, стоит после описания бюджета дать комментарии к бюджету, т.е. пояснить на что тратится та или иная сумма.
Таким образом, бюджет социального проекта должен обладать следующими свойствами:
— обоснованностью объёмов предполагаемых затрат;
— логичностью – взаимосвязанностью с запланированными мероприятиями и иными действиями, предусмотренными по проекту;
— соразмерностью масштабу проекта;
— соразмерностью опыту проектанта;
— эффективностью (прозрачностью) затрат.
В заключение хотелось бы заметить, что важным (но не необходимым) для самого конкурсанта является то, что им будет заявлено о его собственном опыте опыте реализации социальных проектов. Кроме того, проект, как нам это представляется, должен обладать свойством его тиражируемости на других территориях (условия, при которых он может быть тиражируемым, можно конкретизировать).
Источник
РЕЗУЛЬТАТ, ОЖИДАЕМЫЙ
Страхование и управление риском. Терминологический словарь. — М.: Наука . В. В. Тулинов, В. С. Горин . 2000 .
Смотреть что такое «РЕЗУЛЬТАТ, ОЖИДАЕМЫЙ» в других словарях:
ОЖИДАЕМЫЙ — ОЖИДАЕМЫЙ, ая, ое; аем. Такой, к рого ждут, на к рый надеются, к рый должен осуществиться. О. результат. Ожидаемая встреча. Ожидаемое следствие. Ожидаемая награда. | сущ. ожидаемость, и, жен. Толковый словарь Ожегова. С.И. Ожегов, Н.Ю. Шведова.… … Толковый словарь Ожегова
ожидаемый результат — laukiamasis rezultatas statusas T sritis fizika atitikmenys: angl. prospective result vok. erwartendes Resultat, n rus. ожидаемый результат, m pranc. résultat espéré, m … Fizikos terminų žodynas
СТРАТЕГИЯ КОММУНИКАЦИИ — результат выбора и формирования вектора направленности коммуникационной деятельности организации; концепция, программа, генеральный курс субъекта управления по определению и достижению им основных коммуникационных целей организации в области… … Маркетинг. Большой толковый словарь
Футбольный рейтинг Эло — (часто произносится побуквенно, хотя не является акронимом) система ранжирования национальных мужских сборных по футболу. Метод основан на рейтинге Эло, но прошедший ряд изменений, принимая в расчет футбольную специфику. Не следует путать… … Википедия
Коэффициент корреляции — (Correlation coefficient) Коэффициент корреляции это статистический показатель зависимости двух случайных величин Определение коэффициента корреляции, виды коэффициентов корреляции, свойства коэффициента корреляции, вычисление и применение… … Энциклопедия инвестора
Эффективность рынка — (Market Efficiency) Понятие эффективности рынка, эффективность финансового рынка Понятие эффективности рынка, эффективность финансового рынка, эффективность рынка капитала Содержание Содержание 1. Гипотеза об Постулаты, лежащие в основе теории… … Энциклопедия инвестора
выход — 2.11 выход: Служебная дверь или запасной выход. Источник … Словарь-справочник терминов нормативно-технической документации
Инвестиции — (Investment) Инвестиции это капитальные вложения для получения прибыли Виды инвестиций, инвестиционные проекты, инвестиции в фондовый рынок, инвестиции в России, инвестиции в мире, во что инвестировать? Содержание >>>>>>>>>> … Энциклопедия инвестора
Рынок труда — (Labor market) Рынок труда это сфера формирования спроса и предложения на рабочую силу Определение рынка труда, определение рабочей силы, структура рынка труда, субъекты рынка труда, конъюнктура рынка труда, сущность открытого и скрытого рынка… … Энциклопедия инвестора
Рынок — (Market) Рынок это система отношений между продавцом (производителем услуг/товаров) и покупателем (потребителем услуг/товаров) История возникновения рынка, функции ранка, законы рынка, виды рынков, свободный рынок, государственное регулирование… … Энциклопедия инвестора
Источник
Ожидаемые результаты проекта
Рассуждая об измеримости цели, мы с вами выяснили, что, для того чтобы после завершения проекта оценить его успешность, нужно в начале проектирования установить его ожидаемые количественные и качественные результаты.
Количественные результаты – это количество представителей целевой группы, которые ощутят позитивные изменения после осуществления вашего проекта.
Качественные результаты – это конкретные изменения, которых вы добьетесь.
Для того, чтобы грамотно установить ожидаемые результаты вашего проекта, нужно помнить о трех их характеристиках. Они должны быть измеримы, адекватны и конкретны.
Измеримые результаты – это те, которые мы можем посчитать.
Адекватные – соответствующие по своему масштабу заявленной проблеме.
Конкретные – указывающие на целевую группу, сроки, качественные и количественные характеристики предполагаемых изменений.
Качественные результаты в силу своей специфики почти всегда будут менее измеримы, чем количественные, но их все равно нужно стараться формулировать как можно более точно. Давайте рассмотрим характеристики ожидаемых результатов на примерах.
В нашем примере с дворовыми играми целевая аудитория – дети 7-10 лет, проживающие в районе Н вашего города. Вы знаете, что в этом районе проживает около 400 детей этого возраста. Оценив свои возможности, вы понимаете, что с помощью своего проекта сможете охватить порядка 150 человек. Поэтому ожидаемый количественный результат проекта будет звучать так: «150 детей 7-10 лет, проживающих в районе Н, научатся играть в дворовые игры. 80 из них будут делать это регулярно». Другими количественными результатами вашего проекта станут количество занятий, которые волонтеры проведут с детьми, количество игр, которые будут детьми разучены, количество дворов, участвующих в проекте. Качественным результатом проекта будут умения, полученные детьми, навыки общения, приобретенные ими в ходе проекта, количество времени, которое они стали проводить на улице, т.е. изменения, которые произойдут благодаря вашему проекту. Эти ожидаемые результаты измеримы, адекватны и конкретны.
Цель вашего проекта – пропаганда здорового образа жизни среди подростков из вашего региона. Целевая аудитория – 250 тысяч подростков. Ожидаемый результат звучит так: «Ролик о вреде наркотиков, размещенный на региональном телевидении, посмотрят 1 млн. телезрителей (количество жителей региона). Они осознают важность ЗОЖ». Что здесь не так? Во-первых, в целевой группе проекта были заявлены подростки, значит, именно они должны фигурировать в ожидаемых результатах. Во-вторых, мы не можем точно сказать, сколько людей посмотрят ролик, – исходить просто из числа жителей региона в данном случае некорректно. Измерить качественный результат – осознание важности ЗОЖ – также невозможно. Таким образом, ожидаемые результаты проекта неизмеримы и неконкретны.
Задачи и мероприятия
Этот этап – ключевой в социальном проектировании. Он несложный, и главное здесь – понять его механизм и научиться мыслить в рамках задач и мероприятий.
У нас есть проблема: это то, как выглядит ситуация сейчас. Сейчас дети вместо того, чтобы играть во дворе, сидят дома, уткнувшись в гаджеты, потому что утрачена традиция игр во дворе. У нас есть цель – создать условия для того, чтобы эта традиция вернулась. А теперь давайте спросим себя: почему есть этот разрыв между проблемой и целью? Что мешает нам достичь желаемого результата? Из-за чего ситуация такая, какая она есть? Вероятно, из-за того, что современные дети не знают дворовых игр и не умеют в них играть. А также потому, что сегодня нет тех, кто может научить правилам игры — сегодняшние старшие тоже не играли во дворе. И, наконец, во дворах не организована игра детей, а сами они этого сделать не могут.
Решением каждой из трех проблем, сформулированных нами, будет конкретная задача.
Задача – составляющая цели, которая решает конкретную проблему на пути к достижению этой цели.
Итак, давайте превратим препятствия, мешающие ситуации сейчас стать такой, какой она должна быть, в задачи:
— Из проблемы «Современные дети 7-10 лет не знают дворовых игр и не умеют в них играть» вытекает задача «Научить детей 7-10 лет играть в различные игры во дворе».
— Из проблемы «Нет тех, кто может научить правилам игры» вытекает задача «Подготовить команду волонтеров, которые могут организовать игры детей 7-10 лет во дворах».
— Из проблемы «Во дворах не организована игра детей, а сами они это сделать не могут» вытекает задача «Организовать регулярные игры во дворах с детьми 7-10 лет силами подготовленных волонтеров».
Обратите внимание на то, что в формулировках задач уже заложены ожидаемые результаты нашего проекта. Конечно, чтобы правильно сформулировать результаты, с этим надо еще поработать, но в нашем примере результат может быть, например, таким:
— подготовлена команда волонтеров, которые умеют организовать игры детей 7-10 лет во дворах;
— дети 7-10 лет, включенные в проект, научились играть в различные игры во дворе;
— в определенном количестве дворов еженедельно силами волонтеров и самих детей организуются игры для детей;
— увеличилось количество детей 7-10 лет, которые регулярно играют со сверстниками во дворе в различные игры.
Дальше – самое интересное. Нужно решить поставленные задачи. Задачи решаются с помощью конкретных действий – мероприятий.
Давайте вернемся к нашему примеру с играми во дворе. Одна из наших задач заключалась в том, чтобы подготовить команду волонтеров, которые умеют организовать игры детей 7-10 лет во дворах. Давайте подумаем, какие действия нам необходимо предпринять, чтобы решить эту задачу.
1Во-первых, для того чтобы набрать группу волонтеров, надо сначала проинформировать тех, кто потенциально может заинтересоваться: провести презентацию проекта в ВУЗах и ССУЗах педагогической направленности; провести переговоры с молодежными советами (городским, вузовским и т.п.). Именно там есть активная молодежь. Если в городе есть волонтерский центр – встретиться с ребятами там и рассказать им о возможностях проекта.
Благодаря этим действиям мы получим, например, группу заинтересовавшихся ребят в количестве 60 человек, которые готовы включиться в проект.
2Следующее, что мы должны сделать, – обучить этих волонтеров играм и тому, как их организовывать, а еще тому, как взаимодействовать с детьми этого возраста. Какие действия необходимо для этого предпринять? Провести, например, «Школу игротехников», в программе которой все вышеперечисленное. Продолжительность обучения 2 месяца. Занятия 2 раза в неделю по 4 часа. И, конечно, если мы планируем такую обучающую программу, мы должны понимать, кто будет ее проводить.
Достаточно ли этого, чтобы задача была выполнена? Нет! У нас в задаче не просто волонтеры, которые знают игры, у нас волонтеры, которые умеют организовать эти игры с детьми. Значит, нам нужно еще одно действие.
3Дать возможность нашим волонтерам опробовать свои знания, провести практические занятия под присмотром преподавателей нашего курса и с их помощью (например, на какой-то пилотной группе).
Значит, наша задача будет решаться с помощью 3 мероприятий:
— отбор молодежи в возрасте с 18 по 21 год для участия в проекте в качестве игротехников во дворах;
— обучение волонтеров-игротехников;
— отработка навыков волонтерами-игротехниками под кураторством педагогов.
Таким образом, мероприятия – это то, что вы делаете для решения задачи. По сути, они и будут непосредственной реализацией вашего проекта.
Мероприятия – это действия, которые вы предпринимаете для того, чтобы решить задачу
Очень важно понимать разницу между задачами и мероприятиями. Задача – это общая формулировка того, что должно быть сделано, «направление движения». Формулируя задачу, вы определяете, какие препятствия между проблемой и целью необходимо преодолеть.
Мероприятия – конкретные шаги, действия, которые происходят в определенное время в определенном месте и имеют результат. Задача всегда шире, чем мероприятие, потому что она из них состоит. Если в задаче нет мероприятий или она состоит только из одного мероприятия, значит, на самом деле это не задача, а мероприятие.
Источник
Ожидаемый результат что это значит
Что пишут в блогах
2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова
Клара Янова – ответственная тестировщица, которая изучает, практикует и пропагандирует Rapid Software Testing. Недавно она написала на LinkedIn:
«Я могу ОЖИДАТЬ, что что-то произойдет. Но это необязательно значит, что Я ХОЧУ, чтобы это произошло. Я даже могу хотеть, чтобы это произошло, но то, что оно не происходит, вовсе не означает автоматом, что тут есть какая-то проблема.
Смысл заметки: пожалуйста, давайте покончим с «ожидаемыми результатами» в баг-репортах!»
В ответ Дерек Чарльз спросил:
«Но как еще ты сообщишь разработчику или команде, что ДОЛЖНО происходить? Думаю, что ожидаемые результаты необходимы, особенно если в ходе тестирования обнаружен регресс».
«Я предлагаю описывать поведение, которое кажется тестировщику проблематичным, и объяснять, ПОЧЕМУ это может быть проблемой для кого-то. Причины, почему поведение воспринимается как баг – вот что самое важное».
Именно так. Клара говорит в терминах проблем и оракулов – способов, благодаря которым мы распознаем проблемы, когда сталкиваемся с ними в ходе тестирования.
Есть закавыка с «тем, что должно произойти»: в разработке ПО не всегда ясно, что должно произойти. Более того (и важнее) – тестировщики не руководят проектом или бизнесом, и не диктуют, что должно происходить.
К примеру, в ходе тестирования я могу наткнуться на что-то смущающее меня в продукте – или удивляющее, или неверное. Спецификация говорит о желаемом поведении одно; разработчик утверждает, что спека устарела, и противоречит ей; продакт-оунер подтверждает, что спека устарела. Но также сообщает, что интерпретация желаемого поведения в исполнении разработчика – это не то, чего хочет она. А затем я сверяюсь с RFC, и оказывается, что интерпретация продакт-оунера противоречит тому, что RFC называет подходящим поведением.
К счастью, мне не нужно решать, и я не обязан говорить, что должно произойти. Моя задача как тестировщика – сообщить о явном несоответствии между продуктом и предположительно желаемыми вещами, или между продуктом и чьим-то явно выраженным желанием или требованием. В вышеописанном случае я дал продакт-оунеру знать о расхождении между ее интерпретацией и стандартом, и дальнейшее решение, чего она и бизнес хотят от продукта, за ней.
Даже если у меня есть какие-то ожидания, они могут быть ошибочными, а я могу заблуждаться в своем понимании того, как должно работать. К примеру, она может решить, что наш продукт не будет поддерживать этот стандарт. Она может указать мне на то, что стандарт, к которому я апеллирую, заменен более поздним. В любом случае то, как должно работать, решается не мной, а теми, кто всем рулит. Им за это деньги платят. И это хорошо, а не плохо.
Но я бы все равно хотел ответить на вопрос Дерека: как нам, тестировщикам, сообщать о проблеме, не ссылаясь на «ожидаемые результаты»?
- Вместо того, чтобы говорить «ожидаемый результат» и бросать все вот так, мы можем сказать «несоответствие спецификации».
Несоответствие спецификации – это особый случай более общего способа распознавания и описания проблемы: несоответствие заявлениям. «Несоответствие заявлениям» – это оракул-эвристика (эвристика – это ненадежный способ решения проблемы; оракул – это отдельный вид эвристики, который ненадежно помогает вам решить вопрос идентификации и описания бага). Когда продукт не соответствует заявлению, сделанному кем-то значимым, то это, скорее всего, проблема – или с продуктом, или с заявлением. Но не я, не тестировщик, решаю, в чем именно проблема.
Спецификация – это особая форма заявления о том, как работает продукт, или как он должен работать. Заявления могут делаться на дизайн-сессиях, планировочных митингах, при парном программировании, переговорах в коридоре, на тренингах… Заявления можно встретить в файлах справки, маркетинговых материалах, процессных диаграммах, справочных таблицах, руководствах пользователя, набросках на доске, UML-диаграммах. Заявления могут также содержаться в коде автоматизированной проверки, когда автор создает код, сравнивающий результат работы продукта с ожидаемым и предположительно желаемым результатом. Способность распознавать множество источников заявлений и несоответствий им делает нас лучше как тестировщиков.
Когда вы ссылаетесь на релевантное заявление, сообщая «не соответствует заявлению» (и природа заявления и его автор идентифицированы), вам не нужно говорить об «ожидаемом результате».
- Вместо «ожидаемого результата» вы можете сказать «не соответствует тому, как раньше работало».
Несоответствие истории – это оракул-эвристика. После внесения изменений продукт может получить новый баг. С другой стороны, продукт мог раньше работать криво, а теперь с ним все хорошо (это пример того, как оракул может увести нас не в ту степь или конфликтовать с другим оракулом, поэтому важно идентифицировать оракулы, которыми мы пользуемся в баг-репортах). Если вы (или окружающие) не знаете, почему было внесено желательное изменение – это другая проблема, но тем не менее проблема.
В любом случае, если вы говорите «не соответствует тому, как раньше работало» (и описываете это в терминах проблемы), вам не нужно говорить об «ожидаемом результате».
- Вместо «ожидаемого результата» вы можете сказать «не соответствует самому продукту».
Несоответствие самому себе – это оракул-эвристика. Это может принимать различные формы: продукт возвращает разные результаты при разных запусках; продукт в одной части демонстрирует чистый, бесшовный интерфейс, а в другой – раздражающий и запутывающий. В одной части продукта выводится точный результат, а в другой – неточный; один компонент логирует результаты в формате, отличающемся от логов другого компонента, и это затрудняет анализ…
Это несоответствие может быть нежелательным (из-за проблемы надежности), или совершенно нормальным (веб-страница новостного сайта должна меняться ежедневно), или оно может быть желательным и нежелательным по причинам, о которых вы не знаете (так как, как и я, вы не можете знать все).
В целом люди предпочитают вещи, ведущие себя согласованно. Тривиальный пример из Microsoft Office (Office 365): для поиска текста в Word команда клавиатуры – Ctrl+F. В Outlook, части того же самого пакета, Ctrl+F стартует функцию пересылки сообщения, а поиск запускается через F4. Если бы Outlook и Word одновременно разрабатывались одной и той же командой, это было бы, скорее всего, определено как баг и исправлено. В результате программный менеджер пакета Office решил, что соответствие истории продукта важнее, чем несоответствие продукта самому себе, и нам приходится с этим жить. Ну что ж.
В любом случае, когда вы говорите «не соответствует какому-то аспекту того же самого продукта» (и идентифицируете специфику несоответствия), вам не нужно говорить об «ожидаемых результатах»).
- Вместо «ожидаемого результата» вы можете сказать «не соответствует похожему продукту» (и указать продукт и причину несоответствия).
Несоответствие похожему продукту – это оракул-эвристика. Любой продукт (то, что кто-то произвел), дающий релевантные точки сравнения – это по определению похожий продукт. Это, конечно же, включает в себя продукты-конкуренты: Microsoft Word и Google Docs в этом смысле похожие продукты. Microsoft Word и WordPad – тоже похожие продукты, у них много общих функций. Если Word не может открыть RFT-файл, сделанный в WordPad, есть причины подозревать проблему в одном или другом из них. Если WordPad правильно печатает RFT, а Word – нет, есть повод подозревать проблему в Word/
Сравнима ли Unix-программа wc (подсчет слов) с Microsoft Word? Все, что делает wc – это считает слова в текстовых файлах, поэтому нет, хотя… У Word есть функция подсчета слов. Если подсчет слов Word в текстовом файле необъяснимо отличается от числа в wc, есть причина подозревать проблему в том или другом продукте.
Тест-инструменты и наборы автоматизированных проверок – это тоже сравнимые продукты. Если результат работы продукта не соответствует определенным желаемым результатам, выданным вашим тест-инструментом, или обрабатываемым для достижения этих результатов данным – есть причина подозревать проблему.
В любом случае, если вы говорите «не соответствует похожему продукту» и идентифицировали продукт и основания для сравнения, вам не нужно говорить об «ожидаемом результате».
Это всего лишь несколько примеров. Преподавая Rapid Software Testing, мы даем набор оракулов-эвристик, которые идентифицируют принципы желаемого (и нежелательного) соответствия (и несоответствия) для идентификации багов – подробнее можно узнать здесь.
Джеймс Бах недавно вывел еще один принцип, который можно применить к багам, но который, с моей точки зрения, больше применим к запросам на улучшение: мы хотим, чтобы продукт соответствовал приемлемому качеству – то есть был не просто хорош, а настолько хорош, насколько это возможно.
Почему это важно? По ряду причин, как думается мне.
Во-первых, «ожидаемый результат» прямо-таки вымогает вопрос, откуда взялись ожидания. Это просто посредник для чего-то более конкретного. Почему бы не перейти сразу к делу и не сказать об этом, оставаясь профессионалом? Потому что…
Во-вторых, четкое объяснение, откуда пришли ожидания, бережет время и фокусирует разговор на (не)желательных (не)соответствиях, которые имеют значение, когда разработчики и продакт-оунеры решают, баг ли это и надо ли это исправлять. Это также помогает фокусировать починку на нужном заявлении (к примеру, если продукт в порядке, а спека – нет, это намек на исправление спеки).
В-третьих, это помогает помнить, что наша задача как тестировщиков – не подтверждать, что продукт работает «как ожидается», а спрашивать «есть ли в этом проблема?» Продукт может соответствовать ожиданиям и вне зависимости от этого кишеть жуткими проблемами. Наша работа – искать, находить и описывать несоответствия и проблемы, которые имеют значение, прежде чем не стало слишком поздно.
В-четвертых, разговор в терминах оракулов вместо «ожидаемых результатов» помогает избежать патронизирования, снисходительности, потерь времени, и прочих элементов баг-репорта, которые заставляют разработчиков оскорбляться или закатывать глаза.
Источник
