Мастера поддержания репутации компании. Там же небось основная масса этих 100гиговых аккаунтов и так была заполнена не более чем на 8, т.е. по факту отжали какие-то копейки дискового пространства - зато во все новости сегодня попадут. Интересно, кто-нибудь считал сколько они вполне реальных денег потеряют на тех кто в яндекс за это переедет просто из принципа? Они же и так за последнее время провели массовую чистку неактивных аккаунтов.
Вот и вы говорите, что на настройке многие экономят. А это ключевой момент, важнее чем технологическое совершенство системы. Можно сделать сценарного робота на предзаписанных промптах лучше, чем нейросетевого, встречались образцы, даже рядом стоял когда такого делали, для автоматизации приёма звонков в больнице. Мне тема автоматического обслуживания абонентов интересна, стараюсь следить за современным уровнем технологий, но системно не подходил, поэтому обзор рынка предоставить не готов. Из последнего очень понравился Сберовский робот, с ним поначалу даже разговаривать начинаешь. Правильно подобранные паузы, интонации, быстрая реакция на ввод от абонента.. Это тема для целой статьи, с разбором лучших и худших практик. Да и вообще очень живые голоса стали, которые невозможно от человека отличить, не то что до недавнего времени, весь синтез речи - грусть и тоска. Другое дело что вскоре понимаешь, что голоса слишком жизнерадостные, люди такими не бывают. Это как в компьютерной графике - нарисованные персонажи реалистичны, но слишком идеальные.
Понятно что бывает по-разному, но по-моему в такой ситуации речь идёт не о том что не хватает аналитика на проекте, а вообще об отсутствии организации процессов, когда все заняты не своим делом. Тут просто чудесный рыцарь-аналитик в сверкающих доспехах не спасёт, он ещё и должен роли перераспределить, и много чего.
Разработчики начинают работу, но у них возникает куча вопросов → Они идут с вопросами к тестировщикам, те обращаются к бизнесу
Извините, а что это за сумасшедший дом? Тестировщики общающиеся с бизнесом и разъясняющие задачи программистам? Нельзя по хотелкам бизнеса начинать программировать, без предварительного проектирования, это будут бесконечные переделки даже у программ уровня "hello world"! А тут целый коллектив разработчиков, причём судя по уровню оплаты не бог весть какой квалификации.
В переводе на русский - у банка, еле сводящего концы с концами, не хватает ресурсов сделать две вёрстки - вертикальную под телефон и горизонтальную под планшет/компьютер, поэтому 40% пользователей (десктопной версии) должны любоваться на аршинные буквы, узенькую колонку информации, убегающую вниз за экран, и данные в каждом блоке под горизонтальный свайп. Проще заплатить немножко денег пиарщикам, оправдывающим это рукожопство. Впрочем, сейчас уже все банки "оптимизировали" свои приложения таким образом.
Люди вообще много навыков потеряли за последние сотню-другую лет. Например добычу пищи за пределами магазинов :). Но это особо никого не беспокоит, в отличии от устного счёта.
Я отлично помню сколько копий было сломано на тему логарифмических линеек и калькуляторов, что с ними у людей мозги атрофируются. Это чем-то напоминает более свежую зарубу "настоящие программисты должны писать на ассемблере". Когда вы "пишете код" на новомодных фреймворках, вы не код пишете, а промпты компилятору по которым он генерирует машинный код :). Проблема не в том что ИИ пишет код, а что человеческий язык недостаточно детерминирован для чёткого описания инструкций компьютеру, для чего и изобрели ЯП.
Тоже не понимаю зачем два приложения. Видимо, команда "навигатора" обладает изрядным админресурсом чтобы сохранить своё уютненькое место разрабатывая приложение-дубль. Хоть бы интерфейс под управление в движении оптимизировали! Когда поставил в машину андроид-голову, решил попробовать "Навигатор". Помучился и снёс, заменил на "карты". С точки зрения навигации всё то же самое, никакого более удобного управления, скорее даже наоборот. Плюс всю допинфу нужно всё равно получать из "карт" - по городу когда ездишь, полезно с гортранспортом синхронизироваться (доехать на машине и пересесть на автобус, например).
Вы из контекста выдернули фразу - для РЕШЕНИЯ проблемы письма подходят очень плохо. Они подходят для фиксации решения и ответственности за него. А мессенджеры любимы, потому что практически не оставляют следов распоряжений и договорённостей, они легко теряются в бесконечной ленте и десятках чатов, зато позволяют одновременно чайка-менеджерить гораздо больше людей :)
Бюрократию не искоренить, поэтому инструменты работы с ней необходимы. Для этого же цепляют бесконечное количество людей в копию письма - не отреагировал значит не против. Я "статусное совещание" привёл как пример того, что цели у встречи могут быть разные, даже казалось бы "бессмысленные бюрократические пережитки" - важно что организатор чётко понимает цель встречи, организует её для достижения цели, и следит чтобы она была достигнута. ППР - значит ППР :) Дальше нет, структурировать не надо, должна же быть у молодого РП свобода выбора.
А можете написать пару слов о том, как бороться с некорректным использованием каналов коммуникации? Когда заказчик, или смежный руководитель задалбывает звонками, или наоборот вопросы задаёт исключительно по почте? А есть ещё волшебная привычка звонить с городского на стационарный телефон, даже когда известен мобильный. И - всё, повторный звонок через день. Коллегам ещё хоть как-то можно на вид поставить, а заказчики или руководство могут проглотить, но запомнить, и в самый неудобный момент не преминут напомнить моему начальству, что со мной невозможно общаться - не отвечаю на звонки, не реагирую на письма..
Здорово, что несмотря на то, что Азбука Вкуса и Перекрёсток сделали всё как надо ещё лет 10 назад, есть магазины, которые проходят весь путь самостоятельно и приходят к тому же результату, хоть и с опозданием, а филиал ада остаётся в Ашане с Лентой, с подходом "мы кассы поставили, но ими не пользуются - заставим, сократив до максимума обычные". Т.е. можно было поездить по сетям, попользоваться их кассами, и сделать так же но немного лучше уже давно, но это не путь самурая. Не суть, главное - молодцы, что заморочились тем чтобы сделать хорошо, и довели до конца.
Важно обратить внимание, что у каждого канала коммуникации своё предназначение, у них нет ранжира "этот лучше этот хуже" - а то часто люди используют то что нравится/удобно лично им, и пытаются окружающих перестроить на свой лад. И отдельный котёл для тех кто в мессенджерах голосом отвечает на текстовые вопросы :) Я вообще не понимаю кто придумал регулярные встречи в проектной деятельности. Зачем тащить элементы процессов в проекты? Любая встреча должна быть посвящена конкретным вопросам, а не "поговорить по расписанию о работе", с присутствием минимально достаточного количества людей. И они все должны быть вовлечены, если человек не участвовал в обсуждении, то зря приходил. При этом целью встречи может являться в том числе "статус", просто собраться всем и поговорить - но надо понимать что это непроизводственные потери времени всех присутствующих, которые должны быть обоснованы.
Скрытый текст
О да, картинка ещё в 2005 у нас в переговорке на стенке висела :)
Или все же стоит попробовать понять логику разработчиков
Вообще-то с этим давно (но чаще безуспешно) борются - что система сделана не для клиентов, а для разработчиков, и пользователи вынуждены подстраиваться под систему, а не наоборот :). Нужно понимать (что к сожалению в массе отсутствует), что виноваты не роботы сами по себе, а люди, которые их применяют везде подряд, а не там где это уместно, и (даже более важно) что настройка робота для адекватной работы это большой труд, а на это уже бюджет не заложен - "мы вам отличного робота поставили, а дальше сами настройте, там всё просто".
При этом не могу не отметить, что наконец начали появляться хорошо сделанные роботы. Ведь дело не в том, с роботом вы общаетесь или с человеком, а том пользовательском опыте который вы получаете, что ваша задача успешно и комфортно решается.
"одношаговая" я имел в виду в рамках одной транзакции (то что вы называете запросом) - т.е. подразумевается что ошибки имеет смысл ловить только в рамках запроса, более старые редко могут оказать влияние, и там уже логирования уровня INFO не увидим. Но запись идёт в файл на диске, или в какую-то более сложную структуру? Если мы в реальном времени пишем ошибки, а по окончанию транзакции вываливаем info, то оно будет записано позже, плюс если пишут разные потоки то они ещё успеют накидать "своих" логов в середину, и в файле будет нарушена хронология?
Т.е. это кэш для записей логов класса INFO в ожидании успешности транзакции? Есть ряд вопросов - достаточно ли нам одного шага для понимания причин ошибки или хранить стоит бОльший интервал, не пишут ли в один лог разные потоки, из-за чего нарушится хронология при пакетной записи, если ошибка критическая и грохнется процесс то и следов от этой записи в лог не останется?
Тема мне очень близкая, вроде и хочется что-то уточнить - но надо было делать в первых статьях, в новых всё сразу чётко написано и полностью соответствует моему опыту и мировоззрению :)
Вы выяснили, что половина новых сотрудников уходит через месяц работы. Построили линейный график количества увольнений от длительности работы, где тут хоть какая-то аналитика? "Чем дольше человек работает в компании тем больше вероятность его увольнения", это прям на шнобелевскую премию тянет.
Мастера поддержания репутации компании. Там же небось основная масса этих 100гиговых аккаунтов и так была заполнена не более чем на 8, т.е. по факту отжали какие-то копейки дискового пространства - зато во все новости сегодня попадут. Интересно, кто-нибудь считал сколько они вполне реальных денег потеряют на тех кто в яндекс за это переедет просто из принципа? Они же и так за последнее время провели массовую чистку неактивных аккаунтов.
Вот и вы говорите, что на настройке многие экономят. А это ключевой момент, важнее чем технологическое совершенство системы. Можно сделать сценарного робота на предзаписанных промптах лучше, чем нейросетевого, встречались образцы, даже рядом стоял когда такого делали, для автоматизации приёма звонков в больнице.
Мне тема автоматического обслуживания абонентов интересна, стараюсь следить за современным уровнем технологий, но системно не подходил, поэтому обзор рынка предоставить не готов. Из последнего очень понравился Сберовский робот, с ним поначалу даже разговаривать начинаешь. Правильно подобранные паузы, интонации, быстрая реакция на ввод от абонента.. Это тема для целой статьи, с разбором лучших и худших практик.
Да и вообще очень живые голоса стали, которые невозможно от человека отличить, не то что до недавнего времени, весь синтез речи - грусть и тоска. Другое дело что вскоре понимаешь, что голоса слишком жизнерадостные, люди такими не бывают. Это как в компьютерной графике - нарисованные персонажи реалистичны, но слишком идеальные.
Понятно что бывает по-разному, но по-моему в такой ситуации речь идёт не о том что не хватает аналитика на проекте, а вообще об отсутствии организации процессов, когда все заняты не своим делом. Тут просто чудесный рыцарь-аналитик в сверкающих доспехах не спасёт, он ещё и должен роли перераспределить, и много чего.
Извините, а что это за сумасшедший дом? Тестировщики общающиеся с бизнесом и разъясняющие задачи программистам?
Нельзя по хотелкам бизнеса начинать программировать, без предварительного проектирования, это будут бесконечные переделки даже у программ уровня "hello world"! А тут целый коллектив разработчиков, причём судя по уровню оплаты не бог весть какой квалификации.
В переводе на русский - у банка, еле сводящего концы с концами, не хватает ресурсов сделать две вёрстки - вертикальную под телефон и горизонтальную под планшет/компьютер, поэтому 40% пользователей (десктопной версии) должны любоваться на аршинные буквы, узенькую колонку информации, убегающую вниз за экран, и данные в каждом блоке под горизонтальный свайп. Проще заплатить немножко денег пиарщикам, оправдывающим это рукожопство.
Впрочем, сейчас уже все банки "оптимизировали" свои приложения таким образом.
Люди вообще много навыков потеряли за последние сотню-другую лет. Например добычу пищи за пределами магазинов :). Но это особо никого не беспокоит, в отличии от устного счёта.
В картах есть настройка "включать навигацию при такой-то скорости".
Я отлично помню сколько копий было сломано на тему логарифмических линеек и калькуляторов, что с ними у людей мозги атрофируются.
Это чем-то напоминает более свежую зарубу "настоящие программисты должны писать на ассемблере". Когда вы "пишете код" на новомодных фреймворках, вы не код пишете, а промпты компилятору по которым он генерирует машинный код :). Проблема не в том что ИИ пишет код, а что человеческий язык недостаточно детерминирован для чёткого описания инструкций компьютеру, для чего и изобрели ЯП.
Тоже не понимаю зачем два приложения. Видимо, команда "навигатора" обладает изрядным админресурсом чтобы сохранить своё уютненькое место разрабатывая приложение-дубль. Хоть бы интерфейс под управление в движении оптимизировали!
Когда поставил в машину андроид-голову, решил попробовать "Навигатор". Помучился и снёс, заменил на "карты". С точки зрения навигации всё то же самое, никакого более удобного управления, скорее даже наоборот. Плюс всю допинфу нужно всё равно получать из "карт" - по городу когда ездишь, полезно с гортранспортом синхронизироваться (доехать на машине и пересесть на автобус, например).
Вы из контекста выдернули фразу - для РЕШЕНИЯ проблемы письма подходят очень плохо. Они подходят для фиксации решения и ответственности за него. А мессенджеры любимы, потому что практически не оставляют следов распоряжений и договорённостей, они легко теряются в бесконечной ленте и десятках чатов, зато позволяют одновременно чайка-менеджерить гораздо больше людей :)
Бюрократию не искоренить, поэтому инструменты работы с ней необходимы. Для этого же цепляют бесконечное количество людей в копию письма - не отреагировал значит не против.
Я "статусное совещание" привёл как пример того, что цели у встречи могут быть разные, даже казалось бы "бессмысленные бюрократические пережитки" - важно что организатор чётко понимает цель встречи, организует её для достижения цели, и следит чтобы она была достигнута. ППР - значит ППР :)
Дальше нет, структурировать не надо, должна же быть у молодого РП свобода выбора.
А можете написать пару слов о том, как бороться с некорректным использованием каналов коммуникации? Когда заказчик, или смежный руководитель задалбывает звонками, или наоборот вопросы задаёт исключительно по почте? А есть ещё волшебная привычка звонить с городского на стационарный телефон, даже когда известен мобильный. И - всё, повторный звонок через день.
Коллегам ещё хоть как-то можно на вид поставить, а заказчики или руководство могут проглотить, но запомнить, и в самый неудобный момент не преминут напомнить моему начальству, что со мной невозможно общаться - не отвечаю на звонки, не реагирую на письма..
Здорово, что несмотря на то, что Азбука Вкуса и Перекрёсток сделали всё как надо ещё лет 10 назад, есть магазины, которые проходят весь путь самостоятельно и приходят к тому же результату, хоть и с опозданием, а филиал ада остаётся в Ашане с Лентой, с подходом "мы кассы поставили, но ими не пользуются - заставим, сократив до максимума обычные".
Т.е. можно было поездить по сетям, попользоваться их кассами, и сделать так же но немного лучше уже давно, но это не путь самурая. Не суть, главное - молодцы, что заморочились тем чтобы сделать хорошо, и довели до конца.
Важно обратить внимание, что у каждого канала коммуникации своё предназначение, у них нет ранжира "этот лучше этот хуже" - а то часто люди используют то что нравится/удобно лично им, и пытаются окружающих перестроить на свой лад. И отдельный котёл для тех кто в мессенджерах голосом отвечает на текстовые вопросы :)
Я вообще не понимаю кто придумал регулярные встречи в проектной деятельности. Зачем тащить элементы процессов в проекты? Любая встреча должна быть посвящена конкретным вопросам, а не "поговорить по расписанию о работе", с присутствием минимально достаточного количества людей. И они все должны быть вовлечены, если человек не участвовал в обсуждении, то зря приходил. При этом целью встречи может являться в том числе "статус", просто собраться всем и поговорить - но надо понимать что это непроизводственные потери времени всех присутствующих, которые должны быть обоснованы.
Скрытый текст
Вообще-то с этим давно (но чаще безуспешно) борются - что система сделана не для клиентов, а для разработчиков, и пользователи вынуждены подстраиваться под систему, а не наоборот :). Нужно понимать (что к сожалению в массе отсутствует), что виноваты не роботы сами по себе, а люди, которые их применяют везде подряд, а не там где это уместно, и (даже более важно) что настройка робота для адекватной работы это большой труд, а на это уже бюджет не заложен - "мы вам отличного робота поставили, а дальше сами настройте, там всё просто".
При этом не могу не отметить, что наконец начали появляться хорошо сделанные роботы. Ведь дело не в том, с роботом вы общаетесь или с человеком, а том пользовательском опыте который вы получаете, что ваша задача успешно и комфортно решается.
"одношаговая" я имел в виду в рамках одной транзакции (то что вы называете запросом) - т.е. подразумевается что ошибки имеет смысл ловить только в рамках запроса, более старые редко могут оказать влияние, и там уже логирования уровня INFO не увидим.
Но запись идёт в файл на диске, или в какую-то более сложную структуру? Если мы в реальном времени пишем ошибки, а по окончанию транзакции вываливаем info, то оно будет записано позже, плюс если пишут разные потоки то они ещё успеют накидать "своих" логов в середину, и в файле будет нарушена хронология?
Человек с развитыми софт-скиллами - это современный эвфемизм для балабол (на букву пи).
Т.е. это кэш для записей логов класса INFO в ожидании успешности транзакции? Есть ряд вопросов - достаточно ли нам одного шага для понимания причин ошибки или хранить стоит бОльший интервал, не пишут ли в один лог разные потоки, из-за чего нарушится хронология при пакетной записи, если ошибка критическая и грохнется процесс то и следов от этой записи в лог не останется?
Тема мне очень близкая, вроде и хочется что-то уточнить - но надо было делать в первых статьях, в новых всё сразу чётко написано и полностью соответствует моему опыту и мировоззрению :)
Вы выяснили, что половина новых сотрудников уходит через месяц работы. Построили линейный график количества увольнений от длительности работы, где тут хоть какая-то аналитика? "Чем дольше человек работает в компании тем больше вероятность его увольнения", это прям на шнобелевскую премию тянет.
Перевод рекламной статьи. Ни слова про то, каким способом удалось добиться столь впечатляющих результатов.