Читатели публикаций про #Ускорение4X убедили меня, что я не прав, сразу пересказывая методику, и ничего не поведав об истории ее возникновения. Исправляюсь.

Нам удалось ускорить разработку в команде в 4 раза в течение 5 месяцев, с перерывами. Потом нам удалось несколько систематизировать наш путь, и применить не только в разработке. Развивать методику мы продолжаем и поныне (правда, нас стало меньше).

История эта случилась несколько лет назад, в ИТ-отделе не очень большого производственного предприятия. Нас там было пятеро, включая меня, программировали мы на 1С. Скептикам сразу скажу, что язык и среда программирования роли не играют — сейчас я ровно тот же опыт повторяю на javascript.

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

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

Классический скрам

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

Доска, стикеры, митинги, скрам-мастер и т.д. Освоив в первый же день методику покера планирования, пересчитали ретроспективно несколько недель, получили цифру — 4.2 балла в день на человека (далее все оценки будут приведены к баллам на человека в день, нам так показалось честнее считать).

В первую же неделю скрама, на волне энтузиазма, мы сделали 7 баллов. Во вторую — 10. В третью — 13.

Вау! — думали мы! В два раза быстрее! Гениально! Спасибо, скрам!

Привыкание

Но, потом скорость начала падать. Энтузиазм прошел, стикеры вешать стало лень, но мы держались. Понимали, что это нормально — устать и опустить руки. Надо просто привыкнуть.

Взяли себя в руки, перетерпели, заставляя себя, и — привыкли. Это перестало быть проблемой.

Правда, скорость больше не росла — 13 баллов третьей недели так и остались максимумом. В среднем у нас получалось сделать около 8 баллов, иногда чуть больше, иногда чуть меньше.

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

Итого, весь этот первый этап продлился 3 месяца.

Перерыв

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

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

Прочтение книги, после трехмесячного использования скрама по инструкциям интернета, было настоящим озарением. То, что написано в инструкциях, в том числе scrum guide — банальная пошлость по сравнению со смыслом книги и, соответственно, самого скрама.

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

Терпеть было невозможно, и я вернулся к парням и скраму.

Второй этап

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

Доску заменили простейшей автоматизацией, митинги — постоянным наблюдением за процессом, ретроспективы — постоянным изменением процесса.

Второй этап продолжался 2 месяца, за это время мы наработали и проверили на себе примерно 40 практик, методик, фишек и приемов, которые в совокупности дали нам ускорение в 4 раза. Часть из этих практик мы придумали раньше, до скрама вообще, но систематически не применяли, т.к. не видели в этом смысла.

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

За два месяца мы вышли на устойчивую скорость 17.3 балла, что в 4.11 раза больше первой цифры, которая была до скрама. Оттуда и пошло #Ускорение4X.

Новая компания

Через некоторое время я ушел из той компании, и у меня было подозрение, что ускорение было вызвано стечением обстоятельств — ну, мало ли, повезло, или мы чего-то напутали в расчетах.

Я попал в другую компанию, где разрабатывают и внедряют решения на javascript. Там я и продолжил свои исследования эффективности.

Там тоже встречается 1С, поэтому моя эффективность не упала до нуля. Но там пришлось разбираться в javascript, а еще решать задачи управления внешними проектами, менеджмента и маркетинга — отличное поле для экспериментов.

Что в итоге (промежуточном)? Сейчас, на момент публикации, моя средняя скорость составляет 20 баллов — это уже растянутое ускорение в 5 раз. Для меня очевидно, что я могу прибавить еще минимум вдвое, когда наконец проникнусь js до нормального состояния.

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

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

Основные практики

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

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

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

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

Мы ранее предполагали, что расчет сроков можно автоматизировать, и даже сделали это — у нас была очень крутая система планирования, одновременно по ASAP и ALAP, с учетом всего, чего только можно. Ее мы не выкинули, а оставили — для планирования производства, закупок и кассовых разрывов.

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

Цель каждого была учтена, и появилась итоговая цель — «работать на будущего работодателя», или проще говоря — на свой опыт. На то, что останется с тобой после увольнения.

И жить стало значительно интереснее, т.к. каждый из парней находил для себя в каждом дне что-то полезное.

Очень быстро мы поняли влияние абстрактных решений на ускорение. Если работали в 1С, знаете, что там с абстрактными решениями полная задница, и чем дальше, тем хуже — спасибо вендору. Абстрактные решения снимали с нас целые пласты задач, экономя массу времени. За 2 месяца мы создали примерно 10 абстрактных решений (до этого — 20 за три года).

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

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

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

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

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

Так в нашей практике появился адвокат дьявола — swap позиций для случаев, когда двое спорят и не могут договориться.

Так у нас появился Чингисхан — когда ты одно за другим забраковываешь предложения, чтобы на 5-6 итерации получить идеальное решение. А 5-6 итерация — это минут через 15-20.

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

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

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

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

Я все время наблюдал за скоростью и эффективностью, но по инерции делал это раз в день, как на скраме. При этом, чтобы увидеть потери и понять их причину, надо видеть одновременно — и потерю, и причину. Если смотришь сегодня за вчера, то причины уже нет — она осталась позади. Поэтому я вспомнил такую штуку, как контроллинг — не тот, который «контроль», а тот, который «управление на основе цифр», хороший и добрый. И стал наблюдать за приростом баллов в течение дня. Если видел, что у кого-то цифра стоит колом, то шел разговаривать с человеком, и причина быстро находилась. Она была или сиюминутной (затупил), или системной, а это уже повод для улучшений. Этот прием я использовал на протяжении почти всех двух месяцев.

Резюме

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

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

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