Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?

Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?

Немного матана! Совсем недавно, на интервью я столкнулся с интересным вопросом: «Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?»

И казалось бы, ответ довольно очевидный: мол Нильсен говорит 5. Но почему 5? Откуда это магическое число? Без математики не обошлось.

Автор в статье погружается в тему довольно глубоко, проливая свет на скрытую для многих часть айсберга, и разбирается, так сколько ж нужно-то?

Если прорезюмировать, то можно сказать, что Нильсен не был не прав 🙂 Однако стоит приводить полный ответ:

—————————————————————————

Если во время тестирования эксперименты будут независимыми, а выборка по крайней мере квазислучайной, то мы можем предположить, что при тестировании 5 пользователей мы обнаружим 85% ошибок, с которыми сталкиваются не менее 31% пользователей.

—————————————————————————

Последняя часть, вообще интересная, не правда-ли? ) «Не менее 31% пользователей», то есть в самом неудачном случае 59% пользующихся так и не столкнуться с проблемами. Но это не слишком страшно.

Интересно, что если вы хотите повысить эффективность тестирования, то увеличение выборки не единственный способ это сделать (для приличного уровня понадобиться что-то около 40 испытуемых). Вы можете также повлиять на вероятность появления ошибки. Как не парадоксально, уменьшая случайность выборки (сегментация?), вы можете повысить вероятность возникновения ошибок и тем самым снизить число необходимых пользователей.

http://bit.ly/2UqfhOs

Правило хорошего тона на встречах и созвонах: рекомендации

Знаете, несмотря на то, что продакт менеджер это спринты, разработка, интерфейсы, метрики и бла, бла, бла, как раз с "бла, бла, бла", часто возникают проблемы.

Ты отвечаешь за продукт, рулишь большим потоком информации, собираешь встречи с заинтересованными лицами. Но как они проходят? Быстро обстучали, разбежались. Что-то начали делать, потом оказалось, что не так поняли друг друга. Потеряли во времени и ресурсах.

Коммуникации штука интересная и непростая. Люди, с которыми вы работаете, немного иначе смотрят на этот мир, а тем более не могут залезть вам в голову. Просто примите это. Да, не легко, понимаю, но нужно стараться.

Если посмотреть на день продакта, то он легко может состоять на 60-70-80%, из встреч и звонков. Поэтому дам хоть и банальные, но архиважные рекомендации по тому, как нужно проводить эти мероприятия.

0. Подготовка

Чтобы провести встречу или звонок, к ним нужно подготовиться (спасибо кэп). Это кажется настолько очевидно, что куча народа про это тупо забывает или забивает. Тебя зовут на встречу, а в итоге "ни бэ, ни мэ, ни кукарЕку". Ни целей, ни задач, ни решений. Народ просто смотрит друг на друга и не понимает, чтотнужно делать. 80% копаешься в контексте, потом 20% думаешь над решением. Отстой полнейший.

Если вы собираете встречу или звонок, будьте добры подготовиться: определите задачи, состав участников, краткий сценарий и результат, который хотите получить в конце.

1. Контекст

Обязательно убедитесь, что все участники находятся в едином контексте.

Не поленитесь и приложите описание встречи (agenda). Опишите задачу и открытые вопросы. Когда все начнется, еще раз проговорите эту инфу для участников. Так вы синхронизируете всех между собой.

2. Правила игры или сценарий

Когда все введены в контекст, расскажите о том, как будет проведена встреча.

Буквально основные этапы обсуждения: "Предлагаю начать с этого и обменяться мнениями. Дальше посмотрим на бенчмарки, которые я собрал (подготовка). В конце примем решение, на основе всей информации."

3. Во время встречи/звонка

В процессе диалога следите за соблюдением сценария. Если участники отклоняются от темы, возвращайте их обратно. Старайтесь вовлекать всех участников. Если вы позвали определенных людей, то значит вам нужно их мнение. Если не нужно, то нафиг звать?

Часто появляется альфа оратор, который давит остальных. Дайте ему высказаться, а затем спросите тех, кто отмалчивается. Таким образом все будут вовлечены в процесс, и вы получите разные мнения.

