Вход | Регистрация



Заставлять пользователей писать требования?или самому и утверждение у них? (фикси)

Заставлять пользователей писать требования?или самому и утверждение у них? (фикси)
Я
   Бешеный заяц
 
21.11.18 - 10:36
Бывает часто (всегда) ситуация, когда пользователь что-то не договорил или думал, что сказал или имел ввиду что это само самой разумеющиеся, конечно программист на фикси обязан знать компанию изнутри и, если есть возможность предвидеть,дополнять и избегать ошибок постановщика, но всё знать невозможно и не всегда удается прочитать мысли пользователя.

Возникла идея насколько правильно заставить писать пользователей требования? конечно не по госту или другому стандарту, а по более простому шаблону (на просторах интернета пока не нашел подобное наверно плохо искал), или вариант второй составлять подобные требования самому и давать на утверждение заказчику.

Насколько данные варианты правильны? как у вас на предприятиях? шаблоны или примеры подобных случайно нет у вас?
 
 
   ptiz
 
1 - 21.11.18 - 10:41
Должен быть "главный по бизнес-процессам", который разрабатывает и утверждает/отклоняет все ТЗ.
   Cyberhawk
 
2 - 21.11.18 - 10:43
Любое планируемое изменение БП просто нужно чтоб согласовывалось начальниками всех участвующих в этом БП отделов
   Бешеный заяц
 
3 - 21.11.18 - 10:51
(1) нет такого человека
(2) Согласен
   Lama12
 
4 - 21.11.18 - 10:58
(3) Если такого человека нет, то попробуй стать им. Это практически безграничная власть. Перед этим предупреди руководство что если возложить данную задачу на тебя, то всем остальным ты будешь заниматься намного меньше. А без согласования изменений БП, будет автоматизация бардака и в результате получите автоматизированный бардак. Вопрос что им нужно?
   gantonio
 
5 - 21.11.18 - 11:02
правильно. Писать они не смогут и количество работы сократится вдове.
   Бешеный заяц
 
6 - 21.11.18 - 11:04
(4) у нас был бизнес аналитик, его заклевали и откровенно говорили не учи нас как работать... руководству откровенно превать на БП.

Сейчас задача прикрыть себе зад. когда пользователь на тебя смотрит широкими глазами и говорит почему этого нет или почему это так работает , а не иначе.Плюс возможность показать пользователю что он дурак (если это так) так как изначально он сам этот бред предложил.
   Бешеный заяц
 
7 - 21.11.18 - 11:06
(5) они могут еще жаловаться, особенно если это топы
   OldCondom
 
8 - 21.11.18 - 11:06
Конечно самому. Попутно сам больше вникнешь вопрос и вероятно выяснится, что нужно было совсем другое.
Да и когда появится человек, отвечающий за составление подобных требований легче не станет. Ибо этот человек должен будет работать хорошо, чтобы полностью оградить тебя от заявок. Но, как показывает практика, таких людей чертвоски мало и на составлении ТЗ они долго не задерживаются.
   ptiz
 
9 - 21.11.18 - 11:07
(7) Типичный бардак. Если не выходит стать тем, кто принимает решение, то остается делать хотелки и тыкать потом в них носом заказчиков.
   Вафель
 
10 - 21.11.18 - 11:07
Прими как данность, что готовый продукт выходит только после трех-четрыех итераций
 
 Рекламное место пустует
   OldCondom
 
11 - 21.11.18 - 11:08
(6) ты в газпроме работаешь? Странно такое слышать. Ваш аналитик общаться не умел.
А заявки у вас на через дверь в коридор оговариваются устно, или все таки есть нечто вроде хелпдеска?
   Aleksey
 
12 - 21.11.18 - 11:08
(4) и будет как в анекдоте "Да все тоже самое, только ПИСАНИНЫ прибавилось"
   ikea
 
13 - 21.11.18 - 11:09
(0) И так и так. Часть пользователей без проблем напишет свои требования, часть вообще откажется писать - не царское это дело. Для подстраховки пишешь ТЗ как сам понял, даешь на подпись, потом предъявляешь. Но есть еще более хитросделанные, которые отказываются и ипсать и подписывать, чтобы всегда иметь поле для маневров. С такими труднее всего, но и таких можно заставить жить по правилам. Делать их задачи самыми последними, делать их долго, ссылаясь на отсутствие четкого ТЗ.
   Бешеный заяц
 
14 - 21.11.18 - 11:09
(10) согласен что в современном мире принята итерационная модель разработка и я этого понимаю, не понимает заказчик который счетает что каждая итерация это наш косяк.
   1Сергей
 
15 - 21.11.18 - 11:11
Частенько ГБ даёт задание на словах. Пишу письмо с описанием на утверждение. всё
   ikea
 
16 - 21.11.18 - 11:11
(7) К этим товарищам (топам) нужно вырабатывать персональный подход. Тогда особых проблем не будет.
   catena
 
17 - 21.11.18 - 11:12
Пользователи пишут бизнес-требование, утверждают со своим руководством (и с задетыми подразделениями, если таковые имеются). Специально обученные люди перерабатывают бизнес-требование в тех.задание. Разработчик оценивает тех.задание. Оценка, ТЗ и БТ утверждаются всем составом в бумажном или электронном виде.
Специально обученными людьми при необходимости могут выступать разработчики. Пользователи не могут и не должны.
А на счет "подумал, что сказал", у меня в нормативках даже есть примерно такой пункт: если текст задания может толковаться по-разному, разработчик его толкует по своему усмотрению.
   Вафель
 
18 - 21.11.18 - 11:14
(14) а ты тз составляешь вообще? его подписывают?
   Bigbro
 
19 - 21.11.18 - 11:18
давно не было проблем, но со сменой работы похоже появились люди которые делают круглые глаза и заявляют что "такого разговора не было".
от таких требовать буду формулировать письменно.
если остаются непонятные места - письменно же уточнять до тех пор пока не станет полностью все понятно.
   eklmn
 
20 - 21.11.18 - 11:21
(19) такие люди в тихаря капают руководству, что 1сник тупой и надо бы его поменять ))
   МимохожийОднако
 
21 - 21.11.18 - 11:39
(14) Квалификация специалиста 1С определяется умением убедить заказчика в обратном.
   Бешеный заяц
 
22 - 21.11.18 - 11:42
(21) это точно... вот чтобы это было сделать проще нужна некая бумажка
   unregistered
 
23 - 21.11.18 - 11:50
Готового решения нет. Многое зависит от сложности самой задачи (и соответственно рисков ошибочной реализации), квалификации заказчика (а способен ли он в принципе написать полноценную постановку), требований к качеству выполненных работ (допустимо ли в последующем корректировка под не утвержденные требования на этапе тестирования и приёмки).

В идеале схема такая.
1. Заказчик (пользователь) формулирует потребность в терминах предметной области с описанием для чего ему это нужно. Назовём это "заявка на доработку".
2. Исполнитель проводит интервью всех пользователей с целью сбора всех требований по заявленной потребности. При необходимости дополняет или уточняет заявку заказчика.
3. Исполнитель пишет полноценное ТЗ в терминах системы.
4. Заказчик утверждает (согласовывает) ТЗ.

Приём готовой разработки должен проводиться в строгом соответствии с подписанным высокими сторонами ТЗ. Что там написано должно работать. Чего там явно не описано - реализуется (или НЕ реализуется) на усмотрение исполнителя.
   catena
 
24 - 21.11.18 - 11:51
(22)Если ваши пользователи до того никогда ничего не писали, готовьте папку для коллекционных экземпляров. Помню, первые бумажки, которые мне приносили. "Хочу чтоб был виден количество коробок". После уточняющих вопросов, было дополнение: "Сразу, как захожу в 1С, чтоб был виден".
   unregistered
 
25 - 21.11.18 - 11:56
(14) > ...не понимает заказчик, который считает что каждая итерация это наш косяк.

Надо документировать каждую итерацию.
В преамбуле к каждому протоколу передачи на тестирование должно быть большими буквами написано, что исправления и доработки выполненные в рамках этой доработки не были предусмотрены изначальной постановкой и являются дополнительным требованием заказчика к сходному ТЗ.

А еще следует стучать руководству на постановщиков, не способных ясно и полноценно сформулировать задачу. Жаловаться на возрастающую нагрузку, вызванную  необходимостью додумывать за заказчика и многократное переделывание ранее согласованного.
   МимохожийОднако
 
26 - 21.11.18 - 11:58
(23) я бы дополнил "после подписания этих дополнений Заказчиком". Плюс денежку за подготовку ТЗ, если не фикси
   Йохохо
 
27 - 21.11.18 - 12:00
(24) самое классное, когда фича нужна двоим сразу. Там такая интерференционная картина возникает, местами цунами и цугундер
   StanLee
 
28 - 21.11.18 - 12:09
(0) всех требований не учтешь, полюбому нужно чаще общаться с постановщиком задач. Недавно так одна задача почти полностью изменилась. Нарисовал диаграмки BPMN что должны делают юзеры и прога, показал сотруднице, она сходу полсхемы поменяла.
   catena
 
29 - 21.11.18 - 12:13
(27)О, да... Сейчас скушно, сейчас у нас есть отдельный отдел, который устраивает эти бои без правил - согласует и расставляет приоритеты. Разработчики получают готовую утвержденную очередь.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует