В соседних темах вот пишут - я с такими бестолковыми задачами работать у них не буду. Сами, мол, не понимают, что хотят - а я кодь давай! Давайте мне нормальное ТЗ!


Фишка в том, что вам приходят задачи от бизнес-пользователя. И это обычные нормальные такие задачи, юзер стори и всё такое. И такая "мутная" формулировка - нормальная вполне для первого этапа.

Никакого ТЗ чаще всего от бизнес-пользователя вы не получите.

На втором этапе далее такие задачи далее нужно анализировать и делать четкую формализацию. Это может делать и специально обученный человек со стороны бизнеса, это может делать и 1С-ник, и кто-то третий. И это отдельные трудозатраты! И, да, согласуйте эту формализацию по итогам с автором проблемы )

И вот после этого этапа 1С-ник имеет шанс увидеть вожделенное ТЗ :)

Резюмирую, имхо, я бы уточнял (если вы ищете работу, к примеру) - кто формализует задачу для программиста? Готов ли работодатель оплачивать это время? Понимает ли он вообще, зачем это нужно.

голосовалку тогда бы прикрутил

Везде по-разному.

У нас обычно так (работаю удаленно - почасовая, почти франч):
Вариант 1: ТЗ пишет РП, отдает мне, я делаю.
Вариант 2: я сам пишу ТЗ (ставлю за это часы) - отправляю заказчику - они его согласуют.
Вариант 3: заказчик дает сам ТЗ (редко крайне).
У меня оплачиваются все задачи - от написания ТЗ до документирования разработок.

(1) Прикрутил

(0) готов ли работодатель оплачивать формализацию задачи?
Для фикси работодатель оплачивает и, поэтому на фикси обычно не берут просто кодировщиков по ТЗ.
Фри обычно учитывают формализацию в стоимости работ
А все остальные - лохи :)

голосую. везде по разному

(0) У нас аналитик от IT формализует и фиксирует в спецификации саму бизнес-постановку (т.к. заказчик очень часто внятно задачу сформулировать не может), плюс выполняет верхнеуровневое (до объектов системы) проектирование.
В таком виде задача передается на проверку и оценку трудозатрат архитектору и QA.
Ну, и дальше на выполнение разрабам и тестировщикам.

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

по голосовале пункты 1-3 => ...

(5) +1 тут на форуме встречаются альтруисты, которые выставляют закачзчику часы только за кодирование, а время потраченное на разбор и формализацию задачи и поиски решения они почему то дарят. никогда этого не понимал. это же львиная доля времени.

Тема - метание камней в воду. Тут столько методик, техник и технологий.

Мое мнение такое - если программист умеет работать по ТЗ - это хорошо, но выше просто кодера он никогда не станет. Если он умеет "чувствовать", что хочет заказчик, а еще, желательно, понимать предметную тему - тогда он может стать хорошим тимлидом. В остальном ТЗ и всякие архитекторы, РП, qA - это все ненужная бюрократия. Стартапы делаются в agile!)

(9) ну, если стоимость часа завышена, то почему бы нет?

(9) У таких разработчиков просто час 5000 стоит)))

И голосовалка

(12) как раз 5000ники таким не страдают, они свои 5000 за бумажную работу смело выставляют

процесс, описанный мной, понятно, - это пример

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

кто-то должен сделать формализацию

и вы как кодер имеете право спросить у своего начальника - кто делает (и отвечает за неё!) формализацию задачи?

(15) Это надо выяснять ещё на уровне собеседования. Тем более не кто не мешает задать вопрос нанимателю.

(10) ну, мы тут в 1С как-то далеки от стартапов )))

большая часть народа - фикси... и у них частый вопрос/дилемма/камень преткновения -ТЗ

Надо ли его писать? Кто его пишет? Зачем? А что туды писать-то??

и т.п.

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

На наличие/отсутствие ТЗ плевать с высокой колокольни, главное результат.


Как когда-то давно сказал мне бывший начальник: запомни, не пользователи для нас, а мы для пользователей.

(15) ТЗ по хорошему тебе самому и нужно составлять, т.к ТЗ по сути это "договор" между тобой и твоим заказчиком, чтоб подстраховать результат твоих трудов. Мол вот ТЗ, вы его подписали, я сделал. Другое дело, что составление ТЗ должен оплатить заказчик, если это не внутри компании работодателя.

(5) >>Для фикси работодатель оплачивает и, поэтому на фикси обычно не берут просто кодировщиков по ТЗ.


давно не работал на фикси, но, как мне кажется, имеет смысл проговорить со своим начальником официальный такой этап "Формализация и согласования задачи"

делать всё это самому 1С-нику, но просто подкрепить формализованной и официально согласованной задачей

(18) >> Обычно спрашиваю у "заказчика", покажи как делаешь руками, а я автоматизирую.

Бгг. А потом по результату скажут - дык не работает твоя фигня, потому, что ты вот тут не сделал и тут не так сделал. Ты скажешь, что мол как вы показали так я и сделал, на что тебе ответят - а мы не всегда так делаем.

(9) Я вот тоже не сразу это понял, теперь понимаю что это МНОГО, и ТЗ теперь просто так делать не буду)

(21) (18)

А ежели пользователь _это_ в экселе/ворде/на калькуляторе делает? Как будете в 1С переносить?

(21) Нужно задавать правильные наводящие вопросы :)

(23) Открываю конфигуратор и пошл-поехало, а ты думал как?

На серьезный задачи по изменению функционала всегда требую ТЗ, если что-то попроще можно и без ТЗ обойтись.

Я на фикси, потому в основном работаю без ТЗ.
Но если задача объемная или вообще глобальная, то сам и пишу ТЗ вместе с юзером.

+(27) главное в таком деле - вести учет задач, хоть даже в Excel( но у нас битрикс).
Ну и соответственно комментировать код упоминая номер задачи. Иначе потом не вспомнишь для чего писал и кто был инициатором задачи.

Пишу описание задачи сам.
Даже на самую маленькую задачу.
Потому что потом вспомнить что это, и кто это закалывал нельзя.
Должна быть история на все разработки!
Если просишь подписать задачи, которые могут быть конфликтными.
То часть из них отваливается.

Всегда надо писать документацию.
И всегда надо писать тз.
Эти документы должны быть на каждую задачу.
Даже из одного параграфа.
Детализация может страдать.
А факт наличия должен быть.

(28) +100500

(17) Писать надо всегда.
А показывать заказчику - по выбору.

(0) Мне предпочтительнее, когда я сам предлагаю решение и согласовываю его с ЛПР.

https://rinamika.ru/uploaded/davaj-do-svidaniya_4668001_orig_.jpg

(33) Глаза как в этом зачетном клипе: https://www.youtube.com/watch?v=xB_nKpEkILs

По теме: все варианты подходят

ТЗ нужно только программисту, заказчик все равно в немничего не поймет. А тратить время просто так ни для кого и бесплатно, надо ли оно?

Пишу разрабам где-то пол-страницы что как должно быть по архитектуре, какие формы и на что обратить внимание. Это на задачу примерно от 3 до 10 человекодней.

К сожалению пока что так..

(36) "Надо, Федя, надо!" ©

Тема ни о чём
Всё зависит от задачи и клиента

(40) Вот именно: тема ни о чём, а ТЗ всегда о ЧЁМ-ТО! :)))

Какая-то слишком уж разжеванная тема. И так понятно, что если пользователь знает как объяснить по-человечески смысл доработки, то составить ТЗ будет не так уж и трудно; если же пользователю это сделать влом, то это либо увеличивает трудозатраты, либо он идет лесом.

(0) ТЗ составляет прог вместе с заказчиком. Сам заказчик не всегда сможет это сделать. Иногда среди заказчиков попадаются "представители других цивилизаций", для общения с которыми придется подтягивать людей понимающих язык этой "цивилизации". Какое уж тут ТЗ, понять бы вообще о чем речь...

Но и отдавать процесс составления ТЗ прогу тоже нельзя. Вероятна ситуация, когда заказчик не так объяснил, исполнитель не так понял. В итоге получилась никому не нужная какашка. А время идет...

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

Пользователь не знает что он хочет, пока не увидит что он получил...
Время, которое будет потрачено на первичное ТЗ, можно с таким же успехом потратить на набросок чернового варианта. Ну а когда уже конечная задача будет достаточно сформулирована, тогда и можно начинать делать документацию (ТЗ и прочее)...

(44) На небольших задачах это работает. На крупных - не взлетит.

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

(46) Обычно так: собрались, расписали ТЗ. Прикинули, какие дополнительные плюшки можно вытащить из нового функционала. Расписали этапы внедрения. Сделали первый этап - сдали на тестирование. После тестирования откорректировали, внедрили новые "хотелки, дуделки и свистелки". Откорректировали план внедрения следующих этапов. И т.д. Получается, что подробное ТЗ делается на определенный этап. Плюс предварительное ТЗ (представление в общем виде) на весь проект.

Хуже всего работать по ТЗ от бестолковой "прокладки". Чем сейчас и занимаюсь.

(43) Не прог с заказчиком. Прог часто в предметной области ни бум-бум. Консультант прога разговаривает.

Кодер без ТЗ называется "программист"

хотя и не всегда )

Писать ТЗ некогда, а готового нет, поэтому...

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

(9) я так работаю. и не жалею.
потому что уверен : когда фин дир уволится и перейдет в другое место то снова позвонит мне .

(10) +много (даже и добавить нечего)

аутлук, эксель, бумажка вот и все мое ТЗ от юзеров, остальное сам в голове или на листочке.

(53) это всё справедливо, когда у вас объемом знаний программиста покрывается и бизнес и технологии - он там сам себе тогда умелец в одни руки делать всё

но такое есть не везде же


Может же быть и бизнес-требования сложные и технологическая подоплека очень не простой. Что в таком случае будете делать?

(56) это и есть - список требований... по сути - ТЗ

(36) >>ТЗ нужно только программисту, заказчик все равно в немничего не поймет.


тут либо заказчик совсем ничего_не_понимающий, либо вы ему в ТЗ про особенности работы в тонком клиенте пишете


в ТЗ ж надо писать бизнес-хотелки. И тогда они будут заказчику более-менее понятны. Это ж его хотелки, в общем-то.

(57) Повышать свой уровень компетенции.
Встречал, и не раз, тех, кто тупо делал как просили - аргумент - чего вникать, тут дел на 5 минут.
И потом переделки и доделки "недохотелок".
Так же встречал случаи, когда ТЗ описывал уже реализованный функционал. Просто пользователь хотел его видеть "в привычном виде, в привычном месте, так как раньше, так как где-то".
И с соответствующим уровнем компетенции возможно даже исключение реализации ТЗ или ликвидации бесмысленных бизнес-процессов, которые генерят работу для вирус-сотрудников, по сути, не нужных предприятию.