Есть такой забавный парадоксальный эффект, что тот, кто первым начал игру, в каком-то смысле застревает на ее начальных уровнях.
К примеру, в США банковские карты распространены давно, но бесконтактная оплата из-за этого распространена меньше, чем у нас - много старых терминалов, которые этого еще не умеют.
Или вот свежий пример, упорядоченный по убыванию прогрессивности и возрастанию времени игры одновременно:
- в Китае рынок мобильных платежей вырос в 15 раз за 2 года (!) и достиг 15 млрд долларов
- в России при этом население в основном пользуется переводами с карты на карту и терминалами оплаты (qiwi наше национаольное достояние)
- в Германии основной инструмент это банковские переводы (direct debit)
- а в США до сих пор в ходу бумажные чеки
Кто позже всех начал, тот дальше всех ушел.
К примеру, в США банковские карты распространены давно, но бесконтактная оплата из-за этого распространена меньше, чем у нас - много старых терминалов, которые этого еще не умеют.
Или вот свежий пример, упорядоченный по убыванию прогрессивности и возрастанию времени игры одновременно:
- в Китае рынок мобильных платежей вырос в 15 раз за 2 года (!) и достиг 15 млрд долларов
- в России при этом население в основном пользуется переводами с карты на карту и терминалами оплаты (qiwi наше национаольное достояние)
- в Германии основной инструмент это банковские переводы (direct debit)
- а в США до сих пор в ходу бумажные чеки
Кто позже всех начал, тот дальше всех ушел.
В тексте выше был замечен косячок - в реальности рынок мобильных платежей в Китае не миллиарды, а триллионы. Тысячекратненько ошибся
Хотел бы поделиться одной довольно хорошо работающей у нас практикой.
Вот ездят в компании сотрудники на конференции, слушают, мотают на ус... а дальше? Если на конференции окажется "лицо, принимающее решения", да прямо на нужной сессии, да услышит какой-то полезный рецепт - то все хорошо. Но конференции сейчас большие, многопоточные, самих конференций много, всем везде не успеть.
Поэтому применяем простую практику - ретроспектива конференции. После поездки надо заполнить простую таблицу - какой доклад | какая оценка полезности | чем интересен | что хотелось бы применить; Таблицу потом обсуждаем, чтобы дополнить упущенное
Теперь польза:
1) участники выделяют и формулируют главное в услышанном. это очень важный этап в усвоении объемной информации, но мало кто достаточно дисциплинирован чтобы делать это самостоятельно
2) участники обсуждают свои оценки полезности доклада. это вскрывает разность взглядов, создает поле для дискуссии и расширения кругозора
3) не-участники видят какие доклады были наиболее полезны и чем, и могут выбрать какие доклады стоит посмотреть, как только появятся записи (а записи докладов выкладывать сейчас общепринято)
4) отдельное выделение "что хотелось бы применить" позволяет возвращаться к итогам конференции позже и оценивать, а не свалились ли мы в пассивное слушание, когда все всё понимают, но никто ничего не делает
Вот ездят в компании сотрудники на конференции, слушают, мотают на ус... а дальше? Если на конференции окажется "лицо, принимающее решения", да прямо на нужной сессии, да услышит какой-то полезный рецепт - то все хорошо. Но конференции сейчас большие, многопоточные, самих конференций много, всем везде не успеть.
Поэтому применяем простую практику - ретроспектива конференции. После поездки надо заполнить простую таблицу - какой доклад | какая оценка полезности | чем интересен | что хотелось бы применить; Таблицу потом обсуждаем, чтобы дополнить упущенное
Теперь польза:
1) участники выделяют и формулируют главное в услышанном. это очень важный этап в усвоении объемной информации, но мало кто достаточно дисциплинирован чтобы делать это самостоятельно
2) участники обсуждают свои оценки полезности доклада. это вскрывает разность взглядов, создает поле для дискуссии и расширения кругозора
3) не-участники видят какие доклады были наиболее полезны и чем, и могут выбрать какие доклады стоит посмотреть, как только появятся записи (а записи докладов выкладывать сейчас общепринято)
4) отдельное выделение "что хотелось бы применить" позволяет возвращаться к итогам конференции позже и оценивать, а не свалились ли мы в пассивное слушание, когда все всё понимают, но никто ничего не делает
поспорить за пользу/бесполезность конференций можно тут https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ
Тут одни ребята устроили конкурс на решение своей продуктовой боли, а в рамках раскрутки конкурса взяли интервью у членов жюри. В их число входит Константин Горский, бывший главный веб-дизайнер Яндекса, куда его занесло из программистов по профессии и математика по образованию
Такие интервью интересны возможностью как-то "сверить часы" с общим трендом. Из интересных мыслей:
1) поощряйте "соревнование" между продукт менеджером и дизайнером. каждый должен пытаться сделать лучше, бросая некоторый вызов второй стороне.
У нас принцип такой "соревновательности" между сторонами тоже является основопологающим. Это не всегда находит понимание. К примеру, когда мы хотели научить стороны лучше и конструктивнее спорить, один известный тренер сказал, что надо не учить людей спорить, а определить им всем такие полномочия и зоны ответственности, чтобы спорить было не о чем. Иванов сказал, Петров сделал. Пришлось отказаться от его услуг.
2) в дизайне нет места догмам. все правила работают в каких-то ситуацих, и вредны в каких-то других
Думаю, это не только в дизайне так.
3) все время следите за своим пониманием зачем что-то делается, чтобы не завязнуть в ненужных деталях и вернуться к реальности.
У нас в ходу с легкой руки одного менеджера вопрос "Чтобы ЧТО?". Сам факт, что прозвучал такой вопрос, это сигнал проснуться и вернуться в реальность
4) метрики и их оптимизация склонны загонять дизайн в зону локальных минимумов, когда нельзя улучшить ситуацию без того, чтобы ее временно не ухудшить. поэтому метрики-метриками, а иногда требуются воля и вера.
Интересный пример, что дизайн команда в яндексе обходила правила метрик тем, что накапливала запас невнедренных улучшений, который применяли совместно с резким поворотом и тем его "подслащивали" - компенсировали провал от резкого изменения. Видимо, воли и веры не хватало.
Это, наверное, вечная дилемма между сухими цифрами и чувством прекрасного. Цифры не всегда отражают весь спектр ваших ценностей, а чувство прекрасного более полно. С другой стороны, есть куча ситуаций, когда наоборот надо преследовать четкую цель (тут лучше всего работают цифры) и игнорировать отвлеченные вещи.
Горский приводит примеры Амазона и Букинга, которые метрически заоптимизированы до упора, но выглядят ужасно. Но работают и генерируют гору денег. Но выглядят ужасно. Трудный выбор
Интересно, что есть история о том, что главную страницу Амазона дизайнит лично Безос. И однажды он нанял продвинутого профессора ментальных наук, чтобы все это мерить и оптимизировать. Но с профессором пришлось расстаться, поскольку главную страницу Безос все равно правил по своему разумению, а не по умным теориям. Так что может быть в Амазоне тоже есть место чувству прекрасного, просто там чувство такое... особое...
https://www.youtube.com/watch?v=kZz8dJwmH48&index=4&list=WL&t=0s
Такие интервью интересны возможностью как-то "сверить часы" с общим трендом. Из интересных мыслей:
1) поощряйте "соревнование" между продукт менеджером и дизайнером. каждый должен пытаться сделать лучше, бросая некоторый вызов второй стороне.
У нас принцип такой "соревновательности" между сторонами тоже является основопологающим. Это не всегда находит понимание. К примеру, когда мы хотели научить стороны лучше и конструктивнее спорить, один известный тренер сказал, что надо не учить людей спорить, а определить им всем такие полномочия и зоны ответственности, чтобы спорить было не о чем. Иванов сказал, Петров сделал. Пришлось отказаться от его услуг.
2) в дизайне нет места догмам. все правила работают в каких-то ситуацих, и вредны в каких-то других
Думаю, это не только в дизайне так.
3) все время следите за своим пониманием зачем что-то делается, чтобы не завязнуть в ненужных деталях и вернуться к реальности.
У нас в ходу с легкой руки одного менеджера вопрос "Чтобы ЧТО?". Сам факт, что прозвучал такой вопрос, это сигнал проснуться и вернуться в реальность
4) метрики и их оптимизация склонны загонять дизайн в зону локальных минимумов, когда нельзя улучшить ситуацию без того, чтобы ее временно не ухудшить. поэтому метрики-метриками, а иногда требуются воля и вера.
Интересный пример, что дизайн команда в яндексе обходила правила метрик тем, что накапливала запас невнедренных улучшений, который применяли совместно с резким поворотом и тем его "подслащивали" - компенсировали провал от резкого изменения. Видимо, воли и веры не хватало.
Это, наверное, вечная дилемма между сухими цифрами и чувством прекрасного. Цифры не всегда отражают весь спектр ваших ценностей, а чувство прекрасного более полно. С другой стороны, есть куча ситуаций, когда наоборот надо преследовать четкую цель (тут лучше всего работают цифры) и игнорировать отвлеченные вещи.
Горский приводит примеры Амазона и Букинга, которые метрически заоптимизированы до упора, но выглядят ужасно. Но работают и генерируют гору денег. Но выглядят ужасно. Трудный выбор
Интересно, что есть история о том, что главную страницу Амазона дизайнит лично Безос. И однажды он нанял продвинутого профессора ментальных наук, чтобы все это мерить и оптимизировать. Но с профессором пришлось расстаться, поскольку главную страницу Безос все равно правил по своему разумению, а не по умным теориям. Так что может быть в Амазоне тоже есть место чувству прекрасного, просто там чувство такое... особое...
https://www.youtube.com/watch?v=kZz8dJwmH48&index=4&list=WL&t=0s
YouTube
Костя Горский, Intercom, ex-Яндекс, о самых сложных задачах, сильном мнении и конфликтах
Подписывайтесь на канал: https://tg.click/dumik
В рамках образовательного конкурса "Антихайп Продукт" поговорили с Костей о том, что такое продуктовый дизайн, как выстроить отношения между дизайнером и продакт-менеджером (спойлер — через конфликт 😈) и какие…
В рамках образовательного конкурса "Антихайп Продукт" поговорили с Костей о том, что такое продуктовый дизайн, как выстроить отношения между дизайнером и продакт-менеджером (спойлер — через конфликт 😈) и какие…
И как обычно - если кто-то хочет высказаться за Горского, то в чатике https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ
Хорошая статья про разработку CLI интерфейсов.
UX в UI уделяется очень много внимания, но в силу специфики нашего продукта (техническая вещь для инженеров) в какой-то момент мы даже ставили лозунгом, что CLI (и API) также важен, как UI. Не могу похвастаться, что мы достигли небывалых высот, но мы стараемся.
https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46
UX в UI уделяется очень много внимания, но в силу специфики нашего продукта (техническая вещь для инженеров) в какой-то момент мы даже ставили лозунгом, что CLI (и API) также важен, как UI. Не могу похвастаться, что мы достигли небывалых высот, но мы стараемся.
https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46
Medium
12 Factor CLI Apps
CLIs are a fantastic way to build products. Unlike web applications, they take a small fraction of the time to build and are much more…
Закрытие Google+ иллюстрирует подход к решению ситуаций типа «нести тяжело, а бросить жалко».
Гугл держал уже заведомо мертвую и неуспешную соцсеть до тех пор, пока в ней не вскрылся большой баг, а вкладываться в улучшения им уже было не интересно
У нас тоже есть древняя система (магазин подписок), из которого небольшая часть пользователей так и не ушли, какие-то небольшие деньги они продолжали приносить (не лишнее же), сил она не потребляла особо, но сама система была сплошным риском, который нас беспокоил. Устранять риски дорого и чинить их, когда случатся, тоже дорого.
В итоге пришли к соломонову решению под названием «план эвакуации при пожаре». Решили ничего не предотвращать, не улучшать и даже не чинить, а просто стричь купоны до часа Х. Пока не бомбанет. Как только бомбанет, должны были распечатать заготовленный «ПЛАН ЭВАКУАЦИИ». Где заранее расписано, что делать по шагам. Но восстановления в этих шагах нет, есть отправка пользователей в новую систему.
Планом, правда, в чистом виде воспользоваться не пришлось. Не бомбануло, но в итоге всё-таки приняли «политическое» решение о сворачивании сервиса.
Гугл держал уже заведомо мертвую и неуспешную соцсеть до тех пор, пока в ней не вскрылся большой баг, а вкладываться в улучшения им уже было не интересно
У нас тоже есть древняя система (магазин подписок), из которого небольшая часть пользователей так и не ушли, какие-то небольшие деньги они продолжали приносить (не лишнее же), сил она не потребляла особо, но сама система была сплошным риском, который нас беспокоил. Устранять риски дорого и чинить их, когда случатся, тоже дорого.
В итоге пришли к соломонову решению под названием «план эвакуации при пожаре». Решили ничего не предотвращать, не улучшать и даже не чинить, а просто стричь купоны до часа Х. Пока не бомбанет. Как только бомбанет, должны были распечатать заготовленный «ПЛАН ЭВАКУАЦИИ». Где заранее расписано, что делать по шагам. Но восстановления в этих шагах нет, есть отправка пользователей в новую систему.
Планом, правда, в чистом виде воспользоваться не пришлось. Не бомбануло, но в итоге всё-таки приняли «политическое» решение о сворачивании сервиса.
vc.ru
Google закроет соцсеть Google+ для пользователей из-за проблем с защитой данных
По данным WSJ, компания нашла и несколько месяцев скрывала уязвимость, опасаясь ущерба репутации и внимания регуляторов.
Как обычно, по желании обсудить, действует чятик https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ
Компания itrex.ru опубликовала на русском языке широко разошедшуюся картинку о разрыве между тем, чего на самом деле хотят сотрудники, и тем, чего их начальники думают, что они хотят. Да, посмотрите на нее внизу. Там зарплата на 5 месте по оценке сотрудников, а на первом признание и на втором роль в делах компании. Просто рай нематериальной мотивации.
Картинка построена на очень известном исследовании 1946 года Foreman Facts from The Labor Relations Institute of NY и несколько противоречит результатам StackOverflow Survey 2018, где
на 1м месте - зарплата
на 2м месте - используемые технологии
а вопрос признания можно условно подразумевать в офисной культуре, которая только на 4м месте.
И кому верить? Во-первых, достаточно неожиданно увидеть такую организационную бирюзовость аж в 1946м году, где не просто поколение X, а прямо таки XXX. Особенно на контрасте с практичностью 2018 года (где у нас generation Z и бирюзовость должна бы прямо цвести). Во-вторых, вопрос очень важен для практического применения.
Картинка построена на очень известном исследовании 1946 года Foreman Facts from The Labor Relations Institute of NY и несколько противоречит результатам StackOverflow Survey 2018, где
на 1м месте - зарплата
на 2м месте - используемые технологии
а вопрос признания можно условно подразумевать в офисной культуре, которая только на 4м месте.
И кому верить? Во-первых, достаточно неожиданно увидеть такую организационную бирюзовость аж в 1946м году, где не просто поколение X, а прямо таки XXX. Особенно на контрасте с практичностью 2018 года (где у нас generation Z и бирюзовость должна бы прямо цвести). Во-вторых, вопрос очень важен для практического применения.
К счастью, западный мир довольно серьезно вкладывается в исследование подобных вопросов, поэтому нашлось много публикаций, из которых особый интерес представляет анализ серии подобных опросов за разные годы (http://s-space.snu.ac.kr/bitstream/10371/1819/1/sjbv12n1_019.pdf)
В нем мы видим, что опрос 1946 года отличается от последующих. Скажем, в 80е на 1м месте была интересная работа, а в 90е места распределились так:
1) зарплата
2) признание
3) надежность (что не сократят)
4) карьерные возможности
5) интересная работа
Таким образом, мы можем уверенно предполагать, что
А) результаты опросов будут зависеть от места и времени, поэтому если такая информация нужна, то надо делать опрос у себя, а не полагаться на чужие картинки. Чужие картинки это только повод задуматься
и менее уверенно предполагать, что
Б) зарплата и признание - оба важны
В нем мы видим, что опрос 1946 года отличается от последующих. Скажем, в 80е на 1м месте была интересная работа, а в 90е места распределились так:
1) зарплата
2) признание
3) надежность (что не сократят)
4) карьерные возможности
5) интересная работа
Таким образом, мы можем уверенно предполагать, что
А) результаты опросов будут зависеть от места и времени, поэтому если такая информация нужна, то надо делать опрос у себя, а не полагаться на чужие картинки. Чужие картинки это только повод задуматься
и менее уверенно предполагать, что
Б) зарплата и признание - оба важны
Обсудить и поспорить можно в чате https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ
Попалась статья про среднее время восстановления после отвлечения на свежее письмо. Компания отмониторила активность 15 своих сотрудников и установила, что
- 70% писем открывались за 6 секунд от появления уведомления
- после прерывания на письмо работа восстанавливалась в среднем через 64 секунды (но в зависимости от характера работы - до 260 секунд); Это именно потеря уже после обработки и собственно письма (прочтения и ответа)
В этом контексте, переход от проверки почты каждые 5 минут на каждые 30 минут может сохранить полтора часа в день на схлапывании всех восстановлений в одно.
У меня лично попап-уведомления по заветам дорофеева отключены и я просто рефлекторно проверяю почту достаточно регулярно, но в удобные мне моменты времени.
Исследование также предлагает использовать SMS (ныне мессенджеры) в предположении, что короткие сообщения отвлекают меньше - но экспериментального подтверждения этому они не приводят, только результаты опроса по субъективной оценке
https://jamesclear.com/wp-content/uploads/2015/02/email-multitasking-study.pdf
- 70% писем открывались за 6 секунд от появления уведомления
- после прерывания на письмо работа восстанавливалась в среднем через 64 секунды (но в зависимости от характера работы - до 260 секунд); Это именно потеря уже после обработки и собственно письма (прочтения и ответа)
В этом контексте, переход от проверки почты каждые 5 минут на каждые 30 минут может сохранить полтора часа в день на схлапывании всех восстановлений в одно.
У меня лично попап-уведомления по заветам дорофеева отключены и я просто рефлекторно проверяю почту достаточно регулярно, но в удобные мне моменты времени.
Исследование также предлагает использовать SMS (ныне мессенджеры) в предположении, что короткие сообщения отвлекают меньше - но экспериментального подтверждения этому они не приводят, только результаты опроса по субъективной оценке
https://jamesclear.com/wp-content/uploads/2015/02/email-multitasking-study.pdf
В ленте пролетело отличное исследование о влиянии опенспейса на коммуникации. Сейчас индустрия на перегибе - с одной стороны openspace это все ещё считается «модно и современно», а с другой многим оно не нравится и голоса против опенспейса ширятся. Но это мнение, а тут суровые данные.
Итак, в одной конторе сделали опенспейс на 100+ сотрудников и исследователи повесили на всех сотрудников устройства, которые позволяют учитывать кто с кем как долго общался лицом к лицу. И получили доступ к серверам, чтобы снимать интенсивность электронных коммуникаций.
Получилось внезапно, что длительность общения лицом к лицу сократилось на 72%, а объём отправляемой почты вырос на 56%. Во другой компании длительность живого общения упала на 67%, а объём почты вырос где-то между 22 и 50% (две разные модели подсчёта).
http://rstb.royalsocietypublishing.org/content/373/1753/20170239
Итак, в одной конторе сделали опенспейс на 100+ сотрудников и исследователи повесили на всех сотрудников устройства, которые позволяют учитывать кто с кем как долго общался лицом к лицу. И получили доступ к серверам, чтобы снимать интенсивность электронных коммуникаций.
Получилось внезапно, что длительность общения лицом к лицу сократилось на 72%, а объём отправляемой почты вырос на 56%. Во другой компании длительность живого общения упала на 67%, а объём почты вырос где-то между 22 и 50% (две разные модели подсчёта).
http://rstb.royalsocietypublishing.org/content/373/1753/20170239
royalsocietypublishing.org
The impact of the ‘open’ workspace on human collaboration | Philosophical Transactions of the Royal Society B: Biological Sciences
Organizations’ pursuit of increased workplace collaboration has led managers to transform traditional office spaces into ‘open’, transparency-enhancing architectures with fewer walls, doors and oth...
Обсудить и поспорить можно в чате https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ
Сижу на AWS re:Invent, масштабной конференции от Amazon. Пишу прямо из «горящего танка» - с 3х часовой keynote сессии, на которой 33 тысячи человек сидят прямо в главном зале.
В этом году Amazon вдарил по
- файловым хранилищам
- базам данных и data lakes
- инструментам центрального контроля и управления доступом к сервисам и их безопасностью
- блокчейну
Не знаю пока, как относиться к поддержке амазоном блокчейна. С одной стороны - Амазон очень сильно внутри как стартап, а значит - почему бы и не попробовать. Не все сервисы Амазона взлетают одинаково хорошо. С другой стороны, это определенное признание технологии и спроса на неё для прикладных целей. С третьей, сразу за блокчейном Амазон анонсировал Quantum Ledger DataBase - надежную БД для ситуации с central authority, то есть классический инструмент, обратный блокчейну.
Интересными темами кажутся подключение живых людей «как сервис» в machine learning для улучшения качества (SageMaker Ground Truth), создания открытой биржи алгоритмов, обучение с подкреплением (SageMaker RI)
Тема с обученным гоночным автомобилем не озвучена прямо как заявка на решение для самоуправляемых авто, но выглядит как жирный намёк
Под конец выкатились довольно интересные сервисы типа
- Textract, распознавание текста с учетом столбцов, таблиц и сложно скомпонованных анкет-форм
- Personalize, готовый рекомендатель товаров на основе амазоновского внутреннего решения. Нетепловой самому разбираться с ML
- Forecast, готовый предсказатель спроса, тоже на основе амазоновского внутреннего решения
Это интересно не только технологически, но ещё это более коробочные, более конечнопользовательские решения, чем просто инфраструктура. Выглядит так, что Амазон может начать делать конструктор решений для бизнеса
В целом этот год выглядит не таким волшебным, как 2016, где AWS запустила пачку ИИ сервисов, легендарный «камаз с компакт-дисками» и Lightsail (“DigitalOcean” от AWS) и дала возможность делать SQL запросы прямо к файлам в S3.
И не таким, как в 2017, где Amazon подписался за Kubernetes, дал Fargate и дал Machine Learning сервисы.
Для меня выглядит как ряд интересных улучшений везде понемногу, но без прорывов.
В этом году Amazon вдарил по
- файловым хранилищам
- базам данных и data lakes
- инструментам центрального контроля и управления доступом к сервисам и их безопасностью
- блокчейну
Не знаю пока, как относиться к поддержке амазоном блокчейна. С одной стороны - Амазон очень сильно внутри как стартап, а значит - почему бы и не попробовать. Не все сервисы Амазона взлетают одинаково хорошо. С другой стороны, это определенное признание технологии и спроса на неё для прикладных целей. С третьей, сразу за блокчейном Амазон анонсировал Quantum Ledger DataBase - надежную БД для ситуации с central authority, то есть классический инструмент, обратный блокчейну.
Интересными темами кажутся подключение живых людей «как сервис» в machine learning для улучшения качества (SageMaker Ground Truth), создания открытой биржи алгоритмов, обучение с подкреплением (SageMaker RI)
Тема с обученным гоночным автомобилем не озвучена прямо как заявка на решение для самоуправляемых авто, но выглядит как жирный намёк
Под конец выкатились довольно интересные сервисы типа
- Textract, распознавание текста с учетом столбцов, таблиц и сложно скомпонованных анкет-форм
- Personalize, готовый рекомендатель товаров на основе амазоновского внутреннего решения. Нетепловой самому разбираться с ML
- Forecast, готовый предсказатель спроса, тоже на основе амазоновского внутреннего решения
Это интересно не только технологически, но ещё это более коробочные, более конечнопользовательские решения, чем просто инфраструктура. Выглядит так, что Амазон может начать делать конструктор решений для бизнеса
В целом этот год выглядит не таким волшебным, как 2016, где AWS запустила пачку ИИ сервисов, легендарный «камаз с компакт-дисками» и Lightsail (“DigitalOcean” от AWS) и дала возможность делать SQL запросы прямо к файлам в S3.
И не таким, как в 2017, где Amazon подписался за Kubernetes, дал Fargate и дал Machine Learning сервисы.
Для меня выглядит как ряд интересных улучшений везде понемногу, но без прорывов.
