ManageExpert.ru

Успешный менеджмент

Скромный и высокопоставленный писарь

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

Хорошая групповая память должна вмещать много информации. Одна часть этой памяти является непостоянной или временной памятью, другая часть — постоянной. Часть групповой памяти является активной и может оперативно использоваться в обсуждениях и решении повседневных задач. К другой части памяти команда обращается реже. Для удобства функции управления информацией можно разделить на функции сессионной памяти и функции проектной памяти. Сессионная память состоит из записей, созданных и задействованных во время групповых сессий, когда участники команды встречаются и вырабатывают групповые решения. В проектной памяти хранятся постоянные записи и документация, написанная и применяемая группой. Она включает в себя рабочий продукт, под которым понимается не только код, но и все проектные и анали-тЕческие модели и документы, созданные при написании кода. Кроме того, в проектной памяти хранятся входные данные, такие как требования, спецификации и другие основополагающие документы. Для управления проектной памятью нужен библиотекарь, и часто эта роль известна именно под этим названием. Модульная память

Важнейшая функция сессионной памяти — хранение отчета о процессах, который отражает проведенные обсуждения и решения, принятые в группе (Дойл (Doyle) и Страус (Strauss), 1982 [35]). Наверное, идея о ведении записей в ходе процесса нова для большинства групп, разрабатывающих программное обеспечение, однако на различных собраниях это практиковалось десятилетиями. Ведя записи, начинающие писари часто допускают одну из двух ошибок. Они либо пытаются записывать все подряд, словно под диктовку, либо ждут, пока группа не придет к какому-то заключению, и просто записывают итог. Для технической работы, выполняемой командой, записи вида «он(а) сказа л (а)» не особенно подходят и не являются необходимыми. В хорошем протоколе отмечены ключевые события на пути к конечному результату, особенно рассмотренные альтернативы, принятые решения и представленные аргументы. Такие записи вносят наибольший вклад в групповое приобретение опыта. Они могут стать бесценными, когда необходимо оценить проект или когда проект вступает в фазу «post mortem».

Для разработки программного обеспечения сплошной неструктурированный протокол не подходит. Некоторые виды данных так часто анализируются в ходе сессий, что требуют ведения отдельных записей для последующего особого рассмотрения. Полезно также вести записи под заголовком «нужно сделать», где отмечать те идеи, которые возникают в обсуждениях, но сразу не воплощаются. Уже одно это может оправдать утомительное ведение сессионных записей, поскольку позволяет избежать нелепых оплошностей, обычно выявляемых во время системной интеграции или уже после отправки продукта заказчикам: «О, да мы совсем забыли о проблеме с висячим указателем!»

Хорошая сессионная память также включает отложенные решения, которые лучше всего хранить отдельно от уймы записей в списке «нужно сделать». Наличие специального места для отложенных решений может также ускорить их принятие. Вместо того чтобы тратить время на бесконечные споры, вызванные недостаточным пониманием или отсутствием данных, группа может занести этот вопрос в список отложенных реше-ний. Зачастую к тому времени, когда группа возвращается к этому вопросу, уже многое известно для принятия быстрого решения. Третий специальный раздел записей, который тоже полезен команде разработчиков, — это раздел «запасных частей». Сюда можно временно откладывать фрагменты хороших технических идей или частичные решения, чтобы не нарушать основной ход обсуждения. «Мусорная корзина» играет противоположную роль. Здесь можно отмечать все неиспользованные идеи и пути наряду с вескими причинами для их отклонения.

Все четыре специальных списка («нужно сделать», «отложенные решения», «запасные части» и «мусорная корзина») служат для записи того, что могло быть потеряно или забыто. Помимо всего прочего, такие записи помогают группе эффективно использовать время. Отмечая в одном из специальных списков факты отхода от основной темы, группа не теряет главной нити своего обсуждения и не упускает полезную информацию. Все это также может помочь группе избежать никчемных споров. Для того чтобы не пробуксовывать, тот или иной вопрос можно поместить в одну из «корзин» для более позднего рассмотрения. Кроме того, сами корзины служат в качестве механизмов обеспечения качества (QA, quality assurance). В конце проекта все содержимое корзин должно быть уничтожено или каким-то образом учтено.

Перейти на страницу: 1 2 3