Русский
Русский
English
Статистика
Реклама

Business analyst

Про outsource и product компании

10.04.2021 14:17:23 | Автор: admin

Всем привет.

Я team lead, сертифицированный коуч и начинающий психолог.

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

Я работал в двух продуктовых компаниях, одной outstaff (жил и работал в Абу Даби, по контракту с минской компанией) и двух outsource. В общей сложности был где-то на 15 проектах.

В этой статье хочу поделиться своим видением текущей ситуации на рынке.

  • За время работы заметил следующие интересные феномены:

  • В продуктовых компаниях люди чаще обсуждают что изменить в продукте (язык заплетается). В outsource компаниях в процессах

  • В продуктовых компаниях меньше менеджмента

  • В продуктовых компаниях реже взаимодействие с заказчиком (или целевой аудиторией)

Ни на одном проекте не встретил аналитику в outsource.

Здесь думаю следует пояснить, что такое outsource.

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

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

Здесь очень важно понимать, что заказчик в момент обращения за помощью уже находится в НЕ спокойном состоянии. Его напряжение настолько сильное, что он готов расстаться со своими деньгами, лишь бы его избавили от этого напряжения. Более того, он согласен принимать условия scrum, agile и прочего, лишь бы только не встречаться снова с проблемой, которую он не хочет решать.

Забегая вперёд, именно от незнания вышеизложенного часто идёт удивление почему заказчик вдруг стал недоволен. Он и был недоволен, и это вообще не с вами связано.

Так вот, помимо непосредственных задач, которые заказчик пытается переложить на outsource компанию он транслирует ещё и своё нежелание/сопротивление эту работу делать.
Выражаться это может в чём угодно он плохо сформулированных требования (ну, потому что не хочет он больше видеть эту проблему. Решите уже её за меня), он жалуется на плохую работу предыдущих исполнителей или текущих сотрудников и т.д.

Причём всё это нужно трактовать не как объективные и осознанные недовольства заказчика, а как психологическую разгрузку. Что-то в стиле пожаловаться друзьям. Однако в случае outsource компании возможность пожаловаться является услугой, оказываемой такому заказчику.

Здесь ни в коем случае руководство outsource компании не должно обесценивать работу менеджеров или бизнес-аналитиков. Эти люди стоят на передовой. Их задача состоит в том, чтобы путём снижения сопротивления заказчика составить понятные и хорошо описанные требования для команды разработчика.

Таким специалистам необходимо иметь достаточно неплохие дипломатические навыки. И чётко разделять профессиональную и личную критику (вы делаете фигню и вы козёл).

Заказчик, каким бы он милым не казался, будет находиться в большом стрессе. И его логичным желанием будет слить своё напряжение в дипломата со стороны outsource.
Таким специалистом не должен быть разработчик (либо это должно быть отдельно прояснено с ним).

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

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

Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения

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

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

Всё очень просто. Заказчик начинает использовать разработчика, как бизнес-аналитика. И сливать в него своё раздражение от задачи, которую ему так не хочется делать.

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

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

И здесь есть интересная ловушка.

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

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

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

Для упрощения воспользуемся метафорой семьи.

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

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

Поэтому разработчик находится в какой-то не совсем понятной ситуации. Как бы между двух родителей.

Здесь очень важно заметить про страх непринятия и обесценивания.

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

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

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

Получается при сильной фигуре заказчика, старшие разработчики могут открыто выражать своё недовольство как менеджерам, так и заказчикам. И уже отстаивать свой личный интерес.
Младшие же разработчики так делать не могут (чаще всего) в силу собственной идентичности в данной группе.

И здесь важно заметить, что если человек деградирует до невербального периода (до того, как научился говорить), то он просто не будет выражать своё недовольство, замкнётся и выгорит.

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

Со старшими же разработчиками всё сложнее. Здесь как раз могут возникать конфликты. Т.к. необходима сепарация от родителя-менеджера, для выстраивания адекватных отношений с заказчиком. Иначе стресс (между двух родителей).

