Как стать автором
Обновить

Комментарии 12

Хммм…
Есть продукт, который делают разработчики, исходя из собственноручно сформулированных требований. Есть продукт, который делают разработчики(возможно те же самые), исходя из требований, сформулированных заказчиком.
С чего вдруг одно будет разительно отличаться от другого? Непонятно…

P.S. Ну и если продолжить аналогию, то самым верным решением будет не пицца на вынос и не ресторан, а свой собственный повар, знающий все вкусы и привычки(всю внутренюю кухню, хе-хе).
Тут чаще всего создаётся продукт исходя из финансовой составляющей и окупаемости: разработать коробку стоит столько же, сколько продукт для клиента и если делать хорошо, то и продавать нужно дорого. Но такое вряд ли возьмут, поэтому при минимуме затрат разработчикам нужно получить продукт, который можно продать и заработать. Средняя цена на рынке подписки — от 5000 в месяц, а покупки кода — около 300 000. Вот и считайте сколько ещё на рекламу нужно и насколько это выгодно, если делать хорошо.
Хммм… То есть достаточно продать 60 коробок(или месячных подписок на решение), чтобы за окупилась разработка коробки, сделанная с качеством аналогичным индивидуальному решению под заказчика? Звучит, как хороший план. И не забывайте про сопутствующий сервис: настройка под заказчика(ведь коробка — это не неизменный монолит, она тоже может изменяться под заказчика), консультации, вот это вот всё.
Про рекламу не соглашусь. Реклама направленная на поиск штучного дорогого заказа потребует больше бюджета, чем реклама массового дешевого тиражного решения(при одинаковой отдаче от рекламы).
Если вы заказываете разработку с нуля у проверенных и зарекомендовавших себя разработчиков, можете быть уверены в двух вещах:
Этот код легко масштабируется, меняется, поддерживается и дополняется не только теми, кто его писал, но и любыми другими разработчиками.

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


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

Команда коробки, как тут уже было отмечено, ориентируется на какой-то усредненный набор ими самими придуманных требований. И попытка натянуть их сову на ваш персональный глобус поначалу может быть даже успешной. Но с ростом глобуса и/или изменением его формы сова начинает трещать по швам. И чинить ее вам придется (если она в проде), скотчем и степлером. В конечном итоге скотча там будет больше чем самой совы.

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

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

Это все решается за деньги. Но я не говорил, что коробка хорошо. И даже не спорил с тем, что заказная разработка даст продукт гораздо более кастомизированный, чем коробка. Я опровергал то, что заказная разработка даст более поддерживаемый и качественно написанный продукт, потому что она просто не заинтересована это делать, ибо оперирует деньгочасами =) И мой опыт работы с заказной разработкой с обеих сторон это подтверждает =)


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


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

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

Вот такой пример. Один (хотя их на самом деле можно выкатить вагон и маленькую тележку). Есть у нас документ, который называется «Нефункциональные требования к функционалу на платформе IBMi». В нем очень много чего написано. Для примера, вот такой пункт:

Использование MERGE для больших объёмов данных запрещено. На время выполнения создаются блокировки записей в количестве кратном выполненным изменениям, что при большом их объёме приводит к замедлению работы сервера.


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

И, повторюсь, таких требований у нас не одна страница. И все они «выстраданы». Есть целый пул «задач на оптимизацию» где переписывается исправно работающий код просто потому что он неэффективен и оказывает существенное влияние на загрузку и общую производительность системы в целом. Вот как это можно делать в случае «коробочных решений»? И кто этим должен заниматься? Коробочники? А оно им надо? Они свое уже получили с продажи коробки.
Заложником можно стать, только если думать, что везде так. Во-первых, уже на начальном этапе видно, как работает фирма. Например, проектирование — это очень показательный этап. И если тут вас не слышат, некомфортно работать по таймингу или общению, то заканчивайте работу и идите на следующий этап к другим. Ну и от цены нужно отталкиваться. Нет смысла ждать крутого сервиса и качественного продукта от команды за три копейки. Им же тоже кушать нужно, а если дёшево, значит много набирают проектов и нет возможности делать хорошо. Но согласна, что и у дорогих команд есть большие проблемы с менеджментом. Мы с этим сталкивались, поэтому есть мысль написать о специфике поиска подрядчиков.
Поэтому, если человек при возникновении любой задачи упорно… у меня для вас плохие новости — вам достался тупой программист.

Все это верно но для тупых бизнес-систем. Если IQ выше 90 не тратьте свою жизнь на это, если есть выбор. Все эти «достаточно неглупые люди» на самом деле самодуры c мнением, глубоким и обоснованным, как у чат-бота.
Закалив свой ум в битве с серьезными задачи человек редко генерирует всякие глупости.

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

Этот код написан специально под ваш бизнес

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


Вы сами в это верите? код будет написан под ваш бизнес, но вероятность того что он будет ЛЕГКО масштабироваться и меняться близка к нулю.
Писать код так что бы он легко менялся и масштабировался надо уметь, дело не в том что бы писать под бизнес, дело в том что бы уметь так писать и не лениться так делать.
Сколько живу — ни разу не видел. У Яндексов спросите сколько раз они переписывали свои приложения и сколько там легаси, кода унаследованного и в котором ни кто ни когда не будет разбираться, который при необходимости — заменят другим, но ни когда не будет в нём разбираться.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории