Заметки консультанта

Шамрай Александр Владимирович

Archive for the ‘Книги’ Category

USE-CASE 2.0. Заключение

Posted by Shamrai Alexander на Декабрь 9, 2018

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

Сценарий использования 2.0:

  • Легкий – в его определении и применении.
  • Масштабируем – и подходит для команд и систем всех размеров.
  • Универсален – и подходит для всех типов систем и подходов разработки.
  • Прост в использовании – модели сценариев использования могут быть быстро сформированы и слайсы созданы для покрытия требований команды.

Сценарии использования 2.0 в этом руководстве является бесплатным и публичным. Разделы Сценария использования 2.0 «С чем работать» и «Что делать» являются договорными. Хотя возможно применить только части Сценария использования 2.0, результаты будут неопределенными и практика не будет являться Сценарием использования 2.0.

Это руководство намеренно представлено легким и может быть недостаточным для вас, чтобы адаптировать практику. Дополнительная информация доступна в виде полностью задокументированных практик и веб-публикаций на сайте www.ivarjacobson.com. Она предлагается как отдельный веб сайт или расширение для EssWork.

Это первая из многих публикаций по Сценарию использования 2.0, но вы можете найти много других статей, технических документов и блогов по этому вопросу, опубликованных на www.ivarjacobson.com.

Posted in Книги, Полезное, Разное, Стандарты и методологии, Требования, Управление требованиями | Отмечено: , , | Leave a Comment »

USE-CASE 2.0. Об Авторах

Posted by Shamrai Alexander на Декабрь 9, 2018

Ивар Якобсон

Доктор Ивар Якобсон — отец компонентов и архитектуры компонентов, сценариев использования, аспектно-ориентированной разработки программного обеспечения, современного бизнес инжиниринга, Unified Modeling Language и Rational Unified Process. Его последним вкладом в индустрию программного обеспечения является концепция формальной практики, которая продвигает практики как «объекты первого класса» в разработке программного обеспечения и рассматривает процесс просто как совокупность практик. Он является основным автором шести влиятельных и самых продаваемых книг. Он является основным спикером на многих крупных конференциях по всему миру и обучил несколько консультантов по улучшению процессов.

Айян Спенс

Айян является главным техническим директором в Ivar Jacobson International, где он специализируется на гибком применении Unified Process. Он является сертифицированным практиком RUP, ScrumMaster-ом и является опытным тренером, поработав в 100-е проектов внедрения итеративный и гибких методов. Он имеет более чем 20 лет опыта в индустрии программного обеспечения, который охватывает полный жизненный цикл разработки, включая определение требований, архитектуру, анализ, проектирование, разработку и управление проектами. Его вопросами специализации являются итеративные проекты, работа с гибкими командами и управление требованиями через сценарии использования. В роли технического директора Айян способствует техническому направлению Ivar Jacobson International и работает с технологическим офисом компании для определения следующего поколения современных, активных практик разработки программного обеспечения. Он является лидером проекта и процессным архитектором разработки Essential Unified Process и практик, которые он содержит. Когда он не работает над исследованиями, поиском и определением практик, он проводит свое время, оказывая помощь компаниям в создании и выполнении программ изменений для повышения потенциала разработки программного обеспечения. Он является соавтором книги Addison Wesley «Use Case Modeling» и «Managing Iterative Software Development Projects».

Биттнер Курт

Курт – главный технический директор Ivar Jacobson International Северной и Южной Америки. Он проработал в индустрии программного обеспечения более чем 25 лет в различных ролях, включая разработчика, руководителя группы, архитектора, руководителя проекта и бизнес-лидера. Он вел гибкие проекты, запустил большой отдел разработки программного обеспечения для компании, спас и развил несколько стартапов, выполнял приобретения и работал с клиентами в различных отраслях промышленности, включая аэрокосмическую, финансы, энергетику и электронику. Он внес ключевой вклад в раннюю разработку Rational Unified Process, а также, совсем недавно, проект IBM Jazz. Его опыт включает в себя значительную работу в банковской сфере и финансов, проектирование и разработку архитектуры систем реляционных баз данных, консалтинг и наставничество широкого спектра клиентов по улучшении стратегии и подходов разработки программного обеспечения. Он является соавтором книг «Use Case Modeling», «Managing Iterative Software Development Projects» и «The Economics of Iterative Software Development».

