Мьёльнир - платформа для создания (технологических) продуктов

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

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

Идея проекта

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

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

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

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

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

Подробнее об этом я докладывал в на хайлоуде у Олега Бунина.

Дорожная карта

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

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

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

Цель нельзя "выполнить", можно только "получить".

  • Написать пост - задача. Получить просмотры - цель.
  • Сделать фичу - задача. Получить пользование ей - цель.
  • Открыть бизнес - задача. Получить прибыль в бизнес - цель.

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

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

Хороший план - тот что отвечает на вопрос "а че *ля если нет?"

Чеклист хорошей дорожной карты / стратегии / плана:

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

В связи с этим ваши действия становятся простыми:

  • Изложить из все что есть в голове о проекте сразу на карту
  • Расставить связь - причина-следствие
  • Добавить вариантов развития событий (а что делать если не достиг цели)
  • Разделить что цель а что задача
  • Переслать товарищу / инвестору / команде
  • ...
  • Profit!

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

От диаграммы Ганта ...

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

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

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

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

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

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

... к "пяти пoчeму" Тойоды

Основатель компании Тоуоta, Caкити Тoйодa, постоянно пользовался правилом «пяти пoчeму». Во всех непонятных ситуациях он использовал этот метод, и тот ему всегда помогал.

Например, тебе хочется шyбy.

Спрашиваешь себя: почему я хочу шубy? Это первое «почему». Отвечаешь: потому что я хочу всех удивить.

Окей, второе «почему»: Почему ты хочешь всех удивить?
Ответ: Потому что хочу, чтобы на меня обратили внимание.

Третье «почему»: Почему тебе нужно, чтобы на тебя обратили внимание?
Ответ: Потому что я чувствую себя неуверенно.

Четвертое «почему»: Почему ты чувствуешь себя неуверенно?
Ответ: Потому что я никак не могу реализоваться, потому что я сижу на одном месте.

Пятое «почему»: Почему ты не можешь реализовать себя?
Ответ: Потому что я занимаюсь тем, что мне не нpaвится.

И скажи теперь, при чем тут шуба?

Caкити Тoйодa, Основатель компании Тоуоta

Caкити Тойoдa научил, что в ответе на пятое «почему» и кроется первопричина, которая, на первый взгляд, не просматривается. Пятое «потому что» выводит на свет то, что скрыто. Если угодно, пятoe «потому что» и есть настоящий ты. Это очень действенный способ проверить, что ты на самом деле скрываешь, в чём боишься признаться дaже себе, чего ты действительно хочешь и что, на самом деле, просто мишура.

Спасибо господину Тoйoде не только за Тoйoтy, а тут могу лишь добавить что совершенно случайно вышло объединить два этих назначения:

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

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

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

Подробный разбор как формируется концепция проекта на живом примере можно посмотреть тут (видео).

Просто трекинг задачи

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

Поэтому есть режим трекинга - можно вооще не нырять в разработку.

Режим трекинга

Хозяйке на заметку

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

Разработка продукта

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

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

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

Конструирование

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

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

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

Выглядит это так: (как это делается посмотреть можно на видео)

Конструирование Архитектуры. Александр Павлють.

Коротко что выявляется в этой процедуре:

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

Все это складывается далее в автоматические разделы документации "Предметная область"

Онтология предметной области, тезаурус.

И "Функции проекта"

Функции проекта.

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

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

Цепочка задач

Карточки все кликабельные, уже заполненные заданиями, вот тут есть пример того, как разделяется "труд" по продукту (продукты бекенд и мобайл):

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

В тестировании мы шьем баг репорты если надо:

В Enabling (приемка / ввод в эксплуатацию) мы раскрываем терминологию, описываем функции и пишем юзер-гайд на то что сделано:

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

Вроде бы это неплохо получить такой набор документов out-of-the-box:

1. Ментальную карту + Whitepaper
2. Онтологию и тезаурус предметной области
3. Сформулированные технические задания с критериями приемки по каждой задаче
4. Функциональная спецификация
5. Спецификация продуктов
6. Пользовательский гид

Также есть внутренняя wiki - иногда нужный инструмент, хотя у нас пустой.

And one more thing ...

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

Все (почти) скриншоты сделаны из этого проекта - пожалуйста изучайте:

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

Копирование шаблона к себе в проект.

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

Резюме

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

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

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

Если еще интересно на какой почве прорастает вся идея и замысел, рекомендую ознакомится с моим путеводителем:

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

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

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

Благодарим дорогую редакцию vc за площадку, всем - хороших выходных!

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

Как продукт - норм?

0
14 комментариев
Написать комментарий...
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Pol Bal

Спасибо за материал!

Ответить
Развернуть ветку
Alexander Pavlyut
Автор

Рад что полезен, спасибо.

Ответить
Развернуть ветку
Slava Gatsko

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

Ответить
Развернуть ветку
Alexander Pavlyut
Автор

Спасибо, я всегда на прямой связи.

Ответить
Развернуть ветку
Сергей Киселев

Хороший продукт!

Ответить
Развернуть ветку
Сергей Киселев

Удачи в продвижении!

Ответить
Развернуть ветку
Alexander Pavlyut
Автор

Спасибо!

Ответить
Развернуть ветку
Ilya Dyachenko

Интереснейший продукт. Слежу за развитием.

Ответить
Развернуть ветку
Vladislav Proshinsky

Полезно. Попробую

Ответить
Развернуть ветку
Alexander Pavlyut
Автор

Добро пожаловать на борт.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Alexander Pavlyut
Автор

Можно прямо писать что именно непонятно - я раскрою подробности.

Ответить
Развернуть ветку
Сэнди Найтова
Ответить
Развернуть ветку
Alexander Pavlyut
Автор
Ответить
Развернуть ветку
11 комментариев
Раскрывать всегда