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

Question

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

1. Я легко реализую эту функцию, поскольку она совместима с существующей платформой

2. Клиент отзывает запрос, поскольку его реализация на существующей платформе обходится слишком дорого

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Взгляните на эти две статьи.

Answer 4

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

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

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