Про REST слышали наверняка все.
Некоторые даже слышали про RESTful. Единицы вспомнят модель зрелости REST Леонарда Ричардсона и её уровни.
Между тем, есть отличная статья Guy Levin, перевода которой я почему-то не нашел. Нужно это срочно исправить! Здесь дам короткий вольный пересказ.
Уровень 0: The swamp of POX (Plain old XML) — Болото старого доброго XML.
Это нам напоминает, с чем боролся Рой Филдинг: XML, SOAP и вызовы разных функций из одного эндпоинта методом POST.
Даже тут есть правила:
1. В названиях эндпоинтов слова нужно разделять дефисом: "-", это spinal case или kebab-case, "шашлычный стиль" — слова как бы нанизываются на шампур.
2. Подчеркивания в названиях эндпоинтов лучше не использовать. Почему так: потому что ссылки в тексте подчеркиваются, и символы "_" могут визуально потеряться, в отличие от "-".
3. Все ссылки должны быть в нижнем регистре. Это всё рекомендации RFC3986.
4. Расширения (то есть точку) лучше не использовать, формат ответа задаётся заголовком Content-Type.
Пример:
Уровень 1. Ресурсы.
Идея: разные эндпоинты для разных ресурсов. Названия эндпоинтов - существительные.
Правила:
1. Слэш ("/") в конце названия эндпоинта не нужен. Каждый ресурс имеет один адрес (URI). Разные URI указывают на разные ресурсы.
2. Слэш употребляется для указания иерархии ресурсов:
3. Существительные в единственном или во множественном числе? Тут у автора сомнения, но большинство фреймворков поддерживают названия ресурсов во множественном числе. Мне лично тоже больше нравится во множественном.
Уровень 2. Методы.
Используем для операций с ресурсами стандартные методы http, соответствующие CRUD: POST, GET, PUT, DELETE, PATCH + дополнительные HEAD и OPTIONS. Если вам не хватает операций CRUD, автор рекомендует сделать подчиненный ресурс /actions, и делать к нему POST с указанием типа операции и дополнительных параметров. Такой небольшой кусочек RPC-like style, когда RESTful не одобряет, но очень хочется.
2.1. Заголовки HTTP
Используйте заголовки! Тема тут обширная, но в основном заголовки используются для безопасности, переговоров клиента и сервера о форматах и кодировках контента, о кэшировании, версиях и обновлениях ресурсов, их размерах. Собственно, запрос HEAD возвращает заголовки без самого тела ресурса, чтобы клиент мог понять — нужно ли запрашивать ресурс вообще.
2.2. Параметры запроса
Используйте параметры запроса! (та часть, которая после @?"). Не забывайте про такие операции, как фильтрация, поиск, сортировка и пагинация. Для фильтров добавляем названия полей ресурса, по которым можно отфильтровать результат, указав значения или диапазон:
Для поиска — параметр
Для сортировки:
Для пагинации указываем число элементов на странице и номер страницы:
2.3. Коды ошибок
Используйте коды ошибок HTTP.
Уровень 3. Управление гипермедиа.
Тут два аспекта: обсуждение формата и HATEOAS.
3.1. Обсуждение формата — это про заголовки. Клиент и сервер договариваются, в каком формате сервер вернет ресурс. Может, в json, может в XML, а может просто в виде текста. В теории должно работать, и серверы должны отдавать ресурс в удобном для клиента представлении. На практике реализация встречается очень редко, но во внутренних гетерогенных системах может быть полезным. Запрос OPTIONS как раз про это: какие действия допускает сервер над ресурсом и в каких форматах готов его отдавать.
Некоторые даже слышали про RESTful. Единицы вспомнят модель зрелости REST Леонарда Ричардсона и её уровни.
Между тем, есть отличная статья Guy Levin, перевода которой я почему-то не нашел. Нужно это срочно исправить! Здесь дам короткий вольный пересказ.
Уровень 0: The swamp of POX (Plain old XML) — Болото старого доброго XML.
Это нам напоминает, с чем боролся Рой Филдинг: XML, SOAP и вызовы разных функций из одного эндпоинта методом POST.
Даже тут есть правила:
1. В названиях эндпоинтов слова нужно разделять дефисом: "-", это spinal case или kebab-case, "шашлычный стиль" — слова как бы нанизываются на шампур.
2. Подчеркивания в названиях эндпоинтов лучше не использовать. Почему так: потому что ссылки в тексте подчеркиваются, и символы "_" могут визуально потеряться, в отличие от "-".
3. Все ссылки должны быть в нижнем регистре. Это всё рекомендации RFC3986.
4. Расширения (то есть точку) лучше не использовать, формат ответа задаётся заголовком Content-Type.
Пример:
http://api.example.com/blogs/guy-levin/posts/this-is-my-first-postУровень 1. Ресурсы.
Идея: разные эндпоинты для разных ресурсов. Названия эндпоинтов - существительные.
Правила:
1. Слэш ("/") в конце названия эндпоинта не нужен. Каждый ресурс имеет один адрес (URI). Разные URI указывают на разные ресурсы.
2. Слэш употребляется для указания иерархии ресурсов:
http://api.canvas.com/shapes/polygons/quadrilaterals/squares,
http://api.college.com/students/3248234/courses/2020/fall3. Существительные в единственном или во множественном числе? Тут у автора сомнения, но большинство фреймворков поддерживают названия ресурсов во множественном числе. Мне лично тоже больше нравится во множественном.
Уровень 2. Методы.
Используем для операций с ресурсами стандартные методы http, соответствующие CRUD: POST, GET, PUT, DELETE, PATCH + дополнительные HEAD и OPTIONS. Если вам не хватает операций CRUD, автор рекомендует сделать подчиненный ресурс /actions, и делать к нему POST с указанием типа операции и дополнительных параметров. Такой небольшой кусочек RPC-like style, когда RESTful не одобряет, но очень хочется.
2.1. Заголовки HTTP
Используйте заголовки! Тема тут обширная, но в основном заголовки используются для безопасности, переговоров клиента и сервера о форматах и кодировках контента, о кэшировании, версиях и обновлениях ресурсов, их размерах. Собственно, запрос HEAD возвращает заголовки без самого тела ресурса, чтобы клиент мог понять — нужно ли запрашивать ресурс вообще.
2.2. Параметры запроса
Используйте параметры запроса! (та часть, которая после @?"). Не забывайте про такие операции, как фильтрация, поиск, сортировка и пагинация. Для фильтров добавляем названия полей ресурса, по которым можно отфильтровать результат, указав значения или диапазон:
https://example.com/api/products?category=electronics&price=50-100
Для поиска — параметр
?q={строка поиска}. Для сортировки:
?sort={поле, по которому сортируем}&order={ASC|DESC}. Как вариант, для сортировки по нескольким полям: ?sort=name,-price (сортируем по названию в прямом порядке, по цене — в обратном).Для пагинации указываем число элементов на странице и номер страницы:
?limit=10&offset=20.2.3. Коды ошибок
Используйте коды ошибок HTTP.
Уровень 3. Управление гипермедиа.
Тут два аспекта: обсуждение формата и HATEOAS.
3.1. Обсуждение формата — это про заголовки. Клиент и сервер договариваются, в каком формате сервер вернет ресурс. Может, в json, может в XML, а может просто в виде текста. В теории должно работать, и серверы должны отдавать ресурс в удобном для клиента представлении. На практике реализация встречается очень редко, но во внутренних гетерогенных системах может быть полезным. Запрос OPTIONS как раз про это: какие действия допускает сервер над ресурсом и в каких форматах готов его отдавать.
❤9🔥5👍3
3.2. HATEOAS. Hypermedia As Transfer Engine Of Application State. Не бывает. Хотя идея в целом хорошая: к ответу сервер должен цеплять перечень эндпоинтов, связанных с запрашиваемым ресурсом, показывая всю иерархию подчиненных ресурсов. В теории, если вы обращаетесь к корню API, сервер должен отдать всю структуру API, фактически -- документацию. Но реализации такого почти не встречается.
3.3. Версионирование. Тут понятно: у вас может быть несколько версий API, и клиент может пользоваться только какой-то конкретной. Варианта два — добавляем версию в URL: /v2/user или в кастомный заголовок типа X-API-VERSION или похожий.
Вот такие уровни зрелости и правила REST. И цитата из Роя Филдинга:
3.3. Версионирование. Тут понятно: у вас может быть несколько версий API, и клиент может пользоваться только какой-то конкретной. Варианта два — добавляем версию в URL: /v2/user или в кастомный заголовок типа X-API-VERSION или похожий.
Вот такие уровни зрелости и правила REST. И цитата из Роя Филдинга:
A REST API should be entered with no prior knowledge beyond the initial URI and set of standardized media types that are appropriate for the intended audience. [...]
In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.
🔥11❤4👍3
К вопросу про развитие "после senior": обнаружилась забавная история — некоторые работодатели, когда хотят написать "опытный аналитик", пишут "Бизнес-архитектор"; особенно такое название любят интеграторы.
Список обязанностей достаточно типовой для аналитика:
— выявлять требования заказчика совместно с командой аналитиков;
— проектировать и описывать сквозные бизнес-процессы;
— формулировать архитектурное видение и требования к продуктам, входящим в единое проектное решение:
— искать способы использования готового функционала в продуктах для решения потребности заказчика;
— валидировать технологические решения;
— совместно с владельцами продукта находить возможности реализации требуемой функциональности;
— участвовать в переговорах с заказчиком и отстаивать архитектурное решение перед ним;
— проводить демонстрации для заказчика: обсуждать реализованные пользовательские сценарии, требования к бизнес-процессам;
— разрабатывать в паре с техническим писателем техническую документацию, описывающую целевую модель разрабатываемого решения по согласованным бизнес-требованиям;
— участвовать в подготовке и проведении приемо-сдаточных испытаний;
— организовывать обучение пользователей заказчика;
— быть единой точкой экспертизы по проектному решению для заказчика и участников команды.
Или вот:
— Анализ общего перечня функциональных требований. Определение расхождений с базовым функционалом системы и противоречий с существующей архитектурой системы.
— Взаимодействие с заказчиком на уровне согласования общей архитектуры системы в контексте бизнес-процессов, управление конфигурацией и составом решения.
— Непрерывный мониторинг в части изменения требований и соответствия поставляемого продукта данным требованиям.
— Формирование консолидированной оценки по объему работ в рамках запросов на разработку и конфигурацию системы.
— Управление сквозными кросс-модульными клиентскими путями и пользовательским опытом.
— Принятие решений о подходе к реализации функциональных требований в рамках стандарта и запросов на разработку.
— Непрерывное взаимодействие с менеджерами продуктов и системными аналитиками в рамках проработки решений.
— Участие в разрешении сложных вопросов по реализации требований совместно с техническим архитектором и руководителями направлений, поиск обходных путей.
— Согласование и экспертиза проектной документации
Иногда, конечно, под этим названием попадаются и настоящие бизнес-архитекторы, основная задача которых, по-честному: "Развивать возможности бизнеса, идентифицировать и реагировать на изменения рынка и окружающей среды" и "Исследовать и описывать бизнес-архитектуру компании на языке потоков ценностей и business-capabilities, бизнес-функций, бизнес-сервисов, бизнес-возможностей и бизнес-процессов" — но это буквально только в одной вакансии.
В общем, хотите стать архитектором — просто назовите себя архитектором! Делов-то.
Список обязанностей достаточно типовой для аналитика:
— выявлять требования заказчика совместно с командой аналитиков;
— проектировать и описывать сквозные бизнес-процессы;
— формулировать архитектурное видение и требования к продуктам, входящим в единое проектное решение:
— искать способы использования готового функционала в продуктах для решения потребности заказчика;
— валидировать технологические решения;
— совместно с владельцами продукта находить возможности реализации требуемой функциональности;
— участвовать в переговорах с заказчиком и отстаивать архитектурное решение перед ним;
— проводить демонстрации для заказчика: обсуждать реализованные пользовательские сценарии, требования к бизнес-процессам;
— разрабатывать в паре с техническим писателем техническую документацию, описывающую целевую модель разрабатываемого решения по согласованным бизнес-требованиям;
— участвовать в подготовке и проведении приемо-сдаточных испытаний;
— организовывать обучение пользователей заказчика;
— быть единой точкой экспертизы по проектному решению для заказчика и участников команды.
Или вот:
— Анализ общего перечня функциональных требований. Определение расхождений с базовым функционалом системы и противоречий с существующей архитектурой системы.
— Взаимодействие с заказчиком на уровне согласования общей архитектуры системы в контексте бизнес-процессов, управление конфигурацией и составом решения.
— Непрерывный мониторинг в части изменения требований и соответствия поставляемого продукта данным требованиям.
— Формирование консолидированной оценки по объему работ в рамках запросов на разработку и конфигурацию системы.
— Управление сквозными кросс-модульными клиентскими путями и пользовательским опытом.
— Принятие решений о подходе к реализации функциональных требований в рамках стандарта и запросов на разработку.
— Непрерывное взаимодействие с менеджерами продуктов и системными аналитиками в рамках проработки решений.
— Участие в разрешении сложных вопросов по реализации требований совместно с техническим архитектором и руководителями направлений, поиск обходных путей.
— Согласование и экспертиза проектной документации
Иногда, конечно, под этим названием попадаются и настоящие бизнес-архитекторы, основная задача которых, по-честному: "Развивать возможности бизнеса, идентифицировать и реагировать на изменения рынка и окружающей среды" и "Исследовать и описывать бизнес-архитектуру компании на языке потоков ценностей и business-capabilities, бизнес-функций, бизнес-сервисов, бизнес-возможностей и бизнес-процессов" — но это буквально только в одной вакансии.
В общем, хотите стать архитектором — просто назовите себя архитектором! Делов-то.
😁19👍4👎2❤1
Придумал игру "Снежинки среди нас": новогодняя ИТ-мафия. Позволяет и развлечься, и прокачать софт-скиллы, и украсить офис к Новому году.
Правила как в Мафии, только роли такие:
— Скрам-мастер — ведущий. В игре не участвует, но следит за ритуалами.
— Заказчики. Их несколько, никто не знает, кто они, но каждую ночь они просыпаются и подбрасывают в бэклог новые таски, и могут, на выбор — либо забраковать произвольное число готовых задач ("не прошли приемку"), или потребовать снять кого-нибудь с проекта. Таски выбираются из отдельной колоды с идеями по украшению офиса: вырезать снежинку, раскрасить гномика, сделать гирлянду и т.п. За одну ночь можно подкинуть в бэклог столько тасок, сколько осталось игроков. В начале игры бэклог наполняется тасками по числу игроков x2.
— Команда. Ночью спят, днём выполняют таски из бэклога. Заодно обсуждают, как вообще успеть сделать всё, что навалили, и кого можно выгнать, чтобы уже перестали наваливать. Тот, кого выгоняют, вскрывает свою карту и дальше участвует только как наблюдатель. Во время спринта ("днем") Заказчики работают, как члены команды.
— Продакт-оунер. Просыпается раньше всех, может либо проверить кого-то — не является ли тот Заказчиком, либо выкинуть из бэклога несколько задач, которые ещё не взяли в работу (до половины от числа оставшихся игроков).
— Ресурсный менеджер. Может спасти от снятия с проекта одного из членов Команды, но не дважды подряд. Себя может спасти только один раз за игру.
— Человек-снежинка. Не является Заказчиком, но выигрывает, когда выигрывают они. Никакими специальными умениями не обладает, ночью не просыпается, но старается незаметно парализовать работу команды.
Игра заканчивается победой Команды, если всех Заказчиков выкинули (объявлен фича-фриз и можно спокойно доделать все задачи в работе).
Заказчики (и Снежинки) побеждают, когда Команда полностью разобрана (результат работы им достаётся бесплатно + неустойка).
Пока на практике играть не пробовал, но должно быть весело!
Правила как в Мафии, только роли такие:
— Скрам-мастер — ведущий. В игре не участвует, но следит за ритуалами.
— Заказчики. Их несколько, никто не знает, кто они, но каждую ночь они просыпаются и подбрасывают в бэклог новые таски, и могут, на выбор — либо забраковать произвольное число готовых задач ("не прошли приемку"), или потребовать снять кого-нибудь с проекта. Таски выбираются из отдельной колоды с идеями по украшению офиса: вырезать снежинку, раскрасить гномика, сделать гирлянду и т.п. За одну ночь можно подкинуть в бэклог столько тасок, сколько осталось игроков. В начале игры бэклог наполняется тасками по числу игроков x2.
— Команда. Ночью спят, днём выполняют таски из бэклога. Заодно обсуждают, как вообще успеть сделать всё, что навалили, и кого можно выгнать, чтобы уже перестали наваливать. Тот, кого выгоняют, вскрывает свою карту и дальше участвует только как наблюдатель. Во время спринта ("днем") Заказчики работают, как члены команды.
— Продакт-оунер. Просыпается раньше всех, может либо проверить кого-то — не является ли тот Заказчиком, либо выкинуть из бэклога несколько задач, которые ещё не взяли в работу (до половины от числа оставшихся игроков).
— Ресурсный менеджер. Может спасти от снятия с проекта одного из членов Команды, но не дважды подряд. Себя может спасти только один раз за игру.
— Человек-снежинка. Не является Заказчиком, но выигрывает, когда выигрывают они. Никакими специальными умениями не обладает, ночью не просыпается, но старается незаметно парализовать работу команды.
Игра заканчивается победой Команды, если всех Заказчиков выкинули (объявлен фича-фриз и можно спокойно доделать все задачи в работе).
Заказчики (и Снежинки) побеждают, когда Команда полностью разобрана (результат работы им достаётся бесплатно + неустойка).
Пока на практике играть не пробовал, но должно быть весело!
🔥42😁28👏7👍2
Практически на каждом Летнем аналитическом фестивале умудрённые опытом аналитики жаловалась, что для них мало докладов, а всё в основном для начинающих и миддлов. И вот, наконец, организаторы решили сделать отдельное событие для опытных системных аналитиков! Причём зимой. Меня пригласили в качестве председателя программного комитета, что очень лестно. Я ещё помню, как 10 лет назад выступал на ЛАФ, и это было чуть ли не первое выступление моё на отраслевой конференции вообще.
Но для опытных в системном анализе людей мы не хотим делать просто конференцию, "чтобы послушать" — мы хотим вместе поговорить про саму нашу отрасль, и выпустить в итоге некоторый манифест или совместное видение того, где мы находимся и куда движемся.
🎙 Итак, идея Зимних аналитических выходных 2024 — настоящее и будущее индустрии системного анализа. Кроме традиционных докладов и мастер-классов мы запланировали сессии совместного выявления основных трендов и требований к самим задачам системного анализа, к людям, которые работают в этой сфере, и к подразделениям, выполняющим эту роль в компании.
В течение 2 дней на площадках мероприятия пройдет более 20 докладов, мастер-классов, круглых столов и деловых игр от топовых экспертов, основателей сообществ аналитиков, авторов профессиональных стандартов и карт компетенций, руководителей направлений СА.
📆 Даты: 17-18 февраля 2024 года.
🏨 По традиции ЛАФ, это загородный отель, проживание по системе "все включено", зимние развлечения, бассейн, скалодром и всё такое. И afterparty с музыкой и общением 🎉.
Мы уже собрали звездный пул спикеров, но программа ещё будет пополняться. Регистрация уже открыта: участвуйте в самом ярком аналитическом событии зимы! 🚀❄️
Но для опытных в системном анализе людей мы не хотим делать просто конференцию, "чтобы послушать" — мы хотим вместе поговорить про саму нашу отрасль, и выпустить в итоге некоторый манифест или совместное видение того, где мы находимся и куда движемся.
🎙 Итак, идея Зимних аналитических выходных 2024 — настоящее и будущее индустрии системного анализа. Кроме традиционных докладов и мастер-классов мы запланировали сессии совместного выявления основных трендов и требований к самим задачам системного анализа, к людям, которые работают в этой сфере, и к подразделениям, выполняющим эту роль в компании.
В течение 2 дней на площадках мероприятия пройдет более 20 докладов, мастер-классов, круглых столов и деловых игр от топовых экспертов, основателей сообществ аналитиков, авторов профессиональных стандартов и карт компетенций, руководителей направлений СА.
📆 Даты: 17-18 февраля 2024 года.
🏨 По традиции ЛАФ, это загородный отель, проживание по системе "все включено", зимние развлечения, бассейн, скалодром и всё такое. И afterparty с музыкой и общением 🎉.
Мы уже собрали звездный пул спикеров, но программа ещё будет пополняться. Регистрация уже открыта: участвуйте в самом ярком аналитическом событии зимы! 🚀❄️
🔥18❤1🆒1
Интересная мысль про необходимость роли системного аналитика из-за протечек абстракций (а точнее — ещё и из-за слабой изоляции контекстов).
То есть, у нас обычно системы так реализованы, что у них контексты сильно пересекаются — от этого сразу не ясно, в какой системе делать изменения. Нет чёткого понимания, за что каждая система отвечает, а за что нет.
Одновременно в системах ещё и слои абстракций дырявые: представление данных для пользователя не отделено от способов хранения данных, а логика вообще размазана по всем слоям.
Тут-то конечно, для каждого изменения нужно разобраться — что где лежит, что где отображается и что где проверяется и преобразуется. И куда новые функции воткнуть, чтобы ничего не сломать.
Продолжая тему игр — это Дженга наоборот получается: как напихать в систему ещё функций, пока она не совсем не развалится. Причем в N-мерном пространстве.
Собственно, задачи по интеграции почти все такие — понять, в какой из N систем должна быть новая функция, найти K систем, из которых нужно данные взять и в которые отправить, и решить — кто именно будет брать, что брать, куда отправлять, кто за всем этим будет следить + всё это ещё и во времени.
Ergo, если мы имеем чистую архитектуру, low coupling high cohesion, да ещё и единый язык бизнеса и разработки, то системные аналитики становятся ненужными. Хм, кажется, я только что сформулировал основные принципы DDD.
Аналитики! Сопротивляйтесь внедрению в своих компаниях DDD! Запутывайте архитектуру!Ломайте станки! Храните документацию в Ворде!
То есть, у нас обычно системы так реализованы, что у них контексты сильно пересекаются — от этого сразу не ясно, в какой системе делать изменения. Нет чёткого понимания, за что каждая система отвечает, а за что нет.
Одновременно в системах ещё и слои абстракций дырявые: представление данных для пользователя не отделено от способов хранения данных, а логика вообще размазана по всем слоям.
Тут-то конечно, для каждого изменения нужно разобраться — что где лежит, что где отображается и что где проверяется и преобразуется. И куда новые функции воткнуть, чтобы ничего не сломать.
Продолжая тему игр — это Дженга наоборот получается: как напихать в систему ещё функций, пока она не совсем не развалится. Причем в N-мерном пространстве.
Собственно, задачи по интеграции почти все такие — понять, в какой из N систем должна быть новая функция, найти K систем, из которых нужно данные взять и в которые отправить, и решить — кто именно будет брать, что брать, куда отправлять, кто за всем этим будет следить + всё это ещё и во времени.
Ergo, если мы имеем чистую архитектуру, low coupling high cohesion, да ещё и единый язык бизнеса и разработки, то системные аналитики становятся ненужными. Хм, кажется, я только что сформулировал основные принципы DDD.
Аналитики! Сопротивляйтесь внедрению в своих компаниях DDD! Запутывайте архитектуру!
😁35👍4🔥2🥰2
Forwarded from Sergey Baranov
В крупных организациях, опять же, по моему опыту (он достаточно обширный) системный аналитик занимается тремя основными вещами:
1. Проводит сбор требований со стейкхолдеров
2. Пытается определить в каких ИС и какие изменения необходимо реализовать (это следствие бесконечно огромных протечек моделей предметных областей друг в друга, высокой привнесенной сложности)
3. Фиксирует требования и какие ИС затрагиваются в документах
1. Проводит сбор требований со стейкхолдеров
2. Пытается определить в каких ИС и какие изменения необходимо реализовать (это следствие бесконечно огромных протечек моделей предметных областей друг в друга, высокой привнесенной сложности)
3. Фиксирует требования и какие ИС затрагиваются в документах
СМИ и блогеры тиражируют исследование Head Hunter'а — хотя первоисточник не находится почему-то — по профессиям специалистов с самой большой средней зарплатой.
И там на первом месте Devops (214 тыс.) , на втором — дата саентисты (202), а вот на третьем — системные аналитики (150). С чем всех коллег и поздравляю!
Понятно, что это средние зарплаты по стране, и за неимением первоисточника трудно сказать — какой там разброс и кто утянул на дно разработчиков, и куда вообще подевались архитекторы, которым раньше меньше 240 не предлагали.
Но в целом вы теперь знаете, на что в среднем ориентироваться.
И там на первом месте Devops (214 тыс.) , на втором — дата саентисты (202), а вот на третьем — системные аналитики (150). С чем всех коллег и поздравляю!
Понятно, что это средние зарплаты по стране, и за неимением первоисточника трудно сказать — какой там разброс и кто утянул на дно разработчиков, и куда вообще подевались архитекторы, которым раньше меньше 240 не предлагали.
Но в целом вы теперь знаете, на что в среднем ориентироваться.
❤10👍8🎉3
А вот ещё интересный взгляд на роль аналитика (и архитектора) с точки зрения Теории ограничений (TOC) Голдратта. Если у вас разработка является ограничением, логично перед ней ставить звено предобработки, чтобы на вход подавать не сырье, а заготовку. (Помним, что Голдратт в основном анализировал материальные производства).
Как вам кажется, похоже это на работу аналитика? Не постановка задачи, а предобработка, подготовка материала для работы, создание заготовок.
Если с этой точки зрения посмотреть на процесс, можно уточнить у разработки — что именно им полезно в качестве заготовки, а что не нужно (заготовка не должна быть излишне тщательной).
Как вам кажется, похоже это на работу аналитика? Не постановка задачи, а предобработка, подготовка материала для работы, создание заготовок.
Если с этой точки зрения посмотреть на процесс, можно уточнить у разработки — что именно им полезно в качестве заготовки, а что не нужно (заготовка не должна быть излишне тщательной).
🔥5👍1
Forwarded from Управление проектным бизнесом (Alexey Vasilyev [bipulse.ru])
Про Винcтона Ройса, Agile и разработку программного обеспечения.
На заре индустрии разработки программного обеспечения был хороший доклад Винстона Ройса (Winston Royce 1970) про то, как БЫСТРЕЕ выводить программный продукт в эксплуатацию. Так, как основная проблема отрасли это... ОШИБКИ!
Ключевая мысль доклада: Пиши БОЛЬШЕ документов, чтобы БЫСТРЕЕ выводить программный продукт в эксплуатацию.
И тут стоит понимать, что в 1970 году, время от Идеи до осязаемого Результата - минимум 1 неделя, просто потому что технологии такие.
И тут на курсе (который сейчас провожу), при разборе применения Теории Ограничений коллеги заметили что, на самом деле Ройс решал проблему ЗАЩИТЫ ОГРАНИЧЕНИЯ!
То есть:
Пиши много документов для того, чтобы..... ЗАЩИТИТЬ ОГРАНИЧЕНИЕ!
Где Ограничение - машинное время ЭВМ.
Другими словами, это шаг "три" из пяти фокусирующих шагов ТОС.
Отсюда вывод:
Если у вас разработчики - это Ограничение, то им нужны Аналитики и Архитекторы, как "цех заготовки". Чтобы разработчики делали то, что нужно сделать и не делали то, что не нужно делать. И была "полная комплектация" перед началом работы по задаче.
#ответы_на_вопросы #TOC
На заре индустрии разработки программного обеспечения был хороший доклад Винстона Ройса (Winston Royce 1970) про то, как БЫСТРЕЕ выводить программный продукт в эксплуатацию. Так, как основная проблема отрасли это... ОШИБКИ!
Ключевая мысль доклада: Пиши БОЛЬШЕ документов, чтобы БЫСТРЕЕ выводить программный продукт в эксплуатацию.
И тут стоит понимать, что в 1970 году, время от Идеи до осязаемого Результата - минимум 1 неделя, просто потому что технологии такие.
И тут на курсе (который сейчас провожу), при разборе применения Теории Ограничений коллеги заметили что, на самом деле Ройс решал проблему ЗАЩИТЫ ОГРАНИЧЕНИЯ!
То есть:
Пиши много документов для того, чтобы..... ЗАЩИТИТЬ ОГРАНИЧЕНИЕ!
Где Ограничение - машинное время ЭВМ.
Другими словами, это шаг "три" из пяти фокусирующих шагов ТОС.
Отсюда вывод:
Если у вас разработчики - это Ограничение, то им нужны Аналитики и Архитекторы, как "цех заготовки". Чтобы разработчики делали то, что нужно сделать и не делали то, что не нужно делать. И была "полная комплектация" перед началом работы по задаче.
#ответы_на_вопросы #TOC
👍10❤1
Продолжают публиковать записи моих выступлений. В основном про ChatGPT, много про него говорил в этом году. Вот это — с Инфостарта, точнее с их спин-оффа "Анализ & управление в ИТ-проектах".
Видео: https://www.youtube.com/watch?v=qG0Hx3LeMlc
В виде текста: https://infostart.ru/pm/2004555/
Новости, конечно, в этой области устаревают стремительно. Всё уже поменялось с весны — теперь есть GPT4-turbo, в которой:
📆 данные о мире актуальны на апрель 2023,
📝окно контекста может быть до 128Кб (это прямо много!)
💻 есть возможность получить ответ, структурированный в виде json
🤖есть возможность воспроизводить строго одинаковый ответ для идентичных запросов
⚒есть возможность вызывать кастомные функции (запросы к внешним API, БД) и формировать ответ на основе их результата
🖼на вход можно подать изображение, и задать по нему вопросы (уже писал об этом тут на примере документирования интерфейсов, но так же можно и схемы в виде картинок разбирать -- например, попросить описание процесса и инструкции для участников по его модели-картинке).
Я уже не говорю о прогрессе альтернативных моделей, за ними пока просто не успеваю следить. Пишите, если знаете ещё хорошие новости.
Видео: https://www.youtube.com/watch?v=qG0Hx3LeMlc
В виде текста: https://infostart.ru/pm/2004555/
Новости, конечно, в этой области устаревают стремительно. Всё уже поменялось с весны — теперь есть GPT4-turbo, в которой:
📆 данные о мире актуальны на апрель 2023,
📝окно контекста может быть до 128Кб (это прямо много!)
🤖есть возможность воспроизводить строго одинаковый ответ для идентичных запросов
⚒есть возможность вызывать кастомные функции (запросы к внешним API, БД) и формировать ответ на основе их результата
🖼на вход можно подать изображение, и задать по нему вопросы (уже писал об этом тут на примере документирования интерфейсов, но так же можно и схемы в виде картинок разбирать -- например, попросить описание процесса и инструкции для участников по его модели-картинке).
Я уже не говорю о прогрессе альтернативных моделей, за ними пока просто не успеваю следить. Пишите, если знаете ещё хорошие новости.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Юрий Куприянов. Как искусственный интеллект помогает в работе с требованиями
С выходом ChatGPT стала общедоступна генерация текстов, очень похожих на творчество человека. Использование этой технологии может здорово облегчить вам жизнь и избавить от рутины, но только если вы сами хорошо понимаете – чего вы от него хотите, в каком виде…
👍20❤2🔥2
Персональный подарочек под ёлочку! 🎄
Теперь я ещё и "соавтор книги" 🤵♂
На самом деле, рад иметь общий труд вместе с людьми, которых считаю своими учителями — в университете и в профессии.
Всех с наступающим!🎄
Теперь я ещё и "соавтор книги" 🤵♂
На самом деле, рад иметь общий труд вместе с людьми, которых считаю своими учителями — в университете и в профессии.
Всех с наступающим!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥53👍15👏5🤓3🤝1
Всех с наступающим Новым годом! Счастья в новом году, профессиональных успехов и мирного неба! 🔥 🎄🥂
Please open Telegram to view this post
VIEW IN TELEGRAM
❤28☃8🎉8🦄2👍1
С наступившим Новым годом! Всем профессиональных успехов и развития в новом году!
Ну а я буду стараться докидывать вам авторского видения нашей отрасли, её задач и проблем, а также интересных материалов.
Вот, например, руководства по стилю REST API. Как мы все знаем, REST -- это просто набор архитектурных принципов, но, когда доходит дело проектирования конкретных API, возникает множество мелких вопросов. Иногда совсем мелких: какой регистр использовать для названий полей в json? А в названиях эндпоинтов? А имена ресурсов писать во множественном числе или в единственном?
Такие вопросы хорошо бы закрепить на уровне всей компании, чтобы не думать каждый раз заново.
Образцы таких гайдлайнов, как ни странно, можно найти у правительств разных стран. Они есть у Австралии, Новой Зеландии, Канады, Великобритании, у США конечно. Но мне больше всего нравится бельгийский гайдлайн: https://www.belgif.be/specification/rest/api-guide . Он и устроен наиболее логично, и как-то по-человечески, что ли. И при этом учитывает разнообразные аспекты, о которых и вправду стоит подумать.
В частности, в нём есть:
👉🏻 формат для URI эндпоинтов: рекомендуется lowerCamelCase, без расширений файлов;
👉🏻 три типа ресурсов: документ, коллекция и контроллер.
Документ — единичная сущность, с которой можно делать CRUD, у неё есть id, URI и поля;
Коллекция — набор однотипных сущностей, с которыми можно делать только GET и POST, и в редких случаях DELETE - если мы хотим удалить все элементы сразу;
документы обычно лежат в коллекциях, и могут содержать подчиненные коллекции:
Ну а контроллер — это подчиненный ресурс документа, представляющий бизнес-операцию, не укладывающуюся в CRUD (примеры:
👉🏻 спецификация дополнительных операций: для документов — ?select={(поле,(поле,поле))}, чтобы выбирать только указанные поля — убираем overfetching;
для коллекций — сортировка: ?sort={поля для сортировки} , пагинация: ?page, ?next, ?prev, ?pageSize= , полнотекстовый поиск: ?q={поисковый запрос}, фильтрация: ?{поле}={значение}.
👉🏻 механизм для встраивания ресурсов (возможности GraphQL в REST!): ?embed={название связанной сущности, которую мы хотим встроить в ответ}, убираем underfetching.
👉🏻 требования к идентификаторам документов: рекомендуется текст, URI или UUID, а вообще там множество нюансов: идентификатор должен хорошо запоминаться, легко вводиться, легко проверяться, распечатываться, подсказывать природу объекта (по структуре идентификатора), предупреждать коллизии, не содержать чувствительной информации, не быть легким для подбора (если идентификаторы выдаются последовательно - легко угадать предыдущие и последующие, и даже вычислить, например, количество сущностей), использоваться в разных системах, быть расширяемым, вставляться в URL, логичным образом сортироваться... То есть вообще непонятно, бывают ли идентификаторы, удовлетворяющие всем требованиям!
👉🏻 рекомендации по использованию кодов ошибок;
👉🏻 соглашение об использовании значений null в json (решение: не должны использоваться, чтобы не создавать неоднозначности; если значение null, то оно не передаётся. При этом [] — это не null!)
👉🏻 кэширование (по времени и по содержимому, управление через параметры заголовка:
👉🏻 эволюция и версионирование API (обсуждаются совместимые и несовместимые изменения)
👉🏻 интернационализация (фильтрация языка через ?lang={код языка})
👉🏻 отслеживание (Trace-Id в заголовках)
👉🏻 статус API (ресурс health)
В общем, рекомендую и для справки и тренировки насмотренности — всё-таки, тут зафиксировано решение многих вопросов, с которыми авторы сталкивались в реальной жизни, и для использования в качестве шаблона, если у себя в компании соберетесь вводить единые гайдлайны.
Ну а я буду стараться докидывать вам авторского видения нашей отрасли, её задач и проблем, а также интересных материалов.
Вот, например, руководства по стилю REST API. Как мы все знаем, REST -- это просто набор архитектурных принципов, но, когда доходит дело проектирования конкретных API, возникает множество мелких вопросов. Иногда совсем мелких: какой регистр использовать для названий полей в json? А в названиях эндпоинтов? А имена ресурсов писать во множественном числе или в единственном?
Такие вопросы хорошо бы закрепить на уровне всей компании, чтобы не думать каждый раз заново.
Образцы таких гайдлайнов, как ни странно, можно найти у правительств разных стран. Они есть у Австралии, Новой Зеландии, Канады, Великобритании, у США конечно. Но мне больше всего нравится бельгийский гайдлайн: https://www.belgif.be/specification/rest/api-guide . Он и устроен наиболее логично, и как-то по-человечески, что ли. И при этом учитывает разнообразные аспекты, о которых и вправду стоит подумать.
В частности, в нём есть:
👉🏻 формат для URI эндпоинтов: рекомендуется lowerCamelCase, без расширений файлов;
👉🏻 три типа ресурсов: документ, коллекция и контроллер.
Документ — единичная сущность, с которой можно делать CRUD, у неё есть id, URI и поля;
Коллекция — набор однотипных сущностей, с которыми можно делать только GET и POST, и в редких случаях DELETE - если мы хотим удалить все элементы сразу;
документы обычно лежат в коллекциях, и могут содержать подчиненные коллекции:
/{имя коллекции}/{id документа}/{имя подчиненной коллекции}/{id подчиненного документа}. Ну а контроллер — это подчиненный ресурс документа, представляющий бизнес-операцию, не укладывающуюся в CRUD (примеры:
POST /accounts/123/withdraw, GET /convertMoney?from=EUR&amount=45&to=USD). При этом для долгих операций рекомендуется создавать ресурс типа документ, и уметь возвращать промежуточный статус операции (превращая её, таким образом, в асинхронную).👉🏻 спецификация дополнительных операций: для документов — ?select={(поле,(поле,поле))}, чтобы выбирать только указанные поля — убираем overfetching;
для коллекций — сортировка: ?sort={поля для сортировки} , пагинация: ?page, ?next, ?prev, ?pageSize= , полнотекстовый поиск: ?q={поисковый запрос}, фильтрация: ?{поле}={значение}.
👉🏻 механизм для встраивания ресурсов (возможности GraphQL в REST!): ?embed={название связанной сущности, которую мы хотим встроить в ответ}, убираем underfetching.
👉🏻 требования к идентификаторам документов: рекомендуется текст, URI или UUID, а вообще там множество нюансов: идентификатор должен хорошо запоминаться, легко вводиться, легко проверяться, распечатываться, подсказывать природу объекта (по структуре идентификатора), предупреждать коллизии, не содержать чувствительной информации, не быть легким для подбора (если идентификаторы выдаются последовательно - легко угадать предыдущие и последующие, и даже вычислить, например, количество сущностей), использоваться в разных системах, быть расширяемым, вставляться в URL, логичным образом сортироваться... То есть вообще непонятно, бывают ли идентификаторы, удовлетворяющие всем требованиям!
👉🏻 рекомендации по использованию кодов ошибок;
👉🏻 соглашение об использовании значений null в json (решение: не должны использоваться, чтобы не создавать неоднозначности; если значение null, то оно не передаётся. При этом [] — это не null!)
👉🏻 кэширование (по времени и по содержимому, управление через параметры заголовка:
👉🏻 эволюция и версионирование API (обсуждаются совместимые и несовместимые изменения)
👉🏻 интернационализация (фильтрация языка через ?lang={код языка})
👉🏻 отслеживание (Trace-Id в заголовках)
👉🏻 статус API (ресурс health)
В общем, рекомендую и для справки и тренировки насмотренности — всё-таки, тут зафиксировано решение многих вопросов, с которыми авторы сталкивались в реальной жизни, и для использования в качестве шаблона, если у себя в компании соберетесь вводить единые гайдлайны.
👍39❤5🔥2
Коллеги приглашают пройти опрос и предложить темы для ИТ-конференций. Мне, как члену Программных комитетов двух конференций, было бы очень интересно — какие направления и темы интересны участникам. Так что, пожалуйста, пройдите опрос! Результаты тоже опубликую.
Друзья, коллеги, всем привет! 🙌
Просим всех принять участие в опросе об интересных для вас темах докладов на IT-конференциях.
Результаты будут доступны для широкого круга. Это поможет и ПК, и спикерам выбирать для вас наиболее актуальные и интересные темы.
Две минуты вашего драгоценного времени сейчас - бесценный вклад 💎 в качество конференций!
Будем благодарны за репосты коллегам-айтишникам любых ролей!
Пройти опрос 🔥 ОПРОС О ТЕМАХ ДОКЛАДОВ 🔥
Друзья, коллеги, всем привет! 🙌
Просим всех принять участие в опросе об интересных для вас темах докладов на IT-конференциях.
Результаты будут доступны для широкого круга. Это поможет и ПК, и спикерам выбирать для вас наиболее актуальные и интересные темы.
Две минуты вашего драгоценного времени сейчас - бесценный вклад 💎 в качество конференций!
Будем благодарны за репосты коллегам-айтишникам любых ролей!
Пройти опрос 🔥 ОПРОС О ТЕМАХ ДОКЛАДОВ 🔥
❤2👍1
Когнитивные паттерны аналитика.
В обсуждениях поста про темы докладов возник очень классный запрос на обзор когнитивных стратегий системного аналитика.
Как думают экспертные и опытные системные аналитики? Про что они думают? Что важно в ходе их мыслей?
Тема интересная, и требует рефлексии - не всегда эксперт сам понимает, как он думает 🤷🏼♂️
В целом за стратегию не скажу, но вот отдельные паттерны, которые бывают полезными (без какой-либо последовательности, скорее для проверки):
👁 Умение видеть абстракции и переключаться между ними. То есть, когда мы говорим или читаем про какой-то объект/явление, мы должны понимать — на каком уровне этот объект находится. Это уровень бизнеса? Или уровень действий пользователя? Или уровень интерфейса системы? Устройства системы? (И все уровни внутри архитектуры). Переключаться — это видеть связи и понимать, как объект на одном уровне соответствует уровню на другом. И как может быть по-другому. Тут же — понимание связи и умение различать функцию и конструкцию. Вот есть кнопка. Это часть конструкции. Какую функцию она выполняет? Показывает следующую страницу выдачи найденных товаров. Можно ли для той же функции использовать другую конструкцию? Можно, например — показывая следующую страницу по долистыванию до низа страницы. Это, кстати, так же разница между действием (по смыслу) и интерфейсом (по виду элемента управления для этого действия).
Идём вниз по уровню абстракции — как реализовано действие по этой кнопке? Как это разложено в слоях архитектуры системы: на фронте, в методах API, в контроллере, в уровне доступа к данным. Идём вверх — какие действия пользователь тут выполняет? Зачем ему вообще постраничный вывод, что он хочет увидеть? Для чего он это делает, в рамках какой деятельности? В чём его цель?
⚛️ Машинка типов. Мы смотрим на объект, какого он типа? Какие объекты одного типа с ним? Какие отличаются? Какие есть производные типы? Какие есть обобщающие понятия (супертипы)? Тут мы можем ответить на известный вопрос, как сложить яблоки с грушами. Да очень просто, 2 яблока + 3 груши = 5 фруктов. Что объединяет договор, счёт и акт? Они все — документы, у каждого есть номер, дата, подпись. С документом любого вида можно обращаться одинаково, но у каждого конкретного вида есть свои специфические поля и варианты действий (счет можно оплатить, а договор - расторгнуть).
🎭 Выявление омонимов: называется одинаково, а смысл (и тип!) разный. Вот тут "пользователь" — это объект в системе, "карточка пользователя", на самом деле, или действующее лицо, актор, который в системе не учтен?
📈 Разница между структурой данных и их представлением. Мы видим какой-то объект, содержащий данные. Это самостоятельный объект, или это просто форма представления данных каких-то объектов? Выписка, отчёт, витрина?..
💬 Выявление общих и конкретных слов. Тут просто: если можем вставить слово "какой-то" и это нормально звучит — значит, слишком общее слово, нужно конкретизировать.
🔬 Внимание к определениям. Что означает это слово? Оно имеет общее, единым образом понимаемое значение? Или оно в данной предметной области означает что-то специальное? Вводилось ли это слово ранее, или оно встретилось впервые?
📁 Группировка и разделение данных/функций по принципу единой ответственности. То, что в микросервисах называется "low coupling, high cohesion", а в ООП — SRP. Тут может быть и протечка абстракций (в одном классе и хранение данных и представление), и смешение бизнес-логики (в одном классе и список студентов, и их оценки по предметам).
🧬 Учет кратности связей: что с чем сколько раз связано? Что у кого сколько раз может быть? В сколько групп может быть зачислен студент? Сколько студентов может быть в группе? Сколько оценок может быть у студента по одному предмету? Скольким студентам может быть выставлена оценка?
🎩 Умение принимать разные роли и смотреть с разных позиций (на систему). А теперь смотрим с точки зрения архитектора. А теперь — с точки зрения пользователя. А теперь — с точки зрения офицера безопасности. И т.д.
В обсуждениях поста про темы докладов возник очень классный запрос на обзор когнитивных стратегий системного аналитика.
Как думают экспертные и опытные системные аналитики? Про что они думают? Что важно в ходе их мыслей?
Тема интересная, и требует рефлексии - не всегда эксперт сам понимает, как он думает 🤷🏼♂️
В целом за стратегию не скажу, но вот отдельные паттерны, которые бывают полезными (без какой-либо последовательности, скорее для проверки):
Идём вниз по уровню абстракции — как реализовано действие по этой кнопке? Как это разложено в слоях архитектуры системы: на фронте, в методах API, в контроллере, в уровне доступа к данным. Идём вверх — какие действия пользователь тут выполняет? Зачем ему вообще постраничный вывод, что он хочет увидеть? Для чего он это делает, в рамках какой деятельности? В чём его цель?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍33🔥15👌1
This media is not supported in your browser
VIEW IN TELEGRAM
ByteByteGo (проект Алекса Сюя, автора System Design Interview) прислал шпаргалку по основным принципам REST API.
Разрешение, правда маловато, так что продублирую текстом. Вот что они считают главным в REST:
1️⃣ Клиент-сервер. Причем понимают это как разделение пользовательского интерфейса и хранения/процессинга данных. Что, в свою очередь, обеспечивает масштабирование и переносимость.
2️⃣ Отсутствие состояния. В каждом запросе клиент отправляет всю необходимую для обработки информацию, состояние сессии не хранится на сервере.
3️⃣ Кэширование. Ответ сервера может быть в явном виде помечен как кэшируемый или некэшируемый, что позволяет клиенту оптимизировать число перезапросов.
4️⃣ Слоистая система. Для клиента прозрачна, а на стороне сервера позволяет организовать промежуточные слои — для безопасности, балансировки, изолирования реальной архитектуры обработки и хранения и т.п.
5️⃣ Код по запросу. Сервер может передавать клиенту программный код для обработки или представления данных, таким образом расширяя возможности клиента и добавляя гибкости.
6️⃣ Стандартизированный интерфейс: понятно, как строить запрос.
Элементы запроса:
🔹Глагол http (GET, POST, PUT, PATCH, DELETE)
🔹Протокол (всегда HTTPS://)
🔸Субдомен для API
🔸Версия (/v1)
🔸Эндпоинт — имя ресурса (существительное)
🔹Параметры фильтрации
🔹Параметры пагинации (page, limit)
А теперь проверьте себя — используете ли вы эти возможности в своих "REST API", или вы просто JSON'ы кидаете через HTTP? 😉
Разрешение, правда маловато, так что продублирую текстом. Вот что они считают главным в REST:
Элементы запроса:
🔹Глагол http (GET, POST, PUT, PATCH, DELETE)
🔹Протокол (всегда HTTPS://)
🔸Субдомен для API
🔸Версия (/v1)
🔸Эндпоинт — имя ресурса (существительное)
🔹Параметры фильтрации
🔹Параметры пагинации (page, limit)
А теперь проверьте себя — используете ли вы эти возможности в своих "REST API", или вы просто JSON'ы кидаете через HTTP? 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22
Разговор про когнитивные стратегии напомнил мне старую (1997 года!) культовую и немного эзотерическую книгу (или сборник статей) "Программистский камень" — Programmer's Stone. Книга как раз пытается ответить на вопрос — чем отличаются лучшие программисты в плане мышления.
В первой части авторы предполагают деление людей на "паковщиков" (packers) и "картостроителей" (mappers). Подавляющее большинство людей — "паковщики".
Особенности и стиль рассуждений паковщиков:
1. Запомнить множество инструкций и алгоритмов решения проблем.
2. При встрече с задачей — попробовать вспомнить из своего опыта или спросить у окружающих подходящий алгоритм для решения похожей задачи
3. Предложить решение, аналогичное предыдущему опыту.
4. Следовать алгоритму и убеждать других следовать алгоритму/процедуре.
5. Если люди не следуют процедуре — могут злиться на них и расстраиваться.
6. Ориентированы на процесс.
7. Запутанные задачи (high complexity) вызывают фрустрацию (не находится подходящий алгоритм).
8. Нравятся стандарты, традиции, ритуалы, регулярные, повторяемые действия — так спокойнее. Учатся по книгам и курсам.
9. Склонны к трудоголизму, переработкам.
10. Чаще бывают экстравертами, любят общаться.
Особенности и стиль рассуждений картостроителей:
1. Создать мысленную модель проблемы.
2. Исследовать связи между всеми объектами в проблемной области.
3. Определить требуемый результат и его измеримые показатели.
4. Упростить проблему до минимально разумного уровня (соотнося при этом частные решения с общей картиной и итоговым результатом).
5. Ориентированы на результат. Испытывают трудности с выполнением повторяемых процессов, часто даже бесятся от них. Учатся всему в основном сами, складывая из обрывков знаний общую картину.
6. Генерируют сразу множество идей. Креативны и любопытны. Легко отвлекаются. Могут по цепочке ассоциаций уйти далеко от начальной проблемы.
7. Склонны выявлять паттерны, особые случаи (объект, который чем-то отличается от других похожих), связи, обобщать, переходить на более абстрактный уровень.
8. Любят интеллектуальные вызовы, узнавать новое, придумывать необычные и новые способы выполнить работу, достижение целей неочевидным способом, "хаки".
9. С крайне высокой производительностью работают "в потоке", но не всегда могут войти в поток и удержаться в нём. Без потока производительность наоборот низкая.
10. Интроверты, любят быть в одиночестве, отлично себя чувствуют, когда ни с кем не общаются.
Как вам кажется, какой тип личности больше подходит для системного / бизнес-аналитика?
В этом сборнике статей, который сами авторы называют "проектом", ещё есть рассуждения о качестве и Total Quality Management (и его принципиальных отличий от Тейлоризма и выросшего на этой почве KPI и прочих инструментов контроля) , а в качестве одной из вдохновивших их книг они упоминают "Дзен и искусство уход за мотоциклом". Также там есть обоснования разницы в поведении разницей в выработке гормонов (дофамин vs серотонин, например), но тут я совсем не компетентен. На удивление, перевод "Программистского камня" на русский всё ещё доступен.
В первой части авторы предполагают деление людей на "паковщиков" (packers) и "картостроителей" (mappers). Подавляющее большинство людей — "паковщики".
Особенности и стиль рассуждений паковщиков:
1. Запомнить множество инструкций и алгоритмов решения проблем.
2. При встрече с задачей — попробовать вспомнить из своего опыта или спросить у окружающих подходящий алгоритм для решения похожей задачи
3. Предложить решение, аналогичное предыдущему опыту.
4. Следовать алгоритму и убеждать других следовать алгоритму/процедуре.
5. Если люди не следуют процедуре — могут злиться на них и расстраиваться.
6. Ориентированы на процесс.
7. Запутанные задачи (high complexity) вызывают фрустрацию (не находится подходящий алгоритм).
8. Нравятся стандарты, традиции, ритуалы, регулярные, повторяемые действия — так спокойнее. Учатся по книгам и курсам.
9. Склонны к трудоголизму, переработкам.
10. Чаще бывают экстравертами, любят общаться.
Особенности и стиль рассуждений картостроителей:
1. Создать мысленную модель проблемы.
2. Исследовать связи между всеми объектами в проблемной области.
3. Определить требуемый результат и его измеримые показатели.
4. Упростить проблему до минимально разумного уровня (соотнося при этом частные решения с общей картиной и итоговым результатом).
5. Ориентированы на результат. Испытывают трудности с выполнением повторяемых процессов, часто даже бесятся от них. Учатся всему в основном сами, складывая из обрывков знаний общую картину.
6. Генерируют сразу множество идей. Креативны и любопытны. Легко отвлекаются. Могут по цепочке ассоциаций уйти далеко от начальной проблемы.
7. Склонны выявлять паттерны, особые случаи (объект, который чем-то отличается от других похожих), связи, обобщать, переходить на более абстрактный уровень.
8. Любят интеллектуальные вызовы, узнавать новое, придумывать необычные и новые способы выполнить работу, достижение целей неочевидным способом, "хаки".
9. С крайне высокой производительностью работают "в потоке", но не всегда могут войти в поток и удержаться в нём. Без потока производительность наоборот низкая.
10. Интроверты, любят быть в одиночестве, отлично себя чувствуют, когда ни с кем не общаются.
Как вам кажется, какой тип личности больше подходит для системного / бизнес-аналитика?
В этом сборнике статей, который сами авторы называют "проектом", ещё есть рассуждения о качестве и Total Quality Management (и его принципиальных отличий от Тейлоризма и выросшего на этой почве KPI и прочих инструментов контроля) , а в качестве одной из вдохновивших их книг они упоминают "Дзен и искусство уход за мотоциклом". Также там есть обоснования разницы в поведении разницей в выработке гормонов (дофамин vs серотонин, например), но тут я совсем не компетентен. На удивление, перевод "Программистского камня" на русский всё ещё доступен.
👍18🔥1
Классификация людей на паковщиков и картостроителей в "Программистском камне" спекулятивна — по крайней мере, мне не удалось найти каких-либо научных статей, подтверждающих существование такого деления.
Есть одна популярная статья со ссылками на несколько исследований, в которой говорится о разном настрое на обучение: fixed mindset vs growth mindset: те, кто верят, что в основном способности врожденные, и что человеку дано, то не разовьешь; и те, кто убеждены, что способности можно развивать обучением. Соответственно, первые не очень-то стремятся научиться, а больше стараются получить оценку; вторые наоборот — больше заинтересованы в изучении нового — не ради оценок, а из интереса. Также отличается и реакция на трудности и ошибки: первые скорее всё бросят, вторые наоборот обрадуются сложностям (здесь тонкий момент, речь идёт интеллектуальные сложности, а не политические или социальные, например).
Спекулятивных классификаций много: это и MBTI/соционика, и управленческие стили Адизеса, и спиральная динамика. Из научно подтвержденных, со многими исследованиями: "большая пятерка", OCEAN — openness, conscientiousness, extraversion, agreeableness, neuroticism — открытость новому опыту, добросовестность, экстраверсия, доброжелательность, нейротизм.
В многочисленных исследованиях показано, что связи между факторами незначительны, а независимость дополнительных факторов под вопросом.
Внутри каждого фактора есть дополнительные фасеты (например, этот тест показывает их детализацию):
— Нейротизм: тревожность, злость, депрессия, застенчивость (не путать с интроверсией!), неумеренность, уязвимость.
— Экстраверсия: дружелюбность, общительность, напористость, активность, азарт и жизнерадостность.
— Открытость к опыту: воображение, артистические интересы, эмоциональность, авантюризм, интеллект, либерализм.
— Доброжелательность (договороспособность): доверие, мораль, альтруизм, кооперация, скромность, симпатия к окружающим.
— Добросовестность: эффективность, организованность, послушность, стремление к достижениям, самодисциплина, осторожность.
Фасеты в отдельных факторах могут быть противоположно направлены: например, хотя я, в целом, интроверт, у меня высокие показатели активности и азарта. И наоборот — в части добросовестности проседают послушность и самодисциплина.
Отсюда понятно, какие факторы могут быть полезны аналитикам: экстраверсия, чтобы лучше общаться и навязывать свои идеи; договороспособность, чтобы улаживать конфликты и интересы разных сторон; добросовестность, чтобы организовать свою работу; открытость опыту, чтобы придумывать лучшие решения; низкий невротизм, чтобы не мешал действовать. К сожалению, таких людей почти не бывает, либо они очень быстро становятся начальниками.
Собственно, начальники обычно либо организованные экстравертные доброжелательные экспериментаторы, либо деятельные экстравертные недоброжелательные невротики.
У нормальных людей обычно что-то западает: либо экстраверсия (думаем и анализируем отлично, с людьми поддерживаем хорошие отношения, работу свою можем организовать, но выделиться не можем), либо высокий нейротизм (в спокойной среде можем работать классно, но в реальной жизни всегда очень страшно, настолько, что парализует всю деятельность), либо добросовестность (не можем организоваться для выполнения работы, да и фиг с ней). Если проседает открытость и доброжелательность — скорее всего в принципе будет сложно с работать с людьми и со сложными системами.
NB! Я понимаю, что я сейчас залезаю в область, в которой не являюсь экспертом, так что воспринимайте этот пост с осторожностью, проконсультируйтесь со специалистами!
Есть одна популярная статья со ссылками на несколько исследований, в которой говорится о разном настрое на обучение: fixed mindset vs growth mindset: те, кто верят, что в основном способности врожденные, и что человеку дано, то не разовьешь; и те, кто убеждены, что способности можно развивать обучением. Соответственно, первые не очень-то стремятся научиться, а больше стараются получить оценку; вторые наоборот — больше заинтересованы в изучении нового — не ради оценок, а из интереса. Также отличается и реакция на трудности и ошибки: первые скорее всё бросят, вторые наоборот обрадуются сложностям (здесь тонкий момент, речь идёт интеллектуальные сложности, а не политические или социальные, например).
Спекулятивных классификаций много: это и MBTI/соционика, и управленческие стили Адизеса, и спиральная динамика. Из научно подтвержденных, со многими исследованиями: "большая пятерка", OCEAN — openness, conscientiousness, extraversion, agreeableness, neuroticism — открытость новому опыту, добросовестность, экстраверсия, доброжелательность, нейротизм.
В многочисленных исследованиях показано, что связи между факторами незначительны, а независимость дополнительных факторов под вопросом.
Внутри каждого фактора есть дополнительные фасеты (например, этот тест показывает их детализацию):
— Нейротизм: тревожность, злость, депрессия, застенчивость (не путать с интроверсией!), неумеренность, уязвимость.
— Экстраверсия: дружелюбность, общительность, напористость, активность, азарт и жизнерадостность.
— Открытость к опыту: воображение, артистические интересы, эмоциональность, авантюризм, интеллект, либерализм.
— Доброжелательность (договороспособность): доверие, мораль, альтруизм, кооперация, скромность, симпатия к окружающим.
— Добросовестность: эффективность, организованность, послушность, стремление к достижениям, самодисциплина, осторожность.
Фасеты в отдельных факторах могут быть противоположно направлены: например, хотя я, в целом, интроверт, у меня высокие показатели активности и азарта. И наоборот — в части добросовестности проседают послушность и самодисциплина.
Отсюда понятно, какие факторы могут быть полезны аналитикам: экстраверсия, чтобы лучше общаться и навязывать свои идеи; договороспособность, чтобы улаживать конфликты и интересы разных сторон; добросовестность, чтобы организовать свою работу; открытость опыту, чтобы придумывать лучшие решения; низкий невротизм, чтобы не мешал действовать. К сожалению, таких людей почти не бывает, либо они очень быстро становятся начальниками.
Собственно, начальники обычно либо организованные экстравертные доброжелательные экспериментаторы, либо деятельные экстравертные недоброжелательные невротики.
У нормальных людей обычно что-то западает: либо экстраверсия (думаем и анализируем отлично, с людьми поддерживаем хорошие отношения, работу свою можем организовать, но выделиться не можем), либо высокий нейротизм (в спокойной среде можем работать классно, но в реальной жизни всегда очень страшно, настолько, что парализует всю деятельность), либо добросовестность (не можем организоваться для выполнения работы, да и фиг с ней). Если проседает открытость и доброжелательность — скорее всего в принципе будет сложно с работать с людьми и со сложными системами.
NB! Я понимаю, что я сейчас залезаю в область, в которой не являюсь экспертом, так что воспринимайте этот пост с осторожностью, проконсультируйтесь со специалистами!
🔥11👍3