![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rWir nennen das "Narkotargeting"... "Nanotargeting".
/ Мы называем это нарко-таргетированием... нано-таргетированием. /
Прослушал вполуха веб-конференцию по новым веяниям в маркетинге. Это был единственный светлый момент за два дня выступлений.
Нет, люди вполне адекватные. Даже продавец искусственного интеллекта сказал, что нужен интеллект профессиональный, чтобы поставить роботам задачу и понять, что же на самом деле говорят данные, которые они натаскали в базу. Но общий настрой был печальным, потому что в основном обсуждался вопрос, как сохранить контакт с покупателем, когда чиновники запрещают сохранять данные контакта с покупателем. (Как будто китайцам и мошенникам, в том числе и от государства, такие законы могут помешать.)
Это было как-бы введение с объяснением. Вот также и с review и agile-review. Ошибочка маленькая, а смысл совершенно разный.
В принципе, стоящее ниже не объяснение, а тем более не доказательство и надо было бы расписать всё подробно с основами, но времени на это нет. Воспринимайте это не более чем подсказку. Можно было бы, конечно, подождать лучших времён и сделать всё правильно, но фиг знает, когда это будет.
Просто увидел, что к статусу "waiting for review" в реальном проекте надо добавлять "still waiting for review" и "really waiting for review", вот и подумал, может кому сейчас пригодится. Кто куда эти намёки дальше додумает -- уже не ко мне.
Итак,
The main goal of an agile review is the blurring of responsibilities for errors within the team.
The main goal of an engineering review is the internal cross-education of the team.
Не смотря на то, что стоит в рекламных буклетах, реальная и единственная цель agile-review -- это размывание ответственности. Есть ещё масса положительных и отрицательных аспектов, но они совершенно опцинальны при agile-подходе.
В отличие от культуры самолётов из соломы, у инженеров review -- это прежде всего процесс обучения. При взаимодействии специалистов происходит не критика для расстановки оценок, а объединение областей знаний. Те, кто не понимает, сидят и слушают. И задают настолько глупые вопросы, что в agile-проектах с их лелеемым чувством собственной важности такое и помыслить невозможно.
То есть, вопрос не в том, чтобы найти мелкие ошибки в заполнении документации (для этого есть более эффективные методы) и не в том, чтобы надавать великомудрых советов (модератор должен затыкать всезнаек даже из высшего менеджмента). При решении любой сложной проблемы будут аспекты, не замеченные или не рассмотренные одним человеком. Именно для этого команда специалистов и объединяет усилия.
Ещё более важный аспект обучения -- это демонстрация образа мыслей, то есть способов поиска решения. Обычно в процессе хорошего review пара людей бьёт себя ладонью в лоб и быстро ставит в блокноте пометку, обязательно проверить или исправить что-то в собственной задаче. Иногда вся группа в обсуждении доходит до необходимости исправления совершенно другой части проекта.
В принципе, глупый менеджмент инженерные review потому и не любит, что результаты у них непредсказуемые в плане влияния на сроки и планирование. Кстати, в этом месте и насаждается культура "Давайте сделаем неправильно, но в срок, а переделки -- это уже будет следующим проектом". А потом результатами такого подхода доказывают, что формальные методы не работают. А тут и до agile недалеко.
Да, в индустрии софтописания engineering review практически никогда не бывает. И чаще всего причина в неадекватности специалистов. Помнится, в одном real time mission critical проекте пришлось долго рисовать на доске распараллеливание процессов, после чего гуру, единственный кто в параллельных процессах чего-то понимал, сказал, что не понял, как это будет работать, но попробовать можно.
Обычно какая-то красивая идея натыкается на стену непонимания. Приходится заменять правильное решение на понятное. Просто потому, что люди не хотят учиться.
В agile-проекте и в работе с индийско-китайскими программистами даже в полном непонимании никто не сознается.
Это хорошо заметно по вторичным признакам. Непонимание порождает у одних отторжение, а у других сопротивление. Первые уходят в отказ, становятся недоступны для диалога и втихаря жалуются начальству (Indian subversion), а вторые начинают засыпать безумными предложениями и бессмысленными замечаниями, пытаясь протолкнуть их административно через менеджмент (German vandalism). Потому как в общении с менеджерами сейчас рекомендовано перед review вставлять пару очевидных ошибок, чтобы удовлетворить чувство собственной важности идиотов.
no subject
Date: 2020-12-10 02:35 pm (UTC)О какой отличный текст. И масса полезных идеек. Спасибо!
С ревью... да я в нашей команде уже понял, что вообще делать что-то содержательное лучше не надо - одни не поймут, другие, неизвестно из каких соображений, будут активно возражать.
no subject
Date: 2020-12-10 03:40 pm (UTC)Системные проблемы требуют системных решений. Вот с этим-то и загвоздка.
no subject
Date: 2020-12-13 02:21 am (UTC)