Программисты хорошо делают у вас оценку или обычно вынуждены перерабатывать? На мой практике, программисты очень часто недооценивают затраты, забывая включить какой-то ресерч, транзакционные издержки и слепые зоны. Также у большинства разработчиков есть стремление показать, что они смогут решить задачу более оперативно и ответственно, чем обычно выходит, и это также приводит к недооценке.
Как вы с этим справляетесь на практике? Или, как собственник, вы закрываете на это глаза, оставляя ответственность самим исполнителям?
Тут мы рискуем уйти в спор о терминологии. На мой взгляд, итерационная разработка никак не мешает проектированию общей архитектуры системы, а также появлению документации. Но ТЗ по водопаду будет существенно отличаться от проекта в итерационной разработке.
Пример с домом не совсем отражает ситуацию даже не этапе строительства. Если взять хорошую команду, которая делала многократно похожие проекты и доводила их до продакшена, затем набрать общую структуру проекта и декомпозировать все строительство на понятные команде блоки, то локально специалисты смогут принять все необходимые решения о материалах, инструментах и методах. В итоге, дом будет построен. Но, в отличии от дома, программный продукт гораздо более живой и модифицируемый, с одной стороны, а также более абстрактный с другой. Поэтому и методы работы должны различаться, с учётом их особенностей.
А как в этом помогает ТЗ? По факту, оно будет согласовываться невероятно долго или, как обычно, часть руководителей передаст ответственность на кого-то другого. В момент приемки все это всплывёт в виде несоответствия с реальными бизнес-процессами и исполнитель будет вынужден отстаивать свою позицию на основе подписанных документов. Ситуация может легко измениться и со сменой одного из руководителей. При итеративный разработке остаётся больше степеней свободы, чтобы это учесть и подстроиться.
Не очень понятна цель статьи. Поверхностное перечисление возможностей кажется не очень полезным, хотелось бы более глубокого анализа и "историй успеха" - как эффективно удалось решить конкретные рабочие кейсы, какие выводы сделали.
В этом вся прелесть ChatGPT, что он может сэкономить профессионалу время, как инструмент, но не может заменить специалиста. На текущем уровне, во всяком случае.
После появления Dall-E 3 в ChatGPT, остальное уже мало впечатляет. Вот там круто, действительно.
Программисты хорошо делают у вас оценку или обычно вынуждены перерабатывать? На мой практике, программисты очень часто недооценивают затраты, забывая включить какой-то ресерч, транзакционные издержки и слепые зоны. Также у большинства разработчиков есть стремление показать, что они смогут решить задачу более оперативно и ответственно, чем обычно выходит, и это также приводит к недооценке.
Как вы с этим справляетесь на практике? Или, как собственник, вы закрываете на это глаза, оставляя ответственность самим исполнителям?
Тут мы рискуем уйти в спор о терминологии. На мой взгляд, итерационная разработка никак не мешает проектированию общей архитектуры системы, а также появлению документации. Но ТЗ по водопаду будет существенно отличаться от проекта в итерационной разработке.
Пример с домом не совсем отражает ситуацию даже не этапе строительства. Если взять хорошую команду, которая делала многократно похожие проекты и доводила их до продакшена, затем набрать общую структуру проекта и декомпозировать все строительство на понятные команде блоки, то локально специалисты смогут принять все необходимые решения о материалах, инструментах и методах. В итоге, дом будет построен. Но, в отличии от дома, программный продукт гораздо более живой и модифицируемый, с одной стороны, а также более абстрактный с другой. Поэтому и методы работы должны различаться, с учётом их особенностей.
А как в этом помогает ТЗ? По факту, оно будет согласовываться невероятно долго или, как обычно, часть руководителей передаст ответственность на кого-то другого. В момент приемки все это всплывёт в виде несоответствия с реальными бизнес-процессами и исполнитель будет вынужден отстаивать свою позицию на основе подписанных документов. Ситуация может легко измениться и со сменой одного из руководителей. При итеративный разработке остаётся больше степеней свободы, чтобы это учесть и подстроиться.
Какие условия?
Поделитесь промптом )
Не очень понятна цель статьи. Поверхностное перечисление возможностей кажется не очень полезным, хотелось бы более глубокого анализа и "историй успеха" - как эффективно удалось решить конкретные рабочие кейсы, какие выводы сделали.
Где этому учат?
Разный горизонт планирования
Проблемы целеполагания нет, люди сами дадут сети целый ворох безумных и опасных целей.
Можно просто вставить структуру таблиц и дать комментарии, если назначение таблицы не понятно
Говорят, что полезно начать разговаривать с самим собой, просто описывать все, что вы видите и делаете.
В этом вся прелесть ChatGPT, что он может сэкономить профессионалу время, как инструмент, но не может заменить специалиста. На текущем уровне, во всяком случае.
Будем ждать, очень полезно
Дело за малым - получить аккредитацию.
А затем ещё голос прикрутят. Будущее уже здесь, как оказалось.
Интересно будет на это посмотреть. Но маловероятно, что получится что-то обосновать, ведь он не копирует.
А! И правда, эту связь нужно изучить. Вдруг игры как-то влияют на мозг и заставляют думать ошибочно...
Уже выросло целое поколение на играх, что ещё они хотят изучить? Недостаточно текущей информации?
Спасибо, отличный материал!