• Как Иван метрики DevOps делал. Объект влияния

      Прошла неделя с тех пор как Иван в первый раз задумался над метриками DevOps и понял, что управлять с их помощью надо временем поставки продукта (Time-To-Market).

      Даже на выходных он думал про метрики: «Ну и что, что я измерю время? Что оно мне даст?»

      Действительно, что даст знание времени? Допустим, поставка занимает 5 дней. И что дальше? Это хорошо или плохо? Даже если это плохо, то нужно же как-то уменьшать это время. Но как?
      Эти мысли не давали ему покоя, но решение не приходило.

      Иван понимал, что подошёл к самой сути. Бесчисленные графики метрик, виденные им до этого, давно убедили его, что стандартный подход не сработает, и что если просто построить график (пусть даже когортный), толку от него будет ноль.

      Как же быть?..
      Читать дальше →
    • Как Иван метрики DevOps делал. Начало

        Однажды Ивана позвали на совещание, чтобы обсудить метрики DevOps.

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

        Слушая доклады Иван попытался подсчитать сколько метрик было предложено: 5,10, опять 10, и еще около десятка. Получилось 30 с чем-то.

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

        Наблюдая со стороны Иван задавал себе вопросы: зачем? Почему именно эти метрики? Что они вам дадут? Стало вдруг очевидно, что на совещании собрались люди, совершенно далекие от реального понимания природы метрик, и что всё закончится как обычно, потерей огромного количества времени и выбрасыванием наработок в мусор.

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

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

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

        Иван решил подготовить своё видение метрик DevOps, причём сделать так, чтобы каждая метрика была в нём обоснована, имела конкретную цель, несла пользу и была понятна.
        Вот, что у него получилось…
        Читать дальше →
      • Как Иван конверсию стендов исследовал

          После того как Иван познакомился с когортным анализом, он терпеть не мог любые виды слащавых метрик.

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

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

          image
          Читать дальше →
          • +13
          • 2.3k
          • 2
        • One Metric To Rule Them All – Существует ли одна единственная универсальная метрика?

            «One Ring To Rule Them All»
            J.R.R.Tolkien

            «Управлять можно только тем, что можно измерить»
            П.Друкер


            Когда речь заходит о метриках, то на ум приходят десятки, а то и сотни различных вариантов.
            Каких только измерений не придумали!

            Но вот беда, когда смотришь на эти красивые картинки, часто бывает совершенно непонятно, что они обозначают.

            Да и вообще совершенно неясно, правильно ли были выбраны эти метрики или стоило бы смотреть на совершенно другие?

            Хочется какой-то одной метрики, такой, чтобы посмотрел, и всё сразу стало понятно.
            Но существует ли она? Или волшебства нет?

            Давайте разберемся и посмотрим на конкретном примере…
            Читать дальше →
          • Где же у него кнопка?! Как простому человеку выгрузить данные из Kibana и Elasticsearch и не напрягать при этом разрабов

              Elasticsearch, Kibana и Logstash (ELK) – отличный набор инструментов для сбора и визуализации большого количества данных.

              Логи, журналы, события – всё это довольно легко собирается, мапится и отображается в едином инструментарии. Logstash мапит данные, Elasticsearch хранит их, а Kibana отображает в виде графиков.

              При всей мощи этой связки, естественно, есть задачи, которые невозможно реализовать через встроенные возможности.

              Например, Kibana прекрасно показывает данные в рамках одной таблицы (индекса), но как только дело доходит до объединения разных индексов в одну выборку, она беспомощно разводит руки.

              И единственный способ решить задачу в этом случае – выгрузить данные из Kibana и объединить их в любом другом средстве, например, в Excel.

              Простой пример. Представьте, что Ваша Ёлка (ELK) собирает и хранит события Jira – по любому изменению любой из задач таск-трекера.

              В этом случае в индексе Elasticsearch по одной задаче будет храниться несколько записей:


              Читать дальше →
              • +15
              • 5.3k
              • 8
            • Как мы улучшали службу технической поддержки с помощью когортного анализа

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

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

              В большой организации работа централизованных служб часто имеет критическое значение.

              Представьте, что Вы – руководитель службы поддержки, состоящей из 10 человек, и Ваша команда обслуживает коллектив из 200 команд, в каждой из которой по 7-10 человек. Это минимум 1400 человек, ежедневно засыпающих Вас работой.

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

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

              И тут начинаются жалобы на медленную отработку запросов…

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

              На помощь приходит когортный анализ.
              Читать дальше →
            • Как я применил когортный анализ участвуя в соревновании по сбросу веса

              Всё началось с того, что я бросил вызов и принял участие в соревновании. Дело в в том, что вес у меня заоблачный и, конечно, хочется его серьезно сбросить.

              Раньше был опыт избавления от 20 кг, но потом, из-за отсутствия мотивации, много вернулось обратно. В этот раз, чтобы мотивация была серьезной, я бросил вызов другому человеку и взялся за дело.
              Читать дальше →
            • Прозрение по метрикам: как я понял, что такое метрики и в чём их главная прелесть

              Метрики — это фуфло, скажите Вы, и будете правы. В чём-то.

              Действительно, если речь заходит о метриках, то самая первая первая метрика, которая приходит на ум — посещаемость.

              Многие любят медитировать часами глядя на график посещаемости своего сайта.

              image

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

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

              Ах, какая радость, какое блаженство!

              image

              И даже если картина печальная…



              От графика все равно не оторвать глаз, так он затягивает.



              Кажется, что в графике скрыт тайный смысл. Еще немного, и картинка раскроет свои секреты и расскажет невероятно простой и эффективный способ привлечения огромного количества клиентов. И тогда-то деньги точно потекут рекой.

              Но на самом деле, посещаемость — типичная “слащавая (тщеславная) метрика”, не несущая в себе полезного смысла.
              Читать дальше →
            • Когортный анализ показывает картину, совершенно отличную от нашего привычного восприятия

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

                Не верили не потому, что я не логично изложил суть или сказал что-то глупое. Нет. С этой точки зрения всё было хорошо. “То, что ты предлагаешь — это действительно интересно и инновационно, но… давай-ка мы все-таки сделаем всё по-старому”. Как же обидно было это слышать.

                Я разрабатывал систему метрик, ориентировать на которые должны были несколько тысяч человек. Представьте, что Вы совершенно чётко осознаете, что люди вокруг вас упорно и настойчиво, всеми своими силами стремятся упасть в глубочайшую яму, цена падения в которую невероятно высока. Вы просто не имеете права допустить, чтобы это произошло, понимаете? Просто не имеете права!

                Но в тот момент я как собачка смотрел преданными глазами на коллег и ничего не мог сказать. Знаете, есть несколько выдающихся человек в мире, которые мне очень нравятся. И один из них — Илон Маск. После очередного неудачного запуска ракеты Фалькон в его компании царило полное уныние. Несмотря на то, что день был очень тяжелым, несмотря на 20 часов, проведенных на ногах и постигший его удар, Маск выступил перед компанией, поддержал сотрудников и завершил свою речь словами: “Сам я никогда не сдамся. Никогда!”

                Слова Маска тогда сами собой всплыли у меня в голове: “Я не сдамся!”.
                Читать дальше →
              • Скрытая угроза: критические моменты, на которые обращают недостаточно внимания после окончания разработки ПО

                  Недостаточно просто закодировать и протестировать программу.

                  Бывало у Вас так, что после запуска программы уходит сотрудник, который с ней работал долгое время? Или возникает необходимость доработать программу, но никто уже не помнит как она устроена?

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

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

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

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

                  Однако есть один момент, на который мало кто обращает внимание.

                  Давайте рассмотрим его на конкретном примере…
                  Читать дальше →
                • Как использовать сценарии использования для точной оценки трудоемкости работы

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

                    Попробуйте открутить назад все Ваши проекты и оцените реальное опоздание по ним.

                    Может оказаться, что задержки достигают просто гигантских значений.

                    Автор статьи видел проекты с задержкой сроков в 400% и 700%!

                    Бытует мнение, что разрабатывать программы без опоздания невозможно в принципе.

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

                    На момент оценки трудоемкости ТЗ есть не всегда. И даже если оно есть, фактор неизвестности всё равно продолжает играть огромную роль – ведь люди, к сожалению, действительно не провидцы, и каким бы подробным не было ТЗ, всё равно остаются моменты, скрытые от глаз.

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

                    Интересно, что сценарии (варианты) использования позволяют довольно точно оценить трудоемкость работ.

                    Практика показала, что можно достигнуть 20% точности (=%ошибки) при оценке. А ведь опоздание 20% это совсем не 700%, верно?

                    Как это сделать?
                    Читать дальше →
                    • +13
                    • 14.9k
                    • 5
                  • Тестирование сайтов с помощью сборок: что это такое и как работает

                    Тестировать на боевом сайте запрещено.

                    Если Вы создаёте сайты, то наверняка понимаете почему это так. И скорее всего Вы знакомы с проблемой, о которой пойдет речь.
                    Читать дальше →
                    • –1
                    • 3.1k
                    • 8
                  • Что программируют программисты?

                    На самом деле этот вопрос будет скорее интересен системным аналитикам, чем программистам.

                    Речь пойдет не о программировании, а о том, как делать постановки (технические задания) для программистов.

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

                    Итак, представьте, что Вам нужно написать техническое задание на программное обеспечение.

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

                    Да, в целом так. Но дьявол, как известно, скрывается в деталях…
                    Читать дальше →
                  • Почему ИТ-директоры обязательно должны «работать в поле»

                    Необходимость в едином походе к автоматизации предприятия особенно ярко проявляется когда сам сталкиваешь с проблемой “изнутри”.

                    Когда смотришь на предприятие “сверху” и пытаешься понять, что бы тебе такое объединить и автоматизировать, то придумывается обычно плохо.

                    Хорошо помогает выход на места и анализ того как работают рядовые сотрудники.

                    На рабочих местах обычно открывается то, что скрыто в основное время за дверью Вашего кабинета…
                    Читать дальше →