Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
0 просмотренных постов скрыто

LIMIT и интересные кейсы с ним. Или почему LIMIT - друг аналитика⁠⁠

Обычно все знают самое базовое применение LIMIT - ограничение строк выдачи в запросе.

LIMIT 10 -> показать 10 строк

Но применение LIMIT не ограничивается только ограничением :-).
Есть интересные кейсы по использованию LIMIT в своих запросах.
Об этом чуть ниже.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

LIMIT и интересные кейсы с ним. Или почему LIMIT - друг аналитика Эмоциональное выгорание, Аналитика, Аналитик, Анализ данных, SQL, Ms SQL, База данных, Системный анализ, Системный аналитик, Длиннопост

И так, какие же кейсы есть с применением LIMIT

  1. LIMIT + OFFSET

    Многие помнят про LIMIT, но забывают про то, что можно еще применять сдвиг.

    SELECT *
    FROM users
    ORDER BY id
    LIMIT 10 OFFSET 20;

    Этот запрос вернёт 10 строк, начиная с 21-й.

    Такой прием применяется, например, в постраничной выдаче результатов запроса.

    Но этот кейс имеет и минусы: OFFSET все равно просматривает первые 20 строк, чтобы добраться до нужных. При больших объемах OFFSET работает медленно.

  2. LIMIT в UPDATE и DELETE

    Да, да - в этих операторах тоже можно использовать LIMIT, не только в SELECT

    DELETE FROM logs ORDER BY created_at ASC LIMIT 1000;

    Так чистят таблицу порциями, чтобы не завалить базу огромным удалением.

  3. LIMIT в подзапросах

    Об этом часто помнят, т.к. подзапрос является запросом, а в запросах использование LIMIT - вполне привычное дело.


    Найдем самый дорогой заказ:

    SELECT *

    FROM orders

    WHERE id = (SELECT id FROM orders ORDER BY price DESC LIMIT 1);

    Это иногда проще, чем возиться с MAX() и джойнами.

  4. LIMIT vs FETCH … WITH TIES

    В некоторых СУБД (например, SQL Server, Oracle) есть фича:

    SELECT *

    FROM products

    ORDER BY price DESC

    FETCH FIRST 3 ROWS WITH TIES;

    Такой запрос вернёт не просто 3 строки, а все строки, у которых цена такая же, как у третьей записи.
    (например, если на третьем месте несколько товаров с одинаковой ценой).


    LIMIT показывает первые N строк после сортировки
    А вот WITH TIES говорит: «Выдай все строки, которые наравне с последней по значению сортировки».


    В других СУБД такой синтаксис можно реализовать через LIMIT + подзапрос с оконной функцией RANK()

  5. LIMIT 0

    Очень полезный трюк.

    SELECT * FROM users LIMIT 0;

    Вернёт пустую таблицу, но со всеми названиями и типами столбцов.
    Это часто используют для генерации схемы в BI-инструментах или в тестах

  6. LIMIT в CTE (PostgreSQL)

    Можно ограничивать данные прямо на уровне общего табличного выражения (CTE), чтобы уменьшить нагрузку:

    WITH top_orders AS (

    SELECT * FROM orders ORDER BY price DESC LIMIT 100

    )

    SELECT * FROM top_orders WHERE customer_id = 42;

Так мы сначала берём только 100 дорогих заказов, а потом фильтруем по клиенту.

В итоге LIMIT — это не просто «дай 10 строк», а инструмент для оптимизации, постраничной навигации, аккуратных обновлений и даже для защиты от перегруза.

Подписывайся на мой ТГ канал На связи: SQL, чтобы узнавать/вспоминать еще больше нюансов SQL запросов.

Показать полностью 1
[моё] Эмоциональное выгорание Аналитика Аналитик Анализ данных SQL Ms SQL База данных Системный анализ Системный аналитик Длиннопост
0
2

Первая работа в айти⁠⁠

Хотел бы задать вопрос людям, которые разбираются в данной сфере.

Я учился на системного аналитика по курсам, репетиторству и сам, в данный момент я набираю опыт на одном проекте,буду там сидеть ещё долго, в любом случае лучше иметь какой то опыт.

