Connect with us

Статьи

Почему вам стоит убить вашу денежную корову

Единственный способ построить устойчивую техническую компанию – успешно переходить с одной S-кривой на другую.

Анна Гуляева

Опубликовано

/

     
     

Абхишек Мадхаван, продукт-менеджер, автор Wired и других изданий, рассказал о жизненных циклах продуктов и как бороться с их упадком.

В начале 2017 Gartner сообщил, что аппаратный бизнес Blackberry окончательно почил в бозе, достигнут рыночной доли в 0.0%.

Да, вы прочитали это правильно.

Ноль.

Ничего. Совсем. Нет продаж.

Что на самом деле случилось? Blackberry просто умерла?

На самом деле, нет. Компания умерла еще в 2007, когда был выпущен iPhone. Бывший исполнительный директор Blackberry Джим Бальсилли признался в этом пару лет назад.

График выше просто показывает отставание.

Самое смешное, что вплоть до 2009 года, спустя два года после запуска iPhone, компания владела почти 25% мирового рынка смартфонов, что побудило Fortune назвать ее самой быстрорастущей компанией в мире. К тому же доходы компании выросли более чем в 4 раза и достигли максимума через четыре года после запуска iPhone.

Apple вышла на рынок смартфонов с новой парадигмой потребительского устройства, а не устройства для предприятий.

Не было никакой возможности Blackberry, с ее огромной клиентской базой, состоящей из крупнейших компаний и связанных с ними больших контрактов в области ИТ, возможно, увидеть угрозу ее тогда чрезвычайно успешную бизнес-модели и портфелю продуктов, чтобы приспособиться к изменившемуся миру вокруг.

Единственный вариант, который, к сожалению, оставался – быть разрушенными другими. Нетрудно представить, как стажер, увлекшись iPhone, мог представить его своим боссам в RIM.

iPhone? Пффф… Посмотрите на их продажи и потом на наши. Иди, заключи еще IT-контрактов.

Даже несмотря на то, что они умерли уже в 2007, ошибочность отстающих во времени показателей дохода и прибыли заставляла их думать, что они по-прежнему в игре, так как доходы продолжали расти и достигли пика в 2011. Мы побеждаем!

А затем, в 2012 доходы упали. Упс.

Еще резче в 2013. Что происходит?

К тому времени, как они вышвырнули генерального директора и вложились в новый «consumer-ready» продукт, гонка уже давно шла, и победители уже были определены.

Обгонит ли нас Netflix? Это все равно как сказать, что албанская армия захватит мир, – Джеф Бевкес, директор Time Warner в начале 2009.

Болезненная неизбежность жизненных циклов продуктов

Жизненный цикл технологических продуктов смущающе предсказуем. Лучше всего его можно представить S-образной кривой, основанной на десятилетиях эмпирических доказательств, наблюдаемых в бесчисленных отраслях.

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

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

После достижения критической массы продукт начинает взлетать по мере достижения неуловимого успеха. Продажи растут как на дрожжах, и фокус затем смещается на масштабировании продукта до максимально возможного охвата рынка.
С течением времени рынок начинает взрослеть, продукт становится стандартным и фокусируется на достижении максимальной эффективности в свете появления успешных последователей. Здесь маржа и доля на рынке находятся на самом высоком уровне. Кривая инноваций теперь начинает сглаживаться по мере того, как производятся небольшие изменения.

Как только эта кривая начинает сглаживаться, появляются новые продукты. Они снова возникают с нижней части рынка, захватывая ниши. Медленно сначала, а затем все быстрее, разрушитель догоняет действующего лидера с точки зрения производительности и стоимости. Затем разрушитель начинает отъедать все больше и больше рынка, заменяя действующего лидера и открывая новую собственную кривую роста.

В технологиях этот цикл постоянно повторяется.

Развитие технологий имеет тенденцию следовать S-образной кривой: они сначала медленно улучшаются, потом быстро, а затем снова медленно. И на этом последнем этапе они действительно хороши. Все оптимизировано, работает и понято, продукты быстры, дешевы и надежны. Это также часто указывает на то, что на подходе новая архитектура, – Бенедикт Эванс.

Единственный способ построить устойчивую техническую компанию – успешно переходить с одной S-кривой на другую.

То, чего никогда не сделала Blackberry.

Несмотря на удручающе цикличную природу продуктов, которая общеизвестна и наглядна, шокирует то, как многие компании отказываются видеть ее и оставляют погибать под новым технологическим взрывом.

Матрица BCG и ее забытая правда

Фактически, Boston Consulting Group разработала эту матрицу еще в 1970 году, и ее изучают в любых бизнес-школах – она объясняет, что нужно делать в отношении этого повторяющегося явления.

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

Когда вы являетесь лидером на зрелом рынке, ваш продукт генерирует больше денег, чем потребляет. Крайне важно, чтобы вы доили свой продукт, называемый дойной коровой, до максимума. Все технологические компании, похоже, интуитивно понимают это и выполняют «доение» почти идеально.

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

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

Проще говоря, единственная цель существования денежных коров – обеспечить рождение будущих денежных коров.

Бостонская модель утверждает, что рынки являются стабильными системами, в которых у авторитетных компаний есть естественное преимущество. Это было так 50 лет назад, но сейчас это точно не так. Скорость изменения рынков сегодня сильно возросла, и она будет только увеличиваться в дальнейшем.

Во времена основания Amazon Web Services барьера для создания масштабируемого ПО почти не существовало, а Интернет снизил затраты на распространение до нуля. Жизненные циклы продукта стали короче, а изгибы на кривой – круче.

Компании, которые не принимают этот простой факт, умирают быстрее, чем когда-либо. Ожидаемое время жизни компании из Fortune 500 снизилось до 15 лет с 75 лет в 1960 году.

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

Дилемма инноватора

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

Причины найти несложно.

Сотрудники ненавидят начинать S-кривую новой технологии. Она выглядит ужасно непривлекательно с вершины существующей S-кривой.

Сотрудники умирающих компаний становятся добычей иллюзии о бесконечной S-кривой, экстраполируя свои графики бесконечно вверх. Не помогает и то, что наш мозг запрограммирован видеть прямые зависимости, а не кривые.

Когда Blackberry зарабатывала все больше денег на своем пике, кривая iPhone выглядела маленькой и несущественной.

В своей революционной книге “Дилемма инноватора” Клей Кристенсен говорит, что из-за развития инновации по кривой, она наиболее ценна в середине и менее ценна в начале и конце.

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

И угадайте, о какой кривой вы должны заботиться по мнению Уолл Стрит.

Сложно заметить следующую большую вещь, когда у вас уже есть одна прямо перед вами.

Если вы CEO, вы должны сообщать о ежеквартальном доходе, и Уолл Стрит хочет, чтобы эти доходы каждый раз росли. Легко понять необходимость продавать больше и больше денежных коров для максимизации прибыли и дохода.

Самая сложная вещь – делать фундаментальные изменения в бизнесе, когда вы зарабатываете деньги и приносите прибыль. – Бен Томпсон.

Совсем редко вы можете убедить инвесторов в растущих доходах, особенно на коротком отрезке времени, когда вы тратите деньги на новые инициативы. Если, конечно, вы не Amazon.

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

Арджун Сети из Social Capital считает, что, несмотря на работу Клея Кристенсена, середина S-кривой заставляет компании думать, что их миссия – защищать существующую аудиторию и долю на рынке. Самая фатальная ошибка.

В этой точке компания становится не клиентоориентированной, а фокусируется на продукте, денежной корове. Стратегия компании теперь ориентирована на увеличение масштабов прибыли продукта.

Это может включать три пути развития:

  1. Привлекать новых пользователей существующего продукта развитием на новых рынках.
  2. Побуждать более частое использование продукта среди текущих пользователей.
  3. Расширение функций продукта, чтобы привлечь пользователей из новых вертикалей.

К существующему продукту добавляются новые функции, он становится более сложным. Тем временем компания продвигается на рынке, приближаясь к точке невозврата.

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

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

Компании похожи на биологические организмы. Они фокусируются на “ключевых показателях” и работают для их оптимизации. Это значит, что другие пути менее исхожены и стоят того, чтобы их изучить. – Шамик Шарма.

Вот что Стив Джобс говорил о фатальной ошибочности такого поведения:

Малейший сдвиг в стратегии ведет к полному непониманию бизнеса компанией.

Ваш бизнес никогда не находится в точке “продайте-больше-ваших-денежных-коров”. Он всегда находится в точке “реши-конкретную-проблему”.

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

И затем метеор ударяет.

Теперь вы поняли фатальную ошибку.

Но как вы решите дилемму инноватора?

Увеличивая свои шансы.

Это та же простая логика, с которой выигрывают люди на биржах или в казино.

Известно три способа:

  1. Развивайте группу продуктов вместо того, чтобы полагаться на одну денежную корову или звезду. Facebook (c Messenger, Whatsapp и Instagram) – отличный пример. Создание семейства продуктов значит, что вы распределили свои ставки на разные продукты на разных стадиях кривой.
  2. Поймите, что вы не всегда можете создавать правильный продукт. Вместо этого создайте платформу и улавливайте успешные S-кривые с её помощью. Amazon – самый успешный пример компании с платформенным мышлением в самой её ДНК (очевидный пример – AWS). Slack также сейчас находится на пути превращения в платформу для предпринимателей.
  3. Примите неизбежное, убейте свою денежную корову и начинайте создавать следующую большую вещь.

Конечно, сделать это не так просто, как звучит. Даже если вы узнали свое место на кривой и начали создавать следующий продукт, существует много подводных камней.

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

Одна из моих задач – побуждать людей быть смелыми. Это очень сложно. Эксперименты склонны проваливаться. Несколько успешных случаев – компенсация за десятки несработавших вещей. Смелые ставки – Amazon Web Services, Kindle, Amazon Prime – все эти вещи заплатили за многие эксперименты.

Я потерял миллиарды долларов на неудачных экспериментах в Amazon. Можете вспомнить Pets.com или Kosmo.com. Но они неважны.

Важно то, что компании, которые перестают экспериментировать и не принимают провала, оказываются в положении, где могут сделать только ставку в казино в конце своего существования. Компании, которые постоянно рискуют, в плюсе. Но я не верю в ставки на всю компанию. Это для отчаянных случаев, – Джефф Безос.

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

Стив Джобс упоминал работу Кристенсена, чтобы рассказать о факте, который полностью усвоила Apple.

Если вы не разрушите себя, кто-нибудь другой разрушит, – Стив Джобс

В 2007, когда Apple запустила iPhone, iPod был их денежной коровой, приносящей 50% дохода. Стив Джобс знал, что интегрируя функциональность iPod в iPhone, он убивает свою денежную корову.

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

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

Наша главная философия – не бояться каннибаллизма. Если мы этого не сделаем, найдется кто-нибудь ещё. Mac убил Apple II. iPhone поглотил часть бизнеса по продаже iPod. Мы знаем, что iPad убьет часть Mac. Но это нас не тревожит, – Тим Кук.

Организационная структура Apple также помогает им справляться с дилеммой инноватора и двигаться от одной успешной S-кривой к другой снова и снова.

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

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

Вывод такой: принять неизбежную смерть продуктов и быть готовым уничтожить ядро вашего бизнеса, чтобы выжить в будущем. Если вы не следуете кривой, вы обречены.

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
1 Comment

1 Comment

  1. Daniel Chepenko

    26.07.2017 at 17:15

    шикарная статья! Спасибо за перевод

You must be logged in to post a comment Login

Leave a Reply

Аналитика магазинов

Как iOS и Android разделили мобильный рынок

Ходят легенды, что раньше на рынке мобильных устройств было много операционных систем, и они делили рынок на примерно равноценные части… AppCraft рассказывает о том, как было все на самом деле, и что происходит с платформами сейчас.

AppCraft

Опубликовано

/

Автор:

Беглый поиск в Google позволил найти занимательную информацию о том, что первые изменения начались в недалеком 2010-ом. В августе того года на geektimes опубликовали статью с заголовком “Android вырвался на 3-е место по продажам на рынке мобильных ОС”, и в комментариях помимо баталий начались предсказания даты, когда Android захватит мир.

Выглядел переходный момент вот так:

Распределение операционных систем проданных смартфонов за 2 кв. 2010 года

Диаграмма показывает статистику по проданным смартфонам по всему миру за второй квартал 2010 года от исследователей из Gartner, а к апрелю 2011 года компания Nielsen подбила статистику по США, что позволяет нам сегодня легко определить ту самую отправную точку успеха Android:

Распределение операционных систем проданных смартфонов в США в марте 2011 года:

Распределение операционных систем проданных смартфонов в США в марте 2011 года

И уже в августе 2011 года аналитики Сanalys опубликовали информацию о том, что Android захватил половину рынка, став самой распространенной платформой среди пользователей смартфонов.

Распределение мирового рынка операционных систем в 2011 году

Заканчивая небольшую историческую справку, скажу, что даже сооснователь Apple Стив Возняк в том же 2010 году в интервью De Telegraaf беспристрастно заявил, что Android станет доминирующей платформой, поэтому назвать текущее положение дел на рынке удивительным не получится – тенденция к этому была очень наглядной и устойчивой.

Распределение операционных систем в 2017 году

На сегодняшний день Android сохраняет лидерские позиции по количеству пользователей в мире с большим отрывом от других участников рынка. Однако в ряде стран показатели сильно расходятся со среднестатистическими данными. Статистический сервис StatCounter удобно демонстрирует результаты аналитики рынка мобильных операционных систем с разбивкой по месяцам, странам и другим параметрам. Вот так распределялись платформы по рынку за последний год:

На долю Android приходится 73.54% рынка, на iOS – 19.91%, оставшиеся 6.5% распределены между другими системами.

Но если взять данные за этот же промежуток времени – с декабря 2016 по декабрь 2017, но по Канаде, то мы увидим совсем иное распределение:

Именно такие нюансы нужно учитывать при выборе платформы для разработки вашего приложения. Подобные графики можно посмотреть на StatCounter по миру, Европе, Африке, Азии и некоторым крупным странам за период с 2009 по 2017 год.

Платежеспособность iOS и Android пользователей

Финансовые возможности пользователей двух основных операционных систем регулярно сравнивают практически все аналитические фирмы в сфере IT. Из года в год результаты меняются не кардинально, но проследить некоторую динамику в существующих изменениях можно. Исследовательская компания App Annie наглядно продемонстрировала, что несмотря на рост скачиваний приложений из Google Play, платить за контент пользователи Apple готовы значительно больше.

Количество загруженных приложений

Количество потраченных денег

Говоря о динамике, хочется обратить внимание на разрыв в выручке между App Store и Google Play – он почти не сокращается. Здесь и раскрывается вопрос платежеспособности владельцев девайсов на этих платформах.

Разберемся подробнее:

  1. Число загрузок из App Store за год практически не изменилось, а пользователи Android стали скачивать больше приложений.
  2. За второй квартал 2017 года из Google Play было загружено 17 миллиардов приложений – на 135% больше, чем из App Store за тот же период. Разница в количестве скачиваний между операционными системами по сравнению с прошлым годом увеличилась практически на 30%.
  3. Пользователи iOS при том же количестве загрузок стали платить за контент гораздо больше, а траты владельцев Android увеличились незначительно.

Вывод получается однозначным: пользователи iOS тратят больше денег на покупки в мобильных приложениях, хотя скачиваний на Android больше в 2,5 раза.

Так для какой платформы разрабатывать приложения?

До запуска рекламной кампании сложно предсказать, какая именно платформа принесет больше прибыли для конкретного приложения. Выбор платформы в первую очередь должен быть связан с идеей вашего приложения и его целевой аудиторией. Причем целевой аудиторией в широком смысле: важен не только возраст и интересы, но и регион проживания, ведь где-то соотношение iOS к Android практически 1/1.

Монетизация приложений для двух описанных платформ разная: как мы выяснили, пользователи техники Apple тратят больше денег на покупки в приложениях, поэтому приложения, подразумевающие премиум–аккаунты, внутренние покупки и прямую монетизацию пользователя в приложении, стоит разрабатывать скорее для iOS.

