181

Работа / Re: Помогу системным аналитикам в поиске работы в Москве в штат

« : 04 Февраля 2013, 12:41:35 »

davvol, поделитесь своими догадками? интересно.

Ну, я угадал где-то на треть:)

1. Исходя из того что из 9 человек опыт аналитики есть только у двоих, я предположил, что людям других профессий на данном форуме могло показаться что аналитики только и делают что рисуют симпатичные схемы в UML, IDEF0 и BPMN, а все проблемы сводятся к "как красиво нарисовать ВИ" и "как заставить программеров делать то что я написал в ТЗ".

2. Исходя из того что четверо человек были не из столиц, я предположил что эти люди как раз и не имели опыта работы аналитиком и соответственно им будет тяжело найти работу с учетом низкого спроса на специальность по месту проживания. (Тут у меня есть пример друга, который долгое время мыкался в Воронеже в поисках приличной работы, а переехав в Москву тут же был взят аналитиком в Люксофт).

3. Несоответствующий набор навыков. Здесь схоже с первым пунктом. Я предположил что люди без опыта могли предположить что знания специализированного софта(EA, RR, Bizagi и т.д.) будет достаточно чтобы удовлетворить требованиям профессии.

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

Вот это кстати довольно интересно. При чем тут биологический отбор?
У нас на работе так же было пару лет назад. 6 женщин-аналитиков и только один мужчина. Сейчас 3 на 3.

182

Задачи студентов / Re: Помощь в диаграммах для проекта "Форум"

« : 31 Января 2013, 11:43:49 »

"Создайте сценарии выполнения для каждого базового прецедента."

Это значит теперь для каждого ВИ надо написать сценарий? А в какой форме его писать? Читал, что должно быть подобие 3х таблиц: Общее описание сценария, Типичный ход событий, Исключения.

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

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

Можно описывать потоки текстом: Например основной поток: шаги 1,2,3 и т.д., а альтернативный 3а, 4а, 5а и т.д.
А можно рисовать разветвленные блок-схемы с развилками там где основной поток может перейти в альтернативный.
Тут уж как кому хочется. Но я считаю что рисунок надо всегда сопровождать текстом. 

183

Работа / Re: Помогу системным аналитикам в поиске работы

« : 30 Января 2013, 10:30:30 »

Ниже я поясню, почему, если вы ещё не догадались.

Может уже пора?
Любопытно, соответствуют ли догадки реальности.

184

Системный Анализ и Требования / Re: ТЗ на доработку

« : 21 Декабря 2012, 12:37:08 »

По нему все сделанно, сейчас начинается 2-й этап работы, в котором есть как доработка/изменение существующего функционала, так и добавление абсолютно новых компонентов. Например, нужно добавить справочник "SomethingRef". Вообщем нужно думать.

А что вам мешает так и называть разделы:
"Требования по реализации нового функционала"
"Требования по доработке существующего функционала"
?

И в каждом по пунктам каждое требование отдельно.

185

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

« : 05 Декабря 2012, 11:49:27 »

Обычный файл Excel, как вариант.

Возможно.
Но у меня создалось впечатление что речь идет о чем-то большем.

186

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

« : 05 Декабря 2012, 10:39:32 »

Коллеги, добрый день!

Привет!

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

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

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

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

Для наглядности я сделал маленький пример (во вложении), на основе твоих вводных, где проиллюстрировал свои предложения.

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

Да, мне про реестр тоже интересно:)

187

Вакансии / Re: системный аналитик на долгосрочный проект в Москве

« : 04 Октября 2012, 10:47:51 »

а чего офигительного?

Наверное потому что  написано в стиле:

"Требуется работник чтобы работать на работе. Зарплата деньгами"

188

Управление Проектом / Re: один способ управления задачами в команде

« : 02 Октября 2012, 11:50:44 »

А есть возможность внести изменения в схему?

Если, например, привязать срок не к закрытию заявки, а к ее выполнению?
Как допустим в Jira, выполнил задачу в срок, и перевел ее обратно на руководителя. А он ее пусть хоть до второго пришествия проверяет, ты уже все сделала и со всех сторон молодец.
Тогда появится возможность и руководителей штрафовать:)

189

Для всех / Re: обратная связь по документации с помощью опросника

« : 02 Октября 2012, 11:42:45 »

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

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

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

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

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

Хотя тут может зависеть от людей. В моей команде, например, есть разработчик который просит чтобы я рисовал ему в ТЗ прототипы интерфейсов буквально для всего нового функционала, вплоть до добавления поля в отображаемой таблице:)

190

Работа / Re: Как стать аналитиком?

« : 20 Августа 2012, 15:24:38 »

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

Когда я был новорожденным аналитиком, я думал что самое главное - это круто рисовать схемы на UML да знать нотации BPMN с IDEF.

Однако практика работы показала(сейчас говорю только за себя конечно), что самое главное - это вытянуть из заказчика то, что ему действительно нужно, а не записать в ТЗ то, о чем он говорит.
Что нужно разрешать конфликты требований между представителями заказчика.
Что нужно следить за разработчиками чтобы они делали по ТЗ.
Что нужно помогать тестерам при проверке требований.
Что основные инструменты аналитика - это не Requisite Pro, Sparx EA и BPWin, а почта, телефон и Word:)

Работа аналитика неразрывно связана с общением.
Если вы не любите разговаривать с людьми, то лучше даже не пытаться. Потому что придется каждый день с ними общаться. От соседа-разработчика, до директора Банка. И к каждому нужен свой подход.

191

Управление Проектом / Re: Может ли менеджер IT проектов успешно управлять проектом, не зная самого ПО?

« : 03 Августа 2012, 16:54:34 »

По Вашему принциму, тогда на должность директора завода вполне подойдет директор ресторана, главное подобрать Главного инженера. Только на практике я такое не видела

Это уже другая сфера работ. Ресторан - не производственная отрасль.

Однако, в истории страны были похожие примеры.
Например во время войны, хороших управленцев из кадрового резерва центрального аппарата ставки отправляли руководить заводами на местах, которые не справлялись с планом.
И в большинстве случаев они справлялись с задачей, т.к. именно в управлении превосходили местных директоров.

Так что на знании предметной области свет клином не сошелся. Это важно, но вторично.

192

Управление Проектом / Re: Может ли менеджер IT проектов успешно управлять проектом, не зная самого ПО?

« : 03 Августа 2012, 13:28:30 »

Как выпускаются котлы - обязан знать главный инженер.
Директору эти знания полезны и желательны, но не обязательны:)

193

Управление Проектом / Re: Может ли менеджер IT проектов успешно управлять проектом, не зная самого ПО?

« : 03 Августа 2012, 10:26:43 »

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

И Королев и Глушко не были менеджерами в том смысле, как мы понимаем это слово сейчас. Они были скорее "тим лидами", в то время как реальное управление осуществляло непосредственно советское руководство.

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

Не могу согласиться. Чубайс очень талантливый менеджер, который блестяще достигал всех поставленных перед ним целей. Просто не мы с вами бенефициары его проектов, вот и все.

Управленцем в данной ситуации был Витте, а Александр 3 только заказчиком. Говорите "грамотно ставить задачи", а как их ставить грамотно, если понятия не имеешь, что задача должна решать? Как определить срок, не зная задачи? А как узнать правильность решения?

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

В итоге наше обсуждение можно выродить к вопросу: Обязан ли начальник РЖД знать как делают паровозные котлы?
Имхо в такой  постановке, ответ очевиднее чем изначально:)

194

Управление Проектом / Re: Может ли менеджер IT проектов успешно управлять проектом, не зная самого ПО?

« : 20 Июля 2012, 13:48:45 »

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

Значит он просто хреновый менеджер. Предметная область тут совсем не при чем.

195

Управление Проектом / Re: Может ли менеджер IT проектов успешно управлять проектом, не зная самого ПО?

« : 20 Июля 2012, 10:36:14 »

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

А с каких пор качество управленца определяется знанием предметной области?
Ему что, надо знать как система работает с БД чтобы составить бюджет?
Ему надо знать особенности архитектуры чтобы опросить разработчиков на предмет трудозатрат и составить план-смету с продажником?
Ему надо владеть используемой в компании IDE чтобы планировать загрузку сотрудников на год с учетом проектов, больничных и отпусков?
Ему нужно уметь писать на Java чтобы поддерживать мотивацию команды и разруливать конфликты?

Знание предметной области это несомненно плюс и важно, но оно  вторично по отношению к управлению.