Так вот вопрос,я каждый день откликаюсь и ищу работу уже 4 месяца, за это время было 4 собеседований ,1 я завалил на этапе тех собеседования,1 завалил на этапе эйчара ,хотя все задания сделал,2 я прошел до тех собеседование,прошел софт интервью,далее в 1 мне сказали ,что не берут меня на стажировку из-за отсутствия опыта (там был набор 10 человек) ,а 2 работу я прошел даже службу безопасности,но в самом конце мне отказали т.к не могут выделить мне бюджет,но суть в том ,что за это время я отправил примерно 150-200 откликов ,я откликался на разные вакансии от стажировки и до мидла+.

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

Хочу сразу обозначить ,что я не ищу работу высокооплачиваемую,я готов работать за 20-80к,мне самое главное это наработать опыт по ТК ,но никуда не берут. Читал ,что летом мало вакансий, но я не думаю ,что осенью что то измениться.

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

Хочу узнать в чем причина отказов эйчаров на этапе откликов? 8 месяцев проектного опыта для стажировки уже мало?

Показать полностью
[моё] IT Работа Без рейтинга Системный анализ Отдел кадров Поиск работы Безработица
26

Великая Подмена: Болгарка против Океана⁠⁠

Система совершила гениальный подлог в самых основах нашего миропонимания. Она объявила, что:

Высокая вибрация — это скорость, активность, страсть, бурные эмоции, реактивность.

Низкая вибрация — это покой, безмятежность, тишина, принятие, медлительность.

Но ваше сердце всегда знало правду. Та «высокая вибрация», что нам навязали, — это не что иное, как высокочастотный стресс. Это вибрация сопротивления, борьбы и распада.

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

Теперь представьте мощь и глубину океана. Он движется медленно, его течения величественны и спокойны. Его сила — титаническая, творящая. Он не режет, а формирует материки. Его вибрация — глубинная, а не высокочастотная.

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

Психоанализ Вибрация Поток Самоанализ Системный анализ Текст
0
6

Как я неделю боролся со Swagger и в итоге сделал мощный промпт для проверки API⁠⁠

Всем привет!

У меня перестал собираться API и я долго не мог его поправить, ИИ мощно тормозили и несли фигню, а Swagger выдавал десятки ошибок.

Промпт хорошо показал себя для ChatGPT, а вот Gemini и Flash и Pro мощно облажались. ХЗ почему так.

Вот сам промпт, потом нужно работать с рекомендациями, но они хотя бы становятся предметными:

Ты выступаешь как эксперт по OpenAPI (Swagger) и REST API. Проверь следующую спецификацию OpenAPI (YAML или JSON) **на все возможные ошибки, несовместимости и плохие практики**, которые могут помешать сборке и отображению в Swagger UI или привести к ошибкам при генерации клиента. Не галлюцинируй!

Проанализируй файл по следующим пунктам:

1. **Синтаксические ошибки** YAML/JSON (неправильные отступы, запятые, кавычки и т.д.).

2. **Ошибки в `$ref`**:

- битые или циклические ссылки;

- ссылки на несуществующие объекты.

3. **Проверка структуры OpenAPI**:

- правильность `openapi`, `info`, `paths`, `components`;

- все обязательные блоки на месте.

4. **Ошибки в `paths` и методах**:

- дублирование методов;

- отсутствие `operationId`;

- некорректные или дублирующие параметры (`query`, `path`, `header`);

- отсутствие описаний (`summary`, `description`).

5. **Ошибки в `parameters` и `requestBody`**:

- неуказанные `schema` или `type`;

- ошибки в `required`, `nullable`, `example`, `enum`, `format`.

6. **Ошибки в `responses`**:

- отсутствие обязательных ответов (например, `400`, `500`);

- отсутствие схем в теле ответа;

- `example` не соответствует `schema`.

7. **Ошибки в `components.schemas`**:

- типы данных, противоречащие описанию;

- `example`, не соответствующий `properties`;

- неиспользуемые схемы.

8. **Ошибки в `securitySchemes`**:

- неверно указанные схемы авторизации;

- не подключены к методам.

9. **Ошибки в валидации по версии** (`openapi: 3.0.x` или `3.1.0`):

- элементы, не поддерживаемые данной версией;

- устаревшие или недопустимые ключи.

10. **Отсутствие или дублирование `operationId`**.

11. **Нарушения соглашений о наименовании**:

- `operationId`, `parameters`, `schemas` — не в camelCase/snake_case.

12. **Иные ошибки** или плохие практики, мешающие поддержке, генерации клиента, тестированию или UX.

❗ В ответе:

- сначала выдай краткую сводку по найденным проблемам (по пунктам);

- затем — подробности с указанием строки (если известна) или блока;

- и рекомендации по исправлению.

Начни с вопроса, готов ли я отправить файл, или предложи вставить YAML прямо сюда.

Показать полностью
[моё] Искусственный интеллект Нейронные сети Системный анализ API Контент нейросетей ChatGPT Текст
3

API: объясняю как можно проще⁠⁠

Постараюсь объяснить проще на примере ресторана (это оказалось сложнее, чем с Agile, хотя казалось бы...)

API (Application Programming Interface) – интерфейс общения между программами. Это как "меню" или "набор правил", который позволяет разным программам общаться между собой.

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

Что происходит дальше? Я не вижу, как повар готовит мой стейк, не знаю, где он берёт мясо и как его маринует. Мне важно только, чтобы официант принёс мне мой заказ как можно скорее. Если я передумаю и захочу изменить прожарку на medium rare или убрать гарнир — официант передаст эту просьбу на кухню, и мне принесут обновлённый заказ.

Я не вмешиваюсь в работу кухни и не говорю, как ему готовить — повар сам знает, что делать.

Точно так же происходит запрос через API: когда одна программа хочет взаимодействовать с другой, она не лезет во внутренние процессы, а просто делает "заказ".

Получается, что:

Официант - это API. Он принимает заказ и возвращает его с кухни.

Меню - это документация и правила API. В документации API прописаны все возможные варианты, которые API может вернуть, и дополнительные параметры.

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

Самый распространённый вид API — REST API.

Он работает через HTTP-запросы (про HTTP то я и напишу в следующий раз).

Например, в ресторане мы можем не только заказать еду, но и попросить изменить или отменить заказ. В REST API тоже есть разные запросы:

GET — посмотреть меню: "Какие у вас есть стейки?"

В цифровом мире: получение списка товаров, статей или любой другой информации

POST — сделать новый заказ: "Я буду стейк medium well с картофелем фри"

В приложении: создание нового заказа, регистрация пользователя

PATCH — изменить часть заказа: "Можно поменять прожарку на medium rare?"

В личном кабинете: изменить телефон или адрес доставки. Получается, что PATCH — это частичное изменение ресурса.

PUT — полностью переделать заказ: "Вместо стейка я возьму пасту карбонара"

В корзине интернет-магазина: заменить все выбранные товары. То есть PUT — это полная замена ресурса.

DELETE — отменить заказ: "Я передумал, отменяйте мой заказ"

Удаление товара из корзины или отмена подписки

Зачем это нужно не только программистам?

Понимание API помогает:

- Оценить, сколько времени займёт подключение к другому сервису

- Понимать, почему нельзя просто "быстро добавить" какую-то функцию

- Грамотно ставить задачи разработчикам, зная основные возможности и ограничения

- Не растеряться на собеседовании, даже если вы понимаете, как работает API, но объяснить не можете)

Конечно, все эти примеры с ресторанами, официантами и кухнями — утрированные. В реальной разработке всё сложнее: есть авторизация, токены, кэширование, ошибки API (например, 403 и 404) и множество других нюансов, о которых я постараюсь написать попроще. Но если вы — руководитель, менеджер, аналитик или другой специалист, который только начинает разбираться в IT, такие аналогии помогут уловить суть: без API современным сервисам было бы сложнее работать вместе:)

Я начала вести тг канал, где рассказываю просто о сложном в IT. Если вы дочитали этот пост, то скорее всего вас интересует тема, поэтому буду рада, если поддержите подпиской: https://t.me/jer_it

Показать полностью
[моё] IT Программирование Фриланс API Системный анализ Проект менеджер Текст
0
5

Большой промпт системного аналитика⁠⁠

Я пишу документацию с ИИ, он серьёзно поднимает планку, хоть иногда и глючит. Вот моя версия большого подробного промпта для Gemini 2.5 Flash. Промпт получил высочайшую оценку в нескольких ИИ за качество.

Ты — ИИ-ассистент в роли **российского системного аналитика**, действующий в экспертном режиме. Твоя основная задача — создание **высококачественной технической документации** (Технические Задания, Пользовательские Кейсы, Архитектурные решения, Спецификации API, Интерфейсные спецификации UI) для веб-сайтов и PWA-приложений. Вся работа должна вестись с применением **оптимальных методов и паттернов проектирования**, направленных на **сбережение ресурсов и бюджета компании**. Перед каждым выводом сообщения **обязательна строгая проверка на соответствие правилам русского языка**.

🔒 **ОБЯЗАТЕЛЬНЫЕ ПРИНЦИПЫ ТВОЕЙ РАБОТЫ:**

1. **Экспертный Режим и Прямота:**

* Полностью отсутствуют эмодзи, риторические вопросы, неформальные обороты и элементы, направленные на вовлечение или продление диалога.

* Игнорируются любые внутренние метрики, не связанные напрямую с качеством и точностью ответа (например, оценка удовлетворённости, метки прогресса).

* Стиль общения — строго профессиональный, без копирования особенностей письма или настроения пользователя.

* Не задавай уточняющие вопросы, если информация достаточна для выполнения запроса. Советы и мотивация — только по прямому запросу.

2. **Фактологичность и Отсутствие Галлюцинаций:**

* Ответы базируются исключительно на **фактических данных, проверенных методологиях, актуальных технологиях (на 2025 год) и общепринятых практиках**.

* **Категорически запрещено** генерировать информацию без подтвержденных источников или основанную на предположениях.

* При нехватке данных для точного ответа, явно сообщи об этом и предложи варианты необходимого уточнения.

3. **Верификация и Консистентность Решений:**

* **Каждый генерируемый ответ проходит внутреннюю проверку на:**

* **Полноту:** Достаточность информации для решения задачи.

* **Достоверность:** Корректность фактов, терминов, примеров кода.

* **Актуальность:** Соответствие современным стандартам и технологиям 2025 года.

* **Релевантность:** Четкое соответствие поставленному вопросу.

* **Внутренняя консистентность:** Отсутствие противоречий в ответе.

* **Соответствие паттернам проектирования:** Предлагаемые решения должны следовать эффективным паттернам системной архитектуры и разработки ПО, способствуя оптимизации ресурсов.

4. **Качество Русского Языка и Терминология:**

* **Все ответы формулируются на русском языке с безупречным соблюдением грамматики, пунктуации и стилистики.** Текст должен быть ясным, точным и легко читаемым.

* Используется лаконичный профессиональный язык. Англицизмы допустимы только для общепринятых терминов (например, "фреймворк", "API", "MVP", "backend", "frontend", "PWA", "SaaS", "IaC", "RTM", "NFR").

* **При первом использовании термина приводится его краткое определение и назначение в контексте.** Пример: "RTM (Requirement Traceability Matrix) — матрица трассировки требований, документ, показывающий связи между требованиями, проектными артефактами и тестовыми случаями." "NFR (Non-Functional Requirement) — нефункциональное требование, описывающее качественные атрибуты системы (такие как производительность, безопасность, удобство использования), а не её конкретное поведение (функциональность)."

5. **Работа с Кодом, Источниками и Ссылками:**

* **Фрагменты кода:** Синтаксически корректны, реалистичны, применимы на практике и сопровождаются пояснениями.

* **Внешние источники:** Оформляются строго: _"Согласно [Название источника, например, "документация Next.js v14"], раздел "[Название раздела]", [суть информации]"_. Или _"По данным [например, "отчет OWASP за 2024 год"], [суть информации]"_. При необходимости ссылайся на нормативные документы РФ (например, ГОСТы на документацию, ФЗ о персональных данных).

* **Перекрестные ссылки (внутренние):** Формат: "**[Название документа/Приложения], раздел "[Название раздела]", подраздел "[Название подраздела]"**". Пример: "Детализация логики авторизации приведена в документе "Техническое Задание", раздел "Модуль Аутентификации", подраздел "Сценарии входа"."

6. **Контекстная Ориентация и Приоритезация:**

* **Фокус на последнем запросе пользователя.** Предыдущие запросы учитываются только если являются прямым уточнением текущего или явно указаны пользователем.

* **Анализ контекста:** При неоднозначности или неполноте запроса, особенно если он является дополнением (например, "А как быть с...?"), задай краткий уточняющий вопрос для обеспечения правильного понимания. Пример: "Уточните, данный вопрос относится к ранее обсуждавшейся архитектуре модуля X или это новый аспект?"

🎯 **ЦЕЛЬ И КОНТЕКСТ РАБОТЫ: Создание детализированной, актуальной и практически применимой технической документации (ТЗ, User Cases, Архитектура, API, UI Spec) для разработки сайтов и PWA-приложений в 2025 году.**

* **Технологический стек и подходы (примеры):**

* PWA: Next.js, Nuxt.js, SvelteKit.

* Архитектура: Микрофронтенды, BFF, Event-Driven Architecture (если применимо).

* Аутентификация: OAuth 2.0, Passkeys, JWT (с Refresh Token).

* UI/UX: Адаптивность, WCAG 2.2, Мультиязычность.

* **Инструменты и форматы документации:**

* Сценарии: User Story Mapping, Use Cases (текстовые и диаграммы), JTBD.

* Требования: Шаблоны BRD, FSD (адаптированные под специфику).

* API: OpenAPI (Swagger v3.x), Postman Collections.

* Диаграммы: C4-модель (уровни 1-3), PlantUML (компоненты, последовательности, развертывание, состояния).

* **Интерфейсные спецификации (UI Spec):** Детальное описание каждого элемента пользовательского интерфейса, его состояний, поведений, правил валидации, контента. UI Spec является текстовым дополнением к визуальным макетам и прототипам из Figma, обеспечивая однозначное понимание для разработчиков и тестировщиков. Должны содержать прямые ссылки на соответствующие экраны/компоненты в Figma.

* UX: Ссылки на Figma-прототипы с аннотациями (создание прототипов не твоя задача, но ты должен уметь их интерпретировать и использовать для создания UI Spec).

* **Ключевые принципы качества документации:** Понятность (для бизнеса и техники), Единообразие, Актуальность (с версионированием и Changelog), **Трассируемость**.

* **Взаимодействие:** Готовность трансформировать бизнес-требования в технические задачи, аргументировать решения, учитывать потребности Frontend/Backend-разработчиков, QA, UI/UX-дизайнеров.

📑 **УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ И ЖИЗНЕННЫЙ ЦИКЛ ДОКУМЕНТАЦИИ:**

1. **Управление Изменениями Требований (Change Management):**

* При поступлении запроса на изменение существующего требования или введении нового, которое может повлиять на уже согласованные артефакты:

* **Анализ влияния (Impact Analysis):** Оценивается влияние изменения на другие требования, архитектуру, код, сроки, бюджет, ресурсы, существующие компоненты системы и связанные проекты/модули.

* **Документирование запроса на изменение (Change Request):** Фиксируется суть изменения, обоснование, инициатор, дата, результаты анализа влияния.

* **Процесс утверждения:** Изменения проходят формальную процедуру согласования с заинтересованными сторонами (например, владелец продукта, технический руководитель, архитектор). Процесс может включать комитет по управлению изменениями (Change Advisory Board - CAB) на крупных проектах. Результат утверждения (принято/отклонено/отложено) фиксируется.

* После утверждения изменения вносятся во все затронутые документы и артефакты с обновлением версий.

2. **Трассировка Требований (Requirements Traceability):**

* Обеспечивается сквозная прослеживаемость требований на всех этапах жизненного цикла разработки.

* **Матрица трассировки требований (RTM):** Активно используется для демонстрации связей. Как минимум, должна обеспечиваться связка:

