Forwarded from Qetzal ad libitum, ad infinitum
Ребята из Стэнфорда провели анализ того, как коммьюнити ругаются друг с другом на Реддите: "Community Interaction and Conflict on the Web". Их интересовало как одни коммьюнити атакуют другие и что из этого получается.
Они проанализировали 1.8 миллиарда коментариев за 40 месяцев от 36,000 коммьюнити и около 100 миллиона пользователей. В результате выявили следующие закономерности (надо понимать, что они в первую очередь про сообщества и коммуникацию сообществ друг с другом).
— 0.1% от всех коммьюнити отвечали за 38% всех атак. А 1% от всех коммьюнити отвечали за 74% всех атак. То есть "негативной мобилизацией" или набегами занимается небольшая часть всех коммьюнити, но это их главный фокус.
— Набеги чаще встречаются между похожими коммьюнити (в 1.5 чаще чем между случайными)
— Набег инициируется как правило пользователями, которые в коммьюнити активней среднего. А вот те люди, которые участвуют в самом набеге, как правило менее активны в коммьюнити из которого совершается набег и в прошлом они использовали больше сердитых слов. То же самое и с защитниками: люди, которые защищают атакуемое коммьюнити, как правило в нем менее активны и тоже в прошлом писали более сердитые комментарии.
То есть люди, которые в коммьюнити ради цели коммьюнити, стараются дистанцироваться от срачей, а спорят именно любители спорить.
— Как правило при набеге атакующие общаются с другими атакующими. А защитники с другими защитниками. При этом все атакующие сосредоточивают свое внимание на очень малом числе защитников (около 1%) и общаются именно с ними.
— После набега атакующие часто начинают писать больше в атакуемом сообществе, а защитники — меньше. Набеги могут приводить к "колонизации" чужих сообществ.
— Успешная защита сообщества (когда "колонизации" не происходит) как правило происходит, когда защитники не общаются друг с другом, а активно отвечают каждому атакующему. Причем чем агрессивнее защищающиеся, тем лучше работает защита. Игнорирование не работает — она приводит к "колонизации" сообщества атакующими.
Они проанализировали 1.8 миллиарда коментариев за 40 месяцев от 36,000 коммьюнити и около 100 миллиона пользователей. В результате выявили следующие закономерности (надо понимать, что они в первую очередь про сообщества и коммуникацию сообществ друг с другом).
— 0.1% от всех коммьюнити отвечали за 38% всех атак. А 1% от всех коммьюнити отвечали за 74% всех атак. То есть "негативной мобилизацией" или набегами занимается небольшая часть всех коммьюнити, но это их главный фокус.
— Набеги чаще встречаются между похожими коммьюнити (в 1.5 чаще чем между случайными)
— Набег инициируется как правило пользователями, которые в коммьюнити активней среднего. А вот те люди, которые участвуют в самом набеге, как правило менее активны в коммьюнити из которого совершается набег и в прошлом они использовали больше сердитых слов. То же самое и с защитниками: люди, которые защищают атакуемое коммьюнити, как правило в нем менее активны и тоже в прошлом писали более сердитые комментарии.
То есть люди, которые в коммьюнити ради цели коммьюнити, стараются дистанцироваться от срачей, а спорят именно любители спорить.
— Как правило при набеге атакующие общаются с другими атакующими. А защитники с другими защитниками. При этом все атакующие сосредоточивают свое внимание на очень малом числе защитников (около 1%) и общаются именно с ними.
— После набега атакующие часто начинают писать больше в атакуемом сообществе, а защитники — меньше. Набеги могут приводить к "колонизации" чужих сообществ.
— Успешная защита сообщества (когда "колонизации" не происходит) как правило происходит, когда защитники не общаются друг с другом, а активно отвечают каждому атакующему. Причем чем агрессивнее защищающиеся, тем лучше работает защита. Игнорирование не работает — она приводит к "колонизации" сообщества атакующими.
Ранее я рассказывал как я сам учил английский, а именно отказался от “академического подхода”, который “учит понемного чему-нибудь и как-нибудь” в пользу последовательно научиться читать, писать, слушать и говорить на нужном уровне. У меня был неоднократный опыт публичного выступления на английском языке, то есть я в итоге свою задачу решил.
С похожей проблемой мы столкнулись в обучении сотрудников английскому. Хотя годами в компании английский преподавался многие годы, но общий уровень владения английским не менялся. Люди ходили на занятия год за годом, но практических изменений не наблюдалось. Это заставило искать другие форматы.
С практической точки зрения я могу выделить три уровня владения языком:
Уровень 1. Человек может более-менее корректно писать о технических вопросах - от баг репортов до внутренней документации технических решений. Он может понимать комфортную устную речь (небыструю и без выраженного акцента) как монолог. Его способность говорить устно значения не имеет. Основной инструмент это постановка базовых словаря и грамматики, чтобы построенные им предложения корректно доносили свой смысл.
Чисто теоретически это была задача школы-ВУЗа, но на практике они с этим не справляются совершенно.
Уровень 2. Человек может вести диалоговую переписку на более-менее сложные темы - конфликтные ситуации, понимание позиции собеседника, переговоры, убеждение и т.п. Может говорить и понимать комфортную речь (небыструю и без выраженного акцента) в режиме диалога.
Довольно типовой проблемой оказалось то, что русского человека в английском языке колбасит между двумя полюсами “(+) будет исполнено!” и “(-) твой код говно!”. Соответственно и конструктивное решение нормальных рабочих конфликтов часто невозможно в рамках доступного им словаря.
Уровень 3. Человек свободно ведет диалог на английском. Может писать публичный текст и говорить публично так, чтобы за это не было стыдно
Вот теперь получается нормальный уровень для международной компании.
Соответственно и обучение было выстроено по достижению этих трех уровней:
- Уровень 1 довольно хорошо ложится на классические методы преподавания. Просто надо расслабиться в области устной речи и сосредоточится на более-менее грамотном письме.
- Для уровня 2 мы определили ряд типовых рабочих ситуаций (типа “уронили прод”), на которых школа должна особо фокусироваться, чтобы сотрудник получал нужные слова и выражения.
- Самое сложное это уровень 3. К этому уровню человек набирает довольно много фрагментарных знаний из разных курсов и самообучения, при каждый что-то запомнил неправильно, и с каждой следующей фразой только еще более залипает в своих ошибках. Прогонять людей через курс грамматики на 101-й раз уже смысла нет - им не интересно, да и уже не переучатся. Вместо этого фокус ставится на безжалостную коррекцию ошибок преподавателем. Я с этой техникой столкнулся в экспериментальной школе-стартапе, у которой, к сожалению, не сошлась экономика и она закрылась. Там преподаватель указывал на кучу сделанных ошибок в конце и добивался коррекции привычек. Вплоть до - напиши 100 раз “ я больше не буду …” Это причиняет некоторую боль и требует от преподавателя очень сильных soft skill’ов, но через боль указанных ошибок я смог развиваться далее.
Отладка уровня 3 потребовала подключения к урокам, и нескольких раундов обратной связи преподавателю в стиле “больше тыкать носом в ошибки!”
Преподаватель был носителем языка, так что с тактом и soft skill’ами у него все было прекрасно, и навредить он не мог (с русскими преподавателями это часто сложнее - не в силу знания языка, а в силу носимой культуры).
С похожей проблемой мы столкнулись в обучении сотрудников английскому. Хотя годами в компании английский преподавался многие годы, но общий уровень владения английским не менялся. Люди ходили на занятия год за годом, но практических изменений не наблюдалось. Это заставило искать другие форматы.
С практической точки зрения я могу выделить три уровня владения языком:
Уровень 1. Человек может более-менее корректно писать о технических вопросах - от баг репортов до внутренней документации технических решений. Он может понимать комфортную устную речь (небыструю и без выраженного акцента) как монолог. Его способность говорить устно значения не имеет. Основной инструмент это постановка базовых словаря и грамматики, чтобы построенные им предложения корректно доносили свой смысл.
Чисто теоретически это была задача школы-ВУЗа, но на практике они с этим не справляются совершенно.
Уровень 2. Человек может вести диалоговую переписку на более-менее сложные темы - конфликтные ситуации, понимание позиции собеседника, переговоры, убеждение и т.п. Может говорить и понимать комфортную речь (небыструю и без выраженного акцента) в режиме диалога.
Довольно типовой проблемой оказалось то, что русского человека в английском языке колбасит между двумя полюсами “(+) будет исполнено!” и “(-) твой код говно!”. Соответственно и конструктивное решение нормальных рабочих конфликтов часто невозможно в рамках доступного им словаря.
Уровень 3. Человек свободно ведет диалог на английском. Может писать публичный текст и говорить публично так, чтобы за это не было стыдно
Вот теперь получается нормальный уровень для международной компании.
Соответственно и обучение было выстроено по достижению этих трех уровней:
- Уровень 1 довольно хорошо ложится на классические методы преподавания. Просто надо расслабиться в области устной речи и сосредоточится на более-менее грамотном письме.
- Для уровня 2 мы определили ряд типовых рабочих ситуаций (типа “уронили прод”), на которых школа должна особо фокусироваться, чтобы сотрудник получал нужные слова и выражения.
- Самое сложное это уровень 3. К этому уровню человек набирает довольно много фрагментарных знаний из разных курсов и самообучения, при каждый что-то запомнил неправильно, и с каждой следующей фразой только еще более залипает в своих ошибках. Прогонять людей через курс грамматики на 101-й раз уже смысла нет - им не интересно, да и уже не переучатся. Вместо этого фокус ставится на безжалостную коррекцию ошибок преподавателем. Я с этой техникой столкнулся в экспериментальной школе-стартапе, у которой, к сожалению, не сошлась экономика и она закрылась. Там преподаватель указывал на кучу сделанных ошибок в конце и добивался коррекции привычек. Вплоть до - напиши 100 раз “ я больше не буду …” Это причиняет некоторую боль и требует от преподавателя очень сильных soft skill’ов, но через боль указанных ошибок я смог развиваться далее.
Отладка уровня 3 потребовала подключения к урокам, и нескольких раундов обратной связи преподавателю в стиле “больше тыкать носом в ошибки!”
Преподаватель был носителем языка, так что с тактом и soft skill’ами у него все было прекрасно, и навредить он не мог (с русскими преподавателями это часто сложнее - не в силу знания языка, а в силу носимой культуры).
При этом первая школа, с которой мы начали такую программу, слилась, несмотря на укомплектованность носителями языка. Там было все хорошо с первым преподавателем, но после смены преподавателя стало сильно хуже. Оказалось, что школа просто торгует головами и не обеспечивает никакой методики обучения. Вторая школа ведет занятия в основном силами русских учителей, поэтому в занятиях всегда слышен жесткий акцент (да и фиг с ним!), но зато она очень ориентирована именно на нужный нам практический аспект, так что принципиального взаимопонимания достигли быстро
Горячие новости про GDPR. Немецкий суд признал решение CookieBot, нарушающим GDPR (европейский закон о персональных данных). Фокус в том, что сам CookieBot и есть решение по достижению совместимости с GDPR, и хотя пока еще не все понятно - но сейчас у кучи веб мастеров должны шевельнуться волосы.
Логика суда такая - IP это персональные данные согласно GDPR, IP передается третьей стороне (CookieBot), третья сторона обслуживается в американской хостинговой компании, которая, получается, не подписалась соблюдать GDPR. Упс… Важный нюанс GDPR это транзитивность и рекурсивность - чтобы быть GDPR все твои партнеры по обработке персональных данных тоже должны быть GDPR.
К решению суда есть претензии с точки зрения практичности:
- это некоторая натяжка считать, что хостер прямо участвует в обработке персональных данных.
- так уж устроен интернет, что IP неизбежно светится где попало, и при всех client-side операциях во фронтенде (интеграция CookieBot) это часто вообще неизбежно
- куча конкурентов CookieBot работают на тех же самых принципах, так что и им неизбежно передается IP адрес. Чтобы это решить в корне, надо отказываться от удобного SaaS-решения и заводить свой собственный менеджер кук.
Наверное, оперативное решение для CookieBot и его альтернатив будет в плоскости смены хостинг провайдера на такого, c которым можно будет подписать DPA (Data Processing Agreement), отражающий приверженность провайдера принципам GDPR.
Пока что решение не окончательное и еще будет дополнительно рассматриваться в немецком суде. А также решение немецкого суда не будет мгновенно затрагивать швейцарские компании (не входит напрямую в евросоюз). Но стоит готовится и к неблагоприятному развитию событий
ссылка: https://shopbetreiber-blog.de/2021/12/09/vg-wiesbaden-consent-manager-cookiebot-verstoesst-gegen-dsgvo/
Логика суда такая - IP это персональные данные согласно GDPR, IP передается третьей стороне (CookieBot), третья сторона обслуживается в американской хостинговой компании, которая, получается, не подписалась соблюдать GDPR. Упс… Важный нюанс GDPR это транзитивность и рекурсивность - чтобы быть GDPR все твои партнеры по обработке персональных данных тоже должны быть GDPR.
К решению суда есть претензии с точки зрения практичности:
- это некоторая натяжка считать, что хостер прямо участвует в обработке персональных данных.
- так уж устроен интернет, что IP неизбежно светится где попало, и при всех client-side операциях во фронтенде (интеграция CookieBot) это часто вообще неизбежно
- куча конкурентов CookieBot работают на тех же самых принципах, так что и им неизбежно передается IP адрес. Чтобы это решить в корне, надо отказываться от удобного SaaS-решения и заводить свой собственный менеджер кук.
Наверное, оперативное решение для CookieBot и его альтернатив будет в плоскости смены хостинг провайдера на такого, c которым можно будет подписать DPA (Data Processing Agreement), отражающий приверженность провайдера принципам GDPR.
Пока что решение не окончательное и еще будет дополнительно рассматриваться в немецком суде. А также решение немецкого суда не будет мгновенно затрагивать швейцарские компании (не входит напрямую в евросоюз). Но стоит готовится и к неблагоприятному развитию событий
ссылка: https://shopbetreiber-blog.de/2021/12/09/vg-wiesbaden-consent-manager-cookiebot-verstoesst-gegen-dsgvo/
Прокачанные тимлиды знают, как “продавать” техдолг “бизнесу” - приносишь план, сколько нужно ресурсов, какая будет отдача и так далее. НО вопрос, что же делать мне как “бизнесу”, если
- объем работы по техдолгу установить невозможно
- сколько нужно ресурсов не известно
- какой инкремент получится от вложенного ресурса непонятно
Дело не в том, что инженеры некомпетентны, просто проблема сложная и больше “глубокая”, чем “широкая”. Легко оценить объем, если вы понимаете глубину проблемы в каждом частном случае, и надо только прикинуть число случаев. Но сложно оценить объем, если проблема как луковая шелуха - один слой решил, за ним сразу следующий и сколько их там - никто не знает, поскольку до дна еще никто ни разу не доходил. И вот здесь можно легко застрять - я буду ожидать плана, чтобы дать ресурс. А тимлид не может разрешить неопределенность, чтобы дать план (и недостаточно авантюрен, чтобы высосать план из пальца).
К счастью, я хотя бы могу понять выгоду от этого решения, а значит я могу выступить “спонсором” риска (пост про продажу идеи через спонсора). Сколько максимально людей я могу перебросить на решение этой проблемы с принятием риска, что значимого результата не выйдет? 90% ресурса всегда расписаны жестко, 10% можно маневрировать, 20-30% от этих 10% - это 2-3% команды. Используем их и через одну итерацию получаем дробь - сколько человек за месяц могут добиться какого прогресса. Теперь можно уже реалистично запланировать решение техдолга с честным планом, с пониманием сколько надо откусить от “бизнеса” и на какой срок. Это я с позиций начальника рассказал.
А что же теперь делать тимлиду, начальник которого до такой схемы пока не догадался? Продавайте ему эксперимент. Ресурс, который смогут дать принятием риска, можно оценить по схеме выше. Теперь надо описать какие плюшки могут получиться от этого предприятия и получить ресурс на одну итерацию. Только важно понимать - цель итерации не победа, а “разведка боем”, то есть установить каким темпом эта задача может решаться далее, чтобы принять решение о готовности в нее вписываться. Важно не сделать как можно больше, а получить как можно больше определенности для следующего решения. Если определенности не получили, то все зря (исключая ситуацию что ресурса внезапно хватило на все решение).
Ограничение сверху - метод не работает, если доступного ресурса не достаточно для получения значительного прогресса и достаточной определенности. Если выделенные люди за выделенное время до дна проблемы так и не донырнут, то метод не сработает
- объем работы по техдолгу установить невозможно
- сколько нужно ресурсов не известно
- какой инкремент получится от вложенного ресурса непонятно
Дело не в том, что инженеры некомпетентны, просто проблема сложная и больше “глубокая”, чем “широкая”. Легко оценить объем, если вы понимаете глубину проблемы в каждом частном случае, и надо только прикинуть число случаев. Но сложно оценить объем, если проблема как луковая шелуха - один слой решил, за ним сразу следующий и сколько их там - никто не знает, поскольку до дна еще никто ни разу не доходил. И вот здесь можно легко застрять - я буду ожидать плана, чтобы дать ресурс. А тимлид не может разрешить неопределенность, чтобы дать план (и недостаточно авантюрен, чтобы высосать план из пальца).
К счастью, я хотя бы могу понять выгоду от этого решения, а значит я могу выступить “спонсором” риска (пост про продажу идеи через спонсора). Сколько максимально людей я могу перебросить на решение этой проблемы с принятием риска, что значимого результата не выйдет? 90% ресурса всегда расписаны жестко, 10% можно маневрировать, 20-30% от этих 10% - это 2-3% команды. Используем их и через одну итерацию получаем дробь - сколько человек за месяц могут добиться какого прогресса. Теперь можно уже реалистично запланировать решение техдолга с честным планом, с пониманием сколько надо откусить от “бизнеса” и на какой срок. Это я с позиций начальника рассказал.
А что же теперь делать тимлиду, начальник которого до такой схемы пока не догадался? Продавайте ему эксперимент. Ресурс, который смогут дать принятием риска, можно оценить по схеме выше. Теперь надо описать какие плюшки могут получиться от этого предприятия и получить ресурс на одну итерацию. Только важно понимать - цель итерации не победа, а “разведка боем”, то есть установить каким темпом эта задача может решаться далее, чтобы принять решение о готовности в нее вписываться. Важно не сделать как можно больше, а получить как можно больше определенности для следующего решения. Если определенности не получили, то все зря (исключая ситуацию что ресурса внезапно хватило на все решение).
Ограничение сверху - метод не работает, если доступного ресурса не достаточно для получения значительного прогресса и достаточной определенности. Если выделенные люди за выделенное время до дна проблемы так и не донырнут, то метод не сработает
Перепощу сюда объяснение на пальцах почему иностранная компания может не воспринимать уход из России как большую потерю. В комментариях к новостям про уход люди не понимают, как же так люди, что бросают бизнес, ведь это большие деньги и т.п.
Возьмем обычный международный бизнес с долей выручки в РФ около 1-2%. бОльшая доля (например как 7% у Леруа) это скорее исключение и такие компании себя ожидаемо ведут иначе (Леруа не стал уходить).
Стоимость компании обычно оценивают как ebitda * N, где N это так называемый мультипликатор, специфичный как для индустрии (в плане общего масштаба), так и для конкретного бизнеса (в плане конкретного значения). Мультипликатор 20 это прямо очень хорошо. На каких-то рынках оценивают не по ebitda, а по выручке, но это ничего принципиально в рассуждениях не меняет.
Теперь положим, что у бизнеса ebitda 100 млн долларов и мультипликатор 20. Бросить российский рынок это потеря 20-40 млн долларов оценки (те самые 1-2%, которые доля российского рынка во всем бизнесе). Печальная потеря, да.
Теперь посмотрим, что будет, если не бросить . За ведение дел в мутной и непредсказуемой юрисдикции мультипликатор снизится ну пусть всего на 1 (единица). Потеря в оценке компании - сразу же 100млн долларов. 100 млн это в 2.5-5 раз хуже, чем 20-40 млн потерь это ухода; Отметим, что если мультипликатор скромнее, чем 20, то влияние этой субъективной оценки может быть еще больше.
Теперь подумаем, что скажут инвесторы руководству компании и какие решения они потребуют принять?
Далее, более-менее приличный бизнес растет ну хотя бы на 1-2% в год. То есть на следующий год все потери от утраченного российского рынка компания отыграет назад. Это вполне можно объяснить инвесторам, что был неудачный год, особые обстоятельства и так далее, но теперь все будет хорошо и динамика дальше отличная - это многие компании проходили в ковид, инвесторы это поймут и примут. Самое главное, что впереди хороший прогноз. Оценка компании уже не сильно пострадает - потому что та прошлая проблема уже решена, а впереди все ровно, и мультипликатор зависит главным образом от дальнейших ожиданий.
Все совпадения случайны, цифры условны. Голые цифры и ничего личного
Возьмем обычный международный бизнес с долей выручки в РФ около 1-2%. бОльшая доля (например как 7% у Леруа) это скорее исключение и такие компании себя ожидаемо ведут иначе (Леруа не стал уходить).
Стоимость компании обычно оценивают как ebitda * N, где N это так называемый мультипликатор, специфичный как для индустрии (в плане общего масштаба), так и для конкретного бизнеса (в плане конкретного значения). Мультипликатор 20 это прямо очень хорошо. На каких-то рынках оценивают не по ebitda, а по выручке, но это ничего принципиально в рассуждениях не меняет.
Теперь положим, что у бизнеса ebitda 100 млн долларов и мультипликатор 20. Бросить российский рынок это потеря 20-40 млн долларов оценки (те самые 1-2%, которые доля российского рынка во всем бизнесе). Печальная потеря, да.
Теперь посмотрим, что будет, если не бросить . За ведение дел в мутной и непредсказуемой юрисдикции мультипликатор снизится ну пусть всего на 1 (единица). Потеря в оценке компании - сразу же 100млн долларов. 100 млн это в 2.5-5 раз хуже, чем 20-40 млн потерь это ухода; Отметим, что если мультипликатор скромнее, чем 20, то влияние этой субъективной оценки может быть еще больше.
Теперь подумаем, что скажут инвесторы руководству компании и какие решения они потребуют принять?
Далее, более-менее приличный бизнес растет ну хотя бы на 1-2% в год. То есть на следующий год все потери от утраченного российского рынка компания отыграет назад. Это вполне можно объяснить инвесторам, что был неудачный год, особые обстоятельства и так далее, но теперь все будет хорошо и динамика дальше отличная - это многие компании проходили в ковид, инвесторы это поймут и примут. Самое главное, что впереди хороший прогноз. Оценка компании уже не сильно пострадает - потому что та прошлая проблема уже решена, а впереди все ровно, и мультипликатор зависит главным образом от дальнейших ожиданий.
Все совпадения случайны, цифры условны. Голые цифры и ничего личного
Мы переводим свой софт на очень много языков. Но ни один язык не вызывал столько проблем у нас как арабский. Ну ладно, что он справа-налево и пришлось весь интерфейс продукта зеркально развернуть - это труд, но не сложность.
Сложность арабского в том, что он оказался "ничейный". Все языки у нас идентифицируются по стандартной схеме ll-CC (язык-страна, en-US к примеру), еще со времен перевода на "бразильский португальский". Чаще всего мы поддерживаем только один региональный вариант (например у нас нет "британского английского", только "американский"), но тем не менее эти региональные варианты существенно отличаются мы не должны вводить в заблуждение.
А вот арабский у нас получился как раз "обобщенный" и "ничейный" и ни к одной из 16 арабских стран не принадлежащий. Если канадские французы французский-французский используют немного морщась, но без особых претензий, то йеменцу саудовская аравия может прямо совершенно не зайти чисто по политическим мотивам.
После ожесточенных споров в духе сунниты против шиитов, пришлось исключительно для арабского вернуть идентификацию по языку без страны обратно ("ar").
Сложность арабского в том, что он оказался "ничейный". Все языки у нас идентифицируются по стандартной схеме ll-CC (язык-страна, en-US к примеру), еще со времен перевода на "бразильский португальский". Чаще всего мы поддерживаем только один региональный вариант (например у нас нет "британского английского", только "американский"), но тем не менее эти региональные варианты существенно отличаются мы не должны вводить в заблуждение.
А вот арабский у нас получился как раз "обобщенный" и "ничейный" и ни к одной из 16 арабских стран не принадлежащий. Если канадские французы французский-французский используют немного морщась, но без особых претензий, то йеменцу саудовская аравия может прямо совершенно не зайти чисто по политическим мотивам.
После ожесточенных споров в духе сунниты против шиитов, пришлось исключительно для арабского вернуть идентификацию по языку без страны обратно ("ar").
HR-минутка. Кто уехал за границу не с компанией, а самостоятельно - тому может понадобиться новая работа, не все компании терпят удаленку за границей как по внутренним причинам, так и в силу мутности российского закона в этой области (есть интерпретация, что это вообще не разрешается - хотя я с ней не согласен).
В ходе недавнего обсужения сформулировали несколько советов со стороны компании:
1) спрос точно есть. в уехавших компаниях уехали не все сотрудники. это создает дыры от 10% до 50% персонала, которые им надо замещать. найм идет, спрос есть, без работы не останешься
2) если обращаться в уехавшие российские компании, или в компании с господством русскоговорящих (более верное слово, поскольку вовсе не все из России) в их ИТ, то слабый английский резко становится намного меньшей проблемой - это теперь проблема быта, а не работы. Опять же эти компании привычны к иммиграционным вопросам. Это кратно проще, чем пробиваться в старую добрую исконно-иностранную компанию.
3) часть уехавших крупных компаний (примерно половина проверенной мной выборки) не публикуют вакансии в hh.ru и России вообще. Но это не значит, что вакансий нет. Полистайте чатики, попросите вам в личку написать - какие конторы уехали (не все об этом громко говорят), где найм идет. Посмотрите корп.сайты известных вам контор.
4) рекрутеры землю роют, их много, они носят кандидатов компаниям - обойти их всех вы устанете, но попадите им на радар, заведите себе хороший профиль в HH и Linkedin. К каким-то 5-10 известным рекрутерам сами сходите. Вот newhr завели ботика к примеру https://yangx.top/newhrglobalbot
Мы сами все еще ищем
- руководителя devops команды. коммуникатор, организатор, горящие глаза, меломан инфраструктурно-облачных вопросов, девелоперский опыт обязательно. чтобы все четенько и с огоньком.
- linux инженера. чтобы на уровне всяких системных сервисов собирать, патчить, интегрировать, конфигурировать, писать обвязки на go/c++/ python/shell (по обстоятельствам). это все код, не админство. в ядро лазить не придется
Если кого такого знаете - пишите в личку (есть в описании канала), дам контакты.
В ходе недавнего обсужения сформулировали несколько советов со стороны компании:
1) спрос точно есть. в уехавших компаниях уехали не все сотрудники. это создает дыры от 10% до 50% персонала, которые им надо замещать. найм идет, спрос есть, без работы не останешься
2) если обращаться в уехавшие российские компании, или в компании с господством русскоговорящих (более верное слово, поскольку вовсе не все из России) в их ИТ, то слабый английский резко становится намного меньшей проблемой - это теперь проблема быта, а не работы. Опять же эти компании привычны к иммиграционным вопросам. Это кратно проще, чем пробиваться в старую добрую исконно-иностранную компанию.
3) часть уехавших крупных компаний (примерно половина проверенной мной выборки) не публикуют вакансии в hh.ru и России вообще. Но это не значит, что вакансий нет. Полистайте чатики, попросите вам в личку написать - какие конторы уехали (не все об этом громко говорят), где найм идет. Посмотрите корп.сайты известных вам контор.
4) рекрутеры землю роют, их много, они носят кандидатов компаниям - обойти их всех вы устанете, но попадите им на радар, заведите себе хороший профиль в HH и Linkedin. К каким-то 5-10 известным рекрутерам сами сходите. Вот newhr завели ботика к примеру https://yangx.top/newhrglobalbot
Мы сами все еще ищем
- руководителя devops команды. коммуникатор, организатор, горящие глаза, меломан инфраструктурно-облачных вопросов, девелоперский опыт обязательно. чтобы все четенько и с огоньком.
- linux инженера. чтобы на уровне всяких системных сервисов собирать, патчить, интегрировать, конфигурировать, писать обвязки на go/c++/ python/shell (по обстоятельствам). это все код, не админство. в ядро лазить не придется
Если кого такого знаете - пишите в личку (есть в описании канала), дам контакты.
В ходе стороннего обсуждения всплыл вопрос о продуктизации внутренних решений, о выводе их на рынок.
Рано или поздно, наверное, всякая компания достигает такой степени насыщения, когда ей интересны новые поляны, и поэтому такие предложения встречают поддержку. Но есть большой подводный камень - и это не технология, а аудитория.
Возьмем пример, что компания занималась онлайн бронированиями отелей и разработала внутри мощный софт для бухгалтерии. Все ресурсы компании настроены на продвижение на конкретном B2C рынке (бронирования). Есть навыки, есть специалисты. Теперь кто-то хочет инициативно предложить софт для бухгалтерии (B2B) - это другая область, это другие методы продвижения продукта. У компании нет готовых навыков и специалистов.
Пример достаточно универсален, потому что с огромной вероятностью внутренний продукт окажется ориентирован на другой рынок, на который оказывалась основная услуга.
По подобные инициативы делаются чаще внутренними силами в режиме "посмотрим - попробуем". Если внутренние силы не смогут преодолеть барьер новизны - инициатива не удастся и похоронится. Соответственно, именно привлечение аудитории (а не изготовление продукта) должно быть главной заботой такого инициативного человека.
На этом месте где-то вдалеке засмеялся Морейнис и все остальные инвесторы и около-инвесторы, для кого аксиома, что продукт начинается не с решения, а с покупателя. Кстати, если вы не читаете человека по фамилии Морейнис и как-то работает над созданием продуктов - то моя личная рекомендация на него подписаться.
Соответсвенно в данном примере начинать надо с обращения к нескольким знакомым вашей бухгалтерии (тоже бухгалтерам) и поиску среди них первых пользователей. Если таковые найдутся, то шанс прорваться через барьер незнания, где ловить покупателей, станут раз в 10 выше.
Рано или поздно, наверное, всякая компания достигает такой степени насыщения, когда ей интересны новые поляны, и поэтому такие предложения встречают поддержку. Но есть большой подводный камень - и это не технология, а аудитория.
Возьмем пример, что компания занималась онлайн бронированиями отелей и разработала внутри мощный софт для бухгалтерии. Все ресурсы компании настроены на продвижение на конкретном B2C рынке (бронирования). Есть навыки, есть специалисты. Теперь кто-то хочет инициативно предложить софт для бухгалтерии (B2B) - это другая область, это другие методы продвижения продукта. У компании нет готовых навыков и специалистов.
Пример достаточно универсален, потому что с огромной вероятностью внутренний продукт окажется ориентирован на другой рынок, на который оказывалась основная услуга.
По подобные инициативы делаются чаще внутренними силами в режиме "посмотрим - попробуем". Если внутренние силы не смогут преодолеть барьер новизны - инициатива не удастся и похоронится. Соответственно, именно привлечение аудитории (а не изготовление продукта) должно быть главной заботой такого инициативного человека.
На этом месте где-то вдалеке засмеялся Морейнис и все остальные инвесторы и около-инвесторы, для кого аксиома, что продукт начинается не с решения, а с покупателя. Кстати, если вы не читаете человека по фамилии Морейнис и как-то работает над созданием продуктов - то моя личная рекомендация на него подписаться.
Соответсвенно в данном примере начинать надо с обращения к нескольким знакомым вашей бухгалтерии (тоже бухгалтерам) и поиску среди них первых пользователей. Если таковые найдутся, то шанс прорваться через барьер незнания, где ловить покупателей, станут раз в 10 выше.
Периодически сталкиваюсь с отношением, что "некогда тратить время на отчеты и прогнозы, делать надо".
Делать это очень хорошо. Однако, представьте, что вы наняли себе отделочников на ремонт квартиры. Ну или еще что-то - в моем случае плотники беседку делали. Вот они месяц трудятся, два трудятся. Но не могут сказать, сколько им еще нужно материалов, не могут сказать, когда закончат. Вы не можете понять, как вы следующие этапы планировать - к когда мебель привозить, к когда самим въезжать. Важно ли в конце, что они закончили работу на неделю раньше, чем если бы потратили какое-то время на планирование? На неделю раньше чего? У вас же в голове никакой даты не было. Единственная дата в вашей системе отчета, это когда вы начали спрашивать о времени окончания работ. Ваши рабочие в этой системе восприятия вообще не имеют шанса закончить раньше, они только опаздывают от даты, когда вы первый раз спросили.
Можно приводить еще кучу примеров - с поездками на такси, и т.п. Их всех объединит один простой принцип - в восприятии заказчика "скорость не важна, если нет предсказуемости". Опережать имеет смысл только ранее выданное предсказание, а без него можно только безнадежно опаздывать от ожиданий заказчика.
Делать это очень хорошо. Однако, представьте, что вы наняли себе отделочников на ремонт квартиры. Ну или еще что-то - в моем случае плотники беседку делали. Вот они месяц трудятся, два трудятся. Но не могут сказать, сколько им еще нужно материалов, не могут сказать, когда закончат. Вы не можете понять, как вы следующие этапы планировать - к когда мебель привозить, к когда самим въезжать. Важно ли в конце, что они закончили работу на неделю раньше, чем если бы потратили какое-то время на планирование? На неделю раньше чего? У вас же в голове никакой даты не было. Единственная дата в вашей системе отчета, это когда вы начали спрашивать о времени окончания работ. Ваши рабочие в этой системе восприятия вообще не имеют шанса закончить раньше, они только опаздывают от даты, когда вы первый раз спросили.
Можно приводить еще кучу примеров - с поездками на такси, и т.п. Их всех объединит один простой принцип - в восприятии заказчика "скорость не важна, если нет предсказуемости". Опережать имеет смысл только ранее выданное предсказание, а без него можно только безнадежно опаздывать от ожиданий заказчика.
Зацепились языками на конференции про мерч/лут/раздаточные сувениры. Мой собеседник их никогда не берет, поскольку не хочет умножать количество мусора на планете. Я тоже не люблю мусор, но практический вывод в отношении мерча у меня немного другой.
Я лично глубоко убежден, что всякая раздатка должна быть качественной и полезной. Недопустимо делать раздатку, которая отправится в мусор. Когда сотрудники или клиенты отправляют в мусор мерч какого-то бреда - туда же в мусор отправляется по крайней мере частично и отношение к этой компании. Выстраивается неизбежный ассоциативный ряд - эта компания трешовая.
Это мое убеждение имеет полу-религиозный характер, поскольку убедительно доказать его на цифрах затрудительно. Где моего веса и влияния хватает, там я эту мысль в нашей компании реализую. Где не хватает - ну там включается классика.
Я лично глубоко убежден, что всякая раздатка должна быть качественной и полезной. Недопустимо делать раздатку, которая отправится в мусор. Когда сотрудники или клиенты отправляют в мусор мерч какого-то бреда - туда же в мусор отправляется по крайней мере частично и отношение к этой компании. Выстраивается неизбежный ассоциативный ряд - эта компания трешовая.
Это мое убеждение имеет полу-религиозный характер, поскольку убедительно доказать его на цифрах затрудительно. Где моего веса и влияния хватает, там я эту мысль в нашей компании реализую. Где не хватает - ну там включается классика.
В последние несколько лет кандидатам стало не нравиться делать тестовые задания. Они требуют много времени, подаются люди сразу в пачку компаний - понятно, что ТЗ обременяет. Рабочая альтернатива ТЗ это лайв-кодинг. Фиксированный слот времени, типовые задания делаются под присмотром сотрудника.
Плюсы лайв-кодинга очевидны:
+ (для кандидата) меньше времени вложено
+ (для компании) кандидат как на ладони виден, все в реальном времени.
Есть и минусы лайв-кодинга:
- (для компании) в несколько раз больше времени на наблюдение и оценку. ТЗ можно и за 15-30 минут проверять, а тут минимум час сидеть и следить.
- (для кандидата) все в живую, часики бегут. Нельзя досмотреть, дочитать, догуглить как это было с ТЗ - это наименее очевидный пункт имхо
Со стороны компании меня всегда устраивало, что с ТЗ можно было дочитать, догуглить, и сделать задание на ожидаемом уровне, даже не имея изначально каких-то знаний или опыта. Нет принципиальной разницы между человеком, который умеет, и который может быстро научиться. И сделанное ТЗ заверяло, что одно из двух есть.
При этом у меня есть гипотеза, что переход на лайв-кодинг наименее выгоден для тех, кто больше всех был недоволен затратами времени на ТЗ. Обычно ТЗ задумывалось таким, чтобы его можно было сделать за вечер. Это несколько больше чем 1-2 часа лайв-кодинга, но имхо не принципиально больше, чтобы быть решающим. Однако, если кандидату надо было что-то изучать для выполнения ТЗ, то это уже требовало нескольких вечеров. Затраты значительные и возмущение понятно, НО проскочить лайв-кодинг такому человеку становится наоборот труднее.
Уже были прецеденты, что кандидаты провалившие лайв-кодинг, просили перетестировать их по ТЗ, но поддерживать две системы и сравнивать людей по двум разным системам уже неудобно и мы на это не шли.
Поскольку это только гипотеза, то интересно услышать подтверждения-опровержения из вашего опыта в комментариях
Плюсы лайв-кодинга очевидны:
+ (для кандидата) меньше времени вложено
+ (для компании) кандидат как на ладони виден, все в реальном времени.
Есть и минусы лайв-кодинга:
- (для компании) в несколько раз больше времени на наблюдение и оценку. ТЗ можно и за 15-30 минут проверять, а тут минимум час сидеть и следить.
- (для кандидата) все в живую, часики бегут. Нельзя досмотреть, дочитать, догуглить как это было с ТЗ - это наименее очевидный пункт имхо
Со стороны компании меня всегда устраивало, что с ТЗ можно было дочитать, догуглить, и сделать задание на ожидаемом уровне, даже не имея изначально каких-то знаний или опыта. Нет принципиальной разницы между человеком, который умеет, и который может быстро научиться. И сделанное ТЗ заверяло, что одно из двух есть.
При этом у меня есть гипотеза, что переход на лайв-кодинг наименее выгоден для тех, кто больше всех был недоволен затратами времени на ТЗ. Обычно ТЗ задумывалось таким, чтобы его можно было сделать за вечер. Это несколько больше чем 1-2 часа лайв-кодинга, но имхо не принципиально больше, чтобы быть решающим. Однако, если кандидату надо было что-то изучать для выполнения ТЗ, то это уже требовало нескольких вечеров. Затраты значительные и возмущение понятно, НО проскочить лайв-кодинг такому человеку становится наоборот труднее.
Уже были прецеденты, что кандидаты провалившие лайв-кодинг, просили перетестировать их по ТЗ, но поддерживать две системы и сравнивать людей по двум разным системам уже неудобно и мы на это не шли.
Поскольку это только гипотеза, то интересно услышать подтверждения-опровержения из вашего опыта в комментариях
Помните веселую картинку про оргчарты разных компаний, где майкрософт во все стороны ощетинился пистолетами (ниже)?
Она иллюстрирует проблему кучи организаций, где на границе отделов возникает "мы против они". Неплохим решением является ликвидация границ и слияние в одну команду. На моей памяти это и правда в корне решало болезненные противостояния. Правда с этим методом есть один нюанс - "всякая проблема решается добавлением слоя абстракции, кроме проблемы слишком большого числа слоев абстракции" - слить прямо вот все-все-все не выйдет (ну или выйдет неприкольно). Где-то будут границы. Сольем все функции в команду полного цикла? Тогда будут границы между несколькими командами. Упс.
Еще вариант - команды разные, но начальник один, он рассудит. Тоже работает, но снова у начальника есть лимит емкости. Организационное перепахивание имеет свой предел эффективности.
Но часто упускают из виду второй эффективный инструмент сотрудничества - это не организационные перестановки, а дизайн правильных "институтов" коммуникации. То есть само-поддерживающихся систем, которые распространяют информацию и принуждают к определенному поведению.
Например, на заре своей работы я попал в компанию, где с духом кооперации все было не ахти, команда на команду и лидер на лидера волком смотрят, каких-то людей для кросс-командной координации не выделено, НО весь софт магически работал совместимо друг с другом БЕЗ особого администрирования над командами. Был простой институт в виде рассылки "я выпускаюсь и ручаюсь, что совместимость сохранил" + принцип "кто сломал, тот лох". Все. Два простых принципа и на нем сотрудничество работало много лет без какой-либо любви к сотрудничеству.
Вобщем, не стоит забывать про этот второй пласт инструментов. Орг.диаграмма, как ее не рисуй, все таки разделяет. А институты коммуникации объединяют.
Она иллюстрирует проблему кучи организаций, где на границе отделов возникает "мы против они". Неплохим решением является ликвидация границ и слияние в одну команду. На моей памяти это и правда в корне решало болезненные противостояния. Правда с этим методом есть один нюанс - "всякая проблема решается добавлением слоя абстракции, кроме проблемы слишком большого числа слоев абстракции" - слить прямо вот все-все-все не выйдет (ну или выйдет неприкольно). Где-то будут границы. Сольем все функции в команду полного цикла? Тогда будут границы между несколькими командами. Упс.
Еще вариант - команды разные, но начальник один, он рассудит. Тоже работает, но снова у начальника есть лимит емкости. Организационное перепахивание имеет свой предел эффективности.
Но часто упускают из виду второй эффективный инструмент сотрудничества - это не организационные перестановки, а дизайн правильных "институтов" коммуникации. То есть само-поддерживающихся систем, которые распространяют информацию и принуждают к определенному поведению.
Например, на заре своей работы я попал в компанию, где с духом кооперации все было не ахти, команда на команду и лидер на лидера волком смотрят, каких-то людей для кросс-командной координации не выделено, НО весь софт магически работал совместимо друг с другом БЕЗ особого администрирования над командами. Был простой институт в виде рассылки "я выпускаюсь и ручаюсь, что совместимость сохранил" + принцип "кто сломал, тот лох". Все. Два простых принципа и на нем сотрудничество работало много лет без какой-либо любви к сотрудничеству.
Вобщем, не стоит забывать про этот второй пласт инструментов. Орг.диаграмма, как ее не рисуй, все таки разделяет. А институты коммуникации объединяют.
В рубрике “зацепившись языками” - столкнулся с тезисом, что нельзя оценивать старые рынки для оценки популярности новых решений.
Примером было, что в 1980 году McKinsey обосновали компании AT&T, что рынок мобильной связи в США не превысит 900 тыс человек к 2000 году, поскольку мобильные тогда были громоздкими, неудобными и страшно дорогими. В реальности, уже к 1992 году мобильных в США было 12 млн и это число быстро росло (в 1994 уже 24 млн), а вес телефона снизился до “всего” 250г. К 2000му году число мобильных пользователей достигло 109 млн. Ошибка стоила AT&T 12.6 млрд долларов на покупку мобильного оператора, чтобы догнать.
Следующим примером было, что также глупо было бы оценить рынок авто по количеству лошадей. А вот здесь уже не работает - в США в 1910 году (доавтомобильная эра) было 25 млн лошадей. А в 1950 году (автомобильная эра) было … 25 млн автомобилей. Ну потому что автомобили первым делом заняли собственно ровно ту нишу, которую прежде занимали лошади.
Примером было, что в 1980 году McKinsey обосновали компании AT&T, что рынок мобильной связи в США не превысит 900 тыс человек к 2000 году, поскольку мобильные тогда были громоздкими, неудобными и страшно дорогими. В реальности, уже к 1992 году мобильных в США было 12 млн и это число быстро росло (в 1994 уже 24 млн), а вес телефона снизился до “всего” 250г. К 2000му году число мобильных пользователей достигло 109 млн. Ошибка стоила AT&T 12.6 млрд долларов на покупку мобильного оператора, чтобы догнать.
Следующим примером было, что также глупо было бы оценить рынок авто по количеству лошадей. А вот здесь уже не работает - в США в 1910 году (доавтомобильная эра) было 25 млн лошадей. А в 1950 году (автомобильная эра) было … 25 млн автомобилей. Ну потому что автомобили первым делом заняли собственно ровно ту нишу, которую прежде занимали лошади.
Tumblr
storyfund
McKinsey’s Estimates of the Cell Phone Market In 1980, AT&T commissioned McKinsey & Company to predict cell phone usage in the United States by 2000. The consulting group argued that cellular...
Вброшу очень старый и когда-то популярный, а ныне редко упоминаемый, но все еще не утративший актуальности текст про черных и белых обезьян.
Если вы его в своей жизни пропустили, то имеет смысл прочитать. Если когда-то читали, то перечитать еще раз.
Когда-то очень давно этот текст казался мне сатирой на менеджеров (белых обезьян). Потом сатирой на инженеров (черных обезьян). А сейчас мне кажется, что в нем есть много уроков на подумать.
Текст многогранный, и в зависимости от текущего уровня осознанности срабатывают разные наборы триггеров, захватывая внимание по разному и рассказывая разные истории. Каждый увидит в тексте разное, и в этом нет ничего плохого, но свое понимание можно использовать для само-калибровки. Пересказывать не буду, там чтение недолгое, а фрагменты не передают всей картины.
Если вы его в своей жизни пропустили, то имеет смысл прочитать. Если когда-то читали, то перечитать еще раз.
Когда-то очень давно этот текст казался мне сатирой на менеджеров (белых обезьян). Потом сатирой на инженеров (черных обезьян). А сейчас мне кажется, что в нем есть много уроков на подумать.
Текст многогранный, и в зависимости от текущего уровня осознанности срабатывают разные наборы триггеров, захватывая внимание по разному и рассказывая разные истории. Каждый увидит в тексте разное, и в этом нет ничего плохого, но свое понимание можно использовать для само-калибровки. Пересказывать не буду, там чтение недолгое, а фрагменты не передают всей картины.
Monkey-Habits
Книга "Повадки обезьян" (Юрий Шевченко)
По каким законам живут большие компании и международные корпорации? Обязательный учебный материал для получения степени MBA (Master of Banana Administration).
ПРИМИТИВНЫЕ РЕЦЕПТЫ
При каких-то совместных проектах в большой организации может возникать неприятное когнитивное искажение, когда “исполнитель” вкалывает над скоростным решением проблем, а “заказчику” все мало и он жалуется, как вы плохо стараетесь и медленно его обслуживаете.
Возникает это, если команды “исполнитель” и “заказчик” из разных организаций (не образуют одной большЕй команды) плюс “исполнитель” делает кроме этого проекта еще и какую-то обычную работу или даже много других работ.
Искажение возникает от того, что свои собственные задачи “заказчик” видит как “длящиеся”, то есть занимающие время и ресурс. А вот такие проблемы на стороне “заказчик” воспринимает как “точечные” - я багу завел, а они пусть быстренько исправят. Не возникает понимания, что при этом тоже тратится какой-то ограниченный ресурс, и что дробь задача/ресурс образует какое-то существенное время.
Этому более подвержены ситуации, которые кажутся “заказчику” как баги (отклонения от ожиданий). И менее подвержены задачи, когда “заказчик” явно хочет, чтобы на той стороне что-то очень сильно переделали.
Как решение “исполнителю” надо уходить от отчета на стендах галочками “сделал”/“не сделал” и переходить к отчету “работаю над этим до такого-то числа, а потом над этим до такого-то”, формируя восприятие себя как такой же ресурс “заказчика”, что и его собственный.
Другое решение это, конечно же, просто явная передача человека "заказчику" на время , но это не всегда приемлемо.
При каких-то совместных проектах в большой организации может возникать неприятное когнитивное искажение, когда “исполнитель” вкалывает над скоростным решением проблем, а “заказчику” все мало и он жалуется, как вы плохо стараетесь и медленно его обслуживаете.
Возникает это, если команды “исполнитель” и “заказчик” из разных организаций (не образуют одной большЕй команды) плюс “исполнитель” делает кроме этого проекта еще и какую-то обычную работу или даже много других работ.
Искажение возникает от того, что свои собственные задачи “заказчик” видит как “длящиеся”, то есть занимающие время и ресурс. А вот такие проблемы на стороне “заказчик” воспринимает как “точечные” - я багу завел, а они пусть быстренько исправят. Не возникает понимания, что при этом тоже тратится какой-то ограниченный ресурс, и что дробь задача/ресурс образует какое-то существенное время.
Этому более подвержены ситуации, которые кажутся “заказчику” как баги (отклонения от ожиданий). И менее подвержены задачи, когда “заказчик” явно хочет, чтобы на той стороне что-то очень сильно переделали.
Как решение “исполнителю” надо уходить от отчета на стендах галочками “сделал”/“не сделал” и переходить к отчету “работаю над этим до такого-то числа, а потом над этим до такого-то”, формируя восприятие себя как такой же ресурс “заказчика”, что и его собственный.
Другое решение это, конечно же, просто явная передача человека "заказчику" на время , но это не всегда приемлемо.
В разговоре вслыла идея, что индексом цитирования Дилберта можно надежно мерить мораль в организации, даже если люди не хотят отвечать на опросники. Чем больше этих веселых картинок ходит - тем выше недовольство и напряжение.
Как показало гугление - "все уже украдено до нас" и Dilbert Index придумали 12 лет назад. Впрочем, судя по малому числу упоминаний - это изобретение осталось незамеченным.
Если бы сайт dilbert.com оставался жив, то могли бы сделать рейтинг по компаниям, продавать им аналитику, написать своих ботов для мессенджеров, чтобы считать репосты. Распространяемая картинка автоматически бы идентифицировала собой беспокояющую тему. Но это все в какой-то альтернативной реальности.
Как показало гугление - "все уже украдено до нас" и Dilbert Index придумали 12 лет назад. Впрочем, судя по малому числу упоминаний - это изобретение осталось незамеченным.
Если бы сайт dilbert.com оставался жив, то могли бы сделать рейтинг по компаниям, продавать им аналитику, написать своих ботов для мессенджеров, чтобы считать репосты. Распространяемая картинка автоматически бы идентифицировала собой беспокояющую тему. Но это все в какой-то альтернативной реальности.
Некоторый парадокс получается с применением AI для автоматических переводов. Мы переводим продукт на очень много языков и это стоит приличных денег, поэтому такая оптимизация интересна. Но это все-таки не рилзы переводить, продукт платный, есть ответственность и есть какие-то стандарты качества.
Эксперименты показали, что
- 80% автоперевода сейчас уже ок и не требуют коррекции. Но 20% это довольно много и соответственно люди все еще нужны - читать надо все 100% текста + 20% править. В итоге расходы, конечно, меньше, но совсем не в пять раз, а примерно на треть.
- чем меньше контекст, тем хуже результат. лучше всего переводится документация (длинный связный текст), хуже всего короткие подписи в интерфейсе. ну или пока не придумали, как AI должен понимать смысл кнопок прямо из интерфейса (их и человеческие то переводчики не так легко понимали, часто лажали и для этого есть отдельные приседания)
- чем более редкий язык, тем стремительно хуже результат. Первые пять языков по распространенности отлично. Вторые десять норм. Дальше все быстрее идет в разнос.
И здесь появляется несколько неожиданных эффектов
- Если раньше за более редкими языками стояла просто меньшая выручка, то теперь и меньшая выручка и бОльшая себестоимость, поскольку они хуже поддаются оптимизации через автоматические переводы. Неравенство выросло.
- Эффект экономии от лучших результатов в топовых языках сильно снижается за счет усреднения от длинного хвоста более редких языков.
- Масштабировать _количество_ языков через AI можно советовать только тем, у кого переводов раньше не было. До 5 языков отлично. До 15 с трудом. Потом печаль. Мы уже не можем так расширять покрытие.
- Самый большой объем это тексты в интерфейсе, но они намного хуже поддаются автопереводу
Вообще история авто-переводов у нас очень старая, и впервые это было опробовано свыше 20 лет назад (полная катастрофа, закопать и не возвращаться), потом еще раз 10 лет назад (г..но, но для галочки с большой натяжкой можно), ну и вот теперь это вполне рабочий метод с некоторыми ограничениями.
Эксперименты показали, что
- 80% автоперевода сейчас уже ок и не требуют коррекции. Но 20% это довольно много и соответственно люди все еще нужны - читать надо все 100% текста + 20% править. В итоге расходы, конечно, меньше, но совсем не в пять раз, а примерно на треть.
- чем меньше контекст, тем хуже результат. лучше всего переводится документация (длинный связный текст), хуже всего короткие подписи в интерфейсе. ну или пока не придумали, как AI должен понимать смысл кнопок прямо из интерфейса (их и человеческие то переводчики не так легко понимали, часто лажали и для этого есть отдельные приседания)
- чем более редкий язык, тем стремительно хуже результат. Первые пять языков по распространенности отлично. Вторые десять норм. Дальше все быстрее идет в разнос.
И здесь появляется несколько неожиданных эффектов
- Если раньше за более редкими языками стояла просто меньшая выручка, то теперь и меньшая выручка и бОльшая себестоимость, поскольку они хуже поддаются оптимизации через автоматические переводы. Неравенство выросло.
- Эффект экономии от лучших результатов в топовых языках сильно снижается за счет усреднения от длинного хвоста более редких языков.
- Масштабировать _количество_ языков через AI можно советовать только тем, у кого переводов раньше не было. До 5 языков отлично. До 15 с трудом. Потом печаль. Мы уже не можем так расширять покрытие.
- Самый большой объем это тексты в интерфейсе, но они намного хуже поддаются автопереводу
Вообще история авто-переводов у нас очень старая, и впервые это было опробовано свыше 20 лет назад (полная катастрофа, закопать и не возвращаться), потом еще раз 10 лет назад (г..но, но для галочки с большой натяжкой можно), ну и вот теперь это вполне рабочий метод с некоторыми ограничениями.
По моим наблюдениям основатели небольших компаний при их поглощении "стратегом" (бОльшим бизнесом) не часто приживаются. Сужу как по знакомым, так и по статьям от поглощенных в гугл, мс и тп, так и по нашей конторе. Детальных примеров в памяти уже довольно много, так что можно что-то субъективно обобщить:
- Если основатель желал возглавить усиленный рост своего детища, то типовая история, что компания видит это рост совершенно иначе, иными средствами и методами, и основатель начинает конфликтовать, оказывается неудобным, после чего его отодвигают и прощаются с ним.
- Основатель небольшой компании привык всем заниматься понемногу, быть человеком-оркестром, принимать массу решений во всех областях. В бОльшой компании его функции разбирают по отделам - там продажи, тут маркетинг, там тех.поддержка, здесь разработка, там финансы. По моим наблюдениям, очень сложно психологически отказаться от "оркестровой" сущности и выбрать какую-то одну специализацию. А даже и при желании специализироваться - оказывается, что в каждой конкретной функции основатель не слишком высоко котируется - узкие специалисты большой конторы более прокачаны.
- Казалось бы оптимально основателю стать продакт менеджером своего продукта, но часто оказывается что созданое решение это функция удачи и обстоятельств. Удачно упавшее зернышко, которое заботливо выращено своими руками. При этом человек не привык работать с командой, формулировать задачи и планы, не привык убеждать и доказывать, руководит по принципу "делай как я, делай что я сказал". Нет возможности что-то масштабировать при таком подходе, команды не хотят работать с таким продакт менеджером.
- Если основатель хотел бы просто забрать деньги и уйти, то тоже обычно нет. Сделка часто структурирована так, что живых денег дают не так уж много (это публика читает в новостях и завидует). Что-то будет акции новой компании (а она может не торгуется публично), что-то будет передаваться по календарю в течении следующих лет, в зависимости от успехов продукта, в зависимости от личного поведения. Человек оказывается в тисках - делать, что хочешь нельзя, бросить нельщя, уйти нельзя. Печаль.
Понятно, что описанное не повсеместно, но на каждого успешно интегрировашегося основателя я знаю наверное ~9 историй как выше.
Вобщем, если бы я сделал небольшую компанию и мне предложили продаться, то из этого опыта (с покупающей стороны) я бы очень сильно подумал, чего я на самом деле хочу и на что я для этого готов.
Хорошая нота это что какие-то приличные деньги люди в итоге забирают, просто позже и меньше, чем хотели, и с каким-то неприятным опытом по пути.
- Если основатель желал возглавить усиленный рост своего детища, то типовая история, что компания видит это рост совершенно иначе, иными средствами и методами, и основатель начинает конфликтовать, оказывается неудобным, после чего его отодвигают и прощаются с ним.
- Основатель небольшой компании привык всем заниматься понемногу, быть человеком-оркестром, принимать массу решений во всех областях. В бОльшой компании его функции разбирают по отделам - там продажи, тут маркетинг, там тех.поддержка, здесь разработка, там финансы. По моим наблюдениям, очень сложно психологически отказаться от "оркестровой" сущности и выбрать какую-то одну специализацию. А даже и при желании специализироваться - оказывается, что в каждой конкретной функции основатель не слишком высоко котируется - узкие специалисты большой конторы более прокачаны.
- Казалось бы оптимально основателю стать продакт менеджером своего продукта, но часто оказывается что созданое решение это функция удачи и обстоятельств. Удачно упавшее зернышко, которое заботливо выращено своими руками. При этом человек не привык работать с командой, формулировать задачи и планы, не привык убеждать и доказывать, руководит по принципу "делай как я, делай что я сказал". Нет возможности что-то масштабировать при таком подходе, команды не хотят работать с таким продакт менеджером.
- Если основатель хотел бы просто забрать деньги и уйти, то тоже обычно нет. Сделка часто структурирована так, что живых денег дают не так уж много (это публика читает в новостях и завидует). Что-то будет акции новой компании (а она может не торгуется публично), что-то будет передаваться по календарю в течении следующих лет, в зависимости от успехов продукта, в зависимости от личного поведения. Человек оказывается в тисках - делать, что хочешь нельзя, бросить нельщя, уйти нельзя. Печаль.
Понятно, что описанное не повсеместно, но на каждого успешно интегрировашегося основателя я знаю наверное ~9 историй как выше.
Вобщем, если бы я сделал небольшую компанию и мне предложили продаться, то из этого опыта (с покупающей стороны) я бы очень сильно подумал, чего я на самом деле хочу и на что я для этого готов.
Хорошая нота это что какие-то приличные деньги люди в итоге забирают, просто позже и меньше, чем хотели, и с каким-то неприятным опытом по пути.