Archive for the ‘Эффективность’ Category

Ford против BMW, плюс оптимизация.

Понедельник, Март 17th, 2008

В куче своих статей я говорю об оптимизации разнообразных процессов. Например, тут:

Директор, дай рублик на ремонт.

Стоимость бага.

Работать 8 часов вредно.

Программистский синхрофазотрон.

Обучение мыслить на шаг вперед.

Собственно, а зачем она нужна?

Начну, с одной недавно произошедшей со мной истории. Я езжу на Ford’е Focus, достаточно старого по США понятиям 2000 года. И вот, как-то я выезжаю из двора, и прямо за мной выезжает навороченный такой спортивный BMW (увы, я не рыбак, модель не скажу). Ну и этот BMW паля колеса с пробуксовкой уносится в сторону светофора. Через где-то пол минуты я подъезжаю и обнаруживаю его стоящим на перекрестке (красный свет) в полосе за пятью машинами, сам же пристраиваюсь в соседнюю полосе за двумя авто (то бишь в результате я нахожусь впереди него). Свет переключается на зеленый, опять у него горят колеса, он уносится за горизонт, только для того, чтобы через 30 секунд я обнаружил его стоящим на следующем перекрестке. На этот раз в поворотной полосе с десятью машинами, сам я предпочел стать в поворотную полосу с тремя машинами.

А теперь, к чему это я… Абсолютно понятно, что в большинстве случае лучше быть компанией эквивалентной спортивному BWM и рвать вперед. И понятно, что ему просто не повезло, что светофоры были красные, не было бы светофоров и ограничений, при всем желании за ним было бы сложно угнаться.
Вопрос состоит в том, что не все
IT компании являются эквивалентом спортивного BWM, а большинство как раз являются компаниями, эквивалентными хорошей рабочей лошадке а-ля средней давности Ford.

И соответственно, для того, чтобы не отставать от других нужно, что

А) Прокладка между сидением и рулем работала хорошо

Б) Автомобиль был на ходу, масла заправлены и шины лучше, чтобы были не лысые.

Так вот А) нужно не просто оптимизировать, а развивать. А вот фактически вся оптимизация о которой я говорю, как раз и есть пункт Б). Да, можно толком в фирме ничего не делать и она будет как-то ехать вперед, но, раз в некоторое время от нее будут отпадать колеса, она будет застревать в самый неподходящий момент и т.п. И вы, как водитель, будете выходить, плеваться, ставить новые колеса и толкать ее сзади. И разумная оптимизация и настройка фирмы и есть то самое подливание масла. Это позволяет мотору работать не на преодоление силы трения всей компании, а на то, чтобы двигать компанию вперед.

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

Директор, дай рублик на ремонт.

Среда, Март 12th, 2008

Представьте себе, идет серьезные переговоры в кабинете директора. Приехали большие потенциальные заказчики. Без стука, заходит завхоз в грязных сапожищах, ничего не спрашивая, подходит к директору и заявляет: “Э… тут ручка поломалась, нужна десятка, чтобы купить новую”, директор извиняется перед заказчиками, начинает рыться в портмоне, находит десятку, отдает завхозу. Через десять минут тоже самое повторяет с фразами «Закончилась туалетная бумага» или еще чего-нибудь. Ну, как вы догадываетесь переговоры проходят, ну очень успешно и больше о этих заказчиках никто ничего не слышал.

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

Как вы считаете, должен ли директор:

Тратить свое время на выдачу такой суммы лично

Контролировать траты таких размером

Прерываться, на решение вопросов данного уровня

Я искренне надеюсь, что вы ответили «нет».

Теперь другой вопрос, почему, собственно, он не должен этого делать? Да потом, что час работы директора, скажем условно стоит $60/ч (это не его ЗП, а скорее стоимость его воздействия на фирму). Так, вот для того, чтобы решить даже такую мелочь, он отвлечется скажем на 5 минут (это еще хороший случай, так как, если мысля думается и ее сбить, то она долго может не возвращаться). Как результат, он потратит $60/ч*5/60 = $5, для того, чтобы даже не сэкономить, а просто выдать $2. В результате туалетная бумага, купленная завхозом, по цене будет ближе к золотой парче 🙂

Соответственно напрашивается несколько выводов:

— Обычно у завхоза на руках должны быть какие-то деньги, чтобы он не бегал за каждым рублем.

