Страницы: 1
RSS
Как правильно описывать (составлять) ТЗ
 
Добрый день!
Вопрос к продвинутым спецам наверно. У кого есть форма, может ссылка какая на форму ТЗ при постановке задачи, допустим в разделе Работа? Периодически делаю заказы, мне суть задачи как правило ясна, но бывает сложно объяснить спецу. Нужна некая форма, НО не от айтишника к айтишнику, а скорее от обычного пользователя к исполнителю, чтобы избежать лишних обсуждений.
 
Вряд ли есть такая форма. Задачи-то разные.
Составить понятный пример и описание. Как понять, понятны ли? Показать знакомому, который не вникал раньше в задачу.
Если задача непроста, разбить описание на подзадачи.
Указать сумму, на которую рассчитываете.
 
Yanosh, а почему вопрос в ЭТОМ разделе?
 
Юра, Yanosh создавал темы в основной ветке, потом создал в Работе. И нигде не может толком объяснить задачу. Вот и спрашивает. как правильно рассказать, чтобы задача была понятна не только ему самому.
Вот и здесь название темы такое, что запутывает
Цитата
Необходимо ТЗ
Поменял
 
Понял )) Ну а к РАБОТЕ ФОРУМА какое отношение это имеет? В КУРИЛКУ :)
 
Это я уже недосмотрел. Думал, вопрос в Курилке :)
Переношу.
 
Цитата
vikttur написал:
вопрос в Курилке
Про курилку как-то не подумал. Объяснить я могу, способы просто разные, ТЗ айтишников мне известны, хотел уточнить как тут это сделать с меньшим словообразованием..
 
Уважаемый Yanosh!
Хочу процитировать Дмитрия Щербакова...
Даже самый простой вопрос можно превратить в огромную проблему. Достаточно не уметь формулировать вопросы...
_____________________________________________________
Как правило, многие заказчики ТЗ, пытаются "навязать" свое видение автоматизации.
При этом, заказчики не допускают мысли, что их понятия в алгоритмизации могут быть - НУЛЕВЫМИ!
Как известно, алгоритмизация - ПЕРВИЧНА, программирование - ВТОРИЧНО!
В моей АЛЬМА-МАТЕР (Томский Государственный Университет) этот принцип жестко исповедуют!
 
Во-о-от. Это самая суть:
Цитата
Как правило, многие заказчики ТЗ, пытаются "навязать" свое видение автоматизации.
Нужно отбросить свое видение решения и изложить только саму суть задачи.

Простой пример.
"я копирую ячейку и вставляю на другой лист"
А оказавается, это делается для того, чтобы по критерию на другом листе посчитать значения. Но для этого не обязательно копировать!
И вот такой информацией заглушается вся полезная.
 
Фактически это повтор фразы
Цитата
vikttur написал:
Если задача непроста, разбить описание на подзадачи.
Наверно надо начинать с двух видов ТЗ. ТЗ верхнего уровня, которое описывает что на входе и что на выходе (естественно путь достижения тоже там указан, указаны ограничения, например такие как инструментарии, объемы ….) Второе  - это уже более детальное описание подзадач и оно может возникнуть уже на этапе исполнения.

При написании надо отталкивается от мысли, что исполнитель  видит задачу в первые и каким бы опытом и умом не располагал, он может ничего не понимать из области в которой работает заказчик и все обязательные фантазии заказчика, о том почему , от куда и куда попадает и каким цветом  отображается - должно поясняться.
Концепция, должна быть продумана и проверена заказчиком не при помощи автоматизации, а руками на предмет , а такое возможно?  Чтоб не получалось 8 взаимно перпендикулярных линий.
Идеально иметь набор тестовых сценариев (фактически это эталонные примеры ранее сделанные руками) которыми можно проверить работу, как на этапе разработки, так и на приемо-передаче. Конечно трудно охватить все моменты, но основные должны быть.
По вопросам из тем форума, личку не читаю.
 
Уважаемый Yanosh!
А если в Вашей конторе Ваши потуги на VBA будут не нужны?
Вдруг Ваша контора приобретет: SAP — страшно дорогая 1С-ка немецкого происхождения!
Вот уж тут точно потребуются "доработки"!
Вам, ОДНОЗНАЧНО, придется "освоить" немецкие технологии ТЗ с обязательными экономическими обоснованиями!
Без Ваших ссылок на Ваше видение Автоматизации!  :)  
 
Мотя,Ну не знаю какие были до этого задачи, но последнюю SAP не потянет :-) только Excel .
По вопросам из тем форума, личку не читаю.
 
Цитата
Мотя написал:
Как правило, многие заказчики ТЗ, пытаются "навязать" свое видение автоматизации.
:) Вот именно поэтому и дается только алгоритм ЧТО нужно делать. Уверяю Вас, одно экономическое и одно технически-специализированное образование позволяет четко ставить цели и указывать направление движения)) как и понимать, что не стоит "грузить" народ там, где слабо разбираюсь. А в целом с Вашим тезисом по алгоритмизации полностью согласен.....как гуманитарий)) Просто хотел услышать мнение спецов в данной теме, как следующий раз упростить задачу и себе и специалисту, думал просто может у кого ссылка есть какая на готовый текст, желательно не SAP-е алгоритмы))
 
Цитата
БМВ написал:
Наверно надо начинать с двух видов ТЗ.
Полностью согласен! Вот с ТЗ верхнего уровня все в порядке, с нижним уровнем значительно слабее, вот поэтому и сам мой вопрос был. Понимаю, что там очень конкретно формулировать нужно и, как показала практика, уже на уровне словообразования начинаются проблемы, поэтому и спросил.
 
Цитата
Yanosh написал:
Вот с ТЗ верхнего уровня все в порядке,
ну как в порядке …. . У вас есть представление, как это должно быть, и практика показал, что только на часть.  Сколько  я раз спрашивал про то, как попадают новые данные - и это не конкретика, это верхнеуровневая задача, так как относится к потокам данных.  

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


Короче, если продумана и описана функциональная модель или архитектура, то это и должно попасть в ТЗ.
По вопросам из тем форума, личку не читаю.
 
Цитата
БМВ написал:
Сколько  я раз спрашивал про то, как попадают новые данные
Ну как же, я и говорил...данные "зеркалятся" вот оттуда и туда и пальцем показывал, ну или данные оттуда "выгружаются" вот в этот диапазон и тоже пальцем)) а вот способ исполнения уже в голову не приходил, как раз слабость в ТЗ того самого нижнего уровня. Пытаюсь просто понять как видят мир технари, чтобы быть конкретней в будущем.
 
Цитата
БМВ написал:
Короче, если продумана и описана функциональная модель или архитектура, то это и должно попасть в ТЗ
Мне в процессе обсуждения на ветках просто показалось, что далеко не всегда спецы внимательно выслушивают саму задачу, как бы хватают верхнюю или первую мысль, а дальше как бы "ну мы сами мастера". И тогда приходится обсуждать значительно дольше, не все но несколько раз такое встречал. Хотя когда заказывал работу и входишь в конкретный диалог и согласования, обычно там уже все значительно четче становится. Вот простой пример. Как бы спецы на моем месте поставили задачу на работу - "создание базы иерархических выпадающих списков по условию на 15ть уровней"?
 
Цитата
Yanosh написал:
Ну как же, я и говорил...данные "зеркалятся" вот оттуда и туда и пальцем показывал
В том то и дело, что вы показывали куда они попадают. А вот туда они могли попадать ручным заполнением, атоматически запросами, макросами ….  для конкретной части задания это очень важно.

По второй части , про выпадающие списки: Однозначно нужно определить границы VBA или нет. Справочник единый или для каждой сущьности отдельная таблификсированне или  пополняются, если да, то как. Выбор строго иерархический или при изменении уровни ниже сбрасываются. …
Изменено: БМВ - 30.05.2018 23:49:13
По вопросам из тем форума, личку не читаю.
 
Цитата
БМВ написал:
Выбор строго иерархический или при изменении уровни ниже сбрасываются. …
Уровни заполняются последовательно, ветками по содержимому...
Спросил как пример. Был опыт раньше. И тоже в самом начале "бодались" прилично, определились примерно после 5го примера и долгих объяснений. В итоге задача была решена отлично, спасает по сей день шикарно. И тоже, четко понимал что нужно, но объяснял долго, майнды даже специально рисовал.
 
Цитата
БМВ написал:
А вот туда они могли попадать ручным заполнением, атоматически запросами, макросами
Вот именно, для меня при постановке задачи это КАК - уже способ решения поставленной задачи, это как бы уже не архитектура, а сам способ исполнения. Единственно что интуитивно понимаю, что сам способ тоже имеет массу нюансов, способ решения и даже этапов. Макрос это код, сложные массивы - это сервисный лист к примеру, вот именно тут обычно людям сложно объяснять как решать, но при постановке задачи как раз это для заказчика нужно только в самых общих чертах, я не прав?
Страницы: 1
Читают тему
Loading...