Мой основной проект — это платформа для конструирования веб-приложений для автоматизации процессов: база данных, действия, триггеры, интерфейс. Но пока я её разрабатывал, сделал множество готовых решений автоматизации под конкретные задачи. И почти везде встречалась одна и та же история: проект застревал где-то посередине, и дальше требовались какие-то невероятные усилия, чтобы довести его до завершения. По факту эти усилия ложились на меня.
В конце концов я пришёл к выводу, что лучше бы их вообще не брать. Но если уж ввязался — то только на следующих условиях (которые в последние несколько проектов спасли мне миллиарды нервных клеток).
Может, это я плохой сервис оказывал клиентами, что так все плохо?
Ну не совсем так, скорее даже наоборот. Когда заказчик знает, что вы — и разработчик платформы, и общаетесь с ним не через прослойку из десяти менеджеров, а напрямую, — это создаёт некоторое измерение безумия: ночью что-то приснилось, и утром в восьми случаях из десяти с нас требовали, чтобы вот непременно именно в платформе поменяли всё вверх-ногами, потому что «вот так надо». Особенно это было интересно, когда два заказчика на разных проектах, идущих параллельно, требовали изменить стандартное поведение в противоположные стороны. Но это оставим в стороне — про это рассказывал здесь: https://habr.com/ru/companies/totum_online/articles/972596/
Прослойка из 10 менеджеров, которая на автомате на всё отвечает, как они заинтересованы, а потом кладёт обращение в корзину, — тоже очень помогает (но у меня таких не было, я всегда страдал и за себя и за других, где отвечали менеджеры-автоответчики).
Когда мы опубликовали платформу, достаточно быстро появились люди, которые закончили свои внутренние проекты автоматизации и пришли спросить — нет ли заказов со стороны. Мы начали отправлять интересующихся к ним — и те стали в ужасе разбегаться (не заказчики, а потенциальные подрядчики). Потому что делать проект внутри компании, будучи её частью, и делать его же на заказ — это совсем разные вещи.
И одно из сильно отличающихся измерений — это сам факт сдельной оплаты
Недавно тут была статья (потерял ссылку) со статистикой судебных дел в диапазоне 1–3 млн ₽. Вот там проекты автоматизации — самые ужасные: за них, помимо того что не платят, когда они сделаны, так ещё и часто требуют вернуть деньги.
В чем проблема оплаты на подряде?
В том, что заказчику как-то не очень заходит оплачивать штуку, которая не решает его задачу (и если может не заплатить, то и не платит).
А как так может быть, что автоматизация не решает задачу, если всё сделано, как он просил, и даже лучше — ведь мы выяснили проблемы и нестыковки и сразу их порешили?
А вот как:
Он заказывает автоматизацию, рассчитывая решить проблему, которая не решается автоматизацией!
Из нашего опыта такие были случаи:
Система должна ликвидировать незаменимость одного из сотрудников, и данные в систему должен вводить этот же сотрудник… ну всё, приехали.
То же самое применительно к отделу — система автоматически выполняет работу, которую выполняет отдел из трёх человек за один вечер, и внедрение поручается… тадам! — этому же отделу!
Система должна решить проблему планирования и расчёта сроков (что нарушает интересы одного из начальников), но для этого в систему должны быть внесены корректные нормировочные данные (расчёт которых задерживается уже в течение Х лет), и эти данные должен предоставить… этот самый отдел!
Система предоставит данные, но дальше всё равно требуется действие в физическом мире — и это действие не совершается уже Х лет
Похоже на абонемент в спортзал: система разрабатывается, ожидая, что её наличие простимулирует выполнение этого действия. Пример — выложенная система поиска более выгодных предложений по загруженным счётам (описание здесь: https://habr.com/ru/companies/totum_online/articles/976542/). И тут даже если отделу закупок на ногу не наступает (его нет), то всё равно надо что-то менять — а не хочется (хотя пользователи есть, но используют систему для чего-то другого).
Решили приделать финтифлюшку к процессу, который и так работает
Учёт чего-то ведётся в Excel, и там уже пять лет всё в порядке: да, есть ошибки, но они ни на что не влияют и последствий не имеют. Или, например, вручную считается количество чего-то для определения качества. И тут решают сделать это очень модно — чтобы фотоаппарат сам что-то фотографировал, нейросеть считала. Но потом, правда, всё равно пересчитают для проверки.
Даже если пересчитывать не будут, установка образца, например, для пересчёта и фотографирования всё равно осуществляется вручную (робота Ф. ещё не завезли), и время установки образца занимает 80% всего процесса. Эта автоматизация просто не заработает ни при каких обстоятельствах.
Просто решили сделать бесполезную штуку
Я не знаю почему, но особенно это к заводским цехам при��енимо — лампочка или табло, которое светится над станком и что-то там показывает через весь цех в будку начальника смены, — это прямо какой-то фетиш. Особенно её хотят те, у кого на станках нет такой заводской. Откорректировать при этом таблицы расчёта времени они обычно не хотят — это обратно пропорционально желанию иметь мигающую лампочку. У тех, у кого японцы такую поставили, всё уже мигает, и это ничего не поменяло — они как-то более расслаблены в этом направлении.
В процессе выяснилось, что есть конкурирующий подрядчик, от которого зависит работоспособность итоговой системы
Например, очень злая бухгалтерия на подряде, которая хотела продать вашему заказчику свою систему управления процессами.
Заказали большую систему из 10 модулей, а реальную проблему решил уже первый — и дальше ничего не надо
Но контракт-то был подписан на 10, а мотивация подупала.
Система вообще должна всё-превсё изменить, но только она одна — и магическим образом, без участия сотрудников, то есть изменить самих сотрудников
Это вообще классика — таблетка белая, чтобы вылечиться. Заказало руководство, всё даже сделали и даже запустили (сотрудники не дураки ведь — начальство хочет, чтобы что-то изобразили, вот и изобразили; время на это обычно есть свободное), и она там как-то параллельно в виде ИБД существует. Для подрядчика вообще неплохой вариант.
Как получается зомби-система?
Приступили мы к разработке вот этого всего. И да, предварительная оценка же не решает всех этих проблем, если нам надо взять заказ в разработку.
Если есть возможность отказаться (как у чуваков, которые у нас все разбежались), то это самый лучший вариант. А что если надо за что-то взять денег? Или, например, заказчик клянётся, что всё понял и порешает в процессе (ага, порешает — я ни разу не видел, чтобы порешал)?
Дальше мы как подрядчик делаем какую-то часть проекта, обычно до того момента, когда все понимают, что травка пузик не щекочет (такой момент рано или поздно наступает), — и тут начинается:
Переключение на задачи, которые не ведут к завершению, а усложняют функционал сбоку (это особенно выражено, когда со стороны заказчика есть человек, ведущий проект, но без полномочий реально что-то менять в статус-кво).
Бесконечные правочки, затягивающие всё в бесконечность.
Просто неоплата.
Игнорирование (иногда какими-то непонятными импульсами всё это движется).
Требование денег обратно.
В нашем случае — ещё и требования изменить платформу.
Неважно, из каких психологических причин это получается — ведь статья не про психологию, а про бабки и время, потраченное на фигню.
Далее — система, которая меня очень выручала, чтобы спокойно выезжать из всего этого
Ключевая подсказка, как с этим всем быть: заказчик на самом деле в глубине души всё понимает — как дела обстоят на самом деле, — и нанимать человека на зарплату (пусть даже и на временный проект) он обычно не хочет. Кто хочет — тот так и делает, и у них всё успешно: они потом годами покупают у нас лицензии, и у них всё хорошо. А если есть глубокие внутренние сомнения — то подрядчик то выгоднее (он же клиентоориентирован и мы его можем немножечко поэксплуатировать в серой зоне договоренностей, которые в сложном проекте с небольшим бюджетом есть всегда).
Выход отсюда — time-and-material, но для сложных проектов временные рамки никто не отменял. Если два дня делаем, потом полгода пауза, а потом снова срочно два дня — так в итоге ничего не получится.
Поэтому для нашего среднего чека 800К–1,5М выработали такую схему:
Здесь ещё раз оговорюсь, что всё это выработано для случая, когда нет армии менеджеров, юристов и бухгалтеров, которые могут тратить своё рабочее время на выяснение, что там не так с требованиями заказчика, — а мне самому это ещё и глубоко неинтересно.
И всё это заточено на то, чтобы завершить проект с теми, кто реально хочет его завершить, и быстро расстаться с теми, кто на старте летал в своих фантазиях. Не работает, если ваша задача — вытрясти деньги любой ценой, в том числе и из вторых.
Итак погнали:
Делаем некоторый предварительный скоринг (1–2 встречи по 2 часа) — бесплатно. Это не финальное ТЗ (его не будет, оно бесполезно) — это чтобы понять, что хотят сделать и где всё это зафейлится.
Если есть ключевой технологический элемент, в котором мы сами не уверены (например, скрипт, который будет считывать параметры чертежа из .dxf), — делаем предварительно с затратами не более 10 часов без предоплаты (сейчас с вайб-кодингом это стало сильно проще и возможностей больше), но это время учитывается далее в случае заключения договора.
По результатам при заключении договора на разработку составляется условная схема проекта с модулями, которые в нём должны быть, и описаниями функционала — максимум по одному абзацу на каждый.
Ключевое — это взаимосвязи модулей и последовательность их разработки.
Также мы в схему вписывали, что именно не заработает из-за действий (или бездействия) сотрудников заказчика: «модуль не заработает без корректного внесения данных производственным отделом».
Порядок, в котором они будут разрабатываться: мы стремились дойти до точки фейла как можно раньше (желательно в первые две итерации).
Условие, что по ключевым моментам будут специальные акты-подтверждения — без них продолжение невозможно, и отдельных сроков на них не устанавливается; предполагается, что заказчик ведёт подготовку критических данных параллельно.
Закрепляется стоимость часа от общего объёма проекта, но с условием, что она будет пересмотрена для последующих работ, если заказчик нарушит сроки оплаты.
Предмет договора: часы работы, затраченные на разработку описанного проекта, — в обмен на оплату.
Закрепляется объём часов, который мы как подрядчик обязаны тратить на проект в месяц (не менее Х часов). Отсюда получается плюс-минус срок готовности, но никакие конкретные даты не прописываются — если есть дата, она станет инструментом давления (неважно, чьего). Также никакой ориентировочной конечной цифры по часам или сумме — ни при каких обстоятельствах! Только устно, с 100500 оговорками, и не про этот проект, а: «похожие проекты имели показатели Y». Плюс обсуждение того, что миллион у вас должен быть выделен на первый период.
Закрепляется объём времени, который заказчик обязан выделить ответственным сотрудникам на созвоны — обычно до 4 часов в неделю (хотя на практике это может быть и меньше; встречи проводятся по нашей необходимости).
Закрепляется объём итерации, обычно это 150–200 тыс. руб. — её оплачивают.
Разработка ведётся на сервере заказчика, чтобы не было потом вопросов с передачей. Можно контролировать в режиме реального времени.
За неделю предоставляется отчёт с часами и акт. По акту — возражения по объёму выполненной работы в течение недели или подписание. Нет подписания — значит, проект останавливается. Здесь важно железно не продолжать, если у вас уже два неподписанных акта. Если неподписано два — значит, можно не подписывать вообще ничего, и тогда всё это теряет смысл.
Когда исчерпан весь предоплаченный объём, заказчик обязан оплатить следующий в течение недели. Не оплатил — пауза до трёх недель. Не оплатил в течение месяца — неважно, что он говорит, но в договоре должно быть указано, что после такой паузы возобновление работ после оплаты осуществляется не сразу, а в течение двух-трёх месяцев (ушли делать другой проект).
Пауза три месяца — возможность одностороннего расторжения со стороны подрядчика и возможность изменения стоимости часа работ. Три месяца означают, что заказчик из проекта выбыл.
Оплатил, даже подписал все акты, но застрял на внесении данных — и проект стоит. То же самое: три месяца — и есть возможность вернуть неизрасходованную часть и расторгнуть договор. Сначала подписывают соглашение о расторжении, а потом возвращаются деньги.
Когда дошли до первого фейл-момента и становится понятно, что заказчик его руинит (например, не вносит или не корректирует зависящие от него критические данные), но при этом требует продолжения работ, — обязательно подписать акт о том, что он не выполнил этот ключевой момент. Называть его «соглашение об отказе» ни в коем случае нельзя — он ведь не отказывается; он просто говорит, что сделают потом (никогда) или отмалчивается. Назвать его надо, например, «акт о пуско-наладочных работах» или как-то в таком духе — и прямо прописать, что заказчик реально сделал: «внесение/корректировка данных позиций — 3 из 30 000». Это позволяет избежать конфликта, а также даёт тому, кто платит деньги, чёткое понимание, что потом их истребовать обратно будет сильно сложнее — и лучше сразу сливаться.
Соответствующая законодательству схема, но важно не забивать на акты!
С госами не работает — там другая кухня.
ЭДО позволяет быстро обмениваться документами.
Никто ни с кем не разбирается и не «лечит» — все просто: «Вот, подпишите акт». Акт не подписан — проект на паузе, так как акт не подписан. Не оплачено — проект на паузе из-за задержки оплаты. Не оплачено два месяца — уведомляем: в случае просрочки три месяца у нас есть возможность одностороннего расторжения договора. Ничего личного — просто автоматическое уведомление (оно само, как и расторжение: мы просто автоматически расторгаем для поддержания порядка в документах).
Когда вы и разрабатываете, и ведёте переговоры, и потом взыскиваете дебиторку — всё это очень экономит время (наде��сь вам поможет).
В конце напомню, что мы делаем платформу для проектов учёта всякого нестандартного на производствах и не только — и у неё даже есть небольшой фримиум для пет-проектиков.
Посмотреть можно здесь: https://ru.totum.online
