166

Обсуждение статей / Re: Analyst Days 2014, Мск, 24 мая

« : 14 Апреля 2014, 10:44:44 »

Сергей, первая тема мне тоже интересна. Но Вы легких путей не ищите?

Не очень понял про легкие пути.  Ну да ладно.

Переписка с программным комитетом шла как то сильно вяло и похоже моего доклада не будет на Analyst Days 2014.
Может расскажу на ЛАФ, может оформлю в виде семинара, если будет интерес к теме.

== Описание ===============================
Аннотация
Развитие успешных компаний происходит по следующему сценарию. После выхода на самоокупаемость компания начинает приносить неплохую прибыль. Число сотрудников растет. Но наступает момент, когда рост доходов не успевает за ростом расходов. Также, возможно наступление момента, когда каждый принятый сотрудник это не только плюс к расходам, но и минус к доходам.
В данном докладе я собираюсь провести анализ ситуации с разных точек зрения: теории Деминга; теории ограничений; жизненных циклов организации, предложенных Адизесом; психологии.
Для рядового сотрудника этот доклад будет полезен для распознания кризиса и выработке стратегий поведения в нелегкое для компании время.

Доклад достаточно сложен и желательно предварительное знакомство с материалами:
* Цель. Процесс непрерывного улучшения. Э. Гольдратт.
* Организация как система. Генри Р. Нив
* Управление жизненным циклом корпорации. Ицхак Адизес
* Доклад Игоря Ашманова «Кризис роста в ИТ» http://vimeo.com/26868924
* Когнитивные искажения
 http://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%BA%D0%BE%D0%B3%D0%BD%D0%B8%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D1%85_%D0%B8%D1%81%D0%BA%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9


Тезисы

• С кризисом управления сталкивается практически любая растущая компания.
• Ключ к решению не очевиден. Он контринтуитивен. И чтобы компания не пополнила кладбище неудачных стартапов нужна огромная удача. Или знания.
• Во время такого кризиса сотруднику очень просто «перегореть». Чтобы этого не произошло, нужно понимать причины происходящего.

167

Обсуждение статей / Re: Analyst Days 2014, Мск, 24 мая

« : 11 Апреля 2014, 14:31:32 »

я буду.
Только с темой не определился. То ли выбрать тему по анализу и оптимизации процессов организации, то ли по созданию спецификации требований к ПО... Первое потенциально полезнее, но в РФ практически неприменимо, второе проще и понятней. Что скажете коллеги?

168

Примеры / Re: UML диаграмма для сайта-магазина

« : 07 Апреля 2014, 14:25:23 »

Вам очень поможет введение понятия "Уровень ВИ".
* "авторизация" - уровень ниже уровня моря. И действительно, часто его лучше не включать. Это уровень программиста. Но. Авторизация может оказаться сильно не тривиальной и ее реализация может потребовать более 2 недель. В этом случае имеет смысл внести ее в реестр, как единицу планирования, а потом отдельно расписать.
* "добавить товар в корзину" - уровень моря, основная единица планирования (как правило).
* "Управление товаром в корзине" - обобщающий сценарий. Включает от 5 сценариев уровня моря

Предложение 1. На ДВИ лучше выносить ВИ одного уровня.
Предложение 2. Есть метод "Зачем <-> как". Один из вариантов - описываете бизнес идею сначала как результат, потом как набор действий, затем декомпозируете.
Например.
Книги по IT тематике стоят в США очень дорого. О, идея! В Индии полно дешевых репринтов. Наш интернет магазин будет позволять американцам дешево купить индийский репринт. Теперь нужно написать самый верхнеуровневый сценарий. Пишите.

Идея скорее всего не сработает, т.к. ЕМНИП ввоз в США книг очень сильно ограничен. Но для курсовой, сойдет.
Идея пересылать дешевые репринты в РФ (переводчики такие переводчики) тоже скорее всего не сработает, т.к. наши инженеры, "в булочную на такси не ездят книг по специальности не читают".

169

Примеры / Re: UML диаграмма для сайта-магазина

« : 04 Апреля 2014, 17:13:17 »

Сергей, а оплата — при получении в почтомате?
А, вижу. Мне удобней оплатить сразу, без налички)

Правильно. Мы с тобой разные, нам удобно по разному.
Поэтому естественно нужно поддержать множество вариантов оплаты: оплата с счета в банке, при помощи карты и Pidion1300 принесенный курьером, вебмани, пайпал, банковский счет (говорить карта в корне неверно), со своего счета на сайте (заработок при помощи партнерки) и т. д.
Но это лучше не в ВИ. это другая категория требований.


PS. Кстати, популярную некогда партнерку забыли. А это еще куча ВИ.

170

Примеры / Re: UML диаграмма для сайта-магазина

« : 04 Апреля 2014, 16:48:39 »

"Укажу" по части функционала.

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

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

Любить клиента нужно нежно.

+1
Регистрация действительно сильно снижает конверсию. Поэтому она нужна:
* Для накопительной системы баллов
* Отслеживания статусов заказов на сайте (иногда это удобно)
* Защиты от ботов, накручивающих/скручивающих отзывы и оценки
* и т.д.

А для покупателя удобнее всего "купить в один клик". Вот идеальный функционал с моей точки зрения для книжного магазина:
* На форуме uml2.ru увидел линк на книгу по анализу, нажал
* Попал на описание товара
* начал "купить"
* ввел номер телефона и подтвердил желание купить
* закрыл броузер
Все, моя работа с сайтом закончилась.
Через 1 минуту мне перезвонили, мы договорились, каким почтоматом я воспользуюсь (это стоит всего 50 руб, в отличии от курьерки http://www.ozon.ru/context/detail/id/20171026/), вечером, возвращаясь с работы сунул в терминал наличку и забрал заказ.
От заказа до получения - 2 часа.
При повторном заказе оператор спросит: "Вам в тот же почтомат?"

Тот, кто сделает это первым в своем секторе рынка, получит преимущество перед конкурентами.

171

Примеры / Re: UML диаграмма для сайта-магазина

« : 04 Апреля 2014, 15:21:39 »

Но это не "Просматривать страницы", это уже близко к кнопке "Получить совет эксперта". Т.е. ты полностью согласен с Гришей.

Для обеспечения полноты проще думать в терминах CRUDL. "Read page", но согласен, что на стадии выявления целей пользователя лучше думать в терминах целей.

Только вот какая петрушка получается, если думать в терминах целей, то цель одна "определиться, какими характеристиками должен обладать товар, чтобы он подошел мне". А вот ВИ будет много. ~20 штук я вижу навскидку, вероятно можно накопать еще.

172

Примеры / Re: UML диаграмма для сайта-магазина

« : 04 Апреля 2014, 13:30:09 »

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

Точно есть. Для обычного любителя роликов ABIC 3-5 является оптимумом. 6-9 будет катиться хуже. Поэтому есть цель: "Ознакомиться с советами эксперта по подбору роликовых коньков".

173

Примеры / Re: UML диаграмма для сайта-магазина

« : 04 Апреля 2014, 13:27:04 »

Преподаватель посоветовал начать с UML диаграммы.

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

Согласен с davvol почти по всем пунктам.
> В четвертых "Статические страницы" вообще не имеют отношения к ВИ.
Здесь не хватает действия. Должно быть:
CRUDL статических страниц (пять вариантов использования).
Причем RL для всех, включая покупателя, а CUD только для группы подготовки контента. Ну и в сложных случаях еще будет что то типа "Опубликовать/ вернуть на доработку страницу" для роли "Выпускающий редактор".

И да, название Ви имеет структуру: <Действие> <Объект действия> <Дополнения>.
При этом ошибкой будет указание в названии субъекта, производящего действие.

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

174

Вакансии / Re: Нужен Системный аналитик (Санкт-Петербург)

« : 02 Апреля 2014, 15:17:43 »

"master of everything is master of nothing"

Исходя из "спецодежда", рискну выдвинуть гипотезу.
А не входил в должностные обязанности:
* смена катриджей
* прокладка локальных сетей
* закупка бумаги
* и  т.д.

175

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 06 Марта 2014, 11:27:15 »

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

Для веб-сайтов сценарный подход тоже оказался неприменим.

По большей части, согласен с Григорием. Я на тренинге тоже рассказываю об ограничениях ВИ (в нотации Коберна).

ВИ очень удобны для учетных систем (склад, фильмотека, форум, социальная сеть). Т.е. для сайтов с функционалом они более чем применимы.

Случаи, когда они не очень удобны:
* Проекты по настройке систем.  Для разработки багтрекера ВИ прекрасно подходят, а для проекта по настройке багтрекера лучше использовать более высокоуровневые нотации [EPC|State|Data Flow|...] + [табличное описание объектов |XML|...] + ...
* Протоколы интеграции. Примитивный форум сейчас интегрируется с кучей систем. Т эту интеграцию лучше описывать другими нотациями.
* Игромеханика. С помощью ВИ сложно описать шахматы...

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

Так что, да: ВИ все еще занимают важную нищу, но ее размер сокращается.

176

Для всех / Re: Как облегчить жизнь с помощью UML (классификации)?

« : 24 Февраля 2014, 15:45:48 »

Посмотрите http://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D1%81%D0%B5%D1%82%D0%BD%D0%B0%D1%8F_%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F
Мне кажется, такой подход лучше решает вашу задачу.

177

Вакансии / Re: Москва, Системный аналитик (мобильные проекты)

« : 11 Февраля 2014, 12:38:48 »

-- ---

178

ПО Аналитика / Re: ELMA для управления бизнесом. FAQ, новые «фишки», уникальные возможности

« : 06 Февраля 2014, 11:34:41 »

KPI как раз и являются особой причиной вариации.  Слишком часто.

179

Тестирование / Re: Проверка алгоритма программистом

« : 27 Января 2014, 13:45:03 »

Тести́рование програ́ммного обеспе́чения — процесс исследования, испытания программного обеспечения (ПО) с целью получения информации о качестве продукта.

IMHO: "Очень распространенное заблуждение."
Опровержение данного заблуждения смотри: http://blog.shumoos.com/archives/281

PS. Если найдете ошибку в логическом построении - буду благодарен. Но пока никто не нашел.

180

Тестирование / Re: Проверка алгоритма программистом

« : 27 Января 2014, 10:50:17 »

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

И не пожалейте 45 минут, посмотрите: http://vimeo.com/13803733