Изменения

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

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

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

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

:: Петя, более опытный тестировщик из той же команды и знающий программу, объяснил Васе, что надо проверять в релизе, и Вася это запомнил. И теперь тестирует именно так. А еще Петя сказал, что в компании принято обращаться к коллегам за помощью, особенно когда имеешь дело с чем-то новым. Что лучше спросить, чем сделать неправильно по незнанию. И Вася чувствует поддержку в своей команде - команде — но компания за ее пределами по-прежнему не знакома и внешнего взаимодействия он опасается.

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

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

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

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

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

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

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

: <font color="NavajoWhite">██</font> Наконец-то у меня приняли этот проект :: Коля совсем недавно стал вести проекты, и для него самое страшное - сдача проекта. Потому что там он сталкивается с не слишком понятными ему представителями Заказчика в гораздо большем количестве, чем в ходе проекта. Иван Иванович (Ваня. он тоже молодой), менеджер проекта от Заказчика говорит, что они все должны завизировать акт приемки, и для этого надо устранять замечания или объяснять, устно и письменно, что замечание не может быть принято, обосновывать сделанное. И эти замечания - совершенно непонятные, странные, и Ваня тоже не понимает, что они значат. Иногда можно просто объяснить, почему что-то сделано так. и этого оказывается достаточно, иногда приходится что-то переделывать, иногда объясняешь так долго, что кажется - придется-таки переделывать, и тут вдруг представитель заказчика соглашается. И сколько будет таких замечаний, тоже предсказать нельзя. Иногда проект шел с трудом, а сдача - хорошо, иногда - наоборот. В общем, когда проект, наконец-то, принят, это приносит большое облегчение.: <font color="Violet">██</font> Танцы с бубнами вокруг непонятных замечаний завершились успешно : <font color="Red">██</font> Я заставил их принять проект и признать нашу правоту, несмотря на врагов : <font color="Blue">██</font> В соответствии с процедурами и регламентами проект был сдан заказчику : <font color="Orange">██</font> Мы поняли интересы ''принимающих'' проект и обеспечили их удовлетворение. : <font color="LawnGreen">██</font> Проект стал частью большого общего дела : <font color="Yellow">██</font> Результат проекта оправдывает ожидания, которые на него возлагались

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

: <font color="LawnGreen">██</font> До конца осознать общие ценности и вместе делать общее дело : <font color="Yellow">██</font> Найти '''свое место''' в команде и начать вносить вклад в достижение ее целей

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

: <font color="Violet">██</font> Понял работающие способы общения : <font color="Red">██</font> «Построил» заказчика, он делает то, что мне требуется : <font color="Blue">██</font> Наладил регламенты взаимодействия : <font color="Orange">██</font> Научился манипулировать и добиваться своего : <font color="LawnGreen">██</font> Заказчик понял, что мы вместе делаем общее дело : <font color="Yellow">██</font> Понял цели заказчика и интерес команды, чтобы работа пошла : <font color="Turquoise">██</font> Совместно с заказчиком выработали общие цели и путь и пошли по нему

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

В [[Спиральная динамика: понимай ценности – и действуй! (Максим Цепков на SQAdays-16)|докладе на '''SQAdays''']] я давал соответствие '''уровней с жизненным циклом корпорации Адизеса''', слайды 19-20.

Подробное представление можно составить, опираясь на книгу '''Фредерика Лалу "Открывая «Открывая организации будущего"будущего»''', в которой он дает описание описание организаций разного уровня. Надо только иметь ввиду, что Лалу использует собственную уровневую систему, основанную на синтезе уровней Спиральной динамики, Интегрального подхода Уилбера и ряда других, и его уровни системы несколько отличаются от уровней Спиральной динамики - динамики — я пишу об этом в [[Блог:Максима Цепкова/2016-01-15: Фредерик Лалу - Открывая организации будущего|отзыве на книгу]]. В если брать все уровни, соответствующие классическому менеджменту - менеджменту — красный, синий (янтарный у Лалу) и оранжевый, то их совокупность практически не отличается, то есть речь идет о перераспределении отдельных качеств внутри этой тройки.

Лалу так же дает описания организаций старших уровней - уровней — зеленого и желтого (у него - него — teal, переведенный как бирюзовый).