Программисты, кажется, забыли реальную цель программного обеспечения — это решать реальные проблемы.
50 лет назад, в 1968 году, была организована рабочая конференция по программной инженерии, которая была организованна при поддержке «Научного Комитета НАТО». В то время люди начали замечать, что программное обеспечение становится фундаментальной частью общества. Однако это также становилось слишком трудным для понимания. После этой конференции программирование стало целой индустрией. И оно начало отходить от контролирования деловых людей.
Независимо от того, каким путем программирование пошло с тех пор, по-прежнему существует проблема с разделением между бизнесом и разработкой программного обеспечения — или «ИНЖИНИРИНГ», как впервые назвала конференция. Если разработчики слишком сосредоточены на разработке, они могут пропустить цель программного обеспечения, которое они пишут. Они могут не видеть скрытых решений, которые не требуют никакого кода.
Вот пример.
Был стартап, который создавал устройство позволяющее человеку открывать дверь своего дома по Bluetooth. В качестве визуального интерфейса использовался виджет, который был виден даже когда телефон был заблокирован. У него была единственная кнопка под названием «Открыть дверь».
Когда пользователь подходил ближе к дому, он брал телефон, находил виджет и затем нажимал кнопку, чтобы открыть дверь.
Кто-то посмотрел на это и спросил:
Если мы используем Bluetooth и наша бизнес-модель пускает в дом любого, кто имеет телефон, почему мы должны заставлять кого-то брать телефон и нажимать на кнопку? Пусть дверь будет открываться при приближении устройства на 1 метр. Таким образом, нам не нужно платить за разработку и программирование визуального интерфейса!Эта история с Bluetooth — отличный пример узкой направленности: цель состояла в том, чтобы открыть дверь с минимальными усилиями. Нет смысла разрабатывать визуальный интерфейс, если датчики беспроводные.
Если вы знаете, каких целей хочет достичь бизнес и что имеет ценность для пользователя, то вы можете объединить эти знания с вашими знаниями о технологиях. Только тогда вы будете располагать достаточной информации, чтобы придумать лучшие ответы, и сделать вывод, что для продукта интерфейс не нужен.
Это отличный пример того, как решить техническую проблему без необходимости писать какой-либо дополнительный код, кроме кода для разблокировки. Однако, как и в случае с «Техническим долгом», ничто не должно служить оправданием для написания дерьмового кода.
Не каждый код стоит писатьИногда исправление серьезной ошибки не может быть приоритетом. Если у вас криптобиржа и в системе один и тот же платеж провелся дважды, вмешательство человека может быть лучшим решением с точки зрения затрат и выгод, если стоимость решения этой проблемы высокая.
Этот компромисс между Серьезностью и Приоритетом напоминает мне модель, которую недавно показал мне коллега. Она называется «Матрица приоритетов», двумерная модель, которая может быть использована для определения приоритетов ошибок в зависимости от количества пользователей, на которых они влияют, и серьезности.
Описанная выше проблема с повторным внесением депозита попадает в категорию неудобств, затрагивающих одного пользователя. Поэтому приоритет 3.
Не каждый баг стоит исправлятьЭто очень распространенная вещь, когда разработчики пытаются написать скрипт для всего. Однако некоторые повторяющиеся задачи не стоит, чтобы их автоматизировали. Вам не нужно тратить время на программирование скриптов, если вы собираетесь скрыть необходимые знания о том, как работает основная команда.
Существует разница между инкапсуляцией сложной логики и абстракцией полезных знаний. Иногда информация должна быть сделана понятной. Если вы абстрагируете их, они могут иметь противоположный эффект и их будет труднее понять.
Более полезно использовать некоторые типы команд низкого уровня в CLI, чем команду высокого уровня, которая абстрагирует знания, такие как Git.
Несколько лет назад я работал над проектом с использованием пошаговой доставки. Это была система проверки личности, которая требовала от пользователя предоставить некоторые личные данные для проверки сторонним поставщиком.
Это была особенная функция проверки полей, которую команда хотела создать. Тем не менее, история проверки была расставлена ??по приоритетам при планировании каждого спринта, поскольку крайний срок становился все ближе и ближе. В конце концов, команда выяснила, что не было никакого смысла в том, чтобы причудливая валидация вообще существовала.
И вот почему: проверка была обязательной!
В интересах пользователя предоставить достоверную информацию. Если пользователь предоставит неверные данные, они не будут проверены и у них не будет возможности использовать систему. Кроме того, большинство браузеров поддерживали стандартную проверку HTML, которая была достаточно хорошей.
В худшем случае пользователи, которые не смогли проверить себя, могли позвонить в службу поддержки, чтобы проверить все вручную.
Не каждую функцию стоит программироватьЕсли вы разработчик и вы понимаете проблему, которую вы пытаетесь решить, вы сможете придумать более качественный код, а иногда и сможете справиться вовсе без кода. Вы не "Code Monkey", которому платят за написание символов на экране. Вы профессионал, которому платят за решение проблем.
Однако, если вы попытаетесь решить все проблемы при помощи технологий, без каких-либо размышлений, у вас возникнут проблемы с пониманием того, что представляет ценность для клиента, и для придумывания отличных идей.
Ваша цель и цель написанного вами кода состоит в том, чтобы создать ценность и сделать существующий мир лучше, а не удовлетворять ваш эгоцентрический взгляд на то, каким должен быть мир.
Есть такая поговорка: «Если у вас есть только молоток, все выглядит как гвоздь».
Лучше сначала иметь гвоздь, чтобы вы смогли рассмотреть необходимость молотка.
То есть если вам нужен гвоздь в первую очередь.
Спасибо за прочитанную статью!
Если у меня есть ошибки в переводе, пожулуйста напишите об этом в комментариях!
А также зайдите на мой сайт, где появился быстрый доступ к вопросом и ответам по javascript — Вопросы и ответы по JavaScript
Буду очень вам благодарен и признателен)
Я в твиттере и вк
Спасибо большое за ваше внимание!
Комментарии (52)
dss_kalika
02.09.2019 14:38+1Так и рождаются странные вещи, которыми нельзя удалённо открыть дверь, а необходимо именно самому подойти. т.е. открыть кому то дверь не вскакивая каждый раз — будет тем ещё приключением )
FDA847
02.09.2019 14:54+2Да, решение очень странное. За дверью нужен чёткий контроль в плане открытия.
timfcsm
02.09.2019 15:25+1плюс постоянные открывания двери когда просто проходишь мимо неё… решение не то что странное, а идиотское и вредное
batyrmastyr
02.09.2019 16:06+1Всё становится веселее, если оставить телефон у входной двери ))
Rapprogtrain Автор
02.09.2019 16:18Ахах, а если телефон дома забыл?)))
Akon32
02.09.2019 17:16Странные вещи рождаются от непроработки всех вариантов использования и "бездумной" реализации всех фич, которые где-то видел менеджер или разработчик. А если в процессе разработки есть фильтр на "странные/ненужные фичи" и отдел тестирования, странных вещей на выходе уже должно получаться меньше.
Те же постоянные автоматические открывания/закрывания двери возможны, скорее всего, тогда, когда кому-то автоматическое открывание показалось отличной идеей, но он не подумал, что можно ходить не только сквозь дверь, но и рядом с дверью. Но этот вариант может быть лучше, чем постоянный виджет на экране блокировки смартфона (зачем он, когда пользователь далеко от двери?). Тут надо много думать, прежде чем делать (собственно, вся статья про это).dss_kalika
02.09.2019 17:25+1Виджет нужен если вы хотите кого то впустить-выпустить.
А вариант с автоматически открывающейся дверью было бы интересно отработать на предмет проверки направления движения человека — можно определять угол движения и траекторию.
Насчёт думать и делать… это всё прекрасно, конечно, но, чаще всего просто фантазии.
Для этого должны быть специальные люди (аналитики?) которые должны понимать пользователя, собирать данные и формулировать задания программистам и инженерам в таком виде, в котором они должны быть сделаны. Потому что требовать от программиста ещё и изучать предметную область, определять пользовательские пути и специфику их работы и мировоззрений — это требовать его выполнять не его обязанности, очевидно.
Более того, когда «видиние» программиста входит в конфликт с тем, как это видит начальство или его же аналитик… не избежать беды. =)Akon32
02.09.2019 17:42Для этого должны быть специальные люди (аналитики?) которые должны понимать пользователя, собирать данные и формулировать задания программистам и инженерам в таком виде, в котором они должны быть сделаны.
Наверно, статья больше рассчитана на людей, которые формулируют задания (и, возможно, сами их исполняют), а не на тех, что пишет код по уже сформулированным заданиям.
dss_kalika
03.09.2019 10:20ну так о том и речь.
Это функции разных ролей в команде.
И если они совмещаются в одном человеке, то это или очень маленькая команда, или что то пошло не так (руководство решило поэкономить).
noodles
02.09.2019 23:16Для этого должны быть специальные люди (аналитики?)
Возможно, продуктовые дизайнеры.
greg123
04.09.2019 14:51А вариант с автоматически открывающейся дверью было бы интересно отработать на предмет проверки направления движения человека — можно определять угол движения и траекторию.
А теперь смотрите прикол — в попытке избавиться от разработки виджета вы приходите к тому, что нужно усложнить и поддерживать код, который будет анализировать необходимость открытия двери. И этот код можно не усложнять и не писать, если создать… виджет, где пользователь сам нажмет на кнопку, если захочет открыть дверь. Вот такой вот прикол.
onground
03.09.2019 14:18Про самооткрывающуюся гостеприимную дверь я читал в одной детской книжке:
Frank Cottrell Boyce «Chitty Chitty Bang Bang Flies Again»But that afternoon, as Mum trudged up the garden path after a hard day’s work at Unbeatable Motoring Bargains, a very refreshing thing happened. The front door opened all by itself, and a bright little voice said, “Do come in. The kettle is on.”
“What a lovely homecoming,” said Mum, strolling into the kitchen just as the kettle came to the boil.
“I installed an automatic self-opening on the front door,” explained Dad, “and hooked it up to the kettle.”
“My genius.” Mum smiled.
“The word today,” said Dad, “is welcome home.”maxzh83
02.09.2019 14:56+5Это менеджерское мнение и оно в стратегическом смысле справедливое. То есть в перспективе, если программисты постоянно занимаются тем, что никому не нужно, то это повредит всем, в том числе, опосредованно и самим программистам.
А есть другое мнение. Есть программист, ему платят зп за 8 часов работы, он наемный работник и его судьба проекта (особенно большого) интересует не слишком сильно. Ему же интересно попробовать новые технологии, порешать сложные задачи (даже если не просят), прокачать скиллы для резюме. А дальше, если с проектом все пойдет плохо, он плюнет, уволится и будет технически готов к новой работе. Это выглядит цинично, менеджерам это не нравится и они пишут подобные статьи.
Kanut
02.09.2019 15:16+1А что мешает совмещать одно с другим? Ну вот скажем вы программист и отработав свои 8 часов вы уходите домой. Пока вы на фирме вы пробуете новые технологии и решаете сложные задачи. Но если к вам приходят с юзер стори/техзаданием, то вы можете попытаться прокачать скилл «определение адекватности техзадания и нахождения более оптимальных вариантов решений». Ну или что-то в этом роде ;)
П.С. И на мой взгляд такой скилл очень даже полезен на рынке труда и вполне себе пригодится в профессиональной карьере. И мне кажется вся статья как раз об этом.
П.П.С. И я бы даже сказал что в как минимум в некоторых областях ИТ именно этот скил необходим чтобы стать сениором или техлидом.maxzh83
02.09.2019 15:33А что мешает совмещать одно с другим?
Видимо, склад мышления. Не даром есть разделение на программистов, аналитиков и менеджеров. Хотя, иногда, программист может решать и аналитические и менеджерские задачи, но это скорее исключение.Kanut
02.09.2019 15:38Ну я бы не сказал что такое как-то обязательно противоречит складу мышления программиста.
Но да, в чём-то вы правы и тогда я бы сказал что «сениор/техлид» из моего поста выше это комбинация «программист-аналитик». А «программист-менеджер» это уже какой-нибудь тимлид :)
P.S.Но останусь при своём: если вы можете такие навыки прокачать, то оно пожалуй того стоит и в жизни/профессии пригодится.maxzh83
02.09.2019 15:45Но останусь при своём: если вы можете такие навыки прокачать, то оно пожалуй того стоит и в жизни/профессии пригодится.
Я с этим и не спорил. Да и со статьей несильно спорю, просто показал другую точку зрения, которая очень распространена в последнее время.Kanut
02.09.2019 16:10Да она всегда была распространена. И я бы даже сказал что раньше её придерживалось гораздо больше айтишников чем сейчас. Ну как минимум в процентном соотношении уж точно.
И ты не перестаёшь быть хорошим айтишником если ты этого всего не делаешь. Просто вопрос ещё одного дополнительного «техно-софт-скилла» :)
0xd34df00d
02.09.2019 18:11Но если к вам приходят с юзер стори/техзаданием, то вы можете попытаться прокачать скилл «определение адекватности техзадания и нахождения более оптимальных вариантов решений»
Просто это неинтересный мне скилл. Я лучше попрокачиваю навыки в темплейтах или в хаскеле.
Akon32
02.09.2019 17:36Есть программист, ему платят зп за 8 часов работы, он наемный работник и его судьба проекта (особенно большого) интересует не слишком сильно.
Иногда людей, пишущих код,
презрительноразделяют на кодеров и программистов. В этой "классификации", ваш программист — это кодер.
А есть и другой путь — заниматься не написанием фич, а созданием программного продукта. Не просто множества разных функций, а упорядоченной, гибкой и логичной системы, позволяющей пользователям решать даже такие задачи, о которых создатели системы не подозревали. Узкие примеры таких систем — word, excel (по принципу "чего в них только не пишут"). Ещё примеры — СУБД, файловые системы, различные редакторы и т.д.
maxzh83
02.09.2019 17:47+1В этой «классификации», ваш программист — это кодер.
Во-первых, нет, не обязательно кодер. Во-вторых, при чем тут это деление, для красного словца? Ну хорошо, подставьте кодера туда, если нравится. Ситуация-то не изменится, есть кодер, ему платят зп за работу, ему пофиг на судьбу проекта и т.д.
А есть и другой путь
Ваш пример требует архитектора или команды архитекторов, в статье про это ни слова, это другой кейс.
Akon32
02.09.2019 18:54при чем тут это деление
Мне показалось, вы описали позицию "делаю строго то, что скажут", и у меня возникли ассоциации с таким делением. Имхо, эта позиция — совсем не самое интересное, что может быть в профессии программиста.
vvadzim
02.09.2019 14:58+4— Что за ревью?! Какие тесты?! Тут работы на два дня на всю систему! Просто сделайте!
...(некоторое время)…
— Ты же сам это написал! Всё работало! Неделю простейший баг исправить не можешь! Я тебе за что деньги плачу?! Что значит ты уходишь?!!!
...(некоторое время)…
— Вот тут у нас уже всё написано… Немного доработать… Как переписать?! Я столько денег ввалил!
А вообще всё правильно. Но очень часто принцип, вынесенный в заголовок, «используется» «менеджерами» из монолога выше.
Alexey2005
02.09.2019 15:17+4Очень часто, а в мире OpenSource так в большинстве случаев, код пишется не потому, что хотят решить какую-то проблему, а потому, что нравится писать код. Т.е. людей интересует не цель, которой часто может и не быть, а сам процесс.
Вот возьмём в качестве примера такой крупный OpenSource проект, как radare2. Это кроссплатформенный фреймворк для анализа и реверсинжениринга кода, который иногда даже осмеливаются назвать свободным аналогом IDA. Но вся его крутость разбивается о тот маленький фактик, что r2 не позволяет загружать ранее созданные проекты. Ну то есть вы можете загрузить бинарник, провести анализ, расставить комментарии, обозвать переменные и структуры, даже провести частичную декомпиляцию в псевдокод. Вот только при повторной загрузке всё это потеряется, потому что загружать проекты r2 пока не умеет.
В итоге софт, над которыми работали многие сотни людей, пригоден разве только для примитивных крекмисов. И знаете что? Никого из разработчиков это не волнует, потому что у них нет цели создать рабочий продукт. Они занимаются ровно теми вещами, над которыми им интересно работать, пишут новые фичи, добавляют поддержку новых архитектур. В общем, получают кайф от процесса кодирования. А результат? Да кому он вообще нужен.
К счастью, когда подобные проекты в достаточной мере обрастают более-менее рабочими фичами, на них могут обратить внимание крупные корпорации. Вот например достал всех Autodesk совершенно неадекватной работой с крупными клиентами, и корпорации подбросили бабла в Blender. После чего вместо насквозь глючного кошмара, в котором даже union двух кубов булился с дырами, образовался вполне себе пригодный к использованию продукт.
Именно для того в разработке и нужны менеджеры — чтобы ставить чёткие цели и контролировать их достижение вне зависимости от того, нравится это кодерам или нет.Anrock
02.09.2019 17:23Проекты radare вроде умеет с 2017 http://radare.today/posts/project-files/. Или вы имели в виду что-то другое?
Alexey2005
02.09.2019 17:57Это только заявлено, что умеет. А вы попробуйте:
r2 some_binary_file aaa Ps proj_name q
и потом загрузить этот проект через Po или командную строку. Сохранение проектов реализовано, загрузка — нет.
KvanTTT
03.09.2019 00:17Нужны менеджеры, которым нравится Open Source :)
Гитхаб в последнее время активно внедряет поддержку спонсорства. Уже можно спонсорить как проекты, так и самих пользователей. Может это больше их больше стимулирует пилить нужные фичи.
nobodyhave
02.09.2019 17:29+3Рекомендую почитать «Психбольница в руках пациентов».
Если кратко, то все программисты, согласно автору (вроде тоже бывшему программисту), являются особым подклассом людей, которые не умеют проектировать, но умеют писать код. И их и близко нельзя подпускать к проектированию, иначе все равно получится дурно пахнущая субстанция. Для проектирования нужны специально обученные люди.
Задача же программиста определить, насколько предлагаемое решение является осуществимым технически и сколько по времени и ресурсам займет реализация. Ну и написать код. Все.
P.S. А дверной замок, открывающийся при приближении телефона не купил бы никогда. Слишком непредсказуемая система.
pyrk2142
02.09.2019 20:36+1Есть довольно интересный взгляд немного с другой стороны: программисты и менеджеры, которые непосредственно руководят разработкой, обычно не очень тупые. И они понимают, что им платят за процесс разработки, а завершение разработки приведёт к массовым сокращениям, когда на поддержке останется пара человек. Поэтому надо сесть и продолжать кодить, выдавая тысячи обновлений и новые проекты, получая при этом зарплату. Так появляются безумные приложения для замков (!), почта, которая тормозит на современном ноутбуке, приложение мобильного оператора, которое требует максимальную версию IOS и посылает остальных, и пиццерия, которая нанимает десятки разработчиков и аналитиков, чтобы стабильно возить невкусную пиццу.
Отдельный вопрос в том, что в куче компаний разработчик получит больше бонусов (внутренняя известность, продвижение в должности, премии) если проект, который он писал и продвигал, провалится или будет просто закрыт с гигантским убытком, чем если бы этого проекта не было. Привет, Гугл, ваши методы повышения в должности шикарны.Kanut
02.09.2019 21:25И они понимают, что им платят за процесс разработки, а завершение разработки приведёт к массовым сокращениям, когда на поддержке останется пара человек. Поэтому надо сесть и продолжать кодить, выдавая тысячи обновлений и новые проекты, получая при этом зарплату.
Извините, но во первых это на мой взгляд обыкновенный саботаж и не то чтобы особо моральное поведение.
Во вторых среди начальства тоже далеко не все идиоты и рано или поздно такое раскроется. И опять же есть хороший шанс получить определённую репутацию от которой уже будет не избавиться.
В третьих я слабо могу себе представить как может «завершиться разработка» большинства известных мне систем и продуктов. Практически всегда пользователи, бизнес и окружающий мир «придумывают» что ещё можно добавить в продукт или как его изменить.
Ну и напоследок лично я вообще ничего не имею против если продукт доходит до какого-то уровня развития, когда лично мне в нём больше нет места. Значит уволюсь(а ещё лучше пусть меня уволят) и найду новую работу по нраву. Причём скорее всего ещё и с большей зарплатой.maxzh83
02.09.2019 23:46бизнес и окружающий мир «придумывают» что ещё можно добавить в продукт или как его изменить
Бизнес и окружающий мир — это часто и есть те люди, которые не заинтересованы в том, чтобы проект закончился. И они не хотят, в отличие от вас, увольняться и искать новую работу по нраву.Kanut
03.09.2019 07:44Я скорее имел ввиду «хозяев фирмы» и «мир за пределами фирмы». И если не хотчт чтобы проект заканчивался и платят за это, то тут у меня вообще никаких проблем нет.
maxzh83
03.09.2019 10:24На стороне заказчика тоже есть люди, которые вели проект, довели до рабочего состояния, но как и с ремонтом — невозможно завершить, всегда можно придумать что-то еще.
Kanut
03.09.2019 10:51С этим я не спорю. И я ничего не имею против того чтобы проекты развивались и продолжались. Я против того чтобы разработчики сами «создавали» себе ненужную работу просто из боязни быть уволенными,
П.С. И ненужная работа это именно ненужная, а не какой-нибудь действительно полезный рефакторинг или технологичеслий апгрэйд.
BOM
02.09.2019 20:41+1The first prerequisite you need to fulfill before beginning construction is a clear statement of the problem that the system is supposed to solve.
© Code complete, Steve McConnell
Программисты, кажется, забыли реальную цель программного обеспечения — это решать реальные проблемы.
Программисты ничего не забыли. Просто существует очень сильная корреляция между хорошим кодом, лучшим практикам, современным технологиям, продуманным решениям с одной стороны и качеством ПО, стабильностью работы, стоимостью разработки и поддержки с другой. И если аналитик, менеджер, либо кто-то еще этого не понимает, то, вполне возможно, проблемным звеном в цепи разработки являются не программисты.
Программисты осознают, что их первостепенная задача решить проблему. Вот только проблема не бывает в отрыве от контекста. У проблемы есть некий бекграунд, у проблемы есть причина, у проблемы может быть классификация. А еще иногда проблема на самом деле не является проблемой, а это просто наша собственная интерпретация ее как проблемы.
arthuriantech
02.09.2019 23:11Есть такая поговорка: «Если у вас есть только молоток, все выглядит как гвоздь».
И все же забитый молотком шуруп держится куда лучше, чем завернутый отверткой гвоздь.
flancer
03.09.2019 06:38+1Проблема, которую вы решаете, важнее, чем код, который вы пишете
Программисты не решают проблемы. Программисты пишут код. А те, кто решают проблемы, сами код не пишут. Если для решения проблемы им нужен код, они зовут программистов для написания кода. И почему-то думают, что программисты решают их проблему. Господи, да мы в большинстве случаев только от вас и узнаём, что проблема существует! Хотите открывать дверь по кнопке — нате вам кнопку, хотите по GPS — нате вам GPS. Вы сами не знаете, чего хотите, и вам просто нужно с кем-то об этом поговорить? ОК, давайте устроим совещание.
Kanut
03.09.2019 07:45+1А те, кто решают проблемы, сами код не пишут.
Очень глобальное заявление и на мой взгляд даже если это и правило, то у него есть огромное количество исключений :)flancer
03.09.2019 08:57Согласен, получилось немножко совоглобусно :) Я заявлял это в рамках условий, постулируемых заголовком публикации. Ведь если вы решаете какую-то проблему путём написания кода, то код становится даже важнее самой проблемы, т.к. код является её решением.
muhaa
03.09.2019 10:50Проблема, которую вы решаете, важнее, чем код, который вы пишете
Одни разработчики не могут сделать и шага, пока не видят всю задачу создаваемого продукта в целом, других разработчиков интересуют только текущие четко поставленные задачи и технологии их решения и ничего другого они не желают знать. ИМХО, коллективы состоящие из первых всегда эффективнее, если разве что, речь не идет о том, чтобы шлепать похожие проекты на конвейере.
Gokudera
03.09.2019 16:11Вот вообще ни разу не согласен, какая-то однобокая статья.
Программисты, кажется, забыли реальную цель программного обеспечения — это решать реальные проблемы.
КМК, тот же Spring Framework код ради кода, но при этом упрощает решение бизнесовых задач.
Про виджет вам выше вполне обоснованно написали когда он удобен, возможно из-за его отсутствия стартап и накрылся?
Однако, как и в случае с «Техническим долгом», ничто не должно служить оправданием для написания дерьмового кода.
Не каждый код стоит писать
На сколько правильно я понял посыл, зачем писать ___, которое займет 3 часа если в нужном месте можно добавить костыль за 5 минут. Так и рождается тех долг.
Если у вас криптобиржа и в системе один и тот же платеж провелся дважды
Не каждый баг стоит исправлять
поставьте себя на место клиента, а если еще и сопровождается фин издержками со стороны клиента?
то что произошло 1н раз може повториться в будущем неоднократно, тогда и баг придется править и людям разгребать.
amarao
… не каждый продукт следует разрабатывать. /закопали.
Rapprogtrain Автор
извините, не понял
amarao
Если не каждую функцию стоит программировать и не каждый баг фиксить, то и не каждый продукт стоит разрабатывать.
Вот придумали PM'ы новый суперметод на аукционе продавать рекламу по приватным данным фейсбука.
Стоит такой продукт делать? Вот, допустим, программисту, который любит код писать чисто и хорошо, да и в целом, человек этичный. А его PM считает, что надо делать всё, за что деньги платят.