Изображение сайта media.licdn.com
Как утверждает венчурный инвестор и программист Лео Половетс, в сегодняшнем мире Saas, API и облачной инфраструктуры проработанная техническая составляющая редко становится причиной успеха или провала программного продукта. Современные технологии теперь позволяют разработать его очень быстро с минимальными затратами. Казалось бы, это как раз то, что нужно стартаперам.
По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации. Большинство провалов случается в результате неверного позиционирования продукта, отсутствия грамотной маркетинговой стратегии, плохих специалистов по продажам, неверной бизнес-модели. Наличие или отсутствие высококвалифицированных инженеров практически не играет никакой роли, делают вывод исследователи.
Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений. Зато очевидным преимуществом этих компаний является удачная бизнес-модель. Вкупе с активным продвижением, эти сервисы смогли стать одними из самых востребованных и дорогих стартапов мира. Но вряд ли они нанимали десятки инженеров, чтобы разработать сервис и подготовить его к запуску, сомневается Половетс.
Однако он признает, что есть компании со сложными технологиями, требующими тщательной и выверенной реализации: SpaceX, Zoox, Rigetti Quantum Computing. Но, по его мнению, эти исключения только подтверждают правило.
Высвободившиеся средства и ресурсы Половетс предлагает направить на исследование потребностей рынка и выбор подходящей бизнес-модели. Все это, конечно же, при условии, что для этого продукта существует целевая аудитория, которая еще и готова платить за него.
Это приводит нас к мысли, что с точки зрения бизнеса программное обеспечение, само по себе не является продуктом или услугой.
«Продукт — это не программное обеспечение, не сайт, не приложение, которое вы сделали. Продукт — это набор свойств, которые вы продаете потенциальному покупателю». Несколько примеров в качестве иллюстрации привел Аркадий Морейнис на лекции в Технопарке:
Пример номер один. Приходит письмо от программиста — он разрабатывает торговую площадку, на которой продавцы могут размещать свои товары: «Я программист, у меня проект уже практически готов, я уже сайт сделал, осталось только две мелочи — подскажите мне, как найти покупателей и продавцов. Все остальное уже сделано. Проект на 95% готов». Вот это как раз распространенная ошибка. Если ты не знаешь, откуда брать покупателей и продавцов, у тебя нет на руках продукта. У тебя на руках есть все что угодно, но только не продукт.
Второй пример. Одна и та же технология или техническая составляющая может быть разным продуктом, в зависимости от того, как ее подать. Например, блендер и мясорубка. Мы же понимаем, что с точки зрения инженера это одно и то же. Какая разница? Есть некий измельчитель, который вращается на оси внутри ёмкости, горизонтально или вертикально, измельченный продукт может выдавливаться наружу или оставаться внутри емкости. Но все же это два совершенно разных продукта. Они по-разному рекламируются, рассчитаны на разную целевую аудиторию. В качестве преимуществ выдвигаются абсолютно разные свойства. Поэтому то, что вы программируете или делаете руками, и то, что вы продаете — это как раз две абсолютно разные вещи. Продавать можно даже то, чего еще нет.
Однако уже несколько лет инвесторы упрекают стартаперов как раз в том, что они продают «воздух». На поверку оказывается, что продукт не готов, недоработан, не взлетел. При всех современных технологических возможностях далеко не всякое программное обеспечение можно сделать быстро, «без шума и пыли, не отходя от кассы».
Джон Эванс из HappyFunCorp обращает внимание на проблему качества продуктов, сделанных на скорую руку (Startup Software Quality Problem). Многие проекты разрабатываются под флагом Minimum Viable Product (MVP), что нередко создает стартаперам больше проблем, чем пользы.
«MVP (минимально жизнеспособный продукт) — простейший работающий прототип продукта, которым тестируют спрос до полномасштабной разработки. Такой подход страхует предпринимателя от невостребованности конечного продукта и потери потраченных на разработку ресурсов». (Словарь предпринимателя: MVP | Rusbase).
Дело в том, что после запуска стартаперы хотят быстро доработать программное обеспечение, исправить проблемы, возникшие в ходе его использования и учесть пожелания пользователей. Иногда предприниматели предпринимают решение о пивоте. В таком случае программному продукту грозят более серьезные изменения.
Но, как бы там ни было, разработчики вскоре понимают, что софт, сделанный на скорую руку, нуждается в серьезной переработке, а иногда – вообще не пригоден для дальнейшего развития и сопровождения. В таких случаях лучшим решением будет все переписать с нуля.
Эванс объясняет это плохо продуманной архитектурой и не менее бездарной реализацией. Программный продукт усеян багами, которые еще и непросто воспроизвести. В результате разработчикам приходится тратить в разы больше времени, чем они планировали.
Часто в подобной ситуации они пытаются больше работать, чтобы быстрее закончить исправления, но из-за этого допускают еще больше ошибок. Из этого замкнутого круга поможет выбраться только удача. При этом время идет, и спрос начинает падать. Это приводит к падению продаж и, что самое плохое, к падению интереса со стороны инвесторов.
При этом Эванс признает, что MVP не должен быть идеальным и хорошо «причесанным». Однако нужно найти баланс между стремлением пораньше выпустить продукт на рынок и созданием устойчивого спроса на продукт. Это даст возможность выиграть время на переработку софта. Иначе проект не сможет конкурировать с командами, которые работают качественнее, быстрее, либо имеют больше денег.
Однако, выходя на пустой рынок, стартаперы могут до поры до времени не беспокоиться о скорости развития продукта. Пользуясь положением первооткрывателя, легче добиться и коммерческого успеха.
К сожалению, не все предприниматели задумываются о подтверждении того, что их идея решает такие проблемы, которые важны для людей, и они захотят за это платить. Так что, предприниматель может в конечном итоге остановиться на идее, жизнеспособность которой подтверждена недостоверными комментариями пользователей либо предвзятыми мнениями создателей.
Если идея проекта действительно стоящая, то конкуренты обязательно появятся. А возможно, в игру включатся и крупные компании. С последними конкурировать на поле маркетинга бессмысленно, ведь обычно из возможности в этом плане, очевидно, намного шире. Тогда и выходит на первый план скорость и гибкость разработки, а также уникальность или сложность самой технологии, которая лежит в основе продукта.
Многие стартаперы любят называть свои продукты и технологии уникальными. Если сделать ставку на техническую составляющую, эти высказывания будут не просто рекламным ходом.
Эванс соглашается, что качество софта не гарантирует коммерческий успех. Роль этого фактора может быть различна от проекта к проекту. Однако, чем выше качество ПО, тем выше скорость развития проекта.
Еще один пример от Аркадия Морейниса – ситуация, когда роль ПО второстепенна:
У одной американской компании возникла идея, что они будут продавать людям наборы ингредиентов и рецепты сразу для готовки на неделю. То есть люди могут раз в неделю заказывать некое меню, получать с курьером уже нарезанные продукты и неделю из этого готовить. С чего бы начал среднестатистический олух в стартапе? С простого: он бы запрограммировал сайт с подбором рецептов по параметрам. А как поступили авторы идеи?
Они пошли в ближайший супермаркет и начали ловить тетушек. То есть они буквально подходили к тетушкам, которые ходили закупаться в этот супермаркет и говорили: «У нас есть сервис — за 9,95 долларов в неделю мы можем вам привозить продукты и рецепты на целую неделю готовки».
Они нашли первую тетушку, которая согласилась заплатить им $9,95. После этого они опять же не побежали программировать. Они начали подбирать рецепты, закупать товары, резать, раскладывать по мешочкам и каждую неделю приносить все это тетушке и выслушивать от нее всю обратную связь за прошлую неделю. И получать свои законные $9,95.
Параллельно они приставали к другим тетушкам. Они начали делать из этого какой-то сервис только в тот момент, когда перестали справляться с потоком тетушек. Они поняли, что нащупали тему, и людям это нужно. Вот это один из примеров, когда начинать можно и нужно, не делая полностью продукт.
Пример Netflix
Старт с продуктом в качестве услуги – с этого начинал свою деятельность Netfix.
Netflix появился на свет в Калифорнии, его основателями стали двое мужчин: Рид Хастингс и Марк Рэндольф. Хастингсу пришлось заплатить огромную неустойку за возвращение с опозданием фильма, который он брал напрокат. Именно тогда к нему пришла идея создать сервис, который позволит заказывать по электронной почте фильмы без штрафов за опоздания с их возвращением.
Сразу же после этого они начали давать напрокат друзьям коллекцию своих фильмов – так зародился Netfix. Это может показаться очевидным, но, если вы спросите большинство предпринимателей, как они начали бы свой собственный Netflix сегодня, вы получите очень подробные технологические ответы.
Для стартапа жизненно важно создать продукт, который действительно нужен людям. Как уже говорилось, продукт – это не только софт. Но если стартап построен вокруг какого-то программного обеспечения, то даже при изначально высоком спросе проект может сойти на нет из-за проблем с ПО.
Комментарии (39)
Zavtramen
31.07.2016 22:18Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений
Может статья и хорошая, но дальше читать не стал.
sentyaev
01.08.2016 03:15Поддержу. Uber и Airbnb это ж как два пальца…
voidnugget
01.08.2016 03:54Да, вот только в 80% проектов с eslint'ом и jscs используется пресет AirBnB, в плане контроля качества они очень сильно преуспели из-за своего фейла с backbone… но это уже совсем другая история.
Вот решения uber'a в плане QA не особо, да и сейчас из-за этого наблюдается плавный переход с node.js на java/go, их существующие решения очень сильно уступают по качеству тому же netflix'у.
Captcha
01.08.2016 09:43Что за фэйл с Бэкбон? Можно поподробнее?
voidnugget
01.08.2016 10:17Начинали они с backbone, и переписывали пару раз из-за подтеканий и криворукости разработчиков. Оно переодически отваливалось… потом был вариант вообще без SPA, но он медленно и уверенно был портирован на React. В процессе портирования был разработан ряд подходов к контролю качества, учитывая предыдущий печальный опыт с backbone. В итоге допиливать и поддерживать решение на react'e получилось в ~6 раз дешевле, а по объёму кода оно было почти в 2 раза меньше первоначального.
Zavtramen
01.08.2016 22:05Как в бэкбоне может что-то подтекать? Расскажите, мне действительно интересно. Там кода мышка наплакала, в котором разобраться и поправить если что нет так займет полчаса-час. Бэкбоне предоставляет только каркас по сути и базовые вещи типа роутинга и моделей. Честно не знаю где там что-то может течь.
voidnugget
01.08.2016 22:24Пример: частенько получается так что есть вложенные вьюшки, родительская внезапно удаляется, и вместо неё создаётся новая с таким же, или большим, количеством потомков, и так с довольно высокой частотой — GC просто не успеет собрать мусор. Да и если с одной вьюшки удалить родительскую другой вьюшки — тоже потечёт. Даже банальный jQuery UI в далёком 2009ом из-за криворукости мог довольно сильно подтекать ...
В своё время для предотвращения выстрелов в ногу был придуман Marionette, но и на нём можно косячить без разбору. Вот, в большинстве случаев, оно так и получается.
Zavtramen
01.08.2016 23:05Пример: частенько получается так что есть вложенные вьюшки, родительская внезапно удаляется, и вместо неё создаётся новая с таким же, или большим, количеством потомков, и так с довольно высокой частотой — GC просто не успеет собрать мусор.
Вьюшки надо удалять каскадом, каждый родитель должен уметь удалять созданные им вьюхи. Бекбон сам этого не делает и никогда не обещал этого делать. Это криворукость разработчиков, бэкбон тут ни при чем. Пишешь вьюху — всегда делай в ней destroy метод. Создаешь вложенные вьюхи — удаляй их при дестрое. Подписываешься на события — отписывайся при дестрое. Бэкбон никогда не обещал делать этого за разраба, тем он и ценен, 100% гибкость решений, но надо все аккуратно кодить. Это не плохо и не хорошо, просто вот такая у него ниша.voidnugget
01.08.2016 23:12Проще взять любой более зрелый фреймворк типа Angular2 / React / Ember и не заморачиваться с этим boilerplate'ом, что собственно и сделала AirBnB в своё время. Там тоже возможны утечки из-за криворукости, но и вероятность накосячить будет на много меньше.
Zavtramen
01.08.2016 23:21Все зависит от задачи. При использовании Backbone и подобных мы делаем то, что мы хотим, а при использовании Angular2 / React / Ember мы делаем то, что нам разрешают сделать. Но холивар устраивать не стоит, это мое личное мнение.
sentyaev
01.08.2016 23:35Про зрелость Angular2 вы конечно загнули)
Пол года пишем на нем приложение, и за это время у Angular2 уже третья реализация роутинга, и вторая форм. Плюс куча breaking changes, учитывая то, что с конца мая это уже как бы RC.
Angular2 конечно хорош, но зрелым я бы его не назвал.voidnugget
01.08.2016 23:50Использую уже более года, на ES6. Без тестов ничего не выкатываю из-за этих проблем обратной совместимости, но я не считаю что изменения API в бете слишком уж значительны. В плане архитектуры в бете уже ничего значительно меняться не будет.
sentyaev
01.08.2016 23:57Эм, как минимум будет другой роутинг, принципиально другой.
И, как я уже говорил, сменили дизайн апи форм.
В rc5 вроде модули появятся.
Ну и так, уже всетаки не бета.
Я же говорю, что он не зрелый, т.к. ребята до сих пор не определились с окончательным дизайном фреймворка.
voidnugget
01.08.2016 03:49+2Был в пачке сфейляных американских стартапов, работал с airbnb soundcloud uber cloudflare netflix akamai ...
Могу подтвердить что действительно наукоёмкими задачами и оптимальными решениями никто не заморачивается, даже с учётом всех сверхоптимистических ожиданий о росте продукта, получается так что после релиза выходит куча хлама. Опосля, если разработчики успевают допилить этот "Минимально-Нежизнеспособный Продукт", что бы он мог расти и масштабироваться без ущерба для UX, и способны применить QoE практики, то и росту спроса можно соответствовать. В противном случае наблюдается острое недовольство клиентов и различные "параноидальные фьючеризмы" "грибной менеджмент" "говноштормы" "кластерфаки" ...
С психологической точки зрения, со старту самого проекта, можно наблюдать ряд распространённых когнитивных искажений из-за потребности веры в иллюзорные перспективы успеха… "Ореолы" "Бумеранги" и проч. А в попытках объяснения и предложений о принятии дальнейшего решения дальше "Проекций" и "Актуализации" дело не доходит.
В общем банальные амбиции и лень затмевают взор…
Вместо того что бы мерить и принимать решение, люди верят в иллюзорные перспективы абстрактного успеха.
dmitry_ch
31.07.2016 22:29Увы, но вывод каков — писать сразу все серьезно и спланировано на всех возможные варианты развития?
Точка «ой, у нас все плохо, мы этого не закладывали в архитектуру» всегда будет, вопрос, как ее встретить и что с ней делать. Бежать с нуля переписывать — отличный вариант, только надо не забывать о поддержании старой версии.
А с Netflix-ом я лично не знал, что начинали они с пиратской раздачи видео всем друзьям )))
sbnur
31.07.2016 23:02+3Да — в основе любого бизнеса лежит простая идея — уговорить некую условную тетушку купитьза $10 нечто, о чем она 5 мин назад и не подозревала.
Если число тетушек растет с течением времени, то бизнес удачен, иначе это просто разводка
PavelMSTU
01.08.2016 13:59Как говорил один мой знакомый циничный предприниматель
Есть два способа продать ПО:
- соблазнить;
- напугать.
KroTozeR
31.07.2016 23:55+4Печально, что менеджмент превалирует над техническим процессом. Понимаю, «белые воротнички» хотят покупать лексусы и катать гламурных див на дискотеки с мохито… Только какое отношение всё это имеет к производству программного продукта? Вопреки мнению автора, производство – это написание и отладка программного кода. Именно это и является продуктом, а остальное – не более чем схема его реализации. И сколь бы она не влияла на продажи, она не должна оказывать влияния на программистов, т.к. от симбиоза программиста и менеджера появляются недопрограммисты-недоменеджеры. Каждый должен заниматься своим делом. И хорошо бы эти кухни окончательно разделить. Нужен продукт? Заказывайте его разработку. А что до рисков… Ну вы же сами хотели капитализм? Получите, распишитесь! Только не надо скулить о том, что «весь мир так живёт». Уже давно пора наплевать на весь мир и жить своими реалиями, которые требуют весьма жёсткого и принципиального планирования, не считающегося с рыночными «реалиями» никак.
sentyaev
01.08.2016 03:31+1Продукт — это товар или услуга, которую можно предложить для рынка, и которая будет удовлетворять потребности потребителей. Ваш КО.
Вопреки мнению автора, производство – это написание и отладка программного кода.
Получается, чтобы начать производство, вам нужен продукт, и продаете вы именно продукт.
И хорошо бы эти кухни окончательно разделить.
Многие годы люди пытаются их как-раз соединить, отсюда появляются скрамы, канбаны и остальные аджаил-методологии, да и само понятие аджаил, как раз про это.
Вопреки мнению автора, производство – это написание и отладка программного кода.
Это всего лишь процесс.
— Куда мне отсюда идти?
— А куда ты хочешь попасть?
— А мне все равно, только бы попасть куда-нибудь.
— Тогда все равно куда идти. Куда-нибудь ты обязательно попадешь.
Voltera
01.08.2016 12:48+1В проектной деятельности код стоит на последнем месте, основной критерий это соответствие требованию заказчика, а с точки зрения кода оно абсолютно невзыскательное. Заказчик пишет ТЗ в стиле: «Нужен импорт данных из такой то системы», «Аналитика по таким то объектам», «Сбор данных из контроллера».
Проектный менеджер в такой ситуации — царь и бог, а остальные просто действуют под его указку, захочет сменит всю команду, главное добиться тех основных требований, что указаны в ТЗ. Дальнейшие баги и проблемы, являются лишь пунктом поддержки данного решения.
Для SaaS решений обратный подход.
i86com
01.08.2016 12:49+1«Печально, что менеджмент превалирует над техническим процессом.»
Единственный способ превалирования технического процесса — работать на себя. Бесплатно. Либо проинвестировать компанию из своего кошелька.
Не получится вот так просто придти в компанию, и сказать «платите мне среднюю месячную зарплату по стране каждую неделю, а я буду сам решать, будет релиз продукта в этом году или нет».
«Вопреки мнению автора, производство – это написание и отладка программного кода. Именно это и является продуктом, а остальное – не более чем схема его реализации.»
Зависит от бизнеса. В большинстве стартапов, даже чисто технологических это совсем не так. Часто продуктом являются просмотры пользователей, которые продаются рекламодателям. А пользователей ведёт маркетинг, а не качество реализации (см. фейсбук, ранние дни твиттера (картинка с китом)).
Но даже в тех компаниях, где качество продукта чего-то стоит, менеджмент и маркетинг не являются лишь «обслуживающим персоналом единственных работающих людей — программистов». Они выполняют работы и принимают решения, в основном стремясь к тому, чтобы компания выжила, а не ради соблюдения «ритуала техпроцесса».
«А что до рисков… Ну вы же сами хотели капитализм? Получите, распишитесь!»
Предположим, вам предложили работать в компании за процент от прибыли. Компания получила большую прибыль — вы получаете миллионы. Компания понесла убытки — вам нужно продать квартиру и взять кредит, чтобы их покрыть. Вышла в ноль — все остаются при своих. Вы бы хотели такой капитализм?
Это естественно, что люди, берущие на себя риск, стараются его минимизировать. И инвесторы тут не исключение — потому им и нужно сначала убедиться, что «криво, быстро и на коленке» — хоть немного работает.
«Уже давно пора наплевать на весь мир и жить своими реалиями, которые требуют весьма жёсткого и принципиального планирования, не считающегося с рыночными «реалиями» никак.»
Вся статья выше как раз о том, реалии не требуют жёсткого и принципиального планирования. Реалии требуют гибкости и скорости.
Не поймите меня неправильно, я бы тоже был рад если бы все эти «жадные» инвесторы перестали уже трястись над своими деньгами, перестраховываясь и ожидая возврата, а просто раздавали бы их стартапам для развлечения.
«А давайте три года делать сервис с геолокацией, вот миллион, как закончится — просите ещё.»
«Надоела геолокация? Проект ещё не успели в третий раз переписать перед запуском, а конкуренты уже заняли весь рынок? Ну ладно, зато как хорошо посидели. Вот ещё миллион, давайте теперь big data поковыряем.»
Но так уж лучше было бы помечтать, что мне просто в карман деньги сразу положат, без всей этой имитации бурной деятельности.
Jef239
01.08.2016 12:49+2Ну произвели вы чугунную рельсу. Ну есть у вас 3 квадратных километра складов, забитых рельсами. И что дальше? Никому вы из не продадите, все хотят стальные.
Производство — лишь малая часть работы. Равно как и беготня по клиентам с просьбами купить вашу рельсу, то есть продажи.
А в основе… в основе менеджмент. Бизнес-идея. Удовлетворения потребностей заказчиков. Ну скажем чугунная рельса, по которой поезд едет тихо.
Так что в идеале — программер должен понимать, зачем он делает ту или иную фичу, что она дает при маркетинге. А если программер не понимает ЦЕЛИ написания кода, не понимает, какие характеристики кода важны, а какие нет — хреновый получается код.
При выборе между памятью и скоростью, между универсальностью и эффективность, между отлаженностью и скоростью разработки, важнее всего понимать маркетинг.
P.S. Я как раз программер, а не маркетолог. Но я хочу, чтобы наши изделия продавались, а не писать свой код «в стол».
vlad72
01.08.2016 04:55Статья кидает из крайности в крайность, но как тема к размышлению — хороша.
По поводу MVP — путается прототип для тестирования спроса и 1-я версия уже добротно сваянного продукта (тоже с с минимум необходимых функций).
evalexdy
01.08.2016 08:23Так это ж классика: «good marketing and sales always beat great technology» (хороший маркетинг и продажи всегда победят отличную технологию).
voidnugget
01.08.2016 10:23Прям "Перспективный маркетинг бесперспективных продуктов" решает все проблемы бизнеса...
Вы уверены что "хороший маркетинг" должен бороться с "отличной технологией"?
Может он в результате пытается бороться с отлаженным и жизнеспособным процессом разработки в угоду иллюзорной прибыли в краткосрочных перспективах ?turbopower
07.08.2016 02:00речь о конкурентной борьбе, а не о двух ветвях внутри одной компании
10.000 дорогостоящих высокоточных самонаводящихся ракет против миллиарда дешевых, хитрых и окопавшихся пехотинцев?
Sinatr
01.08.2016 12:48+3По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации
Простите, а где там такое написано? Друг интересуется, я было обрадовался, смотри мол, пофиг на твой левел, главное — маркетинг. А по ссылке какой-то мутный перечень, без сводки. Запросил там отчет, получил сводку. В ней тоже нет 5%.
Поэтому резонный вопрос, откуда взята цифра? От верблюда?
OlegGelezcov
01.08.2016 12:50По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации. Большинство провалов случается в результате неверного позиционирования продукта, отсутствия грамотной маркетинговой стратегии, плохих специалистов по продажам, неверной бизнес-модели. Наличие или отсутствие высококвалифицированных инженеров практически не играет никакой роли, делают вывод исследователи.
Ну все верно, обычно я исхожу из того, что на успех проекта инженерная составляющая влияет примерно на 30%, но время идет, создается больше удобных инструментов, фактически продукты производить легче и роль инженеров-программистов в успехе продукта постоянно падает.turbopower
07.08.2016 02:05я всё удивляюсь, при таком количестве заготовок кода в базах гугла и гитхабов, где нейросеть-программист, которая предложит лучший по качеству код, сама его реплицирует и заставит самосовершенствоваться?
по сути, стиральная машинка, девальвировавшая ценность труда прачки.
и все эти годы учебы программированию следующим поколением землян будут восприниматься как архаичная и бесполезная трата времени, вроде просмотра тв. если нейросеть-программист оставит землян в живых.
xFuzzer
01.08.2016 12:50«Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений.»
Да ладно не увидим?
Uber Engineering Blog:https://eng.uber.com/voidnugget
01.08.2016 13:09+1Пост #1 о том как Uber слез с PostgreSQL 9.2 на новый мускуль, плакаются что репликации нет и хранилище не эффективное — ну конечно, сидеть на ископаемой винрарщине и плакаться на MVCC, мягко говоря, не серьёзно.
Пост #2 о том как хорошо интернам в Убере менять мир к лучшему, т.е. вброс.
Пост #3 о том как они используют PCA (метод главных компонент) для предотвращения фрода.PCA, Карл! PCA против мошенничества.
Пост #4 о том как они сглаживают ускорения логистической регрессией, т.е. тролейбус с батона.
Пост #5 про абстрактный деплой микросервисов в вакууме, без консенсусов, CRDT и прочих умных штук, просто потому что они магическим образом могут без этой заумной ерунды обойтись.
Прям очень таки познавательные, наукоёмкие и высокотехнологические статьи...
aquamakc
01.08.2016 13:14+5Всю статью можно свести к одной фразе:
Лучше сначала надо что-то продать, а потом начать разрабатывать, чем сначала разработать, а потом пытаться продать.turbopower
07.08.2016 02:11это же классическая история про двух программистов, когда один пилил продукт несколько лет до идеала, а второй каждые полгода сыровяленную требуху апдейтил. когда первый свой продукт явил миру, оказалось, что он никому не нужен.
ибо: у всех стоит продукт второго программиста, им нравится, что он постоянно обновляется и поддерживается, а главное — в нем уже появилось то новое, что в «идеальный продукт» первого не вкрячишь никак — только заново писать всё.
финита.
//это было краткое содержание статьи методом «притчи»
potan
01.08.2016 13:20К сожалению, выигрывает тот, кто первый вышел на рынок. По этому метод разработки «хуяк-хуяк и в продакшен» всегда будет самым востребованным, несмотря на высокие риски. Есть слабая надежда на хорошие статически типизированные языки, типа Haskell или Rust, но что бы их применение не замедляло разработку, требуются очень опытные программисты.
ZapevalovAnton
Спасибо за статью