Size: a a a

Архитектура ИТ-решений

2019 August 08

RM

Rustem Mannanov in Архитектура ИТ-решений
Denis Zarin
Александр, не в порядке поспорить — согласен, взвешенную табличку удобно проводить через комитеты.

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

Для этого паттерна есть даже название, “жонглирование коэффициентами”. Кто работал с тендерными критериями — будет скептически относиться к результату.

Но на комитетах хорошо идет ))
Соглашусь.
1.Жонглирование коэффициентами можно прекратить утвердив/согласовав методику («общую для всех» или частную в рамках класса систем). Но это уже скорее «следующий шаг»...
2. Оценки можно выставлять методом Planning Poker. Тоже помогает снизить «коэффициент жонглирования».
источник

RM

Rustem Mannanov in Архитектура ИТ-решений
3. Для варианта с «физическим» смыслом есть универсальная мера - деньги) К ней можно свести почти любые экспертные/статистические оценки.
источник

A

Alx in Архитектура ИТ-решений
Gennadiy Kruglov
Зайдите, например, в любой чат по DevOps. Там слово из 3-х букв звучит намного чаще чем "Спасибо".
не повезло вам с чатами =)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Коллеги, приветствую! Может быть кто-нибудь подскажет методики и/или практики "перевода" прототипа или MVP в зрелый продукт. Материалы по ЖЦ продуктов. А ещё лучше, если поделитесь опытом формализации этого процесса.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Rustem Mannanov
Соглашусь.
1.Жонглирование коэффициентами можно прекратить утвердив/согласовав методику («общую для всех» или частную в рамках класса систем). Но это уже скорее «следующий шаг»...
2. Оценки можно выставлять методом Planning Poker. Тоже помогает снизить «коэффициент жонглирования».
Про Planning Poker — мне кажется, это не совсем прямая аналогия. PP позволяет повысить точность оценки за счет собственно обсуждения вопроса. Но (в оригинале) это не та оценка, которую надо комиттить - это такие лучшие краткосрочные намерения, в которые все одинаково верят.

Про деньги тоже сложно. Есть кейсы, где сравниваем цифры в столбик (стоимость хостинга в простых случаях). Все остальные случаи мэппинга на деньги тоже содержат огромный пласт экспертных оценок.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Вдогонку — есть изумительная, относительно древняя книга того-самого-Макконнелла: Software Estimation: Demystifying the black art. Там про все.

У него центральный тезис, что есть три уровня оценивания — Count (явно пересчитать руками), Calculate (вычислить на основе других известных), Judge (экспертные оценки).
И много интересных примеров о том, как достоверность оценки идет в разнос при переключении на следующий в этом списке метод.
источник

RM

Rustem Mannanov in Архитектура ИТ-решений
Denis Zarin
Про Planning Poker — мне кажется, это не совсем прямая аналогия. PP позволяет повысить точность оценки за счет собственно обсуждения вопроса. Но (в оригинале) это не та оценка, которую надо комиттить - это такие лучшие краткосрочные намерения, в которые все одинаково верят.

Про деньги тоже сложно. Есть кейсы, где сравниваем цифры в столбик (стоимость хостинга в простых случаях). Все остальные случаи мэппинга на деньги тоже содержат огромный пласт экспертных оценок.
1. Про PP, да соглашусь. Не более чем понижает риск, но не устраняет его конечно же). Коммитить или нет = всегда вопрос баланса риска и выгоды. Тут каждый сам себе выбирает нужный баланс)
2. Да, тоже согласен. Проблема в том что стоимость «точного математического подсчета» всех составляющих, как правило, на порядок превышает риск, а иногда и стоимость проекта/системы. В отдельных позициях оценки (где риск самый большой) можно перейти к моделям/статистике или иным «более точным» методам, снизив влияние риска. Делать/хотеть делать это «везде» - не видел пока ни у кого.

Про управление рисками в жц систем/проектов - отдельная адская боль...
источник

RM

Rustem Mannanov in Архитектура ИТ-решений
Denis Zarin
Вдогонку — есть изумительная, относительно древняя книга того-самого-Макконнелла: Software Estimation: Demystifying the black art. Там про все.

У него центральный тезис, что есть три уровня оценивания — Count (явно пересчитать руками), Calculate (вычислить на основе других известных), Judge (экспертные оценки).
И много интересных примеров о том, как достоверность оценки идет в разнос при переключении на следующий в этом списке метод.
Спасибо за материал, обязательно прочитаю.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Rustem Mannanov
1. Про PP, да соглашусь. Не более чем понижает риск, но не устраняет его конечно же). Коммитить или нет = всегда вопрос баланса риска и выгоды. Тут каждый сам себе выбирает нужный баланс)
2. Да, тоже согласен. Проблема в том что стоимость «точного математического подсчета» всех составляющих, как правило, на порядок превышает риск, а иногда и стоимость проекта/системы. В отдельных позициях оценки (где риск самый большой) можно перейти к моделям/статистике или иным «более точным» методам, снизив влияние риска. Делать/хотеть делать это «везде» - не видел пока ни у кого.

