Комментарии 5
Смущает требование к аналитику знать постман, ладно знать про API в теории, но постман...
И кстати, а где-нибудь учат на аналитика, кроме курсов за 100500 монет?
Так Вы свои UserStory пересмотрите, и на их основе сделайте улучшенное ТЗ)) И вы сами зарываетесь местами, например - "какой резистор должен стоять там-то" - ключевой вопрос. Но недолгий, но, допустим, срочный (напр. - отправляем в производство вечером). И ради него совещание организовывать нет смысла, срочность подразумевает оперативные коммуникации, а это только звонок(потом можно письмо написать, для протокола, когда срочность спадёт). Растягивание коммуникаций - это отстой само по себе.
Лирика про совещания
Совещания съедают всё время совещания у всех участников, прерывают основной контекст, от этого всем грустно (если только они не играют при этом в bullshit bingo). Так что отрыв программиста-архитектора-продакта-проджекта коротким звонком считаю благом, потому как за пару минут основной контекст не выгрузится (особенность человеческого мозга), да ещё обычно и сами эти люди иногда вспоминают, чего хотели спросить у звонящего.
Вы явно перемудрили с критериями отбора. Разбираться в чужом ТЗ - это тоже самое, что разбираться в чужом коде. Проще, легче и лучше сделать своё заново.
Поддерживаю.
Умения читать чужой код - одно из основных умений хорошего программиста.
Аналогично и аналитики - должны уметь читать и анализировать чужое ТЗ.
В конце-концов, ищут аналитика, например, на замену уволившемуся.
А от уволившегося - недоделанная работа осталась, надо продолжить.
Из текста не совсем понял про тестовое ТЗ - это недоделанное другим аналитиком ТЗ, которое надо допилить, попутно указав недостатки, или же имелась ввиду постановка задачи от бизнеса, которую надо довести до разработки и внедрения? Это подразумевает несколько разные навыки...
А как вы ищете аналитика?