— У него есть предел до который он имеет тратить не спрашивая (например, $30 в месяц).

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

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

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

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

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

Идем дальше, добираемся до менеджеров. И вот тут мысль спориться окончательно, почему-то, если программист имеет право тратить $5/месяц без запросов вперед, то менеджеру могут выделить ну дай бог $7/месяц, ну в самом крайнем случае $10.

Опять же, менеджер уже способен запороть не просто один проект на пару тысяч, а штучки три проекта, которые на нем висят, включая работу еще штук 5 программистов, которые ему подчинены. Но опять же выделить ему лимит в $50/месяц…. у… не, страшно и низзя.

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

Как мне кажется, примерная формула предела для большинства IT работников, что человек имеет тратить в месяц до 1% * количество людей в иерархии подчиненных ему (включая самого человека) * на свою ЗП. Для программиста — это 1% от его зарплаты, для менеджера младшего менеджера с 5 подчиненными получается 6% от его ЗП, для старшего менеджера – 5 прямых подчиненных у каждого из которых 5 своих – 26% от ЗП.

Замечу, это не ограничения сколько он вообще может потратить, это ограничения сколько он может тратить и оповещать об этом пост-фактум.

Завхоз в этом смысле исключение, так как заранее известно, что ему понадобиться больше, чем 1% от ЗП.По этому поводу ему можно/нужно выставить сумму прямым образом (без учета формулы). Кстати, он и не IT работник, так что формула к нему пожалуй еще и поэтому поводу не применима.

P.S. Пост основан на реальных событиях. Это просто меня убила сегодня ситуация, когда менеджер у которого суммарно в иерархии порядка 30 человек (с зарплатами от $4k до $8k в месяц) пошел к своему начальнику, чтобы тот одобрил трату в $1.2k.

P.P.S. Прошла неделя с тех пор как начала обсуждаться это покупка. Она уже прошла через менеджера, фин. директора, админа и пока еще не куплена. Магазин где ее можно купить находится в 5 минутах от офиса.

P.P.P.S. После полторы недели, меня достало ожидание, пошел к фин. директору и вопрос был решен в течении 5 минут. Замечу, что на разные разговоры и обсуждения уже было потрачено часа полтора.

Умение оценить нерабочее время.

Воскресенье, Март 9th, 2008

Очень у многих (особенно  у наемных рабочих) есть проблема, что они не ценят/не оценивают свое свободное время.

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

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

Тем не менее, нужно иметь какую-то внутреннюю оценку стоимости своего нерабочего времени. Тогда получается, если вы имеете оценку нерабочего часа условного говоря $2/ч, то вы не станете тратить 4 часа, на поиск скидки в $2 доллара.

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

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

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

Стоимость бага.

Вторник, Март 4th, 2008

Берем количество выпущенных машин — А,

умножаем на вероятную долю машин с неисправностями — B,

и умножаем произведение на стоимость урегулирования вопроса без суда — С.

A на B на C равно X

Если X меньше затрат на доработку, возврата не будет.

И часто случаются такие аварии?

Вы и представить не можете.

Бойцовский Клуб

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

Фактически все, раз в некоторое время жалуются – почему <вставить название программы> работает так глючно. Вспомним, тот же Windows 95, благодаря которому Microsoft получила такую плохую репутацию.

А ведь, если вдуматься, то формула приведенная в эпиграфе верна. Если цена предполагаемо проданных программ (количество программ * цена программы) – A, вероятность того, что заказчик увидит баг – B и вероятность того, что заказчик не купит из-за бага программу, то A*B*C = X равно недополученной прибыли из-за бага. И соответственно, цена исправления бага Y. Как вы понимаете до тех пор пока X < Y, то никому не интересно будет исправлять этот баг.

Просто для того, чтобы показать порядок цифр. Предположим, что цена предполагаемо проданных программ $1M. Вероятность того, что заказчик увидит какой-то конкретный баг 1% и вероятность того, что заказчик не захочет покупать программу из-за этого бага 1%. Итого мы имеем 1M*0.01*0.01 = $100. Ну, что можно сказать… Сто баксов – это сто баксов. Есть баги, которые можно будет решить дешевле, есть которые дороже.

Несколько производных из этой формулы:

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

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

Пару вещей, которые находятся вне формулы:

— часто во время исправление вносятся новые баги (и это тяжело внести в формулу)

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

— чем дольше исправляются баги, тем дольше время до выхода версии.

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