Комментарии 25
На моем опыте был случай, когда один такой дешевый разработчик озаботился джобсекьюрити и перестал пускать кого-либо вообще в свою часть проекта. В итоге эта его часть стала самой проблемной, а он соответственно – самым продуктивным, так как эти проблемы постоянно решал. Его часть проекта была довольно критичной для заказчика, так что предложения по переработке от более дорогих разработчиков отбивались со словами "я пока занят" и "вы без меня все сломаете". В итоге проект растянулся в полтора раза и это перекрыло всю "экономию" на квалифицированных разработчиках.
Классика жанра: "сам создаю пожары, сам же геройски тушу". Такие псевдо-герои часто получают ордена за продуктивность, пока не посчитать, сколько стоит "спасённый" ими проект.
Тут на менеджере тоже сэкономили явно
Это ещё повезло, что он смог сам потушить свои пожары. Бывает в подобных случаях, разработчик создал столько проблем, что не в состоянии их решить. Тогда есть 2 варианта.
Первый вариант, разраб бежит к команде, за помощью, но проблема в том, что его участок проекта реально плохо написан и чтобы помочь, надо разобраться самим. Однако, с горем пополам, вместе решаете проблемы и вроде всё "хорошо".
Второй вариант случается намного чаще, если мы говорим о "дешёвых" разработчиках, они зачастую просто сливаются, оставляя проблемы не решёнными. Истории, когда фрилансер бьёт себя в грудь, даже берёт предоплату, делает проект наполовину, понимает, что нагородил фигни и упёрся в нерешаемые проблемы даже с нейронками, берёт и сливается под разными предлогами, по типу: развод, умер родственник, попал в больницу или полицию, забрали в армию и т.д. После чего, пропадает с радаров, оставляя вас с полу законченным, криво работающим проектом / участком проекта. По итогу, вам придётся, либо искать нового разработчика, (если предыдущий был один), при этом все новые разрабы будут говорить, что проект быстрее и проще переписать с нуля. Они точно всё сделают супер, хотя если это опять фрилансер, то гарантий повторения истории нет. Либо, если он был не один, команде придёться решать критические баги или переписывать часть проекта с нуля, что пойдёт во вред производительности и срокам коллег.
Не про дешёвых разработчиков, а про дешёвых инженеров поддержки.
Я как-то общался с владельцем/директором айтишной фирмы. По поводу инженеров техподдержки. "Почему не наберёшь хороших грамотных спецов вместо этих недоучек, да, дороже, но ведь клиенты жалуются?", спрашиваю. "А не выгодно, я пробовал. Да, это с учётом того, что некоторые клиенты недовольны уровнем техподдержки ", ответил он.
Опытные инженеры пишут код с прицелом на будущее: они понимают бизнес-контекст, оставляют документацию, следуют best practices.
Розовый пони приехал в Амстердам.
Ага, приехал, развернул monorepo без доков, закоммитил всё в main и уехал, оставив нас жить с его наследием. Теперь каждый раз, когда кто-то открывает этот код, рождается новый джун с ПТСР и вопросом: "А можно я лучше тесты писать буду?".
Так что да – пони бывают, но техдолг за ними – как навоз. Много и воняет.
Всё это очень логично в теории, но к сожалению, реальность такова, что в нынешнем мире взаимосвязь между ценой и качеством далеко не всегда прямая. Это касается всех сфер и профессий.
Согласен, реальность – это когда тебе за $150 в час приносят switch(true) в проде и any через всю архитектуру.
Но это не отменяет закономерности: если платить мало и без разбора, то вероятность нарваться на катастрофу стремится к единице. Так что да, цена не всегда про качество. Но вот низкая цена и отсутствие отбора – это почти всегда про боль.
Так ревизию надо делать. Встречал ситуацию когда компания расчитывала на долгоиграющий проект и его поддержку, нанимала отдельных ревизионеров которые заворачивали исходки со словами "г****код" - переписывайте.
Реальность такова - что нельзя четко посчитать сколько сэкономили. И всегда, даже с командой лютых сениоров, можно сказать, что вы выкладываете фичи слишком медленно.
написано всё правильно, но похоже что текст придумал ИИ :-(
Пока ты будешь кодить дорого и правильно, с документацией и ориентацией на будущее масштабирование, твои конкуренты сделают тяп-ляп быстро и раньше тебя откусят свой ("твой") кусок пирога, а потом (если понадобится), будут масштабировать и выделываться в разных позах.
Тяп-ляп – норм стратегия "срубить -> свалить". Но скейлить и мэйнтейнить бардак стоит дороже, чем строить нормально сразу.
Срубить и свалить нет цели, просят же - а когда, нам быстрее бы. Часто перед выбором - сделать правильно или быстро, просьба подождать однажды привела к потере клиента
Время разработчика стоит в десятки если не в сотни раз дороже серверов, в каком году вы живёте? Разрабатывать год "правильно" и потерять из-за этого пользователей, проверку гипотез и в целом развитие продукта в нужную сторону это идея фикс всех разработчиков. Бизнесу , а особенно стартапу вообще пофиг что там под капотом. Если решает проблему за свои деньги, то и супер.
Вот вроде бы согласен со всеми, сам все это видел... Только как бизнесу быть уверенным, что за дорогой ценник пришел не такой же тяп-ляпщик, как за дешёвый. Это помимо того, что знать нескольких людей, кто на собеседовании показал вполне сносные харды. Только в работе оказалось, что он может и может хорошо, но не хочет. У него задача тикет закрыть. И новому багу завтра он только рад - свой код исправлять гораздо проще, чем что-то новое делать
цена – не показатель, а фильтр минимумов. Как по мне, так дальше работает только одно: жёсткий найм + ревью + культура.
Воот, сперва кредиты цена, потом - культура.
Даже A/B тестирование из двух команд (недорогие разработчики и дорогие сеньоры) на один и тот же проект не покажет никаких выводов однозначно. Всё сильно упирается в:
1) сложность реализуемого функционала и прозрачность запрашиваемого функционала (поддается ли функционал алгоритмизации или требуется человек на поддержку)
2) требованиям к отказоустойчивости и информационной безопасности (эти требования могут снизить скорость очень сильно)
3) зрелость производственного процесса внутри компании, т.к. взаимодействие со смежниками может быть весьма болезненным
4) практики DEVOPS и CI/CD, зрелости инфраструктурных решений внутри компании
5) документированию и учёту мнения технической поддержки при формировании бэклога доработок
6) искусству лидера команды организовать работу внутри команды (как в условиях непрозрачности при реализации на деве, так и в условиях большого количества багов на проде), внутрикомандные взаимодействия
Правильно организованный процесс - всегда стоит дорого.
Отличная статья
Почему дешёвые разработчики обходятся дорого