Процесс

_{Соавтор:Кузнецова Юлия Андреевна - UX-писатель Экосистемы РСХБ}

Каким должен быть дизайнер в банке, чтобы и продукт хороший создавал, и коллеги не жаловались. Смотрим через призму софт-навыков вместе с UX-дизайнерами РСХБ.

#1 Коммуникабельность: не просто коллега человек

Дизайнер отличная профессия для интровертов. Рисуешь интерфейсы, слушаешь музыку, ни с кем не общаешься На самом деле, нет!

Работая в банке, ты участвуешь в большом количестве созвонов, слушаешь коллег, предлагаешь свои идеи. Споришь. Много споришь. Убеждаешь. Идешь на компромисс. Вместе с тобой над продуктом работают много других сотрудников продакт-менеджеры, аналитики, разрабы, редакторы, юристы ты должен уметь услышать каждого и найти общий язык.

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

Итог: учись разговаривать с людьми и старайся взаимодействовать с коллегами так, как хотел бы, чтобы они взаимодействовали с тобой.

#2 Презентация: готов объяснить свою работу

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

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

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

#3 Аналитика: думает не только о красоте

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

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

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

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

#4 Понимание бизнес-процесса: переводит с банковского языка на человеческий

Юный дизайнер: мастерски работает в Фигме, любит компоненты, боготворит филигранную верстку.

Продвинутый дизайнер: понимает, как устроен бизнес и финансы.

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

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

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

#5 Любознательность: постоянно учится новому

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

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

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

Мне кажется, что в любой компании, деятельность которой как-то связана с IT, отдел разработки является двигателем бизнеса. Leadership team дает направление движения и прокладывает основные координаты, а development дает тягу и мчит компанию в хорошем случае вперед, по проложенному маршруту. Ну или в некоторых случаях куда-то еще. Мы называем наш development процесс и команду Warp Drive, и в этой статье я расскажу про то то, как он построен и про основные принципы его работы.

Для начала картинка, основных составляющих нашего движка. Упрощенная схема выглядит примерно так:

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

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

В целом процесс, по которому мы идем основан на agile практиках. На вход в двигатель поступают требования от бизнес\команды руководства. Это то, что впоследствии будет преобразовано в составляющие конечного продукта, фичи и апдейты. Раз в 2 недели мы проводим Warp Jump (Sprint Planning) где истории назначаются на конкретных людей в команде и мы идем по стандартному 2-х недельному спринту. В результате прыжка в продукте появляются новые фичи, и они потихоньку накапливаются в Dev Environment. Там они проходят проверку качества, и затем деплоятся на Prod. Для простоты Staging/QA environments в нашей схеме пропущены.

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

Итак - желтые фичи находятся в состоянии квантовой неопределенности. Все новые фичи, которые появились в Dev начинают с этого состояния. Это означает, что на данный момент, мы не имеем точного представления о том, является ли эта фича полезной конечному пользователю, или же она только отвлекает\не работает\работает не как надо\не используется. Ответы на эти вопросы мы можем получить только после того, как фича была задеплоена на Prod Environment и мы увидели обратную связь от пользователей. Если пользователь доволен - фича переходит к подтвержденно-хорошее состояние (зеленая), если что-то не так - подтвержденно-плохое состояние (красная) и должна быть либо отправлена на доработку, либо удалена из системы.

Синие фичи, это Technical Debts, т.е. те улучшения, которые девелопмент команда запланировала сделать для своей собственной эффективности. Это может быть или улучшение инфраструктуры проекта, или архитектурный рефакторинг, либо что-то еще. Т.к. участники Warp Drive сами являются заказчиками Tech Debts и мы знаем, что конкретно мы хотим, то такие фичи не проходят через фазу квантовой неопределенности и поэтому классифицируются отдельно от бизнес фич\требований и обычно просто соответствуют состоянию Confirmed Good. В целом процесс перестроения и патчинга двигателя на полном ходу с помощью Tech Debts завораживает, но я думаю все мы в IT индустрии к этому уже давно привыкли.

Далее пройдемся по деталям и поговорим про анатомию одной конкретной фичи.

Из чего же состоит одна фича на нашей схеме? Во первых в нее входят затраты времени на сбор требований и понимание того, какой мы видим ту или иную функцию. Затем, перевод требований в истории, которые непосредственно пойдут в разработку и их приоритизация. Дальше идут Front-End/Back-End development, иногда подключаем DevOps, если нужно еще и environment докрутить. Затем идут затраты на тестирование/QA. И еще один пункт, это поддержка того, что уже работает в Prod.

Для наглядности, развернем эту картинку на полосу конвейера конвертации топлива warp drive(времени) в одну фичу.

Затраты на реализацию одной фичи у нас делятся на 2 типа: повторяющиеся (на схеме отмечены звездочкой), и неповторяющиеся. Для простоты будем считать, что собирать требования, разбивать на истории, проводить backend/frontend development нам нужно только один раз за жизненный цикл фичи. В то же время есть повторяющиеся операции, которые скорее всего понадобится делать снова и снова, уже после того, как данная функция была выпущена в PROD environment. Такими операциями могут быть тестирование, поддержка, иногда конфигурация среды и прочие сервисные штуки.

Таким образом мы получаем, что каждый раз, когда мы релизим что-то в PROD, за счет повторяющихся составляющих фичи, мы увеличиваем операционную стоимость нашего продукта. Если один релиз скорее всего пройдет незаметно, то релизы множества различного функций со временем накапливаются и начинают работать законы масштабируемости. И, как мы обсуждали ранее, не все фичи одинаково полезны. Одним из побочных эффектов нашего Warp Drive являются фичи в Confirmed Red State(красные). Если мы оставляем в системе красные фичи, которые не несут полезной функциональной нагрузки, они не просто увеличивают кодовую базу приложения, но и прибавляют к стоимости поддержки всего продукта. Если не обращать на этот фактор внимание, со временем продукт обрастает функциями, которые не нужны пользователю, и за него еще и платить нужно все больше и больше. И поэтому это очень важно, для поддержания эффективности продукта с точки зрения usability и операционной стоимости стараться держать положительный баланс зеленых фич приложения, и конечно же избавляться от красных. Именно для этого мы держим постоянный контакт с конечными пользователями и требуем от них обратной связи на те или иные функции. Это является частью нашего feature management process.

Еще одним моментом, который влияет на эффективность нашего Warp Drive, является эффективность каждого участника процесса. Основой продуктивности обычно являются не технологии, а слаженность взаимоотношений внутри команды. Но технологии и удовлетворенность работы с конкретными технологиями тоже конечно важны. Следующая диаграмма показывает крутящий момент и общую мощность которую может выдать наш Warp Drive, когда мы работаем над тем или иным функционалом.

Здесь мы видим соответствие участников процесса технологиям, которые используются для разработки фич, таким как front-end development, back-end development, support, requirements gathering, и т.д. Нет, процентные показатели на данной диаграмме это не опыт участников в какой-то технологии. Это количество внутренней энергии и заинтересованность человека в чем-то. Например, если мы дадим Василию ковырять Front-End, наверное не стоит ожидать от него супер продуктивности, просто потому что у него с этой частью как-то не сложилось и он оценил свою вовлеченность в эту область в 10%. Василий предпочтет настроить вместо этого базу данных и будет при этом работать с высокой отдачей, потому что это та деятельность, которая ему нравится, и которая наполняет его энергией.

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

Надеюсь, кому-то будет полезен наш опыт и те опорные точки, которые мы учитываем в работе. Если кому-то интересна бизнес часть нашей работы, прошу посетить подкаст моего кофаундера Брендона. Сори, на английском, но есть субтитры. Как и во многом другом, двигатель и командный пост должны дополнять и помогать друг-другу. Многие решения, которыми мы руководствуемся на уровне разработки, продиктованы именно нефункциональными бизнес требованиями.

https://brandoncwhite.com/startup-podcast-build-business-brandon-straight-talk-for-entrepreneurs/

Спасибо за внимание.

Технический долг по аналитике это любая отсутствующая документация на функционал, который поставлен в промышленную среду.

Давайте разберемся на простом жизненном примере, почему важно не копить техдолг?

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

Однажды в летний жаркий день вы едете на машине в отпуск, и кондиционер не охлаждает, пошел ливень, а дворники не помогают, да еще порвался ремень ГРМ, и машина остановилась. Выглядит как самый худший день в жизни, остается только ждать эвакуатор.

В этот момент вы вспоминаете: Почему я не выполнил сразу работы по ремонту, а отложил их подальше?!

Вот и с техдолгом похожая ситуация.

Какими могут быть последствия накопления техдолга?

• Снежный ком документов

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

• Отсутствие экспертизы для будущих поколений

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

• Время разбора дефектов увеличивается

Наташ, мы все уронили!

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

• Негатив от команды

Разработчики пишут код со слов, тестирование тестирует со слов, а бизнес думал, что его слова по-другому поняли. В итоге функционал работает, но когда начинаешь разбираться, как работает, появляется много вопросов, и нет документации, где посмотреть

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

Что мы сделали?

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

2. Определили, что такое техдолг, и как выбирать приоритеты;

3. Расписали процесс ведения, включения задач по техдолгу в бэклог, ответственных;

4. Сформулировали ситуации, сигнализирующие, что техдолг растет, и определили, что делать в таких случаях;

5. Собрали задачи по техдолгу в рамках направлений.

Что такое техдолг и как выбирать приоритеты?

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

Как завести задачу по техдолгу в backlog?

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

Добавить задачу по техдолгу аналитики может любой член команды или сопровождение. За выполнением задач по техдолгу следит техлид аналитиков.

Правила ведения задач в jira

В качестве инструкции и отчета в первой версии создали статью в Confluence с содержанием:

• Что такое техдолг

• Почему важно закрывать техдолг

• Ответственность

  • Кто добавляет задачи

  • Как задача попадает в техдолг

• Процесс работы с техдолгом

• Как ведем задачи в Jira

  • Кто закрывает техдолг

  • Кто следит за выполнением

• Список задач

  • Срез задач на 2 квартал 2021

Список задач собрали автоматически с помощью макроса Jira и настроили возможность фильтрации с помощью макроса Фильтр таблиц. Для визуального отображение использовали макрос Jira круговая диаграмма

Что делать, если техдолг растет

Ситуация 1 растет тех.долг

Решение: Бери задачи по техдолгу в работу в sprint.

Ситуация 2 увеличилось время разборов дефектов из-за отсутствия документации

Решение: Выполняй задачи по техдолгу.

Ситуация 3 хочешь повысить оценку компетенций для продвижения по карьерной лестнице

Решение: Помогай другим направлениям закрывать их техдолг.

Как закрывать техдолг, а не копить

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

Каждый аналитик из рабочей группы в рамках своего направления:

• создал задачи в JIRA по текущему техдолгу;

• написал статью по шаблону. Пример статьи был выше;

• обсудил с аналитиками из своего направления, кто какие задачи возьмет в работу в следующем квартале;

• рассказал аналитикам из своего направления, какие правила заведения задач по техдолгу.

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

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

Следующим шагом будет настройка dashboard для мониторинга прироста задач по техдолгу.

Предупрежден значит вооружен.

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

Статья нашего сотрудника.

Тема посвящена нейронным сетевым технологиям.

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

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

В нейронных сетевых технологиях есть метод решения проблем исключающего или (XOR).

Таблица исключающего или выглядит следующим образом:

для бинарного сложения по модулю 2 (применяется в двоичных полусумматорах):

Правило: результат равен 0, если оба операнда равны; в остальных случаях результат равен 1.

для тернарного сложения по модулю 2 (применяется в двоичных полных сумматорах):

Правило: результат равен 0, если нет операндов, равных 1, либо их чётное количество.

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

Нейрон это единица (входные данные (input data)), которая получает информацию и дальше передаёт информацию на скрытые слои n, где происходят арифметико-логические вычисления, после следует выходной слой, который выводит результат (выходные данные (output data)).

Синапс это связь между двумя нейронами, у синапсов есть 1 параметр вес.
Благодаря ему входная информация изменяется, когда передаётся от одного нейрона к другому.

Аннотированная ссылка

Нейроны оперируют числами в диапазоне [0,1] или [-1,1]. Если числа выходят из данного диапазона, то необходимо 1 разделить на полученное число.

Аннотированная ссылка

В поле input попадает суммарная информация всех нейронов с предыдущего слоя, после чего она нормализуется с помощью функции активации.

Функция активация служит для нормализации входных данных (оптимизация), то есть, если на вход поступает большое число, функция активации позволяет получить это число в нужном для нас диапазоне.

Самые основные функции активации: Линейная, Сигмоид и Гиперболический тангенс. Главное их отличие, это диапазон значений:

Линейная функция

Чаще всего используется для тестирования нейронной сети.

Сигмоид

Распространённая нормализуемая сигмоидальная функция активации, её диапазон значений [0,1].

Гиперболический тангенс

Используется тогда, когда могут быть числа отрицательными, и положительными, так как диапазон функции [-1,1].

Аннотированная ссылка

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

Аннотированная ссылка

где x min минимальное выборочные значения признака.
x max максимальное выборочное значение признака.
[a, b] выборка интервала.
x i значение признака.

Либо, если метод обработки нейронной сети обучения не имеет жёстких ограничений, применяется формула по масштабированию, дающая ненулевое среднее и единичную дисперсию пред обработанной величине:

Аннотированная ссылка

где M(x) исходное выборочное среднее.
(x) среднее квадратичное отклонение.
x i значение признака.

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

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

Аннотированная ссылка

Примером может быть популярная система распознавания объектов с помощью изображения от разработчиков компании Google.
Вот пример обработки изображения с целью получения результата, что это за действие/объект:

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

Заключение

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

Автор: Кирилл Артамонов