1186

Сообщество Аналитиков / Re: Неформальная сентябрьская встреча

« : 21 Сентября 2007, 12:54:32 »

У нас теперь аналитики, как и программеры, пиво пьют??? Аналитик - более достойная профессия

В смысле - только коньяк и текила?

1187

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

« : 20 Сентября 2007, 11:49:38 »

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

Да, я туда действительно пошёл по Вашей "наводке".

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

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

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

1188

Бизнес-анализ и Целеполагание / Re: Модель потребностей в малых проектах по созданию публичных веб-систем

« : 19 Сентября 2007, 20:15:26 »

Ничего теоретического - у самого несколько проектов такого характера на руках.

Нет возможности провести ОБШИРНОЕ маркетинговое исследование.

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

О чём вообще этот наш с вами системный анализ?

(голосом Вицина) Не "наш", а "ваш". Я вообще-то аналитик не настоящий.

1189

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

« : 19 Сентября 2007, 19:59:20 »

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

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

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

1190

Бизнес-анализ и Целеполагание / Re: Обещанная статья про целеполагание

« : 19 Сентября 2007, 19:27:02 »

2greesha
И?

С точки зрения "обычного" менеджера, "самоуправляемая команда" несёт полную ответственность за разработку продукта: "Я даю вам полную свободу и умываю руки".

Хорошо, если над командой нет такого менеджера. А если есть? Интересно, кстати, было бы узнать, что думает по этому поводу команда, которая представляла пример внедрения SCRUM на прошедшем в прошлый четверг семинаре AgileRussia.

1191

Бизнес-анализ и Целеполагание / Re: Модель потребностей в малых проектах по созданию публичных веб-систем

« : 19 Сентября 2007, 19:17:03 »

Но как быть в ситуации с созданием массовых продуктов, когда нет чёткого понимания, на какую аудиторию ориентироваться и какие именно потребности закрывать? Причём делать обширные маркетинговые исследования не позволяют ресурсы (деньги и время).

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

Мне кажется это один из "чисто теоретических" случаев.

Если нет возможности провести маркетинговое исследование, то что означают "релевантные потребности"? Откуда они возьмутся?

1192

Бизнес-анализ и Целеполагание / Re: Обещанная статья про целеполагание

« : 19 Сентября 2007, 12:00:27 »

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

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

Казалось бы, при чём здесь Agile?

1193

Управление Проектом / Re: укрощение EPF Composer

« : 18 Сентября 2007, 18:31:58 »

Кажется, я понял как и что.

Да можно загрузить соотвествующую библиотеку OpenUP и начать ее активно переводить.

Вопрос как работать совместно? Кто и что переводит? Как распределить обязанности? Пока я не очень понял как это сделать с помощью данного продукта.

Кроме того, Вы то лично что переводите? Сам OpenUP или конструктор, насколько я понял первое...
Как обмениваться частями перевода? Как быть если выйдет новая версия, сильно отличающаяся от предыдущей (так и было между последующей и предыдущей)

Только что я запостил в другую ветку свой комментарий по поводу перевода:
http://www.uml2.ru/forum/index.php?topic=219.0

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

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

Использование EPF для меня не является самоцелью. Я пока не вижу явных преимуществ использования его как инструмента, но уже нашёл преимущества в организации данных по сравнению с Wiki.

1194

RUP EUP AUP OpenUP / Re: Создание русскоязычной версии и развитие процесса OpenUP/Basic

« : 18 Сентября 2007, 18:14:39 »

Поскольку я успел внести мизерный вклад в перевод, меня "посчитали", и неделю назад я получил письмо из IBM, содержащее такие строки:

As you know, we want to leverage your knowledge and experience by harvesting the comments and content added to this Wiki so we can enhance the processes available in EPF. In order to do this, we need to perform two activities:

1- Migrate the EPF Wiki from its current location to Eclipse organization infrastructure.
2- Move the content from the current Wiki to the new Wiki located on Eclipse infrastructure

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


При переводе я упёрся, в первую очередь, в терминологию. Ниже в этой ветке было небольшое обсуждение по этому поводу. Как мне сейчас видится, единой терминологии как не было, так и нет. Приверженцы Agile, похоже, вообще не озабочены переводом и говорят на жаргоне, в котором большинство слов представляют собой англоязычные термины, склоняемые по правилам русского языка. Среди "процессников" идут вялотекущие споры о терминах, но каждый, как мне кажется, остаётся при своём мнении.

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

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

Но в EPF есть раздел Term Definitions! И мне кажется логичным начать с перевода этого раздела.

1195

Управление Проектом / Re: укрощение EPF Composer

« : 18 Сентября 2007, 17:32:42 »

Чёрт, до меня только что дошло, что речь идёт об Eclipse.
Я не тормоз.

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

Я заинтересован в данном общении. И первый же вопрос такой: а на русский язык Вы уже что-то переводили?

1196

Работа / Re: Чем плохи типичные объявления о работе?

« : 17 Сентября 2007, 15:47:17 »

Вы думали как культура появляется, сама собой?

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

1197

Работа / Re: Чем плохи типичные объявления о работе?

« : 17 Сентября 2007, 15:18:32 »

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

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

Впрочем, поживём - увидим. Критиковать других легко, это я тоже по себе знаю.

1198

Работа / Re: Чем плохи типичные объявления о работе?

« : 17 Сентября 2007, 14:21:59 »

Да, правда? А если мы рассмотрим объявление как интерфейс между "соискателем" и работодателем, выявим их интересы, представим чтение и реакцию на объявление как прецедент, в ходе которого достигаются цели, проистекающие из интересов участников?

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

Чтобы оторваться от теории, попробую прокомментировать некоторые из требований.

Краткий рассказ о тематике работы, её специфике, компании и её положении на рынке, коллективе и его ценностях.

1) Компании как таковой ещё нет, есть только гениальная идея, и для её реализации формируется команда.
2) Компания, которой требуется аналитик, - ФСБ России.
3) Требуется аналитик в команду, формируемую для освоения крупной суммы из государственных средств (например, для разработки второй версии ЕГАИС). Причина: по условиям тендера в команде должен присутствовать какой-то непонятный "аналитик".

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

Если бы работодатель точно знает суть работы и требуемые навыки, значит, скорее всего, у него уже есть аналитик.

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

Ага, так и писать: зарплата - 5 тыс. долларов, чёрная
Перспективы роста полностью зависят от личных качеств сотрудника, я себе трудно представляю описание перспектив роста для человека, которого в глаза не видел.

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


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

1199

Работа / Re: Чем плохи типичные объявления о работе?

« : 17 Сентября 2007, 13:43:08 »

хорошо... ролевик так ролевик...

"Мы не из дурдома, мы - ролевики!.." (c)

Как мне кажется, мы здесь придаём излишнее внимание собственно объявлению о работе. Объявление должно только привлечь внимание соискателя. Для этого достаточно нескольких формальных требований (например: указать компанию, сайт, требования к опыту работы и реальную вилку зарплаты).

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

1200

Работа / Re: Организация работы отдела анализа

« : 14 Сентября 2007, 11:53:40 »

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

Да разве кто-то исследовал, сколько подходов используется на практике... IMHO, сколько людей, столько и подходов.
Вон Эля изложила свой подход - разве он стандартный?