Roman
Я чаще всего сталкивался, что де-факто заказчик ожидает решение проблемы, а не разработку/внедрение системы. И заказчик отказывается считать ОБЯЗАТЕЛЬСТВА подрядчика выполненными пока проблема не будет решена. А дальше кто кого — чьи обязательства в договоре более жестко зафиксированы, тот и теряет/тратит деньги.
Roman
И дело тут не в форме договора, а в ожиданиях заказчика — хочет за гарантированно фиксированный бюджет решить проблему, не зная заранее решения. Вернее не решить проблему, а заставить это сделать подрядчика.
Roman
Форма договора обычно отражает ожидания.
Roman
До тех пор пока заказчики не поймут, что разработчики это всего лишь "руки" для решения их проблем, а "голова" и ответственность за решения должна быть на заказчике бесполезно обсуждать формат договора.
Roman
Мой опыт — крупный энтерпрайз. Заказчики там в основном такие.
Roman
Все так, однако, бизнес-риски заставляют заказчика менять требования (с пониманием здесь все ОК, просто за некое время требования эволюционировали), а это начинает влиять на разработчиков. Не всегда хорошо...
Если с пониманием все ОК (у бизнеса с пониманием эволюционности требований действительно все ОК, да??? 😀), то не вижу проблем с объяснением преимуществ Agile. Реально вагон аргументов ЗА. Включая контракты с полуоткрытым скопупом. По опыту "все ОК с пониманием" только на словах но не на уровне финансовых обязательств.
Roman
Если с пониманием у бизнеса все ОК, то задача подрядчика просто доказать свою техническую компетенцию (например, предъвить портфолио и резюме специалистов) и предложить удобный комфортный способ поставки результата и уточнения требований.
☝️😉👍
Бизнес видит в маркетинговых слоганах agile "серебряную пулю", зачастую слишком полагаясь на магию со стороны подрядчика
Roman
Ага
Roman
Карго-культ :)
☝️😉👍
Это какая-то общая беда
Roman
Типа мы будем делать ритуалы по agile, пинать разработчиков (как обычно), а они за это мобилизуются и все быстро сделат.
Roman
Это приводит тупо к большему количеству работы в рамках того же бюджета денег.
Roman
Такое тоже видел :)
☝️😉👍
Даже при смене работы ловил себя на том, что говорю те же самые слова, но уже другим людям и в других компаниях
☝️😉👍
Потому что "маркетинг" продан и сверху людей убедили
Roman
Если сводить все к просым идеям, то "простое" решение этой проблемы — просто всего лишь внедрить agile в управление бизнесом. ХЗ как это сделать :) МБ Герману Оскаровичу с его евангелистами удастся это в Сбере, а мы посмотрим :)
☝️😉👍
Мастерклассы пусть потом запустят
Roman
Пока в качестве удачных примеров внедрения agile я видел только ситуации, когда конкретные представители бизнес-заказчика крайне замотивированы на результат.
Roman
Но так же могу сказать, что в такой ситуации работает либой гибкий подход, даже без задумывания о том что это Agile/SCRUM/Kanban и тп — если разработчикам поставить интересную задачу (хотя бы очевидно полезную для бизнеса) и дать свободу, то они свернут горы. Технари они такие :)
Roman
Если мотивация конкретных людей (не путать со спонсором проекта) не завязана на результат, то бесполезно что-то оптимизировать.
☝️😉👍
Ага, бонус топам в качестве мотивировки хорошо работает, проверяли
Roman
Или так :) Бонус топам, стимул (палка с заостренным концом) миддл-уровню.
Roman
Но лучше конечно бонусы всем :)
☝️😉👍
Наш кейс был как раз про острые палки
☝️😉👍
Зато решения не затягивались, что приятно
Roman
К сожалению острые палки работают только для относительно простой работы. Например, для внедрения крупной ERP-системы, когда пордячиквнедряет ее уже 10-й раз, а от заказчика требуется лишь изложить требования в нужном формате и не сильно настаивать на кастомизации.
Andrey
В общем так и не услышал я ответа, как заключать контракты без предварительой работы аналитиков и ТЗ долгого. В заказной разработке есть вид сделки time and material , работашь на почасовке и все. Но даже там оказываются кейсы, когда заказчик говорит «да это же на 40 часов работы было, а вы все 120 возились, я отказываюсь платить» Хотя на старте все проговорено было, что мы не платим за аналитику и прочее, экономим тут и начинаем работать
Roman
В остальном острые палки мешают.
Roman
Андрей, а что вы хотите услышать?
Roman
Как убедить заказчика взять на себя ответственность за бизнес-результат?
Roman
По мне (см мой монолог выше) дело не в формате договора, а в ответственности. Если заказчик готов взять ответственность на себя за бизнес, то формат договора приложится.
☝️😉👍
Предварительную аналитику тяжело зачарджить заказчику
Andrey
Да вот заказчик говорит «да, идет, ответственность на мне» но как вы и заметили, как только денег начинает касаться , сразу гм :)
Roman
Значит, он лукавит :)
Roman
Возможно, он лукавит вынужденно — у него есть фиксированный бюджет и таймер отрубания головы (собственной головы конкретного представителя заказчика) если задача не будет решена к такому-то сроку. Обычно в сроке делается запас, но все равно страшно. Да? :)
Alex
это дело уже в простых договоренностях и доверии между командой и заказчиком. Раз-два попавшись на том, что задачи, оцененные в 40 часов, выполняются в 3 раза дольше, доверие только на убыль пойдет, тут уже не важно, по каким схемам вы работаете
Andrey
Может есть где-то математическая модель, которая показывает , например 2 кривых - стоимость проекта во времени, одна для водопада, другая аджайл. Где можно двигать ползунок (число неожиданных изменений требований) и кривые меняются
Roman
Алексей, тут как раз вам поможет Agile :) SCRUM вообще рулит — много некрупных интераций, в ходе которых растет оыт и естественно повышается точность оценки.
Andrey
для time and material оценок нет, поэтому аппеляция про 40 часов это лишь внутреннее ожидание заказчика ничем не подтвердженное
Roman
Нельзя без оценок, это хаос.
Roman
Но оценки нужно уточнять.
☝️😉👍
Есть такая штука у Макконнелла в Construx
Roman
Может есть где-то математическая модель, которая показывает , например 2 кривых - стоимость проекта во времени, одна для водопада, другая аджайл. Где можно двигать ползунок (число неожиданных изменений требований) и кривые меняются
Если взять один и тот же объем фнкциональных требований — грубо говоря утвержденное ТЗ, то цена разработки Водопадом будет ниже чем Agile :)
Andrey
Бог с ним, пример не самый подходящий скорее. Про мат модель интересно. Задал на входе количество людей в проекте, их ставки. Построил идеальную модель по водопаду и по скраму. Потом начал увеличивать количество изменений в проекте. Цель наглядно показать усредненную выгоду от процесса по аджайл
☝️😉👍
Software Development's Defect Cost Increase
Иван
Про "скоуп и очкование" - тут либо заказчик бизнес-риски берет на себя или хочет переложить их на подрядчика. Если бизнес-риски на заказчике (продукт не выстрелит, не закроет проблему), то от подрядчика нужно как можно лучше понять функциональные требования и как можно качественнее реализовать продукт. Agile в разработке помогает лучше понять и качественее делать продукт. Но ничего не делает с бизнес-рисками.
а вот и не все так однозначно. контрактование не заключается в двух вариантах: фикс прайс и TnM.
☝️😉👍
У него ещё своя патентованная прога есть, только с ней повозитесь
Roman
Иван, я специально не указывал формат договора :) Я чисто про ответственность писал.
Roman
Ответственность и мотивация — главное.
Roman
А чтобы эффективно риски поделить для начала нужно этим делением заняться :)
Иван
рискшаринг модели тоже есть
Andry
К примеру?
Roman
Если нет ответственности и мотивации, но есть желание спихнуть риски на другую сторону, то это проблема.
Dmitry
Нельзя без оценок, это хаос.
Некоторые с вами поспорят)
http://www.slideshare.net/Askhat/no-estimate
Иван
говорят скоро СкрамТрек запустит тренинг по agile-контрактам и вообще отношениям, когда есть заказчик и подрядчик. там будут и примеры и системно все ;)
Roman
Но какие-то оценки есть всегда — оценка это цена ресурсам которую планируется заплатить за фичу — это обратная связь от разработчика заказчику.
Roman
Оценки должны быть чтобы заказчик был мотивирован формулировать наиболее дешевые фичи, более качественно прорабатывать требования. И лучше расставлять приоритеты. Не все же во власти разработчиков. Мб бизнесу стоит провести какие-то свои исследования — для него будет повод подумать над уточнением требований, если он сразу услышит что цена высока.
Dmitry
Я не спорю
Я не из заказной разработки, у нас с этим проще)
Roman
Глянул презентацию — работа "без оценок" как цель, идеал — супер.
Roman
Но не как карго-культ :)
Roman
Чтобы "без оценок" заработало разработчики должны быть в теме бизнеса, иметь адекватный опыт (хз какой конкретно, но адекватный 😀) и разработка с тестированием и деплоем на прод должна быть максимально автоматизирована.
Anonymous
Если сводить все к просым идеям, то "простое" решение этой проблемы — просто всего лишь внедрить agile в управление бизнесом. ХЗ как это сделать :) МБ Герману Оскаровичу с его евангелистами удастся это в Сбере, а мы посмотрим :)
не так уж и сложно, мы этому учим - Agile Product Management + Agile Marketing и владелец бизнеса может спокойно заниматься стратегией :)
Dmitry
Roman
не так уж и сложно, мы этому учим - Agile Product Management + Agile Marketing и владелец бизнеса может спокойно заниматься стратегией :)
Это очень круто. А планировать бюджет по Agile учите? Без отрубания голов в случае неудач :)
Anonymous
@RuslanKuzminov юнит-экономика считается планированием бюджета? :)
Ruslan Kuzminov
Научим! =)
Roman
@RuslanKuzminov юнит-экономика считается планированием бюджета? :)
А что это такое? Название слышал, но знаю сути.
Anonymous
@roman_kolchin если очень абстрактно - расчет бюджета исходя из издержек на единицу продукции, чтобы не уйти в убыток
Roman
говорят скоро СкрамТрек запустит тренинг по agile-контрактам и вообще отношениям, когда есть заказчик и подрядчик. там будут и примеры и системно все ;)
Очень интересно. А но основании чьего реального опыта? Российского? Просто я когда-то был на тренинге по agile и изложил там свои проблемные кейсы, то мне после серии предложений и моих -контр-аргументов предложили не работать с такими заказчиками :)
Ruslan Kuzminov
Unit-экономика это расчет доходов и расходов на одного клиента
Anonymous
@roman_kolchin у меня куча аджайл-проектов в заказной разработке, я просто все проекты делаю в аджайл парадигме :)))
Anonymous
и в общем-то заказчика никто не спрашивал, все равно отчитываться раз в неделю
Ruslan Kuzminov
Если простыми словами то инструмент оперативной оценки доходности бизнеса =)
Roman
и в общем-то заказчика никто не спрашивал, все равно отчитываться раз в неделю
У Вас аджайл — это итерационная разаботка? Или контракты с открытым скоупом?
Roman
Если простыми словами то инструмент оперативной оценки доходности бизнеса =)
Спасибо. А как быть с кучей инфраструктурных и бэкофисных инвест-проектов, которые напрямую не аллоцируются на конкретных клиентов. Особенно если проекты с долгосрочной окупаемостью.
Roman
Или вся соль в том, чтобы не пропускать проекты без по-клиентного обоснования?