Работа с рисками включает в себя две составляющие: идентификация (подумать о том, какие есть риски) и анализ (обмозговать эти риски — насколько они значимы и что с ними делать).
1) Идентификация. Опишу простую вариацию процесса:
Возьмите экселечку или майндмэп и побрейнстормьте, что может пойти не так в вашей работе или работе команды аналитиков, исходя из нюансов, которые уже заметны. У любимого нами Карла Вигерса можно взять стартовый чеклист для этого в разделе “Требования к ПО и управление рисками”, профильтровать под свой проект и подумать по каждому пункту — повторюсь, что всегда проще взять какой-нибудь чеклист за базу, чем думать в пустоту. Есть еще один вариант: сначала накидать какой-никакой план своих работ, а потом пройтись по этим работам и подумать, что может пойти не так в каждой из них. Много времени на это тратить не стоит: уделите хотя бы несколько секунд каждому пункту — всплывает что-либо в голове при формулировке подобного вопроса? Выше у нас был пример с отпуском, соответственно, проект “Отдохнуть” может включать такие риски после мозгового штурма: “Не дадут визу”, “Сломается самолет” (не чисто гипотетически, а, например, в связи с тем, что участились новости о подобном в последнее время), “Приболею на отдыхе или получу травму”, “Превышу бюджет”, “Вещи могут украсть”.
2) Анализ.
- Во-первых, взгляните на каждый риск в двух плоскостях: вероятность и влияние. Один из простейших вариантов оценить каждый компонент — это описать их в ключе “низкое”, “среднее”, “высокое”. Например, поломка самолета может быть оценена вами как риск с низкой вероятностью и критично высоким влиянием (особенно, если подобное произошло в полете). Если у вас есть опыт регулярного приболевания в отпусках, то такой риск может иметь высокую вероятность и высокое, вероятно (зависит от того, как вы с подобным справляетесь), влияние на весь отпуск.
- Во-вторых, для каждого риска или выбранных категорий (например, для рисков с вероятностью “средняя-высокая” и влиянием “среднее-высокое” — тут вы уже сами решаете, на какие риски обратить внимание) вам нужно сделать то, ради чего, собственно, вы всю эту работу и затеяли: решить, что будем по этому поводу делать (политика работы с риском).
4 известные политики (и это вы тоже можете взять за чеклист):
1) Уклонение: избегаем ситуации, которая несет риск.
Поломка самолета: решаем, что в последнее время самолеты часто ломаются, а потому ищем локацию, в которую можно добраться иным транспортом.
Коммуникационные помехи из-за языкового барьера (к примеру, на первой встрече мы заказчика еле-еле поняли на звонке): решаем, что будем склоняться к переписке вместо устного общения (это не рекомендация — вы сами решаете, подойдет ли подобное в вашей ситуации).
2) Передача: перекладывание ответственности за риск на иную сторону.
Кража вещей: решаем, что в целевой стране это частое явление, а потому заранее поищем варианты страховки этого дела, чтобы не так обидно было, если что.
Заказчик будет часто менять требования (по первому звонку видно, что он без понятия, каковым должно быть наполнение системы, и просто бросается идеями в воздух): заранее явно обсудим с ним управление изменениями (точки, после которых к изменениям будем относиться более внимательно, и процесс, по которому после наступления этих точек заказчик будет платить за свои изменчивые хотелки).
3) Снижение а) вероятности или б) влияния.
Плохое самочувствие в отпуске: а) решаем, что не будем кушать всякую хрень на улице, б) берем с собой аптечку под свои типовые нужды.
Заказчик будет редко отвечать (например, это видно по его ответам на наши исходные письма): а) обговорим с ним план коммуникаций заранее: как-никак, подобный план склоняет к тому, чтобы уделить коммуникациям больше внимания, 2) явно проговорим с ним политику действий, если он не отвечает (например, при отсутствии ответа в течение дня мы движемся на базе предложенных нами в письме решений или сформулированного нами понимания — объясняем ценность подобного подхода для проекта и получаем на это явный аппрув).
1) Идентификация. Опишу простую вариацию процесса:
Возьмите экселечку или майндмэп и побрейнстормьте, что может пойти не так в вашей работе или работе команды аналитиков, исходя из нюансов, которые уже заметны. У любимого нами Карла Вигерса можно взять стартовый чеклист для этого в разделе “Требования к ПО и управление рисками”, профильтровать под свой проект и подумать по каждому пункту — повторюсь, что всегда проще взять какой-нибудь чеклист за базу, чем думать в пустоту. Есть еще один вариант: сначала накидать какой-никакой план своих работ, а потом пройтись по этим работам и подумать, что может пойти не так в каждой из них. Много времени на это тратить не стоит: уделите хотя бы несколько секунд каждому пункту — всплывает что-либо в голове при формулировке подобного вопроса? Выше у нас был пример с отпуском, соответственно, проект “Отдохнуть” может включать такие риски после мозгового штурма: “Не дадут визу”, “Сломается самолет” (не чисто гипотетически, а, например, в связи с тем, что участились новости о подобном в последнее время), “Приболею на отдыхе или получу травму”, “Превышу бюджет”, “Вещи могут украсть”.
2) Анализ.
- Во-первых, взгляните на каждый риск в двух плоскостях: вероятность и влияние. Один из простейших вариантов оценить каждый компонент — это описать их в ключе “низкое”, “среднее”, “высокое”. Например, поломка самолета может быть оценена вами как риск с низкой вероятностью и критично высоким влиянием (особенно, если подобное произошло в полете). Если у вас есть опыт регулярного приболевания в отпусках, то такой риск может иметь высокую вероятность и высокое, вероятно (зависит от того, как вы с подобным справляетесь), влияние на весь отпуск.
- Во-вторых, для каждого риска или выбранных категорий (например, для рисков с вероятностью “средняя-высокая” и влиянием “среднее-высокое” — тут вы уже сами решаете, на какие риски обратить внимание) вам нужно сделать то, ради чего, собственно, вы всю эту работу и затеяли: решить, что будем по этому поводу делать (политика работы с риском).
4 известные политики (и это вы тоже можете взять за чеклист):
1) Уклонение: избегаем ситуации, которая несет риск.
Поломка самолета: решаем, что в последнее время самолеты часто ломаются, а потому ищем локацию, в которую можно добраться иным транспортом.
Коммуникационные помехи из-за языкового барьера (к примеру, на первой встрече мы заказчика еле-еле поняли на звонке): решаем, что будем склоняться к переписке вместо устного общения (это не рекомендация — вы сами решаете, подойдет ли подобное в вашей ситуации).
2) Передача: перекладывание ответственности за риск на иную сторону.
Кража вещей: решаем, что в целевой стране это частое явление, а потому заранее поищем варианты страховки этого дела, чтобы не так обидно было, если что.
Заказчик будет часто менять требования (по первому звонку видно, что он без понятия, каковым должно быть наполнение системы, и просто бросается идеями в воздух): заранее явно обсудим с ним управление изменениями (точки, после которых к изменениям будем относиться более внимательно, и процесс, по которому после наступления этих точек заказчик будет платить за свои изменчивые хотелки).
3) Снижение а) вероятности или б) влияния.
Плохое самочувствие в отпуске: а) решаем, что не будем кушать всякую хрень на улице, б) берем с собой аптечку под свои типовые нужды.
Заказчик будет редко отвечать (например, это видно по его ответам на наши исходные письма): а) обговорим с ним план коммуникаций заранее: как-никак, подобный план склоняет к тому, чтобы уделить коммуникациям больше внимания, 2) явно проговорим с ним политику действий, если он не отвечает (например, при отсутствии ответа в течение дня мы движемся на базе предложенных нами в письме решений или сформулированного нами понимания — объясняем ценность подобного подхода для проекта и получаем на это явный аппрув).
👍7
4) Принятие. Есть и есть — ничего с риском не делаем.
Смотрите, разница между аналитиком, который вообще такое не делает, и аналитиком, который уделил этому процессу время (и уделяет по мере периодического ревью планов) может быть серьезной. То есть это может быть разницей между “поехал в отпуск -> заболел ->потратил кучу денег на местные лекарства ->испортил отдых”; “остался без денег, потому что не рассчитал” и “взял мегасобранную аптечку - > полечился - > все более-менее терпимо”, “взял карту на всякий случай -> не остался бомжевать на улице в чужой стране”. Или, если говорить о бизнес-анализе, “уточнил про планируемые отпуска и доступность ЗЛ заранее”, “узнал, что помимо почты заказчик, оказывается, совсем не против и в Телеграме пообщаться, где он отвечает гораздо оперативнее”, “не получил от заказчика лютое удивление, когда сказал, что после старта разработки любые изменения влияют на бюджет/сроки, потому что заранее это обговорил” и т. п. Ну а для менеджера и команды это разница между аналитиком, который “Ой, ну так получилось… Не виноватый я”, и аналитиком, у которого подобное в силу неизвестной магии встречается гораздо реже.
Ну и пара типовых ошибок понимания у тех, кто только начинает погружаться в эту область:
- Мы говорим не об общепроектных рисках, а о рисках БА. То, что разработчик Вася может заболеть, это риск проекта и проектных параметров, а не деятельности аналитика. В общем, не ваш это головняк, если это не затрагивает вашу работу.
- Мы говорим не о бизнес-рисках, а о рисках БА. С бизнес-рисками вы можете работать в рамках анализа стратегии, и это то, что вы активно можете обсуждать с заказчиком в контексте “А что может пойти не так в применимости решения к бизнес-целям?”. Риски БА — это ваш внутренний головняк в контексте планирования своей работы, и заказчику реестр рисков и их анализ вываливать не стоит — он платит компании не за то, чтобы аналитик обсуждал с ним кучу негатива, который может повлиять на его работу.
Смотрите, разница между аналитиком, который вообще такое не делает, и аналитиком, который уделил этому процессу время (и уделяет по мере периодического ревью планов) может быть серьезной. То есть это может быть разницей между “поехал в отпуск -> заболел ->потратил кучу денег на местные лекарства ->испортил отдых”; “остался без денег, потому что не рассчитал” и “взял мегасобранную аптечку - > полечился - > все более-менее терпимо”, “взял карту на всякий случай -> не остался бомжевать на улице в чужой стране”. Или, если говорить о бизнес-анализе, “уточнил про планируемые отпуска и доступность ЗЛ заранее”, “узнал, что помимо почты заказчик, оказывается, совсем не против и в Телеграме пообщаться, где он отвечает гораздо оперативнее”, “не получил от заказчика лютое удивление, когда сказал, что после старта разработки любые изменения влияют на бюджет/сроки, потому что заранее это обговорил” и т. п. Ну а для менеджера и команды это разница между аналитиком, который “Ой, ну так получилось… Не виноватый я”, и аналитиком, у которого подобное в силу неизвестной магии встречается гораздо реже.
Ну и пара типовых ошибок понимания у тех, кто только начинает погружаться в эту область:
- Мы говорим не об общепроектных рисках, а о рисках БА. То, что разработчик Вася может заболеть, это риск проекта и проектных параметров, а не деятельности аналитика. В общем, не ваш это головняк, если это не затрагивает вашу работу.
- Мы говорим не о бизнес-рисках, а о рисках БА. С бизнес-рисками вы можете работать в рамках анализа стратегии, и это то, что вы активно можете обсуждать с заказчиком в контексте “А что может пойти не так в применимости решения к бизнес-целям?”. Риски БА — это ваш внутренний головняк в контексте планирования своей работы, и заказчику реестр рисков и их анализ вываливать не стоит — он платит компании не за то, чтобы аналитик обсуждал с ним кучу негатива, который может повлиять на его работу.
👍11❤1
Раз затронули тему про планирование БА, то немного об ещё одной непростой его части - оценке своих работ (эстимации, эстимейты - есть ещё вариации?) И в эту тему пара замечательных статей от замечательных людей:
Оценка трудоемкости задач для бизнес-аналитика
Оценка трудозатрат для аналитика
Если добавить от себя, то:
1) Понимать, что есть разные подходы, надо. Когда будете давать начальству оценку, сможете не просто пальцем ткнуть, а подумать с нескольких сторон и сравнить несколько оценок.
2) Знание теории не сделает ваши оценки точными и не уберёт стресс в процессе. Они всегда будут неточными в той или иной степени. Но расхождение с реальностью будет с опытом постоянно снижаться.
3) Знание теории сделает вас внешне мудрее на собеседованиях. А это часто спрашивают, ага.
Оценка трудоемкости задач для бизнес-аналитика
Оценка трудозатрат для аналитика
Если добавить от себя, то:
1) Понимать, что есть разные подходы, надо. Когда будете давать начальству оценку, сможете не просто пальцем ткнуть, а подумать с нескольких сторон и сравнить несколько оценок.
2) Знание теории не сделает ваши оценки точными и не уберёт стресс в процессе. Они всегда будут неточными в той или иной степени. Но расхождение с реальностью будет с опытом постоянно снижаться.
3) Знание теории сделает вас внешне мудрее на собеседованиях. А это часто спрашивают, ага.
👍4🔥3
Интересный менторский кейс:
У человека, с которым я недавно работал, был не очень позитивный фидбэк по итогам нескольких собеседований. Начали раскапывать выполнение тестовых заданий и ответы на вопросы, и так совпало, что значимыми оказались моменты, собранные в этой заметке: https://t.me/itmineba/47. Только слегка переформулирую симптом для данного кейса: проблемы в понимании зон ответственности бизнес-аналитика по умолчанию. Добавил “по умолчанию”, потому что замечал резкое неприятие обсуждений зон ответственности (мол, взрослые же, сами на проекте оперативно решат, кто и куда погружается — весьма ограниченно, но согласен).
В общем, что у человека было:
1) Собеседование в компанию X. “Расскажи техническую архитектуру последнего проекта.” В рамках ответа было затронуто такое: “когда я говорил про базы данных, которые у нас были, и про интеграции, я сказал что-то вроде “моя основная зона ответственности - вот эта часть интеграции и БД”. Интервьюер удивился, повторил мои слова и задал следующий вопрос.”
Были и другие моменты, но по итогу фидбэк суммарно был таким: “Дальше общаться не имеет смысла, потому что между нами слишком большой gap.” Вероятно, не только этот пункт вызвал удивление, но именно по этому вопросу оно вполне себе понятно.
Как, на мой взгляд, стоило поступить: 1) в целом, понимать, где лежат типовые зоны ответственности БА (requirements vs design specifics), 2) если вы занимались чем-то не очень типовым, то осознавать это и проактивно пояснить в дополнение к ответу. В моей практике были собеседования сеньоров, которые 5 лет были погружены, например, сугубо в проектирование API своих продуктов. Ответ на вопрос, а чем ещё, причем более общепринятым, могут заниматься аналитики, они не знали. Денег на позицию БА-генералиста в аутсорс-проекте хотели много :)
2) Тестовое задание для компании Y. Задание состояло в, грубо говоря, составлении плана на БА для выданного проекта. И одной из точек плана по итогу у человека была такая: “совместная с ПМ, клиентом и техлидом выработка подхода к разработке (agile vs waterfall)” (тут я все же рекомендую читануть это).
Фидбек вполне имхо ожидаем: самым первым пунктом шло “Очевиден проектноменеджерский опыт. Но в данном кейсе мы бы хотели видеть фокус на процессе анализа в рамках проекта. “
Рекомендации тут нехитрые: это не часть планирования БА (и полезно-таки знать и корректно понимать, что входит в планирование БА), и в типовом процессе у аналитика мало кто будет спрашивать, по какому подходу будет идти проект. И уж точно не аналитик должен триггерить решение этого вопроса.
В целом, человек — весьма крутой аналитик по многим фронтам, и работу с требованиями ведёт, кажись, прекрасно. Но вылезла такая вот слепая зона: где кончается работа усредненного ИТ БА и начинаются сферы ответственности иных ролей. Это ещё раз доказывает, что личный опыт может быть ограничен и с разной степенью искажен. Могу только в очередной раз посоветовать активно интересоваться как грамотно собранной теорией, так и опытом других людей.
У человека, с которым я недавно работал, был не очень позитивный фидбэк по итогам нескольких собеседований. Начали раскапывать выполнение тестовых заданий и ответы на вопросы, и так совпало, что значимыми оказались моменты, собранные в этой заметке: https://t.me/itmineba/47. Только слегка переформулирую симптом для данного кейса: проблемы в понимании зон ответственности бизнес-аналитика по умолчанию. Добавил “по умолчанию”, потому что замечал резкое неприятие обсуждений зон ответственности (мол, взрослые же, сами на проекте оперативно решат, кто и куда погружается — весьма ограниченно, но согласен).
В общем, что у человека было:
1) Собеседование в компанию X. “Расскажи техническую архитектуру последнего проекта.” В рамках ответа было затронуто такое: “когда я говорил про базы данных, которые у нас были, и про интеграции, я сказал что-то вроде “моя основная зона ответственности - вот эта часть интеграции и БД”. Интервьюер удивился, повторил мои слова и задал следующий вопрос.”
Были и другие моменты, но по итогу фидбэк суммарно был таким: “Дальше общаться не имеет смысла, потому что между нами слишком большой gap.” Вероятно, не только этот пункт вызвал удивление, но именно по этому вопросу оно вполне себе понятно.
Как, на мой взгляд, стоило поступить: 1) в целом, понимать, где лежат типовые зоны ответственности БА (requirements vs design specifics), 2) если вы занимались чем-то не очень типовым, то осознавать это и проактивно пояснить в дополнение к ответу. В моей практике были собеседования сеньоров, которые 5 лет были погружены, например, сугубо в проектирование API своих продуктов. Ответ на вопрос, а чем ещё, причем более общепринятым, могут заниматься аналитики, они не знали. Денег на позицию БА-генералиста в аутсорс-проекте хотели много :)
2) Тестовое задание для компании Y. Задание состояло в, грубо говоря, составлении плана на БА для выданного проекта. И одной из точек плана по итогу у человека была такая: “совместная с ПМ, клиентом и техлидом выработка подхода к разработке (agile vs waterfall)” (тут я все же рекомендую читануть это).
Фидбек вполне имхо ожидаем: самым первым пунктом шло “Очевиден проектноменеджерский опыт. Но в данном кейсе мы бы хотели видеть фокус на процессе анализа в рамках проекта. “
Рекомендации тут нехитрые: это не часть планирования БА (и полезно-таки знать и корректно понимать, что входит в планирование БА), и в типовом процессе у аналитика мало кто будет спрашивать, по какому подходу будет идти проект. И уж точно не аналитик должен триггерить решение этого вопроса.
В целом, человек — весьма крутой аналитик по многим фронтам, и работу с требованиями ведёт, кажись, прекрасно. Но вылезла такая вот слепая зона: где кончается работа усредненного ИТ БА и начинаются сферы ответственности иных ролей. Это ещё раз доказывает, что личный опыт может быть ограничен и с разной степенью искажен. Могу только в очередной раз посоветовать активно интересоваться как грамотно собранной теорией, так и опытом других людей.
👍18
Всем доброго времени суток!
Сегодня речь пойдет о коммуникациях. Я поделюсь с вами 11-ю правилами, придерживаясь которых вы увеличите эффективность устных коммуникационных сессий в 2-4 раза📈 Как эксперту в сфере лидерства, цифровых трансформаций и мотивации мне часто задают вопрос: есть ли у тебя какие-либо советы, как новичку построить разговор с клиентом, чтобы создать у него впечатление общения с опытным профессионалом? Несомненно, есть 💯 В первую очередь, пункты ниже применимы к общению с внешними проектными заинтересованными лицами (stakeholders), но они прекрасно работают и в любых иных коммуникациях, будь-то общение с командой или интервью при устройстве на работу.
📸 Если мы говорим об удаленном общении, НЕ используйте камеру, если контекст этого явно не требует. Любая информация (information) доносится голосом. Все прочие помехи — это информационный шум. Собеседнику сложнее сосредоточиться на том, ЧТО вы доносите, если он будет отвлекаться на КАК. В IT есть всем известное правило: если детали встречи заранее в явном виде не содержат пометку о необходимости видео-общения, камера должна оставаться выключенной. Камера — это лишний стресс для вас, плюс она серьезно вас ограничивает (стимулирует приводить внешний вид в порядок, держать уверенную деловую позу, мешает заниматься иными делами в процессе). Призываю не недооценивать важность личного комфорта при удаленном общении.
☕️ В продолжение темы фокуса: не злоупотребляйте перерывами. Совет актуален для тех сессий, форматом которых вы управляете. Все мы слышали про научно подтвержденное тренингами личностного роста ресурсное состояние — состояние, в котором человек максимально продуктивен и эффективен. Чтобы всем участникам встречи войти в ресурсное состояние, необходимо всецело сосредоточиться на обсуждаемых вопросах. Представьте, что вы погружены в тематику обсуждения, и тут фасилитатор встречи внезапно заявляет: “А сейчас мы уходим на перерыв.” Вы потеряете контекст и накопленную энергию, и на включение вам потребуются время и новый квант энергии. Сформулирую простое правило: перерывы не нужны, вне зависимости от длительности сессий. Все участники понимают, что они собрались работать, а не отдыхать. Если участнику экстренно потребуется перерыв, он сам об этом попросит и удалится, не мешая другим работать.
❓ Одна из критичных ошибок, которую вы можете допустить на высокоэффективном интервью — это переспрашивать собеседника. Не выставляйте себя идиотом: ваш образ (image) — это ваш главный актив. Если вы отвлеклись, задумались или не поняли собеседника из-за помех в канале коммуникации или языкового барьера, просто плывите в потоке дальше, не фиксируясь на произошедшем. Людям свойственно повторяться в разговоре — информация в любом случае всплывет еще не один раз. А если не всплывет, то помним о всем известном принципе Парето — 20 на 80. В данном случае его можно трактовать так: 20% процентов информации имеют значение, 80% — информационный шум, а потому вероятность того, что вы упустите что-то важное, крайне мала.
⏺ Многие аналитики по умолчанию записывают встречи, пользуясь встроенными средствами Zoom или диктофоном на личной встрече. Я не советую. Запись встречи, во-первых, требует подготовки (что по сути тратит ваше время, которые вы могли быть уделить еще одному интервью, если по какой-то причине не все из сказанного собеседником зафиксировали), и во-вторых — стейкхолдеры (stakeholders) могут негативно на это отреагировать, т. к. никто не любит, когда их записывают. Если у вас все же есть такая необходимость (как правило, это нужно только лишь для того, чтобы создать базу для предъявления официальных претензий к собеседнику в случае, если он позже будет противоречить себе же), сделайте это скрыто, чтобы не вызвать негативных реакций. Скачайте себе любой скринграббер или же настройте диктофон на телефоне/часах так, чтобы его можно было включать/выключать естественными не привлекающими внимание жестами.
Сегодня речь пойдет о коммуникациях. Я поделюсь с вами 11-ю правилами, придерживаясь которых вы увеличите эффективность устных коммуникационных сессий в 2-4 раза
☕️ В продолжение темы фокуса: не злоупотребляйте перерывами. Совет актуален для тех сессий, форматом которых вы управляете. Все мы слышали про научно подтвержденное тренингами личностного роста ресурсное состояние — состояние, в котором человек максимально продуктивен и эффективен. Чтобы всем участникам встречи войти в ресурсное состояние, необходимо всецело сосредоточиться на обсуждаемых вопросах. Представьте, что вы погружены в тематику обсуждения, и тут фасилитатор встречи внезапно заявляет: “А сейчас мы уходим на перерыв.” Вы потеряете контекст и накопленную энергию, и на включение вам потребуются время и новый квант энергии. Сформулирую простое правило: перерывы не нужны, вне зависимости от длительности сессий. Все участники понимают, что они собрались работать, а не отдыхать. Если участнику экстренно потребуется перерыв, он сам об этом попросит и удалится, не мешая другим работать.
⏺ Многие аналитики по умолчанию записывают встречи, пользуясь встроенными средствами Zoom или диктофоном на личной встрече. Я не советую. Запись встречи, во-первых, требует подготовки (что по сути тратит ваше время, которые вы могли быть уделить еще одному интервью, если по какой-то причине не все из сказанного собеседником зафиксировали), и во-вторых — стейкхолдеры (stakeholders) могут негативно на это отреагировать, т. к. никто не любит, когда их записывают. Если у вас все же есть такая необходимость (как правило, это нужно только лишь для того, чтобы создать базу для предъявления официальных претензий к собеседнику в случае, если он позже будет противоречить себе же), сделайте это скрыто, чтобы не вызвать негативных реакций. Скачайте себе любой скринграббер или же настройте диктофон на телефоне/часах так, чтобы его можно было включать/выключать естественными не привлекающими внимание жестами.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁7❤3👍1🤔1
👩🏼🏫 Учите собеседников правильной терминологии. Часто наблюдается ситуация, когда участник беседы использует неверные термины. Коммуникация должна быть прозрачной и не допускать разночтений, плюс все мы знаем, что установить глоссарий терминов — крайне важно. Если вы слышите, что собеседник использует не тот термин, который вы считаете верным, прервите его и четко дайте понять, что его терминология неверна (incorrect). Собеседник должен понимать, что на звонке — вы эксперт, а потому он будет благодарен вам за наставничество.
🙈Не допускайте пауз в диалогах. Любая пауза создает ощущение дискомфорта. Вам необходимо сформировать навык заполнения пауз. Причем содержимое того, чем вы будете их заполнять, не играет особой роли. Главное — поддерживать видимость активно идущей беседы. Если собеседник задал вам вопрос, на который у вас нет моментального ответа, то, во-первых, это сигнал к тому, что вы плохо подготовились — не учли все возможные ответвления диалога, а во-вторых — ответьте первое, что придет в голову. Так вы будете выглядеть профессионалом, имеющим ответ на любые вопросы. Вы всегда можете позже вернуться к этой части беседы и поправиться, сказав, что не обдумали в моменте и у вас есть новый ответ. В этом нет ничего страшного (людям в целом свойственно менять позиции, и это всем очевидно), в отличие от неловких пауз.
Please open Telegram to view this post
VIEW IN TELEGRAM
💯5🤣4🔥1
Плюс важно понимать, что участникам бесед на старте нужно преодолеть барьер вовлечения, ну или попросту разогнаться, чтобы войти в рабочее ресурсное состояние. Соответственно, очевидно, что чем быстрее все это сделают, тем эффективнее пройдет встреча. Я рекомендую выносить в начало беседы наиболее ресурсоемкие вопросы. Т. е. выберите ту часть беседы, которая наиболее сложна для понимания и восприятия участниками (потребует максимальных умственных усилий) и начните с (with) нее (рекомендую сразу после включения в беседу и краткого приветствия — например вы подключаетесь к встрече, включаете микрофон и без лишних задержек: “Добрый день, Ибрагим! Вопрос к вам по логической модели данных… ”).
💡Коммуникативность. Коммуникативность повышает продуктивность и эффективность общения. В целях повышения результативности встреч я крайне рекомендую фасилитировать коммуникативность среди ее участников. Высокоорганизованная культура общения — это залог успеха проектов в эпоху цифровизации, а подобные проекты приводят к трансформации организаций в современных реалиях. В качестве дополнительных предпосылок отмечу также необходимость выработки функциональных процессов, стимулирующих процессы коммуникаций, непосредственным участником которых вы как аналитик будете являться. Не должен вызывать сомнений тезис о том, что вы как проектный коммуникатор ответственны за вовлечение заинтересованных лиц в коллаборацию c целью достижения стратегических показателей и выработки эффективных решений. А потому вывод о неизбежности роста фактора коммуникативности в общем успехе проектной деятельности вполне очевиден.
Напоследок хочу отметить, что это лучшие правила, которые вы можете найти. Если вы внедрите эти правила в практику, то в перспективе они приведут к карьерному росту и росту доходов на 5-50% 🚀 Около 100 человек уже раскрыли свой коммуникационный потенциал за счет данных рекомендаций, и это только за прошлый год.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁7❤4🔥2🤪1
Небольшая подборка полезных чтив и подборок:
Впечатляющая коллекция советов для UI: https://www.linkedin.com/posts/zamakhov_podbiratel-ux-activity-7178263906702790656-zLhx
Сам я не особо фанат таких сборок и мне проще погуглить и вручную профильтровать, но вдруг кому-то актуально здесь и сейчас.
https://www.forbes.ru/forbeslife/480596-akornoe-smesenie-i-effekt-dizinformacii-kak-kognitivnye-iskazenia-opredelaut-vybor — о ряде когнитивных искажений (biases). Это очень интересная и недооцененная для аналитика тема (как раз аналитику по роду деятельности эта тема и нужна). Если заинтересует, то вот тут более всеобъемлющий гайд: https://habr.com/ru/companies/otus/articles/793130/
Частный случай реализации моего горячо любимого GTD: https://medium.com/@semyonkolosov/system-setup-how-does-my-gtd-work-605ce2d4482a Вдруг и вас зацепит.
Небольшая заметка о том, как договариваться о деньгах при трудоустройстве: https://www.linkedin.com/posts/emilyworden_jobinterview-negotiations-jobseekers-activity-7178458584135942144-NDiV
Мне этот пункт показался очень актуальным. Сложно сказать, сработают ли именно такие текстовки, но с тем, что надо пытаться вытянуть цифру первым, сильно согласен.
Впечатляющая коллекция советов для UI: https://www.linkedin.com/posts/zamakhov_podbiratel-ux-activity-7178263906702790656-zLhx
Сам я не особо фанат таких сборок и мне проще погуглить и вручную профильтровать, но вдруг кому-то актуально здесь и сейчас.
https://www.forbes.ru/forbeslife/480596-akornoe-smesenie-i-effekt-dizinformacii-kak-kognitivnye-iskazenia-opredelaut-vybor — о ряде когнитивных искажений (biases). Это очень интересная и недооцененная для аналитика тема (как раз аналитику по роду деятельности эта тема и нужна). Если заинтересует, то вот тут более всеобъемлющий гайд: https://habr.com/ru/companies/otus/articles/793130/
Частный случай реализации моего горячо любимого GTD: https://medium.com/@semyonkolosov/system-setup-how-does-my-gtd-work-605ce2d4482a Вдруг и вас зацепит.
Небольшая заметка о том, как договариваться о деньгах при трудоустройстве: https://www.linkedin.com/posts/emilyworden_jobinterview-negotiations-jobseekers-activity-7178458584135942144-NDiV
Мне этот пункт показался очень актуальным. Сложно сказать, сработают ли именно такие текстовки, но с тем, что надо пытаться вытянуть цифру первым, сильно согласен.
🔥11❤1
Тэкс, продолжим обсуждать ошибки аналитика, и еще одна, периодически высвечивающаяся (#20, если не сбился), — это взгляд на систему только со стороны фич или почему аналитику желательно не брезговать UX. Тема эта часто затрагивается в разных источниках, поэтому буду относительно краток.
Все мы знаем, что такое скоуп (границы, рамки) решения — характеристики решения в виде неких крупных единичек, чтобы по ним и требования можно было структурировать, и в процессе проекта есть слона кусочками, а не целиком.
Что такое скоуп в понимании agile-аналитика? Как правило, это часть product backlog, представленная в виде user stories, или user story map (они же, но еще и визуально).
Что такое скоуп в понимании более консервативного аналитика? Это либо набор фич (функций, функциональных возможностей), либо юз кейсов (вариантов использования).
Проблема в том, что как первые, так и вторые зачастую страдают тем, что продумывают наполнение решения, отталкиваясь сугубо от вопроса «А что бы нам заложить такого в систему?». Это ярко проявляется, когда аналитик либо смотрит на скоуп только лишь с позиции фич, спрашивая себя и других «Какими функциями должна обладать система?», либо когда он делает то же самое, а потом задумывается над тем, а как теперь это в формат сторей переписать. Опасна именно сама подобная постановка вопроса, если она не дополняется или даже не начинается с несколько иного вопроса: «Что пользователям нужно получить от системы?».
В качестве быстрого примера давайте представим, что вы проектируете сайт-визитку для бизнеса. Паровозик мысли тут у каждого будет разный (что тоже симптом проблемы), но, допустим, в процессе общения с заказчиком вы, задав вопрос «Что должно быть в системе?», дружно бредогенерируете следующее:
- Главная страница
- Описание услуг
- Контакты
- Подача заявки
Спрашиваете друг у друга: логично/полно/огненно? Одобряюще киваете и уходите оформлять это в виде фич или историй, чтобы донести команде. Ошибка тут проста: отсутствие попытки посмотреть на это со стороны пользователей и их потребностей.
Что стоило бы сделать в дополнение к этому или даже первым шагом?
1. Спросить себя и стейкхолдеров, а кто наши пользователи? После чего —структурировать их через категории / роли / персоны. А если еще и не забудете про то, что пользователи бывают непрямыми, а еще и не обязательно человеками (робот, индексирующий сайт, или стороннее ПО, пользующее API вашего решения) — вообще огонь будет.
2. Какие потребности каждой категории нужно удовлетворить, чтобы реализовать ранее сформулированные бизнес-требования? Есть много вариантов того, как выполнить эту задачу, причем каждый из них можно осуществить самостоятельно (при прокачанном скилле эмпатии), совместно с заказчиком, а можно выйти и на самих пользователей или их представителей:
- Накидать юз кейсы (например: Получить информацию о компании; Получить информацию о том, как связаться с компанией; Изучить услуги компании; Понять расписание работы компании; Отправить сообщение и т. п.)
- Построить CJM (Customer Journey Map), чтобы понять целостный контекст взаимодействия пользователей с решением или даже бизнесом в целом и еще сильнее им поэмпатировать: подумать о мотивации, болях и прочих эмоциях в разных точках взаимодействия.
- Построить User Story Map, причем сделать это именно так, как отцы завещали: не вопросом «А че там у нас должно быть в системе?», а последовательной проработкой пользовательского пути: цели -> шаги -> вариации шагов -> приоритизация.
- Построить Impact Map и тоже по заветам предков: бизнес-цели -> актеры -> желаемое изменение их поведения -> реализация этого в решении.
Все мы знаем, что такое скоуп (границы, рамки) решения — характеристики решения в виде неких крупных единичек, чтобы по ним и требования можно было структурировать, и в процессе проекта есть слона кусочками, а не целиком.
Что такое скоуп в понимании agile-аналитика? Как правило, это часть product backlog, представленная в виде user stories, или user story map (они же, но еще и визуально).
Что такое скоуп в понимании более консервативного аналитика? Это либо набор фич (функций, функциональных возможностей), либо юз кейсов (вариантов использования).
Проблема в том, что как первые, так и вторые зачастую страдают тем, что продумывают наполнение решения, отталкиваясь сугубо от вопроса «А что бы нам заложить такого в систему?». Это ярко проявляется, когда аналитик либо смотрит на скоуп только лишь с позиции фич, спрашивая себя и других «Какими функциями должна обладать система?», либо когда он делает то же самое, а потом задумывается над тем, а как теперь это в формат сторей переписать. Опасна именно сама подобная постановка вопроса, если она не дополняется или даже не начинается с несколько иного вопроса: «Что пользователям нужно получить от системы?».
В качестве быстрого примера давайте представим, что вы проектируете сайт-визитку для бизнеса. Паровозик мысли тут у каждого будет разный (что тоже симптом проблемы), но, допустим, в процессе общения с заказчиком вы, задав вопрос «Что должно быть в системе?», дружно бредогенерируете следующее:
- Главная страница
- Описание услуг
- Контакты
- Подача заявки
Спрашиваете друг у друга: логично/полно/огненно? Одобряюще киваете и уходите оформлять это в виде фич или историй, чтобы донести команде. Ошибка тут проста: отсутствие попытки посмотреть на это со стороны пользователей и их потребностей.
Что стоило бы сделать в дополнение к этому или даже первым шагом?
1. Спросить себя и стейкхолдеров, а кто наши пользователи? После чего —структурировать их через категории / роли / персоны. А если еще и не забудете про то, что пользователи бывают непрямыми, а еще и не обязательно человеками (робот, индексирующий сайт, или стороннее ПО, пользующее API вашего решения) — вообще огонь будет.
2. Какие потребности каждой категории нужно удовлетворить, чтобы реализовать ранее сформулированные бизнес-требования? Есть много вариантов того, как выполнить эту задачу, причем каждый из них можно осуществить самостоятельно (при прокачанном скилле эмпатии), совместно с заказчиком, а можно выйти и на самих пользователей или их представителей:
- Накидать юз кейсы (например: Получить информацию о компании; Получить информацию о том, как связаться с компанией; Изучить услуги компании; Понять расписание работы компании; Отправить сообщение и т. п.)
- Построить CJM (Customer Journey Map), чтобы понять целостный контекст взаимодействия пользователей с решением или даже бизнесом в целом и еще сильнее им поэмпатировать: подумать о мотивации, болях и прочих эмоциях в разных точках взаимодействия.
- Построить User Story Map, причем сделать это именно так, как отцы завещали: не вопросом «А че там у нас должно быть в системе?», а последовательной проработкой пользовательского пути: цели -> шаги -> вариации шагов -> приоритизация.
- Построить Impact Map и тоже по заветам предков: бизнес-цели -> актеры -> желаемое изменение их поведения -> реализация этого в решении.
❤1🔥1
Несложно догадаться, что вопросы «Как мы думаем, что должно быть в системе?» и «А что бабушке Любе нужно от системы в том контексте, когда она в нее полезет?» дадут разные результаты: разные единички скоупа окажутся необходимыми или лишними, плюс иной будет их приоритизация.
А раз разные результаты, то какой из них предпочтителен? Сдается, что эпоха продуктов, которые построены так, как видят правильным их разработчики или заказчик, которого в отношении продукта интересуют только деньги, прошла. Это была эпоха сложных систем, которым надо активно обучаться, чтобы постичь гений автора, и все равно частенько фрустрировать в процессе работы, озвучивая кривизну его рук. Мы все же в точке, когда продукт должен быть лучше, чем у конкурентов, потому что конкурентов — действующих или потенциальных — много, и чаще всего именно пользователи решат, пользоваться ли именно вашим решением. Мы часто действительно кайфуем от решений любого плана, сделанных «экспертами» по традиционному подходу «я художник, я так вижу»? Например, от того, как работают больницы, школы и многие подобные услуги. Когда-то читал замечательный кейс, в котором городские власти решили обратиться к UX-специалистам из IT для анализа и редизайна городской больницы и точек взаимодействия людей с ней. И внезапно, несмотря на серьезные инвестиции в это, новая больничка не просто повысила авторитет властей за счет резкого роста удобства для людей, но и стала существенно более доходной.
В общем, если вы все еще работаете по дивному процессу «Заказчик, расскажи , что там в системе нужно -> Ок, я это в виде фич или сторей сделяль -> Команда, узри постановку задачи!», предлагаю попробовать встроить сюда один или несколько описанных выше подходов — высока вероятность, что счастья этим стейкхолдерам вы принесете значительно больше.
А раз разные результаты, то какой из них предпочтителен? Сдается, что эпоха продуктов, которые построены так, как видят правильным их разработчики или заказчик, которого в отношении продукта интересуют только деньги, прошла. Это была эпоха сложных систем, которым надо активно обучаться, чтобы постичь гений автора, и все равно частенько фрустрировать в процессе работы, озвучивая кривизну его рук. Мы все же в точке, когда продукт должен быть лучше, чем у конкурентов, потому что конкурентов — действующих или потенциальных — много, и чаще всего именно пользователи решат, пользоваться ли именно вашим решением. Мы часто действительно кайфуем от решений любого плана, сделанных «экспертами» по традиционному подходу «я художник, я так вижу»? Например, от того, как работают больницы, школы и многие подобные услуги. Когда-то читал замечательный кейс, в котором городские власти решили обратиться к UX-специалистам из IT для анализа и редизайна городской больницы и точек взаимодействия людей с ней. И внезапно, несмотря на серьезные инвестиции в это, новая больничка не просто повысила авторитет властей за счет резкого роста удобства для людей, но и стала существенно более доходной.
В общем, если вы все еще работаете по дивному процессу «Заказчик, расскажи , что там в системе нужно -> Ок, я это в виде фич или сторей сделяль -> Команда, узри постановку задачи!», предлагаю попробовать встроить сюда один или несколько описанных выше подходов — высока вероятность, что счастья этим стейкхолдерам вы принесете значительно больше.
🔥10❤2👍1
Написал заметку о том, как я использую GTD: Мой GTD: процесс, инструменты и советы.
Если у вас похожий опыт и есть свои фишки и тулы, которыми готовы поделиться в комментах, буду рад 🤗
Если у вас похожий опыт и есть свои фишки и тулы, которыми готовы поделиться в комментах, буду рад 🤗
shesterov.by
Мой GTD: процесс, инструменты и советы
Опишу свою реализацию GTD-подхода (Getting Things Done) и то, зачем это мне, как я поменял исходный процесс, какие использую инструменты, плюс какие из полученных советов оказались наиболее ценными.
🔥13👍2👏1
Мы ещё не закончили с циклом типовых ошибок 😊 Пришла очередь для типовых проблем со скоупом (#21).
В предыдущих заметках мы затрагивали скоуп (границы, рамки, объем решения) и то, что его чаще всего представляют и поддерживают в виде функциональных возможностей (фич, features), вариантов использования (use cases, UC) и пользовательских историй (user stories, US). Давайте обсудим проблемы, которые чаще всего наблюдаются в скоупах, сформированных с помощью каждой из этих техник. Мы не будем обсуждать, а) чем каждая из проблем чревата, дабы не сильно удлинять опус — каждый сам может поразмыслить над тем, где кроются серьезные риски, а где — удобство восприятия; б) очевидные вещи, применимые к любому логическому набору требований, которые еще дядюшка Вигерс постулировал: полнота и непротиворечивость.
Фичи:
- Пропуски aka ни одна мелочь не должна остаться за кадром. Да, я упомянул, что неполнота — вещь очевидная, но тут я хотел бы акцентировать внимание именно на «мелочных деталях». Скоуп в виде фич — это распил решения на части. Если после такого распила остались опилки, которые не «приклеены» ни к одной доске, то их нет в решении. Часто, например, выделяют фичу Аутентификация, в описании или дальнейшей декомпозиции которой ни слова о выходе из системы (log out). Этот пункт актуален и для US, но не актуален для UC — UC не покрывают весь скоуп решения исходя из самой их сути, что делает их ограниченными в применимости для этой задачи.
- Неоднородность. Какие-то фичи — большие куски, другие — «мелочи», которые ценными кусками решения назвать сложно. Возьмем для примера Telegram. Работа с сообщениями и аудиозвонки — вполне зачетные фичи. Настройка аватарки — так себе, в сравнении. Почему вся работа с сообщениями — это один большой кусок, а из управления профилем как схожего по масштабу куска выделена одна только операция? Получается, что среди, условно, 20 элементов одним будет вся работа с сообщениями, а ещё 10 — это подпункты работы с профилем? Акценты тут точно верно выставлены? Пункт вполне себе применим и к US, когда одни эпики действительно эпичны, а другие порой меньше, чем отдельно взятая история. Для UC, при этом, это не особо актуально, т. к. сама техника диктует, чем должен быть каждый из UC, что и обеспечивает однородность (ниже рассмотрим это).
- Подача одним сплошным списком. Если фич немного — ок. Если их, например, 20+, то задумайтесь: не проще ли для восприятия и дальнейшего управления ими поделить решение вначале на 5 элементов, а затем каждый из них декомпозировать на ряд дочерних? Аналитик структурирует все, что можно структурировать. Если в вашем скоупе идут подряд такие фичи для Telegram, как Отправка сообщения, Редактирование сообщения, Настройка аватарки, Ночной режим и Редактирование параметров группы (или, что еще печальнее, они идут вперемешку), вселенная не шепчет, что их можно сгруппировать по функциональным областям / фичам более высокого уровня абстракции? Для US также есть понятие эпиков, которое можно еще дополнить рядом уровней: темы/стримы/любой_ваш_термин_позволяющий_выстроить_наглядную_структуру. UC, при этом, не могут быть разного уровня абстракции, но их также можно как визуально, так и в тексте сгруппировать по областям.
Варианты использования:
Проблемы с UC, как правило, вытекают из непонимания, что такое UC и каким качественно отдельно взятый UC должен быть. Сразу оговорюсь, что это все не есть заветы, высеченные на скрижалях, — опытный аналитик может осознанно нарушать пункты ниже. Но я бы не рекомендовал это делать из-за незнания или не понимая, серьезная это ошибка или оформительская мелочь.
- Когда UC — не операция. UC — это вариант использования, операция над решением. Если среди ваших UC Отправить сообщение, Создать группу и Совершить звонок затесалось что-то типа Интеграция с Google-аутентификацией, то вы смешиваете «Что полезного юзер может сделать с системой» с «Что в решении нужно реализовать».
В предыдущих заметках мы затрагивали скоуп (границы, рамки, объем решения) и то, что его чаще всего представляют и поддерживают в виде функциональных возможностей (фич, features), вариантов использования (use cases, UC) и пользовательских историй (user stories, US). Давайте обсудим проблемы, которые чаще всего наблюдаются в скоупах, сформированных с помощью каждой из этих техник. Мы не будем обсуждать, а) чем каждая из проблем чревата, дабы не сильно удлинять опус — каждый сам может поразмыслить над тем, где кроются серьезные риски, а где — удобство восприятия; б) очевидные вещи, применимые к любому логическому набору требований, которые еще дядюшка Вигерс постулировал: полнота и непротиворечивость.
Фичи:
- Пропуски aka ни одна мелочь не должна остаться за кадром. Да, я упомянул, что неполнота — вещь очевидная, но тут я хотел бы акцентировать внимание именно на «мелочных деталях». Скоуп в виде фич — это распил решения на части. Если после такого распила остались опилки, которые не «приклеены» ни к одной доске, то их нет в решении. Часто, например, выделяют фичу Аутентификация, в описании или дальнейшей декомпозиции которой ни слова о выходе из системы (log out). Этот пункт актуален и для US, но не актуален для UC — UC не покрывают весь скоуп решения исходя из самой их сути, что делает их ограниченными в применимости для этой задачи.
- Неоднородность. Какие-то фичи — большие куски, другие — «мелочи», которые ценными кусками решения назвать сложно. Возьмем для примера Telegram. Работа с сообщениями и аудиозвонки — вполне зачетные фичи. Настройка аватарки — так себе, в сравнении. Почему вся работа с сообщениями — это один большой кусок, а из управления профилем как схожего по масштабу куска выделена одна только операция? Получается, что среди, условно, 20 элементов одним будет вся работа с сообщениями, а ещё 10 — это подпункты работы с профилем? Акценты тут точно верно выставлены? Пункт вполне себе применим и к US, когда одни эпики действительно эпичны, а другие порой меньше, чем отдельно взятая история. Для UC, при этом, это не особо актуально, т. к. сама техника диктует, чем должен быть каждый из UC, что и обеспечивает однородность (ниже рассмотрим это).
- Подача одним сплошным списком. Если фич немного — ок. Если их, например, 20+, то задумайтесь: не проще ли для восприятия и дальнейшего управления ими поделить решение вначале на 5 элементов, а затем каждый из них декомпозировать на ряд дочерних? Аналитик структурирует все, что можно структурировать. Если в вашем скоупе идут подряд такие фичи для Telegram, как Отправка сообщения, Редактирование сообщения, Настройка аватарки, Ночной режим и Редактирование параметров группы (или, что еще печальнее, они идут вперемешку), вселенная не шепчет, что их можно сгруппировать по функциональным областям / фичам более высокого уровня абстракции? Для US также есть понятие эпиков, которое можно еще дополнить рядом уровней: темы/стримы/любой_ваш_термин_позволяющий_выстроить_наглядную_структуру. UC, при этом, не могут быть разного уровня абстракции, но их также можно как визуально, так и в тексте сгруппировать по областям.
Варианты использования:
Проблемы с UC, как правило, вытекают из непонимания, что такое UC и каким качественно отдельно взятый UC должен быть. Сразу оговорюсь, что это все не есть заветы, высеченные на скрижалях, — опытный аналитик может осознанно нарушать пункты ниже. Но я бы не рекомендовал это делать из-за незнания или не понимая, серьезная это ошибка или оформительская мелочь.
- Когда UC — не операция. UC — это вариант использования, операция над решением. Если среди ваших UC Отправить сообщение, Создать группу и Совершить звонок затесалось что-то типа Интеграция с Google-аутентификацией, то вы смешиваете «Что полезного юзер может сделать с системой» с «Что в решении нужно реализовать».
🔥7❤1
- Когда UC — не ценная для конечного юзера операция. Например, Выбрать получателя сообщения. Ну выбрал я его, а дальше что? Применимо ли такое в контексте «я иду в систему, чтобы выполнить UC и уйти из системы с полными штанами счастья?». Может, выбор получателя сообщения — это всего лишь шаг в рамках некоего действительного полезного для юзера UC? Да, если это априори не полезный UC (включаемый куда-то или расширяющий что-то) — вполне себе вариант, но не как самостоятельная операция в списке «что полезного можно сделать с системой».
- Когда UC — не разовая операция. Например, Управление сообщениями. Что это за действие такое? Аналитик в таком примере, вероятно, решил абстрагировать CRUDL для сообщений и иные дополнительные действия с ними в некую общую область, и это похвальная затея, но UC так не работают. Зачем нарушать понятие и специфики UC как техники, если можно просто очертить это областью или иным термином, который группирует UC по тематике?
- Когда актер для UC — не внешний агент. UC — это варианты использования решения: что с решением может сделать кто-то/что-то. Послать запрос в Google-аутентификатор, например, — это действие системы, которое, скорее всего, триггерится каким-то действием пользователя в рамках полезного для него UC. И UC как раз и будет полезная операция юзера над решением, которая будет как формулироваться иначе (например, Войти в систему с помощью Google-аккаунта), так и описываться внутри иначе и со стороны пользователя.
Пользовательские истории:
Описанное для фич выше актуально и для US, но есть и свои особенности. И вытекают они из того, что US в agile-контексте — это не только техника распила решения на единички скоупа с целью накопления поддерживаемой базы знаний. Это еще и постановки задачи, и элемент планирования и контроля проекта — если мы, конечно, про «правильные» US говорим.
- Нарушение Independent в INVEST. Сразу оговорюсь, что это актуально и для фич, просто для US это акцентировано явно.
Что может нарушить этот принцип? Во-первых, пересечение US. Например, Пересылка письма и Ответ на письмо как US для почтового клиента, если представить, что обе истории в плане критериев приемки включают в себя форматирование и отсылку конечного письма (т. е. разработчику нужно будет реализовывать одинаковые вещи в рамках обеих историй). Разбейте на три US: Отправка письма, Ответ на письмо и Пересылка письма. В таком случае общая часть будет реализована как постановка задачи до двух рассматриваемых историй, и пересечения не будет.
Второе, что нарушает зависимость, — это порядок реализации. Например, между историями Отправить письмо и Переслать письмо из примера выше выстроился определенный порядок реализации. Такая зависимость не страшна и без нее не обойтись в вашем бэклоге. Если это будет спланировано в контексте релизов так, чтобы не противоречило данной зависимости, то и не вопрос.
- Нарушение Small в INVEST. Давайте поделим то, что упомянули выше, на две сферы применимости US. Первая — это напилить систему на доски, чтобы понять скоуп (например, в рамках discovery для нового решения или в качестве обратного инжиниринга при формировании скоупа уже существующего решения). В это задаче — как и с фичами — без разницы, смолл или не смолл будут ваши единички скоупа. Но на каком-то этапе перед вашими US встают новые задачи: стать инструкцией для разработки/тестирования и единицей планирования в контексте проекта и его итераций. И вот уже для этой задачи классики гласят, что US должны быть small enough. Для каждой команды это означает свое (например, US должна влезать в спринт в плане сроков или в 1/6 спринта в плане трудоемкости), но в целом нужно иметь в виду, что в игру вступает еще и этот параметр, и помнить про SPIDR и refinement.
- Когда UC — не разовая операция. Например, Управление сообщениями. Что это за действие такое? Аналитик в таком примере, вероятно, решил абстрагировать CRUDL для сообщений и иные дополнительные действия с ними в некую общую область, и это похвальная затея, но UC так не работают. Зачем нарушать понятие и специфики UC как техники, если можно просто очертить это областью или иным термином, который группирует UC по тематике?
- Когда актер для UC — не внешний агент. UC — это варианты использования решения: что с решением может сделать кто-то/что-то. Послать запрос в Google-аутентификатор, например, — это действие системы, которое, скорее всего, триггерится каким-то действием пользователя в рамках полезного для него UC. И UC как раз и будет полезная операция юзера над решением, которая будет как формулироваться иначе (например, Войти в систему с помощью Google-аккаунта), так и описываться внутри иначе и со стороны пользователя.
Пользовательские истории:
Описанное для фич выше актуально и для US, но есть и свои особенности. И вытекают они из того, что US в agile-контексте — это не только техника распила решения на единички скоупа с целью накопления поддерживаемой базы знаний. Это еще и постановки задачи, и элемент планирования и контроля проекта — если мы, конечно, про «правильные» US говорим.
- Нарушение Independent в INVEST. Сразу оговорюсь, что это актуально и для фич, просто для US это акцентировано явно.
Что может нарушить этот принцип? Во-первых, пересечение US. Например, Пересылка письма и Ответ на письмо как US для почтового клиента, если представить, что обе истории в плане критериев приемки включают в себя форматирование и отсылку конечного письма (т. е. разработчику нужно будет реализовывать одинаковые вещи в рамках обеих историй). Разбейте на три US: Отправка письма, Ответ на письмо и Пересылка письма. В таком случае общая часть будет реализована как постановка задачи до двух рассматриваемых историй, и пересечения не будет.
Второе, что нарушает зависимость, — это порядок реализации. Например, между историями Отправить письмо и Переслать письмо из примера выше выстроился определенный порядок реализации. Такая зависимость не страшна и без нее не обойтись в вашем бэклоге. Если это будет спланировано в контексте релизов так, чтобы не противоречило данной зависимости, то и не вопрос.
- Нарушение Small в INVEST. Давайте поделим то, что упомянули выше, на две сферы применимости US. Первая — это напилить систему на доски, чтобы понять скоуп (например, в рамках discovery для нового решения или в качестве обратного инжиниринга при формировании скоупа уже существующего решения). В это задаче — как и с фичами — без разницы, смолл или не смолл будут ваши единички скоупа. Но на каком-то этапе перед вашими US встают новые задачи: стать инструкцией для разработки/тестирования и единицей планирования в контексте проекта и его итераций. И вот уже для этой задачи классики гласят, что US должны быть small enough. Для каждой команды это означает свое (например, US должна влезать в спринт в плане сроков или в 1/6 спринта в плане трудоемкости), но в целом нужно иметь в виду, что в игру вступает еще и этот параметр, и помнить про SPIDR и refinement.
🔥8👍1
- US попилена не как требования, а как кусок дизайна. Подобное, естественно, актуально и для фич и юз кейсов, но для них такая проблема наблюдается существенно реже — думается, из-за того, что фичи и юз кейсы редко отправляются как таски в разработку сами по себе. Например, Отправка сообщения в Телеграм — полезная штука для юзера. Мы можем эту US пилить и дальше — например, по SPIDR, но только если это по итогу все еще представляет ценность для юзера как кусок функциональности. Мы не можем пилить эту историю на девелопмент-задачи, например UI для отправки сообщения, Таблица и процедуры в БД для отправки сообщения и т. д. и все еще называть получившееся историями в скоупе решения.
- US не отражают эволюционную поставку. Сложно сказать, что это актуально для фич и UC — в этом пункте мы смотрим на US в контексте второй задачи: инструкция для разработки/тестирования и единица планирования в контексте проекта. Одной из специфик agile-проектов, как мы знаем, часто является стремление реализовать вначале самокат, а затем постепенное допиливание его до космического корабля. Благое стремление, но и ваш скоуп должен поддерживать это на этапе, когда эта самая вторая задача становится актуальной. Отправка сообщения — это не минимально возможная единица декомпозиции. Тот же SPIDR диктует нам, что по концепции «самокат -> космический корабль» мы можем вначале сделать простую отправку, потом — с аттачментом, затем — с форматированием, затем — с эмоджи, затем — со стикерами, затем — голосовые и т. п.
В общем и целом, буду рад комментариям, если не все типовые проблемы учел и вы встречаете иные косяки, которые делают скоупы проблемными. Плюс, если интересно раскрытие чего-либо из этого детальнее, также кричите 😊
- US не отражают эволюционную поставку. Сложно сказать, что это актуально для фич и UC — в этом пункте мы смотрим на US в контексте второй задачи: инструкция для разработки/тестирования и единица планирования в контексте проекта. Одной из специфик agile-проектов, как мы знаем, часто является стремление реализовать вначале самокат, а затем постепенное допиливание его до космического корабля. Благое стремление, но и ваш скоуп должен поддерживать это на этапе, когда эта самая вторая задача становится актуальной. Отправка сообщения — это не минимально возможная единица декомпозиции. Тот же SPIDR диктует нам, что по концепции «самокат -> космический корабль» мы можем вначале сделать простую отправку, потом — с аттачментом, затем — с форматированием, затем — с эмоджи, затем — со стикерами, затем — голосовые и т. п.
В общем и целом, буду рад комментариям, если не все типовые проблемы учел и вы встречаете иные косяки, которые делают скоупы проблемными. Плюс, если интересно раскрытие чего-либо из этого детальнее, также кричите 😊
🔥15
Сегодня затронем тему ассампшнов (assumptions, предположения, гипотезы, допущения). В контексте цикла ошибок её можно сформулировать как «отсутствие работы с ассампшнами» (#22), что может серьезно повлиять на качество прорабатываемой информации, включая требования. По наблюдениям, чем сеньорнее аналитик, тем активнее он в работе «обкладывается» ассампшнами — о причинах поговорим ниже.
Как обычно, начнем с кораблей, бороздящих просторы. Для аналитика любая информация, включая требования, может быть фактом или чем-то близким к нему, а может — предположением. Предположение — это некое утверждение, которое принимается за истину, когда нет возможности в этом удостовериться. Например, утверждения «В этом канале, в основном, постятся материалы по бизнес-анализу» и «В этом канале 300+ подписчиков» — на данный момент факты, а «Материалы канала подписчикам нравятся» — предположение, которое можно вывести из ряда косвенных наблюдений (наличие одних реакций, отсутствие других, общение с отдельными читателями) — нет разумной по эффортам возможности получить более достоверную и статистически полную информацию. При этом, любое предположение может оказаться неверным, в чем, собственно, и есть их суть.
Соответственно, аналитику полезно не просто аккуратно подмечать, где он оперирует фактами VS ассампшнами, а вести с ними отдельную работу (фиксировать в явном виде, трассировать на них связанную информацию/требования, периодически проверять их валидность — стали ли они фактом или были опровергнуты, плюс явно коммуницировать их стейкхолдерам).
Чем меньше у аналитика возможностей выяснить надёжную информацию, тем больше у него ассампшнов. Именно поэтому в пресейле это популярный инструмент. Когда пресейл-команде дают один созвон с заказчиком, после чего закрывают коммуникацию с источником информации, им придётся формировать коммерческое предложение, исходя из имеющихся предположений на базе намеков, здравого смысла и расклада Таро, ибо ответ “мы не можем предложить бюджет/сроки, у нас крайне мало информации” никого не устроит. Поэтому хорошие пропоузалы всегда имеют отдельную секцию Предположения, где описано то, на каких допущениях строится та или иная информация в документе.
Возьмем за пример планы на отпуск — это также проект, и у решения в контексте этого проекта есть требования, пусть вы и не пишете для них спецификацию. На этапе discovery вы прорабатываете бизнес-требования, суть/образ решения и его скоуп. Допустим, у вас есть некая цель («Релакснуть душой и телом»), есть уже конечное решение («Отпуск в Испании») и есть скоуп в виде каких-то единиц (к примеру, это наполнение отпуска как в плане подготовки, так и проведения: «Получить визу», «Купить билеты», «Забукать отель», «Посетить место А», «Отдохнуть в месте Б» и т. п.).
Что может стать причиной ассампшнов?
1) Невозможность проверить информацию в принципе, т. к. это гипотеза о том, что будет в будущем. Например, элемент «Получить визу» сработает, только если в момент обращения эти визы будут выдавать, что есть неопределенность. Соответственно, вполне себе ассамшпн здесь «В июле 2024 г. визу в Евросоюз в РБ возможно будет получить». Или же ваш спонсор на проекте (речь уже идет про категорию ЗЛ для IT-проекта, а не спонсора вашего отпуска) выдвигает бизнес-цель «Заработать миллион баксов на продаже продукта в течение месяца после его релиза». В попытках удостовериться в ачиваблности этой цели вы выходите на простую математику «100000 юзеров * 10$ за подписку». И если стоимость подписки — это факт, т. к. спонсор явно высказал вам, что планирует ее таковой сделать, то то, что 100000 юзеров приобретут и установят продукт — это точка вне вашего или его контроля; это гипотеза спонсора, которую он сформулировал на базе чего-либо (анализ схожих продуктов, опросы, влажные мечты и пр.). «100000 пользователей приобретут продукт в течение месяца» — это предположение.
Как обычно, начнем с кораблей, бороздящих просторы. Для аналитика любая информация, включая требования, может быть фактом или чем-то близким к нему, а может — предположением. Предположение — это некое утверждение, которое принимается за истину, когда нет возможности в этом удостовериться. Например, утверждения «В этом канале, в основном, постятся материалы по бизнес-анализу» и «В этом канале 300+ подписчиков» — на данный момент факты, а «Материалы канала подписчикам нравятся» — предположение, которое можно вывести из ряда косвенных наблюдений (наличие одних реакций, отсутствие других, общение с отдельными читателями) — нет разумной по эффортам возможности получить более достоверную и статистически полную информацию. При этом, любое предположение может оказаться неверным, в чем, собственно, и есть их суть.
Соответственно, аналитику полезно не просто аккуратно подмечать, где он оперирует фактами VS ассампшнами, а вести с ними отдельную работу (фиксировать в явном виде, трассировать на них связанную информацию/требования, периодически проверять их валидность — стали ли они фактом или были опровергнуты, плюс явно коммуницировать их стейкхолдерам).
Чем меньше у аналитика возможностей выяснить надёжную информацию, тем больше у него ассампшнов. Именно поэтому в пресейле это популярный инструмент. Когда пресейл-команде дают один созвон с заказчиком, после чего закрывают коммуникацию с источником информации, им придётся формировать коммерческое предложение, исходя из имеющихся предположений на базе намеков, здравого смысла и расклада Таро, ибо ответ “мы не можем предложить бюджет/сроки, у нас крайне мало информации” никого не устроит. Поэтому хорошие пропоузалы всегда имеют отдельную секцию Предположения, где описано то, на каких допущениях строится та или иная информация в документе.
Возьмем за пример планы на отпуск — это также проект, и у решения в контексте этого проекта есть требования, пусть вы и не пишете для них спецификацию. На этапе discovery вы прорабатываете бизнес-требования, суть/образ решения и его скоуп. Допустим, у вас есть некая цель («Релакснуть душой и телом»), есть уже конечное решение («Отпуск в Испании») и есть скоуп в виде каких-то единиц (к примеру, это наполнение отпуска как в плане подготовки, так и проведения: «Получить визу», «Купить билеты», «Забукать отель», «Посетить место А», «Отдохнуть в месте Б» и т. п.).
Что может стать причиной ассампшнов?
1) Невозможность проверить информацию в принципе, т. к. это гипотеза о том, что будет в будущем. Например, элемент «Получить визу» сработает, только если в момент обращения эти визы будут выдавать, что есть неопределенность. Соответственно, вполне себе ассамшпн здесь «В июле 2024 г. визу в Евросоюз в РБ возможно будет получить». Или же ваш спонсор на проекте (речь уже идет про категорию ЗЛ для IT-проекта, а не спонсора вашего отпуска) выдвигает бизнес-цель «Заработать миллион баксов на продаже продукта в течение месяца после его релиза». В попытках удостовериться в ачиваблности этой цели вы выходите на простую математику «100000 юзеров * 10$ за подписку». И если стоимость подписки — это факт, т. к. спонсор явно высказал вам, что планирует ее таковой сделать, то то, что 100000 юзеров приобретут и установят продукт — это точка вне вашего или его контроля; это гипотеза спонсора, которую он сформулировал на базе чего-либо (анализ схожих продуктов, опросы, влажные мечты и пр.). «100000 пользователей приобретут продукт в течение месяца» — это предположение.
2) Невозможность (или нежелание — но количество подобных ассампшнов лучше сокращать) вами или ЗЛ в моменте удостовериться в валидности информации. Например, на этапе планирования отпуска у вас нет возможности проверить, какая обычно погода в целевом месте в июле. Но вы, вроде как, слышали, что она подходит для релакса на пляже. Соответственно, вы строите выбор решения на ассампшне «В Испании в месте X в июле, как правило, подходящая для пляжа погода». Или, например, на этапе пресейла контакт со стороны заказчика говорит вам, что сотрудники его отдела не будут пользоваться мобильными устройствами для доступа к целевой системе. Хозяин-барин, конечно, но полезно было бы все же напрямую с пользователями проработать сценарии использования системы — мы знаем, что «передатчики» требований могут ошибаться, и в идеале всегда стоит выходить на авторов. Нам, однако, надо решать, будет ли адаптация веб-системы под девайсы частью пропоузала. Соответственно, отсутствие такой фичи в скоупе в пропоузале может базироваться на предположении «Сотрудники будут использовать систему только с настольных устройств».
3) Ассампшны, которые являются неявной установкой у вас или у ЗЛ. Подмечать подобное — отдельное искусство (ранее тут, кстати, была ссылка на статьи про когнитивные искажения, которые часто становятся причиной подобного). Например, «Пляжный отдых — лучший для меня вариант расслабона». Это может идти как установка по умолчанию, но полезно подвергать подобные вещи критическому осмыслению и смотреть на них с долей скепсиса. На этом ассампшне базируется выбор типа решения для достижения бизнес-требования, однако так ли вы уверены в том, что это истина? Стейкхолдер, например, говорит вам, что в его бизнес-процессе действие X приведет к повышению оценки его работы со стороны начальства, а потому в систему это пипец как надо заложить. Так ли это на самом деле или стейкхолдер оперирует некой гипотезой, основанной на сформировавшемся убеждении? Можно ли это перепроверить непосредственно у начальства?
Где пригодятся ассампшны: везде, где мы фиксируем информацию для ЗЛ — Vision and Scope, SRS, ТЗ, планы на БА, User Stories в Confluence и т. п. Ассампшны могут быть на уровне бизнес-требований, выбора и обоснования решения, скоупа решения, а могут быть и на более низких уровнях — в требованиях ЗЛ и к решению. Ассампшны могут также быть в описании бизнес-процессов, ваших планах на бизнес-анализ, описании технических решений — ну то есть везде, где мы оперируем информацией.
Что с ними нужно сделать:
1. Учиться подмечать, критически осмысливая получаемую и прорабатываемую нами самими информацию. Уверены ли мы или стейкхолдер в этой информации или это предположение, которое в идеале стоило бы валидировать (удостовериться в истинности и превратить в факт)? Лучше всего, конечно, сразу ассампшны устранять, т. к. они — источники неопределенности и несут риски.
2. Если превратить в факт не получается, то фиксировать отдельно (в отдельно вынесенном разделе или любым иным обособленным от основной информации способом) — глава Assumptions в V&S, глава Assumptions в SRS, отдельные страницы в Confluence, отдельные секции/разделы на уровне каждой User Story, отдельная ветка в вашей mind map (если вы в виде карты памяти, например, брейнстормите ваш отпуск) и т. п.
Зачем? Нам придется дальше с ними работать, и ассампшны, зашитые глубоко в 500-страничную документацию, мы едва ли выудим быстро и полно.
3. Трассировать на них информацию, которая на них базируется или от них зависит. Например, в vision statement для примера выше «Решением будет являться отдых в Испании в июле…» стоит встроить в явном виде трассировку на ассампшн про погоду, который сам по себе будет зафиксирован в отдельно вынесенном месте (см. п. 2): «Решением будет являться отдых в Испании в июле (см. AS-1)…»
3) Ассампшны, которые являются неявной установкой у вас или у ЗЛ. Подмечать подобное — отдельное искусство (ранее тут, кстати, была ссылка на статьи про когнитивные искажения, которые часто становятся причиной подобного). Например, «Пляжный отдых — лучший для меня вариант расслабона». Это может идти как установка по умолчанию, но полезно подвергать подобные вещи критическому осмыслению и смотреть на них с долей скепсиса. На этом ассампшне базируется выбор типа решения для достижения бизнес-требования, однако так ли вы уверены в том, что это истина? Стейкхолдер, например, говорит вам, что в его бизнес-процессе действие X приведет к повышению оценки его работы со стороны начальства, а потому в систему это пипец как надо заложить. Так ли это на самом деле или стейкхолдер оперирует некой гипотезой, основанной на сформировавшемся убеждении? Можно ли это перепроверить непосредственно у начальства?
Где пригодятся ассампшны: везде, где мы фиксируем информацию для ЗЛ — Vision and Scope, SRS, ТЗ, планы на БА, User Stories в Confluence и т. п. Ассампшны могут быть на уровне бизнес-требований, выбора и обоснования решения, скоупа решения, а могут быть и на более низких уровнях — в требованиях ЗЛ и к решению. Ассампшны могут также быть в описании бизнес-процессов, ваших планах на бизнес-анализ, описании технических решений — ну то есть везде, где мы оперируем информацией.
Что с ними нужно сделать:
1. Учиться подмечать, критически осмысливая получаемую и прорабатываемую нами самими информацию. Уверены ли мы или стейкхолдер в этой информации или это предположение, которое в идеале стоило бы валидировать (удостовериться в истинности и превратить в факт)? Лучше всего, конечно, сразу ассампшны устранять, т. к. они — источники неопределенности и несут риски.
2. Если превратить в факт не получается, то фиксировать отдельно (в отдельно вынесенном разделе или любым иным обособленным от основной информации способом) — глава Assumptions в V&S, глава Assumptions в SRS, отдельные страницы в Confluence, отдельные секции/разделы на уровне каждой User Story, отдельная ветка в вашей mind map (если вы в виде карты памяти, например, брейнстормите ваш отпуск) и т. п.
Зачем? Нам придется дальше с ними работать, и ассампшны, зашитые глубоко в 500-страничную документацию, мы едва ли выудим быстро и полно.
3. Трассировать на них информацию, которая на них базируется или от них зависит. Например, в vision statement для примера выше «Решением будет являться отдых в Испании в июле…» стоит встроить в явном виде трассировку на ассампшн про погоду, который сам по себе будет зафиксирован в отдельно вынесенном месте (см. п. 2): «Решением будет являться отдых в Испании в июле (см. AS-1)…»
Зачем? Как и любая трассировка — в первую очередь, для импакт анализа. Если мы получим информацию, которая подтвердит/опровергнет ассампшн, нужно точно понимать, на что это повлияет. Например, узнав, что погода в этом году в июле будет фиговой, мы быстрым поиском по ID найдем 5 связей ассампшна с планами/требованиями и быстро поймем, где и что нужно теперь менять.
4. В явном виде доносить и акцентировать их стейкхолдерам, когда мы коммуницируем информацию, основанную на них. Это могут быть подобные посылы:
- «Вот анализ решений и наши рекомендации. Обратите внимание на секцию «Предположения». Анализ решений и рекомендации справедливы только при условии, что сформулированные предположения верны.»
- «Вот наше коммерческое предложение. В секции с предположениями описано то, на чем мы основывались, формируя бюджет и сроки. Если у вас есть комментарии или возражения по поводу предположений, дайте знать, и мы переработаем предложение исходя из новых условий.»
Этот пункт часто используется для прикрытия собственной попы или попы команды, и вполне справедливо. В условиях нехватки информации легко сделать ошибку, которая будет стоит репутации или даже более серьезных санкций команде. «Мы сделаем этот кусок работы за месяц!» — заверение, которое строится на ряде ассампшнов («Если наше понимание фичи, описанное тут, верно», «Если ничего больше в плане требований не будет вкинуто», «Если вот у этого сервиса есть доступно описанный API и он актуален»). Одно дело, когда мы даем серьезные обещания без пояснения подобного контекста, другое — когда мы делаем явными подобные неявно подразумеваемые вещи — в канале уже была заметка на тему явной настройки ожиданий.
5. Периодически перепроверять актуальность ассампшнов. Можно привязать это к старту итераций или любым иным ключевым точкам, а можно просто по графику или принципу «когда глаз наткнется». С течением времени ситуация может проясняться, и ассампшны могут либо становиться фактами (что есть круто и нам нужно актуализировать это, убрав эти ассампшны), либо опровергаться — что, с одной стороны, не круто, т. к. может повлиять на актуальность связанных бизнес-целей, выбора решения, скоупа, требований к решению любого плана, сроки, бюджеты и пр., но с другой — очень крут сам факт того, что выстроив с ними работу, мы это подметили и дали знать об этом стейкхолдерам, а не просто пустили на самотек. Весьма вероятно, что подобное стейкхолдеры оценят и скажут нам «спасибо, бро, от души!».
4. В явном виде доносить и акцентировать их стейкхолдерам, когда мы коммуницируем информацию, основанную на них. Это могут быть подобные посылы:
- «Вот анализ решений и наши рекомендации. Обратите внимание на секцию «Предположения». Анализ решений и рекомендации справедливы только при условии, что сформулированные предположения верны.»
- «Вот наше коммерческое предложение. В секции с предположениями описано то, на чем мы основывались, формируя бюджет и сроки. Если у вас есть комментарии или возражения по поводу предположений, дайте знать, и мы переработаем предложение исходя из новых условий.»
Этот пункт часто используется для прикрытия собственной попы или попы команды, и вполне справедливо. В условиях нехватки информации легко сделать ошибку, которая будет стоит репутации или даже более серьезных санкций команде. «Мы сделаем этот кусок работы за месяц!» — заверение, которое строится на ряде ассампшнов («Если наше понимание фичи, описанное тут, верно», «Если ничего больше в плане требований не будет вкинуто», «Если вот у этого сервиса есть доступно описанный API и он актуален»). Одно дело, когда мы даем серьезные обещания без пояснения подобного контекста, другое — когда мы делаем явными подобные неявно подразумеваемые вещи — в канале уже была заметка на тему явной настройки ожиданий.
5. Периодически перепроверять актуальность ассампшнов. Можно привязать это к старту итераций или любым иным ключевым точкам, а можно просто по графику или принципу «когда глаз наткнется». С течением времени ситуация может проясняться, и ассампшны могут либо становиться фактами (что есть круто и нам нужно актуализировать это, убрав эти ассампшны), либо опровергаться — что, с одной стороны, не круто, т. к. может повлиять на актуальность связанных бизнес-целей, выбора решения, скоупа, требований к решению любого плана, сроки, бюджеты и пр., но с другой — очень крут сам факт того, что выстроив с ними работу, мы это подметили и дали знать об этом стейкхолдерам, а не просто пустили на самотек. Весьма вероятно, что подобное стейкхолдеры оценят и скажут нам «спасибо, бро, от души!».
🔥12👍2
Доброго понедельника всем!
Очередная порция материалов в вашу кибитку:
- О личных планах развития БА и матрице компетенций: https://www.youtube.com/watch?v=a1fivBqUmzo
Любопытный контент, на мой взгляд, начинается где-то в районе 52 минуты — частичный пример матрицы скиллов.
- From BA to Senior BA: 3 Tips — довольно очевидные, на первый взгляд, но очень верные замечания. Эти пункты часто были моей личной болью при “взращивании” сотрудников. В статье мало деталей и примеров, но она может заставить задуматься и искать, где и как копнуть глубже, особенно если трассировать при чтении на собственный опыт и текущую позицию.
- 4 Thinking Traps of Ineffective Leaders — так как у нас тут канал про лидерство и успешный успех, то вот. На самом деле, заменив “leader” на “BA”, советы не теряют в полезности.
- A comprehensive list of Scrum and Agile Terminology — Project management — черт его знает, кому интересно читать словари, но вдруг вы в моменте готовитесь к собеседованию 🙂 Именно этот словарик довольно хорош.
Очередная порция материалов в вашу кибитку:
- О личных планах развития БА и матрице компетенций: https://www.youtube.com/watch?v=a1fivBqUmzo
Любопытный контент, на мой взгляд, начинается где-то в районе 52 минуты — частичный пример матрицы скиллов.
- From BA to Senior BA: 3 Tips — довольно очевидные, на первый взгляд, но очень верные замечания. Эти пункты часто были моей личной болью при “взращивании” сотрудников. В статье мало деталей и примеров, но она может заставить задуматься и искать, где и как копнуть глубже, особенно если трассировать при чтении на собственный опыт и текущую позицию.
- 4 Thinking Traps of Ineffective Leaders — так как у нас тут канал про лидерство и успешный успех, то вот. На самом деле, заменив “leader” на “BA”, советы не теряют в полезности.
- A comprehensive list of Scrum and Agile Terminology — Project management — черт его знает, кому интересно читать словари, но вдруг вы в моменте готовитесь к собеседованию 🙂 Именно этот словарик довольно хорош.
❤12
Поделюсь парой недавних интересных менторских кейсов. Они объединены невеселой темой “На меня на работе глядят, как на чмо”. Может, пригодится кому-то в копилку идей для собственных ситуаций.
#1
Проблема:
ПМ не видит работу и постоянно на это намекает, а иногда даже открыто говорит: “Не особо понимаю, что ты там все это время делаешь — там работы по каждой задаче на пару часов”. При этом у самого аналитика — состояние лютой перегрузки. И из-за подобного диссонанса у человека сильная демотивация и ощущение “я что-то очень не умею и делаю совсем неправильно”.
Как решали:
1) Начали с того, чтобы понять, куда часики утекают: активный трэкинг рабочего времени. Провели такой эксперимент в течение недели. В целом, результат оказался вполне обоснованным и разумным, но, во-первых, страдала видимость работы для внешних наблюдателей (для начальника, в частности — эту часть отложили порешать чуть позже), а во-вторых — митинги, митинги, митинги: их оказалось безумно много, и аналитик сидит на них по принципу “авось будет что сказать”.
2) Решили проактивно показать трэкинг начальнику под соусом “спасибо за указание на проблему — я пытаюсь её усердно решать, и вот как…” Плюс предложили для начала переработать систему участия аналитика во встречах в качестве пробного решения.
Что получилось:
1) Начальник искренне респектнул за саму инициативу (что само по себе вин), при этом со скрипом, но согласился на то, чтобы аналитик участвовал только в ключевых митингах, где у него есть активная роль по умолчанию.
2) По итогам недельного “спринта” (решения, кстати, строили по принципу “планнинг - > спринт с регулярными апдейтами - > ретро”) времени у аналитика стало существенно больше, стресса — меньше. Люди стали чуть чаще ходить к аналитику за уточнениями вне встреч, но именно что “чуть” — катастрофы (внезапно, Карл) не случилось. Вспомнилось при этом недавно увиденное в соседнем чате: “Думаете, поменять хедер на сайте легко? Аналитик две недели будет на митингах сидеть, чтобы эту проблему решить” 😂 При этом уже начинают наблюдаться побочные эффекты в виде более крутых и надежных требований и иных полезных работ, на которые высвободилось время.
Итоговые мысли: Не раз наблюдал на своем и чужом опыте, что в одиночку взглянуть на свои процессы с высоты птичьего полета бывает сложным. Тут либо нужно взять паузу для очистки головы от тушения пожаров (что в условиях активных пожаров едва ли возможно), либо попросить кого-то посмотреть на процессы со стороны. В целом, планируем последить еще за тем, не нанесут ли эти меры долгосрочный вред проекту, но пока они выглядят как логичное рабочее решение.
#1
Проблема:
ПМ не видит работу и постоянно на это намекает, а иногда даже открыто говорит: “Не особо понимаю, что ты там все это время делаешь — там работы по каждой задаче на пару часов”. При этом у самого аналитика — состояние лютой перегрузки. И из-за подобного диссонанса у человека сильная демотивация и ощущение “я что-то очень не умею и делаю совсем неправильно”.
Как решали:
1) Начали с того, чтобы понять, куда часики утекают: активный трэкинг рабочего времени. Провели такой эксперимент в течение недели. В целом, результат оказался вполне обоснованным и разумным, но, во-первых, страдала видимость работы для внешних наблюдателей (для начальника, в частности — эту часть отложили порешать чуть позже), а во-вторых — митинги, митинги, митинги: их оказалось безумно много, и аналитик сидит на них по принципу “авось будет что сказать”.
2) Решили проактивно показать трэкинг начальнику под соусом “спасибо за указание на проблему — я пытаюсь её усердно решать, и вот как…” Плюс предложили для начала переработать систему участия аналитика во встречах в качестве пробного решения.
Что получилось:
1) Начальник искренне респектнул за саму инициативу (что само по себе вин), при этом со скрипом, но согласился на то, чтобы аналитик участвовал только в ключевых митингах, где у него есть активная роль по умолчанию.
2) По итогам недельного “спринта” (решения, кстати, строили по принципу “планнинг - > спринт с регулярными апдейтами - > ретро”) времени у аналитика стало существенно больше, стресса — меньше. Люди стали чуть чаще ходить к аналитику за уточнениями вне встреч, но именно что “чуть” — катастрофы (внезапно, Карл) не случилось. Вспомнилось при этом недавно увиденное в соседнем чате: “Думаете, поменять хедер на сайте легко? Аналитик две недели будет на митингах сидеть, чтобы эту проблему решить” 😂 При этом уже начинают наблюдаться побочные эффекты в виде более крутых и надежных требований и иных полезных работ, на которые высвободилось время.
Итоговые мысли: Не раз наблюдал на своем и чужом опыте, что в одиночку взглянуть на свои процессы с высоты птичьего полета бывает сложным. Тут либо нужно взять паузу для очистки головы от тушения пожаров (что в условиях активных пожаров едва ли возможно), либо попросить кого-то посмотреть на процессы со стороны. В целом, планируем последить еще за тем, не нанесут ли эти меры долгосрочный вред проекту, но пока они выглядят как логичное рабочее решение.
🔥14👍3
#2
Проблема:
снова у человека ощущение, что он — центр вселенной и работает всю работу в этом мире, при этом есть сигналы, что команда считает иначе: аналитик на проекте — тупо ради мебели. По итогу это “бьёт по самоидентификации”.
Как решали и что получилось:
1) Совместно строили Исикаву, пытаясь забрейнстормить, откуда идут подобные сигналы и чем они могут быть вызваны.
2). Пару девелоперов, с которыми есть более-чем-формально-рабочий контакт, попросили заполнить опросник под условным грифом “Я хочу быть лучше; что вы обо мне думаете и что я могу сделать, чтобы быть более полезной”.
3) Подтвердилась, хоть и на примере пары человек, гипотеза о том, что команда, как и в предыдущем кейсе, не видит работу. Аналитик много общается с заказчиком (почему-то практически всегда письменно, что отнимает тонны времени — с этим будем также пытаться работать), и это остаётся невидимым для команды от слова “совсем”. При этом часть с документированием требований (то, что, собственно, ярко видимо для команды) остаётся в просадке за счет многих факторов, но в основном по незнанию того, как оно может быть иным. Общий посыл, который словили: “Документация — полное гуано, брезгуем ей пользоваться, приходится постоянно спрашивать.” Плюс вскрылось, что техническая часть у аналитика страдает. А точнее её практически нет, что также влияет на то, что команда едва смотрит в сторону БА на встречах. Такое, кстати, я описывал вот тут.
4) Точечных решений было много, но ключевые такие:
- Построили план по приведению документации в порядок: перенос в Confluence, построение структуры, работа с требованиями к данным, НФТ и пр. В AS IS была фактически только постановка задач в Jira в относительно свободном формате. Те же девелоперы, которые участвовали в опросе, на примере прототипа сказали, что огонь огненный. Для этого, правда, серьёзно пришлось подтянуть теорию/практику по тому, какими бывают требования, как с ними работать и документировать, в частности.
- Построили планы на техническую прокачку. Будем наблюдать, как это повлияет на самоощущение от работы и восприятие участия аналитика со стороны.
Итоговые мысли: на мой взгляд, корень проблем тут в том, что аналитик начал работать по принципу “разберусь в процессе” — без качественной теоретической хотя бы подготовки. Я вижу большую ценность в грамотно структурированной теории в голове, о чем также не раз тут писал — не зная, как оно должно быть “по учебнику” и какие вариации могут быть на практике, сложно видеть недостатки собственных процессов. Да, можно учиться и на ходу, но только звезды могут сойтись как удачно (ментор на работе научит; теория выведется, причем правильно, из практики “наощупь”), так и не очень (потеря репутации в команде, негативное влияние на проект, сильно ограниченная применимость вне текущего места работы). Конечно, лучше поздно, чем никогда, и все эти проблемы решаемы, но не покидает мысль, что путь изначально мог быть более правильным и менее болезненным.
Проблема:
снова у человека ощущение, что он — центр вселенной и работает всю работу в этом мире, при этом есть сигналы, что команда считает иначе: аналитик на проекте — тупо ради мебели. По итогу это “бьёт по самоидентификации”.
Как решали и что получилось:
1) Совместно строили Исикаву, пытаясь забрейнстормить, откуда идут подобные сигналы и чем они могут быть вызваны.
2). Пару девелоперов, с которыми есть более-чем-формально-рабочий контакт, попросили заполнить опросник под условным грифом “Я хочу быть лучше; что вы обо мне думаете и что я могу сделать, чтобы быть более полезной”.
3) Подтвердилась, хоть и на примере пары человек, гипотеза о том, что команда, как и в предыдущем кейсе, не видит работу. Аналитик много общается с заказчиком (почему-то практически всегда письменно, что отнимает тонны времени — с этим будем также пытаться работать), и это остаётся невидимым для команды от слова “совсем”. При этом часть с документированием требований (то, что, собственно, ярко видимо для команды) остаётся в просадке за счет многих факторов, но в основном по незнанию того, как оно может быть иным. Общий посыл, который словили: “Документация — полное гуано, брезгуем ей пользоваться, приходится постоянно спрашивать.” Плюс вскрылось, что техническая часть у аналитика страдает. А точнее её практически нет, что также влияет на то, что команда едва смотрит в сторону БА на встречах. Такое, кстати, я описывал вот тут.
4) Точечных решений было много, но ключевые такие:
- Построили план по приведению документации в порядок: перенос в Confluence, построение структуры, работа с требованиями к данным, НФТ и пр. В AS IS была фактически только постановка задач в Jira в относительно свободном формате. Те же девелоперы, которые участвовали в опросе, на примере прототипа сказали, что огонь огненный. Для этого, правда, серьёзно пришлось подтянуть теорию/практику по тому, какими бывают требования, как с ними работать и документировать, в частности.
- Построили планы на техническую прокачку. Будем наблюдать, как это повлияет на самоощущение от работы и восприятие участия аналитика со стороны.
Итоговые мысли: на мой взгляд, корень проблем тут в том, что аналитик начал работать по принципу “разберусь в процессе” — без качественной теоретической хотя бы подготовки. Я вижу большую ценность в грамотно структурированной теории в голове, о чем также не раз тут писал — не зная, как оно должно быть “по учебнику” и какие вариации могут быть на практике, сложно видеть недостатки собственных процессов. Да, можно учиться и на ходу, но только звезды могут сойтись как удачно (ментор на работе научит; теория выведется, причем правильно, из практики “наощупь”), так и не очень (потеря репутации в команде, негативное влияние на проект, сильно ограниченная применимость вне текущего места работы). Конечно, лучше поздно, чем никогда, и все эти проблемы решаемы, но не покидает мысль, что путь изначально мог быть более правильным и менее болезненным.
🔥21👍1🫡1
Сегодня поговорим о user stories (US) и частых ошибках при их проработке (#23). Я затрагивал некоторые в предыдущих постах (тут и тут), но надежный как швейцарские час план подразумевает посвященный этому отдельный пост. При всем моем стремлении сделать это вкратце, заметка, скорее всего, в очередной раз задавит объемом: ну извините — как вы давно поняли, за форматом инстапостов не сюда 😊
1. US не отражают эволюцию продукта. Такое часто наблюдается, когда аналитик переходит в agile из традиционных подходов. Аналитик берет планируемую систему, нарезает ее на доски, и они становятся единицами скоупа, причем сложив эти доски воедино выходит полный статичный срез системы на какой-то момент времени. Что не учтено в этом, так это то, что US используются, как правило, в agile-разработке, которой свойственны короткие итерации и постоянная эволюция системы от MVP-самоката до космического корабля — это дает поэтапную проверку того, что мы делаем нужные вещи и быструю обратную связь от стейкхолдеров.
Как избегать: внимательно изучить SPIDR (подход к декомпозиции US) и всегда держать в голове, что подход «начинаем с малого и постепенно улучшаем» к любой функциональности может быть выигрышным для проекта (конечно, если подобное — в ногу с видением заказчика).
Например, у вас с заказчиком может быть вполне себе огненное видение фичи «Отправить письмо» для почтового клиента, который призван втоптать Outlook в грязь. И тут целесообразным может являться не кушать этот кусок целиком и сразу (хотя, если подумать, чем не фича или юз кейс сам по себе?), а разбить по Paths и Data из SPIDR, чтобы поставлять это постепенно: Отправка письма в базовом варианте, Указание СС, Указание BCC, Прикрепление файлов, Проверка заполненности темы и пр. — это разные истории в таком подходе.
2. Затронутый недавно в чате момент: нарезка «торта» по горизонтали, а не по вертикали. Да, user story — это постановка задачи (об этом детальнее поговорим в другом пункте), но это постановка задачи команде, а не ее отдельным ролям. User Story — это user (!) story. Это прирост функциональности, который несет ценность пользователям (может, кстати, и иным стейкхолдерам, а может — и прирост НЕфункциональности, но это уже полезные порой извращения за рамками темы). US — это не кусок БД или кода, который нужен для будущих свершений и который пользователи не заметят. Называйте такие куски кода тасками, спайками и пр., но краеугольным камнем бэклога являются полноценные куски торта, затрагивающие все его слои и несущие ценность для «едоков».
Как избегать: смотреть на US с описанной выше позиции и не дробить US на задачи отдельным исполнителям — команда сделает это без вас как аналитиков. Не работать с такими историями, как, например, БД для писем, UI для писем с мобилок, Структура микросервисов для отправки и т. п. Для юзера есть только Отправка письма, которую можно (и, скорее всего, стоит) разбить по примеру в пункте выше, а не на технические задачи фронтенду, бэкенду, DBA, дизайнеру и пр., называя их при этом все так же user stories.
3. «Большие» US. Все мы, надеюсь, в курсе про INVEST и Small в нем. И все равно зачастую не особо стремимся «декомпозировать, пока декомпозируется». Фишка в том, что с небольшими задачами команде обычно легче работать (до разумной степени, естественно), а US, еще раз напомню, — постановка задачи. Т. е. помимо эволюции продукта (пункт 1 выше) «дробление» US, скорее всего, облегчит команде планирование и контроль в рамках проекта.
1. US не отражают эволюцию продукта. Такое часто наблюдается, когда аналитик переходит в agile из традиционных подходов. Аналитик берет планируемую систему, нарезает ее на доски, и они становятся единицами скоупа, причем сложив эти доски воедино выходит полный статичный срез системы на какой-то момент времени. Что не учтено в этом, так это то, что US используются, как правило, в agile-разработке, которой свойственны короткие итерации и постоянная эволюция системы от MVP-самоката до космического корабля — это дает поэтапную проверку того, что мы делаем нужные вещи и быструю обратную связь от стейкхолдеров.
Как избегать: внимательно изучить SPIDR (подход к декомпозиции US) и всегда держать в голове, что подход «начинаем с малого и постепенно улучшаем» к любой функциональности может быть выигрышным для проекта (конечно, если подобное — в ногу с видением заказчика).
Например, у вас с заказчиком может быть вполне себе огненное видение фичи «Отправить письмо» для почтового клиента, который призван втоптать Outlook в грязь. И тут целесообразным может являться не кушать этот кусок целиком и сразу (хотя, если подумать, чем не фича или юз кейс сам по себе?), а разбить по Paths и Data из SPIDR, чтобы поставлять это постепенно: Отправка письма в базовом варианте, Указание СС, Указание BCC, Прикрепление файлов, Проверка заполненности темы и пр. — это разные истории в таком подходе.
2. Затронутый недавно в чате момент: нарезка «торта» по горизонтали, а не по вертикали. Да, user story — это постановка задачи (об этом детальнее поговорим в другом пункте), но это постановка задачи команде, а не ее отдельным ролям. User Story — это user (!) story. Это прирост функциональности, который несет ценность пользователям (может, кстати, и иным стейкхолдерам, а может — и прирост НЕфункциональности, но это уже полезные порой извращения за рамками темы). US — это не кусок БД или кода, который нужен для будущих свершений и который пользователи не заметят. Называйте такие куски кода тасками, спайками и пр., но краеугольным камнем бэклога являются полноценные куски торта, затрагивающие все его слои и несущие ценность для «едоков».
Как избегать: смотреть на US с описанной выше позиции и не дробить US на задачи отдельным исполнителям — команда сделает это без вас как аналитиков. Не работать с такими историями, как, например, БД для писем, UI для писем с мобилок, Структура микросервисов для отправки и т. п. Для юзера есть только Отправка письма, которую можно (и, скорее всего, стоит) разбить по примеру в пункте выше, а не на технические задачи фронтенду, бэкенду, DBA, дизайнеру и пр., называя их при этом все так же user stories.
3. «Большие» US. Все мы, надеюсь, в курсе про INVEST и Small в нем. И все равно зачастую не особо стремимся «декомпозировать, пока декомпозируется». Фишка в том, что с небольшими задачами команде обычно легче работать (до разумной степени, естественно), а US, еще раз напомню, — постановка задачи. Т. е. помимо эволюции продукта (пункт 1 выше) «дробление» US, скорее всего, облегчит команде планирование и контроль в рамках проекта.
👍8❤🔥1❤1