4. И последнее — подготовка участников. Подумайте над следующими вопросами:
4.1. Нужно ли обучить участников чему-либо, чтобы сама сессия прошла эффективно? Стоит ли, к примеру, тратить время на изучение того, что за техника такая под названием User Stories, если можно дать стейкхолдерам материалы, а саму сессию посвятить работе с ними? Стоит ли тратить время на обучение работе с Zoom? Может ли иметь смысл попросить людей познакомиться с какими-то вещами самостоятельно и заранее?
4.2. Необходимость изучения материалов. Если вы обсуждаете какой-то артефакт, допустим V&S, стоит ли попросить людей ознакомиться с ним до сессии, нежели устраивать сеанс группового чтения на встрече?
4.3. Обдумайте обязательно, полезным ли будет донести до стейкхолдеров повестку/агенду сессии. Если не хватает опыта для принятия осознанного решения — just do it. Тема эта весьма избита, и Интернет пестрит шаблонами и примерами — главное, не стремитесь обязательно накидать туда горы текста. Иногда один небольшой абзац — это уже отличная агенда, которая точно лучше описанного в первом пункте кейса с ПМом. Осмыслите следующие компоненты повестки (ее, кстати, можно в инвайт запихнуть, но имейте в виду, что не все такое видят и зачастую просто жмякают Accept машинально):
- Темы/цели — то, что вы обдумали в первом пункте, стоит сделать явным для участников (как в примере с внезапно прилетевшим чайка-ПМом, участникам тоже может хотеться обдумать, что и в каком ключе они будут доносить).
- Участники — ситуации могут быть разными, и иногда знать, кто будет на встрече, другим участникам таки нужно.
- Когда и сколько будет длиться.
- Где (ссылка в случае онлайна) будет проходить.
- Детализация — какие вопросы будут обсуждаться. Вероятно, люди смогут обдумать и подготовиться тщательнее, если они будут понимать в деталях, о чем на встрече будет идти речь. А может они еще и возьмут с собой кого-то, кто шарит в этом вопросе.
- Сопроводительные материалы для подготовки до встречи, если таковая необходима.
4.1. Нужно ли обучить участников чему-либо, чтобы сама сессия прошла эффективно? Стоит ли, к примеру, тратить время на изучение того, что за техника такая под названием User Stories, если можно дать стейкхолдерам материалы, а саму сессию посвятить работе с ними? Стоит ли тратить время на обучение работе с Zoom? Может ли иметь смысл попросить людей познакомиться с какими-то вещами самостоятельно и заранее?
4.2. Необходимость изучения материалов. Если вы обсуждаете какой-то артефакт, допустим V&S, стоит ли попросить людей ознакомиться с ним до сессии, нежели устраивать сеанс группового чтения на встрече?
4.3. Обдумайте обязательно, полезным ли будет донести до стейкхолдеров повестку/агенду сессии. Если не хватает опыта для принятия осознанного решения — just do it. Тема эта весьма избита, и Интернет пестрит шаблонами и примерами — главное, не стремитесь обязательно накидать туда горы текста. Иногда один небольшой абзац — это уже отличная агенда, которая точно лучше описанного в первом пункте кейса с ПМом. Осмыслите следующие компоненты повестки (ее, кстати, можно в инвайт запихнуть, но имейте в виду, что не все такое видят и зачастую просто жмякают Accept машинально):
- Темы/цели — то, что вы обдумали в первом пункте, стоит сделать явным для участников (как в примере с внезапно прилетевшим чайка-ПМом, участникам тоже может хотеться обдумать, что и в каком ключе они будут доносить).
- Участники — ситуации могут быть разными, и иногда знать, кто будет на встрече, другим участникам таки нужно.
- Когда и сколько будет длиться.
- Где (ссылка в случае онлайна) будет проходить.
- Детализация — какие вопросы будут обсуждаться. Вероятно, люди смогут обдумать и подготовиться тщательнее, если они будут понимать в деталях, о чем на встрече будет идти речь. А может они еще и возьмут с собой кого-то, кто шарит в этом вопросе.
- Сопроводительные материалы для подготовки до встречи, если таковая необходима.
🔥12❤2
Сегодня — о документации аналитика, и в первую очередь — о документировании требований в контексте постановки задачи на разработку или накопления базы знаний. Перечислю типовые ошибки (пусть это суммарно будет ошибка #18 — косяки в написании документации) и советы на их базе по написанию и оформлению документации, которые качнут вас на десяток левелов в глазах потребителей ваших трудов. Цель тут — не детализация каждого пункта вглубь, а широта охвата, чтобы вы могли взять себе это за чеклист и при желании пытаться в дальнейшем делать ваши письмена круче, поэтому это будет просто набор пунктов разной степени важности одним большим списком. Те, кто прошел тот или иной курс от ITMINE в последние пару лет, увидят много знакомых вещей, которые мы либо транслировали в виде чеклистов, либо правили/комментировали в работах, но все равно надеюсь, что пост будет полезным даже для выпускников — хотя бы освежить в памяти. Ну и постараюсь вкратце, дабы прямо совсем не перегрузить, но если нужно что-то раскрыть — сигнальте.
1) Использование синонимов для обозначения одних и тех же вещей. Критичность: высокая. Например, в спецификации требований вы используете слова «экран», «форма», «страница» для обозначения одного и того же UI-элемента. Или, что еще опаснее, используете в описании бизнеса заказчика синонимичные термины («заявка», «заявление», «запрос»). Последствия: ошибки в требованиях, усложнение их поддержки, вопросы или неверная трактовка со стороны читателей. В контексте технических терминов выберите наиболее точный и используйте только его. В контексте домена заказчика создайте глоссарий терминов и дайте каждому точное определение. Если есть синонимы, которые не меняют значение, укажите их в глоссарии, но в текстах все равно используйте только одно из значений.
2) Пассивный залог в формулировках вместо активного («кто что делает»). Критичность: высокая, если это относится к требованиям. «Когда пользователь нажимает на кнопку «Сохранить», должна появляться форма подачи заявки.» В данном примере последствия несущественны — едва ли кто-то поймет это как мистическое явление, а не как действие системы. Но часто бывают ситуации, когда понимать исполнителя необходимо, как в контексте бизнеса, так и требований, причем и вам (для полноты информации, с которой вы работаете), и читателям. А пассивный залог его скрывает: «Когда клиент подает заявку, она обрабатывается в течение пары дней». Гораздо удобнее ввести себе в жесткое правило использовать только активный залог, чтобы и самим заметить нехватку информации, и у читателя не оставить вопросов. «Когда пользователь нажимает на кнопку «Сохранить», система должна отобразить форму подачи заявки.»
3) Субъективные оценки. Критичность: высокая. Аналитик оперирует фактами. От оценок, которые другие люди могут подвергнуть сомнению, аналитик должен стараться избавляться. Давайте вспомним тут ряд запретных слов по мнению дядюшки Карла, которые как раз об этом: приемлемо, адекватно, (не)эффективно, быстро, легко, просто и т. п. Любое подобное слово — маркер того, что вы совершаете эту ошибку, причем как в описании домена, так и в подаче требований. Примеры в разных контекстах:
«Сделать процесс работы с документацией удобным» — бизнес-требование. Кто будет решать, в какой точке требование становится реализованным? Чья шкала удобства берется за эталон? А другие стейкхолдеры ее точно понимают и принимают? Измерить реализацию подобного требования и добиться согласия ЗЛ невозможно — SMART вам в помощь.
1) Использование синонимов для обозначения одних и тех же вещей. Критичность: высокая. Например, в спецификации требований вы используете слова «экран», «форма», «страница» для обозначения одного и того же UI-элемента. Или, что еще опаснее, используете в описании бизнеса заказчика синонимичные термины («заявка», «заявление», «запрос»). Последствия: ошибки в требованиях, усложнение их поддержки, вопросы или неверная трактовка со стороны читателей. В контексте технических терминов выберите наиболее точный и используйте только его. В контексте домена заказчика создайте глоссарий терминов и дайте каждому точное определение. Если есть синонимы, которые не меняют значение, укажите их в глоссарии, но в текстах все равно используйте только одно из значений.
2) Пассивный залог в формулировках вместо активного («кто что делает»). Критичность: высокая, если это относится к требованиям. «Когда пользователь нажимает на кнопку «Сохранить», должна появляться форма подачи заявки.» В данном примере последствия несущественны — едва ли кто-то поймет это как мистическое явление, а не как действие системы. Но часто бывают ситуации, когда понимать исполнителя необходимо, как в контексте бизнеса, так и требований, причем и вам (для полноты информации, с которой вы работаете), и читателям. А пассивный залог его скрывает: «Когда клиент подает заявку, она обрабатывается в течение пары дней». Гораздо удобнее ввести себе в жесткое правило использовать только активный залог, чтобы и самим заметить нехватку информации, и у читателя не оставить вопросов. «Когда пользователь нажимает на кнопку «Сохранить», система должна отобразить форму подачи заявки.»
3) Субъективные оценки. Критичность: высокая. Аналитик оперирует фактами. От оценок, которые другие люди могут подвергнуть сомнению, аналитик должен стараться избавляться. Давайте вспомним тут ряд запретных слов по мнению дядюшки Карла, которые как раз об этом: приемлемо, адекватно, (не)эффективно, быстро, легко, просто и т. п. Любое подобное слово — маркер того, что вы совершаете эту ошибку, причем как в описании домена, так и в подаче требований. Примеры в разных контекстах:
«Сделать процесс работы с документацией удобным» — бизнес-требование. Кто будет решать, в какой точке требование становится реализованным? Чья шкала удобства берется за эталон? А другие стейкхолдеры ее точно понимают и принимают? Измерить реализацию подобного требования и добиться согласия ЗЛ невозможно — SMART вам в помощь.
❤7
«Решение призвано сделать процесс обработки заявки быстрым» — часть образа решения. А что, если в процессе приемки решения заказчик скажет: «Не, че то процесс не быстрый»? Как будете доказывать обратное? Числовые показатели, конечно, решат проблему, но если в текущем контексте в них нет необходимости, то хотя бы постарайтесь использовать сравнительные характеристики: «Процесс обработки заявки будет идти быстрее, чем в текущей реализации»; «Коробочное решение будет иметь более низкую стоимость, чем разработка с нуля» (вместо «Купить коробку будет дешево») — так вы перешли в плоскость фактов, а не личной оценки.
«Система должна быть надежной, безопасной и т. д.» — требование к решению. Тут очевидно, что нарушен ряд известных нам качеств требований и такое требование невозможно однозначно понять, реализовать и проверить.
Отдельно стоит отметить субъективные оценки с негативной коннотацией. Например, вы пишете в описании AS IS такие вещи: «Отдел работает неэффективно», «Менеджер обрабатывает заявки непродуктивно». Тут добавляется к описанному выше еще и риск нездоровой реакции со стороны стейкхолдеров, которые могут обидеться на подобное описание их деятельности.
4) Неоднозначные показатели. Снова обратимся к дядюшке Карлу и его списку матных слов: между, не более чем, как минимум, не превышая и т. п. Критичность их использования варьируется, но рекомендация тут — добавить везде, где возможно, точность.
Например, вместо «Если кредитный рейтинг человека между 1 и 100, система должна…» используйте «Если кредитный рейтинг человека >=1 и <=100» или нечто похожее, не вызывающее двусмысленных толкований.
5) Правописание (орфография, пунктуация и иже с ними). Критичность: от незначительной до высокой. Если вы — сториписец в условиях аврала и демократичных стейкхолдеров, то черт с ним. Если вы готовите пропоузал для высокобюджетного проекта от серьезной организации — это может заруинить вам проект. При этом, если вы умеете по щелчку переключать контексты, то огонь, но чаще встречаю иное — банальное неумение написать документацию грамотно. Учитывая, что критичность в некоторых ситуациях может быть огромной, считаю подобный скилл a must для хорошего аналитика. Например, откровенная неграмотность в резюме — для меня серьезный маркер в минус. Что тут можно добавить: 1) Включите и научитесь замечать сигналы проверки правописания в любых инструментах, где вы документируете. С распространением AI задача еще более упрощается. 2) Качайте навыки правописания у себя, придавая этому значение. 3) Внимательность, личная вычитка после написания, ревью другими людьми.
Отдельно отмечу ошибки в написании имен собственных, имеющих отношение к стейкхолдерам. Например, вы ошибаетесь в написании имени человека, названии его организации, систем и пр. — по невнимательности или халатности. В таких случаях остается только полагаться на то, что вы по жизни удачливый человек.
6) Дефисы вместо тире. Критичность: минимальная. Это, скорее, точка улучшения вашей документации и показатель скрупулезного отношения к документации. Как это делать: 1) настройка автозамен в Word и пр. инструментах, 2) специальный софт — например, я пользую вот это: https://cemrajc.github.io/em-n-en/, и на тире у меня стоит отдельное сочетание клавиш.
7) Небрежность в оформлении. Критичность: средняя, но в целом, как и с правописанием, зависит от задачи и контекста. И, как и с правописанием, стоит научиться подстраиваться и забивать на это, если необходимости нет, чем банально не уметь сделать классно оформленный документ. Сюда может входить много нюансов, включая степень освоения целевого инструмента, например:
- Ручная нумерация пунктов вместо использования средств инструмента (и вызванные ей ошибки — лишние пробелы, неконсистентное оформление, сбитая нумерация и пр.)
- Неоднотипное оформление (таблиц и их отдельных элементов, картинок, шрифтов, их размеров, отступов, межстрочных интервалов, заголовков, формат дат, выравнивания текста).
«Система должна быть надежной, безопасной и т. д.» — требование к решению. Тут очевидно, что нарушен ряд известных нам качеств требований и такое требование невозможно однозначно понять, реализовать и проверить.
Отдельно стоит отметить субъективные оценки с негативной коннотацией. Например, вы пишете в описании AS IS такие вещи: «Отдел работает неэффективно», «Менеджер обрабатывает заявки непродуктивно». Тут добавляется к описанному выше еще и риск нездоровой реакции со стороны стейкхолдеров, которые могут обидеться на подобное описание их деятельности.
4) Неоднозначные показатели. Снова обратимся к дядюшке Карлу и его списку матных слов: между, не более чем, как минимум, не превышая и т. п. Критичность их использования варьируется, но рекомендация тут — добавить везде, где возможно, точность.
Например, вместо «Если кредитный рейтинг человека между 1 и 100, система должна…» используйте «Если кредитный рейтинг человека >=1 и <=100» или нечто похожее, не вызывающее двусмысленных толкований.
5) Правописание (орфография, пунктуация и иже с ними). Критичность: от незначительной до высокой. Если вы — сториписец в условиях аврала и демократичных стейкхолдеров, то черт с ним. Если вы готовите пропоузал для высокобюджетного проекта от серьезной организации — это может заруинить вам проект. При этом, если вы умеете по щелчку переключать контексты, то огонь, но чаще встречаю иное — банальное неумение написать документацию грамотно. Учитывая, что критичность в некоторых ситуациях может быть огромной, считаю подобный скилл a must для хорошего аналитика. Например, откровенная неграмотность в резюме — для меня серьезный маркер в минус. Что тут можно добавить: 1) Включите и научитесь замечать сигналы проверки правописания в любых инструментах, где вы документируете. С распространением AI задача еще более упрощается. 2) Качайте навыки правописания у себя, придавая этому значение. 3) Внимательность, личная вычитка после написания, ревью другими людьми.
Отдельно отмечу ошибки в написании имен собственных, имеющих отношение к стейкхолдерам. Например, вы ошибаетесь в написании имени человека, названии его организации, систем и пр. — по невнимательности или халатности. В таких случаях остается только полагаться на то, что вы по жизни удачливый человек.
6) Дефисы вместо тире. Критичность: минимальная. Это, скорее, точка улучшения вашей документации и показатель скрупулезного отношения к документации. Как это делать: 1) настройка автозамен в Word и пр. инструментах, 2) специальный софт — например, я пользую вот это: https://cemrajc.github.io/em-n-en/, и на тире у меня стоит отдельное сочетание клавиш.
7) Небрежность в оформлении. Критичность: средняя, но в целом, как и с правописанием, зависит от задачи и контекста. И, как и с правописанием, стоит научиться подстраиваться и забивать на это, если необходимости нет, чем банально не уметь сделать классно оформленный документ. Сюда может входить много нюансов, включая степень освоения целевого инструмента, например:
- Ручная нумерация пунктов вместо использования средств инструмента (и вызванные ей ошибки — лишние пробелы, неконсистентное оформление, сбитая нумерация и пр.)
- Неоднотипное оформление (таблиц и их отдельных элементов, картинок, шрифтов, их размеров, отступов, межстрочных интервалов, заголовков, формат дат, выравнивания текста).
❤4
- Отсутствующие, нерабочие или перекрашенные гиперссылки (трассировка вообще должна быть везде в явном виде, где она по контексту подразумевается, но это отдельная тема для обсуждения), плюс включение лишних элементов текста в ссылки.
- Неактуализированное содержание.
- Неоднообразная пунктуация в конце элементов списка.
- Отсутствующие колонтитулы с важной информацией (например, название документа и номера страниц — помните о том, что ваши труды могут печатать для дальнейшего пользования в этом формате).
- Слабое разрешение изображений и/или их нечитаемость в плане размера в печатной версии.
8) Обрывочные формулировки вместо полноценных предложений. Критичность: средняя. Иногда это просто показатель того, что вам больше по душе Твиттер, чем книги, а иногда такие вещи влияют на полноту информации для читателей. Например, из раздела Предположения (Assumptions): Выгрузка отчетности в PDF. Что это значит, в чем тут предположение конкретно? Нужно гадать или тратить время на уточнение, и только лишь потому, что аналитику было лень постучать по клавишам и написать больше букв. Читайте хорошую документацию, берите язык в ней за пример и не ленитесь всегда формулировать полные предложения в вашей документации (ага, эти ваши подлежащие и сказуемые) вместо обрывков и хэштэгов.
9) Нечистота языка 😁 Как и с рядом предыдущих пунктов, к этому нужно подходить с учетом контекста, а потому это может быть как проблемой, так и наоборот — рекомендацией. Помните о том, что лучше говорить с ЗЛ на их языке. Формулировка «Система должна проверить валидность аккаунта в процессе логина» может быть отличным способом коммуникации требований для команды, но при этом быть грустяшкой для сугубо русскоязычного заказчика в рамках коммерческого предложения для его организации. И в таком случае нужен иной вариант, типа такого: «Система должна проверить корректность учетной записи в процессе входа.»
10) Просторечные для формальной документации слова. Критичность: низкая, но в формальной документации, особенно в случае ее важности, может серьезно подпортить впечатление. Типичный пример: функционал. Вообще, это снова об органичных в контексте формальной документации формулировках, и исправляется это при отсутствии опыта снова-таки постоянным изучением хороших примеров (ну или ментором, который заметит подобное, пояснит и исправит).
Пример (Vision statement):
Будем делать для компании веб программку Best Web Soft, которая будет работать с Google API, где работники компании смогут заказать еду, а бухгалтер — смотреть на заказы, чтобы понять, сколько они стоят. Эта программа будет лучше, чем сейчас, потому что работникам удобнее заказать за компьютером, чем ходить в кафе, и вообще мы сможем легко добавлять новый функционал.
Подозреваю, что первое впечатление после прочтения — корявенько как-то в плане языка 😊 Да и без проблем, главное, чтобы читатели поняли, но вернемся к контексту, описанному ранее — в формальной документации такой язык едва ли позитивно охарактеризует опыт автора.
А как воспринимается такой вариант?
Решением для организации X является веб-приложение под названием Best Web Soft, интегрированное с Google API, с помощью которого сотрудники организации смогут осуществлять заказ еды удаленно, а бухгалтер — просматривать детали заказов с целью изучения их стоимости. В отличие от текущего процесса заказа еды сотрудниками, решение сделает процесс более удобным за счет отсутствия необходимости покидать рабочее место и возможности прямой доставки заказов. Преимуществом собственной разработки решения является возможность расширения его функциональности по мере необходимости.
- Неактуализированное содержание.
- Неоднообразная пунктуация в конце элементов списка.
- Отсутствующие колонтитулы с важной информацией (например, название документа и номера страниц — помните о том, что ваши труды могут печатать для дальнейшего пользования в этом формате).
- Слабое разрешение изображений и/или их нечитаемость в плане размера в печатной версии.
8) Обрывочные формулировки вместо полноценных предложений. Критичность: средняя. Иногда это просто показатель того, что вам больше по душе Твиттер, чем книги, а иногда такие вещи влияют на полноту информации для читателей. Например, из раздела Предположения (Assumptions): Выгрузка отчетности в PDF. Что это значит, в чем тут предположение конкретно? Нужно гадать или тратить время на уточнение, и только лишь потому, что аналитику было лень постучать по клавишам и написать больше букв. Читайте хорошую документацию, берите язык в ней за пример и не ленитесь всегда формулировать полные предложения в вашей документации (ага, эти ваши подлежащие и сказуемые) вместо обрывков и хэштэгов.
9) Нечистота языка 😁 Как и с рядом предыдущих пунктов, к этому нужно подходить с учетом контекста, а потому это может быть как проблемой, так и наоборот — рекомендацией. Помните о том, что лучше говорить с ЗЛ на их языке. Формулировка «Система должна проверить валидность аккаунта в процессе логина» может быть отличным способом коммуникации требований для команды, но при этом быть грустяшкой для сугубо русскоязычного заказчика в рамках коммерческого предложения для его организации. И в таком случае нужен иной вариант, типа такого: «Система должна проверить корректность учетной записи в процессе входа.»
10) Просторечные для формальной документации слова. Критичность: низкая, но в формальной документации, особенно в случае ее важности, может серьезно подпортить впечатление. Типичный пример: функционал. Вообще, это снова об органичных в контексте формальной документации формулировках, и исправляется это при отсутствии опыта снова-таки постоянным изучением хороших примеров (ну или ментором, который заметит подобное, пояснит и исправит).
Пример (Vision statement):
Будем делать для компании веб программку Best Web Soft, которая будет работать с Google API, где работники компании смогут заказать еду, а бухгалтер — смотреть на заказы, чтобы понять, сколько они стоят. Эта программа будет лучше, чем сейчас, потому что работникам удобнее заказать за компьютером, чем ходить в кафе, и вообще мы сможем легко добавлять новый функционал.
Подозреваю, что первое впечатление после прочтения — корявенько как-то в плане языка 😊 Да и без проблем, главное, чтобы читатели поняли, но вернемся к контексту, описанному ранее — в формальной документации такой язык едва ли позитивно охарактеризует опыт автора.
А как воспринимается такой вариант?
Решением для организации X является веб-приложение под названием Best Web Soft, интегрированное с Google API, с помощью которого сотрудники организации смогут осуществлять заказ еды удаленно, а бухгалтер — просматривать детали заказов с целью изучения их стоимости. В отличие от текущего процесса заказа еды сотрудниками, решение сделает процесс более удобным за счет отсутствия необходимости покидать рабочее место и возможности прямой доставки заказов. Преимуществом собственной разработки решения является возможность расширения его функциональности по мере необходимости.
11) Неоднообразие в формулировках требований: система должна, я «вижу» (например, в критериях приемки), система делает, система будет делать и т. п. Критичность: низкая. То бишь этот пункт — это также просто показатель того, как круто вы умеете писать документацию и насколько внимательно относитесь к этой работе. Рекомендую выбрать наиболее подходящую для вас систему формулировок и строго ее придерживаться (вообще, если заметили принцип, однообразие/консистентность в чем угодно — это прямо про аналитика). И если вы решили именно так формулировать требования («Если при нажатии Пользователем на кнопку «Войти», поле «Логин» не заполнено, система должна отобразить «Чувак, введи сюда инфу»), то не стоит иные требования формулировать по-иному («Нажимая на кнопку… Пользователь видит», «По нажатию на кнопку… Система показывает…», «Система покажет…», «Будет отображено…», «По нажатию… появляется…»).
12) Неструктурированная подача информации. Критичность — от средней до высокой. Аналитик — о систематизации/структуризации информации. Например, то, что я перечислил все эти пункты одним списком, а не сгруппировал их по критичности, области применения и прочим признакам, плюс не подал в виде таблицы (Пункт, Критичность, Формулировка проблемы, Примеры, Формулировка рекомендаций, Исправленные примеры), уже вызывает какую-то внутреннюю боль 😊 Но это осознанное упрощение. Часто, при этом, вижу неумение структурировать подачу, и на выходе мы получаем эссе в свободной форме, крайне тяжелое для восприятия. Лучшие друзья аналитика в плане подачи информации: абзацы, разделы и главы, пустые строки, списки (нумерованные и нет, многоуровневые и нет), таблицы (для многомерной информации), диаграммы, визуальная маркировка для привлечения внимания (жирный, курсив, подчеркивания, цвет и пр.). Не пишите, пожалуйста, сплошные полотна однообразного текста — восприятие текста потребителями таки важно. Если что-то структурируется (списком, таблицей, разделами) — сделайте это, вы не проиграете.
12) Неструктурированная подача информации. Критичность — от средней до высокой. Аналитик — о систематизации/структуризации информации. Например, то, что я перечислил все эти пункты одним списком, а не сгруппировал их по критичности, области применения и прочим признакам, плюс не подал в виде таблицы (Пункт, Критичность, Формулировка проблемы, Примеры, Формулировка рекомендаций, Исправленные примеры), уже вызывает какую-то внутреннюю боль 😊 Но это осознанное упрощение. Часто, при этом, вижу неумение структурировать подачу, и на выходе мы получаем эссе в свободной форме, крайне тяжелое для восприятия. Лучшие друзья аналитика в плане подачи информации: абзацы, разделы и главы, пустые строки, списки (нумерованные и нет, многоуровневые и нет), таблицы (для многомерной информации), диаграммы, визуальная маркировка для привлечения внимания (жирный, курсив, подчеркивания, цвет и пр.). Не пишите, пожалуйста, сплошные полотна однообразного текста — восприятие текста потребителями таки важно. Если что-то структурируется (списком, таблицей, разделами) — сделайте это, вы не проиграете.
🔥13👍4❤2
Привет всем,
Пара небольших новостей:
- “Большие” материалы, на которые я иногда ссылался в заметках, переехали в причесанном и профильтрованном виде вот сюда: https://www.shesterov.by/. Ссылки в заметках в канале поправил. За багрепорты и UX-проблемы в личку буду признателен 🙂
- Для наших курсов в формате lite и medium мы сделали пробный доступ, чтобы можно было поглядеть на примеры материалов (для тех, кто ранее не пользовался онлайн-материалами от ITMINE). Как туда достучаться, описано на страничках курсов в разделе “Компоненты обучения” -> “Пример материалов”. Не то, чтобы процесс идеально удобен, но как смогли 🙂 По багам — аналогично.
Пара небольших новостей:
- “Большие” материалы, на которые я иногда ссылался в заметках, переехали в причесанном и профильтрованном виде вот сюда: https://www.shesterov.by/. Ссылки в заметках в канале поправил. За багрепорты и UX-проблемы в личку буду признателен 🙂
- Для наших курсов в формате lite и medium мы сделали пробный доступ, чтобы можно было поглядеть на примеры материалов (для тех, кто ранее не пользовался онлайн-материалами от ITMINE). Как туда достучаться, описано на страничках курсов в разделе “Компоненты обучения” -> “Пример материалов”. Не то, чтобы процесс идеально удобен, но как смогли 🙂 По багам — аналогично.
🔥16👍4⚡1
Салют!
Следующая проблема/ошибка в нашем цикле — это отсутствие работы с рисками в контексте бизнес-анализа на проекте (#19). По-хорошему, тут можно подняться выше и сформулировать проблему как “отсутствие планирования своей работы в целом” (работа с рисками — это всего-лишь небольшая часть планирования бизнес-анализа). Правда, тогда это будут кэпские постулаты в духе “думайте заранее, как будете работать работу, а не действуйте импульсивно, на базе того, с какой ноги сегодня встали”. Я немного затрону планирование в целом, но фокус будет на чаще всего упускаемой его части — работе с рисками. Многие либо не знают, что это можно и стоит делать, либо ленятся таким заниматься, но те, кто с рисками хоть немного работают, получают обычно от этого жирные плюшки.
В книжках и курсах тема про планирование деятельности обычно самая нудная. Мне эта тема тоже долгое время напоминала некоторые курсы университетских времен, когда читаешь какую-нибудь там теорию проектного управления и тонешь в этом гипнотизирующем словоблудии. И BABOK в ту же степь: он настолько преисполнился в своей абстракции, что понять, а что конкретно делать надо, бывает весьма сложно. Давайте попробуем поговорить о планировании БА и рисках в частности, но на нашем деревенском диалекте.
Планирование чего-либо — это подумать о том, как вы будете это что-то делать, заранее. Например, вы собираетесь в отпуск — наверняка вы обдумываете ключевые моменты заранее: куда, когда, чем вы там заниматься будете, сколько бабла с собой взять и как не забыть зарядку от смартфона и активированный уголь. Вот и с работой так же. К сожалению или к счастью, работа аналитика — это не таск, прилетевший в трэкере и триггерящий старт работы. Это мини-проект. Тебе говорят (или ты своей головой понимаешь), что яма должна быть выкопана. Как хочешь копай, но яма должна быть выкопана асап. И надо сесть и подумать, как это осуществить, где найти лопату и как не сломать ее в процессе. Наверное, основное, что нужно понять, чтобы не лишиться разума в процессе изучения темы, это то, что планирование ≠ созданию мудреных артефактов под названием BA Plan, BA Approach и им подобных. Сесть и подумать полчаса о том, каков он — предварительный план действий — и раскидать ближайшие шаги в майндмэпе — это тоже планирование БА как область знаний из BABOK. И этого будет достаточно для многих проектов, если к плану периодически возвращаться по мере прояснения дорожной карты. Причем думать лучше не в пустоту, а взяв чеклист для подобного плана, который предлагают хорошие книжки, курсы или ваш личный опыт.
Соответственно, один из пунктов при планировании БА — это работа с рисками. Это подразумевает подумать множко или немножко про то, что может пойти не так, на базе видимых сейчас предпосылок. И тут важно подчеркнуть две вещи:
1) “Сейчас” — это намек на то, что планирование (как и любая активность аналитика) не особо подвержена водопадности. Планируем мы не сугубо на старте проекта или своей деятельности в нем, а регулярно — например, на старте каждой итерации или по мере получения новой важной информации о проекте.
2) “На базе видимых предпосылок”. Что такое риск? Это некое вероятностное событие, которое может навредить (или наоборот — помочь, если придерживаться теории, но на практике мало кто на такие риски смотрит) целевой активности. Т. е. что-то может произойти (я уже сейчас вижу предпосылки для этого), что может негативно повлиять на бизнес-анализ на проекте. Это к тому, что если в ваши риски входят суждения вида “на нас всех упадет метеорит и мы умрем” — рекомендую от подобного избавляться, потому что если метеорит в данный момент не мчится к району Земли, риском считать подобное не стоит. Если вы видите, что в силу специфики проекта, заказчика, начальника, вашей команды, вашей техники, личного гороскопа на месяц и прочих элементов контекста в вашей работе или работе команды БА что-то может пойти не так — это риск бизнес-анализа.
Следующая проблема/ошибка в нашем цикле — это отсутствие работы с рисками в контексте бизнес-анализа на проекте (#19). По-хорошему, тут можно подняться выше и сформулировать проблему как “отсутствие планирования своей работы в целом” (работа с рисками — это всего-лишь небольшая часть планирования бизнес-анализа). Правда, тогда это будут кэпские постулаты в духе “думайте заранее, как будете работать работу, а не действуйте импульсивно, на базе того, с какой ноги сегодня встали”. Я немного затрону планирование в целом, но фокус будет на чаще всего упускаемой его части — работе с рисками. Многие либо не знают, что это можно и стоит делать, либо ленятся таким заниматься, но те, кто с рисками хоть немного работают, получают обычно от этого жирные плюшки.
В книжках и курсах тема про планирование деятельности обычно самая нудная. Мне эта тема тоже долгое время напоминала некоторые курсы университетских времен, когда читаешь какую-нибудь там теорию проектного управления и тонешь в этом гипнотизирующем словоблудии. И BABOK в ту же степь: он настолько преисполнился в своей абстракции, что понять, а что конкретно делать надо, бывает весьма сложно. Давайте попробуем поговорить о планировании БА и рисках в частности, но на нашем деревенском диалекте.
Планирование чего-либо — это подумать о том, как вы будете это что-то делать, заранее. Например, вы собираетесь в отпуск — наверняка вы обдумываете ключевые моменты заранее: куда, когда, чем вы там заниматься будете, сколько бабла с собой взять и как не забыть зарядку от смартфона и активированный уголь. Вот и с работой так же. К сожалению или к счастью, работа аналитика — это не таск, прилетевший в трэкере и триггерящий старт работы. Это мини-проект. Тебе говорят (или ты своей головой понимаешь), что яма должна быть выкопана. Как хочешь копай, но яма должна быть выкопана асап. И надо сесть и подумать, как это осуществить, где найти лопату и как не сломать ее в процессе. Наверное, основное, что нужно понять, чтобы не лишиться разума в процессе изучения темы, это то, что планирование ≠ созданию мудреных артефактов под названием BA Plan, BA Approach и им подобных. Сесть и подумать полчаса о том, каков он — предварительный план действий — и раскидать ближайшие шаги в майндмэпе — это тоже планирование БА как область знаний из BABOK. И этого будет достаточно для многих проектов, если к плану периодически возвращаться по мере прояснения дорожной карты. Причем думать лучше не в пустоту, а взяв чеклист для подобного плана, который предлагают хорошие книжки, курсы или ваш личный опыт.
Соответственно, один из пунктов при планировании БА — это работа с рисками. Это подразумевает подумать множко или немножко про то, что может пойти не так, на базе видимых сейчас предпосылок. И тут важно подчеркнуть две вещи:
1) “Сейчас” — это намек на то, что планирование (как и любая активность аналитика) не особо подвержена водопадности. Планируем мы не сугубо на старте проекта или своей деятельности в нем, а регулярно — например, на старте каждой итерации или по мере получения новой важной информации о проекте.
2) “На базе видимых предпосылок”. Что такое риск? Это некое вероятностное событие, которое может навредить (или наоборот — помочь, если придерживаться теории, но на практике мало кто на такие риски смотрит) целевой активности. Т. е. что-то может произойти (я уже сейчас вижу предпосылки для этого), что может негативно повлиять на бизнес-анализ на проекте. Это к тому, что если в ваши риски входят суждения вида “на нас всех упадет метеорит и мы умрем” — рекомендую от подобного избавляться, потому что если метеорит в данный момент не мчится к району Земли, риском считать подобное не стоит. Если вы видите, что в силу специфики проекта, заказчика, начальника, вашей команды, вашей техники, личного гороскопа на месяц и прочих элементов контекста в вашей работе или работе команды БА что-то может пойти не так — это риск бизнес-анализа.
👍6
Работа с рисками включает в себя две составляющие: идентификация (подумать о том, какие есть риски) и анализ (обмозговать эти риски — насколько они значимы и что с ними делать).
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