26:04 О Workflow. Доминантные активности.

33:19 Процесс накопления знаний.

О, спасибо

Угадайте кто )

Ыыы

Хорошее качество видео

а бывает другое разве? В онлайне только падает скорей всего, а в записи HD

Про "забыть" поспорил бы с докладчиком. )
а) Хорошие выходные или отпуск стирают знания о завершенной задаче. Гештальт завершен, зачем про него помнить.
б) Увольнение носителя знаний (а иногда и всей команды) оставляет бизнес ни с чем, разве что кодовую базу, с которой нужно разбираться. К сожалению бизнесу пофиг.
в) Отсутствие документации на сложные системы (много интеграций) не дает даже возможности вспомнить, т.к. все знания не помещаются в отдельного человека или команду. Наличие кодовой базы вряд ли поможет.
г) Часть решений может быть реализовано вендором в виде коробочного продукта. Как работает черный ящик не знает никто, а вендор редко делится своими знаниями. У вендора проблемы аналогичные предыдущим пунктам.  

это то, с чем сталкиваюсь каждый день.

А почему ты каждый день сталкиваешься с увольнением людей?

Ба-дум-тссс

Потому что рынок перегрет и рабский труд в РФ запрещен. А так бы конечно отобрал паспорта и сказал грести слаженно )

а другие варианты снижения текучести кроме как рабские ошейники не рассматривал? 🙂

только полная автоматизация всего и вся ) говорят тогда человек будет не нужон

понятно

Спасибо большое за конспект!

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

Если что-то реализовано не так (именования кривые, неудобные формы, недоделаны по функции по мелочи) я просто влезаю в код и его меняю. Не сказать, что на мне не было ответственности, но была достигнута ситуация ее справедливого распределения.

Сейчас пытаюсь адаптировать этот же процесс на более крупном проекте с разным уровнем исполнителей. Ощущение -- получается. Хотя, кто знает. Такие доклады в этом помогают, спасибо)

Проблема, как мне кажется, не в низкой з/п системного аналитика, а в высокой мидла. Только что завершилось обсуждение профстандарта разработчика. Навыки проектирования заложены на очень высоком (6-м уровне, по сути, сениор). И вот, 100%, использование системного аналитика как компенсатора нехватки квалифицированных ИТ-кадров попахивает

+ 100 в карму.
Недавно тоже дали править код в фичах (выполняю роль СА в текущей команде). Команда разделилась на два лагеря. 1й поддержал инициативу, т.к. благотворно сказалось на качестве. 2й (без права вето) не одобрил, т.к. считает, что T-shape только тормозит команду в закрытии фичей и каждый должен выполнять свою роль.

Ну вот общие технические решения - это уже скорее функция техлида. А удобство форм - ux-специалиста. А доработки - программиста.
Вряд ли все это получится сделать хорошо...

Ну а профстандарты - скорее зло (

Вроде как Алексей Жеглов изначально притянул это в Канбан-метод. Вот его статьи в переводе на эту тему:

https://kanbanguide.ru/ponimanie-vashego-proczessa-kak-proczessa-kollektivnogo-nakopleniya-znanij/

https://kanbanguide.ru/ponimanie-vashego-proczessa-kak-proczessa-kollektivnogo-nakopleniya-znanij-chast-1-reczepty/

https://kanbanguide.ru/ponimanie-vashego-proczessa-kak-proczessa-kollektivnogo-nakopleniya-znanij-chast-2-nablyudeniya/

https://kanbanguide.ru/vozvrashhayas-k-proczessu-nakopleniya-znanij

https://kanbanguide.ru/primer-pnz-№1-proczess-izmereniya-izucheniya-v-startape/

https://kanbanguide.ru/primer-pnz-№2-obuchenie-i-kursy/