Вы путаете accountability и reliability.
Скрам полностью подотчетен, раз в две недели проходит демонстрация и в любой момент можно уточнить как бэклог продукта, так и бэклог команды.
Скрам не может быть надежным по срокам на длинных временных промежутках. И в обмен на ненадежность, владелец получает гибкость. Не каждому владельцу эта гибкость нужна, но, вот если не нужна, у проекта есть более серьезный риск выживаемости, чем риск не закончить проект: риск остаться без клиентов.
Задачи в разработке ведь не просто так появляются. И если за две недели владелец с готовым продуктом ничего не узнал про рынок и про клиента, то чем он тогда занимался?
Если мы по-разному смотрим на вопрос, то мы должны прийти к одинаковым по-сути выводам, но разными словами, а пока что я вижу, что выводы диаметрально противоположные.
Ну, хорошо, допустим, не шизоидного. А какого тогда?
Давайте я уточню пару моментов: во-первых, я ссылаюсь на временной промежуток до начала 2000-х. А во-вторых, я не имею в виду буквально что «все программисты были шизоидами», а что шизоидный радикал в тот период имел преимущество и лидеры того времени организовывали разработку удобным для себя способом.
Также, я абсолютно не имею в виду профессиональную деформацию. Речь идет о способе мышления. Шизоиды принципиально отличаются от обычных людей способом мышления.
Люди и взаимодействие важнее процессов и инструментов
Это очень интересная проблема, которая выходит за рамки, собственно, разработки. Дело в том, что традиционно программирование было (и во много остается) вотчиной людей с особым складом ума, шизоидным. Они всем хороши, но, увы, не понимают социальных сигналов. В сущности, шизоиды идут по жизни, просто приучая себя делать одну и ту же вещь много раз, и это они называют «процессом».
Увы, но большинство людей не являются носителем такого радикала и они просто не выживают в шизоидной среде. Они просто не могут следовать «процессам». То, как простые люди ведут дела — бьют других людей по голове (морально) и они называют это «взаимодействием» и «коммуникацией».
В итоге, возникает конфликт ценностей «процесс»/«коммуникация», который авторы скрама и agile-манифеста решают в пользу «коммуникации». Все остальное — в сущности, просто поддерживающие процедуры.
Работа короткими итерациями
Работа короткими итерациями нужна не для того, чтобы бизнес мог контролировать работу. Он это всю дорогу мог и это вообще не проблема никакая.
Настоящая проблема в том, что бизнес постоянно получает новые данные от рынка и перегружает отдел разработки. Они не понимают за что взяться и в итоге вообще ничего не делают.
Соглашение, которое реализуется с помощью коротких итераций: «мы готовы к переменам, но не так часто».
И вот тут у вас должен прозвенеть звоночек: «если я не перегружаю отдел разработки задачами, зачем мне нужны итерации и вообще аджайл?». И вот тут то как раз и вступает в дело «трезвость руководителя», о которой я писал выше. Руководитель должен осознать неуправляемость и поменять свою стратегию поведения с «контроля исполнения» на «пойду, выясню, как обстоят дела на самом деле». Узнаете много нового. Появится что разрабатывать. И сама идея о том, чтобы разрабатывать что-то по полгода этапами начнет приводить вас в ужас.
Ну, вот смотрите. Вы пишете «Во-первых, необходимо внедрить мысль о том, что гибкость — в самой основе природы.». Вы не можете внедрить мысль.
Дальше, «крайне важно каждое изменение позиционировать как новый вызов и возможность.». Опять же. Позиционирование — это какая-то уловка. Каждое конкретное изменение может быть вызовом или возможностью по факту. Вы не можете изменить оценку изменения, просто сказав другие слова. Нет никакой нужды добавлять про позиционирование. Все, что вы говорите или правда и не нуждается в каких-то уловках, или нет. А у вас я вижу сборник уловок. Сама необходимость уловок говорит о том, что что-то идет не так.
Ну, тогда я не совсем понимаю, для чего нужна ваша статья. Все взрослые люди и так умеют вступать в отношения и поддерживать их. Кого и чему вы хотите научить?
Смотрите. Когда речь идет о взаимодействии между людьми, есть в общем-то всего два варианта: тирания и сделка. Скрам — сделка.
Если вы пытаетесь выдать тиранию за сделку, у вас проблема. Эта проблема больно стукнет и вас и тех, кого вы пытались обмануть.
Все «проблемы» скрама и аджайла — вы просто не сечете фишку.
Все же просто очень. Когда вы отказываетесь от иллюзии того, что вы можете чем-то «управлять», вы встаете перед вопросом «но если управление не возможно, как же мне тогда завершить мой проект?».
Скрам — не какая-та шаманистическая практика (как кое-кто тут уверен), а, наоборот, ответ на вопрос что вы будете делать, когда примете на себя обязательство абсолютной честности по отношению к себе и к окружающим?
У нас разные понимания MVP, продукт для «показать потрогать и получить фидбек» в моём мире называется прототип.
Да. В каком-то смысле, MVP — это прототип для бизнес-идеи.
С ним, прежде всего, бегаешь по потенциальным пользователям/клиентам/спонсорам/инвесторам, проверяешь нужно ли вообще что-то подобное хоть кому-то.
Что-то вы не по тем бегаете. По-идее, если вы сделали MVP и подтвердили ценность, то все инвесторы будут рады вам дать денег — новые работающие идеи большая редкость. А если опровергли, значит расслабьтесь — это не нужно. Начинайте придумывать новую идею.
малые банки готовы платить меньше за более качественное ядро всех своих систем
Сильно сомневаюсь. Смотрите, как это работает. Продукт делается не просто так, а ради того, чтобы проверить какую-то гипотезу. Minimal Viable — это не имеется в виду, что он готов деньги заколачивать, а что его можно кому-то показать потрогать и получить фидбек, достаточный для опровержения этой ключевой гипотезы.
Для того, чтобы показать клиенту и получить фидбек не обязательно соблюдать требования всех регуляторов. В релиз, конечно, с таким не уйти, но цель MVP — не улететь в бой, а проверить ключевую гипотезу.
Ну, понятно. Заняли свое время очередной развлекаловкой. Поэтому, я и говорю, что вам надо больше ответственности брать — вам так всегда и будет скучно.
Нет, конечно. Есть метода, по ней все делается. Смысл в том, что вы вначале находите клиента, а уже для этого клиента делаете. Формулы там будут, конечно, но они очень простые. Там целая пирамида валидации. Вначале вы валидируете идею в разговоре с коллегами, потом выходите на потенциальных клиентов, с ними два вида интервью: проблемное и глубинное, и только потом уже валидация гипотезы масштабирования — идете в сеть или обзваниваете массу людей. В этом деле всякие там корреляции, критерии стьюдента не принципиальны — и так все понятно. Если вам несколько человек говорят одно и то же и готовы платить за решение проблемы, значит ее стоит попробовать решить.
«Он адекватный» == «Он действует исходя из объективных факторов и не додумывает ничего сам» == «Я ему доверяю, потому что он справедлив и рассудит по-существу».
За две недели сделать Minimal Viable Core Bank System (АБС) разве реально?
Не знаю, может и реально. Зависит от много всего.
Просто вы себя заранее в ловушку загоняете терминологией. Может, вашему клиенту этот самый АБС даром не нужен, а ему нужно что-то другое. Проблемы начинаются, когда вы подтвердили ценность АБС, поняли что нужно делать только так и никак иначе и у вас не хватает денег.
Скрам полностью подотчетен, раз в две недели проходит демонстрация и в любой момент можно уточнить как бэклог продукта, так и бэклог команды.
Скрам не может быть надежным по срокам на длинных временных промежутках. И в обмен на ненадежность, владелец получает гибкость. Не каждому владельцу эта гибкость нужна, но, вот если не нужна, у проекта есть более серьезный риск выживаемости, чем риск не закончить проект: риск остаться без клиентов.
Задачи в разработке ведь не просто так появляются. И если за две недели владелец с готовым продуктом ничего не узнал про рынок и про клиента, то чем он тогда занимался?
Потому что реальность одна и мы в ней живем. Если выводы разные, значит кто-то чего-то не понимает. И мне интересно, не я ли это.
Ну, хорошо, допустим, не шизоидного. А какого тогда?
Давайте я уточню пару моментов: во-первых, я ссылаюсь на временной промежуток до начала 2000-х. А во-вторых, я не имею в виду буквально что «все программисты были шизоидами», а что шизоидный радикал в тот период имел преимущество и лидеры того времени организовывали разработку удобным для себя способом.
Также, я абсолютно не имею в виду профессиональную деформацию. Речь идет о способе мышления. Шизоиды принципиально отличаются от обычных людей способом мышления.
Люди и взаимодействие важнее процессов и инструментов
Это очень интересная проблема, которая выходит за рамки, собственно, разработки. Дело в том, что традиционно программирование было (и во много остается) вотчиной людей с особым складом ума, шизоидным. Они всем хороши, но, увы, не понимают социальных сигналов. В сущности, шизоиды идут по жизни, просто приучая себя делать одну и ту же вещь много раз, и это они называют «процессом».
Увы, но большинство людей не являются носителем такого радикала и они просто не выживают в шизоидной среде. Они просто не могут следовать «процессам». То, как простые люди ведут дела — бьют других людей по голове (морально) и они называют это «взаимодействием» и «коммуникацией».
В итоге, возникает конфликт ценностей «процесс»/«коммуникация», который авторы скрама и agile-манифеста решают в пользу «коммуникации». Все остальное — в сущности, просто поддерживающие процедуры.
Работа короткими итерациями
Работа короткими итерациями нужна не для того, чтобы бизнес мог контролировать работу. Он это всю дорогу мог и это вообще не проблема никакая.
Настоящая проблема в том, что бизнес постоянно получает новые данные от рынка и перегружает отдел разработки. Они не понимают за что взяться и в итоге вообще ничего не делают.
Соглашение, которое реализуется с помощью коротких итераций: «мы готовы к переменам, но не так часто».
И вот тут у вас должен прозвенеть звоночек: «если я не перегружаю отдел разработки задачами, зачем мне нужны итерации и вообще аджайл?». И вот тут то как раз и вступает в дело «трезвость руководителя», о которой я писал выше. Руководитель должен осознать неуправляемость и поменять свою стратегию поведения с «контроля исполнения» на «пойду, выясню, как обстоят дела на самом деле». Узнаете много нового. Появится что разрабатывать. И сама идея о том, чтобы разрабатывать что-то по полгода этапами начнет приводить вас в ужас.
Дальше, «крайне важно каждое изменение позиционировать как новый вызов и возможность.». Опять же. Позиционирование — это какая-то уловка. Каждое конкретное изменение может быть вызовом или возможностью по факту. Вы не можете изменить оценку изменения, просто сказав другие слова. Нет никакой нужды добавлять про позиционирование. Все, что вы говорите или правда и не нуждается в каких-то уловках, или нет. А у вас я вижу сборник уловок. Сама необходимость уловок говорит о том, что что-то идет не так.
Если вы пытаетесь выдать тиранию за сделку, у вас проблема. Эта проблема больно стукнет и вас и тех, кого вы пытались обмануть.
Все же просто очень. Когда вы отказываетесь от иллюзии того, что вы можете чем-то «управлять», вы встаете перед вопросом «но если управление не возможно, как же мне тогда завершить мой проект?».
Скрам — не какая-та шаманистическая практика (как кое-кто тут уверен), а, наоборот, ответ на вопрос что вы будете делать, когда примете на себя обязательство абсолютной честности по отношению к себе и к окружающим?
Да. В каком-то смысле, MVP — это прототип для бизнес-идеи.
Что-то вы не по тем бегаете. По-идее, если вы сделали MVP и подтвердили ценность, то все инвесторы будут рады вам дать денег — новые работающие идеи большая редкость. А если опровергли, значит расслабьтесь — это не нужно. Начинайте придумывать новую идею.
Какие именно качества ядра проверялись?
Для того, чтобы показать клиенту и получить фидбек не обязательно соблюдать требования всех регуляторов. В релиз, конечно, с таким не уйти, но цель MVP — не улететь в бой, а проверить ключевую гипотезу.
Какая ключевая гипотеза вашего продукта?
Кто ваш клиент?
Для дженериков можно сделать ADT и на их базе все решать.
В принципе, вопрос со статическими переменными можно решить на базе Map-ов (псевдокод):
class Foo (type T) {
static Bar = Map(subclassof Foo, T)
}
Ну и для красоты снабдить это отдельным синтаксисом:
class Foo (type T) {
static instance T Bar
}
В общем, решаемо.
К психологу!
Нет, конечно. Есть метода, по ней все делается. Смысл в том, что вы вначале находите клиента, а уже для этого клиента делаете. Формулы там будут, конечно, но они очень простые. Там целая пирамида валидации. Вначале вы валидируете идею в разговоре с коллегами, потом выходите на потенциальных клиентов, с ними два вида интервью: проблемное и глубинное, и только потом уже валидация гипотезы масштабирования — идете в сеть или обзваниваете массу людей. В этом деле всякие там корреляции, критерии стьюдента не принципиальны — и так все понятно. Если вам несколько человек говорят одно и то же и готовы платить за решение проблемы, значит ее стоит попробовать решить.
«Он адекватный» == «Он действует исходя из объективных факторов и не додумывает ничего сам» == «Я ему доверяю, потому что он справедлив и рассудит по-существу».
Не знаю, может и реально. Зависит от много всего.
Просто вы себя заранее в ловушку загоняете терминологией. Может, вашему клиенту этот самый АБС даром не нужен, а ему нужно что-то другое. Проблемы начинаются, когда вы подтвердили ценность АБС, поняли что нужно делать только так и никак иначе и у вас не хватает денег.