В такой ситуации для менеджеров наступает момент встречи с "ребёнком в подростковом периоде". Когда он ещё не самостоятельный (человек всё-таки на контракте). Но уже требует своего признания (уважение его договоров с заказчиком).

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

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

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

Такой конфликт спор за признание родителя. Или "про процессы". Является наиболее частым в outsource компании именно из-за специфики работы.

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

От сюда и появляется первый феномен (из начала статьи).

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

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

Как следствие разворачивается и второй пункт меньше менеджмента. Он практически не нужен. Всё прекрасно работает.

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

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

Подробнее..

BAдайджест, январь 2021 как отклонять feature request иоценить стоимость ошибки вБП

10.02.2021 14:12:50 | Автор: admin

Всем привет! Меня зовут Юра, яBA Tech Lead вNIX, аэто первый выпуск дайджеста для бизнес-аналитиков. Внем вынайдете, намой взгляд, ценные идостойные внимания материалы за прошлый месяц. Enjoy!

В скобках возле заголовков уровень сложности статьи (Normal * Hard Expert ***) и примерное время на изучение материала.

Business Analysis

Sorting Through the Pile: Classifying Customer Requirements (*, 6 мин). Классификация требований от дедушки Вигерса для самых маленьких. Новичкам в помощь, старичкам в радость.

Tactfully rejecting feature requests (**, 9 мин). Каждый из нас попадал в ситуацию, когда приходит очередной важный запрос на фичу, а она не ложится в продукт не помогает реализации бизнес-идеи, ломает архитектуру, не приносит пользы целевой аудитории и так далее. А отказать тому же клиенту неудобно, он же клиент. Так вот, в статье есть рекомендации о том, как просящему понять, почему фича не нужна, через несколько несложных шагов и техник.

Куда пропадают деньги компании, или Как оценить стоимость ошибки в бизнес-процессах (**, 6 мин). В статье рассматривается пример расчета финансовых потерь из-за несовершенства бизнес-процессов, типы ошибок, как их искать и что с ними делать. Актуально для процессных аналитиков, которые взаимодействуют непосредственно с бизнесом. Для остальных не будет вредным для общего развития.

The 10 Attitudes of Outstanding Product Owners (**, 7 мин). Кто еще не сталкивался узнать, а кто знает вспомнить о том, что лежит в основе этой роли. К аналитикам эти принципы относятся в равной степени.

Top 7 Hybrid Business Analysis roles (*, 10 мин). Разбор наиболее частых вариантов совмещения профессий БА+. По полочкам разложено, какие варианты более удачны, а какие скорее нет.

Writing Kick-Ass User Stories (*, 7 мин). Очень короткий, но емкий гайд, расписанный на примере, который поможет быстро погрузиться в процесс написания User Stories.

The Business Value of Better Requirements (*, 6 мин). Свежий материал от дедушки Вигерса на тему почему хорошие требования очень экономят бюджет.

No One Expects the Requirements Inquisition: Asking Next-Level Questions (*, 6 мин). И еще материал от Карла (!). На этот раз о том, какие вопросы помогут углубиться в реальные needs.

Почему важно наглядно доносить информацию. Визуализация данных для бизнес-аналитика (**, 10 мин). Кирилл Белявский из SoftServe рассказывает об актуальности техник визуализации, важности для бизнеса, восприятии визуализации, а также популярных инструментах.

Build effective Minimum Viable Products with the MVP Experiment Canvas (**, 13 мин). Бесплатный фреймворк для структурирования и запуска MVP и валидации бизнес-идеи.

Расширяем кругозор

Как не надо релизить проекты. Работаем с требованиями, оценкой и оплатой (**, 15 мин). Страшные сказки на ночь о нерадивых клиентах, срывах сроков, размытых требованиях, форс-мажорных ситуациях и других бабайках, которыми только и делать, что пугать Junior'ов. Если же серьезно, то в статье много жизненных ситуаций, на которых можно поучиться не совершать чужие ошибки и предвидеть свои.

Lightning Cast: Resistance to Change (*, 4 мин). Выжимка теории по Goldratts Four Quadrants on Change почему сопротивляются изменениям и что с этим делать.

Your Product Has Too Many Features (*, 6 мин). Взгляд на возможные причины захламления фичами на примерах Facebook / Amazon, а также - что с этим делать.

Beware SAFe (the Scaled Agile Framework for Enterprise), an Unholy Incarnation of Darkness (*, 14 мин). Как можно догадаться из названия статьи, автор далеко не фанат SAFe, у которого пригорело. Мне довелось лишь слышать о SAFe, изучать теорию, но использовать ни разу. Тем не менее мне все казалось, что два дня планирования это перебор, ограничивающий команды, хоть мне и были озвучены весомые аргументы за. Автор статьи приводит много аргументов против, в том числе ссылки на Кена Швабера и других лиц, которые высказывали свои опасения на счет SAFe.

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

Готумо до запуску продукт. Чек-лист для Product Manager (**, 10 мин). Мария делится опытом и дает нам рабочий инструмент, которым стоит воспользоваться.

A comprehensive list of UX design methods & deliverables (*, 12 мин). Подборка техник по сабжу краткий обзор + ссылки на почитать. Пожалуй, наиболее лаконичный и полный обзор из тех, что встречал.

How to Spot and Prevent Useless Meetings (*, 4 мин). Признаки, с помощью которых вы быстро определите, откуда стоит слинять, либо, если не получится, хотя бы взять ноутбук, чтобы поработать.

IT-словарик для не-айтишников (*, 4 мин). Словарь терминов, которые стоит знать каждому :)

UI cheat sheet: Icon categories + icon style reference guide (**, 21 мин). Очередной шикарный гайд от Тессы Гадд, на этот раз о том, как правильно делать иконки.

Подробнее..

Root Cause Analysis как метод предотвращения багов

02.03.2021 22:15:14 | Автор: admin

Привет! Мое имя Юра Гомон, яBATech Lead вNIX ивот уже 8лет занимаюсь бизнес-анализом, помогая реализовывать веб- имобильные решения для бизнеса, атакже автоматизировать бизнес-процессы. Мое имя кажется Вам знакомым, т.к. недавно я опубликовал на Хабре свой BADigest.

Цель статьи напомнить бизнес-аналитикам ометоде Root Cause Analysis (далее RCA) иподелиться опытом его применения для предотвращения багов.

В сети очень много информации по RCA, потому не хочу повторяться в отношении теории. Если Вы еще не использовали Problem-solving техники и, в частности, RCA, рекомендую ознакомиться с материалами по ссылками ниже, а уже затем переходить к статье:

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

Кейс первый ополитиках

Вливной enterprise-системе на200+ пользователей все было хорошо: жили нетужили, работали три года после релиза. Новодин прекрасный день при попытке перейти поссылке всистему вместо желаемого результата пользователей ждало угрожающее сообщение

Аналог сообщения, которое увидели пользователи. Оригинал несохранился :) Источник:Bytebitebit

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

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

Почему пользователи видят эту страницу?
Посмотрим А-а, так это заэкспайрился SSL-сертификат, продлим, ивсе будет впорядке.
Апочему это несделали заранее?
Никто непоставил напоминание, атри года быстро пролетели.
Резонно. Как думаете, почему непоставили?
Хм, по-моему, это первый проект, где была потребность виспользовании SSL. Это уже после вас стали сертификаты покупать идругим.
Так это ивдругих системах может случиться?
Пожалуй, пойдем везде проверим, поставим напоминалки ивгайдлайны внутренних систем добавим, что надо незабывать это делать.

Витоге ошибку быстро исправили иработа возобновилась. Пользователей обняли, пообещали новых вкусных фичи, отдышавшись, пошли делать обещанное.

Что изэтого стоит вынести? Ответственные, те, кто знаком сметодами RCA иFive Whys, нетолько исправили ошибку, ноначали задавать вопросы, чтобы найти истинную причину. Как только это случилось, проблему превентивно закрыли везде, где она могла произойти, тоесть предотвратили баг безопасности вдругих системах. Косвенно это привело ктому, что вкомпании стали уделять еще больше внимания безопасности.

Кейс второй олюдях

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

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

  1. Менеджер задокументировал ключевые поинты разговора счеловеком названные импричины.

  2. Предположил варианты сосвоего опыта.

  3. Собрал доказательства существованию причин, проанализировал.

  4. Попытался связать разные причины водну систему, поскольку редко бывает так, чтобы причина была только вчем-то одном.

Граф причин проблемы, воссозданный сослов рассказчика

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

  1. Сначала человек стал засиживаться вофисе после работы почти каждый день.

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

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

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

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

Кейс третий оработе стребованиями

Когда БАвходит впроект, который идет уже некоторое время, первая задача разобраться стребованиями, тоесть провести аудит. Обэтом кейсе яделалдоклад наNIX Multiconfв2019году. Сегодня раскрою некоторые детали того случая сточки зрения применения RCA: как искали причины того, почему впроекте начало появляться много багов.

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

Коммуникация

Невозможно было найти ответ или решение через время. Обсуждение требований велось вAsana, Slack, JIRA, через почту, вонлайн- иофлайн-документах. Среди всех источников небыло единого:

  • клиент писал там, где ему было удобно втекущий момент;

  • остальные команды неподдержали нашу критику, поскольку имитак норм;

  • бюджет наведение SRS, митинг-минуток иструктурирование информации невыделялся.

Наша команда неполучала ответов вовремя. Другие команды непонимали наших вопросов:

  • трудности перевода;

  • если непинговать, томогли забы(и)вать нам ответить;

  • пинговать из-за большой разницы сдвумя другими таймзонами было затруднительно.

Стейкхолдеры

Наша команда получала разную информацию изразных источников.

Небыло обмена решениями сдругими командами:

  • небыло четких зон ответственности вплане шаринга информации;

  • структурированные минутки исинки команд требовали времени, которое нехотели выделять.

Клиент часто менял требования/ принимал решения. Настолько часто, что одна команда успевала получить одно, авторая уже другое:

  • уклиента небыло четкой бизнес-идеи, онстарался быстро адаптироваться под нужды целевой аудитории;

  • клиент хотел реализовать как можно больше фич, невзирая наобщий концепт приложения, атакже удовлетворить всех пользователей;

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

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

Недожидаясь правок понескольким десяткам других пунктов, ЛПРы состороны команды реорганизовали перечень каналов связи иоставили всего три: обсуждение идей велось вAsana, дизайна итребований всоответствующих каналах Slack, тамже создали канал для общих вопросов. Кроме того, все решения покаждой функции стали фиксировать вJIRA, куда перевели только тетаски, которые должны были идти вразработку. Вдополнение ввели жесткие правила понеизменности скоупа врамках спринта (либо полной приостановке ипланированию спринта снуля) идлительности спринта.

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

Ичто?

Есть вещи, которые вот уже 8лет, смомента как явошел вIT, янеперестаю евангелизировать, поскольку нахожу имприменение либо вижу отражение вокружающем мире. Среди них философияпиши-сокращай, модель Кано, принцип Парето, think out ofthe box итак далее. Как выуже догадались, RCA входит вэтот перечень. Авсе потому, что важнейшая, если непервичная задачаБА заключается втом, чтобы понять почему. Будь топроблемная функция всистеме, ошибки вбизнес-процессах, нюансы человеческого поведения, негативные события вокруг все имеет глубокие корни.

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

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

Подробнее..

BAдайджест, февраль 2021 тренды на2021, чек-лист тестирования требований

21.03.2021 18:07:02 | Автор: admin

Всем привет! Встречайте дайджест ссамыми сочными статьями зафевраль.

Вскобках возле заголовков уровень сложности статьи (Normal * Hard Expert ***) ипримерное время наизучение материала

Business Analysis

6Trends Impacting Business Analysis toWatch in2021(*, 5мин). Тренды глазами Delvin Fletcher, President and Chief Executive Officer ofthe IIBA.

Круглый стол Эффективные техники для выявления требований(*, 30мин). Запись доклада Дениса Гобова дляanalyst.by, где были раскрыты такие темы, как Фреймворк процесса выявления требований, Модель Кано иеесвязь стехниками выявления, Классификация техник иКакие техники действительно используют бизнес-аналитики (результаты опросаБА вУкраине).

Уточняем детали проекта методами практической психологии(*, 6мин). Как информация (требования) искажаются при передаче между людьми ичто сэтим делать.

System Analysis Meetup 18/02 отRaiffeisenbank(**, 186мин). Обсуждали, как аналитик может влиять напроцессы вAgile-команде, как использование Agile снижает риски проекта (нонеисключает всех) икак изменилась роль аналитика после цифровой трансформации.

Аудит технчно документац: кому, навщо, як(*, 7мин). Ирина делится снами опытом проведения аудита ивнедрения его результатов.

Чек-лист тестирования требований(*, 11мин). Встатье разобраны основные критерии качества хороших требований напримерах изреальной жизни

Как мыиспользуем Confluence для разработки требований кпродукту(*, 8мин). Шикарная статья, вкоторой рассказывается оприменяемых подходах иплагинах. Очень рекомендую кпрочтению! Апредставленные плагины самый сок, без них жить очень непросто :)

AChecklist For Business Analysis Planning(*, 6мин). Опытный аналитик-ментор делится своим чек-листом для планирования бизнес-анализа.

Расширяем кругозор

Cheatsheet Differences Scrum vsScrumban vsKanban(*, 4мин). Освежаем впамяти основные различия между одними изсамых популярных методологий.

UI-элементы ижесты вмобильных приложениях(*, 3мин). Обзор сабжа сбольшим количеством примеров.

Never Forget aPassword Again(*, 12мин). Эссе, вкотором сделан обзор важности создания сильных паролей каккаунтам, оспособах взлома иметодах защиты.

Personas: AWaste OfMoney And Time(*, 7мин). Критика техники персон, что применять вместо нее икакие риски могут из-за этого выстрелить.

Three drawingsI use toexplain agile(*, 5мин). Отличная статья за2018-й,которая поможет быстро понять суть Agile, апотом показать его ценность клиенту.

How todiscover your customers willingness topay(**, 10мин). Если высделали классный продукт, показали его фокус-группе, которой онпонравился это еще незначит, что вызаработаете много денег. Это значит, что высделали что-то хорошее. Авот будутли заэто платить... Встатье рассматриваются подходы, которые должны помочь выудить изпотенциальных клиентов информацию отом, насколько ваш продукт для них ценен иготовыли они (исколько) платить.

UI-элементы ижесты вмобильных приложениях What does afterUX even mean?(*, 5мин). Абсолютно шикарная статья, которая показывает, как может быть вреден необдуманный UX-design, если слепо повторять паттерны.

The Homer Principle(*, 6мин). Юмористическая ижизненная статья отом, счем придется столкнуться при разработке продукта вконтексте восприятия продукта конечными пользователями. Напримере Гомера Симпсона автор вывел 6принципов, скоторым нужно будет работать.

Почему, чтобы переместить кнопку, нужно две недели(*, 5мин). Навесьма простом примере показано, как впростые запросы вреальности оказываются весьма нетривиальными. Можно взять пример заоснову ипользоваться вследующий раз (применяя квашему случаю), когда клиент удивляется, почему так долго.

Product Owner vs. Business Analyst Demystifying the similarities and the differences(*, 11мин). Годнота изблога Adaptive US одного изпровайдеров обучения для сдачи экзаменов IIBA.

Нюансы общения ванглоязычной среде. Часть первая.(*, 5мин). Прокачиваем софт скилы вместе сбизнес-аналитиком, живущей вВеликобритании изнающей подноготную коммуникации сносителями языка.

Building User Trust InUXDesign(***, 19мин). Статья отом, как провести пользователя отэтапа яовас инеслышал, кто вытакие дообоже, яхочу пользоваться вашим продуктом всю жизнь! спомощью понимания пользователя инекоторых маркетинговых уловок.

Material Design Text Fields Are Badly Designed(*, 6мин). Пост критики (обоснованной, намой взгляд) material design.

State OfGDPR In2021: Key Updates And What They Mean(**, 20мин). Изменения вGDPR икак теперь сэтим жить.

Подробнее..

BAдайджест, апрель 2021 тестирование требований, непрерывная discovery-фаза

08.05.2021 20:10:07 | Автор: admin

Всем привет! Встречайте свежий дайджест ссамыми сочными статьями заапрель.

Вскобках возле заголовков уровень сложности статьи (Normal * Hard ** Expert ***) ипримерное время наизучение материала.

Business Analysis

Тестирование требований: как янахожу ошибки вбизнес-логике фичи прежде, чем ихзакодят(*, 16мин). Авторка делится опытом тестирования требований через применение Use Case Scenarios.

Product Discovery IsAMindset, Not AProcess(**, 8мин). Автор поясняет, почему непрерывная Discovery-фаза (которая незаканчивается состартом проекта) залог успеха.

Requirements for Implementing Packaged Solutions(**, 6мин). Дедушка Вигерс продолжает нас радовать! Вэтот раз онподелился подходом копределению требований при выборе коробочных решений.

Локализация (адаптация) продукта для работы вновых регионах(*, 6мин). Авторка делится своим опытом поразработке требований клокализации решений напримерах продуктов E-commerce.

Нюансы общения ванглоязычной среде. Часть вторая: small talk(*, 6мин). Продолжение статьи, окоторой упоминалвпрошлом дайджесте. Впродолжении тематики культуры беседы, вовторой части авторка рассказывает обопыте применения small talk.

Что такое бизнес-анализ. Разрушаем мифы оработе BA(*, 11мин). Интересная подборка иразнос самых популярных заблуждений ороли ВА.

Новое как старое. Как провести успешный User Acceptance Testing для Reverse Engineering проекта(**, 12мин). Авторка делится вызовами иопытом работы впроектах пореализации NFR (Functionality) при переносе старой функциональности вновый продукт.

Масштабный проект повнедрению SAP S/4HANA вудаленном режиме: уроки, которые мыусвоили(***, 10мин). Внедрение продуктов, тем более таких крупных как SAP, работа спользователями дело крайне сложное. Вам мало? Добавьте кэтому удаленку! Статья отом, скакими проблемами столкнулись внедряторы икак ихрешали.

Как выбрать уровень статистической значимости для AB-теста икак интерпретировать результат(**, 12мин). Напримерах автор подробно рассматривает результаты различных A/B тестирований икак ихправильно интерпретировать.

Расширяем кругозор

SCRUM: Понимание иприменение фреймворка,часть 1(**, 15мин)ичасть 2(**, 12мин). Автор предлагает формализованный подход для оценки зрелости команды/ компании при внедрении SCRUM. Как минимум это свежий взгляд наиспользование методологии, как максимум потенциально зрелый подход квнедрению. Нужно тестить :)

