Сказка о хорошо выстроенных бизнес-процессах, или как одна проблема хакнула идеально работающую систему разработки

    Предисловие


    Не секрет, что правильно выстроенные бизнес-процессы нужны всем.
    Отдельные граждане, отделы и целые компании с холдингами бегают кругами и воют о необходимости правильного обустройства всех и всяческих процессов. Всё должно быть посчитано, измерено, запланировано и выполнено в срок, в строгих рамках бюджета. Метрики и KPI, предсказуемость и прозрачность. Везде должен быть “внедрён” Agile. Все должны мыслить категориями Lean. Все должны думать о Business Value. И, будучи разбуженными ночью, — мгновенно ответить на вопрос: “каков LTV нашего пользователя?”

    Отличный, рациональный подход.

    В разработке программного обеспечения давно и прочно обосновался тренд “не изобретай велосипеда”.

    Нужно разработать инсталлятор для нашего мега-продукта? Интегрироваться с внешней системой? Разработать кучу отчётов?

    Не умничай, бери коробочное решение. Сэкономишь кучу времени, нервов, и, как результат, — денег компании.

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

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

    Отличный, рациональный подход.

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

    Итак, знакомьтесь с нашими героями


    Компания Anytime Rational Inc.


    До мозга костей рациональна, следует обоим принципам. Вся по Agile, везде Scrum, каждый разработчик точно знает, какой Business Value имеет каждая его задача. Все озабочены повышением эффективности, общим индексом счастья и прибылью организации.
    Не компания, а сказка. Любой владелец IT-бизнеса, глядя на неё, пускает слюнки. Сплошная конфетка.

    Ведь таких отличных компаний в реальном мире просто не существует.

    Компания Somehow Someway Ltd

    .
    Ну, здесь, — традиционный бардак. Инженеры поминутно травят свои инженерные байки в курилках, любят инженерные задачи, и чихать хотели на User LIfetime Value. Время от времени изобретают велосипеды, хотя в целом держатся в тренде “повторного использования” сторонних компонент.

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

    Словом, — чего уж там. Обычная инженерная компания.

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

    Так, конечно, не бывает, но правильные подходы должны же, при прочих равных, показывать преимущества Ratio над броуновским движением человеческой материи, верно?

    Итак, в обеих компаниях на низовом уровне, в процессе работы над некоей фичей, возникает инженерная проблема. Один из компонентов ведёт себя непредсказуемо, — старая добрая проблема “протекающих абстракций”, помноженная на проблему интеграции, — и инженер, работающий над фичей, не понимает, почему это происходит.

    Хронология проблемы


    Day 1


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

    В Somehow Someway перед инженером, — для простоты Петром Вторым, — встаёт точно такая же проблема.

    На стендапе он привычно отбарабанивает: “сегодня продолжаю работать над таской SM-134, помощь не требуется”. Он не особо задумывается над смыслом своих слов. Ведь весь его мозг поглощён обдумыванием “этой херни, которая происходит в долбаном модуле, написанном криворукими даунами из Third Party Component Solutions”.

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

    Day 2


    Anytime Rational


    Пётр Первый ковыряется со своей проблемой уже второй день. Он понимает, что микроспринт, видимо, будет профукан, и на утреннем стендапе говорит, что ему необходима помощь.

    “Кто тебе для этого нужен?” — участливо спрашивает скрам мастер.
    “В идеале, — Ярослав Мудрый из смежного отдела. Он крутой системщик, и это как раз его профиль” — отвечает Пётр Первый, уже точно зная ответ на этот запрос.
    “Оооо, Ярослааав..” — огорчённо тянет скрам мастер, — “ты же знаешь, он очень занят серьёзнейшими задачами, которые очень важны для нашей компании.”
    “У тебя же есть ещё один день”, — встревает владелец продукта, — “Давай посмотрим, что получится по результатам микроспринта, и будем принимать решение.”

    Somehow Someway


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

    “Чего такой смурной?” — благодушно интересуется зашедший на дымок тимлид Иван Грозный.
    “Да так… одна херовинка тут..” — мнётся Петр. Ивана Васильевича он уважает, но побаивается, и расписываться в своей неспособности решить задачу не очень-то спешит.
    “Ну-ну”, — хитро усмехается Иван, — “небось, опять взялся за дело не по своей квалификации?”
    Иван, посмеиваясь, удаляется, а посрамлённый Пётр идёт ковыряться дальше.

    Day 3


    Anytime Rational


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

    “А что мы будем эскалировать?” — буркает недовольный владелец продукта. “Какова стоимость решения проблемы? Мы же так ничего и не выяснили.”
    “Хорошо, значит, у нас остаётся два варианта.” — примирительно улыбается скрам мастер. “Будем запрашивать помощь или продолжим разбираться сами?”

    Все выжидательно смотрят на Петра. Он нервно сглатывает, но, будучи верным сторонником идеалов Agile, честно и открыто сообщает, что ему нужна помощь.

    “Отлично.” — говорит скрам мастер, делая пометку в Evernote. “Я узнаю у отдела системной разработки, когда они смогут нам с этим помочь.”
    “Пётр, пока что переключайся на следующую по приоритету задачу. Так, это у нас… SM-135, если я не ошибаюсь.”

    Someway Somewhat


    Пётр Второй, привычно отбарабанив дежурную фразу, продолжает размышлять над поведением модуля, зафиксированным вчера вечером. Однако Иван прерывает его размышления.
    “Пётр, а как там твоя проблемка? Уже решил?”
    “Эмм… пока нет, сегодня ещё попробую пару подходов..” — глаза Петра избегают внимательного, с прищуром, взгляда Ивана.
    “Ну-ну..” — без улыбки произносит Иван.

    Day 5


    Anytime Rational


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

    Somewhat Somewhere


    Петр Второй, поминутно матерясь, сидит за своим рабочим столом, неощутимо слушает в наушниках какой-то тяжеляк и пытается разобраться, “что же, мать его, происходит внутри этой грёбаной помойки!”

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

    “А? Что? Какого..” — срывает с головы наушники Пётр. “А, Ярослав… ты чего тут?”
    “Да вот, думал тут над твоей проблемкой на досуге… кстати, смотри, тебе бы вот здесь JNE пробросить, — а то ты дальше не продвинешься.”
    “Где? А, вот тут вот… и что это даст? Ааа, вона как..” — Пётр снова входит в поток. “А это тут что за хрень?”
    “Кривая работа с регистрами. Давай вот так попробуем..” — подключается к нему Ярослав.

    Day 10


    Anytime Rational


    “Итак, скорость нашей команды в этом спринте упала на 3 стори поинта. Учитывая, что фича SM-134 была нами в итоге выброшена из спринта, — это вполне ожидаемо. Кстати, Пётр, ты молодец, я не ожидал, что ты успеешь реализовать SM-135.” — скрам мастер привычно проводил ретроспективу, когда в комнату стремительно влетел Ярослав.

    “Ребята, я буквально на минуту, извините. Микроспринт согласован, на три дня мы вам выделим Ефима. Он хороший системщик, вдвоём с Петром проблему наверняка успешно решите. Ну, всё, я побежал, извините ещё раз, что прервал ваше ретро.”

    Пётр Первый растерянно хлопает глазами. Проблема? Ах, да, вон та, страшная и сложная… бррр…

    Somewhere Someone


    “Пётр, что там с твоей проблемой??” — грозно вопрошает Иван.
    “Нормально всё, Иван Васильевич. Один небольшой глюк остался, — ну, и код потом вылизать. Дня за три точно управлюсь.” — спокойно отвечает Пётр Второй.
    “Знаю я твои три дня..” — ворчит Иван. “Давай быстрее заканчивай, у меня уже руководство интересуется, почему мы эту фичу так сильно затягиваем. Скоро ведро вазелина надо будет заготавливать!”
    “Да знаю я, Иван Васильевич. Затащим!” — улыбается Пётр.

    Day 13


    Anytime Rational


    “По результатам микроспринта с Ефимом оказалось, что на решение проблемы потребуется ещё половина спринта. Или даже целый спринт.” — не вполне уверенно говорит Пётр Первый. Вдвоём с Ефимом они ковырялись над этой проблемой три полновесных дня, но уверенного решения так и не нашли. — “Есть несколько наметок..”
    “Наметок, шнаметок!” — взрывается владелец продукта, — “Где решение? Ты точно за неделю это сделаешь??”
    “Так, коллеги, давайте успокоимся.” — вмешивается скрам мастер, укоризненно глядя на владельца продукта. “Пётр, я правильно понимаю, что за половину спринта ты можешь не успеть, но уж за целый спринт точно решишь проблему?”
    “Да, всё верно.” — отвечает Пётр, пытаясь говорить уверенно.
    “Это всё хорошо и здорово, конечно.” — немного успокоившись, рассуждает владелец продукта. “Но готовы ли мы тратить дополнительное время на эту фичу? Мы и так уже потратили силы и время. Мне кажется, надо эскалировать. Рациональность дополнительных затрат лично мне кажется неочевидной.”
    “Хорошо, давайте так и сделаем.” — подытоживает скрам мастер.

    Someone Sometime


    “Ну, я тут почти закончил. Всё работает, только subroutine бы ещё причесать.” — отчитывается Пётр Второй. “Благо, скиллы по C я мальца подтянул, там фигня осталась.”
    “Ну, вот и молодец.” — улыбается Иван. “Причёсывать-то обязательно, или просто очень хочется? Может быть, лучше фичу наконец-то закроешь?”
    “А как же моё чувство прекрасного?” — показушно оскорбляется Пётр, потрясая в воздухе руками.
    Все инженеры дружно ржут.

    Day 17


    Anytime Rational


    “Руководство пришло к выводу, что возобновлять работу над фичей в данный момент нерационально. Business Value не настолько велико, чтобы вкладывать в неё дополнительные ресурсы, да и по срокам получается, что к следующему релизу никак не успеваем.” — сообщает владелец продукта.
    “Ну, и слава богу.” — бурчит себе под нос довольный Пётр Первый. “Можно забыть, как страшный сон.”

    Sometime Something


    “Пётр, фича твоя идёт в релиз. Тестами-то покрыл?” — интересуется Иван.
    “Ну, так… надо бы ещё добавить..” — мнётся Пётр Второй.
    “Вот и добавь.” — веско говорит Иван. “Всё, разошлись, работаем.”

    Итог


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

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

    Хотя может быть, в конкретном встреченном вами случае дело просто в рукожопости быдлокодеров, разрабатывающих левой пяткой какое-то говно.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 65

      +4
      Внимательный читатель заметит, что и в нашей истории проблема Anytime Rational возникает на стыке двух прекрасно работающих систем — продаж и производства.


      Мне кажется, что здесь проблема возникла из-за того, что процессы Agile поставили выше взаимодействия людей. Что на корню убило саму идею Agile.
        0
        Верно.
          +1
          Ну да, система стала мертвой. Если это и есть agile, то печально. Лучше бирюзовые организации строить.
          Вообще в основе лежат таланты и коммуникации.
          Интересно, помог бы ли решить проблему принцип 80/20 (когда 20 % рабочего времени тратится не на непосредственную работу, а на общее дело, в т.ч. помощь коллегам)?
          +8
          Счастливая история о том, как Ярославу Мудрому хватило «десяток минут», чтобы задать правильный вектор Петру второму.
          А в жизни не всё решается десятком минут. Как насчет дня-полутора? И тут Ярослава Мудрый мог бы и не выделить столько время со своих задач. И сидел бы Петр Второй долго-предолго.

            +3
            Я бы сказал что Петру Второму повезло, что Ярослав обратил свой взор на эту проблему.
              +1
              Ну, для начала Ярослав пообщался достаточно подробно о сути задачи с Петром.
              Потом покрутил эту проблему в бэкграунде. И пришёл к нему постоять за спиной уже не с пустой головой.
              В случае же первой компании он вообще не вникал в суть.
                +1
                В жизни Петр Второй побоялся бы рассказать, что у него затык на такой простой задаче. Подумал бы что он м… к и бился бы головой об задачу неделю. Потом бы все проклял и решил бы уволиться.

                Но автор подгоняет сказку под ответ. Потому все как во властелине колец. Когда полная засада, из рукава выныривает оживший внезапно Гендальф да не просто так а на гиганских птичках.
                  0
                  А в жизни не всё решается десятком минут. Как насчет дня-полутора? И тут Ярослава Мудрый мог бы и не выделить столько время со своих задач. И сидел бы Петр Второй долго-предолго.

                  На это есть тех лид который должен управлять ресурсами: задача Пети передается Ярославу, часть задач Ярослава раскидывается на кого-то еще, есть и куча других вариантов.
                  +5
                  Вся разница состоит в том, что второй компании повезло, а первой — нет.
                  Я слабо представляю себе компании вот совсем без перекуров или совместных обедов, а значит обсуждения все равно есть. И внезапно помочь Ярослав Мудрый как бы мог попробовать и в первом случае, вместо перекура.
                    0
                    Тут не только в везении дело, но и в отношениях между людьми.
                      +3
                      То есть в первой компании отношения между людьми тоже 100% стерильные? Вы в это верите?
                      Ну и как бы этот Ярослав Мудрый шатался бы по залу, если бы был сильно загружен? Проваливал бы свои задачи, что бы решить неважные? Тогда я тем более за первый вариант.
                        0
                        То есть в первой компании отношения между людьми тоже 100% стерильные
                        Запросто может быть. Руководство набирало и «воспитывало» сотрудников в стиле «ТОЛЬКО ПЛАН И НИ ЧЕГО ЛИЧНОГО!», перекуры и обеды по расписанию, каждые N часов персональный отчет о том что сделано, работы с персоналам нет, только делай план и думай как компанию сделать богаче. Поощряются конфликты между сотрудниками, т.к. это «повышает конкуренцию»и пр. тимбилдинг.
                        Тогда вполне возможно, что когда скажут что Ярослав может решить проблему, то Ярослав будет отнекиваться до последнего, что бы «утопить конкурента»
                          0

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

                            0
                            Виноват, тимбилдинг надо было взять в кавычки.
                            В контексте комментария имелись ввиду такие мероприятия «крысиные бега», публичные наказания (они бывают, нужны но как крайняя мера) и пр.
                              0

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

                                0
                                комментарий относился к фразе
                                «вы верите что отношения могут быть стерильные»
                                и комментарий не подразумевал отношения в фирме.
                                Хотя если учесть что на третий день:
                                Ты и так уже два дня..” — начинает закипать владелец продукта, но скрам мастер умело перехватывает управление потенциальным конфликтом.


                                Он (Петр Первый) нервно сглатывает, но, будучи верным сторонником идеалов Agile, честно и открыто сообщает, что ему нужна помощь.

                                оставляет пространство для полета фантазии об отношениях в фирме. Например по последней цитате, как бы поступил Петр Первый, если бы не был верен идеалам?
                                  +1
                                  > оставляет пространство для полета фантазии об отношениях в фирме. Например по последней цитате, как бы поступил Петр Первый, если бы не был верен идеалам?

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

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


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

                                        +1
                                        Тут пожалуй стоит учесть что слова Ярослава такие
                                        Да вот, думал тут над твоей проблемкой на досуге… кстати, смотри, тебе бы вот здесь JNE пробросить, — а то ты дальше не продвинешься.”
                                        и это должно нам намекнуть, что Ярослав не в ущерб своим задачам решил проблему Петра.
                                          0

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

                                          +1
                                          Судя по тексту, во второй фирме, на пятый день Ярослав думал о проблеме уже два дня (может он думал по дороге домой-наработу, час в пробках туда, час обратно вот два часа в день). А в первой, на пятый день только начали согласовывать с Ярославом когда он сможет помочь. Вполне может быть, что первые пять дней Ярослав не был занят глобальной проблемой, а на шестой и далее навалилось по полной. И опять же. На в одном случае Ярослав сам пришел, а во втором — отправил сотрудника.

                                          в одном случае — личная инициатива, а во втором — производственная задача, с отчетностью и прочим возможным счастьем.
                                            +1

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


                                            Я не могу понять, почему первое лучше второго, если второе помимо того, что надежнее, еще позволяет разумно оценить то, насколько оно вообще нужно и контролировать как над задачей идет работа. Вас пугает лишняя бюрократия, на которую у вас должно уходить минут 10-15 максимум, иначе у вас что-то неправильно работает? Так как раз эта бюрократия подстрахует и вас, и ПМ и прочих людей в случае, если вам не повезет, что на мой взгляд, вообще отлично.

                                              +2
                                              зависит только от личностных качеств.
                                              Если взять за пример данный текст, то можно сделать такое предположение о мотивах Ярослава.
                                              Личная инициатива. Петр нормальный парень, у меня с ним ровные отношения, курим, пьем кофе, общаемся. Он столкнулся с проблемой. Я бы ее решил так или так.
                                              Хм пятый день я не могу с ним по пить кофе и поговорить за жизнь. Что там у него произошло? Зайду посмотрю. О у тебя тут JRE…

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

                                              Производственное распоряжение.
                                              У Ярослава есть задачи за которые с него спросят в конце спринта, может даже строго (например решение проблем завязано на ЗП). Тут ему говорят есть задача, глубины которой ты не знаешь, соответственно не можешь пока представить во что она выльется, вдруг из-за нее не успею что то сделать и будут мозг выносить на планерках, а если там конкретная Ж. То потом решение этой проблемы будет вечным счастьем. Пусть ответственным за ее решение будет другой отдел, а я только помогу есть что. Скрам-мастеру дам кого не жалко, если что, крайним его сделаем а там будет видно.

                                              Словом, есть набор задач которые решает отдел и получает ЗП. И от новых задач которые не ведут к увеличению фонда оплаты труда будут сопротивляться по мере возможности.
                                                0

                                                Ваш взгляд можно взять и перевернуть задом наперед:


                                                Личная инициатива.
                                                Петр нормальный парень, у меня с ним ровные отношения, курим, пьем кофе, общаемся. Он столкнулся с проблемой. Я бы ее решил так или так. Хм пятый день я не могу с ним по пить кофе и поговорить за жизнь. Что там у него произошло? Хотя у меня нет времени, тут еще надо добить дела по проекту да и сроки горят, зайду через пару деньков (а получилось недели две, так как на проекте был адский трешак).


                                                Производственное распоряжение.
                                                У Ярослава есть задачи за которые с него спросят в конце спринта, может даже строго (например решение проблем завязано на ЗП). Тут ему говорят есть задача, глубины которой ты не знаешь, соответственно не можешь пока представить во что она выльется, вдруг из-за нее не успею что то сделать и будут мозг выносить на планерках, а если там конкретная Ж. Он говорит это скрам-мастеру, тут оценивает риски и обо всем договаривается с продакт овнером. В итоге все довольны и все заканчивается вовремя.


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


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

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

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

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

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


                                                        как только поймет что не может решить самостоятельно

                                                        Вот во втором случае такого не произошло, такое произошло только в первом. Во втором случае так повезло, что ему помогли.

                                                        +1
                                                        Если у вас нет каких-то дейли стендапов, то откуда ПМ узнает об этом?

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

                                                      +2
                                                      во втором случае задача будет сделана в сроки, или вы об этом сразу узнаете.

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

                            –1
                            Хотите ещё наброшу? :)
                            В первом случае решение задачи было вполне рационально посчитано нерациональным. Т.е. business value не настолько велик, чтобы её вообще реализовывать.
                            Во втором случае этого никто не считал. В итоге эта задача реализована, — но, похоже, не реализована другая фича (другиЕ фичи?)

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

                            Что лучше для конечного пользователя? — вопрос спорный.

                            Но с точки зрения чистого бизнеса, судя по количеству огромных дистрибутивов, жрущих тонны памяти, ЦП и питания, — первый подход куда как лучше.
                              0
                              > Что лучше для конечного пользователя? — вопрос спорный.

                              Если business value низкий — то никакого вопроса. Он определяется в значительной степени потребностями пользователя.

                              Пример из жизни. Доводилось работать в конторе, где почему-то решили что радиобаттоны должны вести себя как чекбоксы (времена до css). Потрахаться комманде пришлось изрядно. Ценность для пользователя — как у гульки достоинство, техническая сложность — вот она вам пожалуйста.
                                0
                                Да, всё очень сильно зависит от примера.
                                Приведённый вами — конечно, клинический. )))
                                  +1
                                  Ну мы делали что-то в этом роде. Кажется — кнопки на тулбаре с фиксированным нажатым состоянием. Причина простая — при дизайне не поняли размер задачи, а переделывать дизайн во время работы — не захотелось.

                                  Тут нужно найти верный момент, когда стоит подумать: может дешевле переделать дизайн?
                            • UFO just landed and posted this here
                                0
                                Да и в той которая Agile тоже как-то странно, фича мега важная для бизнеса, разработчик попросил помощь ему только выделили какого-то Эфима.
                                • UFO just landed and posted this here
                                    0
                                    По условиям задачи как раз не важная.
                                    Day1.
                                    Владелец продукта говорит, что фича, в общем-то, второстепенная, и выделить больше двух дней он не может.

                                    Меня больше занимает вопрос, почему во второй фирме Ярослав помог другу Пете из другого отдела, но в первой не может помочь своему подчиненному Ефиму?
                                      0
                                      Он же вне микроскрама. Там — Ефим и Пётр.
                                        +1
                                        Если скрам, то их безусловно оттаскивают от чужого монитора. А если все-равно лезут помогать, то сразу расстреливают.
                                          0
                                          Кстати, сразу вспомнились истории про «команды», где уровень дохода каждого зависит от числа закрытых Story Points, а в коллективе поддерживается атмосфера «профессиональной конкуренции».

                                          Вот там, — безусловно, людей оттаскивают от чужого монитора. Не руками, а выстроенной системой (де)мотивации.
                                            0
                                            Ух ты! Кто-то отличную штуку придумал. Ни разу о таком подходе не слышал и не доводилось сталкиваться. Вы сами сталкивались с таким или кто-то рассказывал?
                                          +1
                                          А он разве не тимлид, который должен помогать и разруливать?
                                    +3
                                    – У нас не получится уложиться в сроки!
                                    – Примените Agile!
                                    – Без достаточного количества людей он нам не поможет!
                                    – Тогда придумайте другое умное слово!
                                      0
                                      В точку: многие применяют эту процессную модель абы как, лишь бы можно было галочку в протфолио поставить. Мол, вот я такой супер мена менеджер что и вот так могу и еще дюжину англицизмов умею. Страдает только от временщиков-скакунов процесс.
                                      +1
                                      Нормально KPI считается только на линейных производственных линиях, где первый гайки штампует, второй за ним же их штангенциркулем измеряет, а третий заворачивает. На все остальное он «натягивается» с такой гигантской погрешностью, что отчеты времен Брежневской эпохи по сбору мегаурожаев покажутся детскими фантазиями. И толку от таких KPI нет никакого. Это отдельные фантазии, которые к реальности не имеют отношения. Думаю, мега «манагеры» это прекрасно понимают. А раз понимают, то занимаются вредительством осознанно.
                                        +2
                                        Первая компания выглядит положительнее.
                                        Ребята постоянно держали палец на пульсе. Чётко понимали, какие у них проблемы, честно оценивали риски и расставляли приоритеты.

                                        Несомненно, статистически их результат хорош. Хотя на отдельных задачах могут и не оптимально отработать.
                                          0
                                          Как мне показалось проблема очевидна: «Бюрократия умрет с последним человеком».
                                          Ну а если серьезно то со стороны выглядит что дружный коллектив решает проблему эффективнее Scrum методик. Но тогда интересно было бы внести эту плоскость и рассмотреть такой вариант: Дружный коллектив + Без Scrum VS Недружный коллектив / C идеальным Scrum
                                            0
                                            Верно.
                                            Как выше уже заметили, — Agile ставит людей и коммуникации выше процессов.
                                            «Недружный коллектив с идеальным Scrum» — это карго-культ.
                                            0
                                            На мой взгляд представлены единичные случаи, на основе которых судить ни о чем нельзя. При прочих равных команда с построенными процессами будет производить стастистически значимо больше ценности.
                                              0
                                              Петр первый больше зарабатывает и меньше может работать.
                                              Петр второй качает скилы и свое самолюбие.

                                              Что лучше спорный вопрос.
                                                0
                                                Почему первый меньше работать? Он же решил задачу SM-135 вместо того, чтобы буксовать на месте.
                                                Ему просто не дали биться головой об стену.
                                                  +1
                                                  Исходя из моей личной практики — решение задачи SM-135, а потом возвращение к предыдущей проблеме может серьёзно помочь решению. Во время долгого анализа глаз замыливается, а возвращение даёт возможность посмотреть свежим взглядом.
                                                +3
                                                «В сказке можно покататься на луне. И по радуге промчаться на коне.»

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

                                                Ну и вывод. Да scrum не работает в мире где некоторые задачи могут выполнены только магами 50 уровня и никем иначе.
                                                  0
                                                  Это не совсем о сакральных знаниях.
                                                  Скорее — именно о наблюдениях из жизни, — как идеи Agile могут быть легко подменены процессами. Которые в итоге выхолащивают весь смысл, сводя живые коммуникации между людьми к формальным соблюдениям ритуалов.
                                                  На примере сферического коня в вакууме.
                                                  0
                                                  Мне одному кажется, что автор писал статью, ради последнего предложения?
                                                    0
                                                    От вас ничего не утаишь, — на то вы и генерал. (с) Даун Хаус
                                                    0
                                                    Надо было Петру Первому просить сразу Ефима и не умничать 2 доп дня. Не справились бы с Ефимом, подключили бы Ярослава на 10 минут или скинули бы фичу как неперспективную. Скрам менеджер (или это тимлид такой?) какой-то неопытный… Слабо верится что в такой вумной компании и нельзя вытащить Ярослава официально, обязательно должно быть время когда более опытные люди (или даже свежий взгляд) давали консультации.
                                                      0
                                                      Ефим не в их команде.
                                                      +2
                                                      В первой организации нет ни Agile ни Scrum.

                                                      Короткие фиксированные спринты в scrum это очень многосторонний контракт. Судя по всему задачи большого (для scrum) объёма, соответственно команда реально ответственность не принимает, и, кстати, именно необходимость глубокой декомпозиции на целостные задачи 0,5-3 дня (5 дней в крайнем случае) является важным практическим ограничением scrum. Состав спринта менялся на ходу (и судя по всему меняется по каждому чиху).

                                                      Ретроспектива проходит с нарушениями. PO — дятел, который умеет долбить команду разработки, но не умеет работать по scrum. SM занимается не тем, чем должен. Ошибки/проблемы не обсуждаются и приоритет не согласуется. Технические решения не обсуждаются.

                                                      Технически, если из-за ошибки в third-party прикладному программисту пришлось доставать дизассемблер, чтобы спасти фичу, то это уже fail 80 lvl. С данным объёмом информации сложно сказать в чем именно fail: в архитектуре, в процессах, во взаимодействии, в компетенциях или еще в чем-то. И непонятно, можно ли его исправить (я видел как исправляли и как не исправляли).

                                                      Круто. Но это точно не конфетка.

                                                      Во второй организации непонятно, что хорошо, а что плохо, что случайно, а что систематично.
                                                        –1
                                                        Вообще весь этот скрам и agile выдумка умных продаванов и глупых манагеров.
                                                        До прихода Agile Scrum было написано куча различного софта в, том числе и качественного. Потом вдруг откуда ни возьмись, появляется XP, Agile и начинают его насаждать. Что за бред? Покажите мне хоть один проект, который не смог был бы быть напианным без Scrum, а со Scrum его реализация вдруг стала возможной.
                                                        Манифест Agile прочеловеческий ресуср совсем не нов и еще во времена СССР рационализаторы и простые рабочие, оценивались как социально, так и финансово. Шутка ли простой рабочий на заводе в 70-80 годах получал 900 рублей в мес и директор завода знал его лично.
                                                        Рациональный подход точно так же был всегда, когда взешивались ресурсы и цели(фичи).
                                                        Есть ощущение, что с бурным развитием финансов в менеджмент IT компаний пришли какие-то бездари, не имеющие базовых навыков управления и как слесдствие пытающиеся прикрыться процессами.
                                                        PS как пример успешного продукта, пошел изучать процессы разработки ядра линукс, а так же попытаюсь найти инфу о том как разрабатывался тот же MS SQL, Visual Studio и другие успешные продукты от MS и не только.
                                                        На хабре также была статья про просецц разработки хрома.
                                                        Весь скрам укладывается в простое понятие, выдача наиболее значимых фичей на регулярной основе, scrum также позволяет давать некоторую оценку трудозатрат со стороны разработчика, но это было во все времена.
                                                          0
                                                          Вы правы, ноги у Agile растут из Lean принципов, появившихся на производстве.
                                                          Традиционно принято считать, что окончательно эти принципы сформировались на заводах Toyota, и многое было взято, в том числе, из производственных подходов СССР.
                                                          Если так разобраться, то:
                                                          Lean = Agile, это общий набор принципов.
                                                          XP, Scum, Kanban, — набор рекомендаций.
                                                          Custom Agile, вырабатываемый на каждом конкретном предприятии — это методология. Она может быть задокументирована, может быть просто частью культуры производства, — не так важно.

                                                          Важно другое: бездумное «внедрение Agile» в любой организации — это карго культ. Если внедрена методология под любым названием, нарушающая базовые принципы Agile подходов, — то система будет неэффективной.
                                                            0
                                                            Если внедрена методология под любым названием, нарушающая базовые принципы Agile подходов, — то система будет неэффективной.

                                                            Слишком сильное утверждение, не находите?
                                                              0
                                                              С точки зрения формальной логики, — да, конечно: во всём теоретически возможном множестве решений наверняка найдутся эффективные псевдо-Agile методологии, нарушающие принципы Agile.
                                                              С практической точки зрения, к сожалению, получается, что «внедряют Agile» — по названию, нарушая при этом принципы Agile. И получают на выходе карго-культ, позволяющий гордо бить себя пяткой в грудь: «мы ВНЕДРИЛИ Agile». А что там под капотом, — мало кто понимает, и почему это получается неэфективно, — тоже мало кто понимает.

                                                              ЗЫ Вероятно, мне надо было выразиться точнее: «Если внедрена якобы Agile методология под любым названием, нарушающая базовые принципы Agile подходов...»

                                                        Only users with full accounts can post comments. Log in, please.