Как мне описать процесс изучения чужого кода? (В ситуации выставления счетов.) [Закрыто]

Редактировать: Джастин Кейв подчеркнул, что такого рода коммуникации должны быть в моих цитатах / оценках. В этом случае мне все еще интересно узнать, на каком языке люди описывают действия по «изучению существующего кода». Особенно для компании, которая раньше не занималась программными подрядчиками. Конец редактирования

У меня есть контракт на обновление собственного программного обеспечения для большой компании. Компания запросила несколько дополнений и исправлений ошибок. Это моя первая внештатная работа.

Во-первых, мне нужно было познакомиться с тем, как работает приложение, - я узнал его так, как если бы я был пользователем.

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

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

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

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

Я бы выставил счета на такие задачи, как «Просмотр существующей функциональности» и / или «Просмотр существующего кода». В зависимости от сложности новых функций я бы добавил задачу «Design xxx», которая включала бы время, затрачиваемое на выяснение точек интеграции в существующий код.

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

Диагностика проблем.

Это знакомый термин, если вы когда-нибудь почините свое авто или обратитесь к врачу, диагноз - это общий термин для определения того, что не так. Это также точно, вы должны пойти под капот и посмотреть, как все связано, чтобы выяснить, что не работает. Это действительно похоже на работу над двигателем без руководства, и компания пошла и сделала двигатель, не глядя на другой двигатель раньше (так что он, вероятно, уникален).

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

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

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

Будучи фрилансером, я бы назвал это «ассимиляцией знаний» в общем смысле. И это было бы включено в любую оценку, первоначально предоставленную клиенту.

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

Даже если нет разницы между чтением и чтением при документировании, ваш клиент, вероятно, будет иметь небольшое психологическое предпочтение для этих более «активных» задач. И вы можете узнать больше, документировав чужой код, чем просто прочитав его. (Это, безусловно, будет иметь место, если вы будете писать тесты против их кода).

Если вы сделаете это, у вас может появиться позиция в счете-фактуре с надписью «Ассимиляция знаний и тестирование / документация устаревшего кода».

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

Исправление ошибки: анализ первопричины.

Новая функция: анализ, дизайн, интеграция и тестирование.

Представляем новые ошибки: безопасность работы. :)

С клиентом, который любит понимать, как все работает и слушает меня мечтательными глазами, я бы пошел прямо Codebase Familiarization. Я бы уже объяснил ему, в какую струю боли он меня вкладывает, и в чем преимущество - приходить ко мне для дальнейших апгрейдов.

С другим типом клиента ... (тот же подход, но он , очевидно, не слушает ни одного слова, которое я говорю ), я бы сказал что-то вроде:

• Planning Phase

• Intervention Planning

  (Я бы использовал этот, на самом деле, но я бы написал это по-итальянски, где он звучит лучше)

• Тогда, может быть ... Solution Planning

Мне нравится Diagnosisчасть Problem Diagnosisпредложения anon, но Problemмне это не кажется правильным. Это может быть открыто для мягкой, предвзятой, невежественной и поверхностной критики ... которая может оставить плохой вкус позади.

Вы знаете, все хотят бросить дротик в внешнего консультанта, и они делают. (... как будто он не был достаточно хорош, чтобы понять корень проблемы во время разговора с ними, и должен был выставить счет за свою невежество, или бог знает что)

Мой слесарь присылает мне счет "Замените масло, свечи плюс, проверьте фильтры, обороты шин. Исправьте погремушки двигателя, дорожные испытания .....

Части (постатейные),

Труд x @ $ y / hour = z)

Он не сломает труд, как и вы. Билл на общее количество часов, и опишите, что вы сделали.