(При том какому Опсосу номер принадлежит хз - да и номер как-будто без 1 цифры).
Если номер всё-таки полный и принадлежит РФ, то можно через банковское приложение сбера попробовать определить
Начинаете процедуру пополнения счета номера. После ввода номера банк определяет какому Опсосу он будет переводить деньги.
Дальше можно сходить в этот Опсос и уточнить, это их номер или нет.
В целом принадлежность к опсосу, наверное, можно раскопать через историю переходов междц опсосами. Если начинается с 915, то это был номер МТС-а. Возможно, они дадут информацию, их это номер, или кто-то с ним перешел в другому оператору.
В целом можно сходить ко всем опсосам в регионе прописки и у каждого получить справку, что этот номер вам не принадлежал
Человек может лишь реагировать на события, и принимать решения исходя из существующей информации.
Исходя из моего опыта, человек может освободиться от реактивного поведения. И достаточно большую часть решений принимать не реактивно, а осознанно.
Кроме того, есть возможность выбора реакций. В случае болезни можно отреагировать как фразой "у меня лапки", так и "буду работать пока не свалюсь без памяти". А можно любое из этих решений сделать через осознанный выбор, а не через реакцию.
Выбираю взять больничный и не геройствовать. Или выбираю работать, т.к. ухудшение самочувствия не мешает работать.
Гиперответственность требует осознания и принятия полного контроля над каждым аспектом своей жизни.
Это иллюзия. У вас никогда не будет полного контроля над каждым аспектом своей жизни. Корону снимите. Есть вещи, которые не зависят от вас. Тот же ковид, например.
Я разве говорил, что ваш знакомый богат? Если он сам рожал, как вы сначала написали, то вполне мог получить премию в лимон баксов.
Вы ещё спросите, зачем совершать ошибки. Я вам отвечу, что без них невозможно жить. И вы, и я совершаем ошибки. Совершали и будем совершать. Пока живые.
Насчет результата вопрос открыт. Может его и нет. А может есть, но не видно. Или результат не материальный. Я с ситуацией не знаком, не могу ничего сказать.
Массам предлагается образ "твёрдого, решительного человека", и массы взывают к "наведению порядка жёсткой рукой". В этой небольшой статье я попробую рассказать, почему "жёсткие руководители", как правило, совершенно не нужны вам в вашей коммерческой компании.
Печально, что вы не видите разницы между решительным (антоним - безвольный) и властным (антоним - не желающий демонстрировать свою власть) человеком.
Коммерческой компании как раз нужен твердый и решительный человек, умеющий задать четкие границы и четкие правила. По четким правилам комфортно работать. Четкие границы легко соблюдать.
Начну с главного. На мой взгляд, желание руководителя "навести порядок жёсткой рукой" почти всегда означает не владение представлением о предмете управления, его сложности, и нежелание разобраться в этом. Другими словами, такой руководитель как бы заявляет: "Я некомпетентен, и объект моего воздействия пусть сам опустится на мой уровень".
Это определение (с моей точки зрения), хорошо характеризует властного человека и недалекого человека. Но никак не решительного и твердного.
А если серьезно, то что в такой жизни плохого? Знакомому явно хватает на все его хотелки. Возможно, что он отлично умеет признавать свои ошибки (не отказывается от переезда в Австралию из-за ипотеки, не добивает коленку катанием только из-за наличия комплекта сноуборда хай-класса, не живет с нелюбимой женой ради ребенка).
Вот если бы он раза 3 подряд женился/стал отцом в браке/развелся - можно было бы задуматься о наличии системной ошибки.
Я знаю, что серийное производство и разработка - это разные процессы.
Для меня суть в том, что на серийном производстве заранее известен конечный результат и набор деталей, который нужен для производства. Кроме того, заранее зафиксирован процесс достижения результата: в каком порядке соединять детали, чтобы это занимало меньше времени.
А в разработке может оказаться, что через спринт вы узнали такие детали, из-за которых ваше представление о конечном результате (или о процессе достижения результата) коренным образом изменилось. И тут без гибкости никак.
Суть процесса другая, потому что по сути в разработке вы создаете прототип (или концепт) автомобиля. А потом копипаста сильно облегчает серийное производство.
Поэтому для серийного производства важен налаженый (работающий) конвейр, а для разработки - налаженый процесс Agile.
Только я не понял, что вы хотели сказать.
И за что мне слили карму, кстати, тоже не понял. Но слили явно после того, как я отметился в комментариях под этой статьей.
Т.е. заголовок звучит так: Если ты пришел к команде со своими требованиями к продукту, то Agile невозможен. Но это не так. Контрпример: Аналитик может формулировать прекрасные требования. И дальше команда может реализовывать эти требования по спринтам максимально быстро. И это будет Agile.
Ваш специфичный пример из статьи говорит только о том, что хорошая команда при хреновом аналитике может за счет принципов Agile оперативно выяснить всю хреновость требований. А если требования сформулированы хорошо - как это искоренит Agile?
Дальше вы пишете про согласование (не про формулировку!):
Если требования согласовываются до того, как команда разработки о них узнает, то это точно не Agile.
Это неверно, т.к. выше я уже привел контрпример с нормальным аналитиком и нормальными требованиями.
Дальше в комментарии вы пишете
Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей
Это совсем другая ситуация. Когда на одном планировании распланировали сразу несколько спринтов. 2-6 или больше. И отказываются заниматься перепланированием после завершения первого спринта. Тут я с вами соглашусь, что это не Agile, а имитация. Так как нет гибкости в планировании. Но это совсем о другом. Не то, что вы писали в заголовке. К сформулированным (и согласованным!) требованиям отношения не имеет. И вот здесь я начинаю подзревать, что вы натягиваете сову на глобус.
А вот это совсем из другой оперы:
Ситуация бы изменилась, если бы команде дали возможность предлагать изменения в функционале
Даже если команде не дают предлагать изменения в функционале - это не искоренит Agile, т.к. не является необходимым условием Agile. Внесение изменений со стороны команды может быть приятным бонусом, когда команда достигла нужного уровня зрелости.
Детализация требований командой является необходимым, но не достаточным условием.
Детализировать можно после того, как требования согласованы. С моей точки зрения вы опять говорите не о том, что у вас сформулировано в заголовке и в статье. Детализировать и согласовывать - это совершенно разные процессы.
Поэтому у меня и возник вопрос: что это за магия?
Можете еще раз сформулировать с примером, что вы хотели сказать статьей?
Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей, а затем их передают команде с предложением "давайте в Agile-формате найдем способ сделать это подешевле".
Побуду занудой: в таком процессе предлагаемое вами изменение не изменит сути процесса разработки. Как процесс не был Agile-ом, так он им и не станет.
Agile - это не про поиск самого дешевого решения. Он больше про гибкость (менять продукт в соответствии с новыми требованиями) и возможность добавлять функционал небольшими порциями.
Есть ощущение, что вы по одному случаю (который специфичен для вашей схемы работы, и вам встречается довольно часто), пытаетесь натянуть сову на глобус.
Если требования согласовываются до того, как команда разработки о них узнает, то это точно не Agile.
А можете объяснить почему?
Выглядит как карго-культ: "Чтобы был Agile, необходимо ознакомить команду разработки с требованиями до согласования требований. И тогда фичу получиться реализовать за один спринт, а не за 4 (или даже больше, если считать стабилизацию и тестирование)."
К тому же не советую Whoosh, «МТС Юрент» и «Яндекс» ссылаться на нарушения ПДД, санкции за которые и без того уже имеются в КоАП РФ. Тогда получится нарушения правового принципа Non bis in idem («не дважды за одно и то же»).
Предположу, что потребителя услуги "аренда самоката", наказывать будут не за нарушение ПДД. А за то, что во время аренды самоката он допустил административное правонарушение.
Поясню на примере, почему это разные вещи: Если турист совершает административку в чужой стране, то в следующий раз его легко могут развернуть при въезде в эту страну. Потому что не нужны закононепослушные туристы. Чтобы не мешали законопослушным туристам отдыхать.
Но тесты по НФ лучше включить в регресс, т.к. коммит с исправлением по нему или вообще часть НФ могут забыть добавить в релиз. Можно проверять НФ и в середине спринта, а потом его сломают при починке бага где-то еще.
Проверку НФ лучше включить не в регресс, а в предрелизное тестирование. А перед этим не забыть выполнить цикл проверки сразу после разработки.
Регресс - это проверка состояния старого функционала, который уже был в предыдущем релизе.
А чтобы коммит с исправлением НФ не забыли добавить в релиз, нужно не забыть, что жизненный цикл бага завершается не тогда, когда на рабочей станции у разработчика всё работает, а когда баг верифицировали на выпущенной версии продукта.
И что предрелизная стадия тестирования НФ включает в себя верификацию найденных багов.
Все подводные камни, описанные вами, легко обойти зная жизенный цикл разработки продукта. Ощущение, что вы сами старательно раскладываете грабли из-за плохого знания жизненного цикла, а потом героически терпите боль от собранных граблей.
Пример с забытым коммитом как бы намекает на бардак в тестировании и разработке.
Замечание справедливо, если не успевать тестировать НФ до регресса. Обычно оно у нас все-таки протестировано и описано в новых тестах до начала выпуска нового регресса.
Я не совсем понимаю. Вам нравится дублировать работу?
Если вы уже протестировали НФ до начала регресса, то зачем вам повторно заниматься тестированием НФ во время регресса?
Для того, чтобы часть тестов НФ стала регрессом, вы сначала должны выпустить текущий релиз и перейти к следующему циклу разработки НФ. Пока вы текущий релиз не выпустили, НФ текущего релиза отдельно, регресс отдельно. НФ тестируется в первую очередь, и лишь потом приступают к регрессу.
пока у вас нет этой четкой картинки предрелизного тестирования, есть вероятность того, что вы блокирующий баг в НФ найдете после регресса. Т.е. весь регресс проделаете зря.
Конечно, есть лайфхаки типа "баг затрагивает только вот этот кусочек функционала, поэтому переделывать регресс будем только для этого маленького кусочка продукта". Но даже с этим лайфхаком вы все равно будете переделывать то, что можно было не переделывать.
То, что вам редко дают время на второй цикл регресса - не означает, что нет смысла во втором цикле. И может быть имеет смысл выпускать релиз со списком известных багов вместо того, чтобы исправлять баги без надлежащей проверки продукта после исправлений.
Как по мне - тут вводит в заблуждение всё. И нумерация частей (которая может подразумевать порядок выполнения). И то, что вы "тестирование НФ" считаете подмножеством тестов регресса.
С моей точки зрения тестирование НФ можно считать частью предрелизного тестирования. И если говорить про предрелизное тестирование, то тогда можно будет формулировать так:
Тестирование релиза перед выпуском можно делить на две части
Тестирование НФ
Регресс
И выполнять последовательно именно в перечисленном порядке. Потому что как только вы при тестировании НФ нашли ошибку, требующую исправления, так сразу после исправления ошибки у вас новая версия продукта. И для новой версии продукта тоже надо будет выполнить регресс. Поэтому тестирование НФ (вместе с починкой найденных багов и верификацией) выполняют до регресса.
Кроме того, сам регресс может найти блокирующие выпуск релиза ошибки. И тогда придется повторять цикл регресса. По опыту редко удается обойтись одним циклом.
Про количество тестов в ядре регресса можно говорить долго. Обычно это считается по другим метрикам (где-то тут для сокращения количества тестов на регресс надо будет применять техники тест-дизайна). Хотя при расчете учитывается в том числе и доступные ресурсы.
На хабре вроде популярны статьи про борьбу с прокрастинацией.
И эти статьи прекрасно иллюстрируют, почему одни ждут (прокрастинируют), а другие достигают результатов.
Потому что ждущим, например, нужны гарантии успеха. И тут можно писать целый цикл статей как перестать ждать этих гарантий, брать на себя ответственность и начать действовать без таких гарантий.
Итого: для меня это хороший пример из жизни для того, чтобы увидеть разницу между ждущим и действующим. Так что для меня эта статья несет смысл и связана с темой ИТ.
P.S. Для меня интересно наблюдать отношение тру-айтишников к данным статьям. Типа заранее понятно, что там нет успеха. И я вспоминаю историю про создание синего светодиода https://youtu.be/gF1pHmqM1QU И мне кажется, что на примерах из этих статей тру-айтишникам есть чему поучиться.
да, спасибо за подсказку более просто пути.
Для меня приложение банка более надежно. Я ему большн доверяю.
Если номер всё-таки полный и принадлежит РФ, то можно через банковское приложение сбера попробовать определить
Начинаете процедуру пополнения счета номера. После ввода номера банк определяет какому Опсосу он будет переводить деньги.
Дальше можно сходить в этот Опсос и уточнить, это их номер или нет.
В целом принадлежность к опсосу, наверное, можно раскопать через историю переходов междц опсосами. Если начинается с 915, то это был номер МТС-а. Возможно, они дадут информацию, их это номер, или кто-то с ним перешел в другому оператору.
В целом можно сходить ко всем опсосам в регионе прописки и у каждого получить справку, что этот номер вам не принадлежал
Геморно, но шансы вроде есть
Если у вас есть карта лояльности, то могут звонить представители пятерочки с опросом про магазин. По факту покупки.
Типа "Вы недавно совершали покупку в магазине Эн, оцените качество обслуживания от 1 до 5"
Причем я даже видел в одном из магазинов плакат: Вам могут позвонить.
Исходя из моего опыта, человек может освободиться от реактивного поведения. И достаточно большую часть решений принимать не реактивно, а осознанно.
Кроме того, есть возможность выбора реакций. В случае болезни можно отреагировать как фразой "у меня лапки", так и "буду работать пока не свалюсь без памяти". А можно любое из этих решений сделать через осознанный выбор, а не через реакцию.
Выбираю взять больничный и не геройствовать. Или выбираю работать, т.к. ухудшение самочувствия не мешает работать.
Тут важно понимание меры и субъектная позиция
Разве тут есть выбор?
Ощущение, что в такой ситуации можно лишь сделать вид, что это выбор. Но самого выбора нет.
Поясняющий анекдот о полном контроле над ситуацией
На стройку собирается приехать комиссия. Прораб инструктирует рабочих:
— Что бы ни случилось, делайте вид, что так и должно быть.
Комиссия приехала, осматривает. Вдруг рухнула одна стена. Рабочий, радостно посмотрев на часы:
— Десять тридцать пять. Точно по графику!
Это иллюзия. У вас никогда не будет полного контроля над каждым аспектом своей жизни. Корону снимите. Есть вещи, которые не зависят от вас. Тот же ковид, например.
Я разве говорил, что ваш знакомый богат? Если он сам рожал, как вы сначала написали, то вполне мог получить премию в лимон баксов.
Вы ещё спросите, зачем совершать ошибки. Я вам отвечу, что без них невозможно жить. И вы, и я совершаем ошибки. Совершали и будем совершать. Пока живые.
Насчет результата вопрос открыт. Может его и нет. А может есть, но не видно. Или результат не материальный. Я с ситуацией не знаком, не могу ничего сказать.
Печально, что вы не видите разницы между решительным (антоним - безвольный) и властным (антоним - не желающий демонстрировать свою власть) человеком.
Коммерческой компании как раз нужен твердый и решительный человек, умеющий задать четкие границы и четкие правила. По четким правилам комфортно работать. Четкие границы легко соблюдать.
Это определение (с моей точки зрения), хорошо характеризует властного человека и недалекого человека. Но никак не решительного и твердного.
А за премией в лимон баксов он обращался? :)
А если серьезно, то что в такой жизни плохого? Знакомому явно хватает на все его хотелки. Возможно, что он отлично умеет признавать свои ошибки (не отказывается от переезда в Австралию из-за ипотеки, не добивает коленку катанием только из-за наличия комплекта сноуборда хай-класса, не живет с нелюбимой женой ради ребенка).
Вот если бы он раза 3 подряд женился/стал отцом в браке/развелся - можно было бы задуматься о наличии системной ошибки.
Я знаю, что серийное производство и разработка - это разные процессы.
Для меня суть в том, что на серийном производстве заранее известен конечный результат и набор деталей, который нужен для производства. Кроме того, заранее зафиксирован процесс достижения результата: в каком порядке соединять детали, чтобы это занимало меньше времени.
А в разработке может оказаться, что через спринт вы узнали такие детали, из-за которых ваше представление о конечном результате (или о процессе достижения результата) коренным образом изменилось. И тут без гибкости никак.
Суть процесса другая, потому что по сути в разработке вы создаете прототип (или концепт) автомобиля. А потом копипаста сильно облегчает серийное производство.
Поэтому для серийного производства важен налаженый (работающий) конвейр, а для разработки - налаженый процесс Agile.
Только я не понял, что вы хотели сказать.
И за что мне слили карму, кстати, тоже не понял. Но слили явно после того, как я отметился в комментариях под этой статьей.
Простите, что? Я никак не могу вас понять, т.к. вы каждый раз говорите о разном.
Смотрим заголовок
Т.е. заголовок звучит так: Если ты пришел к команде со своими требованиями к продукту, то Agile невозможен.
Но это не так. Контрпример: Аналитик может формулировать прекрасные требования. И дальше команда может реализовывать эти требования по спринтам максимально быстро. И это будет Agile.
Ваш специфичный пример из статьи говорит только о том, что хорошая команда при хреновом аналитике может за счет принципов Agile оперативно выяснить всю хреновость требований. А если требования сформулированы хорошо - как это искоренит Agile?
Дальше вы пишете про согласование (не про формулировку!):
Это неверно, т.к. выше я уже привел контрпример с нормальным аналитиком и нормальными требованиями.
Дальше в комментарии вы пишете
Это совсем другая ситуация. Когда на одном планировании распланировали сразу несколько спринтов. 2-6 или больше. И отказываются заниматься перепланированием после завершения первого спринта. Тут я с вами соглашусь, что это не Agile, а имитация. Так как нет гибкости в планировании. Но это совсем о другом. Не то, что вы писали в заголовке. К сформулированным (и согласованным!) требованиям отношения не имеет. И вот здесь я начинаю подзревать, что вы натягиваете сову на глобус.
А вот это совсем из другой оперы:
Даже если команде не дают предлагать изменения в функционале - это не искоренит Agile, т.к. не является необходимым условием Agile. Внесение изменений со стороны команды может быть приятным бонусом, когда команда достигла нужного уровня зрелости.
Детализировать можно после того, как требования согласованы. С моей точки зрения вы опять говорите не о том, что у вас сформулировано в заголовке и в статье. Детализировать и согласовывать - это совершенно разные процессы.
Поэтому у меня и возник вопрос: что это за магия?
Можете еще раз сформулировать с примером, что вы хотели сказать статьей?
Побуду занудой: в таком процессе предлагаемое вами изменение не изменит сути процесса разработки. Как процесс не был Agile-ом, так он им и не станет.
Agile - это не про поиск самого дешевого решения. Он больше про гибкость (менять продукт в соответствии с новыми требованиями) и возможность добавлять функционал небольшими порциями.
Есть ощущение, что вы по одному случаю (который специфичен для вашей схемы работы, и вам встречается довольно часто), пытаетесь натянуть сову на глобус.
У меня другая точка зрения. Agile - это тот процесс, без которого эффективная разработка невозможна в принципе.
Как без налаженного конвейра сложно собирать автомобили, так без налаженного Agile сложно пилить задачки.
Я бы даже сказал, что вся наша жизнь - Agile. Только в сфере личных проектов, которая гораздо шире сферы разработки ПО.
А можете объяснить почему?
Выглядит как карго-культ: "Чтобы был Agile, необходимо ознакомить команду разработки с требованиями до согласования требований. И тогда фичу получиться реализовать за один спринт, а не за 4 (или даже больше, если считать стабилизацию и тестирование)."
Что это за магия такая?
Предположу, что потребителя услуги "аренда самоката", наказывать будут не за нарушение ПДД. А за то, что во время аренды самоката он допустил административное правонарушение.
Поясню на примере, почему это разные вещи: Если турист совершает административку в чужой стране, то в следующий раз его легко могут развернуть при въезде в эту страну. Потому что не нужны закононепослушные туристы. Чтобы не мешали законопослушным туристам отдыхать.
И это не повторное наказание за одно и то же.
Значит вы находитесь в категории недоверчивых попаданцев :) И этот комментарий не про вас
Проверку НФ лучше включить не в регресс, а в предрелизное тестирование. А перед этим не забыть выполнить цикл проверки сразу после разработки.
Регресс - это проверка состояния старого функционала, который уже был в предыдущем релизе.
А чтобы коммит с исправлением НФ не забыли добавить в релиз, нужно не забыть, что жизненный цикл бага завершается не тогда, когда на рабочей станции у разработчика всё работает, а когда баг верифицировали на выпущенной версии продукта.
И что предрелизная стадия тестирования НФ включает в себя верификацию найденных багов.
Все подводные камни, описанные вами, легко обойти зная жизенный цикл разработки продукта. Ощущение, что вы сами старательно раскладываете грабли из-за плохого знания жизненного цикла, а потом героически терпите боль от собранных граблей.
Пример с забытым коммитом как бы намекает на бардак в тестировании и разработке.
Я не совсем понимаю. Вам нравится дублировать работу?
Если вы уже протестировали НФ до начала регресса, то зачем вам повторно заниматься тестированием НФ во время регресса?
Для того, чтобы часть тестов НФ стала регрессом, вы сначала должны выпустить текущий релиз и перейти к следующему циклу разработки НФ. Пока вы текущий релиз не выпустили, НФ текущего релиза отдельно, регресс отдельно. НФ тестируется в первую очередь, и лишь потом приступают к регрессу.
пока у вас нет этой четкой картинки предрелизного тестирования, есть вероятность того, что вы блокирующий баг в НФ найдете после регресса. Т.е. весь регресс проделаете зря.
Конечно, есть лайфхаки типа "баг затрагивает только вот этот кусочек функционала, поэтому переделывать регресс будем только для этого маленького кусочка продукта". Но даже с этим лайфхаком вы все равно будете переделывать то, что можно было не переделывать.
То, что вам редко дают время на второй цикл регресса - не означает, что нет смысла во втором цикле. И может быть имеет смысл выпускать релиз со списком известных багов вместо того, чтобы исправлять баги без надлежащей проверки продукта после исправлений.
Как по мне - тут вводит в заблуждение всё. И нумерация частей (которая может подразумевать порядок выполнения). И то, что вы "тестирование НФ" считаете подмножеством тестов регресса.
С моей точки зрения тестирование НФ можно считать частью предрелизного тестирования. И если говорить про предрелизное тестирование, то тогда можно будет формулировать так:
Тестирование релиза перед выпуском можно делить на две части
Тестирование НФ
Регресс
И выполнять последовательно именно в перечисленном порядке. Потому что как только вы при тестировании НФ нашли ошибку, требующую исправления, так сразу после исправления ошибки у вас новая версия продукта. И для новой версии продукта тоже надо будет выполнить регресс. Поэтому тестирование НФ (вместе с починкой найденных багов и верификацией) выполняют до регресса.
Кроме того, сам регресс может найти блокирующие выпуск релиза ошибки. И тогда придется повторять цикл регресса. По опыту редко удается обойтись одним циклом.
Про количество тестов в ядре регресса можно говорить долго. Обычно это считается по другим метрикам (где-то тут для сокращения количества тестов на регресс надо будет применять техники тест-дизайна). Хотя при расчете учитывается в том числе и доступные ресурсы.
На хабре вроде популярны статьи про борьбу с прокрастинацией.
И эти статьи прекрасно иллюстрируют, почему одни ждут (прокрастинируют), а другие достигают результатов.
Потому что ждущим, например, нужны гарантии успеха. И тут можно писать целый цикл статей как перестать ждать этих гарантий, брать на себя ответственность и начать действовать без таких гарантий.
Итого: для меня это хороший пример из жизни для того, чтобы увидеть разницу между ждущим и действующим. Так что для меня эта статья несет смысл и связана с темой ИТ.
P.S. Для меня интересно наблюдать отношение тру-айтишников к данным статьям. Типа заранее понятно, что там нет успеха. И я вспоминаю историю про создание синего светодиода https://youtu.be/gF1pHmqM1QU И мне кажется, что на примерах из этих статей тру-айтишникам есть чему поучиться.