Без внятного ТЗ...
раскрыть ветку (1)
Регулярно сталкивался с ситуациями:
- или В ТЗ не написано что кнопка должна быть нажимаемой.
- или Ты зачем в ТЗ написал что кнопка должна быть нажимаемой? А какой она еще может быть. Это итак понятно! Это ТЗ для умственно отсталых?
Причем часто эти фразы говорит один человек.
показать ответы
Командный анализ ещё помогает. Плюс, если фича прям важная, лучше ещё разок к заказчику сходить с запросом: "А правильно ли я тебя понял".
раскрыть ветку (1)
А бывает и так: заказчик не акцентирует внимание на каком-то нюансе, потому что он кажется ему очевидным. Аналитик понимает по-своему, и тоже не акцентирует, потому что его видение кажется ему очевидным. У разраба третье видение, и тоже типа очевидное. В итоге на выходе вообще не то, и виноваты как бы все, но шишки достаются в основном аналитику.
раскрыть ветку (1)
раскрыть ветку (1)
ситуации разные бывают... Сказал поручик Ржевский...
Или в ТЗ это есть, но разраб читал наискосок.
Или в ТЗ это реально нет потому что аналитик накосячил.
показать ответы
Я вот одного не могу понять: ну откуда это увлечение Agile? Ладно в аутсорс-галерах, которые могут просто рубануть бабла по быстрому и потом непонятно как поддерживать. Но вот в казалось бы серьёзных конторах. Сидят, грумят с умным видом, а через год к проекту вернуться не могут, т.к. документации нет. Все прогрумлено.
раскрыть ветку (1)
Все прогрумленно! Все что накодено непосильным трудом!
СУБД забугорная - 3 штуки.
Android-пиложение - 3 штуки...
показать ответы
Бизнес требования по-любому не пишутся технарями, курите BABOK. Это верхнеуровневые требования, которые даже не юзкейсы обычно.
раскрыть ветку (1)
раскрыть ветку (1)
Мне на одной из прошлых выкатили претензию что по некоторым ключевым моментам знания есть только у меня, и если я в отпуске или заболел или уволился и произойдёт пиздец, то это будет фатально для компании.
Когла я пытался рассказать коллегам самые тонкие места и что на что нужно оьращать внимание то меня попросили не грузить им мозг этой инфой
Когла я пытался рассказать коллегам самые тонкие места и что на что нужно оьращать внимание то меня попросили не грузить им мозг этой инфой
показать ответы
вы таки будете смеяться но меня когда учили в альма матер всегда говорили что проектирование занимает до трети разработки, ладно хоть не жизненного цикла.
сейчас норма - 2 недели на ТЗ, полгода до продакшн версии.
раскрыть ветку (1)
Потому что по задумке заказчика, зачастую, машина должна летать, быть с квадратные колёсами и заправляться водой. И, если этого не прописано, ты "по логике" делаешь её ездящей по дороге, с круглыми колёсами и заправляешь бензином, но, по итогу, ты сделал не правильно. Никогда не знаешь, что хочет закзачик, ибо это не вседа логично, поэтому делаешь строго по бумаге.
раскрыть ветку (1)
Так именно. В тз написано: сделать машину. Разраб делает легковую машину для езды по дороге. Надо внедорожник. Переделывают во внедорожник. Надо для езды по болоту. Переделывают на болота. Оказывается лучше сделать не колеса, а гусеницы. Сделали гусеницы. Надо чтобы сверху открывался люк. Добавили люк.
В итоге заказчик: ну вот, теперь так как я хотел. Неужели сложно сразу было догадаться?!
В итоге заказчик: ну вот, теперь так как я хотел. Неужели сложно сразу было догадаться?!
раскрыть ветку (1)
Только вот платит он как за легковую и не хочет оплачивать стоимость доработок и расходников
показать ответы
В чем проблема? Записал его поток мыслей на бумажку и тутже ему пихай на подпись пока он тёпленький! Я к таким мудакам сразу с готовым бланком тз прихожу и пока он как тетерев на току заливается быстренько записываю и тут же ему сую. И диктофончик иногда на запись ставлю с особо хитрожопыми.
Некоторый формализм иногда помогает.
Некоторый формализм иногда помогает.
раскрыть ветку (1)
Против сбера это не работает. По крайней мере той его части, с которой работаем мы. После высылки ТЗ у нас бывает бриф совместно с заказчиком, с разбором ТЗ, в процессе постоянные обсуждения что и как делать, в чате, где есть заказчик, и все равно, после выполнения работы оказывается, что все не то и не так. Мы даже запись брифа делали и носом тыкали - не помогло. То ли человек от сбера, который с нами работает, тупой как пробка, то ли наоборот, слишком хитровыделанный.
раскрыть ветку (1)
Может быть оба эта качества одновременно - встречал несколько таких.
Они постоянно пытаются юлить и хитрить, но настолько тупо, что вызывает чувство испанского стыда.
А если у них не получается и есть вариант включить начальника то обязательно это сделают.
Тыкали. Каждый раз это делаем. Наше вышестоящее начальство тоже тыкает, но там ноль на массу понимания, что косяк с их стороны. Отсюда у нас уже и шутеечки, про понимание того, почему сбер работает через одно место.
раскрыть ветку (1)
ИМХО, к.м.к. кажется есть большой косяк в том, что зачастую документация на проект отделена от кода и плохо с ним связана.
Прогеру надо одновременно втыкать в IDE и в документ который иначе структурирован, оформлен и т.п.
И тяжело отслеживать взаимосвязь.
К примеру есть какая-то функция и в документации должна быть четко описана и в описании разных процессов давалась чёткая ссылка именно на конкретную функцию.
А не так что прогеру дали пачку описаний разных процессов, которые скорее описывали разные аналитики и описания сильно отличаются по стилистике и оформлению, и прогер только сам должен догадаться что все эти процессы связаны одной функцией, потому что по тексту чёткой взаимосвязи не прослеживается.
Ну и аналитиков как и у прогеров должен быть свой чёткий стайлгайд и регулярное докревью чтобы коллеги друг друга регулярно макали нос в явные косяки.
показать ответы
IT-юмор
7.2K поста53.2K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору