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

×


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

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


Сообщения - AlexTheRaven

Страницы: 1 2 3 4 5 6 7 8 9 10 11 »
1
Не, IMHO никакой сложной логики учёта баззвордов в цитатах и отслеживания соответствия баззвордов контексту не нужно. Режим же шуточный и по умолчанию отключённый. Но в каждой шутке...

2
Мне очень нравится сайт uml2.ru . Я считаю его одним из самых полезных, а участников - корректными, адекватными и говорящими по делу в большинстве своих постов.

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

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

Чтобы участники этим не злоупотребляли - предлагаю реализовать на постах форума "bullshit bingo". Это такой режим, который участник может включить у себя в профиле. И после того, как включил:
1) "баззворды" у него начинают подсвечивается;
2) каждые, например, 10 "баззвордов", в ветке, которую смотрит участник, начинает отображаться пост "Бинго!".

Предположение о реализации - пре-процессинг записей, извлекаемых из БД, при формировании страниц форума.

Подробнее:
http://en.wikipedia.org/wiki/Bullshit_bingo
http://netlore.ru/Bullshit_Bingo
http://e-loto.altsoph.ru/

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

3
аналитик такой же как все???
Да. С одной стороны - да, он отличается от рабочего на конвейере. Хотя и рабочие иногда выдвигают настолько полезные и проработанные идеи и рац. предложения, что диву даёшься. С другой стороны - ничего исключительного. Обычный инженер. Ощущение "исключительности" и "элитарности" - ложное, как и во всех остальных случаях. За редчайшим исключением.

нет ну понятно дисциплина, хотя почитайте последние вакансии на hh,  им всем готовы дать по дивану для расслабиться, а не лежать и спортинвентарь чуть ли не в кабинете...обратитесь к опыту зарубежному...
Дисциплина - не самоцель, а способ организации достижения результата рабочей группой. Когда группа становится командой, в ней всегда развивается самодисциплина. Например в том, чтобы:
1) вовремя закоммитить работающий, поддерживаемый и прокомментированный код, от которого зависит ночная сборка и утренняя выдача в тестирование
2) максимально быстро и объективно провести ревью, от которого зависит дальнейшая работа остальных
3) терпеливо собирать, предлагать, дорабатывать и объяснять требования, пока всем не станет понятно, что, почему и зачем нужно/будут реализовать.

Дисциплина "отсидеть с 9:oo до 17:oo с каменным лицом" никому не нужна. Дисциплина "прийти на работу/встречу вовремя, чтобы сэкономить время своё и остальных, не расхолаживать, и/или повысить качество (1), (2), (3)" - почти обязательна. Дисциплина "сделать (продумать и записать) творчески, качественно и в срок, хоть сидя за столом, хоть занимаясь в это время на тренажёре, хоть лёжа дома на диване" - абсолютно необходима.

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

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

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

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

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


его положение сильно зависит от целей и задач, а его основная оценка - это результат...во времени!
Да. Но в довольно коротком и обозримом времени. Через месяц его работы на проекте людям должно уже стать легче понять, что нужно сделать. Даже если аналитик просто фиксирует запросы на доработку и помогает отвечать на вопросы "как пользователю нужно, чтобы вот в этом месте работало", при этом ещё слабо разбираясь в предметной области, не создав полные целостные [логико-математические] модели системы и организации, в первую очередь в своей голове.

А вот если и когда разберётся и создаст - тогда сможет вывести продукт на другой уровень потребительского качества и привлекательности для заказчиков.

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

4
Денис, у меня есть реальные WBS каждого аналитика, со всеми без исключения задачами, статусами, оценками, сколько ушло и осталось, и историей выполнения. В т.ч. на какой неделе какой у задачи был статус (хотя задача, которая в работе 2 календарные недели, уже привлекает внимание), сколько, по нашим оценкам, на неё тратили времени и оставалось потратить, как шло выполнение.

Задачи - разные, от "спланировать проработку...", "разработать доменную модель к...", "написать и согласовать требования к...", "проверить макет GUI... на соответствие требованиям...", до "разобраться с правильным поведением системы в issue id..." или "вычитать раздел документации...". Но стараемся все доводить до SMART. Конкретные примеры - покажу тебе в понедельник.

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

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