Posted in Книги, Полезное, Разное, Стандарты и методологии, Требования, Управление требованиями | Отмечено: , , | Leave a Comment »

USE-CASE 2.0. Библиография

Posted by Shamrai Alexander на Декабрь 9, 2018

Object Oriented Software Engineering: A Use Case Driven Approach

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, Gunnar Overgaard

Оригинальная книга, которая представила миру сценарии использования.

  • Publisher: Addison-Wesley Professional; Revised edition (July 10, 1992)
  • ISBN-10: 0201544350
  • ISBN-13: 978-0201544350

The Object Advantage: Business Process Reengineering With Object Technology

Ivar Jacobson, Maria Ericsson, Agneta Jacobson

Полное руководство по использованию сценариев использования для реинжиниринга бизнес-процессов.

  • Publisher: Addison-Wesley Professional (September 30, 1994)
  • ISBN-10: 0201422891
  • ISBN-13: 978-0201422894

Software Reuse: Architecture, Process and Organization for Business Success

Ivar Jacobson, Martin Griss, Patrik Jonsson

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

  • Publisher: Addison-Wesley Professional (June 1, 1997)
  • Language: English
  • ISBN-10: 0201924765
  • ISBN-13: 978-0201924763

Use-Case Modeling

Kurt Bittner and Ian Spence

Полное руководство для создания модели сценариев использования и написания хороших вариантов использования.

  • Publisher: Addison-Wesley Professional; 1 edition (August 30, 2002)
  • ISBN-10: 0201709139
  • ISBN-13: 978-0201709131

Aspect-Oriented Software Development with Use Cases

Ivar Jacobson and Pan-Wei Ng

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

  • Publisher: Addison-Wesley Professional; 1 edition (January 9, 2005)
  • ISBN-10: 0321268881
  • ISBN-13: 978-0321268884

Posted in Книги, Полезное, Разное, Стандарты и методологии, Требования, Управление требованиями | Отмечено: , , | Leave a Comment »

USE-CASE 2.0. Благодарности

Posted by Shamrai Alexander на Декабрь 9, 2018

Общие

Сценарий использования 2.0 подготовлен на основе признанных передовых практик, используемых и проверенных десятилетиями. Мы хотели бы поблагодарить десятки тысяч людей, которые повседневно используют сценарии использования в своих проектах, и в частности тех, которые делятся своим опытом внутри и вне их собственных организаций. Без всей их напряженной работы и энтузиазма мы не имели бы мотивации или понимания необходимости эволюции этой техники. Мы надеемся, что вы найдете это небольшое электронное пособие полезным и продолжите оценивать и адаптировать способы применения сценариев использования.

Людям

Мы также хотели бы поблагодарить всех, кто непосредственно способствовал созданию этой книги, включая, но без определенного порядка: Пол Мак-Магон, Ричард Скафф, Эрик Лопес Кардосо, Сванте Лидман, Крейг Люций, Тони Людвиг, Рон Гартон, Буркхард Перкинс-Голомб, Арран Хартгровес, Джеймс Гэмбл, Брайан Хупер, Стефан Байлунд и Пан Вэй Нг.

Posted in Книги, Полезное, Разное, Стандарты и методологии, Требования, Управление требованиями | Отмечено: , , | Leave a Comment »

USE-CASE 2.0. Глоссарий

Posted by Shamrai Alexander на Декабрь 9, 2018

Альтернативный поток: Описание варианта или необязательного поведения в рамках повествования сценария использования. Альтернативные потоки определяются в отношении к основному потоку сценария использования.

