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


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

Через неделю получаем срочный запрос: поотключать все меню и проверки, и оставить только такую последовательность:
- терминал постоянно готов к проведению оплаты
- кассир проводит картой
- кассир вводит сумму
- терминал проводит транзакцию, печатает короткий чек покупателя
- терминал возвращается в состояние готовности к проведению следующей оплаты


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

Ещё один пример вспомнился.

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

С хостовыми протоколами обмена дело решилось быстро - спецификация известна, и свои наработки уже были. Но когда речь зашла о пользовательском интерфейсе, клиент (в лице начальника какого-то технического отдела, не помню названия) выкатил такое требование: "Чтобы всё было, как на старом терминале! Вплоть до отдельных строчек меню и способов навигации." Последнее требование было явной глупостью: на старых терминалов навигация в меню осуществлялась нажатием кнопки с номером соответствующего пункта, а у нас были специальные удобные кнопки прокрутки "вверх" и "вниз".

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

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

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

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

Ещё один пример вспомнился.

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

С хостовыми протоколами обмена дело решилось быстро - спецификация известна, и свои наработки уже были. Но когда речь зашла о пользовательском интерфейсе, клиент (в лице начальника какого-то технического отдела, не помню названия) выкатил такое требование: "Чтобы всё было, как на старом терминале! Вплоть до отдельных строчек меню и способов навигации." Последнее требование было явной глупостью: на старых терминалов навигация в меню осуществлялась нажатием кнопки с номером соответствующего пункта, а у нас были специальные удобные кнопки прокрутки "вверх" и "вниз".

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

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

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

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

Это не просчет. КАк сказали - так и сделали. Более высокий начальник все равно отослал бы Вас к кассирам, ведь он не вводит информацию, а им нужно сделать как им удобнее. На моем опыте так.

Это не просчет. КАк сказали - так и сделали. Более высокий начальник все равно отослал бы Вас к кассирам, ведь он не вводит информацию, а им нужно сделать как им удобнее. На моем опыте так.

Нет, не отослал бы. Интересы кассиров в данном случае не должны иметь высокого приоритета. Тем более что, как я сказал, предполагалась установка терминалов в новые точки.

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

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

Да, при разработке такой системы я бы тоже не сразу додумался про требования на пропускную способность (throughput). Хотя для телеком media gateway такое требование очевидно "is a must"
Спасибо, довольно познавательная история

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

Кстати, такого рода риски и способы их избежания хорошо рассматриваются в книжке Risk Management for IT Projects: How to Deal with Over 150 Issues and Risks.
http://www.amazon.com/Risk-Management-Projects-Issues-Risks/dp/0750682310/ref=sr_1_1/104-4804846-6876767?ie=UTF8&s=books&qid=1190894837&sr=8-1

<...>Интересы кассиров в данном случае не должны иметь высокого приоритета.

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

Тем более что, как я сказал, предполагалась установка терминалов в новые точки.

Старшими кассирами, которые будут учить новичков, поставили бы старых кассиров.

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

Менее удобный для Вас?

<...>скрыли часть полезных сервисных операций и разработали новые операции (хотя того же результата позволяли добиться "скрытые").

IMHO не того же.
Действие(10 сек)=результат
не равно
Действие(10 сек)+время на переучивание=результат .

Так что IMHO описанный случай действительно был ошибкой - при разработке Вы не учли требования одной из групп пользователей системы. Эту группу можно было бы попытаться переубедить, обеспечив её наиболее "влиятельным" представителям участие в прототипировании GUI, создании GUI "для себя". Но простое копирование старого GUI - более простое и дешёвое решение.

Оценка удобства GUI - вообще скользкий и очень субъективный вопрос.

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

Дело в том, что он НЕ БЫЛ начальником кассиров. Более того, он их, скорее всего, даже в глаза не видел.
Просто вместо того, чтобы предоставить нам документированные требования к интерфейсу или хотя бы потратить время на их обсуждение, он выбрал самый простой и дешёвый для себя способ: вот вам старый образец, и делайте всё, как здесь.

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

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

Менее удобный для Вас?

Объективно менее удобный. Эти кнопки "вверх-вниз" и система меню с прокруткой были разработаны именно для удобства пользователей. Представьте, что в Вашем мобильном телефоне нет кнопок прокрутки, а меню реализовано таким образом: чтобы выбрать первый пункт нужно нажать кнопку 1, второй пункт - кнопку 2 и т. д. Если пользователь уже привык к специальным кнопкам прокрутки, то такой подход его, скорее всего, будет раздражать.

Лично я специальных исследований, конечно, не проводил, но из опыта общения с пользователями вижу: назначение кнопок прокрутки интуитивно понятно, людям, впервые увидевшим терминал, не надо объяснять, как ими пользоваться. Может быть, потому что у большинства людей уже есть мобильные телефоны.

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

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

Так что IMHO описанный случай действительно был ошибкой - при разработке Вы не учли требования одной из групп пользователей системы. Эту группу можно было бы попытаться переубедить, обеспечив её наиболее "влиятельным" представителям участие в прототипировании GUI, создании GUI "для себя". Но простое копирование старого GUI - более простое и дешёвое решение.

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

Про throughput: антипримером хорошего нововведения следует признать новые терминалы для продажи карточек в Московском метро (в них карточка заглатывается внутрь автомата, которые её обрабатывает). В противовес старому - где карточку кассир рукой проводил по щели в аппарате.
В результате время обработки с секунды снизилось до 3-5 секунд.
Кассиры ругаются. Очереди стоят.