Батя в здании. Пора тебе забыть свой Аджайл.

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

Название хорошо выражает философию проекта своими культурологическими аналогиями:

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

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

Аннотация

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

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

Для кого продукт

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

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

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

Для кого конкретно будет полезен продукт:

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

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

Терминология

Кооперация - сотрудничество между командами клиента и исполнителя.

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

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

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

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

Проблемы к решению

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

не в каком-либо логическом порядке, а просто набросок перечня "с кончиков пальцев":

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

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

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

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

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

что-то проблемы идут а решени все еще нет - может быть это только мои выдуманные проблемы? о_О

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

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

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

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

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

Компоненты

Из чего состоит работающее решение перечисленных проблем.

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

До начала разговора про компоненты введу термин:

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

Все о практиках на которых в итоге вырос Мьёльнир я
изложил отдельно и приводить их тут нет смысла в текущем изложении.

1. Кооперации

На самом деле это могут называть по разному - кто-то workspace, кто-то workplace, кто-то думает что это "проекты" в своей терминологии, as you with - у меня это кооперация, ее создаем и приглашаем участников по ролям.

Рис 93 — Добавление кооперации:

Uploads 2f1514477420811 7jqr3npqdg9 9349f115e56057c85c5f6f12c8244ebe 2fscreen%2bshot%2b2017 12 28%2bat%2b13.32.13

Рис 91 — Кооперация во всей красе:

Uploads 2f1514477291150 yrkzdfb2f9 7c63bc04ce0a8ea481bf9a517e310d63 2fscreen%2bshot%2b2017 12 28%2bat%2b15.06.01

Рис 92 — Виды практик по ролям:

Uploads 2f1514477319171 0q80se5w554 95affa68d693617f161898f351734a64 2fscreen%2bshot%2b2017 12 28%2bat%2b15.06.06
2. Тикетница

На самом деле никакая это не тикетница, схожести у нее столько же с остальными как и у любого поля input.

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

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

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

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

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

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

>>> на 14:32 Николай сообщает что должна быть параллельная не пересекающаяся линия.

3. Аналитика.

Кто не знаком с неким базовым принципом аналитики можно подсмотреть как все механизмы map / reduce устроены.

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

Рис 95 — Так выглядит разметка записи.:

Uploads 2f1514477679919 k6kk0bqg5j 45c4bc335968a6efd3a79fbb07505cbb 2fscreen%2bshot%2b2017 12 28%2bat%2b15.22.29

Рис 96 — Так выглядит анализ конкретной разметки.:

Uploads 2f1514477720470 zpmu3d8pk7 2999ea5ddc1d1ad73581d6e4fa26998b 2fscreen%2bshot%2b2017 12 28%2bat%2b15.22.59
Тут самое важное что размечать можно и файлы вложенные - pdf и картинки сразу мапятся на изображения, если там вложен какой-либо эксель то можно самому "дозагрузить" нужные скиршоты этого экселя чтобы явно указать на те части откуда вы берете информацию для запуска ее в работу.

Рис 98 — Развернутая часть разбора под записью:

Uploads 2f1514477795326 xcrgfi280g 44e00924f280ef81b56403657f643223 2fscreen%2bshot%2b2017 12 28%2bat%2b15.25.36

Рис 99 — Из реального проекта с клиентом - запись разговора и файлы под его каментом:

Uploads 2f1514477883341 ohoujc5o39l 03eefa8745a0939d90addda3a1e4f0a0 2fscreen%2bshot%2b2017 12 28%2bat%2b15.26.32

Рис 101 — Или например вот развертка разбора загруженного vsd файла который автоматом не разберешь ровно и поэтому наскринены существенные вещи и точно также разобраны:

Uploads 2f1514478040095 8k5y3kpweua 2a56091ed2a443991e81c8cf9dcccac8 2fscreen%2bshot%2b2017 12 28%2bat%2b15.27.21
3. Проект

- Задача

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

Рис 102 — Карточка проекта:

Uploads 2f1514478179087 wwr9p1y39fs 5f2dfa039b824f22a2fb023863534312 2fscreen%2bshot%2b2017 12 28%2bat%2b15.33.50
Собрано специально для обзора, детальное описание можно найти в коротком видео.

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

- Дано

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

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

Рис 104 — Тезаурус, типы данных и онтология которая выстраивается визуально:

Uploads 2f1514478256062 s8ily0eyu1q e52937dcd2d166d333d0312556ba3d53 2fscreen%2bshot%2b2017 12 28%2bat%2b15.33.56
Отдельно тезаурус конечно же есть побольше и его тоже надо заполнять для успешности вашего мероприятия.

