Фрилансеры, охарактеризуйте техзадание пожалуйста - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
txt хуже. оба варианта как тз отстой:
что дано?..
что необходимо?..
каковы критерии приемки?..
тз должен быть таким, чтобы в случае чего его можно было прикрепить к договору и/или арбитраж мог запросто решить кто прав а кто нет и в какой мере.
поддерживаю.
Напишите пожалуйста, как заказчик, что бы вы потребовали для себя по этому алгоритму, как доказательство правоты
поддерживаю.
Напишите пожалуйста, как заказчик, что бы вы потребовали для себя по этому алгоритму, как доказательство правоты
мне кажется, что стиль написания ТЗ не имеет значения.
НО! Главное это отношение к людям.
Если человек не потрудился поставить перевод строки в своем ТЗ (как минимум в txt) и текст получился скомканным, то такое ТЗ "втопку"
мне кажется, что стиль написания ТЗ не имеет значения.
НО! Главное это отношение к людям.
Если человек не потрудился поставить перевод строки в своем ТЗ (как минимум в txt) и текст получился скомканным, то такое ТЗ "втопку"
у меня в notepad++ было wrap text, поэтому не заметил
---
но вот как правильно заметили "критерии приемки" - это хорошее направлении.
Может вы знаете что заказчик должен дописать в текст этого алогритма, чтоб он стал иметь "критерии приёмки" ?
Для меня лучше средний вариант: Если взять оформление структурой как у исполнителя и текст/модульность как у заказчика.
Вариант Исполнителя сухой и в нем потеряны акценты, которые делал Заказчик. По нему сложнее понять, что требуется - может оказаться, что алгоритм совсем не тот, что имел в виду Заказчик.
Вариант Заказчика многословный, в нем не хватает структуры/модульности. Но меньше простора для ошибки понимания Задания.
правильно, но на первый взгляд.
Так как если появятся "якоря" от закачзика, то есть упомянутые "критерии правильности",
то сухой исполнительный текст (фактически чертёж закоденого эксперта) приобретет ньюансы заказчика.
---
проблема в том, что упомянутые акценты, не формализуются в первом приближении. И именно они должны перефразироваться чтоб в конечном ТЗ быть алгоритмически описаны.
Для этого ТЗ вобщем-то и утверждается.
Вариант Заказчика многословный, в нем не хватает структуры/модульности. Но меньше простора для ошибки понимания Задания.
как раз шанс на ошибку в нем больше. Так как многословность скрывает отсутствие "критерия приемки". У исполнителя встанет дилемма "не озвученных требований". Которые хорошо описаны здесь
проблема в том, что упомянутые акценты, не формализуются в первом приближении. И именно они должны перефразироваться чтоб в конечном ТЗ быть алгоритмически описаны.
Я прикинул для себя при чтении - сходу хороший вариант не смог набросать. Вообще, ТЗ нужно писать как статьи - начинать с Плана, в котором есть пишутся Название/Назначение модуля. А потом уже наполнять Статью/ТЗ текстом/деталями.
Мне так кажется.
Я прикинул для себя при чтении - сходу хороший вариант не смог набросать. Вообще, ТЗ нужно писать как статьи - начинать с Плана, в котором есть пишутся Название/Назначение модуля. А потом уже наполнять Статью/ТЗ текстом/деталями.
Мне так кажется.
да, примерно так.
Cкажу, что данное ТЗ было сгенерировано программой. Отсюда чувствуется сухость и конкретность. Но в целом по результату опроса, оно понятно исполнителю.
Cкажу, что данное ТЗ было сгенерировано программой. Отсюда чувствуется сухость и конкретность.
Не понял? Искусственный интеллект уже пишет ТЗ?
Не понял? Искусственный интеллект уже пишет ТЗ?
нет ))
я просто создал нечто новое для понимания работы ЕА.
Некоторое подобие на структурированный шаблонный опросник.
Который во время заполнения может показывать
- Человеческое читабельное ТЗ (rtf что в архиве) для утверждения между Исполнителем и заказчиком
- Исходные коды на требуемом языке для любой торговой платформы на рынке (MQL, Java итд.)
вот тестирую мнение про "человечность ТЗ". ))
----
Но Рашид обрати внимание, тебе будет тоже полезно разобрать по полочкам замечание Ильнура
txt хуже. оба варианта как тз отстой:
что дано?..
что необходимо?..
каковы критерии приемки?..
тз должен быть таким, чтобы в случае чего его можно было прикрепить к договору и/или арбитраж мог запросто решить кто прав а кто нет и в какой мере.
Это как разв в копилку темы https://www.mql5.com/ru/forum/227780
И это на мой взгляд то, чего не хватает для качественной работы сервисов фриланса
нет ))
я просто создал нечто новое для понимания работы ЕА.
Некоторое подобие на структурированный шаблонный опросник.
Который после заполнения может генерировать
- Человеческое читабельное ТЗ (rtf что в архиве) для утверждения между Исполнителем и заказчиком
- Исходные коды на требуемом языке для любой торговой платформы на рынке (MQL, Java итд.)
вот тестирую мнение про "человечность ТЗ". ))
----
Но Рашид обрати внимание, тебе будет тоже полезно разобрать по полочкам замечание Ильнура
Это как разв в копилку темы https://www.mql5.com/ru/forum/227780
И это на мой взгляд то, чего не хватает для качественной работы сервисов фриланса
второй вариант почти как на псевдоязыке написан
чуть доработать и можно получить еще один мастер по написанию советников без знания программирования )