Статья супер! Хотела ещё дополнить: в разных компаниях, конечно, по-разному процесс устроен, но обычно если это не бага, а доработка (т.е. что-то неучтённое в ТЗ), то это уже не тестировщик, а аналитик заводит, предварительно исправляя ТЗ
Очень круто результат! А расскажите, пожалуйста, о том как строился процесс работы непосредственно внутри команды: из статьи понятно какие решения принимались на том или ином этапе, но не очень понятно как к ним приходили и как их воплощали в жизнь
Очень интересная позиция, но звучит как утопия, если честно))
По Причине 1. "Зачем пишут ТЗ?" Тут профит получает не только клиент, но и подрядчик:
Это источник правды для команды - без ТЗ у дизайнера может сложиться одно видение, у разработчика бэка - второе, у iOS/Android - третье и четвёртое, а у QA - пятое. ТЗ решает эту проблему - правда в нём. Как я поняла, у вас в качестве источника правды выступают дизайнеры и проджекты, но странно, что коммуникация внутри команды идёт без них. В таком случае у вас должна быть не только очень сильная команда, но и думающая в одной парадигме)
Это страховка подрядчика: если разработка сделана по согласованному ТЗ, но клиент внезапно говорит, что он хотел иначе - всегда можно показать согласованное ТЗ и провести доработку как платный CR, а не как багу. То что вы пишите далее, что оставляются ссылки на договорённости с клиентом, т.е. "есть доказательства того, о чём мы договорились" - частично решает проблему, но только в рамках договорённостей, которые едва ли охватывают полную функциональность)
По Причине 5. "Пока ты пишешь ТЗ, у клиента все поменялось внутри" Возникает ощущение, что аналитик сначала собирает все требования по всему проекту, а потом садится, и не вставая месяц пишет ТЗ на весь проект) Пока аналитик работает над ТЗ по фиче, он плотно взаимодействует по ней с заказчиком, затем согласовывает с ним же и отдаёт в разработку. Если что-то меняется в процессе написания ТЗ - это сразу учитывается в ТЗ, но это редко бывают изменения вселенского масштаба. Тот же переход на другую CRM не делается за один день, и уж конечно о нём заказчик должен предупредить подрядчика заранее
Приходилось сталкиваться с командами, пытающимися работать примерно по такому сценарию - заканчивалось всё добавлением аналитика и ТЗ на проект) Здорово, что у вас получается, наверное, и правда команда гениев)
Потому что на заголовок "ChatGPT может лагать" скорее кликнут, чем на заголовок "ChatGPT может ошибаться")
Статья супер!
Хотела ещё дополнить:
в разных компаниях, конечно, по-разному процесс устроен, но обычно если это не бага, а доработка (т.е. что-то неучтённое в ТЗ), то это уже не тестировщик, а аналитик заводит, предварительно исправляя ТЗ
Очень круто результат!
А расскажите, пожалуйста, о том как строился процесс работы непосредственно внутри команды: из статьи понятно какие решения принимались на том или ином этапе, но не очень понятно как к ним приходили и как их воплощали в жизнь
И ещё один частый кейс: нам некогда ретро проводить, мы пожары тушим, вот потушим - тогда проведём. Спойлер: полгода жили без ретро
Очень интересная позиция, но звучит как утопия, если честно))
По Причине 1.
"Зачем пишут ТЗ?"
Тут профит получает не только клиент, но и подрядчик:
Это источник правды для команды - без ТЗ у дизайнера может сложиться одно видение, у разработчика бэка - второе, у iOS/Android - третье и четвёртое, а у QA - пятое. ТЗ решает эту проблему - правда в нём.
Как я поняла, у вас в качестве источника правды выступают дизайнеры и проджекты, но странно, что коммуникация внутри команды идёт без них. В таком случае у вас должна быть не только очень сильная команда, но и думающая в одной парадигме)
Это страховка подрядчика: если разработка сделана по согласованному ТЗ, но клиент внезапно говорит, что он хотел иначе - всегда можно показать согласованное ТЗ и провести доработку как платный CR, а не как багу.
То что вы пишите далее, что оставляются ссылки на договорённости с клиентом, т.е. "есть доказательства того, о чём мы договорились" - частично решает проблему, но только в рамках договорённостей, которые едва ли охватывают полную функциональность)
По Причине 5.
"Пока ты пишешь ТЗ, у клиента все поменялось внутри"
Возникает ощущение, что аналитик сначала собирает все требования по всему проекту, а потом садится, и не вставая месяц пишет ТЗ на весь проект) Пока аналитик работает над ТЗ по фиче, он плотно взаимодействует по ней с заказчиком, затем согласовывает с ним же и отдаёт в разработку. Если что-то меняется в процессе написания ТЗ - это сразу учитывается в ТЗ, но это редко бывают изменения вселенского масштаба. Тот же переход на другую CRM не делается за один день, и уж конечно о нём заказчик должен предупредить подрядчика заранее
Приходилось сталкиваться с командами, пытающимися работать примерно по такому сценарию - заканчивалось всё добавлением аналитика и ТЗ на проект)
Здорово, что у вас получается, наверное, и правда команда гениев)