@roman_kolchin второй вариант, вот сейчас французский стартап с нуля делаем

@roman_kolchin второй вариант, вот сейчас французский стартап с нуля делаем

Стартап с нуля.... 😀

Марина, моя ирония в том, что у вас клиент готов на такую организацию работы, считает ее приемлемой для себя. По мне тут дело в мотивации клиента на результат и адекватном разделением ответственности.

Если разобраться с мотивацией и ответственностью, то гибко работать очень классно, даже не задумваясь о том как назвать такой подход.

Весь вопрос - КАК мотивировать и поделить ответственность.

UNIT-экономика - это инструмент для работы на открытом рынке. Тут вся соль в том, что на одном листе вы видите все ключевые метрики бизнеса + можете моделировать влияние метрик на результат (например, стоит задача кратно поднять прибыль => через unit-экономику ищем точки для роста => принимаем решение на что влиять в первую, вторую, итд очередь). Кучу инфраструктурных и бэкофисных инвест-проектов (если требуется) можно засунуть в фиксированные расходы (капексы показать через амортизацию)

@roman_kolchin нужно быть избирательным и брать только нормальных клиентов :)

"Кучу инфраструктурных и бэкофисных инвест-проектов (если требуется) можно засунуть в фиксированные расходы (капексы показать через амортизацию)"

Не совсем понял что вы имеете в виду?

Инвест проект генерит два потока — расходы и доходы, обычно с лагом.

Для клиенто-ориентированных проектов доходы более мнее понятны.

Для инфраструктурных и бэкофисных — нет.

Амортизация влияет лишь на налогооблагаемую базу.

прямой доход? или улучшение работы компании?

А как оценить полезность бэкофисного проекта с точки зреня unit-экономики?

можем уйти в отдельный чат если интересно :)

Интересно, но пока это чисто любопытство :) Сам я не на стороне клиента работаю и буду работать, в бюджетный процесс не вовлечен поэтому.

Если можете предложить конкретные материалы для изучения или мероприятия, то буду благодарен.

Сорри. Я тут на совещании. Выпадаю иногда

На самом деле все довольно просто

Если мы говорим, что мы инвестируем в инфраструктуру - типа покупки некого апк для дальнейшего оказания услуг, то в рамках P&L пойдет в статье амортизации (как основное средство)

Unit экономика считается в рамках месяца

И Инвест расходы можем показать через амортизацию в фикс кострах

Костах

Но суть не в этом

Если об оперативном контроле речь, то понятно тогда. Согласен с математикой.

Да да именно так

Но оно же не решает задачу об инвестировании денег в принципе.

С точки зрения планирования, стандартных P&L и cf никто не отменял

Она решает задачу оценить насколько бизнес может быть прибыльный с точки зрения потока клиентов, которые генерят доход x, которых привлечение нас стоит y

Нам стоит

Понятно :)

А я пытаюсь (умозрительно) связать защиту бюджета на проект -> выделение бюджета -> реализацию проекта -> получение (подтвержденного) результата.

Где-то тут должна появиться мотивация заказчика разрабатывать/внедрять системы по Agile :)

Пока в эту цепочку agile плохо вписывается для большинства крупных компаний

В таком контексте согласен

Потому что мотивация КОНКРЕТНЫХ предствителей заказчика теряется в процессе от защиты денег до оценки результата. Потому что на этих этапах участвуют РАЗНЫЕ предствители заказчика :)

а мы легко продаем Time&Material модель, сколько потратите столько потратите, а если сделаем быстрее возьмем меньше

оценки бюджетов на проекты по сути круги на воде как ни крути

а мы легко продаем Time&Material модель, сколько потратите столько потратите, а если сделаем быстрее возьмем меньше

Я как раз это обдумываю. Но риски...

Когда появляется фигура заказчика (читай - заказная разработка) - да

и вот там как раз продает факт аджайла - раз в неделю результат

Если мы говорим про продуктовую работу на открытом рынке, то тут иначе

@roman_kolchin вы заказчик?

Нет, подрядчик.

риски заказчик несет сам, а в современном мире возможность внести изменения в проект без допсоглашения к контракту заказчику обычно приятна

