суббота, 11 июня 2011 г.

Комментарий к передаче Точки Ветвления - как пытались управиться с управлением информацией и т.п.

Фрагмент из Google Docs - готовимся к передаче


Очень интересная была беседа, мои предположения, что Стас не даст заскучать, оправдались. Ниже мой комментарий к передаче.
Данные, папки, их структуризация, проблемы коммуникации и взаимодействия и т.д. всегда мне были интересны, хотя все это звучит для архитектора крайне занудно. Я не являюсь ни супер САПР-специалистом (все-таки я архитектор), ни тем более профессионалом в PDM-системах. Но когда Филипп Кац позвал меня на передачу, я с удовольствием согласился. Всегда полезно послушать других. Так оказалось и в этот раз.


В первую очередь скажу, что реальным специалистом в управлении информацией был Стас Воронков. Собственно он, а также Эдуард Хайман и Филипп Кац придали ту самую концептуальную глубину передаче.


* * *


Итак, "повестка дня" передачи:
  • Информация пронизывает всю архитектурную деятельность, но как ей управлять? 
  • А что такое “управление знанием” (knowledge management) и “CAD-менеджмент”? 
  • И зачем это всё нужно нам? 
  • Каковы процессы управления информации в рамках архитектурного проектирования? 
  • Какой инструментарий и системы могут быть использованы для управления знанием/информацией? 
  • Последние тренды в управлении информацией? 
  • Какая роль и возможности у социальных медиа и сервисов подобным Google.Docs? 
  • Как сочетаются порядок, стандартизация и творчество?
У меня были некоторые предложения по вопросам для передачи, но в ходе подготовки они немного модифицировались. Поэтому я хотел бы прокомментировать несколько моментов самой передачи и закрепить свои первоначальные мысли.


* * *


Комментарии:
Прежде всего, прошу прощения некорректно сравнил nanoCAD и AutoCAD! Непростительная ошибка..
Потом дал жару, приведя пример Inforbix, забыл упомянуть о следующей отличительной особенности этого сервиса:


"Тесты, тесты, тесты!" - Стас Воронков. Действительно, чем больше тестируешь как и модель в САПР, саму САПР(здесь Стас занятно рассказывает историю одна на 00:31:05) -  ну и конечно весь наш великий архитектурный замысел!
Что касается моего представления об управлении знанием: влачу свое профанное существование и дальше, однако некоторое время назад пришла в голову интересная мысль. Если целенаправленно посещать форумы по САПР (и в принципе технические), собирать различные сведения по темам, упорядочивать и переводить это все для других в Best Practices согласно своим задачам проектирования, то, может, это и есть своеобразное управление знаниями?
Касательно технологических проблем, возникших у Стаса во время проектирования n-ной PDM-системы, - файлы в акаде по 1 Гб? Наверное, стоило использовать ссылки, чтобы разбивать на куски... Не знаю, может не понял что-то
Fix this sh..! - новый лозунг архитектора-параметриста.
Поучительная история про мерседес и трактор на 01:00:43
Тормоз в развитии семантики - отсутствие стандартов и отвественности за внесении информации (комментарий Стаса)
О SharePoint и что происходит с данными, когда они попадают туда? 01:18:47 Данные(любые) сразу же приобретают смысл(!) в системе, но если данные прошли вне системы - например, через Skype переслали файл - тогда данные становятся бессмысленными.. ну и бесполезными, наверное.
Метатег "яблоко": магазин яблок или магазин айфонов? 
Конференция в МИРЭА по теме семантике, системах искусственного интеллекта и т.д. (осень 2011)
О Pachube и забавном процессе управления светом в офисе с лэптопа - 01:33:35
Филипп Кац о проблеме "маршрута проектирования" в малых фирмах; нелинейный процесс концептуального проектирования и конфликт с "жесткой" PDM-системой  - 01:35:33
Эдуард Хайман осмысляет архитектурный процесс - 01:49:49. Да, мы можем "спроектировать эмоции" человека...
....Мы не просто потребители, а творческие потребители...


* * *

Зафиксирую свою недавнюю мысль - работая с проектом в цифровой среде, мы имеем дело с большим количеством файлов, которые вместе приобретают больший смысл, чем по отдельности:
  • Адаптация продукта (например, светильника) или материала (например, мрамора) в контексте проекта выражается в его определенных свойствах, которые в рамках проекта приобретают ценность! в других случаях этот компонент может "не работать". вот где качественное решение
  • Поэтому встает следующий ряд задач по формализации процесса проектирования:
    • Целостное представление "облака" компонентов (от конкретного материала в растровой картинке до общей схемы-чертежа) проекта 
    • Повторное использование компонента проекта в других проектах - в одном проекте компонент "мрамор" имеет финиш "антик", а в другом - "полированный"; при этом это один и тот же материал. Параметрические объекты с вариантами?


* * *


А вот отрывок из общего гуглдокса (в ходе подготовки передачи):


  • Взаимодействие, совместная работа, управление информацией проекта сейчас очень актуально. Представьте - например, Точка Ветвления развивается, работает над несколькими проектами одновременно совместно с другими командами, в том числе и удаленно, параллельно документируется процесс, ведутся блоги, нарастает массив информации и знания и т.п. Разрозненные гуглдоки, закладки в браузере, твиты, файлы на ноуте (а куда я их положил? кто-нить помнит?) и т.д. уже не способны поддерживать целостный процесс работы группы. Тем более, если Точка Ветвления расширяется, цветет и пахнет. Мне кажется, четкая концепция в области информационных процессов может пригодиться. Вот я к чему.
  • Нам всем интересен процессы управления информации в рамках архитекутрного проектирования. Мы (каждый по-своему) заинтересованы различными аспектами: управление САПР (внедрение, стандарты и т.п.), социальные медиа, системы документооборота и вообще новые среды взаимодействия и сообщения.
  • Мы  пригласили Стаса - специалиста в области разработок сервисов, корпоративных приложений (не сетей) и т.п.. В принципе, нам важна концепция действия в этом направлении. Конкретное техническое исполнение - уже детали. Но для начала необходимо понять специфику разработки таких сред. Пусть и отрывочно. И Стас мог бы скорректировать нас, помочь точнее сформировать ТЗ-концепцию, указать на подводные камни. Допустим, какие самые частые ошибки людей, которые хотят внедрить у себя какие-либо видов порталов? Мне было бы интересно это узнать. (пусть и сейчас мы не будем ничем пользоваться, а просто рассуждаем)
  • Что мы хотим узнать на данный момент(цель передачи?): какие ключевые проблемы встают перед архитектором (скорее в небольшой команде) в сфере информационных потоков - проблема поиска, проблема стандартизации, разграничения ролей и единой информационной базы. Также существуют и другие сложности - накопление знаний, сведений и управление ими.
  • Какие способы решения существуют для этих задач, с чего начать, с чем разобраться - и тут Стас, как специалист, помогает нам в этом. (да, ок, можно обсудить) ...

Вот еще один:



Основная моя мысль по поводу твоего комментария такова - существует несколько путей внедрения информационной инфраструктуры в компании(может, поправишь меня, как это все назвать верно):
  • Возьми многофункциональную платформу (например, SharePoint - очень условно)
  • Возьми простые бесплатные инструменты, типа Google Services и Dropbox, пойми, что ты хочешь и что тебе нужно, а потом:
    • либо внедряй что-то готовое типа SharePoint
    • либо разрабатывай что-то на заказ
Ну и первоначальный план передачи (зафиксирую, вдруг понадобится что-то потом):


План передачи + тайминг:
  1. Процесс информационных потоков в проектировании - просто “замоделить” недостаточно.(завязка) - 10 мин.
  2. Стандарты(СТП), гайдлайны в САПР - эффективная коммуникация в рамках проектных файлов, качество “продукта” - например, качество модели для станка; просто культура проектирования в “цифре” - 15 мин.
  3. Стандарты, нормативная документация трудно внедрять и выполнять - что делать? длинные, занудные мануалы или “фрагментарное” получение необходимой информации(типа wiki)?   - 15 мин.
  4. Тренды в корпоративном информационном менеджменте: вики-порталы, блоги, твиты, webos-сервисы как дружественные для пользователя источники информации и каналы сообщения. - 10 мин.
  5. Множество типов файлов - как решить возрастающее разнообразие форматов внутри процесса проектирования? Как легко и быстро осуществлять поиск по файлам? традиционные PDM-системы или удобные в использовании сервисы (e.g. Inforbix - метаданные и семантика как решение проблемы разнообразия форматов) - 15 мин.
  6. Большие корпорации и маленькие бюро: изначальное различие подходов в развертывании системы управления информацией. Развертывание информационной системы внутри компании - точка зрения специалиста; проблематика, подходы - 10 мин.
  7. Корпоративный интранет: интерфейс имеет минимум возможностей, действия пользователя ограничены, делай то, что должен и никакой ленты новостей - жесткие принципы управления; другой пример - http://prosapr.blogspot.com/2011/06/social-media-hok-hok-life.html ;информационное пр-во проектирования как культурная среда. - 15 мин.
  8. Сервисы Гугл - первый шаг в применении PDM, PLM, ERP? С чего начать, если хочешь организовать процесс управления информацией своими силами.         - 15 мин.
  9. etc Заключение


Социальные медиа, проблемы культивирования этих сред мы не затронули. Ну сам копать продолжу...
В общем, как-то так

5 комментариев:

  1. Корпоративный интранет: интерфейс имеет минимум возможностей, действия пользователя ограничены, делай то, что должен и никакой ленты новостей - жесткие принципы управления;

    а как без игры в quakelive?

    ОтветитьУдалить
  2. Только с нетбука в туалете. и фраги будешь набирать засчет лагов - никто попасть не сможет

    ОтветитьУдалить
  3. AutoQuake пусть будет - выкосил план за минуту - медаль Excellent или Impressive.

    ОтветитьУдалить
  4. Корпоративный интранет: интерфейс имеет минимум возможностей, действия пользователя ограничены, делай то, что должен и никакой ленты новостей - жесткие принципы управления;

    а как без игры в quakelive?

    ОтветитьУдалить
  5. Только с нетбука в туалете. и фраги будешь набирать засчет лагов - никто попасть не сможет

    ОтветитьУдалить