286

Управление Проектом / Re: Дружеские отношения или жесткая корпоративная этика

« : 12 Октября 2010, 19:59:21 »

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

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

287

Управление Проектом / Re: Дружеские отношения или жесткая корпоративная этика

« : 12 Октября 2010, 17:22:26 »

что-то мне подсказывает, что у Вас в загашнике еще много тем из серии "научите меня по-быстрому...", не так ли?

ответ: с вами работают ЛЮДИ. кто они и какие у них характеры, интересы и т.п. - дело по сути случайное. автоматические механизмы "я тут подумал и решил: мы будем работать в условиях дружеских отношений (или наоборот)" не работают.
только в одном случае доля случайности снижается - когда вы затеваете дело с стародавними друзьями-приятелями (например, знакомыми с детства) и то, уверяю вас, в реальных обстоятельствах вы будете удивлены какими неожиданными гранями блеснут их (да и ваш тоже) характеры...
примеров тому - мульён! но, по счастью, есть и исключения.

288

Системный Анализ и Требования / Re: Противоречивость требований

« : 12 Октября 2010, 17:16:23 »

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

289

Системный Анализ и Требования / Re: Противоречивость требований

« : 12 Октября 2010, 12:58:29 »

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

290

Системный Анализ и Требования / Re: Противоречивость требований

« : 12 Октября 2010, 12:22:31 »

IMHO всё-таки Вы не слышите, что Вам говорят, и гнёте свою линию.
нет правильных вопросов, нет и правильной последовательности! нет и всё! всё строго индивидуально.
а чтобы говорить со знанием дела - нужно быть специалистом. однако ни вы, ни я, ни кто-то еще из нас ИТишников не может лучше заказчика знать его предметную область, его проблемы и потребности/хотелки. хорошо знать может, но лучше - вряд ли (иначе б работал на его месте). вот и нужно этого "хорошо" достигать + коммуникативные навыки.
так что единственный способ - грамотно говорить с заказчиком на его языке (как в той рекламе).

291

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 18:27:50 »

правильно договариваться нужно как-то так:
 - Я предлагаю чтобы эту функциональность не включать в такой-то релиз системы. Вы согласны?

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

292

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 17:56:40 »

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

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

293

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 16:36:37 »

Народ, не похоже ли это уже на флуд??

согласен

294

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 16:36:10 »

2 Странник:

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

по второму - детский сад, штаны на лямках. Ваше "Вы же согласились" ответственности с Вас как компетентного специалиста в области требований не снимает. Вам скажут: "Вы должны были предусмотреть и объяснить последствия. Вы это сделали? Нет? Какой же Вы тогда профессионал."
Так что это не последний рубеж - это желтый билет.
Не хотите его получать - идите, учитесь смотреть на три метра в глубь земли.
 

295

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 16:29:41 »

Я написал что систему менять нельзя Так что не подходит !

пардон, я ВООБЩЕ тогда НИЧЕГО НЕ ПОНИМАЮ. либо прекращайте абстракцию, либо закрывайте тему.

296

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 16:27:54 »

еще раз.
контракт на поддержку непринятой в эксплуатацию системы, т.е. системы с неопределенным набором функций, ЗАКЛЮЧАТЬСЯ НЕ ДОЛЖЕН. Иначе Вы не сможете его выполнить.
При этом действительно ресурсы поддержки оцениваются из опыта, статистики и т.п. Количество обращений тоже.
Однако дальше все зависит от организации процессов поддержки. В принципе я могу и в эту тему погрузиться, но она не для этого форума - читайте ITIL/ITSM и itsmforum.ru

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

297

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 12:11:18 »

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

298

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 12:06:40 »

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

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

P.S. зря вы это затеяли :о)))) с абстрактным примером... получите абстрактные ответы на все случаи жизни кроме вашего...

299

Консалтинг и Внедрение / Re: Расчет эффективности

« : 08 Октября 2010, 11:42:59 »

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

300

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 11:29:57 »

2 LastLegion86: Снимите шоры!
в приведенном Вами примере ни бухгалтерия, ни продавцы не видят и не могут знать какие и сколько полей в объекта накладная есть в БД!
еще одна подсказка: накладная для бухгалтерии и накладная для продавцов - суть разные представления одного и того же объекта.