Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoft

[@gsstroy5347]

Спасибо, Александр, за доклад! Информативно, полезно и ёмко.

[@yaroslavabondarenko9219]

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

[@juv7823]

Благодарю за такую ёмкую, содержательную, полезную лекцию. 🙏

[@ninelvaschenko8088]

Спасибо. Хорошая подача инфо

[@alesiakarpelenia5034]

Спасибо, было интересно и полезно 👍

[@DenisBrilliantov]

Как ты таску сделаеш без чтения?

[@kseniatech]

Топ, спасибо

[@isamstay]

Почему так мало просмотров и комментов? Очень полезная инфа же

[@skifrg]

не продвигает в рф, сам случайно нашел

[@VladiYaX]

Странно, доклад на русском, презентация - на английском... ))

[@fensmart437]

У Александра фамилия = название стартапа. VoiTech.

[@АнтонБеляков-й4п]

не понравилась английская презентация. Докладчик вещает по русски, объясняет по-русски, а презентация английская? тут правильнее и гармоничнее смотрелась бы презентация на русском

[@thevenusproject2915]

Наоборот, изучайте!!!!

[@kovnick]

Хороший доклад о том, как делать аналитику НЕ нужно

[@elenakorolova1224]

а что не так? как нужно?

[@kovnick]

@@elenakorolova1224 требования должны быть максимально абстрагированы от реализации функционала, описывая "как должно работать" и желательно "почему именно так, а не иначе должно работать", а не "что конкретно нужно сделать, чтобы работало, сам догадайся как и почему". очень простой надуманный пример: не валидировать имейл при регистрации на длинну и наличие собачки посредине, а обеспечить валидацию имейла пользователя при регистрации для совместимости с такими-то внешними сервисами, поддреживающими стандарт такой-то отсутсвие информации от том, что именно делать, не будет ограничивать разработчиков в выборе решения, которое подходит для реализации требуемого функционала. а наличие информации о том, почему нужен данный фуцконал именно в таком виде, позволяет разработчикам провалидировать адекватность требований (возможно нужно изменить требования, а не пытаться их реализовать в изначальном виде)

[@alekseykostyuk3806]

Много думаете за разработчиков. Не делайте так никогда. Приходите в команду с проблемой, а не решением. И дайте специалистам делать свое дело.

[@alexandervaitsiakhovich8816]

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

[@Александр-ъ3с3ж]

а что по русски писать тезисы уже не можем ?! хотя бы дублировать их или вы уже там в силиконовой долине себя представляете ?

[@ГлебДолганин]

Из-за того, что преза на английском мне, как не программисту, вообще не понятно в чём отличие в 3 примерах требований. На слайде написано одно, спикер говорит вообще другое. Забавно, что человек, суть работы которого по идее объяснять сложное проще, смог настолько усложнить подачу материала:)

[@ГлебДолганин]

отложу просмотр в долгий ящик и с опытом вернусь, вдруг станет понятнее

[@elenakorolova1224]

подучите ООП и все станет понятно. Чтобы использовать ООП, не нужно быть программистом.