Про фикс тайм энд баджет и флекс скоуп
Сука, кто придумает название этому подходу нормальное?..
Тут Александр Дейков в советах спрашивает:
Интересно послушать мнение Коли, после десяти месяцев в Бюро. Каково это, скажем, после «Научных приборов»?
А я отвечаю:
Александр, я как раз удачно попал на время, когда бюро переходило от одного подхода к другому и могу сравнивать.
Когда я только пришел ( Read more... )
Тут Александр Дейков в советах спрашивает:
Интересно послушать мнение Коли, после десяти месяцев в Бюро. Каково это, скажем, после «Научных приборов»?
А я отвечаю:
Александр, я как раз удачно попал на время, когда бюро переходило от одного подхода к другому и могу сравнивать.
Когда я только пришел ( Read more... )
Дальнейшие мои действия были бы:
1) узнать ваш эстимейт (в часах/деньгах) на допиливание ИЕ. Если речь идёт о каком-то % от общей стоимости проекта, то разумеется нет смысла здесь ломать копья и я согласен перенести это на следующий этап работ и оплатить отдельно.
2) перед началом следующего этапа пересмотреть наш договор и прописать в него то, что называется acceptance criterias - перечень условий, которые должны быть выполнены с вашей стороны, прежде чем я подпишу акт и сполна рассчитаюсь с Бюро. То есть по сути это значит, отойти от вашего принципа фиксировать только время и деньги.
Если Бюро на это не пойдёт, то тут будет зависеть уже от наших с вами отношений - то есть, как часто и насколько много вы ошибаетесь с оценкой скоупа. Если скажем мы уже прошли 3 этапа и каждый раз к зафиксированному времени/деньгам работа оказывается выполнена только на 80% и Бюро просит сокращать скоуп - значит, нужно фиксировать объем работ, либо разбегаться. Если же изменение скоупа случилось только 1 раз и по такой мелочи, как этот пример с ИЕ, где дел вероятно на 5% от всех работ - то конечно нет смысла ссориться, ведь 95% это суперолтличное попадание.
Reply
Захар (давайте уже до конца играть в переговоры :), из нашего опыта мы знаем, что если мы не будем делать функционал гибким, то это почти наверняка приведет к задержки по срокам и мы вас подведём.
Мне очень хочется доделать наш проект и чтобы он получился хорошим, поэтому я предлагаю продолжить работы по прежнему методу.
Reply
Дело в том, что я не могу отличить, происходит ли это из-за недостатка опыта у ваших сотрудников, либо из-за недостатка опыта заказа подобных вещей у меня. Я признаю, что разработка веб-инфосистемы - для меня дело относительно новое, возможно, я не умею объяснить то, чего я хочу и что для меня важно. Но тут я доверяю вашей команде - вы можете расспрашивать меня столько, сколько вам нужно, чтобы определить трудозатраты. Разумеется, я готов сполна оплатить затраченное вами время на анализ моих требований.
Однако, если в следующий раз вновь возникнет такая же ситуация, когда что-то важное (а ведь мы включаем в план работ только важное! несущественные вещи остаются за бортом изначально) окажется несделанным и его доделывание кроме отставания во времени будет означать для меня ещё и дополнительное удорожание проекта на очередные пусть даже 5%... я всерьёз буду сомневаться в компетентности ваших специалистов.
Посмотрите, Николай: выходит, что я старадаю дважды! Сначала из-за смещения сроков, потом из-за доп.расходов. Я не могу работать в ситуации, когда последствия нашего общего риска (один непонятно объяснял, другой мало спрашивал) ложатся только на меня одного. Поэтому я предлагаю разделить их, внеся изменения в договор. Я признаю, что поторопился, подписав его в нынешнем виде, который позволяет вам менять скоуп. Я согласен продолжить работать по нему, если вы заверите меня (изменениями в договоре), что каждый этап будет выполняться не менее чем на 90% (т.е. остающиеся невыполненными работы не будут превышать в сумме 10% от оговоренной стоимости этапа).
Reply
*Кстати, за обсуждение такого письменно, Артём бы меня через скайп прямо мечём хуйнул.
Захар! Мне очень жаль, что нам не удалось объяснить смысл подхода с гибким функционалом и наше предложение убрать ИЕ стало для вас непрятным сюрпризом (вообще это говно, потому что если это сюрприз, значи тот, кто заключал договор зафакапил и не объяснил что значит гибкий функционал. Ладно, пусть типа зафакапил он и это првда сюрприз).
Мне бы не хотелось, чтобы вы принимали решение, о котором будете сожалеть (типа вы выбрали перекинуть ИЕ на другую итерацию, которая будет хер знает когда, так ведь?), поэтому я предлагаю еще раз обсудить это и подумать какие у нас еще есть варианты.
К сожалению, я не могу обещать вам, что мы сможем выполнить 90% от запланированного. Я не знаю с какими сложностями мы столкнёмся на следующем этапе и не могу гарантировать какой-либо процент, который мы точно выполним. Если бы я мог делать такие оценки, я, как мне кажется, смог бы обещать вам все 100% и точно в срок.
Чтобы сделать изменения в функционале более контролируемыми, я предлагаю разбить следующий этап на более мелкие итерации, но всё равно исползовать подход с фиксированным временем, бюджетом и гибким функционалом.
Чтобы не огорчать вас в будущем, я бы хотел еще раз объяснить суть подхода:
Мы предлагаем не сдвигать дедлайн. При таком методе работы мы бы хотели, чтобы мы вместе свами отвечали за согласование макетов. Этот подход, предусматривает, что при возникновении проблем, предпочтение отдается отказу от функциональности ради соблюдения сроков и высокого качества.
Когда продукт будет готов и вы соможете его проверить на практике, мы сможем лучше понять как следующей итерации добавить новые фичи, от которых нам пришлось отказаться.
Reply
А вот ваше предложение работать более короткими этапами мне подходит - давайте попробуем. Но мне бы не хотелось снова вести длинные переговоры, если в следующий раз мы окажемся в такой же ситуации. Что Бюро может предложить мне, чтобы разделить риски?
Reply
Reply
(The comment has been removed)
http://ksoftware.livejournal.com/174994.html
Reply
Leave a comment