Краткое описание уровней Спиральной динамики — различия между версиями

Материал из MaksWiki
Перейти к: навигация, поиск
м
м
Строка 40: Строка 40:
 
А здесь - история тестировщика Васи.
 
А здесь - история тестировщика Васи.
  
: <font color="NavajoWhite">██</font> Потыкать что-нибудь
+
: <font color="NavajoWhite">██</font> '''Потыкать что-нибудь'''
 
:: Вася только-только стал тестировщиком и пришел в компанию и первый раз тестирует программу. Он, конечно, посмотрел описание, но программу не изучил. Тем не менее, ему дали задание протестировать этот релиз и он пытается проверить, ориентируясь на имеющийся документ и свои представления, но, в целом - не понимая, то ли он делает, каков будет результат и боясь, что он будет неудовлетворительным и он не пройдет испытательный срок. И обратиться за помощью он боится по той же причине - компания незнакомая и он не знает, как это повлияет на его оценку.
 
:: Вася только-только стал тестировщиком и пришел в компанию и первый раз тестирует программу. Он, конечно, посмотрел описание, но программу не изучил. Тем не менее, ему дали задание протестировать этот релиз и он пытается проверить, ориентируясь на имеющийся документ и свои представления, но, в целом - не понимая, то ли он делает, каков будет результат и боясь, что он будет неудовлетворительным и он не пройдет испытательный срок. И обратиться за помощью он боится по той же причине - компания незнакомая и он не знает, как это повлияет на его оценку.
: <font color="Violet">██</font> Проверить, как у нас принято
+
: <font color="Violet">██</font> '''Проверить, как у нас принято'''
 
:: Петя, более опытный тестировщик из той же команды и знающий программу, объяснил Васе, что надо проверять в релизе, и Вася это запомнил. И теперь тестирует именно так. А еще Петя сказал, что в компании принято обращаться к коллегам за помощью, особенно когда имеешь дело с чем-то новым. Что лучше спросить, чем сделать неправильно по незнанию. И Вася чувствует поддержку в своей команде - но компания за ее пределами по-прежнему не знакома и внешнего взаимодействия он опасается.
 
:: Петя, более опытный тестировщик из той же команды и знающий программу, объяснил Васе, что надо проверять в релизе, и Вася это запомнил. И теперь тестирует именно так. А еще Петя сказал, что в компании принято обращаться к коллегам за помощью, особенно когда имеешь дело с чем-то новым. Что лучше спросить, чем сделать неправильно по незнанию. И Вася чувствует поддержку в своей команде - но компания за ее пределами по-прежнему не знакома и внешнего взаимодействия он опасается.
: <font color="Red">██</font> Героически проверить все, что смог придумать
+
: <font color="Red">██</font> '''Героически проверить все, что смог придумать'''
 
:: Вася задумывается, что это он все время тестирует одинаково, как ему когда-то объяснил Петя. И начинает пытаться делать разные другие действия в программе. И иногда программа падает, возникают различные ошибки. И вот уже он при тестировании героически нажимает все кнопки подряд, и радуется большому количеству сыплющихся багов. Впрочем, некоторые модули упорно не ломаются, но он - все равно ищет баги. Но при этом после релиза иногда обнаруживаются ошибки в тех функциях, которые он считал надежными и не проверил, или просто не успел, потому что все время потратил на другие части, или просто забыл.
 
:: Вася задумывается, что это он все время тестирует одинаково, как ему когда-то объяснил Петя. И начинает пытаться делать разные другие действия в программе. И иногда программа падает, возникают различные ошибки. И вот уже он при тестировании героически нажимает все кнопки подряд, и радуется большому количеству сыплющихся багов. Впрочем, некоторые модули упорно не ломаются, но он - все равно ищет баги. Но при этом после релиза иногда обнаруживаются ошибки в тех функциях, которые он считал надежными и не проверил, или просто не успел, потому что все время потратил на другие части, или просто забыл.
: <font color="Blue">██</font> Провести проверку строго по регламенту
+
: <font color="Blue">██</font> '''Провести проверку строго по регламенту'''
 
