Офисное, просто офисное

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

Бывает так, что встречаются люди, и говорят: “а вот нефигово бы забабахать такой-то крутой сервис, который будет офигительно нужен такой-то аудитории! Все считают, что нефигово? Так давайте, вместе и забабахаем!”, они — единомышленники, они собираются командой, у которой есть единая цель, и каждый из команды, в зависимости от специализации, выполняет свою часть работ таким образом, чтобы оптимальным образом достигнуть цели. Аналитики анализируют, админы обеспечивают интернет и сервера, программеры пишут код, дизайнеры рисуют интерфейсы, маркетологи работают с рынком. Бывает так, что каждый из команды находится в системе, где все элементы системы настроены на достижение практически одинаковой цели. Я знаю несколько таких команд, в той или иной степени похожих на то, что описано.

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

К примеру, какой-то руководитель осознал, что цель “сваять полезный тулз”, в общем-то, достигнута, и надо двигаться дальше, и это очень же приятно, когда твоё детище кому-то нужно, и хочется большего, и уже мало владеть тулзом и командой, которая этот тулз поддерживает, уже хочется стать значительной частью рынка, уважаемым, известным в отрасли монстром. Хочется славы и власти. У каких-то юных разработчиков так же очень важная цель — заработать побольше денег, чтобы жить комфортно, чтобы девицы чуть подороже и тачки чуть покруче, и в рамках описываемой системы, возможно, достигнуть этой цели реально, но для этого придётся немного поработать, а работать он умеет. А у какого-то другого разработчика цель другая: фиг с ними, с деньгами, ему нужно поднять skills после долгих студенческих лет пустой теории, и он будет стараться, и пользу приносить, в расчёте на то, что дальше уже — по обстоятельствам, или в другую компанию, как квалифицированный спец, или в рамках той же компании, если хорошо сложатся обстоятельства.

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

И что какой-то разработчик, пусть и семи пядей, оказывается, хочет не только много зарабатывать, но и поменьше работать, попозже приходить и пораньше уходить, а тонко саботировать свой участок работ умеет и затягивание процесса объясняет грамотно и со знанием дела трудностями разработки. А другой, тоже семи пядей, остро хочет стать управленцем, хоть бы для начала и тимлидом маленькой команды, все с чего-то начинают, и для достижения этой цели затевает тонкую, никому не заметную паутину интриг, из-за чего блокируется (по непонятным причинам) работа какого-то направления, а его партнёр (напарник или кто-то там), который ещё недавно всех радовал хорошими результатами вдруг начал “делать всё не так”, и “неправильно”, и этого партнёра пессимизируют в системе за его “ошибки”, а то и вообще удаляют из системы как слабое звено или лишний элемент.

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

Организационный бардак, о котором было написано в начале поста, он тоже становится частью системы, без него никак не обойтись. Очень успешный ход project manager`а — отправить разработчикам двусмысленную (а то и трёх- четырёх- смысленную, сорри) постановку задачи и вовремя убраться куда-нибудь из офиса подальше по личным делам. Он-то никому не скажет, что он сам задачу не понял, а нарываться на упрёки в тупости несообразительности от генерального руководства ему впадлу, да и выполнение этой задачи “за сегодня” нарушает кое-какие его личные планы на weekend. Суперское решение в этом случае, и работает на ура. Разработчики только случайно могут решить задачу верно, чаще задача либо решается неверно, либо не решается вообще, за что их можно отругать, наказать, оштрафовать или даже уволить. PM при этом в шоколаде, да, попались вот такие неумные исполнители.

И вот ещё стабильно работающее решение: присылать в разработку эскизы неких форм или веб-страниц с требованием “сделать в точности, как нарисовано”. В случае отклонения в размере шрифта или ширины поля на 1px дрючить разработчиков нещадно, обвиняя в том, что именно из-за этого несоответствия, конечно же, проект оказывается коммерчески невыгодным. Ну да ладно, разработчики и в самом деле где-то недосмотрели. Через неделю прислать рекомендации к исправлениям, возьмём для примера визуальную часть, эти траблы мне ближе. Оки, поисправляли, дотошно, до пикселя. Проходит неделя. Присылаются НОВЫЕ ЭСКИЗЫ ФОРМ, в которых header и footer остались со старой, первой версии, и вот вы эти серединки изменяйте, а шапку и низ – не обращайте внимания, это маркетологи не исправили в соответствии со второй, последней версией. С психами и уточнениями делается третья версия проекта. И что вы думаете? К четвёртой, пятой, etc. версиям в разработку присылаются совсем уж загадочные экраны, на которых где-то правильный правый верхний уголок, а остальное осталось от предыдущей (первой, второй версии) и вы это не смотрите, где-то новая формочка (вы её добавьте в это место, а обрамление не меняйте, оно УСТАРЕЛО).

К моменту, когда разработчики привыкли к бардаку в эскизах и к определённой каше в версиях экранных форм, нужно прислать новые экраны, указав на новые формы, получив же результат, обнаружить, что формы поменяли, внешнее же оформление оставили то, какое было в шаблоне последней версии проекта, а не то, которое в эскизе, привыкнув к тому, что ошибочные оформления в шаблонах наследуются из версии в версию, иногда пересекаются (ещё вчера оформление было ошибочно оставлено из третьей версии, а сегодня прислали ошибочное оформление из второй версии, потому что эту модель продумывал другой маркетолог, у которого третьей версии под рукой не было, а была только вторая). Вот здесь следует устроить очередную раздачу розог всем с удивительной постановкой вопроса: руководитель им, видите ли, поставил задание, а они, видите ли, его решили проигнорировать! На эскизе же N-ной версии изменился header! Почему вы не исправили во всех файлах проекта на новый header??? Робкие попытки разработчиков заявить о том, что они подумали, что это артефакты с неправильных версий маркетологов, на которые они привыкли не обращать внимание, только подливают масла в огонь. Ситуация, в которой что-то объяснять, взывать к здравому смыслу смысла-то и не имеет.

Ещё очень полезно в течении месяца собирать программеров в конференц-руме и обсуждать с ними движок будущего сервиса. Рассказывать им что, зачем и для кого этот сервис нужен. Перетирать детали с подключением по громкой связи удалённых маркетологов и прочих ответственных лиц. После прийти к дизайнерам и поставить им задачу нарисовать суперский интерфейс для нового сервиса. А спустя неделю — громко и публично бранить дизайнеров за то, что они нарисовали идиотскую фигню, совершенно не подходящую для сервиса ни с точки зрения движка, ни с точки зрения рынка. На замечание о том, что “дизайнеры не в полной мере понимают, что и для чего они рисуют” взвинтиться и заявить, что этот сервис уже месяц обсуждается, вы что там, на другой планете живёте? На вопрос, почему же дизайнеров ни разу не пригласили в тот же конференц-рум, когда проект был на стадии обсуждения, авторитетно заявить “вам это не нужно!” (мы уже проходили эту фразу выше, и знаем, что она успешно работает). Интересно, как, дизайнеры в кулуарах на перекурах у программеров должны выпытывать, что же на самом деле происходит? А если дизайнер не курит, то как? И каким это образом, и, главное, в честь чего собственно программеры должны рассказывать дизайнерам суть проекта? У них, как правило, задачи как раз другие.

RSS feed | Trackback URI

5 Comments »

Comment by Золотой
2008-06-08 21:26:03

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

а вот воще козырная фраза:
“а вот нефигово бы забабахать такой-то крутой сервис, который будет офигительно нужен такой-то аудитории! Все считают, что нефигово? Так давайте, вместе и забабахаем!”

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

 
Comment by Антон
2008-06-11 17:39:14

“а вот нефигово бы забабахать такой-то крутой сервис, который будет офигительно нужен такой-то аудитории! Все считают, что нефигово? Так давайте, вместе и забабахаем!”

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

 
Comment by Yaroslav
2008-06-12 09:41:24

Как всегда и бывает, кто то что-то делает а кто-то ….пинает. Лавры достаются вообще третьему.

 
Comment by Scratch
2008-06-12 15:52:23

Да, пресловутая “коммерческая тайна” — это не для того чтобы враги не узнали, а для того чтобы свои не догадались…
И фразу “вам это не нужно” я слышал часто. Периодически возмущался, отвечая “если мне это не нужно, то какого … я это буду делать? Тебе нужно, ты и делай”, ну и в таком же духе.
Пока не достало окончательно.

 
Comment by Артур
2008-08-22 19:52:54

Действительно Антон, природа человека такова, кто-то жаждет больше славы, кто-то больше денег, кто-то и того и того хочет в избытке…

 
Name (required)
E-mail (required - never shown publicly)
URI
Subscribe to comments via email
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> in your comment.