Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Проблема — это инвертированная цель.На основе каких предпосылок сделано это заключение?
Говорят, что русскому мышлению присущ негативизм. Поэтому мы любим идти от проблем, от настоящего (а что у нас болит?). Другая культура может идти от целей, от будущего (а куда мы хотим прийти)? Это накладывает отпечаток на методы работы.Речь, видимо, идет про реактивный и проактивный подходы?
Поэтому, я бы сказал так, что имеет смысл определять цели и задачиЯ как-то раз свои соображения по поводу задач и целей вот тут описал.
Такой пример.
Сейчас лето. У меня в СПб за окном в 11 часов уже 29 градусов... Но будет и зима.
Представьте себе, что просыпаетесь ночью от холода. Это под одеялом холодно. А в квартире вообще - дубак. На улице -25, а батареи холодные. И света еще нет к тому же. Так как народ ринулся включать электрические обогреватели и сеть нагрузки не выдержала.
Ситуация элементарная. Где-то лопнула труба. Ремонтная бригада приедет, найдет больное место. Раскопают, заварят, тепло дадут снова. И будет вам счастье, может даже не придется батареи менять...
Как было написано выше
Текущее состояние -- труба течет.
Желаемое состояние -- труба не течет.
Наша цель -- чтоб труба не текла. Теперь труба не течет.
Все правильно? Проблему действительно решили?
А если трубу снова прорвет завтра (послезавтра, через неделю, через месяц) но в другом месте? Это ведь будет уже совершенно другая проблема, не так ли? А потом и третья совершенно новая проблема, а за ней четвертая, пятая и т.д.Акцентирование внимания на трубе аналогично акцентированию внимания на разработке ПО в посте bas'a.
Готов ли смириться с этим пользователь/потребитель? Или у него тут ничем не обоснованные "хотелки". Труба-то ведь сейчас в момент устранения аварии не течет! Значит и проблемы нет?
М... это твое определение или академическое?..Не академическое.
Разница между текущим состоянием и желаемым не всегда является проблемой.Выше я писал, что эту разницу можно назвать хоть стулом.
Мне нравится название - проблема.Вообще ожидания тут не при чем.Я и не говорил про ожидания. Скорее про желания.
Я бы сформулировала проблему (в данном контексте) как препятствие, мешающее достижению цели.Ok, принимается. Давай назовем разницу между текущим и желаемым положением не проблемой, а препятствием.
Согласен, "стул" тут не совсем подходит. А выражаться оно может в чем угодно - и в описанной разнице тоже, но только как частный случай.А в чем угодно?
Вообще по-моему странная взаимосвязь между проблемами и целью.Не спорю. Просто приведенная выше терминология мне наиболее удобна. При этом готов поддерживать беседу в рамках других определений. Главное, чтобы они [определения] были.
Если взять профессиональную ситуацию, то цель обычно ставит заказчик. Можно и самому поставить, если рассуждать абстрактно.ИМХО скорее у Заказчика возникает какая-то идея. А цель ставить может кто угодно - консалтеры, разработчик ПО, сам Заказчик, etc..
Ни кто-то, а мы сами вводим это ограничение
Сначала ставим бизнес цель, потом ее декомпозируем до целей, которые мы можем решить с помощью ПО, а уже потом ищем проблемы, которые нам мешают этого достичь.Мое глубокое имхо, что такой подход несколько порочен.
Ведь решить проблему можно не только с помощью ПО. То есть вообще говоря углубление в частый конкретный вариант решения - это не гуд (в случае, если идет процесс анализа проблем и стратегическое решение по данной проблеме еще не выработано). Почему разница состояний - это обязательно проблема? Новое, желаемое состояние не всегда обуславливается необходимостью решать проблему. Мне так кажется.В приведенном определении речь идет не о каких-то абстрактных состояниях (новом-старом), а именно о текущем и желаемом. И именно в их контексте и появляется проблема.
Вот как-то режет слух определение проблемы...С удовольствием обсудил бы иной взгляд на термин "проблема".
... Просто, определение цели, состояния системы... как-то напомнило "идеи" IPMA, а уж там проблема имеет иное толкование.
Не ограничиваем ли мы тогда решение проблемы только той областью, которую изучаем?Почему ты сделал вывод, что кто-то вводит такое ограничение?
Не правильнее бы было поставить цель, а уже потом искать проблемы, которые мешают нам достичь этой цели?Если принять терминологию вверху поста, то таки да - вначале ставится цель (мы понимаем, что хотим иметь), а потом уже определяется проблема (разница между тем что имеем сейчас, и тем что хотим).
Я могу предложить тебе очень эффективный метод проверки неполноты ТЗ. Берешь ТЗ листов на 500 и через 10 минут возвращаешь с пометкой "неполнота".
Делать презентацию ТЗ на словах с доской, это быстрее и можно выловить явные пробелы, особенно если согласователей много.
+ плотное и желательно очное общение с автором по всем вопросам.
Есть техники быстрого чтения - очень кстати эффективные.
В последнее время приходится согласовывать и рецензировать большое кол-во документов.
Задумался как это делать более эффективно (быстрее, но без потери качества)?!
Как например большие руководители (президент) это делают? Есть какие-нить специальные техники?
