#забесплатно

У моих кентов из Эльдорадо друзей из AI IDE BAS вышло новое обновление – теперь они дают бесплатный триальный доступ к LLM, чтобы вы могли попробовать их детище в действии.

При входе через Google каждый получает 500 токенов бесплатно – этого хватит, чтобы сделать около 3 артефактов. А бонусом от меня идет эпический щит впрочем, об этом ниже.

Что нужно, чтобы попробовать?
✅ Скачать VS Code для вашей ОС
✅ Установить расширение AI IDE BAS:
🔸Visual Studio Marketplace
🔸Open VSX
✅ Авторизоваться через Google Sign In
✅ Вернуться в VS Code/Open VSX и подтвердить вход

Вуаля – 500 токенов у вас на счету. Остаток можно проверить в личном кабинете.

Подробная информация о релизе – тут.
Инструкция по настройке – здесь.

Keep on delivering🔥

Ах да! Специально для моих подписчиков ребята готовы дать 50 дополнительных токенов, чтобы точно хватило на заветные артефакты. Пишите в личку канала после всех манипуляций выше и получите 50 бонусов от меня🕸

#analystvalue

Когда убеждения проверяются на прочность…

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

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

Но как быть в ситуации, когда исключения в процессе делаются как раз для того, чтобы бизнес мог зарабатывать много денег? А любое «выпрямление» существующего процесса грозит несколькими днями простоя и, как следствие, снижением выручки компании. Существенным снижением выручки.

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

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

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

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

#analystsread

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

✅ Почему аналитики плохо пишут use cases?

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

✅ Правда или красивая выдумка?

Про канал BA Team я уже как-то рассказывал, но на этой неделе ребята сделали классный пост про мифы и стереотипы о работе бизнес-аналитика. Каждый пункт – в самое сердечко, так сказать.

✅ Заменит ли нас искусственный интеллект?

Вдумчивое размышление на тему использования ИИ в работе аналитика. Тема, безусловно, очень актуальная сейчас, и такие мысли, как изложила Галина – на вес золота.

Enjoy🔥

Наберут по объявлению…

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

Сразу подсвечу два момента. Первое – в этом посте я буду говорить только о тех тестировщиках, которые проверяют функциональность систем. Пентестеры, нагрузочные тестировщики – о них речи не будет. Второе – терминология: я буду использовать просторечные «ручные тестировщики» и «автотестеры».

Итак, как многие знают, долгое время я был fullstack-аналитиком – и в бизнес ходил, и с разработкой общался. И общение с разработкой часто сталкивало меня именно с тестировщиками – как-то так складывалось, что у разработчиков вопросов было меньше (а иногда и не было вовсе), но, когда за дело брались тестировщики, вопросы лились как из ведра.

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

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

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

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

Но, безусловно, не все так однозначно. Я ни в коем случае не утверждаю, что ручные тестировщики – зло, а автотестеры – добро. Мой вывод чуть шире и банальнее одновременно – все дело в профессионализме.

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

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

Stay tuned🔥

#babok101

Планирование управление информацией бизнес-анализа: назначение и элементы

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

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

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

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

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

✅ Возможность повторного использования информации –
повторное использование информации бизнес-анализа позволит в дальнейшем сэкономить время и снизить затраты при проведении новых инициатив. При этом важно понимать, что далеко не каждое требование, дизайн или артефакт могут быть использованы повторно. Так что при оценке возможности долгосрочного использования информации следует обратить внимание на:
🔸нормативные требования
🔸договорные обязательства
🔸бизнес-правила
🔸бизнес-процессы
Конечно, все подвержено изменениям, но, зачастую, такие изменения не происходят за день, а растягиваются во времени, что позволяет своевременно провести актуализацию информации.

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

✅ Атрибуты требований – в двух словах, это информация о самих требованиях, помогающая управлять ими в ходе инициативы. Если более широко... то лучше вынести это в отдельный пост💡 А десять инопланетян под этим сообщением смогут доставить полный разбор атрибутов требований на канал🌟

Что ж, с целями и элементами разобрались, завтра обсудим техники и инструменты!

Stay tuned🔥

#babok101

Планирование управления информацией бизнес-анализа: инструменты и техники

Чтобы грамотно сформировать подход к управлению информацией бизнес-анализа BABOK рекомендует использовать следующие инструменты:
💡 оценка эффективности бизнес-анализа – опыт аналитика и его коллег будет полезен для выявления лучших практик в части хранения и обеспечения доступа к информации, использовавшихся в рамках прошлых инициатив.
💡 бизнес-политики – формальные соглашения, договоренности и процедуры, принятые внутри компании.
💡 инструменты управления информацией – в каждой компании в том или ином виде поддерживаются инструменты хранения и обмена информацией. Это может быть бумажный или электронный документооборот, внутренняя wiki-система (всеми нами любимый Confluence) или вообще облачный сервис. Понимание принятых в компании инструментов облегчит формирование подхода к управлению информацией для аналитика.
💡 юридическая/нормативная информация – в ряде отраслей хранение информации строго регламентировано извне. Знание таких требований может серьезно сказаться на формируемом подходе.

Что касается конкретных техник, то их набор во многом похож на другие задачи, связанные с планированием, о которых я писал ранее.
🔍 Карты ассоциаций – наши любимые mind maps, которые в рамках формирования подхода к управлению информацией бизнес-анализа могут быть использованы для фиксации отдельных идей, важных заметок в части используемых инструментов.
🔍 Моделирование процесса – диаграмма процесса управления информацией позволит всем стейкхолдерам одинаково понимать планируемый подход.
🔍 Отслеживание вопросов – любой процесс так или иначе приводит к появлению вопросов у различных его участников. Такие вопросы должны фиксироваться и управляться аналитиком в рамках формирования подхода.

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

Keep on delivering🔥

Fellow analysts, с праздником🔥

Сегодня отмечается Международный день бизнес-анализа.

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

Мы крутые, и это факт🔥

#babok101

Определение возможностей улучшения эффективности бизнес-анализа: назначение и элементы

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

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

✅ Оценочные показатели эффективности бизнес-анализа – для их использования необходимо для начала определить, какие аспекты работы и каким образом будут оцениваться. Следующий шаг – определение самих показателей как качественных, так и количественных.
Примерами показателей могут служить:
🔸правильность и полнота – весьма субъективный показатель, характеризующий корректность и уместность поставляемых аналитиком артефактов с точки зрения стейкхолдеров
🔸стратегический аспект – помогла ли работа аналитика достичь заявленных бизнес-целей
🔸своевременность – была ли работа выполнена вовремя, в соответствии с планом, или этот план постоянно нарушался
На моем опыте оценочные показатели включали такие характеристики как количество ревью документов со стороны коллег, количество возвратов документов на доработку, а также обратная связь от заказчика.

✅ Анализ полученных результатов – сравнение результатов работы аналитика в рамках конкретной инициативы с установленными показателями.

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

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

Stay tuned🔥

#babok101

Определение возможностей улучшения эффективности бизнес-анализа: инструменты и техники

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

Техник, напротив, предлагается целое разнообразие. Помимо все тех же стандартных интервью, наблюдения и семинаров, я бы хотел выделить следующие:
🔍 Метрики и ключевые показатели эффективности – да-да, наши любимые KPI. Если они применяются в организации, то и для оценки эффективности бизнес-аналитика точно можно найти несколько метрик.
🔍 Моделирование процесса и Анализ процесса – в работе бизнес-аналитика можно (а, вернее, даже нужно) выделить некоторое количество процессов, которые могут быть смоделированы. Эти модели, в свою очередь, должны быть изучены и проанализированы на предмет потенциальных точек улучшения и повышения эффективности.
🔍 Анализ корневых причин – для каждой неудачи или трудности, с которой столкнулся аналитик при выполнении своих задач, следует определить исходные причины, чтобы в дальнейшем сформировать шаги по их исключению.

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

Keep on delivering🔥

Прибыль важнее прозрачности но это не точно

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

Что ж, выбор сделан – победили деньги. Но не все так однозначно.

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

К чему я это все? Эта история в очередной раз подсвечивает два важных и одновременно простых момента.
1️⃣Можно досконально изучить предметную область, можно видеть и понимать все процессы и их изъяны, можно выстроить идеальную картину и горевать, что она недостижима. А можно пригласить к обсуждению коллег, которые свежим взглядом оценят ситуацию и смогут дать полезные рекомендации.
2️⃣Очень и очень сложно из точки А сразу оказаться в прекрасной точке Е. Между ними есть расстояние, которое невозможно преодолеть за один скачок. Но стоит сконцентрироваться на маленьких шагах, и этот путь будет осилен.

Keep on delivering🔥

Fellow analysts🔥

Завтра и послезавтра буду на Analyst Days – пока только слушателем🤷🏼‍♂️

Если кто-то из вас также будет участвовать и тем более выступать – с радостью пообщаюсь и послушаю выступление.

Пишите в комментарии🔥

Как я сходил на Analyst Days

Если коротко, то:
🔸послушал 11 докладов
🔸поучаствовал в 2 мастер-классах
🔸послушал коллегу из Каспера в экспертной зоне
🔸выпил 3 бокала игристого и неограниченное количество кофе

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

