{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Блоги: заметки с тегом как сделать", "_rss_description": "Автоматически собираемая лента заметок, написанных в блогах на Эгее", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": false, "_itunes_explicit": "no", "home_page_url": "https:\/\/blogengine.me\/blogs\/tags\/kak-sdelat\/", "feed_url": "https:\/\/blogengine.me\/blogs\/tags\/kak-sdelat\/json\/", "icon": false, "authors": [ { "name": "Илья Бирман", "url": "https:\/\/blogengine.me\/blogs\/", "avatar": false } ], "items": [ { "id": "135370", "url": "https:\/\/artemushanov.ru\/?go=all\/sila-prostoty-2\/", "title": "Сила простоты-2", "content_html": "

Я попробовал вести рабочие задачи и заметки в одном md-файле с синхронизацией через гитхаб и не только выжил, но и преуспел.<\/p>\n

Некоторое время назад я написал пост «Сила простоты»<\/a> про хранение индекса j.d — моей системы организации файлов и заметок. Индекс мне нужен для того, чтобы вспомнить, где лежит некоторый файл, или записать новую папку для хранения. Сейчас это обычный текстовый файл на гитхабе, хотя сначала я чрезмерно усложнил работу с ним — вел в заметочниках, с кучей категорий и папок. В итоге перешел на ведение txt-файла с синхронизацией через гитхаб и не жалею.<\/p>\n

В очередной раз немного подбесившись от тормозов Таны<\/a>, где я вел свои рабочие заметки, я задумался о переезде. Мне захотелось повторить тот минималистичный вайб, который мне дал переход на текстовый файл с индексом, но в голове засели какие-то ограничения: а как же теги<\/i>? А как же поля у заметок<\/i>, по которым я ищу? А как же сложнейшая система организации<\/i>, без которой все моментально превратится в бардак?<\/p>\n

Я в очередной раз посмотрел — в этот раз как исследователь — на Обсидиан, Emacs OrgMode и еще несколько инструментов, и понял, как устроены все заметочники.<\/p>\n

Как устроены заметочники<\/h3>\n

Заметочник — это некоторый файл или набор файлов (.md в обсидиане, .org в оргмоде) плюс редактор-рендерер. Обсидиан рендерит встроенные свойства маркадун-файлов, вроде таблиц и разметки текста, плюс имеет какое-то количество собственных надстроек для удобства работы. Оргмод вообще адски увешан свистелками-перделками (тудушки, календари, напоминалки), и все они рендерятся из текстового содержания орг-файла или какой-то его скрытой части, не видной пользователю.<\/p>\n

Аутлайнеры — workflowy, dynalist, roam research, tana.inc — используют формат буллет-листа с возможностью бесконечной вложенности. Единицей контента обычно считается буллет, и на него уже наворачивают фич кто во что горазд. Тана, например, умеет прикреплять к буллетам поля, с помощью которых можно как-то этот буллет формализовать: присвоить тип, дату, еще чего-то. После этого из таких буллетов можно строить таблички. Вот как выглядит карточка книги из моей таны:<\/p>\n

\n\"\"\n
Поля автоматически возникают у любого буллета, помеченного тегом #book<\/div>\n<\/div>\n

Что нам дает это понимание? Например, следующее: чем проще разметка и файл — тем быстрее все будет работать. В обсидиане поиск моментальный, а вот тана ощутимо подтормаживает и при поиске, и при скроллинге длинного списка буллетов.<\/p>\n

Вторая важная штука: если мы выбираем для задачника распространенный формат (md, txt) — нас лишь частично затронет утрата рендерера. Контент останется, мы его не потеряем. Тана и прочие аутлайнеры требуют регулярных бэкапов и перевода в нужный формат — потому что экспорт у них сделан через жопу и редко работает как надо. А контроль над собственным контентом для нас важен, т. к. наступает эра ИИ-агентов, которые точно смогут нам помочь с задачами-заметками, и проприетарные сервисы за их использование захотят получить свой кусочек маржи. А нам оно не надо: во-первых, мы дальновидные и хотим гибкости, пока рынок не определил лидеров; во-вторых — мы экономные и хрен вам, а не кусочек маржи.<\/p>\n

Очевидный вывод: можно получить удобство проприетарного инструмента вроде Таны\/воркфлови\/роума, если использовать распространенный формат файлов и хороший удобный редактор. Я остановился на двух конфигурациях: один маркдаун-файл и VScode для рабочих задач, с синхронизацией через гитхаб, и Обсидиан с синхронизацией через гитхаб для личных.<\/p>\n

Про Обсидиан и так все знают, поэтому сегодня мы говорим о первом варианте.<\/p>\n

Один файл для всего<\/h3>\n

В дополнение к вышеописанному добавлю, что все-таки хотелось понять — насколько минимальным может быть сетап для задач и заметок?<\/p>\n

В упомянутом посте «Сила простоты» я писал:<\/p>\n

\n

Индекс виден весь и целиком, не нужно открывать-закрывать папки и навигировать по структуре. Правится в любом редакторе на любом устройстве, ничего не весит. Когнитивная стоимость работы с текстовым файлом — почти нулевая. Поиск в нормальных текстовых редакторах работает лучше, чем в любом заметочнике. Можно скачать весь индекс куда и откуда угодно, переслать по почте, перекинуть в мессенджере.<\/p>\n<\/blockquote>\n

Все указанные плюсы в полной мере сохраняются и для задачника. Я веду его в одном файле с прошлого октября, сейчас в нем примерно три тысячи строк. Серьезный минус всего один: нельзя вставлять картинки.<\/p>\n

Почему файл всего один<\/i><\/p>\n

    \n
  1. Для облегчения поиска и снижения когнитивной нагрузки. Мне не нужно создавать отдельную заметку\/файл для каждой встречи, задачи или проекта — всё живет в одном файле и мгновенно ищется полнотекстовым поиском VSСode.<\/li>\n
  2. Для простоты синхронизации. Файл лежит на гитхабе, ничего не весит и доступен с любого компа.<\/li>\n<\/ol>\n

    Почему маркдаун<\/i>
    \nМаркдаун позволяет минимально размечать текст — заголовки, подзаголовки, списки, цитаты, — и при этом поддерживается кучей редакторов. Я работаю с файлом в режиме редактирования, но даже так редактор подсвечивает разметку, поэтому работать удобнее, чем с плоским txt.<\/p>\n

    Почему VSCode<\/i>
    \nМне он показался самым мощным из бесплатных вариантов. Быстро работает, отличный поиск, всякие программистские штуки вроде редактирования нескольких строк разом и т. п. Есть две киллер фичи конкретно для моего рабочего процесса: разделение окна (можно открыть разные части одного файла в разных секциях), панель результатов поиска с возможностью прокликать все результаты. Эти две фичи закрывают сразу несколько сценариев из тех, что меня беспокоили при отказе от проприетарных инструментов.<\/p>\n

    Почему гитхаб<\/i>
    \nПотому что на рабочем компе он разрешен, а облачные сервисы — нет. Плюсы — универсально, доступно. Минусы — нужно не забывать коммитить изменения в конце рабочего дня. Это всего два клика в десктопном клиента гитхаба, но нужно не забывать их делать, или изменения так и останутся на локальной машине. На рабочем компе с виндой я сделал bat-скрипт, который коммитит по расписанию и в случае простоя компа, на домашнем маке пока не сподобился.<\/p>\n

    Как устроен файл<\/h3>\n

    Ну раз у нас маркдаун, то можно навести некоторую иерархию. У меня она такая:<\/p>\n

    Заголовки первого уровня (один диез #) — это разделы, их несколько: индекс (важная инфа по файлу, список тегов, ссылки и тексты, которые регулярно нужны), задачи и заметки (тут основная работа), 2024 (тут все за прошлый год), старое (из других задачников переходного периода, меньше сотни строчек).
    \nЗаголовки второго уровня — это подразделы, в которых некая конкретная информация. В разделе «задачи и заметки» подразделами являются даты — каждый день я завожу строчку вида ## 28.03.25<\/tt> и пишу под ней задачи и заметки за день.<\/p>\n

    VSCode умеет показывать структуру файла по заголовкам, по ней можно сориентироваться.<\/p>\n

    \n\"\"\n<\/div>\n

    Заголовки третьего уровня — для встреч или важных заметок внутри дня.
    \nЗадачи я пишу маркированным списком (не признаю другого способа записи) и помечаю хештегом #todo в конце строки. По чесноку, хештег — избыточная мера: редактор не умеет делать хештеги кликабельными. Но я во-первых уже привык, а во-вторых, если открыть файл через Обсидиан — теги станут интерактивными.
    \nВыполненные задачи я помечаю тегом #done. В маркдауне есть разметка для чекбоксов:<\/p>\n

    - [ ]<\/code><\/pre>
    но ее неудобно вводить, неудобно искать и неудобно помечать выполненные.<\/p>\n
    Помимо todo\/done у меня есть теги для ссылок, контактов и справочной инфы, все эти теги перечислены в разделе  «Индекс» в самом верху файла. Строки с тегами я нахожу обычным поиском: контрол-эф, вводим тег, вуаля — во-первых теперь они подсвечены в тексте, во-вторых их видно на карте файла справа.
    \nЕсли жмем контрол-шифт-эф, то результаты поиска открываются в отдельной панели, что еще удобнее.<\/p>\n
    \n\"\"\n
    Панель с поиском слева<\/div>\n<\/div>\n
    Крошечный лайфхак, который нивелирует невозможность кликнуть тег: если выделить текст и нажать контрол-эф, VSCode сразу в окошке поиска вставит выделенный текст. Не нужно копипастить. А если вы умеете с клавиатуры выделять слово целиком (контрол-шифт-стрелка влево\/вправо), то по скорости эта операция не уступает клику по тегу в Обсидиане.<\/p>\n
    На связь задач и проектов я забил: проекты висят списком в самом верху раздела «Задачи и заметки», периодически я туда дописываю короткие комментарии и перемещаю проекты из активных в выполненные или отмененные, да и все. Из контекста задачи обычно понятно, к какому проекту она относится, если же я боюсь забыть — просто указываю в скобках в конце строки с задачей.<\/p>\n
    На встречах я либо набиваю заметки\/минутки прямо в файл, либо пишу от руки в ремаркабл и потом перебиваю в файл после встречи. Календарь и расписание живут в аутлуке.<\/p>\n
    И чо, удобно?<\/h3>\n
    Да, нормально. Базу знаний в таком формате вести вряд ли получится, а вот рабочие задачи и заметки — вполне, за почти полгода серьезных проблем у меня не возникло. Полнотекстовый поиск для извлечения информации показал себя лучше, чем хорошо организованная структура хранения, но в то же время он обязывает писать много и подробно. Прямо как я люблю.<\/p>\n
    Единственная штука, которую очень хочется, это возможность менять режим отображения в файле, скрывая часть строк. Речь не про collapse\/expand, это VScode умеет, пусть и только с мыши, я скорее про режимы отображения из OrgMode. Там можно было комбинацией клавиш циклически переключать вьюшки: показать всё, показать только задачи, показать только напоминалки, показать только заметки. Тогда можно продолжать вести записи в хронологическом порядке (единственный приемлемый для меня способ), но быстрее находить требуемое через нужную вьюшку.<\/p>\n",
            "date_published": "2025-03-28T06:21:45+05:00",
            "date_modified": "2025-03-28T06:20:27+05:00",
            "tags": [
                "post",
                "автоматизация",
                "как сделать",
                "софт"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Fri, 28 Mar 2025 06:21:45 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "135370",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "132570",
            "url": "https:\/\/artemushanov.ru\/?go=all\/zametki-po-ekzokorteksu\/",
            "title": "Проблема использования внешнего мозга",
            "content_html": "
    Люди используют два типа хранилищ для информации: свой мозг (который в голове) и внешние системы. Внешними системами могут быть любые носители, от блокнота с ручкой до обвешанного плагинами Обсидиана. Такие внешние системы иногда называют «экзокортексом» — внешним мозгом.<\/p>\n
    \n\"\"\n<\/div>\n
    Любая современная работа, не связанная с физическим трудом, подразумевает использование экзокортекса наравне со своим мозгом. И не просто подразумевает: внешняя информационная система многократно усиливает результативность работника. Еще совсем недавно в объявлениях о найме писали в качестве требования к кандидату «уверенный пользователь ПК». Сейчас уже не пишут, а подразумевают по дефолту; потому что если работа сложнее таскания камней с места на место — владение каким-то экзокортексом потребуется обязательно.<\/p>\n
    Экзокортекс хорошо дополняет наш мозг, он проще в обращении и легче дублируется. В экзокортекс влезет любое количество данных (носители растут в объеме очень быстро), туда легко записать информацию, легко ее извлечь или обработать. Для того, чтобы с такой же легкостью «писать» себе в мозг, потребуются месяцы тренировок на всякие мнемотехники для запоминания, а потом еще месяцы — на изучение техник извлечения. К тому же человеческая память — весьма ненадежный носитель, она склонна затираться, заменять фрагменты или даже целые воспоминания. И никаких change logs — если уж забыл, то забыл!<\/p>\n
    Все это подталкивает к мысли, что хранить информацию в экзокортексе и извлекать ее оттуда для использования — отличная идея, что тут может пойти не так?<\/p>\n
    Один важный нюанс<\/h3>\n
    Для удобства разделим информацию, хранящуюся в наших хранилищах, на два условных типа: справочные данные<\/i> и руководства к действию<\/i>. Справочные данные одинаково удобно хранить и в голове, и в экзокортексе. Телефон друга, адрес хорошего бара в курортном городке, количество БЖУ в порции пасты с креветками — эти кусочки информации одинаково полезны и однозначно воспринимаемы и по памяти, и будучи прочитанными в Apple Notes. Их просто нельзя интерпретировать по-разному.<\/p>\n
    Не так дело обстоит с типом «руководство к действию». К этому типу я отношу любые инструкции, мануалы, алгоритмы и прочие руководства. Руководство\/алгоритм обычно описывает порядок шагов, которые требуется предпринять для достижения некоторого результата. То есть, реципиент при прочтении руководства должен проделать описанное там.<\/p>\n
    Вот тут нюанс и всплывает. В чем разница алгоритма, запомненного и заученного до автоматизма, и алгоритма из базы знаний? В том, что первый алгоритм — интернализирован. При его выполнении возникает чувство «знакомости», привычности — мы это сто раз делали, мы это умеем.<\/p>\n
    А второй алгоритм будет выполняться параллельно с его чтением, и ни о какой интернализированности и привычности речи не идет. А значит, при выполнении такого алгоритма исполнитель будет ощущать не привычность и удобство, а что-то еще.<\/p>\n
    Если вы умеете ездить на велосипеде — у вас есть интернализированный навык. Вы просто садитесь и едете, руководство не нужно. Но если вы учитесь ездить на велосипеде по мануалу — «перекиньте ногу через раму, поставьте ногу на педаль...», — то скорее всего вы испытываете широкий спектр эмоций, от досады до ужаса.<\/p>\n
    Потому что ничего не получается, тело реагирует неправильно, нога цепляется за раму, велик норовит опрокинуться... Мануал можно хоть по сто раз в день перечитывать, но прогресс появится только от практики. Потом вы научитесь ездить, а через год-два будете делать это как профи.<\/p>\n
    Поменялся ли как-то за это время мануал? Нет — он и во время обучения был верным, и после освоения навыка остался таковым.<\/p>\n
    Менее физичный пример. Допустим, я уже сто раз варил кофе в турке и на интуитивном уровне понимаю правильность\/неправильность исполнения конкретных шагов алгоритма. Мне достаточно чуйки для того, чтобы сварить его в сто первый раз; я могу не помнить точное время до закипания или в какой момент нужно помешать ложечкой для получения пенки, но интуитивно верно проделаю эти операции, ориентируясь на свои ощущения и внешний вид напитка в турке.<\/p>\n
    Если я варю кофе впервые по рецепту из интернета — нужно будет сверяться по каждому шагу и контролировать свои действия. Чувства «привычности» при исполнении алгоритма из экзокортекса не будет, на каждом шаге будет казаться, что что-то идет не так.<\/p>\n
    Ценность алгоритма в голове и вне её<\/h3>\n
    В общем, если «телефон друга» в голове и в Apple Notes имеет плюс-минус одинаковую ценность, то алгоритм в интернализированном и записанном в блокнотике виде ощущается совершенно по-разному.<\/p>\n
    Вот та самая мысль, из-за которой я решил написать заметку:<\/p>\n
    Алгоритмы и инструкции, которые хранятся в экзокортексе, при воспроизведении лишены интуитивного ощущения «знакомости» и потому не ощущаются правильными.<\/p>\n
    Интернализированные алгоритмы — те, которые мы выучили и воспроизводим по памяти, — при выполнении ощущаются знакомыми, а значит — верными. Неинтернализированные алгоритмы из экзокортекса не ощущаются таковыми.<\/p>\n
    Если мы уверены в качестве источника, из которого получили алгоритм, то мы обязаны сделать еще один вывод: интуитивное ощущение правильности\/привычности не является обязательным признаком рабочего алгоритма. Только результат выполнения может свидетельствовать о качестве алгоритма, получилось задуманное — или нет.<\/p>\n
    Оформим вышеописанное в виде проблемы: при следовании записанному в экзокортекс алгоритму исполнитель не ощущает привычного ощущения правильности хода процесса, как бывает с интернализированными алгоритмами. Поэтому исполнитель отказывается от более эффективного, но незнакомого алгоритма в пользу менее эффективного, но знакомого.<\/p>\n
    И выходит, что вся работа по поиску, обработке и сохранению десятков (сотен, тысяч) алгоритмов была проделана напрасно. А ведь это время можно было потратить на онлайн-игры!<\/p>\n
    Доверяйте своему экзокортексу<\/h3>\n
    Нужно научиться доверять своему экзокортексу. То есть, себе самому в прошлом. Это же вы сами сохранили алгоритм в базу, пометили тегами, выделили куски текста хайлайтом. Просто так старались, что ли?<\/p>\n
    Во-первых, нужно интернализировать связанные с доступом к экзокортексу сценарии. Запись инфы в экзокортекс, получение инфы из экзокортекса — должны стать привычками. Тут любые средства хороши, можно потратить на это время и силы — потому что в идеале экзокортекс будет прирастать информацией и использоваться в течение всей жизни.
    \nЛюбой пройденный курс, любая прочитанная книга должны быть отражены в экзокортексе. Потому что интернализировать (превратить в навыки и привычки) всю информацию из них за короткое время средний человек точно не сможет.<\/p>\n
    Во-вторых, нужно правильно организовать сам экзокортекс. Доставать из него информацию должно быть примерно так же просто, как пользоваться библиотечным указателем. Он должен быть future proof — не ломаться при очередном обновлении операционной системы, или ноутбука, или при переезде в другой город. Он должен быть прост и универсален.<\/p>\n
    В-третьих, работу с информацией из экзокортекса нужно вести осознанно и обдуманно. Оценивать результат исполнения алгоритмов, а не ощущение знакомости\/правильности в процессе работы с ними. Обновлять информацию после получения обратной связи — и дописывать в базу знаний.<\/p>\n
    Эти выводы мне кажутся важными. Мы сталкиваемся с огромным количеством информации в течение жизни. Часть этой информации нам может пригодиться в дальнейшем, нужно ее сохранять на этот случай. Головы и мозга для этого недостаточно, они устроены так, что запоминают лишь долю от того, что требуется. Поэтому нам нужна внешняя память.<\/p>\n
    Информация в базе должна быть качественная: мы будем использовать ее в будущем и предпочитать другим источникам как проверенную. Для этого мы должны доверять своей базе знаний и хранящимся в ней инструкциям.<\/p>\n",
            "date_published": "2024-11-06T00:55:57+05:00",
            "date_modified": "2025-01-05T15:49:39+05:00",
            "tags": [
                "post",
                "интеллект",
                "как сделать",
                "экзокортекс"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Wed, 06 Nov 2024 00:55:57 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "132570",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "128787",
            "url": "https:\/\/artemushanov.ru\/?go=all\/piramida-minto-v-prodazhah\/",
            "title": "Пирамида Минто в продажах",
            "content_html": "
    Мой пост из сообщества «Алаверды»<\/p>\n
    Поговорим о том, как правильно строить аргументацию, чтобы наш собеседник имел меньше шансов отказаться. В этом нам помогут законы формальной логики и Барбара Минто со своей пирамидой.<\/p>\n
    \n\"\"\n<\/div>\n
    Пирамида Минто выглядит так:<\/p>\n
      \n
    1. «Верхушка»: главный месседж, утверждение или тезис. То, в чем мы хотим убедить собеседника.<\/li>\n
    2. Подробности к верхушке — по фреймворку СОВО (Ситуация, Осложнение, Вопрос, Ответ)<\/li>\n
    3. Первый уровень пирамиды — поддерживающие аргументы. То, что мы сообщаем в поддержку тезиса, 2-3 штуки. Должны отвечать принципу ВИСИ — «взаимно исключающие, совместно исчерпывающие».<\/li>\n
    4. Второй уровень пирамиды — свидетельства в пользу аргументов.<\/li>\n
    5. Основание пирамиды — заключение, подтверждающее тезис с помощью аргументов в кратком виде.<\/li>\n<\/ol>\n
      Строить пирамиду можно как сверху вниз, так и снизу вверх.<\/p>\n
      Пример<\/b>:<\/p>\n
        \n
      1. Допустим, мы хотим успешно продавать нашу специализированную CRM-систему ALVRD девелоперам. Формулируем тезис: «Наша CRM-система лучше всего подходит для нужд девелоперов». Вот наша верхушка. Подробности пусть будут такие: Ситуация — продажи недвижимости нужно вести правильно, соблюдая правила компании и не забывая про массу обязательных деталей; Осложнение — коммерческая деятельность с недвижимостью устроена сложнее, чем продажи в других сферах, поэтому стандартные СРМ-системы не подходят для автоматизации продаж; Вопрос — как же лучше быть: заказать кастомную разработку или смириться с отсутствием нужных функций в стандартных СРМ-системах?; Ответ — лучше купить СРМ-систему ALVRD.<\/li>\n
      2. Формулируем три аргумента. Первый: «За пять лет мы отлично разобрались в подробностях коммерческой работы девелоперов и воплотили эту экспертизу в продукте». Второй: «Пять крупных девелоперов из первой десятки пользуются нашей системой и довольны». Третий: «Нашу систему легко подстроить под любого девелопера или риэлтора с помощью простого редактора».<\/li>\n
      3. Формулируем свидетельства в поддержку аргументов:
        \nПервого: «мы учли все основные виды партнерств и типы продаж, вот список...»
        \nВторого: отзывы и кейс-стади пяти крупнейших девелоперов\/клиентов с акцентом на сильные стороны системы
        \nТретьего: картинки и описания редактора процессов, кейс «Как это сделано у девелопера Икс»<\/li>\n
      4. Основание пирамиды — заключение: «Наша CRM-система изначально проектировалась под коммерческие бизнес-процессы крупных девелоперов, поэтому... (аргументы, свидетельства)».<\/li>\n<\/ol>\n
        Как будет выглядеть готовый текст<\/b>:
        \n«CRM-система ALVRD лучше всего подходит для коммерческой работы крупных девелоперов и риэлторов.
        \nВ продажах принято использовать CRM-системы для фиксации лидов и сделок. Это помогает менеджерам не забывать важные вещи и доводить сделки до конца. Однако, в продажах недвижимости есть много специфики: ипотека, необходимость взаимодействовать с банками и регуляторами, обязательная проверка контрагентов и регистрация сделок в Росреестре. В стандартных CRM-системах нет поддержки этих процессов. Как быть? Можно потратить деньги и время и разработать кастомную систему, но это неоптимально — дорого и долго. Можно использовать стандартную CRM-систему и часть сделки вести в ней, часть — в переписке и Excel, но это сильно нагрузит менеджеров. Вместо этого мы предлагаем рассмотреть ALVRD — специализированную CRM-систему для коммерческих сделок с недвижимостью.<\/p>\n
        Мы более пяти лет работаем со строительными и риелторскими компаниями, и за это время отлично разобрались в их деятельности и воплотили эту экспертизу в продукте. Мы из коробки поддерживаем стандартную систему ролей и ведение KPI, легко подключаем партнеров или сети франчайзи, а также готовы предложить десять видов мотивирующих акций из числа наиболее часто встречающихся, с возможностью добавлять свои. Все стандартные виды договоров (ДДУ, ДКП, ДУПТ) уже внесены в систему и готовы к использованию.
        \nВ мире нет двух одинаковых компаний, даже если они работают в одной сфере, поэтому наша система легко модифицируется. Добавить новые процессы или переделать существующие можно с помощью встроенного редактора. Если нужно, мы проведем обучение и научим ваших сотрудников делать это самостоятельно. Если редактора не хватает и нужны более серьезные изменения — сделаем под вас проектную доработку, обычно это занимает от одного до трех месяцев. А еще мы внимательно отслеживаем изменения в законодательстве и быстро дорабатываем систему под них.<\/p>\n
        Пятеро крупнейших девелоперов из первой десятки в российском рейтинге работают с нами. Компания Прима с нашей помощью провела 3000 сделок купли-продажи за прошлый год, весь процесс полностью смоделирован в системе — вот кейс (ссылка). Компания Секунда в три раза увеличила сеть офисов продаж первички и вторички за два года, а мы помогли масштабировать и подстроить систему под новые задачи, описание кейса тут (ссылка). Компания Терция проводила маркетинговые эксперименты весь прошлый год — вот кейс, про то, как нам пришлось перестроить разработку и саппорт под короткие интенсивные проекты клиента (спойлер: были проблемы, но мы справились).<\/p>\n
        Именно по этим трем причинам мы считаем, что ALVRD — лучшая CRM-система для девелоперов и риэлторов. Мы знаем, как устроена коммерческая работа с недвижимостью, мы поможем подстроить систему под вас, и с нами уже работают лучшие игроки рынка.»<\/p>\n",
            "date_published": "2024-06-17T17:21:26+05:00",
            "date_modified": "2024-07-10T05:42:24+05:00",
            "tags": [
                "post",
                "как сделать",
                "методика",
                "Минто"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Mon, 17 Jun 2024 17:21:26 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "128787",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "127779",
            "url": "https:\/\/artemushanov.ru\/?go=all\/kak-izuchat-novuyu-predmetnuyu-oblast\/",
            "title": "Как изучать новую предметную область",
            "content_html": "
        Два месяца назад я пришел работать в компанию-девелопер, в дирекцию по цифровой ипотеке. Область для меня новая: ни со стройкой, ни с финансовыми продуктами я раньше не работал. Нужно разбираться.<\/p>\n
        «Разобраться» для меня означает следующие шаги:<\/p>\n
          \n
        1. Навести «грубую сетку» домена — понять, где мы вообще. «К черту подробности, город какой?»<\/li>\n
        2. Понять свое место в рамках домена — детализировать «сетку» в важных для проектов областях<\/li>\n
        3. Углубиться в изучение этих важных частей, разобраться в них до нужного уровня, чтобы предсказуемо планировать и реализовывать изменения.<\/li>\n<\/ol>\n
          Еще про грубую сетку в посте «Как читать сложную книгу<\/a>»<\/p>\n
          Первое, что я сделал — навел «грубую сетку» предметной области. Без этого действия любые факты и детали, относящиеся к предметке, как бы повисают в неопределенности: ну вот они есть, а куда и как их сложить — непонятно. Чтобы такого не было, нужно завести какое-то небольшое количество условных смысловых коробочек и начать факты с деталями раскладывать по ним. Качество этих коробочек изначально будет плохим — это не страшно, потом переделаем как надо. Но сначала надо понять, а как же надо.<\/p>\n
          \n\"\"\n
          Грубой сетки достаточно, чтобы понять общие очертания объектов в домене<\/div>\n<\/div>\n<\/div>
          Грубую сетку я себе построил путем чтения статей и просмотра видосов на тему ипотеки и всяких сопутствующих штук — их в рунете навалом.<\/p>\n
          Сложилась вот такая картинка:<\/p>\n