Хорошо, что требования вообще есть

Ром, привет!

Не дашь мне интервью на тему "что разработчики ждут в постановках, но редко получают"?

Можно попробовать, но честно скажу, у нас через раз аналитик на проектах появляется. Возможно не все смогу ответить :))

А кто вам ставит задачи?

Иногда это эксперты- внутренние заказчики. Эксперты по разным системам, операционкам. Они хотят быть в курсе какие атаки/уязвимости появляются для их систем.

Для внешних заказчиков составляют аналитики. Часто требуется участие и эксперта, и аналитика. Дело в том, что аналитики порой не знают всех нюансов требований заказчиков и деталей защит от угроз. Бывают ситуации, что на демо эксперты хватаются за голову, понимая что заказчику то не нужно, а вот это хорошо, но надо ещё добавить много свистелок и чтобы работало без ненужной шелухи.

Как у вас распределены эксперты и аналитики по проектам? Из-за чего происходит расхождение в показаниях?

Эксперты обычно работают не на проекте, а на определенном семействе ОС и/или типах защит. Все время появляются новые атаки/уязвимости. Эксперты их постоянно ресерчат. Аналитики не всегда в курсе последних угроз и ресерчей. Часто цепочка бывает: заказчик->аналитик->разработчик. Потом происходит затык, и вспоминают про экспертов.

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

Какие частые боли у вашей команды от постановок?

1. Часто мы ничего не знаем о непредвиденных кейсах.
2. Нет требований к логированию. Для нас это особенно критично, чтобы исследовать проблемы заказчика, исследовать алгоритмы поиска и устранения уязвимостей/угроз.
3. Иногда про расширяемость в требованиях нет ни слова. Но проходит месяц и прилетает, что заказчик помимо всего хочет то-то и вот чтоб кофе варили по смс.
4. И вот кстати! Хорошо что затронула это - к сожалению, не всегда во время узнаем об изменениях взаимодействия с продуктом/его новое api, изменениях в смежных модулях.

В каком формате вы обычно получаете задачи?

В основном описание- большое ТЗ.
Чаще всего оно выложено на Вики, на которую ссылаются из трекера (у нас tfs). В трекере кратко суть задачи и более подробно на Вики.

Это удобно?

Вполне удобно. Особенно когда сопровождается скринами, подробными сносками и примерами что же должно получится из этого скопа входных данных. Особенно если пример указан в реальном выходном формате (в нашей специфике это небольшие xml/json/yaml). Нам это невероятно ускоряет и упрощает жизнь; по сути понимаем к чему в итоге стремиться и какую модель/шаблон применить ОПТИМАЛЬНО И (если указано) РАСШИРЯЕМО в будущем.

В Вики можно подключать людей, которые непосредственно обсуждают кейсы и отвечают на вопросы. Это важно :)

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

Ты упоминал, что продукт состоит из нескольких модулей. Вы в документации получаете описание на всю систему или выжимку вашей части?

Ага, все правильно :)
Как правило только наша часть.

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

Насколько тебе важно знать бизнес-контекст и что тебя мотивирует в работе?

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

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

Спасибо за интервью!