Pull to refresh

Comments 257

Например, на последней работе я сделал прототип проекта за сутки — и это 60% всей работы, нужной для выхода на рынок

Ну так сделайте, что мешает?
Будете делать коммерческий продукт и поймете, что кодинг, дай бог 30% от всей работы по выходу продукта на рынок и оставшиеся 40% работы кодинга съедят как минимум в 10 раз больше времени.
Интересно будет почитать его статью когда он начнёт делать собственное приложение и на 85%-ом проценте разработки врубится в архитектурные ограничения. заложенные в самом начале. :))) Прям вспоминаешь молодость. :)
неплохо получается, если делать одну версию «как идет», а потом вторую версию «как надо»

или когда без тестов и CI/CD сломает что-то , выкатит юзерам и будет отдуваться

Однажды я научусь использовать свой собственный опыт, а пока, что
1) Июль 2016 года — «да тут только пару ошибок исправить, это недели две, и еще пара недель на вот эти фичи».
Июль 2018 — *спустя 2 полных переписывания модуля и множество изменений архитектуры и процессов* — «проект готов на 95%».
2) Сентябрь 2019 года — «да тут надо немного исправить, вы как раз из отпуска вернетесь, а уже все готово»
Сентябрь 2020 — *твою ж мать, опять*.
Он же написал уже что именно мешает — желание билдить 6 часов, а в это время заниматься полезными домашними делами и хобби, да так, чтоб это время ещё и оплачивалось )))
UFO landed and left these words here

Раз на десятый эти классы можно с закрытыми глазами писать с минимальными изменениями под конкретный проект.

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

А потом комбинировать, в разы проще, а то основные проблемы это как бы pixel-perfect сделать и кнопочку с анимацией. Нахрен не надо этого. Но Стив Джобс создал армию тех кто хочет (или претендует) чтобы быть Стив Джобсом. Дизайн это главное.

Я может ошибаюсь(вскользь читал про него лет N назад, когда он умер), но по-моему как раз он и протолкнул все эти Guidebook-и для разработчиков у яблоков, в которых описывается как желательно делать интерфейс в приложениях, использовать максимум стандартное, чтобы GUI был у всех похож и пользователю было с ходу привычно пользоваться любым приложением, а все лишнее кастомное всячески порицается.
UFO landed and left these words here
У нас был один случай, когда какой-то менеджер случайно не ту картинку залил для заголовка формы. Потом выяснилось, что пока висела эта картинка (дня 2 или 3) продажи резко снизились и общие потери оценили во вполне приличную сумму что-то порядка 30к долларов. Так что дизайн имеет значение :)
«Выиграть в работе нельзя, зато проиграть можно запросто.
Кто втащил входную дверь наверх??»

Вы не поняли суть — наличие крутой картинки не привлечёт толпы покупателей. А как раз таки неудачно (специально, или случайно, не важно) подобранная картинка (видео) обрушит продажи (см. примеры бойкотирования брендов в Китае/Японии после несуразных рекламных роликов).

То есть «магия дизайна» в софте/вэбе не имеет обратной силы. В вашем примере, если бы была установленная мега крутая картинка/фотка/видео/etc это бы не привело к скачку продаж на 30k за три дня.

Может ну его нафиг так рисковать, а просто делать хороший продукт без этих ваших свистоперделок?

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

PPS помню даже встречал задизайнерные окна перепрошивальщиков боиса мамок.

PPPS А видеоплееры припроетарные? Как ни версия, так новый дизайн и все кнопки перемешаны. Самый эпик — это в Windows Media Player после очередного редизайна убили связь «пробел» = пауза. Тыкай мышкой в кнопку! Вот это просто финиш! После этого хочется взять биту и идти убивать!

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

>не привело к скачку продаж на 30k за три дня.

Здрасте, не привело бы. Не знаю как во всем мире, но в мобилках (игры/приложения) очень даже привело бы.

Вот и сидит 100500 команд, пилят свои стайлгайды и юайкиты под них: д

Очень странные утверждения. Когда мне 8 лет назад пришлось около года работать на маке, я так и ниасилил его интерфейс. Он совершенно безумный и не поддающийся никакой логике. Например, в itunes (кажется, так называется тамошний медиа-плеер) я несколько месяцев не мог слушать интернет-радио. Потом разговорился об этом со специалистами, они попытались мне объяснить, но я никак не мог понять, о чём они говорят. Наконец, я отправил им скриншот и они мне нарисовали, куда нажимать, чтобы оно заработало. Оказалось, нужно было нажать надпись Radio, которая оказалась кнопкой. После этого я изучил интерфейс уже повнимательнее и насчитал на том экране не меньше 10 видов начертаний кнопок. О какой стандартизации в такой каше вообще можно говорить?
Да, поддерживаю… Насчет логичности в Apple-интерфейсах есть неочевидные моменты. Например — подключение iOS-устройства к скрытым сетям Wi-Fi. При помощи в подключении каждый раз* мозК оттормаживает, когда после перехода-> на экран выбора типа безопасности (ну и собственно выбора типа) для продолжения процесса — ввода пароля, наверху слева нужно тыцкнуть возвратную кнопку <-Другая сеть, и потом вводить пароль уже на исходном экране. Почему на возвратной кнопке написано «Другая сеть»** — без ввода имени сети я бы не смог перейти к экрану выбора типа безопасности? Ну тут ладно — это общее странноватое название кнопки (было бы логично назвать «Подключаемая сеть»), но! — Зачем вообще разматывать взаимосвязанные и взаимозависимые настройки на 2 экрана? Причем настроек-то всего 3. В Android, под разными оболочками, все это настолько примитивно-очевидно, что основной массе пользователей помощь не требуется.

* — помогаю коллегам, обратившимся за помощью, на протяжении нескольких лет делал это уже раз 50+, каждый очередной раз взбадриваюсь, что есть какой-то неочевидный момент, а все равно спотыкаюсь.
** — причем это не нюанс локализации, в английском интерфейсе это кнопка <-Other Network
iTunes — это не весь мак. У Эппла есть много хороших продуктов, но есть 2 отвратительных — айтюнс и appstore connect (слава богу, с последним сталкиваются только девелоперы).
Давно убедился в мысли что стандартизация это благо. Стандартный UI, стандартизировать основные классы, схемы таблиц и т.п.

Девелоперы — такие лицемеры.
Ратуют за виндовый блокнот для юзеров, а сами юзают IDE с автокомплитом, кодеджампом и автоматическим рефакторингом.
Забыли основное кредо программиста — экономить время юзера?
Наша задача — сделать труд юзера эффективным, а не строить его, превращая в солдата.
А для этого иногда надо потрудиться и понять, что выпадающий список — это 2 и более клика мышки, а плашка с горизонтальными кейсами — один.


Пример самописного контрола

image

Контрол, кстати, очень классный для своей области!
Ратуют за виндовый блокнот для юзеров, а сами юзают IDE с автокомплитом, кодеджампом и автоматическим рефакторингом.
Простите, а где тут «за блокнот». IDE-то как раз и состоят из стандартизированных компонентов, причём не только внешне, но и функционально. Просто стандартизированы они с умом, людьми понимающими, что и для чего они делают.

Не всегда с умом, к сожалению. Пример:
Новомодный рибон в МС продуктах. Для кого-то очень удобно, для кого-то нет, но есть один нюанс: мониторы сейчас растут больше в ширь, чем в ввысь. А эти затейники отъели не таясь часть дефицитного вертикального пространства. Тогда как боковики совсем не используются и зачастую пустуют. Я пару раз подумывал — не поставить ли мне монитор на попа, вертикально.

ИМХО, самый лучший интерфейс был, потому что хоть и был слегка громоздкий, зато очень легко и гибко настраивался. Просто пользоваться надо было без фанатизма.
Поставить, очень удобно, у меня второй так и стоит для простыней текста.
Новомодный рибон в МС продуктах.

Новомодный? Ему почти 15 лет...

Это смотря для какой области, в мобайле все только вширь: слева — дерево файлов (без него никуда, не из проводника же все открывать), справа — окно эмулятора, по центру собссно редактор, и все в одной IDE.

То, что у вас боковики в ворде не используются, не значит, что у остальных так же.

Тоже довольно долго плевался на риббон, но не так уж он и плох, если найдётся время сесть и настроить всё под себя — сделать кастомные табы, скрыть ненужные дефолтные.
Дико удобная фича - возможность добавления кнопок на Quick Access Toolbar.
image

1) Поставил +. Красиво!
2) Однако поинтересуюсь — как в этой концепции организовать интерфейс для выбора цвета границы? Для каждого типа линии в каждой отдельной плашке сделать раскрывающееся меню с палитрой?

Я делал нечто вроде:


Еще самописный контрол

image


Но думаю цвет для каждой рамки — избыточен. А вот толщина — да, необходима.

Боль. Окно не расширяется вниз? В ползунок перемещения по шрифтам надо попадать при помощи оптического прицела. Цвета расположены хаотично.
)))))))
А… сорри! Да — так уже хорошо. Заставлять юзера лезть в текст программы и перекомпилировать проект — необоснованная жестокость.
Но вообще говоря заставлять думать программиста о юзабилити — тоже излишне.
Пользоваться программой же не он будет скорее всего. Дизайн должен рисовать специальный человек который хорошо знает, что нужно юзеру.
Мне как-то программист принес программу — я стал смотреть, а там… местами вместо трех кликов достаточно двух, вместо двух — одного, вместо восьми — трех, и т.п… плюс нестандартные сочетания клавиш. А работать с этой программой людям по восемь часов в день. У меня как-то была статья, я там жаловался на интерфейс разных программ. А сам как-то писал утилитку для генерации конфигурационных файлов — так интерфейс рисовал (на листике) две недели.

По скольку я и сам юзер, то за юзабелити слежу..

О! Точно такой контрол был первым моим заданием на моей первой программёрской работе около 25 лет назад. На дельфи.
А потом вас просят сделать инлайн грид с проверкой ввода и автоблокировкой отдельных полей и 3хэтапным вызовом окна после его заполнения но с сохранением контекста введенного. После работы с проектами в государственном документообороте становится понятно что стандартизированные решения в этом вопросе упирается в хотелки клиента. А пока на дворе капитализмъ — придется искать компромисс.
UFO landed and left these words here
Может идут, может нет. Если они выполнили текущую цель заказанным ПО и в целом получили прибыль, думаете им есть дело?

Так-то так, да вот только поддерживать эти стандартны не всегда легко. Стандартизация хороша, когда у вас уже есть много готовых компонент, и их можно немного подпилить, чтоб они друг к другу подходили. А вот сделать сразу хороший стандарт, который будет вам служить хотя бы несколько релизов — штука возможная, но рискованная. Весь мой опыт говорит в пользу того, что нельзя просто посидеть, подумать и сразу придумать правильно. Надо пробовать, экспериментировать и быть готовым, что придется все переделать.

А в индустриальную разработку пусть играют индустриальные гиганты — у них это отбивается.
Золотые слова. С текущими зарплатами «инженеров» почти никакая разработка, кроме той, что делается на ОЧЕНЬ большую аудиторию или проедает венчурные-пофиг-сколько-их-деньги, не отобьется. Удел большинства проектов — легкий серверный скриптинг на php и дизайн за 30 тыс рублей, и его бы хватило для 90% проектов.

Кроме php бывают еще и задачи на производстве, например раскрытие заказов по спецификациям. Это раньше были альбомы с чертежами, одну сборку пропустишь — все, ее не сделали, и меняй работу. Это еще на машинах СМ было. Потом тоже самое на Unix. Это называется "Заводской программист". Программа идет только в комплекте с программистом. Один человек, постепенное усложнение задачи, и ничего лишнего.

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

UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here

Выгода бывает разной. Относительной, абсолютной, кратко-, средне- и долгосрочной. А исходных данных и целей у технарей обычно просто нет. Бизнес приходит к нам не с бизнес-планом, а набором фич

Если у вас есть понимание как правильно сделать и вы думаете, что это в граните. Вы ничего не понимаете.

Прекрасная статья, каждое слово резонирует с каждым нейроном в моем организме.

Просто хочу сказать — спасибо.
«Например, на последней работе я сделал прототип проекта за сутки — и это 60% всей работы, нужной для выхода на рынок.» — на самом деле это примерно 15-20 процентов, если, конечно, мы говорим о продукте, а не о мелкой кустарной поделке. Как уже сказали выше, в разработке программного продукта собственно программирование занимает далеко не основное время.
UFO landed and left these words here

Первые 80%. После которых будут вторые 80% и доводка — ещё процентов 40-50.

а после того как появятся первые пользователи — в лучшем случае придется переписать половину всего!!! В худшем… в худшем пользователи так и не появятся
Кстати да, аджайл, туда-сюда.
Вероятно имелось в виду от того, что необходимо было сделать автору. Да и в таком случае, это не маленькие цифры.
> на самом деле это примерно 15-20 процентов

Как бы даже не 3-5%…

У афтора исходной статьи впереди ещё много чудных открытий…
Отличная статья!
27 лет моего опыта разработки говорят о том, что если в проекте больше 10 программистов, то производительность труда катастрофически падает.
Так же опыт показывает, что 2 месяца на проект — это почти диагноз зелёного программиста, возомнившего себя сеньором.
Да почти о любом, где как правило на неделю кодинга идёт месяц-два пуско-наладки, согласований с пятью начальниками, игр со шрифтами и прочих реалий жизни, которых этот лихой программер просто не нюхал.
игр со шрифтами и прочих реалий жизни, которых этот лихой программер просто не нюхал

очень сильно зависит от специфики разработки. Где-то программист и дизайнер — это одно лицо, а где-то у каждого своя область ответственности и программист не играет со шрифтами в принципе.
Согласен.
Правда, проекты бывают разные.
Я свой делал более шести лет. А потом переход на другую платформу.
UFO landed and left these words here
Фредерик Брукс, «Мифический человеко-месяц». Должна быть настольной книгой у каждого PM или тимлида.
Спасибо за рекомендацию.
Мне предстоит совершить очень важный шаг в трансформации моей (уже нашей) программы.

«Я подарил своему начальнику два экземпляра "Мифического человеко-месяца", чтобы он мог прочесть её вдвое быстрее»

"… Теперь у меня два начальника, и я должен работать вдвое быстрее".

UFO landed and left these words here
Узнаёте?
Не понял вопроса?
Я в этой статье немножко рассказал, как работал 4 года над CAD проектами.
UFO landed and left these words here
забавно что когда сам работаешь и приходишь к мысли что «а оно действительно надо»… и начинается многомесячное разгребание конюшен

видал в одной конторе такое, «нам это не нужно, работаем без этого бреда»… а потом увольняется начальник разработки-тимлид(по совместительству)… и команда из 10 человек остается около репозитория на пару миллионов строк кода, от перла до си, без единой строчки документации «ведь ясно же что код-самая лучшая документация» (с), с ТЗ в виде папки с вордовскими файлами, с деплоем «ну мы вручную тут war файлики подкладываем, а там на серваке reset жмем потому что перезапуск почемуто не работает… прод конечно останавливается, но ЭТО НОРМАЛЬНО»
И вот тогда понимаешь, что все эти новомодные фичи нужны в том числе чтобы уменьшить эффект автобуса и структурировать происходящее.

но я согласен что иногда надо быстро-быстро наваять MVP, и если дело пойдёт. то надо бегом структурировать разработку, потому что всё потом утонет в бардаке самопального беклога и неорганизованной дичью
UFO landed and left these words here
тут опасно упустить момент, когда вы из ларька превращаетесь в «амазон» (всмысле не охвата, а объема проекта). Иногда это происходит незаметно для всех, а потом бежать уже некуда.

Также игнорирование типовых паттернов отрасли — негативно влияет на саморазвитие разработчиков и отпугивает их (у меня нынешняя работа такая, топим за минимализм, неважно что интеграция любых фич требует адского рефакторинга, важно что нам сейчас это не нужно — не делаем, будет нужно — сделаем, в итоге любое фичепиление занимает по один — два месяца с переписыванием тонн кода потому что «это было не нужно, мы это не предусматривали»)
нам сейчас это не нужно — не делаем, будет нужно — сделаем, в итоге любое фичепиление занимает по один — два месяца с переписыванием тонн кода потому что «это было не нужно, мы это не предусматривали»

Странно. У меня нога такая же, но не болит.

Но ведь когда ларёк превращается в Amazon — ему всё равно не нужны склады по всей стране, как Amazon, по крайней мере, сразу.
Сначала стоит построить или даже взять в аренду 1 небольшой склад и посмотреть, что будет с деньгами, людьми и бизнес-процессами, если попрёт — развиваться дальше.
А то приходят люди и говорят — "у нас тут бигдата, целых 20гб, а к концу года все 50гб будет! Прикиньте нам архитектуру основного озера данных, резервного, etl, резервного копирования, мониторинга и шифрование поверх всего, заодно и интеграцию со всеми системами, правда, мы ещё не придумали, с какими"
Идея хорошая, но на этом этапе никто не понимает, зачем столько, кто и как будет работать с данными и какие результаты хочет получить, и честно говоря, на этом этапе полезее всего был бы 1 хороший аналитик с хорошим ноутбуком — оценить сценарии использования и показать результат и потом уже решать — нужны ли кластера и если да — то какие.
А пока — культ карго в it становится всё сильнее: задачи "как в гугле" для приёма джунов и петабайтные кластеры для данных, что влезут на современный телефон.

Не, если 20-50ГБ это именно оперативные данные (по которым принимаются текущие решения) и без фоточек юзеровблобов, то вполне себе биг дата для ларька. Например прайсы поставщиков электронных компонентов с ценами, остатками и сроками поставки.
то вполне себе биг дата для ларька.

Биг дата это все-таки то что физически не может поместиться на один сервер, а тут хватить одного ноута или VPS за 10$/месяц. Поэтому многие методы для бигдаты (всякие Hadoop кластеры) там будут просто забивание гвоздей микроскопом.
Согласен с vedenin1980 — в описываемом случае всего 25Гб и к концу года планируется всего 50, такой объем можно спокойно порезать и обработать в Excel.
PS Единственный случай, когда такие закупки с запасом оправданы — крупные компании, у которых для покупки хоть чего нужно пройти 6 уровней согласования, архитектурный комитет, безопасников, коммерческий комитет, 3 раза защитить проект и при любых правках ждать следующий сбор комитета через пару месяцев и уж когда выделяют деньги — их нужно срочно тратить, пока финансовый год не закончился.
Я бы уточнил. Если МОЖНО БЫСТРО сделать MVP на коленке, тогда его надо делать быстро и на коленке.

Если MVP нельзя сделать быстро, то структуру лучше закладывать сразу, хотя бы частично и в ручном режиме и уже потом развивать и её тоже.
Я бы ответил, что каждой задаче свой инструмент. Для доставки пиццы фуры же не используют, и карьерные самосвалы тоже. Тот же маленький интернет-магазин можно даже в ВК и инстаграме организовать, для этого не нужно ни микросервисов, ни девопса. А как у амазона технологии имеет смысл использовать, когда оборот будет как у амазона. Руководители малого бизнеса умеют считать деньги, так что им нужно всё переводить на деньги.
Тот же маленький интернет-магазин можно даже в ВК и инстаграме организовать, для этого не нужно ни микросервисов, ни девопса

тут все проще, для маленького интернет-магазина вообще программисты не нужны как таковые… достаточно в любой типовой картинок налить и оплаты подцепить один раз а вот эта идея «мы сделаем свой велосипед» и «нам обязательно нужны кастомизации» — это всё в ту-же тему о чем и основная тема статьи
Для маленького магазина не нужно цеплять оплаты, они могут съедать на своих комиссиях большую часть прибыли того самого маленького магазина. Большинство клиентов таких магазинов готовы оплатить переводом на карту. А для совсем маленького, как верно написали выше, и сайт не нужен, т.к. его ещё надо продвигать, а это тоже денег стоит — достаточно инстаграма, контакта, юлы, региональных торговых площадок.
А по другую сторону успех dodo-пицца, которые были маленьким сыктывкарским подвальным магазином, пока не решили, что они «гугло-амазон», и понеслось.
Их статьи есть на хабре.
У меня большие сомнения в правдивости истории додопиццы «вложили 1,5 ляма от нивестора, и уже через три месяца выкупили долю компании, а через год уже куча пиццерий»

ИТ система это долгосрочная инвестиция, особенно применительно к классическому бизнесу и сама по себе не дает роста прибыли чтобы «быстро стать амазоном»… а вот бабла жрет немеряно

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

Так что успех сомнительный.
Оценочные суждения типа «не особо популярна» и его ограничивание до «у нас» — всё таки не объективный показатель (не)успеха.
А что будет объективным показателем успеха? Давайте возьмём Макдональдс в качестве примера успешной франшизы из области общепита.

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

Додо-пицца позиционирует себя как IT компанию, поэтому логичней сравнивать ее хотя бы с JetBrains, касперским, яндексом, мейлру, а не каким-то там общепитным Макдональдсом :)

> Додо-пицца
> IT-компания

Хорошая шутка, мне по нраву.

Собес туда проходил как-то, вполне айти компания. То что они автоматизируют не какую-нибудь логистику (где я щас работаю), а пицца франчайзи мало что меняет.

Это не мешает заказывать еду из вполне оффлайн Макдональдса вполне онлайн Яндекс.едой или Деливери клабом

Если что — это было саркастическое сравнение. Конечно Макдональдс не какой-то, а мировой лидер фастфуда и цифровизация там внедрена неплохо.

А что будет объективным показателем успеха?
Финансовые показатели.

Как насчёт такого критерия успеха: имеется ли хотя бы один ресторан Додо-пиццы в каждом городе мира, из числа тех городов, в которых уже есть хотя бы один ресторан Макдональдса?
По такому критерию нет вообще ни одной успешной фастфуд франшизы, кроме самого Макдональдса. Но вам же не придёт в голову назвать успех KFC «сомнительным», несмотря на то, что у него вдвое меньше точек.

Успех там очень сомнительный, и им до гугла-амазона как до луны.

До гугло-амазона далеко не только додопице, но и газпрому, тинькову и какой-нибудь там Франции. Это не значит, что они не должны исполдьзовать их стек технологий. Успех там вполне ощутимый, если сравнивать с какой-нгибудь другой шаурмечной из сыктывкара без ит-технологий.

Только вот додопицца со своим пафосом и неумелой маркетинговой стратегией (они нанимают 250 разработчиков) ведут себя так, как будто они гугл и какая-то крутая айти-компания, хотя по факту их основная деятельность — это продажа пиццы.

хотя по факту их основная деятельность — это продажа пиццы.

франшизы и её обслуживание.
Успех там вполне ощутимый

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

если сравнивать с какой-нгибудь другой шаурмечной из сыктывкара

А в этом и странность успеха, о которой они не говорят.
Чтобы шаурмячная из сыктывкара смогла стать такойже, ей надо бахнуть в развитие пару десятков лямов… но при типичном заработке шаурмячной (далеко не миллионы в месяц) это практически невозможно… тоесть просвечивает классическая схема «я стал миллионером так — я вырастил поле из зернышка пшеницы и продал его… а потом у меня умер дядя и оставил наследство» (чисто imho, я не знаю подробностей)
Обычно классическая схема богатых франшиз — «я (франчайзи-овнер) добился всего сам, а вы (соинвесторы, покупатели фрнашизы и прочие вложившиеся баблом в бизнес) — просто ленивые и криворукие, поэтому вам не фортануло и я ухожу от вас (с вашими деньгами)». Примеров мильён :)
Как айти-новаторы они наверно хороши, но пицца на троечку. Я лучше готовлю :p

Додо и Доминос — самые норм пиццы что я обычно ем. Так что был бы счастлив поесть вашей пиццы.

Папа Джонс лучше, хоть и дороже )
не берем в расчет всяких Достаевских (потому что не стоит) ))))

Не поверите, но папа джонс мне из всех нравится меньше всех

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

Достаточно показать смету расходов на все это добро у Амазона (ну или хотя бы приблизительно посчитать число инженеров и их зарплаты). Мозг включится моментально.

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

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

Ну не пали контору, кому плохо от того, что мы делаем скворечники, используя для этого инструменты для построения авианосцев?

UFO landed and left these words here

А ещё какой-то из ларьков таки станет хотя бы сетью ларьков и там вложения в ИТ в прошлом не дадут превратиться сети в бардак. Если повезёт.

Если бы меня кто-то спросил, за сколько можно сделать такое приложение в одиночку — я бы сказал: «два месяца на разработку, один на тестирование». Но нас было много, поэтому мы работали больше двух лет.
Жизненно, но зависит от величины проекта.
Сотрудничаем с одной московской студией, у них в штате около 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 году

На волне того "не циклического" кризиса я обернул несколько квартир (которые продавались тогда по пять копеек пучок) и неплохо поднялся (+ скупка акций на падении и продажа несколькими годами позже на подъёме).


а кризис падения эффективности капитала

Не Вам одному эффективность вложения капитала покоя не даёт.

И были правы. Текущий кризис — это тот самый, который начался в 2008. Реального экономического роста с тех пор ещё не было. Искусственная накачка финансовых рынков не считается. Ну, а спекуляции в любом кризисе позволяют подняться. Это не новость. Как говорил чувак из Игры Престолов: "Хаос — это лестница".

Прочитал обе части про разработчикономику. Очень напоминает книгу "Netократия". Местами — до степени неотличимости от краткого пересказа.

Что бы оставалась ценность надо все оформлять как продукт (регистрировать ПО, opensource). Если получилось использовать нейросеть, обученную сотрудниками в процессе своей деятельности (не ИТ, любая деятельность, имеющая аналитику в каком-то виде) и ее оформить как продукт, то это тоже имеет ценность. Все надо оформлять на компанию, а не растаскивать по физикам.

Просто гора кода, конечно, не нужна.
Что? Скупили за $1? Кто у кого что скупил? Гугл у обанкротившихся стартапов поисковый движок купил? Или Фейсбук, который возник через дохрена лет после краха, купил исходный код обанкротившихся соцсетей 90-х?

Единственная история, которую помню о скупке чего-либо после краха доткомов, это когда Getco скупили сервера после краха доткомов, и поднялись на HFT. Но там история сильно нишевая, да и те сервера, уверен, через год уже устарели, учитывая скорость роста тактовых частот в то время.

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

Распространенное мнение разработчика: виноват заказчик. Всегда.
UFO landed and left these words here
Заказчик в подавляющем большинстве случаев неквалифицирован, именно поэтому он идёт к специалисту в надежде, что тот поможет решить его проблему. Его проблему, а не проблемы программиста.
UFO landed and left these words here
Да, но услугу оказывает он. У меня нельзя сказать, что большой опыт в заказах, но, по моим наблюдениям, разработчики делятся на два типа: одни точно знают, что и как надо делать и крайне болезненно относятся к предложениям заказчика, а вторые заказчика более-менее слушают. Со вторыми мне как-то результативнее удавалось поработать. Что не отменяет задачу заказчика сесть за стол и хорошенько подумать над ТЗ.
UFO landed and left these words here
Вы привели прекрасный пример из совкового прошлого. Тогда как раз все делали работу, результат мало кого интересовал (кроме оборонки). Поэтому ширпотреб стремились купить за границей.
Если у вас не получилось толково внедрить agile — это не повод его ругать. У меня был положительный опыт, хотя и не в IT-сфере.
UFO landed and left these words here

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

Ещё часть проблемы в том, что многие разработчики на позиции разработчиков, считают, что их наняли чтобы разрабатывать почему-то — странные, да?.. Приходит менеджер к разработчику и говорит: нам нужен интернет-магазин, за сколько мы его можем сделать? Ну, разработчик спрашивает требования, ему их дают (постфактум неполные дае на момент опроса) и даёт оценку: полгода. Исходя из простого факта: менеджер пришёл к разработчику, а не к веб-мастеру или интегратору.


Хотя разработчик может упомянуть альтернативы: "есть готовые универсальные движки интернет-магазинов, но я с ними не работал, а по слухам очень сложно кастомизируются и жрут немерянно ресурсов, и есть даже готовые интернет-магазины как сервис, так они вообще вроде бы только логотип позволяют поменять. И какую бы альтернативу не выбрали — я увольняюсь, их выбор покажет что я вам не сейчас не нужен"

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

Вот очень правильное guarding condition, очень.

— корова всё же сдохла…
— чёрт, какая жалось, у нас ещё столько идей было!
(с) анек
Бизнес-консультанты во многом похожи на частных врачей: проблему выгоднее лечить, чем вылечивать.

Теоретически, если менеджер подошёл к разработчику, значит к бизнес-консультанту, чтобы это не значило, он уже подходил и тот ему сказал, что надо своё пилить :)


На мой взгляд, всё же, выбор между какой-то "коробкой", "облаком" и кастомной разработкой, обычно архитектор делает. Ну или предоставляет технико-экономические расчёты на варианты, а менеджер выбирает.

Архитектор да, как раз в качестве бизнес-консультанта часто и выступает. Но это тоже не идеальный процесс, архитектора 1с спрашивать, чем лучше заменить 1с.
Например, на последней работе я сделал прототип проекта за сутки — и это 60% всей работы, нужной для выхода на рынок

Вы ведь помните закон Парето? На всякий случай напоминаю


Закон Парето (принцип Парето, принцип 80/20) — эмпирическое правило, названное в честь экономиста и социолога Вильфредо Парето, в наиболее общем виде формулируется как «20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата».
Вот только последние 5% продукта до выхода на рынок делаются столько же, сколько и 95% продукта до этого. Экономист Парето тихо завидует в сторонке. И это пока он не посмотрит на то, как Google допиливает поиск последние 15 лет.

А тут уже 60% сделано — 90+% результата? :)

Не так страшны первые 80% проекта, как вторые 80%.
Применяем закон Парето к оставшимся 20 % и вгоняем все это в рекурсию.

Догонит ли когда-либо Ахиллес черепаху?

Уже которая статья Фила где всё спорят и спорят в комментариях: "Всё так", "Всё не так", "Вот тут так, вот тут не так". А для меня эти статьи — просто повод задуматься, посмотреть на себя со стороны (да хотя бы со стороны Фила). Подумал, где-то согласился, где-то не согласился, но понял, почему есть именно такие разные мнения.
Ожидаемо прицепились к 60% — понятно почему. Возможно ли такое — почему бы и нет? Идеи могут быть достаточно компактными, а коммуникации — весьма затратными.
Никто не зацепился за последние 4-5 абзацев. То ли все согласны, то ли не дочитали, то ли так подгорело, что аж захлебнулись желчью. Думаю всё вместе. А они неплохо подытоживают статью, особенно предпоследний.

Как вторая? А мне кажется, он как раз и отличается подобными статьями. Просто степень провокации различна — какие-то чуть меньше цепляют за живое, какие-то чуть больше, но мимо пройти нельзя :)

Вообще у меня уже сформировалось вИдение Фила — это не разраб, ни в коем разе. Не тимлид. Это философ-евангелист не знаю какой идеологии, но с конкретными такими навыками работы с аудиторией.

У меня в комментарии нет слова "вторая" :)

Сорри ))) Да, согласен полностью.
Я могу зафигачить целое приложение за месяц. Например, на последней работе я сделал прототип проекта за сутки — и это 60% всей работы, нужной для выхода на рынок.


Если это приложения из домена в котором у вас уже накоплен опыт двух лет работы в команде из 10 человек то да — можно повторить. Попробуйте что-то написать из незнакомого домена, к примеру у меня обширный опыт e-commerс, сейчас я в fintech и несмотря на то что вроде как что-то смежное с e-commerс, но мне сложно.
во многом согласен. сейчас поддерживаю проект в котором настолько много всего усложнено, что я с трудом могу в нём разобраться, хотя по сути проект простой. странно видеть подход фреймворка в терминальной задаче с конкретным тз
ИМХО, дело тут не в «заигрались в Google». Дело в том, что «сделать как получится» и «сделать как сказано» — это 2 очень разные задачи. В первом случае ты по максимуму делаешь то, что у тебя хорошо получается, поэтому выходит быстро и относительно качественно, но это «как получится» со временем может очень сильно увести проект в сторону или даже завести в тупик. Во втором ты вынужден тратить время на изобретение не очень понятных велосипедов, зато заказчик получает ровно то, что заказывал.
Хм, внешне напоминает проблемы неопытного менеджмента. Рецепт простой, берем программиста и говорим ему «Теперь ты главный на проекте, должен все знать», он тут же заводит таск менеджер, доку, и еще пяток инструментов контроля. В зависимости от чувства ответственности может дойти даже до скрытого контроля за рабочим столом. Заодно введет правила написания кода, как раз чтобы не допускать ошибок легаси, и чем больше опыт тем страшнее и не актуальней эти правила, вплоть до именования переменных из ветхого стандарта для си применяемые где-то в битриксе. И конечно каждый инструмент и каждое правило направлено на решение конкретной проблемы, но новоиспеченный менеджер плохо осознает что пытается впихнуть всем многолетний опыт.
Ну а главная ошибка таких менеджеров это неграмотная делегация. Такие менеджеры очень редко спускают будущую общую логику, совмещая общие фразы «на проект делает задачу %task» и огромные страницы с кучей определений в доке. В результате могут быть созданы два таска, «сделать корзину» и «сделать каталог», оба таска сделаны, протестированы, работают, одно но — нету кнопки «добавить в корзину». Просто потому что менеджер продумывал киллер фичи для каталога и корзины, и для таких банальностей как покупка времени не нашел. Ну а тестеры и разрабы вообще решили что это будет следующей задачей) И хорошо если разраб один, он может заметить что что-то не так, но ведь часто эти таски даются нескольким и параллельно. Отсюда и заметка про 60%. Это сделать без киллер фич, но то что уже работает и делает это не плохо. Да потом остальное можно пилить годами, но при этом у вас уже будет работающий продукт. А если делать фичи изначально, то до этапа готового продукта можно и не дойти.
Ой да ладно. Бизнесу не нужен VPN клиент, ему нужно заработать денег. Деньги платят люди, грубо говоря покупая подписку на тот самый VPN клиент. Люди не хотят фичастый VPN клиент без дизайна, люди хотят, чтобы была одна красивая и очень крутая кнопка «сделать хорошо». За красивую и хорошую кнопку они готовы платить — оттуда и берутся другие команды:
  • Дизайнеров — которые делают красиво
  • Дата-тим, которые анализируют данные и грубо говоря по итогу сокращают путь пользователя до покупки
  • Серверная команда — которая делает сервер (если свой протокол)
  • Frontend — ведь сначала пользователю нужно показать сайт
  • Backend — где-то же нужно хранить информацию о премиум пользователях
  • Support — премиум-пользователям нужна поддержка
  • и так далее.

Да и саму библиотеку, реализующую подключение, тоже кто-то должен написать. Таким образом, никто не будет платить просто за форму с кнопками, дёргающими предоставленный кем-то API. VPN клиент — это продукт слаженной работы многих команд, именно поэтому мы делаем то, что требует бизнес, а не то, чего бы нам хотелось. В конце концов, за это мы и получаем деньги, не так ли?
Вооот, уже похоже на голос разума. И вот в контексте всего этого реального, полностью ускользающего от ТС, начинает проглядываться, что разработка прототипа — не то, что на пол сделанные работы не тянет. Это вообще обычно сильно меньше 1/10 всего гемора, через который надо пройти, чтобы сделать Продукт.
Вот ведь, читаешь, как будто про себя ))
Но люди разные, и подходы у всех разные.
Например, я лично полностью солидарен с автором статьи, а вот одна моя коллега напротив, считает что нет ничего лучше вечных проектов. Она мне так и говорит, чем дольше будет продолжаться проект, тем лучше — пока вся эта хрень длится, я уверена, что у меня есть работа.
По-моему все закономерно. Разработка превращается в сервис.
Я не удивлюсь если когда увижу на сайтах помесячные тарифы.

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

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

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

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

P.S.
Кстати нельзя не отметить, что в соответствии с этой тенденцией качество продуктов должно падать. Что мы и можем наблюдать в жизни. Кроме всего и по этой причине крупные фирмы держат людей на постоянке, чтобы хоть как-то контролировать и гарантировать качество.
Ну а в перспективе необходимость в тестировщиках будет расти. Опять же дешевых, тестировщиках-как-сервисах, кнопкотыкальщиках (а не инженерах), но все же.
Почти каждое слово в точку — живу в фирме с приличными оборотами, но «продуктовой», в которой огромный ИТ отдел и много самописных приложений. Одно из них по стоимости уже перевалило за XXмлн рублей — и не закончено — именно тот «бесконечно незаконченный проект», который будет таковым до тех пор, пока… а вот пока — я границ не передумал. Проект насколько завязан на внутреннюю инфраструктуру, что отказаться от него — будет довольно сложно.
Ну и что автор ноет и раскричался? Стартапы не нравятся, так путь не работает в таких проектах.
Денег сейчас очень много в индустрии, если 8 из 10 проектов не доходят до выпуска, то оставшиеся 2 покрывают все затраты с запасом, что и позволяет отрасли экспериментировать в методиках и подходах.
Жил бы в Советском Союзе, работал бы в НИИ за кусок хлеба над какой нибудь очень полезной программой, считающей удои.
Свобода выбора и наличие денег в отрасли ему не нравится виде те ли…

Вроде автору не нравится, что не стартапы играют в стартапы, используя энтерпрайз инструменты

Так денег навалом!=) Играй — нихочу.
И специалистам большая радость — не надо в Гугле работать чтоб попробовать все эти девопсы, кубернетсы, канбаны.
Сплошные плюсы кругом, а он не доволен…
Сплошные плюсы кругом, а он не доволен…

Так и автор на самом деле всем доволен — у него есть повод для очередной статьи.

Взять и сделать — это чушь
Я так преподам о курсовых отвечал
Похоже, малыш не может отличить прототип от законченного продукта. Не ругайте его, мы все проходим через такой этап, когда нас просят проэстимировать задачу.
ну вместо «улучшаю и чиню» пишешь «пилю»
Круто, статья интересная… смотрю на все с не замыленным взглядом, и действительно, согласен с автором.
Хочешь идти быстро — иди один, хочешь идти далеко — иди с друзьями.
Стандартный этап развития :) Множество народа проходит через все эти типовые «озарения» а-ля комментарии не нужны, тесты не нужны, документация не нужна и т.д.
Позднее с опытом человек поймет, что есть не только проекты на пару недель, но и на многие годы, и отнюдь не только в FAANG, что то, что понятно одному разработчику, может быть, ну очень мягко говоря, непонятно другому, что собственно кодинг — это далеко не все, что нужно для продажи продукта, что крэш в неподходящее время может стоить сотни тысяч евро и т.д. В общем с опытом пройдет :)
Кто считал, при каких условиях дешевле писать каждый раз заново (ТЗ на салфетке, никакой документации, в продакшн), а когда юзать все или часть этих инструментов и методологий? Наверняка кто-то сравнивал, все эти накладнуха и спецсофт денег стоят.
it depends © Стандартизированные процессы проще автоматизировать стандартизированными решениями. Например, если бизнес у вас не сильно «специфичный», то коробки 1С вам может хватить без особой магии.
Если же фичей вашего бизнес является какое-то своеобразное видение процессов или что-то такое — то я сомневаюсь, что «переделка» стандартных решений будет дешевле.

В любом случае — всегда надо считать.
it depends
Это-то понятно, но нет ли каких полуколичественных оценок? В производстве обычно понятно, когда менять способ производства.
Это-то понятно, но нет ли каких полуколичественных оценок?

Есть, в целом суммарная «стоимость» проекта за время его жизни должна быть минимальной (или наоборот, чистая «прибыль» от проекта — максимальной).

Сюда входит:
1. Потерянная прибыль из-за возможных ошибок/падений проекта,
2. Стоимость переписывания на нормальную систему,
3. Потерянная прибыль из-за слишком затянувшегося выхода на рынок (появления новых фич),
4. Затраты из-за найма разработчиков на сырой легаси проект/уход разрабочиков из-за плохого кода (или наоборот, экономия из-за сотрудников мотивированных интересным проектов и технологиями),
5. Стоимость добавления и отладки новых фич,
6. И т.п.

В целом, нужно считать «затраты» (в том числе, косвенные).

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

В целом, основной навык архитектора спланировать все так, чтобы получить минимальные суммарные издержки и не доводить до авралов и спасения с тонущего корабля. Иногда для этого нужно изначально не идти по пути «ТЗ на салфетки», иногда вовремя залажиться на глобальный рефакторинг/создание новой надежной системы с нуля в какой-то момент в будущем.

Вопрос, как я понимаю, исключительно о процессах разработки. Когда, например, оправдано внедрение CI/CD, а когда это экономического смысла не имеет.

UFO landed and left these words here

С вариантами, я думаю, глядя на руководство по деплою нового проекта...

Способность быстро собрать из стандартных компонентов проект до стадии MVP — чтобы работал основной функционал и на этом все — это серьезная часть успеха проекта.
Но хороший дизайн и удобное UI, которое приносит радость пользователям (или хотя бы не бесит) не менее важны, уже на этапе выхода проекта в рлиз.
Всему свое время, каждой стадии разработки — свое время.

Это доказано, например:
— студиями, которые делают красивые дизайнерские сайты на битриксе и продают их по цене порядка 1 млн руб (а ведь можно шаблонный за считанные часы собрать, да?);
— производителями телефонов;

Поэтому я бы не призывал делать стандартные продукты из базовых компонентов для небольших фирм. Все большие фирмы были когда-то небольшими. А вдруг этот ларек достоин крутого продукта?

Да и вообще, красота и удобство ценится не мене высоко, почем функционал. Не нужно стремиться свести все продукты к серым прототипам, собранным побыстрее да поскорее.
UFO landed and left these words here
«и это 60% всей работы, нужной для выхода на рынок.»
Написать 60% не проблема. 80 тоже. А вот последние 10-15…

«У нас были четыре разраба, три тестера, продукт оунер, проджект менеджер, сторонняя команда дизайнеров.»


Хорошее начало для фильма «Страх и ненависть в IT».

О самоуверенности. Довлатов как-то пришел на занятие к своему другу — профессору литературы. Тот в разговоре показал на аудиторию, заполненную что-то пишущими студентами и спросил сколько у него заняло бы времени раскрыть одну важную тему о творчестве Пушкина. Довлатов ответил: «Одну неделю». Профессор улыбнулся: «А у меня бы две. Этим же», — снова показал он на студентов, — «хватит одного часа»)) Обращаясь к автору. Вместо этого длинного и весьма претензионного опуса просто прикрепите ссылку на проект, который вы создали лично, в одиночку))
В целом резон в написаном есть. Но… Уже несколько раз сталкивался с таким. Приходит заказчик. Хочу говорит прототип с такими то фичами. Даю столько-то денег. Запиливаем ему прототип на коленке — без нормальной архитектуры и свистелок, просто чтобы работали затребованные фичи. Скажем за месяц. Заказчику прототип нравится — говорит ну давайте теперь с вами работать и расширять проект. И когда ему говоришь — нет дорогой, если ты хочешь получить нормальный проект для широкой аудитории, расширяемый без анальных пыток, то прототип мы выкидываем и начинаем с нуля пилить нормальный продукт с нормальной архитектурой — многие заказчики просто не понимают почему.Ведь работает же. И была у меня на старте карьеры одна контора, которая под давлением заказчика согласилась пилить дальше продукт используя прототип. В результате получился такой монстр, что лучше в исходники не лезть было. Но заказчику нравилось, продукт деньги приносил, а то, как трахаются девелоперы чтобы добавить очередную фичу никого не волновало. Благо я в этой конторе надолго не задержался.
UFO landed and left these words here
Никого не волнует как вам или мне или тому парню тяжело, пока доходы выше расходов — все делается правильно

«Тяжело» тоже имеет денежное выражение, в виде уволившихся сотрудников, плохой мотивации и нежелании кадидатов связываться с этим проектом даже за зарплату выше средней по рынку.

Плюс, выигрыш в краткосрочном планировании может оказаться проигрышем в долгосрочном (пока в проект добавляется одна фича — конкуренты выкатывают уже десяток по той же себестоимости).
UFO landed and left these words here

Их ещё волнует недополученные доходы, недополученная прибыль. Если в таких терминах объяснять, то проще выбивать ресурсы на "переписать"

> У каждого проекта есть точка невозврата — момент, когда ответ на вопрос «а не полную ли хрень мы делаем» уже не имеет значения

ЕМНИП это в этическом разделе Проджект Менеджмента есть — как только ПиэМ понимает, что проект не сможет/не будет отвечать критериям Содержание/Сроки/Стоимость он обязан сообщить это стейкхолдеру. Ну, конечно, если это сертифицированный ПиэМ, и не боится быть лишенным «корочки»
Менеджер может и не понять — ибо проект будет отвечать бизнес требованиям.
Да, тут есть специфика, согласен

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

На английском бы вашу статью, она как никогда сейчас актуальна на моей работе
Для того, чтобы ускорить рабочий процесс, приходится прибегать к различным методам. Например, меня радует, что для заполнения товарами новосозданного интернет-магазина больше не нужно вносить по одному товару вручную. Для этого есть парсеры. И даже не обязательно уметь ими пользоваться — можно снять с себя весь головняк, и просто заплатить людям чтоб они скачали-залили. Вот, недавний опыт показал, что эти ребята хорошо справляются: parsing.top
Пусть билд крутиться 6 часов — у меня как раз много важных дел дома, но ты должен понимать — мое время стоит дорого. А платить ты вздумал не за продукт, а за игру в разработку. И я с тобой поиграю.


Счастливчик.
Ему платят не за результат, а за процесс.

а есть другие примеры? Неужели вы не платите разрабам, пока они работают в течение 3-6 месяцев, причем, зачастую, с непредсказуемым результатом?
Непредсказуемый результат разработки является тем редким случаем, когда можно точно сказать, что это недостаток компетенции менеджеров.
Очень часто конечный продукт отражает то, что написано в ТЗ, но все недовольны. Я такое встречаю сплошь и рядом, и, подозреваю, тут проблема на стыке бизнеса и ит, где-то в районе общего видения продукта, коего не достигли еще на самом первом этапе.

Но вопрос был все-таки про то, как расплачиваются с программистами, пока результат не достигнут? Ведь им платят за процесс, а не за результат. Тогда как s75 писал, что знает, где платят за результат.
Насколько я понял, чтобы программисты делали то, что заказчик хочет, а не то, что он пишет, аджайл и придумали. А поскольку хочет он разного, внезапного и не всегда внутренне консистентного, то и иного способа, кроме как платить за время, нет. За результат можно платить в когда утрированные водопад или V-модель, т.е. приёмка только по соответствию с ТЗ (которое есть, подробное и неизменное).

Платить можно по разному и с аджайлом. Главное найти согласных на эту плату.

так я о том же, за результат можно премировать, но платить все равно придется за время.

p.s. премировать за то, что в итоге работа сделана корректно — это признавать, что разработка нынче все еще подобна золотодобыче.

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

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

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

Если премии платились наличкой, то, возможно, с неё вообще забыли заплатить налоги ))
Налог меньше с дивидендов — там нет отчислений в ПФР (а раньше еще и ставка была меньше). А что зп, что премии — они облагаются одинаково и по одной ставке. Для белой ЗП, конечно.
А что зп, что премии — они облагаются одинаково и по одной ставке.

если речь про 13% — нет, мы не про них. Мы про социальные отчисления и все прочие.

С премии они так же платятся.
Налоги не платятся только с премий, выписанных лично Президентом или Правительством РФ. Любые доходы физлица по обычному месту трудовой деятельности находятся в одном общем котле.
Погуглил — да, действительно, с премии платится тот же НДФЛ и та же социалка. Возможно раньше было по-другому (из той компании я ушёл в 2014, за 6 лет могло многое измениться), а может переводят часть оклада в премию, чтоб легко можно было срезать — «денег нет, но вы держитесь».
Возможно раньше было по-другому
Последние двадцать лет точно было одинаково, до того не скажу.
переводят часть оклада в премию, чтоб легко можно было срезать
Это единственная причина.
как программист может повлиять на проект? Т.е. его надо премировать за то, что проект не завален именно по его вине?
Можно попытаться сдать проект раньше срока. Тогда всем причастным и будет премия.
И урезание сроков на следующий проект. ИМХО, премию нужно платить только за выход за пределы должностных обязанностей.

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

Если такое случилось раз или два — может быть. Но если человек регулярно раньше сроков сдает свою работу — тут что-то не так с планированием у него. Я уж не говорю о том, что, по этой логике, за сдачу не во время, его надо штрафовать? Нет, программист — такой же человек, с такой же плавающей производительностью, как и все. Его надо обеспечить нормальной фикс зарплатой, нормальными условиями труда, может быть премировать за что-то: прорыв какой-нить или в самом деле много сверхурочных в случае форс-мажора. При этом, программисту надо дать понять, что есть норма на проекте: какие-то бюрократические вещи, какой-то этикет и стандарты и объяснить — что либо вы соглашаетесь с «правилами» и работаете по ним, либо нет.

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

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

Если же сдали раньше, но этого особо никто не ждал, профита не принесло, то «ну окей». Сдали также раньше во второй раз — класс. В третий — с планированием какая-то беда?
Only those users with full accounts are able to leave comments. Log in, please.