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

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

Конкретно вам НЕ стоит читать дальше, если вы МОЖЕТЕ в течение 5 минут ответить на вопрос: насколько изменилась скорость, или эффективность вашей работы за последние полгода?

Если вы ответили на этот вопрос цифрой, и цифра эта не равна нулю, то публикация не для вас.

Для 1Сников вместо нуля может быть Неопределено, для js'ников — undefined.

Нетрудно догадаться по названию, что речь о гибких методах управления проектами, т.е. agile, и, в частности, о конкретном фреймворке — scrum.

Напомню в двух словах, кто такой суррогат:

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

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

Если вы – дядя из франчайзи – самое время надуть щеки и уйти восвояси. Здесь программисты разговаривают.

Цель


Так вот, со скрамом получилось ровно также. Кто знает цель внедрения скрама? Вот прямо сейчас можете назвать? Не залезая в интернет.

Прозрачность? Командная работа? Регулярные встречи с заказчиком? Короткие циклы разработки? Ежедневные митинги?

Все мимо. Звучит, как фразы из рекламных буклетов 1С. Помните? Прозрачность учета, единое информационное пространство, аналитические отчеты, сквозное прослеживание, бла-бла-бла.

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

Цель у скрама одна. Записываем определение: цель скрама — ускорение достижения результата.

Все, больше ничего.

Кто-то возмутится: да как же, а гибкость? Ведь скрам, в отличие от водопада, работает короткими циклами, а значит, при выборе ошибочного пути мы быстро опомнимся. И у нас будет fail fast.

Ну, сами и ответили на свой вопрос. Fail fast — он зачем? Да там 4 буквы из 8 кричат об этом: fast. Быстро. Быстрее. Ускорение. Ускорение достижения цели.

Потому что цель скрама — ускорение достижения результата.

Уже давно баян, но вдруг кто не знает. У нас, в России, когда переводили название книги Сазерленда, допустили роковую ошибку. В оригинале книга называется «art of doing twice the work in half the time», проще говоря – как делать работу в четыре раза быстрее. А у нас назвали «Революционный метод управления проектами».

Видите разницу?

Книга написана про ускорение работы в 4 раза. Видя такое название, человек садится читать, чтобы узнать, как ускорить работу в 4 раза.

А видя наше название, человек садится читать про некий метод управления проектами. Пусть и революционный, но метод. Процесс. И все внимание концентрируется на процессе.

Не думает человек «зачем», думает лишь «как». Как что делать, как стикеры вешать на доску, сколько митинг должен длиться, кто свинья, а кто курица.

Не задает он любимого вопроса индейцев языковой группы «нахуа» (модераторы! это не мат!). Так любили этот вопрос индейцы, что языковую группу в его честь назвали.

Разница в понимании целей


В суррогатах я говорил, что бизнес то-то любит, а того-то не любит, вот книжки любит, потому что там оригинал и бизнес его понимает.

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

Конкретно скрам. Ту же самую книгу Сазерленда читали знакомые. Один — собственник бизнеса, другой — генеральный директор бизнеса.

Потом пришли ко мне позвали меня, и задали один и тот же вопрос: насколько ты ускорил работу, применяя скрам?

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

Сколько из них хотя бы упомянули, что цель скрама — ускорение достижения результата? Ноль.

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

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

Программисты, считая себя умнее всех, книги не читают вообще. Есть же описание фреймворка! Мануал! Что мне муть эта словоблудная, патока сахарная, я ж не манагер. Прочитаю алгоритм, что делать надо, и все пойму, будет у нас скрам.

Что в итоге? Суррогат!

Бессмысленный процесс, не приводящий ни к чему. Так, прикольно, но не более того. Один процесс из жизни напоминает… Забыл название… Каждый точит, как хочет?

Как не терять Цель?


Скрам в этом смысле – уникальный фреймворк. Контроль цели заложен в платформу. Единственное, что надо делать – не забывать о ней, о цели.

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

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

Не хватит памяти. На неделю хватит, на две, максимум на месяц. А скрам – это про годы, если не про всю жизнь. И не только про программистскую.

Просто делайте это – измеряйте. Что бы вам там ни казалось, какой вы великий гений управления командами, какая сложная / простая / интересная / необычная / провальная была неделя – измеряйте.

Это такая уловка мозга хитрая срабатывает, типа «у меня сегодня был неудачный день, я не могу собраться, пойду потуплю в интернете, а вот завтра уж!», или наоборот – «вау! Сегодня такой день! Я такую штуку сделал! Нахрен эти измерения, сегодня обойдусь! Завтра! Все завтра!».

Пока вы не измеряете, вы во тьме, и скрама нет.

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

Как в навигаторе. По спутнику, или по окружающим сетям, но навигатор должен знать, где находится. Потому что иначе не определит, как далеко от цели, и куда надо двигаться.

Скрам вообще очень похож на навигатор. Можно сказать, что навигатор – это хороший прототип скрама.

Цель навигатора известна, ясна и записана в виде цифр – координат пункта назначения. Цель неизменна. Изменению подлежит лишь путь к цели, т.к. он зависит от факторов – пробок, решений водителя, и т.д.

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

Включили, посмотрел навигатор, где цель, и сказал вам – едем туда, 2 км. Вы – ок, выключили позиционирование, едете 2 км, включаете обратно. Навигатор опять смотрит – ок, почти то, что надо, на 200 метров проскочили, щас маршрут перестрою. Это – работа владельца продукта, определять задачи, максимально приближающие к цели, на ближайший спринт.

Система координат скрама – просто шикарна. В одних и тех же единицах известно:

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

Представьте, было бы что-то подобное во внедрении информационных систем типа 1С? Что было бы с суррогатами?

Позвал собственник франча, говорит – хочу затраты сократить, внедрив 1С.

Ему, по классическому суррогатному пути, ТЗ написали, задачи, этапы. Внедрять начали. С актами пришли.

Он спрашивает: затраты сократили? Нет, говорят, увеличили. Ну идите, сокращайте.

Приходят опять – автоматизировали расчет себестоимости! Ура, отвечает собственник. А затраты сократили? Нет. Чего приперлись тогда? Себестоимость автоматизировали. Зачем? Главбух сказал. А деньги кто платит? Вы. А я чего сделать просил? Затраты сократить. А вы чего сделали? Себестоимость автоматизировали. Чувствуете, что не так что-то? Чувствуем. Ну вот, с чувством, с толком, с расстановкой, затраты сокращать.

И т.д., пока лимит на дебиторскую задолженность не иссякнет.

Нахуа?


(Модераторы! Это не мат! Это название языковой группы индейцев).

Вы, так или иначе, система. Из одного человека, или из нескольких. Вы производите продукт. Раз вы производите, у вас есть производительность – единицы продукта в единицу времени.

Производительность – неотъемлемое свойство системы. Одна из базовых характеристик, наравне со стоимостью – вы ведь, как система, стоите определенных денег, рублей или долларов в единицу времени.

Ваши знания, ваш опыт, ваш гитхаб – это прекрасно. Но это не характеристика системы в действии, в рантайме.

Ваши знания, написанные в резюме или разделе «наш опыт» на сайте – это объем занятого пространства жесткого диска. Ваша производительность – это комплексная характеристика процессора, ОЗУ, шины данных и т.д.

Без понимания скорости вы – просто дисковый накопитель. Красивый, может даже изящный, но бесполезный в реальном применении.

Тысячи людей в этом мире могут сказать – «я знаю javascript на профессиональном уровне». О чем это говорит? Ни о чем. Как диплом о высшем образовании.

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

Но скорость – это снапшот, определенный уровень в конкретный момент времени. Для вас, как программиста, важна не скорость, а ускорение, производная скорости. В институте говорили, что ускорение – это скорость изменения скорости.

Ускорение – это ваша способность к развитию, улучшению и адаптации.

И это – главная цель скрама. Если вы используете скрам для чего-то другого, то вы работаете в суррогате.

Как ускориться?


Однозначного ответа нет ни у кого.

Лично у меня есть накопленный опыт, состоящий примерно из 40-50 ускорителей, которые дали и дают суммарный результат 4x. Такое устойчивое ускорение я получал в своей практике.

Пробовал в разработке на 1С, сейчас обкатываю в разработке на js внутри metadata.js.

Обо всем, что знаю – расскажу.

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

Комментарии (12)


  1. Crysdd
    26.12.2017 07:07

    40-50 ускорителей, которые дали и дают суммарный результат 4x
    Это все вместе, или каждый по отдельности?


    1. nmivan Автор
      26.12.2017 07:08

      Вместе


    1. nmivan Автор
      26.12.2017 07:09

      Точнее не так. 40-50 — это то, что использовалось в конкретной команде, для получения 4Х.
      Сейчас, в другой команде, используется 5-10, с тем же эффектом.
      Набор индивидуален, как таблетки от давления.


  1. VolCh
    26.12.2017 07:12

    Как мне кажется, в случае заказной разработки исполнитель не несёт ответственности за недостижение заказчиком бизнес-целей типа сокращения затрат или увеличения дохода. За это отвечает в целом кто-то со стороны заказчика, тот же Главбух, например. Или гендир. Разработчик (в штате или сторонний) отвечает за автоматизацию, цели проекта ему нужны для оценки и обоснования технических решений, но не более. Грубо, не в его компетенции сокращение бухгалтерии или снижение ФОТ после снижения трудоемкости или квалификационных требований расчёта себестоимости на порядок. Не в его компетенции разбираться с причинами блокирующих задержек со стороны заказчика, явный это саботаж планируемого к сокращению сотрудника или на человека взвалили сопровождение разработки, не разгрузив от обычных задач. Бизнес принимает решение, что автоматизация того или иного процесса в такой-то форме снизит его издержки и несёт за это решение ответственность.


    1. nmivan Автор
      26.12.2017 07:18

      в случае заказной разработки исполнитель не несёт ответственности за недостижение заказчиком бизнес-целей

      по факту — да.

      Но ведь обещают же?
      Смотрим http://v8.1c.ru/erp/:
      «Если вы желаете повысить эффективность управления производством и бизнесом, автоматизировать большинство задач на современном цифровом уровне и достичь принципиально новых целевых показателей, «1С:ERP Управление предприятием 2» – это ваш выбор!»

      Тут еще можно вывернуться, но заходим по ссылке глубже http://v8.1c.ru/erp/economic_effect.htm:
      «Снижение объемов материальных запасов, среднее значение 20%»
      «Сокращение расходов на материальные ресурсы, среднее значение 11%»
      Даже «Рост прибыли, среднее значение 14%».

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


      1. VolCh
        26.12.2017 11:24

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


    1. zeronice
      26.12.2017 07:42

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


  1. dyhmichail
    26.12.2017 09:04
    +1

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


  1. RationalBot
    28.12.2017 08:04

    А можно подробнее, как именно эти 4x были получены? Это сокращение time to market или увеличение velocity команды? Если последнее, то насколько это объективно? Может просто гиперинфляция store points?
    Спасибо!


    1. nmivan Автор
      28.12.2017 08:08

      Это сокращение time to market или увеличение velocity команды?

      Работа по ускорению велась над velocity, одним из результатов стало сокращение time to market.
      Time to market уменьшился примерно в 6 раз.

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

      Вот цитата, чтоб долго не искать:
      Чтобы оценки не уплывали в сторону увеличения или снижения, придумайте себе якорь. Самый простой якорь – решить, что есть задача на 1 балл. Это – бит вашей работы, самое простое из того, что вам приходится делать. Например, добавить поле ввода. Можно придумать не один, а несколько якорей, если вам так проще.

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


      1. RationalBot
        28.12.2017 13:32

        Спасибо!
        Выдающийся результат! На Agile конференциях больше полутора редко заявляют.
        За какое время достигается? На команде какого размера? Например, во втором проекте:
        фактически один контрибьютер (если отбросить 5 коммитов из 1170).
        Индивидуальный скрам?


        1. nmivan Автор
          28.12.2017 19:36

          Про процесс достижения расскажу подробно, в нескольких публикациях.
          На гитхаб рано смотреть, я там недавно, как и в разработке на js.