Успех достигается не разовым усилием, а через постоянное совершенствование процессов и продуктов, с акцентом на быстром реагировании на изменения и тесном сотрудничестве между командами.
Все рассматриваем вместе и разные процессы друг на друга влияют. И их нужно подстраивать/изменять под текущие условия.
Как я понял - проблема с требованиями в том как они “добываются”. Обычно их кто-то приносит: “нам продакт принес требования”, “иди уточни требования”. Что я раньше не замечал - что “конвертация требований” происходит на многих уровнях, и логично что проблемы возникают при копировании/конвертации информации.
Ну и, конечно, фиксированные требования добавляют проблем. Писал немного про это тут СММ-АК-2024. Водопад на производстве. Из-за того, как они добываются - легко получить ошибку, а когда работаешь в парадигме “требования утверждены и изменению не подлежат” все может легко пойти как попало: лишние ресурсы будут потрачены, чтобы выполнить “букву требований”, а пользователям от этого разницы особой не будет.
У меня даже в начале моей трудовой практики такой пример был, когда по требованиям нужно было какую-то фичу сделать(уже не помню какую), но помню что сделать именно так у меня не получалось. И вот я день сижу, два, три, неделю, а все никак. Пошел “сдаваться” к своему начальнику, показал/рассказал, а он такой: ок, не делай это, мы это из скоупа совсем уберем, это далеко не критическая функциональность. [а че так можно было??.png]
Но естественно, просто заменить требования на юз-кейсы нельзя, т.к. тут всю стуктуру переделывать надо:
- гибкие методологии
- инкрементальная разработка
- прямое взаимодействие с пользователями и стейкхолдерами, эволюционное развитие, понимание разработчиками бизнес-домена(и немалые инвестиции в это)
- неразрывность разработки и организации процесса разработки
- и т.д.
В разработке софта применяется подход формирования кросс-функциональной команды. В такой команде есть люди, с разным набором навыков, необходимые для доставки какой-то пользы. Сейчас вспоминаю свой опыт кросс-функциональных команд: почему-то никогда не включали маркетологов, customer-service specialists, да просто каких-то бизнесс-людей. Есть пространство для роста.
В разделе “непрерывное уточнение концепции” отдельно подчеркивается важность наличия “альтернативных концепций”. Указывается что без наличия альтернатив не будет “прохождения развилок”. А почему прохождение развилок важно? Конечно развилки важные не сами по себе, а что в них важно?
Я так понимаю, что важно в них именно то, что их несколько и они субоптимальны. Если их несколько - есть довольно большой шанс, что они как минимум “не очень плохи”. Но если ты сгенерировал один вариант и его же принял - шанс на какашку значительно выше.
Так же если вариантов несколько - это заставляет думать: а что действительно важно, а что не важно, может это приведет мысль куда-то и откроет новую перспективу на рассматриваемую проблему.
Отдельное место тут занимают ADRs. Документирование принятых решений позволяет понимать путь развития. Почему именно так, а не иначе. Не раз замечал в работе: приходит новый человек в проект и не понимает почему “так плохо принимали архитектурные решения”, “там идиоты что-ли проектировали это все?” и начинает стараться переделывать/растаскивать все, чтобы сделать лучше. Но наступает на те же грабли из-за которых данные решения и были сделаны. В итоге: фрустрация, злость, обида(оказывается проектировали не такие уж и дибилы).
- Там случился шибко умный джун. Решил “выдернуть” старый костыль на проде, по древнему тикету
- При близком осмотре костыль оказался позвоночником
Глава “Нейтральное по отношению к конструкции выражение функции: use case”. Оказывается use-caseы можно прекрасно описывать и текстом, я почему-то был застрявшим в визуальном выражении. Нужна небольшая сноровка, но вкатиться довольно просто. И как замечено ранее в учебниках - текстовую версию легче редактировать. Хотя для презентации кому-то(а не для постоянного использования) визуальную схему лучше использовать, лучше “продается”.
Глава “Сценарии использования и «управление делами»”. Хороший алгоритм опредления альф:
- определите ключевые объекты или компоненты системы, которые важны для ее функционирования
- опишите возможные состояния каждой альфы и критерии перехода между ними
- выявите действия или процессы, которые влияют на состояния альф
Нужно думать про выявление ошибок как можно раньше
Это логично, да. Вспоминается табличка со стоимостью исправления ошибки на разных стадиях: проектирование, имплементация, внедрение.
Чтобы сделать хорошо - надо убрать людские операции)
меньше человеков - лучше!
Правда есть интересный момент с over-automatisation. Это не такой гибкий процесс, как людской, но ошибок меньше
“automation is good, so long as you know exactly where to put the machine”