apavlyut

Потребности для валидации, требования - для верификации.

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

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

Все верификации на соответствие требованиям прошли, а вот валидация - нет.

Кто не понял - тот поймет (с) ...

/// Это мои возмущения из подзамочной группы общения по бизнес-консалтингу. ///

UPD: дискуссия выросла и я добавил уточнение в ps в конце поста.

Коллеги.

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

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

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

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

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

Не мешайте людям покупать ваши товары - они сами сделают это с удовольствием без вас. Вы просто ДАЙТЕ им это сделать - выложите ВСЮ информацию с ответами на ВСЕ возможные вопросы с ответами на них - в доступности зрения и чтения для клиента, в полном и кратком описании, с видео / картинками и без - дайте потребить ваш продукт мозгом, до его реального приобретения.

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

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

Не хочешь продавать - не мучай менеджера.

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

Так и передайте своим клиентам.

P.S. Чеклист.

Сесть и написать на трех листах А4:

1) кто ты,
2) для кого ты,
3) что ты продаешь (по каждому товару),
4) как ты это делаешь,
5) в чем реальная выгода для какого конкретно потребителя этого продукта,
6) в чем она выражается,
7) в каком контексте жизненной ситуации эта выгода проявлеятся
8) зачем это все дело делать именно с твоим бизнесом.

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

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

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

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

Железобетонный цемент который держит бизнес и является его стержнем - это такие вот бумажонки А4.

Как говорит мой знакомый сотрудник МВД - надо аккуратней с заявлениями, бумага вещь функциональная.

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

-> http://geekbrains.ru/events/201

=== копипаста прямо с сайта школы программирования ===

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

На каждом этапе существует определенный порядок работы с требованиями, а так же с ситуациями (issues).

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

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

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

1. Инциация замысла
2. Моделирование решения;
3. Формирование архитектурных описаний
4. Сооружение
5. Верификация
6. Валидация
7. Ввод в эксплуатацию
8. Эксплуатация
9. Вывод из эксплуатации



P.S Часть первая тут -> http://geekbrains.ru/events/200

Моя основная ошибка всегда была в том что ранее я относился к системам как к месту “в котором“ работу работают.



Ну у меня уже только в студии было создано четыре полноценных версии работающих систем, текущая запечатлена тут http://www.pavlyut.com/cases/artefactor

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

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

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

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

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

Поэтому постановление Павлютя следующее:

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

А как мы знаем появление рабочих продуктов это факт выполнения определенных работ.

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

На сегодня все!

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

Площадка заглючила и не давала мой звук и видео пришедшим.

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

http://geekbrains.ru/events/200

Просто вставлю анонс который там был

====

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

Данной темой я постараюсь ответить на самые важные вопросы:

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

- Что дальше?

====

Аудитория у меня тоже была достойная:




Всем пис!

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



NOTE: В жж верстка просто какой ад и израиль - нет желания с ней бороться, жж использую как хранилище черновиков. Нормально прочитать и обсудить можно у меня в фейсбуке - https://www.facebook.com/notes/alexander-pavlyut/как-проектируется-полезный-сайт-или-система-гид-для-чайников-или-как-уволить-сво/10205278553112242


Как я делаю архитектурное описание проекта - или в средневековом простолюдье “техническое задание”.

У системы есть назначение (функция) - что она выдает окружающий мир своим существованием.

У системы есть архитектура которая реализует это назначение.

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

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

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

У каждой страницы есть два вида целей (логистики информации) - выдача или получение.

1. Выдача информации (не просто показать, а достчичь пользу в голове читающего) - как достичь - выполнить пункты по раскрытию : как? почему? для чего? цена? как получить? сколько стоит? почему доверять? кто вы такие? примеры в контексте моей проблемы? статьи? видеозаписи?
2. Получение информации от пользователя. Тут все про формы и прочие кнопки воздействия на сайт.

Цели эти живут часто вместе.

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

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

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

Задаем себе вопрос - какой информацией находящейся в элементе мы выполним это назначение?

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

Если все хорошо - переходим к технической части сайта.

