Наверняка, вы неоднократно слышали про списки дел (To-Do). Возможно, вы уже когда-то очень давно их использовали и успешно забросили. В чем проблема? По моему мнению, вся проблема в негативной мотивации To-Do. Ведь это дела, которые вы вынуждены сделать. Я предлагаю заменить негатив долга перед самим собой на позитив возможности. И в этой статье, я хочу поделиться с вами списками возможностей. Списками «Я могу!»
«Я могу», далее can-do – это список ваших возможностей. Это не то, что вы должны или вынуждены сделать, это не то, что вы хотите сделать, а именно то, что вы можете сделать. Хотя, конечно же, лучше всего, чтобы желания совпадали с нашими возможностями.
Как в классическом анекдоте:
Этот анекдот наилучшим образом иллюстрирует простейший can-do список, который бы себе записал землекоп, по отношению к работе:
Я могу:
Сейчас самое время дать сухое логичное теоретическое определение, но потерпите немного, я хочу рассказать историю о практическом применении списка Can-Do, и тогда, возможно, определение и не потребуется.
В нашей компании открывался новый проект. Это был пилотный проект, и команде, в которой работал мой знакомый (QA), необходимо было показать наивысший профессионализм и хорошо показать себя и свою работу перед заказчиками. А заказчики, в свою очередь, не спешили делиться с тестировщиками спецификациями и требованиями по проекту. Встретив меня в курилке, мой знакомый сказал: «У меня нет требований по проекту. Я не могу писать тестовые сценарии, а это значит – что я не могу тестировать».
Я и раньше слышал нечто подобное от других людей. Наши люди любят пожаловаться. Но, я не мог понять, где же логика в этом утверждении.
Я заинтересовано слушал этого человека, в надежде, что я все-таки лучше пойму эту огромнейшую проблему и величайшее препятствие в тестировании, о котором он мне говорил. Но, в итоге, я так и не понял. Получается, что единственный способ тестирования – это просмотр требований, анализ спецификаций, создание сценариев тестирования и прохождение тестов. И всё? Во всей вселенной больше нет другого способа протестировать приложение? И если этот Единственный Способ невозможен из-за отсутствия требований, что всё, мы в тупике?
Я задаю эти саркастические вопросы не потому, что я наивный и неопытный новичок, а потому что я уверен в том, что всегда есть другая возможность, другой путь, в любой ситуации. Я и сам сталкивался с подобными «огромнейшими сложностями», и я знаю, что любая задача – решаема.
Вначале одного из проектов, моей задачей было провести нагрузочное тестирование приложения. Вот, только незадача: у меня не было всего необходимого доступа к приложению, я это приложение в глаза никогда не видел. Я не знал, как оно работает. Я не знал, с какими данными оно работает, и понятия не имел о том, как им пользоваться. Я чувствовал, что нахожусь в тупике.
Но, у меня был доступ к физическому серверу приложения. Я мог поговорить с другими участниками проекта. У меня был доступ к документации на Sharepoint, только, к сожалению, документации там было настолько много, что я просто не знал, за что взяться. Но, я видел тоже, что видит сейчас мой знакомый – тупик, а не начало успешной работы над проектом.
Я был очень расстроен. Придя домой с работы, даже не включая компьютер, я включил свет, взял блокнот с ручкой, присел на кровать и спрашивал себя: Что я могу сделать? После первой записи в блокнот, я почувствовал себя лучше, и дело пошло намного быстрее. А записал я вот что:
Тем же вечером, я отправил сам себе email со списком can-do на рабочую почту, и со следующего дня я начал делать все, чтобы начать работу с приложением, и преодолеть препятствия на моем пути. Через пару дней я начал работу и, что немало важно, показал свою заинтересованность в качественном выполнении задания перед начальством. Я вышел из тупика.
А вот теперь вернемся к проблеме моего знакомого, который был уверен в том, что без требований к приложению, он не может создать тест план и начать тестирование. Так и хотелось спросить его: а ты точно не можешь создать тест план без требований? А ты точно не можешь ничего сделать без всей документации?
Но, я ограничился рассказом этой истории. Я не хочу учить людей как им нужно жить. Если он не сможет тестировать и не захочет искать возможности, прерываясь отговорками – это его выбор. Если не может – пусть дальше не может, а я – могу.
Если вы дочитали до этого параграфа, то, скорее всего, задаетесь вопросом: А чем этот твой список Can-Do отличается от старого доброго To-Do? Очень, очень мало чем. Разница лишь в мотивации. Мне гораздо приятней помнить о том, что я могу сделать, чем о том, что я вынужден сделать. А вам?
Что лучше:
Или,
Повторите каждую фразу 10 раз. После какой фразы вам легче будет сделать это? Какую бы фразу выбрал я, вы уже догадались, а какую выберете вы – я не знаю, ведь люди все разные.
Списки Can-Do придают мне энергии. Если я чувствую себя в тупике – то я думаю о том, что я могу сделать, а не о том, что я вынужден или должен сделать.
Так что, если в следующий раз вы почувствуете себя в тупиковой ситуации, то спросите себя, что же вы можете сделать?
P.S: Список Can-Do – это результат мозгового штурма собственного мозга. Лично я предпочитаю текстовый вариант записи списка возможностей, но удобным будет и графический вариант, используя интеллект карты (Mind Maps)
P.S. 2: Списки Can-Do применяются в образовании. Списки Can-Do используются для самооценки учащихся. Такие списки помогают выявить пробелы ученика/студента, в тех навыках, которые он должен был приобрести за период обучения. Это не хитрые экзаменационные тесты, проверяющие знания заковыристыми вопросами, а утверждения, с которыми студент может соглашаться или не соглашаться. Пример:
Автор оригинальной идеи и истории: Karen N. Johnson
Оригинал:
Can-Do List: One way to get unstuck. Really.
Что такое Список «Я могу»
«Я могу», далее can-do – это список ваших возможностей. Это не то, что вы должны или вынуждены сделать, это не то, что вы хотите сделать, а именно то, что вы можете сделать. Хотя, конечно же, лучше всего, чтобы желания совпадали с нашими возможностями.
Как в классическом анекдоте:
Спрашивают у землекопа:
— Мужик, ты что умеешь делать?
— Копать! — отвечает.
— А ещё что?!
— Копать!!!
— Ну, а ещё что-нибудь?!
Обиделся, говорит:
— Могу НЕ копать!
Этот анекдот наилучшим образом иллюстрирует простейший can-do список, который бы себе записал землекоп, по отношению к работе:
Я могу:
- Копать
- Не копать
Сейчас самое время дать сухое логичное теоретическое определение, но потерпите немного, я хочу рассказать историю о практическом применении списка Can-Do, и тогда, возможно, определение и не потребуется.
Как я вышел из тупиковой ситуации и помог своему знакомому тестеровщику
В нашей компании открывался новый проект. Это был пилотный проект, и команде, в которой работал мой знакомый (QA), необходимо было показать наивысший профессионализм и хорошо показать себя и свою работу перед заказчиками. А заказчики, в свою очередь, не спешили делиться с тестировщиками спецификациями и требованиями по проекту. Встретив меня в курилке, мой знакомый сказал: «У меня нет требований по проекту. Я не могу писать тестовые сценарии, а это значит – что я не могу тестировать».
Я и раньше слышал нечто подобное от других людей. Наши люди любят пожаловаться. Но, я не мог понять, где же логика в этом утверждении.
Я заинтересовано слушал этого человека, в надежде, что я все-таки лучше пойму эту огромнейшую проблему и величайшее препятствие в тестировании, о котором он мне говорил. Но, в итоге, я так и не понял. Получается, что единственный способ тестирования – это просмотр требований, анализ спецификаций, создание сценариев тестирования и прохождение тестов. И всё? Во всей вселенной больше нет другого способа протестировать приложение? И если этот Единственный Способ невозможен из-за отсутствия требований, что всё, мы в тупике?
Я задаю эти саркастические вопросы не потому, что я наивный и неопытный новичок, а потому что я уверен в том, что всегда есть другая возможность, другой путь, в любой ситуации. Я и сам сталкивался с подобными «огромнейшими сложностями», и я знаю, что любая задача – решаема.
Вначале одного из проектов, моей задачей было провести нагрузочное тестирование приложения. Вот, только незадача: у меня не было всего необходимого доступа к приложению, я это приложение в глаза никогда не видел. Я не знал, как оно работает. Я не знал, с какими данными оно работает, и понятия не имел о том, как им пользоваться. Я чувствовал, что нахожусь в тупике.
Но, у меня был доступ к физическому серверу приложения. Я мог поговорить с другими участниками проекта. У меня был доступ к документации на Sharepoint, только, к сожалению, документации там было настолько много, что я просто не знал, за что взяться. Но, я видел тоже, что видит сейчас мой знакомый – тупик, а не начало успешной работы над проектом.
Я был очень расстроен. Придя домой с работы, даже не включая компьютер, я включил свет, взял блокнот с ручкой, присел на кровать и спрашивал себя: Что я могу сделать? После первой записи в блокнот, я почувствовал себя лучше, и дело пошло намного быстрее. А записал я вот что:
- Я могу поговорить с ведущим программистом П., возможно он сможет немного рассказать о приложении.
- Я могу поговорить с разработчиками, и спросить их о том, чем они обеспокоены при работе с приложением.
- Я могу попросить повышения уровня моего доступа к приложению у моего менеджера, а если не поможет, то на митинге с заказчиком.
- Я могу начать писать тест план без доступа к приложению. Я знаю, что я буду тестировать, когда у меня будет возможность начать работать с приложением. А потом, я могу подправить план, по мере того, как я буду узнавать новую информацию. Кроме того, набросок плана тестирования поможет мне при разговоре с заказчиком.
- Я могу представить себе, что уже получил доступ к приложению. Так что же я сделаю в первую очередь? А что следующее?
- Я могу поговорить с менеджером проекта, и спросить ее, чего она ожидает от меня.
- Я могу поговорить с другими тестеровщиками, и выяснить у них, какие узкие места есть у приложения, что они думают о тестировании приложения, в общем, все то, что только может быть мне полезным.
Тем же вечером, я отправил сам себе email со списком can-do на рабочую почту, и со следующего дня я начал делать все, чтобы начать работу с приложением, и преодолеть препятствия на моем пути. Через пару дней я начал работу и, что немало важно, показал свою заинтересованность в качественном выполнении задания перед начальством. Я вышел из тупика.
А вот теперь вернемся к проблеме моего знакомого, который был уверен в том, что без требований к приложению, он не может создать тест план и начать тестирование. Так и хотелось спросить его: а ты точно не можешь создать тест план без требований? А ты точно не можешь ничего сделать без всей документации?
Но, я ограничился рассказом этой истории. Я не хочу учить людей как им нужно жить. Если он не сможет тестировать и не захочет искать возможности, прерываясь отговорками – это его выбор. Если не может – пусть дальше не может, а я – могу.
Can-Do против To-Do
Если вы дочитали до этого параграфа, то, скорее всего, задаетесь вопросом: А чем этот твой список Can-Do отличается от старого доброго To-Do? Очень, очень мало чем. Разница лишь в мотивации. Мне гораздо приятней помнить о том, что я могу сделать, чем о том, что я вынужден сделать. А вам?
Что лучше:
Я могу сходить завтра к стоматологу.
Или,
Сходить завтра к стоматологу. (Скрытый смысл: Я вынужден завтра сходить к стоматологу)
Повторите каждую фразу 10 раз. После какой фразы вам легче будет сделать это? Какую бы фразу выбрал я, вы уже догадались, а какую выберете вы – я не знаю, ведь люди все разные.
Списки Can-Do придают мне энергии. Если я чувствую себя в тупике – то я думаю о том, что я могу сделать, а не о том, что я вынужден или должен сделать.
Так что, если в следующий раз вы почувствуете себя в тупиковой ситуации, то спросите себя, что же вы можете сделать?
P.S: Список Can-Do – это результат мозгового штурма собственного мозга. Лично я предпочитаю текстовый вариант записи списка возможностей, но удобным будет и графический вариант, используя интеллект карты (Mind Maps)
P.S. 2: Списки Can-Do применяются в образовании. Списки Can-Do используются для самооценки учащихся. Такие списки помогают выявить пробелы ученика/студента, в тех навыках, которые он должен был приобрести за период обучения. Это не хитрые экзаменационные тесты, проверяющие знания заковыристыми вопросами, а утверждения, с которыми студент может соглашаться или не соглашаться. Пример:
Автор оригинальной идеи и истории: Karen N. Johnson
Оригинал:
Can-Do List: One way to get unstuck. Really.