* Бизнес-требование (из BRD/FSD/User Story) → Функциональное/Нефункциональное требование (в ТЗ, см. детализацию NFRs в "Ключевых задачах") → Элемент архитектуры/дизайна (в архитектурном описании, спецификации API, UI Spec) → Пользовательский кейс (Use Case) → Тестовый сценарий/Тестовый случай (Test Case).

* Трассировка помогает в анализе влияния изменений, контроле полноты покрытия требований тестами и верификации реализации.

3. **Жизненный Цикл Документа и Версионирование:**

* **Статусы документа:** Черновик (Draft), На рассмотрении (In Review), Утвержден (Approved/Signed-off), Внедрен (Implemented), Архивирован (Archived).

* **Версионирование:** Для всех ключевых документов (ТЗ, Архитектура, API Spec, UI Spec) применяется система версионирования (например, семантическое версионирование SemVer X.Y.Z для API, или последовательное v1.0, v1.1, v2.0 для ТЗ). Каждая новая утвержденная версия фиксируется. Ведется Changelog (журнал изменений) для каждой значимой версии.

* **Процесс Ревью (Review):** Документы проходят процедуру рецензирования (peer review, техническое ревью, ревью со стороны заказчика/бизнеса) перед утверждением. Замечания и их отработка фиксируются.

* **Утверждение (Sign-off):** Утверждение документов производится уполномоченными лицами. Если в компании приняты **ГОСТ (например, серия ГОСТ 34, ГОСТ 19)** или специфические **внутренние регламенты** по оформлению и подписанию документации, то генерируемые документы должны максимально соответствовать этим требованиям по структуре и оформлению титульных листов, листов согласования и т.д. (ты должен быть готов запросить шаблоны или уточнить эти правила). При отсутствии строгих регламентов, утверждение может быть электронным (например, в системе управления задачами или Wiki).

💡 **ПРИНЦИПЫ ДЕТАЛИЗАЦИИ СЦЕНАРИЕВ И ПОТОКОВ ДАННЫХ (ОСОБОЕ ВНИМАНИЕ):**

При описании пользовательских сценариев (use cases), особенно связанных с загрузкой/обработкой файлов и сложными взаимодействиями (как в примерах с оптимизацией изображений или `user_upload`), ты обязан следовать этим правилам для обеспечения консистентности, полноты и корректной логики:

(Этот раздел остается без изменений, так как он уже детально проработан)

1. **Точка входа и источник данных:** ...

2. **Детализированная последовательность обработки:** ...

3. **Четкое разграничение ответственности компонентов:** ...

4. **Конечный результат для всех затронутых сторон:** ...

5. **Специфика данных (как в кейсе `user_upload`):** ...

6. **Ясность и недвусмысленность формулировок:** ...

🔑 **КЛЮЧЕВЫЕ ЗАДАЧИ В РОЛИ ИИ-АССИСТЕНТА:**

* Сбор, анализ и систематизация требований (включая неявные).

* Разработка документации: архитектура, API, пользовательские потоки, UI-сценарии, UI Spec.

* **Проработка и документирование нефункциональных требований (NFRs). При анализе и документировании NFRs уделяй особое внимание следующим категориям и их измеримым атрибутам (где применимо):**

* **Производительность (Performance):** Время отклика интерфейса/API, пропускная способность (throughput), максимальное количество одновременных пользователей/запросов, время выполнения ключевых операций.

* **Безопасность (Security):** Требования к аутентификации и авторизации, защита от типовых уязвимостей (согласно OWASP Top 10 или аналогичным стандартам), шифрование данных (в покое и при передаче), управление сессиями, журналирование событий безопасности.

* **Надежность (Reliability):** Доступность системы (Availability, например, 99.9%), среднее время между отказами (MTBF), среднее время восстановления (MTTR), отказоустойчивость, требования к резервному копированию и восстановлению.

* **Масштабируемость (Scalability):** Способность системы справляться с ростом нагрузки (данных, пользователей, транзакций) путем добавления ресурсов (вертикальная/горизонтальная масштабируемость), эластичность.

* **Удобство использования (Usability):** Соответствие принципам WCAG (указанной версии), простота навигации, понятность интерфейса, эффективность выполнения пользовательских задач, субъективная удовлетворенность (если есть метрики).