Аспектно-ориентированное программирование: Технология программирования, которая стремится повысить модульность через обеспечение разделения сквозных ответственностей (см. http://en.wikipedia.org/wiki/Aspect-oriented_programming).

Диаграмма сценариев использования: Диаграмма, показывающая набор субъектов и сценариев использования и их взаимосвязи.

Заинтересованное лицо: Лицо, группы или организация, которая затрагивает или затрагивается программной системой.

Заказчик: Заинтересованная сторона, которая оплачивает развитие системы или которая, как ожидается, купит систему после ее завершения.

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

Модель сценариев использования: Модель всех полезных способов использования системы и значение, которое они будут обеспечивать. В основном модель сценариев использования состоит из ряда субъектов, набора сценариев использования и схемы, иллюстрирующей их взаимоотношения.

Основной поток: Описание обычного, ожидаемого пути сценария использования. Это путь, в котором большинство пользователей проводит большинство времени. Это наиболее важная часть повествования варианта использования.

Повествование сценария использования: Описание сценария использования, которое рассказывает историю о том, как система и ее субъекты работают вместе для достижения определенной цели. Она включает в себя последовательность действий (включая различные варианты), выполняемые системой и ее субъектами для достижения цели.

Пользователь: Заинтересованное лицо, которое взаимодействует с системой для достижения своей цели.

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

Приложение: Компьютерное программное обеспечения, призванное помочь субъектам в выполнении конкретных задач.

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

Разделение ответственности: Процесс расщепления системы для сведения к минимуму дублирования функциональности (см. http://en.wikipedia.org/wiki/Separation_of_concerns).

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

Слайс сценария использования: Слайсом сценария использования является одной или несколько историй, отобранных из сценария использования в форме рабочего элемента, который имеет понятное значение для Заказчика.

Субъект: Субъект определяет роль, которую пользователь может представлять при взаимодействии с системой. Пользователь может быть лицом или другой системой. Субъекты имеют имя и краткое описание, и они связаны со сценариями использования, с которыми они взаимодействуют.

Сценарий использования: сценарий использования – это все пути использования системы для достижения определенной цели для определенного пользователя.

Сценарий использования 2.0: Масштабируемая, гибкая практика, которая использует сценарии использования для определения набора требований и направления инкрементальной разработки системы для их реализации.

Тестовый сценарий: Тестовый сценарий определяет набор тестовых входных данных и ожидаемых результатов с целью оценки правильно ли работает система.

Требования: Что программная система должны делать для удовлетворения заинтересованных сторон.

Элемент системы: Единица набора элементов, который представляет собой систему (ISO/IEC 15288:2008).

Posted in Книги, Полезное, Стандарты и методологии, Требования, Управление требованиями | Отмечено: , , | Leave a Comment »

Записки мистера Томпкинса из романа об управлении проектами «Deadline»

Posted by Shamrai Alexander на Август 17, 2010

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

Безопасность и перемены

  1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
  2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
  3. Неуверенность заставляет человека избегать риска.
  4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
  5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.

Отрицательная мотивация

  1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
  2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
  3. Более того, если люди не справятся, вам придется выполнить свои обещания.

Части тела, необходимые для управления проектами

  1. Для руководства нужны сердце, нутро, душа и нюх
  2. Так что:
    • руководить надо сердцем;
    • чувствовать нутром;
    • вкладывать в команду и проект душу;
    • иметь нюх на всякую ерунду и бессмыслицу.

Главнокомандующий на поле битвы, как метафора управления проектами.
К началу сражения работа главнокомандующего уже закончена.
Собеседование и прием на работу.

  1. Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (по большей части последнее).
  2. Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
  3. Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
  4. Попросите наводку — тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
  5. Больше слушайте, меньше говорите.
  6. И все это сработает еще лучше, если вы слегка подтасуете колоду.

Повышение производительности

  1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
  2. Повышение производительности — результат долгосрочных усилий.
  3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко» .

Управление рисками

  1. Чтобы управлять проектом, достаточно управлять его рисками.
  2. Создайте список рисков для каждого проекта.
  3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
  4. Оцените вероятность возникновения и стоимость каждого риска.
  5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
  6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
  7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.

Играй в защите

  1. Сокращайте потери.
  2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
  3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
  4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
  5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
  6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
  7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
  8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.

Моделирование процесса разработки

  1. Моделируйте свои предположения и догадки о том, как пойдет процесс работы.
  2. Обсуждайте эти модели вместе с партнером, чтобы лучше понимать процесс работы и вносить необходимые исправления.
  3. Предсказывайте результаты работы с помощью модели.
  4. Сравнивайте результаты, полученные в процессе моделирования, с реальными.

Извращенная политика

  1. В любой момент нужно быть готовым отказаться от работы и попросить расчет…
  2. …однако это не означает, что тем самым вы сумеете избежать последствий извращенной политики.
  3. Извращенная политика достанет вас везде, даже в самой здоровой и чистой организации.
  4. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании.
  5. Это может произойти даже тогда, когда личные цели напрямую противоречат целям организации.
  6. Один из побочных эффектов извращенной политики: иметь хорошо укомплектованную команду становится небезопасно.

Сбор метрических данных

  1. Определяйте размер каждого проекта.
  2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
  3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
  4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
  5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
  6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
  7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
  8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.

Процесс разработки и его улучшение

  1. Хороший процесс разработки и его постоянное улучшение — весьма достойные цели.
  2. Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.
  3. Формальные программы, направленные на улучшение существующего процессе разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
  4. Можно надеяться получить положительный результат от одного какого-нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
  5. Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего приведут к тому, что сроки только увеличатся.
  6. Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
  7. Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).

Делать работу по-другому

  1. Есть только один способ сократить время на разработку, когда его и без того мало — уменьшить сроки отладки программы.
  2. Проекты с высокой производительностью требуют гораздо меньше времени на отладку и исправление ошибок.
  3. Проекты с высокой производительностью требуют гораздо больше времени на проектирование.
  4. Нельзя заставить людей делать что-то по-другому, если ты о них не заботишься, если ты ими не интересуешься. Чтобы они изменились, ты должен понимать (и ценить) их самих, что они делают и к чему стремятся.

Что дает давление сверху

  1. Люди не начнут быстрее соображать, если руководство будет давить на них.
  2. Чем больше сверхурочной работы, тем ниже производительность.
  3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
  4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
  5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.

Сердитый начальник

  1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
  2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
  3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).

Туманные спецификации

  1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
  2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
  3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.

Конфликт

  1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
  2. Процесс создания и распространения программных систем — прямо таки рассадник всевозможных конфликтов.
  3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
  4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
  5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
  6. Тяжело договариваться. Гораздо легче выступать посредником.
  7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
  8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.

Кто такой катализатор проекта

  1. Существуют люди катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
  2. Посредничество — еще одна сфера, в которой люди катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
  3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»

Человеку свойственно ошибаться

  1. Нам кажется, что самое страшное — не знать чего то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.

О персонале

  1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую то работу).
  2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
  3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
  4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
  5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!

Проблемы социологии

  1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
  2. Каждому проекту нужна какая то церемония или ритуал.
  3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
  4. Защищайте людей от оскорблений и ругани Начальства.
  5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего то очень боятся.
  6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)

О патологической политике (еще раз)

  1. Эту патологию невозможно вылечить снизу.
  2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.
  3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
  4. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.

Злоба и скупость

  1. Злоба и скупость — вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
  2. Злоба и скупость прямо противоположны истинным целям любой хорошей компании — быть щедрыми и заботливыми по отношении к своим сотрудникам.
  3. Когда вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина — страх и боязнь провала.

Основы здравого смысла

  1. У проекта должно быть два срока сдачи — запланированный и желаемый.
  2. Эти сроки должны быть разными.

Posted in Книги, Разное | Отмечено: , , , | Leave a Comment »

 
%d такие блоггеры, как: