Как научиться писать технические задания для разработчиков?

Question

[kirumit]

Давно работаю с внешними разработчиками. Работаю в страховой компании. Занимаюсь анализом бизнес-процессов. Курирую разработки и внедрении различных систем. От портала и CRM на базе "Битрикс" до медицинских систем "Барс Мед" и CRM Microsoft. Как я ощущаю, профессионального уровня в написании технических заданий для разработчиков я не достиг. В будущем хотел бы пойти в ИТ компанию, бизнес-аналитиком. Подскажите пожалуйста как на практике и быстро научиться писать ТЗ? Чтобы эти знания потом пригадились бы мне в ИТ компании (занимается разработкой и предоставлением ИТ услуг)

Прилагаю отрывок от своего задания.

Comments

[Максим Кузнецов]

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

Answer 1

[Денис Инешин]

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

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

Вот это уже будет понятное всем ТЗ, а не бумагомарание.

Пара программ для создания мокапов вам помощь:
ninjamock.com
https://balsamiq.com/products/mockups/

Comments

[Дмитрий Ларгович]

Денис Инешин Денис Спасибо за ответ!) А можете показать какой-нибудь внятный скриншот со стрелками и т.д.? Хотел бы посмотреть идеальный вариант для изучения.

[Денис Инешин]

Дмитрий Ларгович: тут же нагугил serfery.ru/wp-content/uploads/bystro-sozdayom-skri...

[Дмитрий Ларгович]

Денис Инешин: Спасибо большое!

Answer 2

[Тим]

В ТЗ вообще не должно быть скриншотов. Максимум - блок схемы.
Скриншоты и картинки это не ТЗ, это уже ФЗ - Функциональное задание. Не путайте!

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

ТЗ должно быть лёгким для контроля изменений. Если для внесения изменения вам надо будет менять скриншоты или переписывать целую главу, то вас ожидает каторга и страдание. Я придерживаюсь не более 30 страниц в ТЗ.

Comments

[SergeySpitsin]

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

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

[Тим]

Знаете, я для себя вывел одну закономерность. Чем опытнее разработчик - тем больше он задает вопросов перед принятием задачи. Джунам всегда всё было понятно, и чаще всего они недоделывали или делали немного не то. Если у вас там нет проблем с непониманием то может у вас слабые разработчики?

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

Answer 3

[uvelichitel]

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

• чтобы оно было
  
• чтобы служба заказчика отчетливо понимала хотя бы для себя, чего хочет
  
• чтобы служба заказчика могла связно изложить свои хотелки
  

формальных требований у меня лично нет, но шаблонов полно валяется в сети

Answer 4

[Артём Каретников]

За все программистов я бы лично говорить не стал. Хорошей программой в плане скриншотов еще можно назвать screenpresso. Что касается ТЗ - увы, у вас оно бестолковое. О чем второй пункт? "Если указать ноль, то отобразиТСЯ в сумме ноль".

При выборе товаров с типом "ДМС" следует указывать не только цену в рублях, но и количество. Если количество не указано или равно 0, цена должна быть нулевой.

Похоже на правду? Чуете, в чем разница? Вы описываете то, что вам бизнес говорит. Это не ТЗ, это бизнес-требование. Я написал, как должна себя вести программа.

Comments

[Дмитрий Ларгович]

Да вы правы, я неправильно сформулировал предложения для разработчиков. Спасибо!!!

Answer 5

[Денис Котляров]

Пиши простые условия так ,что мозг сломишь пока поймешь что они от тебя хотят:) (учителя обычно наши так пишут:))

Answer 6

[Андрей Ласточкин]

никто не научился. и тебе не удастся

Answer 7

[074909]

mastertz.ru

Мастер ТЗ - бесплатная программа для создания технических заданий на сайт, программное обеспечение и т.д.
Программа обеспечивает легкое создание профессионального ТЗ в соответствии с ГОСТ.
Возможно редактирование раннее созданного проекта, экспорт результатов в формате HTML и Microsoft Word.
Не требует инсталяции, работает с любого носителя.
Имеется встроеная документация (рекомендации, ГОСТы).

Comments

[Vlad Chernik]

Программа кажется недоделанной...
А в соответствии с каким ГОСТ? Он ведь не один.

[Дмитрий Ларгович]

074909 Здравствуйте. спасибо. На сайте не нашел инфу. Поддерживаю Влада, напишите пжта в соответствии с каким ГОСТОМ?

[074909]

Дмитрий Ларгович: Дело в том, что не я автор программы, и не могу ответить на этот вопрос.