Ребята ниже правильно ответили: нужно фиксировать границы проекта, а новые требования выносить в отдельный этап или (если они критичны для запуска проекта) увеличивать время и ресурсы. Нельзя в литровую банку налить два литра воды, это законы физики.
Посоветовать конкретную книжку не могу, но рекомендую поискать литературу по фразе «управление изменениями в проекте».
Примеров много, но приводить их не стоит по ряду причин:
1. Не все компании готовы к публичному обсуждению своих процессов ведения проектов.
2. Приведенный пример — это выжимка из ряда случаев. Я постарался синтезировать наиболее объективный пример, чтобы не уводить читателя в обсуждение качеств конкретного человека, проекта или компании.
3. В реальных случаях проблема может быть в другом. Например, во взаимоотношении заказчика и исполнителя.
Я вас услышал, спасибо. В следующий раз попробую взять реальную историю и обезличить.
В связи с тем, что «Критик должен быть готов и способен в любой момент и по первому требованию занять место критикуемого им и выполнять его дело продуктивно и компетентно; в противном случае критика превращается в наглую самодовлеющую силу и становится тормозом на пути культурного прогресса».
А теперь перепишите эту же самую статью, но с указанием, как нужно исправить сайты магазинов, чтобы ваша или похожие задачи были решаемы. Когда будете писать, постарайтесь воздержаться от субъективизма и грамматических ошибок.
Для интересующихся. Позвонил в саппорт оператора, сказали, что это проблема симки, а не телефона. Мол старая она, взяла и умерла. Заменили в течение 10-15 минут. С собой нужен паспорт.
Спасибо за статью. Установил только ради эксперимента — симка не могла подключиться к оператору. Прошивка тормозит, особенно на перелистывании экранов и в списке программ. Графика некрасивая, начиная от заставки и заканчивая интерфейсом. Иконки растянутые не по размеру.
Вы, к сожалению, не на пике инноваций и прогресса. Составление контента из заранее определенных блоков существует достаточно давно. Наиболее простой пример можете посмотреть на behance.net.
(по клику большая картинка)
Что касается самого подхода, то я не вижу смысла в конструкторе — все равно нужно думать над составлением структуры статьи. Лучше предлагать набор типовых шаблонов и отдельно WYSIWYG (если кому-то не хватило шаблонов).
Спасибо за развернутое описание. Вот Вы и ответили на вопрос «почему нет».
Понимаете, внедрять нужно то, что гарантированно будет работать и помогать. Причем стоимость владения таким решением должна должна быть как минимум не больше того, что я привел в посте. Ну или плюсы должны очень сильно перевешивать. Поэтому «онтологии форева!», но «папки пока не маздай» :)
Приведите, пожалуйста, практический пример, который можно реализовать и внедрить в компании? Хотя бы на уровне взаимодействия между сотрудниками одного отдела.
Я, конечно же, за светлое будущее. Но исключительно ради его практических плюсов, а не абстрактного блага.
Это клуб для общения дизайнеров интерфейсов и юзабилити-специалистов. Пока что это обычное комьюнити как ru_ucd, только закрытое. Членство модерирует создатель.
Я не пытался решить задачу организации информации. Речь о презентации формата и удобства его использования в рамках конкретного процесса. Файлы и папки в этом топике не более чем сущности, посредством которых представлен формат. Но за активность спасибо :)
Если в зараженные эболой районы Африки завезти лейкопластыри, они тоже будут в восторге, потому что у них и этого нет. Впрочем, тебе обо всем уже давным-давно рассказали.
Здравствуй, робот. Вместо того, чтобы взяться за ум (о чем тебе около года назад рассказали в ru_ucdesign), ты опять пытаешься составлять чек-листы и измерять гаечным ключем силу эмоций влюбленного в ежа дикобраза. Что ж, удачного брутфоса.
Посоветовать конкретную книжку не могу, но рекомендую поискать литературу по фразе «управление изменениями в проекте».
1. Не все компании готовы к публичному обсуждению своих процессов ведения проектов.
2. Приведенный пример — это выжимка из ряда случаев. Я постарался синтезировать наиболее объективный пример, чтобы не уводить читателя в обсуждение качеств конкретного человека, проекта или компании.
3. В реальных случаях проблема может быть в другом. Например, во взаимоотношении заказчика и исполнителя.
Я вас услышал, спасибо. В следующий раз попробую взять реальную историю и обезличить.
Вернулся на старую официальную прошивку.
Ну, в любом случае, успехов!
(по клику большая картинка)
Что касается самого подхода, то я не вижу смысла в конструкторе — все равно нужно думать над составлением структуры статьи. Лучше предлагать набор типовых шаблонов и отдельно WYSIWYG (если кому-то не хватило шаблонов).
Понимаете, внедрять нужно то, что гарантированно будет работать и помогать. Причем стоимость владения таким решением должна должна быть как минимум не больше того, что я привел в посте. Ну или плюсы должны очень сильно перевешивать. Поэтому «онтологии форева!», но «папки пока не маздай» :)
А теперь расскажите почему схема ограниченная, запутанная и вредная?
Я, конечно же, за светлое будущее. Но исключительно ради его практических плюсов, а не абстрактного блага.
Я не пытался решить задачу организации информации. Речь о презентации формата и удобства его использования в рамках конкретного процесса. Файлы и папки в этом топике не более чем сущности, посредством которых представлен формат. Но за активность спасибо :)