Про компенсацию согласен, но тут скорее дофамин от того что инвестиции сработали и чисто психологический крючок. Тезиса про длительность проработки это не снимает, но тут сработало удовольствие от того что теперь не нужно ждать пока появятся ставки инженеров чтобы посадить профильного человека и он сделал все хотелки, а можно просто брать и делать все то чего раньше хотелось но не моглось.
Цепочка простая - сработало раз - должно сработать и еще раз, но для этого надо поднапрячься чуть больше чем в прошлый раз.
Главное чтобы в подворотне не подошел мутный тип в плаще со словами "пс, загрумленный бэклог не нужен? первый спринт бесплатно" =)
Комментарий справедливый, если попытаться подумать почему так произошло, я бы ответил так - за короткий срок был реализован большой пласт работ, как пример - за три недели до прода удалось дотащить полностью работающее решение, оценка по которому была 6 месяцев снизу. Это немного вскружило голову, захотелось повторить подвиг и поддержать уровень производительности, но готовых задач не оказалось.
Ну и да, интерес и развитие, особенно на хайпе, никуда не ушел - каждый день продолжаю подкручивать какие-то вещи и доуточнять метрики.
Насчёт «разбить на подсистемы» — декомпозиция не убирает голову, она переносит её на границы. Каждая граница между подсистемами — это контракт, интерфейс, и на них теряется контекст (а зачем мы это делали и на что мы сожгли два спринта разработки?). Так что «каждой мелкой подсистеме коллектив не нужен» — да, но только пока кто‑то держит знание о том, как части стыкуются и зачем они вообще нужны. Вполне возможно что это даже не инженерная задача.
Насчёт «ИИ не расширяет когнитивные возможности» — согласен, не расширяет. Контекст выносится наружу — спеки, контракты, issue‑файлы или задачи, чтобы в голове осталось только суждение: что строим и как разруливать стыки. Кодогенерация это действительно не узкое место в текущих реалиях, и в таком процессе разработки проблема начинается с управления тем где живёт знание о границах и особенностях эксплуатации.
У вас в проектах где жило это знание — в архитекторе, вики или коде?
Вариантов два - или искать альтернативных провайдеров, или искать более лояльные компании.
Для первого случая из личного опыта могу порекомендовать perplexity api - доступ актуальным моделям (openai, anthropic, google и тд) без танцев с бубном, но тарификация может отличаться от оригинала.
Для второго случая - опыт перехода показал что deepseek v4pro справляется не сильно хуже. Есть специфичные вещи где пока есть сложности (например я так и не смог адекватно подружить его с Unity в домашних проектах), но на условных задачах по перекладыванию json'ов справляется нормально, особенно если накормить его референсами.
Нет, потому что решение из статьи у меня работает на том, что весь организационный контекст сидит в одной голове и он постепенно выносится наружу по мере необходимости. Открытый вопрос: можно ли заменить эту голову внешним источником истины — спецификациями, контрактами, issue-файлами или чем-то еще.
Да, потому что общий подход не меняется от масштаба команды и продукта/проекта, но в это нужно осознанно инвестировать. Если речь идет про огромный легаси который пилился годами - на таком проекте адаптация может занять месяцы, а то и годы. На новых проектах - счет пойдет на дни.
Если убрать всех глупых людей - когда-то этим глупым человеком неизбежно становишься ты.
Глупость - понятие относительное, если человек продолжает работать - значит есть что-то почему он продолжает работать. Возможно он хорош в других задачах о которых мы не знаем.
Дополнительно, альтернативный взгляд может помочь посмотреть на процесс под другим углом и получить вопросы которыми даже не задавались, думая что "тут и так все понятно"
Если все держится только на человеке - если нет быстрой замены, не уступающей по инициативности, пониманию и опыту управления всем этим оркестром - процесс начнет буксовать и уничтожать сам себя принося проблемы там где должен был их исправлять. В таком случае начнется бунт, команды будут сознательно саботировать все до чего смогут дотянуться чтобы можно было быстрее показать несостоятельность отдельных практик или всего процесса разом и его упразднят/пересмотрят/третье
Если он успел выстроить систему (идеально - саморегулируемую, но это звучит утопично) - отсутствие одного человека можно пережить временно распределив его функции на других людей/код/ручные операции
Менять процессы в угоду руководства - это не то чтобы нормально, но у каждого руководителя есть понимание того чего он хочет достичь от результатов работы как своих, так и своих подчиненных/систем. Другое дело что процессы плотно связаны между собой и изменение в одном из них не должно драматически влиять на другие, а это часто задача со звездочкой.
Да, полностью без негатива, все в порядке
Про компенсацию согласен, но тут скорее дофамин от того что инвестиции сработали и чисто психологический крючок. Тезиса про длительность проработки это не снимает, но тут сработало удовольствие от того что теперь не нужно ждать пока появятся ставки инженеров чтобы посадить профильного человека и он сделал все хотелки, а можно просто брать и делать все то чего раньше хотелось но не моглось.
Цепочка простая - сработало раз - должно сработать и еще раз, но для этого надо поднапрячься чуть больше чем в прошлый раз.
Главное чтобы в подворотне не подошел мутный тип в плаще со словами "пс, загрумленный бэклог не нужен? первый спринт бесплатно" =)
Комментарий справедливый, если попытаться подумать почему так произошло, я бы ответил так - за короткий срок был реализован большой пласт работ, как пример - за три недели до прода удалось дотащить полностью работающее решение, оценка по которому была 6 месяцев снизу. Это немного вскружило голову, захотелось повторить подвиг и поддержать уровень производительности, но готовых задач не оказалось.
Ну и да, интерес и развитие, особенно на хайпе, никуда не ушел - каждый день продолжаю подкручивать какие-то вещи и доуточнять метрики.
Насчёт «разбить на подсистемы» — декомпозиция не убирает голову, она переносит её на границы. Каждая граница между подсистемами — это контракт, интерфейс, и на них теряется контекст (а зачем мы это делали и на что мы сожгли два спринта разработки?). Так что «каждой мелкой подсистеме коллектив не нужен» — да, но только пока кто‑то держит знание о том, как части стыкуются и зачем они вообще нужны. Вполне возможно что это даже не инженерная задача.
Насчёт «ИИ не расширяет когнитивные возможности» — согласен, не расширяет. Контекст выносится наружу — спеки, контракты, issue‑файлы или задачи, чтобы в голове осталось только суждение: что строим и как разруливать стыки. Кодогенерация это действительно не узкое место в текущих реалиях, и в таком процессе разработки проблема начинается с управления тем где живёт знание о границах и особенностях эксплуатации.
У вас в проектах где жило это знание — в архитекторе, вики или коде?
Вариантов два - или искать альтернативных провайдеров, или искать более лояльные компании.
Для первого случая из личного опыта могу порекомендовать perplexity api - доступ актуальным моделям (openai, anthropic, google и тд) без танцев с бубном, но тарификация может отличаться от оригинала.
Для второго случая - опыт перехода показал что deepseek v4pro справляется не сильно хуже. Есть специфичные вещи где пока есть сложности (например я так и не смог адекватно подружить его с Unity в домашних проектах), но на условных задачах по перекладыванию json'ов справляется нормально, особенно если накормить его референсами.
И да и нет.
Нет, потому что решение из статьи у меня работает на том, что весь организационный контекст сидит в одной голове и он постепенно выносится наружу по мере необходимости. Открытый вопрос: можно ли заменить эту голову внешним источником истины — спецификациями, контрактами, issue-файлами или чем-то еще.
Да, потому что общий подход не меняется от масштаба команды и продукта/проекта, но в это нужно осознанно инвестировать. Если речь идет про огромный легаси который пилился годами - на таком проекте адаптация может занять месяцы, а то и годы. На новых проектах - счет пойдет на дни.
Если убрать всех глупых людей - когда-то этим глупым человеком неизбежно становишься ты.
Глупость - понятие относительное, если человек продолжает работать - значит есть что-то почему он продолжает работать. Возможно он хорош в других задачах о которых мы не знаем.
Дополнительно, альтернативный взгляд может помочь посмотреть на процесс под другим углом и получить вопросы которыми даже не задавались, думая что "тут и так все понятно"
тут два варианта:
Если все держится только на человеке - если нет быстрой замены, не уступающей по инициативности, пониманию и опыту управления всем этим оркестром - процесс начнет буксовать и уничтожать сам себя принося проблемы там где должен был их исправлять. В таком случае начнется бунт, команды будут сознательно саботировать все до чего смогут дотянуться чтобы можно было быстрее показать несостоятельность отдельных практик или всего процесса разом и его упразднят/пересмотрят/третье
Если он успел выстроить систему (идеально - саморегулируемую, но это звучит утопично) - отсутствие одного человека можно пережить временно распределив его функции на других людей/код/ручные операции
Менять процессы в угоду руководства - это не то чтобы нормально, но у каждого руководителя есть понимание того чего он хочет достичь от результатов работы как своих, так и своих подчиненных/систем. Другое дело что процессы плотно связаны между собой и изменение в одном из них не должно драматически влиять на другие, а это часто задача со звездочкой.