Зарядка для хачапури• 15 декабря 2022
Вопрос к айтишникам и около
Начала работать в продуктовый ит компании, юрист. Вникаю в терминологию, пристаю к ребятам (сейлзам, как правило), но полной инфо для себя не получаю (так, чтобы реализовать в договорах и т.д.), они объясняют по своему и у меня нет общей картины. Понимаю, что для того чтоб лучше разобраться во взаимоотношениях клиент - разработчик, нужны доп.знания. Посоветуйте, плз, какие курсы для этой цели подошли бы (склоняюсь к пм)?
20
0
Често говоря как итшник я вообще не поняла ваш вопрос.курсы чего вы хотите? В чем вы хотите разобраться? Какую полную картину вы не видете?
6
Взаимоотношений клиент - компания. Что есть acceptance criteria, difinition of done, где баг, а где нет и клиент просто морозится платить и т.д.
Ага, примерно поняла. Не знаю, конечно, учат ли этому на курсах пм. Но может быть. Мне так со своей колокольни кажется, что это всё только опыт. Но сейчас курсов миллион на каждый пук. Наверное и такие курсы есть.
Пук не нужен)) нужно понимание процессов, чтоб не дергать лишний раз ребят и преобразовывать их терминологию в свою))
Это все можно загуглить. Не уверена только про клиент-компания, бывает по разному, и наверное юрист должен лучше знать.
Здається ви з мухи слона робите. Вперше чую, щоб юрист заглиблювався в технологічні процеси.
Ви якщо на птахофабрику влаштуєтеся працювати, теж підете на курси технологію виробництва вивчати?
Щоб зрозуміти поняття, які ви перерахували, достатньо Гугла і перекладача
Ви якщо на птахофабрику влаштуєтеся працювати, теж підете на курси технологію виробництва вивчати?
Щоб зрозуміти поняття, які ви перерахували, достатньо Гугла і перекладача
Тут про definition of done
Acceptance criteria - это вам нужно прочитать про user story/use case.
Баг - это не ожидаемое поведение системы, импрувмент - ожидаемое, но требует поправки. За отношения с заказчиком отвечает проджект менеджер или деливери менеджер, за проект- продакт аналитик/продакт оунер. Спрашивайте еще.
Acceptance criteria - это вам нужно прочитать про user story/use case.
Баг - это не ожидаемое поведение системы, импрувмент - ожидаемое, но требует поправки. За отношения с заказчиком отвечает проджект менеджер или деливери менеджер, за проект- продакт аналитик/продакт оунер. Спрашивайте еще.
2
Я коли працювала в агро, то заглиблювалась в процес запліднення корів і якість сперми племінних бичків, бо режим температури, порядок перевезення біоматеріалів мають бути передбачені в договорі та іншій документації. І вважаю це нормальним, бо якщо обслуговуєш певну сферу, повинен розуміти їх хоча б базову специфіку
2
І як вам це допомогло в укладенні договорів/контрактів?
Вам оплачують послуги юриста, а не недо агронома, чи айтівця.
Можна, java, python і хмарні технології піти вивчати, ну так, щоб вже точно баг від фічі відрізнити.
Для якісного виконання вашої роботи достатньо базового (!) розуміння процесів
Вам оплачують послуги юриста, а не недо агронома, чи айтівця.
Можна, java, python і хмарні технології піти вивчати, ну так, щоб вже точно баг від фічі відрізнити.
Для якісного виконання вашої роботи достатньо базового (!) розуміння процесів
А это вопрос какие у компании отношения с заказчиком. Если полностью заказная рвзработка с зеро доверия, то тогда думаю нужен реестр в том или ином виде. В любом случае чем более прозрачнее загруженность команды тем лучше. Именно поэтому так популярны Джиры, скрам митинги типа дейли и демо, и задокументированные и согласованные требования.
Дуже допомогло, бо мы доводили, що при транспортуванніп потім було порушено темп.режим і з придбаної кількості вижила мізерно мала кількість клітин.
Я і запитую про базові розуміння процесів, щоб перекладати їх на юридичну мову.
Я і запитую про базові розуміння процесів, щоб перекладати їх на юридичну мову.
Вот. Просто уже встречала ситуации, где в ходе митингов клиент говорит, что нужно бы поменять логину, хотя уже было утверждено тз, а потом отказывался платить, т.к. продукт не отвечал его ожиданиям. Если б не тот момент, что клиенты все за рубежом, для меня проблемы б не было, я б нашла, как урегулировать, но здесь нужно предусмотреть по максимуму, потому что ни в какой суд в ВБ не пойдем(
Выглядит так, что команда (бизнес-аналитик в частности) не смогли выявить требования клиента, не смогли их нормально описать, согласовать с клиентом, проработать ожидания, подсветить риски и сразу побежали в разработку. Команда потратила время, а оказалось нужно было чуть иначе. Этой ситуации можно избежать максимально прояснив все в начале, а потом еще на митингах корректируя бэклог.
Вы конечно можете прописать контракты, но без нормально выстроенного SDLC - жизненный цикл разработки, есть вероятность с новым клиентом опять попасть в такую же ситуацию.
Вы конечно можете прописать контракты, но без нормально выстроенного SDLC - жизненный цикл разработки, есть вероятность с новым клиентом опять попасть в такую же ситуацию.
1
Ага, спасибо. Я именно о понимании этих процессов говорю.
Ведь одно дело - это вина команды , а бывает и так, что клиент получил желаемое и отморозился. И шлют ему инвойсы в бездну(
Ведь одно дело - это вина команды , а бывает и так, что клиент получил желаемое и отморозился. И шлют ему инвойсы в бездну(
Ну это совсем печальная ситуация((
Еще момент по процессам: их выстраивают. Это не то, что set in stone. В каких-то компаниях даже тикеты не заводят и это никому не мешает. Чем меньше доверия, тем более формальный должен быть процесс утвержения того, что пойдет в разработку, когда это будет сделано и главное зачем? На вопрос зачем отвечает вся команда. Все, от продакта, до тестера держат в голове business value. Иначе на выходе может получится классный продукт, но бесполезный, за который никто не захочет платить. Итог: заказчик фрустрирован, команда выгорела. Не очень.
Еще момент по процессам: их выстраивают. Это не то, что set in stone. В каких-то компаниях даже тикеты не заводят и это никому не мешает. Чем меньше доверия, тем более формальный должен быть процесс утвержения того, что пойдет в разработку, когда это будет сделано и главное зачем? На вопрос зачем отвечает вся команда. Все, от продакта, до тестера держат в голове business value. Иначе на выходе может получится классный продукт, но бесполезный, за который никто не захочет платить. Итог: заказчик фрустрирован, команда выгорела. Не очень.
Мнения, изложенные в теме, передают взгляды авторов и не отражают позицию Kidstaff
Тема закрыта
Похожие темы:
Комментарии к ответу