Всем привет!

В первой публикации этого канала хочу выразить благодарность своим дурзьям, которые заверили, что мне есть чем поделиться с Миром, и, собственнно, благодаря им этот канал появился.
Здесь я буду рассказывать о том, что меня волнует на момент публикации. Не могу гарантировать, что все заметки будут как-то связаны с трудовой деятельностью (ИТ, ИБ), так как есть масса других интересов (музыка, спорт, философия, психология, иностранные языки, путешествия), причем с годами они часто меняются. Со своей стороны постараюсь, чтобы мои публикации были полезны и интересны.
За мной можно следить:
reply-to-all.blogspot.com
dzen.ru/soldatov
linkedin.com/in/sergeysoldatov

Будем на связи!

Облако тегов:
#vCISO - заметки, полезные для руководителя ИБ
#управление - размышленния об управлении, руководстве и менеджменте вообще
#финансы - заметки о финансах, накоплениях, сбережениях, инвестициях
#книги - заметки о книгах и литературе вообще
#здоровье - заметки о спорте и ЗОЖ вообще
#кино - делюсь впечатлениями о просмотренных фильмах, если они того стоят
#театр - о театральных постановках и театре вообще
#музыка - рассуждения о музыке, редкие\уникальные записи :)
#искусство - прочие темы об искусстве, не попавшие в выделенные категории
#история - со времен школы люблю историю, до сих пор изучение истории для меня приятный досуг, буду помечать что-то интересное из истории и методов ее изучения
#саморазвитие - обо всем, что может пригодиться в жизни
#пятница - выходит в пятницу, чаще касается парадоксов из практики ИБ и вызывает улыбку
#MDR - здесь будем обсуждать все что касается технических аспектов SOC, обнаружения атак, интересных инцидентов
#ml - все что касается машинного обучения, глубокого обучения, искусственного интеллекта
#dev - о разработке ПО в широком смысле
#мир - анализируем мировые события

Интерфейс пользователя должен быть удобным! Но как это измерить?

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

Лично для меня "интерфейс красивый" в первую очередь означает "интерфейс удобный", причем в это "удобный" я включаю, как минимум, следующее:
1. цветовую палитру, расположение и размеры элементов, которые позволяют мне не напрягаясь, максимально быстро, рассматривать все элементы, фокусировать внимание в соответствии с ожидаемыми функциональными приоритетами (в первую очередь видеть то, что действительно важно)
2. количество манипуляций (например, движений и нажатий мышкой\пальцем) для совершения действий минимально

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

По цвету, расположению и размеру элементов предлагаю следующий тест. Профессионал в предметной области (SME), но ни разу не видевший тестируемый интерфейс, рассматривает интерфейс в течение N секунд (время определяется в зависимости от сложности интерфейса и на базе бенчмаркинга с аналогичными решениями), а затем его по памяти просят воспроизвести этот интерфейс на бумаге. При этом, стоит обратить внимание в какой последовательности SME будет зарисовывать интерфейс - это ответ на вопрос что он увидел в первую очередь, и сравнить это с функциональным назначением. Если SME не смог воспроизвести интерфейс по памяти, то с цветом, размером, расположением элементов есть проблемы, интерфейс надо перерабатывать. Более сложная, но и более эффективная реализация теста - это поискать ответ на вопрос: сколько нужно времени SME, чтобы запомнить его в достаточной для воспроизведения по памяти мере? Здесь надо уже привлекать нескольких SME. На практике у группы SME можно просто спросить их мнения (Метод Дельфи) и точечно отработать противоречия.

По сложности достижения цели предлагаю считать расстояние, которое проходит манипулятор (мышь\палец) для достижения цели и количество кликов. Здесь бы очень подошла мышка, измеряющая свой пробег - мышь с одометром, и счетчиком кликов. Чем меньше пройденное расстояние и количество кликов, тем лучше.

Отмечу, что UX - это целая наука, и я не могу себя отнести к эксперту в ней, но я не сильно совру, сказав, что я - эксперт по использованию продуктов, я опытный пользователь, и поэтому позволю себе иметь суждения о UX, чем и делюсь в этой заметке.

#dev #управление #пятница

Maintenance и Freezing

Я для себя четко различаю maintenace и freezing применительно к функционалу или компоненту информационной системы, однако, при общении с командами разработки заметил, что встречается несколько иное видение. Пользуясь преимуществом автора этого блога, поделюсь своим мнением.

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

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

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

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

#dev #управление #пятница

Наверно, это очевидно, что на КПЭ команд разработки положительно влияют выполненные ими CR/BRQ (Change Request, Business ReQurements) и негативно влияют дефекты (ошибки, bugs). Однако, даже от таких гигантов как Microsoft мы до сих пор нередко слышим, что какой-то баг - это вовсе не баг, а фича, что лишний раз подтверждает, что даже в зрелых конторах дефекты не всегда распознают как дефекты, или .... у них те же КПЭ - плюсы в карму за фичи, и минусы за баги.

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

#dev #пятница

От Waterfall до Snowball

Несмотря на то, что книжки про гибкую разработку уже давно стали классикой, а agile всеми интерпретируется как "абсолютное добро", вот и у Сбера есть целый Agile центр (правда, закрылся, видимо, они agile уже повсеместно внедрили и необходимость в Центре пропала) и пишут они о нем много теплых слов, на реальном производстве нередко встречается классический waterfall, ровно такой, как мне преподавали в институте, аж в 1996 году, иногда, для осовременивания, этот waterfall снабжают итерациями (спринтами), видимо, это и есть основное достижение гибкой разработки.

В 1996 году в институте я проходил жизненный цикл информационной системы: она разрабатывается (по waterfall-у), внедряется, эксплуатируется и выводится из эксплуатации (или что-то вроде того). Однако, за все свои 25 лет работы, ровно такого цикла я никогда не видел, а было примерно так: разработка - внедрение - эксплуатация с постоянной доработкой - .... (видимо, я уже поколение CI/CD). И это нормально, ибо ничто не стоит на месте и нам постоянно нужно дорабатывать используемую систему, чтобы она лучше отражала постоянно изменяющуюся действительность (да и закон диалектики утверждает, что совершенству нет предела). А вот для "постоянной доработки" waterfall совсем не пригоден, как минимум, потому, что за время пути собака точно подрастет. Но детали еще хуже!

Мы все хотим функционала - чем функциональнее наша система, тем лучше! А еще мы хотим, чтобы весь функционал тестировался, поэтому мы хотим много сценариев тестирования! А чтобы иметь постоянную уверенность, что наш новый функционал ничего не отломал, мы хотим проводить регрессионное тестирование, постоянно! Чем больше у нас функционала и тестов, тем дольше у нас регресс. Бесконечно сложная система, с бесконечно хорошим покрытием тестовыми сценариями будет иметь бесконечно долгое регрессионное тестирование, которое рискует не поместиться ни в одну итерацию (не забываем, что прогрессивный waterfall имеет итерации). Но и это еще не все!

Чем больше функционала, и чем он сложнее, тем больше дефектов! А исправление дефекта тоже может что-то поломать, поэтому после исправления бага объяснимо желание проведения полного регрессионного тестирования. Бесконечно сложный функционал и так имеет бесконечно долгий регресс, но надо не забыть добавить к этому бесконечное количество багов! Хорошо, что математика тут за нас - умножая бесконечность на бесконечность, мы получаем все ту же бесконечность, а не супер-бесконечность или мета-бесконечность, однако, легче от этого не становится, а ситуация нарастает как снежный ком.

#dev #пятница

Эффектное тестирование

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

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

#пятница #dev