Comments 11
ИМХО формы делались и принимались в работу высокой комиссией с глубоким пофигизмом к тому, как этим будут пользоваться граждане.
Отсюда и нестыковки, и возникающие проблемы, решаемые (как многое другое) в регистратуре :))
Вы ничего не понимаете в апельсинах. А точнее, в проектировании государственных информационных систем. Есть как минимум два паттерна проектирования пользовательских интерфейсов — через use cases и "типа по ГОСТ". Идеальный разработчик умеет комбинировать эти два паттерна в одном документе и получать годный интерфейс, все остальные вынуждены делать так как записано и утверждено синими печатями в ТЗ. Есть прямая и глубокая связь между ТЗ и ПиМИ (программой и методикой испытаний), собственно тест-кейсы из ПиМИ по сути копируют пункты функциональной части ТЗ. И разработчик рад бы написать человеческим, а не казенным языком, но не может, потому что любое несовпадение с текстом в ТЗ грозит неприемкой системы. А если принять во внимание, что этап проектирования и написания ТЗ очень часто является предметом другого госконтракта, и принять во внисание, что на этапе проектирования подрядчик может осознанно вносить в ТЗ закладки, которые помогут выиграть конкурс на разработку ему, а не его конкуренту, то становится еще веселее.
Но не переживайте, все обязательно исправят, на следующем этапе, это вечное колесо сансары, ровно так же, как смена весенних бордюров на осенние.
Все-таки здоровая конкуренция на рынке должна быть, иначе получим то, что имеем сейчас.
Все беды начинают исходить из ТЗ. ТЗ, как правило, пишет Исполнитель, а Заказчик, в зависимости от его адекватности, подписывает или отправляет на доработку.
Исполнитель может досконально не знать предметку Заказчика, поэтому он буквально ночует у Заказчика (повторюсь, если Заказчик адекватен) и выискивает все нюансы.
Всё, ТЗ подписано, деньги за него уплачены.
Исполнитель четко по ТЗ разрабатывает ПО.
Затем наступает этап ПиМИ. А там написано допустим следующее (утрирую, но формат условия примерно такой):
-при нажатии на кнопку, должно появиться окно с надписью в верхнем левом углу «Здравствуйте»;
если надпись будет другая, например «Привет», то ПиМИ не подпишут.
Далее заключается договор на тех. поддержку — это тоже деньги.
В рамках этого договора, Исполнитель исправляет ошибки, но, как правило, не добавляет новые фичи (это уже отдельный договор).
То что вы описали, не будет расценено Исполнителем как «ошибки», это будут «доработки» и Заказчик за них должен будет заплатить. А ему это надо? :)
Вот как то так.
— Но людям будет неудобно и непонятно, давайте напишем
Вызов принят. Вызовы до 13.00 — обслуживаются в этот же день, вызовы после 13.00 — на следующий
А Заказчик ему такой:
— Нет, это несолидно! Я хочу
Обращаем Ваше внимание, что в случае оформления вызова после 13:00, обслуживание вызова может быть назначено медицинской организацией на завтрашний день
, а если вы хотите писать по-другому, то нам с вами не по пути, ТЗ не подписываем, сроки срываем, платите пеню.
Обращаем Ваше внимание, что в случае оформления вызова после 13:00, обслуживание вызова может быть назначено медицинской организацией на завтрашний день
даёт больше шансов перенести вызов или вообще его не обработать, т.к. ключевая фраза тут «может быть».
А вот формулировка:
Вызов принят. Вызовы до 13.00 — обслуживаются в этот же день, вызовы после 13.00 — на следующий
уже не дает никаких шансов на перенос/отмену вызова.
Я выше уже писала: нужен хоть один завалящий конкурент, что бы мозги начали работать в правильную сторону.
А не путать витиеватыми рассказами, про 24 часа на обработку и что мой вызов будет засчитан, если на него обратит внимание мед. работник. Я и так нервничаю, если что.Это защита прежде всего для медперсонала. Иначе (по собственному опыту, связан с программированием в медицине) весь мозг будет гарантированно выклеван, а чего так долго и т. п.
С остальным во многом согласен.
Капитан очевидность рекомендует… или 100500 раз про правильные тексты