А вот ещё интересный взгляд на роль аналитика (и архитектора) с точки зрения Теории ограничений (TOC) Голдратта. Если у вас разработка является ограничением, логично перед ней ставить звено предобработки, чтобы на вход подавать не сырье, а заготовку. (Помним, что Голдратт в основном анализировал материальные производства).

Как вам кажется, похоже это на работу аналитика? Не постановка задачи, а предобработка, подготовка материала для работы, создание заготовок.

Если с этой точки зрения посмотреть на процесс, можно уточнить у разработки — что именно им полезно в качестве заготовки, а что не нужно (заготовка не должна быть излишне тщательной).

Про Винcтона Ройса, Agile и разработку программного обеспечения.

На заре индустрии разработки программного обеспечения был хороший доклад Винстона Ройса (Winston Royce 1970) про то, как БЫСТРЕЕ выводить программный продукт в эксплуатацию. Так, как основная проблема отрасли это... ОШИБКИ!

Ключевая мысль доклада: Пиши БОЛЬШЕ документов, чтобы БЫСТРЕЕ выводить программный продукт в эксплуатацию.

И тут стоит понимать, что в 1970 году, время от Идеи до осязаемого Результата - минимум 1 неделя, просто потому что технологии такие.

И тут на курсе (который сейчас провожу), при разборе применения Теории Ограничений коллеги заметили что, на самом деле Ройс решал проблему ЗАЩИТЫ ОГРАНИЧЕНИЯ!

То есть:

Пиши много документов для того, чтобы..... ЗАЩИТИТЬ ОГРАНИЧЕНИЕ!
Где Ограничение - машинное время ЭВМ.

Другими словами, это шаг "три" из пяти фокусирующих шагов ТОС.

Отсюда вывод:

Если у вас разработчики - это Ограничение, то им нужны Аналитики и Архитекторы, как "цех заготовки". Чтобы разработчики делали то, что нужно сделать и не делали то, что не нужно делать. И была "полная комплектация" перед началом работы по задаче.

#ответы_на_вопросы #TOC

С наступившим Новым годом! Всем профессиональных успехов и развития в новом году!

Ну а я буду стараться докидывать вам авторского видения нашей отрасли, её задач и проблем, а также интересных материалов.

Вот, например, руководства по стилю 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)

В общем, рекомендую и для справки и тренировки насмотренности — всё-таки, тут зафиксировано решение многих вопросов, с которыми авторы сталкивались в реальной жизни, и для использования в качестве шаблона, если у себя в компании соберетесь вводить единые гайдлайны.

Коллеги приглашают пройти опрос и предложить темы для ИТ-конференций. Мне, как члену Программных комитетов двух конференций, было бы очень интересно — какие направления и темы интересны участникам. Так что, пожалуйста, пройдите опрос! Результаты тоже опубликую.


Друзья, коллеги, всем привет! 🙌
Просим всех принять участие в опросе об интересных для вас темах докладов на IT-конференциях.

Результаты будут доступны для широкого круга. Это поможет и ПК, и спикерам выбирать для вас наиболее актуальные и интересные темы.

Две минуты вашего драгоценного времени сейчас - бесценный вклад 💎 в качество конференций!

Будем благодарны за репосты коллегам-айтишникам любых ролей!

Пройти опрос 🔥 ОПРОС О ТЕМАХ ДОКЛАДОВ 🔥

Разговор про когнитивные стратегии напомнил мне старую (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 серотонин, например), но тут я совсем не компетентен. На удивление, перевод "Программистского камня" на русский всё ещё доступен.

Классификация людей на паковщиков и картостроителей в "Программистском камне" спекулятивна — по крайней мере, мне не удалось найти каких-либо научных статей, подтверждающих существование такого деления.

