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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Discipline

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

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

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

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

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

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

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

Sadism

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

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

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

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

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

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

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

В качестве бонуса:

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

Резать, не дожидаясь перитонитов, так как маленькой струйкой из вас вытечет все равно больше. Так что надо пойти к заказчику (в т.ч. внутреннему), сказать: «Пацаны, что-то пошло не так, давайте будем честны друг с другом» и:

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

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

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

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

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

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

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

Masochism

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

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

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

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

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

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

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

P.S.

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

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

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