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

×


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

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


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

1726
Денис, годится. Время оставляем 7:30?
ага, дальше можно телефоном

1727
Ну я ж говорю - встретимся втроём, пива попьём ) Для остальных будет выглядеть как переноос.

1728
А по фамилиям можно? Товарищ BAS будет?
Нельзя, без согласия людей. Будет. Он первый Саша и есть.

1729
А почему нет?
Если коротко - потому что это абсурд. Только Мюнхгаузен мог вытащить сам себя из болота за волосы.

1730
Итак, буду я, Юра, Саша, Сергей, Саша.
Кто щё?

Заказываю столег.

Про "более достойная профессия" не понял, какой-то шовинизм.

1731
у него етсь альтернатива, не читать документ. Ознакомление с документом будут носить рекамендательный характер.
Но в любом случае документ должен быть максимально легким и в плане объема и в плане информации.
А почему вы вообще думаете, что проблемы неэффективности КОММУНИКАЦИЙ с помощью ДОКУМЕНТА могут быть решены с помощью ДОКУМЕНТА же?

1732
ArtemyY, мне кажется, есть нечто забавное в том, что чтобы вовлечь Заказчика в разработку 1-го документа (проектного - ТЗ), вы хотите сначала нагрузить его вторым (процессным).

1733
29-го сентября, в субботу, с 11 до 17
в здании московского офиса Luxoft состоится
II-я открытая конференция специалистов по качеству ПО

Тема: Постановка процессов контроля и обеспечения качества ПО

Формат: бесплатная, по регистрации

Секции конференции:
1. Понятие качества, метрики и практики обеспечения и контроля качества.
2. Организация и управление тестированием.
3. Внедрение автоматизации в тестировании.

Для участия необходимо обязательно зарегистрироваться с указанием ФИО по ссылке
(Выберите справа "Участвую").

Если вы хотите сделать доклад на конференции, пошлите письмо по адресу qa2conf@mail.ru.
Заявки на доклады принимаются до вечера воскресенья 23.09.
Тезисы докладов будут выложены в понедельник, 24-го сентября.

Организаторы:
Сергей Мартыненко, Денис Бесков-Доронин, Дмитрий Ручко, Александр Лобач

Адрес проведения семинара:
метро Октябрьское Поле, 1-й Волоколамский проезд, д.10, строение 3

Путь от метро:
первый вагон из центра, выход по подземному переходу направо, потом сразу налево, далее проходите около 50 метров вперед на остановку 105 и 800. Вам необходимы автобусы NN 105, 800, следующие до остановки "1-й Волоколамские проезд". Автобус останавливается напротив первой проходной.
Либо пешком от метро, идти минут 10.

1734
С точки зрения "обычного" менеджера, "самоуправляемая команда" несёт полную ответственность за разработку продукта: "Я даю вам полную свободу и умываю руки".
Это какой-то дезинформированный менеджер. В Agile команда несёт ответственность только за техническую часть. Фичи и целеполагание остаются на менеджере продукта.

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

1735
Мне кажется это один из "чисто теоретических" случаев.
Ничего теоретического - у самого несколько проектов такого характера на руках.

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

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

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

1736
ArtemyY, я возможно повторю то, что говорится в источниках, на которые ссылается Galogen, но тем не менее.

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

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

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

Заказчик должен быть не столько инициативный (иначе вы рискуете свалиться под грузом противоречивых идей и требований), сколько вовлечённый. Фактически на время проекта вам нужно слиться с заказчиком в единую команду, а не перебрасываться документами через стену электронной почты.

Если заказчиков уровня директоров/начальников отделов много, то нужно объяснять необходимость менеджера проекта со стороны Заказчика, который будет участвовать в согласовании и приоритезации требований с соотв. полномочиями, иначе вы останетесь один на один с Лебедем, Раком и Щукой и все эти животные останутся несчастными и во всём обвинят вас.

1737
Здравствуйте Все!

Пишу бакалаврскую по теме "Автоматизированная классификация информационных моделей на основе искусственных нейронных сетей". Модели представлены диаграммами классов и деятельности UML. Для обучения сетей мне нужно как минимум 100 диаграмм каждого вида где-нить достать, ибо времени в обрез.Буду исключительно признателен, если кто-нибудь может выслать мне пару-тройку моделей(с миру по нитке... :)). Oптимальный формат -- ХMI от MagicDraw, но и просто графическое представление моделей годится. Заранее благодарен за любую помощь.

Игорь
UML на вес - это что-то новенькое. Игорь, поищите файлы формата XMI в пиринговых сетях.

1738
Управление Проектом / Re: укрощение EPF Composer
« : 19 Сентября 2007, 18:24:40 »
... Вот собственно говоря и возможность использования EPF в команде разработчиков. Любой может открыть и посмотреть, что он должен делать на данном этапе проекта.
Любой может открыть что? Как он узнает, на каком этапе проект находится? Как он узнает свою роль в проекте? Как он узнает, что в этом проекте мы используем именно такой тип процесса, а не другой, описание которого лежит отдельно?

1739
Под "массовым продуктом" понимается ПО, рассчитанное на большой тираж, но с каждой инсталляцией работает небольшое количество пользователей с узкоспециализированными  потребностями или "публичные" системы (небольшое количество инсталляций, но большое количество - "масса" пользователей)?
Массовый продукт - продукт, рассчитанный на использование массами. Я же пишу в заголовке - "публичные веб-системы" - частный случай массового продукта.

Цитировать
Нотация - это только знаки, которыми описывается модель. Задача соотнесения  потребностей и идеи проекта часто упирается в модель автоматизируемой деятельности (пользователя системы). Т.е. проблема обычно в содержательном развертывнии идеи в модель, особенно для систем, которые не подпадают под традиционные модели типа "промышленное производство" или даже "предприятие". У Вас не так?
Кто бы спорил, что только знаки. Модель использования вполне ложится в use-case'ы. Но нужна не модель использования, а модель потребностей, принципы её формирования. Модель использования из неё сделать уже не так сложно, когда знаешь цели потребителя, его портрет и ожидания.

Вот тут есть цикл тематически близких публикаций, точка зрения маркетолога.

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

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

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

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

Т.е. вопрос вот в чём - есть ли какие-то нотации помимо MindMap, Excel для модели потребностей, методы её формирования и трансформации в пользовательские требования?