Комментарии 123
Т. е., предложив клиенту свой малофункциональный продукт за 100$ и установку его за 1 день, а еще доработку продукта под клиента за 500$ и 3 дня, компания выигрывает. А ещё клиент подписывается на годовую поддержку продукта за 100$/мес. И малофункциональный продукт выжал на 1700$ больше, чем если бы сразу продавалась полноценная версия.
Вам не кажется, что продавать говно — неэтично?
Никто не призывает делать говно. Если не сделать 10 фич в продукт, которые могли бы быть необходимыми и продавать их отдельно, продукт не обязательно будет говном.
PS. К сожалению, продавать говно — это норма. Зайдите в магазин, в котором вы покупаете продукты и убедитесь :-(
PS. К сожалению, продавать говно — это норма. Зайдите в магазин, в котором вы покупаете продукты и убедитесь :-(
Если не сделать 10 фич в продукт, которые могли бы быть необходимыми и продавать их отдельно, продукт не обязательно будет говном.
А какое это имеет отношение к качеству КОДА? Функциональность продукта вообще определяют ни разу не программисты. Задачей программиста сделать то кол-во фич и в том объеме что ему задано.
А какое это имеет отношение к качеству КОДА?
А какое отношение качество кода имеет к качеству продукта?
Ровно такое же как качество работы строителей к качеству построенного дома. Это важная часть, но далеко не единственная, при отвратительных материалах (отсутствии времени/ресурсов, плохом дизайне, некачественном тестировании, плохом бизнес анализе) дом качественный труд рабочих не спасет. С другой стороны, при раздолбайстве рабочих можно легко загубить самые качественные материалы.
А функциональность продукта — сколько в доме надо построить этажей. Это должны решать ни разу не строители, а руководство застройщика.
А функциональность продукта — сколько в доме надо построить этажей. Это должны решать ни разу не строители, а руководство застройщика.
Давайте разбираться :-)
Возьмем такую штуку как интернет магазин. Что такое качественный интернет магазин:
1) Это тот, который построен качественными материалами, с кучей настроек и т. д.
2) Который имеет возможность продать клиенту товар, но собран на тяп ляп.
Как не странно, но подойдут оба :-) И следуя вашей аналогии, мы вспомним, как крутой огромный супермаркет с огромной парковкой, так и говнистый ларёк с пивом, окрашенный в голубой цвет или обитый пластиковой вагонкой, в котором тоже кто-то что-то покупает.
Так что качество в данном случае определяет заказчик отталкиваясь от того, что надо ему (а также опираясь на мелочи вроде бюджета и ЦА), а не программист. Не всем нужны высотки, не всем нужны супермаркеты, как ни странно есть люди которым нужны ржавые гаражи, сараи и ларьки с пивом.
Возьмем такую штуку как интернет магазин. Что такое качественный интернет магазин:
1) Это тот, который построен качественными материалами, с кучей настроек и т. д.
2) Который имеет возможность продать клиенту товар, но собран на тяп ляп.
Как не странно, но подойдут оба :-) И следуя вашей аналогии, мы вспомним, как крутой огромный супермаркет с огромной парковкой, так и говнистый ларёк с пивом, окрашенный в голубой цвет или обитый пластиковой вагонкой, в котором тоже кто-то что-то покупает.
Так что качество в данном случае определяет заказчик отталкиваясь от того, что надо ему (а также опираясь на мелочи вроде бюджета и ЦА), а не программист. Не всем нужны высотки, не всем нужны супермаркеты, как ни странно есть люди которым нужны ржавые гаражи, сараи и ларьки с пивом.
как крутой огромный супермаркет с огромной парковкой, так и говнистый ларёк с пивом, окрашенный в голубой цвет или обитый пластиковой вагонкой, в котором тоже кто-то что-то покупает.
Ну смотрите разница между огромным супермаркетом и ларьком с пивом исключительно в размерах проекта. Вряд ли вы даже когда нанимаете сделать ларек с пивом задачу будите ставить как «склейте тут на скотч как-нибудь», ибо тупо развалится.
P.S. Представьте что в вашем интернет-магазине, который собран тяп-ляп половина заказчиков тупо не может никак оформить заказ. Ей богу, лучше тогда уж ничего не писать, а тупо поставить какую-нибудь бесплатную инет-магазина CMS со стандартной темой за три копейки, чем нечто самописное работающее через раз. ИМХО.
Вряд ли вы даже когда нанимаете сделать ларек с пивом задачу будите ставить как «склейте тут на скотч как-нибудь», ибо тупо развалится.Ну скотч — нет, а преслувутая проволока — легко может быть.
Представьте что в вашем интернет-магазине, который собран тяп-ляп половина заказчиков тупо не может никак оформить заказ.И даже это может быть лучшим решением если вы запускаете магазин цветов в начале марта. Даже если половина потенциальных покупателей уйдёт — это лучше, чем если вам придётся все цветы, закупленные к 8 марта, просто выкинуть.
А если заказчик – это вы сами, и ваш ларек потостоянно нужно развивать, как бы вы поступили?
А ларек не нужно развивать. Достаточно законодательно почти запретить продажу пива в стране. И смотреть сквозь пальцы на отдельные ларьки — и будут у них огромные очереди и давка без всякого развития. Эх, как вспомню, так здрогну. Зато какое счастье, когда после 2-4 часов в очереди отхватишь пару трехлитровых банок! ;)
1) Это тот, который построен качественными материалами, с кучей настроек и т. д.
2) Который имеет возможность продать клиенту товар, но собран на тяп ляп.
Ну как сказать… если они торгуют одним и тем же товаром, но второй собран на тяп-ляп, он постепенно заберет клиентов у первого. Как только пользователь видит, что на первом сайте удобнее выбирать товары, он не тормозит при изменении фильтров и т.д., он делает свой выбор в пользу этого сайта.
Клиенты будут там, у кого ниже цена и где нет проблем с оплатой и доставкой )
удобная витрина и фильтры будут на 10 месте по значимости для клиента.
удобная витрина и фильтры будут на 10 месте по значимости для клиента.
Ценой и оплатой/доставкой конкурировать сложно. Большинство интернет-магазинов в любой сфере имеют один и тот же не слишком широкий набор поставщиков, с одинаковыми закупочными ценами и минимальной собственной маржой. Условия оплаты и доставки также у всех примерно одинаковые. Так что им реально остается конкурировать витриной, да еще рекламой :) Но в любом случае, это ж аллегория. Смысл в том, что качество при прочих равных — весомый аргумент в конкурентной борьбе, и ему надо уделять внимание.
Да ладно, для примера зайдите на маркет. Разница цен до в несколько раз доходит, а минимальная цена только у 1-2 магазинов, там и берут. А какая у них будет витрина, если там цена минимальная, то всем по барабану, я обычно ограничиваюсь поиском номера телефона на странице и мне от их витрины больше ничего не надо.
Да ладно, для примера зайдите на маркет.А там что — обороты указаны для магазинов? Где?
А какая у них будет витрина, если там цена минимальная, то всем по барабану, я обычно ограничиваюсь поиском номера телефона на странице и мне от их витрины больше ничего не надо.Ох уж эти сказки, ох уж эти сказочники. О каких тонких проблемах можно говорить с людьми, которые элементарной логике не обучены. Ну я понимаю на сайте для уборщиц люди могут приравнять «я обычно ограничиваюсь» к «всем по барабану», но тут вроде как статья для людей с несколько более высоким интеллектом.
Вы можете сколько угодно рассказывать про то, как вам все по барабану, но из песни-то слов не выкинешь: приличные деньги делают Юлмарт и Ситилинк, а не магазины, у которых на странице только номер телефона. Или тот же Wildberries — думаете у него самая дешёвая одежда? Нет, у него самый удобный каталог.
Зашёл. Какой именно из продуктов «говно»? Свежайшие фрукты, молоко (скисает за 5 дней), куча разных сыров, хлеб собственной выпечки. ЧЯДН?
Ну сходу я вполне уверен, что «хлеб собственной выпечки».
Вряд ли на месте занимаются сложными заквасками, брожениями, фермантациями. Залили муку водой в хлебопечке — через час можно покупателям втюхивать свежий хлеб.
Вообще, словом «куча» опровергать, что продают «говно» не стоит.
Вряд ли на месте занимаются сложными заквасками, брожениями, фермантациями. Залили муку водой в хлебопечке — через час можно покупателям втюхивать свежий хлеб.
Вообще, словом «куча» опровергать, что продают «говно» не стоит.
Ну, если они что-то будут «втюхивать», то покупать у них никто не будет. Потому что рядом конкурирующая пекарня, которая рада будет (за такие-то деньжищи!) дать качественного хлеба.
То же касается и фруктов. Если мне хоть раз продадут гадость под видом хорошего (например, подсунут клементины по полтора евра по цене четырёхевровых), то фиг я к ним второй раз пойду.
Ни разу не сталкивался с протухшим мясом или рыбой, хотя казалось бы, жара, и только так всё портиться должно. У клубники можно чуть-чуть подгнивающую штучку найти, но это издержки того, что она вся гнить начинает через два часа как её с грядки собрали. Так что к вечеру она уже может оказаться слегка порченой местами. Для меня это, скорее, доказательство свежести, чем некачественности (то же касается и апельсинов, которые могут начинать плесневеть прям на следующее утро) — их как собрали с веток, так тут же в магазин и привезли.
Короче, выбирайте магазины и продавцов.
То же касается и фруктов. Если мне хоть раз продадут гадость под видом хорошего (например, подсунут клементины по полтора евра по цене четырёхевровых), то фиг я к ним второй раз пойду.
Ни разу не сталкивался с протухшим мясом или рыбой, хотя казалось бы, жара, и только так всё портиться должно. У клубники можно чуть-чуть подгнивающую штучку найти, но это издержки того, что она вся гнить начинает через два часа как её с грядки собрали. Так что к вечеру она уже может оказаться слегка порченой местами. Для меня это, скорее, доказательство свежести, чем некачественности (то же касается и апельсинов, которые могут начинать плесневеть прям на следующее утро) — их как собрали с веток, так тут же в магазин и привезли.
Короче, выбирайте магазины и продавцов.
Ну то есть я правильно написал, только не упомянул, что есть ещё соседняя пекарня, в которой почти то же самое, только в Х раз дороже.
Скажем, у товара есть 20 характеристик (10 маркетинговых, 10 измеримых). Каждая из них беспокоит одного из 10. Очевидно, все 20 характеристик подтянуть на максимум стоит бесконечно дорого.
Натянув маркетинговые можно удовлетворить (не осчастливить, а что бы не пошли в другой магаз) 90% населения. А если ещё покупателям рассказать, что ценность хлеба — в близости пекарни, а гниль — показатель свежести…
А вот тем, кто знает, чем можно полить мясо, что бы оно на жаре не портилось — приходится ехать далеко, если вообще знаешь куда. Потому что из 10% понимающих доедут 1%, значит нормальный магазин обосновано строить 1 из 100. Вы, например, знаете где взять парное молоко?
Впрочем, если я правильно помню, живёте вы на симпатичном острове с зашкаливающим внешним долгом. То есть у вас плотность может быть чуть выше, но этот праздник жизни случился за счёт соседей. И скоро поймут, что свежее возить утром и выбрасывать остатки вечером — очень не экономично. Ну как скоро, в пределах 10 лет. Вы к тому времени за приличными магазинами успеете слинять… Ну пусть в Канаду, но там клубники с грядки в апреле уже не будет по объективным причинам.
Скажем, у товара есть 20 характеристик (10 маркетинговых, 10 измеримых). Каждая из них беспокоит одного из 10. Очевидно, все 20 характеристик подтянуть на максимум стоит бесконечно дорого.
Натянув маркетинговые можно удовлетворить (не осчастливить, а что бы не пошли в другой магаз) 90% населения. А если ещё покупателям рассказать, что ценность хлеба — в близости пекарни, а гниль — показатель свежести…
А вот тем, кто знает, чем можно полить мясо, что бы оно на жаре не портилось — приходится ехать далеко, если вообще знаешь куда. Потому что из 10% понимающих доедут 1%, значит нормальный магазин обосновано строить 1 из 100. Вы, например, знаете где взять парное молоко?
Впрочем, если я правильно помню, живёте вы на симпатичном острове с зашкаливающим внешним долгом. То есть у вас плотность может быть чуть выше, но этот праздник жизни случился за счёт соседей. И скоро поймут, что свежее возить утром и выбрасывать остатки вечером — очень не экономично. Ну как скоро, в пределах 10 лет. Вы к тому времени за приличными магазинами успеете слинять… Ну пусть в Канаду, но там клубники с грядки в апреле уже не будет по объективным причинам.
Гниль, а точнее, плесень, показатель того, что их не мыли (там даже на свежих можно нащупать лёгкий пушок будущего пеницилина). Они долго в таком виде не хранятся, и всё это вместе гарантирует свежайшее качество.
В принципе, в магазинах бывают привозные (Израиль, Морокко), но зачем они, когда есть местные и очень сочные.
Насчёт «не очень экономично выбрасывать» — никто и не выбрасывает. К вечеру в магазинах почти пустые лотки с овощами. Кто опоздал — тот остаётся с яблоками, которые могут несколько дней лежать, да квашенными оливками (аналогично).
И это общепринятая практика. Более того, часто бывает так, что если вечером приезжаешь в мясную лавку, а там ещё мясо с утреннего раздела осталось, то мясник может сказать, что лучше не брать, потому что «уже давно разделано» (читай, часа 4 назад) и посоветовать прийти лучше завтра утром.
Где берут парное молоко не знаю, а в магазины завозят рано утром.
Почему местные должны делать назло и всё плохо? Не путайте Грецию и Кипр, это у Греции с внешним долгом всё плохо, а Кипру всё более-менее ок, кроме греческого долга (перед Кипром).
Это другой менталитет — зачем людям делать плохо и стыдиться потом смотреть в глаза соседям?
В принципе, в магазинах бывают привозные (Израиль, Морокко), но зачем они, когда есть местные и очень сочные.
Насчёт «не очень экономично выбрасывать» — никто и не выбрасывает. К вечеру в магазинах почти пустые лотки с овощами. Кто опоздал — тот остаётся с яблоками, которые могут несколько дней лежать, да квашенными оливками (аналогично).
И это общепринятая практика. Более того, часто бывает так, что если вечером приезжаешь в мясную лавку, а там ещё мясо с утреннего раздела осталось, то мясник может сказать, что лучше не брать, потому что «уже давно разделано» (читай, часа 4 назад) и посоветовать прийти лучше завтра утром.
Где берут парное молоко не знаю, а в магазины завозят рано утром.
Почему местные должны делать назло и всё плохо? Не путайте Грецию и Кипр, это у Греции с внешним долгом всё плохо, а Кипру всё более-менее ок, кроме греческого долга (перед Кипром).
Это другой менталитет — зачем людям делать плохо и стыдиться потом смотреть в глаза соседям?
> Гниль, а точнее, плесень, показатель того, что их не мыли (там даже на свежих можно нащупать лёгкий пушок будущего пеницилина).
Плесень нельзя «смыть». Не знаю на сколько конкретная плесень вредная, но за показатель качества заражение грибками я не считаю в принципе.
Как и уменьшение срока годности продуктов. Так не далеко до того, что бы над витриной с фруктами споры плесени распылять, что бы у вас они быстро портились, а на складе — нет.
Это не «на зло» — это выгоднее.
Открываем вики — 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.
Нет, ничего не путаю. Зачем людям делать плохо, если можно взять кредит и не отдавать.
Вообще, то что вы рассказываете может быть применимо только к местным продуктам, проще говоря вы передёргиваете.
Плесень нельзя «смыть». Не знаю на сколько конкретная плесень вредная, но за показатель качества заражение грибками я не считаю в принципе.
Как и уменьшение срока годности продуктов. Так не далеко до того, что бы над витриной с фруктами споры плесени распылять, что бы у вас они быстро портились, а на складе — нет.
Это не «на зло» — это выгоднее.
Открываем вики — 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.
Нет, ничего не путаю. Зачем людям делать плохо, если можно взять кредит и не отдавать.
Вообще, то что вы рассказываете может быть применимо только к местным продуктам, проще говоря вы передёргиваете.
Споры можно смыть. Например, беловатое на винограде — это как раз плесень, которая всю жизнь на нём живёт. Аналогично с цитрусовыми.
Впрочем, объяснять это почти бесполезно, надо просто сравнить ту химию, которую продают в МСК/Питере и свежие…
В питерское время иногда на прилавках за бешенные деньги попадались мандарины 'bollo' (продавались в деревянных ящичках). Вот примерно такое же, только более спелое.
Насчёт «нельзя смыть» — можно. Если апельсины вымыть, то плесень не появится в течение нескольких недель.
Насчёт долга — был неправ, не интересовался вопросом.
Вопрос применим не только к местным продуктам. Если кто-то начнёт продавать откровенную халтуру под видом качественных продуктов, то как он в глаза соседям смотреть будет?
Впрочем, объяснять это почти бесполезно, надо просто сравнить ту химию, которую продают в МСК/Питере и свежие…
В питерское время иногда на прилавках за бешенные деньги попадались мандарины 'bollo' (продавались в деревянных ящичках). Вот примерно такое же, только более спелое.
Насчёт «нельзя смыть» — можно. Если апельсины вымыть, то плесень не появится в течение нескольких недель.
Насчёт долга — был неправ, не интересовался вопросом.
Вопрос применим не только к местным продуктам. Если кто-то начнёт продавать откровенную халтуру под видом качественных продуктов, то как он в глаза соседям смотреть будет?
Я не спорю, что на фруктах бывает плесень. Но это минус, а не плюс.
Просто брак. Как, не знаю, содержимое кишечника барана на свежеразделанной туше.
Плесень смыть нельзя. Смыть можно споры. Может быть они созревают за 2 недели, но при этом внутри апельсина плесень продолжает жизнедеятельность и что там за химия — я не знаю.
Болло не встречал, то что в интернете висит ценой от покупаемых мной радикально не отличается, подозреваю, что вы сравниваете с лежащим в супермаркетах по 100р. Пока вы не переехали к магазину, где привозят свежие фрукты вы не руководствовались «Короче, выбирайте магазины и продавцов»?
Никто не продаёт «откровенную халтуру» и «под видом». Есть же десяток маркетинговых характеристик, которые исключают попадание в «откровенную халтуру».
И можно продавать говно. Нужен просто триггер, например соседи попросят вернуть долги, чуть повыше налоги, чуть поменьше спрос. Как в глаза смотреть? Ну как таджики из под кассы в питере смотрели, так и тут.
И не «вопрос применим», а ваши примеры.
«свежие фрукты из соседнего сада в магазинах есть. До обеда.». А работающим людям, идущим в магазин после заката? Есть говно, которое осталось.
Есть ли у вас свежее спелое тайское манго? Нет? Оно же у вас не растёт? Вот поэтому рассказанное вами применимо только к местным товарам.
Просто брак. Как, не знаю, содержимое кишечника барана на свежеразделанной туше.
Плесень смыть нельзя. Смыть можно споры. Может быть они созревают за 2 недели, но при этом внутри апельсина плесень продолжает жизнедеятельность и что там за химия — я не знаю.
Болло не встречал, то что в интернете висит ценой от покупаемых мной радикально не отличается, подозреваю, что вы сравниваете с лежащим в супермаркетах по 100р. Пока вы не переехали к магазину, где привозят свежие фрукты вы не руководствовались «Короче, выбирайте магазины и продавцов»?
Никто не продаёт «откровенную халтуру» и «под видом». Есть же десяток маркетинговых характеристик, которые исключают попадание в «откровенную халтуру».
И можно продавать говно. Нужен просто триггер, например соседи попросят вернуть долги, чуть повыше налоги, чуть поменьше спрос. Как в глаза смотреть? Ну как таджики из под кассы в питере смотрели, так и тут.
И не «вопрос применим», а ваши примеры.
«свежие фрукты из соседнего сада в магазинах есть. До обеда.». А работающим людям, идущим в магазин после заката? Есть говно, которое осталось.
Есть ли у вас свежее спелое тайское манго? Нет? Оно же у вас не растёт? Вот поэтому рассказанное вами применимо только к местным товарам.
Отвечу на главный вопрос: а нефиг по магазинам после работы ходить. Да, такой суровый остров. Рыбу прекращают продавать в 6, остальное — в 8. И если тебе приспичило купить поесть в 10 вечера — периптеры (киоски 24 часа со скудным ассортиментом джанкфуда) тебе в помощь. Или в ресторан (не сильно дороже получится).
Зато всё свежее.
Зато всё свежее.
Никто не призывает делать говно. Если не сделать 10 фич в продукт, которые могли бы быть необходимыми и продавать их отдельно, продукт не обязательно будет говном.
PS. К сожалению, продавать говно — это норма. Зайдите в магазин, в котором вы покупаете продукты и убедитесь :-(
Норма для человека, это то с чем он согласен. Если вы с этим согласны, и не хотите ничего с этим делать, то это ваши проблемы.
Пример из IT: Вы реально поверите, когда новый ПМ вам скажет, что вы должны работать без выходных и баги править в личное время, т.е по ночам и за старую зарплату. Потому, что у него типа все сотрудники так делают и для него, это норма? Вы в это поверите и сразу согласитесь?
Такая уж задача у бизнеса, всё сделать побыстрее и подешевле. Но вот вопрос, если всё вначале делать в сжатые сроки и по быстрому как просит менеджер, то кто потом будет по ночам сидеть и в лапша-коде ковыряться и окажется крайний, если не уложится в срок? Менеджер или программист?
НЛО прилетело и опубликовало эту надпись здесь
Это надо бизнесу объяснить. Чем продукт за $100 хуже продукта за $1700.
А также почему надо подождать полгода и переписать проект (просто переписать, даже новые фичи не добавлять), а не запиливать новые фичи завтра.
А также почему надо подождать полгода и переписать проект (просто переписать, даже новые фичи не добавлять), а не запиливать новые фичи завтра.
НЛО прилетело и опубликовало эту надпись здесь
> Т. е., предложив клиенту свой малофункциональный продукт за 100$ и установку его за 1 день, а еще доработку продукта под клиента за 500$ и 3 дня, компания выигрывает.
А что помешает клиенту сразу купить продукт у конкурентов за 250$, сэкономив таким образом почти 1500$? (конкуренция то сейчас огромная)
А что помешает клиенту сразу купить продукт у конкурентов за 250$, сэкономив таким образом почти 1500$? (конкуренция то сейчас огромная)
Я всего лишь пример привел. Можно и за 250 баксов продать, для бизнеса такой вариант, всё равно, лучше чем стартовые 100$ :-)
Дык для того чтобы впарить и нужны эффективные менеджеры!
А что помешает клиенту сразу купить продукт у конкурентов за 250$, сэкономив таким образом почти 1500$? (конкуренция то сейчас огромная)Отсутствие цен $250 и $1700 на ценнике, очевидно. Это из той же серии, что и пакеты молока по 700 грамм и гречки по 900.
Казалось бы: ну кем нужно быть, чтобы на это купиться? Но кошелёк не обманешь: продажи растут.
Чтобы понять позицию «твой код никого не интересует», надо подойти со стороны бизнеса: зарабатывание денег, выплата ЗП своим сотрудникам, уплата налогов, в общем, с точки зрения доходов/расходов компании или отдельно взятого человека. Например, утверждение «идеальный код — залог успешного бизнеса» может казаться логичным, но с точки зрения доходов/расходов далеко не всегда истинно.
Задача бизнеса — обеспечить поток денег. Задача инженеров — обеспечить поток фич. Эти 2 задачи безусловно «как-то» связаны друг с другом, но не обязательно так, как описано в статье. Если бизнес завязывает поток денег напрямую на поток фич — это проблема бизнеса, а не инженеров.
Автору респект. Правильную тему поднял.
Мы последние годы в обязательном порядке в процессе разработки учитываем не только требования заказчика, но и интересы своей конторы. У нас есть стадия анализа востребованности проекта, где мы решаем, насколько и в каком объёме нам (нам, а не заказчику!) нужен продукт. При разработке требований мы учитываем и требования заказчика, и требования своего бизнеса. Фичуризм учитывается как риск. При реализации всегда исходим из минимальных затрат, позволяющих удовлетворить требования заказчика. Начиная с концепции и заканчивая кодированием.
Это даёт свои плоды. Наше ПО применимо, работает правильно и чуть лучше, чем у конкурентов. Может работать ещё лучше, но… всему своё время.
Мы последние годы в обязательном порядке в процессе разработки учитываем не только требования заказчика, но и интересы своей конторы. У нас есть стадия анализа востребованности проекта, где мы решаем, насколько и в каком объёме нам (нам, а не заказчику!) нужен продукт. При разработке требований мы учитываем и требования заказчика, и требования своего бизнеса. Фичуризм учитывается как риск. При реализации всегда исходим из минимальных затрат, позволяющих удовлетворить требования заказчика. Начиная с концепции и заканчивая кодированием.
Это даёт свои плоды. Наше ПО применимо, работает правильно и чуть лучше, чем у конкурентов. Может работать ещё лучше, но… всему своё время.
Все чаще встречаются статьи «о качестве кода» да и от своих коллег, тоже подобное слышал (тех, кто на конторах работает). А слышу одно: в бизнесе нужны деньги и чтобы работали твои алгоритмы. А как они работают это уже никому не интересно.
Кстати печально, но такова правда жизни.
Кстати печально, но такова правда жизни.
Ваши эмоции понятны. Но картина несколько другая. У нас, во всяком случае.
У нас разрабатывалась несколько лет назад комплексная система безопасности. Поставлялась как «коробка». Покупателей было не очень много, но они были, и проект приносил прибыль. К нам приехал начальник службы безопасности АФК «Система» с кучей фич, которые, как он считал, самые нужные и обязательно должны быть реализованы в нашем продукте. Надо сказать, он был сильно удивлён, услышав мой твёрдый отказ. У нас была стратегия развития продукта, и его фичи нарушали эту стратегию. Мы могли попасть на сопровождение «кастомной» версии, что могло сделать проект убыточным в среднесрочной перспективе.
Мы включили в проект только небольшую функцию для поддержки печати пропусков на магнитных картах. Небольшой плагин. И таки поставили наш продукт в АФК. И получили благодарность и рекомендации, благодаря которым смогли привлечь других покупателей.
На самом деле, заказчику ВАЖНО как работает код. И бизнесу это очень ВАЖНО. Потому что корректно написанный код, учитывающий жизненно важные потребности исполнителя и заказчика, становится опорой для бизнеса и того, и другого.
Но да, есть вещи, которые бывают неважны. Например, если один и тот же функционал может достигаться применением старой, проверенной и надёжной технологии или новой, перспективной, но пока не проверенной, и заказчик, и топ-менеджмент исполнителя предпочтут первое, хотя программисту хотелось бы использовать второе.
Так что код интересен всем, но у каждого при этом свой интерес.
У нас разрабатывалась несколько лет назад комплексная система безопасности. Поставлялась как «коробка». Покупателей было не очень много, но они были, и проект приносил прибыль. К нам приехал начальник службы безопасности АФК «Система» с кучей фич, которые, как он считал, самые нужные и обязательно должны быть реализованы в нашем продукте. Надо сказать, он был сильно удивлён, услышав мой твёрдый отказ. У нас была стратегия развития продукта, и его фичи нарушали эту стратегию. Мы могли попасть на сопровождение «кастомной» версии, что могло сделать проект убыточным в среднесрочной перспективе.
Мы включили в проект только небольшую функцию для поддержки печати пропусков на магнитных картах. Небольшой плагин. И таки поставили наш продукт в АФК. И получили благодарность и рекомендации, благодаря которым смогли привлечь других покупателей.
На самом деле, заказчику ВАЖНО как работает код. И бизнесу это очень ВАЖНО. Потому что корректно написанный код, учитывающий жизненно важные потребности исполнителя и заказчика, становится опорой для бизнеса и того, и другого.
Но да, есть вещи, которые бывают неважны. Например, если один и тот же функционал может достигаться применением старой, проверенной и надёжной технологии или новой, перспективной, но пока не проверенной, и заказчик, и топ-менеджмент исполнителя предпочтут первое, хотя программисту хотелось бы использовать второе.
Так что код интересен всем, но у каждого при этом свой интерес.
Вспомнилось тут, что у Джоэля Спольски была заметка «Мастерство». Он там говорил, что иногда исправление 1% ошибок влечёт 500% усилий. Так вот, лучше я со своей командой сделаю ещё 5 проектов, чем буду править ошибку, которая не сказывается на применимости и правильности нашего ПО. И, заметьте, если эти проекты будут сделаны для одного и того же заказчика, он будет больше счастлив, чем если бы ему пришлось ждать всё это время от нас исправления бага, незначительного для его бизнеса.
Это всецело зависит от области деятельности. Если решаемая задача mission critical или, тем более, life critical, то увеличение затрат в 5 раз ради сведения вероятности какой-нибудь определенной ошибки с 1% до 0.1% может оказаться оправданным.
Как всегда, это вопрос рисков (т. е. вероятности ошибки на сумму убытков от её реализации). И, если риск маленький (низкая вероятность и/или маленькие потенциальные убытки), то любой разумный управленец на эту ошибкуположитпоставит резолюцию «не трогать».
Как всегда, это вопрос рисков (т. е. вероятности ошибки на сумму убытков от её реализации). И, если риск маленький (низкая вероятность и/или маленькие потенциальные убытки), то любой разумный управленец на эту ошибку
то любой разумный управленец...
Мне кажется, но весь смысл этой статьи именно в этой фразе.
И никогда не будет разногласия кто что и как будет делать.
А если к людям подходить как к винтикам в системе, которые можно заменить, то можно и не начинать разговор о проф навыках.
Это из личного опыта, совсем недавнего
Поработал на одну организацию где на качество забивали болт.
Выполнял работу в 3 раза быстрее тех программистов (качество когда было лучше раз в 5, их еще пришлось обучать при учете, что я раньше не работал программистом, только ради фана программировал), сделал их работу, запустил этот «стартап» за 2 месяца (без меня сидели 4). Ушел из этого болота.
Написать данный комментарий подтолкнули меня комментарии, а точнее сама статья, которая говорила о полном или частичном непонимании того, что смотреть с точки зрения бизнеса программисту есть смысл, только если это его бизнес или он по совместительству заодно и продает этот продукт. В остальных же случаях, программисту вполне достаточно того, что он хорошо делает своё дело — выполняет свою техническую работу. А с точки зрения бизнеса на бизнес смотрят те, кто этим бизнесом занимается. Потому что они получают за это деньги. Так что хватит мешать отвественности.
Как говаривал один популярный бюрократ, you are technically correct — the best kind of correct.
Однако понимание программистом бизнеса — это полезный навык. Будучи скорее программистом, я бесконечно далек от мысли, что надо бросаться делать работу за директоров; с другой стороны, мы с директорами в одной лодке же.
Сегодня я приложу усилия, чтобы понять их приоритеты, а завтра они с ненулевой вероятностью захотят в ответ понять мои — и жизнь станет лучше, трава зеленее, совокупные чемоданы с деньгами толще.
Однако понимание программистом бизнеса — это полезный навык. Будучи скорее программистом, я бесконечно далек от мысли, что надо бросаться делать работу за директоров; с другой стороны, мы с директорами в одной лодке же.
Сегодня я приложу усилия, чтобы понять их приоритеты, а завтра они с ненулевой вероятностью захотят в ответ понять мои — и жизнь станет лучше, трава зеленее, совокупные чемоданы с деньгами толще.
Конечно, я ни в коем случае не предлагаю «не понимать приоритеты бизнеса». Просто говорю о том, учитывать их в своей работе — не задача программиста. Думаю, этим вполне может заниматься ПМ или кто там еще стоит между программистами и бизнесом. Именно он учитывает приоритеты бизнеса, когда транслирует реквест в задачи программистам (именно поэтому интересы бизнеса будут удовлетворены, а не потому что программист приложил усилия, чтобы понять чьи-то приоритеты). И наверное программисту морально проще понимать зачем нужен реквест, но по большому счету совершенно не обязательно. А если бизнес своими реквеставми требует от тебя работать не так, как ты считаешь возможным, то ты просто находишь более подходящего постановщика задач, ведь в конечном итоге, ты строишь не свой дом, а дом какого-то дяди.
Баба Клава должна держать офис в чистоте, потому за целостностью оборудования после её уборки должны следить программисты и админы. Хватит уже мешать ответственности.
Программисту имеет смысл всегда смотреть на продукт с точки зрения бизнеса, потому что бизнес на самом деле для него главный и единственный заказчик. Если он не продаёт продукт и это не его бизнес, то на этом все разговоры заканчиваются, и он просто выполняет именно то, что правильно с точки зрения бизнеса. Или идёт искать другую работу.
Но если программист проявляет усердие и воспринимает продукт как свой бизнес, то у него появляется возможность проявлять инициативу и за счёт этого расти. Он начинает по-другому воспринимать желания заказчика и своего руководства, и, понимая разницу между желаниями и истинными потребностями и имея техническую подготовку, может предлагать весьма интересные альтернативы. И тогда ему доверяют больше, платят больше, стараются дать более ответственные проекты.
Конечно, только сам программист решает, как воспринимать свой продукт.
Но если программист проявляет усердие и воспринимает продукт как свой бизнес, то у него появляется возможность проявлять инициативу и за счёт этого расти. Он начинает по-другому воспринимать желания заказчика и своего руководства, и, понимая разницу между желаниями и истинными потребностями и имея техническую подготовку, может предлагать весьма интересные альтернативы. И тогда ему доверяют больше, платят больше, стараются дать более ответственные проекты.
Конечно, только сам программист решает, как воспринимать свой продукт.
НЛО прилетело и опубликовало эту надпись здесь
Путей много. Я вот до архитектора дорос. Знакомый техническим директором стал в не самой слабой компании. Как говорил старина Деминг: «Совершенствоваться не обязательно. Выживание — дело добровольное.»
НЛО прилетело и опубликовало эту надпись здесь
Рост — понятие комплексное. Если менеджеры чувствуют Ваше понимание и видят Ваши способности, они дают Вам более ответственные проекты, в результате чего Вы получаете возможность изучать новые технологии и работать над более сложными проблемами. Бизнес начинает вкладывать в Вас деньги: у Вас появляется более комфортное рабочее место, более качественное оборудование, нужная поддержка со стороны других специалистов. Возможно, Вас пошлют на курсы повышения квалификации, особенно, если бизнес заинтересован в наличии у некоторых сотрудников «корочек». Иными словами, профессиональный рост программиста имеет сильную зависимость от его лояльности понимания интересов бизнеса.
Но должен Вас огорчить. Одним из интересов бизнеса является рост Вашей ответственности. Не только ответственности за свой код, но и ответственности за работу всей команды в целом. Те же «корочки» бизнесу нужны, чтобы показать потенциальному заказчику способность команды реализовать сложный проект. Но заказчика редко интересует рядовой программист с кучей корочек. Заказчику нужны ключевые разработчики — архитекторы, тим-лиды, ведущие программисты. Те, с кого он может спросить.
Поэтому, если Вы хотите развиваться как программист, Вы должны понять, что отсидеться в стороне не удастся. Как говорил Джоэль Спольски:
Но должен Вас огорчить. Одним из интересов бизнеса является рост Вашей ответственности. Не только ответственности за свой код, но и ответственности за работу всей команды в целом. Те же «корочки» бизнесу нужны, чтобы показать потенциальному заказчику способность команды реализовать сложный проект. Но заказчика редко интересует рядовой программист с кучей корочек. Заказчику нужны ключевые разработчики — архитекторы, тим-лиды, ведущие программисты. Те, с кого он может спросить.
Поэтому, если Вы хотите развиваться как программист, Вы должны понять, что отсидеться в стороне не удастся. Как говорил Джоэль Спольски:
«Ты никогда не стремился стать менеджером. Как и большинство разработчиков программ, с которыми я знаком, ты был бы гораздо счастливее, если бы тебе позволили спокойно сидеть и писать код. Но ты лучший разработчик...»
Баба Клава должна держать офис в чистоте, потому за целостностью оборудования после её уборки должны следить программисты и админы. Хватит уже мешать ответственности.
Нет, бабе Клаве должны сказать где можно мыть, а где нет. Это разделение ответственности. Вот если баба Клава сама начинает решать как и что её мыть — вот тогда она берет ответственность системного администратора на себя.
В случае программистом должны быть те (бизнес аналитики, продажники и ПМ'ы) кто скажет что нужно мыть, а что ни в коем случае. Это называется планированием имплементации и это не задача программиста. Задача программиста — сделать поставленные задачи в нужном объеме, максимально качественно/быстро.
В случае программистом должны быть те (бизнес аналитики, продажники и ПМ'ы) кто скажет что нужно мыть, а что ни в коем случае. Это называется планированием имплементации и это не задача программиста. Задача программиста — сделать поставленные задачи в нужном объеме, максимально качественно/быстро.
максимально качественно/быстро.
Я бы заменил на «максимально качественно и быстро». Правда максимально качественно как это возможно за определённый период времени :-)
Программисту как и бабе Клаве говорят что сделать и за какой период, а они берут и начинают фичи на будущее добавлять, новые суперправильные подходы применять и пр. самодеятельность.
Вот приведу пример из недавнего. Мы в нашей компании писали сервис на ангуляре 1. Писали около года. Заложились на фичи под будущее. А потом бац! И вышла версия №2, не сильно похожая на версию №1. И скорее всего когда наступит то будущее, когда будут внедрятся фичи будущего, будет уже третья версия ангуляра. И спрашивается зачем все эти старания были и будет ли в будущем поддержка нашего кода легче и проще?
Понимаете, вы сейчас свой опыт JavaScript разработчика пытаетесь эстрополировать вообще на любых программистов. Я не пытаюсь никого обидеть, но в силу ряда особенностей самого языка JavaScript и особенно фреймворков на нем зачастую действительно приходится делать выбор между писать правильно/красиво или быстро.
В промышленных языках бекенда (вроде Java, С# и т.п.) все сделано (от самого языка до IDE) для того чтобы наиболее правильный и красивый код был бы одновременно наиболее быстрым для написания и легким для отладки и понимания остальными (ибо для того они и разрабатывались). Поэтому там предложения «а давайте мы быстро тут наговнокодим» воспринимается как извращение в особо сильной форме. ИМХО, конечно.
В промышленных языках бекенда (вроде Java, С# и т.п.) все сделано (от самого языка до IDE) для того чтобы наиболее правильный и красивый код был бы одновременно наиболее быстрым для написания и легким для отладки и понимания остальными (ибо для того они и разрабатывались). Поэтому там предложения «а давайте мы быстро тут наговнокодим» воспринимается как извращение в особо сильной форме. ИМХО, конечно.
Ну, и к тому же если на вебе ошибки в коде как правило лишь слегка мешают пользователю, то в беке клиент легко может потерять данные или деньги.
В целом за 10 лет разработки на Java я практически ни разу не сталкивался с ситуацией когда говнокодирование выигрывало по скорости (не берем всякие одноразовые классики для служебных целей)
В целом за 10 лет разработки на Java я практически ни разу не сталкивался с ситуацией когда говнокодирование выигрывало по скорости (не берем всякие одноразовые классики для служебных целей)
Кстати, я не писал о «а давайте мы быстро тут наговнокодим». Если в Java, С# и т.п. качественный код пишется быстро и легко — это невероятно прекрасно. Разработчикам на этих языках повезло.
Я писал о том, что во главу угла проекта надо ставить финансовую сторону, так как без неё программист не сможет просто работать, так как не ясно откуда возьмутся деньги ему на ЗП. А ещё точнее: качественный код не приносит деньги, деньги приносят клиенты. Это не значит, что им надо напаривать говно, просто у них может быть запущена реклама через месяц, потому к этому времени надо подготовить проект и времени на изящества может не быть.
Если в Java, С# и т.п. говнокод — удорожание, пишите без говонокода. Если в вашем языке нет быстрых изящных решений, то не стоит бояться костылей. В общем, смотрите по финансам и времени.
Я писал о том, что во главу угла проекта надо ставить финансовую сторону, так как без неё программист не сможет просто работать, так как не ясно откуда возьмутся деньги ему на ЗП. А ещё точнее: качественный код не приносит деньги, деньги приносят клиенты. Это не значит, что им надо напаривать говно, просто у них может быть запущена реклама через месяц, потому к этому времени надо подготовить проект и времени на изящества может не быть.
Если в Java, С# и т.п. говнокод — удорожание, пишите без говонокода. Если в вашем языке нет быстрых изящных решений, то не стоит бояться костылей. В общем, смотрите по финансам и времени.
во главу угла проекта надо ставить финансовую сторону, так как без неё программист не сможет просто работать, так как не ясно откуда возьмутся деньги ему на ЗП.
Ваш подход будет замечательно работать для команд, состоящих из одного человека. В случае команд из двух и более людей начинаются проблемы :-)
Программист будет работать в компании только до тех пор, пока ему нравится работать в этой компании. «Нравится» состоит, например, из: размера зарплаты, гламурности офиса, «веры» в востребованность своей работы, профессионального роста и ещё пары десятков очевидных и не очень очевидных вещей.
Программист (если это «профессиональный программист», а не «студент») стабильно работает с примерно одной и той же производительностью — у него нет перепадов типа «я вчера запилил десяток фич, поэтому следующие 3 дня работать не буду, а после этого буду работать вполсилы». Например, программист может делать одну фичу в неделю. Стабильно.
Бизнес (основанный на программировании) будет существовать только до тех пор, пока появляются новые фичи. Если в команде есть 5 программистов, можно теоретически ожидать 5 фич в неделю. Так вот задача бизнеса — продавать эти самые «5 фич в неделю» таким образом, чтобы в итоге и на зарплату хватило, и компы новые можно было купить, и ещё осталось «на всякий случай». И конечно же речь не идёт о том, чтобы взять «хочу столько денег», поделить на «есть столько фич» и пытаться продавать фичи по той цене, которая получилась. Где-то здесь появляется «суть бизнеса» :-)
Если сравнивать с автомобилем, то дополнительное оборудование которое может/должно входить в стоимость и качество автомобиля, это разные вещи.
Качество, кстати, всегда работает на перспективу.
Сравните качество BMW и GreatWall.
То же самое и с кодом.
Качество, кстати, всегда работает на перспективу.
Сравните качество BMW и GreatWall.
То же самое и с кодом.
Далеко не всегда качество работает на перспективу, поскольку стоимость обеспечения качества «сейчас» и «спустя год после начала продаж» может отличаться в разы и даже на порядки, и почти всегда не в пользу варианта «сейчас». Зачастую случается так:
Отдельно от себя добавлю к примеру, что у Пети, который работал «на перспективу», в большинстве случаев получится не «вылизанное приложение», а никому не нужная фигня, оторванная от реальности, поскольку за всё время он был единственным её пользователем, и у него замылился глаз ещё на второй день разработки.
Пишите код, который можно выкатывать на реальных пользователей, с минимальной оглядкой на качество кода. Вы не знаете, что хотят пользователи. Даже заказчик не может заглянуть им в головы и узнать, что они хотят. Позвольте пользователям как можно быстрее работать на кривом-косом MVP, и они сами вам покажут, что им надо. Возможно, через неделю на основе фидбека вы выкинете 90% этого кода и начнёте развивать продукт в совершенно другом направлении. А возможно, он начнёт приносить деньги, и вот уже тогда вы и займётесь качеством.
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге.
Отдельно от себя добавлю к примеру, что у Пети, который работал «на перспективу», в большинстве случаев получится не «вылизанное приложение», а никому не нужная фигня, оторванная от реальности, поскольку за всё время он был единственным её пользователем, и у него замылился глаз ещё на второй день разработки.
Пишите код, который можно выкатывать на реальных пользователей, с минимальной оглядкой на качество кода. Вы не знаете, что хотят пользователи. Даже заказчик не может заглянуть им в головы и узнать, что они хотят. Позвольте пользователям как можно быстрее работать на кривом-косом MVP, и они сами вам покажут, что им надо. Возможно, через неделю на основе фидбека вы выкинете 90% этого кода и начнёте развивать продукт в совершенно другом направлении. А возможно, он начнёт приносить деньги, и вот уже тогда вы и займётесь качеством.
Коротко и лаконично!
Код — он очень разный. Один код идёт в репозиторий на многолетнюю поддержку, другой — пишется на коленке в исследовательских целях и будет запускаться 2-3 раза. Тратить время, делая исследовательский код понятным и сопровождаемым — точно такая-же пустая трата ресурсов, как и сопровождение плохого кода. Только ресурсы эти тратятся здесь, сейчас и вами, а не в предполагаемом будущем вашими сменщиками.
Код должен быть читабелен и поддерживаем ровно настолько, насколько этому коду необходимо с учётом его жизненного цикла. А красоту пусть наводят энтузиасты в сверхурочное неоплачиваемое время.
Код должен быть читабелен и поддерживаем ровно настолько, насколько этому коду необходимо с учётом его жизненного цикла. А красоту пусть наводят энтузиасты в сверхурочное неоплачиваемое время.
Именно!
К сожалению, гражадане этого не понимают и зачастую всё делается «в урочное оплачиваемое время» :-(
А красоту пусть наводят энтузиасты в сверхурочное неоплачиваемое время.
К сожалению, гражадане этого не понимают и зачастую всё делается «в урочное оплачиваемое время» :-(
Я думаю, самая важная фраза ServPonomarev была
Код должен быть читабелен и поддерживаем ровно настолько, насколько этому коду необходимо с учётом его жизненного циклаА вы вырвали из контекста только то, что хотели увидеть.
То есть вас устраивает формулировка «после 18 идите в жопу со своим подходом»?
Так и зародились DLC, которые никто, кроме самого разработчика, не любит. Нельзя толкать людей на такое, ибо скоро люди на таких примерах пойдут делать цены в магазине таким образом:
«Покупайте эту газировку 0.2л всего за 2 рубля!!!» А ниже мелким шрифтом будет написано: Цена, указанная выше, идёт за упаковку. За наполнение упаковки водой вам придётся заплатить 20 рублей, за газ 15 рублей, за ароматизатор 5 рублей и за краситель 7 рублей. Итого мы получаем «Газировку» стоимостью 49 рублей.
ЭТО ЗЛО!
«Покупайте эту газировку 0.2л всего за 2 рубля!!!» А ниже мелким шрифтом будет написано: Цена, указанная выше, идёт за упаковку. За наполнение упаковки водой вам придётся заплатить 20 рублей, за газ 15 рублей, за ароматизатор 5 рублей и за краситель 7 рублей. Итого мы получаем «Газировку» стоимостью 49 рублей.
ЭТО ЗЛО!
Программисты не понимают
Собственно администраторы тоже негодуют. Если работаешь где-то более 5 лет, то видишь, что покупка плохого продукта выливается не только в излишние затраты на оборудование, но и в затраты на поддержку. Так что, написание плохого кода — краткосрочная выгода.
тем не менее эта выгода рулит бизнесом, факт
P.S. Нужно стараться писать идеальный код, конечно. Только вот у бизнеса, к сожалению, на это нет ни времени, ни желания…
Имхо, если это решать, то это надо делать программисту самому, оставаться вечерами в неоплачиваемое время и переписывать большие куски кода. Потому что бизнес не понимает, почему надо переписывать код, и не будет выделять на это время.
Имхо, если это решать, то это надо делать программисту самому, оставаться вечерами в неоплачиваемое время и переписывать большие куски кода. Потому что бизнес не понимает, почему надо переписывать код, и не будет выделять на это время.
что бизнес не понимает, почему надо переписывать код, и не будет выделять на это время.
Просто вы не с тем «бизнесом» сталкивались. Нормальный «бизнес» относится к «качеству продукта» как к машине, непонятно зачем ремонтировать, если вроде и так бегает, но если уж тот кому доверяешь сказал «в сервис» — значит «в сервис». Вопрос тут найти такого технического менеджера, которому «бизнес» мог бы доверять.
Ну если вы готовы батрачить на работодателя сверхурочно за бесплатно, то ради бога. Но лучше бы вы это время в open source вкладывали, честное слово, – будет что потом нормальному работодателю на собеседовании показать.
Любой код должен быть написан идеально. Другое дело, что «идеальный код» – это такой, который наилучшим образом решает поставленую задачу. Так что говнокод на коленке для одноразового скрипта – это и есть идельный код. Но если заказчик или работодатель не понимает, что качество определенного кода выльется им боком в будущем и не выделяет время на рефакторинг, то либо вы не умеете доносить свои мысли коллегам, либо заказчик/работодатель упорот и пора валить.
Любой код должен быть написан идеально. Другое дело, что «идеальный код» – это такой, который наилучшим образом решает поставленую задачу. Так что говнокод на коленке для одноразового скрипта – это и есть идельный код. Но если заказчик или работодатель не понимает, что качество определенного кода выльется им боком в будущем и не выделяет время на рефакторинг, то либо вы не умеете доносить свои мысли коллегам, либо заказчик/работодатель упорот и пора валить.
Тут идет жонглирование двумя понятиями — стратегией продаж и качеством продукта. Покупая авто даже в самой убогой комплектации, покупатель никогда не получит машину с разной компрессией в цилиндрах, отваливающимся глушителем и дырявым бензобаком. Маркетинговая стратегия в компании автора видимо такая — срубим заказ, выставя зараннее зауженные сроки реализации, загоним разработчиков в перегорание и хронический стресс, поставим клиенту говно, потом под соусом «доработки под заказчика» будем допиливать то, что валится слишком явно. А потом еще, на десерт, подпишем клиента на поддержку продукта, потом что багов в таком говнософте предостаточно, и они будут периодически всплывать.
Браво, бис!
Браво, бис!
Увы, частенько идею поста некоторые фирмы доводят до — «старясем бабла сколько сможем, наймем код писать кого попало». Понятно, что качество и доход связаны мало. Но иногда заказчик очень прав, ругаясь на качество, но при этом не имеет особых механизмов как-то создать обратную связь такую, чтобы подрядчик хотел делать пусть и не идеальный, но не отстойный код. Увы.
В конце призыв понятный, но (на мой взгляд) несколько однобокий.
Я бы перефразировал в «разработка многих проектов затягивалась на месяцы как из-за излишнего перфекционизма, так и из-за нежелания сделать рефакторинг на пару лет раньше».
А если бы писал статью «с нуля» (только из своего опыта), то получилось бы так: «не видел, чтобы разработка проектов затягивалась из-за излишнего перфекционизма; но из-за нежелания вовремя сделать рефакторинг тратились многие человекогоды», увы.
Просто из-за излишнего перфекционизма и возможности заложиться под «будущие фичи» разработка многих проектов затягивалась на месяцы.
Я бы перефразировал в «разработка многих проектов затягивалась на месяцы как из-за излишнего перфекционизма, так и из-за нежелания сделать рефакторинг на пару лет раньше».
А если бы писал статью «с нуля» (только из своего опыта), то получилось бы так: «не видел, чтобы разработка проектов затягивалась из-за излишнего перфекционизма; но из-за нежелания вовремя сделать рефакторинг тратились многие человекогоды», увы.
Маркетологам кажется, что они понимают.
Крамолу несёт уважаемый автор. Искусство не продаётся.
Если программист начнёт расставлять приоритеты с точки зрения бизнеса, мы получим культ карго и бесконечные времянки, а не процесс разработки. При этом, у разработчика, разумеется, всегда будет работа — бороться с симптомами можно бесконечно.
Если программист начнёт расставлять приоритеты с точки зрения бизнеса, мы получим культ карго и бесконечные времянки, а не процесс разработки. При этом, у разработчика, разумеется, всегда будет работа — бороться с симптомами можно бесконечно.
Если программист будет рассматривать свою работу с точки зрения бизнеса, то его цель будет «сделать как можно меньше, заработать как можно больше, в свободное время запустить новые направления»
Т.е. сиди тихо, бери деньги, давай деньгам работать, пока «в струе». Жаль авторы таких статей это не понимают.
Т.е. сиди тихо, бери деньги, давай деньгам работать, пока «в струе». Жаль авторы таких статей это не понимают.
На мой взгляд постыл статьи не верный и совершенно вредный. Предыдущая статья была совершенно о другом. Дело в том, что опытный программист должен чувствовать необходимую планку качества, которая требуется от конкретного кода и соответсвовать этому качеству.
1. Если нужно слепить до завтра «из говна и палок» чтобы показать клиенту прототип, хороший програмист не смущаясь лепит «из говна и палок» за один день. Бизнес выиграл.
2. Если разрабатывается модуль, крах которого приведет к убыткам бизнеса на тысячи долларов, хорошому программисту будет не западло потратить неделю/месяц на вылизываение кода, написание юнит тестов и т.п. Бизнес выиграл.
А за подход в стиле «впарим клиенту говно-продукт чтобы через месяц он к нам вернулся и мы наварили еще больше бабла» гореть автору в аду.
1. Если нужно слепить до завтра «из говна и палок» чтобы показать клиенту прототип, хороший програмист не смущаясь лепит «из говна и палок» за один день. Бизнес выиграл.
2. Если разрабатывается модуль, крах которого приведет к убыткам бизнеса на тысячи долларов, хорошому программисту будет не западло потратить неделю/месяц на вылизываение кода, написание юнит тестов и т.п. Бизнес выиграл.
А за подход в стиле «впарим клиенту говно-продукт чтобы через месяц он к нам вернулся и мы наварили еще больше бабла» гореть автору в аду.
На одном из начальных этапов своей карьеры работал я в одной фирме, занимался автоматизированным тестированием. И был у нас клиент, очень большой и очень солидный, с другой стороны земного шара. Он продавал свое ПО другим, еще более крупным конторам, на которых держится наш, так сказать, вероятный противник. И крутились там очень большие бабки.
Так вот, ответственно заявляю, что код там был — говно! Причем говно редкостное. Они сами это понимали, поэтому и наняли целый штат специалистов по контролю качества. Но продавать и поддерживать это говно им очень нравилось, так как за это платили большие бабки. С тех пор я твердо уяснил, что главное в разработке ПО (собственно как и везде) — продажи, а не качество кода или свободная конкуренция. Не будет маркетинга и продаж — не будет денег. Не будет денег — никого не будет волновать качество кода. Потому что в этом случае за самый лучший код вам нечем будет платить.
Так вот, ответственно заявляю, что код там был — говно! Причем говно редкостное. Они сами это понимали, поэтому и наняли целый штат специалистов по контролю качества. Но продавать и поддерживать это говно им очень нравилось, так как за это платили большие бабки. С тех пор я твердо уяснил, что главное в разработке ПО (собственно как и везде) — продажи, а не качество кода или свободная конкуренция. Не будет маркетинга и продаж — не будет денег. Не будет денег — никого не будет волновать качество кода. Потому что в этом случае за самый лучший код вам нечем будет платить.
Диагноз — маркетология головного мозга.
Я как раз сейчас на таком проекте работаю. Ну, который именно в такой парадигме и развивался до меня. И где-то с два годика назад заказчику надоело, что его сайт постоянно тормозит, глючит, а за это из него за это еще и качают деньги. И он послал таких маркетолухов нахрен и нашел меня.
Первые пол-года я занимался совсем не тем, что писал новые фишки для сайта — я боролся со старыми глюками. Поскольку код был написан ровно в той парадигме: «Нам заплатили — сделаем говно и подсадим на поддержку!» — это заняло те самые пол-года, а не, скажем, месяц. Фактически, я занимался тем самым рефакторингом — хотя всеми силами старался его избежать. Кое-где получалось отрезать приваренные намертво костыли и как-то подкорректировать код. А кое-где приходилось целые куски выбрасывать и просто писать всё заново — ибо не просто код был поганым, но сами выбранные алгоритмы и решения приводили к тем самым багам, которые мне нужно было исправить.
Затем — всё работало нормально примерно три месяца. А дальше — опять началась веселуха: росла посещаемость и сайт начинал тормозить. Просто потому, что начинали «играть» не просто хреновые алгоритмы — но хреновые архитектурные решения. И снова в бой — уже не просто рефакторинг, а переписывание целых подсистем — да еще с обратной совместимостью с остальным старым убогим кодом (весь код сразу не перепишешь, а сайт должен работать без тормозов уже ВЧЕРА) и с модулями вывода (которые создавались тоже через жопу). Ну, фигли нам — клёвым паладинам! Неделя вкалываний по 10-12-14 часов — и узкое место расшито, очередная подсистема переписана с нуля и сайт летает, шо живой… Следующие три месяца. А затем — всё опять по-новой. Тем более, что сайт потихоньку раскручивался и стала расти посещаемость…
После третьей итерации, заказчик стал подозревать, что надо что-то делать — и решил полностью переписать сайт с нуля уже руками нормальных программистов. Ирония в том, что всё это время сайт должен был работать, что бы дать денег тем самым нормальным программистам. Поэтому поддержку сайта никто не отменял.
И тут упёрлись, так сказать, не просто в архитектуру приложения — а уже в узкие места так сказать мета-архитектуры аппаратного решения, которые тоже пришлось расшивать…
Итог? С заказчика вытянули кучу денег. Заказчику это надоело — он послал нахрен плотный коллектив менеджеров и студентов-говнокодеров и ушел от фирмы.
Было ли это выгодно фирме? На тактическом уровне — безусловно! Денег было выкачано столько, что мне даже страшно сказать. Было ли это выгодно фирме на стратегическом уровне? Очевидно — нет. Заказчик не только сам теперь не обратиться в эту контору, но еще и «распиарит» её всем знакомым.
Я как раз сейчас на таком проекте работаю. Ну, который именно в такой парадигме и развивался до меня. И где-то с два годика назад заказчику надоело, что его сайт постоянно тормозит, глючит, а за это из него за это еще и качают деньги. И он послал таких маркетолухов нахрен и нашел меня.
Первые пол-года я занимался совсем не тем, что писал новые фишки для сайта — я боролся со старыми глюками. Поскольку код был написан ровно в той парадигме: «Нам заплатили — сделаем говно и подсадим на поддержку!» — это заняло те самые пол-года, а не, скажем, месяц. Фактически, я занимался тем самым рефакторингом — хотя всеми силами старался его избежать. Кое-где получалось отрезать приваренные намертво костыли и как-то подкорректировать код. А кое-где приходилось целые куски выбрасывать и просто писать всё заново — ибо не просто код был поганым, но сами выбранные алгоритмы и решения приводили к тем самым багам, которые мне нужно было исправить.
Затем — всё работало нормально примерно три месяца. А дальше — опять началась веселуха: росла посещаемость и сайт начинал тормозить. Просто потому, что начинали «играть» не просто хреновые алгоритмы — но хреновые архитектурные решения. И снова в бой — уже не просто рефакторинг, а переписывание целых подсистем — да еще с обратной совместимостью с остальным старым убогим кодом (весь код сразу не перепишешь, а сайт должен работать без тормозов уже ВЧЕРА) и с модулями вывода (которые создавались тоже через жопу). Ну, фигли нам — клёвым паладинам! Неделя вкалываний по 10-12-14 часов — и узкое место расшито, очередная подсистема переписана с нуля и сайт летает, шо живой… Следующие три месяца. А затем — всё опять по-новой. Тем более, что сайт потихоньку раскручивался и стала расти посещаемость…
После третьей итерации, заказчик стал подозревать, что надо что-то делать — и решил полностью переписать сайт с нуля уже руками нормальных программистов. Ирония в том, что всё это время сайт должен был работать, что бы дать денег тем самым нормальным программистам. Поэтому поддержку сайта никто не отменял.
И тут упёрлись, так сказать, не просто в архитектуру приложения — а уже в узкие места так сказать мета-архитектуры аппаратного решения, которые тоже пришлось расшивать…
Итог? С заказчика вытянули кучу денег. Заказчику это надоело — он послал нахрен плотный коллектив менеджеров и студентов-говнокодеров и ушел от фирмы.
Было ли это выгодно фирме? На тактическом уровне — безусловно! Денег было выкачано столько, что мне даже страшно сказать. Было ли это выгодно фирме на стратегическом уровне? Очевидно — нет. Заказчик не только сам теперь не обратиться в эту контору, но еще и «распиарит» её всем знакомым.
А частичной вины заказчика в том, что сайт стал таким нет?
Речь не о заказчике — речь об фирме-исполнителе, которая в точности следует заветам статьи: говнокод побыстрее, да подсадить заказчика на поддержку — исправление своих же косяков.
И о заказчике. Заказчик написал ТЗ. Чёткое и ясное. Я по этому ТЗ вполне успешно работал полтора года. Так что — нет, это вина не заказчика. Если не считать «виной», что ему попалась «шарашкина контора», которая работала на принципах, описанных в статье.
Ну и еще нюанс. Почему я работаю с заказчиком два года — а успешно работаю по ТЗ всего полтора.
Потому что заказчик забыл всё плохое и избаловался форматом: «Вот тебе пару строчек в скайпе в два ночи — сделай мне фикс/фичу к утру». Полезли всякие: «А почему так долго?», «А я не то хотел!», «А ты меня неправильно понял!» и моё любимое: «Я ЭТО НЕ ПРОСИЛ!». Не говоря уже об обсуждениях аппаратной архитектуры с участием только сисадмина — и без моего участия и ответов в стиле: «Слишком много написал, я не понял — поэтому я это проигнорировал» в ответ на подробной алгоритм миграции сервисов между физическими машинами с минимальным даунтаймом сайта. В итоге, конечно, всё выйдет по-моему (не с потолка же я схему миграции расписывал?) — только моих нервов, денег закзачика, времени всех участвующих и даунтайма сервера будет затрачено намного больше.
И вот это — целиком моя вина.
Потому что заказчик забыл всё плохое и избаловался форматом: «Вот тебе пару строчек в скайпе в два ночи — сделай мне фикс/фичу к утру». Полезли всякие: «А почему так долго?», «А я не то хотел!», «А ты меня неправильно понял!» и моё любимое: «Я ЭТО НЕ ПРОСИЛ!». Не говоря уже об обсуждениях аппаратной архитектуры с участием только сисадмина — и без моего участия и ответов в стиле: «Слишком много написал, я не понял — поэтому я это проигнорировал» в ответ на подробной алгоритм миграции сервисов между физическими машинами с минимальным даунтаймом сайта. В итоге, конечно, всё выйдет по-моему (не с потолка же я схему миграции расписывал?) — только моих нервов, денег закзачика, времени всех участвующих и даунтайма сервера будет затрачено намного больше.
И вот это — целиком моя вина.
Да, мы не понимаем. И не собираемся понимать.
Мы пишем код, это наша работа, нам за неё зарплату платят. И именно поэтому мы отвечаем за свою работу, за её качество.
Меньше фич, быстрее релиз? Это вам к менеджеру проекта, согласовывайте, а мы выпустим релиз попроще и побыстрее, но он все равно будет качественным. API будет документирован, тесты будут написаны, критические баги будут закрыты.
А вот тем программистам, которые пытаются «понимать бизнес» нужно читать Роберта Мартина, для просветления.
Почти месяц назад подкинули простой заказ, но как обычно с подвохом — сделать нужно за три дня. Сделал. Угадайте, когда о нем вспомнили, и потребовалось вносить правки? Правильно — вчера.
Два ценных урока можно извлечь: 1) не верь заказчикам, их «срочно-срочно-срочно» может быть совсем не таким уж и срочным и поспешным; 2) за 3 недели код и его особенности забываются, поэтому код должен быть нормально написан и содержать некоторые комментарии, даже если кажется, что эта поделка на вечер, я и так все помню.
Мы пишем код, это наша работа, нам за неё зарплату платят. И именно поэтому мы отвечаем за свою работу, за её качество.
Меньше фич, быстрее релиз? Это вам к менеджеру проекта, согласовывайте, а мы выпустим релиз попроще и побыстрее, но он все равно будет качественным. API будет документирован, тесты будут написаны, критические баги будут закрыты.
А вот тем программистам, которые пытаются «понимать бизнес» нужно читать Роберта Мартина, для просветления.
Почти месяц назад подкинули простой заказ, но как обычно с подвохом — сделать нужно за три дня. Сделал. Угадайте, когда о нем вспомнили, и потребовалось вносить правки? Правильно — вчера.
Два ценных урока можно извлечь: 1) не верь заказчикам, их «срочно-срочно-срочно» может быть совсем не таким уж и срочным и поспешным; 2) за 3 недели код и его особенности забываются, поэтому код должен быть нормально написан и содержать некоторые комментарии, даже если кажется, что эта поделка на вечер, я и так все помню.
Я согласен с мыслью стать, с точки зрения бизнеса все верно.
Но! Я не очень понимаю, почему меня как программиста, наемного работника, должно это все интересовать? Почему я должен думать о доходах/расходах компании и о том, на чем именно она собирается зарабатывать, а не о качестве кода, архитектуре проекта, организации процесса разработки. Меня вроде как программиста наняли на работу, а не как бизнес аналитика.
Мне, как программисту, выгодно развивать свои профессиональные навыки.
Мне выгодно писать хороший код, мне выгодно изучать новые технологии, мне выгодно совершенствовать свои программы, писать тесты на них и т.д.
Писать же говнокод и непрофессиональные продукты мне не выгодно. Т.е. это может быть выгодно в краткосрочной перспективе, но вот в долгосрочной совсем нет.
Что будет если я 5 лет буду писать говнокод, а потом меня уволят или компания разорится? Кому мне продать свои знания написания говнокода? Как мне получить хорошее место работы с такими вот знаниями? Как объяснить на собеседовании, что это было выгодно моему работодателю?
Так вот, у меня вопрос, почему я должен думать о том, что выгодно текущему работодателю, а не о том, что выгодно мне?
Но! Я не очень понимаю, почему меня как программиста, наемного работника, должно это все интересовать? Почему я должен думать о доходах/расходах компании и о том, на чем именно она собирается зарабатывать, а не о качестве кода, архитектуре проекта, организации процесса разработки. Меня вроде как программиста наняли на работу, а не как бизнес аналитика.
Мне, как программисту, выгодно развивать свои профессиональные навыки.
Мне выгодно писать хороший код, мне выгодно изучать новые технологии, мне выгодно совершенствовать свои программы, писать тесты на них и т.д.
Писать же говнокод и непрофессиональные продукты мне не выгодно. Т.е. это может быть выгодно в краткосрочной перспективе, но вот в долгосрочной совсем нет.
Что будет если я 5 лет буду писать говнокод, а потом меня уволят или компания разорится? Кому мне продать свои знания написания говнокода? Как мне получить хорошее место работы с такими вот знаниями? Как объяснить на собеседовании, что это было выгодно моему работодателю?
Так вот, у меня вопрос, почему я должен думать о том, что выгодно текущему работодателю, а не о том, что выгодно мне?
Вот это видео отражает положение дел у многих контор. Хотя оно уже и не ново.
Напишу тоже.
1) «Заблуждаются не потому что не знают, а потому что думают что знают». Жан Жак Руссо.
2) Программист который способен разобраться в предметной области заказчика в степени достаточной для понимания вопроса — хороший программист. (Это между строчек у Стив Макконнелла и Джона Роббинса)
3) Подходов к разработке много, моделей реализации тоже, что лучше знают те кто на этом зарабатывает.
Да, сам «код» заказчика не интересует. Он требует продукт который решает его задачи.
Про качество кода написано много, но мало вспоминают про архитектуру, не даром у них з.п. с пятью нулями.
Лишний функционал не делают, его не требуют, но он отнимает время и деньги которые никто не закладывал.
1) «Заблуждаются не потому что не знают, а потому что думают что знают». Жан Жак Руссо.
2) Программист который способен разобраться в предметной области заказчика в степени достаточной для понимания вопроса — хороший программист. (Это между строчек у Стив Макконнелла и Джона Роббинса)
3) Подходов к разработке много, моделей реализации тоже, что лучше знают те кто на этом зарабатывает.
Да, сам «код» заказчика не интересует. Он требует продукт который решает его задачи.
Про качество кода написано много, но мало вспоминают про архитектуру, не даром у них з.п. с пятью нулями.
Лишний функционал не делают, его не требуют, но он отнимает время и деньги которые никто не закладывал.
НЛО прилетело и опубликовало эту надпись здесь
На эту тему есть прекрасная лекция Евгения Кривошеева.
Видео
Малофункциональный продукт и говнокод это совсем разные критерии. Вы килограммы с метрами сравниваете.
Обычная статья офисной крысы, котора дальше своего носа и $100 ничего не видит.
На самом деле есть довольно просто формулируемое правило: качество кода должно быть коммерчески оправдано. Эта самая коммерческая оправданность очень, очень зависит от конкретного проекта.
Вот пример, можно сказать, из личного опыта. Было две компании, А и Б. Занимались примерно одним и тем же. Компания А была сильна технологически. У нее был вычищен код, были все элементы грамотно организованного технологического процесса. В компании Б было в два раза меньше программистов, и очень многие вещи делались, что называется, на коленке, на скорую ручку, побыстрее. При этом компания А при ближайшем рассмотрении оказалась убыточна, а компания Б — прибыльна. И, как выяснилось, убыточность во многом происходила из-за непомерных затрат на технологию. При этом там не было особо ненужных трат; просто поддержание такого уровня качества кода и процесса оказалось делом более дорогостоящим, чем компания могла себе позволить.
При этом я не могу сказать, что в компании Б царил сплошной говнокод. Младшие разработчики периодически получали, фигурально говоря, по шее от старших товарищей за особо впечатляющие художества, код периодически просматривался и рефакторился… Просто это не было на столь высоком уровне, не отнимало столько ресурсов.
Так вот, в данной ситуации в компании Б трезвее оценили то, какой уровень качества им нужен и доступен. Да, низкое качество кода впоследствии икнулось и не раз: из-за нестабильности продукта компания потеряла несколько клиентов; пришлось выделять отдельное время на залатывание самых вопиющих дырок; в какой-то момент в компании Б пришлось просто остановить новые разработки и ьросить все силы на восстановление управляемости и стабильности проекта. Конечно, ничего бы этого не случилось, будь качество кода в компании Б на том уровне, на каком оно было в компании А…
… которая до этого момента просто не дожила.
Вот пример, можно сказать, из личного опыта. Было две компании, А и Б. Занимались примерно одним и тем же. Компания А была сильна технологически. У нее был вычищен код, были все элементы грамотно организованного технологического процесса. В компании Б было в два раза меньше программистов, и очень многие вещи делались, что называется, на коленке, на скорую ручку, побыстрее. При этом компания А при ближайшем рассмотрении оказалась убыточна, а компания Б — прибыльна. И, как выяснилось, убыточность во многом происходила из-за непомерных затрат на технологию. При этом там не было особо ненужных трат; просто поддержание такого уровня качества кода и процесса оказалось делом более дорогостоящим, чем компания могла себе позволить.
При этом я не могу сказать, что в компании Б царил сплошной говнокод. Младшие разработчики периодически получали, фигурально говоря, по шее от старших товарищей за особо впечатляющие художества, код периодически просматривался и рефакторился… Просто это не было на столь высоком уровне, не отнимало столько ресурсов.
Так вот, в данной ситуации в компании Б трезвее оценили то, какой уровень качества им нужен и доступен. Да, низкое качество кода впоследствии икнулось и не раз: из-за нестабильности продукта компания потеряла несколько клиентов; пришлось выделять отдельное время на залатывание самых вопиющих дырок; в какой-то момент в компании Б пришлось просто остановить новые разработки и ьросить все силы на восстановление управляемости и стабильности проекта. Конечно, ничего бы этого не случилось, будь качество кода в компании Б на том уровне, на каком оно было в компании А…
… которая до этого момента просто не дожила.
в компании Б пришлось просто остановить новые разработки и ьросить все силы на восстановление управляемости и стабильности проекта. Конечно, ничего бы этого не случилось, будь качество кода в компании Б на том уровне, на каком оно было в компании А…
… которая до этого момента просто не дожила.
А потом у компании Б перестало хватать сил и на поддержание проекта, она потеряла клиентов и её постигла та же судьба, только позже.
Программисты в компании А спокойно делали свою работу, как только компания А разорилась, они нашли компанию В и продолжили спокойно там работать. Программисты в компании Б, из последних сил тянули проваливающийся продукт, получали стрессы, работали по выходным, чтобы вытянуть проект, и в конце, измотанные, оказались перед необходимостью искать новую работу.
Ой какие страсти вы рассказываете. Ужас прям. Но. О гипотетических компаниях хорошо спорить, всегда можно под себя историю повернуть, так что давайте рассмотрим вполне себе конкретный вариант ровно этой истории.
Так когда там у нас компания Б умерла, не подскажете? И где сейчас разработчки из компании А не напомните?
Так когда там у нас компания Б умерла, не подскажете? И где сейчас разработчки из компании А не напомните?
У меня, кстати, компании не гипотетические, а вполне себе конкретные. Но мне не хотелось указывать реальные названия.
Это неважно. Ваша история тем и интересна, что она далеко не уникальна.
Правда заключается в том, что
1) компании с самым ужасным качеством кода всегда проигрывают (как в рассказе akrupa).
2) компании с самым лучшим качеством кода всегда проигрывают (как у вас).
Выигрывают (то есть выживают) только и исключительно компании код которых плох, но не настолько плох, чтобы в попытках его «вытянуть» нужно было работать по 20 часов в день по выходным 7 дней в неделю… ну пару-тройку раз в году придётся, наверное.
Пока программист этого не поймёт, не осознает — за ним нужно следить и в случае чего бить по рукам, а если этого не понимает архитектор — то ваша команда (а может и компания в целом) вообще не жилец.
Правда заключается в том, что
1) компании с самым ужасным качеством кода всегда проигрывают (как в рассказе akrupa).
2) компании с самым лучшим качеством кода всегда проигрывают (как у вас).
Выигрывают (то есть выживают) только и исключительно компании код которых плох, но не настолько плох, чтобы в попытках его «вытянуть» нужно было работать по 20 часов в день по выходным 7 дней в неделю… ну пару-тройку раз в году придётся, наверное.
Пока программист этого не поймёт, не осознает — за ним нужно следить и в случае чего бить по рукам, а если этого не понимает архитектор — то ваша команда (а может и компания в целом) вообще не жилец.
О! Золотые слова!
Я бы только добавил: выигрывают только и исключительно компании, обладающие самым плохим из приемлемого для данной ситуации кода. Потому что требования к этому самому минимальному качеству кода у, скажем, производителя программного обеспечения для самолётов и разработчика онлайн-игрушек будут принципиально разные.
Я бы только добавил: выигрывают только и исключительно компании, обладающие самым плохим из приемлемого для данной ситуации кода. Потому что требования к этому самому минимальному качеству кода у, скажем, производителя программного обеспечения для самолётов и разработчика онлайн-игрушек будут принципиально разные.
Программисты из компании А в компании Б, или других. Им живется мирно и спокойно. У них есть работа и зарплата. Они не пропадут.
Обожаю ссылки на дядю Джоэля!
Обычно люди, дающие такие ссылки, расписываются в собственной ограниченности. По сути — что пишет Джоэль? Он рассказывает об ЕДИНИЧНОМ опыте ОДНОГО программиста по развитию мелкой программерской лавочки. Да, рассказывает убедительно, зажигательно и с огоньком. Вполне возможно, что так легли карты — и кроме отличного продажника (а он именно что «продает» свой личный опыт миллионам читателей) и рассказчика (читать его статьи — очень интересно) в одном человеке уместился еще и хороший программист (ммм… А?).
Но попытка распространения единичного опыта на весь стат-набор — выдает в человеке полное отсутствие хоть какого-то математического образования. В частности — полное незнакомство с таким занимательным разделом, как «статистический анализ» на уровне предпоследнего класса школы с углубленным изучением математики. Ведь то, что этот гипотетический человек пытается сделать — это по результату одного-единственного опыта сразу построить статистику! А это даже круче, чем «50/50» в анекдоте про блондинку и динозавра…
Обычно люди, дающие такие ссылки, расписываются в собственной ограниченности. По сути — что пишет Джоэль? Он рассказывает об ЕДИНИЧНОМ опыте ОДНОГО программиста по развитию мелкой программерской лавочки. Да, рассказывает убедительно, зажигательно и с огоньком. Вполне возможно, что так легли карты — и кроме отличного продажника (а он именно что «продает» свой личный опыт миллионам читателей) и рассказчика (читать его статьи — очень интересно) в одном человеке уместился еще и хороший программист (ммм… А?).
Но попытка распространения единичного опыта на весь стат-набор — выдает в человеке полное отсутствие хоть какого-то математического образования. В частности — полное незнакомство с таким занимательным разделом, как «статистический анализ» на уровне предпоследнего класса школы с углубленным изучением математики. Ведь то, что этот гипотетический человек пытается сделать — это по результату одного-единственного опыта сразу построить статистику! А это даже круче, чем «50/50» в анекдоте про блондинку и динозавра…
Стоит учитывать, что большинство авторов грешат тем же. Ещё и без осознания ограниченности своего видения ситуации.
Кроме того, картины, рисуемые Спольки, часто неплохо пересекаются с реальностью. И его аналитические способности вполне позволяют экстраполировать его частный опыт на некоторые области индустрии.
Кроме того, картины, рисуемые Спольки, часто неплохо пересекаются с реальностью. И его аналитические способности вполне позволяют экстраполировать его частный опыт на некоторые области индустрии.
Перечитал все статьи из своих закладок (которые делал лет пять-шесть назад). Слегка охренел от прочитанного. Погуглил чутку. Еще больше охренел. Провел простейшие матоперации над датами. Охренел настолько, что аж сам разродился статьей: habrahabr.ru/post/257165
В общем — ИМХО совсем всё грустно со ссылками на дядю Джоэля
В общем — ИМХО совсем всё грустно со ссылками на дядю Джоэля
Ну, окончания у этой истории пока нет, так что посмотрим. Для компании Б она может кончиться по-разному. Вполне возможно, что так, как вы описываете. А может, и по другому…
А вот для компании А она УЖЕ ЗАКОНЧИЛАСЬ.
А вот для компании А она УЖЕ ЗАКОНЧИЛАСЬ.
Одно слово: YAGNI
Именно по причине написаного в этой статье программы на моём двухъядерном 3.4 гигагерцовом процессоре работают примерно на такой же скорости, что и когда то на 300 мегагерцовом.
Временем и ресурсами для выполнения программы пожертвовали в пользу уменьшения времени и ресурсов на создание программы. Что с точки зрения здравого смысла глупость, так как пишется программа один раз, а запускается много раз.
В общем что я хочу сказать как программист: горите в аду, маркетологи! :)
Временем и ресурсами для выполнения программы пожертвовали в пользу уменьшения времени и ресурсов на создание программы. Что с точки зрения здравого смысла глупость, так как пишется программа один раз, а запускается много раз.
В общем что я хочу сказать как программист: горите в аду, маркетологи! :)
Я понимаю такую позицию, но всё равно возмущён до глубины души.
Когда в вебстудии берут проекты «интернет-магазин за 20 часов» а через 20 часов сдают сырой кривой проект, и потом на протяжении 2-3 месяцев выполняют БЕСПЛАТНУЮ работу над багами (клиент нашёл баг и пишет — ребята вы накосячили, поправьте) Это намного больший ущерб для бизнеса, чем если бы этот проект изначально рассчитали например на месяц или 2, и сдали в срок нормальный рабочий продукт.
Посчитайте сами. лучше получить деньги за 20 часов работы и потом бесплатно править баги клиенту и получать его недовольство в ответ? Или получить деньги за бОльший срок и получить довольного клиента и хороший сайт который будет легко поддерживать другим программистам?
Например я ни раз сталкивался с сайтом, в котором даже обычный баннер элементарно нельзя поменять или добавить. Иногда доходит до того что в поисках «где же эта хрень подключается» приходится залезать в ядро продукта и находить кривую строчку от какого то нерадивого программиста, который сделал это даже не потому что он нуб, а напротив — опытный разработчик который знает ядро и который знал что так БЫСТРЕЕ! А на дальнейшую поддержку и что кто-то с этим намучается — ему было наплевать. В итоге задача которая должна быть сделана за 5 минут а то и за минуту превращается в часовую работу по поиску быдлокодинга в проекте. Вместо того чтобы сделать за рабочий день 100 таких правок (по ~5 минут) мы приходим к 5-8 правкам. Ну и ответьте мне, любители «склепать побыстрее» кому вы делаете одолжение? ведь большинство веб-студий зарабатывают на дальнейшей поддержке сайта или поддержке чужих проектов, а не на разработке собственных. И из-за чьих то глупых поступков и желания срубить бабла потом появляются вот такие вот статьи и толпы опытных программистов которые несмотря на свой опыт делают говно и пишут быдлокод.
Когда в вебстудии берут проекты «интернет-магазин за 20 часов» а через 20 часов сдают сырой кривой проект, и потом на протяжении 2-3 месяцев выполняют БЕСПЛАТНУЮ работу над багами (клиент нашёл баг и пишет — ребята вы накосячили, поправьте) Это намного больший ущерб для бизнеса, чем если бы этот проект изначально рассчитали например на месяц или 2, и сдали в срок нормальный рабочий продукт.
Посчитайте сами. лучше получить деньги за 20 часов работы и потом бесплатно править баги клиенту и получать его недовольство в ответ? Или получить деньги за бОльший срок и получить довольного клиента и хороший сайт который будет легко поддерживать другим программистам?
Например я ни раз сталкивался с сайтом, в котором даже обычный баннер элементарно нельзя поменять или добавить. Иногда доходит до того что в поисках «где же эта хрень подключается» приходится залезать в ядро продукта и находить кривую строчку от какого то нерадивого программиста, который сделал это даже не потому что он нуб, а напротив — опытный разработчик который знает ядро и который знал что так БЫСТРЕЕ! А на дальнейшую поддержку и что кто-то с этим намучается — ему было наплевать. В итоге задача которая должна быть сделана за 5 минут а то и за минуту превращается в часовую работу по поиску быдлокодинга в проекте. Вместо того чтобы сделать за рабочий день 100 таких правок (по ~5 минут) мы приходим к 5-8 правкам. Ну и ответьте мне, любители «склепать побыстрее» кому вы делаете одолжение? ведь большинство веб-студий зарабатывают на дальнейшей поддержке сайта или поддержке чужих проектов, а не на разработке собственных. И из-за чьих то глупых поступков и желания срубить бабла потом появляются вот такие вот статьи и толпы опытных программистов которые несмотря на свой опыт делают говно и пишут быдлокод.
Похоже вы так ничего и не поняли.
Если же сайт «не взлетит» — тогда тем более будет неважно какой там код у него внутри, так его просто закроют и всё.
P.S. Да, если вы делаете высоконагруенный сайт, где вы просто не можете себе позволить быдлокод — тогда расклад будет другой. Но если вы клепаете сайты «под заказ» — то ситуация такая, какая есть.
Ну и ответьте мне, любители «склепать побыстрее» кому вы делаете одолжение?Бизнесу. Найти покупателя на предложение «интернет-магазин за 20 часов» гораздо проще, чем на «качественный интернет-магазин через месяц или два». И даже если объяснить заказчику все ньюансы, то он, наверняка, препочтет «интернет-магазин за 20 часов». Просто потому что если магазин не совсем убог, то она за месяц или два заработает денег на правки, которые нужно вносить час вместо пяти минут. А экономия времени вашей работы в состав критериев заказчика не входит совсем.
Если же сайт «не взлетит» — тогда тем более будет неважно какой там код у него внутри, так его просто закроют и всё.
ведь большинство веб-студий зарабатывают на дальнейшей поддержке сайта или поддержке чужих проектов, а не на разработке собственныхИ чего это меняет, спрашивается? Отменить формулу «время == деньги» они всё равно не в силах… Закачику нужен определённый результат и он готов оплатить определённое количество часов, точка. Конец дискуссии.
P.S. Да, если вы делаете высоконагруенный сайт, где вы просто не можете себе позволить быдлокод — тогда расклад будет другой. Но если вы клепаете сайты «под заказ» — то ситуация такая, какая есть.
Если бы в каждой нормальной студии тупо отказывались клепать такое дерьмо и отказывались от поддержки таких сайтов, потому что это трата времени на фигню, вот тогда бы любой заказчик трижды подумал — стоит ли отдавать 20 штук за сайт, который потом никто не возьмётся править.
И кстати как показывает практика — заказчику не объяснишь что «у вас сайт плохо сделан, поэтому мы час меняли баннер. и чтобы другой баннер поменять ещё час потратим». Часто возникают претензии типа «и что я должен платить за час работы чтоб вы баннер поменяли?». Так что Ваш вариант о том что у заказчика найдутся деньги чтобы делать часовые маленькие правки — не верен. Им плевать как крив сделан сайт. Для них заменить картинку это работа на 5 минут.и платить вместо этого за час они не хотят. В этом то и вся соль поддержки таких сайтов.
И кстати как показывает практика — заказчику не объяснишь что «у вас сайт плохо сделан, поэтому мы час меняли баннер. и чтобы другой баннер поменять ещё час потратим». Часто возникают претензии типа «и что я должен платить за час работы чтоб вы баннер поменяли?». Так что Ваш вариант о том что у заказчика найдутся деньги чтобы делать часовые маленькие правки — не верен. Им плевать как крив сделан сайт. Для них заменить картинку это работа на 5 минут.и платить вместо этого за час они не хотят. В этом то и вся соль поддержки таких сайтов.
И кстати как показывает практика — заказчику не объяснишь что «у вас сайт плохо сделан, поэтому мы час меняли баннер.А это — уже другая история. Не пытайтесь решать мировых пробелем и будет вам счастье. Нормальные заказчики либо примут тот факт, что у них на сайте картинка меняется час, либо найдут кого-то, кто поменяет им всё за пять минут — но угробит им базу. Пройдя пару «кругов ада» (с потерей данных и клиентов) заказчик к вам ещё вернётся… или не вернётся, а разорится — вам-то какая разница?
Им плевать как крив сделан сайт. Для них заменить картинку это работа на 5 минут.и платить вместо этого за час они не хотят. В этом то и вся соль поддержки таких сайтов.«Вся соль» заключается не в заказчиках, а в исполнителях, которые не находят в себе силы отказаться от заказа, который, совершенно очевидно, убыточен. Ну так и менять нужно не заказчика, а ваш собственный подход к делу.
И да, процесс обучения заказчиков — он не одномоментный, он растянут во времени.
Про непрерывные релизы не в курсе?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программисты не понимают