Как заставить внештатные клиенты понять затраты на разработку и поддержание сформировавшихся продуктов?
У меня есть внештатный проект веб-приложения, где клиент запрашивает новые возможности каждые две недели или около этого. Я не могу ожидать требования предстоящих функций. Таким образом, когда клиент запрашивает новую возможность, одна из нескольких вещей может произойти:
Я реализую опцию легко, потому что это совместимо с существующей платформой
Я реализую опцию с трудностью, потому что я должен переписать значительную часть основы платформы
Клиент забирает запрос, потому что он стоит слишком много для реализации против существующей платформы
В начале проекта, в течение приблизительно шести месяцев, все запросы новых функций подпали под категорию 1), потому что система была маленькой и гибкой. Но в течение прошлых шести месяцев, большая часть реализации функции подпала под категорию 2). Система является сформировавшейся, вынуждая меня осуществить рефакторинг, и протестировать каждый раз я хочу добавить новые модули. Кроме того, я повреждаю вещи, которые используют для работы и фиксации ее (я не становлюсь оплаченным это).
Клиент начинает выражать разочарование в то время и стоить для меня для реализования новых опций. Им многие запросы новых функций имеют тот же масштаб как функции, которые они запросили шесть месяцев назад. Например, клиент спросил бы, "Если бы Вам потребовалась 1 неделя для создания системы покупки билетов в прошлом году, почему Вам требуется 1 месяц для создания системы регистрации события сегодня? Система регистрации события намного более проста, чем система покупки билетов. Вам должна только потребоваться 1 неделя!" Из-за этого сценария я боюсь, что запросы новых функций скоро приземлятся в категории 3). На самом деле я уже ем много стоимости сам, потому что я добровольно предлагаю много часов для поддержки проекта.
Клиент часто потрясается, когда я определяю ему честно время, что это берет, чтобы сделать что-то. Клиент всегда сравнивает мои оценки с ранними месяцами проекта. Я не думаю, что они подготовлены к тому, чего это действительно стоит, чтобы разработать, поддержать и поддерживать сформировавшееся веб-приложение.
При работе над зарплатой для полностью занятой компании менеджеры были более восприимчивыми из моих оценок и даже поощрили меня заполнять свои числа для подготовки к неожиданному. Существует ли способ тренировать мои клиенты для размышления того же пути?
Кто-либо может дать совет о том, как я могу продолжить работать над этим веб-проектом, не съедая слишком много стоимости сам?
Дополнительная информация - я только был полным рабочим днем фриланса в течение 1 года. У меня еще нет клиентов высокого класса, но я медленно добираюсь там. Я - качественные клиенты улучшения с течением времени.
4 ответа
Мне кажется, что у вас есть технический долг в вашей архитектуре; он хрупкий по отношению к изменениям. Кроме того, непонятно, вовремя ли вы проводите тестирование. Лучшее время для написания ваших тестов - это до того, как вы напишете свой код, позволяя вашим тестам функционировать как исполняемая спецификация для вашего кода.
Надежная архитектура должна способствовать изменениям, поощряя разделение между классами. Это должно ограничить распространение изменений по мере добавления новых функций. Звучит так, как будто у вас больше связей, чем необходимо, но это почти невозможно сказать, не глядя на код. Я просто следую вашему описанию симптомов.
Если это так, возможно, стоит потратить некоторое время на улучшение базовой архитектуры. Скажите клиенту заранее, что базовая система больше не соответствует его требованиям и что вам нужно потратить некоторое время, чтобы будущие изменения можно было вносить быстрее и дешевле. Возможно, что частично это ваша вина - если да, то тоже будьте честны. Я не думаю, что неразумно ожидать, что клиент откроет вкладку для изменений в архитектуре, необходимых для поддержки их новых функций. Однако, если это частично является результатом неопытности, вы можете съесть часть затрат самостоятельно и списать это на учебный опыт. Вы можете сделать это в любом случае, если в противном случае вы можете потерять клиента.
Кто-нибудь может дать совет, как я могу продолжить работу над этим веб-проектом , не съедая слишком много денег я?
Прозрачность и общение - ваши лучшие инструменты. Если ваши клиенты не могут понять, почему то, что раньше занимало неделю, теперь занимает три недели, вам нужно лучше объяснить. В зависимости от области знаний клиента вы можете найти подходящую для него метафору - например, попытаться построить Prius на раме Model T или попытаться написать «Войну и мир» на пишущей машинке без гласных. Не стесняйтесь своих честных оценок и не подвергайтесь издевательствам. И поделитесь со своим клиентом всем, что он может вынести, о вашем процессе и препятствиях, с которыми вы сталкиваетесь - вы даже можете обнаружить, что у них есть несколько достойных предложений.
Что касается проблемы технического долга - и я согласен, что это основная проблема - TDD уведет вас далеко, как и частый рефакторинг, который позволяет широкое тестовое покрытие. Подумайте о том, какой дизайн позволил бы легко внести все ваши изменения, и работайте над этим дизайном, постепенно, с помощью тестов и рефакторинга. Возможно, вам придется съесть затраты на это, потому что все функции уже оплачены. Но, забегая вперед, включайте в свои оценки затраты на рефакторинг - и не думайте об этом как о дополнении. Заполнение (возможно) нечестно; поддержание дизайна вашего кода с учетом будущих изменений - честное требование вашей работы.
Сам недавно занимался фрилансом (в другой сфере), и я встроил в контракт две вещи; а) Если какие-либо существенные (на мой взгляд) дополнения / изменения должны были быть внесены в структуру, каждое считалось отдельным проектом с отдельными требованиями к доставке и расходами, б) что я предоставил соответствующий уровень документации, чтобы, если они не были довольны моей «оценкой», они могли бы попробовать кого-нибудь другого.
Один клиент однажды попробовал вариант b; они вернулись довольно быстро.