Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Водолей

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »
91
Судя по написанному проблема у Вас не там, где Вы ее диагностируете.

Пушкина читайте, не зря же в конце концов он написал: И опыт, сын ошибок трудных... :о)))

Еще посоветую почитать, как Рональд Рейган в бытность его президентом США (а может и раньше - но про это я не в курсе) принимал решения.

92
Как насчет - "через 5 лет зарабатывать 10 тыс долларов в месяц"?

93
Цитата: Alla
Но  мне кажется, что  в работе психоаналитиками   происходит тоже  самое, что в работе  с системными  аналитиками.

Это Вы сильно заблуждаетесь :о)))

Я хоть и не психоаналитик, но подозреваю, что начинать с вопроса "какая у вас проблема?" - моветон. IMHO Вы ошибаетесь в том, кто должен решать Ваши задачи. Психоаналитик помогает определить проблему (это - да), но решает ее не он, а Вы (но с его помощью). Он-то как раз и помогает Вам разобраться в себе, в т.ч. используя преимущества взгляда со стороны. Это есличё про хорошего психоаналитика, ну а так-себе-психоаналитик действительно выдаст какой-нибудь стереотип и будет побуждать Вас ему следовать. Вот только найти хорошего придётся на основе собственного опыта.

Насчет своего опыта...
У меня по счастью никогда не было проблем с мотивацией. Даже если она менялась :о))) Были, конечно, разочарования, особенно, когда приходилось бросать (особенно попервости) вроде бы успешно сделанное дело/налаженную работу/ставшие привычными условия и т.п. А сейчас уже воспринимаю профессиональную часть жизни как нескончаемую череду ограниченных по времени проектов. И даже в чем-то горжусь этим! :о)))

Кстати, тут подходит известная поговорка: не можешь изменить ситуацию - измени отношение к ней.

Цитата: Alla
А  насчет того, что тема  очень   далека от форума....  Мне  кажется , что прежде  всего   мы все - люди, а потом  уже  системные  аналитики   или кто там  еще.   А  во-вторых,  одна  из главных проблем-  это  Думать, рассуждать, анализировать.  Иногда это очень сложно.  
А системные  аналитики  ведь тем  и занимаются же , что  думают, рассуждают, анализируют,  прогнозируют, моделируют,  разве нет?

Ответ короткий :о))) :
 - Да, тема очень далека от форума. Да, все мы - люди, человеки. Да, жить сложно. Нужно принимать решения и нести за них ответственность. И не все были обучены этому с детства.
 - Нет, системные (и, кстати, бизнес) аналитики НЕ ЗАНИМАЮТСЯ этим! Т.е. они думают, рассуждают, анализируют, прогнозируют, моделируют и т.п. НО! Они рассматривают ДРУГИЕ (!) системы - скажем так, человеко-машинные.
 - Да, конечно, они должны (желательно!) учитывать отношения людей, существующие/возникающие/изменяющиеся в рассматриваемой среде (но уверяю Вас, очень многие этого вообще не делают). К тому же эти отношения обычно рассматриваются через весьма специфическую призму производимых изменений, т.е. что-то в духе: "что должны будут делать эти люди, когда то, что они делали вчера, теперь делать не нужно" или наоборот "что должны будут делать эти люди, когда им придется делать то, что еще вчера они не делали"... И это в лучшем случае!

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

95
Цитата: andre
Класс!  ;D

обычное дело. особенно с пальцатыми заказчиками...

96
пункт 3 какой-то.... некузявый.
какое заказчику дело до того, какая задача поставлена вам?

ответьте сначала "зачем вам в принципе нyжно общаться с заказчиком?" и оттуда будет все вытекать...

97
Для всех / Re: Реинжиниринг ИС
« : 24 Июня 2011, 17:00:24 »
уточните. вы имеете в виду "реинжиниринг бизнес процессов" или "реверсинжиниринг ИС"?
стандартные приемы и методы есть и для того и для другого. попробуйте начать с яндекса или википедии

98
тут видите ли, какое дело.
С одной стороны, план управления проектом составляется только (!?) на тот проект, которым, собственно, собираются управлять.
С другой стороны, когда есть ряд отработанных методов управления (фактически, процедур по областям знаний) можно использовать их, и постепенно расширяя перечень этих процедур (фактически, стандартизируя процесс управления проектом(-ами) в целом), можно превратить план управления проектом в виртуальный документ со ссылками на эти процедуры.
Поэтому, вообще говоря, формально план управления проектом - необязателен. НО! Его наличие и качественная проработка говорит о зрелости управления проектами в целом и зрелости и опыте менеджера в частности. Так что стремиться к идеалу нужно, но, я бы так сказал ..... постепенно, если что-то можно упростить - упрощайте...

Проект не зря называется ВРЕМЕННОЕ предприятие, т.к. он выполняется ограниченное время до получения результатов и достижения целей проекта. Поэтому на старый договор и все что с ним связано можно вообще не обращать внимания. А новый договор считать единственным и соответствующим образом относиться к нему. Один скользкий момент связан с наследием старого проекта:
 - и с точки зрения функциональности, а это влияет и на объем работ, и на сроки, и на ожидания,
 - и с точки зрения отношения (память заказчиков, особенно на неудачи и сложности, очень, понимаете ли, долгоиграющая), а это ну оччччень влияет на коммуникации, даже если с вашей стороны все люди будут новыми.
 - и с точки зрения рисков - ну это понятно, должно быть.

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

операционные планы - считайте - готовые процедуры управления по областям знаний. Т.к. они связаны друг с другом (это можно посмотреть в PMBOK), то важна системность их использования.

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

Устав и план управления проектом по сути одно и то же, с одним существенным различием: устав обычно определяет рамки проекта (любые) и может являться просто напросто приложением к договору, а план управления проектом - это описание методов управления. Впрочем в PMBOK что-то подобное уже написано :о)))

И в заключение.
Формировать план проекта снизу - на основе процедур можно, но нужно обязательно видеть не только отдельные кирпичи, но и все здание в целом. Поэтому проще начать с плана, при необходимости добавляя имеющиеся процедуры. Главное постоянно задавать себе вопросы типа "а что мы будем делать, когда понадобится то-то и то-то"

как-то так....

99
Цитата: ES2011
Предположим, я захочу закрепить новые способы коммуникации (фиксирование требований в системе управления).

дык это разные области управления проектами: одно дело - управление коммуникациями, другое - управление содержанием проекта  

Цитата: ES2011
Буду конкретнее. Есть проект, который формально завершен (ПМИ сдано, акты подписаны).Потенциально есть договор на доработку.
Плана по управлению НЕТ.
Интересно, если его писать "с нуля":
* включать ли в него этапы, которые уж прошли. Читала, что есть такой раздел, как "Основные этапы проекта". Или писать в него прошедшие этапы уже бессмысленно?  Пишутся только этапы по новому договору?
* иногда план управления проектом включает в себя разделы "Общая информация" (где указывают менеджера) или Матрицу ответственности. В новом договоре появлюются новые роли, новое перераспределение обязанностей. Поэтому я и написала про изменение структуры команды.

Что-то наводит меня на мысль о каше в Вашей голове... извините, если что не так... :о)))
План управления проектом (Project Charter) пишется для того, чтобы знать как управлять НОВЫМ проектом.
С другой стороны, по разным причинам проекты бывают практически одинаковые... ну почти, например, внедрение одного и того же продукта в разных компаниях. Тогда можно было бы взять план первого проекта за основу и при необходимости внести изменения сообразно изменившейся ситуации во втором проекте. Вроде как на текущий момент Вы не сказали ничего, что противоречит этому подходу, но с другой стороны, Вы не сказали и того, что помешает воплотить этот подход в жизнь.
В общем случае, писать про то, как должен был выполняться или как выполнялся старый проект, который еще неизвестно когда был, кем и как выполнялся - даже если это было "вчера" - смысла никакого нет. Однако есть такой момент как lessons learnt (извлеченные уроки), которые могу повлиять на те же коммуникациии, риски и некоторые другие области управления проектом.
Новые роли - это следствие, в том числе связанное с новым содержанием проекта или персоналом, который СЕЙЧАС есть в наличии. Отсюда может меняться, разумеется, и структура команды.

НО! Это не говорит о необходимости изменения процедур (!) управления, т.е. того, как менеджер (он же руководитель) проекта будет управлять работами, командой, рисками.
Поэтому порекомендую еще раз подумать вот в каком направлении: отделите новое содержание проектной среды, от механизмов управления, которые могут быть в чем-то (или во всем) унаследованы из прошлого проекта, вдруг они вполне себе подходят. Это, кстати, путь к тому, что называется "корпоративный стандарт управления проектом".

Цитата: ES2011
Вопрос проще:
Заключение договора = новый проект = новый план по управлению проектом
ИЛИ договор по развитию продукта  НЕ РАВНО новый проект = модификация существующего плана
Просто я путаюсь - закрытие работ по договору есть ли закрытие проекта?

ИЛИ.

Во-первых, договор, проект и план - разные вещи. Договор - определяет объект договора, обязательства сторон, результаты, сроки, деньги и т.п. Субъектами договора в простом случае являются два юр.лица, представленные ген.директорами. Но бывают случаи и посложнее.
Главная его особенность он не говорит, как делать эту работу, хотя может содержать план-график работ любой детальности.
Проект - временное предприятие... бла-бла-бла... ну да Вы знаете. Обычно суть его в том, чтобы выполнить работы, обещанные по договору, т.е. обязательства исполнителя. При этом проект представляет собой способ выполнения работ и получения обещанных результатов.
Существует интересная особенность, что проект и договор могут находиться в любом ...э... "соотношении": может быть один договор и много проектов, но может быть и наоборот. В вашем случае скорее всего один договор и один проект во его исполнение, хотя это не значит, что не могут появиться другие договоры и подпроекты (или просто проекты). Причины, по которым они появляются и примеры приводить не буду, чтобы не забивать Вам голову.
А вот план - это ...э... описанный способ реализовать этот способ выполнения работ и получения результатов :о))) т.е. то как Вы будете управлять этими работами. Поэтому целесообразно иметь один план для управления всей совокупностью проектов и подпроектов, причем независимо от количества договоров :о)))  

Про закрытие.
В простом случае Вы выполняете все работы, получаете результаты, представляете их заказчику и в соответствии с соответствующим порядком (из договора) представляете их заказчику. С точки зрения проекта это уже можно считать закрытием (и, например, распустить часть команды или всю), а дальше менеджер будет иметь головную боль по закрытию договора (акты, сверки, платежи, протоколы, договоренности и много всякой ерунды) :о)))) НО! (куда ж без НО?) Это в простом случае. А в сложных все может быть гораздо интереснее (или наоборот) и сложнее.  
Поэтому целесообразно выделить фазы относящиеся к управлению проектом (в PMBOK они есть). Одни из них будут задействовать персонал (команду) проекта, другие нет. При этом менеджер на всем протяжении проекта (с оговорками) задействован всегда.

Цитата: ES2011
Если по логике, то план управлени ПРОЕКТОМ создается для проекта, а проект и продукт есть разные вещи.

Да

Цитата: ES2011
То есть, новый договор = новый проект = новый план

Нет (в общем случае) см. выше

Цитата: ES2011
Да, он на 80% может быть копией предыдущего, но опять же...включает новый план по управлению содержанием работ, новый план по управлению рисками, новый план по управлению изменениями.
А вот некоторые части могут и не меняться (План управления качеством и т.д.) и браться "шаблонно" из других планов.
Просто план управления проектом, как я понимаю, состоит из вспомогательных планов.
Но создается он при старте очередного договора, который определяет ресурсы и задачи.
Просто для меня проект всегда ограничивался сроками, ресурсами и, соответственно, план для него тоже.
Где я ошибаюсь?

ошибки выделены по тексту :о))) они, скорее всего, следуют из методической ошибки, считающей методом управления проектом - MS Project, потому что зачастую в нем ведется план-график, относящийся только к работам. В лучшем случае добавляются работы типа, "управление проектом" со 100% загрузкой менеджера, что по сути является неким нонсенсом, т.к. редко какой менеджер пишущий подобное может внятно объяснить, что это такое, максимум сослаться на PMBOK или НТК

Проект - это предприятие (см.определение). а Продукт - результат. см. выше.
В общем случае план управления проектом создается на проект (но в широком смысле - см. выше.), при этом план не ограничивается сроками, ресурсами и т.п. Это этап выполнения ограничивается этими факторами. А план может быть, грубо говоря, один на всю жизнь.
по поводу шаблонности напишу ниже.

Цитата: ES2011
Вопросы могу не понимать, потому что не менеджер проектов и имею весьма упрощенные знания в данной области.
Ограничены пролистыванием PMBOK

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

Надеюсь, теперь стало понятнее?
 

100
Вы, по-моему, не поняли вопроса. При чем тут ресурсное обеспечение?
еще раз: что изменилось в управлении проектом? имею в виду: именно в управлении, а не в команде.

101
ОК, про план-график "забыли", т.е. считаем, что с ним все в порядке
тогда следующий вопрос: что изменилось в управлении проектом в связи с вашей ситуацией?

102
сначала определите, что вы называете "планом управления проектом": план управления проектом или план-график проекта?

103
забудьте на время о классах, диаграммах. пока вы не будет понимать вашу систему на уровне предметной области, без какого бы то ни было UML, вы будете себя постоянно запутывать

нарисуйте на листочке бумаги максимально простую схему, где будут изображены ваши объекты в виде машинок, антеннок, коробочек, проводов, электромагнитных волн и чего угодно подобного... покажите на ней обычными стрелочками что куда идет, даже безотносительно протоколов, видов сообщений и т.п.
разберетесь и тогда вам будет значительно легче анализировать эту информацию и строить необходимые для задачи сущности...

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

105
Цитата: Lillu
Однако, мне непоятно как изобразить типы передаваемых данных: мультимедиа, телеметрия, голос и SMS? в качестве объектов класса данные? Или как отдельные классы?

Скорее это класс "Каналы передачи данных", у них свои свойства: среда передачи данных, протоколы, скорости и т.д. и т.п.
По сути Объекты (или устройства) соединяются друг с другом посредством определенных каналов: одни могут обмениваться только по каналам одного типа, другие по каким-то другим или комбинации первых и вторых и т.п.

Я бы предложил определить классы устройств, классы каналов, классы передаваемых данных (пакетов данных), плюс классы управляющих сигналов (или как они там называются), ну а потом отрисовать сначала обобщенную схему классов, где представлены родительские объекты этих классов, и постепенно спускаясь к конкретным классам конкретных взаимодействующих объектов, также отражая эти взаимодействия на соответствующей диаграмме.

P.S. вообще я бы посоветовал не решать одновременно две непонятные задачи: выполнять формализацию предметной области и изучать UML. лучше начать с первой и, когда с ней станет все ясно,  переходить к ее описанию с использованием некоторого стандартизованного синтаксиса (того же UML)

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »