Эйнштейн работал в патентном бюро потому что другой работы не нашлось, в те времена (да и сейчас) физик теоретик мало где мог устроиться по специальности.
Для такого человека экономический отдел РЖД может быть лучшей работой на свете.
кто из нас работал в планово-экономическом отделе РЖД? Там ведь только декларируется работа с 9 до 18, по факту тоже бывают переработки, авралы и прочее. При этом коллектив ещё может быть очень токсичный (это мы тоже не знаем).
Так про сферический Waterfall начали вы. По ГОСТу, да и по PMBOK, каскад (водопад) это линейная интерпретация принятых и проверенных допущений. Пока не проверим - не примем. В этом и слабость, на выходе то, что надо, но выход получаем когда-то в будущем, а результат нужен сейчас (фактор времени, а не качества). Если переводить каскад на агентов, то будет примерно так: Базовый запрос (на входе человек), Проверка базового запроса (может быть возврат), Формирование функциональных требований Обследование текущих артефактов (процессов, документов, кода). Уточнение полноты артефактов (может быть возврат) Формирование технического задания (спецификации). Проверка спецификации (может быть возврат) Проектирование решений: - Прототипирование отдельных решений - Проверка отдельных решений (может быть возврат) - Сборка проектных решений - Проверка сборки решений (может быть возврат) Реализация запроектированного: - написание кода - написание тестов - проверка кода (может быть возврат) Поставка реализованного (там еще дальше могут быть разворачивание, тестовая эксплуатация, нагрузочные тестирования и т.п.) и тут на выходе может быть человек. В целом постарался указать только ту работу, которую поручить можно агентам, в промежуточных стадиях люди тоже буду проверять и согласовывать.
В вашем же случае вы сделали: 1) Запрос (на входе человек) 2) Реализация 3) Тестирование 4) Поставка (на выходе оказался человек) Проверок не было. Наличие спецификации в запросе не делает этот подход водопадом. В чем отличие от гибкого подхода? Ни в чем. Сделали быстро, быстро получили обратную связь. Просто из-за уменьшения сроков реализации и тестирования у вас задачи, которые раньше разбивались на несколько итераций теперь делаются за одну. Что делать с этим ускорением: 1) Возможно сократить итерации, если ускорили разработку, значит надо от 2-х недель идти к дням. Чаще коммуницировать с соседями и вот это всё. 2) Оставить как есть, shit happens, раньше тоже некоторые спринты не давали прироста ценности и работу выкидывали, что изменилось? Цена двух недель ведь не выросла, значит и дальше можно выкидывать двухнедельную работу.
Для работодателей у меня недавно был совет: пробовать и испытывать кандидатов, а не просеивать по резюме.
В карьерных консультациях я себя не пробовал, но наверно я бы также посоветовал попробовать, вдруг понравится. К сожалению, тут заранее нельзя просчитать через собеседования и т.д., поскольку ни один человек не обладает знанием реалий работы в разных профессиях, а нейросети, как вы правильно заметили, обучались на куче маркетингового шлака.
Жалуются то везде, но надо понимать, что в IT только жалуются, а в других местах это как бы данность. Я по роду деятельности с разными производствами сталкивался, в it лучше всего.
Я, как консультант, тоже часто отговариваю от каких-то решений, бывает даже, что без альтернативного варианта, типа оставьте как есть. Но в карьерной консультации мне кажется важным всё таки довести человека до решения, а не просто отговорить от неверного.
Ну и нейросеть наверно не сможет ни первого ни второго, даже если человек будет не один день и не с одной моделью сидеть.
Вот в этом посте вашей компании описан случай, когда по бюджету явно потратили больше, чем надо было https://habr.com/ru/posts/1080906/ Такие вещи у вас в системе можно отслеживать?
я тоже про такую реализацию задумался. У меня есть небольшой трекер задач и небольшой скрипт быстрого назначения задач (это всё сделано в Dataexpress https://forum.mydataexpress.ru). Вместо проведения процесса "согласование документа" как одной задачи, в которой последовательно меняются исполнители, статусы и т.д., хотел сделать описание процесса в виде списка последовательно-параллельных задач, которые формируются все вместе, но активируются заданном порядке и в зависимости от результата. При этом часть задач могли бы быть автоматического исполнения (например создается какой-то документ, отчет, отправляется письмо и т.д.). Я не знаю, как это устроено в Сamunda и других BPMN движках, подозреваю, что также на каждое действие создается новый объект и новая запись.
Ну это ваш выдуманный waterfall, однако в данном случае и его нет.
Собственно при использовании агентов как раз лучше, использовать agile: что-то сделали, протестировали, затем либо в прод, либо откатили. Ведь стоимость кода снизилась, значит надо снижать и стоимость определения требований и проектирования, а в этом месте всегда ускорялись ща счёт прототипирования и экспериментальной разработки.
Главное понять , что делать с ускорением разработки, чтобы при этом не ломать много дров.
Может кроме моих вариантов вам ещё что в голову пришло.
Саботаж, то есть прямое вредительство, наблюдается редко. В основном всегда речь идёт про нормальное сопротивление изменениям.
Просто спрошу, вы это делаете для 1С 7.7.
А зачем?
Идея правильная, а вот илюстративная часть не очень подходит
Эйнштейн работал в патентном бюро потому что другой работы не нашлось, в те времена (да и сейчас) физик теоретик мало где мог устроиться по специальности.
кто из нас работал в планово-экономическом отделе РЖД? Там ведь только декларируется работа с 9 до 18, по факту тоже бывают переработки, авралы и прочее. При этом коллектив ещё может быть очень токсичный (это мы тоже не знаем).
Интересная идея, надо обдумать
Так про сферический Waterfall начали вы. По ГОСТу, да и по PMBOK, каскад (водопад) это линейная интерпретация принятых и проверенных допущений. Пока не проверим - не примем. В этом и слабость, на выходе то, что надо, но выход получаем когда-то в будущем, а результат нужен сейчас (фактор времени, а не качества).
Если переводить каскад на агентов, то будет примерно так:
Базовый запрос (на входе человек),
Проверка базового запроса (может быть возврат),
Формирование функциональных требований
Обследование текущих артефактов (процессов, документов, кода).
Уточнение полноты артефактов (может быть возврат)
Формирование технического задания (спецификации).
Проверка спецификации (может быть возврат)
Проектирование решений:
- Прототипирование отдельных решений
- Проверка отдельных решений (может быть возврат)
- Сборка проектных решений
- Проверка сборки решений (может быть возврат)
Реализация запроектированного:
- написание кода
- написание тестов
- проверка кода (может быть возврат)
Поставка реализованного (там еще дальше могут быть разворачивание, тестовая эксплуатация, нагрузочные тестирования и т.п.) и тут на выходе может быть человек.
В целом постарался указать только ту работу, которую поручить можно агентам, в промежуточных стадиях люди тоже буду проверять и согласовывать.
В вашем же случае вы сделали:
1) Запрос (на входе человек)
2) Реализация
3) Тестирование
4) Поставка (на выходе оказался человек)
Проверок не было. Наличие спецификации в запросе не делает этот подход водопадом. В чем отличие от гибкого подхода? Ни в чем. Сделали быстро, быстро получили обратную связь. Просто из-за уменьшения сроков реализации и тестирования у вас задачи, которые раньше разбивались на несколько итераций теперь делаются за одну.
Что делать с этим ускорением:
1) Возможно сократить итерации, если ускорили разработку, значит надо от 2-х недель идти к дням. Чаще коммуницировать с соседями и вот это всё.
2) Оставить как есть, shit happens, раньше тоже некоторые спринты не давали прироста ценности и работу выкидывали, что изменилось? Цена двух недель ведь не выросла, значит и дальше можно выкидывать двухнедельную работу.
Для работодателей у меня недавно был совет: пробовать и испытывать кандидатов, а не просеивать по резюме.
В карьерных консультациях я себя не пробовал, но наверно я бы также посоветовал попробовать, вдруг понравится. К сожалению, тут заранее нельзя просчитать через собеседования и т.д., поскольку ни один человек не обладает знанием реалий работы в разных профессиях, а нейросети, как вы правильно заметили, обучались на куче маркетингового шлака.
Жалуются то везде, но надо понимать, что в IT только жалуются, а в других местах это как бы данность. Я по роду деятельности с разными производствами сталкивался, в it лучше всего.
В IT это как раз было реально, конечно ключевое слово "было".
Странные придирки к коду на VBA. Хороший понятный код.
Я, как консультант, тоже часто отговариваю от каких-то решений, бывает даже, что без альтернативного варианта, типа оставьте как есть. Но в карьерной консультации мне кажется важным всё таки довести человека до решения, а не просто отговорить от неверного.
Ну и нейросеть наверно не сможет ни первого ни второго, даже если человек будет не один день и не с одной моделью сидеть.
Можно список примеров работ, куда можно свитчнуться и за год выйти на зарплаты выше средней?
Я такой же, никак не могу синтаксис запомнить и базовую обвязку, но пока до агентского кодинга не дошёл.
хотел сделать универсальный и быстро настраиваемый инструмент.
Вот в этом посте вашей компании описан случай, когда по бюджету явно потратили больше, чем надо было https://habr.com/ru/posts/1080906/
Такие вещи у вас в системе можно отслеживать?
я тоже про такую реализацию задумался.
У меня есть небольшой трекер задач и небольшой скрипт быстрого назначения задач (это всё сделано в Dataexpress https://forum.mydataexpress.ru).
Вместо проведения процесса "согласование документа" как одной задачи, в которой последовательно меняются исполнители, статусы и т.д., хотел сделать описание процесса в виде списка последовательно-параллельных задач, которые формируются все вместе, но активируются заданном порядке и в зависимости от результата. При этом часть задач могли бы быть автоматического исполнения (например создается какой-то документ, отчет, отправляется письмо и т.д.).
Я не знаю, как это устроено в Сamunda и других BPMN движках, подозреваю, что также на каждое действие создается новый объект и новая запись.
И тут напишу.
Никакой фактуры нет, какие ресурсы, какая нагрузка.
Пост видимо рассчитан на тех, кто так же не умеет считать ресурсы и всегда перезакладывает в три раза.
Пост на кого расчитан?
На тех, кто так же не умеет расчитывать ресурсы и перезакладывает в три раза?
Ну это ваш выдуманный waterfall, однако в данном случае и его нет.
Собственно при использовании агентов как раз лучше, использовать agile: что-то сделали, протестировали, затем либо в прод, либо откатили. Ведь стоимость кода снизилась, значит надо снижать и стоимость определения требований и проектирования, а в этом месте всегда ускорялись ща счёт прототипирования и экспериментальной разработки.