Изменения

= Об учебном взгляде аналитика на работу =

У многих аналитиков неявно есть «учебный» взгляд на работу. Что я имею ввиду? Когда вы учились в школе и, позднее, в институте, ко всем учебным заданиям существовала инструкция, как его сделать, чтобы получить хорошую оценку. Понятно, что задания могли быть разные, предполагать творчество, например, сочинение, учебный проект или диплом, но это творчество касалось определенных элементов и по их поводу инструкция тоже в некотором виде. А еще критерием успеха являлась именно полученная оценка, которую поставит преподаватель, и эта оценка «по умолчанию» считалась верной, изменить ее требовало очень больших усилий. И дальше все это проявляется и на конференции и в работе: от докладов ждут, что там будет такая инструкция, по которым можно выполнять свою работу. А оценкой работы считают мнение принимающего твой документ, а применимость документа для следующего шага. И неявно предполагают, что оценка зависит именно от следования правилам.

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

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

* Короткая бизнес-модель

* Карта пользователей историй Story map

* Карта системного ландшафта — потоки данных

* Карты систем: функциональная; информационная; развертывания доступа и обслуживания — это архитектура

* Какую ценность несем, кому несем, в каких юридических отношениях мы с ними находимся.

* Клиентский путь: узнать, пройти воронку продаж, подключиться (попал в систему) — дает доходы

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

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

* Ключи. Бывает, что в системе-источнике контактные лица юрика — вообще не отдельные сущности-люди, а в системе-приемнике есть таблица физ-лиц контактов с идентичностью.

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

* Логирование. Чтобы интеграция записывала, что сделала, и почему упала, и фиксировала — что там было, и в каком сообщении это пришло.

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

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

= Евгений Скориков. Нефункциональные требования? Модели обеспечения качества! =

Гораздо интереснее, что в докладе был рассказ, чем их следует заменять, чтобы это имело смысл и реально работало. С практическими примерами, которые в интерактиве обсуждали с аудиторией. Общая схема такова.

# Берем аспекты работы с системами: отказоустойчивость, производительность, масштабируемость, эргономичность интерфейса и другие.

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

# Для проблем — есть специфические тактики предотвращения, которые снижают ущерб и имеют определенную стоимость. Выбираем тактики и проектируем варианты решения.

# Проектируем тест выбранного решения.

Это - тестируемо.

'''Phil Delgyado''': Вообще, доступность в процентах (sla) считают только для плановых остановов. Для разных инцидентов используется пара RTO/RPO, которая легко тестируется изначально. Ну и вообще доклад (судя по описанию) делал 'системный аналитик' (в плохом смысле этого слова), а не архитектор.

: '''MaximTsepkov''': Обсуждение личности автора вместо содержания доклада означает, что содержание не понравилось, но возражать — сложно. В докладе рассказана вполне рабочая модель, которой можно следовать в реальных условиях и с теми разработчиками и аналитиками, которые в среднем имеются. При чем достаточно общая, то есть подход можно применять для разных аспектов, хотя иллюстрирован только для некоторых. А если накидаешь ссылок на другие хорошие доклады или статьи — читатели отчета смогут обратиться к ним. Вдруг у тебя есть?

: '''Phil Delgyado''': По хорошему работа с НФТ — часть архитектурной деятельности, до разработки и до системной аналитики (как ее понимают в большинстве компаний). Более высокий уровень.

: '''MaximTsepkov''': Реально у бизнеса жестких требований нет. В том смысле, что он готов платить за определенное качество определенные деньги и обсуждать баланс — это как с фичами, они нужны при условии, что их стоимость оправдана. При этом, как и с фичами, функция стоимости — сильно не гладкая, а ступенчатая, холодный бэкап и горячее резервирование на standby дают сильно разные возможности за разные деньги, также как возможность автономной работы приложения против возможности работы только при подключении к инету, и там еще есть свои особенности по скорости подключения. Методика у Жени как раз позволяет превратить обобщенные НФТ в фичи, конструкция которых принципиально понятна, и дальше — выяснять, что из них бизнес готов купить.

: '''Phil Delgyado''': Нее, у бизнеса есть вполне понятные требования и цены, просто не все умеют их вытаскивать. И общая архитектура системы в первую очередь зависит от НФТ, там нет возможности демонстрировать бизнесу 'можно так, а можно так', основные выборы уже не изменить. И выборов гораздо больше, чем бэкап или active-standy, их десятки только для HA, не говоря уж про время отклика и так далее.

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

: '''MaximTsepkov''': Проекты, когда реально идет обсуждение, а нельзя ли ограничиться Standard edition вместо Enterprise, а недостающий функционал сделать своими методами и будет ли это дешевле, потому как из enterprise нужно немного а разница цен, если умножить на число инстансов — велика — редкое исключение, они у меня были. И архитекторы об этом, как правило, вообще не думают — что будет сильно дороже. Или предложить отказаться для конкретного набора рабочих мест от Windows, при том, что на Linux есть определенные проблемы, включая администрирование — если ты при этом экономишь несколько тысяч лицензий.

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