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

×


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

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


Сообщения - maksiq

Страницы: « 1 2 3 4 5 6 7 8 9
121

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

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

123
SALar Вы неверно представляете кванты работы во всех трех сценариях. Потому что это компьютер при примитивном программировании крутит цикл по записям. Человек работает со всем заданием/каталогом/отчетом целиком. Потому что там взаимозависимые вещи и интегральные ограничения (в первом случае), а во втором и в третьем - идет настройка некоторых описателей или выбор класса строк, убеждаются что с ними хорошо, отбрасывают, разбираются с оставшимися. Да и компьютер при программировании в терминах коллекций, а не циклов - работает так же, по классам ситуаций. Естественно, в посте я писал по диагонали, без подробностей и шагов - которые интересны только в контексте конкретного бизнес-процесса. Но кванты работы с точки зрения человека и бизнес-области - именно такие, как я написал. Конечно, формлаьно можно придумать за человека жесткий алгоритм, по которому он якобы работает, но реально он работает не так, а параллельно и сложно. Тут, кстати, полная аналогия с процессом проектирования: есть умозрительная методика последовательных шагов и есть реальная жизнь со свободными переключениями. ПО должно поддерживать реальную жизнь.

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

125
Первый пример - автоматизация склада, формирование сменного задания складу, выполняется ежедневно с жесткими временными рамками (начинают в 16, надо успеть до 19). Основная ветка - тупая, система выбирает все заказы (назовем это так) с завтрашней датой отгрузки, контролирует, что для всех регулярных адресатов заказы уже созданы, проверяет ограничения и формирует это самое задание по некоторому алгоритму. Человек практически жмет большую кнопку, смотрит интегральные результаты и все, процесс на несколько минут. По этому сценарию идут 2/3 дней. А остальные - по побочным ветвям: если каких-то заказов нет, то репер - формировать из того что есть, или ждать. Если ограничения (их много, они разные) не удовлетворяются, то дальше начинается работа оператора, он смотрит на задание под разными разрезами и уменьшает его, или может принять решение о формировании с превышением (склад может поднатужится и сделать на 30% больше, но не ежедневно, а вот в машину лишний объем - не влезет, но можно поменять). А если почему-то отгрузка на день оказалась маленькой, он смотрит заказы на послезавтра и может запустить их. В общем-то, описание этого в виде ВИ - относительно муторное, потому что очень много ветвлений, но надо же на что-то опираться при проектировании интерфейса. Поэтому несколько кейсов мы прописали, как частых, так и экзотических. При этом, хотя человек в этом процессе взаимодействует не только с системой, но и с телефоном, это непрерывный кусок работы, на выходе которого должен быть вполне осязаемый результат. Это - один кейс.

Другой кейс. Девочки сидят на загрузке Каталогов от поставщиков. Квант работы - загрузка Каталога на следующий сезон от одного поставщика. Это Excel/Word файл условно структурированного формата, часто на несколько тысяч артикулов. "Условно" означает, что жесткой структуры нет. Конечная цель - товары и модели с необходимой атрибутикой должны появиться в Каталоге и правильно лечь по веткам, создав, где надо новые, а также - заполнив вспомогательные справочники (по необходимости). В зависимости от числа товаров, качества исходного материала и объема новых дополнительных справочников, задача занимает от некоторого количества минут на универсальной форме загрузки, до нескольких часов с последовательным преобразованием информации. Основное для нас было продумать удобную навигацию по интерфейсам и полуавтоматические кейсы заполнения справочников. А для этого - понять ход работы на типичных ветках.

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

Как-то так.

126
Для всех / Re: Кто из UML2 будет на CEE-SECR 2010?
« : 06 Октября 2010, 00:29:27 »
Я буду

127
Вообще вопрос решения противоречий упирается в приемку системы. Кто будет принимать - тот и отвечает за способ реализации. Если с ним договориться о любой формальной методике решения - можно по ней работать. Если не договориться, то никакие ссылки на стандарты не помогут. Если вернуться к приведенным примерам, то цены с НДС и без НДС - надо делать оба, благо это можно и это - реальные требования. Бывают и менее реальные - когда менеджеры хотят скидку в 1/3 от всего, а бухи - цену и НДС (!) на единицу товара в целых копейках. И все это надо напечатать в одной накладной - тогда договариваешься с обоими и объясняешь, что тупого решения - нет (а они - не верят), и иногда будут получаться кривоватые документы. Это как раз противоречие реальное, когда обоим надо обеспечить бизнес-процесс и есть объективные требования. А с безопасностью - там другие заморочки, обычно бизнесу надо, чтобы процесс шел, а безопаснику - чтобы он виноват не был. И придумываешь (иногда вместе с ним), как это "не виноват" - обосновать соответствием системы нормативам. Обычно получается. И все это (оба случая) - работа аналитика.

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

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

130
В общем-то название статьи - типично газетно-рекламное. Потому что статья, как и ее истоники  - о том, что ООП не стало единственной и всеобъемлющей методологией, и провалилось именно в этом смысле. Но это-то было очевидно изначально - единственная правильная методология означает остановку прогресса, а так не бывает. Диалектика развития.

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

131
Возможно, будет интересно, если я расскажу, как устроено у нас. Правда, оно сильно по-другому, потому что основная масса аналитиков - погружена в проектную (sсrum)команду. Внутри команды аналитикой занимается руководитель проекта (он же PO, и у нас он внутри), и один из инженеров (это те, кто на поддержке и контактах с заказчиком). Плюс, по ситуации, аналитические задачи берет кто-то еще, из инженеров или разработчиков (если много техники). А еще есть группа сильных аналитиков, курирующих проекты. Они обычно занимаются новыми проектами, которые на стадии начального проектирования и разработки, но при этом приглядывают за проектными решениями внутри проектной группы. "Приглядывание" организовано по принципу прошлого участия в проектировании, так что человек в целом в контексте. В таких условиях в случае болезни или отпуска текучку всегда есть кому подхватить с приемлемым качеством. Что касается новых проектов, то там тоже выработка основных проектных решений обычно коллективная, а не индивидуальная и на начальных стадиях идет аудит. То есть по сути имеем ту же проектную команду, только с более сильным аналитическим составом (и некоторые - совместители). Примерно так.

132
Выложил свою презентацию на http://www.slideshare.net/custisppt/custistsepkovaccountingdiagrams
Видео предварительной версии доклада опубликовано у нас на сайте http://lib.custis.ru/Диаграммы_планов_счетов_(ЛАФ-2010) (эту ссылку уже давали).
Готов отвечать на вопросы интересующихся.

Страницы: « 1 2 3 4 5 6 7 8 9