Фронт и бэк гонят друг на друга, потому что нифига не обсудили API о начала работы, что большой минус обоих. Менеджер (заивисит, конечно, чего он там менеджер точно) им должен был помогать и координировать, так что он больше всех мудак неквалифицированный.
Они обсудили, но хотелки клиента превыше всего и в первоначальный АПИ не укладываются, а надо уже вчера.
Как я устал своему манагеру это объяснять.. Им тама видите ли виднее, а потом "ой, шамиль, а чего это мы по проекту не уложились в часы за которые продали, а на-ка тебе хуй вместо премии за проект"
У меня лид хороший. Он всех нахер шлет, пока задача полный цикл не пройдет - в работу не пойдет. Даже некоторые баги превращаются в стори.
Горящими могут быть баги, которые не дают работать. А новые фичи, прикрученные на скорую руку без нормального тестирования, как раз к таким багам и приводят.
Да, а потом читаем истории, как прибегает менеджер в слезах и просит срочно сделать до понедельника. Команда вджобывает в выхи. А в понедельник менеджер с невиным лицом - А? Что? Какая фича? Ну или в лучшем случае - ну молодцы, клиент вернется из отпуска через месяц, сделаем презенташку. Ну или - я посмотрю в четверг, если время будет.
"Вчера надо - вот вчера и приходи" - правильная формулировка.
Это отличный ответ, когда у тебя есть деньги на зарплату сотрудникам/аренду/кредиты/налоги хотя бы на три-четыре месяца вперёд.
Если от фичи зависит жизнеспособность бизнеса вообще, то она важнее)
Да и хрен с ним. Я уже поработал за еду, дорогу молодым. Я хочу делать (и делаю) полезные вещи для бизнеса заказчика. Без нервов, планируемо, прозрачно для заказчика (сроки + деньги).
ну хусим так хусим )) у нас обьемы немножко не те, так что часть планируемых хотелок заказчика приходится в изначальную цену закладывать.
15% ? У меня почему-то не попадёт в 15%.
У одного заказчика это 2%, у другого все 50%.
Как ты эти 15% определяешь?
Эти 15% просто запаска, чтобы я мог показать заказчику свою клиентоориентированность и желание учесть мелочи, которые заказчик считает важными. Эти 15% – реально уходят на мелкие правки. Все более-менее серьезное – строго за доп. кост.
Что для тебя 15%?
Вот есть заказ - во сколько ты его оценишь? В 100р? Почему? Там уже заложено 15% запаски или нет?
и снова это задача менеджера - выяснить все требования и пресекать попытки менять требования после. Зачастую для последнего нужны яйца, чтобы сказать "нет, или платите +100500 и срок увеличим на месяц". Но зачастую неопытные менеджеры тупят взгляд и соглашаются на все мелкие правки, которых набирается на удвоение изначальных работ.
Я сам бэкендер, насмотрелся на менеджеров хороших и плохих.
Пожалуй, эта главная черта менеджера - удерживать баланс между хотелками программистов и заказчиков.
Ну на деле это всё инициилизировать бек должен. Бек должен ставить условие для фронта. Так и так.
Но вот "всё править на клиенте" звучит как бред..)
Чё - на секурность чтоли хуй положили?..
Да нифига. Бэкенд заботится о логике. Он не знает что точно нужно фронтенду для правильного отображения, что они там в какой момент хотят получать. Если это хоть сколько-то нетривиальный фронт, заботящийся о UX, то им нужны будут специфические endpoint'ы от бэкенда, и бэкенд не должен их угадывать.
Потому что менеджер на проекте не для красоты, вопрос тут не в премии, а втом почему в команде такая херня и адресовал бы я его именно менеджеру, потому нормальные менеджеры обычно это вывозят, да,накладки бывают, но когда такое происходит и менеджер вообще не очем,Это бред
Если фронту нужно чота специфическое - пусть пинают менеджера, а тот составляет дополнение к ТЗ
Вы что-нибудь о современных фреймворках слышали? Сейчас всю логику уже на клиенте ворочают))
От бэка требуется только корректно отдать массив данных в нужном формате.
Ох... Ну расскажи бэкендеру с 8 годами опыта в самых разных местах, что бэкенд это просто. "Массив данных в нужном формате" - это не все, так как ещё есть требования надёжности, отказоустойчивости, безопасности и так далее. А если данных много или их как-то сложно нужно преобразовать - отдельная история.
"так как ещё есть требования надёжности, отказоустойчивости, безопасности" - а при чём тут бэкенд? этим сисадмины должны заниматься. или в чём тут скилл?
Вы правда считаете, что не разработчики, а именно сисадмины беспокоятся о том, чтобы ваши данные не утекли?
Кто-то беспокоится о том чтобы мои данные не утекли?))
И я не считаю, я знаю. Ключи для серверов у нас генерировали именно админы. Бэкэндщики же просто писали на похапэ.
Что? К чему этот коммент? Есть ключ от сервера - заходишь и творишь всякую дичь. Причём тут инъекции, XSS-уязвимости и т.п.?
Ага, а ещё лучше физический доступ к серверу. Спиздил диски и ушёл. Тогда тут косяк охраны. *сарказм*
Сейчас всю логику уже на клиенте ворочают))Есть такая штука, которую я называю «пагинация по-американски». Сначала мы выгружаем всё в клиент, а потом на стороне клиента фильтруем и бьём на страницы. По какой-то причине встречается исключительно у американских фронтендеров.
Вот когда фронт определяет требования к API, в API и получается лютая каша, которую кроме как через graphQL не разгребешь.
значит вы работали со слабыми фронтами. Нормальный фронт должен понимать, как строится API - версионирование, методы, идемпотентность и т.д.
Я с разными фронтами работал. Но «понимать как строится» и «определять требования» — это немного разные вещи. А при адекватном API в 99% случаев REST-а хватает за глаза.
Другой вопрос, что каждый первый стартап считает себя Amazon-ом и Facebook-ом в одном лице и пытается обмазаться технологиями, которые конкретно в его случае не решают ни одной его проблемы, зато создают кучу новых.
Но, как бы, эпидемию noSQL мы пережили, нашествие функциональщиков пережили — переживём и GraphQL.
Т.е. слова фронт-энда из комикса по сути не объективны т.к. проблемы производительности вызваны им самим?)
Это схуяб, судя по по тексту он продакт, а координировать и помогать должен скраммастер, который ваще проебался и не пришел обсуждение приемирования.
Это ты очень наверно постарался, чтобы тактически не заметить мою пометку
(заивисит, конечно, чего он там менеджер точно)
Но в команде из двух разрабов и менеджера отвать менеджера исключительно на продакт - тупость. Роль project manager кто-то должен выполнять, и это должно быть явным выбором, озвученным и согласованным. И почти всегда это будет любой доступный менеджер, потому что двум разрабам на проект и так делов дохера.
Ну вообще имхо нет, скраммастер курирует разработку и действия команды, как лидер-технарь, тогда как продакт по сути заказчик, и,помимо выдачи тз команде, занимается туевой хучей бизнес вопросов вроде согласования финансирования команды, согласования всякой непонятной херни типа требований внутренних нормативных документов или смежных, не относящихся к продукту напрямую, служб, раскрутки продукта, сопровождения, вопросами дизайна продукта, получения пизды от начальства (ибо суть любой задачи - бизнес ценность, а не кол-во строк кода, хоть ты идеально его напиши, этого недостаточно). А если сюда еще приплести необходимость тестирования и аналитики в любой команде....
Во-первых, сам только что сказал что менеджер выдает ТЗ, а его, судя по всему, не было четкого.
Во-вторых, как я уже писал, менеджеры есть разные. Ты пишешь про product manager. Заниматься организацией работы коллектива должен project manager. Иметь продакта в команде из двух разрабов и без прожекта - очень странно и обречено на провал обычно.
Ну так на картинке просто менеджер, который про тз и заказчика, то бишь именно product, а не project (в описанном Вами случае - скрам).
Ну и ошибочно полагать, то невыданное верно тз - это всегда ошибка product, т.к. всегда существуют ограничения на разработку, о которых в сложных проектах узнают уже во время этой самой разработки и это надо принять как данность, ибо для этого и придумали скрам. К сожалению нонстоп с этим сталкиваюсь. Не было б так - все б работали по вотерфолу и не парились.
IT-юмор
5.7K постов52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору