Промысел

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

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

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

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

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

В итоге можно грабить корованы
1. Сначала было слово
Которое мы пишем в телеграм бот, и он нам все сохраняет.
Мы отлавливаем что нас интересует, чтобы не забыть, как говорят "в мемориз".
2. GTD развилка: дело, информация или выкинуть
Добавленное это падает в фид входящих в системе, в котором мы можем это отклассифицировать или закрыть вопрос чтобы не маячил.

3. Классификатор
Или прокрастинатор - можно все пораскладывать по полочкам до посинения, очень практично.

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



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

В общем рекомендую:


4. Пульс
Блиц ответ на вопрос "Чо как" или "как дела" самому себе.

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

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

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

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

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

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

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

Больше тонкостей ищите в путеводителе руководителя.

Стандарт дорожной карты взят из плана мероприятий и порядка оформления дорожных карт из законодательства, главые графы в которых это:
  1. Целеполагание и
  2. Ожидаемый результат
Понятно что ответственные само собой, но заполнение этих граф и совместное подписание сторонами такого документа имеет магическую силу. 

Визуализация честно потянута с гитхаба.

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

Все наглядно.
8. Промысел в действии
Про промысел есть целое видео, так выглядит обработанный, "промысленный" документ.

Сверху текст, снизу выводы и следствия.

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

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

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

Повышает управленческий сигнал кратно, рекомендую.

Как строить сети смотрим в Путеводителе руководителя.

11. Требования - учет и управление
Без требований невозможно что-то сделать.

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

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

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

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

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

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



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

12. Результат, а не задача
Результаты это не задачи, это всегда файлы.

Один файл один результат.

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

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

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

Поэтому результат крепится к задаче.

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

14. Канбан
Самое мое любимое - канбанчик.

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

Потому что они и есть физическая измеряемая форма ваших действий.

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

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

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

(При открытии канбана сверху остаются задачи, у которых нет результатов, такой беклог для канбана):

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

Даже самому себе, это полезно.

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



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




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

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

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

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

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



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

Как я уже устал всем объяснять, что 90% или больше содержания всех созвонах это коммуникации об теоретизацию.

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

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

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

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

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

Такие дела, никакой воды, все только по делу.

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

В общем рисовать их ненадо, их надо смотреть, после того как хорошо поработал.

23. Концепция. Business Model Canvas
Куда без нее.

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


25. Сайты. Моделирование
В основе любой веб системы лежит модель данных.

Ее мы собираем в Промысле.

Модель этого сайта собрана так, как и сам сайт.


26. Настройки сайта
27. Документы
В системе простой редактор документов, для автора заменяющий всякие ноушны как и было заявлено.


28. Шаблоны
Как вы понимаете документ можно публиковать при помощи шаблонов как страницу на сайт.

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

А уже этот документ выводить на странице.


30. Версионирование. Повестка
Из коробки у нас каждый документ версинируется.

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

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


32. Медиа библиотека
Ну и все файлы и документы которые мы имеем в папках можно использовать на страницах.


Дата выпуска
  • 24 сентября 2024 года
Категории
Тематика
Действующие лица
Павлють Александр
Технологии
Возможности