The Search Before the Search: Keyword Foraging(*, 5мин). Бывалоли увас так, что прежде чем что-либо загуглить, выгуглили как это называется? Еслида, тостатья познакомит вас стермином keyword foraging, который объясняет это явление.

Bringing product thinking toany team(**, 8мин). Статья отом, как ставить потребности пользователей вцентр внимания. Автор делится опытом применения продуктового мышления для оптимизации работы команды навсех этапах проекта.

Comprehensive anatomy ofall Design Thinking workshops(*, 16мин). Встатье рассмотрены наиболее популярные виды воркшопов для создания хорошего UI/UXс применением дизайн-мышления.

IsYour UIMessy? 7Common Mistakes toAvoid(*, 12мин). Автор подробно рассказывает отом, почему нельзя игнорировать мелкие детали, как избежать грязи впользовательском интерфейсе исделать UXкомфортнее.

10Psychological rulesI used tomake users love atfirst sight(**, 8мин). Автор делится рядом подходов, которые ониспользует для расположения пользователей кпродукту навербально-психологическом уровне.

Аунас нет мышей! Амызаведём... Какая польза отархитектора решений(*, 9мин). Обзор роли архитектора решений изачем эта роль нужна.

Designing toreduce the users mental burden(*, 7мин). Хороший продукт невынуждает пользователей думать отом, как импользоваться. Карл Вигерс приводит примеры когда мелкая недоработка создает лишнюю умственную нагрузку ивызывает дискомфорт.

How ToBake Layers OfAccessibility Testing Into Your Process(**, 15мин). Accessibility-эксперты делятся опытом внедрения accessibility-тестирования впроцесс разработки цифровых продуктов.

Introducing FigJam(*, 4мин). Обзор новой коллаборативной фичи для Figma отразработчика инструмента.

Best practice for date-of-birth form fields(*, 6мин). Разбор наиболее удачных, помнению автора, паттернов реализации поля date ofbirth.

Designing for the autistic community(*, 7мин). Вовремя создания продукта, мыпомним обособенностях портрета пользователя, который заточен под большинство наших юзеров. При этом, нередко мызабываем пользователях сособыми потребностями. Встатье авторка описывает принципы создания интерфейсов сфокусом налюдей срасстройствами аутистического спектра.

Designing for Dyslexia(*, 5мин). Вкопилочку кпредыдущей статье как вразработке интерфейса учесть потребности пользователей, страдающих дислексией.

10Figma Tricks IWish IKnew Earlier(*, 4мин). Подборка хаков Figma окоторыхвы, возможно, неслышали.

The UI& UXtips collection,часть 1(*, 14мин)ичасть 2(*, 9мин). Шикарная подборка из34 + 18советов посабжу.

Этический антидизайн: как разработать продукт, невызывающий привыкания(*, 10мин). Антидизайн средство для защиты отдурака инетолько.

Best Practices For Modal Window Design(*, 9мин). Автор делится 9незамысловатыми принципами для оптимизации проектирования модальных окон.

Ближайшие события, курсы

13мая состоится бесплатный вебинарUI/UXMeetUp. Порядок тем заинтересует всех, отджуна долида. Намитапе выузнаете офундаментальной теории близости винтерфейсах, какие скилы нужны чтобы активно расти дизайнеру, атакже сюрприз вкачестве секретного спикера. Аналитикам будет полезно для расширения кругозора всфере прототипирования.

19мая состоится бесплатная онлайн-лекцияBA&UX: взаимодействие сускорением. Входе лекции выузнаете рекомендации для построения дизайн-процесса, атакже отехниках BA&UX.

29мая состоится платная конференция для бизнес-аналитиков. Вас ждут доклады 6спикеров изУкраины иЛатвии, скоторыми высможете коммуницировать иполезно провести время вкругу коллег.

Подробнее..

BAдайджест, май 2021 подкаст сКарлом Вигерсом, Docs asCode

18.06.2021 00:22:38 | Автор: admin

Всем привет! Встречайте свежий дайджест ссамыми сочными статьями замай.

