Я не волшебник, я только учусь

Позавчера одна из моих студенток показала картинку:

Она очень боялась, что не пройдет курс, но справилась!

А еще за день до этого я прочитала в книге Светланы Ивановой "Искусство подбора персонала" замечательную цитату:

ЗНАНИЕ и НАВЫК — принципиально разные вещи. Для того, чтобы НАУЧИТЬСЯ применять все те методы, которые мы рассмотрим, надо много ТРЕНИРОВАТЬСЯ и осваивать их ПОСТЕПЕННО, выбрав для начала те подходы, которые наиболее актуальны именно для вас, в дальнейшем добавляя все новы и новые методы и подходы.

Подходит к любому обучению, не только к материалу книги.

Мои студенты переживают, когда не получается красиво оформить чек-лист или правильно сформулировать название для бага. Но это не беда. Когда что-то не получается — это абсолютно нормально! Именно ради этого мы и приходим на курсы — чтобы оступиться и подняться под присмотром тренера.

Какой смысл платить деньги за курс, на котором все задания выполняются с первого раза и ничего нового не узнаешь? Нет, фишка обучения именно в том, чтобы начать тренироваться. Начать нарабатывать НАВЫК, имея хоть какое-то ЗНАНИЕ.

При этом обратите внимание на слово "постепенно" → все сразу вы не усвоите при всем желании. Именно поэтому в статье "Что делать после окончания курсов для начинающих тестировщиков" я рекомендую не проходить новых курсов ближайший месяц после выпуска. Сначала надо дать устояться тем знаниям, которые уже получены. Попробовать их поприменять в реальной работе, попрактиковать. Иначе это все просто забудется. Да, классно и здорово узнать за один раз много нового. Только через неделю 90% забудется. Учитесь постепенно.

Выпусники курсов делятся своим опытом, как нарабатывать навык на работе и дома:

Студент А: Кстати, еще отметила, что очень здорово читать, когда уже работаешь на каких-то проектах в данный момент. У меня все как-то автоматически мысленно переносится на то, что я делаю сейчас и появляется много новых идей.

Студент Б: Я без контекста вообще ничего не запоминаю) У меня есть подруга, которая от IT в принципе далека, я придумываю какие-нибудь аналогии не про софт и ей рассказываю, что я прочитала или выучила, на этих аналогиях, так лучше оседает в голове. Иначе, если не применяется, ничего не остается. Меня мой преподаватель по танцам этому научил) Пришли домой - заколебите всех домашних рассказом, что вы сегодня узнали, даже если не будете тушкой тренироваться, мозг запомнит)

Я от себя добавлю парочку способов, как набирать опыт — для тех, кто еще не устроился на работу, а домашних уже задолбал 

А еще добавлю, что все мы профи в одном деле, но новички в другом. Не бойтесь учиться, не бойтесь оступаться, не бойтесь задавать вопросы!

Для студентов я — крутой гуру, который давно варится в области тестирования. Но для Максима Ильяхова я — простой студент, который делает глупые ошибки. Да, да, я тое не идеальна! 

Я прошла курс по информационному стилю и редактуре текста и теперь учусь писать полезные блог-посты в инфо-стиле. Получается не всегда. И не сразу. Далеко не сразу. Примеры:

• Что такое тест-кейс — Статью писала 2 недели. Писала, а потом по комментариям коллеги переделывала. И так несколько раз.
• Как заводить задачи — Написала статью еще на курсе по инфостилю. Потом доработала, принесла на встречу-обсуждение (проводятся в коворкафе раз в месяц). Тестировщиков в кафе не было, но пара ребят сказали мне "СПАСИБО! Очень полезная статья!". При этом по редактуре комментариев набралось штук 15 :) Переделала. Потом еще раз и еще. В итоге спустя месяц принесла на очередную встречу, опять получила фидбек "Крутая статья! Я уже узнала много нового", но опять набрали комментариев по редактуре. Перед публикацией снова дорабатывала.

Хорошие вещи не делаются с полпинка и с первого раза  Эта мысль утешает меня ))))

В следующий раз, когда будете в 10 раз переделывать очередной ДЗ на курсе, помните — вы не одиноки! Мы все чему-то учимся и все ошибаемся и переделываем, и переделываем, и снова переделываем. Это - нормально. Смотрите на картинку и помните о цели. И все будет хорошо 

Как заводить задачи в баг-трекер

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

1. Выберите тип

Разработчики не боги, они не могут делать все и сразу. Им нужно понимать, с чего начинать. Они сортируют задачи по типу — сначала новые функции, потом ошибки, потом все остальное.

