Человеческий фактор в программировании - [8]
Если в подготовке предложенных решений участвовали отдельные подгруппы, то после первоначальных обсуждений каждой подгруппе может быть предложено вернуться назад и улучшить свое предложение, используя то, что по их мнению является лучшим в подходах, предложенных другими. Тогда в начале следующей встречи противостоящие точки зрения окажутся ближе друг к другу.
В общем, технический консенсус достигается на основе комбинирования лучших черт всех вариантов и даже генерации новых. Вместо того чтобы начинать с конкретных технических предложений, зачастую бывает более разумно и эффективно начать с самой задачи. Первым делом команде нужно выяснить основные технические аспекты, присутствующие в раз-личных вариантах, а также базовые предпосылки и техническое обоснование исходных позиций и предлагаемых решений.
Процесс творческого синтеза начинается еще до первой встречи. Вместо того чтобы обдумывать, скажем, структуру файлов, члены команды могут очертить круг вопросов, связанных с разработкой эффективной файловой структуры. Они могут составить список конкретных критериев для принятия решений и определить их приоритетность. Их можно даже попросить пока не думать об идеях и предложениях. С большинством тех разработчиков программного обеспечения, которые в большей мере являются одиночками, проблема состоит, скорее, не в том, чтобы побудить их к работе, сколько в том, чтобы сдержать их пыл перед тем, как они сорвутся с мест.
Из журнала Computer Language Magazine, том 9, № 5, май 1992 г.
4
Скромный и высокопоставленный писарь
Помните, как Боб Крэтчит (Bob Cratchit) трудился над книгами в солидной фирме Скруджа (Scrooge) и Марли (Marley), надев на руки перчатки без пальцев, чтобы они не замерзали, пока Боб перелистывал страницы? Я очень люблю «Рождественский гимн» (A Christmas Carol). Недавно мне подарили видеокассету с изумительной черно-белой экранизацией, где главную роль играет Алистэр Сим (Alistair Sim). Посмотрев этот фильм, я задумался о старом Бобе и других «клерках», которые на протяжении столетий вели учетные книги для множества предприятий. Эти писари были настоящими компьютерами своего времени. Без них предприятия пришли бы к банкротству, а целые отрасли были бы ввергнуты в хаос. Их реальная власть и влияние намного превосходили их скудные жалования или невысокий статус. Вообще говоря, продолжительный успех Скруджа и Марли был в большей мере связан с работой старого доброго Боба и его соотечественников, чем с тем, что привнес Эбенезер.
Сегодня вряд ли что-то изменилось. Сотрудники, которые ведут учетные книги, по-прежнему ценятся невысоко. Но в их карандашах, маркерах и клавиатурах может скрываться сила, предопределяющая успех или провал разработки программного обеспечения.
Если группы по разработке программного обеспечения ведут какие-то записи, то в архивах и заметках отражаются только результаты и выводы, рабочие продукты или готовые компоненты. Программисты особенно не любят записывать что-нибудь кроме самого кода, если только перед ними не стоит угроза штрафа или тюремного заключения. Заставить их нари-совать диаграммы — это все равно, что заставить слона сделать наброски карандашом. В конце концов, разве не является хороший код самодокументируемым?
Такое отношение приводит к потере жизненно важной информации. Вообще говоря, когда сохраняется только конечный продукт, нам известен результат, но мы не знаем, как его получили. Как создавалось программное обеспечение, какие решения были найдены в процессе работы — все это является важным. Можем ли мы полагаться на свою память? Беспокоимся ли мы только об ошибках или вдобавок хотим извлечь из них пользу?
Особые трудности в работе групп, сохраняющих только конечный программный продукт, вызывает отсутствие записей о решениях, от которых отказались. Знать о том, какие методы были отклонены и по каким причинам, часто бывает так же важно, как и о том, какие методы были выбраны. Это жизненно важно в тех случаях, когда готовятся новые версии или системы или когда разработка текущей системы заходит в тупик.
Наверное, вы когда-нибудь рассматривали свой код, написанный несколько месяцев или лет назад. Случалось ли так, что вы находили такие места, которые казались неверными, и вы удивлялись, как же программа вообще могла работать? Если вы поддавались соблазну «исправить» эту скрытую ошибку, как это иногда делал и я, то могли обнаружить, что «исправление» загоняло систему «в угол». Естественно, код только казался неправильным, но сам по себе он не объяснял, почему здесь все в порядке. Не помогут и такие комментарии в коде: «Ничего здесь не меняйте. Это место кажется неверным, но здесь все правильно». Если программист знал, что «здесь все правильно» и почему другой вариант будет неверным, то почему же тогда эта логика не отражена в комментарии? Если мы хотим поддерживать систему не один год или иметь возможность выпустить следующую версию через пять лет после того, как все разработчики первой версии системы будут далеко, нам нужно знать, какие варианты рассматривались, какие были отклонены и почему.
Покупайте конкурентов, усиливайте команду, предлагайте новые продукты и услуги. Все эти предложения для большинства собственников и руководителей компаний актуальны в период роста, когда график продаж неуклонно идет вверх, а на лицах членов совета директоров по итогам отчетных собраний из полугодие в полугодие непременно играет улыбка. Автор придерживается иного мнения. Атаковать нужно в кризис, когда большинство топ-менеджеров заняты тем, что играют в защите, и, самое главное, – боятся волны кризиса, которая может отправить их на дно.
Прежде чем взяться за перо, я много лет проработал в коммерческих предприятиях в качестве первого лица. Я не только работал (и работаю) генеральным директором крупных российских компаний из самых разных сфер — общепит, производство, отделочные материалы, — но и входил (и вхожу) в советы директоров государственных и частных компаний. Я бы никогда не написал эту книгу, если бы не московские пробки. Обилие «пробочного» времени, привычка записывать свои мысли и современные цифровые технологии сделали эту книгу возможной.В этой книге я делюсь собственным опытом и впечатлением от других прочитанных книг.
Любая предпринимательская деятельность – это не только извлечение прибыли, это прежде всего люди, которые работают в компании или у предпринимателя. Даже сам предприниматель, который трудится на себя, является работником. Аналогичная ситуация возникает и в том случае, когда в компании работает только генеральный директор, который одновременно является учредителем. И ошибочно полагать, что кадровый учет и кадровую отчетность в этом случае вести не нужно. Но большая ответственность на работодателе лежит, если в штате компании или предпринимателя трудятся работники.
Проблема управления рисками при информатизации бизнеса является одной из наиболее актуальных и значимых в ИТ-индустрии. В предлагаемом учебно-практическом пособии, затронуты как теоретические, так и практические вопросы управления рисками, раскрывается специфика механизма управления рисками при реализации проектов в области информационных технологий.В основу учебного пособия положен многолетний опыт преподавания авторами дисциплины «Управление рисками» на отделении программной инженерии Высшей школы экономики.Книга предназначена для студентов магистратуры, обучающихся по направлениям 080500.68 «Бизнес-информатика» и 231000.68 «Программная инженерия», а также для ИТ-специалистов, разработчиков и заказчиков программных продуктов, менеджеров ИТ-проектов.
Если вы работаете в туристическом бизнесе, вам обязательно стоит прочесть эту книгу, чтобы обогатить свой опыт советами и подсказками профессионала-практика, который не понаслышке знает, как получать хорошую прибыль с минимальными финансовыми вложениями.
В современных условиях высока потребность рынка труда в специалистах-управленцах разного уровня. От уровня профессиональной подготовки и личностных качеств менеджера напрямую зависит успех компании.Книга посвящена общению в деятельности менеджера. Здесь подробно рассказано о коммуникабельности менеджера, деловой беседе, публичных выступлениях менеджера, деловых совещаниях и заседаниях, деловых переговорах, технике переговорного процесса, сохранении имиджа менеджера в спорах и конфликтах, а также об особенностях международного партнерства.