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

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

Я легко реализую эту функцию потому что он совместим с существующая платформа
Я реализую функцию с трудности, потому что я должен переписать значительная часть фундамент платформы
Клиент отменяет запрос, потому что он слишком много стоит для существующая платформа

В начале проекта в течение примерно шести месяцев все запросы функций попадали под категорию 1), потому что система была небольшой и гибкой. Но за последние шесть месяцев большинство функций реализовано под категорию 2). Система зрелая, вынуждая меня реорганизовать и тестировать каждый раз, когда я хочу добавить новые модули. Кроме того, я обнаружил, что нарушаю то, что используется для работы, и исправляю его (мне не платят за это).

Клиент начинает выражать разочарование в то время и для меня, чтобы реализовать новые функции. Для них многие запросы функций имеют тот же масштаб, что и те функции, которые они запрашивали шесть месяцев назад. Например, клиент спросил бы: "Если в прошлом году вам понадобилось 1 неделю для создания системы продажи билетов, почему вам понадобится 1 месяц для создания системы регистрации событий? Система регистрации событий намного проще, чем система билетов. Это займет всего 1 неделю! Из-за этого сценария, я опасаюсь, что запросы функций скоро приземлятся в категории 3). На самом деле, я уже много трачу на себя, потому что я добровольно много часов поддерживаю проект.

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

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

Может ли кто-нибудь предложить советы о том, как я могу продолжать работать над этим веб-проектом, не тратя слишком много на себя?

Дополнительная информация. Я занимаюсь только фрилансом в течение 1 года. У меня пока нет клиентов высокого уровня, но я медленно туда добираюсь. Я получаю более качественные клиенты с течением времени.

Ответ 1

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

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

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

Ответ 2

Недавно я занимался фрилансированием (разное поле), и я включил в контракт две вещи; a) Если какие-либо крупные (на мой взгляд) дополнения или изменения должны были быть внесены в структуру, каждый из них учитывался как отдельный проект с отдельными требованиями к поставке и стоимостью, b) что я бы предоставил подходящий уровень документации, чтобы, если они не были довольны моей "оценкой", они могли попробовать кого-то другого.

У меня был один вариант попытки клиента b один раз; они вернулись довольно быстро.

Ответ 3

Посмотрите эти два статьи.

Ответ 4

Кто-нибудь может посоветовать, как я могу продолжить работу над этим веб-проектом без слишком большой стоимости сам?

Прозрачность и коммуникация - ваши лучшие инструменты. Если ваши клиенты не могут понять, почему то, что когда-то занимало неделю, занимает три недели, вы должны уметь лучше объяснять. В зависимости от клиентской области знаний вы сможете найти метафору, которая резонирует с ними, - пытаясь построить Prius на модели T, скажем, или пытаться написать "Война и мир" с пишущей машиной без гласных. Не стесняйтесь своих честных оценок и не будешь издеваться. И делитесь с вашим клиентом столько, сколько они могут нести о вашем процессе и препятствиях, с которыми вы сталкиваетесь - вы даже можете обнаружить, что у них есть достойные предложения.

Что касается вопроса о технической задолженности - и я согласен с тем, что это основная проблема - TDD унесет вас далеко, как и частое рефакторинг, разрешающий широкий охват тестирования. Подумайте, какой дизайн позволил бы все ваши изменения легко - и поработать над этим дизайном, поэтапно, с помощью тестов и рефакторинга. Может быть, вам придется есть затраты на это, потому что все функции уже оплачены. Но, с нетерпением ожидая, включите затраты на рефакторинг в ваших оценках - и не думайте об этом как дополнение. Простуда (возможно) нечестна; поддержание дизайна вашего кода для будущих изменений является честным требованием вашей работы.