Комментарии 19
Концепция по ГОСТУ и Vision — это не совсем одно и то же. Точнее, совсем не одно и то же. Я об этом даже писал как-то (см. «Ловушка вторая»):
www.webursitet.ru/article/terminologicheskie-lovushki-gost-34.html
А грустная история про врача очень хорошо иллюстрирует это высказывание:
imho при внедрении любой новой системы нет ничего сложнее, чем изменение бизнес-процесса в организации. Бизнес-процесс — это поведение людей, и больше всего сил уходит на то, чтобы его изменить.
Подстроить бизнес-процесс под инструмент можно сравнительно легко только там, где этот инструмент даёт явные преимущества всем его участникам. Например, если вы внедряете АБС в банке, в котором до сих работают только с экселем, то вас наверняка встретят с распростёртыми объятиями (правда, таких банков уже не осталось). А вот при попытке поменять одну АБС на другую вы наткнётесь на жёсткое сопротивление пользователей на всех уровнях: процессы уже устоялись, и поменять их можно только боем, с кровью и потерями.
www.webursitet.ru/article/terminologicheskie-lovushki-gost-34.html
А грустная история про врача очень хорошо иллюстрирует это высказывание:
самым простым способом оптимизации производства является изменение бизнес-процесса в организации
imho при внедрении любой новой системы нет ничего сложнее, чем изменение бизнес-процесса в организации. Бизнес-процесс — это поведение людей, и больше всего сил уходит на то, чтобы его изменить.
Подстроить бизнес-процесс под инструмент можно сравнительно легко только там, где этот инструмент даёт явные преимущества всем его участникам. Например, если вы внедряете АБС в банке, в котором до сих работают только с экселем, то вас наверняка встретят с распростёртыми объятиями (правда, таких банков уже не осталось). А вот при попытке поменять одну АБС на другую вы наткнётесь на жёсткое сопротивление пользователей на всех уровнях: процессы уже устоялись, и поменять их можно только боем, с кровью и потерями.
Концепция по ГОСТУ и Vision — это не совсем одно и то же. Точнее, совсем не одно и то же.
Greesha, я не ставил в один ряд ГОСТ и Vision, а лишь сказал, что оба указанных подхода отталкиваются от Проблемы.
Подстроить бизнес-процесс под инструмент можно сравнительно легко только там, где этот инструмент даёт явные преимущества всем его участникам. Например, если вы внедряете АБС в банке, в котором до сих работают только с экселем, то вас наверняка встретят с распростёртыми объятиями (правда, таких банков уже не осталось). А вот при попытке поменять одну АБС на другую вы наткнётесь на жёсткое сопротивление пользователей на всех уровнях: процессы уже устоялись, и поменять их можно только боем, с кровью и потерями.
Не соглашусь с Вами. В грустной истории проблема заключалась как раз в том, что внедряемый инструмент ломал сложившийся бизнес-процесс, не предлагая ничего взамен, а даже наоборот, порождал у врачей жуткий когнитивный диссонанс своей функциональностью.
Был в моей практике пример, когда в организации заменялась информационная система. Так пользователи просто отказывались работать в старой системе, видя как их коллеги работают в новой.
А все почему? Потому что, в первом случае, функциональность программного продукта никак не соотносилась с потребностями пользователей, в то время как во втором, реализованная функциональность прямо коррелировала с выявленными потребностями и удовлетворяла их.
Великолепно!
Еще чуть-чуть — и диссер :)
Еще чуть-чуть — и диссер :)
о, какую редкую и интересную тему вы затронули!
Хочу предложить пару дополнений:
ИТ-проекты выполняются не только для решения существующих или будущих проблем, но и для реализации возможностей. Хотя с возможностями всё гораздо хуже — заказчики менее мотивированы их финансировать, выгодна от них более эфемерна и т.д.
Мой опыт показал, что отталкиваться от проблемы в построении проектной цепочки хорошо, но надо научиться правильно выявлять проблемы. У большинства моих учеников (а это уже действующие не один год специалисты) большая путаница с тем, что считать проблемой и как с ней работать.
Поэтому хочу предложить ещё несколько терминов и компонентов модели для ситуационного анализа, кроме проблем:
1. Собственно Ситуация — совокупность контекста, действующих лиц, их интересов, фактов, проблем, причин и последствий.
2. Факт — некоторое существенное обстоятельство реальности, единичное или систематическое.
3. Причина — вид факта, который порождает проблему.
4. Последствие — вид факта, который порождается фактом-проблемой.
5. Проблема — вид факта, который порождает последствия, наносящие ущерб ЗЛ (деньги, время, репутация, здоровье, мотивация, настроение).
Почему я предлагаю понимать проблему именно так?
Потому что иначе в качестве проблемы берётся, например «У нас нет CRM». И в парадигме «проблема — это разница между желаемым и существующим» (которая мне тоже раньше нравилась) получается всё формально корректно:
* Текущее состояние — CRM нет
* Целевое состояние — CRM есть.
И всё, поехали в качестве результата и цели проекта ставить «Внедрить CRM» со всеми вытекающими :)
А если проанализировать последствия того, что CRM нет, то можно обнаружить много интересного и выйти на реальные проблемы, типа «потери клиентов» и т.д. И увидеть, что отсутствие CRM является не единственной возможной «причиной», а есть ещё и отсутствие правил работы, конфликт интересов сейла и руководства и т.д.
Хочу предложить пару дополнений:
ИТ-проекты выполняются не только для решения существующих или будущих проблем, но и для реализации возможностей. Хотя с возможностями всё гораздо хуже — заказчики менее мотивированы их финансировать, выгодна от них более эфемерна и т.д.
Мой опыт показал, что отталкиваться от проблемы в построении проектной цепочки хорошо, но надо научиться правильно выявлять проблемы. У большинства моих учеников (а это уже действующие не один год специалисты) большая путаница с тем, что считать проблемой и как с ней работать.
Поэтому хочу предложить ещё несколько терминов и компонентов модели для ситуационного анализа, кроме проблем:
1. Собственно Ситуация — совокупность контекста, действующих лиц, их интересов, фактов, проблем, причин и последствий.
2. Факт — некоторое существенное обстоятельство реальности, единичное или систематическое.
3. Причина — вид факта, который порождает проблему.
4. Последствие — вид факта, который порождается фактом-проблемой.
5. Проблема — вид факта, который порождает последствия, наносящие ущерб ЗЛ (деньги, время, репутация, здоровье, мотивация, настроение).
Почему я предлагаю понимать проблему именно так?
Потому что иначе в качестве проблемы берётся, например «У нас нет CRM». И в парадигме «проблема — это разница между желаемым и существующим» (которая мне тоже раньше нравилась) получается всё формально корректно:
* Текущее состояние — CRM нет
* Целевое состояние — CRM есть.
И всё, поехали в качестве результата и цели проекта ставить «Внедрить CRM» со всеми вытекающими :)
А если проанализировать последствия того, что CRM нет, то можно обнаружить много интересного и выйти на реальные проблемы, типа «потери клиентов» и т.д. И увидеть, что отсутствие CRM является не единственной возможной «причиной», а есть ещё и отсутствие правил работы, конфликт интересов сейла и руководства и т.д.
Да, в нашей культуре слово «проблема» носит исключительно негативную окраску, равно как и слово «конфликт», например. Но это очень узкое понимание термина.
В статье сказано, что наличие или отсутствие автомитизированной системы не может являться проблемой — это предположение заинтересованного лица о том, что операция по ее внедрению изменит сложившуюся на предприятии ситуацию. Какую ситуацию? Выяснить это и является задачей проектной команды (в частности, аналитика) и потом внедрить не просто CRM, а CRM с требуемой функциональностью.
Потому что иначе в качестве проблемы берётся, например «У нас нет CRM»
В статье сказано, что наличие или отсутствие автомитизированной системы не может являться проблемой — это предположение заинтересованного лица о том, что операция по ее внедрению изменит сложившуюся на предприятии ситуацию. Какую ситуацию? Выяснить это и является задачей проектной команды (в частности, аналитика) и потом внедрить не просто CRM, а CRM с требуемой функциональностью.
В каком именно месте это сказано?
То, что говорите вы тут в комментарии «это не проблема, найдите настоящую проблему» — это классическое «мышки, станьте ёжиками». Как именно найти настоящую проблему? Об этом надо рассказывать, а не только мантры «думайте о пользователях», «учтите риски», «взвесьте все за и против», «решайте настоящую проблему», «начинайте сначала, а как дойдёте до конца — заканчивайте».
То, что говорите вы тут в комментарии «это не проблема, найдите настоящую проблему» — это классическое «мышки, станьте ёжиками». Как именно найти настоящую проблему? Об этом надо рассказывать, а не только мантры «думайте о пользователях», «учтите риски», «взвесьте все за и против», «решайте настоящую проблему», «начинайте сначала, а как дойдёте до конца — заканчивайте».
В каком именно месте это сказано?
В разделе «Природа требований к программному продукту» сказано, цитирую:
Если в процессе размышлений о способе решения проблемы ЛПР придет к выводу, что достижению поставленной цели будет способствовать автоматизация деятельности организации, то одной из разрабатываемых им операций станет внедрение соответствующей информационной (автоматизированной) системы.
Как именно найти настоящую проблему?
Анализ способов выявления проблемы и формирование образа решения не являлся целью настоящей статьи.
Я кстати не понял, как из списка причин срыва проекта следует, что всему виной — требования.
Недостаточное вовлечение пользователей и менеджмента, например — это недостаточное вовлечение. А требования — это требования.
С ежедневными итерациями (общаемся с пользователями и топами утром и вечером), например, можно создать ПО/систему и без всяких требований.
Недостаточное вовлечение пользователей и менеджмента, например — это недостаточное вовлечение. А требования — это требования.
С ежедневными итерациями (общаемся с пользователями и топами утром и вечером), например, можно создать ПО/систему и без всяких требований.
beskov, а разве общение с пользователями и менеджерами (топами) не порождает требования?
Агилисты, например, считают, что нет. И мне эта точка зрения импонирует.
В некоторых подходах считается, что пользователи и менеджеры описывают проблему, а команда проекта создаёт набор решений этих проблем. Но ничто из этого не называется «требованием».
В некоторых подходах считается, что пользователи и менеджеры описывают проблему, а команда проекта создаёт набор решений этих проблем. Но ничто из этого не называется «требованием».
«Считается» — очень подходящее слово. На деле же оказывается иначе — пользователи и менеджеры формулируют свои пожелания к поведению программы, а команда проекта сначала выясняет чем поможет пользователям требуемое поведение, а уже потом предлагает соответствующее программное.
Я не увидел, в чём разница.
А разница в том, что зачастую пользователи не могут сформулировать решаемую проблему и необходимо вместе с ними к ней придти, а уже потом решать.
Ловлю себя на мысли, что представленный план довольно статичен. То есть принимается как аксиома неизменность потребностей пользователей и уровня владением созданным инструментом. В моем опыте, довольно большое количество проблем решается более глубоким знакомством с используемыми инструментами работы. Конечно, для произведения действия необходимо зафиксировать стабильный уровень опытности пользователей, но очевидно, что его необходимо регулярно пересматривать и приводить в соответствие инструменты-уровень владения.
Кроме того, мне неясен критерий необходимости автоматизации против оптимизации бизнес-процесса (подскажите, может быть не увидел). Можно было бы например рассматривать выигрыш от переложения рутинной работы на автомат и снижение числа человеческих ошибок, но обычно это еще труднее оценить.
Кроме того, мне неясен критерий необходимости автоматизации против оптимизации бизнес-процесса (подскажите, может быть не увидел). Можно было бы например рассматривать выигрыш от переложения рутинной работы на автомат и снижение числа человеческих ошибок, но обычно это еще труднее оценить.
Александр, судя по этой статье и вашим ответам в комментариях, вы упорно пытаетесь изобрести велосипед, а точнее даже собрать нечто велосипедообразное из фрагментов конструкций, подсмотренных у других «изобретателей».
То, что вы пытаетесь сформулировать и преподнести как результат собственного исследования (по крайней мере, мне так показалось), давно известно и широко используется в кругах практиков тех самых «гибких методологий», которые вы упоминаете в качестве одного из второстепенных факторов успешности современных проектов.
В частности, стратегическое и тактическое проектное планирование, фокусирующееся на эффекте (читай: решении проблем и реализации возможностей), в последние годы находит всё большее распространение в ИТ сфере под эгидой техники «Карт влияния» (Impact mapping). Техника заключается в построении ментальных карт (mind maps), отражающих взаимосвязи между целями организации, вовлечёнными (прямо и косвенно) в достижение этих целей людьми, необходимыми изменениями в их поведении и конкретными программно-аппаратно-административными-… мерами/инструментами, необходимыми для воплощения этих изменений в жизнь.
К сожалению, время сейчас не позволяет, но, если интересно, я могу проработать с помощью этой техники пример с «хранилищем медицинских данных о состоянии здоровья населения». Разница с вашей табличкой будет колоссальная. Хотя даже моя «Карта» всё ещё будет сферическим конём в вакууме, потому что строить её будет всего один человек, который при этом ещё и слабо знаком с вопросом. Мне придётся делать огромное количество предположений относительно каждого из уровней, точно так же, как один ЛПР вынужден делать предположения, как минимум, относительно того, какие реальные изменения в поведении необходимы и какими инструментами они могут быть обеспечены. Все эти знания не могут находиться в голове одного человека (если, конечно, он не гений, которыми человечество, увы, не особенно располагает) и даже при их наличии всё равно остаётся высокая мера неопределённости, связанная с изменчивостью предметной области и мира в целом.
Именно поэтому «Карты влияния» — коллективная техника, направленная на вовлечение и со-трудничество как можно большего числа релевантных людей, чьи знания, опыт и интуиция могут существенно снизить число неверных предположений и помочь подобрать оптимальные инструменты для достижения цели. И именно поэтому такие проекты реализуются итеративно с постоянной проверкой остающихся предположений и постоянным пересмотром планов на основе этих проверок-экспериментов.
Если вдруг будете в апреле в Минске, приходите на Analyst Days, я буду рассказывать там на примере конкретного открытого проекта о применении этой техники в рамках комплексного подхода. А после можем пообщаться.
То, что вы пытаетесь сформулировать и преподнести как результат собственного исследования (по крайней мере, мне так показалось), давно известно и широко используется в кругах практиков тех самых «гибких методологий», которые вы упоминаете в качестве одного из второстепенных факторов успешности современных проектов.
В частности, стратегическое и тактическое проектное планирование, фокусирующееся на эффекте (читай: решении проблем и реализации возможностей), в последние годы находит всё большее распространение в ИТ сфере под эгидой техники «Карт влияния» (Impact mapping). Техника заключается в построении ментальных карт (mind maps), отражающих взаимосвязи между целями организации, вовлечёнными (прямо и косвенно) в достижение этих целей людьми, необходимыми изменениями в их поведении и конкретными программно-аппаратно-административными-… мерами/инструментами, необходимыми для воплощения этих изменений в жизнь.
К сожалению, время сейчас не позволяет, но, если интересно, я могу проработать с помощью этой техники пример с «хранилищем медицинских данных о состоянии здоровья населения». Разница с вашей табличкой будет колоссальная. Хотя даже моя «Карта» всё ещё будет сферическим конём в вакууме, потому что строить её будет всего один человек, который при этом ещё и слабо знаком с вопросом. Мне придётся делать огромное количество предположений относительно каждого из уровней, точно так же, как один ЛПР вынужден делать предположения, как минимум, относительно того, какие реальные изменения в поведении необходимы и какими инструментами они могут быть обеспечены. Все эти знания не могут находиться в голове одного человека (если, конечно, он не гений, которыми человечество, увы, не особенно располагает) и даже при их наличии всё равно остаётся высокая мера неопределённости, связанная с изменчивостью предметной области и мира в целом.
Именно поэтому «Карты влияния» — коллективная техника, направленная на вовлечение и со-трудничество как можно большего числа релевантных людей, чьи знания, опыт и интуиция могут существенно снизить число неверных предположений и помочь подобрать оптимальные инструменты для достижения цели. И именно поэтому такие проекты реализуются итеративно с постоянной проверкой остающихся предположений и постоянным пересмотром планов на основе этих проверок-экспериментов.
Если вдруг будете в апреле в Минске, приходите на Analyst Days, я буду рассказывать там на примере конкретного открытого проекта о применении этой техники в рамках комплексного подхода. А после можем пообщаться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От проблемы к требованиям. Теория принятия решений в разработке ПО