|
||||
Меню:
Главная
Форум
Литература: Программирование и ремонт Импульсные блоки питания Неисправности и замена Радиоэлектронная аппаратура Микросхема в ТА Рубрикатор ТА Кабельные линии Обмотки и изоляция Радиоаппаратура Гибкие диски часть 2 часть 3 часть 4 часть 5 Ремонт компьютера часть 2 Аналитика: Монтаж Справочник Электроника Мощные высокочастотные транзисторы 200 микросхем Полупроводники ч.1 Часть 2 Алгоритмические проблемы 500 микросхем 500 микросхем Сортировка и поиск Монады Передача сигнала Электроника Прием сигнала Телевидиние Проектирование Эвм Оптимизация Автомобильная электроника Поляковтрансиверы Форт Тензодатчик Силовые полевые транзисторы Распределение частот Резисторные и термопарные Оберон Открытые системы шифрования Удк |
[20] 4.5 Условия работы Проблемы создания нормальных условий для работы уже так много лет обсуждаются среди разработчиков ПО, что кажется бессмысленным снова их поднимать. Tom DeMarco и Tim Lister, чья книга уже не раз цитировалась в этой главе, уделяют большое внимание тем преимуществам, которые дает создание нормальных условий для работы; например, если разработчики ПО работают в достаточно тихом помещении, вероятность появления у них ошибок уменьшается на одну треть по сравнению с теми, кто работает в шумном офисе и постоянно отвлекается на посторонние дела. Проанализировав работу 600 разработчиков ПО, DeMarco и Lister смогли получить результаты, убедительно говорящие о том, что продуктивность работы тех, кто находится в хорошем офисе и может закрыть дверь, не отвечать на телефонные звонки и не отвлекаться на посторонние дела, почти в 2,6 раза выше, чем у находящихся в обычном офисе. Хотя DeMarco и Lister опубликовали свою работу в 1987 году, с тех пор в условиях работы большинства разработчиков ПО мало что изменилось - за исключением фирм-разработчиков ПО. Условия работы в Microsoft и в большинстве других софтверных компаний Силиконовой Долины в самом деле достаточно цивилизованные - отдельные помещения с закрытыми дверями, наличие содовой, сока и других напитков, и «постоянный» телефонный номер, который остается за программистом даже в том случае, если он перебирается в другое помещение. Что касается разработчиков ПО, работающих в банках, страховых компаниях, правительственных учреждениях, промышленных предприятиях и сотнях других компаний, которые до сих пор смотрят на программное обеспечение как на «накладные» расходы, то им приходится работать не в нормальных офисах, а в отгороженных клетушках, где возможность сконцентрировать свои умственные усилия на решении какой-либо проблемы варьируется от плохой до полностью отсутствующей. Звучит набившая оскомину музыка, не прекращаются телефонные звонки, лают собаки, кричат люди, и нет никакого спасения от кого угодно (от курьера до директора), кто может засунуть голову в твою комнату и отвлечь тебя. Как отмечают • Выполнение: команда начинает функционировать как целое. В идеальном случае команда оказывается уже прошедшей первые две стадии еще до начала проекта - поскольку участники команды работали вместе в предыдущих проектах. Тем не менее, все проекты разные, и в каждой проектной команде обычно имеются один или два новых человека, присутствие которых повлечет за собой некоторое «формирование» и «утряску». Но независимо от того, сколько времени потребуется на весь процесс - день, неделя или месяц - он все равно произойдет; если это окажется возможным, менеджеру проекта следует постараться как можно больше ввести команду в курс дела еще до «официального» начала проекта, с тем, чтобы к этому моменту уже оказаться в стадии «выполнения». Важно также не забывать, что даже сплоченная команда может развалиться под воздействием тех стрессов, которые они испытывают в безнадежном проекте. В своем письме ко мне Dale Emery рекомендует, чтобы менеджер проекта внимательно следил за процессами, происходящими в команде: Уделяйте внимание взаимоотношениям, складывающимся в команде, и не жалейте усилий на поддержку готовности людей к совместной сверхурочной работе. Давление, которое испытывают участники безнадежного проекта, может превратить небольшие недоразумения в большие конфликты. Периодическое «измерение температуры» в группе может помочь вам и команде справляться с проблемами во взаимоотношениях, когда они еще находятся в самом зародыше. В худшем случае может случиться, что команда так и не пройдет первые две стадии, или, иначе говоря, встанет на путь «командного самоубийства», не сумев справиться с перечисленными выше проблемами. Если через какое-то время менеджер проекта (или кто-нибудь из более высокого руководства) обнаружит, что так оно и произошло, может оказаться слишком поздно формировать новую команду. Се ля ви. DeMarco и Lister: Проектировщики с полицейскими наклонностями проектируют рабочие места наподобие тюрем: оптимальная вместимость при минимальных затратах. Мы бездумно соглашаемся с ними в вопросах проектирования рабочих мест, хотя в большинстве организаций, испытывающих проблемы с продуктивностью работы, не существует более подходящего фактора ее повышения, чем рабочие места. До тех пор, пока сотрудники будут тесниться в шумных и неприспособленных помещениях, нельзя говорить о сколько-нибудь продуктивной работе. К сожалению, мои рассуждения относительно сложившейся ситуации вряд ли смогут оказать на нашу индустрию большее воздействие, чем гораздо более детальные и убедительные выкладки DeMarco и Lister. Однако не следует забывать, что мы здесь говорим о безнадежных проектах, к которым применимы другие правила, и я думаю, что менеджеру проекта следует принять такую философскую позицию, которая подразумевает отсутствие вообще каких бы то ни было правил. Если вы являетесь менеджером безнадежного проекта с практически нереальными сроками, то сведений о том, что хорошие условия работы могут улучшить продуктивность в 2,6 раза, может оказаться достаточно, чтобы заставить вас сломать множество преград. То, чего вам удастся в этом деле достичь, может оказаться всего лишь временным; как только проект закончится, налетит хозяйственная служба, все отберет и вернет вас обратно в крохотные клетушки. Однако, если безнадежный проект продолжается хотя бы полгода, и вы достаточно изобретательны, стоит попытаться обеспечить подходящие условия для работы таким образом, чтобы хозяйственная служба вообще не знала о том, что происходит. Для этого есть несколько возможностей: •Лобовая атака - если у вашего проекта есть защитник и/или владелец, которые крайне заинтересованы в его успехе, объясните им, насколько важно, чтобы проектная команда работала в хороших условиях. Если защитник проекта является руководителем высокого уровня, то организовать временный переезд команды в более подходящее помещение будет относительно несложно. •Самовольный захват - не спрашивая ни у кого разрешения, займите какое-нибудь пустое помещение, которое пока никем не занято, в то время как хозяйственная служба пытается подсчитать, сколько сотен людей они смогут туда впихнуть. Такой захват обеспечит 90% успеха в борьбе за условия работы; пока бюрократы будут ругаться, спорить и отправлять в разные стороны гневные послания, вам, может быть, уже удастся закончить проект и незаметно удалиться на прежнее место. •Дистанционный доступ - разрешите всем работать дома и организуйте еженедельные рабочие совещания в ближайшем «Макдональдсе» (в 9 часов утра, когда почти нет посетителей). Пока кто-нибудь обнаружит исчезновение команды, может пройти не одна неделя. Для дополнительного отвлечения внимания можно посадить чучела за столы, которые обычно занимала проектная команда; руководству понадобится достаточно много времени, чтобы отличить их от других зомби, сидящих в офисе. •Переход в ночную смену - это более радикальный вариант, однако он может оказаться достаточно эффективным, если большая часть работы может выполняться без взаимодействия с пользователями. Не слишком приятно просить людей работать в ночное время вместо дневного, однако фактически это гарантирует отсутствие обычных отвлечений. Подобная стратегия наверняка вызовет гнев местных бюрократов, но самая замечательная вещь заключается в том, что бюрократы не остаются в офисе до полуночи! Они будут слать сердитые записки и послания по электронной почте, при этом следует игнорировать их и делать вид, что никогда их не получали. Если это не удается, просто откажитесь менять свой график работы; пока они не додумаются отключать свет или поменять замки на двери офиса, вряд ли им удастся помешать вам в рамках обычного безнадежного проекта. • Преграды и заслоны - если ваша команда работает в обычном «открытом» офисе и упомянутые выше стратегии неприменимы, тогда постарайтесь сделать все возможное, чтобы сосредоточить команду в смежных помещениях. После этого сделайте все необходимое, чтобы забаррикадироваться от остальной толпы в офисе. Отключите селекторную связь и вопящий из угла громкоговоритель (и будьте готовы проделывать это еженедельно, поскольку обслуживающий персонал может снова включить их). Выключите телефоны из сети, или, как советуют DeMarco и Lister, набейте вату в звонок. Если вы сможете проделать такое на целом этаже или вообще во всем здании, то будет еще лучше. Поднимите над зданием пиратский флаг, как это сделал Стив Джобс со своей командой в Apple во время проекта Macintosh. Установите охрану, чтобы гнать прочь непрошеных визитеров. Некоторые из этих могут спровоцировать более резкую ответную реакцию корпоративной бюрократии, чем другие; команда и ее менеджер должны решить, какая стратегия будет наиболее эффективной. Но я хотел бы подчеркнуть, что вполне серьезно рассматриваю все эти стратегии, невзирая на очевидный факт, что они нарушают «правила игры», принятые почти в каждой крупной компании. Бороться с бюрократией таким способом - не для робкого десятка; но ведь и сами безнадежные проекты тоже не для робкого десятка. Если менеджер безнадежного проекта не проявляет желания бороться и отстаивать право на нормальные условия работы, то с какой стати проектная команда должна проявлять готовность идти на экстраординарные жертвы ради организации и менеджера проекта? 4.6 Заключение Талантливых исполнителей, сплоченной команды и хороших условий для работы все же недостаточно, чтобы гарантировать успех безнадежного проекта. С другой стороны, их отсутствие почти наверняка гарантирует провал проекта. Как будет ясно из следующих двух глав, хорошо организованные процессы разработки и хорошая технология также являются важными составляющими успеха; однако, все же самая главная составляющая - это люди. Как сказал Рональд Рейган: «Окружите себя самыми лучшими людьми, которых вы только сможете найти, передайте им в руки власть и не мешайте им». Литература к главе: 1.Tom DeMarco, Tim Lister. Peopleware. Dorset Publishing, 1987. 2.Frederick Herzberg. One More Time: How Do You Motivate Employees? Harvard Business Review, September-October 1987. 3.John Boddie. Crunch Mode. Englewood Cliffs: Prentice-Hall/Yourdon Press, 1987. 4.Rob Thomsett. Effective Project Teams: A Dilemma, a Model, a Solution. American Programmer, July-August 1990. Дополнительная литература: 1.Larry Constantine. Constantine on Peopleware. Englewood Cliffs, NJ: Prentice Hall, 1995 2.Watts Humphrey. Managing for Innovating: Leading Technical People. New York: McGraw- Hill, 1987. 3.Gerald M. Weinberg. Understanding the Professional Programmer. New York: Dorset House, 4.Ken Whitaker. Managing Software Maniacs. New York: John Wiley & Sons, 1994. |
Среды: Smalltalk80 MicroCap Local bus Bios Pci 12С ML Микроконтроллеры: Atmel Intel Holtek AVR MSP430 Microchip Книги: Емкостный датчик 500 схем для радиолюбителей часть 2 (4) Структура компьютерных программ Автоматическая коммутация Кондиционирование и вентиляция Ошибки при монтаже Схемы звуковоспроизведения Дроссели для питания Блоки питания Детекторы перемещения Теория электропривода Адаптивное управление Измерение параметров Печатная плата pcad pcb Физика цвета Управлении софтверными проектами Математический аппарат Битовые строки Микроконтроллер nios Команды управления выполнением программы Перехода от ahdl к vhdl Холодный спай Усилители hi-fi Электронные часы Сердечники из распылённого железа Анализ алгоритмов 8-разрядные КМОП Классификация МПК История Устройства автоматики Системы и сети Частотность Справочник микросхем Вторичного электропитания Типы видеомониторов Радиобиблиотека Электронные системы Бесконтекстный язык Управление техническими системами Монтаж печатных плат Работа с коммуникациями Создание библиотечного компонента Нейрокомпьютерная техника Parser Пи-регулятор ч.1 ПИ-регулятор ч.2 Обработка списков Интегральные схемы Шина ISAВ Шина PCI Прикладная криптография Нетематическое: Взрывной автогидролиз Нечеткая логика Бытовые установки (укр) Автоматизация проектирования Сбор и защита Дискретная математика Kb радиостанция Энергетика Ретро: Прием в автомобиле Управление шаговым двигателем Магнитная запись Ремонт микроволновки Дискретные системы часть 2 | ||