Да, в этом значении учтено, что некоторые части всё равно пропускаются. 60 знаков в секунду — это довольно быстро. Если средняя скорость выше — читатель гарантированно не читал и сразу пошёл в комменты)
В будущем хотелось бы показать тепловую карту статьи, чтобы автор понимал, какие части читали вдумчиво, а какие скроллили быстрее. Но до этого нам пока далеко.
По средней скорости скролла во время чтения. Доскролл — это достижение конца статьи без дополнительных условий. Дочтение — достижение конца статьи с низкой скоростью скролла (это позволяет предположить, что человек всё-таки читал текст).
Чтобы засчиталось дочтение, скорость скролла должна быть ниже 60 знаков в секунду. Это стандарт для большинства систем контентной аналитики.
При этом дочтение — это частный случай доскролла. Поэтому если значения не равны, то доскроллов будет больше.
И если вы считаете, что они начинают и заканчивают одновременно
Так считаю не только я, но и Институт управления проектами, который выпускает PMBOK. C «начинают» ещё можно хвостом покрутить и сказать, что программист мог не входить в инициативную группу проекта. Но с «заканчивают» всё однозначно.
Смотрим жизненный цикл проекта в PMBOK, находим пять фаз:
Инициация
Планирование
Исполнение
Контроль (с пометкой, что этап проходит одновременно с предыдущим)
Завершение
И завершается проект для команды только на этапе Завершение (сюрприз). В нём программист принимает непосредственное участие — ходит на ретро, пишет недостающую техническую документацию.
Как можно придерживаться определения проекта из PMBOK и отрицать это — я не знаю, вам виднее.
Прочитал комментарий, внутренне согласился с основными тезисами и не понял, где мы расходимся. Перечитал внимательнее — кажется, дело в определениях)
Вы проектом называете сущность, которая во времени ограничена только коммерческой целесообразностью (пока целесообразно, ваш проект существует). Ваше право, определения — штука гибкая.
Открывайте форточку, здесь душно
У проекта также есть общепринятое определение, которое даёт PMBOK:
Проект — это временное предприятие, направленное на создание уникального продукта, услуги или результата.
Т.е. и для разработчика, и для продакта проект заканчивается в момент достижения результата (создания продукта, оказания услуги). По контексту понятно, что ваше определение проекта отличается и больше похоже на продукт.
пример продукта на Хабре: статистика публикации для автора
пример проекта на Хабре: реализация MVP статистики публикации или новая фича для статистики публикации
В своём посте я пользовался общепринятым определением проекта. Выходит, что я полностью согласен с вашим тезисом и в каком-то смысле говорю о том же самом:
Рассказывайте про реализованные отдельные фичи, их аналитику, оценку их перспективности, планирование и согласование разработки, внедрение и полученный эффект, влияние на другие фичи и т.д.
И в то же время ваш тезис не вступает в противоречие с основным тезисом из моего поста. 9 из 10 проектов (фич) не повлияют на продукт или будут иметь отрицательный эффект, что снижает ценность рассказа о них. Вы можете с этим не согласиться и привести аргументы против, ведь в негативном опыте тоже есть польза. Но в резюме «я уронил Retention на 30%» вряд ли кто-то станет писать.
При этом у разработчика все 10 из 10 фич будут сильными, потому что каждая из них была реализована (в этом и состоит задача разработчика).
При прочих равных потребитель выберет тот курс, создатели которого больше врут обещают больший результат меньшими усилиями. Онлайн-школа не может не приукрашивать реальность, если она хочет конкурировать.
Со временем реальность искажается больше: кто-то первым начинает приукрашивать чуть сильнее, остальные подтягиваются до этого уровня — и вот уже будущим разрабам обещают 300k в наносекунду за работу, с которой якобы и дурак справится.
Продакт действительно почти всегда работает больше, чем с одним разработчиком. Но я не понял, как это опровергает тейк из поста.
Допустим, продакт клепает продуктовые изменения вместе с 20 разработчиками, 1 из 10 изменений приносит пользу. За 10 изменений продакт получил +1 в карму на рынке труда, каждый разработчик — +10.
Если продуктовых изменений больше, то и работы продакт выполняет больше — я же тут не про загруженность/недозагруженность, а про сам принцип) За участие в одном продуктовом изменении продакт получает конвертируемого в деньги опыта меньше, чем команда — потому что его оценивают по результатам.
Продакт отвечает за завершённость и качество линейки продуктов.
Ну и здесь явно смешаны роли проджекта и продакта. В укомплектованной команде за завершённость и качество (если под качеством понимать соответствие ТЗ) отвечает проджект. Ответственность продакта на уровень выше — он отвечает за то, чтобы выпущенный продукт сработал в бизнесовом смысле. Привлёк новых пользователей, принёс деньги — в зависимости от того, что нужно компании сейчас.
Обычная жизнь дизайнера. Паша ходит на работу, пьет кофе, старается спать. Рисуйте плакаты, билеты, афиши и другое, потому что всем надо что-то есть. Исследуйте московские улицы в поисках своих шедевродизайнов.
Волшебные приключения ночью. Ночью вы отправитесь на крыши Москвы, где вам предстоит спасать существ, остерегаясь лишних глаз. Уютный стелс, за ошибки в котором не наказывает игра, но самых аккуратных ждёт вознаграждение.
Ламповая завязка! Почему-то вспомнилась Persona, что ни разу не минус — достойный ориентир. Правда, там за ошибки игра наказывает (да ещё как).
Подруга закончила длительные курсы по бэкенду, но стартовая галера особо не ищется. Говорит, что сейчас у джунов принято сбиваться в стайки и вместе пилить небольшой проект под бизнес чьих-то родственников.
Помогает ли это найти работу потом — точно не знаю, слежу за подругой)
Воронки отработают корректно: система затрекает глубину доскролла и отдельно время, чтобы посчитать дочтение. Если дело происходит в несколько сеансов — мы учтём только самое длительное и глубокое прочтение.
Но тут важно понимать, что воронки не показывают распределение внимания по частям статьи — для этого используются другие, более сложные системы (вроде яндексовского Вебвизора). То есть воронка дочтений ни при каких условиях не покажет, что дочтение 3/4 было больше, чем 2/4. Даже если по факту юзеры проскроллили кусок 2/4, но два раза внимательно прочитали 3/4.
Задача воронок другая — показать, в каком месте читатели отвалились (совсем перестали скроллить или читать). С этим наша система справляется отлично.
В будущем хотелось бы разработать условную тепловую карту, чтобы было видно, какие части статьи читались особенно внимательно. Но впереди долгий путь)
Пока читал коммент, в голове всплыл тот самый голос) Но вообще есть такая опасность.
Поэтому доступ к данным по всем публикациям мы никому давать не планируем. Понаобучают моделей, а статей от тёплых ламповых человеков не дождёшься потом.
Пошёл в комменты, чтобы написать о том же самом. В общем, как всегда всё сводится к поиску баланса между чётко отлаженными процессами и здоровым рабочим задором.
Но читать статьи про нормальных людей не очень интересно)
Получается не совсем так, ведь есть прочитавшие не до конца. По идее их тоже нужно учитывать (за вычетом тех, кто дочитал до конца).
Но логика понятна, на выходе должен получиться показатель в духе «среднее количество прочитанных знаков». И больше он будет у крайне увлекательного лонгрида, да.
Примеров таких статей у меня пока нет, данные собираются с 25 мая — маловато, чтобы объективно оценить. Но потом примеры найдутся и мы наверняка включим их в золотой фонд где-нибудь в хелпе Хабра)
Момент: ниже 60 знаков в секунду. Если что, придумали не мы — это стандарт индустрии.
Скорость считаем по всей части статьи, которую доскроллил пользователь. Учитываем только время, когда во вьюпорте находился текст. То есть если пользователь уходит на другую вкладку — мы это понимаем и трекаем правильно.
В примере с бутербродами статистика действительно портится. Через некоторое время мы поймём, что пользователь ушёл, но не сразу. К счастью, на тысячах прочтений влияние таких случаев минимально. Бороться с этим можно, но есть риск, что начнутся перекосы в статистике по читателям, которые за бутербродом не пошли)
Да, в этом значении учтено, что некоторые части всё равно пропускаются. 60 знаков в секунду — это довольно быстро. Если средняя скорость выше — читатель гарантированно не читал и сразу пошёл в комменты)
В будущем хотелось бы показать тепловую карту статьи, чтобы автор понимал, какие части читали вдумчиво, а какие скроллили быстрее. Но до этого нам пока далеко.
По средней скорости скролла во время чтения. Доскролл — это достижение конца статьи без дополнительных условий. Дочтение — достижение конца статьи с низкой скоростью скролла (это позволяет предположить, что человек всё-таки читал текст).
Чтобы засчиталось дочтение, скорость скролла должна быть ниже 60 знаков в секунду. Это стандарт для большинства систем контентной аналитики.
При этом дочтение — это частный случай доскролла. Поэтому если значения не равны, то доскроллов будет больше.
Так считаю не только я, но и Институт управления проектами, который выпускает PMBOK. C «начинают» ещё можно хвостом покрутить и сказать, что программист мог не входить в инициативную группу проекта. Но с «заканчивают» всё однозначно.
Смотрим жизненный цикл проекта в PMBOK, находим пять фаз:
Инициация
Планирование
Исполнение
Контроль (с пометкой, что этап проходит одновременно с предыдущим)
Завершение
И завершается проект для команды только на этапе Завершение (сюрприз). В нём программист принимает непосредственное участие — ходит на ретро, пишет недостающую техническую документацию.
Как можно придерживаться определения проекта из PMBOK и отрицать это — я не знаю, вам виднее.
Прочитал комментарий, внутренне согласился с основными тезисами и не понял, где мы расходимся. Перечитал внимательнее — кажется, дело в определениях)
Вы проектом называете сущность, которая во времени ограничена только коммерческой целесообразностью (пока целесообразно, ваш проект существует). Ваше право, определения — штука гибкая.
Открывайте форточку, здесь душно
У проекта также есть общепринятое определение, которое даёт PMBOK:
Т.е. и для разработчика, и для продакта проект заканчивается в момент достижения результата (создания продукта, оказания услуги). По контексту понятно, что ваше определение проекта отличается и больше похоже на продукт.
пример продукта на Хабре: статистика публикации для автора
пример проекта на Хабре: реализация MVP статистики публикации или новая фича для статистики публикации
В своём посте я пользовался общепринятым определением проекта. Выходит, что я полностью согласен с вашим тезисом и в каком-то смысле говорю о том же самом:
И в то же время ваш тезис не вступает в противоречие с основным тезисом из моего поста. 9 из 10 проектов (фич) не повлияют на продукт или будут иметь отрицательный эффект, что снижает ценность рассказа о них. Вы можете с этим не согласиться и привести аргументы против, ведь в негативном опыте тоже есть польза. Но в резюме «я уронил Retention на 30%» вряд ли кто-то станет писать.
При этом у разработчика все 10 из 10 фич будут сильными, потому что каждая из них была реализована (в этом и состоит задача разработчика).
Плюсую! Постмодерн, симулякры и прочий Бодрийяр)
При прочих равных потребитель выберет тот курс, создатели которого
больше врутобещают больший результат меньшими усилиями. Онлайн-школа не может не приукрашивать реальность, если она хочет конкурировать.Со временем реальность искажается больше: кто-то первым начинает приукрашивать чуть сильнее, остальные подтягиваются до этого уровня — и вот уже будущим разрабам обещают 300k в наносекунду за работу, с которой якобы и дурак справится.
Продакт действительно почти всегда работает больше, чем с одним разработчиком. Но я не понял, как это опровергает тейк из поста.
Допустим, продакт клепает продуктовые изменения вместе с 20 разработчиками, 1 из 10 изменений приносит пользу. За 10 изменений продакт получил +1 в карму на рынке труда, каждый разработчик — +10.
Если продуктовых изменений больше, то и работы продакт выполняет больше — я же тут не про загруженность/недозагруженность, а про сам принцип) За участие в одном продуктовом изменении продакт получает конвертируемого в деньги опыта меньше, чем команда — потому что его оценивают по результатам.
Ну и здесь явно смешаны роли проджекта и продакта. В укомплектованной команде за завершённость и качество (если под качеством понимать соответствие ТЗ) отвечает проджект. Ответственность продакта на уровень выше — он отвечает за то, чтобы выпущенный продукт сработал в бизнесовом смысле. Привлёк новых пользователей, принёс деньги — в зависимости от того, что нужно компании сейчас.
Кажется, что если спрашивать у инженера как построить ракету — это уже экспертная оценка, а не опрос.
Ламповая завязка! Почему-то вспомнилась Persona, что ни разу не минус — достойный ориентир. Правда, там за ошибки игра наказывает (да ещё как).
Подруга закончила длительные курсы по бэкенду, но стартовая галера особо не ищется. Говорит, что сейчас у джунов принято сбиваться в стайки и вместе пилить небольшой проект под бизнес чьих-то родственников.
Помогает ли это найти работу потом — точно не знаю, слежу за подругой)
Да, разумно. Вспомнил про книжку «Тирания показателей», в своё время она помогла мне понять, почему работу с метриками вредно сводить к KPI. Обзор
Передам команде, ребята точно порадуются)
Воронки отработают корректно: система затрекает глубину доскролла и отдельно время, чтобы посчитать дочтение. Если дело происходит в несколько сеансов — мы учтём только самое длительное и глубокое прочтение.
Но тут важно понимать, что воронки не показывают распределение внимания по частям статьи — для этого используются другие, более сложные системы (вроде яндексовского Вебвизора). То есть воронка дочтений ни при каких условиях не покажет, что дочтение 3/4 было больше, чем 2/4. Даже если по факту юзеры проскроллили кусок 2/4, но два раза внимательно прочитали 3/4.
Задача воронок другая — показать, в каком месте читатели отвалились (совсем перестали скроллить или читать). С этим наша система справляется отлично.
В будущем хотелось бы разработать условную тепловую карту, чтобы было видно, какие части статьи читались особенно внимательно. Но впереди долгий путь)
Пока читал коммент, в голове всплыл тот самый голос) Но вообще есть такая опасность.
Поэтому доступ к данным по всем публикациям мы никому давать не планируем. Понаобучают моделей, а статей от тёплых ламповых человеков не дождёшься потом.
В планах есть, в обозримом будущем добавим)
На то и расчёт) А вообще да, некоторые фичи мы анонсируем с задержкой, чтобы была возможность проверить на проде.
Так что внимательное использование Хабра вознаграждается. Иногда можно узнать о чём-то интересном раньше других)
Будет, но позже. Полный набор параметров мы начали собирать только 25 мая — чтобы прикинуть ориентиры, нужно накопить данные.
Как посчитаем для себя, обязательно поделимся. И статью на Хабр запилим, и в интерфейсе статистики подсказки оставим)
Пошёл в комменты, чтобы написать о том же самом. В общем, как всегда всё сводится к поиску баланса между чётко отлаженными процессами и здоровым рабочим задором.
Но читать статьи про нормальных людей не очень интересно)
Доказательство того, что Оби-Ван — ситх
Получается не совсем так, ведь есть прочитавшие не до конца. По идее их тоже нужно учитывать (за вычетом тех, кто дочитал до конца).
Но логика понятна, на выходе должен получиться показатель в духе «среднее количество прочитанных знаков». И больше он будет у крайне увлекательного лонгрида, да.
Примеров таких статей у меня пока нет, данные собираются с 25 мая — маловато, чтобы объективно оценить. Но потом примеры найдутся и мы наверняка включим их в золотой фонд где-нибудь в хелпе Хабра)
Момент: ниже 60 знаков в секунду. Если что, придумали не мы — это стандарт индустрии.
Скорость считаем по всей части статьи, которую доскроллил пользователь. Учитываем только время, когда во вьюпорте находился текст. То есть если пользователь уходит на другую вкладку — мы это понимаем и трекаем правильно.
В примере с бутербродами статистика действительно портится. Через некоторое время мы поймём, что пользователь ушёл, но не сразу. К счастью, на тысячах прочтений влияние таких случаев минимально. Бороться с этим можно, но есть риск, что начнутся перекосы в статистике по читателям, которые за бутербродом не пошли)
smells like баг, проверим