Так для этого (мы видим по опыту китая) надо вкладывать дохулиардные инвестиции много лет подряд, чего сейчас в текущих условиях не делается (денег выделено на импортзам и передовые железки с гулькин нос). А с учетом дефицита бюджета и подавно не будет.
То есть прямо сейчас надо будет усиленно переориентировать инвестиции в НИОКР, чего не предвидится.
Мы смотрели шире, на качество коммуникации тоже. Support / CSM / Sales могут пороть ерунду, могут преувеличивать проблемы. Там, по-хорошему, надо еще и в то как они свою работу делают погружаться и мониторить. Но это совсем другая история (там моделька - тогда еще ранний gemini - ходила по заметкам общения с клиентами в google meet / gong / salesforce и очень базово репортила если были паттерны общения, которые мы не поощряем). Это было на заре начала chatGPT и всяких суммаризаторов google meet (в end 2022- mid 2023)
Специфика стартапа: жизнь от раунда к раунду инвестиций.
Безусловно вы правы, закон Гудхарта так и говорит. Поэтому самой команде мы никогда такие цели не ставили. Это договор и трекинг на уровне sales, csm, engineering, support. Zero Bugs Policy - это входная точка на практику работы с качеством и ориентированием на клиента: когда начнут отваливаться платящие клиенты, вы сразу поймете что команду больше держать не на что - и дело в качестве. Поэтому поставите (как в тойоте) линию на стоп и будете фиксить дефекты или переделывать системно работу с качеством (shift left, re-architecture, refactoring, еще что-то релевантное вам).
У команды есть явная ответственность за Uptime своего сервиса (который потом обвалится), у руководителя - есть ответственность по архитектуре перед своим CIO. Для остального есть сонар и внешний аудит.
Поэтому там и написано про то что данные потом идут в общую ретроспективу, на которой надо принимать системные решения - и вкорячиваются в Definition of Done.
у меня тут вопрос скорее про то что в продуктовой разработке по мере реализации начинаешь понимать что же пользователю надо. Супер четкого тз с чертежами возможно не будет. Если итерации в идеале небольшими кусочками в вашем случае вшиты в процесс, то ок. Просто ухо резануло немного что мы хотим 100% upfront документацию
Так для этого (мы видим по опыту китая) надо вкладывать дохулиардные инвестиции много лет подряд, чего сейчас в текущих условиях не делается (денег выделено на импортзам и передовые железки с гулькин нос). А с учетом дефицита бюджета и подавно не будет.
То есть прямо сейчас надо будет усиленно переориентировать инвестиции в НИОКР, чего не предвидится.
Мы смотрели шире, на качество коммуникации тоже. Support / CSM / Sales могут пороть ерунду, могут преувеличивать проблемы. Там, по-хорошему, надо еще и в то как они свою работу делают погружаться и мониторить. Но это совсем другая история (там моделька - тогда еще ранний gemini - ходила по заметкам общения с клиентами в google meet / gong / salesforce и очень базово репортила если были паттерны общения, которые мы не поощряем). Это было на заре начала chatGPT и всяких суммаризаторов google meet (в end 2022- mid 2023)
Ну вот я ж писал что мы трекам после выхода на нужную траекторию смотрим не на уменьшение багов, а на баланс и предсказуемость (быть внутри SLA).
Так-то, вы можете любую метрику хакать, это нормально. Если вы хотите какое-то ультимативное решение - то сферических коней в вакууме не бывает :)
Но это же не метрика, а подход. С какой целью вы его применяете - это уже другой вопрос.
Я упоминаю психологическую безопасность не просто так.
Специфика стартапа: жизнь от раунда к раунду инвестиций.
Безусловно вы правы, закон Гудхарта так и говорит. Поэтому самой команде мы никогда такие цели не ставили. Это договор и трекинг на уровне sales, csm, engineering, support. Zero Bugs Policy - это входная точка на практику работы с качеством и ориентированием на клиента: когда начнут отваливаться платящие клиенты, вы сразу поймете что команду больше держать не на что - и дело в качестве. Поэтому поставите (как в тойоте) линию на стоп и будете фиксить дефекты или переделывать системно работу с качеством (shift left, re-architecture, refactoring, еще что-то релевантное вам).
У команды есть явная ответственность за Uptime своего сервиса (который потом обвалится), у руководителя - есть ответственность по архитектуре перед своим CIO. Для остального есть сонар и внешний аудит.
Поэтому там и написано про то что данные потом идут в общую ретроспективу, на которой надо принимать системные решения - и вкорячиваются в Definition of Done.
поправил, надеюсь что теперь чище и лучше видно - что агент делает параллельно несколько этапов, но человек должен завизировать.
Потому что там можно сделать один аппрув сразу на два этапа. И один вытекает из другого.
Если это немного смущает, могу для простоты перерисовать)
Что было бы для вас актуально? Есть ли в целом у вас как у архитектора какие-то мысли по поводу трансформации SDLC, или все таки нету?
у меня тут вопрос скорее про то что в продуктовой разработке по мере реализации начинаешь понимать что же пользователю надо. Супер четкого тз с чертежами возможно не будет. Если итерации в идеале небольшими кусочками в вашем случае вшиты в процесс, то ок. Просто ухо резануло немного что мы хотим 100% upfront документацию
а как качество обеспечивать и отлавливать?
такое ощущение, что это местами тупиковая ветвь)
но базово в статейке все таки здравая мысля - прокачивай observability и будет уже получше
вопрос, как быстро потом придем к авариям как в Амазоне https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f771de?syn-25a6b1a6=1
ну мы как будто по Амазону и еще паре отечественных компаний начинаем видеть масштаб аварий из-за ai генерированного кода.
респект за "ө"
набрел три года спустя на коммент! Это стоило примерно как один senior разработчик на аутсорсе в Индии)
dry в целом можно запихнуть как правило в agents.md, думаю.
Есть уже какие-то заработки и практики, которыми можно было бы поделиться?) круто было б почитать
Блин, у нас часто похоже на воскресный приход)
fixed, спасибо за наблюдение.