Про фикс тайм энд баджет и флекс скоуп
Сука, кто придумает название этому подходу нормальное?..
Тут Александр Дейков в советах спрашивает:
Интересно послушать мнение Коли, после десяти месяцев в Бюро. Каково это, скажем, после «Научных приборов»?
А я отвечаю:
Александр, я как раз удачно попал на время, когда бюро переходило от одного подхода к другому и могу сравнивать.
Когда я только пришел ( Read more... )
Тут Александр Дейков в советах спрашивает:
Интересно послушать мнение Коли, после десяти месяцев в Бюро. Каково это, скажем, после «Научных приборов»?
А я отвечаю:
Александр, я как раз удачно попал на время, когда бюро переходило от одного подхода к другому и могу сравнивать.
Когда я только пришел ( Read more... )
2) как происходит изменение скоупа? От кого исходит запрос на изменение скоупа - вероятно, от исполнителя (дизайнера, верстальщика) или от арт-директора, который видит, что исполнители не могут выдать то, что нужно клиенту в срок? Потом всё это передаётся менеджеру, задача которого - согласовать с клиентом и установить новый срок и дополнительный бюджет, так?
3) бывает ли, и если да, то примерно в каком % случаев, расширение скоупа проекта при фиксированных деньгах и времени? Ведь очень большой соблазн, увидев, что задача была решена скажем за 7 дней вместо 10, взять себе 1 отгул, 1 инженерный день и 1 день на рефакторинг. Всё равно о деньгах и сроках уже договорено...
4) как решается вопрос с мотивацией сотрудников, если они всегда знают, что скоуп можно изменить? насколько часто приходится слышать о "творческом кризисе" от дизайнера, "нерешаемых задачах" от программиста, "этом чёртовом ИЕ" от вебтехнолога, которые как бы намекают, что нужно ещё время (естессно, оплачиваемое клиентом).
5) где вы берете таких клиентов, которые согласны просто вот так что-то выкинуть из проекта, оставаясь при этом проигравшими по деньгам (которые фиксированы)? на мой взгляд, такой клиент должен быть очень глупым, если соглашается на уступки в одностороннем порядке. С моей точки зрения, если вы - подрядчик - не успеваете сделать работу за оговоренные деньги в оговоренный срок, то какого рожна только я должен делать уступки вам? ведь в конце-концов, неверная оценка сроков - это ваш факап (при условии конечно, что я не давил и вы не уступли мне, согласясь на заранее невыполнимые сроки, но даже это - тоже был бы ваш факап). Поэтому я хотел бы либо продления сроков с сохранением бюджета, либо сокращения вашего гонорара, т.к. к указанному сроку вы выдали меньший скоуп. Неужели так не бывает?
Reply
2. У нас в бюро нет менеджеров. Подобные решения принимает ведущий дизайнер или арт-дир.
3. Скоуп не увеличивается, он может только уменьшаться. То есть если все сделали, и в срок вложились - это идеал.
А вообще у нас же ресурс, поэтому вопрос не очень понятный. В ресурсе если ты взял задачу, скажем на неделю, то это твоё дело как её делать. Можешь, если умеешь, за день сделать и улететь на море. Тут также это работает, как я понимаю.
4. Пиздюлиной это решается. Ну у нас пиздюлины нужны разве только мне и то всё реже и реже. Просто ребята, которые нихуя делать не хотят в Бюро не держатся. Удаления функций из-за лени дизайнера не случается. Любое удаление должно быть обоснованно и должно быть на пользу проекта. Если дизайнер проленился - это его проблемы, пусть делает в своё личное время.
Кроме того мы понимаем, что для клиента сложно отказываться от количества функций, поэтому не делаем это просто так.
История про ИЕ показательна. Допустим программист не успевает за срок сделать вёрстку для ИЕ. Ведущий дизайнер при этом инициирует собрание с клиентом. И говорит, что так и так, за это время мы ну никак не успеем сделать вёрстку для ИЕ. Дальше решение принимает фактически клиент.
5. Ессно заказчики не отказываются от функций легко.
Так как мы делаем не сайты визитки из готовых шаблонов или как там это бывает, то всегда есть некая определенность. В ТЗ было два макета на раздел сайта, а потом мы что-то придумали и стало три макета на раздел. Всё равно что-то гнётся.
Даже если обещать делать всё и в срок, то потом в итоге будет растягиваться срок. Причем общим недовольством со всех сторон. Флекс скоуп допускает увеличение сроков, но это всё строго оговаривается.
В этом и прелесть - гибкость сразу оговаривается.
Reply
Остался непонятным только один момент: с историей про ИЕ, то есть про конфликты вообще. Давайте рассмотрим её ещё раз:
"Допустим программист не успевает за срок сделать вёрстку для ИЕ. Ведущий дизайнер при этом инициирует собрание с клиентом. И говорит, что так и так, за это время мы ну никак не успеем сделать вёрстку для ИЕ. Дальше решение принимает фактически клиент."
Я как клиент могу принять тут единственное решение: вы сделаете вёрстку для ИЕ за свой счёт, но позже. Я могу быть готов подождать её ещё неделю и тогда запускать сайт, могу запустить сайт без поддержки ИЕ - это уже детали. Но так как мы оговаривали поддержку ИЕ в ТЗ и я за неё заплатил (я ведь заплатил в фиксед прайс, или нет?), то я хочу её получить. При этом я согласен войти в положение и получить её несколько позже запланированного без штрафных санкций к вам.
Таким образом, мы усекаем скоуп, но мне как клиенту поддержка ИЕ не будет стоить дополнительных денег. Я правильно понимаю?
Reply
Ок, допустим я ведущий дизайнер и мне клиент отвечает: «вы сделаете вёрстку для ИЕ за свой счёт, но позже».
Во-первых, я могу согласиться, но это довольно сложно, надо будет уговорить технолога работать бесплатно.
Скорее всего я скажу, что мне очень жаль, что мы подвели вас, но мы договорились работать по фиксированному времени и я не могу увеличить срок проекта. Дальше я, скорее всего, попробую узнать почему поддержка ИЕ так важна и почему нельзя обойтись без неё. Получив инфу я буду пытаться придумать решение, которое устроит всех. Ну, например, я фантазирую, поддержку ИЕ мы делаем только для формы покупки и т. д.
Reply
"Мне очень жаль, что мы подвели вас, но мы договорились работать по фиксированному времени и я не могу увеличить срок проекта. Дальше я, скорее всего, попробую узнать почему поддержка ИЕ так важна и почему нельзя обойтись без неё"
Отвечаю: от того, что вам жаль, мне не горячо, ни холодно. Да, я согласен с вами - мы действительно договаривались работать по фиксированному графику. Но в то же время мы договаривались о том, что создаваемая инфосистема/сайт будет работать во всх браузерах, в т.ч. в ИЕ начиная с 7-й версии. (вы же обычно прописываете нефункциональные требования к системе в ТЗ?) Поддержка ИЕ для нас важна, потому что среди моих клиентов много всяких разных "энтерпрайз" клиентов, у которых ИЕ навязан корпоративной политикой. Пользователи не могут сами выбиать браузер, которым они пользуются, а мы не можем навязывать им какой-то определенный баузер. По статистике с нашего предыдущео сайта у нас было 30% пользователей ИЕ. Мы не знаем, все ли они перейдут на ИЕ9 и как быстро, поэтому нам важна поддержка ИЕ7 и 8.
Мне бы хотелось получить её, пусть и позже, но без дополнительной платы.
Reply
Мне очень хочется, чтобы у нас получился отличный проект, но за указанный срок мы не успеем сделать хорошо всё, что планировали. Раз поддержка ИЕ критична я предлагаю отказаться от реализации раздела А, а освободившееся время оставить технологу на доводку вёрстки по ИЕ.
---
Кстати в договори чётко прописывается, что решения подобного рода должны приниматься в определенное время (например неделя на согласование), причём за принятие решений несет ответственность и сам клиент тоже. То есть я могу (культурно конечно) сказать клиенту, что у нас по договору записано, что вот сейчас мы должны сесть с ним вдвоём и придумать как быть.
Reply
Дальнейшие мои действия были бы:
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
Итерации идут фиксированные - неделя работы сотрудников стоит столько-то, за эту неделю они делают вот это.
Там надо понять саму суть «геттин рил» - лучше сделать половину намеченного, но чтобы все работало хорошо. Очень часто бывает так (у нас почти всегда так, если с запасов время не возьмем), что проект закладывается на месяц, через месяц сдается бета, в которой куча багов, и еще две недели идут на доработку, а эти две недели не оплачиваются, естественно. Люди заняты, их надо перекинуть на новый проект, а они дорабатывают старый, и понятно, что деньги нам не идут. И мы торопимся и вместо качества делаем пункты «todo», количество.
Это получается разбиение большой мутной задачи на более короткие промежутки, чтоб по итогу не быть в попандосе и получить хорошие результаты. Поправь меня, Коля, если я неправ.
Однако есть другая сторона. Пробовал на проект закладывать полтора месяца - то же самое, сдавали бету через полтора месяца и опять две-три недели править ошибки. То есть тут дело не всегда во времени, наверное :-)
Reply
Мы используем Скрам, с переменным успехом :) А вы?
Reply
Leave a comment