Мне кажется вужно применять испытанные средства... утюги, паяльники, отрезания пальцев. Но делать это нужно гуманно и демакратично, чтобы злвые языки не могули обвинить вас в черствости.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Бусел, Вы писали:
Б>С чего начать опрос о существующих бизнес-процессах?
Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме. Затем это всё тщательно анализируется, прикидывается предварительная модель системы, и только потом начинается её обсуждение и уточнение с заказчиком. Всё это очень здорово экономит время как заказчика так и разработчиков.
Желательно получить не просто бланки, а реальные документы с реальными данными. Если это невозможно из соображений конфиденциальности, то вот здесь заказчику можно немножко попотеть и всё же предоставить какой-нибудь более менее правдоподобный вариант с Иван Ивановичами.
Бумажки также хороший способ верификации модели. Если, например, структура базы данных не позволяет получить какой-либо отчёт, то значит эта схема не верна.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Бусел, Вы писали:
IT>>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме.
Б>Образцы нужны, сгласен, но ведь нужно сперва выяснить с каким набором бумаг (документов) сотрудник работает (каким-то образом относятся к теме). Следовательно, опрос первичен! Б>Но я так понял, что Вы предлагаете ДОПРОС №1 свести именно к краткому выяснению списка документов и их изьятию, правильно?
Точно.
IT>>Затем это всё тщательно анализируется, Б>Проанализировали образцы и видим, что не понятно 50% из них!
Ты думаешь тебе будет больше понятно если просто проведёшь интервью?
Б>Не хватает ответа на ворос "Как получил сотрудник тот или иной документ?".
Вот когда ты пойдёшь интервьюировать его второй раз об это можно будет и спрость.
IT>>прикидывается предварительная модель системы, Б>Как можно прикидывать модель, если не известен бизнес-процесс создания этих образцов? Б>Еще не хватает информации о системе. Б>Какой на ваш взгляд? Б>И как ее получить? Б>Заказчик страдает путанным объяснением происходящего! Б>Нужна некая технология или способ ведения Допроса! Б>Как формулировать вопросы, чтобы полученный ответ был ценным?
Начинать нужно с обработки документов, а не с интервью именно потому, что у тебя нет для первого интервью никаких вопросов, что приводит к пустой трате времени. Первое интервью обычно сводится к тому что разработчик и заказчик сидят друг против друга и молча смотрят друг на друга испепеляющими взглядами. Затем разработчик спрашивает:
— Ну и как вы тут ведёте бизнес?
— Нормально ведём, а что конкретно интересует?
— Ну, например, интересует как вы конкретно бизнес ведёте, детали всякие. Что автоматизировать будем?
— Да вот его бизнес автоматизировать и будем...
Короче, всё как обычно.
А теперь представь, что тебе что-то не понятно в бумажках, которые ты просмотрел. Какие у тебя будут вопросы? Правильно, конкретные.
— Я не понял, что это за цифра вот в этом отчёте. Она вообще тут нужна?
— Ну как же, это же... (рассказ на 30 минут что и как они делают).
— А вот эти данные откуда взяты.
— Ну у нас есть специальный классификатор и баба Маня, которая... (ещё 30 минут).
— А вот эти данные кто вводит?
— Это у нас есть отдел ввода этих данных, 150 человек, которые... (ещё 30 минут).
и т.п.
Т.е. то что тебе что-то не будет понятно, это нормально, и это как раз главная цель сбора бумаг — получить вопросы не тратя своё время и время заказчика.
ЗЫ. Насчёт самого интервью. Желательно его проводить вдвоём. Один задаёт вопросы, другой записывает всё что услышит. Затем всё это вдвоём представляют в виде отчёта, диаграмм и т.п.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Бусел, Вы писали:
Б>>С чего начать опрос о существующих бизнес-процессах?
IT>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме. Затем это всё тщательно анализируется, прикидывается предварительная модель системы, и только потом начинается её обсуждение и уточнение с заказчиком. Всё это очень здорово экономит время как заказчика так и разработчиков.
Все так. А еще для начала надо познакомиться с начальниками отделов, и переговорить с ними, с целью выяснить структуру и функции их отделов (только структуру и функции, ничего лишнего!), а также договориться с ними о проведении интервью с сотрудниками отделов (исполнителями). Которых надо последовательно опросить с целью выяснить, как они работают. Надо выделить роли сотрудников, и опросить по крайней мере по одному сотруднику для каждой роли, до тех пор, пока не сложится целостная картина бизнес-процесса.
Это важно. Будте готовы к тому, что руководители не знакомы (!) с бизнес процессами своей компании. Это нормально. Они, как сова из анекдота — о стратегии думают, и чаще всего не знают деталей бизнес-процессов. Но думают при этом, что знают, и введут вас в заблуждение. Руководители, конечно, бывают разные. Но они не обязаны разбираться в деталях, а язык неточно передает суть дела. Может очень уж неудобно получится, если этот нюанс выяснится при внедрении.
Иногда этот "нюанс" виден сразу. В моей практике один из директоров на просьбу в общих чертах описать схему товародвижения ответил вот что:
— Значит так. — вздох — Товар сначала поступает на Главный Виртуальный Склад...
И сразу мы понимаем, что нам трахают мозг, причем извращенным способом. Кстати, как я выяснил через 5 минут, "Главный Виртуальный Склад" — это сводный отчет по остаткам товаров на всех складах.
Мораль: не надейтесь узнать истину о бизнес-процессах в беседах с руководством заказчика. Это сложно, болезненно для обоих сторон, и даже иногда небезопасно для рассудка. Говорите с исполнителями.
Кстати, вам на заметку один нетрадиционный способ сорвать проект. После составления модели бизнес-процессов вы идете к начальникам отделов и показываете им схему. Так как они (см. предыдущий пункт) возможно впервые в подробностях узнали, как работает их отдел, у них чешутся руки и они затевают реорганизацию. Вас же просят подождать, пока все устоится. Или не просят, а просто начинают немедленно "оптимизировать" эти процессы. Это в большей степени относится к большим начальникам, вроде директоров.
Резюме: будте аккуратны, знакомя руководство заказчика со спецификацией бизнес-процессов. Подумайте, прежде чем предлагать улучшения в их схеме работы, это может затруднить вашу работу.
IT>Желательно получить не просто бланки, а реальные документы с реальными данными. Если это невозможно из соображений конфиденциальности, то вот здесь заказчику можно немножко попотеть и всё же предоставить какой-нибудь более менее правдоподобный вариант с Иван Ивановичами.
Обязательно именно заполненные бланки. Даже в очевидных (казалось-бы) случаях этого требовать необходимо. Уж очень неожиданные сюрпризы иногда вылезают.
IT>Бумажки также хороший способ верификации модели. Если, например, структура базы данных не позволяет получить какой-либо отчёт, то значит эта схема не верна.
Здравствуйте, Бусел, Вы писали:
Б>Привет всем! Б>Решил обсудить с вами процесс получения информации у заказчика о Б>бизнес-процессах в его предметной области!
Добрый день. Есть 2 существенно различных варианта.. развития событий.
1 В случае, если организация не использует четко определенных бизнес-процессов в своей деятельности или находится в стадии активного роста (бизнес-процессы существенно меняются) автоматизация выступает одним из инструментов организации бизнеса. Это достаточно тяжелый случай для автоматизирующего подразделения (или сторонней компании).
2 В случае, если заказчик "всего лишь" не может четко сформулировать требования вам придется помочь ему это сделать.
Б>С чего начать опрос о существующих бизнес-процессах? Б>На какие этапы или ступени разбить процесс выяснения?
Сначала необходимо получить общее представление о бизнесе, который ведет компания (или автоматизируемое подразделений). Определите ключевые виды деятельности заказчика (например, ведутся ли закупки, складской учет, продажи, доставка продукции). Познакомьтесь со списком подразделений компнии. Определите масштаб бизнеса. Дальнейшее заключается в декомпозиции полученной информации — детализируется каждый из видов деятельности. Проведите консультации с руководителями отделов, специалистами, ответственными за узкоспециальные операции в ходе которых прорисовывается иерархическая структура процессов.
Для документирования используйте, скажем, BPWin, который позволяет получить наглядную многоуровневую схему бизнес-процессов. Получите полный список формируемых в ходе бизнеса документов, отчетов (в бумажном виде и электронном), список входящих, подлежащих обработке и регистрации документов. Полезна запись бесед с представитедями заказчика на диктофон (по письменным описаниям не всегда удается воспроизвести ход обсуждения в точности, упускаются кажущиеся неважными детали).
Проработку вопросов следует вести иерархически — не стоит производить детализацию какого-либо процесса не получив информации по смежным (практически все процессы взаимопроникают и любая информация по одному будет неполной без знания остальных).
Б>Какого характера нужно задавать вопросы?
Вопросы следует задавать непосредственно относящиеся с вопросу обсуждения . Например, "Какой объем документов ежедневно формируется отделами?", "Требуется ли экспорт отчетов в excel или html?", "Требуется ли удаленный доступ к системе (заказчиками или торговыми представителями)?". Недопустимы вопросы типа "Какой процент продаж установлен для агента на итальянском рынке?" — вопросы, не относящиеся к теме автоматизации.
Б>Как хитро отвечать на вопрос заказчика "Зачем вам это нужно" ?
Хитро отвечаьт не нужно. Если вы считаете необходимым получить ту или иную информацию, вы должны уметь четко объяснить, для чего вам это нужно. Если объяснить не получается — видимо, вопрос не имеет смысла.
Б>Спасибо всем, кто решится ответить.
Здравствуйте, Бусел, Вы писали:
Б>Решил обсудить с вами процесс получения информации у заказчика о Б>бизнес-процессах в его предметной области!
Б>С чего начать опрос о существующих бизнес-процессах? Б>На какие этапы или ступени разбить процесс выяснения? Б>Какого характера нужно задавать вопросы? Б>Как хитро отвечать на вопрос заказчика "Зачем вам это нужно" ?
Здравствуйте, g_i, Вы писали:
g_i>Вообще, набор фактов поможет в случае, если имеется возможность сопоставить его с некой схемой — адекватно восстановить по нему исходную систему вряд-ли получится.
Ты так рассуждаешь, как будто я призываю один раз сходить к заказчику, забрать у него все бумажки, а потом сразу принести ему готовую систему
Главная идея всех этих бумажек в том, что придя второй раз к заказчику ты уже будешь задавать вполне конкретные вопросы, а следовательно получать вполне конкретные ответы. А это очень важно, хотя бы даже для того чтобы показать себя профессионалом, не говоря уже о бесполезной потере времени, пытаясь выковырять знания из людей, которых никто никогда не учил ими делиться и их формализовывать.
Бумажки — это прежде всего быстрый старт и начинать следует с них.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, g_i, Вы писали:
g_i>>Вообще, набор фактов поможет в случае, если имеется возможность сопоставить его с некой схемой — адекватно восстановить по нему исходную систему вряд-ли получится.
IT>Ты так рассуждаешь, как будто я призываю один раз сходить к заказчику, забрать у него все бумажки, а потом сразу принести ему готовую систему
Нет, я убежден, что следует начинать с получения представления (1) о предметной области на живом языке.
IT>Главная идея всех этих бумажек в том, что придя второй раз к заказчику ты уже будешь задавать вполне конкретные вопросы, а следовательно получать вполне конкретные ответы. А это очень важно, хотя бы даже для того чтобы показать себя профессионалом, не говоря уже о бесполезной потере времени, пытаясь выковырять знания из людей, которых никто никогда не учил ими делиться и их формализовывать.
Знания, достаточные для (1) всегда можно получить. Список бумажек не даст МНЕ представления о том, чем занимается компания — выставляет счета, регистрирует заявки, формирует расходно-приходные накладные, отчеты с непонятными названиями и цифрами — и что? Задавать вопросы навроде "Я так понимаю, это счет (нет, не счет? странно), он выставляется в момент отгрузки продукции.. Ах не в момент отгрузки? И не вы выставляете, а вам выставляют?" — разве не это пустая трата времени? Бумажки полезны для детализации схемы (МНЕ .
IT>Бумажки — это прежде всего быстрый старт и начинать следует с них.
Ты предпочитаешь начинать с модели данных — я с набросков потоков упреавления. Уверен, право на жизнь имеет более одного способа стартовать проект — личные предпочтения, привычки, опыт работы и склад ума в большой степени определяют выбор.
Здравствуйте, IT, Вы писали:
IT>Стоп. Сейчас ты меня уташишь во флейм модель данных vs потоки управления. IT>Давай ка step back. IT>Мы здесь обсуждаем начало общения с заказчиком, первое интервью. Так? Вот давай это и обсуждать. Я утверждаю, что первым шагом должно быть изъятие всех возможных документов у заказчика и их анализ. Предметное интервью — это уже второй шаг. Твоё мнение — никаких бумаг рассматривать не надо, нужно сразу брать быка за рога и вытряхивать из него всю возможную информацию. Я прав?
Я предпочитаю начать с интервью, в нем определить ключевые виды деятельности, основных участников. Получив общее представление, провести интервью с руководителями подразделений и конкретными исполнителями на предмет, "ваша повседневная работа". Лучше к этому моменту иметь копии всех документов (образцы подготавливаются этими отделами), для того, чтобы в процессе интервью сразу "прикреплять" все бумажки к соответсвующим пунктам. В этот же момент основные вопросы связанные с формированием этих документов. После того, как все бумажки будут приколоты на свои места, начинаю их изучать более внимательно.
Начинать с анализа первички считаю неправильным по след. причинам:
1 если заказчик пропустит несколько важных образцов, это может не всплыть достаточно долгое время — ты обратишься за разъяснениями по собранным документам и получишь их. Чтобы выйти на пропущенные документы придется переключиться на вопросы типа "а чем вы еще занимаетесь" и "не забыли-ли вы чего"? Т.е. вернуться с обсуждению в стиле "расскажите о своей повседневной работе". Поэтому я начинаю с него.
2 кроме названий документов вряд-ли удастся выявить что-то существенное. Если я неправ, поясни этот момент.
3 начав с самостоятельного анализа первички можно сделать ложные предположения о структуре бизнеса, при интервьюировании опасность этого существенно ниже.
Опиши более конкретно преимущества, которые дает тебе твой подход, если получится, на простом примере. Укажи недостатки, которые дискредитируют мой подход.
Здравствуйте, Бусел, Вы писали:
Б>С чего начать опрос о существующих бизнес-процессах?
Сначало не забыть поздороваться. Пожать ручку. Улыбнуться. Б>На какие этапы или ступени разбить процесс выяснения?
Сначала выясняешь каким образом пользователь будет контактировать. Чем быстрее пользователь отвечает на твои вопросы, тем лучше. Лучше всего когда определяется человек который явно ответсвенен за взаимодействие. Лучше 10 раз рассказать что для того что продукт без консультаций пользователей сделать невозможно. И успех проекта напрямую зависит от самого клиента.
Сначала выясняешь что и как делается сейчас. В основном нужны действия пользователей. Какие продукты используются, какие интересы у того или иного пользователя. Можно посидеть и посмотреть как работает тот или иной пользователь. Постепенно по этим действиям врубишься в предметную область. Если предметная область уже знакома, то этот этап проходит быстро. И только затем можно уже спрашивать а что же пользователь хочет. Иногда пользователь не особо то и представляет что он хочет, тогда лучше узнать проблему пользователя которую он хочет решить. И уже от этого начинаешь плясать.
Затем делаешь ограничение задачи(явно определяешь а что же будем делать), делаешь концепцию с прецедентами и заверяешь у пользователя. Далее делишь задачи, и начинаешь детализировать. И каждый раз заверять у пользователя. Не заверяй только технические детали. Чем более плотное покрытие заверки, тем безопаснее для тебя. И приготовься, что процедура заверки может длиться долго(иногда очень ленивый народ попадается). А посему дело от этого не должно останавливаться(потом можно переделать под то, о чем договоришься в результате с заказчиком).
Б>Как хитро отвечать на вопрос заказчика "Зачем вам это нужно" ?
Ответ примерно такой. Мы не есть профессионалы в предметной области на данном предприятии, но мы профессионалы в решении построения и постановки задач. И чтобы продукт удовлетворял требованиям, при разработке нужно иметь полную картину.
Да сразу предупреждение. Не в коем случае не ложись под заказчика. Поясни ему сколько денег может стоить то или иное действие и изменение. В большинстве случаев они вполне вменяемы.
Здравствуйте, g_i, Вы писали:
IT>>Ты так рассуждаешь, как будто я призываю один раз сходить к заказчику, забрать у него все бумажки, а потом сразу принести ему готовую систему
g_i>Нет, я убежден, что следует начинать с получения представления (1) о предметной области на живом языке.
На представлениях систему не сделаешь. Нужны конкретные знания и данные. А представление можно получить и по дороге в лифте с 1-го этажа на 9-й. Это не проблема.
g_i>Знания, достаточные для (1) всегда можно получить. Список бумажек не даст МНЕ представления о том, чем занимается компания — выставляет счета, регистрирует заявки, формирует расходно-приходные накладные, отчеты с непонятными названиями и цифрами — и что? Задавать вопросы навроде "Я так понимаю, это счет (нет, не счет? странно), он выставляется в момент отгрузки продукции.. Ах не в момент отгрузки? И не вы выставляете, а вам выставляют?" — разве не это пустая трата времени? Бумажки полезны для детализации схемы (МНЕ .
Ну вот только не надо так утрировать. Мы здесь все профессионалы, поднявшие не один проект. Зачем прикидываться первокурсником
IT>>Бумажки — это прежде всего быстрый старт и начинать следует с них.
g_i>Ты предпочитаешь начинать с модели данных — я с набросков потоков упреавления.
Потоков управления чем? Не данными ли?
g_i>Уверен, право на жизнь имеет более одного способа стартовать проект — личные предпочтения, привычки, опыт работы и склад ума в большой степени определяют выбор.
Меня на модели данных больше всего интересуют связи между объектами. Вот эти связи я и собираюсь выявлять с самого самого начала.
Что касается потоков управления, то они не позволяют просто выразить общую картину предметной области. Для этого тебе понадобится несколько диаграмм для каждой подсистемы. Модель данных позволяет обойтись минимальным количеством диаграми, а для проведения танковых атак на глобусе мира вообще достаточно одной.
К тому же для моделирования потоков управления тебе всё равно нужны объекты. Соответственно, ты всё равно сначала, пусть неявно, в голове, строишь объектную модель. Так зачем себя и других обманывать
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, g_i, Вы писали:
g_i>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, g_i, Вы писали:
g_i>>>Вообще, набор фактов поможет в случае, если имеется возможность сопоставить его с некой схемой — адекватно восстановить по нему исходную систему вряд-ли получится.
IT>>Ты так рассуждаешь, как будто я призываю один раз сходить к заказчику, забрать у него все бумажки, а потом сразу принести ему готовую систему
g_i>Нет, я убежден, что следует начинать с получения представления (1) о предметной области на живом языке.
Господа, спор на тему "с чего начинать анализ" имеет очень длинную историю, и многие уважаемые люди придерживаются противоположных точек зрения. Моя практика, к примеру, показывает, что начинать можно с чего угодно. Все равно процесс итеративный, и не слишком важно с чего начинать. Это вопрос сугубо личных предпочтений.
Здравствуйте, g_i, Вы писали:
g_i>Пример. Опять утрирую, ты уж извини.
Стоп. Сейчас ты меня уташишь во флейм модель данных vs потоки управления.
Давай ка step back.
Мы здесь обсуждаем начало общения с заказчиком, первое интервью. Так? Вот давай это и обсуждать. Я утверждаю, что первым шагом должно быть изъятие всех возможных документов у заказчика и их анализ. Предметное интервью — это уже второй шаг. Твоё мнение — никаких бумаг рассматривать не надо, нужно сразу брать быка за рога и вытряхивать из него всю возможную информацию. Я прав?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, g_i, Вы писали:
IT>>>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает.
g_i>>ИМХО, "поговорить", все-же, надо. Ситуация: вы приходите в незнакомую компанию, собираете все бумажки, и..??? Пытаетесь восстановить по ним, чем-же все-таки эта контора занимается? Наверное, нужно прояснить структуру бизеса, для начала. А изучение первички, форм отчетности и т.п. — один из аспектов, но не единстенный.
IT>Я к тому, что разговор после изучения бумажек будет в разы гораздо более эффективный.
Не согласен. Без предварительного обсуждения изучение бумажек затянется. Ибо это сродни реинженирингу (часто путанного) кода без тех. документации. Обследование должно начинаться с общения. ИМХО.
PS То, что изучение бумажек необходимо — это бесспорно.
alex-chin -> "Re[4]: Как вести ДОПРОС?" :
hrg>> На самом деле — нужно строить 2 модели — AS IS & TO BE. Как hrg>> правило, ресурсов хватает только на TO BE Поэтому hrg>> ориентироваться на текущую орг.структуру нужно только для создания hrg>> базового плана бизнес-процессов. Как правило, после прописания hrg>> бизнес-процессов она иногда кардинально меняется
ac> Вообще то вопрос был как вести ДОПРОС. А именно как стоять на краю
ДОПРОС надо вести так, чтобы потом систему не переписывать
ac> Сначало как правило производится реинжениринг а уж потом... А сказки ac> про реинжениринг вообще кто-то слышал?
Жизнь страшнее.
Yury Kopyl aka hrg | http://id.totem.ru | Только взял боец гитару, сразу
видно — гармонист...
Здравствуйте, IT, Вы писали:
g_i>>Ты предпочитаешь начинать с модели данных — я с набросков потоков упреавления.
IT>Потоков управления чем? Не данными ли?
Это называется ERD vs DFD. То есть по причинам не имеющим видимых оснований в объективной реальности разные люди предпочитаю начинать либо со схемы данных, либо c потоков. Не лечится. Да и что лечить-то?
Привет всем!
Решил обсудить с вами процесс получения информации у заказчика о
бизнес-процессах в его предметной области!
С чего начать опрос о существующих бизнес-процессах?
На какие этапы или ступени разбить процесс выяснения?
Какого характера нужно задавать вопросы?
Как хитро отвечать на вопрос заказчика "Зачем вам это нужно" ?
Спасибо всем, кто решится ответить.
21.05.05 17:22: Перенесено модератором из 'Философия программирования' — AndrewVK
22.05.05 01:39: Перенесено модератором из 'Shareware и бизнес' — retalik
Привет, весьма интересный ответ!
Забыл сказать, что я столкнулся с совершенно неизвестной мне областью.
Начал я с поиска в интернете информации для ликбеза, прочитал и .... что дальше-то.
Нужно вызывать на допрос заказчика, но с какой целью? IT>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме.
Образцы нужны, сгласен, но ведь нужно сперва выяснить с каким набором бумаг (документов)
сотрудник работает (каким-то образом относятся к теме). Следовательно, опрос первичен!
Но я так понял, что Вы предлагаете ДОПРОС №1 свести именно к краткому выяснению списка документов и их изьятию, правильно?
IT>Затем это всё тщательно анализируется,
Проанализировали образцы и видим, что не понятно 50% из них!
Не хватает ответа на ворос "Как получил сотрудник тот или иной документ?". IT>прикидывается предварительная модель системы,
Как можно прикидывать модель, если не известен бизнес-процесс создания этих образцов?
Еще не хватает информации о системе.
Какой на ваш взгляд?
И как ее получить?
Заказчик страдает путанным объяснением происходящего!
Нужна некая технология или способ ведения Допроса!
Как формулировать вопросы, чтобы полученный ответ был ценным?
А с остальным согласен!!! Пока остановились на дополнительном Допросе!
Здравствуйте, Бусел, Вы писали:
Б>Привет всем! Б>Решил обсудить с вами процесс получения информации у заказчика о Б>бизнес-процессах в его предметной области!
Б>С чего начать опрос о существующих бизнес-процессах? Б>На какие этапы или ступени разбить процесс выяснения? Б>Какого характера нужно задавать вопросы? Б>Как хитро отвечать на вопрос заказчика "Зачем вам это нужно" ?
--
В книге Джонс Дж. К. "Методы проектирования", 1986 среди других способов и методов формального проектирования можно найти подробное описание того, как надо интервьюировать пользователей.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Бусел, Вы писали:
IT>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает.
ИМХО, "поговорить", все-же, надо. Ситуация: вы приходите в незнакомую компанию, собираете все бумажки, и..??? Пытаетесь восстановить по ним, чем-же все-таки эта контора занимается? Наверное, нужно прояснить структуру бизеса, для начала. А изучение первички, форм отчетности и т.п. — один из аспектов, но не единстенный.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Бусел, Вы писали:
Б>>С чего начать опрос о существующих бизнес-процессах?
IT>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме. Затем это всё тщательно анализируется, прикидывается предварительная модель системы, и только потом начинается её обсуждение и уточнение с заказчиком. Всё это очень здорово экономит время как заказчика так и разработчиков.
Вообще, активно общаться с заказчиком нужно на протяжении всего цикла разработки, особенно в начале. Любые документы в ходе работы подвергаются трактовке и анализу сотрудниками компании. Обязательно нужно знать, как используется тот или иной отчет, в какой последовательности возникают документы. Чем руководствуется сотрудник оформляющий, скажем, скидку, а не кредитноту в схожих ситуациях.
Здравствуйте, g_i, Вы писали:
IT>>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает.
g_i>ИМХО, "поговорить", все-же, надо. Ситуация: вы приходите в незнакомую компанию, собираете все бумажки, и..??? Пытаетесь восстановить по ним, чем-же все-таки эта контора занимается? Наверное, нужно прояснить структуру бизеса, для начала. А изучение первички, форм отчетности и т.п. — один из аспектов, но не единстенный.
Я к тому, что разговор после изучения бумажек будет в разы гораздо более эффективный.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, g_i, Вы писали:
IT>>>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает.
g_i>>ИМХО, "поговорить", все-же, надо. Ситуация: вы приходите в незнакомую компанию, собираете все бумажки, и..??? Пытаетесь восстановить по ним, чем-же все-таки эта контора занимается? Наверное, нужно прояснить структуру бизеса, для начала. А изучение первички, форм отчетности и т.п. — один из аспектов, но не единстенный.
IT>Я к тому, что разговор после изучения бумажек будет в разы гораздо более эффективный.
Если не утверждается, что начинать нужно именно с изучения бумажек — тогда согласен.
Здравствуйте, g_i, Вы писали:
g_i>Если не утверждается, что начинать нужно именно с изучения бумажек — тогда согласен. g_i>
Именно это и утверждается. Экскурсии по предприятию и знакомство с передовиками производства не в счёт. Я говорю о начале детального изучения предметной области.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, g_i, Вы писали: IT>Именно это и утверждается. Экскурсии по предприятию и знакомство с передовиками производства не в счёт. Я говорю о начале детального изучения предметной области.
Ок. Тебе вывалили ворох бумаг — образцов форм отчетности и певичных документов. Что ты со всем этим будешь делать? Как будешь анализировать? Имеется в виду, предварительных сведений об организации у тебя нет. Нет ТЗ, нет сформулированных требований к системе.
Здравствуйте, Бусел, Вы писали:
Б>Привет всем! Б>Решил обсудить с вами процесс получения информации у заказчика о Б>бизнес-процессах в его предметной области!
Сначало надо понять для чего тебе нужна информация о заказчике.
Как правило она нужна для достяжения двух целей:
1) Определение границ системы автоматизации.
2) Моделирование (реализация) объектов и процессов в системе.
Даже если заказчик ваш коллега на предприятии — определение границ системы является необходимым этапом.
Советую начать работу с составления словаря предметной области. Как вы начнете свою работу в принципе все равно.
Это может быть интервью, опросники и т.д. Главное не вдаваться в детали с которых ты будешь плавать, а задавать наводящие вопросы. Ключевые объекты предметной области д.б. записаны и образованны основные связи между ними.
Дальше можно как угодно долго работать с этими терминами. Будет ли присутствовать объект в системе? Как реализован объект в виде документов? Это очень важно. ВАМ НЕ ОБЯЗАТЕЛЬНО ЗНАТЬ ПРЕДМЕТНУЮ ОБЛАСТЬ. Важно разговаривать в терминах предметной области.
Как правило работнику более понятны связи по управлению. Типа имею такой то документ ДЕЛАЮ ТО-ТО получаю такие-то изменения и новые документы. Более сложные связи типа ЧАСТЬ-ЦЕЛОЕ, ОБЩЕЕ-ЧАСТНОЕ обсуждать надо акуратно, как правило работник в них плавает. Пример, обсуждение что СЧЕТ состоит из заголовка СЧЕТА и ДЕТАЛЕЙ приводит работника в ступор.
Здравствуйте, Бусел, Вы писали:
Б>Привет всем! Б>Решил обсудить с вами процесс получения информации у заказчика о Б>бизнес-процессах в его предметной области!
Б>С чего начать опрос о существующих бизнес-процессах? Б>На какие этапы или ступени разбить процесс выяснения? Б>Какого характера нужно задавать вопросы?
Есть ГОСТ на создание автоматизированных систем — ГОСТ 34.602
AC>Советую начать работу с составления словаря предметной области. Как вы начнете свою работу в принципе все равно. AC>Это может быть интервью, опросники и т.д. Главное не вдаваться в детали с которых ты будешь плавать, а задавать наводящие вопросы. Ключевые объекты предметной области д.б. записаны и образованны основные связи между ними.
Да! Забыл добавить: необходимо включить в обсуждение ролей работников в системе. Сам термин РОЛЬ или АКТЕР лучше не употреблять. Должности и должностные инструкции тебе в помощь. После получения орг-штатной структуры у тебя появляется возможность получить информацию кто за что отвечает и кто что делает. Вопросы желательно задавать в разрезе МЫ ХОТИМ АВТОМАТИЗИРОВАТЬ, а не КАК ВЫ ЭТО ДЕЛАЕТЕ. Ответы на второй прямой вопрос ты получишь опосредованно.
AC>> Советую начать работу с составления словаря предметной области. Как AC>> вы начнете свою работу в принципе все равно. AC>> Это может быть интервью, опросники и т.д. Главное не вдаваться в AC>> детали с которых ты будешь плавать, а задавать наводящие вопросы. AC>> Ключевые объекты предметной области д.б. записаны и образованны AC>> основные связи между ними.
ac> Да! Забыл добавить: необходимо включить в обсуждение ролей ac> работников в системе. Сам термин РОЛЬ или АКТЕР лучше не ac> употреблять. Должности и должностные инструкции тебе в помощь. После ac> получения орг-штатной структуры у тебя появляется возможность ac> получить информацию кто за что отвечает и кто что делает. Вопросы ac> желательно задавать в разрезе МЫ ХОТИМ АВТОМАТИЗИРОВАТЬ, а не КАК ВЫ ac> ЭТО ДЕЛАЕТЕ. Ответы на второй прямой вопрос ты получишь ac> опосредованно.
На самом деле — нужно строить 2 модели — AS IS & TO BE. Как правило,
ресурсов хватает только на TO BE Поэтому ориентироваться на текущую
орг.структуру нужно только для создания базового плана бизнес-процессов. Как
правило, после прописания бизнес-процессов она иногда кардинально меняется
Yury Kopyl aka hrg | http://id.totem.ru |
"Если ты плюнешь на коллектив — коллектив утрется,
но если коллектив плюнет на тебя — ты утонешь" (С)Баралгин
Здравствуйте, g_i, Вы писали:
g_i>Ок. Тебе вывалили ворох бумаг — образцов форм отчетности и певичных документов. Что ты со всем этим будешь делать? Как будешь анализировать? Имеется в виду, предварительных сведений об организации у тебя нет. Нет ТЗ, нет сформулированных требований к системе.
Буду начинать строить модель данных.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, g_i, Вы писали:
g_i>>Ок. Тебе вывалили ворох бумаг — образцов форм отчетности и певичных документов. Что ты со всем этим будешь делать? Как будешь анализировать? Имеется в виду, предварительных сведений об организации у тебя нет. Нет ТЗ, нет сформулированных требований к системе.
IT>Буду начинать строить модель данных.
Нельзя строить модель неизвестно чего. Тебе выдали разобраный на детали механизм — без принципиальной схемы ты его либо не соберешь, либо соберешь не то. Модель данных у тебя получается — некая застывшая неупорядоченная схема, в ней не будут отражены (на старте) существенные связи и отношения. Динамические показатели системы во многом определяют структуру модели — а у тебя они поначалу вовсе не учитываются.
Я соглашусь с тобой в случае, если:
1 с набором первичных документов тебе выдали хотя бы общий список требований к системе
2 первичные документы и отчеты разбиты по неким функциональным группам и зафиксирофан определенный порядок их возникновения
Вообще, набор фактов поможет в случае, если имеется возможность сопоставить его с некой схемой — адекватно восстановить по нему исходную систему вряд-ли получится.
Здравствуйте, hrg, Вы писали:
hrg>alex-chin -> "Re[2]: Как вести ДОПРОС?" :
hrg>На самом деле — нужно строить 2 модели — AS IS & TO BE. Как правило, hrg>ресурсов хватает только на TO BE Поэтому ориентироваться на текущую hrg>орг.структуру нужно только для создания базового плана бизнес-процессов. Как hrg>правило, после прописания бизнес-процессов она иногда кардинально меняется hrg>
Вообще то вопрос был как вести ДОПРОС. А именно как стоять на краю пропасти незнания ПО и не показаться профаном. Так что ASIS, то что надо. Ближе надо к юзверу... И по-ласковее...
А то что меняется после реинжиниринга — это разговоры в куринках — типа Кого сократят. И вообще мешать реинжениринг (а только поэтому может меняться ОШ структура) с автоматизацией не есть хорошо. Сначало как правило производится реинжениринг а уж потом... А сказки про реинжениринг вообще кто-то слышал?
Здравствуйте, hrg, Вы писали:
hrg>alex-chin -> "Re[4]: Как вести ДОПРОС?" :
hrg>>> На самом деле — нужно строить 2 модели — AS IS & TO BE. Как hrg>>> правило, ресурсов хватает только на TO BE Поэтому hrg>>> ориентироваться на текущую орг.структуру нужно только для создания hrg>>> базового плана бизнес-процессов. Как правило, после прописания hrg>>> бизнес-процессов она иногда кардинально меняется
ac>> Вообще то вопрос был как вести ДОПРОС. А именно как стоять на краю
hrg>ДОПРОС надо вести так, чтобы потом систему не переписывать
До следующей итерации... А по опыту следующая бывает через день
Здравствуйте, IT, Вы писали:
g_i>>Знания, достаточные для (1) всегда можно получить. Список бумажек не даст МНЕ представления о том, чем занимается компания — выставляет счета, регистрирует заявки, формирует расходно-приходные накладные, отчеты с непонятными названиями и цифрами — и что? Задавать вопросы навроде "Я так понимаю, это счет (нет, не счет? странно), он выставляется в момент отгрузки продукции.. Ах не в момент отгрузки? И не вы выставляете, а вам выставляют?" — разве не это пустая трата времени? Бумажки полезны для детализации схемы (МНЕ .
IT>Ну вот только не надо так утрировать. Мы здесь все профессионалы, поднявшие не один проект. Зачем прикидываться первокурсником
Я попытался описать конкретную ситуацию. Естественно, упрощенно, чтобы не оставить возможностей трактовки. Ты не ответил ни на один вопрос типа "Как ты это сделаешь?". Я пока не понял, что ты подразумеваешь под "анализом" первички. Выделение ключевых объектов — и все?
g_i>>Ты предпочитаешь начинать с модели данных — я с набросков потоков упреавления. IT>Потоков управления чем? Не данными ли?
[skipped] IT>Что касается потоков управления, то они не позволяют просто выразить общую картину предметной области. Для этого тебе понадобится несколько диаграмм для каждой подсистемы. Модель данных позволяет обойтись минимальным количеством диаграми, а для проведения танковых атак на глобусе мира вообще достаточно одной.
Несколько диаграмм — правильно. Но не горизонтально соседствующих, а иерархически. Каждая диаграмма содержит полную схему — отличаясь уровнями детализации. Модель данных (в моем представлении) не содержит динамики. Разверни схему процессов до полной детализации — получишь свою модель данных, но уже с "причинно-следственными" связями, правда без детализации сущностей.
IT>К тому же для моделирования потоков управления тебе всё равно нужны объекты. Соответственно, ты всё равно сначала, пусть неявно, в голове, строишь объектную модель. Так зачем себя и других обманывать
Пример. Опять утрирую, ты уж извини. "Сотрудник отдела по работе с клиентами получает заказ на продукцию. Обрабатывает его стандартным образом. Передает для согласования в производственную службу." Для того, чтобы описать данный блок совсем необязательно знать, что из себя представляет заказ — это детализируется позже. А вот от "заказа" без операций "принят", "обработан", "согласуется" с самого начала толку немного. На начальном этапе меня вполне устроят только наименования сущностей — "заказ" , "клиент", "счет", без детального описания. В дальшейшем я заинтересуюсь, что из себя представляет тот или иной документ, на следующем этапе анализа.
Здравствуйте, g_i, Вы писали:
IT>>Мы здесь обсуждаем начало общения с заказчиком, первое интервью. Так? Вот давай это и обсуждать. Я утверждаю, что первым шагом должно быть изъятие всех возможных документов у заказчика и их анализ. Предметное интервью — это уже второй шаг. Твоё мнение — никаких бумаг рассматривать не надо, нужно сразу брать быка за рога и вытряхивать из него всю возможную информацию. Я прав?
g_i>Я предпочитаю начать с интервью, в нем определить ключевые виды деятельности, основных участников. Получив общее представление, провести интервью с руководителями подразделений и конкретными исполнителями на предмет, "ваша повседневная работа". Лучше к этому моменту иметь копии всех документов (образцы подготавливаются этими отделами), для того, чтобы в процессе интервью сразу "прикреплять" все бумажки к соответсвующим пунктам. В этот же момент основные вопросы связанные с формированием этих документов. После того, как все бумажки будут приколоты на свои места, начинаю их изучать более внимательно.
Это не начало, это план работ минимум на неделю
g_i>Начинать с анализа первички считаю неправильным по след. причинам: g_i>1 если заказчик пропустит несколько важных образцов, это может не всплыть достаточно долгое время — ты обратишься за разъяснениями по собранным документам и получишь их. Чтобы выйти на пропущенные документы придется переключиться на вопросы типа "а чем вы еще занимаетесь" и "не забыли-ли вы чего"? Т.е. вернуться с обсуждению в стиле "расскажите о своей повседневной работе". Поэтому я начинаю с него.
То что при твоих беседах с заказчиком он тебе не выдаст какую-то важную деталь, которая ему столь важной не кажется как раз гораздо более вероятнее.
g_i>2 кроме названий документов вряд-ли удастся выявить что-то существенное. Если я неправ, поясни этот момент.
Дай мне пример конкретного документа и я тебе всё поясню
g_i>3 начав с самостоятельного анализа первички можно сделать ложные предположения о структуре бизнеса, при интервьюировании опасность этого существенно ниже.
Вот эти ложные предположения я и разъясну при второй встрече с заказчиком Я тебе уже говорил, никто не делает по бумажкам готовую систему. Мы говорим лишь о первом знакомстве с проектом.
g_i>Опиши более конкретно преимущества, которые дает тебе твой подход, если получится, на простом примере. Укажи недостатки, которые дискредитируют мой подход.
Твой подход — это стандартный путь, в принципе большинство делает именно так. Но это вовсе не значит, что этот путь самый оптимальный. Анализ документов — это другой путь начать общение с заказчиком, т.к. во время анализа ты уже можешь оценить разнообразие информации, ознакомится с терминологией, увидеть специфику, особенно если ты уже раньше занимался чем-то подобным. Дальше ты уже идёшь к заказчику и задаёшь вполне конкретные понятные ему вопросы, а не что-то абстрактное "Ну и что мы тут собираемся автоматизироавть". Привести пример я могу, если ты мне дашь какой-нибудь бланк или отчёт. Выдумывать что-то из головы мне лень, а текущая предметная область в которой я сейчас работаю, боюсь будет слишком далека от российской действительности
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, g_i, Вы писали: IT>Твой подход — это стандартный путь, в принципе большинство делает именно так. Но это вовсе не значит, что этот путь самый оптимальный. Анализ документов — это другой путь начать общение с заказчиком, т.к. во время анализа ты уже можешь оценить разнообразие информации, ознакомится с терминологией, увидеть специфику, особенно если ты уже раньше занимался чем-то подобным. Дальше ты уже идёшь к заказчику и задаёшь вполне конкретные понятные ему вопросы, а не что-то абстрактное "Ну и что мы тут собираемся автоматизироавть". Привести пример я могу, если ты мне дашь какой-нибудь бланк или отчёт. Выдумывать что-то из головы мне лень, а текущая предметная область в которой я сейчас работаю, боюсь будет слишком далека от российской действительности
Здравствуйте, Бусел, Вы писали:
Б>Привет, весьма интересный ответ! Б>Забыл сказать, что я столкнулся с совершенно неизвестной мне областью. Б>Начал я с поиска в интернете информации для ликбеза, прочитал и .... что дальше-то. Б>Нужно вызывать на допрос заказчика, но с какой целью? IT>>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме. Б>Образцы нужны, сгласен, но ведь нужно сперва выяснить с каким набором бумаг (документов) Б>сотрудник работает (каким-то образом относятся к теме). Следовательно, опрос первичен! Б>Но я так понял, что Вы предлагаете ДОПРОС №1 свести именно к краткому выяснению списка документов и их изьятию, правильно?
IT>>Затем это всё тщательно анализируется, Б>Проанализировали образцы и видим, что не понятно 50% из них! Б>Не хватает ответа на ворос "Как получил сотрудник тот или иной документ?". IT>>прикидывается предварительная модель системы, Б>Как можно прикидывать модель, если не известен бизнес-процесс создания этих образцов? Б>Еще не хватает информации о системе. Б>Какой на ваш взгляд? Б>И как ее получить? Б>Заказчик страдает путанным объяснением происходящего! Б>Нужна некая технология или способ ведения Допроса! Б>Как формулировать вопросы, чтобы полученный ответ был ценным?
Б>А с остальным согласен!!! Пока остановились на дополнительном Допросе!
Работая над одной системой, мы научили заказчика читать диаграммы IDEFx, каковые в данном случае были наиболее просты для понимания, и путем спуска сверху вниз по диаграммам, довольно быстро выяснили потоки информации в компании и ответственных людей. Использовали для этого BPWin и было это в 2000 году...
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, g_i, Вы писали:
g_i>>Ок. Тебе вывалили ворох бумаг — образцов форм отчетности и певичных документов. Что ты со всем этим будешь делать? Как будешь анализировать? Имеется в виду, предварительных сведений об организации у тебя нет. Нет ТЗ, нет сформулированных требований к системе.
IT>Буду начинать строить модель данных.
Не актуально. Это устаревший подход, который проигрывает по эффективности подходу со стороны бизнес-модели. Строить-то всё равно приходится и модель данных, и бизнес-модель, но только быстрее это делать не с модели данных.
Здравствуйте, O-Sam, Вы писали:
g_i>>>Ок. Тебе вывалили ворох бумаг — образцов форм отчетности и певичных документов. Что ты со всем этим будешь делать? Как будешь анализировать? Имеется в виду, предварительных сведений об организации у тебя нет. Нет ТЗ, нет сформулированных требований к системе.
IT>>Буду начинать строить модель данных.
OS>Не актуально. Это устаревший подход, который проигрывает по эффективности подходу со стороны бизнес-модели. Строить-то всё равно приходится и модель данных, и бизнес-модель, но только быстрее это делать не с модели данных.
А с чего?
... << RSDN@Home 1.1.4 stable rev. 510>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alexanderfedin, Вы писали:
A>Работая над одной системой, мы научили заказчика читать диаграммы IDEFx, каковые в данном случае были наиболее просты для понимания, и путем спуска сверху вниз по диаграммам, довольно быстро выяснили потоки информации в компании и ответственных людей. Использовали для этого BPWin и было это в 2000 году...
Тут уже Влад писал про проверенные средства... Но были ли вы достаточно осторожны, дабы злые языки не обвинили вас в чёрствости?
Здравствуйте, Gaperton, Вы писали:
G>Это важно. Будте готовы к тому, что руководители не знакомы (!) с бизнес процессами своей компании. Это нормально. Они, как сова из анекдота — о стратегии думают, и чаще всего не знают деталей бизнес-процессов. Но думают при этом, что знают, и введут вас в заблуждение. Руководители, конечно, бывают разные. Но они не обязаны разбираться в деталях, а язык неточно передает суть дела. Может очень уж неудобно получится, если этот нюанс выяснится при внедрении.
Хорошо сказал, подпишусь под каждым словом. Очень редко бывают исключения, которые действительно знают как обстоит дело сейчас и как надо.
Б>Решил обсудить с вами процесс получения информации у заказчика о Б>бизнес-процессах в его предметной области!
В первую очередь, попроси заказчика "выделить" тебе консультанта,
наиболее хорошо представляющего себе процесс функционирования предприятияэтот
чувак будет экспертом в предметной области.
Ну вот далее собсвенно изучаешь все пироги , задавая вопрос этому человеку,
постепенно вы сним общий суррогатный диалект выработаете. Он же, в дальнейшм, хорошо поможет тебе
при согласовании проекта с заказчиком.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Если нам не помогут, то мы тоже никого не пощадим.
