Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Юрий Булуй

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »
451
А где мое интервью -- обещали прислать ... там же?

452
Юрий, я имею ввиду интерфейс, который содержит элементы, которые ссылаются на требования.

Не вполне понял что имеется ввиду (сложно как-то предложение выстроено :-)) ... вы не могли бы пояснить?

453
2 anastazya: Вопрос в том, что именно поинимается под требованиями к GUI в конкретном случае. Я встречал 2 разных случая описания такого рода требований:
1) требования к интерфейсу описываются в общем виде -- т.е. в лучшем случае говорится какие элементы GUI должны использоваться (или из какой библиотеки GUI), могут приводиться ссылки на конкретное ПО ("чтобы был GUI как в нем", например sсheduller как в Outlook и т.п.)
2) в ТЗ приводится собственно дизайн GUI -- это бывает когда задача разработчика суть чисто кодирование (т.е. вот тебе дизайн, включая дизайн GUI -- напиши реализацию на таком-то ЯП) или когда по требованиям (например по тем же юзкейсам) в качестве сторибоардинга был спроектирован МАКЕТ GUI (для иллюстрации) и который имеет рекомендательный характер.

Очевидно, в зависимости от ситуации описание требований к GUI будет различно ... Каков случай ваш?


454
Я же уже пояснил мотивацию "гуру" к паблисити ... Только статусом и аудиторией мероприятия можно добиться присутствия известных людей. Взять например состав докладчиков на SECR с 2005 по 2007 гг. ... Почему многие участники идут на SECR -- правильно, т.к. там можно послушать Якобсона, Казамана и пр. реальных гуру -- причем им за это платят деньги (гурям за выступление), т.е. у них есть определенная мотивация, и они эти деньги отрабатывают. Теперь прикинь сколько народу из числа участников выложили свои собственные деньги за участие в конференции в качестве слушателей ... правильно -- единицы. Почему многие другие известные люди и консультанты в России не выступают на SECR, но зато их доклады регулярно есть на целевых мероприятиях проводимых вендорами? Тоже правильно, они считают что это выступление на SECR им не принесет новых контрактов, зато выступая на мероприятих вендоров, в партнерах которых они числятся -- даст им дивиденты -- это чистый бизнес-расчет. Т.к. аудитория правильная, плюс лишний раз показать лояльность вендору.
Т.о. мы имеем 2 разных "business drivers" "гурей" :-) к выстеплению на ивентах -- первый это чисто маркетингово-бизнесовый, а вот второй, условно назовем "моральный" -- это как раз та самая контрибуция в развитие сообщества. Согласись, мотивация участия в качестве докладчика несколько иная -- одни это могут рассматривать как некую "благотворительность", другие же могут иметь искренние порывы к "улучшению мира". Конечно тут тоже есть бизнесовая нотка, именно поэтому слово "моральный" в кавычках, но эта бизнесовая составляющая не столь явная. Но, если такой ивент, позиционирующийся организаторами как развитие сообщества и т.п. на самом деле будет преследовать иные цели (т.е. банально организаторы хотят немножко заработать, и\или потренироваться на организации ивентов чтобы в будущем из этого сделать бизнес) -- то становиться закономерным вопрос у докладчика "шо я с этого таки буду иметь" :-) ... какая мотивация должна сработать?
Вот поэтому я и хочу понять позиционирование и намерения чтобы четко себе осознавать в каком качестве и для чего я буду участвовать. Доклад подготовить - это время, ибо халтуру гнать я не люблю. Одно дело я делаю маркетинг и морально принимаю условия игры, другое дело действительно искренне участвую в развитии сообщества -- но тогда ни о какой коммерции речь не может идти.

455
Мы все можем пообщаться с кем угодно и когда угодно, но можно ли это сделать в одном месте и в одно время - собрать профессионалов и уважаемых людей и устроить круглый стол или просто пообщаться в кулуарах?
Проведение встречь и семинаров - это неотъемлемая часть и бум это делать раз в месяц, но опять же на один семинар собрать 10 гуру, я думаю, не реально.
Конференция имеет совсем другой статус и проходит как правило 1 раз в год, будем стараться двигаться к идеалу, чтобы заинтересовать МНОГО интересных людей, но без Вашей поддержки это не получится.
Опять же в Америке конференция рассматривается просто как большая тусовка гуру по обмену опытом и зачастую бывает с фуршетом и многодневная.
Но не могут на первую конференцию прийти сразу толпа CIO и это понятно. Вторая-третья конференция - вот это уже более реально. Будем работать с CIO целенаправлено.
А мы пока с ними и не конкурируем, они свои ивенты проводят, а мы свои. В след. году нам уже будет легче.

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

456
ОК, значит речь идет о зарождении бизнеса по организации конференций, т.е. преимущественно коммерческая идея. т.е. бизнес строится на простой идее: докладчики имеют интерес самопиариться (для тех же коммерческих целей, а "общение" и все такое это только красивые слова, ибо при желании я могу сам пообщаться с тем же Хлебниковым и др. уважаемыми в сообществе людьми, кроме этого для общения есть и этот сайт), а организаторы хотят заработать. Платят за это участники :-). Отсюда явный интерЭс у докладчиков -- участвовать в тех ивенах которые принесут им больше дивидентов за счет целевой аудитории на которую он будет вещать. Т.о. докладчику лучше всего прилагать усилия чтобы попадать на c-level events, на котором будут присутствовать CIO, пусть даже небольших компаний, но люди которые принимают решения о том чтобы "купить услуги докладчика".

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

Р.S. Интересно, сможете ли вы конкурировать с ТЕКАМА и CareerLab ...?


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

458
Дистанцируйтесь от денег и мотивации организаторов. Мероприятие делается для обмена опытом как среди равных по роли специалистов, так и с другими специалистами. Не надо ничего домысливать и заниматься фантазированием.
Здесь вполне конкретное предложение выступить с докладом или прийти послушать доклады коллег. Если это неинтересно, никакие доводы не убедят вас в обратном, это пройденный этап.

Денис использовал хороший термин "информационная прозрачность". Просто я хочу понимать цели и задачи организаторов, а так же финансовую сторону вопроса. Вот с Training Labs все было вобщем-то понятно. Цели УЦ Люксофт тоже понятны, как и финансовая сторона вопроса. Мне было понятно почему я иду экспертом туда, да еще в выходной (тащиться в Москву) -- я "морально" поддерживал многочисленную группу своих товарищей из UML2.ru и нескольких докладчиков :-).
Второй момент, вы действительно считаете, что на таком ивенте, про который мне НИЧЕГО пока не известно, даже не известно будет ли он отражен на CNews и вообще в ИТ-прессе мне будет ПРОСТО интересно сделать доклад? Даже если предположить, что мотивацией докладчика будет самопиар в среде "равных по роли", то этот самопиар сомнителен ... ибо аналитики не распоряжаются ИТ-бюджетом и степень их влияния на принятие решения о покупке скажем меня как консультанта в их организацию не так уж велика ... Выходит материального стимула у меня нет. Мне остается ожидать увидеть "моральные" стимулы для участия -- да, интересные темы, да интересные люди, с кем можно пообщаться (та же Наташа Желнова, не прочь с ней поговорить) -- но это участие не в качестве докладчика

Относительно формата. Неужели Вы не общаетесь с коллегами по цеху. Более непредвзято о том же PMDays мог бы рассказать Денис. К моему мнению всеравно будет предвзятое отношение, т.к. я был в оргкомитете.
Многие из Ваших мыслей уже были реализованы. А вот идея с разбором кейсов мне очень понравилась. Следует внедрить.
Круглые столы в прошлый раз были заменены на флип-чарты, где докладчик мог рассказать всем желающим по тематике доклада или на какую-нибудь еще тему. Кроме того на флип-чартах мог выступить любой желающий за тему которого проголосовали участники конференции.

Я обычно беру 10% за идеи :-).

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

Докладчики (в роли коих будут выступать и кто-то из организаторов) могут "засветиться" и "поднять собственный бренд", ок .... what's about money? Организаторы планируют получить какую-то компенсацию за собственные усилия по организации (затраты на аренду, обеды не в счет) или делают это абсолютно for free? В чем собственно мотивация организаторов?

Далее ряд мыслей.
1. Если мы позиционируем узкоспециализированную конференцию, то возможно стоит более четко фокусироваться на определенной области знаний программной инженерии. Если речь о требованиях, то тогда видимо следует говорить, что целевая аудитория в первую очередь - аналитики. Архитекторы, техписы, разработчики, тестировщики -- "так же могут получить интересную информацию для себя участвуя в конференции". 
2. Второе -- это формат проведения. Просто доклады, даже с элементами "заигрывания" с аудиторией, можно увидеть и на других конференциях. Как вариант можно предложить разбор кейсов совместно с аудиторией. Скажем, участники могут тоже заранее подготовить ряд кейсов для совместного обсуждения, формулировки проблем их конкретной ситуации -- чтобы совместно провести обсуждение.
3. Круглые столы по "острым" тематикам ... можно обсудить например где получить систематическую подготовку аналитику и дают ли программы подготовки от Люксофта, ТЕКАМы и пр. таковую, какой набор знаний должен иметь аналитик, как оценить качество работы аналитика, как оценить качество разрабатываемых требований ....

Вобщем мероприятие должно быть четко отличимо от подобных а) узконаправленностью б) форматом

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

460
1. К сожаления я не присутствовал на вышеперечисленных конференциях, поэтому не могу оценить статус, отчего и вопрошаю.
2. Точек соприкосновения с аналитиками (чуть не написал "с психоаналитиками" :-)))) много не только у техписов, но так же и у менеджеров проектов (scope проекта при разработке ПО целиком определяется требованиями), и проектировщиков\разработчиков ... а еще больше у специалистов по качеству ПО (особенно если тест-кейсы писать на базе требований) ...
3. Вопросы задавать Михаилу Острогорскому?
4. Да, есть отдельные люди, которые талантливы и могут совмещать несколько ролей в команде разработки ПО, но тем не менее, это разные роли с разными обязанностями, в нашем случае быть аналитиками требований и техписами. Но на аналитиков (или "постановщиков" в a-la советской практике) так же грузят еще и проектом управлять в отдельных компаниях .... и что, нужно делать тогда конференцию по проектному управлению и управлению требованиями ... дык SECR уже есть, который объединяет все области знаний программной инженерии ...

Так фишка в чем? Вобщем нужен четкий message ...

461
Адекватной замены из бесплатных тулов НЕТ. Хотя вопрос что есть "адекватная замена" ...

462
Конференция и темы докладов это хорошо. Но тут я соглашусь с Денисом. Мне нужно понять какова аудитория, каков  статус у конференции, где она будет освещена (CNews, Открытые системы, ....). IMHO объединять разработчиков документации (читай техписов) с аналитиками в одну конференцию ... лично мне как аналитику не очень интересно будет слушать про формат DocBook, Single Source и про то как разрабатывать качественную документацию пользователя. А техписам не очень интересны и понятны особенности построения Domain model ...

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

464
Здравствуйте!
             Кумара я не читала, а вот на счет Вигерса, то у него, действительно, большая путаница в терминологии. (Не смотря на всю ценность и полезность его контекста вцелом.)

"С этого момента пожалуйста подробнее" (с). Можно узнать о каких терминах идет речь, в которых есть путаница?

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

Бизнес-целью проекта вполне может быть некое желаемое состояние бизнес-системы (!), которое может характеризоваться достижением заданных значений набором определенных параметров ИЛИ приобретение некоторых новых свойств, ценных для бизнеса. Определение того, где будет цель (за пределами системы или внутри ее) зависит от понимания того, что мы принимаем за бизнес-СИСТЕМУ. Если бизнес-система организация в целом (включая акционеров), то моей бизнес-целью может быть сокращение расходов на те же 20%. Эта цель лежит где -- снаружи или внутри?

   Вообще, цель на бизнес-уровне – это очень выигрышный инструмент. И ее нужно четко уловить. Должна быть формализация понятия «цель», понятия «требования в контексте цели» или «проблема». К примеру, у нас есть цель – написание документа, и есть цели у Заказчика. Помимо того, у Заказчика есть цели относительно какого-то его текущего состояния и проблемы. Что-то делает его счастливым, а что-то его мучит. Поэтому, когда «совсем уже в чужую страну попадаешь», то первым делом нужно узнать, что в «этой стране» уже делается. То есть, расписать и показать бизнес-процесс «как есть».
   Чем цель отличается от задачи?
   Задача – полностью проверяема в рамках нашего контекста и какой-то формальной структуры. В отличие от задачи, цель – никогда полностью не проверяема.
   Оценка достижения или не достижения цели учитывается с учетом помех «из вне».
   Например, задача – получить документ на выходе. Цель – получит что-то больше, с этим документов достичь каких-то больших результатов, за пределами нашего понимания, знания о том, как пошел документ.

Написание документа не может быть целью. Это задача которая выполняется для каких-то целей. И вообще, нужно таки делать различие между целями ПРОЕКТА и целями той же операционной деятельности.

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »