В будущее действительно берут не всех

Все мы создаём «революционные» «технологические» и «прорывные» продукты и хотим, чтобы наши Чёрные Лебеди плавали в Голубых Океанах.

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

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

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

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

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

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

Какие проекты практически всегда доживают до запуска, а какие никогда - как это оценивается на стадии зародыша?

Есть два пути.

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

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

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

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

Действительно люди месяцами шерстили темы, вынюхивали что "пойдет", люди имели свои каналы и способы понимания этих тем, и в итоге раз за разом какой-то очередной оптовик "удачно" ставил на закупку на заводе "раньше всех" крупные объемы, и его компания за короткий срок превращалась из ИП Кто-то по реализации в розницу кукл Wings (или как их там) до Федеральной компании с сетью представительств по России.

Везло конечно не всем. Больше хороших личных примеров "ловцов удачи" не имеем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как вы считаете - Джобс все же был открывателем “голубых океанов” и удачно видел черных лебедей, или же, с таким подходом, был посредственным предпринимателем?

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

Вокруг нас очень много продуктов и услуг среднего и плохого качества.

Даже если вы сделаете сервис / услугу или что-то что уже есть, но повысите уровень качества - вы уже будете в обойме и получите свой рост. Потребитель проголосует рублем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сразу приведу не совсем свежую цитату, год уже не помню.

Вывод, к которому я подвожу очень простой.

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

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

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

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

В этот момент уже есть четкое понимание что нужно от систем (какие требования) хотя бы в общем виде, но одновременно есть понятный сценарий потребления этой части системы - привет Jobs To Be Done.

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

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

И вы переходите на стадию:

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

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

В какой-то момент времени абсолютно все приходят к написанию своих платформ.

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

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

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

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

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

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

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

Как увидеть нужное будущее проекта? Как сформировать предъявляемое понимание и видение картины будущего?

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

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

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

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

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

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

На поверку выясняется что:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это в совокупности происходит в каждом из проектов, у каких-то есть что-то одно, у каких-то что-то другое, у каких-то все сразу.

1. В работу принимаются задачи со слов руководителя, потому что "иерархия", без “промысленной” картинки -> как результат непонятно в деталях о чем договорились, но отвечать уже есть кому.
2. Выдаются сразу "задания" на разработку, то есть выдаются / пишутся задания, не передается картинка деятельности (целей и задач) - зачем и почему решили делать эти задания нет ясности. Нет контекста.
   
3. Руководитель / заказчик рад бы "промыслить" верно - но ему никто об этом не говорит и не указывает, что приводит к пункту 1.
   
4. Стартапер “самообанывается” или "заблуждается".
   Непроработанные вещи, то есть - не вынесенные перед собой для переосмысления, - воспринимаются нами не так как они выглядят на самом деле.
   Эта ситуация и опять приводит к пункту 1

Первое и самое главное - мышление должно быть письменное до того как оно попадет в какие-то документы или сервисы. И принудительное.

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

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

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

Доска должна жить (желательно) с нарисованным не менее недели а лучше трех, чтобы никто не стер информацию.

1. Извлекаем из головы и останавливаем мышление на носителе.

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

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

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

2. Выстраиваем логические связи.

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

3. Формируем беклог.

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

4. Что делать каждый день. Расстановка приоритетов.

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

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

2. Разобраться с сетевыми графиками

3. Книга - Принцип пирамиды Минто - золотые правила мышления, делового письма и устных выступлений

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

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

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

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

1. Оффлайновые доски.

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

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

Еще одна деталь которые не все видят - то что преимущественно они пишут карандашом а не ручками.

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

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

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

2. Realtimeboard - все в кучу можно вывалить.

Если нужно вывалить все из головы и это сохранить для регулярного доступа - прекраснейший (пока писал они стали Miro - https://miro.com/)

3. Mindnode - ментальные карты

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

Ну а нам пора двигаться дальше.

Любое начинание когда-то обязательно заканчивается.

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

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

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

Точнее становится предельно понятно, что нужно совсем не то, что сделали.

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

Так выглядит столкновение "крутых" идей с реальностью.

Изначальные цели оказались не совсем настоящими.

Профессор Савельев — автор таких научных трудов, как «Изменчивость и гениальность», «Возникновение мозга человека», «Атлас мозга человека», и некоторых других.

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

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

Также есть интересная и полезная книга от профессионального "мерзавца" (по его же словам) Александра Глебыча Невзорова "Искусство оскорблять" - в ней он достаточно подробно раскрывает моменты корысти, глупости и многого другого что стоит за истинным поведением человека.

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

Что характерно для этого - свои цели, как правило, никто никому в здравом уме и в трезвой памяти не предъявит.

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

1. Вы делаете сайт? - да делаем.
2. Сделайте такой и такой сайт - договор, работа, сделали.
3. Почему нас нет в поисковике? - идут первые конфликты, допустим продвинулись в выдаче по ключевикам, договорились о доплатах, сделали.
4. Итог - клиент рассказывает что все вышло как нельзя лучше: "Пацанам в бане показываю - опа, мой сайт на первой / второй строчке, а вы в пролете".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• DOD - Definition Of Done
• Smart цели
  
• Acceptance Criteria
  
• OKR и прочие
  

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

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

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

Формат Jobs To Be Done.

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

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

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

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

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

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

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

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

Такое очень редко встречается когда идет сотрудничество и деньги - никогда я не видел такого. Но честно слышал.

Тут надо отметить что всем на помощь спешит "эджайл".

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

Можно же нормально планировать работы. Зато очень многие считают "стратегию" и "стратегирование" водной водой. Вот и вся разница.

Давайте закрепим цепочку рассуждения:

1. Поставили цели, определили задачи
2. Пришли к результату
   
3. Выяснили что это "не то что надо"
   
4. Поставили новые цели / уточнили старые
   
5. Вернулись на первый шаг

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

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

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

Как существенно сократить будущие изменения или повторы итераций?

- Говорить об истинном результате сразу.

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

Обсуждать нужно то, что будете делать вы / заказчик / руководитель с полученным результатом в момент приемки. Зачем он ему.

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

Очень простой пример

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

1. Захожу к Михалыванычу, открываю вот это.

2. Он берет свой айфон и видит у себя что это "появилось".

Примерно вот такой будет сценарий.

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

1. Представить что результат получен успешно.

Вот, допустим, все сделали - дальше что мы с этим делаем? Что куда показываем / отправляем - чего ждем от этого?

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

2. Фиксируем приемочный сценарий

• По шагам пишем что будем делать
• Кто это будет делать
  
• В какой ситуации

• Что будет является критерием успешности ЭТОГО шага с точки зрения (вас / клиента / руководителя).

В дальнейшем ориентируемся только на этот сценарий.

1. Что волнует человека? Профессор С.В. Савельев: еда, размножение и доминантность.

2. Искусство оскорблять - А.Г. Невзоров.

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

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

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

3. Дизайн - это работа. Монтейро Майк

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

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

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

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

Поэтому смело двигаемся дальше.

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

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

- А в чем тут изобретение?

На что я уточнил риторическим вопросом:

- А в чем, по вашему, разница между изобретением и инновацией?

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

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

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

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

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

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

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

Есть такой интересный Сергей Чернышёв, и его лекции на тему Техноэкономики. Я воспользуюсь его терминологий "снятие трансакций" и попробую сам привести теоретический пример покороче.

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

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

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

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

Примеры технологических инноваций в этом, уже существующем технологическом укладе хорошо демонстрируют нам компании - Яндекс и его Еда / Шеф. До этого были предварительные подходы у DeliveryClub и прочих доставеских.

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

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

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

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

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

Запускаются "лендосы" для продажи несуществующих продуктов и так "тестируют гипотезы".

Ходят с презентациями а не с рассчетами и детализацией своих проектов.

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

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

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

1. Быть носителем предметной области - вы должны иметь максимально точное представление о происходящем чтобы это менять.

2. Работая осознавать предметную область деятельности во всех подробностях. Записывать и смотреть на нее.
   

3. Понимать всю цепочку деятельности и поставок результатов, в которой находится твое место.
   

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

5. Применять технологии для сокращения количества операций.
   

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

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

1. Сергей Чернышев - лекции на тему Техноэкономики.

2. Петр Щедровицкий - "Новая промышленная революция". Простое вводное видео на 7 минут, а далее по интересам ныряете в related videos.

3. "Булавки Адама Смита" - подробно про эффекты от “перестановки” простых операций местами, и получении от этого на ровном месте огромного прироста производительности читайте в материале про булавки Адама Смита http://vphil.ru/index.php?option=com_content&task=view&id=1392

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

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

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

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

Двигаемся дальше.

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

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

1. У нас выставлены истинные цели

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

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

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

Инструментом в данном случае является сама технология - интернет, софт, железки.

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

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

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

Расскажу на примере разработки ПО на заказ.

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

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

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

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

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

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

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

Вот тут я и сошлюсь на первые главы - что:

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

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

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

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

На чертежах (или "об чертежи") договариваются что нужно сделать - по чертежам проверяют все ли сделано о чем договорились. Ставят марку “проверено” или выявляют “несоответствия” (дефекты / баги).

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

Допустим все шаги, выше рассмотренные, прошли успешно и нам на руки попало ТЗ (или мы сами сели его писать).

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

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

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

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

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

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

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

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

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

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

Проблема хорошо проиллюстрирована Вигерсом:

Косвенное следствие этой проблемы - это большой объем документации, которая при этом имеет повышенную "волатильность".

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

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

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

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

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

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

Я считаю что подробнейшей документации быть.

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

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

И что надо делать - собирать и документировать Архитектуру "on Demand" - по ситуации, по факту “выявления предмета”. И накапливать ее. Накапливать по кусочкам.

Это очень похоже на сценарии UseCase, но со своими особенностями и поэтому это не UseCase.

1. Вернуться к работе на досках и понять о какой задаче идет речь.
2. Сконструировать по шагам детальный сценарий потребления результата, в котором нужно обозначить по каждому шагу:
   a) Указать какое происходит воздействие на продукт
   b) Кто выполняет это действие (деятель)
   c) В каком месте какого физического продукта он выполняет это действие
   d) Какие характеристики каких понятий предметной области задействованы.
3. Снабдить сконструированный сценарий графической функциональной схемой взаимодействия - она ответит на вопрос "как это работает?".
4. Конструировать и уточнять такие сценарии каждый раз при появлении новой информации и обзывать "новой версией задания".
5. Согласованные задания пускать в работу до их завершения, вне зависимости от появления новых параметров - все новое пускать только следующими партиями.
6. Все архитектурные элементы записывать в "конфигурацию" того что строится:
   a) Какие продукты (конструкции) сейчас в изготовлении
   b) Структура продуктов - из каких мест (модулей) они состоят.
   с) Опираясь на функциональные схемы сценариев - формировать и обновлять "общую схему" как функционирует весь производимый продукт в границах всех его конструкций.
   
7. Все выявленные характеристики предметной области группировать по общим понятиям, накапливая отчуждаемую базу знаний о предмете.

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

Завершая практику по производству хочу сказать одно:

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

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

1. Психбольница в руках пациента. Алан Купер.

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

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

Как это делается - читайте в этой прекрасной книге.

UPD: Нашел внятные выжимки книги на хабре которые раскрывают важные части (перечисляю пересечения, не все что там есть):

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

2. Разработка требований к программному обеспечению, упомянутого чуть выше Карла Вигерса.

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

Ну и много чего хорошего и не устаревающего содержится в этой книге.

3. Системноинженерное мышление, Анатолий Левенчук.

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

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

4. Системное мышление, Анатолий Левенчук.

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

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

5. Cистемное мышление, Анатолий Левенчук.

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

6. Основы проектирования приложений интернета вещей. Великолепный курс Алексея Корнилова.

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

А после вы добавите резделение ios / android и у вас будет еще несколько вещей. А вы добавите после запросы данных из внешних сервисов - у вас еще появилась новая "вещь" в вашем продукте.

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

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

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

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

1. Прототипирование должно максимально "приблизить" вас к пониманию продукта, и в успешной обратной связи пойти в работу.
2. Если вы используете программы прототипирования только для "понимания" того, что вы собираетесь строить - вы занимаетесь работой которая не входит в цепочку создания продуктов. Заняты вы чем угодно - но не результативным трудом.
3. На создание прототипа нужен опыт работы не только в самих программах, но и опыт проектирования - то есть работа все равно пойдет с привлечением специалиста, читай - за деньги.
4. За что платим деньги - опыт показал что "прототип" не дает возможности уловить "всю картинку" как он работает, как будет работать вся система в общем, и по желанию в частности.
5. Прототипирование не дает быстрых ответов, и не дает вообще ответов, кроме "спецификаций" на конструктивные элементы. И то эти спецификации никогда не выглядели достаточными чтобы "подшить к договору" или "передать в отдел" и по ним совершить приемку.
6. Помимо затрат на создание прототипа, вам необходимо уже точно и принудительно сформировать "документацию" по этому прототипу (+ специалист или время) и пытаться это поддерживать.
7. Вишенка на торте - после того как вы с ним "поработали" - вы его выбрасываете. Прототипы Axure и подобных систем - никак не связаны с продуктом.

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

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

1. Простой html
2. Различные конструкторы
3. Любые языки программирования для создания функционального прототипа - ROR / Django / Node / Phoenix ...
4. Мобильные платформы - Expo CLI для создания мобильного приложения на обе платформы с возможностью проверки
5. Во всех случаях сохраняется возможность развивать результат в продукт.
6. Также стоит денег как и прототипирование в отдельных системах
7. Также строится от "Сценариев" и не подразумевает режима "Кодинг со слов в продакшн".

Поэтому нужно работать в простой последовательной цепочке работ:

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

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

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

Но в итоге вот чего полностью достаточно:

1. Wireframe.cc - лучший инструмент для быстрого скетчинга.

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

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

2. Confluence. Отличное место чтобы все вместе попытаться в итоге собрать.

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

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

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

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

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

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

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

1. Можно фиксировать и обновлять стратегическую картинку всего проетка (и подпроектов). Видеть связи. В отличие от realtimeboard все графики рисуете не вы, а система. Вы (и я в том числе) не умеете их рисовать и обновлять каждый раз адекватно а вовремя.
2. Конструирование - та самая инновация, и это инструмент который позволяет делать "Сценарии" каждый раз когда они придут в голову - вся предметная и функциональная часть накапливается. Аналогов такого решения на текущий момент нет.
3. Все технические задания вытекают из конструирования и их не надо писать - они сделаны автоматом и их надо только выполнять. Делать это можно и в трекере, и просто предъявлять их исполнителям - везде существуют критерии приемки.
4. Вся техническая документация автоматически генерируется (планируем добавить формат ГОСТа, если кому надо пишите - откроем пораньше).
5. Продуктовая документация / гиды документируются также on-demand, по завершению работы над какой-то частью продукта, представляемый контекст помогает сразу понять что и как написать в доку без сильных сложностей.

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

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

Спасибо за прочтение, всем успехов.

#лонгриды #стартапы #продукты #инструменты #чеклисты #книги #курсы #инновации #подборка