Ускоряем исследования с помощью конкурсов как их готовить и выигрывать / Иван...Ontico
Мы в Авито часто сталкиваемся с ситуацией, когда нужно быстро придумать алгоритм, решающий некоторую бизнес задачу на основе анализа больших объёмов данных. Придумать какой-то алгоритм не сложно, но каждый раз возникает вопрос — а вдруг можно решить эту же задачу в разы более качественно. Исследования можно вести годами, но это рискованно — лучшего решения может и не быть, и будет затрачено много времени.
На помощь приходят конкурсы по анализу данных. Мы устраивали конкурсы на построение алгоритмов, работающих с совершенно различными типами и объемами данных:
+ Выявление запрещенных объявлений.
+ Прогнозирование вероятности клика на рекламное объявление.
+ Обнаружение телефонов на изображениях.
+ Прогнозирование инкрементального эффекта от скидочных акций.
Какие-то были более удачными, какие-то — менее. Расскажем про основные этапы подготовки задач к конкурсу, а также про основные трюки, используемые для победы в таких конкурсах
Потоковые алгоритмы в задачах обработки больших данных / Виктор Евстратов (Se...Ontico
Для того чтобы таргетировать рекламу по поведению интернет-пользователей, DMP ежедневно оценивает терабайты данных. В докладе расскажу, как при помощи алгоритмов потоковой обработки данных можно быстро оценить большой объем статистики и формы распределения различных характеристик.
+ Что будем оценивать?
Будем оценивать функции распределения различных случайных величин. На практике это может понадобиться, например, как инструмент первичного анализа трафика или как данные, необходимые для принятия решений в RTB.
+ Распределения параметров пользователей и их поведения.
+ Метод Манро-Патерсона, метод Канна-Гринвальда.
В этой части я расскажу о методе Манро-Патерсона — алгоритме оценки медианы, и о методе Канна-Гринвальда, который позволяет оценить функцию распределения.
+ Мотивирующий пример.
Расскажу о том, как применяю описанные методы на наших данных для составления портрета целевой аудитории наших клиентов.
КГТУ Лекция 7: Обеспечение Качества Программного Обеспечения Iosif Itkin
Курс Лекций: Обеспечение Качества Программного Обеспечения
Лекция 7: Высоконагруженные системы и тестирование производительности
Максим Рудовский, Инновационные Трейдинговые Системы
Иосиф Иткин, Exactpro Systems
Выбираем СУБД для хранения временных рядов / Павел Филонов (Лаборатория Каспе...Ontico
Проблема мониторинга целостности технологических процессов на индустриальных объектах связана с обработкой большого объема показаний различных датчиков (температура, давление, управляющие сигналы и т.д.). Каждый из таких сенсоров порождает временной ряд, который может быть использован как для потоковой обработки, так и для проведения исторического анализа и расследования инцидентов. Здесь возникает задача хранения показаний за некоторый период времени. При этом потоки данных могут достигать десятков тысяч показаний в секунду, а период хранения достигать нескольких месяцев или даже лет. При таких условиях необходимо предельно аккуратно выбирать СУБД для хранения временных рядов, которая правильно впишется в нефункциональные требования.
В качестве конкурсантов выступят: OpenTSDB, InfluxDB, MongoDB, PostgreSQL и еще несколько "чёрных лошадок".
В докладе будет рассмотрен многокритериальный подход к выбору с учетом таких показателей как:
* зависимость пропускной способности на запись от различных параметров;
* время исполнения запроса на чтение;
* степень сжатия данных;
* пропускная способность при нагрузочном тестировании.
В докладе предлагается не только привести получившиеся числа, но и обсудить почему они получились именно такими.
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
Бигдата — как добывать золото из данных / Александр Сербул (1С-Битрикс)Ontico
Расскажем о самых распространенных технологиях и алгоритмах добычи критичной для бизнеса информации из больших массивов данных. Отдельно коснемся темы рекомендательных сервисов и их эффективного применения.
План:
1) Откуда брать данные, тренды и концепции.
2) Основные алгоритмы и технологии их применения для обработки массивов данных: MapReduce, Spark.
3) Методика создания рекомендательного сервиса — этапы от концепции до работающей системы.
Ускоряем исследования с помощью конкурсов как их готовить и выигрывать / Иван...Ontico
Мы в Авито часто сталкиваемся с ситуацией, когда нужно быстро придумать алгоритм, решающий некоторую бизнес задачу на основе анализа больших объёмов данных. Придумать какой-то алгоритм не сложно, но каждый раз возникает вопрос — а вдруг можно решить эту же задачу в разы более качественно. Исследования можно вести годами, но это рискованно — лучшего решения может и не быть, и будет затрачено много времени.
На помощь приходят конкурсы по анализу данных. Мы устраивали конкурсы на построение алгоритмов, работающих с совершенно различными типами и объемами данных:
+ Выявление запрещенных объявлений.
+ Прогнозирование вероятности клика на рекламное объявление.
+ Обнаружение телефонов на изображениях.
+ Прогнозирование инкрементального эффекта от скидочных акций.
Какие-то были более удачными, какие-то — менее. Расскажем про основные этапы подготовки задач к конкурсу, а также про основные трюки, используемые для победы в таких конкурсах
Потоковые алгоритмы в задачах обработки больших данных / Виктор Евстратов (Se...Ontico
Для того чтобы таргетировать рекламу по поведению интернет-пользователей, DMP ежедневно оценивает терабайты данных. В докладе расскажу, как при помощи алгоритмов потоковой обработки данных можно быстро оценить большой объем статистики и формы распределения различных характеристик.
+ Что будем оценивать?
Будем оценивать функции распределения различных случайных величин. На практике это может понадобиться, например, как инструмент первичного анализа трафика или как данные, необходимые для принятия решений в RTB.
+ Распределения параметров пользователей и их поведения.
+ Метод Манро-Патерсона, метод Канна-Гринвальда.
В этой части я расскажу о методе Манро-Патерсона — алгоритме оценки медианы, и о методе Канна-Гринвальда, который позволяет оценить функцию распределения.
+ Мотивирующий пример.
Расскажу о том, как применяю описанные методы на наших данных для составления портрета целевой аудитории наших клиентов.
КГТУ Лекция 7: Обеспечение Качества Программного Обеспечения Iosif Itkin
Курс Лекций: Обеспечение Качества Программного Обеспечения
Лекция 7: Высоконагруженные системы и тестирование производительности
Максим Рудовский, Инновационные Трейдинговые Системы
Иосиф Иткин, Exactpro Systems
Выбираем СУБД для хранения временных рядов / Павел Филонов (Лаборатория Каспе...Ontico
Проблема мониторинга целостности технологических процессов на индустриальных объектах связана с обработкой большого объема показаний различных датчиков (температура, давление, управляющие сигналы и т.д.). Каждый из таких сенсоров порождает временной ряд, который может быть использован как для потоковой обработки, так и для проведения исторического анализа и расследования инцидентов. Здесь возникает задача хранения показаний за некоторый период времени. При этом потоки данных могут достигать десятков тысяч показаний в секунду, а период хранения достигать нескольких месяцев или даже лет. При таких условиях необходимо предельно аккуратно выбирать СУБД для хранения временных рядов, которая правильно впишется в нефункциональные требования.
В качестве конкурсантов выступят: OpenTSDB, InfluxDB, MongoDB, PostgreSQL и еще несколько "чёрных лошадок".
В докладе будет рассмотрен многокритериальный подход к выбору с учетом таких показателей как:
* зависимость пропускной способности на запись от различных параметров;
* время исполнения запроса на чтение;
* степень сжатия данных;
* пропускная способность при нагрузочном тестировании.
В докладе предлагается не только привести получившиеся числа, но и обсудить почему они получились именно такими.
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
Бигдата — как добывать золото из данных / Александр Сербул (1С-Битрикс)Ontico
Расскажем о самых распространенных технологиях и алгоритмах добычи критичной для бизнеса информации из больших массивов данных. Отдельно коснемся темы рекомендательных сервисов и их эффективного применения.
План:
1) Откуда брать данные, тренды и концепции.
2) Основные алгоритмы и технологии их применения для обработки массивов данных: MapReduce, Spark.
3) Методика создания рекомендательного сервиса — этапы от концепции до работающей системы.
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
(Не) преждевременная оптимизация проекта на Unreal Engine 4 / Владимир Алямки...DevGAMM Conference
В рамках лекции будет рассмотрен ряд уже имеющихся инструментов оптимизации на движке, о которых стоит знать, начиная работу над проектом. Доклад также затрагивает практическую основу и причины таких подходов, совмещая тематику архитектуры современных игровых движков и механик рендера сцены.
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Статический анализ кода: борьба с удорожанием ошибокAndrey Karpov
Нет смысла говорить, что "надо писать код без ошибок". Ошибки были, есть и будут. Все хорошо понимают, что ошибки следует исправлять. Люди забывают, что ошибка должна быть исправлена с минимальными временными и денежными затратами!
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Функциональное тестирование высоконагруженных проектов / Илья Пастушков (2ГИС)Ontico
В докладе я расскажу о следующем:
+ почему тема доклада не оговорка, а абсолютно реальная вещь;
+ что можно извлечь из результатов теста помимо «да/нет»;
+ в каких случаях «количество» = «качество»;
+ когда «один в поле не воин»;
+ немного о том, зачем тестировщику нужна матстатистика;
+ как избежать случайностей в результатах;
+ «буря в стакане» или масштабируем highload в docker/openvz;
+ почему фиксация запросов в тестах приводит к фиксации сервиса на продакшене;
+ а также всё вышеперечисленное на примерах наших проектов.
Презентация делалась для JuJa конференции - Java конференции для (пре) Juniors: https://juja.com.ua/materials/jujacon-2017/
В ней
- описываются основные темы-вопросы, которые часто спрашивают на собеседовании на позицию Junior Java Developer;
- советы, что спросить собеседующего;
- как себя позиционировать, как относиться к собеседованию, как не бояться и как понять, что вам "туда".
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
(Не) преждевременная оптимизация проекта на Unreal Engine 4 / Владимир Алямки...DevGAMM Conference
В рамках лекции будет рассмотрен ряд уже имеющихся инструментов оптимизации на движке, о которых стоит знать, начиная работу над проектом. Доклад также затрагивает практическую основу и причины таких подходов, совмещая тематику архитектуры современных игровых движков и механик рендера сцены.
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Статический анализ кода: борьба с удорожанием ошибокAndrey Karpov
Нет смысла говорить, что "надо писать код без ошибок". Ошибки были, есть и будут. Все хорошо понимают, что ошибки следует исправлять. Люди забывают, что ошибка должна быть исправлена с минимальными временными и денежными затратами!
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Функциональное тестирование высоконагруженных проектов / Илья Пастушков (2ГИС)Ontico
В докладе я расскажу о следующем:
+ почему тема доклада не оговорка, а абсолютно реальная вещь;
+ что можно извлечь из результатов теста помимо «да/нет»;
+ в каких случаях «количество» = «качество»;
+ когда «один в поле не воин»;
+ немного о том, зачем тестировщику нужна матстатистика;
+ как избежать случайностей в результатах;
+ «буря в стакане» или масштабируем highload в docker/openvz;
+ почему фиксация запросов в тестах приводит к фиксации сервиса на продакшене;
+ а также всё вышеперечисленное на примерах наших проектов.
Презентация делалась для JuJa конференции - Java конференции для (пре) Juniors: https://juja.com.ua/materials/jujacon-2017/
В ней
- описываются основные темы-вопросы, которые часто спрашивают на собеседовании на позицию Junior Java Developer;
- советы, что спросить собеседующего;
- как себя позиционировать, как относиться к собеседованию, как не бояться и как понять, что вам "туда".
5. Но почему?
Оценка важна для бизнеса:
Время = деньги
Оценка важна для синхронизации работ
в команде
Оценка важна для будущих проектов
Оценка важна для самоорганизации
8. Как не надо 1
Группа A
Оригинальная спецификация
456 часов
Группа Б
Оригинальная спецификация,
с
указанием ,
что
оценка
постановщика – 500 часов
555 часов
Группа С
Оригинальная спецификация,
с
указанием ,
что
оценка
постановщика – 50 часов
99 часов
10. Как не надо 2
Группа A
Оригинальная спецификация объем
в 20 страниц
117 часов
Группа Б
Та
же
спецификация
но
с
увеличенным
форматированием
(~30 cтраниц)
173 часа
12. Как не надо 3
“В этот раз (версию/спринт) мы будем
работать более эффективно”
“Если проектом грамотно управлять, то
можно сделать быстрее”
“Вот внедрим эту технологию и можно
будет протестировать в 2 раза
быстрее”
21. Интуитивная оценка
Сколько станций метро в Лондоне?
Какой средний срок беременности у осла
(в днях)?
Какова температура плавления золота?
Сколько составили сборы фильма «Dark
Knight Rises» в мире?
22. Интуитивная оценка
Сколько станций метро в Лондоне?
270
Какой средний срок беременности у осла
(в днях)? - 348
Какова температура плавления золота? 1063
Сколько составили сборы фильма «Dark
Knight Rises» в мире? - 1,084 млрд. $
26. Оценка по аналогии
Сколько станций метро в Токио?
Какой средний срок беременности у зебры
(в днях)?
Какова температура плавления меди?
Сколько составили сборы фильма «Iron
Man 3» в мире?
27. Оценка по аналогии
Сколько станций метро в Токио?
290
Какой средний срок беременности у зебры
(в днях)? - 361
Какова температура плавления меди? 1083,4
Сколько составили сборы фильма «Iron
Man 3» в мире? - 1,215 млрд. $
29. Оценка по аналогии
Требует наличия предыдущего опыта и
оценок (и чем их больше, тем точнее
оценка)
Не применима для принципиально новых
проектов и предметных областей
Хорошо работает на малых и средних
проектах
Опыт предыдущих проектов может быть
неосознанно нерелевантным
31. Экспертная оценка
Сколько станций метро в Москве?
Какой средний срок беременности у
человекообразной гориллы(в днях)?
Какова температура плавления бензола?
Сколько составили сборы фильма
«Avengers» в мире?
32. Экспертная оценка
Сколько станций метро в Москве?
190
Какой средний срок беременности у
человекообразной гориллы(в днях)? 260
Какова температура плавления бензола? 5,5
Сколько составили сборы фильма «Avengers»
в мире? 1,518 млрд. $
34. Экспертная оценка
Можно оценивать любые проекты и вещи (был
бы эксперт)
Нужен тот самый эксперт
Очень сильно зависит от человеческого
фактора (устал, забыл, забил, запил)
Риск “игнорирования” рисков
36. Немного формул
Берем три экспертных оценки срока:
!
MIN
- «раньше не справлюсь точно, даже если
повезет»
MAX
- «успею гарантированно, даже если все
риски сыграют»
NORM
– «наиболее вероятно успею»
38. Что это дает?
➢ Длительность
задачи - случайная
величина, имеющая
бета-распределение.
!
➢ Между крайними
оценками – 6 сигм
!
➢Вероятность
попадания в оценку:
72%
39. PERT
Сколько станций метро в Ташкенте?
Какой средний срок беременности у рыси (в
днях)?
Какова температура плавления платины?
Сколько составили сборы фильма «Сумерки»
в мире?
40. PERT
Сколько станций метро в Ташкенте?
29
Какой средний срок беременности у рыси (в
днях)? 72
Какова температура плавления платины?1772
Сколько составили сборы фильма «Сумерки»
в мире? 392 млн $
42. PERT
Хорошо применяется для неопределенных задач
Довольно высокая вероятность верной оценки
Есть возможности модифицировать методику и
получить более точную оценку без
дополнительных трудозатрат ;)
49. А если подумать
Мозговой штурм - вместе с командой!
“Срываем низко висящие плоды”
Тестируем то что нужно.
Привлекаем, но только экспертов!
Заручаемся поддержкой руководства
Проводим ретроспективу по факту