Записалась на курс Моделирование и собранность с инструктором.
Гадости происходят сами собой, полезные дела требуют планирования и организации
Календарные сроки: 6 января 2024 вводная встреча - 18 мая 2024 защита.
Планируемые затраты времени: 5-10 часов в неделю без учёта еженедельных вебинаров.
5 часов план минимум, это я для себя думаю, как час каждый будний день. По моей раскладке, теория в учебнике проходится за первые день-два. По опыту “Практик саморазвития”, я начинала читать учебник в воскресенье, а в понедельник уже заканчивала. Т.е. получается 4 дня в рабочей неделе отведены под практику: выполнение заданий (в учебнике) и мышление письмом. Пробежка по разделам показала, что в части моделирования бывает до 5 заданий на раздел, а в собранности до 2х. При этом оценить сколько времени будет уходить на моделирование я пока не могу. Но основную сложность я закладываю именно в моделировании. В собранности задания скорее размазаны по неделе, т.е. похожи по структуре на постановку практики с финальным отчётом в конце недели. Что по идее должно вызывать меньше сложностей и оставлять запас времени.
Есть шальная мысль. У меня есть желание как можно раньше внедрить в свою жизнь собранность (докрутить уровень). 4 месяца это долго, а собранность почти всем нам нужна ещё вчера. Разделы по дисциплинам чередуются. Идея моя честно заимствована. Есть такой фокус в составлении программ тренировок в тренажёрке, когда в подход объединяется несколько упражнений. Вместо последовательного выполнения трёх подходов одного упражнения, а потом другого. Я делаю, в одном подходе оба упражнения, потом во втором подходе и т.д. Вот я думаю, что собранность можно брать вместе с моделированием, не дожидаясь следующей недели.
Почему я считаю, что это “может сработать”? Я писала в посте с итогами по “Практикам саморазвития”, что считаю практики пререквизитом к МиС. Всё-таки сам курс МиС не подразумевает, что человек проходил подготовительную программу (СС и ПРС). А значит в части собранности ставятся практики ученика (мышление письмом, инвестирование и учёт времени, работа помидорами, планирование и режим дня). Да смысл не только в этих практиках, а ещё и в том, чтобы хватило сил не подавиться моделированием (ломанием мозгов). И задел на будущее (впереди ещё много курсов из следующих семестров). Но надежда моя в том, что имея за плечами ПРС, какой-то уровень собранности и владения этими практиками у меня есть. А значит мне их можно углублять, а не ставить с нуля. Поэтому я считаю, что идея совмещения может прокатить.
Ресурсы: время, деньги, силы, мотивация.
Деньги уже вложены. Время планируется, конкретные слоты надо подобрать. Мотивация есть. Силы вроде тоже. Все ресурсы планируется отслеживать, как и прогресс.
Зачем мне курс?
Роль: разработчик ПО (backend) в Центре цифровых HR технологий.
Проблема: я считаю, что у нас есть проблемы с этапом проектирования, с переходами моделей/информации между ролями.
Это мой первый проект, где предметная область сложная.
Когда я только пришла, процесс разработки был такой: методолог даёт подробное описание на уровне бизнеса (и в голове у него есть все ответы на вопросы, “как это должно работать”). Дальше бизнес-аналитик разбивает фичу на задачи. Дальше мы как разработчики, описываем что нам нужно сделать технически. Если есть вопросы, идём к сначала к аналитику, потом к методологу. Но чаще (дешевле) сразу к методологу.
Сейчас методолога у нас нет. Есть бизнес-архитектор, который даёт описание (но уже не такое подробное и уже далеко не на все вопросы готов сходу ответить). Дальше опять бизнес-анализ. За ним появился системный анализ. Т.е. часть технической реализации должен системный аналитик перевести с птичьего на понятный. А мы как разработка, как будто должны только закодить по описанию от системного анализа.
Звучит красиво, но не работает. Во-первых, как я и сказала выше, бизнес-архитектор периодически не продумывает граничные условия. У него верхнеуровненое решение, которое должно сработать в большинстве случаев. Дальше видимо нарастить детали и заметить косяки в реализации должны аналитики. В моей голове, я так думаю. Что мы хотели бы на стадии проектирования разобраться с вопросами и описать хорошую модель? Хорошую = работающую. Но бизнес-анализ описание не углубляет, а отдаёт, что есть в системный анализ. Видимо пусть там думают. А системный анализ между молотом и наковальней. Потому что как работает система на самом деле системный аналитик не знает. Почему? А кто делал своими руками и головой реализацию? Правильно, разработчики. Но интересно то, что и, как должна работать система на уровне бизнеса, системный анализ тоже не знает. Потому что это ответственность бизнес-анализа.
Откуда я делаю такие выводы. По нашей прекрасной схеме, мне для работы прилетает “готовая” задача и у неё есть родительская фича, с “полным” бизнес-описанием. Я читаю описание (от системного анализа, задачи это уже их зона описаний) и нахожу там ошибки и опечатки. Ладно, это допустим просто собранности не хватает. Но дальше, я или мой коллега реализует функционал согласно описанию. Идём проверять (на этап тестирования). И оно не работает. Или работает частично. Я иду к аналитикам, ко всем по очереди. Потому что может быть и от системных “пойду уточню, сейчас описание поменяю, там же недолго переделать?” и от бизнес “надо уточнять, я не знаю почему так, если что переделаем”. И так переделывать “срочную” фичу можно 4 раза. Как по мне это так себе цикл обратной связи и так себе проектирование. Страшно сказать вслух “как будто мы без системного анализа жили лучше”. Особенно когда с вопросами можно было на прямую к методологу ходить. И не ждать этих описаний на основании описаний, которые чем ближе к реализации, тем сильнее разваливаются.
Чем мне поможет курс: я надеюсь, что лично у меня в голове станет лучше с проектированием, я смогу задавать правильные вопросы, с ними ходить к нужным людям и видимо не отставать от этих людей, пока не будут найдены работающие ответы на эти вопросы. И перестану ходить по кругу из переделок.
