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