?

Log in

No account? Create an account

Требования к создаваемой системе. Практическое руководство по инжинирингу требований (черновичек).
alexander pavlyut
deppkind
Управление требованиями - это логистка требований.

Многие считают что управление требованиями это и есть процесс выявления требований. Нет это не так.

Требования выявляются как-то кратко если то вот:

  1. Декомпозируем так называемое ТЗ от клиента. В самом начале мы вообще пишем все хотелки в любом формтате (обычно построчно сюда выгружаем то что присылают клиенты с гордным именованием Техническое Задание) в простой список нужд.

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

  3. Потом каждую их этих нужд надо отметить "тегом" или меткой чтобы после отработать по теме.

  4. После по каждому тегу или метке записать все хотелки в простом формате: Я хочу _хотелку_ для того чтобы _получаемая_польза_через_хотелку_ и я вижу решение (хочу чтобы были розовые кнопочки) этого так _возможное_видение_решения_.

  5. Финальный список даем таких "требований" (система должна ДЕЛАТЬ) и ограничений (система должна делать это ТАК) - это и есть требования.


На требования пишутся уже решения, или то что назвается Техническое задание в производство.

Клиент его никогда не напишет потому что у него нет образования говорить на языке производства.

В моих альфах управление - это запись (созданного), извлечение, хранение, аткуализация и предоставление нашего артефакта заинтересованным лицам в нужный момент времени.
Создание в информационной системе записи это не процесс создания требования, поэтому тут отдельная история о которой я вам поведую.
В требованиях нам обязательно нужно отразить что именно хочет клиент и как он это себе представляет, чтобы связать это с контекстом требования, потому что даже изготовленная система согласно требованиям, которые может подписать клиент благодаря пробивному менеджеру проекта в итоге может не соответсвовать его нуждам - а это все про качество и сервис клиента, так что момент в первую очередь важный для исполнителей, клиент должен удовлетворить свои потребности, а не "пройти" по вашему контракту и тз с ощущением что его в итоге "развели" как несведующего.
Эти нужды необходимо выявлять и фиксировать - это является основой для извлечения требований.
Требования рассказывают что делают стейкхолдеры с системой (а не то что делает система).
Важно понимать что требование - это любое условие, которому должна соответствовать система, должно быть:
Требование должно обладать следующими характеристиками:

  1. Единичность — требование описывает одну и только одну вещь.

  2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.

  3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.

  4. Атомарность — требование нельзя разделить на более мелкие.

  5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.

  6. Актуальность — требование не стало устаревшим с течением времени.

  7. Выполнимость — требование может быть реализовано в рамках проекта.

  8. Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.

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

  10. Проверяемость — реализованность требования может быть проверена.

Мы пишем требования в формате JobStory:
Находясь в __контексте_ситуации-context__ (под воздействием _внешней_принуждающей_силы__) я как __стейкхолдер__ хочу что-то сделать с система имела  __возможность_как_требование__, для того чтобы сбылась моя _хотелка-userneed__.
Необходимо указать артефакт-обоснование что данное требование решит потребность.
В результате составленного списка требований мы извлекаем стейкхолдера и модели данных, которые точно так же подшиваются к требованию, а так-же извлечение алгоритма (критичного для клиента правила поведения).
На основании данной информации мы составляем базовые последовательности - воздействия пользователя в месте входа - выдача от системы в месте выхода.
После этого хотелка считается отработана и закрывается - от нее остаются только требования.
После того как у нас извлечено большинство требований мы спокойно переходим к построению архитектурного описания.
Итак, начнем с того что архитектура решения есть всегда.
Для того чтобы сделать хорошую архитектуру - необходимо иметь знания о различных видах архитектуры, и поддерживать навыки их создания и эксплуатации, чтобы "мочь" хотя бы их повторить, а тем более описать.
Также нужно использовать ТРИЗ для поиска наилучших архитектурных решений.
Архитектура системы задается интерфейсами - страницы, элементы, кнопки. Вот как раз на языке этой архитектуры описывается решение.
На архитектуру навешивается взаимодейсвтие с системой по сценариям в деталях. UseCases.
Это и есть контрольная конфигурация выпуска.
Рабочая документация - это и есть то самое Техническое Задание которое нужно реализовать, оно состоит из сценариев, экранов, структур данных, и тд.

После каждый сценарий передается в работу при помощи описания - как это сделать сотруднику. Но это совсем другая истрория.

Про дизайн и искусство в наших буднях.
alexander pavlyut
deppkind
Есть компания X и она радостно пишет:

<<
1. Стратегия ....
2. Понимание клиентов ...
3. Метрики и измерения ...
4. Культура ...
5. Дизайн. Сделайте взаимодействие с клиентом удобным и красивым в каждой точке его путешествия — сайт, торговые точки или офисы, центр обслуживания клиентов и на каждой стадии его путешествия: поиск информации об услуге, товаре, выбор контрагента, покупка, пользование, сервис.
6. ...
>>
Еще раз - "... взаимодействие с клиентом удобным и красивым в каждой точке ... " - дальше можно не читать.

Я себе представляю "красивое" взаимодействие в салоне связи - это когда продавец стоит в костюме кардинала Решелье и делает пометки на пергамент.

Вот и хороший пример для указания на проблему понимания дизайна и искусства.

Фундаментальная разница в физике приложения двух направлений - дизайна и искусства - вот то что выдает невероятное количество проблем для ввода в эксплуатацию дизайна различных систем.

Дизайн - это как должно работать. С минимальными затратами энергии во всех плоскостях - электроэргии, тепла, интеллектуального напряжения.

Искусство (творчество) - это способ передачи внешнему миру путем изображения, звука, телесных угодий и прочего - своего личного взгляда (на что угодно), и в случае удачного стечения обстоятельств получения принзнания (одна из основных целей творчества) > как следствие повышения своей внутренней самооценки  -> повышение доминантности, своей исключительности. (https://www.youtube.com/watch?v=ydlTrw-AhHE&feature=youtu.be&t=40).

Дизайн - это когда удобно, ничего не мешает, не отвлекает и вообще не заметно в рамках выполнения основной деятельности.

Дизайн это когда уютно и комфортно - решать основную задачу!

Пока мы не решим задачу, нечему "наводить" уют и "красоту" - действия не приносят результат никогда: если вы разработчик или дизайнер и попались в эту вопронку прекрасно понимайте что пока вы неудовлетворите внутренние хотелки вашего клиента, работа будет считаться невыполненной и некачественной. Просто потому что клиент сам не знает в данном контексте что такое качественнно и красиво, и как это получить, попутно используя вас как удлинение своих рук которыми он таки может что-то там делать в этих ваших интернетах.

Это главная ошибка многих при создании систем которые будут использовать люди.

Елси уже мы говорим про уют - тогда мы устраняем весь дискомфорт в окружении клиента, находящегося в нашем салоне или на сайте в процессе совершения целевых действий.

Если вести цепочку из из интеллектуального напряжения можно понять что надо устранять любые стрессовые и дискомофортные ситуации для человека (нарпяжение любого рода нещадно уничтожает наши энергозапасы http://deppkind.livejournal.com/1596.html) - необходимо просто убрать все то лишнее, что мешает решать задачу.

А для этого нам нужна задача. Сформулированная, подтвержденная, согласованная, зафиксированная и неизменная на момент ее решения.
Искусство -> это про "показать себя" если мы говорим про корпоративное творчество.

Нельзя говорить про дизайн как про "стиль" и "цвета" при отсутсвие брендбука (https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D1%80%D0%BF%D0%BE%D1%80%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B8%D0%B4%D0%B5%D0%BD%D1%82%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D1%8C).

Когда мы говорим про стиль - это про брендбук.

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

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

Как сделать сайт (Блог / CRM / Магазин / Соцсеть / Лэндинг ...) и не сесть в лужу.
alexander pavlyut
deppkind
Быстрый ответ - вот простая последовательность:

  1. Определить что хотим.

  2. Сформулировать требования к целевой системе.

  3. Выбрать путь решения - готовый сервис / внедрение решения / собственная разработка.

  4. Внедрить.

Определяемся

Обязательно пишем назначение - какую пользу, кому и как будет приносить эксплуатация нашей системы.

Составляем простой список действующих лиц, заинтересованных (работающих напрямую) с системой, и влияющих на ее появление - это все персонажи, с которыми будет идти коммуникация на всем жизненном цикле от задумки до запуска.

Директор, менеджер, бухгалтер, smm спец - все кто задействован в назначении системы.

Составляем список хотелок от системы простым списком.

Выявляем требования

Требования это прослойка между реальным бизнес-процессом (не хотелкой) в компании и возможностями в архитектуре целевой системы.

Требования выступают контрольными точками, которые нам в итоге дают возможность понять система удовлетворяет требованиям или нет.

Требования конкретные к системе всегда нужны, потому как всегда возможны два варианта:

  1. Если ты не знаешь что ты хочешь, то любая система тебя удовлетворит.

  2. Если ты не знаешь что ты хочешь, то никакая система тебя не удовлетворит.

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

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

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

Поэтому требования нужны всем, и это важный кусок предпроектных работ.

Нельзя написать требования не зная бизнес-процессов в формате выходов и входов из них - а как я не раз писал, 90% малого и среднего бизнеса ничего не пишут, а хранят и накапливаю все процессы в своих киборгах (сотрудник + его комп);

Хотелки используются как входные точки в диалоге при поиске и выявлении реальных требований к системе. Я рекомендую применять метод JobStories (http://deppkind.livejournal.com/3259.html) который просто бомбит инсайтами (http://deppkind.livejournal.com/4344.html) на полную катушку.

Так как требования влияют на все дальнейшие движения проекта сильно волнообразно, им свойственно также появляться волнообразно или лавинообразно в процессе всего проекта, поэтому их важно заморозить после написания.

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

Почему требования "выявляются" и никогда не известны полностью:


  1. Бизнес-процесс не описан (не известен).

  2. Бизнес-процесс описан но в процессе формулировки требования и атаки инсайтами - бизнес-процесс сам по себе улучшился или определился в конечный вид.

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

Кому нужны примеры табличек хотелок+выявленных требований или просто шаблоны - велком, скоро будет на сайте.

Если кратко подсказать то требования описывают любую систему как "черный ящик" - мы понятия не имеем что там внутри и как она работает, но знаем что если мы тыкнем в нее пальцем, она нам подмигнет. Ни слова про то как она это делает, зато понятно что она делает и с кем.

Только в этот момент можно уверенно сказать что мы можем выбрать решение для себя, и понять что нам нужно.

Выбираем пути решений

Сравнивается предложение существующего рынка - нужно составить список целевых систем которые предлагает рынок.

Нужно четко имеет ввиду что большинство популярных проблем бизнеса уже давно решены, и внедряются за 5$ / мес. Поставка через сервис существенно экономит бюджет, давая качество хорошей системы, разработку которой можно не поднять и за пол года, с хорошей командой разработчиков - вот и тут начинается сравнение.

Разработка собственного решения, а не внедрения существующего обоснована и возможна только после ответов на вопросы:

  1. Существующие решения точно не перекрывают составленные требования - об этом свидетельствует сравнительная таблица существующих функций систем против ваших требований.

  2. Требования точно не перекрываются, и изменение хотелок под одно из существующих подходящих хотя-бы уже на 50-70% решений (подвинуться в хотелках и выбрать то что есть) существенно снижает получаемую итоговую пользу от внедрения в таком усеченном формате требований.

  3. Решение согласуется с требованиями, формат его поставки SAAS - риск отказа системы в эксплуатации по различным причинам (сеть, банкротство, атаки, сбои, прочее) - принесет существенные повреждения бизнесу, остановит деятельность или создаст угрозу его прекращения ввиду финансовых и прочих появившихся проблем.

  4. Решение согласуется с требованиями, поставка решения идет путем внедрения - стоимость "внедрения" в работу компании выше стоимости создания собственного решения на заказ или своими силами.

Если с требованиями справились и ответили хотя бы на один пункт ответ - да, значит вам нужна собственная разработка.

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

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

У меня в студии этот тариф называется "Жигули" http://www.deppkind.com/devprocess#soluton, аналогия в названии выбрана не случайна и не является приколом, это простым языком сказанные вещи понятные всем - из точки А в точку Б вы доберетесь и на жигулях и на БМВ.

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

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

P.S Про то что должно быть на лендинге, что должна делать crm система и в целом про примеры требования в следующих сериях.


Всем систем и осознанности,
всегда ваш - Саша Павлють.

Осознанный бизнес. Атака инсайтами.
alexander pavlyut
deppkind

С завидной регулярностью от проекта к проекту (по разным видам услуг за последние 8 лет) собственники бизнесов меня часто спрашивают - зачем то или иное действие.

Показываю суть старым баяном:

- Клиент: "Я ни в чем не разбираюсь, ты тут специалист, поэтому давай говори как надо делать"
- Консалтер: "Делай раз, два, три"
- Клиент: "Я не согласен что это [сработает/то что мне нужно]"
- занавес.

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

Или же у клиента выявляется (осознается) четкое понимание после "контрольных вопросов и задач" что следование выполняемым рекомендациям приведет к краху текущей "мутной воды" разведенной руководством в предприятии, на которой построено управление, подробнее я пишу об этом тут - http://deppkind.livejournal.com/3696.html.

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

Deliverables. Результаты - что на самом деле получает клиент.

Причины именно того что по моему мнению многие консалтеры (и я в том числе какой-то период ранее)  сами не "осознают" что именно они дают клиенту, что именно клиент получает только от них а не сам, и что именно клиент без консультанта не получит никогда - инсайт (осознание / озарение) в голове клиента после контрольных вопросов консультанта.

Вот что остается у клиента по факту дискуссии:


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

  2. Переданный навык / метод проработки информации и проблем (у каждого хорошего консультанта всегда куча трюков в рукаве и подробных табличек).

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

Клиент получает свои инсайты в результате воздействия на него консалтера - уже полно бенефисов. Обычно в этот момент у клиентов глаза горят и это видно.

В виду того что консалтер - это носитель намного бОльшего количества "конфигураций" разных видов бизнеса - как раз делает его хорошим источником для возникновения нужных инсайтов у клиента. Это надо понимать и об этом вести переговоры.

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

Может ли клиент сам себя консультировать?

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

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

Даже понимая все КГБшные трюки по стимулированию мышления, памяти через картинки образы и контрольные вопросы - если человек погряз в своем деле по уши, то у него есть все шансы вытащить себя за косичку из болота только если он сам Барон Мюнхаузен.

Поэтому показывая себе картинки (какие?) и заполняя таблички (какие?) отвечая на вопросы (какие?) предприниматель не получит результатов как если бы это делал для него консультант.

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


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

Сейчас я собрался с мыслями и разложил тему инсайта по полочкам. Поехали.

Инсайт и озарение. Нейронная сетка.

На самом деле авторами идей или замыслов мы с вами не являемся. Мы - это как многие называют себя хозяевами своего организма по части управления им. Как вот захотел - так и получилось. На самом деле нет.

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

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

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


  1. Появляется входящий импульс - свет, звук, ощущения, энергетические импульсы и все прочие которые известны и не известны пока науке.

  2. Проходящий импульс пробегает (проверяет похожие) по связям нейронов оставляя еще более заряженные ионы в днк где он уже прошел

  3. Тем самым создавая новую версию информации - фото видео звук ощущения - и все это "укомплектовывается" а старое и нетронутая связь уничтожается (просто поле разряжается).

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

Пример прохода нескольких импульсов (каждый одним цветом указан):

Теперь медицинско-химические факты:

  • Процесс распознавания образа составляет около 10 (в минус первой степени) секунд. За это время один электрический сигнал может пройти максимум через 6 000–7 000 нейронов.

  • При узнавании существует двойное движение информации: от органов чувств к нейрону и из запоминающей среды к другим участкам мозга.

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

  • Процесс создания очередной магистрали не может превышать время распознавания образа.

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

Такую логику реализует нейрон при электрической форме представления информации.

Все подробности про нейроны в гугле, это целая длинная тема. Хорошо об этом в целом говорит Воловник в своей книжке 2002 года - "Знакомьтесь, информационные технологии", постоянный источник цитирования это Савельев и любые его работы про мозг. Гугл в помощь.

В общем итоге потоки в нашей голове по магистралям огромные и постоянные.

В общем именно благодаря такому устройству мы обучаемы.
Как говорил дедушка Ленин - "учиться, учиться, и еще раз учиться" (на самом деле он говорил еще более важную вещицу, о ней чуть позже).

Факт того что мы постоянно подключены к "сетке" экосистемы нашей планеты для большинства ученых мужей простой обычный факт, даже не буду ссылки искать, считаем это фактом - мы все части большой системы.

Теперь разберемся как у нас происходит то что в омерике называют "инсайт" - можно озарение, но я предпочитаю четкий термин осознание.

Осознание - касание артефактом реального мира нашего мозга (моя формулировка).

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

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

Вот пример 69 года того как человек смотрит на картину и что в этот момент у него в голове крутиться:




На изображении четко видны:


  • различные виды интерпритации и корреляции

  • онтологии по теме

  • прочих "зверей" синонимов-антонимов.


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

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



На картинке показано как консалтер/коуч/трекер/специалист "извлекает" из клиента нужную клиенту информацию, которую сам консалтер знать не знает в принципе и знать не желает:


  1. (на картинке шаг 0) - Бобмардировка извне. Консультант воздействуйствует на клиента всеми необходимыми конструкциями и инструментами (вопросы, формы, таблицы, изображения, видео, анкетирование - любые формы структуры в которые надо заполнить информацию).

  2. (на картинке шаг 1) - Инсайт. У клиента в момент "бомбардировки" консультантом возникает "Идея" или "Понимание" или "Вот я разобрался"

  3. (на картинке шаг 2) - Материализация. Чтобы это извлечь из состояния нейронов и ноликов-единиц своей информации клиенту принудительно нужно это "сформулировать" человеческими формами реального мира чтобы записать смысл понятными словами (именно словами, а не ссылками на картинки или какие-то целые сайты) - формулировка это "Гробик для мысли" (с) Анатолий Левенчук.

  4. (на картинке шаг 3) - Извлечение. Тут мало помех консультанту если мы на встрече (физика общая), и много если мы по скайпу (практически нет физики).

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

  6. Выход в физику - тут уже пошли документы, проработки и тд. Первая физика это всегда бумага с резюме + я присылаю всякие там брифы и аудиозаписи на всякий случай - тут уже пошел процесс того как устроено производство услуги или продукта о котором идет речь. Физика плавно перемещается в физику продукта и услуги. Как она там стыкуется, уже не важно.

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

А теперь у нас начинается удивительное путешествие инсайта из кортекса в неокортекс.

Онтология и ее друзья альфы бизнеса

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


  • В одной компании продают образцы - в другой товары.

  • В одной - коробки, в другой - упаковки.

  • В одной - мажа это одно, в другой - маржа это то что считает владелец.

  • В одной - продажи это одно, в другой - продажи это во времени что-то третье.

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

Базовая онтолгия витает в воздухе и более мене ее понимают как-бы все, но хранится она в головах (конкретно в кортексе) сотрудников. Такой распределенный дата-центр важной бизнес информации завязанной на неустойчивые узлы и хранилища (увод бизнеса и кража информации на самом деле начинается с ухода менеджеров которые много знают о бизнесе из боевых полей, но практик изъятия из них этой информации нет).

То есть тут растут ноги многих проблем - от управления и обучения персоналом, до контроля, а без контроля нет развития, также быстрого развития и расширения, или улучшения качества и тд.

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

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

Есть интересное возражение в момент создания книг продаж - бизнесмены мне говорят что зачем ее сейчас писать, если нам непонятно и так как мы работаем, процесс не устаканился, и эта работа не принесет результат. Окей.

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

Также это осознание в голове мешает работать с глубинной информацией потому что сам факт держания ее в неокортексе забирает все внимание на себя.

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

Гроссмейстеры и шахматы VS Бизнесмены и их бизнесы

Шахматные гроссмейстерам не нужна доска. Долгое время игры в шахматы отработало нейронные сгустки компетенций по этому вопросу у них в голове, и им в итоге достаточно просто "держать" в своем неокортексе не одну шахматную доску и все фигуры на ней. Он играет в голове, а к доске подходит просто чтобы нам передать информацию о своем ходе передвинув фигуру.

Может ли неопытный в шахмотах человек так держать "крепко" связи в голове? Нет - нам всем нужна доска чтобы "смотреть". Увидеть "картину" периодически просматривая на одну и ту же фигурку прикидывая ее ходы.

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

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

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

Мало того ее еще нужно всем сообщать и передавать - это тот самый набор внутренней вселенной, в которой как раз все сотрудники и компания существуют.

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

Я вот слабо себе представляю коллективного гроссмейстера - где у них общий неокортекс, причем один на всех?

Вот и правильно - общий неокортекс это на самом деле экзокортекс, где все описание компании - вся информация о компании описывающая и регламентирующая ее деятельность. Эта информация не появляется просто так - бац и написали работающие процессы. Сам процесс осознания этих процессов начинается со "съема" реальной информации с носителей в базовую черновую версию.

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

Последовательности это всегда чек-листы.
Чек листы формируют своего рода когнитивную сеть, в которую попадают все ошибки мозговой деятельности, характерные для каждого человека и объясняемые недостатками памяти, внимания и сосредоточенности. Благодаря этому перед человеком открываются широкие дополнительные возможности.
Одним из важнейших шагов на пути к мастерству является желание и умение передать другим свои знания. А, как говорится в известной китайской пословице «Худшие чернила лучше, чем самая лучшая память».

Подводя итог всему сказанному скажу что жизнь любой информационной системы начинается с построения книги бизнеса (продажи, производство, обслуживание). Потому что формальное описание чего-либо – хороший способ для индивидуального и коллективного осознания. Общая информация о бизнесе это не "гробик" для описаний, а рабочий инструмент. Всегда должен быть назначен ответственный за фиксацию, хранение, извлечение и предоставление доступа к актуальной информационной "конфигурации" в момент времени заинтересованным лицам.

Вот что дает компания хотя-бы базовое описание знаний о бизнесе находящееся в общем месте в информационной системе (информационная система, книга продаж, производственная книга - общие знания):

  • Лучшее осознание. Формальное описание чего-либо – хороший способ для индивидуального и коллективного осознания.

  • Фиксация и повторное использование знании - изучение с нуля того, как делаются определенные вещи, очень дорого (по времени и деньгам).

  • Уменьшение вероятности пропуска или искажения шагов - некоторые шаги процесса могут быть пропущены или искажены по забывчивости или по незнанию.

  • Обучение - для того, чтобы обучать других тому, что мы делаем, мы должны знать, что мы делаем, а для этого необходимо описание.

  • Измерения - мы не сможем узнать, есть ли какие-то улучшения, если мы не знаем, что мы делаем.

  • Согласованность - мы будем действовать более согласованно, если мы все будем играть по одним правилам.

  • Удовлетворение требовании клиентов - клиенты, как правило, отдают предпочтение исполнителям, у которых определены процессы.

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

Всем сбыта мечт!

Сайтов не существует - есть лишь информационные системы
alexander pavlyut
deppkind
Системы с веб интерфейсом плотно сплетенные вокруг любого бизнеса.

Недавно наткнулся на статью Токовнина http://siliconrus.com/2015/07/digital-is-dying/ в которой он сообщает что рынок разработки сайтов помирает.

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

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

Дело все в том, что любой нормальный бизнес идет по своей дороге развития двумя путями - либо вверх, либо вниз.

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

Ни в коем случае коробочные продукты плохими не являются, а даже наоборот - хорошая коробочка в умелых руках это отличный инструмент.

Просто возвращаясь к статье я понял что на рынке сайт за три рубля я никогда не присуствовал просто по определению, потому что рынком это не счиал никогда.

Я же за здравый смысл и понятные цели, нужные результаты, выдача в общество и так далее, а как это связанно с бизнесом и битриксом мне не совсем понятно.

Коробки закрывают чьи-то потребности на уровне закрыть вопрос внутри компании у того кого на это крайним назначили, или там штрафы не штрафы.

Также коробки закрывают непроффесионализм коллег по цеху - а именно студентов и прочих “придаточных” разработчиков которые на самом деле не были никогда веб разработчиком, а всего-лишь менеджерами по продажам битриксов и всяких юми, с сомнительными навыками обслуживания этого же продукта далее (что собственно 1С пытался решить созданием форумов знаний там и тд и тп, что на выходе - очередная армия 1Сников пытающихся покроить веб).

Хорошие коробки сегодня - это веб сервисы, на которых можно зарегистрироваться и сразу пользоваться, если список потребностей перекрыватся услугами сервиса.

Вот сюда этот рынок разработки про который говорит Токовнин и нырнул - студентов криворучек заменили роботы. Ура.

Так как с 2004 года ко мне периодически обращаются с вопросом “тыж програмист”, я  для этого сделал специальный тарифный план “Жигули” (http://www.deppkind.com/devprocess#soluton - колоночка справа).

Уже в те годы из-под моих рук вышел продукт, требования к которому не удовлетворила бы ни одна CMS на тот момент - http://web.archive.org/web/20041208215018/http://www.wicanders.ru/index.php:


  1. Управление контентом - то место где вроде бы могла мопочь коробка, но не помогла

  2. Интеграция остатков с 1С - (да это было раньше не так просто с картинками и прочим, это вам не rails+aws / heroku а хардкорный php с заходом через прокси fpt с получением выгруженных из 1С самописных sql отчетов для обновления остатков сайтом)

  3. Базовый функционал личных кабинетов партнеров по россии.

  4. Macromedia Flash CD каталог с инсталером под винду, с обновлением из флеша (загрузка swf на диск и ассетов к ним) с сайта. (http://web.archive.org/web/20041220184151/http://www.wicanders.ru/cd.php)


В чем суть данных требований - тем что они продиктованы потребностями бизнеса напрямую (являются обоснованными и подтвержденными, а не хотелками), и закрывали конкретные задачи своим появлением.

А теперь про системы.

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

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

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

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

Информационные системы существуют везде где больше 3х человек заняты предоставлением услуги или продукта, но они имеют разные формы представления:


  1. Все плохо. Система находится в отдаленных уголках голов гроссмейстеров бизнеса с активным использованием кортекса в качестве места для извлечения и визуализации в процессе мышления информации по рабочим вопросам.

  2. Осознанность. Книга продаж. Информация извлечена из кортекса супергероев и перенесена в экзокортекс (т.е. записан на бумагу, документ, или засунут в компьютер в свободной форме). Не сильно контролируема и управляема.

  3. Автоматизация хаоса. Существуют отдельные системы внутри предприятия которые работают отдельно друг от друга, решая свои задачи, и компания не имеет “спайки” всего бизнеса в одну верхнюю систему, а получает данные через файлы, отчеты и совещания.

  4. Спокойный сон, пилотируемый полет. Внутренние системы (обеспечение продаж, производства и тд) - работают самостоятельно, но входные и выходные данные от каждой системы по бизнес-процессу передаются в федеративном формате и доступны для анализа, просмотра текущих статусов и принятия решений.


Какие можно перечислить виды информационных систем по их назначению в деятельности компании:


  • CRM (поддержка продаж)

  • PLM (проектирование)

  • ERP (сооружение и учет по деталькам в одно большое на выходе)

  • и EAM (эксплуатация сооруженного)

  • ISSUE Trackers (трекеры рабочих ситуаций),

  • Workflow engines (управление)

  • wiki (базы знаний),

  • Системы поддержки принятия управленческих решений,

  • Аналитика закупок.

  • Внутренние каталоги материалов,

  • Различные чек-листы и прочие контрольные проверки

  • я уже не говорю про все остальные системы “поддержки” и тд.


К примеру приведу кейс из проекта управления финтес-клубом.

Сначала клиенту нужен был сайт, а клуб он еще не построил - мы настояли и обосновали клиенту позицию что сайт с фейковыми картинками “типа клуб” не нужен, и будет только хуже.

Мы предложили и собрали лендинг (страница захвата заявок) - http://www.deppkind.com/cases/fitsolution/v1

Вот тут и начинается органический рост системы по ее потребностям - для работы с заявками понадобилось пристроить CRM систему http://www.deppkind.com/cases/fitsolutionncrm

Ну а когда фитнес построился и у него появились реальные потребности в сайте про клуб - мы сделали полноценный клубный сайт, собрав всю полезную информацию и представив ее для клиентов - http://www.deppkind.com/cases/fitsolution.

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

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

Зачем? Мы предложили решение и провели его в жизнь (понадобилось обязательное обучение под подпись) - мы выдали каждому сотруднику учетную запись, и дали возможность самостоятельно “заявить” о занятии.

Наша целевая женщина видела эти заявки и спокойненько их или одобряла, или отменяла, либо двигала время.

Дальше на сайте это расписание доступно для скачивания в ее любимом формате экселя, с которым дальше делали что им необходимо.

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

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


  • Нас интересует система диагностики бизнеса в любой момент времени в любом компоненте любого подконтрольного бизнес-процесса.

  • Заказ поехал - где авто, кто водитель, информация о машине для взаимодействия с реальным миром (номер, цвет, марка, год, vin).

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


Наши продукты в студии это всегда системы - внаружу смотрит что-то каталожное или новостное, или совсем простенькое, а внутри всегда мы захватываем кусочки управления бизнесом (фрэш например очень плотная система - http://www.deppkind.com/cases/myfresh/details), и на сколько это возможно укрепляем и развиваем ситуацию в компании, устраняя по дороге человеческий фактор.

Система обеспечения.

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


  • Как пример Issues Tracker с вопросами и принятыми решениями по ним с доступом к дискуссии в любое время в любом месте. (Была проблема, как решили, какое решение приняли, кто решил, какие результаты).

  • Например когда идет сам заказ - крайне важно окружить заказ информационной системой которая "сопровождает заказ" по всему его жизненному циклу внутри компании, а это уже у каждого своя ситуация вокруг каждого заказа.

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

  • Заказ - клиент, товары/услуги, суммы и тд

  • Информация о заказе - три раза звонил и ругался матом, сделал предоплату за 10 месяцев, не ту доску напилили. Это все issues которые куда-то надо цеплять и рассматривать, потом разбирать и делать выводы.


Так есть в каждом бизнесе - только не каждый бизнес это учитывает и ведет в системах, а значит бОльшую часть таких ситуаций руководство не видит.

Информационная система нужна в первую очередь для осознания, описания, управления и развития рабочего процесса.

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

Просто никто не понимает особо из известных мне руководителей, что любая передача информации подразумевает какое-то рабочее взаимодействие в части процессов в компании, а эти процессы нужно отмоделировать и передачу "эстафетной палочки" в сквозном процессе (workflow travesal) поддержать софтом. Это ключ.

Ну и как мы с вами уже понимаем - разумеется все это ни сейчас (ни раньше) нельзя "купить" в виде готового решения.

Развитие идет от поддержки рудиментарного workflow/issue tracking к полноценному гибко настраиваемому процессному/трекинговому движку, по мощности вполне сравнимого с промышленными системами документооборота/управления процессами/управления кейсами.

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

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

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

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

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

Обычно про последовательность работ, в которой не разделяют работы людей, компьютеров и других (как правило, интеллектуальных - внутри них либо сидит человек, как в экскаваторе, либо компьютер, как в автопилоте) инструментов, называют воркфлоу -- потоком/ходом работ.

Ну и чтобы два раза не вставать - любые крутые разарбокти и супер мега системы бессильны перед человеческим нежеланием в них работать.

Работают они только по принципу - если есть заинтересованное лицо и оно является пользователем системы - тогда можно рассчитывать что система начнет как-то жить и развиваться.

Если нет прямых заинтересованных лиц, тогда систему (что лучше) заводить в бизнес через внедрение в бизнес процесс (распечатывать из этого личного кабинета, отмечать результаты тут и тут по утрам и вечерам и тд):


  1. В инструкциях и под подпись. Это закрепляется приказами.

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

  3. Определение порядка отнесения публикуемых кусков проекта к какой-то из конфигураций. Это закрепляется приказом. (изменения постоянно происходят, система развиваются и внедряются как в случае с расписанием).


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

Собственно, вся системная инженерия устроена так же, в "повторении неповторяемого", в устранении супергероев-генеральных конструкторов и исполнителей бизнеса и переходу к рутинной работе специалистов по каким-то отдельным проблемам.

И информационная система должна это поддерживать явно, о описание метода должно содержать не только "процедуры", но и чеклисты, как объекты базового уровня, но об этом в следующих выпусках.

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

P.S. Рассматриваемый фитнес клуб год назад поглощен другим клубом и работ по нему мы не ведем, там свои нинзди и другой бренд.

Всем систем!


Только трансперенси во всех отношениях.
alexander pavlyut
deppkind
Недавно смотрел интересный видос про брендинг (https://www.youtube.com/watch?v=9Jt5a6V_fyM) и там была затронута очень хорошая мысль по поводу прозрачности в организациях - мол в паблик все вещают что да да, мы за прозрачность, мы супер прозрачны, а по факту получается всегда мутная вода.

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

Дело все в том что любая затея состоящая из двух трех шагов уже для многих оказывается неподъемным объектом для точнейгого описания, которое нужно поддерживать в актуальном состоянии в голове из раза в раз, по дороге не теряя смысл.

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

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

Как всегда мы знаем что никто ничего записывать не любит в принципе и боится этого дела - не в смысле кинуть абы что в почту, или чиркануть на салфетке, а составить полноценное описание видения и результата работ, и обозвать его публично - "Это наше описание того что мы хотим и делаем, и вот в третьем ящике оно лежит, вносить изменения можно только по процедуре с отметкой у Екатерины Петровны и по паспорту". Иногда по объемам это может быть камазик переписанной бумаги в больших проектах.

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

Одна из причин - это банальная ответсвенность. То что видно - нужно выполнять. К сожалению безответсвтенных руководителей на сегодняший момент я встречаю крайне много, точнее ответсвенных я за последнее время практически не встречал. Все наровят свалить в кусты от обязательств, с утодольствием пользуясь мутной водой, не смотря ни на что не признавая (но понимая в момент открытости) что могли соверишть ошибку и сделать неверное распоряжение, чего-то не учесть и тд. Пока что кроме трусости я тут оснований не встретил.

Это все те люди которые не знают что такое TDD -> RED Сначала обязательный фейл -> разбор результатов -> повторо попытки и GREEN !!

Ну не будем об этом я про другое сейчас.

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

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

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

Вернусь к открытости - открытость очень крутой инструмент, который при помощи всяких там вопросов "зачем, почему, для чего" очень быстро чистит мутную воду и делает из нее прозрачную в любом замысле где работают люди.

Открытость появляется когда что-то извлекается в артефакт - и тут все, вот он, его не забыть, его можно только выкинуть или с ним работать - он доступен для зрительного мышления всех кто на него смотрит. Бинго.

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

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

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

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

И если помыслы чисты - у нас не будет проблем.

Если же я что-то увижу или не получу ответ на вопрос - я всегда задам этот вопрос.

Только так создаются великолепные интернет-проекты.

http://www.deppkind.com/devprocess

У нас же есть техническое задание на систему / сайт / приложение / проект ...
alexander pavlyut
deppkind
Ситуация

  1. На входе в студию клиент (виртуально / реально не важно).

  2. Клиент хочет что-то заказать у нас - систему, сайт, приложение, аппу, что угодно - все что можно разработать и даже потом скрестить бульдога с муровьедом например (1С битрикс, просто 1С, другие системы и наша разработка).

  3. Высылает он нам нечто (как мы это видим), называя это "тз" (как он это видит) и говорит - оценить / посчитать / задать вопросы и далее везде, ожидая в ответ как правило получить вполне конкретную точную цифру и срок (беру пример крайней клиники) когда это будет готово.

  4. Ждет.

За годы работы я пришел к работающей конструкции в данной части воронки моих продаж - я всегда отвечаю на такие письма - отлично, получил, я вижу ваши пожелания к решениям в письме и, а тз вы забыли приложить?

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

Соглашение о терминологии


  1. Артефакт - физическое представление в реальном мире чего либо сотворенного человеком.

  2. Замысел - то что находится в голове или головах клиентов.

  3. Пожелания - артефакт замысла.

  4. Требования - согласованные с реальностью пожелания.

  5. Физика окружения - в случае с сайтом это все компоненты из которых он может быть изготовлен согласно консорциому w3c. В случае с мобильным приложением - это apple developer program или andriod development и тд

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

  7. Техническое задание - подробная конфигурация сооружаемой системы с описанием свойств характеристик назначений каждого элемента и компонента,  документ задание в производство, а также документ для приемочного тестирования.

Мухи отдельно - котлеты отдельно.

Рассмотрим очень коротенько жизненный цикл любого замысла и его реализации в реальность:


  1. Замысел (что) -> хотелось бы вина

  2. Пожелания (сформулировано зафиксировано) -> не послать ли нам гонца за бутылочкой винца

  3. Требования (контрольная точка) -> красное сухое французское

  4. Архитектурное решение -> будем потреблять дома из бутылок а не в розлив из бочки в ресторане.

  5. Техническое задание -> в магазине номер 5, выкупить 2 бутылки французского за 5 рублей каждую.

  6. Сооружение (производство, выполнение) -> сходили купили привезли показываем

  7. Получение (верификация) -> приняли по требованию, детали сверили с тз по необходимости.

  8. Ввод в эксплуатацию -> открываем бутылки

  9. Эксплуатация -> разливаем по бокалам, потребляем блага.

Еще раз с сайтом или мобильным приложением:


  1. Замысел (что) -> хотелось супер сервис который может делать дело

  2. Пожелания (сформулировано зафиксировано) -> нам нужен сервис который делает это дело X, Y, Z

  3. Требования (контрольная точка) -> сервис должен делать X, Y, а Z не возможно при наличие X и Y, давайте лучше H.  ОК.

  4. Архитектурное решение -> X мы сделаем как страницу. Y будет как игра, а H будет как запрос через форму.

  5. Техническое задание -> X 5 экранов (нарисовано), 24 элемента (отмечены, описаны все данные), назначение каждого (выход от работы), сценарии поведения каждого (нажал увидел победил), действующие лица эксплуатирующие (менеджер, домохозяйка на айпеде), результаты от выполнения такие-то (информация получена, ачивка пройдена, письмо отослано, информация о товаре передана в сборку на систему склада и тд ...)

  6. Сооружение (производство, выполнение) -> кодинг, сборка, тестирование по тз, прогон сценариев.

  7. Получение (верификация) -> деплоймент (развертывание в эксплуатационное окружение, appstore, amazon ...)

  8. Ввод в эксплуатацию -> принята работа, пошли баннеры реклама, регистрации.

  9. Эксплуатация -> сервис работает, конверсии растут, кеш заходит в кассу.


Кто кому что должен?

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

Для наглядности я изложил одному из клиентов схемку жизненного цикла одного(!) требования и по сей день показываю для ответа на вопрос что делать:






Если есть замысел то его необходимо извлечь из головы чтобы начать работу - поняли что хотим и записали. Это пожелания. Артефакты замысла клиента - это может сделать только клиент, замысел это его часть работы.

Обычно замысел в виде пожелания и высылают на почту ошибочно называя это техническим заданием, а это даже не требования.

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

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


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

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

Куда важней этот документ для производства внутри компании подрядчика, а также для контроля выходного продукта на соответствие всем заявленным требованиям и ограничениям - так мы получаем качество.

Вот простые правила предъявляемые мною к любому техническому заданию:

Требования к техническому заданию


  1. Техзадание должно быть

  2. Оно пишется исполнителем в противовес на согласованные требования и подписывается сторонами.

  3. Техническое задание содержит полное и исчерпывающее описание создаваемой системы в терминологии физики решения, в ее эксплуатационном окружении и четко недвусмысленно дает ответы на вопросы:

    • как именно по шагам отвечая на конкретные воздействия пользователя будет работать любой элемент системы.

    • как при этом он будет выглядеть

    • каково его назначение в рамках всей системы

    • как будет обслуживаться данный элемент в процессе эксплуатации и кем

    • и тд.


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

  5. Написано в паре со специалистом (с подтверждаемой квалификацией) в области системной инженерии требований и специалистом по проектированию взаимодействию с системой.

О требованиях

Требования - это описание (модель) системы к которому сбоку мы приписываем деонтическую модальность. (Анатолий Левенчук)

Отдельно стоит отметить что Бизнес требования - это тербования к тому как должна протекать деятельность системы.

Требования отличаются от пожеланий по простому принципу: требование = пожелание + обоснование.

Для того чтобы обосновать требование необходимо предоставить артефакты подтверждений что требования определены реальной потребностью и своим выполнением перекроют (согласуется с) миссию всего проекта (
http://deppkind.livejournal.com/1863.html)

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

| 1. требование | 2. для чего нужно |  3. возможное решение |

Не существует требований второго порядка, или вложенных - требования это конкретное требование к выдаче от системы во внешний мир - что система должна выдать в конкретный момент времени и места.

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

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

Примеры требований из реальных проектов:



  1. Каталог должен показывать (в глаза) товары

  2. Логистическая система должна выдавать маршрут (на бумаге, в электроном письме опять же в глаза и мозг) - чтобы выполнение доставки шло согласно плану.

  3. SMS о тренировках должны приходить на телефоны (устройства) - чтобы не звонить каждому.

  4. Страница товара должна передавать конкретную информацию x y z (в глаза) - для принятия решения о ...

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

Если какое-то пожелание из видения решения становиться крайне важным - оно перекачивает в раздел документа под названием "Ограничения на решение".

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

Все это позволяет синхронизировать онтологию мира клиента и нашу для более ясного взаимопонимания.

Когда у нас есть требования - дальше все отрабатывается на автомате - процесс просто выполняется. Тут уже дело техники - за хорошим исполнителем как правило не заржавеет.

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


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

Трассировка требований - это инструмент, позволяющий показать степень проработки и влияния требования на компоненты системы.

В этот момент можно понять степень влияния требований.
Требования поменялись - конфигурация поменялась - еще и указывает трассировку и степень влияния.

Требования подписываются сторонами. Требования легко меняются и дополняются постоянно в процессе работы, это фиксируется и не мешает работе. Требования пишутся клиентом - согласуются исполнителем, подписываются сторонами.

Если говорить о распространенных заблуждениях о том что нужно всегда формулировать выгоду от создания продукта или функции, всегда нужно иметь ввиду что мы говорим только о части работ по возведению системы в жизнь и эксплуатацию, и ни разу не говорили о бизнес стратегоровании или требованиях к бизнесу.

Чуть подробнее на поиск решения через Job Stories я писал тут http://deppkind.livejournal.com/3259.html.

Поэтому когда мы говорим про требование и техзадания мы всегда говорим - не выгода а выдача.
Стоит понимать что назначение технического задания - это контрольная точка на вход в производство и выход из него.

Назначение документа-требований - проработка пожеланий и контроль результата.

Если у вас тз на самом деле всего лишь ожидания или непроработанные пожелания - задайте себе вопрос - каким образом вы проконтролируете выход из производства достаточно комплексного продукта?

Где брать требования?


  1. Сесть и писать - ничего в этом сложного вообще нет. Требования это ваши же ожидания.

  2. Если совсем сложно - требования можно заказать, кто сколько берет за это (это интервьюирование вас, где и как это делать каждый решает сам - я делаю это только в студии и за деньги), тут помесь работы секретаря + машинистки. Ну и контрольные вопросы конечно же от нас )

  3. На собранные требования можно давать решения - а только на каждое решение может быть уже цена и сроки. Можно за 5 рублей а можно и за 50 лямов. Тут кто что вам предложит на рынке, каковы ваши потребности и ситуация.

  4. Ждать и требовать подробнейшее тз от исполнителя.

  5. Только после четкого понимания пускать в сооружение (разработку) систему.

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

Вопросы, комментарии приветствуются.

Найденные опечатки исправляются, добавляются новые.

Mission is Possible, часть 7 (последняя). Вызовы реальности или Jobs To Be Done.
alexander pavlyut
deppkind
Содержание


  1. Энергия.

  2. Миссия, изменчивость мира и видение.

  3. Дерево целей, ТРИЗ, причина и следствие.

  4. Write down - запись и фиксация.

  5. Цели и передача миссии.

  6. Результаты. Называем дъявола.

  7. Вызовы реальности или Jobs To Be Done.



Вызовы к решению. Jobs To Be Done.


Именно поэтому появился такой формуляр как Job To Be Done - дело которое придется сделать объекту чтобы исправить ситуацию (получить результат).


В процессе проектировки любого дерева целей я упрощенно называю это Job Stories, которые записываются в следующем виде:


[ситуация] [мотивация] [ожидаемый результат]


Примеры из реальных проектов как верно описывались ситуации:


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


Неверно, не охватывает сиутацию:


  1. мы хотим делать анонсы новых продуктов для наших потребителей, для этого нам сделайте раздел акции на сайте и смс рассылку.


Верно (после длительного интервью о бизнесе):


  1. [Ситуации]:


    1. когда у нас выходят новые продукты или акции,


    2. когда товар у нас залежались, и мы хотим его сдвинуть с полок


    3. когда мы хотим перетянуть одеяло от конкурентов в конкретные моменты по нужным событиям



  2. Мы хотели бы [мотивация]:


    1. иметь план действий на нужный момент, все необходимые  инструменты коммуникаций (email рассылки, sms, социальные сети, листовки, курьеры, штендеры, периодика локальная, наружка, партнерская сеть) - все возможные инструменты которые помогут получить или усилят ожидаемый результат.



  3. Тогда мы смогли бы [ожидаемый результат]


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




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


Стоит ли говорить что после обсуждения этой ситуации по методу Job Story возникло моментальное понимание что одной смс рассылкой реально ожидаемый клиентами инструмент “войны” они вряд ли получили бы, а также возник энергетический всплеск и появился азарт и риск, ожидание больших результатов которые подняли всем настроение.


Если говорить простым языком на примере простых задач то схему формулировки цели можно описать еще проще:


[текущая ситуация] => [воздействия на ситуацию] => [ожидаемый результат в контексте его применения]


Примеры:



  1. Грязная гора посуды. Нужно ее помыть. В [чистой раковине] можно разделать курицу (понятен срок - ужинать ночью не будем)


  2. Машина стоит напротив въезда. Нужно убрать машину. Через час [через эти ворота] будет проезжать президент компании (видна важность работы - тебя могут уволить или испортить машину если она будет в момент проезда президента).


  3. и так далее.



Каждый раз детали появляются те самые которые возникают в голове в момент выполнения.


Proof Of Concept

https://en.wikipedia.org/wiki/Proof_of_concept


Раскрывая последующий замысел мы выполняем также важную задачу - подтверждение реальной значимости и достаточности поставленной цели для достижения искомого результата.


Очень важно понимать реальность выполнения цели - когда сразу понятно как и чем можно получить нужный результат, мы опять же зажигаем энергию мотивирующую это сделать.


Что делать в итоге? Как ставить правильные цели?


А давайте на примере успешности в целом посмотрим:



  • Что отличает успешного человека от не успешного?


    • Успешный человек совершает правильные действия.



  • Как совершать правильные действия?


    • Необходимо иметь опыт неправильных действий.



  • Как получить опыт неправильных действий?


    • Нужно получить опыт действий.



  • Как получить опыт действий?


    • Необходимо действовать, и каждый день! Статистика решает.




Полагаю по аналогии будет понятно как в конечном итоге вы научитесь ставить правильные цели.


Заключение


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


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


Я как мог постарался обоснованно донести свое видение такого важного момента как миссия и мотивация миссией.


Поставленная цель сама помогает подтянуть к себе ресурсы, дает энергию на ее достижение и приносит много энергии и сил от наслаждения результатом.


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


Ставьте потрясающие цели, достигайте результатов и помните - миссия выполнима!



Mission is Possible, часть 6. Результаты. Называем дъявола.
alexander pavlyut
deppkind
Содержание


  1. Энергия.

  2. Миссия, изменчивость мира и видение.

  3. Дерево целей, ТРИЗ, причина и следствие.

  4. Write down - запись и фиксация.

  5. Цели и передача миссии.

  6. Результаты. Называем дъявола.

  7. Вызовы реальности или Jobs To Be Done.



Формулируем результат и правильные критерии приемки.


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

Для первого повышения результативности я всегда помогаю сформулировать цель как конечный результат.

Стоит понимать что результат – это всегда нечто отчуждаемое, появившееся в следствие некоей активности, что можно будет взять и использовать далее для достижения следующих результатов.


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


Дело в том что критерии приемки это те параметры, которые крайне важны для фактического принятия результата как успешно выполненного, но их просто не называют так как они могут находятся вне информационного поля выполнения самой задачи / активности.


Гарантии результата


Первое что нужно указать - критерии при которых результат будет считаться успешным.


Укажите как можно меньше важных именно для вас критериев, не стоит с ними перебарщивать - лучше дайте свободу принятия решений самому исполнителю, и бонусом получите повышение качества.


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


Требования и ограничения


Также стоит указывать критерии, которые крайне важны, и если они не будут соответствовать ожиданиям то задача не будет принята сто процентов.


Предварительные условия


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


Хоть это и звучит как “для тупых” - но это спасет во многих случаях замысел от провала, стоит это иметь ввиду.


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


Необходимые утверждения


Перед тем как мы перейдем к процессу поиска и формирования правильных целей я хочу отметить необходимые для этого утверждения и закрепления.



  1. Есть только цели направленные на реализацию миссии - цель должна находится в общей цепочке конкретной ветки общего дерева целей во главе с миссией.


  2. Невозможно управлять тем что ты не можешь измерить. You can’t manage what you can’t measure. - W. Edwards Deming


  3. Цель это отчуждаемый результат деятельности (activity outcome).


  4. Сформулировать цель - придать реальность


  5. Мысль движется скачками по веткам дерева - поэтому мы все это “ловим” записью / метим, если надо то “подшиваем к делу” или же закрываем (вычеркиваем).


  6. Размещение цели на временную доску придает ответственности за ее выполнение.


  7. Результатом считается только то что может быть использовано для выполнения следующей цели - это дает ответы на возникающие вопросы по дороге.


  8. Цель должна быть детально записана - подход SMART. Нет записи - нет цели.



Что же делать


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


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


Сразу отмечу что после внедрения данного подхода клиенты стали очень довольны и благодарны за передаваемые знания.


Дело в том что этот подход у некоторых людей даже может конструктивно изменить в принципе жизненный подход практически ко всему.


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


Нужные цели не видит в целом никто, если не пройти процедуру понимания ситуаций.


Опросы общественного мнения, сотрудников и прочие неработающие инструменты это прекрасно демонстрируют.


Данный подход подробно изложен в небольшом докладе инстута Phoenix в 2012 году http://www.youtube.com/watch?v=f84LymEs67Y


Снова ТРИЗ


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


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


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


Дело в том что в своей жизни мы принимаем те или иные решения не потому что мы хотим сделать что-то просто потому что захотели, нет. Как будто-бы только захотев у нас в жизни все будет по Щучьему велению по нашему хотению (на самом деле не будет).


Мы принимаем те или иные решения только под воздействием внешних сил, находясь в определенных обстоятельствах, которые корректируют наше поведение.


Люди вынуждены зарабатывать деньги чтобы поддерживать свой уровень жизни.


Или же возникает:



  1. Недовольство собой


  2. Недовольство текущим положением дел в компании / отделе / на рынке


  3. Недовольство чем угодно



Многих вынуждает общество на проявление тех или иных качеств (не редко лидерами становятся благодаря безысходности и необходимости в том числе выживания).


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


ТРИЗ, в частности “веполь”, нам поясняет на примерах что любое взаимодействие между двумя объектам возникает только в результате воздействия внешней силы (требует) на первый объект (потребитель) и обстоятельств, которые определяют порядок и направление его движения в сторону именно второго объекта (продукт).


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

Далее часть 7 - Вызовы реальности или Jobs To Be Done.

Mission is Possible, часть 5. Цели и передача миссии.
alexander pavlyut
deppkind
Содержание


  1. Энергия.

  2. Миссия, изменчивость мира и видение.

  3. Дерево целей, ТРИЗ, причина и следствие.

  4. Write down - запись и фиксация.

  5. Цели и передача миссии.

  6. Результаты. Называем дъявола.

  7. Вызовы реальности или Jobs To Be Done.



Жизненный цикл цели


Каждая цель всегда проходит определенные этапы жизни.


  1. Мечта - плохо сформулированное скопление нейронных представлений в секунду времени в мозге человека - аудио, видео, изображения, сценарии, тонны текста. Это как раз мое любимое состояние у клиентов “зачем записывать, все же понятно, мы же обсудили”. В этот момент различия восприятия носят громадный характер противоречий, и что у каждого на уме остается только догадываться.


  2. Желание обладания - уже что-то сгруппированное ярлыками реальности, например “красная большая машина”, или “большой дом”. Пока это не реально, но уже дан вектор, и внутри загорается энергия обладания.


  3. Столкновение с реальностью - тут мы двигаемся к процессу получения цели, и тут же принудительно для нас начинаются конкретные расчеты, потому что мы делаем первые робкие шаги “приземления” мечты в формы и объекты нашей реальности, путем формулировки конкретных измеряемых параметров, все для того чтобы произвести аккумуляцию ресурсов на выполнение этой цели, поэтому нам просто придется совершить формализацию, которая поможет:


    1. получить цену замысла - сколько как чего и где придется вложить в получение результата.


    2. Понять что из этого мы можем сделать по ресурсам а что нет.


    3. Оформить цель в формате SMART - Specific Measurable … (gooogle it)


    4. Выполнив все эти действия фактически совершить ЗАКАЗ на выполнение этой цели.



  4. Недооценка страхов обладания - что-то полученное надо иметь, содержать и использовать по назначению. Страх того что это не получится сделать силен, но точно так же силен страх того что это получится. Это нужно проработать так как этого чаще всего боятся и недооценивают, но об этом в следующих статьях.


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


    1. Если цель оказалась плохой - важно сделать до конца, прочувствовать на себе в деталях и принять поражение с одной простой целью - следующая цель получится куда правильней.


    2. А если откажетесь от выполнения - разрушите весь процесс и вернетесь к анархии и хаосу - оно вам надо?




Передаем миссию и делегируем результативно

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


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


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

Я всегда рекомендую формулировать цели как конечный результат от планируемой активности, чтобы было очень просто понимать как ее сделать – и когда она будет готова.


Дополнительно (а вообще обязательно) необходимо записывать тут же рядом для чего это нужно делать или как именно и где далее этот результат будет использован.


Запись “для чего” нужна нам для небольшой хитрости. Хитрость заключается в том что мы никогда не сможем спланировать что-то более-менее похожее на реальный ход событий. Все мы знаем что планирование это процесс мышления, а то как будет в реальности мы даже и не догадываемся.


Тут представляю вам небольшое замыкание реальности - наша запись “для чего” это и есть “миссия” в данном конкретном случае.


Формулируя миссию для каждой своей задачи мы получаем двойной бонус по энергии - мы получаем энергию миссии, а также по ее выполнении энергию результата + опять же зажигаемся энергией следующей миссии от следующей задачи.


Бонус для дочитавших до этой строчки - мы получаем самонаводящуюся цель или истинно верное работающее на практике делегирование.


Практическим бонусом мы получаем защиту “от дурака” или же ответ на вечный вопрос - как же правильно делегировать чтобы получать нужный результат и не участвовать в процессе его достижения вообще.


Тут проще пояснять на очень простых примерах.


Пример 1. Поездка в такси.


Исходное состояние


Представьте что ваша конечная цель - приехать к определенному часу на мероприятие в центре соседнего города Б от текущего А. Ваша миссия как результат достижения главной задачи - оказаться вовремя на открытие (пройти все нужные процедуры, знать как подъехать и тд).


Неверное делегирование


Вы говорите - едем на ярославку, там пару километров дальше покажу куда поедем, нам надо успеть к 14.


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


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


Верное делегирование


Пассажир сообщает - мне нужно быть в городе Б на мероприятии в 14 часов на сцене.


Таксист зная что в этом месте возможны трудности и приехать надо явно заранее планирует себе прибытие в 13:30 и довольный пассажир отплачивает чаевые.


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


Это очень сильный плюс от передачи миссии.


Пример 2. Поход в магазин. Более точно раскрывает погрешность при отсутствии миссии.


Жена ждет мужа на ужин дома, она сварила борщ. Чтобы быть точным отмечу условие что к борщу в этой семье ожидается бородинский хлеб.

Миссия - поужинать с вкусным хлебом свежим борщиком.


Неверное делегирование


Жена сообщает - по дороге домой зайди в наш магазин и купи хлеб.


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


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


Правильное делегирование


Муж - у нас сегодня ароматный борщик, выбери хлебушек по твоему вкусу. И конечно же муж покупает самый ароматный свежий бородинский хлеб, а еще внимание - сметанку пожирнее! Занавес.


Для закрепления важности передачи миссии покажу как самоликвидируются любые идиотские вопросы которые могут возникать на пути выполнения задачи при наличие миссии:


  • Можно ли купить несвежий хлеб - для уток какая разница?


  • А можно принести завтра - я как раз другим маршрутом пойду, там выбор больше?


  • А можно вместо хлеба хлебцы - они же полезные?


  • А если взять тесто и самим испечь - будет же вкусно и себя займем?


  • Может ну его хлеб - раз булки мять, может пиццу закажем?



И так далее в том же духе - я думаю многие встречают эту беду со своими подчиненными достаточно часто.

Далее часть 6 - Результаты. Называем дъявола.