Задача
Запустить новое направление бизнеса на Кипре — управление недвижимостью.
Контекст
- Общий рынок ~ 21 000 зданий (220000 домохозяйств) в “совместной собственности”, что означает необходимость соответствия нормам, предписанными законом по управлению, страхованию, содержанию.
- Рынок управления оценивается в €178–284 млн и растёт темпами до 20% в год.
- Из общего количества около 27% не соответствует закону. И сейчас в парламенте рассматривается об ужесточении проверки соотсветвия законодательству.
- То есть около 60000 домохозяйств будут искать профессиональных управляющих недвижимостью.
- Сейчас на рынке кризис: жители получают низкий уровень услуги, при этом не влияют на качество обслуживания/управления.
- Моя компания несколько лет реализует техническое обслуживание и ремонты для частных заказчиков. И может выступить системным игроком на этом рынке с адаптированной услугой.
Сетап
- среда: VS Code
- расширение: Claude Code for VS Code от Anthropic
- FPF: mcp от @nedbailov375426 Станислав Недбайлов https://fpf.sh
- подписка: GLM Coding Pro от z.ai
Выбор системы обусловлен финансами — $200/месяц в настоящий момент за рамками моего бюджета. $25/месяц — мне хватает и по бюджету токенов и по качеству рассуждений (хотя, конечно, хочется лучше).
Проект умер, да здравствует проект
Моя новая работа биздев в компании, осуществляющей ремонты. И предыдущий месяц я провёл за привлечением клиентов на этот вид услуги. Отправил несколько десятков предметных приглашений к сотрудничеству, провёл несколько встреч. Получил 5 заявок, одна из которых была реализована (выполнена) компанией.
Следующим возможным развитием могла стать автоматизация поиска заявок — понятны продукт, каналы, коммуникация. Но узкое звено становится персонал: компания предлагает не только высокий уровень реализации ремонта, но и высокий уровень сервиса: моляры не пьют, не курят, не матерятся, денег у собственников не занимают (и не существуют).
Для компании с накопленной экспертизой по техническому сопровождению логичным является переход от разовой услуги ремонта к регулярной, где взаимодействие с заказчиком линейных сотрудников ниже, а доходность обеспечивается за счёт объёма — количества оказанных услуг.
Изначально я формулировал задачу, как создание описания для запуска компании, которая должна была предоставлять техническое и административное сопровождение — FM (facility management). Задача не была новой для меня. В Барекамутюн мы проектировали тоже самое — сначала для своего собственного объекта, а потом и для других объектов мы хотели предлагать и развивать услугу.
Тогда запуск не случился из-за отсутствия собственного кейса — другие заказчики нам не поверили, что мы справимся с задачами, если мы нигде не работали. Теперь этот кредит доверия у нас пройден — мы видный игрок на рынке, хоть и в смежных услугах.
Проект, ещё проект
Разработку я начал с общего описания — по ходу исслудования складывал в один документ всё, относящееся к сути: системы, системы создания, план работ, экземплеры чеклистов отдельных работ, законодательные акты и проч.
Когда я перестал удерживать во внимании содержание, попросил проанализировать FPF и уточнить свой план.
Правило для работы с моделью — выгружать из контекста её критические рассуждения. Так, предложенные с FPF семь эпистем, были вынесены в отдельный чеклист для дальнейшего отслеживания зрелости проекта:
- BoundedContext
- Description
- Method/MethodDescription
- Role/RoleState
- WorkPlan
- Work occurrences
- ArchitectureDecision
Так как эти эпистемы общие для всех проектов, а FM не последний моделируемый мной проект, сразу захотелось выделить ещё один проект, который будет опорой для создания и FM, и последующих — Платформа.
И третьим я добавил проект, который будет вестись самой FM. Таких проектов будет много, поэтому я сразу хочу разработать стандарт для объектов недвижимости. Буду сохранять информацию и в FM, и в FM/P1.
Так появилось несколько репо, которые будут развиваться по общим правилам.