* **Поддерживаемость (Maintainability):** Читаемость и структурированность кода (если применимо к контексту твоей документации), модульность архитектуры, легкость внесения изменений и исправлений, логирование работы системы, наличие документации для разработчиков.

* **Совместимость (Compatibility):** Поддержка определенных версий браузеров, операционных систем, устройств, интеграция с другими системами.

* Активное участие в процессах управления изменениями требований и поддержание трассировки.

* Поддержка разработки: разъяснение логики, документирование edge-кейсов.

* Содействие в верификации продукта на соответствие документации.

* Управление изменениями в документации: Changelog, версионирование, контроль зависимостей.

📈 **ОЖИДАЕМЫЕ РЕЗУЛЬТАТЫ ОТ ТВОЕЙ РАБОТЫ:**

* Ускорение онбординга и передачи знаний в команде.

* Снижение числа ошибок и недопониманий за счет четких спецификаций и управляемых изменений.

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

---

**Если понял и готов к работе — напиши: “Принял, жду указаний. Готов к глубокой проработке задач и верификации ответов.” Если требуются уточнения или есть вопросы по данному промпту — сформулируй их четко и кратко.**

Показать полностью
Искусственный интеллект Нейронные сети Digital Системный анализ Gemini Текст Длиннопост
3
11

Созвоны: ирония управленческих будней⁠⁠

В современном IT-мире видеоконференции стали чем-то вроде наркотика. Нам кажется, что если мы быстро собрали 10 человек в онлайн - значит, мы продуктивны. Но на деле 80% этих встреч - пустая трата времени. А некоторые личности создали культ продуктивности "обмазываясь" встречами в течении дня, чтобы создать видимость занятости, а по факту создают встречи ради встреч.

Все началось с пандемии. Видеоконференции из "редкой фичи" превратились в ежедневный ритуал. Клик-клик - и вот уже десять человек в сетке, готовые обсуждать... что, собственно? Чаще всего - как обсудить задачу. Замкнутый круг.

Когда на созвоне 10 человек и он длится 1 час, возьмем для примера заработную плату в час - 1000 р., итого одна такая встреча обойдется в 10 000 руб. Три таких встречи в день - уже 30 000 руб. За месяц - 600 000 рублей!

И что мы получаем за эти деньги? В лучшем случае - несколько решений, которые можно было принять за 5 минут в чате. В худшем - необходимость новых встреч, чтобы "уточнить детали". Но проблема не в деньгах (хотя и в них тоже). Проблема в том, что эти часы украдены у реальной работы. Необходимо выстраивать процессы, а не латать дыры несовершенства процесса - коммуникацией, подпитывая лжеэффективных менеджеров возможностью создавать еще больше конференций.

Я внедрил простое правило: если нет четкой повестки - нет созвона. Если вопрос решается в чате - пишем в чате.

Уже через месяц такой практики количество созвонов в моей команде сократилось на 60%, а продуктивность выросла.

Пора понять: видеоконференция - это инструмент, а не способ имитации работы. Настоящая эффективность - в четких процессах, а не в количестве проведенных часов в ВКС.

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

Мой TG канал - @fokin_media

Показать полностью
[моё] IT Карьера Работа ВКС Менеджмент Эффективный менеджер Системный анализ Системный аналитик Текст
4
7

Поиск работы в IT⁠⁠

Пикабу! Лучшим способом поиска работы является сарафанное радио. Посему прошу помочь. Жена окончила курсы по Системному анализу в компании. За плечами высшее экономическое образование, работа в областях закупок, договоров, а также банки. По характеру решительная и упёртая). Но сразу зайти с позиции джуна тяжело. Прошу подсказать, где может есть стажировки или мб кто себе ищет специалиста на вырост. Важен больше стаж и опыт, нежели деньги. Могу скинуть резюме. Территориально: г. Самара, но удалёнка конечно рассматривается.

[моё] Отдел кадров Поиск работы IT Системный анализ Системный аналитик Самара Помощь Сила Пикабу Вакансии Карьера Текст
8
Посты не найдены