Pull to refresh

Comments 27

В закладки)

Нет ли рекомендаций, как внедрить данные методики в процесс онбординга новых членов команды?

Не понимаю почему минуса. Тоже интересует этот вопрос, особенно в контексте agile. Вот приходит новый человек в команду/компанию. Его самого сначала нужно научить этому методу, и потом уже возможно, оно за 2 недели разберется в проекте.

Т.к. кастис не расположен отвечать, попробую подискутировать:

По-моему это вообще не про "разобраться в проекте".

По описанию: OMG Essence помогает ... разложить по полочкам ... ключевые показатели проекта. Стандарт ... давал ... такую цельную картину проекта ...

Т.е. это типа глобального KPI по разным областям: например, требования к системе на уровне 55 попугаев. А дальше может быть как в анекдоте: "приборы? 500! - что 500? - а что приборы?".

Естественно, это личное мнение как понял эту статью.

Уважаемый @Apoheliy, я не это имела в виду в статье. Перечитайте, пожалуйста, ещё раз моменты, которые кажутся непонятными.

Я там выше в комменте ответила.

Кстати, у нас обучение заняло 8 часов, в групповом формате с перерывами на отдохнуть.

Когда вводим в команду нового человека, нужно рассказать про инструменты и практики, которые использует команда. Если он их не знает, то научить.

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

Мы делали воркшоп по обучению сотрудников работе со стандартом в феврале 2020, потом проводили еще онлайн-форматы обучения для сотрудников других компаний, провели 4 таких итерации. Из нашей компании было 11 сотрудников, которые в командах занимаются постановкой практик работы и работают в разных областях интересов, и еще больше 20 человек из других компаний. В итоге у нас есть сценарий того, как проводить такое обучение в оффлайн- и в онлайн-формате. Наверное, это заслуживет отдельной статьи ;-) Насладиться фоточками можно тут: https://drive.google.com/drive/folders/1ejQ29r3Cg8vIYM0OAyqao_BPRO_ilvgO?usp=sharing

Могу поделиться сценарием проведения этого воркшопа. Надо?

Правильно ли понимаю, что у каждого, кто решит посчитать альфы на одном и том же проекте получится своя картинка? Или это как-то всё сводится воедино?

Вначале описано преимущество, что можно понять что сделано до уровня багфиксов. Непонятно, как это накладывается на альфы. Делать детализированные чеклисты (вплоть до вех)? Или цель essential получить общее представление "в целом"? Например: сейчас разворачиваем. Как долго - ну это не здесь ...

Хм... не знаю, что такое «посчитать альфы». Может быть, вы имеете в виду проверить состояния альф для конкретного этапа жизненного цикла? 

Обратите внимание, что в играх к стандарту (https://drive.google.com/file/d/1ib5uRLbvXY_DrYtEYM8VL7ZvD-Fmg-bm/view?usp=sharing) особый упор дается на то, чтобы проводить сверку по команде в целом, чтобы синхронизировать это понимание и выявлять разночтения. Например, кто-то может считать, что требования уже согласованы, а по факту они еще не выявлены. В этом одна из плюшек практик.

Хм... не знаю, наверное "проверить" - этого мало. Нужно ... ставите галочки там, где состояние пройдено ... (терминология статьи).

И всё таки: проект на 10 лет. Количество участвующего народа явно не два человека. И не двадцать.

Согласно статье, каждый может определить свою роль (или роли) и "ставить галочки там, где состояние пройдено". Явно это делает не один человек, т.к. он не охватит все роли. Т.е. в результате получим несколько десятков/сотен "Карт Здоровья" (это ваш термин). Опускаем явные случаи, что (например) стейкхолдер может в разделе "Система" не поставить ни одной галочки.

И дальше ... что?

Игра на 3-10 человек это, конечно, отлично. Только собрать всех +100500 людей в одном месте в одно время каждые 2 недели вы (наверное) не сможете.

И .. всё свалить на одного человека (со своим мнением)?

Или каждый со своим мнением и ... лебедь-рак-щука?

Или как-то по-другому?

В статье описан вариант для индивидуального освоения. Если у вас есть задача определить состояния здоровья проекта и сделать это в группе, то на стр.9 здесь https://drive.google.com/file/d/1ib5uRLbvXY_DrYtEYM8VL7ZvD-Fmg-bm/view?usp=sharing есть рекомендации по количеству людей, которых в этом надо задействовать  (от 3 до 10 человек), периодичности проведения (30 минут, каждые 2 недели), продолжительности синка (30 минут). Как выбирать роли людей, кого задействовать в этой практике, там явно не написано, но я рекомендую брать тех, кто обладает инфой по заданной области интересов.

Стандарт дает альфы, в процессе работы естественным образом возникнет потребность сделать подальфы, там и возникнут детальные вещи. В стандарте про это явно написано.

Вел :-) Ходила к Анатолию вольным слушателем на курсы, которые он вел на кафедре РосНано, и проходила курсы по системному мышлению.

Похоже Кастис в выходные не работает :(. Пн-Пт 10-18.

CUSTIS ценит личное время своих сотрудников, поэтому @oleolkeответит вам, когда ей будет удобно.

Это очень забавно, про Essence я узнал, когда пытался разобраться с процедурами стандартизации в OMG (меня интересовал BPMN). И тогда (3 года назад) статья «The making of an OMG standard» меня расстроила и сформировала предубеждение в отношении Essence.

У меня пара вопросов:

  • Почему вы (лично/компания) решили продвигать эту штуковину?

  • Почему вы делаете это так? Перечисленные преимущества уж очень универсальны и требуют подтверждений, названные упрощения (на самом деле обобщения) пугают абстрактностью (отсутствием точности), а «прыжок» во внедрение оставляет с извечным «Зачем»?

Можете поделиться, какие предубеждения в части стандарта у вас возникли? 

  • Я лично продвигаю эту штуку, потому что она оказалась мне полезной в работе. Помогает компактно мыслить об ИТ-системах любого масштаба, а в вариации, которая описана в книге по Системному мышлению А.И. Левенчука, в целом распростаняется на системы любого типа и масштаба (тут ссль на книжку этого года https://ridero.ru/books/sistemnoe_myshlenie/contents/#tocList ). 

  • Способ, предложенный в статье, и алгоритм того, как можно оперативно освоить и применить практики из стандарта, — это микс:

1) из игры про определение «здоровья проекта» (смотреть тут https://drive.google.com/file/d/1ib5uRLbvXY_DrYtEYM8VL7ZvD-Fmg-bm/view?usp=sharing)

2) и личного опыта, как учить этому людей в группе и осваивать индивидуально.

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

Левенчука не предлагать, мы с ним конкретно разошлись характерами.:)

С мотивацией мне понятно, спасибо за ответ.

Если я увидел, что одна альфа дошла до этапа, например, проектирования, а другая альфа - только на концепкции, то мне надо стремиться доводить первую до конца или же вторую до состояния первой? Какие тут рекомендации?

Нужно стараться, чтобы альфы переходили согласованно по этапам жизненного цикла. Представьте, одна альфа находится на этапе концепции, например альфа «Возможность», а «Требования» уже на этапе проектирования. Это означает, что нужно крепко задуматься, почему так происходит. Можно придумать какое-то решение, даже ИТ-систему разработать, а возможность его использования, или внедрения, или продажи проверена не будет. Это та ситуация, когда аналитики сформировали требования, программисты уже что-то написали, а возможность продажи системы еще не подтверждена — например, рынок не найден, нужность этой ИТ-системы не подтверждена.

Если какая-то альфа сильно отстает от другой, это скорее всего будет означать некий проектный риск.

К примеру, если для системы уже выбрана архитектура и даже частично реализована, но мы не знаем кто будут ключевые стейкхолдеры, а тем более они в проект никак не вовлечены, у нас появляется риск, что разрабатываемая система их не удовлетворит.

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

Ну и т.д.

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

Сравним предмет рассмотрения у 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 (надо логиниться, но все бесплатно, там много материалов для практического использования).

Благодаря OMG Essence можно за две недели освоиться с реальным проектом, который рассчитан на десятилетие разработки и внедрения

А если проект рассчитан на 1-3 месяца разработки роллаут, стоит ли заморачиваться? Например в контексте стартапа, где работа идет над внутренними проектами, которые пилятся быстро так как важен time to market.

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

Кто должен этим заниматься (всем тем что описано в статье)? Team Lead? Project manager? Кто несет ответственность за апдейт документов и состоянии?

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

 Плюс, вопрос не в длительности проекта, как таковой, а в том, сколько времени есть у организатора деятельности для разворачивания деятельности по реализации этого проекта (правильнее писать тут, кстати, «реализации ИТ-системы») и того, какие ресурсы для этого есть. Например: команда, знания и умения людей, опыт, инструменты, технологии и практики работы, которые людям уже известны и проч. И дальше надо находить баланс по этим штукам. 

На вопрос про то, кто в стартапе может быть заинтересован во внедрении практик работы на основе стандарта, я вам не отвечу :-) Потому что стартап стартапу рознь. Готова обсудить в личке конкретно вашу ситуацию.

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

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

Для маленького проекта и маленькой команды можно заполнить эксельку и получить индикатор здоровья проекта, сделать это в одиночку за полчаса (в первый раз) или за 5 минут (последующие).

Sign up to leave a comment.