Заказчик не знает, что такое НФТ. И не должен
"Какие у вас нефункциональные требования?" – спрашиваю на встрече.
Заказчик смотрит как на инопланетянина.
Он не мыслит категориями "производительность 1000 RPS" или "доступность 99.9%". Он вообще не понимает, чего я от него хочу.
Зато он точно знает, как его бизнес работает. И вывести из этого НФТ – задача аналитика.
ФТ vs НФТ – в чём разница
Функциональные требования – это ЧТО система делает.
Нефункциональные – это КАК она это делает.
Основные типы НФТ
🔸 Производительность – сколько запросов в секунду, время отклика
🔸 Доступность – какой процент времени система работает (SLA 99.9% = 8 часов простоя в год)
🔸 Масштабируемость – что будет при росте нагрузки в N раз
🔸 Безопасность – разграничение доступа, шифрование, аудит
🔸 Надёжность – что происходит при сбоях, как восстанавливаемся
🔸 Совместимость – с какими браузерами, ОС, устройствами работает
🔸 Локализация – языки, часовые пояса, форматы дат
Проблема в том, что заказчик не думает этими категориями.
Кейс с собеседования
На интервью в Леруа Мерлен дали задачку: собрать функциональные и нефункциональные требования для приложения, которое показывает сотрудникам – сейчас день или ночь.
Звучит как шутка. Но попробуй вытащить из этого НФТ.
Я начал спрашивать:
🔸 Сколько человек работает в компании?
→ 20 000 сотрудников → понимаю нагрузку
🔸 Есть геораспределение? Часовые пояса важны?
→ Магазины по всей стране → нужна логика определения времени по локации
🔸 Как будут использовать и зачем это вообще нужно?
→ "По приколу, сидят в тёмном помещении, не знают – идти домой или нет" → Низкая критичность, не нужен SLA 99.99%
🔸 На каких устройствах?
→ Личные телефоны → кроссплатформенность, разные версии ОС
Из ответа про использование понял ещё кое-что: пики нагрузки будут в начале рабочего дня и под конец. Все одновременно проверяют – пора домой или нет.
Что я упустил
Не спросил: "Нужно ли собирать статистику? Логировать действия? Синхронизировать что-то между пользователями?"
Если нет – день/ночь можно определять вообще без сервера, просто по времени на телефоне. И тогда:
🔸 Нет бэкенда → нет нагрузки
🔸 Нет интернета → работает офлайн
🔸 Нет синхронизации → нет проблем с часовыми поясами
Один вопрос мог изменить всю архитектуру.
Вопросы, которые вытаскивают НФТ
Заказчик не скажет "мне нужна доступность 99.9%". Но ответит на вопросы:
🔸 "Что случится, если система не будет работать час? День?"
→ Критичность, требования к доступности
🔸 "Сколько человек будет пользоваться одновременно?"
→ Нагрузка, производительность
🔸 "Откуда будут заходить – офис, дом, в дороге?"
→ Мобильность, офлайн-режим
🔸 "Данные одинаковые для всех или у каждого свои?"
→ Архитектура, где хранить логику
🔸 "Что будет через год – пользователей станет больше?"
→ Масштабируемость
🔸 "Кто не должен видеть эти данные?"
→ Безопасность, разграничение доступа
Выводы для аналитика
🔸 Не спрашивай про НФТ напрямую – спрашивай про сценарии использования
🔸 Из контекста бизнеса рождаются конкретные требования
🔸 Один вопрос про архитектуру может перевернуть всё решение
🔸 Упущенное ограничение больнее упущенной фичи – фичу добавишь, а переделывать архитектуру дорого
С функционалом, надеюсь, уже все справляются. А вот мыслить ограничениями – это то, что отличает хорошего специалиста.
А как вы вытаскиваете НФТ из заказчиков? Есть любимые вопросы?
@analyst_exe
"Какие у вас нефункциональные требования?" – спрашиваю на встрече.
Заказчик смотрит как на инопланетянина.
Он не мыслит категориями "производительность 1000 RPS" или "доступность 99.9%". Он вообще не понимает, чего я от него хочу.
Зато он точно знает, как его бизнес работает. И вывести из этого НФТ – задача аналитика.
ФТ vs НФТ – в чём разница
Функциональные требования – это ЧТО система делает.
Пользователь может авторизоваться
Нефункциональные – это КАК она это делает.
Авторизация занимает не больше 2 секунд
Основные типы НФТ
🔸 Производительность – сколько запросов в секунду, время отклика
🔸 Доступность – какой процент времени система работает (SLA 99.9% = 8 часов простоя в год)
🔸 Масштабируемость – что будет при росте нагрузки в N раз
🔸 Безопасность – разграничение доступа, шифрование, аудит
🔸 Надёжность – что происходит при сбоях, как восстанавливаемся
🔸 Совместимость – с какими браузерами, ОС, устройствами работает
🔸 Локализация – языки, часовые пояса, форматы дат
Проблема в том, что заказчик не думает этими категориями.
Кейс с собеседования
На интервью в Леруа Мерлен дали задачку: собрать функциональные и нефункциональные требования для приложения, которое показывает сотрудникам – сейчас день или ночь.
Звучит как шутка. Но попробуй вытащить из этого НФТ.
Я начал спрашивать:
🔸 Сколько человек работает в компании?
→ 20 000 сотрудников → понимаю нагрузку
🔸 Есть геораспределение? Часовые пояса важны?
→ Магазины по всей стране → нужна логика определения времени по локации
🔸 Как будут использовать и зачем это вообще нужно?
→ "По приколу, сидят в тёмном помещении, не знают – идти домой или нет" → Низкая критичность, не нужен SLA 99.99%
🔸 На каких устройствах?
→ Личные телефоны → кроссплатформенность, разные версии ОС
Из ответа про использование понял ещё кое-что: пики нагрузки будут в начале рабочего дня и под конец. Все одновременно проверяют – пора домой или нет.
Что я упустил
Не спросил: "Нужно ли собирать статистику? Логировать действия? Синхронизировать что-то между пользователями?"
Если нет – день/ночь можно определять вообще без сервера, просто по времени на телефоне. И тогда:
🔸 Нет бэкенда → нет нагрузки
🔸 Нет интернета → работает офлайн
🔸 Нет синхронизации → нет проблем с часовыми поясами
Один вопрос мог изменить всю архитектуру.
Вопросы, которые вытаскивают НФТ
Заказчик не скажет "мне нужна доступность 99.9%". Но ответит на вопросы:
🔸 "Что случится, если система не будет работать час? День?"
→ Критичность, требования к доступности
🔸 "Сколько человек будет пользоваться одновременно?"
→ Нагрузка, производительность
🔸 "Откуда будут заходить – офис, дом, в дороге?"
→ Мобильность, офлайн-режим
🔸 "Данные одинаковые для всех или у каждого свои?"
→ Архитектура, где хранить логику
🔸 "Что будет через год – пользователей станет больше?"
→ Масштабируемость
🔸 "Кто не должен видеть эти данные?"
→ Безопасность, разграничение доступа
Выводы для аналитика
🔸 Не спрашивай про НФТ напрямую – спрашивай про сценарии использования
🔸 Из контекста бизнеса рождаются конкретные требования
🔸 Один вопрос про архитектуру может перевернуть всё решение
🔸 Упущенное ограничение больнее упущенной фичи – фичу добавишь, а переделывать архитектуру дорого
С функционалом, надеюсь, уже все справляются. А вот мыслить ограничениями – это то, что отличает хорошего специалиста.
А как вы вытаскиваете НФТ из заказчиков? Есть любимые вопросы?
@analyst_exe
❤7🔥7
Коллеги, субботний мэм, честно украденный, все как вы любите
Если кто-то из вас работает сегодня - "фу, брось бяку"
@analyst_exe
Если кто-то из вас работает сегодня - "фу, брось бяку"
@analyst_exe
😁13❤1
Как работают пароли
Ни один нормальный сервис не хранит твой
Вместо пароля хранят его "отпечаток" – хеш.
Хеш-функция превращает любой текст в строку фиксированной длины. Главное свойство – односторонность: из хеша нельзя получить исходный пароль.
Любое изменение данных → новая строка
Хеш активно используется для проверки целостности данных, например, после скачивания: вычисляется хеш скачанного файла и сравнивается с хешем файла на сервере. Если хеши совпадают – файл скачан без ошибок, содержимое не изменилось.
Сколько стоит взломать
MD5 – устарел. Видеокарта перебирает ~40 млрд хешей/сек. Пароль из 8 символов подберет за считанные минуты.
bcrypt – надёжный, проверенный временем. Встроенное замедление: ~30 тыс хешей/сек. Разница с MD5 – в миллион раз.
Argon2 – современный стандарт. Сильно нагружает память, чем ломает перебор на GPU.
Медленный алгоритм – это фича. Пользователь ждёт 100мс и не замечает. Злоумышленник при переборе миллиарда вариантов ждёт годы.
Но есть НЮАНС
Квантовые компьютеры. Да, они сломают все шифрование.
А потом мир перейдет на постквантовое шифрование. В общем, пока живем спокойно.
Зачем нужна соль
Если у тысячи юзеров пароль
Соль – случайная строка, уникальная для каждого пользователя:
Теперь каждый пароль нужно подбирать отдельно.
Как это работает
Регистрация:
Пароль прилетает по HTTPS в теле POST-запроса (не в URL – там логируется). Сервер генерирует соль, считает хеш, сохраняет в базу данных. Сам пароль не хранится.
Вход:
Сервер достаёт соль и хеш из базы данных, считает хеш введённого пароля с той же солью, сравнивает. Совпало – пускает.
Диаграммы процессов приложу в комментах.
О перце
Когда нужна более сильная защита, используется перец – общий секретный ключ, хранящийся отдельно от базы данных. Он добавляется к паролю и соли перед хешированием:
Даже если злоумышленник получит базу с хешами и солью, без перца он не сможет правильно вычислять хеши для проверки догадок. Подобрать пароль будет невозможно.
Выводы
🔸 Пароли не хранятся в открытом виде – только хеши
🔸 Соль препятствует массовому подбору
🔸 Перец защищает хеши при утечке БД
🔸 Медленный алгоритм – не баг, а метод защиты
И никакой магии. Когда пишешь требования к аутентификации – за фразой "пользователь может войти" стоит конкретная инженерная логика.
А вы знали, как это работает?
@analyst_exe
Ни один нормальный сервис не хранит твой
qwerty123 в открытом виде. Иначе одна утечка – и все пароли у злоумышленника.Вместо пароля хранят его "отпечаток" – хеш.
Хеш-функция превращает любой текст в строку фиксированной длины. Главное свойство – односторонность: из хеша нельзя получить исходный пароль.
password123 → ef92b778...password124 → a1b2c17a...Любое изменение данных → новая строка
Хеш активно используется для проверки целостности данных, например, после скачивания: вычисляется хеш скачанного файла и сравнивается с хешем файла на сервере. Если хеши совпадают – файл скачан без ошибок, содержимое не изменилось.
Сколько стоит взломать
MD5 – устарел. Видеокарта перебирает ~40 млрд хешей/сек. Пароль из 8 символов подберет за считанные минуты.
bcrypt – надёжный, проверенный временем. Встроенное замедление: ~30 тыс хешей/сек. Разница с MD5 – в миллион раз.
Argon2 – современный стандарт. Сильно нагружает память, чем ломает перебор на GPU.
Медленный алгоритм – это фича. Пользователь ждёт 100мс и не замечает. Злоумышленник при переборе миллиарда вариантов ждёт годы.
Но есть НЮАНС
Квантовые компьютеры. Да, они сломают все шифрование.
А потом мир перейдет на постквантовое шифрование. В общем, пока живем спокойно.
Зачем нужна соль
Если у тысячи юзеров пароль
password123 – у всех одинаковый хеш. Взломал один – взломал всех.Соль – случайная строка, уникальная для каждого пользователя:
password123 + x7Ks9pLm → 8f4a2b1c...password123 + Qw3rTy5z → d9e8f7a6...Теперь каждый пароль нужно подбирать отдельно.
Как это работает
Регистрация:
Пароль прилетает по HTTPS в теле POST-запроса (не в URL – там логируется). Сервер генерирует соль, считает хеш, сохраняет в базу данных. Сам пароль не хранится.
Вход:
Сервер достаёт соль и хеш из базы данных, считает хеш введённого пароля с той же солью, сравнивает. Совпало – пускает.
Диаграммы процессов приложу в комментах.
О перце
Когда нужна более сильная защита, используется перец – общий секретный ключ, хранящийся отдельно от базы данных. Он добавляется к паролю и соли перед хешированием:
password123 + x7Ks9pLm + pepper1# → 16hs8ac0...Даже если злоумышленник получит базу с хешами и солью, без перца он не сможет правильно вычислять хеши для проверки догадок. Подобрать пароль будет невозможно.
Выводы
🔸 Пароли не хранятся в открытом виде – только хеши
🔸 Соль препятствует массовому подбору
🔸 Перец защищает хеши при утечке БД
🔸 Медленный алгоритм – не баг, а метод защиты
И никакой магии. Когда пишешь требования к аутентификации – за фразой "пользователь может войти" стоит конкретная инженерная логика.
А вы знали, как это работает?
@analyst_exe
🔥9👍2🤯2
Как торговаться за скоуп и не стать врагом заказчика
У друга был проект. Заказчик пришёл с запросом: "небольшой CRM для отдела продаж".
На первой встрече набросали требования. Получилось 47 пунктов.
Заказчик назвал бюджет. Его хватило бы на 15 пунктов. Или на 20, если сильно ужаться.
"Ну давайте всё сделаем, потом посмотрим" – говорит заказчик. Классика.
Друг уже видел, чем это заканчивается. Бессонные ночи, переработки, "а вы же обещали", и в конце – недовольный заказчик, которому "не совсем то сделали".
Пришлось торговаться.
Почему это вообще задача аналитика
Потому что менеджер хочет продать. А заказчик хочет получить реализацию всех пунктов.
Аналитик – единственный, кто видит картину целиком: что реально нужно, что "хотелось бы", и что написали, потому что пришло в голову на встрече.
Если ты просто записываешь требования и передаёшь дальше – ты секретарь, а не аналитик.
Как друг разрешил ситуацию
Разбил на категории. Взял все 47 требований и разложил:
🔸 Must have – без этого система бесполезна (12 пунктов)
🔸 Should have – важно, но можно запуститься без (18 пунктов)
🔸 Could have – было бы круто (11 пунктов)
🔸 Won't have – хотелки на будущее (6 пунктов)
Получается MoSCoW. Но название не важно – важен принцип.
Привязал к боли. Пошёл к заказчику не со списком, а с вопросом:
"Какую проблему мы решаем в первую очередь?"
Оказалось – менеджеры теряют сделки, потому что забывают перезвонить. Вот боль. А остальное – "ну было бы неплохо".
Сразу 20 требований отвалились. Они не решали эту проблему.
Показал trade-offs. Не "это не влезает в бюджет", а:
"Если делаем интеграцию с телефонией сейчас – запуск через 4 месяца. Если откладываем на вторую версию – через 2 месяца уже работаем и собираем обратную связь."
Заказчик сам выбрал быстрый запуск. Это уже не ты режешь скоуп – это он принимает решение.
Зафиксировал письменно.
Подпись заказчика. Теперь "а вы же обещали" не работает.
Что в итоге
Запустились через 2.5 месяца с 16 требованиями. Заказчик доволен – проблема с потерянными сделками решена.
Через полгода пришли за второй версией. Половину из отложенных требований выкинули сами – оказалось не нужно.
Друг говорит: если бы сделали всё сразу, потратили бы в 3 раза больше времени на фичи, которые никто не использует.
Выводы
🔸 Приоритизация – твоя работа, не заказчика. Он хочет всё. Твоя задача – помочь выбрать.
🔸 Привязывай к боли. "Это решает вашу проблему?" – главный вопрос.
🔸 Показывай trade-offs, а не говори "нет". Пусть заказчик сам выбирает.
🔸 Фиксируй письменно. Память – штука ненадёжная, особенно когда дедлайн горит.
🔸 MVP – это не "урезанная версия", это "версия, которая решает главную проблему".
Так что умение говорить "давайте выпустим это в следующей версии" – это не слабость. Это профессионализм.
А как вы торгуетесь за скоуп? Получается или заказчики давят?
@analyst_exe
У друга был проект. Заказчик пришёл с запросом: "небольшой CRM для отдела продаж".
На первой встрече набросали требования. Получилось 47 пунктов.
Заказчик назвал бюджет. Его хватило бы на 15 пунктов. Или на 20, если сильно ужаться.
"Ну давайте всё сделаем, потом посмотрим" – говорит заказчик. Классика.
Друг уже видел, чем это заканчивается. Бессонные ночи, переработки, "а вы же обещали", и в конце – недовольный заказчик, которому "не совсем то сделали".
Пришлось торговаться.
Почему это вообще задача аналитика
Потому что менеджер хочет продать. А заказчик хочет получить реализацию всех пунктов.
Аналитик – единственный, кто видит картину целиком: что реально нужно, что "хотелось бы", и что написали, потому что пришло в голову на встрече.
Если ты просто записываешь требования и передаёшь дальше – ты секретарь, а не аналитик.
Как друг разрешил ситуацию
Разбил на категории. Взял все 47 требований и разложил:
🔸 Must have – без этого система бесполезна (12 пунктов)
🔸 Should have – важно, но можно запуститься без (18 пунктов)
🔸 Could have – было бы круто (11 пунктов)
🔸 Won't have – хотелки на будущее (6 пунктов)
Получается MoSCoW. Но название не важно – важен принцип.
Привязал к боли. Пошёл к заказчику не со списком, а с вопросом:
"Какую проблему мы решаем в первую очередь?"
Оказалось – менеджеры теряют сделки, потому что забывают перезвонить. Вот боль. А остальное – "ну было бы неплохо".
Сразу 20 требований отвалились. Они не решали эту проблему.
Показал trade-offs. Не "это не влезает в бюджет", а:
"Если делаем интеграцию с телефонией сейчас – запуск через 4 месяца. Если откладываем на вторую версию – через 2 месяца уже работаем и собираем обратную связь."
Заказчик сам выбрал быстрый запуск. Это уже не ты режешь скоуп – это он принимает решение.
Зафиксировал письменно.
По итогам обсуждения в MVP входит: ...
В следующую версию планируем: ...
Подпись заказчика. Теперь "а вы же обещали" не работает.
Что в итоге
Запустились через 2.5 месяца с 16 требованиями. Заказчик доволен – проблема с потерянными сделками решена.
Через полгода пришли за второй версией. Половину из отложенных требований выкинули сами – оказалось не нужно.
Друг говорит: если бы сделали всё сразу, потратили бы в 3 раза больше времени на фичи, которые никто не использует.
Выводы
🔸 Приоритизация – твоя работа, не заказчика. Он хочет всё. Твоя задача – помочь выбрать.
🔸 Привязывай к боли. "Это решает вашу проблему?" – главный вопрос.
🔸 Показывай trade-offs, а не говори "нет". Пусть заказчик сам выбирает.
🔸 Фиксируй письменно. Память – штука ненадёжная, особенно когда дедлайн горит.
🔸 MVP – это не "урезанная версия", это "версия, которая решает главную проблему".
Так что умение говорить "давайте выпустим это в следующей версии" – это не слабость. Это профессионализм.
А как вы торгуетесь за скоуп? Получается или заказчики давят?
@analyst_exe
🔥9👍8❤3💯1
Вчера в комментах к прошлому посту сказали, что нормальные парни работают по FFF (fix time, budget, flex scope -> читай как режем фичи, но делаем дело)
Где-то смеется один синий или зеленый, а может и красный, в общем любой банк 🥲🥲🥲
@analyst_exe
Где-то смеется один синий или зеленый, а может и красный, в общем любой банк 🥲🥲🥲
@analyst_exe
😁6
Никогда не делайте "техническую интеграцию" и вот почему
Однажды на проекте прилетела задача: "Нужна техническая интеграция с [название системы]". Не попросили — практически приказали. Сроки горят, давайте быстрее.
Что за проект — не скажу. Абсолютно реальная история из МТС.
Мы нашли документацию сами. Потому что её никто не дал. Сделали еле-еле, душа в теле. Отметили галочкой. Положили в ящик.
Через полгода бизнес наконец согласовал финансовые вопросы. Приходят радостные: "Ну, вам же только включить?"
А там не просто вершина айсберга. Там "зачем мы это вообще делали". Проще было начать с нуля.
Что пошло не так
Мы сделали техническую интеграцию. Буквально: связали две системы, данные ходят, ошибок нет.
Но никто не спросил:
🔸 Какой бизнес-процесс это поддерживает?
🔸 Какие данные реально нужны, а какие "на всякий случай"?
🔸 Кто будет пользоваться и как?
🔸 Что изменится в процессах, когда включим?
Мы интегрировали системы. А надо было интегрировать процессы.
За полгода изменилось всё: требования бизнеса, структура данных на той стороне, даже команда, которая это заказывала. А наша "техническая интеграция" осталась памятником тому, что было полгода назад.
Почему так происходит
"Давайте сделаем техническое, пока бизнес согласовывает" — звучит логично. Параллелим работу, экономим время.
На практике:
🔸 Техническое без бизнесового контекста — это код в вакууме
🔸 Требования меняются, пока ждёшь согласований
🔸 "Просто включить" никогда не бывает просто
Интеграция — это не про "данные ходят". Это про "бизнес-процесс работает".
Что стоило сделать
Задать вопросы до начала работы:
🔸 "Какую проблему решаем этой интеграцией?" — если ответ "ну, надо связать системы" — красный флаг
🔸 "Когда планируется запуск в прод?" — если "непонятно" или "когда согласуют" — может, не стоит начинать
🔸 "Что будет, если не сделаем сейчас?" — если ничего страшного — точно не стоит
И главное: интеграция без согласованного бизнес-процесса — это технический долг с первого дня.
Выводы
🔸 "Техническая интеграция" без бизнес-контекста — это не интеграция, это заглушка
🔸 Если бизнес не готов — техника тоже не готова
🔸 Вопрос "зачем?" важнее вопроса "как?"
🔸 Галочка в трекере ≠ готовая фича
Иногда лучший результат работы аналитика — не сделанная задача. Потому что вовремя спросил "а точно надо сейчас?"
А у вас были проекты, которые "сделали заранее", а потом выкинули?
@analyst_exe
Однажды на проекте прилетела задача: "Нужна техническая интеграция с [название системы]". Не попросили — практически приказали. Сроки горят, давайте быстрее.
Что за проект — не скажу. Абсолютно реальная история из МТС.
Мы нашли документацию сами. Потому что её никто не дал. Сделали еле-еле, душа в теле. Отметили галочкой. Положили в ящик.
Через полгода бизнес наконец согласовал финансовые вопросы. Приходят радостные: "Ну, вам же только включить?"
А там не просто вершина айсберга. Там "зачем мы это вообще делали". Проще было начать с нуля.
Что пошло не так
Мы сделали техническую интеграцию. Буквально: связали две системы, данные ходят, ошибок нет.
Но никто не спросил:
🔸 Какой бизнес-процесс это поддерживает?
🔸 Какие данные реально нужны, а какие "на всякий случай"?
🔸 Кто будет пользоваться и как?
🔸 Что изменится в процессах, когда включим?
Мы интегрировали системы. А надо было интегрировать процессы.
За полгода изменилось всё: требования бизнеса, структура данных на той стороне, даже команда, которая это заказывала. А наша "техническая интеграция" осталась памятником тому, что было полгода назад.
Почему так происходит
"Давайте сделаем техническое, пока бизнес согласовывает" — звучит логично. Параллелим работу, экономим время.
На практике:
🔸 Техническое без бизнесового контекста — это код в вакууме
🔸 Требования меняются, пока ждёшь согласований
🔸 "Просто включить" никогда не бывает просто
Интеграция — это не про "данные ходят". Это про "бизнес-процесс работает".
Что стоило сделать
Задать вопросы до начала работы:
🔸 "Какую проблему решаем этой интеграцией?" — если ответ "ну, надо связать системы" — красный флаг
🔸 "Когда планируется запуск в прод?" — если "непонятно" или "когда согласуют" — может, не стоит начинать
🔸 "Что будет, если не сделаем сейчас?" — если ничего страшного — точно не стоит
И главное: интеграция без согласованного бизнес-процесса — это технический долг с первого дня.
Выводы
🔸 "Техническая интеграция" без бизнес-контекста — это не интеграция, это заглушка
🔸 Если бизнес не готов — техника тоже не готова
🔸 Вопрос "зачем?" важнее вопроса "как?"
🔸 Галочка в трекере ≠ готовая фича
Иногда лучший результат работы аналитика — не сделанная задача. Потому что вовремя спросил "а точно надо сейчас?"
А у вас были проекты, которые "сделали заранее", а потом выкинули?
@analyst_exe
❤6😢2
Воскресный дайджест
Собрал для вас всё самое полезное за эти несколько недель (мемы сами полистаете). Про интеграции, переговоры, безопасность и выбор технологий.
🔸 Никогда не делайте "техническую интеграцию" и вот почему — https://t.iss.one/analyst_exe/575
🔸 Как торговаться за скоуп и не стать врагом заказчика — https://t.iss.one/analyst_exe/572
🔸 Как работают пароли — https://t.iss.one/analyst_exe/570
🔸 Заказчик не знает что такое НФТ и не должен — https://t.iss.one/analyst_exe/568
🔸 Три дороги к решению: коробка, Open Source или самопис — https://t.iss.one/analyst_exe/565
🔸 Как работает оплата по QR — https://t.iss.one/analyst_exe/563
Всем хорошо отдохнуть перед началом недели!
@analyst_exe
Собрал для вас всё самое полезное за эти несколько недель (мемы сами полистаете). Про интеграции, переговоры, безопасность и выбор технологий.
🔸 Никогда не делайте "техническую интеграцию" и вот почему — https://t.iss.one/analyst_exe/575
🔸 Как торговаться за скоуп и не стать врагом заказчика — https://t.iss.one/analyst_exe/572
🔸 Как работают пароли — https://t.iss.one/analyst_exe/570
🔸 Заказчик не знает что такое НФТ и не должен — https://t.iss.one/analyst_exe/568
🔸 Три дороги к решению: коробка, Open Source или самопис — https://t.iss.one/analyst_exe/565
🔸 Как работает оплата по QR — https://t.iss.one/analyst_exe/563
Всем хорошо отдохнуть перед началом недели!
@analyst_exe
🔥8
БЕСПЛАТНО ПЕРЕДЕЛАЮ 10 РЕЗЮМЕ
Нужны аналитики и не только, которые сейчас в поиске
Тестирую гипотезу связки билдер+матчер+скринер
Придумал хитрый флоу, нужно обкатать на реальных кейсах
Пришлите свое резюме мне в личку @darkwing_duck101
UPD: Набрал
@analyst_exe
Нужны аналитики и не только, которые сейчас в поиске
Тестирую гипотезу связки билдер+матчер+скринер
Придумал хитрый флоу, нужно обкатать на реальных кейсах
Пришлите свое резюме мне в личку @darkwing_duck101
UPD: Набрал
@analyst_exe
🥰7
Вчера писал про работу с резюме, и неожиданно откликнулись ребята с канала @yazhanalitik (1.5k+ подписчиков)
Почитал — зацепило. Интересные истории, текущее состояние рынка, короче круто, я раньше не видел такой канал. Думаю, стоит собрать подборку каналов, которые реально стоит читать
Полезно для расширения картины мира. Рекомендую заглянуть 👀
А я пойду дальше разбирать ваши резюмешки, половину уже сделал.
#НЕРЕКЛАМАМНЕЗАЭТОНИКТОНЕПЛАТИЛЯПРОСТОДЕЛАЮДОБРОЕДЕЛО
@analyst_exe
Почитал — зацепило. Интересные истории, текущее состояние рынка, короче круто, я раньше не видел такой канал. Думаю, стоит собрать подборку каналов, которые реально стоит читать
Полезно для расширения картины мира. Рекомендую заглянуть 👀
А я пойду дальше разбирать ваши резюмешки, половину уже сделал.
#НЕРЕКЛАМАМНЕЗАЭТОНИКТОНЕПЛАТИЛЯПРОСТОДЕЛАЮДОБРОЕДЕЛО
@analyst_exe
Telegram
#ЯЖАНАЛИТИК
😫 Страх и ненависть в найме: новый ⡁⢢⡔⠑⢄⡂ сезон
За последние пару недель я в полной мере ощутил на себе все изменения найма. Прежние попытки заткнуть самостоятельно дырку в доходах считаю легкой разминкой.
Успел пройти отрицание, гнев, торг. Особенно торг!…
За последние пару недель я в полной мере ощутил на себе все изменения найма. Прежние попытки заткнуть самостоятельно дырку в доходах считаю легкой разминкой.
Успел пройти отрицание, гнев, торг. Особенно торг!…
🔥6
Ну что господа, час настал, чебурнет все ближе
Cоздаем приватный чат в max?
Проведем честное голосование
👍 - создаем
🤡 - сидим до упора тут, max не торт
я бы не стал. лучше analystexe.ru в полноценный блог превратим
@analyst_exe
Cоздаем приватный чат в max?
Проведем честное голосование
👍 - создаем
🤡 - сидим до упора тут, max не торт
@analyst_exe
🤡37👍6😢1
Бл*, Костя, это можно было нормально сделать? Ну чего сложного было кнопку скрыть, ну почему она на dev01 все ещё есть?
А я это сейчас заказчику показывал и обосрался, ну Костя! 10 раз же уже переделывали! 😡😡😡😡
Быстро пошли в созвон! Ещё раз и я иду к менеджеру!
А я это сейчас заказчику показывал и обосрался, ну Костя! 10 раз же уже переделывали! 😡😡😡😡
Быстро пошли в созвон! Ещё раз и я иду к менеджеру!
😁9
Ой, не туда
Хотя ладно. 14 февраля на носу, а самые крепкие отношения у меня всё равно с Костей. Созвоны каждый день, переписка нон-стоп, «ну давай ещё разочек переделаем» — романтика 💔
С наступающим, аналитики. Берегите своих разрабов, других таких Кость не будет
Хотя ладно. 14 февраля на носу, а самые крепкие отношения у меня всё равно с Костей. Созвоны каждый день, переписка нон-стоп, «ну давай ещё разочек переделаем» — романтика 💔
С наступающим, аналитики. Берегите своих разрабов, других таких Кость не будет
❤15
Forwarded from BPM, Бизнес-процессы и котики (Denis Kotov)
Media is too big
VIEW IN TELEGRAM
В прошлом году на конференции обсудили все вопросы, и про дорожки тоже
В этом - обсудим настоящую оптимизацию процессов, а не дерганье квадратиков туда-сюда
Приходите на Stormconf26 10 апреля
В этом - обсудим настоящую оптимизацию процессов, а не дерганье квадратиков туда-сюда
Приходите на Stormconf26 10 апреля
🔥11❤6🤔2
Forwarded from BPM, Бизнес-процессы и котики (Denis Kotov)
Разыгрываем 8 билетов на Stormconf26: BPM + AI
3 билета среди подписчиков и 5 билетов среди владельцев пабликов в ТГ на 200+ человек.
Как поучаствовать (подписчики):
1. Поставь сердечко.
2. Переслать пост коллеге\другу.
3. Написать комментарий к посту.
...(будьте готовы прислать скриншот пересланного сообщения с датой до объявления победителей)
Как поучаствовать (владельцы пабликов):
1. Поставить сердечко.
2. Репостнуть в паблик.
3. Кинуть ссылку на репост в комментарий.
Итоги подведем 20 февраля, в пятницу вечером.
Поехали 😍😍😍
3 билета среди подписчиков и 5 билетов среди владельцев пабликов в ТГ на 200+ человек.
Как поучаствовать (подписчики):
1. Поставь сердечко.
2. Переслать пост коллеге\другу.
3. Написать комментарий к посту.
...(будьте готовы прислать скриншот пересланного сообщения с датой до объявления победителей)
Как поучаствовать (владельцы пабликов):
1. Поставить сердечко.
2. Репостнуть в паблик.
3. Кинуть ссылку на репост в комментарий.
Итоги подведем 20 февраля, в пятницу вечером.
Поехали 😍😍😍
❤6
Вся лента последние дни в огне: телегу блокируют, Max всех заставляют ставить, потом удаляют и так по кругу
Люди ставят одну звезду в сторе, пишут гневные посты, заводят отдельный телефон «для этой дряни». И я понимаю эмоцию. Но пока все воюют с одним мессенджером, хочется спросить: а вы знаете, что ваш оператор связи обязан по закону давать спецслужбам прямой доступ к вашему трафику? Причём с 1996 года?
Знакомьтесь — СОРМ.
Что это вообще такое
СОРМ — Система технических средств для обеспечения Оперативно-Розыскных Мероприятий. Это не приложение, которое можно удалить. Это железо и софт, которые стоят прямо на сети вашего провайдера. Любой оператор связи в России обязан его установить — за свой счёт, между прочим — иначе лишится лицензии.
У СОРМ три поколения, и каждое расширяет охват.
1. СОРМ-1 — прослушка звонков
Появилась ещё в 90-х. Работает как подслушивающее устройство, встроенное прямо в телефонную станцию. Только не жучок в вазе, а сертифицированный модуль в серверной стойке оператора. Сейчас почти не используется в чистом виде — телефония давно не единственный канал связи.
2. СОРМ-2 — перехват интернет-трафика
Вот тут начинается интересное. С начала 2000-х провайдеры обязаны ставить «съёмник» — оборудование, которое фильтрует трафик по идентификатору пользователя. Пульт управления стоит уже в ФСБ. Представьте, что на вашей водопроводной трубе стоит кран, ключ от которого — не у вас и не у сантехника.
3. СОРМ-3 — хранение всего
Это уже про закон Яровой. Операторы обязаны не просто давать доступ к трафику в реальном времени, а хранить его. Звонки, сообщения, интернет-сессии — всё складывается на серверы и лежит там месяцами. Как камера видеонаблюдения, которая не просто показывает картинку охраннику, но ещё и пишет на диск — на случай, если кто-то потом захочет перемотать.
Так что не так с паникой вокруг MAX?
Товарищ майор не вчера на работу вышел. Он бдит с 1996 года — задолго до того, как VK вообще появился. СОРМ стоит на уровне оператора связи: ниже любого приложения, ниже любого мессенджера. Удалить MAX и почувствовать себя в безопасности — это как снять шапочку из фольги, но остаться жить в стеклянном доме.
Это не значит, что критика MAX не по делу. Избыточные разрешения, отсутствие сквозного шифрования, сбор буфера обмена — всё это реальные косяки, и ругать за них правильно. Но если единственное, что вы сделали для своей приватности — удалили одно приложение и написали гневный пост — у меня плохие новости.
Мораль: не путайте фронтенд с инфраструктурой. MAX — это иконка на экране. СОРМ — это железо в серверной вашего провайдера с прямым каналом куда надо. Первое можно снести. Второе — нет.
Товарищ майор передаёт привет и просит не отвлекаться на мессенджеры.
@analyst_exe
Люди ставят одну звезду в сторе, пишут гневные посты, заводят отдельный телефон «для этой дряни». И я понимаю эмоцию. Но пока все воюют с одним мессенджером, хочется спросить: а вы знаете, что ваш оператор связи обязан по закону давать спецслужбам прямой доступ к вашему трафику? Причём с 1996 года?
Знакомьтесь — СОРМ.
Что это вообще такое
СОРМ — Система технических средств для обеспечения Оперативно-Розыскных Мероприятий. Это не приложение, которое можно удалить. Это железо и софт, которые стоят прямо на сети вашего провайдера. Любой оператор связи в России обязан его установить — за свой счёт, между прочим — иначе лишится лицензии.
У СОРМ три поколения, и каждое расширяет охват.
1. СОРМ-1 — прослушка звонков
Появилась ещё в 90-х. Работает как подслушивающее устройство, встроенное прямо в телефонную станцию. Только не жучок в вазе, а сертифицированный модуль в серверной стойке оператора. Сейчас почти не используется в чистом виде — телефония давно не единственный канал связи.
2. СОРМ-2 — перехват интернет-трафика
Вот тут начинается интересное. С начала 2000-х провайдеры обязаны ставить «съёмник» — оборудование, которое фильтрует трафик по идентификатору пользователя. Пульт управления стоит уже в ФСБ. Представьте, что на вашей водопроводной трубе стоит кран, ключ от которого — не у вас и не у сантехника.
3. СОРМ-3 — хранение всего
Это уже про закон Яровой. Операторы обязаны не просто давать доступ к трафику в реальном времени, а хранить его. Звонки, сообщения, интернет-сессии — всё складывается на серверы и лежит там месяцами. Как камера видеонаблюдения, которая не просто показывает картинку охраннику, но ещё и пишет на диск — на случай, если кто-то потом захочет перемотать.
Так что не так с паникой вокруг MAX?
Товарищ майор не вчера на работу вышел. Он бдит с 1996 года — задолго до того, как VK вообще появился. СОРМ стоит на уровне оператора связи: ниже любого приложения, ниже любого мессенджера. Удалить MAX и почувствовать себя в безопасности — это как снять шапочку из фольги, но остаться жить в стеклянном доме.
Это не значит, что критика MAX не по делу. Избыточные разрешения, отсутствие сквозного шифрования, сбор буфера обмена — всё это реальные косяки, и ругать за них правильно. Но если единственное, что вы сделали для своей приватности — удалили одно приложение и написали гневный пост — у меня плохие новости.
Мораль: не путайте фронтенд с инфраструктурой. MAX — это иконка на экране. СОРМ — это железо в серверной вашего провайдера с прямым каналом куда надо. Первое можно снести. Второе — нет.
Товарищ майор передаёт привет и просит не отвлекаться на мессенджеры.
@analyst_exe
🔥6❤5😢2