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

×


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

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


Сообщения - Григорий Печенкин

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »
1156
В начальной фазе проекта возможно делается набросок видения, в котором уясняются проблемы, определяются основные функции системы, определяются границы системы, намечаются этапы работы, выделяются архитектурно значимые нефункциональные требования. неболее 10-15 % прецедентов детализируются и обсуждаются в ходе 2-х дневного семинара, устаканивается общее понимание проблем, целей всеми сторонами.

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

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

Идеи не рождаются на пустом месте. Если компания понимает, что может сделать "хорошее решение", значит, по крайней мере, известна проблема, которую нужно решить. Возможные варианты:
1) у компании есть опыт предоставления услуг в этой сфере;
2) знакомый врач за кружкой пива пожаловался, что без автоматизации он как без рук, и обозначил на салфетке проблему;
3) во время визита аналатика в местную поликлинику и ожидания в многочасовой очереди в его голове начали роиться мысли, как можно улучшить обслуживание с помощью информационной системы.

Варианты развития:
1) а значит, есть и некоторое представление о предметной области и более-менее налаженные контакты получения информации о процессах;
2) этот знакомый врач и является "проводником" к процессам - сначала нужно выудить как можно больше информации из него лично, и через него же попробовать выявить других заинтересованных лиц и наладить с ними контакты;
3) возможно, у ИС нет заинтересованных лиц, кроме томящихся в очереди граждан. А они вряд ли выступят спонсорами проекта.


Вообще говоря, если речь идёт о бюджетной поликлинике, то действовать нужно по каналам, имеющим слабое отношение к науке. :(
Если речь заходит о бюджетных деньгах, нужно найти того, кто ими распоряжается, и искать подходы к нему. Улучшение обслуживания населения в данном случае не является приоритетной задачей, а всего лишь необходимым "бумажным" условием получения заказа.

1158
После определения миссии и целей этого сообщества я, возможно, запишусь в сочувствующие. Или не запишусь. В зависимости от миссии. :)

1159
Этот движок называется MediaWiki и на нём работает Википедия.

Создать новую страницу можно следующими способами:
1) Добавив в адресной строке в корневому узлу название статьи после index.php/
2) Вбив название статьи в поиск.
3) Создав ссылку на статью с таким названием, сохранив статью и щёлкнув для перехода по созданной ссылке.

Во всех случаях, если страница не существует, система предлагает её создать.

А, точно! Я же с этим уже как-то бился, но найденный способ не отложился в моей дырявой памяти.

Спасибо за подсказку. Статью создал и ссылку на неё разместил.

1160
Промежуточные итоги работы.

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

Поэтому я потратил несколько часов на перевод страницы "Введение в UMA".
http://www.epfwiki.net/wikis/openuppt/base_concepts/guidances/concepts/introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg.html

При этом мне очень пригодилась статья по RUP (сюрприз, да? :) ), из которой я нагло позаимствовал некоторые термины:
http://www.interface.ru/home.asp?artId=1524


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

1161
Предлагаю результаты перевода фиксировать в вики: http://chernoviki.ru/index.php/OpenUP_Dictionary

Объясните тупому, как в chernoviki создать новую страницу? Хотел поместить туда перевод "Введение в UMA" и прикрутить к нему ссылку со страницы OpenUP_Dictionary. Я пытался сделать это через "руководство", но оно незаметно перебросило меня на wikimedia.org, с которого моя страница была немедленно удалена модератором с пометкой offtopic.

1162
Так это, наверное, указана, цель написания этого документа.
А раздел "Бизнес-требования", наверное, содержит требования к этому же документу.
Описание бизнес-проблем - проблемы, созданные в процессе его написания.

Вот такая, понимаш, рекурсия. :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

1167
Вообще, если хотите, давайте тему "Просчеты аналитика" вынесем в отдельный топик, и поделимся там "случаями из жизни".

Кстати, очень хорошее предложение! Я бы там с удовольствием проанализировал наши ошибки.
Сейчас же такую тему и заведу.

1168
Не получается так, что запуганные пользователи после этого затягивают согласование до бесконечности, и пытаются впихнуть в ТЗ все, что нужно и что не нужно, лишь бы, не дай бог, не осталось что-то за кадром, что может понадобиться, даже и чисто гипотетически?

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

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

1169
Сообщение об ошибке:

Fatal error: Cannot redeclare template_init() (previously declared in /home/uml2ru62/public_html/forum/Sources/Load.php(1702) : eval()'d code:32) in /home/uml2ru62/public_html/forum/Sources/Load.php(1702) : eval()'d code on line 30

1170
Конкретно - вот эта ветка:

http://www.uml2.ru/forum/index.php?topic=450.msg4892#new

Первый (пока единственный) пост содержит ссылку. При нажатии на неё - выбрасывает с форума. Только что проверил, воспроизводится.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »