Pre: XForms с которого все началось
В общем это начало прошлого поста XForms с которого все началось. И, что самое забавное, я уже точно не помню с чего все началось... Встал вчера в 22:30 и как раз успел на "Рим" по 1+1. Получил почту с просьбой нарисовать в BPMN "процесс планирования расписаний учебных встреч в ВУЗе" с набросками процесса, и около часа начал пытаться рисовать и естественно углубился ... Хотя по плану я должен был писать ТЗ, на BPMN отвлекся с удовольствием, хоть так ничего и не получилось из-за описания. Затем я начал создавать в OpenOffice шаблон SRS на основе IEEE-830, но списывал у Вигерса
... И все это время в голове крутится идея проекта быстрого создания UI на основе объектов БД, что уже два раза начинался на Delphi и теперь появилось желания сделать на Java, с учетом прошлого опыта, в концепции интеграции с BPMS, BRMS и конечно же BIRT. По интеграции с BIRT есть книжка на английском - Integrating and Extending BIRT, по остальным же нету ничего, но это пока не так важно. Но основная задача это UI, и если стандартный UI сделать можно и он уже делался, то с кастомизацией его были проблемы и в Delphi проектах (в SWT Snippets есть примеры таскания мышкой кнопки по форме).
... Тут я уперся в мелкую проблему с нумерацией разделов в OpenOffice.org Writer и полез в мануал. Ничего по моей проблеме не увидел (все-таки сказывается ночной график), но увидел, что он работает с XForms. И почему бы не попробовать его для построения UI - пусть себе какие-либо продвинуты пользователи рисуют себе формы в других редакторах. По XForms помню, что и интерфейс Intalio|Workflow построен на XForms. В общем так я и полез в Google. Как все это продолжается можно судить по датам последних постов.
И тут попался Nuxeo - http://www.javalobby.org/java/forums/t63868.html
Nuxeo , a french open source ISV specialised in Enterprise Content Management, has just published the code for an XForms engine for SWT and Eclipse .
Я сразу отметил "SWT", подробнее я смотрю только сейчас и по дороге пишу этот пост. Apogee Project проходит сейчас процесс рассмотрения включения в Eclipse Foundation. Смотрим подробнее что он может:
Documentation
- Apogée XForms Engine: Viewers
- Apogée XForms Engine: developer guide
В общем понравился он мне - если посмотреть приведенные выше документы, то все довольно просто. А если еще заглянуть в SVN то можно увидеть плагин к OO (Для редактирования?) Скачал ... еще бы время на наего найти. Проект оформлен хорошо - и документация присутствует и модели Together Designer (наверное его уже не найдешь - был такой бесплатный тугезе года три назад, ну и UML 1.4 кажется там)
ЗЫ. А вот кстати и информация о том, что Intalio использует для Front-End именно Orbeon, о котом есть в начале-продолжении. Также возьму на заметку и посмотрю что там с UI для десктопа... нету UI для десктопа но демонстрации тоже поражают - посмотрите сами - особенно первую. Правда на PHP было быстрее 
OASIS UBL
Итак кажется я нашел самый что ни на есть интересный документ для изучения XML Shema. И это OASIS Universal Business Language. Документ вообще интересный, т.к. рассматривает такие вопросы как бизнес-процессы, каталоги, заказы, счета, платежи, перевозки. Приводятся Use Case диаграммы и диаграммы процессов на UML... Стандарты XSD и примеры XML документов.
Да что распинаться, если интересно смотрите сами! Тут думаю мои вопросы с ключами уйдут после изучения. Да и вообще интересный документ для любой разработки бизнес ПО.
Описание релиза UBL 1.0
UBL определяет общую XML-библиотеку бизнес-документов, таких как заказы на поставку и счета-фактуры, а также компоненты данных многократного использования, с помощью которых можно создавать различные бизнес-документы. UBL является первой стандартной реализацией технической спецификации "ebXML Core Components" ("Базовые компоненты языка ebXML").
.. библиотека опирается на концептуальную модель информационных компонентов, известную как информационные сущности бизнеса (Business Information Entities, сокр. BIEs). Эти базовые элементы собираются в модели конкретных документов, как, например, Заказ на поставку (Order) и Счет-фактур (Invoice). Затем эти собранные модели документов трансформируются в соответствии с правилами наименования и проектирования UBL (UBL Naming and Design Rules) в синтаксические структуры XML-схемы W3C. Благодаря этому можно создавать типы документов, основанные на UBL, отличные от определенных в спецификации языка UBL 1.0. Таким образом, можно говорить о модульности, практичности и расширяемости схем UBL.
Комплект документов UBL 1.0 содержит 244 файла, которые объединены в zip-архив, и содержит документацию, нормативные XML-схемы, UML-диаграммы, примеры электронных документов и другие документы:
XML-схемы для восьми основных бизнес-документов: Заказ (Order), Ответ на заказ (Order Response), Простой ответ на заказ (Order Response Simple), Изменение заказа (Order Change), Аннулирование заказа (Order Cancellation), Извещение об отправке (Despatch Advice), Извещение о получении (Receipt Advice) и Счет-фактура (Invoice);
описание общего процесса закупки по схеме заказ-счет, для которого разработаны типы документов UBL;
библиотека, состоящая из более чем 400 элементов данных XML (с определениями, основанными на технической спецификации "Core Components"), с помощью которых строятся схемы документов UBL;
" описание методологии разработки UBL 1.0;
UML-диаграммы всей модели данных UBL и модулей составляющих ее компонентов: Модуль адреса (Address Package), Модуль контракта (Contract Package), Модуль доставки (Delivery Package), Модуль указания документа (Document Reference Package), Модуль опасного изделия (Hazardous Item Package), Модуль изделия (Item Package), Модуль партии (Party Package), Модуль платежа (Payment Package), Модуль закупки (Procurement Package), Модуль налога (Tax Package);
диаграммы компоновки документов, демонстрирующие отношения между каждым типом документа UBL и его составляющими компонентами;
электронные таблицы Excel и OpenOffice, показывающие модель данных каждого документа UBL и библиотеку компонентов UBL.
ЗЫ
Утопия - бизнес-приложение мирового уровня и опыта за 10 минут. Все бизнес-процессы, документы, возможность интеграции через веб-сервисы, работа через веб и толстый клиент. XSD готовы из XForms и схему БД ... или XML СУБД
И немного ссылок
UBL: Another Opportunity for FOSS in the Enterprise
UBL: Ready for Prime Time
Free UBL на sourceforge
www.freebxml.org
freebxmlbp
______________
Автосалоны и компании, производящие срочный выкуп автомобилей в Липецке можно найти по адресу А48.RU.
XML OLTP Утопия
Сказка ложь, да в ней намек
Добрым молодцам урок
Продолжая тему Карра работаю над утопией быстрого построения OLTP приложений. ИТ становится дешевым товаром и XML здесь играет свою роль.
Брукс кончено был прав, что в ближайшие Икс лет (не помню цифр, кажется книга была в 75, прогнозировалось 15 лет и в 95 его же статься подтверждающая прогнозы) не произойдет взрыва производительности труда программистов. Однако в дополнение к разнообразным компонентам и библиотекам появляются целые стандартизированные области и законченные структуры данных, готовые к употреблению из коробки. К таким вещам можно отнести UBL - бесплатную библиотеку стандартных электронных XML бизнес-документов. Напомним немного что это такое ссылкой.
Если сегодня строить бизнес-систему, то почему бы не взять за основу UBL? Что нам это даст? Сначала конечно стандартные XSD схемы бизнес-документов. Вторым важным готовым элементом будут XForms произведенные на основе UBL схем (free-ubl-kit).
Постоянное хранение - Xml СУБД. Исключительно в качестве эксперимента хочу пробовать в ближайшее время Sedna и Xml-Xindice. Отображение XFroms Apogee / Orbeon. Apogee немного потрогал - довольно просто получается. Пугает пока только, что вестей по проекту нету. Из основного осталось построить списки, но думаю, что это самая простая из проблем.
Процессы и Бизнес-правила пока под вопросом, т.к. UBL определяет свои схемы процессов, с которыми пока не ознакомился, но связи с BPEL какие-то существуют и думаю со временем будут укрепляться (сладкое слово стандарты).
И конечно же бизнес-приложению нужны отчеты на основе Xml, и они тоже есть - это BIRT (JDBC, XML, Web Services, and Flat File support, as well as support for using code to get at other sources of data).
Довольно перспективная идея автоматической генерации мощных приложений, т.к. все технологии для этого как бы уже есть. XSD, XForms, XMLDB вообще не вызывают проблем (разве что с производительностью). Сомневающимся предлагаю посмотреть простой кусок кода по отображению XForms из SWT и небольшую статейку по использованию Xindice.
Вот почему таких приложений пока нету, хотя все технологии готовы? Никому не нада? Никто не верит? Ни у кого нету комплекса необходимых знаний? Как по Карру, так такое бы рынок ИТ в плане бизнес-приложений то и пообрушило ... Ищу спонсоров
----------
Фитнесс и бодибилдинг сделают ваше тело стройным, избавят от болезней и помогут освободиться от излишков веса.
Оставляя Delphi
Сидя на красивом холме
видишь ли ты то что видно мне
в игре наверняка что-то не так
(С) Б.Г.
Смотрю со стороны за своей блого-деятельностью и вижу как она постепенно превращается из развлечения в какую-то обязанность. Просто чувствую, что нужно высказаться по определенному вопросу ...
Появилось несколько интересных новостей, звезды выстроились в необходимом порядке и вот случился этот пост. Давно не заходил на delphiplus.org (когда-то посещал его постоянно) но вот недавно зашел и увидел две интересные новости - (1) появился наконец официальный dbExpress драйвер под Firebrid (2) Peter Morris бросает свои открытые Delphi-проекты и переходит на C#. И вот закончилось оценкой Eclipse Foundation совместно с IDC Обзор итогов работы сообщества Eclipse.
Еще менее года назад я был просто программист Delphi. Вокруг бушевали страсти по .Net и Java, Borland становился CodeGear и давно подсел на .Net, многие знакомые свернули Delphi проекты и пересели на C#. И глядя на статистику предложений о работе казалось вполне естественным экономическим шагом тихонько перейти на C# ... Немного поразмышляв об этом я понял простую истину - деньги там где Enterprise. На Delphi его никто его не делает и значит денег здесь гораздо меньше. Кстати забегая на перед скажу что никто из оставивших Delphi и ушедших в C# не жалел, а наоборот, восхищался даже просто возможностями среды.
Сегодня кстати наступила некоторая Delphi усталось что-ли ... В СНГ было сделано много внутренних проектов, программисты потихоньку мигрировали в Java и С#, и сегодня найти адекватных Delphi программистов становится проблемой. Вспоминается Cobol и С++ пару лет назад. Это хорошо для delphi разработчиков - наконец они могут немного покачать права и добиться большего вознаграждения. В Киеве уже например вполне реально получит зарплату в 1200 у.е. или может даже больше.
Но речь не о С#. Что самое неприятное, оставаясь на Delphi вы просто игнорируете огромные возможности производительности просто за счет использования готовых и часто открытых решений, которые не успевает или не хочет внедрять CodeGear. Размер сообщества среды и технологий разработки дает о себе знать, как никогда раньше. А в Delphi с этим Застой.
На самом деле до момента денег я не рассматривал всерьез перехода на новую платформу разработки. В конце концов появился Turbo Explorer и можно было наконец заниматься разработкой бесплатно.
Подсел на Borland я еще в школе - во времена TurboPascal 5.5 и Turbo C 2.0. В институте в 1992 компьютеров было мало и доступ был сильно ограничен. Да и после школьных IBM PS2/30 на Искре даже неприятно было на кнопки нажимать ... Я забросил программирование на несколько лет и вернулся уже где-то в 97-98 уже немного на Delphi 4.0 и потом как-то сразу на 5.0. Тогда я конечно был поражен и засел за изучение VCL... В общем дальнейшие почти 10 лет были плотно связаны с Delphi, но прозрение все-таки наступило, пусть и не так скоро как хотелось бы.
Манил веб и кросс-платформенность и перед отпуском я скачал Eclipse 3.2 SDK. Никаких быстрых движений я тогда особо не планировал, но потихоньку пробовал делать тоже самое что и на Delphi. Начал я с изучения справки по Eclipse JDT - читаю справку и повторяю в среде то что там написано. Кстати есть русский перевод 2005 года может кого заинтересует. И чесно сказать был поражен возможностями и удобством среды по работе с исходным кодом. Именно этот тот предпоследний день отпуска, потраченный на изучение Eclipse JDT, наверное и есть та точка в пространстве и времени, которая отвратила меня от Delphi. Потом уже были RCP, менеджер обновлений, огромное количество подключаемых модулей ... потом - для первого же увлечения хватило возможностей редактора кода! После этого, особо не обращая внимания на Eclipse, я поработал с Delphi еще пару месяцев и затем уволился... немного поработал с J2EE и JSF, сделал пару мелочей на C# Developer и стал аналитиком.
Сегодня я мало программирую, но технологиями немного интересуюсь. Как видно из моих последних постов мне интересны XML технологии - BPM, XSD, XForms, XML DB - и мне кажется это естественным. Даже если бы я и захотел делать свои изыскания на Delphi то просто не нашел бы поддержки этих технологий в самом продукте. Это даже без обид Petera Morisa ...
Однако хочу также заметить что Together остается передовым средством моделирования, JGear тоже выглядит довольно приятно. Т.е. не стоит сбрасывать Borland и CodeGear со счетов вообще, но целиком они уже не поспевают. Ну и конечно OpenSource ... в мире караоке-капитализма капиталист должен что-то давать обществу и IBM, Sun, много кого еще дают, а Borland как-то не очень.
Service Data Objects (SDO) 2.0
Даже странно подумать, что раньше
Каждый шел как хотел, а теперь
Паровоз, как мессия, несет нас вперед
По пути из Калинина в Тверь.
(С) Аквариум
Последнее время много времени провожу в поисковой строке гугла. Дай людям поиск и что они будут делать? Конечно же искать!
Последними XML постами я пытался показать одну мысль - современные корпоративные приложения обмениваются данными, и в 99% случаев это XML - стандарт де-факто для взаимодействия приложений через web. Сказать только одно слово "XML" будет слишком большим упрощением здесь нужно добавить немного страшных слов типа XSD, WSDL, XSL, XFoms, XPath и XQuery. И это далеко не полный список... а еще недавно хватало простого SQL и он пока не отменяется. XML сегодня определяет не только данные, но и метаданные, а также стандартные способы манипуляции этими данными и метаданными.
В общем натолкнулся на статью - Service Data Objects (SDO) 2.0: Создание и чтение документа XML на основе схемы XML. Понравился мне там примерчик - как легко в стиле RowSet можно работать с XML экземплярами не отвлекаясь на DOM/SAX.
Интерфейсы SDO 2.0 предоставляют единообразный способ создания данных и доступа к ним, а также избавляют разработчиков от необходимости подробной разработки процедур парсинга и поддержки целостности данных. На сегодняшний день SDO 2.0 является инкубаторным субпроектом (под названием Tuscany) организации Apache Software Foundation, цель которого - стать де-факто стандартным интерфейсом программирования моделей данных для разработки SOA.
.. интерфейсы SDO 2.0 полностью избавляют вас от необходимости знания и использования API парсера XML для чтения, записи и управления данными. Если вы создаете на Java DataObject, представляющий данные XML в соответствии с определенной вами схемой XML, SDO 2.0 обеспечивает вам удобство и гибкость, позволяя сконцентрироваться непосредственно на работе с данными. В результате этот API предоставляет значительные преимущества, заключающиеся в повышении производительности разработки и качества продукта.
Затем сходил на сайт продукта Apache Tuscany и это не только прозрачная работа с XML - файлами а еще с Data Access Services (DAS) и Service Component Architecture (SCA)... В общем всем кто работает с XML на Java рекомендую посмотреть. Хочу обратить внимание на простоту работы - оказывается для всей работы хватает всего трех элементов
---
Холодильные шкафы, камеры морозильные и льдогенераторы для магазина или склада продуктов вы всегда можете купить у компании «Холод-Торг»
Улетное секс видео со страстными латинками, сисястыми азиатками и крикливыми ниггершами ждет тебя на эротическом портале ebemsa.com. Просмотр всех роликов бесплатен, здесь нет никаких платных аккаунтов и доступа через СМС!
Принципы независимости бизнес-правил
Вчера попал на Манифест бизнес-правил - решил что это довольно важный документ для понимания темы BRMS и попытался перевести. Замечания и предложения по переводу приветствуются.
The Business Rules Manifesto
Статья 1. Первичные требования, а не вторичные
1.1. Правила это элита граждан мира требований.
1.2. Правила неотъемлемая, а не дискретная часть, бизнес-моделей и технологических моделей.
Статья 2. Отдельны от процессов и не заключены в них
2.1. Правила - четкие ограничения на поведение и/или оказывают поддержку поведения.
2.2. Правила не являются процессом или процедурой. Они не должны включаться в эти понятия.
2.3. Правила применяются вокруг процессов и процедур. Должен быть один последовательный свод правил, исполняющийся последовательно во всех соответствующих областях бизнес-деятельности.
Статья 3. Хорошо продуманные знания, а не побочный продукт
3.1. Правила опираются на факты, а факты опираются на понятия выраженные в условиях.
3.2. Условия выражают бизнес-концепции; факты утверждают эти концепции, правила ограничивают и поддерживают эти факты.
3.3. Правила должны быть ясными. Правило не всегда предполагает какую-либо концепцию или факта.
3.4. Правила являются базовыми для понимания бизнесом самого себя - то есть, основным бизнес-знанием.
3.5. Правила должны быть развитыми, защищенными и управляемыми.
Статья 4. Декларативные, не процедурные
4.1. Правила должны выражаться в описательных предложениях на естественном языке деловой аудитории.
4.2. Если что-либо не может быть выражено, то это не правило.
4.3. А набор высказываний декларативный, только если набор не поразумевает последовательность.
4.4. Любые утверждения о том, что правила требуют других конструкций, помимо терминов и фактов, означают предположения о внедрении системы.
4.5. А правило не зависит от каких-либо воздействий, определенных для него. Правило и его воздействие - отдельные проблемы.
4.6. Правила должны определяться независимо от ответственности за то "кто", "где", "когда" и "как" их выполняет.
4.7. Исключения из правил выражаются другими правилами.
Статья 5. Правильно-сформированные выражение, не специальные
5.1. Бизнес-правила должны выражаться таким образом, чтобы они могли быть проверены на корректность деловыми людьми.
5.2. Бизнес-правила должны выражаться таким образом, чтобы они могли быть проверены в отношении логичность друг к другу.
5.3. Формальная логика, например, логика предикатов, имеет основополагающее значение для правильно-сформированных выражений правил в терминах бизнеса, также как и технологий, обеспечивающих реализацию бизнес-правил.
Статья 6. Архитектура основанная на правилах, не косвенная реализация
6.1. Приложения бизнес-правил намеренно построена с учетом непрерывных изменений в бизнес правилах. Платформа, на которой запускается приложение должна поддерживать такие непрерывные изменения.
6.2. Непосредственно выполнение правил - например, в машинах в правил - лучше реализации стратегии переписывания правил в различные процедурные формы.
6.3. Система бизнес-правил должна всегда быть в состоянии объяснить рассуждения, с помощью которого она приходит к заключения или принимает решения.
6.4. Правила основаны на значениях истинности. Определение или поддержка значение истинности скрыто от пользователей.
6.5. Отношения между событиями и правилами, обычно, как многие-ко многим.
Статья 7. Процессы ведомые правилами, а не программирование основанное на исключениях
7.1. Правила определяют границу между приемлемой и неприемлемой деловой деятельностью.
7.2. Правила часто требуют особой или выборочной обработки обнаруженных нарушений. Такие правила нарушения деятельности есть деятельность, такая же как и любая другая.
7.3. Для обеспечения максимальной согласованности и повторного использования, обработки неприемлемой деловой деятельности должна быть неотделима от обработки с приемлемой деловой деятельности.
Статья 8. Во имя бизнеса, а не технологии
8.1. Правила касаются бизнес практики и руководства; поэтому, правила диктуются бизнес-целями и задачами, и формируется под влиянием различных воздействий.
8.2. Правила всегда стоят что-то бизнесу.
8.3. Стоимость исполнения правила должна быть сбалансирована с бизнес-рисками, и в отношении упущенных коммерческих возможностей.
8.4. Обычно меньшее количество "хороших правил" лучше чем "больше правил" вообще.
8.5. Эффективная система может основываться на небольшом количестве правил. В дополнение, большеинство специфический правил можно добавить потом, так что со временем система будет становиться умнее.
Статья 9. От бизенса, к бизнесу, и для людей бизнеса, не для людей ИТ
9.1. Правила должны возникать от знающих людей бизнеса.
9.2. Люди бизнеса должны иметь инструменты, помогающие им формулировать, утверждать и управлять правилами.
9.3. Люди бизнеса должны иметь инструменты, помогающие им проверять логичность бизнес-правил по отношению друг-к-другу.
Статья 10. Управление бизнес-логикой, а не аппаратно-программной платформой
10.1. Бизнес-правила являются жизненно важных бизнес-активом.
10.2. В долгосрочной перспективе, правила являются более важными для бизнеса, чем аппаратно-программные платформы.
10.3. Бизнес-правила должны быть организованы и храниться таким образом, чтобы их можно было легко перевести на новые аппаратно-программные платформы.
10.4. Правила, а также возможность эффективного изменения, имеют основополагающее значение для улучшения адаптивности бизнеса.
Version 2.0, November 1, 2003. Edited by Ronald G. Ross.
Copyright, 2006. Business Rules Group.
Simple Brillants
Фергюс О'Коннел "Simple Brilliant. Все гениальное просто".
До того как мне предложили эту вещь был знаком с его "Управление проектами Серебрянная пуля" и взял "за глаза" не смотря на цену и объем. Простотой подкупила первая книга. Вот кстати отличная обзорная статья
1. Многие вещи просты и первый принцип гласит: нужно избегать сложности
и стремится к простоте. Ищите самые простые решения. Для уже имеющихся решений ищете способы их еще упростить.
2. Важно иметь представление о том, что вы собираетесь сделать
"Если вы не знаете в какой порт плывет ваш корабль - любой ветер будет для вас попутным."
поймите, что вы пытаетесь сделать (цели);
узнайте, хотят ли все того же самого (максимизация благоприятных условий для всех участников);
следите за изменениями того, что вы пытесь сделать (если цели изменились пройдите еще раз пункт максимизации благоприятных условий).
3. Всегда существует последовательность событий.
Когда вы пытаетесь что-либо сделать обязательно существует последовательность событий. Знание этого факта приводит к планированию, расстановке приоритетов, поиску оптимальных путей.
мысленно пройдите весь путь от начала до конца (план проекта);
пройдите путь, акцентируя внимание на мельчайших деталях (детализация);
используйте свои знания и предположения;
пересчитайте кирпичики в стене (повторяющиеся действия);
всегда существует другое решение (альтернативный план);
записывайте то, что происходит на самом деле (история и чужой опыт);
старайтесь найти взаимосвязь вещей.
4. Задания не выполняются, если люди их не выполняют
Здания не будут выполнены, если не будут их выполнять. Если большое количество задач
останется невыполненным, то все пойдет на перекосяк. Есть масса причин ко которым это
может происходить:
неразбериха - люди не знали что они должны были что-то сделать, или не знали что именно им следовало сделать;
черезмерная загруженность - задачи есть, но нет времени на их выполнение;
некомпетентность - нет опыта, навыков или необходимого уровня знаний для решения конкретной задачи.
Лечить назначением конкретного исполнителя для каждой задачи. Обеспечение высокого профессионального уровня коллектива.
Карточки танцев - полный учет времени по задачам
проекты\всего\интервал1\интервал2
---------------------------------
проект1 20 10 10
проект2 25 10 15
... .. .. ..
---------------------------------
итого: 45 20 25
Таблицы с планками - кто чем занимается
---------------------------------
дата / состав исполнителей (задача)
исполнитель1 / исполнитель2 / ...
---------------------------------
1 задача1 задача2
2 задача2 -
оптимизация времени
- сокращение времени на типичные задачи, например почту, телефон, совещания ..
- не выполнять вообще некоторые задачи
Последствия давления по Deadline Де Марко
Скорость мышления людей, когда на них оказывают давление, не становится быстрее.
Увеличение сверхурочной работы - тактика, ведущая к снижению производительности труда.
Сверхурочное время может оказаться полезной тактикой (концентрация усилий, осознание важности), но оказывать давление длительное время это ошибка.
Пожалуй, руководители слишком часто прибегают к оказанию давления, потому что не знают, что еще можно сделать, или же их пугают трудности альтернативных подходов.
Ужасное подозрение: что если настоящая причина оказания давления и принуждения сотрудников работать сверхурочно, не что иное как способо выставить себя в лучшем свете, когда проект пойдет под откос?
Учет времени на помехи и внесение их в план\карточку танцев
5. Редко все получается так, как ожидалось.
В жизни всегда есть место для непредвиденных обстоятельств. Нужно свести к минимуму их количество и возможные последствия. "Если вы не будете вести активное наступление на риски, то риски будут сами активно атаковать вас" Том Джилб
Всегда обещайте меньше чем выполняете.
Добавьте резерв в проект.
Управляйте рисками.
6. Вещи либо есть, либо их нет
Вещи либо есть, либо их нет. Также и работа - либо сделана, либо нет. Задания нужно дробить на элементарные составляющие, так чтобы можно было точно сказать выполнена задача или нет.
7. Взгляните на проблему с точки зрения других людей
Практически в любом из наших заданий и проектов неизбежно участвуют другие люди.
Умение рассматривать любые вопросы с точки зрения других людей может помочь нам
правильно понять и выполнить любое задание.
Если люди относятся к заданию положительно и у них высокая мотивация, они могут
буквально свернуть горы.
Станьте на место других людей. Полезная привычка - умение мыслить так, чтобы в выигрыше оставались все вовлеченные в это дело стороны. Увеличивайте до максимума благоприятные условия для всех участников совместного дела. Убедитесь, что все хотят именно того, чего хотите добиться вы.
Mobile-ON - все про сотовые телефоны, и для них: темы, игры, картинки. Узнай все про мобильные телефоны ведущих брендов: Нокиа, Сони Эриксон
Для московской компании «Latini» лучшие кухни на заказ поставляются со знаменитых итальянских фабрик. Специалисты «Latini» помогут вам не только выбрать подходящую кухню, но и выполнить дизайн проект квартиры.
Для того чтобы стать начальником нужно вести себя так как ведет начальник. И завести два пиджака, один из которых будет на вас, а другой на спинке вашего стула создавать постоянную видимость присутствия. (Стул в моем пиджаке скажет: "Вышел. Весь вышел, не знаю когда и прийдет").
Во какие мысли лезут в голову простому украинскому безработному в это не по-зимнему сырое январское утро. По радио Чай-Ф "у судьбы как у трамвая жизнь кольцо .. быть первым как и тот что тащится за ним, впереди только рельсы и провода". Вспоминается летний утренний вид 1993 года на салтовку из 802 расширителя. Привет, Длинный!. Утро перед практикой после первого курса, или утро после посиделок до утра с Вовой, Бортником и Ткаченко - "ростер" и бутерброды с тушенкой
"Молодые львы .. они свободны от наших потерь, и им нечего делать с собой сейчас - они войдут когда Екатерина откроет им дверь."
"Я пишу эти песни в конце декабря, голый в снегу при свете полной луны... но если ты меня слышишь наверное это не зря" - какой контраст однако. И Рыжая на балконе квартиры Длинного в Мелитополе с грустно смешной фразой: "Где мои шестнадцать лет" ...
Вот же будит воспоминания музыка. Ловлю себя на том, что в последнее время музыку почти не слушаю, хотя старательно собираю все на компьютере. А тут включил JAM FM и протащился. Ночью репертуар гораздо ближе.
Вальсируя с медведями - Проекты на выживание
"В этих случаях непоколебимая жертвенность непреложно требуется от всех до одного участников проекта. Проект требует забросить личную жизнь, бесконечно работать сверхурочно, проводя субботы и воскресенья в офисе, отделиться от семьи и т.д. Неприемлемо ничто меньшее , чем полное посвящение себя проекту.
Оправдание этих жертв всегда апеллирует к важности проекта: это так важно и необходим, что требует предела возможного от персонала проекта. Но есть нечно загадочное в этом утверждении. Если этот проект так важен, почему компания не может потратить время и деньги, необходимые для его нормального осуществления?
По нашему опыту, единственной общей характеристикой таких проектов является низкая ожидаемая выгода. Это проекты, на выпуск продуктов монументальной незначительности. Единственным реальным обоснованием проектов на выживание является то, что выгода столь мала, что нормальное выполнение проекта явно привело бы к затратам, которые будут больше выгоды. Только героическими усилиями можно надеятся заставить свинью летать.
Второй характеристикой проекта на выживание является одурачивание людей, чтобы заставить их принести свою личную жизнь в жертву компании, убедив, что только это может привести к успеху, поскольку выгода столь крохотная, что осмысленным будут только самые низкие затраты.
Третья характеристика такого проекта состоит в том, что они почти всегда кончаются полным фиаско, не создав ничего или почти ничего (обычно при затратах выше среднего) и заставив всех чувствовать себя одураченными и озлобленными. Должен быть выход лучше."
ЗЫ. Книжка довольно интересная. Обязательно вернусь и опишу подробнее как появится время. Интересна прежде всего тем, что она не только о рисках, а как всегда при разработки ПО случается, касается еще кучки маленьких бездн. Тут много теории вероятности применимой как к рискам так и к ожидаемой окупаемости и еще много интересных наблюдений и статистики.
Теория W
Открытые системы #05/2003
Человеческий фактор в управлении ИТ-проектом
Теория W
В 1989 году Барри Боэм и Рони Росс описали парадигму управления программным проектом, получившую название Теории W («Theory-W Software Project Management: Principles and Examples», IEEE Trans. Software Eng., July 1989). Для каждого проекта, согласно Теории W, следует создавать взаимовыгодные условия, формировать такой же процесс и производить взаимовыгодный продукт.
Взаимовыгодные условия. Те, кто создает взаимовыгодные условия, понимают, что самые лучшие рабочие взаимоотношения — это те, выигрыш от которых может получить каждый. Ничья, проигрыш одних и выигрыш других могут озлобить одну или обе стороны, поэтому лучше пытаться создавать взаимовыгодные ситуации. Сделать можно это следующим образом.
Понять, что каждый хочет выиграть. Выяснить, какая для каждого отдельного человека ситуация будет выигрышной. Для большинства людей выигрыш означает деньги, власть и признание, но есть и другие, менее очевидные условия, такие как удовольствие от своей работы, чувство причастности и моральное удовлетворение.
Формировать разумные надежды. Необходимо создавать разумные и взаимно осуществимые ожидания в каждом аспекте человеческих отношений. Гарантировать, что постановка задач для каждого конкретного человека будет способствовать формированию выигрышной для него ситуации.
Способствовать общению. Создать атмосферу, поддерживающую выигрышные для сотрудников условия. Такая атмосфера может проявляться в разных формах, таких как материальные стимулы, групповая деятельность и общие беседы, позволяющие устранить проблемы.
Взаимовыгодный процесс. Создание такого процесса означает внедрение системы, которая приведет к успеху. Сюда относится реалистичное планирование процесса на основе определенной стандартной методологии, будь то внутренняя, общекорпоративная или готовая.
Крайне важно руководить ИТ-проектом, опираясь на план. Недаром говорят, что «план — ничто, а планирование — все». «Слишком часто менеджеры разрабатывают план для того, чтобы проект одобрило руководство или заказчик, а затем, после того, как проект утвержден, забывают о плане. Наоборот, они должны использовать и поддерживать план на всем протяжении срока существования проекта.
Как менеджеру проекта вам необходимо помнить о рисках, которые могут привести к общему проигрышу. Убедитесь, что вы представляете себе эти риски и приняли необходимые меры для того, чтобы избавиться от них как можно скорее. К примеру, решая поручить задание одному сотруднику, а не другому, вы создаете ситуацию, в которой один оказывается в выигрыше, а другой — в проигрыше. В этом случае следует поговорить с человеком, которому было отказано, для того, чтобы объяснить ему причины принятия такого решения и подтвердить его состоятельность. Точно также человек, который получил задание, должен понять причины этого, причем его следует предупредить, что не следует вести себя так, чтобы его «победа» вызвала чью-то обиду. Ему необходимо объяснить значимость другого сотрудника и необходимость привлекать его к выполнению полученного задания там, где это возможно.
Не менее важно не забывать о людях. Это улучшает взаимоотношения и позволяет добиваться того, чтобы все сотрудники принимали участие в работе группы. Прислушайтесь к советам других членов группы; скорее всего, у них есть великолепные идеи.
Взаимовыгодный продукт. Создание взаимовыгодных программных продуктов связано с процессом подготовки спецификации. Главное здесь — согласование выигрышных условий для пользователей и специалистов, поддерживающих программное обеспечение. Этот процесс предполагает тщательно выверенное формулирование возлагаемых на продукт надежд.
Теория W может оказаться адекватной для ситуации с рестораном, поскольку она согласуется с описанной ранее успешной стратегией. Вдобавок, если организовать согласованную, приятную работу для поваров и сотрудников и столь же приятные условия отдыха для клиентов, причем все это с четко продуманной направленностью ресторана и его популяризацией, то успех вероятен, если не возможен.