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

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

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

Дополнительно развиваются навыки по прохождению бюрократических препон. Кто-то удивлялся в посте про то, как я уговорила техподдержку кредитной карточки завести IT тикет, что мне это удалось. А это на самом деле просто результат долгих тренировок взаимодействия со структурами, которые устроены неудобным для потенциального пользователя способом.

В обоих проектах использовалась модная ныне в IT система под названием «Scrum».  В этой системе основная идея состоит в том, что большое глобальное планирование не  подходит для больших программистских проектов, потому что часто к концу проекта выясняется, что заказчик хотел получить что-то совсем другое, не похожее на то, что было описано в написанном заранее техническом задании, но понимает это заказчик только в тот момент, когда видит уже готовую, созданную систему, в которой поздно чтобы то ни было менять.  В Скраме заказчику показывают сделанное каждый спринт (период времени, чаще всего равный двум неделям, за это время делается некоторая часть работы и должны случиться все необходимые рабочие совещания), и если заказчику видно, что что-то пошло не так, то это можно сообщить разработчикам тут же, и новые задачи могут быть тут же включены в следующий спринт.

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

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

На примере моих двух опытов, включавших наблюдения за семью разными командами, я очень хорошо увидела, что Скрам на самом деле очень сбалансированная система и очень хорошо продуманная система, и если из нее что-то извлечь, то сразу провисает в другом месте. Главная жалоба людей, которые начинают по этой методологии работать, состоит в том, что все эти совещания занимают очень много времени. Поэтому первая идея состоит в том, что давайте мы совсем ненужные и непонятные совещания уберем, чтобы было полегче. Первым кандидатом на вылет обычно становится тот самый груминг, который был последним в моем списке совещаний. Что случается, если убрать груминг? Разработчики перестают думать,  о том насколько задача сложна, а на самом деле даже опытному человеку легко вдруг не увидеть таящийся где-нибудь подводный камень, из-за которого задача, казавшаяся задачей на полдня, превращается в задачу на неделю. Если о сложности думали несколько человек, или даже, если одному человеку дали время на то, чтобы хорошо обдумать, что там может скрываться, шансы, что задача уйдет неправильно оцененной, сильно уменьшаются. Если же задачи не оцениваются по сложности, или их сложность оценивает только один человек, то очень часто случается, что в спринт попадает больше задач, чем в реальности можно за спринт сделать, и в результате нарушается очень важная цикличность: все что попало в спринт за спринт выполнено, и можно изменить курс в следующем спринте, если что-то пошло не так.

Другим частым кандидатом бывает ежедневный апдейт. Зачем нужен ежедневный апдейт? Он нужен, чтобы создавать у человека важность работы над проектом каждый день. Потому что завтра утром нужно будет рассказать, что ты сделал вчера. Что случается, если этого не делать? Очень часто у человека есть кроме проекта еще срочные задачи. Например, ответить на e-mail с вопросом начальника. Или знакомые и понятные задачи. А из срочного и важного, человек, как известно, склонен выбирать понятное. И в результате,  у человека, у которого много текучки, в какие-то дни могут руки не дойти до работы по проекту. Что в свою очередь увеличивает вероятность того, что таящийся в задаче подводный камень будет найден за день до того, как задачу нужно будет сдавать. Другой плюс ежедневного апдейта в том, что другие люди могут знать, как решается та проблема, которая не дает тебе двигаться дальше. Или, если стало понятно, что ты завяз в своей первой задаче и до второй назначенной тебе в этом спринте не доберешься,  то могут забрать твою вторую задачу, если у них есть дополнительное время.

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

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

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

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

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

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

И наверно, хорошей метафорой всего этого является покупка автомобиля. Если вы решаете купить автомобиль, то обычно вам не приходит в голову сэкономить на руле, коробке передач, бензине или колесах. Или по крайней мере, если вы это делаете, то вас не удивляет тот факт, что машина не очень хорошо едет вперед. Мораль этой истории состоит в том, что если Скрам почему-то не работает как надо (выполнение задач не ускоряется, заказчики недовольны тем, что им сделали), то скорее всего что-то где-то не функционирует, неправильно состыковано или где-то не хватает нужной детали, и поэтому Скрам не едет.

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

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

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

Меня дополнительно подкупала качественно сделанная геймификация: я очень люблю, когда мне рассказывают, что у меня что-то получилось, выдают звездочки, новые уровни сложности являются новыми уровнями в программе, так что прогресс реально очень хорошо виден. Еще мне очень понравилась возможность сыграть мелодию на замедленной скорости: с 60% и 80% замедлением. В этом режиме ритм замедляется и можно научиться попадать в нужные клавиши и справляться со сложными переходами, а потом уже ускоряться. Прямо сейчас я умею играть «Весну» Вивальди на скорости 60% и «Голубой Дунай» на скорости 80%.

А вам удалось сделать что-нибудь неожиданное в карантин? Одна моя знакомая индианка рассказала, что она начала читать биографию Ганди в четырех томах. А вы умеете читать ноты? И если да, думаете ли вы при этом?

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

Но пожалуй самое важное лично для меня произошло именно благодаря суровому расписанию с 8 до 5 в самом начале. Так случилось, что все остальные  члены моей семьи — совы. А я единственный среди них жаворонок. И в результате у нас дома часто все занимались чем-то вместе вечером. Разговаривали, смотрели кино. И в результате мы все поздно ложились спать и поздно вставали. А тут так получилось, что я начала работать с восьми до пяти. И для того чтобы попасть на работу к восьми утра, мне нужно было вставать в шесть. А для того чтобы вставать в шесть, нужно в десять вечера уже спать. Я объяснила всем домашним, что после 09:30 вечера я уже недоступна. Потому что мне нужно ложиться спать. И в результате я перешла на гораздо более подходящий для меня режим, когда я просыпаюсь рано утром. Теперь по выходным я просыпаюсь очень рано и у меня оказывается три, а иногда и четыре, свободных утренних часа.

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

mariek марафон про джедайские техники. Там советуют: переформулируйте свои задачи так, чтобы было сразу понятно, с чего надо начать. Переформулировала задачу «Разобрать ящик возле ванной, который уже второй год там стоит» в задачу «Выбросить из этого ящика все, что там давно уже испортилось». Сразу почувствовала, что про эту задачу все понятно. Пришла к нему с мусорным пакетом и в результате осталась с примерно пятью невыброшенными предметами, которые быстро разнесла по местам. В процессе влипла во что-то злоклеючее, во что превратилось что-то, что в этом ящике уже какое-то время назад пролилось. Пока отмывала себя прошла две стадии: 1) надо на будущее запомнить, что, если идёшь разбирать что-то, что протекло, то нужно сразу надевать хозяйственные перчатки 2) кажется хорошо, что я их не надела, потому что до этого у меня была идея, что нужно ящик от этой субстанции отмыть, а теперь стало понятно, что просто выбросить гораздо проще.