1

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

« : 23 Марта 2010, 14:35:36 »

2 Водолей. Скорее, нужен best practise, как в части организационных подходов, так и в части теххнических/программных средств. Т.е. как ВООБЩЕ можно управлять требованиями - и с организационной, и с программно-технической точек зрения нам понятно. Хотелось позаимствовать чужого опыта для описанного кейса.

2

Системный Анализ и Требования / Управление требованиями в портфеле проектов

« : 23 Марта 2010, 12:18:45 »

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

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

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

Можно выделить очень много вопросов, которые хотелось бы решать, приведу только примеры. 1. В прикладном проекте заявлено требование заказчика - сделать Х. Кто будет реализовывать это требование - команда фреймворка (с тем, чтобы Х вошло в функции платформы) или команда прикладного проекта? 2. Со стороны прикладного проекта П1 заявлено пожелание модифицировать фичу платформы Y. На какие характеристики прикладных систем в проектах П2, П3 и т.д. это может повлиять? 3. Во фреймворке есть фича Z, а в прикладном проекте мы ее докручиваем до Z*. Правильно иметь в прикладном проекте формулировку требований Z* или Z*-Z? Ну и т.п.
 
Изобретать велосипеды мы сами мастаки, но все равно буду признателен и за частные отзывы. Но вопрос вообще про то, не знает ли кто, где можно ознакомиться с мнением великих по данной теме.

3

Консалтинг и Внедрение / Re: Укрощение строптивого или бег на месте

« : 04 Марта 2010, 23:05:42 »

К сожалению, куда-то не туда нажал, сообщение ушло недописанным.

Недописанная фраза должна выглядеть так:

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

4

Консалтинг и Внедрение / Re: Укрощение строптивого или бег на месте

« : 04 Марта 2010, 23:03:28 »

Эдуард, давайте проанализируем Вашу ситуацию с позиции управления рисками.

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

Нам надо продумать меры по предотвращению реализации этого риска, и, поскольку риск высокоприоритетны

Что бы Вы предложили?

5

Консалтинг и Внедрение / Re: Укрощение строптивого или бег на месте

« : 04 Марта 2010, 19:44:20 »

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

6

Консалтинг и Внедрение / Re: Укрощение строптивого или бег на месте

« : 04 Марта 2010, 19:40:32 »

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

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

7

Работа / Re: Поощрения

« : 01 Июля 2009, 11:28:16 »

Маленький дополнительный аспект. Некоторые из указанных видов "поощрений" будут "поощрениями" только в том случае, если носят индивидуальный характер.
Например, "медицинская страховка". Если она оформляется по умолчанию всем сотрудникам компании (входит в стандартный социальный пакет), то она вряд ли может рассматриваться как фактор поощрения (если только как поощрение за лояльность компании - но никак не поощрение за достижения). Другое дело, если это какая-то ТАКАЯ медицинская страховка, которой ни у кого другого нет, а данному сотруднику она очень необходима - тогда ее получение можно, конечно, рассматривать как поощрение.

8

Проектирование / Re: Peer Review ТЗ

« : 30 Июня 2009, 15:53:45 »

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

9

Работа / Re: Головоломки (логические) на собеседовании

« : 27 Июня 2009, 00:01:54 »

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

О чем, действительно, спор?

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

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

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

10

Проектирование / Re: Peer Review ТЗ

« : 24 Июня 2009, 17:55:47 »

Коллеги, мне кажется, смешиваются две немного разные вещи - review и peer review. Эти два процесса в чем-то похожи, но имеют совершенно разные цели.

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

В термине peer review ключевое слово - первое. Т.е. это "обзор равных" - коллег по цеху, собратьев по перу, как угодно можно назвать, но, главное - это не руководство аналитика (менеджеры), не заказчики и не "внутренние заказчики" (разработчики etc - кто принимает работу аналитика в проекте). Это именно эксперты, и цель такого review - не отладка ТЗ с целью его улучшения в конкретном проекте, а анализ стиля написания документов данным аналитиком для выявления его личных типовых ошибок и проблем в формулировании требований, структурировании информации, грамматике и пунктуации, если хотите. Аналогичная практика - peer review - существует в программировании, где братья-программисты могут под микроскопом рассмотреть код своего коллеги и по-братски поделиться с ним наблюдениями, как на самом деле надо строить циклы, работать с исключениями, называть переменные и т.п. Еще раз подчеркну, что цель такого мероприятия - чисто учебная. Это повышение квалификации аналитика. Это можно проводить в любое время, не обязательно когда ТЗ "с пылу-с жару", надо утверждать. Это можно сделать хоть через полгода после написания ТЗ - стиль работы аналитика так быстро не меняется...

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

