Как это понимать?
#опыт #мысливслух #субботнее
Термины, которые используются в предметной области - это важная часть контекста, в котором проектируется продукт. Чем лучше понимаешь контекст продукта, тем лучше справляешься с его терминологией и наоборот - чем лучше понимаешь термины, тем больше приближаешься к пониманию контекста.
Мне всегда было интересно наблюдать, что так же как есть «ложные друзья переводчика», то есть слова схожие по звучанию, но отличающиеся по смыслу в разных языках, так же есть и «ложные друзья аналитика». Я имею в виду термины, значения которых могут значительно различаться в зависимости от предметной области.
Само слово «требование» одно из таких и его лучше уточнять, когда оказываетесь на новом рабочем месте. Где-то за этим кроется документ конкретного вида, где-то любое бизнес-правило, а где-то вам скажут «у нас пользовательские истории и никаких требований у нас нет».
Есть слово «клиент», которое в разном контексте приобретает разные оттенки. Для юриста это человек, с которым заключен договор, а операционист может так назвать любого обратившегося по какому-либо вопросу. Фраза «оформить профиль клиента» может означать и «внести данные договора в систему» и «внести данные нового потенциального клиента» в зависимости от того, кто ее произносит. При проектировании системы это может быть важным различием и есть риск понять разницу только после внедрения, если не уточнить значение термина.
Под этим постом Quiz, который показывает еще один хитрый термин. Как бы вы его «перевели»?
#опыт #мысливслух #субботнее
Термины, которые используются в предметной области - это важная часть контекста, в котором проектируется продукт. Чем лучше понимаешь контекст продукта, тем лучше справляешься с его терминологией и наоборот - чем лучше понимаешь термины, тем больше приближаешься к пониманию контекста.
Мне всегда было интересно наблюдать, что так же как есть «ложные друзья переводчика», то есть слова схожие по звучанию, но отличающиеся по смыслу в разных языках, так же есть и «ложные друзья аналитика». Я имею в виду термины, значения которых могут значительно различаться в зависимости от предметной области.
Само слово «требование» одно из таких и его лучше уточнять, когда оказываетесь на новом рабочем месте. Где-то за этим кроется документ конкретного вида, где-то любое бизнес-правило, а где-то вам скажут «у нас пользовательские истории и никаких требований у нас нет».
Есть слово «клиент», которое в разном контексте приобретает разные оттенки. Для юриста это человек, с которым заключен договор, а операционист может так назвать любого обратившегося по какому-либо вопросу. Фраза «оформить профиль клиента» может означать и «внести данные договора в систему» и «внести данные нового потенциального клиента» в зависимости от того, кто ее произносит. При проектировании системы это может быть важным различием и есть риск понять разницу только после внедрения, если не уточнить значение термина.
Под этим постом Quiz, который показывает еще один хитрый термин. Как бы вы его «перевели»?
Что может означать термин «ID клиента» в контексте работы колл-центра?
Anonymous Quiz
58%
Уникальный номер клента в CRM системе
25%
UID записи клиента в БД
8%
Номер телефона клиента
0%
Серия и номер паспорта клиента
8%
Ничего из перечисленного
Как ID клиента оказался номером телефона и вдвое увеличил стоимость задачи
#кейс #опыт
Расшифрую ответ на субботнюю викторину...
В одной из групп на очном тренинге коллеги поделились историей проектирования экранной формы для колл-центра. Запрос заказчика звучал как «выведите на экран ID клиента». Когда вывели на экран идентификатор записи клиента, то оказалось, что заказчики имели в виду номер телефона.
Для участников ИТ-команд выглядит абсурдной ассоциация между «ID клиента» и «номер телефона». Часто к слову «идентификатор» прибавляется слово «уникальный», и так как номер телефона может меняться, он ни в коем случае не может уникально идентифицировать запись клиента. Это совершенно верно в контексте ИТ-решения.
Что если обратить внимание на данные экранных форм в решениях для колл-центров (Dialer системы)? Чаще всего на рабочем месте оператора колл-центра и при входящем звонке, и при исходящем обзвоне, единственная легко читаемая информация, на которую можно опереться — номер телефона. Если в таких системах есть интеграция с CRM, то могут быть подтянуты данные из договора клиента и его номер в реестрах компании, но это не всегда удобно, так как большинство списков на экране и в том числе окошко входящего звонка точно содержат номер телефона и не обязательно данные из CRM. Так возникает ситуация, когда оператор колл-центра значение номера телефона назовет «ID клиента», не вникая в нюансы уникального соответствия между клиентом и его номером телефона.
Когда аналитик впервые оказывается в предметной области, то он может решить, что термин имеет только одно вполне очевидное значение. Цена ошибки — двойная стоимость разработки. Выручают небольшие лайфхаки
📍если вы слышите термин впервые, проговорите его с заказчиком в явном виде, даже если думаете, что вам все понятно. Лучше показаться дотошным чудаком, чем заставлять команду переделывать функционал.
📍если проговорить не получается или ответ запутанный, то нарисуйте макет экрана, хотя бы в виде контуров на бумаге и на нем покажите пример отображения информации. Разница между UID и номером телефона будет явно заметна.
📍если макет не применим и речь не об экране, а о логике функционала, то на примере проговорите ожидаемую логику и/или покажите как вы понимаете пример данных до и после ее применения
#кейс #опыт
Расшифрую ответ на субботнюю викторину...
В одной из групп на очном тренинге коллеги поделились историей проектирования экранной формы для колл-центра. Запрос заказчика звучал как «выведите на экран ID клиента». Когда вывели на экран идентификатор записи клиента, то оказалось, что заказчики имели в виду номер телефона.
Для участников ИТ-команд выглядит абсурдной ассоциация между «ID клиента» и «номер телефона». Часто к слову «идентификатор» прибавляется слово «уникальный», и так как номер телефона может меняться, он ни в коем случае не может уникально идентифицировать запись клиента. Это совершенно верно в контексте ИТ-решения.
Что если обратить внимание на данные экранных форм в решениях для колл-центров (Dialer системы)? Чаще всего на рабочем месте оператора колл-центра и при входящем звонке, и при исходящем обзвоне, единственная легко читаемая информация, на которую можно опереться — номер телефона. Если в таких системах есть интеграция с CRM, то могут быть подтянуты данные из договора клиента и его номер в реестрах компании, но это не всегда удобно, так как большинство списков на экране и в том числе окошко входящего звонка точно содержат номер телефона и не обязательно данные из CRM. Так возникает ситуация, когда оператор колл-центра значение номера телефона назовет «ID клиента», не вникая в нюансы уникального соответствия между клиентом и его номером телефона.
Когда аналитик впервые оказывается в предметной области, то он может решить, что термин имеет только одно вполне очевидное значение. Цена ошибки — двойная стоимость разработки. Выручают небольшие лайфхаки
📍если вы слышите термин впервые, проговорите его с заказчиком в явном виде, даже если думаете, что вам все понятно. Лучше показаться дотошным чудаком, чем заставлять команду переделывать функционал.
📍если проговорить не получается или ответ запутанный, то нарисуйте макет экрана, хотя бы в виде контуров на бумаге и на нем покажите пример отображения информации. Разница между UID и номером телефона будет явно заметна.
📍если макет не применим и речь не об экране, а о логике функционала, то на примере проговорите ожидаемую логику и/или покажите как вы понимаете пример данных до и после ее применения
👍6
Научит ли эксперт по бизнес-анализу аналитике?
#мысливслух #что_почитать
Недавно я получила заявку через GetMentor от потенциального менти. В заявке запрос «изучить аналитику данных». Вот так на практике выплывают нюансы терминологии. Казалось бы много раз обсуждена разница между анализом и аналитикой, но все равно непонимания много. Люди приходят к специалисту в построении процессов и просят научить их BI. Когда слышу что-то вроде «Настя, что у нас с аналитикой?», очень хочется включить сарказм и ответить: «Откуда я могу знать, что у нас с дашбордами и данными?».
Можете представить, что были времена, когда ни системных аналитиков, ни аналитиков данных в индустрии не было явно выделено? И это всего-навсего лет 20 назад, когда я начинала работать. Было название «бизнес-аналитик», аналитики с таким названием и общались с заинтересованными сторонами, и составляли постановки задач на системном уровне. На тот момент это была новая дисциплина, по хайпу похожая на теперешний хайп вокруг роли владельца продукта. Довольно быстро пришло время, когда недостаточно знать название роли, чтобы понимать круг обязанностей, потому что требовался акцент на разные задачи и предметные области. Еще немного и аналитиков в ИТ стало больше двух видов.
При трудоустройстве по-прежнему обязательно нужно уточнять ожидания от роли, которую в компании называют «бизнес-аналитик». Разница только в том, что 15-20 лет назад это было новым и не всем понятным, а сегодня очень много вариантов может быть скрыто за одним и тем же названием. Думаю, не так важно назову я себя «бизнес-аналитик» или «эксперт в бизнес-анализе», все равно не удастся избежать путаницы. Были у вас забавные истории связанные с разницей между анализом и аналитикой?
Вот тут есть хорошая статья о разных видах аналитиков.
#мысливслух #что_почитать
Недавно я получила заявку через GetMentor от потенциального менти. В заявке запрос «изучить аналитику данных». Вот так на практике выплывают нюансы терминологии. Казалось бы много раз обсуждена разница между анализом и аналитикой, но все равно непонимания много. Люди приходят к специалисту в построении процессов и просят научить их BI. Когда слышу что-то вроде «Настя, что у нас с аналитикой?», очень хочется включить сарказм и ответить: «Откуда я могу знать, что у нас с дашбордами и данными?».
Можете представить, что были времена, когда ни системных аналитиков, ни аналитиков данных в индустрии не было явно выделено? И это всего-навсего лет 20 назад, когда я начинала работать. Было название «бизнес-аналитик», аналитики с таким названием и общались с заинтересованными сторонами, и составляли постановки задач на системном уровне. На тот момент это была новая дисциплина, по хайпу похожая на теперешний хайп вокруг роли владельца продукта. Довольно быстро пришло время, когда недостаточно знать название роли, чтобы понимать круг обязанностей, потому что требовался акцент на разные задачи и предметные области. Еще немного и аналитиков в ИТ стало больше двух видов.
При трудоустройстве по-прежнему обязательно нужно уточнять ожидания от роли, которую в компании называют «бизнес-аналитик». Разница только в том, что 15-20 лет назад это было новым и не всем понятным, а сегодня очень много вариантов может быть скрыто за одним и тем же названием. Думаю, не так важно назову я себя «бизнес-аналитик» или «эксперт в бизнес-анализе», все равно не удастся избежать путаницы. Были у вас забавные истории связанные с разницей между анализом и аналитикой?
Вот тут есть хорошая статья о разных видах аналитиков.
Хабр
Откуда есть пошла аналитика и что отличает DS, DA, BA и SA
Каждому из нас приходится принимать решения и иметь дело с их последствиями. Если речь идёт о бизнесе, то верный выбор может принести кругленькую сумму денег, а неверный — стоить целого состояния. Неудивительно, что сейчас в моде data-driven-подход, при котором…
🔥4😁1
Очень вредно не ездить на бал, когда ты этого заслуживаешь
#мысливслух #конференции
Сегодня еду на конференцию Analyst Days. Поделилась этим в офисе и услышала от коллеги что-то вроде: «И когда вы все находите время по конференциям ходить?». Меня эта фраза зацепила. Подумала как сформулировать причину и пришла к двум тезисам.
🕰Было время, когда я развивалась в профессии вдали от заметной профессиональной движухи. Мероприятий было мало и на них нужно было куда-то ехать, что не всегда получалось. Поэтому сейчас, когда всего много и есть возможность участвовать, бывает грустно пропустить, не пообщаться и не узнать как другие аналитики решают задачи, обобщают свой опыт, используют разные техники и т. п. Когда стало много форматов он-лайн, легко могла подняться в 4 утра, чтобы, например, подключиться к семинару Карла Вигерса. Видимо, это называется «синдром упущенных возможностей» :)
🗃Вы замечали, что чем быстрее решишь одну задачу, чем быстрее получишь следующую и не одну? Забавно, что получается замкнутый круг: чем больше нагрузился задачами — тем меньше учишься и общаешься — тем быстрее теряешь ценность как специалист и выгораешь — тем хуже решаешь задачи… Карета может превратиться в тыкву. Получается, что нужно отложить рутину и найти время на конференцию как раз для того, чтобы не выгореть и качественнее решать те самые задачи из-за которых нет времени ходить на конференции.
Нет зависимости от возраста и стажа, потому что новые инструменты и точки зрения появляются быстро, синьоры тоже многое теряют без постоянного профессионального общения и учебы. Вот только с опытом все больше информации на конференциях относится скорее к «повторению пройденного», чем к чему-то новому. Хотя это неплохо, понимаешь, что «пройденное» еще актуально.
Посмотрим, что будет в этот раз.
#мысливслух #конференции
Сегодня еду на конференцию Analyst Days. Поделилась этим в офисе и услышала от коллеги что-то вроде: «И когда вы все находите время по конференциям ходить?». Меня эта фраза зацепила. Подумала как сформулировать причину и пришла к двум тезисам.
🕰Было время, когда я развивалась в профессии вдали от заметной профессиональной движухи. Мероприятий было мало и на них нужно было куда-то ехать, что не всегда получалось. Поэтому сейчас, когда всего много и есть возможность участвовать, бывает грустно пропустить, не пообщаться и не узнать как другие аналитики решают задачи, обобщают свой опыт, используют разные техники и т. п. Когда стало много форматов он-лайн, легко могла подняться в 4 утра, чтобы, например, подключиться к семинару Карла Вигерса. Видимо, это называется «синдром упущенных возможностей» :)
🗃Вы замечали, что чем быстрее решишь одну задачу, чем быстрее получишь следующую и не одну? Забавно, что получается замкнутый круг: чем больше нагрузился задачами — тем меньше учишься и общаешься — тем быстрее теряешь ценность как специалист и выгораешь — тем хуже решаешь задачи… Карета может превратиться в тыкву. Получается, что нужно отложить рутину и найти время на конференцию как раз для того, чтобы не выгореть и качественнее решать те самые задачи из-за которых нет времени ходить на конференции.
Нет зависимости от возраста и стажа, потому что новые инструменты и точки зрения появляются быстро, синьоры тоже многое теряют без постоянного профессионального общения и учебы. Вот только с опытом все больше информации на конференциях относится скорее к «повторению пройденного», чем к чему-то новому. Хотя это неплохо, понимаешь, что «пройденное» еще актуально.
Посмотрим, что будет в этот раз.
🔥7❤3👍2
Analyst Days – 17, день первый
#конференции #analyst_days
Люблю слушать синьоров, не в смысле роли в корпорации, а мастеров в профессии, известных спикеров и авторов. В этот раз главным впечатлением был доклад Анатолия Левенчука Интеллект-стек для инженеров и менеджеров. Наблюдения, знания, опыт были поданы с такой энергией и провокацией, что 40 мин прошли на одном дыхании. Доклад о наборе знаний и практик мышления, которые требуются, чтобы проектировать и воплощать в реальность сложные системы вплоть до космических кораблей. Может ли аналитик построить космический корабль в сегодняшнем процессе работы с размытой ответственностью за решения?
В ИТ считают, что действия с моделью, как с куклой вуду, могут что-то менять в реальном мире. Переставил стрелки на схеме что-то поменялось? Умение отделить объекты модели и объекты реального мира определяет некий интеллект-стек, то есть мыслительные практики, которые мы используем, чтобы разобраться в реальном мире. Составляющие этого стека: системная инженерия, риторика, этика, эстетика, алгоритмика, логика, онтология, теория понятий, математика, физика, семантика...
Основные моменты мне откликнулись в докладе
📍Аналитик - это сложная роль. Исследуем, анализируем, но это не похоже на научные исследования, которые будут применены в промышленности. Предложенные решения проходят на следующий круг и зависят от решений менеджмента, который не имеет экспертизы в индустрии, а иногда и в предметной области
📍Чтобы строить сложные системы, не достаточно знать только инструменты вроде архитектурных принципов или нотаций… Нужно сочетание интеллекта и эрудиции. Например, одна из задач аналитика давать названия объектам предметной области. Как отделить объект от фона (контекста) и дать название, которое удастся не просто найти, но и удержать в использовании? Нужно, видимо, уметь больше, чем просто полистать словарь
Видео вчерашней конференции еще недоступны, поэтому поделюсь не менее провокационным докладом Системное мышление 2020 Анатолия Левенчука на Analyst Days-11
#конференции #analyst_days
Люблю слушать синьоров, не в смысле роли в корпорации, а мастеров в профессии, известных спикеров и авторов. В этот раз главным впечатлением был доклад Анатолия Левенчука Интеллект-стек для инженеров и менеджеров. Наблюдения, знания, опыт были поданы с такой энергией и провокацией, что 40 мин прошли на одном дыхании. Доклад о наборе знаний и практик мышления, которые требуются, чтобы проектировать и воплощать в реальность сложные системы вплоть до космических кораблей. Может ли аналитик построить космический корабль в сегодняшнем процессе работы с размытой ответственностью за решения?
В ИТ считают, что действия с моделью, как с куклой вуду, могут что-то менять в реальном мире. Переставил стрелки на схеме что-то поменялось? Умение отделить объекты модели и объекты реального мира определяет некий интеллект-стек, то есть мыслительные практики, которые мы используем, чтобы разобраться в реальном мире. Составляющие этого стека: системная инженерия, риторика, этика, эстетика, алгоритмика, логика, онтология, теория понятий, математика, физика, семантика...
Основные моменты мне откликнулись в докладе
📍Аналитик - это сложная роль. Исследуем, анализируем, но это не похоже на научные исследования, которые будут применены в промышленности. Предложенные решения проходят на следующий круг и зависят от решений менеджмента, который не имеет экспертизы в индустрии, а иногда и в предметной области
📍Чтобы строить сложные системы, не достаточно знать только инструменты вроде архитектурных принципов или нотаций… Нужно сочетание интеллекта и эрудиции. Например, одна из задач аналитика давать названия объектам предметной области. Как отделить объект от фона (контекста) и дать название, которое удастся не просто найти, но и удержать в использовании? Нужно, видимо, уметь больше, чем просто полистать словарь
Видео вчерашней конференции еще недоступны, поэтому поделюсь не менее провокационным докладом Системное мышление 2020 Анатолия Левенчука на Analyst Days-11
🔥3
Analyst Days – 17, день второй
#конференции #analyst_days
Второй день Analyst Days прошел для меня в докладах по теме discovery. Пользовательские исследования уже давно в сфере моих интересов, поэтому меня очень порадовало, что в программе не менее пяти докладов были на исследовательские темы. Однако discovery в контексте этих докладов - активность аналитика, в результате которой рождаются функциональные требования, определяется объем задач проекта и концепция дизайна. На продуктовых конференциях этот термин будет означать другое — поиск идей новых продуктов и точек роста для существующих.
Тема исследований, на мой взгляд, - это давняя и неизбежная зона развития для аналитиков всех видов. Пока еще такие доклады на Analyst Days оставляют ощущение нераскрытых вопросов, да и зрителей собирают меньше, чем доклады о docs as code или архитектуре. Пока еще приходится слышать много спорного:
📍мы провели интервью, где все вопросы были с вариантами ответов (получился опрос с затратами равными интервью и оценкой объема выборки под интервью, а не опрос)
📍 есть же какое-то исследование, что достаточно 5 интервью, так что мы провели их 5 (это о статье Якоба Нильсена, где говорится, что при итеративном проведении небольших частых юзабилити тестов достаточно 5 респондентов для каждой итерации, а вовсе не о том, что в общем случае этого достаточно для любого исследования)
В целом время на конференции прошло продуктивно и душевно. Наверное, самое важное профессиональных мероприятиях - именно атмосфера психологической безопасности, понимание, что здесь собрались люди из смежных профессиональных областей и настроены на общение и обмен информацией. Даже в очереди в гардероб после закрытия было интересно постоять, потому что в ней обсуждались впечатления от докладов 😉
#конференции #analyst_days
Второй день Analyst Days прошел для меня в докладах по теме discovery. Пользовательские исследования уже давно в сфере моих интересов, поэтому меня очень порадовало, что в программе не менее пяти докладов были на исследовательские темы. Однако discovery в контексте этих докладов - активность аналитика, в результате которой рождаются функциональные требования, определяется объем задач проекта и концепция дизайна. На продуктовых конференциях этот термин будет означать другое — поиск идей новых продуктов и точек роста для существующих.
Тема исследований, на мой взгляд, - это давняя и неизбежная зона развития для аналитиков всех видов. Пока еще такие доклады на Analyst Days оставляют ощущение нераскрытых вопросов, да и зрителей собирают меньше, чем доклады о docs as code или архитектуре. Пока еще приходится слышать много спорного:
📍мы провели интервью, где все вопросы были с вариантами ответов (получился опрос с затратами равными интервью и оценкой объема выборки под интервью, а не опрос)
📍 есть же какое-то исследование, что достаточно 5 интервью, так что мы провели их 5 (это о статье Якоба Нильсена, где говорится, что при итеративном проведении небольших частых юзабилити тестов достаточно 5 респондентов для каждой итерации, а вовсе не о том, что в общем случае этого достаточно для любого исследования)
В целом время на конференции прошло продуктивно и душевно. Наверное, самое важное профессиональных мероприятиях - именно атмосфера психологической безопасности, понимание, что здесь собрались люди из смежных профессиональных областей и настроены на общение и обмен информацией. Даже в очереди в гардероб после закрытия было интересно постоять, потому что в ней обсуждались впечатления от докладов 😉
🔥2
Подборка статей о User Story
#что_почитать
В этот раз разбор тематических блогов принес несколько статей о пользовательских историях (ENG)
📍Шаблон User Story: Что это и почему он хорошо работает? Статья в блоге Майка Кона. Рассуждения о том чем хорош и какие имеет варианты стандартный шаблон записи из трех элементов «кто», «хочет что», «чтобы что»
📍Нефункциональные требования как пользовательские истории Еще одна статья Майка Кона. О том, что нефункциональные требования хорошо ложатся в стандартный шаблон истории и такой шаблон позволяет не забыть почему это требование появилось. Из всех примеров, на мой вкус странно выглядит только история вида «Как человек, говорящий на японском языке, я, возможно, когда-нибудь захочу запустить ваше программное обеспечение»
📍Составить критерии приемки как профи Красочная статья с примерами критериев приемки. «Красочная» - это буквально, с разноцветными картинками и художественным сравнением пользовательской истории с эскизом художника, а критериев приемки с красками.
#что_почитать
В этот раз разбор тематических блогов принес несколько статей о пользовательских историях (ENG)
📍Шаблон User Story: Что это и почему он хорошо работает? Статья в блоге Майка Кона. Рассуждения о том чем хорош и какие имеет варианты стандартный шаблон записи из трех элементов «кто», «хочет что», «чтобы что»
📍Нефункциональные требования как пользовательские истории Еще одна статья Майка Кона. О том, что нефункциональные требования хорошо ложатся в стандартный шаблон истории и такой шаблон позволяет не забыть почему это требование появилось. Из всех примеров, на мой вкус странно выглядит только история вида «Как человек, говорящий на японском языке, я, возможно, когда-нибудь захочу запустить ваше программное обеспечение»
📍Составить критерии приемки как профи Красочная статья с примерами критериев приемки. «Красочная» - это буквально, с разноцветными картинками и художественным сравнением пользовательской истории с эскизом художника, а критериев приемки с красками.
👍2😁1
Что получится, если скрестить компьютер с фотокамерой?
#книжки #кейс #что_почитать
У меня сегодня получился пост состоящий из кучи вопросов и одной загадки, потому что решила рассказать о провокационной книге. Ее сначала не было в мое плане публикаций, но как только о ней вспомнила уже не смогла не поделиться.
Книга Алана Купера «Психбольница в руках пациентов» сейчас чуть менее популярна, чем 5-10 лет назад. Понятно, что книга написана в 2004 году и примеры интерфейсов устарели. Большинство уже не помнят окошек Windows’95. Тем более удивительно, что не теряют актуальности сами идеи о различиях между проектированием ради функциональности и проектированием для людей. Это книга о разнице подходов в проектировании продуктов с точки зрения проектировщика-дизайнера и проектировщика-программиста. Рассуждение о том, что продукты оказались перегружены функциями не нужными их пользователям и почему так получается. В заголовок этого поста я вынесла название одной из глав книги. Как, думаете, что получится, если скрестить компьютер с фотокамерой?
Далеко не все хорошо оценивают эту книгу. Наверное потому, что автор высказывается провокационно и много рассуждает о точке зрения программистов на проектирование продукта. Достаточно взглянуть на оглавление с названиями разделов «Программисты пожертвуют простотой ради контроля», «Программисты сосредотачиваются на исключительных ситуациях» или «Программисты ведут себя прямолинейно».
В книге есть задачка для подтверждения тезиса, что не все свойства продукта можно описать перечислением его функций без описания целей пользователя. Описан продукт с помощью перечня функций и этот продукт имеет:
📍двигатель внутреннего сгорания;
📍четыре колеса с резиновыми покрышками;
📍трансмиссию, связывающую двигатель с ведущими колесами;
📍трансмиссию и двигатель смонтированные на ходовой части;
📍рулевое колесо.
Напишите в комментариях, о каком продукте речь? Завтра напишу ответ из текста книги.
#книжки #кейс #что_почитать
У меня сегодня получился пост состоящий из кучи вопросов и одной загадки, потому что решила рассказать о провокационной книге. Ее сначала не было в мое плане публикаций, но как только о ней вспомнила уже не смогла не поделиться.
Книга Алана Купера «Психбольница в руках пациентов» сейчас чуть менее популярна, чем 5-10 лет назад. Понятно, что книга написана в 2004 году и примеры интерфейсов устарели. Большинство уже не помнят окошек Windows’95. Тем более удивительно, что не теряют актуальности сами идеи о различиях между проектированием ради функциональности и проектированием для людей. Это книга о разнице подходов в проектировании продуктов с точки зрения проектировщика-дизайнера и проектировщика-программиста. Рассуждение о том, что продукты оказались перегружены функциями не нужными их пользователям и почему так получается. В заголовок этого поста я вынесла название одной из глав книги. Как, думаете, что получится, если скрестить компьютер с фотокамерой?
Далеко не все хорошо оценивают эту книгу. Наверное потому, что автор высказывается провокационно и много рассуждает о точке зрения программистов на проектирование продукта. Достаточно взглянуть на оглавление с названиями разделов «Программисты пожертвуют простотой ради контроля», «Программисты сосредотачиваются на исключительных ситуациях» или «Программисты ведут себя прямолинейно».
В книге есть задачка для подтверждения тезиса, что не все свойства продукта можно описать перечислением его функций без описания целей пользователя. Описан продукт с помощью перечня функций и этот продукт имеет:
📍двигатель внутреннего сгорания;
📍четыре колеса с резиновыми покрышками;
📍трансмиссию, связывающую двигатель с ведущими колесами;
📍трансмиссию и двигатель смонтированные на ходовой части;
📍рулевое колесо.
Напишите в комментариях, о каком продукте речь? Завтра напишу ответ из текста книги.
Задачи или функции?
#книжки #что_почитать
Продолжение предыдущего поста о книге Алана Купера «Психбольница в руках пациентов»…
📍Что получится, если скрестить компьютер с фотокамерой? Имеется в виду, что перегруженная функциями система перестает напрямую выполнять свои задачи, а превращается во что-то сложное. Будильник с кучей настроек для некоторых пользователей выглядит как компьютер, а не как удобный будильник. Может получиться, что не пользователь управляет будильником, а будильник пользователем...
От себя дополню. В работе аналитика это может проявляться, например, в виде запроса пользователя ”сделайте выгрузку этого в Excel”. Причины запроса могут быть разными и одна из вероятных — работа с записями в системе перегружена непонятными пользователю приемами управления данными, а он хочет сам управлять записями понятным ему способом. Нужно не только обучить пользователя, но и поискать функции, которые для него избыточны.
📍Кейс про функции и свойства продукта. В кейсе сначала перечислены функции продукта
• двигатель внутреннего сгорания
• четыре колеса с резиновыми покрышками
• трансмиссия, связывающая двигатель с ведущими колесами
• трансмиссия и двигатель смонтированы на ходовой части
• рулевое колесо.
Можно решить, что этот продукт — автомобиль, а после называются задачи продукта
• быстро и легко срезает траву
• на этом удобно сидеть.
Получается минитрактор-газонокосилка.
Я вспоминаю этот пример, когда думаю о документировании требований к функциональности. Не каждому разработчику понравится, если описание задачи перегружено описанием контекста. Разработчику удобнее видеть четкий перечень «что нужно сделать». Зато при изменении требований через пару месяцев, когда уже забыто зачем внедрялось изменение, вы сами будете рады найти информацию о целях и задачах заинтересованных сторон. Эта информация может помочь при тестировании запланировать тесты соответственно контексту. Поэтому при документировании приходится балансировать между описанием функций и задач.
#книжки #что_почитать
Продолжение предыдущего поста о книге Алана Купера «Психбольница в руках пациентов»…
📍Что получится, если скрестить компьютер с фотокамерой? Имеется в виду, что перегруженная функциями система перестает напрямую выполнять свои задачи, а превращается во что-то сложное. Будильник с кучей настроек для некоторых пользователей выглядит как компьютер, а не как удобный будильник. Может получиться, что не пользователь управляет будильником, а будильник пользователем...
От себя дополню. В работе аналитика это может проявляться, например, в виде запроса пользователя ”сделайте выгрузку этого в Excel”. Причины запроса могут быть разными и одна из вероятных — работа с записями в системе перегружена непонятными пользователю приемами управления данными, а он хочет сам управлять записями понятным ему способом. Нужно не только обучить пользователя, но и поискать функции, которые для него избыточны.
📍Кейс про функции и свойства продукта. В кейсе сначала перечислены функции продукта
• двигатель внутреннего сгорания
• четыре колеса с резиновыми покрышками
• трансмиссия, связывающая двигатель с ведущими колесами
• трансмиссия и двигатель смонтированы на ходовой части
• рулевое колесо.
Можно решить, что этот продукт — автомобиль, а после называются задачи продукта
• быстро и легко срезает траву
• на этом удобно сидеть.
Получается минитрактор-газонокосилка.
Я вспоминаю этот пример, когда думаю о документировании требований к функциональности. Не каждому разработчику понравится, если описание задачи перегружено описанием контекста. Разработчику удобнее видеть четкий перечень «что нужно сделать». Зато при изменении требований через пару месяцев, когда уже забыто зачем внедрялось изменение, вы сами будете рады найти информацию о целях и задачах заинтересованных сторон. Эта информация может помочь при тестировании запланировать тесты соответственно контексту. Поэтому при документировании приходится балансировать между описанием функций и задач.
👍2
«Да», «Нет» и «Зачем» не говорить?
#что_почитать
Сегодня выходной понедельник, как вы его проводите? В выходные проще найти время полистать статьи и блоги. Если вдруг и вы проводите час-другой за чтением, поделюсь тем, на что обратила внимание на этот раз.
📌50 слов самых опасных для бизнес-аналитика (ENG) В статье подобраны слова-индикаторы неопределенности и предлагается внимательно отлавливать их в разговоре с любыми заинтересованными сторонами. Например, список начинается с фразы «наиболее подходящий», которая ничего по сути не объясняет, а только вносит неопределенность. Кто решает что именно будет подходящим? На этапе проектирования и тем более разработки нужна более конкретная информация.
📌Всегда спрашивайте «Зачем»: пример из опыта (ENG) Автора попросили распечатать документ, поставить подпись, отсканировать и приложить скан в e-mail. Я так и не поняла, подписал ли он в итоге документ, зато выполнил и описал в статье разбор причин, которые могли привести к такому винтажному процессу. В итоге пришел к выводу, что если целью была безопасность, то она осталась недостигнутой.
⚙️Как построить контекстную диаграмму? (ENG) Нет это не о С4, но по смыслу инструмент похож на диаграмму контекста в модели С4. Статья о визуализации обмена данными между системами на концептуальном уровне, что может быть полезно при определении объема задачи.
Часть контента из этого канала превратилась в статьи
🔖Термины-хамелеоны (на Хабре) о неоднозначных терминах, которые могут обнаружиться в предметной области ИТ-задач.
🔖Как прокормить экспедицию? (кейс про заинтересованные стороны в Дзене) о выявлении заинтересованных сторон и какие вопросы-подсказки помогут никого не забыть.
#что_почитать
Сегодня выходной понедельник, как вы его проводите? В выходные проще найти время полистать статьи и блоги. Если вдруг и вы проводите час-другой за чтением, поделюсь тем, на что обратила внимание на этот раз.
📌50 слов самых опасных для бизнес-аналитика (ENG) В статье подобраны слова-индикаторы неопределенности и предлагается внимательно отлавливать их в разговоре с любыми заинтересованными сторонами. Например, список начинается с фразы «наиболее подходящий», которая ничего по сути не объясняет, а только вносит неопределенность. Кто решает что именно будет подходящим? На этапе проектирования и тем более разработки нужна более конкретная информация.
📌Всегда спрашивайте «Зачем»: пример из опыта (ENG) Автора попросили распечатать документ, поставить подпись, отсканировать и приложить скан в e-mail. Я так и не поняла, подписал ли он в итоге документ, зато выполнил и описал в статье разбор причин, которые могли привести к такому винтажному процессу. В итоге пришел к выводу, что если целью была безопасность, то она осталась недостигнутой.
⚙️Как построить контекстную диаграмму? (ENG) Нет это не о С4, но по смыслу инструмент похож на диаграмму контекста в модели С4. Статья о визуализации обмена данными между системами на концептуальном уровне, что может быть полезно при определении объема задачи.
🔖Термины-хамелеоны (на Хабре) о неоднозначных терминах, которые могут обнаружиться в предметной области ИТ-задач.
🔖Как прокормить экспедицию? (кейс про заинтересованные стороны в Дзене) о выявлении заинтересованных сторон и какие вопросы-подсказки помогут никого не забыть.
Масштабируемая структура требований
#что_почитать
В выходные было время почитать и встретилась статья, которой хочу поделиться. Это обзор статьи, оригинал по ссылке Splitting Requirements at Scale.
Анализ подразумевает разбивку сложных проблем на более простые, но иногда такая структура выглядит как клубок взаимных зависимостей между ее элементами. По мере расширения процесса такие структуры становятся все сложнее. Как разбить отдельные требования для сложных процессов? В статье приведены примеры подходов к структуре требований.
Пример он-лайн магазина. Шаги процесса могут иметь разные правила в зависимости от категорий товаров: для заказа одежды нужно выбрать размер и цвет, для заказа продуктов нужно указать вес, для заказа напитков нужно указать объем и количество. Так в трех направлениях могут быть разбиты требования. Если предположить, что магазин решит развивать и В2В, и В2С продажи, то вариантов правил для каждого вида заказов становится больше, в каждой категории товаров добавляется два вида сделок, по одному для каждого сегмента клиентов. Структура требований усложнится. А какие еще можно рассмотреть варианты?
Снизу вверх и сверху вниз. Выявляются требования разных уровней и затем организуются в группы от общего к частному или от частного к общему. В таком случае эти группы либо повторяют порядок, в каком собирались требования (например, оргструктуру компании) или идут от процесса, к которому требования относятся, но процесс может быть очень большим и такие требования сложно передавать в разработку без дополнительной декомпозиции.
Разбивка в Agile. Здесь основная идея — любое требование разбивать на имеющие бизнес-ценность малые части для реализации за спринт. Подход отличный, но может теряться общая структура того, чего требуется в итоге достичь.
Иерархия требований. Этот подход автор описал как предпочтительный. Требования разбираются на уровни абстракции и образуют иерархию. Например: Уровень процесса, уровень пользователя и уровень системы. Каждый уровень должен представлять проблему или ценность на заданном уровне детализации. Верхние уровни задают контекст для нижних, а нижние детализируют родительские. Пример на картинке ниже. При этом сами требования можно нарезать по структуре организации или решения, а можно по логике процесса end-to-end, что предпочтительнее. Детальные шаги при этом оказываются на самом нижнем уровне
Вывод. Можно ли в реальности построить систему независимых атомарных требований, если зависимость заложена в самом процессе? Понятно, что для планирования разработки отсутствие зависимостей упрощает картину, но если без связей нельзя, то их нужно сделать понятными и построить структуру без скрытых требований. Нужно внимательно выбирать ключевые направления в области решаемых проблем, чтобы выбрать структуру требований, которая не усложняется по мере развития процесса.
#что_почитать
В выходные было время почитать и встретилась статья, которой хочу поделиться. Это обзор статьи, оригинал по ссылке Splitting Requirements at Scale.
Анализ подразумевает разбивку сложных проблем на более простые, но иногда такая структура выглядит как клубок взаимных зависимостей между ее элементами. По мере расширения процесса такие структуры становятся все сложнее. Как разбить отдельные требования для сложных процессов? В статье приведены примеры подходов к структуре требований.
Пример он-лайн магазина. Шаги процесса могут иметь разные правила в зависимости от категорий товаров: для заказа одежды нужно выбрать размер и цвет, для заказа продуктов нужно указать вес, для заказа напитков нужно указать объем и количество. Так в трех направлениях могут быть разбиты требования. Если предположить, что магазин решит развивать и В2В, и В2С продажи, то вариантов правил для каждого вида заказов становится больше, в каждой категории товаров добавляется два вида сделок, по одному для каждого сегмента клиентов. Структура требований усложнится. А какие еще можно рассмотреть варианты?
Снизу вверх и сверху вниз. Выявляются требования разных уровней и затем организуются в группы от общего к частному или от частного к общему. В таком случае эти группы либо повторяют порядок, в каком собирались требования (например, оргструктуру компании) или идут от процесса, к которому требования относятся, но процесс может быть очень большим и такие требования сложно передавать в разработку без дополнительной декомпозиции.
Разбивка в Agile. Здесь основная идея — любое требование разбивать на имеющие бизнес-ценность малые части для реализации за спринт. Подход отличный, но может теряться общая структура того, чего требуется в итоге достичь.
Иерархия требований. Этот подход автор описал как предпочтительный. Требования разбираются на уровни абстракции и образуют иерархию. Например: Уровень процесса, уровень пользователя и уровень системы. Каждый уровень должен представлять проблему или ценность на заданном уровне детализации. Верхние уровни задают контекст для нижних, а нижние детализируют родительские. Пример на картинке ниже. При этом сами требования можно нарезать по структуре организации или решения, а можно по логике процесса end-to-end, что предпочтительнее. Детальные шаги при этом оказываются на самом нижнем уровне
Вывод. Можно ли в реальности построить систему независимых атомарных требований, если зависимость заложена в самом процессе? Понятно, что для планирования разработки отсутствие зависимостей упрощает картину, но если без связей нельзя, то их нужно сделать понятными и построить структуру без скрытых требований. Нужно внимательно выбирать ключевые направления в области решаемых проблем, чтобы выбрать структуру требований, которая не усложняется по мере развития процесса.
👍1🤩1
Бэклог не может содержать все подряд
#agile #что_почитать
Некоторое время назад подписалась на рассылку от Майка Кона. Как большинство рассылок от профессиональных консультантов и блогеров она бОльшей частью содержит рекламу курсов, но есть письма, которые составлены в жанре «меня часто спрашивают». Такие рассылки оказались содержательными и я хочу поделиться с вами некоторыми текстами. Надеюсь, они вам тоже понравятся 🌱
_______
Бэклоги — это как десерт, с ними нужно иметь чувство меры. Слишком большой бэклог является признаком проблемы, так же как и очень большой кусок пирога с двумя ложками мороженого. Это относится как к бэклогу продукта, так и к бэклогу спринта. Размеры обоих должны быть в рамках разумного.
Бэклог спринта. Бэклог спринта может стать слишком громоздким, если участники команды начнут использовать его в качестве отстойника для собственных задач.
Например, мой коллега недавно готовил презентацию к конференции Scrum Gathering в Новом Орлеане в мае 2024 года. Эта работа важна для него и выгодна нашей компании, поэтому я ее поддерживаю, но она не включена в бэклог спринта, потому что никто кроме него ей не занимается. Просто один человек готовит презентацию и время от времени интересуется нашим мнением. Выполнение этой задачи не является общей целью, никто не скажет: «Он сегодня заболел, поэтому сегодня я поработаю над его презентацией».
Если другим участникам команды нужно знать про вашу работу, или они могут заменить вас в выполнении этой работы, тогда эту задачу можно включить в бэклог спринта, в ином случае, ей там не место.
Бэклог продукта. Бэклог продукта может стать слишком большим если в него включено слишком много незавершенных идей.
Будучи владельцем продукта, я не хочу забивать бэклог продукта, включая в него каждую идею, которая у меня появляется. Для этого я завожу другой список, тоже своего рода бэклог, который я называю накопителем. Идеи находятся в этом списке до тех пор, пока я либо не перемещу их в бэклог продукта, либо откажусь от них. Я не пытаюсь скрыть что-то от команды, помещая это в накопитель, я просто не хочу загружать кого-либо своими идеями, пока я их не обдумал. Это как новый рецепт Флоридского лаймового пирога. Я поместил его в закладки, но не внес его составляющие в список покупок. И когда я соберусь его приготовить, мне хватит одного кусочка!
Поддерживая бэклог спринта и бэклог продукта в разумных рамках, вам будет проще добиться успеха с Agile.
Оригинал тут (ссылка на Яндекс Диск).
#agile #что_почитать
Некоторое время назад подписалась на рассылку от Майка Кона. Как большинство рассылок от профессиональных консультантов и блогеров она бОльшей частью содержит рекламу курсов, но есть письма, которые составлены в жанре «меня часто спрашивают». Такие рассылки оказались содержательными и я хочу поделиться с вами некоторыми текстами. Надеюсь, они вам тоже понравятся 🌱
_______
Бэклоги — это как десерт, с ними нужно иметь чувство меры. Слишком большой бэклог является признаком проблемы, так же как и очень большой кусок пирога с двумя ложками мороженого. Это относится как к бэклогу продукта, так и к бэклогу спринта. Размеры обоих должны быть в рамках разумного.
Бэклог спринта. Бэклог спринта может стать слишком громоздким, если участники команды начнут использовать его в качестве отстойника для собственных задач.
Например, мой коллега недавно готовил презентацию к конференции Scrum Gathering в Новом Орлеане в мае 2024 года. Эта работа важна для него и выгодна нашей компании, поэтому я ее поддерживаю, но она не включена в бэклог спринта, потому что никто кроме него ей не занимается. Просто один человек готовит презентацию и время от времени интересуется нашим мнением. Выполнение этой задачи не является общей целью, никто не скажет: «Он сегодня заболел, поэтому сегодня я поработаю над его презентацией».
Если другим участникам команды нужно знать про вашу работу, или они могут заменить вас в выполнении этой работы, тогда эту задачу можно включить в бэклог спринта, в ином случае, ей там не место.
Бэклог продукта. Бэклог продукта может стать слишком большим если в него включено слишком много незавершенных идей.
Будучи владельцем продукта, я не хочу забивать бэклог продукта, включая в него каждую идею, которая у меня появляется. Для этого я завожу другой список, тоже своего рода бэклог, который я называю накопителем. Идеи находятся в этом списке до тех пор, пока я либо не перемещу их в бэклог продукта, либо откажусь от них. Я не пытаюсь скрыть что-то от команды, помещая это в накопитель, я просто не хочу загружать кого-либо своими идеями, пока я их не обдумал. Это как новый рецепт Флоридского лаймового пирога. Я поместил его в закладки, но не внес его составляющие в список покупок. И когда я соберусь его приготовить, мне хватит одного кусочка!
Поддерживая бэклог спринта и бэклог продукта в разумных рамках, вам будет проще добиться успеха с Agile.
Оригинал тут (ссылка на Яндекс Диск).
🤔2👍1
Пользовательские истории и нефункциональные требования
#кейс #agile #субботнее
В продолжение темы agile предлагаю порешать кейс про пользовательские истории. Вы наверняка помните самый распространенный шаблон для историй. В шаблоне есть три части «кто», «хочет что», «чтобы что». Чтобы соблюдать такой формат, важно выделить действующие роли и цели для каждой истории. Для нефункциональных требований это бывает непросто...
Ниже несколько формулировок пользовательских историй, выберите, какие на ваш взгляд лучше всего описывают участников и цели авторизации пользователей. Можно выбрать несколько вариантов. В понедельник поделюсь своим мнением.
#кейс #agile #субботнее
В продолжение темы agile предлагаю порешать кейс про пользовательские истории. Вы наверняка помните самый распространенный шаблон для историй. В шаблоне есть три части «кто», «хочет что», «чтобы что». Чтобы соблюдать такой формат, важно выделить действующие роли и цели для каждой истории. Для нефункциональных требований это бывает непросто...
Ниже несколько формулировок пользовательских историй, выберите, какие на ваш взгляд лучше всего описывают участников и цели авторизации пользователей. Можно выбрать несколько вариантов. В понедельник поделюсь своим мнением.
В приложении для он-лайн бронирования авиабилетов, только авторизованные пользователи могут оформить бронирование. Какие из пользовательских историй лучше всего соответствуют такому требованию?
Anonymous Poll
31%
Я, как пользователь хочу войти в Систему, чтобы быстрее перейти к бронированию
19%
Я, как Система хочу, чтобы указывались логин и пароль, чтобы правильно логировать все действия
47%
Я, как пользователь хочу иметь вход в Личный кабинет и хранить данные для заполнения полей в билете
44%
Я, как специалист по кибербезопасности хочу знать, кто имеет доступ к бронированию и перс.данным
8%
Посмотреть результаты
Одушевленные системы и неодушевленные пользователи
#мысливслух #кейс #agile
Субботний опрос я затеяла, чтобы обратить внимание на пару моментов в работе с пользовательскими историями. Как и обещала делюсь мыслями.
📍Я предложила для уже сформулированного свойства решения определить, кто в нем может быть заинтересован и для чего. Получилось, что к следствию нужно придумать причины. На практике это случается, хотя по сути не выглядит нормальным порядком вещей. Обычно именно в таких случаях получаются формулировки с одушевлением систем «Я, как Система хочу, чтобы пользователь указывал логин и пароль, чтобы правильно логировать действия пользователя» или формулировки, где пользователю присваивается неестественное поведение «Я, как пользователь хочу войти в Систему, чтобы быстрее перейти к бронированию». Если человек действительно хочет скорее перейти к бронированию, то ввод логина и пароля будет восприниматься как помеха, а не как ожидаемая функция.
📍Как любые другие нефункциональные требования, требования к авторизации относятся к системе в целом. При реализации большинства историй будет важно учесть, что заявленный «кто» должен быть авторизованным пользователем. Получается, что общие характеристики системы так или иначе должны учитываться в критериях приемки любой истории или любая история должна наследоваться от нефункциональной...Может получиться громоздкая и неочевидная структура.
Прежде чем формулировать нефункциональное требование в формате истории я бы посоветовала подумать как эта история будет использоваться командой? Формат отдельной истории для требования к авторизации полезен, только если действительно нужен вашей команде как элемент бэклога. Иначе такое требование лучше не маскировать под историю, а фиксировать вместе с другими нефункциональными требованиями короткой фразой. Например, «Доступ к функциям должен предоставляться на основании ролей пользователей и схемы разграничения прав доступа между ними». Будет достаточно сослаться на это требование из других историй и задач, где необходимо.
Возвращаясь к субботнему опросу скажу так… На мой взгляд, лучше всего показывают контекст требования истории вида «Я, как пользователь хочу иметь Личный кабинет, чтобы хранить данные для автоматического заполнения полей при бронировании» и «Я, как специалист по кибербезопасности хочу знать, кто имеет доступ к бронированию и перс.данным». При этом с точки зрения планирования разработки эти истории слишком крупные и их придется разбивать на более конкретные. Так что подумайте как такой формат будет работать именно в вашей команде?
#мысливслух #кейс #agile
Субботний опрос я затеяла, чтобы обратить внимание на пару моментов в работе с пользовательскими историями. Как и обещала делюсь мыслями.
📍Я предложила для уже сформулированного свойства решения определить, кто в нем может быть заинтересован и для чего. Получилось, что к следствию нужно придумать причины. На практике это случается, хотя по сути не выглядит нормальным порядком вещей. Обычно именно в таких случаях получаются формулировки с одушевлением систем «Я, как Система хочу, чтобы пользователь указывал логин и пароль, чтобы правильно логировать действия пользователя» или формулировки, где пользователю присваивается неестественное поведение «Я, как пользователь хочу войти в Систему, чтобы быстрее перейти к бронированию». Если человек действительно хочет скорее перейти к бронированию, то ввод логина и пароля будет восприниматься как помеха, а не как ожидаемая функция.
📍Как любые другие нефункциональные требования, требования к авторизации относятся к системе в целом. При реализации большинства историй будет важно учесть, что заявленный «кто» должен быть авторизованным пользователем. Получается, что общие характеристики системы так или иначе должны учитываться в критериях приемки любой истории или любая история должна наследоваться от нефункциональной...Может получиться громоздкая и неочевидная структура.
Прежде чем формулировать нефункциональное требование в формате истории я бы посоветовала подумать как эта история будет использоваться командой? Формат отдельной истории для требования к авторизации полезен, только если действительно нужен вашей команде как элемент бэклога. Иначе такое требование лучше не маскировать под историю, а фиксировать вместе с другими нефункциональными требованиями короткой фразой. Например, «Доступ к функциям должен предоставляться на основании ролей пользователей и схемы разграничения прав доступа между ними». Будет достаточно сослаться на это требование из других историй и задач, где необходимо.
Возвращаясь к субботнему опросу скажу так… На мой взгляд, лучше всего показывают контекст требования истории вида «Я, как пользователь хочу иметь Личный кабинет, чтобы хранить данные для автоматического заполнения полей при бронировании» и «Я, как специалист по кибербезопасности хочу знать, кто имеет доступ к бронированию и перс.данным». При этом с точки зрения планирования разработки эти истории слишком крупные и их придется разбивать на более конкретные. Так что подумайте как такой формат будет работать именно в вашей команде?
Написанное должно быть удобочитаемо
#мысливслух #что_почитать
В русском языке выделяют пять основных стилей:
• научный,
• официально-деловой,
• публицистический,
• разговорный,
• художественный
Как думаете, в каком стиле аналитики пишут свои документы? Наиболее последовательным, логичным и точным считается научный стиль. Его мы легко угадываем по монотонному звучанию, множеству терминов, пассивному залогу, сложным предложениям, обобщающим и вводным словам. Если все это служит, чтобы однозначно, логично и последовательно донести информацию, то в этом нет ничего плохого, хотя читается сложно.
Почему-то аналитики часто начинают смешивать научный стиль с офисно-деловым, самым консервативным. Там много устоявшихся клише, терминологии, отглагольных существительных, сложных предложений, официальных слов, бесконечных названий и аббревиатур. Получается совсем нечитаемые конструкции вида: «По окончании выполнения расчета регистрируется высокоприоритетная заявка». Видимо, авторы хотят таким образом сделать текст более внушительным. В итоге теряется однозначность информации, а чтение и без того сложного текста становится очень затратной задачей. Каждый канцеляризм в тексте превращает его в договор. Никто не любит читать договоры.
Реже бывают случаи, когда спецификации пытаются составлять в публицистическом, художественном или разговорном стиле. Тогда в тексте появляются эвфемизмы, обобщения и лирические отступления. Например, «В этот момент система решает вопрос отображения сообщения об ошибке. Не знаю, есть ли среди пользователей англичане, но сообщение нужно на английском». Предполагаю, что таким образом авторы хотят сделать чтение документа увлекательным. Действительно ли читатели технических документов готовы тратить время на художественные отступления?
Штампы и канцеляризмы из других текстов легко въедаются в стиль, которым пишут аналитики. От этого можно избавиться, если несколько раз вычитывать свои тексты, чтобы убирать из них лишнее, и помнить о целях и читателях.
📍По окончании выполнения расчета регистрируется высокоприоритетная заявка → После расчета система создает заявку с приоритетом «Высокий»
📍На данном этапе разработка приложения идёт по плану. → Разработка приложения идет по плану.
В дополнение хорошая статья про страдательный залог в технической документации
#мысливслух #что_почитать
В русском языке выделяют пять основных стилей:
• научный,
• официально-деловой,
• публицистический,
• разговорный,
• художественный
Как думаете, в каком стиле аналитики пишут свои документы? Наиболее последовательным, логичным и точным считается научный стиль. Его мы легко угадываем по монотонному звучанию, множеству терминов, пассивному залогу, сложным предложениям, обобщающим и вводным словам. Если все это служит, чтобы однозначно, логично и последовательно донести информацию, то в этом нет ничего плохого, хотя читается сложно.
Почему-то аналитики часто начинают смешивать научный стиль с офисно-деловым, самым консервативным. Там много устоявшихся клише, терминологии, отглагольных существительных, сложных предложений, официальных слов, бесконечных названий и аббревиатур. Получается совсем нечитаемые конструкции вида: «По окончании выполнения расчета регистрируется высокоприоритетная заявка». Видимо, авторы хотят таким образом сделать текст более внушительным. В итоге теряется однозначность информации, а чтение и без того сложного текста становится очень затратной задачей. Каждый канцеляризм в тексте превращает его в договор. Никто не любит читать договоры.
Реже бывают случаи, когда спецификации пытаются составлять в публицистическом, художественном или разговорном стиле. Тогда в тексте появляются эвфемизмы, обобщения и лирические отступления. Например, «В этот момент система решает вопрос отображения сообщения об ошибке. Не знаю, есть ли среди пользователей англичане, но сообщение нужно на английском». Предполагаю, что таким образом авторы хотят сделать чтение документа увлекательным. Действительно ли читатели технических документов готовы тратить время на художественные отступления?
Штампы и канцеляризмы из других текстов легко въедаются в стиль, которым пишут аналитики. От этого можно избавиться, если несколько раз вычитывать свои тексты, чтобы убирать из них лишнее, и помнить о целях и читателях.
📍По окончании выполнения расчета регистрируется высокоприоритетная заявка → После расчета система создает заявку с приоритетом «Высокий»
📍На данном этапе разработка приложения идёт по плану. → Разработка приложения идет по плану.
В дополнение хорошая статья про страдательный залог в технической документации
Хабр
«Кто на ком стоял?» Про страдательный залог в технической документации
В технической и пользовательской документации часто встречаются фразы с использованием страдательного залога. Параметры там «задаются», файлы «сохраняются», а программа «запускается». Ох, опасная эта...
🔥2
Иногда лучше потратить немножко времени, чтобы потом его сберечь
#мысливслух #кейс
Неделю назад я поучаствовала в разборе кейса про решение конфликтов. Постановка задачи затянула. Дано: тимлид команды разработки не видит ценности в работе аналитика и ведет разработку сам, без учета результатов анализа. Получается, что аналитик работает сам по себе, никто не ждет результатов его работы, разработка ведется параллельно. Аналитика не привлекают к решению открытых вопросов.
Подумала, что аналитик, особенно БА часто работает под скептическими взглядами «посмотрим, что ты нам скажешь, балабол». Я часто слышу что-то вроде: «И так же понятно, надо делать вот так и так, зачем тратить время на поиск чего-то и на документы». Обычно «так и так» оказывается видением картины с точки зрения ИТ-инженера, не отвечающим потребностям пользователей. Сделанное таким образом в 90% случаев приходится переделывать. При этом ситуация неочевидна для ее активных участников, зато заметно, что пока аналитик проводит какие-то непонятные исследования или проектирование, люди уже «что-то делают». Если в такой ситуации не отстаивать свои границы и не показывать ценность своей работы, то можно оказаться отрезанным от нужной информации и выглядеть странно в глазах команды и заказчиков. Поэтому нужны отличные навыки коммуникации и умение обосновывать ценность своей работы.
В случае с кейсом выводы оказались такими:
🔅Нужно оценить ситуацию с точки зрения влияния на бизнес, трудностей для себя, возможностей решения (например, эскалации или получения информации по задаче из других источников)
🔅Показать тимлиду проблемы с помощью обратной связи. В том числе обратить внимание на нарушение своих границ, в случае, если к вам относятся как к "балаболу"
🔅Оценить реакцию на обратную связь. Если столкнулись с отказом выслушать или неприятием, то пора эскалировать. Если удается донести ценность своей работы, то начинать договариваться о сотрудничестве в рамках общего процесса работы
#мысливслух #кейс
Неделю назад я поучаствовала в разборе кейса про решение конфликтов. Постановка задачи затянула. Дано: тимлид команды разработки не видит ценности в работе аналитика и ведет разработку сам, без учета результатов анализа. Получается, что аналитик работает сам по себе, никто не ждет результатов его работы, разработка ведется параллельно. Аналитика не привлекают к решению открытых вопросов.
Подумала, что аналитик, особенно БА часто работает под скептическими взглядами «посмотрим, что ты нам скажешь, балабол». Я часто слышу что-то вроде: «И так же понятно, надо делать вот так и так, зачем тратить время на поиск чего-то и на документы». Обычно «так и так» оказывается видением картины с точки зрения ИТ-инженера, не отвечающим потребностям пользователей. Сделанное таким образом в 90% случаев приходится переделывать. При этом ситуация неочевидна для ее активных участников, зато заметно, что пока аналитик проводит какие-то непонятные исследования или проектирование, люди уже «что-то делают». Если в такой ситуации не отстаивать свои границы и не показывать ценность своей работы, то можно оказаться отрезанным от нужной информации и выглядеть странно в глазах команды и заказчиков. Поэтому нужны отличные навыки коммуникации и умение обосновывать ценность своей работы.
В случае с кейсом выводы оказались такими:
🔅Нужно оценить ситуацию с точки зрения влияния на бизнес, трудностей для себя, возможностей решения (например, эскалации или получения информации по задаче из других источников)
🔅Показать тимлиду проблемы с помощью обратной связи. В том числе обратить внимание на нарушение своих границ, в случае, если к вам относятся как к "балаболу"
🔅Оценить реакцию на обратную связь. Если столкнулись с отказом выслушать или неприятием, то пора эскалировать. Если удается донести ценность своей работы, то начинать договариваться о сотрудничестве в рамках общего процесса работы
👍3
День рождения в октябре
#что_почитать #мысливслух #субботнее
Сегодня нашему уютному каналу ровно 2 месяца! За месяц нас стало в два раза больше. Стало больше прочтений, больше реакций, пересылок и комментариев. Пока еще я как ребенок радуюсь каждому комментарию и реакции — значит вы читаете и текст откликается.
Должна сказать, что обмен знаниями затягивает. Умение писать совсем легко пока еще не пришло, по-прежнему каждый пост перечитываю и корректирую. Зато стало интересно поделиться чем-то и ждать реакции читателей. Например, особенно интересно было рассказать о подмеченном на Analyst Days-17, причем рассказать сразу нескольким десяткам человек. Кстати, посты с тегом #analyst_days оказались в топ-5 по количеству просмотров.
Посмотрела какие публикации за 30 дней набрали больше просмотров, реакций и пересылок. Получилось так:
📍Очень вредно не ездить на бал, когда ты этого заслуживаешь
📍Итоги кейса про снабжение экспедиции
📍Почему не удалось с первой попытки найти приоритеты?
📍Подборка статей о User Story
📍Analyst Days – 17, день второй
#что_почитать #мысливслух #субботнее
Сегодня нашему уютному каналу ровно 2 месяца! За месяц нас стало в два раза больше. Стало больше прочтений, больше реакций, пересылок и комментариев. Пока еще я как ребенок радуюсь каждому комментарию и реакции — значит вы читаете и текст откликается.
Должна сказать, что обмен знаниями затягивает. Умение писать совсем легко пока еще не пришло, по-прежнему каждый пост перечитываю и корректирую. Зато стало интересно поделиться чем-то и ждать реакции читателей. Например, особенно интересно было рассказать о подмеченном на Analyst Days-17, причем рассказать сразу нескольким десяткам человек. Кстати, посты с тегом #analyst_days оказались в топ-5 по количеству просмотров.
Посмотрела какие публикации за 30 дней набрали больше просмотров, реакций и пересылок. Получилось так:
📍Очень вредно не ездить на бал, когда ты этого заслуживаешь
📍Итоги кейса про снабжение экспедиции
📍Почему не удалось с первой попытки найти приоритеты?
📍Подборка статей о User Story
📍Analyst Days – 17, день второй
🔥4❤1
Чем отличаются критерии приемки и DOD?
#agile
Делюсь еще одним текстом из рассылки от Майка Кона, на этот раз о двух видах критериев. Оригинал на Яндекс Диске
________________________________
Меня постоянно спрашивают в чем разница между Acceptance Criteria и Definition of done.
Я разъясню в двух словах. Acceptance criteria (Критерии приемки) уникальны для каждого элемента бэклога продукта. Какие-то критерии становится приемочными, когда они настолько важны для владельца продукта, что если продукт им не соответствует, то он просто не будет принят. Definition of done универсальны, то есть включают те критерии, которым должны соответствовать практически все элементы бэклога продукта.
Пример. Здесь представлен пример того, как я использую Acceptance criteria и Definition of done прямо сейчас в создании моего видео. Недавно я снял видео на тему разницы между этими понятиями.
Acceptance criteria для этого видео были:
1. Объяснить, что такое Acceptance criteria,
2. Объяснить, что такое Definition of done,
3. Объяснить разницу между ними.
Но каждое мое видео одновременно должно соответствовать моему Definition of done:
1. Видео должно начинаться с короткого вступления
2. Видео должно быть настолько коротким, насколько это возможно, чтобы проявить уважение к затраченному зрителем времени.
3. В видео должно быть напоминанием для зрителей поставить лайк и подписаться.
4. Видео должно иметь обложку, если видео длиннее одной минуты.
5. У видео должно быть короткое описание.
6. Мне нужно добавить ссылки на другие мои видео.
Кто формулирует acceptance criteria? Владелец продукта формулирует Acceptance criteria. В конце концов, именно он принимает продукт (или не принимает). Это не означает, что владелец продукта должен документировать все критерии, вместо этого конкретные критерии выводятся из вышестоящих acceptance criteria.
Кто формулирует definition of done? Definition of done формулируется с согласия всей команды, владельца продукта и Scrum Мастера. Эта формулировка может и должна развиваться со временем. Команда сходится на формулировке definition of done основываясь на общем понимании того, что означает создание высококачественного готового продукта в конкретном контексте.
#agile
Делюсь еще одним текстом из рассылки от Майка Кона, на этот раз о двух видах критериев. Оригинал на Яндекс Диске
________________________________
Меня постоянно спрашивают в чем разница между Acceptance Criteria и Definition of done.
Я разъясню в двух словах. Acceptance criteria (Критерии приемки) уникальны для каждого элемента бэклога продукта. Какие-то критерии становится приемочными, когда они настолько важны для владельца продукта, что если продукт им не соответствует, то он просто не будет принят. Definition of done универсальны, то есть включают те критерии, которым должны соответствовать практически все элементы бэклога продукта.
Пример. Здесь представлен пример того, как я использую Acceptance criteria и Definition of done прямо сейчас в создании моего видео. Недавно я снял видео на тему разницы между этими понятиями.
Acceptance criteria для этого видео были:
1. Объяснить, что такое Acceptance criteria,
2. Объяснить, что такое Definition of done,
3. Объяснить разницу между ними.
Но каждое мое видео одновременно должно соответствовать моему Definition of done:
1. Видео должно начинаться с короткого вступления
2. Видео должно быть настолько коротким, насколько это возможно, чтобы проявить уважение к затраченному зрителем времени.
3. В видео должно быть напоминанием для зрителей поставить лайк и подписаться.
4. Видео должно иметь обложку, если видео длиннее одной минуты.
5. У видео должно быть короткое описание.
6. Мне нужно добавить ссылки на другие мои видео.
Кто формулирует acceptance criteria? Владелец продукта формулирует Acceptance criteria. В конце концов, именно он принимает продукт (или не принимает). Это не означает, что владелец продукта должен документировать все критерии, вместо этого конкретные критерии выводятся из вышестоящих acceptance criteria.
Кто формулирует definition of done? Definition of done формулируется с согласия всей команды, владельца продукта и Scrum Мастера. Эта формулировка может и должна развиваться со временем. Команда сходится на формулировке definition of done основываясь на общем понимании того, что означает создание высококачественного готового продукта в конкретном контексте.
👍4