Тут Григорий Деминга цитировал, http://www.uml2.ru/forum/index.php?topic=1824.msg18552#msg18552 . Так вот, при оценке важно понимать, где та часть, которая зависит от организации, а где та, которая зависит от работы конкретного сотрудника :) .

5
Перечитал обе ветки, эту и http://www.uml2.ru/forum/index.php?topic=1824.0 . Выскажу своё мнение.

Аналитик – абсолютно такой же сотрудник, как все остальные. В ходе проекта, ему ставят конкретные задачи, и он их выполняет в конкретные сроки, при различных обстоятельствах. Текущая оценка «в целом» в ходе проекта должна состоять из множества оценок «в частности» за выполненные конкретных задач, а также учитывать стабильность и динамику работы и результата. Эти оценки могут быть существенно более объективными, чем чьи-то мнения и суждения, чувство удовлетворённости. Про удовлетворённость как критерий отдельно написал здесь, http://alextheraven.livejournal.com/4316.html .

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

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

А так, в общих оценках, зачастую ответственность за свои ошибки, в т.ч. перед начальством, перекладывают на исполнителя. «Поставил задачи/делегировал обязанности неправильным людям, которые получили за это низкие оценки и уже наказаны» - нелогичная, но существенно более безопасная формулировка, чем честное «сначала сам сказал ерунду сделать, а потом сам недосмотрел, что ерунду делают, ещё и сам никак не повлиял на обстоятельства, которые мешали сделать эту ерунду в срок, в результате на ерунду такие большие затраты».
Оценка многое говорит о том, кто оценивает.

В конкретных контрольных точках и по завершению проекта, наверное, нужно оценивать работу всех. Да и обстановку на проекте в целом. Такую контрольную оценку должны давать люди, которые умеют:
1) учитывать содержание и качество постановки задач, которые ставили, и обстоятельства, в которых их выполняли;
2) ценить то, что результат работы человека полезен, ну или не полезен, для проекта или направления в целом, хотя может быть неприятен (я уже писал в http://www.uml2.ru/forum/index.php?topic=1824.msg18798#msg18798 , что аналитик принимает или помогает принять решения, которые могут отличаться от того, что другие хотят или считают нужным, т.е. обеспечивает выработку общих интересов и ущемление частных);
3) понимают, то, что существующий результат – намного лучше, ну или хуже, чем работа вообще без:
-- требований;
-- моделей системы;
-- связи с заказчиками, технологиями и исследованиями, рынком и трендами, просто знающими людьми на проекте и вне его;
-- учёта предложений и запросов на изменения;
-- доведения до всех и каждого требований и решений;
-- всякой определённости с тем, что нужно разработать и протестировать;
-- просто человека-справочника, который может решать извечный спор между разработчиком и тестировщиком/приёмщика, как должно быть на самом деле, баг или enhancement;
4) учитывать, то, что работа с человеком приносит чувство удовлетворённости, вдохновляет, ну или наоборот, раздражает и расхолаживает (сильно зависит от ожиданий, отношений, отношения);
5) учитывать, что сначала нужно дать возможность и помочь научиться и сработаться, и только потом спрашивать;
6) что то, что для одного тривиально - то для другого может быть большим достижением, и эти достижения нужно ценить; кстати, в этом люди часто меняются ролями и дополняют друг друга.

Если людей, которые могут сделать такие контрольные оценки, нет – вообще не нужно делать таких оценок. Лучше никаких оценок, чем неправильные или неправильно применённые.

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

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

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

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

А зрелость, кстати, не всегда на пользу организации., см. теорию жизненного цикла организации Адизеса.

8
На этом уровне все предприятия похожи. В т.ч. в том, что пытаются считать себя уникальными.

А саповские бизнес-карты реально работают, особенно если говорить с людьми, понимающими бизнес на уровне реальных топ-менеджеров.

9
А зачем эти высокоуровневые процессы выделять? Они известны. От теории предприятия до эталонных процессов (напр., eTOM) и "бизнес-карт", напр. http://www.sap.com/solutions/businessmaps/index.epx.

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

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

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

2.   Отзывы ключевых клиентов о реализации процесса управления требованиями
3.   Показатели удовлетворенности клиентов
Для ключевого клиента требования отвратительные: его "хотелки" не будут реализованы сейчас же, как он хотел! Клиент этим не удовлетворён, ну и что, что он сменил "элитную" поддержку на самую дешёвую, и хочет сделать из АСУ склада систему SCADA. Да к тому же он же написал "сделайте, чтобы мне было хорошо, нажимаешь кнопку и ага!", чего уж непонятного, а этот глупый системный аналитик зачем-то расспрашивает...

4.   Соблюдение или превышение планов разработки требований, ограничений по ресурсам и качественных целей
План не соблюли! Хотели сделать за неделю 20 UC на 15 страниц, а пришлось 3 месяца делать 1500 требований и UC на 2000 страниц. Ну и что, что оказалось, что это - естественная сложность предметной области, помноженная на то, что решили делать подробное ТЗ для аутсорсеров...

5.   Контроль расползания требований, связанный с пропущенными требованиями и просачиванием "неформальных" требований в проект
Требования "расползлись", разработчики всеми правдами и неправдами добились того, что в SRS прошло их представление о том, что нужно Заказчикам. Ну и что, что именно благодаря этому продукт имел оглушительный успех.

По сумме 5 оценок имеем 0 из 10. При успешном продукте. Увольняем?

11
<...> Подскажите, пожалуйста, внутренний корпоративный портал является автоматизированной, информационной или автоматизированной информационной системой? Как можно это обосновать?<...>
IMHO, в большинстве случаев, это просто информационная система. Хранит много справочных данных, даёт к ним доступ. CMS. Ничего толком не считает и не автоматизирует.

как называется интерфейс руководителя на портале, в котором он может смотреть отчеты, статистику и т.п.? Может ли он называться АРМ?<...>
Отчёты о чём? Статистика чего? В большинстве случаев, "портал" - не СППР, не MIS. Если это АРМ, то что оно автоматизирует?
IMHO cкорее - "страница руководителя". А может, его и нет совсем?

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

12
Поясните, пожалуйста, а где здесь управление требованиями, причём тут agile и разработка систем?

---

"Было выделено определенное количество денег и 3 месяца для того, чтобы понять эффективность таких мер."
Т.е. не систему надо было создавать, а "рынок" человеческих душ исследовать.

Да, один из методов - создать прототип "сайта" для единомышленников.

Но IMHO - это изобретение велосипеда. Между тем, "велосипед" уже есть, нужно просто понять, сколько человек готовы на нём "кататься". Я бы взял какой-нибудь существующий церковный сайт, и в течение 2,5 мес. активно его "раскручивал" - баннеры на улицах и на сайтах, социальная реклама на ТВ, плакаты, брошюры. А затем, в течение оставшихся 0,5 мес. исследовал бы, как это отразилось на посещаемости сайта, а также изменение посещаемости церквей и общей соц. обстановки в районе рекламной компании среди её целевой аудитории и семей представителей этой целевой аудитории. Да и то, срок, конечно, маловат.

---

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

---

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

---

То, что было - судя по описанию, про управление проектом, а не про управление требованиями, и в сильно упрощённом виде. Оценка - не методикой (COCOMO II или IFPUG FPA, например), а киданием "костей". Ресурсов - предостаточно (4*10<3*18), ничего не резали. US между собой не связаны. Риски не прорабатывались. SCRUM-команда - одна. Работа - чистой воды каскад (каламбур?), спланировали и поехали. А где же обязательный в этом случае для agile батюшка on-site? :)

Самое интересное же с управлением требованиями IMHO происходит не при инициации и планировании, которые были разобраны, а при выполнении, контроле и закрытии, про которые здесь - ни слова. А как полетят к вам запросы, распоряжения, отвлечения людей на другие проекты, "напихивания" в текущую итерацию дополнительной функциональности против всех правил SCRUM, как выяснится, что 1-ю US нельзя реализовать раньше последней, как взыграют людские амбиции (каждый захочет показать богатство своего внутреннего мира) и встанет человеческий фактор в полный рост - всё с требованиями станет куда интереснее.

13
Связь класса с UC - вполне нормальная вещь, если понятно, для чего она нужна. Что делает ваш класс для UC? Он "аналитический" или относится к тому, что реально есть в коде? Он entity, boundary, control реализации, контейнер для всего этого, или что-то другое? Что вы хотите показать - что класс оперирует понятием, которое представляет собой класс, реализует весь UC, часть (сценарий? поток? триггер? проверку предусловия? постусловия?) UC? Что и до кого вы хотите донести этой связью, поймут ли вас?

Опять же, для чего вы используете UC? Они у вас "бизнес", "системные про взаимодействие с actor'ами" или "технические про алгоритмы системы"?

IMHO (но только IMHO)
- связь UC с аналитическими классами - это правильно, и её выстраивание - работа системного аналитика
- связь UC с отдельным классом реализации - это "мелковато", трудно поддерживать; для того, чтобы показать связь UC с кодом, лучше связывать UC с компонентами, и выстраивание такой связи - работа системного архитектора.

Про средства отображения такой связи - в Rational Rose, насколько я помню, была связь через UC Realization, в EA можно рисовать напрямую, но IMHO лучше стереотипировать и комментировать.

Чтобы отобразить в EA связь между UC и классом, UC и компонентом - достаточно
- перетащить оба элемента на одну диаграмму из дерева проекта; насколько я помню, между ними будут доступны связи dependency и trace, но их можно стереотипировать
- просто создать два элемента разных типов на одной диаграмме, переключая панели инструментов.

14
<...>Получается, что для разработки Help очень неплохо знать UML :-), а для написания ТЗ по ГОСТ 19 или 34 нужно уметь литературно редактировать текст??? Ниже оригинал объявления ...<...>

ЕСПД (которую, скорее всего, имели в виду)  - это не только ТЗ/ЧТЗ/ЭП/ТП, но и различные руководства. В т.ч. пользователя, администратора, системного программиста, программиста. Содержание у них - IMHO вполне здравое. И чтобы удобоваримо написать такое - нужно иметь порядок в голове и уметь принять сторону пользователя. Или, что страшнее, вжиться в роль администратора, а то и самого программиста. В общем, Станиславский отдыхает :). Так вот, надо рассказать этому пользователю-администратору-программисту, как ему удовлетворить его потребности при помощи существующей, великой, могучей, до конца не познанной системы, созданной, чтобы получить просветления, а не ради удовлетворения земных нужд. Причём лучше описать языком Пришвина и снабдить занимательными цветными картинками а-ля "Мурзилка".

Некоторые системы обладают большой сложностью, естественной и/или наведённой. Чтобы написать руководство по такой системе, нужно обладать высокой квалификацией. В т.ч. побывать в роли пользователя, администратора, разработчика. Что в этом удивительного? Хорошее руководство написать непросто. Особенно если кто-то в жизненном цикле ПО до тех. писателя сделал свою работу... не очень хорошо. Особенно - если системный аналитик и дизайнер UI.

15
Всем добрый вечер. Передо мной стоит задача формирования задания на разработку OLAP-отчета <...> нет четкого представления о содержимом этого документа<...>
Начните с того, на какие вопросы хочет получить ответ пользователь при помощи "OLAP-отчётов". Дальше, если нужны именно отчёты, согласовать с заказчиком список и содержание отчётов. Возможно "OLAP" и "ad-hoc" на самом деле не нужно, а нужно ввести пару параметров в условии фильтрации, вывести таблицу и строчку "итого". Это и опишите.

Если заказчику непременно хочется именно слова "OLAP" - предложите ему SAS или Business Objects в качестве средства реализации. Дорого. А "восстанавливать" UC существующих платформ для построения "OLAP" - дело неблагодарное. В т.ч. потому, что приведёт к написанию собственного велосипеда.

Страницы: 1 2 3 4 5 6 7 8 9 10 11 »