Видимо, удешевить товары с одновременным увеличением средней производительности и при незначительном изменении занятости. А получается так, что производительность примерно остаётся на своём месте, а вот занятость уменьшается, да и удешевление готовых товаров не особо заметно, т.к. высвобождаются преимущественно начальные роли, которые ранее обслуживали верхние в задаче создания добавочной стоимости.
Если бизнес такое устраивает, то почему бы нет? Сделать по нормальному сейчас будет примерно на столько дольше, насколько дольше было бы сделать изначально, зато фирма работает уже сейчас. Если на это исправление не выделяют ресурсов, значит еще не пришла пора.
Почему ТЗ не может быть на уровне отдельных сторей? Вполне может. Главное что бы было прописано все, касающееся доработки. Не обязательно, что бы был том “войны и мира”.
Совмещение ролей - это хорошо. Но важно понимать: если есть ТЗ, то фактически систему проектируют разработчики этого ТЗ (на основе интервью по сбору требований и т.п. соображений). У тех, кто будет использовать ТЗ тоже может быть существенный вклад, но поскольку выйти за рамки ТЗ они не могут, то какой бы хитрой разработанная система ни была внутри, снаружи она будет вести себя как описано в ТЗ. Если же ТЗ нет, -то результат ХЗ-, то разрабатывает систему тот, кто её шатает (разработчик, программист, админ и т.п.).
Для нормального Agile достаточно UserStory, написанной на салфетке или стикере. Но там и аналитики не нужны - их роль выполняют исполнители.
В принципе, все, что вы перечислили - должно быть в ТЗ по ГОСТУ. Если ТЗ делалось нормально, а не формально, то принципиальных ошибок там не должно быть. А мелких сложно избежать.
Итеративная/Agile разработка это хорошо и это отдельная история. Но не стоит называть User Story техническим заданием. Это разные документы. Равно как не стоит путать совместную разработку ТЗ с регулярным исправлением ошибок аналитиков разработчиками (такие аналитики и не нужны).
Статья немного сумбурная - кажется, её надо было разбить на две. Первая - про спорное отношение к ТЗ. Вторая с мемуарами и чеклистом.
По отношению к ТЗ: если писать ТЗ нормально, по ГОСТу, то обсуждений никаких не требуется. Там и так должно быть все подробно и понятно описано. Если разраб бросился писать код на низкоуровневом ЯП с первых строчек, то это его проблема.
Во всяком случае “аналитик написал ТЗ, а теперь обсудите и поспорьте о нем” - это очень странный подход. Такое можно говорить об эскизе ТЗ на каком-то промежуточном этапе сбора требований. Но о готовом ТЗ, за которое аналитик расписался?
К слову, в не функциональные требования почему-то брошены и функциональные (точнее, их нюансы, которые должны быть расписаны вместе с этими ФТ).
Вы читали описание https://github.com/adriancable/eternal/blob/main/docs/napkin.md ? Возможно, автору статьи имело бы смысл её перевести. Вкратце, идея о примитивной виртуальной машине, имеющей посимвольный последовательный ввод-вывод, цветной TrueColor экран 800x512, возможность узнавать текущее время по запросу изнутри виртуальной машины, и ещё какое то странное немаскируемое прерывание, принцип и назначение работы которого из описания совсем непонятно.
Вообще, идея очень интересная.
Там, конечно, есть косяки. Например, я так понимаю, что символы, получаемые из портов ввода-вывода - это ASCII. Возможно, автору проекта стоило бы привести таблицу таких символов. Потом, хорошо бы какой-то глоссарий и примеры цветов (я опускаю идею, что возможно “human” тогда не будет, а у тогдашних разумных существ будут органы чувств, не распознающих привычный нам спектр). Возможно, с глоссарием понятия адреса и описание прерываний было бы более понятно. Без этого данное описание - это просто какая-то шутка “для немногих причастных” :)
Против этого есть правило, что аудит таких систем должны осуществлять другие админы. Ну а дальше вопрос политический: требовать соблюдения этого или нет?
Единственно, за кадром остались вопросы, касающиеся бюджетов. В данной схеме Продукт тратит бюджет инфраструктурной команды в виде выделенного человека на взаимодействие с иннерсорс командой и на архитектурное ревью и обеспечение качества. Если будет слишком много таких иннеррсорс команд, то как компания будет решать вопрос увеличения бюджета инфраструктурной команды?
По сути, этот ваш иннерсорсинг - это понятный процесс Дискавери (в т.ч. с точки зрения ограничений/архитектуры общего сервиса, а также решений QA) и Деливери. Выделены постоянно или выделяются под проект отдельные ресурсы на архитектурное и код ревью, на подготовку решения в коде. Эти ресурсы ограничиваются для использования. Где естественным образом (т.к. больше разработчиков, чем есть в иннерсорс-команде, Продукт “сожрать” не сможет), а где - за счёт договоренностей (SLA и т.п.).
Текущий формат PKI в целом давно уже пора пересматривать и уходить от централизации, в т.ч. из-за таких рисков.
Да, причём решение на поверхности. Нужно просто иметь возможность ограничивать каждый корневой сертификат дополнительно к тем ограничениям, которые в нём самом уже есть. К примеру, ограничивать возможность зимбабвийским корневым CA возможность заверять сертификаты в зоне .uy. Технически, такая возможность, вроде, есть уже сейчас, но для обычных пользователей возможность настройки этого никто не реализует.
Непонятно только, как обеспечивать валидацию.
Тут непонятен вопрос. Если речь про то, каким корневым сертификатам доверять, как обычно - доверянием определённому набору сертификату, которому доверяет ваш гуру (или: монарх, президент, генсек и т.п.).
Упустил по мере повествования: началось с того, что локальные KPI тормозили общий прогресс, а в конце что с этими KPI сделали? Они остались те же, но уже не тормозят, или как?
Ну, аналогия с поездом тут натянутая. У начальника поезда и у проводника вагона есть свои полномочия и ответственность. У машиниста - свои. У дежурной по станции и поездного диспетчера - свои. У путевых рабочих и инженеров - другие. Точки их взаимодействия описаны в толстенных инструкциях, и да, там иногда возникают накладки, как в том случае, когда дежурная приказала срочно отправляться, а проводники дёрнули стоп-кран и в поезд влетел потерявший управление состав.
Но у них у всех есть общее начальство. Если оно пожелает изменить проблемные места, то изменит, и никаких ДМ тут не нужно. А если нет, то будь там десять ДМ (если учитывать поездную аналогию, - это некий “заместитель по улучшению процессов/по научной организации труда” некоего наименьшего общего начальника), ничего не сдвинется - как раз потому что у каждого есть свои чётко прописанные обязанности, в т.ч. не только перед инструкцией, но и перед законом.
… А ещё можно в ТЗ просто поставить требование минимизации влияния на водителей (либо прямо так, либо расписать, “оцифровав” с помощью соответствующих метрик).
Если у РП только “свои бригады и задачи”, то это по определению не РП. Основная задача РП - довести конкретный проект до завершения. И у него должна быть возможность, в частности, заменить бригаду “пьющих” на нормальную, иначе, опять же, он никакой не РП.
А Delivery Manager отвечает за то, чтобы стройка в целом не остановилась.
Т.е когда видишь какой-то долгострой с “обманутыми дольщиками”, то это виноват DM, а не тот, кто направил средства “куда-то не туда”, либо начал строительство без надежды на завершение. Здорово, что дома строят пока ещё не по Agile
А если серьёзно, то кейсы интересные, но ещё раз подчёркивают мысль, что необходимость в DM - это следствие провала в каком-то отдельном месте процесса.
Видимо, удешевить товары с одновременным увеличением средней производительности и при незначительном изменении занятости. А получается так, что производительность примерно остаётся на своём месте, а вот занятость уменьшается, да и удешевление готовых товаров не особо заметно, т.к. высвобождаются преимущественно начальные роли, которые ранее обслуживали верхние в задаче создания добавочной стоимости.
Не все пассажиры в вашем авто оплатили функцию “Быстрота”, скорость ограничена до 90 км/ч
Смотря какой fabric, смотря сколько details
С одной стороны, верно, а с другой стороны, у провода и радио просто разные риски. И получается, что провод и радио друг друга резервируют.
Если бизнес такое устраивает, то почему бы нет? Сделать по нормальному сейчас будет примерно на столько дольше, насколько дольше было бы сделать изначально, зато фирма работает уже сейчас. Если на это исправление не выделяют ресурсов, значит еще не пришла пора.
Почему ТЗ не может быть на уровне отдельных сторей? Вполне может. Главное что бы было прописано все, касающееся доработки. Не обязательно, что бы был том “войны и мира”.
Совмещение ролей - это хорошо. Но важно понимать: если есть ТЗ, то фактически систему проектируют разработчики этого ТЗ (на основе интервью по сбору требований и т.п. соображений). У тех, кто будет использовать ТЗ тоже может быть существенный вклад, но поскольку выйти за рамки ТЗ они не могут, то какой бы хитрой разработанная система ни была внутри, снаружи она будет вести себя как описано в ТЗ. Если же ТЗ нет, -то результат ХЗ-, то разрабатывает систему тот, кто её шатает (разработчик, программист, админ и т.п.).
Для нормального Agile достаточно UserStory, написанной на салфетке или стикере. Но там и аналитики не нужны - их роль выполняют исполнители.
В принципе, все, что вы перечислили - должно быть в ТЗ по ГОСТУ. Если ТЗ делалось нормально, а не формально, то принципиальных ошибок там не должно быть. А мелких сложно избежать.
Итеративная/Agile разработка это хорошо и это отдельная история. Но не стоит называть User Story техническим заданием. Это разные документы. Равно как не стоит путать совместную разработку ТЗ с регулярным исправлением ошибок аналитиков разработчиками (такие аналитики и не нужны).
Статья немного сумбурная - кажется, её надо было разбить на две. Первая - про спорное отношение к ТЗ. Вторая с мемуарами и чеклистом.
По отношению к ТЗ: если писать ТЗ нормально, по ГОСТу, то обсуждений никаких не требуется. Там и так должно быть все подробно и понятно описано. Если разраб бросился писать код на низкоуровневом ЯП с первых строчек, то это его проблема.
Во всяком случае “аналитик написал ТЗ, а теперь обсудите и поспорьте о нем” - это очень странный подход. Такое можно говорить об эскизе ТЗ на каком-то промежуточном этапе сбора требований. Но о готовом ТЗ, за которое аналитик расписался?
К слову, в не функциональные требования почему-то брошены и функциональные (точнее, их нюансы, которые должны быть расписаны вместе с этими ФТ).
Вы читали описание https://github.com/adriancable/eternal/blob/main/docs/napkin.md ? Возможно, автору статьи имело бы смысл её перевести. Вкратце, идея о примитивной виртуальной машине, имеющей посимвольный последовательный ввод-вывод, цветной TrueColor экран 800x512, возможность узнавать текущее время по запросу изнутри виртуальной машины, и ещё какое то странное немаскируемое прерывание, принцип и назначение работы которого из описания совсем непонятно.
Вообще, идея очень интересная.
Там, конечно, есть косяки. Например, я так понимаю, что символы, получаемые из портов ввода-вывода - это ASCII. Возможно, автору проекта стоило бы привести таблицу таких символов. Потом, хорошо бы какой-то глоссарий и примеры цветов (я опускаю идею, что возможно “human” тогда не будет, а у тогдашних разумных существ будут органы чувств, не распознающих привычный нам спектр). Возможно, с глоссарием понятия адреса и описание прерываний было бы более понятно. Без этого данное описание - это просто какая-то шутка “для немногих причастных” :)
Против этого есть правило, что аудит таких систем должны осуществлять другие админы. Ну а дальше вопрос политический: требовать соблюдения этого или нет?
Единственно, за кадром остались вопросы, касающиеся бюджетов. В данной схеме Продукт тратит бюджет инфраструктурной команды в виде выделенного человека на взаимодействие с иннерсорс командой и на архитектурное ревью и обеспечение качества. Если будет слишком много таких иннеррсорс команд, то как компания будет решать вопрос увеличения бюджета инфраструктурной команды?
По сути, этот ваш иннерсорсинг - это понятный процесс Дискавери (в т.ч. с точки зрения ограничений/архитектуры общего сервиса, а также решений QA) и Деливери. Выделены постоянно или выделяются под проект отдельные ресурсы на архитектурное и код ревью, на подготовку решения в коде. Эти ресурсы ограничиваются для использования. Где естественным образом (т.к. больше разработчиков, чем есть в иннерсорс-команде, Продукт “сожрать” не сможет), а где - за счёт договоренностей (SLA и т.п.).
Интересный подход, имеет право на жизнь.
Да, причём решение на поверхности. Нужно просто иметь возможность ограничивать каждый корневой сертификат дополнительно к тем ограничениям, которые в нём самом уже есть. К примеру, ограничивать возможность зимбабвийским корневым CA возможность заверять сертификаты в зоне .uy. Технически, такая возможность, вроде, есть уже сейчас, но для обычных пользователей возможность настройки этого никто не реализует.
Тут непонятен вопрос. Если речь про то, каким корневым сертификатам доверять, как обычно - доверянием определённому набору сертификату, которому доверяет ваш гуру (или: монарх, президент, генсек и т.п.).
Упустил по мере повествования: началось с того, что локальные KPI тормозили общий прогресс, а в конце что с этими KPI сделали? Они остались те же, но уже не тормозят, или как?
Ну, это не самое плохое решение. Зависит от фирмы и её размеров…
Ну, аналогия с поездом тут натянутая. У начальника поезда и у проводника вагона есть свои полномочия и ответственность. У машиниста - свои. У дежурной по станции и поездного диспетчера - свои. У путевых рабочих и инженеров - другие. Точки их взаимодействия описаны в толстенных инструкциях, и да, там иногда возникают накладки, как в том случае, когда дежурная приказала срочно отправляться, а проводники дёрнули стоп-кран и в поезд влетел потерявший управление состав.
Но у них у всех есть общее начальство. Если оно пожелает изменить проблемные места, то изменит, и никаких ДМ тут не нужно. А если нет, то будь там десять ДМ (если учитывать поездную аналогию, - это некий “заместитель по улучшению процессов/по научной организации труда” некоего наименьшего общего начальника), ничего не сдвинется - как раз потому что у каждого есть свои чётко прописанные обязанности, в т.ч. не только перед инструкцией, но и перед законом.
… А ещё можно в ТЗ просто поставить требование минимизации влияния на водителей (либо прямо так, либо расписать, “оцифровав” с помощью соответствующих метрик).
Если у РП только “свои бригады и задачи”, то это по определению не РП. Основная задача РП - довести конкретный проект до завершения. И у него должна быть возможность, в частности, заменить бригаду “пьющих” на нормальную, иначе, опять же, он никакой не РП.
Т.е когда видишь какой-то долгострой с “обманутыми дольщиками”, то это виноват DM, а не тот, кто направил средства “куда-то не туда”, либо начал строительство без надежды на завершение. Здорово, что дома строят пока ещё не по Agile
А если серьёзно, то кейсы интересные, но ещё раз подчёркивают мысль, что необходимость в DM - это следствие провала в каком-то отдельном месте процесса.
Давным давно придуманы механизмы подтверждения значимых действий несколькими разными сотрудниками.
Было бы желание эти меры внедрять
А ФСП - это что за организация? Это же не про ФССП?