Что я понял про разработку, годами наблюдая за программистами со стороны

Годы, проведенные в бизнесе, особенно в сфере, далекой от IT, научили меня одной важной вещи: между «хочу» и «как это сделать» в мире программирования лежит настоящая пропасть. Я не программист по образованию – мой путь начался со спорта, живописи, а затем экономики и ландшафтного дизайна. Тем не менее, с начала 90-х годов, когда я управлял НПФ «Алькар» и ставил задачи программистам по управленческому учету, и до создания formspace.design в 61 год, я постоянно сталкивался с разработкой. И вот что я понял о ней, наблюдая со стороны.

Пропасть между "хочу" и "как это сделать"

Самое первое и, пожалуй, главное, что я осознал – это фундаментальная разница в мышлении. Предприниматель, практик, мыслит категориями задач и решений для клиента: «Нам нужно, чтобы клиент мог выбрать растения по определенным критериям», «Мне нужен отчет о маржинальности проектов». Программист же мыслит категориями кода, алгоритмов, структур данных, эффективности и масштабируемости. Он не видит конечного пользователя так, как его вижу я. Для него задача «выбрать растения по критериям» раскладывается на базу данных, фильтры, запросы, интерфейсные элементы и так далее. И часто в этой трансляции теряется суть. Например, я могу сказать: «Нужна CRM для ландшафтного бизнеса», подразумевая учет до 20 одновременных проектов, с 20-30 параметрами для каждого растения и сложным циклом работ. Программист же может начать с базовой CRM, которая подходит для любого бизнеса, не углубляясь в специфику.

Важность четкого ТЗ и почему оно всегда "недостаточное"

Я много раз составлял технические задания – сначала для систем управленческого учета в «Алькаре», потом для автоматизации процессов в «Дом и Сад». И каждый раз, казалось бы, я прописывал все до мельчайших деталей. Но после первой итерации я понимал, что чего-то не хватает. Программисты не читают между строк, они не догадываются о контексте. Если я не указал, что при расчете стоимости мощения участка площадью 50 м² с тремя типами плитки нужно учитывать 5% на отходы и разные цены на укладку для каждого типа, то расчет будет простым умножением площади на цену. Это не их вина, это моя ответственность как заказчика. Я понял, что почему технический долг в бизнесе начинается с плохого брифинга – это прямое следствие неполного, пусть и объемного, ТЗ. Каждая неопределенность – это потенциальная ошибка или задержка.

Мышление программиста: не "что", а "как"

Программисты – это инженеры, которые строят мосты из кода. Им важна прочность конструкции, ее эффективность, скорость. Мне же, как владельцу бизнеса, важнее, чтобы мост вел куда надо и по нему могли пройти люди. Это не значит, что качество кода не важно, но приоритеты часто расходятся. Программист может часами оптимизировать запрос, который выполняется за 0.01 секунды, чтобы он выполнялся за 0.005 секунды, в то время как бизнесу важнее, чтобы появилась новая функция, приносящая доход. Эта разница в фокусе – одна из ключевых причин, почему разница между продуктом от программистов и продуктом от практика так велика. Они видят код, я вижу решение проблемы клиента.

Технический долг и его корни в коммуникации

Технический долг – это не просто «плохой код». Это, в первую очередь, результат компромиссов, принятых на этапе разработки из-за нечетких требований или стремления к быстрому результату без должного планирования. Я помню случай, когда мне нужно было срочно внедрить новый тип расчета для определения маржинальности услуг. Программист сделал «быстрый костыль», который работал, но был жестко завязан на одну конкретную услугу. Через полгода, когда появились новые услуги и нужно было масштабировать расчет, этот «костыль» превратился в огромную проблему, требующую полной переработки. То, что заняло бы пару дней на старте при правильном планировании, превратилось в недели работы и тысячи долларов затрат. Это типичный пример того, как нежелание или невозможность глубоко погрузиться в бизнес-логику на старте приводит к долгосрочным проблемам.

Как я научился говорить на их языке (или хотя бы понимать его)

С годами я понял, что единственный способ преодолеть эту пропасть – это самому приблизиться к пониманию логики разработки. Это не значит, что я стал профессиональным программистом, но я начал изучать основы, разбираться в архитектуре систем, понимать принципы работы баз данных. А с появлением ИИ, в 61 год, я получил инструмент, который позволил мне не просто ставить задачи, а формировать их, общаться с «кодом» напрямую, проверяя свои гипотезы и даже создавая прототипы. Это дало мне невероятную свободу и возможность построить formspace.design, не имея штата программистов. Это путь, доступный каждому, кто готов погрузиться в предметную область и проявить дисциплину.

Когда продукт нужен "здесь и сейчас", а не "когда допилят"

Бизнес не может ждать идеального продукта годами. Нужен MVP (Minimum Viable Product) – минимально жизнеспособный продукт, который решает основную проблему клиента, даже если он не идеален. Программисты часто стремятся к совершенству, к безупречной архитектуре, к отсутствию багов. Это похвально, но в реальном мире это означает упущенные возможности и потерянные клиенты. Мой опыт научил меня ценить скорость и итеративность. Лучше выпустить продукт с 80% функций, которые действительно нужны, и быстро доработать его на основе обратной связи, чем оттачивать 100% функций, которые могут оказаться ненужными.

Как мой опыт отразился в formspace.design

Все эти годы наблюдения и работы с программистами, все мои «боли» и «прозрения» легли в основу formspace.design. Я создавал его как инструмент, который максимально сглаживает эти острые углы. Я стремился сделать его интуитивно понятным для ландшафтных дизайнеров и владельцев участков, чтобы они могли воплощать свои идеи, не углубляясь в технические дебри. Отсутствие штата программистов и использование ИИ в разработке позволили мне создать продукт, который отражает реальные потребности рынка, а не только технические возможности. Это продукт, который я сам хотел иметь в своей практике.

Как спланировать ландшафт в formspace.design

Представьте, что вы хотите создать на участке 15 соток зону отдыха с перголой и небольшим водоемом. formspace.design разработан как мост между вашей идеей и ее реализацией, минуя сложные объяснения с техническими специалистами. Сначала я бы загрузил аэрофотоснимок или нарисовал контур участка в модуле 1.0 «План участка». Это позволяет быстро получить основу для работы.

Затем, используя модули зонирования (1.1 «Зоны»), я бы определил место для зоны отдыха, детской площадки и огорода, учитывая стороны света и уклон. В модуле 2.1 «ИИ-концепция» можно получить несколько вариантов дизайна, просто описав свои пожелания. Например, «современный стиль, минимализм, преобладание хвойных растений». ИИ предложит идеи, которые затем можно детализировать, добавляя объекты (1.2 «Объекты») — ту же перголу, скамейки, светильники. А модуль 3.1 «Дизайн по фото» позволит увидеть, как выбранные элементы будут смотреться на реальном снимке вашего участка. Это позволяет увидеть общую картину и избежать многих ошибок еще до начала работ, не прибегая к дорогостоящим услугам проектировщиков или долгим объяснениям с исполнителями.

FAQ

Могу ли я обойтись без программистов, если у меня есть ИИ?

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

В чем главное отличие в подходе между бизнесом и IT?

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

Как избежать бесконечных доработок и переделок?

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

Стоит ли изучать основы кодирования для лучшей коммуникации?

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

Почему программисты часто не понимают "очевидных" для бизнеса вещей?

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

Как выбрать правильного разработчика для своего проекта?

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

Мой продукт слишком нишевый, стоит ли его автоматизировать?

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

Что такое "технический долг" с точки зрения бизнеса?

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

Мой путь к formspace.design был долгим, полным ошибок и открытий в общении с миром разработки. Но каждое из этих пониманий сделало меня сильнее и помогло создать продукт, который, я надеюсь, будет полезен тысячам людей. Главное – не бояться углубляться в то, что кажется сложным, и всегда помнить, для кого и зачем вы создаете свой продукт. Это и есть настоящий опыт.

Связанные материалы

• Читать дальше