ТЗ — техническое задание, описание задачи для разработчика.

Очень подробное ТЗ — это хорошо или плохо?

Есть разные мнения на этот счёт, ниже я представляю вам моё.

Что делать разработчику если заказчик не даёт чёткое ТЗ?

Это лучшие заказчики, на самом деле.

Хуже нет тех душнил которые катают ТЗ на 100 листов расписывая каждое поле в таблице а потом оно “почему-то” не получается.

Это не исключение из правил, а скорее правило. Видите подробное и тщательно составленное ТЗ со всеми техническими деталями — бегите не оглядываясь.

Каким должно быть ТЗ?

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

Но не все заказчики и даже не все разработчики этому следуют.

Ну а если в компании есть аналитик, который например ставит чёткое ТЗ для аутсорсера, разве это плохо?

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

Аналитики это признак импотенции отдела разработки.

Чем крупнее компания, тем хуже у неë с разработкой, тем сильнее она затыкает эти дыры аналитиками и другими затычками.

Что будет с “чётким ТЗ”?

Разработка “интеграции по чëткому ТЗ от аналитика” на аутсорсе это вообще из области фантастики, в жизни это не работает.

Половина из описанного и реализованного сразу пойдëт нафиг при первой же попытке пристыковаться к системе, сколько бы аналитик перед этим ни пыхтел.

ТЗ может быть ориентиром, черновиком чтобы передать “примерно что мы хотим”. Если следовать этому как железобетонному контракту, ничего не выйдет.

Испытание реальностью без изменений не проходит ни одно ТЗ.

Почему ТЗ не работают?

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

То есть придëтся сделать, или хотя бы начать делать систему чтобы еë правильно описать.

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

Люди которые этого не понимают или не хотят признавать требуют полного описания будущей системы заранее.

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

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

Но если вдруг попадëтся душный бюрократ, который поставит условием полнейшее следование ТЗ, пиши пропало.

Не получается — значит плохо написали ТЗ!

Чтобы полностью описать требования к системе, еë надо сначала создать, и никакой “крутой писака аналитик” или гениальный менеджер или супер опытный разработчик не сможет решить это противоречие.

Если у него нет работающего шара для предсказания будущего, это просто логически невозможно, а кто говорит что возможно, банально врëт или обманывает сам себя.

Как написать ТЗ для программиста на аутсорсе?

1. Сначала ты пишешь что хочешь видеть.

Например список методов API, формат запроса и ответа. Может быть описания структур. Краткие комментарии какое поле что означает.

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

Это и будет твоë первоначальное ТЗ.

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

Фиксируешь и отдаëшь ему в разработку. Это будет утверждëнное ТЗ.

3. Далее остаëшься на связи, отвечая на вопросы, внося корректировки.

4. По итогу вы вместе проверяете и опять корректируете если что-то работает не так как задумывалось.

5. Потом принимаешь работу как есть. Расхождения с первоначальным ТЗ и даже с утверждëнным вполне допустимы.

6. Если необходимо, финальную версию в формате “As Is” заносите в документацию.

На этом всë. Так можно строить работу с аутсорсером, а можно и с внутренними командами.

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