Про управление рисками в жц систем/проектов - отдельная адская боль...
Особенности формата (Телеграм) — приходится общаться кусками мыслей )).

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

Проблема, на мой взгляд, — когда оценкам с квази-математикой начинают слишком доверять; принимая их за предсказание. И здесь мы возвращаемся к табличкам с баллами и весами )).
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Denis , Rustem Спасибо! Мне нечего добавить.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Gennadiy Kruglov
Коллеги, приветствую! Может быть кто-нибудь подскажет методики и/или практики "перевода" прототипа или MVP в зрелый продукт. Материалы по ЖЦ продуктов. А ещё лучше, если поделитесь опытом формализации этого процесса.
Геннадий!

Disclaimer: ответ не знаю, тема интересует.

Что понимаем под зрелым продуктом?
Могу ошибаться, но MVP во всех соответствующих подходах понимается не как недоделанный продукт — а как нормальное первое приближение. А дальше начинается эволюционирование / непрерывное улучшение.

Про ЖЦ продуктов знаю 2 разных области / школы:
— Маркетологи/стратеги. Здесь будет с упором на долю рынка, динамику маржинальности, etc. Хороший пример (приближенный к хайтеку) — это Crossing the Chasm Джеффри Мура и центральная модель оттуда.
— Хайтек стартапы вокруг продуктов. Здесь Lean Startup и все что после / до / вокруг него.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Denis Zarin
Геннадий!

Disclaimer: ответ не знаю, тема интересует.

Что понимаем под зрелым продуктом?
Могу ошибаться, но MVP во всех соответствующих подходах понимается не как недоделанный продукт — а как нормальное первое приближение. А дальше начинается эволюционирование / непрерывное улучшение.

Про ЖЦ продуктов знаю 2 разных области / школы:
— Маркетологи/стратеги. Здесь будет с упором на долю рынка, динамику маржинальности, etc. Хороший пример (приближенный к хайтеку) — это Crossing the Chasm Джеффри Мура и центральная модель оттуда.
— Хайтек стартапы вокруг продуктов. Здесь Lean Startup и все что после / до / вокруг него.
Денис, спасибо! Попробую чуть позже точнее сформировать вопрос. Сам вспомнил почему-то только про Мура и Lean Startup:)
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Gennadiy Kruglov
Денис, спасибо! Попробую чуть позже точнее сформировать вопрос. Сам вспомнил почему-то только про Мура и Lean Startup:)
Что накопаете -- поделитесь, пожалуйста, очень интересно!
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Denis Zarin
Что накопаете -- поделитесь, пожалуйста, очень интересно!
Да, обязательно. Может и у Вас будут идеи.
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Коллеги, а раз уж вы заговорили о стартапах, мне интересно, как вы относитесь к  идее продажи до того как начата разработка? Это распространненное мнение в некоторых кругах, но в Lean Startup я этого не увидел, там написанор про "Start small, Think Big" (про MVP выше уже сказали, что это все таки продукт, пусть ограниченный), т.е это не одно и то же, что "Sell first, code later". По моему мнению это и не этично, и в 2019 году по-моему мало таких покупателей вообще можно найти.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
отношусь плохо, это вредит рынку. Реальные инвесторы начинают относится к ИТ как сборищу жуликов.
источник

S

Sergey in Архитектура ИТ-решений
до начала разработки продать можно лишь разработчиков
источник

S

Sergey in Архитектура ИТ-решений
вначале продукт, потом продавать.  Деньги на разработку  - кредит пусть берут
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
имеет право на жизнь "продать идею" чтобы получить финансирование на разработку, но не "продать несуществующую компанию"
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Alexander Teterkin
Коллеги, а раз уж вы заговорили о стартапах, мне интересно, как вы относитесь к  идее продажи до того как начата разработка? Это распространненное мнение в некоторых кругах, но в Lean Startup я этого не увидел, там написанор про "Start small, Think Big" (про MVP выше уже сказали, что это все таки продукт, пусть ограниченный), т.е это не одно и то же, что "Sell first, code later". По моему мнению это и не этично, и в 2019 году по-моему мало таких покупателей вообще можно найти.
к идее продажи чего? компании или будущего продукта?
источник