Без внятного ТЗ...
раскрыть ветку (24)
Регулярно сталкивался с ситуациями:
- или В ТЗ не написано что кнопка должна быть нажимаемой.
- или Ты зачем в ТЗ написал что кнопка должна быть нажимаемой? А какой она еще может быть. Это итак понятно! Это ТЗ для умственно отсталых?
Причем часто эти фразы говорит один человек.
раскрыть ветку (17)
А бывает и так: заказчик не акцентирует внимание на каком-то нюансе, потому что он кажется ему очевидным. Аналитик понимает по-своему, и тоже не акцентирует, потому что его видение кажется ему очевидным. У разраба третье видение, и тоже типа очевидное. В итоге на выходе вообще не то, и виноваты как бы все, но шишки достаются в основном аналитику.
раскрыть ветку (13)
Командный анализ ещё помогает. Плюс, если фича прям важная, лучше ещё разок к заказчику сходить с запросом: "А правильно ли я тебя понял".
раскрыть ветку (3)
О. Было такое.
Заказывали новостной сайт. Т.е. основная задача - быстро и максимально просто выкладывать новостные материалы.
Как и о чем договаривались сказать ничего не могу, т.к. к проекту подключили уже после того, как начали подозревать что что-то с новым сайтом не так.
Погромист умудлся максимально усложнить процесс добавления новости: надо было каждый абзац добавлять как отдельный блок(элемент в битриксе), а для публикации новости надо было скомпоновать в нужном порядке ранее добавленные блоки.
В итоге отказались от такого прогрессивного подхода и настояли на обычном редакторе, позже сделал самописную легковесную обвязку, а потом - вообще возможность добавления, отображения и скрытия новостей из телеги.
А все потому, что понятие "очевидное" у каждого своё. Ну.. Или одинэсники - оторванные от реальности наркоманы.
Было у нас недавно недопонимание с разрабом) Я аналитик и у нас аналитики же занимаются тестированием своих задач.
Пишу в задаче, что товары с признаком А исключаются из заказов. В другом абзаце пишу, что товары исключаются из заказов на время действия спец.запрета (наличие запрета = признак Б). Попадается нам во время тестов товар с обоими признаками: А и Б. Ну для меня очевидно, что приоритет у признака А, то есть товар в принципе не должен быть в заказе, независимо от того, есть ли на него какой-то специальный временный запрет. А реализован был приоритет у признака Б: то есть, если у товара есть временный запрет, после его окончания, товар появляется в заказах. И разраб упирался, что работает верно, потому что в явном виде не прописано, что делать в таком случае.
Пишу в задаче, что товары с признаком А исключаются из заказов. В другом абзаце пишу, что товары исключаются из заказов на время действия спец.запрета (наличие запрета = признак Б). Попадается нам во время тестов товар с обоими признаками: А и Б. Ну для меня очевидно, что приоритет у признака А, то есть товар в принципе не должен быть в заказе, независимо от того, есть ли на него какой-то специальный временный запрет. А реализован был приоритет у признака Б: то есть, если у товара есть временный запрет, после его окончания, товар появляется в заказах. И разраб упирался, что работает верно, потому что в явном виде не прописано, что делать в таком случае.
раскрыть ветку (3)
Разраб был неправ в том, что система работает верно, и (в меньшей степени) в том, что не переспросил поведение при некачественных требованиях.
Увы, то, что произошло неверное толкование конкретно вашей командой (они усмотрели в группе требований взаимозависимость, которой не ожидалось), как раз и есть лучший индикатор того, что требования не слишком качественны, и что стоит улучшить процессы чтоб такие случаи отлавливать пораньше.
Другое дело, что абсолютно все аналитики в такой ситуации хоть раз да были.
раскрыть ветку (2)
Угу, тут ещё и недостаток знаний о существующей системе. Я когда писала требования, была уверена, что каждый раз перед заказом происходит проверка на оба признака. То есть в моём миропонимании такой проблемы в принципе не могло случится: если есть запрет, то товара нет в заказе по любому из условий, запрет кончается, срабатывает запрет только по признаку А.
А оказалось, что проверка один раз проходит, то есть изначально товары делятся на А и Б и больше не перепроверяются.
Если честно, даже постфактум не понимаю, как избежать того, что принимаешь за истину свои догадки и идёшь херачить задачи другим.
А оказалось, что проверка один раз проходит, то есть изначально товары делятся на А и Б и больше не перепроверяются.
Если честно, даже постфактум не понимаю, как избежать того, что принимаешь за истину свои догадки и идёшь херачить задачи другим.
раскрыть ветку (1)
Нужно по шагам расписывать бизнес-процесс. Желательно, ещё и блок-схему алгоритма рисовать. Это очень полезно во многих случаях:
1) Уменьшает недопонимание между аналитиком и разработчиком. Аналитик может внятно донести до разработчика, что он хочет, разработчик может аргументированно возразить и предложить другое решение сразу, а не тогда, когда приступит к реализации и представит себе алгоритм в подробностях.
2) Проще тестировщикам, тут даже объяснять нечего
3) Заказчик не может определиться с окончательными требованиями. В этом случае вы сразу видите, что нужно менять и оцениваете объём доработки
4) Заказчик по прошествии времени ставит ТЗ на доработку. К этому моменту вы уже, скорее всего, и не вспомните нюансов алгоритма, а ваш разработчик - тем более. Со схемой и описанием разобраться будет проще.
5) Ваш разработчик уволился. Объяснять новому человеку замысловатый алгоритм на пальцах - ну такое
6) Вы уволились. Хоть это уже и не ваша проблема, но со схемой вас вспоминать будут добрым словом
обычно в тз пишется действие которое должно выполняться при нажатии на кнопку, что уже подразумевает что кнопка нажимаемая
Ну это же документ, с содержанием которого должны быть согласны обе стороны. Иначе будет описанное Вами).
Причем часто эти фразы говорит один человек.
Бть...а житуха же. С содроганием вспомнил работу в мегафоне.
Хватило поработать там год (как выдержал, сам хуею). Именно вот так руководитель оценивал все мои ТЗ и пыталась заставить писать как он бть видит. Придирки буквально к каждому предложению.
Плюнул, устроился в норм компанию. Уже 3 года пишу ТЗ которые никто не ревьюит и вообще не контролит (Только РП который контролит сроки по проекту).
Заказчик доволен, новый руководитель доволен, я доволен (и ЗП еще повыше)
раскрыть ветку (1)
Это как ремонтнику нужно рассказать какой цемент брать. А не вот этот вот выровнять и поклеить вот это. Нет. Надо сказать как выровнять сука мне надо спецом быть по всему. А то у всех лапки и вы не говорили. Мне вот проводку штробили наискосок просто тупо по диагонали. А я электрику должна говорить про ГОСТы. А он ответил: вы не говорили. Уехать бы лопатой таких спецов. У программеров так же сука. 1 с ники это вообще отдельный вид. Да админы на работе и то сука отмороженные. Принтер не работает и дело не в бумаге. Через 8 часов вопрос: а вам чо срочно надо? Нет сука. Просто так звоню. Вы реально всё бесите. И чем больше ты программист тем меньше у тебя связи с реальностью.
Претензия к дизайнеру. Иногда как нарисуют, что фиг поймешь это кнопка или просто часть картинки. При этом у дизайнера не спросить, т.к. разумеется он тоже на фрилансе и "уехал в отпуск будет через неделю"
Не скажите.... ТЗ соответствует ГОСТу на информационную систему и там могут быть прямо прописаны способы реализации. Вот именно поэтому ТЗ это плохо - требования не должны ограничивать разработчика в поиске решения, они должны только ограничивать скоуп проекта. Есть раздельно бизнес требования, юзкейсы, функциональные требования, вижн, солюшн, естимейшн...
IT-юмор
7.2K поста53.2K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору