Roman
16.08.2016
09:13:27
Форма договора обычно отражает ожидания.
До тех пор пока заказчики не поймут, что разработчики это всего лишь "руки" для решения их проблем, а "голова" и ответственность за решения должна быть на заказчике бесполезно обсуждать формат договора.
Мой опыт — крупный энтерпрайз. Заказчики там в основном такие.
Google
Roman
16.08.2016
09:22:13
Если с пониманием у бизнеса все ОК, то задача подрядчика просто доказать свою техническую компетенцию (например, предъвить портфолио и резюме специалистов) и предложить удобный комфортный способ поставки результата и уточнения требований.
Timothy
16.08.2016
09:22:28
Бизнес видит в маркетинговых слоганах agile "серебряную пулю", зачастую слишком полагаясь на магию со стороны подрядчика
Roman
16.08.2016
09:22:40
Ага
Карго-культ :)
Timothy
16.08.2016
09:23:04
Это какая-то общая беда
Roman
16.08.2016
09:23:16
Типа мы будем делать ритуалы по agile, пинать разработчиков (как обычно), а они за это мобилизуются и все быстро сделат.
Это приводит тупо к большему количеству работы в рамках того же бюджета денег.
Такое тоже видел :)
Timothy
16.08.2016
09:24:26
Даже при смене работы ловил себя на том, что говорю те же самые слова, но уже другим людям и в других компаниях
Потому что "маркетинг" продан и сверху людей убедили
Roman
16.08.2016
09:27:33
Если сводить все к просым идеям, то "простое" решение этой проблемы — просто всего лишь внедрить agile в управление бизнесом. ХЗ как это сделать :) МБ Герману Оскаровичу с его евангелистами удастся это в Сбере, а мы посмотрим :)
Timothy
16.08.2016
09:28:38
Мастерклассы пусть потом запустят
Roman
16.08.2016
09:30:23
Пока в качестве удачных примеров внедрения agile я видел только ситуации, когда конкретные представители бизнес-заказчика крайне замотивированы на результат.
Google
Roman
16.08.2016
09:31:53
Но так же могу сказать, что в такой ситуации работает либой гибкий подход, даже без задумывания о том что это Agile/SCRUM/Kanban и тп — если разработчикам поставить интересную задачу (хотя бы очевидно полезную для бизнеса) и дать свободу, то они свернут горы. Технари они такие :)
Если мотивация конкретных людей (не путать со спонсором проекта) не завязана на результат, то бесполезно что-то оптимизировать.
Timothy
16.08.2016
09:33:10
Ага, бонус топам в качестве мотивировки хорошо работает, проверяли
Roman
16.08.2016
09:33:39
Или так :) Бонус топам, стимул (палка с заостренным концом) миддл-уровню.
Но лучше конечно бонусы всем :)
Timothy
16.08.2016
09:35:02
Наш кейс был как раз про острые палки
Зато решения не затягивались, что приятно
Roman
16.08.2016
09:39:48
К сожалению острые палки работают только для относительно простой работы. Например, для внедрения крупной ERP-системы, когда пордячиквнедряет ее уже 10-й раз, а от заказчика требуется лишь изложить требования в нужном формате и не сильно настаивать на кастомизации.
Andrey Levin
16.08.2016
09:40:24
В общем так и не услышал я ответа, как заключать контракты без предварительой работы аналитиков и ТЗ долгого. В заказной разработке есть вид сделки time and material , работашь на почасовке и все. Но даже там оказываются кейсы, когда заказчик говорит «да это же на 40 часов работы было, а вы все 120 возились, я отказываюсь платить» Хотя на старте все проговорено было, что мы не платим за аналитику и прочее, экономим тут и начинаем работать
Roman
16.08.2016
09:40:25
В остальном острые палки мешают.
Андрей, а что вы хотите услышать?
Как убедить заказчика взять на себя ответственность за бизнес-результат?
По мне (см мой монолог выше) дело не в формате договора, а в ответственности. Если заказчик готов взять ответственность на себя за бизнес, то формат договора приложится.
Timothy
16.08.2016
09:42:28
Предварительную аналитику тяжело зачарджить заказчику
Andrey Levin
16.08.2016
09:44:04
Да вот заказчик говорит «да, идет, ответственность на мне» но как вы и заметили, как только денег начинает касаться , сразу гм :)
Roman
16.08.2016
09:44:17
Значит, он лукавит :)
Возможно, он лукавит вынужденно — у него есть фиксированный бюджет и таймер отрубания головы (собственной головы конкретного представителя заказчика) если задача не будет решена к такому-то сроку. Обычно в сроке делается запас, но все равно страшно. Да? :)
Alex
16.08.2016
09:45:51
это дело уже в простых договоренностях и доверии между командой и заказчиком. Раз-два попавшись на том, что задачи, оцененные в 40 часов, выполняются в 3 раза дольше, доверие только на убыль пойдет, тут уже не важно, по каким схемам вы работаете
Andrey Levin
16.08.2016
09:46:08
Может есть где-то математическая модель, которая показывает , например 2 кривых - стоимость проекта во времени, одна для водопада, другая аджайл. Где можно двигать ползунок (число неожиданных изменений требований) и кривые меняются
Roman
16.08.2016
09:46:09
Алексей, тут как раз вам поможет Agile :) SCRUM вообще рулит — много некрупных интераций, в ходе которых растет оыт и естественно повышается точность оценки.
Google
Andrey Levin
16.08.2016
09:47:11
для time and material оценок нет, поэтому аппеляция про 40 часов это лишь внутреннее ожидание заказчика ничем не подтвердженное
Roman
16.08.2016
09:47:34
Нельзя без оценок, это хаос.
Но оценки нужно уточнять.
Timothy
16.08.2016
09:49:33
Есть такая штука у Макконнелла в Construx
Roman
16.08.2016
09:49:38
Andrey Levin
16.08.2016
09:49:45
Бог с ним, пример не самый подходящий скорее. Про мат модель интересно. Задал на входе количество людей в проекте, их ставки. Построил идеальную модель по водопаду и по скраму. Потом начал увеличивать количество изменений в проекте. Цель наглядно показать усредненную выгоду от процесса по аджайл
Timothy
16.08.2016
09:50:12
Software Development's Defect Cost Increase
Roman
16.08.2016
09:50:30
Иван
16.08.2016
09:51:22
Timothy
16.08.2016
09:51:41
У него ещё своя патентованная прога есть, только с ней повозитесь
Roman
16.08.2016
09:51:57
Иван, я специально не указывал формат договора :) Я чисто про ответственность писал.
Ответственность и мотивация — главное.
А чтобы эффективно риски поделить для начала нужно этим делением заняться :)
Иван
16.08.2016
09:52:43
рискшаринг модели тоже есть
Andry
16.08.2016
09:53:03
К примеру?
Roman
16.08.2016
09:53:08
Если нет ответственности и мотивации, но есть желание спихнуть риски на другую сторону, то это проблема.
Dmitry
16.08.2016
09:53:16
Roman
16.08.2016
09:53:20
Иван
16.08.2016
09:53:35
говорят скоро СкрамТрек запустит тренинг по agile-контрактам и вообще отношениям, когда есть заказчик и подрядчик. там будут и примеры и системно все ;)
Roman
16.08.2016
09:53:43
Google
Roman
16.08.2016
09:54:39
Но какие-то оценки есть всегда — оценка это цена ресурсам которую планируется заплатить за фичу — это обратная связь от разработчика заказчику.
Оценки должны быть чтобы заказчик был мотивирован формулировать наиболее дешевые фичи, более качественно прорабатывать требования. И лучше расставлять приоритеты. Не все же во власти разработчиков. Мб бизнесу стоит провести какие-то свои исследования — для него будет повод подумать над уточнением требований, если он сразу услышит что цена высока.
Dmitry
16.08.2016
09:58:32
Я не спорю
Я не из заказной разработки, у нас с этим проще)
Roman
16.08.2016
10:00:20
Глянул презентацию — работа "без оценок" как цель, идеал — супер.
Но не как карго-культ :)
Чтобы "без оценок" заработало разработчики должны быть в теме бизнеса, иметь адекватный опыт (хз какой конкретно, но адекватный ?) и разработка с тестированием и деплоем на прод должна быть максимально автоматизирована.
Marina
16.08.2016
10:02:06
Dmitry
16.08.2016
10:02:22
Roman
16.08.2016
10:04:01
Marina
16.08.2016
10:04:49
@RuslanKuzminov юнит-экономика считается планированием бюджета? :)
Ruslan
16.08.2016
10:05:19
Научим! =)
Roman
16.08.2016
10:05:27
Marina
16.08.2016
10:07:50
@roman_kolchin если очень абстрактно - расчет бюджета исходя из издержек на единицу продукции, чтобы не уйти в убыток
Roman
16.08.2016
10:08:01
Ruslan
16.08.2016
10:08:37
Unit-экономика это расчет доходов и расходов на одного клиента
Marina
16.08.2016
10:08:46
@roman_kolchin у меня куча аджайл-проектов в заказной разработке, я просто все проекты делаю в аджайл парадигме :)))
и в общем-то заказчика никто не спрашивал, все равно отчитываться раз в неделю
Ruslan
16.08.2016
10:09:22
Если простыми словами то инструмент оперативной оценки доходности бизнеса =)
Roman
16.08.2016
10:10:30
Google
Roman
16.08.2016
10:12:19
Или вся соль в том, чтобы не пропускать проекты без по-клиентного обоснования?
Marina
16.08.2016
10:13:38
@roman_kolchin второй вариант, вот сейчас французский стартап с нуля делаем
Roman
16.08.2016
10:14:49
Марина, моя ирония в том, что у вас клиент готов на такую организацию работы, считает ее приемлемой для себя. По мне тут дело в мотивации клиента на результат и адекватном разделением ответственности.
Если разобраться с мотивацией и ответственностью, то гибко работать очень классно, даже не задумваясь о том как назвать такой подход.
Весь вопрос - КАК мотивировать и поделить ответственность.
Ruslan
16.08.2016
10:18:30
UNIT-экономика - это инструмент для работы на открытом рынке. Тут вся соль в том, что на одном листе вы видите все ключевые метрики бизнеса + можете моделировать влияние метрик на результат (например, стоит задача кратно поднять прибыль => через unit-экономику ищем точки для роста => принимаем решение на что влиять в первую, вторую, итд очередь). Кучу инфраструктурных и бэкофисных инвест-проектов (если требуется) можно засунуть в фиксированные расходы (капексы показать через амортизацию)
Marina
16.08.2016
10:18:30
@roman_kolchin нужно быть избирательным и брать только нормальных клиентов :)
Roman
16.08.2016
10:19:01
"Кучу инфраструктурных и бэкофисных инвест-проектов (если требуется) можно засунуть в фиксированные расходы (капексы показать через амортизацию)"
Не совсем понял что вы имеете в виду?
Инвест проект генерит два потока — расходы и доходы, обычно с лагом.
Для клиенто-ориентированных проектов доходы более мнее понятны.
Для инфраструктурных и бэкофисных — нет.
Амортизация влияет лишь на налогооблагаемую базу.
Marina
16.08.2016
10:20:21
прямой доход? или улучшение работы компании?
Roman
16.08.2016
10:20:32
А как оценить полезность бэкофисного проекта с точки зреня unit-экономики?
Marina
16.08.2016
10:20:35
можем уйти в отдельный чат если интересно :)
Roman
16.08.2016
10:21:27
Интересно, но пока это чисто любопытство :) Сам я не на стороне клиента работаю и буду работать, в бюджетный процесс не вовлечен поэтому.
Если можете предложить конкретные материалы для изучения или мероприятия, то буду благодарен.