В то же время столбец с доходами Google Play не на нуле. Мы уже писали, что пользовательское внимание сегодня стоит дорого, поэтому самым простым и популярным способом вывода в прибыльность Android–приложений является реклама. Когда ваше приложение скачивают миллиарды пользователей, найти рекламодателей, желающих урвать хотя бы 15 секунд внимания своей целевой аудитории, не сложно.

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

Комментарии
Продолжить чтение

Разработка

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

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

Анна Гуляева

Опубликовано

/

“Почему мы так медленно выпускаем новые функции так медленно?” — думал я спустя год после присоединения к быстро растущему стартапу. Релиз каждой новой функции был болезненно долгим. Это не то, чего я ожидал — стартапы должны двигаться быстро. Особенно, если вы ещё не нашли свою нишу. В начале моей работы у нас было три команды разработки. Спустя год и несколько миллионов инвестиций у нас в распоряжении было девять команд разработки. Наша способность к разработке утроилась, но новые функции выходили с той же скоростью. В чем же дело? Я думаю, что дело было в законе Брукса, который утверждает, что добавление новых разработчиков в проект на поздней стадии, приводит к ещё большему замедлению проекта. Мы наняли многих отличных разработчиков, но им нужно было понять что замедляло остальных сотрудников.

Наш мотивирующий постер для разработчиков

Спустя полгода мы по-прежнему выпускали новые функции медленно. Поэтому, очевидно, закон Брукса был уже не при чем. Должна была существовать ещё одна причина, но какая? Потом мы столкнулись с проблемой в производстве, которая указала мне на возможного виновника.

Проблема и урок

Мы только выпустили новую функцию фильтрации по тегам. Поддержка получала жалобы о том, что функция не работает. Первым делом я попытался загрузить картинку и отметить её как “Не хот-дог”. Потом я попробовал отфильтровать картинки по этому тегу и убедился, что фильтрация не работает. Я составил список команд, которые участвовали в создании функции. Каждая команда была ответственна за свой компонент:

  1. Загрузка и обработка изображений.
  2. Elasticsearch.
  3. Фронтенд фотоальбома.
  4. Команда DevOps, ответственная за инфраструктуру и развертывание новых функций в облаке.

Я решил сначала поговорить с командой по загрузке изображений. Я спросил руководителя команды, почему их функция не работала. Он посмотрел, что теги были сохранены и предположил, что они не были проиндексированы, что привело меня к команде Elasticsearch. Разработчик из следующей команды заглянул в Elasticsearch. Тег был проиндексирован, все выглядело отлично. Поэтому он отправил меня к команде фронтенда альбома. Они обнаружили, что фронтенд-библиотека была развернута в более старой версии. Функция фильтрации зависит от этой библиотеки, поэтому это, вероятно, было причиной проблемы. Фронтенд-команда посоветовала мне поговорить с командой DevOps, чтобы они развернули нужную библиотеку. Я устал ходить от одной команды к другой и сказал им, чтобы они сразу исправили эту проблему. Наконец проблема была решена. Я понял, что командам не хватало ответственности за то, что они создавали. Команды были разбиты по компонентам, и никто из них не чувствовал ответственности за функции – каждый работал только над маленьким кусочком пазла. Разбитие команд по компонентам сделала быстрый выпуск новых функций сложным. Все их усилия были тесно связаны. Если одна из четырех команд не работала или задерживалась, это влияло на выпуск всего функционала.

Почему компании начали разбивать команды по компонентам?

В начале разработки продукта команды часто самостоятельно разбиваются по компонентам. Если сам продукт пока не имеет структуры, то технические компоненты для его работы понятны. Поэтому команды проще организовать по этим компонентам. Эта идея довольно проста — каждая команда ответственна за один или более компонентов. Такая структура помогает увеличить продуктивность разработчиков, которые работают над конкретными частями системы. Создание чего-то нового на Amazon RedShift? Только одна команда должна беспокоиться об изучении RedShift. Недостаток таких команд заключается в том, что менеджеры должны беспокоиться о выпуске функций. Границы между командами создают зависимости, которые требуют активного управления. Это возможно, если у вас не так много компонентов или функции не распределены между множеством команд. Представьте, что вы владелец продукта и хотите внедрить Feature 2,  как на картинке ниже. Она зависит от двух компонентов, за которые отвечают разные команды. Функция выйдет, только если обе команды завершат необходимую работу над своими компонентами. Вернемся к примеру с фильтрацией тегов. Так как даже причину неисправности было сложно установить, представьте, как неэффективно было заставлять все эти команды координироваться ради одной маленькой функции. Любая задержка в любом компоненте вызывала задержку релиза функции. Чем больше компонентов и команд вовлекалось в дело, тем больше возникало проблем с координацией и вынужденного ожидания. Если один спринт одной команды проваливается, функция не может быть выпущена.

Альтернатива: команды по функциям

Вместо того чтобы делать команы ответственными за компоненты, вы можете сделать команды ответственными за функции. Представьте, что одна команда была бы ответственна за фильтрование и поиск, а другая — за метаданные к изображениям. При выпуске фильтрации по тегам вам нужно было скоординировать усилия всего двух команд. При этом ответственность за компоненты делится, и несколько команд могут работать над изменениями в одних и тех же компонентах. Усилия по координации смещаются с уровня функции на уровень компонентов. Управлять на уровне функции сложно, но это проще, чем управлять на уровне компонентов. Вам нужно убеждаться, что изменениями в компонентах занимаются люди, которые больше других в компании знают об этих компонентах, а также все команды должны разбираться в одних и тех же технических вопросах.

Переход к командам по функциям

Многие команды начинают с команд по компонентам, потому что структура продукта неясна в начале существования проекта. Но в какой-то точке команды по компонентам могут начать вас тормозить. Вот симптомы, которые подскажут вам, что ваша структура вас замедляет:

  1. Разработка небольших функций занимает больше времени, чем вы ожидали, потому что они находятся в зонах ответственности разных команд.
  2. При возникновении проблем все показывают пальцем друг на друга. Никто не несет ответственность за функцию.

Если это происходит, вам стоит рассмотреть переход на команды по функциям. Такая работа имеет свои сложности: вам нужно будет придумать лучшее распределение компонентов между командами и подстроить свою архитектуру, чтобы разъединить как можно больше компонентов. Переход к командам по функциям — это самая сложная часть работы с подобной структурой. Как структурировать команды? Как передавать знания? Как убедиться, что организация разрешит вам изменить структуру? Этому будет посвящена уже другая статья.    https://apptractor.ru/develop/myi-uvolili-nashego-luchshego-razrabotchika.html https://apptractor.ru/info/articles/vyi-uvolili-luchshego-razrabotchika-nadeyus-vyi-dovolnyi.html  

Комментарии
Продолжить чтение

Программирование

Создание анимации в 7 строк кода

Android-разработчик Леонардо Пирро рассказывает, как создать простую анимацию при помощи ConstraintLayout и ConstraintSet.

Анна Гуляева

Опубликовано

/

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

ConstraintLayout + ConstraintSet

Я хочу поделиться с вами новым способом создания анимаций в приложении при помощи всего семи строк кода, используя Keyframe Animations, ConstraintLayout и ConstraintSet. Эта концепция заключается в создании двух разных макетов: одного для начальной точки и одного для конечной точки анимации. Давайте посмотрим, что мы хотим создать: наша цель — создать плавную анимацию детали, которая будет появляться при нажатии пользователем на экран.

Анимация создается при помощи двух файлов макета: circuit.xml and circuit_detail.xml. Эти макеты очень похожи и различаются только тем, что на первом элементы вынесены за экран, а на втором — находятся в нужной позиции.

Поэтому давайте создадим анимацию и увидим, как просто создавать анимацию при помощи ConstraintLayout и ConstraintSet.

Пусть магия произойдет

Сначала создадим отдельный ConstraintSet, куда мы скопируем ограничения второго макета, вызвав метод clone():

val constraintSet = ConstraintSet()
constraintSet.clone(this, R.layout.circuit_detail)

Теперь создадим объект перехода, используемый для установки интерполятора и продолжительности анимации:

val transition = ChangeBounds()
transition.interpolator = AnticipateOvershootInterpolator(1.0f)
transition.duration = 1200

Сейчас вызовем TransitionManager.beginDelayedTransition(), который используется для осуществления перехода на следующий кадр рендеринга. Затем мы вызываем applyTo(), чтобы начать анимацию.

TransitionManager.beginDelayedTransition(constraint, transition)

constraintSet.applyTo(constraint)

Это действительно семь строк кода. Вот и все! Вы можете посмотреть полный пример в моем репозитории GitHub по этой ссылке.

Комментарии
Продолжить чтение

Статьи

Как лучшие руководители сочетают два подхода к видению мира

Что общего между Генри Фордом и Биллом Гейтсом? Дело в сочетании двух подходов к своей работе, которое могут применять люди любых профессий, считает основатель рассылки Design Luck Зат Рана.

Анна Гуляева

Опубликовано

/

Когда Microsoft впервые представила Windows, это не произвело особого шума. Первая версия вышла в 1985 году и почти не привлекла внимания. В последующие годы популярность начала расти, но только в начале 1990-х система начала набирать обороты.

Несколько первых десятилетий существования Microsoft Билл Гейтс был очень вовлечён в каждый аспект своего бизнеса. Первые пять лет существования компании он просматривал каждую строчку кода лично. Компании несколько раз крупно повезло, но даже если учесть это, то вряд ли люди, отличающиеся от Гейтса, смогли бы развить Microsoft до нынешнего размера.

То же самое касается Стива Джобса. Многие его коллеги рассказывали о его маниакальном внимании к мельчайшим деталям. Теперь мы можем видеть, как это вывело Apple на вершину.

Теперь их подходу во многом следует Илон Маск. Он создал уже не одну компанию, обладающую потенциалом изменить мир. Интересно, что около 80% своего времени он проводит, работая над дизайнерскими и инженерными проблемами.

Фокус на деталях

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

Но любопытно, что успех многих самых влиятельных лидеров в истории можно отследить до мельчайших и, казалось бы, неважных вещей. Это относится ко всем людям – от Томаса Эдисона, Альфреда Слоуна и Генри Форда до Гейтса, Джобса и Маска.

Так, например, в биографии Маска Эшли Вэнс рассказывает о письме, которое он лично отправил каждому сотруднику SpaceX. Это было предупреждение о чрезмерном употреблении аббревиатур. Маск посчитал, что это выходит из-под контроля и может в будущем привести к неэффективной коммуникации, если создание новых слов и смыслов продолжится. Этот человек работает от 80 до 100 часов в неделю над революционными проектами, и довольно необычно, что он потратил час или два, чтобы написать о такой небольшой проблеме.

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

Эффект формирующего

Рэй Далио — основатель крупнейшего хедж-фонда в мире Bridgewater Associates. В своей книге он поделился тем, что провел несколько лет за анализом того, что делает некоторых людей более эффективными в достижении больших результатов при управлении крупными компаниями. Многие преемники людей, вроде Джобса или Гейтса, справляются не так хорошо, и чтобы избежать того же для своей компании, он хотел лучше понять, что отличает таких людей. Далио разработал тесты для понимания людей, которых он нанимает, их сильных и слабых сторон.

Чуть позже он пригласил Гейтса и Маска пройти некоторые из этих тестов, как и других людей, достигших уникального успеха. Он обнаружил, что многих из этих людей можно назвать «формирующими», и их особенность заключается в том, что они сильны как в стратегических, так и в тактических вопросах. Они эффективны и в работе над небольшими деталями, и в разработке глобальных планов, которые будут вести их на протяжении долгого времени.

Что это значит?

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

В обеих позициях все равно стоит посмотреть на другую сторону. Если вы объедините оба подхода, вы сможете увидеть вещи, которые не видят другие. Это расширит ваше поле зрения и взгляд на мир.

 

Комментарии
Продолжить чтение

Постеры для разработчиков

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.