- Решение

Тут самое интересное - на основании требований и данных я создаю решение.

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

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

Рис 106 — Визуальный редактор финального продукта:

Uploads 2f1514478340156 l55srs5xcop 5a697b14e9700dd85973a1d694514297 2fscreen%2bshot%2b2017 12 28%2bat%2b15.34.41

Рис 109 — После этого так эта часть выглядит в спецификации:

Uploads 2f1514478433290 c55rh21os08 0dde72be521bf4b0dfb423c8813043fb 2fscreen%2bshot%2b2017 12 28%2bat%2b15.35.20
Под капотом редактора:

  • Редактируем прямо так как будет, потому что бустрап 4, sass переменные и гибкость невероятная, сокеты и тд.
  • В редакторе идет разметка компонентов и элементов, привязка к данными из онтологии и тезауруса, отметка пожеланий и где они исполнены
  • ААА А можно грабить корованы (на самом деле нет).

- Смета

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

Рис 111 — Смета выстраивается от компонентов и учтенных пожеланий в конструкции:

Uploads 2f1514478518338 olm349jbz3b eda1374f9c39376fcfc295f615bb9b32 2fscreen%2bshot%2b2017 12 28%2bat%2b15.34.06
Каждый финальный результат стоит своих конкретных денег. Работы разделены на оплату по следующему принципу - как только "вошла" информация в систему вы как клиент на каждую пятницу будете должны оплачивать спроектированные решения каким образом:

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

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

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

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

Рис 113 — Пример из сгенерировнаного ТЗ которое прилетает на почту.:

Uploads 2f1514478587807 ru5op32y8j 8a8f5cb17cf47e087a767805678c2e80 2fscreen%2bshot%2b2017 12 28%2bat%2b15.35.32

Рис 114 — Письмо выглядит так:

Uploads 2f1514478634314 jd8jrqh7t9 6de08fd1a6917dbb8b34ebed97b682a6 2fscreen%2bshot%2b2017 12 28%2bat%2b15.58.12

Финализация и next steps

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

Рис 117 — Эти все ваши трело можно выкинуть:

Uploads 2f1514478705134 ux93b32vn5k 05872eb451719d63d84f75f54a395463 2fscreen%2bshot%2b2017 12 28%2bat%2b16.00.42
Ранее у меня была заложена такая конструкция что после появления тикета в системе, открывается таск "проанализировать" и он как бы должен разбираться теми кто имеет роль аналитка, но в последствии в углублении всех деталей я понял что это как раз в нашей жизни совсем неинтересное занятие.

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

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

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

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

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

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

А это и есть экономика - есть спрос, есть рынок, должно быть и предложение.

Оффер. Дедлайн. Призыв к действию.

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

Для внимательных читателей и желающих так же внятно описать свой продукт или бизнес подвезли новогодний промокод на скидку в 40% на продукт Как сделать правильный Whitepaper - mjolnir-here.

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

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

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

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

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

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

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

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

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

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

Спасибо дорогой друг - с наступающим осознанием в новом году!

Обсуждение


Picture
Alexander P., 28 дек., 19:35 (7 месяцев назад):
Автор - огонь!

Picture
Eugene R., 29 дек., 14:26 (7 месяцев назад):
Фундаментально.

Gravatar 140 9aac498dbd9b15de660eb9130f3fc68f7ceccd45019da4425654ffe20333a527

Поделиться ссылочкой

Подписка на новые статьи этого блога


Прочие продукты (новинка!)



Экономика токена (бесплатный продукт)


Uploads 2f1510070533879 wdaffh6qk2 a7cbf39c18605a547a2cd68c1342a7ba 2fscreen%2bshot%2b2017 11 07%2bat%2b18.47.23
Экономическое обеспечение присутствия токенов (блокчейна) в цепочке деятельности использователей продукта / услуги (бизнеса)

Тип продукта — практическая методология, отвечает на вопрос "Как конкретно что-то сделать?".

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


Как сделать правильный Whitepaper


Uploads 2f1509981524306 79qzy3xlzlb 286ee2a1c3964d0be34bf9da2e8fc7f3 2fscreen%2bshot%2b2017 11 06%2bat%2b17.57.24
Пошаговый план создания результативного пред-инвестиционного документа с разбором каждого шага:
  1. Природа появления и назначения такого типа документа
  2. Архитектура документа
  3. Редактура и формат

Тип продукта — практическая методология, отвечает на вопрос "Как конкретно что-то сделать?".

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



Еще можно почитать публикации: