Интересный кейс, конечно)))). Получается джун один остался на проекте и все пытаешься тащить?))) Тут вопрос закономерный - а оно тебе нужно с таким подходом? М????
Познавательно! Спасибо за статью! После общения с коллегами пришел к выводу, что именно Systems Engineer по большей части является системным аналитиком в нашем понимании. Это если такая роль выделена! Потому что у них немного не так, как у нас.
У них и проджект может выполнять функции БА, а БА уметь в техничку и при этом "СА" не будет заниматься проектированием, не будет иметь овер квалификейт практику в части технологий, как требуют в наших Российских компаниях.
Но при этом знаю кейсы, как наши СА релоцировались на какой-то оверпрайсный рейт в виду отличных хард скиллов))).
Отличный вопрос! Потому что он максимально приближен к реальности и выходит за рамки любых методологий. Да и диагностика не всегда возможна в идеальных условиях. Когда мы говорим о каком-то подходе, то чаще всего рассчитываем на "хеппи пас" т.к. все пограничные ситуации покрыть просто невозможно! Иначе все сводится к борьбе приоритетов.
Если говорить именно о ситуации когда продакт гонит паровоз вперед ради красивого дашборда с метриками, то нужно адаптироваться и менять подход:
1. Диагностируй "на лету". Каждая задача - это возможность задать дополнительные вопросы. Например, это новое требование или доработка старого? Есть ли связь с бизнес-целью? Это не замедляет, а помогает лучше понять контекст.
2. Фиксируй вводные как есть. Если задача пришла из головы продакта - так и фиксируй: источник, дата, статус проработки. Это нужно не для отчетности, а чтобы через две недели не доказывать, что никто этого не уточнял. Это снимает с тебя ответственность за последствия и помогает управлять изменениями без истерик.
3. Документируй фактический процесс, а не идеальный. Раз ты не можешь выстроить структуру заранее, то строй её постфактум. Каждую итерацию фиксируй: откуда пришло изменение, почему оно появилось, что было непонятно на старте. Через несколько недель у тебя получится карта реального процесса требований.
Диагностика хаоса - это не про то, чтобы всех усадить и построить идеальный процесс с предварительным сбором всей информации. Это про то, чтобы даже в хаосе сохранить смысл, связность и управляемость. Адаптируйся!)))))
Собственно в примере нестандартного использования я такой кейс и расписал. Но видимо не очень явно.
Просто пишешь несколько Then и And подряд
Given заказ в статусе «Подтверждён» When пользователь нажимает «Отменить заказ» Then система меняет статус на «Отменён» And шлёт уведомление клиенту And освобождает товары на складе
Если становится слишком громоздко - значит пора разбить на отдельные сценарии.
Да, ты описали абсолютно реальную сторону. Проекты, где "всё как по учебнику", но фича выходит через год. Слепое следование архитектурным заветам без учёта контекста - это такая же ошибка, как и забивание на архитектуру вообще. Поддержу коммент выше - "Гибче нужно быть".
Но и игнорировать явные последствия ради скорости не меньшее зло. Истина где-то между, и именно об этом статья.
Очень годный комментарий, спасибо!))) Бизнес может осознанно выбрать путь "сначала быстро, потом переделаем". И это нормально, если он действительно потом переделывает. Если бизнес готов платить - круто. Тут скорее против иллюзии, что “мы потом всё исправим, когда станет удобно”. Никогда не станет удобно.
Спасибо за комментарий! Он по делу. Реально. Потому что ты прав. Если бизнес ставит цель "налепить за три дня", то никто не будет играться в архитектуру. И правда в том, что не всякая архитектура нужна MVP, и не всегда "чистый код" = полезный код. Для прототипов и одноразовых выстрелов это не нужно.
Но. Как только MVP выжил, многие команды начинаешь платить по счетам. И если архитектура не закладывалась хоть как-то, то дальше проект возникает большой вопрос. И именно об этом статья. О том, что "чуть-чуть неправильно, но пока сойдёт" -> за три спринта превращается в болото. Не про красоту ради красоты. Про выживание на длинной дистанции скорее.
Главное, чтобы подъедать не начало именно то, что было "пофиг, потом поправим")))))
На самом деле софты решают. Без шуток. Проводя тех интервью кандидата я большое внимание обращаю именно на них. А хардам всегда можно научиться очень быстро. В любом случае гугл пока никто не запретил).
Бинго!))) Облака, multi-AZ и другие современные технологии не решают проблему CAP, а лишь предоставляют инструменты для её адаптации.
Это ведь не ограничение, которое нужно "обойти", а фундаментальный принцип, который помогает понять, как работают распределенные системы. Но можно минимизировать последствия выбора. Например, с помощью современных технологий)))))
Добрейший вечер!))) Хм. Очень интересный комментарий. Попробую по пунктам. 1. Здесь на самом деле парадоксальная ситуация. Теоретически они должны выбирать CP, чтобы гарантировать точность данных и избежать продажи одного и того же места нескольким пассажирам. Практически они выбирают AP, чтобы обеспечить высокую доступность и работоспособность в условиях сложных взаимодействий между глобальными и локальными системами. Это как бы не противоречит CAP. Скорее показывает практическое применение.
2. Да, все верно. Многие компании продают билеты сверх лимита на досадку, основываясь на статистике. Здесь двоякая ситуация. С одной стороны бизнес-решение, а с другой можно рассматривать, то фактически является способом адаптации к невозможности обеспечить строгую согласованность в распределённой системе. И демонстрирует, как бизнес-процессы могут дополнять технические решения, чтобы минимизировать последствия ограничений, описанных в теореме CAP.
3. Агась! Но это скорее не опровержение теоремы, а отличная демонстрация, как технологии развиваются. Spanner - отличный пример минимизации ограничений, описанных в CAP. При этом CAP не утверждает, что невозможно достичь всех трех свойств вообще. Теорема говорит, что невозможно гарантировать их одновременно в любых условиях. Spanner достигает всех трех свойств в подавляющем большинстве случаев , но допускает временные потери Availability в экстремальных условиях.
Да, вы правы! Собственно посыл и был в том, что методологию нужно адаптировать под себя. Если взять пример со SMART, то разумно применить Testable, как наиболее подходящее определение. Например, "Система должна генерировать отчет о текучести кадров за последние 12 месяцев в формате PDF".
Но если вернуться к классическому определению SMART, Time-bound может быть частью требований если это требуется бизнес-процессом. Например, "Система должна генерировать ежемесячный отчет о текучести кадров за последние 12 месяцев в формате PDF и отправлять его руководству компании до 5 числа каждого месяца."
Я нашел свое спасение в спорте. Если быть точным, то полноконтактное карате. Уже давно занимаюсь, но на период жесткой депрессии и выгорания из-за ненормированного графика на какое-то время забросил. Как показала практика - зря!)) Теперь 3 раза в неделю в зал и вырабатывать гормон радости через физ нагрузки.
50 лет... Владимир Николаевич, мое уважение! Невероятный опыт! Искренне хотел бы с вами поработать, чтобы чему-то научиться.
Касаемо почты и ответов - к сожалению, это реальность и очень часто работа не отпускает "после работы". Чего стоят релизы, в процессе которых что-то пошло не так.
Сейчас я бодр и полон сил, но еще недавно от такой работы дошел до состояние "сидел и смотрел в стену 4 часа". Было очень скверное состояние. Хотя казалось опытный уже! Должен понимать)))
Ну примерно так, да).
Интересный кейс, конечно)))). Получается джун один остался на проекте и все пытаешься тащить?))) Тут вопрос закономерный - а оно тебе нужно с таким подходом? М????
Познавательно! Спасибо за статью!
После общения с коллегами пришел к выводу, что именно Systems Engineer по большей части является системным аналитиком в нашем понимании. Это если такая роль выделена! Потому что у них немного не так, как у нас.
У них и проджект может выполнять функции БА, а БА уметь в техничку и при этом "СА" не будет заниматься проектированием, не будет иметь овер квалификейт практику в части технологий, как требуют в наших Российских компаниях.
Но при этом знаю кейсы, как наши СА релоцировались на какой-то оверпрайсный рейт в виду отличных хард скиллов))).
Отличный вопрос! Потому что он максимально приближен к реальности и выходит за рамки любых методологий. Да и диагностика не всегда возможна в идеальных условиях. Когда мы говорим о каком-то подходе, то чаще всего рассчитываем на "хеппи пас" т.к. все пограничные ситуации покрыть просто невозможно! Иначе все сводится к борьбе приоритетов.
Если говорить именно о ситуации когда продакт гонит паровоз вперед ради красивого дашборда с метриками, то нужно адаптироваться и менять подход:
1. Диагностируй "на лету". Каждая задача - это возможность задать дополнительные вопросы. Например, это новое требование или доработка старого? Есть ли связь с бизнес-целью? Это не замедляет, а помогает лучше понять контекст.
2. Фиксируй вводные как есть. Если задача пришла из головы продакта - так и фиксируй: источник, дата, статус проработки. Это нужно не для отчетности, а чтобы через две недели не доказывать, что никто этого не уточнял. Это снимает с тебя ответственность за последствия и помогает управлять изменениями без истерик.
3. Документируй фактический процесс, а не идеальный. Раз ты не можешь выстроить структуру заранее, то строй её постфактум. Каждую итерацию фиксируй: откуда пришло изменение, почему оно появилось, что было непонятно на старте. Через несколько недель у тебя получится карта реального процесса требований.
Диагностика хаоса - это не про то, чтобы всех усадить и построить идеальный процесс с предварительным сбором всей информации. Это про то, чтобы даже в хаосе сохранить смысл, связность и управляемость. Адаптируйся!)))))
На здоровье! Хм... В каждом кейсе есть пример и после него шаблон. Посмотрите внимательнее!)
Собственно в примере нестандартного использования я такой кейс и расписал. Но видимо не очень явно.
Просто пишешь несколько
ThenиAndподрядGiven заказ в статусе «Подтверждён»
When пользователь нажимает «Отменить заказ»
Then система меняет статус на «Отменён»
And шлёт уведомление клиентуAnd освобождает товары на складе
Если становится слишком громоздко - значит пора разбить на отдельные сценарии.
Да, ты описали абсолютно реальную сторону. Проекты, где "всё как по учебнику", но фича выходит через год. Слепое следование архитектурным заветам без учёта контекста - это такая же ошибка, как и забивание на архитектуру вообще. Поддержу коммент выше - "Гибче нужно быть".
Но и игнорировать явные последствия ради скорости не меньшее зло. Истина где-то между, и именно об этом статья.
Очень годный комментарий, спасибо!)))
Бизнес может осознанно выбрать путь "сначала быстро, потом переделаем". И это нормально, если он действительно потом переделывает. Если бизнес готов платить - круто. Тут скорее против иллюзии, что “мы потом всё исправим, когда станет удобно”. Никогда не станет удобно.
Но гибкость это да! Это хорошо)
Спасибо за комментарий! Он по делу. Реально. Потому что ты прав. Если бизнес ставит цель "налепить за три дня", то никто не будет играться в архитектуру. И правда в том, что не всякая архитектура нужна MVP, и не всегда "чистый код" = полезный код. Для прототипов и одноразовых выстрелов это не нужно.
Но. Как только MVP выжил, многие команды начинаешь платить по счетам. И если архитектура не закладывалась хоть как-то, то дальше проект возникает большой вопрос. И именно об этом статья. О том, что "чуть-чуть неправильно, но пока сойдёт" -> за три спринта превращается в болото. Не про красоту ради красоты. Про выживание на длинной дистанции скорее.
Главное, чтобы подъедать не начало именно то, что было "пофиг, потом поправим")))))
На самом деле софты решают. Без шуток. Проводя тех интервью кандидата я большое внимание обращаю именно на них. А хардам всегда можно научиться очень быстро. В любом случае гугл пока никто не запретил).
Бинго!))) Облака, multi-AZ и другие современные технологии не решают проблему CAP, а лишь предоставляют инструменты для её адаптации.
Это ведь не ограничение, которое нужно "обойти", а фундаментальный принцип, который помогает понять, как работают распределенные системы. Но можно минимизировать последствия выбора. Например, с помощью современных технологий)))))
Добрейший вечер!)))
Хм. Очень интересный комментарий. Попробую по пунктам.
1. Здесь на самом деле парадоксальная ситуация. Теоретически они должны выбирать CP, чтобы гарантировать точность данных и избежать продажи одного и того же места нескольким пассажирам. Практически они выбирают AP, чтобы обеспечить высокую доступность и работоспособность в условиях сложных взаимодействий между глобальными и локальными системами. Это как бы не противоречит CAP. Скорее показывает практическое применение.
2. Да, все верно. Многие компании продают билеты сверх лимита на досадку, основываясь на статистике. Здесь двоякая ситуация. С одной стороны бизнес-решение, а с другой можно рассматривать, то фактически является способом адаптации к невозможности обеспечить строгую согласованность в распределённой системе. И демонстрирует, как бизнес-процессы могут дополнять технические решения, чтобы минимизировать последствия ограничений, описанных в теореме CAP.
3. Агась! Но это скорее не опровержение теоремы, а отличная демонстрация, как технологии развиваются. Spanner - отличный пример минимизации ограничений, описанных в CAP. При этом CAP не утверждает, что невозможно достичь всех трех свойств вообще. Теорема говорит, что невозможно гарантировать их одновременно в любых условиях. Spanner достигает всех трех свойств в подавляющем большинстве случаев , но допускает временные потери Availability в экстремальных условиях.
Да, вы правы! Собственно посыл и был в том, что методологию нужно адаптировать под себя. Если взять пример со SMART, то разумно применить Testable, как наиболее подходящее определение. Например, "Система должна генерировать отчет о текучести кадров за последние 12 месяцев в формате PDF".
Но если вернуться к классическому определению SMART, Time-bound может быть частью требований если это требуется бизнес-процессом. Например, "Система должна генерировать ежемесячный отчет о текучести кадров за последние 12 месяцев в формате PDF и отправлять его руководству компании до 5 числа каждого месяца."
В погоне за высоким рейтом мы об этом забываем. А зря!)
Я нашел свое спасение в спорте. Если быть точным, то полноконтактное карате. Уже давно занимаюсь, но на период жесткой депрессии и выгорания из-за ненормированного графика на какое-то время забросил. Как показала практика - зря!)) Теперь 3 раза в неделю в зал и вырабатывать гормон радости через физ нагрузки.
50 лет... Владимир Николаевич, мое уважение! Невероятный опыт! Искренне хотел бы с вами поработать, чтобы чему-то научиться.
Касаемо почты и ответов - к сожалению, это реальность и очень часто работа не отпускает "после работы". Чего стоят релизы, в процессе которых что-то пошло не так.
Сейчас я бодр и полон сил, но еще недавно от такой работы дошел до состояние "сидел и смотрел в стену 4 часа". Было очень скверное состояние. Хотя казалось опытный уже! Должен понимать)))