Экстраполяция IT

Принципиально существует два вида обмена информацией в команде с условными названиями «push» и «pull».

Очевидно, что pull намного ленивее, потому как, собственно, делать ничего не надо: просто делаешь свою работу и всё. Если кому будет надо что, тот обратится и вытянет всю необходимую ему информацию. И его заботой будет убедится, что информации достаточно и ничего не упущено из виду. Если же что-то понадобится тебе, то задачей будет раздобыть и вытянуть всю нужную инфу. Понятное дело, что носитель сакраментальных знаний будет занят целую неделю и вообще ему не до ваших проблем. И передавать знания он будет по пути наименьшего сопротивления, мол «ты спрашивай что тебе надо, а я все отвечу и подготовь вопросы заранее, чтобы время не терять». В итоге передача знаний затягивается и бюрократизируется. Обработать и переварить ответы можно и не сразу и задать уточняющие вопросы наверняка нужно будет, а для этого отдельную встречу планируй и все по новой.

Способ с кодовым названием «push» напротив сосредотачивается на том, что весь процесс тщательно записывается и ответы на все вопросы уже как бы есть и ничего узнавать ни у кого не нужно. Достаточно просто знать где искать. Этот подход более требователен как к исполнителям, так и к менеджерам, ведь любой чих и пук должен быть запротоколирован и каталогизирован. Был выбор между двумя библиотеками? Нужно описать все сомнения, факторы, повлиявшие на решение и само решение в специальное место, чтобы если вдруг у кого-то появится желание использовать противоположную библиотеку, он мог узнать о предыдущем решении и проникнуться всеми сомнениями прошлого исполнителя. Прилетело резюме от кандидата, с которым мы уже имели дело в прошлом? Об этом нужно незамедлительно узнать и выяснить все детали прошлого расставания или отказа. Недостатком такого подхода будет стабильно увеличенное время разработки. А серьезной проблемой будет простая человеческая лень и забывчивость. А самое сложное в этом подходе будет придумывание структуры хранения всего этого

И вообще все современные методологии разработки в принципе нужны исключительно для того, чтобы уйти от принципа вытягивания знаний к процессам доступных и структурированных знаний о проекте и всех его процессах.

Хорошей аналогией, кстати, будут строгие и ленивые вычисления. Преимущества и недостатки будут приблизительно совпадать.

#полныйаджайл

www.tgoop.com/itextrapolation/366

2.88K viewsedited  Aug 5, 2019 at 15:30

Принципиально существует два вида обмена информацией в команде с условными названиями «push» и «pull».

Очевидно, что pull намного ленивее, потому как, собственно, делать ничего не надо: просто делаешь свою работу и всё. Если кому будет надо что, тот обратится и вытянет всю необходимую ему информацию. И его заботой будет убедится, что информации достаточно и ничего не упущено из виду. Если же что-то понадобится тебе, то задачей будет раздобыть и вытянуть всю нужную инфу. Понятное дело, что носитель сакраментальных знаний будет занят целую неделю и вообще ему не до ваших проблем. И передавать знания он будет по пути наименьшего сопротивления, мол «ты спрашивай что тебе надо, а я все отвечу и подготовь вопросы заранее, чтобы время не терять». В итоге передача знаний затягивается и бюрократизируется. Обработать и переварить ответы можно и не сразу и задать уточняющие вопросы наверняка нужно будет, а для этого отдельную встречу планируй и все по новой.

Способ с кодовым названием «push» напротив сосредотачивается на том, что весь процесс тщательно записывается и ответы на все вопросы уже как бы есть и ничего узнавать ни у кого не нужно. Достаточно просто знать где искать. Этот подход более требователен как к исполнителям, так и к менеджерам, ведь любой чих и пук должен быть запротоколирован и каталогизирован. Был выбор между двумя библиотеками? Нужно описать все сомнения, факторы, повлиявшие на решение и само решение в специальное место, чтобы если вдруг у кого-то появится желание использовать противоположную библиотеку, он мог узнать о предыдущем решении и проникнуться всеми сомнениями прошлого исполнителя. Прилетело резюме от кандидата, с которым мы уже имели дело в прошлом? Об этом нужно незамедлительно узнать и выяснить все детали прошлого расставания или отказа. Недостатком такого подхода будет стабильно увеличенное время разработки. А серьезной проблемой будет простая человеческая лень и забывчивость. А самое сложное в этом подходе будет придумывание структуры хранения всего этого

И вообще все современные методологии разработки в принципе нужны исключительно для того, чтобы уйти от принципа вытягивания знаний к процессам доступных и структурированных знаний о проекте и всех его процессах.

Хорошей аналогией, кстати, будут строгие и ленивые вычисления. Преимущества и недостатки будут приблизительно совпадать.

#полныйаджайл

BY Экстраполяция IT