Надо сказать, что тогда это серьёзно подкосило мою и без того просевшую к тому времени мотивацию. Не прошло и года, как я уволился.
Исходя из моего опыта - у вас странная мотивация. Как и у героя статьи. Делать что-то только ради денег.
С моей точки зрения и у вас, и у героя статьи может быть другая мотивация: делать оптимизацию для того, чтобы получать опыт успешной оптимизации. А потом этот опыт можно хорошо продавать в резюме другим работодателям.
Тем более кажется странной ваша мотивация, если у вас должностной инструкцией предусмотрена возможность проведения оптимизации.
А если вам платят за другое, но вам нравится оптимизировать - то может стоит явно обговорить с работодателем желание получать премии за оптимизацию? С примерами успешных оптимизаций.
Просто это странно выглядит. Вы с работодателем об оплате не договорились. Сделали ему хорошо и требуете премию за хорошую работу. А если премии нет (или она ниже ваших ожиданий), то нет смысла работать. Или нет смысла работать хорошо.
Почему нельзя сразу договориться о достойной оплате и работать хорошо?
Причем я бы понял вашу потрею мотивации в случае, если б вы провели за год 5 успешных оптимизаций, пришли за повышением, а вас проигнорировали и не оценили. Тогда вы спокойно со своим опытом найдете того, кто вас оценит.
А по одному случаю делать вывод - для меня это странно. Ну и есть повод задуматься о том, что за такую работу действительно платят не очень много.
У вас есть статистика по другому работодателю, где вы за каждую оптимизацию получили X2 или X3 от месячной экономии?
Разве он попросил? Когда просят - готовы к отказу. Если на отказ обиделись - это было требование.
Не похоже на вин-вин, т.к. с моей точки зрения можно просить либо разовую выплату в 0.4 от месячной экономии, либо три месячных выплаты по 0.2 (ну или по 0.3). И опять же, быть готовым к отказу.
Но это моя мера. Кто-то может считать, что можно просить (или даже требовать) гораздо больше.
Тут ведь вот какое дело: Работы были выполнены в рамках договора. И вместо гипотетических денег получен опыт: сначала договариваемся, потом делаем по договору. И вознаграждение получаем тоже по договору.
Если опыта нет, но сразу хочется договор на самых выгодных условиях по любому случаю -можно нанять юриста и башлять ему процент или фикс (как получится договориться) за грамотное составление договора.
А ходить обиженкой (типа я сэкономил, а со мной не поделились) - ну такое себе.
Но если мало кто умеет его готовить, может не в поваре дело?
Когда я занимался джедайскими техниками, то заметил один удивительный факт. Люди думали, что навык планирования зависит от инструмента.
Пример: У меня проблемы с планированием, а я вижу как хорошо у Васи получается планировать с помощью Jira (или Notion, или Singularity). И начинаю думать, что я научусь планировать так же хорошо как Вася как только начну применять его инструмент.
Только это так не работает. Я не стану хорошим фотографом от того, что куплю себе крутой фотик. Для этого нужно что-то ещё, кроме инструмента, а именно умение увидеть и поймать хороший кадр. И от перехода в Jira у меня не появятся навыки планирования.
Сдается мне, что с декомпозицией та же история. Любой процесс разработки будет идти сложно (хоть ватерфол, хоть скрам), если вы не умеете декомпозировать. Однако я предполагаю, что в скраме проблема с декомпозицией будет лучше видна.
Но многие продолжают думать, что переход на скрам автоматически научит людей декпомозировать/планировать/делать то, что они раньше не умели делать.
И в этом проблема. В ложной связке "я купил пианино - и теперь я классный пианист". Или "Стоит мне перейти на скрам - я сразу стану таким же крутым разрабом как тот чувак"
В целом это основная причина плохой готовки скрама. Что кроме скрама надо знать и уметь много чего, о чем не говорят в силу того, что это сложно и неочевидно. А среднестатистический тренер находится в ложной связке "сейчас введем процедуры дейли, демо и ретро, и тогда научимся всему тому, чего раньше не умели". При этом этот же тренер даже не осознает, что среди навыков, которым надо научиться, может быть умение декомпозировать. И не знает как научить декомпозиции. Но надеется, что на ретро все такие моменты подсветит команда. И та же команда придумает как научить декомпозиции.
(При том какому Опсосу номер принадлежит хз - да и номер как-будто без 1 цифры).
Если номер всё-таки полный и принадлежит РФ, то можно через банковское приложение сбера попробовать определить
Начинаете процедуру пополнения счета номера. После ввода номера банк определяет какому Опсосу он будет переводить деньги.
Дальше можно сходить в этот Опсос и уточнить, это их номер или нет.
В целом принадлежность к опсосу, наверное, можно раскопать через историю переходов междц опсосами. Если начинается с 915, то это был номер МТС-а. Возможно, они дадут информацию, их это номер, или кто-то с ним перешел в другому оператору.
В целом можно сходить ко всем опсосам в регионе прописки и у каждого получить справку, что этот номер вам не принадлежал
Человек может лишь реагировать на события, и принимать решения исходя из существующей информации.
Исходя из моего опыта, человек может освободиться от реактивного поведения. И достаточно большую часть решений принимать не реактивно, а осознанно.
Кроме того, есть возможность выбора реакций. В случае болезни можно отреагировать как фразой "у меня лапки", так и "буду работать пока не свалюсь без памяти". А можно любое из этих решений сделать через осознанный выбор, а не через реакцию.
Выбираю взять больничный и не геройствовать. Или выбираю работать, т.к. ухудшение самочувствия не мешает работать.
Гиперответственность требует осознания и принятия полного контроля над каждым аспектом своей жизни.
Это иллюзия. У вас никогда не будет полного контроля над каждым аспектом своей жизни. Корону снимите. Есть вещи, которые не зависят от вас. Тот же ковид, например.
Я разве говорил, что ваш знакомый богат? Если он сам рожал, как вы сначала написали, то вполне мог получить премию в лимон баксов.
Вы ещё спросите, зачем совершать ошибки. Я вам отвечу, что без них невозможно жить. И вы, и я совершаем ошибки. Совершали и будем совершать. Пока живые.
Насчет результата вопрос открыт. Может его и нет. А может есть, но не видно. Или результат не материальный. Я с ситуацией не знаком, не могу ничего сказать.
Массам предлагается образ "твёрдого, решительного человека", и массы взывают к "наведению порядка жёсткой рукой". В этой небольшой статье я попробую рассказать, почему "жёсткие руководители", как правило, совершенно не нужны вам в вашей коммерческой компании.
Печально, что вы не видите разницы между решительным (антоним - безвольный) и властным (антоним - не желающий демонстрировать свою власть) человеком.
Коммерческой компании как раз нужен твердый и решительный человек, умеющий задать четкие границы и четкие правила. По четким правилам комфортно работать. Четкие границы легко соблюдать.
Начну с главного. На мой взгляд, желание руководителя "навести порядок жёсткой рукой" почти всегда означает не владение представлением о предмете управления, его сложности, и нежелание разобраться в этом. Другими словами, такой руководитель как бы заявляет: "Я некомпетентен, и объект моего воздействия пусть сам опустится на мой уровень".
Это определение (с моей точки зрения), хорошо характеризует властного человека и недалекого человека. Но никак не решительного и твердного.
А если серьезно, то что в такой жизни плохого? Знакомому явно хватает на все его хотелки. Возможно, что он отлично умеет признавать свои ошибки (не отказывается от переезда в Австралию из-за ипотеки, не добивает коленку катанием только из-за наличия комплекта сноуборда хай-класса, не живет с нелюбимой женой ради ребенка).
Вот если бы он раза 3 подряд женился/стал отцом в браке/развелся - можно было бы задуматься о наличии системной ошибки.
Я знаю, что серийное производство и разработка - это разные процессы.
Для меня суть в том, что на серийном производстве заранее известен конечный результат и набор деталей, который нужен для производства. Кроме того, заранее зафиксирован процесс достижения результата: в каком порядке соединять детали, чтобы это занимало меньше времени.
А в разработке может оказаться, что через спринт вы узнали такие детали, из-за которых ваше представление о конечном результате (или о процессе достижения результата) коренным образом изменилось. И тут без гибкости никак.
Суть процесса другая, потому что по сути в разработке вы создаете прототип (или концепт) автомобиля. А потом копипаста сильно облегчает серийное производство.
Поэтому для серийного производства важен налаженый (работающий) конвейр, а для разработки - налаженый процесс Agile.
Только я не понял, что вы хотели сказать.
И за что мне слили карму, кстати, тоже не понял. Но слили явно после того, как я отметился в комментариях под этой статьей.
Т.е. заголовок звучит так: Если ты пришел к команде со своими требованиями к продукту, то Agile невозможен. Но это не так. Контрпример: Аналитик может формулировать прекрасные требования. И дальше команда может реализовывать эти требования по спринтам максимально быстро. И это будет Agile.
Ваш специфичный пример из статьи говорит только о том, что хорошая команда при хреновом аналитике может за счет принципов Agile оперативно выяснить всю хреновость требований. А если требования сформулированы хорошо - как это искоренит Agile?
Дальше вы пишете про согласование (не про формулировку!):
Если требования согласовываются до того, как команда разработки о них узнает, то это точно не Agile.
Это неверно, т.к. выше я уже привел контрпример с нормальным аналитиком и нормальными требованиями.
Дальше в комментарии вы пишете
Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей
Это совсем другая ситуация. Когда на одном планировании распланировали сразу несколько спринтов. 2-6 или больше. И отказываются заниматься перепланированием после завершения первого спринта. Тут я с вами соглашусь, что это не Agile, а имитация. Так как нет гибкости в планировании. Но это совсем о другом. Не то, что вы писали в заголовке. К сформулированным (и согласованным!) требованиям отношения не имеет. И вот здесь я начинаю подзревать, что вы натягиваете сову на глобус.
А вот это совсем из другой оперы:
Ситуация бы изменилась, если бы команде дали возможность предлагать изменения в функционале
Даже если команде не дают предлагать изменения в функционале - это не искоренит Agile, т.к. не является необходимым условием Agile. Внесение изменений со стороны команды может быть приятным бонусом, когда команда достигла нужного уровня зрелости.
Детализация требований командой является необходимым, но не достаточным условием.
Детализировать можно после того, как требования согласованы. С моей точки зрения вы опять говорите не о том, что у вас сформулировано в заголовке и в статье. Детализировать и согласовывать - это совершенно разные процессы.
Поэтому у меня и возник вопрос: что это за магия?
Можете еще раз сформулировать с примером, что вы хотели сказать статьей?
Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей, а затем их передают команде с предложением "давайте в Agile-формате найдем способ сделать это подешевле".
Побуду занудой: в таком процессе предлагаемое вами изменение не изменит сути процесса разработки. Как процесс не был Agile-ом, так он им и не станет.
Agile - это не про поиск самого дешевого решения. Он больше про гибкость (менять продукт в соответствии с новыми требованиями) и возможность добавлять функционал небольшими порциями.
Есть ощущение, что вы по одному случаю (который специфичен для вашей схемы работы, и вам встречается довольно часто), пытаетесь натянуть сову на глобус.
Если для часов не заморачиваться с секундами, то можно вообще одним символом обойтись для отображения четырех знаков.
Для фитнес-браслетов с вертикальным узким экраном может получится неплохой циферблат.
Исходя из моего опыта - у вас странная мотивация. Как и у героя статьи. Делать что-то только ради денег.
С моей точки зрения и у вас, и у героя статьи может быть другая мотивация: делать оптимизацию для того, чтобы получать опыт успешной оптимизации. А потом этот опыт можно хорошо продавать в резюме другим работодателям.
Тем более кажется странной ваша мотивация, если у вас должностной инструкцией предусмотрена возможность проведения оптимизации.
А если вам платят за другое, но вам нравится оптимизировать - то может стоит явно обговорить с работодателем желание получать премии за оптимизацию? С примерами успешных оптимизаций.
Просто это странно выглядит. Вы с работодателем об оплате не договорились. Сделали ему хорошо и требуете премию за хорошую работу. А если премии нет (или она ниже ваших ожиданий), то нет смысла работать. Или нет смысла работать хорошо.
Почему нельзя сразу договориться о достойной оплате и работать хорошо?
Причем я бы понял вашу потрею мотивации в случае, если б вы провели за год 5 успешных оптимизаций, пришли за повышением, а вас проигнорировали и не оценили. Тогда вы спокойно со своим опытом найдете того, кто вас оценит.
А по одному случаю делать вывод - для меня это странно. Ну и есть повод задуматься о том, что за такую работу действительно платят не очень много.
У вас есть статистика по другому работодателю, где вы за каждую оптимизацию получили X2 или X3 от месячной экономии?
Разве он попросил? Когда просят - готовы к отказу. Если на отказ обиделись - это было требование.
Не похоже на вин-вин, т.к. с моей точки зрения можно просить либо разовую выплату в 0.4 от месячной экономии, либо три месячных выплаты по 0.2 (ну или по 0.3). И опять же, быть готовым к отказу.
Но это моя мера. Кто-то может считать, что можно просить (или даже требовать) гораздо больше.
И это тоже можно было бы обсудить.
Тут ведь вот какое дело: Работы были выполнены в рамках договора. И вместо гипотетических денег получен опыт: сначала договариваемся, потом делаем по договору. И вознаграждение получаем тоже по договору.
Если опыта нет, но сразу хочется договор на самых выгодных условиях по любому случаю -можно нанять юриста и башлять ему процент или фикс (как получится договориться) за грамотное составление договора.
А ходить обиженкой (типа я сэкономил, а со мной не поделились) - ну такое себе.
Когда я занимался джедайскими техниками, то заметил один удивительный факт. Люди думали, что навык планирования зависит от инструмента.
Пример: У меня проблемы с планированием, а я вижу как хорошо у Васи получается планировать с помощью Jira (или Notion, или Singularity). И начинаю думать, что я научусь планировать так же хорошо как Вася как только начну применять его инструмент.
Только это так не работает. Я не стану хорошим фотографом от того, что куплю себе крутой фотик. Для этого нужно что-то ещё, кроме инструмента, а именно умение увидеть и поймать хороший кадр. И от перехода в Jira у меня не появятся навыки планирования.
Сдается мне, что с декомпозицией та же история. Любой процесс разработки будет идти сложно (хоть ватерфол, хоть скрам), если вы не умеете декомпозировать. Однако я предполагаю, что в скраме проблема с декомпозицией будет лучше видна.
Но многие продолжают думать, что переход на скрам автоматически научит людей декпомозировать/планировать/делать то, что они раньше не умели делать.
И в этом проблема. В ложной связке "я купил пианино - и теперь я классный пианист". Или "Стоит мне перейти на скрам - я сразу стану таким же крутым разрабом как тот чувак"
В целом это основная причина плохой готовки скрама. Что кроме скрама надо знать и уметь много чего, о чем не говорят в силу того, что это сложно и неочевидно. А среднестатистический тренер находится в ложной связке "сейчас введем процедуры дейли, демо и ретро, и тогда научимся всему тому, чего раньше не умели". При этом этот же тренер даже не осознает, что среди навыков, которым надо научиться, может быть умение декомпозировать. И не знает как научить декомпозиции. Но надеется, что на ретро все такие моменты подсветит команда. И та же команда придумает как научить декомпозиции.
900К - это за период в 5 лет
В пересчете на месяц - 15К
С точки зрения месячной экономии предприятие попадает на 3-ехмесячную экономию. Не слишком ли жирно за 5-и летнюю перспективу?
А может сразу за 100 лет посчитать? Тогда вообще можно будет премию в 20 раз больше попросить.
Добавил бы в соглашение о выполнении работ пункт: фиксированный процент премии за сэкономленные деньги.
Причем готовился бы к тому, что если расходы по каким-нибудь причинам выросли, то с меня компенсация такого же процента.
Бюрократия, да.
На которую наложилась ошибка с номером телефона.
Вам не позавидуешь, но вроде бы докопаться до истины можно. Вопрос в том, сколько ресурсов будет потрачено, и рационально ли это.
да, спасибо за подсказку более просто пути.
Для меня приложение банка более надежно. Я ему большн доверяю.
Если номер всё-таки полный и принадлежит РФ, то можно через банковское приложение сбера попробовать определить
Начинаете процедуру пополнения счета номера. После ввода номера банк определяет какому Опсосу он будет переводить деньги.
Дальше можно сходить в этот Опсос и уточнить, это их номер или нет.
В целом принадлежность к опсосу, наверное, можно раскопать через историю переходов междц опсосами. Если начинается с 915, то это был номер МТС-а. Возможно, они дадут информацию, их это номер, или кто-то с ним перешел в другому оператору.
В целом можно сходить ко всем опсосам в регионе прописки и у каждого получить справку, что этот номер вам не принадлежал
Геморно, но шансы вроде есть
Если у вас есть карта лояльности, то могут звонить представители пятерочки с опросом про магазин. По факту покупки.
Типа "Вы недавно совершали покупку в магазине Эн, оцените качество обслуживания от 1 до 5"
Причем я даже видел в одном из магазинов плакат: Вам могут позвонить.
Исходя из моего опыта, человек может освободиться от реактивного поведения. И достаточно большую часть решений принимать не реактивно, а осознанно.
Кроме того, есть возможность выбора реакций. В случае болезни можно отреагировать как фразой "у меня лапки", так и "буду работать пока не свалюсь без памяти". А можно любое из этих решений сделать через осознанный выбор, а не через реакцию.
Выбираю взять больничный и не геройствовать. Или выбираю работать, т.к. ухудшение самочувствия не мешает работать.
Тут важно понимание меры и субъектная позиция
Разве тут есть выбор?
Ощущение, что в такой ситуации можно лишь сделать вид, что это выбор. Но самого выбора нет.
Поясняющий анекдот о полном контроле над ситуацией
На стройку собирается приехать комиссия. Прораб инструктирует рабочих:
— Что бы ни случилось, делайте вид, что так и должно быть.
Комиссия приехала, осматривает. Вдруг рухнула одна стена. Рабочий, радостно посмотрев на часы:
— Десять тридцать пять. Точно по графику!
Это иллюзия. У вас никогда не будет полного контроля над каждым аспектом своей жизни. Корону снимите. Есть вещи, которые не зависят от вас. Тот же ковид, например.
Я разве говорил, что ваш знакомый богат? Если он сам рожал, как вы сначала написали, то вполне мог получить премию в лимон баксов.
Вы ещё спросите, зачем совершать ошибки. Я вам отвечу, что без них невозможно жить. И вы, и я совершаем ошибки. Совершали и будем совершать. Пока живые.
Насчет результата вопрос открыт. Может его и нет. А может есть, но не видно. Или результат не материальный. Я с ситуацией не знаком, не могу ничего сказать.
Печально, что вы не видите разницы между решительным (антоним - безвольный) и властным (антоним - не желающий демонстрировать свою власть) человеком.
Коммерческой компании как раз нужен твердый и решительный человек, умеющий задать четкие границы и четкие правила. По четким правилам комфортно работать. Четкие границы легко соблюдать.
Это определение (с моей точки зрения), хорошо характеризует властного человека и недалекого человека. Но никак не решительного и твердного.
А за премией в лимон баксов он обращался? :)
А если серьезно, то что в такой жизни плохого? Знакомому явно хватает на все его хотелки. Возможно, что он отлично умеет признавать свои ошибки (не отказывается от переезда в Австралию из-за ипотеки, не добивает коленку катанием только из-за наличия комплекта сноуборда хай-класса, не живет с нелюбимой женой ради ребенка).
Вот если бы он раза 3 подряд женился/стал отцом в браке/развелся - можно было бы задуматься о наличии системной ошибки.
Я знаю, что серийное производство и разработка - это разные процессы.
Для меня суть в том, что на серийном производстве заранее известен конечный результат и набор деталей, который нужен для производства. Кроме того, заранее зафиксирован процесс достижения результата: в каком порядке соединять детали, чтобы это занимало меньше времени.
А в разработке может оказаться, что через спринт вы узнали такие детали, из-за которых ваше представление о конечном результате (или о процессе достижения результата) коренным образом изменилось. И тут без гибкости никак.
Суть процесса другая, потому что по сути в разработке вы создаете прототип (или концепт) автомобиля. А потом копипаста сильно облегчает серийное производство.
Поэтому для серийного производства важен налаженый (работающий) конвейр, а для разработки - налаженый процесс Agile.
Только я не понял, что вы хотели сказать.
И за что мне слили карму, кстати, тоже не понял. Но слили явно после того, как я отметился в комментариях под этой статьей.
Простите, что? Я никак не могу вас понять, т.к. вы каждый раз говорите о разном.
Смотрим заголовок
Т.е. заголовок звучит так: Если ты пришел к команде со своими требованиями к продукту, то Agile невозможен.
Но это не так. Контрпример: Аналитик может формулировать прекрасные требования. И дальше команда может реализовывать эти требования по спринтам максимально быстро. И это будет Agile.
Ваш специфичный пример из статьи говорит только о том, что хорошая команда при хреновом аналитике может за счет принципов Agile оперативно выяснить всю хреновость требований. А если требования сформулированы хорошо - как это искоренит Agile?
Дальше вы пишете про согласование (не про формулировку!):
Это неверно, т.к. выше я уже привел контрпример с нормальным аналитиком и нормальными требованиями.
Дальше в комментарии вы пишете
Это совсем другая ситуация. Когда на одном планировании распланировали сразу несколько спринтов. 2-6 или больше. И отказываются заниматься перепланированием после завершения первого спринта. Тут я с вами соглашусь, что это не Agile, а имитация. Так как нет гибкости в планировании. Но это совсем о другом. Не то, что вы писали в заголовке. К сформулированным (и согласованным!) требованиям отношения не имеет. И вот здесь я начинаю подзревать, что вы натягиваете сову на глобус.
А вот это совсем из другой оперы:
Даже если команде не дают предлагать изменения в функционале - это не искоренит Agile, т.к. не является необходимым условием Agile. Внесение изменений со стороны команды может быть приятным бонусом, когда команда достигла нужного уровня зрелости.
Детализировать можно после того, как требования согласованы. С моей точки зрения вы опять говорите не о том, что у вас сформулировано в заголовке и в статье. Детализировать и согласовывать - это совершенно разные процессы.
Поэтому у меня и возник вопрос: что это за магия?
Можете еще раз сформулировать с примером, что вы хотели сказать статьей?
Побуду занудой: в таком процессе предлагаемое вами изменение не изменит сути процесса разработки. Как процесс не был Agile-ом, так он им и не станет.
Agile - это не про поиск самого дешевого решения. Он больше про гибкость (менять продукт в соответствии с новыми требованиями) и возможность добавлять функционал небольшими порциями.
Есть ощущение, что вы по одному случаю (который специфичен для вашей схемы работы, и вам встречается довольно часто), пытаетесь натянуть сову на глобус.