Был опыт совместной работы двух команд из Москвы и Нью-Йорка. В 17 час по Мск созванивались с американцами, рассказать что сделали сами и что им достанется и расходились по домам (рабочий день был строго до 17). Американцы в этот момент только двигались в офис и были способны только запомнить, что им говорят, поэтому созвон был максимально сжатым. Поужинав и отдохнув, менеджеры из Москвы ещё раз созванивались с Америкой, которая уже проснулась, выпила кофе и подгрузила рабочий контекст. А американцы свою «смену» сдавали нам асинхронно, емейлом.
у меня 4 (четыре) загранпаспорта, где имя Валерий написано по четырем разным правилам. "Такой стандарт, другого нет" - говорили мне в МВД, МИД, и ФМС в разные годы. Да, на водительском удостоверении пятый вариант. "Это стандарт", - говорили они
в части управления требованиями? Про РМ ВоК я знаю, но там про другое. А требования?
В таких методологиях подробно расписаны подходы к выявлению требований, их сортировке, выделению приоритетов, противоречий, способов согласования, уточнения и так далее.
Запускать приложение банка и сканировать из него - безопасный, но самый долгий путь. Сканировать можно штатной камерой (если она умеет читать QR). Еще быстрее - читать QR или NFC приложением СБПэй (именно так и называется). Оно маленькое, быстрое, через NFC до 1000 руб вообще не требует подтверждения, а при чтении QR - отпечаток пальца или ПИН экрана. Новость в заголовке именно об этом - что приложение СБПэй подружилось с Сбером.
Увы, точно наоборот. Перевод в пользу физлица должен быть осмысленным для отправителя, т.е. нужно самому сознательно выбрать раздел "переводы" в приложении, руками вбить номер с суммой. Если все это зашить в QR-код или ссылку, то уже завтра мошенники будут печатать липовые квитнции на ЖКУ со своим личным QR и раскидывать по почтовым ящикам в надежде, что каждый второй пенсионер отсканируети нажмет "перевести" не думая
было ли в таком сетапе у вас проблемы отсутствия подробной документации?
Документированием разработанных фичей в данном случае занимался я (как аналитик) скорее по личностным причинам: разработчики были слишком гордые, чтобы записывать за собой, а мне в таком объеме писать было даже в радость. Требования и архитектура/проектирование точно были за мной как за аналитиком. Не могу ответить на вопрос с точки зрения «в таком сетапе» :(
Либо разработчики/тестировщик составлением проектной документации занимались?
Под проектной документацией я понимаю документы управления проектом - планы календарные, управления коммуникациями, риски и пр., что в PMI PMBoK. По поскольку всея команда на ладони, то из «проектной» документации был только беклог/роадмап.
Были ли задачи, когда нужно было доработать сервис, который последний раз версионировали год назад? Как разбирались с этим?
— ну, аналитик, давай объясняй нам, что это и как работало — да это вы же сами писали год назад, вы ведь задокументировали за собой, верно? — вот ты токсик! — ладно, вот описание на уровне функциональности и архитектура, а глубже сами копайте. «Код - лучшая документация», вы же говорили, - «Там все структурировано и понятно»
Есть ощущение, что @fenrrr хотел получить систематизированный ответ, а я скатился до частного случая
Я работал в таком сетапе команды из двух человек: проджект-менеджер, занимающийся в недозагруженное время требованиями и проектированием, два разработчика и тестировщик. Плюсы - экономлю на коммуникациях, когда например внутренний РМ просит аналитика оценить сроки; минусы - отсутствие коллегиального мнения, например, в том же вопросе формулирования сроков ;) А ещё плюс - разнообразие задач защищали от выгорания.
Спасибо за статью! Прекрасный текст. И очень своевременный в конце суетливого года и перед новогодней паузой
Кажется, вы очень специфически понимаете термин "невербально", раз приписываете воображаемым тимлидам пинки, крики и слюни
Любопытно, как комментаторов штормит от видеосвязи
Был опыт совместной работы двух команд из Москвы и Нью-Йорка. В 17 час по Мск созванивались с американцами, рассказать что сделали сами и что им достанется и расходились по домам (рабочий день был строго до 17). Американцы в этот момент только двигались в офис и были способны только запомнить, что им говорят, поэтому созвон был максимально сжатым.
Поужинав и отдохнув, менеджеры из Москвы ещё раз созванивались с Америкой, которая уже проснулась, выпила кофе и подгрузила рабочий контекст.
А американцы свою «смену» сдавали нам асинхронно, емейлом.
Может быть, 70% невербального характерно для менеджеров и лидов? Автор-то не рядовой разраб.
Так отлично, что рано выявили несовместимость
Напоминает скрам-гайд в альтернативной переводе. Он тоже читаем за 10 минут
у меня 4 (четыре) загранпаспорта, где имя Валерий написано по четырем разным правилам. "Такой стандарт, другого нет" - говорили мне в МВД, МИД, и ФМС в разные годы. Да, на водительском удостоверении пятый вариант. "Это стандарт", - говорили они
Лайк!
Можно уточнить, что такое
в части управления требованиями? Про РМ ВоК я знаю, но там про другое. А требования?
жаль нельзя в ответ прикрепить скриншот с моими кешбэками как раз по СБП
Запускать приложение банка и сканировать из него - безопасный, но самый долгий путь. Сканировать можно штатной камерой (если она умеет читать QR).
Еще быстрее - читать QR или NFC приложением СБПэй (именно так и называется). Оно маленькое, быстрое, через NFC до 1000 руб вообще не требует подтверждения, а при чтении QR - отпечаток пальца или ПИН экрана.
Новость в заголовке именно об этом - что приложение СБПэй подружилось с Сбером.
Увы, точно наоборот. Перевод в пользу физлица должен быть осмысленным для отправителя, т.е. нужно самому сознательно выбрать раздел "переводы" в приложении, руками вбить номер с суммой.
Если все это зашить в QR-код или ссылку, то уже завтра мошенники будут печатать липовые квитнции на ЖКУ со своим личным QR и раскидывать по почтовым ящикам в надежде, что каждый второй пенсионер отсканируети нажмет "перевести" не думая
Такой комментарий тянет на статью!
Возможно, на собеседовании задают вопрос в таком виде, чтобы отсеять ответивших на него от тех, кто возмутится формулировкой ;)
Документированием разработанных фичей в данном случае занимался я (как аналитик) скорее по личностным причинам: разработчики были слишком гордые, чтобы записывать за собой, а мне в таком объеме писать было даже в радость.
Требования и архитектура/проектирование точно были за мной как за аналитиком. Не могу ответить на вопрос с точки зрения «в таком сетапе» :(
Под проектной документацией я понимаю документы управления проектом - планы календарные, управления коммуникациями, риски и пр., что в PMI PMBoK. По поскольку всея команда на ладони, то из «проектной» документации был только беклог/роадмап.
— ну, аналитик, давай объясняй нам, что это и как работало
— да это вы же сами писали год назад, вы ведь задокументировали за собой, верно?
— вот ты токсик!
— ладно, вот описание на уровне функциональности и архитектура, а глубже сами копайте. «Код - лучшая документация», вы же говорили, - «Там все структурировано и понятно»
Есть ощущение, что @fenrrr хотел получить систематизированный ответ, а я скатился до частного случая
Рабочие тапки, рабочий ноут и рабочий кофе - это прекрасное
В результате проверки отсеиваются те, кто хуже. Лучшие просто остаются, как в эволюции.
Но это тоже моё частное понимание
Я работал в таком сетапе команды из двух человек: проджект-менеджер, занимающийся в недозагруженное время требованиями и проектированием, два разработчика и тестировщик. Плюсы - экономлю на коммуникациях, когда например внутренний РМ просит аналитика оценить сроки; минусы - отсутствие коллегиального мнения, например, в том же вопросе формулирования сроков ;)
А ещё плюс - разнообразие задач защищали от выгорания.