Ivan Kuznetsov
10 лямов резаной бумаги это копейки для медиа, в целом.
"Слоган Setters Media — «издание для тех, кто согласен на будущее», рассказала компания. Его целевая аудитория — специалисты креативных индустрий, любители культуры, науки и инноваций и предприниматели." — это интересная идея, я никогда не видел еще медиа для заложников.
ну да — в основном бегуны это делают установив на смартфон приложение Strava.
"что такое Strava?" — можете не вдаваться, важно что у любого кто говорит что 5км меньше чем за 30 мин это фигня в 99% есть Strava, поэтому он на практике может доказать свое утверждение
Не могу судить за всех разрабов, я был по большей части счастлив как разраб, но мне попадались плохие менеджеры. Дай им молоток или дай микроскоп получится одинаковый результат (читай, методология им ничем бы не помогла). Так же я был свидетелем пары agile трансформаций, которые все сделали только хуже, внедрение методологию в среду слабых руководителей не приводит ни к их замене на более сильных, не к улучшению их работы и работы в целом (тоже сюрприз).
Я сторонник гибкости и в первую очередь, здравого смысла, в разработке и точно не призываю планировать на пять лет вперед. Но аджайл в массах ушел от идей гибкости, примерно как церковь ушла от идеи бога.
"вы сам источник всех своих проблем. Удачи вам в нелегкой борьбе с собой!" — так можно сказать про любого человека )
проблема в том, что продукт и технологии часто связаны. В примере выше — торговый терминал это огромный продукт. Его могут пилить даже несколько команд. И у них свой сет технологий. У бэкендеров свой. И в такой ситуации, когда есть сложные технологии, не веб-приложение для трекинга задачек, и не vc.ru а технически более изощренный продукт, делать кроссфункциональные команды которые несут ценность пользователям не получается.
Понятно что это все разбивается на внутренние продукты, внутренних пользователей, метрики и kpi но в целом это не сильно ближе к принципам декларируемым аджайлом чем то как работает какой-нибудь Крок, только более модно.
отлично — внутренние продукты. С внутренними заказчиками. И приоритизация между ними, синхронизация продуктовых планов. И вот мы приходим к старому доброму Ганту.
вы сравниваете две полярности — чистый божественный аджайл и адский вотерфол. На практике никто за пределами аджайла не собирает все требования в начале года, более того, в большинстве проектов требования уточняются постоянно, планы пересматриваются регулярно. Я понимаю что сравнивая с ситуацией собрать все требования в начале года и запланировать, любая методология будет выглядеть победителем, примерно как если не стрелять себе в колено это отличная мера для здоровья коленей.
самое важное здесь, что кроссфункциональные команды это утопическое царствие небесное для очень многих бизнесов, особенно если они с самого начала не нанимали и не создавали всю разработку в таком виде.
Например, если вы делаете продукт со сложным клиентом, такой как трейдинговая платформа, у вас рано или поздно он вырастет в набор самостоятельных продуктов — хранилище котировок, торговый терминал, обработка заявок и гейты к поставщикам ликвидности и биржам, административные интерфейсы и так далее. Можно заменить эту аналогию на любой продукт где клиент и сервер достаточно масштабные, созданы на разных технологических стеках, то есть почти всегда.
Каждый из этих продуктов будет состоять из разных специалистов, иногда даже с разным стеком технологий (очевидно клиент и сервер могут быть созданы на разном стэке, но даже бэкендовые сервисы могут иметь разные технологии — go для high performance и python, например, для того, что не требует высокой производительности)
Go программист в такой ситуации не может написать клиентскую часть, а разработчик клиента не может писать бэкенд. При этом каждый из продуктов делается силами нескольких людей. И все — нет кроссфункциональных команд. Это пытаются решить разными способами в agile, лучший из которых это фичекоманды.
Да, настоящие адепты скажут мне — что всегда можно сделать кроссфункциональные команды, что я говорю ересь — распределить 4 фронтедера по командам и вот вам 4 кроссфункциональные команды, но в реальной жизни это так не работает, люди объединяются вокруг сервиса и вокруг технологического стэка. Четыре человека из разных команд коммитящие во фронт без согласования сотворят дичь. Придется иметь отдельного архитектора который синхронизирует их работу. И в итоге мы просто получим параллельную структуру (фронтендеры/члены кроссфункциональных команд) с параллельным менеджментом (архитектор фронтенда/менеджер команды).
Фичекоманды как идея мне нравится. В такой ситуации продуктовый менеджер выделяется на фичу и работает с командой которая готова эту фичу сделать. И когда мы начинаем дальше крутить эту идею в голове — мы приходим к Shape Up
1. SAFE это чистый кровавый энтерпрайз, как и прочие попытки масштабирования Agile
2. "а мотивация разработчиков должна быть подвязана на результаты" — должна конечно, но в реальной жизни у людей есть разные мотивации, и вот эта идея, что кто-то кому-то что-то должен, не работает за пределами идеального мира религиозно-озабоченных людей.
3. Я плачу продактам не для того, чтобы они спрашивали у пользователей, что им нужно. А для того чтобы они делали то, что пользователь купит. Нужен пользователю blackberry с лучшим экраном и большей батарейков. А купит он Айфон. Интервью это один из инструментов проверки гипотез, заказчик и пользователь не знают что им нужно.
да и в продуктовых, вы планируете что? спринт. В спринт идут что — таски. Таски делегируются от кого — от продуктового менеджера. Программисты и дизайнеры — делают таски, а не проекты.
Вы писали когда-нибудь "Обоснование выбора программных средств" на 200 страниц, а потом "Обоснование выбора проектных решений" на пять томов перед разработкой системы? — это же не вопрос скрам или не скрам, это вопрос принятых верхнеуровневых стандартов в документообороте. При этом, внутри могут быть скрам-команды вполне, но наружу вам придется отдавать тома документации все равно.
У меня три класса церковно-приходской школы, а что?
Проблемы неопределенности есть в любой индустрии. Да, разработка ПО это скорее стык творчества и производства, но так же, например и архитектура, и всякие cutting edge проекты. В той или иной степени элемент творчества и элемент неопределенности есть в любой задаче.
Покажи свою Strava.
Модно и не работает — не противоречит друг другу.
Вырастил ли он экономику с начала года при этом на 86%?
Марк Цукерберг недооценен современниками.
Он создал компанию больше 15-ти лет доминирующую на рынке социальных сетей который очень быстро менялся и всегда был конкурентен
Он продолжает делать очень смелые ставки, не смотря на всеобщую критику, зная что стагнация это смерть, и что ставки, если сыграют, принесут ещё десятилетия благоденствия
Он не ушел на пенсию, не стал почетным президентом и напрямую 19 лет управляет огромной компанией
Он занимается MMA, участвует в любительских соревнованиях по Джиу Джитсу и может тупо отпиздить большинство своих критиков (включая журналиста Insider).
Пробегает 5км меньше чем за 30 минут.
Вырастил акции FB на 86% c начала года (это больший рост чем даже 69% у Майкрософта)
Но да, по мнению журналистов, он плохой CEO
Ну конечно, работать с неполнотой требований можно только по scrum. Ведь за пределами разработки ПО всегда есть вся полнота требований, от оборонного заказа до частных яхт. И только в разработке ПО, так получилось, что требования бывают неполными, и только скрам это решение проблемы.
"Scrum-команда работает над продуктом, а не над проектом." — за исключением ранних стадий, над продуктом работают несколько команд.
"В Scrum команде полностью делегирована ответственность за продукт." — ответственность обычно у того, кто рискует (деньгами, карьерой), делегировать ответственность не делегировав риск невозможно.
"Суть же Scrum очень проста - послушали пользователя, записали на бумажку, то как его поняли, запилили как сумели - показали пользователю," — кнопочный айфон часто показывали пользователю, как и многие другие продукты (gpt, ракеты spacex, впрочем назовите любой продукт, которым пользуетесь). Более того, пользователь, или даже внутренние стейкхолдеры способны дать вменяемый фидбек по прототипу, mvp етц.
"У вас же аджайл, мальчики, быстро все запилите, я вон в 2004 году вдвоем с другом автоматизацию лакокрасочной фабрики сделал!" — это прямо мои слова
я работал с большим количеством команд. Agile и не agile. Все говорили, что они agile, разумеется. Потому что странно говорить что ты работаешь по waterfall, это немодно, некрасиво (повторюсь, многие из них работали по самому адскому waterfall, из аджайла у них были может разве что стендапы). Человек который скажет что у них waterfall либо очень уверенный в себе успешный менеджер (видимо те успешные проекты из картинки выше делает) либо человек навсегда разочаровавшийся в жизни и разработке ПО.
Опять же так или иначе очень многие применяют какие-либо из методологий agile полностью или частично. Можно ли назвать их Agile командами? нет. Еще момент — что гибкие методологии начинают интересовать более жирные проекты, где в целом, работают более опытные люди, что тоже влияет на "успешность".
есть немного разное понимание проекта. В моем мире — любая фича это проект. В скраме обычно выбирается набор задач из бэклога, которые войдут в спринт, планируются/оцениваются, и идут в разработку. Да, в идеале, каждый спринт должен завершаться, с новым функционалом который приносит ценность и можно было бы это обозначить как проект. На практике, это просто итеративный производственный процесс где бэклог переходит в фичи. К тому же — в процессе планирования участвует менеджер, иногда продакт-овнер, скрам-мастер. Кто в итоге планирует — команда или они, на практике сложно отличить (очевидно что человек способный к лидерству способен заставить команду делать как он хочет, так чтобы команда думала что она это хочет делать именно так). Можно ли считать это делегированием команде?
нет, это просто кривая статистика )
да
нет конечно. В скраме делегируются задачи.
12 принципов
Ты сам-то читал что-то кроме газеты комсомольская правда?
Да нормально искал. Тут я думаю тоже методология не выдерживает никакой критики. Но где я, а где сраная advisory group которая делит всю разработку на agile и waterfall. ))
для любого — если у тебя нет аудитории уже готовой или простого доступа к ней, что на 10млн закупишь?
Да и какая окупаемость в медиа, это оксюморон.