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

×


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

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


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

Страницы: « 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 »
391
Цитата: sudo-su
Процесс ОДНОЗНАЧНО является объектом автоматизации. Ну, если точнее, то следовало бы его назвать субъектом, наверное :) В ГОСТ 34-й системы столько противоречий...

нееее, не следовало. сами подумайте почему. ГОСТ он есть, считайте что это "объективная реальность, данная нам в ощущении". тем более, что противоречти ГОСТа не являются предметом этого обсуждения.

Цитата: sudo-su
Это ведь тоже процесс... Процесс снятия показаний со счетчиков мы автоматизирует или делаем автоматическим, потому он и становится объектом автоматизации.

Нет не процесс, а операция. Так что если Вы ее автоматизируете, то в лучшем случае получится автоматизированная операция. Но будет лучше, если в данном случае ни Вы, ни кто-либо еще не будет ее автоматизировать. "Оно работает - не трогай его" (с)

:о)))

392
Вам скорее всего не нужно тащить аналитика в пресейл. Правильнее будет, чтобы продавец продавал продукт!
И вот проданный продукт пусть он формально опишет для следующих стадий разработки (или что у вас там)

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

P.S. по SPIN смотрите книжку Нила Рекхема (Neil Rackham) Продажи по методу SPIN. она есть в сети


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

на просторах я пока не нашел 2.0, 1.6 есть, по 2.0 есть overview страниц на 16. искал с помощью pdf-search-engine.com может надо было какой-нить djvu-файл искать...

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

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

397
IMHO в соответствии с описанной выше схемой последовательность состояний должна выглядеть примерно следующим образом:
1. Готов к работе (находится в резерве)
2. Находится в работе (установлен, используется)
3. Ожидание обслуживания (снят независимо от причины, но еще не отправлен в ремонт / на заправку)
4. Находится на обслуживании
5. Выведен из эксплуатации

398
Раз у Вас описание формы на XML, то значит форма может быть показана и обработана в браузере, разве не так? или я чего-то не понимаю про Ваше описание формы?

Хотя может Вы хотите просто заменить один редактор форм другим... Но Вы ведь собираетесь поддерживать совместимость структуры сохраняемых форм при создании их с помощью совсем другого редактора?  или уже нет?

Что-то у меня вопросов больше чем ответов.

399
ПО Аналитика / Re: ARIS
« : 11 Марта 2010, 16:47:27 »
Цитата: zmey14
Вчера прочитал громадную PDF-ку про ARIS.

интересно какую именно, раз возникло так много впечатлений :о))

Цитата: zmey14
Понял что это что то очень полезное.

Несомненно :о)))

Цитата: zmey14
Где можно купить или скачать бесплатно это ПО насколько дорого оно стоит ?

Дорого-дорого, спрашивать цену в компании "Логика бизнеса", IDS Sheer
Но есть и бесплатный ARIS Express

Знания UML при освоении ARIS вряд ли помогут. Однако ARIS поддерживает UML. Плюс у полной версии есть некоторые возможности, которые могут быть полезны и для проектировщиков программного обеспечения.

400
Обсуждение статей / кстати
« : 10 Марта 2010, 15:04:05 »

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

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

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

P.S. про политические игры довольно много написано у Йордона в Death march.

402
успеха тебе, поделись инфой по результатам...

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

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

P.S. а в проектную группу заказчик тоже должен входить, ведь с его стороны тоже есть работы, которые никто кроме него не может выполнить. но в любом случае проблемный начальник как минимум stakeholder.
Рекомендую почитать книжку Рассела Арчибальда по управлению высокотехнологичными проектами.

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



404
чёта какие-то глюки наблюдаются, обрывы всякие... ничего не понимаю... что происходит-то?

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

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

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

вот как-то так, в таком вот разрезе...

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

Если этого ничего нет, то, боюсь, что у Вас реализовался риск проекта, когда Вы должны что-то получить от заинтересованных лиц, при том, что у них нет обязанностей это делать, а у Вас нет полномочий с них это требовать. Если у Вас нет роли "чей-то родственник"  :), то я бы, к сожалению, оценил Ваши шансы на урегулирование данной ситуации как достаточно низкие.

как говорится, плюсадин. практически

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

сейчас время уже упущено, но договариваться и решать что-то подобное все равно придется...

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

Цитата: Михаил Курбасов
Просто ситуация выглядит как организационная проблема, вызванная нерешенностью вопроса о ролях, зонах ответственности и полномочиях в проекте. И надеяться, что ее можно решить "психологическими трюками" - ну, не знаю...

согласен.

Цитата: Galogen
А тут меня не подпускают как раз к сотруднику, который реально и будет заниматься ШР (да и занимается). Более того, я спросил при второй встречи, кто занимается ШР, с кем мне главным образом заниматься. Начальник ПФО указала на эту сотрудницу. Но, конечно, слова это не документ

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

[quote  author=Galogen]
я думал написать служебную  на имя ректора, объяснив чем может быть риск успешности проекта. Стоит сделать, как думаете?
[/quote]

а что это даст? если просто пожаловаться, то IMHO бессмысленно - все равно что расписаться в собственной немощности
IMHO если уж эскалировать, то сказать, что не хватает полномочий таких-то (если это так), и нужно предложить 2-3 (хотя можно и одно) проработанных решения, каждое из которых приводит к нужному результату, но каким-то своим путем, чтобы ЛПР выбрал одно из предложенных, хотя может и свое предложить.
кстати, термин "риск успешности проекта" как-то вне рассматриваемого контекста, или это опечатка?

[quote  author=Galogen]
 попытка решить организационную проблему и вызвала в общем-то негативную реакцию
[/quote]

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




Страницы: « 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 »