Gaperton's blog

Два простых принципа, составляющих саму суть.

Никогда не откладывай на завтра то, что можно сделать послезавтра

Никогда не делай сейчас того, что можно отложить на потом. Близкое к этому (но не то же самое) – «не знаешь что делать - не делай ничего». Ибо - сейчас надо делать то, что действительно необходимо делать сейчас, и результат чего нужен завтра, а не что попало.

С детства в головах закреплено противоположное – «никогда не откладывай на завтра то, что можно сделать сегодня». Фанатичное следование этому правилу приводит к провалу проектов. Ибо сегодня можно начать делать очень много всякой ерунды. Чем, собственно, плоха задача, за которую мы беремся слишком рано?

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

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

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

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

в) Задание, запущенное слишком рано, которое завершится сильно до того, когда будет реально использован результат - это плохое задание. В идеале работы должны идти непрерывным потоком, чтобы результат завершенных заданий использовался немедленно. Это снижает требования к приемочным тестам, и, с другой стороны, «поддреживает кэша исполнителей в разогретом состоянии».

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

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

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

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

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

Ок, а как же нам понять, что именно надо делать сейчас, что завтра, а что – послезавтра? Мы переходим к основному, центральному моменту, когда пора аргументированно объяснить «как надо».

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

Что будет, если этого не делать? Инженеры интуитивно стремятся пускать вперед ты задачи, которые им понятно как делать. «мутные» задачи, которые непонятно как делать, (т. е. содержащие проблемы) они имеют тенденцию откладывать на потом.

Эти задачи - наиболее рискованные, трудоемкость которых точно не известна. То есть, позволив инженерам выбирать порядок реализации фич и работ, и пустив это на самотек, вы скорее всего получите очень пологую «кривую риска», которая будет слабо убывать к концу проекта. Другими словами, по мере продвижения по графику, прогноз окончания проекта не будет становиться достовернее, и вы можете получить сюрприз буквально на последних неделях до окончания. «О, да тут еще столько же работы». Знакомо?

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

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

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

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

Полезная фича – «хорошо бы сделать вот так», но обычно вы этим легко жертвуете, и не станете откладывать из-за них релиз.

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

Итак, если вы дадите инженерам определять порядок задач то они с высокой вероятностью:

а) отнесут рискованные задачи на конец проекта, а понятные двинут вперед

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

В итоге, если не принимать во внимание риски и важность фич, вы с высокой вероятностью получите план, в котором:

1) Кривая риска - пологая, т.е. прогноз срока не уточняется по мере продвижения.

2) Критичные и рискованные фичи отнесены на конец.

Чувствуете, что будет? А будет так. Тихо-мирно, точно по графику, мы дойдем до 80% завершения такого проекта (в начале стоят не особо рискованные задачи), и тут вдруг - ВНЕЗАПНО: проект намертво встал на 80-90% по базовому плану, и никак не собирается продвигаться дальше. Тысячи их, таких проектов. Программисты разводят руками, ссылаясь на сложность и принципиальную непредсказуемость своей работы. У менеджера жопа в мыле. Директорат уже распланировал бюджеты, и возмущен такой задержкой. Особенно их бесит то, что это произошло ВНЕЗАПНО, и они в ужасе от того, что ситуация ВДРУГ вышла из под контроля, хотя еще вчера все шло по плану.

Потому что в кузнице не было гвоздя, собственно.

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

1) Критичные фичи надо делать в первую очередь, а некритичные - во вторую.

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

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

1) Сначала делаем критичные фичи.

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

2) Вторым приоритетом делаем некритичные фичи.

Здесь совсем другое правило определения порядка - ибо в целом чем больше мы их сделаем за меньшее время, тем лучше. Поэтому, в на данном этапе мы применяем стратегию максимального КПД.

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

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

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

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

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

Ой! Ну, то есть, я хотел сказать, есть еще очень много полезных и важных вещей, конечно :) Но. Если Вы будете следовать приведенным правилам (при этом грамотно выдавая людям задания, и разумно управляя ресурсами), то будет все хорошо, даже если Вы как менеджер не делаете ничего больше.

И наоборот – если Вы не следуете данному правилу – на проекте начиная с определенной сложности, который не делается самотеком, Вам ничего не поможет. Ни fuck-up, пардон, я хотел сказать stand-up митинги, ни красиво оформленный план проекта. Который, кстати, на самом деле, кроме Вас просто никто не будет внимательно читать. Ни начальство, ни (тем более) подчиненные. И который будет проигнорирован. И Вы в глубине души это знаете. Ибо:

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

б) говоря откровенно - длинные документы все равно ведь по факту никто не читает, даже если есть когда. В том числе и Вы сами. Особенно – если они об абстрактных материях, и непосредственно Вас не касаются. Все просто стесняются в этом признаться, не только друг другу, но часто – даже себе. J