Speaker A
Хорошо. Скажите, такой вопрос. Вот заказчик вас просит сделать что-то, да, а ваши разработчики говорят, что это долго, дорого и вообще ерунда. Это не нужно так делать.
Советы по работе с заказчиком и разработчиками при спорных требованиях на собеседовании и в проекте.
Key Takeaways
- Уточняйте у заказчика реальные бизнес-задачи и необходимость каждой фичи.
- Обсуждайте с заказчиком и разработчиками риски, сроки и стоимость заранее.
- Если заказчик настаивает, фиксируйте требования и приоритеты, даже если это сложно для команды.
- Не скрывайте проблемы и изменения от заказчика, информируйте его своевременно.
- Предлагайте альтернативы и варианты решения, чтобы минимизировать потери времени и ресурсов.
Summary
- Как уточнять у заказчика необходимость спорных фич и предлагать MVP.
- Обсуждение рисков и стоимости реализации с заказчиком и разработчиками.
- Что делать, если архитектура не позволяет быстро реализовать желаемую фичу.
- Как вести диалог с разработчиками, если они негативно реагируют на требования заказчика.
- Стратегии переговоров по изменению требований для экономии времени и ресурсов.
- Роль менеджера в транслировании позиции заказчика и управлении ожиданиями.
- Действия при выявлении проблем за несколько дней до релиза.
- Необходимость своевременного информирования заказчика о рисках и изменениях.
- Предложение альтернативных решений и вариантов развития ситуации.
- Важность четкой спецификации и согласования деталей до начала разработки.
Full Transcript — Download SRT & Markdown
Speaker A
Ага. В таких случаях делайте, думаете. Хорошо. В таких случаях на самом деле можно, во-первых, реально как бы уточнить, точно ли нужна вот эта фича. Э-э, которая, мы говорим, может, она вообще не нужна.
Speaker A
Заказчик утверждает, что очень нужна эта фича, да, а разработчики говорят: "Так же никто не делает, это ерунда".
Speaker A
Смотрите, можно, ээ, попробовать сторговаться на MVP, то есть взять какие-то ээ основные, ээ основные части нашей фичи, которые вот прямо критически важны. Мм, а остальное, мм, остальное потом доработать, если с точки зрения, мм, ну вот я думаю, так можно сторговаться в
Speaker A
общем на какой-то про... А если разработчики говорят, что чтобы сделать MVP, там же нужно 90% работы сделать, всю архитектуру менять надо.
Speaker A
Так, именно вот в нашем текущем проекте, чтобы сделать новые MVP, да? Да. Да. Вот приходит заказчик, говорит: "Хочу вот такую вот зелёную кнопку". Разработчики говорят: "Да у нас же все кнопки исключительно круглые и красные, да? А чтобы сделать зелёные,
Speaker A
нам нужно 3 месяца перелопатить архитектуру, подключить три фреймворка". Может, это не нужно делать? А заказчик выверяет, что ему нужна именно вот такая кнопка.
Speaker A
Угу. Так, если мы обходим и не говорим про вариант MVP, сначала нужно как бы реально спросить у нашего заказчика, какую реально вот бизнес-задачу решает вот эта вот зелёная кнопка, потому что, ну, как бы он как бы хочет, но если на уровне вот реально там денег
Speaker A
спросить, что вы хотите, ну, как бы как это будут приносить деньги, возможно, мм, удастся как бы ээ убедить заказчика, что, ну, скорее всего, вот эта кнопка нам не нужна. Вот. Ээ, чего также можно ээ довести до заказчика всё, что сказали
Speaker A
разработчики, то есть вот предварить оценку, что у нас там 90% надо перелопачивать. То есть так рассказать, какие у нас риски есть по стоимости, по срокам, что вот у нас происхо... ну, вот вот так вот сложно будет реализовывать.
Speaker A
Возможно, это тоже повлияет как-то на ээ на мнение заказчика. Хорошо. Вам заказчик говорит, что деньги он вам не покажет, потому что они провели внутреннее исследование и результатом это явилось, что вот нужна именно такая вот зелёная кнопка, да?
Speaker A
А то, что говорят разработчики, по его мнению, так это что такое фиговое приложение написали, что у вас такая плохая архитектура? Сами виноваты.
Speaker A
Ну смотри, те, давайте так. Так, тогда подумаем. Если у нас фича реально как бы, ну, заказчик прямо хочет её и уже не получается, я жизни говорю, не получается стравать, ну тогда, э, хорошо фиксируем ээ стоимость, сроки реализации, какой у
Speaker A
нас приоритет вот этой вот кнопки, возможно, ну, как бы она не самая приоритетная, ну, в каком приоритете мы будем её разрабатывать? Ну и идём уже тогда разрабатывать. Ну, как бы, если заказчик хочет. Ну, как бы это постепенно, скорее всего.
Speaker A
Хорошо. Разработчики бомбятся и говорят о том, что да что же мы будем редко делать? Ну, никто же так не делает.
Speaker A
И называют нас всячески плохими словами. Угу. Говорит: "Как же тебе так?" И всё такое.
Speaker A
Так, ну хорошо. Такая интересная ситуация. Мм, ну смотрите, я бы объяснил так. Ээ, ну, если заказчик это требует, мы уже как бы с ним не договориться. Это как бы его, мм, решение финальное заказчика, то есть это его как бы бизнес-
Speaker A
приоритет, вот эта вот кнопка. Вот. И как бы мы ту работу, которую мы совершаем, это как бы ну наша работа, в общем, ээ, ээ, ну, не прямо вот исполнять то, что у нас требует заказчик. Ну, примерно вот в этом
Speaker A
направлении. То есть где-то можешь подсказать какие-то риски, какие-то ограничения, какие могут у нас встретиться, но по факту как бы мы всё равно не можем, ну, на финальное решение повлиять, потому что это как бы решать заказчик. Вот. Мм.
Speaker A
М. Да. Хорошо. То есть мы транслируем позицию заказчика в итоге разработчикам, да, что он хотел вот эту зелёную кнопку, значит, мы будем делать именно зелёную кнопку.
Speaker A
Нужно, да. Ну, то есть с разработчиками что можно? Ну, ээ, ну да, как бы вот такая задача у нас. Э, не, не все задачи прямо интересные, не все они прямо какие-то, ээ, с точки зрения разработчиков нужные для бизнеса,
Speaker A
но как бы придётся сделать жизнь боль. Понятно. Хорошо. А вот такой момент. Разработчики же в разговоре говорили о том, что они замечательно умеют делать такие же кнопки, но только красные.
Speaker A
Угу. Мы этот аргумент как-то будем использовать будем. Так они А для красных кнопок нужно 90% системы переделывать?
Speaker A
Нет, у нас же архитектура заточена только под красные кнопки. Ну, смотрите, да, то есть если у нас разговор идёт вот с этой стороны, то скорее, да, можно как бы заказчику это тоже рассказать, что вот смотрите, ну, на этапе условно торга за фичу, что
Speaker A
смотрите, вы хотите зелёную, но вот у нас как бы и дешевле и быстрее будет сделать красную кнопку. Вот. Ну, возможно, этот вариант устроит нашего заказчика.
Speaker A
Хорошо. О'кей, понятно. Ещё один кейс. Смотрите, вот у нас есть спецификация. Мы договорились по этой фиче, что делаем в итоге красную кнопку, как мы умеем, да? Вот запустили её в работу и за пару дней до релиза разработчики говорят: "У,
Speaker A
что-то красная-то не получается". Точнее, она получается, она, но она получается исключительно круглая, а не квадратная, как хотел заказчик. Угу. А чтобы сделать квадратную, нам нужно ещё пару месяцев работать. Что будем делать?
Speaker A
Так, хорошо. У нас получается круглая, а не квадратная. Да, он хотел зелёную и квадратную, да, мы с ним договорились на красную и квадратную, а теперь получается, что у нас красная, да, ещё и круглая.
Speaker A
Угу. А чтобы сделать квадратную, как он хотел, нужно ещё пару месяцев. Поэтому выяснили за пару дней до релиза. Пришли разработчики. Ну что-то, а что мы делаем именно вот на этом этапе? Или что можно было бы сделать до, да? Да, да. Что мы, что мы делаем? Вот
Speaker A
вы узнали об этом. Угу. Ну, в первую очередь сходить, да? В первую очередь нужно сходить к заказчику, рассказать ему о такой ситуации. Ну, это в первую очередь, чтобы предупредить, какие у нас уже голову оторвёт немедленно.
Speaker A
Не, ну всё равно нужно как бы о всех вот таких вот ситуациях, которые возникают, о всех рисках. Не нужно это замалчивать, нужно, ну, рассказывать заказчику, потому что как бы это ну очень важно. Вот, э-э, то есть в первую очередь надо к нему сходить, мм,
Speaker A
рассказать, да, какие у нас есть, идём, просто рассказываем, что вот есть такая вот ерунда.
Speaker A
Ага, смотрите, да, то есть слушаем его сейчас ещё раз, ээ, рассказываем, что у нас вот такая ситуация, что, э, какие у нас будут новые сроки, ээ, чего, что ещё можно подумать на этом этапе? Может быть, на этом этапе как-то можно
Speaker A
всё-таки может быть заказчик скажет, что о'кей, там взяла ваша типа разработчиков, давайте сделаем, как вот вы предлагали. Возможно, как бы это будет по срокам быстрее.
Speaker A
Такая ситуация ещё может быть. Мм. Ну самое главное, в общем, от заказчика не скрывать и быстро, мм, как бы ему об этом рассказать. Какой у нас пока какой у нас фактический результат уже на нашей фиче, что мы сделали, сколько там процентов
Speaker A
условно мы сделали, объяснить там причину, почему у нас такое происходит. Ну и самое важное, наверное, предложить варианты, то есть то, что я уже уже сказал, то есть либо, ну, какие вот варианты я вижу, либо как бы мы всё-таки доделаем эту фичу с новыми
Speaker A
сроками, либо возможно вот другой вариант, что мы как бы всё откатываем и делаем, как разработчики нам в самом начале предлагали там красную кнопку сделать.
Speaker A
Хорошо. О'кей, мысль понятна. И ещё один кейс. Такая же ситуация. За 2 дня до релиза разработчики приходят и говорят: "Мы всё сделали, но поскольку окантовка кнопки не была явно прописана, она у нас теперь не из линии сделана, а вот с завитушками". Вот мы это уже сделали. Менять мы не хотим, потому что это долго. Давай ты там сам как-то с заказчиком договоришься.
Speaker A
Угу. Так что будем делать? Что мы будем делать? Мм, ну уже на этом этапе. То есть мы не говорим, что можно было заранее прописать вот какие-то требования по этой окантовке.
Speaker A
Вот это было явно не прописано. Они решили сами по-
Speaker A
Вот это было явно не прописано. Они решили сами по-своему. Оказалось, что это может быть важно. А вам про это смотрите об этом.
Speaker A
Да, нужно, смотрите, посмотреть на требования. То есть реально ли вот вот эта вот окантовка, она влияет на нашу мм фичу или это просто, ну вот такой не очень, ну просто лёгкое визуальное там отклонение какое-то. Если у нас по
Speaker A
нашему макету, который у нас был макет, нам критично, что у нас была именно определённая контовка. М ну тоже идём, естественно, к заказчику, показываем ему фактическую реализацию. Мм, объясняем какой у нас там может быть риск, связанный с этим. Чего? Ну и можно
Speaker A
предложить тоже два варианта. То есть либо мы сейчас дорабатываем, мм, либо вот фиксируем вот это вот как ээ ну согласованное, ну отклонение какое-то.
Speaker A
Так вам заказчик говорит: "Вы мне обещали сделать такое-то, да, вот и делайте, как нужно". Что вы шли ко мне?
Speaker A
Да ещё те сок, которые обещали. Вы обещали, а, ну, мы уже зафиксировали то, что, то есть, смотрите, вы говорите про то, что мы не не фиксировали изначально в требованиях, то, что у нас определённая часть будет или мы его
Speaker A
зафиксировали вот только, да, у него 20 кнопок сделано обычной контовкой, а это двадцать первая кнопка, которая в этом же продукте, в этом же в экране и вто смотрите если у нас переводит, естественно, требования это тоже, а вот разработчики удивили,
Speaker A
да, то смотрите, тогда тут уже скорее больше проблема в разработчиках, то есть То есть, если у нас заказчик, это мы с ним согласовали вот эту оригинальную контовку, в требованиях это было, на макете это было, и тут уже как бы
Speaker A
разработчик разработчики сделали вот не ту окантовку, только вот тут уже разговор не не с этим, ээ, с не заказчиком, а с разработчиком. Ну, естественно, заказчи нужно прийти и рассказать, что у нас такая ситуация случилась, чтобы предупредить о текущей ситуации. Но тут
Speaker A
в первую очередь я бы, наверное, поговорил с разработчиками, то есть показал ещё раз, э, какие у нас есть требования, мм, что они были изначально, что у нас в макете было указано. Ээ и как бы, ну, тогда нужно попросить
Speaker A
всё-таки переделать вот этот ээ макет точнее эту вот кнопку на оригинальную. Ну, естественно, надо предупредить заказчика, что вот такая ошибка произошла и как бы, наверное, заложить ещё побольше времени, чтобы у нас мы зафиксили вот эту вот.
Speaker A
А есть смысл погружать тогда заказчика, если мы сейчас разработчиками? М, думаю, да, потому что у нас же были какие-то зафиксированы сроки, а, мы в них не укладываемся. И раз такая ситуация случилась, нам точно нужно его предупредить, чтобы, ну, о том, что у
Speaker A
нас сроки будут сдвинуты. А может они не будут сделать, может разработчики расскавятся и не будут выходные работать.
Speaker A
Смотри, ну как бы выходные плохо выходить работать. Ээ, но, э, смотрите, если мы, смотрите, если мы изначально, допустим, заложили какой-то буфер, 20%, допустим, времени, разработчики сделали ровно там на, э, сделали так, что у нас буфер этот остался, то можно как бы мм
Speaker A
ну не знаю, ну, всё равно нужно заказчику ээ рассказать, что такая ситуация происходит. И вот за этот буфер времени, если мы допускаем, что у нас он был, но он, скорее всего, должен быть, у нас сроки не сдвинуться, но мы как бы успеем
Speaker A
сделать вот этот буфер, который мы оставили времен. Хорошо. То есть в любом случае случае заказчику рассказываем, что происходит правильно.
Speaker A
Всегда, да? О'кей. Переда слова. Так, Кирилл, можно ты? Да. Да. Супер. Скажи, пожалуйста, ты когда сейчас рассматриваешь вакансии, на что обращаешь внимание? Ну, что для тебя важно?
Speaker A
Да. Ээ, на самом деле, мне важно, чтобы, ну, в первую очередь, ээ, чтобы компания, ну, не было связано с какими-то там ставками там или с казино, потому что такое тоже бывает, потому что мне кажется, чтобы какая-то белая сфера
Speaker A
была. Вот. Чего важно, чтобы мм чего? чтобы в компании был какой-то хотя бы подобие омбординга, чтобы там сразу тебя не бросали на на А вразуру, чтобы чуть-чуть как бы могли ну подрассказать, там ввести в курс дела. Вот что я имею в виду. Так, ну ещё
Speaker A
важно, чтобы мм ну зарплата не задерживалась тоже. Ээ ну просто тоже такое бывает. Ээ чего ещё? Ну и в общем, чтобы какие-то, ну, минимально какие-то процессы были выстроены, условно там скрам, не скрам, там примерно там два-три дветрили спринты. Ну примерно там, чтобы
Speaker A
хотя бы там делик был. А то, ну просто где-то где-то бывает вот я совешиваю где-то там ээ асинхронное взаимодействие в чате там или что-то там вообще никаких А у вас сейчас на каждом проекте индивидуальные условия по коммуникации взаимодейст Нет, не нет нет, просто нет.
Speaker A
У нас на текущем всё нормально. То есть у нас двухнедельные спринты, там делики, типа ретро. Ну просто сейчас я какие места, ну собесился, там типа есть где-то вот что ээ какое-то асинхронное взаимодействие в чате, то есть типа без
Speaker A
деликов толтобе. Дадада. По Угу. Хорошо, поняла. А ещё скажи, пожалуйста, а опыт с дизайнерами у тебя есть, да, на вот на проектах?
Speaker A
Да. То есть дизайнеру обычно я в Фигме, ну, набрасывал какой-то минимальный макет, потом уже, ну, с требования по дизайнудавал дизайнер.
Speaker A
Угу. А дизайн валидировал ты сам или прокт онер? А, Prodct Owner. Ага. Ну, ты при этом мог сказать, да, что здесь вот, не знаю, не по требованиям какая- валидация. Ну, да, да, да. То есть смотри, то есть если есть какие-то,
Speaker A
если если у нас есть требования к дизайну, я иду дизайнеру и потом, ну, я вижу, вижу, что проходит. Ну, как бы, да, естественно, тут надо как бы дизайнеру сказать, что, ну, тут не сходится, ну, и нужно переделать, условно.
Speaker A
Ага. О'кей. Хорошо. А скажи, пожалуйста, обю написано, что на последнем месяц ты разрабатывал UML диаграммы для описания жизненного цикла документа от загрузки инженерам до утверждения. А это ты имеешь в виду, а какой-то бизнес-процесс именно в рамках самолёта? Да, здесь имеется в виду
Speaker A
инженер - это застройщик или типа того? Или это аля процесс согласования твоих артефактов? Так, я надо подсказать. У меня получается я вот как ставь работал в двух проектах снача потом.
Speaker A
И вот то, что ты говоришь, ну это по сути, ну то есть бизнес процесс там согласования документации, это, ну у нас что там инженер какой-то м пользователь там загружает документ там в систему, дальше там у нас маршрут происходит, что
Speaker A
у нас там проверка, согласование, там возврат на доработку, там отждение, в общем. Ну и для этого, естественно, ну я рисовал секвенс там вмеле, чтобы показать, какие у нас сервисы и роли участвуют.
Speaker A
Вот. Ну, ещё активитеграмма, чтобы там отразить, ну, сам жизненный цикл документа. Вот от загрузки, получается, до финального статуса. Да.
Speaker A
Угу. О'кей, хорошо, поняла. А, смотри, дальше у нас есть такие небольшие задачки, о которые мы планируем, что там, ну, в онлайне мы там порассуждаем и так далее. Вот смотри, у нас предметная область. Считаем, что онлайн-кинотеатр ты пользуешься чем? Там
Speaker A
Кинопоиском. Ну, Кинопоиском, да. Ага. Ну вот представь себе, что условно есть кинотеатр, есть сущность контент, аля фильм, да, есть там пользователи кинотеатра и так далее. Вот. И представь себе, что к тебе приходит, ну, продукт или там заказчик и говорит, что нам
Speaker A
нужна фича сделать удобный поиск фильмов. Какие бы ты задал вопросы, уточняющие продукту, ну, заказчику.
Speaker A
Удобный поиск фильмов. Угу. У нас его не было. Да, это удобный поиск. Ну, допустим, что нет у нас, да, сейчас так удобный поиск. Ну, смотри, то есть сначала нам нужно уточнить зачем вообще нам это нужно, то есть зачем это нужно бизнесу? То есть,
Speaker A
наверное, это как-то ээ улучшит ээ, не знаю, улучшит ээ времянахождения пользователя там или удовлетворённости.
Speaker A
Так, потом что именно мы хотим улучшить? То есть быстрее какой-то находить конкретно фильм или там подбирать по интересам, может быть, по категориям там или Угу.
Speaker A
То есть, может быть, нам это вообще нужно для того, чтобы увеличить просмотры вообще по фильмам. Банально может, может у нас пользователи заходят на Кинопоиск, у нас нет поиска вообще и они уходят. Я понимаю, как фильм найти. Потом так к требованиям,
Speaker A
наверное, к поиску я бы спросил, какие у нас должны быть. То есть там по, ну, мы должны сказать по полям. Ну, ну тип, о'кей, то есть не не так. То есть мы должны сказать по названиям, по жанру, там, по актёру, по режиссёру. То есть
Speaker A
вот это вот нам нужно ли вот в поиске вот вот это вот там год, можно, наверное страну.
Speaker A
Это мы так мы уточняем. Дальше нам нужно подумать про сценарий использования. То есть нам нужен только текстовой поиск или вот что сейчас модно, голосовой, а ещё круче какой-нибудь Ий. Поиск. Вот.
Speaker A
Так. Чего? Нужны ли нам фильтры? Нужны ли нам фильтры вообще? М. Так. Сортировка нужна ли нам?
Speaker A
Сортировка, ну по тоже по всем вот этим моментам. М. Так. Ну ещё также можно про наверное про ограничения поговорить. То есть, что мы делаем с м Не, не так, не ограничения какие-то ээ есть у нас какой-то м основной сценарий,
Speaker A
там, Happy Pass там и про какие-то криевые сценарии, какие у нас там альтернативные могут произойти.
Speaker A
Угу. Так, вроде бы что с ходу сказал. А какие тебе, кажется, могут альтернативные произойти? Угу.
Speaker A
Так, третий сценарий. Вот пользователь заходит ээ говорит: "Давай хороший сценарий". То, что у нас пользователь заходит, выбирает там по фильтрам сортирует и у него всё хорошо произошло. То есть всё у него всё супер. Ээ есть какой сценарий ещё, что у
Speaker A
нас по его поиску ничего не найдено. То есть какой-то Угу. задал, не знаю, мм, афганский фильм, не знаю, девяносто пятого года. Его нету такого фильма, к сожалению. Вот чего у нас может какой-то м а у нас могут быть опечатки в нашем э
Speaker A
поиске. Вот опечатки, тогда тоже ничего не у нас не получится. Нам нужно предлагать, ну, для печаток исправление.
Speaker A
Вот. М. Угу. Также у нас может быть такое, что пользователь банально может не знать вообще, что он ищет. И можно ему тогда в этом случае подсказать там по категориям, по жанрам.
Speaker A
Так, ну это в плане можно мм допустим, вот на поиск можно, не знаю, какой-нибудь м кнопку добавить, что вот не знаю, что искать, например, и подсказать ему вот там выдавать какие-то жанры категории, чтобы навести, допустим, что ему нужно.
Speaker A
Вот. Угу. Ну, вроде так, наверное. Угу. Хорошо. Вот. А представь себе, что мы хотим ещё сделать фичу помимо поиска.
Speaker A
Ну, допустим, вот он, не знаю, нашёл фильм или просто поиском или так и хочет добавить его в список, там смотреть позже, чтобы потом вернуться к просмотру. Угу.
Speaker A
Какие бы сущности, ну, атрибуты были у сущности, ну, пускай там, не знаю, watchчлист, назовём её, да, и какая была, какие были бы связи с другими сущностями, ну, с фильмом и с пользователя, например, понял. Так, хорошо. Мы добавляем фильм в
Speaker A
в эти в избранные. Какие сущности у нас там могут быть? Мм. Так, ну смотри, то есть, ну, usеer ID, фильм ID.
Speaker A
Ээ так. Когда мы этот фильм добавили, то есть creat Ага. Так. Чего ещё? А, ну, наверное, так ещё можно статусы какие-то добавить в плане, что, ээ, типа сейчас просматриваю, планирую посмотреть. Посмотрел. уже я вот, ну, связи какие у нас могут быть, у нас
Speaker A
может быть несколько этих, как его, вот ну избранных, да, то есть, посмотри, то есть что я имею в виду, типа у юзера и там в у вишлиста типа один ко многим. То есть у одного юзера может быть много этих
Speaker A
вещестов и этих фильмов, которые можно посмотреть. А один фильм тоже может быть в низких вышлистах. Тоже один к многим.
Speaker A
Также так. Угу. Хорошо. А теперь представь, что пользователь может натыкать несколько фильмов и добавить их в избранное. При этом, ну, допустим, он натыкал три фильма. Два фильма добавились, а добавления одного произошла ошибка, чтобы в апи правильно было бы вернуть в
Speaker A
этом случае. Так, ещё раз. У нас филь юзер выбирает несколько фильмов, и один фильм не добавляется.
Speaker A
Ну да, не смог добавиться. А два добавились. Она можно вернуть условно на запрос какой-то ответ.
Speaker A
имеется в виду, что это одним запросом, да? То есть пришёл запрос на БК, в котором написано там добавить в избранное ID1, ID5, ID 10. Да, этот запрос обрабатывает.
Speaker A
Два не successful, а один с ошибкой. Что нужно вернуть в ответ на запрос? Угу.
Speaker A
Так ну может смотри, то есть либо возвращаем двухсотую с то, что у нас как бы всё круто произошло, но нам нужно для каждого этого прописать для каждого фильма типа статус. То есть у нас ээ он условнос, а где-то у нас он с ошибкой. Или можно
Speaker A
вернуть какую-то ещё, ну, допустим, 207 типа мультистатус, что у нас такая вот ситуация. Или или если нас строго как бы строго либо всё, либо ничего, то четырёхсотую, что у вас ничего, короче, не произошло.
Speaker A
Угу. Угу. А как ты думаешь, какой из этих трёх вариантов? Ну, лучше, хуже. Лучше.
Speaker A
Ага. Ну, если мы хотим м Тактак. Ээ, ну, нам, наверное, лучше, чтобы всё-таки пользователь хотя бы час добавил. То есть полностью то, что прекращать нам не нужно. Скорее всего, более так лояльно будем относиться. Давай тогда, ну, вот лучше м
Speaker A
ну и попроще. Давай тогда просто 200 возвращать и вот прописывать для каждого статус его типа success и error.
Speaker A
Ага. О'кей хорошо поняла. Аа представь себе, что у нас есть сценарий, когда пользователь может в приложении выбрать, ну, пускай подписку, да, на фильмы и её купить, увидеть там длительность, стоимость и её купить. Ну, пускай там, не знаю, с
Speaker A
банковской карты оплатить. Вот, ээ, можешь назвать, какие примерно были бы акторы в этом сценарии? И, ну, примерно позитивный описать и там пару альтернативных, какие бы нужно было учесть.
Speaker A
Так, пользователи подписка и нам нужно, ну, условно условно сиквенс в уме нарисовать. Угу. Так.
Speaker A
А, да, сикнс в уме. Хорошо. Ну, не хочешь, если тебе можно бумажкой? Давай. Уме. В общем, у нас есть чего по акторам? Ну, пользователь, мм, мм, ну, у нас есть веб-интерфейс.
Speaker A
Так, если мы связаным с подпиской, у нас должен быть какой-то, мм, что связано с деньгами, ну, например, платёжный шлюз -э ну или просто банк, какой-то сервис подписок обязательно должен быть у нас.
Speaker A
Вот чего также эти платежи можно ещё авторизовывать, можно внешний сервис, ну, авторизация этих платежей добавить. Позитивный сценарий какой у нас. Ну, пользователь чего? Ну, выбирает подписку, он видит срок и стоимость.
Speaker A
Мм, он подписку подтверждает, ну, подтверждает эту покупку. Вот. Потом у нас оплата. Давай картой. Мм. Платёж у нас успешно подтверждён.
Speaker A
Вот подписка у нас активируется. Пользователю приходит статус success, что подписка сделана. Ну а всё, короче, присутствует в личном кабинете. Есть альтернативные сценарий. Допустим, нашего клиента не хватает денег и карта у нас отклоняется.
Speaker A
Тогда м ну такой сценарий. Вот чего ну показываем пользователю, что нестаточно средств. Если у нас ещё может такой сценарий, что вот пользователь нажал, что вот всё круто, давайте плачу и потом нажать от может допустим нажать отменяю оплату тоже вот
Speaker A
подписка у нас не активируется, получается. И ещё у нас может быть ошибка на стороне платёжного шлюза. вдруг там мм как раз-таки точки не пользуется всё хорошо, а там э не знаю, отрубился интернет, вот как вот часто бывает сейчас, и всё. И тогда не
Speaker A
не проходит никакая подписка. И тоже показываем ошибку. Ну и в этом случае, наверное, надо дать пользователю возможность повторить попытку.
Speaker A
Ага. А что, если, например, у нас прошёл платёж, деньги списались? И вот тут и у нас интернет и пропал. И условно до нашего сервиса с подписками ничего не дошло. Как тебе кажется нужно было бы Понял? Да. Супер. Что нужно добавить?
Speaker A
Давай добавить брокер сообщений здесь, чтобы у нас в аксинхронном формате всё равно как бы дошло, э, чтобы Кавка всё как бы отправила ээ как не ну как бы непонятно когда, но гарантированно доставила пользователю сообщение, что протиск прошла, если
Speaker A
правильно понял. Угу. О'кей, хорошо, спасибо. А так, ну, смотри, что такой кейс. Представь себе, что у тебя есть четыре э задачи, да, и тебе нужно определить порядок, в которых ты будешь над ними работать. Ну, условно, их приоритеты, да. Представь себе, что тебе нужно, есть
Speaker A
задача добавить аватарки пользователей в личном кабинете, а починить критический баг, ну, точнее, есть критический баг, и тебя просят проанализировать, э, точно ли не нужно поменять требования и так далее. В общем, принять участие в подчинке критического бага. Аэ, добавить
Speaker A
возможность выбора тёмно-светлой темы, а, в приложении, а, или улучшить загрузку, ну, пускай результатов поиска, которые у нас уже теперь есть, там на 30%, чтобы пользователь ещё быстрее вываливались результаты.
Speaker A
Угу. Так, ээ хорошо. Так, ещё раз. Аватарки, критичный баг, ээ, улучшить поиск. А третье что было?
Speaker A
А-а, и ээ тему светлую, тёмную выбирать светлую тему. Так, ну я думаю, смотри, светло-тём тему точно мы ставим, ну, ближе к концу.
Speaker A
Первое точно будет критический баг. М потому что он как бы ломает основной типа сценарий и без него, ну, скорее всего, у нас не будет работать нашей системой, и мы будем терять деньги. То есть критический Макс первый.
Speaker A
Второе, скорее всего, улучшение поиска, потому что, ну, это будет банально помогать, в общем, ну, пользователю искать нужный фильм.
Speaker A
Если она быстрее найдёт, он больше задержится на нашем сайте, больше вероятност, что он купит. То есть тоже очень важно. Так, и что у нас остаётся?
Speaker A
Аватарки и тёмная с этого тёмная тема. М, смотри, давай всё-таки тёмная тема, она будет поважнее. Потому что это тоже влияет на удовлетворённость клиента с точки зрения, как ему приятно находиться на сайте, тоже влияет на его время нахождения на сайте. То есть ему
Speaker A
может удобнее ночью смотреть в тёмной. Тоже как бы влияет на деньги. А аватарки вот, наверное, они вообще не влияют. То есть ну на деньги это просто, я не знаю, ну космети косметичные карта изменения не так важно.
Speaker A
Ага. О'кей, хорошо, спасибо. Так, ну, наверное, по задачам всё. А я хотел спросить ещё призмать там есть момент. А как посчитали самый?
Speaker A
Ага. В какой-то момент непел, да, там много. Как посчитали увеличение уменьшение объёма ручных коммуникаций на 40% после внедрения системы контекст чаго внутри строительных документов?
Speaker A
Ага. Смотри, то есть у нас по сути что там было изначально в задаче? То есть у нас ранее, ну, обсуждение документов шло по почте там или в мессенджерах, и у нас информация, ну, терялась, то есть не было привязки, получается, к контексту.
Speaker A
Чего делал я? То есть я уже участвовал в обработке системы этих контекстных чатов, ну, внутри документов, то есть описывал логику, там сценарии, какие там интеграции у нас. В результате, короче, коммуникация, ну, начала происходить прямо в системе в нашей, то есть в
Speaker A
контексте конкретного нашего этого объекта, то есть именно, ну, этого строительного имеется в виду. В общем, метрику считали, ну, оценивали по количеству внешних коммуникаций и условно активности там внутри системы.
Speaker A
Вот. Ну, по обайке смотрели. Это я сколько изменений-то понял. Мне интересно, а как саму метрику это считали? То есть замеряли время в почте реально или время в чате? Как это считали, да? То есть считали, ну просто мм с точки зрения ну опроса, то есть до
Speaker A
этого делали опрос, какая какое количество коммуникаций происходит у нас по почте мессенджеров. И после этого ещё один опрос.
Speaker A
Ну, ещё раз точно такой же. И количество, э, этих коммуникаций уже внутри этого нашего контекстного этого чата вот возросло.
Speaker A
То есть два вопроса пользователей досв. Да. То есть это это фидбек от пользователя, да?
Speaker A
Их их акцент примерно, да? Хорошо, понял. А какую нейронку используете для своих целей? Ну, или в работе?
Speaker A
именно вот в работе на текущем проекте. Ну, для себя в работе на текущем. Смотрите, если там, а, допустим, надо что-то немножко помочь там, ну, под поднабросать для условно сиквен, ну, чтобы банально там deepsка GPT. Вот если там что-то,
Speaker A
допустим, разобраться с с кодом, залезть там, посмотреть, то можно в клоде. Угу. Ну, естественно, вы туда кладите, туда передаёте документы.
Speaker A
Нет, естественно. Нет, естественно, для себя. То есть какую-то чувствительную информацию там про что-то там связано с клиентами естественно я ну не загружают.
Speaker A
Хорошо. У нас вопросы закончились. Вот знатно, у вас есть вопросы какие-то?
Topics:собеседованиеуправление проектамиработа с заказчикомразработка ПОMVPпереговорыуправление рискамитехнический долгкоммуникация в командеспецификация требований
![[IELTS SP2] Sample Answer | DESCRIBE A WORK OF ART — Transcript](https://i.ytimg.com/vi/GQuYabbycTM/maxresdefault.jpg)
