Comments 17
ну и за какую веревочку надо дернуть в этой выдуманной ситуации?
И, кстати, такие картинки надо выкладывать не в jpeg-е.
И, кстати, такие картинки надо выкладывать не в jpeg-е.
А как выложить? Расскажите, у меня опыта совсем нет…
Помоему вполне реальная ситуация полного хаоса :)
Карта расписана не полно. Если работают профессионалы, на мой взгляд, стоит:
1) Обьяснить разработчикам смысл того, что они пишут
2) Сделать публичными задания и время их выполнения, устроить соц. соревнование с раздачей пряничных слонов, если разработчики заняты однотипными заданиями, и их результаты можно оценить в одной шкале.
3) Сделать возможность «плавающего» графика. Задержался утром? Не проблема — отработаешь вечером.
4) Раздать чай и печеньки, если это еще не было сделано, дать возможность пообщаться в неформальной обстановке.
5) Сделать более четкую зависимость получаемых денег от результата. В KPI внести качество кода, например по количеству пойманных багов и их критичности в первый месяц после выпуска кода.
6) Перемены в работе. Нельзя допускать застаивания и скуки.
7) Проанализировать проблемы коллектива. Если есть «черная овца», разлагающая работу — смело выбрасываем. Если есть врожденный говнокодер, не тешим себя мыслью, что он когда нибудь под вашим чутким руководством научиться все делать хорошо, выбрасываем.
8 или 0) Если у вас нет ресурсов или возможности чтобы что то поменять, или проблема таки в вас — уходите сами.
Карта расписана не полно. Если работают профессионалы, на мой взгляд, стоит:
1) Обьяснить разработчикам смысл того, что они пишут
2) Сделать публичными задания и время их выполнения, устроить соц. соревнование с раздачей пряничных слонов, если разработчики заняты однотипными заданиями, и их результаты можно оценить в одной шкале.
3) Сделать возможность «плавающего» графика. Задержался утром? Не проблема — отработаешь вечером.
4) Раздать чай и печеньки, если это еще не было сделано, дать возможность пообщаться в неформальной обстановке.
5) Сделать более четкую зависимость получаемых денег от результата. В KPI внести качество кода, например по количеству пойманных багов и их критичности в первый месяц после выпуска кода.
6) Перемены в работе. Нельзя допускать застаивания и скуки.
7) Проанализировать проблемы коллектива. Если есть «черная овца», разлагающая работу — смело выбрасываем. Если есть врожденный говнокодер, не тешим себя мыслью, что он когда нибудь под вашим чутким руководством научиться все делать хорошо, выбрасываем.
8 или 0) Если у вас нет ресурсов или возможности чтобы что то поменять, или проблема таки в вас — уходите сами.
В этом примере не за что дергать. Реальные ДСР получаются сложнее и в них набор признаков намного шире. У меня не хватило места и воображения на этот случай. Попытался хотя бы принцип отобразить.
ну чем не майндмэп?..
собственно, в том и вопрос: что тут есть такого, чего нет в интеллект-картах? может стоило чуть развернутее пример объяснить.
собственно, в том и вопрос: что тут есть такого, чего нет в интеллект-картах? может стоило чуть развернутее пример объяснить.
Думаю, Вы правы. Нужно было пример развернуть.
Просто хотелось привести пример, который соответствовал бы ИТ-тематике Хабра. Неудачная попытка.
По поводу майндмэпинга. Техники, действительно похожие. Принципиальных отличий 2:
1. ДСР можно описать по принципу «снизу вверх», то есть оно имеет уровневую структуру. В то время как в майндмэпинге все ветки ведут в центр.
2. Майндмэпинг больше служит описанию проблемы, представлению ясной картины. ДСР имеет своей целью решение проблемы. В этом смысле ММ имеет смысл сравнить с системами взаимосвязанных компонентов (СВК).
Просто хотелось привести пример, который соответствовал бы ИТ-тематике Хабра. Неудачная попытка.
По поводу майндмэпинга. Техники, действительно похожие. Принципиальных отличий 2:
1. ДСР можно описать по принципу «снизу вверх», то есть оно имеет уровневую структуру. В то время как в майндмэпинге все ветки ведут в центр.
2. Майндмэпинг больше служит описанию проблемы, представлению ясной картины. ДСР имеет своей целью решение проблемы. В этом смысле ММ имеет смысл сравнить с системами взаимосвязанных компонентов (СВК).
раскрою подробность не слишком известную: майндмэпы в виде радиальной схемы — не единственный вариант, просто он наиболее распространен, да и ПО реализовано чаще всего именно под него.
есть т.н. омега-мэппинг — рисуем текущее состояние в одном углу, желаемое — в противоположном и приступаем сначала к более детальному описанию, а затем из 2-х схем пытаемся придумать пути реализации (в некоторых источниках указывают, что нужно только действия указывать, но, по-моему и не только, мнению, это уход в крайности).
есть т.н. омега-мэппинг — рисуем текущее состояние в одном углу, желаемое — в противоположном и приступаем сначала к более детальному описанию, а затем из 2-х схем пытаемся придумать пути реализации (в некоторых источниках указывают, что нужно только действия указывать, но, по-моему и не только, мнению, это уход в крайности).
Никогда не слышал про омега-мэппинг. Мне, как тренеру, такая техника интересная.
Я согласен, что радиальный вариант когнитивных карт более распространен. Это вполне резонно, потому что это именно карта.
Я согласен, что радиальный вариант когнитивных карт более распространен. Это вполне резонно, потому что это именно карта.
рад был подсказать )
это только предположение, но возможно менее распространен из-за того, что пути реализации часто вытекают из детального понимания текущего состояния/предметной области/желаемого состояния, т.е. случаев, когда в принципе не хватает радиальной карты — не слишком много и сталкиваются с ними далеко не все.
это только предположение, но возможно менее распространен из-за того, что пути реализации часто вытекают из детального понимания текущего состояния/предметной области/желаемого состояния, т.е. случаев, когда в принципе не хватает радиальной карты — не слишком много и сталкиваются с ними далеко не все.
Я бы, на вашем месте, привел бы ссылку не первоисточник, а именно книги товарища Элии Голдрата.
ДТР, так же как и дерево будущей реальности, дерево перехода и схема локализации конфликта «грозовая туча» изначально в оборот были введены именно им. Да и практики, описываемые вами были сформулированы им же.
ДТР, так же как и дерево будущей реальности, дерево перехода и схема локализации конфликта «грозовая туча» изначально в оборот были введены именно им. Да и практики, описываемые вами были сформулированы им же.
Я вижу только две проблемы которые осталось решить для полного счастья, это субъективность восприятия ситуаций, которая не позваляет создать полную модель и неспособность принимать волевые решения, которая не позволяет изменть модель
Как по мне, так как раз самое интересное начинается уже после того, как выписано ДСР. Как раз построение корневой тучи, дерево перехода, нахождение предпосылок является подходом к решению проблем. Построение ДСР есть первый шаг (ну второй, максимум) из сложной (и, возможно, продолжительной) цепи локализации и устранения проблем в проекте.
И далеко не обязательно, что предпосылка, которая связана с другими большим количеством связей, является основной проблемой.
И далеко не обязательно, что предпосылка, которая связана с другими большим количеством связей, является основной проблемой.
В небольших проектах, я думаю, ДСР можно использовать и как самостоятельный инструмент. Все зависит от того, как сформулирован первоначальный запрос.
Этот признак может и не являться основной проблемой, однако устранив его, мы устраняем наибольшее количество остальных признаков.
Этот признак может и не являться основной проблемой, однако устранив его, мы устраняем наибольшее количество остальных признаков.
Sign up to leave a comment.
Дерево существующей реальности