Тестировщики не должны находить баги
Читаю сейчас книгу Мартина о правильных программистах. Вообще, Мартин весёлый дядька — обожает категоричные утверждения, прямо как я. Но тут превзошёл сам себя: тестировщики, мол не должны ничего находить! На кой они тогда нужны, верно?
На самом деле, мысль его другая: код должен попадать к тестировщику уже тщательно проверенным. И тут я 100% «за».
Сколько раз наблюдал: программист чего-то там наделал, как-то вроде работает, какие-то даже тесты есть. И перебрасывает в тестирование — проверяйте, мол. QA сразу находит баги, программист чинит, QA снова находит, он снова чинит... В тяжёлых случаях это длится неделями.
Мартин прав. Фича здорового человека попадает в тестирование уже проверенной со всех сторон. Все ветки покрыты тестами, проверена производительность, учтены особенности продакшен-среды.
И это тяжело. Постоянно хочется срезать углы и понадеяться на «авось», когда знаешь, что за тобой кто-то проверит. Давите эти гнилые порывы, проверяйте всё сами — как если после вас сразу на прод ツ
Конечно, тестировщик всё равно найдёт баги — просто потому что мыслит иначе, чем разработчик. Но не будет ни бессмысленного пинг-понга, ни продолбов по срокам, ни костылей в коде.
Читаю сейчас книгу Мартина о правильных программистах. Вообще, Мартин весёлый дядька — обожает категоричные утверждения, прямо как я. Но тут превзошёл сам себя: тестировщики, мол не должны ничего находить! На кой они тогда нужны, верно?
На самом деле, мысль его другая: код должен попадать к тестировщику уже тщательно проверенным. И тут я 100% «за».
Сколько раз наблюдал: программист чего-то там наделал, как-то вроде работает, какие-то даже тесты есть. И перебрасывает в тестирование — проверяйте, мол. QA сразу находит баги, программист чинит, QA снова находит, он снова чинит... В тяжёлых случаях это длится неделями.
Мартин прав. Фича здорового человека попадает в тестирование уже проверенной со всех сторон. Все ветки покрыты тестами, проверена производительность, учтены особенности продакшен-среды.
И это тяжело. Постоянно хочется срезать углы и понадеяться на «авось», когда знаешь, что за тобой кто-то проверит. Давите эти гнилые порывы, проверяйте всё сами — как если после вас сразу на прод ツ
Конечно, тестировщик всё равно найдёт баги — просто потому что мыслит иначе, чем разработчик. Но не будет ни бессмысленного пинг-понга, ни продолбов по срокам, ни костылей в коде.
Как стать на порядок умнее
Есть одна вещь, которая огорчает меня в коллегах по отрасли. Встречается она даже у программистов, что уж говорить о других причастных к производству софта специализациях.
Это безответственное использование выражения «на порядок».
Часто, когда человек хочет сказать «намного больше» — говорит «на порядок». Это, видимо, должно придать словам дополнительный «математический» вес:
— Мы добавили на сайт пять всплывающих окон, и конверсия выросла на порядок.
— Новая версия нашего мега-продукта работает на порядок быстрее.
— Я стал применять технику «помидорок», и эффективность увеличилась на порядки.
По определению, «на порядок» — это отличие как минимум в 10 раз. А «на порядки» — минимум в 100 раз.
Если конверсия была 2%, а стала 25% — поздравляю, это действительно «на порядок» (хотя больше похоже на то, что кто-то совсем заврался).
Если мега-продукт заработал в 2 раза быстрее — это «в два раза», а не «на порядок» (если хотите выпендриться — скажите «производительность возросла кратно»).
Если в прошлом месяце на сайт пришло 1000 человек, а в этом 1500 — это «посещаемость выросла на 50%» (или «в полтора раза»), а не «на порядок».
Если эффективность вроде бы возросла, но вы никогда её не мерили, и понятия не имеете, насколько — это «по ощущениям стало лучше», а не «на порядок».
Уверен, что у моих читателей всё в порядке с порядками. Просто наболело.
Есть одна вещь, которая огорчает меня в коллегах по отрасли. Встречается она даже у программистов, что уж говорить о других причастных к производству софта специализациях.
Это безответственное использование выражения «на порядок».
Часто, когда человек хочет сказать «намного больше» — говорит «на порядок». Это, видимо, должно придать словам дополнительный «математический» вес:
— Мы добавили на сайт пять всплывающих окон, и конверсия выросла на порядок.
— Новая версия нашего мега-продукта работает на порядок быстрее.
— Я стал применять технику «помидорок», и эффективность увеличилась на порядки.
По определению, «на порядок» — это отличие как минимум в 10 раз. А «на порядки» — минимум в 100 раз.
Если конверсия была 2%, а стала 25% — поздравляю, это действительно «на порядок» (хотя больше похоже на то, что кто-то совсем заврался).
Если мега-продукт заработал в 2 раза быстрее — это «в два раза», а не «на порядок» (если хотите выпендриться — скажите «производительность возросла кратно»).
Если в прошлом месяце на сайт пришло 1000 человек, а в этом 1500 — это «посещаемость выросла на 50%» (или «в полтора раза»), а не «на порядок».
Если эффективность вроде бы возросла, но вы никогда её не мерили, и понятия не имеете, насколько — это «по ощущениям стало лучше», а не «на порядок».
Уверен, что у моих читателей всё в порядке с порядками. Просто наболело.
Дизайн — это здравый смысл
Чтобы создать хороший интерфейс, дизайнеру требуется:
— 80% здравого смысла,
— 19% знания предметной области,
— 1% дизайн-мышления, дизайн-систем, насмотренности и прочего, про что дизайнеры любят писать статьи на Медиуме.
То есть главное в дизайне — здравый смысл. Чтобы доказать это утверждение, я сделаю «редизайн» популярного приложения Zoom (замена скайпу для видео- и аудио-конференций) с позиции обычного здравомыслящего человека, не дизайнера.
Включаем голову: https://antonz.ru/common-sense-design/
Чтобы создать хороший интерфейс, дизайнеру требуется:
— 80% здравого смысла,
— 19% знания предметной области,
— 1% дизайн-мышления, дизайн-систем, насмотренности и прочего, про что дизайнеры любят писать статьи на Медиуме.
То есть главное в дизайне — здравый смысл. Чтобы доказать это утверждение, я сделаю «редизайн» популярного приложения Zoom (замена скайпу для видео- и аудио-конференций) с позиции обычного здравомыслящего человека, не дизайнера.
Включаем голову: https://antonz.ru/common-sense-design/
Задачка: «очистить» vs «удалить»
На скриншоте интерфейс управления почтовыми ящиками. В контекстном меню есть действия Empty (очистить ящик) и Delete (удалить ящик). Я постоянно их путаю, и удаляю ящики, вместо того, чтобы очистить.
Как бы вы минимально изменили интерфейс, чтобы уменьшить вероятность ошибки?
На скриншоте интерфейс управления почтовыми ящиками. В контекстном меню есть действия Empty (очистить ящик) и Delete (удалить ящик). Я постоянно их путаю, и удаляю ящики, вместо того, чтобы очистить.
Как бы вы минимально изменили интерфейс, чтобы уменьшить вероятность ошибки?
Как отличить «очистить» от «удалить»?
Final Results
13%
Переименовать, чтобы стало понятнее
25%
Сделать Delete красным и добавить ⚠️
4%
Убрать Empty в настройки
58%
Убрать Delete в настройки
Разбор: «очистить» vs «удалить»
Я согласен с большинством — лучше убрать Delete в настройки. Удаление почтового ящика — редкая операция, ей нечего делать в контекстном меню. Empty же используется часто: это тестовая почта, ящики время от времени чистят.
Почему остальные варианты нравятся меньше:
Переименовать, чтобы стало понятнее
Как не переименовывай, оба пункта останутся близкими по смыслу, а значит ошибки никуда не уйдут.
Сделать Delete красным и добавить ⚠️
Это, скорее всего, сработает. Но визуальный акцент на редкой операции — так себе решение.
Убрать Empty в настройки
Этот вариант я специально добавил, чтобы чуть усложнить выбор ツ Думаю, тут всё понятно.
В личку несколько раз прислали ещё один вариант:
Добавить подтверждение на Delete
Оно там и так есть, ничуть не помогает. Подтверждения не работают, потому что для рутинных операций люди их не читают 🤷
Я согласен с большинством — лучше убрать Delete в настройки. Удаление почтового ящика — редкая операция, ей нечего делать в контекстном меню. Empty же используется часто: это тестовая почта, ящики время от времени чистят.
Почему остальные варианты нравятся меньше:
Переименовать, чтобы стало понятнее
Как не переименовывай, оба пункта останутся близкими по смыслу, а значит ошибки никуда не уйдут.
Сделать Delete красным и добавить ⚠️
Это, скорее всего, сработает. Но визуальный акцент на редкой операции — так себе решение.
Убрать Empty в настройки
Этот вариант я специально добавил, чтобы чуть усложнить выбор ツ Думаю, тут всё понятно.
В личку несколько раз прислали ещё один вариант:
Добавить подтверждение на Delete
Оно там и так есть, ничуть не помогает. Подтверждения не работают, потому что для рутинных операций люди их не читают 🤷
Как упростить пользователю жизнь
Давным-давно Дональд Норман написал книгу «Дизайн привычных вещей». Максимум, что обычно из неё помнят люди — обзор дверей с неудобными ручками.
Книга, между тем, чудесная. Например, есть глава про то, как продукт может сделать жизнь человека проще. Там четыре шага, от простого к сложному. Я примерил их на сервисы доставки еды и обнаружил, что до конца пути никто до сих пор не прошёл. А книге 20 лет уже ツ
https://antonz.ru/simplify-users-life/
Давным-давно Дональд Норман написал книгу «Дизайн привычных вещей». Максимум, что обычно из неё помнят люди — обзор дверей с неудобными ручками.
Книга, между тем, чудесная. Например, есть глава про то, как продукт может сделать жизнь человека проще. Там четыре шага, от простого к сложному. Я примерил их на сервисы доставки еды и обнаружил, что до конца пути никто до сих пор не прошёл. А книге 20 лет уже ツ
https://antonz.ru/simplify-users-life/
Задачка: вахтёр
По моим наблюдениям, разработчики (и дизайнеры, в меньшей степени) очень любят запрещать. Я это называю «синдром айти-вахтёра».
Например, есть известная коллективная блог-площадка. Там можно голосовать за статьи, и если случайно ткнуть на голосовалку дважды, получаешь суровое:
> Повторное голосование запрещено
А если нажать много раз — будет чудесная картина, которая изображена на скриншоте. Присмотритесь, у каждого сообщения есть собственный прогресс-бар обратного отсчёта. Инженерный дизайн ツ
Как бы вы поступили с этим сообщением?
По моим наблюдениям, разработчики (и дизайнеры, в меньшей степени) очень любят запрещать. Я это называю «синдром айти-вахтёра».
Например, есть известная коллективная блог-площадка. Там можно голосовать за статьи, и если случайно ткнуть на голосовалку дважды, получаешь суровое:
> Повторное голосование запрещено
А если нажать много раз — будет чудесная картина, которая изображена на скриншоте. Присмотритесь, у каждого сообщения есть собственный прогресс-бар обратного отсчёта. Инженерный дизайн ツ
Как бы вы поступили с этим сообщением?
Что сделаете с «повторное голосование запрещено»?
Final Results
2%
Всё нормально, оставлю так
6%
Оставлю, но только одно
15%
Переформулирую в позитив
9%
Уберу текст, покажу визуально
68%
Задизейблю кнопку, если уже есть голос
Разбор: вахтёр
Приятно видеть такое единодушие ツ Разберём все же варианты:
Всё нормально, оставлю так
Понимаю, жаль отказываться от такой красоты. Там целая система! Мало того, что у каждого сообщения собственный обратный отсчёт. Так ещё если сообщений больше 5, то дополнительные становятся в очередь и выскакивают только после того, как закрылись предыдущие. Кто-то явно потрудился над этим ツ
Но всё же для пользователя сообщение бесполезно.
Переформулирую в позитив
Формулировать сообщение об ошибке в позитиве («вы уже проголосовали» вместо «повторное голосование запрещено») — хорошая мысль, если сообщение действительно нужно. Здесь оно ничем не помогает, так что смысла нет.
Уберу текст, покажу визуально
Подходящий способ для валидации обязательного поля на форме, например. Здесь же нет пользовательской ошибки, повторное голосование никому не мешает, так что сигнализировать о нём не стоит.
Задизейблю кнопку, если уже есть голос
Простой и рабочий вариант. Если человек уже проголосовал «в плюс», то дальнейшие тыки на кнопку можно спокойно игнорировать. Нет ошибки, нет проблемы, все счастливы.
При этом визуально кнопка не должна дизейблиться (становиться серой) — чтобы не смущать человека. Достаточно деактивировать её, то есть игнорировать повторные нажатия.
Снимать голос при повторном тыке
Этот вариант предложили в личке. Мне он не очень нравится. Если бы действие было одно (как лайк в фейсбуке) — да, логично, при повторном нажатии отменять его (снимать лайк).
Но тут в интерфейсе два раздельных действия (плюс и минус). И снимать плюс при повторном нажатии на плюс — нелогично.
Приятно видеть такое единодушие ツ Разберём все же варианты:
Всё нормально, оставлю так
Понимаю, жаль отказываться от такой красоты. Там целая система! Мало того, что у каждого сообщения собственный обратный отсчёт. Так ещё если сообщений больше 5, то дополнительные становятся в очередь и выскакивают только после того, как закрылись предыдущие. Кто-то явно потрудился над этим ツ
Но всё же для пользователя сообщение бесполезно.
Переформулирую в позитив
Формулировать сообщение об ошибке в позитиве («вы уже проголосовали» вместо «повторное голосование запрещено») — хорошая мысль, если сообщение действительно нужно. Здесь оно ничем не помогает, так что смысла нет.
Уберу текст, покажу визуально
Подходящий способ для валидации обязательного поля на форме, например. Здесь же нет пользовательской ошибки, повторное голосование никому не мешает, так что сигнализировать о нём не стоит.
Задизейблю кнопку, если уже есть голос
Простой и рабочий вариант. Если человек уже проголосовал «в плюс», то дальнейшие тыки на кнопку можно спокойно игнорировать. Нет ошибки, нет проблемы, все счастливы.
При этом визуально кнопка не должна дизейблиться (становиться серой) — чтобы не смущать человека. Достаточно деактивировать её, то есть игнорировать повторные нажатия.
Снимать голос при повторном тыке
Этот вариант предложили в личке. Мне он не очень нравится. Если бы действие было одно (как лайк в фейсбуке) — да, логично, при повторном нажатии отменять его (снимать лайк).
Но тут в интерфейсе два раздельных действия (плюс и минус). И снимать плюс при повторном нажатии на плюс — нелогично.
Юлия → Iuliia. Всё о транслитерации
Транслитерация — это запись кириллических слов латиницей (Анна → Anna, Самара → Samara). Её используют в загранпаспортах, водительских удостоверениях, трансграничной доставке, библиотечных каталогах и множестве других международных процессов.
В интерфейсах транслитерацию обычно реализуют как придётся. Взял программист первую попавшуюся в гугле библиотеку (или ещё хуже — сделал свою) и вперёд.
Я недавно окунулся в эту тему, а в Википедии она раскрыта слабо. Поэтому расскажу, что к чему (спойлер — если вы думаете, что с транслитерацией всё плохо, то на самом деле всё ещё хуже).
Как обстоят дела и что с этим делать:
https://antonz.ru/iuliia/
Транслитерация — это запись кириллических слов латиницей (Анна → Anna, Самара → Samara). Её используют в загранпаспортах, водительских удостоверениях, трансграничной доставке, библиотечных каталогах и множестве других международных процессов.
В интерфейсах транслитерацию обычно реализуют как придётся. Взял программист первую попавшуюся в гугле библиотеку (или ещё хуже — сделал свою) и вперёд.
Я недавно окунулся в эту тему, а в Википедии она раскрыта слабо. Поэтому расскажу, что к чему (спойлер — если вы думаете, что с транслитерацией всё плохо, то на самом деле всё ещё хуже).
Как обстоят дела и что с этим делать:
https://antonz.ru/iuliia/
Простой интерфейс
Ещё до того, как пользователь в первый раз запустил программу, у него в голове уже сложилось представление, как она работает.
Если обмануть ожидания — человек будет воспринимать интерфейс как сложный, что вы с ним ни делайте. Не поможет ни онбординг, ни обучающие ролики, ни красочные картинки и игривый текст.
А вот как не обмануть:
https://antonz.ru/simple-ui/
Ещё до того, как пользователь в первый раз запустил программу, у него в голове уже сложилось представление, как она работает.
Если обмануть ожидания — человек будет воспринимать интерфейс как сложный, что вы с ним ни делайте. Не поможет ни онбординг, ни обучающие ролики, ни красочные картинки и игривый текст.
А вот как не обмануть:
https://antonz.ru/simple-ui/
Как человек решает задачи в интерфейсе
Человек взаимодействует с интерфейсом не для того, чтобы насладиться творчеством дизайнеров и программистов. Он решает конкретную задачу. Происходит это в три шага:
1. Сформулировать задачу. Я подписан на один канал в Телеграме. Он хороший, но надоел оповещениями. Хочу их отключить.
2. Выполнить действие. Полагаю, это делается где-то в самом канале. Захожу в ленту, тыкаю на канал. Вижу внизу большую кнопку Mute. Ага, это наверняка она. Нажимаю.
3. Оценить результат. Кнопка изменилась: Mute → Unmute. Рядом с названием канала появилась иконка с перечёркнутым динамиком. Полагаю, оповещения выключены.
На каждом шаге интерфейс может помогать, а может вставлять палки в колёса. Вот как это бывает:
https://antonz.ru/user-actions/
Человек взаимодействует с интерфейсом не для того, чтобы насладиться творчеством дизайнеров и программистов. Он решает конкретную задачу. Происходит это в три шага:
1. Сформулировать задачу. Я подписан на один канал в Телеграме. Он хороший, но надоел оповещениями. Хочу их отключить.
2. Выполнить действие. Полагаю, это делается где-то в самом канале. Захожу в ленту, тыкаю на канал. Вижу внизу большую кнопку Mute. Ага, это наверняка она. Нажимаю.
3. Оценить результат. Кнопка изменилась: Mute → Unmute. Рядом с названием канала появилась иконка с перечёркнутым динамиком. Полагаю, оповещения выключены.
На каждом шаге интерфейс может помогать, а может вставлять палки в колёса. Вот как это бывает:
https://antonz.ru/user-actions/
Аптайм на статус-странице
Есть такая штука у облачных сервисов — «статус-страница». Это отдельный, независимый от основного сайт, на котором написано, работает основной сервис или нет.
Статус-страница полезна, когда основной сервис свалился под ддос-атакой или от веселого пятничного обновления. Так пользователям есть куда пойти, чтобы понять масштаб проблемы и ход решения.
У большинства сервисов статус-страница сделана по такому шаблону:
1. Общий статус (работает / нет)
2. Статус отдельных сервисов (сайт, мобильное приложение, API, ...)
3. Список инцидентов.
Неплохая структура, отвечает на важный вопрос — «что-то сломалось?» Но не отвечает на второй важный вопрос — «насколько вы вообще надежные?».
Удивительно, но сервисы редко раскрывают общие показатели доступности. Хорошо, если покажут за 90 дней, за год — почти никогда.
Я думаю, нормальный подход — показывать доступность за день, неделю, месяц и год.
В любом случае, даже плохая статус-страница лучше, чем никакой. Тем более, что подключить ее несложно — есть куча готовых инструментов. Даже бесплатные, вроде UptimeRobot или Upptime
Рекомендую!
Есть такая штука у облачных сервисов — «статус-страница». Это отдельный, независимый от основного сайт, на котором написано, работает основной сервис или нет.
Статус-страница полезна, когда основной сервис свалился под ддос-атакой или от веселого пятничного обновления. Так пользователям есть куда пойти, чтобы понять масштаб проблемы и ход решения.
У большинства сервисов статус-страница сделана по такому шаблону:
1. Общий статус (работает / нет)
2. Статус отдельных сервисов (сайт, мобильное приложение, API, ...)
3. Список инцидентов.
Неплохая структура, отвечает на важный вопрос — «что-то сломалось?» Но не отвечает на второй важный вопрос — «насколько вы вообще надежные?».
Удивительно, но сервисы редко раскрывают общие показатели доступности. Хорошо, если покажут за 90 дней, за год — почти никогда.
Я думаю, нормальный подход — показывать доступность за день, неделю, месяц и год.
В любом случае, даже плохая статус-страница лучше, чем никакой. Тем более, что подключить ее несложно — есть куча готовых инструментов. Даже бесплатные, вроде UptimeRobot или Upptime
Рекомендую!
Сила комментария
Комментарий в интерфейсе — это необязательное текстовое поле. В комментарии человек указывает любую дополнительную информацию, которая кажется ему важной:
— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге
Комментарии в интерфейсах недооценены. Аналитики, дизайнеры, программисты — все мы любим и умеем систематизировать информацию. Поэтому любой объект в интерфейсе представляем как набор полей с конкретным назначением: наименование, почтовый индекс, стоимость.
Но жизнь всегда богаче моделек. И когда люди используют софт, часто получается, что важная информация есть, а записать ее некуда. Тут и приходит на помощь комментарий.
Например, на работе мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?
Проблема в том, что непонятно, кто заблокировал IP и почему. В большинстве случаев это и неважно, но иногда пригодилось бы для разбора. Решить проблему элементарно — добавить поле «комментарий».
Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:
— точно ли нужны именно эти поля?
— действительно ли они нужны?
Добавлять поля просто «чтобы были» — так себе идея. А выяснить реальные сценарии как раз и поможет поле «комментарий». Потом, если что, можно заменить его на поля с конкретным назначением.
Комментарий — элемент хаоса. Но с ним система устойчивее.
Комментарий в интерфейсе — это необязательное текстовое поле. В комментарии человек указывает любую дополнительную информацию, которая кажется ему важной:
— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге
Комментарии в интерфейсах недооценены. Аналитики, дизайнеры, программисты — все мы любим и умеем систематизировать информацию. Поэтому любой объект в интерфейсе представляем как набор полей с конкретным назначением: наименование, почтовый индекс, стоимость.
Но жизнь всегда богаче моделек. И когда люди используют софт, часто получается, что важная информация есть, а записать ее некуда. Тут и приходит на помощь комментарий.
Например, на работе мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?
Проблема в том, что непонятно, кто заблокировал IP и почему. В большинстве случаев это и неважно, но иногда пригодилось бы для разбора. Решить проблему элементарно — добавить поле «комментарий».
Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:
— точно ли нужны именно эти поля?
— действительно ли они нужны?
Добавлять поля просто «чтобы были» — так себе идея. А выяснить реальные сценарии как раз и поможет поле «комментарий». Потом, если что, можно заменить его на поля с конкретным назначением.
Комментарий — элемент хаоса. Но с ним система устойчивее.
Более быстрая лошадь
Продуктоводы любят цитировать Генри Форда:
Если бы я спросил у людей, чего они хотят, они бы попросили более быструю лошадь [а не автомобиль]
Вывод делается такой, что пользователи, мол, сами не знают, чего им надо.
Кажется, в этой байке очень мало хорошего:
1. «Если бы спросил, они бы попросили». Да откуда ты знаешь? Спроси сначала — мало ли, вдруг ответы тебя удивят.
2. Допустим, реально ответили, что нужна «более быстрая лошадь». Это весьма полезная информация, только надо сфокусироваться на «быстрая», а не «лошадь». Почему важна именно быстрота, а не выносливость, комфорт или там стоимость владения? Что смогут они такого делать, чего раньше не могли? Сразу возникают вопросы, которые помогут увидеть правильное направление.
3. Некоторые пользователи не то что про лошадь не станут рассказать, они сразу затребуют гоночный болид или вообще космический корабль для межзвездных путешествий. Это тоже ценная информация, особенно если за странными желаниями вскроется реальная потребность.
4. Средний продуктовод — далеко не Генри Форд (сорян). Не грех и спросить, корона не свалится.
В общем, я за другую цитату Форда:
Мой секрет успеха заключается в умении понять точку зрения другого человека и смотреть на вещи и с его, и со своей точек зрения.
Продуктоводы любят цитировать Генри Форда:
Если бы я спросил у людей, чего они хотят, они бы попросили более быструю лошадь [а не автомобиль]
Вывод делается такой, что пользователи, мол, сами не знают, чего им надо.
Кажется, в этой байке очень мало хорошего:
1. «Если бы спросил, они бы попросили». Да откуда ты знаешь? Спроси сначала — мало ли, вдруг ответы тебя удивят.
2. Допустим, реально ответили, что нужна «более быстрая лошадь». Это весьма полезная информация, только надо сфокусироваться на «быстрая», а не «лошадь». Почему важна именно быстрота, а не выносливость, комфорт или там стоимость владения? Что смогут они такого делать, чего раньше не могли? Сразу возникают вопросы, которые помогут увидеть правильное направление.
3. Некоторые пользователи не то что про лошадь не станут рассказать, они сразу затребуют гоночный болид или вообще космический корабль для межзвездных путешествий. Это тоже ценная информация, особенно если за странными желаниями вскроется реальная потребность.
4. Средний продуктовод — далеко не Генри Форд (сорян). Не грех и спросить, корона не свалится.
В общем, я за другую цитату Форда:
Мой секрет успеха заключается в умении понять точку зрения другого человека и смотреть на вещи и с его, и со своей точек зрения.
Начни с примера
Главное правило для всех, кто пишет обучающие статьи, курсы и вообще что угодно для начинающих:
>>> Начинайте с примеров, черт возьми <<<
Например, вы решили учить людей SQL. И первым делом подсовываете им такую замечательную схему SQL-запроса, как на картинке к посту. Не, ну а чо. Пусть сразу системному подходу учатся, правда?
Нет.
Начните с простых примерчиков. Расскажите про большую эксельку, которую можно фильтровать и сортировать. Покажите примитивные запросы на табличке из 10 записей. Нарисуйте элементарные картинки или сделайте гифку.
Не нужен начинающим «системный подход». Потом сами к нему придут.
Интересно, что на примере с базовым SQL почти все это понимают. Но стоит взять чуть более сложную тему — и привет. Начинают с многотомной классификации, зубодробительных схем внутреннего устройства и прочей жести. А примеры типа на потом оставим, когда «целостная картина» будет.
Не будет у людей целостной картины. Никакой картины не будет. Пока вы не начнете объяснять на примерах.
Главное правило для всех, кто пишет обучающие статьи, курсы и вообще что угодно для начинающих:
>>> Начинайте с примеров, черт возьми <<<
Например, вы решили учить людей SQL. И первым делом подсовываете им такую замечательную схему SQL-запроса, как на картинке к посту. Не, ну а чо. Пусть сразу системному подходу учатся, правда?
Нет.
Начните с простых примерчиков. Расскажите про большую эксельку, которую можно фильтровать и сортировать. Покажите примитивные запросы на табличке из 10 записей. Нарисуйте элементарные картинки или сделайте гифку.
Не нужен начинающим «системный подход». Потом сами к нему придут.
Интересно, что на примере с базовым SQL почти все это понимают. Но стоит взять чуть более сложную тему — и привет. Начинают с многотомной классификации, зубодробительных схем внутреннего устройства и прочей жести. А примеры типа на потом оставим, когда «целостная картина» будет.
Не будет у людей целостной картины. Никакой картины не будет. Пока вы не начнете объяснять на примерах.
Руководство по визуализации данных
Ребята из Германии сделали классное руководство по визуализации данных и открыли его под лицензией Creative Commons.
А чтобы никто не догадался и не оценил их труд — назвали максимально непонятно и спрятали на сайте в слабочитаемом виде.
Но я все равно нашел!
Поэтому теперь у вас есть бесплатная книга по визуальному представлению данных для отчетов и дашбордов. Подробная (150 страниц) и практическая (197 иллюстраций). В вебе, epub и pdf:
https://antonz.ru/dataviz-guide/
Ребята из Германии сделали классное руководство по визуализации данных и открыли его под лицензией Creative Commons.
А чтобы никто не догадался и не оценил их труд — назвали максимально непонятно и спрятали на сайте в слабочитаемом виде.
Но я все равно нашел!
Поэтому теперь у вас есть бесплатная книга по визуальному представлению данных для отчетов и дашбордов. Подробная (150 страниц) и практическая (197 иллюстраций). В вебе, epub и pdf:
https://antonz.ru/dataviz-guide/
Видение, эмпатия, смелость
Одиннадцать лет назад, весной 2010 года, Adobe Flash был на пике популярности. Adobe построил вокруг этого поделия аж целую платформу, с прицелом на мобильные устройства и встраиваемое ПО.
Флеш был так успешен, что Microsoft еще в 2007 году выкатила конкурента — аналогичную хреновину под названием Silverlight. Борьба намечалась нешуточная.
Apple, владея стремительно набирающей популярность iOS, не могла остаться в стороне. И анонсировала собственную альтернативу флешу — iSlate. Аналогичный шаг сделал и Google. В следующие 10 лет развернулась кровавая битва флешеподобных плагинов, а обычный веб (HTML и JS) остались совсем не у дел.
А, нет. Вычеркните последний абзац. Ничего этого не было, и вот почему.
29 апреля 2010 года Стив Джобс опубликовал открытое письмо под названием «Thoughts on Flash», в котором разгромил флеш и поддержал HTML5. В течение двух следующих лет Adobe Flash и Microsoft Silverlight были уничтожены. Технически они продолжали существовать еще довольно долго, но и разработчики, и сами производители признали, что это тупик.
HTML5, CSS и JS получили такой мощный пинок, что до сих пор не могут остановиться (вот кому мы обязаны мириадами глючных фич веба и армией js-фреймворков). При всех недостатках, веб действительно оказался лучшим выбором, потому что не принадлежал одному монополисту.
Заботился ли Джобс о процветании Apple, когда писал свое письмо? Конечно. Он честно сказал, что благодаря отмиранию флеша Apple продаст больше устройств. Но он также думал и о разработчиках, и о пользователях. Джобс понимал, что ждет нас всех, если индустрия пойдет по пути конкурирующих плагинов вместо развития общей платформы — веба.
Джобс не был ангелом, это уж точно. Но у него было видение, и эмпатия, и смелость. Не будь этого письма в 2010 году — не было бы веба, каким мы его знаем сегодня.
В 2020 году Apple тихо удалила открытое письмо Джобса с сайта компании. Конечно, зачем эти слова про открытый веб — у нынешнего Apple совсем другие приоритеты. Да и у других техногигантов тоже. Очень жаль.
Thoughts on Flash
Одиннадцать лет назад, весной 2010 года, Adobe Flash был на пике популярности. Adobe построил вокруг этого поделия аж целую платформу, с прицелом на мобильные устройства и встраиваемое ПО.
Флеш был так успешен, что Microsoft еще в 2007 году выкатила конкурента — аналогичную хреновину под названием Silverlight. Борьба намечалась нешуточная.
Apple, владея стремительно набирающей популярность iOS, не могла остаться в стороне. И анонсировала собственную альтернативу флешу — iSlate. Аналогичный шаг сделал и Google. В следующие 10 лет развернулась кровавая битва флешеподобных плагинов, а обычный веб (HTML и JS) остались совсем не у дел.
А, нет. Вычеркните последний абзац. Ничего этого не было, и вот почему.
29 апреля 2010 года Стив Джобс опубликовал открытое письмо под названием «Thoughts on Flash», в котором разгромил флеш и поддержал HTML5. В течение двух следующих лет Adobe Flash и Microsoft Silverlight были уничтожены. Технически они продолжали существовать еще довольно долго, но и разработчики, и сами производители признали, что это тупик.
HTML5, CSS и JS получили такой мощный пинок, что до сих пор не могут остановиться (вот кому мы обязаны мириадами глючных фич веба и армией js-фреймворков). При всех недостатках, веб действительно оказался лучшим выбором, потому что не принадлежал одному монополисту.
Заботился ли Джобс о процветании Apple, когда писал свое письмо? Конечно. Он честно сказал, что благодаря отмиранию флеша Apple продаст больше устройств. Но он также думал и о разработчиках, и о пользователях. Джобс понимал, что ждет нас всех, если индустрия пойдет по пути конкурирующих плагинов вместо развития общей платформы — веба.
Джобс не был ангелом, это уж точно. Но у него было видение, и эмпатия, и смелость. Не будь этого письма в 2010 году — не было бы веба, каким мы его знаем сегодня.
В 2020 году Apple тихо удалила открытое письмо Джобса с сайта компании. Конечно, зачем эти слова про открытый веб — у нынешнего Apple совсем другие приоритеты. Да и у других техногигантов тоже. Очень жаль.
Thoughts on Flash
О продуктоводстве
С начала года я окончательно перестал притворяться продакт-менеджером и занимаюсь исключительно техническими штуками. Кажется, это хороший момент, чтобы описать мой опыт создания и развития облачного B2B-сервиса в России.
О чем пишу:
— продукт и фичи
— B2B и кровавый энтерпрайз
— API и документация
— техподдержка
— разработка
— интерфейс
— люди
О чем не пишу:
— маркетинг
— метрики
— касдев
— гроус-хакинг
— эджайл
— что там еще модно у продактов в этом сезоне
https://antonz.ru/productology/
С начала года я окончательно перестал притворяться продакт-менеджером и занимаюсь исключительно техническими штуками. Кажется, это хороший момент, чтобы описать мой опыт создания и развития облачного B2B-сервиса в России.
О чем пишу:
— продукт и фичи
— B2B и кровавый энтерпрайз
— API и документация
— техподдержка
— разработка
— интерфейс
— люди
О чем не пишу:
— маркетинг
— метрики
— касдев
— гроус-хакинг
— эджайл
— что там еще модно у продактов в этом сезоне
https://antonz.ru/productology/