Спасибо Максиму. Не все вошло в его отзыв. Будет время статейку напишу...

#lafest Евгений Скориков. Нефункциональные требования? Модели обеспечения качества! Очень хороший доклад, о том, что нефункциональные требования в их привычном виде "отказоустойчивость 99.5%" или "отклик системы 5 секунд" - совершенно бесполезная вещь: непонятна осмысленность, способы удовлетворения и тестирования и риски. 99.5% - это 0.5% сбоев, если система не работает в год 1.5 суток подряд - это как, нормально? Для многих - ненормально, хотя в норматив формально укладывается. В общем, эта критика - понятная, эти требования часто берут произвольно. Например, по производительности, кстати, нет достоверных исследований: как именно скорость работы сайта влияет на бизнес. Понятно, что если ваш сайт жутко тормозит, и есть сайт конкурента, который делает все тоже самое и быстро, то люди уйдут туда. Но в реальной жизни сайт конкурента делает НЕ тоже самое, там есть чего-то меньше и чего-то больше, у него есть другая эргономика. И как это влияет? Исследований нет. Честное исследование - замедлить сайт для части клиентов и сравнить, но на это ни один бизнес не пойдет.

Гораздо интереснее, что в докладе был рассказ, чем их следует заменять, чтобы это имело смысл и реально работало. С практическими примерами, которые в интерактиве обсуждали с аудиторией. Общая схема такова.
1) Берем аспекты работы с системами: отказоустойчивость, производительность, масштабируемость, эргономичность интерфейса и другие.
2) Для каждого аспекта есть специфические проблемы, и мы декомпозируем систему с точки зрения этих проблем. Например, для отказоустойчисовти смотрим на отказы базы данных, серверов приложений, сетевой инфраструктуры, клиентских приложений. Для производительности - деградацию на выполнении различных функций. И так далее.
3) Выписываем возможные проблемы в каждой части, оцениваем их значимость: если это случится - каковы последствия, потери для бизнеса.
4) Для проблем - есть специфические тактики предотвращения, которые снижают ущерб и имеют определенную стоимость. Выбираем тактики и проектируем варианты решения.
5) Выбор решения - по балансу потерь против стоимости.
6) Проектируем тест выбранного решения.

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

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

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

В целом - очень конструктивный и полезный доклад, спасибо Евгению.

Коллеги, ищу себе в подмастерье джуна/мидла, нюхавшего пороха. Придется много учится и читать (книга в месяц - минимум). Критерии отбора - отличные соображалка, вьедливость и умение писать. Зато за год - крепкий мидл. http://hh.ru/vacancy/82250382

Коллеги, вакансию закрыли внутренним переводом

Коллеги, если что, мой контакт в телеге https://t.me/EvgeniySkorikov

Обратил внимание.
Аналитик должен формализовать знания, полученные в результате интервью. Джун - как то в виде mindmap.
Мидл уже должен укладывать полученные знания в модели систем.
Но !!! на интервью затрагивают разные модели разных систем: 1. ИТ системы,
2. бизнес процессы,
3. ИТ / бизнес проект,
4. орг структуры бизнеса/ИТ/проектные,
5. стратегия бизнеса,
6. модель клиента,
7. конкурентное и другое окружение бизнеса (контекст).
Если аналитик в этом не разбирается, то вряд ли он сделает это качественно.
Альтернатива - каждый пишет свою часть (бизнес аналитик, системный аналитик, рп, бизнес архитектор, архитектор приложения, начальник отдела разработки, поддержки и пр). А потом собирается все вместе в один протокол. Или джун пишет mindmap, который каждый потом еще обрабатывает, создавая свои модели.
Вывод прост. ИТ аналитику, проектирующий автоматизацию бизнеса, хорошо бы разбираться в том как могут работать использующие системы (по иерархии вверх вплоть до клиента), системы в окружении и обеспечивающие системы.

Что такое отчет и статусная встреча по проекту (главного) для заказчика проекта? Это же интерфейс проекта как системы. Статусная встреча – это интеграционное взаимодействие заказчика и системы-проекта через интерфейс.
И что с этого? Заказчики – люди разные, с разными интересами. Контекст и проектная ситуация разная. А следовательно, универсальный интерфейс неудобен, его нужно проектировать под ситуацию. Какую информацию пользователь интерфейса должен видеть для принятия решений, какие кнопки на этом интерфейсе он может нажимать.

Выпустили видео моего доклада "Не надо разрабатывать НФТ, надо проектировать модели обеспечения качества". Доклад буду повторять онлайн когда-нибудь (есть пара моментов которые можно улучшить) + статья в процессе подготовки https://vimeo.com/845291852 (или тут - https://conf.uml2.ru/class/nft.html )

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

Дожал таки статью про "Проработку НФТ", более точно про то, что не надо прорабатывать "НФТ", а надо прорабатывать модели обеспечения качества. Буду рад вопросам/комментам/обсуждениям.
Можно посиделки провести вживую, чтобы обсудить где я лажу написал.
(Статья пока не прошла корректуру, так что на знаки препинания не смотрите, сейчас важно дожать смысл).
https://docs.google.com/document/d/1-cFpdnzWOsLoOtsFjGkk8wKdYpBAqTeRyGQLm9tQNHY/edit?usp=sharing

Сегодня в 18-00 будет обсуждение статьи. Кому интересно, приходите. Ссылку пришлю в коммент

Прочитал отличную статью про психологические эффекты при внедрение изменений в рабочие процессы. Зашло. https://dckms.github.io/system-architecture/emacsway/soft-skills/change-making.html

Придумал новый термин "Система упала монолитнонепонятно"...

Опубликовал статью про НФТ, большое спасибо коллегам за обсуждения и замечания. В статье есть что улучшать, особенно в преамбуле, но пока так https://habr.com/ru/articles/756378/

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

А неплохая статья. Взгляд со стороны разработчика (Автор умолчал про возникающие задачи для аналитика при повышении доступности системы, но такие уж разрабы) https://habr.com/ru/articles/764904/

Буду выступать тут. Повторение мать учения. https://samokattech.timepad.ru/event/2618817/

Бугагашенька

Задачка. В одном из чатов увидел задачу "сделать классификатор софта". На вопрос зачем автор ответил "чтобы им пользовались". Вопрос - в чем ошибка ответа и что должно быть в ответе, чтобы этот ответ был годным?