Если бизнес такое устраивает, то почему бы нет? Сделать по нормальному сейчас будет примерно на столько дольше, насколько дольше было бы сделать изначально, зато фирма работает уже сейчас. Если на это исправление не выделяют ресурсов, значит еще не пришла пора.
Почему ТЗ не может быть на уровне отдельных сторей? Вполне может. Главное что бы было прописано все, касающееся доработки. Не обязательно, что бы был том “войны и мира”.
Совмещение ролей - это хорошо. Но важно понимать: если есть ТЗ, то фактически систему проектируют разработчики этого ТЗ (на основе интервью по сбору требований и т.п. соображений). У тех, кто будет использовать ТЗ тоже может быть существенный вклад, но поскольку выйти за рамки ТЗ они не могут, то какой бы хитрой разработанная система ни была внутри, снаружи она будет вести себя как описано в ТЗ. Если же ТЗ нет, -то результат ХЗ-, то разрабатывает систему тот, кто её шатает (разработчик, программист, админ и т.п.).
Для нормального 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 - это следствие провала в каком-то отдельном месте процесса.
По поводу зависимых досок: Да, - это определённый "костыль", который нужен, что бы негибкие системы приспособить для Kanban-метода. Собственно KM идеален (и был создан) для вариативных непонятных процессов, и подразумевается, что у вас могут быть самые необычные средства представления этих процессов. И, самое главное, должно быть легко менять эти процессы, т.к. KM - это про управление изменениями. Поэтому, если бы мы не жили в мире удалёнки, удобнее всего была бы физическая доска.
Непонятно из статьи: откладываем, и заменяем на что?
И по формулировке проблемы вопросы (я так понимаю, про шкафы - это не про материальное производство для которого есть отдельные MES системы, а некоторая метафора для нематериального процесса, отслеживаемого с помощью Канбан Метода):
Чем мешает вариативность процессов? Совсем необязательно проходить по всем колонкам на канбан-доске. И доски для разных видов процессов вполне себе могут быть разными. Часто это при накладывании на популярные IT системы для визуализации кодируется системой зависимых досок. На верхнем уровне у вас доска с эпиками, элементы которых находятся на соответствующих досках.
С одной стороны, верно, а с другой стороны, у провода и радио просто разные риски. И получается, что провод и радио друг друга резервируют.
Если бизнес такое устраивает, то почему бы нет? Сделать по нормальному сейчас будет примерно на столько дольше, насколько дольше было бы сделать изначально, зато фирма работает уже сейчас. Если на это исправление не выделяют ресурсов, значит еще не пришла пора.
Почему ТЗ не может быть на уровне отдельных сторей? Вполне может. Главное что бы было прописано все, касающееся доработки. Не обязательно, что бы был том “войны и мира”.
Совмещение ролей - это хорошо. Но важно понимать: если есть ТЗ, то фактически систему проектируют разработчики этого ТЗ (на основе интервью по сбору требований и т.п. соображений). У тех, кто будет использовать ТЗ тоже может быть существенный вклад, но поскольку выйти за рамки ТЗ они не могут, то какой бы хитрой разработанная система ни была внутри, снаружи она будет вести себя как описано в ТЗ. Если же ТЗ нет, -то результат ХЗ-, то разрабатывает систему тот, кто её шатает (разработчик, программист, админ и т.п.).
Для нормального 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 - это следствие провала в каком-то отдельном месте процесса.
Давным давно придуманы механизмы подтверждения значимых действий несколькими разными сотрудниками.
Было бы желание эти меры внедрять
А ФСП - это что за организация? Это же не про ФССП?
Можно ли с использованием 152-фз привлечь обзвонщиков? Считается ли набор номера использованием ПДн? Кто в этом случае оператор, как его найти?
По поводу зависимых досок: Да, - это определённый "костыль", который нужен, что бы негибкие системы приспособить для Kanban-метода. Собственно KM идеален (и был создан) для вариативных непонятных процессов, и подразумевается, что у вас могут быть самые необычные средства представления этих процессов. И, самое главное, должно быть легко менять эти процессы, т.к. KM - это про управление изменениями. Поэтому, если бы мы не жили в мире удалёнки, удобнее всего была бы физическая доска.
Непонятно из статьи: откладываем, и заменяем на что?
И по формулировке проблемы вопросы (я так понимаю, про шкафы - это не про материальное производство для которого есть отдельные MES системы, а некоторая метафора для нематериального процесса, отслеживаемого с помощью Канбан Метода):
Чем мешает вариативность процессов? Совсем необязательно проходить по всем колонкам на канбан-доске.
И доски для разных видов процессов вполне себе могут быть разными. Часто это при накладывании на популярные IT системы для визуализации кодируется системой зависимых досок. На верхнем уровне у вас доска с эпиками, элементы которых находятся на соответствующих досках.