Чтобы понять позицию «твой код никого не интересует», надо подойти со стороны бизнеса: зарабатывание денег, выплата ЗП своим сотрудникам, уплата налогов, в общем, с точки зрения доходов/расходов компании или отдельно взятого человека. Например, утверждение «идеальный код — залог успешного бизнеса» может казаться логичным, но с точки зрения доходов/расходов далеко не всегда истинно.
Например, малофункциональный продукт или продукт недостаточного качества для бизнеса, продающего этот продукт, может быть куда полезней, чем полноценная рабочая версия. Это звучит нелогично, но, увы, больше похоже на правду.
Это можно понять на примере покупки автомобиля. Когда вы приходите в автосалон, вам с радостью предложат весь модельный ряд для покупки, из которого вы сможете выбрать авто себе по вкусу и по карману. Но вам никто и никогда не скажет, что, заплатив за базовую комплектацию 10 000$ (эта и следующая цены условны), вам надо будет доплатить ещё 5 000$ за установку дополнительных наворотов в виде магнитолы, электроподъемника стекол, кожаного салона, хотя кажется, что всё это должно входить в указанные в начале 10 000$. А также дальнейшие ТО, покупки запчастей и т. д.
Т. е., предложив клиенту свой малофункциональный продукт за 100$ и установку его за 1 день, а еще доработку продукта под клиента за 500$ и 3 дня, компания выигрывает. А ещё клиент подписывается на годовую поддержку продукта за 100$/мес. И малофункциональный продукт выжал на 1700$ больше, чем если бы сразу продавалась полноценная версия.
Также логичным и понятным кажется: чем больший объем заказов за минимально потраченное время выполнит компания, тем больше будут её доходы и тем выше шансы выплаты зарплат для её сотрудников. Если компания за месяц зарабатывает на выполнении работ 1000$, а платит зарплату 500$, то перенос сроков проектов будет чреват неприятными последствиями в виде задержек выплат ЗП и пр.
Это значит, если вы не пишете ПО для ракет/спутников, трейдинга, мед. оборудования и т. д., то, скорее всего, ваш доход (или доход вашей компании) не завист напрямую от качества кода. А это значит, что ваш доход зависит от ваших объемов и скорости разработки, из чего выплывает, что «твой код никого не интересует».
Эта статья — не призыв к снижению качества разработки. Просто из-за излишнего перфекционизма и возможности заложиться под «будущие фичи» разработка многих проектов затягивалась на месяцы. Это попытка показать, что, кроме идеального и удобного кода, есть и другие, не менее важные, приоритеты и следует их учитывать при разработке.
Комментарии (116)
LastDragon
30.04.2015 12:35+1> Т. е., предложив клиенту свой малофункциональный продукт за 100$ и установку его за 1 день, а еще доработку продукта под клиента за 500$ и 3 дня, компания выигрывает.
А что помешает клиенту сразу купить продукт у конкурентов за 250$, сэкономив таким образом почти 1500$? (конкуренция то сейчас огромная)
legobrain Автор
30.04.2015 12:46Я всего лишь пример привел. Можно и за 250 баксов продать, для бизнеса такой вариант, всё равно, лучше чем стартовые 100$ :-)
khim
30.04.2015 19:36+1А что помешает клиенту сразу купить продукт у конкурентов за 250$, сэкономив таким образом почти 1500$? (конкуренция то сейчас огромная)
Отсутствие цен $250 и $1700 на ценнике, очевидно. Это из той же серии, что и пакеты молока по 700 грамм и гречки по 900.
Казалось бы: ну кем нужно быть, чтобы на это купиться? Но кошелёк не обманешь: продажи растут.
js605451
30.04.2015 12:41+8Чтобы понять позицию «твой код никого не интересует», надо подойти со стороны бизнеса: зарабатывание денег, выплата ЗП своим сотрудникам, уплата налогов, в общем, с точки зрения доходов/расходов компании или отдельно взятого человека. Например, утверждение «идеальный код — залог успешного бизнеса» может казаться логичным, но с точки зрения доходов/расходов далеко не всегда истинно.
Задача бизнеса — обеспечить поток денег. Задача инженеров — обеспечить поток фич. Эти 2 задачи безусловно «как-то» связаны друг с другом, но не обязательно так, как описано в статье. Если бизнес завязывает поток денег напрямую на поток фич — это проблема бизнеса, а не инженеров.
max-kuznetsov
30.04.2015 12:45Автору респект. Правильную тему поднял.
Мы последние годы в обязательном порядке в процессе разработки учитываем не только требования заказчика, но и интересы своей конторы. У нас есть стадия анализа востребованности проекта, где мы решаем, насколько и в каком объёме нам (нам, а не заказчику!) нужен продукт. При разработке требований мы учитываем и требования заказчика, и требования своего бизнеса. Фичуризм учитывается как риск. При реализации всегда исходим из минимальных затрат, позволяющих удовлетворить требования заказчика. Начиная с концепции и заканчивая кодированием.
Это даёт свои плоды. Наше ПО применимо, работает правильно и чуть лучше, чем у конкурентов. Может работать ещё лучше, но… всему своё время.
prishelec
30.04.2015 14:11+1Все чаще встречаются статьи «о качестве кода» да и от своих коллег, тоже подобное слышал (тех, кто на конторах работает). А слышу одно: в бизнесе нужны деньги и чтобы работали твои алгоритмы. А как они работают это уже никому не интересно.
Кстати печально, но такова правда жизни.max-kuznetsov
03.05.2015 10:17+1Ваши эмоции понятны. Но картина несколько другая. У нас, во всяком случае.
У нас разрабатывалась несколько лет назад комплексная система безопасности. Поставлялась как «коробка». Покупателей было не очень много, но они были, и проект приносил прибыль. К нам приехал начальник службы безопасности АФК «Система» с кучей фич, которые, как он считал, самые нужные и обязательно должны быть реализованы в нашем продукте. Надо сказать, он был сильно удивлён, услышав мой твёрдый отказ. У нас была стратегия развития продукта, и его фичи нарушали эту стратегию. Мы могли попасть на сопровождение «кастомной» версии, что могло сделать проект убыточным в среднесрочной перспективе.
Мы включили в проект только небольшую функцию для поддержки печати пропусков на магнитных картах. Небольшой плагин. И таки поставили наш продукт в АФК. И получили благодарность и рекомендации, благодаря которым смогли привлечь других покупателей.
На самом деле, заказчику ВАЖНО как работает код. И бизнесу это очень ВАЖНО. Потому что корректно написанный код, учитывающий жизненно важные потребности исполнителя и заказчика, становится опорой для бизнеса и того, и другого.
Но да, есть вещи, которые бывают неважны. Например, если один и тот же функционал может достигаться применением старой, проверенной и надёжной технологии или новой, перспективной, но пока не проверенной, и заказчик, и топ-менеджмент исполнителя предпочтут первое, хотя программисту хотелось бы использовать второе.
Так что код интересен всем, но у каждого при этом свой интерес.
max-kuznetsov
30.04.2015 13:02+6Вспомнилось тут, что у Джоэля Спольски была заметка «Мастерство». Он там говорил, что иногда исправление 1% ошибок влечёт 500% усилий. Так вот, лучше я со своей командой сделаю ещё 5 проектов, чем буду править ошибку, которая не сказывается на применимости и правильности нашего ПО. И, заметьте, если эти проекты будут сделаны для одного и того же заказчика, он будет больше счастлив, чем если бы ему пришлось ждать всё это время от нас исправления бага, незначительного для его бизнеса.
grossws
30.04.2015 21:34Это всецело зависит от области деятельности. Если решаемая задача mission critical или, тем более, life critical, то увеличение затрат в 5 раз ради сведения вероятности какой-нибудь определенной ошибки с 1% до 0.1% может оказаться оправданным.
Как всегда, это вопрос рисков (т. е. вероятности ошибки на сумму убытков от её реализации). И, если риск маленький (низкая вероятность и/или маленькие потенциальные убытки), то любой разумный управленец на эту ошибкуположитпоставит резолюцию «не трогать».
Calc
02.05.2015 18:32то любой разумный управленец...
Мне кажется, но весь смысл этой статьи именно в этой фразе.
И никогда не будет разногласия кто что и как будет делать.
А если к людям подходить как к винтикам в системе, которые можно заменить, то можно и не начинать разговор о проф навыках.
Это из личного опыта, совсем недавнего
Поработал на одну организацию где на качество забивали болт.
Выполнял работу в 3 раза быстрее тех программистов (качество когда было лучше раз в 5, их еще пришлось обучать при учете, что я раньше не работал программистом, только ради фана программировал), сделал их работу, запустил этот «стартап» за 2 месяца (без меня сидели 4). Ушел из этого болота.
fogone
30.04.2015 13:41+18Написать данный комментарий подтолкнули меня комментарии, а точнее сама статья, которая говорила о полном или частичном непонимании того, что смотреть с точки зрения бизнеса программисту есть смысл, только если это его бизнес или он по совместительству заодно и продает этот продукт. В остальных же случаях, программисту вполне достаточно того, что он хорошо делает своё дело — выполняет свою техническую работу. А с точки зрения бизнеса на бизнес смотрят те, кто этим бизнесом занимается. Потому что они получают за это деньги. Так что хватит мешать отвественности.
printf
30.04.2015 13:54+3Как говаривал один популярный бюрократ, you are technically correct — the best kind of correct.
Однако понимание программистом бизнеса — это полезный навык. Будучи скорее программистом, я бесконечно далек от мысли, что надо бросаться делать работу за директоров; с другой стороны, мы с директорами в одной лодке же.
Сегодня я приложу усилия, чтобы понять их приоритеты, а завтра они с ненулевой вероятностью захотят в ответ понять мои — и жизнь станет лучше, трава зеленее, совокупные чемоданы с деньгами толще.fogone
30.04.2015 16:15+3Конечно, я ни в коем случае не предлагаю «не понимать приоритеты бизнеса». Просто говорю о том, учитывать их в своей работе — не задача программиста. Думаю, этим вполне может заниматься ПМ или кто там еще стоит между программистами и бизнесом. Именно он учитывает приоритеты бизнеса, когда транслирует реквест в задачи программистам (именно поэтому интересы бизнеса будут удовлетворены, а не потому что программист приложил усилия, чтобы понять чьи-то приоритеты). И наверное программисту морально проще понимать зачем нужен реквест, но по большому счету совершенно не обязательно. А если бизнес своими реквеставми требует от тебя работать не так, как ты считаешь возможным, то ты просто находишь более подходящего постановщика задач, ведь в конечном итоге, ты строишь не свой дом, а дом какого-то дяди.
legobrain Автор
30.04.2015 14:58-5Баба Клава должна держать офис в чистоте, потому за целостностью оборудования после её уборки должны следить программисты и админы. Хватит уже мешать ответственности.
max-kuznetsov
03.05.2015 10:27+1Программисту имеет смысл всегда смотреть на продукт с точки зрения бизнеса, потому что бизнес на самом деле для него главный и единственный заказчик. Если он не продаёт продукт и это не его бизнес, то на этом все разговоры заканчиваются, и он просто выполняет именно то, что правильно с точки зрения бизнеса. Или идёт искать другую работу.
Но если программист проявляет усердие и воспринимает продукт как свой бизнес, то у него появляется возможность проявлять инициативу и за счёт этого расти. Он начинает по-другому воспринимать желания заказчика и своего руководства, и, понимая разницу между желаниями и истинными потребностями и имея техническую подготовку, может предлагать весьма интересные альтернативы. И тогда ему доверяют больше, платят больше, стараются дать более ответственные проекты.
Конечно, только сам программист решает, как воспринимать свой продукт.
0xd34df00d
06.05.2015 13:30-1расти
А куда, позвольте, расти?max-kuznetsov
07.05.2015 23:11Путей много. Я вот до архитектора дорос. Знакомый техническим директором стал в не самой слабой компании. Как говорил старина Деминг: «Совершенствоваться не обязательно. Выживание — дело добровольное.»
0xd34df00d
08.05.2015 13:51Но если я не хочу быть никаким директором, а хочу расти как, гм, программист и, в идеале, и математик ещё?
max-kuznetsov
08.05.2015 20:01Рост — понятие комплексное. Если менеджеры чувствуют Ваше понимание и видят Ваши способности, они дают Вам более ответственные проекты, в результате чего Вы получаете возможность изучать новые технологии и работать над более сложными проблемами. Бизнес начинает вкладывать в Вас деньги: у Вас появляется более комфортное рабочее место, более качественное оборудование, нужная поддержка со стороны других специалистов. Возможно, Вас пошлют на курсы повышения квалификации, особенно, если бизнес заинтересован в наличии у некоторых сотрудников «корочек». Иными словами, профессиональный рост программиста имеет сильную зависимость от его
лояльностипонимания интересов бизнеса.
Но должен Вас огорчить. Одним из интересов бизнеса является рост Вашей ответственности. Не только ответственности за свой код, но и ответственности за работу всей команды в целом. Те же «корочки» бизнесу нужны, чтобы показать потенциальному заказчику способность команды реализовать сложный проект. Но заказчика редко интересует рядовой программист с кучей корочек. Заказчику нужны ключевые разработчики — архитекторы, тим-лиды, ведущие программисты. Те, с кого он может спросить.
Поэтому, если Вы хотите развиваться как программист, Вы должны понять, что отсидеться в стороне не удастся. Как говорил Джоэль Спольски:
«Ты никогда не стремился стать менеджером. Как и большинство разработчиков программ, с которыми я знаком, ты был бы гораздо счастливее, если бы тебе позволили спокойно сидеть и писать код. Но ты лучший разработчик...»
legobrain Автор
30.04.2015 13:45-8Баба Клава должна держать офис в чистоте, потому за целостностью оборудования после её уборки должны следить программисты и админы. Хватит уже мешать ответственности.
vedenin1980
30.04.2015 15:23+5Нет, бабе Клаве должны сказать где можно мыть, а где нет. Это разделение ответственности. Вот если баба Клава сама начинает решать как и что её мыть — вот тогда она берет ответственность системного администратора на себя.
В случае программистом должны быть те (бизнес аналитики, продажники и ПМ'ы) кто скажет что нужно мыть, а что ни в коем случае. Это называется планированием имплементации и это не задача программиста. Задача программиста — сделать поставленные задачи в нужном объеме, максимально качественно/быстро.legobrain Автор
30.04.2015 15:33-5максимально качественно/быстро.
Я бы заменил на «максимально качественно и быстро». Правда максимально качественно как это возможно за определённый период времени :-)
Программисту как и бабе Клаве говорят что сделать и за какой период, а они берут и начинают фичи на будущее добавлять, новые суперправильные подходы применять и пр. самодеятельность.
Вот приведу пример из недавнего. Мы в нашей компании писали сервис на ангуляре 1. Писали около года. Заложились на фичи под будущее. А потом бац! И вышла версия №2, не сильно похожая на версию №1. И скорее всего когда наступит то будущее, когда будут внедрятся фичи будущего, будет уже третья версия ангуляра. И спрашивается зачем все эти старания были и будет ли в будущем поддержка нашего кода легче и проще?vedenin1980
30.04.2015 16:05+14Понимаете, вы сейчас свой опыт JavaScript разработчика пытаетесь эстрополировать вообще на любых программистов. Я не пытаюсь никого обидеть, но в силу ряда особенностей самого языка JavaScript и особенно фреймворков на нем зачастую действительно приходится делать выбор между писать правильно/красиво или быстро.
В промышленных языках бекенда (вроде Java, С# и т.п.) все сделано (от самого языка до IDE) для того чтобы наиболее правильный и красивый код был бы одновременно наиболее быстрым для написания и легким для отладки и понимания остальными (ибо для того они и разрабатывались). Поэтому там предложения «а давайте мы быстро тут наговнокодим» воспринимается как извращение в особо сильной форме. ИМХО, конечно.vedenin1980
30.04.2015 16:14+5Ну, и к тому же если на вебе ошибки в коде как правило лишь слегка мешают пользователю, то в беке клиент легко может потерять данные или деньги.
В целом за 10 лет разработки на Java я практически ни разу не сталкивался с ситуацией когда говнокодирование выигрывало по скорости (не берем всякие одноразовые классики для служебных целей)
legobrain Автор
30.04.2015 16:21-3Кстати, я не писал о «а давайте мы быстро тут наговнокодим». Если в Java, С# и т.п. качественный код пишется быстро и легко — это невероятно прекрасно. Разработчикам на этих языках повезло.
Я писал о том, что во главу угла проекта надо ставить финансовую сторону, так как без неё программист не сможет просто работать, так как не ясно откуда возьмутся деньги ему на ЗП. А ещё точнее: качественный код не приносит деньги, деньги приносят клиенты. Это не значит, что им надо напаривать говно, просто у них может быть запущена реклама через месяц, потому к этому времени надо подготовить проект и времени на изящества может не быть.
Если в Java, С# и т.п. говнокод — удорожание, пишите без говонокода. Если в вашем языке нет быстрых изящных решений, то не стоит бояться костылей. В общем, смотрите по финансам и времени.js605451
01.05.2015 13:32+2во главу угла проекта надо ставить финансовую сторону, так как без неё программист не сможет просто работать, так как не ясно откуда возьмутся деньги ему на ЗП.
Ваш подход будет замечательно работать для команд, состоящих из одного человека. В случае команд из двух и более людей начинаются проблемы :-)
Программист будет работать в компании только до тех пор, пока ему нравится работать в этой компании. «Нравится» состоит, например, из: размера зарплаты, гламурности офиса, «веры» в востребованность своей работы, профессионального роста и ещё пары десятков очевидных и не очень очевидных вещей.
Программист (если это «профессиональный программист», а не «студент») стабильно работает с примерно одной и той же производительностью — у него нет перепадов типа «я вчера запилил десяток фич, поэтому следующие 3 дня работать не буду, а после этого буду работать вполсилы». Например, программист может делать одну фичу в неделю. Стабильно.
Бизнес (основанный на программировании) будет существовать только до тех пор, пока появляются новые фичи. Если в команде есть 5 программистов, можно теоретически ожидать 5 фич в неделю. Так вот задача бизнеса — продавать эти самые «5 фич в неделю» таким образом, чтобы в итоге и на зарплату хватило, и компы новые можно было купить, и ещё осталось «на всякий случай». И конечно же речь не идёт о том, чтобы взять «хочу столько денег», поделить на «есть столько фич» и пытаться продавать фичи по той цене, которая получилась. Где-то здесь появляется «суть бизнеса» :-)
cdmax2002
30.04.2015 14:19+3Если сравнивать с автомобилем, то дополнительное оборудование которое может/должно входить в стоимость и качество автомобиля, это разные вещи.
Качество, кстати, всегда работает на перспективу.
Сравните качество BMW и GreatWall.
То же самое и с кодом.
Archon
30.04.2015 16:03+6Далеко не всегда качество работает на перспективу, поскольку стоимость обеспечения качества «сейчас» и «спустя год после начала продаж» может отличаться в разы и даже на порядки, и почти всегда не в пользу варианта «сейчас». Зачастую случается так:
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге.
Отдельно от себя добавлю к примеру, что у Пети, который работал «на перспективу», в большинстве случаев получится не «вылизанное приложение», а никому не нужная фигня, оторванная от реальности, поскольку за всё время он был единственным её пользователем, и у него замылился глаз ещё на второй день разработки.
Пишите код, который можно выкатывать на реальных пользователей, с минимальной оглядкой на качество кода. Вы не знаете, что хотят пользователи. Даже заказчик не может заглянуть им в головы и узнать, что они хотят. Позвольте пользователям как можно быстрее работать на кривом-косом MVP, и они сами вам покажут, что им надо. Возможно, через неделю на основе фидбека вы выкинете 90% этого кода и начнёте развивать продукт в совершенно другом направлении. А возможно, он начнёт приносить деньги, и вот уже тогда вы и займётесь качеством.
ServPonomarev
30.04.2015 15:20+5Код — он очень разный. Один код идёт в репозиторий на многолетнюю поддержку, другой — пишется на коленке в исследовательских целях и будет запускаться 2-3 раза. Тратить время, делая исследовательский код понятным и сопровождаемым — точно такая-же пустая трата ресурсов, как и сопровождение плохого кода. Только ресурсы эти тратятся здесь, сейчас и вами, а не в предполагаемом будущем вашими сменщиками.
Код должен быть читабелен и поддерживаем ровно настолько, насколько этому коду необходимо с учётом его жизненного цикла. А красоту пусть наводят энтузиасты в сверхурочное неоплачиваемое время.legobrain Автор
30.04.2015 15:41-2Именно!
А красоту пусть наводят энтузиасты в сверхурочное неоплачиваемое время.
К сожалению, гражадане этого не понимают и зачастую всё делается «в урочное оплачиваемое время» :-(
defuz
30.04.2015 19:18+4Я думаю, самая важная фраза ServPonomarev была
Код должен быть читабелен и поддерживаем ровно настолько, насколько этому коду необходимо с учётом его жизненного цикла
А вы вырвали из контекста только то, что хотели увидеть.
selenite
01.05.2015 11:43То есть вас устраивает формулировка «после 18 идите в жопу со своим подходом»?
Dinir102
30.04.2015 15:52+8Так и зародились DLC, которые никто, кроме самого разработчика, не любит. Нельзя толкать людей на такое, ибо скоро люди на таких примерах пойдут делать цены в магазине таким образом:
«Покупайте эту газировку 0.2л всего за 2 рубля!!!» А ниже мелким шрифтом будет написано: Цена, указанная выше, идёт за упаковку. За наполнение упаковки водой вам придётся заплатить 20 рублей, за газ 15 рублей, за ароматизатор 5 рублей и за краситель 7 рублей. Итого мы получаем «Газировку» стоимостью 49 рублей.
ЭТО ЗЛО!
OlegTar
30.04.2015 16:17Статья не об этом. Статья о том, что бизнесу плевать на то, что вам надо время, чтобы написать хорошо или переписать код, ему нужно, чтобы фичи новые запиливались побыстрее, к сожалению.
maledog
30.04.2015 16:06+3Программисты не понимают
Собственно администраторы тоже негодуют. Если работаешь где-то более 5 лет, то видишь, что покупка плохого продукта выливается не только в излишние затраты на оборудование, но и в затраты на поддержку. Так что, написание плохого кода — краткосрочная выгода.OlegTar
30.04.2015 16:14-2тем не менее эта выгода рулит бизнесом, факт
OlegTar
30.04.2015 17:03-1P.S. Нужно стараться писать идеальный код, конечно. Только вот у бизнеса, к сожалению, на это нет ни времени, ни желания…
Имхо, если это решать, то это надо делать программисту самому, оставаться вечерами в неоплачиваемое время и переписывать большие куски кода. Потому что бизнес не понимает, почему надо переписывать код, и не будет выделять на это время.vedenin1980
30.04.2015 17:17+1что бизнес не понимает, почему надо переписывать код, и не будет выделять на это время.
Просто вы не с тем «бизнесом» сталкивались. Нормальный «бизнес» относится к «качеству продукта» как к машине, непонятно зачем ремонтировать, если вроде и так бегает, но если уж тот кому доверяешь сказал «в сервис» — значит «в сервис». Вопрос тут найти такого технического менеджера, которому «бизнес» мог бы доверять.
defuz
30.04.2015 19:07Ну если вы готовы батрачить на работодателя сверхурочно за бесплатно, то ради бога. Но лучше бы вы это время в open source вкладывали, честное слово, – будет что потом нормальному работодателю на собеседовании показать.
Любой код должен быть написан идеально. Другое дело, что «идеальный код» – это такой, который наилучшим образом решает поставленую задачу. Так что говнокод на коленке для одноразового скрипта – это и есть идельный код. Но если заказчик или работодатель не понимает, что качество определенного кода выльется им боком в будущем и не выделяет время на рефакторинг, то либо вы не умеете доносить свои мысли коллегам, либо заказчик/работодатель упорот и пора валить.
brewerof
30.04.2015 16:31+19Тут идет жонглирование двумя понятиями — стратегией продаж и качеством продукта. Покупая авто даже в самой убогой комплектации, покупатель никогда не получит машину с разной компрессией в цилиндрах, отваливающимся глушителем и дырявым бензобаком. Маркетинговая стратегия в компании автора видимо такая — срубим заказ, выставя зараннее зауженные сроки реализации, загоним разработчиков в перегорание и хронический стресс, поставим клиенту говно, потом под соусом «доработки под заказчика» будем допиливать то, что валится слишком явно. А потом еще, на десерт, подпишем клиента на поддержку продукта, потом что багов в таком говнософте предостаточно, и они будут периодически всплывать.
Браво, бис!
achekalin
30.04.2015 16:38+6Увы, частенько идею поста некоторые фирмы доводят до — «старясем бабла сколько сможем, наймем код писать кого попало». Понятно, что качество и доход связаны мало. Но иногда заказчик очень прав, ругаясь на качество, но при этом не имеет особых механизмов как-то создать обратную связь такую, чтобы подрядчик хотел делать пусть и не идеальный, но не отстойный код. Увы.
x256
30.04.2015 17:21+6В конце призыв понятный, но (на мой взгляд) несколько однобокий.
Просто из-за излишнего перфекционизма и возможности заложиться под «будущие фичи» разработка многих проектов затягивалась на месяцы.
Я бы перефразировал в «разработка многих проектов затягивалась на месяцы как из-за излишнего перфекционизма, так и из-за нежелания сделать рефакторинг на пару лет раньше».
А если бы писал статью «с нуля» (только из своего опыта), то получилось бы так: «не видел, чтобы разработка проектов затягивалась из-за излишнего перфекционизма; но из-за нежелания вовремя сделать рефакторинг тратились многие человекогоды», увы.
yvm
30.04.2015 17:55+6Маркетологам кажется, что они понимают.
timfactory
30.04.2015 18:06Крамолу несёт уважаемый автор. Искусство не продаётся.
Если программист начнёт расставлять приоритеты с точки зрения бизнеса, мы получим культ карго и бесконечные времянки, а не процесс разработки. При этом, у разработчика, разумеется, всегда будет работа — бороться с симптомами можно бесконечно.Calc
02.05.2015 18:46Если программист будет рассматривать свою работу с точки зрения бизнеса, то его цель будет «сделать как можно меньше, заработать как можно больше, в свободное время запустить новые направления»
Т.е. сиди тихо, бери деньги, давай деньгам работать, пока «в струе». Жаль авторы таких статей это не понимают.
defuz
30.04.2015 18:02+11На мой взгляд постыл статьи не верный и совершенно вредный. Предыдущая статья была совершенно о другом. Дело в том, что опытный программист должен чувствовать необходимую планку качества, которая требуется от конкретного кода и соответсвовать этому качеству.
1. Если нужно слепить до завтра «из говна и палок» чтобы показать клиенту прототип, хороший програмист не смущаясь лепит «из говна и палок» за один день. Бизнес выиграл.
2. Если разрабатывается модуль, крах которого приведет к убыткам бизнеса на тысячи долларов, хорошому программисту будет не западло потратить неделю/месяц на вылизываение кода, написание юнит тестов и т.п. Бизнес выиграл.
А за подход в стиле «впарим клиенту говно-продукт чтобы через месяц он к нам вернулся и мы наварили еще больше бабла» гореть автору в аду.
Captain
30.04.2015 18:27-3На одном из начальных этапов своей карьеры работал я в одной фирме, занимался автоматизированным тестированием. И был у нас клиент, очень большой и очень солидный, с другой стороны земного шара. Он продавал свое ПО другим, еще более крупным конторам, на которых держится наш, так сказать, вероятный противник. И крутились там очень большие бабки.
Так вот, ответственно заявляю, что код там был — говно! Причем говно редкостное. Они сами это понимали, поэтому и наняли целый штат специалистов по контролю качества. Но продавать и поддерживать это говно им очень нравилось, так как за это платили большие бабки. С тех пор я твердо уяснил, что главное в разработке ПО (собственно как и везде) — продажи, а не качество кода или свободная конкуренция. Не будет маркетинга и продаж — не будет денег. Не будет денег — никого не будет волновать качество кода. Потому что в этом случае за самый лучший код вам нечем будет платить.
SuperNovaWS
30.04.2015 19:31+5Диагноз — маркетология головного мозга.
Я как раз сейчас на таком проекте работаю. Ну, который именно в такой парадигме и развивался до меня. И где-то с два годика назад заказчику надоело, что его сайт постоянно тормозит, глючит, а за это из него за это еще и качают деньги. И он послал таких маркетолухов нахрен и нашел меня.
Первые пол-года я занимался совсем не тем, что писал новые фишки для сайта — я боролся со старыми глюками. Поскольку код был написан ровно в той парадигме: «Нам заплатили — сделаем говно и подсадим на поддержку!» — это заняло те самые пол-года, а не, скажем, месяц. Фактически, я занимался тем самым рефакторингом — хотя всеми силами старался его избежать. Кое-где получалось отрезать приваренные намертво костыли и как-то подкорректировать код. А кое-где приходилось целые куски выбрасывать и просто писать всё заново — ибо не просто код был поганым, но сами выбранные алгоритмы и решения приводили к тем самым багам, которые мне нужно было исправить.
Затем — всё работало нормально примерно три месяца. А дальше — опять началась веселуха: росла посещаемость и сайт начинал тормозить. Просто потому, что начинали «играть» не просто хреновые алгоритмы — но хреновые архитектурные решения. И снова в бой — уже не просто рефакторинг, а переписывание целых подсистем — да еще с обратной совместимостью с остальным старым убогим кодом (весь код сразу не перепишешь, а сайт должен работать без тормозов уже ВЧЕРА) и с модулями вывода (которые создавались тоже через жопу). Ну, фигли нам — клёвым паладинам! Неделя вкалываний по 10-12-14 часов — и узкое место расшито, очередная подсистема переписана с нуля и сайт летает, шо живой… Следующие три месяца. А затем — всё опять по-новой. Тем более, что сайт потихоньку раскручивался и стала расти посещаемость…
После третьей итерации, заказчик стал подозревать, что надо что-то делать — и решил полностью переписать сайт с нуля уже руками нормальных программистов. Ирония в том, что всё это время сайт должен был работать, что бы дать денег тем самым нормальным программистам. Поэтому поддержку сайта никто не отменял.
И тут упёрлись, так сказать, не просто в архитектуру приложения — а уже в узкие места так сказать мета-архитектуры аппаратного решения, которые тоже пришлось расшивать…
Итог? С заказчика вытянули кучу денег. Заказчику это надоело — он послал нахрен плотный коллектив менеджеров и студентов-говнокодеров и ушел от фирмы.
Было ли это выгодно фирме? На тактическом уровне — безусловно! Денег было выкачано столько, что мне даже страшно сказать. Было ли это выгодно фирме на стратегическом уровне? Очевидно — нет. Заказчик не только сам теперь не обратиться в эту контору, но еще и «распиарит» её всем знакомым.OlegTar
30.04.2015 20:10-1А частичной вины заказчика в том, что сайт стал таким нет?
SuperNovaWS
30.04.2015 20:15+1Речь не о заказчике — речь об фирме-исполнителе, которая в точности следует заветам статьи: говнокод побыстрее, да подсадить заказчика на поддержку — исправление своих же косяков.
SuperNovaWS
30.04.2015 23:04+3И о заказчике. Заказчик написал ТЗ. Чёткое и ясное. Я по этому ТЗ вполне успешно работал полтора года. Так что — нет, это вина не заказчика. Если не считать «виной», что ему попалась «шарашкина контора», которая работала на принципах, описанных в статье.
SuperNovaWS
03.05.2015 01:49+1Ну и еще нюанс. Почему я работаю с заказчиком два года — а успешно работаю по ТЗ всего полтора.
Потому что заказчик забыл всё плохое и избаловался форматом: «Вот тебе пару строчек в скайпе в два ночи — сделай мне фикс/фичу к утру». Полезли всякие: «А почему так долго?», «А я не то хотел!», «А ты меня неправильно понял!» и моё любимое: «Я ЭТО НЕ ПРОСИЛ!». Не говоря уже об обсуждениях аппаратной архитектуры с участием только сисадмина — и без моего участия и ответов в стиле: «Слишком много написал, я не понял — поэтому я это проигнорировал» в ответ на подробной алгоритм миграции сервисов между физическими машинами с минимальным даунтаймом сайта. В итоге, конечно, всё выйдет по-моему (не с потолка же я схему миграции расписывал?) — только моих нервов, денег закзачика, времени всех участвующих и даунтайма сервера будет затрачено намного больше.
И вот это — целиком моя вина.
Ogra
30.04.2015 19:46+14Да, мы не понимаем. И не собираемся понимать.
Мы пишем код, это наша работа, нам за неё зарплату платят. И именно поэтому мы отвечаем за свою работу, за её качество.
Меньше фич, быстрее релиз? Это вам к менеджеру проекта, согласовывайте, а мы выпустим релиз попроще и побыстрее, но он все равно будет качественным. API будет документирован, тесты будут написаны, критические баги будут закрыты.
А вот тем программистам, которые пытаются «понимать бизнес» нужно читать Роберта Мартина, для просветления.
Почти месяц назад подкинули простой заказ, но как обычно с подвохом — сделать нужно за три дня. Сделал. Угадайте, когда о нем вспомнили, и потребовалось вносить правки? Правильно — вчера.
Два ценных урока можно извлечь: 1) не верь заказчикам, их «срочно-срочно-срочно» может быть совсем не таким уж и срочным и поспешным; 2) за 3 недели код и его особенности забываются, поэтому код должен быть нормально написан и содержать некоторые комментарии, даже если кажется, что эта поделка на вечер, я и так все помню.SuperNovaWS
30.04.2015 20:33+1Извините, не хватает кармы поставить вам карму!
Поэтому просто напишу: +1!
name1ess0ne
30.04.2015 19:49+4Я согласен с мыслью стать, с точки зрения бизнеса все верно.
Но! Я не очень понимаю, почему меня как программиста, наемного работника, должно это все интересовать? Почему я должен думать о доходах/расходах компании и о том, на чем именно она собирается зарабатывать, а не о качестве кода, архитектуре проекта, организации процесса разработки. Меня вроде как программиста наняли на работу, а не как бизнес аналитика.
Мне, как программисту, выгодно развивать свои профессиональные навыки.
Мне выгодно писать хороший код, мне выгодно изучать новые технологии, мне выгодно совершенствовать свои программы, писать тесты на них и т.д.
Писать же говнокод и непрофессиональные продукты мне не выгодно. Т.е. это может быть выгодно в краткосрочной перспективе, но вот в долгосрочной совсем нет.
Что будет если я 5 лет буду писать говнокод, а потом меня уволят или компания разорится? Кому мне продать свои знания написания говнокода? Как мне получить хорошее место работы с такими вот знаниями? Как объяснить на собеседовании, что это было выгодно моему работодателю?
Так вот, у меня вопрос, почему я должен думать о том, что выгодно текущему работодателю, а не о том, что выгодно мне?SuperNovaWS
30.04.2015 20:32+3Опять то же самое… Мне интересно — с какого момента кидалово и шарашкины конторы вдруг начали называть словом «бизнес»?
name1ess0ne
30.04.2015 20:44+1Бизнес бывает разный, контора автора статьи получает деньги за то, что они делают. Так что, наверно, это можно назвать бизнесом. Просто бизнес модель такая у них. Но я не об этом. Я как раз спрашивал, почему я вообще должен понимать как там «бизнес» устроен, если я обычный программист.
Dywar
30.04.2015 22:32+2Напишу тоже.
1) «Заблуждаются не потому что не знают, а потому что думают что знают». Жан Жак Руссо.
2) Программист который способен разобраться в предметной области заказчика в степени достаточной для понимания вопроса — хороший программист. (Это между строчек у Стив Макконнелла и Джона Роббинса)
3) Подходов к разработке много, моделей реализации тоже, что лучше знают те кто на этом зарабатывает.
Да, сам «код» заказчика не интересует. Он требует продукт который решает его задачи.
Про качество кода написано много, но мало вспоминают про архитектуру, не даром у них з.п. с пятью нулями.
Лишний функционал не делают, его не требуют, но он отнимает время и деньги которые никто не закладывал.
OnYourLips
30.04.2015 22:36> Например, утверждение «идеальный код — залог успешного бизнеса» может казаться логичным, но с точки зрения доходов/расходов далеко не всегда истинно.
В долгосрочной перспективе всегда. Хороший код дешевле в поддержке.
sainnr
30.04.2015 23:16На эту тему есть прекрасная лекция Евгения Кривошеева.
Видео
fshp
01.05.2015 00:29+1Малофункциональный продукт и говнокод это совсем разные критерии. Вы килограммы с метрами сравниваете.
inook
01.05.2015 11:43-2Обычная статья офисной крысы, котора дальше своего носа и $100 ничего не видит.
hoack
01.05.2015 20:32+1На самом деле есть довольно просто формулируемое правило: качество кода должно быть коммерчески оправдано. Эта самая коммерческая оправданность очень, очень зависит от конкретного проекта.
Вот пример, можно сказать, из личного опыта. Было две компании, А и Б. Занимались примерно одним и тем же. Компания А была сильна технологически. У нее был вычищен код, были все элементы грамотно организованного технологического процесса. В компании Б было в два раза меньше программистов, и очень многие вещи делались, что называется, на коленке, на скорую ручку, побыстрее. При этом компания А при ближайшем рассмотрении оказалась убыточна, а компания Б — прибыльна. И, как выяснилось, убыточность во многом происходила из-за непомерных затрат на технологию. При этом там не было особо ненужных трат; просто поддержание такого уровня качества кода и процесса оказалось делом более дорогостоящим, чем компания могла себе позволить.
При этом я не могу сказать, что в компании Б царил сплошной говнокод. Младшие разработчики периодически получали, фигурально говоря, по шее от старших товарищей за особо впечатляющие художества, код периодически просматривался и рефакторился… Просто это не было на столь высоком уровне, не отнимало столько ресурсов.
Так вот, в данной ситуации в компании Б трезвее оценили то, какой уровень качества им нужен и доступен. Да, низкое качество кода впоследствии икнулось и не раз: из-за нестабильности продукта компания потеряла несколько клиентов; пришлось выделять отдельное время на залатывание самых вопиющих дырок; в какой-то момент в компании Б пришлось просто остановить новые разработки и ьросить все силы на восстановление управляемости и стабильности проекта. Конечно, ничего бы этого не случилось, будь качество кода в компании Б на том уровне, на каком оно было в компании А…
… которая до этого момента просто не дожила.akrupa
01.05.2015 22:30в компании Б пришлось просто остановить новые разработки и ьросить все силы на восстановление управляемости и стабильности проекта. Конечно, ничего бы этого не случилось, будь качество кода в компании Б на том уровне, на каком оно было в компании А…
… которая до этого момента просто не дожила.
А потом у компании Б перестало хватать сил и на поддержание проекта, она потеряла клиентов и её постигла та же судьба, только позже.
Программисты в компании А спокойно делали свою работу, как только компания А разорилась, они нашли компанию В и продолжили спокойно там работать. Программисты в компании Б, из последних сил тянули проваливающийся продукт, получали стрессы, работали по выходным, чтобы вытянуть проект, и в конце, измотанные, оказались перед необходимостью искать новую работу.
khim
01.05.2015 23:09Ой какие страсти вы рассказываете. Ужас прям. Но. О гипотетических компаниях хорошо спорить, всегда можно под себя историю повернуть, так что давайте рассмотрим вполне себе конкретный вариант ровно этой истории.
Так когда там у нас компания Б умерла, не подскажете? И где сейчас разработчки из компании А не напомните?hoack
01.05.2015 23:20У меня, кстати, компании не гипотетические, а вполне себе конкретные. Но мне не хотелось указывать реальные названия.
khim
01.05.2015 23:40+2Это неважно. Ваша история тем и интересна, что она далеко не уникальна.
Правда заключается в том, что
1) компании с самым ужасным качеством кода всегда проигрывают (как в рассказе akrupa).
2) компании с самым лучшим качеством кода всегда проигрывают (как у вас).
Выигрывают (то есть выживают) только и исключительно компании код которых плох, но не настолько плох, чтобы в попытках его «вытянуть» нужно было работать по 20 часов в день по выходным 7 дней в неделю… ну пару-тройку раз в году придётся, наверное.
Пока программист этого не поймёт, не осознает — за ним нужно следить и в случае чего бить по рукам, а если этого не понимает архитектор — то ваша команда (а может и компания в целом) вообще не жилец.hoack
01.05.2015 23:56О! Золотые слова!
Я бы только добавил: выигрывают только и исключительно компании, обладающие самым плохим из приемлемого для данной ситуации кода. Потому что требования к этому самому минимальному качеству кода у, скажем, производителя программного обеспечения для самолётов и разработчика онлайн-игрушек будут принципиально разные.
akrupa
01.05.2015 23:39Программисты из компании А в компании Б, или других. Им живется мирно и спокойно. У них есть работа и зарплата. Они не пропадут.
SuperNovaWS
03.05.2015 02:00-2Обожаю ссылки на дядю Джоэля!
Обычно люди, дающие такие ссылки, расписываются в собственной ограниченности. По сути — что пишет Джоэль? Он рассказывает об ЕДИНИЧНОМ опыте ОДНОГО программиста по развитию мелкой программерской лавочки. Да, рассказывает убедительно, зажигательно и с огоньком. Вполне возможно, что так легли карты — и кроме отличного продажника (а он именно что «продает» свой личный опыт миллионам читателей) и рассказчика (читать его статьи — очень интересно) в одном человеке уместился еще и хороший программист (ммм… А?).
Но попытка распространения единичного опыта на весь стат-набор — выдает в человеке полное отсутствие хоть какого-то математического образования. В частности — полное незнакомство с таким занимательным разделом, как «статистический анализ» на уровне предпоследнего класса школы с углубленным изучением математики. Ведь то, что этот гипотетический человек пытается сделать — это по результату одного-единственного опыта сразу построить статистику! А это даже круче, чем «50/50» в анекдоте про блондинку и динозавра…grossws
03.05.2015 03:49+2Стоит учитывать, что большинство авторов грешат тем же. Ещё и без осознания ограниченности своего видения ситуации.
Кроме того, картины, рисуемые Спольки, часто неплохо пересекаются с реальностью. И его аналитические способности вполне позволяют экстраполировать его частный опыт на некоторые области индустрии.SuperNovaWS
03.05.2015 04:10-2Перечитал все статьи из своих закладок (которые делал лет пять-шесть назад). Слегка охренел от прочитанного. Погуглил чутку. Еще больше охренел. Провел простейшие матоперации над датами. Охренел настолько, что аж сам разродился статьей: habrahabr.ru/post/257165
В общем — ИМХО совсем всё грустно со ссылками на дядю Джоэля
hoack
01.05.2015 23:19+1Ну, окончания у этой истории пока нет, так что посмотрим. Для компании Б она может кончиться по-разному. Вполне возможно, что так, как вы описываете. А может, и по другому…
А вот для компании А она УЖЕ ЗАКОНЧИЛАСЬ.
DarkSet
18.05.2015 18:36+1Именно по причине написаного в этой статье программы на моём двухъядерном 3.4 гигагерцовом процессоре работают примерно на такой же скорости, что и когда то на 300 мегагерцовом.
Временем и ресурсами для выполнения программы пожертвовали в пользу уменьшения времени и ресурсов на создание программы. Что с точки зрения здравого смысла глупость, так как пишется программа один раз, а запускается много раз.
В общем что я хочу сказать как программист: горите в аду, маркетологи! :)
k12th
Вам не кажется, что продавать говно — неэтично?
legobrain Автор
Никто не призывает делать говно. Если не сделать 10 фич в продукт, которые могли бы быть необходимыми и продавать их отдельно, продукт не обязательно будет говном.
PS. К сожалению, продавать говно — это норма. Зайдите в магазин, в котором вы покупаете продукты и убедитесь :-(
vedenin1980
А какое это имеет отношение к качеству КОДА? Функциональность продукта вообще определяют ни разу не программисты. Задачей программиста сделать то кол-во фич и в том объеме что ему задано.
legobrain Автор
А какое отношение качество кода имеет к качеству продукта?
vedenin1980
Ровно такое же как качество работы строителей к качеству построенного дома. Это важная часть, но далеко не единственная, при отвратительных материалах (отсутствии времени/ресурсов, плохом дизайне, некачественном тестировании, плохом бизнес анализе) дом качественный труд рабочих не спасет. С другой стороны, при раздолбайстве рабочих можно легко загубить самые качественные материалы.
А функциональность продукта — сколько в доме надо построить этажей. Это должны решать ни разу не строители, а руководство застройщика.
legobrain Автор
Давайте разбираться :-)
Возьмем такую штуку как интернет магазин. Что такое качественный интернет магазин:
1) Это тот, который построен качественными материалами, с кучей настроек и т. д.
2) Который имеет возможность продать клиенту товар, но собран на тяп ляп.
Как не странно, но подойдут оба :-) И следуя вашей аналогии, мы вспомним, как крутой огромный супермаркет с огромной парковкой, так и говнистый ларёк с пивом, окрашенный в голубой цвет или обитый пластиковой вагонкой, в котором тоже кто-то что-то покупает.
Так что качество в данном случае определяет заказчик отталкиваясь от того, что надо ему (а также опираясь на мелочи вроде бюджета и ЦА), а не программист. Не всем нужны высотки, не всем нужны супермаркеты, как ни странно есть люди которым нужны ржавые гаражи, сараи и ларьки с пивом.
vedenin1980
Ну смотрите разница между огромным супермаркетом и ларьком с пивом исключительно в размерах проекта. Вряд ли вы даже когда нанимаете сделать ларек с пивом задачу будите ставить как «склейте тут на скотч как-нибудь», ибо тупо развалится.
P.S. Представьте что в вашем интернет-магазине, который собран тяп-ляп половина заказчиков тупо не может никак оформить заказ. Ей богу, лучше тогда уж ничего не писать, а тупо поставить какую-нибудь бесплатную инет-магазина CMS со стандартной темой за три копейки, чем нечто самописное работающее через раз. ИМХО.
khim
И даже это может быть лучшим решением если вы запускаете магазин цветов в начале марта. Даже если половина потенциальных покупателей уйдёт — это лучше, чем если вам придётся все цветы, закупленные к 8 марта, просто выкинуть.
SuperNovaWS
Только меня мучает одна мысль — почему вы называете это «бизнесом» и почему за ваше превратное понимание термина «бизнес» должны расплачиваться программисты потерей своей квалификации?
defuz
А если заказчик – это вы сами, и ваш ларек потостоянно нужно развивать, как бы вы поступили?
dyadyaSerezha
А ларек не нужно развивать. Достаточно законодательно почти запретить продажу пива в стране. И смотреть сквозь пальцы на отдельные ларьки — и будут у них огромные очереди и давка без всякого развития. Эх, как вспомню, так здрогну. Зато какое счастье, когда после 2-4 часов в очереди отхватишь пару трехлитровых банок! ;)
DrPass
Ну как сказать… если они торгуют одним и тем же товаром, но второй собран на тяп-ляп, он постепенно заберет клиентов у первого. Как только пользователь видит, что на первом сайте удобнее выбирать товары, он не тормозит при изменении фильтров и т.д., он делает свой выбор в пользу этого сайта.
DonkeyHot
Клиенты будут там, у кого ниже цена и где нет проблем с оплатой и доставкой )
удобная витрина и фильтры будут на 10 месте по значимости для клиента.
DrPass
Ценой и оплатой/доставкой конкурировать сложно. Большинство интернет-магазинов в любой сфере имеют один и тот же не слишком широкий набор поставщиков, с одинаковыми закупочными ценами и минимальной собственной маржой. Условия оплаты и доставки также у всех примерно одинаковые. Так что им реально остается конкурировать витриной, да еще рекламой :) Но в любом случае, это ж аллегория. Смысл в том, что качество при прочих равных — весомый аргумент в конкурентной борьбе, и ему надо уделять внимание.
DonkeyHot
Да ладно, для примера зайдите на маркет. Разница цен до в несколько раз доходит, а минимальная цена только у 1-2 магазинов, там и берут. А какая у них будет витрина, если там цена минимальная, то всем по барабану, я обычно ограничиваюсь поиском номера телефона на странице и мне от их витрины больше ничего не надо.
khim
Ох уж эти сказки, ох уж эти сказочники. О каких тонких проблемах можно говорить с людьми, которые элементарной логике не обучены. Ну я понимаю на сайте для уборщиц люди могут приравнять «я обычно ограничиваюсь» к «всем по барабану», но тут вроде как статья для людей с несколько более высоким интеллектом.
Вы можете сколько угодно рассказывать про то, как вам все по барабану, но из песни-то слов не выкинешь: приличные деньги делают Юлмарт и Ситилинк, а не магазины, у которых на странице только номер телефона. Или тот же Wildberries — думаете у него самая дешёвая одежда? Нет, у него самый удобный каталог.
amarao
Зашёл. Какой именно из продуктов «говно»? Свежайшие фрукты, молоко (скисает за 5 дней), куча разных сыров, хлеб собственной выпечки. ЧЯДН?
areht
Ну сходу я вполне уверен, что «хлеб собственной выпечки».
Вряд ли на месте занимаются сложными заквасками, брожениями, фермантациями. Залили муку водой в хлебопечке — через час можно покупателям втюхивать свежий хлеб.
Вообще, словом «куча» опровергать, что продают «говно» не стоит.
amarao
Ну, если они что-то будут «втюхивать», то покупать у них никто не будет. Потому что рядом конкурирующая пекарня, которая рада будет (за такие-то деньжищи!) дать качественного хлеба.
То же касается и фруктов. Если мне хоть раз продадут гадость под видом хорошего (например, подсунут клементины по полтора евра по цене четырёхевровых), то фиг я к ним второй раз пойду.
Ни разу не сталкивался с протухшим мясом или рыбой, хотя казалось бы, жара, и только так всё портиться должно. У клубники можно чуть-чуть подгнивающую штучку найти, но это издержки того, что она вся гнить начинает через два часа как её с грядки собрали. Так что к вечеру она уже может оказаться слегка порченой местами. Для меня это, скорее, доказательство свежести, чем некачественности (то же касается и апельсинов, которые могут начинать плесневеть прям на следующее утро) — их как собрали с веток, так тут же в магазин и привезли.
Короче, выбирайте магазины и продавцов.
areht
Ну то есть я правильно написал, только не упомянул, что есть ещё соседняя пекарня, в которой почти то же самое, только в Х раз дороже.
Скажем, у товара есть 20 характеристик (10 маркетинговых, 10 измеримых). Каждая из них беспокоит одного из 10. Очевидно, все 20 характеристик подтянуть на максимум стоит бесконечно дорого.
Натянув маркетинговые можно удовлетворить (не осчастливить, а что бы не пошли в другой магаз) 90% населения. А если ещё покупателям рассказать, что ценность хлеба — в близости пекарни, а гниль — показатель свежести…
А вот тем, кто знает, чем можно полить мясо, что бы оно на жаре не портилось — приходится ехать далеко, если вообще знаешь куда. Потому что из 10% понимающих доедут 1%, значит нормальный магазин обосновано строить 1 из 100. Вы, например, знаете где взять парное молоко?
Впрочем, если я правильно помню, живёте вы на симпатичном острове с зашкаливающим внешним долгом. То есть у вас плотность может быть чуть выше, но этот праздник жизни случился за счёт соседей. И скоро поймут, что свежее возить утром и выбрасывать остатки вечером — очень не экономично. Ну как скоро, в пределах 10 лет. Вы к тому времени за приличными магазинами успеете слинять… Ну пусть в Канаду, но там клубники с грядки в апреле уже не будет по объективным причинам.
amarao
Гниль, а точнее, плесень, показатель того, что их не мыли (там даже на свежих можно нащупать лёгкий пушок будущего пеницилина). Они долго в таком виде не хранятся, и всё это вместе гарантирует свежайшее качество.
В принципе, в магазинах бывают привозные (Израиль, Морокко), но зачем они, когда есть местные и очень сочные.
Насчёт «не очень экономично выбрасывать» — никто и не выбрасывает. К вечеру в магазинах почти пустые лотки с овощами. Кто опоздал — тот остаётся с яблоками, которые могут несколько дней лежать, да квашенными оливками (аналогично).
И это общепринятая практика. Более того, часто бывает так, что если вечером приезжаешь в мясную лавку, а там ещё мясо с утреннего раздела осталось, то мясник может сказать, что лучше не брать, потому что «уже давно разделано» (читай, часа 4 назад) и посоветовать прийти лучше завтра утром.
Где берут парное молоко не знаю, а в магазины завозят рано утром.
Почему местные должны делать назло и всё плохо? Не путайте Грецию и Кипр, это у Греции с внешним долгом всё плохо, а Кипру всё более-менее ок, кроме греческого долга (перед Кипром).
Это другой менталитет — зачем людям делать плохо и стыдиться потом смотреть в глаза соседям?
areht
> Гниль, а точнее, плесень, показатель того, что их не мыли (там даже на свежих можно нащупать лёгкий пушок будущего пеницилина).
Плесень нельзя «смыть». Не знаю на сколько конкретная плесень вредная, но за показатель качества заражение грибками я не считаю в принципе.
Как и уменьшение срока годности продуктов. Так не далеко до того, что бы над витриной с фруктами споры плесени распылять, что бы у вас они быстро портились, а на складе — нет.
Это не «на зло» — это выгоднее.
Открываем вики — en.wikipedia.org/wiki/2012%E2%80%9313_Cypriot_financial_crisis
150% ВВП долга
€2.5bn (US$3.236 billion) emergency loan from Russia
Looking further ahead, it was generally expected Cyprus would need to apply for an additional bailout loan.
Нет, ничего не путаю. Зачем людям делать плохо, если можно взять кредит и не отдавать.
Вообще, то что вы рассказываете может быть применимо только к местным продуктам, проще говоря вы передёргиваете.
amarao
Споры можно смыть. Например, беловатое на винограде — это как раз плесень, которая всю жизнь на нём живёт. Аналогично с цитрусовыми.
Впрочем, объяснять это почти бесполезно, надо просто сравнить ту химию, которую продают в МСК/Питере и свежие…
В питерское время иногда на прилавках за бешенные деньги попадались мандарины 'bollo' (продавались в деревянных ящичках). Вот примерно такое же, только более спелое.
Насчёт «нельзя смыть» — можно. Если апельсины вымыть, то плесень не появится в течение нескольких недель.
Насчёт долга — был неправ, не интересовался вопросом.
Вопрос применим не только к местным продуктам. Если кто-то начнёт продавать откровенную халтуру под видом качественных продуктов, то как он в глаза соседям смотреть будет?
areht
Я не спорю, что на фруктах бывает плесень. Но это минус, а не плюс.
Просто брак. Как, не знаю, содержимое кишечника барана на свежеразделанной туше.
Плесень смыть нельзя. Смыть можно споры. Может быть они созревают за 2 недели, но при этом внутри апельсина плесень продолжает жизнедеятельность и что там за химия — я не знаю.
Болло не встречал, то что в интернете висит ценой от покупаемых мной радикально не отличается, подозреваю, что вы сравниваете с лежащим в супермаркетах по 100р. Пока вы не переехали к магазину, где привозят свежие фрукты вы не руководствовались «Короче, выбирайте магазины и продавцов»?
Никто не продаёт «откровенную халтуру» и «под видом». Есть же десяток маркетинговых характеристик, которые исключают попадание в «откровенную халтуру».
И можно продавать говно. Нужен просто триггер, например соседи попросят вернуть долги, чуть повыше налоги, чуть поменьше спрос. Как в глаза смотреть? Ну как таджики из под кассы в питере смотрели, так и тут.
И не «вопрос применим», а ваши примеры.
«свежие фрукты из соседнего сада в магазинах есть. До обеда.». А работающим людям, идущим в магазин после заката? Есть говно, которое осталось.
Есть ли у вас свежее спелое тайское манго? Нет? Оно же у вас не растёт? Вот поэтому рассказанное вами применимо только к местным товарам.
amarao
Отвечу на главный вопрос: а нефиг по магазинам после работы ходить. Да, такой суровый остров. Рыбу прекращают продавать в 6, остальное — в 8. И если тебе приспичило купить поесть в 10 вечера — периптеры (киоски 24 часа со скудным ассортиментом джанкфуда) тебе в помощь. Или в ресторан (не сильно дороже получится).
Зато всё свежее.
Dark_Scorpion
Норма для человека, это то с чем он согласен. Если вы с этим согласны, и не хотите ничего с этим делать, то это ваши проблемы.
Пример из IT: Вы реально поверите, когда новый ПМ вам скажет, что вы должны работать без выходных и баги править в личное время, т.е по ночам и за старую зарплату. Потому, что у него типа все сотрудники так делают и для него, это норма? Вы в это поверите и сразу согласитесь?
Такая уж задача у бизнеса, всё сделать побыстрее и подешевле. Но вот вопрос, если всё вначале делать в сжатые сроки и по быстрому как просит менеджер, то кто потом будет по ночам сидеть и в лапша-коде ковыряться и окажется крайний, если не уложится в срок? Менеджер или программист?
fzn7
Восприняв буквально слова Хаяма:
«Ты лучше голодай, чем что попало есть,
И лучше будь один, чем вместе с кем попало.»
я стал очень голодным и антисоциальным (с)
overmes
Чтоб мудро жизнь прожить, знать надобно немало.
Два важных правила запомни для начала:
OlegTar
Это надо бизнесу объяснить. Чем продукт за $100 хуже продукта за $1700.
А также почему надо подождать полгода и переписать проект (просто переписать, даже новые фичи не добавлять), а не запиливать новые фичи завтра.
ustasby
На рынке лидирует говнокод, и ничего, посмотрите внутренности «лидера» с тысячами партнеров, в многих даже программисты отсутствуют.
k12th
Речь шла не о говнокоде в данном случае, а о намеренно говенном продукте, за фикс багов в котором платит клиент. Это все равно что продавать тухлые продукты и подписку на активированный уголь на год.
ustasby
Все правильно, это как раз про этого лидера, точь в точь, за фикс багов там платит каждый клиент, хороший рынок, хорошие зарплаты и «патентованная» система кэширования за 200К. И еще есть магазин говнокода, ежедневно пополняемый.
k12th
Это вы не про 1С ли?)
ustasby
Нет, но почти угадали