Требования которые мы пишем
Прогностические методики проектирования продуктов и сервисов диктовали и сейчас пытаются диктовать максимально точный и корректный стиль изложения требований. В попытках максимально верно описать слова заказчика в пустую тратят время.
С другой стороны типичность решений и зрелость экспертов в каждой из предметных областей и технологических направлений значительно выросли. А все потому, что достаточно внимания уделяется практикам командного взаимодействия. Даже если сотрудник не научился в гибкость или бережливость, процессы жизненного цикла в команде помогут ему остаться полезным (читай, справиться с задачами).
Существует мнение, что взамен точному и аналитически выверенному стилю изложения требований на замену приходят фасилитационно-ориентированный, направленный на помощь формулированию потребности, методы описания требований. Вернее то, о чем чем написал сложно, все же имело место быть, но не было на столько актуально, как сейчас.
Как же можно позволить требованиям работать за вас? Можно продемонстрировать при помощи аналога крупно узловой сборки автомобилей. Достаточно описать для фронтэнд специалиста образ результата или его наиболее важные критерии, он предложит максимально эффективные методы взаимодействия пользователя с продуктом или сервисом. Детали реализации, ровно как и мелкие детали крупного узла для авто, будут сопровождать решение. Быть как бы в комплекте решения.
Такой подход помогает на первых этапах или первых неделях проекта:
• Собрать информацию для уточнения,
• Представить прототип для более ясного сбора потребности,
• Утвердить или отбросить кардинальные гипотезы,
• Точнее расставить приоритеты,
• Точнее посчитать ресурсы,
• Получить запас времени на отбор и наем необходимого персонала,
• Получить время для более конкурентного торга с поставщиками и провайдерами,
• В принципе получить преимущества в планировании и тд.
Поэтому в реалиях #BANI мира вряд ли следует волноваться о точности написанного текста в артефактах. Не «шляпа или панама» важны на выходе, а польза, и польза своевременности в том числе. Как можем наблюдать, часть времени литературных дебатов полезнее тратить на обработку огромного количества информации, получаемой в качестве обратной связи от заинтересованных сторон.
Гораздо важнее, собирая требования, отвечать на вопрос «Зачем». В будущем мне следует взяться за «йэтэнадэр» рассуждениями о развитии потребности заказчика. Или не развитием, а прояснением. Или помощью формулировки, или поддержки. В любом случае это тоже емкая тема. Хотя бы потому что на вопрос «Зачем» могут вам и не ответить, даже с подписанными #NDA.
Источник: https://levgrishin.ru/требования-которые-мы-пишем/
Прогностические методики проектирования продуктов и сервисов диктовали и сейчас пытаются диктовать максимально точный и корректный стиль изложения требований. В попытках максимально верно описать слова заказчика в пустую тратят время.
С другой стороны типичность решений и зрелость экспертов в каждой из предметных областей и технологических направлений значительно выросли. А все потому, что достаточно внимания уделяется практикам командного взаимодействия. Даже если сотрудник не научился в гибкость или бережливость, процессы жизненного цикла в команде помогут ему остаться полезным (читай, справиться с задачами).
Существует мнение, что взамен точному и аналитически выверенному стилю изложения требований на замену приходят фасилитационно-ориентированный, направленный на помощь формулированию потребности, методы описания требований. Вернее то, о чем чем написал сложно, все же имело место быть, но не было на столько актуально, как сейчас.
Как же можно позволить требованиям работать за вас? Можно продемонстрировать при помощи аналога крупно узловой сборки автомобилей. Достаточно описать для фронтэнд специалиста образ результата или его наиболее важные критерии, он предложит максимально эффективные методы взаимодействия пользователя с продуктом или сервисом. Детали реализации, ровно как и мелкие детали крупного узла для авто, будут сопровождать решение. Быть как бы в комплекте решения.
Такой подход помогает на первых этапах или первых неделях проекта:
• Собрать информацию для уточнения,
• Представить прототип для более ясного сбора потребности,
• Утвердить или отбросить кардинальные гипотезы,
• Точнее расставить приоритеты,
• Точнее посчитать ресурсы,
• Получить запас времени на отбор и наем необходимого персонала,
• Получить время для более конкурентного торга с поставщиками и провайдерами,
• В принципе получить преимущества в планировании и тд.
Поэтому в реалиях #BANI мира вряд ли следует волноваться о точности написанного текста в артефактах. Не «шляпа или панама» важны на выходе, а польза, и польза своевременности в том числе. Как можем наблюдать, часть времени литературных дебатов полезнее тратить на обработку огромного количества информации, получаемой в качестве обратной связи от заинтересованных сторон.
Гораздо важнее, собирая требования, отвечать на вопрос «Зачем». В будущем мне следует взяться за «йэтэнадэр» рассуждениями о развитии потребности заказчика. Или не развитием, а прояснением. Или помощью формулировки, или поддержки. В любом случае это тоже емкая тема. Хотя бы потому что на вопрос «Зачем» могут вам и не ответить, даже с подписанными #NDA.
Источник: https://levgrishin.ru/требования-которые-мы-пишем/
Лев Гришин
Требования которые мы пишем
Прогностические методики проектирования продуктов и сервисов диктовали и сейчас пытаются диктовать максимально точный и корректный стиль изложения требований. В попытках максимально верно описать с…
👍2
Месяц назад приступил к изучению (и переводу на русский язык) свода знаний практика цифровых технологий.
Откровенно говоря, до этого документа мне пришлось немного дорасти головой вот в какой мере. Ведь по сути ИТ как функцию и профессию аналитика в ИТ стало больше объединять, а растущая потребность во взаимных навыках у тишэйпов и … скажем так, гуманитариев, заставила шире смотреть на профессию.
После завершения авторского курса по введению в TOGAF мне удалось 1 - более гибко и разнесторонее управлять абстракциями, 2 - в принципе внимательнее присмотреться к тому огромному озеру накопленной экспертизы организации Open Group.
Итак, о чем же этот #DPBoK. Авторы документа замахнулись на формат обучения практиков в ИТ и подошли к этому классическим приемом, когда каждый из аспектов в «цифре» появляется в контексте своей необходимости.
Понятнее будет так, индивидуальному разработчику, который пишет элементарный кроссплатформенный калькулятор не зачем забивать голову и заниматься #GRC или Разработкой культуры своего предприятия. Хотя бы потому что он предоставлен сам себе.
Следуя такой парадигме, авторы #DPBoK предлагают опираться на модель четырех последовательных контекстов:
1. Основатель,
2. Команда,
3. Команда команд,
4. Предприятие.
В каждом из Контектов авторы излагают области компетенции и категории компетенций с примерами для каждой. Например в контексте Основателя есть область компетенций - Цифровая инфраструктра и она же содержит в себе пять категорий:
1. Принципы Информации и вычисления,
2. Виртуализация,
3. Облачные сервисы,
4. Управление конфигурациями и инраструктурой как кодом,
5. Инфраструктура безопасности.
Как можете догадаться, пройдя такой «курс информатики» можно абсолютно ясно понимать как устроены процессы в ИТ и, что важно, быть готовым зайти в любой из обеспечительных процессов для каждого из них. И это только двенадцатая часть свода знаний.
Откровенно говоря, до этого документа мне пришлось немного дорасти головой вот в какой мере. Ведь по сути ИТ как функцию и профессию аналитика в ИТ стало больше объединять, а растущая потребность во взаимных навыках у тишэйпов и … скажем так, гуманитариев, заставила шире смотреть на профессию.
После завершения авторского курса по введению в TOGAF мне удалось 1 - более гибко и разнесторонее управлять абстракциями, 2 - в принципе внимательнее присмотреться к тому огромному озеру накопленной экспертизы организации Open Group.
Итак, о чем же этот #DPBoK. Авторы документа замахнулись на формат обучения практиков в ИТ и подошли к этому классическим приемом, когда каждый из аспектов в «цифре» появляется в контексте своей необходимости.
Понятнее будет так, индивидуальному разработчику, который пишет элементарный кроссплатформенный калькулятор не зачем забивать голову и заниматься #GRC или Разработкой культуры своего предприятия. Хотя бы потому что он предоставлен сам себе.
Следуя такой парадигме, авторы #DPBoK предлагают опираться на модель четырех последовательных контекстов:
1. Основатель,
2. Команда,
3. Команда команд,
4. Предприятие.
В каждом из Контектов авторы излагают области компетенции и категории компетенций с примерами для каждой. Например в контексте Основателя есть область компетенций - Цифровая инфраструктра и она же содержит в себе пять категорий:
1. Принципы Информации и вычисления,
2. Виртуализация,
3. Облачные сервисы,
4. Управление конфигурациями и инраструктурой как кодом,
5. Инфраструктура безопасности.
Как можете догадаться, пройдя такой «курс информатики» можно абсолютно ясно понимать как устроены процессы в ИТ и, что важно, быть готовым зайти в любой из обеспечительных процессов для каждого из них. И это только двенадцатая часть свода знаний.
👍1
Дашборд без единой кнопки
В моей практике был момент, когда появилась необходимость снизить неопределенность на столько быстро, на сколько это можно было сделать в рамках приличий. Речь пойдет о проектировании консоли или, как еще говорят, дашборде.
Мы можем долго полемизировать о важности доверять профессионалам проектирования специализированных инструментов. Только есть факты и есть опыт, которые показывают следующее:
• Подготовленное задание от заказчика - плод его рассуждений. И этот плод необходимо помочь вырастить. Когда вам придет на ум предлагать свое решение прямо, вместо подведения заказчика к нему, значит не получилось.
• Хороший дизайн — простой дизайн. Поэтому если не получилось просто, значит не получилось.
• Суть дашборда, экономить время: 1 - на вычислении, 2 - на восприятии. Поэтому если результат не помогает принимать решение, хотя бы в 30 раз быстрее, значит снова не получилось.
Существуют вполне себе определенные методы сбора требований, которые помогают приходить к полезным решениям. Тот случай, в котором мне предстояло снижать неопределенность был рядовым. Заинтересованная сторона не могла сформулировать точный набор данных для будущих отчетов, поэтому требовала избыточные данные. Поверьте «все что есть и даже больше» звучало на столько туманно и так останавливало проект, как с большим успехом это заставляет делать вполне себе реальный осенний туман на автомагистрали.
В том примере мы предложили отталкиваться от спектра решений, которые потенциально будут приниматься пользователями отчета, опираясь на обозначенные данные. Суть принятия решения, обычно, увидеть данные в удобном масштабе, сравнить их с референсными значениями и выбрать из модели поведения, необходимый итог. Еще раз, что необходимо:
• Нормализовать и/или конверитировать данные,
• Сравнить их с заранее подготовленными данными,
• Подобрать решение (в заранее определенной модели), соответствующее этому случаю.
Теперь предлагаю поразмышлять. Что для этих трех скромных пунктов потребуется от аналитика? Вообще говоря, корень всего та самая модель принятия решений. А в модели есть входные параметры в своих единицах измерений и выходные параметры. Все вроде, и все же не совсем.
Ведь если говорить о восприятии, то важно помнить, что разные данные должны говорить за себя по разному. Помните красные поля между рисками на шкале приборов со стрелками. Или, возможно, помните как начинает мигать индикатор заряда, начиная с десяти процентов. А еще точно помните, как в некоторых консолях наиболее важные и основные показатели делают большими, толстыми и яркими цифрами. Все это для адаптивно ускоренного восприятия.
И скромно про композицию. Да, про композицию, а не дизайн! Композиция полезного дашборда должна быть простой. Убирайте очевидное и добавляйте необходимое© (Джон Маэда).
В итоге разработка любой, но полезной и функциональной консоли пролегает в умении подвести заинтересованную сторону к своему решению, собрав по дороге модель, нефункциональные требования и выбрав макет с простой композицией. Сложнее таблицы умножения придумывать не нужно. Что нужно? Хорошо владеть знаниями инструментов реализации. Это помогает подкинуть идею или предостеречь от лишних трат на владение результатом и на время подготовки.
Источник: http://levgrishin.ru/dashboard-button-free/
В моей практике был момент, когда появилась необходимость снизить неопределенность на столько быстро, на сколько это можно было сделать в рамках приличий. Речь пойдет о проектировании консоли или, как еще говорят, дашборде.
Мы можем долго полемизировать о важности доверять профессионалам проектирования специализированных инструментов. Только есть факты и есть опыт, которые показывают следующее:
• Подготовленное задание от заказчика - плод его рассуждений. И этот плод необходимо помочь вырастить. Когда вам придет на ум предлагать свое решение прямо, вместо подведения заказчика к нему, значит не получилось.
• Хороший дизайн — простой дизайн. Поэтому если не получилось просто, значит не получилось.
• Суть дашборда, экономить время: 1 - на вычислении, 2 - на восприятии. Поэтому если результат не помогает принимать решение, хотя бы в 30 раз быстрее, значит снова не получилось.
Существуют вполне себе определенные методы сбора требований, которые помогают приходить к полезным решениям. Тот случай, в котором мне предстояло снижать неопределенность был рядовым. Заинтересованная сторона не могла сформулировать точный набор данных для будущих отчетов, поэтому требовала избыточные данные. Поверьте «все что есть и даже больше» звучало на столько туманно и так останавливало проект, как с большим успехом это заставляет делать вполне себе реальный осенний туман на автомагистрали.
В том примере мы предложили отталкиваться от спектра решений, которые потенциально будут приниматься пользователями отчета, опираясь на обозначенные данные. Суть принятия решения, обычно, увидеть данные в удобном масштабе, сравнить их с референсными значениями и выбрать из модели поведения, необходимый итог. Еще раз, что необходимо:
• Нормализовать и/или конверитировать данные,
• Сравнить их с заранее подготовленными данными,
• Подобрать решение (в заранее определенной модели), соответствующее этому случаю.
Теперь предлагаю поразмышлять. Что для этих трех скромных пунктов потребуется от аналитика? Вообще говоря, корень всего та самая модель принятия решений. А в модели есть входные параметры в своих единицах измерений и выходные параметры. Все вроде, и все же не совсем.
Ведь если говорить о восприятии, то важно помнить, что разные данные должны говорить за себя по разному. Помните красные поля между рисками на шкале приборов со стрелками. Или, возможно, помните как начинает мигать индикатор заряда, начиная с десяти процентов. А еще точно помните, как в некоторых консолях наиболее важные и основные показатели делают большими, толстыми и яркими цифрами. Все это для адаптивно ускоренного восприятия.
И скромно про композицию. Да, про композицию, а не дизайн! Композиция полезного дашборда должна быть простой. Убирайте очевидное и добавляйте необходимое© (Джон Маэда).
В итоге разработка любой, но полезной и функциональной консоли пролегает в умении подвести заинтересованную сторону к своему решению, собрав по дороге модель, нефункциональные требования и выбрав макет с простой композицией. Сложнее таблицы умножения придумывать не нужно. Что нужно? Хорошо владеть знаниями инструментов реализации. Это помогает подкинуть идею или предостеречь от лишних трат на владение результатом и на время подготовки.
Источник: http://levgrishin.ru/dashboard-button-free/
👍2
План как поддержка экспресс оценки (PaaSEE)
Угнетающие изменения дарят способность раскатывать план действий, как раскатывает рулон обоев ловкий мастер ремонта. Метафора уровня 100500 уровня… скажете вы и будете правы. Сегодня вспомню как сходил на мастеркласс по мудборду и совсем немного затрону тему планирования.
Можете проверить и убедитесь, что дизайнеры интерьеров применяют один из полезных методов, чтобы «выйти на решение». Мудборд (Moodboard англ.) — это своеобразный холст, набрасывая на который предметы будущего интерьера, заказчик фактически создает за дизайнера образ будущего пространства. Конечно, в этом процессе принимает участие и дизайнер. Очень важно, чтобы его экспертиза помогала предвидеть будущие конфликты исключающие одно или другое желание клиента.
Так, зная начальную высоту потолков, размер и расположение окон, площадь помещений и толщину стен, дизайнер подскажет, как проявит себя освещение вкупе с выбранным материалом и цветом обоев. Кроме этого, именно дизайнер расскажет сколько и где потребуется выходов для розеток, люстр и выключателей. В какой последовательности пойдут работы и потребуется ли брать кредит, если окажется, что на втором месяце ремонта придется заказывать почти две трети от всего объема материалов. А если материалы поступают из зарубежа, и заказ необходимо произвести в валюте, то когда выгодно произвести обменную операцию.
Фактически дизайнер подменяет модели на экране, мелкими, но живыми точечными деталями. Он предлагает разговаривать на языке критерия достижения результата, а не на языке расплывчатых потребностей. И уже сам набрасывает паттерны решений, отдавая макет, расчет и… план!
Итак, как обещал, немного о планировании. Вам, условно, дали задачу и потребовали оценить, как скоро вы ее выполните. Вам неуютно, потому что неясная задача, требует привлечь коллег, которые могут быть заняты (не редко вашим же заказчиком). Как быть?
Не следует брать лишних обязанностей, вы уже отвечаете за задачу и первый шаг огласить оценку. Важно договориться, но о чем? Во-первых, важно придти к образу результата. Кто-то потребует от вас описания решения в принципе, кто-то будет просить точности описания каждой запятой в форматах интеграции. Во-вторых, договоритесь о контроле. Контроль подразумевает частоту проверки траектории движения к результату и описания правил принятия решений, если траектория разойдется с планом.
На этом можно пока остановиться. Сами для себя принимаете три категории задачи: малая, большая и не малая и не большая, а средняя. Для каждой из задач определяете длительность спринта. Его предлагаю определить из расчета занятости руководителя проекта или другого контролирующего лица. Допустим спринт в 2 недели (10 рабочих дней) с трех дневным статусом и одним ревью.
Затем решайте сами. Сколько спринтов у вас в каком по мере сложности проекте. Но что самое важное для успешных договоренностей, это список рисков. Рекомендую присесть на 10 минут и порассуждать, какие из факторов часто мешают двигаться задаче вперед. Это может быть сезонный трафик, зимние заболевания, сезон отпусков, ротация коллектива или статус внешнего партнера. У каждого свои «болячки». Обсудите рисковые сценарии с коллегой и учтите их в плане. А те, которые не нашли свое место в графике, должны получить себе пару — решение в случае возникновения.
Как показывает практика, даже весьма сложный проект можно за 25 минут расписать в деталях, которые удивят и не раз своей стабильностью проявления по пути к цели. Хороший план служит и проверкой для озвученной оценки или ее балансу в большую или меньшую из сторон. И самое чудесное, что хороший план еще не раз послужит отмене проекта. Такое тоже бывает.
Источник: http://levgrishin.ru/план-как-поддержка-экспресс-оценки-paasee/
Угнетающие изменения дарят способность раскатывать план действий, как раскатывает рулон обоев ловкий мастер ремонта. Метафора уровня 100500 уровня… скажете вы и будете правы. Сегодня вспомню как сходил на мастеркласс по мудборду и совсем немного затрону тему планирования.
Можете проверить и убедитесь, что дизайнеры интерьеров применяют один из полезных методов, чтобы «выйти на решение». Мудборд (Moodboard англ.) — это своеобразный холст, набрасывая на который предметы будущего интерьера, заказчик фактически создает за дизайнера образ будущего пространства. Конечно, в этом процессе принимает участие и дизайнер. Очень важно, чтобы его экспертиза помогала предвидеть будущие конфликты исключающие одно или другое желание клиента.
Так, зная начальную высоту потолков, размер и расположение окон, площадь помещений и толщину стен, дизайнер подскажет, как проявит себя освещение вкупе с выбранным материалом и цветом обоев. Кроме этого, именно дизайнер расскажет сколько и где потребуется выходов для розеток, люстр и выключателей. В какой последовательности пойдут работы и потребуется ли брать кредит, если окажется, что на втором месяце ремонта придется заказывать почти две трети от всего объема материалов. А если материалы поступают из зарубежа, и заказ необходимо произвести в валюте, то когда выгодно произвести обменную операцию.
Фактически дизайнер подменяет модели на экране, мелкими, но живыми точечными деталями. Он предлагает разговаривать на языке критерия достижения результата, а не на языке расплывчатых потребностей. И уже сам набрасывает паттерны решений, отдавая макет, расчет и… план!
Итак, как обещал, немного о планировании. Вам, условно, дали задачу и потребовали оценить, как скоро вы ее выполните. Вам неуютно, потому что неясная задача, требует привлечь коллег, которые могут быть заняты (не редко вашим же заказчиком). Как быть?
Не следует брать лишних обязанностей, вы уже отвечаете за задачу и первый шаг огласить оценку. Важно договориться, но о чем? Во-первых, важно придти к образу результата. Кто-то потребует от вас описания решения в принципе, кто-то будет просить точности описания каждой запятой в форматах интеграции. Во-вторых, договоритесь о контроле. Контроль подразумевает частоту проверки траектории движения к результату и описания правил принятия решений, если траектория разойдется с планом.
На этом можно пока остановиться. Сами для себя принимаете три категории задачи: малая, большая и не малая и не большая, а средняя. Для каждой из задач определяете длительность спринта. Его предлагаю определить из расчета занятости руководителя проекта или другого контролирующего лица. Допустим спринт в 2 недели (10 рабочих дней) с трех дневным статусом и одним ревью.
Затем решайте сами. Сколько спринтов у вас в каком по мере сложности проекте. Но что самое важное для успешных договоренностей, это список рисков. Рекомендую присесть на 10 минут и порассуждать, какие из факторов часто мешают двигаться задаче вперед. Это может быть сезонный трафик, зимние заболевания, сезон отпусков, ротация коллектива или статус внешнего партнера. У каждого свои «болячки». Обсудите рисковые сценарии с коллегой и учтите их в плане. А те, которые не нашли свое место в графике, должны получить себе пару — решение в случае возникновения.
Как показывает практика, даже весьма сложный проект можно за 25 минут расписать в деталях, которые удивят и не раз своей стабильностью проявления по пути к цели. Хороший план служит и проверкой для озвученной оценки или ее балансу в большую или меньшую из сторон. И самое чудесное, что хороший план еще не раз послужит отмене проекта. Такое тоже бывает.
Источник: http://levgrishin.ru/план-как-поддержка-экспресс-оценки-paasee/
Лев Гришин
План как поддержка экспресс оценки (PaaSEE)
Угнетающие изменения дарят способность раскатывать план действий, как раскатывает рулон обоев ловкий мастер ремонта. Метафора уровня 100500 уровня… скажете вы и будете правы. Сегодня вспомню как сх…
👍1
Короткая, но полезная статья для тех, кто хочет начинать развивать Отраслевые навыки (см. гл. 9.3.1 BABoK). Речь идет о PESTLE (PEST) анализе. Или другими словами, это чем-то похоже на ту часть модели ITIL4, где формирующие ценность продукта/услуги четыре измерения окружены средой факторов влияния. Вот эти силы или факторы практическии повторяются в акрониме PESTLE.
https://cleverics.ru/digital/2022/10/chto-takoe-pestle-analiz-vazhnyj-instrument-biznes-analiza/
https://cleverics.ru/digital/2022/10/chto-takoe-pestle-analiz-vazhnyj-instrument-biznes-analiza/
Digital Enterprise
Что такое PESTLE-анализ? Важный инструмент бизнес-анализа – Digital Enterprise
Что такое анализ PESTLE? PESTLE-анализ, который иногда называют PEST-анализом, является концепцией в принципах маркетинга. Более того, эта концепция
👍1
Так и было задумано
Ведь бывало такое у многих, сквозь текст узнавали риск или кардинальную ошибку в допущениях/модели? Я это явление называю коварными словами. Чтобы было понятнее, о чем это, расскажу о слове бесшовный.
Для меня это слово важное, потому что именно с него мне пришла на ум мысль вести справочник маркеров. При этом сам подход такого… наверное - аудита, уверен, не раз спасал всех нас. Просто проверить очевидные «факапы», о которых знаете не от хорошей жизни.
Итак слово Бесшовный. Это было ТЗ или Договор, в текстовых джунглях которого висело это слово. Что меня побудило погуглить это понятие уже не вспомню, но через мгновение я уже открывал мир бесшовных сетевых технологий, стоимость оборудования которых умножало ценник оборудования если не 15-20 раз, то уж точно в 3-5 раз.
И надо понимать, что тогда лет 10 назад, если говорить о текстах лучших практик, это был ITILv2 (третья версия библиотеки только восходила), который только обозначал процессы и их адекватные конструкции. Еще пройдет минимум лет 6 и методологи обозначат важность партнерства, как целого измерения формирования ценности для услуг. То есть, этим словом можно было по результатам внедрения на сложном объекте со звездочкой полностью оправдать провал.
Медленно работает отбор на складе? Плохая связь. Что в ней плохого, когда речь идет о скорости работы системы? А… позвольте, видите: Бесшовная сеть, смотрим что это… а у вас что? аля - оборудование для квартирного интернета?! И ТАК ПО ВСЕМ АСПЕКТАМ. Заказчик был бы рад возразить, но неудача есть неудача.
Это позже появятся биллинговые подходы, когда вы платите за результат. А сейчас смотрите в договор. И приходилось таки следить за словами в Договорах и требовать формализации терминологии на том же уровне, как это организованно даже в самых простых SLA.
Поэтому есть наблюдение, что раньше шатания в терминах позволяли уйти от ответсвенности. Тем более, что клиентов - не паханное поле, как говорится. Но развитие качества и ценности услуг диктует получать как можно больше полезной, в том числе и критической и не приятной, информации. Сложность и технологичность услуг выросли и продолжают расти. Компании умеющие обосновать сложность услуги и обосновать ее стоимость, сами притягивают вовлеченных клиентов-партнеров, готовых на сотрудничество.
Если вдруг придется выкручиваться из факапа. Будьте уверены, «Так и было задумано». Кроме Бесшовного есть еще несколько слов или выражений, которые заставляют внимательнее в читаться в абзац артефакта. А у вас есть такие «волшебные» слова?
• Задвоение
• Бесшовный
• Выключить/отключить
• Все требования покрываются коробкой
• Особенность комплекта поставки/партии/релиза
• Автоматически
• Соответсвующий
• С точки зрения бизнес-логики
Источник: http://levgrishin.ru/magic-phrases/
Ведь бывало такое у многих, сквозь текст узнавали риск или кардинальную ошибку в допущениях/модели? Я это явление называю коварными словами. Чтобы было понятнее, о чем это, расскажу о слове бесшовный.
Для меня это слово важное, потому что именно с него мне пришла на ум мысль вести справочник маркеров. При этом сам подход такого… наверное - аудита, уверен, не раз спасал всех нас. Просто проверить очевидные «факапы», о которых знаете не от хорошей жизни.
Итак слово Бесшовный. Это было ТЗ или Договор, в текстовых джунглях которого висело это слово. Что меня побудило погуглить это понятие уже не вспомню, но через мгновение я уже открывал мир бесшовных сетевых технологий, стоимость оборудования которых умножало ценник оборудования если не 15-20 раз, то уж точно в 3-5 раз.
И надо понимать, что тогда лет 10 назад, если говорить о текстах лучших практик, это был ITILv2 (третья версия библиотеки только восходила), который только обозначал процессы и их адекватные конструкции. Еще пройдет минимум лет 6 и методологи обозначат важность партнерства, как целого измерения формирования ценности для услуг. То есть, этим словом можно было по результатам внедрения на сложном объекте со звездочкой полностью оправдать провал.
Медленно работает отбор на складе? Плохая связь. Что в ней плохого, когда речь идет о скорости работы системы? А… позвольте, видите: Бесшовная сеть, смотрим что это… а у вас что? аля - оборудование для квартирного интернета?! И ТАК ПО ВСЕМ АСПЕКТАМ. Заказчик был бы рад возразить, но неудача есть неудача.
Это позже появятся биллинговые подходы, когда вы платите за результат. А сейчас смотрите в договор. И приходилось таки следить за словами в Договорах и требовать формализации терминологии на том же уровне, как это организованно даже в самых простых SLA.
Поэтому есть наблюдение, что раньше шатания в терминах позволяли уйти от ответсвенности. Тем более, что клиентов - не паханное поле, как говорится. Но развитие качества и ценности услуг диктует получать как можно больше полезной, в том числе и критической и не приятной, информации. Сложность и технологичность услуг выросли и продолжают расти. Компании умеющие обосновать сложность услуги и обосновать ее стоимость, сами притягивают вовлеченных клиентов-партнеров, готовых на сотрудничество.
Если вдруг придется выкручиваться из факапа. Будьте уверены, «Так и было задумано». Кроме Бесшовного есть еще несколько слов или выражений, которые заставляют внимательнее в читаться в абзац артефакта. А у вас есть такие «волшебные» слова?
• Задвоение
• Бесшовный
• Выключить/отключить
• Все требования покрываются коробкой
• Особенность комплекта поставки/партии/релиза
• Автоматически
• Соответсвующий
• С точки зрения бизнес-логики
Источник: http://levgrishin.ru/magic-phrases/
Лев Гришин
Так и было задумано
Ведь бывало такое у многих, сквозь текст узнавали риск или кардинальную ошибку в допущениях/модели? Я это явление называю коварными словами. Чтобы было понятнее, о чем это, расскажу о слове бесшовн…
О сертификации в БА
Ничего необычного, просто список организаций, которые уполномочены раздавать сертификаты за прохождение испытаний по направлению бизнес-анализа. У каждой из них, есть своя партнерская сеть тренеров и подготовки. У каждой из них свой скоуп (не свод) знаний для подготовки. И, наверное, это еще не полный перечень:
Теперь о главном. Решение о получении сертификации каждый будет принимать сам. Ведь на самом деле это не только проверка знаний как есть, но и подписка в профессии. С другой стороны это же хорошо, что существует кто-либо, кто на международном уровне сможет подтвердить вашу квалификацию. Ну почти. Фактор SWUk и последующая за ним культура отмены тут тоже обозначили границы для граждан РФ и РБ.
Поэтому, есть такой подход, скажем, фольклорный. Решайте сами, «шашечки или ехать». В нашем случае, ни кто не мешает самостоятельно подготовиться по обозначенным программам и проверить свои знания по примерам вопросов. Прикладная польза покажет истинную ценность полученных знаний и статуса сертификата.
Ничего необычного, просто список организаций, которые уполномочены раздавать сертификаты за прохождение испытаний по направлению бизнес-анализа. У каждой из них, есть своя партнерская сеть тренеров и подготовки. У каждой из них свой скоуп (не свод) знаний для подготовки. И, наверное, это еще не полный перечень:
• ISCB • IIBA • IQBBA • PMI • IREBТеперь о главном. Решение о получении сертификации каждый будет принимать сам. Ведь на самом деле это не только проверка знаний как есть, но и подписка в профессии. С другой стороны это же хорошо, что существует кто-либо, кто на международном уровне сможет подтвердить вашу квалификацию. Ну почти. Фактор SWUk и последующая за ним культура отмены тут тоже обозначили границы для граждан РФ и РБ.
Поэтому, есть такой подход, скажем, фольклорный. Решайте сами, «шашечки или ехать». В нашем случае, ни кто не мешает самостоятельно подготовиться по обозначенным программам и проверить свои знания по примерам вопросов. Прикладная польза покажет истинную ценность полученных знаний и статуса сертификата.
А у нас новость: Международный институт по бизнес-анализу выпустил первую редакцию стандарта по бизнес-анализу.
Он доступен бесплатно. Если вдруг, такой способ распространения, который продемонстрировал сейчас не приемлем. Дайте знать. Сниму файл от греха..)
Он доступен бесплатно. Если вдруг, такой способ распространения, который продемонстрировал сейчас не приемлем. Дайте знать. Сниму файл от греха..)
👍3
Первый мой опыт перевода с подготовкой публикации в виде электронной книги. Есть, что сказать. После такой работы к меня остались возникшие попутно идеи и мысли. Например можно подготовить статью или обзор на новый обозначенный тип требований. Затем внимательнее изучил библиотеку IIBA. Как оказалось, тема базовых компетенций не просто не раскрыта, она и обозначена мной была не совсем с эффективной позиции. Скажем, я бы взялся за корректировку своего видения. Начну позже с точки отсчета. Плюс, так как в соответствующей книге IIBA есть сегрегация ролей БА по мере экспертизы, следует это измерение тоже обозначить и обсудить.
Документ, который прикладываю к публикации, удобно читать с телефона. Кто захочет продолжить работу над переводом, пишите, поделюсь промежуточным источником. Прежде всего рад тому, что языковой барьер уже не препятствие. Да, работая долго с техническим английским этот порог (как не для говорящего по англ.) был ниже, и мне было не очевидно, на сколько это стена для многих моих соратников по профессии. Всем хорошего дня!
ПС. Ссылки в канал приветсвуются 😉
Документ, который прикладываю к публикации, удобно читать с телефона. Кто захочет продолжить работу над переводом, пишите, поделюсь промежуточным источником. Прежде всего рад тому, что языковой барьер уже не препятствие. Да, работая долго с техническим английским этот порог (как не для говорящего по англ.) был ниже, и мне было не очевидно, на сколько это стена для многих моих соратников по профессии. Всем хорошего дня!
ПС. Ссылки в канал приветсвуются 😉
👍1
Forwarded from Лев Гришин
Есть хороший способ расширения кругозора — готовиться или тренироваться сдавать экзамены на известные сертификации. Одной из качественных платформ в этом поле компания Pocket prep. В бесплатных подписках достаточно вопросов и пояснений и ссылок на полезные источники. https://apps.apple.com/ru/app/professional-pocket-prep/id1503584541
App Store
Pocket Prep Professional
Hundreds of exam practice questions at your fingertips. We are Pocket Prep, makers of high-quality exam prep built by industry experts and designed to help you pass your exam.
Professional Pocket Prep gives you access to study prep for 17 different professional…
Professional Pocket Prep gives you access to study prep for 17 different professional…
👍2
Forwarded from Лев Гришин
Смешно, досадно и интересно было самому себе признаться, что лет 5 не правильно понимал термин тишейп/Т-шейп. И только во время перевода учебного руководства по эджайл от PMI наткнулся на ноту, рассказывающую, про I и T шейп. Вот, отрывок:
«Некоторые люди имеют глубокую специализацию в одной области и крайне редко вносят свой вклад за ее пределами. Их назыывают «Ай-шейп», поскольку, подобно букве “I”, они обладают глубиной определенного навыка, но не охватом вспомогательных навыков.
И есть «Ти-шейпы» , которые дополняют свой опыт, навык в одной области вспомогательными, но менее развитыми навыками в смежных областях и хорошими навыками сотрудничества.
В качестве примера, человек, который может протестировать некоторые области продукта и разработать различные области продукта — «Ти-шейп».
«Ти-шейпы» имеют определенную, признанную специализацию и основную роль, но обладают дополнительными навыками, универсальностью и расположены к сотрудничеству с другими, когда и где это необходимо. Такое сотрудничество сокращает передачу полномочий и ограничения, связанные с тем, что только один человек может выполнять эту работу. — Agile Study Guide п. 4.3.3»
Мне видимо показалось, что тишейпы, это просто - «технари». По такой аналогии должны быть эф-шейпы/финансисты, эм-шейпы/медики, ю-шейпы/юристы и так далее как в наивном 2020 называли варианты вирусов.
«Некоторые люди имеют глубокую специализацию в одной области и крайне редко вносят свой вклад за ее пределами. Их назыывают «Ай-шейп», поскольку, подобно букве “I”, они обладают глубиной определенного навыка, но не охватом вспомогательных навыков.
И есть «Ти-шейпы» , которые дополняют свой опыт, навык в одной области вспомогательными, но менее развитыми навыками в смежных областях и хорошими навыками сотрудничества.
В качестве примера, человек, который может протестировать некоторые области продукта и разработать различные области продукта — «Ти-шейп».
«Ти-шейпы» имеют определенную, признанную специализацию и основную роль, но обладают дополнительными навыками, универсальностью и расположены к сотрудничеству с другими, когда и где это необходимо. Такое сотрудничество сокращает передачу полномочий и ограничения, связанные с тем, что только один человек может выполнять эту работу. — Agile Study Guide п. 4.3.3»
Мне видимо показалось, что тишейпы, это просто - «технари». По такой аналогии должны быть эф-шейпы/финансисты, эм-шейпы/медики, ю-шейпы/юристы и так далее как в наивном 2020 называли варианты вирусов.
👍1
Приятно наблюдать за знаменитыми людьми, у кого растет аудитория их сообществ и появляются сообщники. Скорее всего потребуется потратить часть своих усилий, чтобы просто регулярно писать сюда заметки об аналитике.
Странное раскаяние, и тем не менее очередной приятный и полезный ресурс подтолкнул меня поделиться. Речь идет о продукте (сайтом его не назвать) https://www.smaply.com/resources/cx-course-online
Это ссылка на вводный курс для получения начальных знаний о клиентском опыте. На него можно потратить полдня (3 часа на изучение и короткий проверочный тест/эксзамен). Контент красивый и качественный. Кроме этого изобилует «вкусняшками» в виде бесплатных шаблонов.
Есть и ложка дегтя или просто нюанс, который некоторым поднимет планку. Курс на английском. Но… английский элементарный и материал дублируется текстом, кторый можно перевести онлайн, если совсем не просто.
Вышел на этот материал изучая книгу «THIS IS SERVICE DESIGN DOING». Кто тянется к знаниям через стильный и вдохновляющий контент - высоко оценит. В этом я уверен.
Странное раскаяние, и тем не менее очередной приятный и полезный ресурс подтолкнул меня поделиться. Речь идет о продукте (сайтом его не назвать) https://www.smaply.com/resources/cx-course-online
Это ссылка на вводный курс для получения начальных знаний о клиентском опыте. На него можно потратить полдня (3 часа на изучение и короткий проверочный тест/эксзамен). Контент красивый и качественный. Кроме этого изобилует «вкусняшками» в виде бесплатных шаблонов.
Есть и ложка дегтя или просто нюанс, который некоторым поднимет планку. Курс на английском. Но… английский элементарный и материал дублируется текстом, кторый можно перевести онлайн, если совсем не просто.
Вышел на этот материал изучая книгу «THIS IS SERVICE DESIGN DOING». Кто тянется к знаниям через стильный и вдохновляющий контент - высоко оценит. В этом я уверен.
Smaply
Free online CX course & certificate | Smaply
Learn the basics of Customer Experience in this free online CX course. ⮕ Sign up and get your certificate!
👍1
И еще немного вашего внимания для скромных, но красивых находок с песплаными шаблогами и на этот раз «холстов». https://designabetterbusiness.com
У меня сейчас в проработке перевода два источника знаний в сфере Digital Design. И один из них попутно изобразил странный Шаблон холста, не тот, который мы привыкли видеть (поразумеваю, бизнес-холст). Поисковик и Пинтерст вывели меня на этот забавный ресурс. Вот так. Пользуйтесь, там множество интересных и забавных шаблонов. Даже если они не принесут пользу, точно вдохновят и наведут на идеи.
У меня сейчас в проработке перевода два источника знаний в сфере Digital Design. И один из них попутно изобразил странный Шаблон холста, не тот, который мы привыкли видеть (поразумеваю, бизнес-холст). Поисковик и Пинтерст вывели меня на этот забавный ресурс. Вот так. Пользуйтесь, там множество интересных и забавных шаблонов. Даже если они не принесут пользу, точно вдохновят и наведут на идеи.
Раз уж меня проравало, расскажу, куда пропал и чем планирую заниматься в аналитике в 2023.
Конечно, планировать и строить прогнозы если не смешно, то забавно. Тем не менее это правильно и полезно. Поэтому впишу ниже часть факультативных дел, которые не отпустят мои глаза от экрана до следующего января:
* Провести убучающий курс по аналитике в ИТ,
* Перевести на русский вводный курс DDP (Digital Design Professional),
* Завершить вычитку переведенного и отформатированного DPBoK,
* Немного вырасти в направлении аудита,
* Подготовить обучающий продукт по «Управлению знаниями» и «Введению в логику».
Пожалуй из основного все. В ушедшем Ноябре меня захватила мысль принять участие в коференции аналитиков, но дальше изучения потребности в темах и создания своих тем для выступления к концу подачи заявок… не продвинулся. Поэтому оставлю на следующий раз, но очень хочу пройти этот опыт в этом году. Вот теперь все. Обещаю не пропадать, тем более у меня на руках много, чем со времен последних регулярных записей могу делиться.
Конечно, планировать и строить прогнозы если не смешно, то забавно. Тем не менее это правильно и полезно. Поэтому впишу ниже часть факультативных дел, которые не отпустят мои глаза от экрана до следующего января:
* Провести убучающий курс по аналитике в ИТ,
* Перевести на русский вводный курс DDP (Digital Design Professional),
* Завершить вычитку переведенного и отформатированного DPBoK,
* Немного вырасти в направлении аудита,
* Подготовить обучающий продукт по «Управлению знаниями» и «Введению в логику».
Пожалуй из основного все. В ушедшем Ноябре меня захватила мысль принять участие в коференции аналитиков, но дальше изучения потребности в темах и создания своих тем для выступления к концу подачи заявок… не продвинулся. Поэтому оставлю на следующий раз, но очень хочу пройти этот опыт в этом году. Вот теперь все. Обещаю не пропадать, тем более у меня на руках много, чем со времен последних регулярных записей могу делиться.
ВЫБОР ЖИЗНЕННОГО ЦИКЛА
В процессе изучения/перевода Практического руководства по гибкому мышлению (Agile Practice Guide см. https://www.pmi.org/pmbok-guide-standards/practice-guides/agile) подошел к очень полезной информации. Речь на стыке 2 и 3 главы там идет о выборе жизненного цикла проекта. Соглашусь с каждым из нас, кто напомнит, что моя функция анализ, а не управление проектом. Хочу возразить на это тем, что аналитику приходится 1 - консультировать заинтересованные стороны (любые), 2 - выбирать наиболее приспособленный тип жизненного цикла.
Попробуем разобраться. Одним из инструментов для задачи «Подход к БА» являются Методологии и Стандарты, которые как раз определяют и адаптируют подходы. Те в свою очередь помогают наиболее хорошо удовлетворить потребности конкретной задачи. Интересно, что именно здесь раскрывается та самая деталь, которая позволила отсечь в отдельную публикацию описание пяти групп процессов (они еще в шестой редакции PMBoK жили в теле свода знаний).
Как пользоваться всем этим добром нам. Предлагаю для самостоятельного изучения две темы:
Ссылки прилагаю. По желанию делитесь своими:
https://blog.bitobe.ru/article/matritsa-steysi/
https://kachestvo.pro/kachestvo-upravleniya/instrumenty-menedzhmenta/model-kenevin-teoriya-zaputannosti-ili-novyy-instrument-resheniya-zadach/
Если в двух словах, то в векторном пространстве увеличения неопределенности требований и увеличения технической неопределенности, образуются радиальные площади. Они помогают оценить то, на сколько сложный проект по шкале: Простое, Сложное, Комплексное, Хаос. С простым понятно, со сложным и Комплексным почти тоже. Что же касается Хаоса, то для того, чтобы проект был надежно осуществим, в нем должна содержаться всего одна из переменных:
Делая вывод прихожу к мысли о том, что в полном хаосе, необходимо уметь договариваться и может быть это о тех самых коммуникационных навыках. Все может быть С учетом наступления BANI мира/реальности, приветствую всех, кто принял в свое сердце Парето. И сегодня развесовка части навыков из всего, что есть к успеху проекта ярче. Пусть это будет не 20 на 80, а 3 на 97. И тогда напрашивается вопрос. Какие такие супер необходимые буквально несколько навыков, которые дадут 97% успех в проектах? Мое мнение - Проактивность, Сотрудничество и Этика. Было бы интересно прочитать/сделать исследование на эту тему.
Ссылка на статью: http://levgrishin.ru/выбор-жизненного-цикла/
В процессе изучения/перевода Практического руководства по гибкому мышлению (Agile Practice Guide см. https://www.pmi.org/pmbok-guide-standards/practice-guides/agile) подошел к очень полезной информации. Речь на стыке 2 и 3 главы там идет о выборе жизненного цикла проекта. Соглашусь с каждым из нас, кто напомнит, что моя функция анализ, а не управление проектом. Хочу возразить на это тем, что аналитику приходится 1 - консультировать заинтересованные стороны (любые), 2 - выбирать наиболее приспособленный тип жизненного цикла.
Попробуем разобраться. Одним из инструментов для задачи «Подход к БА» являются Методологии и Стандарты, которые как раз определяют и адаптируют подходы. Те в свою очередь помогают наиболее хорошо удовлетворить потребности конкретной задачи. Интересно, что именно здесь раскрывается та самая деталь, которая позволила отсечь в отдельную публикацию описание пяти групп процессов (они еще в шестой редакции PMBoK жили в теле свода знаний).
Как пользоваться всем этим добром нам. Предлагаю для самостоятельного изучения две темы:
• Матрица Стейси. • Модель «Кеневин».Ссылки прилагаю. По желанию делитесь своими:
https://blog.bitobe.ru/article/matritsa-steysi/
https://kachestvo.pro/kachestvo-upravleniya/instrumenty-menedzhmenta/model-kenevin-teoriya-zaputannosti-ili-novyy-instrument-resheniya-zadach/
Если в двух словах, то в векторном пространстве увеличения неопределенности требований и увеличения технической неопределенности, образуются радиальные площади. Они помогают оценить то, на сколько сложный проект по шкале: Простое, Сложное, Комплексное, Хаос. С простым понятно, со сложным и Комплексным почти тоже. Что же касается Хаоса, то для того, чтобы проект был надежно осуществим, в нем должна содержаться всего одна из переменных:
• неопределенность (состоящая или из пригодности и требований, или из технической осуществимости и производительности), • или несогласие.Делая вывод прихожу к мысли о том, что в полном хаосе, необходимо уметь договариваться и может быть это о тех самых коммуникационных навыках. Все может быть С учетом наступления BANI мира/реальности, приветствую всех, кто принял в свое сердце Парето. И сегодня развесовка части навыков из всего, что есть к успеху проекта ярче. Пусть это будет не 20 на 80, а 3 на 97. И тогда напрашивается вопрос. Какие такие супер необходимые буквально несколько навыков, которые дадут 97% успех в проектах? Мое мнение - Проактивность, Сотрудничество и Этика. Было бы интересно прочитать/сделать исследование на эту тему.
Ссылка на статью: http://levgrishin.ru/выбор-жизненного-цикла/
👍3
Пока готовил программу вебинаров по аналитике в ИТ, очередной раз столкнулся с обозначенным в стандарте БА в. 1.0 видом требований - Требования к усточивому развитию (англ.: Sustainability Requirements).
Не сталкивался с необходимостью таких требований, поэтому пришлось самостоятельно разобраться. В попытке понять, о чем такие требования, изучил (и перевел) прилагаемую ниже статью. В ней такие требования обозначены на примере поддержания экологии, а вообще требования к устойчивому развитию это больше трасировка к определенному ориентиру организации. И этот ориентир качественно фильтрует спектр возможных решений и конкретизирует решение. За что спасибо!
Не сталкивался с необходимостью таких требований, поэтому пришлось самостоятельно разобраться. В попытке понять, о чем такие требования, изучил (и перевел) прилагаемую ниже статью. В ней такие требования обозначены на примере поддержания экологии, а вообще требования к устойчивому развитию это больше трасировка к определенному ориентиру организации. И этот ориентир качественно фильтрует спектр возможных решений и конкретизирует решение. За что спасибо!
Кстати, подобный момент и тоже на примере окружающей среды можно увидеть и в учебном пособии введения в ITIL4 в той части, когда рассказывают о подходе развития взаимоотношений с партнерами. Там показывают, как компания, предоставляющая автомобили в аренду, чтобы выбрать партнера, который поставит сырье - стаканчики для питьевой воды - останавливаются на критерии бережности окружающей среды. Короче говоря, выбирают компанию с бумажными стаканчиками.
В обычной жизни, то есть работая в проектах ИТ, тоже начинаю находить место для таких видов требований. В них реально есть польза.
В обычной жизни, то есть работая в проектах ИТ, тоже начинаю находить место для таких видов требований. В них реально есть польза.
👍1
Случайно наткнулся на интересное обсуждение. Специалисты обсуждают проблему хранения эскизов корпоративных процессов