Кроме того, есть одно распространенное заблуждение - что peer review можно применить для повышения качества ТЗ. Вот это совсем не так, это не получается...

11

Работа / Re: Какие профессии в IT сфере близки к бизнес-аналитике?

« : 17 Июня 2009, 12:40:58 »

P.s. Мой ник на форуме не Mikо, а Маko

Прошу прощения, ошибся.

дополню первоначальный вопрос: кем возьмут/пойти работать в IT-сферу, с полугодовым опытом работы бизнес-аналитиком/помощником бизнес-аналитика, чтобы в перспективе выйти на должность бизнес-аналитика? Может быть, менеджер по продажам ПО, хотя, что-то я сомневаюсь, но все таки, возможно, найдется тот, кто проведет параллель между этой профессией и бизнес-аналитиком, и покажет, как из нее можно вырасти в желаемую

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

Вот на что еще я обратил внимание.

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

В крупные ИТ-компании сейчас, я думаю, приходит что-то порядка 100 резюме в неделю на вакансии типа БА, и можно предположить, Mako, что с Вашим полугодовым опытом Вы там не очень котируетесь (хотя резюме я не видел Ваше, могу только предполагать). Удивительно, что Вам вообще ответили оттуда. Значит, все-таки у Вас не все так безнадежно, Вас заметили, хотя и не оценили. Может быть, Вам имеет смысл выбрать фирму поскромнее, с окладом поменьше? Там конкуренция будет не столь сильна, и, кто знает, может быть Вас и возьмут? Накопите опыт, а потом и перейдете в компанию посолиднее.

Вообще, Вы человек, наверное, достаточно молодой, и видели состояние экономики только в одной фазе. А я когда-то искал работу в 1998-1999 году, времена были другие, и тогда в типовых "рекомендациях соискателям" упоминалось "золотое правило" 1:10. Имеется в виду, что чтобы вас пригласили на одно собеседование, надо отправить 10 резюме. Чтобы в одном месте вам предложили работу, надо сходить на 10 собеседований. Тогда это считалось нормальным. Я нашел свою работу на 76-м посланном резюме.
Поэтому если Вы направляли резюме в <10 крупных фирм, и Вас никуда не берут пока, то это еще совсем ничего не значит. Может быть, в условиях нынешнего кризиса "золотое правило" выглядит как 1:20 или даже 1:50? Все равно не надо опускать руки, шлите и шлите - рано или поздно теория вероятностей сработает, и Ваша настойчивость вознаградится.
Удачи!

12

Работа / Re: Какие профессии в IT сфере близки к бизнес-аналитике?

« : 16 Июня 2009, 15:07:46 »

Где-то на форуме обсуждалось (не могу найти), из каких ИТ-профессий можно вырасти в аналитики. Общий вывод - практически из любых.

Miko, по вашей ситуации есть одно противоречие. Если Вам трудно найти работу, имея "всего полгода" опыт работы помощником бизнес-аналитика, то почему Вы думаете, что по другой ИТ-специальности, имея опыт работы ноль, Вам будет устроиться легче?! Сейчас такое время, что большинство работодателей, если и ведут найм, то хотят только готовых профессионалов в любой специализации. Время, когда ИТ-компании охотно брали людей без опыта "навырост", закончилось в прошлом году и вернется нескоро.

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

13

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

« : 29 Мая 2009, 11:27:49 »

обычно в ТКМ или КМ максимум что перечисляют, так это функционал будущей Системы, а на главный вопрос "Зачем весь этот функционал нужен?" никто не отвечает

Но это же не догма. Можно это и написать.

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

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

14

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

« : 28 Мая 2009, 23:00:44 »

Александр, но все же, и Концепция, как Вы пишете, призвана ответить на вопрос "Почему или Зачем мы разрабатываем\дорабатываем Систему?". И в ТКП, по сути, мы раскрываем ту же тему.

Почему я считаю важным на это указать?

Не во всех компаниях развита практика формирования vision'ов перед началом проекта. Многие до сих пор спрашивают, а что это? а зачем это? Ну уж ТКП-то, наверное, каждая организация пишет, у которой есть какие-то заказчики, ведутся какие-то продажи.

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

Как вам такая гипотеза?

15

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

« : 28 Мая 2009, 17:41:59 »

Вопрос к гуру по вижнам. Чем отличается с точки зрения практики применения в отечественной действительности vision от ТКП (технико-коммерческого предложения)?
В теории - шаблоны разные, все понятно.
А на практике - если вы высылаете заказчику ТКП на будущий проект, вы пишете еще отдельно vision? Или все, что вы могли бы написать в vision'e, вы пишете в самом ТКП?