Вскобках возле заголовков уровень сложности статьи (Normal * Hard ** Expert ***) ипримерное время наизучение материала

Business Analysis

Подкаст. MBA220: Thoughtless Design with Karl Wiegers(**, 32мин). Карл Вигерс продолжает радовать нас своим опытом. Вэтот раз онделится принципами иуроками, которые извлек изнекачественного дизайна, атакже рассказывает, чтоВы можете сделать, чтобы помочь всоздании дизайна.

Нужнали сертификация для бизнес-аналитика?(**, 10мин). Все осертификацииВА: список популярных, какие преимущества каждая даёт инужнали сертификация вообще.

Docs asCode: введение впредмет(**, 21мин). Автор делится многолетним опытом, приобретенным напути кDocs asCode, атакже рекомендациями повнедрению этого фреймворка.

Business Analyst: Tools and Principles for Professional Self-Development(*, 16мин). Структурированный набор материалов, который поможет обнаружить изаполнить пробелы всвоих навыках. Статью готовил аналитик с15+лет опыта, всоавторстве сдругими опытными БА.

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

User Experience inProduct(*, 8мин). Как исследования ианализ пользователей помогут увеличить значимость вашего продукта для конечных пользователей.

Моделирование данных: обзор(**, 6мин). Встатье автор раскрывает понятие моделирование данных, атакже делится оптимальной пошаговой инструкцией поприменению.

Цикл статей про бизнес-анализ напресейле. Статья первая, или почему всем нужен БА?(*, 5мин). Старт цикла статей ороли изадачах бизнес-аналитика напресейле. Впервой части: что такое пресейл, роль ивлияние бизнес-аналитика наэтом этапе, артефакты, которые могут понадобиться.

Расширяем кругозор

Этический антидизайн. Разработка продуктов, которые невызывают привыкания(*, 6мин). Оглавных принципах антидизайна, атакже когнитивных искажениях, которые располагают кзалипанию набесполезной/произвольной информации.

SCRUM: Гибкое управление продуктовыми направлениями(*, 9мин). Третья часть изцикла статей, окотором говорил впрошлом дайджесте. Вэтой части предложена система метрик для измерения ианализа процесса гибкого управления продуктовыми направлениями.

Frustrating Design Patterns That Need Fixing: Birthday Picker(*, 16мин). Подробный обзор неудачных шаблонов проектирования поля для выбора даты рождения.

Как работать сбэклогом иприоритизацией фич взрелом продукте(*, 8мин). CTO одной изпродуктовых компаний делится опытом приоритезации фич врамках канбан-процесса.

Three Levels ofPain Points inCustomer Experience(*, 8мин). Что такое болевые точки вклиентском опыте, накаких уровнях взаимодействия возникают ипонять какие наиболее критичны.

Left-Side Vertical Navigation onDesktop: Scalable, Responsive, and Easy toScan(*, 12мин). Статья овесьма непривычном подходе кпостроению навигации, когда она находится невшапке сайта, анаместе левой боковой панели: каким доменам подходит, преимущества ирекомендации поиспользованию.

Все, что выхотели знать про диалоговый UX/UIв проектировании чат-ботов(*, 9мин). Встатье покрыто определение диалогового UX/UI-дизайн, есть пошаговые рекомендации счего начать, атакже годные лайфхаки для проектирования сценариев для чат-бота.

Какие рефералки работают: сбонусами для себя, для того парня или для обоих? Исследование(*, 4мин). Саммари исследования видов рефералок.

The role ofpassword verification atsign up(*, 7мин). Анализ практик реализации поля ввода пароля.

UX-Roadmapping Workshops: Agenda + Activities(**, 16мин). Содержательная статья осоздании дорожных карт UX.

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

UI& UXmicro-tips: Volume five(*, 4мин). Коллекция небольших, нополезных подсказок поUI/UX.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru