CustisWiki - Новые страницы [ru]

Курс молодого бойца для менеджеров (Ольга Павлова, SPMConf-2011)

2011-12-07T14:44:03Z

StasFomin:

Отдельные вопросы анатомии менеджера (Максим Вишнивецкий, SPMConf-2011)

2011-12-07T14:42:41Z

StasFomin: /* Примечания и отзывы */

Техническое интервью с человеческим лицом (Виктория Придатко, SPMConf-2011)

2011-12-07T14:38:00Z

StasFomin: /* Примечания и отзывы */

Как влияет специфика товара на интерфейс интернет-магазина (Екатерина Умнова, UXRussia-2011)

2011-12-05T17:49:04Z

StasFomin:

Как реклама обучает людей (Юрий Марин, WUD-2011)

2011-12-05T16:12:55Z

StasFomin: /* Примечания и отзывы */

WUD-2011: Заметки Стаса Фомина/Как реклама обучает людей

2011-12-05T16:12:17Z

StasFomin: Новая страница: «* Как реклама обучает людей (Юрий Марин, WUD-2011) Одной из близких к «юзабилити» областей (н...»

Как реклама обучает людей (Юрий Марин, WUD-2011)

Одной из близких к «юзабилити» областей (наряду с «дизайном», «продукт-менеджментом», «маркетингом») является «чистая реклама». И вот, доклад одного из коллег Вавилена Татарского, с девизом «Medium is the message» на слайдах, показывает аналогии, ведь и реклама и UX — это все про коммуникацию с пользователем, результаты которой фиг с два измеримы и чудовищно субъективны — т.е. да, вполне можно заставить пользователя считать более дружелюбным интерфейс, который вроде по метрикам у конкурентов не выигрывает.

Интерфейс — это контекст!
Usability — это RTB («Reason to believe»)
RTB обычно неочевиден, и контринтуитивен — жуткий интерфейс «Одноклассников», вероятно является RTB сложившейся аудитории, и трогать его видимо нельзя (хотя хочется убрать явные ужасы).

Яркие слайды, классический подход эффектнивного доклада — storytelling, «я расскажу вам пять историй», и все это истории, как решение рекламной задачи изменило мир. Случайно или нет — к лучшему.

Продвижение порошка Ariel под лозунгом «Casual Friday» пошатнуло господство унылого офисного дресс-кода.
Вредная и вкусная «bacon-end-eggs» → изобретение пройдохи-рекламиста, племянника Зигмунда Фрейда, продвигавшего это через «исследования британских ~~ученых~~ врачей».
Absolut Vodka — стильная прозрачная бутылка без этикетки
United colors of Benetton — продвижение через антивоенное движение, и разгоняющиеся права цветных.
Skittles — девиз «легальное сумашедствие без комплексов»: см. «Share the rainbow, taste the rainbow».

WUD-2011: Заметки Стаса Фомина

2011-12-05T16:04:14Z

StasFomin:

Когда пользователи далеко (Маргарита Титова, WUD-2011)

2011-12-05T14:55:11Z

StasFomin: /* Примечания и отзывы */

WUD-2011: Заметки Стаса Фомина/Когда пользователи далеко

2011-12-05T14:54:46Z

StasFomin:

Когда пользователи далеко (Маргарита Титова, WUD-2011)

Часто, когда продукт прост — например редизайн сайта-визитки, или выбор из пары вариантов промо-сайтов, юзабилити-тестирование не требует настоящих лабораторий, ай-трекингов, записей под камеру и т.п. — достаточно просто разослать анкеты где-то набранной аудитории (иногда среди посетителей предыдущей версии сайта, среди пользователей продукта), где оценить сайт цифрами по десятку осей («сложный ←→ простой», «консервативный ←→ инновационный», …) и даже в таком простом случае можно получить неожиданные результаты.

Задумался, имеет ли смысл оценить новый сайт-визитку нашей компании, среди нашей аудитории (внутри компании на него уже все посмотрели).

Update: Сделал опрос сразу после запуска сайта. Передал все собранные отзывы и статистику в отдел маркетинга.

Информационный стиль и редактура текста (Максим Ильяхов, WUD-2011)

2011-12-05T14:29:21Z

StasFomin:

Как должны выглядеть приложения для продуктивной работы? (Алексей Копылов, WUD-2011)

2011-12-05T14:24:50Z

StasFomin: /* Видео */

WUD-2011: Заметки Стаса Фомина/Как должны выглядеть приложения для продуктивной работы?

2011-12-05T14:22:48Z

StasFomin: Новая страница: «* Как должны выглядеть приложения для продуктивной работы? (Алексей Копылов, WUD-2011) Совер...»

Как должны выглядеть приложения для продуктивной работы? (Алексей Копылов, WUD-2011)

Совершенно разумный доклад, что все основной тренд юзабилити сконцентрирован на привлечении безмоглых хомячков («не заставляйте меня думать», «сделать поярче, рекламней, сексуальней»), что дико смертельно для приложений требующих постоянной, профессиональной работы.

Очевидные соображения, подкрепленные примерами интерфейсов — рулят спокойные, блеклые тона, минимум интерфейсных бантиков (градиентов, 3D-границ), палитры типа «кома».

Замечания из зала:

Дело не только в цветах и градиентах, в профессиональных приложениях требуются минимизировать весь нефункциональный мусор.
Современная проблема многих профессиональных приложений в том, что авторы, для привлечения более широкой аудитории, руководствуются парадигмой YAGNI («You are not gonna need it» + «Мы не заставим тебя думать»), и отключают кучу функционала позарез нужного, хоть не всей, но наиболее продвинутой части аудитории.

Аналитик и Тестировщик в одном лице - путь к качеству (Максим Цепков, SQA Days-10)

2011-12-05T10:46:15Z

VitaliyFilippov:

Аналитик и Тестировщик в одном лице – путь к качеству

Доклад Максима Цепкова на 10-й конференции SQA Days 2-3.12.2011
Презентация на slideshare
Статья опубликована на software-testing.ru, обсуждение на форуме

Что стоит знать проектировщикам интерфейсов об управлении продуктами (Денис Бесков, WUD-2011)

2011-11-30T19:26:00Z

StasFomin: /* Примечания и отзывы */

Дизайн для Windows Phone7 (Константин Кичинский, WUD-2011)

2011-11-30T19:22:52Z

StasFomin:

Как делать редизайн сайта? (Дмитрий Тарахно, UXRussia-2011)

2011-11-29T17:13:54Z

StasFomin:

Новая идеология поиска. Как говорим, так и ищем (Сергей Михайлов, UXRussia-2011)

2011-11-29T17:10:51Z

StasFomin:

Использование ай-трекера в дизайне модной одежды (Юлия Зверева, UXRussia-2011)

2011-11-29T17:07:34Z

StasFomin:

Интервью со спонсорами SQADays-10

2011-11-28T19:30:46Z

StasFomin: /* Интервью с Trading System и Execpro */

CUSTIS запускает новый проект для торговой сети O’STIN

2011-11-28T13:49:57Z

GalinaTsaturyan: Новая страница: «'''Пресс-релиз, 7 ноября 2011, Москва''' '''Компания CUSTIS разработала ПО «Розничный магазин Lite» д...»

Пресс-релиз, 7 ноября 2011, Москва

Компания CUSTIS разработала ПО «Розничный магазин Lite» для торговой сети O’STIN. Целью проекта было создание «облегченного» рабочего место кассира — системы, работающей без постоянной связи с учетной системой магазина. Новое решение позволяет отказаться от размещения сервера в каждом магазине, но благодаря интеграции продолжать вести полноценный учет продаж на сервере, размещенном в центральном офисе. Это особенно актуально для розничной сети с большим количеством малоформатных магазинов, поскольку позволяет существенно упростить выбор помещений и сократить затраты на автоматизацию.

Решение о старте проекта было принято партнерами в декабре 2010 г., и тогда же был разработан концептуальный проект системы. Новое решение должно было сократить затраты на автоматизацию магазинов без ущерба для процесса продаж. Планировалось снизить требования, предъявляемые к помещениям магазинов и каналам связи, а также обеспечить кроссплатформенную работу на Windows и Linux.

Специалисты CUSTIS и O’STIN совместно сформулировали требования к функционалу системы «Розничный магазин Lite». Разработчики CUSTIS приступили к ее созданию в январе 2011 г. Первый этап — «Оборудование, касса, продажи» — был завершен в мае 2011 г. Вторая часть работ — «Информационный обмен, настройка» — была выполнена к середине июля 2011 г.

В конце июля 2011 г. состоялось первое внедрение системы в магазине O’STIN в столичном ТЦ «Речной» на базе Windows XP. В начале августа был запущен «Розничный магазин Lite» под Linux в магазине O’STIN в TЦ «Гагаринский». В настоящее время система установлена в шести магазинах и готова к дальнейшему тиражированию.

В системе «Розничный магазин Lite» реализованы все стандартные функции POS-терминала и ряд специфических требований, обусловленных особенностями бизнеса заказчика, включая поддержку многочисленных и разнообразных промоакций O’STIN.

Кроссплатформенность. Система разработана на технологии Java. Это обеспечило независимость функционала и интерфейса от используемой операционной системы.

Эргономичный дизайн. Интерфейс программы позволяет работать как с сенсорным (touch screen) экраном, так и с использованием горячих клавиш на клавиатуре.

Работа с кассовым оборудованием и оплата товара. Система поддерживает протокол AzimutEpson (кассы ПРИМ-07К, ПРИМ-07ФКЗ, ПРИМ-08, ПРИМ-08в2 и др.) и позволяет работать с дисплеем покупателя, сканером штрих-кодов, считывателем магнитных карт и денежным ящиком. Корзину можно оплатить не только наличными или платежной картой, но и с помощью комбинации двух видов оплаты.

Выполнение кассовых операций. Система обеспечивает выполнение всех необходимых кассовых операций, таких как открытие смены, получение Х-отчета, инкассация и подкрепление средств в кассе, а также получение Z-отчета, необходимого для закрытия смены.

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

Информационный обмен с основной учетной системой магазина. В систему «Розничный магазин Lite» загружаются все необходимые справочники из ПО «Розничный магазин», установленного на сервере в центральном офисе. Они содержат информацию о товарах, пользователях, скидках и промоакциях. А в систему «Розничный магазин» передаются данные о продажах товара из ПО «Розничный магазин Lite»: оплаты, назначенные на корзину скидки, сторнирования.

Настройка системы «Розничный магазин Lite» для работы. Администратор заказчика может делать необходимую настройку системы и оборудования, заводить учетные записи новых пользователей и настраивать права доступа.

Работа с корзиной покупателя. Система «Розничный магазин Lite» позволяет выполнять различные действия со строками неоплаченной корзины с подтверждением цифровой подписью: изменение количества в строке, удаление строки, разделение строк. Система также дает возможность сторнирования корзины с подтверждением цифровой подписью пользователя с правами администратора.

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

«По отзывам непосредственных пользователей из разных магазинов O’STIN, система, разработанная компанией CUSTIS, оказалась достаточно удобной для работы, настройки и обслуживания, — рассказывает Константин Ранцан, начальник отдела информационных систем розничных магазинов. — Даже неопытные продавцы быстро осваиваются на новом рабочем месте, поскольку интерфейс программы прост и эргономичен, а справочная информация доступна и полна».

«Управляющие магазинами отмечают, что с внедрением новой системы ускорилось обслуживание покупателей благодаря устранению проблем, связанных с качеством каналов связи между рабочими местами кассиров и сервером базы данных, и, что особенно важно, аварийное отключение электричества в помещении больше не сопровождается авралом и потерей информации. Теперь достаточно обеспечить блоком бесперебойного питания одно рабочее место кассира — и сотрудники продолжают обслуживать покупателей и вносить данные о продажах в систему „Розничный магазин Lite“. Также хочется отметить, что обслуживание серверов улучшилось за счет их компактного сосредоточения в одном месте», — подытоживает Константин Ранцан.

О компании O’STIN

Компания O’STIN — крупная розничная сеть магазинов, предлагающих мужскую, женскую и молодежную одежду и аксессуары в стиле casual среднего ценового диапазона под торговыми марками O’STIN Casual, O’STIN Studio и O’STIN Woman. В России компания работает с 2003 г. Сеть включает около 350 магазинов по всей России, а также на Украине и в Казахстане.

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «CUSTIS запускает новый проект для торговой сети O’STIN»

Описание бизнес-процессов - waste? (Максим Цепков, SPM-2011)

2011-11-28T11:12:00Z

VitaliyFilippov:

Тезисы доклада Максима Цепкова на конференции SPM Conf 2011 26.11.2011
Презентация на slideshare

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

Поэтому в настоящее время тезис о необходимости полных описаний бизнес-процессов представляется спорным.

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

В этих условиях отказ от описаний и регламентов находится в согласии с принципами эффективного производства Lean и Agile.

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

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

Репликация: База Знаний «Заказных Информ Систем» → «Описание бизнес-процессов - waste? (Максим Цепков, SPM-2011)»

Блиц-доклады (WUD-2011)

2011-11-24T13:45:50Z

StasFomin: /* Голосовые и жестовые интерфейсы */

На рынке ERP есть место и для заказных разработок

2011-11-24T11:23:22Z

GalinaTsaturyan:

Владимир Рахтеенко: Генеральный директор CUSTIS

Интервью опубликовано в газете PC Week Review: ERP — системы, 18 ноября 2011

Нередко можно слышать, что заказная разработка ПО для предприятия менее выгодна, чем покупка готового бизнес-приложения (или ERP-системы), поскольку в готовом продукте затраты на его создание распределяются на множество покупателей, а при заказной разработке один клиент оплачивает ее полностью. С другой стороны, необходимость тщательной настройки «готового приложения» практически в каждом проекте внедрения свидетельствует о том, что, купив коммерческий пакет ПО, заказчик все равно вынужден заниматься его доработкой. Есть ли место для заказных разработок на высококонкурентном российском рынке ERP?
Об этом научный редактор PC Week/RE Сергей Свинарев беседует с генеральным директором компании CUSTIS Владимиром Рахтеенко.

PC Week: Каковы, на ваш взгляд, достоинства и недостатки этих двух моделей построения систем управления предприятием?

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

Нередко говорят о том, что уникальные процессы можно реализовать и в готовом коммерческом решении, используя его инструментальные средства. На таком пути заказчика ждет множество опасностей. Люди, занимающиеся доработкой, как правило, не представляют себе в полной мере ИТ-архитектуру готового продукта и поэтому могут породить множество проблем, которые начнут проявляться по мере усложнения системы. А усложнение — это обычная практика: у нас есть одно заказное приложение, функциональность которого по просьбе заказчика за шесть лет была расширена в 15 раз. Чтобы такая скорость была возможна, приложение не должно содержать ничего лишнего, нередко закладываемого вендором «на всякий случай». Мы с этой целью иногда прибегаем к так называемой «управляемой санации» своих приложений: к удалению по согласованию с заказчиком избыточных или отживших своё функций. Что же касается коммерческого продукта, то для реализации необходимой заказчику функциональности иногда необходимо вносить исправления на уровне ядра, но если это будет сделано, вендор снимает с себя ответственность за безошибочное функционирование своей системы.

PC Week: Как распределяются затраты на создание и сопровождение бизнес-приложения на протяжении всего его жизненного цикла в том и в другом случае?

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

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

PC Week: Насколько снижает объем необходимых доработок ПО рост числа так называемых отраслевых решений, построенных на базе коммерческих ERP-систем?

В. Р.: Как бы ни было хорошо отраслевое решение, если им пользуется лидер рынка, он все равно будет применять какие-то уникальные бизнес-процессы: иначе ему не удастся противостоять конкурентам. Такие компании будут использовать заказные разработки всегда. Не исключено, что эти разработки со временем перекочуют в коммерческое вертикальное решение и станут стандартными функциями, но произойдет это только лет через пять — десять. За это время лидеры продвинутся дальше, и им снова потребуются заказные разработки.

Мы видим, что в России ситуация именно такова. Спрос на подобные разработки настолько велик, что нам приходится отказываться от некоторых предложений, если мы понимаем, что рискуем потерять контроль за развитием своих проектов. В нашем сегменте, где потеря репутации гораздо страшнее, чем потеря дополнительного дохода, это очень важно.

PC Week: Чем должен руководствоваться заказчик, принимая решение, покупать ли ему тиражный продукт или заказывать разработку приложения? Кто ему может помочь в этом выборе?

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

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

PC Week: Какие дополнительные требования на ИТ-департамент заказчика накладывает развертывание у него заказного, а не тиражного ПО?

В. Р.: В организациях, с которыми CUSTIS имеет дело, в проектах участвуют три стороны: бизнес-подразделение, ИТ-департамент и мы. В этих компаниях ИТ-архитектура, как правило, согласована с бизнес-архитектурой. Она грамотно структурирована с учетом потребностей бизнеса. С такими заказчиками можно четко договориться, какие пределы гибкости разрабатываемого приложения мы можем обеспечить в рамках его архитектуры, описанной в бизнес-терминах и согласованной тремя сторонами. Пока мы остаемся в рамках договоренностей — бюджет и сроки принципиально не меняются. Как только новое понимание бизнеса приводит к пересмотру бизнес-архитектуры, то нужно будет изменить также и архитектуру ИС, что будет сопряжено с дополнительными затратами времени и денег. Не будем говорить о других компаниях, а они есть, где CIO больше думает не о потребностях предприятия, а о своих карьерных перспективах. В этом случае проект, сопряженный с заказной разработкой, вряд ли имеет шансы на успех.

PC Week: Спасибо за беседу.

Репликация: База Знаний «Заказных Информ Систем» → «На рынке ERP есть место и для заказных разработок»

Заказная разработка для госсектора

2011-11-23T16:55:47Z

GalinaTsaturyan:

Для ноябрьского обзора на сайте CNews ИТ в органах государственной власти 2011 Вадим Ференец подготовил материал на тему оффшорного программирования для заказчиков из госсектора. Интервью Владимира Рахтеенко вошло в его статьи Государство все больше доверяет оффшорным программистам и Как «оффшорному разработчику» организовать взаимодействие с заказчиком.

Владимир Рахтеенко: Генеральный директор CUSTIS

Тестирование сегодня представляет собой отдельную дисциплину

2011-11-23T15:13:00Z

GalinaTsaturyan:

Беспальчук Игорь: руководитель отдела технологического развития CUSTIS

В журнале «CIO (Компьютерра)», № 11 (ноябрь) 2011 — опубликован обзорный материал Артема Стародумова «Верификация ИС: жизнь после внедрения». Публикуем комментарий Игоря Беспальчука, который вошел в этот обзор.

Тестирование сегодня представляет собой отдельную дисциплину с богатой историей, собственными методами и инструментами. И эта дисциплина развивается с каждым годом. В этих условиях все сильнее проявляются тенденции к отделению тестирования ПО от разработки не только в области специализации, но и в области устройства общего рабочего процесса. Сначала появляется отдельный специалист по тестированию, чуть позже отдел тестирования, и наконец — тестирование отдается на аутсорсинг другой организации.

Важно понимать, что хотя подобное разделение повышает эффективность на отдельном участке (а именно — на участке тестирования), оно может негативно повлиять на эффективность процесса разработки продукта в целом. Представьте себе, что хирург и анестезиолог — это не два специалиста, совместно, бок о бок заботящиеся о пациенте, а два отдела, перевозящие пациента из одной палаты в другую в ходе операции, чтобы один мог вырезать опухоль, а другой — добавить немного анестетика! Эта метафора хорошо иллюстрирует, что, несмотря на введение отдельной специализации тестировщика, при организации процесса разработки жизненно важно, чтобы программный продукт не нужно было «перекидывать через стену» в отдел тестирования.

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

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

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

***

Репликация: База Знаний «Заказных Информ Систем» → «Тестирование сегодня представляет собой отдельную дисциплину»

Ритейл и ИТ: настоящее и будущее

2011-11-23T13:17:49Z

GalinaTsaturyan:

Дмитрий Майоров

заместитель руководителя направления «Торговые сети», CUSTIS

Опубликовано в газете PC Week Review: ИТ в торговле, 1 ноября 2011

Автор обзора редактор PC Week/RE Алексей Воронин собрал мнения представителей ИТ-компаний относительно актуальных задач автоматизации в розничной торговле. Мы публикуем ответы на предлагавшиеся вопросы нашего участника — заместителя руководителя направления «Торговые сети» компании CUSTIS Дмитрия Майорова.

PC Week: Оптимизация торговых запасов, отслеживание движения товаров — важнейшие составляющие современного торгового бизнеса. Как решаются сегодня эти проблемы? Какие решение/подходы выбирает бизнес — все большая интеграция ИТ на базе единой технологической платформы или использование специализированных продуктов?

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

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

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

PC Week: Решение управленческих задач — наиболее ответственный участок бизнеса, стоимость ошибок здесь наиболее высока. Как зарекомендовали себя на этом участке работы продукты класса BI? Насколько они эффективны?

Д. Майоров: Нужно сказать, что для решения управленческих задач компании далеко не всегда используют готовые BI-системы. Трудность задачи анализа заключается не только и не столько в специфических алгоритмах, сколько в подготовке полноценных выверенных данных для этого анализа. Нам приходилось создавать на заказ системы, условно говоря, класса BI — которые решали задачи создания консолидированной отчетности в рамках крупного торгового холдинга, интегрирующих колоссальные объемы информации из десятков операционных систем и формирующих отчетность в стандарте МСФО.

Много управленческих задач ставится и решается на уровне операционных (OLTP) систем. Чтобы ошибки с этого уровня не мигрировали наверх — на уровень принятия стратегических решений, необходимо уже тут обеспечивать полноту и достоверность данных для анализа.

PC Week: Насколько актуальна для крупного бизнеса связка «традиционный бизнес — интернет торговля»? Предлагают ли ИТ-поставщики специализированные решения?

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

А для тех бизнесов, где покупатель обязательно должен выбирать глазами, пощупать руками, примерить на себя и сравнить разные модели, — например, продажа одежды, обуви и т. п., — ситуация совсем не однозначна. Есть понимание, что интернет-рынок очень большой и западный опыт показывает, что на нем можно работать очень эффективно. У нас сейчас уже есть категория потребителей, которые покупают fashion-товары через интернет, но не у российских, а у зарубежных интернет-продавцов (китайских, американских). Их привлекает низкая цена товара, являющегося полным аналогом фирменного. Чрезвычайно низкая, даже с учетом доставки, цена вполне компенсирует риск того, что купленная одежда не подойдет: ее можно будет легко продать/обменять своему интернет-собрату.

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

Софт интернет-магазинов для продажи электроники, FMCG, продуктов питания хорошо развит и широко используется. А проблемы интернет-торговли товарами типа fashion лежат совсем не в плоскости ИТ, а в оптимальной организации специфических процессов логистики и продажи покупателю, который хочет иметь возможность выбора даже «на дому». Естественно, особенности такой торговли требуют соответствующей поддержки и от ИТ-решений.

PC Week: Актуальны для розницы программы лояльности покупателей? Существуют ли специфические проблемы с их ИТ-поддержкой?

Д. Майоров: Программы лояльности, конечно, очень актуальны для розницы. Естественно, что они завязаны на ИТ, поскольку связаны с хранением и анализом больших объемов информации. Сбор данных о платежеспособности и предпочтениях покупателей ведется различными способами. Одним из инструментов для этого являются ко-брендинговые карты, которые покупатели используют для покупок в различных сетях. Благодаря им продавцы различных товаров и услуг, не будучи конкурентами, получают возможность делать покупателю такие индивидуальные целевые предложения, от которых тому трудно отказаться.

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

PC Week: Одно из направлений развития ИТ в торговом бизнесе — специализированные системы для управления торговым залом, позволяющие «мониторить» кассовые аппараты, вплоть до оперативного получения статистики продаж. Насколько такие решения востребованы/актуальны?

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

PC Week: Мобильные терминалы — получат ли они в итоге широкое распространение на российском рынке в ближайшей перспективе?

Д. Майоров:Мобильный терминал как инструмент продавца в зале — безусловно, получит распространение. Он существенно облегчает и работу с товаром, и обслуживание покупателя. Бурное развитие потребительских мобильных устройств позволяет использовать в этом качестве даже не специализированное оборудование, а планшеты, смартфоны, КПК. Специальным должно быть их программное обеспечение.

***

Репликация: База Знаний «Заказных Информ Систем» → «Ритейл и ИТ: настоящее и будущее»

VLC

2011-11-23T08:52:14Z

StasFomin:

Кросс-платформенный меди-плейер и сервер медиа-вещания.

Преимущества:

бесплатен
не требует установки
содержит большой список интегрированных кодеков — его стоит держать только для того, чтобы иметь альтернативный способ взглянуть на медиафайл (когда стандартные, установленные в систему, кодеки, глючат).
куча гиковских возможностей тонкое управление просмотром с клавиатуры, в частности
- ускорение и замедление видео (клавиши «[» и «]»)
- удобная перемотка («Ctrl→», «Ctrl←», «Shift←», «Shift→»)
- подгонка субтитров и многое другое.

http://www.videolan.org/vlc/

Репликация: База Знаний «Заказных Информ Систем» → «VLC»

Практика «Design Thinking» (WUD-2011)

2011-11-23T08:38:39Z

StasFomin:

Планирование исследований. Первый подход к снаряду (Екатерина Умнова, WUD-2011)

2011-11-23T07:47:14Z

StasFomin: /* Видео */

Веб-аналитика для дизайна сайтов - как правильно построить облако тэгов. Применение статистики поиска по сайту (Анатолий Сергеев, UXRussia-2011)

2011-11-23T07:23:23Z

StasFomin:

Управление потребностями и оценка качества внедрения (Алексей Чумаков, UXRussia-2011)

2011-11-23T07:20:16Z

StasFomin: /* Примечания и отзывы */

Опыт международного юзабилити-тестирования (Евгения Гайсина, UXRussia-2011)

2011-11-21T19:53:49Z

StasFomin:

Тренды мобильного UX в Японии (Тойохиро Канаяма, UXRussia-2011)

2011-11-21T19:50:03Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://jp.linkedin.com/in/toyohirokanayama Тойохиро Канаяма] <blockquote> На примере неда...»

Инновации против лучших практик — конфликт или новые возможности? (Эрик Райс, UXRussia-2011)

2011-11-21T19:44:34Z

StasFomin:

От наброска до продукта - проектирование Windows Phone (UXRussia-2011, Megan Donahue)

2011-11-21T19:39:46Z

StasFomin: /* Примечания и отзывы */

Поисковые паттерны — дизайн для открытий (Питер Морвиль, UXRussia-2011)

2011-11-21T19:31:11Z

StasFomin: переименовал «Поисковые паттерны — дизайн дя открытий (Питер Морвиль, UXRussia-2011)» в «[[Поисковые паттерны — дизайн для открытий (Питер М...

ADD-2011 (Рецензии Стаса Фомина)

2011-11-19T17:51:17Z

StasFomin:

ADD-2011 (Рецензии Стаса Фомина)/Швейцарский нож аналитика - визуализируем логи одной строкой!

2011-11-18T23:42:26Z

StasFomin:

Будучи в программном комитете я долго сопротивлялся этому докладу, ибо изобретенный велосипед мне казался очень специфическим и редким. Но все равно он достоит внимания. Да и кто без греха? Вот и я делал поделки для визуализации коллективной работы, и доклады «швейцарским ножом» обзывал…

И в целом, я понимаю, что такое удобно сделанный под твою задачу инструмент, повышающий твою эффективность на порядки (хотя в зале указывали, что для визуализации жизни кластера давно есть крутое http://meta.rocksclusters.org/ganglia/ и возможно этот велосипед излишен). И что эффективный инструмент скорее всего будет не в парадигме «визивига», где надо тыкать кнопки, заполнять тыщи полей, и двигать мышью виджеты, а будет работать в парадигме «запрос—ответ» и «визуализации компактных требований», каковые удобно делать либо в командной строке, либо кратким предметным языком. Так вот, я просмотрел доклад в записи, которую же сам и смонтировал пользуясь изобретенным command-line видеоредактором, слушающим команды и спецификации для видеомонтажа.

Другое дело — все-таки очень ограничена предметная область, подлежащая визуализации этими тулами. Плоские графики с временной осью, серии или числовая ось... А преимущество «уанлайнера» несколько лукавое — «лайн» длиной в килобайт — это уже не лайн, line — это то, что можно набить за пару секунд, т.е. не больше пары десятков символов. А больше — это уже надо писать компактный dsl, который можно делать расширяемым, и таким же удобным и интерактивным — хороший, компактный DSL, без кучи «зюк и хрюк», скобок, кавычек двух типов, символов продолжения линий..., так вот, такой DSL, удобный и читаемый, ибо для читаемости можно и отступы использовать и переводы строк и пробелы — открыт в одном окне в редакторе, а в консоле происходит запуск тулы. Редактировать параметры и смотреть, как меняется картинка — гораздо быстрей и удобнее! И да — тут нет ограничений на отсутствия гуя — картинки то все равно надо смотреть!

В некотором смысле это проблема «уанлайн» подхода — сначала все кратко и красиво, а потом, с ростом задачи понимаешь, что к черту awk, лучше сразу perl, а то и python.

Забавно, что когда-то давно у нас и металогика алгоритмов учетных систем была «уанлайнером», с обвешанными семантикой символами «@!$», что знатно выносило мозг незнакомым с этой нотацией аналитикам, но потом это стало жать и самим разработчикам.

Т.е. если бы я начал решать эту задачу, это был бы python + matplotlib или pycairo (ну или другая библиотека визуализации), где все кишки бы я спрятал в отдельный модуль, а оставил лишь формулировку задачи компактной Python-функцией (что бы бы офигически и прозрачно расширяемо). Ну и если спектр графиков у меня получился бы совсем простым, я бы сделал простой DSL, то тоже редактируемый, с разбиением на строки, с максимальной читаемостью.

Я так и не придумал, чтобы мне можно было визуализировать этими тулами (полно всего просит визуализации, но там и графы и многомерность и динамика треба, на плоскость «время-серии» ничего не ложится), но вот что мне надо на самом деле — попрактиковаться в Haskell. И возможно для этого я и поковыряю исходники этих тулов, благо они опубликованы, да и писал их не какой-то ламер, а antilamer и эксперт по функциональному программированию.

Исследования в интернете или как собрать информацию о будущем? (Ярослав Карасев, UXRussia-2011)

2011-11-18T14:55:06Z

StasFomin:

Новое лицо персоны. Аналитика поведения для дизайна (Санжар Кеттебеков, UXRussia-2011)

2011-11-18T14:49:38Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://vkontakte.ru/id63596581 Санжар Кеттебеков] <blockquote> Одно из слабых звенье...»

Оранжерея знаний с MediaWiki

2011-11-16T19:52:19Z

GalinaTsaturyan:

Стас Фомин, заместитель директора по информационным технологиям компании CUSTIS.
«Оранжерея знаний с MediaWiki»^[1]

Управление знаниями—область достаточно молодая, с неясно очерченными границами, включающая как программную, так и социальную инженерию. Упоминания «knowledge management» в интернете и публикациях часто склоняются к крайним взглядам:

«Библиотекарский»: Знания — это то, что надо хранить целостно в некоторой библиотеке, куда нужно все занести, каждый элемент детально описать и каталогизировать, «составить карточки», далее выдавать по атрибутным запросам. Управление заключается в контроле над этим процессом. Это основа разного рода систем документооборота и прочих библиотек, выдаваемых за «базы знаний».
«Менеджерский»: «Библиотека» — это утопия, основной объем знаний всегда остается в головах сотрудников, поэтому надо занимать «проактивную» позицию, шевелить людей, сбивать их в сообщества, проводить собрания-семинары-конференции. Для этого нужны специально обученные люди, сводящие ищущих со знающими, занимающиеся «фасилитацией» общения и оргвопросами, — и все это представляет разновидность обычного организационного менеджмента. Типичный пример популярной книги от гуру Knowledge Management с такой позицией — «Learning to Fly: Practical Knowledge Management from Leading and Learning Organizations».

К сожалению, русский перевод-калька «Управление Знаниями» не совсем соответствует исходному понятию. «Управление» ближе к «контролю», а «management» тут скорее «забота и обеспечение». А ожидаемая цель «Knowledge Management-a» — не бесконечный затратный процесс с «ручным приводом, бурлаками и аниматорами»^[2], а обеспеченное инфраструктурой состояние организации, когда с минимальными накладными расходами знания фиксируются и распространяются по всем доступным каналам, где спрашивающие эффективно получают ответы и знакомятся с экспертами по своим темам.

При этом важно нащупать работающий компромисс между крайними точками разных граней:

Измерение «ПЗУ vs. ОЗУ» — все ли должно быть 100% формально зафиксировано, разложено по полочкам, прошито семантическими связями? К этому стремятся тяжелые системы управления требованиями. Или пусть все будет в головах, просто нужно больше общаться? Это Agile-подход.
Грань «Полнота или актуальность?» — надо ли стремиться к широте в ущерб актуальности, или бороться за целостность? «Обо всем, с ошибками» или «точно, но о малом»?
Субъективность «авторского взгляда» или выстраданные компромиссы?
Передача знаний — «PUSH vs. PULL» — «Толкать в людей» или дать им свободу «тянуть то, что им нужно»?
Синхронные или асинхронные процессы?

Получившаяся инфраструктура должна быть достаточно удобна для массового использования без существенной мотивации, ведь премиями или угрозой штрафов и увольнения пользователя можно заставить работать со сколь угодно неудобной системой, а тут ожидается «Счастья всем, даром, и пусть никто не уйдет обиженным» ©.

Откуда же ждать такие системы и инструменты? Ведь полно примеров неработающих дорогих систем: установленных и внедренных, которыми сотрудники так и не стали пользоваться. И возникает желание решить проблему менеджерскими методами, мотивировать сотрудников работать с системой — «премия наиболее активным пользователям портала»^[3]. Это опасно, ибо подменяет истинную мотивацию, и если «перестать платить за любовь» — все будет кончено. Тут очень уместна притча о пенсионере и хулиганах:

Хулиганы каждый день беспокоили одного старика, играли в футбол в его дворе, шумели и т.п. Рычагов воздействия у пенсионера никаких не было. Тогда он сказал, что эта игра ему нравится, и стал давать каждому гопнику по доллару «за работу» — каждую игру в его дворе. После такой недели он, с видимым сожалением (кризис!), урезал оплату до 50 центов. Еще через неделю — до 25. В следующий раз шпана уже не пришла — «нашел дураков вкалывать за копейки».

А как сделать, чтобы все это заработало без материального подогрева и смазки? Забегая вперед, скажем, что все наши решения, о которых мы расскажем, уже есть, проверены нашим опытом, и можно использовать совершенно бесплатно!

Например, open-source системы поддержки разработки гораздо гуманней, ведь в мире проектов с открытым кодом обычно нет материальной власти менеджеров над участниками и нельзя навязать жесткие процессы или инструменты. Более подробно см. книгу «Producing Open Source Software»

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

А именно, появились:

Закладки: Самая первая парадигма, сбор находок в безбрежном интернете. Затем они эволюционировали в сетевые закладки и даже в «закладки-цитаты» — Google Notebook, Evernote.
Блоги: Простейшая фиксация «ответов на не заданные вопросы». Минимальные «налоги» на регистрацию — не нужно классифицировать и актуализировать. Каждая запись — это только мнение автора на момент публикации.

Форумы: Место, где вопросы встречаются с ответами. Здесь уже есть попытка найти объективную истину или хотя бы собрать спектр мнений. Опять-таки, актуализировать ничего не требуется, представлен весь спектр мнений вокруг одного вопроса, а вычленение сухого остатка — обычно работа читателя.

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

Основным средством доступа стали:

Полнотекстовый поиск: Все научились «гуглить» и, даже если есть отличная документация, пользователям так быстрее найти ответы на свои конкретные вопросы.
Концепция RSS/Atom-каналов: Все изменения распространяются через ленты-каналы в формате RSS или Atom, пользователи подписываются на них и просматривают агрегированные потоки в специальных программах и сервисах. Колесико мыши оказалось не менее ценным изобретением, чем обычное колесо: с ним очень удобно читать-просматривать длинные информационные полосы-ленты.

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

Это будет антипод инженерного подхода типа «есть задача — разработать конструкцию для ее решения», после чего все это пустует, как заброшенные промздания. Тут скорее «агротехника» — высаживается правильная жизнеспособная рассада, обеспечивается поливка и прочая инфраструктура, а дальше нужно наблюдать за внутренними тенденциями, внося коррективы лишь по необходимости. И такое садоводство, по крайней мере в IT-компаниях, встречается все чаще, ударяясь в одну из двух крайностей:

Установить только какую-нибудь вики-систему, и ждать, когда она сама наполнится знаниями — Получилось в мировом масштабе «Википедии», значит и у нас все будет ОК. Но «Википедия» работает на мощности огромного числа авторов и редакторов и упор там сделан не на полноту, а на целостность и актуальность — удаление недостаточно важного, недостаточно объективного, не имеющего твердых доказательств и т.п. В масштабе компании так делать нельзя — надо «допустить» информацию разной степени актуальности и обновляющие её «дельты». Именно это и обеспечивает «поток» информации в противовес модели склада^[4]. И это как раз модель блогов и форумов. И дать персональное пространство для хранения личного опыта.
«Дать людям все! © к/ф. Фонтан». Установить и вики-систему, и блоги, и форумы, и закладки! Увы, в этом случае возникает конфликт использования — разные интерфейсы систем, невозможность переноса содержимого из-за несовместимых форматов разметки и концепций ссылок и т.п.

Что же делать? Хорошие новости! На самом деле все стандартные системы блогов/форумов/закладок созданы для агрессивной внешней интернет-среды, где нужно учитывать противодействие спаму, вандалам и идиотам. Даже вики-системы справляются только благодаря активному сообществу — заброшенная вики очень быстро превращается в ферму ссылок для SEO^[5]-спаммеров.

Но внутри компании, в интранете — доверенная среда, где, если обнаруживается спаммер/вандал/идиот — это радость для HR службы: ему можно вправить мозги или уволить, пока он не наломал серьезных дров. В компании можно создать не просто «сад знаний», а настоящую оранжерею на базе мощной вики-системы, что невозможно в Большом Интернете — ведь там мало кто согласится вести блог, который сможет испортить любой прохожий. В компании становятся осмысленными даже микроблоги. Ведь твит^[6] в Интернете о том, что какой-то «sdk756f разобрался с технологией XXX» несет практически нулевую информацию. Ну разве что эта технология настолько редка и важна для вас, что вы попробуете с ним связаться. Совсем другое дело, если это заметка от «Васи из соседнего отдела» — теперь, когда вы нашли этот микропост-маркер, вы знаете, с кем эту тему можно обсудить, а сделать запись Васе ничего не стоило!

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

Внимательно присмотревшись, можно даже убрать концептуальный раздел между блогами и форумами — это на самом деле одно и то же, вопрос только в представлении и классификации. В обоих случаях это список блоков «тема, сообщение, обсуждение». Но блоги — это в первую очередь хронологическая лента сообщений от отдельного автора, а форум — это «самое свежее от всех», т.е. только что опубликованные темы, либо те, где уже кипит обсуждение. Технически это может быть единая система, просто имеющая два представления — «Блоги» и «Форумы» — и не возникает никакого ментального барьера, куда писать сотруднику, когда у него возникла мысль или вопрос, или то и другое одновременно.

Да, информация в блогах и форумах может стать:

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

И все это не теоретические соображения, а реальный опыт: именно такое расширение «ВикиЛоги» MediaWiki мы реализовали в нашей компании. Широк спектр обсуждаемых в компании тем — от политических и организационных новостей в блоге генерального директора, до жарких технологических споров с сотнями комментариев, в которых, если и не рождается истина, то, по крайней мере, составляется резюме возможных проблем и решений, а участники определяются с позицией. Выросла и вовлеченность сотрудников в процесс наполнения базы знаний.

Да, «блогосфера» взлетела не сразу, ведь не все сотрудники «продвинутые интернетчики», сначала пришлось показывать пример, вести «блог команды», «политические и инфаструктурные новости», «обзоры книг» — а затем — все полетело само! Начался активный обмен опытом, рефлексия над практиками и культурой компании, и т.п.

Некоторое представление об этом взрывном росте, можно получить с помощью этого инфографического ролика:

(Сделан с помощью ShowTeamWork).

Иногда еще встречается мнение, что вики-системы — это какие-то унылые поделки для программистов и прочих гиков, у которых нет денег на «что-то серьезное от солидного вендора». Это не так. Добротные вики-системы являются отличным компромиссом между эффективностью фиксации и актуализации знаний и их простотой и доступностью для всех категорий сотрудников. Важно запомнить: правильная вики-система — это не когда «все плоским текстом», а когда «быстро-быстро»^[7]. Т.е. можно грузить сколь угодно «богатый» контент — фото, видео, скринкасты, звук, диаграммы, майндмапы, статьи и книги в PDF/DjVu и, на худой конец, просто документы в офисных форматах.

А мощность самой концепции позволяет использовать вики практически для всего, хоть как-то попадающего в категории «база знаний» и «публикация материалов». Единственная уязвимость веб-контента — это неудобство при выполнении постраничной верстки для бумажной печати (которая, впрочем, становится все менее ценной). Более подробно все это разобрано в статье «MediaWiki — Серебряная пуля или швейцарский нож?»^[8]

Осталось поговорить о «Закладках» или, вернее, о «Вырезках» — ведь нечто схожее аналитики доинтернетной эры, пользуясь ножницами и кнопками, вытворяли с газетами. Они очень важны при Knowledge Miningе во внешнем интернете — ведь сейчас пользователь компьютера совсем не похож на «оператора ЭВМ», сидящего перед клавиатурой с 10:00 до 18:00. Мы постоянно «серфим» в интернете — ноутбуки и прочие девайсы сделали возможным чтение/просмотр информационных потоков в любом месте и положении, на улице и в туалете, стоя, лежа и сидя. Чисто физически приходится разделять режимы «Читателя» и «Аналитика-Реализатора»: заметив интересное, выделить важное, чтобы позже, сидя за столом, проанализировать и применить. Или обратить внимание экспертов или ответственных товарищей на что-то важное. Например, можно собрать ключевые цитаты из книги или статьи, чтобы потом написать рецензию. Или добавить ссылки-заметки на плюсы и минусы технологии, а затем заняться их реальной проверкой. Или отметить активность конкурентов, чтобы отдел маркетинга сделал правильные выводы.

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

Как вы уже, наверное, догадались, мы сделали свой сервис «ВикиЗакладки» на базе MediaWiki. Там можно завести неограниченное число «каналов закладок» — статей, где будут размещаться ссылки и вырезки. Для добавления закладки и вырезки нужно всего лишь выделить интересное в броузере и нажать кнопку букмарклета. Сервис работает во всех броузерах без инсталляции. Закладки можно вести в одиночку и коллективно («Сводки аналитического отдела по рыночному сектору X»), разделять по темам («Книга YYY») или перемешивать. Закладки автоматически сортируются в хронологическом порядке по разделам статьи, но хранить их вечно не обязательно. Лучше время от времени разбирать их: на основе каких-то писать новые или дополнять существующие статьи базы знаний, какие-то превращать в реализованные проекты. А что-то вскоре потеряет важность и эти закладки можно будет стереть. Все это делается быстро, ибо интерфейс самый эффективный — редактирование теста: copy-paste, перенос и удаление блоков.

Чтобы сделать «pull»-интерфейс, нужно уметь превращать в RSS-поток любое изменение, будь то свежий пост в блоге, новая статья, закладка, редактирование и другие гибко задаваемые события. И сделать удобной подписку на эти каналы, с централизованной агрегацией и веб-интерфейсом, чтобы можно было их просматривать откуда угодно, быстро и удобно, — короче, сделать внутри-корпоративный «Google Reader». Мы сделали и его — это система «FeedOnFeeds»!

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

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

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

Общеизвестен софизм Горгия: «Ничто не существует; если и существует, то оно не познаваемо; если оно и познаваемо, то непередаваемо». И трудно с ним не согласится: просто диву даешься, насколько люди склонны пропускать или неверно трактовать элементарные регламенты!

Но выход есть! Как прочность программного обеспечения увеличивается при покрытии кода проверочными тестами, так и надежность передачи знаний увеличится, если сопроводить ее «автоматическими проверочными тестами на понимание».

Система тестов с выбором вариантов — классический подход GMAT, GRE, ЕГЭ и даже тренажера ПДД. При всей критике, это очень дешево и эффективно. Ведь критикуют именно систему оценивания, с линейной зависимостью от числа баллов. А достаточно просто отсекать «тяжелые случаи», тугодумов или лентяев, и дополнять оценку по другим критериям. И очень эффективно использовать систему тестов в роли тренажера-симулятора^[9].

Но неужели нужна специальная система для редактирования тестов и выполнения проверок? Нет! Мы и это реализовали как расширение MediaWiki «MediaWikiQuizzer», т.е. тесты — это те же вики-статьи, а все функции быстрой и эффективной публикации под рукой. Можно делать сколь угодно сложные композиции новых тестов из уже существующих, использовать вариации одной и той же тестовой базы — выдавать случайные блоки по N вопросов, перетасовывать варианты, включать режим экзамена или обучения и т.п.

Тесты могут работать как в проверочном режиме, так и в обучающем: «вы выбрали не тот вариант, правильно так-то и потому-то». Если использовать MediaWiki для публикации курсов и MediaWikiQuizzer-тесты, то никакие «профессиональные системы e-learningа», скорее всего, не потребуются. Ведь остальной бюрократический функционал (учет студентов, оценок), предлагаемый этими системами, в организации разумного размера и с нормальными отношениями попросту не нужен.

И еще об обучении: Mediawiki можно использовать не только в режиме «человек-компьютер», но и для передачи знаний «человек-человек» — а именно, для семинаров и курсов со слайдами.

Широко известны проблемы правильных слайдов:

Автор пытается угнаться за двумя зайцами: подготовить слайд-презентацию, которую можно одновременно и показывать во время доклада, и раздавать для самостоятельного чтения. Из-за этого получаются страшные «слайдоменты» — гибриды «слайдов и документов»^[10], совершенно бессмысленные для выступления.
Авторы не могут работать совместно: быстро параллельно редактировать слайды.
Нет богатых возможностей семантической подготовки материала, таких как автоматическое построение графов и диаграмм, раскраски исходных кодов и т.п. — все это приходится делать вручную и повторять при изменении материала.
Хочется включать мультимедиа контент на современном уровне — видеоролики, майднмапы, анимацию и т.п.
Сложно делать целостный reusable контент — например, составлять презентации для разных аудиторий из одних и тех же блоков слайдов.

Мы решили и эту задачу, реализовав MediaWiki-расширение «S5SlideShow», позволяющее выпускать «гибридные» статьи, пригодные и для чтения, и для показа в виде слайдов.

К сожалению, объем бумажной статьи ограничен и «за бортом» осталось много наших MediaWiki-изобретений: календарь с системой регистрации, совместное редактирование изображений и много другое.

Но для читателя важны два момента:

MediaWiki «расцветает» в «оранжерее» корпоративного интранета, огражденная от вандалов и спаммеров, и на ней можно удобно реализовать все привычное для обмена знаниями: блоги, форумы, закладки, слайды, проверочные тесты.
Мы не просто «делимся опытом», а выложили все наши доработки в open-source и предлагаем всем заинтересовавшимся совершенно бесплатно установить все это у себя: просто зайдите по адресу http://wiki.4intra.net/Mediawiki4Intranet.

Репликация: База Знаний «Заказных Информ Систем» → «Оранжерея знаний с MediaWiki»

↑ Опубликовано в Intellegent Enterprise, №10 (232), октябрь 2011 года
↑ По опыту бизнес-форума по управлению знаниями, самый актуальный вопрос: «как заставить людей делиться знаниями», а «материальная мотивация за активность» — самый распространенный ответ.
↑ Более подробно см. статью и видеовыступления на конференции «Knowledge Management: От Склада к Потоку» http://lib.custis.ru/Knowledge-management-from-store-to-flow
↑ Search Engine Optimization, создатели мусорных сайтов для манипуляции результатами ведущих поисковых систем
↑ Пост в системе микроблогов типа http://twitter.com, http://juick.com и подобных им
↑ «Wiki-Wiki» — это на гавайском означает «быстро-быстро».
↑ См. http://lib.custis.ru/Mediawiki-silver-bullet-or-swiss-army-knife. Опубликована с сокращениями в «Открытых системах», апрель 2009. Также с этим названием была серия выступлений на конференциях по программной инженерии.
↑ Призываю всех, кто честно получал водительские права вспомнить изучение билетов с картинками-ситуациями и вариантами выбора, и автоматические программы-тренажеры по проверке этих билетов
↑ Понятие, введенное Алексеем Каптеревым в известной презентации «Смерть через Powerpoint»

ADD 2010: Отчет Глеба Тарасова

2011-11-16T18:41:03Z

StasFomin:

ADD 2010: Отчет Глеба Тарасова/Как прекратить писать

2011-11-16T18:39:59Z

StasFomin: Новая страница: «;Как прекратить писать (Андрей Аксенов на ADD-2010) Андрей Аксенов в своем стиле рассказыва...»

Как прекратить писать (Андрей Аксенов на ADD-2010)

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

ADD 2010: Отчет Глеба Тарасова/Как стать героем

2011-11-16T18:38:52Z

StasFomin: Новая страница: «;Как стать героем (Яков Сироткин на ADD-2010) Доклад был глубоко рефлексивный, интересный, н...»

Как стать героем (Яков Сироткин на ADD-2010)

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

ADD 2010: Отчет Глеба Тарасова/Программирование под iPhone

2011-11-16T18:37:49Z

StasFomin: Новая страница: «;Как начать разрабатывать для iPhone (Никита Фролов на ADD-2010) Здесь полдоклада я негодовал в...»

Как начать разрабатывать для iPhone (Никита Фролов на ADD-2010)

Здесь полдоклада я негодовал в твиттере. Суровый рыбинский программист (видевший мак впервые в жизни после того, как его заставили писать под iPhone) с черно-белой нокией и пользующийся на Маке файрфоксом рассказывал, как это ужасно и неудобно — писать на Objective-C.

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

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

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

ADD 2010: Отчет Глеба Тарасова/С++0x

2011-11-16T18:35:55Z

StasFomin: Новая страница: «;C++0x (Елена Сагалаева на ADD-2010) Так как многопоточное программирование было очень длинны...»

C++0x (Елена Сагалаева на ADD-2010)

Так как многопоточное программирование было очень длинным докладом, решил забежать на Алену про новый стандарт C++. Сейчас все пишут на стандарте, написанном в 1998 году. Это о многом говорит. Новый должен был появиться в 200x году, но появится не раньше 2011го. Основная цель — уменьшить порог входа, сделать удобнее для написания системных библиотек, оставить по максимуму обратную совместимость.

Что будет:

Теперь можно будет писать List<List<int>> (раньше две угловые скобки нельзя было писать подряд =)).
auto (var в С#).
Инициализация списков в фигурных скобках.
Лямбды. Причем можно замыкать и по ссылке, и по значению. Синтаксис кривоват.
Диагностика по словам докладчика все такая же.

ADD 2010: Отчет Глеба Тарасова/SQL vs NoSQL

2011-11-16T18:34:48Z

StasFomin: Новая страница: «По горячим следам был круглый стол по БД. NoSQL базы бывают двух видов. * ''Column-oriented''. В них фишк...»

По горячим следам был круглый стол по БД. NoSQL базы бывают двух видов.

Column-oriented. В них фишка в том, что схема не фиксирована, и в каждой строке могут быть разные поля.
А есть базы с хорошей scalability (автоматический шардинг и др. фишки).

Причем кто из них кто — непонятно. Вроде как действительно быстро работает только MongoDB. Хотя в Facebook, Twitter работает Cassandra.

ADD 2010: Отчет Глеба Тарасова/Apache Hadoop

2011-11-16T18:33:43Z

StasFomin: Новая страница: «;Apache Hadoop (Владимир Климонтович на ADD-2010) Сначала было введение про <tt>MapReduce</tt>. Потом был р...»

Apache Hadoop (Владимир Климонтович на ADD-2010)

Сначала было введение про MapReduce. Потом был рассказ как оно в Apache Hadoop работает. Работает не очень стабильно, подглючивает. Так что пользоваться этим можно только в вебе. Еще есть интересный проект по трансляции SQL в MapReduce запросы — Apache Hive. И свой язык запросов в Apache Pig. Так как после MapReduce результаты логично хранить в базах «ключ-значение», то есть еще и БД HBase.

ADD 2010: Отчет Глеба Тарасова/Статический анализ в С++

2011-11-16T18:32:39Z

StasFomin: Новая страница: «;Устаревание стандартов кодирования и статический анализ кода (Андрей Карпов на ADD-2010) В...»

Устаревание стандартов кодирования и статический анализ кода (Андрей Карпов на ADD-2010)

Вывод один — бедные сиплюсплюсники. У них столько проблем, что даже статическими анализаторами тут не поможешь. Еще у них нет решарпера, жалко их.

ADD 2010: Отчет Глеба Тарасова/Алена C++ про искусственный интеллект в играх

2011-11-16T18:31:00Z

StasFomin: Новая страница: «;Искусственный интеллект в играх (Елена Сагалаева на ADD-2010) Как и ожидалось, практически ...»

Искусственный интеллект в играх (Елена Сагалаева на ADD-2010)

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

Интересные фишечки про вероятность с состояниями, подкрутку поведения для более интересной игры и т. п.

Про алгоритмы было только в поисках пути, причем вся информация примерно как в Википедии.

ADD 2010: Отчет Глеба Тарасова/Леша и Коля

2011-11-16T18:29:35Z

StasFomin: Новая страница: «;[[Предупреждение ошибок программиста с помощью статического анализа кода и доменной моде...»

Предупреждение ошибок программиста с помощью статического анализа кода и доменной модели (Алексей Алексеев и Николай Гребнев на ADD-2010)

По сравнению с первым прогоном на нашей демонстрации прогресс был просто огромный. Доклад прошел практически без накладок. Единственное, что Леша забыл рассказать, как структура Крипке разворачивается в бесконечное дерево, поэтому дальше народ немного перестал понимать суть, но те кто понял — прониклись. Недостатком было, что рассказывали про абстрактный «наш фреймворк» без ссылок, где он выложен в OpenSource. К SECR-у если его уже не выложим, будет совсем глупо.