Управление разработкой в стиле BDSM

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

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

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

    Часть первая: Bondage


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

    И тут все на полном серьезе начинают обсуждать отличие Basecamp’а от MS Project, писать обзоры, читать обзоры, и вообще чувствовать важность момента. Особо отъявленные ребята пишут свои системы — у меня был один товарищ, которому я написал аж две системы управления задачами, а потом, через несколько лет, он поделился со мной желанием это дело еще разок повторить.

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

    А система сама по себе процесса не создает.

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

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

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

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

    Отдельной строкой хочу отметить еще одну цель установки подобных систем: посчитать эффективность сотрудников в виде красивой таблицы.

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

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

    Discipline


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

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

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

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

    То есть если бизнес эффективен и прет, то производство идет с ним под руку.

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

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

    Sadism


    В этом деле лучше сразу переходить от теории к практике.

    Пример раз: синдром последнего рывка.


    Нассим Талеб сформулировал довольно простую теорему: «чем дольше у вас все плохо, тем меньше вероятность, что у вас будет все хорошо».

    То есть, если вы уже 10 лет живете в лагере для беженцев, вряд ли вы вернетесь домой к среде (этот циничный пример взят из самого Талеба — он из Ливана, ему видней).

    Итак, у нас есть какой-нибудь проект, по которому просраны все сроки, но его вот еще чуть-чуть и наконец-то сдадут.

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

    И все от мала до велика решают: «Давайте скормим чудищу лесному еще одну девственницу, глядишь, подавится на этот раз».

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

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

    Пример два: синдром малой крови


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

    По-умному это называется «оптимизаций процесса», в народе — «делать три конца».

    Если вы делаете для внешнего заказчика, то он рассчитывает получить продукт, например за 10 рублей, а если вы ему приносите за 3, то он справедливо вас отправляет обратно, и не факт, что не отправит еще раз, когда вы ему принесете то, что сделали на оставшиеся 7.

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

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

    Masochism


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

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

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

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

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

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

    P.S.


    Еще немного на тему Basecamp’ов.

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

    При этом тебе все равно пишут в скайп: «Я там открыла задачку» и «Я там закрыл задачку».
    Есть все возможности для того, чтобы просто парсить сообщения и строить из них отчетность. Почему это никто никак не сделает?
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 50

      +3
      > Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?
      C матами? :)

      Что по теме. В общем-то вы всё сказали двумя словами, «автоматизировать процесс». Если есть процесс, то его автоматизация помогает, нет — мешает.

      Ну и да.
      Системы управления проектами нужны. Нужны потому что есть разные пользователи (и одна общая база на них на всех). Да, заполнять неудобно, да заполнять лень. Зато это окупается тем, что все в курсе всего и (!) всё в одном месте. Да и вообще не представляю уже давно, как можно управлять проектом без диаграммы Гантта. Этак даже не знаешь, когда всё закончится с одной стороны, с другой стороны не нужно всё держать в голове — особенно если проектов больше двух. Спасают…
        +1
        Если процесс препарировать, потом упорядочить, потом оптимизировать, то вот в этой стадии автоматизировать его сущий пустяк.

        А если процесс никто из исполнителей толком не понимает, то и автоматизация получается никому не понятная (в еще большей степени), и никто не сможет заставить этими средствами пользоваться, а если и заставит, то выйдет еще хуже — вместо одного кривого процесса два параллельных кривых процесса (второй — отражение первого в кривом зеркале автоматизации).
        +1
        игривая затея
          +2
          >Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?
          Да и матюги будут и орфография кривая… и косяки автоматизации, например проверка почты парсером каждые 5 минут даёт задержку обновления статуса задачи по крайней мере на эти же 5 минут. Ну и как крайность — подвисание сервиса, БД, сервера… Что тоже бывает и без этого никак. Чем сложнее система автоматизации — тем она менее надёжна. Поэтому нельзя всё автоматизировать на 100% и отключить телефон — нужно подстраховываться — где джаббером, где телефоном и т.п.
            0
            Ну если технически, то у нас есть jabber сервер, который сообщение кладет в mq откуда ее забирает парсер, поэтому 5 минут-- это на сервере с паровой тягой.
            Да и по большому счету этот лаг не важен-- для коммуникации используется IM, а парсер формирует аналитику, которая оперативно не нужна, кроме того, она может быть полезна для цепочки вида: «я закрыл»-«почему ссылка зеленая?»-«верни задачу»

            Но задача конечно не тривиальная, мне кажется MS будет по силам скрестить Skype и Project- тогда и пойдет
              +1
              — «я закрыл #902985»
              — «а в #902985 ссылка зеленая и в #346224 надо увеличить фонт»
              — «верни #902985 и открой #346224»

              Вы будете запоминать тикеты?

              Придумываете себе франкенштейна, супер мегапоиск. :)
              Тулбар «последние задачи» -> клик #902985 -> «закрыть»

              +1
              > каждые 5 минут
              Вообще, есть куча разных Push решений. В IMAP есть, есть PubSubHubbub для абстрактных данных. Фиксированные таймауты уже не нужно закладывать в новые системы, кроме случаев интеграции с legacy системами.
              +14
              Тема от меня уже далекая, но стиль изложения очень уж понравился. Пишите еще.
                +4
                И картинок побольше!
                +16
                Прекрасный стиль изложения, респект!)
                  +1
                  По поводу учета эффективности — очень часто одно только наличие учета весьма эту самую эффективность повышает. Главное — не перегибать с этим учетом палку, отслеживая время каждого похода в туалет, например :)
                    0
                    Безусловно, нужно всегда соблюдать баланс между отчетностью и здравым смыслом.

                    Взгляд с другой стороны баррикад: учет эффективности может очень здорово повышать учитываемую эффективность, т.е. разработчик просто делает то, что система считает работой.
                    –1
                    Уважение!!! :)
                      +4
                      Возбудило! :)
                        +9
                        Интересный набор мыслей, равнозначно несвязанных между собой, как набор карточек.
                          0
                          К сожалению, часто чтобы связать мысли нужно плодить лишние смыслы, что не хорошо.
                          А так, да вы правы, у меня есть такая проблема, но не по отдельности же их выкладывать
                          0
                          Особенно в тему:
                          «В итоге мы получаем ситуацию, когда куча ресурсов тратится на что-то непонятное и прекрасное как песни китов: «общую шину», «суперпоиск» или «модуль сделать заебись».»
                          Ох как много этого и в наших конторах, и о ужас, в заподных. При чем там этого просто дофигища.
                            +2
                            Очень часто это синдром NIH. Вместо того, чтобы взять какой-то существующий фреймворк или приложение, мы пишем свой атомный подводный велосипед.
                            0
                            >«все что-то бегают и истерят, давайте-ка купим джиру, чтобы это прекратить»

                            А у нас ДВЕ системы управления для каждого проекта. Считается, что одна решает проблему «бегают», а другая — «истерят». Эффект очень неожиданный: развилась возможность одноверменного мышления над одной проблемой в двух разных категориях.
                              0
                              Расскажите поподробней!

                              Мы для проекта сейчас используем обычный спредшит: один лист — бэклог, второй — баглист. В дополнение к нему подключили trello.com но он играет чисто визуальную роль — там отслеживаем текущее состояние. Но у нас команда маленькая — хватает.
                                0
                                Ох, мы то же самое сделали в итоге.
                              +5
                              Афтар, пеши исчо!
                              Прямо Зощенко какой-то…
                                +4
                                Тут был соседний топик про дырявые абстракции. К системам учета и контроля тоже можно применить такие рассуждения. Эти системы оперируют понятиями которые, при определенных обстоятельствах, перестают описывать реальную ситуацию, а значит такая система начинает мешать решать реальные проблемы.

                                В моей практике была такая ситуация. Аутсорспроект, как полагается багтрекер заказчика, менеджеров научили всем этим пользоваться, программеры потихоньку начали разбираться как вся система работает. Началась работа, менеджеры принимают тикеты, раздают программерам, те их резолвят — вообщем все супер. Но после некоторого времени (год наверное) такая система начала сбоить. Заказчики ругаются, менеджеры ищут виновных, одни программеры засиживаются до поздна, другие увольняются. Это уже потом, когда я уволился, начал думать почему так получилось. Понятно, что сначала резолвились относительные простые тикеты, остальные тикеты труднее решить. Но менеджерам это было не понять, потому что они оперируют абстракцией — тикет, много решили — хорошо, мало — нет бонусов. Программисты конечно говорили об этом, но не так внятно, а у менеджеры уже давно научились фильтровать техническую информацию, которую грузит ему программер (как банерная слепота — за долгую практику мозг на бессознательном уровне отсекает ненужную информацию).
                                  +2
                                  В этом плане, есть еще клевая тема-- если задача профакаплена, ее можно уже и не делать- все равно уже минус в карме.
                                    0
                                    Довольно интересное наблюдение. Ещё есть практика, что если задача сложная, её разбивают на ряд задач, объёмом не более 2-3 дней. Тогда видно, кто на чём зависает (при условии ежедневного отчёта о прогрессе) и легче соразмеряется сложность разных задач. Но вообще, если менеджеры не понимают тему и начинают думать исключительно категориями тикетов — пробуксовывание проекта обеспечено, потому что никому не выгодно делать сложные задачи, которые и сформулировать-то сложно, не говоря об разбиении на части. А такие обычно лежат в глубине решения общей задачи; если не решены — топтание на месте, латание дыр возможно, нормальное решение — нет.

                                    Возможно, у вас проблема заключалась в наборе недостаточно грамотных менеджеров, например, из-за оптимизации их по зарплате в течение года (брали только тех, кто соглашался на низкую зарплату, но не умел работать).
                                      0
                                      Фразу «оптимизация по зарплате» я бы в кавычки взял :)
                                        +3
                                        Менеджеры вообще лишние в этом деле. Общий трекер и есть менеджер, если толково заряжен. Все это программеры сделают сами, если заинтересованы в результате (всего проекта), а не тупо в закрытии тикетов.

                                        У программеров профессия — управление сложностью, они на этом менеджменте собаку съели (хотя может сами и не догадываются). Надо их просто поставить в нужном месте в нужное время и объяснить роль в общем механизме. Вот это задача для менеджера — но не «манагера», а опытного программиста.
                                      • UFO just landed and posted this here
                                        0
                                        При этом тебе все равно пишут в скайп: «я там открыла задачку» и «я там закрыл задачку».
                                        Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?

                                        Только не это!
                                        Будет тоже самое, динозавровое, только еще и с ошибками :)

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

                                          P.S. Все-таки в BDSM буква D чаще подразумевает Domination, и про это тоже вполне можно было бы написать в рамках «управления разработкой».
                                            +5
                                            Истину глаголишь, но истинное Domination как в Теме, так и в управлении проектами встречается чуть более чем не часто. Ведь в управлении проектами Domination это как правило роль, а не сущность. И играют эту роль как правило, хлюпики у которых эта девиация сексуального поведения развивается как психологическая компенсация. Вот уж действительно какие интересные параллели между «менеджерами» и «господами по вызову» :-)

                                            True Domination — это когда ты зажигаешь разработчиков темой так что она становится им интересна и они работают от души. Этого не достичь ни кнутом ни пряником, ибо играя роль нижнего, они как правило нижними не являются, вот ведь какая однако девиация сексуального поведения.
                                            +1
                                            Я один прочитал заголовок как БСДМ? =)
                                              0
                                              Да, все прочитали как БДСМ :)
                                                0
                                                В данном случае это вовсе не BSD!
                                                0
                                                Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?

                                                Делают-делают, аналогичная идея появилась году в 94м, тогда же и реализовали.
                                                Сейчас это больше похоже на wiki, т.е. все сообщения интерпретируются как wiki (с расширяемым языком разметки, что и позволяет любой фрагмент любого сообщения считать командой и «проводить» соответствующие учетные действия).
                                                • UFO just landed and posted this here
                                                    0
                                                    >Ага, сидит куча красноглазиков, и что они там делают— непонятно, и мало что непонятно, так еще и за очень нехилую такую зарплату.
                                                    Блин, везет же им
                                                      0
                                                      Классно, но резануло: «живет мечта о боге из машины».
                                                      «бог из машины» звучит как «Deus ex machina», т.е. «выражение, означающее неожиданную, нарочитую развязку той или иной ситуации, с привлечением внешнего, ранее не действовавшего в ней фактора».

                                                      Непонятно, это очень тонкий такой стеб, игра смыслов, или немного корявый перевод?
                                                        0
                                                        Я подразумевал «Deus ex machina», но, честно говоря, ввернул дословно для красного словца.
                                                        Но благодаря тому, что вы написали про «неожиданную развязку» появится еще один слой, который я честно говоря не подразумевал
                                                        +3
                                                        А я гляжу, пацаны-то в Теме!
                                                          +2
                                                          хорошая статья, дельная.

                                                          мои 5 копеек относительно таск-менеджеров. Я в работе своей команды долго пытался обойтись без систем управления. Скайп и тп — это ведь достаточно? В итоге оказалось что без системы никуда. Вопрос в эффективности и удобстве — напишите свою. Мы так и сделали — основной упор делался на удобстве. Так что в итоге все довольны, а времена когда все было в чатах и тд вспоминаются с ужасом.
                                                          • UFO just landed and posted this here
                                                              0
                                                              Отличная статься, но… Эй, руки прочь от самокатов! Это святое! :)
                                                                +2
                                                                порекомендую книгу
                                                                Записки автоматизатора. Профессиональная исповедь
                                                                Андрей Георгиевич Орлов

                                                                покупал когда еще нельзя было скачать, не жалею
                                                                  +1
                                                                  я читал в скачанном варианте. атомная бомба, а не книжка :) советую почти всем кто в теме :)
                                                                  0
                                                                  В итоге мы получаем ситуацию, когда куча ресурсов тратится на что-то непонятное и прекрасное, как песни китов: «общую шину», «суперпоиск» или «модуль сделать заебись».


                                                                  Борюсь с такой фигней уже долгие годы. Кстати, тоже ненавижу программистов. Об их инфантилизме и глупости еще Ашманов в своих скрижалях писал.
                                                                    0
                                                                    Ашманов писал не об инфантилизме, и тем более глупости, а об некотором «аутизме». Это не уровень интеллекта, а скорее психологический тип, склонный к «чрезмерной» интроверсии.
                                                                      0
                                                                      Ашманов писал о некоторых типично детских замашках программеров, что свидетельствует об инфантилизме. Глупость у них присутствует не «интеллектуальная» (ибо они все, разумеется, ниибацца мозги), а глупость от неразвитости.

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

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

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

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