Comments 14
Спасибо за статью, прям хорошо!
Вот и получается такая ситуация, что чем больше всего мы делаем, чтобы заработать денег, тем больше денег нам надо на то, чтобы это поддерживать.
Вот это прям интересное замечание, да. По сути есть вопрос "сколько это будет стоить, и сможем ли мы продать это с прибылью?"
А еще на это должна быть завязаны стратегия продукта (сервиса) внутри компании. Например: "Мы будем продавать дешево, поэтому продукт должен обойтись дешево", "Наш план - стать Гуглом, поэтому мы будем проедать инвесторские деньги и набирать аудиторию" и пр. Только вот стратегии продукта, увы, обычно нет (или она написана, но на неё никто не смотрит); стратегия часто сводится к "берем больше, кидаем дальше" - т.е. пилим фичи и пытаемся продавать, пока нам дают бюджет.
А если это разработка компании только для себя, не для продажи?
Имхо опять же вопрос стратегии - т.е. что мы делаем за продукт, и зачем стратегически.
Я как раз делаю программы для компании, где работаю, потому что эти программы нужны. Например, открыла компания новое направление разработки и производства интеллектуальных датчиков, но оказывается чтобы его поддерживать нужны программы для технологического процесса линеаризации, поверки, тестирования и ремонта датчиков и тд. А у компании главный ресурс автоматизации это excell. В своей статье на хабре я как раз описываю создание одной из таких систем.
А если это разработка компании только для себя, не для продажи?
Тут стоит учитывать вопрос денег. Даже если это разработка внутреннего продукта, то она также оплачивается из бюджета компании. И такой продукт также будет иметь свои требования со стороны бизнеса.
А если бизнес, в своих требованиях, не учитывает или считает доработку качества ПО лишним, то с точки зрения описанного в статье, внутренний продукт не будет отличаться от клиентского.
Все упирается в цели бизнеса и в количество времени/средств, которые он готов вложить в разработку.
Дополню.
По ресурсам. Можно нагружать серверную часть задачами, а можно и клиентские компы, как делают в вебе очень многие, когда на одной странице видишь и backbone и react и angular с vue и jquery вперемежку.. :(
По стоимости продукта: сравните 2 фразы:
а) "Мы создали продукт за 100500 мильонов долларов всего за полгода"
б) "Мы создали небольшой и шустрый, малотребовательный продукт за 500 долларов всего за год"
Какой из них привлекательнее для условного "покупателя" при одинаковой цене доступа? маркетинг .. ничего лишнего. ;)
"Мы создали продукт за 100500 мильонов долларов всего за полгода"
Но если люди уже покупают продукт за 100500 мильонов долларов зачем продавать свой продукт за 500.
А если мы можем продать продукт за 100500, зачем стараться делать его себестоимость 500? Точно ли маржа покроет альтернативные издержки?
Есть SQLite который протестирован так как корпорациям и не снилось, есть Tex, который тоже Кнутом написан а не корпорацией. Там с качеством все в порядке. Просто когда пишут специалисты а не аникейщики все получается :)
SQLite - первый релиз в 2000г, последняя версия 2024г
ТеХ первый релиз в 1978г, последняя 2021г
К сожалению не знаю всю историю версий, но сомневаюсь, что за столько времени разрабатывались только фичи без багфиксов и оптимизации, а также что за столько времени все возможные баги были отловлены и пофикшены до попадания в очередной релиз. В целом, подобный срок достаточный для обширного сбора обратной связи и её обработки.
История с open source приложениями это история энтузиастов. В статье я писал о том, что есть люди, готовые потратить своё личное время на повышение качества разрабатываемого в рамках своей работы ПО, такие люди редкость и примерно такие же и занимаются разработкой подобных продуктов.
Также в open source специалист, как правило, не так ограничен в сроках, ведь над ним не стоит руководство, тыкающее его лицом в дату очередного релиза с набором требований, которые к этой дате в этом ПО должны быть.
Да, раньше финансовая поддержка не была такой концентрированной, как сегодня. Но тем не менее не паразитировали на постоянных обновлениях, пытались осуществить и осуществляли продукт.
Дело в том что сегодня не требуется столько денег, сил и затрат на столь простые вроде бы программы. Это опыт всего IT.
Но как видим стали воспитывать новых пользователей, которые стерпят все.
Какие ужасы творятся в интерфейсах современных приложений. Работает и ладно? И вот за это должен платить?
мой опыт работы подсказывает к сожалению полную пелевинщину во всех отраслях - как 15 лет назад за интеллектуальные счётчики электроэнергии по одному и тому же ТЗ счёт выставляли от 1000$ до 100000$ за опытный образец, так и в настоящем времени вижу проекты которые компания из 30 человек пилит 2 года, в то время как я один более сложные вещи делаю за 6-8 месяцев при лучшем качестве кода и удобстве обслуживания. сейчас тенденция в разработке к сожалению от технической стороны уходит в коммерческую, когда заказчику нужно впарить решения которые ему не нужны, просто для увеличения размера команды и сложности проекта, чтобы сесть на % от зарплаты и ехать на дорогих заказчиках в светлое финансовое будущее. о качестве кода тут вобще речи нет потому что другие задачи у людей - не в технической плоскости. я как программист с опытом своего бизнеса понимаю как много бизнес переплачивает за оверинжениринг - при этом получая крайне низкое качество кода. как с любыми системами, когда в дело вступают большие деньги качество имеет тенденцию снижаться. "парадокс плохих автомобилей" из экономики приходит в программирование, и приходится долго искать компанию где не нужно будет бороться против менеджмента за качество
Кажется корень проблемы в том, что потребителям ПО (и не только ПО), стало плевать на качество, кто-то просто не понимает разницы, кто-то привык что всё лагает и забагано. Решать все эти проблемы можно было бы хорошим отделом QA, который проводил бы качественное функциональное и нагрузочное тестирование (косвенно это увеличивало бы и внутреннее качество кода), но кажется таких отделов QA не существует или очень мало.
Частенько в работе с современным ПО наталкиваюсь на баги, которые можно было воспроизвести просто запустив это ПО и потыкать пару кнопок, как специалисты QA эти баги пропускают мне не понятно.
О качестве ПО и почему оно такое. Взгляд на проблемы бизнеса с точки зрения технического специалиста