Какие бывают типы задач:

• Баг — ошибка в программе.
• Улучшение — все ок, но хотим с перламутровыми пуговицами.
• Новая разработка — такой возможности нет, а очень хочется.

Допустим, заказчик захотел новую возможность, а вы завели ее не как новую возможность, а как баг. Разработчики весь месяц делали другие новые функции, и до вашей не добрались. Заказчик в ярости: вы же обещали... А виноват постановщик задачи — умей выбирать тип!

Баг	Улучшение	Новая разработка
Ошибка 500 при загрузке xlxs файла	Загружать файлы драг-н-дропом	Возможность грузить сразу несколько файлов
Город “Москва” исправляется на “Масква”	Выводить код ФИАС в результатах разбора адреса	Обработка иностранных адресов
Нет подсказок по букве "Б" на английской раскладке	Распознавать не переключенную раскладку в подсказках для email	Транслитерация в подсказках
При загрузке файла большого размера сообщение об ошибке “некорректный тип”	Увеличить ограничение на размер загружаемого файла до 30Мб	Загрузка файлов формата .djvu

Осторожнее с ошибками. Разработчик не любит слышать, что в его детище что-то не так. Он будет топать ногами и кричать “Это не баг и исправлять его не надо”. Финт ушами — ставьте улучшения вместо некритичных ошибок.

Системный архитектор реагирует на появление ошибки

2. Локализуйте проблему

Локализация — это поиск первопричины.

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

Почему студенты задают много вопросов по второму и третьему разу?

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

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

Выдержка из книги:

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

— тема поддерживается с огромным энтузиазмом (один из кандидатов даже рассказал мне, что у него есть собственная классификация тупых пользователей);

— тема поддерживается, но частично, т.е. кандидаты говорят о том, что пользователи бывают разные, среди них есть и хорошие (умные, вежливые...), а есть и другие (не понимают с первого раза, несколько раз переспрашивают об одном и том же, не очень вежливы...), т.е. кандидат занимает компромиссную позицию;

— кандидат дает положительную оценку пользователям (пример такого ответа: "Каждый просто профи в своей области, бехгалтер не обязан отлично разбираться в информационных технологиях, как я не должен разбираться в бухучете"). Кстати, молодой человек, давший этот ответ, был взят на работу и в деле действительно проявлял именно такой подход, т.е. ответ не был социально-желательным.

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

Пример из книги:

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

Я много общаюсь с пользователями. Как по работе, так и в виде тренера. Своих Заказчиков очень люблю, поэтому читать эти примеры было смешно.

И стыдно. Потому что задавать вопросы для студентов тоже нормально. Нормально не понять с первого раза. Я это знаю и стараюсь учитывать, стараюсь помнить о своем "проклятье знания". Но на прошлой неделе у меня было 30 студентов (в два раза больше обычного потока) и каждый второй задавал вопросы по несколько раз. И периодически казалось, что они специально издеваются, ведь по онлайн общению сложно понять, пытался человек или даже не пробовал.

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

Дзэн и искусство ухода за мотоциклом. Роберт Пёрсинг

Ссылка на OZON.

Роман о качестве. Как тестировщик, я просто не могла пройти мимо 

Автор рассказывает, как отправился с маленьким сыном в 17-дневную поездку на мотоцикле. В процессе езды он устраивал "нечто вроде шатокуа". Шатокуа — традиционный слет учителей и ораторов с публичными лекциями, концертами и театральными постановками (по названию озера Шатокуа в штате Нью-Йорк, где такой слет впервые провели в 1874 г).

Но, конечно, главный герой ни с кем у озера не встречался. Он просто думал о разных вещах. Мне нравится это слово. Я тоже люблю шатокуа, когда идешь вдоль парка, вокруг тихо, красиво, хорошо... Можно спокойно подумать. О важном и неважном.

Мне понравилось, как автор начал уходить в философию. Едет он с друзьями в поход на мотоциклах. Он изучил свой мотоцикл вдоль и поперек и чинит его сам. После того, как "специально обученные люди" на его глазах чуть не разломали машину напрочь. Увы, такие "профессионалы" есть в любых сферах деятельности. А друг главного героя к своему мотоциклу прикоснуться боится. Только механики, "сам не полезу".

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

Это очень похоже на тестирование. Если заметить только саму проблему, не докопаться до ее первопричин, то фикс не поможет. Ну удалят сорняк с поверхности, не затронув корень, он вырастет снова, причем в другом месте.

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

К тому, как это делать, автор приходит в конце книги. Он рассказывает на примере мотоцикла, но это не суть важно. Очень понравилась цитата:

Все решения просты — после того как их найдешь. Но они просты, лишь когда знаешь, каковы они.

Подходит не только для тестирования, но и для обучения. Моих студентов периодически клинит на простых вещах. Когда мы вместе выводим ответ, они сильно удивляются "Это так просто! Почему я сразу так не сказал(а)?".

А в тестировании? Нашел проблему, не можешь локализовать. Ищешь, ищешь, ищешь... А потом находишь элементраный ответ! Но он элементарен только тогда, когда ты его уже знаешь.

А чтобы найти этот элементарный ответ, нужна сметка. Так автор называет состояние вроде потока. Когда увлечен идеей, когда работаешь с удовольствием — тогда результаты всегда лучше.

Есть много ловушек сметки. Это и мандраж, и скука, и многие другие. Особое внимание хочется остановить на скуке. Если заскучал — прервись! Отдохни! Попей чай, кофе, погуляй, сходи в кино, поспи. Все, что угодно, только прервись. Иначе результата не будет.

В общем, много хороших мыслей в книжке. И полезных 

Но до чтения "Дзена" надо дорасти. Мне книга далась тяжело, потому что философией как таковой я не очень увлекаюсь. Я слышала вдохновенные отзывы о том, как читаешь роман и проникаешься идеей и рассчитывала на книгу аля "Цель". Вот там читаешь увлекательную историю и умудряешься делать мудрые выводы. А тут читаешь не сильно увлекательную историю, потому что истории как таковой мало, большинство времени отдано под шатокуа.

Но тут уже "на вкус и цет все фломастеры разные" ©

PS - Добавила книгу в общий список прочитанных мною книг.

Денежный тур (The Money Tour)

Предисловие

У туристов должна быть веская причина поехать в конкретное место. В Лас-Вегасе это казино и стрип-клубы, в Амстердаме — кофейные магазины и улица красных фонарей, в Египте — пирамиды. Уберите эти достопримечательности, и туристы уйдут тратить деньги в другое место.

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

Тестировщик денежного тура:

• ходит на демонстрации,
• смотрит продающие продукт видеоролики,
• общается с Заказчиками.

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

Мощная вариация тура — Тур Скептичного Заказчика (Sceptical Customer Tour). Выполняем Денежный Тур, но представляем, что Заказчик постоянно останавливает демонстрацию и спрашивает "Что, если..?".

• Что, если я захочу сделать так?
• Как я должен делать это?

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

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

В Дадате пользователи платят за:

1. Стандартизацию данных через файл или API.
2. Подсказки.

Начнем со стандартизации.

Проверяем все, что связано с деньгами? Пополним счет, обработаем файл и проверим списание средств? Неверно! Туристы приезжают посмотреть на пирамиды, а не отдать деньги экскурсоводу. Конечно, будет печально, если их не пустят внутрь, так как сломался аппарат приема денег. Но это не главное в туре. Нет пирамид — неважно, работает денежный аппарат или давно сломался.

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

Итак, какая проблема у пользователя? Есть клиентские данные, записанные абы как. Необходимо привести их к единому виду и исправить опечатки.

Пользователь платит за то, что:

• Данные стандартизируются — нужно побольше разных кейсов придумать, в каком виде эти данные могут поступать. Например, в исходной системе на форме ввода адресов надо вводить отдельно город, отдельно улицу и т.д. Для обработки в Дадате система склеивает адрес из кусочков. Это могут быть разные разделители (точки, запятые, пробелы), могут быть разные обозначения полей “ул. Московская”, “улица Московская”, “Московская улица”. И я как пользователь хочу платить деньги, зная, что Дадата справится с моим форматом выгрузки.
• Данных может быть много в ширину — Ну вот мои пользователи заводят по 10 адресов и 10 телефонов! Дадата должна их обработать, а не отрезать “лишние” колонки.
• Данных может быть много в высоту —200 тысяч разных данных в одном файле тоже не должно стать проблемой при наличии денег.

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

Не путайте денежный тур с туром оплаты. Лучше вспомните о вариации скептичного Заказчика:

— А что, если я загружу файл txt, но в формате csv?
— Мы все обработаем, смотрите! *демонстрация*

— А что, если у моих пользователей по 5 адресов? Вы можете осилить только один?

— Нет, что вы, ограничений пока нет, загружайте все!

— А что, если в фамилии мои операторы часто опечатываются?