риски заказчик несет сам, а в современном мире возможность внести изменения в проект без допсоглашения к контракту заказчику обычно приятна

Я на это тоже иду. Но обычно со знакомыми клиентами. С новым клиентом - никогда.

но мы все равно приблизительно оцениваем проект

в смыслек идешь? мы вот в фикспрайсах не идем, а в т&M делайте что хотите хоть каждый день меняйте концепт

а так ченджи за доплату

Опробованный подход — фиксированный бюджет, фиксированные требования, НО итерационная разработка с принятием отдельных изменений в рамках бюджета.

Со знакомыми клиентами все всех устраивает.

ну а что тогда мешает сделать там аджайл?

Клиенты крупные, формат договора утвержден для всех одинаковый, под меня менять лень :)

Но если все всех устраивает, то можно работать.

Дело в мотивации и доверии. А договор вторичен.

Я был бы рад работать по T&M, но клиенты не готовы, так как они хотят максимально обезопасить себя, с учетом процедуры выделения бюджета и оценки результата. Формат договора утвержден и жетско контролируется юристами и (иногда) даже специально выделенными закупщиками. Просто так не поменяешь. Да и, если удается завоевать доверие, на договор через какое-то время начинаем смотреть снисходительно с обоих сторон.

Но еще раз (для тех, кого интересует именно вопрос контрактования и кто прочитал только мое последнее сообщение 😀) — договора это следствие внутренней культуры, внутренних процедур, того как в компании принято делить ответственность и отвечать за результат финансовых затрат. Менять надо не формат договора, а культуру инвестирования.

Всем привет) я Куа тимлид. Узнала о чате из группы Куа) посмотрим чем могу быть поленой)

Всем привет!

привет!

Кто нибудь пробовал внедрять «тяжелые» системы типа ERP или POS или CRM по Agile

?

Кто нибудь пробовал внедрять «тяжелые» системы типа ERP или POS или CRM по Agile

Посмотрите методологию SAP Activate

У Оракла agile-подход используется в Oracle Unified Method (OUM), который пришел на смену старому каскадному Application Implementation Method (AIM). Но даже в OUM больше RUP, чем современный Agile.

Внедрять ERP пробовали (отдельные модули Oracle) — через итерационную разработку в цикле: демо стандартного функционала -> выявление разрывов с реальностью/сбор требований -> демо доработанного функционала -> ... новые требования, подключение новых модулей.....

Ораковый OUM: http://www.oracle.com/partners/ru/products/applications/oracle-unified-method/get-started/index.html, там же скачать можно

#whois Всем привет, QA Lead и Scrum Master на одном из старт апов в Сан Франциско, интересно узнать о Agile best practices, как научить команду делать более точные эстимейты;

Мария, а скорость команды замеряете?

Я делал так. Планирование и оценка-планнинг покер. Потом ежедневная метрика скорости команды. У нас итерация была в месяц. Через 3-4 итерации мы знали-какой объем мы можем пропустить через итерацию с учетом скорости разработки.

Вы не можете работать по Agile с не-Agile заказчиком

😅

Мария, а что вы конкретно эстимейтите в часах? И зачем вам нужен скрам для работы с этим заказчиком?

Лёш я правильно понимаю, что ты консультируешь компанию в санфране? ;)

Почему консультирую, просто пытаюсь выяснить как они работают

Пусть так. Мне тоже интересен ответ на этот вопрос.

Мария, а почему скрам?

потому что он тут был до меня :)

Или вы предлагаете прийти в компанию и сказать, все что вы тут делаете это №%ня и я настаиваю на новых процессах, скинуть фаундерам ссылку на презентацию, почему скрам это не серебряная пуля 😊? fun fun)

Думаю, что окажусь капитаном. На моих проектах в разных командах более точные оценки помогало получить: возможность оценивать глядя в код, возможность в любой момент задать вопрос продакт овнеру и оперативно получить ответ, знание скорости команды, ревью кода, описание историй и критериев приемки, командная оценка или валидация оценок, знание фокус фактора команды, знание сколько действительно часов будет у каждого члена команды в эту итерацию, борьба с точками непредсказуемости как в коде, так и в процессах. Но мы никогда не гнались за выполнением оценок программистами, а приглядывали за объемом работ в итерацию.