Здравствуйте

У нас проект... Он был долгое время Times materials (оплачивали просто часы в отчете), теперь его перевели на fixed prise (оплачивают сделанные работы)

есть менеджер
есть человек, сотрудник нашей комппании, который принимает работы. Он как бы приближен к руководству.
Причем он (возможно в связи с кризисом, возможно просто потому что подозревает что мы неэффективно работали), очень неохотно принимает работы, даже если они уже давно сделаны и приняты реальным заказчиком (!)
есть еще сотрудники — разработчики, тестировщики
я как бы архитектор: анализирую трудозатраты, раздаю задачи программистам, сам их делаю

Мы с менеджером умеем убеждать "приемщика" что надо платить за анализ требований, разработку, документирование, тестирование

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



Прошу мысли по теме и "стандартные фразы" для "промывания мозгов" о том, что нужно платить за исправление багов
либо убеждение в том, что за баги платить не нужно. В общем как правильно делается?

Здравствуйте, saprxm, Вы писали:

S>я не могу вспомнить из программы в универе как надо поступать с багами. Его аргументация сильна: вы накосячили сами, поэтому исправляйте баги за свой счет (недополучение премий)

гхм, странная аргументация. вижу в ней позицию слабого человека не на своём месте.

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

имхо не так важно, откуда баги. важно, что они будут, о чём известно для любого проекта заранее. главное, адекватно оценить

S>Прошу мысли по теме и "стандартные фразы" для "промывания мозгов" о том, что нужно платить за исправление багов

unit-testing, багфиксинг, приёмка (интеграция), интеграционный багфиксинг и поддержка (maintenance) — суть такие же этапы жизненного цикла ПО, и также могут быть оценены и оплачены вне зависимости от формы time&material или fixed price.

в случае с fixed price unit-testing и внутренный багфиксинг следует заносить с максимально возможной верхней оценкой в цену разработки. тогда, всё, что ненакосячите будет вашей прямой прибылью.
оценку этапов интеграции надо обосновывать отдельно, причём чем раньше её начать обосновывать, тем больше рисков удастся нарисовать, чтобы удлинить сроки и цену

Здравствуйте, saprxm, Вы писали:

S>Прошу мысли по теме и "стандартные фразы" для "промывания мозгов" о том, что нужно платить за исправление багов
S>либо убеждение в том, что за баги платить не нужно. В общем как правильно делается?

Баги бывают разные — одно дело когда при нажатии на кнопку "Сохранить" весь клиент падает, с другой
когда в тз написано что 2*2 = 4, а вы сделали 2*2=7
с третьей в тз написано всю цену умножаем на 10, вы и сделали на 10, а надо было на 5.

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

а вот 3-й баг Вы выявить не могли никак, значит создается запрос на изменение и начинается его реализация за бабло клиента.

PS все при условии, что есть вменяемое ТЗ, подписанное клиентом

Здравствуйте, saprxm, Вы писали:

S>Прошу мысли по теме и "стандартные фразы" для "промывания мозгов" о том, что нужно платить за исправление багов

Попробую дать идею (на практике применить не пришлось).

Доказываем, что программирование "без багов" более затратно. Примеры берем, например, отсюда: http://www.sei.cmu.edu/news-at-sei/columns/watts_new/2004/3/watts-new-2004-3.htm . То есть вы можете свести количество багов к минимуму (если это является целью), но тогда придется значительно вложиться в тестирование, причем многие из тестируемых вариантов могут быть так никогда и не использованы.

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

Только про всякие метрики лучше не упоминать, а то чего доброго начнут подсчитывать, кто сколько произвёл кода.

S>Причем он (возможно в связи с кризисом, возможно просто потому что подозревает что мы неэффективно работали), очень неохотно принимает работы, даже если они уже давно сделаны и приняты реальным заказчиком (!)

Этот момент вообще непонятен. Как такое возможно и на что влияет? Не лучше ли, чтобы в кризис программист занимался делом, а не правил уже сданную работу?

Здравствуйте, saprxm, Вы писали:

S>а вот с исправлением ошибок труднее.
S>я не могу вспомнить из программы в универе как надо поступать с багами. Его аргументация сильна: вы накосячили сами, поэтому исправляйте баги за свой счет (недополучение премий)

в том что прошло тестирование и приемку, багов нет по определению Это фичи которые требуют отдельной работы по документированию, обнаружению и изменению.

Здравствуйте, saprxm, Вы писали:

S>Здравствуйте

S>Прошу мысли по теме и "стандартные фразы" для "промывания мозгов" о том, что нужно платить за исправление багов
S>либо убеждение в том, что за баги платить не нужно. В общем как правильно делается?

Одно из двух: либо отношения с приемщиками-проверяльщиками строятся как с внешним заказчикам, либо нет.

Если это "свои" люди — то тебя должно волновать как бы в сроки и в бюджет уложиться, а твою команду — только то, как уложиться в сроки. Тебе и команде платят вне зависимости от того, какую работу ты в данный момент делаешь — баги правишь или доки составляешь.
Если они ведут себя как внешний заказчик — то значит, все и вся ты должен продавать своему руководству. В стоимость продукта изначально закладывать стоимость поддержки во время некого гарантийного срока (в течении которого ты как бы обязан править баги за свой счет). А после этого (четко оговоренного!) гарантийного срока продай руководству поддержку проукта. Не покупают? Докажи, что твой мега-пупер сложный продукт надо поставлять с поддержкой, обоснуй это с финансовой позиции. Все равно не покупают? Ну, значит, остануться со своими багами, а ты тем временем потренируешься продавать им еще что-нибудь.

Здравствуйте, jhfrek, Вы писали:

J>Здравствуйте, saprxm, Вы писали:

S>>а вот с исправлением ошибок труднее.
S>>я не могу вспомнить из программы в универе как надо поступать с багами. Его аргументация сильна: вы накосячили сами, поэтому исправляйте баги за свой счет (недополучение премий)

J>в том что прошло тестирование и приемку, багов нет по определению Это фичи которые требуют отдельной работы по документированию, обнаружению и изменению.

спорить не буду, но он пишет сами кодим — сами тестируем, что же теперь заказчику команду тестирования нанимать за ними все проверять?

из жизни:
Машину из сервиса после замены масло забираешь ездеешь полдня потом бац — масло потекло. Что сделаешь — правильно приедешь и заставишь их еще раз все сделать. Хотя машину забирал все чистенько было красиво

Здравствуйте, saprxm, Вы писали:

S>У нас проект... Он был долгое время Times materials (оплачивали просто часы в отчете), теперь его перевели на fixed prise (оплачивают сделанные работы)

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

а вообще — он чушь несёт. если уж так считать, то программисты должны получать все деньги от заказчика и сами гарантироватькачество работ. а менеджеров сократить за ненужностью

Здравствуйте, barlock, Вы писали:

J>>в том что прошло тестирование и приемку, багов нет по определению Это фичи которые требуют отдельной работы по документированию, обнаружению и изменению.
B>спорить не буду, но он пишет сами кодим — сами тестируем, что же теперь заказчику команду тестирования нанимать за ними все проверять?

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

B>Машину из сервиса после замены масло забираешь ездеешь полдня потом бац — масло потекло. Что сделаешь — правильно приедешь и заставишь их еще раз все сделать. Хотя машину забирал все чистенько было красиво

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

Здравствуйте, saprxm, Вы писали:

S>я не могу вспомнить из программы в универе как надо поступать с багами. Его аргументация сильна: вы накосячили сами, поэтому исправляйте баги за свой счет (недополучение премий)

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

Hi jhfrek

J>>>в том что прошло тестирование и приемку, багов нет по определению Это фичи которые требуют отдельной работы по документированию, обнаружению и изменению.
B>>спорить не буду, но он пишет сами кодим — сами тестируем, что же теперь заказчику команду тестирования нанимать за ними все проверять?

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

Так проблема же не в том, что заказчик не принимает. В первом письме было

даже если они уже давно сделаны и приняты реальным заказчиком (!)

Там просто свой человек пальцы кидает.