Из чего состоит элемент - опись под ключ: форматы, размеры, цвета, слова, фразы, картинки, размеры - все под точные измеримые параметры.

Отвечаем на вопрос - что делать дальше с элементом - как информация этого элемента должна оказаться на странице?

Как часто эта информация планируется изменяться на сайте?

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

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

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

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

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

На каждом экране описываются следующие сценарии поведения:

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

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

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

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

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

Одна страница - одна цель для пользователя.

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

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

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

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

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

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

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

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

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



http://www.pavlyut.com/cases/artefactor

Начинаю раскрывать свой 7-летний опыт работы на рынке разработки ПО на заказ в своей студии и в консалтинге по внедрению разных решений.

Как-то мы договоримся что мы знаем простые аксиомы:

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

Кому интересно подробности читаем прекрасную статью Марка Андерсона "Софт (ПО) пожирает мир" -  http://www.wsj.com/articles/SB10001424053111903480904576512250915629460


И теперь контекст ситуации:

1. Как понять что клиенту (ему самому понять и нам разработчикам понять) - уже нужна заказная разработка ПО?
2. Откуда в таком случае могут появится требования?

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

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

Мой опыт нахождения в проекте в котором нет бизнеса, но уже все обсуждают как проходить процедуру PCI DSS для хранения номеров кредитных карт - стоит 1,8 млн старых рублей (33 за $) в месяц на такие разговоры по скайпу.

Я сейчас не про них - их надо обходить стороной и даже не поднимать этот вопрос.

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

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

1) Есть список конкретнейших проблем которые он собиарется решать так как ему это уже будет лучше, он понимает вектор развития и примерно представляет возможное решение своей задачи. Их надо только прорабатывать нашими методами чтобы получить грамотный Product Requirements Document (читай требования) + Архитектурное описание проекта (читай ТЗ).

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

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

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

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

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

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

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

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

За что платит клиент в консалтинге / трекинге / коучинге - и сколько стоит консалтинг?

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

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

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

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

У кого-то есть вопросы про справедливость - сначала читаем книгу "Справделивость" издательства "Манн Иванов Фербер"  а также статью Максима Ильяхова "Рынок, расценки и справедливая цена" ( спасибо Артему Горбунову за ссылку).

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

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

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

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

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

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

Я подробно раскрывал эту тему на уровне головного мозга в посте Атака Инсайтами.

Поэтому имея ввиду вышеизложенное я дал следующий комментарий:

"(не давать) Никаких гарантий возврата кроме - гарантии результата при выполнении заданий. Задания документировать. Услуга консультации оказывается в момент ее оказания - это возмездная услуга, это пишется в договоре. Без работы клиента ему не может быть оказана услуга. Как только будет прописан возврат - им сразу же воспользуются, а цену договора будут считать нулевой на попробовать. Я просто проходил это на практике и скажу вам что опыт этого бреда не дает ничего кроме выводов - какой же я мудак, а кто мне заплатит за мое потраченное время и предоставленные услуги. Уважайте себя в первую очередь - если вы себя и свой труд не уважаете и допускаете что вы его некачественно оказываете - это говорит только о качестве услуги и уверенности вас в результате. Это и портит контракты. Только предоплата, только гаранитя результата - предприниматель который поверит в гарантию от вашей работы - просто не предприниматель. Мы продаем "инсайты" в голове предпринимателя на его опыте и его знаниях, давая нужные конструкции, внешний взгляд на ситуацию, и подводим к заявлению о целях и планах - а дальше мы контролируем как предприниматель свои же планы выполняет. Именно в этом работа консультанта - нет тут никакой гарантии возврата средств - и думать забудьте!"

" ... Человеческий мозг не является генератором мыслей, а лишь их приемником и передатчиком
http://slavikapple.livejournal.com/122363.html ..."

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

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

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

Тонкая вещь, всем кто ведет консалтинг на заметку.

UPD: вот еще - Цифровое бессмертие: как создать свою вечную http://www.rbc.ru/opinions/society/30/10/2015/56331a139a794750360bcaed