— Мы исправляем большинство опечаток, давайте посмотрим на вашей тестовой выборке?

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

И только после проверки функционала стоит убедиться, что пользователи смогут за него заплатить. Теперь обратим взор непосредственно на деньги:

— Можно пополнить баланс из личного кабинета.

— Можно пополнить баланс, начав грузить файл (если средств для обработки хватит только на половину).

— Скидки работают, но не применяются внутри одного файла (если обработали 120 тысяч, цена 9 коп начнется со следующего файла)

Функционал проверили, деньги проверили. На этом всё.

Теперь перейдем к подсказкам.

Внимательно читаем продающий текст на странице и делаем выводы, за что платят пользователи.

И опять начинаем с функционала. Нам не нужны хитрые классы эквивалентности “а что, если ввести китайские иероглифы, спецсимволы…?”. Думайте о позитивных сценариях. Думайте о том, что будете показывать на демонстрации, чем будете гордиться? “А еще мы умеем так и вот так!”. Если вы разрабатываете продукт, вы наверняка знаете о том, что он умеет.

Но если вы пришли на середине проекта, и у вас нет идей, то вспомните о скептичном Заказчике и попробуйте ответить на все его “а что, если…”:

— А что, если я введу короткое имя? У меня в классе училась девочка Янг!

— А что, если я введу составное имя?

— А что, если я знаю только название организации? Понятия не имею об ИНН, ОГРН и прочих вещах?

— А что, если я не помню точное название улицы?

— А что, если… ?

И только проверив тот функционал, за который стоит платить, убедитесь, что за него можно заплатить. Пожалуй, все! Хотя задачка не для пары часов, а для нескольких сессий! А ведь казалось бы, просто денежный тур…

<< Тур по путеводителю. The Guidebook Tour

>> Тур по ориентирам. The Landmark Tour

Вернуться к полному списку туров

PS: Статья написана в помощь студентам моих курсов по тестированию. Изучайте новое, не стойте на месте!

PPS: Статья сохранена на Testbase, чтобы не потерялась ссылка.

Exploratory software testing. James Whittaker

Книга на Amazon.

Must read для тестировщика! Причем любого уровня:

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

Тестировщикам с опытом поможет взглянуть на свои проекты по новому. Поможет избежать проблемы "замыленного взгляда".

Мои заметки по книге — Как искать баги — исследовательские туры Виттакера.

Джеймс Витаккер рассказывает о том, как посмотреть на тестирование по-новому. Его идея — прдеставить себя туристом и идти по заданному маршруту. Это помогает разделить работу между разными людьми. Если просто дашь задание "потестируй приложение", тестировщики будут пересекаться между собой. А если обозначить перед ними цель тура, они будут исследовать каждый свою зону, каждый со своей колокольни.

Из особо понравившегося в книге:

The price of entry is low, but the road to mastery is difficult

Стать тестировщиком может каждый. А вот стать мастером в своей области — это надо уметь!

Интересный факт о тестировании игр для XBox - там много всего скрыто (hidden элементы). Программисты выводили всю скрытую информацю в игре, чтобы тестировщики видели, на что влияют их действия. Это помогало им тестировать быстрее и умнее. Очень любопытный пример, хорошая практика!

А как тренер, я не могла пройти мимо этой цитаты:

However, i would add that no matter what practical experiance you may have, you never really know a subject until you have to teach it. There are so many nuances to engineering endeavors that we don`t think about except at an intuitive level. Having to explain those nuances to someone else is a lot harder than it sounds.

Сколько бы реального опыта у тебя не было, ты никогда не познаешь тестирование, пока не начнешь преподавать его. Есть столько разных нюансов, о которых ты даже не задумываешься, применяя на интуитивном уровне. Объяснение этих нюансов кому-либо другому — работа намного сложнее, чем кажется.

Когда я начинала вести свои курсы для начинающих тестировщиков, я думала, что это будет легко. Но как только я начала преподавать, только тогда и познала всю глубину своего проклятья знания. К тому же некоторые вопросы студентов ставят в тупик. Ты не знаешь, как это объяснить — это маячок, что ты плохо разбираешься в теме. Копаешь вглубь и вот уже ты знаешь больше, чем раньше.

Или даже когда выступаешь на конференции. Вот вроде знаешь, как идет процесс в компании. Знаешь, как пишутся автотесты. Но, когда это надо объяснить "с нуля", начинаешь понимать, как много ты еще не знаешь. В итоге как в том анекдоте:

Ну и глупые школьники сегодня попались! Объяснил тему — не поняли. Объянил еще раз — не поняли. Объяснил третий раз — сам уже понял, а они не поняли!

Так что просто попробуйте объяснить свежевыученные знания другим. Устройте мини-конференцию или обучение у себя в компании. Коллегам приятно, и вам полезно!


С разрешения автора я публикую в блоге вольный перевод 4 главы его книги, посвященной собственно турам. Но настоятельно рекомендую прочитать всю книжку. Там ведь не только 4 глава. Есть много другого интересного. Есть опыт применения этих туров в Microsoft, есть невыпущенные статьи, размышления на тему будущего тестирования, есть... Да много чего есть. Прочитайте и узнаете!

PS - Добавила книгу в общий список прочитанных мною книг.

Человеческий фактор. Том де Марко и Тимоти Листер

Ссылка на OZON.

Книга для менеджеров о провалах проектов и о том, как сделать работу лучше за счет улучшения качества жизни людей. Написана известными консультантами с богатым жизненным опытом, поэтому все утверждения обосновываются на реальных примерах, что хорошо!

Начиная с 1977 года, авторы проводили исследования проектов по разным параметрам. В том числе узнавали причину провала (если он проваливался). И выяснили, что в подабляющем большинстве случаев не было ни одной объясняющей неудачу причини из области технологий! Проблема всегда в людях, почти всегда в политике. Стоит задуматься! Поэтому книга и называется "человеческий фактор", от него зависит очень многое.

Вторая глава книги посвящена офису. Тому, как лучше всего рассаживать людей. Осуждаются ужасные опен-спейсы, в которых окна есть только в коридорах, где никто не бывает. А сидят все в маленьких комнатушках. Авторы подмечают забавную вещь — покупаются такие пространства как "очень гибкие", но предложение применить гибкость и расставить комнатки по-другому вызывает дикий батхерд, "как же так!!! нельзя!!!". Читать забавно 

А дальше авторы говорят о тайм-менеджменте. О том, как раздражают телефоны и прочие прерывания. О том, как счастливы люди, которые могут себе позволить выключить телефон. Это немного странно читать, сейчас в офисах обычно нет проблем с отключением звука, Заказчику всегда можно перезвонить. Приводится хороший пример из жизни разработчицы: 3 минуты пишет код, потом отвлекает телефонный звонок на 3 минут. Еще 3 минуты пишет код, потом заходит поболтать начальник на такое же время. Еще 3 минуты пишет код, потом коллега задает вопрос... И так далее. Продуктивная работа? Нет, не очень.

В наше время большую популярность приобрели мессенджеры и электронная почта, потому что они позволяют работать в потоке, отключив телефон. Поработал полчасика — проверил почту/скайп. Намного эффективнее прерываний раз в 5 минут.

Правильный пример приводится о собеседованиях. Недостаточно просто спросить "вы умеете кодить на Java / составлять чек-лист?". Пока вы не увидите кандидата в действии, вам ничего не скажут его ответы. Именно поэтому на собеседовании тестировщикам даются небольшие задания — чтобы увидеть, на что он способен. Начинающие могут принести свои тест-кейсы или чек-листы, чтобы собеседующий увидел красоту описания и широту мышления, оценил внешний вид и наполнение.

Но нанять сотрудника недостаточно. Их надо еще удержать. Надо быть компанией, в которой хочется работать. Надо быть лучшей компанией. А лучшие компании не похожи между собой, они достигают этого каждая по своему. Так что не ищите серебряной пули у других, придумайте лучше свою!

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

Яркий пример — нотариус приносит генеральному документы на подпись и тот собирается расписаться. Нотариус просит почитать документ, но тут уже удивляется директор "я не читаю документы". Тогда сотрудник просит дать ему время еще раз перечитать. Люди настолько привыкают, что им не верят, что за ними все перепроверяют, что считают это нормальным и расслабляются. Ну допущу я ошибку, и что? Шеф заметит. А вот если шеф тебе всецело верит, приходится быть на уровне!

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

Книжка мне понравилась. Да, частично она уже устарела. Да, что-то не подходит лично мне (я не работаю в опен-спейсе, поэтому раздел про офис читала как сказку на ночь). Но в книге есть много полезных и умных вещей. Которые менеджеру могут быть очень полезны! Ведь главное — чтобы книга попала в твою ситуацию, в твою боль, твою проблему. Тогда вынесешь много пользы из абзаца, который в другой ситуации даже не заметил бы.

Читается легко, написана интересно. Почитайте, она может оказаться вам весьма полезной!

PS - Добавила книгу в общий список прочитанных мною книг.