Комментарии 19
Концепция по ГОСТУ и Vision — это не совсем одно и то же. Точнее, совсем не одно и то же. Я об этом даже писал как-то (см. «Ловушка вторая»):
www.webursitet.ru/article/terminologicheskie-lovushki-gost-34.html

А грустная история про врача очень хорошо иллюстрирует это высказывание:
самым простым способом оптимизации производства является изменение бизнес-процесса в организации


imho при внедрении любой новой системы нет ничего сложнее, чем изменение бизнес-процесса в организации. Бизнес-процесс — это поведение людей, и больше всего сил уходит на то, чтобы его изменить.

Подстроить бизнес-процесс под инструмент можно сравнительно легко только там, где этот инструмент даёт явные преимущества всем его участникам. Например, если вы внедряете АБС в банке, в котором до сих работают только с экселем, то вас наверняка встретят с распростёртыми объятиями (правда, таких банков уже не осталось). А вот при попытке поменять одну АБС на другую вы наткнётесь на жёсткое сопротивление пользователей на всех уровнях: процессы уже устоялись, и поменять их можно только боем, с кровью и потерями.
Концепция по ГОСТУ и Vision — это не совсем одно и то же. Точнее, совсем не одно и то же.

Greesha, я не ставил в один ряд ГОСТ и Vision, а лишь сказал, что оба указанных подхода отталкиваются от Проблемы.

Подстроить бизнес-процесс под инструмент можно сравнительно легко только там, где этот инструмент даёт явные преимущества всем его участникам. Например, если вы внедряете АБС в банке, в котором до сих работают только с экселем, то вас наверняка встретят с распростёртыми объятиями (правда, таких банков уже не осталось). А вот при попытке поменять одну АБС на другую вы наткнётесь на жёсткое сопротивление пользователей на всех уровнях: процессы уже устоялись, и поменять их можно только боем, с кровью и потерями.

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

Был в моей практике пример, когда в организации заменялась информационная система. Так пользователи просто отказывались работать в старой системе, видя как их коллеги работают в новой.

А все почему? Потому что, в первом случае, функциональность программного продукта никак не соотносилась с потребностями пользователей, в то время как во втором, реализованная функциональность прямо коррелировала с выявленными потребностями и удовлетворяла их.
2 факта не дают возможности перейти к универсальному обобщению.
Какой диссер? Это пересказ пары глав из книжек про требования.
о, какую редкую и интересную тему вы затронули!

Хочу предложить пару дополнений:

ИТ-проекты выполняются не только для решения существующих или будущих проблем, но и для реализации возможностей. Хотя с возможностями всё гораздо хуже — заказчики менее мотивированы их финансировать, выгодна от них более эфемерна и т.д.

Мой опыт показал, что отталкиваться от проблемы в построении проектной цепочки хорошо, но надо научиться правильно выявлять проблемы. У большинства моих учеников (а это уже действующие не один год специалисты) большая путаница с тем, что считать проблемой и как с ней работать.

Поэтому хочу предложить ещё несколько терминов и компонентов модели для ситуационного анализа, кроме проблем:
1. Собственно Ситуация — совокупность контекста, действующих лиц, их интересов, фактов, проблем, причин и последствий.
2. Факт — некоторое существенное обстоятельство реальности, единичное или систематическое.
3. Причина — вид факта, который порождает проблему.
4. Последствие — вид факта, который порождается фактом-проблемой.
5. Проблема — вид факта, который порождает последствия, наносящие ущерб ЗЛ (деньги, время, репутация, здоровье, мотивация, настроение).

Почему я предлагаю понимать проблему именно так?

Потому что иначе в качестве проблемы берётся, например «У нас нет CRM». И в парадигме «проблема — это разница между желаемым и существующим» (которая мне тоже раньше нравилась) получается всё формально корректно:
* Текущее состояние — CRM нет
* Целевое состояние — CRM есть.

И всё, поехали в качестве результата и цели проекта ставить «Внедрить CRM» со всеми вытекающими :)

А если проанализировать последствия того, что CRM нет, то можно обнаружить много интересного и выйти на реальные проблемы, типа «потери клиентов» и т.д. И увидеть, что отсутствие CRM является не единственной возможной «причиной», а есть ещё и отсутствие правил работы, конфликт интересов сейла и руководства и т.д.
Да, в нашей культуре слово «проблема» носит исключительно негативную окраску, равно как и слово «конфликт», например. Но это очень узкое понимание термина.

Потому что иначе в качестве проблемы берётся, например «У нас нет CRM»

В статье сказано, что наличие или отсутствие автомитизированной системы не может являться проблемой — это предположение заинтересованного лица о том, что операция по ее внедрению изменит сложившуюся на предприятии ситуацию. Какую ситуацию? Выяснить это и является задачей проектной команды (в частности, аналитика) и потом внедрить не просто CRM, а CRM с требуемой функциональностью.
В каком именно месте это сказано?

