Comments 20
Иногда, чтобы добиться от заказчика какой-то информации, хочется воспользоваться старым проверенным способом
Предпочитаю этот способ:
Глубокая термо-ректальная обратная связь? (народное :))
а мне знающие люди говорили, что терморектальный криптоанализ уже не в моде
и надо пользоваться вот этим
и надо пользоваться вот этим
Не уштоль так часто паять телефонные провода приходится?
Ахахахахх… Увидев в твиттере заголовок новости, у меня сразу воображение нарисовало первый комментарий.
Это пять!
По тексту, к своему стыду не прочитал, добавить нечего, так как далек от затронутой темы.
Это пять!
По тексту, к своему стыду не прочитал, добавить нечего, так как далек от затронутой темы.
Пара вопросов:
1) Используете ли вы какие-либо методики классификации требований?
2) Рисуете ли диаграммы/блок-схемы (IDEF, ARIS, UML)?
3) Недавно на хабре была статья о неэффективности мозговых штурмов. Плюс в вашей схеме есть, как мне кажется, определенная логическая ошибка. Если на штурме все только генерят без критики, каким образом потом выбирается оптимальное решение?
4) У меня в «секретном» конспекте написано: Используйте проверенные техники сбора и документирования требований:
— Практические семинары;
— Интервью, собеседования;
— «Мозговой штурм»;
— Анализ документов;
— Создание прототипов;
Три из пяти вы в статье описали, а что можете порекомендовать по 1 и 5 пунктам?
1) Используете ли вы какие-либо методики классификации требований?
2) Рисуете ли диаграммы/блок-схемы (IDEF, ARIS, UML)?
3) Недавно на хабре была статья о неэффективности мозговых штурмов. Плюс в вашей схеме есть, как мне кажется, определенная логическая ошибка. Если на штурме все только генерят без критики, каким образом потом выбирается оптимальное решение?
4) У меня в «секретном» конспекте написано: Используйте проверенные техники сбора и документирования требований:
— Практические семинары;
— Интервью, собеседования;
— «Мозговой штурм»;
— Анализ документов;
— Создание прототипов;
Три из пяти вы в статье описали, а что можете порекомендовать по 1 и 5 пунктам?
1) очень хороший вопрос. Ответ на него неоднозначный. Исходя из опыта моей работы могу сказать, что это зависит от того, где ты работаешь. А я работала на обоих сторонах баррикады — и в разработке ПО, и при его внедрении. Так вот могу отметить, что в разработке обычно всегда используют либо ПО (например, RequisitePro, wiki). На стороне заказчика при внедрении ПО обычно пишут ТЗ. Причиной тому является необходимость согласования этих требований по внутреннему регламенту заказчика, соответственно все заинтересованные лица должны поставить свою визу. Для разъяснений в этом случае используется Outlook. Что интересно, что и в первом и втором случае эти техники, с моей точки зрения, неэффективны из-за частого изменения требований и нежелания вдумчиво читать тонны документации.
Разрабатывая схемы бизнес-процессов для последующей автоматизации я пришла к выводу, что существенно облегчает работу так называемый Social BPM, когда документирование и изменение регламентов и документов идет параллельно со всеми согласованиями и проектированием.
Приведу пример:
Документация процесса происходит с помощью привязки к модели:
Собственно само описание процессов с комментариями заинтересованных лиц и решениями на совещаниях:
Разрабатывая схемы бизнес-процессов для последующей автоматизации я пришла к выводу, что существенно облегчает работу так называемый Social BPM, когда документирование и изменение регламентов и документов идет параллельно со всеми согласованиями и проектированием.
Приведу пример:
Документация процесса происходит с помощью привязки к модели:
Собственно само описание процессов с комментариями заинтересованных лиц и решениями на совещаниях:
2)
2) Рисую конечно, но в российских условиях, работая в отрасли, понимаю, что скорее для себя, а не для заказчика. ARIS — это не диаграмма, а методология, включающая в себя нотацию epc, которая считается наиболее понятной бизнес-пользователям. На самом деле даже ее многие не понимают. IDEF не использую вообще и никому не советую. UML — нотация для разработки ПО, раньше рисовала в ней, сейчас нет, так как занимаюсь внедрением.
3) иногда решение принимается той же группой, что участвовала в мозговом штурме, но чаще всего отобранные идеи передаются руководству для принятия решения. Все предложения делятся на группы: пригодные, непригодные, спорные, или используется рейтинг. Можно задействовать метод от противного: если идея будет реализована, то что может быть причиной ее провала, каких она требует затрат?
4) практические семинары (еще их называют иногда диагностическими). Есть такое тоже. Обычно провожу их с топ-менеджерами.
5) прототипы не создаю, так как работаю не в сфере разработки. Если и делаю, то в виде пользовательских историй.
3) иногда решение принимается той же группой, что участвовала в мозговом штурме, но чаще всего отобранные идеи передаются руководству для принятия решения. Все предложения делятся на группы: пригодные, непригодные, спорные, или используется рейтинг. Можно задействовать метод от противного: если идея будет реализована, то что может быть причиной ее провала, каких она требует затрат?
4) практические семинары (еще их называют иногда диагностическими). Есть такое тоже. Обычно провожу их с топ-менеджерами.
5) прототипы не создаю, так как работаю не в сфере разработки. Если и делаю, то в виде пользовательских историй.
Юлия, не совсем, правда, понятно почему этот топик в хабе erp-системы…
У Вас все перемешано: приемы и для крупных компаний, и для средних и для мелких. Те способы, которые приемлемы для мелких и, порой, средних компаний часто не приемлемы для крупных.
Анкетирование проводится как раз в момент обследования и является одним из его инструментов. Анкеты — это кладезь информации для аналитика. Обработка анкет очень часто позволяет выявить почему разорваны б/п, границы ответственности сотрудников, понять цепочки документооборота. А проводить анкетирование после обследования — это пустая и бессмысленная трата времени, тем более, что сами упомянули, что обработка анкет занимает часто колоссальное количество времени.
Наблюдение… Тоже отличный инструмент. Но не обязательно его делать самому, а можно подвязать на это табельщика (и т.д. кто там отвечает в ОТиЗ за нормирование труда, например, кто может сделать фотографию работчего дня). Если наблюдение проводится б/аналитиком (хотя я ни разу не слышал, чтобы внешние консалтеры этим занимались, только штатные б/аналитики), то не обязательно сообщать человеку, что проводится наблюдение за ЕГО работой. Можно сказать, что проверяется процесс работы слесаря, токаря (логиста, кладовщика и т.д.), обезличенно. Никого это не разозлит. Ну, и чтобы начальник этого сотрудника объяснил это тоже — это обязательно.
Мозговой штурм… Мне лично не понятно, каким образом МШ может помочь ПОЛУЧИТЬ информацию от заказчика? Выработать решение — да, но получить?
Вообще немного непонятно о сборе какой информации Вы писали: о функционирующих б/п, о требованиях заказчика к б/п. Просто как-то все в кучу свалилось.
Я без претензий, только выразил свои мысли по поводу написанного.
У Вас все перемешано: приемы и для крупных компаний, и для средних и для мелких. Те способы, которые приемлемы для мелких и, порой, средних компаний часто не приемлемы для крупных.
Анкетирование проводится как раз в момент обследования и является одним из его инструментов. Анкеты — это кладезь информации для аналитика. Обработка анкет очень часто позволяет выявить почему разорваны б/п, границы ответственности сотрудников, понять цепочки документооборота. А проводить анкетирование после обследования — это пустая и бессмысленная трата времени, тем более, что сами упомянули, что обработка анкет занимает часто колоссальное количество времени.
Наблюдение… Тоже отличный инструмент. Но не обязательно его делать самому, а можно подвязать на это табельщика (и т.д. кто там отвечает в ОТиЗ за нормирование труда, например, кто может сделать фотографию работчего дня). Если наблюдение проводится б/аналитиком (хотя я ни разу не слышал, чтобы внешние консалтеры этим занимались, только штатные б/аналитики), то не обязательно сообщать человеку, что проводится наблюдение за ЕГО работой. Можно сказать, что проверяется процесс работы слесаря, токаря (логиста, кладовщика и т.д.), обезличенно. Никого это не разозлит. Ну, и чтобы начальник этого сотрудника объяснил это тоже — это обязательно.
Мозговой штурм… Мне лично не понятно, каким образом МШ может помочь ПОЛУЧИТЬ информацию от заказчика? Выработать решение — да, но получить?
Вообще немного непонятно о сборе какой информации Вы писали: о функционирующих б/п, о требованиях заказчика к б/п. Просто как-то все в кучу свалилось.
Я без претензий, только выразил свои мысли по поводу написанного.
Я рекомендую применять анкетирование при использовании стандартизованных методик, например, SWOT-анализа.
При правильном проведении мозгового штурма участники должны получить формулировку проблемы, продумать изолированно друг от друга варианты решений и выбрать, на свой взгляд, наиболее подходящие. Когда команда соберется вместе, все предложения будут исследованы, появится возможность видеть все точки зрения и индивидуальные уровни рассмотрения проблемы, таким образом, это способ не только принятия, но и получения информации.
При правильном проведении мозгового штурма участники должны получить формулировку проблемы, продумать изолированно друг от друга варианты решений и выбрать, на свой взгляд, наиболее подходящие. Когда команда соберется вместе, все предложения будут исследованы, появится возможность видеть все точки зрения и индивидуальные уровни рассмотрения проблемы, таким образом, это способ не только принятия, но и получения информации.
Sign up to leave a comment.
Способы получения информации от заказчика