пишет документы SRS, SDD и прочие?

высасывальщик аббревиатур из пальца и прочие

Написал подробнее.

В идеале – всё пишется до начала разработки техрайтером при участии всей команды. IRL - абы как абы кем и хорошо если хоть кто-то, хотя бы тестировщик это прочитает, не говоря уже о других членах команды. Пояснительную записку к диплому читают и то чаще.

Я пишу ТЗ перед стартом разработки. Но это больше защитное планирование: если есть ТЗ, то сразу исчезают веселые менеджеры, которые готовый каждый день требовать «а давай сделаем так!». Нет, не давай. Давай ты лучше выпустишь дополнение к ТЗ, утвердишь его, и только потом девелоперы будут делать то что сказано в дополнении. А пока его нет, извини, но у нас будут работы только в рамках ТЗ и ни как иначе.

Но это подходит не для всех команд и сфер разработки.

+1!

Абсолютно верный подход. Сам от бойцов требую того же. И все разговоры о том, что дескать «а вот Заказчик внезапно захотел...» резко заканчиваются. Дополнение к ТЗ, дополнение к договору, дополнительные деньги. Без этого ни как.

Но это подходит не для всех команд и сфер разработки.

Этот подход работает в случае договорных отношений.

а с почасовой оплатой заказчик сам себя ограничивает в своих хотелках, профит

Я ни чего не скажу про почасовую оплату.

Просто потому, что согласно норм Российского законодательства (попрошу без танцпола, если можно) есть два варианта организации работ.

1 «Трудовой договор». Это Вы устраиваетесь на работу в контору, подписывая этот документ. В этом случае Вы, по сути, продаёте своё время. Т.е., рабочий день с ... по ..., прочие условия (полис ДМС, кофе/чай, печеньки на кухне и спортзал в офисе, ...). За это время Вы получаете свою з/п в размере, прописанном в договоре и исполняете свои обязанности, прописанные в должностной инструкции.

2 Договор гражданско-правового характера (ГПХ), которые очень не любит налоговая. Но в этом случае Вы продаёте только результат своего труда. Оговариваются сроки и объёмы выполнения работ. Конкретные. Всё, что сверх того, всё идёт по отдельным дополнительным документам в виде дополнений и за отдельные деньги.

3 Платить по договору с почасовой оплатой я бы например, не стал, т.к. я бы не стал его даже подписывать. В этом случае я покупаю кота в мешке.

Но в обоих случаях выше (в случае 1 и 2) я могу только приветствовать наличие документов, говорящих что именно должен сделать программист в данном проекте или проектах. Иначе деньги платятся, а за что — не понятно. Поэтому, ТЗ и далее всё как положено, а не как там оно кому-то возжелалось.

+1

А еще ТЗ помогает раскрыть структуру работ и спланировать их, оценить сроки и пр.

Это все понятно. Но кто именно пишет эти документы (больше конечно интересно про srs)? Moisha_Liberman

Пишет тех.пис., а материал готовят бизнес-аналитик, дизайнер, маркетолог, заказчик и т.д.

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

Тонкий вопрос.

Но кто именно пишет эти документы (больше конечно интересно про srs)?

Всё зависит от размеров конторы. Иногда, если контора большая, то есть возможность выделить отдельных людей на это. Иногда тимлид или менеджер проекта (смотря кто именно отвечает за проект). А иногда и сам программист или старший по проекту программист. Это если контора мелкая.

У меня, кстати, последний случай. Мелкая контора. Потому как свой бизнес. Последний раз, когда работал «на дядю», там тимлид такую пургу нёс, что пришлось в итоге послать его по матери и прямым ходом (и, кстати, не мне одному, а всей команде проекта) и сделать всё руками и по уму. Насколько это было возможно не благодаря, а вопреки. «Хотеть» чтобы было «вот так» и как оно реально работает (должно работать) это иногда вещи слабо сопоставимые. В особенности, если за дело берутся чуваки, только-только пришедшие в конкретную предметную область. И пытающиеся рулить по принципу «я начальник, ты дурак». Сейчас этот наш технический гений, насколько я знаю, остался в компании один. Команда в разное время оттуда свинтила.

Ещё один тонкий момент. Это то, что называется подходом к разработке микросервисов. В идеале каждый проект пилит команда, которую можно накормить двумя коробками пиццы. Тогда между ними, внутри команды, будут сильные личностные связи. И все решения будут приниматься в японском стиле. У японцев компания не принимает решений, если решения противоречат взглядам/интересам одного из задействованных лиц. Пока не будет согласия между членами команды. Здесь точно так же. И это крайне важно.

Если «каждый солдат знает свой манёвр», то даже если боец сам себе пишет SRS для своего куска работы, то он на автомате будет его утрясать с остальными участниками команды. Вопросов с интерфейсами и их реализациями не возникает. В итоге SRS всего проекта будут складываться из SRS каждого разработчика. А там уже... У сетевика может быть одно, у спеца по СУБД другое, у математика третье и т.д. и т.п.

Но в любом случае всё начинается с требований Заказчика. Он чего-то хочет, мы думаем как это можно реализовать, показываем выкладки Заказчику, это такой... Итерационный процесс. Потом, когда пришли к согласию, подписали документы, дальше уже ни для кого в команде нет сюрпризов. Остаётся только сесть, да написать.

Как-то вот так. Надеюсь, понятно объяснил.

правильный подход.

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