Pull to refresh

Дайте мне работать-2

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

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

Для начала, давайте рассмотрим типичные роли в типичной IT-компании. Обычно, упрощенно, есть 3 уровня. Если есть 2, то это либо очень маленькая компания либо очень глупая. Итак:

1.Программисты — реальные исполнители, рабочие лошадки, те кто реально делает работу, пишет код, поддерживает и обслуживает проект
2.Менеджмент — это тех. директор, ПМ, продюсер, маркетинг и т.д., то есть люди кто осуществляет непосредственное руководство проектом, постановку задач, планирование и др.
3.Заказчик — тот кто дает деньги, обеспечивает бюджет, и главное это тот, кто хочет получить прибыль. Это главный чел, именно тот из-за кого вообще весь этот сыр-бор.

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

Казалось бы, IT-таджики — самый лучший вариант. Но давайте задумаемся ради чего работают IT-таджики? Они работают ради своей зарплаты. Они готовы делать все, что скажут, лишь бы платили деньги. Если менеджмент горит «надо», «Джамшут» отвечает «есть»! Важно ли этому Джамшуту получит ли заказчик прибыль или нет? Да, может какой-то извилиной он и понимает, что прибыль заказчика позволяет ему платить зарплату, и потому, прибыль заказчика конечно важна. С другой стороны, ну обанкротится он, ничего страшного, можно найти новую работу. Да и поднимет ли заказчик зарплату, если его прибыль вырастет? Заметит ли вообще твою заслугу? Стоит ли овчинка выделки? Даже если Джамшут сумеет додумать эту мысль до конца, ответом скорее всего будет «Нет». Поэтому этот чувак никогда не будет делать что-то, что выходит за рамки поставленных менеджментом задач, даже если он видит что это, прямо или косвенно принесет прибыль Заказчику.

Но хуже всего, когда IT-таджики переходят на следующий уровень. Как я писал в предыдущем эссе, это случается регулярно. Они терпеливы и прилежны, такие, казалось бы, идеально подходят для руководящей должности. Но это еще одно заблуждение. Потому, что меняется уровень, меняется ответственность и круг задач, но не меняются цели. А цель как и раньше — получить зарплату. А запись в трудовой уже позволяет надеяться, что есть большие шансы найти работу этого же уровня. Спорно? Думаете менеджер заинтересован в прибыли заказчика? Нет, максимум в чем он заинтересован — держать заказчика на голодном пайке, то есть, что бы прибыль была, но не сильно большая. Что бы он, с одной стороны, был как бы доволен, с другой что бы не сильно рад. В этом есть смысл, но обо все по порядку.

Понятно, что для Заказчика конечная цель — получение прибыли, но между всем прочим Заказчик хочет, что бы:
1.Задачи выполнялись быстро
2.Работа выполнялась качественно
3.Любые новые задачи быстро попадали в план, и выполнялись в кратчайшие сроки

Но соответствует ли это целям менеджмента, вышедшего из IT-таджиков? Нет!

1.Менеджменту не надо выполнять задачи быстро, потому что чем дольше длится проект, тем больше раз удастся сходить в кассу. Новый проект может и не появится, либо за него будут платить не столько, и он может быть сложнее (придется работать), а начинать новый проект всегда сложнее чем продолжать старый. Менеджеру выгодно внушить заказчику, что проект не может идти быстрее, что программисты тупые, что планы слишком часто меняются и тд. Все что бы тормозить проект любыми средствами. Это не выдумка. Я работал в одной компании, и случалось когда мы реально всей командой сидели, и пытались растянуть трехмесячный план на полгода. То же самое было и в других компаниях, когда проект специально переделывался несколько раз, что бы растянуть время и получить как можно больше ежемесячных бонусов.
2.Менеджменту не надо больше качества, по причинам описанным выше. Чем больше ошибок, тем больше длится проект. Наличие ошибок с одной стороны позволяет показать заказчику сложность проекта, с другой стороны, держать на короткой уздечке программистов, внушая им что у них руки-крюки, а заказчику, что во всем виноваты программисты. Ошибок не должно быть слишком много, но определенный уровень необходим. Но не только ошибки — проблема качества. Часть проблем качества продукта связанны со скоростью, с юзабилити, дизайном, гибкостью. Все это не нужно менеджменту. Это лишняя работа, за которую заплатят столько — же. Многие из улучшений будут просто не заметны заказчику. Если их ввести, он принесут ему дополнительную прибыль, но доказать, что эти прибыль была результатом работы менеджмента нельзя. Поэтому менеджменту достаточно держать планку качества на уровне «удовлетворительно». Выше нет смысла.
3.О, это наверное самая сытная «кормушка» для менеджмента. Осознают они это или нет, но это так. Менеджер стремится внушить заказчику что внесение изменений это очень трудоемкий процесс. Что задачи должны ставится заранее, и планы это гранитные монолиты, не терпящие изменений. Менеджеры даже пишут толстые ТЗ, и носят их на подпись Заказчику. А если приходит таки новая задача, то это еще один повод растянуть проект. Если вы Заказчик, не верьте кислой роже менеджера, когда вы начинаете разговор о новой задаче, отсутвовавшей в плане. Он так маскирует свою радость, от того, что проект можно еще немного растянуть :)

На самом деле, это только краткий обзор. Вообще, практически всегда, цели менеджмента и заказчика совершено противоположные. Это же классическая схема. Кто-то дает бюджет, а кто то его «осваивает». Оглянитесь вокруг, в России это повсюду! И рыночный сектор не исключение. Там те же бюрократы, просто их не привыкли рассматривать с этой позиции. Ленивые прилипалы. Пиление различных бюджетов это древняя русская национальная забава!

Что же делать? Выход в незаслуженно заклейменных IT-художниках. Вспомним разницу — таджики работают за оклад, художники — за идею, за результат. Лучшей наградой художнику, будут не деньги за его картину, а его собственное удовлетворение результатом, восхищение зрителей на выставках и критиков в профессиональных журналах, а так же память потомков. Если ему удастся продать халтуру, это не вызовет у него большого удовлетворения. То же самое с IT-художником. Ему важен результат, ему важно, что бы кто-то подошел и сказал «вау, ты выполнил такую сложную задачу, и ни одного бага!»
Таковыми они остаются и на руководящих должностях. И именно такие нужны хорошему заказчику, потому что его цели и цели IT-художников схожи. По пунктам:

1.Менеджмент, состоящий из IT-художников стремится выполнить любую задачу быстро, как только может. Во-первых, больше всего боятся они рутины, и задачу необходимо выполнить до того как она превратилась в рутину. Сам проект, если он вялотекущий, может надоесть, потому менеджмент стремится сделать проект динамичнее, что бы он развивался быстро, быстрее появлялись новые задачи. Тем самым проект никому никогда не надоест, и производительность труда не будет падать. Во-вторых IT-художник не боится новых проектов, и даже наоборот, рад завершению любого проекта, да еще и в рекордные строки. Ведь это повод для гордости, повод рассказать всем как быстро и качественно мы завершили такой сложный проект.
2.Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать. Став начальником, это чувство остается. Если IT-таджикам, без разницы над какой задачей работать, лишь бы денег платили, IT-художник будет любым способом избегать появление багов, и править их как можно быстрее. И менеджменту нет никакого удовольствия ломать все планы, задерживать проект. Откладывать новые задачи ради того, что можно было бы и не делать. Их приоритетом всегда остается скорость и динамика проекта. Баги это тормоза проекта. Поэтому работа будет нацелена на то, что бы создать такие условия, в которых количество ошибок будет минимальным. Например, изначально грамотно ставит задачи, пытаясь учесть возможные проблемы, или внедрить модульное тестирование.
3.Как я и написал выше, динамика проекта это главное. Поэтому внесение изменений это не зло, это благо. Но для того, что бы постоянные пересмотры планов действительно не стали проблемой, необходимо правильным образом поставить работу, процесс внесения изменений в план, распределение и перераспределение задач. Для этого надо работать, и это еще один стимул для менеджмента состоящего из художников. Вместо того что бы внушать заказчику, что изменяемость приносит вред, они потратят усилия на то, что бы работа была поставлена так, что бы внесение изменений не вредило проекту. Это же еще одна интересная задача! Это же так увлекательно, и сколько удовольствия будет когда все получится!

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

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

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

P.S. Прошу прощение за использованную метафору у таджиков. Ничего против этой нации я не имею. Просто показалось такое сравнение очень удачным, ведь никто не скажет что они из-за любви к России едут сюда работать)))
Tags:
Hubs:
Total votes 112: ↑71 and ↓41 +30
Views 906
Comments 251
Comments Comments 251

Posts