Здравствуйте, Dair, Вы писали:
D>Чудес не бывает, один человек не делает за 40 часов в неделю задач как два. Можно сэкономить на передаче знаний от бэкэнда к фронтенду, но когда проект растёт, всё равно надо знания передавать и экономия снижается.
Практика говорит об обратном. В айти один человек может делать работу за пятерых.
Верно и обратное, один человек может работать и в минус, принося отрицательную ценность и создавая работу нескольким программистам.
А в целом, чем меньше программистов и чем лучше они понимают бизнес и стек разработки, тем меньше им нужно тратить время на формализацию взаимодействия между собой и тем меньше они совершают ошибок, которые ведут к переделыванию.
Н>Так дело не количестве часов, а в количестве задач, которые в те же самые часы надо решить
нифига. адекватный работодатель не будет фулстека заставлять верстать с нуля, например. фулстек — копипаста формы и обработка ее напильником (помимо бэка)
Здравствуйте, Нomunculus, Вы писали:
D>>Но нет же. Фулстек-разработчики работают те же 40 часов в неделю что и отдельно бэкэндеры/фронтендеры. Н>Так дело не количестве часов, а в количестве задач, которые в те же самые часы надо решить
Чудес не бывает, один человек не делает за 40 часов в неделю задач как два. Можно сэкономить на передаче знаний от бэкэнда к фронтенду, но когда проект растёт, всё равно надо знания передавать и экономия снижается.
Здравствуйте, MaximVK, Вы писали:
MVK>Здравствуйте, Dair, Вы писали:
D>>Чудес не бывает, один человек не делает за 40 часов в неделю задач как два. Можно сэкономить на передаче знаний от бэкэнда к фронтенду, но когда проект растёт, всё равно надо знания передавать и экономия снижается.
MVK>Практика говорит об обратном. В айти один человек может делать работу за пятерых. MVK>Верно и обратное, один человек может работать и в минус, принося отрицательную ценность и создавая работу нескольким программистам. MVK>А в целом, чем меньше программистов и чем лучше они понимают бизнес и стек разработки, тем меньше им нужно тратить время на формализацию взаимодействия между собой и тем меньше они совершают ошибок, которые ведут к переделыванию.
Вот, кстати да, встречал в своей практике пару примеров, когда команда из 3-5 человек делает хороший продукт, который начинает продаваться, приносить прибыль (ну или случайно получается козырного "генерального клиента" отхватить).
На получаемое бабло контора растёт, штат увеличивается до 100 — 500 — 1000 человек.
А суть продукта не меняется, новых фич появляется минимальное количество, вся эта орава работает на горизонтальное масштабирование продаж и поддержание текущего "статус-кво".
После того, как весь штат меняется два раза, из изначальных пятерых остается дай бог один (ставший вице-президентом и далеко ушедший от разработки), генеральный клиент отваливается, "золотой дождь" заканчивается и контора медленно чахнет и умирает, хороня под своим жирным телом некогда классный и хороший продукт.
--------------------------------------------------------------
Правильно заданный вопрос содержит в себе половину ответа
Можно еще утроить — прописав в требованиях к фуллстековой вакансии знание Jenkins, Docker и Kubernetes.
— Нет в мире справедливости, — простонал Билл, когда цепкие пальцы Смертвича впились в его плечо.
— Конечно, нет, — согласился Смертвич. — А ты как думал?