• Чего не говорят об отчете Tesla
    +3
    Очень опасно надеяться на «самый продвинутый» автопилот, потому что изредка он все же ошибается.
    Более приземленный случай. В последнее время навигаторы пытаются облегчить жизнь водителя, показывая ему знаки, движения по полосам на перекрестках, ограничения скорости и т.п.
    Действительно, это может показаться удобным, но лишь до первого расхождения данных в навигаторе и на дороге. Можно проехать тысячи знаков, поверить во «всезнающий» навигатор с самыми актуальными данными, и затем попасть на лишение, потому что навигатор «не знает» про недавно установленный временный знак «Обгон запрещен».
    В этом случае водителю все равно необходимо следить за знаками и разметкой, и подсказки только вредят. Также и с «автопилотом». Если за ним нужно следить, толку от него ноль.
  • Диаграмма сценариев использования в процессе разработки ПО
    +1
    dedyshka, fpinger безусловно, СИ очень полезны для разработчиков, и я ратую за их широкое использование :) Но, к сожалению, СИ в классическом виде, состоящий только из шагов основного и альтернативных потоков, не дает полной спецификации деталей системы. Не специфицированными остаются элементы пользовательского интерфейса, сообщения об ошибках, различные информационные сообщения и т.п.
    В аджайле эти детали обычно проговариваются голосом и потому СИ можно рассматривать как эпики для user story, и они вполне самодостаточны.
    В традиционных методологиях СИ необходимо дополнительно детализировать. То есть, в итоге получается документ, содержащий в себе СИ + детализацию требований, которая уточняет те или иные шаги, детали UI, обработки ошибок и т.п.
  • Диаграмма сценариев использования в процессе разработки ПО
    0
    Сценарии использования как раз очень полезны! Даже методология RUP исповедует Use Case Driven подход. Но статья немножко не об этом :)
    Довольно часто такой артефакт как диаграмма сценариев использования (именно диаграмма, а не модель СИ, которая как раз и включает в себя диаграмму + текстовое описание сценариев + детальные требования) проектными командами не используется, потому что нет понимания, зачем она нужна.
    Я и попытался рассказать, что и диаграмма СИ бывает очень полезна, только надо знать, для чего её применять.
  • Управление задачами в проектной организации
    +1
    Из приведенного текста не заметно, что развернутая система упрощает жизнь ГИПов. Несмотря на красные задачи, производственный процесс, судя по всему, успешно работает.
    А вот жизнь главного инженера да, скорее всего упростилась, но целью добавления временных затрат подчиненных. И я бы не был настолько оптимистичен, утверждая, что процесс успешно автоматизирован, так как его внедрение происходит административными методами.

    Похоже, что главный инженер уже сразу предложил решение, которое, по его мнению, поможет снизить количество неисполненных задач, а исходную проблему так и не попытались найти. По крайней мере, в статье об этом нет ни слова.

    Но проблема может быть совсем другой. Например, что главный инженер-самодур, раздает по 15 незначительных задач в день (по 2 в час!) и заставляет по ним отчитываться, а каждый отчет требует у подчиненных 15-20 минут на подготовку. Поэтому сотрудники такие задачи не любят и саботируют их. В этом случае и решение, скорее всего, было бы совсем другое, и не лежащее в области автоматизации.