😌 Рассказы не только про привычный анализ
Это следствие первого пункта. Помимо базовых вещей о бизнес-/системном анализе некоторые спикеры рассказывали о визуализации (потрясающий доклад Наташи Веселовой) и Process Mining, об использовании ИИ (разумном, а не бездумном) и ментальных ошибках.

😌 Мастер-классы
Отличный способ применить знания на практике на выдуманном, но вполне реалистичном кейсе. Мы с командой делали MVP умного сада и запускали его на Таймыре. Сказать, что это было весело, – ничего не сказать.

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

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

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

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

Stay tuned🔥

Fellow analysts🔥

Сегодня каналу исполнись два года.

Я бесконечно благодарен всем вам, что вы проходите этот путь вместе со мной. Ваша поддержка, ваши реакции, комментарии, репосты – все это действительно помогает двигаться дальше. Спасибо!

И как всегда… keep on delivering🔥

Fellow analysts🔥

Я готов в ближайшее время взять двух-трех человек в качестве менти.

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

Как будет устроена совместная работа:
✅ ознакомительная встреча для выявления потребностей
✅ формирование персонального плана работы
✅ 1 или 2 часовые встречи в неделю (возможно – реже), время – по договоренности

Отзыв о первом опыте совместной работы можно найти здесь.

По условиям и дополнительным вопросам – welcome в личные сообщения канала или напрямую ко мне.

Stay tuned🔥

#analystvalue

Расширение или детализация?

Обычная ситуация: на старте проекта зафиксирован скоуп, но в ходе выявления требований появляются новые детали. Как трактовать эти детали? Самый простой путь – как расширение того самого скоупа.

Но всегда ли это так? Давайте порассуждаем.

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

Во-первых, как понятно из вольного определения, скоуп – это границы, причем границы всего:
🔸области управления – что именно аналитик будет анализировать, роли и обязанности участников проекта
🔸объем потребностей – исследуемые в рамках проекта потребности стейкхолдеров, планируемая к поставке ценность, функциональные области и т.д.
🔸границы решения – поддерживаемые в рамках решения сценарии, влияние изменений на окружение, а также поставляемая ценность решения
🔸объем изменений – действия, которые необходимо предпринять не только в рамках реализуемой инициативы, но и «вокруг» нее: инициировать смежные изменения, обеспечить организационные сдвиги и т.д.

Во-вторых, скоуп – это про контекст. Фиксируя скоуп, аналитик также фиксирует контекст организации, т.е. текущее положение дел. Больше того, аналитик может зафиксировать и целевой контекст – состояние, в котором организация стремится оказаться после реализации инициативы. Зачем это нужно? Понимание текущего и целевого контекста помогает принимать правильные решения в рамках выполнения задачи, а в случае внезапных изменений – адаптироваться к ним.

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

Что ж, зачем нам фиксировать скоуп, мы разобрались. А что насчет расширения или детализации? Читайте в продолжении⬇️

#analystvalue

Расширение или детализация? Продолжение.

Часть первая – здесь.

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

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

Приведу несколько примеров, чтобы раскрыть мысль, причем все они будут основываться на одной формулировке из скоупа, а именно: «Поддержать автоматическую отправку email-нотификаций покупателям при размещении заказа».

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

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

И, наконец, третий кейс: аналитик выявляет, что текст нотификации формируется в соответствии со множеством условий и наполняется динамически в зависимости от содержимого заказа. Механизм при этом кажется весьма громоздким и сложным и потенциально усложняет разработку, но сотрудники заказчика сейчас самостоятельно делают такую рассылку. Является ли так эта ситуация расширением скоупа? Мне кажется, что нет. И вот почему:
1️⃣сам скоуп никак не детализирует содержание нотификации. Это может свидетельствовать как о том, что аналитик был готов к любым вариантам email-нотификаций, так и о том, что он недостаточно погружался в процесс при формировании скоупа. Но не будем о формализме.
2️⃣ценность обычной нотификации (т.е. без динамического наполнения) очевидно ниже ценности полноценного уведомления с условными картинками внутри. Реализация отправки таких нотификаций будет существенным снижением качества процесса в общем, что потенциально негативно скажется на удовлетворенности покупателей.
3️⃣а тут я приглашаю вас поделиться своими мыслями в комментариях💡

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

Stay tuned🔥

Итоги года... но не мои

Так вышло, что в уходящем году я регулярно пересекался и рассказывал о ребятах из AI IDE BAS. И иначе как совместным эфиром такой год закончиться не мог.

29 декабря ждем всех вас на предновогодней Q&A-сессии, где я тоже буду светить лицом отвечать на вопросы и обсуждать итоги года.

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

Подробности – по ссылке✨

А мои персональные итоги года не за горами. Расскажу обо всем в понедельник-вторник.

Stay tuned🔥

Fellow analysts🔥

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

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

Собственно, отсюда вопрос ниже⬇️