я полагаю, что многие из аутсорсеров сталкивались с понятием warranty, иначе говоря, гарантийного периода после сдачи итерации или релиза, когда все найденные баги компания чинит бесплатно. вопрос заключается в том, как наиболее правильно регламентировать обязательства между заказчиком и подрядчиком, чтобы этот период был наименее убыточным?
в идеальном мире ответом на этот вопрос конечно же было идеальное качество кода и не менее идеальное качество самого тестирования, которое просто не позволяет багам появится в продакшине. в идеальном мире acceptance testing на стороне заказчика происходит быстро и последовательно и приоритеты багов расставляются в зависимости от их значимости для проекта. к сожалению мы не живем в идеальном мире. и наши программисты не всегда пишут качественный код, а наши тестеры не всегда находят все баги, acceptance testing затягивается на месяц, а если оговорить отдельно починку за это время только багов с приоритетом Critical, то все баги станут критическими, даже текст подвинуть на экране из правого угла в левый.
таким образов в нашем не идеальном мире warranty-период очень часто является периодом, когда команда бесплатно работает на заказчика. это не приятно, но если таковы правила игры, то ничего ужасного в этом нет. разумеется если речь идет о большой конторе, в которой есть иные источники дохода, кроме одного проекта. как этом случае выживают мелкие предприятия я не представляю.
цель поста вобщем-то проста, если кто-то знает как разрешаются коллизии связанные с warranty в его или смежной конторе, как минимизируются затраты на этот период, каким образом повышается в этот период доходность команды я с удовольствием полушаю. иначе говоря, а у вас как?
пособов масса, все зависит от степени легальности и от того, что считать коллизиями :)
ВідповістиВидалитиНаиболее нелегальный - "откат" за приемо-сдаточные испытания или свое лобби в коллективе заказчиков, дабы ПСИ прошли успешно (да, не удивляйтесь, 90% госзаказов сдаются именно так). Но не подумайте - не призываю так делать, просто для обзора указал :)
Теперь легальные. В нашей компании некритические (объективно) баги отдавались на откуп джуниорам и т.д. (хотя у нас джуниор - это 1-2 года опыта).
Еще один способ - на этапе падения активности разработки проекта (средняя и/или заключительная фаза кодирования)подключать/задействовать аутсорсеров с целью передать сопровождение им.
Лекарства нет – только профилактика.
ВідповістиВидалити1. В контракте оговаривается, какие баги будут исправляться в рамках гарантии, а какие не будут. Как минимум это уменьшает число багов, которые заказчик может выставить как критичные.
2. Бесплатной гарантии не бывает. В проекте закладывается бюджет на гарантийный период как минимум на валидацию багов и коммуникацию. На стороне подрядчика баг надо, во-первых, провалидировать на соответствие требованиям (чтобы отбросить «хотелки» Заказичка), во-вторых, повторить (чтобы бесплатно не решать проблемы вызванные неверной конфигурацией и т.п. – в общем не баги).
Часто бывает так, что накапливается значительное число багов, которые не попадают в гарантию, но заказчик хочет их фиксать за отдельный бюджет. Вот тут можно (только осторожно) попытаться покрыть часть оверхедов.
Ну и, как это банально не звучит, надо стремиться добиваться идеального качества кода и отсутствия багов.
2katkovonline.com, существует. и означает именно то, что написано в заголовке поста. Вас беспокоит уровень моего английского? Вы хотите об этом поговорить?
ВідповістиВидалити2meowth, ну мы не на столько круты, чтобы позволить себе покупать машины или дома западным менеджерам. заказчик у нас не на столько крут, чтобы не мочь контролировать процесс лично, а проект не на столько крут, чтобы телодвижения по откатам имели смысл.
на счет джуниров -- принимается, команду можно усилить.
аутсорсеров мы не прокормим. сами, извиняюсь, жрать нечего. тем более, что сами мы аутсорсеры.
2vadim, может и warranty. Вы тоже хотите поговорить об уровне моего английского языка?
2Аноним, спасибо. примерно это я и подозревал. потому и поговорил с отделом продаж на тему контрактов.
к идеальному коду стремимся всегда. дойти бы хотя бы до приемлимого уровня.
>>Вас беспокоит уровень моего английского? Вы хотите об этом поговорить?
ВідповістиВидалитиХочу поговорить о вашем хамстве
2Igor, для этого нужно как минимум представиться. теперь по сути вопроса -- пойдите вон, пожалуйста. на этой площадке Ваше мнение не стоит ни цента. нехай щастить.
ВідповістиВидалитиг.Антон Наумов, пожалуй уровень вашего английского или как Igor тут сказал - хамства, меня беспокоит меньше всего.
ВідповістиВидалитиНо я удивлён, да.
2katkovonline.com, Игорь (?) чему Вы удивлины? моему "хамству"? я во-первых, не люблю анонимов, во-вторых, не люблю людей, которые приходят учить меня хорошим манерам ко мне домой. в-третьих, терпеть не могу во-первых + во-вторых.
ВідповістиВидалититеперь что касается английского. да, я плохо говорю по-английски. но это не проблема для людей, которые не говорят по-русски. только для тех, которые говорят. рудимент совковой системы образования, где имели привычку "ставить на вид". хотите меня поправить? поправьте. хотите ерничать -- в другом месте пожалуйста.
и последнее, главное. цель поста была не спровоцировать обсуждение моего уровня владения английским языком. и дать возможность поерничать на мой счет. цель поста была получить совет. я попрежнему рад любому совету по теме. иные, кто придет сюда учить меня жизни, отправятся вослед Igorю. я не стану делать площадку закрытой, но это не означает, что любой может здесь устраивать трибуну для своих заявлений, обвинений или нравоучений.
я надеюсь моя позиция ясна?
p.s. а вообще некий юноша уже записывал меня в трамвайные хамы. переживу, если что.