Есть одна популярная статья со ссылками на несколько исследований, в которой говорится о разном настрое на обучение: fixed mindset vs growth mindset: те, кто верят, что в основном способности врожденные, и что человеку дано, то не разовьешь; и те, кто убеждены, что способности можно развивать обучением. Соответственно, первые не очень-то стремятся научиться, а больше стараются получить оценку; вторые наоборот — больше заинтересованы в изучении нового — не ради оценок, а из интереса. Также отличается и реакция на трудности и ошибки: первые скорее всё бросят, вторые наоборот обрадуются сложностям (здесь тонкий момент, речь идёт интеллектуальные сложности, а не политические или социальные, например).

Спекулятивных классификаций много: это и MBTI/соционика, и управленческие стили Адизеса, и спиральная динамика. Из научно подтвержденных, со многими исследованиями: "большая пятерка", OCEAN — openness, conscientiousness, extraversion, agreeableness, neuroticism — открытость новому опыту, добросовестность, экстраверсия, доброжелательность, нейротизм.
В многочисленных исследованиях показано, что связи между факторами незначительны, а независимость дополнительных факторов под вопросом.

Внутри каждого фактора есть дополнительные фасеты (например, этот тест показывает их детализацию):
— Нейротизм: тревожность, злость, депрессия, застенчивость (не путать с интроверсией!), неумеренность, уязвимость.
— Экстраверсия: дружелюбность, общительность, напористость, активность, азарт и жизнерадостность.
— Открытость к опыту: воображение, артистические интересы, эмоциональность, авантюризм, интеллект, либерализм.
— Доброжелательность (договороспособность): доверие, мораль, альтруизм, кооперация, скромность, симпатия к окружающим.
— Добросовестность: эффективность, организованность, послушность, стремление к достижениям, самодисциплина, осторожность.

Фасеты в отдельных факторах могут быть противоположно направлены: например, хотя я, в целом, интроверт, у меня высокие показатели активности и азарта. И наоборот — в части добросовестности проседают послушность и самодисциплина.

Отсюда понятно, какие факторы могут быть полезны аналитикам: экстраверсия, чтобы лучше общаться и навязывать свои идеи; договороспособность, чтобы улаживать конфликты и интересы разных сторон; добросовестность, чтобы организовать свою работу; открытость опыту, чтобы придумывать лучшие решения; низкий невротизм, чтобы не мешал действовать. К сожалению, таких людей почти не бывает, либо они очень быстро становятся начальниками.

Собственно, начальники обычно либо организованные экстравертные доброжелательные экспериментаторы, либо деятельные экстравертные недоброжелательные невротики.

У нормальных людей обычно что-то западает: либо экстраверсия (думаем и анализируем отлично, с людьми поддерживаем хорошие отношения, работу свою можем организовать, но выделиться не можем), либо высокий нейротизм (в спокойной среде можем работать классно, но в реальной жизни всегда очень страшно, настолько, что парализует всю деятельность), либо добросовестность (не можем организоваться для выполнения работы, да и фиг с ней). Если проседает открытость и доброжелательность — скорее всего в принципе будет сложно с работать с людьми и со сложными системами.

NB! Я понимаю, что я сейчас залезаю в область, в которой не являюсь экспертом, так что воспринимайте этот пост с осторожностью, проконсультируйтесь со специалистами!

Говорят, в немецком языке есть словосочетание "Eierlegende Wollmilchsau", что-то вроде "Яйценоская шерстистая молочная свинья" — конкретно вот этот поросёночек, например, из рекламы Volkswagen.

В общем, я теперь знаю, кто является маскотом аналитиков, если верить описаниям типовых вакансий на эту роль 😹😹😹

Одна из простых и недооцененных техник при разработке интеграций — составление регламента взаимодействия систем.
В примерах, которые можно найти в Интернете, это обычно целый документ, раскрывающий все аспекты интеграции — вплоть до вопросов безопасности, протоколов, форматов запросов и ответов, и описания ошибок.

Но в первом приближении это может быть одна таблица с полями:
|Система-источник|Система-приёмник|Состав данных|Фильтр|Режим обмена|Цель|Комментарий

То есть, нам нужно указать:

1. Откуда куда какие данные попадают. Детализация тут может быть до названия ("Реквизиты карточки документа"), до перечисления полей ("Карточка документа: Идентификатор документа, Наименование документа, Автор документа, Дата создания, Дата последнего изменения, Номер версии") или даже до конкретного формата (JSON/XML, ссылка на схему).

2. Когда они попадают? По расписанию? По событию внутри системы? По запросу пользователя? ("Запрашиваются при выборе документов, измененных с момента последнего обращения к системе", "выгружается вручную сотрудником время от времени по собственной инициативе") — это в поле "Режим обмена". Тут же можно указать, за кем инициатива по старту передачи — "по запросу <наименование системы-приёмника>" / "по инициативе <наименование системы-источника>" (или, может, по инициативе внешнего оркестратора). Можно это вынести в отдельное поле — "стиль взаимодействия": синхронный запрос / асинхронный запрос / подписка.

3. Фильтр — что именно передаётся. Одна запись, соответствующая запросу (когда запрос по ID), со всеми полями, или только с изменившимися? Набор записей, отобранных по определенному условию? ("Документы с датой обновления, большей даты в запросе").

4. Цель — пожалуй, самое важное поле. Для чего интеграция? В рамках какого процесса? Тут можно указать также метрики и даже ROI.

5. В комментарий можно положить всё, что не вошло в другие поля, например — способ аутентификации или требования по обезличиванию, или технологию передачи (по шине, http-запросом, через файловое хранилище, по почте(!)). Если однотипных комментариев наберётся много — можно завести для них отдельную колонку.

Такую таблицу хорошо бы завести для всех интеграций в ИТ-ландшафте — чтобы не разбирать каждый раз, что куда передается и по какому расписанию. Очень помогает при разработке новых интеграций.

Самое интересное при исследовании — внести ручной перенос данных. Вот это прямо источник предложений по оптимизации работы!

Дальше эту простую таблицу можно наращивать и обогащать деталями: ссылками на форматы запросов и ответов, точными названиями адресов, эндпоинтов, топиков; ссылками на спецификации OpenAPI и AsyncAPI, и т.д. Получится описание актуальной архитектуры, и каждый следующий проект будет делать легче, а оформлять в том же формате, но как проект изменений.

Но начать можно с простой инвентаризации взаимодействий. Первый шаг научного подхода — классификация и учёт!

Профессия системного аналитика намного старше, чем у нас обычно принято считать (для меня это тоже стало открытием).
Вероятно, она даже появилась раньше, чем профессия программиста(!).

Системные аналитики выросли из подразделений, занимавшихся измерениями и оптимизацией производственных процессов. В каком-то смысле, их работа была похожа на современных BA — они занимались анализом бизнес-процессов, их оптимизацией и внедрением новых. Только в то время (1940-е) это называлось "процедуры".

Аналитики активно использовали различные технические средства: картотеки, журналы, табуляторы, автоматические машины для учёта всего подряд — в фильме "Новые времена" герой Чарли Чаплина пробивает карточку учета рабочего времени, когда идёт в туалет — а появились такие табели ещё в XIX веке. Кстати, одна из компаний, объединенная под маркой IBM, производила автоматы для учёта рабочего времени и измерения производственных операций.

Когда появились компьютеры, именно этим подразделениям поручили разобраться, как можно эффективно применить эти жужжащие и мигающие шкафы в реальном деле. Программисты были готовы написать всё, что угодно, но связать возможности компьютеров и потребности бизнеса могли не все.

В 1960 годы появился термин "MIS" — Management Information Systems, и привычные нам "data management" и "data processing". Отдали это в смешанные отделы, состоящие из разработчиков и аналитиков. Выявлением потребностей бизнеса и проектированием структур БД занялись системные аналитики.

В 1976 году состоялась конференция CPR:Computers and People Research, полностью посвященная профессии "системный аналитик". Доклады на ней один интересней другого:
"Изменение роли системного аналитика", "Перспективы системных аналитиков", "А кто-нибудь здесь системный аналитик?", "Нет такой вещи, как "системный аналитик", "Учебный курс по системному анализу на видеокассетах", "Улучшенные техники выявления общения с пользователями для выявления проблем", "Пробелы в обучении системных аналитиков", "Требования и навыки системных аналитиков" — жаль, что сборника докладов нет в оцифрованном виде, кажется, там масса интересного.

Судя по аннотациям, почти все сходятся в том, что роль аналитика определена нечетко, двусмысленно; непонятно, что этим словом называется; чем аналитик отличается от программиста; чего от таких специалистов хотят и как вообще их готовить. Хм. Кажется, с 1976 года поменялось не так уж много.

К 90-м годам изменения роли (теперь уже ролей!) аналитика продолжаются. Только по публикациям из Google Scholar:
1990: "Идентификация навыков, требуемых для изменяющейся роли системного аналитика"
1992: "Подход к прогнозированию будущих ролей для системного аналитика"
1996: "Изменение ролей системного аналитика"
1996: "Влияние организационных изменений на роль системного аналитика"
ну и дальше всё в таком же духе — роль всё изменяется и изменяется, в последнее время уже в связи с agile:
2020: "New role of systems analysts in Agile requirements engineering";
где-то с 2018 года упоминаний системных аналитиков становится уже мало.

Интересно, что в 90-х некоторый консенсус образуется вокруг идеи, что системный аналитик является агентом изменений в компании, эта идея встречается во многих публикациях. Впрочем, идея не новая: и изменения, и проблемы, с которыми сталкивается системный аналитик, не претерпели большого изменения с 60-х: "One of the greatest challenges to the systems analyst is the potential conflict between the business’s need for change and its employees’ resistance to change." — и это 1964 год!

"Reactions to the installation of MIS may range from failure to use the output to outright sabotage." - а это 1970.
Будь агентом изменений! Преодолевай сопротивление человеков!

"Operating management, the group that should enjoy most of the system benefits, goes farther than any other group in its resistance, and exhibits all three forms: aggression, projection, and avoidance" — а ничего не изменилось, однако.

Судя по всему, опасаться нам не стоит: как бы не называлась задача оптимизации рабочих процессов и подбора для этого доступных технологий, актуальность её не пропадёт. Не удивлюсь, если в каком-нибудь Древнем Египте или Вавилоне были специалисты по внедрению глиняных досок или учёта на папирусах (в широком смысле, письменность как раз и придумали для учёта и оптимизации работ, так что можно приписать эту заслугу системным аналитикам).

Первая интерактивная база данных с контролем целостности и поддержкой транзакций — это, как известно, двойная запись в бухгалтерии, а Лука Пачоли был одним из первых системных аналитиков. Правда, в XV веке такой профессии ещё не было, и его называли просто математиком.

А вот реклама, за которую точно не стыдно: курс Ветчинкина я проходил сам, и считаю на данный момент лучшим по теме микросервисной архитектуры.

Для аналитиков, проектирующих решения, интеграции или описывающих сервисы, отличный уровень погружения: не слишком технический и не слишком общий. На курсе очень много практики, и, что важно — на каждое задание даётся образец решения от автора, что не всегда встретишь.

И ещё мне очень понравился переход и увязка разных уровней рассмотрения: от высокоуровневых решений и нефункциональных требований, до организации команд вокруг сервисов и быстрых примеров, как какая-то концепция может в коде выглядеть.

В общем, от всей души рекомендую!

Это из книги The Playnoscript Procedure, 1961 год.

А ещё в книге есть оценки зрелости процедур, обзор типовых ошибок и процедуры вокруг процедур (нумерация, индексирование, версионирование, контроль актуальности, пересмотр, изъятие устаревших).

В общем, всё, о чём мы говорим в связи с требованиями, вариантами использования или бизнес-процессами, известно (и забыто) ещё с 50-х годов.

Слов 'systems analyst' там нет, людей в этой роли называют 'Systems Men', "системщики".

Книгу можно взять почитать(!) на часок вот тут: https://archive.org/details/playnoscriptproced0000leli