Очередной пост-задание из курса СМС. “Убедитесь, что для всех ваших рабочих продуктов у вас есть система ведения версий и известно, кто и когда вносил последнее изменение”
ПОЛУЧИЛ НЕИДЕАЛЬНЫЙ РЕЗУЛЬТАТ
- убедился, что нет: не для всех и не известно
- погрустил, что в одном проекте не выделен рабочий продукт. А в другом проекте крепко задумался про границы рабочего продукта.
- понял, что правил внесения изменений нет ни в одном проекте. Но даже в личном проекте, где ты сам себе режиссер и актер, не стоит ими пренебрегать
- так и не разобрался, конфигурация - это всё-таки желаемое запроектированное устройство системы, которое может быть еще не достигнуто? Или AS IS, каким бы несовершенным не было это состояние по сравнению с замысленной конфигурацией? Или должно иметь желаемое состояние для каждой стадии ЖЦ и сверять, что даже недоделанная система на данной стадии соответствует замыслу?
- ау, курсанты в теме, напишите живой пример, пожалуйста! Такой, в котором будут конфигурации системы, описаний и проекта создания, а также примеры правил по работе с изменения и трудностей, которые при этом происходят
В ЧЕМ СЛОЖНОСТЬ ЗАДАНИЯ
Тяжело делать такие задания. Они проявляют такую бездну несовершенства в действиях, что тянет удавиться. Поэтому требуется недюжиное само-лидерство, чтоб продолжать выполнять эти задания. То есть погружаться в бездну разочарования дальше и не терять при этом оптимизма.
Чуть не в каждом слове задания - подвох:
- “для всех рабочих продуктов” >> cначала бы устаканить рабочие продукты
- вслед за намеченными рабочими продуктами и конфигурацией тянется не только конфигурация описаний, но и конфигурация работ по получению этих РП
- “у вас” >> “вы/мы/я” тут в какой роли: того, кто ведет версии или просто пользуется?
- “есть система ведения версий” >> система же это 4D-процессю. Тогда ищу вниманием набор моделей версионирования, технологии учёта версий и особенно людей, которые производят какие-то операции с рабочими продуктами и делают отметки в системе ведения версий. Обширная штука!
- “известно, кто и когда вносил изменение” >> что такое “известно”: общедоступная при наличии прав на просмотр метка?
Приходиться еще и бороться с внутренним перфекционистом. Следовать “догме черновика” и сделать задание хотя бы “кое-как”, неидеально - чем совсем не сделать его идеально. Ради такой сложной тренировки решил разобрать аж 4 личных ЦС в работе.
КРУГОЗОР ПО СИСТЕМНОМУ МЕНЕДЖМЕНТУ ПРИОБРЕТЕН
По такой системе почти все сложные штуки уже разжёваны в ОдО и МОО. Но задумался - можно ли считать рабочие продукты, произведенные кусками мозга, за конфигурационные единицы мастерства? Вроде бы не вполне, мастерство это система создания для конечных продуктов. Но ведь сами куски мозга с впечатанным в них мастерством пока увидеть не выйдет → приходится работать с прокси-метрикой.
| Проект \\ вопрос чек-листа | Кругозор по СМС приобретён |
|---|---|
| Рабочий продукт, меняющийся в ходе проекта, определён | Куски мозга, которые знают основные объекты практик, упомянутых в курсе, и находят эти объекты в жизни |
| Рабочий продукт имеет номер/маркировку/идентификатор <поименован> | по имени владельца мозга: кругозор Боклашова Юрия |
| Конфигурация рабочего продукта (baseline) определена >> т.е. определены элементы конфигурации | да, её определил автор курса, задал примеры вычислений, которые должны куски мозга делать уметь на выходе |
| Состав описаний для РП явно определён и документирован <задана конфигурация описания> | описание (модель) РП это заполненные поля в aisystant состав моделей, т.о., это сами поля заданий, мета-модель. Т.е. да, определен и документирован |
| Воплощение системы прошло первую стадию ЖЦ <появилась конфигурация системы> | Да, сейчас идет работа по переводу на стадию, аналогичную стадии “демонстрируемо” через выполнение заданий |
| Правила работы с изменениями конфигурации РП установлены | нет, я сам вношу изменения в конфигурацию, например, решаю, что какие-то задания делать не буду. Правил принятия этих решений я сам для себя не пишу, хотя оставляю где-то отметки письмом, почему отстрелил или модифицировал РП по тому или иному заданию >> убрал-модифицировал куски мозга, которые могли бы продемонстрировать исходный рез-т |
| Есть исполняющий практику конфигУчёта | нет |
| Есть конфигурационная база данных >> система ведения версий | есть как минимум 3 базы, где хранятся результаты работ разных кусков мозга: в Кода я пишу посты или описываю результаты выполнения заданий; в aisystant делаю некоторые задания целиком и ставлю отметки по всем заданиям; в блог ШСМ пишу результаты некоторых заданий по логике aisystant самая полная БД, но именно в ней нет свежих данных - я не переношу туда инфо из Кода, блога или своей туду >> потому что не удобно ходить по разделам |
| Состав работ по получению рабочего продукта определен <конфигурация проекта> | Да, я выбрал задания которые планирую сделать, прикинул потребные временные ресурсы, прикинул когда буду их делать |
| Известно, кто и когда вносил изменение в систему | личный проект, поэтому кроме меня пока никто не может вносить изменения |
| 5 дел, которые надо сделать по итогу размышления над столбцом | >> предложить Ильшату сделать в курсе отдельную страничку всех заданий, где можно оптом ставить и видеть отметки >> переделать страничку в Кода со всеми вне-ассистантными тасками курса из простыни строк в таблицу в чек-боксами и ссылками на результаты >> заполнить табличку в Кода |
<ЦС члена совета учредителей>
Недавно я вышел из активного оперативного участия в делах бизнеса. В терминах СМ, повыходил из многих ролей то есть. Тем не менее, роль владельца части бизнеса у меня осталась, как и у других партнеров. Вместе с ролью остался и вопрос - что же мы в этих ролях за рабочий продукт создаем? Задание лишний раз подсветило, что стоит шевелить булками с ответом.
| Проект \\ вопрос чек-листа | <ЦС члена СУ> |
|---|---|
| Рабочий продукт, меняющийся в ходе проекта, определён | нет, и это прямо стоит отдельного рассуждения. Кратко: это РП для альф “Стратегия” и “Собственники”, по 1 хотя бы понятно как думать, просто руки не дошли, по 2 только-только начинает понимание собираться по мотивам поста Анатолия об “цепочках создания” |
| Рабочий продукт имеет номер/маркировку/идентификатор <поименован> | нету будет “Стратегия FTNet <дата>” и соотв. документ |
| Конфигурация рабочего продукта (baseline) определена >> т.е. определены элементы конфигурации | нет |
| Состав описаний для РП явно определён и документирован <задана конфигурация описания> | нет, но понятно, что это можно будет взять из модуля “Стратегирование” |
| Воплощение системы прошло первую стадию ЖЦ <появилась конфигурация системы> | да, жизнь катится, практики реализуем - конфигурационный бардак имеем ) |
| Правила работы с изменениями конфигурации РП установлены | нет. Например, в начале 2022 года мы наметили вариант стратегии, а после 24.02 она претерпела изменения, которые происходили стихийно |
| Есть исполняющий практику конфигУчёта | нет |
| Есть конфигурационная база данных >> система ведения версий | нет |
| Состав работ по получению рабочего продукта определен <конфигурация проекта> | нет, но будет определён при выполнении заданий модуля “Стратегирование” |
| Известно, кто и когда вносил изменение в систему | нет, но это требование должно быть явно учтено при проектировании ответа в п. 6 |
| 5 дел, которые надо сделать по итогу размышления над столбцом |
определить рабочий продукт! предполагаю, что для этого делать задания модуля “Стратегирование”. И завершающие будут: — Стратегия документирована в одном из предложенных в курсе форматов — Проведены 3 обсуждения задокументированной стратегии |
Капитал удовлетворяет потребности домохозяйства
Пришлось провести понятизацию и решить, рассуждаю ли я только про активы, то есть про имущество, участвующее в создании дохода? Или про всё имущество целиком? А потом пришлось удивиться термину “финансовая инженерия”. Ведь он прилип к разработке конкретных финансовых инструментов, а не капитала как системы, выполняющей функции. При этом владелец капитала смотрит на него ровно из такого viewpoint’а. И предпринимателю, подбирающему финансирование, приходится под такой view находить нужные модели, выступать инженером для системы “капитал Иван Иваныча”. Курс об инвестировании времени в ШСМ уже задуман, значит, придет время и для курса об инвестировании вообще.
| Проект \\ вопрос чек-листа | Капитал удовлетворяет потребности домохозяйства |
|---|---|
| Рабочий продукт, меняющийся в ходе проекта, определён | Капитал как совокупность материальных активов или записей о правах на активы на 31.12.2022 |
| Рабочий продукт имеет номер/маркировку/идентификатор <поименован> | задумался, что все части поименованы, а система целиком - разве что по имени владельца “капитал Боклашова Юрия” |
| Конфигурация рабочего продукта (baseline) определена >> т.е. определены элементы конфигурации | да, и это потребовало значительной работы например, в свете последних событий особое значение приобрело размещение/компоновка частей системы |
| Состав описаний для РП явно определён и документирован <задана конфигурация описания> | нет, и это заставило меня крепко задуматься, что над разницей функционального и модульного описания частей системы “капитал” а еще о том, что описаний частей системы много - а какой роли на какой предмет интереса они отвечают, явно я никогда не задумывался |
| Воплощение системы прошло первую стадию ЖЦ <появилась конфигурация системы> | Да, сейчас идет работа по переводу на стадию, аналогичную стадии “демонстрируемо” |
| Правила работы с изменениями конфигурации РП установлены | нет, и несмотря на то, что это личный проект, явное документирование этих правил есть базовая лучшая практика инвестирования |
| Есть исполняющий практику конфигУчёта | нет |
| Есть конфигурационная база данных >> система ведения версий | есть система учёта личных финансов, в которой описано актуальное состояние системы есть сводный документ в Кода, где описан базис, т.е. желаемая конфигурация системы, являющаяся основой для дальнейшей работы >> вероятно именно coda в связи с этим можно считать конфигурационной БД системы, хотя многие части системы связаны с другими БД |
| Состав работ по получению рабочего продукта определен <конфигурация проекта> | Да, после того, как была определена целевая конфигурация, я определил работы, прикинул потребные временные ресурсы, прикинул план выполнения |
| Известно, кто и когда вносил изменение в систему | очень интересно: для некоторых частей системы, которые поддерживаются институтами (банки, брокеры и т.п.) тут всё ОК сделано у некоторых частей это известно по дефолту, т.к. кроме меня никто не может внести эти изменения - но я могу быть безалаберным и забыть, не сделать отметку а для других частей, которые зависят не только от меня, но и не основаны на традиционных институтах, всё не ОК - будут коллизии |
| 5 дел, которые надо сделать по итогу размышления над столбцом | >> составить список проектных ролей для системы “Капитал” с указанием их предметов интереса и намерений >> написать первый драфт правил внесения изменений в систему “Капитал” >> найти метод “Как описать свою инвестиционную стратегию” >> в сводной таблице, описывающей части системы, добавить столбец про способ фиксации последних изменений |
Новый проект "iTMF" системно отмоделирован
Из старых ролей я вышел, и конечно сразу открылись взору предложения новых? Как принять решение об участии в новом проекте? ШСМ предлагает годную модель: разложить проект по 7 альфам. Дальше есть “два путя”:
- если в проекте одна альфа сильно отстает по стадиям от других, это риски-риски. Про них думать в первую очередь, особенно если предлагаемая роль в команде работает с этими альфами
- если даже с альфами все ок, будет ли движ? Максим Боровик на конференции ШСМ рассказал, как поставил так на hold один с виду перспективный проект. После анализа по альфам стал понятно, что будет проект не развития, а совершенствования. То есть там будет результат в пределах 10% —> вряд ли будет движ вокруг проекта. И лучше сделать что-то принципиально по-другому, спроектировать развитие.
| Проект \\ вопрос чек-листа | Новый проект "iTMF" системно отмоделирован по схеме 7 альф |
|---|---|
| Рабочий продукт, меняющийся в ходе проекта, определён | Документ, воплощающий описание по мета-модели проекта по 7 альфам |
| Рабочий продукт имеет номер/маркировку/идентификатор <поименован> | да |
| Конфигурация рабочего продукта (baseline) определена >> т.е. определены элементы конфигурации | еще нет, требуется приземление мета-мета-модели 7 альф на язык предметной области >> создание мета-модели >> но не самостоятельное заполнение до тех пор, пока не приняты роли в проекте |
| Состав описаний для РП явно определён и документирован <задана конфигурация описания> | да, мета-мета-модель, т.е. понятия из СМ-курса уже заданы |
| Воплощение системы прошло первую стадию ЖЦ <появилась конфигурация системы> | да, первый вариант документа, пока без существенного приземления, создан |
| Правила работы с изменениями конфигурации РП установлены | нет, я сам вношу изменения в конфигурацию, например, решаю, какие добавить альфы-подальфы и как их лучше приземлить, а потом и пере-приземлить. Правил принятия этих решений я сам для себя не пишу, хотя оставляю где-то отметки |
| Есть исполняющий практику конфигУчёта | нет |
| Есть конфигурационная база данных >> система ведения версий | да, coda |
| Состав работ по получению рабочего продукта определен <конфигурация проекта> | нет, но понятно как это сделать |
| Известно, кто и когда вносил изменение в систему | личный проект, поэтому кроме меня пока никто не может вносить изменения |
| 5 дел, которые надо сделать по итогу размышления над столбцом | >> заполнить верхнеуровневую схему чек-листами по альфам, которые предстоит адаптировать → задача большая, бьется на 5 дел по альфам понятным образом >> сделать встречу с основателем проекта, чтоб повытаскивать из него язык предметной области |