Стандарт дает альфы, в процессе работы естественным образом возникнет потребность сделать подальфы, там и возникнут детальные вещи. В стандарте про это явно написано.
В статье описан вариант для индивидуального освоения. Если у вас есть задача определить состояния здоровья проекта и сделать это в группе, то на стр.9 здесь https://drive.google.com/file/d/1ib5uRLbvXY_DrYtEYM8VL7ZvD-Fmg-bm/view?usp=sharing есть рекомендации по количеству людей, которых в этом надо задействовать (от 3 до 10 человек), периодичности проведения (30 минут, каждые 2 недели), продолжительности синка (30 минут). Как выбирать роли людей, кого задействовать в этой практике, там явно не написано, но я рекомендую брать тех, кто обладает инфой по заданной области интересов.
При любой длительности проекта для его реализации нужны люди, которые будут его выполнять. И способ работы должен быть согласован участниками этого веселья.
Плюс, вопрос не в длительности проекта, как таковой, а в том, сколько времени есть у организатора деятельности для разворачивания деятельности по реализации этого проекта (правильнее писать тут, кстати, «реализации ИТ-системы») и того, какие ресурсы для этого есть. Например: команда, знания и умения людей, опыт, инструменты, технологии и практики работы, которые людям уже известны и проч. И дальше надо находить баланс по этим штукам.
На вопрос про то, кто в стартапе может быть заинтересован во внедрении практик работы на основе стандарта, я вам не отвечу :-) Потому что стартап стартапу рознь. Готова обсудить в личке конкретно вашу ситуацию.
Но в целом, это человек с ролью, которая про выбор и внедрение практик жизненного цикла ;-) А уж какую должность этот человек имеет конкретно у вас, я не знаю. Может быть, это технический директор, руководитель проектов, технический лидер или кто-то еще. Здесь важно понимать, что роль и должность не одно и тоже. Тот же тимлид может играть много ролей, как и проджект-менеджер. А уж кому актуализировать какие-то документы и их состояния, тоже решается на местности.
Про мой опыт. Когда я начинала применять стандарт, то была системным аналитиком, занималась инженерией требований, проектированием архитектуры ИТ-систем. И вела эксельку по своей области интересов — инженерной (желтая область на картинках в стандарте). В процессе у меня начала проявляться необходимость расширять область знаний и по другим областям интересов. Всё это я делала в своих рабочих эксельках и не афишировала — я приходила к другим членам команды и спрашивала у них состояния, чтобы принять решение по своей части.
Потребности (определение из BABOK — «проблема или возможность, подлежащая рассмотрению») — это может относиться как к альфе «Возможности», так и к альфе «Описания системы/Требования», быть подальфами этих альф или какой-то из них.
Изменения — это может быть как про «Описания системы/Требования», так и про «Воплощение». BABOK не делает разделения описаний от воплощения в реальном мире.
Решение лучше всего мапится на альфу «Воплощение системы».
Ценность ближе всего к альфе «Возможность».
Заинтересованные стороны (определение из BABOK — «лицо или группа лиц, имеющие отношение к изменению, потребности или решению») — тут это можно мапить на альфу «Стейкхолдеры». Однако, тоже интересный момент, в BABOK не отмечается важность отделения роли человека от его персоналии, судя по определению и дальнейшим выкладкам.
Я перенесла треугольники с модели базовых понятий бизнес-анализа BABOK на диаграмму 7 альф для наглядности, получилось вот так:
Здесь видно, что остались не покрыты такие области инженерного проекта, как «Команда», «Задачи», «Технология работы». А в части маппинга по треугольникам «Контекст», «Потребность» и «Ценность» наблюдаются логические пересечения.
На странице перед текстом стандарта есть фраза: «Этот документ предоставляется сообществу бизнес-аналитиков в образовательных целях» (стр 3 в доке перевода BABOK). Тогда как Essence — инженерный стандарт, который рекомендован для использования в реальной работе.
Для справки: на сайте консалтинговой компании Ивора Якобсона есть про практики, которые можно использовать в работе: https://practicelibrary.ivarjacobson.com/start (надо логиниться, но все бесплатно, там много материалов для практического использования).
Можете поделиться, какие предубеждения в части стандарта у вас возникли?
Я лично продвигаю эту штуку, потому что она оказалась мне полезной в работе. Помогает компактно мыслить об ИТ-системах любого масштаба, а в вариации, которая описана в книге по Системному мышлению А.И. Левенчука, в целом распростаняется на системы любого типа и масштаба (тут ссль на книжку этого года https://ridero.ru/books/sistemnoe_myshlenie/contents/#tocList ).
Способ, предложенный в статье, и алгоритм того, как можно оперативно освоить и применить практики из стандарта, — это микс:
Нужно стараться, чтобы альфы переходили согласованно по этапам жизненного цикла. Представьте, одна альфа находится на этапе концепции, например альфа «Возможность», а «Требования» уже на этапе проектирования. Это означает, что нужно крепко задуматься, почему так происходит. Можно придумать какое-то решение, даже ИТ-систему разработать, а возможность его использования, или внедрения, или продажи проверена не будет. Это та ситуация, когда аналитики сформировали требования, программисты уже что-то написали, а возможность продажи системы еще не подтверждена — например, рынок не найден, нужность этой ИТ-системы не подтверждена.
Хм... не знаю, что такое «посчитать альфы». Может быть, вы имеете в виду проверить состояния альф для конкретного этапа жизненного цикла?
Обратите внимание, что в играх к стандарту (https://drive.google.com/file/d/1ib5uRLbvXY_DrYtEYM8VL7ZvD-Fmg-bm/view?usp=sharing) особый упор дается на то, чтобы проводить сверку по команде в целом, чтобы синхронизировать это понимание и выявлять разночтения. Например, кто-то может считать, что требования уже согласованы, а по факту они еще не выявлены. В этом одна из плюшек практик.
Когда вводим в команду нового человека, нужно рассказать про инструменты и практики, которые использует команда. Если он их не знает, то научить.
По итогам такого обучения сотрудники смогут выполнять свои дела определенным образом — новым, отличным от прошлого опыта.
Мы делали воркшоп по обучению сотрудников работе со стандартом в феврале 2020, потом проводили еще онлайн-форматы обучения для сотрудников других компаний, провели 4 таких итерации. Из нашей компании было 11 сотрудников, которые в командах занимаются постановкой практик работы и работают в разных областях интересов, и еще больше 20 человек из других компаний. В итоге у нас есть сценарий того, как проводить такое обучение в оффлайн- и в онлайн-формате. Наверное, это заслуживет отдельной статьи ;-) Насладиться фоточками можно тут: https://drive.google.com/drive/folders/1ejQ29r3Cg8vIYM0OAyqao_BPRO_ilvgO?usp=sharing
Могу поделиться сценарием проведения этого воркшопа. Надо?
Стандарт дает альфы, в процессе работы естественным образом возникнет потребность сделать подальфы, там и возникнут детальные вещи. В стандарте про это явно написано.
В статье описан вариант для индивидуального освоения. Если у вас есть задача определить состояния здоровья проекта и сделать это в группе, то на стр.9 здесь https://drive.google.com/file/d/1ib5uRLbvXY_DrYtEYM8VL7ZvD-Fmg-bm/view?usp=sharing есть рекомендации по количеству людей, которых в этом надо задействовать (от 3 до 10 человек), периодичности проведения (30 минут, каждые 2 недели), продолжительности синка (30 минут). Как выбирать роли людей, кого задействовать в этой практике, там явно не написано, но я рекомендую брать тех, кто обладает инфой по заданной области интересов.
При любой длительности проекта для его реализации нужны люди, которые будут его выполнять. И способ работы должен быть согласован участниками этого веселья.
Плюс, вопрос не в длительности проекта, как таковой, а в том, сколько времени есть у организатора деятельности для разворачивания деятельности по реализации этого проекта (правильнее писать тут, кстати, «реализации ИТ-системы») и того, какие ресурсы для этого есть. Например: команда, знания и умения людей, опыт, инструменты, технологии и практики работы, которые людям уже известны и проч. И дальше надо находить баланс по этим штукам.
На вопрос про то, кто в стартапе может быть заинтересован во внедрении практик работы на основе стандарта, я вам не отвечу :-) Потому что стартап стартапу рознь. Готова обсудить в личке конкретно вашу ситуацию.
Но в целом, это человек с ролью, которая про выбор и внедрение практик жизненного цикла ;-) А уж какую должность этот человек имеет конкретно у вас, я не знаю. Может быть, это технический директор, руководитель проектов, технический лидер или кто-то еще. Здесь важно понимать, что роль и должность не одно и тоже. Тот же тимлид может играть много ролей, как и проджект-менеджер. А уж кому актуализировать какие-то документы и их состояния, тоже решается на местности.
Про мой опыт. Когда я начинала применять стандарт, то была системным аналитиком, занималась инженерией требований, проектированием архитектуры ИТ-систем. И вела эксельку по своей области интересов — инженерной (желтая область на картинках в стандарте). В процессе у меня начала проявляться необходимость расширять область знаний и по другим областям интересов. Всё это я делала в своих рабочих эксельках и не афишировала — я приходила к другим членам команды и спрашивала у них состояния, чтобы принять решение по своей части.
Сравним предмет рассмотрения у BABOK и OMG Essence.
Кратко. Диаграмма 7 альф и подход Essence шире, чем BABOK, не говоря уже о том, что они про разное.
Теперь подробнее.
Открываем стр. 28, например, в переводе BABOK 3 версии https://drive.google.com/file/d/1zqcakkS-Ygyy-ytAaLpwXxJIN179ICW1/view?usp=sharing):
Потребности (определение из BABOK — «проблема или возможность, подлежащая рассмотрению») — это может относиться как к альфе «Возможности», так и к альфе «Описания системы/Требования», быть подальфами этих альф или какой-то из них.
Изменения — это может быть как про «Описания системы/Требования», так и про «Воплощение». BABOK не делает разделения описаний от воплощения в реальном мире.
Решение лучше всего мапится на альфу «Воплощение системы».
Ценность ближе всего к альфе «Возможность».
Заинтересованные стороны (определение из BABOK — «лицо или группа лиц, имеющие отношение к изменению, потребности или решению») — тут это можно мапить на альфу «Стейкхолдеры». Однако, тоже интересный момент, в BABOK не отмечается важность отделения роли человека от его персоналии, судя по определению и дальнейшим выкладкам.
Я перенесла треугольники с модели базовых понятий бизнес-анализа BABOK на диаграмму 7 альф для наглядности, получилось вот так:
Здесь видно, что остались не покрыты такие области инженерного проекта, как «Команда», «Задачи», «Технология работы». А в части маппинга по треугольникам «Контекст», «Потребность» и «Ценность» наблюдаются логические пересечения.
На странице перед текстом стандарта есть фраза: «Этот документ предоставляется сообществу бизнес-аналитиков в образовательных целях» (стр 3 в доке перевода BABOK). Тогда как Essence — инженерный стандарт, который рекомендован для использования в реальной работе.
Для справки: на сайте консалтинговой компании Ивора Якобсона есть про практики, которые можно использовать в работе: https://practicelibrary.ivarjacobson.com/start (надо логиниться, но все бесплатно, там много материалов для практического использования).
Можете поделиться, какие предубеждения в части стандарта у вас возникли?
Я лично продвигаю эту штуку, потому что она оказалась мне полезной в работе. Помогает компактно мыслить об ИТ-системах любого масштаба, а в вариации, которая описана в книге по Системному мышлению А.И. Левенчука, в целом распростаняется на системы любого типа и масштаба (тут ссль на книжку этого года https://ridero.ru/books/sistemnoe_myshlenie/contents/#tocList ).
Способ, предложенный в статье, и алгоритм того, как можно оперативно освоить и применить практики из стандарта, — это микс:
1) из игры про определение «здоровья проекта» (смотреть тут https://drive.google.com/file/d/1ib5uRLbvXY_DrYtEYM8VL7ZvD-Fmg-bm/view?usp=sharing)
2) и личного опыта, как учить этому людей в группе и осваивать индивидуально.
Нужно стараться, чтобы альфы переходили согласованно по этапам жизненного цикла. Представьте, одна альфа находится на этапе концепции, например альфа «Возможность», а «Требования» уже на этапе проектирования. Это означает, что нужно крепко задуматься, почему так происходит. Можно придумать какое-то решение, даже ИТ-систему разработать, а возможность его использования, или внедрения, или продажи проверена не будет. Это та ситуация, когда аналитики сформировали требования, программисты уже что-то написали, а возможность продажи системы еще не подтверждена — например, рынок не найден, нужность этой ИТ-системы не подтверждена.
Вел :-) Ходила к Анатолию вольным слушателем на курсы, которые он вел на кафедре РосНано, и проходила курсы по системному мышлению.
Хм... не знаю, что такое «посчитать альфы». Может быть, вы имеете в виду проверить состояния альф для конкретного этапа жизненного цикла?
Обратите внимание, что в играх к стандарту (https://drive.google.com/file/d/1ib5uRLbvXY_DrYtEYM8VL7ZvD-Fmg-bm/view?usp=sharing) особый упор дается на то, чтобы проводить сверку по команде в целом, чтобы синхронизировать это понимание и выявлять разночтения. Например, кто-то может считать, что требования уже согласованы, а по факту они еще не выявлены. В этом одна из плюшек практик.
Уважаемый @Apoheliy, я не это имела в виду в статье. Перечитайте, пожалуйста, ещё раз моменты, которые кажутся непонятными.
Я там выше в комменте ответила.
Кстати, у нас обучение заняло 8 часов, в групповом формате с перерывами на отдохнуть.
Когда вводим в команду нового человека, нужно рассказать про инструменты и практики, которые использует команда. Если он их не знает, то научить.
По итогам такого обучения сотрудники смогут выполнять свои дела определенным образом — новым, отличным от прошлого опыта.
Мы делали воркшоп по обучению сотрудников работе со стандартом в феврале 2020, потом проводили еще онлайн-форматы обучения для сотрудников других компаний, провели 4 таких итерации. Из нашей компании было 11 сотрудников, которые в командах занимаются постановкой практик работы и работают в разных областях интересов, и еще больше 20 человек из других компаний. В итоге у нас есть сценарий того, как проводить такое обучение в оффлайн- и в онлайн-формате. Наверное, это заслуживет отдельной статьи ;-) Насладиться фоточками можно тут: https://drive.google.com/drive/folders/1ejQ29r3Cg8vIYM0OAyqao_BPRO_ilvgO?usp=sharing
Могу поделиться сценарием проведения этого воркшопа. Надо?