Стадии описания цс

Когда в десятый раз переделываешь описание целевой системы, открывая чистый лист и начиная все с нуля, вдруг понимаешь, что:

  1. Хочется уже создать шаблон описания, в котором прописана последовательность шагов и нужно только заполнить необходимые поля, а на выходе получить список работ с разбивкой по дедлайнам.
    Если такое уже есть, то киньте в меня ссылкой)))) Если нет - хоть помечтайте со мной)))))
  2. Как же хорошо организовано обучение в ШСМ: я уже не помню, какой именно учебник окончательно вбил в мою голову последовательность работы над проектом, при которой таки остаются на месте все важные детали!! (То ли Системное мышление, то ли Системное саморазвитие, то ли ОДО) Все, что хочешь использовать (вплоть до удачных формулировок рекламных текстов), находит свое место и потом несложно это место найти (в системном описании, а не в куче описаний и сопутствующих документах).
  3. Из ответа на вопрос: “что конкретно я хочу поменять в реальности?” вырастает (первая, рабочая) формулировка целевой системы.
  4. Из чеклиста отбора возможностей (это в Системном саморазвитии было) вырастает черновик всего описания, но в кратком варианте, который позволяет пройти так называемый lift-test.
  5. Определив предпринимательскую гипотезу, никуда не денешься от необходимости вписать ее в реальный мир, поэтому следующим шагом изволь определить надсистему, в которую физически (то есть прям вот вложена как матрешка в матрешку - и отсюда весь этот разговор про матрешку) входит ЦС.
  6. Когда поднялся на уровень надсистемы, то можешь увидеть и системы в окружении, которые как-то связаны с твоей ЦС (не путать с "нашей системой" - про которую я пока понимаю только в теории).
  7. А когда уже знаешь про надсистему и про системы в окружении, то у тебя уже есть список внешних ролей - то есть тех, кто будет как-то взаимодействовать с твоей целевой системой, и поэтому у каждого из них к ней будут требования, но выражены они скорее всего будут в виде потребностей, причем на уровне надсистемы.
    А вычленить из потребностей требования - это уже твоя задача (если ты в одно лицо все это пилишь, а если в команде, то если правильно понимаю - инженера по требованиям).
  8. И вот тут меня посетила красота!
    Потому что придумывать из головы, чего же может захотеть будущий участник создаваемого курса, очень сложно!
    А вот если понять, какую задачу следующего уровня (в Надсистеме) он сможет решить, когда пройдет предлагаемый курс, то вычленить его пожелания к целевой системе уже гораздо проще.

    Пример сегодня вот какой:

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

Впереди - переход от требований к архитектуре и потом к подсистемам. 

Буду рада получить обратную связь о том, что можно сделать лучше.

Заранее спасибо!

1 лайк

Елена, спасибо за пост!
Отлично, что продолжаете размышлять, несмотря на трудности, и публикуете посты)

Сложность с выделением ЦС в том, что она субъективна и выделяется вниманием в зависимости от цели) алгоритмов выделения – нет, потому что это предпринимательская (надсистема) и менеджерская (система обеспечения) области интересов более единообразны, а вот инженерная область (ЦС) супер-разнообразна.

Учебники у нас согласованы по содержанию, они все нужны для формирования “единой картинки”, “мастерства”, так что много идей в разных контекстах с разными объяснениями гоняются по кругу, чтобы прошла “пропитка” и СМ “завелось”, встало на рельсы в мозгах) хорошо, что получается)

О ЦС еще очень удобно так: сначала в мире <чего-то> не было, после моей деятельности в мире <что-то появится и как-то будет влиять на других>. Что такое появится в мире после моей деятельности, чего раньше не было? Что эта штука позволит мне делать такого, что я раньше не могла?

По поводу курса: рекомендую явно назвать ЦС курса и дальше вставить как раз ваши предположения по поводу того, от чего страдает будущий участник и зачем он к вам придет. Потом – применить практики исследования потребностей и понять, что за боли у вашей ЦА на самом деле, как они описывают свои боли. Для этого рекомендую погуглить практики “кастдев”, почитать книги вроде “Спроси маму” Фитцпатрика, почитать о практике Jobs to be done / JTBD, по которой можно почитать начало книги Замесина по кастдеву. Зачем это надо:

  • вы не ваша ЦА. Если вы долго работаете по профессии, то есть риск, что вы начнете ассоциировать / путать себя со своим клиентом и предполагать за него, чего он хочет. Это не конкретно ваша проблема как человека или исполнителя роли, это вообще распространенное заблуждение среди исследователей. (Я по работе в должности продакта, продакты такой практикой пользуются и частенько такое искажение "зарабатывают".)
  • требования к вашей ЦС (курсу) будут глупыми. С этим надо просто смириться)) ваша задача – сделать их менее глупыми (за счет практики исследований как поиска инсайтов (предпринимательство) и практик инженерии требований). Илон Маск в недавнем интервь-туре по Starbase (предприятие, которое производит ракеты) оч круто об этом рассказал. По ссылке видео начинается как раз с рассказа о его 5-шаговом процессе, используемом на производстве (your requirements are dumb). Рекомендую посмотреть вообще все 3 части интервью от начала до конца)
  • Всегда спрашивать себя: на чем основано это требование? на моей уверенности, на каких-то свидетельствах вроде "а у меня есть пара друзей", или есть какие-то реальные данные (интервью с 10-20 представителями потенциальной ЦА, проведенные согласно практикам выше, данные аналитики по прошедшим курсам и тп)?
  • Когда лучше поймете потребности ЦА, как она их описывает и тп, тогда только можно углубиться в подсистемы целевой или начать продумывать систему обеспечения. И в процессе лучше продолжать с потенциальной ЦА разговаривать (не "поговорили – и хватит", а разговаривать регулярно, раз в неделю-две). Требования и архитектура еще не раз поменяются)
Если хочется быстро понять, зачем вообще эти интервью, то можно сравнить 2 поста Яны по описанию ЦС "садовые ножницы". В первом посте были сложности с описанием ЦС, поэтому Яна позвонила подруге-садоводу и проинтервьюировала ее: для чего и какие ножницы она использует. Второе описание в результате было куда круче. Это был отличный ход, который мы не подсказывали, и который Яна взяла сама (практики на стыке предпринимательства как поиска возможностей / инсайтов и инженерии требований). Рекомендую и вам тоже взять эти штуки и применять)
1 лайк

Анна, спасибо большое за подробный ответ!
Особенно за подсказку про регулярный разговор с ЦА. Буду применять!

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

На ФБ публиковала пост тут:

Не знаю, может, стоит тут тоже опубликовать, вдруг кому надо?

Спасибо за очень ценное замечание про то, что автор курса не является ЦА курса, хотя это вроде как самое простое - сделать как для себя, но вы совершенно правы, что это вносит искажение, которое потом мешает.