Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - shishechka

Страницы: 1
1
и конечно, это все происходит в Москве?  :-[

2
Елена, а подскажите, Вы рассматриваете работников с Украины?  ;)

3
ну очень часто руководство не заинтересовано такие мероприятия организовывать, т.к. от таких времяпровождений результатов нет. Считается, что и так кому нужно, тот сам все найдет.

смотря как подойти к этой проблеме  :)

но по большей части Вы правы...  ;)

4
А это самое трудное, никакие организационные мероприятия не помогают.

никто не говорит, что поначалу будет легко. людям надо дать время привыкнуть. понятное дело, что часть будет против... но если руководство решить такие действия целесообразными, придется подчинится.

5
Если писателей много, то для этого нужно выделить отдельного человека, как правило ведущий аналитик, который как раз и занимается тем, что не пишет ТЗ, а делает ревью всех написанных ТЗ, проверяет их на полноту, корректность и непротиворичивость, + говорит куда нужно засунуть, если написали не в том месте или что-то продублировали.
у ведущего аналитика много других дел, чтоб проверять ревью написанных ТЗ...  :(

Цитировать
Если действительно система большая и аналитиков много, то можно разделить систему на функциональные блоки (очень слабо связанные друг с другом) и у каждого блока будет лид-аналитик.

и сейчас у нас в принципе система, поделена на функциональные блоки (очень слабо связанные друг с другом), но чтоб у каждого блока был лид-аналитик...
а вот это идея  :D спасибо

6
pmle, спасибо Вам большое  :D

7
Цитировать
В разделе с требованиями
  * ссылка на словарь предметной области, скажем так
  * ссылки на требования (у меня больша часть требования была в виде вариантов использования), сгруппированные по подсистемам.  Подсистемы можно
выделять по различным признакам, конечно. Требования могли ссылаться друг на друга.
  * ссылки на требования нефункциональные

вот в том то и проблема - что ссылка на ссылке  :-[  мы так и делаем.

а так как сидит не один системный аналитик и где-то я что-то описала, потом об этом не знали, что я описала, описали снова. в другом ТЗ дали ссылку на второе ТЗ. при обновление - я не знала, что появилось второе ТЗ, проапдейтила только свое, а во втором ни слова не указано об апдейте. и получается полная каша.

итог: время от времени я сижу периодически просматриваю все ТЗ и дублирующиеся удаляю, и обновляю информацию.

и шаблоны, где что должно лежать, и как оформляется и название, и само ТЗ - есть, но это не помогает  :(

Цитировать
А какая система, кстати? Каково ее назначение?

это CRM-система. только не на продажу. мы ее сами для себя разрабатывали, а сейчас поддерживаем.

8
Всем спасибо за ответы  :) И хотелось бы еще услышать пару дельных советов  ;)

По поводу того, как лучше хранить ТЗ - в данном случае (в фирме много сотрудников) - и для меня лучше не хранить ТЗ в формате Word, и делать рассылку по почте людям тоже не удобно.

Мы используем ВИКИ.


9
Уточните, пожалуйста,  что именно вы пытаетесь структурировать:
  * требования к системе в целом, которые дают пониманием как и что уже работает и куда новые требования "вписывать".
Я структурировала требования по подсистемам. 
  * или речь о структуре самого ТЗ на разработку, в котором должно быть описано все-все?

У меня вопрос больше касался как можно соединить все-все ТЗ (в том числе и требования) на систему так, чтобы, если что-то меняется не править во многих местах. 

10
Спасибо за ответ  :)

Вопрос реально-практический.

Понимаете, ГОСТ-ы и все такое - это хорошо. Но меня интересует, кто как на практике делает.

11
Здравствуйте.

У меня вопрос по структуризации технических заданий.

Если система очень огромная и технических заданий очень и очень много, то кто как структурирует ТЗ?

Необходимо, чтоб ТЗ не терялись друг от друга, и в тоже время, чтоб не было тысячи описаний одного и того же. а в случае правки - чтоб не править в 1000 местах?

Страницы: 1