:: Вася понимает, что сначала надо проверять самый важный функционал, а еще - не забывать про множество функций в программе, которые надо проверить. И пишет регламент, по которому дальше тестирует. Регламент становится предметом гордости, все время дорабатывается, и проверка идет строго по нему. Отступление не допускаются, и быстрее - никак нельзя. А еще регламент позволяет поручить проверку людям, которые слабо знают программу, и это - важно, потому что релиз надо протестировать быстро, и на это время хорошо бы подключать других исполнителей.
 
:: Вася понимает, что сначала надо проверять самый важный функционал, а еще - не забывать про множество функций в программе, которые надо проверить. И пишет регламент, по которому дальше тестирует. Регламент становится предметом гордости, все время дорабатывается, и проверка идет строго по нему. Отступление не допускаются, и быстрее - никак нельзя. А еще регламент позволяет поручить проверку людям, которые слабо знают программу, и это - важно, потому что релиз надо протестировать быстро, и на это время хорошо бы подключать других исполнителей.
: <font color="Orange">██</font> Проверить сложные нетривиальные кейсы
+
: <font color="Orange">██</font> '''Проверить сложные нетривиальные кейсы'''
:: Работая над регламентом, Вася постепенно начинает разбираться во внутреннем устройстве программы, связи ее модулей. И зная о доработках, понимает чувствительные точки в других функциях, на которых это может сказаться. Поэтому часто быстро находит нетривиальные ошибкив новом релизе. И это его личное первенство, борьба за количество багов. А вот тестирование по регламенту он отдает другим - это скучно. Пытается переложить на разработчиков, объясняя, что уж минимальную работоспособность они должны проверять сами или жестко высмеивая случающиеся ляпы. Но вот наиболее перспективные для сложных багов места в регламент тестирования не вписываются, ссылаясь на их сложность. Они действительно сложны, но еще это место, в котором баги легко возникают, и он его бережет...
+
:: Работая над регламентом, Вася постепенно начинает разбираться во внутреннем устройстве программы, связи ее модулей. И зная о доработках, понимает чувствительные точки в других функциях, на которых это может сказаться. Поэтому часто быстро находит нетривиальные ошибки в новом релизе. И это его личное первенство, борьба за количество багов. А вот тестирование по регламенту он отдает другим - это скучно. Пытается переложить на разработчиков, объясняя, что уж минимальную работоспособность они должны проверять сами или жестко высмеивая случающиеся ляпы. Но вот наиболее перспективные для сложных багов места в регламент тестирования не вписываются, ссылаясь на их сложность. Они действительно сложны, но еще это место, в котором баги легко возникают, и он его бережет...
: <font color="LawnGreen">██</font> Вместе со всеми тестировать и тестировать
+
: <font color="LawnGreen">██</font> '''Вместе со всеми тестировать и тестировать'''
 
:: Васе таки объясняют, что задачей является не поиск максимального количества багов, а выпуск хорошего релиза, который ждут пользователи. И система тестирования перестраивается, теперь релиз тестируют вся команда вместе, Вася активно участвует в этом своими знаниями и умениями, а места, которые часто ломаются - выписывают и за ними совместно следят. Но, к сожалению, далеко не всегда дружное и совместное тестирование дает нужное качество, в релизе оказываются баги. Особенно когда релиз надо почему-то выпустить срочно, и даже в такой совместной работе команда не успевает все проверить.
 
:: Васе таки объясняют, что задачей является не поиск максимального количества багов, а выпуск хорошего релиза, который ждут пользователи. И система тестирования перестраивается, теперь релиз тестируют вся команда вместе, Вася активно участвует в этом своими знаниями и умениями, а места, которые часто ломаются - выписывают и за ними совместно следят. Но, к сожалению, далеко не всегда дружное и совместное тестирование дает нужное качество, в релизе оказываются баги. Особенно когда релиз надо почему-то выпустить срочно, и даже в такой совместной работе команда не успевает все проверить.
: <font color="Yellow">██</font> Проверить в срок критичные кейсы и новый функционал
+
: <font color="Yellow">██</font> '''Проверить в срок критичные кейсы и новый функционал'''
 