То, что говорите вы тут в комментарии «это не проблема, найдите настоящую проблему» — это классическое «мышки, станьте ёжиками». Как именно найти настоящую проблему? Об этом надо рассказывать, а не только мантры «думайте о пользователях», «учтите риски», «взвесьте все за и против», «решайте настоящую проблему», «начинайте сначала, а как дойдёте до конца — заканчивайте».
В каком именно месте это сказано?

В разделе «Природа требований к программному продукту» сказано, цитирую:
Если в процессе размышлений о способе решения проблемы ЛПР придет к выводу, что достижению поставленной цели будет способствовать автоматизация деятельности организации, то одной из разрабатываемых им операций станет внедрение соответствующей информационной (автоматизированной) системы.

Как именно найти настоящую проблему?

Анализ способов выявления проблемы и формирование образа решения не являлся целью настоящей статьи.
Я кстати не понял, как из списка причин срыва проекта следует, что всему виной — требования.

Недостаточное вовлечение пользователей и менеджмента, например — это недостаточное вовлечение. А требования — это требования.

С ежедневными итерациями (общаемся с пользователями и топами утром и вечером), например, можно создать ПО/систему и без всяких требований.
beskov, а разве общение с пользователями и менеджерами (топами) не порождает требования?
Агилисты, например, считают, что нет. И мне эта точка зрения импонирует.

В некоторых подходах считается, что пользователи и менеджеры описывают проблему, а команда проекта создаёт набор решений этих проблем. Но ничто из этого не называется «требованием».
«Считается» — очень подходящее слово. На деле же оказывается иначе — пользователи и менеджеры формулируют свои пожелания к поведению программы, а команда проекта сначала выясняет чем поможет пользователям требуемое поведение, а уже потом предлагает соответствующее программное.
А разница в том, что зачастую пользователи не могут сформулировать решаемую проблему и необходимо вместе с ними к ней придти, а уже потом решать.
Ну а для этого уже и существует роль аналитика/product owner, как посредника между ними, чтобы вернуть первых от разговора про требования и кнопочки к разговору про ситуацию, проблемы, результаты.

Пользователи же описывают свои потребности не сами по себе, в виде «заполните бриф».
И мы вернулись к посылу статьи — выясняй проблему, потом делай! ))
Ловлю себя на мысли, что представленный план довольно статичен. То есть принимается как аксиома неизменность потребностей пользователей и уровня владением созданным инструментом. В моем опыте, довольно большое количество проблем решается более глубоким знакомством с используемыми инструментами работы. Конечно, для произведения действия необходимо зафиксировать стабильный уровень опытности пользователей, но очевидно, что его необходимо регулярно пересматривать и приводить в соответствие инструменты-уровень владения.

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

То, что вы пытаетесь сформулировать и преподнести как результат собственного исследования (по крайней мере, мне так показалось), давно известно и широко используется в кругах практиков тех самых «гибких методологий», которые вы упоминаете в качестве одного из второстепенных факторов успешности современных проектов.

В частности, стратегическое и тактическое проектное планирование, фокусирующееся на эффекте (читай: решении проблем и реализации возможностей), в последние годы находит всё большее распространение в ИТ сфере под эгидой техники «Карт влияния» (Impact mapping). Техника заключается в построении ментальных карт (mind maps), отражающих взаимосвязи между целями организации, вовлечёнными (прямо и косвенно) в достижение этих целей людьми, необходимыми изменениями в их поведении и конкретными программно-аппаратно-административными-… мерами/инструментами, необходимыми для воплощения этих изменений в жизнь.

К сожалению, время сейчас не позволяет, но, если интересно, я могу проработать с помощью этой техники пример с «хранилищем медицинских данных о состоянии здоровья населения». Разница с вашей табличкой будет колоссальная. Хотя даже моя «Карта» всё ещё будет сферическим конём в вакууме, потому что строить её будет всего один человек, который при этом ещё и слабо знаком с вопросом. Мне придётся делать огромное количество предположений относительно каждого из уровней, точно так же, как один ЛПР вынужден делать предположения, как минимум, относительно того, какие реальные изменения в поведении необходимы и какими инструментами они могут быть обеспечены. Все эти знания не могут находиться в голове одного человека (если, конечно, он не гений, которыми человечество, увы, не особенно располагает) и даже при их наличии всё равно остаётся высокая мера неопределённости, связанная с изменчивостью предметной области и мира в целом.

Именно поэтому «Карты влияния» — коллективная техника, направленная на вовлечение и со-трудничество как можно большего числа релевантных людей, чьи знания, опыт и интуиция могут существенно снизить число неверных предположений и помочь подобрать оптимальные инструменты для достижения цели. И именно поэтому такие проекты реализуются итеративно с постоянной проверкой остающихся предположений и постоянным пересмотром планов на основе этих проверок-экспериментов.

Если вдруг будете в апреле в Минске, приходите на Analyst Days, я буду рассказывать там на примере конкретного открытого проекта о применении этой техники в рамках комплексного подхода. А после можем пообщаться.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.