Любимое: путать теплое с мягким
Аналитикам важно различать цель и результат при проектировании ИТ-систем и написании инженерной документации. Это нужно уметь делать, чтобы принимать и успешно реализовывать правильные (достигающие целей) решения в условиях растущей неопределенности и сложности при ограниченных ресурсах.
Про (аналитить) это
#глоссарий
Аналитикам важно различать цель и результат при проектировании ИТ-систем и написании инженерной документации. Это нужно уметь делать, чтобы принимать и успешно реализовывать правильные (достигающие целей) решения в условиях растущей неопределенности и сложности при ограниченных ресурсах.
Про (аналитить) это
#глоссарий
🔥6
Оценка задач 🔮
Оценка задачи (или проекта) не гарантирует того, что специалист сделал декомпозицию и действительно продумал ход работы над ней.
Специфика оценки своей части аналитиками состоит в высокой неопределенности относительно существенной сложности системы. Мы тупо пытаемся угадать будущую сложность на основании опыта, внешних признаков, имеющихся обрывков информации.
Мне нравится конус неопределенности, который я позаимствовал у Натальи (которая подсмотрела у Сергея Нужненко). Помогает мне наглядно показать коллегам, чего стоит наша оценка.
Наблюдал ещё такой эффект: если за неточную оценку наказывать (хотя бы выговаривать) то спецы начинают перезакладываться и точность страдает. Плюс оценка в одно лицо по ощущениям довольно утомительное занятие.
В команде оцениваем коллективно (системными аналитиками) в дискуссии чтобы: (а) все смогли высказаться и указать на возможные проблемы/пути решения и (б) по одиночке не выгорали. Ну и да, пишем список примерных задач по оцениваемой фиче с детализацией, чтобы было понятно откуда оценка взялась.
Еще момент: не даю в оценку писать штуки типа «коммуникация со стейкхолдерами» 🙈 а призываю писать по существу задачи, функциональным блокам и артефактам. Напоминаю, что «встречи» и «переписка» являются частью процесса анализа и самостоятельной ценности в отрыве от задачи не представляют.
Иногда так и говорю: за письма заказчик не заплатит
Оценка задачи (или проекта) не гарантирует того, что специалист сделал декомпозицию и действительно продумал ход работы над ней.
Специфика оценки своей части аналитиками состоит в высокой неопределенности относительно существенной сложности системы. Мы тупо пытаемся угадать будущую сложность на основании опыта, внешних признаков, имеющихся обрывков информации.
Мне нравится конус неопределенности, который я позаимствовал у Натальи (которая подсмотрела у Сергея Нужненко). Помогает мне наглядно показать коллегам, чего стоит наша оценка.
Наблюдал ещё такой эффект: если за неточную оценку наказывать (хотя бы выговаривать) то спецы начинают перезакладываться и точность страдает. Плюс оценка в одно лицо по ощущениям довольно утомительное занятие.
В команде оцениваем коллективно (системными аналитиками) в дискуссии чтобы: (а) все смогли высказаться и указать на возможные проблемы/пути решения и (б) по одиночке не выгорали. Ну и да, пишем список примерных задач по оцениваемой фиче с детализацией, чтобы было понятно откуда оценка взялась.
Еще момент: не даю в оценку писать штуки типа «коммуникация со стейкхолдерами» 🙈 а призываю писать по существу задачи, функциональным блокам и артефактам. Напоминаю, что «встречи» и «переписка» являются частью процесса анализа и самостоятельной ценности в отрыве от задачи не представляют.
Иногда так и говорю: за письма заказчик не заплатит
👍4🔥1
Существенная Сложность (Essential Complexity) - сложность того, что делает система, сложность реализованных ею моделей, отражающих сложность реального мира, не зависящая от способа и деталей реализации. Сложность, порожденная решаемой проблемой, и ничто не может устранить или уменьшить её. Мы можем только управлять ею таким образом, чтобы минимизировать объем существенной сложности, рассматриваемой одновременно, до уровня, не превосходящего ограничения краткосрочной памяти человека.
— emacsway-log #глоссарий
1
Telegram
Jira Priority
Emojipack with 6 emoji for Telegram Premium subscribers.
Наглядность в коммуникациях
Рабочие сообщения в телеграме должны быть максимально информативны, чтобы экономить внимание получателей. Если вы работаете с задачами в Atlassian Jira, то рекомендую использовать кастомные эмодзи Jira Priority для указания приоритетов задач в сообщениях, например:
⬆️ Доработать фид для маркетплейсов
➡️ Добавить в мониторинг отслеживание robots.txt
Получатель может сразу оценить степень срочности указанной задачи не открывая собственно задачу.
Использование кастомных эмодзи, правда, требует платного аккаунта в телеге.
Всё это укладывается в парадигму «заботы о читателе», про которую хорошо рассказывает Максим Ильяхов в книге «Пиши, сокращай» и Ольга Лукинова в канале «Цифровой этикет».
Рабочие сообщения в телеграме должны быть максимально информативны, чтобы экономить внимание получателей. Если вы работаете с задачами в Atlassian Jira, то рекомендую использовать кастомные эмодзи Jira Priority для указания приоритетов задач в сообщениях, например:
Получатель может сразу оценить степень срочности указанной задачи не открывая собственно задачу.
Использование кастомных эмодзи, правда, требует платного аккаунта в телеге.
Всё это укладывается в парадигму «заботы о читателе», про которую хорошо рассказывает Максим Ильяхов в книге «Пиши, сокращай» и Ольга Лукинова в канале «Цифровой этикет».
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍3
[2/x] Как сделать правильное логгирование
Начать нужно с прояснения целей логгирования:
(1) Информирование о переходе систем в нештатный режим: узнать о проблеме раньше клиента;
(2) Анализ причин возникновения нештатных ситуаций: что сломалось, воспроизвести и починить;
(3) Сбор информации для оптимизации систем: анализ времени выполнения операций, найти «медленные», которые можно оптимизировать (в т.ч. на межсистемном уровне).
Иногда бОльший акцент нужно сделать в пользу защиты от вторжений, анализа уязвимостей и так далее. Всё, что связано с информационной безопасностью, лучше прояснять с профильными специалистами.
Источники информации для логов
(1) Клиентское приложение — даже веб-страницы должны вести лог, например в консоль браузера, чтобы при случае было чего отправить в техподдержку (пример — Crashlytics, Sentry)
(2) Веб-сервер — обычно имеет свои логи наподобие access.log, error.log и другие. Тупо пишет запросы и ответы на них без учёта бизнес-логики.
(3) Приложение — нужно описывать требования, какие логи хотим иметь, в каком формате, события каких типов писать и сколько хранить. Здесь учитываем бизнес-логику и архитектуру, дополнительные требования и пожелания в части анализа данных.
(4) Базы данных — обычно имеют свои логи с разной степенью детализации. Есть текстовые, есть бинарные.
(5) Сетевое оборудование — файерволлы всех типов, прокси и прочее, обычно пишут свои логи.
Что писать в лог
Типы сообщений, которые вы можете писать в лог:
(1) Получение входящих, отправка исходящих запросов;
(2) Валидация модели данных и параметров запроса;
(3) Аутентификация и авторизация — успех и ошибки отдельно;
(4) Ошибки приложения: runtime-ошибки, проблемы с сетью, долгие запросы, сообщения от используемых библиотек;
(5) Старты и остановки сущности приложения;
(6) Применение алгоритмов бизнес-логики — что пересчитано, трансформировано в данных;
(7) Исполнение потенциально опасных SQL-запросов на INSERT, UPDATE и DELETE;
(8) Создание и экспирация токенов, разрешений, изменение прав доступа, ролевые назначения;
(9) Отдельно логгировать действия пользователей с высокими административными полномочиями;
(10) Действия, потенциально опасные с юридической точки зрения: согласие пользователя на обработку персональных данных, согласование сертификатов между системами, подтверждение Terms of Use и так далее.
Возможно, стоит так же логгировать:
(11) Дерево ошибок — если позволяет стек приложения. Вся цепочка вызовов, приведшая к исключению, вместе со значениями параметров в вызванных методах, с указанием файла и строки в коде;
(12) Интенсивное использование какого-либо ресурса, превышающего пороговые значения, всё что похоже на DDOS, в том числе от корпоративных, внутренних систем;
(13) Подробный аудит изменяемых сущностей;
(14) Выявленные попытки фрода, подлога, подозрительного поведения определяемые логикой приложения;
(15) Изменение конфигурационных настроек приложения;
(16) Изменение версии приложения.
Что точно писать в лог не нужно
🔵 Пароли, токены, закрытые ключи
🔵 Database connection string
🔵 Номера банковских карт
🔵 Информацию, составляющую коммерческую тайну
🔵 Информацию, которая может быть признана незаконной для хранения — персональные данные, к примеру
Представьте, что судебные приставы изымут логи системы по решению суда и опубликуют их на сайте суда как часть материалов дела. Убрать их оттуда будет крайне проблематично. Сразу проектируйте так, чтобы подобный сценарий не стал для вас проблемой.
Как именно писать лог
Структура записи лога должна быть машиночитаемой и индексируемой. Формат данных зависит от хранилища. Одна из хорошо зарекомендовавших себя структур состоит из 4 частей — WWWW: when, where, who and what.
🔵 When — когда: дата-время, идентификаторы trace_id;
🔵 Where — где: название приложения, версия, эндпоинт, файл, модуль, компонент;
🔵 Who — кто: человек или система, адрес источника запроса, порты, идентификаторы;
🔵 What — что: тип и важность события, описание, параметры.
Для себя использую шаблон «Пример требований к логгированию», который дополняю в зависимости от специфики проекта.
#логгирование
Начать нужно с прояснения целей логгирования:
(1) Информирование о переходе систем в нештатный режим: узнать о проблеме раньше клиента;
(2) Анализ причин возникновения нештатных ситуаций: что сломалось, воспроизвести и починить;
(3) Сбор информации для оптимизации систем: анализ времени выполнения операций, найти «медленные», которые можно оптимизировать (в т.ч. на межсистемном уровне).
Иногда бОльший акцент нужно сделать в пользу защиты от вторжений, анализа уязвимостей и так далее. Всё, что связано с информационной безопасностью, лучше прояснять с профильными специалистами.
Источники информации для логов
(1) Клиентское приложение — даже веб-страницы должны вести лог, например в консоль браузера, чтобы при случае было чего отправить в техподдержку (пример — Crashlytics, Sentry)
(2) Веб-сервер — обычно имеет свои логи наподобие access.log, error.log и другие. Тупо пишет запросы и ответы на них без учёта бизнес-логики.
(3) Приложение — нужно описывать требования, какие логи хотим иметь, в каком формате, события каких типов писать и сколько хранить. Здесь учитываем бизнес-логику и архитектуру, дополнительные требования и пожелания в части анализа данных.
(4) Базы данных — обычно имеют свои логи с разной степенью детализации. Есть текстовые, есть бинарные.
(5) Сетевое оборудование — файерволлы всех типов, прокси и прочее, обычно пишут свои логи.
Что писать в лог
Типы сообщений, которые вы можете писать в лог:
(1) Получение входящих, отправка исходящих запросов;
(2) Валидация модели данных и параметров запроса;
(3) Аутентификация и авторизация — успех и ошибки отдельно;
(4) Ошибки приложения: runtime-ошибки, проблемы с сетью, долгие запросы, сообщения от используемых библиотек;
(5) Старты и остановки сущности приложения;
(6) Применение алгоритмов бизнес-логики — что пересчитано, трансформировано в данных;
(7) Исполнение потенциально опасных SQL-запросов на INSERT, UPDATE и DELETE;
(8) Создание и экспирация токенов, разрешений, изменение прав доступа, ролевые назначения;
(9) Отдельно логгировать действия пользователей с высокими административными полномочиями;
(10) Действия, потенциально опасные с юридической точки зрения: согласие пользователя на обработку персональных данных, согласование сертификатов между системами, подтверждение Terms of Use и так далее.
Возможно, стоит так же логгировать:
(11) Дерево ошибок — если позволяет стек приложения. Вся цепочка вызовов, приведшая к исключению, вместе со значениями параметров в вызванных методах, с указанием файла и строки в коде;
(12) Интенсивное использование какого-либо ресурса, превышающего пороговые значения, всё что похоже на DDOS, в том числе от корпоративных, внутренних систем;
(13) Подробный аудит изменяемых сущностей;
(14) Выявленные попытки фрода, подлога, подозрительного поведения определяемые логикой приложения;
(15) Изменение конфигурационных настроек приложения;
(16) Изменение версии приложения.
Что точно писать в лог не нужно
Представьте, что судебные приставы изымут логи системы по решению суда и опубликуют их на сайте суда как часть материалов дела. Убрать их оттуда будет крайне проблематично. Сразу проектируйте так, чтобы подобный сценарий не стал для вас проблемой.
Как именно писать лог
Структура записи лога должна быть машиночитаемой и индексируемой. Формат данных зависит от хранилища. Одна из хорошо зарекомендовавших себя структур состоит из 4 частей — WWWW: when, where, who and what.
Для себя использую шаблон «Пример требований к логгированию», который дополняю в зависимости от специфики проекта.
#логгирование
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5
Системный сдвиг
Сколько вы знаете способов передачи данных на клиент по инициативе сервера?
Этот пост зацепил моё внимание заявленной темой — но по прочтению у меня сложилось впечатление, что с логикой изложения что-то не то. Задал вопрос автору в каментах и продублирую его здесь.
Юрий Куприянов ведет довольно интересный для меня канал, но иногда возникает ощущение что логика сохраняется в локальных утверждениях, но цельность всего поста будто бы чуток «троит» 😈
===
Всю статью будто бы пронизывает трудноуловимый сбой в логике повествования. Прошу прощения у автора, возможно я неверно интерпретировал некоторые утверждения в заметке.
(1) В заголовке постулируется тема по передаче данных от сервера к клиенту по инициативе сервера; к концу статьи множество понятий сваливается в кучу, включая event-driven архитектуру и логику принятия решений на уровне приложения.
Возможно я ошибаюсь, но решение о том, вокруг чего «устроены сообщения», должен принять проектировщик при проектировании системы, а не «приложение на уровне логики».
(2) Мне кажется неверно постулировать использование «оберток» GraphQL и gRPC вокруг коммуникационных протоколов по причине того, что «сложно разобраться» с этими самыми коммуникационными протоколами HTTP/* и WebSocket.
Создавались GraphQL и gRPC чтобы решить вполне конкретные проблемы:
GraphQL — язык запросов, чтобы решить проблему поставки рекурсивных данных в условиях узких каналов передачи данных;
gRPC — фреймворк, чтобы связать большое количество микросервисов написанных на разных языках в корпоративном контуре, используя преимущества протоколов SPDY, HTTP/2 и QUIC.
Выбор в пользу технологии должен делаться системно, с рассмотрением решаемых проблем и с учетом архитектуры информационных систем. Не потому, что технология сложная.
(3)
REST предлагался Филдингом как концепция «самоописываемого состояния гипермедиа» в условиях «анархического масштабирования сети». Основная идея состояла в том, что клиент может добраться до любого узла графа API, начав от корня и следуя ссылкам HATEOAS. В целом можно почитать комментарий Филдинга здесь или разбор диссертации Филдинга здесь.
Как архитектурный стиль REST API может стать более или менее технологическим? Да, REST вовсе не требует использования HTTP для имплементации. Но в чём именно может выражаться меньшая технологичность этого стиля?
Тот же вопрос применим и к RPC.
Буду признателен за содержательные ответы или критику.
===
Юрий обещал ответить содержательно. Записал в книжку душных напоминаний😯
Юрий Куприянов ведет довольно интересный для меня канал, но иногда возникает ощущение что логика сохраняется в локальных утверждениях, но цельность всего поста будто бы чуток «троит» 😈
===
Всю статью будто бы пронизывает трудноуловимый сбой в логике повествования. Прошу прощения у автора, возможно я неверно интерпретировал некоторые утверждения в заметке.
(1) В заголовке постулируется тема по передаче данных от сервера к клиенту по инициативе сервера; к концу статьи множество понятий сваливается в кучу, включая event-driven архитектуру и логику принятия решений на уровне приложения.
Возможно я ошибаюсь, но решение о том, вокруг чего «устроены сообщения», должен принять проектировщик при проектировании системы, а не «приложение на уровне логики».
(2) Мне кажется неверно постулировать использование «оберток» GraphQL и gRPC вокруг коммуникационных протоколов по причине того, что «сложно разобраться» с этими самыми коммуникационными протоколами HTTP/* и WebSocket.
Создавались GraphQL и gRPC чтобы решить вполне конкретные проблемы:
GraphQL — язык запросов, чтобы решить проблему поставки рекурсивных данных в условиях узких каналов передачи данных;
gRPC — фреймворк, чтобы связать большое количество микросервисов написанных на разных языках в корпоративном контуре, используя преимущества протоколов SPDY, HTTP/2 и QUIC.
Выбор в пользу технологии должен делаться системно, с рассмотрением решаемых проблем и с учетом архитектуры информационных систем. Не потому, что технология сложная.
(3)
«кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими»
REST предлагался Филдингом как концепция «самоописываемого состояния гипермедиа» в условиях «анархического масштабирования сети». Основная идея состояла в том, что клиент может добраться до любого узла графа API, начав от корня и следуя ссылкам HATEOAS. В целом можно почитать комментарий Филдинга здесь или разбор диссертации Филдинга здесь.
Как архитектурный стиль REST API может стать более или менее технологическим? Да, REST вовсе не требует использования HTTP для имплементации. Но в чём именно может выражаться меньшая технологичность этого стиля?
Тот же вопрос применим и к RPC.
Буду признателен за содержательные ответы или критику.
===
Юрий обещал ответить содержательно. Записал в книжку душных напоминаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Шина vs Брокер
Вчера выступили на митапе «Шина vs Брокер» в ITFB вместе с Наташей @start_in_IT. Рассказали аналитикам, Q&A, разработчикам и руководителям проектов что это такое, чем различается и где применяется. Несмотря на то, что был вечер, удалось вовлечь ребят в проектирование выдуманной системы — пусть и в урезанном варианте, но всё же настоящее проектирование и рассуждения о том, какой способ интеграции выбрать и главное, почему именно такой.
В реальной жизни откровенно ошибочные варианты бывают редко. Обычно архитекторы и команда выбирают решение учитывая множество критериев: функциональные и нефункциональные требования, ограничения существующего ландшафта. Идёт сравнение «за» и «против» разных вариантов, взвешивание рисков, стоимости поддержки и ещё триллиона вещей. Иногда тупо решает политика; тогда инженеры пожимают плечами и готовятся разгребать последствия.
На митапе коллеги серьёзно подошли к вопросу и многие смогли неплохо аргументировать свои решения.
Мне понравилось🕶 и спасибо коллегам за приглашение!
Подумываю поучаствовать где-нибудь, а может быть даже организовать архитектурные ката:
Почитать про них можно на английском или на русском.
Вчера выступили на митапе «Шина vs Брокер» в ITFB вместе с Наташей @start_in_IT. Рассказали аналитикам, Q&A, разработчикам и руководителям проектов что это такое, чем различается и где применяется. Несмотря на то, что был вечер, удалось вовлечь ребят в проектирование выдуманной системы — пусть и в урезанном варианте, но всё же настоящее проектирование и рассуждения о том, какой способ интеграции выбрать и главное, почему именно такой.
В реальной жизни откровенно ошибочные варианты бывают редко. Обычно архитекторы и команда выбирают решение учитывая множество критериев: функциональные и нефункциональные требования, ограничения существующего ландшафта. Идёт сравнение «за» и «против» разных вариантов, взвешивание рисков, стоимости поддержки и ещё триллиона вещей. Иногда тупо решает политика; тогда инженеры пожимают плечами и готовятся разгребать последствия.
На митапе коллеги серьёзно подошли к вопросу и многие смогли неплохо аргументировать свои решения.
Мне понравилось
Подумываю поучаствовать где-нибудь, а может быть даже организовать архитектурные ката:
Это возможность в игровой форме потренировать свои архитектурные навыки на вымышленных проектах. Формат основан на Architectural katas — игре для разработчиков и архитекторов ПО.
Почитать про них можно на английском или на русском.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥2
Как называть очереди в брокерах
Слава пришла откуда не ждали. Вчера во внутренней группе для аналитиков коллега поделился артефактом СА с таким комментарием:
Из любопытства я порылся в приложенном документе (закину в комментарии к посту) и обнаружил в нём копию своего собственного документа, который я создал на одном из проектов в 2022 году.
Неповторимый, так сказать оригинал вот он: Правила именования топиков
Создавайте правила
Мало просто правильно назвать очередь или грамотно описать артефакт. Создавайте правила, описывайте стили, внедряйте принципы организации информации. Тогда больше шансов, что команда будет работать как команда, а не просто группа случайно собранных людей, каждый со своим неповторимым почерком.
#брокеры
Слава пришла откуда не ждали. Вчера во внутренней группе для аналитиков коллега поделился артефактом СА с таким комментарием:
Зашёл я в Инстаграм значит, а там в рилсах вот такой шаблон девушка раздает. Некоторые примеры наивные, но в целом как чек-лист о чем нужно/можно подумать аналитику наверное неплохо
Из любопытства я порылся в приложенном документе (закину в комментарии к посту) и обнаружил в нём копию своего собственного документа, который я создал на одном из проектов в 2022 году.
Неповторимый, так сказать оригинал вот он: Правила именования топиков
Создавайте правила
Мало просто правильно назвать очередь или грамотно описать артефакт. Создавайте правила, описывайте стили, внедряйте принципы организации информации. Тогда больше шансов, что команда будет работать как команда, а не просто группа случайно собранных людей, каждый со своим неповторимым почерком.
#брокеры
👍13❤2
Помощь ИИ в анализе и проектировании
Лично я пока не видел реальной помощи от ИИ в анализе, проектировании и в операционной части бизнеса электронной коммерции. Проблема, на мой взгляд, состоит в том, что ИИ на самом деле не понимает, о чем пишет/говорит/рисует. Он анализирует частотность токенов при обучении и их связь между собой. И чем длиннее ассоциативные цепочки токенов, тем «умнее» выглядит ИИ.
В екоме, несмотря на общие закономерности, бизнес-процессы сильно различаются от организации к организации. И выходит, что каждая решаемая аналитиком проблема — оптимизация, проектирование процессов или автоматизация — уникальна. ИИ просто неоткуда взять решение; он пытается собрать из грязи и палок то, что где-то видел. А там про другое. Да ещё без глубины смысла.
Поэтому взять и натравить ИИ на бизнес и сказать «проектируй» или «анализируй» — не получится. Те процессы наполовину состоят из «крысиных» чатиков и эмоциональной поддержки людей друг друга; поди это учти в моделях без интервью.
Думаю, со временем ситуация улучшится, когда ИИ сможет теснее наблюдать нас в естественной среде обитания; длина цепочек анализируемых токенов позволит таки создавать убедительные результаты и артефакты.
Пока максимум что ИИ может в разработке — это помогать писать типовые конструкции в коде, где много повторяющихся паттернов и экономить труд разработчиков на написание действительно сложных частей. Аналитики пользуются ИИ, чтобы набросать типовые sequence-диаграммы (которые потом всё равно допиливать руками до ума). В системах массового обслуживания, которые легко алгоритмизируются — например, колл-центры, кассы и так далее, — там ИИ действительно эффективно помогает.
Видели ли вы примеры в работе, где ИИ действительно блестяще справляется? Лучше людей? Поделитесь в комментариях, это интересно.
Лично я пока не видел реальной помощи от ИИ в анализе, проектировании и в операционной части бизнеса электронной коммерции. Проблема, на мой взгляд, состоит в том, что ИИ на самом деле не понимает, о чем пишет/говорит/рисует. Он анализирует частотность токенов при обучении и их связь между собой. И чем длиннее ассоциативные цепочки токенов, тем «умнее» выглядит ИИ.
В екоме, несмотря на общие закономерности, бизнес-процессы сильно различаются от организации к организации. И выходит, что каждая решаемая аналитиком проблема — оптимизация, проектирование процессов или автоматизация — уникальна. ИИ просто неоткуда взять решение; он пытается собрать из грязи и палок то, что где-то видел. А там про другое. Да ещё без глубины смысла.
Поэтому взять и натравить ИИ на бизнес и сказать «проектируй» или «анализируй» — не получится. Те процессы наполовину состоят из «крысиных» чатиков и эмоциональной поддержки людей друг друга; поди это учти в моделях без интервью.
Думаю, со временем ситуация улучшится, когда ИИ сможет теснее наблюдать нас в естественной среде обитания; длина цепочек анализируемых токенов позволит таки создавать убедительные результаты и артефакты.
Пока максимум что ИИ может в разработке — это помогать писать типовые конструкции в коде, где много повторяющихся паттернов и экономить труд разработчиков на написание действительно сложных частей. Аналитики пользуются ИИ, чтобы набросать типовые sequence-диаграммы (которые потом всё равно допиливать руками до ума). В системах массового обслуживания, которые легко алгоритмизируются — например, колл-центры, кассы и так далее, — там ИИ действительно эффективно помогает.
Видели ли вы примеры в работе, где ИИ действительно блестяще справляется? Лучше людей? Поделитесь в комментариях, это интересно.
🔥4👍2
Андрей Корниенко. Про (аналитить) это
На днях прочел перевод статьи Ицхака Адизеса https://premiummanagement.com/blog/ichak-adizes-chto-takoe-zdorovaya-kompania
В статье поднимается тема успешности стартапов:
- что для этого важно и необходимо для успеха,
- о важности внимания к проблемам своих клиентов,
- что нужно уделять внимание как краткосрочным так и долгосрочным перспективам
Но меня заинтересовала следующая мысль:
Организация, которая эффективно обслуживает своих клиентов, принимая во внимание заинтересованные стороны в краткосрочной и долгосрочной перспективе, является ЗДОРОВОЙ компанией.
В статье поднимается тема успешности стартапов:
- что для этого важно и необходимо для успеха,
- о важности внимания к проблемам своих клиентов,
- что нужно уделять внимание как краткосрочным так и долгосрочным перспективам
Но меня заинтересовала следующая мысль:
Организация, которая эффективно обслуживает своих клиентов, принимая во внимание заинтересованные стороны в краткосрочной и долгосрочной перспективе, является ЗДОРОВОЙ компанией.
Здоровая организация
Увидел размышления про здоровую организацию на канале Максима Каширина и прокомментировал пост — в лучших восточных традициях «комментарий на комментарий на комментарий» ☺️
Возьму на себя смелость уточнить уважаемого Адизеса:
Эффективно — означает, что бизнес приносит прибыль своему владельцу (для простоты будем иметь в виду только коммерческие организации).
Результативно — означает, что клиенты полностью удовлетворены качеством товаров и услуг.
Одно вообще не связано автоматически с другим, и я наблюдаю повсеместный перекос и болтания процессов из одной крайности в другую: то зарабатываем деньги и забываем про клиентов, то бежим облизывать клиентов и забываем зачем нужен бизнес. Поэтому: обязательно нужно мониторить оба набора метрик. Не контролировать. Мониторить, по необходимости делать выборочный контроль и при сбоях процессов — корректировать (управляющие воздействия).
Если коммерческая организация не приносит прибыль владельцу, то она бессмысленна. Если клиенты не удовлетворены— то в условиях рынка компания рискует лишиться клиентов.
В здоровой организации владелец компании делится прибылью со своими сотрудниками. Не только окладом, а еще и переменной частью, которая зависит от степени влияния сотрудника на конечный результат. Даже уборщица и офис-менеджер сильно влияют на результат; эту очевидную истину почему-то редко кто видит и регулярно переоткрывают Америку: а офис-то должен быть уютным! Вот уж сюрприз.
Я уж не говорю про продажников, аналитиков, разработчиков и прочих (мне проще про ИТ). Все они влияют на результат и в здоровой организации должны получать плюсы и минусы финансового результата.
У меня есть опыт выстраивания процессов, в которых сотрудники получают прибыль (или убыток) прямо пропорционально эффективности процесса. Это сложно, но дает потрясающие результаты.
Как считаете, жизнеспособна ли такая модель? Приходилось ли работать в процессно-ориентированном бизнесе или некоммерческой организации?
Увидел размышления про здоровую организацию на канале Максима Каширина и прокомментировал пост — в лучших восточных традициях «комментарий на комментарий на комментарий» ☺️
Возьму на себя смелость уточнить уважаемого Адизеса:
Организация, которая эффективно и результативно обслуживает своих клиентов…
Эффективно — означает, что бизнес приносит прибыль своему владельцу (для простоты будем иметь в виду только коммерческие организации).
Результативно — означает, что клиенты полностью удовлетворены качеством товаров и услуг.
Одно вообще не связано автоматически с другим, и я наблюдаю повсеместный перекос и болтания процессов из одной крайности в другую: то зарабатываем деньги и забываем про клиентов, то бежим облизывать клиентов и забываем зачем нужен бизнес. Поэтому: обязательно нужно мониторить оба набора метрик. Не контролировать. Мониторить, по необходимости делать выборочный контроль и при сбоях процессов — корректировать (управляющие воздействия).
Если коммерческая организация не приносит прибыль владельцу, то она бессмысленна. Если клиенты не удовлетворены— то в условиях рынка компания рискует лишиться клиентов.
В здоровой организации владелец компании делится прибылью со своими сотрудниками. Не только окладом, а еще и переменной частью, которая зависит от степени влияния сотрудника на конечный результат. Даже уборщица и офис-менеджер сильно влияют на результат; эту очевидную истину почему-то редко кто видит и регулярно переоткрывают Америку: а офис-то должен быть уютным! Вот уж сюрприз.
Я уж не говорю про продажников, аналитиков, разработчиков и прочих (мне проще про ИТ). Все они влияют на результат и в здоровой организации должны получать плюсы и минусы финансового результата.
У меня есть опыт выстраивания процессов, в которых сотрудники получают прибыль (или убыток) прямо пропорционально эффективности процесса. Это сложно, но дает потрясающие результаты.
Как считаете, жизнеспособна ли такая модель? Приходилось ли работать в процессно-ориентированном бизнесе или некоммерческой организации?
🔥3👍1