Amazon запатентовал Airborne Fulfillment Center - дирижабль-склад с дронами, которые доставляют вам всякие повседневности. До создания Space Fulfillment Center (aka Death Star) оставалось уже недолго.
https://patents.google.com/patent/US9305280B1/en
https://patents.google.com/patent/US9305280B1/en
Очень давно не писал в канал, а тем временем прошла конференция CofeFestX в Новосибирске. Мероприятие огненного масштаба для нашей деревни. Как у знатного старпера, у меня есть свои нудные претензии по содержанию отдельных докладов или секций, но кому они интересны... Зато может быть вам интересно, какую пользу я выношу с посещения докладов, а я их выношу как минимум ТРИ. Поэтому в моем блокнотике по ходу доклада я пишу в ТРИ столбца:
1) если доклад интересен по содержанию, то все просто - конспектируем содержание, фотографируем слайды и всячески самообразовываемся. Я ранее писал про нашу практику делиться выводами с доклада на всю контору (https://yangx.top/program_man/47). Это я пишу в центральный столбец.
Часто бывает, что доклад не так уж интересен лично мне - то есть я лично не узнаю ничего нового, но содержит отличный обзор какой-то темы. Тогда я его могу приспособить как методическое пособие для кого-то в команде. "А посмотри-ка доклад вот такого-то и все поймешь!". Благо, что сейчас очень многие раскрученные компании и их докладчики вкладываются именно в такие, по хорошему капитанские доклады, а не в передовой край науки.
Еще часть докладов не интересна мне, но позволяет увидеть уровень интереса аудитории к теме и ее информированности. Это потом пригодится, когда на конференцию поедут наши докладчики 🙂 Уже понятно, какой материал мог бы быть интересен и востребован
2) если доклад интересен (или не интересен) по форме, то смотрю и записываю приемы докладчика и реакцию аудитории. это потом очень пригождается, когда опять же придет время выступать нашим докладчикам. Зачем повторять чужие ошибки? Это я пишу в левый столбец.
3) а еще многие доклады каким-то образом провоцирует у меня гору мыслей на всякие окольные слабосвязанные с докладом темы, которые я пишу в самый ценный правый столбец, и потом с воодушевлением бегу делать.
Кстати, в платном ютубе есть опция сохранять видео оффлайн. После публикации записей, очень удобно докачать все пропущенные хорошие доклады и посмотреть в долгих перелетах. До Москвы и обратно - это 8 полновесных докладов с вопросами. Вроде летел на одну конференцию, а получил ДВЕ! А самые интересные пропущенные доклады легко выбрать благодаря все тем же нашим внутренним ретроспективам конференций 🙂
И кстати, оказалось, что многие умные люди вообще не смотрят на конференции доклады, а знакомятся и общаются, что может оказаться намного полезнее. В сочетании с практикой смотреть доклады в записи, можно перейти на 200% КПД с каждой конференции, но я так еще не пробовал
1) если доклад интересен по содержанию, то все просто - конспектируем содержание, фотографируем слайды и всячески самообразовываемся. Я ранее писал про нашу практику делиться выводами с доклада на всю контору (https://yangx.top/program_man/47). Это я пишу в центральный столбец.
Часто бывает, что доклад не так уж интересен лично мне - то есть я лично не узнаю ничего нового, но содержит отличный обзор какой-то темы. Тогда я его могу приспособить как методическое пособие для кого-то в команде. "А посмотри-ка доклад вот такого-то и все поймешь!". Благо, что сейчас очень многие раскрученные компании и их докладчики вкладываются именно в такие, по хорошему капитанские доклады, а не в передовой край науки.
Еще часть докладов не интересна мне, но позволяет увидеть уровень интереса аудитории к теме и ее информированности. Это потом пригодится, когда на конференцию поедут наши докладчики 🙂 Уже понятно, какой материал мог бы быть интересен и востребован
2) если доклад интересен (или не интересен) по форме, то смотрю и записываю приемы докладчика и реакцию аудитории. это потом очень пригождается, когда опять же придет время выступать нашим докладчикам. Зачем повторять чужие ошибки? Это я пишу в левый столбец.
3) а еще многие доклады каким-то образом провоцирует у меня гору мыслей на всякие окольные слабосвязанные с докладом темы, которые я пишу в самый ценный правый столбец, и потом с воодушевлением бегу делать.
Кстати, в платном ютубе есть опция сохранять видео оффлайн. После публикации записей, очень удобно докачать все пропущенные хорошие доклады и посмотреть в долгих перелетах. До Москвы и обратно - это 8 полновесных докладов с вопросами. Вроде летел на одну конференцию, а получил ДВЕ! А самые интересные пропущенные доклады легко выбрать благодаря все тем же нашим внутренним ретроспективам конференций 🙂
И кстати, оказалось, что многие умные люди вообще не смотрят на конференции доклады, а знакомятся и общаются, что может оказаться намного полезнее. В сочетании с практикой смотреть доклады в записи, можно перейти на 200% КПД с каждой конференции, но я так еще не пробовал
Telegram
Products | People | Process
Хотел бы поделиться одной довольно хорошо работающей у нас практикой.
Вот ездят в компании сотрудники на конференции, слушают, мотают на ус... а дальше? Если на конференции окажется "лицо, принимающее решения", да прямо на нужной сессии, да услышит какой…
Вот ездят в компании сотрудники на конференции, слушают, мотают на ус... а дальше? Если на конференции окажется "лицо, принимающее решения", да прямо на нужной сессии, да услышит какой…
В Китае на 10 тысяч школьников надели экспериментальный цифровой браслет, который считывает активность мозга, чтобы отследить степень вовлечённости в учебный процесс и эффективность преподавания.
А теперь вспомним про компании, которые любят следить за производительностью сотрудников по скриншотам экрана, клавиатуре и мышке. Это же какие перспективы открываются по оптимизации производительности персонала ...
https://www.inkstonenews.com/tech/brainco-startup-tests-brain-reading-headbands-chinese-schoolkids/article/3005502
А теперь вспомним про компании, которые любят следить за производительностью сотрудников по скриншотам экрана, клавиатуре и мышке. Это же какие перспективы открываются по оптимизации производительности персонала ...
https://www.inkstonenews.com/tech/brainco-startup-tests-brain-reading-headbands-chinese-schoolkids/article/3005502
South China Morning Post
HK, China, Asia news & opinion from SCMP’s global edition | South China Morning Post
Your source for credible news and authoritative insights from Hong Kong, China and the world.
В интернете бушует шторм, что Джек Ма рассказал о "благословлении работать 6 дней по 12 часов". Кто-то топит, что он прав - "надо работать, а не ныть", кто-то топит, что "это рабство".
Мое же отношение к подобным морально противоречивым подходам в том, что в эволюции и рынке нет правых и виноватых, а есть только естественный отбор. Если в Алибабе люди работают 72 часа в неделю и это работает (лучше возможных альтернатив) - то все хорошо. Если это не работает и они загнутся - то плохо. Нет в этом ни логики, ни справедливости, есть только сложное стечение множества факторов, которые все вместе приводят к успеху или поражению и отделить один от другого возможно не всегда.
Наше "нравится" или "не нравится" не играют особой роли. С таким же успехом может не нравится зима или дождь. Роль играет только наша способность массово предпринять какое-то противодействие.
Могут ли сотрудники Алибабы разбежаться кто куда? Маловероятно. В Китае формула "фигачить 996" (с 9 утра до 9 вечера 6 дней в неделю) очень популярна по отзывам. Образ жизни офисных сотрудников массово под это подстроен - есть рынок доставки не только товаров, но и услуг - стрижки и массаж на дом, еда на дом, товары на дом. Ходить по магазинам и ресторанам некогда. у Alibaba главный конкурент на рынке доставки услуг это компания Meituan - 15 миллионов доставленных услуг в сутки, как сообщают. Из 996 можно уйти в другой 996.
А вот когда Alibaba не сможет далее продолжать эту стратегию, они ее естественным образом сменят или вымрут.
Наше отношение к практикам Alibaba в далеком Китае ничего не значит. Он может нам не нравится - но никто же и не планировал ехать в Китай работать? А может кому-то он нравится, может кто-то фанат фигачить и хочет, чтобы у него тоже трудились по схеме 996 - йо-хо-хо, добро пожаловать в столкновение ваших желаний и рынка труда. Известен скандал с Revolut и их гонкой за достижениями любой ценой. На этом рынке, похоже, такое поведение не проходит и приходится меняться. Не секрет, что лет 15 назад, когда мы входили в холдинг SWsoft, постоянные авралы и сверхурочные создали нам очень дурную славу, которая тянулась за нами не менее 5 лет после полного прекращения такой выматывающей практики. Но прекратилась эта практика только тогда, когда ее разрушительное воздействие стало очевидно и измеримо - люди увольнялись, людей было трудно нанять. Пока эта практика работала, она продолжалась не взирая на то, как сильно она не нравилась людям внутри и снаружи компании. Но это не значит, что при должной мотивации в какой-то другой компании такая практика не возникнет снова.
К счастью, сейчас рынок труда в РФ довольно хорош для ИТшников - это рынок с дефицитным предложением и поэтому компании стараются делать хорошие условия для сотрудников не в силу внутренней хорошести, а в силу объективных причин. Поэтому Alibaba-йный подход здесь особо не грозит.
Мое же отношение к подобным морально противоречивым подходам в том, что в эволюции и рынке нет правых и виноватых, а есть только естественный отбор. Если в Алибабе люди работают 72 часа в неделю и это работает (лучше возможных альтернатив) - то все хорошо. Если это не работает и они загнутся - то плохо. Нет в этом ни логики, ни справедливости, есть только сложное стечение множества факторов, которые все вместе приводят к успеху или поражению и отделить один от другого возможно не всегда.
Наше "нравится" или "не нравится" не играют особой роли. С таким же успехом может не нравится зима или дождь. Роль играет только наша способность массово предпринять какое-то противодействие.
Могут ли сотрудники Алибабы разбежаться кто куда? Маловероятно. В Китае формула "фигачить 996" (с 9 утра до 9 вечера 6 дней в неделю) очень популярна по отзывам. Образ жизни офисных сотрудников массово под это подстроен - есть рынок доставки не только товаров, но и услуг - стрижки и массаж на дом, еда на дом, товары на дом. Ходить по магазинам и ресторанам некогда. у Alibaba главный конкурент на рынке доставки услуг это компания Meituan - 15 миллионов доставленных услуг в сутки, как сообщают. Из 996 можно уйти в другой 996.
А вот когда Alibaba не сможет далее продолжать эту стратегию, они ее естественным образом сменят или вымрут.
Наше отношение к практикам Alibaba в далеком Китае ничего не значит. Он может нам не нравится - но никто же и не планировал ехать в Китай работать? А может кому-то он нравится, может кто-то фанат фигачить и хочет, чтобы у него тоже трудились по схеме 996 - йо-хо-хо, добро пожаловать в столкновение ваших желаний и рынка труда. Известен скандал с Revolut и их гонкой за достижениями любой ценой. На этом рынке, похоже, такое поведение не проходит и приходится меняться. Не секрет, что лет 15 назад, когда мы входили в холдинг SWsoft, постоянные авралы и сверхурочные создали нам очень дурную славу, которая тянулась за нами не менее 5 лет после полного прекращения такой выматывающей практики. Но прекратилась эта практика только тогда, когда ее разрушительное воздействие стало очевидно и измеримо - люди увольнялись, людей было трудно нанять. Пока эта практика работала, она продолжалась не взирая на то, как сильно она не нравилась людям внутри и снаружи компании. Но это не значит, что при должной мотивации в какой-то другой компании такая практика не возникнет снова.
К счастью, сейчас рынок труда в РФ довольно хорош для ИТшников - это рынок с дефицитным предложением и поэтому компании стараются делать хорошие условия для сотрудников не в силу внутренней хорошести, а в силу объективных причин. Поэтому Alibaba-йный подход здесь особо не грозит.
vc.ru
Цитата: основатель Alibaba о реакции соцсетей на его слова про 12-часовой рабочий день — Карьера на vc.ru
Ранее миллиардер заявил, что работа по графику «996» — это «благословение».
Был сильно занят и ничего не писал, в частности потому, что весной много конференций, сам в разъездах и все в разъездах. Компенсирую очередным капитанским соображением о том, а зачем инженерам ездить на конференции? Даже еще точнее, а зачем компании, чтобы инженеры ездили на конференции? У нас некоторые волнуются, зачем мы на это "тратим народные деньги"
Помимо очевидной охоты за готовыми чужими рецептами, инженеры ездят на конференции, чтобы:
1) Расширять кругозор. Недостаточно просто пилить, и даже недостаточно регулярно точить пилу - надо знать как лучше всего точить и где лучше всего пилить. Наивно полагать, что ты самый умный и придумаешь оптимальное решение под задачу. Вокруг нас методом проб и ошибок движется технологическая эволюция, поэтому надо смотреть по сторонам и собирать чужой лучший опыт.
2) Расшатывать устои. Можно играть игру в "босс самый умный, остальные следуют за ним", но тогда сталкиваешься со всеми прелестями сопротивления изменениям. Можно дать людям посмотреть на других, захотеть изменений. Тогда самым умным выглядеть уже не будешь, но зато изменять ситуацию будет в разы проще.
3) Избавляться от комплексов. Инженеры - люди самокритичные и склонны впадать в состояние "у нас все плохо, а где-то далеко все хорошо". Прослушав доклады из других компаний (а общий уровень пока не такой уж высокий), люди понимают, что у них на работе кое-что существенно лучше, чем им рассказывают со сцены. А значит повышается самооценка, удовлетворение от своей работы и все такое.
Люди становятся грамотнее, гибче и больше любят свою работу. Сплошная выгода.
А зачем компании, чтобы инженеры выступали на конференции?
1) Открытость. Это несколько больше, чем рекламная поддержка найма. Даже наоборот - люди сейчас умные и не верят откровенной рекламе, но хотят понимать, куда они нанимаются. Рассказать о каких-то конкретных задачах, дать задать вопросы, выдержать критику - это неплохой способ показать себя.
2) Полнота понимания. Знаете анекдот про молодого преподавателя, который так долго объяснял студентам какую-то тему, что даже сам понял? Так вот - обучение (а доклад это форма обучения) заставляет понять тему намного лучше, чем если просто чем-то позаниматься. Когда объясняешь другим - лучше понимаешь сам.
3) Критичность. Больше всего проблем в нашем продукте я находил не когда им пользовался для себя, а когда готовил рассказ о нем для других. Сам можешь привыкнуть не замечать кочек и ухабов, но когда рассказываешь и пишешь "здесь пригнешься, там подпрыгнешь", то понимаешь, что какая-то фигня происходит, а не user experience. Также и с докладом - навык что-то рассказать другим формирует более критичный взгляд на то, что делаешь. Делаешь чище, вдумчивее, правильнее. Потому что могут спросить и надо суметь ответить.
Сделаешь доклад - и сам лучше работать будешь, и к тебе более лучшие люди потянутся. Опять же выгода
Помимо очевидной охоты за готовыми чужими рецептами, инженеры ездят на конференции, чтобы:
1) Расширять кругозор. Недостаточно просто пилить, и даже недостаточно регулярно точить пилу - надо знать как лучше всего точить и где лучше всего пилить. Наивно полагать, что ты самый умный и придумаешь оптимальное решение под задачу. Вокруг нас методом проб и ошибок движется технологическая эволюция, поэтому надо смотреть по сторонам и собирать чужой лучший опыт.
2) Расшатывать устои. Можно играть игру в "босс самый умный, остальные следуют за ним", но тогда сталкиваешься со всеми прелестями сопротивления изменениям. Можно дать людям посмотреть на других, захотеть изменений. Тогда самым умным выглядеть уже не будешь, но зато изменять ситуацию будет в разы проще.
3) Избавляться от комплексов. Инженеры - люди самокритичные и склонны впадать в состояние "у нас все плохо, а где-то далеко все хорошо". Прослушав доклады из других компаний (а общий уровень пока не такой уж высокий), люди понимают, что у них на работе кое-что существенно лучше, чем им рассказывают со сцены. А значит повышается самооценка, удовлетворение от своей работы и все такое.
Люди становятся грамотнее, гибче и больше любят свою работу. Сплошная выгода.
А зачем компании, чтобы инженеры выступали на конференции?
1) Открытость. Это несколько больше, чем рекламная поддержка найма. Даже наоборот - люди сейчас умные и не верят откровенной рекламе, но хотят понимать, куда они нанимаются. Рассказать о каких-то конкретных задачах, дать задать вопросы, выдержать критику - это неплохой способ показать себя.
2) Полнота понимания. Знаете анекдот про молодого преподавателя, который так долго объяснял студентам какую-то тему, что даже сам понял? Так вот - обучение (а доклад это форма обучения) заставляет понять тему намного лучше, чем если просто чем-то позаниматься. Когда объясняешь другим - лучше понимаешь сам.
3) Критичность. Больше всего проблем в нашем продукте я находил не когда им пользовался для себя, а когда готовил рассказ о нем для других. Сам можешь привыкнуть не замечать кочек и ухабов, но когда рассказываешь и пишешь "здесь пригнешься, там подпрыгнешь", то понимаешь, что какая-то фигня происходит, а не user experience. Также и с докладом - навык что-то рассказать другим формирует более критичный взгляд на то, что делаешь. Делаешь чище, вдумчивее, правильнее. Потому что могут спросить и надо суметь ответить.
Сделаешь доклад - и сам лучше работать будешь, и к тебе более лучшие люди потянутся. Опять же выгода
На неделе CodeFest выложил записи докладов https://www.youtube.com/user/codefestru/playlists?shelf_id=6
Рискну порекомендовать к просмотру некоторые из них, которые довольно широким массам могут быть полезны
1) Георгий Могелашвили, Эффективные 1-на-1
https://www.youtube.com/watch?v=oWNgix2sNJ8
Кому смотреть - тем, кто уже стал лидером команды, но делать 1-1 не умеет ИЛИ тому, кто сам умеет и уже должен учить других, но что-то времени не хватает. Тогда можно свалить всю работу на Георгия 🙂
2) Иван Замесин, Стыдно просить повышения зарплаты. Что с этим делать?
https://www.youtube.com/watch?v=N2wr88xqmoA
Кому смотреть - тем, кто не боится подойти и попросить, а также тем, к кому должны подходить и просить. Нюанс такой - если не придут, то уйдут 🙂
Еще я очень хотел порекомендовать доклад Евгения Кот, про инженерный шовинизм, а на самом деле про страдания свежевыдвинувшегося лидера команды и путь к их решению (https://2019.codefest.ru/lecture/1384). Сложно понять, почему именно этот доклад CodeFest решили не выкладывать. Можно найти более ранние версии или прототипы этого доклада с других конференций, но мне показалось, что они "еще не то". Есть онлайн версия в его github (https://bunopus.github.io/presentation-manager-fear/) - но там вначале будет очень долго грузиться, потом надо заметить малюсенькую стрелочку в правом нижнем углу и кликнуть по ней, а потом будет несколько красивых, но непонятных слайдов. Вобщем не судьба.
Вместо этого хочу порекомендовать почитать о том, какая адская вычислительная магия стоит за красивыми фоточками со смартфона, или как электроника делает то, чего обычной оптикой не добиться в таком компактном размере и куда это нас со временем приведет. А приведет к тому, что фотки из коробки будут красивее реальности.
https://vas3k.ru/blog/computational_photography/
Рискну порекомендовать к просмотру некоторые из них, которые довольно широким массам могут быть полезны
1) Георгий Могелашвили, Эффективные 1-на-1
https://www.youtube.com/watch?v=oWNgix2sNJ8
Кому смотреть - тем, кто уже стал лидером команды, но делать 1-1 не умеет ИЛИ тому, кто сам умеет и уже должен учить других, но что-то времени не хватает. Тогда можно свалить всю работу на Георгия 🙂
2) Иван Замесин, Стыдно просить повышения зарплаты. Что с этим делать?
https://www.youtube.com/watch?v=N2wr88xqmoA
Кому смотреть - тем, кто не боится подойти и попросить, а также тем, к кому должны подходить и просить. Нюанс такой - если не придут, то уйдут 🙂
Еще я очень хотел порекомендовать доклад Евгения Кот, про инженерный шовинизм, а на самом деле про страдания свежевыдвинувшегося лидера команды и путь к их решению (https://2019.codefest.ru/lecture/1384). Сложно понять, почему именно этот доклад CodeFest решили не выкладывать. Можно найти более ранние версии или прототипы этого доклада с других конференций, но мне показалось, что они "еще не то". Есть онлайн версия в его github (https://bunopus.github.io/presentation-manager-fear/) - но там вначале будет очень долго грузиться, потом надо заметить малюсенькую стрелочку в правом нижнем углу и кликнуть по ней, а потом будет несколько красивых, но непонятных слайдов. Вобщем не судьба.
Вместо этого хочу порекомендовать почитать о том, какая адская вычислительная магия стоит за красивыми фоточками со смартфона, или как электроника делает то, чего обычной оптикой не добиться в таком компактном размере и куда это нас со временем приведет. А приведет к тому, что фотки из коробки будут красивее реальности.
https://vas3k.ru/blog/computational_photography/
У вас бывали бесполезные митинги? Сидим, жуем время, говорим о том, о сем? А откосить нельзя, потому что он для вас или вашей команды отчетный или что-то в этом роде. Дал своим совет, как поступать в такой ситуации - перехватывай инициативу:
1) Ваша повестка. Чтобы не болтать о чем попало, приходите со своим списком вопросов, проблем и ожидаемых действий. Не отвлекайтесь на необязывающие разговоры о текучке, пока не решили актуальные вопросы.
2) Проблемы на стол. Если вы о какой-то проблеме не говорите, то ее для всех остальных не существует - не со зла, а потому что "с глаз долой, из сердца вон". Всякая встреча по статуса должна обязательно показывать все актуальные внешние проблемы и требовать по ним либо решения, либо коррекции ожиданий.
3) Приходи подготовленным. Есть довольно очевидные вопросы, которые будут спрошены на пути от проблемы к решению. Если на них есть ответы, то будет и решение принято. Если ответов нет, то можно утонуть в "в следующий раз обсудим"
4) Выгрузить рутину. Можно всякий раз бесполезно читать вслух содержание спринта, или жевать каждую метрику проекта. Можно их просто сбросить в документе и говорить про действительно важные вещи - экстраординарные ситуации, повышение общего уровня работы и так далее. Нет смысла тратить время на бесконечные "тут показать 3.7, это нормально...", достаточно сказать - "метрики вы все видели, там все нормально, кроме X, о котором мы сейчас и поговорим ..."
5) Сделай уже документ. Все вышеперечисленное легко достигается, если встреча идет по документу, который приносите вы. Устный рассказ - это слова, которые провоцируют другие слова. Документ - это как рельсы, едем строго по ним. Грубо говоря, "у кого слайды, тот и музыку заказывает". Хотя слайды для митингов это часто зло и подойдет любой структурированный документ.
После этого можно переходить к сокращению времени и частоты встреч.
1) Ваша повестка. Чтобы не болтать о чем попало, приходите со своим списком вопросов, проблем и ожидаемых действий. Не отвлекайтесь на необязывающие разговоры о текучке, пока не решили актуальные вопросы.
2) Проблемы на стол. Если вы о какой-то проблеме не говорите, то ее для всех остальных не существует - не со зла, а потому что "с глаз долой, из сердца вон". Всякая встреча по статуса должна обязательно показывать все актуальные внешние проблемы и требовать по ним либо решения, либо коррекции ожиданий.
3) Приходи подготовленным. Есть довольно очевидные вопросы, которые будут спрошены на пути от проблемы к решению. Если на них есть ответы, то будет и решение принято. Если ответов нет, то можно утонуть в "в следующий раз обсудим"
4) Выгрузить рутину. Можно всякий раз бесполезно читать вслух содержание спринта, или жевать каждую метрику проекта. Можно их просто сбросить в документе и говорить про действительно важные вещи - экстраординарные ситуации, повышение общего уровня работы и так далее. Нет смысла тратить время на бесконечные "тут показать 3.7, это нормально...", достаточно сказать - "метрики вы все видели, там все нормально, кроме X, о котором мы сейчас и поговорим ..."
5) Сделай уже документ. Все вышеперечисленное легко достигается, если встреча идет по документу, который приносите вы. Устный рассказ - это слова, которые провоцируют другие слова. Документ - это как рельсы, едем строго по ним. Грубо говоря, "у кого слайды, тот и музыку заказывает". Хотя слайды для митингов это часто зло и подойдет любой структурированный документ.
После этого можно переходить к сокращению времени и частоты встреч.
Иногда кажется сложным соблюсти верный баланс между соблюдением правил и гибкостью процесса. Чуть вильнул в одну сторону - бюрократия и косность, чуть вильнул в другую - хаос и бардак. Еще сложнее объяснить этот баланс людям - должны ли они строго соблюдать правила или должны они смело экспериментировать?
Несколько раз я это объяснял через метафору "ты первопроходец или отщепенец?" -
- есть некий минимальный стандарт качества для любого дела. нельзя делать хуже минимума.
- правила это проверенный способ соответствовать этому стандарту
- если ты хочешь и можешь сделать что-то сверх, чтобы получилось лучше - в добрый путь
- а вот если ты хочешь сделать не сверх, а по другому, то подумай секундочку - ты это делаешь сознательно потому, что ожидаешь лучшего результата, или делаешь просто так? если ты подумал и имел основания ожидать лучшего результата, и сознательно пошел не по правилам - может быть, что ты первопроходец. Тогда победителей не судят, а проигравших не сильно ругают. А вот если ты просто забил на правила - тогда ты отщепенец. И это глупо. Глупо игнорировать наработанный другими опыт
Получилось введение в CMMI для чайников
Несколько раз я это объяснял через метафору "ты первопроходец или отщепенец?" -
- есть некий минимальный стандарт качества для любого дела. нельзя делать хуже минимума.
- правила это проверенный способ соответствовать этому стандарту
- если ты хочешь и можешь сделать что-то сверх, чтобы получилось лучше - в добрый путь
- а вот если ты хочешь сделать не сверх, а по другому, то подумай секундочку - ты это делаешь сознательно потому, что ожидаешь лучшего результата, или делаешь просто так? если ты подумал и имел основания ожидать лучшего результата, и сознательно пошел не по правилам - может быть, что ты первопроходец. Тогда победителей не судят, а проигравших не сильно ругают. А вот если ты просто забил на правила - тогда ты отщепенец. И это глупо. Глупо игнорировать наработанный другими опыт
Получилось введение в CMMI для чайников
Интересная заметка от иностранного профессора про российских студентов
Некоторым российским студентам было не под силу понять, что аргумент — это сложная, формализованная, зачастую логически упорядоченная цепочка рассуждений, которые по необходимости выражают неочевидное суждение о мире. Студенты часто полагали, что аргумент сущностно равен мнению, т.е. субъективному ценностному суждению о какой-то конкретной проблеме (например, «эта идея хорошая» или «эта идея плохая»).
Многие студенты восприняли задание по оценке исследуемого текста как приглашение делиться субъективными впечатлениями, рассказывать о чувствах, которые вызывает предложенный материал, и проделывать всё это без предоставления достаточной аргументации, которая могла бы по крайней мере указать на источник этих чувств. Как только студентам предлагалось оценить аргумент, они принимались выражать свои частные впечатления, игнорируя критическую оценку валидности или убедительности рассматриваемого аргумента.
Боязнь ошибки
Боязнь допустить ошибку – пожалуй, наиболее заметная общая проблема, отмеченная всеми преподавателями. Студенты считают необходимым поднять руку и участвовать лишь в том случае, если они уверены в том, что их ответ будет соответствовать ожиданиям профессора. К числу самых крепко засевших психологических ограничителей можно отнести убежденность студентов, что им следует отвечать лишь в том случае, если они уверены в «правильности» ответа, — от этой привычки они никак не могут отказаться. Обратимся к следующему примеру: преподаватель задает вопрос открытого типа, потенциально ведущий к нескольким ответам и линиям развития дискуссии. Студент поднимает руку, дает ответ. Другие студенты пристально смотрят на преподавателя, пытаясь понять, одобряет он этот ответ или нет; в этот момент студенты вовсе не размышляют над собственными ответами и не готовят замечания на ответ однокурсника. Считывая реакцию преподавателя, они пробуют изменить свой будущий ответ, подстроив его под то, что – как они считают – он хотел бы услышать. Если студентам не удается найти шаблон, по которому можно выкроить ответ, их охватывает неуверенность.
Постановка вопросов
Студент, не уверенный в том, что он правильно понял тему, не поднимет руку и не задаст вопрос. Это еще один психологический барьер, который оказалось очень трудно преодолеть. Преподаватели, имеющие опыт преподавания в иных странах, привыкли полагать, что отсутствие вопросов говорит либо о полном понимании, либо о согласии всех слушателей с представленными аргументами. В случае России это – значимое отсутствие другого типа. Студенты считают, что заданный вопрос – признак слабости, символ пораженчества. Это касается и вопросов на уточнение (когда что-то было неясно), и вопросов на объяснение (когда студенты хотят узнать больше о конкретной проблеме).
В общем, студенты полагают, что роль преподавателя сводится к чтению лекций и задаванию вопросов; а задача учащихся – отвечать на вопросы, если они могут (если не могут – молчать). Если студенты все-таки задают вопросы, то чаще всего это вопросы на уточнение. Очевидно, их не учили задавать вопросы, которые могут развивать дискуссию; к примеру, их вопросы не указывают на непроговоренные допущения и противоречия, заключенные в рассматриваемом аргументе. Студенты не считают, что вопрос может значительно обогатить дискуссию – по крайней мере, так, как это сделает правильный ответ. С точки зрения студентов, ценные высказывания следует представлять в утвердительной манере; их нельзя сформулировать в виде вопроса.
Некоторым российским студентам было не под силу понять, что аргумент — это сложная, формализованная, зачастую логически упорядоченная цепочка рассуждений, которые по необходимости выражают неочевидное суждение о мире. Студенты часто полагали, что аргумент сущностно равен мнению, т.е. субъективному ценностному суждению о какой-то конкретной проблеме (например, «эта идея хорошая» или «эта идея плохая»).
Многие студенты восприняли задание по оценке исследуемого текста как приглашение делиться субъективными впечатлениями, рассказывать о чувствах, которые вызывает предложенный материал, и проделывать всё это без предоставления достаточной аргументации, которая могла бы по крайней мере указать на источник этих чувств. Как только студентам предлагалось оценить аргумент, они принимались выражать свои частные впечатления, игнорируя критическую оценку валидности или убедительности рассматриваемого аргумента.
Боязнь ошибки
Боязнь допустить ошибку – пожалуй, наиболее заметная общая проблема, отмеченная всеми преподавателями. Студенты считают необходимым поднять руку и участвовать лишь в том случае, если они уверены в том, что их ответ будет соответствовать ожиданиям профессора. К числу самых крепко засевших психологических ограничителей можно отнести убежденность студентов, что им следует отвечать лишь в том случае, если они уверены в «правильности» ответа, — от этой привычки они никак не могут отказаться. Обратимся к следующему примеру: преподаватель задает вопрос открытого типа, потенциально ведущий к нескольким ответам и линиям развития дискуссии. Студент поднимает руку, дает ответ. Другие студенты пристально смотрят на преподавателя, пытаясь понять, одобряет он этот ответ или нет; в этот момент студенты вовсе не размышляют над собственными ответами и не готовят замечания на ответ однокурсника. Считывая реакцию преподавателя, они пробуют изменить свой будущий ответ, подстроив его под то, что – как они считают – он хотел бы услышать. Если студентам не удается найти шаблон, по которому можно выкроить ответ, их охватывает неуверенность.
Постановка вопросов
Студент, не уверенный в том, что он правильно понял тему, не поднимет руку и не задаст вопрос. Это еще один психологический барьер, который оказалось очень трудно преодолеть. Преподаватели, имеющие опыт преподавания в иных странах, привыкли полагать, что отсутствие вопросов говорит либо о полном понимании, либо о согласии всех слушателей с представленными аргументами. В случае России это – значимое отсутствие другого типа. Студенты считают, что заданный вопрос – признак слабости, символ пораженчества. Это касается и вопросов на уточнение (когда что-то было неясно), и вопросов на объяснение (когда студенты хотят узнать больше о конкретной проблеме).
В общем, студенты полагают, что роль преподавателя сводится к чтению лекций и задаванию вопросов; а задача учащихся – отвечать на вопросы, если они могут (если не могут – молчать). Если студенты все-таки задают вопросы, то чаще всего это вопросы на уточнение. Очевидно, их не учили задавать вопросы, которые могут развивать дискуссию; к примеру, их вопросы не указывают на непроговоренные допущения и противоречия, заключенные в рассматриваемом аргументе. Студенты не считают, что вопрос может значительно обогатить дискуссию – по крайней мере, так, как это сделает правильный ответ. С точки зрения студентов, ценные высказывания следует представлять в утвердительной манере; их нельзя сформулировать в виде вопроса.
Изменение собственной позиции
Некоторые студенты считают: признаться в том, что ты изменил точку зрения, – значит, признать поражение. Они будут защищать исходную позицию изо всех сил, исключительно чтобы показать, что способны отстаивать её всеми возможными способами. Студентам тяжело оспаривать собственные предпосылки, и часто они выстраивают выступления на шатких, предвзятых суждениях – лишь потому, что хотя бы одно из этих суждений им знакомо (или потому, что это первое суждение, услышанное ими за время семинара). Стоит им соотнести себя с конкретной интеллектуальной позицией или идеей, как они принимают её в качестве неотделимого элемента собственной идентичности, которую следует защищать – не потому что она убедительна, но потому что это часть их самости. Студентам трудно ставить мыслительные эксперименты, потому что они сразу стремятся занять ту или иную позицию. Они привыкли сплавлять своё «я» с конкретной точкой зрения, и потому им сложно оценивать суждения отстраненно. Эта проблема стала особенно очевидна, когда преподаватели попытались разделить студентов на разные группы и пригласить их к дебатам. Студенты хотели отстаивать только те позиции, с которыми они уже соотнесли себя, что затруднило поиск волонтеров для оппонирующих команд.
Обратная связь и образовательный процесс
Студентам сложно давался разбор обратной связи, полученной в комментариях к их эссе. Некоторые были убеждены: чем больше «рецензия» (то есть, чем больше комментариев, вопросов, уточнений, исправлений), тем хуже поданная работа. Кажется, некоторые студенты рассчитывали, что преподаватель пришлет им эссе без помарок и замечаний и с наивысшей оценкой. Они расценивали замечания как попытку цензурирования или же вовсе как выговор, от которого они, естественно, пытались уклониться. В общем, эффективность обратной связи оставила желать лучшего: студенты продолжали допускать одни и те же ошибки. В паре случаев студенты и вовсе с удивлением узнавали, что им следует читать комментарии, замечания и исправления преподавателя, они не могли понять, что изучение замечаний преподавателя и работа с ними является частью учебного процесса.
К другим процессуальным неудачам, которые отмечали многие профессора, можно отнести отсутствие привычки вести заметки. Примечательно, что студенты записывали лишь то, что преподаватель писал на доске или обозначал в речи как нечто, имеющее особую значимость. В иных ситуациях, к которым можно отнести семинар или групповые презентации, студенты часто и вовсе не открывали свои ноутбуки (которые можно было приносить на занятия). Возможно, причина кроется в том, что студенты знали, что курс не предполагает итогового экзамена, а, значит, нет и конкретного массива знаний, которые следует копировать, усваивать и повторять перед преподавателем. Студенты не привыкли к тому, что во время обсуждения их может посетить вдохновляющая идея, которую стоит записать; идея, которая может помочь спроектировать и написать итоговое эссе.
Обсуждения в классе
Следует отметить еще одну сложность: студентов довольно трудно увлечь свободным обсуждением академической темы – если преподаватель не задает наводящих вопросов, беседа угасает. Учащиеся ожидают, что обмениваться мнениями будет лишь один из них, и только с преподавателем; они скорее готовы к интеллектуальному пинг-понгу, нежели к круглому столу. Они полагают, что комментариям преподавателя следует уделять больше внимания, чем репликам однокурсников. Это привело к появлению новой проблемы: через несколько занятий в группах проявился устойчивый паттерн – несколько студентов постоянно вовлечены в работу, а остальные превращаются в пассивных слушателей. При этом студенты считали эту ситуацию нормальной, словно занятия так и должны проходить всегда
https://sas.utmn.ru/ru/russian-students/?fbclid=IwAR0rFNmKc77RcBOEWI2DNAsEkfcBJ-FIfQLNlbtcTVe4USwvWpf8nax8FbQ
Некоторые студенты считают: признаться в том, что ты изменил точку зрения, – значит, признать поражение. Они будут защищать исходную позицию изо всех сил, исключительно чтобы показать, что способны отстаивать её всеми возможными способами. Студентам тяжело оспаривать собственные предпосылки, и часто они выстраивают выступления на шатких, предвзятых суждениях – лишь потому, что хотя бы одно из этих суждений им знакомо (или потому, что это первое суждение, услышанное ими за время семинара). Стоит им соотнести себя с конкретной интеллектуальной позицией или идеей, как они принимают её в качестве неотделимого элемента собственной идентичности, которую следует защищать – не потому что она убедительна, но потому что это часть их самости. Студентам трудно ставить мыслительные эксперименты, потому что они сразу стремятся занять ту или иную позицию. Они привыкли сплавлять своё «я» с конкретной точкой зрения, и потому им сложно оценивать суждения отстраненно. Эта проблема стала особенно очевидна, когда преподаватели попытались разделить студентов на разные группы и пригласить их к дебатам. Студенты хотели отстаивать только те позиции, с которыми они уже соотнесли себя, что затруднило поиск волонтеров для оппонирующих команд.
Обратная связь и образовательный процесс
Студентам сложно давался разбор обратной связи, полученной в комментариях к их эссе. Некоторые были убеждены: чем больше «рецензия» (то есть, чем больше комментариев, вопросов, уточнений, исправлений), тем хуже поданная работа. Кажется, некоторые студенты рассчитывали, что преподаватель пришлет им эссе без помарок и замечаний и с наивысшей оценкой. Они расценивали замечания как попытку цензурирования или же вовсе как выговор, от которого они, естественно, пытались уклониться. В общем, эффективность обратной связи оставила желать лучшего: студенты продолжали допускать одни и те же ошибки. В паре случаев студенты и вовсе с удивлением узнавали, что им следует читать комментарии, замечания и исправления преподавателя, они не могли понять, что изучение замечаний преподавателя и работа с ними является частью учебного процесса.
К другим процессуальным неудачам, которые отмечали многие профессора, можно отнести отсутствие привычки вести заметки. Примечательно, что студенты записывали лишь то, что преподаватель писал на доске или обозначал в речи как нечто, имеющее особую значимость. В иных ситуациях, к которым можно отнести семинар или групповые презентации, студенты часто и вовсе не открывали свои ноутбуки (которые можно было приносить на занятия). Возможно, причина кроется в том, что студенты знали, что курс не предполагает итогового экзамена, а, значит, нет и конкретного массива знаний, которые следует копировать, усваивать и повторять перед преподавателем. Студенты не привыкли к тому, что во время обсуждения их может посетить вдохновляющая идея, которую стоит записать; идея, которая может помочь спроектировать и написать итоговое эссе.
Обсуждения в классе
Следует отметить еще одну сложность: студентов довольно трудно увлечь свободным обсуждением академической темы – если преподаватель не задает наводящих вопросов, беседа угасает. Учащиеся ожидают, что обмениваться мнениями будет лишь один из них, и только с преподавателем; они скорее готовы к интеллектуальному пинг-понгу, нежели к круглому столу. Они полагают, что комментариям преподавателя следует уделять больше внимания, чем репликам однокурсников. Это привело к появлению новой проблемы: через несколько занятий в группах проявился устойчивый паттерн – несколько студентов постоянно вовлечены в работу, а остальные превращаются в пассивных слушателей. При этом студенты считали эту ситуацию нормальной, словно занятия так и должны проходить всегда
https://sas.utmn.ru/ru/russian-students/?fbclid=IwAR0rFNmKc77RcBOEWI2DNAsEkfcBJ-FIfQLNlbtcTVe4USwvWpf8nax8FbQ
Кому кажется, что описанное поведение действительно характерно для соотечественников? Кто считает, что наговаривают? Кто считает, что "сами вы ничем не лучше"?
Как обычно, развернуто выразиться можно в чятике https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ
Как обычно, развернуто выразиться можно в чятике https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ
Почему в век, когда все можно спросить или нагуглить, остаются важны люди, которые много знают или знают глубоко?
Давайте возьмем простое упражнение - пройти лабиринт (слева на картинке ниже).
Вы его прошли с небольшим напряжением секунд за 10. Ребенок дошкольного возраста пройдет за минуту
Теперь разделим карту лабиринта на 4 части, дадим каждую отдельному человеку и предложим найти решение.
Они могут обсуждать сколько угодно, но нельзя просто состыковать все части вместе.
У самых способных организаторов это может занять несколько минут. У менее способных это займет 20-40-60 и более минут. Можно даже вообще завязнуть и не найти решения
Понимаете, откуда сложность?
Да, нейронная сеть в нашей голове довольно ловко жонглирует данными, перебирает самые разные сочетания, чтобы найти решение сложной задачи. Все это прекрасно работает при одном простом условии - все нужные данные уже в голове. Если данные не в голове, то ими нельзя ловко жонглировать
Есть способы организовать коллективную работу нескольких человек, но она всегда МЕНЕЕ эффективна, чем когда все в голове у одного. Можно делать медленный перебор вариантов (согласование)
- А если я пойду сюда?
- Нет, тогда мы не можем…
- А сюда?
- Тогда уже мы не можем…
- Зато мы можем!
- Хотя нет, тоже не можем…
Это как минимум долго. Это с большой вероятностью может вообще не дать увидеть самый лучший вариант. Это вообще может не дать ни одного работающего варианта.
Можно вначале объяснить друг другу всю полноту картины. Попробуйте рассказать товарищу словами свою часть лабиринта. Да, здесь есть свои сложности и искажения.
Поэтому все, что может физически обработать один человек - наиболее эффективно этим одним человеком и решать. Именно поэтому сколько бы не совершенствовался гугл, для решения сложных вопросов по-прежнему ценны люди, которые знаю тему вдоль и поперек. Они могут находить решения, которые другим образом вообще не найти. Уже потом можно перепроверить найденное решение разными медленными способами. Поэтому индустрия всегда ценила I-людей (кто знает вопрос глубоко), а потом стала особо ценить T-людей (кто знают вопрос глубоко, но еще знают и смежные вопросы вширь). Знание - сила.
Это не означает, что это единственный подход. Просто он самый эффективный и его стоит предпочитать альтернативам. неизбежно наступает момент, когда тема не помещается в одного человека, поскольку у всякого человека и у всякого знания есть границы - и тогда понадобятся организаторы, модераторы, фасилитаторы, которые организуют решение вопроса коллективом авторов
Давайте возьмем простое упражнение - пройти лабиринт (слева на картинке ниже).
Вы его прошли с небольшим напряжением секунд за 10. Ребенок дошкольного возраста пройдет за минуту
Теперь разделим карту лабиринта на 4 части, дадим каждую отдельному человеку и предложим найти решение.
Они могут обсуждать сколько угодно, но нельзя просто состыковать все части вместе.
У самых способных организаторов это может занять несколько минут. У менее способных это займет 20-40-60 и более минут. Можно даже вообще завязнуть и не найти решения
Понимаете, откуда сложность?
Да, нейронная сеть в нашей голове довольно ловко жонглирует данными, перебирает самые разные сочетания, чтобы найти решение сложной задачи. Все это прекрасно работает при одном простом условии - все нужные данные уже в голове. Если данные не в голове, то ими нельзя ловко жонглировать
Есть способы организовать коллективную работу нескольких человек, но она всегда МЕНЕЕ эффективна, чем когда все в голове у одного. Можно делать медленный перебор вариантов (согласование)
- А если я пойду сюда?
- Нет, тогда мы не можем…
- А сюда?
- Тогда уже мы не можем…
- Зато мы можем!
- Хотя нет, тоже не можем…
Это как минимум долго. Это с большой вероятностью может вообще не дать увидеть самый лучший вариант. Это вообще может не дать ни одного работающего варианта.
Можно вначале объяснить друг другу всю полноту картины. Попробуйте рассказать товарищу словами свою часть лабиринта. Да, здесь есть свои сложности и искажения.
Поэтому все, что может физически обработать один человек - наиболее эффективно этим одним человеком и решать. Именно поэтому сколько бы не совершенствовался гугл, для решения сложных вопросов по-прежнему ценны люди, которые знаю тему вдоль и поперек. Они могут находить решения, которые другим образом вообще не найти. Уже потом можно перепроверить найденное решение разными медленными способами. Поэтому индустрия всегда ценила I-людей (кто знает вопрос глубоко), а потом стала особо ценить T-людей (кто знают вопрос глубоко, но еще знают и смежные вопросы вширь). Знание - сила.
Это не означает, что это единственный подход. Просто он самый эффективный и его стоит предпочитать альтернативам. неизбежно наступает момент, когда тема не помещается в одного человека, поскольку у всякого человека и у всякого знания есть границы - и тогда понадобятся организаторы, модераторы, фасилитаторы, которые организуют решение вопроса коллективом авторов
Ребята в конторе увидели пост Евгения Казначеева про то, что публичный багтракеры/копилки идей не работают и попросили прокомментировать. Я несколько таких штук эсклуатировал сам, про несколько общался со "смежниками", и в еще нескольких участвовал как пользователь или свидетель (MS Outlook, World of Tanks), и выходит так, что для ответа надо определить что такое "работает".
Есть практическая ситуация - ежедневно поступают разносортные хотелки пачками. Несколько штук в день, порядка тысяч в год. Отслеживать руками их трудно и больно. Простейший "груминг" на предмет объединения дупликатов, инкремента счетчика голосов и поддержания приоритетов занимал другоценные часы. А стоит его запустить и беклог становится невозможно далее обслуживать и на моей памяти несколько таких накопленных беклогов в 500+ единиц пришлось просто закопать за отсутствием времени на все это перечитывать и сортировать.
И вот эту ситуацию "голосовалка" решает очень хорошо - с практически нулевыми затратами времени система типа Uservoice создает довольно качественный и упорядоченный список хотелок. Это настолько надежно, что у нас был длительный период организационно сломанной процедуры присмотра за порядком на Uservoice, и оно все равно работало. Где-то содержание замусорилось, где-то протухло, но система продолжала производить довольно упорядоченный список при уже однозначно нулевых затратах. Это то, что РАБОТАЕТ.
Также РАБОТАЕТ возможность проводить custdev или иное взаимодействие. Авторы хотелок очень заинтересованные в вопросе люди и очень хорошо откликаются на предложения поговорить, заполнить опросник и т.п.
Теперь об обратной стороне:
- НЕ РАБОТАЕТ ожидание, что пользователь перестанет что-то хотеть от того, что оно не пользуется популярностью. Он все равно хочет. А вы все равно в его глазах плохие, что этого не делаете. Во всех голосовалках, где я участвовал, была такая картина. Частные симптомы - пользователь начинает аппелировать к возрасту запроса ("уже два года не делаете") вместо популярности, к абсолютной величине числа запросов ("уже 50 голосов") вместо относительной (в топ попадасть надо 250+), к переходу в другой канал (просят на форуме, потому что в голосовалке все равно не делают).
- НЕ РАБОТАЕТ ожидание, что аудитория будет признавать голоса как легитимный источник и это как-то улучшит ваш publicity. В самом лучшем случае вы можете получить какую-то обоснованность в глазах других пользователей за неделание этой конкретной хотелки, НО во-первых пользователи и не будут массово смотреть какие-то чужие непопулярные хотелки, а во-вторых авторы непопулярных хотелок будут сочувствовать друг другу в своем горе.
- НЕ РАБОТАЕТ ожидание, что аудитория будет сообщать качественную обратную связь. Все знают разницу между проблемой пользователя и решением, которое он просит. Огромная разница. Но не возможно хотеть проблему, поэтому будут приходить с готовыми решениями и просить их. Впрочем, поскольку работает взаимодействие, то можно уточнять. К примеру, есть в активе "security" фича, где все возмущенно кричали про наше недопустимое отношение к безопасности, а далее оказалось, что ее наличие банально позволяет получить скидку по ряду услуг у других вендоров и никакой безопасности никто и не ожидает.
- НЕ РАБОТАЕТ ожидание про то, что делая эти хотелки продукт станет успешнее. Есть частный случай, когда уже есть хороший product-market fit, потенциальная аудитория большая, текущими клиентами представлена релевантна, будешь делать хорошо для них - будут новые пользователи. Но так не всегда и в общем случае будущие клиенты (prospects) могут хотеть совсем не того, чего хотят текущие. Но не-клиенты никогда не придут в вашу голосовалку.
Поэтому при запуске такой системы надо понимать цели - ЛЮБВИ И СЧАСТЬЯ НЕ БУДЕТ, а упорядоченный список острых хотелок будет. Ровно в нем и цель
Эксплуатация и запуск такой системы имеют ряд тонкостей (иначе все пойдет совсем плохо), часть которых описана в старой статье, но сейчас не все из описанного актуально
Есть практическая ситуация - ежедневно поступают разносортные хотелки пачками. Несколько штук в день, порядка тысяч в год. Отслеживать руками их трудно и больно. Простейший "груминг" на предмет объединения дупликатов, инкремента счетчика голосов и поддержания приоритетов занимал другоценные часы. А стоит его запустить и беклог становится невозможно далее обслуживать и на моей памяти несколько таких накопленных беклогов в 500+ единиц пришлось просто закопать за отсутствием времени на все это перечитывать и сортировать.
И вот эту ситуацию "голосовалка" решает очень хорошо - с практически нулевыми затратами времени система типа Uservoice создает довольно качественный и упорядоченный список хотелок. Это настолько надежно, что у нас был длительный период организационно сломанной процедуры присмотра за порядком на Uservoice, и оно все равно работало. Где-то содержание замусорилось, где-то протухло, но система продолжала производить довольно упорядоченный список при уже однозначно нулевых затратах. Это то, что РАБОТАЕТ.
Также РАБОТАЕТ возможность проводить custdev или иное взаимодействие. Авторы хотелок очень заинтересованные в вопросе люди и очень хорошо откликаются на предложения поговорить, заполнить опросник и т.п.
Теперь об обратной стороне:
- НЕ РАБОТАЕТ ожидание, что пользователь перестанет что-то хотеть от того, что оно не пользуется популярностью. Он все равно хочет. А вы все равно в его глазах плохие, что этого не делаете. Во всех голосовалках, где я участвовал, была такая картина. Частные симптомы - пользователь начинает аппелировать к возрасту запроса ("уже два года не делаете") вместо популярности, к абсолютной величине числа запросов ("уже 50 голосов") вместо относительной (в топ попадасть надо 250+), к переходу в другой канал (просят на форуме, потому что в голосовалке все равно не делают).
- НЕ РАБОТАЕТ ожидание, что аудитория будет признавать голоса как легитимный источник и это как-то улучшит ваш publicity. В самом лучшем случае вы можете получить какую-то обоснованность в глазах других пользователей за неделание этой конкретной хотелки, НО во-первых пользователи и не будут массово смотреть какие-то чужие непопулярные хотелки, а во-вторых авторы непопулярных хотелок будут сочувствовать друг другу в своем горе.
- НЕ РАБОТАЕТ ожидание, что аудитория будет сообщать качественную обратную связь. Все знают разницу между проблемой пользователя и решением, которое он просит. Огромная разница. Но не возможно хотеть проблему, поэтому будут приходить с готовыми решениями и просить их. Впрочем, поскольку работает взаимодействие, то можно уточнять. К примеру, есть в активе "security" фича, где все возмущенно кричали про наше недопустимое отношение к безопасности, а далее оказалось, что ее наличие банально позволяет получить скидку по ряду услуг у других вендоров и никакой безопасности никто и не ожидает.
- НЕ РАБОТАЕТ ожидание про то, что делая эти хотелки продукт станет успешнее. Есть частный случай, когда уже есть хороший product-market fit, потенциальная аудитория большая, текущими клиентами представлена релевантна, будешь делать хорошо для них - будут новые пользователи. Но так не всегда и в общем случае будущие клиенты (prospects) могут хотеть совсем не того, чего хотят текущие. Но не-клиенты никогда не придут в вашу голосовалку.
Поэтому при запуске такой системы надо понимать цели - ЛЮБВИ И СЧАСТЬЯ НЕ БУДЕТ, а упорядоченный список острых хотелок будет. Ровно в нем и цель
Эксплуатация и запуск такой системы имеют ряд тонкостей (иначе все пойдет совсем плохо), часть которых описана в старой статье, но сейчас не все из описанного актуально
О важности usability. Помните смешной случай, когда на Гаваях объявили ракетную тревогу по ошибке? Потом говорили, что в интерфейсе было легко перепутать учебную тревогу и реальную. Или пару лет назад эсминец Джон Маккейн протаранил танкер, погибли 10 человек и были ранены 58. Оказалось, что новые сенсорные пульты управления были не до конца понятны экипажу и оператор перепутал полный ход обоими двигателями с полным ходом только одной стороной - в итоге эсминец резко развернуло. И теперь ВМФ США хочет вернуться к старым добрым механическим крутилкам-вертелкам от всего этого дижитала.
Вынужден признать, что digital интерфейсы оказываются очень неудобны. Приведу пачку примеров (картинка ниже). На старом водонагревателе я мог сменить температуру нагрева одним движением. На новом я должен нажимать и держать кнопки больше/меньше. Ладно, водонагреватель редко трогать надо. Возьмем новую микроволновку. Раньше я в два движения горил "греть сильно в течении 5 минут". Теперь надо долго ее "программировать" цифрами. Совсем плохо с чайником. Там не всегда нужно кипятить воду, часто ее надо просто подогреть. И раньше я это делал в одно движение, а теперь там 4 кнопки, с кучей режимов, я должен их нажать и держать пока там что-то на экране не появится. Но самое веселое, что впервые я с адом этого тренда столкнулся 20 лет на военном устройстве. У старого была очень удобная двойная крутилка - ладонью крутишь для большого изменения, а пальцем одновременно подкручиваешь тонкую настройку. Одно тактильное удовольствие. Но отечественное радио-конструкторы выпустили цифровой прибор, где вместо комфортного лампового кручения влево-вправо (секунды) я должен непрерывно набирать на тумблерах 0001, 0002, ..., 9999 - понимаете сколько времени и сил уходило?
Давайте еще анти-примеров "ux прогресса" приведу. В одном продукте, чтобы пользователь лучше понимал, что он вводит IP адрес, его разбили на 4 поля. Тренд такой был в начале 2000х. Но НИКТО не вводит IP адреса из головы - все их копируют откуда-то. И вот копировать в 4 отдельных поля пользователям стало намного сложнее. аналогично решили постпить с телефонами. Пройдет свыше 10 лет прежде чем индустрия обратно научится представлять телефоны и IP адреса нормально.
В одном продукте виновен был и я сам. В нем список сущностей был представлен большой text area. Дописываешь туда новое - оно создается. Стираешь одну из строк - оно удаляется. Это же не профессионально, решили мы. И переделали на табличный список с кнопками "создать" и "удалить". Конечно же, на нас потом ругались, потому что было очень удобно раньше делать copy-paste из письма пользователя, и стало совершенно невозможно потом. Примитивная text area как раз вполне удовлетворяла идеалам Джефа Раскина, что интерфейс должен быть текстом.
Во всех этих случаях пользовательский experience ухудшался на многие годы по всей индустрии. И немножко стремно понимать, что ты и сам был частью этого тренда. Давайте как-то ответственнее к этому относиться что ли...
Вынужден признать, что digital интерфейсы оказываются очень неудобны. Приведу пачку примеров (картинка ниже). На старом водонагревателе я мог сменить температуру нагрева одним движением. На новом я должен нажимать и держать кнопки больше/меньше. Ладно, водонагреватель редко трогать надо. Возьмем новую микроволновку. Раньше я в два движения горил "греть сильно в течении 5 минут". Теперь надо долго ее "программировать" цифрами. Совсем плохо с чайником. Там не всегда нужно кипятить воду, часто ее надо просто подогреть. И раньше я это делал в одно движение, а теперь там 4 кнопки, с кучей режимов, я должен их нажать и держать пока там что-то на экране не появится. Но самое веселое, что впервые я с адом этого тренда столкнулся 20 лет на военном устройстве. У старого была очень удобная двойная крутилка - ладонью крутишь для большого изменения, а пальцем одновременно подкручиваешь тонкую настройку. Одно тактильное удовольствие. Но отечественное радио-конструкторы выпустили цифровой прибор, где вместо комфортного лампового кручения влево-вправо (секунды) я должен непрерывно набирать на тумблерах 0001, 0002, ..., 9999 - понимаете сколько времени и сил уходило?
Давайте еще анти-примеров "ux прогресса" приведу. В одном продукте, чтобы пользователь лучше понимал, что он вводит IP адрес, его разбили на 4 поля. Тренд такой был в начале 2000х. Но НИКТО не вводит IP адреса из головы - все их копируют откуда-то. И вот копировать в 4 отдельных поля пользователям стало намного сложнее. аналогично решили постпить с телефонами. Пройдет свыше 10 лет прежде чем индустрия обратно научится представлять телефоны и IP адреса нормально.
В одном продукте виновен был и я сам. В нем список сущностей был представлен большой text area. Дописываешь туда новое - оно создается. Стираешь одну из строк - оно удаляется. Это же не профессионально, решили мы. И переделали на табличный список с кнопками "создать" и "удалить". Конечно же, на нас потом ругались, потому что было очень удобно раньше делать copy-paste из письма пользователя, и стало совершенно невозможно потом. Примитивная text area как раз вполне удовлетворяла идеалам Джефа Раскина, что интерфейс должен быть текстом.
Во всех этих случаях пользовательский experience ухудшался на многие годы по всей индустрии. И немножко стремно понимать, что ты и сам был частью этого тренда. Давайте как-то ответственнее к этому относиться что ли...
Wikipedia
2018 Hawaii false missile alert
On the morning of January 13, 2018, an alert was accidentally issued via the Emergency Alert System and Wireless Emergency Alert System over television, radio, and cellular networks in the U.S. state of Hawaii, instructing citizens to seek shelter due to…
А давайте еще раз проиллюстрирую про вред многозначности на пальцах
Я обустраиваю себе дачу за городом и это очень много работы. А если точнее, то это очень много всяких разных работ. Каждая из работ требует массы материалов и инструментов. И замыслов вагон и все хочется успеть. Знаете что меня сильнее всего тормозит? Меня тормозит именно этот вагон.
Типовая ситуация:
- Ох, какая у меня классная новая идея возникла! Привезу-ка я под нее инструмент, материалы и начну… нет, не начну. Я же еще прошлое дело не закончил и мне нету места начать новое дело. Давай-ка я закончу старое… ох, но для этого надо вначале убрать все незаконченное новое…замкнутый круг
Я трачу вагон времени на то, чтобы убирать материалы от незаконченных проектов, чтобы что-то поделать. Я об них спотыкаюсь. Я их опрокидываю или рассыпаю и мне надо их убирать. Я теряю среди них нужное. Я трачу время на то, чтобы их сберечь - убирать от дождя или холода. Потому что жалко! Я регулярно трачу время на подумать об этих проектах, потому что натыкаюсь на их артефакты, закатываю глаза и думаю. Это все выкинутое время.
Все это мое поведение было сплошной антипаттерн. Пока я не поставил год назад задачу на сворачивание числа активных дел и не стал себя драйвить не числом начатого, а числом законченного. Максимизирую конечный выхлоп - что полезное можно закрыть за сейчас? За сегодня? За выходные? Не просто поделать, а закрыть окончательно или хотя бы перевести на следующий значимый этап.
Как определить, что я закрыл этап? Я могу избавиться от какой-то массы комплектующих и материалов. Она исчезла, она больше не мешает, и не обременяет меня. Строго по “Дао Тойота” - принцип сокращения запасов. Стремлюсь иметь запасов ровно на то дело, которым занимаешься сейчас.
Эти мешающие комплектующие и материалы - аналог знания всех тех тонкостей и нюансов, которые я должен помнить в работе про какое-то дело. Я не могу их выкинуть и не могу их отставить далеко, пока не закончу. И одновременно их масса заставляет меня часто отвлекаться от текущего дела. :( Средне-срочная память в мозге работает как цикл (это я курс лекций стенфордских прослушал) - поток информации непрерывно гоняется по кругу, чтобы не забыть. Чтобы не забыть, приходится регулярно вспоминать. И это отвлекает. Но я над собой работаю
Надеюсь, мой анти-пример позволит вам действовать лучше
Я обустраиваю себе дачу за городом и это очень много работы. А если точнее, то это очень много всяких разных работ. Каждая из работ требует массы материалов и инструментов. И замыслов вагон и все хочется успеть. Знаете что меня сильнее всего тормозит? Меня тормозит именно этот вагон.
Типовая ситуация:
- Ох, какая у меня классная новая идея возникла! Привезу-ка я под нее инструмент, материалы и начну… нет, не начну. Я же еще прошлое дело не закончил и мне нету места начать новое дело. Давай-ка я закончу старое… ох, но для этого надо вначале убрать все незаконченное новое…замкнутый круг
Я трачу вагон времени на то, чтобы убирать материалы от незаконченных проектов, чтобы что-то поделать. Я об них спотыкаюсь. Я их опрокидываю или рассыпаю и мне надо их убирать. Я теряю среди них нужное. Я трачу время на то, чтобы их сберечь - убирать от дождя или холода. Потому что жалко! Я регулярно трачу время на подумать об этих проектах, потому что натыкаюсь на их артефакты, закатываю глаза и думаю. Это все выкинутое время.
Все это мое поведение было сплошной антипаттерн. Пока я не поставил год назад задачу на сворачивание числа активных дел и не стал себя драйвить не числом начатого, а числом законченного. Максимизирую конечный выхлоп - что полезное можно закрыть за сейчас? За сегодня? За выходные? Не просто поделать, а закрыть окончательно или хотя бы перевести на следующий значимый этап.
Как определить, что я закрыл этап? Я могу избавиться от какой-то массы комплектующих и материалов. Она исчезла, она больше не мешает, и не обременяет меня. Строго по “Дао Тойота” - принцип сокращения запасов. Стремлюсь иметь запасов ровно на то дело, которым занимаешься сейчас.
Эти мешающие комплектующие и материалы - аналог знания всех тех тонкостей и нюансов, которые я должен помнить в работе про какое-то дело. Я не могу их выкинуть и не могу их отставить далеко, пока не закончу. И одновременно их масса заставляет меня часто отвлекаться от текущего дела. :( Средне-срочная память в мозге работает как цикл (это я курс лекций стенфордских прослушал) - поток информации непрерывно гоняется по кругу, чтобы не забыть. Чтобы не забыть, приходится регулярно вспоминать. И это отвлекает. Но я над собой работаю
Надеюсь, мой анти-пример позволит вам действовать лучше
одна картина стоит тысячи слов - есть такая красивая цитата Конфуция. И хотя, как с кучей других раскрученных цитат - сказал он самом деле не то и не так, но недавно я имел возможность наглядно убедиться в верности этого принципа для сложных тем.
Есть группа людей, все понимают некую тему, и собрались, чтобы порешать наболевшие вопросы.
Но в этот раз решили начать с диаграммы, как все устроено. И хотя вроде все должны понимать одинаково, но с самого начала изображение блоков и стрелок потребовало уточнений
- э, нет! этот блок идет вперед этого
- а вот эта стрелка не туда, а сюда... хотя если точнее, то даже сюда... и она пунктирная, потому что это не обязательный шаг...
и тп
Все-таки в словах остается большой простор для домысливания и интерпретации. Понимаем ли мы под одним словом одно и тоже? Не понимаем ли наоборот одно и тоже под разными словами? Не домысливаем ли связи, где их нет? И не упускаем ли там, где они есть? Лишь лучшие тексты способны достичь той ясности, что легко дают простые блоки и стрелочки -
- однозначность списка сущностей. блок либо есть, либо нет. либо один, либо несколько.
- однозначность связей. стрелка либо идет, либо нет. либо в ту сторону, либо обратно.
В более раннем случае, мы решали довольно сложную бизнес задачу, и с какого-то момента стало ясно, что во множественных текстовых требованиях мы легко можем упустить какую-то деталь и схема не заработает. Строго как в электрической схеме - нет одного контакта и ток не течет, только тут деньги вместо тока. Мы нарисовали все сущности, прочертили все связи, пронумеровали их и только затем уже описали текстово их суть - но зато точно были уверены, что все нужные связи есть и никакой сигнал не повиснет в воздухе.
Ни в одном случае мы не упарывались с формальными нотациями типа BPMN, UML и другими. Для ясности хватало просто обозначить блоки, их группировку и связи между ними.
Продолжительное время внедрению диаграмм в оборот препятствовало отсутствие инструмента. Word'ом мы для внутренней документации давно не пользуемся, а в wiki-подобных онлайн системах диаграмма обычно импортировалось как скриншот из другой системы - то есть править ее мог только автор, что сильно ограничивает обычные сценарии совместной работы на требованиями и дизайном. Вначале это решали плагином для draw.io. Сейчас чаша весов начинает склоняться в пользу Miro (которые Realtime Board)
Ни в коем случае, правда, не стоит полагать, что диаграмма это универсальный ключ и решит все проблемы. К примеру, когда мы делали сложный редизайн интерфейса и чтобы ничего не пропустить нарисовали схему всех переходов пользователя и выглядело все очень хорошо. В реальности однако один из переходов был, но был настолько не гладким, что пользователь тупо терялся и не понимал, где он теперь. Отловили до релиза, к счастью.
Мой совет - чертите!
Есть группа людей, все понимают некую тему, и собрались, чтобы порешать наболевшие вопросы.
Но в этот раз решили начать с диаграммы, как все устроено. И хотя вроде все должны понимать одинаково, но с самого начала изображение блоков и стрелок потребовало уточнений
- э, нет! этот блок идет вперед этого
- а вот эта стрелка не туда, а сюда... хотя если точнее, то даже сюда... и она пунктирная, потому что это не обязательный шаг...
и тп
Все-таки в словах остается большой простор для домысливания и интерпретации. Понимаем ли мы под одним словом одно и тоже? Не понимаем ли наоборот одно и тоже под разными словами? Не домысливаем ли связи, где их нет? И не упускаем ли там, где они есть? Лишь лучшие тексты способны достичь той ясности, что легко дают простые блоки и стрелочки -
- однозначность списка сущностей. блок либо есть, либо нет. либо один, либо несколько.
- однозначность связей. стрелка либо идет, либо нет. либо в ту сторону, либо обратно.
В более раннем случае, мы решали довольно сложную бизнес задачу, и с какого-то момента стало ясно, что во множественных текстовых требованиях мы легко можем упустить какую-то деталь и схема не заработает. Строго как в электрической схеме - нет одного контакта и ток не течет, только тут деньги вместо тока. Мы нарисовали все сущности, прочертили все связи, пронумеровали их и только затем уже описали текстово их суть - но зато точно были уверены, что все нужные связи есть и никакой сигнал не повиснет в воздухе.
Ни в одном случае мы не упарывались с формальными нотациями типа BPMN, UML и другими. Для ясности хватало просто обозначить блоки, их группировку и связи между ними.
Продолжительное время внедрению диаграмм в оборот препятствовало отсутствие инструмента. Word'ом мы для внутренней документации давно не пользуемся, а в wiki-подобных онлайн системах диаграмма обычно импортировалось как скриншот из другой системы - то есть править ее мог только автор, что сильно ограничивает обычные сценарии совместной работы на требованиями и дизайном. Вначале это решали плагином для draw.io. Сейчас чаша весов начинает склоняться в пользу Miro (которые Realtime Board)
Ни в коем случае, правда, не стоит полагать, что диаграмма это универсальный ключ и решит все проблемы. К примеру, когда мы делали сложный редизайн интерфейса и чтобы ничего не пропустить нарисовали схему всех переходов пользователя и выглядело все очень хорошо. В реальности однако один из переходов был, но был настолько не гладким, что пользователь тупо терялся и не понимал, где он теперь. Отловили до релиза, к счастью.
Мой совет - чертите!
Обычно я не пишу про новости, но тут уж очень хороший повод
Компания Grammarly достигла оценки в $1 млрд, что дает ей статус "единорога"
Я сам пользуюсь grammarly уже год и очень ее рекомендую тем, кому английский по работе нужен (клиенты, заказчики, коллеги и тп), кто его учил-учил, но не доучил. Grammarly интегрируется с браузером, с текстовыми редакторами, и тп - и предлагает вам более правильный текст. В каком-то смысле это робот - частный учитель. Подсказки довольно разумные. Следуя этим правкам, постепенно приучаешься писать лучше, писать правильнее.
Почему это важно:
1) каждый ESL (English as a Second Language) притаскивает в английский гору шаблонов родного языка, которые в английском жутко неправильны
2) есть "эффект Джумшута" - человек, который говорит неправильно, воспринимается второсортным, умственно ущербным. мы смеемся и смотрим сверху вниз на гастарбайтеров с их "начальника..." не в последнюю очередь из-за их языка. и теперь на секунду подумайте, как воспринимается ваша собственная речь и насколько это поможет вашей работе
3) даже без №2, неграмотная фраза затрудняет понимание. какая бы умная мысль не была в голове, что бы умного мы не хотели сказать, все это резко обесценивается тем, что вас просто не понимают.
Вобщем, очень рекомендую
https://vc.ru/finance/87511-it-kompaniya-s-ukrainskimi-kornyami-grammarly-privlekla-90-mln-pri-ocenke-vyshe-1-mlrd?fbclid=IwAR2WCapNvkyN_u3JrBEfyQ4MY8T9KKveNbdqmjzrO9PWhD2goaoCsoQsHg0
Компания Grammarly достигла оценки в $1 млрд, что дает ей статус "единорога"
Я сам пользуюсь grammarly уже год и очень ее рекомендую тем, кому английский по работе нужен (клиенты, заказчики, коллеги и тп), кто его учил-учил, но не доучил. Grammarly интегрируется с браузером, с текстовыми редакторами, и тп - и предлагает вам более правильный текст. В каком-то смысле это робот - частный учитель. Подсказки довольно разумные. Следуя этим правкам, постепенно приучаешься писать лучше, писать правильнее.
Почему это важно:
1) каждый ESL (English as a Second Language) притаскивает в английский гору шаблонов родного языка, которые в английском жутко неправильны
2) есть "эффект Джумшута" - человек, который говорит неправильно, воспринимается второсортным, умственно ущербным. мы смеемся и смотрим сверху вниз на гастарбайтеров с их "начальника..." не в последнюю очередь из-за их языка. и теперь на секунду подумайте, как воспринимается ваша собственная речь и насколько это поможет вашей работе
3) даже без №2, неграмотная фраза затрудняет понимание. какая бы умная мысль не была в голове, что бы умного мы не хотели сказать, все это резко обесценивается тем, что вас просто не понимают.
Вобщем, очень рекомендую
https://vc.ru/finance/87511-it-kompaniya-s-ukrainskimi-kornyami-grammarly-privlekla-90-mln-pri-ocenke-vyshe-1-mlrd?fbclid=IwAR2WCapNvkyN_u3JrBEfyQ4MY8T9KKveNbdqmjzrO9PWhD2goaoCsoQsHg0
vc.ru
ИТ-компания с украинскими корнями Grammarly привлекла $90 млн при оценке выше $1 млрд
Grammarly занимается разработкой онлайн-сервиса для помощи в написании текстов на английском языке.
Зацепился с утра языками про слайды - хорошо или плохо делать презентации для рабочих нужд. Не когда вы делаете выступление, а просто как самодостаточный документ. В этом формате пишут отчеты, предложения, планы и т.п.
Но есть справедливые жалобы. С одной стороны тренеры по публичным выступлениям любят показывать в качестве образца "как не надо" адские "корпоративные" забитые мелким шрифтом или гигантскими сложными схемами слайды. С другой стороны бизнес люди справедливо офигевают от "эффективных слайдов" с какой-нибудь банальностью и стоковой картинкой (образец ниже).
Ну и все уже наверное знают, что в Amazon формат презентаций для запрещен c 2004, и надо всегда писать текстом. Каждый год про это пишут как новость, но это 15 лет уже не новость.
Тем не менее, всякий инструмент это только инструмент.
Слайды имеют ограниченную информационную емкость и поэтому толкают на более ясные и четкие формулировки (подобно твиттеру с его ограничением в 140 символов). Это в целом хорошо.
Не все подталкиваются, это да (тогда рождается "корпоративный" мега слайд со страницей мелкого текста)
Кто-то подменяет ясность банальностью, это да.
Но все это можно успешно делать и без слайдов.
Если план или предложение выглядит пустышкой и банальщиной как слайды, то в форме текста он ... вобщем-то тоже будет пустышкой и банальщиной. НО на осознание этого уйдет больше времени - поскольку читать текст будет в 3-6 раз дольше. На слайд норм тратить 5-10 сек. На страницу текста - уже 30-60 сек. Выигрыш в чтении.
Слайды это не зло само по себе, зло это не умение ясно выражать свою мысль
Но есть справедливые жалобы. С одной стороны тренеры по публичным выступлениям любят показывать в качестве образца "как не надо" адские "корпоративные" забитые мелким шрифтом или гигантскими сложными схемами слайды. С другой стороны бизнес люди справедливо офигевают от "эффективных слайдов" с какой-нибудь банальностью и стоковой картинкой (образец ниже).
Ну и все уже наверное знают, что в Amazon формат презентаций для запрещен c 2004, и надо всегда писать текстом. Каждый год про это пишут как новость, но это 15 лет уже не новость.
Тем не менее, всякий инструмент это только инструмент.
Слайды имеют ограниченную информационную емкость и поэтому толкают на более ясные и четкие формулировки (подобно твиттеру с его ограничением в 140 символов). Это в целом хорошо.
Не все подталкиваются, это да (тогда рождается "корпоративный" мега слайд со страницей мелкого текста)
Кто-то подменяет ясность банальностью, это да.
Но все это можно успешно делать и без слайдов.
Если план или предложение выглядит пустышкой и банальщиной как слайды, то в форме текста он ... вобщем-то тоже будет пустышкой и банальщиной. НО на осознание этого уйдет больше времени - поскольку читать текст будет в 3-6 раз дольше. На слайд норм тратить 5-10 сек. На страницу текста - уже 30-60 сек. Выигрыш в чтении.
Слайды это не зло само по себе, зло это не умение ясно выражать свою мысль
Business Insider
A 2004 email from Jeff Bezos explains why PowerPoint presentations aren't allowed at Amazon
PowerPoint presentations are banned at e-commerce giant Amazon. Here's why.
Очень интересно следить за достижениями на стыке технологий и нейронаук. Прогресс местами пугающий
https://medium.com/@bilb02/adversarial-examples-attacks-against-natural-neural-networks-524b654450e2
Существует способ незаметно для человеческого глаза изменить изображение так, что ИИ ее классифицирует совсем иначе. Например, исследователи обманули ИИ Теслы несколькими наклейками на дорогу и направили его на встречку. НО оказалось, что и человека можно также незаметно обмануть. Тест довольно синтетический - людям давали выбрать между двумя картинками, и ИИ смог незаметными глазу изменениями изменить статистическое распределение в человеческом выборе.
https://www.roadtovr.com/researchers-exploit-natural-quirk-of-human-vision-saccade-hidden-redirected-walking-vr-gtc-2018/amp/
Человеческий глаз смотрит прерывисто (называется “саккады”). И если в момент прерывания картинку сместить, то мозг автоматически и неосознанно подстраивается как будто так было всегда. VRщики придумали пододвигать картинку в эти прерывания и тем менять незаметно для человека его направление движения. Можно в итоге гонять человека по небольшой комнате в полной уверенности, что он идет долго и прямо. Более того, есть видео, где по небольшой комнате гоняют несколько человек, там стоят разные препятствия. А люди ни о соседях, ни о препятствиях не догадываются. Практическое применение само очевидно - для симуляции бесконечных миров в конечных площадках
https://medium.com/@bilb02/adversarial-examples-attacks-against-natural-neural-networks-524b654450e2
Существует способ незаметно для человеческого глаза изменить изображение так, что ИИ ее классифицирует совсем иначе. Например, исследователи обманули ИИ Теслы несколькими наклейками на дорогу и направили его на встречку. НО оказалось, что и человека можно также незаметно обмануть. Тест довольно синтетический - людям давали выбрать между двумя картинками, и ИИ смог незаметными глазу изменениями изменить статистическое распределение в человеческом выборе.
https://www.roadtovr.com/researchers-exploit-natural-quirk-of-human-vision-saccade-hidden-redirected-walking-vr-gtc-2018/amp/
Человеческий глаз смотрит прерывисто (называется “саккады”). И если в момент прерывания картинку сместить, то мозг автоматически и неосознанно подстраивается как будто так было всегда. VRщики придумали пододвигать картинку в эти прерывания и тем менять незаметно для человека его направление движения. Можно в итоге гонять человека по небольшой комнате в полной уверенности, что он идет долго и прямо. Более того, есть видео, где по небольшой комнате гоняют несколько человек, там стоят разные препятствия. А люди ни о соседях, ни о препятствиях не догадываются. Практическое применение само очевидно - для симуляции бесконечных миров в конечных площадках
Medium
Adversarial Examples Attacks against Natural Neural Networks
Most existing artificial neural networks are known to be highly vulnerable to adversarial examples attacks. As Alexey Kurakin, Ian…
Немного расскажу про работу с технической поддержкой - это те, прикованные к пулемету люди, которые прикрывают разработчиков от неприятных слов со стороны клиентов. И затыкают собой все дырки в customer experience.
Масштабируется техническая поддержка трудно и дорого. Неудовлетворенный клиент - это весьма вероятно потерянный клиент. Один сотрудник может обработать только фиксированное число входящих запросов. А много сотрудников это дорого. Итого: проблемный продукт делает удержание клиента дорогим.
Есть в индустрии широко известный показатель CAC = Customer Acquisition Cost, сколько стоит привлечение клиента в бизнес. Например, KupiVip рассказывал, что им привлечение клиента стоит 2000р и зарабатывать магазин начинает только после 3й покупки однажды привлеченного клиента. А есть несколько менее известная метрика CRC = Customer Retention Cost, сколько стоит удержать клиента. Вот туда надо посчитать расходы на тех. поддержку. Например, в хостинге одно обращение в поддержку в год может вывести лишить компанию дохода от этого клиента и оставить один убыток. В нашем бизнесе такое же произойдет для самых маленьких и дешевых клиентов. Поэтому мы боремся за низкое число инцидентов в поддержке даже исходя из чисто экономических соображений, а не только из любви к клиентам.
Что можно сделать для снижения числа инцидентов? Из очевидного, что можно сделать заранее:
1) качественный продукт без багов. бинго! но есть тонкий нюанс - релевантность багов пользовательским сценариям
> Заходит однажды тестировщик в бар.
> и заказывает:
> кружку пива,
> 2 кружки пива,
> 0 кружек пива,
> 999999999 кружек пива,
> ...
> После всего этого в бар заходит первый реальный пользователь и спрашивает, где тут туалет. Бар взрывается.
2) продукт с хорошим UX. Всякая непонятность вызовет вопросы и обращение в поддержку. Возможно, вызовет даже больше обращений, чем баг выше (баг хотя бы не всегда и не у всех срабатывает).
Что можно сделать после (продукт уже вышел)?
3) устранить типичные проблемы. как о них узнать? если поддержку оказывает непосредственно разработка - то все просто. если поддержку оказывает другой отдел - то уже произойдет потеря информации. отдел тех. поддержки решит часть проблем сам и часть более сложных передаст в разработку. Нюанс - не всегда решение наиболее сложных проблем (которые передали) будет более экономически эффективным, чем решение простых и массовых проблем (которые не передали).
Передавать скорее будут проблемы, которые или сложно решить отделом тех. поддержки самостоятельно или вообще невозможно. Цена решения такой проблемы очень высока в поддержке (часы, дни, недели). Но может быть также дорого ее устранение и в разработке. Но возможно , что массовая проблема на 15 минут в поддержке кумулятивно (на десятках и сотнях случаев) стоит в поддержке столько же, как и сложная проблема, а решается в разработке намного дешевле.
Почему не всегда легко узнать о типовых простых проблемах? Если поддержка передана в аутсорс, то аутсорс часто оплачивается за объем. Или за объем и скорость решения. Как легче всего набить объем? На массовом решении инцидентов с типовым известным рецептом. Никакого интереса сообщать о таких инцидентах в разработку аутсорсер не испытывает. Но это не обязательно проблема корыстного интереса. Даже бескорыстный человек не запоминает то, что не было для него проблемой. Вы не помните в каком порядке чистили зубы и какой ботинок застегнули первым. А применить легкое известное решение это не проблема. С какой стороны подступиться?
3.1) если не аутсорс поддержка - то попросить подумать и вспомнить типовые массовые проблемы (здесь есть интерес в общем успехе, так что сработает)
3.2) взять выборку в 100-500 входящих инцидентов и поискать повторы в причинах. Кажется страшным, но это вполне реально сделать.
Масштабируется техническая поддержка трудно и дорого. Неудовлетворенный клиент - это весьма вероятно потерянный клиент. Один сотрудник может обработать только фиксированное число входящих запросов. А много сотрудников это дорого. Итого: проблемный продукт делает удержание клиента дорогим.
Есть в индустрии широко известный показатель CAC = Customer Acquisition Cost, сколько стоит привлечение клиента в бизнес. Например, KupiVip рассказывал, что им привлечение клиента стоит 2000р и зарабатывать магазин начинает только после 3й покупки однажды привлеченного клиента. А есть несколько менее известная метрика CRC = Customer Retention Cost, сколько стоит удержать клиента. Вот туда надо посчитать расходы на тех. поддержку. Например, в хостинге одно обращение в поддержку в год может вывести лишить компанию дохода от этого клиента и оставить один убыток. В нашем бизнесе такое же произойдет для самых маленьких и дешевых клиентов. Поэтому мы боремся за низкое число инцидентов в поддержке даже исходя из чисто экономических соображений, а не только из любви к клиентам.
Что можно сделать для снижения числа инцидентов? Из очевидного, что можно сделать заранее:
1) качественный продукт без багов. бинго! но есть тонкий нюанс - релевантность багов пользовательским сценариям
> Заходит однажды тестировщик в бар.
> и заказывает:
> кружку пива,
> 2 кружки пива,
> 0 кружек пива,
> 999999999 кружек пива,
> ...
> После всего этого в бар заходит первый реальный пользователь и спрашивает, где тут туалет. Бар взрывается.
2) продукт с хорошим UX. Всякая непонятность вызовет вопросы и обращение в поддержку. Возможно, вызовет даже больше обращений, чем баг выше (баг хотя бы не всегда и не у всех срабатывает).
Что можно сделать после (продукт уже вышел)?
3) устранить типичные проблемы. как о них узнать? если поддержку оказывает непосредственно разработка - то все просто. если поддержку оказывает другой отдел - то уже произойдет потеря информации. отдел тех. поддержки решит часть проблем сам и часть более сложных передаст в разработку. Нюанс - не всегда решение наиболее сложных проблем (которые передали) будет более экономически эффективным, чем решение простых и массовых проблем (которые не передали).
Передавать скорее будут проблемы, которые или сложно решить отделом тех. поддержки самостоятельно или вообще невозможно. Цена решения такой проблемы очень высока в поддержке (часы, дни, недели). Но может быть также дорого ее устранение и в разработке. Но возможно , что массовая проблема на 15 минут в поддержке кумулятивно (на десятках и сотнях случаев) стоит в поддержке столько же, как и сложная проблема, а решается в разработке намного дешевле.
Почему не всегда легко узнать о типовых простых проблемах? Если поддержка передана в аутсорс, то аутсорс часто оплачивается за объем. Или за объем и скорость решения. Как легче всего набить объем? На массовом решении инцидентов с типовым известным рецептом. Никакого интереса сообщать о таких инцидентах в разработку аутсорсер не испытывает. Но это не обязательно проблема корыстного интереса. Даже бескорыстный человек не запоминает то, что не было для него проблемой. Вы не помните в каком порядке чистили зубы и какой ботинок застегнули первым. А применить легкое известное решение это не проблема. С какой стороны подступиться?
3.1) если не аутсорс поддержка - то попросить подумать и вспомнить типовые массовые проблемы (здесь есть интерес в общем успехе, так что сработает)
3.2) взять выборку в 100-500 входящих инцидентов и поискать повторы в причинах. Кажется страшным, но это вполне реально сделать.