:: Для быстрого и качественного тестирования релизов в системе выделяется критичный функционал, который надо проверять всегда - не как жесткие регламент проверки, а как небольшой чек-лист. Второй чек-лист для каждого релиза свой - это тестирование нового или измененного в нем функционала. Проверку чек-листа при тестировании разбирают члены команды, Вася занимается теми пунктами, которые требуют специальных умений тестировщика. И отвечает за ведение чек-листов.
 
:: Для быстрого и качественного тестирования релизов в системе выделяется критичный функционал, который надо проверять всегда - не как жесткие регламент проверки, а как небольшой чек-лист. Второй чек-лист для каждого релиза свой - это тестирование нового или измененного в нем функционала. Проверку чек-листа при тестировании разбирают члены команды, Вася занимается теми пунктами, которые требуют специальных умений тестировщика. И отвечает за ведение чек-листов.
: <font color="Turquoise">██</font> Проверить с учетом ожиданий заказчика по срокам и функционалу этого релиза
+
: <font color="Turquoise">██</font> '''Проверить с учетом ожиданий заказчика по срокам и функционалу этого релиза'''
 
:: Оказывается, что новый функционал далеко не всегда проверяют так, как предполагается работа с ним пользователей. Кроме того, при высокой скорости выпуска релизов в новом функционале часто возникают недоделки, которые полагают незначимыми. Иногда они действительно являются незначимыми, пользователи используют это редко и могут справится обходными путями. А иногда оказывается, что из-за недоделки выполнение пользователями своих новых функций оказывается недопустимо медленной, и новые возможности практически не могут быть использованы - хотя заказчик на это рассчитывал. Поэтому Вася начинает думать о сценариях предполагаемого использования нового функционала, эргономике работы и сроках выполнения пользователями своих операций по-новому. И возникающие недоработки оценивает именно с этой точки зрения, понимая, какие из них недопустимы в релизе, а что можно отложить до более позднего исправления. Вася понимает, какие функции и когда нужны пользователям в новом релизе и участвует в его планировании и тестировании с учетом этого.
 
:: Оказывается, что новый функционал далеко не всегда проверяют так, как предполагается работа с ним пользователей. Кроме того, при высокой скорости выпуска релизов в новом функционале часто возникают недоделки, которые полагают незначимыми. Иногда они действительно являются незначимыми, пользователи используют это редко и могут справится обходными путями. А иногда оказывается, что из-за недоделки выполнение пользователями своих новых функций оказывается недопустимо медленной, и новые возможности практически не могут быть использованы - хотя заказчик на это рассчитывал. Поэтому Вася начинает думать о сценариях предполагаемого использования нового функционала, эргономике работы и сроках выполнения пользователями своих операций по-новому. И возникающие недоработки оценивает именно с этой точки зрения, понимая, какие из них недопустимы в релизе, а что можно отложить до более позднего исправления. Вася понимает, какие функции и когда нужны пользователям в новом релизе и участвует в его планировании и тестировании с учетом этого.
  

Версия 11:46, 21 сентября 2016

Я активно рассказываю про уровни системы ценностей Спиральной динамики на разных площадках и в разных коммуникациях. И решил в этой статье дать краткое представление об общей конструкции уровней Спиральной динамики и о содержании конкретных уровней — на основании своих презентаций и докладов — для того, чтобы можно было давать ссылки заинтересованным лицам. Слайды - из доклада на AgileDays-2016.

Предупреждение. Представленный здесь материал — моя авторская интерпретация. Я представляю, чем он отличается от версии, изложенной в книге Дона Бека и Криса Кована «Спиральная динамика», и считаю эти отличия обоснованными логикой развития организаций в целом, и ИТ — в частности. Уже произошедшее со времен проведения исследований развитие позволяет скорректировать представления о старших уровнях, которые на момент исследований в 60-е — 70-е годы были лишь слабо намечены в будущем. Если Вы хотите глубже разобраться в системе уровней, то стоит прочитать полное (а не краткое) описание в книге авторов. А затем — наложить на него Ваши представления о развитии общества и организаций, если проявления старших уровней Вам видны в окружающем мире.

Конструкция Спиральной динамики

В основе — типы ценностей. Тип ценностей представляет собой фрейм, способ мышления.

  • Что важнее — организация или инициатива?
  • Нужно ли жертвовать чем-то ради других? Если да, то ради кого?
  • Нужно ли изменять мир и каким образом?
  • Важно ли спокойное существование? В чем оно заключается?

Ответы на подобные вопросы не произвольны, они образуют �устойчивые конструкции — value mem (vMem). Их выявил в ходе экспериментальных исследований автор Спиральной динамики, Клэр Грейвз (Clare Graves).

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

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

Описание уровней

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

Уровни образуют дихотомию Я — Мы.

Описание уровней приведено на схеме, при этом дополнительно показана цветовая кодировка Фредерика Лалу, приведенная в его книге о бирюзовых организациях будущего (мой отзыв-конспект), соответствующих желтому уровню Спиральной динамики.

Действуй опираясь на ценности а не просто применяй инструменты Максим Цепков.pdf

На каждом уровне делаются открытия, которые сохраняются на последующих.

Действуй опираясь на ценности а не просто применяй инструменты Максим Цепков.pdf

Уровни в примерах

Протестировать релиз

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

А здесь - история тестировщика Васи.

██ Потыкать что-нибудь
Вася только-только стал тестировщиком и пришел в компанию и первый раз тестирует программу. Он, конечно, посмотрел описание, но программу не изучил. Тем не менее, ему дали задание протестировать этот релиз и он пытается проверить, ориентируясь на имеющийся документ и свои представления, но, в целом - не понимая, то ли он делает, каков будет результат и боясь, что он будет неудовлетворительным и он не пройдет испытательный срок. И обратиться за помощью он боится по той же причине - компания незнакомая и он не знает, как это повлияет на его оценку.
██ Проверить, как у нас принято
Петя, более опытный тестировщик из той же команды и знающий программу, объяснил Васе, что надо проверять в релизе, и Вася это запомнил. И теперь тестирует именно так. А еще Петя сказал, что в компании принято обращаться к коллегам за помощью, особенно когда имеешь дело с чем-то новым. Что лучше спросить, чем сделать неправильно по незнанию. И Вася чувствует поддержку в своей команде - но компания за ее пределами по-прежнему не знакома и внешнего взаимодействия он опасается.
██ Героически проверить все, что смог придумать
Вася задумывается, что это он все время тестирует одинаково, как ему когда-то объяснил Петя. И начинает пытаться делать разные другие действия в программе. И иногда программа падает, возникают различные ошибки. И вот уже он при тестировании героически нажимает все кнопки подряд, и радуется большому количеству сыплющихся багов. Впрочем, некоторые модули упорно не ломаются, но он - все равно ищет баги. Но при этом после релиза иногда обнаруживаются ошибки в тех функциях, которые он считал надежными и не проверил, или просто не успел, потому что все время потратил на другие части, или просто забыл.
██ Провести проверку строго по регламенту
Вася понимает, что сначала надо проверять самый важный функционал, а еще - не забывать про множество функций в программе, которые надо проверить. И пишет регламент, по которому дальше тестирует. Регламент становится предметом гордости, все время дорабатывается, и проверка идет строго по нему. Отступление не допускаются, и быстрее - никак нельзя. А еще регламент позволяет поручить проверку людям, которые слабо знают программу, и это - важно, потому что релиз надо протестировать быстро, и на это время хорошо бы подключать других исполнителей.
██ Проверить сложные нетривиальные кейсы
Работая над регламентом, Вася постепенно начинает разбираться во внутреннем устройстве программы, связи ее модулей. И зная о доработках, понимает чувствительные точки в других функциях, на которых это может сказаться. Поэтому часто быстро находит нетривиальные ошибки в новом релизе. И это его личное первенство, борьба за количество багов. А вот тестирование по регламенту он отдает другим - это скучно. Пытается переложить на разработчиков, объясняя, что уж минимальную работоспособность они должны проверять сами или жестко высмеивая случающиеся ляпы. Но вот наиболее перспективные для сложных багов места в регламент тестирования не вписываются, ссылаясь на их сложность. Они действительно сложны, но еще это место, в котором баги легко возникают, и он его бережет...
██ Вместе со всеми тестировать и тестировать
Васе таки объясняют, что задачей является не поиск максимального количества багов, а выпуск хорошего релиза, который ждут пользователи. И система тестирования перестраивается, теперь релиз тестируют вся команда вместе, Вася активно участвует в этом своими знаниями и умениями, а места, которые часто ломаются - выписывают и за ними совместно следят. Но, к сожалению, далеко не всегда дружное и совместное тестирование дает нужное качество, в релизе оказываются баги. Особенно когда релиз надо почему-то выпустить срочно, и даже в такой совместной работе команда не успевает все проверить.
██ Проверить в срок критичные кейсы и новый функционал
Для быстрого и качественного тестирования релизов в системе выделяется критичный функционал, который надо проверять всегда - не как жесткие регламент проверки, а как небольшой чек-лист. Второй чек-лист для каждого релиза свой - это тестирование нового или измененного в нем функционала. Проверку чек-листа при тестировании разбирают члены команды, Вася занимается теми пунктами, которые требуют специальных умений тестировщика. И отвечает за ведение чек-листов.
██ Проверить с учетом ожиданий заказчика по срокам и функционалу этого релиза
Оказывается, что новый функционал далеко не всегда проверяют так, как предполагается работа с ним пользователей. Кроме того, при высокой скорости выпуска релизов в новом функционале часто возникают недоделки, которые полагают незначимыми. Иногда они действительно являются незначимыми, пользователи используют это редко и могут справится обходными путями. А иногда оказывается, что из-за недоделки выполнение пользователями своих новых функций оказывается недопустимо медленной, и новые возможности практически не могут быть использованы - хотя заказчик на это рассчитывал. Поэтому Вася начинает думать о сценариях предполагаемого использования нового функционала, эргономике работы и сроках выполнения пользователями своих операций по-новому. И возникающие недоработки оценивает именно с этой точки зрения, понимая, какие из них недопустимы в релизе, а что можно отложить до более позднего исправления. Вася понимает, какие функции и когда нужны пользователям в новом релизе и участвует в его планировании и тестировании с учетом этого.

Успешно завершить проект

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

Вписаться в коллектив

Освоиться и разобраться в новом незнакомом месте
Стать «одним из нас» в закрытом уютном мирке
Завоевать свое место в подразделении и включиться в борьбу друг с другом
Принять порядок компании и вносить вклад на своем месте
Начать приносить ожидаемую прибыль и соревноваться с другими
До конца осознать общие ценности и вместе делать общее дело
Найти свое место в команде и начать вносить вклад в достижение ее целей
Вписаться в компанию, ее деятельность и внешние связи

Построить отношения с заказчиком

Начал общаться, меня не гонят
Понял работающие способы общения
«Построил» заказчика, он делает то, что мне требуется
Наладил регламенты взаимодействия
Научился манипулировать и добиваться своего
Заказчик понял, что мы вместе делаем общее дело
Понял цели заказчика и интерес команды, чтобы работа пошла
Совместно с заказчиком выработали общие цели и путь и пошли по нему

Соответствие менеджменту

Уровни Спиральной динамики и Волны развития Тоффлера

Действуй опираясь на ценности а не просто применяй инструменты Максим Цепков.pdf

Уровни Спиральной динамики и традиционный менеджмент

Уровни спиральной динамики, традиционный менеджмент и стили управления по Адизесу.

Действуй опираясь на ценности а не просто применяй инструменты Максим Цепков.pdf

В докладе на SQAdays я давал соответствие уровней с жизненным циклом корпорации Адизеса, слайды 19-20.

Уровни Спиральной динамики и ИТ-менеджмент

Действуй опираясь на ценности а не просто применяй инструменты Максим Цепков.pdf

Действуй опираясь на ценности а не просто применяй инструменты Максим Цепков.pdf