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

×


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

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


Сообщения - Denis Beskov

2011
ГУ-ВШЭ с Билингвой рядом находятся, кстати )

Может мы всё-таки в 6 начнём, или как?

2012
В пятницу вечером 18-го мая пройдёт открытый семинар:
"Гибкие методологии разработки интернет-проектов"
http://blog.styleru.net/events/agiledev/

2013
А тут я тебя не понимаю, что проясняет нам картинка диаграммы взаимосвязей ЗЛ? Ну отразит она иерархию этих лиц, а дальше?
Это сугубо техническая, вспомогательная вещь - повторное использование для исключения дублирования. Чтобы не писать одинаковые цели Разным ЗЛ, даже если они у них действительно есть.

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

Как я понимаю, при формулировке целей носителями целей могут быть:
1. Принципал (Заинтересованное лицо, не принимающего непосредственного участьия в работе Системы)
2. Агент (ЗЛ, выполняющее поручения Принципала в рамках Системы)
3. Система

Причём СОБСТВЕННЫЕ цели системы - относятся сугубо к категориям термодинамики, кибернетики и теории систем, например "сохранение гомеостаза". Цели системы, о которых говорят обычно в контексте бизнес-моделирования и разработки систем - это цели НАНОСНЫЕ, СПРОЕЦИРОВАННЫЕ на систему цели Агентов и Принципалов (главным образом последних).

В общем случае я бы сказал так, что "Целью системы является удовлетворение интересов заинтересованных лиц". Тогда всё сводится к выработке целостного, сбалансированного набора интересов, которые переносятся на Систему.

У Агентов и Принципалов в контексте выполнения какой-то Деятельности есть определённые Интересы, Потребности. Вот о них и нужно говорить, при этом детализировать Деятельность диаграммами я смысла не вижу, максимум можно построить диаграмму взаимосвязей (обобщения/специализации) для ЗЛ.

2015
Здрасте. А у меня вопрос на засыпку: как выглядит в IDEF  процесс работы интернет-магазина??
Я уже заснул, спасибо.

2016
2 - это достаточно? ) Или это трюк такой, по выманиванию инфы, которую они в аське не раскрывают? ) Типа чтобы у них волосы на голове встали дыбом от того, насколько мы неправильно тут пишем, и рука сама потянулась точки расставить? ну тогда да, стоит попробовать.

2017
Дельный совет номер 1: Про управление проектами справшивать не на форумах по БД и SQL и не на форуме по анализу и проектированию систем, а на форумах по управлению проектами.

Из книжек я читал Йордона "Путь камикадзе" и "Управление сложными интернет-проектами" - здраво, интересно, но как-то несистемно и не методически. ДеМарко и Листера - "Человеческий фактор", "DEADLINE" - практически то же самое. На подходе медведи.

Ну а Брукс - просто обязательная классика.

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

2018
А что за название такое никто не знает? По приведенной Денисом ссылке понял, что "Вызови Айвана" это конкурс какой-то...?
"Айван" = iOne, журнал такой, в первом посте есть ссылка на него. Нет, не конкурс, просто такое название оригинальное.

2019
Вышла интересная книжка:

   
Вызови Айвана: непридуманные истории ИТ-внедрений

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

via lj user statecouncillor

2020
3. Слабая структурированность требований. Например, если мы добавляем некое требование и оно должно быть вставлено, как номер 5 среди уже написаных 10 требований, то автоматическая нумерация не произойдет
Пока не понял как решить, кроме переименования всех страниц в ручную.
Не понял, ты номера требованиям вручную что-ли задаёшь? Зачем?

2021
Достаточно спорно. Все от команды зависит. Кому то комфортно общаться через интернет, кому-то удобнее общаться в реале.
Саша, если у людей есть возможность общаться в реале и они общаются в реале, например в режиме "парного анализа", то какая нафиг разница, что у них там на экране открыто в режиме редактирования - MS Word/OpenOffice или браузер? Просто большинство вики лишено избыточного синтаксиса и автоматически поддерживает версионность.
Цитировать
Я - плохой аналитик. Я не умею ставить wiki.
Я сказал - "не может", а не "не умеет" ) Ты попробуй.

Цитировать
Можно ли запретить на wiki просмотр незарегистрированным пользователям и централизовать регистрацию? Или это делается другими способами. Как делал ты в своих проектах?
Хорошо, буду нудить. Большинство вики-систем являются открытыми системами. Открытая система - это значит, что её код доступен и его можно расширять. Для открытых систем обычно есть возможность написать модуль, плагин, патч и т.д. У популярных открытых систем обычно есть много полезных плагинов. Если плагин настолько полезен, что нужен почти всем, он попадает в ядро очередной версии системы. Поскольку, например, MediaWiki создавалась для Википедии, которая предполагает полную открытость контента, то там нем очевидного удобного разграничения прав доступа. Но тем не менее, в базовой поставке есть возможность ограничить видимость через конфигурационные файлы.

Если ты будешь пользоваться готовыми hosted-сервисами, такими, как, например, Zoho Wiki, то там разграничение доступа - естественная и удобная функция системы.

Подобрать вики-систему для установки у себя можно на WikiMatrix.org

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

Цитировать
Не стоит под инструменты пытаться подстраивать бизнес-процессы.
А кто пытался?

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

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

Цитировать
Если разворачивать wiki локально - то смысл ее теряется в значительной мере - специалистам проще собраться и поговорить.
Ты не прав. Собраться и поговорить - это одно. Создавать проектную дкоументцаию - это постоянный процесс.

Цитировать
Кроме того, в малых и средних фирмах будут ли специалисты, обесчивающие поддержку wiki  внутри сети, решать все проблемы с ней.
А какие с ней проблемы? Поставил и пользуйся. И то, я не вижу смысла ставить локально вики в малых компаниях, если нет задачи интеграции и модификации. Во-вторых, плох тот аналитик, который не может поставить вики :)

Цитировать
Крупной фирме проще будет купить doors, caliberRm, requisitePro - в которых также есть коллективные обсуждения требований, но при этом они лишены обозначенных в статье недостатков.
Саша, ты в крупной фирме работаешь? Почему тебя вообще крупные фирмы волнуют?

Посчитай, какое количество проектов, связанных с требованиями делается в мире/России, и какую долю из них составляют проекты больших компаний. У НИХ И ТАК ВСЁ НОРМАЛЬНО. ИЛИ НЕНОРМАЛЬНО, НО НИКОМУ ДО ЭТОГО НЕТ ДЕЛА.

Вот я сейчас вроде как в крупной, и ПО мы себе КАЗАЛОСЬ БЫ купить/поставить можем, и регламенты написаны - а процесс не внедрён, ан нет - если пересчитать потребное кол-во лицензий, получается немалая сумма, каждого надо обучать программе и т.д. и т.п. И на реальном проекте я использовал MediaWiki, и для локальных нужд мы купили и поставили Confluence (а не имеющийся SharePoint) - но уже не для УТ, а в качестве основы системы накопления знания. Потому что это - работает.

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

Цитировать
Я бы не стал повсеместно пропагандировать wiki к применению. wiki, на мой взгляд, будет востребована при разработке ПО с открытым кодом, когда сроки не стоят жестко.
Саша, я использовал и использовую wiki на реальных проектах. Мне 50-летний бизнес-аналитик сказал, что это удобно - что он смог сесть на выходных и вне этих корпоративных будничных запар спокойно и тихо расписать всё в онлайне. Причём тут сроки?

2023
Отличный материал в Открытых системах:

Wiki в коллективной разработке требований

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

2024
а почему никто не внедряет open-source?? может нам начать :)
Потому что мало компетенции и риски большие. Не хватает компетентных команд по поддержке ПО, а также бизнес-консультантов по его адаптации под российские условия. См. также: http://www.openenterprise.ru/

2025
Юра просил перенести на следующую неделю, 18 мая.