46

Управление Проектом / Re: Оценка трудоемкости модификаций (разработки)

« : 11 Января 2009, 20:38:28 »

На мой взгляд, Заказчик, пытаясь обсуждать с Разработчиком трудоемкости доработок, заведомо играет на чужом поле и обречен на проигрыш. Согласен с Юрием, что "если разработчик не идиот", то найдет способ обосновать свои затраты.

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

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

Обычно даже самый малый намек Заказчика на то, что он рассмотривает возможные альтернативные варианты, оказывает эффект сродни детализации сметы в строительстве :-)

47

Работа / Re: Обзор зарплат бизнес-аналитиков

« : 04 Декабря 2008, 14:00:55 »

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

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

Может, в онлайн-конференции какие-то пояснения давались по этим вопросам?

48

Работа / Re: Кто такой Product Manager?

« : 19 Марта 2008, 14:51:28 »

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

Потому что один из основных принципов, лежащих в основе модели проектной команды MSF, состоит в распределении общей ответственности за продукт между различными ролями. И в этом смысле правильно было бы сказать, что ответственность за продукт команды = сумма ответственностей отдельных ролей. Если вы берете для себя только одну роль (Product Management), но не берете остального, то вы рискуете получить или дублирование функций, или, что еще хуже, пробелы в распределении ответственности.

Поэтому, если кто-то говорит, что его организация придерживается MSF в части модели формирования проектных команд, и у них есть Product Manager, то это более-менее понятно, что имеется в виду. А если MSF нет, а Product Manager есть, то тогда это, действительно, может быть все что угодно - микс между чем хотите...

49

Работа / Re: Кто такой Product Manager?

« : 18 Марта 2008, 15:48:41 »

Насколько я знаю, термин используется для обозначения одной из шести ролей в модели проектной команды Microsoft Solution Framework (MSF).

Вот по этой ссылочке:
http://www.microsoft.com/downloads/details.aspx?FamilyID=c54114a3-7cc6-4fa7-ab09-2083c768e9ab&DisplayLang=en можно скачать описание этой модели.
За ролью Product Manager закреплены следующие зоны ответственности (в модели Microsoft):
 - Acts as customer advocate
 - Drives shared project vision\scope
 - Manages customer requirements definition
 - Develops and maintaines business case
 - Drives features vs. schedule vs. resources tradeoff decisions
 - Manages marketing, evangelizing and public relations
 - Develops, maintaines and executes the communication plan

50

RUP EUP AUP OpenUP / Re: Как Agile вытесняет RUP

« : 23 Января 2008, 15:22:39 »

Обращает на себя внимание, что "Agile вытесняет RUP", прежде всего, в Индии. По остальным странам картинка, мягко говоря, другая.

P.S. Может, индусы просто не смогли разобраться в RUP?...

51

Работа / Re: Начало карьеры

« : 22 Января 2008, 23:41:45 »

Да, тут важно определиться, что Вы хотите.
Есть три пути:
...

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

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

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

52

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

« : 01 Октября 2007, 21:29:41 »

Мне понравилась мысль boatman'a о трассировании требований к целям как о методе проверки необходимости требований. Правда, встает вопрос о качестве и адекватности описания целей...

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

53

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

« : 01 Октября 2007, 10:53:47 »

2 All: Я так понял, что экспертное вычитывание рулит.

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

54

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

« : 01 Октября 2007, 10:46:01 »

...не могли бы Вы уточнить...

Уважаемый Shur! Мне кажется, Вы хотели бы подискутировать на тему "ответственность Заказчика vs ответственность Исполнителя". Я понимаю, что это важная тема, и в другой ветке форума готов был бы продолжить данный диалог. Но здесь я задавал исходный вопрос немного по-другому. По теме "можно ли считать подпись Заказчика достаточным критерием качества ТЗ?" Вы свою точку зрения высказали, я свою - тоже. Стало понятно, что у нас с Вами разные точки зрения...

55

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

« : 28 Сентября 2007, 21:44:39 »

Вы полагаете, что можно сделать хорошую систему в рамках конкретного проекта для конкретного Заказчика вопреки его косноязычию и изменчивости его позиции?

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

Если Вы формулируете требования, которые должны быть качественными с точки зрения Заказчика, то то, что конкретный Заказчик считает правильным, то и будет качественными требованиями.

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

56

Обучение / Re: Критерии профессионального роста аналитика

« : 28 Сентября 2007, 21:26:56 »

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

Мне идея оценки сложности/рисковости проектов понравилась. Надо ее подумать поосновательнее...

57

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

« : 28 Сентября 2007, 09:55:44 »

Заказчик (принимающий работы по написанию ТЗ) целиком несет ответственность за то, под чем он подписался, принимая ТЗ.

Как говорил один наш заказчик, "ну и что, что я подписал ТЗ?! моя подпись на документе не означает, что мы теперь не можем ничего изменить".

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

58

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

« : 27 Сентября 2007, 12:49:05 »

Пожалуйста, не могли бы Вы уточнить:
Насколько я понял - Аналитик (который писал ТЗ) - специалист Исполнителя.
Согласующий (с субъективизмом которого нужно разобраться) - специалист Заказчика или Исполнителя?

В Вашей практике ответственность за содержание (написание) технического задания в большей степени лежит на Исполнителе, а не на Заказчике системы?

Насчет ответственности - да, в нашей практике именно так.

Насчет субъективизма, поясню вопрос. Человек, который согласует документ требований, может сказать, что "как же вы не учли то-то и то-то, это очень важно!", и настоит, чтобы эти требования, которые он считает важными, были добавлены. Однако, где гарантия, что это действительно важные требования для всех пользователей, а не только его личные пристрастия? Тут, по опыту, не принципиально, будет ли данный "эксперт" со стороны заказчика или со стороны исполнителя. Такие сюрпризы могут быть и в том, и в другом случае. Есть ли у вас silver bullet для таких случаев?

59

Обучение / Re: Критерии профессионального роста аналитика

« : 27 Сентября 2007, 11:31:44 »

А чем они там у вас занимаются? Что есть результаты их работы? Через какой срок и где могут всплыть просчеты аналитика?

Я как раз хотел понять не столько, как "у нас", а как раз узнать, как с этим обстоит "у вас" 

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

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

60

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

« : 27 Сентября 2007, 11:21:53 »

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

Не получается так, что запуганные пользователи после этого затягивают согласование до бесконечности, и пытаются впихнуть в ТЗ все, что нужно и что не нужно, лишь бы, не дай бог, не осталось что-то за кадром, что может понадобиться, даже и чисто гипотетически?