Обязательно записывайте основные моменты и договоренности на протяжении всего митинга.

4. Итоги и MOM

По итогу встречи проговорите то, о чем договорились. Кто-то из участников может вас дополнить. Скорректируйте список, если потребуется.

После встречи вышлите всем MOM (minuites of meeting) или протокол встречи с основными моментами и решениями.

Поздравляю

Теперь ваши встречи и звонки преобразятся. Вы наконец-то стали не просто продактом, а еще и менеджером, который умеет эффективно проводить подобные мероприятия.

Попробуйте хотя бы раз воспользоваться текущими рекомендациями и увидите насколько круче станут ваши коммуникации с коллегами.

P. S. Если то, что вы прочитали выше, для вас само собой разумеющиеся, то я искренне рад, что вы существуете.

Просто поделитесь этими рекомендациями с теми, кто о них еще не слышал. Так мы сделаем нашу корпоративную жизнь чуть лучше ;)

Испытываю слабость к сделанным с любовью вещам.

Испытываю слабость к сделанным с любовью вещам.

Продукты — физические и цифровые — за которыми чувствуется человек и его мысль, не оставляют тебя равнодушным.

Казалось бы:
«Просто» крекеры.
«Просто» упаковка.

Но.

Смотрите, что написано внутри

«Привет!

Я — специальная конструкция :)

Именно благодаря мне при транспортировке крекеры не ломаются и остаются целыми.

Хорошего дня!»

То есть кто-то прошёл экстра милю:
— согласовал идею
— договорился о технологии
— и вовлёк команду в эти экстра косты на производство (с одной стороны)

С другой → удивил меня и порадовал.

Это настоящий микро-момент, где ты испытываешь своё микро-WOW: коробка рассказывает тебе свою историю в категориях пользы для тебя.

Дружественный, но не инфантильный tone-of-voice. Пожелание хорошего дня.

Если мы все с вами так будем подходить к работе, так строить команду и компанию, чтобы этого было больше — будем жить в другом мире.

Если знаете ребят — передайте респект.

Минутка рекомендаций книг

Минутка рекомендаций книг о человеке, для неторопливого чтения в самоизоляции и для творческого осмысления потребностей современного общества в период перемен внешних условий.

Старайтесь самые принципиальные задачи ставить себе на утро, может еще до завтрака, когда мозг отдохнувший, свободный и радостный. Иногда пять минут утренних размышлений по проекту вызывает такой позитивный прилив энергии, что возникает «прорыв» — мыслить становится интересно и легко, факты прочитываются иначе. Читайте по двадцать минут с утра, неторопливо впитывая смысл, а не текст. Возможно, что за день сама информация из книги или статьи свяжется логическими связями с вашей повседневностью и поможет ее трансформировать, увидеть иначе, а это и есть настоящее творчество.

Леви-Стросс. «Структурная антропология»
Пиаже. «Психология интеллекта»
Тейяр де Шарден. «Феномен человека»
Вебер. «Протестантская этика и дух капитализма»
Веблен. «Теория праздного класса»
Фрейд. «По ту сторону принципа удовольствия»
Ортега-и-Гассет. «Восстание масс»
Лебон. «Психология народов и масс»
Фромм. «Бегство от свободы»
Фромм. «Анатомия человеческой деструктивности»

7 важных факторов PHP-приложения

7 важных факторов PHP-приложения

Инженеры платформы Heroku (https://www.heroku.com/) на основе собственного опыта создали методологию (https://12factor.net/ru/) для разработки SaaS-приложений.

Эта методология учитывает три важных аспекта:
— расширяемость — развитие кодовой базы и функционала;
— сопровождаемость и возможность командной работы над проектом;
— масштабируемость.

12 факторов приложения стали шаблоном для многих разработчиков и Ops-инженеров, а мы постарались адаптировать самые важные из них для приложений на PHP.

Кодовая база (https://12factor.net/ru/codebase). Забота о коде начинается с принципов его версионирования и хранения. Используйте Git Flow или его адаптацию с учетом специфики работы ваших команд.

Зависимости (https://12factor.net/ru/dependencies). Используйте менеджер зависимостей Composer (https://getcomposer.org/) и его основные операции install и update для манипуляций c composer.json (https://getcomposer.org/doc/04-schema.md) и composer.lock.

Конфигурация (https://12factor.net/ru/config). Предпочтительным методом обработки конфигурации является использование переменных среды. Для работы с ними мы применяем компонент symfony/dotenv (https://github.com/symfony/dotenv).

Параллелизм (https://12factor.net/ru/concurrency). Выполняйте процессы в фоне, тем самым снижая время отклика при взаимодействии с вашим сервисом. Выделяйте веб-процессы в реальном времени и рабочие процессы. Первые принимают http-запросы от клиента, а вторые — выполняют фоновые задачи, например, с помощью брокера сообщений RabbitMQ (https://github.com/rabbitmq).

Паритет разработки/работы приложения (https://12factor.net/ru/dev-prod-parity). Для того чтобы обеспечить схожесть сред разработки, тестирования и продакшена, мы используем виртуализацию на основе Docker и специально подготовленные образы, содержащие одинаковые наборы и версии библиотек. Промышленные и тестовые среды отличаются лишь степенью масштабирования, на основе технологий K8S и Swarm.

Журналирование (https://12factor.net/ru/logs). Фактор утверждает, что приложение должно просто писать в STDOUT и STDERR, а среда должна отвечать за маршрутизацию этих сообщений в хранилище. Технология PHP-FPM позволяет производить вывод логов в STDOUT, что крайне полезно при работе с Docker-контейнерами. Для организации процесса логирования на уровне приложения мы используем сторонние внешние библиотеки, например Monolog (https://github.com/Seldaek/monolog) или компоненты фреймворков.

Задачи администрирования (https://12factor.net/ru/admin-processes). Реализовать сценарии администрирования приложения можно с помощью внешних библиотек, например Symfony Console (https://github.com/symfony/console). Большинство современных фреймворков имеют встроенные средства для организации запуска консольных команд для служебных целей и миграций. Например, в Yii Framework есть понятие консольного приложения (https://www.yiiframework.com/doc/guide/2.0/en/tutorial-console) и команды.

О таланте

О таланте

О таланте. Таланте и стае. Знаю полсотни талантливых ребят, тех кому дано природой, космосом, родителями, средой, умение видеть в своем деле больше и глубже других. Все — сложные. Но видел я и как сложно бывает таким людям попадать в среду людей и задач не обремененных сложностью. Талантливый всегда в сомнении, в понимании промежуточности любого успеха и жестоком давлении на самого себя.

Стая не готова увидеть в талантливом путь к соучастию, но помогать, понимать, а главное — оставить наедине талант с собственным делом, возможно. Таланту сложно увидеть в себе вершину, верхушку достижения, ведь особенность любой одаренности в легкости с которой эта вершина уходит все дальше и выше.

Талант стремится делать иначе, искать с легкостью и упорством неожиданное и это ставит результаты его работы на одну плоскость восприятия с безумством и бездарностью. Видеть в необычном, странном, разноголосом талантливую суть, самостоятельный стержень — это умение. Надо воспитывать в себе это чувство «понимания непонимания».
Редкий талант успешен, он не умеет голосить о себе, не умеет объяснять, не умеет дергать за рукав. Не нужно хвалить, нужно верить. Доверять сложному. Помогайте талантливым умением слышать. Не отрывайте их пальцы от труда, не наносите ран осуждением — таланту не нужно много труда в физическом мире, но труд душевный, мыслительный, самоокапывание не самых плодородных тем и заданий — удел способных, одаренных и талантливых. Не отвлекайте талантливых от мысли — но становитесь их голосом, их личным чудом, вдохновителем. Становитесь стаей, коллективным пространством понимания, что все мы разные и роли наши только в взаимной поддержке, в взаимном импульсе.

Но чаще я видел как стая вытаптывала из таланта желание быть. Выгавкивала своими советами и напутсвиями из человека огонек блеска в глазах, который бы мог стать сигнальным огнем маяка для других. Выбивала из стаи. Вылизывала лестью и похвалой путь, на котором легко соскользнуть с цели. Быть — иным.