Pull to refresh
1
0
Елизавета @Tipchak

User

Send message

Потому что на заголовок "ChatGPT может лагать" скорее кликнут, чем на заголовок "ChatGPT может ошибаться")

Статья супер!
Хотела ещё дополнить:
в разных компаниях, конечно, по-разному процесс устроен, но обычно если это не бага, а доработка (т.е. что-то неучтённое в ТЗ), то это уже не тестировщик, а аналитик заводит, предварительно исправляя ТЗ

Очень круто результат!
А расскажите, пожалуйста, о том как строился процесс работы непосредственно внутри команды: из статьи понятно какие решения принимались на том или ином этапе, но не очень понятно как к ним приходили и как их воплощали в жизнь

И ещё один частый кейс: нам некогда ретро проводить, мы пожары тушим, вот потушим - тогда проведём. Спойлер: полгода жили без ретро

Очень интересная позиция, но звучит как утопия, если честно))

По Причине 1.
"Зачем пишут ТЗ?"
Тут профит получает не только клиент, но и подрядчик:

  1. Это источник правды для команды - без ТЗ у дизайнера может сложиться одно видение, у разработчика бэка - второе, у iOS/Android - третье и четвёртое, а у QA - пятое. ТЗ решает эту проблему - правда в нём.
    Как я поняла, у вас в качестве источника правды выступают дизайнеры и проджекты, но странно, что коммуникация внутри команды идёт без них. В таком случае у вас должна быть не только очень сильная команда, но и думающая в одной парадигме)

  2. Это страховка подрядчика: если разработка сделана по согласованному ТЗ, но клиент внезапно говорит, что он хотел иначе - всегда можно показать согласованное ТЗ и провести доработку как платный CR, а не как багу.
    То что вы пишите далее, что оставляются ссылки на договорённости с клиентом, т.е. "есть доказательства того, о чём мы договорились" - частично решает проблему, но только в рамках договорённостей, которые едва ли охватывают полную функциональность)

По Причине 5.
"Пока ты пишешь ТЗ, у клиента все поменялось внутри"
Возникает ощущение, что аналитик сначала собирает все требования по всему проекту, а потом садится, и не вставая месяц пишет ТЗ на весь проект) Пока аналитик работает над ТЗ по фиче, он плотно взаимодействует по ней с заказчиком, затем согласовывает с ним же и отдаёт в разработку. Если что-то меняется в процессе написания ТЗ - это сразу учитывается в ТЗ, но это редко бывают изменения вселенского масштаба. Тот же переход на другую CRM не делается за один день, и уж конечно о нём заказчик должен предупредить подрядчика заранее

Приходилось сталкиваться с командами, пытающимися работать примерно по такому сценарию - заканчивалось всё добавлением аналитика и ТЗ на проект)
Здорово, что у вас получается, наверное, и правда команда гениев)

Information

Rating
Does not participate
Works in
Registered
Activity

Specialization

Business Analyst, Mobile Analyst
Middle