Дохуя зарабатывают, хвалятся своими сверхспособностями в освоении Кнута за три дня, а банально написать не тормозящий код уже не могут. Те сайты что успешно работали десяток лет назад на мобильнике с 256 мегабайт оперативки - уже не работают. И нехуй оправдываться фантазиями про технологии. Просто вы не умеете ничего без ваших фреймворков. А фреймворк заточен не на скорость, а на слив бигдаты.
В бассейн сливается бигдата по одной трубе и, одновременно, выливается бигдата по другой. Объем слива бигдаты в бассейн в два раза больше объема слива бигдаты из бассейна. Сколько автору поста лет?
ЗЫ. Сайты разрабатывают по техническому заданию (ТЗ). Если не по ТЗ - программистов бьют. Если в ТЗ оптимизация быстродействия не прописана, то важны только стоимость и длительность работ. Идите и огорчайте заказчиков, чтобы в ТЗ писали больше про оптимизацию быстродействия. Хватит заставлять погромистов делать не по ТЗ. Это как каменщиков ругать, что потолки низкие.
Если серьезно, то ничего нельзя сделать. Если вы продолжаете жить в цифровом мире, вы подвержены цифровой диктатуре. Государственной или корпоративной, мировой или отечественной.
Можно в некоторой степени искажать, прятаться, но только до тех пор, пока вы или люди похожие на вас диктатуре не интересны. Будет интерес - найдется алгоритм, подсистема, выборка, метаданные метаданных и пр., чтобы все посчитать и учесть. Это наша новая норма и ничем ее не прокрутить на 30-40 лет назад, чтобы попробовать по-другому.
не важно с какой скоростью тебе вываливается поток цифровой информации, слабое место в том что опреативно-розыскные мероприятия пока еще ведут люди, которым надо задать правильные вопросы системе, получить ответ за миллисекунду, а затем сообразить, что сделать с ответом и таки физически прореагировать, то бишь подорвать жопу со стула. Пока что за тобой не отправляется рой киберищеек без участия человека.
Неправильный ответ критиковать кривой код погромиста это как ругать каменщиков за швы в 3 пальца. Я вот глядя в код одинц заебался поблевывать уже.
Забавно. С точки зрения ИБ иногда ощущения схожие )) но там больше общая архитектура и конфигурации, в самом коде сильно поводов меньше безопаснику видно, хотя и от systemfileoutput(argv[0]) и $rootPassword='12345' перистальтика страдает в обе стороны
Будто бы ТЗ изолировано разрабатываются и независимо. Заказчик максимум может выдать "сделай хорошо", если он не понимает ничего и это НЕ ТЗ.
Вечно такие "ой нам скучно а давайте эту хуйню попробуем а давайте другую хуйню? Ой чуть медленнее? ну пох, главное заказчик чтобы съел", потом другие заказчики смотрят и им тоже подавай.
Выходит какая-то прям коллективная ответственность за общие тенденции. Я не согласен с тем чтобы винить некоторых из конкретных исполнителей, но тенденции реал шлак.
А другой момент, что когда-то компьютеры были дорогими, а программисты дешёвыми и код был лучше. Щас же программисты слишком дорогие чтобы тратить их время на хороший код.
Заказчик максимум может выдать "сделай хорошо", если он не понимает ничего и это НЕ ТЗ.
Представьте, что при этом, заказчик, просит построить не вел-бегунок, а самолет. Вот и разработчики пилят за бюджет мерседеса, что-то похожее на боинг.
Нормальные компании-заказчики прекрасно умеют сначала составить ТЗ с аналитиками, прописав в нем целевые значения для быстродействия. Но само ТЗ уже стоит как проектирование самолета, а его еще и разработать надо.
Я имел в виду сторону заказчика внутри компании. Работодатель как заказчик. Владелец фирмы не с бухты барахты придумывает какое говноприложение он хочет. Есть много специальных людей вокруг него, часть из которых в том числе и разработчики, с которыми они совместно и составляют. а что собственно делать они будут. Я крайне сомневаюсь что ситуации когда разработчикам, хотябы одному техлиду, просто спускают сверху, не спросив у него ничего, часты.
Да точно также работает внутри компаний. Кто помельче, у тех и сотрудники попроще - без всяких ТЗ и методологий херачат вместе со своим заказчиком все фантазии.
Кто побогаче и крупнее уже имеют отделы для анализа требований к ПО, имеют на руках аналитику результатов творчества разработчиков. Техлид хоть и участвует во всем этом, но с него тоже спрос будет уже из отдела продаж, если полезут негативные отзывы о ПО.
Да, прописано. И даже прописано - как. И даже прописаны требования к системным ресурсам, допустимая нагрузка и показатели производительности при этих параметрах, если это нужно заказчику. Критерии приемки, все дела.
Ну по меньшей мере заказчик должен понимать что ему нужно и положить эти требования в ТЗ. Всем известно выражение, что без ТЗ результат ХЗ. Если заказчик думает, что команда разработки залезет к нему в мозг и достанет оттуда все его хотелки и реализует в проекте, то это не так. Если заказчик не проявляет желания работать с командой разработки на протяжении всего контракта, а заявляет, что я вам дал ТЗ вот по нему и делайте, то результат будет очевиден и не будет соответствовать ожиданиям заказчика.
Пример хуйня. Больше подходит обращение к бригаде ремонтников "сделайте красиво, чтоб все охуели". А в подробности какую плитку или сантехнику ставить не вдаваемся.
"вы сказали поставить кран - я и поставил. Вы же не сказали, что вам нужен кран именно под ваши старые советские трубы в стене, я и поставил новый, с подводом снизу - врезал в раковину, а воду подвёл через клубок ПВХ переходов на полраковины - вы же не сказали, что вам нужна вся раковина, только просили "сделать побыстрее".
Это неправильная аналогия, правильно будет:
- зачем Вы холодную слева, а горячую справа сделали???
- так у Вас так и было! И вообще это стандарт! И трубы у Вас как раз с этих сторон подходят!
- но мы хотели поменять!
Не так. Приходит заказчик к сантехнику и говорит "Нужен кран, чтобы красивенький. Вот труба из дома 1/2 дюйма торчит, прикрутите кран на свой вкус"
Разрабы прикручивают обычный шаровый кран. А потом оказывается что у него там производственная теплица и требовалось организовать систему для ее полива с потоком в 300м3/час. Но в ТЗ нигде про это не написано.
Тз, чтобы было 100 заявок от клиентов в день.
Но начинается нытье. И нет результата. Аналитики, где их взять, вы ж сами компутерщики.
Прикинь, да. Для этого обычно есть проектная команда на стороне заказчика (или как минимум компетентный ПМ).
Верное ощущение.
Содание и согласование ТЗ по затратам может быть больше основных работ. Иногда надо тестовый стенд создать и его поэксплуатировать для получения данных для расчета разделов ТЗ основного проекта, но это для нетиповых работ. Иногда ТЗ пишет более дорогой исполнитель с сильной экспертизой, реализует другой - подешевле.
Создание сайтов, даже очень сложных, сейчас гораздо проще. Скорее всего там будут требования по нагрузке / отклику. Они могут пользователю не нравиться, но скорее всего эти требования будут обоснованы компромиссом время/деньги/качество.
Можно заказчика просвещать и объяснять эффект экономии на пользовательском опыте, но если у него нет денег или горят сроки - что сделаешь?
А если один или оба в паре заказчик-исполнитель долбоебы? Там шансов нет, будут проблемы ) и, к сожалению, у пользователей тоже, а не только у них
ТЗ редко целиком пишет заказчик, обычно этим занимаются аналитики, причём это могут быть аналитики со стороны исполнителя, а заказчик согласовывает.
В ТЗ прям прописаны объемы приложухи? Мы такто не про сайты але.
Челы, платящие бабки, иногда к сути ТЗ имеют сильно опосредованное отношение. Они имеют некое представление о результате, но если в ТЗ будет просто написано "сделать заебись", то ты сам такого заказчика нахуй пошлешь (ну если с мозгами). Я тебе даже такую крамольную вещь открою - ТЗ иногда пишет сам исполнитель. Это вытекает из тендерных игрищ - есть задача и исполнители хором рассказывают как заебись они это исполнят. Выбрали тебя - ну вот и расписывай как ты исполнять то будешь. А чтоб ты не ахуевал на фоне нулевого заказчика у него есть такие братки под названием супервайзеры, ну это собсна твои коллеги, просто которым прям счас не повезло тебя перебазарить и они приложат все усилия, чтоб ты обосрался и они это обоснованно заказчику распишут. Только я это пишу про реальное производство, а у кодеров похоже обратной связи или нет или очень слаба.
Всегда поражало мнение об оптимизации, а как о какой-то финализирующей процедуре, ну как о покраске жоповозки - типа похуй как там собрали накодили, главное потом красочкой пройтись и прям конфетка. "Оптимизировать" уже написанный говнокод это иногда написать его заново. Делать это надо прямо в процессе. Но это ж сложна, там думать надо, а не скопипиздить из шаблонов, слепить как из лего франкенштейна, и заебись.
Что называется: делай нормально - нормально будет
Удивительно. Самолеты тоже всегда падают из-за человеческого фактора?
Масштабируемая система требует проработанной архитектуры под задачу, чуть более квалифицированных исполнителей, чуть более сложных инструментов, запаса по аппаратным средствам, желания заказчика сделать проект чуть за бОльшее время и чуть за бОльшие деньги.
Как часто вы видите проблемы с надежностью, производительностью в реальной жизни? Там где не прорабатывают решение под новые условия: ну подумаешь, в 5 раз больше пользователей + добавились регионы, на глазок добавим 30% везде, прокатит.
Заказчик как чайка повторяет "Еще дешевле/быстрее можно?", а на все риски говорит "ок" - экономия же сейчас, а проблемы потом (или не у него, а в эксплуатации)
Люди не знают специфику отрасли, тащат непроработанные решения из других реалий, делают не что надо, а что могут.
Честные ошибки - выбранная архитектура/компоненты/фреймворки просто не могут обеспечить нужного функционала, что ты с ними не делай, либо требуют титанических усилий по переделке ключевых компонентов, вроде сетевого стека или управления памятью.
Оптимизация должна быть предусмотрена при проектировании, если мы не говорим про типовые решения. Одно дело гамбургер испечь, другое - вкс запустить по всему миру. В какой-то момент сложность системы такова, что она ни в одну голову не помещается уже и предсказать все возможные проблемы становиться нереалистично. А если и удается догадаться аналитически, часто это кончается "это маловероятно и мы ок, если произойдет" тк решить сейчас - дополнительные проблемы со сроками/стоимостью гарантированно.
Проблема что джун/мидл делает неоптимизированную херню в то время как мог бы делать оптимизированную очень тривиальная и мне встречалась очень редко. Все-таки при подборе смотришь на людей, многим лично нравиться делать работу качественно, по крайней мере мой опыт за много лет и много мест. Коекакеров много, но их меньшинство, основные проблемы в управлении и взаимодействии уровнем повыше.
ЗЫ. В больших системах заранее оптимизировать опасно, тк вы улучшая что-то, одновременно что-то ухудшаете. Каких-то чумовых результатов оптимизируя наперед редко получается достичь, как правило нужны или испытания, или опыт в отрасли, или очень четкий кейс, чтобы оптимизировать заранее.
Самолеты тут причем?
Масштабируемая система
мы про стандартные приложения зачем в дебри вылезать?
Как часто вы видите проблемы с надежностью, производительностью в реальной жизни?
ежесекундно, дальше что?
у подумаешь, в 5 раз больше пользователей + добавились регионы,
У вас разный код под разную наполненность базы данных? Мдааа если б такие спецы писали наш софт мы б уже по миру пошли.
Заказчик как чайка повторяет "Еще дешевле/быстрее можно?"
ну что за бред вы за пирожок на базаре с Ашотом торгуетесь? Сроки и цены прописываются заранее, а не "можно дешевле".
Люди не знают специфику отрасли
потому что они вообще никакую специфику не знают, их н+1 заборостроительный выкинул с корочкой "умеет налепить фреймфорков и это даже немного работает" и все. Говорят что де вот спецов не хвататет так именно что людей полно, но спецов среди них нет. Есть говнокодеры.
Вопрос почему приложение Сбера в 10 раз тяжелее приложения Россельхозбанка? Он там нитакой банк чтоли?
Хватит сваливать на ТЗ своё похуистическое отношение к работе. Дуб заказчик со своим примитивным ТЗ обращается к профессионалам, а не любителям
Вы со срачем ошиблись - про то, что все бабы бляди, а мужики сплошь красавчикии, это в другом треде. Тут про заказчиков и исполнителей. С таким уровнем понимания проблемы для вас все исполнители идиоты и вы всю жизнь будете искать "нормального, настоящщего проффисионала". И не найдете ...
Хорошо ) а я не сваливаю на ТЗ свое похуистическое отношение к работе.
Заказчик, конечно, обращается к профессионалам. Если заказчик не понимает или не хочет понимать особенности реализации, значит все варианты ТЗ для него будут одинаковыми вне зависимости от профессионализма потенциальных исполнителей. Значит конкуренция будет только по стоимости. Значит выиграет тот исполнитель, который даст минимальную себестоимость и минимальную маржу. Чем обычно жертвуют в снижении себестоимости? Жертвуют обычно: обследование, проектирование, тестирование, документирование, кастомные фичи и, конечно, любая оптимизация и запасы на непредвиденное в первую очередь.
Если жадность продажников удасться победить угрозами о кошмарах в процессе и катастрофой при сдаче, тогда работы в итоге выиграет ПБОЮЛ Ашот-Камшот и все - заказчик сам себе злой Буратино, примет как миленький эту каку и отчитается наверх о полном успехе (он же не хочет проблем себе у руководства?) Если по цене упали в минус и работы все равно взяли на себя, еще хуже - теперь вы тот самый негодяй-разработчик, который в 40 часов должен вместить 60 или 80 и при этом совершенно не заботится об оптимизации, похуист чортов.
В обоих случаях пользователи жалуются на невозможность работы с системой. Квалификация программистов никакой роли не играет - создана атмосфера, где качество не ценится и ни на что не влияет при принятии решений.
Жалко СНИПов нет в ИТ ((
Работаю в сфере АСУ ТП, ситуация в отрасли такая же. Слабое ТЗ или его полное отсутствие, зачастую отсутствие прямой связи с заказчиком, вал проектов и нежелание на этапае договоров вникать в детали у манагеров. . В итоге вся боль проекта замыкается на разработчике, у которого сроки и значительное отсутствие исходной ининфориаци. Цена ошибки из-кривого кода очень высока. Вывозят проекты более опытные программеры, которые начали принимать такую ситуацию как некую данность и призыв действовать их более самостоятельно по решению задач проекта. Используют наработки, которые могут перекрыть многие пробелы ТЗ в короткие сроки. В итоге набираемый специалистом опыт, вес и отсутствие очереди за забором заставляет шевелиться руководство. Но многие новички страдают, ждут чёткой постановки задачи и максимум вводных инструкций, не получают, быстро горят и ,не набравшись опыта, работают на отъе... Сь. Если принимает правила игры, набирает опыт через боль, то становится норм инженером.
Сочувствую. Все как у нас прям :')
Нам повезло, было самостоятельное направление, пошли к сейлам напрямую, выкинули всех остальных из взаимодействия. Выделили инженера, чтобы сейлов везде сопровождал. Всем лучше - лояльность заказчика, себестоимость, маржа, переговоры.
Но это на личных контактах - из 30 продажников 2 были супер, 10 норм, 15 туда-сюда, а 3 конченные мудаки. Вот с 12 и работали изо всех сил +10%, остальным - что останется и только по бумагам. Но это генеральный был толковый. Новичкам не давали общаться ни с кем, только через опытных. Кидали их по нубству страшно, особенно РП.
ЗЫ. Отсутствие связи с заказчиком прям хуже рака на проекте. Всяко лучше, если тебе заказчик сам звонит и в рабочем порядке заранее договориться поменять что-то, чем потом носом его представителя по тз возить ... и все равно тебя свой же сейл и сольет в конце ((
Держитесь!
> Если в ТЗ оптимизация быстродействия не прописана
Именно поэтому в тиражируемой CMS вы не делаете индексацию таблиц?
Я видел таблицы, где индексацию отключали ради мизерного прироста в скорости инзертов. Официально вендор запрещал, неофициально поддержка говорила - индексируйте.
Допустим, тиражируемая система в 80% случаев, тормозит из-за этой таблицы у заказчиков с большим, чем 50 конкурентных пользователей. Они индексацию отключат и 19,99% не заметят, а 0,01% будут чесать репу - нахрена так делать?!
Может быть частые изменения данных в таблице делают индексы слишком медленными, а процедуру оптимизации запускать некому и нечему. Эта фича появится через год, наверное. Отключат индексы, тк 10% пользователей обратилось с такой проблемой и отключение индекса помогло.
Я знал систему, которая хранила уведомления в отдельной таблице и она была без индексов. Зачем? При нормальной работе там больше 1000 записей не бывало. Но! Если оператор не отрабатывал их неделями, то при рестарте системы счетчик уведомлений отваливался по таймауту и не давал запустится ui, если уведомлений накопилось больше 100к и железо у заказчика было слабое.
Я не хотел бы множить сущности, стажеры, долбоебы, стажеры-долбоебы иногда совершают и такие ошибки, иногда опыта не хватает, иногда очень неочевидные вещи происходят ... всякое бывает.
Со всем согласен. Но тут был именно тут случай, когда добавление индексов позволило ускорить работу примерно в 3000 раз.
Заказчик пишет "хочу на таком-то фреймворке"?
Или это пишет программер, который знает фреймворк но не знает хтмл?
Фуу, реакт, соооу 10's. Next.js из зе будущее. И ещё быстрее можно навалить дымящийся, свежий сайт
Не совсем корректно, имхо. Next.js основан на реакте, но им не является.
Так-то и андроид основывается на линуксе, но явно им не является... Хотя разница тут больше, конечно.
А вообще чет у меня душнила-мод включился, походу). Пофик на самом деле.
Next.js — серверный фреймворк для Реакта для SSR-приложений, но он не создаёт новый уровень абстракции. Если пишешь приложение на Next.js, в любом случае будешь использовать React и писать реактовые компоненты напрямую безо всяких обёрток. Сравнение андроида и линукса здесь вообще не в тему. Андроид как платформа может быть реализован поверх любого ядра, и приложения без нативного кода будут работать точно так же.
андроид основывается на линуксе, но явно им не является
каковы критерии явности и являния? Это как сказать что какаянить убунта основывается на линуксе но им не является.
Разумеется. Чтобы не остаться завязанным на исполнителя. Поэтому и выбирают обычно по принципу: этот фреймворк популярный — используем его. А сами программисты может быть взяли что-то более эффективное, но малопопулярное.
А потом эти программисты увольняются, приходят новые и не понимают, что с этим говном на неизвестном фреймворке делать.
Именно. Поэтому есть тенденция продолжать использовать «не совсем эффективные, но проверенные и популярные решения». Здесь нужна очередная волна хайпа, чтобы переломить сложившийся статус-кво на рынке, но этого сложно добиться.
С учетом стремительности прогресса в этой области - то что вчера было мегапопулярным завтра может быть мегастарьем, которое "никто не понимает". А проблема не в фреймворках как способе написания, а в том что эти новые даже с новыми фреймфорками понятия не имеют че там унутри. Раньше писали как музыку Бах, выверяя октавы и ноты, а сейчас как говнодиджеи (бля с каких хор чел, крутящий диски, стал их сочинителем, как чела, заправляющего пленку в кинотеатре, вознести до ранга режиссера) лепят музячку из сэмплов.
Заказчик еще пишет сроки и чтобы в них уложиться не получится писать без использования каких-либо готовых решений, как фрэймворки, библиотеки и прочие прелести. Также , если мы говорим про веб, то веб 15 лет назад и сейчас прям очень разные вещи. Если раньше это было статичное угловатое нечто, с возможным флэшем в шапке, то сейчас это все обвешано свистелками, перделками и прочими прелестями, которые, кстати, далеко не программисты придумывают. Еще в вебе много кто использует сео продвижение, которое замедляет работу из-за хитровыдуманных требований, и вот там очень много чего сами программисты не любят. Еще есть различные статистики типа яндекс метрики и гугл аналитики, к которой программисты тоже имеют мало отношения.
Ну и ваш пример с хтмл просто убивает, мало того что это язык разметки, а не программирования, дак еще и фрэймворком он не заменяется, а расширяются возможности.
Ой вот ненадо а, это ж производители стиральных машин придумали фишку что можно выпустить говнобетаверсию, а затем патчить ее до скончания времен. Вы сами развратили заказчика своими - счас за 5 минут накопипизжу и будет квакать.
Начнем с того, что в любой профессии есть разные люди с разными принципами и уровнем ответственности. Уже отсюда можно понять что есть и говнокодеры и те, кому запилить сайт для онлайн казино не впадлу, но есть и те, кто придумывают, практикуют и распространяют всякие SOLID, KISS, DRY и подобные принципы.
Первых может быть гораздо больше, т.к. новичков достаточно много и не все "выживут", но подобных и не особо допускают до крупных проектов.
Т.к. давно работаю в веб, то приведу вам пример, коих очень много, сразу и тех и тех, но с вашей точки зрения они будут оба говнари. Жил был заказчик и захотел освоить продажу через интернет, пришел к фрилансеру (вот тут люди часто натыкаются на говнокодеров и тут частично есть фактор конкуренции и демпинга от оных. Также есть фактор того что они работают по контракту, а не за зарплату. И это не оправдание, а описание как есть) и заказал себе интернет магазин. Сделали это нечто и даже поддерживали пару лет. Проект начал приносить плоды и трафик попер, фрилансер уже не вывозит или просто сливается еще раньше. На поддержку набирают штат уже более-менее толковых (работая в штате, да еще и если проект интересный, отношение у многих абсолютно другое). Проводят анализ и говорят что надо все переписать и это займет год. Никто им этот год не дает и начинается вялотякущая работа по попыткам выделять по кускам и преписывать, держа при этом и поддержку старого и работу на новом. Через год-два начинается текучка кадров, т.к. многие программисты пытаются найти более развитый проект в плане технологий, а не копаться в этом франкенштейне из монолита легаси с кусочками архитектурно и программно нормальных блоков. И вот только 1 из 100, а может и менее, таких проектов доживет до момента перехода от старого к новому и займет это не чистый год, а лет 5.
Никто им этот год не дает
то есть отмели главную проблему и разбираетесь в частностях?
Этак любую работу невозможно сделать если на нее не выделить время. Даж посрать только в штаны получится.
Прекратить штамповать кодеров и начать ебать существующих кодеров если они желают получать за это бабки
А теперь оцените вероятности данного события. Особенно с учетом того что штампуют одни, а ебать должны другие. Ну и не забыть в уравнении что сейчас рынок соискателя в этой области.
Я, конечно, разделяю твою боль, но, давай смотреть правде в глаза? Какие условия работнику ставят, так он работу и делает. Что заказчик требует, то разработчик и будет делать, минимизирую усилия. Я сам программист и меня точно так же ажтрисёт от приложений в телефоне, с несколькими формами и парой десяток элементов на них, на 200+ мб., а ещё каких-то 15 лет назад такое приложение и 1 мб. не весило бы. Хочется спросить "Акаковахрена?!", но спрашивать особо то не у кого, имеем что имеем. С таким же успехом, мы можем мясокомбинатам предъявлять о том, почему они не делают исключительно качественную колбасу, на что они, скорее всего, ответят что-то типа "идите на йух со своими идеалами, мы тут прибыль к 300% пытаемся подтянуть"
С таким же успехом, мы можем мясокомбинатам предъявлять
Так и предъявляют. И делают это рублем, просто не покупая его продукцию. Не ну говноеды будут всегда, согласные за пару рублей жрать все, что навалят, лишь бы с горкой
Думается, что «идеальность» Телеги была её маркетинговой стратегией, дабы конкурировать с существующими мессенджерами.
То есть остальным стопитсот мессенджерам нахуй не нужно было ни с кем конкурировать, а тут Дуров решил в дурака поиграть и как давай конкурировать? Мб просто он из старой школы?
Вероятно не нужно, иначе почему они как были bloatware, написанные индусами, так и остались: и скайп, и ватсап, и вайбер. Это при том, что у Майкрософта и Фейсбука хватило бы ресурсов и специалистов сделать нормально.
Тз придумали программисты.
Мне как заказчику надо, чтобы красиво, что неважно. Главное, чтобы клиентов сайтег приносил. А там хоть на голове стойте, но нет им надо тз.
То есть, хочу, чтобы с одной стороны вставил доллар, а с другого два выпало. Бизнес так не делается. А чтобы ваш сайтег хотя хроменького клиента привёл, вы должны знать свою ца и как её поймать. Программисты её не знают и не должны, это не их работа. Так что писать задание должны вы.
Яж написал, я не шарю в компутерам, но говорят в интернете клиент.
А зарплата твоя программистская допустим 10% от тех денег, которые ты в клюве притащить в виде клиентов. Иначе зачем ты нужен, убыточный такой. Готов даже кормить тебя полгода за свой счёт, но затем результат выдай.
Бизнес именно так и делается.
Причем желательно доллар не свой совать,
Предполагается, что гайки крутить будет слесарь Вася, ему 60%, 10% ИТР и гендир, и 10% на гайки.
Разделение труда. Продажи, исполнители заказов, прибыль
Заказывается инструмент, а не клиенты.
С тз «приведите клиентов» в лучшем случае нах пошлют
ТЗ нужно обеим сторонам.
Исполнителю - для того, чтобы Заказчик по ходу разработки не навешивал дополнительных хотелок и не менял условия по 10 раз на дню.
Заказчику - для того, чтобы в случае чего можно было предъявить Исполнителю за ненадлежащее выполнение работ.
Составлять ТЗ должен Заказчик и согласовывать его с Исполнителем. Но поскольку IT область специфическая, то в реальности на написание грамотного ТЗ у Заказчика часто не хватает компетенции. В результате Исполнитель сам себе пишет ТЗ и получает двойной профит :о)
Если не можешь составить ТЗ и не можешь заплатить тому кто может составить ТЗ, то никакой сайтик никакой прибыли приносить не будет
Я бы привел аналогию с толпой. Люди индивидуально и люди в составе толпы ведут себя совершенно иначе. Когда мы организовываемся бюрократически и административно, что-то новое начинает жить и влиять на результат.
К сожалению, сейчас стало больше задач, которы могут быть решены исключительно большим количеством людей, которые должны сотрудничать друг с другом.
Про законы рынка ниже тоже хорошо написано ниже, вы должны обманывать себя и заказчика на равне со всеми вокруг, иначе не выживите. Это почти научились решать через собственных дочек-сервисных компаний, но там другие проблемы полезли.
Нет, ну вы всё же лукавите. Любую задачу по-разному можно делать. Просто программист, который по умолчанию делает не тормозящее, больше денег берет. А иногда по трудозатратам вообще одинаково - что тормозящее сделать, что нормальное.
Верно. Просто проблемы на разных уровнях возникают, нерадивый программист самый очевидный, но, мне кажется, по вкладу и последствиям самый незначительный.
