Comments 257
Например, на последней работе я сделал прототип проекта за сутки — и это 60% всей работы, нужной для выхода на рынок
Ну так сделайте, что мешает?
Будете делать коммерческий продукт и поймете, что кодинг, дай бог 30% от всей работы по выходу продукта на рынок и оставшиеся 40% работы кодинга съедят как минимум в 10 раз больше времени.
1) Июль 2016 года — «да тут только пару ошибок исправить, это недели две, и еще пара недель на вот эти фичи».
Июль 2018 — *спустя 2 полных переписывания модуля и множество изменений архитектуры и процессов* — «проект готов на 95%».
2) Сентябрь 2019 года — «да тут надо немного исправить, вы как раз из отпуска вернетесь, а уже все готово»
Сентябрь 2020 — *твою ж мать, опять*.
Раз на десятый эти классы можно с закрытыми глазами писать с минимальными изменениями под конкретный проект.
А потом комбинировать, в разы проще, а то основные проблемы это как бы pixel-perfect сделать и кнопочку с анимацией. Нахрен не надо этого. Но Стив Джобс создал армию тех кто хочет (или претендует) чтобы быть Стив Джобсом. Дизайн это главное.
Я может ошибаюсь(вскользь читал про него лет N назад, когда он умер), но по-моему как раз он и протолкнул все эти Guidebook-и для разработчиков у яблоков, в которых описывается как желательно делать интерфейс в приложениях, использовать максимум стандартное, чтобы GUI был у всех похож и пользователю было с ходу привычно пользоваться любым приложением, а все лишнее кастомное всячески порицается.
Кто втащил входную дверь наверх??»
Вы не поняли суть — наличие крутой картинки не привлечёт толпы покупателей. А как раз таки неудачно (специально, или случайно, не важно) подобранная картинка (видео) обрушит продажи (см. примеры бойкотирования брендов в Китае/Японии после несуразных рекламных роликов).
То есть «магия дизайна» в софте/вэбе не имеет обратной силы. В вашем примере, если бы была установленная мега крутая картинка/фотка/видео/etc это бы не привело к скачку продаж на 30k за три дня.
Может ну его нафиг так рисковать, а просто делать хороший продукт без этих ваших свистоперделок?
PS Я до сих пор недоумеваю с окошек настроек аудикодеков и прочие редкоиспользуемых приблуд по настройке железа — там такие вырвиглаз и кособокие кнопки и крутилки рисуют вчерашние студенты, что даже курсором мышки не хочется к этому приближаться, а двигать/нажимать этот кусок «красоты» вообще страшно.
PPS помню даже встречал задизайнерные окна перепрошивальщиков боиса мамок.
PPPS А видеоплееры припроетарные? Как ни версия, так новый дизайн и все кнопки перемешаны. Самый эпик — это в Windows Media Player после очередного редизайна убили связь «пробел» = пауза. Тыкай мышкой в кнопку! Вот это просто финиш! После этого хочется взять биту и идти убивать!
Насчёт видео плееров очень согласен и в первую очередь в голову приходит Телеграм. Ну вот выработаны же уже стандартные кнопки для плееров. Влево-вправо — перемотка, вверх-вниз — громкость, пробел — пауза. Тут работает только пауза. Нажимаешь вправо — перекидывает на следующее видео. В Youtube вроде бы получше, но тоже косяк. Если ткнул мышкой в прогрессбар, он считает его активным и кнопки вверх-вниз работают уже как перемотка, а не как громкость. Ну вот зачем?
Здрасте, не привело бы. Не знаю как во всем мире, но в мобилках (игры/приложения) очень даже привело бы.
Вот и сидит 100500 команд, пилят свои стайлгайды и юайкиты под них: д
* — помогаю коллегам, обратившимся за помощью, на протяжении нескольких лет делал это уже раз 50+, каждый очередной раз взбадриваюсь, что есть какой-то неочевидный момент, а все равно спотыкаюсь.
** — причем это не нюанс локализации, в английском интерфейсе это кнопка <-Other Network
Давно убедился в мысли что стандартизация это благо. Стандартный UI, стандартизировать основные классы, схемы таблиц и т.п.
Девелоперы — такие лицемеры.
Ратуют за виндовый блокнот для юзеров, а сами юзают IDE с автокомплитом, кодеджампом и автоматическим рефакторингом.
Забыли основное кредо программиста — экономить время юзера?
Наша задача — сделать труд юзера эффективным, а не строить его, превращая в солдата.
А для этого иногда надо потрудиться и понять, что выпадающий список — это 2 и более клика мышки, а плашка с горизонтальными кейсами — один.
Ратуют за виндовый блокнот для юзеров, а сами юзают IDE с автокомплитом, кодеджампом и автоматическим рефакторингом.Простите, а где тут «за блокнот». IDE-то как раз и состоят из стандартизированных компонентов, причём не только внешне, но и функционально. Просто стандартизированы они с умом, людьми понимающими, что и для чего они делают.
Не всегда с умом, к сожалению. Пример:
Новомодный рибон в МС продуктах. Для кого-то очень удобно, для кого-то нет, но есть один нюанс: мониторы сейчас растут больше в ширь, чем в ввысь. А эти затейники отъели не таясь часть дефицитного вертикального пространства. Тогда как боковики совсем не используются и зачастую пустуют. Я пару раз подумывал — не поставить ли мне монитор на попа, вертикально.
Новомодный рибон в МС продуктах.
Новомодный? Ему почти 15 лет...
То, что у вас боковики в ворде не используются, не значит, что у остальных так же.
2) Однако поинтересуюсь — как в этой концепции организовать интерфейс для выбора цвета границы? Для каждого типа линии в каждой отдельной плашке сделать раскрывающееся меню с палитрой?
Я делал нечто вроде:
Но думаю цвет для каждой рамки — избыточен. А вот толщина — да, необходима.
Цвета расположены хаотично.
Бери и меняй как хочешь…
https://github.com/trdm/unnstudioreport/blob/master/Report/uoColorChooser.cpp
пс. Будете так продолжать, придется отряхнуть пыль с проекта...
А… сорри! Да — так уже хорошо. Заставлять юзера лезть в текст программы и перекомпилировать проект — необоснованная жестокость.
Но вообще говоря заставлять думать программиста о юзабилити — тоже излишне.
Пользоваться программой же не он будет скорее всего. Дизайн должен рисовать специальный человек который хорошо знает, что нужно юзеру.
Мне как-то программист принес программу — я стал смотреть, а там… местами вместо трех кликов достаточно двух, вместо двух — одного, вместо восьми — трех, и т.п… плюс нестандартные сочетания клавиш. А работать с этой программой людям по восемь часов в день. У меня как-то была статья, я там жаловался на интерфейс разных программ. А сам как-то писал утилитку для генерации конфигурационных файлов — так интерфейс рисовал (на листике) две недели.
Так-то так, да вот только поддерживать эти стандартны не всегда легко. Стандартизация хороша, когда у вас уже есть много готовых компонент, и их можно немного подпилить, чтоб они друг к другу подходили. А вот сделать сразу хороший стандарт, который будет вам служить хотя бы несколько релизов — штука возможная, но рискованная. Весь мой опыт говорит в пользу того, что нельзя просто посидеть, подумать и сразу придумать правильно. Надо пробовать, экспериментировать и быть готовым, что придется все переделать.
А в индустриальную разработку пусть играют индустриальные гиганты — у них это отбивается.Золотые слова. С текущими зарплатами «инженеров» почти никакая разработка, кроме той, что делается на ОЧЕНЬ большую аудиторию или проедает венчурные-пофиг-сколько-их-деньги, не отобьется. Удел большинства проектов — легкий серверный скриптинг на php и дизайн за 30 тыс рублей, и его бы хватило для 90% проектов.
Кроме php бывают еще и задачи на производстве, например раскрытие заказов по спецификациям. Это раньше были альбомы с чертежами, одну сборку пропустишь — все, ее не сделали, и меняй работу. Это еще на машинах СМ было. Потом тоже самое на Unix. Это называется "Заводской программист". Программа идет только в комплекте с программистом. Один человек, постепенное усложнение задачи, и ничего лишнего.
Есть много окупающихся узконишевых проектов со своей разработкой. Правда, там зачастую профессиональные продукты, а один про-клиент приносит денег как тысяча обычных потребителей.
Просто хочу сказать — спасибо.
Первые 80%. После которых будут вторые 80% и доводка — ещё процентов 40-50.
Как бы даже не 3-5%…
У афтора исходной статьи впереди ещё много чудных открытий…
27 лет моего опыта разработки говорят о том, что если в проекте больше 10 программистов, то производительность труда катастрофически падает.
Правда, проекты бывают разные.
Я свой делал более шести лет. А потом переход на другую платформу.
видал в одной конторе такое, «нам это не нужно, работаем без этого бреда»… а потом увольняется начальник разработки-тимлид(по совместительству)… и команда из 10 человек остается около репозитория на пару миллионов строк кода, от перла до си, без единой строчки документации «ведь ясно же что код-самая лучшая документация» (с), с ТЗ в виде папки с вордовскими файлами, с деплоем «ну мы вручную тут war файлики подкладываем, а там на серваке reset жмем потому что перезапуск почемуто не работает… прод конечно останавливается, но ЭТО НОРМАЛЬНО»
И вот тогда понимаешь, что все эти новомодные фичи нужны в том числе чтобы уменьшить эффект автобуса и структурировать происходящее.
но я согласен что иногда надо быстро-быстро наваять MVP, и если дело пойдёт. то надо бегом структурировать разработку, потому что всё потом утонет в бардаке самопального беклога и неорганизованной дичью
Также игнорирование типовых паттернов отрасли — негативно влияет на саморазвитие разработчиков и отпугивает их (у меня нынешняя работа такая, топим за минимализм, неважно что интеграция любых фич требует адского рефакторинга, важно что нам сейчас это не нужно — не делаем, будет нужно — сделаем, в итоге любое фичепиление занимает по один — два месяца с переписыванием тонн кода потому что «это было не нужно, мы это не предусматривали»)
нам сейчас это не нужно — не делаем, будет нужно — сделаем, в итоге любое фичепиление занимает по один — два месяца с переписыванием тонн кода потому что «это было не нужно, мы это не предусматривали»
Странно. У меня нога такая же, но не болит.
Но ведь когда ларёк превращается в Amazon — ему всё равно не нужны склады по всей стране, как Amazon, по крайней мере, сразу.
Сначала стоит построить или даже взять в аренду 1 небольшой склад и посмотреть, что будет с деньгами, людьми и бизнес-процессами, если попрёт — развиваться дальше.
А то приходят люди и говорят — "у нас тут бигдата, целых 20гб, а к концу года все 50гб будет! Прикиньте нам архитектуру основного озера данных, резервного, etl, резервного копирования, мониторинга и шифрование поверх всего, заодно и интеграцию со всеми системами, правда, мы ещё не придумали, с какими"
Идея хорошая, но на этом этапе никто не понимает, зачем столько, кто и как будет работать с данными и какие результаты хочет получить, и честно говоря, на этом этапе полезее всего был бы 1 хороший аналитик с хорошим ноутбуком — оценить сценарии использования и показать результат и потом уже решать — нужны ли кластера и если да — то какие.
А пока — культ карго в it становится всё сильнее: задачи "как в гугле" для приёма джунов и петабайтные кластеры для данных, что влезут на современный телефон.
то вполне себе биг дата для ларька.
Биг дата это все-таки то что физически не может поместиться на один сервер, а тут хватить одного ноута или VPS за 10$/месяц. Поэтому многие методы для бигдаты (всякие Hadoop кластеры) там будут просто забивание гвоздей микроскопом.
PS Единственный случай, когда такие закупки с запасом оправданы — крупные компании, у которых для покупки хоть чего нужно пройти 6 уровней согласования, архитектурный комитет, безопасников, коммерческий комитет, 3 раза защитить проект и при любых правках ждать следующий сбор комитета через пару месяцев и уж когда выделяют деньги — их нужно срочно тратить, пока финансовый год не закончился.
Если MVP нельзя сделать быстро, то структуру лучше закладывать сразу, хотя бы частично и в ручном режиме и уже потом развивать и её тоже.
Тот же маленький интернет-магазин можно даже в ВК и инстаграме организовать, для этого не нужно ни микросервисов, ни девопса
тут все проще, для маленького интернет-магазина вообще программисты не нужны как таковые… достаточно в любой типовой картинок налить и оплаты подцепить один раз а вот эта идея «мы сделаем свой велосипед» и «нам обязательно нужны кастомизации» — это всё в ту-же тему о чем и основная тема статьи
Их статьи есть на хабре.
ИТ система это долгосрочная инвестиция, особенно применительно к классическому бизнесу и сама по себе не дает роста прибыли чтобы «быстро стать амазоном»… а вот бабла жрет немеряно
p.s. могу ошибаться конечно. но уж больно красивая история чтобы быть правдой, я видел как устроен и работает ресторанный бизнес и чудес там не бывает даже если очень хотеть
Так что успех сомнительный.
Как насчёт такого критерия успеха: имеется ли хотя бы один ресторан Додо-пиццы в каждом городе мира, из числа тех городов, в которых уже есть хотя бы один ресторан Макдональдса?
Давайте возьмём Макдональдс в качестве примера успешной франшизы из области общепита.
Додо-пицца позиционирует себя как IT компанию, поэтому логичней сравнивать ее хотя бы с JetBrains, касперским, яндексом, мейлру, а не каким-то там общепитным Макдональдсом :)
А что будет объективным показателем успеха?Финансовые показатели.
Как насчёт такого критерия успеха: имеется ли хотя бы один ресторан Додо-пиццы в каждом городе мира, из числа тех городов, в которых уже есть хотя бы один ресторан Макдональдса?По такому критерию нет вообще ни одной успешной фастфуд франшизы, кроме самого Макдональдса. Но вам же не придёт в голову назвать успех KFC «сомнительным», несмотря на то, что у него вдвое меньше точек.
Успех там очень сомнительный, и им до гугла-амазона как до луны.
Только вот додопицца со своим пафосом и неумелой маркетинговой стратегией (они нанимают 250 разработчиков) ведут себя так, как будто они гугл и какая-то крутая айти-компания, хотя по факту их основная деятельность — это продажа пиццы.
Успех там вполне ощутимый
далеко не факт что успех там благодаря ИТ технологиям, а не маркетингу и вливанием миллионов в рекламу
Потому что блог додопиццы на хабре и образ типа-ит-конторы — это тоже реклама-пиар, и часть программистов пойдут туда, а не кудато еще. и возможно это играет большую роль чем какаято инфосистема по заказу пиццы
если сравнивать с какой-нгибудь другой шаурмечной из сыктывкара
А в этом и странность успеха, о которой они не говорят.
Чтобы шаурмячная из сыктывкара смогла стать такойже, ей надо бахнуть в развитие пару десятков лямов… но при типичном заработке шаурмячной (далеко не миллионы в месяц) это практически невозможно… тоесть просвечивает классическая схема «я стал миллионером так — я вырастил поле из зернышка пшеницы и продал его… а потом у меня умер дядя и оставил наследство» (чисто imho, я не знаю подробностей)
Достаточно показать смету расходов на все это добро у Амазона (ну или хотя бы приблизительно посчитать число инженеров и их зарплаты). Мозг включится моментально.
Я вот что-то не разу не видел, проект уровня ларька, где не были бы микросервисы, devops, нормальный процесс разработки. Зато я видел достаточно большие проекты, где всего этого нет. И скорее всего, человек, так рассуждающий, не видит целой картины и пилит одну свою кнопку. Ну либо на проекте тимлид/арх глупый, но такого я тоже не встречал.
Плох тот ларек, что не мечтает стать Амазоном. Ну или хотя бы продаться Амазону. Ну или хотя бы кому-нибудь за хорошие деньги. И тут "все эти штуки" начинают генерить дополнительную ценность для покупателя, а то и создают ее с нуля.
Ну не пали контору, кому плохо от того, что мы делаем скворечники, используя для этого инструменты для построения авианосцев?
Если бы меня кто-то спросил, за сколько можно сделать такое приложение в одиночку — я бы сказал: «два месяца на разработку, один на тестирование». Но нас было много, поэтому мы работали больше двух лет.Жизненно, но зависит от величины проекта.
Сотрудничаем с одной московской студией, у них в штате около 20 прогеров, но когда у них перегруз — в режиме прокси хайрят со стороны относительно постоянных фрилансеров по относительно мелким проектам. Да, в них фрил со стороны за 2 месяца действительно может сделать то, что штатных трое прогеров делают полгода. Но на проектах которые штатные трое прогеров делают год такое соотношение уже не работает, будут делать одинаково. А на реально больших проектах — от 5 человек и от 2 лет — фрилансеру ловить нечего в принципе, он будет десятилетиями это пилить и не закончит в принципе никогда, т.к. надо будет еще и под свежий стэк переписывать сделанное.
"Я могу зафигачить целое приложение за месяц." Вы сделали хоть одно такое, которым пользуетесь не только вы?!
Проблема или смысл команды — одна голова хорошо, а две лучше. Нужно создавать не приложение, а уют прежде всего, чтобы потребитель чувствовал себя посетителем. Также не мало важно — накормить как можно больше людей, которые хотят работать даже за гроши. Два полупроффесионала сделают проект лучше чем один профи ИМХО.
Ваша теория хороша для кулаков, которых, как говорит история, в конце концов раскулачат.
Справедливости ради, нужно сказать, что и у гигантов тоже не отбивается. Если считать по-честному. Все известные сегодня гиганты (Google, Facebook, Amazon) поднялись в своё время за счёт краха пузыря доткомов. Сначала миллион доткомов высосал из других отраслей триллиард инвестиций. А затем сегодняшние гиганты за гроши скупили всё полезное у тех, кто не пережил пузырь. Потом гиганты ещё набрали и освоили кучу кредитов, которые они до сих пор не отдали, а просто обслуживают, погашая проценты. И только без учёта всего этого можно считать, что у них есть прибыль.
Это как если бы РЖД появилась с нулевым балансом в мире, где уже построены все железные дороги, а депо забиты поездами. Но всё это никому не нужно и продаётся с молотка за символический $1, потому что до этого весь мир несколько лет думал, что у каждого должен быть свой поезд и своя железнодорожная ветка. РЖД нужно было бы только нанять машинистов и организовать продажу билетов. Ну, ещё топливо и энергию покупать. А всё остальное — это прибыль.
по этому «скупили по дешевке» — не работает. Тут можно вспомнить что гугл купил Android inc, однако от оригинальной Android осталось только название, гугл успел в начале даже сменить концепцию ОС.
А вот купить обанкротившуюся ЖД компанию — это другое, это настоящая инфраструктура «в железе», живые «вечные» контракты на перевозку полезных ископаемых и «базовых» грузов, вроде щебня или стали.
В IT тоже есть железная инфраструктура. Магистральное оптоволокно не само собой повсюду проложилось. И сервера в датацентрах не сами собой наросли вокруг больших данных. Это всё было построено в основном во время пузыря. Этим занимались B2B-компании, которые привлекали инвестиции от тех, кто хотел перейти из более традиционных видов бизнеса в IT. Предполагалось, что всё отобьётся, когда у каждой собаки будет свой веб-сайт. А аналог контрактов на перевозку — это патенты. Современные IT-продукты состоят из патентов чуть менее, чем полностью.
Может и так. Но что это меняет? Деньги в эту инфраструктуру вложены бешеные. IT-гиганты её каким-то образом эксплуатируют. Возможно, даже не напрямую, а косвенно. Без развитой IT-инфраструктуры у их сервисов не было бы столько потребителей. При этом соответствующие капитальные затраты нигде толком не отражены. Какая разница, владеют они этой инфраструктурой сами или арендуют её у подрядчиков? Подрядчики ведь тоже не платили за неё полную стоимость, а купили за доллар у банкротов. Они и арендные платежи взимают, исходя из того, что капитальных затрат у них почти не было.
если так аналогию проводить, то никто ничего не добился сам, а вероломно используют достижения питекантропа изобревшего колесо и палку-копалку
Да, и об этом тоже нужно помнить. Amazon так ловко и дёшево развозит посылки по всей стране отнюдь не потому, что Безос по-честному вложился и построил миллионы километров ровных дорог. Их построили во время депресии. Люди, которые их строили, годами работали за еду для себя и несколько долларов в день на прокорм семьи. Хотя с автодорогами ситуация не такая явная. Они вроде как были построены для всех вообще. В IT же ситуация другая. IT-гиганты, которых можно пересчитать по пальцам одной руки, прямо или косвенно эксплуатируют всю созданную IT-инфраструктуру, к созданию которой они не имеют вообще никакого отношения.
эксплуатируют всю созданную IT-инфраструктуру, к созданию которой они не имеют вообще никакого отношения.
а без гигантов, вся эта инфраструктура не имеет особого смысла
все взаимосвязанно и друг от друга зависит… лет 20 назад было достаточно канала в 56к, а 10 мегабитный линк казался сверхкосмической технологией
тут как курица или яйцо… инфраструктура появилась первая или она развилась из-за требований своих пользователей? убери любой пункт — и ничего не было бы
километров ровных дорог. Их построили во время депресии.
Надеюсь, это шутка. Ни одного километра дорог с тех времён не сохранилось. Переложили уже несколько раз с из пор. Оплатили из налогов, включая и налоги с Амазона и с каждого принадлежащего им автомобиля.
И если у вас такая уверенность, что транспортный сбор в США не покрывает ремонт дорог, то почему тогда у вас нет претензий к валлмарт, которая "за копейки" пользуется той же самой дорожной инфраструктурой?
Перекладка дорог косвенно оплачивается из тех денег, которые зарабатываются при помощи старых. Без старых дорог не было бы денег на новые.
И да, транспортный сбор в США скорее всего не покрывает стоимость ремонта дорог. США в целом имеют отрицательный кэш-флоу. Из-за чего у них всё время растёт внутренний долг. Не вижу причин думать, что это происходит из-за всех других отраслей экономики, а автодорожное хозяйство никакого вклада в рост этого долга не производит.
Утверждение, будто гугл с амазоном поднялись 15 лет назад на скупке задешево оптоволокна или серверов просто невероятно смешное.
И волокно и сервера тех времён — малостоящий хлам, никакой долгосрочной прибыли не дающий. Гугл давно уже выкинул всё железо тех времён. А если вы внимательно посмотрите цены, за которые он скупал стартапы, то увидите, что это железо (уже утилизированное к текущему моменту) он оплачивал по цене золота.
Да не на скупке дешевого железа они поднялись. Google и Amazon — не торговцы железом, а IT-компании. Они поднялись за счёт того, что оптоволокно и сервера уже существовали в мире, в котором они появились. Им не пришлось в это вкладываться, но они на всём этом зарабатывают.
Давайте вы мне десяток квартир внутри Садового кольца на баланс передадите, чтобы у меня образовался кэш-флоу в пару миллионов в месяц. Я затем использую его, чтобы делать кое-какой ремонт, мебель буду обновлять, новые квартиры потихоньку буду приобретать в спальных районах на окраинах. И всем будем рассказывать, что я всего сам добился.
Тогда организуйте мне крах пузыря недвижимости, чтобы я мог прикупить квартиры без существенных вложений. Но только внутри Садового. И только до момента, пока я не выкуплю свой десяток.
Проблема не во мне. Просто аналогия с квартирами не полностью соответствует ситуации, в которой формировались IT-гиганты. Приходится по ходу подкручивать некоторые моменты.
В случае кризиса недвижимости, вы (скорее всего) будете думать где взять деньги на макароны, а не скупать квартиры, так как плохо будет всем и когда рынок откатиться — непонятно.
Вон, биткойн переодически падает в разы, но вы же не вкладывайте все свои деньги в него, потому что неизвестно не упадет ли он еще больше.
Тогда организуйте мне крах пузыря недвижимости,
— Что для тебя вечность?
— Одна минута.
— Что для тебя миллиард долларов?
— Один грош.
— Дай мне один грош!
— Не проблема, сейчас, подожди минуточку.
А если серьёзно, как учат классики, циклические кризисы — в натуре капитализма. Кстати, мы сейчас находимся в одном, так что ловите момент.
Это не совсем так. Текущий кризис не циклический, а кризис падения эффективности капитала. Чтобы из него выйти, придётся существенно перестроить всю экономику. И пока не очень понятно, каким образом. Вкладывать сегодня во что-либо, кроме золота, — чистое безумие. Вероятность угадать правильный актив, который будет котироваться в будущем, равна примерно нулю.
На циклический не похоже вообще ничем. А коковид — это неудачная попытка выскочить из кризиса. Кому-то показалось, что перестроить экономику на удалёнку — это хорошая идея. Но пришлось откатить обратно. Внезапно выяснилось, что часть экономики, обслуживающая офисную работу, является не вспомогательной, а ведущей. Большая часть оплачиваемой работы в современных развитых экономиках делается только для того, чтобы люди ежедневно присутствовали в офисе. Ожидалось, что удалёнка ударит в основном по аренде офисов и всяким Старбаксам, и что это можно будет с запасом компенсировать ростом отраслей по обслуживанию удалёнки. А реально ударило в совсем неочевидных местах. Белые воротнички перестали покупать свои дорогие костюмы и обувь. Оказалось, что никому больше не нужны машины. Не нужен мобильный интернет. Работы не стало у клининговых агенств, которые убирали в офисах. Компании перестали покупать принтеры, ксероксы и расходники к ним. В общем, оказалось, что нельзя просто так перестать ездить на работу в офис. Если все вдруг перестанут, то экономика не просто рухнет, а вообще почти исчезнет.
Белые воротнички — встречаются с другими такими воротничками, они не могут перейти на удаленку, в результате и автомобили и костюмы будут также нужны. (а автомобили в принципе будут нужны… я уже устал парировать возгласы сторонников ОТ, которые забывают что за МКАДом рай заканчивается и врятли когда либо наступит тупо по экономическим причинам)
Принтеры и ксероксы, нужны не потому что в офисе куча народа сидит, а потому что нужны бумажные документы и релокация людей из офиса эти потребности не уберет единомоментно (тенденция по сокращению бумажного документооборота есть, но скорость её не велика и там много проблем)
Я не столько Россию и Москву имел в виду. Честно говоря, я просто пересказал вкратце англоязычную статью с Medium. Там некие эксперты сделали шокирующее открытие. Обнаружили "скрытую" офисную экономику объёмом в триллионы долларов, которая внезапно проявилась из-за пандемии.
Корпорации прямо или косвенно платят эти деньги, чтобы люди в офисах сидели. Рынок же. Есть спрос, есть предложение.
К сожалению, экономика устроена не так, чтобы из неё можно было просто взять и удалить ненужную часть. По крайней мере, капиталистическая. Любая деятельность включена в длиннющую цепочку, которая заканчивается актом конечного потребления. И если убрать значительную часть этого потребления, то вообще всё рассыпется как карточный домик. Кредиты перестанут возвращаться. Начнутся массовые банкротства. Риски по всей цепочке драматически возрастут. А значит сломаются старые схемы перераспределения этих рисков. Без этих схем многие виды деятельности упадут ниже точки рентабельности. И так далее. У экономистов есть такое понятие — "вертолётные деньги". Оно отсылает к тому, что конечный спрос нужно поддерживать любой ценой. Вплоть до того, чтобы тупо печатать деньги и разбрасывать их с вертолётов. А вы предлагаете просто так взять и сознательно вырвать из экономики огромный кусок офисных потребителей.
Вот только "нужность" это не какая-то объективная величина. Это суперпозиция множества индивидуальных субъективных нужд. И в рыночной экономике нужность определяется готовностью платить. И вся "эта экономика" существует не потому, что кто-то хочет в офисе сидеть, а потому что кто-то готов платить людям, чтобы они в офисе сидели.
Неэффективная часть постоянно умирает только в тривиальной модели рыночной экономики. В реальной экономике эффективность довольно давно не является критерием отбора. С тех пор, как изобрели кредит. Выживаемость теперь зависит от доступа к кредиту. Поскольку кредит позволяет перераспределять риски и эффективность. Тот, у кого условия доступа к кредиту лучше, всегда может переложить собственную неэффективность на того, у кого условия хуже. В итоге умрёт именно он. Даже если он был более эффективен. А тот, кто может постоянно перекредитовываться, экономически бессмертен.
гениально! полностью поддерживаю. Из этого следует простой вывод — "бессмертны" будут гос или окологос компании, а деньги ничто — власть все, будет власть — будут деньги, но не факт, что наоборот
Почти. Этот вывод верен только для государств, которые могут эмитировать настоящие деньги, т.е. какую-нибудь резервную валюту. К России, например, он не применим. Она может эмитировать только рубли, которые по своим свойствам похожи на деньги из Монополии.
А про власть, конечно, правильно. Монетизация власти — тривиальная и чисто техническая задача. А вот обратная задача по превращению денег во власть требует реализации стратегического плана со множеством рисков.
Текущий кризис не циклический
Примерно то же мне говорили
На волне того "не циклического" кризиса я обернул несколько квартир (которые продавались тогда по пять копеек пучок) и неплохо поднялся (+ скупка акций на падении и продажа несколькими годами позже на подъёме).
а кризис падения эффективности капитала
Не Вам одному эффективность вложения капитала покоя не даёт.
И были правы. Текущий кризис — это тот самый, который начался в 2008. Реального экономического роста с тех пор ещё не было. Искусственная накачка финансовых рынков не считается. Ну, а спекуляции в любом кризисе позволяют подняться. Это не новость. Как говорил чувак из Игры Престолов: "Хаос — это лестница".
Прочитал обе части про разработчикономику. Очень напоминает книгу "Netократия". Местами — до степени неотличимости от краткого пересказа.
Просто гора кода, конечно, не нужна.
Единственная история, которую помню о скупке чего-либо после краха доткомов, это когда Getco скупили сервера после краха доткомов, и поднялись на HFT. Но там история сильно нишевая, да и те сервера, уверен, через год уже устарели, учитывая скорость роста тактовых частот в то время.
Если у вас не получилось толково внедрить agile — это не повод его ругать. У меня был положительный опыт, хотя и не в IT-сфере.
Инженерный подход — использовать не лучшие, а подходящие для решения задачи практики. Совершенно необязательно строить деревянный сарай титановыми гвоздями и заказывать проект в пинифарино, если он для хранения лопат. Проблема в том, что разработчики зачастую не договаривают, что есть альтернативы, и убеждают заказчика в том что "лучшая" практика является единственной.
Ещё часть проблемы в том, что многие разработчики на позиции разработчиков, считают, что их наняли чтобы разрабатывать почему-то — странные, да?.. Приходит менеджер к разработчику и говорит: нам нужен интернет-магазин, за сколько мы его можем сделать? Ну, разработчик спрашивает требования, ему их дают (постфактум неполные дае на момент опроса) и даёт оценку: полгода. Исходя из простого факта: менеджер пришёл к разработчику, а не к веб-мастеру или интегратору.
Хотя разработчик может упомянуть альтернативы: "есть готовые универсальные движки интернет-магазинов, но я с ними не работал, а по слухам очень сложно кастомизируются и жрут немерянно ресурсов, и есть даже готовые интернет-магазины как сервис, так они вообще вроде бы только логотип позволяют поменять. И какую бы альтернативу не выбрали — я увольняюсь, их выбор покажет что я вам не сейчас не нужен"
Вот очень правильное guarding condition, очень.
— корова всё же сдохла…
— чёрт, какая жалось, у нас ещё столько идей было!
(с) анек
Теоретически, если менеджер подошёл к разработчику, значит к бизнес-консультанту, чтобы это не значило, он уже подходил и тот ему сказал, что надо своё пилить :)
На мой взгляд, всё же, выбор между какой-то "коробкой", "облаком" и кастомной разработкой, обычно архитектор делает. Ну или предоставляет технико-экономические расчёты на варианты, а менеджер выбирает.
Например, на последней работе я сделал прототип проекта за сутки — и это 60% всей работы, нужной для выхода на рынок
Вы ведь помните закон Парето? На всякий случай напоминаю
Закон Парето (принцип Парето, принцип 80/20) — эмпирическое правило, названное в честь экономиста и социолога Вильфредо Парето, в наиболее общем виде формулируется как «20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата».
А тут уже 60% сделано — 90+% результата? :)
Уже которая статья Фила где всё спорят и спорят в комментариях: "Всё так", "Всё не так", "Вот тут так, вот тут не так". А для меня эти статьи — просто повод задуматься, посмотреть на себя со стороны (да хотя бы со стороны Фила). Подумал, где-то согласился, где-то не согласился, но понял, почему есть именно такие разные мнения.
Ожидаемо прицепились к 60% — понятно почему. Возможно ли такое — почему бы и нет? Идеи могут быть достаточно компактными, а коммуникации — весьма затратными.
Никто не зацепился за последние 4-5 абзацев. То ли все согласны, то ли не дочитали, то ли так подгорело, что аж захлебнулись желчью. Думаю всё вместе. А они неплохо подытоживают статью, особенно предпоследний.
Вообще у меня уже сформировалось вИдение Фила — это не разраб, ни в коем разе. Не тимлид. Это философ-евангелист не знаю какой идеологии, но с конкретными такими навыками работы с аудиторией.
Я могу зафигачить целое приложение за месяц. Например, на последней работе я сделал прототип проекта за сутки — и это 60% всей работы, нужной для выхода на рынок.
Если это приложения из домена в котором у вас уже накоплен опыт двух лет работы в команде из 10 человек то да — можно повторить. Попробуйте что-то написать из незнакомого домена, к примеру у меня обширный опыт e-commerс, сейчас я в fintech и несмотря на то что вроде как что-то смежное с e-commerс, но мне сложно.
Ну а главная ошибка таких менеджеров это неграмотная делегация. Такие менеджеры очень редко спускают будущую общую логику, совмещая общие фразы «на проект делает задачу %task» и огромные страницы с кучей определений в доке. В результате могут быть созданы два таска, «сделать корзину» и «сделать каталог», оба таска сделаны, протестированы, работают, одно но — нету кнопки «добавить в корзину». Просто потому что менеджер продумывал киллер фичи для каталога и корзины, и для таких банальностей как покупка времени не нашел. Ну а тестеры и разрабы вообще решили что это будет следующей задачей) И хорошо если разраб один, он может заметить что что-то не так, но ведь часто эти таски даются нескольким и параллельно. Отсюда и заметка про 60%. Это сделать без киллер фич, но то что уже работает и делает это не плохо. Да потом остальное можно пилить годами, но при этом у вас уже будет работающий продукт. А если делать фичи изначально, то до этапа готового продукта можно и не дойти.
- Дизайнеров — которые делают красиво
- Дата-тим, которые анализируют данные и грубо говоря по итогу сокращают путь пользователя до покупки
- Серверная команда — которая делает сервер (если свой протокол)
- Frontend — ведь сначала пользователю нужно показать сайт
- Backend — где-то же нужно хранить информацию о премиум пользователях
- Support — премиум-пользователям нужна поддержка
- и так далее.
Да и саму библиотеку, реализующую подключение, тоже кто-то должен написать. Таким образом, никто не будет платить просто за форму с кнопками, дёргающими предоставленный кем-то API. VPN клиент — это продукт слаженной работы многих команд, именно поэтому мы делаем то, что требует бизнес, а не то, чего бы нам хотелось. В конце концов, за это мы и получаем деньги, не так ли?
Но люди разные, и подходы у всех разные.
Например, я лично полностью солидарен с автором статьи, а вот одна моя коллега напротив, считает что нет ничего лучше вечных проектов. Она мне так и говорит, чем дольше будет продолжаться проект, тем лучше — пока вся эта хрень длится, я уверена, что у меня есть работа.
Я не удивлюсь если когда увижу на сайтах помесячные тарифы.
Есть масса рекрутерских фирм «сорсеров», которые собирают разработчиков со всего мира. Вот тебе и готовая модель. Набирай, возглавляй и отпускай клиентам на проекты.
А Бизнесу это в принципе удобно, чем каждый раз искать новых ребят, притираться. Если ты уже нашел общий язык с командой это дорогого стоит. Не фирма ведь делает проект, а конкретные люди.
А что такая тенденция значит для каждого отдельного разработчика — вы догадываетесь сами. Девальвация реальных знаний, навыков и опыта, повышение субъективной ценности сертификатов и рекомендаций.
Даже фирмы которые якобы классические, ну там возьмите Luxoft, Еpam — тоже работают на проектной основе. Т.е. в принципе те же сорсеры. Только люди там работают на постоянке.
Потому что вечно менять людей невыгодно, подбор кадров штука затратная. Но тебя так же будут кидать с проекта на проект. И работая в таких фирмах вы только для своих соратников будете товарищем, другом, коллегой, для заказчика может быть ценным специалистом, а для предприятия просто надежной шестеренкой в механизме.
Поэтому молодые и уходят в стартапы, на меньшие деньги, но за свободой и творчеством. А потом надышавшись этим свежим воздухом до простуды возвращаются в теплый цех фабрики, где хоть обед по расписанию.
P.S.
Кстати нельзя не отметить, что в соответствии с этой тенденцией качество продуктов должно падать. Что мы и можем наблюдать в жизни. Кроме всего и по этой причине крупные фирмы держат людей на постоянке, чтобы хоть как-то контролировать и гарантировать качество.
Ну а в перспективе необходимость в тестировщиках будет расти. Опять же дешевых, тестировщиках-как-сервисах, кнопкотыкальщиках (а не инженерах), но все же.
Денег сейчас очень много в индустрии, если 8 из 10 проектов не доходят до выпуска, то оставшиеся 2 покрывают все затраты с запасом, что и позволяет отрасли экспериментировать в методиках и подходах.
Жил бы в Советском Союзе, работал бы в НИИ за кусок хлеба над какой нибудь очень полезной программой, считающей удои.
Свобода выбора и наличие денег в отрасли ему не нравится виде те ли…
Взять и сделать — это чушьЯ так преподам о курсовых отвечал
Я пилю АБС более 3 лет. А до этого ее пилили ещё 10. Что мы делаем не так?
Позднее с опытом человек поймет, что есть не только проекты на пару недель, но и на многие годы, и отнюдь не только в FAANG, что то, что понятно одному разработчику, может быть, ну очень мягко говоря, непонятно другому, что собственно кодинг — это далеко не все, что нужно для продажи продукта, что крэш в неподходящее время может стоить сотни тысяч евро и т.д. В общем с опытом пройдет :)
Если же фичей вашего бизнес является какое-то своеобразное видение процессов или что-то такое — то я сомневаюсь, что «переделка» стандартных решений будет дешевле.
В любом случае — всегда надо считать.
it dependsЭто-то понятно, но нет ли каких полуколичественных оценок? В производстве обычно понятно, когда менять способ производства.
Это-то понятно, но нет ли каких полуколичественных оценок?
Есть, в целом суммарная «стоимость» проекта за время его жизни должна быть минимальной (или наоборот, чистая «прибыль» от проекта — максимальной).
Сюда входит:
1. Потерянная прибыль из-за возможных ошибок/падений проекта,
2. Стоимость переписывания на нормальную систему,
3. Потерянная прибыль из-за слишком затянувшегося выхода на рынок (появления новых фич),
4. Затраты из-за найма разработчиков на сырой легаси проект/уход разрабочиков из-за плохого кода (или наоборот, экономия из-за сотрудников мотивированных интересным проектов и технологиями),
5. Стоимость добавления и отладки новых фич,
6. И т.п.
В целом, нужно считать «затраты» (в том числе, косвенные).
Иногда стратегия вполне очевидна («тяп ляп и в продакшен» стратегия для проекта, приносящего миллионы каждую секунду,- не очень разумная, так как одно падения уведет экономию в глубокий минус).
Иногда требуется много опыта и внимательности, чтобы понять, что текущая стратегия уже плохо работает (например, вся команда разработчиков ищет другую работу, потому что текущая архитетура их за… мучала), либо для добавления простейшей возможности нужно несколько месяцев рефакторинга и переделок.
В целом, основной навык архитектора спланировать все так, чтобы получить минимальные суммарные издержки и не доводить до авралов и спасения с тонущего корабля. Иногда для этого нужно изначально не идти по пути «ТЗ на салфетки», иногда вовремя залажиться на глобальный рефакторинг/создание новой надежной системы с нуля в какой-то момент в будущем.
Вопрос, как я понимаю, исключительно о процессах разработки. Когда, например, оправдано внедрение CI/CD, а когда это экономического смысла не имеет.
Но хороший дизайн и удобное UI, которое приносит радость пользователям (или хотя бы не бесит) не менее важны, уже на этапе выхода проекта в рлиз.
Всему свое время, каждой стадии разработки — свое время.
Это доказано, например:
— студиями, которые делают красивые дизайнерские сайты на битриксе и продают их по цене порядка 1 млн руб (а ведь можно шаблонный за считанные часы собрать, да?);
— производителями телефонов;
Поэтому я бы не призывал делать стандартные продукты из базовых компонентов для небольших фирм. Все большие фирмы были когда-то небольшими. А вдруг этот ларек достоин крутого продукта?
Да и вообще, красота и удобство ценится не мене высоко, почем функционал. Не нужно стремиться свести все продукты к серым прототипам, собранным побыстрее да поскорее.
Написать 60% не проблема. 80 тоже. А вот последние 10-15…
«У нас были четыре разраба, три тестера, продукт оунер, проджект менеджер, сторонняя команда дизайнеров.»
Хорошее начало для фильма «Страх и ненависть в IT».
Никого не волнует как вам или мне или тому парню тяжело, пока доходы выше расходов — все делается правильно
«Тяжело» тоже имеет денежное выражение, в виде уволившихся сотрудников, плохой мотивации и нежелании кадидатов связываться с этим проектом даже за зарплату выше средней по рынку.
Плюс, выигрыш в краткосрочном планировании может оказаться проигрышем в долгосрочном (пока в проект добавляется одна фича — конкуренты выкатывают уже десяток по той же себестоимости).
Их ещё волнует недополученные доходы, недополученная прибыль. Если в таких терминах объяснять, то проще выбивать ресурсы на "переписать"
ЕМНИП это в этическом разделе Проджект Менеджмента есть — как только ПиэМ понимает, что проект не сможет/не будет отвечать критериям Содержание/Сроки/Стоимость он обязан сообщить это стейкхолдеру. Ну, конечно, если это сертифицированный ПиэМ, и не боится быть лишенным «корочки»
Пусть билд крутиться 6 часов — у меня как раз много важных дел дома, но ты должен понимать — мое время стоит дорого. А платить ты вздумал не за продукт, а за игру в разработку. И я с тобой поиграю.
Счастливчик.
Ему платят не за результат, а за процесс.
Но вопрос был все-таки про то, как расплачиваются с программистами, пока результат не достигнут? Ведь им платят за процесс, а не за результат. Тогда как s75 писал, что знает, где платят за результат.
Платить можно по разному и с аджайлом. Главное найти согласных на эту плату.
p.s. премировать за то, что в итоге работа сделана корректно — это признавать, что разработка нынче все еще подобна золотодобыче.
Для себя вообще слабо представляю за что программиста можно премировать на регулярной основе, как кое-где принято. В отдельных случаях представляю. Но вот чтобы регулярно...
В РФ с премий, насколько я знаю, меньше налогов платитсянет
за что программиста можно премировать на регулярной основезп за текучку, премии — за проекты, от нуля до 4 в год
нет
вообще мне высказывали мнение, что "с премий платится меньше налогов". Причем неоднократно. Вряд ли это заблуждение вот на 100%, и все равно у него будут предпосылки
Кроме того, надо понимать и точку зрения бизнеса, если 1 из 5 программистов сделал раньше работу — это классно, но если это никак не повлияло на скорость выпуска проекта\продукта — то в чем смысл? Пусть исправляет свой технический долг по предыдущим проектам, благо — ситуаций, когда этого долга нет, я в своей жизни не наблюдал.
— сдали раньше за счет того, что применили что-то новое-невероятное-крутое-работающее
— сдали раньше и все знали, что, чем раньше, тем больше денег заработает проект\продукт
Если же сдали раньше, но этого особо никто не ждал, профита не принесло, то «ну окей». Сдали также раньше во второй раз — класс. В третий — с планированием какая-то беда?
Мы тратим годы на то, что делается неделю — потому что все ларьки заигрались в IT-гигантов